You are on page 1of 108

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

CRISTIANO TAVARES SILVA

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

RECIFE

2010

CRISTIANO TAVARES SILVA

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

Dissertação apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Mestre em Engenharia de Software.

Orientação: Prof. Dr. Vinicius Cardoso Garcia

RECIFE

2010

ii

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

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

CRISTIANO TAVARES SILVA

Dissertação apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Mestre em Engenharia de Software.

Data de aprovação:

/

/ 2010.

Banca examinadora:

Prof.(a).Dr.(a) ***

***instituição***

Prof.(a).Dr.(a) ***

***instituição***

Prof.(a).Dr.(a)

***instituição***

iv

2

AGRADECIMENTOS

Primeiramente, agradeço a Deus por tudo que tenho conquistado, pela família que possuo, por todos os obstáculos que Ele ajuda a remover e por toda a força que Ele me dá para ultrapassar os limites do meu ser.

Agradeço em especial a minha amada esposa Viviane, sem ela, esse sonho e muitos outros não teriam se concretizado, sem a sua eterna compreensão e incentivo, eu não teria conseguido.

À minha querida filha Maria Clara, que muitas vezes acreditou mais em mim

do que eu mesmo. Sempre compreendeu a minha ausência em muitos momentos durante a realização deste trabalho e que, com o seu sorriso e seu abraço, renovavam as minhas forças.

Aos meus pais, Geraldo e Leni pelo carinho, amor e apoio que sempre me deram.

A meu orientador, o professor Vinicius Cardoso Garcia, pelo seu incentivo e principalmente por sua confiança em mim, por todo o conhecimento transmitido, suas críticas e sugestões e pela disponibilidade sempre apresentada.

À minha querida e estimada sogra, a professora Helen Khoury, que muito me

incentivou a me inscrever no curso e na realização deste trabalho.

3

RESUMO

A crescente globalização dos negócios e o ambiente competitivo estimulam

as empresas a investirem na melhoria contínua dos seus processos internos. Diante deste cenário, os investimentos em Tecnologia da Informação são inevitáveis e, com isso, o surgimento de soluções teóricas de melhorias de processo tem sido grande. Mesmo assim, adotar um processo novo a partir de um modelo teórico não significa que irá funcionar no ambiente organizacional, levando em consideração estrutura, equipe e mentalidade da empresa.

Dentre os processos que envolvem o desenvolvimento de sistemas, existe a engenharia de requisitos. Como a existência desse processo é mais forte no início do ciclo de vida de um sistema, sua importância é grande, pois um entendimento errado nessa fase pode gerar um sistema em desacordo com as necessidades a que ele foi projetado. Existem modelos teóricos da engenharia de requisitos que sugerem as melhores práticas. Um dos modelos mais difundidos no Brasil é o Modelo CMMI, que é inclusive um órgão certificador de empresas de tecnologia da informação. Mesmo assim, não existe a garantia que os modelos teóricos, como o CMMI, estão adequados cem por cento ao ambiente de todas as empresas. Por isso aperfeiçoar os processos das empresas de desenvolvimento para moldar-los ao ambiente operacional da empresa é muito importante.

Atualmente a engenharia de software experimental, que é estudo empírico sobre a própria engenharia de software, pode gerar para as empresas a oportunidade de caracterizar, avaliar, prever, controlar e sugerir melhorias em seus processos, tornando-os mais eficientes e gerando valor agregado.

É por isso que neste trabalho foi desenvolvido um modelo que utilizando a

engenharia de software experimental possibilita as empresas caracterizar, verificar

os pontos fortes e de melhorias do processo de engenharia de requisitos, realizando uma comparação com as práticas específicas da engenharia de requisitos do CMMI.

PALAVRAS-CHAVES: Engenharia de Software Experimental. Engenharia de requisitos. CMMI.

4

ABSTRACT

The increasing globalization of business and competitive environment encourage businesses to invest in continuous improvement of its internal processes. In this scenario, investments in information technology are inevitable and with it the emergence of theoretical solutions process improvements have been great. Even so, adopting a new process from a theoretical model does not mean it will work in the organizational environment, taking into account structure, staff and mentality of the company.

Among the processes involving the development of systems, there is the requirements engineering. Since the existence of this process is stronger at the beginning of the life cycle of a system, its importance is great because a misunderstanding that stage can generate a system at odds with the needs to which it was designed. There are theoretical models of requirements engineering that suggest best practices. One of the most widespread in Brazil is the CMMI model, which is also a certifying body for information technology companies. Still, there is no guarantee that the theoretical models such as CMMI, are suitable environment to one hundred percent of all businesses. Therefore improve the processes of development companies to shape them to the company's operating environment is very important.

Currently, experimental software engineering, which is empirical study on their own software engineering, can generate for companies the opportunity to characterize, assess, predict, monitor and suggest improvements in their processes, making them more efficient and generating added value.

That is why this work developed a model using the experimental software engineering enables companies to characterize, verify the strengths and improvements to the process engineering requirements, performing a comparison with the specific practices of requirements engineering of CMMI.

Keywords: Experimental Software Engineering. Requirements Engineering. CMMI.

5

SUMÁRIO

1

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

3.4.1

OPERAÇÃO

MATERIAL INFORMATIVO DAS PRÁTICAS ESPECÍFICAS DO

59

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

3.5.2

VALIDAÇÃO DOS RESULTADOS

ESTATÍSTICA DESCRITIVA

80

80

3.5.3

ANÁLISE DOS RESULTADOS

85

ANÁLISE

3.5.3.1 QUANTITATIVA

85

ANÁLISE

3.5.3.2 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

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,

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

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

55

TABELA 8: PRÁTICAS ESPECÍFICAS DE OBJETIVO ESPECÍFICO DE GERENCIAMENTO DE REQUISITOS E SUAS

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

69

TABELA 13: RESULTADO DAS ENTREVISTAS

74

TABELA 14: PERFIL DOS

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

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

86

ABREVIATURAS

Sigla

Significado

CMMI

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

FDD

GQM

QAI

QFD

QIP

RAD

RD

REQM

TDD

UML

XP

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

Software;

uma

visão

consistente

do

mundo

da

Engenharia

de

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.

mostra uma visão do SWEBOK e suas áreas de conhecimento. Figura 1: Visão do SWEBOK e

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

Processo medido e controlado

qualitativamente

5

– Otimização

Foco na melhoria do processo

26

O nível um também conhecido como o nível inicial é caracterizado como um processo de desenvolvimento de software “ad hoc” e ocasionalmente pode ser caótico. Nesse nível poucos processos estão definidos na empresa e o sucesso depede dos esforços individuais.

No nível dois, os processos básicos de gerenciamento estão estabelecidos para se obter os controles do custo, cronogramas e funcionalidade. A disciplina necessária dos processos permite repetir o sucesso em outros projetos com aplicações similares.

No nível três, o processo de software para as atividades de gerenciamento e de engenharia é documentado, padronizado e integrado em um processo padrão de software para a organização.

Já no nível quatro, medições detalhadas do processo de software e da qualidade do produto são coletadas. Tanto o processo de software quanto o produto de software são quantitativamente entendidos e controlados.

Por fim, no nível cinco, que é o nível de maturidade otimizado, o processo de melhoria continua e é feito através de feedback quantitativo dos processos e das aplicações de novas idéias e tecnologias.

Cada nível de maturidade do CMMI possui áreas de processo formadas por objetivos específicos e genéricos que, por sua vez, também possuem suas práticas específicas e genéricas como é mostrado na Figura 2.

e genéricos que, por sua vez, também possuem suas práticas específicas e genéricas como é mostrado

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 como produtos de trabalho:

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

requisitos.

o

histórico

de

mudanças

ajuda

a

rastrear

a

volatilidade

dos

4. Avaliar o impacto das mudanças de requisitos do ponto de vista dos

stackeholders relevantes.

30

Prática específica 4 - manter rastreabilidade bidirecional dos requisitos:

Esta prática é importante, porque a partir de uma rastreabilidade bidirecional bem feita é possível rastrear os requisitos até sua origem e retornar a sua condição atual, por exemplo, indicando qual será o impacto das mudanças neles e como será refletida no projeto. Para essa prática são utilizados como produtos de trabalho:

1. Matriz de rastreabilidade de requisitos.

2. Sistema de rastreamento de requisitos.

Já as subpráticas usadas são as seguintes:

1. Manter a rastreabilidade dos requisitos para assegurar que a origem do

menor nível de requisito (derivado) esteja documentada.

2. Manter a rastreabilidade de um requisito com seus requisitos derivados e

com sua alocação a funções, interfaces, pessoas, processos e produtos de trabalho.

3. Gerar a matriz de rastreabilidade de requisitos.

Prática específica 5 - identificar inconsistências entre o trabalho do projeto e os requisitos:

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

31

1. documentação de inconsistências incluindo fontes, condições e justificativas

e ações corretivas.

Já as subpráticas usadas são as seguintes:

1. Revisar os planos de projeto, atividades e produtos de trabalho visando à

consistência com os requisitos e com as mudanças neles realizadas.

2. Identificar a origem das inconsistências e fundamento lógico.

3. Identificar mudanças que necessitam ser feitas nos planos e produtos de

trabalho resultantes das mudanças na baseline de requisitos.

4. Iniciar as ações corretivas.

Além da área de processo de gerenciamento existe também a área de processo de desenvolvimento de Requisitos, que como citado anteriormente, é exigida pelo nível três do CMMI. Essa área de processo tem por objetivo desenvolver os requisitos do cliente. A Tabela 3 abaixo apresenta a área de processo e as suas práticas específicas.

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

Área de processo (AP): Desenvolvimento de Requisitos – RD

Objetivo Específico (OE): Desenvolver Requisitos do Cliente

Práticas específicas (PE)

PE01

Coletar as necessidades dos stakeholders.

PE02

Elicitar as necessidades.

PE03

Desenvolver os Requisitos dos clientes.

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

Práticas específicas (PE)

32

PE04

Estabelecer os requisitos dos produtos e seus componentes.

PE05

Alocar os requisitos dos componentes dos produtos.

PE06

Identificar os requisitos de interfaces.

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

Práticas específicas (PE)

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

Requerida:

3.2

-

Estabelecer

uma

Definição

da

Funcionalidade

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:

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

40 Figura 3: Relacionamento entre as variáveis (TRAVASSOS, 2002). No objetivo do experimento verifica-se o relacionamento

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

47 Figura 4: Esquema de uma fábrica de experiência (TRAVASSOS , 2002). SOLINGEN e BERGHOUT (1999)

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

SOLINGEN e BERGHOUT (1999) descrevem outra abordagem que oferece o processo da melhoria com o modelo da medição baseada em camadas a GQM (Goal Question Metric). Segundo BASILI et al. (1994a), O Goal Question Metric é um mecanismos para definir objetivos mensuráveis. O GQM é uma abordagem que uma organização pode usar para medir seus processos, de uma maneira poderosa, que funciona da seguinte maneira: primeiramente é feita a especificação dos objetivos dos projetos, depois esses objetivos são traçados e finalmente disponibiliza-se um framework para interpretação dos dados com os seus respectivos estados relacionados aos objetivos. Para realizar o processo é utilizada uma abordagem top-down, onde os objetivos são estabelecidos, depois as questões são formuladas, e por fim, as métricas são elaboradas. Já para realizar a interpretação dos resultados é utilizada a abordagem bottom-up, através do uso da medição para receber os dados experimentais, depois formulando as respostas para as questões baseada nos dados experimentais, e por fim, agrupando as respostas para demonstrar o grau do de sucesso dos objetivos estabelecidos. Essa abordagem foi originalmente definida para avaliar defeitos de um conjunto de projetos no Goddard Space Flight Center da NASA. Para entender melhor o que representa cada etapa abaixo um resumo do que representa cada uma nesta abordagem:

48

Goal é uma meta definida para um objetivo por razões variadas, com vários modelos de qualidade com vários pontos de vista relativos a ambientes em particular. Objetivos de medição são os produtos, processos e recursos.

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

Metric possui uma quantidade de dados que são associados com cada questão (Question) para ser respondida de uma maneira quantitativa, podendo ser objetivas e subjetivas.

Para TRAVASSOS (2002) os principais objetivos definidos pelo GQM são compreender, controlar, e melhorar. O foco desses objetivos são quatro fatores: o custo, o risco, o tempo, e a qualidade. A junção dos objetivos com os fatores os possibilita aos investigadores o aumento da compreensão do produto e do processo de software, o produto e o processo se tornam controlados, e, finalmente, as atividades de melhoria do produto e do processo de software estão sendo definidas.

A abordagem GQM é composta de quatro fases: A fase do planejamento, quando o projeto da medição está selecionado, definido, caracterizado, e planejado, resultando em o plano do projeto; A fase da definição, quando o programa da medição conceitualmente preparado, ou seja, os objetivos, as questões, as métricas e as hipóteses são estabelecidas; a fase da coleta de dados, quando a coleta de dados experimentais é efetivamente feita resultando em conjunto de dados prontos para a interpretação; e a fase da interpretação, quando os dados são processados a respeito das métricas, questões, e objetivos definidos (TRAVASSOS, 2002).

Segundo WOHLIN et al. (2000) a realização de um estudo experimental geralmente pode ser dividida em cinco fases: a definição, o planejamento, a

49

execução, a análise e o empacotamento do estudo. BARROS et al. (1999) sintetizou as cinco fases do estudo experimental da seguinte forma:

Na definição do experimento é realizado um resumo dos objetivos, seu foco de qualidade e os objetos que vão ser analisados.

A fase de planejamento envolve a descrição do perfil dos participantes, dos instrumentos, do processo de execução é realizada uma avaliação criteriosa dos problemas que podem ser encontrados ao longo da execução.

A execução é a realização do estudo experimental pelos participantes, utilizando os instrumentos e o processo definidos na fase de planejamento.

Na fase da análise é realizada a organização dos resultados obtidos pelos participantes durante a execução e a realização de inferências sobre estes resultados.

O empacotamento é a organização e armazenamento dos documentos construídos nas etapas anteriores. Esse armazenamento é feito com o intuito de facilitar a repetição do estudo experimental no futuro.

Em relação ao empacotamento TRAVASSOS (2002) afirma que uma das características mais importantes de um experimento é a necessidade da sua repetição. Porque é com a repetição que os pesquisadores obtêm o conhecimento adicional sobre os conceitos estudados, e recebem os resultados que podem ser iguais ou diferentes dos resultados do experimento original. Para que esse controle seja feito de uma forma eficaz, o empacotamento deve possuir um padrão para que seja possível o armazenamento correto deles, pois esses dados experimentais podem servir como base para a criação das bibliotecas de experimentação.

50

3 SOLUÇÃO PROPOSTA

Nesta seção, será descrito o experimento que caracterizou como a engenharia de requisitos está sendo utilizada nos projetos de uma empresa de Tecnologia da Informação. Também será apresentada a adequação do processo de engenharia de requisitos da empresa em relação às práticas específicas de engenharia de requisitos do CMMI. E, por fim, será relatada a opinião dos profissionais que foram entrevistados nesse experimento quanto à utilidade e a necessidade de aumentar ou diminuir o nível de detalhamento do uso dessas práticas, bem como os resultados e mapeamento dos pontos fortes e pontos que podem ser melhorados.

3.1 A EMPRESA

A empresa na qual o experimento foi realizado, é uma empresa de tecnologia da informação que tem a sua Matriz situada no Recife, com filiais em vários estados do Brasil. Ela possui negócios internacionais e um faturamento anual superior a 10 milhões. A empresa não possui certificação CMMI, mas tem a intenção de se certificar, por acreditar ser importante para o futuro da empresa.

3.2

DEFINIÇÃO DOS OBJETIVOS

3.2.1

OBJETIVO GLOBAL:

Caracterizar o uso do processo de engenharia de requisitos em uma empresa de Tecnologia da informação, correlacionando o seu uso com as práticas específicas de engenharia de requisitos exigidas pelo CMMI, apontando os pontos fortes e pontos de melhoria no seu processo no nível de utilidade e de adequação do uso.

3.2.2 OBJETIVO DA MEDIÇÃO:

Tendo como base a Engenharia de requisitos, caracterizar:

51

1. Quais são as práticas de engenharia de requisitos utilizadas pelos projetos

da empresa:

Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que são usadas totalmente ou parcialmente pelos projetos de integração da empresa e são consideradas úteis.

Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que não são usadas pelos projetos de integração da empresa.

2. Quais são as práticas específicas de engenharia de requisitos exigidas pelo

CMMI que são consideradas inadequadas ou úteis pela empresa:

Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI que precisam ser mais detalhadas para atender melhor as necessidades da empresa.

Quais são as práticas específicas da engenharia de requisitos exigidas pelo CMMI são que são consideradas úteis para da empresa.

3.2.3 OBJETIVO DO ESTUDO:

Analisar as práticas específicas oferecidas pelo CMMI à empresa, a fim de caracterizá-la com respeito às vantagens oferecidas pelas práticas específicas da engenharia de requisitos exigida pelo CMMI do ponto de vista dos analistas e desenvolvedores da empresa no contexto dos projetos.

3.2.4 QUESTÕES

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

52

Q2: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que não estejam trazendo ganhos para a empresa? Métrica2: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que não são consideradas relevantes.

Q3: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração e que a empresa considera que esteja trazendo ganhos para ela? Métrica3: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que são consideradas relevantes.

Q4: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que não fazem parte dos projetos de integração e que a empresa gostaria de ter? Métrica4: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI não fazem parte dos projetos de integração da empresa e que ela gostaria de ter.

Q5: Existem práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração e que a empresa que não estão adequadas quanto ao seu uso? Métrica5: A lista das práticas específicas da engenharia de requisitos exigidas pelo CMMI que fazem parte dos projetos de integração da empresa e que precisam ser melhoradas.

53

3.3

PLANEJAMENTO

3.3.1

DEFINIÇÃO DAS HIPÓTESES

Para realizar o estudo experimental é preciso levantar as hipóteses nula e alternativa. A hipótese nula representa a afirmação que o estudo experimental tem como objetivo negar, e as hipóteses alternativas têm por objetivo rejeitar a hipótese nula. As hipóteses levantadas nesse estudo estão descritas abaixo.

Hipótese nula (H0): As práticas específicas da engenharia de requisitos exigidas pelo CMMI são similares às práticas de engenharia de requisitos utilizadas nos projetos de integração da empresa. Pa – Práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pc – Práticas de engenharia de requisitos utilizadas2 nos projetos de integração. H0: Pc – (Pa Ω Pc) = 0 Hipótese alternativa (H1) As práticas específicas da engenharia de requisitos exigidas pelo CMMI são diferentes às práticas utilizadas nos projetos de integração da empresa. Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI; Pc – Práticas de engenharia de requisitos utilizadas nos projetos de integração. H1: : Pc – (Pa Ω Pc) ≠ 0

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

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

54

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

empresa considera util.

H3: Pa – (Pa Ω Pau) ≠ 0

Hipótese alternativa (H4): As práticas específicas da engenharia de requisitos

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

Pa – práticas específicas da engenharia de requisitos exigidas pelo CMMI;

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

empresa considera inadequada.

H2: Pa – (Pa Ω Pac) ≠ 0

3.3.2 DESCRIÇÃO DA INSTRUMENTAÇÃO

Para cada prática específica da engenharia de requisitos exigida pelo CMMI

foram escolhidos os itens conforme Tabela 6.

Tabela 6: Opções de resposta aplicadas no questionário

Presença da Prática (P)

Utilidade da Prática (U)

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

1.

Não é utilizada nos

1. Não é útil.

1.

O detalhamento deve

projetos e não acredito ser relevante

2. Provavelmente é útil,

ser aumentado.

mas ainda não apliquei.

2.

O detalhamento não

2.

Não é utilizada, mas

precisa ser modificado.

gostaria de usar.

3.

É útil e já apliquei em

diferentes projetos.

3.

O detalhamento deve

3.

utilizada,

ser diminuído.

parcialmente.

4.

usada.

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.

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

Práticas específicas (PE)

PE1

Obter um entendimento dos requisitos.

A fim de evitar problemas futuros, são designadas as fontes oficiais que serão responsáveis por disponibilizar e receber os requisitos. A prática específica do entendimento dos requisitos trata do estabelecimento do uso de um mecanismo que obtém, com o cliente, o significado do requisito. Ele é composto por atividades que captam os requisitos para assegurar que sua compreensão foi atingida. Essa prática também estabelece os critérios que evitam o crescimento indistinto dos mesmos. Para essa prática são utilizados como produtos de trabalho:

1. Lista de critérios para a apropriada distinção dos fornecedores dos requisitos.

2. Critérios para avaliação e aceitação dos requisitos.

3. Resultados das análises em relação aos critérios.

60

4.

Um conjunto de requisitos acordados.

PE2

Obter comprometimento com requisitos.

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

1.

Analisar os impactos dos requisitos.

2.

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

PE3

Gerenciar mudanças de requisitos.

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

Status de requisitos.

Banco de dados de requisitos.

Banco de dados de decisões de requisitos.

Subpráticas:

 

1.

Documentar todos os requisitos e mudanças de requisitos do projeto.

61

2. Manter um histórico de mudanças de requisitos com os fundamentos lógicos das mudanças.

3. Manter o histórico de mudanças ajuda a rastrear a volatilidade dos requisitos.

4. Avaliar o impacto das mudanças de requisitos do ponto de vista dos stackeholders relevantes.

5. Tornar disponíveis ao projeto os dados de requisitos e de mudanças.

 

PE4

Manter rastreabilidade bidirecional de requisitos.

 

Esta prática é importante porque a partir de uma rastreabilidade bidirecional bem feita é possível rastrear os requisitos até sua origem e retornar a sua condição atual, por exemplo, indicando qual será o impacto das mudanças neles e como será refletida no projeto. Para essa prática são utilizados como produtos de trabalho:

1. Matriz de rastreabilidade de requisitos.

 

2. Sistema de rastreamento de requisitos.

Subpráticas:

 

1.

Manter a rastreabilidade dos requisitos para assegurar que a origem do

menor nível de requisito (derivado) esteja documentada.

 

2.

Manter a rastreabilidade de um requisito com seus requisitos derivados e

com sua alocação a funções, interfaces, pessoas, processos e produtos de

trabalho.

 

3.

Gerar a matriz de rastreabilidade de requisitos.

 

PE5

Identificar inconsistências entre artefatos do projeto e requisitos.

 

Essa

prática

é

utilizada

para

descobrir

as

inconsistências

entre

os

62

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

1. Documentação de inconsistências incluindo fontes, condições e justificativas e ações corretivas.

Subpráticas:

1. Revisar os planos de projeto, atividades e produtos de trabalho visando à

consistência com os requisitos e com as mudanças neles realizadas.

2. Identificar a origem das inconsistências e fundamento lógico.

3. Identificar mudanças que necessitam ser feitas nos planos e produtos de

trabalho resultantes das mudanças na baseline de requisitos.

4. Iniciar as ações corretivas.

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

Área de processo (AP): Desenvolvimento de Requisitos – RD

Objetivo Específico (OE): Desenvolver Requisitos do Cliente

Práticas específicas (PE)

PE01

Coletar as necessidades dos stakeholders.

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

63

Subpráticas:

 

1.

Envolver os stakeholders relevantes usando métodos para levantamento de necessidades, expectativas, restrições e interfaces externas.

PE02

Elicitar as necessidades.

 

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

Subpráticas:

 

1.

Envolver os stakeholders relevantes usando métodos para levantamento de necessidades, expectativas, restrições e interfaces externas.

PE03

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.

 

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

 

Práticas específicas (PE)

 

64

PE04

Estabelecer os requisitos dos produtos e seus componentes.

Essa prática específica estabelece e mantém os requisitos do produto e dos componentes de produto, que são baseados nos requisitos do cliente.

Subpráticas:

 

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

2. Derivar os requisitos que resultam das decisões de design.

PE05

Alocar os requisitos dos componentes dos produtos.

Essa prática específica propõe alocar os requisitos de cada componente do produto.

Subpráticas:

 

1. Alocar requisitos a funções;

2. Alocar requisitos a componentes de produto;

3. Alocar restrições de design a componentes de produto.

PE06

Identificar os requisitos de interfaces.

Essa prática identifica os requisitos de interface. As Interfaces entre funções ou entre objetos são identificadas. As interfaces funcionais podem orientar o desenvolvimento de soluções alternativas descritas na área de processo.

Subpráticas:

 

1.

Identificar as interfaces externas e internas do produto. À medida que o design evolui, a arquitetura do produto será alterada pelos processos da solução técnica, criando novas interfaces entre os componentes de

65

 

produto e os componentes externos do produto;

2.

Desenvolver os requisitos para as interfaces identificadas. Os requisitos de interfaces são definidos em termos de aspectos tais como origem, destino, estímulo, características de dados para software e hardware.

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

Práticas específicas (PE)

PE07

Estabelecer conceitos operacionais e cenários.

Essa prática estabelece e mantém conceitos operacionais e cenários associados. Um cenário é tipicamente uma seqüência de eventos que poderia ocorrer no uso do produto, que são usados para tornar explícita alguma necessidade dos stakeholders.

Subpráticas:

 

1. Elaborar conceitos operacionais e cenários que incluam funcionalidade, desempenho, manutenção, suporte e descarte quando apropriado;

2. Definir o ambiente no qual o produto ou o componente de produto irá operar, incluindo fronteiras e restrições;

3. Revisar os conceitos e cenários operacionais para descobrir e refinar requisitos;

4. Desenvolver um conceito operacional detalhado, quando o produto e os componentes de produto são selecionados, para satisfazer às necessidades operacionais, de manutenção, de suporte e de descarte.

PE08

Estabelecer uma definição das funcionalidades requeridas.

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

66

Subpráticas:

1. Analisar e quantificar as funcionalidades requeridas pelos usuários finais;

2. Analisar os requisitos para identificar as partições lógicas ou funcionais;

3. Particionar os requisitos em grupos, com base nos critérios estabelecidos,para facilitar ou dar foco à análise de requisitos;

4. Considerar a seqüência das funções de tempo-crítico, no início e durante o desenvolvimento dos componentes de produto;

5. Alocar os requisitos do cliente às partições funcionais, objetos, pessoas ou a elementos de suporte para dar suporte à síntese de soluções;

6. Alocar requisitos funcionais e de desempenho às funções e subfunções.

PE09

Analisar os requisitos.

Essa prática prega que os requisitos sejam analisados para determinar se eles são necessários e suficientes para atender aos objetivos dos níveis mais altos da hierarquia do produto. Então, os requisitos analisados fornecem uma base de requisitos mais detalhada e precisa para os níveis mais baixos da hierarquia do produto.

Subpráticas:

1. Analisar as necessidades, expectativas, restrições e interfaces externas dos stakeholders para remover conflitos e organizá-los em assuntos relacionados;

2. Analisar os requisitos para determinar se eles satisfazem aos objetivos dos requisitos dos níveis mais altos;

3. Analisar os requisitos para garantir que eles sejam completos, economicamente viáveis, implementáveis e verificáveis. Enquanto o design determina a viabilidade de uma solução particular;

4. Identificar os requisitos-chave que têm uma forte influência nos custos, cronograma, funcionalidades, riscos ou desempenho;

5. Identificar medidas de desempenho técnico que serão acompanhados durante o esforço de desenvolvimento;

67

6.

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

PE10

Analisar os requisitos para avaliação.

 

Essa prática específica trata da análise das necessidades e restrições dos

stakeholders,

verificando

as

questões

relacionadas

a

custos,

cronograma,

desempenho, funcionalidade, componentes reusáveis e manutenibilidade ou risco.

Subpráticas:

1.

Usar modelos comprovados, simulações e prototipagem para analisar o equilíbrio de necessidades e restrições dos stakeholders;

4.

Realizar uma avaliação de risco nos requisitos e na arquitetura funcional;

5.

Examinar os conceitos ciclo de vida do produto para identificar os impactos dos requisitos nos riscos.

PE11

Validar os requisitos.

 

Essa prática específica prega que a validação dos requisitos tem que ser realizada precocemente no esforço de desenvolvimento com os usuários finais para obter confiança de que os requisitos são capazes de guiar um desenvolvimento que resulte em validação final bem sucedida.

Subpráticas:

1. Analisar os requisitos para determinar o risco do produto resultante não funcionar apropriadamente em seu ambiente de uso pretendido;

2. Explorar a adequação e completitude dos requisitos por meio do desenvolvimento de representações do produto; como protótipos, simulações, modelos, cenários e roteiros; e de obtenção de feedbacks dos stakeholders relevantes a respeito dessas representações;

3. Avaliar o design à medida que ele amadurece no contexto do ambiente de validação dos requisitos para identificar problemas de validação e expor

68

necessidades e requisitos do cliente não declarados.

3.4.2 QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES

Tabela 10: Questionário do perfil dos participantes

Responda:

FORMAÇÃO.

PROFISSÃO.

TEMPO DE EXPERIENCIA PROFISSIONAL.

CARGOS OCUPADOS NA EMPRESA.

69

3.4.3 QUESTIONÁRIO DAS PRÁTICAS

Relacionando-se apenas com os projetos de integração da empresa que você

participou em relação ao processo de engenharia de requisitos, por favor, avalie e

marque as colunas correspondentes segundo as escalas da Tabela 11 considerando a

presença, utilidade e adequação das práticas de engenharia de requisitos listadas

no questionário da Tabela 12.

Tabela 11: Escalas para respostas.

Presença da Prática (P)

Utilidade da Prática (U)

 

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

   

1.

Não é usada nos

1. Não é útil.

 

1.

O detalhamento deve

 

projetos e não acredito

 

ser aumentado.

 

ser relevante

2. Provavelmente é útil,

   

mas ainda não apliquei.

 

2.

O detalhamento não

 
 

precisa ser modificado.

2.

Não é usada, mas

3.

É útil e já apliquei em

   

gostaria de usar.

diferentes projetos.

 

3.

O detalhamento deve

 
 

ser diminuído.

 

3.

Usada, parcialmente.

 

4.

usada.

 

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

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

                   

requisitos.

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

O

histórico de

               

mudanças

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

possível identificar quais os requisitos relacionados.

È

               

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)
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
Existem métodos para
a
elicitação das
necessidades
necessidades,
expectativas,
restrições dos
requisitos junto aos
stakeholders.

73

08 Desenvolver os O desenvolvimento Requisitos dos clientes dos requisitos são acompanhados para identificar se
08
Desenvolver os
O
desenvolvimento
Requisitos dos
clientes
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
Os requisitos são
detalhados nas
funcionalidades,
produtos e seus
componentes
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
Existe o detalhamento
requisitos de
das interfaces de
entrada e saída.
interfaces
12
Conceitos
operacionais e
cenários
As seqüências de
eventos possíveis com
os fluxos descritos em
casos de uso
Além da preocupação
com a instalação,
manutenção e suporte
do produto.
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.

 

Área de processo - Gerenciamento de Requisitos

 
 

Prática

 

Descrição

 

01

Obtenção do

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

 

Entendimento dos

entendimento dos requisitos.

Requisitos

Presença:

 

Utilidade:

Adequação:

4

- Parcialmente presente

4

- Útil e usada

4

- Aumentar detalhamento

 

02

Obtenção do

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

 

Comprometimento

Comprometimento dos Requisitos.

dos Requisitos

Presença:

 

Utilidade:

Adequação:

4

- Ausente gostaria de usar.

4

- Útil e não usada

4

- Aumentar detalhamento

 

03

Gerenciar mudanças

Sua opinião relacionada à prática de Gerenciar

75

 

de requisitos

mudanças de requisitos.

 

Presença:

 

Utilidade:

Adequação:

 

4

- Parcialmente presente.

4

- Útil e usada

4

- Aumentar detalhamento

 

Área de processo - Gerenciamento de Requisitos

 

Prática

 

Descrição

04

Manter a Rastreabilidade Bidirecional dos Requisitos.

Sua opinião relacionada à prática de Manter a Rastreabilidade Bidirecional dos Requisitos.

Presença:

 

Utilidade:

Adequação:

 

4

- Parcialmente presente

4

- Útil e usada

4

- Aumentar detalhamento

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:

Adequação:

4

- Parcialmente presente

4

- Útil e usada

4

- Aumentar detalhamento

 

Área de processo - Desenvolvimento de Requisitos

 

Prática

 

Descrição

06

Coleta das

Existe a coleta das necessidades dos stakeholders.

necessidades

Presença:

 

Utilidade:

Adequação:

3 - Parcialmente presente

4

- Útil e usada

4

- Aumentar detalhamento

1 - Presente

   

76

 

07

Elicitar as

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

 

necessidades

Presença:

 

Utilidade:

Adequação:

4

- Ausente gostaria de usar

4

- Útil e não usada

4

- Aumentar detalhamento

 

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:

 

Utilidade:

Adequação:

1

- Parcialmente presente

4