Engenharia de Software RUP (Rational Unified Process)

Prévia do material em texto

Engenharia de Software 
RUP (Rational Unified Process) - Processo Unificado 
 
 
O Processo Unificado da Rational conhecido como RUP (Rational Unified Process), é um 
processo de engenharia de software criado para apoiar o desenvolvimento orientado a 
objetos, fornecendo uma forma sistemática para se obter vantagens no uso da UML. Foi 
criado pela Rational Software Corporation e adquirido em fevereiro de 2003 pela IBM. 
O principal objetivo do RUP é atender as necessidades dos usuários garantindo uma 
produção de software de alta qualidade que cumpra um cronograma e um orçamento 
previsíveis. Assim, o RUP mostra como o sistema será construído na fase de implementação, 
gerando o modelo do projeto e, opcionalmente, o modelo de análise que é utilizado para 
garantir a robustez. O RUP define perfeitamente quem é responsável pelo que, como as 
coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de 
desenvolvimento especificamente para que sejam alcançadas. 
O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas 
questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e 
implantação do software. Cada fase tem um papel fundamental para que o objetivo seja 
cumprido, distribuídos entre vários profissionais como o Analista de sistema, Projetista, 
Projetista de testes, entre outros. 
 
 
Fase de Concepção / Iniciação: Esta fase do RUP abrange as tarefas de comunicação com o 
cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as 
estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos 
do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes 
interessadas na definição do escopo do projeto, onde são examinados os objetivos para se 
decidir sobre a continuidade do desenvolvimento. 
Fase de Elaboração: Abrange a Modelagem do modelo genérico do processo. O objetivo 
desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando 
os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma 
básica. Indagações como "O plano do projeto é confiável?", "Os custos são admissíveis?" são 
esclarecidas nesta etapa. 
Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal 
objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de 
componentes e outros recursos do sistema. É na fase de Construção que a maior parte de 
codificação ocorre. 
Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo 
desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário 
final. As atividades desta fase incluem o treinamento dos usuários finais e a realização de 
testes da versão beta do sistema visando garantir que ele possua o nível adequado de 
qualidade. 
 
Processo Unificado (PU) – Unified Process 
O Processo Unificado (PU) surgiu para realizar o desenvolvimento de software visando a 
construção de sistemas orientados a objetos. Este modelo de desenvolvimento de software 
é iterativo e adaptativo, desta forma consegue produzir um sistema de grande porte como 
se fosse vários pequenos sistemas, o que diminui o risco do projeto. 
O RUP (Rational Unified Process) surgiu como uma versão melhorada e proprietária do 
Processo Unificado, foi desenvolvido originalmente pela Rational e posteriormente 
comprado pela IBM, também irei apresentar alguns detalhes desse processo. 
O Processo Unificado consiste na repetição de uma série de ciclos durante o 
desenvolvimento de um sistema, por isso esse processo é dito como evolucionário. Cada 
ciclo é concluído com uma versão do produto pronta para distribuição e é subdividido em 4 
Fases: Concepção, Elaboração, Construção e Transição. 
Estas Fases por sua vez são subdivididas em Iterações e estas passam por cinco Fluxos de 
trabalho: Requisitos, Análise, Projeto, Implementação e Teste. A figura a seguir mostra um 
gráfico deste fluxo. 
 
 
Em cada Iteração incrementa-se um pouco mais o produto, utilizando as informações que 
foram obtidas nas iterações anteriores e no feedback dos usuários que já estão utilizando o 
sistema. No Processo Unificado cada Iteração pode ser considerada um projeto de duração 
fixa, sendo que cada um destes inclui suas próprias atividades de análise de requisitos, 
projeto, implementação e testes. 
O resultado de cada Iteração é um sistema executável, embora ainda incompleto, 
outra característica é que o resultado de cada iteração produz um sistema com qualidade de 
produto final, e não um protótipo. 
Cada uma das Fases se foca numa dos Fluxos de Trabalho, durante a Concepção o foco está 
na captação de Requisitos; na Elaboração o foco é a Análise e Projeto do sistema; na fase 
de Construção o foco é a Implementação e a fase 
de Transição é caracterizada pelos Testes e a entrega do produto final aos usuários. 
 
A análise de requisitos é o primeiro passo de uma iteração, como pode-se ver na figura a 
seguir. 
 
Os requisitos do sistema são especificados através da identificação das necessidades de 
usuários e clientes, estes requisitos são expressos em casos de uso através do modelo de 
casos de uso. Os casos de uso são representados através da notação UML, onde cada caso 
de uso é composto pelos diagramas de casos de uso que compõem o sistema. 
Durante a Fase de Concepção, os Requisitos mais importantes são identificadas, delimitando 
o domínio do sistema. Na Fase de Elaboração os Requisitos remanescentes são analisados, 
permitindo aos desenvolvedores identificar o real tamanho do sistema. Ao final da Fase de 
Elaboração 80% dos Requisitos do sistema já devem ter sido descritos, porem apenas 5% ou 
10% destes Requisitos terão sido implementados nesta fase. Os Requisitos remanescentes 
serão identificados e implementados durante a Fase de Construção, na Fase de 
Transição praticamente não há Requisitos a serem identificados, a menos que ocorram 
mudanças nos mesmos. 
 
A Análise é o segundo elemento do Fluxo de Trabalho de uma Iteração, 
neste Fluxo é construído o Modelo de Análise. 
 
 
O produto gerado no Fluxo de Análise é o Modelo de Análise, este refina os requisitos 
especificados no Fluxo de Requisitos através da construção de diagramas de classes 
conceituais, permitindo desta forma identificar o funcionamento interno do sistema. É 
no Modelo de Análise que é gerado o diagrama de interações e o diagrama de gráficos de 
estados que representam a dinâmica do sistema. Com este conhecimento é mais fácil 
definir uma arquitetura estável e facilita o entendimento detalhado dos requisitos. É 
no Modelo de Análise que é dado o primeiro passo para o desenvolvimento do Modelo de 
Projeto. 
O Fluxo de Análise tem maior importância durante a Fase de Elaboração. Para realizar 
esse Fluxo de Trabalho corretamente é necessário primeiro identificar e detalhar os casos 
de uso para uma Iteração, e depois, através da análise da descrição de cada caso de uso, 
sugerir quais classes e relacionamentos são necessários para realizá-lo. 
 
O Projeto é o terceiro elemento do Fluxo de Trabalho de uma Iteração, neste Fluxo 
é construído o Modelo de Projeto que é construído com base no Modelo de 
Análise definido no Fluxo de Análise. 
 
 
 
No Fluxo de Projeto o sistema é moldado e sua e sua forma é definida de maneira a suprir as 
necessidades especificadas pelos requisitos. No Fluxo de Análise é gerado o Modelo de 
Análise que descreve as características comportamentos e estruturais do sistema em um 
nível conceitual, no Fluxo de Projeto é desenvolvido o Modelo de Projeto que descreve o 
sistema em um nível físico. A principal função deste Fluxo é obter a compreensão detalhada 
dos requisitos do sistema, levando em consideração fatores como linguagens de 
programação, SO, tecnologias de banco de dados, interface com o usuário etc. 
O trabalho realizado no Fluxo de Projeto é mais concentrado entre o fim da Fasede 
Elaboração e o início da Fase de Construção, como pode ser observado na figura anterior. 
 
O fluxo de implementação é baseado no produto do Fluxo de Projeto, o Modelo de Projeto; 
e implementa o sistema em termos de componentes, ou seja: código fonte, arquivos 
executáveis etc. Como a maior parte da arquitetura do sistema é definida durante o Fluxo 
de Projeto, este produz um Modelo de Implementação que se limita a: Planejar as 
integrações do sistema em cada Iteração. Neste caso, o resultado é um sistema que é 
implementado como uma sucessão de etapas pequenas e gerenciáveis; implementar os 
subsistemas encontrados durante o Fluxo de Projeto; testar as implementações e integrá-
las, compilando-as em um ou mais arquivos executáveis, antes de enviá-las ao Fluxo de 
Teste. 
 
 
 
Como pode ser visto na figura acima o Fluxo de Implementação tem maior importância 
durante a Fase de Construção, este Fluxo é mais simples de ser realizado devido ao fato de 
as decisões mais difíceis terem sido tomadas durante o Fluxo de Projeto. Por isso o código 
gerado durante a implementação, deve ser uma simples tradução das decisões de projeto 
em uma linguagem específica. 
 
O Fluxo de Teste é desenvolvido com base no produto gerado durante o Fluxo de 
Implementação, ou seja, os componentes executáveis são testados para só então ser 
disponibilizado ao usuário final. Os componentes testados que apresentarem problema 
retornarão a Fluxos anteriores, onde serão corrigidos. 
O teste de um sistema, propriamente dito, é realizado primeiramente durante a Fase de 
Elaboração quando a arquitetura do sistema é definida, e durante a Fase de 
Construção quando o sistema é implementado. Na Fase de Concepção já deve ser feito um 
planejamento inicial dos testes. Já na Fase de Transição, o Fluxo de Testes limita-se ao 
conserto de defeitos encontrados durante a utilização inicial do sistema. Na figura a seguir 
pode-se ver o Fluxo de Teste. 
 
 
Durante o Fluxo de Teste é gerado o Modelo de Teste, esse modelo descreve como 
componentes executáveis, provenientes do Fluxo de Implementação, serão testados. No 
Modelo de Testes pode vir descrito com os aspectos específicos do sistema serão testados, 
como por exemplo, se a interface com o usuário é simples e consistente ou se o manual de 
usuário cumpre o seu objetivo. 
Resumindo o papel do Fluxo de Teste é verificar se os resultados do Fluxo de 
Implementação comprem os requisitos estipulados por clientes e usuários, para decidir se o 
sistema necessita de revisões ou se o processo de desenvolvimento pode continuar. 
 
Um ciclo está dividido em Fases, cada qual podendo ser subdividida em iterações e 
consequentemente incrementos. São quatro as Fases de compõem o ciclo de vida 
do Processo Unificado. 
 
Nesta Fase o objetivo principal é delimitar o escopo do projeto, definindo como o sistema 
será utilizado por cada usuário, utilizando-se da criação dos casos de uso mais relevantes 
para o projeto. A partir dos dados captados durante essa Fase poderá ser definido os custos 
e prazos para a realização do projeto. Nesta Fase é muito importante a identificação dos 
riscos do projeto, o que poderá evitar o fracasso dele. 
A maior parte do trabalho da Fase de Concepção está concentrado no Fluxo de Requisitos, 
porém cada Fluxo de Trabalho possui seu papel dentro desta Fase. Ao final da Fase de 
Concepção, os objetivos do ciclo de vida do projeto devem ser analisados para se decidir de 
o desenvolvimento deve prosseguir em plena escala. 
 
Na Fase de Elaboração os requisitos remanescentes, que é a maioria são capturados e 
transformados em casos de uso; a base da arquitetura, que irá guiar os trabalhos nas Fases 
de Construção e Transição, é estabelecida e os detalhes adicionais do projeto são 
averiguados. 
Nesta Fase o projeto deve ser estudado de forma ampla sem se preocupar com o 
aprofundamento de detalhes. O foco é formular uma base para a arquitetura do sistema, e 
para realizar essa tarefa é necessário estudar a maior parte dos casos de uso do sistema, 
cerca de 80%. 
Quando a Fase de Elaboração terminar, já estarão definidos o escopo e os objetivos 
detalhados do sistema, a escolha da arquitetura e a solução para os principais riscos, desta 
forma as informações necessárias para a Fase de Construção estarão disponíveis. 
O trabalho na Fase de Construção inicia com base na arquitetura executável, que foi 
definida na Fase de Elaboração, e prossegue através de Iterações e incrementos, com 
objetivo de desenvolver um produto para operações iniciais no ambiente de usuário, ou 
seja, a versão beta. 
Durante a Fase de Construção são detalhados os casos de uso remanescentes e a descrição 
da arquitetura é modificada quando necessário. Os Fluxos de Trabalho prosseguem para 
preencher os Modelos de Análise, Projeto e Implementação. 
Enquanto as Fases de Concepção e Elaboração estão ligadas diretamente à modelagem do 
sistema, a fase de Construção é caracterizada pelo desenvolvimento. 
A Fase de Transição tem como objetivo disponibilizar o produto no ambiente operacional do 
cliente. A partir da avaliação da versão beta do sistema, a equipe de desenvolvimento pode 
verificar se o sistema realmente cumpre as necessidades do usuário, se possui falhas, 
problemas e se há ambiguidades na documentação do usuário. É nesta fazer que vai ser 
identificado se os usuários estão encontrando dificuldades na operação do sistema, caso 
isso aconteça pode ser adotado um treinamento para os usuários. 
Nesta Fase procura-se por deficiências mínimas que passaram despercebidas pela Fase de 
Construção e possam corrigidas dentro da arquitetura existente. A conversão de bases de 
dados antigas para a nova configuração também é responsabilidade da Fase de Transição, 
sendo que esta Fase termina quando é realizada a entrega do produto ao cliente. 
 
Conclusão 
O Processo Unificado foi criado para ser um processo ágil de desenvolvimento e prega uma 
abordagem realística para a condução de um projeto. Ao contrário do modelo em cascata, 
onde cada etapa do ciclo de vida é realizada integralmente e de uma só vez (e que é mais 
apropriado para a construção de prédios do que para softwares), no PU as atividades são 
repetidas quantas vezes forem precisos, em ciclos organizados. Não há um plano detalhado 
para todo um projeto. Há um plano de alto nível (chamado Plano de Fases) que estima a 
data de término do projeto e outros marcos de referência principais, mas ele não detalha os 
passos de granularidade fina para se atingir tais marcos. Um plano detalhado (chamado 
Plano de Iterações) somente planeja a iteração a ser feita em seguida. O planejamento 
detalhado é feito de forma adaptativa, de iteração para iteração.