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.
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;
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].
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.