Processo Unificado e Processo Unificado Racional (UP e RUP)

Universidade Federal Fluminense (UFF)
Pólo Universitário de Rio das Ostras (PURO)
Ciência da Computação

Welton Luiz de Oliveira Barbosa¹
Carlos David Pasco¹

¹Instituto de Ciência e Tecnologia
Processo Unificado

1- Introdução
Processo: Ato de proceder, de ir por diante; Sucessão de estados ou de mudanças; Modo por que se realiza ou executa uma coisa; método, técnica. [Dicionário Aurélio]
Por essa definição, podemos identificar o porquê do Processo Unificado ser chamado de processo.
O Processo unificado surgiu como uma nova proposta de desenvolvimento, fugindo do modelo em cascata, seguindo basicamente as mesmas etapas genéricas de desenvolvimento de software, porém visando um desenvolvimento iterativo e incremental, totalmente diferente do modelo em cascata.
O RUP nasce da captura das melhores práticas de desenvolvimento de software, visando dar resposta satisfatória aos diversos problemas inerentes a atividade.
Segundo Grady Booch estas são algumas causas de problemas no decorrer de um projeto de software:
Gerenciamento especial de requisitos
Comunicação ambígua e imprecisa
Arquiteturas frágeis
Complexidade subjugada
Inconsistências não detectadas em requisitos, construções e implementações
Teste insuficiente
Avaliação subjetiva de status do projeto

As melhores práticas são abordagens experimentadas comercialmente e com comprovado sucesso. Usadas em combinação, atacam as origens de problemas no desenvolvimento de software. São elas:

1. Desenvolver software iterativamente.
2. Gerenciar requisitos.
3. Usar arquiteturas baseadas em componente.
4. Modelar visualmente o software.
5. Verificar continuamente a qualidade de software.
6. Controlar mudanças do software.

Esse processo, por ter sido "criado" pelos mesmos nomes da UML, faz um amplo uso desta, durante suas etapas de desenvolvimento de software.
É um processo ágil, com isso, visa à liberação constante de versões de software para o usuário, tendo como objetivo não só a documentação, mas também a construção de artefatos de software, logo após o reconhecimento dos principais requisitos.

2- Histórico
No início da década de 90 surgiu o conceito de orientação a objeto (OO). Junto ao conceito surgiram inúmeras propostas de modelos de análise orientada a objetos (AOO) e projeto orientado a objetos (POO).
Essa quantidade de propostas gerava discussões sobre qual modelo seria o melhor (AOO ou POO). Além do mais, era difícil ocorrer um bom entendimento entre equipes de desenvolvimento, por raramente usarem os mesmos modelos de desenvolvimento OO.
Houve então uma proposta de criação de um modelo unificado entre três (3) grandes nomes da área de engenharia de software, James Rumbaugh, Grady Booch e Ivar Jacobson. Como resultado dessa união surgiu a Unified Modeling Language (UML), servindo como uma norma entre as empresas de desenvolvimento de software. Porém a UML servia como uma ferramenta auxiliadora nas etapas da engenharia de software e não como um molde (esqueleto) a ser seguido no desenvolvimento de sistemas OO.
Durante alguns anos decorridos do surgimento da UML, os mesmos criadores desenvolveram o Processo Unificado (PU). Este sim passou a servir como um modelo a ser seguido durante as etapas de desenvolvimento de grandes sistemas OO. O PU propôs o modelo iterativo e incremental, deixando o software com mais robusto na medida em que o tempo passa.
Atualmente o PU e a UML são amplamente usados em conjunto por empresas desenvolvedoras de software OO. O modelo iterativo e incremental do PU deve ser adaptado para satisfazer às necessidades específicas do projeto.
3- Princípios
3.1- Dirigido por casos de uso
Indicam as funcionalidades a serem cumpridas pelo sistema, podendo gerar mais de uma funcionalidade.
Auxiliam na construção do modelo de análise e de projeto. Depois, na etapa de testes. Com isso podemos perceber a expressão "dirigido por casos de uso", pois está presente em todas as etapas de desenvolvimento de software.
3.2- Centrado em arquitetura
A arquitetura representa visões de como o sistema poderá ser desenvolvido, juntamente com a informação de com quais outros sistemas ele irá interagir (caso esses existam).
Proporciona-nos um entendimento generalizado do sistema, facilita a possibilidade de reuso e a evolução do sistema. Também são baseadas nos casos de uso.
3.3- Iterativo e Incremental
Geralmente subdivide o sistema
As partes divididas do sistema são as iterações e essas resultam nos incrementos (versões) de software. Cada incremento faz parte de uma etapa do modelo evolucionário

4- Fases do Processo Unificado
Existem cinco (5) atividades base para descrever qualquer modelo de processo de software. A figura a seguir mostra todas essas fases.

Figura 1: Fases do Processo Unificado

4.1- Fase de Concepção
Está é a fase onde ocorre a atividade de comunicação com o cliente e de planejamento. Nela é realizada a obtenção dos requisitos, as regras de negócio e é identificada também uma breve arquitetura do sistema (com quais outros sistemas o software irá interagir, como por exemplo).
Os requisitos são obtidos por meio da criação de cenário, com usuários finais e com o cliente (que raramente será a mesma pessoa). A partir do cenário são criados os casos de uso principais do sistema a ser desenvolvido.
No planejamento são identificados os recursos, avaliam-se os principais riscos, define um cronograma e criam-se marcos para as fases de aplicação de acordo com o desenvolvimento incremental do software.
4.2- Fase de Elaboração
Concebe a etapa de planejamento e de modelagem (figura 1). Nela são refinados e expandidos os casos de uso definidos na fase de concepção, incluso, está o refinamento e expansão do modelo de arquitetura para a criação do modelo de análise, o modelo de projeto, o modelo de implementação e o modelo de implantação.
4.3- Fase de Construção
A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição.
É nesta fase onde os casos de uso tornam-se operacionais. Através do modelo arquitetural são obtidos ou desenvolvidos cada componente de software necessário para o desenvolvimento operacional dos casos de uso. Para tornar possível, os modelos de analise e de projeto são melhores desenvolvidos, refletindo a versão final do incremento, para então servirem como auxiliadores na construção.
Tendo todas essas características, serão implementados códigos-fonte que tornarão os casos de uso funcionais. Com o decorrer da implementação, serão realizados teste sobre esses códigos.
Nesta fase, tem como meta otimizar custos, programações e qualidade, a partir de um bom gerenciamento de recursos.
4.4- Fase de Transição
Concebe a última etapa da fase de construção e a primeira voltada a implantação. Nesta fase o software é levado ao usuário final para este realizar testes no mesmo. Criam-se manuais do software, informações de "help" para o usuário, etc. Ao seu final, fecha-se um ciclo do modelo incremental, criando uma versão do software.
4.5- Fase de Produção
É coincidente com a etapa de implantação. Nesta fase o uso do software é acompanhado, além de serem coletados os relatórios de erro, solicitações de modificações e colaboração com o usuário durante o uso (nos primeiros dias de uso).
Ao contrário do modelo em cascata, pode ser provável que no tempo em que as fases de construção, transição e produção de um ciclo, estejam acontecendo em concorrência com a fase de concepção do próximo incremento.

5- Produtos de Trabalho do Processo Unificado (PU)
Na Fase de Concepção são identificados os requisitos, os casos de uso e são definidos os riscos. Esses produtos gerados, no entanto, não estão 100% definidos.
A Fase de Elaboração refina o modelo de casos de uso, define requisitos, cria um projeto e uma descrição arquitetural preliminar. São definidas as classes de análise, após, o modelo de análise e depois um modelo de projeto. Também são revisados os riscos e o plano do projeto.
Fase de Construção, onde é feita a implementação do software, juntamente com o modelo de implantação do sistema. E como parte final dessa fase, são realizados testes para verificar o cumprimento e a exatidão dos casos de uso.
Por fim, a Fase de Transição entrega a versão do incremento de software e acompanha os primeiros passos do usuário com o software, recebendo relatórios de erro e modificações requeridas.
6- O Rational Unified Process
RUP se mostra um processo que pode ser usado exatamente como é, ou ser perfeitamente "personalizado", podendo ser modificado, ajustado e expandido para acomodar necessidades, características, restrições e história da empresa, cultura e domínio no qual esteja sendo utilizado.

6.1 - Elementos do processo

Um processo descreve quem está fazendo o quê, com e quando. RUP possui quatro elementos primários de modelagem.
Trabalhador se refere aos papéis desempenhados por pessoas. O trabalhador define o comportamento e as responsabilidades de um indivíduo ou grupo de indivíduos que trabalham juntos como uma equipe.
Atividade é uma unidade do trabalho que um indivíduo naquele papel pode ser pedido a desempenhar. A atividade tem um propósito claro, normalmente expresso em termos de criar ou atualizar artefatos, como um modelo, uma classe ou um plano.
Artefato é um pedaço de informação que é produzida, modificada ou usada por um processo. Os artefatos são os produtos tangíveis do projeto, o que o projeto produz ou usa para o produto final.
Fluxos definem uma sequência de atividades que produzem algum resultado de valor observável. RUP possui nove fluxos centrados no processo, sendo seis fluxos centrados na engenharia e três de suporte.
Os fluxos de engenharia são:
Fluxo de modelagem de negocio
Fluxo de requisitos
Fluxo de análise e projeto
Fluxo de implementação
Fluxo de teste
Fluxo de distribuição
Os fluxos de suporte são:
Fluxo de gerenciamento de projeto
Fluxo de configuração e gerenciamento de mudança
Fluxo de ambiente

Cada um desses fluxos cobre determinado aspecto do sistema.

6.2 - A arquitetura e seu papel fundamental no RUP

Grande parte do RUP focaliza a modelagem. A modelagem nos ajuda a dominar um sistema grande, complexo e que não pode ser facilmente compreendido em sua totalidade.
Precisamos de modelos múltiplos para focalizar preocupações diferentes. Para que os trabalhadores do processo possam:
Entender o que o sistema faz
Entender como o sistema funciona
Poder trabalhar num pedaço do sistema
Estender o sistema
Reutilizar parte do sistema para construir outro

Quando fazemos isso em uma quantidade limitada de espaço, acabamos por fim fazendo uma descrição da arquitetura do sistema. "Arquitetura é o que resta quando você não puder fazer mais coisa nenhuma e ainda puder entender o sistema e explicar como funciona".



7- Vantagens
É um método evolucionário de desenvolvimento de software.
O usuário não espera até a conclusão do projeto para ter contato com o software, devido ao modelo incremental.
Após o termino do desenvolvimento é muito difícil encontrar novos erros.
...

8- Desvantagens
Podem ocorrer divergências entre a documentação e o software.
Pode entrar em loop devido ao modelo iterativo e incremental, dependendo do cliente para chegar ao fim do projeto.
Aumento de gastos devido à implantação da versão a cada incremento.
Pode gerar uma grande mudança em parte(s) já desenvolvida(s) para realizar algum novo requisito incremental.
...





Bibliografia
PRESMAN, Roger S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw Hill, 2006.
KRUCHTEN, Philippe. Introdução ao RUP ? Rational Unified Process. Rio de Janeiro: Ciência Moderna, 2003.
SOUZA NETO, Plácido Antônio de. Processo Unificado ? Visão Geral. Disponível em <www.cefetrn.br/~placido/ensino/mossoro/aoo/material/UP.pdf>. Acesso em 2011.
Unified Process - Wikipedia, the free encyclopedia. Disponível em: <http://en.wikipedia.org/wiki/Unified_Process>. Acesso em 2011.
MASSONI, Tiago Lima. Introdução ao Processo Unificado de Desenvolvimento de Software. Disponível em: < http://www.cin.ufpe.br/~phmb/RUP/MaterialDeEnsino/VisaoGeralDoCurso.ppt>. Acesso em 2011