Modelos de Processo de Software: Comparativo e Abordagens Híbridas

Modelos de Processo de Software: Definição

Os Modelos de Processo (ou paradigmas) definem a estrutura do processo de desenvolvimento de software (SW), em detrimento dos detalhes das atividades específicas. Eles são utilizados para explicar diferentes abordagens para o desenvolvimento de SW.

• Não existe apenas um processo de software que possa ser utilizado.
• Um mesmo sistema pode utilizar diferentes abordagens para o seu desenvolvimento.

Modelo Cascata (Waterfall)

Características do Modelo Cascata

• Uma fase só se inicia após o término da anterior.
• O marco para o final da fase normalmente envolve a aprovação de documentos.
• Na prática, as fases se sobrepõem: o projeto revela problemas de requisitos; a codificação revela problemas de projeto.
• Quanto mais tarde os problemas são identificados, mais cara é a solução.
• Erros mais caros são os de requisitos omitidos ou não entendidos corretamente.

Pontos Fortes do Cascata

• Fases bem definidas com marcos claros.
• Necessidade de requisitos bem compreendidos.
• Reflete o estado da prática da Engenharia de Software (Eng. SW).

Pontos Fracos do Cascata

• Requisitos devem estar bem definidos muito "cedo".
• Natureza mutável intrínseca aos requisitos.

Modelo Evolucionário

O desenvolvimento evolucionário envolve:

• Desenvolver uma implementação inicial.
• Expor os resultados.
• Evoluções através de versões.
• Obtenção de um sistema adequado.
• Especificação, desenvolvimento e validação concorrentes.

Tipos de Desenvolvimento Evolucionário

1. Exploratório:
   • Parceria com o cliente para explorar os requisitos.
   • Início com as partes (escopo) compreendidas.
   • Evolui com o acréscimo de novas funções.
2. Protótipos Descartáveis:
   • Compreender os requisitos do cliente.
   • Desenvolver a definição dos requisitos.
   • Experimentos com requisitos mal compreendidos.

Pontos Fortes do Evolucionário

• Especificação desenvolvida gradativamente.
• O atendimento dos requisitos tende a ser mais eficaz do que no modelo Cascata.

Pontos Fracos do Evolucionário

• Dificuldade em medir o progresso do projeto.
• Tendência a corromper a estrutura do software (SW), devido a mudanças constantes.
• Ferramentas e técnicas especiais (como geração de código CASE) dificultam a obtenção de Recursos Humanos (RH).

Modelo Formal

Características do Modelo Formal

• A especificação textual é redefinida em uma especificação formal com base em notações matemáticas.
• As fases de projeto, implementação e testes de unidades são substituídas por transformações da especificação em programas.
• A especificação formal é sucessivamente transformada em outra mais detalhada, e provas matemáticas são realizadas para garantir a corretude da nova especificação.
• Quando o nível de detalhes é suficiente, há a transformação em programa.

Pontos Fortes do Formal

• Requisitos com provas matemáticas.
• Implementação com provas matemáticas.
• Atende a exigências rigorosas de segurança, confiabilidade e garantia.
• Ideal para sistemas de missão crítica e tempo real.

Pontos Fracos do Formal

• Pouco utilizado na indústria (escassez de RH).
• Não tem demonstrado vantagens significativas de custo ou qualidade.
• A interação não depende diretamente da especificação/transformação formal, sendo aplicada às regras de negócio.

Modelo Baseado em Reuso

Características do Reuso

• O reuso é utilizado informalmente em outros modelos, particularmente no evolucionário.
• É uma nova sub-área da engenharia: Desenvolvimento Baseado em Componentes.
• Requer uma base de componentes reutilizáveis e infraestrutura de integração.
• Utiliza COTS (Commercial Off-The-Shelf Systems – Sistemas Comerciais de Prateleira).
• As fases de Especificação e Validação são similares a outros modelos.

Fases Específicas do Reuso

1. Análise de Componentes: Busca de componentes que atendam aos requisitos.
2. Modificação de Requisitos: Revisão dos requisitos de acordo com os componentes disponíveis.
3. Projeto de Sistema com Reuso: Projeto da infraestrutura à luz dos componentes versus requisitos.
4. Desenvolvimento ou Integração: Análise da integração dos componentes, COTS e desenvolvimento.

Pontos Fortes do Reuso

• Redução do esforço de desenvolvimento.
• Redução dos custos.
• Redução dos riscos.
• Time-to-market menor.

Pontos Fracos do Reuso

• Adequações inevitáveis nos requisitos.
• Risco de não atender totalmente às necessidades dos usuários.
• Perda do controle na evolução do sistema devido ao uso de COTS.

Casos de Uso (Use Cases)

Um caso de uso é um conjunto de instâncias, no qual cada instância é uma sequência de ações realizada por um sistema que produz um resultado de valor observável para determinado ator.

Modelos Híbridos e Iterativos

Todos os modelos vistos anteriormente (Cascata, Evolucionário, Formal e Reuso) possuem suas desvantagens. Normalmente, duas necessidades são observadas:

• Utilizar modelos diferentes para partes distintas.
• Repetir fases do processo.

A solução é a adoção de modelos híbridos e iterativos, como:

• Incremental: As fases de especificação, projeto e implementação são desdobradas em estágios.
• Espiral: Evolução a partir de um esboço, com foco em análise de risco.

O que é um Processo Iterativo?

A ideia é desenvolver a especificação em conjunto com o software. Isso minimiza o risco de frustração do processo de desenvolvimento, tanto para o desenvolvedor (custos) quanto para o cliente (prazo).

Qual é o problema?

O modelo de aquisição tradicional (como licitação) não é atendido, pois a especificação completa faz parte do contrato, gerando a necessidade de um novo tipo de contrato.

Modelo Incremental

Características do Incremental

• Abordagem híbrida que combina vantagens dos modelos Cascata e Evolucionário.
• Tem por objetivos reduzir o retrabalho e postergar decisões sobre requisitos até que se tenha alguma experiência com o sistema.

O Processo Incremental

1. Identificar em esboço as funções do sistema.
2. Priorizar as funções a serem entregues.
3. Definir estágios de entrega, especificando o que será entregue em cada estágio, de acordo com a prioridade.
4. As funções a serem entregues no primeiro incremento são detalhadas.
5. O incremento é desenvolvido com o processo mais apropriado.

Durante o desenvolvimento:

• Os requisitos para o próximo incremento são detalhados.
• Mudanças para o incremento em desenvolvimento não são aceitas.
• Ao término do incremento, o cliente utiliza o sistema.
• A experiência da utilização auxilia um melhor detalhamento dos próximos incrementos/versões.
• Funções comuns podem ser desenvolvidas no início ou sob demanda.
• Não há obrigatoriedade para um modelo específico de desenvolvimento do incremento:
  • Requisitos bem definidos: Modelo Cascata.
  • Requisitos não claros: Modelo Evolucionário.

Vantagens do Incremental

• O primeiro incremento atende aos requisitos mais importantes, otimizando o Retorno sobre o Investimento (ROI).
• Utilização dos primeiros incrementos como protótipo.
• Minimiza o risco de fracasso do sistema.
• A parte mais importante do sistema é testada várias vezes.

Desvantagens do Incremental

• Incremento relativamente pequeno.
• Dificuldade em mapear requisitos importantes para incrementos pequenos.
• Dificuldade de especificar funções comuns.

XP – eXtreme Programming (Desenvolvimento Incremental)

• Publicado por Beck, 1999.
• Incrementos muito pequenos.
• Envolvimento do cliente.
• Constante melhoria do código.
• Programação impessoal (referindo-se à propriedade coletiva ou programação em par).

RUP – Rational Unified Process

O RUP é mais do que um processo; é:

• Processo + Métodos + Linguagem (UML).
• Um framework para gerar processos.

Consiste em um conjunto de atividades:

• Bem definidas.
• Com responsáveis.
• Com artefatos de entrada e saída.
• Com dependências entre as mesmas e ordem de execução.
• Com modelo de ciclo de vida.
• Descrição sistemática de como devem ser realizadas.
• Guias (de ferramentas ou não) e templates.
• Utilizando diagramas de UML.

Modelo Espiral

Principais Diferenças do Modelo Espiral

Análise de Riscos:

• Especifica o objetivo, considera alternativas e suas restrições, identifica as causas dos riscos e, então, as avalia por atividades (prototipação, simulação, etc.).

Flexibilidade de Fases:

• Não há fases fixas como nos outros modelos.
• O modelo Espiral abrange os demais modelos.
• A prototipação pode ser utilizada para dúvidas nos requisitos.
• Após os requisitos bem definidos, o Cascata pode ser usado para desenvolver.
• Para requisitos rigorosos de segurança, pode-se aplicar a transformação formal.

Visão Geral do Rational Unified Process (RUP)

Definição do RUP

O nome é uma abreviação de Rational Unified Process, mas na verdade é:

• Processo + Métodos + Linguagem (UML).
• Um Framework para gerar processos.

O desenvolvimento de sistemas seguindo o RUP é:

• Iterativo e incremental.
• Guiado por Casos de Uso (Use Cases).
• Baseado na arquitetura do sistema.

Estrutura Estática do RUP

A estrutura estática define os elementos do processo:

• Fluxos de atividades.
• Atividades:
  • Passos.
  • Entradas e saídas.
  • Guias (de ferramentas ou não), templates.
• Responsáveis (papel e perfil, não pessoa).
• Artefatos.

Estrutura Dinâmica do RUP: Fases e Iterações

O ciclo de vida de um sistema consiste em quatro fases:

| Concepção | Elaboração | Construção | Transição |

• Concepção: Define o escopo do projeto.
• Elaboração: Detalha os requisitos e a arquitetura.
• Construção: Desenvolve o sistema.
• Transição: Implanta o sistema.

Cada fase é dividida em iterações, e cada iteração:

• É planejada.
• Realiza uma sequência de atividades distintas (de elicitação de requisitos, análise e projeto, implementação, etc.).
• Geralmente resulta em uma versão executável do sistema.
• É avaliada segundo critérios de sucesso previamente definidos.

Processo Guiado por Casos de Uso no RUP

Os casos de uso não servem apenas para definir os requisitos do sistema. Várias atividades do RUP são guiadas por eles:

• Planejamento das iterações.
• Criação e validação do modelo de projeto.
• Planejamento da integração do sistema.
• Definição dos casos de teste.

Resumo: O RUP é

• Iterativo e incremental.
• Guiado por casos de uso.
• Baseado na arquitetura do sistema.
• Organizado em fases, iterações, fluxos, atividades e passos.

Papel: Integrador

Os implementadores liberam os componentes testados em um espaço de trabalho de integração, enquanto os integradores combinam esses componentes para criar uma build (compilação/versão).

Um integrador também é responsável por planejar a integração, que ocorre no subsistema e no sistema, sendo que cada um tem um espaço de trabalho de integração separado. O fluxo é:

• Componentes testados são liberados do espaço de trabalho de desenvolvimento particular de um implementador para o espaço de trabalho de integração do subsistema.
• Subsistemas de implementação integrados são liberados do espaço de trabalho de integração do subsistema para o espaço de trabalho de integração do sistema.

Boas Práticas do eXtreme Programming (XP)

• Estórias de Usuário (User Stories).
• Iteração.
• Medida de velocidade do projeto.
• Jogo do Planejamento (Planning Game).
• Versões frequentes e pequenas.
• Reuniões rápidas (stand-up meeting).
• Simplicidade.
• Metáfora.
• Criar spike solutions para reduzir riscos (visual).
• O cliente sempre disponível.
• Pair Programming (Programação em Par).
• Propriedade coletiva do código.
• Padronização do código.
• 40 horas semanais.
• Integração contínua.
• Fazer refatoração (refactoring) sempre que possível.
• Testes unitários.