TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

Transcrição

1 TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado a objetos na disciplina Trabalho de Diplomação I dos cursos de Tecnologia em Processamento de Dados e Administração de Sistemas de Informações da Uneb. O texto entre colchetes e exibido em itálico/azul é fornecido para orientar o autor e deverá ser excluído antes da publicação do documento.] 1 Introdução [Este tópico descreve uma visão geral de todo o documento. Descreva a finalidade a que se propõe este documento. Qual a pretensão geral do desenvolvimento do projeto. Qual a motivação para a escolha do projeto.] 2 Análise Institucional 2.1 A Empresa [Descrever os dados pertinentes à empresa, que será beneficiada com o desenvolvimento do projeto (ramo de atividades, organograma, funcionograma, localização, entre outros).] 2.2 Descrição das Regras do Negócio [Contar a história do negócio, quais as atividades que a empresa desempenha independente das que serão automatizadas. Detalhar o melhor possível as regras de negócio que serão o foco do projeto. Se necessário, poderá ser acrescentado um diagrama de atividades para melhor entendimento do negócio.] 2.3 Descrição das Necessidades de Informações [Descrever quais são as informações necessárias e urgentes para melhorar a situação e a competitividade da empresa estas informações serão o foco do sistema. Mostrar também as soluções encontradas para resolver o problema (atividades que serão automatizadas). Obs: Nem toda solução será implementada. Ex: necessidade de ampliação do ambiente físico ou uma reestruturação.] 2.4 Ambiente Tecnológico Existente [Descrever o ambiente tecnológico da empresa, ou seja, como a empresa funciona atualmente, se tem ou não rede de computadores, acesso à internet, utilização de outros sistemas, etc.] 3 Abrangência do Sistema Proposto 3.1 Objetivos do Sistema Objetivo Geral [Fazer estas perguntas ao objetivo, se o mesmo responder, o objetivo estará correto.

2 1. A que situação se pretende chegar com o projeto? 2. Que resultado(s) (produto(s)) se espera obter com o projeto?] Objetivos Específicos [Este tópico deverá especificar todos os requisitos do software em um nível de detalhe suficiente para que os especialistas possam desenvolver o sistema satisfazendo os requisitos do cliente, os responsáveis pelo teste possam verificar se o sistema satisfaz a esses requisitos e os clientes possam avaliar se suas necessidades estão representadas nestes requisitos. Que atividades serão realizadas para alcançar cada um dos produtos do projeto? Na prática, requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi criado. Os requisitos podem ser classificados em: Requisitos Funcionais funcionalidade a ser implementada no software para atender a uma necessidade de automação. Por exemplo: o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal; o software deve emitir relatórios de compras por período de tempo ; emitir relatório gerencial com o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.] 3.2 Requisitos Não Funcionais [Este tópico deverá especificar todos os requisitos não funcionais do projeto, permitindo que os especialistas possam desenvolver o sistema satisfazendo as condições impostas pelo cliente e a infraestrutura de hardware e software existentes. Requisitos Operacionais Especificação de características relacionadas com o processamento do software, tais como: volume, freqüência, disponibilidade, performance, localização física, etc Requisitos de Contingência Tarefas alternativas para o caso de não funcionamento ou indisponibilidade eventual do software. Requisitos Técnicos Premissas e restrições quanto a arquitetura tecnológica, padrões, comunicação, ferramentas, linguagens, etc Requisitos Não Técnicos - Acordo, condições, ou termos contratuais que afetam e determinam as atividades de gerência de um projeto de software. Restrições Descrevem restrições a propriedades que, em princípio, seriam permissíveis, ou seja, tudo o que o software não deve fazer. Em muitos casos, é mais fácil declarar que certos comportamentos nunca poderão ocorrer do que declarar requisitos estabelecendo somente os comportamentos aceitáveis em todas as circunstâncias. São condições que limitam como o software poderá ser implementado. As restrições são condições preestabelecidas e devem ser obedecidas pelos projetistas e implementadores. Restringem as alternativas de implementação. Exemplos de restrições de projeto incluem o fato que o software precisa utilizar um certo sistema de banco de dados ou que o software precisa poder operar em uma máquina com pouca memória.

3 Por exemplo: a base de dados deve ser protegida, devem ter acesso apenas usuários autorizados; o tempo de resposta do sistema não deve ultrapassar 30 segundos; o software deve ser operacionalizado no sistema Linux.] 3.3 Metodologia e Tecnologia Utilizada [Inclua aqui.] 4 Documentação de Análise [Inclua aqui.] 4.1 Modelagem de Casos de Uso [Fazer referências bibliográficas da função da modelagem de casos de uso (qual a finalidade).] Diagrama de Caso de uso [Inclua aqui o seu diagrama principal de casos de uso, construído a partir da ferramenta de modelagem. O diagrama principal deve incluir todos os casos de uso que irão implementar os requisitos do sistema e os atores.] Especificação dos casos de uso [Os casos de uso deverão ter seu fluxo de eventos principal, fluxos alternativos, pré-condições e póscondições especificados no formulário Especificação de Sistemas Casos de Uso ou em modelo próprio (que contenha todas as informações solicitadas), referentes aos requisitos funcionais do sistema.] Checklist de Critérios de Avaliação dos Casos de Uso 1. Este Caso de Uso está representado no Diagrama de Casos de Uso que atende o módulo correspondente do Projeto? O item nome do caso de uso está preenchido em conformidade com o que está descrito no referido diagrama? 2. Os itens descrição resumida e atores envolvidos estão preenchidos? 3. No item interface, foi informado o nome da Tela correspondente ao caso de uso? 4. Todos os atores que se relacionam com este caso de uso estão sendo referenciados na especificação? 5. O item fluxo principal está preenchido de forma a retratar o funcionamento normal do sistema? 6. Todas as regras de negócio e de validação estão referenciadas no passo a passo, tanto no fluxo principal quanto (e principalmente) nos fluxos alternativos? 7. Todas as regras de negócio e de validação, citadas na descrição, aparecem dentro do fluxo principal e dos fluxos alternativos? 8. As pré-condições estão preenchidas de forma a mostrar os estados do sistema que devem estar presentes antes deste caso de uso ser realizado? 9. Todos os cenários estão contemplados no fluxo principal e nos fluxos alternativos? 10. Os fluxos alternativos estão preenchido de forma a tratar as exceções externas que podem ocorrer no

4 sistema? 11. O item pós-condições está preenchido? 12. O item fluxos de exceções está preenchido? 13. O item relacionamentos com outros casos de uso está preenchido? Ele está de acordo com o que está no Diagrama Casos de Uso? Os pontos de include e extend definidos aqui aparecerem no referido diagrama? 4.2 Modelagem de Objetos [Fazer referências bibliográficas da função da modelagem de classes (qual a finalidade).] Diagrama de Classe [Inclua aqui o seu diagrama principal de classes de negócio, construído a partir da ferramenta de modelagem. O diagrama principal deve incluir todas as classes que irão implementar os requisitos do sistema.] Especificação das Classes [Todas as classes que estão presentes no Diagrama de Classes deverão ser detalhadas no formulário Especificação de Sistemas Classes ou em modelo próprio(que contenha todas as informações solicitadas), incluindo todos os atributos e os métodos levantados, referentes aos requisitos funcionais do sistema.] Checklist de Critérios de Avaliação dos Classes 1. Todas as classes que aparecem no Diagrama de Classes (mesmo sendo classes que não possuam atributos ou métodos) estão descritas no formulário Especificação de Sistemas Classes? 2. Se a classe for uma sub-classe, foi informado o nome da sua superclasse no item especialização da classe? 3. Foi preenchido o item descrição da classe para todas as classes existentes no Diagrama? 4. Todos os atributos e métodos descritos no formulário Especificação de Sistemas - Classes estão presentes no Diagrama de Classes? 5. Os nomes dos atributos e métodos das classes estão seguindo o padrão de codificação da orientação a objetos? 6. Os nomes das colunas e tabelas do Banco de Dados estão coerentes com o modelo de classes? 7. O Diagrama de Classes contempla somente, e tão somente, as classes de negócio, não contendo classes de arquitetura? 8. O nome da classe é um substantivo? Todas as palavras que compõe o nome da classe iniciam-se com letra maiúscula? Os atributos iniciam-se com letras minúsculas? 9. Os atributos das classes estão representados? Existe classe vazia? 10. Os métodos mais complexos (por exemplo, que realizam cálculos ou consultas com ordenação diferente da

5 chave primária) estão especificados de forma mais detalhada? 11. Algum item do documento de especificação das Classes foi omitido (ou não preenchido) sem justificativa? 4.3 Modelagem Dinâmica [Fazer referências bibliográficas da função da modelagem dinâmica, incluindo os diagramas de seqüência, de atividades e de estado (qual a finalidade de cada um).] Diagramas de Seqüência [Apresentar os diagramas de seqüência que atendam a pelo menos 5(cinco)casos de uso existentes no diagrama de casos de uso. Os diagramas podem ser comentados caso haja necessidade, porém o próprio diagrama deve conter o máximo de informações para que possa ser compreendido. Deve-se desenvolver diagramas de seqüência com bom senso, ou seja, não é necessário um para cada fluxo de eventos, porém não se deve exagerar na quantidade de fluxos para cada diagrama.] Checklist de Critérios de Avaliação do Diagrama de Seqüência 1. Nos Diagramas de Seqüência, os nomes das classes aparecem conforme especificado no Diagrama de Classes? 2. Estão todas as classes de objetos, que aparecem no Diagrama de Seqüência, especificadas e presentes no Diagrama de Classes? 3. Todas as chamadas aos métodos, no Diagrama de Seqüência, fazem referência a métodos descritos no documento de Especificação de Sistemas - Classes? 4. As interações, como descritas nos Casos de Uso, entre ator e interface, estão contempladas no Diagrama de Seqüência? 5. Existem Diagramas de Seqüência para todos os fluxos básicos descritos no Caso de Uso? 6. As mensagens de retorno estão representadas no Diagrama de Seqüência? 7. O Diagrama de Seqüência contempla somente, e tão somente, classes de negócio, não contendo classes de arquitetura? Diagramas de Atividades [Apresentar os diagramas de atividades que atenda a pelo menos cinco fluxos de eventos existentes no diagrama de casos de uso. Os diagramas podem ser comentados caso haja necessidade, porém o próprio diagrama deve conter o máximo de informações para que possa ser compreendido. Poderá ser utilizado ] 5 Documentação de Projeto 5.1 Arquitetura do sistema 5.2 Projeto de Banco de Dados

6 5.2.1 Modelo Entidade X Relacionamento (MER) Operacional Inclua aqui o seu diagrama principal de entidades x relacionamentos operacional, construído a partir da ferramenta de modelagem. O diagrama principal deve incluir todas as tabelas que irão compor o banco de dados relacional, que irão implementar os requisitos do sistema Especificação das tabelas Todas as tabelas existentes no Modelo Entidade x Relacionamento Operacional deverão ser detalhadas em modelo próprio, incluindo todas as chaves primárias e estrangeiras e os demais campos, com as suas respectivas características. Checklist de Critério de Avaliação de Tabelas 1-Todos os nomes de atributos estão dentro do padrão definido na instituição? 2-Os atributos de classe tipo CS(classificador)/IN(identificador) estão associados a um domínio (restrições integridade)? 3-Todos os atributos estão com suas descrições preenchidas? 4-Todas as opcionalidades e obrigatoriedades foram preenchidas? 5-Todas as propriedades relativas a tamanho e tipo foram preenchidos? 6-Os tipos preenchidos atendem, ao SGBD que a empresa utiliza? São implementáveis? 7-Os tamanhos dos atributos são compatíveis com as classes utilizadas? Critérios de avaliação de Entidades 1-Todas as entidades estão dentro do padrão da norma da instituição? 2-Todas as Entidades estão com suas descrições preenchidas? 3-Os volumes (propriedades) foram preenchidos (estimado/crescimento)? 4-A entidade está com todos os atributos preenchidos? 5-As chaves primárias das entidades foram definidas? 6-As chaves estrangeiras foram definidas? Critérios de avaliação dos relacionamentos 1-A cardinalidade dos relacionamentos está preenchida e são justificáveis pela regra de negócio? 2-A totalidade dos relacionamentos está definida? Critérios para Avaliação do Diagrama 1-A notação utilizada na elaboração do MER na ferramenta case está no mesmo padrão definido?

7 5.3 Projeto de Interfaces Layout e Lógica de telas [Incluir o desenho da tela, contemplando os campos e elementos gráficos de interface que serão considerados. Descrever o processo de interação usuário aplicação, ou seja, descrever as ações que deverão ser realizadas pelo usuário e as reações emitidas pela aplicação, de cada um dos campos e elementos gráficos apresentados no desenho da tela.] Layout e Lógica de relatórios [Incluir o desenho dos relatórios. Descrever o processo de interação usuário aplicação, ou seja, descrever as ações que deverão ser realizadas pelo usuário e as reações emitidas pela aplicação para emissão do relatório.] Ajuda on-line 6 Considerações Finais [Fornecer uma breve descrição do software que está sendo especificado e seu propósito, incluindo benefícios e objetivos. Relacionar o software com as estratégias de negócio e objetivos da organização.] 7 Glossário 8 Bibliografia 9 Anexos Observação: O projeto deverá ser redigido em norma culta da língua portuguesa, seguindo a metodologia científica, conter índice e páginas numeradas de acordo com o Manual de Elaboração de Trabalhos Acadêmicos para conclusão de Curso ( ).