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