O Processo de Desenvolvimento de Software
Objetivos
- Contextualizar Análise e Projeto de software dentro de uma metodologia de
desenvolvimento (um processo de desenvolvimento de software)
Um processo de desenvolvimento de software
- Uma linguagem de modelagem não é suficiente
- Precisamos também de um processo de desenvolvimento
- Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de
desenvolvimento
- O que é um processo de desenvolvimento?
- Define quem faz o que, quando e como, para atingir um certo
alvo
- Veremos os detalhes de processos concretos em outras disciplinas
- As grandes fases de qualquer processo de desenvolvimento
- Planejamento e elaboração
- Planejamento, definição de requisitos, construção de protótipos (opcional)
- Construção do sistema (inclui codificação e testes)
- Implantação (colocar em produção, treinar usuários,
...)
A Fase de Planejamento e Elaboração
- Criar relatório inicial de investigação (para construir o business
case)
- Levantar requisitos funcionais e não funcionais
- Construir glossário (ao longo da fase)
- Definir modelo conceitual inicial (análise inicial)
- Projetar arquitetura
- Priorizar a funcionalidade e distribuí-la entre as iterações
Detalhes sobre o levantamento de requisitos
- Requisitos são "cortes" no espaço de solução
- Entendimento do que o usuário quer
- O resultado é uma promessa para o cliente
- Não só requisitos funcionais, mas também:
- Facilidade de uso necessária
- Quem utilizará o produto
- Hardware e software alvo para o produto
- Qualidade/robustez
- Desempenho
- Segurança
- Compatibilidade com outros produtos/versões e necessidades de migração
- Necessidades de internacionalização do produto
- Suporte
- Preço da solução
- Documentação necessária
- Uso de padrões
- Aspectos legais
- Integração com outros produtos
- Packaging
- etc.
- Não se fala "como" as coisas serão feitas
- "Use cases" descrevem cenários de funcionalidade desejada
- Também chamados de "User Stories", pois é o usuário que decide o que deve
ser feito
Detalhes sobre a fase de Construção
- 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
- Para evitar isso:
- 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, ...)
Detalhes sobre a análise
- A análise gera um modelo para entender o domínio do
problema
- Análise 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)
Detalhes sobre 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
Detalhes sobre 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
Detalhes sobre 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
intro programa