Anda di halaman 1dari 8

Introduo ao OpenUP (Open Unified Process)

Diferentes projetos tm diferentes necessidades de processos. Fatores tpicos ditam as


necessidades de um processo mais formal ou gil, como o tamanho da equipe e localizao,
complexidade da arquitetura, novidades tecnolgicas, conformidade com padres, dentre
outros. No entanto, h boas prticas de desenvolvimento de software que beneficiam
qualquer time de projeto e ajuda-os a serem mais eficientes.
Este artigo apresenta os blocos para a construo do OpenUP, um processo gil e unificado
que contm um conjunto mnimo de prticas para ajudar times a serem mais eficientes no
desenvolvimento de software. OpenUP engloba uma filosofia pragmtica e gil que foca na
natureza colaborativa do desenvolvimento do software. Ele um processo independente de
ferramenta e de pouca cerimnia que pode ser usado como est ou ser estendido para
atender uma ampla variedade de tipos de projetos.

O que o OpenUP
OpenUP um processo de desenvolvimento de software minimamente suficiente isso
significa que somente o contedo fundamental includo. Assim, ele no prov orientao em
alguns tpicos que o projeto possa tratar, como equipes grandes, situaes contratuais,
aplicaes de segurana ou misso crtica, orientao de tecnologia especfica, etc. Contudo,
OpenUP completo no sentido que ele pode ser apresentado como um processo completo
para construir um sistema. Para atender as necessidades que no so cobertas no seu
contedo, OpenUP extensvel para ser usado como base no qual o contedo do processo
pode ser adicionado ou adaptado como necessrio.
OpenUP um processo gil. Embora o OpenUP seja leve, h muito mais para ser gil do que
simplesmente ser leve. Prticas geis mais reconhecidas so voltadas para obter comunicao
do time no qual todos compartilham o entendimento do projeto. Mtodos geis tm chamado
nossa ateno de volta importncia de coordenar o entendimento, beneficiando os
stakeholders ao invs de entregas improdutivas e formalidade.
OpenUP tm uma caracterstica essencial de um Processo Unificado magro que aplica
abordagens interativas e incrementais dentro de um comprovado ciclo de vida estruturado.
OpenUP baseado em casos de uso e cenrios, gerenciamento de risco e uma abordagem
centrada na arquitetura orientada ao desenvolvimento.

Princpios do OpenUP
OpenUP orientado a quatro princpios principais listados abaixo. Os princpios capturam a
inteno geral por trs do processo e cria a fundao para interpretar papis e produtos de
trabalho, e realizar tarefas:

Colaborao para alinhar interesses e compartilhar entendimento. Este princpio


promove prticas para fomentar um ambiente saudvel entre o time, permitindo a
colaborao e desenvolvimento de um entendimento compartilhado do projeto.

Balanceamento de prioridades concorrente para maximizar o valor do cliente. Este


princpio promove prticas que permitem os participantes do projeto e stakeholders
desenvolver uma soluo que maximize os benefcios dos stakeholders e est de
acordo com as restries do projeto.
Foco antecipado na arquitetura para minimizar os riscos e organizar o
desenvolvimento. Este princpio promove prticas que permitem o time focar numa
arquitetura para minimizar os riscos e organizar o desenvolvimento.
Envolver para continuamente obter feedback e melhorar. Este princpio promove
prticas que permitem o time obter feedback contnuo e antecipado dos stakeholders,
e demonstrar valor incremental a eles.

Cada princpio do OpenUP suporta uma afirmao do Manifesto gil, como visto na tabela 1.
Princpio do OpenUP
Afirmao do Manifesto gil
Colaborar para alinhar interesses e
Indivduos e interaes sobre processos e
compartilhar entendimento
ferramentas
Balanceamento de prioridades concorrentes
Colaborao com o cliente mais que
para maximizar valor para o cliente
negociao de contratos
Foco antecipado na arquitetura para
Software em funcionamento mais que
minimizar os riscos e organizar o
documentao abrangente
desenvolvimento
Envolvimento contnuo para obter feedback e Responder a mudanas mais que seguir um
melhoria
plano
Tabela 1 mapeamento entre os princpio do OpenUP e o Manifesto gil

Como o OpenUP organizado


OpenUp organizado em duas dimenses diferentes e correlacionadas: contedo de mtodos
e contedo de processos. O contedo de mtodo onde os elementos de mtodo (papis,
tarefas, artefatos e orientao) so definidos, independentemente de como eles so usados no
ciclo de vida do projeto. O contedo do processo onde os elementos do mtodo so
aplicados no sentido temporal. Muitos ciclos de vida diferentes para tipos de projetos
diferentes podem ser criados do mesmo conjunto de elementos de mtodos (mais detalhes
esto na seo Processo abaixo).

reas de contedo
O contedo do OpenUP atende organizaes de trabalho no nveis pessoal, do time e do
stakeholders, como visto na Figura 1.
No nvel pessoal, os membros do time no projeto OpenUP contribuem com seus trabalhos em
micro-incrementos, que tipicamente representam o resultado de algumas horas a alguns dias
de trabalho. A aplicao evolui um micro-incremento por vez e o progresso efetivamente
visto a cada dia. Os membros do time abertamente compartilham seu progresso dirio nos
micro-incrementos, que aumentam a visibilidade do trabalho, a confiana e o trabalho de
equipe.

O projeto dividido em interaes: intervalos planejados e com tempo definidos, tipicamente


medidos em semanas. OpenUP ajuda o time a concentrar apropriadamente seus esforos
atravs de ciclos de vida de interaes a fim de entregar valor incremental ao cliente de
maneira previsvel uma verso completa testada ou um incremento ao produto ao fim de
casa interao.
OpenUP estrutura o ciclo de vida do projeto em quatro fases: Incio, Elaborao, Construo e
Transio. O ciclo de vida do projeto proveem os stakeholders fiscalizao, transparncia e
mecanismos de direo para controle dos fundos do projeto, escopo, exposio ao risco, valor
fornecido e outros aspectos do processo.

Figura 1 Organizao do trabalho e foco do contedo no OpenUP

Papis
A habilidade essencial necessria aos pequenos times co-alocados so representados pelos
papis do OpenUP:

Stakeholder representa o interesse do grupo cujas necessidades devem ser satisfeitas


pelo projeto. Esse um papel que pode ser executado por qualquer um que (ou
potencialmente ser) afetado materialmente pelo resultado do projeto.
Analista representa o cliente e o usurio final no que diz respeito a obter a entrada
dos stakeholders para entender o problema a ser resolvido e pela captura e
configurao das prioridades para os requisitos.

Arquiteto responsvel por projetar a arquitetura do software, que inclui tomar as


decises tcnicas chave que definem todo o design e implementao do projeto.
Desenvolvedor responsvel por desenvolver uma parte do sistema, inclusive projetlo de acordo com a arquitetura, e ento implement-lo, executar testes unitrios e
integrar os componentes que fazem parte da soluo.
Testador responsvel pelas principais atividades de testes, como identificar, definir,
implementar e conduzir os testes necessrios, bem como registrar as sadas dos testes
e analizar os resultados.
Gerente de projetos lidera o planejamento do projeto em colaborao com os
stakeholders e o time, coordenando interaes com os stakeholders, e mantendo o
time do projeto focado em atingir os objetivos do projeto.
Qualquer papel representa algum no time que pode realizar tarefas gerais.

Disciplinas
O contedo de mtodo do OpenUP focado nas seguintes disciplinas: Requisitos, Arquitetura,
Desenvolvimento, Teste, Gerenciamento de Projeto e Gerenciamento de Configurao e
Mudana.
Outras disciplinas e reas de preocupao foram omitidas, como Modelagem de Negcios,
Ambiente, Gerenciamento de Requisitos avanado e configurao de ferramentas de
Gerenciamento de Configurao. Esses assuntos ou so considerados desnecessrios para um
projeto pequeno ou so tratados por outras reas da organizao, fora do time do projeto.
Tarefas
Uma tarefa uma unidade de trabalho que um papel pode realizar. No OpenUP, h 18 tarefas
que os papis realizam como executante primrio (o responsvel por executar a tarefa) ou
executante adicional (apoiando e fornecendo informao usada na execuo da tarefa). A
natureza colaborativa do OpenUP manifestado ao ter os executantes primrios trabalhando
com uma gama de outros indivduos quando realizam uma tarefa.
Artefatos
Um artefato qualquer coisa que produzida, modificada ou usada em uma tarefa. Os papis
so responsveis pela criao e atualizao dos artefatos. Artefatos esto sujeitos a controle
de verso durante o ciclo de vida do projeto.
Os 17 artefatos do OpenUP so considerados os artefatos essenciais que um projeto deve usar
para capturar informaes sobre o produto e relacionadas ao projeto. No h obrigao em
capturar informao em artefato formal. A informao pode ser informalmente capturada
numa lousa (por exemplo para design e arquitetura), reunir notas (por exemplo para
avaliaes de status), etc. Modelos que oferecem uma forma padro e sem mistrios para
capturar informaes. Projetos podem usar artefatos OpenUP ou substitu-los pelos seus
prprios.
Processos

Contedo de mtodo reusvel criado separadamente da sua aplicao em processo.


Contedo de mtodo fornece explicaes passo a passo, descrevendo como os objetivos
especficos de desenvolvimento so alcanados, independente da ordem dos elementos do
mtodo dentro do ciclo de vida de desenvolvimento.
Processos pegam esses elementos dos mtodos e relaciona-os em sequncias semi-ordenadas
que so customizadas para especificar o tipo de projeto. Elementos de mtodos so
organizados em pedaos de processos reusveis chamados padres de capacidade,
fornecendo uma abordagem de desenvolvimento consistente para as necessidades comuns de
projeto. Esses padres so feitos de tarefas organizadas (do contedo do mtodo) em
atividades, agrupando-os em uma sequncia que faa sentido para uma rea particular onde o
padro aplicado.
Padres podem ser pequenos e focados em reas particulares como gerenciamento de
interao, iniciao do projeto, definio da arquitetura e assim por diante. Esses so
considerados os blocos de construo bsicos para criar padres maiores ou processos de
entrega (definidos abaixo).
Um exemplo de bloco de construo bsico no OpenUp o padro de Incremento de Soluo
de Desenvolvimento, como representado na figura 2.
Esta atividade fornece uma forma de realizar um planejamento baseado em metas e execuo
de um trabalho. Trabalho assumido por desenvolvedores e o progresso do trabalho medido
baseado no atingimento das metas usando um cdigo-fonte projetado, testado pelo
desenvolvedor e integrado.
O item de trabalho pode ser um caso de uso, um cenrio, um requisito de apoio ou uma
requisio de mudana. Um contexto pode ser especificado quando um item de trabalho est
para ser desenvolvido em um incremento. Desenvolvimento pode ser focado, por exemplo, em
uma camada (por exemplo interface com o usurio, lgica de negcio ou acesso ao banco de
dados), ou em um componente. Se um contexto especificado ou no, a responsabilidade do
desenvolvedor criar um design e implementao para aquele item de trabalho, e escrever e
executar os testes do desenvolvedor na implementao para garantir que a implementao
funciona como projetado, tanto os unitrios como os de integrao no cdigo base.
O padro de Incremento de Soluo de Desenvolvimento ocorre quantas vezes houver item de
trabalho a desenvolver na interao dada.

Figura 2 Incremento de Soluo de Desenvolvimento


Como mencionado anteriormente, blocos de construo bsica so usados para a criao de
padres maiores, por exemplo, padres que podem ser usados como modelos para interaes
padres contendo todas as atividades necessrias para uma interao particular dentro da
fase de projeto.
OpenUP aplica as fases do Processo Unificado: Iniciao, Elaborao, Construo e Transio.
Quando tomados juntos, esses blocos de construo bsicos so tambm usados para atingir o
objetivo para cada fase (vide Tabela 2 para o mapeamento desse padres e objetivos das
fases).
Padro de modelo de interao
Interao da Fase de Iniciao
Iniciao do Projeto
Interao de Planejamento e
Gerenciamento
Identificao e refinamento dos
requisitos
Acordo sobre a Abordagem
Tcnica
Interao da Fase de Elaborao

Objetivos das fases


Entendimento do que construir
Identificao das funcionalidades
chave do sistema
Determinar ao menos uma soluo
possvel
Entender o custo, o prazo e os riscos
associados ao projeto

Obter um entendimento mais

detalhado dos requisitos


Interao de Gerenciamento e
Planejamento
Projetar, implementar, validar uma
arquitetura
Identificao e Refinamento dos
Requisitos
Mitigar os principais riscos e produzir
uma agenda precisa e estimativas de
Definio da Arquitetura
custo
Incremento da Soluo de
Desenvolvimento
Soluo de Testes
Tarefas em Andamento
Interao da Fase de Construo
Desenvolver interativamente um
produto completo que esteja pronto
Interao de Planejamento e
para transio para sua comunidade
Gerenciamento
de usurios
Identificao e Refinamento dos
Minimizar os custos de
Requisitos
desenvolvimento e alcanar algum
Soluo de Testes
grau de paralelismo
Tarefas em Andamento
Interao da Fase de Transio
Realizar testes beta para validar as
expectativas do usurio
Interao de Planejamento e
Gerenciamento
Atingir um consenso dos
stakeholders quando a implantao
Incremento da Soluo de
est completa.
Desenvolvimento
Soluo de Testes
Tarefas em andamento
Tabela 2 mapeamento entre padres e objetivos das fases

Quando seguimos os padres de modelo de interao (que ocorrem quantas vezes forem
necessrios), ns temos um processo de entrega uma abordagem completa e integrada para
realizar um tipo de projeto especfico (como visto na Figura 3). Um processo de entrega
descreve um ciclo de vida do projeto completo e usado como referncia para executar
projetos similares.

Figura 3 Processo de Entrega do OpenUP


OpenUP tem um processo de entrega para desenvolvimento interativo em quatro fases. Os
padres de modelo de interao so aplicados quantas vezes forem necessrios, dependendo
de quantas interaes o time decidir executar em cada fase. Projetos com diferente
necessidades podem instanciar padres de modelo de interao diferentemente. Por exemplo,
um projeto que lida com uma tecnologia desconhecida ou uma arquitetura complexa pode
precisar de mais interaes na fase de Elaborao do que um projeto que lida com uma
tecnologia conhecida e uma arquitetura pr-existente.

Um processo base
O processo OpenUP, embora completo no seu escopo e contexto alvo, tambm serve como
um processo base no qual contedo de processo adicional pode ser construdo. Plug-ins
podem estender o OpenUP para incluir orientao para tcnicas em grande escala (tal como
Desenvolvimento Orientado ao Modelo) ou tcnicas mais leves e geis (como Tcnicas de
Banco de Dados geis). Vendedores de ferramentas podem criar plug-ins que anexam
ferramentas de mentoria para tarefas dando instrues passo a passo de como a ferramenta
pode ser usada dentro do processo.
Em adio a essa comunidade de plug-ins que podem ser misturados e combinados para
construir um processo adaptado e possivelmente mais importante para o objetivo de ter um
processo que atenda as necessidades especficas de um projeto em particular a ferramenta
Eclipse Process Framework Composer que pode ser usado por autor de contedo in-house.
Modelos especficos da organizao podem ser integrados ao contedo do processo e novos
elementos do processo de checklists e orientaes novos papis, tarefas e produtos de
trabalho podem ser introduzidos.

Concluso
OpenUP um processo mnimo, completo e extensvel. Ele fomenta tcnicas e princpios geis,
enquanto tem um ciclo de vida estruturado comprovado que enfatiza a entrega contnua de
software de qualidade que leva valor aos stakeholders.

Referncias

Manifesto gil: http://agilemanifesto.org/iso/ptbr


Projeto Eclipse Process Framework: http://www.eclipse.org/epf

Autor
Ricardo Balduino engenheiro de software snior na IBM Rational e committer no projeto
Eclipse Process Framework. tambm arquiteto de contedo e desenvolvedor lder de
contedo para o OpenUP. Seus 13 anos de experincia na indstria de software incluem
desenvolvimento de software, treinamento e consultoria ajudando organizaes a customizar
e adotar as melhores prticas de desenvolvimento de software. Possui bacharelado em Cincia
da Computao pela Universidade Estadual de So Paulo, Brasil.

Tradutor
Daniel Ferreira um cara que um dia conheceu o Google Translator e agora se acha.