Engenharia de Software

Rational Unified Process - RUP

Professor Marcio Victorino mcvictorino@uol.com.br
WWW.DOMINANDOTI.COM.BR

Sintomas de Problemas no Desenvolvimento de Software

Necessidades do usurio ou negcio no atendidas

Requisitos Instveis
Mdulos que no se integram
Dificuldades de Manuteno
Descoberta tardia de erros
Qualidade ou experincia do usurio pobres
Performance de carga sofrvel
Esforo descoordenado da equipe
Questes de versionamento
2

Desenvolvimento Iterativo
Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

Desenvolvimento Iterativo
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida
que consiste em vrias iteraes. Uma iterao incorpora um conjunto
quase seqencial de atividades em modelagem de negcios, requisitos,
anlise e projeto, implementao, teste e implantao, em vrias
propores, dependendo do local em que ela est localizada no ciclo de
desenvolvimento.

Desenvolvimento Iterativo

Desenvolvimento Iterativo

Desenvolvimento Iterativo
Vantagens
Os riscos so reduzidos mais cedo, pois os elementos so integrados progressivamente.
As tticas e os requisitos variveis so acomodados.
A melhoria e o refinamento do produto so facilitados, resultando em um produto
mais robusto.
As organizaes podem aprender a partir dessa abordagem e melhorar seus processos.
A capacidade de reutilizao aumenta.

Gerenciamento de Requisitos
Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

Gerenciamento de Requisitos
"uma condio ou uma capacidade com a qual o sistema dever estar em
conformidade"

O gerenciamento de requisitos uma abordagem sistemtica para localizar,

documentar, organizar e controlar os requisitos variveis em um sistema.

Gerenciamento de Requisitos
O gerenciamento de requisitos definido formalmente como uma
abordagem sistemtica a identificar, organizar e documentar os requisitos
do sistema, alm de firmar e atualizar acordos entre o cliente e a equipe do
projeto sobre os requisitos variveis do sistema.
As chaves para o gerenciamento eficaz de requisitos incluem manter uma
sentena clara dos requisitos, junto com os atributos aplicveis e a
rastreabilidade para outros requisitos e outros artefatos do projeto.

10

Gerenciamento de Requisitos
A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade, porm, os projetos enfrentam
dificuldades pelos seguintes motivos:
Nem sempre os requisitos so bvios e podem vir de vrias fontes.
Existem diversos tipos de requisitos em diferentes nveis de detalhe.
O nmero de requisitos pode se tornar impossvel de gerenciar se eles no forem controlados.
Os requisitos esto relacionados uns com os outros, e tambm com o produto liberado do processo de engenharia do
software.
Os requisitos tm propriedades exclusivas ou valores de propriedade. Por exemplo, eles no so necessariamente
igualmente importantes ou igualmente fceis de se atender.
H vrias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de
diferentes funes.
Os requisitos so alterados.

11

Uso da Arquitetura de Componentes

Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

12

Uso da Arquitetura de Componentes

Os componentes so grupos de cdigo coesos, na forma de cdigo
fonte ou executvel, com interfaces bem definidas e
comportamentos que fornecem forte encapsulamento do contedo
e so, portanto, substituveis.
As arquiteturas baseadas em componentes tendem a reduzir o
tamanho efetivo e a complexidade da soluo e, portanto, so
mais robustas e flexveis.

13

Uso da Arquitetura de Componentes

Um componente de software pode ser definido como um pedao notrivial de software, um mdulo, um pacote ou um subsistema, sendo que
todos desempenham uma funo clara, possuem uma fronteira clara e
podem ser integrados em uma arquitetura bem definida. a realizao
fsica de uma abstrao do design.

14

Modelagem Visual (UML)

Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

15

Modelagem Visual (UML)

A modelagem visual aumenta o nvel de abstrao

16

Modelagem Visual (UML)

A modelagem visual o uso de notaes de design grficas e textuais,
semanticamente ricas, para capturar designs de software.
Uma notao, como a UML, permite que o nvel de abstrao seja
aumentado, enquanto mantm sintaxe e semntica rgidas.

Dessa maneira, a comunicao na equipe de design melhora, medida que

o design formado e revisado, permitindo ao leitor raciocinar sobre ele e
fornecendo uma base no ambgua para a implementao.

17

Modelagem Visual (UML)

Para:
Capturar a estrutura e o comportamento.
Exibir como os elementos do sistema se integram.
Manter projeto e implementao consistentes.
Esconder ou exibir detalhes como for apropriado.
Proporcionar uma comunicao no ambgua.
UML prov uma linguagem comum para todos os tcnicos envolvidos no projeto.

18

Verificao da Qualidade
Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

19

Verificao da Qualidade
Dicionrio:
Uma caracterstica inerente ou diferenciada; uma propriedade.
Superioridade de natureza.
Grau ou classificao de excelncia.

A qualidade no uma dimenso nica, mas vrias. Para usar a definio e aplic-la ao
desenvolvimento de software, ela precisa ser refinada.
"caracterstica de ter demonstrado a realizao da criao de um produto que atende ou excede os
requisitos acordados, conforme avaliado por medidas e critrios acordados, e que criado em
um processo acordado"
20

Verificao da Qualidade
A localizao e a soluo dos problemas de software ficam de 100 a 1.000
vezes mais caros, se realizados aps a implantao. A verificao e o
gerenciamento da qualidade durante o ciclo de vida do projeto essencial
para atingir os objetivos corretos no momento certo.

21

Verificao da Qualidade
Obter qualidade no simplesmente "atender a requisitos" ou produzir um
produto que atende s necessidades e expectativas dos usurios. Pelo
contrrio, a qualidade tambm inclui a identificao das medidas e dos
critrios para demonstrar a obteno da qualidade e a implementao de
um processo para garantir que o produto por ele criado tenha atingido o
grau desejado de qualidade e possa ser repetido e gerenciado.

22

Gerenciamento de Mudanas
Melhores Prticas

Desenvolvimento Iterativo
Gerenciamento de Requisitos
Uso da Arquitetura de Componentes
Modelagem Visual (UML)
Contnua Verificao da Qualidade
Gerenciamento de Mudana

23

Gerenciamento de Mudanas
Um desafio importante quando se est desenvolvendo sistemas intensivos
de software lidar com vrios desenvolvedores, organizados em diferentes
equipes, possivelmente em diferentes locais, trabalhando juntos em vrias
iteraes, releases, produtos e plataformas.
Na ausncia de controle disciplinado, o processo de desenvolvimento
rapidamente se transforma em caos. Gerenciamento de Mudana consiste
de um recurso utilizado para superar esse desafio.

24

Gerenciamento de Mudanas
Coordenao de Atividades e de Artefatos
Coordenao de Iteraes e de Releases
Controle de Mudanas no Software
Desenvolvimento
Paralelo

Gerenciamento de
rea de Trabalho

GM mais do que
simplesmente
check-in e checkout.

Relatrio de

Processo de
Integrao

25

ALERTA

Controle
de
Verses

Princpios Chave (Key Principles)

Adaptar Processos.
Balancear Prioridades dos Interessados.
Colaborao entre Times.
Demonstrar Valor da Iteratividade.
Elevar o Nvel de Abstrao.
Foco contnuo na Qualidade.

26

Adaptar Processos.
Ciclo de vida eficiente.

Incrementar a agilidade do projeto.

Planos e estimativas realsticas.

27

Balancear Prioridades dos Interessados

Alinhar aplicativos s necessidades do negcio e dos usurios.
Reduzir desenvolvimento customizado.
Otimizar o valor do negcio.

28

Colaborao entre Times

Incrementar a produtividade do time.

Melhorar o acoplamento entre necessidades do negcio e

desenvolvimento e operao dos aplicativos.

29

Demonstrar Valor da Iteratividade

Reduo de risco prematura.

Prognostico ao longo do projeto.

Concordncia entre interessados.

30

Elevar o Nvel de Abstrao.

Produtividade.

Reduo da complexidade.

31

Foco contnuo na Qualidade.

Alta qualidade.

Incremento do progresso e da qualidade prematuramente.

32

Processo de Desenvolvimento de Sw
Funes:
Orienta a ordem das atividades de uma equipe.
Especifica quando e quais artefatos devem ser produzidos.
Direciona as tarefas individuais dos desenvolvedores e a equipe como um todo.
Oferece critrios para monitorar e medir os produtos e atividades do projeto.

33

Rational Unified Process (RUP)

O Rational Unified Process (tambm chamado de processo RUP) um
processo de engenharia de software. Ele oferece uma abordagem baseada
em disciplinas para atribuir tarefas e responsabilidades dentro de uma
organizao de desenvolvimento. Sua meta garantir a produo de
software de alta qualidade que atenda s necessidades dos usurios dentro
de um cronograma e de um oramento previsveis.

34

Processo em Equipe
Um processo define quem (papel) est fazendo o qu (produto de
trabalho), como (tarefa) e quando (fluxo) de modo a alcanar
determinado objetivo.

Requisito novo
ou modificado

Processo de
Engenharia de Software

35

Sistema novo
ou modificado

Work Product
Work Product uma abstrao geral que representa algum resultado de
um processo.
Pode ser um dos seguintes elementos:
Artifact (Artefato);
Deliverable (Entrega);
Outcome (Resultado).

36

Artefatos
Observaes:
O rup desencoraja o uso de artefatos em papel, priorizando o uso de mdia.
Cada artefato deve ter apenas um responsvel (na verso 2003, na 7 no existe essa
restrio).

Podem ser organizados em cinco conjuntos de informao:

Conjunto de gerenciamento.
Conjunto de requisitos.
Conjunto de projeto.
Conjunto de implementao.
Conjunto de distribuio.
37

Artefatos
Artefatos so produtos de trabalho tangveis e bem definidos consumidos, produzidos ou
modificados por tarefas. Artefatos podem ser compostos por outros artefatos. So exemplos de
artefatos:
Um modelo, como o Modelo de Casos de Uso ou o Modelo de Design.

Um elemento do modelo, ou seja, um elemento existente em um modelo, como uma classe ou um

subsistema.

O RUP no incentiva a criao de documentos impressos, tendo em vista que o importante

possuir modelos em ferramentas e gerar relatrios quando necessrio.
Um artefato pode ser modificado por vrios papis.

38

Artefatos

39

Entrega
Uma Entrega um produto de trabalho que prov uma descrio
e definio para o empacotamento de outro produto de trabalho.

Uma Entrega utilizada para pr-definir um contedo tpico ou

recomendado da forma que um produto de trabalho deve ser
empacotado para a entrega.

40

Resultado
Um resultado descreve produtos de trabalho intangveis como um
resultado ou um estado como um servidor instalado ou uma rede
otimizada.
Resultados no possuem templates associados ou exemplos e no
possvel a sua reusabilidade.

41

Papeis (Roles)
O conceito mais central no Processo o conceito de papel. O
papel define o comportamento e as responsabilidades de um
indivduo ou de um conjunto de indivduos que trabalham juntos
como uma equipe, no contexto de uma organizao de
engenharia de software.

42

Papeis (Roles)
Um papel uma definio abstrata de um conjunto de atividades executadas e dos
respectivos artefatos.
Normalmente os papis so desempenhados por uma pessoa ou um grupo de
pessoas que trabalham juntas em equipe.
Um membro da equipe do projeto geralmente desempenha muitos papis
distintos.
Os papis no so pessoas; pelo contrrio, eles descrevem como as pessoas se
comportam no negcio e quais so as responsabilidades que elas tm.

43

Tarefa

Os papis possuem tarefas que definem o trabalho que executam.

Uma tarefa uma unidade de trabalho que um indivduo, desempenhando o
papel descrito, pode ser chamado a realizar.

A tarefa tem uma finalidade clara, normalmente expressa em termos da criao

ou atualizao de alguns artefatos como um modelo, uma classe, um plano.
Toda tarefa atribuda a um papel especfico.

Em geral, a granularidade de uma tarefa de durao de algumas horas a

alguns dias e, em geral, envolve um papel e afeta um ou alguns artefatos.

44

Tarefa
As tarefas so divididas em passos. Os passos podem pertencer a trs categorias
principais:
Passos de reflexo: nos quais o indivduo que executa o papel compreende a natureza da
tarefa, rene e examina os artefatos de entrada e formula a sada.

Passos de execuo: nos quais o indivduo que executa o papel cria ou atualiza alguns
artefatos.

Passos de reviso: nos quais o indivduo que executa o papel analisa os resultados em
relao a alguns critrios.

45

Produto de Trabalho x Papel x Tarefa

Tarefa

Papel

Produto de
Trabalho
46

Atividade
Uma tarefa descreve uma unidade de trabalho.
Toda tarefa desempenhada por papis especficos.
A granularidade de uma tarefa de durao de algumas horas a alguns dias e, em
geral, envolve um papel e afeta um ou um pequeno nmero de produtos de
trabalho.
Tarefas no so necessariamente utilizadas como base para o planejamento por
possuirem uma granulao fina (muito detalhadas).
Atividades, grupos de tarefas, normalmente so utilizadas para efeito de
planejamento e controle dos projetos.

47

Observaes
Riscos no RUP:
Riscos de Integrao.
Riscos Arquitetnicos.

Categorias de Mudanas no RUP:

Mudana de Requisitos.
Mudanas Tticas.
Lanar um produto mais cedo com menos funcionalidades.

Mudanas Tecnolgicas.

48

Rational Unified Process - Caractersticas

Iterativo e Incremental
O software desenvolvido em vrias passadas (iterativo), cada passada acrescenta uma parte
soluo (incremental).

Guiado por casos de uso

Os casos de uso definidos para o sistema so a fundao para o resto do processo de
desenvolvimento.

Centrado na arquitetura
Isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de softwares (ou
seja, os aspectos relacionados aos maiores riscos de um projeto de desenvolvimento) esto
intimamente ligados arquitetura. Sendo assim, devemos ento tratar como centro (core) do nosso
desenvolvimento, nossos requisitos arquiteturais do projeto.
49

Rational Unified Process

O RUP tem duas dimenses:
o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo
medida que se desenvolve:
representa o aspecto dinmico do processo quando ele aprovado e expressa em termos de
fases, iteraes e marcos.

o eixo vertical representa as disciplinas, que agrupam as atividades de maneira lgica, por
natureza:
representa o aspecto esttico do processo, como ele descrito em termos de componentes,
disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo (consulte Conceitoschave).

50

Rational Unified Process

Perspectivas do RUP (SOMMERVILLE, 2011, p. 34):
Perspectiva Dinmica: mostra as fases do modelo ao longo do tempo.
Perspectiva Esttica: mostra as atividades realizadas no processo.
Perspectiva Prtica: sugere as boas prticas a serem usadas durante o processo.

(SOMMERVILLE, 2011, p. 34)

... mas eu gostaria de ter lido mais sobre as
dificuldades prticas do uso do processo.

51

Rational Unified Process

52

Observaes

Tempo mdio de uma iterao: 2 6 semanas.

Nmero mdio de iteraes: 6 3.
Considerando as fases [I, E, C, T]:

3 iteraes: [0, 1, 1, 1].

6 iteraes:[1, 2, 2, 1].
9 iteraes:[1, 3, 3, 2].

Disciplina Modelagem de Negcio opcional.

RUP Small Project Lifecycle No possui as
disciplinas:

Modelagem de Negcio.
Implantao.
53

Rational Unified Process

54

Ciclo de Desenvolvimento Completo

Ciclo de Desenvolvimento Completo

Inicia
o

Elabora
o

Iterao 1

Iterao 3

Iterao 2

MN

MN
R

Iterao 4

MN
R

AD

Construo

AD
I
T

T
IM

IM

MN - Modelagem de Negcios
R - Requisitos
AD - Anlise e Design
I - Implementao
T - Testes
IM - Implantao

55

AD
I

T
IM

R
AD

I
T

MN
R

AD
I

Iterao 6

MN
R

AD
I

Iterao 5

MN
R

Transio

I
T

IM

T
IM

IM

Fases do RUP

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software

do RUP dividido em quatro fases seqenciais, cada uma concluda por
um marco principal, ou seja, cada fase basicamente um intervalo de
tempo entre dois marcos principais.

56

Fases do RUP
As fases no so idnticas em termos de programao e esforo. Embora isso varie muito de
acordo com o projeto, um ciclo de desenvolvimento inicial tpico para um projeto de mdio
tamanho deve prever a seguinte distribuio de esforo e programao:

57

Fases do RUP
Uma passagem pelas quatro fases um ciclo de desenvolvimento; cada passagem pelas quatro fases produz
uma gerao do software. A menos que produto "desaparea", ele ir se desenvolver na prxima gerao,
repetindo a mesma seqncia de fases de iniciao, elaborao, construo e transio, mas agora com nfase
diferente nas diversas fases. Esses ciclos subseqentes so chamados de ciclos de evoluo. medida que o
produto atravessa vrios ciclos, so produzidas novas geraes.

58

Fim

Professor Marcio Victorino

59