Modelos de Processo de Desenvolvimento de Software

Modelo Cascata

As fases deste modelo são bem definidas e claras, seguindo uma ordem sequencial.

1. Análise e definição de requisitos: Os requisitos funcionais e os objetivos do programa são definidos pelo cliente.
2. Projeto de sistemas e de software: Estabelece a arquitetura do software e agrupa os requisitos de hardware e software.
3. Implementação e teste de unidades: O projeto é traduzido em código e as unidades são testadas.
4. Integração e teste de sistemas: As unidades são integradas para gerar o software ou sistema completo.
5. Operação e manutenção: O sistema é instalado, operado e mantido.

Vantagens

• As fases bem definidas levam a um modelo simples de gerenciamento.
• Resulta em um software robusto.

Desvantagens

• Os requisitos devem ser completamente definidos muito cedo no processo.
• Tende a gerar retrabalho quando há mudança de requisitos.

Modelo Evolucionário

Este modelo se baseia no desenvolvimento de uma implementação inicial que é exposta aos utilizadores e evolui através de versões até se obter um sistema adequado. A especificação, o desenvolvimento e a validação ocorrem de forma concorrente.

Tipos de Desenvolvimento Evolucionário

• Exploratório: Desenvolvido em parceria com o cliente para explorar os requisitos. Inicia-se com as partes mais bem compreendidas e evolui com o acréscimo de novas funções.
• Protótipos Descartáveis: Utilizado para compreender melhor os requisitos do cliente e desenvolver a definição dos requisitos, especialmente através de experimentos com requisitos mal compreendidos.

Fluxo: Especificação → Versão Inicial → Desenvolvimento → Versões Intermediárias → Validação → Versão Final

Vantagens

• Atende aos requisitos de forma mais eficaz que o modelo Cascata.
• Requisitos e decisões de projeto podem ser postergados.

Desvantagens

• Dificuldade em medir o progresso do projeto.
• O software pode ficar mal estruturado, dificultando a compreensão e a manutenção.

Modelo Formal

Neste modelo, uma especificação textual é redefinida em uma especificação formal com base em notações matemáticas. Quando o nível de detalhes é suficiente, há a transformação em um programa.

Fluxo: Definição de Requisitos → Especificação Formal → Transformação Formal → Integração e Teste de Sistema

Vantagens

• Requisitos e implementação são comprovados matematicamente.

Desvantagens

• Pouco utilizado na indústria, pois não demonstra vantagens significativas de custo ou qualidade.

Modelo Baseado em Reúso

Este modelo é frequentemente utilizado informalmente em outros modelos, particularmente no evolucionário. As fases de especificação e validação são similares a outros processos.

Fases Específicas

• Análise de componentes: Busca por componentes que atendam aos requisitos.
• Modificação de requisitos: Revisão dos requisitos segundo os componentes disponíveis.

Fluxo: Especificação de Requisitos → Análise de Componentes → Modificação de Requisitos → Projeto de Sistema com Reúso → Desenvolvimento e Integração → Validação do Sistema

Vantagens

• Redução do esforço de desenvolvimento.
• Redução dos custos.

Desvantagens

• Adequações nos requisitos são inevitáveis.
• Risco de não atender totalmente às necessidades dos usuários.

Modelo Incremental

Combina vantagens dos modelos Cascata e Evolucionário. A ideia é desenvolver a especificação em conjunto com o software, minimizando o risco de frustração. As fases de projeto e implementação são realizadas em estágios (incrementos).

Processo

1. Identificar em esboço as funções do sistema.
2. Priorizar as funções a serem entregues.
3. Definir estágios de entrega (incrementos).

Os requisitos são detalhados a cada incremento. Mudanças durante o desenvolvimento de um incremento não são aceitas. Funções comuns são feitas no início ou sob demanda.

Fluxo por Incremento: Definir Requisitos do Esboço → Atribuir Requisitos aos Incrementos → Projetar Arquitetura do Sistema → Desenvolver Incremento do Sistema → Validar Incremento → Integrar Incremento → Validar Sistema

Vantagens

• O primeiro incremento atende aos requisitos mais importantes.
• Os primeiros incrementos podem ser utilizados como protótipos.

Desvantagens

• Os incrementos devem ser relativamente pequenos.
• Dificuldade em mapear requisitos importantes para incrementos pequenos.

Modelo Espiral

É um modelo evolucionário onde cada loop representa uma fase do processo, começando com um esboço e evoluindo a cada volta.

Setores de Cada Loop

• Definição de objetivos: Define o plano do projeto e os riscos.
• Avaliação e redução de riscos: Realiza uma análise detalhada dos riscos identificados.
• Desenvolvimento e validação: Um modelo de processo é determinado com base nos riscos (ex: protótipo evolucionário para riscos de interface, transformações formais para segurança, cascata para integração).
• Planejamento: O projeto é revisado e decide-se pela continuidade.

Principais Diferenças

• Análise de riscos: Especifica objetivos, considera alternativas, identifica causas de riscos e as avalia.
• Não há fases fixas: O modelo espiral pode abranger outros modelos conforme a necessidade de cada fase.

Extreme Programming (XP)

Publicado por Kent Beck em 1999, o XP é um método de desenvolvimento incremental com incrementos muito pequenos, grande envolvimento do cliente, constante melhoria do código e programação impessoal.

Princípios e Práticas

• Estórias de Usuário: Requisitos escritos na linguagem do cliente com o mínimo de detalhes para estimativa de custos.
• Iterações: Duração entre 1 e 3 semanas, com prazos que devem ser levados a sério.
• Jogo do Planejamento: Planejamento de versões (releases) e planejamento das iterações no início de cada uma.
• Versões Frequentes e Pequenas: Para obter feedback mais rápido do cliente.
• Reuniões Rápidas (Stand-up meetings): Reuniões diárias para sincronização da equipe.
• Simplicidade: Fazer o mais simples que pode funcionar.
• Metáfora: Uma visão geral e simples do sistema, compartilhada por clientes e programadores.
• Soluções Spike: Usadas para reduzir riscos técnicos ou validar estimativas.
• Não Adicionar Funcionalidades Antecipadamente.
• O Cliente Está Sempre Disponível.
• Programação em Pares: Todo código é escrito por dois programadores em uma máquina, com rotação de pares.
• Propriedade Coletiva do Código: Qualquer um pode alterar qualquer parte do código.
• Padrão de Código: O código deve ser consistente e uniforme.
• Ritmo Sustentável: Evitar horas extras (semana de 40 horas).
• Integração Contínua: Módulos são integrados e testados diversas vezes ao dia.
• Refatoração (Refactoring): Melhorar a qualidade do código e remover redundâncias sempre que possível.
• Testes:
  • Testes Unitários: Teste das menores unidades (classes, métodos). São escritos para detectar bugs e antes da codificação.
  • Testes de Aceitação (Funcionais): Executados periodicamente para testar uma funcionalidade como um todo.

Rational Unified Process (RUP)

O RUP é um processo que combina métodos e uma linguagem (UML). É iterativo, incremental, guiado por casos de uso e baseado na arquitetura do sistema.

Disciplinas do RUP

• Modelagem de Negócios: Entender a estrutura, dinâmica e problemas da organização-alvo.
• Requisitos: Estabelecer e manter um acordo com os stakeholders sobre o que o sistema deve fazer.
• Análise e Design: Transformar os requisitos em um design de sistema e desenvolver uma arquitetura robusta.
• Implementação: Definir a organização do código e implementar classes e objetos como componentes.
• Teste: Atua como uma provedora de serviços para as outras disciplinas, verificando a qualidade.
• Implantação: Lida com a instalação personalizada e o acesso ao software.
• Gerência de Configuração e Mudanças: Identificar itens de configuração e restringir mudanças neles.
• Gerência de Projeto: A arte de equilibrar objetivos concorrentes para entregar o produto.
• Ambiente: Atividades necessárias para configurar o processo para um projeto específico.

Ciclo de Vida e Fases

O ciclo de vida de um sistema em RUP consiste em quatro fases, cada uma dividida em iterações:

1. Concepção: Define o escopo do projeto.
2. Elaboração: Detalha os requisitos e a arquitetura.
3. Construção: Desenvolve o sistema.
4. Transição: Implanta o sistema no ambiente do usuário.

Arquitetura

A arquitetura oferece uma visão geral do sistema, é prototipada nas primeiras iterações e serve para organizar a equipe e identificar oportunidades de reúso. Ela é descrita através de 5 visões: Process View, Deployment View, Programmer's View, Logical View, e End-user View (Use-Case View).

Casos de Uso

Os casos de uso são centrais no RUP e guiam atividades como o planejamento das iterações, a criação e validação do modelo de projeto, o planejamento da integração e a definição dos casos de teste.