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
3.1.1 Objetivo Geral
[Fazer estas perguntas ao objetivo, se o mesmo responder , o objetivo estará correto.
1.
2.
A que situação se pretende chegar com o projeto?
Que resultado(s) (produto(s)) se espera obter com o projeto?]
3.1.2 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.
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).]
4.1.1 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.]
4.1.2 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
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).]
4.2.1 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.]
4.2.2 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
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).]
4.3.1 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?
4.3.2 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
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.
5.2.2 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?
5.3
Projeto de Interfaces
5.3.1 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.]
5.3.2 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.]
5.3.3 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 ( http://www.uneb.com.br/anexos/manual_2.pdf ).