Anda di halaman 1dari 45

1/45

Visão Geral sobre Ciclo de
Vida de Software, Processos
e RUP
Alexandre Monteiro

2/45
Ciclo de Vida e Processo de
Desenvolvimento de
Software
3/45
O que é um modelo de ciclo de
vida de processo de software?
 Uma representação abstrata e
simplificada do processo de
desenvolvimento software,
tipicamente mostrando as principais
atividades e dados usados na
produção e manutenção de software
4/45
Principais Modelos do Ciclo
de Vida de Software
 Cascata
 Modelo de Desenvolvimento Evolucionário
 Programação Exploratória
 Prototipagem descartável
 Modelo de Transformação Formal
 Modelos Iterativos
 Espiral
 Incremental
5/45
Modelo Cascata
(ou clássico)
 Derivado de modelos existentes em outras
engenharias
 Sua estrutura é composta por várias etapas
que são executadas de forma sistemática e
seqüencial
 Na prática, existe uma interação entre as
etapas e cada etapa pode levar a
modificações nas etapas anteriores
6/45
Modelo Cascata
Definição de
Requisitos

Projeto do
Sistema e do
Software

Implementação e
Testes Unitários

Integração e
Teste do
Sistema

Operação e
Manutenção

7/45
Modelo Cascata na Prática
Definição de
Requisitos

Projeto do
Sistema e do
Software

Implementação e
Testes Unitários

Integração e
Teste do Sistema

Operação e
Manutenção














8/45
Modelo de Desenvolvimento
Evolucionário
 Programação Exploratória
 Prototipagem Descartável
Atividades Concorrentes

Especificação

Desenvolvimento

Validação

Esboço de
Descrição

Versão
Inicial

Versões
Intermediárias

Versão Final

9/45
Programação Exploratória
 Idéia geral:
 Desenvolvimento da primeira versão do sistema o
mais rápido possível
 Modificações sucessivas até que o sistema seja
considerado adequado
 Após o desenvolvimento de cada uma das versões do
sistema ele é mostrado aos usuários para
comentários
 Adequado para o desenvolvimento de sistemas
onde é difícil ou impossível se fazer uma
especificação detalhada do sistema
 Principal diferença para os outros modelos é a
ausência da noção de programa correto
10/45
Programação Exploratória
 Tem sido mais usada no desenvolvimento de
sistemas especialistas - geralmente
sistemas que tentam emular capacidades
humanas
 A maioria dos sistemas desenvolvidos com
sucesso usando a programação exploratória
foi implementada usando pequenos grupos
de profissionais altamente qualificados e
motivados
11/45
Prototipagem Descartável
 Como na programação exploratória, a primeira fase
prevê o desenvolvimento de um programa para o
usuário experimentar
 No entanto, o objetivo aqui é estabelecer os
requisitos do sistema
 O software deve ser reimplementado na fase
seguinte
 A construção de protótipos com os quais os
usuários possam brincar é uma idéia bastante
atrativa:
 Para sistemas grandes e complicados
 Quando não existe um sistema anterior ou um
sistema manual que ajude a especificar os requisitos
12/45
Prototipagem Descartável
 Os objetivos do protótipo devem estar bem claros
antes do início da codificação. Possíveis objetivos:
 Entender os requisitos dos usuários
 Definir a interface com os usuários
 Demonstrar a viabilidade do sistemas para os
gerentes.
 Uma decisão importante a ser tomada é escolher o
que será e o que não será parte do protótipo
 Não é economicamente viável implementar todo
o sistema!
 Os objetivos do protótipo são o ponto de
partida
13/45
Transformação Formal
 Idéia geral:
 Uma especificação formal (definição
matemática, não ambígua) do software é
desenvolvida e posteriormente
“transformada” em um programa através
de regras que preservam a corretude da
especificação
esp. 2
esp. 1
implement.
14/45
Transformação Formal
 A grande motivação por trás da idéia de
refinamento formal é a possibilidade de
gerar automaticamente programas que são
corretos por construção
 O próprio processo de desenvolvimento deve
grantir que o programa faz exatamente o que
foi especificado
 Este modelo tem sido aplicado ao
desenvolvimento de sistemas críticos,
especialmente naqueles onde a segurança é
um fator crítico (ex: sistema de controle
de tráfego aéreo)
15/45
Modelo de Desenvolvimento
Baseado em Reuso
 Baseado no reuso sistemático de componentes
existentes ou sistemas COTS (Commercial-off-
the-shelf)
 Etapas do processo
 Especificação dos requisitos
 Análise de componentes
 Modificação dos requisitos
 Projeto de sistema com reuso
 Desenvolvimento e integração
 Validação
 Esta abordagem está se tornando mais importante,
mas há ainda pouca experiência com ela
16/45
Modelo de Desenvolvimento
Baseado em Reuso
Especificação
de Requisitos

Análise de
Componentes

Modificação de
Requisitos

Projeto de
Sistema com
Reuso

Desenvolvimento
e Integração

Validação
do Sistema

17/45
Modelos Iterativos
 Requisitos de sistema SEMPRE evoluem
durante curso de um projeto. Assim a
iteração do processo sempre faz parte do
desenvolvimento de grandes sistemas
 Iterações podem ser aplicadas a quaisquer
dos modelos de ciclo de vida
 Duas abordagens (relacionadas)
 Desenvolvimento espiral
 Desenvolvimento incremental
18/45
Desenvolvimento Espiral
 Acrescenta aspectos gerenciais ao processo de
desenvolvimento de software.
 análise de riscos em intervalos regulares do processo de
desenvolvimento de software
 planejamento
 controle
 tomada de decisão
 O processo é representado como uma espiral em vez de
uma seqüência de atividades
 Cada volta na espiral representa uma fase no processo
 Não há fases fixas como especificação ou projeto -
voltas na espiral são escolhidas dependendo do que é
requerido
 Riscos são avaliados explicitamente e resolvidos ao
longo do processo
19/45
Desenvolvimento Espiral


Determinação dos
objetivos, alternativas
e restrições
Análise de
Riscos



Análise das alternativas
e
identificação e/ou
resolução de riscos
Desenvolvimento e
validação da versão
corrente do produto

Simulações,
modelos e
benchmarks


Planejamento
20/45
Desenvolvimento Incremental
 Em vez de entregar o sistema como um todo, o
desenvolvimento e a entrega são divididos em
incrementos, com cada incremento entregando parte da
funcionalidade requerida
 Requisitos dos usuários são priorizados e os requisitos de
mais alta prioridade são incluídos nas iterações iniciais
 Uma vez que o desenvolvimento de um incremento é
iniciado, os requisitos são "congelados". Embora os
requisitos possam continuar a evoluir para incrementos
posteriores
 Em certos aspectos é similar à programação exploratória.
No entanto, o escopo do sistema deve ser claramente
entendido antes de se iniciar o desenvolvimento
21/45
Desenvolvimento Incremental
Definir
esboço dos
requisitos
Associar
requisitos a
incrementos
Projetar a
arquitetura do
sistema
Desenvolver
um
incremento
Validar o
incremento
Integrar o
incremento
Validar o
sistema
Sistema
Final
22/45
Processo
 Conjunto de atividades
 bem definidas
 com responsáveis
 com artefatos de entrada e saída
 com dependências entre as mesmas e
ordem de execução
 com modelo de ciclo de vida
23/45
Processo
 é uma ação regular e contínua (ou sucessão
de ações) realizada de forma bem definida,
levando a um resultado
 é um conjunto parcialmente ordenado de
atividades (ou passos) para se atingir um
objetivo
 define quem está fazendo o que, quando e
como para atingir um certo objetivo
24/45
Processo versus Metodologia
 Alguns autores consideram que
processos incluem
 uma metodologia
 pessoas
 tecnologia (suporte de ferramentas)
 Outros consideram que uma
metodologia é a especialização de um
processo com um conjunto de métodos

25/45
Método
 Descrição sistemática de como deve-
se realizar uma determinada atividade
ou tarefa
 A descrição é normalmente feita
através de padrões e guias
 Exemplos: Método para descoberta
de atores e casos de uso no RUP.

26/45
Modelo de Processo
 é uma representação de um processo,
usualmente envolvendo
 atividades a serem realizadas
 agentes que realizam as atividades
 artefatos (produtos) gerados
 recursos necessários (consumidos)

27/45
Modelo de Processo
 Um modelo é usado para entendimento e
comunicação do processo, e como base para
análise, execução, gerência e melhoria do
processo
 Idealmente a descrição deve ser formal e
completa para permitir, por exemplo,
automação
 A descrição deve ser apresentada em
diferentes níveis de abstração

28/45
Modelo de Processo
 O formalismo utilizado para
representar o processo é o
ingrediente mais importante da
modelagem
 Não parece haver consenso sobre um
formalismo ideal
 Mas há esforço de padronização (SPEM –
OMG)
29/45
Exemplos de processos
 Processos tradicionais (pesados)
 RUP, OPEN, Catalysis
 Processos ágeis (leves)
 XP, Agile modeling, Crystal, pragmatic
programming, Internet Speed, Scrum, ...

30/45
Exemplos de processos
 Consenso em torno de
 Iteratividade
 Participação de usuários
 Flexibilidade de configuração para
projetos específicos
 Comunicação entre membros da equipe

31/45
Exemplos de processos
 Divergências
 Detalhamento de atividades a serem seguidas
 Critério de conclusão da execução das
atividades
 Arquitetura robusta (RUP)
 Arquitetura para o contexto da iteração atual (agile
modeling)
 Rigor na atribuição de tarefas a responsáveis
 workers (RUP)
 alocação sob demanda e interesse (XP)
 Artefatos (documentação) gerados
 Nível de Automação
 Nível de (im)pessoalidade
32/45
Polêmica
 Se a tendência é processos leves, afinal o
desenvolvimento de software é
 Arte+Sociologia+Psicologia+...
ou
 Lógica+Modelos+Engenharia+...???
 E todo o esforço de consolidação da
Engenharia de Software como uma ciência
exata???
33/45
Visão Geral do RUP
34/45
O que é o RUP?
 O nome é uma abreviação de Rational
Unified Process
 mas na verdade é
 Processo + Métodos + Linguagem (UML)
 e os autores argumentam que é
 Framework para gerar processos
35/45
O que é o RUP?
 Conjunto de atividades
 bem definidas
 com responsáveis
 com artefatos de entrada e saída
 com dependências entre as mesmas e ordem de
execução
 com modelo de ciclo de vida
 descrição sistemática de como devem ser
realizadas
 guias (de ferramentas ou não), templates
 utilizando diagramas de UML
36/45
Características Principais do
RUP
 O desenvolvimento de sistemas
seguindo o RUP é
 Iterativo e incremental
 Guiado por casos de uso (use cases)
 Baseado na arquitetura do sistema

37/45
O RUP é iterativo e
incremental
 O ciclo de vida de um sistema consiste de
quatro fases:




 Concepção (define o escopo do projeto)
 Elaboração (detalha os requisitos e a
arquitetura)
 Construção (desenvolve o sistema)
 Transição (implanta o sistema)
tempo
concepção
elaboração construção transição
38/45
O RUP é iterativo e
incremental
 Cada fase é dividida em iterações:
Minor Milestones: Releases
Inception Elaboration Construction
Transition
Transition
iteration
Preliminary
iteration
Architect.
iteration
Architect.
iteration
Devel..
iteration
Devel..
iteration
Devel..
iteration
Transition
iteration
39/45
O RUP é iterativo e
incremental
 Cada iteração
 é planejada
 realiza uma seqüência de atividades (de
elicitação de requisitos, análise e
projeto, implementação, etc.) distintas
 geralmente resulta em uma versão
executável do sistema
 é avaliada segundo critérios de sucesso
previamente definidos
40/45
O RUP é iterativo e
incremental
41/45
O RUP é guiado por casos de
uso
 Os casos de uso não servem apenas para
definir os requisitos do sistema
 Várias atividades do RUP são guiadas pelos
casos de uso:
 planejamento das iterações
 criação e validação do modelo de projeto
 planejamento da integração do sistema
 definição dos casos de teste

42/45
O RUP é baseado na
arquitetura do sistema
 Arquitetura
 visão geral do sistema em termos dos seus
subsistemas e como estes se relacionam
 A arquitetura é prototipada e definida logo
nas primeiras iterações
 O desenvolvimento consiste em
complementar a arquitetura
 A arquitetura serve para definir a
organização da equipe de desenvolvimento e
identificar oportunidades de reuso


43/45
Organização do RUP
 Fluxos de atividades
 Atividades
 passos
 entradas e saídas
 guias (de ferramentas ou não), templates
 Responsáveis (papel e perfil, não
pessoa)
 Artefatos

44/45
Exemplo de Fluxo:
Planejamento e Gerenciamento
Gerente de
projeto
Arquiteto
Contratante
Iniciar
Projeto
Aprovar
Projeto
Estudar
Viabilidade
Atestar
Conclusão
do Projeto
Identificar
Riscos
Desenvolver
Plano de
Projeto
Desenvolver
Plano de
Iteração
Executar
Plano de
Iteração
Avaliar
Iteração
Finalizar
Projeto
Reavaliar
Riscos
Priorizar
Casos de
Uso
45/45
Referências
 Ivar Jacobson, Grady Booch e James
Rumbaugh. The Unified Software
Development Process. Capítulos 1 a 5.
 Philippe Kruchten. The Rational
Unified Process – an Introduction.