RUP - Rational Unified Process

1 -  INTRODUÇÃO:

Uma metodologia para desenvolvimento de sistemas especifica a sequência de passos a serem seguidos durante o desenvolvimento de um sistema de informação. A cada um destes passos, associa-se um conjunto de atividades, seus produtos e as regras de verificação que garantem a passagem para a próxima fase [Pressman, 2001].

2 - O QUE É RUP (RATIONAL UNIFIED PROCESS)

O RUP - Rational Unified Process (Processo Unificado Rational ), é uma metodologia (ou processo) iterativa, onde cada iteração representa um ciclo completo de desenvolvimento, desde a captação de requisitos na análise até a implementação e a realização de testes, resultando numa versão executável do sistema. Por sua vez, as iterações são agrupadas em fases. Uma fase é o período de tempo entre dois marcos de progresso, onde objetivos são alcançados, artefatos são concluídos e decisões são tomadas em relação à passagem para a fase seguinte.
Criado pela Rational Software Corporation, fornece-nos técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.
O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação.
É preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser totalmente customizável torna possível que seja adaptado para projetos de qualquer tamanho.
O RUP é na verdade um produto composto de material de referência na forma de páginas HTML, descrevendo toda uma metodologia.

3 - PRINCÍPIOS BÁSICOS DO RUP

O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquitetura e iteração. Ele é dito dirigido a casos de uso, pois são os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, são criados uma série de modelos de análise, projeto e implementação, que realizam estes casos de uso. É centrado em arquitetura, pois defende a definição de um esqueleto para a aplicação (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP é iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em porções menores ou mini-projetos. Esses três conceitos são igualmente importantes. A arquitetura provê a estrutura para guiar o desenvolvimento do sistema em iterações, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iteração.

3.1 - Outros Princípios:

• Atacar os riscos cedo e continuamente;
• Certificar-se de entregar algo de valor ao cliente;
• Focar no software executável;
• Acomodar mudanças cedo;
• Liberar um executável da arquitetura cedo;
• Construir o sistema com componentes;
• Trabalhar junto como um time;
• Fazer da qualidade um estilo de vida, não algo para depois.

A figura 01 mostra a arquitetura do RUP, que tem duas estruturas (ou dimensões): o eixo horizontal representa o tempo e mostra aspectos do ciclo de vida do processo na medida em que ele se desenvolve. O eixo vertical representa o núcleo das disciplinas do processo, que agrupa as atividades de acordo com a natureza de cada uma. Cada disciplina possui um fluxo de trabalho específico.

4 - A ESTRUTURA DINÁMICA DO RUP

Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver uma mudança neste período para as funções em questão.

figura 01 – Estrutura do RUP

5 - FASES DE DESENVOLVIMENTO O processo de desenvolvimento é dividido em ciclos, sendo que o ciclo de desenvolvimento é subdividido em 4 fases consecutivas. Estas fases são concluídas tão logo uma milestone é alcançada. Uma milestone define uma etapa, na fase, na qual decisões críticas são feitas ou objetivos são alcançados.

            5.1 - Concepção: nesta fase, é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sobre o planejamento e, por conseguinte, é necessário levantar requisitos do sistema e preliminarmente analisá-los. Ao término dessa fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento, é nesta fase que é apresentada o plano de projeto, caso de uso inicial e o glossário do projeto, entre outros. ;

            5.2 - Elaboração: o propósito desta fase é analisar mais refinadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Esta é a fase mais crítica de todas, pois ao final desta fase a engenharia é considerada completa e os custos para modificação do sistema aumentam a medida que o projeto avança. Do ponto de vista administrativo, é ao final desta fase que um projeto deixa de ser uma operação de baixo risco e baixo custo para se tornar uma operação de alto risco e alto custo.Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do desenvolvimento.

            5.3 - Construção: durante esta fase, um produto completo é desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transição à comunidade usuária.

            5.4 - Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que vão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 01, em que a cor preta indica grande ênfase, enquanto a cor branca indica muito pouca ênfase. Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho de projeto e implementação seja realizado para prototipar a arquitetura, evitando certos riscos técnicos. Na fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir e rechear o protótipo inicial, até obter o primeiro produto operacional. Finalmente, a fase de transição concentra-se nos testes, visando garantir que o sistema possui o nível adequado de qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos esquecidos adicionados.

 6 – A ESTRUTURA ESTÁTICA DO RUP

Além das fases dinâmicas do RUP, existem outros quatro conceitos básicos:

trabalhadores (workers), atividades (activities), artefatos (artifacts) e fluxos de trabalho

(workflows). Eles são agrupados pelas disciplinas relacionadas no eixo vertical da figura 01.

Segundo Kroll e Kruchten (2003), uma disciplina é uma coleção de atividades relacionadas que estão ligadas a uma área de interesse dentro do processo. As disciplinas do RUP são descritas por meio de fluxos de trabalho que mostram uma seqüência significativa de grupos de atividades que produz um determinado resultado. Cada grupo de atividades é descrito por um diagrama de detalhamento de fluxo de trabalho, já que cada fluxo de trabalho envolve uma grande dimensão. Esses diagramas mostram todas as atividades do grupo, os papéis envolvidos e os artefatos de entrada e saída. Um artefato é um produto de trabalho do processo, ou seja, o que é produzido no processo de desenvolvimento e/ ou utilizado por ele (um modelo ou uma classe, por exemplo). Os papéis usam os artefatos na execução das atividades.

Existem nove (9) fluxos de trabalho no RUP, referentes às disciplinas nele definidas, que representam uma partição de todos os trabalhadores e atividades dentro de um agrupamento lógico. São divididos em 6 (seis) fluxos de trabalho de engenharia e 3 (três) de suporte.

Os fluxos de trabalho de engenharia são:

• Modelagem de Negócio;
• Requisitos;
• Análise e Projeto;
• Implementação;
• Teste;
• Implantação.

Os fluxos de trabalho de suporte são:

• Gerenciamento de Projeto;
• Gerenciamento de Configuração e Mudança;
• Ambiente.

7 – TAREFAS:

Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

7.1 - Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário. Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30. Exemplos de papéis são: analista de sistemas, analista de negócio, etc.

7.2 - Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artefatos) gerados ao longo do projeto. Estes documentos são descritos em detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários das ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a usar ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

8 – CASOS DE USO

Um caso de uso é uma descrição de como um ator ou vários atores usam um sistema para alcançar um objetivo, incluindo o que o sistema faz para que este intento seja alcançado (BITTNER, 2003).

Phillips e Kemp (2002) afirmam que os casos são primordiais ao RUP porque estabelecem a base para o desenvolvimento, uma vez que provêem a visão funcional (tarefa), modelando o caminho pelo qual um ator interage com o sistema. Essa visão funcional é obtida pela descrição dos requisitos funcionais do sistema a ser construído.

Assim, cada caso de uso deve descrever um uso do sistema e envolve as seqüências de interações, bem como a manipulação de objetos. São representados na UML pelo diagrama de casos de uso, que é detalhado por meio dos fluxos de eventos, na especificação dos casos de uso.

Os casos de uso executam um papel bem mais amplo no RUP, fora do espaço de requisitos, em direção à análise, projeto, implementação e testes de um sistema de software, sendo o RUP, por isso, um processo que tem uma abordagem guiada por casos de uso. Isso significa que os casos de uso definidos para um sistema são a base para todo o processo de desenvolvimento.

Bittner e Spence (2002) definiram um ciclo de vida dos casos de uso, em que estes iniciam com desenhos que os mostram juntamente com seus atores, interagindo com o sistema, durante esses casos de uso. Logo depois, entretanto, eles evoluem, sendo inseridas breves descrições (parágrafos curtos) que resumem o que acontece com cada um deles (chamadas fluxos de eventos). Apesar de essas descrições serem suficientes para esclarecer, são necessárias mais informações. Por isso, através delas são gerados esboços de fluxos de eventos, que irão dar uma indicação do tamanho e complexidade dos casos de uso.

9 – REQUISITOS DO SISTEMA

Como o RUP é guiado por casos de uso e estes especificam grande parte dos requisitos de um sistema de software, além de promover outras atividades do processo unificado, será descrito a seguir o que vem a ser um requisito de sistema, bem como sua importância.

Um requisito de um sistema de software é definido por Dorfmann et al (1990) como uma capacidade do software necessária para o usuário resolver um problema e alcançar seu objetivo, ou, dito de outra maneira, é uma capacidade do software que deve ser encontrada ou possuída por um sistema ou componente para satisfazer um contrato, padrão, especificação ou outro formalismo.

Os requisitos de um sistema de computação são resumidos por Blashek (2002) como aqueles que constituem uma especificação das características e propriedades do sistema ou uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.

Enfim, um requisito é tudo o que pode ser descrito como um serviço ou restrição de um sistema, que é derivado de uma ou mais características do sistema a ser construído, as quais devem atender às necessidades de um ou mais usuários.

Existem dois tipos de requisitos: os que são específicos do usuário e os pertinentes a sistema. Os primeiros consistem num informativo (em linguagem natural) do que o sistema deve ter, assim como de suas restrições, enquanto os pertinentes ao sistema determinam o que foi descrito nos primeiros, porém de forma detalhada (como um contrato). Os dois se distinguem somente no nível de detalhes.

Com relação aos requisitos de sistema, que serão, em sua maioria, modelados em diagramas de casos de uso, são divididos em três (3):

9.1 - Requisitos funcionais: aqueles que podem ser formalizados por meio de um modelo de casos de uso e seus fluxos (como visto anteriormente), especificando o comportamento de entrada e saída de um sistema e o que deve ser feito (as funcionalidades) em um sistema;

9.2 - Requisitos não funcionais: descrevem os atributos do sistema ou do ambiente do sistema, especificando ‘como’ deve ser feito. Geralmente, são restrições das funcionalidades oferecidas pelo sistema, como requisitos legais (regulamentos), padrões aplicáveis, atributos de qualidade do sistema, que incluem requisitos de usabilidade, confiabilidade, desempenho e portabilidade, além de outros, como sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de projeto;

9.3 -  requisitos de domínio: são derivados do domínio da aplicação, refletindo características deste domínio.

10 - OS ARTEFATOS:

Numa pesquisa realizada por Souza et al (2004), na busca de identificar os artefatos de maior importância para a manutenção de um software, foram consultados sessenta e sete (67) profissionais com experiência prática em manutenção de software. Nessa pesquisa, os artefatos foram divididos por abordagem, ou seja, em abordagem estruturada e orientada a objetos. Esses requisitos, quer tenham sido listados (na abordagem estruturada), ou formalizados em modelos de casos de uso de suas especificações (na abordagem orientada a objetos), juntamente com o código fonte e os modelos de dados (MER), foram considerados os artefatos mais importantes a serem considerados em uma manutenção de software.

Esse resultado, ainda em Souza et al (2004), comprovou a preocupação dos profissionais da área de manutenção com a identificação de uma maior semântica que os modelos pudessem expressar independente da forma como foram implementados.

Portanto, as documentações dos requisitos de um software, bem como seu gerenciamento podem levar a um processo de manutenção menos desgastante, mais preciso.