Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília – UCB
Mestrado em Informática
Qualidade de Software
Processo de Implantação de Gestão de Qualidade de
Software em Empresas Nacionais:
O Estudo de Caso do Tribunal de Contas da União
Tomás Roberto Cotta Orlandi
Resumo
Processo de Implantação de Gestão de
Qualidade de Software em Empresas
Nacionais:
O Estudo de Caso do Tribunal de Contas da
União
A proposta deste trabalho é demonstrar a viabilidade da implantação de um processo
contínuo de avaliação de qualidade de software em empresas brasileiras, apresentando a
abordagem GQM – Goal, Question, Metric , situando-a no contexto de outras abordagens
de avaliação e qualidade de software, que atende não só as expectativas em relação à uma
melhora de qualidade dos produtos, mas também a um incremento na produtividade das
equipes de trabalho.
Palavras-chave
abordagem GQM, CMM, Fábrica de Experiência, ISO, QIP, Qualidade de software,
SPICE.
Tomás Roberto Cotta Orlandi
Abstract
Orientador
Prof. Dr. Walcélio L. Melo
The objective of this article is to show the viability of introducing a continuos evaluation
process of software quality in Brazilian’s companies, presenting the GQM–Goal, Question,
Metric approach, comparing it with others software’s quality approaches, attending the
wishes of a better software product’s quality and best productivity of the team working.
Keywords
CMM, Experience Factory, GQM Approach, ISO, QIP, Software Quality, SPICE
Brasília (DF), dezembro de 2000
1
2
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
I. Introdução
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
II. Caracterização 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 avaliação e
qualidade de software como ISO,CMM, SPICE e QIP. A implantação da abordagem GQM
em empresa nacional, será mostrada através da utilização de um processo padronizado de
desenvolvimento, conversão e manutenção de software.
Este capítulo 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 avaliação e medição, 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 implantação de um processo contínuo de
avaliação de software nas empresas nacionais, que atenda não só as expectativas em relação
à uma melhora de qualidade dos produtos, mas também a um incremento na produtividade
das equipes de trabalho, incorporando naturalmente a cultura de produzir software com
testes, inspeções e medições de resultados.
Será também demonstrada a viabilidade da manutenção de um programa
permanente de qualidade de software, através do treinamento, implantação e aplicação da
abordagem GQM, visando uma melhora contínua na qualidade e na produtividade de
sistemas. Como produto final são gerados modelos quantitativos, baseados em dados
captados, que viabilizam uma análise da qualidade dos software produzidos, possibilitando
uma comparação qualitativa do processo de desenvolvimento de sistemas com organizações
externas.
Em decorrência da implantação dessa abordagem, demonstra-se a implementação e
a manutenção de uma estrutura, separada logicamente do desenvolvimento de software, a
Fábrica de Experiências. A Fábrica de Experiências (Experience Factory)[1] tem por
objetivo armazenar as experiências dos projetos desenvolvidos, em termos de soluções e
implementações adotadas, para que as equipes possam fazer reuso posterior das soluções e
dos códigos já desenvolvidos. As soluções “empacotadas” na Fábrica de Experiências
poderão ser utilizadas também por organizações semelhantes à estudada, ou seja, empresa
nacional pública ou privada.
Objetivos Específicos:
A norma ISO/IEC 12207 objetiva auxiliar organizações na definição de seus
processos de software oferecendo uma guia para definição das atividades e tarefas a serem
desempenhadas durante as principais etapas que envolvem a construção de um produto de
software. A norma agrupa processos de software em três grandes classes – processos
fundamentais, processos de apoio e processos organizacionais.
A categoria de processos fundamentais compreende os processos que executam as
principais funções relacionadas ao ciclo de vida de software. Processos de apoio servem
como auxiliares ao processo fundamental de construção, contribuindo para o sucesso e a
qualidade do produto gerado. Processos organizacionais são responsáveis pelo
acompanhamento do desenvolvimento, compreendendo processos para gerência, 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 realização. Contudo, a
norma não especifica detalhes de como implementar ou executar estas tarefas e atividades.
Este é um dos motivos pelo qual o presente trabalho não abordará o modelo ISO 12207 de
qualidade pois, no contexto de empresas nacionais em questão, necessitamos especificar os
detalhes de como implementar processos de qualidade de software nas organizações.
O Modelo SPICE (ISO/IEC 15504) de Qualidade
§ Apresentar claramente a abordagem GQM e sua forma de aplicação;
§ Situar a abordagem GQM no contexto geral da qualidade de software;
§ Mostrar a viabilidade da implantação 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 manutenção de software, as atividades de testes, inspeções e
medições de resultados;
§ Mostrar o conceito e a forma de implementação da Fábrica de Experiências.
A iniciativa de se estabelecer um padrão 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 elaboração de um padrão ou infra-estrutura (framework)
para avaliação de processos de software e para a determinação de sua capacitação ISO/IEC 15504.
3
4
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
A futura norma ISO/IEC 15504 define processos e práticas que podem ser
implementados para estabelecer e aprimorar a capacidade de aquisição, desenvolvimento,
manutenção, operação e suporte de software em organizações. Estas práticas são
organizadas utilizando-se uma arquitetura que combina duas perspectivas: uma perspectiva
funcional (análoga à perspectiva da norma ISO/IEC 12207), compreendendo quais os
processos que devem existir numa organização e uma outra perspectiva que avalia o nível
de capacitação de cada um destes processos (análoga ao CMM). O uso da norma permite
que as organizações possam perceber a existência ou não de processos específicos, bem
como a capacitação dos que existem, traçando caminhos para a melhoria.
crises. Durante as crises, normalmente, são abandonadas as fases de planejamento, havendo
um incremento exagerado e desordenado das etapas de codificação e teste.
Para esse nível, o CMM não apresenta áreas chave. A caracterização do
comportamento no nível 1 é colocado apenas como base de comparação para os demais
níveis.
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 avaliação do grau de maturidade das organizações quanto à
capacidade produtiva de software. [13]
O CMM representa uma proposição de recomendações para empresas, cujo negócio
seja a produção de software, que pretendam incrementar a capacidade (ou qualidade) do
processo de desenvolvimento de sistemas.
O modelo apresentado pelo CMM não se preocupa em “como” a organização
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 ações de implementação de um modelo de qualidade de software em
organizações brasileiras, pois, trata-se de um modelo consagrado e utilizado mundialmente
por organizações produtoras de software.
O CMM classifica as organizações produtoras de software em cinco grupos (ou
níveis) 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 alcançados para
que a organização seja considerada como tendo atingido determinado nível.
Os cinco níveis de maturidade propostos pelo CMM, em grau crescente, são:
inicial; repetitivo; definido; gerenciado; e otimizado.[13]
Nível 1 - Inicial
Nesse nível, o processo de produção de software é efetuado de maneira empírica e
ocasionalmente, até mesmo, de forma caótica. Poucos processos são definidos e o sucesso
dos projetos depende de esforços individuais e atitudes heróicas dos desenvolvedores.
Uma característica das organizações classificadas nesse nível é o comprometimento
além da capacidade. A dificuldade da organização em cumprir os compromissos
estabelecidos é acompanhada pela sobrecarga do corpo técnico, que fica impossibilitado de
seguir as práticas recomendadas para a engenharia de software, gerando, então, sucessivas
5
Nível 2 - Repetitivo
Nesse nível de maturidade, existe um gerenciamento básico de projetos com a
finalidade maior de acompanhar custos e cronogramas. Porém, o processo aplicado ao
desenvolvimento de novos projetos constitui-se basicamente na repetição de práticas já
experimentadas com sucesso em projetos similares anteriormente desenvolvidos.
Os processos de desenvolvimento podem, assim, ser diferentes de projeto para
projeto em organizações considerados no nível 2. O que deve existir, porém, é uma política
que sirva como guia no estabelecimento de uma gerência apropriada de processos.
Os compromissos assumidos, então, passam a ser mais realistas, pois baseiam-se,
agora, em resultados observados em projetos anteriores. A gerência de projetos pode
acompanhar melhor os custos, o cronograma e o atendimento aos requerimentos.
As áreas chave para o nível 2 estão focadas nas práticas que concernem ao
gerenciamento de projetos:
• gerência de requisitos;
• planejamento do projeto;
• acompanhamento do projeto e de desvios;
• gerenciamento de subcontratados;
• controle de qualidade; e
• gerência de configurações.
Nível 3 - Definido
No nível definido, um processo padrão (ou vários) para desenvolvimento e
manutenção de software é documentado e usado por toda a organização. Esse padrão inclui
as atividades de engenharia e gerenciamento de software integrados em um todo coerente.
O processo padrão é utilizado (e modificado, se necessário) para auxiliar os gerentes
e desenvolvedores em uma produção mais eficiente. Um programa de treinamento é
implementado em toda a organização para assegurar que o corpo técnico e os gerentes
adquiram o conhecimento e habilidade necessários à execução de suas tarefas.
A medida que acontecem, os projetos utilizam-se do processo padrão e fazem
adaptação desse modelo para ajustá-lo às suas peculiaridades. Sendo, então, esse “processo
ajustado” o que realmente é usado nas atividades do projeto.
6
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
O que difere o nível 3 do nível anterior, além das áreas chave relacionadas a seguir,
basicamente, é o fato de existir neste nível o “processo padrão” definido, documentado,
integrado, ajustado e, principalmente, seguido por toda a organização.
O nível 3 do CMM pode ser resumido pelas palavras “padrão e consistência”, uma
vez que, nesse nível, as atividades de engenharia e gerenciamento no processo produtivo de
software são estáveis e repetitivas. Com uma “linha de produção” estabelecida, os custos, o
cronograma e as funcionalidades estão sob controle e qualidade do software é melhor
acompanhada.
As áreas chave definidas para o nível 3 estão voltadas aos aspectos da organização e
do projeto, no sentido de prover uma infra-estrutura que possibilite a institucionalização de
um efetivo processo de engenharia e gerência de software para todos os projetos. São áreas
chave para o nível 3:
• foco no processo da organização (ou estabelecimento de responsabilidades na
organização para atividades relativas à produção de software);
• definição do processo para a organização;
• programa de treinamento;
• gerenciamento integrado;
• engenharia de produtos;
• coordenação intergrupos (ou interação entre grupos de engenharia de software);
• revisão de pares.
Nível 5 - Otimizado
Nível 4 - Gerenciado
Nesse nível, passam a ser coletadas e analisadas métricas detalhadas relativas ao
processo e à qualidade do produto para acompanhamento e controle do processo. Nesse
nível, processo e produto são quantitativamente entendidos e controlados.
No nível gerenciado, a organização define objetivos de qualidade que devem ser
alcançados para produtos e processos. As atividades de produção de software mais
importantes são acompanhadas por meio de um programa de medidas da organização afim
de que possam ser observadas a produtividade, a qualidade, etc. Um banco de dados para a
organização como um todo é usado para coletar e analisar os dados disponíveis extraídos
dos projetos. O processo de software é equipado com um processo de coleta de medidas
consistente e bem definido.
O nível 4 do CMM pode ser resumido como sendo “quantificado e previsível”
porque os processos são medidos e as operações são realizadas dentro de limites
quantitativos. Esse nível permite que a organização trabalhe com segurança na previsão do
desempenho dos processos e da qualidade dos produtos.
As áreas chave para o nível 4 estão direcionadas ao entendimento quantitativo do
processo e do produto:
• gerenciamento quantitativo do processo; e
• gerenciamento da qualidade do produto.
7
No nível otimizado, toda a organização está voltada para um contínuo processo de
melhoria. A organização busca identificar, de forma pró-ativa, os pontos fortes e fracos do
processo, com o objetivo de evitar erros e melhorar a eficiência. Dados reais de processos
são usados para análise da relação custo/benefício, para implementação de novas
tecnologias ou para propor mudanças ao processo produtivo.
As equipes de software em organizações no nível 5 trabalham na análise de defeitos
do processo afim de determinar suas causas, avaliar o processo e prevenir manifestações de
erros conhecidos e recorrentes, e, ainda, disseminar os conhecimentos adquiridos pela
organização.
Em qualquer sistema, existe um desperdício contínuo, em forma de retrabalho,
simplesmente por causa de imprevistos. Esforços no sentido de eliminar esses desperdícios
resultam em mudanças no sistema pela recondução dessas “causas comuns” de ineficiência.
Embora esses esforços para reduzir desperdícios ocorram em todos os níveis de maturidade,
essa preocupação constitui o foco do nível 5.
O nível 5 do CMM pode ser caracterizado como “de melhoria contínua” porque as
organizações identificadas no nível 5 estão continuamente empenhadas em melhorar a
capacidade de seus processos. A melhoria pode surgir tanto em função do progresso do
próprio processo quanto da aplicação de novas tecnologias e métodos. A aplicação de novas
tecnologias ou mudanças no processo são planejadas e gerenciadas como tarefas rotineiras.
As áreas chave que constituem o nível 5 buscam enfocar os assuntos que os projetos
precisam observar para promover um incremento contínuo e mensurável da qualidade do
processo de software. São as seguintes as áreas chave para o nível otimizado:
• prevenção de erros;
• gerenciamento de mudança tecnológica; e
• gerenciamento de mudanças no processo.
8
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Como mostra a figura 1, o CMM, pode ser representado como uma estrutura de
cinco níveis de maturidade:
• Executar (Do): executar a implementação do plano e a coleta de dados.
• Verificar (Check): verificar a melhoria do desempenho usando os dados
coletados dos processos e tomando ações corretivas necessárias.
• Agir (Act): atuar no sentido de padronizar as melhorias e incorporá-las ao
processo.
Otimizado
5
Gerenciado
4
Definido
3
Repetitível
2
•
•
•
•
Inicial
1
•
•
•
•
•
•
•
•
•
• prevenção de erros;
• gerenciamento de mudança tecnológica;
e
• gerenciamento de mudanças no processo
• gerenciamento quantitativo do processo; e
• gerenciamento da qualidade do produto.
foco no processo da organização;
definição do processo para a organização;
programa de treinamento;
gerenciamento integrado;
engenharia de produtos;
coordenação intergrupos;
revisão de pares.
gerência de requisitos;
planejamento do projeto;
acompanhamento do projeto e
de desvios;
gerenciamento de
subcontratados;
controle de qualidade; e
gerência de configurações.
Por sua vez, o QIP desenvolve-se por meio dos seguintes passos:[1]
• Caracterizar: conhecer o ambiente com base nos dados e modelos disponíveis e na
instituição. Estabelecer os fundamentos com os processos existentes na organização e
caracterizá-los criticamente.
• Definir os objetivos: com base na caracterização inicial e nas capacidades estratégicas
da organização, definir com objetivos quantificáveis o que seriam projetos bem
sucedidos e avaliar o desempenho e melhoria da organização. As exceções aceitáveis
são definidas com base nos fundamentos estabelecidos no passo de caracterização.
• Escolher os processos: com base na caracterização do ambiente e dos objetivos
definidos, escolher os processos apropriados para melhoria bem como as ferramentas e
métodos 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 estão sendo coletados para avaliação do alcance dos objetivos.
• Analisar: ao final de cada projeto específico, analisar os dados e informações
acumuladas para avaliar as práticas correntes, identificar problemas, registrar achados, e
fazer recomendações para melhoria de futuros projetos.
• Empacotar: Consolidar a experiência adquirida em forma de refinamento do modelo
praticado ou mesmo pela adoção de novos modelos e, ainda, por meio de outras formas
de estrutura de conhecimento alcançadas no último ou em processos anteriores e
armazená-las em uma base de experiências, disponível para uso futuro.
Uma caracterização apropriada e sem ambigüidades do ambiente é um
pré-requisito para a aplicação correta do paradigma. Essa caracterização requer a
classificação minuciosa do projeto, permitindo a identificação de classes de projetos com
características e objetivos similares. Assim, pode-se estabelecer o ambiente adequado ao
projeto corrente. Com a correta caracterização obtém-se um contexto para a definição de
objetivos, para a reutilização de experiências e produtos, para a seleção de processos, para a
avaliação e comparação de resultados, e para uma maior exatidão nas previsões.
Figura 1
O Paradigma de Aperfeiçoamento da Qualidade - QIP
O Quality Improvement Paradigm – QIP (ou Paradigma do
Aperfeiçoamento da Qualidade), desenvolvido por Victor Basili e outros [1], é o resultado
da aplicação do método científico para resolução 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 indústria para implementação de planos de
gerenciamento da qualidade.
O Processo do Paradigma de Aperfeiçoamento da Qualidade
A abordagem PDCA é articulada em quatro fases: [15]
• Planejar (Plan): Definir os objetivos e metas do aperfeiçoamento da qualidade,
determinar métodos para alcançar esses objetivos e preparar um plano de
implementação.
Há um grande número de características de projetos e de ambiente que
afetam o processo de desenvolvimento e o produto de software, tais como:
• fatores de pessoal - números de empregados, nível de especialização, organização de
grupo, experiências;
• fatores relacionados ao problema - domínio da aplicação, suscetibilidade a mudança,
limites do problema;
• fatores do processo - modelos de processo, métodos, técnicas, ferramentas, linguagem
de programação, outros documentos;
• fatores do produto - implantação/entrega, tamanho do sistema, qualidades requeridas;
9
10
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
• fatores dos recursos - máquinas de produção e desenvolvimento, tempo calendário,
orçamento, software existente.
A Fábrica de Experiência
A definição realista dos objetivos é importante para a caracterização do
ambiente. É preciso estabelecer modelos e objetivos para os processos e para os produtos.
Esses objetivos precisam ser mensuráveis, dirigidos pelos modelos, e definidos para uma
variedade de perspectivas, tais como, a do usuário, do cliente, do projeto, da organização,
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 métricas. Essa abordagem representa uma sistemática
para ajuste e integração de objetivos com modelos de processos, produtos e perspectivas de
qualidade de software, baseadas em necessidades específicas do projeto e da organização.
Existe uma variedade de dados que podem ser coletados:
• Dados sobre recursos - incluem esforço por atividade, fase, tipo ou pessoal, tempo de
computador, tempo calendário, etc;
• Dados de mudanças e falhas – dizem respeito a mudanças e falhas por vários esquemas
de classificação;
• Métricas do processo – relativas à definição e à conformidade dos processos, e aos
dados concernentes ao entendimento do domínio da aplicação;
• Dados do produto – quanto às características lógicas e físicas do produto e quanto à
utilização e contexto da informação.
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 idéia de que o aperfeiçoamento do processo e do
produto de software requer uma acumulação contínua de experiências (aprendizado) em
formato que pode ser efetivamente entendido e modificado (modelos de experiências) em
um repositório integrado (base de experiências) que pode ser acessado e modificado em
conformidade com as necessidades do projeto corrente (reutilização). Para apoiar o
paradigma de aperfeiçoamento foi desenvolvida um estrutura distinta do desenvolvimento
de software denominada Fábrica de Experiências (Experience Factory – EF).[1]
A Fábrica de Experiências é uma estrutura física e/ou lógica que apoia o
desenvolvimento de sistemas por meio da análise e sintetização de todos os tipos de
experiências, agindo como um repositório para essas experiências e fornecendo-as a outros
projetos na medida da demanda, representa um paradigma de mudança 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
Organização Projeto, para o desenvolvimento de sistemas; e a Fábrica de Experiências, para
o empacotamento de conhecimentos adquiridos. Na Organização Projeto, são resolvidos os
problemas, na Fábrica de Experiência, são entendidas as soluções e empacotadas as
experiências para futura reutilização.[1]
O Processo da Fábrica de Experiências
A Fábrica de Experiências representa o grupo que trabalha na base do
conhecimento da engenharia de desenvolvimento de software como um bem da corporação,
enquanto a Organização Projeto representa o grupo cujo trabalho é usar aquele
conhecimento para produzir os mais avançados produtos da corporação.
A Organização Projeto caracteriza o projeto e seu ambiente, define os
objetivos para o projeto e escolhe o processo apropriado dadas as características e
objetivos. O suporte ao projeto é provido pela Fábrica de Experiências pela articulação das
características, formulação de objetivos e seleção do conjunto apropriado de experiências
passadas para uso no projeto. [1]
Pela abordagem da Fábrica de Experiências, a reutilização não representa
apenas o reaproveitamento de código mas de todos os tipos de experiências e do contexto
que envolve essas experiências, reconhecendo que as experiências nem sempre são
reutilizáveis como foram concebidas, antes elas precisam ser ajustadas e empacotadas para
tornar mais fácil o seu acesso e reutilização.
Na prática, a abordagem QIP/EF é implementada colocando-se
primeiramente a organização em seu lugar, a partir de sua caracterização. Isso significa a
coleta de dados para estabelecimento dos fundamentos (baselines) e avaliação dos pontos
fortes e fracos da organização a fim de se obter o enfoque nos negócios e objetivos da
empresa para o processo de melhoria. A coleta inicial de dados é crítica também para a
definição da qualidade do produto que deveria ser aprimorada pelo programa.
Dessa forma, a organização define em si mesma um contínuo
aperfeiçoamento, mesmo se o nível de maturidade não for muito alto, porque ela aprende a
partir do seu próprio negócio, não de um modelo de processo ideal, externamente
12
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
concebido. Melhorias no processo serão baseadas na compreensão do relacionamento entre
processo e produto na própria organização. A introdução de novas tecnologias será
motivada por problemas locais e o corpo técnico estará mais disposto a utilizá-las.
A abordagem GQM
O Modelo Goal Question Metric (GQM)
Esta apresentação da abordagem Goal/Question/Metric (GQM), utilizada
como abordagem na definição 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 mensuração para avaliação e retorno. O procedimento de
medir é uma forma de criar uma memória corporativa e um auxílio na resposta de várias
questões associadas ao estabelecimento de um processo de software.
Um processo de medidas estabelecido auxilia no planejamento de novos
projetos, na determinação de pontos fortes e fracos de produtos e processos, na
racionalidade para adoção ou refinamento de técnicas em uso, e ainda, na avaliação da
qualidade de processos ou produtos específicos. Medir também 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 ação.
Algumas questões que poderiam, por exemplo, ser respondidas a partir de
um sistema de medida, seriam :
• Qual o custo de um novo projeto?
• Qual a freqüência de certos tipos de erros?
• Qual o impacto da aplicação de determinada técnica na produtividade dos projetos?
De acordo com vários estudos realizados sobre a aplicação de métricas e
modelos em ambiente industrial, o processo de medida para trazer resultados precisa ser:
voltado para objetivos específicos;
aplicado a todo o ciclo de vida dos produtos, processos e recursos;
adaptado às características e ao contexto da organização, do ambiente e dos objetivos.
Como na figura 3, o modelo hierárquico GQM, pode ser representado da seguinte forma:
OBJETIVO 1
QUESTÃO
MÉTRICA
OBJETIVO 2
QUESTÃO
MÉTRICA
QUESTÃO
MÉTRICA
A abordagem GQM parte da premissa de que para uma organização
adotar um processo de medida definitivo é necessário primeiramente estabelecer os
objetivos da própria organização 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 informações da organização, se essas
informações podem ser quantificadas e em que momento podem ser colhidas, e se podem
ser analisadas em função dos objetivos.[2]
A abordagem foi definida originalmente para avaliação de defeitos em um
conjunto de projetos no ambiente da NASA Goddard Space Flight Center. A aplicação
envolveu um conjunto de estudos de casos e foi expandida para incluir várias abordagens
experimentais. Embora a abordagem tenha sido usada originalmente para definir e avaliar
os objetivos de um projeto específico, seu uso foi expandido para contextos maiores.
A abordagem foi usada como um passo dentro de outra técnica, o Quality
Improvement Paradigm (discutido anteriormente neste trabalho), processo de melhoria da
qualidade que se utiliza de um ambiente operacional restrito, a Fábrica de Experiência
(Experience Factory), que pode, por sua vez, ser entendida como um ambiente
experimental com o objetivo de produção e/ou avaliação de software e processos para uso
nos demais projetos.
Neste trabalho, a utilização de todas estas técnicas, será norteada pelo
modelo CMM de qualidade de software. A correta utilização destas técnicas permitirá à
organização galgar os níveis de maturidade, através da realização das suas áreas chave para
cada nível alcançado.
O resultado da aplicação da abordagem GQM é a especificação de um
sistema de medidas objetivando um conjunto particular de casos e de regras na
interpretação dos dados medidos.
O modelo de mensuração resultante possui três níveis:[2 - p 3]
1. Nível 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 observação. Podem ser objetos de medida:
− Produtos - quaisquer documentos e produtos que são gerados durante o ciclo de vida
do sistema: especificações, projetos, programas, lotes de testes etc.
− Processos - atividades relacionadas ao desenvolvimento de software normalmente
associadas ao dispêndio de tempo: fase de especificação, de projeto, de teste, de
interação etc.
− Recursos - itens consumidos no processo para gerar os produtos: pessoal,
equipamentos, software, espaço físico etc.
2. Nível Operacional: diz respeito a um conjunto de questões (Question) usado para
caracterizar a forma de julgamento e garantir que o objetivo, definido no modelo, será
atingido. As questões tentam caracterizar o objeto a ser medido (produto, processo ou
recurso) com respeito a um padrão de qualidade e buscam identificar a qualidade desse
objeto a partir de determinado ponto de vista.
MÉTRICA
Figura 3
13
14
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
3. Nível Quantitativo: representa os dados que serão apurados/medidos (Metric). Um
conjunto de dados é associado às questões formuladas a fim de que sejam traduzidas
quantitativamente. Esses dados podem ser objetivos ou subjetivos.
- Objetivos - se dependem apenas do objeto que está sendo medido e não do ponto de
vista em que são tomados. Por exemplo: número de versões de um documento,
horas de pessoal gastas em determinada tarefa, tamanho de um programa etc.
- Subjetivos - se dependem, além do próprio objeto que está sendo medido, do ponto
de vista em que será analisada a medida. Exemplo: facilidade de leitura de um texto,
nível de satisfação do usuário etc.
A segunda fonte de informações é a descrição dos processos e produtos
da organização, ou, pelo menos, daqueles que estão dentro do escopo do programa de
medidas que se pretende efetuar. A partir desse fonte, com a especificação dos modelos de
processos e produtos, dentro da maior formalidade possível, deriva-se a coordenada do
“objeto” para o objetivo em questão.
A terceira fonte de informações é o modelo do negócio da organização,
que fornece a coordenada “ponto de vista”. É evidente que nem todos os assuntos e
processos são relevantes para todos os pontos de vista na organização. Assim, há que se
fazer uma análise da relevância dos objetivos para a organização, antes de se considerar
concluída a lista de objetivos.
Dessa forma, conclui-se a definição dos “objetivos” para o modelo GQM,
tomando-se em conta a estrutura e os objetivos da organização. A partir da especificação
de cada objetivo podem-se derivar questões significantes que quantificam o objetivo.
Geralmente, são feitos pelo menos três grupos de questões:
Assim, um modelo GQM é uma estrutura hierárquica que inicia com a
definição de um objetivo (goal), especificando o propósito da medição, os objetos e
aspectos desses objetos que serão avaliados, e o ponto de vista em que as medidas serão
analisadas. O objetivo é, então, refinado em diversas questões (question). Cada questão é,
por sua vez, delineada nas métricas (metric).
Há que se observar que uma mesma métrica pode ser usada para
responder diferentes questões de um mesmo objetivo; diversos modelos GQM podem,
também, ter questões e métricas em comum, desde que seja assegurado que quando da
coleta das métricas 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 organização, para a divisão ou para
o projeto, tais como satisfação do usuário, entrega de serviço no prazo, melhoria de
desempenho.[2 – p 5]
A partir da identificação dos objetivos e com base em modelos do objeto
em avaliação, derivam-se questões que possam definir esses objetivos de forma mais
completa. Por exemplo, se o objetivo é caracterizar um software quanto a determinadas
qualidades (e.g., portabilidade), então faz-se necessária a escolha de um modelo para o
produto que qualifique esses interesses (e.g., relação de características funcionais que
precisam ser implementadas para diferentes arquiteturas).
O próximo passo consiste em especificar as medidas que devem ser
coletadas a fim de responder às questões 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 avaliação e análise.
O processo de identificação de objetivos é crítico para o sucesso da
aplicação da abordagem GQM, e será apoiado por passos metodológicos específicos. Para a
consecução de um objetivo concorrerão três fontes básicas de informação[2 – p 6].
A primeira fonte diz respeito à política e à estratégia da organização que
aplica a abordagem GQM. A partir dessa fonte, com a análise da política da corporação,
dos planos estratégicos e, ainda, levando-se em conta os interesses relevantes na
organização, derivam-se o “aspecto” e o “propósito” 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 solicitações de mudanças num
sistema em manutenção?
Q 2: Existe um processo (documentado) no atendimento às solicitações de
mudanças?
G 2. Como se podem caracterizar os atributos relevantes do objeto em observação
num modelo GQM específico?
Exemplo:
Q 1: Qual o desvio do prazo no atendimento de solicitações em função do
estimado?
Q 2: O desempenho da equipe no atendimento de solicitações vem melhorando?
G 3. Como podem ser avaliadas as características do objeto que são relevantes com
respeito ao aspecto tratado no modelo GQM?
Exemplo:
Q1: O desempenho tem sido satisfatório sob o ponto de vista do gerente de
projeto?
Q2: Há melhoria visível no desempenho?
Uma vez que as questões tenham sido formuladas, deve-se proceder a associação
destas com as métricas 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 disponíveis e sejam confiáveis.
− Maturidade dos objetos em medição - devem-se aplicar medidas objetivas para
objetos com maior nível de maturidade, e avaliações subjetivas quando se trabalha
com objetos instáveis ou informais.
− Aprendizado do processo - o uso de modelos QGM requer sempre refinamento e
adaptação. Assim, as medidas definidas devem auxiliar não somente na análise do
objeto medido, mas também na avaliação do próprio modelo.
16
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Como exemplo de aplicação da abordagem Goal/Question/Metric, apresenta-se a
suposição de modelo em que se pretenda melhorar o prazo no atendimento às solicitações
de mudança para um determinado sistema em fase de manutenção. O objetivo definido
deverá explicitar o propósito (melhorar), o processo (atendimento de solicitações de
mudança), o ponto de vista (gerente de projeto), e o aspecto a ser observado (prazo de
execução). Esse objetivo deve ser refinado em uma série de questões, que serão
respondidas a partir da comparação do tempo coletado com média. O modelo GQM
completo seria: [2 – p 8]
Métricas
Objetivo
Propósito
Melhoria
Aspecto
Prazo
Objeto (processo)
Atendimento das solicitações
Ponto de vista
Gerente de projetos
Questão
Q1
Métricas
M1
Qual o tempo corrente no atendimento de
solicitações de mudança?
Média de tempo de cada fase
M2
Desvio padrão
M3
% de casos acima do limite superior
Q2
O processo (documentado) no atendimento de
Questão
M8
Média de tempo de execução * 100
Padrão de tempo para a fase
Uma vez que o modelo GQM esteja definido, faz-se necessária a seleção
das técnicas, 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 organização.
Conclui-se, então, que a abordagem Goal/Question/Metric é uma
abordagem para definição de um mecanismo de mensuração que possibilite o
acompanhamento e avaliação do processo operacional de produção de software.
solicitações é fielmente seguido?
Métricas
M4
Avaliação subjetiva do gerente de projetos
M5
% de exceções identificado durante as revisões
Questão
Q3
Qual o desvio do prazo no atendimento de
Métricas
M6
solicitações em função do estimado?
M7
Média da execução – média prevista * 100
Média da execução
Avaliação subjetiva do gerente de projeto
Questão
Q4
O desempenho está melhorando?
Métricas
M8
Questão
Q5
Métricas
M7
Avaliação subjetiva do gerente de projeto
Questão
Q4
Há melhoria visível no desempenho?
Média de tempo de execução * 100
Padrão de tempo para a fase
O desempenho tem sido satisfatório sob o ponto de
vista do gerente de projeto?
17
18
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
III. O Ambiente em que foi Implementado o Modelo GQM
Neste capítulo são apresentadas as principais características e a missão
institucional da instituição aonde foi implantado o processo de melhoria contínua usando o
QIP/GQM - o Tribunal de Contas do Distrito Federal e, inserida nessa missão, o papel
desenvolvido pelo setor de informática.
A missão do TCDF
As competências constitucionais do Tribunal de Contas do Distrito
Federal são:[3]
• apreciar, mediante emissão de parecer prévio, as contas anuais do Governador
e julgar aquelas relativas aos administradores e demais responsáveis por
dinheiro, bens e valores públicos;
• apreciar, para fins de registro, a legalidade dos atos de admissão de pessoal e
de concessão de aposentadorias, reformas e pensões;
• avaliar a execução das metas estabelecidas no plano plurianual, nas diretrizes
orçamentárias e no orçamento anual;
• realizar inspeções e auditorias de natureza contábil, financeira, orçamentária,
operacional e patrimonial nas unidades administrativas dos Poderes Executivo
e Legislativo;
• fiscalizar as aplicações do Poder Público em empresas de cujo capital social o
Distrito Federal participe de forma direta ou indireta;
• fiscalizar a aplicação de recursos repassados ou recebidos pelo Distrito
Federal, a qualquer título;
• atender às solicitações da Câmara Legislativa relativas às atividades de
Controle Externo;
• aplicar, em caso de ilegalidade ou irregularidade de contas, as sanções
previstas em lei e sustar, se o Tribunal não for atendido, a execução de ato
impugnado.
No planejamento estratégico para o período de 1999 a 2003 [7] é dado
especial relevo ao estabelecimento da missão institucional do TCDF com base nas
competências constitucionais acima e nos arts. 77 e 78 da Lei Orgânica do Distrito Federal
(LODF) [3]. Esses artigos elucidam que a fiscalização contábil, financeira, orçamentária,
operacional e patrimonial dos órgãos e entidades da administração do Distrito Federal,
quanto à legalidade, legitimidade, economicidade, aplicação das subvenções e renúncia de
receitas é exercida pela Câmara Legislativa - mediante controle externo e pelo sistema de
controle interno de cada Poder - com o auxílio do Tribunal de Contas do Distrito Federal.
Assim, inferida da essência dos citados dispositivos legais, a missão do
Tribunal pode ser enunciada como:
“Exercer o controle externo da administração dos recursos públicos do
Distrito Federal, em auxílio à Câmara Legislativa, zelando pela legalidade, legitimidade,
efetividade, eficácia, eficiência e economicidade na gestão desses recursos.”
19
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Releva notar que o atributo principal do papel da Corte de Contas
Distrital é garantir à sociedade segurança quanto à transparência e boa gestão dos recursos
arrecadados e gastos pelo Governo do Distrito Federal.
O papel do setor de informática
A política de informatização do Tribunal tem se pautado pela adoção de
soluções que associem qualidade, funcionalidade e economicidade.
Nesse contexto, ao setor de informática do Tribunal, denominado Núcleo
de Informática e Processamento de Dados – NIPD, compete apoiar a atividade de
fiscalização por meio da criação de sistemas de informação para acompanhamento dos
gastos públicos, avaliação de riscos e identificação de pontos críticos para auditoria,
produção, organização e divulgação de súmulas, decisões, votos, pareceres e instruções.
Para auxiliar essas atividades foram desenvolvidos, em especial a partir de 1996, vários
sistemas integrados em repositório de informações único.[8]
Ao NIPD compete também administrar a rede de microcomputadores,
executar e acompanhar a manutenção dos equipamentos de informática, bem como propor a
compra de bens e serviços relativos a tecnologia.
Adicionalmente, o setor mantém atualizado, com o apoio de diversas
Unidades do TCDF, o site www.tc.df.gov.br que permite a qualquer cidadão consultar os
documentos públicos produzidos no exercício do controle externo.
Por ser um ente público com especial apreço pela boa gestão dos
recursos, antes de efetuar investimentos são feitas análises de alternativas com vistas a
encontrar a melhor relação custo x benefício. Essa prática, aplicada ao setor de informática
será, como apresentado a seguir, motivadora do desenvolvimento de um processo de
produção de software.
Motivação para o estabelecimento do processo de desenvolvimento
Devido ao esforço necessário ao estabelecimento de um processo de
desenvolvimento, em especial quando se conta com poucos recursos humanos e materiais,
foi fundamental para o empenho na produção do mesmo a existência das motivações a
seguir relacionadas.
Melhoria da qualidade de produtos
Sendo o TCDF um órgão de informatização relativamente recente, a
partir de 1995, a equipe responsável pelo desenvolvimento de sistemas teve a oportunidade
de construir todo um conjunto de aplicações corporativas, com base nas necessidades
identificadas junto aos usuários, integrado e homogêneo. No entanto, o processo de
construção dessas soluções foi fortemente influenciado pela experiência profissional dos
técnicos e, apesar de ter sido um processo repetitivo, não era explicitado formalmente.
Hoje, contando com mais de dez aplicações em produção (150.000 linhas
de código fonte em Visual Basic, VB Script, Java, Java Script e HTML), que, portanto,
requerem manutenção, e sem modificação no quadro de desenvolvedores (2 analistas e 4
programadores), faz-se necessário aprimorar o processo de trabalho visando a elaboração
20
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
de produtos com menor número de erros possível, que observem a integração e a
homogeneidade dos sistemas já desenvolvidos.
Planejamento de novas demandas
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
IV. Implementando Um Processo De Melhoria Contínua –
Metodologia Empregada
Da forma atual, as estimativas de prazo para desenvolvimento ou
manutenção de sistemas são baseadas somente na experiência pessoal dos técnicos, sem um
acompanhamento efetivo dos prazos.
Essa situação, apesar de bastante comum nas organizações, é fator de
risco para a credibilidade do setor no caso de falha. Felizmente, desde 1995, os técnicos
tem acertado em suas previsões à administração da Casa. No entanto, o acompanhamento
sistemático do processo de desenvolvimento de software será fundamental para aperfeiçoar
as estimativas de prazos e recursos de novas demandas de sistemas.
Mudança de plataforma computacional
Com a relativa estabilização da demanda por desenvolvimento de novos
serviços e programas ao setor de informática do TCDF, a partir do final de 1998, a equipe
técnica iniciou trabalho de busca de alternativas com vistas a reduzir a necessidade de
investimentos em informática e identificou grupos de programas que, se substituídos,
levariam a essa redução.
Esse trabalho subsidiou a Presidência do Tribunal a decidir substituir, até
o final do ano de 2002, o sistema operacional Windows 95 pelo Linux nas estações de
trabalho do TCDF, proporcionando elevada redução de investimentos com hardware e
software [8].
Assim, com vistas a possibilitar essa substituição, será necessário
converter todos os sistemas desenvolvidos e configurar aplicativos de escritório que
possibilitem ao usuário final usufruir das mesmas funcionalidades hoje disponíveis.
Esse fato gerará intenso esforço de codificação que, sem
acompanhamento formalizado por meio de um processo de desenvolvimento definido e
utilizado por todos os técnicos, poderá inviabilizar a substituição da plataforma
computacional proposta pelo fracasso na conversão dos sistemas.
Para que seja possível substituir gradualmente as aplicações, optou-se por
utilizar a linguagem Java como padrão para a execução dessa tarefa. A linguagem de
programação Java permite disponibilizar os sistemas tanto para estações Windows 95 como
Linux e irá facilitar a reutilização de código.
Conforme podemos observar em, um processo contínuo 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 crítica atividade ao montar uma equipe é a aprovação da gerência
para todo o processo de melhoria do software na organização. É importante destacar que
nesse processo uma série de recursos devem ser alocados. A equipe designada para essa
tarefa, preferencialmente em tempo integral, deve ser composta de técnicos experientes,
com credibilidade dentro da organização, podendo contar também com a participação de
pesquisadores e consultores externos.
Hoje já é amplamente reconhecido que uma equipe de melhoria dos processos da
organização deve ser mantida em uma estrutura separada do desenvolvimento de software.
Essa equipe deve ter um mandato, ou tempo de duração bem definido, por exemplo: o
tempo de ser implantado um processo de qualidade com certificação 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 não se enquadravam plenamente no novo processo de informatização da
organização. O levantamento desses processos foi feito por 6 (seis) analistas de sistemas
durante um mês, dedicados exclusivamente à esta tarefa.
- Modelar os Processos Existentes:
Modelar os processos existentes em uma organização pode servir para vários
propósitos e agregar diversos benefícios. No contexto de melhoria de processos, modelos
de processos descritivos são úteis para se entender a maneira como as coisas funcionam e
para comunicar esse entendimento.
Algumas questões básicas que necessitam serem respondidas em uma modelagem
de processos são:
- Quais são as atividades do processo ?
- Quais são as dependências entre essas atividades ?
- Quando as atividades iniciam e terminam ?
- Quem são os atores que executam essas atividades ?
- Quais são as interdependências entre estes atores ?
21
22
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Fontes de informação para responder essas questões indicam que devem ser
utilizadas entrevistas com os membros da organização, inspeções nas documentações dos
processos (quando existirem), inspeções nas documentações de gerência do projeto e
também observações diretas na equipe de desenvolvimento.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
formulários. Foi selecionado o Sistema de Acompanhamento de Processos para uma análise
preliminar da metodologia a ser empregada. Foram levantados os problemas apresentados
na versão do sistema e classificadas a s falhas segundo critérios de gravidade estabelecidos
pelo gerente de informática.
- Definir e Documentar um Plano de Ação:
Os modelos de processos que foram desenvolvidos serão 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 estão sendo
úteis para o dia a dia dos seus trabalhos.
No TCDF, os prováveis processos a serem informatizados, foram modelados e
descritos de forma a explanar claramente as atividades intrínsecas de cada um, as
dependências entre essas atividades, o tempo de duração de cada uma delas, os atores que
as executam e as interdependências entre estes atores.
Uma vez que os processos estão modelados e seus pontos fortes e fracos estão bem
entendidos, um plano de ação deve ser definido. Para o Software Engineering Process
Group Guide o plano de ação é definido como: “Uma resposta formal, escrita da avaliação
(do processo) e o ‘mapa’ para sua melhoria”. O plano de ação é extremamente importante
por várias razões, dentre elas podemos citar: é solicitado para conseguir uma mudança do
orçamento para as próximas fases (avaliação das soluções, mudanças nos processos), é
crucial para transferir as informações corretas para a gerência e para os desenvolvedores
sobre a importância e as dificuldades do que será realizado.
- Conduzir uma Análise Qualitativa:
A meta desse estágio é identificar as causas e os mecanismos internos que indiquem
os problemas de custos e riscos elevados, relacionados à qualidade dos produtos entregues e
à eficiência do processo de desenvolvimento de software.
A equipe de melhoria de processos da organização, citada anteriormente, poderá ser
responsável pela análise contínua desse problemas. Uma modelagem dos processos bem
definida, ajudará a diferenciar os verdadeiros problemas dos aspectos irrelevantes. Nesse
contexto, existem três técnicas principais para se fazer a análise qualitativa: entrevistas
estruturadas, análise eventual dos problemas e questionários bem definidos e bem
desenhados. No contexto da análise qualitativa, essas técnicas se complementam, pois,
permitem uma checagem cruzada das informações levantadas.
A análise eventual é usualmente iniciada quando é reportado um problema vindo da
fase de testes, ou já da operação, de um determinado sistema. Para executar a análise
eventual alguns procedimentos são recomendados:
- Selecione um sistema, ou versão, relevante para a organização;
- Obtenha todos os relatórios de problemas;
- Classifique as falhas de programas de acordo com tipos e níveis de gravidade;
- Determine as causas de maior gravidade de falhas em termos de erros humanos e
falhas nos processos;
- Desenvolva recomendações para mudanças de processos e valide-as com os
participantes da análise eventual;
- Refine as linhas gerais da análise eventual e a nomenclatura utilizada para auxiliar
futuras análises.
A execução destes procedimentos assume que a organização tem processos bem
definidos e modelos organizacionais.
No TCDF, como os processos já haviam sido modelados e bem definidos, nesta fase
foram elaborados também os procedimentos de coleta de dados e desenhados os
23
-
-
Um possível esboço de alto nível de plano de ação pode ter o seguinte formato:
Melhora corporativa dos objetivos e motivações;
O plano de ação dos diversos grupos e participantes do processo de melhoria, suas
responsabilidades e prerrogativas;
Os passos da melhoria, suas conexões com os objetivos corporativos e seus critérios
de entrada e saída;
As fases que conduzem para os critérios de saída de cada passo de melhoria, os
riscos e incertezas associados a cada fase e os planos de contingência
correspondentes, os gerentes encarregados de monitorar e organizar as fases de
execução;
O conjunto de atividades envolvidas em cada fase de cada passo, os participantes
em cada atividade e suas responsabilidades;
O esforço e o custo para cada passo e fase, com intervalos indeterminados;
Os benefícios esperados baseados em experiências externas e em informações
existentes sobre qualidade e produtividade da organização.
Como Plano de Ação para o TCDF foi estabelecida uma metodologia que
contempla: procedimentos de desenvolvimento e manutenção de sistemas, estabelecimento
de um fluxo de solicitações de sistemas, o Sistema de Acompanhamento do
Desenvolvimento de Sistemas – SADS, que permite o registro do processo e a extração das
métricas estabelecidas (todos estes itens podem ser vistos no Anexo I deste documento).
- Montar um Programa de Medição:
A princípio um programa de medição é geralmente projetado para: prover uma base
quantitativa de comparações para futuras mudanças de processos, melhor entendimento dos
requisitos que tenha ou não sido identificados na análise qualitativa precedendo a medição,
e finalmente, fazer com que o processo de tomada decisões seja menos arriscado provendo
informações gerenciais corretas e no tempo certo sobre produtos de software e os processos
utilizados para desenvolvê-los. Em várias ocasiões já foi percebido que o êxito de um
24
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
programa de medições está no seu direcionamento para as metas e objetivos da
organização.
Para transferir a tecnologia para a memória da organização, 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 organização recompensa
a produtividade, então a introdução de métodos estruturados de análise e projeto, que
diminuem a rapidez da execução das primeiras fases do projeto, são improváveis de serem
adotados pela organização ou, caso sejam adotadas pela organização, o seu uso efetivo será
improvável. Segundo, deve haver um número de consultores especialistas na tecnologia
disponível para resolver os problemas e, se necessário, prover treinamento para os membros
da organização.
Os passos usuais de um processo de medição podem ser resumidos da seguinte
forma:
- Definir metas corporativas e de medidas;
- Derivar modelos e medidas que pareçam adequados no contexto específico de
medições;
- Definir procedimentos de coleta de dados para coletar dados válidos 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 necessário;
- Expandindo o uso das medições em toda a organização;
- Analisar os dados coletados para verificar a utilidade destes dados e a exatidão dos
modelos;
- Refinar modelos, medidas e procedimentos de coleta de dados, voltar ao passo 4.
Algumas fontes usuais de problemas quando são implementados programas de medição:
- A coleta de dados não voltada para as metas;
- As metas de medição não estão claramente especificadas e/ou claramente
comunicadas aos colaboradores;
- Muitas metas a serem coletadas de uma só vez. Conflito entre as metas da alta
gerência com as metas operacionais e vice-versa;
- Desenvolvedores têm que coletar muitos dados;
- A equipe encarregada do programa de medição não teve o treinamento adequado
e/ou não tem experiência suficiente.
Por ser o TCDF uma organização pública, que contém processos e procedimentos
estabelecidos em leis, as mudanças dos processos muitas vezes tornam-se problemáticas e
até impossíveis de serem realizadas. Neste cenário, mudar a organização é praticamente
inviável. O que é factível, e que já está em curso, é a proposição de mudanças sistemáticas
e paulatinas na execução de processos e procedimentos. Esta proposição é feita
demonstrando-se os aspectos favoráveis e desfavoráveis destas mudanças, encaminhandoas para posterior decisão das autoridades competentes, gestoras destes processos.
Neste capítulo os autores apresentaram uma abordagem ascendente para a melhoria
prática do processo de produção de software e seus produtos. Estes passos devem ser vistos
como uma implantação do Paradigma de Aperfeiçoamento da Qualidade – QIP. A fim de
facilitar sua aplicação em diferentes organizações de desenvolvimento e manutenção de
software, os autores montaram um conjunto de passos e diretrizes deste paradigma,
baseados em suas experiências adquiridas, conduzindo estudos quantitativos e qualitativos,
em diversas organizações públicas 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 utilização formulários
desenhados anteriormente, sendo treinados os funcionários responsáveis pela captação e
alimentação dos dados. Este passo não apresentou problemas, pois, a coleta dos dados foi
voltada para as metas estabelecidas nas entrevistas, as metas de medição foram claramente
especificadas. Não 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 Organização:
Após o Projeto Piloto e a revisão dos seus resultados, a tecnologia deve ser
transferida para a memória da organização. Tudo que pôde ser observado no Projeto Piloto
deve ser usado para ensinar a tecnologia, as formas e materiais de seu treinamento para a
organização. Também os procedimentos de coleta de dados talvez tenham de ser
modificados para levar em conta as lições aprendidas no Projeto Piloto.
25
26
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Bibliografia
V. Conclusão, Perspectivas e Futuros Trabalhos
O presente trabalho tem por objetivo apresentar a fundamentação teórica e um caso
prático 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
ações de implementação 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
/
Universität
Kaiserlautern
(Alemanha).
In:
http://www.cs.umd.edu/projects/SoftEng/tame/ tame.html.
O Paradigma de Aperfeiçoamento da qualidade – QIP estabelece premissas
fundamentais para que uma organização possa melhorar cada processo de software:
caracterizar o ambiente, definir os objetivos, escolher os processos, analisar os dados e
informações e finalmente “empacotar” as experiências adquiridas nesse projeto realizado.
Essas experiências devem ser armazenadas na Fábrica de Experiências, para que possa ser
estabelecida uma continuidade do processo de melhoria de software nas organizações.
[2] ____. The Goal Question Metric Approach. Institute for Advanced
Computer Studies / Department of Computer Science / University of
Maryland (EUA); & FB Informatik / Universität 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 técnica, para que seja implementado um programa permanente de avaliação e melhoria
da qualidade de software das organizações. Esta técnica foi escolhida principalmente pela
sua abordagem objetiva e abrangente na condução dos trabalhos de melhoria da qualidade
de software dentro das organizações.
[3] BRASIL. CÂMARA LEGISLATIVA - DF. Lei Orgânica do Distrito
Federal, Brasília: Câmara Legislativa, 1993.
Conforme foi citado anteriormente, o presente trabalho será a parte inicial da
dissertação de mestrado que versará sobre a viabilidade de se implantar e manter modelos
de qualidade de software em empresas brasileiras, visando a melhoria contínua dos
produtos de software dessas empresas. Para tanto, pretende-se implementar a abordagem
GQM. com todas as suas implicações, em outra empresa nacional. Contaremos com a
colaboração da equipe do Núcleo de Informática do TCDF para orientar a implantação 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. Constituição Federal, Brasília:
Congresso Nacional, 1988.
[5] BRIAND, Lionel; EL EMAM, Khaled; MELO, Walcélio 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 Estratégico do Tribunal: PLANEST; Período 1999-2003,
Brasília: TCDF/DIPLAN, 1998.
[8] ____. Tecnologia da Informação – Triênio 2000-2002, Brasília:
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
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
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. Tradução de José
Carlos Barbosa dos Santos. São 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
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
ANEXO I
Modelo GQM aplicado ao desenvolvimento de sistemas no TCDF
Considerando o contexto e as razões 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.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Objetivo
Propósito
Avaliar
G2
Aspecto
Tempo
Objeto
Conversão dos sistemas em Visual Basic (VB) para
Java
Ponto de vista
Gerente
Questão
Q3
Qual o tamanho do sistemas originais (VB)?
Métricas
M11
Quantidade de arquivos dos sistemas originais
M12
Quantidade de linhas de código (LOC) dos sistemas
Objetivo
Propósito
Melhoria
Questão
Q4
Qual o tamanho dos sistemas convertidos?
G1
Aspecto
Qualidade
Métricas
M13
Objeto
Sistemas Desenvolvidos (produto)
Quantidade de arquivos dos sistemas convertidos para
Java
Ponto de vista
Gerente
M14
Questão
Q1
Quantidade de erros encontrados pelo usuário?
Quantidade de linhas de código (LOC) dos sistemas
convertidos para Java
Métricas
M1
# mensal de ocorrências de manutenções corretivas
Questão
Q5
Qual o tempo necessário para conversão?
Métricas
M15
Tempo total de conversão por sistema em VB
M16
Tempo médio de conversão de uma LOC em VB para
Java
M2
# mensal de ocorrências de erros que afetam o
desempenho dos sistemas
M3
# mensal de ocorrências de erros que afetam o
funcionamento de pelo menos uma função
Métricas
M17
M16 por arquivo VB
M4
# mensal de ocorrências de erros que afetam o
funcionamento de pelo menos um sistema
Objetivo
Propósito
Avaliar
M5
# mensal de ocorrências de erros que geram
informações inconsistentes
G3
Aspecto
Planejamento
Objeto
Processo de Desenvolvimento de Sistemas
Ponto de vista
Gerente
Questão
Q2
A qualidade dos produtos está melhorando?
Métricas
M6
% de variação do último mês com relação a média
acumulada para M1
M7
% de variação do último mês com relação a média
acumulada para M2
M8
% de variação do último mês com relação a média
acumulada para M3
M9
% de variação do último mês com relação a média
acumulada para M4
M10
% de variação do último mês com relação a média
acumulada para M5
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Questão
Q6
Qual a diferença entre o esforço (tempo) estimado e o
realizado?
M27
# mensal de erros encontrados na leitura de código que
afetam o funcionamento de pelo menos uma função
Métricas
M18
(Esforço real - Esforço estimado) por ocorrência e fase
M28
M19
(M18 / Esforço estimado) * 100 por ocorrência e fase
# mensal de erros encontrados na leitura de código que
afetam o funcionamento de pelo menos um sistema
M20
Média de M19 por objetivo e fase
M29
# mensal de erros encontrados na leitura de código que
que geram informações inconsistentes
Questão
Q7
Qual a diferença entre os prazos previstos e realizados?
M30
Métricas
M21
(Data de início real - Data de início estimada) em dias
por ocorrência e fase
# mensal de erros encontrados nos testes de integração
e implantação
M31
M22
Média de M21 por objetivo e fase
#mensal de erros encontrados nos testes de integração e
implantação que afetam o desempenho dos sistemas
M23
(Data de fim real - Data de fim estimada) em dias por
ocorrência e fase
M32
M24
Média de M23 por objetivo e fase
# mensal de erros encontrados nos testes de integração
e implantação que afetam o funcionamento de pelo
menos uma função
M33
Objetivo
Propósito
Avaliar
G4
Aspecto
Qualidade
# mensal de erros encontrados nos testes de integração
e implantação que afetam o funcionamento de pelo
menos um sistema
Objeto
Processo de Desenvolvimento de Sistemas
M34
Ponto de vista
Gerente
# mensal de erros encontrados nos testes de integração
e implantação que que geram informações
inconsistentes
Questão
Q8
Qual o número de erros identificados pela equipe de
desenvolvimento durante a elaboração do sistema?
Q9
Qual a relação entre os erros encontrados pelo usuário e
os erros identificados durante a elaboração do sistema?
Métricas
M25
# mensal de erros encontrados na leitura de código
M35
M1 / (M25 + M30)
M26
# mensal de erros encontrados na leitura de código que
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 usuários por fonte
de erro
M41
# mensal de erros encontrados na leitura de código por
fonte de erro
M42
# mensal de erros encontrados nos testes de integração
e implantação por fonte de erro
M43
M40 / (M41 + M42)
Questão
Questão
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos
Procura-se aqui ter condições de dimensionar a melhoria dos produtos
entregues aos usuários finais, utilizando-se como indicador principal a quantidade de erros
percebida pelos usuários. Para esse objetivo foram definidas duas questões:
1. Q1 - Qual a quantidade de erros encontrados pelos usuário? - procura dimensionar os
vazamentos de erros não encontrados na produção do sistema, permitindo quantificar os
transtornos causados aos usuários. Em resposta a essa questão foram extraídas as
seguintes medidas:
1.1. M1 = Número mensal de ocorrências de manutenções corretivas - contabiliza
todas as ocorrências de erros encontradas pelos usuários independentemente de sua
gravidade;
1.2. M2 = Número mensal de ocorrências 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 = Número mensal de ocorrências de erros que afetam o funcionamento de
pelo menos uma função - constituem outro subgrupo de M1 e foram destacadas
pois prejudicam o desempenho de pelo menos uma função (tipicamente uma tela de
transação) do sistema;
1.4. M4 = Número mensal de ocorrências 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 aplicação); e
1.5. M5 = Número mensal de ocorrências de erros que geram informações
inconsistentes - constituem outro subconjunto de M1 e foram destacadas pois
provocam o armazenamento ou exibição de informações inconsistentes.
2. Q2 - A qualidade dos produtos está melhorando? - visa avaliar a evolução da
qualidade dos produtos entregues por meio da comparação das métricas da Q1 acima
descritas ao longo do tempo. Em resposta a essa questão foram extraídas as métricas
abaixo:
2.1. M6 = Percentual de variação do último mês com relação a média acumulada
para M1 - obtida pela divisão da medida de M1 para o último mês pela média de
M1 nos meses anteriores ao último mês multiplicado por 100;
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
para M4 - cálculo idêntico ao de M6 utilizando como parâmetro M4; e
2.5. M10 = Percentual de variação do último mês com relação a média acumulada
para M5 - cálculo idêntico ao de M6 utilizando como parâmetro M5.
Objetivo G2 - Avaliar o tempo de conversão de sistemas em Visual Basic para Java
Tendo em vista a mencionada estratégia de substituição do sistema
operacional utilizado no TCDF, faz-se necessário reescrever todos os sistemas em produção
na linguagem Java para que os mesmos possam continuar sendo utilizados. Esse objetivo
visa aperfeiçoar as estimativas de conversão dos sistemas por meio da análise das seguintes
questões:
1. Q3 - Qual o tamanho dos sistemas originais em Visual Basic? - essa questão é
relevante para dimensionar a tarefa a ser executada. Para respondê-la são medidos:
1.1. M11 = Número de arquivos fonte por sistema - agrupam-se os arquivos dos
sistemas desenvolvidos e em desenvolvimento em diretórios de trabalho
específicos e procede-se a contagem. Essa métrica é extraída por apuração
automática em lote, pelo próprio sistema de apoio ao processo, não necessitando de
preenchimento de formulários; e
1.2. M12 = Número de linhas de código por sistema - somam-se as linhas de código,
observada a sintaxe do Visual Basic, dos arquivos que compõem os sistemas de
informação. Essa métrica é extraída por apuração em lote não necessitando de
preenchimento de formulários.
2. Q4 - Qual o tamanho dos sistemas convertidos em Java? - assim, pode-se avaliar o
impacto de substituição da linguagem em termos de tamanho (LOC) dos sistemas
convertidos e acompanhar o progresso do processo de conversão. Para responder a essa
questão são medidos:
2.1. M13 = Número de arquivos dos sistemas - contagem efetuada de forma idêntica a
M11 para os diretórios dos sistemas em Java; e
2.2. M14 = Número de linhas de código por sistema - soma efetuada de forma
idêntica a M12 para os diretórios dos sistemas em Java.
2.2. M7 = Percentual de variação do último mês com relação a média acumulada
para M2 - cálculo idêntico ao de M6 utilizando como parâmetro M2;
3. Q5 - Qual o tempo para conversão dos sistemas? - questão principal para o objetivo
pretendido pois informa o esforço realizado até o momento e permite estimar a tarefa
restante. Para responder a essa questão são extraídas as seguintes medidas:
2.3. M8 = Percentual de variação do último mês com relação a média acumulada
para M3 - cálculo idêntico ao de M6 utilizando como parâmetro M3;
3.1. M15 = Tempo total de conversão por sistema - soma das horas de trabalhadas para
conversão de cada sistema até o momento;
2.4. M9 = Percentual de variação do último mês com relação a média acumulada
3.2. M16 = Tempo médio de conversão de uma linha de código em VB para Java -
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
soma de todo o tempo de codificação em Java para conversão dividida pelo
tamanho (em linhas de código VB) de todos os arquivos convertidos até o
momento; e
3.3. M17 = Tempo médio de conversão de uma linha de código em VB para Java por
arquivo VB - soma de todo o tempo de codificação em Java para conversão do
arquivo dividida pelo tamanho (em linhas de código VB) do arquivo - possibilita
avaliar a evolução da eficiência do trabalho e a complexidade da conversão de cada
arquivo.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
desenvolvimento de sistemas;
2.3. M23 = (data de fim real - data de fim estimada) em dias agrupado por ocorrência
e fase - mede a precisão no planejamento do fim de cada fase do processo de
desenvolvimento - valores negativos indicam fases concluídas antes da data
estimada; e
2.4. M24 = Média de M23 agrupada por objetivo e fase - indica se há variação
sensível entre as previsões de término 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 é
necessário avaliar o seu grau de precisão e efetuar as correções necessárias.
1. Q6 - Qual a diferença entre o esforço (tempo) estimado e o realizado? - questão que
possibilita verificar a precisão do planejamento de recursos; no caso do TCDF, o
principal recurso para desenvolvimento de sistemas é a hora de trabalho dos técnicos.
Assim, foram estabelecidas as seguintes medidas:
1.1. M18 = (esforço real - esforço estimado) agrupado por ocorrência e fase (entendase fase do processo de desenvolvimento como: especificação, codificação, leitura
de código, e teste de integração e implementação) - diferença em minutos entre o
esforço real e o esforço estimado - valores negativos expressam estimativas a maior
e valores positivos estimativas a menor;
1.2. M19 = (M18 / esforço estimado) * 100 agrupado por ocorrência e fase - indica o
percentual de erro das estimativas com relação ao esforço previsto;
1.3. M20 = Média de M19 agrupada por objetivo (entenda-se objetivo da ação da
equipe de desenvolvimento em cada ocorrência: manutenção corretiva,
manutenção evolutiva ou desenvolvimento de um novo sistema) e fase - permite
avaliar se há discrepâncias significativas entre as previsões feitas para cada tipo de
objetivo e dentro de cada objetivo por fase do processo de desenvolvimento de
sistemas.
2. Q7 = Qual a diferença entre os prazos previstos e reais? - possibilita aferir a precisão
das estimativas de datas de início e fim de cada fase do processo de desenvolvimento.
Para essa aferição são computados:
Com a implantação do processo de desenvolvimento de sistemas
pretende-se reduzir o número de erros encontrados pelo usuário, ou seja, erros após a
entrada do sistema em produção, estabelecendo-se pontos de teste no processo de
desenvolvimento de sistemas com a execução das atividades de leitura de código e teste de
integração e implantação. Assim, para avaliar a efetividade do processo em termos de
identificação de erros e redução de vazamentos (erros encontrados pelos usuários) foram
definidas as seguintes questões:
1. Q8 - Qual o número de erros identificados pela equipe de desenvolvimento durante a
elaboração do sistema? - possibilita aferir a eficácia das atividades de teste implantadas
com o processo de desenvolvimento de sistemas. Para essa questão são medidos:
1.1. M25 = Número mensal de erros encontrados na leitura de código - totaliza a
quantidade de erros identificados na fase de leitura de código pela equipe de
desenvolvedores a cada mês;
1.2. M26 = Número mensal de erros encontrados na leitura de código que afetam o
desempenho dos sistemas - indica a quantidade de erros identificados na fase de
leitura de código que prejudicam o desempenho do sistema pela equipe de
desenvolvedores a cada mês;
1.3. M27 = Número mensal de erros encontrados na leitura de código que afetam o
funcionamento de pelo menos uma função - indica a quantidade de erros
identificados na fase de leitura de código que prejudicam o desempenho de pelo
menos uma função (tipicamente uma tela de transação) do sistema pela equipe de
desenvolvedores a cada mês;
2.1. M21 = (data de início real - data de início estimada) em dias agrupado por
ocorrência e fase - mede a precisão no planejamento do início de cada fase do
processo de desenvolvimento - valores negativos indicam fases iniciadas antes da
data estimada;
1.4. M28 = Número mensal de erros encontrados na leitura de código que afetam o
funcionamento de pelo menos um sistema - indica a quantidade de erros
identificados na fase de leitura de código que prejudicam o desempenho de pelo
menos um sistema (toda uma aplicação) pela equipe de desenvolvedores a cada
mês;
2.2. M22 = Média de M21 agrupada por objetivo e fase - indica se há variação
sensível entre as previsões de início por objetivo e/ou fase do processo de
1.5. M29 = Número mensal de erros encontrados na leitura de código que geram
informações inconsistentes - indica a quantidade de erros identificados na fase de
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
leitura de código que provocam o armazenamento ou exibição de informações
inconsistentes pela equipe de desenvolvedores a cada mês;
1.6. M30 = Número mensal de erros encontrados nos testes de integração e
implantação - totaliza a quantidade de erros identificados na fase testes de
integração e implantação pela equipe de desenvolvedores a cada mês;
1.7. M31 = Número mensal de erros encontrados nos testes de integração e
implantação que afetam o desempenho dos sistemas - indica a quantidade de erros
identificados na fase testes de integração e implantação que prejudicam o
desempenho do sistema pela equipe de desenvolvedores a cada mês;
1.8. M32 = Número mensal de erros encontrados nos testes de integração e
implantação que afetam o funcionamento de pelo menos uma função - indica a
quantidade de erros identificados na fase testes de integração e implantação que
prejudicam o desempenho de pelo menos uma função (tipicamente uma tela de
transação) do sistema pela equipe de desenvolvedores a cada mês;
1.9. M33 = Número mensal de erros encontrados nos testes de integração e
implantação que afetam o funcionamento de pelo menos um sistema - indica a
quantidade de erros identificados na fase testes de integração e implantação que
prejudicam o desempenho de pelo menos um sistema (toda uma aplicação) pela
equipe de desenvolvedores a cada mês;
1.10. M34 = Número mensal de erros encontrados nos testes de integração e
implantação que geram informações inconsistentes - indica a quantidade de erros
identificados na fase testes de integração e implantação que provocam o
armazenamento ou exibição de informações inconsistentes pela equipe de
desenvolvedores a cada mês;
2. Q9 - Qual a relação entre o número de erros identificados pelo usuário e os erros
identificados durante a elaboração do sistema? - possibilita a comparação entre as
quantidades de erros encontrados pelos usuários dos sistemas (vazamentos) e de erros
encontrados pela equipe de desenvolvimento de sistemas nas fases de leitura de código
e testes de integração e implantação. Para efetuar essa comparação são extraídas:
2.1. M35 = M1 / (M25 + M30) - compara o total de erros encontrados pelo usuário
com o total de erros encontrados pela equipe de desenvolvimento a cada mês.
Valores acima de 1 indicam que os usuários estão encontrando mais erros do que a
equipe de desenvolvimento;
2.2. M36 = M2 / (M26 + M31) - análoga a métrica anterior limitando a comparação aos
erros que afetam o desempenho dos sistemas;
2.3. M37 = M3 / (M27 + M32) - análoga a métrica anterior limitando a comparação aos
erros que afetam o funcionamento de pelo menos uma função;
2.4. M38 = M4 / (M28 + M33) - análoga a métrica M36 limitando a comparação aos
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
erros que afetam o funcionamento de pelo menos um sistema; e
2.5. M39 = M5 / (M29 + M34) - análoga a métrica M36 limitando a comparação aos
erros que geram informações inconsistentes
3. Q10 - Qual a origem (fonte) dos erros encontrados? - visa caracterizar a origem dos
erros para auxiliar na redução dos mesmos. As fontes de erro possíveis no processo de
desenvolvimento implantado são: codificação, especificação, modificação anterior e
requerimentos do usuário. Para caracterizar as origens dos erros são medidos:
3.1. M40 = Número mensal de erros encontrados pelos usuários por fonte de erro agrupa mensalmente os erros encontrados pelos usuários de acordo com a fonte de
erro indicada pelo analista responsável pela resolução da ocorrência;
3.2. M41 = Número mensal de erros encontrados na leitura de código por fonte de
erro - agrupa mensalmente os erros encontrados pela equipe de desenvolvimento
na fase de leitura de código classificados de acordo com o técnico responsável;
3.3. M42 = Número mensal de erros encontrados nos testes de integração e
implantação por fonte de erro - agrupa mensalmente os erros encontrados na fase
de testes de integração e implantação pela equipe de desenvolvimento de sistema
classificados de acordo com o técnico responsável; e
3.4. M43 = M40 / (M41 + M42) - compara os erros encontrados pelos usuários e pela
equipe técnica de acordo com a fonte de erro indicada.
Todas essas métricas são obtidas automaticamente por meio dos sistemas
de apoio ao processo de desenvolvimento implantado, descrito no próximo capítulo.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
AberturaMestrado
de chamado
ao
Universidade Católica de Brasília,
em Informática,
Qualidade de Software, UCB-QSW-TR-2001/07
Início
NIPD na intranet por usuário
Não
É 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 solicitações de serviços ao setor de informática - que envolvem
desde a criação de um novo sistema de informação até a instalação de um ponto elétrico foi necessário disciplinar e categorizar as demandas com vistas a facilitar o
acompanhamento das mesmas tanto pela gerência como pelos próprios usuários. Para isso
foi implantado, em maio de 1999, um aplicativo na intranet do TCDF que possibilita aos
usuários efetuarem suas solicitações e acompanharem o andamento dos serviços.
Fim
Sim
Elaboração de
Cronograma de Desenvolvimento
de Sistemas - CDS
Análise de Requerimentos do
usuário
Esse sistema se mostrou adequado para as demandas relativas a
manutenção de equipamentos, dúvidas de usuários, instalação de programas, etc., mas não
permitia maior detalhamento das fases relativas ao processo de desenvolvimento de
sistemas.
Assim, considerando a importância de disciplinar o processo de
desenvolvimento, as razões que motivaram sua implantação descritas no item contexto da
aplicação 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 formulários 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 extração das métricas estabelecidas (anexo 4).
Processos que
fogem ao
escopo deste
trabalho
Elaboração da especificação
(projeto)
Não
Projeto
aprovado
1
Teste de integração e implementação
Abaixo, apresenta-se de forma esquemática o diagrama do processo de
desenvolvimento praticado no TCDF.
Codificação
Correções
Leitura de Código
Correções
Sim
Não
Correção após teste
Sim
Correção após leitura de código
Fim
1
Não
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
As atividades realizadas pelos participantes do processo, segundo o papel
que exercem, são as seguintes:
Usuário
Analista
Abre
chamado
Abre CDS2
Equipe
Prog. 1 1
Analisa
requerimentos
Elabora
projeto
RTF3
Codifica
Prog. 2
Prog. 3
Preenche
REF4
Preenche
REF
Lê código
Testa
Secretária
Gerência
Merece destaque o fato de que o processo definido foi adequado à
forma de trabalho dos técnicos e à cultura e disciplina já em uso. O trabalho de definição do
processo permitiu conhecer melhor a forma de atuação da equipe e promover ajustes de
procedimentos.
Digita
REF
Análise da aplicação do processo
O acompanhamento do processo de desenvolvimento de sistemas
realizado a partir de novembro de 1999 possibilitou obter os resultados apresentados neste
tópico, segundo o modelo GQM apresentado anteriormente. Para melhor compreensão dos
mesmos as análises serão realizadas para cada objetivo definido, tomando-se por base as
métricas obtidas até 23 de junho do corrente relacionadas no anexo 2.
Implantação
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 informática. Inicialmente, foram
utilizados formulários mais detalhados para as fases de codificação, baseados nos utilizados
pelo SEL/NASA (anexo 3), que se mostraram de difícil preenchimento e aceitação por
parte da equipe técnica. Assim, complementarmente ao registro de tempo feito por meio do
RSA, o registro do tamanho dos sistemas e programas é feito por rotina de apuração
semanal.
Os resultados obtidos da análise dessas métricas não necessariamente
representam uma tendência neste momento, uma vez não há ainda uma base consolidada
para comparação. Restando dizer que essas medidas passam a representar a formação de
conjunto de indicadores para análises futuras mais consistentes.
Digita
RSA
Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos
Extrai
métrias
Avalia
resultados
Legenda:
1 - Programador - técnico do NIPD atuando como programador;
2 - CDS - Cronograma de Desenvolvimento de Sistemas - modelo no anexo 1;
3 - RTF - Relatório da Reunião de Revisão Técnica Formal para Especificação de Sistema - modelo
no anexo 1 - não é digitado;
4 - REF - Relatório de Erros e Falhas - modelo no anexo 1;
5 - RSA - Relatório de Semanal de Atividades - modelo no anexo 1;
Da observação das métricas apuradas para este objetivo pode-se constatar
o aumento do número de erros encontrados pelos usuários no período. A variação de 133%
na métrica M6 reflete esse aumento e aponta para a necessidade de melhor
acompanhamento do processo de desenvolvimento estabelecido.
Há que se considerar, porém, que a grande maioria dos erros encontrados
não se originam de produtos do atual processo de desenvolvimento, resultam de sistemas
em produção antes da implantação deste processo.
Objetivo G2 - Avaliar o tempo de conversão de sistemas em Visual Basic para Java
O resultado mais expressivo para avaliação desse objetivo é a métrica
M16 que representa o tempo médio de conversão de uma linha de código VB para Java. Por
essa medida cada linha de código VB é convertida para Java em 1,71 minutos, em média.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Assim, pode-se comparar o tempo médio de conversão com a média de
conversão por arquivo (M17) e identificar quais funções consumiram mais recursos ou são
mais complexas.
A partir da associação entre as medidas M16 (tempo médio de conversão)
e M12 (LOC dos sistemas a serem convertidos) pode-se obter uma estimativa do tempo
necessário para a completa conversão dos sistemas. Por exemplo, o Sistema de Acesso às
Bases de Dados - SABD, atualmente em conversão, por essa medida, requer 550 horas para
estar totalmente convertido em Java. Uma vez que já foram realizadas 216 horas de
conversão para esse sistema (M15), pode-se deduzir que resta um esforço de 334 horas para
conclusão de sua conversão.
Objetivo G3 - Avaliar o planejamento do processo de desenvolvimento de sistemas
Quanto ao planejamento de recursos, pode-se constatar, pela variação
média de erro de estimativa de horas a serem despendidas na realização de uma tarefa
(M20) por objetivo e fase do processo de desenvolvimento, que as estimativas para
manutenção (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 início e conclusão de cada fase
por objetivo (M22 e M24), verifica-se uma tendência de acerto para a previsão de início e
de superestimação das datas de término.
Os erros de estimativa, de um modo geral, decorrem do fato de a base de
informações do processo estabelecido estar ainda em construção. Além disso, observa-se
uma tendência dos técnicos em não acompanharem os resultados de suas previsões.
Objetivo G4 - Avaliar a qualidade do processo de desenvolvimento de sistemas
O resultado dessa avaliação é ainda pouco expressivo. Com o curto
período de observação e a falta de hábito dos técnicos, os números apontados nesse
objetivo mostram-se muito modestos, o que inviabiliza uma melhor análise e indica
necessidade de reforçar a orientação para uso correto do processo.
MODELOS DE FORMULÁRIOS APLICADOS NO TCDF
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Cronograma para Desenvolvimento/Manutenção de Sistema – CDS
Nº OCORRÊNCIA:
DATA CONCLUSÃO:
/
/
Descrição :
Objetivo
OBJETIVO:
Desenvolvimento
Manutenção Evolutiva
Formulário destinado ao acompanhamento do atendimento às solicitações
registradas no SSUF.
Manutenção Corretiva
Fonte do erro
Gravidade do erro
Requerimento do Usuário
não permite funcionamento do sistema
Especificação
Codificação
não permite funcionamento de alguma função
Modificação Anterior
gera informações inconsistentes
erro menor ou desvio dos padrões
PERÍODO ESTIMADO
Início
Fim
PERÍODO REAL
ESFORÇO
ESTIMADO
Fim
Início
Campos
compromete desempenho do sistema
Cronograma:
FASE
INSTRUÇÃO DE PREENCHIMENTO DO CRONOGRAMA
para DESENVOLVIMENTO/MANUTENÇÃO DE SISTEMAS CDS
Requerimentos
/
/
/
/
/
/
/
/
Especificação
/
/
/
/
/
/
/
/
Codificação
/
/
/
/
/
/
/
/
Leitura de Código
/
/
/
/
/
/
/
/
Testes
/
/
/
/
/
/
/
/
Responsável(eis)
Nº Ocorrência
Data Conclusão:
Matrícula
Nome
Descrição
Objetivo
Fonte do erro
Gravidade do erro
Detalhes sobre: Banco de Dados; Acessos; Serviço; Configuração de Servidor; Estação de Trabalho; etc.
Cronograma
Período estimado
Período real
Esforço estimado
Responsáveis
Detalhes
Elaborado por:
Cadastrado por:
Em:
/
/
número de registro da ocorrência no SSUF
indique a data de conclusão da implementação da
funcionalidade
matrícula do funcionário que preenche o formulário.
nome do funcionário
resumo do que está sendo desenvolvido/modificado.
indique o objetivo da implementação, conforme o caso:
Desenvolvimento, Manutenção Evolutiva ou Manutenção
Corretiva
somente em caso de manutenção corretiva, indique a origem
do erro.
somente em caso de manutenção corretiva, indique o nível
de gravidade do erro
para cada fase informar:
data de início e término previstos dos trabalhos;
preenchimento posterior, indicando as datas reais de
realização dos trabalhos
tempo em minutos previsto para consecução de cada fase
nome do responsável pela execução da fase
informar detalhes que devem ser observados quando da
colocação do sistema em produção, tais como: tabelas,
stored procedure, views etc, que devem ser atualizadas no
banco de dados; configurações específica para o servidor de
rede ou estação de trabalho; alteração de serviços auxiliares,
compilação simultânea de outros sistema, etc.
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Relatório de Erros e Falhas – REF
TIPO DE VERIFICAÇÃO :
Leitura de Código
Nº OCORRÊNCIA:
Linha
Teste de Integração
Matrícula:
Nome:
ARQUIVO FONTE:
REFERÊNCIA
1
FONTE
2
GRAVIDADE
Descrição
INSTRUÇÃO DE PREENCHIMENTO DO RELATÓRIO DE
ERROS E FALHAS - REF
Objetivo
Formulário destinado ao registro de erros ou falhas detectados durante a Leitura
de Código ou Teste de Integração de determinada funcionalidade.
Campos
Tipo de Verificação marque Leitura de Código ou Teste de Integração, conforme
o caso.
Matrícula
matrícula do funcionário que preenche o formulário.
Nome
nome do funcionário
Nº Ocorrência
número de registro da ocorrência no SSUF
Arquivo fonte
nome do arquivo fonte, inclusive extensão, que está sendo
criado ou alterado. Deve ser escrito com a maior nitidez
possível.
Referência
informar o número a que se refere o erro de acordo com a
lista de verificação de erros e falhas
Linha
número da linha do código a que se refere o erro
Fonte
origem do erro, conforme legenda abaixo no formulário
Gravidade
nível de gravidade do erro, conforme legenda abaixo no
formulário
1
2
Fonte do Erro:
Gravidade do Erro:
REQ – Requerimento do Usuário; ESP – Especificação ; COD – Codificação; MOA – Modificação Anterior
FS – não permite Funcionamento do Sistema; FF – não permite Funcionamento de alguma Função;
DS – compromete Desempenho do Sistema; EM – Erro Menor ou desvio dos padrões; II – gera Informações Inconsistentes
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07
Relatório Semanal de Atividades – RSA
Matrícula.:
Dia
INSTRUÇÃO DE PREENCHIMENTO DO RELATÓRIO
SEMANAL DE ATIVIDADES - RSA
Nome:
Atividade
1
Tempo
nº Ocorrência
Arquivo Fonte (inclusive extensão)
Arquivo VB (somente em caso de
conversão p/
Objetivo
Formulário de preenchimento manual para inserção semanal de dados no Sistema
de Acompanhamento do Desenvolvimento de Sistemas – SADS, com a finalidade
de acompanhar o dispêndio de tempo no atendimento às ocorrências registradas
no Sistema de Solicitações do Usuário Final - SSUF.
Campos
1.
2.
3.
4.
5.
6.
Matrícula: matrícula do funcionário que preenche o formulário.
Nome: nome do funcionário
Mês/ano: mês e ano de referência
Dia: dia de referência do preenchimento
Atividade: indicar sigla de acordo com a legenda abaixo do formulário
Tempo: tempo gasto na execução da atividade em minutos, já descontadas
todas as interrupções
7. Nº Ocorrência: número de registro da ocorrência no SSUF
8. Arquivo fonte: nome do arquivo fonte, inclusive extensão, que está sendo
criado ou alterado. Deve ser escrito com a maior nitidez possível.
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 formulário no SADS
11. Por: assinatura ou nome do responsável pela digitação do formulário no
sistema.
1
Atividade:
REQ – Requerimento do Usuário; ESP – Especificação ; RTF – Reunião de Revisão Técnica Formal;
COD – Codificação; LER – Leitura de Código; CAL – correção após leitura de código;
TII – teste de integração e implementação; CAT – correção após teste; ADM – Administração/Análise de Dados;
DOC - Documentação