Modelos de Processos

Prof. Marcelo de Barros

Estrutura Atividades Fundamentais

1. Comunicação

2. Planejamento

3. Modelagem

4. Construção

5. Implantação

Especificação

Projeto/Implementação

Validação

Evolução

Conceito

◦ Representações abstratas de processos

◦ Determinada perspectiva do processo

Arquitetura

Atividades

Papéis

Fases (ciclo de vida)

Fornece informações parciais

◦ Podem ser ampliados e adaptados

É uma representação abstrata de um processo de software. Cada modelo, representa um processo sob determinada

perspectiva.

Principais modelos

◦ Cascata

◦ Evolucionário

◦ Componentes

◦ Iterativo

◦ Espiral

◦ Métodos Ágeis

Primeiro modelo de processo de desenvolvimento de software

As principais atividades são executadas em estrita sequência

◦ Processo rígido e burocrático:

Não permite erros

Atividades devem ser bem definidas

Atividades Fundamentais:◦ Análise de Requisitos

◦ Projeto de sistema e software

◦ Implementação e teste de unidade

◦ Integração e teste de sistema

◦ Operação e manutenção

Análise de Requisitos◦ Definição dos serviços, restrições e objetivos do sistema

◦ Especificação do sistema

Projeto de sistema e software◦ Divide os requisitos em sistemas de hardware ou de software

◦ Arquitetura geral do sistema

Implementação e teste de unidade◦ Projeto de software é realizado como um conjunto de programas ou

unidades de programa

Integração e teste de sistema◦ Unidades individuais do programa são integrados e testados como um

sistema completo

◦ Verificar atendimento dos requisitos

Operação e manutenção◦ Fase mais longa

◦ O sistema é instalado e colocado em operação

◦ Realizada a correção de erros não detectados

Representação:

Problemas:

1. Projetos reais raramente seguem o fluxo sequencial que o modelo propõe

2. Difícil para o cliente declarar todas as exigências de forma explícita

3. Iterações são onerosas (muitos gastos) e envolvem um retrabalho devido aos custos de produção e aprovação de documentos

4. Durante a fase final, erros e omissões nos requisitos originais são frequentemente descobertos

Só deve ser usado quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento

Baseia-se na ideia de desenvolvimento de uma implementação inicial◦ Expondo o resultado aos comentários do usuário e refletindo esse

resultado por meio de várias versões até que seja desenvolvido um sistema adequado

Atividades de especificação, desenvolvimento e validação são intercaladas

Vantagem:

◦ A especificação pode ser desenvolvida de forma incremental

◦ A medida que os usuários compreendem melhor seu problema, isso pode ser refletido no sistema de software

Desvantagens:

◦ O processo não é visível

◦ Os sistemas são frequentemente mal estruturados

◦ Não é viável manter documentação para cada versão

Representação:

Na maioria dos projetos, existe algum reuso de software

◦ Criação da abordagem orientada a reuso

◦ Dependente de:

Uma grande base de componentes de software que sejam reusáveis

Algum framework de integração desses componentes

Estágios:

◦ Especificação de requisitos

◦ Análise de componentes

◦ Modificação de requisitos

◦ Projeto de sistema com reuso

◦ Desenvolvimento e Integração

◦ Validação do sistema

O processo de Software não é de execução única

◦ Mudança é inevitável em todos os projetos de grande porte

◦ Requisitos mudam

◦ Quando novas tecnologias tornam-se disponíveis, projetos e implementações mudam

Solução:

◦ Desenvolvimento Iterativo

No processo iterativo, a especificação é desenvolvida conjuntamente com o software

◦ Não existe uma especificação completa de software até o incremento final seja especificado

◦ Dois modelos:

Entrega Incremental

Desenvolvimento Espiral

Abordagem intermediária entre o modelo cascata e o modelo evolucionário

Nele:

◦ O cliente identifica, em linhas gerais, os serviços a serem fornecidos pelo sistema (quais são mais importantes e quais são menos)

◦ Um número de incrementos de entrega é definido

◦ Após a identificação dos incrementos, os requisitos dos serviços a serem entregues no 1º incremento são definidos detalhadamente e ele é desenvolvido

Vantagens:

1. Clientes não precisam esperar até a entrega do sistema inteiro para se beneficiarem dele

2. Clientes podem usar os incrementos iniciais como protótipos e ganhar experiência

3. Existe risco menor de falha geral do projeto

4. Os serviços mais importantes recebem mais testes

Originalmente proposto por Boehm, em 1988

O processo é representado por um espiral

Cada loop na espiral representa uma fase do processo de software

◦ O loop mais interno por estar relacionado com à viabilidade do sistema;

◦ O próximo loop, à definição de requisitos;

◦ O próximo ao projeto de sistema e assim por diante.

Cada loop é dividido em 4 setores:

1. Definição de objetivos

2. Avaliação e redução de riscos

3. Desenvolvimento e validação

4. Planejamento

Diferença entre o Espiral e os outros modelos:

◦ Reconhecimento do risco

Modelo Espiral:

Cascata

Baseado em Componentes

Incremental

Espiral

Processo Unificado e RUP

XP (Extreme Programming)

SCRUM

FDD (Feature Driven Development)

Modelagem Ágil

DSDM, ASD, Crystal, ...

Modelo iterativo

Minimizar o risco pelo desenvolvimento de software em curtos períodos

Uma nova versão do software a cada iteração

◦ Reavaliar prioridades do projeto

“Ser ágil é ser eficiente, consequentemente pode-se ganhar tempo”

Os princípios do desenvolvimento ágil valorizam

1. Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;

3. Softwares funcionais são a principal medida de progresso do projeto;

5. Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;

6. Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.

8. Simplicidade;

9. Rápida adaptação às mudanças;

Manifesto ágil

1. Indivíduos e interações entre eles mais que processos e ferramentas

2. Software em funcionamento mais que documentação abrangente

3. Colaboração com o cliente mais que negociação de contratos

4. Responder a mudanças mais que seguir um plano

Críticas

◦ Falta de estrutura e documentação necessárias

◦ Somente trabalhar com desenvolvedores de nível sênior

◦ Incorpora de forma insuficiente o projeto de software

◦ Requer a adoção de muita mudança cultural

◦ Pode levar a maiores dificuldades nas negociações contratuais