Fases do processo unificado

No início deste capítulo, foram apresentadas cinco atividades metodológicas genéricas e ar- gumentos afirmando que elas poderiam ser usadas para descrever qualquer modelo de processo de software. O Processo Unificado não é nenhuma exceção. A Figura 2.9 descreve as “fases” do PU e as relaciona com as atividades genéricas que foram discutidas no Capítulo 1 e anterior- mente neste capítulo.

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 ne- gócio fundamentais são descritos por meio de um conjunto de casos práticos preliminares (Capí- tulo 5), 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 proces- so genérico (Figura 2.9). A elaboração refina e expande os casos práticos preliminares, desenvol- 17 Umcaso de uso (Capítulo 5) é uma narrativa textual ou modelo que descreve uma função ou recurso de um sistema do ponto de

vista do usuário. Um caso de uso é escrito pelo usuário e serve como base para criação de um modelo de requisitos mais amplo. 18 O Processo Unificado é, algumas vezes, chamado de Processo Unificado Racional RUP, Rational Unified Process) em homena-

gem a Rational Corporation (posteriormente adquirida pela IBM), um dos primeiros contribuidores para o desenvolvimento e refinamento do PU e um desenvolvedor de ambientes completos (ferramentas e tecnologia) que dão suporte ao processo. Em seu intento, as fases do Processo Unificado são similares às atividades metodológicas genéricas definidas neste livro.

capítulo 2 MODELOS DE PrOCESSO 73

vidos 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 requisi- tos 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 uni- dades20 _{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, procedi- mentos 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 (in- fraestrutura) operacional, realiza-se e avalia-se relatórios de defeitos e solicitações de mudanças. 19 É importante observar que a base da arquitetura não é um protótipo, já que ela não é descartada. Ao contrário, a base ganha

corpo durante a fase seguinte do PU.

20 Uma discussão extensiva de testes de software (inclusive testes de unidades) é apresentada nos Capítulos 17 a 20.

WebRef Uma interessante abordagem sobre o PU, dentro do contexto de desenvolvimento ágil, poderá ser encontrada em www . ambysoft .com/ unifiedprocess/ agileUP .html . Transição Produção incremento de software Versão modelagem construção planejamento comunicação emprego Construção Concepção Elaboração Figura 2.9 o processo unificado

74 paRtE 1 o ProCesso De software

É provável que, ao mesmo tempo em que as fases de construção, transição e produção este- jam 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 an- teriormente 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, subta- refas e artefatos de software) para ficar de acordo com suas necessidades.

m

P

P

e

O melhor processo de software é aquele próximo às pessoas que realizarão o trabalho. Se um modelo de processo de software for desenvolvido em nível corporativo ou organizacional, ele apenas será efetivo se for aberto a significativas adaptações a fim de atender às necessida- des da equipe de projeto (aquela que está efetivamente realizando o trabalho de engenharia de software). Num cenário ideal, você desenvolveria um processo que melhor se adequasse às suas necessidades e, simultaneamente, atendesse às necessidades mais amplas da equipe e da or- ganização. De forma alternativa, a própria equipe pode criar seu próprio processo e, ao mesmo tempo, atender às necessidades mais específicas dos indivíduos e às necessidades mais amplas da organização. Watts Humphrey ([Hum97] e [Hum00]) afirmam que é possível criar um “proces- so de software pessoal” e/ou um “processo de software da equipe”. Ambos requerem trabalho árduo, treinamento e coordenação, mas são alcançáveis.21