Desenvolvimento de software: Construção

Como é feito a  Construção do software??

Hoje, é considerado errado ter um processo que gere um "big bang!", não se deve ter o software inteiro funcionando por inteiro no primeiro release, o risco é grande demais!
Um processo de desenvolvimento deve ser:

• Iterativo (ter várias iterações no tempo)
• Incremental (gerar novas versões incrementadas a cada release)

           Uma iteração dura entre 2 semanas e 2 meses:
           Motivos:

• Sempre tem algo para entregar para o cliente apressado (a última iteração)
• Os requisitos mudam com tempo e um processo iterativo mantém freqüentes contatos com o cliente o que ajuda a manter os requisitos sincronizados
• Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo

O que é feito a cada iteração?

• Análise (refinamento de requisitos, refinamento do modelo conceitual)
• Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
• Implementação (codificação e testes)
• Transição para produto (documentação, instalação, ...)

                                                                 

A análise

A análise gera um modelo para entender o domínio do problema, e  também trata em alto nível de como uma solução possível pode ser montada para atender aos requisitos . Acaba gerando uma especificação, mas sempre do ponto de vista do usuário e tratando apenas do domínio do problema.

Não trata de detalhes de implementação

Objetos tratados são sempre do domínio do problema (business objects) , muitos diagramas UML podem ser usados.

O modelo é para o cliente e não para o programador.

Atividades típicas durante a análise:
Refinar use cases

Refinar modelo conceitual

Refinar glossário

Definir diagramas de seqüência (opcional)

Definir contratos de operação (opcional)

Definir diagramas de estado (opcional)

 O projeto (design)

O projeto é uma extensão do modelo de análise visando sua implementação num computador.
Novos objetos aparecem, mas não são do domínio do problema, O resultado é para o programador ver, não o cliente
Objetos da análise são (geralmente) mantidos e são embutidos numa infra-estrutura técnica.

• As classes técnicas ajudam os business objects a:
  • Serem persistentes
  • Se comunicarem
  • Se apresentarem na interface do usuário
  • Terem desempenho aceitável (usando caches ou threads, por exemplo)

• As atividades de projeto incluem:
  • Fase de refinamento da arquitetura (high-level design)
    • Definição de pacotes (módulos), interfaces entre pacotes
    • Decisão sobre uso/criação de bibliotecas e/ou componentes
    • Falaremos disso em detalhes adiante
  • Fase de projeto detalhado (low-level design)
    • Atribuição de responsabilidades entre os objetos
    • Construção de diagramas de classes
    • Pode incluir documentação javadoc (ideal)
    • Construção de diagramas de interação (opcional)
    • Levantamento de necessidades de concorrência
    • Considerações de tratamento de falhas
    • Detalhamento do formato de saída (interface com usuário, relatórios, transações enviadas para outros sistemas, ...)
    • Definição do esquema do BD
    • Mapeamento de objetos para tabelas se o BD for relacional
  • Advertência: se você usar Test-Driven Development, então o design é feito bolando testes e escrevendo o software ao mesmo tempo
    • Neste caso, fazer diagramas ou Javadoc antes de codificar não funciona

A implementação

• Escrita do código
• Relativamente simples se o projeto tiver sido bem feito
• Programadores devem normalmente seguir regras de codificação da empresa
• Atividades incluem code reviews
• Não se deve chegar a esta fase cedo demais!
• Mais cedo você agarra o teclado, mais vai demorar a terminar!
• Poucos novos diagramas nesta fase.

Os testes

• Inclui várias fases de testes
• Testes feitos pelo próprio programador durante a programação
  • Unit test: teste de classes individuais (ou de grupos de classes relacionadas)
  • Functional test: teste de funções inteiras (item de menu, p. ex.)
  • Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding
• Testes feitos por equipes independentes de teste
  • System test: testa a integração entre todos os componentes do produto
  • Alpha test: teste de produto inteiro dentro de casa
  • Beta test: teste de produto inteiro fora de casa
• Testes devem ser automatizados