Processos de Software
MATA62 - Engenharia de Software I
Universidade Federal da Bahia
Prof. Rodrigo Rocha
2016.1
Crise do software (1968)
- É difícil escrever software de qualidade com tempo aceitável
- Melhores computadores => problemas mais complexos
- Conferência da OTAN, 1968
- Precisamos de melhores processos, baseados na engenharia
- Deu origem ao termo "engenharia de software"
A natureza do software
- Software não é fabricado
- O software não se desgasta com o tempo
- no entanto, ele envelhece!
- Muito software é criado sob encomenda
- Software é flexível
- Software é caracterizado por
- mudança contínua
- prazos apertados
- necessidade de satisfação do usuário
Processo de software
"Um arcabouço para as atividades, ações e tarefas necessárias para construir software de alta qualidade"
(Pressman)
"Conjunto de atividades relacionadas que levam à produção de um produto de software"
(Sommerville)
Atividades
fundamentais
- especificação/análise
- projeto (design) e implementação
- verificação e validação
- evolução/manutenção
Atividades de suporte
- documentação
- gerenciamento de configuração
- ...
Modelo
de processo
de software
Representação abstrata do processo,
descrição (simplificada) do processo
relacionado: modelo de ciclo de vida de software
Modelo de processo
- atividades
-
produtos (artefatos)
- resultados das atividades
- ex.: documentos, código-fonte...
-
papéis (stakeholders)
- ex.: gerente de projetos, programador...
-
pré/pós-condições
- ex.: cliente aprova requisitos antes de começar o design
Não existe processo ideal
- Depende do software e da organização
- Sistemas críticos => processo mais estruturado
- Sistemas comerciais => processo mais flexível
Cascata (Waterfall)
Requisitos
Projeto
Implementação
Verificação
Manutenção
Cascata
- Royce, 1970
- Orientado a planejamento
- Fases sequenciais
- Cada fase gera documentos que precisam ser aprovados
- Similar ao processo usado em outras engenharias
Cascata: vantagens
- Documentação extensa:
- o conhecimento se preserva mesmo com rotatividade da equipe
- os gerentes têm maior visibilidade do processo
-
Se os requisitos são estáveis:
- um bom planejamento evita o retrabalho
- é mais fácil estimar o tempo de desenvolvimento
Cascata: desvantagens
- Documentação extensa + aprovações =
- baixa produtividade
- resistência à mudança
- O software só é lançado no fim do processo
- time-to-market ruim
- falta de feedback durante o desenvolvimento
- Dificilmente os requisitos são estáveis
- arcar com o grande custo de mudança
- ou entregar software que não satisfaz
V-model
- Variação do modelo cascata
- Detalha a forma de verificação/validação
Métodos formais
- Derivados do processo cascata
- Prova-se matematicamente que o sistema funciona conforme a sua especificação formal
- Adequados para sistemas críticos
- uma falha pode custar vidas ou muito dinheiro
- Adequado para certos sistemas embarcados
- o custo de correção é alto (ex.: recall de carros)
- Ex.: processo Cleanroom, da IBM
Métodos formais
- Vantagem: confiabilidade do software
- Desvantagens:
- Altíssimo custo
- Ex.: a verificação do microkernel seL4 custou 500 dólares por linha de código
- Dificuldade de comunicação
- Nem todos entendem requisitos especificados em linguagens formais
- Altíssimo custo
"A culpa é do usuário!"
"Conversamos com ele, escrevemos um documento de especificação dos requisitos, ele aprovou, e agora ele quer mudar!"
Prototipagem
- Um protótipo é uma versão incompleta do sistema
- ex.: não faz tratamento de erros
- ex.: não tem banco de dados
- ex.: não é executável (protótipo de interface)
- ex.: não tem bom desempenho
- O protótipo tipicamente é descartado após o uso
- em alguns casos é possível evoluí-lo para o software completo
- Busca diminuir o risco do projeto por coletar feedback do usuário
Prototipagem
- Desvantagens:
- Gasto de tempo em algo descartável
- Confusão do usuário entre protótipo e sistema
- Tentativas frustradas de converter protótipo em sistema
Processo incremental
- O sistema é desenvolvido e lançado em partes (incrementos)
- Abordagens:
- várias cascatas, uma para cada parte do sistema
- requisitos e projeto são feitos em cascata, e depois é feito o desenvolvimento em incrementos
Processo iterativo e incremental
- Processo evolucionário
- A cada incremento os requisitos são revistos
Modelo espiral
- Barry Boehm, 1988
Cascata = + controle
Iterativo = + flexibilidade
RUP
Rational Unified Process
MATA62 - Processos de Software
By Rodrigo Rocha Gomes e Souza
MATA62 - Processos de Software
- 947