Projeto da Disciplina

Projeto de Sistema de Informação

Professor:  Jaelson Castro
 

O objetivo desse projeto é possibilitar a prática de especificação de um sistema de informação, assim como detalhar um projeto de objetos para esse sistema. O projeto é para ser executado a partir da análise de requisitos que você fez na disciplina de Engenharia de Software. O projeto de um sistema é focalizado nas tomadas de decisão de alto nível em relação à estrutura geral do sistema. Projeto orientado a objetos relaciona-se com a definição de tipos de atributos, como operações funcionam, como objetos são ligados a outros objetos e na definição de interfaces de objetos. 

Passos para execução do Projeto

1. Adote  a especificação do sistema  feita na disciplina de Engenharia de Software. Revise o documento para capturar os requisitos não funcionais e organizacionais através das técnicas NFR e i*.
2. Defina o projeto de sistema. Atividades que precisam ser realizadas: identificar sub-sistemas e principais componentes, identificar concorrência implícita, aloque sub-sistemas para os processadores, selecione uma estratégia para gerenciamento de dados, escolha uma estratégia e padrões para interação computador-homem.
3. Baseado no projeto de sistema geral que você propôs, projete os objetos do seu sistema. Você deve se preocupar principalmente com os atributos e assinaturas de operações, visibilidade, interfaces, Princípio de substituição de Liskov, associações de projeto, restrições de integridade e operações de projeto.
4. Modele o projeto proposto usando as notações de UML: Diagrama de Use Cases, Diagrama de Classes, Diagrama de Sequência, Diagrama de Estados e Diagrama de Distribuição.
5. Projete procedimentos de entrada/saída e interfaces do usuário. Você pode precisar estender os diagramas de seqüência e de classes para incluir objetos de interface. Diagramas de estado podem ser também usados para modelar o comportamento dinâmico das interfaces.
6. Escreva um relatório descrevendo o sistema completo e o projeto de objetos. O relatório deve fornecer uma cuidadosa consideração de como os requisitos (funcionais e não-funcionais) são descritos no projeto.
7. Documente o seu projeto e complete o relatório de equipe (veja formulário no final). 

1. Página de Rosto: indicando os nomes dos membros de sua equipe, título do trabalho, curso, data, professor.
2. Índice: incluindo índice de figuras, seções e apêndices.
3. Introdução: descrevendo a organização que você escolheu para estudar, o problema que você identificou, e o processo que você seguiu durante seu estudo. (Não omita isso, pensando que o leitor tenha visto seu relatório de estudo de viabilidade). 
4. Descrição dos Requisitos: descrevendo textualmente os requisitos funcionais,  não funcionais e organizacionais do sistema de informação no domínio do problema. (Lembre-se de numerar todos os requisitos desde que isso facilita o rastreamento quando você fizer o projeto).
5. Modelagem Organizacional: usando a notação i*: Deve incluir os modelos de dependência estratégica e o modelo estratégico de razão. 
6. Modelagem dos  Requisitos Não Funcionais: usando o NFR Framework: Deve mostrar os refinamentos dos requisitos não funcionais, explicitar interdependências entre eles, mostrar operacionalizações.
7. Projeto do sistema: Uma descrição textual do projeto do sistema para o sistema proposto consistindo de redes de computadores (já existentes e novas), hardware (já existentes e novos) e plataformas de software (sistema operacional, outros sistemas comerciais que serão usados no sistema final). Também identificar os sub-sistemas e principais componentes, discuta qualquer concorrência implícita, aloque sub-sistemas para processadores e selecione uma estratégia de gerenciamento de dados. Discuta os princípios de interface do usuário que você planeja incorporar no seu projeto.
8. Projeto de objetos: Uma descrição do projeto detalhado do sistema usando a notação UML. Inclua os seguintes artefatos:

• Diagrama de Use Case: você precisa atualizar seu diagrama original para levar em consideração os procedimentos de entrada e saída.
• Diagrama de Seqüência: crie diagramas de seqüência para detalhar os use case do sistema e identificar as classes do sistema.
• Diagrama de Classes: revise seu diagrama original para levar em consideração decisões de projeto de objetos (assinaturas de atributos e operações, visibilidade, multiplicidade, interfaces, Princípio de substituição de Liskov, associações, restrições de integridade, etc.) Especifique completamente duas operações.
• Diagrama de Estado ou Atividades: Use estados para modelar o comportamento dinâmico das classes
• Interface do usuário e protótipo: Use um ambiente de programação visual para desenvolver um protótipo da interface do usuário.

     6. Conclusão: Um sumário do seu projeto

     7. Apêndices: Um ou mais apêndices para mostrar diagramas anteriores, dicionário de dados e outros artefatos.

Seu relatório deve ser digitado no formato A4. (210 x 297mm). Figuras devem ser claras e legíveis. Lembre-se de colocar uma página de capa indicando o nome de todos os membros da equipe, título do trabalho, curso, data e nome do instrutor. ). Entre outras coisas, os projetos serão julgados tanto pela aparência visual, corretude gramatical e qualidade da escrita quanto pelos seus conteúdos. O texto do seu projeto deve estar bem estruturado, usando parágrafos com sentenças completas, e todas as outras características de uma apresentação bem escrita. O relatório não deve consistir de uma lista de itens. Tamanho da fonte de texto deve ser de  12 pontos.

• Identificação do Problema (5%) Descrição do problema e visão geral do trabalho anterior.  Artefatos (nem todos são requeridos) que o avaliador pode avaliar:
  1. sinopse
  2. descrição de como o sistema é e seus problemas,
  3. descrição geral da solução ou meta do sistema proposto,
  4. evidência de contatos com pessoas na organização,
  5. gráfico da organização, gráfico da hierarquia gerencial.
  6. Diagramas de UML da disciplina de Engenharia de Software (incluído nos apêndices)

• Especificação dos Requisitos (25%)

• Projeto do Sistema (15%) Quão completo e bem organizado está a apresentação dos requisitos? Pontos que o avaliador irá considerar:
  1. Especificação da rede  de computadores (já existente ou nova)
  2. Especificação da rede  de hardware (já existente ou nova)
  3. Especificação da plataforma de software (sistema operacional e outros software comerciais que você irá usar no sistema final)
  4. Especificação da arquitetura de software, por exemplo, cliente-servidor, MVC, etc. (identificar 3 padrões de projeto)
  5. Identificação dos sub-sistemas e principais componentes.
  6. Discussão sobre alguma concorrência implícita
  7. Alocação de sub-sistemas para processadores
  8. Discussão da estratégia de gerenciamento de dados
  9. Discussão dos princípios de bom projeto de interface
  10. Protótipo da interface do usuário

   

  Projeto de objetos (45%) Uma descrição do projeto detalhado do sistema, referindo-se aos diagramas de UML e interfaces de entrada e saída, artefatos que serão examinados:
  1. Diagrama de Use Cases, incluindo versões de alto nível e expandidas
  2. Diagrama de Classes, incluindo pelo menos a especificação completa de duas operações
  3. Pelo menos 3 diagramas de seqüência (incluindo interface de objetos) para use cases específicos
  4. Pelo menos 3 diagramas de estado para classes específicas (para os mesmos use cases que forem especificados nos diagramas de seqüência)
  5. Diagrama de atividades da classe mais complexa.
  6. Para os diagramas, inclua um relatório relevante derivado do dicionário de dados 
  7. Uma discussão sobre esses artefatos e como eles estão relacionados com os requisitos

   

  Grade / Planilha de Avaliação

   

  	0-39%	40-49%	50-69%	70-79%	80 - 100%	Peso
  Diagrama de Use Cases	Descrição pobre - poucos  Use cases  são apropriados.	Alguma tentativa válida foi feita para identificar use cases.  Talvez algumas falhas ou omissões séries.	Todas as descrições de alto nível dos use cases estão incluídas. Talvez algumas estejam impróprias.	Boa descrição dos requisitos funcionais do sistema. Alguns erros secundários.	Tratamento exaustivo dos use cases, versões expandidas dos use cases estão incluídas. Todos os relacionamentos estão bem estruturados. Procedimentos de entrada e saída incluídos.	10%
  Diagrama de Classe: relacionamentos ( generalização, associação, composição, etc)	Descrição pobre - poucas classes são apropriadas.	Alguma tentativa válida foi feita, mas somente os atributos e operações mais óbvios foram mostrados.	Razoavelmente completo, talvez alguns são desnecessários, inapropriados ou omitidos. Algum uso de navegabilidade, multiplicidade, papéis, etc.	Quase todos elementos relevantes estão incluídos Inclui atributos derivados e assinaturas de operações.	Completo e consistente com o estudo de caso e bem justificado. Inclui especificação de pelo menos 2 operações	10%
  Diagrama de Classe: atributos e operações	Pouca ou nenhuma tentativa para descrever a notação do diagrama de sequência	Alguma tentativa válida é feita, mas somente mensagens óbvias são descritas. Use cases foram pouco estudados	Tentativa razoável. Talvez algumas mensagens são impróprias ou inconsistentes. Use cases podem não ter sido bem considerados.	Parece completo, a maioria das mensagens/eventos são apropriadas e consistentes com os outros diagramas	Completo e criativo, bastante consistente com o estudo de caso e bem justificado. Alguns objetos de interface estão incluídos.	10%
  Diagrama de Sequência	Pouca ou nenhuma tentativa, diagrama não está consistente com os outros modelos	Alguma tentativa válida é realizada. Alguma consistência limitada com outros modelos	Considerável tentativa no projeto. A maior parte consistente com outros modelos.	Parece claro e completo. Mostra claramente a interação com o usuário.	Completo e criativo. Consistente com estudo de caso	10%
  Diagrama de estado	ouca ou nenhuma tentativa, diagrama não está consistente com os outros modelos	Alguma tentativa válida é realizada. Alguma consistência limitada com outros modelos	Considerável tentativa no projeto. A maior parte consistente com outros modelos.	Parece claro e completo. Mostra claramente a interação com o usuário.	Completo e criativo. Consistente com estudo de caso	10%
  Diagrama de implantação	O diagrama contém nodos de instanciação apropriados e links de comunicação?					10%
  Interface do usuário e protótipo	O diagrama está consistente com outros diagramas ()Use cases, diagrama de classe, estado)?

• Apresentação (10%): O estilo de sua apresentação, incluindo linguagem, gramática, clareza da apresentação, organização dos apêndices, etc. 
  • 5% - Linguagem (Dedução de 0.5% para cada erro ortográfico ou erro gramatical até o máximo de 5%)
  • 5% - Estilo e clareza (Dedução de 0.5% para cada figura sem legenda ou ponto de confusão ou falta de elementos de estilo (por exemplo, índice, paginação, introdução, conclusão, apêndices, etc.).

(deve ser submetido com tarefas)

Descrição de papéis e contribuições de cada membro da equipe:

 

Nome                     % Esforço da equipe           Assinatura

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

Última atualização: sábado, fevereiro 16, 2002