Rational Unified Process

O Rational Unified Process (RUP) é uma das ferramentas fulcrais para o trabalho desenvolvido pelas equipas piloto. É este modelo de processo de desenvolvimento de Software que as equipas irão utilizar como Framework para a realização do projeto, em contexto académico, mas com cliente real, enquadrado na disciplina de “Desenvolvimento de Aplicações Informáticas” (DAI). Em projetos de TIC, um processo de engenharia de Software fornece às equipas um meio para lidar com as causas mais comuns do seu fracasso, tentando deste modo criar soluções de qualidade, que tragam uma mais-valia e atendam às necessidades do cliente (Traa, 2006).

O RUP é um “processo de engenharia de Software. Este providencia uma abordagem disciplinada para a atribuição de tarefas e responsabilidades dentro de uma organização de desenvolvimento. O seu objetivo é garantir a produção de Software de alta qualidade, que vá ao encontro das necessidades dos seus utilizadores finais, dentro de um prazo e orçamento previsíveis” (Rational, 2001). A abordagem utilizada por este processo é a orientada a objetos, sendo baseado na notação UML (Unified Modeling Language) como técnica para modelação de requisitos e desenho. Este assenta num desenvolvimento em espiral e iterativo (Rational, 2001; Traa, 2006). O RUP define, para a efetiva abordagem ao desenvolvimento de Software por parte de equipas de desenvolvimento de Software, um conjunto de seis boas-práticas (Rational, 2001):

1. Desenvolver Software iterativamente: o processo sequencial de definição

da solução para o problema em questão, construção do Software, e teste do produto final para verificação da conformidade com o definido, não se adequa à complexidade atual dos sistemas. Através do desenvolvimento iterativo, isto é, uma sequência de atividades com um plano e critério de avaliação definido, cujo resultado é uma versão executável do Software, é possível obter feedback

30 por parte do cliente final, bem como obter uma visão permanente do estado do projeto. Com versões incrementais do Software, é também mais fácil a introdução de mudanças nos requisitos e funcionalidades, quer pela perceção da equipa do estado do Software, quer pelo feedback obtido do cliente.

2. Gerir requisitos: o RUP define o modo de captar, organizar e documentar as

funcionalidades do sistema, as restrições aplicáveis, decisões, bem como a captura e comunicação de requisitos de uma forma simples.

3. Utilizar uma arquitetura do Software baseada em componentes: É

promovida a utilização e definição de uma arquitetura flexível e fácil modificação, através do aproveitamento e reutilização de componentes (módulos) existentes ou novos.

4. Modelar o Software visualmente: utilizando o UML de modo a capturar a

organização e comportamento dos componentes e arquitetura de forma visual, os detalhes de implementação, tal como código, são “escondidos”. Deste modo é fornecida uma camada de abstração, que ajuda na comunicação e visualização de como os elementos do sistema se interligam.

5. Verificar a qualidade do Software: o RUP auxilia no planeamento,

desenho, implementação, execução e avaliação de testes para verificar os requisitos baseados na funcionalidade, desempenho e robustez do Software. A verificação da qualidade encontra-se em todas as atividades e envolve todos os participantes, através da utilização de critérios e métricas objetivos.

6. Controlar modificações ao Software: o RUP descreve como controlar e

monitorizar as mudanças necessárias e inevitáveis ao processo de desenvolvimento de Software.

31 No processo RUP, como se pode verificar na Figura 10, o eixo horizontal demonstra o aspeto dinâmico do processo, expresso em ciclos, fases, iterações e entregas (milestones). O eixo vertical representa o aspeto estático do processo, isto é, a sua representação e descrição em termos de atividades, artefactos, disciplinas e fluxos de trabalho (workflows) (IBM, 2007; Rational, 2001; Traa, 2006).

“O ciclo de vida do Software encontra-se dividido em ciclos, cada um responsável por uma nova versão do produto” (Rational, 2001). Cada um contém quatro fases consecutivas descritas seguidamente de uma forma resumida (IBM, 2007; Rational, 2001; Traa, 2006):

 Inception : nesta fase é obtida uma perceção inicial do projeto, bem como um consenso entre as partes interessadas sobre os objetivos, viabilidade e necessidade efetiva da sua realização. O foco é na compreensão geral dos requisitos e do âmbito do projeto. Deste modo, é obtido no final desta fase, uma visão geral dos requisitos, restrições e funcionalidades do projeto e produto,

32 uma delineação de aproximadamente 20% dos casos de uso1, uma análise inicial dos riscos inerentes ao projeto, bem como uma descrição do seu contexto e necessidade, definição dos critérios de sucesso, benefícios esperados, entre outros. É também definido o plano do projeto que contém as fases e número de iterações projetadas. Pode, caso desejado, ser criado um protótipo inicial do sistema.

 Elaboration : pretende-se nesta fase obter uma arquitetura base do sistema, bem como uma análise mais detalhada do projeto, nomeadamente, os seus objetivos, âmbito, e riscos estabelecidos como prioritários. Durante esta fase, obtém-se os restantes 80% dos casos de uso, estando todos os atores identificados, é revista a análise de riscos inicial, é criado um protótipo (novo ou incremental, se tiver como base o protótipo anterior), sendo também revistos e atualizados com eventuais alterações, outros documentos tais como o plano do projeto.

 Construction : esta é, normalmente, a fase mais extensa de todas. São clarificados os requisitos e restrições remanescentes, e é implementado o desenvolvimento do sistema com base na arquitetura definida na fase anterior. Todos os componentes e funcionalidades são desenvolvidas, testadas e integradas no produto final, ocorrendo várias evoluções do protótipo através de diversas iterações, até este corresponder às necessidades das partes interessadas, nomeadamente do cliente final. O foco é na gestão dos recursos e processos de modo a otimizar os custos, qualidade e cronograma.

 Transition : nesta última fase, ocorre a transição (entrega do produto) para o utilizador final do sistema desenvolvido, sendo esta versão possuidora de um nível de qualidade e maturidade considerados adequados para utilização em ambiente de produção. Após esta transição, ocorre muitas vezes devido à

1 Casos de Uso são, de uma forma resumida, a forma de representar o levantamento de requisitos na

linguagem UML. Representa os atores (intervenientes no sistema) e os cenários de interação destes com o sistema.

33 necessidade de resolver contratempos ou efetuar ajustes indispensáveis, inerentes ao processo de transição, a correção de problemas, desenvolvimento de novas versões aperfeiçoadas, bem como o término de funcionalidades que podem ter sido adiadas. Nesta fase ocorre o chamado "Beta Testing", que irá validar e verificar se o sistema vai de encontro às expectativas do utilizador final, conversão das bases de dados operacionais, formação dos utilizadores no novo sistema (ou módulo adicionado ao sistema existente, caso seja esse o caso). Nesta fase, para segurança, teste, bem como à necessidade de migração faseada dos dados do sistema antigo para o novo, surge muitas vezes o caso do sistema novo operar em paralelo ao sistema que irá ser substituído.

Tal como referido, no eixo vertical, que representa o aspeto estático do processo, encontram-se os fluxos de trabalho considerados fundamentais ao processo. Estes estão divididos em seis "fluxos de trabalho de engenharia" e três "fluxos de trabalho de suporte" ao processo. Para não fugir ao âmbito desta secção, que serve para oferecer um básico enquadramento dos modelos utilizados pelas equipas piloto, de modo a garantir uma melhor perceção do trabalho desenvolvido, apenas serão referidos os nomes dos nove fluxos de trabalho presentes no RUP, sem entrar em detalhe:

Seis workflows de engenharia:

1. Business modeling workflow 2. Requirements workflow 3. Analysis e Design workflow 4. Implementation workflow 5. Test workflow

6. Deployment workflow

Três workflows de suporte: 1. Project Management workflow

2. Configuration and Change Management workflow 3. Environment workflow

34