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
Top Related