UNIVERSIDADE DE PASSO FUNDO

Vagner Hanel

PhpRm: Uma ferramenta de apoio ao modelo CMMI.

Passo Fundo
2004

UNIVERSIDADE DE PASSO FUNDO

INSTITUTO DE CINCIAS EXATAS E GEOCINCIAS CURSO DE CINCIA DA COMPUTAO

PhpRm: Uma ferramenta de apoio ao modelo CMMI.

Vagner Hanel
Monografia apresentada ao Curso de Cincia da Computao do Instituto de Cincias Exatas e Geocincias da Universidade de Passo Fundo, como parte das exigncias para obteno do grau de Bacharel em Cincia da Computao, sob orientao do Professor Alexandre Lazaretti Zanatta.

Passo Fundo 2004

Ao meu pai Nilson Hanel e a minha me Vanda Trs Hanel fontes inesgotveis de amor e dedicao.

Do fundo do corao, agradeo a todos os companheiros desta difcil e trabalhosa caminhada. Aos amigos e colegas que partilharam momentos nicos e especiais durante a faculdade. Aos colegas de trabalho da Diviso de TI da UPF, pelo apoio nesta jornada, principalmente ao amigo Diego, pela companhia nos difceis momentos pelos quais passamos. Ao Professor Alexandre Lazaretti Zanatta, orientador deste trabalho, pela ajuda e pacincia durante a realizao desta monografia. Ao meu irmo Marcelo, pelo apoio moral, intelectual, por sua amizade e pelos bons e maus momentos passados juntos. Cssia, minha namorada, por todo amor, carinho, dedicao e compreenso ao longo deste ano. Em especial aos meus pais, Nilson e Vanda, pela pacincia, fora, determinao, amor e amizade, tornando mais fcil o caminhar.

RESUMO

Este trabalho tem como objetivo contribuir, por meio dos processos da Engenharia de Requisitos e das reas de processo de Gerenciamento e Desenvolvimento de Requisitos do modelo CMMI, na melhoria e na capacitao do processo de desenvolvimento de produtos de software. Para tanto, torna-se necessrio, alm da conceituao da Engenharia de Software e do modelo CMMI, o desenvolvimento de uma ferramenta para apoiar os mesmos. A ferramenta phpRm proposta por Gampert (2003), foi reestruturada para acompanhar a evoluo do modelo CMM e capacitar as reas de processo de Gerenciamento e Desenvolvimento de Requisitos do modelo CMMI. A partir dos resultados obtidos na utilizao da ferramenta no projeto Portal Simuplan e da anlise do CMMI em relao ferramenta, observa-se que, a princpio, foi possvel atingir o segundo nvel de capacidade nessas duas reas de processo.

Palavras-chave: CMMI, Engenharia de Requisitos, Gerenciamento de Requisitos, Desenvolvimento de Requisitos.

SUMRIO

INTRODUO ................................................................................................................ 7 1 PROCESSO DE SOFTWARE ................................................................................... 9 1.1 Engenharia de Requisitos ..................................................................................... 10 2 CMMI - CAPABILITY MATURITY MODEL INTEGRATION .......................... 17 2.1 Principais diferenas entre o CMMI e o SW-CMM .............................................. 18 2.2 O modelo CMMI ................................................................................................. 19 2.3 A estrutura do modelo CMMI .............................................................................. 20 2.4 Escolhendo a Representao ................................................................................ 22 2.5 Representao Contnua....................................................................................... 22 2.6 Categoria Engenharia ........................................................................................... 25 2.7 Gerenciamento de Requisitos (REQM) ................................................................ 27 2.8 Desenvolvimento de Requisitos (RD)................................................................... 30 3 A FERRAMENTA PHPRM .................................................................................... 38 3.1 Anlise das Funcionalidades da Ferramenta phpRm ............................................. 41 3.2 Resultados da Anlise das Funcionalidades.......................................................... 46 4 ANLISE DA FERRAMENTA PHPRM ................................................................ 49 4.1 Anlise da rea de processo REQM...................................................................... 49 4.2 Anlise da rea de processo RD ........................................................................... 52 4.3 Anlise dos Resultados ........................................................................................ 57 5 UMA APLICAO PRTICA............................................................................... 60 5.1 O Simuplan.......................................................................................................... 60 5.2 Por que o Simuplan? ............................................................................................ 61 5.3 Utilizando a Ferramenta phpRm........................................................................... 61 5.4 Resultados Obtidos .............................................................................................. 70

CONCLUSO ................................................................................................................ 71 REFERNCIAS .............................................................................................................. 73 OBRAS CONSULTADAS .............................................................................................. 74

LISTA DE ILUSTRAES

Figura 1 O processo de engenharia de requisitos ........................................................... 11 Figura 2 Incidncia de defeitos nas etapas de desenvolvimento..................................... 12 Figura 3 Componentes do Modelo CMMI..................................................................... 21 Figura 4 Representao do Modelo Contnuo................................................................ 23 Figura 5 Modelo CMMI na Representao Contnuo .................................................... 24 Figura 6 reas de processo da Engenharia .................................................................... 26 Figura 7 Ciclo de vida dos requisitos ............................................................................ 39 Figura 8 - Tela principal da ferramenta phpRm................................................................ 41 Figura 9 Resultado da anlise das funcionalidades da ferramenta phpRm...................... 47 Figura 10 Grfico da anlise das funcionalidades da ferramenta phpRm ....................... 47 Figura 11 Checklist dos requisitos ................................................................................ 50 Figura 12 - Inconsistncia entre os requisitos e os componentes do produto..................... 52 Figura 13 - Requisitos da baseline ................................................................................... 54 Figura 14 Resultado da anlise da ferramenta phpRm ................................................... 57 Figura 15 Percentual atendido pela ferramenta.............................................................. 58 Figura 16 Percentual atendido para cada rea de processo............................................. 59 Figura 17 Checklist de entendimento dos requisitos ...................................................... 64 Figura 18 - Relatrio de Riscos nos Requisitos ................................................................ 67

LISTA DE ABREVIATURAS E SIGLAS

CMM: Capability Maturity Model for software CMMI: Capability Maturity Model for software Integration HTML: Hypertext Markup Language ISO: International Organization for Standardization PI: Product Integration PHP: Hypertext Preprocessor RD: Requirements Development REQM: Requirements Management SEI: Software Engineering Institute SP: Specific Practices TS: Technical Solution VER: Verification VAL: Validation

INTRODUO

A demanda e a complexidade dos produtos de software vem aumentando com o passar do tempo, com isso, a qualidade, a produtividade e a agilidade so consideradas fatores crticos para a competitividade das organizaes de desenvolvimento de software. Para manter-se nesse cenrio competitivo e diminuir o tempo de resposta aos clientes, fazse necessrio a implantao de boas prticas para a melhoria do processo de desenvolvimento de software. Neste contexto situam-se vrias organizaes que vem investindo na qualidade, almejando melhorar seus processos de desenvolvimento de software. Com base nesta motivao, o presente estudo foi elaborado com o objetivo de evoluir a ferramenta phpRm para a rea de processo Gerenciamento de Requisitos do modelo CMMI e incorporar a rea de Desenvolvimento de Requisitos. Ele divide-se em 5 (cinco) captulos, sendo que o primeiro aborda os processos de software, compreendendo os conceitos de software e seus processos de desenvolvimento. Aps so apresentados os processos da engenharia de requisitos: a importncia dos requisitos num projeto; o documento de requisitos; a validao e verificao dos requisitos. O segundo captulo apresenta o modelo CMMI que determina a melhoria na maturidade do processo de desenvolvimento de software. Uma abordagem do modelo CMMI, sua estrutura, o modelo contnuo e de forma mais detalhada apresenta as reas de processo Gerenciamento de Requisitos e Desenvolvimento de Requisitos com suas respectivas prticas especficas. No terceiro captulo apresentado uma descrio da ferramenta phpRm e suas funcionalidades. Aps feita uma comparao das prticas especficas das reas de processo REQM e RD com a ferramenta. Tendo como objetivo analisar quais foram as mudanas necessrias para adequ-la com o modelo CMMI.

O quarto captulo submete a ferramenta phpRm a uma anlise para verificar se o objetivo do trabalho foi alcanado, ou seja, se foram as reas de processo REQM e RD foram atendidas. O quinto captulo apresenta o relato de uma aplicao prtica, com o objetivo de validar a ferramenta phpRm e gerenciar um projeto de acordo com o modelo CMMI. O captulo finalizado com a apresentao dos resultados. Finalmente, apresentada a concluso deste estudo.

1 PROCESSO DE SOFTWARE

Hoje em dia a grande maioria das empresas dependem de sistemas baseados em computadores e software, estas empresas podero sofrer conseqncias irreparveis se alguns destes sistemas deixarem de funcionar. De acordo com Sommerville (2003, p.5), software no apenas um programa de computador, mas tambm toda a documentao e configuraes que so necessrias para que ele funcione corretamente. Um produto de software, por sua vez, um conjunto de programas associados, suas configuraes e sua documentao, que descreve a estrutura do software e as instrues de utilizao para o usurio final. Um processo de software um conjunto de atividades e resultados associados que geram um produto de software (SOMMERVILLE, 2003, p.7). H uma grande diversidade com os processos de software devido a sua complexidade, cada empresa utiliza um processo que mais se adapte com suas as necessidades. No entanto, existem atividades fundamentais comuns a todos os processos de software: Especificao de software: A funcionalidade do software definida, bem como as suas restries; Desenvolvimento de software: O software projetado e desenvolvido para atender aos requisitos definidos anteriormente; Validao de software: O software deve ser validado para garantir que funciona de acordo com o que foi especificado; Manuteno de software: O software evolui para atender as necessidades do cliente que esto em constante mudana.

10

1.1 Engenharia de Requisitos

A especificao de software ou tambm conhecida como engenharia de requisitos, tem como objetivo estabelecer as funes requeridas e as restries sobre a operao e o desenvolvimento do sistema. uma fase particularmente importante, uma vez que se ocorrerem erros nessa fase fica inevitvel que problemas apaream no projeto e na implementao (SOMMERVILLE, 2003, p. 46). O processo de engenharia de requisitos deve estabelecer todos os requisitos do sistema, esses devem ser documentados, produzindo a documentao de requisitos, que a especificao para o sistema. aconselhvel que esta documentao seja apresentada em dois tipos: com a definio dos requisitos, que deve ser escrita de forma que o cliente possa entender; e a especificao de requisitos, que contm os termos tcnicos para o desenvolvimento do projeto do sistema. Para conseguir produzir uma documentao de requisitos adequada, devem-se seguir alguns processos da engenharia de requisitos. Segundo Sommerville (2003, p. 46) existem quatro fases principais: 1. Estudo de viabilidade: Verificar se possvel atender as necessidades dos usurios. O estudo ir decidir se o sistema poder ser desenvolvido considerando as restries oramentrias existentes. Este deve ser rpido e barato, e tambm deve informar se a anlise deve prosseguir. 2. Levantamento e anlise de requisitos: Identificar os requisitos do sistema, podendo ser utilizadas tcnicas como: observao do sistema existente, reunies com usurios, anlise de tarefas, desenvolvimento de modelos de prottipos, entre outras tcnicas para obter requisitos. Esse processo auxilia o analista a entender o sistema a ser especificado. 3. Especificao de requisitos: Traduzir as informaes coletadas durante o levantamento e anlise de requisitos para um documento que defina um conjunto de requisitos. Neste documento podem ser includos os requisitos dos usurios e os requisitos do sistema. 4. Validao de requisitos: Verificar e classificar os requisitos quanto a sua pertinncia, consistncia e integralidade. Os erros na documentao dos requisitos so descobertos nesse processo e devem ser modificados para corrigir os problemas.

11

O processo de engenharia de requisitos descrito anteriormente mostrado na Figura 1.

Fonte: SOMMERVILLE, Ian (2003, p.47). Figura 1 O processo de engenharia de requisitos

As atividades no processo de requisitos no so seguidas em uma seqncia, tendo em vista que durante a engenharia de requisitos surgem novos requisitos assim como eles mudam freqentemente. Dentro das principais fases da engenharia de requisitos, como visto anteriormente, deve ser dada uma maior nfase na fase de levantamento e anlise de requisitos, pois aqui que as funcionalidades do sistema sero compreendidas. Se um requisito no entendido amplamente pelo analista, esse requisito ser especificado e poder ser validado sem identificar o problema. Para entender melhor essas fases e saber como analisar um requisito para evitar problemas, ser apresentado a seguir um conceito de requisitos, o porqu so importantes, como identific-los e classific-los, a documentao dos requisitos e como valid-los.

1.1.1 O que so requisitos

Segundo Pfleeger (2004, p.111), um requisito uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar, para atingir seus objetivos".

12

Para Sommerville (2003, p.99), os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restries sobre sua operao e implementao. Ambos os autores definem os requisitos como uma funcionalidade do sistema, que so derivadas das necessidades que os usurios tm de resolver algum problema ou atender a alguma especificao. Os requisitos indicam um propsito para o sistema, indicando o que o sistema deve fazer e no tendo a preocupao de como o mesmo ser implementado. Estes requisitos formam a base para a implementao do sistema, por isso devem ser analisados, especificados e validados criteriosamente.

1.1.2 Porque os requisitos so importantes

Conforme Gampert (2003, p. 62) citando Barti, a maioria dos defeitos so resultados de tradues imperfeitas de requisitos e especificaes, conforme Figura 2.

10% 7% Requisitos Anlise e Modelagem Implementao 27% 56% Outros

Fonte: Gampert (2003, p.62) citando Barti. Figura 2 Incidncia de defeitos nas etapas de desenvolvimento

Como pode ser analisado na Figura 2, a inabilidade para trabalhar com os usurios e entender melhor suas necessidades ou requisitos na fase de identificao do problema, conhecida como anlise de requisitos, pode ser identificada como a principal fonte de erro no ciclo de vida de um software. Assim, vale a pena utilizar algum tempo para entender o problema e identificar os requisitos certos na primeira vez.

13

1.1.3 Identificao e classificao dos requisitos

Para Pfleeger (2004, p.113), a identificao dos requisitos uma parte especialmente importante do processo. Deve-se trabalhar com os clientes e usurios do sistema, com o objetivo de entender e analisar os problemas antes de considerar qualquer soluo para eles. Uma maneira de realizar a anlise do problema identificar as pessoas, os processos e recursos envolvidos, e documentar a relao entre eles para tentar determinar o limite do sistema. Durante toda a identificao dos requisitos, a mesma pergunta deve ser feita vrias vezes de maneira diferente, para ter certeza que entendemos o que os usurios e clientes querem e precisam. Ainda segundo Pfleeger, importante dividir os requisitos em trs categorias: 1. Requisitos que devem ser totalmente satisfeitos; 2. Requisitos que so altamente desejveis, mas no necessrios; 3. Requisitos que so possveis, mas poderiam ser eliminados. Pfleeger define porque importante dividir os requisitos em categorias:

A anlise de requisitos por categoria til, para que todas as partes entrem em entendimento sobre o que realmente necessrio. Ela tambm til quando um projeto de desenvolvimento de software est restrito pelo tempo ou por recursos (2004, p.113).

Os requisitos so obtidos no incio do desenvolvimento com o objetivo de determinar a natureza do problema do cliente, no deve ser discutida nenhuma soluo at que o problema esteja claramente definido. As atividades de um sistema so descritas pelos requisitos, tais como uma reao insero de dados, e o estado de cada entidade antes e depois da atividade ocorrer. Para ajudar a descrever os requisitos, segundo Sommerville (2003, p.83), possvel classific-los como funcionais ou no funcionais ou requisitos de domnio: Requisitos funcionais para Sommerville (2003, p.83), so funes ou servios descritos que o sistema deve fornecer. Eles dependem do tipo de software, do tipo de sistema que est sendo desenvolvido e dos usurios. Os requisitos funcionais de sistema descrevem as funes detalhadamente, entradas, sadas e excees.

14

Requisitos no funcionais, conforme Sommerville (2003, p.83), so restries sobre as funes do sistema que limitam as opes para criar uma soluo para o problema. Eles podem estar relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espao em disco. A maioria dos requisitos no funcionais diz respeito ao sistema como um todo. Muitas vezes isso significa que eles so mais importantes do que os requisitos funcionais. A falha de cumprir um requisito funcional pode degradar um sistema, mas a falha de cumprir um requisito no funcional pode inutilizar o sistema. Requisitos de domnio, para Sommerville (2003, p.83), os requisitos de domnio no so obtidos a partir das necessidades dos usurios do sistema, eles so derivados do domnio da aplicao. Podem ser requisitos funcionais, podem restringir requisitos funcionais existentes ou estabelecer funes como realizar clculos especficos. Sabendo como identificar e classificar os requisitos em funcionais e no funcionais, o prximo passo organiz-los em um documento de requisitos de software.

1.1.4 Documentao de requisitos

O documento de requisitos de software ou especificao de requisitos de software, para Sommerville (2003, p.95), a declarao oficial do que exigido dos desenvolvedores de sistema. O documento de requisitos pode incluir tanto a definio como a especificao dos requisitos. A definio de requisitos para Pfleeger (2004, p.140), ou requisitos de usurio para Sommerville (2003, p.89), definido por ambos, como sendo a descrio dos requisitos funcionais e no funcionais do sistema, podendo ser escrito com o uso de linguagem natural, formulrio e diagramas, de modo que os usurios possam entender o que o sistema proposto faz, sem ter conhecimentos tcnicos detalhados. A especificao dos requisitos para Pfleeger (2004, p.141), ou requisitos do sistema para Sommerville (2003, p.91), para eles a viso tcnica do documento de requisitos do usurio, deve ser uma especificao completa e consistente de todo o sistema. Podem ser utilizados vrios modelos na especificao de requisitos, entre eles modelo de objetos ou de fluxo de dados. Em alguns casos um nico documento pode servir para descrever os requisitos de usurios e de sistema. Se houver um grande nmero de requisitos aconselhvel que a

15

definio e a especificao dos requisitos sejam apresentadas como documentos separados. Nesse caso necessrio haver uma correspondncia direta entre cada requisito, de modo que a viso do cliente esteja associada a do desenvolvedor. Antes que os requisitos sejam encaminhados para o projeto, os clientes e desenvolvedores devem ter a certeza de que conhecem a inteno e o entendimento uns dos outros, para ter esta certeza os requisitos devem ser validados.

1.1.5 Validao dos requisitos

A validao dos requisitos na definio de Pfleeger (2004, p.142), o processo que determina que a especificao consistente com a definio dos requisitos. Deve verificar se o conjunto total de requisitos exatamente aquilo que foi solicitado pelo cliente. A importncia da validao de requisitos para Sommerville (2003, p. 115), que o custo de fazer uma modificao no sistema, resultante de um problema de requisito, muito maior do que reparar erros de projeto ou codificao. Diferentes tipos de verificao devem ser realizados durante o processo de validao de requisitos. As verificaes so aplicadas sobre os requisitos no documento de requisitos. Segundo Sommerville (2003, p. 116), destacam-se os tipos de verificaes: Verificaes de validade; Verificaes de consistncia; Verificaes de completeza; Verificaes de realismo; Facilidade de verificao. Para a validao dos requisitos existe uma srie de tcnicas que podem ser utilizadas, desde tcnicas manuais como tcnicas automatizadas. Pfleeger (2004, p.142), apresenta algumas dessas tcnicas: 1. Tcnicas manuais a. Leitura; b. Referncia cruzada normal; c. Entrevistas; d. Revises;

16

e. Lista de verificao; f. Modelos manuais para verificar funes e relaes; g. Cenrios; h. Provas matemticas. 2. Tcnicas automatizadas a. Referncia cruzada automatizada; b. Modelos automatizados para ativar as funes; c. Prottipos. Uma maneira simples de validar requisitos revis-los , segundo Pfleeger (2004, p.142), um processo manual e envolve muitos leitores, tanto do pessoal do cliente como do fornecedor. Os conflitos, contradies, erros e omisses nos requisitos devem ser destacados durante a reviso e formalmente registrados.

2 CMMI - CAPABILITY MATURITY MODEL INTEGRATION

O CMM1 (Capability Maturity Model for software), ou em portugus Modelo de Maturidade da Capacitao para software tornou-se, ao longo do tempo um dos modelos de qualidade mais conhecido, usado e respeitado pela comunidade de engenharia de software. Para Fiorini (2001, p.3), o modelo CMM auxilia as organizaes a se aprimorarem continuamente na busca de uma soluo para os problemas inerentes ao desenvolvimento de software. O CMM conhecido pelo pblico mais propriamente chamado de Software-CMM (SW-CMM) ou CMM para software. Isto porque, no caminho de seu sucesso, diversos outros CMMs foram criados, procurando cobrir outras reas de interesse das organizaes. Assim surgiram os seguintes modelos: Software Acquisition CMM (SA-CMM); Systems Engineering CMM (SE-CMM); Integrated Product Development CMM (IPD-CMM); People CMM (P-CMM). Com o surgimento destes outros modelos, alguns problemas comearam a aparecer. Nem todos os modelos utilizavam a mesma terminologia, de modo que um conceito podia receber nomes diferentes em cada modelo. Alm disso, a estrutura carecia de um formato padro, os modelos tinham diferentes nmeros de nveis ou formas diferentes de avaliar o processo. Outro problema eram os altos custos de treinamento, avaliao e harmonizao para organizaes que tentassem usar mais de um modelo.

CMM and Capability Maturity Model so marcas registradas no U.S. Patent and Trademark Office. CMM Integration, CMMI, SCAMPI, and IDEAL so marcas de servio da Carnegie Mellon University.

18

Por outro lado, a experincia no uso do SW-CMM serviu para identificar pontos em que o modelo poderia ser melhorado e a necessidade de compatibilizar o CMM com a norma ISSO/IEC 155042. Por todas estas razes, o SEI iniciou um projeto chamado CMMI (CMM Integration) tendo como objetivo gerar uma nova verso do CMM buscando resolver essas diferenas, ou seja, integrando os diversos CMMs numa estrutura nica com mesma terminologia, mesmos processos de avaliao e tornado-o tambm compatvel com a norma ISO/IEC 15504, alm disso, incorporar ao CMMI as sugestes de melhoria surgidas ao longo dos anos.

2.1 Principais diferenas entre o CMMI e o SW-CMM

A principal mudana do CMMI em relao ao SW-CMM a possibilidade de utilizar duas abordagens diferentes para a melhoria de processos. Estas abordagens so conhecidas como o modelo contnuo e o modelo em estgios. O SW-CMM, como se sabe, um modelo em estgios, nele existem cinco nveis de maturidade e a organizao avaliada como estando em apenas um deles. Em cada nvel, a partir do nvel 2, existem as chamadas reas chave de processo. O SW-CMM possui 18 reas-chave, e cada uma situa-se em apenas um nvel. Assim, para uma organizao estar no nvel 2, necessrio que as 6 reas-chave deste nvel estejam institucionalizadas. Para estar no nvel 3, preciso cumprir as 6 reas no nvel 2 e mais as 7 reas do nvel 3, e assim por diante. Uma organizao no nvel 2 pode, por exemplo, possuir prticas do nvel 3, mas ser apenas do nvel 2, por no possuir o conjunto completo das reas-chave do nvel 3. Alguns dos outros CMMs citados, bem como a norma ISO/IEC 15504, usam uma abordagem diferente, o chamado modelo contnuo. Neste caso, cada rea-chave de processo possui caractersticas relativas a mais de um nvel. Assim, uma rea-chave que no modelo em estgios, pertence exclusivamente ao nvel 2, no modelo contnuo pode ter caractersticas que a coloquem em outros nveis.

Norma ISSO/IEC 15504, para avaliao de processos de software. Disponvel em <http://www.iso.ch>

19

2.2 O modelo CMMI

O modelo CMMI possui 4 (quatro) reas de conhecimento, conhecidas tambm como disciplinas, que auxiliam a organizao no planejamento da melhoria do processo. A organizao poder optar por selecionar uma ou mais disciplinas para iniciar este processo de melhoria. A seguir uma descrio destas disciplinas: (SEI TR-028, 2002, p.4) Engenharia de sistemas: Abrange o desenvolvimento de sistemas em geral, o qual pode ou no incluir um software; Engenharia de software: Abrange especificamente o desenvolvimento, manuteno e operao de software; Desenvolvimento de Produtos e Processo Integrado: um acompanhamento sistemtico e colaborativo do ciclo de vida do produto para satisfazer as expectativas e requisitos dos usurios; Aquisio: Esta disciplina abrange a aquisio de produtos de terceiros para executarem funes aos produtos do projeto. A implantao de uma ou mais dessas disciplinas ao mesmo tempo considerada uma grande vantagem do modelo CMMI, pois a empresa determina em quais disciplinas deseja melhorar seu processo. Essas disciplinas so compostas por reas de processo3, que quando executadas, determinam a melhoria do processo na disciplina escolhida. O modelo CMMI, ainda dividido em duas representaes, o modelo em estgio e o modelo contnuo. Como ocorre nas disciplinas, necessrio que a organizao opte por uma das representaes, sendo que esta escolha depender das necessidades que melhor convier. A seguir uma descrio destas representaes conforme o SEI TR-028 (2002, p.2): Representao em estgios: oferece uma seqncia de melhoramentos com prticas de gerenciamento e processos, alm de proporcionar uma migrao facilitada do SW-CMM para o modelo CMMI. Cada nvel (estgio) possui diversas reas de processos onde cada uma se encontra em um nico nvel; Representao contnua: oferece uma abordagem mais flexvel para a melhoria do processo, pois foi projetada para que organizaes escolham uma rea de processo ou um conjunto. Baseia-se tambm, na norma ISO/IEC 15504, possuindo 6 (seis)
rea de Processo um conjunto de prticas relacionadas em uma rea que quando executadas coletivamente satisfazem um conjunto de objetivos importantes para a melhoria significante daquela rea. (FIORINI, 2001, p.29)
3

20

nveis de maturidade, onde qualquer rea do processo pode ter sua maturidade avaliada em alguns desses nveis.

2.3 A estrutura do modelo CMMI

O modelo CMMI segundo o SEI TR-028 (2002, p.12), organizado pelas reas de processo, pois a maturidade do processo medida pela satisfao dos objetivos especficos e genricos de cada rea. As reas de processo so detalhadas pelas prticas especficas e pelas prticas genricas. Estas prticas, conforme o SEI TR-028 (2002, p.12), especificam o que deve ser cumprido, exigindo documentos, treinamentos ou polticas organizacionais para as atividades, porm no especificam como elas devem ser implementadas. Os objetivos especficos e genricos so satisfeitos pela execuo das prticas especficas e genricas das reas de processo. Os objetivos e as prticas esto inseridos em componentes dentro das reas de processo. De acordo com o SEI TR-028 (2002, p.13), estes componentes refletem como o modelo CMMI deve ser interpretado, sendo estes componentes separados em trs categorias: Componentes Requeridos: os objetivos especficos e genricos so os componentes requeridos do modelo. Eles descrevem o que uma organizao deve satisfazer para alcanar determinada rea de processo; Componentes Esperados: as prticas especficas e genricas so os componentes esperados do modelo. Estes componentes descrevem o que uma organizao dever implementar para satisfazer um componente requerido; Componentes Informativos: as sub-prticas, tpicos produtos de trabalho, elaborao de prticas genricas, motivos, notas introdutrias e as relaes entre as reas de processo so os componentes informativos do modelo. Estes componentes auxiliam as organizaes a entender os objetivos e prticas e como elas podem ser estabelecidas, fornecendo detalhes que ajudam a pensar em como estabelecer os componentes requeridos e esperados. A Figura 3, demonstra a estrutura dos componentes do modelo CMMI.

21

Fonte: ZANATTA (2004, p.12) adaptado de CHRISSIS. Figura 3 Componentes do Modelo CMMI

Quando se utiliza um modelo CMMI como guia, os processos so planejados e implementados de acordo com os componentes esperados e requeridos das reas de processo. Os objetivos especficos, prticas especficas e tpicos produtos de trabalho das reas de processo de Gerenciamento de Requisitos e Desenvolvimento de Requisitos sero os processos planejados e implementados no presente trabalho, por serem necessrios para o desenvolvimento da ferramenta phpRm. Porm os objetivos genricos, prticas genricas, subprticas e elaborao de prticas genricas destas duas reas de processo, no sero descritas, por serem decises a nvel gerencial da organizao ou serem meramente informativas.

22

2.4 Escolhendo a Representao

Segundo o SEI TR-028 (2002, p.2), trs fatores podem influenciar na deciso da escolha da representao a ser utilizada, so eles: Fatores de negcio: uma organizao que possua um mapeamento de seus processos e objetivos de negcio pode achar a representao contnua mais til para avaliar seus processos. Se a organizao est preocupada com a padronizao e com a publicao de resultados para obter um diferencial competitivo em relao aos seus concorrentes, ela deve preferir a representao em estgios. Fatores culturais: a representao contnua deve ser selecionada se a organizao possuir experincia no processo de melhoria ou se possuir um processo especfico que precise ser melhorado rapidamente. Se a organizao tiver pouca experincia no processo de melhoria deve optar pela representao em estgios, por fornecer uma orientao adicional sobre as mudanas que devem ocorrer. Legado: organizaes com cultura em sistemas de engenharia devem estar familiarizadas com a representao contnua, j as organizaes de software podem estar mais acostumadas com a representao em estgios. aconselhvel a organizao continuar com a representao que tiver mais experincia, pois ambas foram disponibilizadas para as organizaes obterem o sucesso na sua utilizao. Ainda conforme o SEI TR-028 (2002, p.2), uma organizao no forada a selecionar uma representao ou outra, podendo encontrar utilidade em ambas. Raramente as organizaes executam uma representao como definida pelo modelo, elas freqentemente definem um plano para focalizar seus problemas. O modelo na representao estgio no ser descrito no presente trabalho, pois a ferramenta phpRm ser baseada na representao do modelo contnuo, pois ela deve auxiliar uma organizao que necessite melhorar rapidamente os processos de gerenciamento e desenvolvimento de requisitos.

2.5 Representao Contnua

O modelo CMMI na representao contnua, conforme o SEI TR-028 (2002, p.11), foca a mensurao de melhoria de processos usando nveis de capacitao. Esses nveis de

23

so aplicados realizao de melhoria do processo atravs de reas de processos individuais, como por exemplo, Gerenciamento de Requisitos. Segundo Fiorini (2001, p.16), a capacitao do processo , o intervalo ou faixa de tolerncia dos resultados esperados, que podem ser alcanados seguindo um processo de software. De acordo com Zanatta (2004, p.14), o modelo CMMI na representao contnua tem 6 (seis) nveis de capacitao, descritos a seguir: Nvel 0: Incompleto processo executado ou executado parcialmente; Nvel 1: Executado satisfaz os objetivos especficos da rea de processo; Nvel 2: Gerenciado processo executado, planejado, monitorado e controlado para atingir um objetivo; Nvel 3: Definido processo gerenciado, adaptado de um conjunto de processos padro da organizao; Nvel 4: Gerenciado Quantitativamente processo definido, controlado utilizando estatsticas ou outras tcnicas quantitativas; Nvel 5: De Otimizao processo gerenciado quantitativamente para a melhoria contnua do desempenho do processo. Ainda conforme Zanatta (2004, p.14), diferentemente na representao em estgio, as reas de processo na representao contnua so independentes dos nveis de maturidade, ficando relacionadas apenas com a Capabilidade4 do processo, ou seja, uma determinada rea de processo poder ter sua capacidade avaliada independente das outras reas. A Figura 4, ilustra o modelo CMMI na representao contnua.

Fonte: http://www.sei.cmu.edu/cmmi. Figura 4 Representao do Modelo Contnuo O termo Capabilidade no existe no vocabulrio portugus, por esse motivo este termo ser substitudo por capacidade.
4

24

Cabe ressaltar que o nvel de capacidade acumulativo, ou seja, nenhuma rea de processo poder receber um nvel de capacidade superior sem ter alcanado o nvel inferior. A Figura 5, ilustra a representao contnua do modelo CMMI, onde objetivos especficos organizam as prticas especficas e os objetivos genricos organizam prticas genricas. Cada prtica genrica e especfica corresponde ao nvel de capacidade.

Fonte: SEI-TR028 (2002, p.12). Figura 5 Modelo CMMI na Representao Contnuo

No modelo CMMI na representao contnua, os nveis de capacidade fornecem uma recomendao para melhorar os processos dentro de cada rea de processo, possuindo a flexibilidade para determinar qual rea de processo ser abordada para a melhoria.

2.5.1 reas de Processo na Representao Contnua

As reas de processos de maneira semelhante ISO/IEC 122075, conforme descritos por Rocha, Maldonado e Webber (2001, p.10), so separadas em 4 (quatro) categorias. A seguir descritas conforme o SEI TR-028 (2002, p.58): Gerenciamento de Processo: contm atividades que so aplicadas entre os projetos para a definio, planejamento, desenvolvimento, implementao, monitorao, controle, avaliao, medidas e melhoria do processo.

Norma ISO/IEC 12207, terminologia para o ciclo de vida do processo de software. Disponvel em <http://www.iso.ch>

25

Gerenciamento de Projetos: gerenciam as atividades de projeto relacionadas ao planejamento, monitoria e controle do projeto. Engenharia: as reas de processo desta categoria envolvem atividades como de desenvolvimento e manuteno do produto de software; Apoio: essa categoria baseia-se principalmente no suporte as atividades de manuteno e desenvolvimento de produtos. importante ressaltar que na representao contnua as organizaes buscam

melhorar um determinado processo da organizao, seguindo sempre suas prioridades. A proposta deste trabalho visa buscar a melhoria dos processos de gerenciamento e desenvolvimento de requisitos. A seguir ser descrita a categoria da Engenharia onde so abordadas as reas de processo de Gerenciamento de Requisitos e Desenvolvimento de Requisito do modelo CMMI.

2.6 Categoria Engenharia

De acordo com o SEI TR-028 (2002, p.67), as reas de processo da Engenharia abrangem as atividades de desenvolvimento e manuteno do produto de software, que so compartilhadas entre as disciplinas da engenharia de sistemas e engenharia de software. As disciplinas da engenharia de sistemas e de software do modelo CMMI auxiliam uma organizao a planejar a melhoria dos processos de desenvolvimento e manuteno do produto de software. So seis as reas de processo que compem a Engenharia, conforme o SEI TR-28 (2002, p.67): Desenvolvimento de Requisitos (REQM); Gerenciamento de Requisitos (RD); Soluo Tcnica (TS); Integrao do Produto (PI); Verificao (VER); Validao (VAL). A Figura 6, fornece uma viso da interao entres as reas de processos da Engenharia e aps ser feita uma descrio desta interao.

26

Fonte: SEI TR-028 (2002, p.68). Figura 6 reas de processo da Engenharia

Como pode ser observado na Figura 6, o Gerenciamento de Requisitos controla todas as mudanas ocorridas nos requisitos, independentemente da rea de processo da Engenharia responsvel pela mudana. O Gerenciamento de Requisitos para o SEI TR-028 (2002, p.69), fundamental para controlar e organizar os processos da Engenharia. A rea de processo do Desenvolvimento de Requisitos de acordo com o SEI TR028 (2002, p.69), identifica as necessidades do cliente e s traduz em requisitos do produto. Esses requisitos so analisados para produzir uma soluo conceitual do produto. Aps analisar, os requisitos estaro disponveis para a Soluo Tcnica codific-los, ou seja, convert-los em componentes do produto. Os componentes do produto passaro para a Integrao de Produtos, onde sero unificados para formar o produto que ser entregue ao cliente. Os requisitos disponveis para a Soluo Tcnica sero analisados para definir as melhores alternativas de codific-los. Aps os requisitos serem convertidos em componentes do produto necessrio revis-los de acordo com as prticas especficas da Verificao. Os componentes do produto sero integrados para formar o produto de software, e este ser entregue ao cliente. Conforme o SEI TR-028 (2002, p.70), as prticas especficas da Integrao do Produto juntamente com a Verificao e a Validao iro garantir o

27

processo de como gerar as melhores possibilidades de integrao e entrega do produto de software ao cliente. Segundo o SEI TR-028 (2002, p.70), a rea de processo da Verificao assegura que o desenvolvimento do produto de software encontra-se dentro das exigncias especificadas no projeto. A rea do processo da Validao analisa se o produto est de acordo com as necessidades do cliente. As inconsistncias descobertas durante a Verificao e Validao so geralmente resolvidas nas reas de processo do Desenvolvimento de Requisitos ou Soluo Tcnica. A seguir ser apresentado detalhadamente, as reas de processos de Gerenciamento de Requisitos (REQM) e Desenvolvimento de Requisitos (RD), que sero implementadas na ferramenta phpRM, proposta deste trabalho.

2.7 Gerenciamento de Requisitos (REQM)

Conforme o SEI TR-028 (2002, p.323), o objetivo do gerenciamento de requisitos controlar os requisitos do sistema e identificar as inconsistncias entre os requisitos especificados e os requisitos desenvolvidos. O gerenciamento de requisitos para Sommerville (2003, p.118), o processo de compreender e controlar as mudanas nos requisitos do sistema. A rea de processo do Gerenciamento de Requisitos controla todos os requisitos recebidos ou gerados pelo projeto, incluindo os requisitos funcionais e no funcionais. A seguir ser descrito o objetivo especfico (SG) e suas prticas especficas (SP), que organizam esta rea de processo.

2.7.1 REQM SG 1 Gerenciamento dos Requisitos

Para o SEI TR-028 (2002, p.326), os requisitos so gerenciados para verificar as inconsistncias do projeto com o produto de software. O ciclo de vida do projeto mantm os requisitos atualizados e aprovados atravs das seguintes atividades: Gerenciar todas as mudanas dos requisitos; Manter o relacionamento entre os requisitos do projeto e do produto de software;

28

Identificar as inconsistncias entre os requisitos do projeto e do produto de software; Realizar as aes corretivas. As prticas especficas e seus tpicos produtos de trabalho necessrios para atender

este objetivo sero descritos a seguir.

2.7.1.1 REQM SP 1.1-1 Obter o Entendimento dos Requisitos

O objetivo desta prtica entender os propsitos dos requisitos juntamente com seus fornecedores. Estes requisitos devem ser analisados para assegurar que foram compreendidos. No decorrer do projeto novos requisitos so criados, aps obter o entendimento necessrio garantir que estes requisitos sejam atendidos pelo projeto, para isso devem ser estabelecidos critrios para distinguir estes requisitos. Para esta prtica so definidos os seguintes tpicos produtos de trabalhos: 1. Lista de critrios apropriados para distinguir os requisitos fornecidos; 2. Critrios para avaliar e aceitar os requisitos; 3. Anlise dos resultados conforme os critrios estabelecidos; 4. Elaborar um conjunto de requisitos aceitos.

2.7.1.2 REQM SP 1.2-2 Obter Comprometimento para os Requisitos

Tendo obtido o entendimento dos requisitos na prtica anterior deve-se agora chegar a um acordo com os fornecedores dos requisitos. O objetivo desta prtica

especfica, conforme o SEI TR-028 (2002, p.327), obter o comprometimento dos fornecedores de requisitos, e tambm um acordo entre os stakeholders6. Para obter esse comprometimento Sommerville e Sawyer (1999, p.38) propem que, o documento de requisitos a declarao oficial dos requisitos do sistema. Os clientes
6

Segundo Cordeiro, Stakeholder compreende o conjunto de pessoas que direta ou indiretamente so afetadas pelo sistema a ser construdo para a soluo de problemas. Tambm chamado por envolvidos no projeto, e consiste de: clientes, usurios, desenvolvedores, lder do projeto, responsvel do cliente, etc. (2002, p.62).

29

do sistema especificam os requisitos e estudam o documento para verificar se as expresses de suas necessidades esto aceitveis. Eles tambm usam o documento quando especificam mudanas para os requisitos. Os tpicos produtos de trabalhos definidos para esta prtica so os seguintes: 1. Avaliao do impacto dos requisitos; 2. Comprometimento na documentao dos requisitos e suas mudanas.

2.7.1.3 REQM SP 1.3-1 Gerenciar as Mudanas dos Requisitos

No decorrer do projeto as necessidades dos clientes mudam por vrias razes, ento novos requisitos so adicionados ao projeto ou ocorrem mudanas aos requisitos j existentes. Torna-se essencial gerenciar estas mudanas eficientemente e efetivamente. Para o SEI TR-028 (2002, p.328), necessrio documentar toda e qualquer mudana nos requisitos do projeto. Para Sommerville (2003, p.121), a vantagem de utilizar um processo formal de gerenciamento de mudanas que todas as mudanas so tratadas de forma consistente e que as mudanas no documento de requisitos so feitas de maneira controlada. Ainda conforme Sommerville, no processo de mudana h trs estgios principais: Anlise do problema e especificao da mudana; Anlise e custo da mudana; Implementao da mudana. Os tpicos produtos de trabalhos definidos para esta prtica so os seguintes: 1. Status dos requisitos; 2. Banco de dados dos requisitos; 3. Banco de dados para tomada de deciso dos requisitos.

2.7.1.4 REQM SP 1.4-2 Manter a Rastreabilidade Bidirecional dos Requisitos

O objetivo desta prtica especfica, de acordo com o SEI TR-028 (2002, p.329), manter a rastreabilidade bidirecional dos requisitos entre o projeto e o produto de software. Para Sommerville (2003, p. 120), a rastreabilidade uma propriedade da

30

especificao de requisito, que reflete a facilidade de um requisito encontrar seus requisitos relacionados. As informaes sobre a rastreabilidade dos requisitos e do projeto so tipos de informaes que podem ser mantidas com o uso de matrizes de rastreabilidade. As matrizes de rastreabilidade auxiliam a relao com os produtos intermedirios e finais, mudanas na documentao do projeto e planos de testes. Tambm necessria para analisar o impacto das mudanas nos requisitos. A seguir os tpicos produtos de trabalhos definidos para esta prtica: 1. Matriz de rastreabilidade dos requisitos; 2. Sistema de acompanhamento dos requisitos.

2.7.1.5 REQM SP 1.5-1 Identificar Inconsistncias entre o Projeto e os Requisitos

Esta prtica especfica verifica se existem inconsistncias dos requisitos entre o projeto e o produto de software. As inconsistncias encontradas devem ser documentadas e corrigidas. Os tpicos produtos de trabalhos definidos para esta prtica so: 1. Documentao das inconsistncias incluindo fontes, condies e lgica; 2. Aes corretivas. Estando as prticas especficas do Gerenciamento de Requisitos sendo executadas, pode-se dizer que a organizao obteve uma melhoria no processo para gerenciar os requisitos do projeto e do produto de software.

2.8 Desenvolvimento de Requisitos (RD)

O objetivo da rea de processo do Desenvolvimento de Requisitos , conforme o SEI TR-028 (2002, p.336), desenvolver e analisar os requisitos dos clientes, dos componentes do produto e do produto de software. Ainda segundo o SEI TR-028, os requisitos formam a base para qualquer projeto, para estes requisitos serem bem definidos esta rea de processo inclui as seguintes atividades:

31

Elicitar, analisar e validar as necessidades, expectativas e restries dos requisitos do cliente, visando o bom entendimento entre os stakeholders; Coletar e coordenar as necessidades dos stakeholders; Desenvolver o ciclo de vida dos requisitos do produto de software; Estabelecer os requisitos do cliente; Estabelecer que os requisitos iniciais do produto de software e seus componentes sejam consistentes com os requisitos do cliente. Esta rea de processo inclui fases do ciclo vida dos requisitos como elicitar,

analisar, validar e documentar os requisitos do cliente. Os 3 (trs) objetivos especficos (SG) e suas prticas especficas (SP) que organizam a rea de processo de Desenvolvimento dos Requisitos sero descrito a seguir.

2.8.1 RD SG 1 Desenvolver os Requisitos dos Clientes

As necessidades coletadas dos stakeholders so as bases para determinar os requisitos do cliente. Estas necessidades so analisadas e elaboradas para serem traduzidas em um documento de requisitos do cliente. Este documento de requisitos do cliente para Sommerville (2003, p.89), deve descrever os requisitos funcionais e no funcionais de modo compreensvel para o cliente. O documento de requisitos pode ser escrito em uma linguagem natural e com o auxlio de diagramas. Para satisfazer este objetivo especfico necessrio atender suas 3 (trs) prticas especficas descritas a seguir.

2.8.1.1 RD SP 1.1-1 Coletar as Necessidades dos Stakeholders

A atividade bsica desta prtica receber os requisitos fornecidos pelo cliente e definir o que ele necessita. A importncia de identificar e coletar estas necessidades para o SEI TR-028 (2002, p.341), que os requisitos sero utilizados em diferentes fases do ciclo de vida do produto de software. A coleta de requisitos de acordo com Sommerville (2003,

32

p.105), o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. No existem tpicos produtos de trabalho para esta prtica.

2.8.1.2 RD SP 1.1-2 Eliciar as Necessidades

Eliciar identificar requisitos implcitos fornecidos na prtica de onde as necessidades dos Stakeholders so coletadas. Sommerville (2003, p.46) prope tcnicas como: observao do sistema existente, reunies, anlise de tarefas, desenvolvimento de modelos e prottipos e use cases, para elicitar os requisitos do cliente. Para esta tambm no existem tpicos produtos de trabalho.

2.8.1.3 RD SP 1.2-1 Desenvolver os Requisitos do Cliente

Aps coletar e eliciar as necessidades do cliente preciso de documentar essas informaes. Para o SEI TR-028 (2002, p.342), os requisitos fornecidos pelo cliente devem ser consolidados, os que faltam devem ser obtidos e os conflitos devem ser resolvidos e documentados. Para esta prtica so definidos os seguintes tpicos produtos de trabalhos: 1. Requisitos do cliente; 2. Restries do cliente na conduo da verificao; 3. Restries do cliente na conduo da validao.

2.8.2 RD SG 2 Desenvolver os Requisitos dos Produtos

O objetivo especfico de Desenvolver os Requisitos do Produto, conforme o SEI TR-028 (2002, p.343), tem como atividade analisar os requisitos do cliente para elaborar requisitos mais detalhados e precisos, chamados de requisitos do produto. Estes requisitos devem ter uma especificao completa e consistente do produto de software

33

definindo o que ele deve fazer. Para Sommerville (2003, p.91), os requisitos de produto so descries mais detalhadas dos requisitos do cliente.

2.8.2.1 RD SP 2.1-1 Estabelecer os Requisitos do Produto e dos Componentes do Produto

Conforme o SEI TR-028 (2002, p.344), o objetivo desta prtica especificar em termos tcnicos os requisitos do cliente, gerando os requisitos do produto. Estes requisitos sero utilizados para tomar decises durante o desenvolvimento do projeto. Tambm necessrio manter um relacionamento entre os requisitos do cliente e os requisitos do produto, para possibilitar a verificao durante o gerenciamento de requisitos. Para Pfleeger (2004, p.141), a especificao dos requisitos a viso tcnica do documento de requisitos do cliente. Podem ser utilizados vrios modelos para especificar os requisitos do produto, entre eles o modelo de fluxo de dados7. Os tpicos produtos de trabalhos definidos para esta prtica so: 1. Requisitos derivados; 2. Requisitos do produto; 3. Requisitos dos componentes do produto.

2.8.2.2 RD SP 2.2-1 Alocar os Requisitos dos Componentes do Produto

Segundo o SEI TR-028 (2002, p.345), os requisitos do produto de software definidos na prtica especfica anterior devem ser alocados para os componentes do produto. Quando um requisito do produto de software alocado a um ou mais componentes do produto passa a existir um relacionamento entre eles, e este relacionamento deve ser documentado. Por exemplo, um produto de software para controle de estoque, este produto est dividido em trs mdulos: entradas, controle do estoque e sadas. Os requisitos do produto que fazem parte das entradas devem ser alocados a ela, e assim deve ocorrer para os outros. Se um requisito afeta todo produto de software, este deve ser alocado a todos os mdulos.
7

Modela o processamento de dados realizado por um sistema.

34

A seguir os tpicos produtos de trabalhos definidos para esta prtica: 1. Planilhas com alocao dos requisitos; 2. Alocao dos requisitos temporrios; 3. Projeto das restries; 4. Requisitos derivados; 5. Relacionamento entre os requisitos derivados.

2.8.2.3 RD SP 2.3-1 Identificar os Requisitos de Interface

O produto de software composto por componentes do produto, que so desenvolvidos independentemente. Estes componentes do produto interagem entre si, e conforme o SEI TR-028 (2002, p.346), o objetivo identificar os requisitos de interface para que os componentes do produto possam ser desenvolvidos independentemente. De acordo com Sommerville (2003, p.166), especificaes precisas dos requisitos de interface so importantes porque os desenvolvedores de componentes do produto devem escrever o cdigo que utilize os servios de outros componentes do produto, antes que estes sejam implementados. Para esta prtica o tpico produto de trabalho definido o seguinte: 1. Requisitos de interface.

2.8.3 RD SG 3 Analisar e Validar os Requisitos

As prticas especficas desse objetivo abrangem a anlise e a validao dos requisitos para definir se o produto de software est conforme o cliente pretende. Elas tambm do um suporte para os objetivos especficos do desenvolvimento de requisitos do cliente e do produto, analisando e validando os requisitos por eles produzidos. De acordo com SEI TR-028 (2002, p.347), o objetivo da anlise determinar os requisitos candidatos que iro atender as necessidades dos stakeholders. J o objetivo da validao aumentar a probabilidade de que o produto de software atenda as necessidades do cliente.

35

2.8.3.1 RD SP 3.1-1 Estabelecer Conceitos Operacionais e Cenrios

Segundo o SEI TR-028 (2002, p.348), um cenrio uma srie de eventos que ocorrerem no uso do produto de software, usado para tornar explcito algumas necessidades dos stakeholders. O conceito operacional para um produto depende geralmente da soluo do projeto e do cenrio. Da mesma forma em que uma deciso do projeto pode se transformar em um requisito para os componentes do produto, o conceito operacional pode se transformar em cenrios para os componentes do produto. Por exemplo, o conceito operacional de um satlite baseado em comunicaes diferente de um baseado em meteorologia. Conforme Sommerville (2003, p.111), as pessoas geralmente compreendem mais facilmente exemplos da vida real do que descries abstratas. Elas podem compreender e criticar um cenrio como se estivessem interagindo com o produto de software. Essa interao com o cenrio pode ser utilizada para obter os requisitos do produto de software. Os tpicos produtos de trabalhos definidos para esta prtica so: 1. Conceitos operacionais; 2. Conceitos de instalao de produtos, operao manuteno e suporte; 3. Conceitos de distribuio; 4. Casos de uso; 5. Timeline8 dos cenrios; 6. Requisitos novos.

2.8.3.2 RD SP 3.2-1 Estabelecer uma Definio da Funcionalidade Requerida

Segundo o SEI TR-028 (2002, p.349), a definio da funcionalidade, tambm conhecida como anlise funcional, a descrio do que o produto de software se destina a fazer. A anlise funcional utiliza os cenrios estabelecidos na prtica anterior que fornecem aes, seqncias, entradas e sadas para definir como o produto ser utilizado. A seguir os tpicos produtos de trabalhos definidos para esta prtica: 1. Arquitetura funcional; 2. Diagrama de atividades e use cases;
8

Descrio do desenvolvimento dos acontecimentos em ordem de execuo.

36

3. Anlise orientada a objeto com servios identificados.

2.8.3.3 RD SP 3.3-1 Analisar os Requisitos

Para o SEI TR-028 (2002, p.350), analisar os requisitos para assegurar que eles so necessrios e suficientes. Os requisitos do produto de software so analisados de acordo com o que foi definido na anlise funcional (prtica anterior) para determinar se so necessrios e suficientes. Os tpicos produtos de trabalhos definidos para esta prtica so: 1. Relatrio dos defeitos dos requisitos; 2. Propor mudanas nos requisitos para resolver os defeitos; 3. Requisitos chaves; 4. Medidas tcnicas de desempenho.

2.8.3.4 RD SP 3.4-3 Analisar os Requisitos para Alcanar o Equilbrio

Conforme o SEI TR-028 (2002, p.351), analisar os riscos nos requisitos do produto de software e avaliar o impacto no ciclo de vida do produto de software. Os riscos devem ser analisados e priorizados, os mais importantes devem ser considerados durante o projeto. De acordo com Sommerville (2003, p.73), os riscos considerados decisivos e os riscos srios devem sempre ser considerados. Para esta prtica o tpico produto de trabalho definido o seguinte: 1. Avaliar os riscos relatados nos requisitos.

2.8.3.5 RD SP 3.5-1 Validar os Requisitos

De acordo com o SEI TR-028 (2002, p.352), validar os requisitos para assegurar que o produto de software esteja de acordo com o esperado pelo cliente. Conforme descrito anteriormente neste estudo, validar revisar os requisitos para verificar se eles esto de acordo com o que foi solicitado pelo cliente. Esta atividade deve ser integrada com o

37

gerenciamento de riscos para determinar os riscos resultantes caso o produto de software no esteja de acordo com o esperado pelo cliente. Para esta prtica o tpico produto de trabalho definido o seguinte: 1. Validao dos resultados dos requisitos.

2.8.3.6 RD SP 3.5-2 Validar os Requisitos com Mtodos Vlidos

Para o SEI TR-028 (2002, p.352), validar os requisitos para assegurar que o resultado do produto esteja de acordo com o esperado pelo cliente, utilizando mltiplas tcnicas apropriadas. As organizaes devem executar a validao dos requisitos com tcnicas de simulaes ou prottipos para assegurar que os requisitos iro satisfazer as necessidades dos stakeholders. Esta atividade tambm deve ser integrada com o gerenciamento de riscos para determinar os riscos resultantes caso o produto de software no esteja de acordo com o esperado pelo cliente. Para esta prtica o tpico produto de trabalho definido o seguinte: 1. Registrar os mtodos de anlise e os resultados.

3 A FERRAMENTA PHPRM

A ferramenta phpRm foi elaborada por Gampert (2003), inicialmente para apoiar no processo de gerenciamento de requisitos baseado no modelo CMM. Como apontado por Gampert (2003, p.83), a ferramenta phpRm no atingiu todos os objetivos da rea chave do processo Gerenciamento de Requisitos do nvel 2 do CMM. Para atender as deficincias apontadas por Gampert (2003, p.83), foi proposto para este trabalho a adaptao da ferramenta phpRm para auxiliar na melhoria do processo de gerenciamento e desenvolvimento de requisitos baseando-se no modelo CMMI. Objetivando adicionar ou modificar as funcionalidades da ferramenta phpRm para atender as prticas especficas das reas de processo de Gerenciamento de Requisitos e Desenvolvimento de Requisitos do modelo CMMI. Como apresentado na Figura 7, as duas reas de processo tratam o ciclo de vida dos requisitos, sendo que Gampert (2003) em seu trabalho focou a documentao e o gerenciamento dos requisitos.

39

Fonte: Adaptada de Gampert (2003) Figura 7 Ciclo de vida dos requisitos

As funcionalidades da ferramenta phpRm que auxiliam estes processos so as seguintes: Identificao de projetos; Identificao dos stakeholders do projeto; Documento de viso; Documento de requisitos; Gerenciamento da mudana de requisitos; Componentes do produto; Checklist para os requisitos; Glossrio; Referncia a documentos externos; Agrupamento de requisitos em baselines9; Matriz de rastreabilidade dos requisitos; Documento de riscos nos requisitos. Dos recursos acima citados e disponveis na ferramenta phpRm, alguns no atendem completamente as prticas especficas, como por exemplo, a matriz de rastreabilidade. Tambm foram mantidas e atualizadas algumas funcionalidades da ferramenta phpRm no solicitadas pelas prticas especficas estudadas, por serem definidas
Segundo Gampert (2003, p.52), baseline um conjunto de requisitos aprovados e revisados que representam o embasamento de um acordo de desenvolvimento.
9

40

no modelo de Gerenciamento de Requisitos definido por Gampert (2003, p.48). Um exemplo disso o Documento de Viso. Algumas prticas especficas das reas de processo REQM e RD no foram incorporadas na ferramenta phpRm por requisitarem um planejamento definido pela organizao. Por exemplo, a SP 1.1-2 Eliciar as necessidades, da rea de processo RD. A tecnologia utilizada para desenvolver as funcionalidades requeridas pelas prticas especficas do REQM e RD da ferramenta foi software livre, como o HTML10 e o PHP11 para desenvolver a interface do usurio e para armazenar os dados o banco de dados MySQL12. Sua estrutura permite que os stakeholders de um projeto tenham acesso e percebam somente a funcionalidade que combina com a sua responsabilidade. Para isto, foi utilizado o conceito de usurios e grupos. Cada grupo possui um determinado conjunto de permisses de acesso, e estas so herdadas pelo usurio quando vinculado a um grupo. No momento em que um usurio acessa a ferramenta disponibilizado um menu contendo somente suas permisses de acesso. A ferramenta est dividida em quatro regies, como demonstra a Figura 8:

HTML (acrnimo para Hypertext Markup Language) significa Linguagem de Marcao de Hipertexto. Uma linguagem de marcao serve para indicarmos formataes para textos, inserir imagens e ligaes de hipertexto. 11 PHP (acrnimo para Hypertext Preprocessor) uma linguagem de script que foi projetada para desenvolvimento Web e pode ser embutida no HTML (PHP, 2003). 12 MySQL o banco de dados popular do mundo na categoria de software livre, reconhecido pela sua velocidade e confiabilidade (MYSQL, 2003).

10

41

Fonte: adaptada de Gampert (2003, p.58). Figura 8 - Tela principal da ferramenta phpRm

Sua utilizao no depende de nenhuma configurao adicional, basta um computador com sistema operacional que possua ambiente grfico, conectado em rede e um navegador Web que suporte Javascript13.

3.1 Anlise das Funcionalidades da Ferramenta phpRm

A seguir sero analisadas as funcionalidades para determinar qual foi o ndice de mudanas necessrias para adaptar a ferramenta phpRm as reas de processo REQM e RD do modelo CMMI.

Javascript a primeira linguagem de script desenvolvida para a Web. Ela roda no prprio navegador que est acessando a pgina.

13

42

3.1.1 Identificao de projetos

Esta funcionalidade tem como objetivo armazenar os projetos a serem gerenciados. A ferramenta phpRm j possua esta funcionalidade e no houve a necessidade de modific-la.

3.1.2 Identificao dos stakeholders do projeto

A funcionalidade para identificar e vincular os stakeholders do projeto j estava disponvel na ferramenta phpRm e no foi modificada.

3.1.3 Checklist para os requisitos

O objetivo desta funcionalidade armazenar os checklists que sero aplicados sobre os requisitos. Foi necessrio modific-la, pois no havia a possibilidade de vincular e nem armazenar os resultados da aplicao dos checklists nos requisitos.

3.1.4 Documento de viso

O documento de viso demonstra a essncia do produto de software, descrevendo os problemas e as necessidades dos usurios, as responsabilidades dos envolvidos no projeto, os recursos que sero implementados e as restries impostas ao produto de software. O documento de viso foi reestruturado, conforme Anexo A e Anexo B, de forma que as descries contidas no modelo anterior deste documento fossem desassociadas para formar uma estrutura mais consistente e melhor atender o modelo de gerenciamento de requisitos proposto Gampert (2003, p.48).

43

3.1.5 Relatrio do documento de viso

O relatrio possibilita a impresso da ltima reviso do documento de viso. Este relatrio foi desenvolvido para servir como uma proposta do produto de software, de acordo com o Anexo A e Anexo B.

3.1.6 Glossrio do projeto

O glossrio armazena os termos utilizados pelo domnio da aplicao e pelos stakeholders. Este recurso j estava disponvel e no foi necessrio modific-lo.

3.1.7 Referncias a documentos externos

Esta funcionalidade de referenciar fontes externas, como relatrios, manuais, livros, e-mails, etc., foi adicionada, pois segundo Gampert (2003, p.83), a ferramenta phpRm deveria implementar a possibilidade de fazer referncias a documentos externos.

3.1.8 Identificao individualizada de requisitos

O objetivo desta funcionalidade armazenar os requisitos candidatos do projeto. Este cadastro do documento de requisitos foi reestruturado de forma que as informaes do modelo anterior deste documento fossem desassociadas para formar uma estrutura mais consistente e melhor atender o modelo de gerenciamento de requisitos proposto Gampert (2003, p.48). O novo modelo do documento de requisitos apresentado no Anexo C.

44

3.1.9 Documento de requisitos

Esta funcionalidade possibilita a impresso da ltima reviso do documento de requisito. Este relatrio foi desenvolvido para servir juntamente com o documento de viso como uma proposta do produto de software, conforme apresentado no Anexo C.

3.1.10 Histrico das mudanas nos requisitos

O histrico armazena toda e qualquer mudana que ocorra no documento de requisitos. Esta funcionalidade foi adicionada para que fosse possvel gerenciar as mudanas ocorridas nos requisitos.

3.1.11 Relacionar os requisitos dependentes

O objetivo desta funcionalidade vincular os requisitos dependentes de outros requisitos. Esta funcionalidade foi modificada, pois a relao entre os requisitos no existia. No Anexo R, esta relao pode ser observada.

3.1.12 Identificao dos componentes do produto

A identificao dos componentes do produto define os mdulos que iro compor o produto de software. Esta funcionalidade foi incorporada para possibilitar que os requisitos fossem rastreados com o produto de software.

45

3.1.13 Relacionar os requisitos aos componentes do produto

O objetivo desta funcionalidade relacionar os requisitos aos os componentes do produto. Ela foi incorporada para que fosse possvel gerar a matriz de rastreabilidade dos requisitos, como apresentado no Anexo R.

3.1.14 Inconsistncias entre os componentes do produto e os requisitos

Esta funcionalidade possibilita que sejam armazenadas as inconsistncias e as aes corretivas tomadas para solucionar estas incoerncias. Foi adicionado na ferramenta phpRm, uma funcionalidade que armazena estas inconsistncias e as aes corretivas encontradas entre os requisitos e componentes do produto para manter um histrico dos problemas no projeto.

3.1.15 Agrupamento de requisitos em baselines

As baselines armazenam os requisitos que foram incorporados ao produto de software. A ferramenta phpRm j possua esta funcionalidade, mas foi alterada para modificar o estado do requisito quando o mesmo fosse adicionado ou removido de uma baseline.

3.1.16 Matriz de rastreabilidade dos requisitos

A matriz de rastreabilidade possibilita verificar as dependncias dos requisitos. Esta funcionalidade foi adicionada a ferramenta phpRm para auxiliar na anlise de impacto que uma mudana possa ocasionar. No Anexo R, a matriz de rastreabilidade pode ser verificada.

46

3.1.17 Relatrio de riscos nos requisitos

Este relatrio auxilia os engenheiros de software a avaliar os riscos dos requisitos, pois apresenta todas as propriedades definidas no documento de requisitos e o nmero de mudanas ocorridas. O relatrio de riscos foi incorporado as funcionalidades da ferramenta phpRm para auxiliar na anlise de impacto de uma mudana e tambm na definio das baselines do produto de software.

3.2 Resultados da Anlise das Funcionalidades

A Figura 9, demonstra o resultado da anlise das funcionalidades da ferramenta phpRm para adapt-la as reas de processo REQM e RD do modelo CMMI. As funcionalidades analisadas foram graduadas para verificar as alteraes necessrias, graduao essa que apresentada a seguir: No Modificada: no houve nenhuma alterao na ferramenta phpRm em relao ao modelo CMMI; Modificada: houve alteraes na ferramenta phpRm para se adaptar ao modelo CMMI. Nova: funcionalidades que no existiam na ferramenta phpRm, mas eram necessrias para atender as prticas especfica do REQM e RD.

47

Funcionalidade Identificao de projetos Identificao dos stakeholders do projeto Checklist para os requisitos Documento de viso Relatrio do documento de viso Glossrio do projeto Referncias a documentos externos Identificao individualizada de requisitos Documento de requisitos Histrico das mudanas de requisitos Relacionar os requisitos dependentes Identificao dos componentes do produto Relacionar os requisitos aos componentes do produto Inconsistncias entre os componentes do produto e os requisitos Agrupamento de requisitos em baselines Matriz de rastreabilidade dos requisitos Relatrio de riscos nos requisitos
Fonte: Primria.

No Modificada Modificada X X X X X

Nova

X X X X X X X X X X X X

Figura 9 Resultado da anlise das funcionalidades da ferramenta phpRm

A Figura 9 foi representada graficamente na Figura 10, para verificar o percentual modificado na ferramenta phpRm para atender as reas de processo REQM e RD do modelo CMMI.

18%

No Modificada

Modificada 53% 29% Nova

Fonte: Primria. Figura 10 Grfico da anlise das funcionalidades da ferramenta phpRm

48

A Figura 10 mostra que para adaptar a ferramenta phpRm as reas de processo REQM e RD do modelo CMMI foi preciso adicionar um maior nmero de novas funcionalidades do que modificar as j existentes. Cabe ressaltar que no foram avaliadas as funcionalidades de controle de acesso dos usurios e outras funes que fornecem a base da ferramenta.

4 ANLISE DA FERRAMENTA PHPRM

As prticas especficas das reas de processo REQM e RD do modelo CMMI foram estudadas e analisadas para verificar o que seria necessrio alterar na ferramenta para atender estas prticas especficas. Tendo essas alteraes concludas, a ferramenta phpRm foi submetida a uma anlise para verificar os objetivos das prticas especficas do REQM e RD que ela atendeu e o nvel de capacidade do processo que pode ser atingido com sua utilizao.

4.1 Anlise da rea de processo REQM

A seguir ser apresentada a anlise da ferramenta com relao s diversas prticas especficas da rea de processo REQM.

4.1.1 REQM SP 1.1-1 Obter o entendimento dos requisitos

De acordo com o objetivo desta prtica especfica, uma lista de critrios deve ser aplicada para distinguir, avaliar e aceitar os requisitos fornecidos pelo cliente. A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois armazena os resultados dos checklist aplicados nos requisitos. Estes checklist foram elaborados pelo engenheiro de software estabelecendo critrios apropriados para distinguir, avaliar e aceitar os requisitos

50

fornecidos pelos stakeholders. Na Figura 11, o checklist chamado Entendimento do Requisito foi definido para auxiliar na verificao e validao dos requisitos do projeto.

Fonte: Primria. Figura 11 Checklist dos requisitos

4.1.2 REQM SP 1.2-2 Obter o comprometimento para os requisitos

Conforme o objetivo desta prtica especfica, o documento de requisitos servir para obter um acordo entre os stakeholders, compromet-los com os requisitos solicitados e quando os requisitos sofrerem alguma mudana. O objetivo desta prtica especfica foi atendido pela ferramenta phpRm, pois com os documentos de requisitos foi possvel obter o comprometimento dos stakeholders. Estes documentos foram gerados a partir dos requisitos desenvolvidos pelo engenheiro de software e cadastrados na ferramenta phpRm. Um destes documentos de requisitos pode ser encontrado no Anexo C.

51

4.1.3 REQM SP 1.3-1 Gerenciar as mudanas dos requisitos

Para atender o objetivo desta prtica especfica necessrio documentar os requisitos do projeto ou quaisquer mudanas que neles ocorrerem em um banco de dados. A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois todos os requisitos do projeto foram documentados no banco de dados da ferramenta e tambm qualquer mudana que neles possam ocorrer, mantendo assim um histrico dos requisitos. Quando uma mudana ocorre no documento de requisitos uma nova reviso deste gerada, como demonstra o Anexo C.

4.1.4 REQM SP 1.4-2 Manter a rastreabilidade bidirecional dos requisitos

Segundo o objetivo desta prtica especfica, manter a rastreabilidade bidirecional dos requisitos e fornecer um sistema de acompanhamento para facilitar na visualizao da origem dos requisitos, dos requisitos relacionados e dos componentes do produto a qual os requisitos fazem parte. O objetivo desta prtica especfica no foi atendido completamente pela ferramenta phpRm, pois o sistema de acompanhamento dos requisitos, ou seja, a matriz de rastreabilidade gerada pela ferramenta, no est completamente de acordo com esta prtica especfica por no possibilitar o acompanhamento bidirecional dos requisitos. A ferramenta phpRm possibilitou que os requisitos fossem rastreados da origem para seus dependentes, porm no de um dependente at a origem. Como demonstrado no Anexo R. Para atender por completo esta prtica especfica necessrio executar uma busca nos requisitos dependentes e relacion-los com seus requisitos pais, possibilitando desta maneira gerar a matriz de rastreabilidade bidirecional.

4.1.5 REQM SP 1.5-1 Identificar inconsistncias entre o projeto e os requisitos

Para o objetivo desta prtica especfica, as inconsistncias encontradas entre o projeto e o produto de software devem ser corrigidas. As inconsistncias e as aes corretivas devem ser documentadas.

52

A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois as inconsistncias encontradas entre os requisitos e os componentes do produto e suas aes corretivas foram documentadas, como pode ser observado na Figura 12.

Fonte: Primria Figura 12 - Inconsistncia entre os requisitos e os componentes do produto

4.2 Anlise da rea de processo RD

A seguir ser apresentada a anlise da ferramenta com relao s diversas prticas especficas da rea de processo RD.

4.2.1 RD SP 1.1-1 Coletar as necessidades dos stakeholders

O objetivo desta prtica especfica identificar e coletar os requisitos fornecidos pelo cliente e definir o que ele realmente necessita. A ferramenta phpRm no atendeu a esta prtica especfica, pois segundo Sommerville (2003, p.105), coletar os requisitos interagir com os stakeholders para descobrir suas necessidades. Portanto compete a organizao institucionalizar tcnicas para coletar os requisitos do cliente.

53

Fica como sugesto para a organizao a adoo de reunies, entrevistas e questionrios para coletar as necessidades dos stakeholders.

4.2.2 RD SP 1.1-2 Eliciar as necessidades

Conforme o objetivo desta prtica especfica, os requisitos implcitos devem ser identificados. O objetivo desta prtica especfica no foi atendido pela ferramenta phpRm, pois Sommerville (2003, p.46) prope tcnicas para eliciar os requisitos dos stakeholders. Portando compete organizao adotar solues para identificar os requisitos implcitos. A sugesto proposta a ser institucionalizada pela organizao para atender o objetivo desta prtica especfica adotar tcnicas de obvervao do sistema existente, anlise de tarefas e reunies.

4.2.3 RD SP 1.2-1 Desenvolver os requisitos do cliente

Segundo o objetivo desta prtica especfica, aps coletar e eliciar as necessidades do cliente necessrio documentar essas informaes juntamente com as restries dos clientes na conduo da verificao e validao dos requisitos. A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois os requisitos e as restries do cliente foram documentados. O documento de requisitos pode ser verificado no Anexo C, suas restries foram documentadas no item restries/excees do referido anexo.

4.2.4 RD SP 2.1-1 Estabelecer os requisitos do produto e dos componentes do produto

De acordo com o objetivo desta prtica especfica, os requisitos do produto devem ser diferenciados dos requisitos do cliente. necessrio tambm manter uma relao entre requisitos do cliente e os requisitos do produto. A ferramenta phpRm atendeu esta prtica especfica, pois os requisitos do produto foram diferenciados pela propriedade estado do documento de requisito. Aps adicionar os

54

requisitos a uma baseline, como representa a Figura 13, eles passaram do estado de Aprovado para Incorporado. Portanto estes que eram requisitos do cliente passaram a ser tambm requisitos do produto.

Fonte: Primria Figura 13 - Requisitos da baseline

4.2.5 RD SP 2.2-1 Alocar os requisitos dos componentes do produto

Conforme o objetivo desta prtica especfica, os requisitos devem ser alocados aos componentes do produto e uma planilha de alocao deve ser gerada para o acompanhamento destes requisitos. O objetivo desta prtica especfica foi atendido pela ferramenta phpRm, pois os requisitos foram relacionados aos componentes do produto e a planilha de alocao dos requisitos foi representada pela matriz de rastreabilidade. Essa representao pode ser verificada na segunda tabela da matriz de rastreabilidade no Anexo R.

4.2.6 RD SP 2.3-1 Identificar os requisitos de interface

Segundo o objetivo desta SP, os requisitos de interface devem ser identificados para que os componentes do produto possam ser desenvolvidos independentemente. Isto para que os desenvolvedores possam escrever cdigos utilizando dados, funes ou procedimentos de outros componentes que ainda no estejam implementados. A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois foi possvel

55

documentar e identificar os requisitos de interface. No Anexo C, a propriedade tipo do requisito no documento de requisitos diferencia os requisitos do cliente dos requisitos de interface.

4.2.7 RD SP 3.1-1 Estabelecer conceitos operacionais e cenrios

De acordo com o objetivo desta prtica especfica, os cenrios devem ser estabelecidos para representar os eventos que ocorrem no produto de software e fazer com que os stakeholders compreendam e critiquem os cenrios como se estivessem interagindo com o produto de software. O objetivo desta prtica especfica no foi atendido pela ferramenta phpRm, pois compete a organizao adotar solues para estabelecer cenrios como forma de representar o produto de software. Fica como sugesto a adoo de casos de uso, de acordo com Sommerville (2003, p.111), o cliente pode compreender e criticar os casos de uso como se estivessem interagindo com o produto de software.

4.2.8 RD SP 3.2-1 Estabelecer uma definio da funcionalidade requerida

O objetivo desta prtica especfica definir o que o produto de software se destina a fazer. Os cenrios fornecem as aes, seqncias, entradas e sadas que definem a funcionalidade do produto de software. A ferramenta phpRm no atende a esta prtica especfica, pois compete a organizao institucionalizar uma soluo para definir a funcionalidade do produto de software. A soluo proposta conforme o SEI TR-028 (2002, p.349), para atender esta prtica especfica, adotar tcnicas da modelagem orientada a objetos como diagramas de atividades e casos de uso.

4.2.9 RD SP 3.3-1 Analisar os requisitos

Conforme o objetivo desta prtica especfica, os requisitos devem ser analisados de acordo com os diagramas de atividades para verificar se atendem as exigncias do cliente.

56

Esta prtica especfica no foi atendida pela ferramenta phpRm, pois compete a organizao institucionalizar o processo de analisar os requisitos de acordo com o que est definido nos diagramas de atividades.

4.2.10 RD SP 3.4-3 Analisar os requisitos para alcanar o equilbrio

De acordo com o objetivo desta prtica especfica, os riscos nos requisitos devem ser analisados e priorizados. Os requisitos considerados de risco devem ser observados durante o projeto. A ferramenta no atendeu esta prtica especfica, ela apenas subsidia dados dos requisitos para os engenheiros de software analisarem e determinarem quais os requisitos considerados perigosos devem ser monitorados durante o projeto.

4.2.11 RD SP 3.5-1 Validar os requisitos

Segundo o objetivo desta prtica especfica, os requisitos devem ser validados para assegurar que o produto de software esteja de acordo com o esperado pelo cliente. A ferramenta phpRm atendeu o objetivo desta prtica especfica, pois foram aplicados nos requisitos o checklist para executar o processo de validao. Como visto anteriormente na Figura 11.

4.2.12 RD SP 3.5-2 Validar os requisitos com mtodos vlidos

Para o objetivo desta prtica especfica, os requisitos devem ser validados com a utilizao de tcnicas apropriadas para assegurar que o resultado do produto seja o esperado pelo cliente. O objetivo desta prtica especfica no atendido pela ferramenta, pois cabe a organizao adotar mtodos para validar os requisitos. Fica como sugesto, segundo Pfleeger (2004, p.142), a utilizao de prottipos como mtodo para validar se os requisitos esto de acordo com as necessidades do cliente.

57

4.3 Anlise dos Resultados

A Figura 14, demonstra o resultado da anlise executada sobre a ferramenta phpRm. Esse resultado estabelece se as prticas especficas do REQM e RD foram atendidas, parcialmente atendidas, no atendidas ou se no compete a ferramenta atender a prtica especfica. Para quantificar este resultado buscou-se graduar estas prticas especficas, conforme apresentado a seguir: Atendida: a ferramenta phpRm atendeu o objetivo da prtica especfica em questo; Parcialmente Atendida: a ferramenta phpRm atendeu em partes o objetivo da prtica especfica, ou seja, algum tpico produto de trabalho da prtica especfica no foi atendido; No Atendida: a ferramenta phpRm no atendeu o objetivo da prtica especfica em questo. No Compete: a prtica especfica para ser atendida necessita de polticas organizacionais.

Prtica Especfica REQM SP 1.1-1 REQM SP 1.2-2 REQM SP 1.3-1 REQM SP 1.4-2 REQM SP 1.5-1 RD SP 1.1-1 RD SP 1.1-2 RD SP 1.2-1 RD SP 2.1-1 RD SP 2.2-1 RD SP 2.3-1 RD SP 3.1-1 RD SP 3.2-1 RD SP 3.3-1 RD SP 3.4-3 RD SP 3.5-1 RD SP 3.5-2
Fonte: Primria.

Atendida X X X

Atendida Parcialmente

No Atendida

No Compete

X X X X X X X X X X X X X X

Figura 14 Resultado da anlise da ferramenta phpRm

58

Os dados obtido a partir da Figura 14, foram representados graficamente para verificar o percentual atendido pela ferramenta phpRm nas reas de processo REQM e RD do modelo CMMI. A Figura 15, indica que mais da metade das prticas especficas foram atendidas.

A tendida A tendida Parcialmente 35% No A tendida No Compete

53% 6%

6%

Fonte: Primria. Figura 15 Percentual atendido pela ferramenta

O grfico representado na Figura 16, mostra que a ferramenta phpRm atendeu 80% da rea de processo REQM, faltando atender somente 20% para atingir completamente o nvel 2 de capacitao dessa rea de processo. Sendo que estes 20% so representados por uma prtica especfica parcialmente atendida. Da rea de processo RD, a ferramenta atendeu 83% das prticas especficas a ela destinadas, sendo que ao satisfazer os objetivos desta rea de processo a capacidade atingida ser de nvel 3. Mas pode-se dizer que com a utilizao da ferramenta phpRm e a definio das polticas organizacionais cabveis a cada prtica especfica, a capacidade do processo ser de nvel 2. Porm no ser possvel atingir o nvel 3, pois a ferramenta no dispe de um mecanismo para analisar os riscos nos requisitos.

59

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% REQM RD

Fonte: Primria. Figura 16 Percentual atendido para cada rea de processo

Cabe ressaltar que na Figura 16, no foram includas no grfico as prticas especficas que no competem a ferramenta. Das prticas especficas que foram atendidas pela ferramenta, todas necessitam das habilidades dos stakeholders para que o projeto e o produto de software obtenham sucesso. Seja qual for a soluo implantada, se no executada devidamente e por pessoas capacitadas provvel que o produto de software final no atenda as necessidades do cliente. Lembrando tambm que a ferramenta phpRm apenas auxilia nos processos de REQM e RD definidos pelo modelo CMMI, necessitando do apoio da organizao e da conscientizao das pessoas envolvidas para atingir a capacidade destes processos.

5 UMA APLICAO PRTICA

Como forma de validao da ferramenta phpRm, o projeto de software chamado de Portal Simuplan ser inserido na mesma para que os requisitos do cliente sejam documentados e gerenciados de acordo com as reas de processo REQM e RD do modelo CMMI. Objetivando desta maneira validar a utilizao da ferramenta e resolver um dos principais problemas que a grande rotatividade de desenvolvedores do grupo Simuplan.

5.1 O Simuplan

O grupo de pesquisa interdisciplinar denominado Simuplan, mantido pelo Curso de Cincia da Computao da UPF e EMBRAPA, sob coordenao do Prof. M.Sc. Willingthon Pavan, tem como objetivo principal desenvolver solues voltadas em simular alguns tipos de plantaes agrcolas, como por exemplo, a soja e o trigo. Uma destas solues desenvolvidas pelo Simuplan ser o Portal Simuplan. O grupo est formado a mais de 3 anos contando atualmente com 10 pessoas, sendo o coordenador e os outros nove desenvolvedores. Seus projetos tm uma importante participao no cenrio cientfico nacional e internacional na rea da informtica e agronomia. Como resultado deste trabalho pode-se citar diversos projetos de sucesso, tais como: SimTrigo: simulao do crescimento e desenvolvimento do trigo e suas pragas; Sisalert: sistema de alerta para macieiras, alho, milho, morango e outros; SimuSoja: simulao do ataque da ferrugem do soja.

61

O grupo participa de mais outros dois projetos, o EMBRAPA Trigo e o EMBRAPA Uva e Vinho, e tambm do projeto internacional Simulao do trigo em condies climticas daqui a 50 anos. Todos os projetos so ligados rea da informtica aplicada agricultura.

5.2 Por que o Simuplan?

O motivo de validar a ferramenta phpRm no Simuplan e com o projeto Portal Simuplan justifica-se, pois atualmente no h nenhuma documentao dos projetos, os requisitos no so documentados e gerenciados e h uma grande rotatividade dos integrantes do grupo, estes por serem alunos da graduao. Atualmente a equipe de desenvolvedores do Simuplan est dividida entre quatro projetos de pesquisa em andamento e os integrantes do grupo tambm executam atividades de manuteno em projetos j implantados, quando necessrio. Somando-se a demanda dos novos projetos e manutenes, com a inexistncia de uma poltica organizacional que oriente os projetos de desenvolvimento de software, principalmente no que diz respeito ao gerenciamento de requisitos. Como conseqncia disto, o produto de software entregue ao cliente muitas vezes no atende todas as necessidades. E tambm, o sucesso do desenvolvimento dos produtos de software depende das habilidades e da dedicao dos desenvolvedores, gerando assim um vnculo muito forte entre o desenvolvedor e o sistema, comprometendo a manuteno do mesmo. Estes problemas fazem com que os projetos caminhem sem acompanhamento, padro e controle das atividades, dificultando sua monitorao e projeo de resultados.

5.3 Utilizando a Ferramenta phpRm

Inicialmente o modelo CMMI e a ferramenta phpRm foram apresentados para o coordenador do Simuplan, a fim de mostrar as prticas especficas REQM e RD, as funcionalidades da ferramenta e como isso poderia ajudar no gerenciamento dos projetos desenvolvidos pelo grupo.

62

O coordenador do grupo aceitou que a ferramenta fosse utilizada como forma de validao do presente trabalho cedendo um dos integrantes para auxiliar na documentao dos requisitos e um de seus projetos em andamento, o Portal Simuplan. Aps ter a aprovao para estudar e documentar o projeto Portal Simuplan foram definidos os stakeholders que seriam responsveis pelas diversas atividades do processo. Como o projeto encontrava-se em andamento e somente um dos integrantes do Simuplan ficou encarregado de repassar as informaes pertinentes ao projeto, ficou este com o papel de Usurio Responsvel e o autor ficou responsvel por atuar como Engenheiro de Software do projeto. Uma vez conhecidos os stakeholders do projeto foram definidas as atividades a serem executadas para validar a utilizao da ferramenta, a seguir: Apresentao do modelo CMMI e da ferramenta phpRm; Estudo do projeto Portal Simuplan; Definio do checklist de validao dos requisitos; Documentao dos requisitos; Definio dos componentes do produto; Validao e aprovao dos requisitos; Criao das baselines; Matriz de rastreabilidade dos requisitos. Cabe ressaltar que as atividades executadas foram somente em relao ferramenta, no envolvendo as prticas especficas que requerem uma soluo da organizao, ou seja, as prticas que devem ser institucionalizadas pela organizao no foram questionadas.

5.3.1 Apresentao do modelo CMMI e da ferramenta phpRm

Os objetivos necessrios para atender as prticas especficas do REQM e RD do modelo CMMI e as funcionalidades da ferramenta foram apresentados ao stakeholder, a fim de mostrar a dinmica e o funcionamento da ferramenta. Esta atividade foi importante, pois necessrio que os stakeholders estejam comprometidos e que conheam o processo para colaborar e visualizar os benefcios a eles retornados.

63

5.3.2 Estudo do projeto Portal Simuplan

Aps a apresentao do modelo e da ferramenta, passou a ser estudado o projeto Portal Simuplan para entender seu objetivo. Como este projeto estava em andamento, o produto de software esperado pelo cliente encontrava-se definido na idia dos integrantes do projeto, mas sem qualquer documentao referente a ele. Somente os principais requisitos eram documentados e essa documentao continha apenas uma breve descrio dos requisitos. Diante disso, se algum desenvolvedor tivesse que se integrar neste projeto, ele iria depender dos outros integrantes para adquirir o conhecimento necessrio e contribuir com o Portal Simuplan. Com a ajuda do Usurio Responsvel foi possvel entender o propsito do Portal Simuplan e gerar a primeira verso do documento de viso deste produto de software, esse documento apresentado no Anexo A e Anexo B. O portal tem como objetivo auxiliar na preveno de doenas em plantaes e ser um espao para notcias e discusses dentro da rea agrcola. Aps entender o objetivo do produto de software foram inseridos no documento de viso requisitos candidatos solicitados pelo cliente. Alguns dos servios definidos para o portal j esto disponveis para os usurios do mesmo, esses servios ou funcionalidades foram implementados na primeira etapa de desenvolvimento do projeto, portanto alguns dos requisitos acima citados que foram documentados na ferramenta j esto codificados e sendo utilizados.

5.3.3 Definio do checklist de validao dos requisitos

Com o objetivo do Portal Simuplan entendido, passou a ser construdo o checklist para validar e verificar o entendimento dos requisitos fornecidos pelo cliente. O objetivo esperado pelo checklist que os requisitos fossem revisados para identificar e resolver os conflitos, contradies ou omisses. A seguir, as questes que formaram este checklist: O objetivo do requisito est claro? O requisito foi bem compreendido? O cliente domina o entendimento do requisito? Este requisito realmente necessrio?

64

O requisito tem restries? grande o risco para o projeto se o requisito no for incorporado? Existem requisitos dependentes? Os requisitos dependentes foram verificados? Este requisito dependente de outro requisito? Os requisitos que este dependente foram verificados? Algumas destas questes podem no ser aplicadas a todos os requisitos, portanto

nem todas so obrigatrias, isso pode ser verificado na Figura 17.

Fonte: Primria. Figura 17 Checklist de entendimento dos requisitos

5.3.4 Documentao dos requisitos

Aps definir o checklist para validar e verificar os requisitos, comeou a ser estudado os requisitos do portal para serem detalhados e documentados na ferramenta. Conforme citado, o projeto do Portal Simuplan no possui nenhuma documentao, exceto de uma listagem dos requisitos que seriam incorporados ao mesmo. Dos requisitos listados foram analisados e detalhados aqueles que j esto implementados, os requisitos

65

que fazem parte da segunda etapa de desenvolvimento do projeto e o nico requisito no funcional do portal. A seguir os requisitos do Portal Simuplan sero descritos juntamente com seu respectivo documento, esses documentos encontram-se nos anexos do presente trabalho: Requisito 1 Cadastro dos Agricultores: Os agricultores devem ter acesso para se cadastrarem no portal. Anexo C; Requisito 2 Cadastro das Estaes: As estaes de clima devem ser cadastradas. Anexo D; Requisito 3 Cadastro de Cidades: As cidades devem ser cadastradas no portal. Anexo E; Requisito 4 Cadastro de UF: Os estados devem ser cadastrados no portal. Anexo F; Requisito 5 Cadastro de Pases: Os pases devem ser cadastrados no portal. Anexo G; Requisito 6 Mdulo de Usurios: Os usurios devem ter acesso controlado ao portal. Anexo H; Requisito 7 Permisses de Acesso: Os usurios devem ter acesso ao portal de acordo com suas permisses e nveis de acesso. Anexo I; Requisito 8 Cadastro de Agricultores com Estao: Os agricultores devem estar vinculados as suas estaes climticas. Anexo J; Requisito 9 Cadastro de Climas: O portal deve ser alimentado com os dados climticos por estaes. Anexo K; Requisito 10 Sumarizao dos Climas: Os dados climticos devem ser sumarizados por estao e perodo. Anexo L Requisito 11 Busca de dados climticos: Buscar os dados climticos em sites de informaes sobre o clima. Estes dados devem alimentar os dados climticos do portal. Anexo M; Requisito 12 Mapa de incidncia de pragas: O portal deve disponibilizar um mapa das regies das estaes, coloridos conforme risco de incidncia de pragas. Cada cliente deve ver o mapa das suas estaes. Anexo N; Requisito 13 Relatrio de Condies Meteorolgicas: Gerar relatrios das condies meteorolgicas por perodo de tempo e estao. Anexo O;

66

Requisito 14 Relatrio das Simulaes: Gerar relatrios das simulaes meteorolgicas do tempo das estaes. Anexo P; Requisito 15 Fruns: Os usurios do portal devem ter a possibilidade de trocar informaes, idias e formarem grupos de discusses relacionados agricultura, estas discusses se daro em um frum integrado ao portal. Anexo Q. Aps detalhar e documentar os requisitos do projeto, as propriedades como

prioridade, esforo, risco e estabilidade dos requisitos foram analisadas juntamente com o Usurio Responsvel, recebendo cada uma delas o valor apropriado. Tambm foram definidos os requisitos dependentes de cada requisito e a relao desta dependncia, isto pode ser verificado nos documentos dos requisitos que esto em anexo ao presente trabalho.

5.3.5 Definio dos componentes do produto

Com os requisitos devidamente documentados, passou a ser definido os componentes do produto para formar o produto final, o Portal Simuplan. Estes componentes so mdulos que englobam um ou mais requisitos para determinar as funcionalidades do produto de software. A seguir os componentes do produto que formam o Portal Simuplan sero descritos: Mapas de Riscos: Mapas de risco de incidncia de pragas; Mdulo de Alimentao: Mdulo de alimentao de dados do portal; Mdulo de Autorizao: Mdulo de autorizao de acesso ao portal; Mdulo de Cadastros: Cadastros de gerais do portal; Mdulo de Relatrios: Relatrios de dados climticos e de simulaes. Aps estabelecer os componentes do produto, os requisitos dependentes foram alocados aos componentes do produto juntamente com a relao desta dependncia. Nos documentos dos requisitos que esto em anexo ao presente trabalho estas dependncias podem ser verificadas.

67

5.3.6 Validao e aprovao dos requisitos

Aps alocar os requisitos aos componentes do produto, os requisitos foram submetidos ao checklist para validar e verificar o entendimento dos mesmos. Este checklist ajudou o Engenheiro de Software e o Usurio Responsvel a optarem por aprovar ou descartar os requisitos, assim como definir as propriedades de risco e estabilidade dos requisitos do projeto. Com os requisitos validados, o relatrio de riscos mostrou-se til para decidir na aprovao dos requisitos a serem incorporados ao projeto, pois ele demonstra todas as propriedades dos requisitos tornando assim a tarefa mais gil. Tambm auxiliou em apontar os requisitos cuja estabilidade mdia ou baixa e o risco crtico para serem analisados novamente at atingirem a estabilidade desejada, esses requisitos no foram incorporados ao projeto exceto os j implementados, pois podem acarretar em atraso de cronograma ou at mesmo inviabilizar o projeto. Isto pode ser verificado na Figura 18.

Fonte: Primria. Figura 18 - Relatrio de Riscos nos Requisitos

68

5.3.7 Criao das baselines

Com os requisitos do projeto aprovados, a prxima etapa foi definir as baselines para o desenvolvimento. Cada baseline ser composta por um conjunto de requisitos aprovados, porm um requisito no pode constar em mais de uma baseline. Como alguns dos requisitos esto implementados, foram estabelecidas duas baselines, uma para o conjunto de requisitos implementados e outra para os requisitos que sero codificados. Os requisitos propostos ficaram para uma terceira baseline que no ser definida neste trabalho. Aps estabelecer as baselines foram definidas as datas de destino para estabelecer uma previso de concluso da implementao. A seguir so citadas as baselines definidas para o Portal Simuplan juntamente com o conjunto de requisitos aprovados: 1. 2. Sprint 1: Como a baseline est implementada, no foi definido a data de destino; Requisito 1 Cadastro dos Agricultores; Requisito 2 Cadastro das Estaes; Requisito 3 Cadastro de Cidades; Requisito 4 Cadastro de UF; Requisito 5 Cadastro de Pases; Requisito 6 Mdulo de Usurios; Requisito 7 Permisses de Acesso; Requisito 8 Cadastro de Agricultores com Estao; Requisito 9 Cadastro de Climas. Sprint 2: A data de destino definida para esta baseline foi 26/11/2004. Requisito 10 Sumarizao dos Climas; Requisito 11 Busca de dados climticos. Os requisitos acima citados, passaram do estado aprovado para o estado incorporado, definindo desta maneira que agora so requisitos do produto de software.

69

5.3.8 Matriz de rastreabilidade dos requisitos

Aps definir as baselines do projeto foram geradas as matrizes de rastreabilidade, estas sero utilizadas para auxiliar os engenheiros de software na anlise de impacto de uma mudana no projeto, rastreando os requisitos afetados por esta mudana. As informaes de rastreabilidade entre requisitos, componentes do produto e sua origem, foram mantidas pelo engenheiro de software, ou seja, ele decidiu se um requisito depende de outro. De acordo com Sommerville (2003, p. 120), a matriz rastreia os trs tipos de informaes seguintes: Informaes de rastreabilidade dos requisitos: vinculam os requisitos dependentes de outros requisitos. Conforme observado no Anexo S, na primeira tabela, onde se encontram os requisitos e os requisitos dependentes, o primeiro requisito 11 Busca de dados climticos o objeto principal desta matriz, a partir dele sero rastreados todos os seus dependentes, juntamente com o grau de relacionamento entre eles. Por exemplo, o requisito 11 tem uma relao fraca (R) com os requisitos 2 e 3, isso significa que os dependentes devem ser revisados para verificar se necessrio alguma mudana. Porm com o requisito 9, ele tem uma relao forte (U), ento se o 11 for alterado, o possibilidade de o 9 ser modificado grande. Informaes de rastreabilidade do projeto: vinculam os requisitos dependentes dos componentes do produto. Na segunda tabela onde esto os requisitos e os componentes do produto, no Anexo S, pode ser observado que, o requisito rastreado 11, dependente do componente do produto Mdulo de Alimentao, os demais requisitos tem alguma relao com requisito em questo. A relao forte (U) ou fraca (R) segue idia vista anteriormente. Informaes de rastreabilidade da origem: vinculam os requisitos aos stakeholders que os propuseram. Essa informao utilizada para consultar os stakeholders quando uma mudana proposta. As matrizes de rastreabilidade geradas foram somente dos requisitos que compem a baseline 2 e podem ser observadas no Anexo R e Anexo S.

70

5.4 Resultados Obtidos

O resultado obtido na utilizao da ferramenta phpRm para documentar e gerenciar os requisitos foi positivo. Gerou uma reao imediata do coordenador do grupo Simuplan em questes que melhorariam o atual processo de trabalho com a utilizao da ferramenta. Um dos fatores que motivou o coordenador do grupo e o integrante que fez o papel de Usurio Responsvel foi a possibilidade de documentar os requisitos, rastre-los e definir as baselines do projeto, recursos estes que no existem em seu processo de desenvolvimento atual. Talvez a maior dificuldade apresentada tenha sido a utilizao do documento de requisitos por no existir nenhuma documentao referente aos requisitos do projeto. Ficou evidente a motivao dos representantes do Simuplan com a utilizao da ferramenta phpRm, j que o processo de gerenciamento e desenvolvimento de requisitos fundamental para atingir patamares mais elevados de qualidade no desenvolvimento de software.

CONCLUSO

O estudo da Engenharia de Requisitos demonstra sua importncia no processo de desenvolvimento, pois a maioria dos problemas que o produto de software apresenta so derivados da m interpretao ou da falta de implementao de requisitos. Mas to ou mais importante que descobrir os requisitos, gerenci-los, de forma que as mudanas sejam documentadas e avaliadas em relao ao impacto que causaro no projeto. Na evoluo do CMM para o CMMI, as reas de processo REQM e RD, tratam por completo o ciclo de vida dos requisitos nos projetos de desenvolvimento de sistemas. Como principal contribuio do trabalho cita-se a ferramenta desenvolvida, que pode auxiliar na capacitao dos processos da engenharia de requisitos para que se diminua o abismo entre as necessidades do cliente e o produto que lhe entregue. Somando-se a isso, fica como contribuies o estudo realizado do modelo CMMI e tambm sua abordagem crtica em relao aos requisitos. Por fim, destaca-se a aplicao da ferramenta em um ambiente real, trazendo resultados positivos na rotina de trabalho do grupo Simuplan. Neste estudo percebeu-se que uma das maiores dificuldades do emprego das reas de processo REQM e RD do modelo CMMI est na subjetividade encontrada nas prticas especficas, pois definido o que fazer para capacitar o processo e no como fazer, ficando muitas vezes na interpretao de quem est buscando uma soluo. Fica proposto como trabalhos futuros o estudo e implementao das prticas especficas que no foram completamente atendidas e de outras reas de processo da categoria engenharia. Sugere-se, tambm, que seja realizado um trabalho para institucionalizao das prticas especficas que competem organizao.

72

Ainda como trabalhos futuros, pode-se automatizar o processo de anlise de riscos nos requisitos e tambm utilizar a ferramenta como parte do processo de desenvolvimento de software na Diviso de Tecnologia da Informao da UPF.

REFERNCIAS

CORDEIRO, Marco Aurlio. Uma Ferramenta Automatizada de Suporte ao Processo de Gerenciamento de Requisitos. 2002. Dissertao (Mestrado) - Pontifcia Universidade Catlica do Paran, Curitiba, 2002. FIORINI, Soeli T.; STAA, Arndt Von; BAPTISTA, Renan Martins. Engenharia de Software com CMM. Rio de Janeiro: Brasport, 1998. GAMPERT, Gilberto. Gerenciamento de Requisitos na Seo de Informtica da UPF. Monografia (Graduao em Cincia da Computao) Curso de Cincia da Computao, Universidade de Passo Fundo, 2003. PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica. Pearson Brasil, 2004. ROCHA, Ana Regina Cavalcanti da; MALDONADO, Jos Carlos; WEBER, Kival Chaves. Qualidade de Software: Teoria e Prtica. So Paulo: Prentice Hall, 2001. SEI TR-028 SOFTWARE ENGINEERING INSTITUTE, Technical Report 028, Capability Maturity Model Integration for Software Engineering, 2002; Disponvel em: <http://www.sei.cmu.edu/publications/documents/02.reports/02tr028.html>; Acesso em: 25 de novembro de 2003. SOMMERVILE, Ian. Engenharia de Software. 6. ed. So Paulo: Addison Wesley, 2003. SOMMERVILLE, Ian; SAWYER, Peter. Requirements engineering: A Good Practice Guide. Chichester: John Wiley & Sons,1999 . ZANATTA, Alexandre Lazaretti. XSCRUM: Uma proposta de extenso do SCRUM para adequao do modelo CMMI (Mestrado em Computao) - Instituto de Informtica da Universidade Federal de Santa Catarina, Florianpolis, 1999.

OBRAS CONSULTADAS

IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specications. 1998; Disponvel em: < www.csri.utoronto.ca/~sme/CSC2106S/papers/IEEE-STD-830-1998.pdf>; Acesso em: 25 de novembro de 2003. HORCH, John W. Practical Guide to Software Quality Management, Second Edition. Artech House, 2003 LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: A Use Case Approach, Second Edition. Addison Wesley, 2003. MCCONNELL, Steve. Professional Software Development. Addison Wesley, 2003. PRESSMAN, Roger S. Engenharia de Software. So Paulo: Makron Books, 1995. SEI TR-029 SOFTWARE ENGINEERING INSTITUTE. Technical Report 029, Capability Maturity Model Integration for Software Engineering, 2002; Disponvel em: <http://www.sei.cmu.edu/publications/documents/02.reports/02tr029.html>; Acesso em: 25 de novembro de 2003.

ANEXO A - DOCUMENTO DE VISO (parte inicial)

ANEXO B - DOCUMENTO DE VISO (parte final)

ANEXO C DOCUMENTO DO REQUISITO 1

ANEXO D - DOCUMENTO DO REQUISITO 2

ANEXO E - DOCUMENTO DO REQUISITO 3

ANEXO F - DOCUMENTO DO REQUISITO 4

ANEXO G - DOCUMENTO DO REQUISITO 5

ANEXO H - DOCUMENTO DO REQUISITO 6

ANEXO I - DOCUMENTO DO REQUISITO 7

ANEXO J - DOCUMENTO DO REQUISITO 8

ANEXO K - DOCUMENTO DO REQUISITO 9

ANEXO L - DOCUMENTO DO REQUISITO 10

ANEXO M - DOCUMENTO DO REQUISITO 11

ANEXO N - DOCUMENTO DO REQUISITO 12

ANEXO O - DOCUMENTO DO REQUISITO 13

ANEXO P - DOCUMENTO DO REQUISITO 14

ANEXO Q - DOCUMENTO DO REQUISITO 15

ANEXO R - MATRIZ DE RASTREABILIDADE DO REQUISITO 10

ANEXO S - MATRIZ DE RASTREABILIDADE DO REQUISITO 11