METODOLOGIA PARA CONCEPCÃO DE MÉTRICAS DE SOFTWARE PARA

PEQUENAS EMPRESAS

METHODOLOGY FOR DESIGN SOFTWARE METRICS FOR SMALL

BUSINESSES

Murilo César Cabral1; José Morched Carneiro2

RESUMO

A ampliação e globalização do mercado atual de software

obriga as empresas do ramo a desenvolverem técnicas e

estruturas de controle para se manterem competitivas e

atuantes. Este artigo destina-se a pequenas empresas que já

possuem algum tipo de controle sobre as sua produção de

produtos de software incluindo elicitação de requisitos,

gerência de projetos e processos, e elabora um modelo de

métricas a serem inseridas no cotidiano da empresa baseadas na

metodologia GQM (Goal, Questions, Metrics).

Palavras-chave: GQM. Desenvolvimento de Software. TI.

Engenharia de Software.

ABSTRACT

The expansion and globalization of the software current

1 Pós-graduando do curso de MBA em Gestão de Software do Centro

Universitário de Goiás Uni-ANHANGUERA. E-mail: murilo.cabral@gmail.com.2 Professor Mestre, do Núcleo de Pós-Graduação do Centro Universitário de

Goiás Uni-ANHANGUERA.

1

market requires companies in the industry to develop

techniques and control structures to remain competitive and

active. This article is aimed at small businesses that already

have some sort of control over the production of software

products including requirements elicitation, project

management and processes, and establish a model of metrics to

be included in the daily company based methodology GQM (Goal,

Questions, Metrics).

Keywords: GQM. Software Development. IT. Software Engeneer.

2

INTRODUÇÃO

Com os eventos de globalização de mercados e a divulgação

cada vez mais rápida de informações, principalmente por meios

eletrônicos, o desenvolvimento de software tem se tornado uma

atividade muito complexa e cheia de riscos por seus caminhos.

Para se manter no mercado as empresas da área tem que garantir

a qualidade de seus produtos. No caso de médias e grandes

empresas existem, no mercado, modelos de processos de

desenvolvimento software já consagrados que possuem entidades

que certificam que as empresas analisadas seguem os padrões

definidos por eles. Porém os recursos financeiros e humanos

necessários para se conseguir estas certificações ficam longe

da realidade de micro e pequenas empresas da área.

Isso não quer dizer que micro e pequenas empresas não

possam, ou não devam, garantir a qualidade de seus produtos de

software. Estas empresas, doravante chamadas de MPEs (Micro e

Pequenas Empresas), devem, com pena de serem excluídas do

mercado, criar suas próprias metodologias e processos que

garantam que seus produtos tenham a mesma, ou quase, qualidade

dos de organizações de maior porte. Essas atividades de

controle e estruturação para estas MPEs também gerarão custos

que devem, com até maior atenção que nas empresas maiores, ser

controlados e priorizados para que caibam no seus orçamentos.

Rocha (2001) diz que a qualidade de um produto de

software é determinado pela quantidade de satisfação dos

motivos que levaram à criá-lo. Como determinar esta

quantidade? A resposta à esta indagação é métrica.

3

Este trabalho dedica-se a estudar a metodologia GQM(Goal-

Question-Metrics) de elaboração de métricas e tem o objetivo

de ajudar as MPEs a elaborar e utilizar de forma correta estas

definições.

REVISÃO BIBLIOGRÁFICA

Não é por se tratar de um estudo para MPEs que se imagina

organizações sem controle e com uma administração desleixada

e falha. Como veremos na definição do cenário em que se baseia

este trabalho as empresas que compõem o universo ao qual este

se destina efetuam algum tipo de Gerência de Requisitos,

Gerência de projetos e têm processos definidos, mesmo que de

forma rústica e simplória. Quando se fala em elaboração de

métricas para atingir um determinado objetivo, esta atividade

exige, obrigatoriamente, a definição de processos, pois na

hora de defini-las deve-se saber quem irá medir, quando irá

medir, o que será medido e quanto vai custar. Praticamente

todas estas informações estão contidas na definição dos

processos bastando apenas se definir em que ponto do processo

serão feitas as medições.

Cenário

Definir-se-á neste tópico o tipo e tamanho das empresas a

que se refere este trabalho, o mercado no qual elas estão

incluídas, como elas funcionam, que tipo de gerência possuem e

4

as metodologias que já são praticadas.

O Mercado Brasileiro

O Brasil vem se destacando cada vez mais em diversas

áreas do conhecimento e desenvolvimento de software(DS) não é

exceção. Somos um país de dimensões continentais e cheio de

enormes discrepâncias regionais mesmo assim o software tem

chegado a todo tipo de comunidade e a todo tipo de pessoa com

a difusão das aplicações e as variações de tipos de software

fabricado. Quando falamos de software embarcado(software que

já está instalado em produtos), por exemplo, ele está presente

em celulares, relógios, calculadoras, geladeiras, brinquedos e

em praticamente todos os produtos fabricados hoje em dia, e

atinge toda a sociedade sem distinção de de nenhuma

característica, nem mesmo econômica pois existem produtos

muito simples que carregam este tipo de software.

Segundo a ABES – Associação Brasileira de Empresas de

Software (2011), o mercado de TI no Brasil vem crescendo

tanto no número de empresas como nos valores (Tabela 1). O

país já representa 49,6% do mercado Latino Americano e 2,4% do

mercado mundial.

Ainda conforme a ABES, enquanto a maior parte do mercado

5

mundial decresce, EUA, Japão, China, Brasil e Índia seguem em

sentido contrário a esta tendência, inclusive logrando a crise

mundial. No caso do Brasil ainda temos 13,8 milhões de PC's

vendidos, 56,5 milhões de computadores instalados e 81,5

milhões de usuários de internet tudo em 2010. A ABES também

estendeu seu estudo no sentido de totalizar, levando em

consideração somente a quantidade de empresas e não a

participação no mercado, o percentual de micro, pequenas,

médias e grandes empresas deste mercado, chegando à conclusão

que micros e pequenas somam 94,3% do total sendo que micros

36,7% e pequenas 57,6%.

Há também uma tendência de empresas brasileiras de

software buscarem certificações oficiais de modelos como

MPS.BR(Figura 1) e CMMI (Figura 2), causando automaticamente

um aumento na qualidade do software produzido aqui e

difundindo para maior número de profissionais as melhores

práticas contidas nestes modelos. Comparando-se estes gráficos

nota-se uma tendência de forte crescimento nos últimos anos e

mais recentemente uma tendência a estabilizar.

6

No entanto ainda há um percentual muito alto de empresas

do ramo que nem sequer conhecem as técnicas e as disciplinas

envolvidas nestes processos.

O que é uma MPE?

Para efeito da Lei Complementar nº 123, de 14 de dezembro

de 2006 que institui o Estatuto Nacional da Microempresa e da

Empresa de Pequeno Porte, microempresa é aquela que auferiu no

ano-calendário receita bruta igual ou inferior a R$ 360.000,00

(Trezentos e sessenta mil reais) e empresa de pequeno porte é

aquela que auferiu no ano-calendário receita bruta superior a

R$ 360.000,00 (Trezentos e sessenta mil reais) e inferior a R$

3.600.000,00(Três milhões e seiscentos mil reais).

Para efeito das análises e proposições deste trabalho,

MPE é uma organização que, além de se enquadrar nesta

definição da Lei, possui uma estrutura composta por até 50

colaboradores distribuídos em pelo menos uma e no máximo dez

equipes de desenvolvimento.

Estrutura

Considera-se, para fins deste trabalho, uma equipe, um

grupo de trabalho formado por um líder e pelo menos dois

desenvolvedores de mesmo nível como uma estrutura mínima

(Figura 3) até um grupo formado por um líder e vários

desenvolvedores de até três níveis de conhecimento (Figura 4).

7

As melhores práticas exigem, no entanto, que se tenha no

mínimo dois desenvolvedores classificados com o mesmo nível de

conhecimento para que um possa verificar o trabalho do outro.Figura 3. Estrutura mínima de Equipe

Figura 4. Estrutura máxima de uma MPE

Vale ressaltar que as estruturas definidas pelas figuras

3 e 4 são uma formação genérica e que dependendo do tipo de

produto ou das metodologias adotadas ou ainda dos processos da

organização esta estrutura pode ter grandes variações. Cada

organização é única e deve formar a sua própria estrutura

seguindo as suas estratégias e metas.

Gerência de Requisitos

Requisitos são parte fundamental no desenvolvimento de

qualquer produto, inclusive os produtos de software, são eles

que vão definir todas as características que o produto deve

atender e como vai funcionar. Sem a elicitação dos requisitos

8

Líder de equipe 2

D esenvolvedor N ível A

D esenvolvedor N ível X

D esenvolvedor N ível B

D esenvolvedor N ível C

D esenvolvedor N ível B

D esenvolvedor N ível C

Líder de equipe 1

D esenvolvedor N ível A

D esenvolvedor N ível A

D esenvolvedor N ível B

D esenvolvedor N ível C

D esenvolvedor N ível B

D esenvolvedor N ível C

G erente de P rojetos

Líder de equipe N

Líder de equipe

D esenvolvedor N ível X

D esenvolvedor N ível X

todo o projeto fica desnorteado e as chances de fracasso são

aumentadas exponencialmente. Além disso, para determinar se um

produto tem qualidade deve-se saber para que ele foi elaborado

e se ele atende satisfatoriamente estes objetivos

(requisitos).

No caso do desenvolvimento de software os requisitos têm

uma forte tendência a mudança e a boa definição deles

contribuí enormemente para a diminuição das alterações durante

a fase de execução do projeto e também facilitam o

rastreamento de impacto que uma determinada mudança causará.

Da compreensão e definição deste impacto extrai-se as

alterações que serão necessárias no escopo, risco, tempo,

recursos e no orçamento do projeto.

Com base nesta análise concluí-se que, mesmo para

pequenas organizações, a elicitação de requisitos se torna

obrigatória para se garantir a qualidade de produtos de

software. Sem ela o projeto fica fica sem rastreabilidade sem

definição de escopo e correrá em enorme risco de fracasso.

Gerência de Projetos

Um projeto é um esforço coordenado, temporário e único

feito com o objetivo de criar um novo produto, serviço,

resultado ou inovação em um destes e tem como uma

característica possuir data de início e fim. Antunes (2010)

diz que “projeto é uma reunião coordenada de esforços para atingir

objetivo predeterminado com qualidade, custo e prazo definidos”. A

9

criação de um projeto exige conhecimentos nas disciplinas

escopo, tempo, custo, qualidade, RH, comunicação, risco,

aquisições e integração e passa pelas fases de iniciação,

planejamento, execução, controle e encerramento (Figura 5).

Escopo é a área do conhecimento voltada para a definição

dos objetivos e não-objetivos do projeto. Muito importante

para a elaboração para o restante do projeto ela define os

limites do projeto e deve esclarecer para as partes envolvidas

o que será feito e o que não será feito, sendo esta última

fundamental, ou seja, estabelecer o não-escopo é tão ou mais

importante do que o o escopo.

Tempo é a disciplina que vai gerenciar os limites de

tempo para execução do projeto. Do ponto de vista do cliente é

uma das áreas mais importantes juntamente com custo. Cabe ao

gerenciamento do tempo controlar a execução do projeto, prever

possíveis atrasos e fazer ajustes para que estes não ocorram.

Custo provavelmente seja a área mais importante do ponto

de vista do cliente pois ela controla o orçamento do projeto e

as alterações neste.

Qualidade é a disciplina que vai definir os requisitos

de qualidade e garantir que durante a execução do projeto eles

estejam sendo atendidos de forma plena.

Recursos Humanos é uma das áreas mais importantes do

projeto pois tudo dentro dele será feito por pessoas. Cabe a

gerência de RH escolher os colaboradores que participarão do

projeto e planejar a contribuição de cada um de acordo com

suas habilidades. Alocar atividades que fazem parte do

10

conhecimento individual de um determinado colaborador vai

facilitar outras tantas atividades causando uma diminuição no

tempo, e por consequência no custo, e aumentando a qualidade

do produto do projeto.

Aquisições é a disciplina que irá controlar as aquisições

necessárias ao andamento do projeto e garantir que os recursos

envolvidos estejam disponíveis quando forem necessários.

Comunicações é a parte que controla as informações do e

sobre o projeto e mantém as pessoas interessadas atualizadas

sobre o andamento e mudanças ocorridas nele. Faz parte da

responsabilidade desta disciplina identificar as pessoas

interessadas e seus interesses e as formas de comunicação que

serão utilizadas para gerar a comunicação do projeto.

Riscos é a disciplina responsável por identificar

possibilidades de problemas que podem gerar riscos ao bom

andamento e até a execução do projeto e planejar ações

corretivas e/ou preventivas no sentido de minimizar ou até

anular os seus efeitos.

Integração é a gestão do projeto em si. Cabe a esta área

do conhecimento controlar e monitorar o projeto, ou seja,

fazer a coisa acontecer.

A organização que desejar ter qualidade nos seus

produtos, seja qual for a natureza deles, dever ter uma gestão

orientada por projetos. Mesmo que não seja purista, como

defendem os adeptos de tais práticas onde tudo é projeto, ela

deve se utilizar destas ferramentas pelo menos no

desenvolvimento de novos produtos ou serviços.

11

Processos

Um processo é um conjunto de atividades coordenadas e

desenvolvidas rotineiramente que utilizam recursos (humanos,

informações, máquinas e etc.) e que ao serem executadas

transformam entradas em um resultado agregando valor. Os

processos são, também uma forma produzir, melhorar e divulgar

o Know-how, ou seja, o como fazer. As organizações que possuem

processos definidos são menos dependentes das pessoas, que, ao

contrário, ficam dependentes deles e, pelo menos teoricamente,

irão produzir resultados padronizados. Por tanto quanto

melhores os processos maior a qualidade dos produtos gerados

através deles. Covatti (2007) diz que “no desenvolvimento de

software o processo de qualidade é importante, pois é difícil

medir os atributos de um software, a melhoria da qualidade é

focada em encontrar um produto de qualidade e mapear o

processo utilizado para a construção do mesmo.”

Acredita-se que todo trabalho humano deveria ser

orientado por uma metodologia, mas é de conhecimento público

que muitas pequenas empresas não adotam nenhuma por

desconhecimento ou custos envolvidos na implantação. Processos

são uma solução barata e de fácil manutenção e melhoria e para

as empresas a que se destina este trabalho exige-se a

definição, mesmo que rústica, deles.

12

Cultura Organizacional

O ser humano é um ente carregado de defeitos, manias,

vaidades, convicções e outras e quando esta convulsão emocional

se junta a outros, sendo que cada um é único, as interações

entre eles deveriam se tornar um caos. Graças ao bom-senso e a

sociabilidade que também são natos em nós conseguimos

conviver. No entanto, dentro das organizações, detectamos

comportamentos inadequados em quase todos os seus integrantes.

Existem gestores exigentes ao extremo que não confiam em

ninguém como gestores complacentes (quase em extinção pelas

condições do mercado atual) e também colaboradores

desmotivados desinteressados e quase todos com pouca noção do

que do que é o trabalho e o que realmente são as relações

trabalhistas. Máximo Filho (2006) diz que “a cultura

organizacional é o conjunto de valores, crenças e normas que

são partilhados pelos colaboradores de uma organização e que

afetam os seus comportamentos e atitudes”.

Para efeito deste trabalho, que vai tratar a instauração

de métricas dentro de processos, a acomodação e/ou resistência

a mudanças é o aspecto mais relevante deste comportamento.

Pessoas acostumadas a fazer o trabalho sempre da mesma forma e

com pouco controle, como encontramos nas pequenas empresas,

mesmo que sejam muito competentes, têm muita resistência a

implementação de novas rotinas, principalmente as de controle,

pois se sentem ameaçadas. É necessário que o gestor ou

consultor responsável pela implantação esteja atento a estes

13

problemas e procure trazer estas pessoas para dentro do

processo e fazer com se sintam úteis e participantes

diminuindo assim o sentimento de ameaça. Assim que os

envolvidos no processo entenderem que o negócio onde estão

inseridos está crescendo e que necessita de mais controle

sobre tudo que o envolve, até fatores externos, eles se

tornarão verdadeiros colaboradores e se integrarão ao

processo.

Métrica

Uma métrica é a forma de como se vai fazer uma medição.

Ela deve definir quem, quando, como, onde, forma e o motivo

pelo qual faremos a medição. Quem, no caso da métrica, é o

papel do responsável por efetuar as medições desta métrica.

Quando é o momento, dentro do processo, em que uma medição

será feita baseada na métrica. Como é a maneira que as

medições serão executadas. Onde é em que local se efetuará a

medição. A forma é o tipo de número que será medido podendo

ser inclusive uma fórmula. O motivo pelo qual faremos as

medições baseadas na métrica.

Estabelecer um programa de métricas adequado às suas

reais necessidades é extremamente importante, pois medir tem

custos. Preferencialmente deve-se incluir as métricas dentro

do processo, seja qual for, e com isso diluir os custos da

medição. Quando o processo estiver rodando e as pessoas

acostumadas a exercer as suas atividades nem perceberão as

14

medições.

As métricas fornecem grande parte dos dados necessários

para administração de um projeto de software (KOSCIANSKI,

2007). Elas devem ser a base para tomadas de decisão

eliminando-se, assim, decisões tomadas pelo achismo e por

experiências pessoais que nem sempre são as mais adequadas.

Além disso, a formação de dados históricos cada vez mais irá

contribuir para a análise, o aumento da qualidade do produto e

a correição nas decisões dos gestores.

Medição

É a execução de uma métrica, ou seja, é a coleta de dados

referente a uma métrica definida, em um determinado instante.

Ela deve registrar quem efetuou, a data, a hora e o valor

definido na métrica. A medição incluída dentro de um processo

gerará dados históricos sempre no mesmo ponto e sobre as

mesmas condições criando condições ideais para gráficos

comparativos.

Existe uma frase famosa que praticamente se transformou

em um ditado na área de gestão: “Se você não pode medir, você

não pode gerenciar” que é uma grande verdade. Imagine

gerenciar alguma coisa sobre a qual não se tem informação. A

geração, manutenção e controle de informações é fundamental

para se estabelecer, por exemplo, duração e custo de uma

determinada tarefa o que dará base para elaborar uma

estimativa de custo e tempo de execução de um projeto.

15

MATERIAL E MÉTODOS

GQM

Goal, Questions, Metrics (Figura 5) que traduzido

literalmente é Objetivos, Questões, Métricas, é uma

metodologia de elaboração de métricas baseada em uma

hierarquia que o próprio nome explica, ou seja, define-se os

objetivos e em cima destes define-se as perguntas que se quer

responder e baseados nestas define-se as métricas que irão

responder às perguntas sazonalmente e gerarão uma base

histórica que deverá ser utilizada na tomada de decisões

dentro das organizações. Fontoura (2004) diz que “GQM é uma

abordagem orientada a metas e utilizada em engenharia de

software para a medição de produtos e processos de software”Figura 5. Gráfico Demonstrativo do Método GQM

As principais vantagens desta metodologia são:

Apoia a definição top-down do processo de medição;

Ajuda na identificação de métricas úteis e relevantes;

16

Apoia a análise e interpretação dos dados coletados;

Permite uma avaliação da validade das conclusões tiradas;

Diminui a resistência das pessoas contra processos de

medição.

Objetivos/Metas

A definição das metas a serem atingidas com a elaboração

da métricas deve estar totalmente alinhado com o planejamento

estratégico da organização. Só tem sentido fazer medições se

se tiver um objetivo a alcançar. Estes objetivos podem ser os

mais variados como, por exemplo, diminuir o retrabalho,

aumentar a qualidade, diminuir o número de erros e etc.

Questões

Baseadas nos objetivos definidos as questões a serem

formuladas por esta metodologia são o que se deseja/precisa

saber para se atingir a meta a qual esta questão se

referencia. Estas perguntas devem ser claras, objetivas e

devem ser respondidas com medidas, ou seja, números que serão

gerados por uma ou mais métricas. Alguns exemplos de questões:

Quantas horas foram gastas em determinada tarefa?

Qual a quantidade de erros encontrada no projeto?

Qual o percentual de requisitos não atendido pelo

produto?

17

Métricas

As métricas, como citado, são as definições de uma

medição e devem ser elaboradas levando-se em conta as questões

previamente elaboradas. Deve-se atentar, também, para o fato

que elas serão incluídas dentro de um processo e devem ter

características que as habilitem serem reconhecidas como

atividades, para tanto. Uma métrica deve responder, sozinha ou

conjugada com outras, de forma satisfatória à pergunta a qual

ela está vinculada e deve possibilitar manter-se um

histórico de medições.

MODELO PROPOSTO

Modelo

Baseado nos estudos realizados desenvolver-se-á um modelo

de métricas essenciais para empresas com o formato definidos

no módulo cenário deste trabalho. Chega-se à conclusão que

empresas com o tamanho e a estrutura para as quais este

trabalho é destinado não possuem condições de implantar todos

os processos descritos em modelos amplamente divulgados como

CMMI e MPS.BR. Mas para se manter no mercado estas pequenas

empresas devem ter controle sobre a sua produção e devem

definir processos, pelo menos os essenciais, em todas as áreas

do conhecimento abordadas por estes modelos e procurar

aperfeiçoá-los mantendo assim um padrão de melhoria constante

18

e possibilitando até que consigam certificações nos modelos

citados.

O que se discute a seguir é um modelo de métricas

consideradas essenciais para uma organização de

desenvolvimento de software tenha um controle satisfatório

sobre os seus processos de produção e gere base histórica de

números para se tomar decisões cada vez mais acertadas nas

áreas de qualidade, produtividade, custo e tempo baseados na

metodologia GQM.

Metas/Objetivos

Como a ideia deste trabalho é sugerir métricas para as

organizações que queiram criar as suas próprias, ou estejam no

início deste processo, as metas definidas aqui são iniciais e

um pouco subjetivas de propósito para que se criem bases de

dados históricos para então se definir, no futuro, metas mais

específicas e novamente criar e alterar as métricas com o

objetivo de atingi-las. Baseadas nas experiências vividas em

empresas similares às descritas no item 'cenário' deste

trabalho, as metas aqui descritas são as principais

preocupações dos seus gestores.

1 - Diminuir custos;

2 - Aumentar a produtividade;

3 - Diminuir o retrabalho;

4 - Aumentar a qualidade;

5 - Aumentar satisfação do cliente;

19

6 - Diminuir Esforço.

Questões

As questões, definidas no método GQM, são o que é

necessário saber para se atingir as metas estabelecidas

anteriormente e vinculam-se à elas. Acredita-se que as

seguintes questões são suficientes para elaborar um conjunto

de métricas iniciais para as organizações que pretendem

implantá-las dentro de seus processos:

1.1 - Qual a relação entre custo estimado e custo efetivo

do projeto?

1.2 - Qual o custo da atividade?

1.3 - Qual a quantidade de horas de retrabalho?

1.4 - Qual o custo do retrabalho no projeto?

1.5 - Qual o custo real do projeto?

2.1 - Qual relação entre o tempo estimado e efetivo da

atividade?

2.2 - Qual relação entre o tempo estimado e efetivo do

projeto?

3.1 – Qual a relação entre horas de trabalho e horas de

retrabalho?

4.1 - Qual o número de erros encontrados na atividade?

4.2 - Qual o número de erros graves encontrados na

atividade?

4.3 - Qual o número de requisitos encontrados depois da

fase de levantamento?

20

5.1 - Qual o número de erros encontrados depois de da

entrega?

5.2 - Qual a relação de erros encontrados antes e depois

da entrega?

5.3 - Qual o percentual de requisitos não atendidos?

5.4 - Qual o índice de satisfação do cliente por

requisito?

6.1 - Qual o número de horas trabalhadas na atividade?

6.2 - Qual o número de horas trabalhadas no projeto?

6.3 - Qual a relação entre horas estimadas e horas

trabalhadas?

Métricas

A medição de software tem se tornado crucial na busca damelhoria do processo de software, na avaliação doandamento de projetos e também tem auxiliado na tomadade decisões estratégias da organização (SANTOS).

Após a definição das questões as métricas praticamente

aparecem sozinhas ao gestor que as está elaborando. As

definições de métricas que responderão às questões elaboradas

anteriormente são definidas assim:

21

22

23

24

25

CONCLUSÕES

A metodologia GQM (Goal-Questions-Metrics) é uma grande

facilitadora no processo de elaboração de métricas. Os

gestores e organizações que já a utilizam são testemunhas dos

benefícios e da aceleração e correição dos resultados

alcançados. Após a definição de metas e das questões a elas

atreladas, as métricas praticamente brotam como se fossem

plantas em terreno bem adubado e bem umedecido.

Sugere-se que as MPEs que tiverem acesso a este estudo

implementem este modelo como start, ou seja, uma iniciação a

aplicação de métricas, adaptando-as a sua realidade e a seus

processos. Cada organização, mesmo as que seguem padrões

definidos e consagrados, é única e deve conhecer os padrões

para melhor selecionar o que lhe é útil ou essencial para que

formem sua própria metodologia e padrões e os aprimorem com o

passar do tempo melhorando assim e cada vez mais a qualidade

de seus produtos.

REFERÊNCIAS

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2.ed . São Paulo: Novatec,2007. 391 p.

ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves. Qualidade de Software. São Paulo:

26

Prentice Hall, 2001. 303 p.

MAXIMO FILHO, Paulo. Combinando a Metodologia Seis Sigma com aGestão do Conhecimento: Um estudo de caso na GE CELMA. Rio de Janeiro: Ibmec, 2006. Disponível em: <http://www.ibmecrj.br/sub/RJ/files/dissert_mestrado/ADM_paulommaximo_nov.pdf>. Acesso em: 10 set. 2012, 10:30.

FONTOURA, Lisandra M.; PRICE, Roberto T. Usando GQM para Gerenciar Riscos em Projetos de Software. Belo Horizonte: UFMG, 2004. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/sbes/2004/004.pdf>. Acesso em: 05 set. 2010, 15:30.

NARDI, Julio Cesar; FALBO, Ricardo de Almeida. Uma Ontologia de Requisitos de Software. Vitória: UFES, 2006. Disponível em:<http://www.fernandoans.site50.net/curso/curso04/OntologiaER.pdf>. Acesso em: 05 set. 2012, 15:30.

COVATTI, Andressa. MIBCIS – Método de Integração entre o BSC, CMMI e Six Sigma utilizando GQM no suporte a definição de métricas. Porto Alegre: PUC-RS, 2007. Disponível em: <http://tede.pucrs.br/tde_busca/arquivo.php?codArquivo=2293>. Acesso em: 22 ago. 2012, 11:30.

ANTUNES, Ernani José . Gerência de Projetos. Rio de Janeiro: UCB, 2010. Disponível em: <http://ucbweb2.castelobranco.br/webcaf/arquivos/20429/11316/gestA_o_de_projeto_1_.doc>. Acesso em: 15 ago. 2012, 20:00.

SANTOS, Viviane A.; SOUZA, Jerffeson Teixeira de; ANDRADE, Tarciane de Castro. Um Catálogo de Padrões de Métricas de Software para Micro e Pequenas Empresas. Ceará: UECE. Disponível em: <http://www.larces.uece.br/~jeff/padroes/vivianeWW.pdf>. Acesso em: 15 set. 2012, 21:00.

27

MOTTA, Fernando Claudio Prestes. Cultura e Organizações no Brasil. São Paulo: FGV, 1996. Disponível em: <http://www.eaesp.fgvsp.br/AppData/GVPesquisa/P00159_1.pdf>. Acesso em: 14 ago. 2012, 9:00.

28