Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às...

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

ii


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

iv

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


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***

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 INTRODUÇÃO ............................................................................................. 1

1.1 MOTIVAÇÃO ................................................................................................ 5 1.1.1 MOTIVAÇÃO DE MERCADO ...................................................................... 5 1.1.2 MOTIVAÇÃO TÉCNICA ............................................................................... 6

1.2 PROBLEMA ................................................................................................. 6 1.2.1 OBJETIVO GERAL ...................................................................................... 6 1.2.2 OBJETIVOS ESPECÍFICOS ........................................................................ 7

1.3 JUSTIFICATIVA ........................................................................................... 7

1.4 CONTRIBUIÇÕES ....................................................................................... 8

1.5 ESTRUTURA DA DISSERTAÇÃO ............................................................... 9

2 REVISÃO BIBLIOGRÁFICA ...................................................................... 10

2.1 ENGENHARIA DE REQUISITOS .............................................................. 10 2.1.1 REQUISITOS DE SOFTWARE .................................................................. 13 2.1.2 PROCESSO DE ENGENHARIA DE REQUISTOS .................................... 16 2.1.3 ENGENHARIA DE REQUISTOS NO CMMI ............................................... 24

2.2 ENGENHARIA DE SOFTWARE EXPERIMENTAL .................................... 38 2.2.1 MEDIÇÃO .................................................................................................. 41 2.2.2 VALIDADE ................................................................................................. 43 2.2.3 TIPOS DE EXPERIMENTOS ..................................................................... 44 2.2.4 PROCESSO ............................................................................................... 45

3 SOLUÇÃO PROPOSTA ............................................................................ 50

3.1 A EMPRESA .............................................................................................. 50

3.2 DEFINIÇÃO DOS OBJETIVOS .................................................................. 50 3.2.1 OBJETIVO GLOBAL: ................................................................................. 50 3.2.2 OBJETIVO DA MEDIÇÃO: ......................................................................... 50 3.2.3 OBJETIVO DO ESTUDO: .......................................................................... 51 3.2.4 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 OPERAÇÃO ............................................................................................... 59 3.4.1 MATERIAL INFORMATIVO DAS PRÁTICAS ESPECÍFICAS DO

CMMI ......................................................................................................... 59

6

3.4.2 QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES .............................. 68 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 CONCLUSÕES .......................................................................................... 88 3.6.1 CARACTERIZAÇÃO .................................................................................. 88 3.6.2 PONTOS FORTES .................................................................................... 88 3.6.3 PONTOS DE MELHORIA .......................................................................... 89

4 CONSIDERAÇÕES FINAIS ....................................................................... 91

4.1 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 Significado

CMMI Capability Maturity Model Integration

FDD Feature Driven Development

GQM Goal Question Metric

QAI Quality Assurance Institute

QFD Quality function deployment

QIP Quality Improvement Paradigm

RAD Rapid Application development

RD Requirements Development

REQM Requirements Management

TDD Test Driven Development

UML Unified Modeling Language

XP 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 Encontrado na própria fase de análise de requisitos

$5 Encontrado na fase de projeto do sistema

$10 Encontrado na fase de codificação

$20 Encontrado na fase de testes unitários

$200 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 Descrição

1 – Inicial Processo imprevisível pobremente controlado e reativo

2 – Gerenciado Gerenciado Quantitativamente: Processo caracterizado para

o projeto e muitas vezes reativo

3 – Definido Processo caracterizado para a organização e proativo

4 – Gerenciado

qualitativamente

Processo medido e controlado

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 Obter um entendimento dos requisitos.

PE2 Obter comprometimento com requisitos.

PE3 Gerenciar mudanças de requisitos.

PE4 Manter rastreabilidade bidirecional de requisitos.

PE5 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


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


PE01 Coletar as necessidades dos stakeholders.

PE02 Elicitar as necessidades.

PE03 Desenvolver os Requisitos dos clientes.

Objetivo Específico (OE): Desenvolver requisitos do produto


32

PE04 Estabelecer os requisitos dos produtos e seus componentes.

PE05 Alocar os requisitos dos componentes dos produtos.

PE06 Identificar os requisitos de interfaces.



PE07 Estabelecer conceitos operacionais e cenários.

PE08 Estabelecer uma definição das funcionalidades requeridas.

PE09 Analisar os requisitos.

PE10 Analisar os requisitos para avaliação.

PE11 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 e interfaces dos

stakeholders em requisitos do cliente documentados;

2. Definir restrições de verificação e validação.

• 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 Survey Estudo de Caso Experimento

O controle da execução Nenhum Nenhum Tem

O controle da medição Nenhum Tem Tem

O controle da investigação Baixo Médio Alto

Facilidade da repetição Alta Baixa Alta

Custo Baixo Médio 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.


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:


pelo CMMI que precisam ser mais detalhadas para atender melhor as

necessidades da empresa.


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


que fazem parte dos projetos de integração da empresa e que não estejam

trazendo ganhos para a empresa?


CMMI que fazem parte dos projetos de integração da empresa e que não são

consideradas relevantes.


que fazem parte dos projetos de integração e que a empresa considera que esteja

trazendo ganhos para ela?


CMMI que fazem parte dos projetos de integração da empresa e que são

consideradas relevantes.


que não fazem parte dos projetos de integração e que a empresa gostaria de ter?


CMMI não fazem parte dos projetos de integração da empresa e que ela gostaria de

ter.


que fazem parte dos projetos de integração e que a empresa que não estão

adequadas quanto ao seu uso?


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.


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


exigidas pelo CMMI que a empresa não acha útil.


54

Pau - práticas específicas da engenharia de requisitos exigidas pelo CMMI e que a

empresa considera util.

H3: Pa – (Pa Ω Pau) ≠ 0


exigidas pelo CMMI utilizadas na empresa que são consideradas adequadas.


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) Utilidade da Prática (U)

Adequação do nível de detalhamento de uso da Prática (A)

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.

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

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º P U A Descrição da prática Questões

1 0 0 0 não é usada, não é útil, a modificação não é necessária.

Q1,Q2

2 0 0 1 não é usada, não é útil, a modificação é necessária.

Q1,Q2

3 0 1 0 não é usada, é útil, a modificação não é necessária.

Q1,Q4

4 0 1 1 não é usada, é útil, a modificação é necessária.

Q1,Q4

5 1 0 0 É usada, não é útil, a modificação não é necessária.

Q3, Q2

6 1 0 1 É usada, não é útil, a modificação é necessária.

Q3, Q2

7 1 1 0 É usada, é útil, a modificação não é necessária.

Q3

8 1 1 1 É usada, é útil, a modificação é necessária.

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


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


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


PE01 Coletar as necessidades dos stakeholders.



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:



PE02 Elicitar as necessidades.



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:



PE03 Desenvolver os Requisitos dos clientes.

Essa 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.



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.



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. 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.

1. O detalhamento deve ser aumentado. 2. O detalhamento não precisa ser modificado. 3. O detalhamento deve ser diminuído.

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 3 4 1 2 3 1 2 3 1.1 Entendimento do

significado dos requisitos

Existe um entendimento do significado dos requisitos com os fornecedores de requisitos.

70

1.2 Identificação dos fornecedores de requisitos

É estabelecido critérios para identificar esses fornecedores.

1.3 Obtenção do aceite Existe critérios objetivos para receber o aceite de requisitos dos fornecedores.

1.4 Análise dos requisitos.

Os requisitos são analisados para garantir que estes satisfaçam os critérios estabelecidos.

01 Obtenção do Entendimento dos Requisitos

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.

PE 02 - Obtenção do Comprometimento dos Requisitos

1 2 3 4 1 2 3 1 2 3 2.1 Comprometimento

dos participantes Existe o comprometimento dos participantes do projeto com os requisitos acordados.

2.2 Registro do Comprometimento

É Negociado e registrado os compromissos.

2.3 Avaliar Impactos Os impactos dos requisitos nos compromissos existentes são avaliados.

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 4 1 2 3 1 2 3 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.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.

03 Gerenciar mudanças de requisitos

Considerando as respostas (3.1, 3.2, 3.3 e 3.4) Sua opinião relacionada à prática de Gerenciar mudanças de requisitos.

PE 04 – Manter a Rastreabilidade Bidirecional dos Requisitos

1 2 3 4 1 2 3 1 2 3 4.1 Identificação da

necessidade È possível identificar de quem é a necessidade que gerou o requisito.

4.2 Identificação da existência

È possível identificar por que o requisitos existe.

4.3 Requisitos relacionados

È possível identificar quais os requisitos relacionados.

4.4 Relação com outras informações

É possível identificar como os requisitos se relacionam a outras informações como design, implementações e outros documentos.

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 3 4 1 2 3 1 2 3 5.1 Analise dos requisitos A análise dos

requisitos são feitas de forma criteriosa.

5.2 Ações corretivas Existe uma tomada de ações corretivas para evitar a inconsistências.

5.3 Descobrimento das fontes

Existe algum trabalho realizado para descobrir as fontes e as causas das inconsistências.

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 3 4 1 2 3 1 2 3 06 Coleta das

necessidades Existe a coleta das necessidades dos stakeholders.

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.

09 Estabelecer os requisitos dos produtos e seus componentes

Os requisitos são detalhados nas funcionalidades, características, tecnologia e os custos desses atendimentos são levantados.

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.

11 Identificar os requisitos de interfaces

Existe o detalhamento das interfaces de entrada e saída.

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.

13 Definição das funcionalidades requeridas

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

14 Analisar os requisitos É realizado o relatório de incompletudes e inconsistências dos requisitos e existe uma definição de priorização dos 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.


N° Prática Descrição

01 Obtenção do

Entendimento dos

Requisitos

Sua opinião relacionada à prática de obtenção do

entendimento dos requisitos.

Presença:

4 - Parcialmente presente

Utilidade:

4 - Útil e usada

Adequação:

4 - Aumentar detalhamento

02 Obtenção do

Comprometimento

dos Requisitos

Sua opinião relacionada à prática de Obtenção do

Comprometimento dos Requisitos.

Presença:

4 - Ausente gostaria de usar.

Utilidade:

4 - Útil e não usada

Adequação:


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

75

de requisitos mudanças de requisitos.

Presença:

4 - Parcialmente presente.

Utilidade:

4 - Útil e usada

Adequação:




04 Manter a

Rastreabilidade

Bidirecional dos

Requisitos.

Sua opinião relacionada à prática de Manter a

Rastreabilidade Bidirecional dos Requisitos.

Presença:


Utilidade:

4 - Útil e usada

Adequação:


05 Identificar

Inconsistências Entre

Artefatos do Projeto

e Requisitos

Sua opinião relacionada à prática de Identificar

Inconsistências Entre Artefatos do Projeto e

Requisitos.

Presença:


Utilidade:

4 - Útil e usada

Adequação:


Área de processo - Desenvolvimento de Requisitos


06 Coleta das

necessidades

Existe a coleta das necessidades dos stakeholders.

Presença:


1 - Presente

Utilidade:

4 - Útil e usada

Adequação:


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

Utilidade:


Adequação:


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.

Presença:


3 - Usada

Utilidade:

4 - Útil e usada

Adequação:




09 Estabelecer os

requisitos dos

produtos e seus

componentes

Existe a coleta das necessidades dos stakeholders.

Presença:


Utilidade:


Adequação:


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.

Presença:


Utilidade:


Adequação:


77

3 – Parcialmente presente 3 - Útil e usada

11 Identificar os

requisitos de

interfaces

Existe o detalhamento das interfaces de entrada e

saída.

Presença:

4 - Usada

Utilidade:

4 - Útil e usada

Adequação:


1 – não precisa modificar



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.

Presença:


Utilidade:


Adequação:


13 Definição das

funcionalidades

requeridas

Existe uma definição das funcionalidades requeridas

em forma de caso de uso e diagramas de atividades.

Presença:


1 – Parcialmente presente

Utilidade:


1 - Útil e usada

Adequação:


14 Analisar os

requisitos

É realizado o relatório de incompletudes e

inconsistências dos requisitos e existe uma

definição de priorização dos requisitos.

Presença:


Utilidade:


Adequação:


78



15 Analisar os requisitos

para avaliação

Os riscos das necessidades dos usuários são

avaliados

Presença:


1 – Parcialmente presente

Utilidade:


1 - Útil e usada

Adequação:


16 Validar os requisitos É utilizado algum tipo de relatório de validação

dos requisitos.

Presença:


Utilidade:


Adequação:


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

Participante

Formação Profissão Tempo de

experiência

Cargos

ocupados na

Empresa

1 1 2 15 1 ; 2

2 2 2 9 1; 2

3 3 2 6 2

4 3 3 10 2; 3

Tabela 15: Legenda de auxílio da tabela 11

Formação Profissão Cargos ocupados

1 Técnico 1 Programador 1 Programador

2 Graduado 2 Analista de Sistemas 2 Analista de Sistemas

3 Pós-Graduado 3 Coordenador 3 Coordenador

Figura 5: Distribuição dos dados dos profissionais entrevistados

0

2

4

6

8

10

12

14

16

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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Mediana 3 2 3 3 3 3 2 4 2 3 4 2 2 2 2 2

Moda 3 2 3 3 3 3 2 4 2 3 4 2 2 2 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Mediana 3 2 3 3 3 3 3 3 3 3 3 2 2 2 2 2

Moda 3 2 3 3 3 3 3 3 3 3 3 2 2 2 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Mediana 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Moda 1 1 1 1 1 1 1 1 1 1 1 1 1 1 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 P U A Características

08 Desenvolver os

Requisitos dos

clientes

4:0 4:0 0:4 • As práticas são usadas

plenamente pelos projetos;

• As práticas são consideradas

úteis e já foram aplicadas

pelos profissionais

entrevistados da empresa;

• O detalhamento deve ser

aumentado, provavelmente

porque os profissionais acham

que ainda podem ser

melhorados, mas é estranho

serem usados plenamente e

mesmo assim precisarem ser

mais detalhados.

11 Identificar os

requisitos de

interfaces

4:0 4:0 1:3

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)


01 Obter um

entendimento dos

requisitos

4:0 4:0 1:3 • As práticas que são

parcialmente usadas

plenamente pelos projetos;


úteis e já foram aplicadas

pelos profissionais

entrevistados da empresa;

• O detalhamento do uso das

práticas deve ser aumentado.

03 Gerenciar mudanças

de requisitos

4:0 4:0 0:4

04 Manter

rastreabilidade

bidirecional de

requisitos

4:0 4:0 0:4

05 Identificar

inconsistências entre

artefatos do projeto e

requisitos

4:0 4:0 0:4

06 Coleta das

necessidades

4:0 4:0 0:4

10 Alocação dos

requisitos dos

componentes dos

produtos

3:1 4:0 0:4

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)


02 Obter comprometimento com requisitos

0:4 4:0 0:4 • As práticas não são usadas

pelos projetos;


úteis e os profissionais

entrevistados da empresa

gostariam de usar;

• O detalhamento do uso das

práticas deve ser aumentado.

07 Elicitar as

necessidades

0:4 4:0 0:4

09 Estabelecer os

requisitos dos

produtos e seus

componentes

1:3 4:0 0:4

12 Conceitos operacionais e cenários

0:4 4:0 0:4

13 Definição das funcionalidades requeridas

1:3 4:0 0:4

14 Analisar os requisitos 0:4 4:0 0:4

15 Analisar os requisitos para avaliação

1:3 4:0 0:4

16 Validar os requisitos 0:4 4:0 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° Prática P U A 01 Obter um entendimento dos requisitos 1 1 1 02 Obter comprometimento com requisitos 0 1 1 03 Gerenciar mudanças de requisitos 1 1 1 04 Manter rastreabilidade bidirecional de requisitos 1 1 1 05 Identificar inconsistências entre artefatos do projeto

e requisitos 1 1 1

06 Coleta das necessidades 1 1 1 07 Elicitar as necessidades 0 1 1 08 Desenvolver os Requisitos dos clientes 1 1 1 09 Estabelecer os requisitos dos produtos e seus

componentes 0 1 1

10 Alocação dos requisitos dos componentes dos produtos

1 1 1

11 Identificar os requisitos de interfaces 1 1 1 12 Conceitos operacionais e cenários 0 1 1 13 Definição das funcionalidades requeridas 0 1 1 14 Analisar os requisitos 0 1 1 15 Analisar os requisitos para avaliação 0 1 1 16 Validar os requisitos 0 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° Prática P U A 02 Obter comprometimento com requisitos 0 1 1 07 Elicitar as necessidades 0 1 1 09 Estabelecer os requisitos dos produtos e seus componentes 0 1 1 12 Conceitos operacionais e cenários 0 1 1

87

13 Definição das funcionalidades requeridas 0 1 1 14 Analisar os requisitos 0 1 1 15 Analisar os requisitos para avaliação 0 1 1 16 Validar os requisitos 0 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: Prentice-

Hall, 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: Addison-

Wesley, 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. 1087-

1109, 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.

Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às...

Documents

Transcript of Um experimento na engenharia de requisitos para caracterização do processo e sua adequação às...