Processos de Desenvolvimento de Software

O que é um processo de desenvolvimento?
- Define quem faz o que, quando e como, para atingir um certo alvo
Por que usar um processo?
- É a única forma de construir software de qualidade:
  - Que satisfaça o usuário
  - Que apresente um nível aceitável de defeitos
  - Que seja feito no prazo e com orçamento estipulados
Tem muitos processos de desenvolvimento e nenhum pode ser usado sempre, para qualquer projeto
- Depende do tamanho, riscos, orçamento, distância das pessoas, etc.

As grandes fases de um processo típico de desenvolvimento

Planejamento e elaboração
- Planejamento, definição de requisitos, construção de protótipos (opcional)
Construção do sistema
Implantação (colocar em produção, treinar usuários, ...)

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 frequentes 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, ...)

processo1.gif (9262 bytes)

Que modelos e outros artefatos devem ser produzidos durante o processo de desenvolvimento de software?
- Artefatos também são chamados Deliverables
- É o que deve ser concretamente produzido pelas atividades do processo

Algumas idéias seguem
- Pode haver mais ou menos artefatos, dependendo da complexidade do projeto e do processo particular escolhido
Nem todos os artefatos são guardados para sempre
- Processos requerem que certos artefatos sejam guardados para sempre e sincronizados com o software ao longo do desenvolvimento
  - Neste caso, o artefato deve ser colocado sob "controle de mudança" (change control) usando um software apropriado
  - Um exemplo de um artefato que sempre está sob controle de mudança é o código.
- Outros artefatos não precisam ser sincronizados e colocados sobre controle de mudança. Pordem ser jogados fora depois que serviram seu propósito.
A conclusão de um artefato constitui um Milestone
- Pode haver outros tipos de milestones
  - Exemplo: apresentação para um cliente

Documento de business case (investigação preliminar)
Documento de orçamento e cronograma
Documento de especificação de requisitos
- Requisitos funcionais (Modelo de use case)
- Requisitos não funcionais
Modelo conceitual inicial
Glossário
Projeto arquitetural (poderá incluir un Modelo de componentes)

Refinamento dos requisitos funcionais (Modelo de use case)
Refinamento do modelo conceitual (Modelo conceitual)
- Inclui vários tipos de diagramas UML
Refinamento do projeto arquitetural (poderá incluir un Modelo de componentes)
Refinamento do glossário
Projeto de baixo nível (Modelo de projeto)
- Pode incluir vários tipos de diagramas UML
- Pode incluir uma documentação no estilo Javadoc
- Esquema lógico de banco de dados
Testes de unidade e testes de aceitação
Código

Em algum momento do processo, todos os artefatos são sujeitos a reviews por outras pessoas
- Isso aumenta muito a qualidade