C.E.S.A.

R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

CRISTIANO TAVARES SILVA

Um experimento na engenharia de requisitos para caracterizao do processo e sua adequao s prticas especficas do CMMI

RECIFE 2010

CRISTIANO TAVARES SILVA

Um experimento na engenharia de requisitos para caracterizao do processo e sua adequao s prticas especficas do CMMI
Dissertao apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Mestre em Engenharia de Software. Orientao: Prof. Dr. Vinicius Cardoso Garcia

RECIFE 2010

ii

iii

C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

Um experimento na engenharia de requisitos para caracterizao do processo e sua adequao s prticas especficas do CMMI CRISTIANO TAVARES SILVA

Dissertao apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Mestre em Engenharia de Software. Data de aprovao: _____ / _____ / 2010. Banca examinadora: _________________________________ Prof.(a).Dr.(a) *** ***instituio*** _________________________________ Prof.(a).Dr.(a) *** ***instituio*** _________________________________
Prof.(a).Dr.(a)

***instituio***

iv

AGRADECIMENTOS

Primeiramente, agradeo a Deus por tudo que tenho conquistado, pela famlia que possuo, por todos os obstculos que Ele ajuda a remover e por toda a fora que Ele me d para ultrapassar os limites do meu ser. Agradeo em especial a minha amada esposa Viviane, sem ela, esse sonho e muitos outros no teriam se concretizado, sem a sua eterna compreenso e incentivo, eu no teria conseguido. minha querida filha Maria Clara, que muitas vezes acreditou mais em mim do que eu mesmo. Sempre compreendeu a minha ausncia em muitos momentos durante a realizao deste trabalho e que, com o seu sorriso e seu abrao, renovavam as minhas foras. Aos meus pais, Geraldo e Leni pelo carinho, amor e apoio que sempre me deram. A meu orientador, o professor Vinicius Cardoso Garcia, pelo seu incentivo e principalmente por sua confiana em mim, por todo o conhecimento transmitido, suas crticas e sugestes e pela disponibilidade sempre apresentada. minha querida e estimada sogra, a professora Helen Khoury, que muito me incentivou a me inscrever no curso e na realizao deste trabalho.

RESUMO

A crescente globalizao dos negcios e o ambiente competitivo estimulam as empresas a investirem na melhoria contnua dos seus processos internos. Diante deste cenrio, os investimentos em Tecnologia da Informao so inevitveis e, com isso, o surgimento de solues tericas de melhorias de processo tem sido grande. Mesmo assim, adotar um processo novo a partir de um modelo terico no significa que ir funcionar no ambiente organizacional, levando em considerao estrutura, equipe e mentalidade da empresa. Dentre os processos que envolvem o desenvolvimento de sistemas, existe a engenharia de requisitos. Como a existncia desse processo mais forte no incio do ciclo de vida de um sistema, sua importncia grande, pois um entendimento errado nessa fase pode gerar um sistema em desacordo com as necessidades a que ele foi projetado. Existem modelos tericos da engenharia de requisitos que sugerem as melhores prticas. Um dos modelos mais difundidos no Brasil o Modelo CMMI, que inclusive um rgo certificador de empresas de tecnologia da informao. Mesmo assim, no existe a garantia que os modelos tericos, como o CMMI, esto adequados cem por cento ao ambiente de todas as empresas. Por isso aperfeioar os processos das empresas de desenvolvimento para moldar-los ao ambiente operacional da empresa muito importante. Atualmente a engenharia de software experimental, que estudo emprico sobre a prpria engenharia de software, pode gerar para as empresas a oportunidade de caracterizar, avaliar, prever, controlar e sugerir melhorias em seus processos, tornando-os mais eficientes e gerando valor agregado. por isso que neste trabalho foi desenvolvido um modelo que utilizando a engenharia de software experimental possibilita as empresas caracterizar, verificar os pontos fortes e de melhorias do processo de engenharia de requisitos, realizando uma comparao com as prticas especficas da engenharia de requisitos do CMMI.
PALAVRAS-CHAVES: Engenharia de Software Experimental. Engenharia de requisitos. CMMI.

ABSTRACT

The increasing globalization of business and competitive environment encourage businesses to invest in continuous improvement of its internal processes. In this scenario, investments in information technology are inevitable and with it the emergence of theoretical solutions process improvements have been great. Even so, adopting a new process from a theoretical model does not mean it will work in the organizational environment, taking into account structure, staff and mentality of the company. Among the processes involving the development of systems, there is the requirements engineering. Since the existence of this process is stronger at the beginning of the life cycle of a system, its importance is great because a misunderstanding that stage can generate a system at odds with the needs to which it was designed. There are theoretical models of requirements engineering that suggest best practices. One of the most widespread in Brazil is the CMMI model, which is also a certifying body for information technology companies. Still, there is no guarantee that the theoretical models such as CMMI, are suitable environment to one hundred percent of all businesses. Therefore improve the processes of development companies to shape them to the company's operating environment is very important. Currently, experimental software engineering, which is empirical study on their own software engineering, can generate for companies the opportunity to characterize, assess, predict, monitor and suggest improvements in their processes, making them more efficient and generating added value. That is why this work developed a model using the experimental software engineering enables companies to characterize, verify the strengths and improvements to the process engineering requirements, performing a comparison with the specific practices of requirements engineering of CMMI.
Keywords: Experimental Software Engineering. Requirements Engineering. CMMI.

SUMRIO
1 1.1 1.1.1 1.1.2 1.2 1.2.1 1.2.2 1.3 1.4 1.5 2 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.2.4 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 INTRODUO ............................................................................................. 1 MOTIVAO................................................................................................ 5 MOTIVAO DE MERCADO ...................................................................... 5 MOTIVAO TCNICA ............................................................................... 6 PROBLEMA ................................................................................................. 6 OBJETIVO GERAL ...................................................................................... 6 OBJETIVOS ESPECFICOS ........................................................................ 7 JUSTIFICATIVA ........................................................................................... 7 CONTRIBUIES ....................................................................................... 8 ESTRUTURA DA DISSERTAO ............................................................... 9 REVISO BIBLIOGRFICA...................................................................... 10 ENGENHARIA DE REQUISITOS .............................................................. 10 REQUISITOS DE SOFTWARE .................................................................. 13 PROCESSO DE ENGENHARIA DE REQUISTOS .................................... 16 ENGENHARIA DE REQUISTOS NO CMMI............................................... 24 ENGENHARIA DE SOFTWARE EXPERIMENTAL.................................... 38 MEDIO .................................................................................................. 41 VALIDADE ................................................................................................. 43 TIPOS DE EXPERIMENTOS ..................................................................... 44 PROCESSO ............................................................................................... 45 SOLUO PROPOSTA ............................................................................ 50 A EMPRESA .............................................................................................. 50 DEFINIO DOS OBJETIVOS .................................................................. 50 OBJETIVO GLOBAL: ................................................................................. 50 OBJETIVO DA MEDIO: ......................................................................... 50 OBJETIVO DO ESTUDO: .......................................................................... 51 QUESTES ............................................................................................... 51

3.3 PLANEJAMENTO ...................................................................................... 53 3.3.1 DEFINIO DAS HIPTESES .................................................................. 53 3.3.2 DESCRIO DA INSTRUMENTAO ..................................................... 54 3.3.3 SELEO DE CONTEXTO ....................................................................... 56 3.3.4 SELEO DOS INDIVDUOS.................................................................... 56 3.3.5 VARIVEIS ................................................................................................ 56 3.3.5.1 VARIVEIS INDEPENDENTES: .............................................................. 56 3.3.5.2 VARIVEIS DEPENDENTES: .................................................................. 56 3.3.6 ANLISE QUALITATIVA ............................................................................ 57 3.3.7 VALIDADE ................................................................................................. 57 3.4 3.4.1 OPERAO ............................................................................................... 59 MATERIAL INFORMATIVO DAS PRTICAS ESPECFICAS DO CMMI ......................................................................................................... 59

QUESTIONRIO DO PERFIL DOS PARTICIPANTES .............................. 68 3.4.2 3.4.3 QUESTIONRIO DAS PRTICAS ............................................................ 69 3.4.4 RESULTADO DO ESTUDO ....................................................................... 74 3.4.4.1 RESULTADO DO ESTUDO ..................................................................... 74 3.4.4.2 PERFIS DOS PARTICIPANTES .............................................................. 78 3.5 ANLISE E INTERPRETAO DOS RESULTADOS ............................... 80 3.5.1 VALIDAO DOS RESULTADOS............................................................. 80 3.5.2 ESTATSTICA DESCRITIVA...................................................................... 80 3.5.3 ANLISE DOS RESULTADOS .................................................................. 85 3.5.3.1 ANLISE QUANTITATIVA ....................................................................... 85 3.5.3.2 ANLISE QUALITATIVA .......................................................................... 86 3.5.3.3 VERIFICAO DAS HIPTESES ........................................................... 87 3.6 3.6.1 3.6.2 3.6.3 4 4.1 CONCLUSES .......................................................................................... 88 CARACTERIZAO .................................................................................. 88 PONTOS FORTES .................................................................................... 88 PONTOS DE MELHORIA .......................................................................... 89 CONSIDERAES FINAIS ....................................................................... 91 TRABALHOS FUTUROS ........................................................................... 92

REFERNCIAS ......................................................................................................... 93

LISTA DE ILUSTRAES
FIGURA 1: VISO DO SWEBOK E SUAS REAS DE CONHECIMENTO. ...................................................................... 2 FIGURA 2: ESTRUTURA DO CMMI ............................................................................................................... 27 FIGURA 3: RELACIONAMENTO ENTRE AS VARIVEIS (TRAVASSOS, 2002). ................................. 40 FIGURA 4: ESQUEMA DE UMA FBRICA DE EXPERINCIA (TRAVASSOS, 2002). ......................... 47 FIGURA 5: DISTRIBUIO DOS DADOS DOS PROFISSIONAIS ENTREVISTADOS ......................... 79

LISTA DE TABELAS
TABELA 1: CUSTOS DA CORREO DE UM PROBLEMA GERADO NO PROCESO DE REQUISITOS (BOEHM E PAPACCIO, 1988)............................................................................................................................................ 3 TABELA 2: NVEIS DE MATURIDADE DO CMMI ...................................................................................................... 25 TABELA 3: PRTICAS ESPECFICAS DAS REAS DE PROCESSO DE GERENCIAMENTO DE REQUISITOS. ............................................................................................................................................ 27 TABELA 4: PRTICAS ESPECFICAS DAS REAS DE PROCESSO DE DESENVOLVIMENTO DE REQUISITOS. ............................................................................................................................................ 31 TABELA 5: COMPARAO DAS ESTRATGIAS EMPRICAS. ............................................................... 45 TABELA 6: OPES DE RESPOSTA APLICADAS NO QUESTIONRIO .............................................. 54 TABELA 7: RELAO ENTRE OS DADOS DE P,U,A E AS QUESTES. .............................................. 55 TABELA 8: PRTICAS ESPECFICAS DE OBJETIVO ESPECFICO DE GERENCIAMENTO DE REQUISITOS E SUAS SUBPRTICAS. .............................................................................................................................................. 59 TABELA 9: PRTICAS ESPECFICAS DE OBJETIVO ESPECIFICO DE DESENVOLVIMENTO DE REQUISITOS DO CLIENTE E SUAS SUBPRTICAS. .................................................................................................................... 62 TABELA 10: QUESTIONRIO DO PERFIL DOS PARTICIPANTES ............................................................................... 68 TABELA 11: ESCALAS PARA RESPOSTAS. ................................................................................................... 69 TABELA 12: QUESTIONRIO DA LISTA DE PRTICAS DE ENGENHARIA DE REQUISITOS. ........... 69 TABELA 13: RESULTADO DAS ENTREVISTAS.......................................................................................... 74 TABELA 14: PERFIL DOS PARTICIPANTES. .................................................................................................. 79 TABELA 15: LEGENDA DE AUXLIO DA TABELA 11 ................................................................................. 79 TABELA 16: MEDIANA E MODA REFERENTE AS RESPOSTAS SOBRE A PRESENCE DAS PRTICAS NO PROCESSO DA EMPRESA. ...................................................................................... 80 TABELA 17: MEDIANA E MODA REFERENTE S RESPOSTAS SOBRE A UTILIDADE DAS PRTICAS SUGERIDAS PELO CMMI NO PROCESSO DA EMPRESA. ....................................... 81 TABELA 18: MEDIANA E MODA REFERENTE S RESPOSTAS SOBRE A ADEQUAO DAS PRTICAS SUGERIDAS PELO CMMI NO PROCESSO DA EMPRESA. ....................................... 81 TABELA 19: LISTA DE PRTICAS USADAS PARCIALMENTE. ............................................................... 82 TABELA 20: LISTA DE PRTICAS USADAS PLENAMENTE .................................................................... 83 TABELA 21: LISTA DE PRTICAS NO USADAS QUE GOSTARIAM DE USAR ................................. 84 TABELA 22: RELAO DAS RESPOSTAS QUANTIFICADAS. ................................................................ 85 TABELA 23: LISTA DAS PRTICAS QUE NO FORAM USADAS. ......................................................... 86

ABREVIATURAS

Sigla CMMI FDD GQM QAI QFD QIP RAD RD REQM TDD UML XP

Significado Capability Maturity Model Integration Feature Driven Development Goal Question Metric Quality Assurance Institute Quality function deployment Quality Improvement Paradigm Rapid Application development Requirements Development Requirements Management Test Driven Development Unified Modeling Language eXtreme Programming

1 INTRODUO
O Institute of Electrical and Electronic Engineers (IEEE) uma organizao do mundo dos profissionais de informtica com vrias publicaes normas e conferncias realizadas. Ele define a engenharia de software como a aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno de software. Quando o IEEE descreve a engenharia de software como uma abordagem sistemtica, quer dizer que a engenharia de software se desenvolve segundo um mtodo ou ordenao e seus elementos so classificados e organizados entre si, seguindo um ou mais critrios. J em relao disciplinada o IEEE refere-se ao fato a engenharia de software obedecer a ordens e regulamentos. Quanto ao fato da engenharia de software ser quantificvel, porque para o IEEE seu valor pode ser avaliado com preciso. Ainda relacionado engenharia de software, o IEEE tomou a iniciativa de criar um consenso sobre as reas de conhecimento da engenharia de software e seu escopo criando o SWEBOK. O SWEBOK est para a engenharia de software como o PMBOK est para a gerncia de projetos. Ele o guia de conhecimento da engenharia de software e foi criado para: Promover uma viso consistente do mundo da Engenharia de Software; Explicar o ncleo da Engenharia de Software e seu conjunto de fronteiras; Caracterizar os conceitos da disciplina de Engenharia de Software; Promover um acesso por tpicos para a engenharia de software;

Promover uma base de certificaes individuais e material licenciado.

Assim como o PMBOK, o SWEBOK tambm dividido em reas de conhecimento. No caso do SWEBOK existem dez reas conhecimento. So elas: Desenho de software; Construo de software; Teste de software; Manuteno de software; Gerncia de configurao de software; Gerncia de Engenharia de software; Processo de Engenharia de software; Ferramentas e mtodos de Engenharia de software; Qualidade de Software e rea de conhecimento de Requisitos de software. A Erro! Fonte de referncia no encontrada. mostra uma viso do SWEBOK e suas reas de conhecimento.

Figura 1: Viso do SWEBOK e suas reas de conhecimento.

Dentre as reas de conhecimento do SWEBOK, a de Requisitos de software foi utilizada neste trabalho por sua importncia no processo de engenharia de software. Definida por SOMMERVILLE (2008) como o processo de descobrir, analisar, documentar e verificar os servios propostos por um sistema e as suas restries, a engenharia de requisitos citada e usada em vrios estudos. O relatrio do

Standish Group O CHAOS Report de 2007, um exemplo desses estudos, onde seu resultados apresentaram que apenas 35% dos projetos de software so bem sucedidos e que 46% dos projetos de software falharam em relao a tempo e requisitos entregues. Esta importncia relacionada engenharia de requisitos no vem de agora, anos atrs j existiam estudos que mostravam a preocupao neste processo. Como exemplo dessa preocupao, o estudo de BOEHM (1981) apresentou um dado alarmante de 70 a 85% dos erros encontrados em sistemas podem ser rastreados para problemas de requisitos. Outro dado relevante que ratifica a importncia do processo de engenharia de requisitos vem do prprio SEI. Ele considera que os dois principais fatores de falhas de oramentos e cronograma so derivados de problemas de requisitos, seja pela Especificao de requisitos inadequada ou pelas Mudanas que existem nos requisitos. Alm disso, nesse processo que os erros mais caros de serem corrigidos so gerados. A Erro! Fonte de referncia no encontrada. mostra o estudo feito por BOEHM e PAPACCIO (1988) que trs os custos da correo de um problema que foi gerado no processo de requisitos;

Tabela 1: Custos da correo de um problema gerado no proceso de requisitos (BOEHM e PAPACCIO, 1988).

Custo $1 $5 $10 $20 $200 Encontrado na prpria fase de anlise de requisitos Encontrado na fase de projeto do sistema Encontrado na fase de codificao Encontrado na fase de testes unitrios Encontrado aps a entrega do produto

Por isso que a engenharia de requisitos considerada to importante no desenvolvimento de sistemas, sendo exigida e mapeada em modelos e normas certificadoras importantes no mundo da tecnologia da informao. Como exemplo dos mais conhecidos no Brasil podemos citar o MPS.BR (Melhoria do processo de software Brasileiro) e o mais cobiado pelas empresas brasileiras, o CMMI, que foi utilizado nesse trabalho. O CMMI foi escolhido para fazer parte deste trabalho, por ser uma norma internacional e por ser cobiado pelas empresas no mundo todo. Ele divide a engenharia de requisitos em duas reas de processo: A rea de processo de gerenciamento de requisitos e a rea de processo de desenvolvimento de requisitos. Cada uma destas reas de processo possui um objetivo especfico e uma srie de prticas especficas, consideradas pelo CMMI como as melhores prticas para se ter um processo de engenharia de requisitos de boa qualidade. Contudo, no se pode garantir que uma empresa que utiliza de forma plena todas as prticas especficas de engenharia de requisitos do CMMI ter um processo eficiente. Apenas pode-se garantir que a empresa estar com seu processo de engenharia de requisitos adequado com o modelo CMMI. Isso porque, em um ambiente empresarial existem algumas variveis no controlveis como, por exemplo, as diferentes personalidades humanas, que no garantem o funcionamento de forma eficiente desse processo em uma empresa. Por isso que o conhecimento emprico importante, pois s ele pode provar que um modelo ou uma teoria sero adequados para uma empresa. O conhecimento emprico dos processos da engenharia de software se encaixa na engenharia de software experimental, pois ela um estudo emprico sobre a prpria engenharia de software que oferece um modelo sistemtico, disciplinado, computvel e controlado para avaliao da atividade humana (TRAVASSOS, 2002). Com isso, pode-se ter um controle dos objetos e instrumentao, permitindo tirar uma concluso mais geral, permitindo ainda realizar anlises estatsticas, utilizando mtodos de teste de hipteses (WOHLIN et

al. ,2000). Isso tudo feito atravs da realizao de experimentos nos processos da engenharia de software nos ambientes organizacionais. Um experimento deve ser tratado como um processo da formulao ou verificao de uma teoria. Para que o processo oferea os resultados vlidos, ele deve ser propriamente organizado e controlado. Geralmente o experimento dividido em cinco fases, que aparecem em momentos diferentes no experimento, so elas: a definio, o planejamento, a execuo, a anlise e o empacotamento do estudo. Em face de estas informaes, este trabalho realizou um experimento, que caracterizou e comparou o processo de engenharia de requisitos dos projetos de integrao de uma empresa de tecnologia da informao do Recife com as prticas especficas das reas de processo da engenharia de requisitos exigidas pelo CMMI. 1.1 MOTIVAO 1.1.1 MOTIVAO DE MERCADO Uma grande quantidade de projetos de software cancelada ou fracassa por no atenderem por completo as necessidades dos clientes. Uma Explicao simples para este fenmeno no existe, mas alguns trabalhos, tais como LEFFINGWELL e WIDRIG (2003), KOTONYA e SOMMERVILLE (1998) e do The Standish Group International apontam as deficincias nos requisitos dos sistemas como os principais motivos para os fracassos que ocorrem nos projetos de software. Tais afirmaes levaram alguns autores a considerar a Engenharia de Requisitos como uma das mais importantes disciplinas da Engenharia de Software. A importncia do processo da engenharia de requisitos aumenta ainda mais quando se trata de projetos de integrao entre sistemas de empresas distintas, pois alm de se preocupar com as necessidades dos clientes, o produto tem que atender aos requisitos dos sistemas integrantes. Por isso , importante realizar um experimento fora do ambiente acadmico nesses tipos de projetos. Um experimento deste tipo pode trazer uma grande ajuda para projetos futuros das

empresas, trazendo melhorias de processos que podem se traduzir em uma diminuio de tempo e custos. 1.1.2 MOTIVAO TCNICA O estudo de engenharia de software experimental pode ajudar as empresas de tecnologia da informao a obterem uma caracterizao de um ou mais processos da empresa. Aps o conhecimento emprico do processo possvel apontar os pontos falhos e propor possveis melhorias no processo. Isso tem uma grande importncia para as empresas, porque no mundo globalizado em que a competio acirrada conviver com processos engessados sem saber se eles realmente podem levar uma empresa a ter prejuzos que podem ser identificados e melhorados a partir dos conhecimentos empricos. 1.2 PROBLEMA O mercado cada vez mais competitivo e acirrado tem levado as empresas de tecnologia da informao a buscar a excelncia em seus processos para oferecer sempre um melhor produto aos seus clientes. Geralmente essa busca por excelncia leva as empresas a apostarem em processos novos e nem sempre adequados as suas necessidades. O conhecimento emprico, por outro lado, tem o poder de provar a teoria, ajudando a tomar as decises, escolhendo o processo mais acertado para o seu perfil. Outro ponto problemtico no desenvolvimento de software, o processo de levantamento de requisitos, tambm conhecido como engenharia de requisitos; que no vem sendo usado corretamente pela maioria das empresas de desenvolvimento de software. A partir dessas afirmaes a engenharia de software experimental pode ajudar essas empresas a conseguir um feedback do seu processo de engenharia de requisitos, comparando o seu processo atual com os processos tericos propostos, trazendo para a empresa uma caracterizao desse processo e fornecendo informaes necessrias para que ela possa tomar as decises necessrias e melhorar o seu processo.

1.2.1 OBJETIVO GERAL Realizar um experimento em alguns projetos de integrao realizados em uma empresa de Tecnologia da Informao, com o foco na engenharia de requisitos, possibilitando a empresa obter uma caracterizao de sua estrutura atual em relao engenharia de requisitos. Propor, ainda, uma comparao com as prticas especficas de engenharia de requisitos proposta pelo CMMI (do ingls, Capability Maturity Model Integration). Verificar os pontos fortes e propor melhorias no processo de engenharia de requisitos. 1.2.2 OBJETIVOS ESPECFICOS Desenvolver procedimentos e protocolos de engenharia de software experimental para caracterizao da engenharia de requisitos nas empresas. Realizar um mtodo de comparao entre as prticas de engenharia de requisitos da empresa com as prticas especficas do CMMI em relao engenharia de software experimental. Propor melhorias no processo de engenharia de requisitos das empresas a partir dos estudos experimentais. 1.3 JUSTIFICATIVA A constatao de PARKER (2000) e RANGER (2001) que existe uma quantidade significativa de sistemas de informao falhos, sendo que, na maioria dos casos, essa falha por conta do no atendimento das expectativas s necessidades reais dos usurios. Alm disso, segundo SOMMERVILLE e SAWYER (1999) e PRESSMAN (2006) a etapa de elicitao de requisitos no pode ser caracterizada como uma tarefa trivial, conforme aparece em um primeiro momento.

Assin, surge a necessidade de instrumentos mais satisfatrios e que tornem mais confivel e segura esta atividade. Outro ponto a insatisfao dos usurios em relao ao aumento dos

custos, citado por DE BORTOLI e PRICE (2000). E tambm, o desentendimento com os desenvolvedores devido a realizao de atividades desnecessrias ou at mesmo duplicadas, levando ao aumento da tarefa de manuteno. MACEDO e LEITE (1999) afirmam que as vantagens produzidas com uma boa definio de requisitos so reais, pois diminuem a quantidade de alteraes, diminuindo os custos e aumentando a possibilidade de se cumprir prazos e os riscos de insatisfao dos clientes com as aplicaes de software. DAVIS (1982) muito antes de MACEDO e LEITE (1999) afirmava que o principal objetivo da elicitao de requisitos a obteno dos requisitos dos usurios adequados s necessidades dos usurios para poder gerar sistemas compatveis com o esperado. A confirmao do uso da engenharia de requisitos de uma forma correta poder ser feita atravs de uma caracterizao dela, utilizando experimentos. FLEMING (2003) usou as suas experincias empricas para corroborar com a afirmao de que a etapa de elicitao se caracteriza como um dos maiores problemas do processo de desenvolvimento de software. Essa afirmao foi relacionada ao fato da dificuldade no entendimento dos usurios, pois eles possuem uma viso restrita dos seus prprios processos. Com isso ele conseguiu propor a seguinte sada: um conhecimento amplo dos processos de negcio afetados pelo sistema a ser desenvolvido contornaria esse problema e geraria um produto mais satisfatrio. 1.4 CONTRIBUIES Um estudo sobre engenharia de software experimental e sobre engenharia de requisitos.

Um experimento em alguns projetos de integrao de uma empresa de Tecnologia da Informao com foco na engenharia de requisitos, possibilitando uma possvel melhoria nos processos destes tipos de projeto na prpria empresa. Uma metodologia de caracterizao do processo de engenharia de requisitos, utilizando engenharia de software experimental. 1.5 ESTRUTURA DA DISSERTAO O presente trabalho est estruturado em um conjunto de captulos. Neste sentido, esta seo apresenta de forma resumida a seguinte lgica de organizao geral do documento: No Capitulo 1, feita uma breve introduo e realizada uma apresentao inicial do problema de pesquisa com justificativa da relevncia do tema em questo, exposio dos objetivos almejados com o trabalho e da lgica de estruturao geral do documento; No Captulo 2, apresentada uma reviso da literatura relacionada aos principais conceitos da engenharia de requisitos e da engenharia de software experimental; No Captulo 3, apresentado o estudo experimental como ele foi realizado e mostrado os seus resultados; No Captulo 4, so retomados os principais pontos trabalhados durante a pesquisa, apresentadas as limitaes e concluses sobre a pesquisa. As oportunidades de trabalhos futuros tambm so apresentadas nesse captulo final.

10

2 REVISO BIBLIOGRFICA
2.1 ENGENHARIA DE REQUISITOS A Engenharia de requisitos origina-se da necessidade que os profissionais que constroem software tm em atender as necessidades dos clientes e usurios. Se existe um problema possvel de ser entendido e se esta soluo apresentada ao cliente, isto ser timo, pois o cliente ter seu problema resolvido. Para tanto, preciso entender a necessidade do usurio e transform-la em um software. Portanto, pode-se dizer que a necessidade do cliente o problema operacional ou de negcio que precisa ser resolvido. Ela dever englobar todos os requisitos que definem a soluo proposta para um determinado problema e empacotar de uma forma que estes requisitos formem uma definio concisa e clara para que possam ser usada tanto pelos engenheiros de software que iro desenvolver o software, como uma documentao e um guia, quanto aos clientes que esto com o problema para que eles consigam entender a proposta do software e poder analisar se a soluo proposta atender as suas necessidades. Ainda em relao engenharia de requisitos pode-se afirmar que ela preocupa-se com a elicitao, anlise, especificao e como ser realizada a validao do software, ou seja, nessa etapa que se inicia o processo de entendimento do problema que o software a ser construdo procura resolver e definem-se as funcionalidades que o mesmo dever ter. Alm disso, define-se a metodologia para a verificao do software no final do seu desenvolvimento para que ele atenda as necessidades do cliente. Por tudo isso, a engenharia de requisitos fundamental no processo de desenvolvimento de software, uma falha nesta etapa poder causar um efeito cascata que culminar com um software de baixa qualidade. Atravs da literatura podemos retirar algumas definies da engenharia de requisitos, como: o processo de descobrir, analisar, documentar e verificar servios fornecidos pelo sistema e as suas restries operacionais (SOMMERVILLE,

11

2008); O processo de engenharia de requisitos de software envolve a traduo de informao de uma forma para outra (WALIA; CARVER, 2009). Segundo PRESSMAN (2006) a engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vo trabalhar para resolver. Essa etapa importante, porque precisamos primeiramente entender o problema para poder desenvolver o software que atenda a necessidade dos clientes. Ele ainda relata que os responsveis por essa etapa so engenheiros de software que podem estar no papel de engenheiros de sistema ou analistas, dependendo da empresa. Segundo SOMMERVILLE (2008) a engenharia de requisitos est relacionada com a definio do que o sistema deve fazer suas propriedades emergentes desejveis e essenciais e suas restries quanto operao do sistema e quanto ao processo de desenvolvimento do software. um processo de comunicao entre os clientes e os usurios de software e os desenvolvedores. Por tudo isso a engenharia de requisitos um dos processos do desenvolvimento de requisitos mais importante e problemtico. Tanto importante e problemtico que SOMMERVILLE (2008) afirmou que talvez o maior problema que se enfrenta no desenvolvimento de grandes e complexos sistemas de software o da engenharia de requisitos. Uma vez que nela que se encontra a definio dos servios fornecidos pelo sistema e as restries operacionais. Em outras palavras, segundo o prprio SOMMERVILLE (2008), pode-se pensar na engenharia de requisitos como o processo de comunicao entre os clientes e os usurios de software e os desenvolvedores de software. Esta comunicao no uma tarefa to fcil, visto que as pessoas tm entendimentos diferentes das mesmas coisas. Com isso surgem algumas dificuldades que podem ser apresentados nesta fase, tambm conhecida como elicitao de requisitos, do desenvolvimento de software. O problema mais comum de acontecer nesta fase o cliente no conseguir explicitar bem a sua necessidade e o entendimento do requisito no ser bem feito, podendo acarretar a construo de um software que no atende ao desejo do cliente.

12

Outros problemas podem ocorrer nesta fase, como escrita dos requisitos no funcionais, pois eles devem ser escritos cuidadosamente para que no fiquem conflitantes. Um exemplo de conflitos de requisitos que se pode citar : O sistema dever usar 4MB no mximo de memria e ser desenvolvido. Se o sistema for desenvolvido em, que uma linguagem que usa muito recurso e que pode exigir mais de 4MB de memria isso ser conflitante com o uso restrito de memria. Um ponto problemtico na fase levantamento de requisitos o da m especificao de requisitos de domnio. Geralmente estes requisitos so redigidos na linguagem domnio da aplicao e geralmente os engenheiros de software tm dificuldade em compreend-las (SOMMERVILLE, 2008). Eles so provenientes do domnio da aplicao do sistema e refletem as caractersticas e restries do domnio, refletindo ainda os fundamentos do domnio da aplicao. Como problemas que se pode ter na especificao de requisitos pode-se apontar ainda a impreciso na especificao dos requisitos. Alm dos conflitos que se pode surgir, preciso ter cuidado com a ambigidade, pois natural que um desenvolvedor de sistemas interprete um requisito ambguo de modo a simplificar a sua implementao. O ideal que os requisitos de sistema sejam simplesmente descries do comportamento externo do sistema e suas restries operacionais. Eles no devem estar relacionados como o sistema pode ser projetado ou implementado. Outra questo a ser levada em considerao a interoperabilidade, pois a maioria dos sistemas de softwares desenvolvidos hoje em dia deve interagir com os outros sistemas j. Todos estes problemas e cuidados que se deve ter na fase da engenharia de requisitos aumentam consideravelmente quando se trata do desenvolvimento de sistemas crticos, porque ela passa a ser muito mais necessria nestes tipos de sistemas (SOMMERVILLE, 2008). Isso porque, nestes tipos de sistemas a confiabilidade exigida ainda mais que um sistema comum por conta da sua criticidade. Como exemplo de um sistema crtico pode-se citar o sistema de freio de um carro. O desenvolvimento de sistemas crticos precisam ser especificados dirigidos a risco. O processo envolve a compreenso dos riscos enfrentados do sistema, a descoberta das causas da origem e a gerao de requisitos para

13

gerenciar esses riscos. O processo composto pelos passos de identificao dos riscos, analise, classificao, decomposio dos riscos e avaliao e reduo dos riscos. 2.1.1 REQUISITOS DE SOFTWARE A palavra requisitos ser usada bastante ao longo desse trabalho, indicando uma necessidade do sistema. Para isso faz-se necessrio apresentar algumas definies encontradas na literatura, como: Um requisito define como uma aplicao de computador deve fazer para os seus usurios (KULAK, 2001). Apalavra requisitos representa uma condio ou capacidade

necessria para um usurio resolver determinado problema ou atingir um objetivo; ou ainda, uma condio ou capacidade que um sistema deve ter ou prover para satisfazer um contrato, padro, especificao ou outro documento formal imposto (DAVIS, 1982). o requisito definido como propriedades de um sistema que so responsveis pelo xito no ambiente em que ser utilizado (GOGUEN; JIROTKA, 1994). Um requisito de software uma propriedade que o sistema deve apresentar para resolver um problema real (SWEBOK, 2009). Os requisitos de um sistema so descries dos servios fornecidos pelo sistema e as suas restries operacionais, refletindo as necessidades dos clientes de um sistema que ajuda a resolver algum problema (SOMMERVILLE, 2008). Os requisitos de software so definidos durante os primeiros estgios do desenvolvimento de um sistema como uma especificao daquilo que deve ser implementado. Eles so descries de como o software deve se comportar ou das

14

propriedades e atributos do sistema. Eles podem ser restries do processo de desenvolvimento de um sistema (SOMMERVILLE e SAWYER, 1999). Os requisitos devem ser nicos, verificveis e testveis para minimizar ao mximo os erros. nicos, pois podero ser facilmente referenciados, verificveis e testveis, para no ocorrerem erros de entendimento. Eles devem ser completos que possibilite o entendimento dos diferentes leitores que eles devero abranger como os clientes e os desenvolvedores do sistema. Para resolver este problema de completude e para atender a mais de um tipo de leitores SOMMERVILE (2008) sugere que seja utilizado dois tipos distintos de requisitos, os requisitos de usurio e os requisitos de sistemas. GOTTESDIENER (2002) tambm faz essa separao em requisitos de usurio e requisitos do sistema. Para ele os requisitos de usurio constituem declaraes sobre as funes ou restries do sistema em alto nvel, devendo ser uma especificao consistente do comportamento externo do sistema. Por outro lado, os requisitos do sistema definem de maneira bem detalhada as funes e restries sob a tica do sistema, gerando uma especificao consistente e bem completa daquilo que o sistema deve executar. Ainda em relao aos requisitos, SOMMERVILLE (2008) afirma que os requisitos de usurios so declaraes em uma linguagem natural com diagramas, de quais servios so esperados do sistema e as restries sob as quais ele deve operar. Eles devero ser direcionados para os usurios (clientes) do sistema a ser desenvolvido. J os requisitos de sistema SOMMERVILLE (2008) afirma que eles definem, detalhadamente, as funes os servios e as restries operacionais do sistema. O documento de requisitos do sistema uma especificao funcional e deve ser preciso. Ele deve definir exatamente o que ser implementado. Esse documento dever ser direcionado para os desenvolvedores e pessoas que possuem um conhecimento em nvel de desenvolvimento.

15

Segundo MACEDO e LEITE (1999) e GILB (1999), os requisitos de software so necessidades tanto funcionais, que definem comportamentos e propriedades do sistema, quanto no funcionais, que definem as restries. Ou seja, so as definies dos quesitos de qualidade e restries operacionais ou do processo de desenvolvimento do sistema. Assim Podemos classificar os requisitos de sistema como funcionais, no funcionais e de domnio. Requisitos funcionais so declaraes de servios que o sistema deve fornecer, como o sistema deve reagir s entradas especificas e como o sistema deve se comportar em determinadas situaes. A especificao de requisitos funcionais deve ser completa e consistente. Completeza significa que todos os servios exigidos pelo usurio devem ser definidos. Consistente significa que os requisitos no devem ter definies contraditrias (SOMMERVILLE, 2008). Requisitos no funcionais correspondem s restries sobre os servios ou as funes fornecidas pelo sistema. Eles incluem restries de timing, processo e padro de desenvolvimento. Os requisitos no funcionais no esto relacionados diretamente a funes especficas do sistema. Eles podem estar relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espao de armazenamento. Eles so mais importantes que os requisitos funcionais individuais, pois os usurios do sistema em geral encontram meios de contornar uma funo do sistema que no atenda a suas necessidades, contudo, uma falha no atendimento de um requisito no funcional pode significar que todo o sistema intil. Um exemplo de uma falha no atendimento de requisito no funcional o de uma aeronave que no atende ao requisito no funcional de confiabilidade, isso inviabiliza a sua certificao de segurana e por conseqncia no ser usada. Os requisitos no funcionais no esto relacionados somente a sistema de software. Eles podem restringir o processo que deve ser usado para desenvolver o software, como padres de qualidade e ferramentas (SOMMERVILLE, 2008).

16

Os requisitos no funcionais surgem devido necessidade dos usurios, seja em relao a oramento restrito, poltica organizacional, necessidade de interoperabilidade com outros sistemas ou fatores externos. Requisitos de domnio derivam do domnio da aplicao do sistema e no das necessidades especificas dos usurios do sistema. Geralmente fazem referencia a conceitos de domnio. Podem gerar novos requisitos funcionais ou tambm restringi-los. (SOMMERVILLE, 2008). 2.1.2 PROCESSO DE ENGENHARIA DE REQUISTOS Processo da engenharia de requisitos tem como objetivo criar e manter o documento de requisitos do sistema. Ele inclui cinco subprocessos de alto nvel: estudo da viabilidade, obteno dos requisitos, especificao, validao e o gerenciamento dos requisitos (SOMMERVILLE, 2008). J segundo PRESSMAN (2006) os passos do processo de engenharia de requisitos, so a concepo, o levantamento, a elaborao e a validao, ele no cita a fase de estudo da viabilidade, mas cita a fase de concepo como o inicio de tudo. Uma preocupao mais especifica relacionada ao processo de engenharia de requisitos conseguir identificar com clareza a identificao dos interessados do sistema (PRESSMAN, 2006). SOMMERVILLE e SAWYER (1999) definem um interessado como quem quer se beneficie de modo direto e indireto do sistema que est sendo desenvolvido. Podemos identificar o gerente, clientes internos e internos, usurios finais, consultores, engenheiros de produto e de software e engenheiros de manuteno, entre outros. Cada interessado possui uma viso diferente do sistema. Os interessados do sistema podem tambm serem chamados de Stakholders. Segundo SUMMERVILLE (2008) o estudo da viabilidade o comeo do processo da engenharia de requisitos. Nessa etapa realizado um estudo que possui um conjunto preliminar de requisitos de negocio, um esboo da descrio do sistema e como ele pretende apoiar os processos de negocio da empresa. Os resultados desse estudo ficam em um relatrio, recomendando ou no o prosseguimento no processo de desenvolvimento do sistema. Nesse estudo devem

17

ser respondidas algumas questes. Abaixo descrevo trs das que podem ser usadas como ponto de start: O sistema contribui para os objetivos gerais da organizao? O sistema pode ser implementado com a tecnologia atual e dentro das restries de prazo e custo? O sistema pode ser integrado a outros sistemas? Aps estas repostas possvel que possam ser formuladas outras abrangendo o mesmo tema (negcio e viabilidade). Segundo PRESSMAN (2006) a maioria dos projetos comea quando uma necessidade de negocio identificada ou um mercado ou servio potencialmente novo descoberto, ou seja, o estudo da viabilidade no precisa ser feito, j que existe a necessidade. Na concepo do projeto os engenheiros de software fazem uma serie de perguntas livres de contexto aos clientes com a inteno de estabelecer um entendimento bsico do problema. A fase de Elicitao e anlise de requisitos onde os engenheiros de requisitos trabalham com os clientes e usurios finais para aprender sobre o domnio da aplicao e entender quais servios o sistema deve fornecer, o desempenho esperado e as restries. Nessa fase podemos mapear um processo que possui as seguintes etapas: obteno de requisitos, classificao e organizao dos requisitos, priorizao e negociao de requisitos e a documentao. Aps essas etapas aconselhvel que os requisitos sejam agrupados formando subsistemas (SUMMERVILLE, 2008). PRESSMAN (2006) usa a expresso de levantamento para essa fase, onde os engenheiros de software fazem perguntas para os clientes sobre os objetivos do sistema, o que precisa ser conseguido, como o sistema se encaixa e ser usado no dia a dia da empresa e dos usurios entrevistados. Nessa fase os engenheiros de software tem que tentar minimizar os problemas de escopo, de entendimento e de volatilidade dos requisitos. Existe uma grande dificuldade nessa etapa, pois os usurios do sistema freqentemente no sabem o que querem dele a no ser em termos gerais. Outra dificuldade a linguagem utilizada pelos usurios que geralmente so expressas

18

com seus prprios termos e conhecimentos implcitos de seu trabalho. Alm disso, existem outras variveis a serem levadas em considerao, como: A divergncia dos usurio em relao a necessidade e isso gera diferentes requisitos; fatores polticos que podem influenciar nos requisitos, como o pedido de pessoas com poder dentro da organizao, para aumentar o seu poder de influencia; as mudanas econmicas e de negcio que acontecem durante essa fase. A obteno de requisitos o processo que rene informaes sobre o sistema proposto e os sistemas existentes para que seja possvel obter os requisitos de usurio e de sistema com base nessas informaes. Durante essa fase as fontes de informaes so documentao, usurios e especificao de sistemas similares. As fontes de requisitos (usurios, domnio, sistemas similares) podem ser representadas como pontos de vista do sistema, e cada ponto de vista representa um subconjunto de requisitos de sistema. Os pontos de vista organizam o processo de elicitao e os prprios requisitos, usando pontos de vista. Um ponto forte da analise orientada a ponto de vista que ela reconhece varias perspectivas e fornece um framework para descobrir conflitos nos requisitos propostos por usurios diferentes. Os pontos de vista podem ser mapeados em trs tipos genricos: interao, indiretos e de domnio que fornecem trs tipos diferentes de requisitos. A forma mais usada para se obter os requisitos dos usurios atravs de entrevista, diante o qual so formuladas perguntas sobre o sistema a ser desenvolvido, pelos engenheiros de requisitos, as quais devem ser respondidas pelos usurios. As entrevistas podem ser feitas utilizando-se fichas com um conjunto de perguntas predefinidas ou de forma aberta e sem um roteiro definido. Outra forma de se descobrir requisitos de como as pessoas realmente trabalham a etnografia, que uma tcnica de observao usado para compreender requisitos sociais e organizacionais. Prototipagem a forma de se usar prottipos do sistema proposto para conseguir levantar mais alguns requisitos que estejam faltando. Tambm pode ser usada para validar requisitos.

19

Na Especificao ocorrem as descries em linguagem natural de tudo que foi levantado. Podem ser usadas algumas tcnicas para isso, como usar cenrios onde feito um esboo de interao entre usurio e sistema e durante a elicitao vo sendo adicionados detalhes, criando uma descrio completa. A forma mais conhecida de se especificar requisitos usando cenrios atravs de casos de uso conforme sugerido por (FOWLER e SCOTT, 1997) um caso de uso engloba um conjunto de cenrios, sendo cada cenrio um encadeamento isolado ao longo do caso de uso onde existir um cenrio para a interao normal e outra para cada exceo (SOMMERVILLE, 2008). Especificao pode ser um modelo escrito, um modelo grfico, um modelo matemtico formal, uma coleo de cenrios de uso, um prottipo ou qualquer combinao desses elementos (PRESSMAN, 2006). PRESSMAN (2006) cita ainda essa fase como a fase de elaborao, na qual produzido um documento tcnico refinado das funes, caractersticas e restries do sistema. Geralmente utilizam-se na elaborao modelos de desenvolvimento. Por no ser fcil de negociar requisitos com os clientes, pois geralmente os clientes pedem mais do que pode ser conseguido, considerando os recursos limitados do negocio. Os engenheiros de software tem utilizado modelos para obter uma maior facilidade de negociao com os clientes. Utilizar modelos ajuda tambm a verificar requisitos conflitantes, que so sugeridos pelos usurios. Tambm fica mais fcil a Validao dos requisitos junto com os usurios. O processo de levantamento de requisitos visa elaborao de perguntas e respostas e til na concepo dos requisitos, mas no uma abordagem que tenha tido sucesso para levantamento de requisitos mais detalhados. Essa abordagem de perguntas pr-elaboradas deve ser usada apenas para o primeiro encontro, e depois substituda por uma forma de levantamento de requisitos que combine elementos de soluo de problemas, elaborao, negociao e especificao. Uma abordagem desse tipo a coleta colaborativa de requisitos, onde uma equipe de interessados e desenvolvedores trabalha em conjunto para identificar o problema, propor elementos de soluo e negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo (ZAHNISHER, 1990).

20

Uma tcnica que traduz a necessidade do cliente para requisitos tcnicos do software a IFQ (implantao da funo de qualidade, em ingls QFD Quality function deployment). Segundo ZULTNER (1992) ela concentra-se em maximizar a satisfao do cliente a partir do processo de engenharia de software. Para conseguir isso a IFQ enfatiza o entendimento do que tem valor para o cliente e depois implanta esses valores por meio dos processos de engenharia. A IFQ identifica trs tipos de requisitos: requisitos normais, que refletem os objetos e metas estabelecidos para um produto ou sistema durante as reunies com o cliente; requisitos esperados, que so requisitos que esto implcitos no produto ou no sistema, e podem ser to fundamentais que o cliente no se refere a ele explicitamente, e sua ausncia causaria uma insatisfao significativa; e requisitos excitantes, refletem caractersticas que vo alem da expectativa do cliente, mostram ser muito satisfatrio quando presentes. Podemos usar modelos no processo de analise para obter uma compreenso maior do sistema a ser desenvolvido. Como modelos usados existem o modelo de contexto que define os limites do sistema o modelo de comportamento que descrevem o comportamento geral do sistema, o modelo de fluxo de dados que mostra como os dados sero processados o modelo de mquina de estado que mostra como o sistema responde aos eventos internos ou externos, o modelo de dados que possui as definies de forma lgica dos dados que sero processados pelo sistema s usadas a sistemas que possuem banco de dados o que acontece com a maioria dos sistemas nos dias atuais e o modelo de objetos que so usados nos sistemas orientados a objetos e representam como as entidades do sistema podem ser classificadas e compostas por outras entidades, no muito usual para os usurios finais, porque os consideram difceis de ler. O objetivo da modelagem de analise criar uma variedade de representaes que mostram os requisitos de software quanto informao, funo e comportamento. Para tanto duas diferentes filosofias de modelagem podem ser aplicadas: a anlise estruturada e a orientada a objeto. A estruturada considera o software um transformador de informao. Ela ajuda o engenheiro de software na identificao dos objetos de dados, seus relacionamentos e o modo pelo qual esses

21

objetos de dados so transformados medida que fluem atravs de funes de processamento de software. A anlise orientada a objetos examina um domnio de problema definido como um conjunto de casos de uso em um esforo para extrais classes que definam um problema. Cada classe tem um conjunto de atributos e operaes. Classes esto relacionadas entre si por uma variedade de modos e so modeladas por meio de diagrama UML (do ingls, Unified Modeling Language). O modelo de anlise composto de quatro elementos de modelagem: modelos baseados em cenrio, modelos de fluxo, modelo baseado em classe e modelo comportamental (PRESSMAN, 2006). O modelo de anlise fornece uma descrio dos domnios informacional, funcional e comportamental necessrios a um sistema baseado em computador. Podemos ter diferentes modos de representao que foram a equipe de software a considerar os requisitos de diferentes pontos de vista. Esses modos de representao so citados por PRESSMAN (2006), como quatro elementos: baseados em cenrio, classe, elementos comportamentais e orientados a fluxo. Nos elementos baseados em cenrio o sistema descrito do ponto de vista do usurio, usando uma abordagem com base em cenrio.Cenrios de usurios: a medida que os requisitos so coletados uma viso geral das funes e caractersticas do sistema comeam a se materializar. Os cenrios freqentemente chamados de casos de uso (JACOBSON, 1992) fornecem uma descrio de como o sistema ser usado. Para COCKBURN (2001) um caso de uso se refere a um contrato, que descreve o comportamento do sistema sob varias condies na qual o sistema responde a uma suscitao de um dos seus interessados. Um caso de uso conta uma histria estilizada sobre como um usurio final interagi com o sistema sob o conjunto especifico de circunstancia (PRESSMAN, 2006). Os casos de uso no so muito eficazes para elicitar restries ou requisitos de negcio e requisitos no funcionais de alto nvel com base nos pontos de vista indiretos ou para obter requisitos de domnio. Para deixar os requisitos mais ricos podemos usar diagramas de seqncia, que adicionam informaes aos casos de uso. Eles mostram os agentes envolvidos

22

na interao, os objetos com os quais interagem e as operaes associadas a esses objetos. Elementos baseados em classe: cada cenrio de uso implica em um conjunto de objetos que so manipulados medida que um ator (usurio) interage com o sistema. Esses objetos so caracterizados em classe. Essas classes so uma coleo de coisas que tem atributos semelhantes e comportamento comum (PRESSMAN, 2006). Elementos comportamentais: o comportamento de um sistema baseado em computador, pode ter um profundo efeito sobre o projeto que escolhido e a abordagem de implementao que aplicada. Podemos usar o diagrama de estados para representar o comportamento do sistema pela representao de seus estados e dos eventos que causam a modificao do estado do sistema (PRESSMAN, 2006). Elementos orientados a fluxo: a informao transformada a medida que ela flui por um sistema baseado em computador. Podemos criar um modelo de fluxo para qualquer sistema baseado em computador, independentemente do tamanho da complexidade. Reconhecimento de diversos pontos de vista: Como existem muitos interessados diferentes, os requisitos do sistema sero explorados a partir dos pontos de vista diferentes. A medida que a informao de vrios pontos de vista coletada, os requisitos emergentes podem ser inconsistentes ou conflitantes. O trabalho do engenheiro de requisitos categorizar todas estas informaes de modo a permitir que os tomadores de deciso, escolham um conjunto de requisitos do sistema internamente consistente (PRESSMAN, 2006). Todas essas formas devero ser validadas com os clientes. Esse estudo no ir adiantar nada se aps tudo isso o engenheiro de software no obtiver a Validao dos requisitos junto ao usurio. A validao de requisitos dedica-se a mostrar que os requisitos realmente definem o sistema que o usurio deseja. importante para achar erros nos documentos de requisitos, pois documentos com erros levam a um custo excessivo de retrabalho quando descobertos no desenvolvimento ou depois que o sistema est em operao. O custo da correo

23

de problemas de requisitos muito maior do que as correes de erros de projeto e de codificao. A razo disso que uma mudana de requisitos significa mudana no projeto, na implantao e que o sistema deve ser testado novamente. Durante a validao deve-se realizar verificaes do tipo validade, consistncia, realismo, completeza e facilidade de verificao (SUMMERVILLE, 2008). A validao de requisitos examina a especificao para garantir que todos os requisitos do software tenham sido declarados de modo no ambguo que as inconsistncias, omisses e erros tenham sido detectados e corrigidos e que os produtos de trabalho estejam de acordo com as normas estabelecidas para o processo, projeto e produto (PRESSMAN, 2006). Como a sada da engenharia de requisitos o documento de requisitos, importante que exista um Gerenciamento de requisitos. Como o problema no pode ser definido totalmente, os requisitos tendem a ser incompletos. Durante o processo de software, os entendimentos dos usurios mudam constantemente. Com isso os requisitos devem evoluir. Outro ponto que depois da entrega outros requisitos iro surgir. O gerenciamento de requisitos um processo para compreender e controlar as mudanas dos requisitos. Com relao a mudanas podemos ter dois tipos de requisitos os relativamente estveis, que so geralmente derivadas da atividade da organizao e que se relacionam direto com o domnio e que dificilmente mudam. E os volteis que tem a probabilidade bem maior de mudar, inclusive durante o desenvolvimento do sistema. Segundo EL EMAM (1997), podemos identificar alguns problemas relacionados Gerncia de Requisitos como a dificuldade de elicitar claramente as mudanas nos requisitos, a falta de habilidade para chegar a um consenso sobre as mudanas chave para os usurios, a falta de habilidade para manter o documento de requisitos consistente e a Falta de habilidade para estimar adequadamente os recursos necessrios para implementar as mudanas nos requisitos. No Processo de Gerncia de Requisitos Algumas atividades so executadas, entre elas Receber as solicitaes de alterao de requisitos, Registrar novos requisitos, Analisar impacto da mudana de requisito, Elaborar relatrio de impacto, Notificar os envolvidos e Coletar mtricas. O grupo de engenharia de

24

requisitos recebe as solicitaes de alterao de requisitos, ou por formulrio padronizado, ou por meio de um sistema de solicitao de demandas. Isso mostra que novos requisitos devem ser recebidos formalmente, seja por formulrio padronizado, ou por meio de controle sistemtico. Neste ponto se d o registro dos novos requisitos. Posteriormente, uma anlise criteriosa deve ser conduzida para avaliar o impacto do requisito a ser includo, alterado ou excludo sobre cada um dos seus requisitos relacionados, os quais podem ser identificados por meio das matrizes de rastreabilidade (a ser estudado posteriormente). Caso o impacto seja significativo, os requisitos devem ser revistos. importante a elaborao de um relatrio de impacto, onde deve ser mantido um histrico de alteraes para cada requisito, permitindo uma viso cronolgica das principais mudanas nos requisitos. O conjunto de pessoas para as quais pode haver um impacto devido alterao de requisitos (alterao, incluso ou excluso de requisitos) deve ser notificado. Por fim, as mtricas devem ser utilizadas e coletadas periodicamente para o acompanhamento das atividades de Gerncia de Requisitos (SOMMERVILLE, 2008). A gesto de requisitos um conjunto de atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificaes de requisitos em qualquer poca, medida que o projeto prossegue. Ela comea com a identificao. A cada requisito atribudo um identificador nico. Aps a identificao deve ser feita uma tabela de rastreamento que mostra como os requisitos se relacionam a um ou mais aspectos do sistema ou do seu ambiente. Podemos destacar as seguintes tabelas de rastreamento: tabela de rastreamento de caracterstica, tabela de rastreamento de fontes, tabela de rastreamento de dependncia, tabela de rastreamento de subsistema e tabela de rastreamento de interface (PRESSMAN, 2006). 2.1.3 ENGENHARIA DE REQUISTOS NO CMMI O CMMI formado pelas melhores prticas relacionadas ao desenvolvimento e manuteno de sistemas de informao, fornecendo um suporte que engloba todo o ciclo de vida dos produtos da concepo a sua entrega e manuteno. Por isso, e tambm por ser uma das certificaes mais cobiadas pelas empresas brasileiras

25

que o CMMI foi o modelo terico escolhido para ser utilizado neste trabalho. Esta seo mostra uma breve introduo do CMMI em relao a engenharia de requisitos com suas prticas especficas. Para o CMMI a Gesto de Requisitos estabelece um entendimento comum entre o cliente e o fornecedor do servio em relao aos requisitos que sero atendidos no sistema a ser desenvolvido. A Gesto de Requisitos tem como propsito gerenciar os requisitos dos sistemas e identificar, se existirem, as inconsistncias entre os requisitos e os artefatos gerados para o sistema. O CMMI tambm cita a importncia da reviso dos fornecedores de requisitos para que no haja falha de entendimento de requisitos. Para o CMMI documentar as mudanas de requisitos e manter o relacionamento entre requisitos, arquitetura e implementao muito importante. Para contextualizar, abaixo, na Tabela 2 so apresentados os nveis de maturidade presentes no CMMI.

Tabela 2: Nveis de Maturidade do CMMI

Nvel 1 Inicial 2 Gerenciado

Descrio Processo imprevisvel pobremente controlado e reativo Gerenciado Quantitativamente: Processo caracterizado para o projeto e muitas vezes reativo

3 Definido 4

Processo caracterizado para a organizao e proativo

Gerenciado Processo medido e controlado

qualitativamente 5 Otimizao Foco na melhoria do processo

26

O nvel um tambm conhecido como o nvel inicial caracterizado como um processo de desenvolvimento de software ad hoc e ocasionalmente pode ser catico. Nesse nvel poucos processos esto definidos na empresa e o sucesso depede dos esforos individuais. No nvel dois, os processos bsicos de gerenciamento esto estabelecidos para se obter os controles do custo, cronogramas e funcionalidade. A disciplina necessria dos processos permite repetir o sucesso em outros projetos com aplicaes similares. No nvel trs, o processo de software para as atividades de gerenciamento e de engenharia documentado, padronizado e integrado em um processo padro de software para a organizao. J no nvel quatro, medies detalhadas do processo de software e da qualidade do produto so coletadas. Tanto o processo de software quanto o produto de software so quantitativamente entendidos e controlados. Por fim, no nvel cinco, que o nvel de maturidade otimizado, o processo de melhoria continua e feito atravs de feedback quantitativo dos processos e das aplicaes de novas idias e tecnologias. Cada nvel de maturidade do CMMI possui reas de processo formadas por objetivos especficos e genricos que, por sua vez, tambm possuem suas prticas especficas e genricas como mostrado na Figura 2.

27

Figura 2: Estrutura do CMMI

A engenharia de requisitos se encaixa na estrutura do CMMI como rea de processo. Ela est presente em dois nveis de maturidade do CMMI. No nvel 2 (Gerenciado) encontra-se a rea de processo Gerenciamento de Requisitos (Requirements Management - REQM) e no nvel de maturidade 3 (Definido) encontra-se a rea de processo Desenvolvimento de Requisitos (Requirements Development - RD) (http://www.software-quality-assurance.org). A rea de processo de Gerenciamento de Requisitos, como citado anteriormente, exigida pelo nvel 2 do CMMI. O objetivo do Gerenciamento de Requisitos gerenciar os requisitos dos produtos do projeto e os seus componentes e identificar inconsistncias entre esses requisitos e os planos do projeto e produtos de trabalho. A Tabela 2 apresenta as prticas especficas da rea de processo de gerenciamento de requisitos.

Tabela 3: Prticas especficas das reas de processo de Gerenciamento de Requisitos.

rea de processo (AP): Gerenciamento de Requisitos REQM Objetivo Especfico (OE): Gerenciar Requisitos Prticas especficas (PE) PE1 PE2 PE3 PE4 PE5 Obter um entendimento dos requisitos. Obter comprometimento com requisitos. Gerenciar mudanas de requisitos. Manter rastreabilidade bidirecional de requisitos. Identificar inconsistncias entre artefatos do projeto e requisitos.

28

Como visto na tabela 2 a rea de processo de gerenciamento de requisitos composta pelas seguintes prticas especficas:

Prtica especfica 1 - obter entendimento dos requisitos: A fim de evitar problemas futuros, so designados as fontes oficiais que sero responsveis por disponibilizar e receber os requisitos. A prtica especfica do entendimento dos requisitos trata do estabelecimento do uso de um mecanismo que obtm, com o cliente, o significado do requisito. Ele composto por atividades que captam os requisitos para assegurar que sua compreenso foi atingida. Essa prtica tambm estabelece os critrios que evitam o crescimento indistinto dos mesmos. Para essa prtica so utilizados como produtos de trabalho: 1. Lista de critrios para a apropriada distino dos fornecedores dos requisitos. 2. Critrios para avaliao e aceitao dos requisitos. 3. Resultados das anlises em relao aos critrios. 4. Um conjunto de requisitos acordados.

Prtica especfica 2 - obter comprometimento com os requisitos: Quando so formadas as equipes, o compromisso com os requisitos necessrio, assegurando que as mudanas ocorridas ao longo do tempo sejam disponibilizadas para todos os envolvidos. Essa prtica trata de acordos e compromissos entre os profissionais envolvidos na execuo das atividades necessrias para implementao dos requisitos. Para essa prtica so utilizados como produtos de trabalho: 1. Analisar os impactos dos requisitos.

29

2. Compromissos documentados com os requisitos e com as mudanas de requisitos.

Prtica especfica 3 - gerenciar mudanas nos requisitos: Gerenciar as mudanas nos requisitos durante a evoluo do projeto importante para manter os requisitos atualizados. Pois eles podem mudar devido a vrios fatores, inclusive fatores no previstos, como por exemplo, a exigncia de atendimento a uma nova legislao. Estas mudanas devem ser controladas de forma que permita a avaliao dos impactos que podem ocorrer em todo o projeto. Ela tambm possibilita, aos gerentes, rastrear as medidas de volatilidade de requisitos para julgar a necessidade de novos controles ou, fazer a reviso dos existentes. Para essa prtica so utilizados como produtos de trabalho: 1. Status de requisitos. 2. Banco de dados de requisitos. 3. Banco de dados de decises de requisitos. J as subprticas utilizadas so as seguintes: 1. Documentar todos os requisitos e mudanas de requisitos do projeto. 2. Manter um histrico de mudanas de requisitos com os fundamentos lgicos das mudanas. 3. Manter o histrico de mudanas ajuda a rastrear a volatilidade dos requisitos. 4. Avaliar o impacto das mudanas de requisitos do ponto de vista dos stackeholders relevantes. 5. Tornar disponveis ao projeto os dados de requisitos e de mudanas.

30

Prtica especfica 4 - manter rastreabilidade bidirecional dos requisitos: Esta prtica importante, porque a partir de uma rastreabilidade bidirecional bem feita possvel rastrear os requisitos at sua origem e retornar a sua condio atual, por exemplo, indicando qual ser o impacto das mudanas neles e como ser refletida no projeto. Para essa prtica so utilizados como produtos de trabalho: 1. Matriz de rastreabilidade de requisitos. 2. Sistema de rastreamento de requisitos. J as subprticas usadas so as seguintes: 1. Manter a rastreabilidade dos requisitos para assegurar que a origem do menor nvel de requisito (derivado) esteja documentada. 2. Manter a rastreabilidade de um requisito com seus requisitos derivados e com sua alocao a funes, interfaces, pessoas, processos e produtos de trabalho. 3. Gerar a matriz de rastreabilidade de requisitos.

Prtica especfica 5 - identificar inconsistncias entre o trabalho do projeto e os requisitos: Essa prtica usada para descobrir as inconsistncias entre os requisitos e os planos do projeto e produtos de trabalho. Isso permite iniciar aes corretivas para no desviar o foco do requisito em questo. Para essa prtica utilizado como produto de trabalho:

31

1. documentao de inconsistncias incluindo fontes, condies e justificativas e aes corretivas. J as subprticas usadas so as seguintes: 1. Revisar os planos de projeto, atividades e produtos de trabalho visando consistncia com os requisitos e com as mudanas neles realizadas. 2. Identificar a origem das inconsistncias e fundamento lgico. 3. Identificar mudanas que necessitam ser feitas nos planos e produtos de trabalho resultantes das mudanas na baseline de requisitos. 4. Iniciar as aes corretivas. Alm da rea de processo de gerenciamento existe tambm a rea de processo de desenvolvimento de Requisitos, que como citado anteriormente, exigida pelo nvel trs do CMMI. Essa rea de processo tem por objetivo desenvolver os requisitos do cliente. A Tabela 3 abaixo apresenta a rea de processo e as suas prticas especficas.

Tabela 4: Prticas especficas das reas de processo de Desenvolvimento de Requisitos.

rea de processo (AP): Desenvolvimento de Requisitos RD Objetivo Especfico (OE): Desenvolver Requisitos do Cliente Prticas especficas (PE) PE01 PE02 PE03 Coletar as necessidades dos stakeholders. Elicitar as necessidades. Desenvolver os Requisitos dos clientes.

Objetivo Especfico (OE): Desenvolver requisitos do produto Prticas especficas (PE)

32

PE04 PE05 PE06

Estabelecer os requisitos dos produtos e seus componentes. Alocar os requisitos dos componentes dos produtos. Identificar os requisitos de interfaces.

Objetivo Especfico (OE): Desenvolver requisitos do produto Prticas especficas (PE) PE07 PE08 PE09 PE10 PE11 Estabelecer conceitos operacionais e cenrios. Estabelecer uma definio das funcionalidades requeridas. Analisar os requisitos. Analisar os requisitos para avaliao. Validar os requisitos.

Como pode-se observar na tabela 3, a rea de processo de desenvolvimento de requisitos diferentemente da a rea de processo de gerenciamento de requisitos dividida por trs objetivos especficos, onde cada objetivo especfico possui suas prticas especficas. Os objetivos especficos e suas prticas especficas da rea de processo de desenvolvimento de requisitos so: Objetivo especfico 1 - Desenvolver os Requisitos de Cliente: O objetivo especfico de Desenvolver os Requisitos de Cliente utilizado para coletar as necessidades, expectativas, restries e interfaces dos stakeholders e traduzi-las em requisitos de cliente. Ele dividido em duas prticas especficas que so: Prtica especfica 1.1 Levantar os requisitos:

33

Essa prtica especfica prope realizar o levantamento das necessidades, expectativas, restries e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai alm da coleta de requisitos, incluindo a identificao adicional e pr-ativa de requisitos no fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam enderear as vrias atividades do ciclo de vida do produto e seus impactos no produto. Na tabela 3 essa prtica est exibida como as prticas especficas PE01 e PE02. Ela possui uma nica subprtica, que : 1. Envolver os stakeholders relevantes usando mtodos para levantamento de necessidades, expectativas, restries e interfaces externas.

Pratica especfica 1.2 - Desenvolver os Requisitos de Cliente: Essa prtica especfica transforma as necessidades, expectativas, restries

e interfaces dos stakeholders em requisitos do cliente. Essa prtica possui duas subprticas: 1. Traduzir as necessidades, expectativas, restries stakeholders em requisitos do cliente documentados; 2. Definir restries de verificao e validao. e interfaces dos

Objetivo especfico 2 - Desenvolver os Requisitos do produto: O objetivo especfico de Desenvolver os Requisitos do produto utilizado

para refinar os requisitos dos clientes e transform-los em requisitos do produto e dos componentes dos produtos. Ele dividido em trs prticas especficas que so: Pratica especfica 2.1 - Estabelecer os Requisitos de Produto e de Componentes de Produto: Essa prtica especfica estabelece e mantm os requisitos do produto e dos componentes de produto, que so baseados nos requisitos do cliente. Ela possui duas subprticas:

34

1. Desenvolver os requisitos em termos tcnicos, necessrios ao design do produto e dos componentes de produto. Desenvolver os requisitos de arquitetura endereando qualidades e desempenho crticos do produto necessrios ao design da arquitetura do produto; 2. Derivar os requisitos que resultam das decises de design.

Pratica especfica 2.2 - Alocar os Requisitos de Componentes de Produto: Essa prtica especfica prope alocar os requisitos de cada componente do

produto. Ela possui trs subprticas: 1. Alocar requisitos a funes; 2. Alocar requisitos a componentes de produto; 3. Alocar restries de design a componentes de produto.

Pratica especfica 2.3 - Identificar os Requisitos de Interface: Essa prtica especfica identifica os requisitos de interface. As Interfaces

entre funes ou entre objetos so identificadas. As interfaces funcionais podem orientar o desenvolvimento de solues alternativas descritas na rea de processo. Essa prtica possui duas subprticas: 1. Identificar as interfaces externas e internas do produto. medida que o design evolui, a arquitetura do produto ser alterada pelos processos da soluo tcnica, criando novas interfaces entre os componentes de produto e os componentes externos do produto; 2. Desenvolver os requisitos para as interfaces identificadas. Os requisitos de interfaces so definidos em termos de aspectos tais como origem, destino, estmulo, caractersticas de dados para software e hardware.

Objetivo especfico 3 Analisar e validar requisitos:

35

O objetivo especfico de analisar e validar requisitos utilizado para analisar e validar os requisitos e definir as funcionalidades requeridas. Ele dividido em cinco prticas especficas que so:

Pratica especfica 3.1 - Estabelecer Conceitos e Cenrios Operacionais: Essa prtica especfica estabelece e mantm conceitos operacionais e

cenrios associados. Um cenrio tipicamente uma seqncia de eventos que poderia ocorrer no uso do produto, que so usados para tornar explcita alguma necessidade dos stakeholders. Ela possui com quatro subprticas: 1. Elaborar conceitos operacionais e cenrios que incluam funcionalidade, desempenho, manuteno, suporte e descarte quando apropriado; 2. Definir o ambiente no qual o produto ou o componente de produto ir operar, incluindo fronteiras e restries; 3. Revisar os conceitos e cenrios operacionais para descobrir e refinar requisitos; 4. Desenvolver um conceito operacional detalhado, quando o produto e os componentes de produto so selecionados, para satisfazer s necessidades operacionais, de manuteno, de suporte e de descarte.

Pratica especfica 3.2 - Estabelecer uma Definio da Funcionalidade Requerida: Essa prtica especfica prope a definio de funcionalidade, tambm

chamada de anlise funcional, a descrio do que o produto pretende fazer. A definio de funcionalidades pode incluir aes, seqncias, entradas, sadas ou outras informaes que comunicam maneira que o produto ser usado. Essa prtica possui seis subprticas: 1. Analisar e quantificar as funcionalidades requeridas pelos usurios finais;

36

2. Analisar os requisitos para identificar as parties lgicas ou funcionais; 3. Particionar os requisitos em grupos, com base nos critrios estabelecidos,para facilitar ou dar foco anlise de requisitos; 4. Considerar a seqncia das funes de tempo-crtico, no incio e durante o desenvolvimento dos componentes de produto; 5. Alocar os requisitos do cliente s parties funcionais, objetos, pessoas ou a elementos de suporte para dar suporte sntese de solues; 6. Alocar requisitos funcionais e de desempenho s funes e subfunes.

Pratica especfica 3.3 - Analisar os Requisitos: Essa prtica especfica prega que os requisitos sejam analisados para

determinar se eles so necessrios e suficientes para atender aos objetivos dos nveis mais altos da hierarquia do produto. Ento, os requisitos analisados fornecem uma base de requisitos mais detalhada e precisa para os nveis mais baixos da hierarquia do produto. Ela possui seis subprticas: 1. Analisar as necessidades, expectativas, restries e interfaces externas dos stakeholders para remover conflitos e organiz-los em assuntos relacionados; 2. Analisar os requisitos para determinar se eles satisfazem aos objetivos dos requisitos dos nveis mais altos; 3. Analisar os requisitos para garantir que eles sejam completos, economicamente viveis, implementveis e verificveis. Enquanto o design determina a viabilidade de uma soluo particular; 4. Identificar os requisitos-chave que tm uma forte influncia nos custos, cronograma, funcionalidades, riscos ou desempenho; 5. Identificar medidas de desempenho tcnico que sero acompanhados durante o esforo de desenvolvimento; 6. Analisar os conceitos e cenrios operacionais para refinar as necessidades, restries e interfaces do cliente, e descobrir novos requisitos.

37

Pratica especfica 3.4 - Analisar os Requisitos Visando Equilbrio: Essa prtica especfica trata da anlise das necessidades e restries dos

stakeholders, verificando as questes relacionadas a custos, cronograma, desempenho, funcionalidade, componentes reusveis e manutenibilidade ou risco. Ela possui trs subprticas:

1. Usar modelos comprovados, simulaes e prototipagem para analisar o equilbrio de necessidades e restries dos stakeholders; 2. Realizar uma avaliao de risco nos requisitos e na arquitetura funcional; 3. Examinar os conceitos ciclo de vida do produto para identificar os impactos dos requisitos nos riscos.

Pratica especfica 3.5 - Validar os Requisitos com Mtodos Detalhados: Essa prtica especfica prega que a validao dos requisitos tem que ser

realizada precocemente no esforo de desenvolvimento com os usurios finais para obter confiana de que os requisitos so capazes de guiar um desenvolvimento que resulte em validao final bem sucedida. Ela possui trs subprticas: 1. Analisar os requisitos para determinar o risco do produto resultante no funcionar apropriadamente em seu ambiente de uso pretendido; 2. Explorar a adequao e completitude dos requisitos por meio do desenvolvimento de representaes do produto; como prottipos, simulaes, modelos, cenrios e roteiros; e de obteno de feedbacks dos stakeholders relevantes a respeito dessas representaes; 3. Avaliar o design medida que ele amadurece no contexto do ambiente de validao dos requisitos para identificar problemas de validao e expor necessidades e requisitos do cliente no declarados.

38

2.2 ENGENHARIA DE SOFTWARE EXPERIMENTAL Com base em todos os conceitos de engenharia de software e modelos tericos, visto at o momento, preciso saber se as praticas sugeridas pelo modelo terico aplicadas em qualquer ambiente organizacional sero bem sucedidas. Como no possvel obter esses resultados realizando apenas experimentos que comprovem a teoria na prtica, utiliza-se, nesse contexto, a engenharia de software experimental, pois ela ajuda a provar na prtica se o modelo terico funcionar para aquele ambiente no qual o experimento foi aplicado. A engenharia de software experimental nada mais que um estudo emprico sobre a prpria engenharia de software, ou seja, provar na prtica o que a teoria da engenharia de software prega. Segundo TRAVASSOS (2002) a experimentao o centro do processo cientfico e, somente com experimentos que podemos verificam as teorias, pois somente eles podem explorar os fatores crticos e dar luz ao fenmeno novo para que as teorias possam ser formuladas e corrigidas. A experimentao oferece um modelo sistemtico, disciplinado, computvel e controlado para avaliao da atividade humana. A competitividade das empresas de desenvolvimento de software depende cada vez mais da eficincia dos seus processos (WOHLIN et al., 2000). Como o uso de processos padres no so eficientes para todas as empresas, a otimizao dos processos de desenvolvimento para moldar-los ao ambiente operacional da empresa muito importante. Por isso que a realizao de estudos empricos faz-se necessrio, pois somente com uma aplicao prtica sobre as teorias levantadas, nos processos de uma empresa, que se pode saber se aquele processo est adequado para a determinada empresa ou no. Tambm a partir deste estudo emprico nos processos que podemos saber os pontos fortes, fracos e pontos de melhoria, sugerindo otimizao no processo, ou seja, as melhorias necessrias. Segundo TRAVASSOS (2002) os objetivos que levam a execuo de experimentos em Engenharia de Software so a possibilidade de se realizar uma caracterizao, avaliao, previso, controle e melhoria a respeito de produtos, processos, recursos, modelos, teorias entre outros. Quando se realiza um

39

experimento com o objetivo de caracterizar perguntas do tipo "O que est acontecendo?",o esforo menor em relao aos outros. Isso ocorre porque nos outros experimentos, que so de avaliao, previso, controle e melhoria, devero ser respondidas questes como "quo bom isto?", "posso estimar algo no futuro?", "posso manipular o evento?" e "posso melhorar o evento?". Como o mtodo experimental sugere um modelo terico, que a partir desse modelo desenvolvido um mtodo qualitativo ou quantitativo que realiza este experimento e depois mede e avalia o modelo terico e por fim pode ou no repetir esse processo. Esta tcnica representar uma melhoria evolucionria, pois se inicia a partir de um modelo novo e estuda o efeito do processo no software sugerido pelo modelo. BARROS et al. (1999) sugere que normalmente a realizao de um estudo experimental dividida em cinco fases: a definio, o planejamento, a execuo, a anlise e o empacotamento do estudo. Ainda em relao compreenso da engenharia de software experimental, TRAVASSOS (2002) observou que os elementos principais do experimento so as variveis, os objetos, os participantes, o contexto do experimento, hipteses, e o tipo de projeto do experimento. As variveis podem ser de dois tipos de variveis as dependentes (resultados), que so as sadas do processo de experimentao, e as variveis independentes (fatores), que so as entradas do processo e apresentam a causa que afeta o resultado do processo. A Figura 3 apresenta o relacionamento entre essas variveis.

40

Figura 3: Relacionamento entre as variveis (TRAVASSOS, 2002).

No objetivo do experimento verifica-se o relacionamento de causa-efeito na teoria a ser estudada. No processo de execuo os tratamentos so aplicados ao conjunto dos objetos e o resultado avaliado. Participantes so os indivduos selecionados da populao que interessa para a conduo do experimento. Para se conseguir um resultado de um experimento a uma populao desejada, o conjunto de participantes selecionado deve ser representativo para aquela populao. Com isso a importncia nos critrios de seleo grande, porque eles influenciam no resultado do experimento. A princpio, quanto maior a variedade da populao tanto maior deve ser o tamanho do conjunto de participantes. O contexto do experimento composto das condies no qual ele est sendo executado, podendo ser caracterizado em trs: In-vitro vs. In-vivo, Alunos vs. Profissionais, Problema real e Especfico vs. Geral. Os experimentos so normalmente formulados atravs de hipteses, contendo A hiptese principal, tambm chamada de hiptese nula, e a hiptese alternativa. O objetivo principal de um experimento fazer com, baseado nos resultados da verificao da verificao usando testes estatsticos, que uma hiptese alternativa consiga rejeitar a hiptese nula.

41

O tipo de projeto do experimento determina a maneira de conduo do experimento. A deciso sobre alocao dos objetos e dos participantes e como os tratamentos sero aplicados aos objetos so feitas neste momento. Um conjunto dos princpios deve ser considerado no processo de organizao e execuo do experimento, no tempo da anlise e interpretao dos resultados. Segundo TRAVASSOS (2002) os princpios gerais da organizao do experimento so a aleatoriedade, o agrupamento (blocking), e o balanceamento. Uma experimentao ser potencializada se os resultados do experimento puderem ser repetidos. Com isso importante que o experimento seja empacotado para que a outros investigadores possam reproduzir os resultados. Os resultados de um experimento no podem ser amplamente aceitos sem que a repetio seja realizada. 2.2.1 MEDIO Vrios autores definem a importncia da medio na engenharia de software experimental, segundo WOHLIN et al. (2000) a medio de software a parte central dos estudos empricos, ela crucial para ter controle dos projetos, produtos e processos. J DEMARCO (1982) afirma que no conseguimos controlar o que no conseguimos medir. TRAVASSOS (2002) define mediao como o mapeamento do mundo experimental para o mundo formal ou relacional, onde o principal objetivo do mapeamento a caracterizao e a manipulao das entidades empricas. No mapeamento, o julgamento no feito diretamente nas entidades reais, so atribudos nmeros ou smbolos as entidades empricas, e essa atribuio chamada de medida enquanto que o atributo da entidade que est sendo medida se denomina mtrica. Para WOHLIN et al. (2000) uma medida um mapeamento de um atributo de uma entidade a ter seu vali medido, geralmente um valor numrico. Segundo TRAVASSOS (2002) geralmente para um mesmo atributo realizamos mais de um mapeamento, onde esses mapeamentos so chamados de escala. As escalas so divididas em quatro tipos:

42

Nominal: O atributo de uma entidade apresentado como um nome ou smbolo; Ordinal: Ordena as entidades seguindo critrios definidos, usando afirmaes do tipo maior do que....

Intervalo: Ordena as entidades tambm, acrescentando a noo de distncia. Razo: O valor do zero significativo e a razo entre medidas significativa. Como uma medio pode ser feita em escalas diferentes, algumas vezes

preciso realizar as transformaes entre as diferentes escalas, transformando, por exemplo, metros em centmetros. Quando uma transformao aceita de uma escala para outra, preservando o relacionamento, ela chamada de transformao admissvel ou redimensionvel (FENTON; PFLEEGER, 1996). Com as medidas dos atributos podem-se fazer afirmaes sobre os objetos ou a relao entre os objetos ou em relao entre os objetos diferentes. Se a afirmao verdadeira, mesmo quando so redimensionadas elas so chamadas de significativas e, quando no permanecem afirmativas aps o redimensionamento, elas so conhecidas como sem sentido. O objetivo principal da medio na Engenharia de Software, segundo TRAVASSOS (2002), aumentar a compreenso do processo e do produto, controllos definindo antecipadamente as atividades corretivas e identificar as possveis reas de melhoria. Os objetos que so de interesse da engenharia de software podem ser divididos em trs partes diferentes: Processo, produto e recurso (WOHLIN et al.,2000). Na maioria dos casos a medio a engenharia de software utiliza as prprias mtricas de software. Para medir o produto, seja intermedirio ou o produto final, utilizado s mtricas do produto. J para medir as caractersticas dos processos de desenvolvimento de software utiliza-se as mtricas do processo. Pro fim as mtricas para medir objetos necessrios para o desenvolvimento de software como hardware, equipe, ferramentas entre outras so as mtricas de recursos.

43

Como qualquer disciplina da engenharia, o desenvolvimento de software necessita de um mecanismo de medio para evoluir. Esse mecanismo usado para manter uma memria corporativa com respostas para a variedade de perguntas associada com o processo de desenvolvimento de software, ajudando a dar uma base a planejamento de projetos. Estudos (BASILI et al.,1994a) concluram que uma medio para ser efetiva deve ser focada no objetivo especfico; aplicada para todo o ciclo de vida do processo de desenvolvimento do produto; e interpretada e baseada na caracterizao e entendimento no contexto da organizao em relao a ambiente e objetivos. Ou seja, a medio deve ser feita no modo top-down, pois precisa ser focada, baseada nos objetivos e modelos. A abordagem bottom-up no funciona, porque existem vrias caractersticas observveis em um software. 2.2.2 VALIDADE Para utilizar uma medida nos estudos empricos, deve-se verificar sua validade. Uma medida vlida precisa ser a prpria caracterizao matemtica do atributo e que no viole as propriedades necessrias dos atributos das medidas e. Para TRAVASSOS (2002) a validade dos resultados do experimentos fundamental. Os resultados devem ser vlidos para a populao da qual o conjunto de participantes foi recebido. interessante tambm generalizar os resultados para uma populao mais ampla. Os resultados possuem a validade adequada se so vlidos para a populao a qual tendem ser generalizados. Uma medida vlida permite distinguir os objetos diferentes, mas

dependendo da margem de erro das medies, objetos distintos podem ter os mesmos valores para as medies. Segundo KITCHENHAM et al. (1995) As medidas precisam preservar as nossas noes intuitivas sobre o atributo e a maneira de como objetos diferentes se distinguem. Para podermos entender as divises de tratamentos de acordo com a validade dos resultados dos estudos experimentais, podemos citar duas vises de pocas diferentes. Segundo CAMPBELL e STANLEY (1963) define-se dois tipos de tratamentos para a validao a interna e a externa. J para COOK e CAMPBELL

44

(1979) a lista se estende para quatro tipos: validade de concluso, validade interna, validade de construo e validade externa. TRAVASSOS (2002) em seu estudo citou tambm a subdiviso em quatro tipos. A primeira validade a de concluso e est relacionada habilidade de chegar a uma concluso correta a respeito dos relacionamentos entre o tratamento e o resultado do experimento. A segunda a validade interna que define se o relacionamento observado entre o tratamento e o resultado causal, e no o resultado da influncia de outro fator que no controlado ou mesmo no foi medido. Tem se tambm a validade de construo que considera os relacionamentos entre a teoria e a observao, ou seja, se o tratamento reflete a causa bem e o resultado reflete o efeito bem. E por fim, a validade externa, definindo as condies que limitam a habilidade de generalizar os resultados de um experimento para a prtica industrial. 2.2.3 TIPOS DE EXPERIMENTOS Existe um grande nmero de classificaes de experimentos. Segundo TRAVASSOS (2002) isto deve-se ao fato da experimentao ainda ser uma abordagem nova na engenharia de requisitos. A classificao dos experimentos est sempre relacionada aos conceitos das estratgias empricas que so descritos pela literatura, sintetizados em trs principais estratgias experimentais: survey, estudo de caso e experimento. O survey mais indicado para pesquisas de opinio e de mercado. Geralmente usado para realizar um questionrio e entrevistar os stakholders envolvidos no novo processo, questionando o que eles esto achando do processo. O estudo de caso utilizado para realizar um estudo sobre um fenmeno nico em um especfico espao de tempo. Uma forma de usar o estudo de caso seria um modelo para verificar a quantidade de requisitos reprovados pelo cliente aps a adoo do novo modelo a mtrica um seria o nmero total de requisitos reprovados e a mtrica dois seria a quantidade de requisitos reprovados aps a adoo do novo modelo.

45

O experimento oferece o maior nvel de controle. indicado realizar o experimento em um ambiente controlado, como um laboratrio. Seu objetivo a manipulao de algumas variveis, mantendo outras inertes e medindo os efeitos e os resultados. Os experimentos podem ser feitos em laboratrio, com um ambiente controlado ou em condies normais. Os experimentos como foi dito antes, so utilizados para confirmar teorias e sugerir melhorias nos processos. A Tabela 5 apresenta a comparao das estratgias empricas.

Tabela 5: Comparao das estratgias empricas.

FATOR O controle da execuo O controle da medio O controle da investigao Facilidade da repetio Custo

Survey Nenhum Nenhum Baixo Alta Baixo

Estudo de Caso Nenhum Tem Mdio Baixa Mdio

Experimento Tem Tem Alto Alta Alto

De acordo com as estratgias experimentais existem trs principais mtodos para coleta de dados: histrico, utilizado para coletar os dados experimentais dos projetos que j tenham sido terminados; o mtodo de observao, que coleta os dados relevantes enquanto o projeto est sendo executado; e o mtodo controlado, que prov as instncias mltiplas de uma observao oferecendo a validade estatstica dos resultados do estudo (TRAVASSOS, 2002). 2.2.4 PROCESSO Segundo WOHLIN et al. (2000) uma experimentao no um processo simples, porque precisamos preparar, conduzir e analisar os experimentos. Um experimento deve ser tratado como um processo da formulao ou de verificao

46

de uma teoria. Para que o processo do experimento retorne resultados vlidos, ele tem que ser organizado e controlado. Para atingir os objetivos foram elaboradas vrias metodologias de organizao dos experimentos foram elaboradas. BASILI et al. (1994b) descreve uma metodologia de experimentao avanada que est essencialmente ligada melhoria continua do processo do desenvolvimento de software o QIP, do ingls, Quality Improvement Paradigm. Essa metodologia define seis passos que resultam em um ciclo de melhoria de processos. O processo inicia o ciclo com a caracterizao do processo de negcio necessria para a compreenso do ambiente e a definio dos objetivos bsicos. Em seguida, os objetivos quantitativos so estabelecidos. Com base na caracterizao e nos objetivos definidos escolhido o processo mais apropriado. Depois feita a execuo dos processos nos projetos, analisando os dados obtidos em cada projeto e fornecendo um retorno a respeito dos dados que esto sendo coletados. S ento, realizada uma anlise dos dados da informao para avaliar as prticas atuais, determinar os problemas, registrar os achados e realizar recomendaes para projetos futuros. Por fim, os dados da informao so analisados e reunidos para avaliar as prticas atuais, determinar os problemas, registrar os achados e realizar recomendaes para projetos futuros. O QIP ligado ao conceito da Fbrica da Experincia (BASILI et al., 1994b) que o conjunto das ferramentas usadas para realizar o armazenamento, a modificao, e o empacotamento das informaes do projeto. Isso significa que alm do armazenamento passivo dos dados experimentais, a Fbrica de Experincia pode processar os pedidos do projeto atual oferecendo a informao relevante dos projetos semelhantes. A Figura 4 apresenta a estrutura da Fbrica da Experincia.

47

Figura 4: Esquema de uma fbrica de experincia (TRAVASSOS, 2002).

SOLINGEN e BERGHOUT (1999) descrevem outra abordagem que oferece o processo da melhoria com o modelo da medio baseada em camadas a GQM (Goal Question Metric). Segundo BASILI et al. (1994a), O Goal Question Metric um mecanismos para definir objetivos mensurveis. O GQM uma abordagem que uma organizao pode usar para medir seus processos, de uma maneira poderosa, que funciona da seguinte maneira: primeiramente feita a especificao dos objetivos dos projetos, depois esses objetivos so traados e finalmente disponibiliza-se um framework para interpretao dos dados com os seus respectivos estados relacionados aos objetivos. Para realizar o processo utilizada uma abordagem top-down, onde os objetivos so estabelecidos, depois as questes so formuladas, e por fim, as mtricas so elaboradas. J para realizar a interpretao dos resultados utilizada a abordagem bottom-up, atravs do uso da medio para receber os dados experimentais, depois formulando as respostas para as questes baseada nos dados experimentais, e por fim, agrupando as respostas para demonstrar o grau do de sucesso dos objetivos estabelecidos. Essa abordagem foi originalmente definida para avaliar defeitos de um conjunto de projetos no Goddard Space Flight Center da NASA. Para entender melhor o que representa cada etapa abaixo um resumo do que representa cada uma nesta abordagem:

48

Goal uma meta definida para um objetivo por razes variadas, com vrios modelos de qualidade com vrios pontos de vista relativos a ambientes em particular. Objetivos de medio so os produtos, processos e recursos.

Question formada por uma poro de perguntas que so usadas para caracterizar as sadas de avaliao/realizao de uma meta (Goal) especfica. As perguntas tentam caracterizar o objetivo da medio com respeito a uma qualidade de seleo das questes para determinar a qualidade do ponto de vista selecionado.

Metric possui uma quantidade de dados que so associados com cada questo (Question) para ser respondida de uma maneira quantitativa, podendo ser objetivas e subjetivas. Para TRAVASSOS (2002) os principais objetivos definidos pelo GQM so

compreender, controlar, e melhorar. O foco desses objetivos so quatro fatores: o custo, o risco, o tempo, e a qualidade. A juno dos objetivos com os fatores os possibilita aos investigadores o aumento da compreenso do produto e do processo de software, o produto e o processo se tornam controlados, e, finalmente, as atividades de melhoria do produto e do processo de software esto sendo definidas. A abordagem GQM composta de quatro fases: A fase do planejamento, quando o projeto da medio est selecionado, definido, caracterizado, e planejado, resultando em o plano do projeto; A fase da definio, quando o programa da medio conceitualmente preparado, ou seja, os objetivos, as questes, as mtricas e as hipteses so estabelecidas; a fase da coleta de dados, quando a coleta de dados experimentais efetivamente feita resultando em conjunto de dados prontos para a interpretao; e a fase da interpretao, quando os dados so processados a respeito das mtricas, questes, e objetivos definidos (TRAVASSOS, 2002). Segundo WOHLIN et al. (2000) a realizao de um estudo experimental geralmente pode ser dividida em cinco fases: a definio, o planejamento, a

49

execuo, a anlise e o empacotamento do estudo. BARROS et al. (1999) sintetizou as cinco fases do estudo experimental da seguinte forma: Na definio do experimento realizado um resumo dos objetivos, seu foco de qualidade e os objetos que vo ser analisados. A fase de planejamento envolve a descrio do perfil dos participantes, dos instrumentos, do processo de execuo realizada uma avaliao criteriosa dos problemas que podem ser encontrados ao longo da execuo. A execuo a realizao do estudo experimental pelos participantes, utilizando os instrumentos e o processo definidos na fase de planejamento. Na fase da anlise realizada a organizao dos resultados obtidos pelos participantes durante a execuo e a realizao de inferncias sobre estes resultados. O empacotamento a organizao e armazenamento dos documentos construdos nas etapas anteriores. Esse armazenamento feito com o intuito de facilitar a repetio do estudo experimental no futuro. Em relao ao empacotamento TRAVASSOS (2002) afirma que uma das caractersticas mais importantes de um experimento a necessidade da sua repetio. Porque com a repetio que os pesquisadores obtm o conhecimento adicional sobre os conceitos estudados, e recebem os resultados que podem ser iguais ou diferentes dos resultados do experimento original. Para que esse controle seja feito de uma forma eficaz, o empacotamento deve possuir um padro para que seja possvel o armazenamento correto deles, pois esses dados experimentais podem servir como base para a criao das bibliotecas de experimentao.

50

3 SOLUO PROPOSTA
Nesta seo, ser descrito o experimento que caracterizou como a engenharia de requisitos est sendo utilizada nos projetos de uma empresa de Tecnologia da Informao. Tambm ser apresentada a adequao do processo de engenharia de requisitos da empresa em relao s prticas especficas de engenharia de requisitos do CMMI. E, por fim, ser relatada a opinio dos profissionais que foram entrevistados nesse experimento quanto utilidade e a necessidade de aumentar ou diminuir o nvel de detalhamento do uso dessas prticas, bem como os resultados e mapeamento dos pontos fortes e pontos que podem ser melhorados. 3.1 A EMPRESA A empresa na qual o experimento foi realizado, uma empresa de tecnologia da informao que tem a sua Matriz situada no Recife, com filiais em vrios estados do Brasil. Ela possui negcios internacionais e um faturamento anual superior a 10 milhes. A empresa no possui certificao CMMI, mas tem a inteno de se certificar, por acreditar ser importante para o futuro da empresa. 3.2 DEFINIO DOS OBJETIVOS 3.2.1 OBJETIVO GLOBAL: Caracterizar o uso do processo de engenharia de requisitos em uma empresa de Tecnologia da informao, correlacionando o seu uso com as prticas especficas de engenharia de requisitos exigidas pelo CMMI, apontando os pontos fortes e pontos de melhoria no seu processo no nvel de utilidade e de adequao do uso. 3.2.2 OBJETIVO DA MEDIO: Tendo como base a Engenharia de requisitos, caracterizar:

51

1. Quais so as prticas de engenharia de requisitos utilizadas pelos projetos da empresa: Quais so as prticas especficas da engenharia de requisitos exigidas pelo CMMI que so usadas totalmente ou parcialmente pelos projetos de integrao da empresa e so consideradas teis. Quais so as prticas especficas da engenharia de requisitos exigidas pelo CMMI que no so usadas pelos projetos de integrao da empresa. 2. Quais so as prticas especficas de engenharia de requisitos exigidas pelo CMMI que so consideradas inadequadas ou teis pela empresa: Quais so as prticas especficas da engenharia de requisitos exigidas pelo CMMI que precisam ser mais detalhadas para atender melhor as necessidades da empresa. Quais so as prticas especficas da engenharia de requisitos exigidas pelo CMMI so que so consideradas teis para da empresa. 3.2.3 OBJETIVO DO ESTUDO: Analisar as prticas especficas oferecidas pelo CMMI empresa, a fim de caracteriz-la com respeito s vantagens oferecidas pelas prticas especficas da engenharia de requisitos exigida pelo CMMI do ponto de vista dos analistas e desenvolvedores da empresa no contexto dos projetos.

3.2.4 QUESTES Q1: Existem prticas especficas da engenharia de requisitos exigidas pelo CMMI que no fazem parte dos projetos de integrao da empresa? Mtrica1: A lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI que no fazem parte dos projetos de integrao da empresa.

52

Q2: Existem prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao da empresa e que no estejam trazendo ganhos para a empresa? Mtrica2: A lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao da empresa e que no so consideradas relevantes. Q3: Existem prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao e que a empresa considera que esteja trazendo ganhos para ela? Mtrica3: A lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao da empresa e que so consideradas relevantes. Q4: Existem prticas especficas da engenharia de requisitos exigidas pelo CMMI que no fazem parte dos projetos de integrao e que a empresa gostaria de ter? Mtrica4: A lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI no fazem parte dos projetos de integrao da empresa e que ela gostaria de ter. Q5: Existem prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao e que a empresa que no esto adequadas quanto ao seu uso? Mtrica5: A lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integrao da empresa e que precisam ser melhoradas.

53

3.3 PLANEJAMENTO 3.3.1 DEFINIO DAS HIPTESES Para realizar o estudo experimental preciso levantar as hipteses nula e alternativa. A hiptese nula representa a afirmao que o estudo experimental tem como objetivo negar, e as hipteses alternativas tm por objetivo rejeitar a hiptese nula. As hipteses levantadas nesse estudo esto descritas abaixo. Hiptese nula (H0): As prticas especficas da engenharia de requisitos exigidas pelo CMMI so similares s prticas de engenharia de requisitos utilizadas nos projetos de integrao da empresa. Pa Prticas especficas da engenharia de requisitos exigidas pelo CMMI; Pc Prticas de engenharia de requisitos utilizadas2 nos projetos de integrao. H0: Pc (Pa Pc) = 0 Hiptese alternativa (H1) As prticas especficas da engenharia de requisitos exigidas pelo CMMI so diferentes s prticas utilizadas nos projetos de integrao da empresa. Pa prticas especficas da engenharia de requisitos exigidas pelo CMMI; Pc Prticas de engenharia de requisitos utilizadas nos projetos de integrao. H1: : Pc (Pa Pc) 0

Hiptese alternativa (H2): As prticas especficas da engenharia de requisitos exigidas pelo CMMI que no fazem parte das utilizadas pela empresa e que ela gostaria de utilizar. Pa prticas especficas da engenharia de requisitos exigidas pelo CMMI; Pau - prticas especficas da engenharia de requisitos exigidas pelo CMMI que no so usadas nos projetos da empresa e que a empresa no gostaria de utilizar. H2: Pa (Pa Pau) 0

Hiptese alternativa (H3): As prticas especficas da engenharia de requisitos exigidas pelo CMMI que a empresa no acha til. Pa prticas especficas da engenharia de requisitos exigidas pelo CMMI;

54

Pau - prticas especficas da engenharia de requisitos exigidas pelo CMMI e que a empresa considera util. H3: Pa (Pa Pau) 0

Hiptese alternativa (H4): As prticas especficas da engenharia de requisitos exigidas pelo CMMI utilizadas na empresa que so consideradas adequadas. Pa prticas especficas da engenharia de requisitos exigidas pelo CMMI; Pac - prticas especficas da engenharia de requisitos exigidas pelo CMMI e que a empresa considera inadequada. H2: Pa (Pa Pac) 0

3.3.2 DESCRIO DA INSTRUMENTAO Para cada prtica especfica da engenharia de requisitos exigida pelo CMMI foram escolhidos os itens conforme Tabela 6.
Tabela 6: Opes de resposta aplicadas no questionrio

Presena da Prtica (P) 1. No utilizada nos projetos e no acredito ser relevante 2. No utilizada, mas gostaria de usar. 3. utilizada, parcialmente. 4. usada.

Utilidade da Prtica (U) 1. No til. 2. Provavelmente til, mas ainda no apliquei. 3. til e j apliquei em diferentes projetos.

Adequao do nvel de detalhamento de uso da Prtica (A) 1. O detalhamento deve ser aumentado. 2. O detalhamento no precisa ser modificado. 3. O detalhamento deve ser diminudo.

Para continuar com o processo e validar os dados respondidos pelos profissionais da empresa para cada competncia deveria ser aplicado o teste Chi-2. Como os profissionais da empresa que atuaram nesses projetos totalizam quatro e

55

todos eles foram entrevistados, no recomendado realizar o teste do Chi-2. No caso de outro estudo que utilize uma amostragem de entrevistados que ultrapasse 10 profissionais o teste Chi-2 dever ser utilizado. As questes abordadas seriam:

Pode se considerar que essa prtica est presente nos projetos? Pode se considerar que essa prtica til? Pode considerar que o detalhamento do uso da prtica no precisa de modificao?

O resultado desse teste seria uma tabela com apenas as respostas iguais a zero ou um e distribudas entre as questes (P,U,A) onde: P presena (0 no usada;1 usada); U utilidade (0 no til;1 til); A adequao (0 o nvel adequado,1 o nvel no adequado). A Tabela 7 mostra como ficaria a distribuio de todas as combinaes das repostas do teste Chi-2 em relao a presena, utilidade e adequao das prticas e as suas associaes com as questes propostas.
Tabela 7: Relao entre os dados de P,U,A e as Questes.

N 1 2 3 4 5 6 7 8

P U A 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 1 1 1

Descrio da prtica no usada, no til, a modificao no necessria. no usada, no til, a modificao necessria. no usada, til, a modificao no necessria. no usada, til, a modificao necessria. usada, no til, a modificao no necessria. usada, no til, a modificao necessria. usada, til, a modificao no necessria. usada, til, a modificao necessria.

Questes Q1,Q2 Q1,Q2 Q1,Q4 Q1,Q4 Q3, Q2 Q3, Q2 Q3 Q3

56

3.3.3 SELEO DE CONTEXTO O contexto pode ser caracterizado conforme quatro dimenses: Processo: on-line / off-line; Os participantes: Profissionais; Realidade: o problema real / modelado; Generalidade: especifico / geral.

Nesse estudo foi utilizado o processo off-line, pois os participantes foram entrevistados em alguns instantes. Os participantes so os profissionais (analistas, desenvolvedores e coordenadores dos projetos). 3.3.4 SELEO DOS INDIVDUOS Os participantes selecionados foram profissionais da empresa que

acompanharam os projetos de integrao como coordenadores, analistas e desenvolvedores. Foi proposto aos participantes um questionrio com o objetivo de caracterizar sua formao do ponto de vista profissional para analisar os dados e reduzir o vis. 3.3.5 VARIVEIS 3.3.5.1 VARIVEIS INDEPENDENTES: A lista de prticas de Engenharia de requisitos. 3.3.5.2 VARIVEIS DEPENDENTES: 1. A similaridade entre as prticas especficas da engenharia de requisitos exigidas pelo CMMI e as prticas usadas nos projetos de integrao da empresa. Pode receber os valores: Igual, todas as prticas tm o valor PUA = {1, X, X}/qtde de prticas *100;

57

Diferente, todas as prticas tm o valor PUA = {0, X, X}/qtde de prticas *100.

2. A utilidade das prticas especficas. Mostra as prticas especficas da engenharia de requisitos: Parte til: {1, 1, X} / {1, X, X} * 100 Parte intil: {1, 0, X} / {1, X, X} * 100 3. A adequao de prticas especficas. Mostra as prticas especficas da engenharia de requisitos: Parte adequada: {1, X, 0} / {1, X, X} * 100 Parte inadequada: {1, X, 1} / {1, X, X} * 100 3.3.6 ANLISE QUALITATIVA Foi realizada uma anlise qualitativa de modo a analisar a informao referente s prticas especficas da engenharia de requisitos exigidas pelo CMMI que no so usadas pelos projetos de integrao da empresa, mas que foram identificadas como teis pelos entrevistados. Para essa anlise foi apresentada uma lista de prticas de engenharia de requisitos exigida pelo CMMI, que no fazem parte do processo dos projetos, mas que a foi identificada como til e conseqentemente deveria fazer parte do processo de engenharia de requisitos. Para isso, a anlise considerou prticas com valor PUA = {0, X, X}, ou seja, as prticas que no estavam presentes nos projetos. 3.3.7 VALIDADE Validade interna: Na parte Seleo dos indivduos foi mencionado que para o estudo se prope a utilizar os profissionais da empresa que participaram dos projetos de integrao da empresa.

58

Alm disso, com o intuito de reduzir a influncia dos fatores que no so de interesse do estudo e, aumentando a validade interna do estudo utilizou-se os dados do questionrio para dividir dos participantes em grupos conforme os seus papeis nos projetos. Validade de concluso: para receber os valores da presena, utilidade e conformidade o teste binomial foi utilizado. A verificao de hiptese foi feita por meio de simples demonstrao de presena ou no de competncias nas listas que representam as variveis independentes. Validade de construo: esse estudo est caracterizado pela conformidade das prticas especficas da engenharia de requisitos exigidas pelo CMMI. As prticas de engenharia de requisitos utilizadas nos projetos de integrao da empresa. As prticas, que tm o maior grau de relevncia no que diz respeito engenharia de requisitos para a empresa, foram escolhidas do conjunto total de prticas da engenharia de requisitos. Validade externa: como foi mencionado nas partes Seleo dos indivduos e Validade interna os participantes do estudo em geral podem ser considerados representativos para a populao dos profissionais que trabalharam nos projetos de integrao da empresa. Para avaliao do nvel de envolvimento no processo, os dados do questionrio, conforme a experincia dos participantes foram analisados. Os materiais utilizados no estudo podem ser considerados representativos e em tempo para o problema sob anlise, porque se compem das prticas da engenharia de requisitos.

59

3.4 OPERAO 3.4.1 MATERIAL INFORMATIVO DAS PRTICAS ESPECFICAS DO CMMI Para que os participantes do experimento possam ter um conhecimento mais embasado no que diz respeito engenharia de requisitos do CMMI, foi criado um material informativo que explica todas as prticas especficas e suas subprticas. Esse material tem por objetivo alinhar o conhecimento dos participantes em relao s prticas especficas do CMMI e ajudar aos participantes a responderem o questionrio das prticas.

Tabela 8: Prticas especficas de objetivo especfico de gerenciamento de requisitos e suas subprticas.

rea de processo (AP): Gerenciamento de Requisitos REQM Objetivo Especfico (OE): Gerenciar Requisitos Prticas especficas (PE) PE1 Obter um entendimento dos requisitos.

A fim de evitar problemas futuros, so designadas as fontes oficiais que sero responsveis por disponibilizar e receber os requisitos. A prtica especfica do entendimento dos requisitos trata do estabelecimento do uso de um mecanismo que obtm, com o cliente, o significado do requisito. Ele composto por atividades que captam os requisitos para assegurar que sua compreenso foi atingida. Essa prtica tambm estabelece os critrios que evitam o crescimento indistinto dos mesmos. Para essa prtica so utilizados como produtos de trabalho: 1. Lista de critrios para a apropriada distino dos fornecedores dos requisitos. 2. Critrios para avaliao e aceitao dos requisitos. 3. Resultados das anlises em relao aos critrios.

60

4. Um conjunto de requisitos acordados. PE2 Obter comprometimento com requisitos.

Quando so formadas as equipes, o compromisso com os requisitos necessrio, assegurando que as mudanas ocorridas ao longo do tempo sejam disponibilizadas para todos os envolvidos. Essa prtica trata de acordos e compromissos entre os profissionais envolvidos na execuo das atividades necessrias para implementao dos requisitos. Para essa prtica so utilizados como produtos de trabalho: 1. Analisar os impactos dos requisitos. 2. Compromissos documentados com os requisitos e com as mudanas de requisitos. PE3 Gerenciar mudanas de requisitos.

Gerenciar as mudanas nos requisitos durante a evoluo do projeto importante para manter os requisitos atualizados, pois eles podem mudar devido a vrios fatores, inclusive fatores no previstos, como por exemplo, a exigncia de atendimento a uma nova legislao. Estas mudanas devem ser controladas de forma que permita a avaliao dos impactos que podem ocorrer em todo o projeto. Ela tambm possibilita aos gerentes rastrear as medidas de volatilidade de requisitos para julgar a necessidade de novos controles ou, fazer a reviso dos existentes. Para essa prtica so utilizados como produtos de trabalho: Status de requisitos. Banco de dados de requisitos. Banco de dados de decises de requisitos. Subprticas: 1. Documentar todos os requisitos e mudanas de requisitos do projeto.

61

2. Manter um histrico de mudanas de requisitos com os fundamentos lgicos das mudanas. 3. Manter o histrico de mudanas ajuda a rastrear a volatilidade dos requisitos. 4. Avaliar o impacto das mudanas de requisitos do ponto de vista dos stackeholders relevantes. 5. Tornar disponveis ao projeto os dados de requisitos e de mudanas. PE4 Manter rastreabilidade bidirecional de requisitos.

Esta prtica importante porque a partir de uma rastreabilidade bidirecional bem feita possvel rastrear os requisitos at sua origem e retornar a sua condio atual, por exemplo, indicando qual ser o impacto das mudanas neles e como ser refletida no projeto. Para essa prtica so utilizados como produtos de trabalho: 1. Matriz de rastreabilidade de requisitos. 2. Sistema de rastreamento de requisitos. Subprticas: 1. Manter a rastreabilidade dos requisitos para assegurar que a origem do menor nvel de requisito (derivado) esteja documentada. 2. Manter a rastreabilidade de um requisito com seus requisitos derivados e com sua alocao a funes, interfaces, pessoas, processos e produtos de trabalho. 3. Gerar a matriz de rastreabilidade de requisitos. PE5 Identificar inconsistncias entre artefatos do projeto e requisitos.

Essa prtica utilizada para descobrir as inconsistncias entre os

62

requisitos e os planos do projeto e produtos de trabalho. Isso permite iniciar aes corretivas para no desviar o foco do requisito em questo. Para essa prtica utilizado como produto de trabalho: 1. Documentao de inconsistncias incluindo fontes, condies e

justificativas e aes corretivas. Subprticas: 1. Revisar os planos de projeto, atividades e produtos de trabalho visando consistncia com os requisitos e com as mudanas neles realizadas. 2. Identificar a origem das inconsistncias e fundamento lgico. 3. Identificar mudanas que necessitam ser feitas nos planos e produtos de trabalho resultantes das mudanas na baseline de requisitos. 4. Iniciar as aes corretivas.

Tabela 9: Prticas especficas de objetivo especifico de desenvolvimento de requisitos do cliente e suas subprticas.

rea de processo (AP): Desenvolvimento de Requisitos RD Objetivo Especfico (OE): Desenvolver Requisitos do Cliente Prticas especficas (PE) PE01 Coletar as necessidades dos stakeholders.

Essa prtica especfica prope realizar o levantamento das necessidades, expectativas, restries e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai alm da coleta de requisitos, incluindo a identificao adicional e pr-ativa de requisitos no fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam enderear as vrias atividades do ciclo de vida do produto e seus impactos no produto.

63

Subprticas: 1. Envolver os stakeholders relevantes usando mtodos para levantamento de necessidades, expectativas, restries e interfaces externas. PE02 Elicitar as necessidades.

Essa prtica especfica prope realizar o levantamento das necessidades, expectativas, restries e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai alm da coleta de requisitos, incluindo a identificao adicional e pr-ativa de requisitos no fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam enderear as vrias atividades do ciclo de vida do produto e seus impactos no produto. Subprticas: 1. Envolver os stakeholders relevantes usando mtodos para levantamento de necessidades, expectativas, restries e interfaces externas. PE03 Essa Desenvolver os Requisitos dos clientes. prtica especfica transforma as necessidades, expectativas,

restries e interfaces dos stakeholders em requisitos do cliente. Subprticas: 1. Traduzir as necessidades, expectativas, restries e interfaces dos stakeholders em requisitos do cliente documentados; 2. Definir restries de verificao e validao.

Objetivo Especfico (OE): Desenvolver requisitos do produto Prticas especficas (PE)

64

PE04

Estabelecer os requisitos dos produtos e seus componentes.

Essa prtica especfica estabelece e mantm os requisitos do produto e dos componentes de produto, que so baseados nos requisitos do cliente. Subprticas: 1. Desenvolver os requisitos em termos tcnicos, necessrios ao design do produto e dos componentes de produto. Desenvolver os requisitos de arquitetura endereando qualidades e desempenho crticos do produto necessrios ao design da arquitetura do produto; 2. Derivar os requisitos que resultam das decises de design. PE05 Alocar os requisitos dos componentes dos produtos.

Essa prtica especfica prope alocar os requisitos de cada componente do produto. Subprticas: 1. Alocar requisitos a funes; 2. Alocar requisitos a componentes de produto; 3. Alocar restries de design a componentes de produto. PE06 Identificar os requisitos de interfaces.

Essa prtica identifica os requisitos de interface. As Interfaces entre funes ou entre objetos so identificadas. As interfaces funcionais podem orientar o desenvolvimento de solues alternativas descritas na rea de processo. Subprticas: 1. Identificar as interfaces externas e internas do produto. medida que o design evolui, a arquitetura do produto ser alterada pelos processos da soluo tcnica, criando novas interfaces entre os componentes de

65

produto e os componentes externos do produto; 2. Desenvolver os requisitos para as interfaces identificadas. Os requisitos de interfaces so definidos em termos de aspectos tais como origem, destino, estmulo, caractersticas de dados para software e hardware.

Objetivo Especfico (OE): Desenvolver requisitos do produto Prticas especficas (PE) PE07 Estabelecer conceitos operacionais e cenrios.

Essa prtica estabelece e mantm conceitos operacionais e cenrios associados. Um cenrio tipicamente uma seqncia de eventos que poderia ocorrer no uso do produto, que so usados para tornar explcita alguma necessidade dos stakeholders. Subprticas: 1. Elaborar conceitos operacionais e cenrios que incluam funcionalidade, desempenho, manuteno, suporte e descarte quando apropriado; 2. Definir o ambiente no qual o produto ou o componente de produto ir operar, incluindo fronteiras e restries; 3. Revisar os conceitos e cenrios operacionais para descobrir e refinar requisitos; 4. Desenvolver um conceito operacional detalhado, quando o produto e os componentes de produto so selecionados, para satisfazer s necessidades operacionais, de manuteno, de suporte e de descarte. PE08 Estabelecer uma definio das funcionalidades requeridas.

Essa prtica prope a definio de funcionalidade, tambm chamada de anlise funcional, a descrio do que o produto pretende fazer. A definio de funcionalidades pode incluir aes, seqncias, entradas, sadas ou outras informaes que comunicam maneira que o produto ser usado.

66

Subprticas: 1. Analisar e quantificar as funcionalidades requeridas pelos usurios finais; 2. Analisar os requisitos para identificar as parties lgicas ou funcionais; 3. Particionar os requisitos em grupos, com base nos critrios estabelecidos,para facilitar ou dar foco anlise de requisitos; 4. Considerar a seqncia das funes de tempo-crtico, no incio e durante o desenvolvimento dos componentes de produto; 5. Alocar os requisitos do cliente s parties funcionais, objetos, pessoas ou a elementos de suporte para dar suporte sntese de solues; 6. Alocar requisitos funcionais e de desempenho s funes e subfunes. PE09 Analisar os requisitos.

Essa prtica prega que os requisitos sejam analisados para determinar se eles so necessrios e suficientes para atender aos objetivos dos nveis mais altos da hierarquia do produto. Ento, os requisitos analisados fornecem uma base de requisitos mais detalhada e precisa para os nveis mais baixos da hierarquia do produto. Subprticas: 1. Analisar as necessidades, expectativas, restries e interfaces externas dos stakeholders para remover conflitos e organiz-los em assuntos relacionados; 2. Analisar os requisitos para determinar se eles satisfazem aos objetivos dos requisitos dos nveis mais altos; 3. Analisar os requisitos para garantir que eles sejam completos, economicamente viveis, implementveis e verificveis. Enquanto o design determina a viabilidade de uma soluo particular; 4. Identificar os requisitos-chave que tm uma forte influncia nos custos, cronograma, funcionalidades, riscos ou desempenho; 5. Identificar medidas de desempenho tcnico que sero acompanhados durante o esforo de desenvolvimento;

67

6. Analisar os conceitos e cenrios operacionais para refinar as necessidades, restries e interfaces do cliente, e descobrir novos requisitos. PE10 Analisar os requisitos para avaliao.

Essa prtica especfica trata da anlise das necessidades e restries dos stakeholders, verificando as questes relacionadas a custos, cronograma, desempenho, funcionalidade, componentes reusveis e manutenibilidade ou risco. Subprticas: 1. Usar modelos comprovados, simulaes e prototipagem para analisar o equilbrio de necessidades e restries dos stakeholders; 4. Realizar uma avaliao de risco nos requisitos e na arquitetura funcional; 5. Examinar os conceitos ciclo de vida do produto para identificar os impactos dos requisitos nos riscos. PE11 Validar os requisitos.

Essa prtica especfica prega que a validao dos requisitos tem que ser realizada precocemente no esforo de desenvolvimento com os usurios finais para obter confiana de que os requisitos so capazes de guiar um desenvolvimento que resulte em validao final bem sucedida. Subprticas: 1. Analisar os requisitos para determinar o risco do produto resultante no funcionar apropriadamente em seu ambiente de uso pretendido; 2. Explorar a adequao e completitude dos requisitos por meio do desenvolvimento de representaes do produto; como prottipos, simulaes, modelos, cenrios e roteiros; e de obteno de feedbacks dos stakeholders relevantes a respeito dessas representaes; 3. Avaliar o design medida que ele amadurece no contexto do ambiente de validao dos requisitos para identificar problemas de validao e expor

68

necessidades e requisitos do cliente no declarados.

3.4.2 QUESTIONRIO DO PERFIL DOS PARTICIPANTES

Tabela 10: Questionrio do perfil dos participantes

Responda: FORMAO. ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ PROFISSO. ___________________________________________________________________ ___________________________________________________________________

TEMPO DE EXPERIENCIA PROFISSIONAL. __________________________________________________________________

CARGOS OCUPADOS NA EMPRESA. ___________________________________________________________________ ___________________________________________________________________

69

3.4.3 QUESTIONRIO DAS PRTICAS Relacionando-se apenas com os projetos de integrao da empresa que voc participou em relao ao processo de engenharia de requisitos, por favor, avalie e marque as colunas correspondentes segundo as escalas da Tabela 11 considerando a presena, utilidade e adequao das prticas de engenharia de requisitos listadas no questionrio da Tabela 12.

Tabela 11: Escalas para respostas.

Presena da Prtica (P)

Utilidade da Prtica (U)

Adequao do nvel de detalhamento de uso da Prtica (A) 1. O detalhamento deve ser aumentado. 2. O detalhamento no precisa ser modificado. 3. O detalhamento deve ser diminudo.

1. No usada nos projetos e no acredito ser relevante 2. No usada, mas gostaria de usar. 3. Usada, parcialmente. 4. usada.

1. No til. 2. Provavelmente til, mas ainda no apliquei. 3. til e j apliquei em diferentes projetos.

Tabela 12: Questionrio da lista de prticas de engenharia de requisitos.

Prtica

Descrio

Presena

Utilidade Adequao

rea de processo - Gerenciamento de Requisitos PE 01 - Obteno do Entendimento dos Requisitos 1 2 1.1 Entendimento do significado dos requisitos
Existe um entendimento do significado dos requisitos com os fornecedores de requisitos.

70

1.2 Identificao dos fornecedores de requisitos 1.3 Obteno do aceite

estabelecido critrios para identificar esses fornecedores. Existe critrios objetivos para receber o aceite de requisitos dos fornecedores. Os requisitos so analisados para garantir que estes satisfaam os critrios estabelecidos. Considerando as respostas (1.1, 1.2, 1.3 e 1.4) Sua opinio relacionada prtica de obteno do entendimento dos requisitos.

1.4 Anlise dos requisitos.

01

Obteno do Entendimento dos Requisitos

PE 02 - Obteno do Comprometimento dos Requisitos 1 2 2.1 Comprometimento dos participantes

Existe o comprometimento dos participantes do projeto com os requisitos acordados. Negociado e registrado os compromissos. Os impactos dos requisitos nos compromissos existentes so avaliados.

2.2 Registro do Comprometimento 2.3 Avaliar Impactos

02

Obteno do Comprometimento dos Requisitos

Considerando as respostas (2.1, 2.2 e 2.3) Sua opinio relacionada prtica de Obteno do Comprometimento dos Requisitos.

71

PE 03 - Gerenciar mudanas de requisitos 1 2 3.1 Identificao da fonte das mudanas

So identificadas as fontes de cada requisitos e as razes de suas mudanas.

3.2 Histrico das mudanas

O histrico de mudanas so mantidos.

3.3 Anlise de impacto

Existe a etapa de anlises de impacto.

3.4 Disponibilizao das mudanas

Informaes sobre os requisitos e mudanas so disponibilizadas para o restante do projeto. Considerando as respostas (3.1, 3.2, 3.3 e 3.4) Sua opinio relacionada prtica de Gerenciar mudanas de requisitos.

03

Gerenciar mudanas de requisitos

PE 04 Manter a Rastreabilidade Bidirecional dos Requisitos 1 2 4.1 Identificao da necessidade 4.2 Identificao da existncia 4.3 Requisitos relacionados 4.4 Relao com outras informaes
possvel identificar de quem a necessidade que gerou o requisito. possvel identificar por que o requisitos existe. possvel identificar quais os requisitos relacionados. possvel identificar como os requisitos se relacionam a outras informaes como design, implementaes e outros documentos.

72

04

Manter a Rastreabilidade Bidirecional dos Requisitos

Considerando as respostas (4.1, 4.2, 4.3 e 4.4) Sua opinio relacionada prtica de Manter a Rastreabilidade Bidirecional dos Requisitos.

PE 05 - Identificar Inconsistncias Entre Artefatos do Projeto e Requisitos 1 2 5.1 Analise dos requisitos
A anlise dos requisitos so feitas de forma criteriosa.

5.2 Aes corretivas

Existe uma tomada de aes corretivas para evitar a inconsistncias. Existe algum trabalho realizado para descobrir as fontes e as causas das inconsistncias.

5.3 Descobrimento das fontes

05

Identificar Inconsistncias Entre Artefatos do Projeto e Requisitos

Considerando as respostas (5.1, 5.2 e 5.3) Sua opinio relacionada prtica de Identificar Inconsistncias Entre Artefatos do Projeto e Requisitos.

rea de processo Desenvolvimento de Requisitos 1 2 06 Coleta das necessidades

Existe a coleta das necessidades dos stakeholders.

07

Elicitar as necessidades

Existem mtodos para a elicitao das necessidades, expectativas, restries dos requisitos junto aos stakeholders.

73

08

Desenvolver os Requisitos dos clientes

O desenvolvimento dos requisitos so acompanhados para identificar se esto de acordo com o solicitado pelo cliente estando Validados e Verificao. Os requisitos so detalhados nas funcionalidades, caractersticas, tecnologia e os custos desses atendimentos so levantados.

09

Estabelecer os requisitos dos produtos e seus componentes

10

Alocao dos requisitos dos componentes dos produtos

Existe a transformao das necessidades dos stakeholders requisitos do produto e uma alocao e distribuio dos requisitos nos componentes do produto. Existe o detalhamento das interfaces de entrada e sada.

11

Identificar os requisitos de interfaces

12

Conceitos operacionais e cenrios

As seqncias de eventos possveis com os fluxos descritos em casos de uso Alm da preocupao com a instalao, manuteno e suporte do produto. Existe uma definio das funcionalidades requeridas em forma de caso de uso e diagramas de atividades. realizado o relatrio de incompletudes e inconsistncias dos requisitos e existe uma definio de priorizao dos requisitos.

13

Definio das funcionalidades requeridas

14

Analisar os requisitos

74

15

Analisar os requisitos para avaliao

Os riscos das necessidades dos usurios so avaliados

16

Validar os requisitos

utilizado algum tipo de relatrio de validao dos requisitos.

3.4.4 RESULTADO DO ESTUDO 3.4.4.1 RESULTADO DO ESTUDO A Tabela 13 apresenta o resultado sintetizado em relao as respostas apresentadas pelos participantes do experimento.
Tabela 13: Resultado das entrevistas.

rea de processo - Gerenciamento de Requisitos N 01 Prtica Obteno do Entendimento dos Requisitos Presena: 4 - Parcialmente presente 02 Obteno do Comprometimento dos Requisitos Presena: 4 - Ausente gostaria de usar. 03 Utilidade: 4 - til e no usada Adequao: 4 - Aumentar detalhamento Utilidade: 4 - til e usada Adequao: 4 - Aumentar detalhamento Descrio Sua opinio relacionada prtica de obteno do entendimento dos requisitos.

Sua opinio relacionada prtica de Obteno do Comprometimento dos Requisitos.

Gerenciar mudanas Sua opinio relacionada prtica de Gerenciar

75

de requisitos

mudanas de requisitos.

Presena:

Utilidade:

Adequao: 4 - Aumentar detalhamento

4 - Parcialmente presente. 4 - til e usada

rea de processo - Gerenciamento de Requisitos N 04 Prtica Manter a Rastreabilidade Bidirecional dos Requisitos. Presena: Utilidade: Adequao: 4 - Aumentar detalhamento Descrio Sua opinio relacionada prtica de Manter a Rastreabilidade Bidirecional dos Requisitos.

4 - Parcialmente presente 4 - til e usada 05 Identificar

Sua opinio relacionada prtica de Identificar Entre Artefatos do Projeto e

Inconsistncias Entre Inconsistncias Artefatos do Projeto Requisitos. e Requisitos Presena: 4 - Parcialmente presente Utilidade: 4 - til e usada

Adequao: 4 - Aumentar detalhamento

rea de processo - Desenvolvimento de Requisitos N 06 Prtica Coleta das necessidades Presena: 3 - Parcialmente presente 1 - Presente Utilidade: 4 - til e usada Adequao: 4 - Aumentar detalhamento Descrio Existe a coleta das necessidades dos stakeholders.

76

07

Elicitar as necessidades

Existem mtodos para a elicitao das necessidades, expectativas, restries dos requisitos junto aos stakeholders.

Presena: 4 - Ausente gostaria de usar 08 Desenvolver os Requisitos dos clientes

Utilidade: 4 - til e no usada

Adequao: 4 - Aumentar detalhamento

O desenvolvimento dos requisitos so acompanhados para identificar se esto de acordo com o solicitado pelo cliente estando Validados e Verificao.

Presena: 1 - Parcialmente presente 3 - Usada

Utilidade: 4 - til e usada

Adequao: 4 - Aumentar detalhamento

rea de processo - Desenvolvimento de Requisitos N 09 Prtica Estabelecer os requisitos dos produtos e seus componentes Presena: 4 - Ausente gostaria de usar 10 Alocao dos requisitos dos componentes dos produtos Presena: 1 - Ausente gostaria de usar Utilidade: 4 - til e no usada Adequao: 4 - Aumentar detalhamento Descrio Existe a coleta das necessidades dos stakeholders.

Existe a transformao das necessidades dos stakeholders requisitos do produto e uma alocao e distribuio dos requisitos nos componentes do produto. Utilidade: 1 - til e no usada Adequao: 4 - Aumentar detalhamento

77

3 Parcialmente presente 11 Identificar os requisitos de interfaces Presena: 4 - Usada

3 - til e usada Existe o detalhamento das interfaces de entrada e sada.

Utilidade: 4 - til e usada

Adequao: 3 - Aumentar detalhamento 1 no precisa modificar

rea de processo - Desenvolvimento de Requisitos N 12 Prtica Conceitos operacionais e cenrios Presena: 4 - Ausente gostaria de usar 13 Definio das funcionalidades requeridas Presena: 3 - Ausente gostaria de usar 1 Parcialmente presente 14 Analisar os requisitos Utilidade: 3 - til e no usada 1 - til e usada realizado o relatrio de incompletudes e inconsistncias dos requisitos e existe uma definio de priorizao dos requisitos. Presena: 4 - Ausente gostaria de usar Utilidade: 4 - til e no usada Adequao: 4 - Aumentar detalhamento Adequao: 4 - Aumentar detalhamento Descrio As seqncias de eventos possveis com os fluxos descritos em casos de uso Alm da preocupao com a instalao, manuteno e suporte do produto. Utilidade: 4 - til e no usada Adequao: 4 - Aumentar detalhamento

Existe uma definio das funcionalidades requeridas em forma de caso de uso e diagramas de atividades.

78

rea de processo - Desenvolvimento de Requisitos N 15 Prtica Analisar os requisitos para avaliao Presena: 3 - Ausente gostaria de usar 1 Parcialmente presente 16 Validar os requisitos Descrio Os riscos das necessidades dos usurios so avaliados Utilidade: 3 - til e no usada 1 - til e usada utilizado algum tipo de relatrio de validao dos requisitos. Presena: 4 - Ausente gostaria de usar Utilidade: 4 - til e no usada Adequao: 4 - Aumentar detalhamento Adequao: 4 - Aumentar detalhamento

3.4.4.2 PERFIS DOS PARTICIPANTES O perfil dos participantes do experimento est detalhado abaixo em tabelas e grficos. A Tabela 14 exibe os dados dos participantes que responderam os questionrios em relao a sua formao, profisso, tempo de experincia em desenvolvimento de sistemas e os cargos que o entrevistado ocupou na empresa. A Tabela 15 uma legenda que auxilia o entendimento das informaes da Tabela 14. O grfico da Figura 5 mostra a distribuicao dos dados dos proissionais entrevistados em relao a formacao, profisso e tempo de experiencia

79

Tabela 14: Perfil dos participantes.

Nmero

do Formao

Profisso

Tempo experincia

de Cargos ocupados Empresa na

Participante

1 2 3 4

1 2 3 3

2 2 2 3

15 9 6 10

1;2 1; 2 2 2; 3

Tabela 15: Legenda de auxlio da tabela 11

Formao 1 2 3 Tcnico Graduado Ps-Graduado 1 2 3

Profisso Programador Analista de Sistemas Coordenador 1 2 3

Cargos ocupados Programador Analista de Sistemas Coordenador

Figura 5: Distribuio dos dados dos profissionais entrevistados

16 14 12 10 8 6 4 2 0 1 2 3 4 Formao Profisso Tempo de experincia

80

3.5 ANLISE E INTERPRETAO DOS RESULTADOS 3.5.1 VALIDAO DOS RESULTADOS Todas as respostas foram consideradas vlidas do ponto de vista dos valores de presena, utilidade e adequao (PUA). 3.5.2 ESTATSTICA DESCRITIVA Medidas de tendncia central, como os valores "Presena", "Utilidade" e "Adequao", so da escala ordinal, sendo possvel definir somente as mtricas de "moda" e "mediana". A Tabela 16 exibe a mediana e a moda referente s respostas dadas pelos entrevistados em relao presena ou no das prticas. J a Tabela 17 exibe Mediana e Moda referente s respostas sobre a utilidade das prticas sugeridas pelo CMMI no processo da empresa. A Tabela 18 exibe Mediana e Moda referente s respostas sobre a adequao das prticas sugeridas pelo CMMI no processo da empresa.

Tabela 16: Mediana e Moda referente as respostas sobre a presence das prticas no processo da empresa.

Prticas
1 Mediana Moda 3 3 2 2 2 3 3 3 4 3 3 5 3 3 6 3 3 7 2 2 8 4 4 9 10 2 3 2 3 11 4 4 12 2 2 13 2 2 14 2 2 15 2 2 16 2 2

81

Tabela 17: Mediana e Moda referente s respostas sobre a utilidade das prticas sugeridas pelo CMMI no processo da empresa.

Prticas
1 Mediana Moda 3 3 2 2 2 3 3 3 4 3 3 5 3 3 6 3 3 7 3 3 8 3 3 9 10 3 3 3 3 11 3 3 12 2 2 13 2 2 14 2 2 15 2 2 16 2 2

Tabela 18: Mediana e Moda referente s respostas sobre a adequao das prticas sugeridas pelo CMMI no processo da empresa.

Prticas
1 Mediana Moda 1 1 2 1 1 3 1 1 4 1 1 5 1 1 6 1 1 7 1 1 8 1 1 9 10 1 1 1 1 11 1 1 12 1 1 13 1 1 14 1 1 15 1 1 16 1 1

As respostas levantadas nos questionrios precisaram ser ajustadas para se adequarem aos resultados de presena, utilidade e adequao. Para isso, foram consideradas prticas presentes, as que apresentaram mediana e moda iguais a trs ou quatro na Tabela 16. Por conseqncia as prticas consideradas ausentes foram as que apresentaram valores iguais a um e dois. Foram consideradas prticas teis, as que apresentaram valores iguais a dois ou trs na Tabela 17. As que apresentaram valores iguais a um foram consideradas inteis, o que no aconteceu; ou seja, todas as prticas foram consideradas teis. Nesse estudo as prticas consideradas adequadas deveriam apresentar o valor dois, em relao Tabela 18, enquanto que as prticas que precisavam ser mais detalhadas e melhores adequadas tiveram valores iguais a um e trs. Considerando as respostas dos participantes do experimento e utilizando os resultados de estatstica descritiva, as respostas dadas pelos participantes do experimento podem ser divididas em trs grupos, listados abaixo:

82

O grupo de prticas que so usadas plenamente nos projetos da empresa, consideradas teis e que os profissionais acreditam que poderiam ser melhoradas para se adequar as necessidades e ajudar mais nos projetos.
Tabela 19: Lista de prticas usadas parcialmente. Legenda: P - Presente (Parcialmente ou no):No presente U - til (j usou ou

acha til):Intil A - Adequado:Inadequado (precisa ser aumentado ou diminudo)

N Prticas 08 Desenvolver Requisitos clientes

P os 4:0 dos

U 4:0

A 0:4

Caractersticas As prticas so usadas

plenamente pelos projetos; As prticas so consideradas teis e j foram aplicadas pelos profissionais

11 Identificar requisitos interfaces

os 4:0 de

4:0

1:3

entrevistados da empresa; O detalhamento deve ser

aumentado, que ainda

provavelmente podem ser

porque os profissionais acham melhorados, mas estranho serem usados plenamente e mesmo assim precisarem ser mais detalhados.

83

O grupo de praticas que so parcialmente usadas nos projetos da empresa, consideradas teis e que os profissionais acreditam que poderiam ser melhoradas para se adequar as necessidades e ajudar mais nos projetos.
Tabela 20: Lista de prticas usadas plenamente Legenda: P - Presente (Parcialmente ou no):No presente U - til (j usou ou acha

til):Intil A - Adequado:Inadequado (precisa ser aumentado ou diminudo)

N 01

Prticas Obter entendimento requisitos

P um 4:0 dos

U 4:0

A 1:3

Caractersticas As prticas que so usadas

parcialmente

plenamente pelos projetos; mudanas 4:0 4:0 0:4 As prticas so consideradas teis e j foram aplicadas 4:0 de 4:0 0:4 pelos profissionais entrevistados da empresa; O detalhamento do uso das prticas deve ser aumentado. 4:0 entre 4:0 0:4

03

Gerenciar

de requisitos 04 Manter rastreabilidade bidirecional requisitos 05 Identificar inconsistncias requisitos 06 Coleta necessidades 10 Alocao requisitos componentes produtos dos 3:1 dos dos 4:0 0:4 das 4:0 4:0 0:4 artefatos do projeto e

84

O grupo de praticas que no so usadas nos projetos da empresa, consideradas teis e que os profissionais entrevistados gostariam de utilizar nos projetos.
Tabela 21: Lista de prticas no usadas que gostariam de usar Legenda: P - Presente (Parcialmente ou no):No presente U - til (j usou ou

acha til):Intil A - Adequado:Inadequado (precisa ser aumentado ou diminudo)

N Prticas Obter 02 comprometimento com requisitos 07 Elicitar necessidades 09 Estabelecer requisitos produtos e componentes Conceitos 12 operacionais e cenrios Definio das 13 funcionalidades requeridas Analisar os 14 requisitos Analisar os 15 requisitos para avaliao Validar os 16 requisitos

P 0:4

U 4:0

A 0:4

Caractersticas As prticas no so usadas pelos projetos;

as 0:4

4:0

0:4

As prticas so consideradas teis e os profissionais da empresa entrevistados

os 1:3 dos seus

4:0

0:4

gostariam de usar; O detalhamento do uso das prticas deve ser aumentado.

0:4 1:3

4:0 4:0

0:4 0:4

0:4 1:3 0:4

4:0 4:0 4:0

0:4 0:4 0:4

85

3.5.3 ANLISE DOS RESULTADOS 3.5.3.1 ANLISE QUANTITATIVA Para realizar a anlise quantitativa precisam-se saber os valores das respostas dos participantes em relao presena da prtica (0 no usada; 1 usada); utilidade da prtica (0 no til; 1 til) e adequao da prtica (0 o nvel adequado, 1 o nvel no adequado). A Tabela 22 exibe esse resultado.

Tabela 22: Relao das respostas quantificadas.

N 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16

Prtica Obter um entendimento dos requisitos Obter comprometimento com requisitos Gerenciar mudanas de requisitos Manter rastreabilidade bidirecional de requisitos Identificar inconsistncias entre artefatos do projeto e requisitos Coleta das necessidades Elicitar as necessidades Desenvolver os Requisitos dos clientes Estabelecer os requisitos dos produtos e seus componentes Alocao dos requisitos dos componentes dos produtos Identificar os requisitos de interfaces Conceitos operacionais e cenrios Definio das funcionalidades requeridas Analisar os requisitos Analisar os requisitos para avaliao Validar os requisitos

P 1 0 1 1 1 1 0 1 0 1 1 0 0 0 0 0

U 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

A 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Com finalidade de verificar a similaridade entre as prticas especficas exigidas pelo CMMI e as prticas utilizadas pelos projetos, a partir das respostas listadas na Tabela 22, foi calculado o valor de varivel dependente. 1. Os conjuntos das prticas da engenharia de requisitos usadas nos projetos da empresa e as prticas especficas da engenharia de requisitos exigidas pelo CMMI no podem ser consideradas iguais (a quantidade de prticas com o valor PUA {1, X, X} = 8<16) nem diferentes (a quantidade de prticas com o valor PUA {0, X, X}

86

8<16). Com isso a frmula do grau de similaridade pode ser calculada da seguinte forma: varivel 1: grau de similaridade = 8 / 18 * 100% = 50,00% A verificao da utilidade das prticas de engenharia de requisitos do CMMI que so similares as prticas de engenharia de requisitos empregadas nos projetos, feita atravs do clculo do valor de varivel dependente 2: Parte til das prticas similares: 8 / 8 * 100% = 100% Parte intil das prticas similares: 0 / 8 * 100% = 0% A verificao da adequao das prticas de engenharia de requisitos do CMMI que so similares as prticas de engenharia de requisitos empregadas nos projetos, feita atravs do clculo do valor de varivel dependente 3: Parte adequada das prticas similares: 0 / 8 * 100% = 0% Parte inadequada das prticas similares: 8 / 8 * 100% = 100% 3.5.3.2 ANLISE QUALITATIVA A verificao da existncia das prticas especficas da engenharia de requisitos exigidas pelo CMMI que no so utilizadas pelos projetos da empresa, mas que a empresa gostaria de utilizar foi feita atravs do uso da anlise qualitativa. A Tabela 23 mostra a lista das prticas especficas da engenharia de requisitos exigidas pelo CMMI que no so utilizadas pelos projetos da empresa, mas que a empresa gostaria de utilizar:
Tabela 23: Lista das prticas que no foram usadas.

N 02 07 09 12

Prtica Obter comprometimento com requisitos Elicitar as necessidades Estabelecer os requisitos dos produtos e seus componentes Conceitos operacionais e cenrios

P 0 0 0 0

U 1 1 1 1

A 1 1 1 1

87

13 14 15 16

Definio das funcionalidades requeridas Analisar os requisitos Analisar os requisitos para avaliao Validar os requisitos

0 0 0 0

1 1 1 1

1 1 1 1

A partir dessas informaes pode-se concluir que todas as prticas de engenharia de requisitos exigidas pelo CMMI so consideradas teis pelos participantes, includo as prticas que no esta sendo utilizadas. 3.5.3.3 VERIFICAO DAS HIPTESES Hiptese nula (H0): Para verificar a hiptese nula precisamos responder a questo Q1 utilizando a mtrica M4. O resultado das entrevistas, exibido na Tabela 22, mostra que oito das dezesseis prticas especificas da engenharia de software exigidas pelo CMMI no esto sendo utilizadas nos projetos da empresa. Assim, pode-se, concluir que nem todas as prticas especficas da engenharia de requisitos exigidas pelo CMMI fazem parte dos projetos de integrao da empresa (hiptese alternativa H1). De acordo com os resultados da Tabela 22, todas as oito prticas que no so usadas nos projetos foram consideradas teis pelos participantes do experimento. Ou seja, ainda existem prticas especficas da engenharia de software exigidas pelo CMMI que no so utilizados nos projetos da empresa, mas que a empresa gostaria de utilizar (hiptese alternativa H2). Finalmente, pode-se afirmar que na lista das prticas especficas da engenharia de software exigidas pelo CMMI no existe alguma prtica que a empresa ache intil (hiptese alternativa H3), pois o resultado da Tabela 22 mostra que todas as prticas foram consideradas teis pelos participantes do experimento. Um dado relevante que nenhuma prtica especfica foi considerada adequada (hiptese alternativa H4). Ento, pode-se concluir que mesmo as prticas especficas presentes nos projetos so consideradas pelos participantes do

88

experimento inadequadas, ou seja, a adequao da prtica relacionada ao seu detalhamento precisa ser melhorada. 3.6 CONCLUSES 3.6.1 CARACTERIZAO A caracterizao do processo de engenharia de requisitos da empresa mostrou que existem ainda oito prticas especficas que no so utilizadas. Observou-se que nenhuma das prticas utilizadas nos projetos considerada totalmente adequada. O resultado mostra tambm que apesar de no utilizar todas as prticas, os participantes acharam todas elas teis, sinalizando o desejo de utiliz-las. Em relao ao CMMI, considerando as respostas relacionadas a uso total e parcial nos projetos, o resultado mostra que a empresa utiliza a maioria das prticas especficas da rea de processo de gesto de requisitos. Apenas uma das cinco prticas no foi utilizada nos projetos. Em relao s prticas especficas da rea de processo de desenvolvimento de requisitos, os resultados se inverteram, e, das onze prticas, apenas quatro foram utilizadas, totalmente ou parcialmente, nos projetos, significando que a empresa possui um processo de gesto de requisitos mais forte que o prprio desenvolvimento deles. 3.6.2 PONTOS FORTES O estudo apontou que a empresa utiliza quatro das cinco prticas da engenharia de requisitos da rea de processo de gesto de requisitos exigidas pelo CMMI. Outro ponto positivo apontado no experimento que todas as prticas da engenharia de requisitos utilizadas nos projetos, que so exigidas pelo CMMI, foram consideradas teis.

89

3.6.3 PONTOS DE MELHORIA Todas as prticas da engenharia de requisitos utilizadas nos projetos da empresa foram consideradas inadequadas, ou seja, poderiam ser melhoradas para atender melhor os projetos da empresa. Um risco apontado pelo estudo que a empresa no se preocupa em receber dos clientes o comprometimento dos participantes dos projetos com os requisitos acordados. Essa prtica objetiva o comprometimento com os requisitos e pode evitar mudanas desnecessrias nos requisitos. A falta de um mtodo de elicitao de necessidades e expectativas dos requisitos junto aos stakeholders pode gerar no futuro um produto que no atende as necessidades dos mais interessados. Outro ponto falho relacionado engenharia de requisitos nos projetos, que no existe um mtodo definido que realize o levantamento dos requisitos de produtos e seus componentes. Isso pode causar uma surpresa no que diz respeito aos custos do projeto, pois essa prtica usada para levantar as necessidades relacionadas a caractersticas e tecnologia e essas caractersticas podem virar exigncias que gerem, para a empresa, a necessidade de adquirir alguma tecnologia. A falta da prtica especifica que estabelece os conceitos operacionais e cenrios pode gerar para os clientes um mau entendimento dos requisitos levantados, pois os usurios no tero a viso de fluxo do processo do requisito levantado. Os casos de uso que so levantados tambm so boas prticas para levantar cenrios que podem ajudar no entendimento dos requisitos, tanto do ponto de vista dos clientes, quanto dos desenvolvedores. O no uso da prtica de anlise de requisitos, que tem como objetivo analisar as inconsistncias, incompletudes e definir a priorizao dos requisitos, tambm um ponto a ser melhorado no processo de engenharia de requisitos da empresa. Como tambm a falta da avaliao das necessidades dos usurios que pode gerar mais demandas de incluso e alterao de requisitos fechados.

90

Por fim, o ponto mais alarmante: a falta da prtica de validao de requisitos. No ter um processo de validao de requisitos bem definido, pode levar a empresa a desenvolver requisitos que no se adeque as expectativas dos clientes, correndo o risco de invalidar todo o projeto.

91

CONSIDERAES FINAIS
A experimentao oferece uma maneira de caracterizar e comparar as novas

invenes publicadas ou apresentadas ou, ainda, processos e prticas utilizadas em empresas com os processos e prticas existentes e com isso, obter uma concluso do uso do processo, prtica ou inveno, permitindo um aperfeioamento de seu uso. Esse trabalho forneceu importantes contribuies na rea de pesquisa de engenharia de software experimental e na rea de engenharia de requisitos em relao s prticas especficas do CMMI, so elas: O uso da engenharia de software experimental para caracterizar o processo de engenharia de requisitos; Um levantamento das prticas especficas de engenharia de requisitos do CMMI; Uma comparao entre as prticas de engenharia de requisitos dos projetos de uma empresa com as prticas especficas de engenharia de requisitos do CMMI, levando em considerao a presena das prticas, utilidade e adequao. Durante o desenvolvimento desse trabalho foram identificadas cinco hipteses que estruturaram e direcionaram a presente pesquisa, relacionando as prticas especficas de engenharia de requisitos exigidas pelo CMMI quanto presena, utilidade e adequao dessas prticas no ambiente da empresa. Presena das prticas: Foi verificado que nem todas as prticas especficas da engenharia de requisitos exigida pelo CMMI esto presentes nos projetos da empresa. Utilidade das prticas: Foi verificado que todas as prticas especficas da engenharia de requisitos exigida pelo CMMI foram consideradas teis, mesmo aquelas que no so usadas nos projetos.

92

Adequao das prticas: Foi verificado que todas as prticas especficas da engenharia de requisitos exigida pelo CMMI no esto adequadas quanto ao seu detalhamento e precisam ser melhoradas O presente trabalho forneceu uma alternativa para se obter uma caracterizao no processo de engenharia de requisitos, que pode servir para ser usado em estudos e anlises direcionadas para melhorias no processo, utilizando engenharia de software experimental.

4.1 TRABALHOS FUTUROS Existem vrias possibilidades de desdobramento desta pesquisa, tais como: 1. Replicar este experimento para confirmar os resultados; 2. Aplicar o experimento em todos os projetos da empresa e no apenas em projetos de integrao; 3. Aplicar esse experimento utilizando outros modelos tericos, como o MPS.BR; 4. Aplicar esse experimento nas outras reas de conhecimento da engenharia de software, modificando o questionrio; 5. Ampliar o experimento para servir de apoio para as empresas que desejam se certificar no CMMI.

93

REFERNCIAS
BARROS, M. O.; WERNER, C. M. L.; TRAVASSOS, G. H. Um Estudo Experimental sobre a Utilizao de Modelagem e Simulao no Apoio Gerncia de Projetos de Software Anais do XVI Simpsio Brasileiro de Engenharia de Software, Florianpolis, 1999. BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. Goal Question Metric paradigm. In: MARCINIAK, Encyclopedia of Software Engineering. New York: John Wiley & Sons, 1994a. BASILI, V., CALDEIRA, G., ROMBACH, H., Experience Factory, In: Encyclopedia of Software Engineering, New York: John Wiley & Sons, 1994b. BOEHM, B. W. Software Engineering Economics. Englewood Cliffs, NJ: PrenticeHall, 1981. BOEHM, B. W.; PAPACCIO, P. N. Understanding and Controlling Software Costs, IEEE Transactions on Software Engineering, v.14, n.10, p.1462-1477, 1988. CAMPBELL, D. T.; STANLEY, J.C. Experimental and Quasi-Experimental Designs for Research, Massachusetts: Houghton Mifflin Company, Boston, 1963. Capability Maturity Model Integration (CMMI). Disponvel em:

http://www.sei.cmu.edu/cmmi. Acessado em: 25/05/2009. COCKBURN, A.; Writing Effective UCs; Addison Wesley, 2001 COOK, D. T.; CAMPBELL, D. T. Quasi-Experimentation-Design and Analisys Issues for Field Settings, Massachusetts: Houghton Mifflin Company, Boston, 1979. DAVIS, G. B. Strategies for Information Requirements Determination. IBM System Journal, v. 21, n. 1, pp. 4-30, 1982.

94

DE BORTOLI, L. A., PRICE, A. M. A. O Uso de Workflow para Apoiar a Elicitao de Requisitos. In: Workshop em Engenharia de Requisitos (WER06). pp. 22-37. Rio de Janeiro: PUC-Rio, 2000. DEMARCO, T. Controlling software Projects, Nova York: Yourdon press, 1982. EL EMAM. Causal Analyses of the Requirements Change Process for a Large System. IESE-Report No. 054.97/E, 1997. FENTON, N.; PFLEEGER, S. L. Software metrics: A rigorous & practical approach, 2a edio, International Thomson Computer Press, 1996. FLEMING, J. C. Implementing Software Engineering Practices in Small Industry with a Focus on Requirements Elicitation. Dissertao (Mestrado em Cincia da Computaco). West Virginia University, Estados Unidos, 2003. FOWLER, M. ; SCOTT, K. UML Distiled: Applying the standard object modeling language, Addison-wesley, 1997. GILB, T. Principles of Software Engineering Management. Reading, MA: AddisonWesley, 1999. GOGUEN, J.A.; JIROTKA, M. Requirements Engineering: social and technical issues San Diego: Academic Press Professional, 1994. GOTTESDIENER, E. Requirements by Collaboration. Reading, MA: Addison-Wesley, 2002. JACOBSON, I. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1st edition, 1992. KITCHENHAM, B.; PICKARD, L. ; PFLEEGER, S.L. Case studies fot method and tool evaluation. IEEE software. Julho, pp52-62, 1995

95

KOTONYA,

G.;

SOMMERVILLE

I. Requirements

Engineering:

Processes

and

Techniques. New York: John Wiley & Sons, 1998. KULAK, D. Use Cases Requirements in Context. New York: Addison-Wesley, 2001. LEFFINGWELL, D.; WIDRIG, D. Managing Software Requirements. Addison Wesley, Second Edition, 2002 MACEDO, N. A. M.; LEITE, J. C. S. P. Elicit@99: um prottipo de ferramenta para a elicitao de requisitos. In: Workshop em Engenharia de Requisitos. Buenos Aires, 1999. PARKER, A., Commons Committee Calls for Action on IT Fiascos. Financial Times. London, 2000. PRESSMAN, Roger S., Engenharia de software, 6 Edio. So Paulo: Ed. McGraw Hill, 2006. RANGER, S. State IT Failures Squander 1bn: our survey counts the cost of Pathway, NIRS2 and the rest. Computing, n. 5, p. 1, 2001. SOLINGEN, R.; BERGHOUT, E. The Goal/Question/Metric Method: a Practical Guide for Quality Improvement of Software Development, Londres: McGraw-Hill Companies, 1999. SOMMERVILLE, I. Engenharia de software, 8 Edio. So Paulo: Ed. Pearson, 2008. SOMMERVILLE, I.; SAWYER, P. Requirements Engineering: a good practice guide New York: John Wiley & Sons, 1999. SWEBOK Guide to the Software Engineering Body of Knowlegment, Disponvel em: http://www2.computer.org/portal/web/swebok/htmlformat. Acessado em: 19/05/2009. TRAVASSOS, G. H. Introduo Engenharia de Software Experimental. Relatrio Tcnico COPPE, UFRJ, Rio de Janeiro, 2002.

96

WALIA, G. S. ; CARVER, J. C. A systematic literature review to identify and classify software requirement errors. Information and software technology, v.51, p. 10871109, 2009 WOHLIN, C.; RUNESON, P.; HOST, M.; REGNELL, B.; WESSLEN, A. Experimentation in Software Engineering: An Introduction, Massachusetts: Ed. Kluwer Academic Publishers, 2000. ZAHNISHER, R. A. Building software in groups, American Programmer, v. 3 n.7,1990. ZULTNER, R. E. Quality Function Deployment (QFD) for Software: Structured Requirements Exploration, in Schulmeyer, G. G. and J. I. McManus, ed., Total Quality Management for Software, Van Nostrand Reinhold, New York NY, 1992.