GQM – GOAL – QUESTION – METRIC

Figura 5 – Paradigma GQM [BAS94]

1. Nível Conceitual (Goal / Objetivo): um objetivo é definido para um objeto, com um

propósito específico, com respeito a um certo modelo de qualidade, a partir de um dado

ponto de vista relativo ao ambiente. Podem ser objetos de medida:

• Produtos: quaisquer documentos e produtos que são gerados durante o ciclo de

vida do sistema: especificações, projetos, programas, etc.

• Processos: atividades relacionadas ao desenvolvimento de software normalmente,

associadas ao consumo de tempo: fase de especificação, de projetos, de teste, etc.

• Recursos: itens consumidos no processo para gerar os produtos: pessoal,

equipamentos, softwares, espaço físico, etc.

2. Nível operacional (Question / Questão): um conjunto de questões é utilizado para

definir como será feita a avaliação e como será atingido um objetivo específico. O objeto

de medição (produto, processo ou recurso) é caracterizado por meio de questões que

levam em consideração o modelo de qualidade e o ponto de vista definido no objetivo.

3. Nível quantitativo (Metric / Métrica): representa os dados que serão medidos. Um

conjunto de dados é associado às questões formuladas a fim de que sejam traduzidas

quantitativamente. Esses dados podem ser objetivos ou subjetivos.

• Objetivos: se dependerem apenas do objeto que está sendo medido e não do ponto

de vista em que são tomados. Por exemplo, horas de pessoal gastas em

determinada tarefa, tamanho de um programa, etc.

• Subjetivos: se dependerem, além do próprio objeto que está sendo medido, do

ponto de vista em que será analisada a medida. Por exemplo, facilidade de leitura

de um texto, nível de satisfação do usuário, etc.

Capítulo 4 - GQM – Goal – Question – Metric 37

Assim, um modelo GQM é uma estrutura hierárquica que inicia com a definição de

um objetivo (goal), especificando o propósito da medição, os objetos e aspectos desses

objetos que serão avaliados, e o ponto de vista em que as medidas serão analisadas. O

objetivo é refinado em diversas questões (question). Cada questão é, por sua vez, delineada

nas métricas (metric) [BAS94].

Uma vez definidas as questões, é necessário, para cada questão, definir o que precisa

ser medido para respondê-las. Um objetivo é definido tão bem quanto as questões que ele gera

e os modelos nos quais essas questões são baseadas. Uma vez que esses modelos são de difícil

definição, na maioria das vezes, eles ficam implícitos nas questões. Porém, o quanto mais

formal, explícitos e completos forem os modelos, mais eficazes serão as questões e a

definição dos objetivos. Cada questão gera um conjunto de métricas, e, novamente, as

questões somente poderão ser respondidas com relação às métricas utilizadas, com respostas

tão completas quanto às métricas permitirem [BRI96].

Através do GQM, pode-se chegar a um conjunto ótimo de métricas: o menor número

possível de métricas, com maior poder de resposta e que estejam, efetivamente, relacionadas

aos objetivos. Uma mesma questão pode ser utilizada para definir vários objetivos, e as

métricas podem ser utilizadas para responder mais de uma questão. As questões e métricas

podem ser reutilizadas dentro um plano GQM ou mesmo entre diferentes programas de

medição [BAS94].

4.1 F

GQM

A aplicação do GQM consiste em quatro fases [SOL99], conforme ilustração na

Figura 6:

1. Fase de Planejamento, que envolve a seleção do que será mensurado e o

planejamento do projeto de medição.

2. Fase de Definição, onde os objetivos, questões e métricas são definidos e

documentados.

3. Fase de Coleta de Dados, onde é realizada a coleta de dados para atender as

métricas definidas.

4. Fase de Interpretação, na qual os dados coletados são analisados para responder

às questões e as respostas são usadas para verificar se os objetivos estabelecidos

foram alcançados.

Capítulo 4 - GQM – Goal – Question – Metric 38

Figura 6 – Fases do GQM [SOL99]

O GQM ajuda, ainda, a garantir a adequação, a consistência e a completude do plano

de medição. A administração da complexidade do programa de medição também é apoiada

pelo GQM, permitindo uma discussão estruturada sobre medição e diminuindo a resistência

da equipe de desenvolvimento, através de sua contínua participação no processo de medição

[BRI96].

4.2 C

C

Este capítulo apresentou o paradigma GQM, adotado, neste trabalho, para apoiar a

adaptação das métricas, que tem como objetivo auxiliar a decidir como as medições devem

ser feitas e como devem ser utilizadas. Um modelo GQM inicia com a definição de um

objetivo (goal), especificando o propósito da medição; os objetos e os aspectos desses objetos

que serão avaliados; e o ponto de vista em que as medidas serão analisadas. O objetivo é

refinado em diversas questões (question) e cada questão é delineada nas métricas.

39

5. A

A

Q

Este capítulo tem como principal objetivo apresentar os principais

trabalhos relacionados à qualidade dos requisitos utilizados no contexto

desta pesquisa.

Atualmente, alguns trabalhos vêm sendo desenvolvidos pela comunidade de

engenharia de software para apoiar a qualidade de requisitos de software. Esses trabalhos

abordam, de diferentes maneiras, a avaliação da qualidade de requisitos e aplicam algumas

técnicas que auxiliam nessa avaliação.

Como o principal interesse desta pesquisa está relacionado à qualidade dos

requisitos, neste capítulo serão descritos os trabalhos propostos por [BEL05], [FAB01] e

[WIL97], os quais serviram como referência para este trabalho.

5.1 A

B

F

[BEL05]

O trabalho desenvolvido por [BEL05], apresenta uma técnica de leitura que apóia a

construção de casos de uso e a análise de documentos de requisitos. Essa técnica é composta

de duas técnicas de leitura: AGRT (Actor Goal Reading Technique) e UCRT (Use Case

Reading Technique) cujos propósitos são, respectivamente, determinar os atores do sistema e

seus objetivos e, determinar o Modelo de Caso de Uso. Os passos dessas técnicas dão suporte

à construção de Modelos de Casos de Uso e também incorporam uma revisão do Documento

de Requisitos.

[BEL05] também definiu alguns campos necessários no SRS para especificar casos de

uso: Introdução, Funções do Produto, Requisitos Funcionais e Atributos são suficientes para

extrair as informações necessárias para gerar os casos de uso.

A idéia principal do trabalho é, a partir do SRS, construir o Modelo de Casos de Uso e

também incorporar uma revisão do Documento de Requisitos.