O Processo Unificado

Published in

Contexto Delimitado

10 min readAug 25, 2019

O Processo Unificado (Unified Process) foi criado em 1995 por Jim Rumbaugh, Grady Booch e Ivar Jacobson para suportar o paradigma de Orientação a Objetos. Os “três amigos”, como passaram a ser chamados, faziam parte da Rational Software Corporation, onde concluíram a elaboração da UML (Unified Modeling Language) e a lançaram em 1996 (GUEDES, 2018).

Em 2003, a IBM adquiriu o Rational Unified Process ou RUP, como passou a ser chamada a versão melhorada do Processo Unificado, que fornecia “uma forma sistemática para se obter vantagens no uso da UML” (KRUTCHEN, 2003).

A principal novidade é o acréscimo da UML para modelagem do sistema.

Segundo PEREIRA (2006), esta metodologia “objetiva realizar um maior controle sobre os resultados obtidos, gerenciar mudanças e fomentar um produto de qualidade e estável”.

Segundo KROLL e KRUNCHTEN (2003, p34), conforme citado por PEREIRA (2006), os princípios essenciais do RUP são: “atacar os riscos cedo e continuamente, entregar algo de valor ao cliente, focar em um software que possa ser utilizado o quanto antes, realizar mudanças cedo, liberar protótipos da aplicação, utilizar componentes reutilizáveis, trabalhar como um time e fazer da qualidade um estilo de vida”.

Os criadores do processo discutem sua necessidade (JACOBSON, 1999):

Hoje, a tendência em software é em direção a sistemas maiores, mais complexos. Isso se deve, em parte, ao fato de que os computadores têm se tornado mais potentes a cada ano, levando os usuários a esperar mais deles. Essa tendência tem também sido influenciada pelo uso da internet, que está se expandindo, para trocar toda espécie de informação… Nosso apetite por softwares cada vez mais sofisticados cresce à medida que aprendemos de uma versão de produto para a seguinte como o produto poderia ser aperfeiçoado. Desejamos softwares que sejam melhor adaptados às nossas necessidades, mas que, por sua vez, não torne o software somente mais complexo. Em resumo, desejamos mais.

O RUP é uma tentativa de “unificar” o melhor de todos os modelos convencionais (por isso o nome Processo Unificado) de forma que possam se adequar ao Desenvolvimento Ágil de software. Como os outros métodos não possuíam uma maneira satisfatória para lidar com o paradigma de Orientação a Objetos, o RUP introduziu a UML, uma notação gráfica para especificação de objetos capaz de demonstrar visualmente as funcionalidades e os fluxos de um software. Segundo PRESSMAN (2006), “o Processo Unificado e a UML são amplamente usados em projetos de OO de todas as naturezas”.

Características

O modelo possui as seguintes características:

Iterativo e incremental: os fases de Elaboração, Construção e Transição são divididas em uma série de interações. Em projetos grandes, a fase de Concepção também pode ser dividida em iterações. Cada iteração resulta em um incremento, que é uma versão do sistema contendo funcionalidades adicionais ou melhoradas em comparação com a versão anterior. Essa divisão de incrementos deve ser feita no inicio do projeto, definindo todas antes de iniciar a programação;
Dirigido por Casos de Uso: na captura de requisitos, eles são refinados e desenhados na forma de Casos de Uso da UML. Cada iteração tem um conjunto de casos de uso ou cenários de requisitos durante todo o tempo de implementação, teste e desenvolvimento;
Centrado na Arquitetura: o RUP defende que, para dar forma ao sistema, a Arquitetura deve estar no centro dos esforços da equipe do projeto. Uma vez que não existe um modelo único suficiente para cobrir todos os aspectos do sistema, o RUP suporta múltiplas visões e modelos arquiteturais.
Focado no Risco: o modelo requer que a equipe do projeto concentre-se em enfrentar os riscos mais críticos no início do ciclo de vida do projeto. As entregas de cada iteração, especialmente na fase de Elaboração, devem ser selecionadas de forma a garantir que os maiores riscos sejam tratados em primeiro lugar.

As fases do processo

O modelo se divide em quatro fases (GUEDES, 2018):

Concepção: objetivo da fase é fazer a elicitação de requisitos inicial e determinar a viabilidade de se desenvolver o sistema (GUEDES, 2018). São identificadas todas as entidades externas (pessoas ou sistemas) que vão interagir com a aplicação. Com essas informações, avalia-se a viabilidade do sistema para o negócio e, se for pequena, o projeto pode ser cancelado aqui;
Elaboração: nesta fase a maioria dos Casos de Uso são elaborados e especificados. A arquitetura do sistema é projetada, gerando diversos artefatos (Documentação, Diagramas, Planilhas, etc) e uma “baseline” completa é apresentada incluindo os componentes estruturados para posterior formação da equipe de desenvolvimento. No final dessa fase os envolvidos devem estar aptos a planejar a fase de construção em detalhes;

Construção: esta fase envolve a implementação do software e seus testes (GUEDES, 2018). É onde utilização dos vários artefatos possibilita que o sistema seja implementado quase completamente. Tem-se uma visão geral de como o “baseline” do projeto está sendo seguido. Na conclusão dessa fase, você deve ter um sistema de software já funcionando, bem como a documentação associada pronta para ser entregue aos usuários;
Transição: nesta fase o software será implantado garantindo que todos os requisitos do projeto foram atendidos e implementados corretamente. O produto final pode ser liberado em uma versão beta. Outras atividades desta fase, dependendo do projeto, podem ser os testes no ambiente real (onde o software irá funcionar), a conclusão do manual do usuário, a identificação e correção de defeitos, etc. No final, deve-se tirar uma conclusão geral do projeto, levantando e documentando os pontos positivos e negativos para serem ser utilizados nas decisões em projetos futuros.

Essas fases servem de apoio para a execução das tarefas de cada um dos Fluxos de Trabalho, sendo seis da Engenharia de Software e de três para Apoio e Suporte.

Modelagem de negócios (ES): os processos de negócio são modelados por meio de Casos de Uso de negócios (SOMMERVILLE, 2011). O objetivo principal é que o analista entenda muito bem o problema a ser resolvido, elaborando se necessário uma análise de risco e de viabilidade para o projeto como um todo. É preciso uma grande interação entre o analista e o cliente, para que seja possível a criação dos Casos de Uso e consequentemente a extração dos requisitos. Entender o modelo de negócio do cliente é fundamental antes que um requisito possa ser definido;
Requisitos (ES): nesse fluxo de trabalho, procura-se extrair os requisitos de forma que o cliente possa entender claramente a proposta do sistema. O alicerce é que o analista entenda o domínio do problema e consequentemente construa um bom modelo de Caso de Uso. A extração dos requisitos a partir de um Caso de Uso gerará um artefato que será evoluído durante todo o projeto;
Análise e Desenho (ES): um modelo de projeto será criado e documentado em artefatos, como Descrição da Arquitetura Básica do sistema, Protótipos de Funcionalidade e Interface, Diagrama de Classes, Diagrama de Estado, Diagrama de Iteração, Diagrama de Seqüência, etc (SOMMERVILLE, 2011). Durante o desenvolvimento do projeto alguns artefatos poderão sofrer ajustes de acordo com as implementações realizadas. O objetivo aqui é compreender os Casos de Uso mais importantes, que serão úteis para a elaboração dos artefatos necessários, lembrando que não é necessária a utilização de todos os artefatos, mas apenas aqueles que sejam relevantes para o cliente entender perfeitamente o que será construído. Com artefatos bem elaborados, a equipe de desenvolvimento terá grande facilidade em realizar a implementação;
Implementação (ES): os desenvolvedores poderão fazer uso de componentes (funções) que foram utilizados em outro sistema ou projeto. Ainda na fase de Concepção, pode-se ter um protótipo de funcionalidade. No decorrer deste fluxo de trabalho, tenta-se gerar um sistema executável a cada iteração, além da implementação baseada nos artefatos criados no fluxo de Análise e Desenho. O conceito de componentes deve ser sempre consideração, para que seja possível aproveitar esses “pedaços de código” em outros projetos;
Testes (ES): um plano de testes é elaborado, definindo quais tipos de testes serão realizados. Esse plano poderá ser alterado de acordo com as melhorias ou alterações nos requisitos do sistema, impactando no número de testes a serem realizados. Nas fases de Concepção e Elaboração são feitos os testes de módulos e na fase de Construção, os testes de integração;
Implantação (ES): neste fluxo de trabalho, um release do produto será criado, distribuído aos usuários e instalado no ambiente do cliente, ou seja, em seu local de trabalho (SOMMERVILLE, 2011). Durante toda a fase de Elaboração, até o meio da fase de Construção, poderá ser criado um documento especificando, de forma simples, algumas características do ambiente do cliente, contendo especificações técnicas sobre a infra-estrutura de rede, os sistemas operacionais, sistemas integrados, etc. Também é interessante adicionar algumas dicas de instalação para reduzir, no futuro, os erros de instalação e o tempo de testes. No final da fase de Construção, começa a migração do sistema para o “ambiente de testes” do cliente e posteriormente, na fase de Transição, o sistema é configurado no “ambiente de produção” do cliente.
Gerência de configuração e mudança (AS): nesse fluxo de trabalho são controlados todos os artefatos do projeto e suas versões. Antes de realizar uma mudança corretiva ou evolutiva, deve-se fazer uma análise sobre o que deve ser modificado e quais artefatos serão afetados. Um bom controle de mudança é crucial para garantir o sucesso e a qualidade do projeto. Conforme o projeto entra na fase de construção, aumenta-se a dificuldade em controlar as mudanças e gerenciar a configuração. Quanto maior o projeto se torna, com mais requisitos implementados, maior será a chance de uma alteração afetar outras áreas do sistema. Por isso, saber rastrear e relacionar requisitos é uma importante tarefa do engenheiro de software. Após uma modificação, é necessário executar novos testes em várias áreas do sistema, garantindo que a mudança foi implementada corretamente e que nada foi quebrado. Igualmente importante é a atualização da documentação para que reflita perfeitamente o que foi implementado;
Gerenciamento de projeto (AS): aqui se escolhe os artefatos a serem utilizados no desenvolvimento, de acordo com o tipo do projeto e o entendimento do cliente. O gerente de projeto deve ter uma visão clara do que o cliente deseja, do que está documentado e do que está sendo implementado. A atividade de gerenciamento de projeto é constante durante todo o ciclo de vida do software, onde se deve: a) elaborar reuniões para entrega de versões; b) criar documentos de RTF (Revisão Técnica Formal) para cada reunião; c) garantir a correta mudança dos artefatos; d) manter um bom relacionamento com o cliente;
Ambiente (AS): Esse fluxo de trabalho está relacionado com a disponibilização de ferramentas apropriadas para a equipe de
desenvolvimento de software (SOMMERVILLE, 2011). Essa disponibilização pode ser referente ao tipo de plataforma usada, a velocidade da internet e da rede, a organização dos diretórios/repositórios onde serão armazenados os artefatos e os códigos fonte, o sistema de backup etc. No final de cada fase podem acontecer ajustes no ambiente, podendo ser: criação de diretórios, backup de versões do software, etc.

Os artefatos gerados no processo

Durante os “fluxos de trabalho”, podem ser produzidos vários “produtos de trabalho”, também chamados de “artefatos”, contendo informações sobre todo o processo. Segundo PRESSMAN (2006), “do ponto de vista dos Engenheiros de Software, o produto de trabalho mais importante, produzido durante a concepção, é o Modelo de Casos de Uso, uma coleção de Casos de Uso que descreve como atores externos (‘usuários’ humanos e não-humanos do software) interagem com o sistema e obtém valor dele”.

A seguir, uma possível lista de artefatos como propõe PRESSMAN (2006):

Os artefatos gerados na Concepção

Documento de Visão;
Modelo inicial de Casos de Uso;
Glossário inicial do projeto;
Caso de negócio inicial;
Avaliação inicial de risco;
Plano de projeto: fases e iterações;
Modelo de negócio (se necessário);
Um ou mais protótipos

Os artefatos gerados na Elaboração

Modelo de Casos de Uso;
Requisitos suplementares, incluindo não funcionais;
Modelo de análise;
Descrição da arquitetura do software;
Protótipo arquitetural executável;
Modelo de projeto preliminar;
Lista de riscos revisada;
Plano de projeto: planos de iteração, fluxos de trabalho adaptados, marcos e produtos técnicos de trabalho;
Manual preliminar do usuário.

Os artefatos gerados na Construção

Modelo de projeto;
Componentes de software;
Incremento integrado de software;
Plano e procedimento de teste;
Caso de teste;
Documentação de apoio: manuais do usuário, manuais de instalação, descrição do incremento atual.

Os artefatos gerados na Transição

Incremento de software entregue;
Relatório de teste beta;
Realimentação geral do usuário (modificar ou adaptar a compreensão dos requisitos do projeto).

Vantagens

É um dos modelos mais usados em projetos modernos de desenvolvimento de software;
É extremamente robusto e bem estruturado;
Por fazer uso da UML, a facilidade de compreensão dos requisitos aumenta, tanto para os clientes, como para os analistas e desenvolvedores;
Os riscos que poderiam ser mais preocupantes são resolvidos no inicio, minimizando o retrabalho e, consequentemente, a chance de fracasso do projeto.

Desvantagens

Exige uma equipe experiente e alinhada com os processos;
Exigem um bom gerente de projetos;
Complexo e trabalhoso para projetos pequenos.

Espero que o conteúdo tenha sido útil até agora. Um grande abraço e até o próximo artigo!

Leia todos os artigos desta série:

Referências para aprofundamento

ENGHOLM, Hélio. Engenharia de Software na Prática. Novatec Editora. São Paulo, Brasil, 2010.

GUEDES, Gilleanes T. A. UML2 Uma Abordagem Prática, 3ª Edição. Novatec Editora. São Paulo, Brasil, 2018;

JACOBSON, Ivar et all. The Unified Software Development Process. Addison-Wesley, Massachusetts, EUA, 1999.

KRUTCHEN, P. The Rational Unified Process An Introduction. Reading, Addison-Wesley, Massachusetts, EUA, 2003.

PEREIRA, S., & VIEIRA, T. Estudo da aplicação de um processo gerenciado de produção de software em MPEs. In Proc. of the 13th Simpósio de Excelência em Gestão e Tecnologia. Resende/Brasil, 2006.

PRESSMAN, Roger. S. Engenharia de Software, 6ª Edição. McGrawHill, Nova York, EUA, 2006

SOMMERVILLE, Ian. Engenharia de Software, 9ª Edição. Pearson. São Paulo, Brasil, 2011.