Processo Unificado (PU) – Unified Process

Introdução

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.

Desenvolvimento: Iterativo e Incremental

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.

Fluxo de Requisitos

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.

Fluxo de Análise

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 realizar-lo.

Fluxo de Projeto

O Projeto é o terceiro elemento do Fluxo de Trabalho de uma Iteração, neste Fluxo é construído o Modelo de Projeto que é construido 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 das 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 Fase de Elaboração e o início da Fase de Construção, como pode ser observado na figura anterior.

Fluxo de Implementação

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 um 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 envia-las ao Fluxo de Teste.

Como pode ser visto na figura a cima 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 das 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 especifica.

Fluxo de Teste

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 requisito estipulados por clientes e usuários, para decidir se o sistema necessita de revisões ou se o processo de desenvolvimento pode continuar.

Fases do Projeto

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.

Fase de Concepção

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 do mesmo.

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.

Fase de Elaboração

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 trabalho 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 so 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.

Fase de Construção

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.

Fase de Transição

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á ambiquidades 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.

Questões de Concursos

TRT 01 RJ – 2011
61) No Processo Unificado, a maior porção do core workflow denominado Analysis é executada na fase
(A) Inception
(B) Transition
(C) Elaboration
(D) Construction
(E) Implementation
Gabarito: C