Palavras-chave: Norma NBR ISO/IEC 12207, RUP, UP, UML.

Advindo do fato de que a qualidade do produto de software está diretamente relacionada à qualidade do processo de software, diversos modelos e normas para a definição e melhoria de processos de software têm sido desenvolvidos. Modelos como o SW-CMM (SW-CMM - Capability Maturity Model for Software) [9] e o SPICE (SPICE - Software Process Improvement and Capability dEtermination, atualmente, ISO/IEC TR 15504) [5] são cada vez mais conhecidos e utilizados, tanto internacionalmente, como no Brasil, conforme demonstra a pesquisa de Qualidade e Produtividade no Setor de Software Brasileiro, realizada bienalmente pelo Ministério da Ciência e Tecnologia [4]. Da mesma forma o são as normas de qualidade de produto [2] e processo de software [3].

Para manterem-se genéricos o suficiente para poderem ser adaptados aos vários contextos a que se destinam, estes modelos e normas estabelecem o que deve ser feito e não como deve ser implementado. Ou seja, estabelecem quais são os processos que devem estar presentes para garantir o sucesso dos projetos, mas não oferecem orientações sobre qual modelo de ciclo de vida, ferramenta, linguagem ou ambiente deve ser utilizado.

Por outro lado, todo dia surgem novos paradigmas, métodos e ferramentas de desenvolvimento pregando ser a solução definitiva para os problemas dos projetos de software. No decorrer dos anos 90, estiveram em pauta as metodologias orientadas a objetos introduzidas isoladamente por cada um de seus autores. No final dos anos 90, três deles (Jacobson, Booch e Rumbaugh) se reuniram para desenvolver o Unified Software Development Process (UP) [6]. Posteriormente, o UP foi instanciado e especificado pela Rational Software Corporation, resultando no Rational Unified Process (RUP), descrito por Kruchten em [7].

O que nos propomos a analisar neste trabalho é: qual a aderência do processo de desenvolvimento RUP à Norma de Processos de Ciclo de Vida de Software NBR ISO/IEC 12207.

As demais seções deste artigo estão assim organizadas: na seção 2 descrevemos sucintamente a Norma de Processos de Ciclo de Vida de Software NBR ISO/IEC 12207; na seção 3 apresentamos os principais conceitos que envolvem o RUP; na seção 4 analisamos a aderência do RUP à NBR ISO/IEC 12207 e, finalmente, na seção 5 apresentamos as nossas conclusões.

2. A Norma NBR ISO/IEC 12207

A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software [3] tem como principal objetivo fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum é estabelecida na forma de processos bem definidos.

A estrutura da Norma foi concebida de maneira a ser flexível, modular e adaptável às necessidades de quem a utiliza. Para isto, ela está fundamentada em dois princípios básicos: modularidade e responsabilidade. Modularidade, no sentido de processos com mínimo acoplamento e máxima coesão. Responsabilidade, no sentido de estabelecer um responsável único por cada processo, facilitando a aplicação da Norma em projetos onde várias pessoas podem estar legalmente envolvidas.

Conforme citado anteriormente, a Norma é composta por um conjunto de processos, atividades e tarefas que podem ser adaptados de acordo com os projetos de software. Estes processos são classificados em três tipos: fundamentais, de apoio e organizacionais, conforme ilustra a Figura 1. Os processos de apoio e organizacionais devem existir independentemente da organização e do projeto que está sendo executado. Os processos fundamentais são instanciados de acordo com a situação.

2.1 Processos fundamentais

São responsáveis pela geração dos produtos de software, constituindo o ciclo de vida de software propriamente dito. São representados pelos seguintes processos:

• Processo de Aquisição:

Define as atividades do adquirente, organização que adquire um sistema ou produto de software. Inicia-se com a definição da necessidade de adquirir um sistema, um produto de software ou um serviço de software. O processo continua com a preparação e emissão de pedido de proposta, seleção de fornecedor e gerência do processo de aquisição através da aceitação do sistema, produto de software ou serviço de software.

• Processo de Fornecimento:

Define as atividades do fornecedor, organização que provê o produto de software ao adquirente. O processo pode ser iniciado tanto por uma decisão de preparar uma proposta para responder a um pedido de proposta de um adquirente, quanto pela assinatura e celebração de um contrato com o adquirente para fornecer o sistema, produto de software ou serviço de software. O processo continua com a determinação dos procedimentos e recursos necessários para gerenciar e garantir o projeto, incluindo o desenvolvimento e a execução dos planos de projeto, até a entrega do sistema, produto de software ou serviço de software para o adquirente.

• Processo de Desenvolvimento:

Define as atividades do desenvolver, organização que define e desenvolve o produto de software. O processo contém as atividades para análise de requisitos, projeto, codificação, integração, testes, e instalação e aceitação relacionada aos produtos de software.

• Processo de Operação:

Define as atividades do operador, organização que provê serviço de operação de um sistema computacional no seu ambiente de funcionamento para seus usuários. O processo cobre a operação do produto de software e o suporte operacional aos usuários.

• Processo de Manutenção:

Define as atividades do mantenedor, organização que provê os serviços de manutenção do software, isto é, gerenciamento de modificações no software para mantê-lo atualizado e em perfeita operação. Este processo é ativado quando o produto de software é submetido a modificações no código e na documentação associada devido a um problema, ou à necessidade de melhoria ou adaptação. O objetivo é modificar um produto de software existente, preservando a sua integridade.

2.2 Processos de apoio

Têm como objetivo auxiliar outros processos, visando principalmente a qualidade e o sucesso do projeto. São representados pelos:

• Processo de Documentação:

Define as atividades para registrar informações produzidas por um processo ou atividade do ciclo de vida. O processo contém o conjunto de atividades que planeja, projeta, desenvolve, produz, edita, distribui e mantém os documentos necessários a todos os interessados, tais como gerentes, engenheiros e usuários do sistema ou produto de software.

• Processo de Gerência de Configuração:

Define as atividades para a aplicação de procedimentos administrativos e técnicos por todo o ciclo de vida de software, destinado a: identificar e definir os itens de software em um sistema e estabelecer suas linhas básicas (baseline); controlar as modificações e liberações dos itens; registrar e apresentar a situação dos itens e dos pedidos de modificação; garantir a completeza, a consistência e a correção dos itens; e controlar o armazenamento, a manipulação e a distribuição dos itens.

• Processo de Garantia da Qualidade:

Define as atividades para fornecer a garantia adequada de que os processos e produtos de software, no ciclo de vida do projeto, estejam em conformidade com seus requisitos especificados e sejam aderentes aos planos estabelecidos. A abrangência do processo inclui questões como garantia de qualidade do produto (NBR 13596 [3] que corresponde à ISO/IEC 9126), do processo e do sistema de qualidade.

• Processo de Verificação:

Define as atividades para verificação dos produtos de software. É um processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições a eles impostas.

• Processo de Validação:

Define as atividades para validação dos produtos produzidos pelo projeto de software. É um processo para determinar se os requisitos e o produto final (sistema ou software), atendem ao uso específico proposto.

• Processo de Revisão Conjunta:

Define as atividades para avaliar a situação e produtos de uma atividade de um projeto, se apropriado. As revisões conjuntas são feitas tanto nos níveis de gerenciamento do projeto, como nos níveis técnicos e são executadas durante a vigência do contrato.

• Processo de Auditoria:

Define as atividades para determinar adequação aos requisitos, planos e contrato, quando apropriado.

• Processo de Resolução de Problemas:

Define um processo para analisar e resolver os problemas (incluindo não-conformidades), de qualquer natureza ou fonte, que são descobertos durante a execução do desenvolvimento, operação, manutenção ou outros processos. O objetivo é prover os meios em tempo adequado e de forma responsável e documentada para garantir que todos os problemas encontrados sejam analisados e resolvidos e tendências sejam identificadas.

2.3 Processos organizacionais

Têm como objetivo garantir e melhorar os processos dentro da organização. São representados pelos:

• Processo de Gerência:

Define as atividades genéricas que podem ser empregadas por quaisquer das partes que têm que gerenciar seu(s) respectivo(s) processo(s). O gerente é responsável pelo gerenciamento de produto, gerenciamento de projeto e gerenciamento de tarefa do(s) processo(s) aplicável(eis), tais como: aquisição, fornecimento, desenvolvimento, operação, manutenção ou processos de apoio.

• Processo de Infra-estrutura:

Define as atividades para estabelecer e manter a infra-estrutura necessária para qualquer outro processo. A infra-estrutura pode incluir hardware, software, ferramentas, técnicas, padrões e recursos para o desenvolvimento, operação ou manutenção.

• Processo de Melhoria:

Define as atividades básicas que uma organização (isto é, adquirente, fornecedor, desenvolvedor, operador, mantenedor, ou o gerente de outro processo) executa para estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software.

• Processo de Treinamento:

Define as atividades para prover e manter pessoal treinado. A aquisição, o fornecimento, o desenvolvimento, a operação ou a manutenção de produtos de software são extremamente dependentes de pessoal com conhecimento e qualificação. Portanto, é essencial que o treinamento seja planejado e implementado com antecedência para que o pessoal treinado esteja disponível quando o produto de software for adquirido, fornecido, desenvolvido, operado ou mantido.

A Norma também descreve o Processo de Adaptação que contém as atividades básicas para adaptar a Norma à uma organização ou projeto específico.

3. Rational Unified Process - RUP

Tanto o UP como o RUP são, antes de mais nada, processos de desenvolvimento de software, e como tal, seu objetivo é transformar os requisitos do usuário em sistema de software [6]. Sua característica fundamental é serem baseados em componentes, ou seja, o software desenvolvido é formado por componentes de software que se comunicam através de interfaces bem definidas. O padrão adotado para representação dos modelos é a Unified Modeling Language (UML). (é importante lembrar que a UML é apenas uma linguagem para representação e não constitui um processo de desenvolvimento em si)

3.1 Conceitos fundamentais do UP

O UP, e consequentemente o RUP, foi concebido tomando como base três conceitos fundamentais: dirigido por use case (optou-se por manter o termo use case porque é bastante utilizado), centrado na arquitetura, iterativo e incremental, conforme descrito a seguir.

• Dirigido por use case:

"Um use case é uma parte da funcionalidade do sistema que fornece ao usuário um resultado de valor" [6]. Os use cases são utilizados para a captura e definição dos requisitos funcionais do sistema de software, facilitando a comunicação e o entendimento entre os stakeholders. São também utilizados para projetar os casos de teste.

• Centrado em arquitetura:

No UP os use cases e a arquitetura vão sendo desenvolvidos em paralelo. A conceito de arquitetura engloba os aspectos mais relevantes, tanto estáticos, como dinâmicos, do sistema.

• Iterativo e Incremental:

O UP utiliza pequenos ciclos de projeto (mini-projetos) que correspondem à uma iteração e que resultam em um incremento no software. Iterações referem-se a passos no e incrementos a evoluções do produto.

3.2 Fases do RUP

O desenvolvimento de software efetuado através do RUP é incremental e cada incremento é desenvolvido utilizando-se quatro fases: iniciação, elaboração, construção e transição. A isto se chama ciclo de desenvolvimento. Após a fase de transição, o produto pode voltar a percorrer cada uma das fases, constituindo a fase de evolução, na qual se produz uma nova geração do produto [8].

• Iniciação:

Fase de compreensão do problema e da tecnologia através da definição dos use cases mais críticos. No final desta fase deve-se ter definido o escopo do produto, os riscos e ter demonstrado que o projeto é viável do ponto de vista do negócio da organização.

• Elaboração:

Fase de descrição da arquitetura do software na qual os requisitos que mais impactam na arquitetura são capturados em forma de use cases. No final da fase de elaboração deve ser possível estimar custos, elaborar o cronograma e o plano de construção.

• Construção:

Fase na qual o software é construído e preparado para a transição para os usuários. Além do código, propriamente dito, também são produzidos os casos de teste e a documentação.

• Transição:

Fase de treinamento dos usuários e transição do produto para utilização.

3.3 Principais Workflows de Processo do RUP

Cada uma das quatro fases do RUP é adicionalmente dividida em iterações e finalizada com um ponto de checagem que verifica se os objetivos daquela fase foram alcançados. Toda iteração é organizada em termos de workflows de processo, que são conjuntos de atividades realizadas por responsáveis que produzem artefatos, conforme ilustrado na Figura 2. Os principais workflows de processo são descritos a seguir:

• Modelagem de Negócio: (No UP, descrito em [6] não havia o workflow de modelagem de negócios, partindo-se diretamente para o workflow de requisitos)

Provê um entendimento comum entre os stakeholders sobre quais os processos de negócio que devem ser apoiados. A modelagem dos processos de negócio é feita através dos use cases de negócio.

• Requisitos:

Objetiva capturar os requisitos que serão atendidos pelo produto de software. Nas fases de iniciação e elaboração, a ênfase será maior neste workflow de requisitos, pois o objetivo destas fases é o entendimento e a delimitação do escopo do produto de software.

• Análise e Projeto: (No UP, descrito em [6], os workflows de análise e projeto apareciam separadamente, ressaltando a importância de se efetuar o modelo de análise)

Objetiva compreender mais precisamente os use cases definidos no workflow de requisitos, produzindo um modelo já voltado para a implementação que deverá estar adequado ao ambiente de implementação. Este workflow será bastante utilizado na fase de elaboração e durante o início da fase de construção.

• Implementação:

Objetiva a organização do código em termos de implementação de subsistemas, implementa as classes e objetos em termos de componentes, testa os componentes em termos de unidades e integra os códigos produzidos. Este workflow será bastante utilizado na fase de construção.

• Teste:

Objetiva analisar, através de testes, se os requisitos foram atendidos e que os defeitos serão removidos antes da implantação. Os modelos de testes são criados para descrever como os testes serão realizados. Sua ênfase será maior no final da fase de construção e no início da fase de transição.

• Entrega:

Objetiva produzir releases do produto e entregá-los aos usuários finais. Isto pode incluir atividades de beta-teste, migração de dados ou software existente e aceitação formal.

3.4 Principais Workflows de Apoio do RUP

Os workflows de apoio foram definidos como forma de suprir algumas das lacunas deixadas pelo UP [6]. Seu objetivo é auxiliar a execução dos workflows principais. São eles:

• Configuração e Gerenciamento de Mudanças:

Controla as diversas versões dos artefatos produzidos durante o projeto, garantindo sua integridade. Ou seja, assegura que os resultados não sejam conflitantes.

• Gerência de Projeto:

Fornece um framework para a gerência de projetos, orientações para planejamento, alocação de recursos e gerência de riscos.

• Ambiente:

Fornece a descrição para a organização do ambiente de desenvolvimento em termos de processos e ferramentas.

4. Aderência do RUP à Norma NBR ISO/IEC 12207

Esta seção apresenta, na Tabela 1, a análise proposta por este trabalho.

Processos da NBR ISO/IEC 12207		Análise em relação ao RUP
	Aquisição	Não atende esse processo. O conceito fundamental da Norma NBR ISO/IEC 12207 em relação aos papéis de aquisição e fornecimento não é previsto no RUP, como conseqüência, tem-se que a contratação não é endereçada de forma apropriada. Alguns produtos tratam em um nível superficial esta questão: Plano de Iteração, Plano de Construção Integrado, Plano de Projeto e Plano de Desenvolvimento de Software.
	Fornecimento	Não atende esse processo pelas mesmas razões do Processo de Aquisição.
	Desenvolvimento	Atende integralmente as atividades previstas no processo de desenvolvimento de software. A diferença é que a NBR ISO/IEC 12207 não prescreve nenhum modelo específico de ciclo de vida e o RUP estabelece que deve ser utilizado o ciclo incremental e iterativo.
	Operação	Não atende esse processo porque o ciclo de vida do RUP termina com a transição do software para os usuários, não fazendo qualquer referência à fase de operação.
	Manutenção	Atende parcialmente esse processo através da execução de um novo incremento no produto.
	Documentação	Atende parcialmente esse processo. O processo de desenvolvimento da NBR ISO/IEC 12207 é atendido pela documentação gerada pelo RUP, pois um padrão é adotado (UML). As documentações do usuário e gerencial são apenas citadas no RUP como necessárias, no entanto, não são fornecidos detalhes suficientes para implementação.
	Gerência de Configuração	Atende integralmente esse processo através do Plano de Gerência de Configuração e do Plano de Construção Integrada. A responsabilidade pelo processo está a cargo do CCB (Comitê de Controle de Mudanças). As baselines estabelecidas na Norma são definidas no final de cada iteração do RUP através dos milestones que auxiliam no processo de controle de mudanças.
	Garantia de Qualidade	Não atende esse processo pois deixa a responsabilidade para a organização. No entanto, auxilia a sua execução através do fornecimento de um conjunto de atributos que ajudam no programa de garantia de qualidade do projeto, através de checklists e templates. A principal diferença é que a Garantia de Qualidade proposta pelo RUP não é feita por um grupo separado, mas pelo mesmo grupo que desenvolve o projeto, o que não é aderente ao conceito de Garantia de Qualidade da NBR ISO/IEC 12207.
	Verificação	Não atende esse processo.
	Validação	Não atende esse processo.
	Revisão Conjunta	Atende parcialmente esse processo, pois ao final de cada fase são definidos milestones onde é prevista uma reunião conjunta envolvendo profissionais previamente selecionados. Como material de apoio são providos checklists e templates facilitando assim, o atingimento parcial do objetivo deste processo da NBR ISO/IEC 12207.
	Auditoria	Não atende esse processo.
	Resolução de Problema	Não atende esse processo.
	Gerência	Atende este processo através da Elaboração do Plano de Projeto de Software, Plano de Iteração e Lista de Risco. Avaliações periódicas são executadas durante todo o ciclo de vida do projeto através do Relatório de Avaliação de Situação. Algumas métricas são disponibilizadas relacionadas ao progresso, estabilidade, adaptabilidade, modularidade, qualidade, maturidade e perfil de recursos.
	Infra-estrutura	Atende parcialmente esse processo pois cita a necessidade de ferramentas, mas não cobre as necessidades de equipamentos, local físico, facilidades, etc.
	Melhoria	Não atende esse processo pois a melhoria proposta é para a próxima iteração ou incremento, mas não para a organização. O foco principal desse processo da Norma é a melhoria da organização.
	Treinamento	Não endereça esta questão deixando a responsabilidade para a organização.
Adaptação		Não atende esse processo, deixando a responsabilidade para a organização. No entanto, o RUP é construído através de componentes, o que o torna, teoricamente, adaptável a qualquer organização e projeto. No entanto, nenhum método é provido para ajudar nesta tarefa.

Tabela 1 - Comparativo da Norma NBR ISO/IEC 12207 e o RUP

Se uma organização desejar estar aderente à Norma NBR ISO/IEC 12207 e, conseqüentemente, implementar um programa de melhoria contínua de seus processos de software, ela necessitará mais do que a adoção do RUP. Isto não significa que não haja benefícios em utilizá-lo, uma vez que atende ao Processo de Desenvolvimento da Norma, e isto por si só já é um benefício. No entanto, conforme analisado na seção 4, os demais processos ou são atendidos parcialmente, ou não são sequer tratados e é a execução do conjunto dos processos previstos na NBR ISO/IEC 12207, e não de apenas um deles, que fornece o subsídio necessário para a produção de software com qualidade.

Parte dessas ausências já foi percebida e parcialmente suprida pela instanciação do UP efetuada pela Rational através do RUP, como por exemplo, a inserção dos workflows de apoio. Isto se evidencia pela preocupação também demonstrada na elaboração do documento [11], submetido à OMG por um grupo de grandes empresas (IBM, Rational Software, Unisys, etc.), no qual a NBR ISO/IEC 12207 é formalmente citada.

Acreditamos que, por esses motivos, é apenas uma questão de tempo para que estes processos sejam incorporados ao RUP, tornando-o um produto apto a implementar a NBR ISO/IEC 12207 nas organizações. Isto traz como vantagem tornar a implantação da Norma mais fácil para as empresas, uma vez que, além de processos já definidos, também provê métodos e ferramentas.

REFERÊNCIAS

[1] ARAÚJO, A.; VASCONCELOS, A. Adaptando o RUP para o desenvolvimento de sistemas de informação Web. In: CONFERÊNCIA INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, 11., 2000, Curitiba. Anais... Curitiba: CITS, 2000. p. 138-153.

[2] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 13596 - tecnologia de informação - avaliação de produto de software: características de qualidade e diretrizes para o seu uso. Rio de Janeiro: ABNT, 1996.

[3] _____. NBR ISO/IEC 12207 - tecnologia de informação: processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998.

[4] BRASIL. Ministério da Ciência e Tecnologia. Qualidade no setor de software brasileiro - 1999. Brasília: Ministério da Ciência e Tecnologia, 2000. Disponível em: <http://www.mct.gov.br/Temas/info/dsi/palestra/palestras.htm>

[5] INTERNATIONAL STANDARD ORGANIZATION. ISO/IEC TR 15504: Information Technology - software process assessment. Disponível em: <http://www.sqi.cit.gu.edu.au/spice/>

[6] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development process. Reading: Addison-Wesley, 1999. 463 p.

[7] KRUCHTEN, P. Rational Unified Process - an introduction. Reading: Addison-Wesley, 2000. 298 p.

[8] _____. A Rational development process: white paper. Disponível em: <http://www.rational.com/products/ rup/prodinfo/whitepapers/>

[9] PAULK, M. et al. Capability Maturity Model for software, Version 1.1. Pittsburg: SEI, Carnegie Mellon University, 1993. Disponível em: <http://www.sei.cmu.edu/pubs/ documents/93.reports/pdf/ 93tr024.pdf>

[10] RATIONAL CORPORATION. Rational Unified Process - best oractices for software development teams: white paper. Disponível em: <http://www.rational.com/products/ rup/prodinfo/whitepapers/>

[11] _____. Software process engineering management : the unified process model. Disponível em: <http://www.rational.com/products/ rup/prodinfo/whitepapers/> (White paper submetido à OMG em 12/05/2000).