O documento apresenta e descreve os principais modelos de processos de desenvolvimento de software, incluindo o modelo em cascata, evolucionário, de desenvolvimento incremental, espiral e prototipação. Destaca as definições, características, vantagens e desvantagens de cada modelo, além de compará-los e discutir a importância da abordagem ágil.

1. Engenharia de Software
Unidade II – Processos de Software
Objetivo: Apresentar os principais paradigmas e modelos
de processos de software, demonstrando o ciclo de vida do
desenvolvimento de software e enfatizando os processos
de especificação de requisitos, projeto, implementação,
testes e mudanças
Prof. Nécio de Lima Veras

2. Processos de Desenvolvimento de
Software
 Vimos anteriormente que os processos definem uma
estrutura, que consiste em áreas de processos chave.
 Percebemos também que Sommerville subdivide em quatro
atividades básicas:
 Especificação;
 Desenvolvimento;
 Validação; e
 Evolução.
 Partindo disso, muitos modelos já foram
propostos...

3. Roteiro...
 Então para esta aula, veremos:
 Definições de processos e modelos de
processos de software;
 Alguns modelos existentes:
 Cascata;
 Evolucionário;
 Desenvolvimento incremental;
 Espiral; e
 Prototipação.

4. Definições
 Processo de software:
 “É uma seqüência coerente de práticas que objetiva o
desenvolvimento ou evolução de sistemas de
software. Estas práticas englobam as atividades de
especificação, projeto, implementação, testes e
caracterizam-se pela interação de ferramentas,
pessoas e métodos”.
 Modelo de processo de software:
 “Um modelo de processo de software é uma
representação abstrata de um processo. Ele
apresenta uma descrição de um processo a partir de
uma perspectiva específica”.

5. O Modelo em Cascata
 Primeiro modelo publicado do processo de
desenvolvimento de software;
 Originou-se de outros processos de
engenharia;
 Retrata um desenvolvimento gradual e possui
seqüência de passos em ordem que devem
ser seguidos.
 Pode consumir um
tempo estimado entre
seis e dezoito meses;

6. O Modelo em Cascata:
Principais Estágios
 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.

7. O Modelo em Cascata:
Principais Estágios
 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.

8. O Modelo em Cascata:
Principais Estágios
 Implementação e Testes de
Unidade: Durante este
estágio, 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.

9. O Modelo em Cascata:
Principais Estágios
 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.

10. O Modelo em Cascata:
Principais Estágios
 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

11. O Modelo em Cascata: Problemas
 Particionamento inflexível do projeto em
fases distintas;
 Isso torna difícil responder a requisitos do
usuário que mudam;
 Portanto, esse modelo é apropriado somente
quando os requisitos são bem
compreendidos;

12. O modelo Evolucionário
 Tem com base a ideia de desenvolver uma implementação
inicial, expor o resultado ao comentário do usuário e fazer
seu aprimoramento por meio de muitas versões, até que
tenha sido desenvolvido;
 A especificação, desenvolvimento e validação são
executados concorrentemente para gerar um retorno
rápido;

13. O modelo Evolucionário
 Pode ser:
 Exploratório: tem como objetivo trabalhar
com o cliente a fim de explorar seus requisitos
e entregar um sistema final. São feitas partes
inicias e acrescentadas novas de acordo com
o desenvolvimento.
 Protótipos descartáveis: tenta compreender
os melhor os requisitos a partir de protótipos e
então desenvolver uma especificação de
requisitos completa.

14. O modelo Evolucionário
 Problemas:
 O processo não é visível: como o sistema é
desenvolvido rapidamente, não há tempo de
documentar as versões;
 Os sistemas são mal-estruturados: mudanças
constantes podem corromper a estrutura do
software;
 Requer ferramentas e técnicas especiais: que
nem sempre são disponíveis ou são
aplicáveis ao caso.

15. O modelo Evolucionário
 Aplicabilidade:
 Para sistemas interativos pequenos ou de
médio porte
 Para partes de sistemas grandes (p.ex., a
interface com o usuário)
 Para sistemas de vida curta.

16. O modelo Desenvolvimento
Incremental
 É uma variação do modelo Cascata;

17. O modelo Desenvolvimento
Incremental
 A ideia é alargar pouco-a-pouco;
 Analogia à construção de uma mansão;

18. O modelo Desenvolvimento
Incremental
 Vantagens:
 Redução dos riscos envolvendo custos a um único incremento.
 Redução do risco de lançar o projeto no mercado fora da data
planejada. Identificando os riscos numa fase inicial o esforço
despendido para gerenciá-los ocorre cedo, quando as pessoas
estão sob menos pressão do que numa fase final de projeto.
 Aceleração do tempo de desenvolvimento do projeto como um
todo, porque os desenvolvedores trabalham de maneira mais
eficiente quando buscam resultados de escopo pequeno e claro.
 Reconhecimento de uma realidade freqüentemente ignorada: as
necessidades dos usuários e os requisitos correspondentes não
podem ser totalmente definidos no início do processo.
 Este modelo de operação facilita a adaptação a mudanças de
requisitos.

19. O modelo Desenvolvimento
Incremental
 Desvantagens:
 Dificuldade de gerenciamento. Isso ocorre porque as fases de do
ciclo podem estar ocorrendo de forma simultânea.
 O usuário pode se entusiasmar excessivamente com a primeira
versão do sistema e pensar que tal versão já corresponde ao
sistema como um todo.
 Como todo modelo esta sujeito a riscos de projeto:
 O projeto pode não satisfazer aos requisitos do usuário.
 A verba do projeto pode acabar.
 O sistema de software pode não ser adaptável, manutenível ou
extensível.
 O sistema de software pode ser entregue ao usuário tarde
demais.

20. O modelo Espiral
 O processo é representado como uma espiral, em vez de
uma seqüê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
 Os riscos são explicitamente avaliados e resolvidos
durante todo o processo
 Para cada iteração temos:
 Envolvimento do cliente;
 Seis e vinte e quatro meses de duração
(presumidamente);
 Prazo suficiente para que o cliente tenha um brainstorm;

21. O modelo Espiral

22. O modelo Espiral: Setores
 Definição do objetivo
 Identificam-se os objetivos específicos da fase
 Avaliação e redução de risco
 Os riscos são avaliados e são adotadas as atividades para
reduzir os ricos principais
 Desenvolvimento e avaliação
 É escolhido um modelo de desenvolvimento para o
sistema, que pode ser qualquer um dos modelos
genéricos
 Planejamento
 O projeto é revisado e a próxima fase da espiral é
planejada

23. O modelo Prototipação
 Busca, principalmente, velocidade no
desenvolvimento;
 O cliente “enxerga” telas e relatórios resultantes do
software, com os quais ele terá alguma pequena
interação.
 O usuário deve ser envolvido para opinar sobre as
telas e relatórios do software, de maneira que se
consiga torná-lo quase que co-autor do
desenvolvimento responsabilizando-o também, desta
forma, pelo sucesso final do software, uma vez que
terá tido participação ativa na montagem do mesmo.

24. O modelo Prototipação
Análise de Desenvolvimento
Experimentação
Requisitos de Protótipo
Revisão
Codificação e
Detalhamento
Testes
Manutenção Implantação

25. O modelo Prototipação
 Perigos:
 Cliente “empolgar-se”;
 Pressão a fim de que concessões de
implementações ocorram para a urgência da
implantação, sugerindo-se que o protótipo
seja evoluído e entre rapidamente em
funcionamento.

26. Interseção entre os modelo?
 Longo período de tempo para o desenvolvimento;
 Volume muito grande de documentação e planejamento;
 Fases maiores ainda => Big Design Up Front (BDUF);
 Um software BDUF implica em:
 O planejamento é completado e aperfeiçoado antes
mesmo de iniciar a codificação, o que praticamente
inviabiliza uma mudança brusca de escopo [Fox e
Patterson 2012].
 E agora, para onde vamos?

27. Agilidade
 Um grupo em fevereiro de 2001, chamado de Agile Alliance,
começou a descobrir maneiras melhores e mais leves de
desenvolver software valorizando:
 pessoas e interações ao invés de processos e ferramentas;
 softwares funcionando no lugar de documentações
abrangentes;
 colaborações com clientes do que negociações de contratos
e respostas à mudanças por planos fechados.
 Esses valores originaram o Manifesto Ágil com outros
DOZE princípios que regem a filosofia de criar softwares com
agilidade [BECK, 2001]

28. Agilidade
 O modelo é baseado em mudanças
abrangentes;
 O desenvolvedor deve melhorar continuamente
um protótipo incompleto até que o cliente fique feliz com
o resultado;
 Algumas práticas são enfatizadas:
 Test-Driven Development (TDD);
 User Stories; e
 Velocity.

29. Contraste com os outros
modelos
É tão rápido que novas versões são
disponibilizadas ao cliente a cada duas
semanas e novos recursos são adicionados
continuamente ao mesmo protótipo até que o
cliente esteja satisfeito [Fox e Patterson 2012].

30. Exercícios

31. Referências
 Beck, K., et al. (2001). "Manifesto for Agile Software
Development". Agile Alliance. http://agilemanifesto.org/.
Acessado em 18 de agosto de 2012.
 Fox, A., Patterson, D. (2012). “Engineering Long-Lasting
Software: An Agile Approach Using SaaS and Cloud
Computing”, Alpha Edition. Strawberry Canyon LLC, 2012.
 Pressman, R. S. (2005). “Software engineering: a
practitioner‟s approach”, 6 ed. New York:
MacGraw-Hill, 2005.