Processo Unificado
No início deste capítulo, foram apresentadas cinco atividades metodológicas genéricas e argumentos
afirmando que elas poderiam ser usadas para descrever qualquer modelo de processo
de software. O Processo Unificado não é nenhuma exceção.
A fase de concepção (Inception) do PU envolve tanto a atividade de comunicação com o cliente
como a de planejamento. Colaborando com os interessados, identificam-se as necessidades de
negócio para o software; propõe-se uma arquitetura rudimentar para o sistema e se desenvolve
um planejamento para a natureza iterativa e incremental do projeto decorrente. Requisitos de negócio
fundamentais são descritos por meio de um conjunto de casos práticos preliminares descrevendo quais recursos e funções cada categoria principal de usuário deseja. Até esse
ponto, a arquitetura nada mais é do que um esquema provisório dos principais subsistemas e da
função e dos recursos que os compõem. Posteriormente, a arquitetura será refinada e expandida
para um conjunto de modelos que representarão visões diferentes do sistema. O planejamento
identifica recursos, avalia os principais riscos, define um cronograma e estabelece uma base para
as fases que serão aplicadas à medida que o incremento de software é desenvolvido.
A fase de elaboração envolve atividades de comunicação e modelagem do modelo de processo
genérico. A elaboração refina e expande os casos práticos preliminares, desenvolvidos como parte da fase de concepção, e amplia a representação da arquitetura, incluindo cinco
visões diferentes do software: modelo de caso prático, modelo de requisitos, modelo de projeto,
modelo de implementação e modelo de emprego. Em alguns casos, a elaboração gera uma
"base de arquitetura executável" [Arl02], consistindo num sistema executável "de degustação".19
Essa base demonstra a viabilidade da arquitetura, mas não oferece todos os recursos e funções
necessárias para usar o sistema. Além disso, no auge da fase de elaboração, o plano é revisado
cuidadosamente para assegurar que escopo, riscos e datas de entrega permaneçam razoáveis.
Normalmente, as modificações no planejamento são feitas nesta oportunidade.
A fase de construção do PU é idêntica à atividade de construção definida para o processo de
software genérico. Tendo como entrada (input) o modelo de arquitetura, a fase de construção
desenvolve ou adquire componentes de software; esses componentes farão com que cada caso
prático (de uso) se torne operacional para os usuários finais. Para tanto, os modelos de requisitos
e de projeto, iniciados durante a fase de elaboração, são completados para refletir a versão
final do incremento de software. Então, implementa-se, no código-fonte, todos os recursos e
funções necessárias e exigidas para o incremento de software (isto é, para a versão). À medida
que os componentes estão sendo implementados, desenvolve-se e executam-se testes de unidades20
para cada um deles. Além disso, realizam-se atividades de integração (montagem de
componentes e testes de integração). Os casos práticos são usados para obter um pacote de
testes de aceitação, executados antes do início da fase seguinte do PU.
A fase de transição do PU abarca os últimos estágios da atividade da construção genérica e a
primeira parte da atividade de emprego genérico: entrega e realimentação (feedback). Entrega-
-se o software aos usuários finais para testes beta e o feedback dos usuários relata defeitos e
mudanças necessárias. Além disso, a equipe de software elabora material com as informações
de apoio (por exemplo, manuais para o usuário, guias para resolução de problemas, procedimentos
de instalação) que são necessárias para lançamento da versão. Na conclusão da fase de
transição, o incremento torna-se uma versão do software utilizável.
A fase de produção do PU coincide com a atividade de emprego do processo genérico. Durante
essa fase, monitora-se o uso contínuo do software, disponibiliza-se suporte para o ambiente (infraestrutura)
operacional, realiza-se e avalia-se relatórios de defeitos e solicitações de mudanças. É provável que, ao mesmo tempo em que as fases de construção, transição e produção estejam
sendo conduzidas, já se tenha iniciado o incremento de software seguinte. Isso significa que
as cinco fases do PU não ocorrem em sequência, mas sim de forma concorrente e escalonada.
Um fluxo de trabalho de engenharia de software é distribuído ao longo de todas as fases
do PU. Nesse contexto, um fluxo de trabalho é análogo a um conjunto de tarefas (descrito anteriormente
neste capítulo), isto é, identifica as tarefas para realizar uma importante ação de
engenharia de software e os artefatos produzidos como consequência da finalização de tarefas
com êxito. Deve-se notar que nem toda tarefa identificada para um fluxo de trabalho do PU é
conduzida em todos os projetos de software. A equipe adapta o processo (ações, tarefas, subtarefas
e artefatos de software) para ficar de acordo com suas necessidades.