Rational Unified Process - RUP

Os itens que compreendem os requisitos são: relacionamento externo, funções, requisitos de desempenho, requisitos lógicos de banco de dados, restrições de projeto, atributos de sistema e a organização dos requisitos específicos.

Por fim, a ERS é composta também por comentários finais e informações para tornar a compreensão da mesma mais fácil, tais como tabela de conteúdos, índice e apêndices.

Figura 6. Disciplinas, fases e iterações do RUP Fonte: Adaptado de Rational (2002)

Kruchten (2000 apud SCHLICKMANN JÚNIOR, 2002) descreve as quatro fases de maneira simplificada, conforme são apresentadas a seguir:

• Concepção: visa determinar o escopo do projeto, planejar e preparar os casos de negócio, sintetizar uma arquitetura provável de ser utilizada e preparar o ambiente do projeto. O marco dessa etapa é avaliar a viabilidade do projeto;

• Elaboração: nessa fase, o projeto e a implementação do software estão voltados à arquitetura, fazendo com que alguns riscos técnicos sejam suavizados;

• Construção: fase na qual é desenvolvido e detalhado o protótipo inicial do produto operacional. O foco dessa fase é dirigido ao projeto e implementação; e

• Transição: visa garantir que o nível de qualidade do software seja suficiente para cumprir os objetivos propostos no início do projeto, fixando problemas, treinando usuários, ajustando características e adicionando novas funcionalidades. Essa fase também contempla a produção e entrega do software final.

Segundo Pires et al. (2004), uma disciplina é uma coleção de atividades relacionadas que se interligam por meio de sua área de interesse dentro do processo. A seqüência de atividades agrupadas com a produção de um resultado final é descrita através das disciplinas do RUP. Para

cada conjunto de atividades existe um diagrama de detalhamento do fluxo de trabalho. Esses, por sua vez, dão uma visão geral do contexto, mostrando as atividades, papéis envolvidos e os artefatos de entrada e saída.

Segundo Rational (2002), um papel é uma definição abstrata para um conjunto de atividades executadas e seus artefatos acoplados. Geralmente os papéis são realizados por uma pessoa ou um conjunto de pessoas trabalhando em equipe. Um membro de uma equipe pode exercer a função de vários papéis ao mesmo tempo.

As atividades estão diretamente relacionadas com os artefatos. Os artefatos são responsáveis por fornecer as entradas e as saídas para as atividades, é através deles que a informação é passada entre as atividades (RATIONAL, 2002).

Rational (2002) também afirma que uma iteração abrange as atividades do desenvolvimento que levam a uma versão de produto estável juntamente com todos os outros elementos necessários.

As iterações estão em consonância com todas as disciplinas do RUP. A duração de cada iteração depende do tamanho e da natureza do projeto. É provável que múltiplas configurações sejam construídas em cada iteração, conforme especificado no plano de integração para cada uma dessas.

A primeira disciplina apresentada é a disciplina de Modelagem de Negócios. O propósito principal dessa disciplina, segundo Rational (2002), é mostrar a estrutura e as características dinâmicas da organização nas quais o sistema irá funcionar, bem como fornecer uma visão geral do objetivo da organização identificando problemas e implementando melhorias. Essa disciplina visa também fornecer entendimento do objetivo geral da organização aos stakeholders modificando os requisitos de sistema para que esteja adequado aos objetivos da mesma. Informações importantes para a disciplina de requisitos são geradas a partir da disciplina de modelagem de negócios. Para complementar a Modelagem de Negócios, é gerado o glossário e a especificação de negócio complementar.

A disciplina de requisitos, resumidamente, tem por objetivo manter entendimento entre o que o cliente deseja e o que o software deve executar (RATIONAL, 2002). Por ter maior relevância neste trabalho, a disciplina de requisitos é abordada detalhadamente na Seção 2.3.2.2.

Transformar os requisitos em um sistema propriamente dito, segundo Rational (2002), é um dos propósitos da disciplina de análise e projeto. Criar uma arquitetura robusta adaptando o projeto

dos propósitos dessa disciplina. As entradas para essa disciplina são fornecidas pela disciplina de requisitos, conforme explanado na Seção 2.3.2.2.

Os propósitos da disciplina de implementação são: (i) definir a organização do código, em termos de sistemas organizados em camadas; (ii) implementar componentes de classes e objetos;

(iii) testar os componentes desenvolvidos como módulos e (iv) integrar os resultados produzidos por desenvolvedores individuais ou equipes em um sistema executável. Essa disciplina delimita como as classes individuais serão testadas.

A disciplina de testes atua como um provedor de serviços às outras disciplinas. Para isso, através dela são procuradas e documentadas as falhas na qualidade do software, a validação do software também é realizada, bem como a validação dos requisitos para saber se foram implementados de forma correta ou não.

A descrição das atividades associadas para assegurar que o software esteja disponível para os usuários finais é o papel da disciplina de implantação. Essa disciplina descreve três modos de implantação do produto: instalação personalizada, produto de forma “compacta” e acesso ao software através da Internet. Embora o auge das atividades da disciplina de implantação esteja focado na fase de transição, algumas atividades podem ocorrer em fases anteriores para fazer o planejamento e a preparação para a implantação.

A disciplina de ambiente está focada nas atividades necessárias para configurar os processos para um projeto. Nessa disciplina são descritas as atividades requeridas para desenvolver a base de um projeto. O propósito principal dessa atividade é fornecer uma organização do software com o ambiente onde ele está sendo desenvolvido.

O gerenciamento de projeto de software, segundo Rational (2002), é a arte de poder fazer o balanceamento de objetivos competitivos, controlando riscos, e superando restrições para entregar um produto de software que atenda as necessidades dos clientes e dos usuários. A disciplina de gerenciamento de projetos é apresentada de forma a fornecer subsídios para fazer o controle do projeto, aumentando assim a probabilidade de que o produto seja entregue com sucesso. Em suma, essa disciplina fornece a estrutura para o controle, planejamento e o monitoramento de projetos.

O gerenciamento de configuração é essencial para controlar os inúmeros artefatos que são produzidos quando muitas pessoas estão envolvidas em um projeto. Para isso, a disciplina de gerenciamento de configuração e mudança ajuda a evitar confusões e garante que não haja conflitos

com os artefatos resultantes. Essa disciplina envolve a identificação, as mudanças de restrições, a definição e o gerenciamento dos itens de configuração.

2.3.2.2. Disciplina de Requisitos

Segundo Rational (2002), os propósitos dessa disciplina são os seguintes:

• Estabelecer e manter concordância com os clientes e os stakeholders sobre o que o sistema deverá fazer;

• Fornecer aos desenvolvedores do sistema um maior entendimento sobre os requisitos;

• Traçar o escopo do sistema;

• Fornecer base para o planejamento do conteúdo técnico das iterações;

• Fornecer base para a estimativa de custo e tempo do desenvolvimento do sistema; e

• Definir uma interface de usuário para o sistema, ponderando as necessidades e metas dos usuários.

É de primordial importância que se compreenda de forma clara a definição e o escopo do problema que será solucionado com o sistema a ser desenvolvido. Para isso, os stakeholders devem ser identificados, as solicitações dos mesmos levantadas, reunidas e analisadas.

Segundo Rational (2002), alguns artefatos estão envolvidos com a disciplina de requisitos.

Dois modelos são apresentados pelo RUP nessa disciplina, um tratando os casos de uso e outro não.

As descrições do que o software deverá realizar, conforme mostra a Figura 7, são constituídas pelos seguintes artefatos: documento de visão, modelo de casos de uso e seu detalhamento, atributos de requisitos, solicitações dos stakeholders, glossário, o plano de gerenciamento de requisitos, a especificação suplementar, pacote, encenação, o protótipo da interface do usuário e por fim, a Especificação de Requisitos de Software. As fontes de informação para a geração desses requisitos, são os clientes, usuários potenciais e os requisitos de sistema.

Figura 7. Papéis e artefatos utilizados na disciplina de requisitos Fonte: Adaptado de Rational (2002).

Um documento de visão é um artefato no qual é descrito a visão que os stakeholders têm das necessidades e características mais importantes do produto a ser desenvolvido que também serve de alicerce para a descrição dos requisitos técnicos mais detalhados.

O modelo de casos de uso, que é um modelo das funções pretendidas do sistema e seu ambiente, serve como um contrato entre os clientes, usuários e os desenvolvedores. Basicamente, o modelo de casos de uso consiste em casos de uso e atores. Com esse modelo, é possível que os usuários e clientes validem que o sistema realmente atende as necessidades dos mesmos e também fornecer uma visão das funcionalidades para que os desenvolvedores construam o que está sendo esperado por seus stakeholders.

As especificações suplementares têm como objetivo capturar os requisitos de sistema que não foram capturados nos casos de uso. Sendo assim, esse artefato é um complemento bastante importante para o artefato modelo de casos de uso. Esses dois artefatos, capturam todos os requisitos do software que precisam ser descritos para descrever um bom documento de ERS.

O artefato solicitações dos stakeholders também interage com a disciplina de requisitos reunindo as fontes existentes para se obter uma lista das necessidades dos clientes e usuários potenciais juntamente com informações de como essas solicitações foram consideradas para o projeto.

O artefato que especifica as informações e controla os mecanismos que serão usados para medir, relatar e controlar mudanças nos requisitos do produto é o artefato plano de gerenciamento de requisitos, o qual também está envolvido com a disciplina de requisitos.

De forma complementar aos artefatos já mencionados, os artefatos a seguir também estão relacionados com a disciplina de requisitos:

• Glossário: define uma terminologia comum que é utilizada de forma consistente na organização ou no projeto do software;

• Encenação de caso de uso: descrição lógica e conceitual de como um caso de uso é fornecido pela interface do usuário; e

• Protótipo da interface do usuário: podem se manifestar através de esboços ou figuras entre outros.

Para completar o entendimento da disciplina de requisitos, as atividades e os artefatos estão organizados em etapas do fluxo de trabalho da disciplina. Cada etapa desse fluxo reflete ações que precisam ser implementadas para poder executar o gerenciamento de requisitos de forma eficiente.

O fluxo de trabalho para a disciplina de requisitos é mostrado na Figura 8.

Figura 8. Fluxo de atividades da disciplina de requisitos Fonte: Adaptado de Rational (2002).

O relacionamento da disciplina de requisitos com as outras disciplinas se dá conforme apresentado a seguir:

• A disciplina Modelagem de Negócios fornece as regras de negócios, um modelo de casos de uso de negócios e um modelo de objeto de negócio;

• A disciplina Análise e Projeto obtêm suas informações primárias dos requisitos. Falhas no modelo de casos de uso podem ser descobertas nessa disciplina;

• A disciplina de Teste valida o sistema com base principalmente no modelo de casos de uso;

• A disciplina Gerenciamento de Configuração e mudança fornece o mecanismo para controle de mudanças dos requisitos;

• A disciplina de Gerenciamento de Projeto planeja o projeto e cada iteração (descritas em um Plano de Iteração); e

• A disciplina Ambiente desenvolve e mantém os artefatos de suporte usados no gerenciamento de requisitos e na modelagem de caso de uso.