Estutura Típica do Relatório de Projecto de Alto Nível

Definição da Arquitectura

• Arquitectura lógica
  • refere-se à decomposição hierárquica do sistema em módulos lógicos (pacotes de classes), e à especificação dos interfaces e dependências entre módulos lógicos
  • descrita por diagrama de pacotes
  • a decomposição pode fazer-se por camadas (decomposição horizontal), por sub-sistemas (decomposição vertical) ou por ambos
• Mecanismos importantes
• Arquitectura física
  • refere-se à organização do software em componentes de run-time (módulos físicos) e à topologia do hardware (nós e conexões) sobre a qual esses componentes são distribuídos
  • descrita por diagramas de componentes e de distribuição (deployment)
  • convém indicar a localização dos componentes de run-time nos nós de hardware, e relacionar os módulos lógicos com os componentes
  • se possível e aplicável, especificar os interfaces implementados (exportados) e usados (importados) por cada componente
• Arquitectura tecnológica
  • Escolha de tecnologias a usar na implementação

Documentação do Protótipo

• Descrição de componentes
  • Especificação: serviços/dados disponibilizados e serviços requeridos (no caso de componentes visuais, a especificação do interface para o utilizador passa para o manual do utilizador)
  • Implementação: aspectos de concepção interna (algoritmos, estruturas de dados, etc.)
    • algoritmos podem ser descritos através de diagramas de actividades
    • ciclos de vida de objectos podem ser descritos por diagramas de estados
  • Testes: informação sobre testes unitários (procedimentos de teste, resultados de testes, etc.)
  • Aplicações: exemplos / casos de utilização
• Realização de casos de utilização
  • Parte estática: objectos envolvidos (objectos de interface, em memória (de controlo) e persistentes), incluindo objectos internos ao sistema
  • Parte dinâmica: diagramas de interacção (sequência, colaboração, actividades, ...)

Planeamento do Projecto

• Planeamento da fase seguinte (projecto detalhado e implementação)
  • definir iterações semanais, em que cada iteração deve resultar num incremento ao produto com valor para o cliente
    • iterações devem ser definidos de acordo com as prioridades dos casos de utilização, precedências entre casos de utilização e esforço/complexidade da sua implementação
    • definir tarefas dentro de cada iteração, com prazos, esforço previsto e executores
    • o planeamento das iterações deve ter em conta a necessidade de disponibilizar ao cliente uma "release" intermédia na semana de 29 de Abril a 3 de Maio.