Uykuda Periyodik Uzuv Hareketleri (PLMS):

A Figura 14 apresenta a arquitetura global do Rational Unified Process, a qual se apresenta com duas dimensões. A Dimensão Dinâmica apresenta o ciclo de vida do processo e seu desdobramento ao logo do tempo, os quais são expressos em termos de ciclos, fases, iterações e marcos. A outra é a Dimensão Estática, responsável pela apresentação dos fluxos essenciais do processo, que agrupa as atividades por sua natureza [KRUCHTEN, 2003].

Uma das práticas centrais do RUP é o conceito de Desenvolvimento com Iterações. O RUP organiza os projetos em Fases e Disciplinas (Figura 14). Cada fase corresponde a uma etapa de desdobramento do projeto, possuindo uma ou mais iterações. Onde iteração é o momento em que é gerado um executável. Neste momento abre-se a oportunidade de correção de erros, o que agrega o conceito de melhoria contínua ao processo. Uma Disciplina reúne um conjunto de atividades, workflows, artefatos e papéis pertencentes a uma determinada área do projeto global. Dimensão Dinâmica Dimensão Estática Primeira iteração da fase de Construção Dimensão Dinâmica Dimensão Estática Dimensão Dinâmica Dimensão Estática Primeira iteração da fase de Construção Fonte : [Rational, 2003] Figura 14 - Estrutura do RUP

3.2.1. A estrutura estática do RUP

Garantir de forma inequívoca que podemos atender a todos os requisitos no inicio de um grande projeto é muito difícil. Principalmente, porque os requisitos podem variar ao longo do processo por muitos motivos como, por exemplo: os usuários podem mudar de opinião como conseqüência de uma maior compreensão do problema, o problema pode mudar em resposta a fatores externos, a tecnologia subjacente muda, o mercado muda e, por fim, pelo fato de ser difícil identificar todos os requisitos com detalhes e precisão suficiente. Uma outra dificuldade é garantir que o projeto proposto no papel é de fato a solução certa para o problema. A dificuldade deve-se ao fato da engenharia de software, e das teorias subjacentes, estarem em processo de consolidação, sendo ainda difícil sua compreensão. Estes comentários justificam o uso da abordagem de processo seqüencial (dimensão estática).

“A especificação de um processo RUP é feita descrevendo-se quem está fazendo o quê, como, quando e porque. O RUP baseia-se assim em quatro elemento primários (Kruchten, 2003), a saber: Trabalhadores; Atividades; Artefatos e Fluxos.”

Os Trabalhadores são os agentes (funcionários ou grupo de funcionários) que são responsáveis por atividades, que produzem artefatos. Os artefatos produzidos evoluem ao longo do ciclo de desenvolvimento, na medida que passam de uma fase para outra, adquirindo o grau de amadurecimento necessário. Os artefatos estão organizados no RUP em cinco conjuntos de informação. O primeiro é o Conjunto de gerenciamento, onde todos os artefatos são relacionados ao negócio do software e ao gerenciamento do projeto (plano de desenvolvimento de software, processo atual usado pelo projeto, análise empresarial etc.). O segundo é o conjunto de requisitos, grupo relacionado à definição do sistema (documento de visão empresarial; documento com os requisitos, especificação e modelo de caso de uso etc.). O terceiro é o Conjunto de projeto, o qual contém descrição do sistema a ser construído (modelo do projeto, descrição da arquitetura, modelo de teste). O quarto é o Conjunto de implementação que contém o grupo de artefatos que inclui os códigos fonte e executáveis, os arquivos de dados associados ou os arquivos necessários para produzi-los. O último é o Conjunto de distribuição, contendo o conjunto de informações entregues como produto do processo (material de instalação, documentação do usuário e material de treinamento). Complementando o processo temos os fluxos, os quais descrevem as seqüências de atividades que produzem os resultados de valor observável. O RUP organiza o conjunto de atividades em nove fluxos centrais (Figura 14) de processo, que são divididos em seis fluxos de engenharia e

três de suporte. Os fluxos de engenharia são: Fluxo de modelagem empresarial, Fluxo de requisitos, Fluxo de análise e projeto, Fluxo de implementação, Fluxo de teste e Fluxo de distribuição (Figura 14). Os fluxos centrais de suporte são: Fluxo de gerenciamento de projeto, Fluxo de configuração e gerenciamento de mudança e Fluxo de ambiente.

Os fluxos centrais são de grande abrangência. O RUP é decomposto através do detalhamento dos fluxos, que expressam um grupo de atividades muito relacionadas que produzem um resultado intermediário interessante. No detalhamento do fluxo define-se também como as atividades interagem através dos diferentes artefatos.

Segue uma descrição sumária dos fluxos [KRUCHTEN, 2003], descritos obedecendo a seqüência com que eles surgem no início do projeto.

O Fluxo de gerenciamento de projeto enfoca aspectos específicos dos processos de desenvolvimento iterativo, quais sejam: planejamento de um projeto iterativo pelo ciclo de vida e planejamento de uma iteração em particular, administração de risco, monitoramento do progresso de um projeto iterativo e medidas. Entre os objetivos do fluxo de gerenciamento de projeto podemos citar: alocação de tarefas e responsabilidades para uma equipe de pessoas e monitoração do progresso relativo em relação ao planejado para identificar problemas potenciais, a medida que o projeto é desenvolvido. Neste fluxo são produzidos dois planos. O primeiro deles é o Plano de fase, que é um plano simples. Deve ser elaborado um plano de fase por projeto contendo: o objetivo do ciclo de vida; a arquitetura do ciclo de vida; a capacidade operacional inicial e a previsão para lançamento do produto. Esse plano inclui também o perfil da provisão de pessoal (recursos) e datas de fatos secundários (fim de cada iteração e seu objetivo primário). O segundo documento é o Plano de iteração, que é feito para cada iteração do processo, consistindo assim de um refinamento do plano de fase. No plano de iteração são definidas as tarefas e a distribuição da(s) equipe(s) e indivíduo(s). O plano contém ainda as datas das construções principais, da chegada de componentes de outras organizações e revisões principais.

O Fluxo de modelagem de negócio tem por objetivo tornar possível o entendimento da estrutura e da dinâmica da organização usuária do sistema e dos problemas atuais da organização, permitindo a eventual identificação de melhorias potenciais. Este fluxo permite também derivar as exigências de sistema necessárias para o suporte da organização. Na busca dessas metas, este fluxo descreve como desenvolver uma visão da organização alvo, seus processos, papéis e responsabilidades.

As metas previstas para o Fluxo de requisitos são: estabelecer e manter acordos com os usuários definindo o que o sistema deve fazer e porque; proporcionar ao desenvolvedor do

sistema um entendimento melhor dos requisitos do sistema; delimitar o sistema; fornecer uma base para o planejamento dos conteúdos técnicos das iterações; fornecer uma base para o cálculo do custo para o desenvolvimento do sistema e; por fim, definir a interface entre os usuários e o sistema, focando nas necessidades e metas dos usuários. Na busca por essas metas, o fluxo de requisitos descreve como definir uma visão do sistema e como traduzir essa visão em um modelo de caso de usos que, com especificações adicionais, define em detalhes os requisitos de software do sistema. O Fluxo de requisitos também descreve como usar atributos de requisitos na administração da extensão e das mudanças de requisitos do sistema. O Fluxo de análise e projeto possui como objetivo a tradução dos requisitos em uma especificação que descreva como implementar o sistema. O entendimento dos requisitos e sua transformação em um projeto de sistema concretizam essa tradução. São utilizados casos de uso para identificar um conjunto de objetos que é subseqüentemente refinado em classes, subsistemas e pacotes. Este fluxo resulta em um modelo de projeto apresentado em três visões arquitetônicas: uma visão lógica, que apresenta a decomposição do sistema num conjunto de elementos lógicos (classes, subsistemas, pacotes e colaborações); uma visão de processo, que incorpora esses elementos aos processos e linhas (conjunto de artefatos) nos sistemas e; uma visão de distribuição associa os processos a um conjunto de nodos nos quais eles serão executados.

Como já mencionado, o RUP possui como característica fundamental a interação incremental ao longo do ciclo de vida de um processo. No fluxo de implementação essa abordagem é traduzida na construção de protótipos que evoluem na direção da versão final do sistema. Em termos gerais, a proposta do fluxo de implementação baseia-se na definição da organização do código em termos de subsistemas de implementação organizados em camadas. O fluxo prevê também que as classes e objetos sejam implementados como componentes (arquivos-fonte, binários, executáveis e outros). Os componentes desenvolvidos devem ser testados como unidades (componentes individuais) e integrados em um sistema executável.

O fluxo de teste torna possível a avaliação da qualidade do produto que está sendo produzido. Os testes devem ser realizados em todas as fases do ciclo de vida do sistema, sendo parte vital do mecanismos de avaliação e melhoria contínua ao longo do projeto. O fluxo de teste inclui procedimentos para verificação do funcionamento do componentes isolado, verificação das interações entre componentes; verificação do atendimento correto de todos os requisitos e de procedimentos para que se possa identificar e assegurar que todos os defeitos descobertos sejam corrigidos antes do software ser distribuído.

O Fluxo de gerenciamento de configuração e mudanças abrange três funções interdependentes. A primeira delas é o gerenciamento de configuração, que está relacionada à estrutura do produto e lida com a questão de identificação dos artefatos, versões e dependência ente artefatos. Outra facilidade que deve ser suportada é a identificação e gestão de conjuntos consistentes de artefatos relacionados, bem como o controle sobre a distribuição e sobre as condições de execução e desenvolvimento das tarefas aos indivíduos. A segunda é o gerenciamento de solicitações de mudança, que também está relacionado à estrutura de processo, tratando da coleta e gerenciamento das solicitações de mudanças geradas por entidades internos e externos e seus impactos no projeto (custo e prazo). Por fim, o gerenciamento do estado e medidas lida com a estrutura de controle do projeto. Tem como missão a coleta de informações para o gerenciamento do projeto, das ferramentas que suportam as funções de gerenciamento de configuração e solicitação de mudança.

A meta do fluxo de ambiente é fornecer suporte adequado para a organização do desenvolvimento utilizando ferramentas, processos e métodos. Entre as atividades associadas a este fluxo estão a seleção, aquisição e configuração de ferramentas adequadas, e a realização de serviços técnicos necessários para o bom desenrolar do processo como, por exemplo, a implantação da infra-estrutura de tecnologia da informação (TI), administração de contas de usuários, backups , etc.

O Fluxo de desenvolvimento é responsável por todos os artefatos entregues aos usuários finais ou clientes, bem como pela organização do suporte de marketing, distribuição e vendas. Envolve as seguintes atividades: teste do software em seu ambiente operacional final (beta teste), empacotamento do software para entrega, distribuição e instalação do software, treinamento dos usuários finais e da força de vendas (saída do produto) e migração do software existente, com eventuais conversões de banco de dados.

3.2.2. A estrutura dinâmica do RUP

A abordagem iterativa propõe que se desdobre o ciclo de vida de um projeto grande numa sucessão de projetos menores em cascata. A idéia básica é identificar alguns requisitos e riscos, fazer um pequeno projeto, implementar e validar. Após a iteração do processo, deve-se então considerar novos requisitos e iniciar um novo ciclo, até que se tenha obtido um produto de qualidade, completo, estável e entregue aos usuários finais. Essa abordagem torna possível a identificação e solução de problemas nas fases iniciais do processo, evitando assim seu acúmulo ao longo do desenvolvimento, o que poderia comprometer o sucesso do projeto.

Como mostra a Figura 14, o processo iterativo, proposto pelo RUP, é organizado em fases. Diferentemente das etapas (fluxos) descritas na dimensão estática, que são seqüenciais; as fases são completamente ortogonais, sendo concluídas com um marco principal. Observa-se que cada fase contém todos os fluxos de engenharia e suporte da dimensão estática, entretanto a ênfase dada a cada atividade muda de uma iteração para a próxima.

O RUP determina que as seguintes fases sejam cumpridas : Iniciação, Elaboração, Construção e Transição. Na Iniciação deve-se procurar entender o que se deseja ter como produto final do projeto e a sua extensão. O marco22 dessa fase é o objetivo do ciclo de vida (LCO). Na fase de Elaboração, o objetivo aqui é definir como construir o produto desejado. Para tal, é preciso realizar um planejamento o mais detalhado possível do projeto, contendo as atividades e recursos necessários. O marco dessa fase é a arquitetura do ciclo de vida (LCA). Durante a fase de Construção visa-se a elaboração de uma versão beta do seu produto. É preciso construir a visão, a arquitetura e os planos do projeto com o intuito de gerar um produto pronto para os usuários. O marco dessa fase é a capacidade operacional inicial ( IOC). Temos então a fase de Transição, momento em que a versão final do produto é entregue. Todos os processos que contribuirão para a satisfação dos usuários devem ser concluídos: a entrega do produto dentro do prazo, o apoio ao usuário e a manutenção do produto. O marco dessa fase é o lançamento do produto. O término dessa fase coincide com a conclusão do ciclo de desenvolvimento do software.

Ao final dessas quatro fases (iniciação, elaboração, construção e transição) teremos concluído um ciclo de desenvolvimento, com a conseqüente construção de uma versão do software. Ao longo do ciclo de vida do software ele passará por evoluções, que se materializarão por novas versões de software, que serão construídas em novos ciclos, definidos no RUP como sendo ciclos de evolução.

Os ciclos de evolução podem ser motivados por mudanças do contexto de usuário, de tecnologia ou por questões de mercado (competição).