Documentação complementar

1. Documentação de Gerenciamento e Escopo

O Porquê e o Onde

• Garantir o contexto do negócio e o gerenciamento contínuo do sistema, fatores essenciais para o profissional de TI
  • Modelo de Negócio e Metas:
    • Qual problema de negócio que o sistema resolve?
    • Quais são os objetivos do negócio (ROI, eficiência operacional, redução de custos)?
  • Complemento à Investigação e Visão Geral do Sistema.

• Glossário e Dicionário de Dados:
  • • Lista de termos, acrônimos e definições específicas do domínio de negócio e do projeto. O dicionário de dados define precisamente cada campo do DER (ex: código_cliente deve ser único, numérico, 8 dígitos).
  • Complemento aos Requisitos e ao DER

• Matriz de Rastreabilidade (Requisitos vs. Testes):
  • Documento que mapeia cada requisito funcional a um ou mais casos de teste e ao código ou componente que o implementa. Crucial para provar que todos os requisitos foram entregues e testados
  • Complemento a: Requisitos Funcionais.

• Plano de Evolução e Suporte:
  • Documento que detalha como o sistema será mantido após o lançamento (ciclo de manutenção, frequência de atualizações, processo para relatar e corrigir bugs) e quais são os próximos passos de desenvolvimento (roadmap).
  • Complementa a Visão Geral do Sistema.

2. Documentação de Design Detalhado

O Como

• Diagramas de alto nível (Componentes, Implantação e DER) estão presentes. Falta o detalhe da arquitetura interna e da lógica complexa
  • Diagrama de Classes (UML):
    • Mapeamento detalhado das classes, atributos, métodos e seus relacionamentos. Essencial para que novos desenvolvedores entendam o código-fonte rapidamente
    • Complementam os Diagramas de Componentes (que é mais abstrato)
  • Diagramas de Sequência ou Casos de Uso (UML):
    • Visualizam a ordem e a interação entre objetos e componentes para realizar uma função específica, especialmente em fluxos complexos
    • Complementam os Diagramas de Fluxo Principal (que são mais focados no processo de negócio)
  • Padrões de Projeto (Design Patterns) Utilizados:
    • Documentação de quais padrões de design (ex: Factory, Singleton, Observer) foram utilizados na arquitetura e por quê. Facilita a manutenção e a consistência do código.

3. Documentação Técnica do Código

O Como no baixo nível

• Estes são essenciais para os desenvolvedores que farão a manutenção (o "como" no nível do código):
  • Documentação da API (Interface de Programação de Aplicações):
    • Detalha todos os endpoints, métodos, parâmetros de entrada/saída e códigos de erro das APIs internas ou externas utilizadas pelo sistema. Geralmente gerada automaticamente (ex: Swagger/OpenAPI)
    • Complemento Diagrama de Componentes
  • Padrões de Codificação e Boas Práticas (Code Style Guide):
    • Explicação: Regras e diretrizes para escrever código no projeto (convenção de nomes, formatação, como lidar com exceções). Garante a consistência e a legibilidade do código.

4. Documentação de Testes e Qualidade

• Fundamental para garantir que o sistema funciona conforme o esperado e que as correções não introduzam novos bugs.
  • Casos de Teste (Test Cases) Detalhados:
    • Explicação: Conjunto de etapas, dados de entrada e resultados esperados para validar cada funcionalidade. Isso inclui testes de unidade, integração, sistema e aceitação.
    • Complemento a: Requisitos Funcionais.
  • Relatório de Cobertura de Código e Qualidade:
    • Explicação: Métricas de qualidade do código (cobertura de testes, complexidade ciclomática, densidade de bugs). Demonstra a saúde e a manutenibilidade do código.