3 Modelos de Processos de Software

Prévia do material em texto

Modelos de Processos de 
Software
Tópicos da aula
• Ordem x Caos
• Modelos de processo de software.
• Prescritivo
• Especializado
• RUP
• Lidando com mudanças.
Ordem x Caos
• Tendemos a pensar que a ordem é o estado ideal da natureza, mas 
não é bem assim
• Ordem = organização, equilíbrio e estrutura.
• Ambientes imprevisíveis regidos pela ordem são uma grande vantagem, pois 
a mudança ocorre quando há uma estrutura que a permita.
• O problema é quando a estrutura é tão rígida que impede que mudanças 
ocorram.
• Caos = criatividade
• Caos demais impossibilita a coordenação e a coerência.
• Falta de estrutura nem sempre implica em desordem.
O que é Modelo de Processo de Software?
• É uma representação simplificada de um processo de software.
• Além das atividades (metodológicas e de apoio), também 
representam os produtos (artefatos), os papéis e as pré e pós 
condições.
Tipos de modelo de processo
• Segundo Sommerville, temos os processos dirigidos a planos e os 
processos ágeis.
• Segundo Pressman, temos os modelos prescritivos, os modelos 
especializados, o processo unificado (RUP) e o modelo de processo 
pessoal e de equipe e os processos ágeis.
Modelos prescritivos
• Se concentram em estrutura e ordem.
• Defendem uma abordagem ordenada da engenharia de software.
• Modelos:
• Cascata / Modelo V
• Modelo Incremental
• Modelo evolucionário: prototipação
• Modelo evolucionário: espiral
• Modelo evolucionário: concorrente
Modelo Cascata
• Modelo dirigido a planos. 
• Fases de especificação e desenvolvimento separadas e distintas.
• Todo o planejamento do projeto deve ser feito antes que ele seja 
iniciado
• Tem dificuldade de acomodação de mudanças depois de iniciado
• Cada fase deve ser completada, antes de se iniciar outra
• Apropriado apenas para projetos cujos requisitos de software são 
estáveis, o que são bem raros no mercado
• O programa deve estar completo para ser entregue ao cliente
Modelo Cascata
Modelo V
• Variação do modelo 
cascata, onde, depois de 
terminada a geração de 
código, a equipe começa a 
realizar uma série de 
testes que garante a 
qualidade do que foi 
produzido no “lado 
esquerdo do V”.
Modelo Incremental
• Utilizado quando os requisitos iniciais são razoavelmente bem definidos e 
exige-se que o cliente tenha contato com um conjunto funcional do 
software para que ele, posteriormente, seja refinado e expandido.
• Combina o fluxo de processo linear com o paralelo.
• Produz softwares com funções básicas nos primeiros incrementos, para 
posteriormente trazer funções mais sofisticadas.
• O primeiro incremento é sempre o produto essencial, com a entrega dos requisitos 
básicos.
• O planejamento já considera a mudança do produto essencial, para melhor se 
adequar à necessidade do cliente e aos novos incrementos.
• É possível usar prototipação para cada novo incremento.
Modelo incremental
Modelos de processo evolucionário
• Ideais para projetos em que os requisitos mudam com frequência, os 
prazos apertados, a pressão comercial e da concorrência exigem 
entregas funcionais rápidas, mesmo que elas não estejam completas.
• Conjuntos ideias do sistema devem estar bem compreendidos e os 
detalhes podem ser definidos depois.
• São iterativos: a cada ciclo, uma versão mais evoluída do software.
• Desvantagem: priorizam a flexibilidade e a velocidade, às vezes, em 
detrimento da qualidade.
• Modelos mais comuns: prototipação e espiral.
Desfazendo a confusão incremental x 
evolucionário
Prototipação
• Usado quando o cliente tem uma série de objetivos gerais para o 
projeto, mas não identifica os requisitos para funções e recursos;
• Também usado quando o desenvolvedor está inseguro se é aquilo 
mesmo que o cliente quer.
• Embora possa ser usada como processo propriamente dito, é mais 
comum se usada combinada com outro processo (ex.: cascata, 
incremental, etc.)
• Depois de uma reunião para a coleta dos objetivos gerais, faz-se um 
protótipo que se detém nas partes visuais do sistema (layouts, 
interfaces, etc.) para que o cliente VEJA o sistema e tenha ideias mais 
precisas de como quer o software.
Prototipação
• Alguns protótipos podem ser feitos para serem descartáveis, mas 
outros podem ser feitos de maneira funcional para que possam servir 
como “primeiro programa” e, depois de refinados, venham a evoluir e 
se tornar o programa final.
• Os grandes problemas da prototipação são:
• Vendo o protótipo funcional, os clientes apressados não aceitam que um 
novo projeto deve ser realizado para a construção do software verdadeiro 
que atenda a padrões de qualidade e querem o protótipo com apenas 
algumas correções.
• Soluções ruins podem ser usadas nos protótipos apenas porque eram fáceis 
ou eram as disponíveis para uso rápido no momento, mas acabam sendo 
mantidas no projeto do software e diminuindo a qualidade do produto final.
Prototipação
Modelo espiral
• Combina a prototipação ao modelo cascata.
• É orientado a riscos.
• Pode ser adaptado para ser usado durante a construção do software e 
também durante a manutenção dele.
• Marcos e pontos-âncora são representados por artefatos ou condições 
satisfeitas.
• O primeiro passeio pela espiral pode resultar no desenvolvimento da 
especificação do produto, o segundo, pode resultar no protótipo e cada 
passeio seguinte vai evoluindo ainda mais o software.
• Cada passagem pela região do planejamento, exige re-planejamento de 
cronograma e custos, que são ajustados conforme feedback do cliente.
Modelo espiral
Modelos concorrentes
• Todas as atividades da engenharia de software estão ocorrendo 
simultaneamente, porém em diferentes estados.
• O gatilho de mudança de estados das atividades são alguns eventos 
definidos pela modelagem concorrente. 
• Exemplo: durante os estágios iniciais do projeto (uma ação de engenharia de 
software importante que ocorre durante a atividade de modelagem), uma 
inconsistência no modelo de requisitos não é descoberta. Isso gera o evento 
correção do modelo de análise, que vai disparar a ação de análise de requisitos, 
passando do estado concluído para o estado aguardando modificações.
• Modelo adequado para projetos que possuem diferentes equipes de 
desenvolvimento de software.
• Fornece uma imagem precisa do atual estado do projeto.
Modelos concorrentes
Modelos especializados
• COTS (baseado em componentes)
• Se baseia na aplicação de componentes previamente empacotados
• Se parece com o espiral
• Modelagem e construção começam com a identificação de componentes 
candidatos
• Modelos formais
• Baseiam a especificação, o desenvolvimento e a validação em notações 
matemáticas rigorosas
• Ambiguidades, incompletude e inconsistências podem ser descobertas mais 
facilmente com análise matemática, por isso é ideal para a construção de 
sistemas críticos.
• É muito complexo, além de consumir muito tempo e dinheiro.
Modelos especializados
• Orientado a aspectos
• As preocupações dos clientes em relação a aspectos (segurança, tolerância a 
falhas, etc.) são mais importantes que as funções, recursos e conteúdo
• Funciona nos moldes dos modelos concorrentes
Processo Unificado (RUP)
• Processo da UML, “dirigido a casos de uso, centrado na arquitetura, 
iterativo e incremental”.
• Tenta aproveitar os melhores recursos dos modelos tradicionais 
(prescritivos), mas também tenta implementar os melhores princípios 
do desenvolvimento ágil.
• Reconhece a importância da comunicação com o cliente, usando 
método dos casos de uso (escrito na visão do próprio cliente)
• Enfatiza a importância da arquitetura de software com foco na 
compreensibilidade, confiança em mudanças futuras e reutilização.• Sugere o fluxo de processo incremental
Fases do RUP
• Concepção
✓Estabelece o business case para o sistema.
• Elaboração
✓Desenvolve um entendimento da extensão do problema e da arquitetura do sistema.
• Construção
✓Projeta o sistema, programa e testa o sistema.
• Transição
✓ Implanta o sistema no seu ambiente de operação.
Processo Unificado
Workflow do RUP
Workflow do RUP
Boas práticas do RUP
• Desenvolver software iterativamente
✓ Planejar incrementos baseando-se nas prioridades do cliente e entregar as de prioridade
mais alta primeiro.
• Gerenciar os requisitos
✓ Documentar explicitamente os requisitos do cliente e manter registros de mudanças desses
requisitos.
• Usar arquiteturas baseadas em componentes
✓ Organizar a arquitetura do sistema como um conjunto de componentes reusáveis.
Boas práticas do RUP
• Modelar o software visualmente
✓ Use modelos de gráficos UML para representar visões dinâmicas e estáticas do software.
• Verificar a qualidade do software
✓ Garanta que o software atenda aos padrões de qualidade organizacional.
• Controlar as mudanças do software
✓ Gerencie as mudanças no software usando um sistema de gerenciamento de mudanças e
ferramentas de gerenciamento de configuração.
Lidando com mudanças
• Existem duas abordagens que podem ser adotadas para a redução de 
custos de retrabalho:
1. Prevenção de mudanças, em que o processo de software inclui atividades capazes 
de antecipar as mudanças possíveis antes que seja necessário qualquer retrabalho. Por 
exemplo, um protótipo de sistema pode ser desenvolvido para mostrar algumas 
características-chave do sistema para os clientes. Eles podem experimentar o protótipo 
e refinar seus requisitos antes de se comprometer com elevados custos de produção 
de software.
2. Tolerância a mudanças, em que o processo foi projetado para que as mudanças 
possam ser acomodadas a um custo relativamente baixo. Isso normalmente envolve 
alguma forma de desenvolvimento incrementai. As alterações propostas podem ser 
aplicadas em incrementos que ainda não foram desenvolvidos. Se isso for impossível, 
então apenas um incremento (uma pequena parte do sistema) deve ser alterado para 
incorporaras mudanças.