O Processo Unificado (PU) ou Unified Process (UP) surgiu como um processo para o desenvolvimento de software visando à construção de sistemas orientados a objetos. De acordo com Pressman (2011, p. 71), o PU busca aproveitar os melhores recursos dos modelos de processos tradicionais unidos aos melhores princípios do desenvolvimento ágil de software.
De acordo com IBM (2006), o PU foi modelado usando o Software Process Engineering Metamodel (SPEM), que é um padrão para modelagem de processos baseado em UML – Unified Modeling Language. De uma maneira geral, podemos assim caracterizar o Processo Unificado:
- é um framework genérico de um processo de desenvolvimento;
- é baseado em componentes;
- utiliza toda a definição da UML;
- é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).
De acordo com Sommerville (2011, p. 34), o RUP – Rational Unified Process – é derivado de trabalhos da UML – Unified Modeling Language – e do Processo Unificado, reunindo elementos de modelos de processo genéricos, trazendo boas práticas de especificação para o projeto e ainda apoiando a prototipação e a entrega incremental. É um processo iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos por causa da maneira organizada e consistente que oferece na condução de um projeto.
Sommerville (2017) descreve o RUP como um framework descrito em três perspectivas:
- Dinâmica, que mostra as fases ao longo do tempo;
- Estática, que mostra as atividades ao longo do processo;
- Prática, que sugere boas práticas a serem utilizadas.
A figura ilustra as fases e os workflows do RUP.
Fases – Perspectiva dinâmica
O RUP organiza suas iterações em quatro fases principais, que Sommerville (2011) assim define:
Concepção: o objetivo desta fase é definir um caso de negócio para o sistema. São elencadas todas as entradas externas, que se referem a pessoas e sistemas, define-se como estas interagem com o sistema e as interações são definidas. A ideia é ter uma visão inicial do problema, estimar de forma vaga o esforço e os prazos e determinar se o projeto é viável e merece uma análise mais profunda, ou então se deve ser descartado.
Elaboração: na fase de elaboração todos (ou a grande maioria) dos requisitos são levantados em detalhes, o framework arquitetural do sistema é definido, o plano de projeto é desenvolvido e os maiores riscos do projeto são identificados. Ao fim desta fase, deseja-se que 90% dos requisitos tenham sido levantados em detalhes, podendo formar um conjunto de casos de uso da UML, que o planejamento e a arquitetura do sistema tenham sido descritos e que os principais riscos tenham sido tratados, de forma que haja condições para se fazer estimativas mais realistas.
Construção: esta fase envolve o projeto, implementação e testes do sistema. O sistema é cosntruído por partes e integrado e, no final, uma versão do sistema já deve estar funcionando, junto com uma documentação a ser entregue ao cliente.
Transição: esta fase realiza a transferência do sistema do ambiente de produção, ou seja, dos desenvolvedores, para o ambiente real de utilização, ou seja, para os usuários. Ao final da fase, a implantação deve estar concluída e o sistema deve estar funcionando, com a documentação adequada, no ambiente operacional.
Workflows – Perspectiva Estática
A visão estática do RUP dá prioridade às atividades que ocorrem no processo de desenvolvimento, denominadas workflows. Um workflow é uma coleção de atividades relacionadas que estão ligadas à maior área de interesse dentro do processo, podendo ser modeladas por meio de diagramas da UML. São 6 workflows centrais e 3 workflows de apoio, cujos objetivos são:
- Modelagem de Negócios: entender a estrutura e a dinâmica da organização para a qual o produto será desenvolvido; identificar problemas correntes na organização e possíveis aperfeiçoamentos; assegurar que o cliente, o usuário final e os desenvolvedores possuam a mesma compreensão da empresa; produzir os requisitos de sistemas necessários para suportar os objetivos da organização. Os processos de negócio são modelados usando casos de uso de negócios.
- Requisitos: estabelecer e manter o consentimento entre clientes e stakeholders sobre o que o sistema deve fazer; fornecer uma melhor compreensão dos requisitos aos desenvolvedores; definir os limites do sistema; fornecer as bases para o planejamento das iterações, estimativas de custo e tempo de desenvolvimento; definir as interfaces do sistema baseado nas necessidades e objetivos dos usuários. Os atores que interagem com o sistema são identificados e casos de uso são utilizados para modelar os requisitos do sistema.
- Análise e Design: transformar os requisitos dentro de um projeto do que será o sistema; desenvolver uma arquitetura robusta para o sistema; adaptar o projeto para ajustá-lo ao ambiente de implementação. O modelo de projeto é criado e documentado utilizando diagramas que definem os modelos de arquitetura, de componentes, de objetos e de sequência.
- Implementação: preparar a organização do código em termos de implementação de subsistemas, organizados em camadas; implementar classes e objetos em termos de seus componentes; testar os componentes desenvolvidos como unidades; integrar os resultados obtidos por implementadores individuais (ou equipes) em um sistema executável. Os componentes do sistema são implementados e estruturados em subsistemas de implementação, podendo ser utilizada geração automática de código.
- Teste: verificar a interação entre os objetos; verificar a integração de todos os componentes de software; verificar se todos os requisitos foram implementados corretamente; verificar os defeitos e assegurar que eles foram tratados antes da entrega do produto. O teste de sistema segue a conclusão da implementação.
- Implantação: descrever as atividades associadas à verificação para que o produto esteja disponível ao usuário final. Um release (versão) do sistema é produzido e instalado no ambiente de trabalho dos usuários.
- Gerenciamento de Configuração e Mudança: identificar itens de configuração; restringir alterações para aqueles itens; auditar as alterações neles feitas; definir e gerenciar as alterações daqueles itens. Este workflow de apoio gerencia as mudanças do sistema.
- Gerenciamento de Projeto: fornecer uma estrutura para gerenciamento de projeto de software; fornecer um guia prático para planejamento, recrutamento, execução e monitoramento de projeto; fornecer uma estrutura para o gerenciamento de riscos. Este workflow de apoio gerencia o desenvolvimento do sistema.
- Ambiente: identificar
as atividades necessárias para configurar o processo para o projeto;
descrever as atividades requeridas para desenvolver as guias mestras no
suporte ao projeto; fornecer para a organização de desenvolvimento de
software o ambiente de processos e ferramentas que suportarão a equipe
de desenvolvimento. Este workflow de apoio está ligado à disponibilização de ferramentas adequadas para o desenvolvimento.
Perspectiva prática
O RUP indica seis boas práticas de Engenharia de Software a serem aplicadas no desenvolvimento de sistemas de software, que são assim descritas por Sommerville (2011):
- Desenvolver software de forma interativa.
- Gerenciar os requisitos.
- Usar arquiteturas baseadas em componentes.
- Modelar o software usando diagramas e modelos visuais.
- Verificar a qualidade do software.
- Controlar as mudanças do software.
Apesar de apresentar diversas vantagens, o RUP é um processo complexo, envolve custos mais altos e requer equipe de desenvolvimento maior e mais especializada. Não é um modelo adequado para o desenvolvimento de software embarcado, por exemplo.
Nenhum comentário:
Postar um comentário