Rational Unified Process - RUP

http://linu.com.br/papers/paper042.html
Rational Unified Process - RUP
Antes da leitura deste estudo, recomendo a leitura dos itens sobre Modelos de Processo
de Software, cujo link está disponível na seção Referências.
O Rational Unified Process (RUP) é um modelo de processo de software mantido pela IBM
que fornece à equipe de desenvolvimento e aos gerentes de projeto uma alternativa
genérica para se construir um sistema de software. Por genérica, entende-se uma
alternativa adaptável à grande maioria dos casos de softwares.
O RUP fornece boas práticas, templates, orientações e diretrizes para melhorar o
desenvolvimento e para atender todas as atividades críticas no processo de
desenvolvimento do software.
Espera-se atingir um resultado satisfatório quando é utilizado um processo de software
coerente com a situação. A figura acima ilustra uma situação onde existe um cliente
portador de uma necessidade de desenvolvimento de software. Após um processo
complexo de elaboração do sistema de software, um produto é alcançado, atendendo
questões importantes como prazos, requisitos, custos e qualidade. Qual é a finalidade do
RUP? Fornecer uma maneira eficiente para se construir um sistema de acordo com as
necessidades do cliente.
O RUP sugere que os projetos utilizem como ferramenta de modelagem o UML.
Particularmente, com ou sem o RUP, as ferramentas da UML atendem a uma vasta gama
de sistemas. Não hesite em utilizá-las.
Um pouco mais sobre o RUP
Basicamente, o RUP apresenta três perspectivas para detalhar o processo de software.
São elas:
Perspectiva dinâmica: abordagem que trata o projeto em função do tempo,
considerando questões importantes como iteratividade – onde o projeto é direcionado
a partir de versões menores chamadas incrementos – e divisão de fases.
1.
Perspectiva estática: direciona o entendimento do projeto a partir de uma série de
disciplinas – ou workflows – associadas às fases dinâmicas, além de atividades de
apoio – necessárias em todo o projeto.
2.
Perspectiva prática: onde são definidas boas práticas a serem executadas em todos
os processos de software.
3.
Geralmente as perspectivas dinâmicas e estáticas são apresentadas em conjunto.
1 de 16 26/06/13 21:01

Observe a iteração das mesmas pela figura abaixo.
As fases e ciclos (iterações), associados à perspectiva dinâmica, estão dispostos
horizontalmente, enquanto as atividades estão representadas verticalmente – perspectiva
estática. Observe que não existe um critério fixo para a colocação de uma atividade em
determinada fase. De espera que, a partir do contexto apresentado na figura, as atividades
estejam mais associadas a determinados momentos no projeto, mas nada impede de
serem utilizadas em outro instante – outra fase.
Segundo o texto disponibilizado em http://www.wthreex.com/rup/, de onde também foi
retirada a figura, cada disciplina (atividade) está mais centrada em determinada fase. Veja
o texto original:
O gráfico Modelo de Iteração mostra como a ênfase em cada Disciplina varia
através do tempo. Nas Iterações iniciais, dedicamos mais tempo aos Requisitos. Já
nas Iterações posteriores, gastamos mais tempo com Implementação, por exemplo.
Vamos agora ao entendimento aprofundado de cada perspectiva.
Perspectiva dinâmica (divisão do tempo em fases)
Conforme explicado, a divisão do projeto no RUP ao longo do tempo é constituída por
fases. Cada fase precede um marco no projeto (representada pela linha tracejada na
figura), ou seja, terminado uma fase, espera-se alcançar alguns objetivos principais – e
conseqüentemente alcançar um importante marco. Além dos objetivos principais, uma
série de artefatos é pré-estabelecida juntamente com alguns critérios de avaliação do
sucesso da fase. Resumidamente, ao se utilizar o RUP, o processo de software é tratado
em fases que, quando finalizadas, atingem marcos, que serão validados através de
diretivas, e trarão uma série de produtos necessários para a próxima etapa.
Conforme mostrado na figura, as quatro fases são: Iniciação, Elaboração, Construção e
2 de 16 26/06/13 21:01

Transição.
Iniciação (Concepção)
Também chamada de concepção, a fase de iniciação consiste em estabelecer um business
case para o sistema. Você deve avaliar a contribuição do sistema para o negócio e a partir
daí, determinar se o projeto deve ou não continuar.
Nesta fase são analisadas todas as entidades externas ao sistema, tão como suas
associações, para se elaborar os objetivos, arquitetura e planejamento do projeto. Quem
possui essas informações? As entidades externas (mais conhecidas como stakeholders).
Como o próprio RUP sugere, esta fase poderá ser realizada em iterações até que se
encontre um nível respeitável de informações para estabelecimento dos objetivos gerais.
No final da fase de iniciação (ou concepção) encontra-se o marco mais importante do
projeto: marco dos Objetivos do Ciclo de Vida do projeto (LCO – Lifecycle Objetive).
Onde será respondida a pergunta: é válido realizar o projeto?
Neste marco, espera-se possuir os seguintes artefatos:
Visão: documentação dos requisitos, restrições e elementos chave do projeto. Este é
o documento de maior importância nesta fase.
1.
Riscos: identificar os ricos do projeto. Como em todo gerenciamento, saber onde se
está pisando é essencial, como também conhecer a amplitude e gravidade dos
riscos.
2.
Caso de Negócio: documento que contém as informações e suposições sobre o
retorno do investimento para responder a seguinte pergunta: é válido realizar o
projeto?
3.
Plano de desenvolvimento de software: documentação que identifica as fases iniciais
do projeto, tão como a duração e objetivo de cada uma. Devem também ser
especificadas estimativas do tempo, RH e custos envolvidos. Inicialmente esses
valores podem ser considerados brutos e poderão (deverão, talvez fosse o melhor
termo) ser reconstituídos nas próximas iterações desta fase, onde teremos maiores
informações sobre o projeto como um todo.
4.
Plano de iteração: Um conjunto de atividades e tarefas divididas por seqüências de
tempo, com recursos atribuídos e dependência de tarefas, para a iteração.
5.
Caso de desenvolvimento: processo no qual o projeto seguirá, ou seja, é uma
descrição do processo de desenvolvimento para servir de guia.
6.
Ferramentas: tudo que será necessário para o desenvolvimento do software,
considerando também a instalação e aquisição das mesmas.
7.
Glossário: termos importantes no projeto (uma espécie de índice que será utilizado
como referência).
8.
Todos os elementos descritos são necessários. Existem também alguns itens opcionais,
descritos adiante:
3 de 16 26/06/13 21:01

1. Casos de Uso: define um template para modelagem dos casos de uso.
2.
Modelo de Domínio: um modelo de objetos de negócio utilizado como uma extensão
do Glossário. Pode ser utilizado pelos interessados no negócio (stakeholders
primários ou secundários).
Templates dos Documentos: template para a geração dos documentos. A
padronização favorece a continuidade e o gerenciamento do projeto.
3.
Protótipos: os protótipos podem ser utilizados para melhor se compreender do
negócio a ser tratado pelo sistema, como também para compreender os clientes e
usuários e validar os requisitos.
4.
Observação: a literatura sugere que alguns artefatos sejam apresentados como baseline
(linha de base). A linha de base do RUP é uma imagem da versão de um artefato. Ou seja,
a linha de base é composta pela definição das versões dos artefatos que compõem o
produto em dado momento. Essa não é a mesma baseline presente na atividade
Desenvolvimento do Cronograma no Gerenciamento de Projetos (PMI) – mais
especificamente situada na área de conhecimento Gerenciamento de Tempo do Projeto,
sob o processo de Planejamento. Este baseline (PMI) é um cronograma que considera a
alocação dos recursos disponíveis, além do caminho crítico. Pelo fato dos termos serem
iguais, a confusão pode ocorrer. O baseline do PMI é similar ao artefato Plano de Iteração
– identificado nos itens acima. Já o baseline do RUP é associado à situação da versão dos
artefatos em determinado momento, quando é disponibilizada uma versão para o cliente.
Terminada a fase, resta-nos saber se ela foi proveitosa. Para isso utilizaremos os critérios
abaixo – opcionalmente, coloquei-os em formato de perguntas (Martins, 2007), pois o
cérebro, instintivamente, é mais estimulado quando se depara com uma pergunta do que
com uma afirmação.
Os stakeholders estão confiantes de que a equipe do projeto entendeu o problema a
ser resolvido?
1.
2. Os stakeholders estão confiantes de que os riscos mais críticos foram identificados?
3. As estimativas iniciais foram refinadas com base no conhecimento adquirido?
4. As estimativas de curso e prazo são aceitáveis para os stakeholders?
É importante ressaltar que o projeto será construído através de incrementos (ou pequenos
itens). Tais incrementos devem ser implementados pela ordem de prioridade estabelecida
pelos clientes/usuários. Não atendê-las ou documentá-las equivocadamente pode causar
insatisfação dos clientes em relação ao projeto (e à equipe do projeto).
Ao responder a essas perguntas, teremos maior confiança de que o trabalho realizado na
fase de Iniciação é confiável ou suficiente.
Elaboração
Na fase de Elaboração, o objetivo é capturar todos os requisitos ainda não identificados e
definir uma arquitetura sólida que permita a evolução do sistema nas fases seguintes
(Martins, 2007). Como principal objetivo, pode-se definir que a meta da fase de elaboração
é criar um baseline (do RUP) para a arquitetura do sistema fornecendo uma base estável
4 de 16 26/06/13 21:01

para a próxima fase, no caso, a fase de Construção.
Para se construir uma arquitetura confiável, protótipos da arquitetura podem ser
elaborados com o objetivo de obter uma visão abrangente do sistema, em relação ao
escopo, funcionalidades e requisitos não funcionais (chamados de atributos emergentes
não funcionais – confiabilidade, disponibilidade, segurança e proteção).
Um plano de projeto geral e realista para execução do restante do projeto deve ser
construído. Deve também ser estabelecido um ambiente de suporte para o projeto. A
avaliação do risco também é importante. Tratar todos os riscos significativos do ponto de
vista da arquitetura do projeto.
A fase de Elaboração termina com o marco Ciclo de Vida da Arquitetura (LCA –
Lifecycle Architecture). Ao atingir esse marco, pode-se entender que a arquitetura está
definida e os requisitos estão levantados e detalhados.
Os seguintes artefatos devem constar neste marco:
Protótipos: Protótipos da arquitetura podem ser criados a fim de explorar a
funcionalidade crítica e os cenários significativos. Inclusive, é plausível que a
arquitetura em si tenha sido construída com uma série de protótipos evolucionários.
1.
Lista de Ricos: Os novos ricos estarão associados à arquitetura e conseqüentemente
ao gerenciamento de requisitos não funcionais. Ela é uma atualização e revisão dos
riscos identificados na fase anterior.
2.
Caso de Desenvolvimento: Atualização do artefato já elaborado, aqui considerando
questões sobre o ambiente de desenvolvimento, ferramentas e processo.
3.
4. Ferramentas: As ferramentas pertinentes ao trabalho de Elaboração são instaladas.
5.
Documento de Arquitetura de Software: Fornece uma visão geral de arquitetura
abrangente do sistema. Deve conter uma descrição detalhada para os casos de usos
significativos para a arquitetura, e elementos de design (elementos lógicos a serem
definidos como linguagem de programação e banco de dados).
Modelo de Design: Descreve a realização dos casos de uso e de forma abstrata,
serve como guia para o modelo de implementação. Realizações de caso de uso para
cenários significativos do ponto de vista da arquitetura foram definidos.
6.
Modelo de Dados: O modelo de dados é um subconjunto do modelo de
implementação que descreve a representação lógica e física dos dados persistentes
no sistema. Também abrange qualquer comportamento definido no banco de dados,
como procedimentos armazenados, triggers, restrições etc. Este artefato deve ter
sido criado e com baseline.
7.
Modelo de Implementação: Conjunto de componentes (que incluem produtos
liberados – executáveis – elementos dos quais os produtos foram criados – código
fonte). A estrutura inicial deverá ser criada, com ou sem a adoção de protótipos.
8.
Visão: Atualização da visão elabora com foco na compreensão sólida dos casos de
uso mais críticos que conduzem as decisões de arquitetura e planejamento.
9.
5 de 16 26/06/13 21:01

Plano de Desenvolvimento de Software: Atualizar o plano existente com objetivo de
abranger as próximas fases.
10.
Modelo de Casos de Uso: um modelo de casos de uso praticamente concluído.
Estima-se que neste ponto o modelo esteja 3/4 do modelo conclusivo.
11.
Especificações Suplementares: Os requisitos suplementares abrangendo os
requisitos não funcionais são documentados e analisados. Conforme a literatura de
Engenharia de Software, requisitos não funcionais (ou atributos não funcionais)
dizem respeito a características pertinentes à confiança do software quando
integrado (após a fase de integração de subsistemas). Pode-se definir a confiança de
software com base em: disponibilidade (capacidade do sistema de estar disponível
quando requisitado), confiabilidade (capacidade do sistema de operar de acordo com
os requisitos), segurança (capacidade do sistema de operar sem falhas catastróficas)
e proteção (capacidade do sistema de proteger-se de intrusões acidentais ou
intencionais). Mais informações em Sommerville, 2007. Outras abordagens coerentes
para requisitos não funcionais podem ser vistas nas Referências.
12.
Conjunto de Testes: Testes implementados e executados para validar a estabilidade
do build para cada release executável criada nesta fase.
13.
Arquitetura para Automatização de Testes: É uma composição de diversos elementos
de automatização de testes e suas especificações que representam as
características fundamentais do sistema de software de automatização de testes
(Wthreex, em Referências).
14.
Além dos artefatos descritos anteriormente, existe aqueles opcionais:
Caso de Negócio: Atualizado para os casos onde existam elementos descobertos
que influenciem o caso de negócio estabelecido.
1.
Modelo de Análise: Pode ser desenvolvido como um artefato formal, que através da
evolução, poderá servir como a versão inicial do Modelo de Design.
2.
Materiais de Treinamento: Manuais do Usuário e outros materiais 3. de treinamento.
4. Templates Específicos do Projeto: Padrão para a criação dos documentos do projeto.
Ao atingir o marco LCA, podemos avaliar sua consistência e confiabilidade através das
seguintes perguntas:
Os stakeholders têm confiança de que a equipe do projeto tem capacidade de
implementar a solução proposta?
1.
2. A arquitetura reflete os requisitos funcionais (funções que o sistema deve fornecer)?
3. Todos os riscos críticos foram eliminados ou mitigados?
4. As variações de custo e prazo são aceitáveis para os stakeholders?
5. A fase de Construção foi planejada de forma consistente e detalhada?
Conforme definido, a fase de Elaboração pode ser entendida como um processo de
engenharia, onde o foco é especificar uma arquitetura robusta e confiável. Através dos
6 de 16 26/06/13 21:01

critérios de avaliação (perguntas) acima, podemos esperar que um resultado satisfatório foi
alcançado.
Construção
Na fase de construção, o sistema e a documentação destinada ao usuário são criados,
junto com a versão beta do sistema (Martins, 2007). Nesta fase também serão
esclarecidos os requisitos restantes. Toda a construção do sistema terá com base a
arquitetura da baseline.
O controle de recursos, custos e qualidade fazem parte deste processo. As fases da
concepção e elaboração foram auxiliadas por gerenciamento da propriedade intelectual.
Na fase de Construção, o foco estará no desenvolvimento dos produtos que serão
construídos.
Espera-se atingir versões úteis com eficiência. As atividades devem ser coordenadas de
forma que o paralelismo esteja presente. Mesmo em projetos pequenos, é possível
coordenar as equipes para que os componentes independentes sejam elaborados em
paralelo.
Ao concluir esta fase, chegaremos ao marco Capacidade Operacional Inicial (IOC –
Initial Operational Capability). Espera-se neste momento que o produto esteja pronto
para ser passo a equipe de Transição e que os testes alfa estejam concluídos (teste alfa
consiste em testes de aceitação informal, onde os procedimentos de execução do teste
não são definidos).
Os seguintes artefatos são esperados:
O Sistema: o sistema executável pronto para começar o teste beta (teste não
formalizado geralmente realizado pela comunidade de usuários).
1.
Plano de Implantação: plano que coordena e lista as atividades envolvidas na
transferência do sistema da comunidade de desenvolvimento para a comunidade de
usuários. Deve-se criar um plano inicial com baseline.
2.
Conjunto de Testes: Testes implementados e executados de cada release construído
durante esta fase.
3.
4. Materiais de Treinamento: Manuais do usuário e outros materiais de treinamento.
5.
Plano de Iteração: Plano de iteração para a próxima fase (Transição), concluído e
analisado.
Modelo de Design: Atualizado com novos elementos de design identificados durante
a conclusão de todos os requisitos.
6.
Caso de Desenvolvimento: Trata-se do refinamento do ambiente de desenvolvimento
– processo e ferramentas – com objetivo de auxiliar a equipe da próxima fase.
7.
8. Ferramentas: Ferramentas da fase de Construção.
9.
Modelo de Dados: Atualizado com a experiência adquirida no processo de
Construção.
7 de 16 26/06/13 21:01

Além dos artefatos obrigatórios descritos anteriormente, a fase de Construção também
possui alguns artefatos opcionais, que são:
Templates Específicos do Projeto: Os templates de documentos usados para
desenvolver os artefatos de documentos.
1.
Especificações Suplementares: Atualizar as especificações já existentes caso sejam
descobertos novos requisitos não funcionais.
2.
Modelo de Casos de Uso: Atualizado com os possíveis novos casos de usos
descobertos durante essa fase.
3.
A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação
descritos abaixo. O formato em perguntas persiste:
O produto está completo o suficiente e com a qualidade mínima aceitável para iniciar
o teste de aceitação?
1.
O usuário e a organização estão preparados para o início da implementação
(transição do sistema)?
2.
As variações de custo e prazo são aceitáveis 3. para os stakeholders?
O processo de Construção pode ser compreendido como um processo de manufatura.
Obviamente o gerenciamento será adaptado para tal situação, levando em questões
elementos como prazos, custos e recursos. Esta fase, assim como todas as outras do
RUP, deve abordar a iteratividade, apresentando incrementos (releases do sistema) ao
final de cada repetição. É estimado um esforço de programação por volta de 1/2 em
relação ao projeto como um todo. Geralmente esta fase consome mais recursos e tempo,
mas seu sucesso estará associado às questões bem (ou mal) resolvidas nas etapas
anteriores. Certamente, o impacto dos riscos não descobertos (ou não avaliados) serão
maiores nesta etapa.
Ao terminar essa fase, o sistema poderá ser transferido para os usuários.
Transição
Em síntese, o foco da fase de Transição é assegurar que o software esteja disponível para
seus usuários finais. Ele deverá ser distribuído, ou seja, instalado para os clientes e
usuários finais. É comum a continuidade do desenvolvimento do software demandado por
feedback dos usuários. Deverão ser fornecidos, a cada ciclo da Transição, novos releases
do produto. Existe também a possibilidade de que o fim do ciclo de vida do produto do
projeto coincida com o início de outro ciclo de vida para o mesmo produto – como uma
nova versão do software, por exemplo.
A complexidade inerente nesta fase varia de acordo com o produto e cliente. Um software
comercial para uma nova microempresa pode gerar poucos problemas nesta etapa, ao
passo que a substituição de sistemas previdenciários de um país pode levar anos para ser
concluída.
É interessante que nesta fase, sejam definidas metas de acordo com o andamento do
processo. Por exemplo, a alteração de uma falha de sistema pode envolver retrabalho na
programação e teste. Ao passo que a correção de um requisito possa levar a um processo
8 de 16 26/06/13 21:01

similar ao de Construção.
Ao final desta fase, encontra-se o marco Release do Produto (PR – Product Release). O
principal aspecto centra-se na avaliação dos objetivos, se foram ou não atendidos, e na
decisão de iniciar um novo processo de Construção com base nesses objetivos.
Os artefatos envolvidos neste marco são:
O Build do Produto: deve ser fornecido um sistema concluído de acordo com os
requisitos do produto, onde o consumidor final utiliza o sistema.
1.
Notas de Release: As Notas de Release identificam mudanças e erros conhecidos
em uma versão de um build ou em uma unidade de implantação que tenha sido
disponibilizada para uso (texto retirado da Referência). As notas devem estar
concluídas.
2.
Artefatos de Instalação: elementos de instalação do software, como também a
documentação associada.
3.
Material de Treinamento: O material deve estar concluído. A partir dele o cliente
poderá utilizar o sistema.
4.
Material de Suporte para o Usuário Final: Material que colabora com a
aprendizagem, manutenção e utilização do sistema.
5.
Existem também os artefatos opcionais:
Conjunto de Testes: O conjunto de teste associado em cada build poderá ser
fornecido ao cliente.
1.
Empacotamento Compacto do Produto: Elementos fornecidos ao cliente com intuito
de auxiliar o processo de compactação do produto.
2.
Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da
fase de Transição.
Os objetivos do projeto foram atingidos de acordo com os 1. critérios de medição?
2. As variações de custo e prazo são aceitáveis pelos stakeholders?
3. Os usuários estão satisfeitos?
Ao final da fase de transição, espera-se que um ciclo do projeto, ou o projeto em si, tenha
chegado ao fim. Geralmente, conforme mostrado na figura abaixo – retirada das
Referências, o comportamento típico para um processo de software evolui e consome
recursos de forma distinta para cada fase.
9 de 16 26/06/13 21:01

Como se pode ver, o tempo e recurso da Iniciação (Concepção) são significativamente
menores do que o da Elaboração e Construção. A Transição está diretamente associada
às características do projeto, porém espera-se que consuma menos tempo que a
Construção.
Podemos observar o seguinte: projetos mal estruturados e pouco documentados, onde a
análise e o gerenciamento foram negligenciados por pressões dos clientes/gerentes do
projeto tornam o processo de Transição extremamente doloroso, onde muitas alterações e
inclusões de requisitos devem ser realizadas. Na fase de Transição, a correção de falhas
de sistema ou adaptação de requisitos devido a mudanças no escopo do produto é
aceitável, porém a inclusão de requisitos que não foram capturados ou não documentados
pela falta de coordenação e confiança nas fases de Iniciação e Elaboração é altamente
prejudicial ao projeto. Isso é muito comum no desenvolvimento de software atual, mesmo
existindo ferramentas e modelos de processo altamente suficientes para contornar tais
problemas. Em casos como esses, ciclos completos (com as quatro fases) no projeto
talvez sejam necessários.
Vale relembrar que os ciclos são previstos no RUP. Cada fase do projeto poderá ser
repetida várias vezes. Inclusive as quatro fases podem ser repetidas, fornecendo
incrementos (ou versões) em cada ciclo. O processo de desenvolvimento em fases é
comum nos projetos atuais, seja na forma de desenvolvimento iterativo ou por incremento.
No primeiro caso, o desenvolvimento iterativo fornece inicialmente um esqueleto do
sistema, que será aperfeiçoado em cada fase. O esqueleto, porém, não traz confiabilidade
nos requisitos de forma satisfatória. Isso será conquistado ao longo do processo. A figura
abaixo ilustra este tipo de desenvolvimento.
Neste gráfico, os itens em branco foram apresentados de forma genérica, ainda sem
contemplar as reais necessidades do negócio. Os itens em amarelo já foram ajustados aos
requisitos. Observe que na Fase 1, apenas o módulo 2 é apresentado com coerência nos
10 de 16 26/06/13 21:01

requisitos, enquanto os módulos 1 e 3 ainda são soluções paliativas para o problema
- mas já podem ser utilizadas. Este contexto é comum para sistemas ERP, onde um grande
sistema coorporativo (e pode-se dizer, genérico) existe e aos poucos é adaptado a
realidade das empresas. Um exemplo típico é o sistema SAP/R3.
No desenvolvimento por incrementos, cada módulo é entregue em separado, sem um
esboço geral do sistema, porém atendendo a real necessidade dos requisitos analisados.
Neste caso, o projeto desenvolverá o módulo 2 na primeira fase – isso porque a empresa
cliente justificou que este incremento é o de maior prioridade para o negócio. Ao longo dos
próximos ciclos, os outros módulos, também em ordem de prioridade, serão apresentados.
A vantagem deste paradigma centra-se na qualidade alcança nos incrementos de maior
importância. Como o cliente estipulou que o módulo 2 é de maior prioridade, este foi
desenvolvido na íntegra, primeiro e, conseqüentemente, sofrerá maior carga de testes e
validações dos requisitos se comparado com o módulo 1, que foi o último a ser entregue.
As figuras apresentadas acima, que define o desenvolvimento iterativo e incremental,
foram criadas por Flávio Mello, professor da UFRJ. Em uma aula que pude presenciar sua
explicação ele abordou tais temas por meio dessas figuras. Achei interessante abordá-las
aqui também.
Veremos agora a perspectiva estática do RUP.
Perspectiva Estática
A visão estática do RUP enfoca as atividades que ocorrem durante o processo de
desenvolvimento. Elas são chamadas de workflows na descrição do RUP. Existem seis
workflows de processo principais identificados e três workflows de apoio principais
(Sommerville, 2007). Um workflow também é chamado de disciplina. Utilizaremos as duas
formas para identificá-los, como prática comum em tais abordagens.
Ao longo do projeto você precisa construir artefatos (um nome elegante para documento,
com alguma particularidade, do sistema). No RUP você constrói os artefatos por meio das
atividades. Uma disciplina (workflow) mostra todas as atividades que você deve realizar
para construir alguns artefatos.
As disciplinas não são temporais ou fixas nas fases. Isso significa que eu posso utilizar a
disciplina de Requisitos na fase de Construção, mesmo que esta esteja naturalmente mais
associada à fase de Concepção. Isso é válido para todas as disciplinas. Para enfatizar
esse entendimento, por conveniência, repeti aqui o gráfico da disposição das disciplinas ao
longo das fases do projeto.
11 de 16 26/06/13 21:01

Observe que elas são demandadas com maior ênfase em determinado momento, porém
nada impede que sua utilização seja realizada em outras fases. As três disciplinas de
apoio Gerenciamento de Configuração e Mudança, Gerencimanto de Projeto e Ambiente
são mais distrubuídas por todas as fases, sem apresentar nenhum pico significativo. Isso é
comum à tais disciplinas, pois como a própria descrição sugere, elas servem de apoio para
todas as outras disciplinas e para o projeto como um todo.
Veremos agora uma abordagem sobre cada uma das disciplinas. Em primeiro plano,
veremos os seis workflows principais.
Modelagem de Negócios
Os processos de negócios são modelados utilizando casos de uso de negócios
(Sommerville, 2007). Em sintese, a modelagem de negócios se preocupa na descrição do
negócio, identificação dos processos e no desenvolvimento do modelo de domínio,
realizando refinamentos, projeções dos processos e levantamento dos papéis envolvidos.
Essa disciplina é mais comum nas fases de Iniciação e Elaboração, porém é comum ser
repetida nos projetos em que os requisitos sofrem alterações constantemente.
Requisitos
Trata principalmente da definição formal dos requisitos. Para novos sistemas, o problema é
analisado com o objetivo de identificar os indivíduos, as fronteiras e restrições. Em casos
onde já exista um sistema, os envolvidos são identificados com objetivo de conhecer
melhor suas necessidades. Com base nos dados levantados, o sistema é definido, o
escopo é elaborado e os requisitos mutáveis são gerenciados. Possui maior participação
na fase de Iniciação e é normalmente utilizada durante toda a fase de Elaboração.
Análise e Design (ou Análise e Projeto)
Um modelo de projeto é criado e documentado usando modelos de arquitutura, modelos
de componente, modelos de objeto e modelos de seqüência (Sommerville, 2007). Em
12 de 16 26/06/13 21:01

primeiro momento uma sugestão de arquitetura é definida. Posterioremente, em paralelo
com o refinamento da arquitetura, os comportamentos são analisados com o objetivo de
projetar os componentes e o banco de dados do sistema. Está concentrada na fase de
Elaboração e geralmente é refinada e ajustada na fase de Construção.
Implementação
Apesar de sua maior concetração na fase de Construção, a implementação está presente
em todos os momentos. Na fase de Concepção os protótipos poderão facilitar o
entendimento dos requisitos. Na fase de Elaboração, esboços da arquitutura poderão
evoluir até que um nível satisfatório seja alcançado e que um protóripo para a arquitetura
seja construído. Na fase de Transição, correções de falhas no sistema e ajustes são
freqüentes. Na fase de Construção, em geral é definido um modelo de implementação e
integração. Os subsistemas são construídos em forma de incrementos e integrados nos
ciclos. A cada nova integração, os componentes individuais são testados, e existe um
refinamento dos artefatos construídos, se necessário. A geração automatica, comum em
ferramentas CASE, também pode ser utilizada neste momento.
Teste
Segundo Sommerville, o teste é um processo iterativo realizado em conjunto com a
implementação. O teste do sistema segue o término da implementação. Os testes devem
ser formalizados com o objetivo de identificar o foco adequado do esforço de teste para a
iteração e estabelecer consenso com os envolvidos sobre as metas correspondentes que
conduzirão o esforço de teste (Wthreex). Possui maior ênfase no final da fase de
Construção.
Implantação
Nesta disciplina uma versão do produto é distribuída. Como previsto, sua maior utilização
está centrada no marco PR (entre a fase de Construção e Transição). O teste de aceitação
também precisa ser considerado. Artefatos como material de suporte precisão ser
disponibilizados.
Veremos agora os três workflows de apoio.
Gerenciamento de Configuração e Mudanças
Gerencia as mudanças do sistema. Tarefas como Gerenciar Solicitações de Mudanças,
Gerenciar Baselines e Releases e Planejamento de Controle do Projeto e Configuração de
Mudanças são pertinentes e devem ser utilizadas. Apesar de suportar todo o projeto,
possui mais demanda nas fases de Construção e Transição.
Gerenciamento de Projetos
Possui a característica de gerenciar o desenvolvimento do sistema. É uma disciplina ampla
e deve ser considerada com atenção. A gerência de projetos é comum em diversos
ambientes e possui referências importantes de mercado como o PMI. Recomendo leituras
associadas ao Gerenciamento de Projetos para sua aplicação e utilização especializada
neste workflow. O próprio RUP, um modelo genérico de processo de software, espera que
exista uma abordagem empresarial do gerenciamento do projeto em sua estrutura. Deve
ser utilizado em todas as fases.
13 de 16 26/06/13 21:01

Ambiente
Este workflow está relacionado à disponibilização de ferramentas de software apropriadas
para a equipe de desenvolvimento (Sommerville, 2007).
Cada projeto possui sua particularidade. Em determinados casos, existirão maiores
demandas de certos workflows para as fases iniciais, em quanto em outros, a maior
atenção ocorrerá nas fases finais. Os dados mostrados neste documento e sugeridos na
literatura sobre o assunto mostram aplicações corriqueiras para associar as disciplinas às
fases. Mas o fato de serem tratadas como perspectivas dinâmicas e estáticas propõem
justamente que não existam restrições nas suas combinações durante o projeto.
Perspectiva Prática
A adoção de boas práticas no desenvolvimento de software favorece o andamento do
projeto e contribuí para o sucesso e aceitação do produto final. A perspectiva prática
mostra justamente algumas práticas recomendadas no processo de software. São elas:
Desenvolvimento Iterativo: característica já abordada neste estudo que indica que o
software deve ser desenvolvido em incrementos, entregues em ordem de prioridade
definida pelo cliente.
1.
Gerenciar Requisitos: Documentação formal dos requisitos e acompanhamento das
mudanças. Sempre que houver solicitações de mudanças, avaliar o impacto no
projeto antes da aceitação formal.
2.
Arquiteturas Baseadas em Componentes: o uso de arquiteturas baseadas em
componentes, externos ou produzidos no projeto, facilita a produção do sistema.
Deve ser considerada tal característica.
3.
Modelagem Visual: Utilizar modelos da UML para representar o software de forma
estática e dinâmica. Conforme indicado, o RUP sugere a utilização da UML em seus
projetos. Este item reforça isso.
4.
Verificar a Qualidade do Software: A qualidade do software deve ser monitorada e
conduzida de forma a atender os padrões de aceitação do cliente. Isso influenciará o
sucesso do projeto.
5.
Controlar as mudanças do software: As mudanças deverão ser gerenciadas durante
todo o processo. Isso contribuirá para um projeto melhor estruturado, documentado e
para sua continuidade e aceitação.
6.
Conclusões
Neste documento, mostrei uma simplória abordagem sobre o modelo de processo de
software RUP e sua importância num projeto. Minha intenção principal é apresentar o
paradigma de desenvolvimento de forma conceitual. O RUP completo apresenta
templates, entendimento dos papeis e suas importâncias, ferramentas, entre outros.
Abordagens mais coerentes e completas deverão ser consultadas para fins de utilização
específica. Recomendo que seja acessado o site Wthreex, cujo link encontra-se nas
Referências, pois tal material é apresentado de forma completa e bem estruturada. A partir
dos elementos deste site você poderá realizar seu processo de software utilizando todos
14 de 16 26/06/13 21:01

os elementos presentes no RUP e, possivelmente, alcançar o sucesso do projeto.
Termino esse texto com uma reflexão simples, mas que serve de exemplo para aqueles
que ainda resistem à utilização de processos que possam auxiliar o desenvolvimento do
software.
Compare o desenvolvimento de software com o preparo de macarrão. Podemos preparar o
macarrão de duas formas: a forma recomendada diz que devemos ferver a água, colocar o
macarrão para cozinhar, verificar ao longo do processo se o mesmo já está pronto e por
fim, colocar o molho. Existe também a forma fácil, onde se coloca a água, o macarrão e o
molho tudo ao mesmo tempo e vai assistir televisão até que ele fique pronto. O primeiro
método trará um excelente macarrão, mas muitas pessoas não gostam de utilizá-lo, pois
acham uma perda de tempo (este é o meu caso, por exemplo). O segundo método tem
como resultado uma gororoba braba, porém é mais fácil de atingi um resultado (ruim,
porém mais rapidamente). Minha pergunta é: se seu trabalho fosse o de produzir macarrão
para clientes e seu dinheiro dependesse da satisfação dos mesmos, qual dos dois
métodos você utilizaria?
Então porque você insiste em produzir softwares negligenciando os processos de
requisitos, documentação, análise e gerenciamento de projeto, se o resultado será, em
geral, uma porcaria!
Referências
http://en.wikipedia.org/wiki/Work_breakdown_structure
http://www.wthreex.com/rup/
http://pt.wikipedia.org/wiki/Rational_Unified_Process
http://pt.wikipedia.org/wiki/Stakeholder
http://www.algosobre.com.br/portugues/usos-do-porque.html (afinal, errar é humano, mas
corrigir o erro no Google também)
http://www.macoratti.net/proc_sw1.htm
http://pt.wikipedia.org/wiki/Engenharia_de_software
http://wthreex.com/rup/process/workflow/requirem/co_req.htm
http://www.wthreex.com/rup/process/workflow/test/co_accte.htm
Ian Sommerville, 2007. Engenharia de Software, 8ª edição. Pearson Addison-Wesley.
José Carlos Cordeiro Martins, 2007. Técnicas para Gerenciamento de Projetos de
Software. Brasport.
“São as nossas escolhas que revelam o que realmente somos, muito mais do que as
nossas qualidades.” Alvo Dumbledore
15 de 16 26/06/13 21:01

Espero ter colaborado com algo!
Guilherme Pontes
16 de 16 26/06/13 21:01

Rational Unified Process - RUP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Rational Unified Process - RUP

Similar to Rational Unified Process - RUP (20)

More from Fernando Nogueira

More from Fernando Nogueira (7)

Rational Unified Process - RUP