CENTRO UNIVERSITRIO DE GOIS UNI-ANHANGUERA PR-REITORIA DE ENSINO, PESQUISA E EXTENSO NCLEO DE PS-GRADUAO GESTO DE SOFTWARE

SLVIO CNDIDO DA SILVA

2 SEMESTRE DE 2007

GERNCIA DE REQUISITOS: A INFLUNCIA NO AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE Slvio Cndido da Silva

Graduado em Tecnologia em Processamento de Dados pelo Centro Universitrio de Gois-Uni-ANHANGERA e Ps-Graduando em MBA em Gesto de Software pelo Centro Universitrio de Gois-Uni-ANHANGERA

RESUMO: Desenvolver software no uma tarefa fcil. A engenharia de software, tentando minimizar este problema, vem centrando esforos na criao e aprimoramento de metodologias e padres, que tornem o desenvolvimento de um produto mais controlado. Apesar deste grande esforo, no existe uma frmula mgica para o sucesso destas metodologias. Apesar de auxiliarem a vida dos desenvolvedores, a aplicao desta depende fundamentalmente da cultura e do processo organizacional da empresa. Pesquisas indicam nmeros preocupantes quando falamos em sucessos e fracassos no desenvolvimento de software, e dentro deste cenrio notamos que a falta de um controle eficaz sobre o desenvolvimento de requisitos tem sido um dos maiores problemas enfrentados pela indstria de software. Diante deste cenrio as empresas tm investido na qualidade de seus produtos, implantando modelos de maturidade e investindo na capacitao das suas equipes. A gerncia de requisitos surge neste cenrio com o propsito de tornar o controle sobre os requisitos satisfatrio dentro da organizao. Este artigo tem o objetivo de mostrar como a gerncia de requisitos atua sobre o controle destes requisitos desde sua concepo at a entrega final do produto. O estudo de caso mostra como a gerncia de requisitos influencia na qualidade de um produto atravs de indicadores. Por fim, os resultados so demonstrados e analisados, baseando sempre no grau de satisfao do cliente. PALAVRAS-CHAVE: Gerncia de Requisitos; gerncia de mudana em requisitos, rastreabilidade, engenharia de requisitos. 1. INTRODUO Nos ltimos anos as empresas de desenvolvimento de software tm se preocupado com a qualidade de seus produtos, tanto no desenvolvimento de novas aplicaes quanto na

manuteno das aplicaes existentes. A falta de um controle eficaz sobre os requisitos tem levado as empresas a passar por uma srie de problemas, como por exemplo, entrega do produto fora do prazo e acima do custo determinado, estimativas e alocao de recursos de forma inadequada. Some-se a isso, entrega de um produto final diferente do que o esperado pelo cliente e outras falhas que ocorrem devido falta de tratamento do impacto de mudanas. Diante desse cenrio, o que se nota um alto grau de insatisfao do cliente e um total descrdito para a equipe de desenvolvimento. Quando uma equipe de desenvolvimento inexperiente ou no tem o apoio necessrio para mudar este cenrio, o ciclo de crises e problemas se repete de tal forma que a equipe trabalha eternamente pressionada pela necessidade de entregar logo o produto sem se preocupar com o entendimento correto das necessidades do cliente e o devido tratamento das mudanas ocorridas. Isso, em princpio, pode parecer bem produtivo, porm, estamos construindo solues erradas e que iro acarretar em grandes insatisfaes no futuro. Visando detectar as principais causas de falhas nos projetos de software, o Standish Group (1995) fez uma pesquisa em 1995 entrevistando 365 empresas que representavam mais de oito mil projetos. Neste cenrio, foram identificados que 84% dos projetos falham e que as principais causas destas falhas esto nos requisitos, sendo que 12,8% esto na falta de especificao dos requisitos, 12,3% em requisitos incompletos e 11,8% esto na mudana de requisitos. Portanto, a concluso que se chega que a falta de uma gerncia que controla as mudanas e as especificaes corretas dos requisitos um dos principais problemas do desenvolvimento de software. McEwen (1994) diz que, requisitos pobres o grande problema do desenvolvimento de software. Diante desse cenrio, a Gerncia de Requisitos surge com o propsito de controlar os requisitos desde sua concepo at a entrega do software, garantindo assim maior envolvimento entre a equipe de desenvolvimento e o cliente, diminuindo problemas de entendimento e maior controle sobre as mudanas. Conforme a definio do MPS.Br - Melhoria de Processos de Software Brasileiro, Nvel G no guia de implementao do processo de Gerencia de Requisitos, o propsito do processo de Gerncia de Requisitos gerenciar os requisitos dos produtos e componentes do produto de projeto e identificar inconsistncias entre esses requisitos e os planos e produtos de trabalho do projeto. Esta definio est fortemente ligada definio feita pelo CMMI Capability Maturity Model Nvel 2.

Por meio da Gerncia de Requisitos possvel garantir que, ao longo do desenvolvimento de um produto, a parte tcnica e o cliente estejam envolvidos e comprometidos, estabelecendo um alto nvel de comprometimento atravs de critrios definidos pela prpria organizao. Outra caracterstica substancial da Gerncia de Requisitos o controle de mudana entre os requisitos, planos e os produtos de trabalho, garantindo controle eficaz sobre prazo, recurso e custo do desenvolvimento e conseqente diminuio da quantidade de problemas ocorridos. Tudo isso em conjunto s aumenta a qualidade do software e o grau de satisfao do cliente. Este artigo trata os conceitos, as boas prticas e mostra atravs de um estudo de caso, como a gerncia de requisitos influencia na qualidade de um produto. 2. REFERENCIAL TERICO 2.1. Gerncia de Requisitos 2.1.1. Requisitos Segundo o Institute of Electrical and Electronics Engineers, (IEEE, 1987), Requisito uma condio ou capacidade necessria para um usurio resolver um problema ou alcanar um objetivo. Outra definio da IEEE (1987) diz que Requisito uma condio ou capacidade que deve estar presente em um sistema para satisfazer um contrato, especificao, padro ou outro documento formalmente imposto ao projeto. Em virtude de ser uma necessidade que tem o propsito de atender o usurio, esta tarefa se torna difcil devido complexidade de extrair e entender algo abstrato ao qual em muitas vezes, no conhecemos. Sommerville (2003, p.102), define requisitos como sendo as descries das funes e restries para o sistema e define a engenharia de requisitos como sendo o processo de descobrir, analisar, documentar e verificar essas funes e restries. O autor do tema ainda distingue os requisitos em dois nveis de descrio e declara que alguns dos problemas que surgem na engenharia de requisitos so resultantes da falta de separao ntida entre estes nveis. O primeiro diz que o requisito detalha de forma abstrata e em alto nvel, uma funo fornecida pelo sistema ou uma restrio deste. Desta forma o requisito no ter uma soluo predefinida, permitindo desta forma, que todos os envolvidos possam apresentar suas idias de melhorias para as reais necessidades do cliente.

No outro nvel, o requisito uma descrio detalhada de uma funo do sistema. Uma vez definido o requisito, o fornecedor deve detalhar a necessidade de forma que o cliente entenda, aceite e se comprometa com a funo que o sistema atender. Estes dois nveis so tratados como sendo requisitos do usurio e requisitos do sistema respectivamente. Esta mudana de nvel o que chamamos de evoluo natural do requisito e controlada pela Gerncia de Requisitos atravs do estabelecimento da rastreabilidade. Esta prtica quando feita de maneira eficaz, faz com que o requisito seja controlado desde o mais alto nvel de abstrao at o de mais baixo nvel chegando at o requisito fonte. A Gerncia de requisitos um conjunto de atividades executadas em paralelo construo do sistema que auxiliam a equipe de projeto a identificar, controlar, rastrear e monitorar as mudanas nos requisitos. Segundo o guia de implementao da Melhoria de Software Brasileiro MPS.Br, O Principal objetivo controlar a evoluo de todos os requisitos gerados no projeto, tanto os funcionais quanto os no-funcionais. Leite (2006) ressalta que os requisitos a parte mais importante no processo de construo de software, e a razo mais evidente que no se pode construir nada, sem antes saber o que quer construir. Ele tambm define o processo de gerenciamento de requisitos em duas atividades: Gerencia dos Requisitos e Gerencia por Requisitos. A Gerencia dos Requisitos o processo que garante que as tarefas de produo de requisitos sejam bem executadas. J a Gerencia por Requisitos garante o controle sobre todo o processo de produo de requisitos, alm de ser uma atividade que se mantm ao longo do projeto. Por meio destes processos garantimos que os requisitos estejam claros, completos e bem entendidos por toda a equipe que participa do desenvolvimento, incluindo aqui o cliente. 2.1.2. Planejamento da Gerncia de Requisitos O Planejamento o primeiro aspecto que temos que considerar quando decidimos por Gerenciar Requisitos. Por meio deste possvel decidir os procedimentos e as polticas de gerenciamento no que diz respeito identificao, mudanas e rastreabilidade de requisitos. O plano de gerenciamento de requisitos direciona todas as atividades inerentes ao Gerenciamento de Requisitos. O planejamento de requisitos desenvolvido em paralelo s demais definies das atividades do planejamento do projeto. Sua funo descrever diretrizes das atividades da Gerncia de Requisitos. O Rational Unified Process,(RUP, 1987 2001) diz que um plano de gerenciamento de requisitos deve ser desenvolvido e este deve especificar as informaes e

prover mecanismos de controle para avaliar, reportar e controlar as mudanas efetuadas no projeto. Porm, mais que controlar mudanas, O RUP diz que o plano de gerenciamento de requisitos dever descrever como documentar, organizar e usar os atributos dos requisitos durante o ciclo de vida do projeto. O Plano dever ser consultado e re-avaliado ao longo do projeto. 2.1.3. Processo Engenharia de Requisitos O processo de engenharia de requisitos inclui a fase de viabilidade, obteno e anlise, especificao e a validao de requisitos. Aqui se encontra o principal problema da Engenharia de Software, pois no fcil compreender algo que muitas vezes esta implcita na idia do usurio. A situao ainda pior quando existe a necessidade de desenvolver um sistema novo. Devido a estas dificuldades encontradas que cada vez mais a organizao deve obter um processo de acordo com a sua necessidade. O modelo proposto a seguir sugerido por Sommerville (2003). A figura 1 mostra como funciona este processo e como as fases se interagem. No estudo de viabilidade, a idia deste processo obter uma viso global das necessidades do cliente. Nesta etapa o foco discutir se o desenvolvimento do software vivel ou no. Muitas vezes prefervel nem iniciar a fase de obteno e anlise de requisitos do que iniciar um software inadequado ou invivel para a organizao. Na fase de obteno e anlise no necessrio se preocupar com funcionalidades computacionais e ligaes entre componentes e outras coisas relacionadas a software. O foco aqui compreender e detalhar a idia do usurio e delimitar sua idia dentro de um contexto real. Este contexto inicial chama escopo. J a especificao de requisitos a fase onde a equipe tcnica detalha os requisitos do sistema e dos usurios, dando maior clareza e visibilidade, tornando-os mais fcil de entender, comprometer e aceitar.

Estudo de Viabilidade

Obteno e anlise de requisitos Especificao de requisitos Validao de requisitos Modelo de sistema Requisitos de usurio e de sistema

Relatrio de viabilidade

Documento de requisitos

Figura 1: Processo de engenharia de requisitos Fonte: Sommerville (2003, p.103) A validao dos requisitos a fase onde a gerncia de requisitos atua com maior grau de importncia nesta etapa. Aqui ela servir como uma ponte entre a parte tcnica e o cliente. Nesta fase a gerncia de requisitos atua para garantir que os requisitos esto claramente definidos, compreendidos e viveis de serem implementados. Esta garantia envolve toda a equipe do projeto, incluindo o cliente. O Guia de implementao do MPS.Br afirma que nesta fase, a Gerncia de Requisitos dever garantir o entendimento, a aceitao e o comprometimento por todos os envolvidos no projeto. Alm disso, o MPS.Br espera tambm que haja uma comunicao de forma continua ao longo do projeto. Esta comunicao inclui os fornecedores de requisitos e tem o objetivo de garantir o entendimento das necessidades do cliente e do projeto. Aps a fase inicial, com os requisitos entendidos e aceitos, eles estaro prontos para serem desenvolvidos. Aqui definida uma soluo aplicvel e compatvel aos requisitos levantados. Ao longo do projeto, Gerncia de Requisitos tambm atua de forma que garanta que os requisitos esto sendo implementados de acordo com a necessidade do cliente. A figura 2 mostra como as funcionalidades operacionais do software so resultados das atividades da engenharia de requisitos. interessante observar que na medida em que os requisitos so desenvolvidos eles vo se transformando em funcionalidades do software. O funcionamento deste processo depende fundamentalmente da poltica organizacional da empresa. A necessidade de documentar os requisitos e seus atributos se

justifica quando pensamos que o software se degrada com o tempo e que num futuro prximo necessitaremos consultar esta documentao para manutenes.

Engenharia de sistemas

Anlise de requisitos de software Projeto de Software

Figura 2: Anlise como ponte entre engenharia de sistemas e o projeto de software Fonte: Pressman (2002, p.207) 2.1.4. Gerenciamento de Mudanas Mudanas em requisitos so muito comuns quando o assunto Engenharia de Software. No inicio do processo de engenharia de requisitos, nem o usurio sabe como suas necessidades sero implementadas e muito menos a equipe tcnica sabe como o usurio deseja utilizar funcionalidade do software. Este problema geralmente ocorre em grandes produtos. Desta forma, difcil entender o problema na sua totalidade logo no incio da fase de engenharia de requisitos e esta dificuldade fatalmente tornar os requisitos incompletos. Isto naturalmente aceitvel, visto que na medida em que os requisitos so desenvolvidos, o seu entendimento tambm melhora. Esta melhora esta associada mudana nos requisitos. Existem outros motivos que necessitam de mudana de requisitos. Dentre estes encontramos alteraes nos objetivos da organizao, correes de no conformidades entre o software e os produtos de trabalho ou at mesmo novas idias por parte dos interessados. Sommerville (2003) diz que grandes sistemas de software so utilizados para melhorar sistemas atuais, sejam eles manuais ou computacionais. Porm, em qualquer

sistema, sempre haver a necessidade de melhorar ou acrescentar alguma necessidade do usurio. Neste contexto, o que percebemos que requisitos mudam por uma srie de fatores e esta mudana inevitvel. Diante disto, chegamos concluso que existe uma necessidade de controlar estas mudanas de forma que atenda s necessidades do usurio. Outra percepo que temos que a organizao e a equipe devero estar preparadas quando uma mudana for necessria. O processo de gerenciamento de mudanas em requisitos garante que todas as mudanas nos requisitos so feitas de forma controlada. Sommerville (2003) define este processo como sendo o conjunto de atividades que avalia o impacto e o custo das mudanas. Ele diz tambm que este dever ser aplicado sempre que ocorrer uma proposta de mudana nos requisitos do projeto. A gerencia de mudanas em requisitos garante que as mudanas nos requisitos sero devidamente controladas de forma que sua viabilidade seja analisada sob vrios aspectos, incluindo custo e tempo. importante salientar que sem um processo de Gerncia de Mudanas em Requisitos no possvel garantir o sucesso de um projeto. Por outro lado, mudana nos requisitos no significa que o processo de engenharia de requisitos tenha sido falho. A figura 3 mostra um processo de gerenciamento de mudana de forma resumida. Esta figura foi proposta por Sommerville e discutiremos cada fase frente.

Problema Identificado

Anlise do problema e especificao da mudana

Anlise e custo da mudana

Implementao da mudana

Requisitos Revisados

Figura 3: Gerenciamento de mudana de requisitos Fonte: Sommerville (2003, p.122) A anlise do problema inicia com a recepo e identificao desta mudana. Aps isso, a validade da mudana analisada, o grau de importncia e o detalhamento desta necessidade so especificados. Em projetos novos, quanto mais cedo for detectado esta mudana, menor ser o impacto desta no projeto.

10

A anlise e custo da mudana a fase onde feito rastreabilidade do requisito e medido o impacto da mudana proposta no projeto. Nesta fase tambm medido o custo e o tempo que ter a mudana. O guia de implementao do MPS.Br diz que toda mudana proposta nos requisitos deve ter um estudo de viabilidade. Em alguns casos, prefervel no implementar a mudana ou at mesmo parar um projeto, devido ao impacto que esta ter sobre o produto. Uma vez aprovada a mudana por todos os envolvidos, a mudana ser implementada no produto. Neste momento a rastreabilidade dever ser atualizada e todos os requisitos que sofrero modificaes devero ser atualizados. bom lembrar que toda a documentao que envolve os requisitos tambm dever sofrer alteraes. O Processo de Gerenciamento de Mudana uma etapa que a Gerncia de Requisitos atua constantemente. Nesta etapa, ela deve monitorar o desenvolvimento dos requisitos, verificar e aprovar as mudanas juntamente com o cliente sempre que for necessrio. 2.1.5. Rastreabilidade A rastreabilidade outro item importante quando falamos em Gerncia de Requisitos. Sem ela no possvel ter um gerenciamento de requisitos eficaz. Vimos anteriormente que quando ocorre uma mudana nos requisitos, o impacto desta mudana entre requisitos, requisitos e projeto de software e requisitos e artefatos do produto devero ser verificados. Sem o rastreamento, a gerncia de requisitos no conseguir antecipar o impacto de uma mudana nos requisitos. Um requisito rastrevel se possvel descobrir quem sugeriu o requisito (a fonte), por que o requisito existe (rationale), que outros requisitos esto relacionados a ele (dependncia entre requisitos) e como o requisito se relaciona com outras informaes tais como desenho do sistema, implementao e documentao do usurio (Sayo e Leite apud Sommerville, 1998). Um dos fatores que medem a qualidade de manuteno em software o grau de facilidade de se encontrar as decomposies e as dependncias entre os requisitos e entre os requisitos e os produtos de trabalho. Quanto melhor estiverem detalhadas estas dependncias e decomposies, mais rpida ser a analise do impacto da mudana.

11

Uma boa prtica sugerida criar essa rastreabilidade na medida em que os requisitos so desenvolvidos. Pode ser uma atividade paralela ao desenvolvimento do produto. Assim, quando surgir uma mudana mesmo no decorrer do desenvolvimento, possvel verificar as dependncias e as decomposies. Quando falamos em dependncias de requisitos estamos falando de relacionamento horizontal e quando falamos em decomposio de requisitos estamos falando de relacionamento vertical. O guia de implementao do MPS.Br - Nvel G, descreve que o relacionamento horizontal estabelece a ligao de dependncia entre requisitos e outros itens como por exemplo o cdigo fonte de um software. J o relacionamento vertical estabelece a decomposio de cada requisito at o seu nvel fonte de mais baixo nvel. Esta rastreabilidade tambm estabelece ligao com os produtos de trabalhos e os planos do projeto de software. Atravs desta, possvel analisar com mais preciso o impacto de uma mudana no projeto. A tabela 1 representa um exemplo de uma matriz simples de rastreabilidade: Tabela 1: Uma matriz de facilidade de rastreamento
ID do Requisito 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 R R U R R R U R U R U U U R U 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

Fonte: Sommerville (2003, p.120) A letra U representa que o requisito da linha esta utilizando o requisito da coluna, enquanto a letra R significa que existe uma relao fraca entre requisitos. Matriz de rastreabilidade so muito utilizadas quando requisitos precisam ser gerenciados. A gerncia da rastreabilidade quando feita de maneira eficaz, permite identificar o requisito fonte at o requisito de mais baixo nvel e vice-versa. Esta prtica chamamos de rastreabilidade bidirecional. Sayo e Leite (2005) afirmam que o rastreamento de requisitos utilizado para prover relacionamentos entre os requisitos do projeto, a arquitetura e a

12

implementao final do software e que este possibilita a compreenso dos relacionamentos de dependncia entre requisitos. A rastreabilidade torna possvel negociar o prazo e o custo com o cliente quando alguma mudana no projeto solicitada, pois, permite dar visibilidade sobre o impacto desta mudana no projeto. Esta medida diminui os riscos do projeto atravs de uma anlise de viabilidade da mudana. 2.2. Qualidade de Software Nos ltimos anos as empresas de desenvolvimento de software tm voltado suas atenes para a qualidade de seus produtos. Seja em desenvolvimento de novas aplicaes ou na manuteno de softwares existentes, a busca constante pela qualidade tem se tornado um fator obrigatrio. Esta preocupao tem uma razo clara: O diferencial competitivo. Afinal, a tecnologia tem sido um dos itens mais importantes nas mais diversas reas da sociedade. E dentro deste cenrio, o que mais se percebe a procura cada vez maior por produtos com qualidade no menor preo possvel. Leite (2001) diz que esta a funo da engenharia de software: tornar o software dentro do nvel de qualidade exigido com o menor custo possvel. Este tem sido um desafio enorme para a rea de Engenharia de Software que vem amadurecendo ano aps ano. Se esta for comparada a outras, como por exemplo, a Medicina, a Engenharia e outras reas da sociedade, ela ainda est em processo de amadurecimento. Barti (2002) diz que o grande desafio da Engenharia de Software neste inicio de sculo XXI, consolidar um processo que consiga assegurar a qualidade dos produtos e servios. Mesmo sendo uma rea nova se comparada s outras, o que faz a tecnologia evoluir em ritmo acelerado a necessidade que as outras reas da sociedade tm para utiliz-la. A tendncia que cada vez mais, esta necessidade seja mais freqente. Barti (2002) diz que este um processo praticamente irreversvel. Porm, quanto mais as organizaes precisam da tecnologia para se sobressair no mercado competitivo, mais esta necessita evoluir. E a dependncia desta tecnolgica est intimamente ligada utilizao de sistemas informatizados. Devido a isto, as organizaes precisam de sistemas informatizados que lhes garantam mais eficincia e maior controle gerencial. Portanto, chega concluso que a tecnologia tem sido fator estratgico dentro das organizaes.

13

Diante deste cenrio, as empresas de desenvolvimento de software tm voltado suas atenes na qualidade de seus produtos e servios. Alm do mais, essas empresas comeam a notar que quando seus softwares no atendem s expectativas do cliente, alm de ficarem praticamente fora do mercado, ainda tero um custo muito maior nas manutenes corretivas. Quando a empresa entra neste ciclo, a tendncia que chegar um momento que no ser mais vivel dar manuteno neste produto e a melhor sada descontinu-lo. Portanto, vale ressaltar que as organizaes tm forado a indstria de software para produzir seus produtos com qualidade. A criao de normas nacionais, internacionais e os institutos como, por exemplo, a SEI Software Engineering Institute, esto cada vez mais presentes no vocabulrio destas indstrias que apontam suas foras para atender aos resultados esperados destas. Outro fator importante a considerar na produo do software o item intelectual do processo. importante ressaltar que ter um processo de qualidade implantado dentro da organizao no garante que o produto sair com a qualidade esperada pelo cliente. necessrio que se tenha uma equipe comprometida e qualificada. Portanto, chegamos concluso que para atingir a qualidade, necessitamos de um conjunto de fatores como processos, pessoas, infra-estrutura e outras. No entanto, a implantao de um processo de qualidade dentro de uma organizao tem um custo elevado, o que leva muitas empresas a ter um falso entendimento sobre a forma de aplicar esta em seus processos de desenvolvimento. Porm, nota-se que quando a qualidade aplicada apenas em uma parte do ciclo de desenvolvimento, esta parte tende a melhorar. Diante disto, com o passar do tempo, a empresa torna a aplicao do seu processo de qualidade gradativo sobre seus processos de desenvolvimento. Alis, esta tem sido uma boa prtica: Planeja a aplicao do processo, aplica, verifica se este foi satisfatrio e melhora. Este ciclo chamado de PDCA Plan, Do, Check e Act. o ciclo de melhoria continua dos processos. Implantar um processo de qualidade no uma tarefa fcil. Requer tempo, investimento e alto grau de comprometimento da alta gerncia e da empresa como um todo. Devido a esta dificuldade que os modelos de avaliao de maturidade em software possuem vrias etapas que a empresa pode segui-las dentro de cada rea. o caso dos vrios nveis que os modelos de maturidade possuem. Estes modelos avaliam os processos das empresas atravs de mtodos e critrios devidamente definidos e medem tambm o nvel de maturidade que este se encontra. Estes modelos tm como foco

14

principal o aperfeioamento continuo de seus processos para garantir a qualidade de seus produtos. 2.2.1. Capability Maturity Model - CMM Este modelo foi criado pela SEI com o intuito de tornar possvel a melhoria dos processos nas empresas e com isso melhorar a qualidade de seus produtos. Este modelo tem uma estrutura de nveis de maturidade com todos os elementos para a melhoria do processo de desenvolvimento de software. Este modelo evolutivo e parte do nvel um (total falta de controle e gerenciamento) at o nvel cinco (em otimizao dos processos) conforme mostra a figura 5.

Figura 4: Os cinco nveis do CMM para software. Fonte: Fagundes (2007) Este processo no permite organizao sair do nvel um e pular diretamente para o 4, por exemplo. Cada nvel pr-requisito para o outro nvel e cada organizao configura os seus processos para atender o nvel desejado. Barti (2002) diz que mais de 85% das empresas ainda est no nvel 1. Isto preocupante, pois mostra que estas empresas esto produzindo software sem controles dos seus processos e sem a algo que garanta a qualidade de seus produtos. Estas empresas, conforme j dito anteriormente, a continuar assim correm um srio risco de desaparecerem. Algumas empresas j conseguiram o nvel 5 e esto na etapa de melhoria dos

15

seus processos. Diante deste cenrio, percebemos que o maior problema das empresas iniciar este processo. A tabela 2: reas-chave de processos SW-CMM de acordo o nvel de maturidade e categoria de processos.

Fonte: Sotille (2006) A Gerncia de Requisitos uma rea de garantia do nvel 2 do CMM e tem como atividades documentar as mudanas nos requisitos e manter a rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos do produto e componentes do software. 2.2.2. Melhoria de Processo Brasileiro - MPS.Br Este modelo foi criado em 2003 e hoje coordenado pela Associao para Promoo da Excelncia do Software Brasileiro SOFTEX e conta com o apoio do Ministrio da Cincia e Tecnologia - MCT, da Financiadora de Estudos FINEP e do Banco Interamericano de Desenvolvimento BID.

16

O foco principal deste modelo atingir s micros, pequenas e mdias empresas, embora isto no seja uma exclusividade, pois, ele pode ser implementado em qualquer tamanho de organizao. O seu guia de implementao diz que esperado que o MPS.Br seja compatvel com nveis internacionais de padres de qualidade. A Figura 6 mostra os 3 componentes que mobilizam o programa do MPS.Br.

Figura 5: Os cinco nveis do CMM para software. Fonte: Guia geral de implementao do MPS.Br (2006) No modelo referncia, contm as definies dos nveis de maturidade, processos e atributos do processo. J o mtodo de avaliao um guia para os avaliadores verificarem os resultados esperados. J o modelo de negcio diz as regras a serem utilizadas pelas unidades avaliadoras. Segundo o guia MPS.Br (2006) a empresa capaz de melhorar significativamente seus processos em perodo de um a dois anos a custo relativamente baixo, enquanto utilizando o CMM necessrio um esforo entre quatro a dez anos. Isto s confirma o foco deste modelo nas micros, pequenas e mdias empresas. A figura 7 mostra os nveis de maturidade do MPS.Br, e os atributos do processo AP. Estes atributos servem como uma extenso para o resultado atingir o propsito. A gerncia de requisitos se encontra no nvel G do MPS.Br e tem como atividades principais a gerncia dos requisitos dos produtos juntamente com os componentes do produto do projeto

17

e identificar as consistncias que ocorrem entre estes requisitos e os planos de trabalho do projeto.

Figura 6: Nveis de maturidade do MR-MPS Fonte: Guia geral de implementao do MPS.Br (2006) 2.2.3. Objetivo da Qualidade O principal objetivo da Qualidade de Software garantir que o produto final satisfaa s exigncias do cliente atravs de procedimentos e normas dentro de um processo de desenvolvimento. A demanda pela aplicao desta no desenvolvimento e na manuteno de produtos tem levado a comunidade de software a investir em qualificaes e estabelecer processos.

18

Seja qual for o modelo escolhido, a aplicao deste depende da cultura organizacional da empresa, porm um processo de qualidade eficaz deve abranger o software, o processo, a equipe, os planos e os produtos de trabalho e tudo mais que envolve o desenvolvimento deste. 3. METODOLOGIA 4. CONCLUSO O processo gerncia de requisitos torna possvel a garantia da qualidade de um produto de software. O presente artigo foi motivado pela necessidade de implementar padres e metodologias para diminuir os problemas relacionados falta de entendimento e conseqente insatisfao dos clientes. A gerncia de requisitos quando feita de forma satisfatria e de acordo com as polticas organizacionais, garante uma participao ativa do cliente durante todo o ciclo de desenvolvimento de software e torna possvel manter a equipe de desenvolvimento motivada e comprometida com o objetivo final do produto. O estudo de caso demonstrou que no fcil criar, implantar e utilizar um processo dentro de uma estrutura de organizacional. A utilizao de ferramentas de gerenciamento de requisitos, ferramenta case e outras que auxiliam nos registros dos requisitos altamente recomendada. Finalmente depois de utilizado processo, a tendncia agora o processo comece a ser melhorado e outros processos sero criados dentro do prprio ncleo de desenvolvimento. Este processo ser submetido avaliao do MPS.Br. E toda a empresa tem a certeza que os nveis sero alcanados na medida em que o processo melhora. Porm, o mais importante saber que o comprometimento do cliente, da empresa e de todos os envolvidos foi alcanado. REFERNCIA BIBLIOGRFICA ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Avaliao, Verso 1.1, Maio/2006 Disponvel em <www.softex.br>. Acesso em 08/11/2007.

19

BARTI, Alexandre. Garantia de Qualidade de Software. 1 Edio. Rio de Janeiro. Editora Campus, 2002. FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software, 2007. Disponvel em: <http://www.efagundes.com/artigos/CMM.htm>. Acesso em: 08 Novembro 2007. HAZAN, Cludia; LEITE, Julio Csar Sampaio do Prado. Indicadores para Gerncia de Requisitos. 2004. Disponvel em <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/claudia_hazan.pdf>. Acesso em: 28 agosto de 2007. LEITE, Julio Csar Sampaio do Prado.Gerncia dos Requisitos X Gerncia por Requisitos, 2006. Disponvel em: <http://jcspl.wordpress.com/tag/requisitos/>. Acesso em: 08 Outubro 2007. LEITE, Jlio Csar Sampaio do Prado. Gerenciando a Qualidade de Software com Base em Requisitos, 2001. Disponvel em <http://www-di.inf.puc-rio.br/~julio/Slct-pub/Livro-qualidade.pdf>. Acesso em: 24 Outubro 2007. MACHADO, Cristina ngela Filipak; ANTUNES, Dante Carlos. Rumo ao gerenciamento de requisitos: uma experincia da Celepar, 1998 Disponvel em <www.pr.gov.br/batebyte/edicoes/1998/bb82/rumo.htm>. Acesso em: 08 Agosto 2007. MCEWEN, Scott.Requirements: An Introduction, 2004. Disponvel em <www-128.ibm.com/developerworks/rational/library/4166.html#N1008E>. Acesso em: 18 Setembro 2007. PRESSMAN, Roger S. Engenharia de Software. 5 Edio, Rio de Janeiro. Editora McGraw-Hillm 2002. SAYO, Miriam; LEITE, Julio Csar Sampaio do Prado. Rastreabilidade de Requisitos. 2005. Disponvel em <http://www-di.inf.puc-rio.br/%7Ejulio/rastreabilidade5.pdf>. Acesso em: 16 Outubro 2007. SOMMERVILLE, Ian. Engenharia de Software. 6 edio, Rio de Janeiro., Editora Pearson, 2003. SOTILLE, Mauro. Gerenciamento de Projetos na Engenharia de Software, 2006. Disponvel em: <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso em: 08 Novembro 2007. THE STANDISH GROUP. The CHAOS Report (1994).1995. Disponvel <standishgroup.com/sample_research/chaos_1994_1.php>. Acesso em: 16 Agosto 2007. em

20

TSUKUMO, Alfredo N. et al. Qualidade de Software: Vises de Produto e Processo de Software, 1997. Disponvel em <http://www.prodepa.psi.br/sqp/pdf/Qualidade%20de%20Software.pdf>. Acessado em 30 Outubro 2007.