O C ICLO DE V IDA

O UP consiste da repetição de uma série de ciclos durante a vida de um sistema. Cada ciclo é concluído com uma versão do produto pronta para distribuição e é subdividido em quatro Fases relacionadas às metas ao longo do tempo. São elas a Concepção, a Elaboração, a Construção e a Transição. Cada Fase, por sua vez, é subdividida em iterações que passam por cinco Workflows (fluxos de trabalho) que estão relacionados à natureza das atividades. Cada Workflow é responsável por gerar seus respectivos artefatos através de um conjunto de atividades. Cada Artefato corresponde a uma documentação (como um modelo) ou outro objeto de valor a ser criado no desenvolvimento (como um componente de software). Por ser iterativo, cada fase percorre todo o conjunto de fluxos de trabalho (Workflows). Por ser incremental, cada iteração atualiza os artefatos gerados nas iterações anteriores.

3.2.4. ITERAÇÕES

Antes de sua conclusão, o ciclo de vida do UP passa por várias e sucessivas iterações. Cada uma destas iterações resulta em uma versão de um produto executável que constitui um subconjunto do produto final em

desenvolvimento e cresce de modo incremental de uma iteração para outra até se tornar o sistema final.

Cada iteração corresponde a uma das quatro fases do ciclo de vida. Em cada uma destas fases, ocorrem várias iterações, sendo que cada iteração passa pelas cinco Workflows. A importância de cada Workflow para uma iteração depende da fase em que esta se encontra, pois cada fase possui maior ênfase em determinado Workflow. A Figura 3.1, conhecida como “Gráfico de Baleias” apresenta o Workflow que é enfatizado em cada fase.

Figura 3.1. O “Gráfico de Baleias” (Adaptado de RUP, 2002)

Fonte: AZEVEDO Jr., D.P. Aplicação da Técnica de Modelagem de Negócio com UML a Processos Iterativos de Desenvolvimento de Software, Campos dos Goytacazes – RJ, 2003,

página 30

Nessa Figura podem ser observadas duas dimensões:

• o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve;

• o eixo vertical representa os Workflows, que agrupam as atividades de maneira lógica, por natureza.

A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.

A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, atividades, fluxos de trabalho, artefatos e papéis do processo. O gráfico mostra como a ênfase varia através do tempo.

3.2.5. FASES

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do UP é dividido em quatro fases seqüenciais. Cada fase refere-se a uma determinada meta a ser atingida ao longo do desenvolvimento. As fases correspondem a períodos determinados por pontos de controle ao longo do tempo. Em cada ponto de controle, ou seja, ao final de cada fase, é esperado um determinado estado de alguns artefatos do desenvolvimento. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase. As fases e seus marcos são apresentados na Figura 3.2.

Figura 3.2. As fases e os marcos de um projeto no UP. (Adaptado do RUP 2002)

Fonte: AZEVEDO Jr., D.P. Aplicação da Técnica de Modelagem de Negócio com UML a Processos Iterativos de Desenvolvimento de Software, Campos dos Goytacazes – RJ, 2003,

página 31

A seguir descreve-se sucintamente cada uma dessas fases (SEABRA Jr., 2001).

3.2.5.1. CONCEPÇÃO

O objetivo principal da fase de Concepção é conseguir a simultaneidade entre o cliente e o desenvolvedor nos objetivos do ciclo de vida do projeto, isto é, essa fase tem a meta de atingir o consenso entre todos os envolvidos no projeto, ao determinar os objetivos do ciclo de vida do mesmo. Esta fase é muito importante principalmente para novos esforços de desenvolvimento quando há um negócio significativo e riscos requeridos que precisam ser esclarecidos antes do

procedimento do projeto. Para projetos focados ou aprimoramento de um sistema já existente, a fase de Concepção é mais breve, mas ainda deve estar focalizada para assegurar que o projeto ainda é válido e possível de ser feito.

Dentre os principais objetivos desta fase se destacam:

• Estabelecer o escopo do software do projeto e suas condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto;

• Discriminar os dados de uso crítico do sistema, os cenários primários de operação que levará as trocas principais do projeto;

• Sugerir e talvez demonstrar pelo menos uma arquitetura candidata contra alguns cenários primários;

• Estimar o custo geral e a programação para todo o projeto; • Estimar os riscos em potencial;

Ao final desta fase o escopo do projeto deve ser compreendido, e os envolvidos que iniciam o projeto devem ter uma boa compreensão do retorno sobre os investimentos do projeto, isto é, o que é retornado para o que custa o investimento. Com esse conhecimento, é possível decidir se o desenvolvimento do projeto deve prosseguir em plena escala ou não. Isto é, no final desta fase deve-se ter definido o escopo do produto e ter demonstrado que o projeto é viável do ponto de vista do negócio da organização.

3.2.5.2. ELABORAÇÃO

Na fase de Elaboração, os requisitos que não foram considerados na fase de Concepção são reunidos e transformados em casos de uso; a base da arquitetura que irá guiar os trabalhos nas próximas fases é estabelecida; e detalhes adicionais do projeto são averiguados.

Nesse momento, o sistema é estudado mais amplamente, isto é, esta fase tem uma visão mais abrangente do sistema sem considerar detalhes.

Seu objetivo principal é definir uma arquitetura do sistema preliminar para prover uma base estável para o desenvolvimento do projeto e posteriores esforços de implementação na fase de Construção. A arquitetura evolui pela consideração dos requisitos mais significativos (aqueles que têm um grande impacto na arquitetura do sistema e que correspondem a aproximadamente 80%) e uma estimativa de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

Seus principais objetivos são:

• Assegurar que a arquitetura, os requisitos e os planos sejam bastante estáveis, e os riscos sejam suficientemente suavizados para que se possa detalhar o custo e o Cronograma Geral do desenvolvimento por completo; • Endereçar todos os riscos significantes da arquitetura do projeto;

• Estabelecer a linha de base da arquitetura derivada pelo endereçamento dos cenários significantes da arquitetura, que expõe tipicamente os altos riscos técnicos do projeto;

• Produzir um protótipo evolucionário de produção e componentes de qualidade, como também possivelmente um ou mais protótipos exploratórios, disponibilizando protótipos para suavizar riscos específicos como:

o Projetarrequisitos de trocas; o Reuso de componentes;

o A demonstração para investidores, clientes e usuários finais.

• Demonstrar que a linha de base da arquitetura vai suportar os requisitos do sistema num custo e num tempo razoáveis;

• Estabelecer um ambiente de suporte.

Para atingir esses objetivos, é também importante configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Nesta fase são executadas iterações com objetivo de reduzir a arquitetura, gerando visões bem descritas da mesma (visão de caso de uso, visão lógica, visão de processos, visão da implantação, visão da implementação) e um protótipo de

arquitetura executável. A quantidade de iterações dependerá da complexidade do sistema e dos riscos associados ao mesmo.

Ao final desta fase, estarão definidos o escopo e os objetivos detalhados do sistema, a escolha da arquitetura e a solução para os principais riscos.

3.2.5.3. CONSTRUÇÃO

O principal objetivo da fase de Construção é esclarecer os requisitos restantes e completar o desenvolvimento do sistema baseado na arquitetura de base. A fase de Construção é sobretudo um processo de manufatura, onde a ênfase é dada no gerenciamento de recursos e controle de operações para otimizar custos, programação, e qualidade. Durante a fase de Construção são detalhados os casos de uso remanescentes e a descrição arquitetural é modificada quando necessário. Os Workflows prosseguem através de iterações adicionais, preenchendo os modelos de análise, projeto e implementação. Subsistemas são interligados e testados, da mesma forma que o sistema como um todo.

Dentre seus objetivos se destacam:

• Minimização de custos de desenvolvimento pela otimização de recursos e evitando re-trabalhos desnecessários;

• Alcançar qualidade adequada de forma rápida e prática;

• Obter versões utilizáveis (alpha, beta, e outras versões de teste) rápido e praticamente;

• Completar a análise, projeto, desenvolvimento e teste de todas as funcionalidades requeridas;

• Desenvolver iterativamente e incrementalmente um produto completo pronto para ser transmitido aos usuários. Isto implica em descrever os casos de uso e outros requerimentos restantes, concluir o projeto, completar a implementação, e testar o software;

• Decidir se o software, os locais e os usuários estão todos prontos para a aplicação a ser implantada;

• Alcançar algum grau de paralelismo no trabalho de equipes de desenvolvimento. Mesmo em pequenos projetos, geralmente existem componentes que podem ser desenvolvidos independentemente uns dos outros, permitindo um paralelismo natural entre equipes. Este paralelismo pode acelerar significativamente as atividades de desenvolvimento, mas também aumenta a complexidade de gerenciamento de recursos e sincronização de fluxo de trabalho. Ter uma arquitetura robusta é essencial para atingir um paralelismo significativo.

Enquanto as fases de Concepção e Elaboração estão ligadas diretamente à modelagem do sistema, a fase de Construção é caracterizada pelo desenvolvimento, isto é, a construção de um sistema ou produto dentro dos parâmetros de custo e prazos.

3.2.5.4. TRANSIÇÃO

O foco da fase de Transição é assegurar que o software está pronto para o usuário final. A fase de Transição pode transpor várias iterações, e inclui testes do produto na preparação para liberação, e realizar ajustes mínimos baseados no retorno dos usuários. Neste ponto do ciclo de vida, o retorno dos usuários deve focar o ajuste fino do produto, na configuração, instalação e usabilidade.

Ao final do ciclo de vida da fase Transição, os objetivos devem ter sido alcançados e o projeto concluído. Em alguns casos, o fim de um ciclo de vida de Transição corrente pode coincidir com o início de outro ciclo de vida do mesmo produto, levando a uma nova geração ou versão do produto.

Entra-se na fase de Transição quando um projeto está maduro o suficiente para ser implantado no domínio do usuário final. Isto tipicamente requer que um subconjunto utilizável do sistema tenha sido terminado com um nível de qualidade aceitável e com documentação para o usuário (Manual do Usuário).

Dentre os objetivos da fase de Transição se destacam:

• Operações paralelas de substituição do sistema legado; • Treinamento dos usuários;

• Conserto de bugs;

• Preparar infra-estrutura de Hardware e Software do Cliente para receber o novo sistema.

O principal fator que determinará a conclusão da fase de Transição, e conseqüentemente a conclusão do projeto, é a “satisfação” do cliente.

3.2.6. WORKFLOWS

Cada uma das quatro fases do UP é dividida em iterações que por sua vez, realizam atividades que são responsáveis por gerar artefatos ao fim de cada uma dessas iterações. Ao conjunto dessas atividades dá-se o nome de Workflows de processo. São eles (SEABRA Jr., 2001):

3.2.6.1. REQUISITOS

Seu objetivo é capturar os requisitos que serão atendidos pelo produto de software. Os requisitos do sistema são especificados através da identificação das necessidades de usuários e clientes. Eles são expressos em casos de uso através do modelo de casos de uso. Um modelo de casos de uso é composto pelo conjunto de diagramas de casos de uso que compõem o sistema , e especifica como esse sistema será utilizado sob a perspectiva de clientes, usuários e desenvolvedores. A identificação de requisitos é realizada através do estudo de como os usuários precisam usar o sistema para realizar seu trabalho.

Durante a fase de Concepção, os requisitos mais importantes são identificados, delimitando o domínio do sistema, e durante a fase de Elaboração, a maioria dos requisitos remanescentes é capturada. Nada mais lógico, pois o objetivo destas fases é o entendimento e a delimitação do escopo do produto de software. A identificação da maioria dos requisitos permitirá aos desenvolvedores saber o quanto deverão se empenhar para desenvolver o sistema. Os requisitos que sobram são

capturados e implementados durante a fase de Construção, enquanto, na fase de Transição quase não há requisitos a serem capturados, a menos que ocorram mudanças nos mesmos. O Workflow Levantamento de Requisitos aborda as seguintes atividades:

• Identificar casos de uso; • Priorizar casos de uso; • Detalhar casos de uso;

• Estruturar o modelo de caso de uso.

Portanto, o Workflow de Levantamento de Requisitos foca suas atividades na identificação de entidades que interagem com o sistema (atores) e dos requisitos funcionais deste sistema para cada um dos atores (casos de uso) e no agrupamento destes elementos sob determinado contexto de forma a construir diagramas de casos de uso cujo conjunto formará o modelo de casos de uso.

3.2.6.2. ANÁLISE

Seu objetivo é o de criar o modelo de análise que tem como função refinar os requisitos especificados no Workflow de Requisitos através da construção de diagramas de classes conceituais, permitindo argumentações a respeito do funcionamento intero do sistema. O modelo de análise fornece mais poder expressivo e formalismo, como diagramas de interações e diagrama de gráficos de estado que representam a dinâmica do sistema. Este Workflow é mais utilizado durante a fase de Elaboração, contribuindo para a definição de uma arquitetura estável e facilitando o entendimento detalhado dos requisitos.

Ao estruturar os requisitos do sistema, o modelo de análise fornece uma estrutura com foco na manutenção dos mesmos. Esta estrutura serve, não só para a manutenção de requisitos, como também serve de entrada para os Workflows de Projeto e Implementação. Desta forma, o modelo de análise pode ser visto como o primeiro passo para o desenvolvimento do modelo de projeto, mesmo sendo considerado um modelo particular.

3.2.6.3. PROJETO

Neste Workflow o sistema é moldado e sua forma é definida de maneira a suprir as necessidades especificadas nos requisitos. Também é definido um modelo de projeto que é construído com base no modelo de análise definido no Workflow anterior.

O modelo de projeto criado neste Workflow descreve o sistema a nível físico, tendo como principal função obter uma compreensão detalhada dos requisitos do sistema, levando em consideração fatores como linguagem de programação, sistemas operacionais, tecnologias de banco de dados, interface com o usuário, etc. Seu enfoque está entre o fim da fase de Elaboração e o início da fase de Construção.

O Workflow de Projeto, muitas vezes é considerado uma extensão do Workflow de Análise, pois, enquanto este último se interessa por o que o sistema deve fazer, ele diz respeito a como os requisitos serão implementados.

3.2.6.4. IMPLEMENTAÇÃO

Este Workflow se baseia no produto resultante do Workflow de Projeto que é o Modelo de Projeto. Ele tem como objetivos a organização do código em termos de implementação de subsistemas, a implementação das classes e objetos em termos de componentes, o teste dos componentes em termos de unidades e a integração dos códigos produzidos.

O Workflow de Implementação 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 uma sucessão de etapas pequenas e gerenciáveis;

• Testar as implementações e integrá-las, compilando-se em um ou mais arquivos executáveis, antes de enviá-los ao próximo Workflow.

Ele é mais usado durante a fase de Construção e apesar de ter suas características próprias, a maior parte de suas atividades é realizada de forma quase mecânica, pelo fato das decisões mais difíceis terem sido tomadas durante o Workflow de Projeto.

3.2.6.5. TESTE

Neste Workflow os componentes executáveis gerados no Workflow de Implementação, são testados exaustivamente antes de serem disponibilizados aos usuários finais. O principal objetivo deste Workflow é analisar, através de testes, se os requisitos foram atendidos. Componentes que possuírem defeitos retornarão aos Workflows anteriores onde seus problemas serão corrigidos.

Em suma, o papel do Workflow de Teste é verificar se os resultados do Workflow de Implementação cumprem os requisitos estipulados por clientes e usuários para que possa ser decidido se o sistema necessita de revisões ou se o processo de desenvolvimento pode continuar. Sua ênfase será maior no final da fase de Construção e no início da fase de Transição.