Sistema de apoio para a geração de planos de medição de software

(1)

Universidade Federal Fluminense

Instituto de Computa¸

c˜

ao

Bacharelado em Sistemas de Informa¸

c˜

ao

LORENA TEIXEIRA DA COSTA

SISTEMA DE APOIO PARA A GERA ¸

C ˜

AO DE

PLANOS DE MEDI ¸

C ˜

AO DE SOFTWARE

Niter´

oi-RJ

2017

(2)

LORENA TEIXEIRA DA COSTA

SISTEMA DE APOIO PARA A GERA ¸C ˜AO DE PLANOS DE MEDI ¸C ˜AO DE SOFTWARE

Trabalho de conclusão de curso apresentado ao curso de Bacharelado em Sistemas de In-forma¸cão, como requisito parcial para con-clusão do curso.

Orientador: Prof. Dr. Marcos Kalinowski.

Niter´oi-RJ 2017

(3)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

C837 Costa, Lorena Teixeira da

Sistema de apoio para a geração de planos de medição de software / Lorena Teixeira da Costa. – Niterói, RJ : [s.n.], 2017.

68 f.

Trabalho (Conclusão de Curso) – Departamento de Sistemas de Informação, Universidade Federal Fluminense, 2017.

Orientador: Marcos Kalinowski.

1. Medição de software. 2. Sistema de apoio à decisão. 3. Métrica de software. I. Título.

CDD 005.1

(4)

LORENA TEIXEIRA DA COSTA

SISTEMA DE APOIO PARA A GERA ¸C ˜AO DE PLANOS DE MEDI ¸C ˜AO DE SOFTWARE

Trabalho de conclusão de curso apresentado ao curso de Bacharelado em Sistemas de In-forma¸cão, como requisito parcial para con-clusão do curso.

Aprovada em 11 de Janeiro de 2017.

Marcos Kalinowski (Orientador), D.Sc. UFF

Andr´ea Magalh˜aes Magdaleno, D.Sc. UFF

Daniel de Oliveira, D.Sc. UFF

Niter´oi-RJ 2017

(5)

iv

Dedico este trabalho aos meus pais Vera L´ u-cia e Paulo Roberto, por n˜ao medirem esfor-¸

cos para que eu pudesse concluir a minha for-ma¸c˜ao acadˆemica.

(6)

Agradecimentos

Agrade¸co a Deus por tudo.

A toda à minha fam´ılia, em especial aos meus pais Vera Lúcia e Paulo Roberto pela dedica¸cão incondicional.

Ao professor Marcos Kalinowski pela orienta¸c˜ao, incentivo, ensinamentos, dedica-¸c˜ao e confian¸ca.

Aos amigos que contribu´ıram direta ou indiretamente, em especial ao Daniel J´unior pelo apoio de sempre.

Aos professores Andréa Magalhães e Daniel de Oliveira pela presen¸ca na banca examinadora e pelos ensinamentos passados durante a gradua¸cão.

(7)

vi

Resumo

Um plano de medi¸cão feito de forma correta é de suma importância para o aux´ılio das tomadas de decisões. O objetivo desse trabalho é a cria¸cão de um sistema de apoio para que as empresas possam gerar planos de medi¸cão de software seguindo a metodologia GQM. De acordo com esta metodologia, durante a confeçcão do plano, é necessário que sejam definidos objetivos de medi¸cão para então refinar estes objetivos em questões e posteriormente elencar métricas que ajudem a responder a essas questões. O sistema de apoio foi constru´ıdo visando fornecer ao usuário um passo a passo de como montar esse plano de maneira adequada, podendo utilizar conhecimento informado anteriormente por especialistas da área. Para avaliar o sistema, o mesmo foi utilizado para gerar um plano de medi¸cão equivalente a outro plano real que havia sido definido seguindo a metodologia GQM. O apoio mostrou-se adequado para auxiliar organiza¸cões na cria¸cão de planos de medi¸cão de software.

Palavras-chave: Medi¸cão. Software. GQM. Objetivos de Medi¸cão. Questões. Métricas. Plano.

(8)

Abstract

A correctly formulated plan of measurement is of paramount importance in assis-ting decision-making. The objective of this work is the creation of a support system so that companies can generate software measurement plans following the GQM methodo-logy. According to this methodology, during the preparation of the plan, it is necessary to define measurement objectives to refine these objectives in questions and later to list metrics that help to answer these questions. The support system was designed to provide the user with a step-by-step on how to assemble this plan in an appropriate manner, and may use knowledge previously informed by experts in the area. To evaluate the system, it was used to generate a measurement plan equivalent to another real plan that had been defined following the GQM methodology. The support has shown itself adequate to assist organizations in the creation of software measurement plans.

Keywords: Measurement. Programs. GQM. Measurement objectives. Questions. Metrics. Plan

(9)

Sum´

ario

Resumo vi

Abstract vii

Lista de Figuras xii

Lista de Tabelas xiii

Lista de Abreviaturas e Siglas xiv

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao . . . 2

1.2 Objetivo . . . 3

1.3 Organiza¸c˜ao da Monografia . . . 3

2 Medi¸c˜ao de Software 4 2.1 Conceitos da Medi¸c˜ao de Software . . . 4

2.2 Medi¸c˜ao nos Modelos de Maturidade de Software . . . 6

2.2.1 MPS-SW . . . 6

2.2.2 CMMI-Dev . . . 8

2.3 Abordagens para Medi¸c˜ao . . . 8

2.3.1 M´etodo GQM (Goal Question Metric) . . . 9

2.3.2 M´etodo GQ(I)M (Goal Question (Indicator ) Measure) . . . 11

2.3.3 M´etodo GQM+Strategies . . . 12

2.3.4 M´etodo PSM (Practical Software Measuremen) . . . 13

2.4 Defini¸cão dos Procedimentos de Coleta, Armazenamento e Análise dos Dados 14 2.5 Considera¸cões Finais . . . 15

(10)

3 Especifica¸cão do Sistema de Apoio a Gera¸cão de Planos de Medi¸cão de

Software 16

3.1 Escopo do Software . . . 16

3.2 Especifica¸c˜ao Funcional . . . 17

3.2.1 Modelo Conceitual de Classes do Dom´ınio . . . 17

3.2.2 Requisitos N˜ao-Funcionais . . . 18

3.2.3 Requisitos Funcionais . . . 18

3.2.4 Descri¸c˜ao dos Atores . . . 18

3.3 Diagrama de Caso de Uso . . . 19

3.4 Descri¸c˜ao dos Casos de Uso . . . 21

3.4.1 UC01 – Manter Empresas . . . 21

3.4.2 UC02 – Manter Usu´arios . . . 22

3.4.3 UC03 – Manter Plano . . . 24

3.4.4 UC04 - Manter Objetivo de Medi¸c˜ao . . . 25

3.4.5 UC05 - Selecionar Objetivos de Medi¸cão, Questões e Métricas pr´ e-cadastradas . . . 26

3.4.6 UC06 – Manter Quest˜oes e M´etricas . . . 28

3.4.7 UC07 – Manter os atributos das m´etricas . . . 30

3.5 Decis˜oes de Projeto . . . 32

3.6 Considera¸c˜oes Finais . . . 32

4 O sistema de apoio para a gera¸c˜ao de planos de medi¸c˜ao de software 33 4.1 Administrador . . . 33

4.1.1 Manter Empresas . . . 33

4.1.2 Manter Usu´arios . . . 34

4.1.3 Pr´e-cadastros . . . 35

4.2 Usu´ario . . . 35

4.2.1 Objetivos de Medi¸cão, Questões e Métricas . . . 35

4.2.2 Selecionar dados pr´e-cadastrados . . . 36

4.3 Prova de Conceito: Criando um Plano de Medi¸c˜ao Real . . . 37

4.3.1 Objetivos de Medi¸c˜ao . . . 37

4.3.2 Quest˜oes e M´etricas . . . 37

(11)

x

˜

4.4 Trabalhos Relacionados . . . 39

4.5 Considera¸coes Finais . . . 40

5 Considera¸cões Finais 41 ¸ 5.1 Contribui¸cões . . . 41 5.2 Limitacões . . . 42 5.3 Trabalhos Futuros . . . 42 Referências Bibliográficas 44 Anexo A 48 48 48 `Ìi`ÊÜÌÊÌiÊìÊÛiÀÃÊvÊ vÝÊ*ÀÊ*Ê `ÌÀÊ /ÊÀiÛiÊÌÃÊÌVi]ÊÛÃÌ\Ê ÜÜÜ°Vi°VÉÕV°Ì

(12)

Lista de Figuras

2.1 Estrutura hier´arquica GQM adaptada de (BASILI et al., 1994) . . . 10

2.2 GQM+Strategies (ROCHA et al., 2012) adaptado de (BASILI et al., 2007) 12 2.3 Modelo de Informa¸c˜ao de Medi¸c˜ao (ISO/IEC, 2007). . . 14

2.4 Evolu¸cão da Necessidade de Informa¸cão até o Plano de Medi¸cão (Mc-GARRY et al., 2002). . . 14

3.1 Modelo Conceitual de Classes do Dom´ınio . . . 17

3.2 Diagrama de Caso de Uso . . . 20

3.3 Tela principal de Empresas . . . 21

3.4 Tela de Cadastro de Empresa . . . 22

3.5 Tela principal de Usu´arios . . . 23

3.6 Tela de Cadastro de Usu´ario . . . 23

3.7 Tela inicial do Plano . . . 25

3.8 Tela de cadastro de objetivo . . . 26

3.9 Tela de Objetivos de medi¸c˜ao pr´e-cadastrados . . . 27

3.10 Tela do Plano . . . 27

3.11 Tela de cadastro de quest˜ao e m´etrica . . . 29

3.12 Tela de plano em andamento . . . 30

3.13 Tela de cadastro dos atributos da m´etrica . . . 31

4.1 P´agina principal de Empresas . . . 34

4.2 P´agina principal de Usu´arios . . . 34

4.3 P´agina de dados Pr´e-Cadastros . . . 35

4.4 Página de Objetivos de Medi¸cão, Questões, Métricas e Atributos das Métricas 36 4.5 Página de Pré-Cadastros . . . 36

4.6 P´agina de Objetivos de Medi¸c˜ao . . . 37

(13)

xii 4.7 Página de Questões e Métricas . . . 38 4.8 Página de gera¸cão do Plano contendo os objetivos, questões, métricas e

descri¸cão das métricas . . . 38 4.9 Página de gera¸cão do Plano contendo os atributos das métricas . . . 39

(14)

Lista de Tabelas

2.1 Objetivos e Práticas Espec´ıficas da Área de Processo Medi¸cão e Análise no

CMMI-DEV (SEI, 2010) adaptada de (ROCHA et al., 2012). . . 8

3.1 Requisitos N˜ao-Funcionais . . . 18

3.2 Requisitos Funcionais . . . 18

3.3 Descri¸c˜ao dos Atores . . . 19

5.1 Tamanho dos Projetos de Software . . . 49

5.2 Or¸camento . . . 49

5.3 Prazo . . . 50

5.4 Produtividade . . . 50

5.5 Qualidade . . . 51

5.6 Descri¸c˜ao das M´etricas . . . 52

5.7 Descri¸c˜ao das M´etricas . . . 53

(15)

Lista de Abreviaturas e Siglas

CMMI : Capability Maturity Model; CMMI-DEV : CMMI for Development; GQM : Goal Question Metric;

GQ(I)M : Goal Question (Indicator) Measure;

GQM+Strategies : Goal Question Metric +Strategies; ISO/IEC: International Organization for Standardization; MPS.BR : Melhoria do Processo de Software Brasileiro; MPS-SW : MPS para Software;

PSM : Practical Software Measurement; SEI : Software Engineering Institute;

(16)

Cap´ıtulo 1

Introdu¸

c˜

ao

Medidas são essenciais para a obten¸cão de conhecimento que seja capaz de gerar avalia¸cões pertinentes a diversas áreas, dentre as quais está presente o desenvolvimento de software.

A medi¸cão de software adquire relevância gradativamente à medida que cresce a demanda por sistemas cada vez mais complexos e de qualidade, dado que a mesma possibilita que haja uma maior precisão no entendimento e no controle dos projetos, produtos e processos (ROCHA et al., 2012). Assim, a medi¸cão ajuda a levar a uma melhor compreensão do projeto como um todo, auxiliando nas tomadas de decisões e no aumento da qualidade de processos e produtos.

Por meio da análise de medidas é poss´ıvel obter conhecimento a respeito da qua-lidade de um produto, do quão estável e capaz é um processo e ter conhecimento sobre diferentes estágios de um projeto (ROCHA et al., 2012). Ademais, é poss´ıvel saber sobre o tamanho dos projetos, questões referentes ao or¸camento, prazo, produtividade, número de defeitos, estimativas de esfor¸co planejado e realizado, número de falhas, retrabalho, dentre outras.

Além disto, com o registro das informa¸cões coletadas por meio das medi¸cões, pode-se obter um repositório de medi¸cões contendo uma base de dados histórica capaz de orientar nas tomadas de decisões (SOFTEX, 2016).

(17)

2

1.1 Motiva¸

c˜

ao

Apesar das medi¸cões serem de suma importância para o alcance do êxito nos pro-jetos de software, pesquisas indicam que a grande maioria das empresas têm dificuldade em montar um plano de medi¸cão adequado às suas necessidades (GOH et al., 1998; FEN-TON e NEIL, 1999; NIESSINK e VLIET, 2001; GOPAL et al., 2002; WANG e LI, 2005; KITCHENHAM et al., 2006; SARGUT e DEMIRORS, 2006; CURTIS et al., 2008; RACK-ZINSKI e CURTIS, 2008; BARCELLOS 2009a).

De acordo com Rocha et al. (2012), os motivos para esta dificuldade podem es-tar associados à falta de recursos humanos ou financeiros, ou até mesmo à carência de conhecimento sobre a importância das medi¸cões, fato que leva algumas empresas a medi-rem apenas para atingimedi-rem requisitos exigidos para a obten¸cão de determinados n´ıveis de maturidade em modelos como CMMI-DEV (SEI, 2010) ou MPS-SW (SOFTEX, 2011a).

A AMCHAM (Câmara Americana de Comércio) (AMCHAM, 2012) realizou em janeiro de 2012 uma pesquisa com 44 empresários, gestores e executivos da área de Tec-nologia da Informa¸cão, onde 73% dos envolvidos afirmaram que já faz parte da pol´ıtica de suas empresas a medi¸cão periódica e o uso de indicadores de desempenho em TI.

Os aspectos mais relevantes que essas empresas focam ao mensurar os resultados de TI são: melhoria de processos (80%); aumento dos lucros e impactos de processos de TI (55%); maturidade da área (18%); gestão de riscos (16%); e compara¸cão com n´ıveis de mercado (14%). Segundo a percep¸cão dos entrevistados, quantificar os resultados de TI fornece os seguintes resultados: direcionar melhor os investimentos na área (59%); corrigir falhas nos processos (55%); identificar pontos com potencial para redu¸cão de custos (43%); garantir maior visibilidade da área (36%); e justificar investimentos (34%).

No entanto, apenas 14% dos entrevistados se disseram totalmente satisfeitos com a forma como a medi¸cão é realizada. As principais dificuldades reveladas foram conseguir tangibilizar todos os benef´ıcios e retornos das a¸cões (41%); estabelecer indicadores que indiquem desempenho, governan¸ca e maturidade da área (30%); obter informa¸cões sobre o impacto de TI em outros setores da empresa (18%); e quantificar a eficiência dos processos e sistemas de tecnologia (14%).

No contexto do desenvolvimento de software, um plano de medi¸cão é essencial para que as medidas relevantes sejam coletadas, ajudando a gerar conhecimento que permita obter um controle efetivo e que auxilie em tomadas de decisões corretas.

(18)

Desta maneira, prover apoio para a elabora¸cão de um plano de medi¸cão pode se mostrar extremamente benéfico para as empresas.

1.2 Objetivo

O principal objetivo é especificar e prover apoio ferramental para orientar uma empresa a montar um plano de medi¸cão de software seguindo a abordagem GQM (Goal Question Metric) (BASILI et al., 1994; SOLINGEN e BERGHOUT, 1999) e fornecer apoio adicional através de conhecimento alimentado por especialistas.

O plano resultante deve capturar os objetivos de medi¸cão da organiza¸cão, as ques-tões relacionadas a esses objetivos e as métricas que sejam aptas a responder essas ques-tões.

Espera-se, desta forma, auxiliar as empresas na obten¸c˜ao efetiva dos benef´ıcios esperados por um programa de medi¸c˜ao de software.

1.3 Organiza¸

c˜

ao da Monografia

Nesse cap´ıtulo foram apresentadas a motiva¸cão, o contexto e os objetivos desse trabalho. A seguir serão descritos os próximos cap´ıtulos:

No Cap´ıtulo 2, é apresentada a fundamenta¸cão teórica a respeito de medi¸cão de software.

No Cap´ıtulo 3 são apresentadas a especifica¸cão funcional do sistema a ser desen-volvido e as decisões de projeto.

No Cap´ıtulo 4 são apresentados o sistema resultante e uma prova de conceito em que o sistema é utilizado para gerar um plano de medi¸cão real.

No Cap´ıtulo 5 são feitas as considera¸cões finais contendo as contribui¸cões, as limi-ta¸cões e os trabalhos futuros.

(19)

Cap´ıtulo 2

Medi¸

c˜

ao de Software

Medi¸cão de software é uma avalia¸cão quantitativa de qualquer aspecto dos proces-sos e produtos de software, que permite seu melhor entendimento, e com isso, auxilia o planejamento, controle e melhoria do que se produz e de como é produzido (BASS et al., 1999 apud ROCHA et al., 2012).

De acordo com DeMarco (1989, p. 3) a importância de se medir software pode ser resumida em uma frase, que diz: “Não se pode controlar o que não se pode medir”. Fenton e Pfleeger (1997) também refor¸cam a medi¸cão como uma qualidade essencial de uma boa gestão, pois “não se pode predizer o que não se pode medir”.

2.1 Conceitos da Medi¸

c˜

ao de Software

Por ser um tema relativamente recente, ainda não existe um consenso sobre concei-tos e terminologias. A defini¸cão de um vocabulário comum foi proposta por BARCELLOS (2009a), através de uma ontologia de Medi¸cão de Software cujos conceitos estão resumidos a seguir.

• Medida: É a quantifica¸cão de atributos de entidades. Divide-se entre medida base (ex.: prazo estimado para o projeto, prazo real do projeto) e medida derivada (ex.: aderência ao prazo do projeto, dada pela razão entre o prazo real do projeto e o prazo estimado para o projeto). A abordagem GQM se refere a este mesmo conceito como métrica.

• Elemento Mensur´avel: Propriedade de uma entidade que pode ser quantificada. Ex.: a medida prazo estimado para o projeto quantifica o elemento mensur´avel

(20)

tempo.

• Entidade Mensur´avel: Entidade que pode ser caracterizada pela quantifica¸c˜ao dos seus atributos. Ex.: a medida prazo estimado para o projeto quantifica o atri-buto tempo da entidade Projeto P.

• Unidade de Medida: Expressa uma medida. Ex.: a medida prazo estimado para o projeto pode ser expressa em horas. A medida aderˆencia ao prazo do projeto n˜ao possui unidade de medida.

• Escala: Indica os valores que podem ser atribu´ıdos a uma medida. Ex.: A medida prazo estimado para o projeto possui uma escala do tipo Absoluta que ´e composta pelos n´umeros reais positivos.

• Procedimento de Medi¸cão: Descreve como a coleta da medida pode ser feita. Ex.: A medida aderência ao prazo do projeto poderia ter como procedimento de medi¸cão: Aplicar a fórmula de cálculo de medida que determina a razão entre o prazo real do projeto e o prazo estimado para o projeto.

• Procedimento de Análise de Medi¸cão: Descreve como os dados coletados para a medida podem ser representados e analisados. Ex.: A medida aderência ao prazo do projeto poderia ter como procedimento de análise: Representar em histograma as taxas de aderência ao prazo dos projetos. Valores superiores a 1 indicam que o projeto levou mais tempo que o previsto, valores menores que 1 indicam que o projeto levou menos que o previsto e valores iguais a 1 indicam que o projeto levou exatamente o tempo que foi previsto. Analisar os valores medidos para os projetos e compará-los uns com os outros. Subagrupar os dados e representá-los em outros histogramas a fim de identificar e analisar: (i) as diferen¸cas das taxas de acordo com as caracter´ısticas dos projetos; (ii) as diferen¸cas das taxas de acordo com a fase em que o projeto se encontra.

• Defini¸cão Operacional de Medida: Descreve procedimentos sobre medi¸cão e an´ a-lise incluindo o papel dos responsáveis pela medi¸cão e pela análise e os momentos e periodicidade em que as mesmas devem ser feitas.

• Medi¸cão: A¸cão de medir, ou seja, de atribuir um valor a uma medida, execu-tando seu procedimento de medi¸cão. Ex.: medi¸cão do prazo previsto para o projeto obtendo-se o valor 500.

(21)

6 • Análise de Medi¸cão: Análise dos dados coletados para uma determinada medida. Ex.: análise da aderência ao prazo do projeto, concluindo-se que os projetos que envolveram o uso de nova tecnologia apresentaram uma aderência 10% menor aos prazos previstos do que a média das aderências dos projetos que não utilizaram novas tecnologias.

• Indicador: Medida utilizada para analisar o alcance a objetivos. Ex.: aderˆencia ao prazo do projeto poderia ser um indicador para o objetivo melhorar a aderˆencia dos projetos aos planos.

2.2 Medi¸

c˜

ao nos Modelos de Maturidade de

Soft-ware

Modelos de maturidade de software, como CMMI-DEV e MPS-SW, são estruturas conceituais que contêm processos bem definidos capazes de possibilitar que uma organi-za¸cão se desenvolva de maneira planejada.

Além da elabora¸cão da avalia¸cão do estágio atual de uma organiza¸cão e da sua in-ser¸cão em n´ıveis pré-definidos, modelos de maturidade também servem como guias capazes de orientar os passos necessários para que uma determinada organiza¸cão possa conduzir-se na busca por excelência.

A seguir s˜ao discutidas as suas caracter´ısticas e como a medi¸c˜ao de software se relaciona com cada um desses modelos.

2.2.1 MPS-SW

O programa MPS.BR (Melhoria do Processo de Software Brasileiro) é uma inicia-tiva coordenada pela SOFTEX. Foi criado em 2003 com o intuito de melhorar a qualidade do desenvolvimento de software de pequenas e médias empresas nacionais, visando ca-pacitar o software brasileiro para exporta¸cão, tornando-o competitivo para a gera¸cão de negócios no Brasil e no exterior (SANTOS et al., 2012).

Um dos resultados do programa foi a cria¸cão e dissemina¸cão de modelos de ma-turidade, incluindo o modelo de referência MPS-SW, que capacita as empresas em n´ıveis que contém boas práticas associadas. O seu objetivo é que, através da boa utiliza¸cão da

(22)

Engenharia de Software, possa se desenvolver software de melhor qualidade e com cus-tos e prazos mais próximos do estimado. Evidências nesta dire¸cão têm sido produzidas (TRAVASSOS e KALINOWSKI, 2014).

O MPS apresenta sete n´ıveis de maturidade que relacionam processos e suas capa-cidades, são eles: A (Em Otimiza¸cão), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado), onde o n´ıvel G é considerado como inicial e o A é o mais desenvolvido.

A partir do n´ıvel F, a implementa¸cão do processo de medi¸cão passa a ser obri-gatória. Neste n´ıvel, o processo de medi¸cão é apresentado no MPS-SW com o seguinte propósito e resultados esperados (SOFTEX, 2016).

Prop´osito:

O propósito do processo de Medi¸cão é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organiza¸cão e em seus projetos, de forma a apoiar os objetivos organizacionais.

Nesse sentido, o principal objetivo da medi¸cão é auxiliar as tomadas de decisões com sustenta¸cão nos objetivos organizacionais.

O processo de Medi¸cão tem interse¸cão com todos os outros processos do MR-MPS-SW, através do atributo de processo AP2.1 “a execu¸cão do processo é gerenciada”, que exige a medi¸cão dos diferentes processos do modelo, conforme o texto destacado deste atributo: “a execu¸cão do processo é monitorada em rela¸cão ao planejado e, quando necessário, ajustes são realizados”(SOFTEX, 2016).

Resultados esperados:

MED 1. Objetivos de medi¸cão são estabelecidos e mantidos a partir dos objeti-vos de negócio da organiza¸cão e das necessidades de informa¸cão de processos técnicos e gerenciais;

MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medi-¸c˜ao, ´e identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado;

MED 3. Os procedimentos para a coleta e o armazenamento de medidas s˜ao especificados;

MED 4. Os procedimentos para a análise das medidas são especificados; MED 5. Os dados requeridos são coletados e analisados;

(23)

8 MED 6. Os dados e os resultados das an´alises s˜ao armazenados;

MED 7. Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões.

2.2.2 CMMI-Dev

Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI (Capability Maturity Model ) é uma evolu¸cão do CMM composto por boas práticas (Genéricas ou Espec´ıficas), fundamentais para se alcan¸car à maturidade.

O modelo é composto por 5 n´ıveis de maturidade: 1 (Inicial), 2 (Gerenciado), 3 (Definido), 4 (Quantitativamente Gerenciado) e 5 (Em Otimiza¸cão), que visam avaliar o grau de maturidade que uma organiza¸cão possui em um dado momento. Além disto, possui o propósito de atuar como um guia para tornar melhor os processos da organiza¸cão. O modelo referente ao processo de desenvolvimento de produtos e servi¸cos é deno-minado CMMI for Development (CMMI-DEV). Neste modelo a medi¸cão de software está presente no n´ıvel de maturidade 2 (Gerenciado) em que se encontra a área de processos Medi¸cão e Análise, que tem como objetivo desenvolver e conservar a capacidade de me-di¸cão utilizada para dar apoio as necessidades de informa¸cões gerenciais. A Tabela 2.1 apresenta os objetivos e práticas da área de processos Medi¸cão e Análise do CMMI-DEV. Tabela 2.1: Objetivos e Práticas Espec´ıficas da Área de Processo Medi¸cão e Análise no CMMI-DEV (SEI, 2010) adaptada de (ROCHA et al., 2012).

Objetivo Espec´ıfico 1: Alinhar as ati-vidades de medi¸c˜ao e an´alise

Objetivo Espec´ıfico 2: Fornecer re-sultados das medi¸c˜oes

PE 1.1 - Estabelecer objetivos de medi¸c˜ao PE 2.1 - Coletar dados de medi¸c˜oes PE 1.2 - Especificar medidas PE 2.2 - Analisar dados

PE 1.3 - Especificar procedimentos de

co-leta dos dados e armazenamento PE 2.3 - Armazenar dados e resultados PE 1.4 - Especificar procedimentos de an´

a-lise PE 2.4 - Comunicar resultados

2.3 Abordagens para Medi¸

c˜

ao

Um bom planejamento é considerado como um elemento essencial para a elabora¸cão de um plano de medi¸cão que seja alinhado aos objetivos estratégicos da organiza¸cão, onde

(24)

através desse alinhamento possa ser poss´ıvel prover uma associa¸cão capaz de gerar os objetivos de medi¸cão.

Muitas vezes, o relacionamento entre os objetivos estratégicos e os objetivos de medi¸cão é superficial, insuficiente e não se tem a garantia de que as medidas identificadas atendam corretamente às necessidades de informa¸cão dos diferentes n´ıveis de gerência da organiza¸cão (ROCHA et al., 2012).

Logo, é necessário que as organiza¸cões tenham clareza sobre o que cada medida pode informar, tendo consciência da utilidade das medidas que coletam e analisam, ga-rantindo assim que as mesmas possam apoiar a tomada de decisão.

Nas abordagens fundamentadas na defini¸cão de medidas baseadas em objetivos, a primeira questão não deve ser “Qual medida deve ser usada?”, mas sim “O que é preciso saber ou aprender?”(SEMA 2010). É necessário partir do pressuposto de que para medir é preciso: (i) identificar objetivos de negócio ou uma questão chave a ser respondida; (ii) determinar as necessidades de informa¸cão necessárias para determinar se o objetivo foi atingido ou para responder a questão; (iii) quantificar as necessidades de informa¸cão sob a forma de medidas; e (iv) analisar as medidas para determinar se os objetivos foram alcan¸cados ou se a questão foi respondida de forma adequada (ALLEN e DAVIS, 2010).

Diante disso, existem dois métodos que apoiam o planejamento das medi¸cões, são eles: GQM (Goal-Question-Metric) (BASILI et al., 1994; SOLINGEN e BERGHOUT, 1999), com as varia¸cões GQ(I)M e GQM+Strategies, e o PSM (Practical Software Mea-surement ) (MCGARRY et al., 2002).

A seguir serão apresentados os dois métodos citados e suas respectivas varia¸cões, porém para o desenvolvimento desse trabalho foi utilizado apenas o método GQM, que possui uma estrutura simples e, de acordo com (ROCHA et al., 2012), é o mais usado pela indústria de software.

2.3.1 M´

etodo GQM (Goal Question Metric)

O GQM (BASILI et al., 1994; SOLINGEN e BERGHOUT, 1999) é um dos métodos mais utilizados para o aux´ılio da defini¸cão de medidas devido ao fato do seu uso ser considerado simples. Sua estrutura top-down permite a defini¸cão das medidas através das questões associadas aos objetivos de medi¸cão.

(25)

orga-10 niza¸cão precisa definir seus objetivos e os objetivos dos seus projetos para posteriormente fazer as associa¸cões com os dados que forem necessários.

A aplica¸cão do GQM resulta em uma estrutura hierárquica composta por três n´ıveis:

(i) N´ıvel Conceitual – Objetivos (ii) N´ıvel Operacional – Quest˜oes (iii) N´ıvel Quantitativo – Medida

Através da abordagem top-down, é feita a defini¸cão dos objetivos de medi¸cão e estes são refinados em questões. Posteriormente, medidas são definidas com o intuito de responder às questões. Analisando as medidas, é poss´ıvel saber sobre o grau de alcance dos objetivos (BASILI et al., 1994; SOLINGEN e BERGHOUT, 1999).

A Figura 2.2 ilustra a estrutura hierárquica do método GQM que é usada para a defini¸cão das medidas.

Figura 2.1: Estrutura hierárquica GQM adaptada de (BASILI et al., 1994) Um exemplo de aplica¸cão do GQM para a defini¸cão de medidas encontra-se a seguir.

Diante de um cen´ario onde uma organiza¸c˜ao tenha como objetivo entregar seus projetos de software dentro do prazo planejado, o uso do GQM se aplicaria da seguinte forma:

Objetivo: Entregar dentro do Prazo.

Quest˜ao: Estamos atingindo o cronograma? M´etrica: Schedule Performance Index.

F´ormula: SPI = (Earned Value)/(Planned Value).

(26)

Plano de Medi¸cão e Análise que deve conter as seguintes informa¸cões (SOLINGEN e BERGHOUT, 1999):

• Defini¸c˜ao das medidas.

• Poss´ıveis valores para as medidas.

• Procedimentos para coleta das medidas, que podem ser manuais ou automati-zados.

• Responsabilidade pela coleta das medidas.

• Defini¸c˜ao do momento em que a coleta deve ser realizada. • Procedimentos para an´alise das medidas.

• Forma de apresenta¸c˜ao dos dados para os envolvidos.

2.3.2 M´

etodo GQ(I)M (Goal Question (Indicator ) Measure)

O método GQ(I)M é uma modifica¸cão do método GQM, onde a proposta é ali-nhar medidas e indicadores com os objetivos. A ideia presente nesse método é a de que identificar questões e medidas sem a presen¸ca de um indicador nem sempre é suficiente.

A seguir são apresentados os passos necessários ao uso do método GQ(I)M (GO-ETHERT e FISHER, 2003; ALLEN e DAVIS, 2010; BARRETO, 2011):

1. Identificar e priorizar os objetivos de neg´ocio da organiza¸c˜ao.

2. Identificar o que se deseja conhecer para entender, avaliar, predizer ou melhorar as atividades relacionadas ao alcance dos objetivos.

3. Identificar os subobjetivos, o que significa traduzir os objetivos de alto n´ıvel em subobjetivos relacionados `as atividades.

4. Identificar entidades e atributos relacionados aos subobjetivos e necessários à medi¸cão.

5. Formalizar os objetivos de medi¸c˜ao.

6. Identificar questões quantificáveis e indicadores relacionados às questões que serão usados para apoiar o alcance dos objetivos.

7. Identificar os elementos de dados que serão coletados para compor os indicadores que ajudarão a responder às questões.

(27)

12 9. Identificar as a¸c˜oes que ser˜ao realizadas para implementar as medidas.

10. Preparar um plano para implementar as medidas.

2.3.3 M´

etodo GQM+Strategies

O método GQM+Strategies (BASILI et al., 2007) é uma extensão da abordagem GQM que tem como objetivo o alinhamento da medi¸cão de software com as estratégias de negócio das organiza¸cões.

O GQM+Strategies surgiu para satisfazer a necessidade de integra¸cão dos objetivos de medi¸cão de software com os objetivos de n´ıveis mais altos das organiza¸cões. A sua proposta é fornecer um mecanismo de integra¸cão entre objetivos de medi¸cão de software aos objetivos de mais alto n´ıvel da organiza¸cão e aos objetivos e estratégias do negócio como um todo.

A Figura 2.3 mostra a composi¸cão do método GQM+Strategies com acréscimo de extensões no topo do método GQM, deixando claros os objetivos de negócio, as estratégias e os objetivos de software.

Figura 2.2: GQM+Strategies (ROCHA et al., 2012) adaptado de (BASILI et al., 2007) GQM+Strategies ´e composto pelos seguintes passos:

1. Selecionar os objetivos de neg´ocio da organiza¸c˜ao.

2. Identificar estratégias que apoiam a identifica¸cão dos objetivos espec´ıficos de software que contribuem para o alcance dos objetivos de negócio.

(28)

4. Identificar cenários, isto é, um conjunto de a¸cões necessárias para se alcan¸car o objetivo de software.

5. Definir objetivos de medi¸c˜ao a partir dos cen´arios.

6. Derivar quest˜oes e medidas a partir dos objetivos de medi¸c˜ao.

2.3.4 M´

etodo PSM (Practical Software Measuremen )

O PSM é um método de medi¸cão proposto pela ISO/IEC 15939 (ISO/IEC, 2007) com diretrizes guiadas pela necessidade de informa¸cão da organiza¸cão, onde para cada necessidade encontrada é gerado um produto de informa¸cão. Um Modelo de Informa¸cão de Medi¸cão é considerado para estabelecer essa associa¸cão.

Através do Modelo de Informa¸cão de Medi¸cão, para cada necessidade de infor-ma¸cão, pelo menos um conceito mensurável é determinado em rela¸cão às entidades que podem ser medidas. Essas entidades contêm atributos que recebem a aplica¸cão de m´ eto-dos de medi¸cão com o intuito de gerar medidas base que serão associadas por fun¸cões de medi¸cão para constituir medidas derivadas.

Medidas são interpretadas por meio de modelos de análise e geram indicadores através dos quais é poss´ıvel obter produtos de informa¸cão que atendem às necessidades de informa¸cão anteriormente identificadas.

O PSM possui dois componentes, um Modelo de Informa¸cão de Medi¸cão e um Processo de Medi¸cão. A Figura 2.3 apresenta o Modelo de Informa¸cão de Medi¸cão, que tem o intuito de estabelecer a associa¸cão entre as medidas definidas e as necessidades de informa¸cão. A Figura 2.4, por sua vez, representa a evolu¸cão das necessidades de informa¸cão até a gera¸cão de um plano de medi¸cão.

(29)

14

Figura 2.3: Modelo de Informa¸c˜ao de Medi¸c˜ao (ISO/IEC, 2007).

Figura 2.4: Evolu¸cão da Necessidade de Informa¸cão até o Plano de Medi¸cão (McGARRY et al., 2002).

2.4 Defini¸

c˜

ao dos Procedimentos de Coleta,

Armaze-namento e An´

alise dos Dados

Posteriormente a defini¸cão das medidas, o passo seguinte consiste na defini¸cão dos procedimentos de coleta e armazenamento dos dados. Como o desenvolvimento de software é uma tarefa intelectual, a coleta de dados muitas vezes precisa ser feita de forma

(30)

manual.

Coletas manuais, por serem realizadas por pessoas, estão sujeitas ao viés de quem coleta o dado (voluntaria ou involuntariamente), podendo ocorrer erros, omissões e atrasos. O ideal seria que a coleta fosse sempre feita de forma automática. Porém, isso nem sempre é poss´ıvel. Para garantir que a coleta seja feita de forma adequada, é necessário definir como ela será realizada (FENTON e PFLEEGER, 1997).

Uma defini¸cão clara dos métodos de coleta dos dados pode auxiliar para que os dados sejam coletados de forma correta e uniforme. Para isso, se faz necessário identificar: (i) a frequência com que será realizada a coleta; (ii) o responsável pela coleta; (iii) formu-lários e/ou ferramentas utilizadas para a coleta; (iv) instru¸cões e guias de apoio à coleta de dados; (v) o local de armazenamento dos dados; (vi) o responsável pelo armazenamento, recupera¸cão e seguran¸ca dos dados (SEI, 2010; SOFTEX, 2011b).

Outro aspecto importante é a forma como os dados serão armazenados de modo que se possa garantir a sua seguran¸ca e recupera¸cão. Os modelos CMMI-DEV (SEI, 2010) e MR-MPS (SOFTEX, 2011a), possuem requisitos para a defini¸cão de um repositório de medidas.

A defini¸cão do procedimento de análise conta com a sele¸cão dos métodos e fer-ramentas para a análise dos dados, que inclui: (i) escolher as técnicas de apresenta¸cão mais adequadas (por exemplo, tipos de gráfico); (ii) escolher a estat´ıstica descritiva (por exemplo, média, mediana ou moda); (iii) definir os critérios para amostragem quando não for adequado analisar todos os dados; (iv) definir como será realizada a análise caso faltem dados; e (v) selecionar as ferramentas de análise (SEI, 2010; FLORAC e CARLETON, 1999).

2.5 Considera¸

c˜

oes Finais

Nesse cap´ıtulo foram apresentados conceitos referentes a medi¸cão de software, me-di¸cão nos modelos de maturidade de software, abordagens para medi¸cão de software e procedimentos para coleta, armazenamento e análise dos dados. A compreensão destes conceitos serviu como base para a defini¸cão da especifica¸cão de um sistema de apoio para a cria¸cão de planos de medi¸cão seguindo a abordagem GQM. A especifica¸cão funcional será abordada no próximo cap´ıtulo.

(31)

Cap´ıtulo 3

Especifica¸

c˜

ao do Sistema de Apoio a

Gera¸

c˜

ao de Planos de Medi¸

c˜

ao de

Software

Nesse cap´ıtulo será apresentada a especifica¸cão do sistema, contendo o escopo do software, os requisitos funcionais e não funcionais, o modelo conceitual de classes do dom´ınio, o diagrama de casos de uso e a descri¸cão dos casos de uso e dos atores.

3.1 Escopo do Software

O Sistema de Apoio para a Gera¸cão de Planos de Medi¸cão de Software será baseado na metodologia GQM (Goal-Question-Metric Paradigm) e proverá as seguintes funciona-lidades:

• Manter usu´arios (nome, e-mail, senha, empresa).

• Manter (selecionar) os objetivos de medi¸cão da organiza¸cão. • Manter (selecionar) o refinamento dos objetivos em questões.

• Manter (selecionar) as poss´ıveis métricas que respondam as questões, incluindo: Nome da métrica, Descri¸cão, Fórmula, Indicador, Procedimento para coleta das medidas, Responsabilidade pela coleta das medidas, Procedimento para análise das medidas, Frequência de análise dos dados, Fonte de dados e Local para reportar o resultado da medi¸cão.

(32)

• Gerar o plano de medi¸c˜ao completo.

• Manter a base de conhecimento alimentada por especialistas que pode ser utili-zada pelas empresas em seus planos.

– Cadastrar objetivos reutilizáveis. – Cadastrar questões reutilizáveis. – Cadastrar métricas reutilizáveis. • Não fazem parte do escopo do software:

– Coletar, armazenar, analisar e reportar dados referentes `as m´etricas em projetos de software.

3.2 Especifica¸

c˜

ao Funcional

3.2.1 Modelo Conceitual de Classes do Dom´ınio

—

(33)

18

3.2.2 Requisitos N˜

ao-Funcionais

A Tabela 3.1 mostra os requisitos n˜ao funcionais do sistema. Tabela 3.1: Requisitos N˜ao-Funcionais

Seguran¸ca RNF1:

O sistema terá um procedimento de autentica¸cão através de login e senha, somente usuários cadastrados poderão ter acesso as suas funcionalidades.

Tecnol´ogico RNF2: O sistema ser´a desenvolvido para a plataforma Web.

3.2.3 Requisitos Funcionais

A Tabela 3.2 mostra as funcionalidades pensadas para o sistema. Tabela 3.2: Requisitos Funcionais

RF1: O software deve permitir que o Administrador mantenha Empresas.

RF2: O software deve permitir que o Administrador mantenha usu´arios associados `

as empresas.

RF3: O software deve permitir que o usuário mantenha os objetivos de medi¸cão da sua organiza¸cão, podendo selecionar objetivos pré-cadastrados.

RF4: O software deve permitir que o usu´ario mantenha refinamentos de objetivos em quest˜oes.

RF5:

O software deve permitir que o usuário mantenha as poss´ıveis métricas que respondam a cada questão, incluindo: Nome da métrica, Descri¸cão, Fórmula, Indicador, Procedimento para coleta das medidas, Responsabilidade pela co-leta das medidas, Procedimento para análise das medidas, Frequência de an´ a-lise dos dados, Fonte de dados e Local para reportar o resultado da medi¸cão. RF6: O software deve ser capaz de gerar um plano de medi¸cão completo.

RF7: O software deve ser capaz de permitir que o Administrador cadastre objetivos de medi¸c˜ao reutiliz´aveis.

RF8: O software deve ser capaz de permitir que o Administrador cadastre quest˜oes reutiliz´aveis.

RF9: O software deve ser capaz de permitir que o Administrador cadastre m´etricas reutiliz´aveis.

(34)

Na Tabela 3.3 são descritos os papéis exercidos por cada tipo de usuário do sistema. Tabela 3.3: Descri¸cão dos Atores

Nome Descri¸c˜ao Administrador

Usuário do sistema responsável por cadastrar empresas e usuários associados às mesmas. Responsável também por manter a base de dados que contém objetivos de medi¸cão, questões e métricas reutili-záveis.

Usuário Responsável por montar o plano de medi¸cão da sua empresa, po-dendo fazer uso da base que contém dados pré-cadastrados.

3.3 Diagrama de Caso de Uso

O diagrama de caso de uso encontra-se na Figura 3.2. Neste diagrama é poss´ıvel observar que o Administrador será responsável por cadastrar empresas e usuários. Um usuário cadastrado, por sua vez, será capaz de manter planos de medi¸cão. Ao realizar a manuten¸cão dos planos, ele poderá opcionalmente cadastrar objetivos de medi¸cão, ou selecioná-los de uma lista pré-cadastrada. No contexto da manuten¸cão de um objetivo de medi¸cão, questões e métricas podem ser adicionadas, assim como os atributos das métricas.

(35)

20

—

(36)

3.4 Descri¸

c˜

ao dos Casos de Uso

3.4.1 UC01 – Manter Empresas

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados as empresas.

Ator: Administrador.

Trigger: O ator seleciona a op¸c˜ao Empresas. Fluxo principal:

1. O sistema apresenta a tela da Figura 3.3:

Figura 3.3: Tela principal de Empresas

2. Em caso de inclus˜ao, o ator seleciona a op¸c˜ao Nova Empresa [A1]. Fluxo alternativo:

[A1] O ator selecionou a op¸c˜ao Nova Empresa. 1. O sistema apresenta a tela da Figura 3.4:

(37)

22

Figura 3.4: Tela de Cadastro de Empresa 2. O ator digita as informa¸c˜oes solicitadas.

3. O ator seleciona a op¸cão Salvar. Pós-Condi¸cões:

1. O sistema armazena os dados.

2. Os dados ficam dispon´ıveis para consulta. Edi¸c˜ao:

1. Em caso de altera¸c˜ao, o sistema exibe os dados cadastrados e os habilita para edi¸c˜ao.

2. O usu´ario edita e salva as altera¸c˜oes feitas.

3. O sistema atualiza os dados cadastrais da empresa. Exclus˜ao:

1. Em caso de exclus˜ao, o sistema solicita a confirma¸c˜ao. 2. Se confirmado, o sistema exclui os dados do sistema.

3.4.2 UC02 – Manter Usu´

arios

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados aos usuários.

Ator: Administrador.

(38)

Fluxo Principal:

1. O sistema apresenta a tela da Figura 3.5:

Figura 3.5: Tela principal de Usu´arios

2. No caso de inclusão, o ator seleciona a op¸cão Novo Usuário [A1]. Fluxo Alternativo:

[A1] O ator selecionou a op¸c˜ao Novo Usu´ario. 1. O sistema apresenta a tela da Figura 3.6:

(39)

24 2. O ator digita as informa¸c˜oes solicitadas.

3. O ator seleciona a op¸cão Salvar. Pós-Condi¸cões:

3. O sistema atualiza os dados cadastrais do usu´ario. Exclus˜ao:

3.4.3 UC03 – Manter Plano

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados aos planos de medi¸cão.

Atores: Administrador e Usu´arios.

Trigger: O ator seleciona a op¸c˜ao Novo Plano em Plano de Medi¸c˜ao. Fluxo Principal:

(40)

Figura 3.7: Tela inicial do Plano 2. O ator seleciona a op¸c˜ao Novo Objetivo [E1]. Extens˜ao:

1. [E1] O ator selecionou a op¸c˜ao Novo Objetivo.

2. O caso de uso UC04 Manter Objetivo de Medi¸c˜ao ´e acionado.

3.4.4 UC04 - Manter Objetivo de Medi¸

c˜

ao

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados aos objetivos de medi¸cão.

Atores: Administrador e Usu´arios. Regra de neg´ocio:

RN1: Se o cadastro do novo objetivo for feito pelo administrador, o mesmo torna-se reutilizável, podendo ser aproveitado por usuários comuns posteriormente durante a confeçcão dos seus planos.

RN2: Se o cadastro do novo objetivo for feito por um usu´ario comum, o mesmo ´e salvo no seu plano atual.

Fluxo Prinipal:

(41)

26

Figura 3.8: Tela de cadastro de objetivo 2. O ator informa o novo objetivo.

3. O ator seleciona a op¸cão salvar Pós-Condi¸cões:

2. Os dados ficam dispon´ıveis para consulta. Extens˜ao:

[E1] O ator seleciona a op¸cão de buscar por objetivos, questões e métricas pr´ e-cadastradas.

1. O caso de uso UC05 Selecionar Objetivos de Medi¸cão, Questões e Métricas pré-cadastradas é acionado.

3.4.5 UC05 - Selecionar Objetivos de Medi¸

c˜

ao, Quest˜

oes e M´

e-tricas pr´

e-cadastradas

Fluxo Principal:

(42)

Figura 3.9: Tela de Objetivos de medi¸c˜ao pr´e-cadastrados

2. O ator seleciona o(s) objetivo(s) de medi¸cão dentre os pré-cadastrados. 3. O ator seleciona a op¸cão Salvar.

P´os-Condi¸c˜oes:

2. Os dados ficam dispon´ıveis para consulta. 3. O sistema apresenta a tela da Figura 3.10:

(43)

28 Edi¸c˜ao:

3. O sistema atualiza os dados cadastrais do objetivo de medi¸c˜ao. Exclus˜ao:

1. Em caso de exclusão, o sistema solicita a confirma¸cão. 2. Se confirmado, o sistema exclui os dados do sistema. Extensão:

[E2] O ator seleciona a op¸cão cadastrar questão e métrica. 1. O caso de uso UC06 Manter Questões e Métricas é acionado.

3.4.6 UC06 – Manter Quest˜

oes e M´

etricas

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados as questões e métricas.

Trigger: O ator seleciona a op¸cão cadastrar questões e métricas. Regra de negócio:

RN1: Se o cadastro das questões e métricas for feito pelo administrador, o mesmo torna-se reutilizável, podendo ser aproveitado por usuários comuns posteriormente durante a confeçcão dos seus planos.

RN2: Se o cadastro das questões e métricas for feito por um usuário comum, o mesmo é salvo no seu plano atual.

Fluxo Principal:

(44)

Figura 3.11: Tela de cadastro de quest˜ao e m´etrica

2. O ator informa a quest˜ao e a(s) sua(s) respectiva(s) m´etrica(s) a ser(em) cadas-trada(s).

3. O ator seleciona a op¸cão salvar. Pós-Condi¸cões:

2. Os dados ficam dispon´ıveis para consulta. 3. O sistema exibe a tela da Figura 3.12:

(45)

30

Figura 3.12: Tela de plano em andamento Edi¸c˜ao:

3. O sistema atualiza os dados cadastrais das questões e métricas. Exclusão:

1. Em caso de exclusão, o sistema solicita a confirma¸cão. 2. Se confirmado, o sistema exclui os dados do sistema. Extensão:

[E3] O ator seleciona a op¸cão para cadastrar os atributos da métrica. 1. O caso de uso UC07 Manter os atributos das métricas é acionado.

3.4.7 UC07 – Manter os atributos das m´

etricas

Objetivo: Este caso de uso tem como objetivo permitir a inclusão, altera¸cão ou exclusão dos dados relacionados aos atributos das métricas.

Trigger: O ator seleciona a op¸c˜ao para cadastrar os atributos das m´etricas. Fluxo Principal:

(46)

Figura 3.13: Tela de cadastro dos atributos da m´etrica 2. O ator informa os atributos da m´etrica.

3. O ator seleciona a op¸cão salvar. Pós-Condi¸cões:

3. O sistema atualiza os dados cadastrais da empresa. Exclus˜ao:

(47)

32

3.5 Decis˜

oes de Projeto

Para o desenvolvimento do sistema feito nesse trabalho, foi usada a tecnologia Ruby on Rails que é um framework para o desenvolvimento de aplica¸cões Web com base no padrão de arquitetura MVC (Model-View-Controller ), dado que a mesma atendia as necessidades do projeto. O banco de dados MySQL foi usado para fazer a persistência dos dados. O framework front-end bootstrap também foi utilizado.

3.6 Considera¸

c˜

oes Finais

Neste cap´ıtulo foi apresentada a especifica¸cão funcional pensada para o sistema de apoio para a gera¸cão de planos de medi¸cão. O próximo cap´ıtulo apresentará o sistema resultante e uma prova de conceito da sua utiliza¸cão.

(48)

Cap´ıtulo 4

O sistema de apoio para a gera¸

c˜

ao de

planos de medi¸

c˜

ao de software

O sistema resultante será abordado a seguir sob a ótica dos seus usuários, deixando claros os papéis que cada um pode exercer.

4.1 Administrador

4.1.1 Manter Empresas

A página referente ao caso de uso Manter Empresas encontra-se na Figura 4.1. Através dela é poss´ıvel visualizar, cadastrar, editar e apagar empresas, fun¸cões dispon´ıveis somente para o Administrador do sistema.

(49)

34

Figura 4.1: P´agina principal de Empresas

4.1.2 Manter Usu´

arios

A página referente ao caso de uso Manter Usuários encontra-se na Figura 4.2. Através dela é poss´ıvel visualizar, cadastrar, editar e apagar usuários, fun¸cões dispon´ı-veis somente para o Administrador do sistema. Através dessa página também é feita a associa¸cão dos usuários com as empresas das quais eles pertencem.

(50)

4.1.3 Pr´

e-cadastros

A Página composta por dados pré-cadastrados pelo Administrador do sistema encontra-se na Figura 4.3. As informa¸cões dispon´ıveis nela podem ser utilizados pelos usuários comuns durante a elabora¸cão dos seus planos.

Figura 4.3: P´agina de dados Pr´e-Cadastros

4.2 Usu´

ario

4.2.1 Objetivos de Medi¸

c˜

ao, Quest˜

oes e M´

etricas

A página referente aos casos de uso Manter Objetivos de Medi¸cão, Manter Ques-tões, Manter Métricas e Manter os Atributos das Métricas encontra-se na Figura 4.4. Através da mesma é poss´ıvel visualizar, cadastrar, editar e apagar objetivos, questões, métricas e os atributos das métricas.

(51)

36

Figura 4.4: Página de Objetivos de Medi¸cão, Questões, Métricas e Atributos das Métricas

4.2.2 Selecionar dados pr´

e-cadastrados

A página referente ao caso de uso Selecionar Objetivos de Medi¸cão, Questões e Métricas pré-cadastradas encontra-se na Figura 4.5. Através da mesma os usuários co-muns podem fazer uso da base de conhecimento mantida pelo administrador do sistema, inserindo esses dados em seus planos.

(52)

4.3 Prova de Conceito: Criando um Plano de

Medi-¸

c˜

ao Real

Para a realiza¸cão da prova de conceito, foi utilizado um Plano de Medi¸cão real de uma empresa que foi feito antes da elabora¸cão do sistema. O exemplo utilizado encontra-se no Anexo A.

4.3.1 Objetivos de Medi¸

c˜

ao

Nessa página, Figura 4.6, foram adicionados os objetivos e suas respectivas questões e métricas existentes no plano de medi¸cão utilizado.

Figura 4.6: P´agina de Objetivos de Medi¸c˜ao

4.3.2 Quest˜

oes e M´

etricas

Nessa página, Figura 4.7, é poss´ıvel ver como as questões e métricas são apresen-tadas no sistema.

(53)

38

Figura 4.7: Página de Questões e Métricas

4.3.3 Gera¸

c˜

ao do plano

Nessa página, Figura 4.8, é poss´ıvel ver a gera¸cão do plano contendo os objetivos, questões, métricas e a descri¸cão das métricas.

Figura 4.8: Página de gera¸cão do Plano contendo os objetivos, questões, métricas e des-cri¸cão das métricas

Na mesma página também é poss´ıvel visualizar cada métrica informada durante o plano e seus respectivos atributos, como mostra a Figura 4.9. Os espa¸cos em branco representam os dados faltantes exigidos pelo GQM, mas que não foram informados durante a elabora¸cão do Plano, destacando assim a importância da utiliza¸cão de uma ferramenta

(54)

de apoio para a gera¸cão de planos de medi¸cão, tendo em vista que o plano usado como exemplo foi feito sem o aux´ılio de nenhuma ferramenta de apoio espec´ıfica para a gera¸cão de planos de medi¸cão.

Figura 4.9: Página de gera¸cão do Plano contendo os atributos das métricas

4.4 Trabalhos Relacionados

A Esta¸cão TABA é um meta-ambiente capaz de gerar, através de instancia¸cão, am-bientes de desenvolvimento de software (ADS) adequados às particularidades de processos de desenvolvimento e de projetos espec´ıficos (ROCHA et al., 2005).

A TABA apoia as atividades de medi¸cão e análise baseadas no método GQM (Goal Question Metric) (SCHNAIDER et al., 2004). Este apoio possui como objetivo garantir que o procedimento de medi¸cão seja feito de forma consistente, fazendo com que os dados necessários para a sua análise sejam facilmente obtidos de documentos preenchidos pela equipe durante o decorrer dos projetos.

A proposta aqui apresentada se distingue pela possibilidade de cadastrar objetivos de medi¸cão (com questões e métricas) reutilizáveis e ajustáveis que podem ser utilizados durante a confeçcão dos planos e por não apoiar o registro e a análise de medi¸cões. Outra diferen¸ca é a plataforma tecnológica, já que o apoio fornecido pelo TABA é desktop e integrado em uma infraestrutura maior, enquanto o aqui descrito é auto contido e pode ser disponibilizado através da Web.

(55)

40

4.5 Considera¸

c˜

oes Finais

Neste cap´ıtulo foi apresentado o uso do sistema através dos seus casos de uso e também uma prova de conceito de utiliza¸cão do sistema feita com um plano de medi¸cão real. O próximo cap´ıtulo abordará sobre as contribui¸cões, limita¸cões e trabalhos futuros idealizados para esse projeto.

(56)

Cap´ıtulo 5

Considera¸

c˜

oes Finais

5.1 Contribui¸

c˜

oes

Este trabalho tem como principal contribui¸cão a proposta de prover apoio ferra-mental para que as empresas possam criar seus planos de medi¸cão de software seguindo o que propõe a metodologia GQM. Ao utilizar esse sistema, o usuário tem a possibilidade de preencher as informa¸cões requeridas pelo método GQM, caso contrário, o mesmo teria uma maior dificuldade em garantir que o seu plano de medi¸cão fosse feito de maneira correta.

Através de uma prova de conceito utilizando um plano de medi¸cão real, o sistema mostrou-se útil em seu propósito, fazendo com o que o usuário preenchesse os dados requeridos para a confeçcão do plano e ao final gerou um plano de medi¸cão completo com os dados informados que podem ser consultados a qualquer momento.

De forma detalhada, as contribui¸c˜oes da monografia como um todo est˜ao listadas abaixo:

• Provimento de uma revisão bibliográfica a respeito dos conceitos básicos de medi¸cão de software.

• Elabora¸cão de uma especifica¸cão funcional para um sistema de apoio à gera¸cão de planos de medi¸cão de software.

• Projeto e implementa¸c˜ao do software correspondente.

• Realiza¸cão de uma avalia¸cão inicial da viabilidade de utilizar o software para gerar um plano de medi¸cão real.

(57)

42

5.2 Limita¸

c˜

oes

As principais limita¸cões do presente trabalho estão relacionadas ao seu escopo, já que o foco do trabalho foi na gera¸cão de planos de medi¸cão e não no apoio às tarefas de medi¸cão em si. Destacam-se as seguintes:

• Não permitir selecionar objetivos de medi¸cão com marca¸cões (tags) que repre-sentem caracter´ısticas com as quais se relacionam, de modo a facilitar a futura reutiliza¸cão.

• Não apoiar a coleta, registro, análise e comunica¸cão das medidas em projetos de desenvolvimento de software.

• N˜ao realizar controle estat´ıstico de processos, etc.

5.3 Trabalhos Futuros

Tendo em vista as limita¸cões, a evolu¸cão do que propõe inicialmente esse sistema de aux´ılio para elabora¸cão de planos de medi¸cão, poderá ser composta por funcionalidades como:

De acordo com a caracter´ıstica a ser medida (por exemplo, tamanho, esfor¸co), escolhida pelo usuário, o sistema poderá sugerir objetivos de medi¸cão, questões e métricas pré-cadastradas associadas a esta caracter´ıstica.

Apoiar a coleta, armazenamento, análise e comunica¸cão dos dados relativos as medi¸cões.

Através da análise dos indicadores informados, o sistema poderá sinalizar sobre as situa¸cões em que os projetos se encontram.

Aplicar o controle estat´ıstico de processos, para realizar a execu¸c˜ao da an´alise sobre o comportamento dos mesmos.

O controle estat´ıstico de processos pode ser entendido como uma evolu¸cão do pro-cesso de medi¸cão que utiliza gráficos de controle e métodos estat´ısticos espec´ıficos para fazer a análise dos dados coletados para a medi¸cão. Os gráficos possibilitam o controle es-tat´ıstico porque mostram as varia¸cões no comportamento dos processos, permitindo assim a análise da sua estabilidade.

(58)

Através da associa¸cão de métodos estat´ısticos com análises cronológicas, o controle estat´ıstico de processos possibilita a deteçcão de mudan¸cas e tendências no comportamento dos processos ao longo do tempo (BENNEYAN et al., 2003).

No geral, a medi¸cão tradicional faz o acompanhamento periódico (bimestral, men-sal, quinzenal, etc.), já o controle estat´ıstico tem como finalidade um acompanhamento mais frequente, às vezes diário, do comportamento dos processos.

(59)

Referˆ

encias Bibliogr´

aficas

ALLEN,J.H., DAVIS,N., Measuring Operational Resilience Using the CERT Re-siliense Management Model, Carnegie Mellon University, Software Engineering Insti-tute, Technical Note CMU/SEI-2010-TN-030, 2010.

AMCHAM, Somente 14% das empresas est˜ao plenamente satisfeitas com men-sura¸c˜ao de resultados de TI, Dispon´ıvel em: <http://www.amcham.com.br>. Acesso em: 15 de novembro de 2016.

BARCELLOS, M. P., Uma Estratégia para Medi¸cão de Software e Avalia¸cão de Bases de Medidas para Controle Estat´ıstico de Processos de Software em Organiza¸cões de Alta Maturidade, Tese de Doutorado, Universidade Federal do Rio de Janeiro, 2009a.

BASILI. V., CALDIERA, G., ROMBACH, H., Goal Question Metric Paradigm, In: Encyclopedia of Software Engineering, 1994. v.2, pp: 527 – 532.

BASILI,V., HEIDRICH, J., LINDVALL, M., M ¨UNCH, J., REGARDIE, M., TREN-DOWICZ, A., GQM+Strategies - Aligning Business Strategies with Software Measurement, In: 1st International Symposium on Empirical Software Engineering and Measurement, 2007.

BASS,L., BELADY,L.BROWN,A., FREEMAN,P. ISENSEE,S., KAZMAN,R., KRANS-NER,H., MUSA,J. PFEEGER,S, VREDENBURG,K., WASSERMAN,T., Constructing Superior Software, Software Quality Institute Series, Macmillan Technical Publishing, 1999.

(60)

BENNEYAN, J. C., LLOYD, R., PSELK, P. E., 2003, Statistical Process Control as a Tool for Research and Healthcare Improvement, British Medical Journal -Quality and Safety Health Care, vol. 12, pp. 458-464.

WIKIP ´EDIA. CMMI. Dispon´ıvel em: <https://pt.wikipedia.org/wiki/CMMI>. Acesso em: 27 de julho de 2016.

CURTIS,B., REIFER,D. SESHAGIRI,G.V., HIRMANPOUR, T., KEENI,G. The Case for Quantitative Process Management, IEEE Software, 2008. v. 25, n. 3, pp 24-28. DEMARCO, T. Controle de projetos de software: gerenciamento, avalia¸c˜ao e estimativa. Rio de Janeiro: Campus, 1989.

FENTON, N.E e PFLEEGER, S.L., Software Metrics: a Rigorous and Practical Approach, PWS Publishing Company, 2 nd Edition, 1997.

GOETHERT, W., FISHER, M., Deriving Enterprise-Based Measures Using the Balanced Scorecard and Goal-Driven Measurement Techniques, Carnegie Mellon University, Software Engineering Institute, Technical Note CMU/SEI-2003-TN-024, 2003. GOH, T.N., XIE, M., XIE, W., Prioritizing Process in Initial Implementation of Statistical Process Control, IEEE Transactions on Engineering Management, 1998. v.45, n.1, pp 66-72.

GOPAL, A., KRISHNAN, M.S., MUKHOPADHYAY, T. GOLDENSON, D.R., Measu-rement Programs in Software Development: Determinants of Success, IEEE Transactions on Software Engineering, 2002. v.28, n.9, pp 863-875.

ISO/IEC, ISO/IEC 15939 - Software Engineering – Software Measurement Pro-cess, The International Organization for Standardization and the International Electro-technical Commission, 2002.

KITCHENHAM, B., KUTAY, C., JEFFERY, D. R

” CONNAUGHTON, C., Lessons Learnt from the analysis of large-scale corporate databases, International Confe-rence on Software Engineering, 2006. pp 439-444.

(61)

46 MCGARRY, JOHN; CARD, DAVID; JONES, CHERYL; LAYMAN, BETH; CLARK, ELIZABETH; DEAN, JOSEPH; HALL, FRED HALL. Practical Software Measure-ment: Objective Information for Decision Makers, Addison Wesley Professional, 2001.

NIESSINK, F., VLIET, H., Measurement Program Success Factors Revisited, Information and Software Technology, 2001. v.43, n.10, pp 617-628.

ROCHA, A. R. C., SOUZA, G. S., BARCELLOS, M. P., Medi¸c˜ao de Software e Controle Estat´ıstico de Processos, Maio 2012.

ROCHA, A. R. C., MONTONI, M., SANTOS, G., MAFRA, S., FIGUEIREDO, S., BESSA, A., MIAN, P. Esta¸cão TABA: Uma Infra-estrutura para Implanta¸cão do Modelo de Referência para Melhoria de Processo de Software, IV Simpósio Brasileiro de Qualidade de Software, SBQS’05, Porto Alegre, 2005.

SANTOS, G., M. KALINOWSKI, A.R. ROCHA, G.H. TRAVASSOS, K.C. WEBER, and J.A. ANTONIONI. MPS.BR program and MPS model: main results, benefits and beneficiaries of software process improvement in Brazil, In 8th Int. Conf. on the Quality in Information and Communications Technology (QUATIC), Lisbon, Por-tugal, 2012.

SARGUT, K. U., DEMIRORS, O., Utilization of Statistical Process Control (SPC) in Emergent Software Organizations: Pitfalls and Suggestions, Software quality Journal, 2006. v. 14, n. 5, pp 135-157.

SCHNAIDER, L., SANTOS, G., MONTONI, M., ROCHA, A.R.C., Uma abordagem para Medi¸cão e Análise em Projetos de Desenvolvimento de Software. III Simpósio Brasileiro de Qualidade de Software, Bras´ılia, 2004.

SEI, Capability Maturity Model Integration (CMMI) for Development, ver-sion 1.3, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI-2010-TR-033, 2010.

SEMA 2010, Software Engineering Institute Software Engineering Measurement and Analysis web site. Dispon´ıvel em: <http://www.sei.cmu.edu/measurement>. Acesso em: 05 de dezembro de 2016.

(62)

SOFTEX. Manual de referˆencia. Guia Geral MPS de Software, 2016. Dispon´ıvel em: <http://www.softex.br/mpsbr/guias>. Acesso em: 20 de maio de 2016.

SOFTEX. Manual de referência. Guia de Implementa¸cão – Parte 2: Fundamen-ta¸cão para Implementa¸cão do N´ıvel F do MR-MPS-SW:2016. Dispon´ıvel em: <http://www.softex.br/mpsbr/guias>. Acesso em: 11 de outubro de 2016.

SOLINGEN, R., BERGHOUT, E., The Goal/Question/Metric Method: a Prac-tical Guide for Quality Improvement of Software Development, McGraw-Hill, 1999.

TRAVASSOS, G.H., and M. KALINOWSKI, iMPS 2013: Evidˆencias sobre o desem-penho das empresas que adotaram o modelo MPS-SW (in Portuguese), Campinas, Brazil: Softex, 2014. ISBN: 978-85-99334-75-1.

WANG, Q., LI, M., Measuring and Improving Software Process in China, In: Proceedings of International Symposium on Empirical Software Engineering, 2005. p 183-192.

(63)

Anexo A - Plano de Medi¸

c˜

ao de uma

empresa real

Introdu¸c˜ao

O propósito do Plano de Métricas é definir as métricas que irão dar suporte à gerência para tomar decisões baseadas em informa¸cões para promover qualidade, produti-vidade e melhoria de processo. Este plano assegura que as métricas definidas são alinhadas aos objetivos do negócio e do programa, e que as métricas sejam implantadas em uma abordagem organizada e planejada.

Objetivos

O objetivo primário do Plano de Métricas é identificar as métricas que serão usadas para medir e gerenciar a execu¸cão do projeto. Ele detalha que métricas devem ser con-sideradas, como calcular estas métricas, como analisar (incluindo análise quantitativa), e onde reportar os resultados do desempenho do projeto.

Desta forma, o Plano de Métricas apóia as iniciativas de aprimorar o desempenho e a qualidade do desenvolvimento e manuten¸cão de aplica¸cões.

Objetivos, Quest˜oes e M´etricas (GQM)

O paradigma Goal Question Metric (GQM) foi utilizado para selecionar as métricas do Plano de Métricas. O GQM é uma abordagem top-down para desenvolver, selecionar e ajustar métricas.

A empresa participante desse plano tem um conjunto de metas de aperfei¸coamento baseado em suas estratégias. Essas metas são então traduzidas pelo projeto em objetivos espec´ıficos de processo, como definido abaixo. Consequentemente, questões são feitas para determinar se esses objetivos estão sendo atingidos. Cada questão é respondida por uma ou mais métricas espec´ıficas que provêm uma resposta apropriada para a pergunta. Se a métrica responde satisfatoriamente a questão, então pode mostrar se os objetivos do

(64)

projeto est˜ao sendo atingidos.

Objetivo: Conhecer o Tamanho dos Projetos de Software da empresa X. Tabela 5.1: Tamanho dos Projetos de Software Questão Métrica Descri¸cão Qual o tamanho

do projeto de software?

Ponto de Caso de Uso.

Mede a quantidade de funcionali-dade a ser desenvolvida com base em especifica¸c˜oes funcionais ba-seadas em casos de uso.

Objetivo: Entregar no Or¸camento.

Tabela 5.2: Or¸camento

Questão Métrica Descri¸cão

Estamos no

or-¸camento? Cost Performance Index.

Mede a eficiência do esfor¸co (ho-ras ou dias) gastos. Isso significa se que um for CPI menor que 1,0, o projeto é menos eficiente que o planejado (ou seja, gastou mais esfor¸co que o planejado). Se o CPI é maior que 1,0, o projeto é mais eficiente que o planejado. Qual o

es-for¸co total do projeto?

N´umero de Horas Trabalhadas no Projeto.

Mede o n´umero total de horas trabalhadas no projeto.

Qual o esfor¸co total empregado nas atividades do projeto?

N´umero de Horas Trabalhadas por Atividade do Projeto.

Mede o n´umero total de ho-ras trabalhadas por atividade do projeto.

(65)

50 Objetivo: Entregar dentro do Prazo.

Tabela 5.3: Prazo

Questão Métrica Descri¸cão

Estamos atin-gindo o crono-grama?

Schedule Performance Index

Mede se o projeto está agregando valor conforme estimado no cro-nograma. Essa métrica pode ser usada para ajudar os geren-tes a determinar se um projeto será completado no tempo, assu-mindo que a tendência atual con-tinue.

Objetivo: Melhorar a Produtividade.

Tabela 5.4: Produtividade

Questão Métrica Descri¸cão Qual a nossa

produtividade? Produtividade

Mede a quantidade de horas gas-tas para produzir uma unidade de tamanho do software. Qual o nosso percentual de esfor¸co de desenvolvi-mento gasto em retrabalho? Retrabalho

Mede o percentual de esfor¸co de desenvolvimento investido em re-solver problemas descobertos nos testes e em produ¸c˜ao.