Gestão de Software

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Catlica de Braslia UCB

Mestrado em Informtica
Qualidade de Software
Processo de Implantao de Gesto de Qualidade de

Software em Empresas Nacionais:
O Estudo de Caso do Tribunal de Contas da Unio
Toms Roberto Cotta Orlandi
Resumo
Processo de Implantao de Gesto de

Qualidade de Software em Empresas
Nacionais:
O Estudo de Caso do Tribunal de Contas da
Unio
A proposta deste trabalho demonstrar a viabilidade da implantao de um processo

contnuo de avaliao de qualidade de software em empresas brasileiras, apresentando a
abordagem GQM Goal, Question, Metric , situando-a no contexto de outras abordagens
de avaliao e qualidade de software, que atende no s as expectativas em relao uma
melhora de qualidade dos produtos, mas tambm a um incremento na produtividade das
equipes de trabalho.
Palavras-chave
abordagem GQM, CMM, Fbrica de Experincia, ISO, QIP, Qualidade de software,
SPICE.
Toms Roberto Cotta Orlandi

Abstract
Orientador
Prof. Dr. Walclio L. Melo
The objective of this article is to show the viability of introducing a continuos evaluation
process of software quality in Brazilians companies, presenting the GQMGoal, Question,
Metric approach, comparing it with others softwares quality approaches, attending the
wishes of a better software products quality and best productivity of the team working.
Keywords
CMM, Experience Factory, GQM Approach, ISO, QIP, Software Quality, SPICE
Braslia (DF), dezembro de 2000
1
I. Introduo
II. Caracterizao dos Produtos e dos Processos
Objetivos Gerais :
O presente trabalho tem por objetivo apresentar um exemplo da abordagem GQM
Goal, Question, Metric , situando-a no contexto de outras abordagens de avaliao e
qualidade de software como ISO,CMM, SPICE e QIP. A implantao da abordagem GQM
em empresa nacional, ser mostrada atravs da utilizao de um processo padronizado de
desenvolvimento, converso e manuteno de software.
Este captulo visa apresentar os modelos de qualidade de software mais aplicados

em empresas ou setores, produtores de software, que de algum modo se preocupam em
implementar e manter procedimentos de avaliao e medio, visando uma melhora na
qualidade e produtividade dos projetos e sistemas desenvolvidos pela empresa.
O Modelo ISO 12207 de Qualidade

A proposta demonstrar a viabilidade da implantao de um processo contnuo de
avaliao de software nas empresas nacionais, que atenda no s as expectativas em relao
uma melhora de qualidade dos produtos, mas tambm a um incremento na produtividade
das equipes de trabalho, incorporando naturalmente a cultura de produzir software com
testes, inspees e medies de resultados.
Ser tambm demonstrada a viabilidade da manuteno de um programa
permanente de qualidade de software, atravs do treinamento, implantao e aplicao da
abordagem GQM, visando uma melhora contnua na qualidade e na produtividade de
sistemas. Como produto final so gerados modelos quantitativos, baseados em dados
captados, que viabilizam uma anlise da qualidade dos software produzidos, possibilitando
uma comparao qualitativa do processo de desenvolvimento de sistemas com organizaes
externas.
Em decorrncia da implantao dessa abordagem, demonstra-se a implementao e
a manuteno de uma estrutura, separada logicamente do desenvolvimento de software, a
Fbrica de Experincias. A Fbrica de Experincias (Experience Factory)[1] tem por
objetivo armazenar as experincias dos projetos desenvolvidos, em termos de solues e
implementaes adotadas, para que as equipes possam fazer reuso posterior das solues e
dos cdigos j desenvolvidos. As solues empacotadas na Fbrica de Experincias
podero ser utilizadas tambm por organizaes semelhantes estudada, ou seja, empresa
nacional pblica ou privada.
Objetivos Especficos:
A norma ISO/IEC 12207 objetiva auxiliar organizaes na definio de seus

processos de software oferecendo uma guia para definio das atividades e tarefas a serem
desempenhadas durante as principais etapas que envolvem a construo de um produto de
software. A norma agrupa processos de software em trs grandes classes processos
fundamentais, processos de apoio e processos organizacionais.
A categoria de processos fundamentais compreende os processos que executam as
principais funes relacionadas ao ciclo de vida de software. Processos de apoio servem
como auxiliares ao processo fundamental de construo, contribuindo para o sucesso e a
qualidade do produto gerado. Processos organizacionais so responsveis pelo
acompanhamento do desenvolvimento, compreendendo processos para gerncia, melhoria
da qualidade, infra-estrutura e treinamento.
Cada processo inserido nestas classes est dividido em um conjunto de atividades
que, por sua vez, se dividem em um conjunto de tarefas para sua realizao. Contudo, a
norma no especifica detalhes de como implementar ou executar estas tarefas e atividades.
Este um dos motivos pelo qual o presente trabalho no abordar o modelo ISO 12207 de
qualidade pois, no contexto de empresas nacionais em questo, necessitamos especificar os
detalhes de como implementar processos de qualidade de software nas organizaes.
O Modelo SPICE (ISO/IEC 15504) de Qualidade
Apresentar claramente a abordagem GQM e sua forma de aplicao;

Situar a abordagem GQM no contexto geral da qualidade de software;
Mostrar a viabilidade da implantao da abordagem GQM em empresas nacionais
(utilizando o estudo de caso do Tribunal de Contas do Distrito Federal TCDF);
Apresentar uma forma das equipes de trabalho incorporarem naturalmente, no
desenvolvimento e manuteno de software, as atividades de testes, inspees e
medies de resultados;
Mostrar o conceito e a forma de implementao da Fbrica de Experincias.
A iniciativa de se estabelecer um padro internacional para melhoria de processos

de software levou a ISO/IEC a aprovar em 1993 um novo grupo de trabalho, denominado
WG10, a partir do qual se organizou o projeto SPICE (Software Process Improvement and
Capability dEtermination) (ISO/IEC 15504-8, 1996) [5]. Analogamente ao CMM, o
objetivo principal do SPICE a elaborao de um padro ou infra-estrutura (framework)
para avaliao de processos de software e para a determinao de sua capacitao ISO/IEC 15504.
A futura norma ISO/IEC 15504 define processos e prticas que podem ser
implementados para estabelecer e aprimorar a capacidade de aquisio, desenvolvimento,
manuteno, operao e suporte de software em organizaes. Estas prticas so
organizadas utilizando-se uma arquitetura que combina duas perspectivas: uma perspectiva
funcional (anloga perspectiva da norma ISO/IEC 12207), compreendendo quais os
processos que devem existir numa organizao e uma outra perspectiva que avalia o nvel
de capacitao de cada um destes processos (anloga ao CMM). O uso da norma permite
que as organizaes possam perceber a existncia ou no de processos especficos, bem
como a capacitao dos que existem, traando caminhos para a melhoria.
crises. Durante as crises, normalmente, so abandonadas as fases de planejamento, havendo

um incremento exagerado e desordenado das etapas de codificao e teste.
Para esse nvel, o CMM no apresenta reas chave. A caracterizao do
comportamento no nvel 1 colocado apenas como base de comparao para os demais
nveis.
O Modelo CMM
O Capability Maturity Model (CMM) para Software, compilado pelo Software
Engineering Institute SEI da Carnegie Mellon University (EUA), pode ser entendido
como um modelo para avaliao do grau de maturidade das organizaes quanto
capacidade produtiva de software. [13]
O CMM representa uma proposio de recomendaes para empresas, cujo negcio
seja a produo de software, que pretendam incrementar a capacidade (ou qualidade) do
processo de desenvolvimento de sistemas.
O modelo apresentado pelo CMM no se preocupa em como a organizao
implementa, mas, antes, busca descrever o qu se espera do processo produtivo de
software.
O modelo CMM foi utilizado neste trabalho como caminho a ser seguido para
nortear as aes de implementao de um modelo de qualidade de software em
organizaes brasileiras, pois, trata-se de um modelo consagrado e utilizado mundialmente
por organizaes produtoras de software.
O CMM classifica as organizaes produtoras de software em cinco grupos (ou
nveis) de maturidade, identificando, para cada grupo, as reas chave do processo de
desenvolvimento de sistemas que devem ser observadas na busca da melhoria da
capacidade produtiva. Cada rea chave possui objetivos que precisam ser alcanados para
que a organizao seja considerada como tendo atingido determinado nvel.
Os cinco nveis de maturidade propostos pelo CMM, em grau crescente, so:
inicial; repetitivo; definido; gerenciado; e otimizado.[13]
Nvel 1 - Inicial
Nesse nvel, o processo de produo de software efetuado de maneira emprica e
ocasionalmente, at mesmo, de forma catica. Poucos processos so definidos e o sucesso
dos projetos depende de esforos individuais e atitudes hericas dos desenvolvedores.
Uma caracterstica das organizaes classificadas nesse nvel o comprometimento
alm da capacidade. A dificuldade da organizao em cumprir os compromissos
estabelecidos acompanhada pela sobrecarga do corpo tcnico, que fica impossibilitado de
seguir as prticas recomendadas para a engenharia de software, gerando, ento, sucessivas
Nvel 2 - Repetitivo
Nesse nvel de maturidade, existe um gerenciamento bsico de projetos com a
finalidade maior de acompanhar custos e cronogramas. Porm, o processo aplicado ao
desenvolvimento de novos projetos constitui-se basicamente na repetio de prticas j
experimentadas com sucesso em projetos similares anteriormente desenvolvidos.
Os processos de desenvolvimento podem, assim, ser diferentes de projeto para
projeto em organizaes considerados no nvel 2. O que deve existir, porm, uma poltica
que sirva como guia no estabelecimento de uma gerncia apropriada de processos.
Os compromissos assumidos, ento, passam a ser mais realistas, pois baseiam-se,
agora, em resultados observados em projetos anteriores. A gerncia de projetos pode
acompanhar melhor os custos, o cronograma e o atendimento aos requerimentos.
As reas chave para o nvel 2 esto focadas nas prticas que concernem ao
gerenciamento de projetos:
gerncia de requisitos;
planejamento do projeto;
acompanhamento do projeto e de desvios;
gerenciamento de subcontratados;
controle de qualidade; e
gerncia de configuraes.
Nvel 3 - Definido
No nvel definido, um processo padro (ou vrios) para desenvolvimento e
manuteno de software documentado e usado por toda a organizao. Esse padro inclui
as atividades de engenharia e gerenciamento de software integrados em um todo coerente.
O processo padro utilizado (e modificado, se necessrio) para auxiliar os gerentes
e desenvolvedores em uma produo mais eficiente. Um programa de treinamento
implementado em toda a organizao para assegurar que o corpo tcnico e os gerentes
adquiram o conhecimento e habilidade necessrios execuo de suas tarefas.
A medida que acontecem, os projetos utilizam-se do processo padro e fazem
adaptao desse modelo para ajust-lo s suas peculiaridades. Sendo, ento, esse processo
ajustado o que realmente usado nas atividades do projeto.
O que difere o nvel 3 do nvel anterior, alm das reas chave relacionadas a seguir,
basicamente, o fato de existir neste nvel o processo padro definido, documentado,
integrado, ajustado e, principalmente, seguido por toda a organizao.
O nvel 3 do CMM pode ser resumido pelas palavras padro e consistncia, uma
vez que, nesse nvel, as atividades de engenharia e gerenciamento no processo produtivo de
software so estveis e repetitivas. Com uma linha de produo estabelecida, os custos, o
cronograma e as funcionalidades esto sob controle e qualidade do software melhor
acompanhada.
As reas chave definidas para o nvel 3 esto voltadas aos aspectos da organizao e
do projeto, no sentido de prover uma infra-estrutura que possibilite a institucionalizao de
um efetivo processo de engenharia e gerncia de software para todos os projetos. So reas
chave para o nvel 3:
foco no processo da organizao (ou estabelecimento de responsabilidades na
organizao para atividades relativas produo de software);
definio do processo para a organizao;
programa de treinamento;
gerenciamento integrado;
engenharia de produtos;
coordenao intergrupos (ou interao entre grupos de engenharia de software);
reviso de pares.
Nvel 5 - Otimizado
Nvel 4 - Gerenciado
Nesse nvel, passam a ser coletadas e analisadas mtricas detalhadas relativas ao
processo e qualidade do produto para acompanhamento e controle do processo. Nesse
nvel, processo e produto so quantitativamente entendidos e controlados.
No nvel gerenciado, a organizao define objetivos de qualidade que devem ser
alcanados para produtos e processos. As atividades de produo de software mais
importantes so acompanhadas por meio de um programa de medidas da organizao afim
de que possam ser observadas a produtividade, a qualidade, etc. Um banco de dados para a
organizao como um todo usado para coletar e analisar os dados disponveis extrados
dos projetos. O processo de software equipado com um processo de coleta de medidas
consistente e bem definido.
O nvel 4 do CMM pode ser resumido como sendo quantificado e previsvel
porque os processos so medidos e as operaes so realizadas dentro de limites
quantitativos. Esse nvel permite que a organizao trabalhe com segurana na previso do
desempenho dos processos e da qualidade dos produtos.
As reas chave para o nvel 4 esto direcionadas ao entendimento quantitativo do
processo e do produto:
gerenciamento quantitativo do processo; e
gerenciamento da qualidade do produto.
No nvel otimizado, toda a organizao est voltada para um contnuo processo de

melhoria. A organizao busca identificar, de forma pr-ativa, os pontos fortes e fracos do
processo, com o objetivo de evitar erros e melhorar a eficincia. Dados reais de processos
so usados para anlise da relao custo/benefcio, para implementao de novas
tecnologias ou para propor mudanas ao processo produtivo.
As equipes de software em organizaes no nvel 5 trabalham na anlise de defeitos
do processo afim de determinar suas causas, avaliar o processo e prevenir manifestaes de
erros conhecidos e recorrentes, e, ainda, disseminar os conhecimentos adquiridos pela
organizao.
Em qualquer sistema, existe um desperdcio contnuo, em forma de retrabalho,
simplesmente por causa de imprevistos. Esforos no sentido de eliminar esses desperdcios
resultam em mudanas no sistema pela reconduo dessas causas comuns de ineficincia.
Embora esses esforos para reduzir desperdcios ocorram em todos os nveis de maturidade,
essa preocupao constitui o foco do nvel 5.
O nvel 5 do CMM pode ser caracterizado como de melhoria contnua porque as
organizaes identificadas no nvel 5 esto continuamente empenhadas em melhorar a
capacidade de seus processos. A melhoria pode surgir tanto em funo do progresso do
prprio processo quanto da aplicao de novas tecnologias e mtodos. A aplicao de novas
tecnologias ou mudanas no processo so planejadas e gerenciadas como tarefas rotineiras.
As reas chave que constituem o nvel 5 buscam enfocar os assuntos que os projetos
precisam observar para promover um incremento contnuo e mensurvel da qualidade do
processo de software. So as seguintes as reas chave para o nvel otimizado:
preveno de erros;
gerenciamento de mudana tecnolgica; e
gerenciamento de mudanas no processo.
Como mostra a figura 1, o CMM, pode ser representado como uma estrutura de
cinco nveis de maturidade:
Executar (Do): executar a implementao do plano e a coleta de dados.

Verificar (Check): verificar a melhoria do desempenho usando os dados
coletados dos processos e tomando aes corretivas necessrias.
Agir (Act): atuar no sentido de padronizar as melhorias e incorpor-las ao
processo.
Otimizado
5
Gerenciado
4
Definido
3
Repetitvel
2
Inicial
1
preveno de erros;
gerenciamento de mudana tecnolgica;
e
gerenciamento de mudanas no processo
gerenciamento quantitativo do processo; e

gerenciamento da qualidade do produto.
foco no processo da organizao;

definio do processo para a organizao;
programa de treinamento;
gerenciamento integrado;
engenharia de produtos;
coordenao intergrupos;
reviso de pares.
gerncia de requisitos;
planejamento do projeto;
acompanhamento do projeto e
de desvios;
gerenciamento de
subcontratados;
controle de qualidade; e
gerncia de configuraes.
Por sua vez, o QIP desenvolve-se por meio dos seguintes passos:[1]
Caracterizar: conhecer o ambiente com base nos dados e modelos disponveis e na
instituio. Estabelecer os fundamentos com os processos existentes na organizao e
caracteriz-los criticamente.
Definir os objetivos: com base na caracterizao inicial e nas capacidades estratgicas
da organizao, definir com objetivos quantificveis o que seriam projetos bem
sucedidos e avaliar o desempenho e melhoria da organizao. As excees aceitveis
so definidas com base nos fundamentos estabelecidos no passo de caracterizao.
Escolher os processos: com base na caracterizao do ambiente e dos objetivos
definidos, escolher os processos apropriados para melhoria bem como as ferramentas e
mtodos de apoio, certificando-se que esses sejam consistentes com os objetivos.
Executar: executar os processos elaborando os produtos e provendo retorno, a partir do
projeto, dos dados que esto sendo coletados para avaliao do alcance dos objetivos.
Analisar: ao final de cada projeto especfico, analisar os dados e informaes
acumuladas para avaliar as prticas correntes, identificar problemas, registrar achados, e
fazer recomendaes para melhoria de futuros projetos.
Empacotar: Consolidar a experincia adquirida em forma de refinamento do modelo
praticado ou mesmo pela adoo de novos modelos e, ainda, por meio de outras formas
de estrutura de conhecimento alcanadas no ltimo ou em processos anteriores e
armazen-las em uma base de experincias, disponvel para uso futuro.
Uma caracterizao apropriada e sem ambigidades do ambiente um
pr-requisito para a aplicao correta do paradigma. Essa caracterizao requer a
classificao minuciosa do projeto, permitindo a identificao de classes de projetos com
caractersticas e objetivos similares. Assim, pode-se estabelecer o ambiente adequado ao
projeto corrente. Com a correta caracterizao obtm-se um contexto para a definio de
objetivos, para a reutilizao de experincias e produtos, para a seleo de processos, para a
avaliao e comparao de resultados, e para uma maior exatido nas previses.
Figura 1
O Paradigma de Aperfeioamento da Qualidade - QIP

O Quality Improvement Paradigm QIP (ou Paradigma do
Aperfeioamento da Qualidade), desenvolvido por Victor Basili e outros [1], o resultado
da aplicao do mtodo cientfico para resoluo do problema de melhoria da qualidade de
software. O QIP est diretamente relacionado ao Ciclo Plan/Do/Check/Act (PDCA) de
Shewart-Deming[15] largamente utilizado na indstria para implementao de planos de
gerenciamento da qualidade.
O Processo do Paradigma de Aperfeioamento da Qualidade
A abordagem PDCA articulada em quatro fases: [15]

Planejar (Plan): Definir os objetivos e metas do aperfeioamento da qualidade,
determinar mtodos para alcanar esses objetivos e preparar um plano de
implementao.
H um grande nmero de caractersticas de projetos e de ambiente que

afetam o processo de desenvolvimento e o produto de software, tais como:
fatores de pessoal - nmeros de empregados, nvel de especializao, organizao de
grupo, experincias;
fatores relacionados ao problema - domnio da aplicao, suscetibilidade a mudana,
limites do problema;
fatores do processo - modelos de processo, mtodos, tcnicas, ferramentas, linguagem
de programao, outros documentos;
fatores do produto - implantao/entrega, tamanho do sistema, qualidades requeridas;
10
fatores dos recursos - mquinas de produo e desenvolvimento, tempo calendrio,

oramento, software existente.
A Fbrica de Experincia
A definio realista dos objetivos importante para a caracterizao do

ambiente. preciso estabelecer modelos e objetivos para os processos e para os produtos.
Esses objetivos precisam ser mensurveis, dirigidos pelos modelos, e definidos para uma
variedade de perspectivas, tais como, a do usurio, do cliente, do projeto, da organizao,
etc.
A abordagem GQM - Goal/Question/Metric (demonstrada adiante) [2]
o mecanismo usado pelo Quality Improvement Paradigm para definir e avaliar um conjunto
de objetivos operacionais usando mtricas. Essa abordagem representa uma sistemtica
para ajuste e integrao de objetivos com modelos de processos, produtos e perspectivas de
qualidade de software, baseadas em necessidades especficas do projeto e da organizao.
Existe uma variedade de dados que podem ser coletados:
Dados sobre recursos - incluem esforo por atividade, fase, tipo ou pessoal, tempo de
computador, tempo calendrio, etc;
Dados de mudanas e falhas dizem respeito a mudanas e falhas por vrios esquemas
de classificao;
Mtricas do processo relativas definio e conformidade dos processos, e aos
dados concernentes ao entendimento do domnio da aplicao;
Dados do produto quanto s caractersticas lgicas e fsicas do produto e quanto
utilizao e contexto da informao.
Como mostra a figura 2, o ciclo QIP, pode ser representado da seguinte forma:
Empacotar
Caracterizar
Analisar
Definir objetivos
Escolher processo
Executar
Figura 2
11
O QIP baseia-se na idia de que o aperfeioamento do processo e do

produto de software requer uma acumulao contnua de experincias (aprendizado) em
formato que pode ser efetivamente entendido e modificado (modelos de experincias) em
um repositrio integrado (base de experincias) que pode ser acessado e modificado em
conformidade com as necessidades do projeto corrente (reutilizao). Para apoiar o
paradigma de aperfeioamento foi desenvolvida um estrutura distinta do desenvolvimento
de software denominada Fbrica de Experincias (Experience Factory EF).[1]
A Fbrica de Experincias uma estrutura fsica e/ou lgica que apoia o
desenvolvimento de sistemas por meio da anlise e sintetizao de todos os tipos de
experincias, agindo como um repositrio para essas experincias e fornecendo-as a outros
projetos na medida da demanda, representa um paradigma de mudana do pensamento
corrente de desenvolvimento de software. Ela separa os tipos de atividades que precisam
ser executadas em diferentes estruturas, reconhecendo que elas verdadeiramente
representam processos e enfoques diferentes.
Assim, identificam-se duas unidades organizacionais distintas: a
Organizao Projeto, para o desenvolvimento de sistemas; e a Fbrica de Experincias, para
o empacotamento de conhecimentos adquiridos. Na Organizao Projeto, so resolvidos os
problemas, na Fbrica de Experincia, so entendidas as solues e empacotadas as
experincias para futura reutilizao.[1]
O Processo da Fbrica de Experincias

A Fbrica de Experincias representa o grupo que trabalha na base do
conhecimento da engenharia de desenvolvimento de software como um bem da corporao,
enquanto a Organizao Projeto representa o grupo cujo trabalho usar aquele
conhecimento para produzir os mais avanados produtos da corporao.
A Organizao Projeto caracteriza o projeto e seu ambiente, define os
objetivos para o projeto e escolhe o processo apropriado dadas as caractersticas e
objetivos. O suporte ao projeto provido pela Fbrica de Experincias pela articulao das
caractersticas, formulao de objetivos e seleo do conjunto apropriado de experincias
passadas para uso no projeto. [1]
Pela abordagem da Fbrica de Experincias, a reutilizao no representa
apenas o reaproveitamento de cdigo mas de todos os tipos de experincias e do contexto
que envolve essas experincias, reconhecendo que as experincias nem sempre so
reutilizveis como foram concebidas, antes elas precisam ser ajustadas e empacotadas para
tornar mais fcil o seu acesso e reutilizao.
Na prtica, a abordagem QIP/EF implementada colocando-se
primeiramente a organizao em seu lugar, a partir de sua caracterizao. Isso significa a
coleta de dados para estabelecimento dos fundamentos (baselines) e avaliao dos pontos
fortes e fracos da organizao a fim de se obter o enfoque nos negcios e objetivos da
empresa para o processo de melhoria. A coleta inicial de dados crtica tambm para a
definio da qualidade do produto que deveria ser aprimorada pelo programa.
Dessa forma, a organizao define em si mesma um contnuo
aperfeioamento, mesmo se o nvel de maturidade no for muito alto, porque ela aprende a
partir do seu prprio negcio, no de um modelo de processo ideal, externamente
12
concebido. Melhorias no processo sero baseadas na compreenso do relacionamento entre

processo e produto na prpria organizao. A introduo de novas tecnologias ser
motivada por problemas locais e o corpo tcnico estar mais disposto a utiliz-las.
A abordagem GQM
O Modelo Goal Question Metric (GQM)

Esta apresentao da abordagem Goal/Question/Metric (GQM), utilizada
como abordagem na definio do processo de desenvolvimento de software, toma por base
o texto de Victor R. Basili, Gianluigi Caldiera e H. Dieter Rombach [2]. Os dois primeiros
do Institute for Advanced Computer Science, da University of Maryland (EUA), e o ltimo
da FB Informatik, da Universitat Kaiserslautern (Alemanha).
Como em qualquer disciplina de engenharia, o desenvolvimento de
software requer um mecanismo de mensurao para avaliao e retorno. O procedimento de
medir uma forma de criar uma memria corporativa e um auxlio na resposta de vrias
questes associadas ao estabelecimento de um processo de software.
Um processo de medidas estabelecido auxilia no planejamento de novos
projetos, na determinao de pontos fortes e fracos de produtos e processos, na
racionalidade para adoo ou refinamento de tcnicas em uso, e ainda, na avaliao da
qualidade de processos ou produtos especficos. Medir tambm ajuda, durante o curso de
um projeto, a avaliar o seu progresso, tomar as medidas corretivas baseadas nesse
julgamento, e avaliar o impacto de tal ao.
Algumas questes que poderiam, por exemplo, ser respondidas a partir de
um sistema de medida, seriam :
Qual o custo de um novo projeto?
Qual a freqncia de certos tipos de erros?
Qual o impacto da aplicao de determinada tcnica na produtividade dos projetos?
De acordo com vrios estudos realizados sobre a aplicao de mtricas e
modelos em ambiente industrial, o processo de medida para trazer resultados precisa ser:
voltado para objetivos especficos;
aplicado a todo o ciclo de vida dos produtos, processos e recursos;
adaptado s caractersticas e ao contexto da organizao, do ambiente e dos objetivos.
Como na figura 3, o modelo hierrquico GQM, pode ser representado da seguinte forma:
OBJETIVO 1
QUESTO
MTRICA
OBJETIVO 2
QUESTO
MTRICA
QUESTO
MTRICA
A abordagem GQM parte da premissa de que para uma organizao

adotar um processo de medida definitivo necessrio primeiramente estabelecer os
objetivos da prpria organizao e de seus projetos, definir esses objetivos
operacionalmente e, finalmente, criar um ambiente de apoio capaz de interpretar os dados
comparando-os com os objetivos estabelecidos. Assim, importante deixar claro, pelo
menos em termos gerais, qual a necessidade de informaes da organizao, se essas
informaes podem ser quantificadas e em que momento podem ser colhidas, e se podem
ser analisadas em funo dos objetivos.[2]
A abordagem foi definida originalmente para avaliao de defeitos em um
conjunto de projetos no ambiente da NASA Goddard Space Flight Center. A aplicao
envolveu um conjunto de estudos de casos e foi expandida para incluir vrias abordagens
experimentais. Embora a abordagem tenha sido usada originalmente para definir e avaliar
os objetivos de um projeto especfico, seu uso foi expandido para contextos maiores.
A abordagem foi usada como um passo dentro de outra tcnica, o Quality
Improvement Paradigm (discutido anteriormente neste trabalho), processo de melhoria da
qualidade que se utiliza de um ambiente operacional restrito, a Fbrica de Experincia
(Experience Factory), que pode, por sua vez, ser entendida como um ambiente
experimental com o objetivo de produo e/ou avaliao de software e processos para uso
nos demais projetos.
Neste trabalho, a utilizao de todas estas tcnicas, ser norteada pelo
modelo CMM de qualidade de software. A correta utilizao destas tcnicas permitir
organizao galgar os nveis de maturidade, atravs da realizao das suas reas chave para
cada nvel alcanado.
O resultado da aplicao da abordagem GQM a especificao de um
sistema de medidas objetivando um conjunto particular de casos e de regras na
interpretao dos dados medidos.
O modelo de mensurao resultante possui trs nveis:[2 - p 3]
1. Nvel Conceitual: no qual definido um objetivo (Goal) para o objeto a ser medido
levando-se em conta o modelo de qualidade que se pretende atingir e o ponto de vista
da observao. Podem ser objetos de medida:
Produtos - quaisquer documentos e produtos que so gerados durante o ciclo de vida
do sistema: especificaes, projetos, programas, lotes de testes etc.
Processos - atividades relacionadas ao desenvolvimento de software normalmente
associadas ao dispndio de tempo: fase de especificao, de projeto, de teste, de
interao etc.
Recursos - itens consumidos no processo para gerar os produtos: pessoal,
equipamentos, software, espao fsico etc.
2. Nvel Operacional: diz respeito a um conjunto de questes (Question) usado para
caracterizar a forma de julgamento e garantir que o objetivo, definido no modelo, ser
atingido. As questes tentam caracterizar o objeto a ser medido (produto, processo ou
recurso) com respeito a um padro de qualidade e buscam identificar a qualidade desse
objeto a partir de determinado ponto de vista.
MTRICA
Figura 3
13
14
3. Nvel Quantitativo: representa os dados que sero apurados/medidos (Metric). Um

conjunto de dados associado s questes formuladas a fim de que sejam traduzidas
quantitativamente. Esses dados podem ser objetivos ou subjetivos.
- Objetivos - se dependem apenas do objeto que est sendo medido e no do ponto de
vista em que so tomados. Por exemplo: nmero de verses de um documento,
horas de pessoal gastas em determinada tarefa, tamanho de um programa etc.
- Subjetivos - se dependem, alm do prprio objeto que est sendo medido, do ponto
de vista em que ser analisada a medida. Exemplo: facilidade de leitura de um texto,
nvel de satisfao do usurio etc.
A segunda fonte de informaes a descrio dos processos e produtos

da organizao, ou, pelo menos, daqueles que esto dentro do escopo do programa de
medidas que se pretende efetuar. A partir desse fonte, com a especificao dos modelos de
processos e produtos, dentro da maior formalidade possvel, deriva-se a coordenada do
objeto para o objetivo em questo.
A terceira fonte de informaes o modelo do negcio da organizao,
que fornece a coordenada ponto de vista. evidente que nem todos os assuntos e
processos so relevantes para todos os pontos de vista na organizao. Assim, h que se
fazer uma anlise da relevncia dos objetivos para a organizao, antes de se considerar
concluda a lista de objetivos.
Dessa forma, conclui-se a definio dos objetivos para o modelo GQM,
tomando-se em conta a estrutura e os objetivos da organizao. A partir da especificao
de cada objetivo podem-se derivar questes significantes que quantificam o objetivo.
Geralmente, so feitos pelo menos trs grupos de questes:
Assim, um modelo GQM uma estrutura hierrquica que inicia com a

definio de um objetivo (goal), especificando o propsito da medio, os objetos e
aspectos desses objetos que sero avaliados, e o ponto de vista em que as medidas sero
analisadas. O objetivo , ento, refinado em diversas questes (question). Cada questo ,
por sua vez, delineada nas mtricas (metric).
H que se observar que uma mesma mtrica pode ser usada para
responder diferentes questes de um mesmo objetivo; diversos modelos GQM podem,
tambm, ter questes e mtricas em comum, desde que seja assegurado que quando da
coleta das mtricas sejam observados os diversos pontos de vista a que se destinam, pois a
mesma medida pode assumir valores diversos dependendo do ponto de vista em que ser
analisada.
O processo GQM
Um modelo GQM desenvolvido a partir de um conjunto de objetivos
acerca de qualidade e/ou produtividade definidos para a organizao, para a diviso ou para
o projeto, tais como satisfao do usurio, entrega de servio no prazo, melhoria de
desempenho.[2 p 5]
A partir da identificao dos objetivos e com base em modelos do objeto
em avaliao, derivam-se questes que possam definir esses objetivos de forma mais
completa. Por exemplo, se o objetivo caracterizar um software quanto a determinadas
qualidades (e.g., portabilidade), ento faz-se necessria a escolha de um modelo para o
produto que qualifique esses interesses (e.g., relao de caractersticas funcionais que
precisam ser implementadas para diferentes arquiteturas).
O prximo passo consiste em especificar as medidas que devem ser
coletadas a fim de responder s questes e acompanhar a conformidade dos produtos e
processos aos objetivos. Por fim, h que se desenvolver os meios de coleta dos dados,
incluindo-se mecanismos de avaliao e anlise.
O processo de identificao de objetivos crtico para o sucesso da
aplicao da abordagem GQM, e ser apoiado por passos metodolgicos especficos. Para a
consecuo de um objetivo concorrero trs fontes bsicas de informao[2 p 6].
A primeira fonte diz respeito poltica e estratgia da organizao que
aplica a abordagem GQM. A partir dessa fonte, com a anlise da poltica da corporao,
dos planos estratgicos e, ainda, levando-se em conta os interesses relevantes na
organizao, derivam-se o aspecto e o propsito para o objetivo a ser perseguido.
15
G 1. Como se pode caracterizar o objeto (produto, processo ou recurso) com o

respeito ao objetivo global de determinado modelo GQM?
Exemplo:
Q 1: Qual o prazo corrente no atendimento s solicitaes de mudanas num
sistema em manuteno?
Q 2: Existe um processo (documentado) no atendimento s solicitaes de
mudanas?
G 2. Como se podem caracterizar os atributos relevantes do objeto em observao
num modelo GQM especfico?
Exemplo:
Q 1: Qual o desvio do prazo no atendimento de solicitaes em funo do
estimado?
Q 2: O desempenho da equipe no atendimento de solicitaes vem melhorando?
G 3. Como podem ser avaliadas as caractersticas do objeto que so relevantes com
respeito ao aspecto tratado no modelo GQM?
Exemplo:
Q1: O desempenho tem sido satisfatrio sob o ponto de vista do gerente de
projeto?
Q2: H melhoria visvel no desempenho?
Uma vez que as questes tenham sido formuladas, deve-se proceder a associao
destas com as mtricas apropriadas. Diversos fatores devem ser considerados, dentre eles:
Volume e quantidade dos dados existentes - deve-se buscar maximizar o uso das
fontes de dados existentes, desde que estejam disponveis e sejam confiveis.
Maturidade dos objetos em medio - devem-se aplicar medidas objetivas para
objetos com maior nvel de maturidade, e avaliaes subjetivas quando se trabalha
com objetos instveis ou informais.
Aprendizado do processo - o uso de modelos QGM requer sempre refinamento e
adaptao. Assim, as medidas definidas devem auxiliar no somente na anlise do
objeto medido, mas tambm na avaliao do prprio modelo.
16
Como exemplo de aplicao da abordagem Goal/Question/Metric, apresenta-se a

suposio de modelo em que se pretenda melhorar o prazo no atendimento s solicitaes
de mudana para um determinado sistema em fase de manuteno. O objetivo definido
dever explicitar o propsito (melhorar), o processo (atendimento de solicitaes de
mudana), o ponto de vista (gerente de projeto), e o aspecto a ser observado (prazo de
execuo). Esse objetivo deve ser refinado em uma srie de questes, que sero
respondidas a partir da comparao do tempo coletado com mdia. O modelo GQM
completo seria: [2 p 8]
Mtricas
Objetivo
Propsito
Melhoria
Aspecto
Prazo
Objeto (processo)
Atendimento das solicitaes
Ponto de vista
Gerente de projetos
Questo
Q1
Mtricas
M1
Qual o tempo corrente no atendimento de

solicitaes de mudana?
Mdia de tempo de cada fase
M2
Desvio padro
M3
% de casos acima do limite superior
Q2
O processo (documentado) no atendimento de
Questo
M8
Mdia de tempo de execuo * 100

Padro de tempo para a fase
Uma vez que o modelo GQM esteja definido, faz-se necessria a seleo
das tcnicas, ferramentas e procedimentos apropriados coleta de dados. Os dados
coletados devem ser mapeados para o modelo e interpretados de acordo com esquemas
previamente definidos pela organizao.
Conclui-se, ento, que a abordagem Goal/Question/Metric uma
abordagem para definio de um mecanismo de mensurao que possibilite o
acompanhamento e avaliao do processo operacional de produo de software.
solicitaes fielmente seguido?

Mtricas
M4
Avaliao subjetiva do gerente de projetos
M5
% de excees identificado durante as revises
Questo
Q3
Qual o desvio do prazo no atendimento de
Mtricas
M6
solicitaes em funo do estimado?
M7
Mdia da execuo mdia prevista * 100

Mdia da execuo
Avaliao subjetiva do gerente de projeto
Questo
Q4
O desempenho est melhorando?
Mtricas
M8
Questo
Q5
Mtricas
M7
Avaliao subjetiva do gerente de projeto
Questo
Q4
H melhoria visvel no desempenho?
Mdia de tempo de execuo * 100

Padro de tempo para a fase
O desempenho tem sido satisfatrio sob o ponto de
vista do gerente de projeto?
17
18
III. O Ambiente em que foi Implementado o Modelo GQM

Neste captulo so apresentadas as principais caractersticas e a misso
institucional da instituio aonde foi implantado o processo de melhoria contnua usando o
QIP/GQM - o Tribunal de Contas do Distrito Federal e, inserida nessa misso, o papel
desenvolvido pelo setor de informtica.
A misso do TCDF
As competncias constitucionais do Tribunal de Contas do Distrito
Federal so:[3]
apreciar, mediante emisso de parecer prvio, as contas anuais do Governador
e julgar aquelas relativas aos administradores e demais responsveis por
dinheiro, bens e valores pblicos;
apreciar, para fins de registro, a legalidade dos atos de admisso de pessoal e
de concesso de aposentadorias, reformas e penses;
avaliar a execuo das metas estabelecidas no plano plurianual, nas diretrizes
oramentrias e no oramento anual;
realizar inspees e auditorias de natureza contbil, financeira, oramentria,
operacional e patrimonial nas unidades administrativas dos Poderes Executivo
e Legislativo;
fiscalizar as aplicaes do Poder Pblico em empresas de cujo capital social o
Distrito Federal participe de forma direta ou indireta;
fiscalizar a aplicao de recursos repassados ou recebidos pelo Distrito
Federal, a qualquer ttulo;
atender s solicitaes da Cmara Legislativa relativas s atividades de
Controle Externo;
aplicar, em caso de ilegalidade ou irregularidade de contas, as sanes
previstas em lei e sustar, se o Tribunal no for atendido, a execuo de ato
impugnado.
No planejamento estratgico para o perodo de 1999 a 2003 [7] dado
especial relevo ao estabelecimento da misso institucional do TCDF com base nas
competncias constitucionais acima e nos arts. 77 e 78 da Lei Orgnica do Distrito Federal
(LODF) [3]. Esses artigos elucidam que a fiscalizao contbil, financeira, oramentria,
operacional e patrimonial dos rgos e entidades da administrao do Distrito Federal,
quanto legalidade, legitimidade, economicidade, aplicao das subvenes e renncia de
receitas exercida pela Cmara Legislativa - mediante controle externo e pelo sistema de
controle interno de cada Poder - com o auxlio do Tribunal de Contas do Distrito Federal.
Assim, inferida da essncia dos citados dispositivos legais, a misso do
Tribunal pode ser enunciada como:
Exercer o controle externo da administrao dos recursos pblicos do
Distrito Federal, em auxlio Cmara Legislativa, zelando pela legalidade, legitimidade,
efetividade, eficcia, eficincia e economicidade na gesto desses recursos.
19
Releva notar que o atributo principal do papel da Corte de Contas

Distrital garantir sociedade segurana quanto transparncia e boa gesto dos recursos
arrecadados e gastos pelo Governo do Distrito Federal.
O papel do setor de informtica
A poltica de informatizao do Tribunal tem se pautado pela adoo de
solues que associem qualidade, funcionalidade e economicidade.
Nesse contexto, ao setor de informtica do Tribunal, denominado Ncleo
de Informtica e Processamento de Dados NIPD, compete apoiar a atividade de
fiscalizao por meio da criao de sistemas de informao para acompanhamento dos
gastos pblicos, avaliao de riscos e identificao de pontos crticos para auditoria,
produo, organizao e divulgao de smulas, decises, votos, pareceres e instrues.
Para auxiliar essas atividades foram desenvolvidos, em especial a partir de 1996, vrios
sistemas integrados em repositrio de informaes nico.[8]
Ao NIPD compete tambm administrar a rede de microcomputadores,
executar e acompanhar a manuteno dos equipamentos de informtica, bem como propor a
compra de bens e servios relativos a tecnologia.
Adicionalmente, o setor mantm atualizado, com o apoio de diversas
Unidades do TCDF, o site www.tc.df.gov.br que permite a qualquer cidado consultar os
documentos pblicos produzidos no exerccio do controle externo.
Por ser um ente pblico com especial apreo pela boa gesto dos
recursos, antes de efetuar investimentos so feitas anlises de alternativas com vistas a
encontrar a melhor relao custo x benefcio. Essa prtica, aplicada ao setor de informtica
ser, como apresentado a seguir, motivadora do desenvolvimento de um processo de
produo de software.
Motivao para o estabelecimento do processo de desenvolvimento
Devido ao esforo necessrio ao estabelecimento de um processo de
desenvolvimento, em especial quando se conta com poucos recursos humanos e materiais,
foi fundamental para o empenho na produo do mesmo a existncia das motivaes a
seguir relacionadas.
Melhoria da qualidade de produtos
Sendo o TCDF um rgo de informatizao relativamente recente, a
partir de 1995, a equipe responsvel pelo desenvolvimento de sistemas teve a oportunidade
de construir todo um conjunto de aplicaes corporativas, com base nas necessidades
identificadas junto aos usurios, integrado e homogneo. No entanto, o processo de
construo dessas solues foi fortemente influenciado pela experincia profissional dos
tcnicos e, apesar de ter sido um processo repetitivo, no era explicitado formalmente.
Hoje, contando com mais de dez aplicaes em produo (150.000 linhas
de cdigo fonte em Visual Basic, VB Script, Java, Java Script e HTML), que, portanto,
requerem manuteno, e sem modificao no quadro de desenvolvedores (2 analistas e 4
programadores), faz-se necessrio aprimorar o processo de trabalho visando a elaborao
20
de produtos com menor nmero de erros possvel, que observem a integrao e a

homogeneidade dos sistemas j desenvolvidos.
Planejamento de novas demandas
IV. Implementando Um Processo De Melhoria Contnua

Metodologia Empregada
Da forma atual, as estimativas de prazo para desenvolvimento ou

manuteno de sistemas so baseadas somente na experincia pessoal dos tcnicos, sem um
acompanhamento efetivo dos prazos.
Essa situao, apesar de bastante comum nas organizaes, fator de
risco para a credibilidade do setor no caso de falha. Felizmente, desde 1995, os tcnicos
tem acertado em suas previses administrao da Casa. No entanto, o acompanhamento
sistemtico do processo de desenvolvimento de software ser fundamental para aperfeioar
as estimativas de prazos e recursos de novas demandas de sistemas.
Mudana de plataforma computacional
Com a relativa estabilizao da demanda por desenvolvimento de novos
servios e programas ao setor de informtica do TCDF, a partir do final de 1998, a equipe
tcnica iniciou trabalho de busca de alternativas com vistas a reduzir a necessidade de
investimentos em informtica e identificou grupos de programas que, se substitudos,
levariam a essa reduo.
Esse trabalho subsidiou a Presidncia do Tribunal a decidir substituir, at
o final do ano de 2002, o sistema operacional Windows 95 pelo Linux nas estaes de
trabalho do TCDF, proporcionando elevada reduo de investimentos com hardware e
software [8].
Assim, com vistas a possibilitar essa substituio, ser necessrio
converter todos os sistemas desenvolvidos e configurar aplicativos de escritrio que
possibilitem ao usurio final usufruir das mesmas funcionalidades hoje disponveis.
Esse fato gerar intenso esforo de codificao que, sem
acompanhamento formalizado por meio de um processo de desenvolvimento definido e
utilizado por todos os tcnicos, poder inviabilizar a substituio da plataforma
computacional proposta pelo fracasso na converso dos sistemas.
Para que seja possvel substituir gradualmente as aplicaes, optou-se por
utilizar a linguagem Java como padro para a execuo dessa tarefa. A linguagem de
programao Java permite disponibilizar os sistemas tanto para estaes Windows 95 como
Linux e ir facilitar a reutilizao de cdigo.
Conforme podemos observar em, um processo contnuo de melhoria pode ser

implementado institucionalmente, independente se a atividade fim da empresa produzir
software ou outra qualquer, seguindo-se alguns passos descritos detalhadamente a
seguir:[5]
- Montar uma Equipe de Melhoria do Processo:
A primeira e mais crtica atividade ao montar uma equipe a aprovao da gerncia
para todo o processo de melhoria do software na organizao. importante destacar que
nesse processo uma srie de recursos devem ser alocados. A equipe designada para essa
tarefa, preferencialmente em tempo integral, deve ser composta de tcnicos experientes,
com credibilidade dentro da organizao, podendo contar tambm com a participao de
pesquisadores e consultores externos.
Hoje j amplamente reconhecido que uma equipe de melhoria dos processos da
organizao deve ser mantida em uma estrutura separada do desenvolvimento de software.
Essa equipe deve ter um mandato, ou tempo de durao bem definido, por exemplo: o
tempo de ser implantado um processo de qualidade com certificao ISO 9001.
Nesse ambiente em que foi implementado o Modelo GQM, a montagem da equipe
de melhoria dos processos foi o primeiro passo dos trabalhos. Os profissionais mais
experientes foram alocados e levantaram todos os processos do TCDF, propondo melhorias
nos que no se enquadravam plenamente no novo processo de informatizao da
organizao. O levantamento desses processos foi feito por 6 (seis) analistas de sistemas
durante um ms, dedicados exclusivamente esta tarefa.
- Modelar os Processos Existentes:
Modelar os processos existentes em uma organizao pode servir para vrios
propsitos e agregar diversos benefcios. No contexto de melhoria de processos, modelos
de processos descritivos so teis para se entender a maneira como as coisas funcionam e
para comunicar esse entendimento.
Algumas questes bsicas que necessitam serem respondidas em uma modelagem
de processos so:
- Quais so as atividades do processo ?
- Quais so as dependncias entre essas atividades ?
- Quando as atividades iniciam e terminam ?
- Quem so os atores que executam essas atividades ?
- Quais so as interdependncias entre estes atores ?
21
22
Fontes de informao para responder essas questes indicam que devem ser
utilizadas entrevistas com os membros da organizao, inspees nas documentaes dos
processos (quando existirem), inspees nas documentaes de gerncia do projeto e
tambm observaes diretas na equipe de desenvolvimento.
formulrios. Foi selecionado o Sistema de Acompanhamento de Processos para uma anlise

preliminar da metodologia a ser empregada. Foram levantados os problemas apresentados
na verso do sistema e classificadas a s falhas segundo critrios de gravidade estabelecidos
pelo gerente de informtica.
- Definir e Documentar um Plano de Ao:
Os modelos de processos que foram desenvolvidos sero usados em passos

subsequentes do processo de melhoria. Um bom sinal quando os desenvolvedores
penduram partes dos modelos em seus ambientes de trabalho, significa que esto sendo
teis para o dia a dia dos seus trabalhos.
No TCDF, os provveis processos a serem informatizados, foram modelados e
descritos de forma a explanar claramente as atividades intrnsecas de cada um, as
dependncias entre essas atividades, o tempo de durao de cada uma delas, os atores que
as executam e as interdependncias entre estes atores.
Uma vez que os processos esto modelados e seus pontos fortes e fracos esto bem
entendidos, um plano de ao deve ser definido. Para o Software Engineering Process
Group Guide o plano de ao definido como: Uma resposta formal, escrita da avaliao
(do processo) e o mapa para sua melhoria. O plano de ao extremamente importante
por vrias razes, dentre elas podemos citar: solicitado para conseguir uma mudana do
oramento para as prximas fases (avaliao das solues, mudanas nos processos),
crucial para transferir as informaes corretas para a gerncia e para os desenvolvedores
sobre a importncia e as dificuldades do que ser realizado.
- Conduzir uma Anlise Qualitativa:

A meta desse estgio identificar as causas e os mecanismos internos que indiquem
os problemas de custos e riscos elevados, relacionados qualidade dos produtos entregues e
eficincia do processo de desenvolvimento de software.
A equipe de melhoria de processos da organizao, citada anteriormente, poder ser
responsvel pela anlise contnua desse problemas. Uma modelagem dos processos bem
definida, ajudar a diferenciar os verdadeiros problemas dos aspectos irrelevantes. Nesse
contexto, existem trs tcnicas principais para se fazer a anlise qualitativa: entrevistas
estruturadas, anlise eventual dos problemas e questionrios bem definidos e bem
desenhados. No contexto da anlise qualitativa, essas tcnicas se complementam, pois,
permitem uma checagem cruzada das informaes levantadas.
A anlise eventual usualmente iniciada quando reportado um problema vindo da
fase de testes, ou j da operao, de um determinado sistema. Para executar a anlise
eventual alguns procedimentos so recomendados:
- Selecione um sistema, ou verso, relevante para a organizao;
- Obtenha todos os relatrios de problemas;
- Classifique as falhas de programas de acordo com tipos e nveis de gravidade;
- Determine as causas de maior gravidade de falhas em termos de erros humanos e
falhas nos processos;
- Desenvolva recomendaes para mudanas de processos e valide-as com os
participantes da anlise eventual;
- Refine as linhas gerais da anlise eventual e a nomenclatura utilizada para auxiliar
futuras anlises.
A execuo destes procedimentos assume que a organizao tem processos bem
definidos e modelos organizacionais.
No TCDF, como os processos j haviam sido modelados e bem definidos, nesta fase
foram elaborados tambm os procedimentos de coleta de dados e desenhados os
23
Um possvel esboo de alto nvel de plano de ao pode ter o seguinte formato:

Melhora corporativa dos objetivos e motivaes;
O plano de ao dos diversos grupos e participantes do processo de melhoria, suas
responsabilidades e prerrogativas;
Os passos da melhoria, suas conexes com os objetivos corporativos e seus critrios
de entrada e sada;
As fases que conduzem para os critrios de sada de cada passo de melhoria, os
riscos e incertezas associados a cada fase e os planos de contingncia
correspondentes, os gerentes encarregados de monitorar e organizar as fases de
execuo;
O conjunto de atividades envolvidas em cada fase de cada passo, os participantes
em cada atividade e suas responsabilidades;
O esforo e o custo para cada passo e fase, com intervalos indeterminados;
Os benefcios esperados baseados em experincias externas e em informaes
existentes sobre qualidade e produtividade da organizao.
Como Plano de Ao para o TCDF foi estabelecida uma metodologia que

contempla: procedimentos de desenvolvimento e manuteno de sistemas, estabelecimento
de um fluxo de solicitaes de sistemas, o Sistema de Acompanhamento do
Desenvolvimento de Sistemas SADS, que permite o registro do processo e a extrao das
mtricas estabelecidas (todos estes itens podem ser vistos no Anexo I deste documento).
- Montar um Programa de Medio:
A princpio um programa de medio geralmente projetado para: prover uma base
quantitativa de comparaes para futuras mudanas de processos, melhor entendimento dos
requisitos que tenha ou no sido identificados na anlise qualitativa precedendo a medio,
e finalmente, fazer com que o processo de tomada decises seja menos arriscado provendo
informaes gerenciais corretas e no tempo certo sobre produtos de software e os processos
utilizados para desenvolv-los. Em vrias ocasies j foi percebido que o xito de um
24
programa de medies est no seu direcionamento para as metas e objetivos da

organizao.
Para transferir a tecnologia para a memria da organizao, alguns pr-requisitos

devem ser observados. Primeiro, a estrutura de recompensa deve ser mudada para refletir as
metas da tecnologia transferida. Por exemplo, se a cultura atual da organizao recompensa
a produtividade, ento a introduo de mtodos estruturados de anlise e projeto, que
diminuem a rapidez da execuo das primeiras fases do projeto, so improvveis de serem
adotados pela organizao ou, caso sejam adotadas pela organizao, o seu uso efetivo ser
improvvel. Segundo, deve haver um nmero de consultores especialistas na tecnologia
disponvel para resolver os problemas e, se necessrio, prover treinamento para os membros
da organizao.
Os passos usuais de um processo de medio podem ser resumidos da seguinte

forma:
- Definir metas corporativas e de medidas;
- Derivar modelos e medidas que paream adequados no contexto especfico de
medies;
- Definir procedimentos de coleta de dados para coletar dados vlidos e corretos;
- Treinar os participantes em procedimentos de coleta de dados;
- Testar a coleta de dados e validar os procedimentos em projetos piloto,
simplificando e refinando-os quando necessrio;
- Expandindo o uso das medies em toda a organizao;
- Analisar os dados coletados para verificar a utilidade destes dados e a exatido dos
modelos;
- Refinar modelos, medidas e procedimentos de coleta de dados, voltar ao passo 4.
Algumas fontes usuais de problemas quando so implementados programas de medio:
- A coleta de dados no voltada para as metas;
- As metas de medio no esto claramente especificadas e/ou claramente
comunicadas aos colaboradores;
- Muitas metas a serem coletadas de uma s vez. Conflito entre as metas da alta
gerncia com as metas operacionais e vice-versa;
- Desenvolvedores tm que coletar muitos dados;
- A equipe encarregada do programa de medio no teve o treinamento adequado
e/ou no tem experincia suficiente.
Por ser o TCDF uma organizao pblica, que contm processos e procedimentos
estabelecidos em leis, as mudanas dos processos muitas vezes tornam-se problemticas e
at impossveis de serem realizadas. Neste cenrio, mudar a organizao praticamente
invivel. O que factvel, e que j est em curso, a proposio de mudanas sistemticas
e paulatinas na execuo de processos e procedimentos. Esta proposio feita
demonstrando-se os aspectos favorveis e desfavorveis destas mudanas, encaminhandoas para posterior deciso das autoridades competentes, gestoras destes processos.
Neste captulo os autores apresentaram uma abordagem ascendente para a melhoria
prtica do processo de produo de software e seus produtos. Estes passos devem ser vistos
como uma implantao do Paradigma de Aperfeioamento da Qualidade QIP. A fim de
facilitar sua aplicao em diferentes organizaes de desenvolvimento e manuteno de
software, os autores montaram um conjunto de passos e diretrizes deste paradigma,
baseados em suas experincias adquiridas, conduzindo estudos quantitativos e qualitativos,
em diversas organizaes pblicas e privadas.
Neste passo da metodologia foram feitas as entrevistas recomendadas na abordagem

GQM, onde foram definidas as metas corporativas e de medidas. Foram aplicados os
procedimentos de coleta de dados e implantadas as rotinas de utilizao formulrios
desenhados anteriormente, sendo treinados os funcionrios responsveis pela captao e
alimentao dos dados. Este passo no apresentou problemas, pois, a coleta dos dados foi
voltada para as metas estabelecidas nas entrevistas, as metas de medio foram claramente
especificadas. No houve uma sobrecarga no trabalho dos desenvolvedores para coletar os
dados toda a equipe foi treinada no processo de coleta de dados.
- Mudar os Processos e a Organizao:

Aps o Projeto Piloto e a reviso dos seus resultados, a tecnologia deve ser
transferida para a memria da organizao. Tudo que pde ser observado no Projeto Piloto
deve ser usado para ensinar a tecnologia, as formas e materiais de seu treinamento para a
organizao. Tambm os procedimentos de coleta de dados talvez tenham de ser
modificados para levar em conta as lies aprendidas no Projeto Piloto.
25
26
Bibliografia
V. Concluso, Perspectivas e Futuros Trabalhos

O presente trabalho tem por objetivo apresentar a fundamentao terica e um caso
prtico da abordagem QIP/GQM aplicada em uma empresa brasileira, o Tribunal de Contas
do Distrito Federal TCDF. Nos principais modelos de qualidade de software apresentados
neste trabalho, o modelo CMM foi o escolhido por nortear de forma objetiva e direta, as
aes de implementao de modelos de qualidade de software em empresas nacionais.
[1] BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H. Dieter. The

Experience Factory. Institute for Advanced Computer Studies /
Department of Computer Science / University of Maryland (EUA); & FB
Informatik
/
Universitt
Kaiserlautern
(Alemanha).
In:
http://www.cs.umd.edu/projects/SoftEng/tame/ tame.html.
O Paradigma de Aperfeioamento da qualidade QIP estabelece premissas

fundamentais para que uma organizao possa melhorar cada processo de software:
caracterizar o ambiente, definir os objetivos, escolher os processos, analisar os dados e
informaes e finalmente empacotar as experincias adquiridas nesse projeto realizado.
Essas experincias devem ser armazenadas na Fbrica de Experincias, para que possa ser
estabelecida uma continuidade do processo de melhoria de software nas organizaes.
[2] ____. The Goal Question Metric Approach. Institute for Advanced
Computer Studies / Department of Computer Science / University of
Maryland (EUA); & FB Informatik / Universitt Kaiserlautern
(Alemanha).
In:
http://www.cs.umd.edu/projects/SoftEng/tame/
tame.html.
A abordagem GQM, objeto de estudo deste trabalho, utilizada como mecanismo

ou tcnica, para que seja implementado um programa permanente de avaliao e melhoria
da qualidade de software das organizaes. Esta tcnica foi escolhida principalmente pela
sua abordagem objetiva e abrangente na conduo dos trabalhos de melhoria da qualidade
de software dentro das organizaes.
[3] BRASIL. CMARA LEGISLATIVA - DF. Lei Orgnica do Distrito

Federal, Braslia: Cmara Legislativa, 1993.
Conforme foi citado anteriormente, o presente trabalho ser a parte inicial da

dissertao de mestrado que versar sobre a viabilidade de se implantar e manter modelos
de qualidade de software em empresas brasileiras, visando a melhoria contnua dos
produtos de software dessas empresas. Para tanto, pretende-se implementar a abordagem
GQM. com todas as suas implicaes, em outra empresa nacional. Contaremos com a
colaborao da equipe do Ncleo de Informtica do TCDF para orientar a implantao de
todo o processo, que dever se dar primeiramente em uma equipe de desenvolvimento de
software provavelmente da ECT Correios do Brasil.
-
[4] BRASIL. CONGRESSO NACIONAL. Constituio Federal, Braslia:

Congresso Nacional, 1988.
[5] BRIAND, Lionel; EL EMAM, Khaled; MELO, Walclio L. An Inductive
Method for Software Process Improvement: Concrete Steps and
Guidelines. In: Elements of Software Process Assessment and
Improvement. Los Alamitos, California (EUA): IEEE Computer Society,
1999.384 p. p. 113-130.
[6] DION, Ray. Starting the Climb Towards the CMM Level 2 Plateau. In:
Elements of Software Process Assessment and Improvement. Los
Alamitos, California (EUA): IEEE Computer Society, 1999. 384 p. p.
259-269.
[7] DISTRITO FEDERAL (Brasil). Tribunal de Contas do Distrito Federal DF. Plano Estratgico do Tribunal: PLANEST; Perodo 1999-2003,
Braslia: TCDF/DIPLAN, 1998.
[8] ____. Tecnologia da Informao Trinio 2000-2002, Braslia:
TCDF/NIPD, 1999.
[9] JOHNSON, Donna L.; BRODMAN, Judith G. Tailoring the CMM for
Small Businesses, Small Organizations, and Small Projects. In: Elements
27
28
of Software Process Assessment and Improvement. Los Alamitos,

California (EUA): IEEE Computer Society, 1999. 384 p. p. 239-257.
[10] MCGARRY, Frank; PAGE, Gerald; BASILI, Victor; et al. Software
Process Improvement in The NASA Software Engineering Laboratory.
Technical
Report
CMU/SEI-94-TR-22.
ESC-TR-94-022.
Dezembro,1994. NASA/Goddard Space Flight Center; Computer
Sciences Corporation (EUA); & University of Maryland (EUA). In:
http://www.cs.umd.edu/projects/SoftEng/ tame/tame.html.
[11] NASA. Sample SEL Data Collection Forms: Development Estimates
Form and Report Form. In: http://sel.gsfc.nasa.gov/data/ forms.htm.
[12] NASA. Software Process Improvement Guidebook. NASA Janeiro,
1996. NASA-GB-001-95. In: http://www.ivv.nasa.gov.
[13] PAULK, Mark C.; WEBER, Charles V.; CHRISSIS, Mary Beth. The
Capability Maturity Model for Software. In: Elements of Software
Process Assessment and Improvement. Los Alamitos, California (EUA):
IEEE Computer Society, 1999.
[14] PRESSMAN, Roger S. Engenharia de Software. Traduo de Jos
Carlos Barbosa dos Santos. So Paulo: Makron Books, 1995. 1056 p. p.
721-875.
[15] EDWARD DEMING, Out of the Crisis, MIT Center of Advanced
Engineering Study, MIT Press, Cambridge, MA, 1986
29
30
ANEXO I
Modelo GQM aplicado ao desenvolvimento de sistemas no TCDF
Considerando o contexto e as razes acima descritos estabeleceu-se o
seguinte modelo Goal, Question, Metric, adiante detalhado, para a rea de desenvolvimento
de sistemas do Tribunal de Contas do DF.
Objetivo
Propsito
Avaliar
G2
Aspecto
Tempo
Objeto
Converso dos sistemas em Visual Basic (VB) para

Java
Ponto de vista
Gerente
Questo
Q3
Qual o tamanho do sistemas originais (VB)?
Mtricas
M11
Quantidade de arquivos dos sistemas originais
M12
Quantidade de linhas de cdigo (LOC) dos sistemas
Objetivo
Propsito
Melhoria
Questo
Q4
Qual o tamanho dos sistemas convertidos?
G1
Aspecto
Qualidade
Mtricas
M13
Objeto
Sistemas Desenvolvidos (produto)
Quantidade de arquivos dos sistemas convertidos para

Java
Ponto de vista
Gerente
M14
Questo
Q1
Quantidade de erros encontrados pelo usurio?
Quantidade de linhas de cdigo (LOC) dos sistemas

convertidos para Java
Mtricas
M1
# mensal de ocorrncias de manutenes corretivas
Questo
Q5
Qual o tempo necessrio para converso?
Mtricas
M15
Tempo total de converso por sistema em VB
M16
Tempo mdio de converso de uma LOC em VB para

Java
M2
# mensal de ocorrncias de erros que afetam o

desempenho dos sistemas
M3

funcionamento de pelo menos uma funo
Mtricas
M17
M16 por arquivo VB
M4

funcionamento de pelo menos um sistema
Objetivo
Propsito
Avaliar
M5
# mensal de ocorrncias de erros que geram

informaes inconsistentes
G3
Aspecto
Planejamento
Objeto
Processo de Desenvolvimento de Sistemas
Ponto de vista
Gerente
Questo
Q2
A qualidade dos produtos est melhorando?
Mtricas
M6
% de variao do ltimo ms com relao a mdia

acumulada para M1
M7

acumulada para M2
M8

acumulada para M3
M9

acumulada para M4
M10

acumulada para M5
Questo
Q6
Qual a diferena entre o esforo (tempo) estimado e o

realizado?
M27
# mensal de erros encontrados na leitura de cdigo que

afetam o funcionamento de pelo menos uma funo
Mtricas
M18
(Esforo real - Esforo estimado) por ocorrncia e fase
M28
M19
(M18 / Esforo estimado) * 100 por ocorrncia e fase

afetam o funcionamento de pelo menos um sistema
M20
Mdia de M19 por objetivo e fase
M29

que geram informaes inconsistentes
Questo
Q7
Qual a diferena entre os prazos previstos e realizados?
M30
Mtricas
M21
(Data de incio real - Data de incio estimada) em dias

por ocorrncia e fase
# mensal de erros encontrados nos testes de integrao

e implantao
M31
M22
#mensal de erros encontrados nos testes de integrao e

implantao que afetam o desempenho dos sistemas
M23
(Data de fim real - Data de fim estimada) em dias por

ocorrncia e fase
M32
M24

e implantao que afetam o funcionamento de pelo
menos uma funo
M33
Objetivo
Propsito
Avaliar
G4
Aspecto
Qualidade

e implantao que afetam o funcionamento de pelo
menos um sistema
Objeto
Processo de Desenvolvimento de Sistemas
M34
Ponto de vista
Gerente

e implantao que que geram informaes
inconsistentes
Questo
Q8
Qual o nmero de erros identificados pela equipe de

desenvolvimento durante a elaborao do sistema?
Q9
Qual a relao entre os erros encontrados pelo usurio e

os erros identificados durante a elaborao do sistema?
Mtricas
M25
# mensal de erros encontrados na leitura de cdigo
M35
M1 / (M25 + M30)
M26

afetam o desempenho dos sistemas
M36
M2 / (M26 + M31)
M37
M3 / (M27 + M32)
M38
M4 / (M28 + M33)
M39
M5 / (M29 + M34)
Q10
Qual a origem (fonte) dos erros encontrados?
M40
# mensal de erros encontrados pelos usurios por fonte

de erro
M41
# mensal de erros encontrados na leitura de cdigo por

fonte de erro
M42

e implantao por fonte de erro
M43
M40 / (M41 + M42)
Questo
Questo
Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos

Procura-se aqui ter condies de dimensionar a melhoria dos produtos
entregues aos usurios finais, utilizando-se como indicador principal a quantidade de erros
percebida pelos usurios. Para esse objetivo foram definidas duas questes:
1. Q1 - Qual a quantidade de erros encontrados pelos usurio? - procura dimensionar os
vazamentos de erros no encontrados na produo do sistema, permitindo quantificar os
transtornos causados aos usurios. Em resposta a essa questo foram extradas as
seguintes medidas:
1.1. M1 = Nmero mensal de ocorrncias de manutenes corretivas - contabiliza
todas as ocorrncias de erros encontradas pelos usurios independentemente de sua
gravidade;
1.2. M2 = Nmero mensal de ocorrncias de erros que afetam o desempenho dos
sistemas - constituem um subgrupo de M1 e foram destacadas pois prejudicam o
desempenho do sistema;
1.3. M3 = Nmero mensal de ocorrncias de erros que afetam o funcionamento de
pelo menos uma funo - constituem outro subgrupo de M1 e foram destacadas
pois prejudicam o desempenho de pelo menos uma funo (tipicamente uma tela de
transao) do sistema;
1.4. M4 = Nmero mensal de ocorrncias de erros que afetam o funcionamento de
pelo menos um sistema - constituem outro subgrupo de M1 e foram destacadas pois
prejudicam o desempenho de pelo menos um sistema (toda uma aplicao); e
1.5. M5 = Nmero mensal de ocorrncias de erros que geram informaes
inconsistentes - constituem outro subconjunto de M1 e foram destacadas pois
provocam o armazenamento ou exibio de informaes inconsistentes.
2. Q2 - A qualidade dos produtos est melhorando? - visa avaliar a evoluo da
qualidade dos produtos entregues por meio da comparao das mtricas da Q1 acima
descritas ao longo do tempo. Em resposta a essa questo foram extradas as mtricas
abaixo:
2.1. M6 = Percentual de variao do ltimo ms com relao a mdia acumulada
para M1 - obtida pela diviso da medida de M1 para o ltimo ms pela mdia de
M1 nos meses anteriores ao ltimo ms multiplicado por 100;
para M4 - clculo idntico ao de M6 utilizando como parmetro M4; e

para M5 - clculo idntico ao de M6 utilizando como parmetro M5.
Objetivo G2 - Avaliar o tempo de converso de sistemas em Visual Basic para Java

Tendo em vista a mencionada estratgia de substituio do sistema
operacional utilizado no TCDF, faz-se necessrio reescrever todos os sistemas em produo
na linguagem Java para que os mesmos possam continuar sendo utilizados. Esse objetivo
visa aperfeioar as estimativas de converso dos sistemas por meio da anlise das seguintes
questes:
1. Q3 - Qual o tamanho dos sistemas originais em Visual Basic? - essa questo
relevante para dimensionar a tarefa a ser executada. Para respond-la so medidos:
1.1. M11 = Nmero de arquivos fonte por sistema - agrupam-se os arquivos dos
sistemas desenvolvidos e em desenvolvimento em diretrios de trabalho
especficos e procede-se a contagem. Essa mtrica extrada por apurao
automtica em lote, pelo prprio sistema de apoio ao processo, no necessitando de
preenchimento de formulrios; e
1.2. M12 = Nmero de linhas de cdigo por sistema - somam-se as linhas de cdigo,
observada a sintaxe do Visual Basic, dos arquivos que compem os sistemas de
informao. Essa mtrica extrada por apurao em lote no necessitando de
preenchimento de formulrios.
2. Q4 - Qual o tamanho dos sistemas convertidos em Java? - assim, pode-se avaliar o
impacto de substituio da linguagem em termos de tamanho (LOC) dos sistemas
convertidos e acompanhar o progresso do processo de converso. Para responder a essa
questo so medidos:
2.1. M13 = Nmero de arquivos dos sistemas - contagem efetuada de forma idntica a
M11 para os diretrios dos sistemas em Java; e
2.2. M14 = Nmero de linhas de cdigo por sistema - soma efetuada de forma
idntica a M12 para os diretrios dos sistemas em Java.

para M2 - clculo idntico ao de M6 utilizando como parmetro M2;
3. Q5 - Qual o tempo para converso dos sistemas? - questo principal para o objetivo
pretendido pois informa o esforo realizado at o momento e permite estimar a tarefa
restante. Para responder a essa questo so extradas as seguintes medidas:

para M3 - clculo idntico ao de M6 utilizando como parmetro M3;
3.1. M15 = Tempo total de converso por sistema - soma das horas de trabalhadas para
converso de cada sistema at o momento;
3.2. M16 = Tempo mdio de converso de uma linha de cdigo em VB para Java -
soma de todo o tempo de codificao em Java para converso dividida pelo

tamanho (em linhas de cdigo VB) de todos os arquivos convertidos at o
momento; e
3.3. M17 = Tempo mdio de converso de uma linha de cdigo em VB para Java por
arquivo VB - soma de todo o tempo de codificao em Java para converso do
arquivo dividida pelo tamanho (em linhas de cdigo VB) do arquivo - possibilita
avaliar a evoluo da eficincia do trabalho e a complexidade da converso de cada
arquivo.
desenvolvimento de sistemas;
2.3. M23 = (data de fim real - data de fim estimada) em dias agrupado por ocorrncia
e fase - mede a preciso no planejamento do fim de cada fase do processo de
desenvolvimento - valores negativos indicam fases concludas antes da data
estimada; e
2.4. M24 = Mdia de M23 agrupada por objetivo e fase - indica se h variao
sensvel entre as previses de trmino por objetivo e/ou fase do processo de
desenvolvimento de sistemas.
Objetivo G3 - Avaliar o planejamento do processo de desenvolvimento de sistemas

Objetivo G4 - Avaliar a qualidade do processo de desenvolvimento de sistemas
O processo de desenvolvimento de sistemas implantado contempla o
planejamento de prazos e recursos. No entanto, para a efetividade do planejamento
necessrio avaliar o seu grau de preciso e efetuar as correes necessrias.
1. Q6 - Qual a diferena entre o esforo (tempo) estimado e o realizado? - questo que
possibilita verificar a preciso do planejamento de recursos; no caso do TCDF, o
principal recurso para desenvolvimento de sistemas a hora de trabalho dos tcnicos.
Assim, foram estabelecidas as seguintes medidas:
1.1. M18 = (esforo real - esforo estimado) agrupado por ocorrncia e fase (entendase fase do processo de desenvolvimento como: especificao, codificao, leitura
de cdigo, e teste de integrao e implementao) - diferena em minutos entre o
esforo real e o esforo estimado - valores negativos expressam estimativas a maior
e valores positivos estimativas a menor;
1.2. M19 = (M18 / esforo estimado) * 100 agrupado por ocorrncia e fase - indica o
percentual de erro das estimativas com relao ao esforo previsto;
1.3. M20 = Mdia de M19 agrupada por objetivo (entenda-se objetivo da ao da
equipe de desenvolvimento em cada ocorrncia: manuteno corretiva,
manuteno evolutiva ou desenvolvimento de um novo sistema) e fase - permite
avaliar se h discrepncias significativas entre as previses feitas para cada tipo de
objetivo e dentro de cada objetivo por fase do processo de desenvolvimento de
sistemas.
2. Q7 = Qual a diferena entre os prazos previstos e reais? - possibilita aferir a preciso
das estimativas de datas de incio e fim de cada fase do processo de desenvolvimento.
Para essa aferio so computados:
Com a implantao do processo de desenvolvimento de sistemas

pretende-se reduzir o nmero de erros encontrados pelo usurio, ou seja, erros aps a
entrada do sistema em produo, estabelecendo-se pontos de teste no processo de
desenvolvimento de sistemas com a execuo das atividades de leitura de cdigo e teste de
integrao e implantao. Assim, para avaliar a efetividade do processo em termos de
identificao de erros e reduo de vazamentos (erros encontrados pelos usurios) foram
definidas as seguintes questes:
1. Q8 - Qual o nmero de erros identificados pela equipe de desenvolvimento durante a
elaborao do sistema? - possibilita aferir a eficcia das atividades de teste implantadas
com o processo de desenvolvimento de sistemas. Para essa questo so medidos:
1.1. M25 = Nmero mensal de erros encontrados na leitura de cdigo - totaliza a
quantidade de erros identificados na fase de leitura de cdigo pela equipe de
desenvolvedores a cada ms;
1.2. M26 = Nmero mensal de erros encontrados na leitura de cdigo que afetam o
desempenho dos sistemas - indica a quantidade de erros identificados na fase de
leitura de cdigo que prejudicam o desempenho do sistema pela equipe de
funcionamento de pelo menos uma funo - indica a quantidade de erros
identificados na fase de leitura de cdigo que prejudicam o desempenho de pelo
menos uma funo (tipicamente uma tela de transao) do sistema pela equipe de
2.1. M21 = (data de incio real - data de incio estimada) em dias agrupado por
ocorrncia e fase - mede a preciso no planejamento do incio de cada fase do
processo de desenvolvimento - valores negativos indicam fases iniciadas antes da
data estimada;
funcionamento de pelo menos um sistema - indica a quantidade de erros
identificados na fase de leitura de cdigo que prejudicam o desempenho de pelo
menos um sistema (toda uma aplicao) pela equipe de desenvolvedores a cada
ms;
2.2. M22 = Mdia de M21 agrupada por objetivo e fase - indica se h variao
sensvel entre as previses de incio por objetivo e/ou fase do processo de
1.5. M29 = Nmero mensal de erros encontrados na leitura de cdigo que geram
informaes inconsistentes - indica a quantidade de erros identificados na fase de
leitura de cdigo que provocam o armazenamento ou exibio de informaes

inconsistentes pela equipe de desenvolvedores a cada ms;
1.6. M30 = Nmero mensal de erros encontrados nos testes de integrao e
implantao - totaliza a quantidade de erros identificados na fase testes de
integrao e implantao pela equipe de desenvolvedores a cada ms;
implantao que afetam o desempenho dos sistemas - indica a quantidade de erros
identificados na fase testes de integrao e implantao que prejudicam o
desempenho do sistema pela equipe de desenvolvedores a cada ms;
implantao que afetam o funcionamento de pelo menos uma funo - indica a
quantidade de erros identificados na fase testes de integrao e implantao que
prejudicam o desempenho de pelo menos uma funo (tipicamente uma tela de
transao) do sistema pela equipe de desenvolvedores a cada ms;
implantao que afetam o funcionamento de pelo menos um sistema - indica a
quantidade de erros identificados na fase testes de integrao e implantao que
prejudicam o desempenho de pelo menos um sistema (toda uma aplicao) pela
equipe de desenvolvedores a cada ms;
implantao que geram informaes inconsistentes - indica a quantidade de erros
identificados na fase testes de integrao e implantao que provocam o
armazenamento ou exibio de informaes inconsistentes pela equipe de
2. Q9 - Qual a relao entre o nmero de erros identificados pelo usurio e os erros
identificados durante a elaborao do sistema? - possibilita a comparao entre as
quantidades de erros encontrados pelos usurios dos sistemas (vazamentos) e de erros
encontrados pela equipe de desenvolvimento de sistemas nas fases de leitura de cdigo
e testes de integrao e implantao. Para efetuar essa comparao so extradas:
2.1. M35 = M1 / (M25 + M30) - compara o total de erros encontrados pelo usurio
com o total de erros encontrados pela equipe de desenvolvimento a cada ms.
Valores acima de 1 indicam que os usurios esto encontrando mais erros do que a
equipe de desenvolvimento;
2.2. M36 = M2 / (M26 + M31) - anloga a mtrica anterior limitando a comparao aos
erros que afetam o desempenho dos sistemas;
2.3. M37 = M3 / (M27 + M32) - anloga a mtrica anterior limitando a comparao aos
erros que afetam o funcionamento de pelo menos uma funo;
2.4. M38 = M4 / (M28 + M33) - anloga a mtrica M36 limitando a comparao aos
erros que afetam o funcionamento de pelo menos um sistema; e

2.5. M39 = M5 / (M29 + M34) - anloga a mtrica M36 limitando a comparao aos
erros que geram informaes inconsistentes
3. Q10 - Qual a origem (fonte) dos erros encontrados? - visa caracterizar a origem dos
erros para auxiliar na reduo dos mesmos. As fontes de erro possveis no processo de
desenvolvimento implantado so: codificao, especificao, modificao anterior e
requerimentos do usurio. Para caracterizar as origens dos erros so medidos:
3.1. M40 = Nmero mensal de erros encontrados pelos usurios por fonte de erro agrupa mensalmente os erros encontrados pelos usurios de acordo com a fonte de
erro indicada pelo analista responsvel pela resoluo da ocorrncia;
3.2. M41 = Nmero mensal de erros encontrados na leitura de cdigo por fonte de
erro - agrupa mensalmente os erros encontrados pela equipe de desenvolvimento
na fase de leitura de cdigo classificados de acordo com o tcnico responsvel;
implantao por fonte de erro - agrupa mensalmente os erros encontrados na fase
de testes de integrao e implantao pela equipe de desenvolvimento de sistema
classificados de acordo com o tcnico responsvel; e
3.4. M43 = M40 / (M41 + M42) - compara os erros encontrados pelos usurios e pela
equipe tcnica de acordo com a fonte de erro indicada.
Todas essas mtricas so obtidas automaticamente por meio dos sistemas
de apoio ao processo de desenvolvimento implantado, descrito no prximo captulo.
AberturaMestrado
de chamado
ao
Universidade Catlica de Braslia,
em Informtica,
Qualidade de Software, UCB-QSW-TR-2001/07
Incio
NIPD na intranet por usurio
No
relativo ao
desenvolviment
o de sistemas
O processo de desenvolvimento de sistemas no TCDF

Devido ao crescimento do parque computacional do TCDF e,
consequentemente, das solicitaes de servios ao setor de informtica - que envolvem
desde a criao de um novo sistema de informao at a instalao de um ponto eltrico foi necessrio disciplinar e categorizar as demandas com vistas a facilitar o
acompanhamento das mesmas tanto pela gerncia como pelos prprios usurios. Para isso
foi implantado, em maio de 1999, um aplicativo na intranet do TCDF que possibilita aos
usurios efetuarem suas solicitaes e acompanharem o andamento dos servios.
Fim
Sim
Elaborao de
Cronograma de Desenvolvimento
de Sistemas - CDS
Anlise de Requerimentos do
usurio
Esse sistema se mostrou adequado para as demandas relativas a

manuteno de equipamentos, dvidas de usurios, instalao de programas, etc., mas no
permitia maior detalhamento das fases relativas ao processo de desenvolvimento de
sistemas.
Assim, considerando a importncia de disciplinar o processo de
desenvolvimento, as razes que motivaram sua implantao descritas no item contexto da
aplicao do processo, o modelo GQM definido e a maturidade da equipe de
desenvolvimento, foram criados os documentos contendo o processo de desenvolvimento
de sistemas, os formulrios que suportam esse processo e desenvolvido o Sistema de
Acompanhamento do Desenvolvimento de Sistema no TCDF - SADS - que permite o
registro do processo e a extrao das mtricas estabelecidas (anexo 4).
Processos que
fogem ao
escopo deste
trabalho
Elaborao da especificao
(projeto)
No
Projeto
aprovado
1
Teste de integrao e implementao
Abaixo, apresenta-se de forma esquemtica o diagrama do processo de

desenvolvimento praticado no TCDF.
Codificao
Correes
Leitura de Cdigo
Correes
Sim
No
Correo aps teste
Sim
Correo aps leitura de cdigo
Fim
No
As atividades realizadas pelos participantes do processo, segundo o papel

que exercem, so as seguintes:
Usurio
Analista
Abre
chamado
Abre CDS2
Equipe
Prog. 1 1
Analisa
requerimentos
Elabora
projeto
RTF3
Codifica
Prog. 2
Prog. 3
Preenche
REF4
Preenche
REF
L cdigo
Testa
Secretria
Gerncia
Merece destaque o fato de que o processo definido foi adequado

forma de trabalho dos tcnicos e cultura e disciplina j em uso. O trabalho de definio do
processo permitiu conhecer melhor a forma de atuao da equipe e promover ajustes de
procedimentos.
Digita
REF
Anlise da aplicao do processo

O acompanhamento do processo de desenvolvimento de sistemas
realizado a partir de novembro de 1999 possibilitou obter os resultados apresentados neste
tpico, segundo o modelo GQM apresentado anteriormente. Para melhor compreenso dos
mesmos as anlises sero realizadas para cada objetivo definido, tomando-se por base as
mtricas obtidas at 23 de junho do corrente relacionadas no anexo 2.
Implantao
Conclui
CDS
Preenche
RSA5
Digita
CDS
Preenche
RSA
Preenche
RSA
Preenche
RSA
Vale notar que esse processo vem sendo ajustado, desde setembro
de 1999, para se adequar s necessidades do setor de informtica. Inicialmente, foram
utilizados formulrios mais detalhados para as fases de codificao, baseados nos utilizados
pelo SEL/NASA (anexo 3), que se mostraram de difcil preenchimento e aceitao por
parte da equipe tcnica. Assim, complementarmente ao registro de tempo feito por meio do
RSA, o registro do tamanho dos sistemas e programas feito por rotina de apurao
semanal.
Os resultados obtidos da anlise dessas mtricas no necessariamente

representam uma tendncia neste momento, uma vez no h ainda uma base consolidada
para comparao. Restando dizer que essas medidas passam a representar a formao de
conjunto de indicadores para anlises futuras mais consistentes.
Digita
RSA
Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos

Extrai
mtrias
Avalia
resultados
Legenda:
1 - Programador - tcnico do NIPD atuando como programador;
2 - CDS - Cronograma de Desenvolvimento de Sistemas - modelo no anexo 1;
3 - RTF - Relatrio da Reunio de Reviso Tcnica Formal para Especificao de Sistema - modelo
no anexo 1 - no digitado;
4 - REF - Relatrio de Erros e Falhas - modelo no anexo 1;
5 - RSA - Relatrio de Semanal de Atividades - modelo no anexo 1;
Da observao das mtricas apuradas para este objetivo pode-se constatar

o aumento do nmero de erros encontrados pelos usurios no perodo. A variao de 133%
na mtrica M6 reflete esse aumento e aponta para a necessidade de melhor
acompanhamento do processo de desenvolvimento estabelecido.
H que se considerar, porm, que a grande maioria dos erros encontrados
no se originam de produtos do atual processo de desenvolvimento, resultam de sistemas
em produo antes da implantao deste processo.
Objetivo G2 - Avaliar o tempo de converso de sistemas em Visual Basic para Java
O resultado mais expressivo para avaliao desse objetivo a mtrica
M16 que representa o tempo mdio de converso de uma linha de cdigo VB para Java. Por
essa medida cada linha de cdigo VB convertida para Java em 1,71 minutos, em mdia.
Assim, pode-se comparar o tempo mdio de converso com a mdia de

converso por arquivo (M17) e identificar quais funes consumiram mais recursos ou so
mais complexas.
A partir da associao entre as medidas M16 (tempo mdio de converso)
e M12 (LOC dos sistemas a serem convertidos) pode-se obter uma estimativa do tempo
necessrio para a completa converso dos sistemas. Por exemplo, o Sistema de Acesso s
Bases de Dados - SABD, atualmente em converso, por essa medida, requer 550 horas para
estar totalmente convertido em Java. Uma vez que j foram realizadas 216 horas de
converso para esse sistema (M15), pode-se deduzir que resta um esforo de 334 horas para
concluso de sua converso.
Objetivo G3 - Avaliar o planejamento do processo de desenvolvimento de sistemas

Quanto ao planejamento de recursos, pode-se constatar, pela variao
mdia de erro de estimativa de horas a serem despendidas na realizao de uma tarefa
(M20) por objetivo e fase do processo de desenvolvimento, que as estimativas para
manuteno (corretiva ou evolutiva) tendem a ser maiores que os tempos realizados. Por
outro lado, as estimativas para desenvolvimento de novas funcionalidades tem sido
menores que os tempos reais.
Relativamente s estimativa de datas para incio e concluso de cada fase
por objetivo (M22 e M24), verifica-se uma tendncia de acerto para a previso de incio e
de superestimao das datas de trmino.
Os erros de estimativa, de um modo geral, decorrem do fato de a base de
informaes do processo estabelecido estar ainda em construo. Alm disso, observa-se
uma tendncia dos tcnicos em no acompanharem os resultados de suas previses.
Objetivo G4 - Avaliar a qualidade do processo de desenvolvimento de sistemas
O resultado dessa avaliao ainda pouco expressivo. Com o curto
perodo de observao e a falta de hbito dos tcnicos, os nmeros apontados nesse
objetivo mostram-se muito modestos, o que inviabiliza uma melhor anlise e indica
necessidade de reforar a orientao para uso correto do processo.
MODELOS DE FORMULRIOS APLICADOS NO TCDF
Cronograma para Desenvolvimento/Manuteno de Sistema CDS

N OCORRNCIA:
DATA CONCLUSO:
Descrio :
Objetivo
OBJETIVO:
Desenvolvimento
Manuteno Evolutiva
Formulrio destinado ao acompanhamento do atendimento s solicitaes

registradas no SSUF.
Manuteno Corretiva
Fonte do erro
Gravidade do erro
Requerimento do Usurio
no permite funcionamento do sistema
Especificao
Codificao
no permite funcionamento de alguma funo
Modificao Anterior
gera informaes inconsistentes

erro menor ou desvio dos padres
PERODO ESTIMADO
Incio
Fim
PERODO REAL
ESFORO
ESTIMADO
Fim
Incio
Campos
compromete desempenho do sistema
Cronograma:
FASE
INSTRUO DE PREENCHIMENTO DO CRONOGRAMA

para DESENVOLVIMENTO/MANUTENO DE SISTEMAS CDS
Requerimentos
Especificao
Codificao
Leitura de Cdigo
Testes
Responsvel(eis)
N Ocorrncia
Data Concluso:
Matrcula
Nome
Descrio
Objetivo
Fonte do erro
Gravidade do erro
Detalhes sobre: Banco de Dados; Acessos; Servio; Configurao de Servidor; Estao de Trabalho; etc.
Cronograma
Perodo estimado
Perodo real
Esforo estimado
Responsveis
Detalhes
Elaborado por:
Cadastrado por:
Em:
nmero de registro da ocorrncia no SSUF

indique a data de concluso da implementao da
funcionalidade
matrcula do funcionrio que preenche o formulrio.
nome do funcionrio
resumo do que est sendo desenvolvido/modificado.
indique o objetivo da implementao, conforme o caso:
Desenvolvimento, Manuteno Evolutiva ou Manuteno
Corretiva
somente em caso de manuteno corretiva, indique a origem
do erro.
somente em caso de manuteno corretiva, indique o nvel
de gravidade do erro
para cada fase informar:

data de incio e trmino previstos dos trabalhos;
preenchimento posterior, indicando as datas reais de
realizao dos trabalhos
tempo em minutos previsto para consecuo de cada fase
nome do responsvel pela execuo da fase
informar detalhes que devem ser observados quando da

colocao do sistema em produo, tais como: tabelas,
stored procedure, views etc, que devem ser atualizadas no
banco de dados; configuraes especfica para o servidor de
rede ou estao de trabalho; alterao de servios auxiliares,
compilao simultnea de outros sistema, etc.
Relatrio de Erros e Falhas REF

TIPO DE VERIFICAO :
Leitura de Cdigo
N OCORRNCIA:
Linha
Teste de Integrao
Matrcula:
Nome:
ARQUIVO FONTE:
REFERNCIA
FONTE
GRAVIDADE
Descrio
INSTRUO DE PREENCHIMENTO DO RELATRIO DE

ERROS E FALHAS - REF
Objetivo
Formulrio destinado ao registro de erros ou falhas detectados durante a Leitura
de Cdigo ou Teste de Integrao de determinada funcionalidade.
Campos
Tipo de Verificao marque Leitura de Cdigo ou Teste de Integrao, conforme
o caso.
Matrcula
matrcula do funcionrio que preenche o formulrio.
Nome
nome do funcionrio
N Ocorrncia
nmero de registro da ocorrncia no SSUF
Arquivo fonte
nome do arquivo fonte, inclusive extenso, que est sendo
criado ou alterado. Deve ser escrito com a maior nitidez
possvel.
Referncia
informar o nmero a que se refere o erro de acordo com a
lista de verificao de erros e falhas
Linha
nmero da linha do cdigo a que se refere o erro
Fonte
origem do erro, conforme legenda abaixo no formulrio
Gravidade
nvel de gravidade do erro, conforme legenda abaixo no
formulrio
1
2
Fonte do Erro:
Gravidade do Erro:
REQ Requerimento do Usurio; ESP Especificao ; COD Codificao; MOA Modificao Anterior
FS no permite Funcionamento do Sistema; FF no permite Funcionamento de alguma Funo;
DS compromete Desempenho do Sistema; EM Erro Menor ou desvio dos padres; II gera Informaes Inconsistentes
Relatrio Semanal de Atividades RSA

Matrcula.:
Dia
INSTRUO DE PREENCHIMENTO DO RELATRIO

SEMANAL DE ATIVIDADES - RSA
Nome:
Atividade
Tempo
n Ocorrncia
Arquivo Fonte (inclusive extenso)
Arquivo VB (somente em caso de

converso p/
Objetivo
Formulrio de preenchimento manual para insero semanal de dados no Sistema

de Acompanhamento do Desenvolvimento de Sistemas SADS, com a finalidade
de acompanhar o dispndio de tempo no atendimento s ocorrncias registradas
no Sistema de Solicitaes do Usurio Final - SSUF.
Campos
1.
2.
3.
4.
5.
6.
Matrcula: matrcula do funcionrio que preenche o formulrio.

Nome: nome do funcionrio
Ms/ano: ms e ano de referncia
Dia: dia de referncia do preenchimento
Atividade: indicar sigla de acordo com a legenda abaixo do formulrio
Tempo: tempo gasto na execuo da atividade em minutos, j descontadas
todas as interrupes
7. N Ocorrncia: nmero de registro da ocorrncia no SSUF
8. Arquivo fonte: nome do arquivo fonte, inclusive extenso, que est sendo
criado ou alterado. Deve ser escrito com a maior nitidez possvel.
9. Arquivo VB: informar o nome do arquivo visual basic que est sendo convertido
para java.
10. Cadastrado em: informar a data de cadastramento do formulrio no SADS
11. Por: assinatura ou nome do responsvel pela digitao do formulrio no
sistema.
1
Atividade:
REQ Requerimento do Usurio; ESP Especificao ; RTF Reunio de Reviso Tcnica Formal;
COD Codificao; LER Leitura de Cdigo; CAL correo aps leitura de cdigo;
TII teste de integrao e implementao; CAT correo aps teste; ADM Administrao/Anlise de Dados;
DOC - Documentao

Gestão de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gestão de Software

Transféré par

Droits d'auteur :

Formats disponibles

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia UCB

Processo de Implantao de Gesto de Qualidade de

Processo de Implantao de Gesto de

A proposta deste trabalho demonstrar a viabilidade da implantao de um processo

Toms Roberto Cotta Orlandi

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

II. Caracterizao dos Produtos e dos Processos

Este captulo visa apresentar os modelos de qualidade de software mais aplicados

O Modelo ISO 12207 de Qualidade

A norma ISO/IEC 12207 objetiva auxiliar organizaes na definio de seus

O Modelo SPICE (ISO/IEC 15504) de Qualidade

Apresentar claramente a abordagem GQM e sua forma de aplicao;

A iniciativa de se estabelecer um padro internacional para melhoria de processos

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

crises. Durante as crises, normalmente, so abandonadas as fases de planejamento, havendo

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

No nvel otimizado, toda a organizao est voltada para um contnuo processo de

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Executar (Do): executar a implementao do plano e a coleta de dados.

gerenciamento quantitativo do processo; e

foco no processo da organizao;

O Paradigma de Aperfeioamento da Qualidade - QIP

O Processo do Paradigma de Aperfeioamento da Qualidade

A abordagem PDCA articulada em quatro fases: [15]

H um grande nmero de caractersticas de projetos e de ambiente que

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

fatores dos recursos - mquinas de produo e desenvolvimento, tempo calendrio,

A definio realista dos objetivos importante para a caracterizao do

O QIP baseia-se na idia de que o aperfeioamento do processo e do

O Processo da Fbrica de Experincias

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

concebido. Melhorias no processo sero baseadas na compreenso do relacionamento entre

O Modelo Goal Question Metric (GQM)

A abordagem GQM parte da premissa de que para uma organizao

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

3. Nvel Quantitativo: representa os dados que sero apurados/medidos (Metric). Um

A segunda fonte de informaes a descrio dos processos e produtos

Assim, um modelo GQM uma estrutura hierrquica que inicia com a

G 1. Como se pode caracterizar o objeto (produto, processo ou recurso) com o

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Universidade Catlica de Braslia, Mestrado em Informtica, Qualidade de Software, UCB-QSW-TR-2001/07

Como exemplo de aplicao da abordagem Goal/Question/Metric, apresenta-se a

Atendimento das solicitaes

Qual o tempo corrente no atendimento de

% de casos acima do limite superior

O processo (documentado) no atendimento de

Mdia de tempo de execuo * 100

solicitaes fielmente seguido?

Avaliao subjetiva do gerente de projetos

% de excees identificado durante as revises

Qual o desvio do prazo no atendimento de

solicitaes em funo do estimado?

Mdia da execuo mdia prevista * 100

O desempenho est melhorando?

Avaliao subjetiva do gerente de projeto

H melhoria visvel no desempenho?