Levantamento de Requisitos

Atividades ligadas ao Levantamento de Requisitos

De acordo com o PMBoK (Project Management Body of Knowledge), um guia que reúne o conjunto de Melhores Práticas em Gerenciamento de Projetos produzido pelo Project Management Institute (PMI, 2013, p. 110), o Plano de Gerenciamento dos Requisitos deve compor o Plano de Gerenciamento do Projeto de Software, sendo um documento que objetiva descrever como os requisitos serão analisados, documentados e gerenciados. De acordo com o guia, os componentes do Plano de Gerenciamento dos Requisitos podem incluir a definição:

• de como as atividades dos requisitos serão planejadas, rastreadas e relatadas;
• das atividades de gerenciamento da configuração: como as mudanças do produto serão iniciadas, como os impactos serão analisados, rastreados, monitorados e relatados, os níveis de autorização necessários para aprovar tais mudanças etc.;
• do processo de priorização dos requisitos;
• das métricas do produto que serão usadas e os argumentos que justificam o seu uso;
• da estrutura de rastreabilidade que reflita quais atributos dos requisitos serão capturados na matriz de rastreabilidade.

O guia define um processo para a Coleta de Requisitos, que objetiva determinar, documentar e gerenciar as necessidades e requisitos dos stakeholders de forma a atender aos objetivos do projeto.

Os requisitos incluem condições ou capacidades que devem ser atendidas pelo projeto ou estar presentes no produto, serviço ou resultado para cumprir um acordo ou outra especificação formalmente imposta. Os requisitos incluem as necessidades quantificadas e documentadas e as expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem incluídos na linha de base do escopo e medidos uma vez que a execução do projeto se inicie.

Fonte: PMI (2013, p. 112)

O levantamento ou elicitação de requisitos tem como principal objetivo definir e documentar as funções e funcionalidades do sistema necessárias para atender às necessidades e expectativas dos stakeholders. O sucesso do sistema é diretamente influenciado pela atenção ao levantamento e ao gerenciamento dos requisitos.

Pressman (2011, p. 133) afirma que o levantamento de requisitos combina atividades ligadas à análise, negociação e especificação. O autor sugere que os stakeholders devam trabalhar juntos para identificar o problema, propor soluções, negociar abordagens diferentes e especificar os requisitos iniciais da solução, dentro de uma abordagem colaborativa.

Sommerville (2011, p. 70) indica como atividades essenciais ao levantamento de requisitos: descoberta de requisitos; classificação e organização dos requisitos, priorização e negociação dos requisitos e especificação dos requisitos.

A figura ilustra as principais atividades ligadas ao levantamento de requisitos:

Atividades do levantamento de requisitos.
Fonte: baseado em SOMMERVILLE (2011) e PRESSMAN (2011)

Sommerville (2011) enumera os seguintes motivos que tornam a elicitação de requisitos um processo difícil:

• Os stakeholders usualmente não sabem bem o que querem de um sistema computacional, não conhecem seus limites e muitas vezes solicitam coisas inviáveis;
• Os stakeholders expressam os requisitos usando seus termos, que têm implícito seu conhecimento de trabalho, e os engenheiros de requisitos podem não compreendê-los;
• Diferentes stakeholders possuem requisitos distintos e podem expressá-los de forma distinta, então os engenheiros de requisitos devem buscar descobrir semelhanças e conflitos;
• Fatores políticos, como gerentes desejarem requisitos que aumentem seu poder na organização, podem influenciar os requisitos;
• Novos requisitos podem surgir em função da entrada de novos stakeholders, mudanças no cenário econômico podem provocar mudanças nos requisitos e, ainda, a importância dos requisitos pode ser alterada.

Negociação

Fonte: dilbert.com

Como podemos notar, caro aluno, a negociação é essencial para balancear as diferentes opiniões e os conflitos provocados pelos diferentes stakeholders no processo de elicitação de requisitos.

Também é importante que os requisitos levantados sejam documentados para que possam ajudar na descoberta de novos requisitos. Os componentes da documentação podem incluir, mas não estão limitados, a:

• A necessidade do negócio ou oportunidade a ser aproveitada, descrevendo as limitações da situação atual e por que o projeto foi empreendido;
• Objetivos do negócio e do projeto para permitir rastreamento;
• Requisitos funcionais descrevendo processos de negócio, informações e interação com o produto de forma apropriada a ser documentada textualmente;
• Requisitos não funcionais, tais como nível de serviço, desempenho, cuidados, segurança, atendimento a leis e regulamentos etc.;
• Impactos em outras áreas organizacionais;
• Impactos em outras entidades internas ou externas à organização.

Para que este processo ocorra com sucesso, os requisitos devem ser claros, completos, sem ambiguidade, implementáveis, consistentes e testáveis, como mostra a tabela. Os requisitos que não apresentem tais qualidades são problemáticos: eles devem ser revistos e renegociados com os clientes e usuários.

TABELA – Características dos requisitos

Não ambíguo	Todo requisito tem apenas uma interpretação possível.
Correto	Todo requisito representa algo requerido do sistema ou funcionalidade a ser construída.
Completo	Contém o que o software deve fazer e atender em todas as situações possíveis.
Compreensível	Todas as pessoas podem facilmente compreender o significado de todos os requisitos com um mínimo de explicação.
Verificável	Atende ao conjunto de técnicas que podem ser usadas para verificar que todo requisito está implementado pelo sistema.
Internamente consistente	Não deve haver requisitos conflitantes entre si.
Externamente consistente	Não deve haver requisitos conflitantes com outra documentação de projeto já definida.
Realizável	Possibilita que um projeto seja implementado corretamente com todos os requisitos declarados.
Conciso	É tão pequeno quanto possível, sem afetar qualquer outra qualidade que deva atender.
Rastreável	É escrito de modo que facilite o “referenciamento” de cada requisito individualmente.
Modificável	Sua estrutura e estilo são tais que qualquer mudança pode ser feita facil, completa e consistentemente.
Anotado por importância relativa	Permite que se possa facilmente determinar qual requisito é mais importante para os clientes.
Anotado por estabilidade relativa	Permite que se possa facilmente determinar qual requisito é mais suscetível à mudança.
Organizado	Permite que se possa facilmente localizar informações e relacionamentos lógicos entre seções adjacentes.

Fonte: Gonsales, 2010

Requisitos Externos

São requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento, como:

• Requisitos Éticos;
• Requisitos Legais (como política de privacidade e direitos autorais);
• Requisitos Reguladores.

Exemplos: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade); em razão das restrições referentes aos direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos; utilização de uma interface padrão utilizando uma determinada norma; disponibilização de arquivos somente para leitura por causa dos direitos autorais.

Etapas da Engenharia de Requisitos

A Engenharia de Requisitos reúne as primeiras atividades a serem realizadas nos diversos modelos de processo de software. Seu objetivo é definir o que deve ser feito e não a forma como será implementado o sistema. Serve como ponte entre o projeto e a construção do software e define as bases do contrato entre o desenvolvedor e o cliente. Realiza a aquisição, o refinamento e a verificação das necessidades do sistema. A meta é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do sistema para elaboração do DERS (Documento de Especificação de Requisitos de Software).

A Engenharia de Requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar as suas necessidades, negociar uma solução adequada ao seu problema, validar a especificação e administrar os requisitos à medida que eles são transformados em um sistema em operação. De acordo com Pressman (2011, p. 127), o processo de ER abrange as etapas de concepção, levantamento, elaboração, negociação, especificação, validação e gestão, que são apresentadas a seguir.

Engenharia de requisitos. Fonte: Danang Setiawan/shutterstock

Concepção ou Estudo de Viabilidade do Sistema

O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas perguntas:

• O sistema contribui para os objetivos gerais da empresa?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?

Após responder essas questões é necessário questionar as fontes de informação (stakeholders). Para isso, são recomendadas algumas perguntas, como:

• Como a empresa se comportaria se esse sistema não fosse implementado?
• Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?
• Que contribuição direta o sistema trará para os objetivos da empresa?
• As informações podem ser transferidas para outros sistemas e também podem ser recebidas a partir deles?
• O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
• O que precisa e o que não precisa ser compatível com a empresa?
• Quem vai usar o sistema?

Após obter essas respostas, deve-se preparar um relatório de viabilidade.

Levantamento dos Requisitos

O levantamento de requisitos busca descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, o desempenho exigido, dentre outros. O levantamento de requisitos pode envolver diferentes tipos de pessoas da empresa, os stakeholders. Frequentemente os clientes não sabem o que querem do sistema computacional, a não ser em termos muito gerais. Costumam expressar os requisitos utilizando seus próprios termos e com o conhecimento implícito de sua área de atuação. Diferentes stakeholders têm em mente diferentes requisitos e podem expressá-los de maneiras distintas. Além disso, fatores políticos podem influenciar os requisitos do sistema. O ambiente econômico e de negócios, no qual a análise de requisitos ocorre, é dinâmico, ou seja, inevitavelmente o ambiente se modifica durante o projeto. Como consequência, a importância dos requisitos específicos pode mudar. Assim, novos requisitos podem surgir por parte dos novos stakeholders, que não haviam sido consultados inicialmente.

Análise de Requisitos

As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante a análise (ou elaboração) de requisitos. Esta atividade da ER tem por objetivo desenvolver um modelo técnico refinado das funções, características e restrições do software. É guiada pela criação e refinamento de cenários do usuário que descrevem como o usuário final (e outros atores) vão interagir com o sistema.

Negociação de requisitos. Fonte: Reenya/shutterstock

Negociação dos Requisitos

A negociação categoriza e organiza os requisitos em subconjuntos relacionados. Neste passo, as seguintes perguntas devem ser respondidas:

• Cada requisito está consistente com o objetivo global do sistema?
• Todos os requisitos foram especificados no nível de abstração adequado?
• O requisito é realmente necessário ou representa uma característica adicional que pode não ser essencial para o objetivo do sistema?
• Cada requisito é limitado e não ambíguo?
• Cada requisito tem atribuição (será utilizado por alguém)?
• Algum requisito conflita com outros requisitos?
• Cada requisito é realizável no ambiente técnico?
• Cada requisito pode ser testado quando estiver implementado?
• Qual é a prioridade desse requisito?

Especificação dos Requisitos

Especificação de Requisitos geralmente é um documento escrito, que contém o detalhamento do sistema, os requisitos funcionais e não funcionais e os modelos do sistema que podem ser representados por meio de diagramas como IDEF0 (Integration Definition for Function Modeling), diagramas de casos de uso da UML (Unified Modeling Language), diagramas de classes preliminar, diagramas de sequência e prototipação.

Validação dos Requisitos

A validação de requisitos examina a especificação de requisitos para garantir que todos os requisitos do sistema tenham sido identificados e detalhados, que as inconsistências, omissões e erros tenham sido detectadas e corrigidas e que as prioridades tenham sido estabelecidas. Tem a função de mostrar que os requisitos realmente definem o sistema que o cliente deseja. São realizadas diversas verificações, como:

• Verificações de validade: Um usuário pode pensar que um sistema é necessário para realizar certas funções, mas mais estudos e análises podem identificar funções adicionais ou diferentes necessárias.
• Verificações de consistência: Os requisitos em um documento não devem ser conflitantes, ou seja, não devem existir restrições contraditórias ou descrições diferentes para uma mesma função do sistema.
• Verificações de completeza: O documento de requisitos (DERS) deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema.
• Verificações de realismo: Utilizando o conhecimento da tecnologia existente, os requisitos devem ser verificados, a fim de assegurar que eles realmente podem ser implementados. Essas verificações devem também levar em conta o orçamento e os prazos para o desenvolvimento do sistema.
• Facilidade de verificação: Para reduzir o potencial de divergências entre cliente e desenvolvedor, os requisitos do sistema devem sempre ser escritos de modo que possam ser verificados. Isso significa que um conjunto de verificações pode ser projetado para mostrar que o sistema entregue cumpre com esses requisitos, como:
• O requisito é realmente passível de ser testado, como foi definido?
• O requisito pode ser adequadamente compreendido pelos compradores ou usuários finais do sistema?
• A origem do requisito é claramente definida?
• O requisito é adaptável?
• Ele pode ser modificado sem que isso provoque efeitos em grande escala em outros requisitos do sistema?

De acordo com Pressman (2011, p. 381) um dos mecanismos de validação de requisitos é a RTF (Revisão Técnica Formal). Em uma RTF com esse propósito, a equipe de desenvolvimento deve conduzir o cliente pelos requisitos do sistema, explicando as implicações de cada requisito. A equipe de revisão deve verificar cada requisito, em termo de sua consistência e verificar os requisitos como um todo sob o ponto de vista de sua completeza. A RTF é uma atividade que garante a qualidade do software.

Gestão de Requisitos

 

 

Gestão de requisitos. Fonte: Iconic Bestiary/shutterstock

Gestão de Requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos a qualquer momento no desenvolvimento do sistema. Para auxiliar na gestão de requisitos tabelas de rastreamento são criadas com o objetivo de verificar as relações entre requisitos e o impacto da mudança de requisitos. Os requisitos mudam e há uma série de razões para isso, como: os problemas podem ser muito intricados, as especificações podem ficar incompletas, o aumento do entendimento do sistema ocorre ao longo do projeto,como há vários usuários, há várias visões,  quem paga pelo sistema geralmente é diferente de quem o usa, a empresa e o ambiente se modificam e, na medida em  que os  usuários se familiarizam com o sistema, novos requisitos surgem. A gestão de requisitos precisa de apoio automatizado, como ferramentas CASE (Computer Aided Software Engineering), para:

• Armazenamento de requisitos: os requisitos devem ser mantidos em um depósito de dados seguro, gerenciado, que seja acessível por todos os envolvidos no processo de engenharia de requisitos.
• Gerenciamento de mudanças: esse processo pode ser simplificado se o apoio de ferramentas estiver disponível.
• Gerenciamento de facilidade de rastreamento: o apoio de ferramentas para a rastreabilidade permite que requisitos relacionados sejam descobertos.

Sommerville (2011, p. 70) apresenta as atividades de Engenharia de Requisitos, conforme ilustra a figura.

Visão em espiral das atividades da Engenharia de Requisitos

Fonte: SOMMERVILLE (2011, p. 70)

O autor define a ER como um conjunto de atividades que visam avaliar se o sistema é útil para a organização (estudo de viabilidade), realizar o levantamento de requisitos (elicitação e análise), converter os requisitos para um padrão (especificação) e verificar se realmente os requisitos são capazes de definir o que o cliente deseja (validação). Essas atividades são organizadas em torno de uma espiral, como um processo iterativo, cuja saída resulta no DERS (Documento de Especificação de Requisitos de Software).

Requisitos de Produto

 São requisitos que especificam ou restringem o comportamento do produto, como:

• Requisitos de Usabilidade: referem-se ao esforço para utilizar ou aprender a utilizar o produto. Estão relacionados com a interação do usuário junto ao sistema.
• Requisitos de Confiabilidade: referem-se à frequência de ocorrência de falhas e recuperabilidade em caso de falha, como: tempo médio de falhas; probabilidade de indisponibilidade; taxa de ocorrência de falhas; tempo de reinício após falha; percentual de eventos causando falhas; probabilidade de corrupção de dados após falha.
• Requisitos de Eficiência: incluem os Requisitos de Espaço e os Requisitos de Desempenho do sistema e estão associados à eficiência, uso de recursos e tempo de resposta da aplicação, como: transações processadas/segundo; tempo de resposta do usuário/evento, entre outros.
• Requisitos de Proteção: são relativos às regras de segurança da informação que garantem a proteção da informação.

Requisitos Organizacionais

São requisitos derivados das políticas organizacionais do cliente e do desenvolvedor, como:

• Requisitos Operacionais: ligados às restrições de software e hardware usados para desenvolver ou executar o sistema.
• Requisitos de Desenvolvimento: referem-se à definição da linguagem de programação e às normas que devem ser seguidas pelo sistema ou no processo de desenvolvimento, bem como as regras de codificação.
• Requisitos Ambientais: referem-se ao modo como será implantada a solução nos ambientes do usuário, como configurações necessárias e ordem de instalação dos pacotes, capacidade de transferir o produto para outros ambientes etc.

Requisitos Funcionais e Não Funcionais

Os requisitos de software são classificados como funcionais e não funcionais, mas os não funcionais ainda apresentam uma subclassificação. Uma breve descrição destes tipos de requisitos é apresentada a seguir, com base em Sommerville (2011).

Requisitos de software

Fonte: alphaspirit/shutterstock

Requisitos Funcionais

São requisitos que descrevem o que o sistema deve fazer, ou seja, sua funcionalidade (funções que o sistema deve realizar) ou os serviços que se espera que o sistema faça. Quando definidos como requisitos de usuários, os requisitos funcionais são expressos de forma mais abstrata para facilitar sua compreensão. Mas requisitos funcionais de sistema podem detalhar mais as funções do sistema, suas entradas e saídas, exceções etc. Exemplos de requisitos funcionais:

• O usuário deve ser capaz de pesquisar as listas com os agendamentos de atendimento.
• O sistema deve gerar, diariamente, a lista com os agendamentos de clientes.
• Cada usuário do sistema deve ser identificado pelo número de identificação de 8 dígitos.
• O sistema deve solicitar uma senha de acesso de cada usuário.

Requisitos Não Funcionais

São requisitos que não dizem respeito diretamente à funcionalidade do sistema, mas expressam propriedades do sistema e/ou restrições sobre os serviços ou funções por ele providas. Incluem propriedades do sistema como confiabilidade, disponibilidade, desempenho, segurança etc., capacidade dos dispositivos de E/S, tempo de resposta, representações de dados do sistema, detalhes técnicos de softwares e ferramentas, linguagens de programação etc.

Sua classificação é abrangente e é mostrada na figura.

Classificação dos requisitos não funcionais. Fonte: Sommerville (2011, p. 61)

Requisitos do Usuário e do Sistema

De acordo com Sommerville (2011, p. 59), os requisitos de software podem ser diferenciados entre requisitos do usuário e do sistema. Os requisitos do usuário definem quais serviços o sistema oferecerá a seus usuários e as restrições com as quais deverá operar, e isso é feito usando diagramas ou linguagem natural. Os requisitos de sistema são descrições mais detalhadas destas funções, serviços e restrições operacionais do sistema de software. O autor afirma que muitos problemas da Engenharia de Requisitos ocorrem pela falha na distinção e separação entre esses diferentes níveis de descrição.

Requisitos do Usuário

São os requisitos funcionais e não funcionais do sistema sob o ponto de vista do usuário. Em geral apresentam problemas como falta de clareza, confusão e fusão, ou seja, requisitos diferentes escritos como um único requisito.

Requisitos do Sistema

São descrições mais detalhadas dos requisitos do usuário. São a base para que os engenheiros de software possam fazer o projeto do sistema. Servem como base para um contrato destinado à implementação do sistema.

Engenharia de Requisitos

Requisitos de software e sua importância dentro da Engenharia de Requisitos. As etapas e principais conceitos e definições ligadas à Engenharia de Requisitos serão apresentados.

Requisitos e Engenharia de Requisitos

Caro aluno, a Engenharia de Requisitos (ER) pode ser vista como uma subárea da Engenharia de Software, cujo principal objetivo é a obtenção de uma especificação correta e completa dos requisitos de um sistema de software.

De acordo com Pressman (2011, p. 127), na perspectiva do processo de software, a Engenharia de Requisitos é uma ação de engenharia de software que começa durante a atividade de Comunicação (ou Especificação) e continua durante a atividade de Modelagem, devendo ser adaptada às necessidades do processo, do projeto, do produto e das pessoas envolvidas.

Para que o processo de desenvolvimento de software seja bem-sucedido é fundamental que haja uma compreensão completa dos requisitos de software. Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise e especificação dos requisitos. O desenvolvedor age como indagador, consultor e solucionador de problemas e o cliente tenta traduzir os conceitos relativos ao desempenho do software que ele tem concebido apenas em sua mente, tarefa que é, às vezes, bastante complicada e nebulosa, em detalhes concretos.

Mas, afinal, o que são os requisitos?

De acordo com Sommerville (2011, p. 57), requisitos são descrições do que o sistema deve fazer, os serviços que oferece e as restrições relativas ao seu funcionamento. Os requisitos têm por objetivo:

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer;
• Oferecer aos desenvolvedores uma compreensão melhor do sistema a ser desenvolvido;
• Delimitar o sistema;
• Planejar o desenvolvimento do sistema;
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.

A Engenharia de Requisitos tem se tornado cada vez mais necessária para resolver os problemas encontrados nas organizações com relação à definição de sistemas. De acordo com a Regra 10 de Myers, o custo de um defeito tende a ser 10 vezes maior a cada fase de projeto em que ele avança; isso significa que, quanto antes um defeito for encontrado; mais barato é para corrigir (ALMEIDA, 2016). A figura ilustra este fato.

Custo de correção de defeitos em software. Fonte: ALMEIDA, 2016

Como pode ser visto na figura, o custo aumenta com o tempo de descoberta do problema, mas tem origem na especificação dos requisitos. Muitas vezes os defeitos são descobertos pelo próprio cliente, mesmo antes da entrega do produto, quando ele participa ativamente. Os requisitos deficientes são considerados uma das maiores causas de falhas nos projetos de software.

Processo Unificado/RUP

O Processo Unificado (PU) ou Unified Process (UP) surgiu como um processo para o desenvolvimento de software visando à construção de sistemas orientados a objetos. De acordo com Pressman (2011, p. 71), o PU busca aproveitar os melhores recursos dos modelos de processos tradicionais unidos aos melhores princípios do desenvolvimento ágil de software. 

 

 

Processo Unificado. Fonte: Lightspring/shutterstock

De acordo com IBM (2006), o PU foi modelado usando o Software Process Engineering Metamodel (SPEM), que é um padrão para modelagem de processos baseado em UML – Unified Modeling Language. De uma maneira geral, podemos assim caracterizar o Processo Unificado:

• é um framework genérico de um processo de desenvolvimento;
• é baseado em componentes;
• utiliza toda a definição da UML;
• é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).

De acordo com Sommerville (2011, p. 34), o RUP – Rational Unified Process – é derivado de trabalhos da UML – Unified Modeling Language – e do Processo Unificado, reunindo elementos de modelos de processo genéricos, trazendo boas práticas de especificação para o projeto e ainda apoiando a prototipação e a entrega incremental. É um processo iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos por causa da maneira organizada e consistente que oferece na condução de um projeto.

Sommerville (2017) descreve o RUP como um framework descrito em três perspectivas:

• Dinâmica, que mostra as fases ao longo do tempo;
• Estática, que mostra as atividades ao longo do processo;
• Prática, que sugere boas práticas a serem utilizadas.

A figura ilustra as fases e os workflows do RUP. 

Fases e Workflows do Processo Unificado. Fonte: baseado em IBM (2006, p. 4)

Fases – Perspectiva dinâmica

O RUP organiza suas iterações em quatro fases principais, que Sommerville (2011) assim define:

Concepção: o objetivo desta fase é definir um caso de negócio para o sistema. São elencadas todas as entradas externas, que se referem a pessoas e sistemas, define-se como estas interagem com o sistema e as interações são definidas. A ideia é ter uma visão inicial do problema, estimar de forma vaga o esforço e os prazos e determinar se o projeto é viável e merece uma análise mais profunda, ou então se deve ser descartado.

Elaboração: na fase de elaboração todos (ou a grande maioria) dos requisitos são levantados em detalhes, o framework arquitetural do sistema é definido, o plano de projeto é desenvolvido e os maiores riscos do projeto são identificados. Ao fim desta fase, deseja-se que 90% dos requisitos tenham sido levantados em detalhes, podendo formar um conjunto de casos de uso da UML, que o planejamento e a arquitetura do sistema tenham sido descritos e que os principais riscos tenham sido tratados, de forma que haja condições para se fazer estimativas mais realistas.

Construção: esta fase envolve o projeto, implementação e testes do sistema. O sistema é cosntruído por partes e integrado e, no final, uma versão do sistema já deve estar funcionando, junto com uma documentação a ser entregue ao cliente.

Transição: esta fase realiza a transferência do sistema do ambiente de produção, ou seja, dos desenvolvedores, para o ambiente real de utilização, ou seja, para os usuários. Ao final da fase, a implantação deve estar concluída e o sistema deve estar funcionando, com a documentação adequada, no ambiente operacional.

Workflows – Perspectiva Estática

Workflow

Fonte: Rawpixel.com/shutterstock

A visão estática do RUP dá prioridade às atividades que ocorrem no processo de desenvolvimento, denominadas workflows. Um workflow é uma coleção de atividades relacionadas que estão ligadas à maior área de interesse dentro do processo, podendo ser modeladas por meio de diagramas da UML. São 6 workflows centrais e 3 workflows de apoio, cujos objetivos são:

1. Modelagem de Negócios: entender a estrutura e a dinâmica da organização para a qual o produto será desenvolvido; identificar problemas correntes na organização e possíveis aperfeiçoamentos; assegurar que o cliente, o usuário final e os desenvolvedores possuam a mesma compreensão da empresa; produzir os requisitos de sistemas necessários para suportar os objetivos da organização. Os processos de negócio são modelados usando casos de uso de negócios.
2. Requisitos: estabelecer e manter o consentimento entre clientes e stakeholders sobre o que o sistema deve fazer; fornecer uma melhor compreensão dos requisitos aos desenvolvedores; definir os limites do sistema; fornecer as bases para o planejamento das iterações, estimativas de custo e tempo de desenvolvimento; definir as interfaces do sistema baseado nas necessidades e objetivos dos usuários. Os atores que interagem com o sistema são identificados e casos de uso são utilizados para modelar os requisitos do sistema.
3. Análise e Design: transformar os requisitos dentro de um projeto do que será o sistema; desenvolver uma arquitetura robusta para o sistema; adaptar o projeto para ajustá-lo ao ambiente de implementação. O modelo de projeto é criado e documentado utilizando diagramas que definem os modelos de arquitetura, de componentes, de objetos e de sequência.
4. Implementação: preparar a organização do código em termos de implementação de subsistemas, organizados em camadas; implementar classes e objetos em termos de seus componentes; testar os componentes desenvolvidos como unidades; integrar os resultados obtidos por implementadores individuais (ou equipes) em um sistema executável. Os componentes do sistema são implementados e estruturados em subsistemas de implementação, podendo ser utilizada geração automática de código.
5. Teste: verificar a interação entre os objetos; verificar a integração de todos os componentes de software; verificar se todos os requisitos foram implementados corretamente; verificar os defeitos e assegurar que eles foram tratados antes da entrega do produto. O teste de sistema segue a conclusão da implementação.
6. Implantação: descrever as atividades associadas à verificação para que o produto esteja disponível ao usuário final. Um release (versão) do sistema é produzido e instalado no ambiente de trabalho dos usuários.
7. Gerenciamento de Configuração e Mudança: identificar itens de configuração; restringir alterações para aqueles itens; auditar as alterações neles feitas; definir e gerenciar as alterações daqueles itens. Este workflow de apoio gerencia as mudanças do sistema.
8. Gerenciamento de Projeto: fornecer uma estrutura para gerenciamento de projeto de software; fornecer um guia prático para planejamento, recrutamento, execução e monitoramento de projeto; fornecer uma estrutura para o gerenciamento de riscos. Este workflow de apoio gerencia o desenvolvimento do sistema.
9. Ambiente: identificar as atividades necessárias para configurar o processo para o projeto; descrever as atividades requeridas para desenvolver as guias mestras no suporte ao projeto; fornecer para a organização de desenvolvimento de software o ambiente de processos e ferramentas que suportarão a equipe de desenvolvimento. Este workflow de apoio está ligado à disponibilização de ferramentas adequadas para o desenvolvimento.
   

Engenharia de Software. Fonte: emojoez/shutterstock

Perspectiva prática

O RUP indica seis boas práticas de Engenharia de Software a serem aplicadas no desenvolvimento de sistemas de software, que são assim descritas por Sommerville (2011):

1. Desenvolver software de forma interativa.
2. Gerenciar os requisitos.
3. Usar arquiteturas baseadas em componentes.
4. Modelar o software usando diagramas e modelos visuais.
5. Verificar a qualidade do software.
6. Controlar as mudanças do software.

Apesar de apresentar diversas vantagens, o RUP é um processo complexo, envolve custos mais altos e requer equipe de desenvolvimento maior e mais especializada. Não é um modelo adequado para o desenvolvimento de software embarcado, por exemplo.