Visão Geral sobre Ciclo de
Vida de Software, Processos
e RUP
Alexandre Monteiro
1/45
Ciclo de Vida e Processo de
Desenvolvimento de
Software
2/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
3/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
4/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
5/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
6/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
7/45
Modelo de Desenvolvimento
Evolucionário


Programação Exploratória
Prototipagem Descartável
Atividades Concorrentes
Especificação
Esboço de
Descrição
Desenvolvimento
Versão
Inicial
Versões
Intermediárias
Validação
Versão Final
8/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
9/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
10/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
11/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
12/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. 1
esp. 2
implement.
13/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)
14/45
Modelo de Desenvolvimento
Baseado em Reuso


Baseado no reuso sistemático de componentes
existentes ou sistemas COTS (Commercial-offthe-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
15/45
Modelo de Desenvolvimento
Baseado em Reuso
Especificação
de Requisitos
Análise de
Componentes
Modificação de
Requisitos
Desenvolvimento
e Integração
Projeto de
Sistema com
Reuso
Validação
do Sistema
16/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
17/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
18/45
longo do processo
Desenvolvimento Espiral
Determinação dos
objetivos, alternativas
e restrições
Análise das alternativas
e
identificação e/ou
resolução de riscos
Análise de
Riscos
Simulações,
modelos e
benchmarks
Planejamento
Desenvolvimento e
validação da versão
corrente do produto
19/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
20/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
21/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
22/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
23/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
24/45
Método



Descrição sistemática de como devese 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.
25/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)
26/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
27/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)
28/45
Exemplos de processos

Processos tradicionais (pesados)


RUP, OPEN, Catalysis
Processos ágeis (leves)

XP, Agile modeling, Crystal, pragmatic
programming, Internet Speed, Scrum, ...
29/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
30/45
Exemplos de processos

Divergências


Detalhamento de atividades a serem seguidas
Critério de conclusão da execução das
atividades



Rigor na atribuição de tarefas a responsáveis





Arquitetura robusta (RUP)
Arquitetura para o contexto da iteração atual (agile
modeling)
workers (RUP)
alocação sob demanda e interesse (XP)
Artefatos (documentação) gerados
Nível de Automação
Nível de (im)pessoalidade
31/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???
32/45
Visão Geral do RUP
33/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
34/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
35/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
36/45
O RUP é iterativo e
incremental

O ciclo de vida de um sistema consiste de
quatro fases:
concepção
elaboração
construção
transição
tempo




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)
37/45
O RUP é iterativo e
incremental

Cada fase é dividida em iterações:
Inception
Preliminary
iteration
Elaboration
Architect. Architect. Devel..
iteration iteration iteration
Construction
Devel..
iteration
Devel..
iteration
Transition
Transition
iteration
Transition
iteration
Minor Milestones: Releases
38/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
39/45
O RUP é iterativo e
incremental
40/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
41/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
42/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
43/45
Exemplo de Fluxo:
Planejamento e Gerenciamento
Iniciar
Projeto
Aprovar
Projeto
Atestar
Conclusão
do Projeto
Contratante
Identificar
Riscos
Estudar
Viabilidade
Desenvolver
Plano de
Projeto
Gerente de
projeto
Arquiteto
Executar
Plano de
Iteração
Desenvolver
Plano de
Iteração
Avaliar
Iteração
Finalizar
Projeto
Reavaliar
Riscos
Priorizar
Casos de
Uso
44/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.
45/45