Engenharia de Software - Aula 4 - Processos de Software Evolucionarios

Prévia do material em texto

Assuntos do dia
• Processos de Software
• Evolucionários
• Engenharia de Software: Abordagem sistemática, 
disciplinada e capaz de ser medida ao longo de um 
processo de construção de um software
Assuntos do dia
Obter Requisitos Obter Requisitos 
ElaborarElaborar ProjetoProjeto RápidoRápido
ConstruirConstruir ProtótipoProtótipo
Avaliar ProtótipoAvaliar Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
Modelos Evolucionários
• Como todo sistema 
complexo, software evolui
com o passar do tempo
• Requisitos do negócio e do 
produto mudam durante o 
• Necessidade por modelo de 
processo projetado para um 
produto que sempre evolui
• Em que uma versão reduzida 
pode ser elaborada face aos produto mudam durante o 
desenvolvimento
• Prazos reduzidos inviabilizam 
finalizar um software de 
grande porte
• Detalhes das extensões do 
produto ou do sistema ainda 
precisam ser melhor 
definidos
pode ser elaborada face aos 
prazos reduzidos de entrega
• Em que os requisitos básicos
de um produto ou sistema 
sejam bem entendidos
Modelos Evolucionários
• Modelos de processo iterativos que permitem 
desenvolver versões cada vez mais completas de 
um software
• Desenvolve-se uma implementação inicial, expondo-a 
aos comentários do usuário
• Depois, refina-se esse resultado por meio de várias 
versões até que seja desenvolvido um sistema 
adequado
Assuntos do dia
• Processos de Software
• Evolucionários
• Prototipagem• Prototipagem
• Modelo Espiral
Prototipagem
• O que é isso?
– Produto ainda não comercializado, mas em fase de testes
ou de planejamento. Pode ser um avião, automóvel, 
turbina, etc. geralmente testados antes em modelos turbina, etc. geralmente testados antes em modelos 
físicos, laboratórios ...
– É um sistema/modelo sem todos os elementos funcionais, 
mas apenas com as funcionalidades gráficas e algumas 
básicas. É utilizado para aprovação de quem solicita o 
software
Prototipagem
• Entendi, mas para quê?
– Entender os requisitos do usuário e, daí obter uma melhor 
definição dos requisitos do sistema
– Quando o cliente definiu objetivos gerais para o software, 
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
Plano RápidoPlano Rápido
– Quando o cliente definiu objetivos gerais para o software, 
mas ainda não os detalhou, ou quando os requisitos estão 
confusos
• Quando o engenheiro de software pode se sentir inseguro quanto 
à eficiência dos algoritmos, da adaptação a mudanças, da 
interação com hardware específico e outros softwares, etc.
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano Rápido
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano Rápido
COMUNICAÇÃOCOMUNICAÇÃO
� Desenvolvedor(es) e cliente(s) encontram-se para
� Definir objetivos gerais do software
� Identificar quais requisitos são bem compreendidosProjeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
� Identificar quais requisitos são bem compreendidos
� Identificar áreas que necessitam de mais definições
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano RápidoPLANO RÁPIDOPLANO RÁPIDO
� Estimativas e cronogramação rápidas
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
� Esforço de tempo
� Alocação de recursos humanos
� Análise de custo-benefício (compensa?)
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto RápidoPROJETO RÁPIDOPROJETO RÁPIDO
Plano RápidoPlano Rápido
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
PROJETO RÁPIDOPROJETO RÁPIDO
� Modelagem dos aspectos do software 
visíveis ao usuário
� Dados de entrada e saída
� Formatação de telas 
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano Rápido
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
CONSTRUÇÃO DO PROTÓTIPOCONSTRUÇÃO DO PROTÓTIPO
� Implementação rápida do projeto
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano Rápido
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do Protótipo
AVALIAÇÃO DO PROTÓTIPOAVALIAÇÃO DO PROTÓTIPO
� Cliente e desenvolvedor avaliam o protótipo
Prototipagem
ComunicaçãoComunicação
Projeto RápidoProjeto Rápido
Plano RápidoPlano Rápido
Projeto RápidoProjeto Rápido
Construção do ProtótipoConstrução do Protótipo
Avaliação do ProtótipoAvaliação do Protótipo
Refinamento do ProtótipoRefinamento do ProtótipoREFINAMENTO DO PROTÓTIPOREFINAMENTO DO PROTÓTIPO
� Cliente e desenvolvedor refinam os requisitos do 
software desenvolvidos (feedback)
� Pode gerar nova iteração
Plano RápidoPlano Rápido
ConstruçãoConstrução
do Produtodo Produto
Prototipagem
ComunicaçãoComunicação
ProjetoProjeto RápidoRápido
CONSTRUÇÃO DO PRODUTOCONSTRUÇÃO DO PRODUTO
� Identificados os requisitos, o protótipo PODE ou DEVE
ser descartado
�Muito lento, grande, complicado de usar, etc.ProjetoProjeto RápidoRápido
Construção doConstrução do ProtótipoProtótipo
Avaliação doAvaliação do ProtótipoProtótipo
RefinamentoRefinamento dodo ProtótipoProtótipo
�Muito lento, grande, complicado de usar, etc.
� Acertar (mesmo planejado) na 1ª vez não é fácil!
� A versão de produção deve ser construída 
considerando os critérios de qualidade acordados
Vantagens
• Usuários têm o “sabor” de um 
sistema real precocemente
• Desenvolvedores conseguem 
“entender” o sistema e construir 
Desvantagens
• Cliente "pensa” estar usando 
uma versão operacional
− Pode reclamar que o sistema 
ainda vai ser refeito com 
Prototipagem
“entender” o sistema e construir 
“algo” em prazo curto
ainda vai ser refeito com 
melhor qualidade 
− Pode exigir “consertos” para 
começar a usar o software
• Concessões equivocadas do 
desenvolvedor para entregar logo 
o protótipo (esquecer?!?)
− Algoritmo ineficiente, SO ou 
linguagem inapropriados
Conclusão
• Definir as “regras do jogo” no início
– Cliente e desenvolvedor devem estar de acordo 
• que o protótipo deve servir como mecanismo de • que o protótipo deve servir como mecanismo de 
definição de requisitos
• que o protótipo pode ser descartado (prototipação 
throwaway), ou apenas parte dele
• e que o software real será desenvolvido visando 
qualidade
Problemas da Prototipagem
• Falta de visibilidade de processo
– Inviabilidade econômica de se produzir documentação para cada 
versão desenvolvida rapidamente
– Falta de produtos regulares inviabilizam a medição do progresso do 
projetoprojeto
• Software freqüentemente mal estruturado
– Mudanças contínuas tendem a corromper a estrutura do software, 
tornando-a cada vez mais onerosa e difícil
• Habilidades especiais podem ser solicitadas
– Exemplos, linguagens para prototipação rápida (ex: Lua)
Quando usá-la?!?
• Sistemas interativosde pequeno/médio porte
– Mais fácil e rápido para estabelecer uma arquitetura
estável do sistema
• Sistemas de grande porte e longo ciclo de vida custam a 
estabelecer uma arquitetura estávelestabelecer uma arquitetura estável
• Em partes de um sistema de grande porte
– Por exemplo, a interface com o usuário
• Normalmente, é utilizada como técnica auxiliar em 
vez de modelo de processo independente
Leitura Projeto Casa Segura – pg. 44 – Roger Pressman
Assuntos do dia
• Processos de Software
• Evolucionários
•Prototipagem•Prototipagem
• Modelo Espiral
Modelo Espiral
• Processo representado como uma espiral e cada volta na 
espiral representa uma iteração
• Sem fases definidas (ex: comunicação, projeto) as voltas na espiral 
são escolhidas com base no que é requisitadosão escolhidas com base no que é requisitado
• Processo direcionado a riscos e planejamento
• Riscos são explicitamente avaliados e resolvidos ao longo do 
processo
• Um dos mais recentes e melhores processos iterativos e 
incrementais
Modelo Espiral
CUSTOCUSTO
INÍCIOINÍCIO
REVISÃOREVISÃO
Setores do modelo Espiral
• Definição de objetivos
– Objetivos específicos para a 
fase são identificados
• Avaliação e redução de 
• Desenvolvimento e 
validação
– Um modelo de 
desenvolvimento para o • Avaliação e redução de 
riscos
– Riscos são avaliados e 
atividades são realizadas para 
reduzir os riscos-chave
• Escolha de linguagem 
inadequada, que pode gerar 
atraso na entrega e aumento 
de custo
sistema é escolhido (qualquer 
um dos modelos genéricos 
apresentados)
• Planejamento
– O custo do projeto é revisitado 
e revisado e a próxima fase da 
espiral é planejada
Vantagens
� Riscos são gerenciados cedo e ao longo do processo –
reatividade a riscos, que são reduzidos antes de se tornarem 
problemáticos
Usa prototipação para reduzir riscos� Usa prototipação para reduzir riscos
� Software evolui enquanto o projeto prossegue –
erros/alternativas não atrativas são eliminadas cedo
� Planejamento é construído sobre o processo – cada ciclo 
inclui um passo de planejamento para auxiliar o monitoramento 
do projeto
Desvantagens
• Complicado de usar e controlar – análise de riscos 
requer experiência e, consequentemente, $$$
– Se um risco importante não for detectado ou bem 
gerenciado, ocorrerão problemas
• Pode ser inadequado para pequenos projetos –
Não faz sentido se o custo da análise de riscos é 
grande parte do custo do projeto como um todo
Quando usá-lo?
• Abordagem mais realista para sistemas de 
software de grande porte
• Equipe de projeto experiente em relação a 
planejamento e, principalmente, análise de riscos
RESUMO
• Modelo Linear/Cascata/Ciclo de vida clássico
• Modelo Incremental (3 visões)
• Modelo Evolucionário (Prototipação)
• Modelo Evolucionário (Espiral)
Leitura Recomendada
– Capítulo 2 e 3 do livro texto: Pressman, Roger. 
Engenharia de Software, 7ed. McGrawHill, 
Porto Alegre, RS, 2011.
– Capítulo 2 do livro texto: Sommerville, Ian. – Capítulo 2 do livro texto: Sommerville, Ian. 
Engenharia de Software, 9ed. Prentice Hall, 
São Paulo, SP, 2011.
– Capítulo 8: SWEBOK V3. Disponível em 
http://www.swebok.org/