MODELOS DE PROCESSO DE SOFTWARE
Introdução• Processos de software podem ser melhorados através da
padronização dos processos utilizados dentro de uma organização
• A modelagem de processos torna-se essencial para a definição de processos eficientes, capazes de serem replicados
• Modelagem de processos inclui responder as seguintes perguntas:– O quê?– Como?– Quem?– Quando?– Por quê?
Modelos de Processo de Software• São representações abstratas de um processo de
software– das atividades, papéis e artefatos
• Cada modelo representa um processo a partir de uma perspectiva particular
• Não são descrições definitivas de processo de software, mas sim abstrações úteis, que podem ser usadas para explicar diferentes abordagens de desenvolvimento de software
Modelos de Processo de Software• Descrição simplificada do processo
• Definem as atividades para o desenvolvimento do software
• Especificam os produtos de cada atividade
• Indicam os papéis das pessoas envolvidas
Modelos de Processo de Software• Deve ser escolhido com base:
– Na natureza do projeto e da aplicação
– Nos métodos e ferramentas a serem utilizados
– Nos controles e produtos que precisam ser entregues
Modelos de Processo de SoftwaresVantagens
• Oferecem um roteiro útil para o trabalho de engenharia de software
• Mas, nenhum modelo de processo é perfeito
• Outras vantagens– Padronização dos artefatos– Melhor comunicação da equipe– Menos treinamento de pessoal
Método x Processo de Software
• Um método (ou modelo de processo) é algoteórico, um conjunto de possíveis ações –conteúdo do método.
– Define o que, como e porque fazer
7
Método x Processo de Software
• O processo deve determinar ações práticasa serem realizadas pela equipe como prazosdefinidos e métricas para se avaliar comoelas estão sendo realizadas.
– Define quem e quando fazer.
8
O Modelo em “Cascata”
• Também conhecido como:– Clássico– Waterfall– Sequencial Linear
• Primeiro modelo publicado do processo de desenvolvimento de software (Royce, 1970)
O Modelo em “Cascata”
O Modelo em “Cascata”
• Originou-se de outros processos de engenharia
• Derivado do mundo do hardware (linhas de montagens)
• Retrata um desenvolvimento gradual
• Sua estrutura é composta por várias etapas que são executadas de forma sistemática e sequencial
O Modelo em “Cascata”
• Cada fase resulta em um ou mais documentos que deve ser aprovado
• O resultado de uma fase se constitui na entrada da outra
• O desenvolvimento de um estágio deve terminar antes do próximo começar
O Modelo em “Cascata”
13
O Modelo em “Cascata”
O Modelo em “Cascata”
O Modelo em “Cascata”
PRESSMAN X SOMMERVILLEO Modelo em “Cascata”
“Cascata” by Pressman
“Cascata” by Pressman– Comunicação
• Levantamento de Requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido.
“Cascata” by Pressman– Modelagem
Análise: tem por objetivo construir modelos que determinam qual é o problema para o qual estamos tentando conceber uma solução de software.
“Cascata” by Pressman– Modelagem
Projeto: O modelo de análise terá de ser adaptado de tal modo que possa servir como base para implementação no ambiente alvo
Traduz os requisitos em um conjunto de representações que podem ser avaliadas quando à qualidade.
É avaliado antes de começar a ser implementado Junto com as etapas anteriores torna-se parte da
documentação do sistema.
“Cascata” by Pressman – Construção
Codificação: a implementação do sistema é efetivamente executada.
Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador e implementado num ambiente de trabalho.
Projeto traduzido para a linguagem do computador
“Cascata” by Pressman – Construção
Teste: consiste na verificação do software. Concentra-se nos aspectos funcionais externos e lógicos
internos do software. Garante que “todas as instruções” tenham sido testadas. A entrada definida produz os resultados exigidos?
“Cascata” by Pressman - Implantação Entrada em produção do sistema
Manutenção: provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente
Causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho
“Cascata” by Sommerville
“Cascata” by Sommerville
• Análise e Definição de Requisitos– As funções, as restrições e os
objetivos do sistema são estabelecidos por meio de consulta aos usuários do sistema.
– Em seguida, são definidos em detalhes e servem como uma especificação do sistema.
“Cascata” by Sommerville
• Projeto de Sistemas e Software – O processo de projeto de
sistemas agrupa os requisitos em sistemas de hardware e software.
– Envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações.
“Cascata” by Sommerville
• Implementação e Testes de Unidade– O projeto do software é
compreendido como um conjunto de programas ou unidades de programa.
– O teste de unidade envolve verificar se cada uma das unidades atendem à sua especificação.
“Cascata” by Sommerville
• Integração e Teste de sistemas– As unidades de programa ou
programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos.
– Depois do teste, o software é entregue ao cliente.
“Cascata” by Sommerville
• Operação e manutenção– O sistema é instalado e
colocado em operação.– Envolve corrigir erros que
não foram descobertos em estágios anteriores, melhorando a implemen-tação e descobrindo novos requisitos
“Cascata” by Sommerville
• Existe uma interação entre as etapas
• Cada etapa pode levar a modificações nas etapas anteriores
• As vezes o processo atrasa e necessita de uma suspensão dos requisitos
O Modelo em “Cascata” na prática
• Demandam requisitos bem especificados
• Recomendado para projetos maiores de sistemas
O Modelo em “Cascata” na prática
O Modelo em “Cascata” na prática
Fases bem definidas
Pode ser utilizado quando os requisitos são bem conhecidos e razoavelmente estáveis
Recomendado para projetos de sistemas de grande porte
Documentação rígida (idealmente completa) em cada atividade
O Modelo em “Cascata”Vantagens
Reflete abordagens adotadas em outras engenharias
Aderência a outros modelos de processo
Pode ser combinado a outros modelos
Base para os outros
O Modelo em “Cascata”Vantagens
O Modelo em “Cascata”Desvantagens
O Modelo em “Cascata”Desvantagens
Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural. Em geral, é difícil para o cliente identificar todas as suas necessidades a prori
É difícil para o cliente declarar todas as exigências explicitamente. É difícil acomodar as incertezas naturais que existem no começo de muitos projetos.
Uma versão executável do software só fica disponível próximo ao fim do projeto, numa etapa avançada do desenvolvimento
O Modelo em “Cascata”Desvantagens
Projetos reais raramente seguem o fluxo sequencial que o modelo propõe
Dificuldade de acomodar as mudanças após o processo ter sido iniciado
Particionamento inflexível do projeto em fases distintas
Dificuldade de responder a requisitos do usuário que mudam
O Modelo em “Cascata”Desvantagens
Difícil identificação de sistemas legados (não acomoda a engenharia reversa)
Dificulta o gerenciamento de ricos
Mudanças invitáveis de requisitos podem causar confusões
Desenvolvedores ociosos
Portanto, esse modelo mais apropriado quando os requisitos são bem compreendidos
O Modelo em “Cascata” - Resumo• Um dos primeiros modelos
• O mais antigo e amplamente usado
• Derivado de modelos existentes em outras engenharias
• Desenvolvimento gradual
• Fases separadas e distintas de especificação e desenvolvimento
• Possui uma sequência de passos na ordem em que devem ser seguidos
O Modelo em “Cascata” - Resumo• Existe uma consequência nas fases
• Simples, mas não reflete, efetivamente, o modo como o código é desenvolvido
• Requer uma abordagem sistemática, sequencial ao desenvolvimento de software
• Modelado em função do ciclo da engenharia convencional
O Modelo em “Cascata” – Quando aplicar?
• Sistemas críticos
• Quando os requisitos são bem compreendidos
• Quando há pouca probabilidade dos requisitos mudarem
O Modelo em “Cascata” - Importância
• Trouxe contribuições importantes para o processo de desenvolvimento de SW:– Imposição de disciplina, planejamento e
gerenciamento – A implementação do produto deve ser postergada
até que os objetivos tenham sido completamente entendidos
– Permite gerência do baseline, que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento
Modelo V Variação do Cascata Descreve o paralelismo entre as atividades de
desenvolvimento e teste de software
Modelagem de requisitos
Teste deaceitação
Projeto daarquitetura
Teste dosistema
Projeto doscomponentes
Teste deintegração
Codificação Teste deUnidades
Modelo V
Modelos Incrementais
Modelos Incrementais Aplicam sequências lineares, de forma iterativa, à medida que o
tempo avança
Cada sequência linear (cascata) gera “incrementos” (entregáveis) do software
Seu foco consiste na entrega de um produto operacional a cada incremento
Atividades são intercaladas
Objetivo: dar feedback rápido ao cliente
Modelos Incrementais
Modelos Incrementais
Modelos Iterativos
Modelos Incrementais - Vantagens Custo reduzido de acomodar mudanças de requisito Facilita o feedback do cliente Todo incremento gera uma entrega Problemas complexos não são resolvidos de uma
única vez Sequência de builds (versões funcionais)
Maior controle sobre custos e riscos Melhor gerência da instabilidade da equipe
Modelos Incrementais - Desvantagens
Processo não é visível
A estrutura do sistema tende a degradar com a adição dos novos incrementos (exige refatoração)
O processo pode não ser muito claro
A gerência do software é complicada
Modelos Incrementais - Desvantagens
O sistema não é completamente especificado à priori
O produto final é frequentemente mal estruturado
A mudança contínua tende a corromper a modularidade do sistema
Os problemas do desenvolvimento incremental se tornam mais graves em sistemas críticos
Modelos Evolucionários Modelos iterativos com características que
possibilitam desenvolver versões cada vez mais complexas do software.
Obs: Os modelos incrementais e evolucionários são iterativos. A diferença entre os modelos incrementais e evolucionários é que os incrementais tem por objetivo apresentar um produto operacional a cada incremento.
Modelos EvolucionáriosBase:
Desenvolver uma implementação inicial Expor resultado ao comentário do usuário Aprimoramento por meio de muitas versões
São modelos evolucionários: Prototipação Espiral Desenvolvimento Concorrente
Modelos Evolucionários - Tipos• Desenvolvimento exploratório– O objetivo é trabalhar com os clientes e evoluir um sistema
final a partir de uma especificação genérica inicial. – O desenvolvimento se inicia com as partes do sistema que
estão compreendidas.
• Fazer protótipos descartáveis– O objetivo é compreender os requisitos do sistema. – O protótipo se concentra em fazer experimentos com
partes dos requisitos que estejam mal compreendidas
Desenvolvimento Evolucionário [Sommerville]
Desenvolvimento Evolucionário• Problemas– Falta de visibilidade do processo– Os sistemas frequentemente possuem pouca estrutura– Podem ser exigidas habilidades especiais
• Ex.: Em linguagens para desenvolvimento rápido
• Aplicabilidade– Para sistemas interativos pequenos ou de médio porte– Para partes de sistemas grandes
• Ex.: a interface com o usuário– Para sistemas de vida curta
Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos.
O protótipo serve como um mecanismo para a identificação dos requisitos de sw Tipos de protótipos:
Exploratório: É descartadoquando fica pronto, também chamado de protótipopara descarte. Evolutivo: Gradualmente evolui para se tornar um sistema real.
Comunicação(Início)
PlanoRápido
Modelagem Projeto Rápido
Construção do Protótipo
ImplantaçãoEntrega eFeedback
Prototipação
Desvantagens: Os interessados enxergam o protótipo como um software operacional. O engenheiro de software se compromete a colocar o software em produção rapida-mente comprometendo a qualidade final do software.
Comunicação(Início)
PlanoRápido
Modelagem Projeto Rápido
Construção do Protótipo
ImplantaçãoEntrega eFeedback
Prototipação
APROPRIADO QUANDO
O cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes
O desenvolvedor não tem certeza da eficiência de um algoritmo, forma da interação homem/máquina
Prototipação
Prototipação• Permite o refinamento iterativo dos requisitos
• A cada iteração é produzido um protótipo do software final
• Este protótipo pode ser um:
–Protótipo em Papel: primeiras versões que permitem ao usuário ter uma visão abstrata do sistema;
–Protótipo incompleto: implementa algum subconjunto de funções exigidas;
–Protótipo final: um software que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas e ainda não pode ser disponibilizado.
InicioFim
Coleta e Refinamento dos requisitos Projeto
Rápido
Construçãodo Protótipo
Avaliação do Protótipo pelo Cliente
Refinamento do Protótipo
Engenharia do Produto
Decide
Prototipação
Prototipação• Coleta e Refinamento dos Requisitos
–O desenvolvedor e o cliente devem•Definir os objetivos gerais do software(Protótipo)•Identificar quais requisitos são conhecidos e as áreas
que necessitam de definição adicional–Análise de Sistema
• Projeto Rápido–Representação dos aspectos do software que são visíveis
ao usuário (abordagens de entrada e formatos de saída)
Prototipação
• Construção do Protótipo–Implementação rápida do Projeto
• Avaliação do Protótipo–Cliente e desenvolvedor avaliam o protótipo
–No caso de sugestão ou mudanças serão trabalhá-das na próxima fase
Prototipação• Refinamento do Protótipo
–São trabalhados os problemas encontrados na fase anterior. Ou seja, são refinados os requisitos.
–Neste ponto pode ocorrer, no caso de necessidade de alterações, um retorno na fase de projeto Rápido para desenvolver um novo protótipo que incorpora as mudanças.
• Construção do Produto–Identificado todos os requisitos necessários, o protótipo
pode ser descartado e a versão final do produto deve ser construída considerando os critérios de qualidade.
PrototipaçãoProblemas• O cliente muitas vezes não aceita mais uma iteração, aquela
versão mesmo incompleta já serve.• Não há necessidade de desenvolver uma versão final, modifica-
se o protótipo.• O desenvolvedor frequentemente faz uma implementação
comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo.
Solução• Definir as regras do jogo logo no começo, o cliente deve
concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos
Modelo em Espiral Proposto por Boehm em 1988
Combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo em cascata
O software é desenvolvido numa série de versões evolucionárias
As primeiras iterações podem gerar modelos em papel ou protótipos
Modelo em Espiral
Exige a consideração direta dos riscos técnicos em todos os estágios do projeto
Pode ser adaptado para aplicação ao longo da vida do software
Modelo em Espiral• É um modelo incremental
• Combina elementos do modelo cascata (aplicado repetidamente) com a filosofia iterativa da prototipação.
• Acrescenta mais uma atividade: Análise de Risco
• O objetivo é trabalhar junto do usuário para descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido
Modelo em Espiral
• O processo é representado como uma espiral, em vez de uma sequência de atividades com caminhos de retorno
• Cada volta na espiral representa uma fase no processo
• Não há fases fixas, tais como especificação ou projeto– As voltas na espiral são escolhidas dependendo do que for
exigido
Modelo em Espiral
• O desenvolvimento começa com as partes do produto que são mais bem entendidas
• A evolução acontece quando novas características são adicionadas à medida que são sugeridas pelo usuário
• A cada iteração é desenvolvido uma versão usável, não um protótipo
Modelo em Espiral
decisão de continuar ou não
na direção de um sistema concluído
avaliação do cliente engenharia
análise dos riscosplanejamento
Modelo em Espiral
• Fornece o potencial para desenvolvimento rápido de versões incrementais do software
• Nas primeiras iterações são desenvolvido versões que podem ser protótipos
• Nas iterações mais adiantadas são produzido versões incrementais mais completas e melhoradas
Modelo em Espiral1- PLANEJAMENTO:
–determinação dos objetivos, alternativas e restrições;–Comunicação com os clientes;–Definição de Recursos.
2- ANÁLISE DE RISCO: –análise das alternativas e identificação / resolução dos
riscos
Modelo em Espiral3- CONSTRUÇÃO:
–desenvolvimento do produto no nível seguinte;–Constrói protótipos ou versões mais avançadas do produto.–Realiza Testes, implantação, suporte.
4- AVALIAÇÃO DO CLIENTE: –Obter um feedBack do cliente baseado na avaliação da
versão do software.–São levantado as necessidades de mudança para o software
Modelo em Espiral - Vantagens• Abordagem realística para o desenvolvimento de
software em grande escala
• Capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva
• Os riscos são explicitamente avaliados e resolvidos durante todo o processo
• Mantém o enfoque sistemático do ciclo clássico
Modelo em Espiral - Desvantagens
• Pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável
• Requer boa capacidade para Análise de Riscos– Exige considerável experiência na determinação
de riscos e depende dessa experiência para ter sucesso
Espiral Análise dos RiscosPlanejamento
Avaliação do Cliente Engenharia
Espiral (Boehm)
Espiral (Pressman)
Espiral (Pressman)
Espiral - Resumo
• Iterativo • Maior custo• Muitos estágios intermediários
Top Related