1. Processo do Software
Grupo de atividades coerentes para
especificação, projeto, implementação
e teste de sistemas de software.
2. Objetivos
Introduzir os processos de modelagem de
software
Descrever alguns modelos de processos e quando
eles devem ser usados
Descrever em linhas gerais o processo modelo
para os requisitos de engenharia, de
desenvolvimento de softare, seu teste e evolução
Indroduzir a tecnologia CASE para o auxílio dos
processos de software
3. Tópicos cobertos
Modelos do processo de software
Iteração entre os processos
Especificação de software
Projeto e implementação de software
Validação do software
Evolução do software
Processos automatizados de desenvolvimento
4. O processo do software
Um conjunto estruturado de atividades necessárias para
desenvolver um sistema de software
• Especificação
• Projeto
• Validação
• Evolução
Um modelo de processo de software é uma representação
abstrata do processo. Ela apresenta uma descrição do
processo de algumas perspectivas particulares
5. Modelos genéricos de processos de
software
O modelo cascata (waterfall)
• Fases separadas e distintas de especificação e desenvolvimento
Desenvolvimento evolucionário (ou prototipação)
• Especificação e desenvolvimento são intercalados
Modelo de sistema formal
• Um modelo de sistema matemático é formalmente transformado
numa implementação
Desenvolvimento baseado em reuso
• O sistema é construído a partir de componentes existentes
8. Waterfall model phases
Análise de requisitos e definições
Projeto do sistema e do software
Implementação e teste de unidades
Integração e testes do sistema
Manutenção e operação
Uma deficiência do modelo cascata é a
dificuldade em acomodar mudanças depois que o
processo se inicia.
9. Análise e Engenharia de Sistemas
Estabelecer os requisitos básicos para todos os
sistemas que envolvem o software, como
hardware, pessoas e bancos de dados.
Envolve a coleta dos requisitos em nível do
sistema, com uma pequena quantidade de projeto
e análise de alto nível.
10. Analise de Requisitos de Sw
Concentra a coleta de requisitos no sw.
Leva à compreensão do domínio da informação, a
função, desempenho e interfaces exigidos.
Os requisitos para o sistema e para o sw são
documentados e revistos com o cliente.
11. Projeto
Estrutura de dados
Arquitetura de sw
Detalhes procedimentais
Caracterização da interface
É avaliado antes de começar a ser implementado
Junto com as etapas anteriores torna-se parte da
documentação do sistema
12. Codificação
Projeto traduzido para a linguagem do
computador.
Se o projeto for executado detalhadamente, a
codificação pode ser executada mecanicamente?
13. Testes
Concentra-se nos aspectos lógicos internos do sw.
Garante que “todas as instruções” tenham sido
testadas.
A entrada definida produz os resultados exigidos?
Garbage in, garbage out?
14. Manutenção
Sw embutido nem sempre tem esta parte.
Erros encontrados.
Mudanças no ambiente externo.
Acréscimos funcionais.
Desempenho
15. Problemas com a Cascata
O mais antigo e amplamente usado.
Projetos reais raramente seguem o fluxo seqüencial que ele
propõe. Ocorrem iterações que trazem problemas na
aplicação do paradigma.
É 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.
O cliente deve ter paciência. Uma versão do sw só estará
disponível em um ponto tardio do cronograma. Um erro
crasso, pode ser desastroso.
Só é apropriado quando os requisitos são bem conhecidos.
16. Desenvolvimento evolucionário
Desenvolvimento exploratório
• O objetivo é trabalhar com o cliente e desenvolver um sistema
final a partir das especificações iniciais. Deve iniciar com
requisitos bem compreendidos.
Jogar fora a prototipação
• O objetivo é entender os requisitos do sistema. Deve iniciar com
requisitos pouco compreendidos.
19. Desenvolvimento evolucionário
Problemas
• Falta de visibilidade sobre o processo.
• Sistema geralmente pouco estruturado.
• Habilidades especiais (ex. em linguagens para uma rápida
prototipação) são requeridas.
Aplicabilidade
• Para sistemas interativos pequenos ou médios.
• Para partes de de grandes sistemas (ex. A interface com o
usuário).
• Para sistemas com pouco tempo de vida.
20. Modelo de desenvolvimento
formal
Baseado na transformação de uma especificação
matemática através de diferentes representações
em um programa executável.
As transformações preservam a corretude das
especificações, sendo fácil demonstrar que que o
programa segue estas últimas.
Baseado na abordagem ‘Cleanroom’ para o
desenvolvimento de software.
23. Desenvolvimento formal
Problemas
• São necessárias habilidades especiais e treinamento para aplicar
a técnica.
• Dificuldade para formalizar especificamente alguns aspectos do
sistema, como a interface com o usuário.
Aplicabilidade
• Sistemas críticos, especialmente aqueles em que uma versão
segura deve ser feita antes do sistema entrar em operação.
24. Desenvolvimento orientado a
reutilização
Baseado na sistemática do reuse, onde os
sistemas são integrados a partir de componentes
existentes ou sistemas COTS (Commercial-off-
the-shelf).
Estágios do processo
• Análise dos componentes
• Modificação dos requisitos
• Projeto do sistema com reutilização
• Desenvolvimento e integração
Esta abordagem está se tornando mais importante,
porém ainda há pouca experiência com ela.
26. Processo de iteração
Os requisitos do sistema sempre evoluem ao
longo do projeto, então o processo de iteração dos
estágios anteriores é retrabalhado e vira parte do
processo para grandes sistemas.
Iteração pode ser aplicada a qualquer modelo
genérico de ciclo de vida.
Duas abordagens semelhantes:
• Desenvolvimento incremental
• Desenvolvimento espiral
27. Desenvolvimento incremental
Ao invés de entreagar o sistema uma única vez, o
desenvolvimento e a entrega são partidos em
incrementos, que fornecem parte das
funcionalidades requeridas.
Os requisitos do usuários são dispostos
hierarquicamente, e os requisitos de prioridades
mais altas são incluídos nas primeiras entregas.
Quando o desenvolvimento de um incremento é
iniciado, os requisitos são “congelados” de forma
que os requisitos para incrementos posteriores
possam continuar a evoluir.
29. Vantagens do desenvolvimento
incremental
Valor ao cliente tende a ser entregue a cada
incremento, então a funcionalidade dos sistema
tende a ser avaliada mais cedo.
Os primeiros incrementos funcionam como um
protótipo para ajudar a esclarecer os requisitos
para os próximos incrementos.
Baixo risco de o projeto falhar completamente.
As tarefas de mais alta prioridade, tendem a
receber mais testes.
30. Extreme programming (XP)
Nova abordagem de desenvolvimento baseada no
desenvolvimento e entrega de pequenos
incrementos de funcionalidade.
Funciona com melhorias contínuas no código,
envolvimento do usuário no time de
desenvolvimento e programação em pares.
Os testes aparecem antes da codificação.
31. Desenvolvimento em espiral
O Processo é representado como um espiral ao invés de
uma sequência de atividades com voltas para trás.
Cada volta no espiral representa uma fase no processo.
Não há fases fixas como especificação ou projeto. As
voltas no espiral são escolhidas dependendo do que é
requisitado
Os riscos são explicitamente avaliados e resolvidos
durante todo o processo
32. Spiral model of the software process
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integration
test
Acceptance
test
Service Develop, verify
next-level product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
33. Setores do modelo espiral
Definição dos objetivos
• Os objetivos específicos para a fase são identificados.
Avaliação e redução de riscos
• Os riscos são avaliados e as atividades organizadas para reduzir
os riscos chave.
Desenvolvimento e validação
• Um modelo de desenvolvimento para o sistema é escolhido,
que pode ser qualquer um dos modelos genéricos.
Planejamento
• O projeto é revisto e a próxima fase da espiral é planejada.