C.E.S.A.

R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

CRISTIANO TAVARES SILVA

Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às práticas específicas do CMMI

RECIFE 2010

CRISTIANO TAVARES SILVA

Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às práticas específicas do CMMI
Dissertação apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Mestre em Engenharia de Software. Orientação: Prof. Dr. Vinicius Cardoso Garcia

RECIFE 2010

ii

iii

C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às práticas específicas do CMMI CRISTIANO TAVARES SILVA

Dissertação apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Mestre em Engenharia de Software. Data de aprovação: _____ / _____ / 2010. Banca examinadora: _________________________________ Prof.(a).Dr.(a) *** ***instituição*** _________________________________ Prof.(a).Dr.(a) *** ***instituição*** _________________________________
Prof.(a).Dr.(a)

***instituição***

iv

2

AGRADECIMENTOS

Primeiramente, agradeço a Deus por tudo que tenho conquistado, pela família que possuo, por todos os obstáculos que Ele ajuda a remover e por toda a força que Ele me dá para ultrapassar os limites do meu ser. Agradeço em especial a minha amada esposa Viviane, sem ela, esse sonho e muitos outros não teriam se concretizado, sem a sua eterna compreensão e incentivo, eu não teria conseguido. À minha querida filha Maria Clara, que muitas vezes acreditou mais em mim do que eu mesmo. Sempre compreendeu a minha ausência em muitos momentos durante a realização deste trabalho e que, com o seu sorriso e seu abraço, renovavam as minhas forças. 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 confiança em mim, por todo o conhecimento transmitido, suas críticas e sugestões 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 realização deste trabalho.

3

RESUMO

A crescente globalização dos negócios e o ambiente competitivo estimulam as empresas a investirem na melhoria contínua dos seus processos internos. Diante deste cenário, os investimentos em Tecnologia da Informação são inevitáveis e, com isso, o surgimento de soluções teóricas de melhorias de processo tem sido grande. Mesmo assim, adotar um processo novo a partir de um modelo teórico não significa que irá funcionar no ambiente organizacional, levando em consideração estrutura, equipe e mentalidade da empresa. Dentre os processos que envolvem o desenvolvimento de sistemas, existe a engenharia de requisitos. Como a existência desse processo é mais forte no início do ciclo de vida de um sistema, sua importância é grande, pois um entendimento errado nessa fase pode gerar um sistema em desacordo com as necessidades a que ele foi projetado. Existem modelos teóricos da engenharia de requisitos que sugerem as melhores práticas. Um dos modelos mais difundidos no Brasil é o Modelo CMMI, que é inclusive um órgão certificador de empresas de tecnologia da informação. Mesmo assim, não existe a garantia que os modelos teóricos, como o CMMI, estão adequados cem por cento ao ambiente de todas as empresas. Por isso aperfeiçoar os processos das empresas de desenvolvimento para moldar-los ao ambiente operacional da empresa é muito importante. Atualmente a engenharia de software experimental, que é estudo empírico sobre a própria 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 comparação com as práticas específicas da engenharia de requisitos do CMMI.
PALAVRAS-CHAVES: Engenharia de Software Experimental. Engenharia de requisitos. CMMI.

4

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.

5

SUMÁRIO
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 INTRODUÇÃO ............................................................................................. 1 MOTIVAÇÃO................................................................................................ 5 MOTIVAÇÃO DE MERCADO ...................................................................... 5 MOTIVAÇÃO TÉCNICA ............................................................................... 6 PROBLEMA ................................................................................................. 6 OBJETIVO GERAL ...................................................................................... 6 OBJETIVOS ESPECÍFICOS ........................................................................ 7 JUSTIFICATIVA ........................................................................................... 7 CONTRIBUIÇÕES ....................................................................................... 8 ESTRUTURA DA DISSERTAÇÃO ............................................................... 9 REVISÃO BIBLIOGRÁFICA...................................................................... 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 MEDIÇÃO .................................................................................................. 41 VALIDADE ................................................................................................. 43 TIPOS DE EXPERIMENTOS ..................................................................... 44 PROCESSO ............................................................................................... 45 SOLUÇÃO PROPOSTA ............................................................................ 50 A EMPRESA .............................................................................................. 50 DEFINIÇÃO DOS OBJETIVOS .................................................................. 50 OBJETIVO GLOBAL: ................................................................................. 50 OBJETIVO DA MEDIÇÃO: ......................................................................... 50 OBJETIVO DO ESTUDO: .......................................................................... 51 QUESTÕES ............................................................................................... 51

3.3 PLANEJAMENTO ...................................................................................... 53 3.3.1 DEFINIÇÃO DAS HIPÓTESES .................................................................. 53 3.3.2 DESCRIÇÃO DA INSTRUMENTAÇÃO ..................................................... 54 3.3.3 SELEÇÃO DE CONTEXTO ....................................................................... 56 3.3.4 SELEÇÃO DOS INDIVÍDUOS.................................................................... 56 3.3.5 VARIÁVEIS ................................................................................................ 56 3.3.5.1 VARIÁVEIS INDEPENDENTES: .............................................................. 56 3.3.5.2 VARIÁVEIS DEPENDENTES: .................................................................. 56 3.3.6 ANÁLISE QUALITATIVA ............................................................................ 57 3.3.7 VALIDADE ................................................................................................. 57 3.4 3.4.1 OPERAÇÃO ............................................................................................... 59 MATERIAL INFORMATIVO DAS PRÁTICAS ESPECÍFICAS DO CMMI ......................................................................................................... 59

6

QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES .............................. 68 3.4.2 3.4.3 QUESTIONÁRIO DAS PRÁTICAS ............................................................ 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 ANÁLISE E INTERPRETAÇÃO DOS RESULTADOS ............................... 80 3.5.1 VALIDAÇÃO DOS RESULTADOS............................................................. 80 3.5.2 ESTATÍSTICA DESCRITIVA...................................................................... 80 3.5.3 ANÁLISE DOS RESULTADOS .................................................................. 85 3.5.3.1 ANÁLISE QUANTITATIVA ....................................................................... 85 3.5.3.2 ANÁLISE QUALITATIVA .......................................................................... 86 3.5.3.3 VERIFICAÇÃO DAS HIPÓTESES ........................................................... 87 3.6 3.6.1 3.6.2 3.6.3 4 4.1 CONCLUSÕES .......................................................................................... 88 CARACTERIZAÇÃO .................................................................................. 88 PONTOS FORTES .................................................................................... 88 PONTOS DE MELHORIA .......................................................................... 89 CONSIDERAÇÕES FINAIS ....................................................................... 91 TRABALHOS FUTUROS ........................................................................... 92

REFERÊNCIAS ......................................................................................................... 93

LISTA DE ILUSTRAÇÕES
FIGURA 1: VISÃO DO SWEBOK E SUAS ÁREAS DE CONHECIMENTO. ...................................................................... 2 FIGURA 2: ESTRUTURA DO CMMI ............................................................................................................... 27 FIGURA 3: RELACIONAMENTO ENTRE AS VARIÁVEIS (TRAVASSOS, 2002). ................................. 40 FIGURA 4: ESQUEMA DE UMA FÁBRICA DE EXPERIÊNCIA (TRAVASSOS, 2002). ......................... 47 FIGURA 5: DISTRIBUIÇÃO DOS DADOS DOS PROFISSIONAIS ENTREVISTADOS ......................... 79

LISTA DE TABELAS
TABELA 1: CUSTOS DA CORREÇÃO DE UM PROBLEMA GERADO NO PROCESO DE REQUISITOS (BOEHM E PAPACCIO, 1988)............................................................................................................................................ 3 TABELA 2: NÍVEIS DE MATURIDADE DO CMMI ...................................................................................................... 25 TABELA 3: PRÁTICAS ESPECÍFICAS DAS ÁREAS DE PROCESSO DE GERENCIAMENTO DE REQUISITOS. ............................................................................................................................................ 27 TABELA 4: PRÁTICAS ESPECÍFICAS DAS ÁREAS DE PROCESSO DE DESENVOLVIMENTO DE REQUISITOS. ............................................................................................................................................ 31 TABELA 5: COMPARAÇÃO DAS ESTRATÉGIAS EMPÍRICAS. ............................................................... 45 TABELA 6: OPÇÕES DE RESPOSTA APLICADAS NO QUESTIONÁRIO .............................................. 54 TABELA 7: RELAÇÃO ENTRE OS DADOS DE P,U,A E AS QUESTÕES. .............................................. 55 TABELA 8: PRÁTICAS ESPECÍFICAS DE OBJETIVO ESPECÍFICO DE GERENCIAMENTO DE REQUISITOS E SUAS SUBPRÁTICAS. .............................................................................................................................................. 59 TABELA 9: PRÁTICAS ESPECÍFICAS DE OBJETIVO ESPECIFICO DE DESENVOLVIMENTO DE REQUISITOS DO CLIENTE E SUAS SUBPRÁTICAS. .................................................................................................................... 62 TABELA 10: QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES ............................................................................... 68 TABELA 11: ESCALAS PARA RESPOSTAS. ................................................................................................... 69 TABELA 12: QUESTIONÁRIO DA LISTA DE PRÁTICAS DE ENGENHARIA DE REQUISITOS. ........... 69 TABELA 13: RESULTADO DAS ENTREVISTAS.......................................................................................... 74 TABELA 14: PERFIL DOS PARTICIPANTES. .................................................................................................. 79 TABELA 15: LEGENDA DE AUXÍLIO DA TABELA 11 ................................................................................. 79 TABELA 16: MEDIANA E MODA REFERENTE AS RESPOSTAS SOBRE A PRESENCE DAS PRÁTICAS NO PROCESSO DA EMPRESA. ...................................................................................... 80 TABELA 17: MEDIANA E MODA REFERENTE ÀS RESPOSTAS SOBRE A UTILIDADE DAS PRÁTICAS SUGERIDAS PELO CMMI NO PROCESSO DA EMPRESA. ....................................... 81 TABELA 18: MEDIANA E MODA REFERENTE ÀS RESPOSTAS SOBRE A ADEQUAÇÃO DAS PRÁTICAS SUGERIDAS PELO CMMI NO PROCESSO DA EMPRESA. ....................................... 81 TABELA 19: LISTA DE PRÁTICAS USADAS PARCIALMENTE. ............................................................... 82 TABELA 20: LISTA DE PRÁTICAS USADAS PLENAMENTE .................................................................... 83 TABELA 21: LISTA DE PRÁTICAS NÃO USADAS QUE GOSTARIAM DE USAR ................................. 84 TABELA 22: RELAÇÃO DAS RESPOSTAS QUANTIFICADAS. ................................................................ 85 TABELA 23: LISTA DAS PRÁTICAS QUE NÃO 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

1 INTRODUÇÃO
O Institute of Electrical and Electronic Engineers (IEEE) é uma organização do mundo dos profissionais de informática com várias publicações normas e conferências realizadas. Ele define a engenharia de software como a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. Quando o IEEE descreve a engenharia de software como uma abordagem sistemática, quer dizer que a engenharia de software se desenvolve segundo um método ou ordenação e seus elementos são classificados e organizados entre si, seguindo um ou mais critérios. Já em relação à disciplinada o IEEE refere-se ao fato a engenharia de software obedecer a ordens e regulamentos. Quanto ao fato da engenharia de software ser quantificável, é porque para o IEEE seu valor pode ser avaliado com precisão. 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 gerência de projetos. Ele é o guia de conhecimento da engenharia de software e foi criado para: • Promover uma visão consistente do mundo da Engenharia de Software; • Explicar o núcleo da Engenharia de Software e seu conjunto de fronteiras; • • Caracterizar os conceitos da disciplina de Engenharia de Software; Promover um acesso por tópicos para a engenharia de software;

2

Promover uma base de certificações individuais e material licenciado.

Assim como o PMBOK, o SWEBOK também é dividido em áreas de conhecimento. No caso do SWEBOK existem dez áreas conhecimento. São elas: Desenho de software; Construção de software; Teste de software; Manutenção de software; Gerência de configuração de software; Gerência de Engenharia de software; Processo de Engenharia de software; Ferramentas e métodos de Engenharia de software; Qualidade de Software e área de conhecimento de Requisitos de software. A Erro! Fonte de referência não encontrada. mostra uma visão do SWEBOK e suas áreas de conhecimento.

Figura 1: Visão 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 importância no processo de engenharia de software. Definida por SOMMERVILLE (2008) como o processo de descobrir, analisar, documentar e verificar os serviços propostos por um sistema e as suas restrições, a engenharia de requisitos é citada e usada em vários estudos. O relatório do

3

Standish Group O CHAOS Report de 2007, é um exemplo desses estudos, onde seu resultados apresentaram que apenas 35% dos projetos de software são bem sucedidos e que 46% dos projetos de software falharam em relação a tempo e requisitos entregues. Esta importância relacionada à engenharia de requisitos não vem de agora, anos atrás já existiam estudos que mostravam a preocupação neste processo. Como exemplo dessa preocupação, 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 importância do processo de engenharia de requisitos vem do próprio SEI. Ele considera que os dois principais fatores de falhas de orçamentos e cronograma são derivados de problemas de requisitos, seja pela Especificação de requisitos inadequada ou pelas Mudanças que existem nos requisitos. Além disso, é nesse processo que os erros mais caros de serem corrigidos são gerados. A Erro! Fonte de referência não encontrada. mostra o estudo feito por BOEHM e PAPACCIO (1988) que trás os custos da correção de um problema que foi gerado no processo de requisitos;

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

Custo $1 $5 $10 $20 $200 Encontrado na própria fase de análise de requisitos Encontrado na fase de projeto do sistema Encontrado na fase de codificação Encontrado na fase de testes unitários Encontrado após a entrega do produto

4

Por isso é que a engenharia de requisitos é considerada tão importante no desenvolvimento de sistemas, sendo exigida e mapeada em modelos e normas certificadoras importantes no mundo da tecnologia da informação. Como exemplo dos mais conhecidos no Brasil podemos citar o MPS.BR (Melhoria do processo de software Brasileiro) e o mais cobiçado 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 cobiçado 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 específico e uma série de práticas específicas, consideradas pelo CMMI como as melhores práticas para se ter um processo de engenharia de requisitos de boa qualidade. Contudo, não se pode garantir que uma empresa que utiliza de forma plena todas as práticas específicas 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 variáveis não controláveis como, por exemplo, as diferentes personalidades humanas, que não garantem o funcionamento de forma eficiente desse processo em uma empresa. Por isso que o conhecimento empírico é importante, pois só ele pode provar que um modelo ou uma teoria serão adequados para uma empresa. O conhecimento empírico dos processos da engenharia de software se encaixa na engenharia de software experimental, pois ela é um estudo empírico sobre a própria engenharia de software que oferece um modelo sistemático, disciplinado, computável e controlado para avaliação da atividade humana (TRAVASSOS, 2002). Com isso, pode-se ter um controle dos objetos e instrumentação, permitindo tirar uma conclusão mais geral, permitindo ainda realizar análises estatísticas, utilizando métodos de teste de hipóteses (WOHLIN et

5

al. ,2000). Isso tudo é feito através da realização de experimentos nos processos da engenharia de software nos ambientes organizacionais. Um experimento deve ser tratado como um processo da formulação ou verificação de uma teoria. Para que o processo ofereça os resultados válidos, ele deve ser propriamente organizado e controlado. Geralmente o experimento é dividido em cinco fases, que aparecem em momentos diferentes no experimento, são elas: a definição, o planejamento, a execução, a análise e o empacotamento do estudo. Em face de estas informações, este trabalho realizou um experimento, que caracterizou e comparou o processo de engenharia de requisitos dos projetos de integração de uma empresa de tecnologia da informação do Recife com as práticas específicas das áreas de processo da engenharia de requisitos exigidas pelo CMMI. 1.1 MOTIVAÇÃO 1.1.1 MOTIVAÇÃO DE MERCADO Uma grande quantidade de projetos de software é cancelada ou fracassa por não atenderem por completo as necessidades dos clientes. Uma Explicação simples para este fenômeno não existe, mas alguns trabalhos, tais como LEFFINGWELL e WIDRIG (2003), KOTONYA e SOMMERVILLE (1998) e do The Standish Group International apontam as deficiências nos requisitos dos sistemas como os principais motivos para os fracassos que ocorrem nos projetos de software. Tais afirmações levaram alguns autores a considerar a Engenharia de Requisitos como uma das mais importantes disciplinas da Engenharia de Software. A importância do processo da engenharia de requisitos aumenta ainda mais quando se trata de projetos de integração entre sistemas de empresas distintas, pois além 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 acadêmico nesses tipos de projetos. Um experimento deste tipo pode trazer uma grande ajuda para projetos futuros das

6

empresas, trazendo melhorias de processos que podem se traduzir em uma diminuição de tempo e custos. 1.1.2 MOTIVAÇÃO TÉCNICA O estudo de engenharia de software experimental pode ajudar as empresas de tecnologia da informação a obterem uma caracterização de um ou mais processos da empresa. Após o conhecimento empírico do processo é possível apontar os pontos falhos e propor possíveis melhorias no processo. Isso tem uma grande importância para as empresas, porque no mundo globalizado em que a competição é acirrada conviver com processos engessados sem saber se eles realmente podem levar uma empresa a ter prejuízos que podem ser identificados e melhorados a partir dos conhecimentos empíricos. 1.2 PROBLEMA O mercado cada vez mais competitivo e acirrado tem levado as empresas de tecnologia da informação a buscar a excelência em seus processos para oferecer sempre um melhor produto aos seus clientes. Geralmente essa busca por excelência leva as empresas a apostarem em processos novos e nem sempre adequados as suas necessidades. O conhecimento empírico, por outro lado, tem o poder de provar a teoria, ajudando a tomar as decisões, escolhendo o processo mais acertado para o seu perfil. Outro ponto problemático no desenvolvimento de software, é o processo de levantamento de requisitos, também conhecido como engenharia de requisitos; que não vem sendo usado corretamente pela maioria das empresas de desenvolvimento de software. A partir dessas afirmações 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 teóricos propostos, trazendo para a empresa uma caracterização desse processo e fornecendo informações necessárias para que ela possa tomar as decisões necessárias e melhorar o seu processo.

7

1.2.1 OBJETIVO GERAL • Realizar um experimento em alguns projetos de integração realizados em uma empresa de Tecnologia da Informação, com o foco na engenharia de requisitos, possibilitando a empresa obter uma caracterização de sua estrutura atual em relação à engenharia de requisitos. • Propor, ainda, uma comparação com as práticas específicas de engenharia de requisitos proposta pelo CMMI (do inglês, Capability Maturity Model Integration). • Verificar os pontos fortes e propor melhorias no processo de engenharia de requisitos. 1.2.2 OBJETIVOS ESPECÍFICOS • Desenvolver procedimentos e protocolos de engenharia de software experimental para caracterização da engenharia de requisitos nas empresas. • Realizar um método de comparação entre as práticas de engenharia de requisitos da empresa com as práticas específicas do CMMI em relação à engenharia de software experimental. • Propor melhorias no processo de engenharia de requisitos das empresas a partir dos estudos experimentais. 1.3 JUSTIFICATIVA A constatação de PARKER (2000) e RANGER (2001) é que existe uma quantidade significativa de sistemas de informação falhos, sendo que, na maioria dos casos, essa falha é por conta do não atendimento das expectativas às necessidades reais dos usuários. Além disso, segundo SOMMERVILLE e SAWYER (1999) e PRESSMAN (2006) a etapa de elicitação de requisitos não pode ser caracterizada como uma tarefa trivial, conforme aparece em um primeiro momento.

8

Assin, surge a necessidade de instrumentos mais satisfatórios e que tornem mais confiável e segura esta atividade. Outro ponto é a insatisfação dos usuários em relação ao aumento dos

custos, citado por DE BORTOLI e PRICE (2000). E também, o desentendimento com os desenvolvedores devido a realização de atividades desnecessárias ou até mesmo duplicadas, levando ao aumento da tarefa de manutenção. MACEDO e LEITE (1999) afirmam que as vantagens produzidas com uma boa definição de requisitos são reais, pois diminuem a quantidade de alterações, diminuindo os custos e aumentando a possibilidade de se cumprir prazos e os riscos de insatisfação dos clientes com as aplicações de software. DAVIS (1982) muito antes de MACEDO e LEITE (1999) afirmava que o principal objetivo da elicitação de requisitos é a obtenção dos requisitos dos usuários adequados às necessidades dos usuários para poder gerar sistemas compatíveis com o esperado. A confirmação do uso da engenharia de requisitos de uma forma correta poderá ser feita através de uma caracterização dela, utilizando experimentos. FLEMING (2003) usou as suas experiências empíricas para corroborar com a afirmação de que a etapa de elicitação se caracteriza como um dos maiores problemas do processo de desenvolvimento de software. Essa afirmação foi relacionada ao fato da dificuldade no entendimento dos usuários, pois eles possuem uma visão restrita dos seus próprios processos. Com isso ele conseguiu propor a seguinte saída: um conhecimento amplo dos processos de negócio afetados pelo sistema a ser desenvolvido contornaria esse problema e geraria um produto mais satisfatório. 1.4 CONTRIBUIÇÕES Um estudo sobre engenharia de software experimental e sobre engenharia de requisitos.

9

Um experimento em alguns projetos de integração de uma empresa de Tecnologia da Informação com foco na engenharia de requisitos, possibilitando uma possível melhoria nos processos destes tipos de projeto na própria empresa. Uma metodologia de caracterização do processo de engenharia de requisitos, utilizando engenharia de software experimental. 1.5 ESTRUTURA DA DISSERTAÇÃO O presente trabalho está estruturado em um conjunto de capítulos. Neste sentido, esta seção apresenta de forma resumida a seguinte lógica de organização geral do documento: No Capitulo 1, é feita uma breve introdução e realizada uma apresentação inicial do problema de pesquisa com justificativa da relevância do tema em questão, exposição dos objetivos almejados com o trabalho e da lógica de estruturação geral do documento; No Capítulo 2, é apresentada uma revisão da literatura relacionada aos principais conceitos da engenharia de requisitos e da engenharia de software experimental; No Capítulo 3, é apresentado o estudo experimental como ele foi realizado e mostrado os seus resultados; No Capítulo 4, são retomados os principais pontos trabalhados durante a pesquisa, apresentadas as limitações e conclusões sobre a pesquisa. As oportunidades de trabalhos futuros também são apresentadas nesse capítulo final.

10

2 REVISÃO BIBLIOGRÁFICA
2.1 ENGENHARIA DE REQUISITOS A Engenharia de requisitos origina-se da necessidade que os profissionais que constroem software têm em atender as necessidades dos clientes e usuários. Se existe um problema possível de ser entendido e se esta solução é apresentada ao cliente, isto será ótimo, pois o cliente terá seu problema resolvido. Para tanto, é preciso entender a necessidade do usuário e transformá-la em um software. Portanto, pode-se dizer que a necessidade do cliente é o problema operacional ou de negócio que precisa ser resolvido. Ela deverá englobar todos os requisitos que definem a solução proposta para um determinado problema e empacotar de uma forma que estes requisitos formem uma definição concisa e clara para que possam ser usada tanto pelos engenheiros de software que irão desenvolver o software, como uma documentação e um guia, quanto aos clientes que estão com o problema para que eles consigam entender a proposta do software e poder analisar se a solução proposta atenderá as suas necessidades. Ainda em relação à engenharia de requisitos pode-se afirmar que ela preocupa-se com a elicitação, análise, especificação e como será realizada a validação do software, ou seja, é nessa etapa que se inicia o processo de entendimento do problema que o software a ser construído procura resolver e definem-se as funcionalidades que o mesmo deverá ter. Além disso, define-se a metodologia para a verificação 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. Através da literatura podemos retirar algumas definições da engenharia de requisitos, como: é o processo de descobrir, analisar, documentar e verificar serviços fornecidos pelo sistema e as suas restrições operacionais (SOMMERVILLE,

11

2008); O processo de engenharia de requisitos de software envolve a tradução de informação 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 vão 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 responsáveis por essa etapa são 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 definição do que o sistema deve fazer suas propriedades emergentes desejáveis e essenciais e suas restrições quanto à operação do sistema e quanto ao processo de desenvolvimento do software. É um processo de comunicação entre os clientes e os usuários de software e os desenvolvedores. Por tudo isso a engenharia de requisitos é um dos processos do desenvolvimento de requisitos mais importante e problemático. Tanto é importante e problemático 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 definição dos serviços fornecidos pelo sistema e as restrições operacionais. Em outras palavras, segundo o próprio SOMMERVILLE (2008), pode-se pensar na engenharia de requisitos como o processo de comunicação entre os clientes e os usuários de software e os desenvolvedores de software. Esta comunicação não é uma tarefa tão fácil, visto que as pessoas têm entendimentos diferentes das mesmas coisas. Com isso surgem algumas dificuldades que podem ser apresentados nesta fase, também conhecida como elicitação de requisitos, do desenvolvimento de software. O problema mais comum de acontecer nesta fase é o cliente não conseguir explicitar bem a sua necessidade e o entendimento do requisito não ser bem feito, podendo acarretar a construção de um software que não atende ao desejo do cliente.

12

Outros problemas podem ocorrer nesta fase, como à escrita dos requisitos não funcionais, pois eles devem ser escritos cuidadosamente para que não fiquem conflitantes. Um exemplo de conflitos de requisitos que se pode citar é: O sistema deverá usar 4MB no máximo de memória e ser desenvolvido. Se o sistema for desenvolvido em, que é uma linguagem que usa muito recurso e que pode exigir mais de 4MB de memória isso será conflitante com o uso restrito de memória. Um ponto problemático na fase levantamento de requisitos é o da má especificação de requisitos de domínio. Geralmente estes requisitos são redigidos na linguagem domínio da aplicação e geralmente os engenheiros de software têm dificuldade em compreendê-las (SOMMERVILLE, 2008). Eles são provenientes do domínio da aplicação do sistema e refletem as características e restrições do domínio, refletindo ainda os fundamentos do domínio da aplicação. Como problemas que se pode ter na especificação de requisitos pode-se apontar ainda a imprecisão na especificação dos requisitos. Além dos conflitos que se pode surgir, é preciso ter cuidado com a ambigüidade, pois é natural que um desenvolvedor de sistemas interprete um requisito ambíguo de modo a simplificar a sua implementação. O ideal é que os requisitos de sistema sejam simplesmente descrições do comportamento externo do sistema e suas restrições operacionais. Eles não devem estar relacionados à como o sistema pode ser projetado ou implementado. Outra questão a ser levada em consideração é 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 críticos, porque ela passa a ser muito mais necessária 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 crítico pode-se citar o sistema de freio de um carro. O desenvolvimento de sistemas críticos precisam ser especificados dirigidos a risco. O processo envolve a compreensão dos riscos enfrentados do sistema, a descoberta das causas da origem e a geração de requisitos para

13

gerenciar esses riscos. O processo é composto pelos passos de identificação dos riscos, analise, classificação, decomposição dos riscos e avaliação e redução 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 necessário apresentar algumas definições encontradas na literatura, como: • Um requisito define como uma aplicação de computador deve fazer para os seus usuários (KULAK, 2001). • Apalavra requisitos representa uma condição ou capacidade

necessária para um usuário resolver determinado problema ou atingir um objetivo; ou ainda, uma condição ou capacidade que um sistema deve ter ou prover para satisfazer um contrato, padrão, especificação ou outro documento formal imposto (DAVIS, 1982). • o requisito é definido como propriedades de um sistema que são responsáveis 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 são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais, refletindo as necessidades dos clientes de um sistema que ajuda a resolver algum problema (SOMMERVILLE, 2008). Os requisitos de software são definidos durante os primeiros estágios do desenvolvimento de um sistema como uma especificação daquilo que deve ser implementado. Eles são descrições de como o software deve se comportar ou das

14

propriedades e atributos do sistema. Eles podem ser restrições do processo de desenvolvimento de um sistema (SOMMERVILLE e SAWYER, 1999). Os requisitos devem ser únicos, verificáveis e testáveis para minimizar ao máximo os erros. Únicos, pois poderão ser facilmente referenciados, verificáveis e testáveis, para não ocorrerem erros de entendimento. Eles devem ser completos que possibilite o entendimento dos diferentes leitores que eles deverão 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 usuário e os requisitos de sistemas. GOTTESDIENER (2002) também faz essa separação em requisitos de usuário e requisitos do sistema. Para ele os requisitos de usuário constituem declarações sobre as funções ou restrições do sistema em alto nível, devendo ser uma especificação consistente do comportamento externo do sistema. Por outro lado, os requisitos do sistema definem de maneira bem detalhada as funções e restrições sob a ótica do sistema, gerando uma especificação consistente e bem completa daquilo que o sistema deve executar. Ainda em relação aos requisitos, SOMMERVILLE (2008) afirma que os requisitos de usuários são declarações em uma linguagem natural com diagramas, de quais serviços são esperados do sistema e as restrições sob as quais ele deve operar. Eles deverão ser direcionados para os usuários (clientes) do sistema a ser desenvolvido. Já os requisitos de sistema SOMMERVILLE (2008) afirma que eles definem, detalhadamente, as funções os serviços e as restrições operacionais do sistema. O documento de requisitos do sistema é uma especificação 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 nível de desenvolvimento.

15

Segundo MACEDO e LEITE (1999) e GILB (1999), os requisitos de software são necessidades tanto funcionais, que definem comportamentos e propriedades do sistema, quanto não funcionais, que definem as restrições. Ou seja, são as definições dos quesitos de qualidade e restrições operacionais ou do processo de desenvolvimento do sistema. Assim Podemos classificar os requisitos de sistema como funcionais, não funcionais e de domínio. Requisitos funcionais são declarações de serviços que o sistema deve fornecer, como o sistema deve reagir às entradas especificas e como o sistema deve se comportar em determinadas situações. A especificação de requisitos funcionais deve ser completa e consistente. Completeza significa que todos os serviços exigidos pelo usuário devem ser definidos. Consistente significa que os requisitos não devem ter definições contraditórias (SOMMERVILLE, 2008). Requisitos não funcionais correspondem às restrições sobre os serviços ou as funções fornecidas pelo sistema. Eles incluem restrições de timing, processo e padrão de desenvolvimento. Os requisitos não funcionais não estão relacionados diretamente a funções específicas do sistema. Eles podem estar relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento. Eles são mais importantes que os requisitos funcionais individuais, pois os usuários do sistema em geral encontram meios de contornar uma função do sistema que não atenda a suas necessidades, contudo, uma falha no atendimento de um requisito não funcional pode significar que todo o sistema é inútil. Um exemplo de uma falha no atendimento de requisito não funcional é o de uma aeronave que não atende ao requisito não funcional de confiabilidade, isso inviabiliza a sua certificação de segurança e por conseqüência não será usada. Os requisitos não funcionais não estão relacionados somente a sistema de software. Eles podem restringir o processo que deve ser usado para desenvolver o software, como padrões de qualidade e ferramentas (SOMMERVILLE, 2008).

16

Os requisitos não funcionais surgem devido à necessidade dos usuários, seja em relação a orçamento restrito, política organizacional, necessidade de interoperabilidade com outros sistemas ou fatores externos. Requisitos de domínio derivam do domínio da aplicação do sistema e não das necessidades especificas dos usuários do sistema. Geralmente fazem referencia a conceitos de domínio. Podem gerar novos requisitos funcionais ou também 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 nível: estudo da viabilidade, obtenção dos requisitos, especificação, validação e o gerenciamento dos requisitos (SOMMERVILLE, 2008). Já segundo PRESSMAN (2006) os passos do processo de engenharia de requisitos, são a concepção, o levantamento, a elaboração e a validação, ele não cita a fase de estudo da viabilidade, mas cita a fase de concepção como o inicio de tudo. Uma preocupação mais especifica relacionada ao processo de engenharia de requisitos é conseguir identificar com clareza a identificação 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, usuários finais, consultores, engenheiros de produto e de software e engenheiros de manutenção, entre outros. Cada interessado possui uma visão diferente do sistema. Os interessados do sistema podem também serem chamados de Stakholders. Segundo SUMMERVILLE (2008) o estudo da viabilidade é o começo do processo da engenharia de requisitos. Nessa etapa é realizado um estudo que possui um conjunto preliminar de requisitos de negocio, um esboço da descrição do sistema e como ele pretende apoiar os processos de negocio da empresa. Os resultados desse estudo ficam em um relatório, recomendando ou não o prosseguimento no processo de desenvolvimento do sistema. Nesse estudo devem

17

ser respondidas algumas questões. Abaixo descrevo três das que podem ser usadas como ponto de start: • • O sistema contribui para os objetivos gerais da organização? O sistema pode ser implementado com a tecnologia atual e dentro das restrições de prazo e custo? • O sistema pode ser integrado a outros sistemas? Após estas repostas é possível que possam ser formuladas outras abrangendo o mesmo tema (negócio e viabilidade). Segundo PRESSMAN (2006) a maioria dos projetos começa quando uma necessidade de negocio é identificada ou um mercado ou serviço potencialmente novo é descoberto, ou seja, o estudo da viabilidade não precisa ser feito, já que existe a necessidade. Na concepção do projeto os engenheiros de software fazem uma serie de perguntas livres de contexto aos clientes com a intenção de estabelecer um entendimento básico do problema. A fase de Elicitação e análise de requisitos é onde os engenheiros de requisitos trabalham com os clientes e usuários finais para aprender sobre o domínio da aplicação e entender quais serviços o sistema deve fornecer, o desempenho esperado e as restrições. Nessa fase podemos mapear um processo que possui as seguintes etapas: obtenção de requisitos, classificação e organização dos requisitos, priorização e negociação de requisitos e a documentação. Após essas etapas é aconselhável que os requisitos sejam agrupados formando subsistemas (SUMMERVILLE, 2008). PRESSMAN (2006) usa a expressão 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 usuários 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 usuários do sistema freqüentemente não sabem o que querem dele a não ser em termos gerais. Outra dificuldade é a linguagem utilizada pelos usuários que geralmente são expressas

18

com seus próprios termos e conhecimentos implícitos de seu trabalho. Além disso, existem outras variáveis a serem levadas em consideração, como: A divergência dos usuário em relação a necessidade e isso gera diferentes requisitos; fatores políticos que podem influenciar nos requisitos, como o pedido de pessoas com poder dentro da organização, para aumentar o seu poder de influencia; as mudanças econômicas e de negócio que acontecem durante essa fase. A obtenção de requisitos é o processo que reúne informações sobre o sistema proposto e os sistemas existentes para que seja possível obter os requisitos de usuário e de sistema com base nessas informações. Durante essa fase as fontes de informações são documentação, usuários e especificação de sistemas similares. As fontes de requisitos (usuários, domínio, 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 elicitação e os próprios 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 usuários diferentes. Os pontos de vista podem ser mapeados em três tipos genéricos: interação, indiretos e de domínio que fornecem três tipos diferentes de requisitos. A forma mais usada para se obter os requisitos dos usuários é através de entrevista, diante o qual são formuladas perguntas sobre o sistema a ser desenvolvido, pelos engenheiros de requisitos, as quais devem ser respondidas pelos usuários. 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 técnica de observação usado para compreender requisitos sociais e organizacionais. Prototipagem é a forma de se usar protótipos do sistema proposto para conseguir levantar mais alguns requisitos que estejam faltando. Também pode ser usada para validar requisitos.

19

Na Especificação ocorrem as descrições em linguagem natural de tudo que foi levantado. Podem ser usadas algumas técnicas para isso, como usar cenários onde é feito um esboço de interação entre usuário e sistema e durante a elicitação vão sendo adicionados detalhes, criando uma descrição completa. A forma mais conhecida de se especificar requisitos usando cenários é através de casos de uso conforme sugerido por (FOWLER e SCOTT, 1997) um caso de uso engloba um conjunto de cenários, sendo cada cenário um encadeamento isolado ao longo do caso de uso onde existirá um cenário para a interação normal e outra para cada exceção (SOMMERVILLE, 2008). Especificação pode ser um modelo escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários de uso, um protótipo ou qualquer combinação desses elementos (PRESSMAN, 2006). PRESSMAN (2006) cita ainda essa fase como a fase de elaboração, na qual é produzido um documento técnico refinado das funções, características e restrições do sistema. Geralmente utilizam-se na elaboração modelos de desenvolvimento. Por não ser fácil 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 negociação com os clientes. Utilizar modelos ajuda também a verificar requisitos conflitantes, que são sugeridos pelos usuários. Também fica mais fácil a Validação dos requisitos junto com os usuários. O processo de levantamento de requisitos visa à elaboração de perguntas e respostas e é útil na concepção dos requisitos, mas não é 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 substituída por uma forma de levantamento de requisitos que combine elementos de solução de problemas, elaboração, negociação e especificação. 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 solução e negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução (ZAHNISHER, 1990).

20

Uma técnica que traduz a necessidade do cliente para requisitos técnicos do software é a IFQ (implantação da função de qualidade, em inglês QFD Quality function deployment). Segundo ZULTNER (1992) ela concentra-se em maximizar a satisfação 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 três tipos de requisitos: requisitos normais, que refletem os objetos e metas estabelecidos para um produto ou sistema durante as reuniões com o cliente; requisitos esperados, que são requisitos que estão implícitos no produto ou no sistema, e podem ser tão fundamentais que o cliente não se refere a ele explicitamente, e sua ausência causaria uma insatisfação significativa; e requisitos excitantes, refletem características que vão alem da expectativa do cliente, mostram ser muito satisfatório quando presentes. Podemos usar modelos no processo de analise para obter uma compreensão 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 serão processados o modelo de máquina de estado que mostra como o sistema responde aos eventos internos ou externos, o modelo de dados que possui as definições de forma lógica dos dados que serão 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 são usados nos sistemas orientados a objetos e representam como as entidades do sistema podem ser classificadas e compostas por outras entidades, não muito usual para os usuários finais, porque os consideram difíceis de ler. O objetivo da modelagem de analise é criar uma variedade de representações que mostram os requisitos de software quanto à informação, função e comportamento. Para tanto duas diferentes filosofias de modelagem podem ser aplicadas: a análise estruturada e a orientada a objeto. A estruturada considera o software um transformador de informação. Ela ajuda o engenheiro de software na identificação dos objetos de dados, seus relacionamentos e o modo pelo qual esses

21

objetos de dados são transformados à medida que fluem através de funções de processamento de software. A análise orientada a objetos examina um domínio de problema definido como um conjunto de casos de uso em um esforço para extrais classes que definam um problema. Cada classe tem um conjunto de atributos e operações. Classes estão relacionadas entre si por uma variedade de modos e são modeladas por meio de diagrama UML (do inglês, Unified Modeling Language). O modelo de análise é composto de quatro elementos de modelagem: modelos baseados em cenário, modelos de fluxo, modelo baseado em classe e modelo comportamental (PRESSMAN, 2006). O modelo de análise fornece uma descrição dos domínios informacional, funcional e comportamental necessários a um sistema baseado em computador. Podemos ter diferentes modos de representação que forçam a equipe de software a considerar os requisitos de diferentes pontos de vista. Esses modos de representação são citados por PRESSMAN (2006), como quatro elementos: baseados em cenário, classe, elementos comportamentais e orientados a fluxo. Nos elementos baseados em cenário o sistema é descrito do ponto de vista do usuário, usando uma abordagem com base em cenário.Cenários de usuários: a medida que os requisitos são coletados uma visão geral das funções e características do sistema começam a se materializar. Os cenários freqüentemente chamados de casos de uso (JACOBSON, 1992) fornecem uma descrição 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 condições na qual o sistema responde a uma suscitação de um dos seus interessados. Um caso de uso conta uma história estilizada sobre como um usuário final interagi com o sistema sob o conjunto especifico de circunstancia (PRESSMAN, 2006). Os casos de uso não são muito eficazes para elicitar restrições ou requisitos de negócio e requisitos não funcionais de alto nível com base nos pontos de vista indiretos ou para obter requisitos de domínio. Para deixar os requisitos mais ricos podemos usar diagramas de seqüência, que adicionam informações aos casos de uso. Eles mostram os agentes envolvidos

22

na interação, os objetos com os quais interagem e as operações associadas a esses objetos. Elementos baseados em classe: cada cenário de uso implica em um conjunto de objetos que são manipulados à medida que um ator (usuário) interage com o sistema. Esses objetos são caracterizados em classe. Essas classes são uma coleção 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 implementação que é aplicada. Podemos usar o diagrama de estados para representar o comportamento do sistema pela representação de seus estados e dos eventos que causam a modificação do estado do sistema (PRESSMAN, 2006). Elementos orientados a fluxo: a informação é 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 serão explorados a partir dos pontos de vista diferentes. A medida que a informação de vários pontos de vista é coletada, os requisitos emergentes podem ser inconsistentes ou conflitantes. O trabalho do engenheiro de requisitos é categorizar todas estas informações de modo a permitir que os tomadores de decisão, escolham um conjunto de requisitos do sistema internamente consistente (PRESSMAN, 2006). Todas essas formas deverão ser validadas com os clientes. Esse estudo não irá adiantar nada se após tudo isso o engenheiro de software não obtiver a Validação dos requisitos junto ao usuário. A validação de requisitos dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário 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 operação. O custo da correção

23

de problemas de requisitos é muito maior do que as correções de erros de projeto e de codificação. A razão disso é que uma mudança de requisitos significa mudança no projeto, na implantação e que o sistema deve ser testado novamente. Durante a validação deve-se realizar verificações do tipo validade, consistência, realismo, completeza e facilidade de verificação (SUMMERVILLE, 2008). A validação de requisitos examina a especificação para garantir que todos os requisitos do software tenham sido declarados de modo não ambíguo que as inconsistências, omissões 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 saída da engenharia de requisitos é o documento de requisitos, é importante que exista um Gerenciamento de requisitos. Como o problema não pode ser definido totalmente, os requisitos tendem a ser incompletos. Durante o processo de software, os entendimentos dos usuários mudam constantemente. Com isso os requisitos devem evoluir. Outro ponto é que depois da entrega outros requisitos irão surgir. O gerenciamento de requisitos é um processo para compreender e controlar as mudanças dos requisitos. Com relação a mudanças podemos ter dois tipos de requisitos os relativamente estáveis, que são geralmente derivadas da atividade da organização e que se relacionam direto com o domínio e que dificilmente mudam. E os voláteis que tem a probabilidade bem maior de mudar, inclusive durante o desenvolvimento do sistema. Segundo EL EMAM (1997), podemos identificar alguns problemas relacionados à Gerência de Requisitos como a dificuldade de elicitar claramente as mudanças nos requisitos, a falta de habilidade para chegar a um consenso sobre as mudanças chave para os usuários, a falta de habilidade para manter o documento de requisitos consistente e a Falta de habilidade para estimar adequadamente os recursos necessários para implementar as mudanças nos requisitos. No Processo de Gerência de Requisitos Algumas atividades são executadas, entre elas Receber as solicitações de alteração de requisitos, Registrar novos requisitos, Analisar impacto da mudança de requisito, Elaborar relatório de impacto, Notificar os envolvidos e Coletar métricas. O grupo de engenharia de

24

requisitos recebe as solicitações de alteração de requisitos, ou por formulário padronizado, ou por meio de um sistema de solicitação de demandas. Isso mostra que novos requisitos devem ser recebidos formalmente, seja por formulário padronizado, ou por meio de controle sistemático. Neste ponto se dá o registro dos novos requisitos. Posteriormente, uma análise criteriosa deve ser conduzida para avaliar o impacto do requisito a ser incluído, alterado ou excluído 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 elaboração de um relatório de impacto, onde deve ser mantido um histórico de alterações para cada requisito, permitindo uma visão cronológica das principais mudanças nos requisitos. O conjunto de pessoas para as quais pode haver um impacto devido à alteração de requisitos (alteração, inclusão ou exclusão de requisitos) deve ser notificado. Por fim, as métricas devem ser utilizadas e coletadas periodicamente para o acompanhamento das atividades de Gerência de Requisitos (SOMMERVILLE, 2008). A gestão de requisitos é um conjunto de atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue. Ela começa com a identificação. A cada requisito é atribuído um identificador único. Após a identificação 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 característica, tabela de rastreamento de fontes, tabela de rastreamento de dependência, 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 práticas relacionadas ao desenvolvimento e manutenção de sistemas de informação, fornecendo um suporte que engloba todo o ciclo de vida dos produtos da concepção a sua entrega e manutenção. Por isso, e também por ser uma das certificações mais cobiçadas pelas empresas brasileiras é

25

que o CMMI foi o modelo teórico escolhido para ser utilizado neste trabalho. Esta seção mostra uma breve introdução do CMMI em relação a engenharia de requisitos com suas práticas específicas. Para o CMMI a Gestão de Requisitos estabelece um entendimento comum entre o cliente e o fornecedor do serviço em relação aos requisitos que serão atendidos no sistema a ser desenvolvido. A Gestão de Requisitos tem como propósito gerenciar os requisitos dos sistemas e identificar, se existirem, as inconsistências entre os requisitos e os artefatos gerados para o sistema. O CMMI também cita a importância da revisão dos fornecedores de requisitos para que não haja falha de entendimento de requisitos. Para o CMMI documentar as mudanças de requisitos e manter o relacionamento entre requisitos, arquitetura e implementação é muito importante. Para contextualizar, abaixo, na Tabela 2 são apresentados os níveis de maturidade presentes no CMMI.

Tabela 2: Níveis de Maturidade do CMMI

Nível 1 – Inicial 2 – Gerenciado

Descrição Processo imprevisível pobremente controlado e reativo Gerenciado Quantitativamente: Processo caracterizado para o projeto e muitas vezes reativo

3 – Definido 4 –

Processo caracterizado para a organização e proativo

Gerenciado Processo medido e controlado

qualitativamente 5 – Otimização Foco na melhoria do processo

26

O nível um também conhecido como o nível inicial é caracterizado como um processo de desenvolvimento de software “ad hoc” e ocasionalmente pode ser caótico. Nesse nível poucos processos estão definidos na empresa e o sucesso depede dos esforços individuais. No nível dois, os processos básicos de gerenciamento estão estabelecidos para se obter os controles do custo, cronogramas e funcionalidade. A disciplina necessária dos processos permite repetir o sucesso em outros projetos com aplicações similares. No nível três, o processo de software para as atividades de gerenciamento e de engenharia é documentado, padronizado e integrado em um processo padrão de software para a organização. Já no nível quatro, medições detalhadas do processo de software e da qualidade do produto são coletadas. Tanto o processo de software quanto o produto de software são quantitativamente entendidos e controlados. Por fim, no nível cinco, que é o nível de maturidade otimizado, o processo de melhoria continua e é feito através de feedback quantitativo dos processos e das aplicações de novas idéias e tecnologias. Cada nível de maturidade do CMMI possui áreas de processo formadas por objetivos específicos e genéricos que, por sua vez, também possuem suas práticas específicas e genéricas 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 níveis de maturidade do CMMI. No nível 2 (Gerenciado) encontra-se a área de processo Gerenciamento de Requisitos (Requirements Management - REQM) e no nível 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 nível 2 do CMMI. O objetivo do Gerenciamento de Requisitos é gerenciar os requisitos dos produtos do projeto e os seus componentes e identificar inconsistências entre esses requisitos e os planos do projeto e produtos de trabalho. A Tabela 2 apresenta as práticas específicas da área de processo de gerenciamento de requisitos.

Tabela 3: Práticas específicas das áreas de processo de Gerenciamento de Requisitos.

Área de processo (AP): Gerenciamento de Requisitos – REQM Objetivo Específico (OE): Gerenciar Requisitos Práticas específicas (PE) PE1 PE2 PE3 PE4 PE5 Obter um entendimento dos requisitos. Obter comprometimento com requisitos. Gerenciar mudanças de requisitos. Manter rastreabilidade bidirecional de requisitos. Identificar inconsistências entre artefatos do projeto e requisitos.

28

Como visto na tabela 2 a área de processo de gerenciamento de requisitos é composta pelas seguintes práticas específicas:

Prática específica 1 - obter entendimento dos requisitos: A fim de evitar problemas futuros, são designados as fontes oficiais que serão responsáveis por disponibilizar e receber os requisitos. A prática específica do entendimento dos requisitos trata do estabelecimento do uso de um mecanismo que obtém, com o cliente, o significado do requisito. Ele é composto por atividades que captam os requisitos para assegurar que sua compreensão foi atingida. Essa prática também estabelece os critérios que evitam o crescimento indistinto dos mesmos. Para essa prática são utilizados como produtos de trabalho: 1. Lista de critérios para a apropriada distinção dos fornecedores dos requisitos. 2. Critérios para avaliação e aceitação dos requisitos. 3. Resultados das análises em relação aos critérios. 4. Um conjunto de requisitos acordados.

Prática específica 2 - obter comprometimento com os requisitos: Quando são formadas as equipes, o compromisso com os requisitos é necessário, assegurando que as mudanças ocorridas ao longo do tempo sejam disponibilizadas para todos os envolvidos. Essa prática trata de acordos e compromissos entre os profissionais envolvidos na execução das atividades necessárias para implementação dos requisitos. Para essa prática são utilizados como produtos de trabalho: 1. Analisar os impactos dos requisitos.

29

2. Compromissos documentados com os requisitos e com as mudanças de requisitos.

Prática específica 3 - gerenciar mudanças nos requisitos: Gerenciar as mudanças nos requisitos durante a evolução do projeto é importante para manter os requisitos atualizados. Pois eles podem mudar devido a vários fatores, inclusive fatores não previstos, como por exemplo, a exigência de atendimento a uma nova legislação. Estas mudanças devem ser controladas de forma que permita a avaliação dos impactos que podem ocorrer em todo o projeto. Ela também possibilita, aos gerentes, rastrear as medidas de volatilidade de requisitos para julgar a necessidade de novos controles ou, fazer a revisão dos existentes. Para essa prática são utilizados como produtos de trabalho: 1. Status de requisitos. 2. Banco de dados de requisitos. 3. Banco de dados de decisões de requisitos. Já as subpráticas utilizadas são as seguintes: 1. Documentar todos os requisitos e mudanças de requisitos do projeto. 2. Manter um histórico de mudanças de requisitos com os fundamentos lógicos das mudanças. 3. Manter o histórico de mudanças ajuda a rastrear a volatilidade dos requisitos. 4. Avaliar o impacto das mudanças de requisitos do ponto de vista dos stackeholders relevantes. 5. Tornar disponíveis ao projeto os dados de requisitos e de mudanças.

30

Prática específica 4 - manter rastreabilidade bidirecional dos requisitos: Esta prática é importante, porque a partir de uma rastreabilidade bidirecional bem feita é possível rastrear os requisitos até sua origem e retornar a sua condição atual, por exemplo, indicando qual será o impacto das mudanças neles e como será refletida no projeto. Para essa prática são utilizados como produtos de trabalho: 1. Matriz de rastreabilidade de requisitos. 2. Sistema de rastreamento de requisitos. Já as subpráticas usadas são as seguintes: 1. Manter a rastreabilidade dos requisitos para assegurar que a origem do menor nível de requisito (derivado) esteja documentada. 2. Manter a rastreabilidade de um requisito com seus requisitos derivados e com sua alocação a funções, interfaces, pessoas, processos e produtos de trabalho. 3. Gerar a matriz de rastreabilidade de requisitos.

Prática específica 5 - identificar inconsistências entre o trabalho do projeto e os requisitos: Essa prática é usada para descobrir as inconsistências entre os requisitos e os planos do projeto e produtos de trabalho. Isso permite iniciar ações corretivas para não desviar o foco do requisito em questão. Para essa prática é utilizado como produto de trabalho:

31

1. documentação de inconsistências incluindo fontes, condições e justificativas e ações corretivas. Já as subpráticas usadas são as seguintes: 1. Revisar os planos de projeto, atividades e produtos de trabalho visando à consistência com os requisitos e com as mudanças neles realizadas. 2. Identificar a origem das inconsistências e fundamento lógico. 3. Identificar mudanças que necessitam ser feitas nos planos e produtos de trabalho resultantes das mudanças na baseline de requisitos. 4. Iniciar as ações corretivas. Além da área de processo de gerenciamento existe também a área de processo de desenvolvimento de Requisitos, que como citado anteriormente, é exigida pelo nível três 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 práticas específicas.

Tabela 4: Práticas específicas das áreas de processo de Desenvolvimento de Requisitos.

Área de processo (AP): Desenvolvimento de Requisitos – RD Objetivo Específico (OE): Desenvolver Requisitos do Cliente Práticas específicas (PE) PE01 PE02 PE03 Coletar as necessidades dos stakeholders. Elicitar as necessidades. Desenvolver os Requisitos dos clientes.

Objetivo Específico (OE): Desenvolver requisitos do produto Práticas específicas (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 Específico (OE): Desenvolver requisitos do produto Práticas específicas (PE) PE07 PE08 PE09 PE10 PE11 Estabelecer conceitos operacionais e cenários. Estabelecer uma definição das funcionalidades requeridas. Analisar os requisitos. Analisar os requisitos para avaliação. 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 três objetivos específicos, onde cada objetivo específico possui suas práticas específicas. Os objetivos específicos e suas práticas específicas da área de processo de desenvolvimento de requisitos são: • Objetivo específico 1 - Desenvolver os Requisitos de Cliente: O objetivo específico de Desenvolver os Requisitos de Cliente é utilizado para coletar as necessidades, expectativas, restrições e interfaces dos stakeholders e traduzi-las em requisitos de cliente. Ele é dividido em duas práticas específicas que são: • Prática específica 1.1 – Levantar os requisitos:

33

Essa prática específica propõe realizar o levantamento das necessidades, expectativas, restrições e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai além da coleta de requisitos, incluindo a identificação adicional e pró-ativa de requisitos não fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam endereçar as várias atividades do ciclo de vida do produto e seus impactos no produto. Na tabela 3 essa prática está exibida como as práticas específicas PE01 e PE02. Ela possui uma única subprática, que é: 1. Envolver os stakeholders relevantes usando métodos para levantamento de necessidades, expectativas, restrições e interfaces externas.

Pratica específica 1.2 - Desenvolver os Requisitos de Cliente: Essa prática específica transforma as necessidades, expectativas, restrições

e interfaces dos stakeholders em requisitos do cliente. Essa prática possui duas subpráticas: 1. Traduzir as necessidades, expectativas, restrições stakeholders em requisitos do cliente documentados; 2. Definir restrições de verificação e validação. e interfaces dos

Objetivo específico 2 - Desenvolver os Requisitos do produto: O objetivo específico 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 três práticas específicas que são: • Pratica específica 2.1 - Estabelecer os Requisitos de Produto e de Componentes de Produto: Essa prática específica estabelece e mantém os requisitos do produto e dos componentes de produto, que são baseados nos requisitos do cliente. Ela possui duas subpráticas:

34

1. Desenvolver os requisitos em termos técnicos, necessários ao design do produto e dos componentes de produto. Desenvolver os requisitos de arquitetura endereçando qualidades e desempenho críticos do produto necessários ao design da arquitetura do produto; 2. Derivar os requisitos que resultam das decisões de design.

Pratica específica 2.2 - Alocar os Requisitos de Componentes de Produto: Essa prática específica propõe alocar os requisitos de cada componente do

produto. Ela possui três subpráticas: 1. Alocar requisitos a funções; 2. Alocar requisitos a componentes de produto; 3. Alocar restrições de design a componentes de produto.

Pratica específica 2.3 - Identificar os Requisitos de Interface: Essa prática específica identifica os requisitos de interface. As Interfaces

entre funções ou entre objetos são identificadas. As interfaces funcionais podem orientar o desenvolvimento de soluções alternativas descritas na área de processo. Essa prática possui duas subpráticas: 1. Identificar as interfaces externas e internas do produto. À medida que o design evolui, a arquitetura do produto será alterada pelos processos da solução técnica, 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 são definidos em termos de aspectos tais como origem, destino, estímulo, características de dados para software e hardware.

Objetivo específico 3 – Analisar e validar requisitos:

35

O objetivo específico de analisar e validar requisitos é utilizado para analisar e validar os requisitos e definir as funcionalidades requeridas. Ele é dividido em cinco práticas específicas que são:

Pratica específica 3.1 - Estabelecer Conceitos e Cenários Operacionais: Essa prática específica estabelece e mantém conceitos operacionais e

cenários associados. Um cenário é tipicamente uma seqüência de eventos que poderia ocorrer no uso do produto, que são usados para tornar explícita alguma necessidade dos stakeholders. Ela possui com quatro subpráticas: 1. Elaborar conceitos operacionais e cenários que incluam funcionalidade, desempenho, manutenção, suporte e descarte quando apropriado; 2. Definir o ambiente no qual o produto ou o componente de produto irá operar, incluindo fronteiras e restrições; 3. Revisar os conceitos e cenários operacionais para descobrir e refinar requisitos; 4. Desenvolver um conceito operacional detalhado, quando o produto e os componentes de produto são selecionados, para satisfazer às necessidades operacionais, de manutenção, de suporte e de descarte.

Pratica específica 3.2 - Estabelecer uma Definição da Funcionalidade Requerida: Essa prática específica propõe a definição de funcionalidade, também

chamada de “análise funcional”, é a descrição do que o produto pretende fazer. A definição de funcionalidades pode incluir ações, seqüências, entradas, saídas ou outras informações que comunicam à maneira que o produto será usado. Essa prática possui seis subpráticas: 1. Analisar e quantificar as funcionalidades requeridas pelos usuários finais;

36

2. Analisar os requisitos para identificar as partições lógicas ou funcionais; 3. Particionar os requisitos em grupos, com base nos critérios estabelecidos,para facilitar ou dar foco à análise de requisitos; 4. Considerar a seqüência das funções de tempo-crítico, no início e durante o desenvolvimento dos componentes de produto; 5. Alocar os requisitos do cliente às partições funcionais, objetos, pessoas ou a elementos de suporte para dar suporte à síntese de soluções; 6. Alocar requisitos funcionais e de desempenho às funções e subfunções.

Pratica específica 3.3 - Analisar os Requisitos: Essa prática específica prega que os requisitos sejam analisados para

determinar se eles são necessários e suficientes para atender aos objetivos dos níveis mais altos da hierarquia do produto. Então, os requisitos analisados fornecem uma base de requisitos mais detalhada e precisa para os níveis mais baixos da hierarquia do produto. Ela possui seis subpráticas: 1. Analisar as necessidades, expectativas, restrições 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 níveis mais altos; 3. Analisar os requisitos para garantir que eles sejam completos, economicamente viáveis, implementáveis e verificáveis. Enquanto o design determina a viabilidade de uma solução particular; 4. Identificar os requisitos-chave que têm uma forte influência nos custos, cronograma, funcionalidades, riscos ou desempenho; 5. Identificar medidas de desempenho técnico que serão acompanhados durante o esforço de desenvolvimento; 6. Analisar os conceitos e cenários operacionais para refinar as necessidades, restrições e interfaces do cliente, e descobrir novos requisitos.

37

Pratica específica 3.4 - Analisar os Requisitos Visando Equilíbrio: Essa prática específica trata da análise das necessidades e restrições dos

stakeholders, verificando as questões relacionadas a custos, cronograma, desempenho, funcionalidade, componentes reusáveis e manutenibilidade ou risco. Ela possui três subpráticas:

1. Usar modelos comprovados, simulações e prototipagem para analisar o equilíbrio de necessidades e restrições dos stakeholders; 2. Realizar uma avaliação 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 específica 3.5 - Validar os Requisitos com Métodos Detalhados: Essa prática específica prega que a validação dos requisitos tem que ser

realizada precocemente no esforço de desenvolvimento com os usuários finais para obter confiança de que os requisitos são capazes de guiar um desenvolvimento que resulte em validação final bem sucedida. Ela possui três subpráticas: 1. Analisar os requisitos para determinar o risco do produto resultante não funcionar apropriadamente em seu ambiente de uso pretendido; 2. Explorar a adequação e completitude dos requisitos por meio do desenvolvimento de representações do produto; como protótipos, simulações, modelos, cenários e roteiros; e de obtenção de feedbacks dos stakeholders relevantes a respeito dessas representações; 3. Avaliar o design à medida que ele amadurece no contexto do ambiente de validação dos requisitos para identificar problemas de validação e expor necessidades e requisitos do cliente não declarados.

38

2.2 ENGENHARIA DE SOFTWARE EXPERIMENTAL Com base em todos os conceitos de engenharia de software e modelos teóricos, visto até o momento, é preciso saber se as praticas sugeridas pelo modelo teórico aplicadas em qualquer ambiente organizacional serão bem sucedidas. Como não é possível obter esses resultados realizando apenas experimentos que comprovem a teoria na prática, utiliza-se, nesse contexto, a engenharia de software experimental, pois ela ajuda a provar na prática se o modelo teórico funcionará para aquele ambiente no qual o experimento foi aplicado. A engenharia de software experimental nada mais é que um estudo empírico sobre a própria engenharia de software, ou seja, é provar na prática o que a teoria da engenharia de software prega. Segundo TRAVASSOS (2002) a experimentação é o centro do processo científico e, somente com experimentos é que podemos verificam as teorias, pois somente eles podem explorar os fatores críticos e dar luz ao fenômeno novo para que as teorias possam ser formuladas e corrigidas. A experimentação oferece um modelo sistemático, disciplinado, computável e controlado para avaliação da atividade humana. A competitividade das empresas de desenvolvimento de software depende cada vez mais da eficiência dos seus processos (WOHLIN et al., 2000). Como o uso de processos padrões não são eficientes para todas as empresas, a otimização dos processos de desenvolvimento para moldar-los ao ambiente operacional da empresa é muito importante. Por isso que a realização de estudos empíricos faz-se necessário, pois somente com uma aplicação prática sobre as teorias levantadas, nos processos de uma empresa, é que se pode saber se aquele processo está adequado para a determinada empresa ou não. Também é a partir deste estudo empírico nos processos que podemos saber os pontos fortes, fracos e pontos de melhoria, sugerindo otimização no processo, ou seja, as melhorias necessárias. Segundo TRAVASSOS (2002) os objetivos que levam a execução de experimentos em Engenharia de Software são a possibilidade de se realizar uma caracterização, avaliação, previsão, 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 esforço é menor em relação aos outros. Isso ocorre porque nos outros experimentos, que são de avaliação, previsão, controle e melhoria, deverão ser respondidas questões como "quão bom é isto?", "posso estimar algo no futuro?", "posso manipular o evento?" e "posso melhorar o evento?". Como o método experimental sugere um modelo teórico, que a partir desse modelo é desenvolvido um método qualitativo ou quantitativo que realiza este experimento e depois mede e avalia o modelo teórico e por fim pode ou não repetir esse processo. Esta técnica representará uma melhoria evolucionária, 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 realização de um estudo experimental é dividida em cinco fases: a definição, o planejamento, a execução, a análise e o empacotamento do estudo. Ainda em relação à compreensão da engenharia de software experimental, TRAVASSOS (2002) observou que os elementos principais do experimento são as variáveis, os objetos, os participantes, o contexto do experimento, hipóteses, e o tipo de projeto do experimento. As variáveis podem ser de dois tipos de variáveis as dependentes (resultados), que são as saídas do processo de experimentação, e as variáveis independentes (fatores), que são as entradas do processo e apresentam a causa que afeta o resultado do processo. A Figura 3 apresenta o relacionamento entre essas variáveis.

40

Figura 3: Relacionamento entre as variáveis (TRAVASSOS, 2002).

No objetivo do experimento verifica-se o relacionamento de causa-efeito na teoria a ser estudada. No processo de execução os tratamentos são aplicados ao conjunto dos objetos e o resultado é avaliado. Participantes são os indivíduos selecionados da população que interessa para a condução do experimento. Para se conseguir um resultado de um experimento a uma população desejada, o conjunto de participantes selecionado deve ser representativo para aquela população. Com isso a importância nos critérios de seleção é grande, porque eles influenciam no resultado do experimento. A princípio, quanto maior é a variedade da população tanto maior deve ser o tamanho do conjunto de participantes. O contexto do experimento é composto das condições no qual ele está sendo executado, podendo ser caracterizado em três: In-vitro vs. In-vivo, Alunos vs. Profissionais, Problema real e Específico vs. Geral. Os experimentos são normalmente formulados através de hipóteses, contendo A hipótese principal, também chamada de hipótese nula, e a hipótese alternativa. O objetivo principal de um experimento é fazer com, baseado nos resultados da verificação da verificação usando testes estatísticos, que uma hipótese alternativa consiga rejeitar a hipótese nula.

41

O tipo de projeto do experimento determina a maneira de condução do experimento. A decisão sobre alocação dos objetos e dos participantes e como os tratamentos serão aplicados aos objetos são feitas neste momento. Um conjunto dos princípios deve ser considerado no processo de organização e execução do experimento, no tempo da análise e interpretação dos resultados. Segundo TRAVASSOS (2002) os princípios gerais da organização do experimento são a aleatoriedade, o agrupamento (blocking), e o balanceamento. Uma experimentação 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 não podem ser amplamente aceitos sem que a repetição seja realizada. 2.2.1 MEDIÇÃO Vários autores definem a importância da medição na engenharia de software experimental, segundo WOHLIN et al. (2000) a medição de software é a parte central dos estudos empíricos, ela é crucial para ter controle dos projetos, produtos e processos. Já DEMARCO (1982) afirma que não conseguimos controlar o que não conseguimos medir. TRAVASSOS (2002) define mediçao como o mapeamento do mundo experimental para o mundo formal ou relacional, onde o principal objetivo do mapeamento é a caracterização e a manipulação das entidades empíricas. No mapeamento, o julgamento não é feito diretamente nas entidades reais, são atribuídos números ou símbolos as entidades empíricas, e essa atribuição é chamada de medida enquanto que o atributo da entidade que está sendo medida se denomina métrica. Para WOHLIN et al. (2000) uma medida é um mapeamento de um atributo de uma entidade a ter seu vali medido, geralmente um valor numérico. Segundo TRAVASSOS (2002) geralmente para um mesmo atributo realizamos mais de um mapeamento, onde esses mapeamentos são chamados de escala. As escalas são divididas em quatro tipos:

42

• •

Nominal: O atributo de uma entidade é apresentado como um nome ou símbolo; Ordinal: Ordena as entidades seguindo critérios definidos, usando afirmações do tipo “maior do que...”.

• •

Intervalo: Ordena as entidades também, acrescentando a noção de distância. Razão: O valor do zero é significativo e a razão entre medidas é significativa. Como uma medição pode ser feita em escalas diferentes, algumas vezes é

preciso realizar as transformações entre as diferentes escalas, transformando, por exemplo, metros em centímetros. Quando uma transformação é aceita de uma escala para outra, preservando o relacionamento, ela é chamada de transformação admissível ou redimensionável (FENTON; PFLEEGER, 1996). Com as medidas dos atributos podem-se fazer afirmações sobre os objetos ou a relação entre os objetos ou em relação entre os objetos diferentes. Se a afirmação é verdadeira, mesmo quando são redimensionadas elas são chamadas de significativas e, quando não permanecem afirmativas após o redimensionamento, elas são conhecidas como sem sentido. O objetivo principal da medição na Engenharia de Software, segundo TRAVASSOS (2002), é aumentar a compreensão do processo e do produto, controlálos definindo antecipadamente as atividades corretivas e identificar as possíveis áreas de melhoria. Os objetos que são de interesse da engenharia de software podem ser divididos em três partes diferentes: Processo, produto e recurso (WOHLIN et al.,2000). Na maioria dos casos a medição a engenharia de software utiliza as próprias métricas de software. Para medir o produto, seja intermediário ou o produto final, é utilizado às métricas do produto. Já para medir as características dos processos de desenvolvimento de software utiliza-se as métricas do processo. Pro fim as métricas para medir objetos necessários para o desenvolvimento de software como hardware, equipe, ferramentas entre outras são as métricas de recursos.

43

Como qualquer disciplina da engenharia, o desenvolvimento de software necessita de um mecanismo de medição para evoluir. Esse mecanismo é usado para manter uma memória 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) concluíram que uma medição para ser efetiva deve ser focada no objetivo específico; aplicada para todo o ciclo de vida do processo de desenvolvimento do produto; e interpretada e baseada na caracterização e entendimento no contexto da organização em relação a ambiente e objetivos. Ou seja, a medição deve ser feita no modo top-down, pois precisa ser focada, baseada nos objetivos e modelos. A abordagem bottom-up não funciona, porque existem várias características observáveis em um software. 2.2.2 VALIDADE Para utilizar uma medida nos estudos empíricos, deve-se verificar sua validade. Uma medida válida precisa ser a própria caracterização matemática do atributo e que não viole as propriedades necessárias dos atributos das medidas e. Para TRAVASSOS (2002) a validade dos resultados do experimentos é fundamental. Os resultados devem ser válidos para a população da qual o conjunto de participantes foi recebido. É interessante também generalizar os resultados para uma população mais ampla. Os resultados possuem a validade adequada se são válidos para a população a qual tendem ser generalizados. Uma medida válida permite distinguir os objetos diferentes, mas

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

44

(1979) a lista se estende para quatro tipos: validade de conclusão, validade interna, validade de construção e validade externa. TRAVASSOS (2002) em seu estudo citou também a subdivisão em quatro tipos. A primeira validade é a de conclusão e está relacionada à habilidade de chegar a uma conclusão 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 não é o resultado da influência de outro fator que não é controlado ou mesmo não foi medido. Tem –se também a validade de construção que considera os relacionamentos entre a teoria e a observação, ou seja, se o tratamento reflete a causa bem e o resultado reflete o efeito bem. E por fim, a validade externa, definindo as condições que limitam a habilidade de generalizar os resultados de um experimento para a prática industrial. 2.2.3 TIPOS DE EXPERIMENTOS Existe um grande número de classificações de experimentos. Segundo TRAVASSOS (2002) isto deve-se ao fato da experimentação ainda ser uma abordagem nova na engenharia de requisitos. A classificação dos experimentos está sempre relacionada aos conceitos das estratégias empíricas que são descritos pela literatura, sintetizados em três principais estratégias experimentais: survey, estudo de caso e experimento. O survey é mais indicado para pesquisas de opinião e de mercado. Geralmente é usado para realizar um questionário e entrevistar os “stakholders” envolvidos no novo processo, questionando o que eles estão achando do processo. O estudo de caso é utilizado para realizar um estudo sobre um fenômeno único em um específico espaço de tempo. Uma forma de usar o estudo de caso seria um modelo para verificar a quantidade de requisitos reprovados pelo cliente após a adoção do novo modelo a métrica um seria o número total de requisitos reprovados e a métrica dois seria a quantidade de requisitos reprovados após a adoção do novo modelo.

45

O experimento oferece o maior nível de controle. É indicado realizar o experimento em um ambiente controlado, como um laboratório. Seu objetivo é a manipulação de algumas variáveis, mantendo outras inertes e medindo os efeitos e os resultados. Os experimentos podem ser feitos em laboratório, com um ambiente controlado ou em condições normais. Os experimentos como foi dito antes, são utilizados para confirmar teorias e sugerir melhorias nos processos. A Tabela 5 apresenta a comparação das estratégias empíricas.

Tabela 5: Comparação das estratégias empíricas.

FATOR O controle da execução O controle da medição O controle da investigação Facilidade da repetição Custo

Survey Nenhum Nenhum Baixo Alta Baixo

Estudo de Caso Nenhum Tem Médio Baixa Médio

Experimento Tem Tem Alto Alta Alto

De acordo com as estratégias experimentais existem três principais métodos para coleta de dados: histórico, utilizado para coletar os dados experimentais dos projetos que já tenham sido terminados; o método de observação, que coleta os dados relevantes enquanto o projeto está sendo executado; e o método controlado, que provê as instâncias múltiplas de uma observação oferecendo a validade estatística dos resultados do estudo (TRAVASSOS, 2002). 2.2.4 PROCESSO Segundo WOHLIN et al. (2000) uma experimentação não é um processo simples, porque precisamos preparar, conduzir e analisar os experimentos. Um experimento deve ser tratado como um processo da formulação ou de verificação

46

de uma teoria. Para que o processo do experimento retorne resultados válidos, ele tem que ser organizado e controlado. Para atingir os objetivos foram elaboradas várias metodologias de organização dos experimentos foram elaboradas. BASILI et al. (1994b) descreve uma metodologia de experimentação avançada que está essencialmente ligada à melhoria continua do processo do desenvolvimento de software é o QIP, do inglês, Quality Improvement Paradigm. Essa metodologia define seis passos que resultam em um ciclo de melhoria de processos. O processo inicia o ciclo com a caracterização do processo de negócio necessária para a compreensão do ambiente e a definição dos objetivos básicos. Em seguida, os objetivos quantitativos são estabelecidos. Com base na caracterização e nos objetivos definidos é escolhido o processo mais apropriado. Depois é feita a execução dos processos nos projetos, analisando os dados obtidos em cada projeto e fornecendo um retorno a respeito dos dados que estão sendo coletados. Só então, é realizada uma análise dos dados da informação para avaliar as práticas atuais, determinar os problemas, registrar os achados e realizar recomendações para projetos futuros. Por fim, os dados da informação são analisados e reunidos para avaliar as práticas atuais, determinar os problemas, registrar os achados e realizar recomendações para projetos futuros. O QIP é ligado ao conceito da Fábrica da Experiência (BASILI et al., 1994b) que é o conjunto das ferramentas usadas para realizar o armazenamento, a modificação, e o empacotamento das informações do projeto. Isso significa que além do armazenamento passivo dos dados experimentais, a Fábrica de Experiência pode processar os pedidos do projeto atual oferecendo a informação relevante dos projetos semelhantes. A Figura 4 apresenta a estrutura da Fábrica da Experiência.

47

Figura 4: Esquema de uma fábrica de experiência (TRAVASSOS, 2002).

SOLINGEN e BERGHOUT (1999) descrevem outra abordagem que oferece o processo da melhoria com o modelo da medição baseada em camadas a GQM (Goal Question Metric). Segundo BASILI et al. (1994a), O Goal Question Metric é um mecanismos para definir objetivos mensuráveis. O GQM é uma abordagem que uma organização pode usar para medir seus processos, de uma maneira poderosa, que funciona da seguinte maneira: primeiramente é feita a especificação dos objetivos dos projetos, depois esses objetivos são traçados e finalmente disponibiliza-se um framework para interpretação dos dados com os seus respectivos estados relacionados aos objetivos. Para realizar o processo é utilizada uma abordagem top-down, onde os objetivos são estabelecidos, depois as questões são formuladas, e por fim, as métricas são elaboradas. Já para realizar a interpretação dos resultados é utilizada a abordagem bottom-up, através do uso da medição para receber os dados experimentais, depois formulando as respostas para as questões 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 razões variadas, com vários modelos de qualidade com vários pontos de vista relativos a ambientes em particular. Objetivos de medição são os produtos, processos e recursos.

Question é formada por uma porção de perguntas que são usadas para caracterizar as saídas de avaliação/realização de uma meta (Goal) específica. As perguntas tentam caracterizar o objetivo da medição com respeito a uma qualidade de seleção das questões para determinar a qualidade do ponto de vista selecionado.

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

compreender, controlar, e melhorar. O foco desses objetivos são quatro fatores: o custo, o risco, o tempo, e a qualidade. A junção dos objetivos com os fatores os possibilita aos investigadores o aumento da compreensão 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 estão sendo definidas. A abordagem GQM é composta de quatro fases: A fase do planejamento, quando o projeto da medição está selecionado, definido, caracterizado, e planejado, resultando em o plano do projeto; A fase da definição, quando o programa da medição conceitualmente preparado, ou seja, os objetivos, as questões, as métricas e as hipóteses são estabelecidas; a fase da coleta de dados, quando a coleta de dados experimentais é efetivamente feita resultando em conjunto de dados prontos para a interpretação; e a fase da interpretação, quando os dados são processados a respeito das métricas, questões, e objetivos definidos (TRAVASSOS, 2002). Segundo WOHLIN et al. (2000) a realização de um estudo experimental geralmente pode ser dividida em cinco fases: a definição, o planejamento, a

49

execução, a análise e o empacotamento do estudo. BARROS et al. (1999) sintetizou as cinco fases do estudo experimental da seguinte forma: • Na definição do experimento é realizado um resumo dos objetivos, seu foco de qualidade e os objetos que vão ser analisados. • A fase de planejamento envolve a descrição do perfil dos participantes, dos instrumentos, do processo de execução é realizada uma avaliação criteriosa dos problemas que podem ser encontrados ao longo da execução. • A execução é a realização do estudo experimental pelos participantes, utilizando os instrumentos e o processo definidos na fase de planejamento. • Na fase da análise é realizada a organização dos resultados obtidos pelos participantes durante a execução e a realização de inferências sobre estes resultados. • O empacotamento é a organização e armazenamento dos documentos construídos nas etapas anteriores. Esse armazenamento é feito com o intuito de facilitar a repetição do estudo experimental no futuro. Em relação ao empacotamento TRAVASSOS (2002) afirma que uma das características mais importantes de um experimento é a necessidade da sua repetição. Porque é com a repetição que os pesquisadores obtêm 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 padrão para que seja possível o armazenamento correto deles, pois esses dados experimentais podem servir como base para a criação das bibliotecas de experimentação.

50

3 SOLUÇÃO PROPOSTA
Nesta seção, será descrito o experimento que caracterizou como a engenharia de requisitos está sendo utilizada nos projetos de uma empresa de Tecnologia da Informação. Também será apresentada a adequação do processo de engenharia de requisitos da empresa em relação às práticas específicas de engenharia de requisitos do CMMI. E, por fim, será relatada a opinião dos profissionais que foram entrevistados nesse experimento quanto à utilidade e a necessidade de aumentar ou diminuir o nível de detalhamento do uso dessas práticas, 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 informação que tem a sua Matriz situada no Recife, com filiais em vários estados do Brasil. Ela possui negócios internacionais e um faturamento anual superior a 10 milhões. A empresa não possui certificação CMMI, mas tem a intenção de se certificar, por acreditar ser importante para o futuro da empresa. 3.2 DEFINIÇÃO DOS OBJETIVOS 3.2.1 OBJETIVO GLOBAL: Caracterizar o uso do processo de engenharia de requisitos em uma empresa de Tecnologia da informação, correlacionando o seu uso com as práticas específicas de engenharia de requisitos exigidas pelo CMMI, apontando os pontos fortes e pontos de melhoria no seu processo no nível de utilidade e de adequação do uso. 3.2.2 OBJETIVO DA MEDIÇÃO: Tendo como base a Engenharia de requisitos, caracterizar:

51

1. Quais são as práticas de engenharia de requisitos utilizadas pelos projetos da empresa: • Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que são usadas totalmente ou parcialmente pelos projetos de integração da empresa e são consideradas úteis. • Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são usadas pelos projetos de integração da empresa. 2. Quais são as práticas específicas de engenharia de requisitos exigidas pelo CMMI que são consideradas inadequadas ou úteis pela empresa: • Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que precisam ser mais detalhadas para atender melhor as necessidades da empresa. • Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI são que são consideradas úteis para da empresa. 3.2.3 OBJETIVO DO ESTUDO: Analisar as práticas específicas oferecidas pelo CMMI à empresa, a fim de caracterizá-la com respeito às vantagens oferecidas pelas práticas específicas da engenharia de requisitos exigida pelo CMMI do ponto de vista dos analistas e desenvolvedores da empresa no contexto dos projetos.

3.2.4 QUESTÕES Q1: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que não fazem parte dos projetos de integração da empresa? Métrica1: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que não fazem parte dos projetos de integração da empresa.

52

Q2: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que não estejam trazendo ganhos para a empresa? Métrica2: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que não são consideradas relevantes. Q3: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração e que a empresa considera que esteja trazendo ganhos para ela? Métrica3: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que são consideradas relevantes. Q4: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que não fazem parte dos projetos de integração e que a empresa gostaria de ter? Métrica4: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI não fazem parte dos projetos de integração da empresa e que ela gostaria de ter. Q5: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração e que a empresa que não estão adequadas quanto ao seu uso? Métrica5: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que precisam ser melhoradas.

53

3.3 PLANEJAMENTO 3.3.1 DEFINIÇÃO DAS HIPÓTESES Para realizar o estudo experimental é preciso levantar as hipóteses nula e alternativa. A hipótese nula representa a afirmação que o estudo experimental tem como objetivo negar, e as hipóteses alternativas têm por objetivo rejeitar a hipótese nula. As hipóteses levantadas nesse estudo estão descritas abaixo. Hipótese nula (H0): As práticas específicas da engenharia de requisitos exigidas pelo CMMI são similares às práticas de engenharia de requisitos utilizadas nos projetos de integração da empresa. Pa – Práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pc – Práticas de engenharia de requisitos utilizadas2 nos projetos de integração. H0: Pc – (Pa Pc) = 0 Hipótese alternativa (H1) As práticas específicas da engenharia de requisitos exigidas pelo CMMI são diferentes às práticas utilizadas nos projetos de integração da empresa. Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pc – Práticas de engenharia de requisitos utilizadas nos projetos de integração. H1: : Pc – (Pa Pc) ≠ 0

Hipótese alternativa (H2): As práticas específicas da engenharia de requisitos exigidas pelo CMMI que não fazem parte das utilizadas pela empresa e que ela gostaria de utilizar. Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pau - práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são usadas nos projetos da empresa e que a empresa não gostaria de utilizar. H2: Pa – (Pa Pau) ≠ 0

Hipótese alternativa (H3): As práticas específicas da engenharia de requisitos exigidas pelo CMMI que a empresa não acha útil. Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI;

54

Pau - práticas específicas da engenharia de requisitos exigidas pelo CMMI e que a empresa considera util. H3: Pa – (Pa Pau) ≠ 0

Hipótese alternativa (H4): As práticas específicas da engenharia de requisitos exigidas pelo CMMI utilizadas na empresa que são consideradas adequadas. Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pac - práticas específicas da engenharia de requisitos exigidas pelo CMMI e que a empresa considera inadequada. H2: Pa – (Pa Pac) ≠ 0

3.3.2 DESCRIÇÃO DA INSTRUMENTAÇÃO Para cada prática específica da engenharia de requisitos exigida pelo CMMI foram escolhidos os itens conforme Tabela 6.
Tabela 6: Opções de resposta aplicadas no questionário

Presença da Prática (P) 1. Não é utilizada nos projetos e não acredito ser relevante 2. Não é utilizada, mas gostaria de usar. 3. utilizada, parcialmente. 4. usada.

Utilidade da Prática (U) 1. Não é útil. 2. Provavelmente é útil, mas ainda não apliquei. 3. É útil e já apliquei em diferentes projetos.

Adequação do nível de detalhamento de uso da Prática (A) 1. O detalhamento deve ser aumentado. 2. O detalhamento não precisa ser modificado. 3. O detalhamento deve ser diminuído.

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

55

todos eles foram entrevistados, não é 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 questões abordadas seriam:

• • •

Pode se considerar que essa prática está presente nos projetos? Pode se considerar que essa prática é útil? Pode considerar que o detalhamento do uso da prática não precisa de modificação?

O resultado desse teste seria uma tabela com apenas as respostas iguais a zero ou um e distribuídas entre as questões (P,U,A) onde: P – presença (0 – não usada;1 – usada); U – utilidade (0 – não é útil;1 – é útil); A – adequação (0 – o nível é adequado,1 – o nível não é adequado). A Tabela 7 mostra como ficaria a distribuição de todas as combinações das repostas do teste Chi-2 em relação a presença, utilidade e adequação das práticas e as suas associações com as questões propostas.
Tabela 7: Relação entre os dados de P,U,A e as Questões.

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

Descrição da prática não é usada, não é útil, a modificação não é necessária. não é usada, não é útil, a modificação é necessária. não é usada, é útil, a modificação não é necessária. não é usada, é útil, a modificação é necessária. É usada, não é útil, a modificação não é necessária. É usada, não é útil, a modificação é necessária. É usada, é útil, a modificação não é necessária. É usada, é útil, a modificação é necessária.

Questões Q1,Q2 Q1,Q2 Q1,Q4 Q1,Q4 Q3, Q2 Q3, Q2 Q3 Q3

56

3.3.3 SELEÇÃO DE CONTEXTO O contexto pode ser caracterizado conforme quatro dimensões: • • • • 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 são os profissionais (analistas, desenvolvedores e coordenadores dos projetos). 3.3.4 SELEÇÃO DOS INDIVÍDUOS Os participantes selecionados foram profissionais da empresa que

acompanharam os projetos de integração como coordenadores, analistas e desenvolvedores. Foi proposto aos participantes um questionário com o objetivo de caracterizar sua formação do ponto de vista profissional para analisar os dados e reduzir o viés. 3.3.5 VARIÁVEIS 3.3.5.1 VARIÁVEIS INDEPENDENTES: A lista de práticas de Engenharia de requisitos. 3.3.5.2 VARIÁVEIS DEPENDENTES: 1. A similaridade entre as práticas específicas da engenharia de requisitos exigidas pelo CMMI e as práticas usadas nos projetos de integração da empresa. Pode receber os valores: • Igual, todas as práticas têm o valor PUA = {1, X, X}/qtde de práticas *100;

57

Diferente, todas as práticas têm o valor PUA = {0, X, X}/qtde de práticas *100.

2. A utilidade das práticas específicas. Mostra as práticas específicas da engenharia de requisitos: Parte útil: {1, 1, X} / {1, X, X} * 100 Parte inútil: {1, 0, X} / {1, X, X} * 100 3. A adequação de práticas específicas. Mostra as práticas específicas 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 ANÁLISE QUALITATIVA Foi realizada uma análise qualitativa de modo a analisar a informação referente às práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são usadas pelos projetos de integração da empresa, mas que foram identificadas como úteis pelos entrevistados. Para essa análise foi apresentada uma lista de práticas de engenharia de requisitos exigida pelo CMMI, que não fazem parte do processo dos projetos, mas que a foi identificada como útil e conseqüentemente deveria fazer parte do processo de engenharia de requisitos. Para isso, a análise considerou práticas com valor PUA = {0, X, X}, ou seja, as práticas que não estavam presentes nos projetos. 3.3.7 VALIDADE Validade interna: Na parte “Seleção dos indivíduos” foi mencionado que para o estudo se propõe a utilizar os profissionais da empresa que participaram dos projetos de integração da empresa.

58

Além disso, com o intuito de reduzir a influência dos fatores que não são de interesse do estudo e, aumentando a validade interna do estudo utilizou-se os dados do questionário para dividir dos participantes em grupos conforme os seus papeis nos projetos. Validade de conclusão: para receber os valores da presença, utilidade e conformidade o teste binomial foi utilizado. A verificação de hipótese foi feita por meio de simples demonstração de presença ou não de competências nas listas que representam as variáveis independentes. Validade de construção: esse estudo está caracterizado pela conformidade das práticas específicas da engenharia de requisitos exigidas pelo CMMI. As práticas de engenharia de requisitos utilizadas nos projetos de integração da empresa. As práticas, que têm o maior grau de relevância no que diz respeito à engenharia de requisitos para a empresa, foram escolhidas do conjunto total de práticas da engenharia de requisitos. Validade externa: como foi mencionado nas partes “Seleção dos indivíduos” e “Validade interna” os participantes do estudo em geral podem ser considerados representativos para a população dos profissionais que trabalharam nos projetos de integração da empresa. Para avaliação do nível de envolvimento no processo, os dados do questionário, conforme a experiência dos participantes foram analisados. Os materiais utilizados no estudo podem ser considerados representativos e “em tempo” para o problema sob análise, porque se compõem das práticas da engenharia de requisitos.

59

3.4 OPERAÇÃO 3.4.1 MATERIAL INFORMATIVO DAS PRÁTICAS ESPECÍFICAS 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 práticas específicas e suas subpráticas. Esse material tem por objetivo alinhar o conhecimento dos participantes em relação às práticas específicas do CMMI e ajudar aos participantes a responderem o questionário das práticas.

Tabela 8: Práticas específicas de objetivo específico de gerenciamento de requisitos e suas subpráticas.

Área de processo (AP): Gerenciamento de Requisitos – REQM Objetivo Específico (OE): Gerenciar Requisitos Práticas específicas (PE) PE1 Obter um entendimento dos requisitos.

A fim de evitar problemas futuros, são designadas as fontes oficiais que serão responsáveis por disponibilizar e receber os requisitos. A prática específica do entendimento dos requisitos trata do estabelecimento do uso de um mecanismo que obtém, com o cliente, o significado do requisito. Ele é composto por atividades que captam os requisitos para assegurar que sua compreensão foi atingida. Essa prática também estabelece os critérios que evitam o crescimento indistinto dos mesmos. Para essa prática são utilizados como produtos de trabalho: 1. Lista de critérios para a apropriada distinção dos fornecedores dos requisitos. 2. Critérios para avaliação e aceitação dos requisitos. 3. Resultados das análises em relação aos critérios.

60

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

Quando são formadas as equipes, o compromisso com os requisitos é necessário, assegurando que as mudanças ocorridas ao longo do tempo sejam disponibilizadas para todos os envolvidos. Essa prática trata de acordos e compromissos entre os profissionais envolvidos na execução das atividades necessárias para implementação dos requisitos. Para essa prática são utilizados como produtos de trabalho: 1. Analisar os impactos dos requisitos. 2. Compromissos documentados com os requisitos e com as mudanças de requisitos. PE3 Gerenciar mudanças de requisitos.

Gerenciar as mudanças nos requisitos durante a evolução do projeto é importante para manter os requisitos atualizados, pois eles podem mudar devido a vários fatores, inclusive fatores não previstos, como por exemplo, a exigência de atendimento a uma nova legislação. Estas mudanças devem ser controladas de forma que permita a avaliação dos impactos que podem ocorrer em todo o projeto. Ela também possibilita aos gerentes rastrear as medidas de volatilidade de requisitos para julgar a necessidade de novos controles ou, fazer a revisão dos existentes. Para essa prática são utilizados como produtos de trabalho: Status de requisitos. Banco de dados de requisitos. Banco de dados de decisões de requisitos. Subpráticas: 1. Documentar todos os requisitos e mudanças de requisitos do projeto.

61

2. Manter um histórico de mudanças de requisitos com os fundamentos lógicos das mudanças. 3. Manter o histórico de mudanças ajuda a rastrear a volatilidade dos requisitos. 4. Avaliar o impacto das mudanças de requisitos do ponto de vista dos stackeholders relevantes. 5. Tornar disponíveis ao projeto os dados de requisitos e de mudanças. PE4 Manter rastreabilidade bidirecional de requisitos.

Esta prática é importante porque a partir de uma rastreabilidade bidirecional bem feita é possível rastrear os requisitos até sua origem e retornar a sua condição atual, por exemplo, indicando qual será o impacto das mudanças neles e como será refletida no projeto. Para essa prática são utilizados como produtos de trabalho: 1. Matriz de rastreabilidade de requisitos. 2. Sistema de rastreamento de requisitos. Subpráticas: 1. Manter a rastreabilidade dos requisitos para assegurar que a origem do menor nível de requisito (derivado) esteja documentada. 2. Manter a rastreabilidade de um requisito com seus requisitos derivados e com sua alocação a funções, interfaces, pessoas, processos e produtos de trabalho. 3. Gerar a matriz de rastreabilidade de requisitos. PE5 Identificar inconsistências entre artefatos do projeto e requisitos.

Essa prática é utilizada para descobrir as inconsistências entre os

62

requisitos e os planos do projeto e produtos de trabalho. Isso permite iniciar ações corretivas para não desviar o foco do requisito em questão. Para essa prática é utilizado como produto de trabalho: 1. Documentação de inconsistências incluindo fontes, condições e

justificativas e ações corretivas. Subpráticas: 1. Revisar os planos de projeto, atividades e produtos de trabalho visando à consistência com os requisitos e com as mudanças neles realizadas. 2. Identificar a origem das inconsistências e fundamento lógico. 3. Identificar mudanças que necessitam ser feitas nos planos e produtos de trabalho resultantes das mudanças na baseline de requisitos. 4. Iniciar as ações corretivas.

Tabela 9: Práticas específicas de objetivo especifico de desenvolvimento de requisitos do cliente e suas subpráticas.

Área de processo (AP): Desenvolvimento de Requisitos – RD Objetivo Específico (OE): Desenvolver Requisitos do Cliente Práticas específicas (PE) PE01 Coletar as necessidades dos stakeholders.

Essa prática específica propõe realizar o levantamento das necessidades, expectativas, restrições e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai além da coleta de requisitos, incluindo a identificação adicional e pró-ativa de requisitos não fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam endereçar as várias atividades do ciclo de vida do produto e seus impactos no produto.

63

Subpráticas: 1. Envolver os stakeholders relevantes usando métodos para levantamento de necessidades, expectativas, restrições e interfaces externas. PE02 Elicitar as necessidades.

Essa prática específica propõe realizar o levantamento das necessidades, expectativas, restrições e interfaces dos stakeholders para todas as fases do ciclo de vida do produto. Este levantamento vai além da coleta de requisitos, incluindo a identificação adicional e pró-ativa de requisitos não fornecidos explicitamente pelos clientes. Para levantar os requisitos adicionais que deveriam endereçar as várias atividades do ciclo de vida do produto e seus impactos no produto. Subpráticas: 1. Envolver os stakeholders relevantes usando métodos para levantamento de necessidades, expectativas, restrições e interfaces externas. PE03 Essa Desenvolver os Requisitos dos clientes. prática específica transforma as necessidades, expectativas,

restrições e interfaces dos stakeholders em requisitos do cliente. Subpráticas: 1. Traduzir as necessidades, expectativas, restrições e interfaces dos stakeholders em requisitos do cliente documentados; 2. Definir restrições de verificação e validação.

Objetivo Específico (OE): Desenvolver requisitos do produto Práticas específicas (PE)

64

PE04

Estabelecer os requisitos dos produtos e seus componentes.

Essa prática específica estabelece e mantém os requisitos do produto e dos componentes de produto, que são baseados nos requisitos do cliente. Subpráticas: 1. Desenvolver os requisitos em termos técnicos, necessários ao design do produto e dos componentes de produto. Desenvolver os requisitos de arquitetura endereçando qualidades e desempenho críticos do produto necessários ao design da arquitetura do produto; 2. Derivar os requisitos que resultam das decisões de design. PE05 Alocar os requisitos dos componentes dos produtos.

Essa prática específica propõe alocar os requisitos de cada componente do produto. Subpráticas: 1. Alocar requisitos a funções; 2. Alocar requisitos a componentes de produto; 3. Alocar restrições de design a componentes de produto. PE06 Identificar os requisitos de interfaces.

Essa prática identifica os requisitos de interface. As Interfaces entre funções ou entre objetos são identificadas. As interfaces funcionais podem orientar o desenvolvimento de soluções alternativas descritas na área de processo. Subpráticas: 1. Identificar as interfaces externas e internas do produto. À medida que o design evolui, a arquitetura do produto será alterada pelos processos da solução técnica, 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 são definidos em termos de aspectos tais como origem, destino, estímulo, características de dados para software e hardware.

Objetivo Específico (OE): Desenvolver requisitos do produto Práticas específicas (PE) PE07 Estabelecer conceitos operacionais e cenários.

Essa prática estabelece e mantém conceitos operacionais e cenários associados. Um cenário é tipicamente uma seqüência de eventos que poderia ocorrer no uso do produto, que são usados para tornar explícita alguma necessidade dos stakeholders. Subpráticas: 1. Elaborar conceitos operacionais e cenários que incluam funcionalidade, desempenho, manutenção, suporte e descarte quando apropriado; 2. Definir o ambiente no qual o produto ou o componente de produto irá operar, incluindo fronteiras e restrições; 3. Revisar os conceitos e cenários operacionais para descobrir e refinar requisitos; 4. Desenvolver um conceito operacional detalhado, quando o produto e os componentes de produto são selecionados, para satisfazer às necessidades operacionais, de manutenção, de suporte e de descarte. PE08 Estabelecer uma definição das funcionalidades requeridas.

Essa prática propõe a definição de funcionalidade, também chamada de “análise funcional”, é a descrição do que o produto pretende fazer. A definição de funcionalidades pode incluir ações, seqüências, entradas, saídas ou outras informações que comunicam à maneira que o produto será usado.

66

Subpráticas: 1. Analisar e quantificar as funcionalidades requeridas pelos usuários finais; 2. Analisar os requisitos para identificar as partições lógicas ou funcionais; 3. Particionar os requisitos em grupos, com base nos critérios estabelecidos,para facilitar ou dar foco à análise de requisitos; 4. Considerar a seqüência das funções de tempo-crítico, no início e durante o desenvolvimento dos componentes de produto; 5. Alocar os requisitos do cliente às partições funcionais, objetos, pessoas ou a elementos de suporte para dar suporte à síntese de soluções; 6. Alocar requisitos funcionais e de desempenho às funções e subfunções. PE09 Analisar os requisitos.

Essa prática prega que os requisitos sejam analisados para determinar se eles são necessários e suficientes para atender aos objetivos dos níveis mais altos da hierarquia do produto. Então, os requisitos analisados fornecem uma base de requisitos mais detalhada e precisa para os níveis mais baixos da hierarquia do produto. Subpráticas: 1. Analisar as necessidades, expectativas, restrições 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 níveis mais altos; 3. Analisar os requisitos para garantir que eles sejam completos, economicamente viáveis, implementáveis e verificáveis. Enquanto o design determina a viabilidade de uma solução particular; 4. Identificar os requisitos-chave que têm uma forte influência nos custos, cronograma, funcionalidades, riscos ou desempenho; 5. Identificar medidas de desempenho técnico que serão acompanhados durante o esforço de desenvolvimento;

67

6. Analisar os conceitos e cenários operacionais para refinar as necessidades, restrições e interfaces do cliente, e descobrir novos requisitos. PE10 Analisar os requisitos para avaliação.

Essa prática específica trata da análise das necessidades e restrições dos stakeholders, verificando as questões relacionadas a custos, cronograma, desempenho, funcionalidade, componentes reusáveis e manutenibilidade ou risco. Subpráticas: 1. Usar modelos comprovados, simulações e prototipagem para analisar o equilíbrio de necessidades e restrições dos stakeholders; 4. Realizar uma avaliação 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 prática específica prega que a validação dos requisitos tem que ser realizada precocemente no esforço de desenvolvimento com os usuários finais para obter confiança de que os requisitos são capazes de guiar um desenvolvimento que resulte em validação final bem sucedida. Subpráticas: 1. Analisar os requisitos para determinar o risco do produto resultante não funcionar apropriadamente em seu ambiente de uso pretendido; 2. Explorar a adequação e completitude dos requisitos por meio do desenvolvimento de representações do produto; como protótipos, simulações, modelos, cenários e roteiros; e de obtenção de feedbacks dos stakeholders relevantes a respeito dessas representações; 3. Avaliar o design à medida que ele amadurece no contexto do ambiente de validação dos requisitos para identificar problemas de validação e expor

68

necessidades e requisitos do cliente não declarados.

3.4.2 QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES
Tabela 10: Questionário do perfil dos participantes

Responda: FORMAÇÃO. ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ PROFISSÃO. ___________________________________________________________________ ___________________________________________________________________

TEMPO DE EXPERIENCIA PROFISSIONAL. __________________________________________________________________

CARGOS OCUPADOS NA EMPRESA. ___________________________________________________________________ ___________________________________________________________________

69

3.4.3 QUESTIONÁRIO DAS PRÁTICAS Relacionando-se apenas com os projetos de integração da empresa que você participou em relação ao processo de engenharia de requisitos, por favor, avalie e marque as colunas correspondentes segundo as escalas da Tabela 11 considerando a presença, utilidade e adequação das práticas de engenharia de requisitos listadas no questionário da Tabela 12.

Tabela 11: Escalas para respostas.

Presença da Prática (P)

Utilidade da Prática (U)

Adequação do nível de detalhamento de uso da Prática (A) 1. O detalhamento deve ser aumentado. 2. O detalhamento não precisa ser modificado. 3. O detalhamento deve ser diminuído.

1. Não é usada nos projetos e não acredito ser relevante 2. Não é usada, mas gostaria de usar. 3. Usada, parcialmente. 4. usada.

1. Não é útil. 2. Provavelmente é útil, mas ainda não apliquei. 3. É útil e já apliquei em diferentes projetos.

Tabela 12: Questionário da lista de práticas de engenharia de requisitos.

N

Prática

Descrição

Presença

Utilidade Adequação

Área de processo - Gerenciamento de Requisitos PE 01 - Obtenção 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.

3

4

1

2

3

1

2

3

70

1.2 Identificação dos fornecedores de requisitos 1.3 Obtenção do aceite

É estabelecido critérios para identificar esses fornecedores. Existe critérios objetivos para receber o aceite de requisitos dos fornecedores. Os requisitos são analisados para garantir que estes satisfaçam os critérios estabelecidos. Considerando as respostas (1.1, 1.2, 1.3 e 1.4) Sua opinião relacionada à prática de obtenção do entendimento dos requisitos.

1.4 Análise dos requisitos.

01

Obtenção do Entendimento dos Requisitos

PE 02 - Obtenção 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 são avaliados.

3

4

1

2

3

1

2

3

2.2 Registro do Comprometimento 2.3 Avaliar Impactos

02

Obtenção do Comprometimento dos Requisitos

Considerando as respostas (2.1, 2.2 e 2.3) Sua opinião relacionada à prática de Obtenção do Comprometimento dos Requisitos.

71

PE 03 - Gerenciar mudanças de requisitos 1 2 3.1 Identificação da fonte das mudanças
São identificadas as fontes de cada requisitos e as razões de suas mudanças.

3

4

1

2

3

1

2

3

3.2 Histórico das mudanças

O histórico de mudanças são mantidos.

3.3 Análise de impacto

Existe a etapa de análises de impacto.

3.4 Disponibilização das mudanças

Informações sobre os requisitos e mudanças são disponibilizadas para o restante do projeto. Considerando as respostas (3.1, 3.2, 3.3 e 3.4) Sua opinião relacionada à prática de Gerenciar mudanças de requisitos.

03

Gerenciar mudanças de requisitos

PE 04 – Manter a Rastreabilidade Bidirecional dos Requisitos 1 2 4.1 Identificação da necessidade 4.2 Identificação da existência 4.3 Requisitos relacionados 4.4 Relação com outras informações
È possível identificar de quem é a necessidade que gerou o requisito. È possível identificar por que o requisitos existe. È possível identificar quais os requisitos relacionados. É possível identificar como os requisitos se relacionam a outras informações como design, implementações e outros documentos.

3

4

1

2

3

1

2

3

72

04

Manter a Rastreabilidade Bidirecional dos Requisitos

Considerando as respostas (4.1, 4.2, 4.3 e 4.4) Sua opinião relacionada à prática de Manter a Rastreabilidade Bidirecional dos Requisitos.

PE 05 - Identificar Inconsistências Entre Artefatos do Projeto e Requisitos 1 2 5.1 Analise dos requisitos
A análise dos requisitos são feitas de forma criteriosa.

3

4

1

2

3

1

2

3

5.2 Ações corretivas

Existe uma tomada de ações corretivas para evitar a inconsistências. Existe algum trabalho realizado para descobrir as fontes e as causas das inconsistências.

5.3 Descobrimento das fontes

05

Identificar Inconsistências Entre Artefatos do Projeto e Requisitos

Considerando as respostas (5.1, 5.2 e 5.3) Sua opinião relacionada à prática de Identificar Inconsistências 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.

3

4

1

2

3

1

2

3

07

Elicitar as necessidades

Existem métodos para a elicitação das necessidades, expectativas, restrições dos requisitos junto aos stakeholders.

73

08

Desenvolver os Requisitos dos clientes

O desenvolvimento dos requisitos são acompanhados para identificar se estão de acordo com o solicitado pelo cliente estando Validados e Verificação. Os requisitos são detalhados nas funcionalidades, características, tecnologia e os custos desses atendimentos são levantados.

09

Estabelecer os requisitos dos produtos e seus componentes

10

Alocação dos requisitos dos componentes dos produtos

Existe a transformação das necessidades dos stakeholders requisitos do produto e uma alocação e distribuição dos requisitos nos componentes do produto. Existe o detalhamento das interfaces de entrada e saída.

11

Identificar os requisitos de interfaces

12

Conceitos operacionais e cenários

As seqüências de eventos possíveis com os fluxos descritos em casos de uso Além da preocupação com a instalação, manutenção e suporte do produto. Existe uma definição das funcionalidades requeridas em forma de caso de uso e diagramas de atividades. É realizado o relatório de incompletudes e inconsistências dos requisitos e existe uma definição de priorização dos requisitos.

13

Definição das funcionalidades requeridas

14

Analisar os requisitos

74

15

Analisar os requisitos para avaliação

Os riscos das necessidades dos usuários são avaliados

16

Validar os requisitos

É utilizado algum tipo de relatório de validação dos requisitos.

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

Área de processo - Gerenciamento de Requisitos N° 01 Prática Obtenção do Entendimento dos Requisitos Presença: 4 - Parcialmente presente 02 Obtenção do Comprometimento dos Requisitos Presença: 4 - Ausente gostaria de usar. 03 Utilidade: 4 - Útil e não usada Adequação: 4 - Aumentar detalhamento Utilidade: 4 - Útil e usada Adequação: 4 - Aumentar detalhamento Descrição Sua opinião relacionada à prática de obtenção do entendimento dos requisitos.

Sua opinião relacionada à prática de Obtenção do Comprometimento dos Requisitos.

Gerenciar mudanças Sua opinião relacionada à prática de Gerenciar

75

de requisitos

mudanças de requisitos.

Presença:

Utilidade:

Adequação: 4 - Aumentar detalhamento

4 - Parcialmente presente. 4 - Útil e usada

Área de processo - Gerenciamento de Requisitos N° 04 Prática Manter a Rastreabilidade Bidirecional dos Requisitos. Presença: Utilidade: Adequação: 4 - Aumentar detalhamento Descrição Sua opinião relacionada à prática de Manter a Rastreabilidade Bidirecional dos Requisitos.

4 - Parcialmente presente 4 - Útil e usada 05 Identificar

Sua opinião relacionada à prática de Identificar Entre Artefatos do Projeto e

Inconsistências Entre Inconsistências Artefatos do Projeto Requisitos. e Requisitos Presença: 4 - Parcialmente presente Utilidade: 4 - Útil e usada

Adequação: 4 - Aumentar detalhamento

Área de processo - Desenvolvimento de Requisitos N° 06 Prática Coleta das necessidades Presença: 3 - Parcialmente presente 1 - Presente Utilidade: 4 - Útil e usada Adequação: 4 - Aumentar detalhamento Descrição Existe a coleta das necessidades dos stakeholders.

76

07

Elicitar as necessidades

Existem métodos para a elicitação das necessidades, expectativas, restrições dos requisitos junto aos stakeholders.

Presença: 4 - Ausente gostaria de usar 08 Desenvolver os Requisitos dos clientes

Utilidade: 4 - Útil e não usada

Adequação: 4 - Aumentar detalhamento

O desenvolvimento dos requisitos são acompanhados para identificar se estão de acordo com o solicitado pelo cliente estando Validados e Verificação.

Presença: 1 - Parcialmente presente 3 - Usada

Utilidade: 4 - Útil e usada

Adequação: 4 - Aumentar detalhamento

Área de processo - Desenvolvimento de Requisitos N° 09 Prática Estabelecer os requisitos dos produtos e seus componentes Presença: 4 - Ausente gostaria de usar 10 Alocação dos requisitos dos componentes dos produtos Presença: 1 - Ausente gostaria de usar Utilidade: 4 - Útil e não usada Adequação: 4 - Aumentar detalhamento Descrição Existe a coleta das necessidades dos stakeholders.

Existe a transformação das necessidades dos stakeholders requisitos do produto e uma alocação e distribuição dos requisitos nos componentes do produto. Utilidade: 1 - Útil e não usada Adequação: 4 - Aumentar detalhamento

77

3 – Parcialmente presente 11 Identificar os requisitos de interfaces Presença: 4 - Usada

3 - Útil e usada Existe o detalhamento das interfaces de entrada e saída.

Utilidade: 4 - Útil e usada

Adequação: 3 - Aumentar detalhamento 1 – não precisa modificar

Área de processo - Desenvolvimento de Requisitos N° 12 Prática Conceitos operacionais e cenários Presença: 4 - Ausente gostaria de usar 13 Definição das funcionalidades requeridas Presença: 3 - Ausente gostaria de usar 1 – Parcialmente presente 14 Analisar os requisitos Utilidade: 3 - Útil e não usada 1 - Útil e usada É realizado o relatório de incompletudes e inconsistências dos requisitos e existe uma definição de priorização dos requisitos. Presença: 4 - Ausente gostaria de usar Utilidade: 4 - Útil e não usada Adequação: 4 - Aumentar detalhamento Adequação: 4 - Aumentar detalhamento Descrição As seqüências de eventos possíveis com os fluxos descritos em casos de uso Além da preocupação com a instalação, manutenção e suporte do produto. Utilidade: 4 - Útil e não usada Adequação: 4 - Aumentar detalhamento

Existe uma definição das funcionalidades requeridas em forma de caso de uso e diagramas de atividades.

78

Área de processo - Desenvolvimento de Requisitos N° 15 Prática Analisar os requisitos para avaliação Presença: 3 - Ausente gostaria de usar 1 – Parcialmente presente 16 Validar os requisitos Descrição Os riscos das necessidades dos usuários são avaliados Utilidade: 3 - Útil e não usada 1 - Útil e usada É utilizado algum tipo de relatório de validação dos requisitos. Presença: 4 - Ausente gostaria de usar Utilidade: 4 - Útil e não usada Adequação: 4 - Aumentar detalhamento Adequação: 4 - Aumentar detalhamento

3.4.4.2 PERFIS DOS PARTICIPANTES O perfil dos participantes do experimento está detalhado abaixo em tabelas e gráficos. A Tabela 14 exibe os dados dos participantes que responderam os questionários em relação a sua formação, profissão, tempo de experiência em desenvolvimento de sistemas e os cargos que o entrevistado ocupou na empresa. A Tabela 15 é uma legenda que auxilia o entendimento das informações da Tabela 14. O gráfico da Figura 5 mostra a distribuicao dos dados dos proissionais entrevistados em relação a formacao, profissão e tempo de experiencia

79

Tabela 14: Perfil dos participantes.

Número

do Formação

Profissão

Tempo experiência

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 auxílio da tabela 11

Formação 1 2 3 Técnico Graduado Pós-Graduado 1 2 3

Profissão Programador Analista de Sistemas Coordenador 1 2 3

Cargos ocupados Programador Analista de Sistemas Coordenador

Figura 5: Distribuição dos dados dos profissionais entrevistados
16 14 12 10 8 6 4 2 0 1 2 3 4 Formação Profissão Tempo de experiência

80

3.5 ANÁLISE E INTERPRETAÇÃO DOS RESULTADOS 3.5.1 VALIDAÇÃO DOS RESULTADOS Todas as respostas foram consideradas válidas do ponto de vista dos valores de presença, utilidade e adequação (PUA). 3.5.2 ESTATÍSTICA DESCRITIVA Medidas de tendência central, como os valores "Presença", "Utilidade" e "Adequação", são da escala ordinal, sendo possível definir somente as métricas de "moda" e "mediana". A Tabela 16 exibe a mediana e a moda referente às respostas dadas pelos entrevistados em relação à presença ou não das práticas. Já a Tabela 17 exibe Mediana e Moda referente às respostas sobre a utilidade das práticas sugeridas pelo CMMI no processo da empresa. A Tabela 18 exibe Mediana e Moda referente às respostas sobre a adequação das práticas sugeridas pelo CMMI no processo da empresa.

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

Práticas
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 práticas sugeridas pelo CMMI no processo da empresa.

Práticas
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 adequação das práticas sugeridas pelo CMMI no processo da empresa.

Práticas
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 questionários precisaram ser ajustadas para se adequarem aos resultados de presença, utilidade e adequação. Para isso, foram consideradas práticas presentes, as que apresentaram mediana e moda iguais a três ou quatro na Tabela 16. Por conseqüência as práticas consideradas ausentes foram as que apresentaram valores iguais a um e dois. Foram consideradas práticas úteis, as que apresentaram valores iguais a dois ou três na Tabela 17. As que apresentaram valores iguais a um foram consideradas inúteis, o que não aconteceu; ou seja, todas as práticas foram consideradas úteis. Nesse estudo as práticas consideradas adequadas deveriam apresentar o valor dois, em relação à Tabela 18, enquanto que as práticas que precisavam ser mais detalhadas e melhores adequadas tiveram valores iguais a um e três. Considerando as respostas dos participantes do experimento e utilizando os resultados de estatística descritiva, as respostas dadas pelos participantes do experimento podem ser divididas em três grupos, listados abaixo:

82

O grupo de práticas que são 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 práticas usadas parcialmente. Legenda: P - Presente (Parcialmente ou não):Não presente U - Útil (já usou ou

acha útil):Inútil A - Adequado:Inadequado (precisa ser aumentado ou diminuído)

Nº Práticas 08 Desenvolver Requisitos clientes

P os 4:0 dos

U 4:0

A 0:4

Características • As práticas são usadas

plenamente pelos projetos; • As práticas são 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 são 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 práticas usadas plenamente Legenda: P - Presente (Parcialmente ou não):Não presente U - Útil (já usou ou acha

útil):Inútil A - Adequado:Inadequado (precisa ser aumentado ou diminuído)

Nº 01

Práticas Obter entendimento requisitos

P um 4:0 dos

U 4:0

A 1:3

Características • As práticas que são usadas

parcialmente

plenamente pelos projetos; mudanças 4:0 4:0 0:4 • As práticas são consideradas úteis e já foram aplicadas 4:0 de 4:0 0:4 pelos profissionais entrevistados da empresa; • O detalhamento do uso das práticas deve ser aumentado. 4:0 entre 4:0 0:4

03

Gerenciar

de requisitos 04 Manter rastreabilidade bidirecional requisitos 05 Identificar inconsistências requisitos 06 Coleta necessidades 10 Alocação 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 não são usadas nos projetos da empresa, consideradas úteis e que os profissionais entrevistados gostariam de utilizar nos projetos.
Tabela 21: Lista de práticas não usadas que gostariam de usar Legenda: P - Presente (Parcialmente ou não):Não presente U - Útil (já usou ou

acha útil):Inútil A - Adequado:Inadequado (precisa ser aumentado ou diminuído)

Nº Práticas Obter 02 comprometimento com requisitos 07 Elicitar necessidades 09 Estabelecer requisitos produtos e componentes Conceitos 12 operacionais e cenários Definição das 13 funcionalidades requeridas Analisar os 14 requisitos Analisar os 15 requisitos para avaliação Validar os 16 requisitos

P 0:4

U 4:0

A 0:4

Características • As práticas não são usadas pelos projetos;

as 0:4

4:0

0:4

As práticas são 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 práticas 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 ANÁLISE DOS RESULTADOS 3.5.3.1 ANÁLISE QUANTITATIVA Para realizar a análise quantitativa precisam-se saber os valores das respostas dos participantes em relação à presença da prática (0 – não usada; 1 – usada); utilidade da prática (0 – não é útil; 1 – é útil) e adequação da prática (0 – o nível é adequado, 1 – o nível não é adequado). A Tabela 22 exibe esse resultado.

Tabela 22: Relação das respostas quantificadas.

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

Prática Obter um entendimento dos requisitos Obter comprometimento com requisitos Gerenciar mudanças de requisitos Manter rastreabilidade bidirecional de requisitos Identificar inconsistências 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 Alocação dos requisitos dos componentes dos produtos Identificar os requisitos de interfaces Conceitos operacionais e cenários Definição das funcionalidades requeridas Analisar os requisitos Analisar os requisitos para avaliação 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 práticas específicas exigidas pelo CMMI e as práticas utilizadas pelos projetos, a partir das respostas listadas na Tabela 22, foi calculado o valor de variável dependente. 1. Os conjuntos das práticas da engenharia de requisitos usadas nos projetos da empresa e as práticas específicas da engenharia de requisitos exigidas pelo CMMI não podem ser consideradas iguais (a quantidade de práticas com o valor PUA {1, X, X} = 8<16) nem diferentes (a quantidade de práticas com o valor PUA {0, X, X} é

86

8<16). Com isso a fórmula do grau de similaridade pode ser calculada da seguinte forma: variável 1: grau de similaridade = 8 / 18 * 100% = 50,00% A verificação da utilidade das práticas de engenharia de requisitos do CMMI que são similares as práticas de engenharia de requisitos empregadas nos projetos, é feita através do cálculo do valor de variável dependente 2: Parte útil das práticas similares: 8 / 8 * 100% = 100% Parte inútil das práticas similares: 0 / 8 * 100% = 0% A verificação da adequação das práticas de engenharia de requisitos do CMMI que são similares as práticas de engenharia de requisitos empregadas nos projetos, é feita através do cálculo do valor de variável dependente 3: Parte adequada das práticas similares: 0 / 8 * 100% = 0% Parte inadequada das práticas similares: 8 / 8 * 100% = 100% 3.5.3.2 ANÁLISE QUALITATIVA A verificação da existência das práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são utilizadas pelos projetos da empresa, mas que a empresa gostaria de utilizar foi feita através do uso da análise qualitativa. A Tabela 23 mostra a lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são utilizadas pelos projetos da empresa, mas que a empresa gostaria de utilizar:
Tabela 23: Lista das práticas que não foram usadas.

N° 02 07 09 12

Prática Obter comprometimento com requisitos Elicitar as necessidades Estabelecer os requisitos dos produtos e seus componentes Conceitos operacionais e cenários

P 0 0 0 0

U 1 1 1 1

A 1 1 1 1

87

13 14 15 16

Definição das funcionalidades requeridas Analisar os requisitos Analisar os requisitos para avaliação Validar os requisitos

0 0 0 0

1 1 1 1

1 1 1 1

A partir dessas informações pode-se concluir que todas as práticas de engenharia de requisitos exigidas pelo CMMI são consideradas úteis pelos participantes, incluído as práticas que não esta sendo utilizadas. 3.5.3.3 VERIFICAÇÃO DAS HIPÓTESES Hipótese nula (H0): Para verificar a hipótese nula precisamos responder a questão Q1 utilizando a métrica M4. O resultado das entrevistas, exibido na Tabela 22, mostra que oito das dezesseis práticas especificas da engenharia de software exigidas pelo CMMI não estão sendo utilizadas nos projetos da empresa. Assim, pode-se, concluir que nem todas as práticas específicas da engenharia de requisitos exigidas pelo CMMI fazem parte dos projetos de integração da empresa (hipótese alternativa H1). De acordo com os resultados da Tabela 22, todas as oito práticas que não são usadas nos projetos foram consideradas úteis pelos participantes do experimento. Ou seja, ainda existem práticas específicas da engenharia de software exigidas pelo CMMI que não são utilizados nos projetos da empresa, mas que a empresa gostaria de utilizar (hipótese alternativa H2). Finalmente, pode-se afirmar que na lista das práticas específicas da engenharia de software exigidas pelo CMMI não existe alguma prática que a empresa ache inútil (hipótese alternativa H3), pois o resultado da Tabela 22 mostra que todas as práticas foram consideradas úteis pelos participantes do experimento. Um dado relevante é que nenhuma prática específica foi considerada adequada (hipótese alternativa H4). Então, pode-se concluir que mesmo as práticas específicas presentes nos projetos são consideradas pelos participantes do

88

experimento inadequadas, ou seja, a adequação da prática relacionada ao seu detalhamento precisa ser melhorada. 3.6 CONCLUSÕES 3.6.1 CARACTERIZAÇÃO A caracterização do processo de engenharia de requisitos da empresa mostrou que existem ainda oito práticas específicas que não são utilizadas. Observou-se que nenhuma das práticas utilizadas nos projetos é considerada totalmente adequada. O resultado mostra também que apesar de não utilizar todas as práticas, os participantes acharam todas elas úteis, sinalizando o desejo de utilizá-las. Em relação ao CMMI, considerando as respostas relacionadas a uso total e parcial nos projetos, o resultado mostra que a empresa utiliza a maioria das práticas específicas da área de processo de gestão de requisitos. Apenas uma das cinco práticas não foi utilizada nos projetos. Em relação às práticas específicas da área de processo de desenvolvimento de requisitos, os resultados se inverteram, e, das onze práticas, apenas quatro foram utilizadas, totalmente ou parcialmente, nos projetos, significando que a empresa possui um processo de gestão de requisitos mais forte que o próprio desenvolvimento deles. 3.6.2 PONTOS FORTES O estudo apontou que a empresa utiliza quatro das cinco práticas da engenharia de requisitos da área de processo de gestão de requisitos exigidas pelo CMMI. Outro ponto positivo apontado no experimento é que todas as práticas da engenharia de requisitos utilizadas nos projetos, que são exigidas pelo CMMI, foram consideradas úteis.

89

3.6.3 PONTOS DE MELHORIA Todas as práticas 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 não se preocupa em receber dos clientes o comprometimento dos participantes dos projetos com os requisitos acordados. Essa prática objetiva o comprometimento com os requisitos e pode evitar mudanças desnecessárias nos requisitos. A falta de um método de elicitação de necessidades e expectativas dos requisitos junto aos stakeholders pode gerar no futuro um produto que não atende as necessidades dos mais interessados. Outro ponto falho relacionado à engenharia de requisitos nos projetos, é que não existe um método 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 prática é usada para levantar as necessidades relacionadas a características e tecnologia e essas características podem virar exigências que gerem, para a empresa, a necessidade de adquirir alguma tecnologia. A falta da prática especifica que estabelece os conceitos operacionais e cenários pode gerar para os clientes um mau entendimento dos requisitos levantados, pois os usuários não terão a visão de fluxo do processo do requisito levantado. Os casos de uso que são levantados também são boas práticas para levantar cenários que podem ajudar no entendimento dos requisitos, tanto do ponto de vista dos clientes, quanto dos desenvolvedores. O não uso da prática de análise de requisitos, que tem como objetivo analisar as inconsistências, incompletudes e definir a priorização dos requisitos, também é um ponto a ser melhorado no processo de engenharia de requisitos da empresa. Como também a falta da avaliação das necessidades dos usuários que pode gerar mais demandas de inclusão e alteração de requisitos fechados.

90

Por fim, o ponto mais alarmante: a falta da prática de validação de requisitos. Não ter um processo de validação de requisitos bem definido, pode levar a empresa a desenvolver requisitos que não se adeque as expectativas dos clientes, correndo o risco de invalidar todo o projeto.

91

4

CONSIDERAÇÕES FINAIS
A experimentação oferece uma maneira de caracterizar e comparar as novas

invenções publicadas ou apresentadas ou, ainda, processos e práticas utilizadas em empresas com os processos e práticas existentes e com isso, obter uma conclusão do uso do processo, prática ou invenção, permitindo um aperfeiçoamento de seu uso. Esse trabalho forneceu importantes contribuições na área de pesquisa de engenharia de software experimental e na área de engenharia de requisitos em relação às práticas específicas do CMMI, são elas: • O uso da engenharia de software experimental para caracterizar o processo de engenharia de requisitos; • Um levantamento das práticas específicas de engenharia de requisitos do CMMI; • Uma comparação entre as práticas de engenharia de requisitos dos projetos de uma empresa com as práticas específicas de engenharia de requisitos do CMMI, levando em consideração a presença das práticas, utilidade e adequação. Durante o desenvolvimento desse trabalho foram identificadas cinco hipóteses que estruturaram e direcionaram a presente pesquisa, relacionando as práticas específicas de engenharia de requisitos exigidas pelo CMMI quanto à presença, utilidade e adequação dessas práticas no ambiente da empresa. Presença das práticas: Foi verificado que nem todas as práticas específicas da engenharia de requisitos exigida pelo CMMI estão presentes nos projetos da empresa. Utilidade das práticas: Foi verificado que todas as práticas específicas da engenharia de requisitos exigida pelo CMMI foram consideradas úteis, mesmo aquelas que não são usadas nos projetos.

92

Adequação das práticas: Foi verificado que todas as práticas específicas da engenharia de requisitos exigida pelo CMMI não estão adequadas quanto ao seu detalhamento e precisam ser melhoradas O presente trabalho forneceu uma alternativa para se obter uma caracterização no processo de engenharia de requisitos, que pode servir para ser usado em estudos e análises direcionadas para melhorias no processo, utilizando engenharia de software experimental.

4.1 TRABALHOS FUTUROS Existem várias 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 não apenas em projetos de integração; 3. Aplicar esse experimento utilizando outros modelos teóricos, como o MPS.BR; 4. Aplicar esse experimento nas outras áreas de conhecimento da engenharia de software, modificando o questionário; 5. Ampliar o experimento para servir de apoio para as empresas que desejam se certificar no CMMI.

93

REFERÊNCIAS
BARROS, M. O.; WERNER, C. M. L.; TRAVASSOS, G. H. Um Estudo Experimental sobre a Utilização de Modelagem e Simulação no Apoio à Gerência de Projetos de Software Anais do XVI Simpósio Brasileiro de Engenharia de Software, Florianópolis, 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). Disponível 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 Elicitação 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 edição, International Thomson Computer Press, 1996. FLEMING, J. C. Implementing Software Engineering Practices in Small Industry with a Focus on Requirements Elicitation. Dissertação (Mestrado em Ciência da Computacão). 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 protótipo de ferramenta para a elicitação 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ª Edição. São 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ª Edição. São 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, Disponível em: http://www2.computer.org/portal/web/swebok/htmlformat. Acessado em: 19/05/2009. TRAVASSOS, G. H. Introdução à Engenharia de Software Experimental. Relatório Técnico – 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.