Resumo Processo de Implantação de Gestão de · 1 Universidade Católica de Brasília – UCB Mestrado em Informática Qualidade de Software Processo de Implantação de Gestão

1

Universidade Católica de Brasília – UCB

Mestrado em Informática

Qualidade de Software

Processo de Implantação de Gestão deQualidade de Software em Empresas

Nacionais:

O Estudo de Caso do Tribunal de Contas daUnião

Tomás Roberto Cotta Orlandi

OrientadorProf. Dr. Walcélio L. Melo

Brasília (DF), dezembro de 2000

Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07

2

Processo de Implantação de Gestão de Qualidade deSoftware em Empresas Nacionais:

O Estudo de Caso do Tribunal de Contas da União

Tomás Roberto Cotta Orlandi

Resumo

A proposta deste trabalho é demonstrar a viabilidade da implantação de um processocontínuo de avaliação de qualidade de software em empresas brasileiras, apresentando aabordagem GQM – Goal, Question, Metric , situando-a no contexto de outras abordagensde avaliação e qualidade de software, que atende não só as expectativas em relação à umamelhora de qualidade dos produtos, mas também a um incremento na produtividade dasequipes de trabalho.

Palavras-chaveabordagem GQM, CMM, Fábrica de Experiência, ISO, QIP, Qualidade de software,

SPICE.

AbstractThe objective of this article is to show the viability of introducing a continuos evaluationprocess of software quality in Brazilian’s companies, presenting the GQM–Goal, Question,Metric approach, comparing it with others software’s quality approaches, attending thewishes of a better software product’s quality and best productivity of the team working.

KeywordsCMM, Experience Factory, GQM Approach, ISO, QIP, Software Quality, SPICE


3

I. Introdução

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 equalidade de software como ISO,CMM, SPICE e QIP. A implantação da abordagem GQMem empresa nacional, será mostrada através da utilização de um processo padronizado dedesenvolvimento, conversão e manutenção de software.

A proposta é demonstrar a viabilidade da implantação de um processo contínuo deavaliaçã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 produtividadedas equipes de trabalho, incorporando naturalmente a cultura de produzir software comtestes, inspeções e medições de resultados.

Será também demonstrada a viabilidade da manutenção de um programapermanente de qualidade de software, através do treinamento, implantação e aplicação daabordagem GQM, visando uma melhora contínua na qualidade e na produtividade desistemas. Como produto final são gerados modelos quantitativos, baseados em dadoscaptados, que viabilizam uma análise da qualidade dos software produzidos, possibilitandouma comparação qualitativa do processo de desenvolvimento de sistemas com organizaçõesexternas.

Em decorrência da implantação dessa abordagem, demonstra-se a implementação ea manutenção de uma estrutura, separada logicamente do desenvolvimento de software, aFábrica de Experiências. A Fábrica de Experiências (Experience Factory)[1] tem porobjetivo armazenar as experiências dos projetos desenvolvidos, em termos de soluções eimplementações adotadas, para que as equipes possam fazer reuso posterior das soluções edos códigos já desenvolvidos. As soluções “empacotadas” na Fábrica de Experiênciaspoderão ser utilizadas também por organizações semelhantes à estudada, ou seja, empresanacional pública ou privada.

Objetivos Específicos:

§ 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 emedições de resultados;

§ Mostrar o conceito e a forma de implementação da Fábrica de Experiências.


4

II. Caracterização dos Produtos e dos Processos

Este capítulo visa apresentar os modelos de qualidade de software mais aplicadosem empresas ou setores, produtores de software, que de algum modo se preocupam emimplementar e manter procedimentos de avaliação e medição, visando uma melhora naqualidade e produtividade dos projetos e sistemas desenvolvidos pela empresa.

O Modelo ISO 12207 de Qualidade

A norma ISO/IEC 12207 objetiva auxiliar organizações na definição de seusprocessos de software oferecendo uma guia para definição das atividades e tarefas a seremdesempenhadas durante as principais etapas que envolvem a construção de um produto desoftware. A norma agrupa processos de software em três grandes classes – processosfundamentais, processos de apoio e processos organizacionais.

A categoria de processos fundamentais compreende os processos que executam asprincipais funções relacionadas ao ciclo de vida de software. Processos de apoio servemcomo auxiliares ao processo fundamental de construção, contribuindo para o sucesso e aqualidade do produto gerado. Processos organizacionais são responsáveis peloacompanhamento do desenvolvimento, compreendendo processos para gerência, melhoriada qualidade, infra-estrutura e treinamento.

Cada processo inserido nestas classes está dividido em um conjunto de atividadesque, por sua vez, se dividem em um conjunto de tarefas para sua realização. Contudo, anorma 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 dequalidade pois, no contexto de empresas nacionais em questão, necessitamos especificar osdetalhes de como implementar processos de qualidade de software nas organizações.

O Modelo SPICE (ISO/IEC 15504) de Qualidade

A iniciativa de se estabelecer um padrão internacional para melhoria de processosde software levou a ISO/IEC a aprovar em 1993 um novo grupo de trabalho, denominadoWG10, a partir do qual se organizou o projeto SPICE (Software Process Improvement andCapability dEtermination) (ISO/IEC 15504-8, 1996) [5]. Analogamente ao CMM, oobjetivo 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.


5

A futura norma ISO/IEC 15504 define processos e práticas que podem serimplementados 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ãoorganizadas utilizando-se uma arquitetura que combina duas perspectivas: uma perspectivafuncional (análoga à perspectiva da norma ISO/IEC 12207), compreendendo quais osprocessos que devem existir numa organização e uma outra perspectiva que avalia o nívelde capacitação de cada um destes processos (análoga ao CMM). O uso da norma permiteque as organizações possam perceber a existência ou não de processos específicos, bemcomo a capacitação dos que existem, traçando caminhos para a melhoria.

O Modelo CMM

O Capability Maturity Model (CMM) para Software, compilado pelo SoftwareEngineering Institute – SEI da Carnegie Mellon University (EUA), pode ser entendidocomo 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ócioseja a produção de software, que pretendam incrementar a capacidade (ou qualidade) doprocesso de desenvolvimento de sistemas.

O modelo apresentado pelo CMM não se preocupa em “como” a organizaçãoimplementa, mas, antes, busca descrever “o quê” se espera do processo produtivo desoftware.

O modelo CMM foi utilizado neste trabalho como caminho a ser seguido paranortear as ações de implementação de um modelo de qualidade de software emorganizações brasileiras, pois, trata-se de um modelo consagrado e utilizado mundialmentepor organizações produtoras de software.

O CMM classifica as organizações produtoras de software em cinco grupos (ouníveis) de maturidade, identificando, para cada grupo, as áreas chave do processo dedesenvolvimento de sistemas que devem ser observadas na busca da melhoria dacapacidade produtiva. Cada área chave possui objetivos que precisam ser alcançados paraque 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 eocasionalmente, até mesmo, de forma caótica. Poucos processos são definidos e o sucessodos projetos depende de esforços individuais e atitudes heróicas dos desenvolvedores.

Uma característica das organizações classificadas nesse nível é o comprometimentoalém da capacidade. A dificuldade da organização em cumprir os compromissosestabelecidos é acompanhada pela sobrecarga do corpo técnico, que fica impossibilitado deseguir as práticas recomendadas para a engenharia de software, gerando, então, sucessivas


6

crises. Durante as crises, normalmente, são abandonadas as fases de planejamento, havendoum 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 docomportamento no nível 1 é colocado apenas como base de comparação para os demaisníveis.

Nível 2 - Repetitivo

Nesse nível de maturidade, existe um gerenciamento básico de projetos com afinalidade maior de acompanhar custos e cronogramas. Porém, o processo aplicado aodesenvolvimento 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 paraprojeto em organizações considerados no nível 2. O que deve existir, porém, é uma políticaque 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 podeacompanhar 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 aogerenciamento 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 emanutenção de software é documentado e usado por toda a organização. Esse padrão incluias 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 gerentese 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 gerentesadquiram o conhecimento e habilidade necessários à execução de suas tarefas.

A medida que acontecem, os projetos utilizam-se do processo padrão e fazemadaptação desse modelo para ajustá-lo às suas peculiaridades. Sendo, então, esse “processoajustado” o que realmente é usado nas atividades do projeto.


7

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”, umavez que, nesse nível, as atividades de engenharia e gerenciamento no processo produtivo desoftware são estáveis e repetitivas. Com uma “linha de produção” estabelecida, os custos, ocronograma e as funcionalidades estão sob controle e qualidade do software é melhoracompanhada.

As áreas chave definidas para o nível 3 estão voltadas aos aspectos da organização edo projeto, no sentido de prover uma infra-estrutura que possibilite a institucionalização deum efetivo processo de engenharia e gerência de software para todos os projetos. São áreaschave para o nível 3:

• foco no processo da organização (ou estabelecimento de responsabilidades naorganizaçã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 4 - Gerenciado

Nesse nível, passam a ser coletadas e analisadas métricas detalhadas relativas aoprocesso e à qualidade do produto para acompanhamento e controle do processo. Nessenível, processo e produto são quantitativamente entendidos e controlados.

No nível gerenciado, a organização define objetivos de qualidade que devem seralcançados para produtos e processos. As atividades de produção de software maisimportantes são acompanhadas por meio de um programa de medidas da organização afimde que possam ser observadas a produtividade, a qualidade, etc. Um banco de dados para aorganização como um todo é usado para coletar e analisar os dados disponíveis extraídosdos projetos. O processo de software é equipado com um processo de coleta de medidasconsistente 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 limitesquantitativos. Esse nível permite que a organização trabalhe com segurança na previsão dodesempenho dos processos e da qualidade dos produtos.

As áreas chave para o nível 4 estão direcionadas ao entendimento quantitativo doprocesso e do produto:

• gerenciamento quantitativo do processo; e• gerenciamento da qualidade do produto.


8

Nível 5 - Otimizado

No nível otimizado, toda a organização está voltada para um contínuo processo demelhoria. A organização busca identificar, de forma pró-ativa, os pontos fortes e fracos doprocesso, com o objetivo de evitar erros e melhorar a eficiência. Dados reais de processossão usados para análise da relação custo/benefício, para implementação de novastecnologias ou para propor mudanças ao processo produtivo.

As equipes de software em organizações no nível 5 trabalham na análise de defeitosdo processo afim de determinar suas causas, avaliar o processo e prevenir manifestações deerros conhecidos e recorrentes, e, ainda, disseminar os conhecimentos adquiridos pelaorganizaçã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íciosresultam 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 asorganizações identificadas no nível 5 estão continuamente empenhadas em melhorar acapacidade de seus processos. A melhoria pode surgir tanto em função do progresso dopróprio processo quanto da aplicação de novas tecnologias e métodos. A aplicação de novastecnologias 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 projetosprecisam observar para promover um incremento contínuo e mensurável da qualidade doprocesso 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.


9

Como mostra a figura 1, o CMM, pode ser representado como uma estrutura decinco níveis de maturidade:

Figura 1

O Paradigma de Aperfeiçoamento da Qualidade - QIP

O Quality Improvement Paradigm – QIP (ou Paradigma doAperfeiçoamento da Qualidade), desenvolvido por Victor Basili e outros [1], é o resultadoda aplicação do método científico para resolução do problema de melhoria da qualidade desoftware. O QIP está diretamente relacionado ao Ciclo Plan/Do/Check/Act (PDCA) deShewart-Deming[15] largamente utilizado na indústria para implementação de planos degerenciamento 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 deimplementação.

• 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.

Inicial1

Repetitível2

Definido3

Gerenciado4

Otimizado5

• 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.

• gerenciamento quantitativo do processo; e• gerenciamento da qualidade do produto.

• prevenção de erros;• gerenciamento de mudança tecnológica;

e• gerenciamento de mudanças no processo


10

• 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.

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 ecaracterizá-los criticamente.

• Definir os objetivos: com base na caracterização inicial e nas capacidades estratégicasda organização, definir com objetivos quantificáveis o que seriam projetos bemsucedidos e avaliar o desempenho e melhoria da organização. As exceções aceitáveissão definidas com base nos fundamentos estabelecidos no passo de caracterização.

• Escolher os processos: com base na caracterização do ambiente e dos objetivosdefinidos, escolher os processos apropriados para melhoria bem como as ferramentas emétodos de apoio, certificando-se que esses sejam consistentes com os objetivos.

• Executar: executar os processos elaborando os produtos e provendo retorno, a partir doprojeto, 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çõesacumuladas para avaliar as práticas correntes, identificar problemas, registrar achados, efazer recomendações para melhoria de futuros projetos.

• Empacotar: Consolidar a experiência adquirida em forma de refinamento do modelopraticado ou mesmo pela adoção de novos modelos e, ainda, por meio de outras formasde estrutura de conhecimento alcançadas no último ou em processos anteriores earmazená-las em uma base de experiências, disponível para uso futuro.

Uma caracterização apropriada e sem ambigüidades do ambiente é umpré-requisito para a aplicação correta do paradigma. Essa caracterização requer aclassificação minuciosa do projeto, permitindo a identificação de classes de projetos comcaracterísticas e objetivos similares. Assim, pode-se estabelecer o ambiente adequado aoprojeto corrente. Com a correta caracterização obtém-se um contexto para a definição deobjetivos, para a reutilização de experiências e produtos, para a seleção de processos, para aavaliação e comparação de resultados, e para uma maior exatidão nas previsões.

O Processo do Paradigma de Aperfeiçoamento da Qualidade

Há um grande número de características de projetos e de ambiente queafetam 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;


11

• fatores dos recursos - máquinas de produção e desenvolvimento, tempo calendário,orçamento, software existente.

A definição realista dos objetivos é importante para a caracterização doambiente. É preciso estabelecer modelos e objetivos para os processos e para os produtos.Esses objetivos precisam ser mensuráveis, dirigidos pelos modelos, e definidos para umavariedade 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 conjuntode objetivos operacionais usando métricas. Essa abordagem representa uma sistemáticapara ajuste e integração de objetivos com modelos de processos, produtos e perspectivas dequalidade 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:

Figura 2

Caracterizar

Definir objetivos

Escolher processoExecutar

Analisar

Empacotar


12

A Fábrica de ExperiênciaO 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) emformato que pode ser efetivamente entendido e modificado (modelos de experiências) emum repositório integrado (base de experiências) que pode ser acessado e modificado emconformidade com as necessidades do projeto corrente (reutilização). Para apoiar oparadigma de aperfeiçoamento foi desenvolvida um estrutura distinta do desenvolvimentode 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 odesenvolvimento de sistemas por meio da análise e sintetização de todos os tipos deexperiências, agindo como um repositório para essas experiências e fornecendo-as a outrosprojetos na medida da demanda, representa um paradigma de mudança do pensamentocorrente de desenvolvimento de software. Ela separa os tipos de atividades que precisamser executadas em diferentes estruturas, reconhecendo que elas verdadeiramenterepresentam processos e enfoques diferentes.

Assim, identificam-se duas unidades organizacionais distintas: aOrganização Projeto, para o desenvolvimento de sistemas; e a Fábrica de Experiências, parao empacotamento de conhecimentos adquiridos. Na Organização Projeto, são resolvidos osproblemas, na Fábrica de Experiência, são entendidas as soluções e empacotadas asexperiências para futura reutilização.[1]

O Processo da Fábrica de ExperiênciasA 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 aqueleconhecimento para produzir os mais avançados produtos da corporação.

A Organização Projeto caracteriza o projeto e seu ambiente, define osobjetivos para o projeto e escolhe o processo apropriado dadas as características eobjetivos. O suporte ao projeto é provido pela Fábrica de Experiências pela articulação dascaracterísticas, formulação de objetivos e seleção do conjunto apropriado de experiênciaspassadas para uso no projeto. [1]

Pela abordagem da Fábrica de Experiências, a reutilização não representaapenas o reaproveitamento de código mas de todos os tipos de experiências e do contextoque envolve essas experiências, reconhecendo que as experiências nem sempre sãoreutilizáveis como foram concebidas, antes elas precisam ser ajustadas e empacotadas paratornar mais fácil o seu acesso e reutilização.

Na prática, a abordagem QIP/EF é implementada colocando-seprimeiramente a organização em seu lugar, a partir de sua caracterização. Isso significa acoleta de dados para estabelecimento dos fundamentos (baselines) e avaliação dos pontosfortes e fracos da organização a fim de se obter o enfoque nos negócios e objetivos daempresa para o processo de melhoria. A coleta inicial de dados é crítica também para adefinição da qualidade do produto que deveria ser aprimorada pelo programa.

Dessa forma, a organização define em si mesma um contínuoaperfeiçoamento, mesmo se o nível de maturidade não for muito alto, porque ela aprende apartir do seu próprio negócio, não de um modelo de processo ideal, externamente


13

concebido. Melhorias no processo serão baseadas na compreensão do relacionamento entreprocesso 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.

O Modelo Goal Question Metric (GQM)

Esta apresentação da abordagem Goal/Question/Metric (GQM), utilizadacomo abordagem na definição do processo de desenvolvimento de software, toma por baseo texto de Victor R. Basili, Gianluigi Caldiera e H. Dieter Rombach [2]. Os dois primeirosdo Institute for Advanced Computer Science, da University of Maryland (EUA), e o últimoda FB Informatik, da Universitat Kaiserslautern (Alemanha).

Como em qualquer disciplina de engenharia, o desenvolvimento desoftware requer um mecanismo de mensuração para avaliação e retorno. O procedimento demedir é uma forma de criar uma memória corporativa e um auxílio na resposta de váriasquestões associadas ao estabelecimento de um processo de software.

Um processo de medidas estabelecido auxilia no planejamento de novosprojetos, na determinação de pontos fortes e fracos de produtos e processos, naracionalidade para adoção ou refinamento de técnicas em uso, e ainda, na avaliação daqualidade de processos ou produtos específicos. Medir também ajuda, durante o curso deum projeto, a avaliar o seu progresso, tomar as medidas corretivas baseadas nessejulgamento, e avaliar o impacto de tal ação.

Algumas questões que poderiam, por exemplo, ser respondidas a partir deum 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 emodelos 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:

Figura 3

OBJETIVO 1 OBJETIVO 2

QUESTÃO QUESTÃO QUESTÃO

MÉTRICA MÉTRICA MÉTRICA MÉTRICA


14

A abordagem GQM

A abordagem GQM parte da premissa de que para uma organizaçãoadotar um processo de medida definitivo é necessário primeiramente estabelecer osobjetivos da própria organização e de seus projetos, definir esses objetivosoperacionalmente e, finalmente, criar um ambiente de apoio capaz de interpretar os dadoscomparando-os com os objetivos estabelecidos. Assim, é importante deixar claro, pelomenos em termos gerais, qual a necessidade de informações da organização, se essasinformações podem ser quantificadas e em que momento podem ser colhidas, e se podemser analisadas em função dos objetivos.[2]

A abordagem foi definida originalmente para avaliação de defeitos em umconjunto de projetos no ambiente da NASA Goddard Space Flight Center. A aplicaçãoenvolveu um conjunto de estudos de casos e foi expandida para incluir várias abordagensexperimentais. Embora a abordagem tenha sido usada originalmente para definir e avaliaros 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 QualityImprovement Paradigm (discutido anteriormente neste trabalho), processo de melhoria daqualidade 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 ambienteexperimental com o objetivo de produção e/ou avaliação de software e processos para usonos demais projetos.

Neste trabalho, a utilização de todas estas técnicas, será norteada pelomodelo 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 paracada nível alcançado.

O resultado da aplicação da abordagem GQM é a especificação de umsistema de medidas objetivando um conjunto particular de casos e de regras nainterpretaçã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 vistada 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, deinteraçã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 paracaracterizar 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 ourecurso) com respeito a um padrão de qualidade e buscam identificar a qualidade desseobjeto a partir de determinado ponto de vista.


15

3. Nível Quantitativo: representa os dados que serão apurados/medidos (Metric). Umconjunto de dados é associado às questões formuladas a fim de que sejam traduzidasquantitativamente. 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 pontode vista em que será analisada a medida. Exemplo: facilidade de leitura de um texto,nível de satisfação do usuário etc.

Assim, um modelo GQM é uma estrutura hierárquica que inicia com adefinição de um objetivo (goal), especificando o propósito da medição, os objetos easpectos desses objetos que serão avaliados, e o ponto de vista em que as medidas serãoanalisadas. 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 pararesponder 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 dacoleta das métricas sejam observados os diversos pontos de vista a que se destinam, pois amesma 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 objetivosacerca de qualidade e/ou produtividade definidos para a organização, para a divisão ou parao projeto, tais como satisfação do usuário, entrega de serviço no prazo, melhoria dedesempenho.[2 – p 5]

A partir da identificação dos objetivos e com base em modelos do objetoem avaliação, derivam-se questões que possam definir esses objetivos de forma maiscompleta. Por exemplo, se o objetivo é caracterizar um software quanto a determinadasqualidades (e.g., portabilidade), então faz-se necessária a escolha de um modelo para oproduto que qualifique esses interesses (e.g., relação de características funcionais queprecisam ser implementadas para diferentes arquiteturas).

O próximo passo consiste em especificar as medidas que devem sercoletadas a fim de responder às questões e acompanhar a conformidade dos produtos eprocessos 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 daaplicação da abordagem GQM, e será apoiado por passos metodológicos específicos. Para aconsecuçã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 queaplica 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 naorganização, derivam-se o “aspecto” e o “propósito” para o objetivo a ser perseguido.


16

A segunda fonte de informações é a descrição dos processos e produtosda organização, ou, pelo menos, daqueles que estão dentro do escopo do programa demedidas que se pretende efetuar. A partir desse fonte, com a especificação dos modelos deprocessos 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 eprocessos são relevantes para todos os pontos de vista na organização. Assim, há que sefazer uma análise da relevância dos objetivos para a organização, antes de se considerarconcluí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çãode cada objetivo podem-se derivar questões significantes que quantificam o objetivo.Geralmente, são feitos pelo menos três grupos de questões:

G 1. Como se pode caracterizar o objeto (produto, processo ou recurso) com orespeito 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çãonum 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 comrespeito 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çãodestas com as métricas apropriadas. Diversos fatores devem ser considerados, dentre eles:

− Volume e quantidade dos dados existentes - deve-se buscar maximizar o uso dasfontes de dados existentes, desde que estejam disponíveis e sejam confiáveis.

− Maturidade dos objetos em medição - devem-se aplicar medidas objetivas paraobjetos com maior nível de maturidade, e avaliações subjetivas quando se trabalhacom objetos instáveis ou informais.

− Aprendizado do processo - o uso de modelos QGM requer sempre refinamento eadaptação. Assim, as medidas definidas devem auxiliar não somente na análise doobjeto medido, mas também na avaliação do próprio modelo.


17

Como exemplo de aplicação da abordagem Goal/Question/Metric, apresenta-se asuposição de modelo em que se pretenda melhorar o prazo no atendimento às solicitaçõesde mudança para um determinado sistema em fase de manutenção. O objetivo definidodeverá explicitar o propósito (melhorar), o processo (atendimento de solicitações demudança), o ponto de vista (gerente de projeto), e o aspecto a ser observado (prazo deexecução). Esse objetivo deve ser refinado em uma série de questões, que serãorespondidas a partir da comparação do tempo coletado com média. O modelo GQMcompleto seria: [2 – p 8]

Objetivo Propósito Melhoria

Aspecto Prazo

Objeto (processo) Atendimento das solicitações

Ponto de vista Gerente de projetos

Questão Q1 Qual o tempo corrente no atendimento desolicitações de mudança?

Métricas M1 Média de tempo de cada fase

M2 Desvio padrão

M3 % de casos acima do limite superior

Questão Q2 O processo (documentado) no atendimento de

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

solicitações em função do estimado?

Métricas M6 Média da execução – média prevista * 100Média da execução

M7 Avaliação subjetiva do gerente de projeto

Questão Q4 O desempenho está melhorando?

Métricas M8 Média de tempo de execução * 100

Padrão de tempo para a faseQuestão Q5 O desempenho tem sido satisfatório sob o ponto de

vista do gerente de projeto?

Métricas M7 Avaliação subjetiva do gerente de projeto

Questão Q4 Há melhoria visível no desempenho?


18

Métricas 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çãodas técnicas, ferramentas e procedimentos apropriados à coleta de dados. Os dadoscoletados devem ser mapeados para o modelo e interpretados de acordo com esquemaspreviamente definidos pela organização.

Conclui-se, então, que a abordagem Goal/Question/Metric é umaabordagem para definição de um mecanismo de mensuração que possibilite oacompanhamento e avaliação do processo operacional de produção de software.


19

III. O Ambiente em que foi Implementado o Modelo GQM

Neste capítulo são apresentadas as principais características e a missãoinstitucional da instituição aonde foi implantado o processo de melhoria contínua usando oQIP/GQM - o Tribunal de Contas do Distrito Federal e, inserida nessa missão, o papeldesenvolvido pelo setor de informática.

A missão do TCDF

As competências constitucionais do Tribunal de Contas do DistritoFederal são:[3]

• apreciar, mediante emissão de parecer prévio, as contas anuais do Governadore julgar aquelas relativas aos administradores e demais responsáveis pordinheiro, bens e valores públicos;

• apreciar, para fins de registro, a legalidade dos atos de admissão de pessoal ede concessão de aposentadorias, reformas e pensões;

• avaliar a execução das metas estabelecidas no plano plurianual, nas diretrizesorç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 Executivoe Legislativo;

• fiscalizar as aplicações do Poder Público em empresas de cujo capital social oDistrito Federal participe de forma direta ou indireta;

• fiscalizar a aplicação de recursos repassados ou recebidos pelo DistritoFederal, a qualquer título;

• atender às solicitações da Câmara Legislativa relativas às atividades deControle Externo;

• aplicar, em caso de ilegalidade ou irregularidade de contas, as sançõesprevistas em lei e sustar, se o Tribunal não for atendido, a execução de atoimpugnado.

No planejamento estratégico para o período de 1999 a 2003 [7] é dadoespecial relevo ao estabelecimento da missão institucional do TCDF com base nascompetê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 dereceitas é exercida pela Câmara Legislativa - mediante controle externo e pelo sistema decontrole 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 doTribunal pode ser enunciada como:

“Exercer o controle externo da administração dos recursos públicos doDistrito Federal, em auxílio à Câmara Legislativa, zelando pela legalidade, legitimidade,efetividade, eficácia, eficiência e economicidade na gestão desses recursos.”


20

Releva notar que o atributo principal do papel da Corte de ContasDistrital é garantir à sociedade segurança quanto à transparência e boa gestão dos recursosarrecadados 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 desoluções que associem qualidade, funcionalidade e economicidade.

Nesse contexto, ao setor de informática do Tribunal, denominado Núcleode Informática e Processamento de Dados – NIPD, compete apoiar a atividade defiscalização por meio da criação de sistemas de informação para acompanhamento dosgastos 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áriossistemas 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 acompra de bens e serviços relativos a tecnologia.

Adicionalmente, o setor mantém atualizado, com o apoio de diversasUnidades do TCDF, o site www.tc.df.gov.br que permite a qualquer cidadão consultar osdocumentos públicos produzidos no exercício do controle externo.

Por ser um ente público com especial apreço pela boa gestão dosrecursos, antes de efetuar investimentos são feitas análises de alternativas com vistas aencontrar a melhor relação custo x benefício. Essa prática, aplicada ao setor de informáticaserá, como apresentado a seguir, motivadora do desenvolvimento de um processo deprodução de software.

Motivação para o estabelecimento do processo de desenvolvimento

Devido ao esforço necessário ao estabelecimento de um processo dedesenvolvimento, 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 aseguir relacionadas.

Melhoria da qualidade de produtos

Sendo o TCDF um órgão de informatização relativamente recente, apartir de 1995, a equipe responsável pelo desenvolvimento de sistemas teve a oportunidadede construir todo um conjunto de aplicações corporativas, com base nas necessidadesidentificadas junto aos usuários, integrado e homogêneo. No entanto, o processo deconstrução dessas soluções foi fortemente influenciado pela experiência profissional dosté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 linhasde 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 4programadores), faz-se necessário aprimorar o processo de trabalho visando a elaboração


21

de produtos com menor número de erros possível, que observem a integração e ahomogeneidade dos sistemas já desenvolvidos.

Planejamento de novas demandas

Da forma atual, as estimativas de prazo para desenvolvimento oumanutenção de sistemas são baseadas somente na experiência pessoal dos técnicos, sem umacompanhamento efetivo dos prazos.

Essa situação, apesar de bastante comum nas organizações, é fator derisco para a credibilidade do setor no caso de falha. Felizmente, desde 1995, os técnicostem acertado em suas previsões à administração da Casa. No entanto, o acompanhamentosistemático do processo de desenvolvimento de software será fundamental para aperfeiçoaras 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 novosserviços e programas ao setor de informática do TCDF, a partir do final de 1998, a equipetécnica iniciou trabalho de busca de alternativas com vistas a reduzir a necessidade deinvestimentos 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 detrabalho do TCDF, proporcionando elevada redução de investimentos com hardware esoftware [8].

Assim, com vistas a possibilitar essa substituição, será necessárioconverter todos os sistemas desenvolvidos e configurar aplicativos de escritório quepossibilitem ao usuário final usufruir das mesmas funcionalidades hoje disponíveis.

Esse fato gerará intenso esforço de codificação que, semacompanhamento formalizado por meio de um processo de desenvolvimento definido eutilizado por todos os técnicos, poderá inviabilizar a substituição da plataformacomputacional proposta pelo fracasso na conversão dos sistemas.

Para que seja possível substituir gradualmente as aplicações, optou-se porutilizar a linguagem Java como padrão para a execução dessa tarefa. A linguagem deprogramação Java permite disponibilizar os sistemas tanto para estações Windows 95 comoLinux e irá facilitar a reutilização de código.


22

IV. Implementando Um Processo De Melhoria Contínua –

Metodologia Empregada

Conforme podemos observar em, um processo contínuo de melhoria pode serimplementado institucionalmente, independente se a atividade fim da empresa é produzirsoftware ou outra qualquer, seguindo-se alguns passos descritos detalhadamente aseguir:[5]

- Montar uma Equipe de Melhoria do Processo:

A primeira e mais crítica atividade ao montar uma equipe é a aprovação da gerênciapara todo o processo de melhoria do software na organização. É importante destacar quenesse processo uma série de recursos devem ser alocados. A equipe designada para essatarefa, 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 depesquisadores e consultores externos.

Hoje já é amplamente reconhecido que uma equipe de melhoria dos processos daorganizaçã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: otempo de ser implantado um processo de qualidade com certificação ISO 9001.

Nesse ambiente em que foi implementado o Modelo GQM, a montagem da equipede melhoria dos processos foi o primeiro passo dos trabalhos. Os profissionais maisexperientes foram alocados e levantaram todos os processos do TCDF, propondo melhoriasnos que não se enquadravam plenamente no novo processo de informatização daorganização. O levantamento desses processos foi feito por 6 (seis) analistas de sistemasdurante um mês, dedicados exclusivamente à esta tarefa.

- Modelar os Processos Existentes:

Modelar os processos existentes em uma organização pode servir para váriospropósitos e agregar diversos benefícios. No contexto de melhoria de processos, modelosde processos descritivos são úteis para se entender a maneira como as coisas funcionam epara comunicar esse entendimento.

Algumas questões básicas que necessitam serem respondidas em uma modelagemde 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 ?


23

Fontes de informação para responder essas questões indicam que devem serutilizadas entrevistas com os membros da organização, inspeções nas documentações dosprocessos (quando existirem), inspeções nas documentações de gerência do projeto etambém observações diretas na equipe de desenvolvimento.

Os modelos de processos que foram desenvolvidos serão usados em passossubsequentes do processo de melhoria. Um bom sinal é quando os desenvolvedorespenduram 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 edescritos de forma a explanar claramente as atividades intrínsecas de cada um, asdependências entre essas atividades, o tempo de duração de cada uma delas, os atores queas executam e as interdependências entre estes atores.

- Conduzir uma Análise Qualitativa:

A meta desse estágio é identificar as causas e os mecanismos internos que indiquemos 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á serresponsável pela análise contínua desse problemas. Uma modelagem dos processos bemdefinida, ajudará a diferenciar os verdadeiros problemas dos aspectos irrelevantes. Nessecontexto, existem três técnicas principais para se fazer a análise qualitativa: entrevistasestruturadas, análise eventual dos problemas e questionários bem definidos e bemdesenhados. 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 dafase de testes, ou já da operação, de um determinado sistema. Para executar a análiseeventual 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 bemdefinidos e modelos organizacionais.

No TCDF, como os processos já haviam sido modelados e bem definidos, nesta faseforam elaborados também os procedimentos de coleta de dados e desenhados os


24

formulários. Foi selecionado o Sistema de Acompanhamento de Processos para uma análisepreliminar da metodologia a ser empregada. Foram levantados os problemas apresentadosna versão do sistema e classificadas a s falhas segundo critérios de gravidade estabelecidospelo gerente de informática.

- Definir e Documentar um Plano de Ação:

Uma vez que os processos estão modelados e seus pontos fortes e fracos estão bementendidos, um plano de ação deve ser definido. Para o Software Engineering ProcessGroup 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 importantepor várias razões, dentre elas podemos citar: é solicitado para conseguir uma mudança doorç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 desenvolvedoressobre a importância e as dificuldades do que será realizado.

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ênciacorrespondentes, os gerentes encarregados de monitorar e organizar as fases deexecução;

- O conjunto de atividades envolvidas em cada fase de cada passo, os participantesem 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 quecontempla: procedimentos de desenvolvimento e manutenção de sistemas, estabelecimentode um fluxo de solicitações de sistemas, o Sistema de Acompanhamento doDesenvolvimento de Sistemas – SADS, que permite o registro do processo e a extração dasmé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 basequantitativa de comparações para futuras mudanças de processos, melhor entendimento dosrequisitos 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 provendoinformações gerenciais corretas e no tempo certo sobre produtos de software e os processosutilizados para desenvolvê-los. Em várias ocasiões já foi percebido que o êxito de um


25

programa de medições está no seu direcionamento para as metas e objetivos daorganização.

Os passos usuais de um processo de medição podem ser resumidos da seguinteforma:

- 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.

Neste passo da metodologia foram feitas as entrevistas recomendadas na abordagemGQM, onde foram definidas as metas corporativas e de medidas. Foram aplicados osprocedimentos de coleta de dados e implantadas as rotinas de utilização formuláriosdesenhados anteriormente, sendo treinados os funcionários responsáveis pela captação ealimentação dos dados. Este passo não apresentou problemas, pois, a coleta dos dados foivoltada para as metas estabelecidas nas entrevistas, as metas de medição foram claramenteespecificadas. Não houve uma sobrecarga no trabalho dos desenvolvedores para coletar osdados 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 sertransferida para a memória da organização. Tudo que pôde ser observado no Projeto Pilotodeve ser usado para ensinar a tecnologia, as formas e materiais de seu treinamento para aorganização. Também os procedimentos de coleta de dados talvez tenham de sermodificados para levar em conta as lições aprendidas no Projeto Piloto.


26

Para transferir a tecnologia para a memória da organização, alguns pré-requisitosdevem ser observados. Primeiro, a estrutura de recompensa deve ser mudada para refletir asmetas da tecnologia transferida. Por exemplo, se a cultura atual da organização recompensaa produtividade, então a introdução de métodos estruturados de análise e projeto, quediminuem a rapidez da execução das primeiras fases do projeto, são improváveis de seremadotados 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 tecnologiadisponível para resolver os problemas e, se necessário, prover treinamento para os membrosda organização.

Por ser o TCDF uma organização pública, que contém processos e procedimentosestabelecidos em leis, as mudanças dos processos muitas vezes tornam-se problemáticas eaté impossíveis de serem realizadas. Neste cenário, mudar a organização é praticamenteinviável. O que é factível, e que já está em curso, é a proposição de mudanças sistemáticase paulatinas na execução de processos e procedimentos. Esta proposição é feitademonstrando-se os aspectos favoráveis e desfavoráveis destas mudanças, encaminhando-as para posterior decisão das autoridades competentes, gestoras destes processos.

Neste capítulo os autores apresentaram uma abordagem ascendente para a melhoriaprática do processo de produção de software e seus produtos. Estes passos devem ser vistoscomo uma implantação do Paradigma de Aperfeiçoamento da Qualidade – QIP. A fim defacilitar sua aplicação em diferentes organizações de desenvolvimento e manutenção desoftware, 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.


27

V. Conclusão, Perspectivas e Futuros Trabalhos

O presente trabalho tem por objetivo apresentar a fundamentação teórica e um casoprático da abordagem QIP/GQM aplicada em uma empresa brasileira, o Tribunal de Contasdo Distrito Federal – TCDF. Nos principais modelos de qualidade de software apresentadosneste trabalho, o modelo CMM foi o escolhido por nortear de forma objetiva e direta, asações de implementação de modelos de qualidade de software em empresas nacionais.

O Paradigma de Aperfeiçoamento da qualidade – QIP estabelece premissasfundamentais para que uma organização possa melhorar cada processo de software:caracterizar o ambiente, definir os objetivos, escolher os processos, analisar os dados einformaçõ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 serestabelecida uma continuidade do processo de melhoria de software nas organizações.

A abordagem GQM, objeto de estudo deste trabalho, é utilizada como mecanismoou técnica, para que seja implementado um programa permanente de avaliação e melhoriada qualidade de software das organizações. Esta técnica foi escolhida principalmente pelasua abordagem objetiva e abrangente na condução dos trabalhos de melhoria da qualidadede software dentro das organizações.

Conforme foi citado anteriormente, o presente trabalho será a parte inicial dadissertação de mestrado que versará sobre a viabilidade de se implantar e manter modelosde qualidade de software em empresas brasileiras, visando a melhoria contínua dosprodutos de software dessas empresas. Para tanto, pretende-se implementar a abordagemGQM. com todas as suas implicações, em outra empresa nacional. Contaremos com acolaboração da equipe do Núcleo de Informática do TCDF para orientar a implantação detodo o processo, que deverá se dar primeiramente em uma equipe de desenvolvimento desoftware provavelmente da ECT -Correios do Brasil.


28

Bibliografia

[1] BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H. Dieter. TheExperience Factory. Institute for Advanced Computer Studies /Department of Computer Science / University of Maryland (EUA); & FBInformatik / Universität Kaiserlautern (Alemanha). In:http://www.cs.umd.edu/projects/SoftEng/tame/ tame.html.

[2] ____. The Goal Question Metric Approach. Institute for AdvancedComputer Studies / Department of Computer Science / University ofMaryland (EUA); & FB Informatik / Universität Kaiserlautern(Alemanha). In: http://www.cs.umd.edu/projects/SoftEng/tame/tame.html.

[3] BRASIL. CÂMARA LEGISLATIVA - DF. Lei Orgânica do DistritoFederal, Brasília: Câmara Legislativa, 1993.

[4] BRASIL. CONGRESSO NACIONAL. Constituição Federal, Brasília:Congresso Nacional, 1988.

[5] BRIAND, Lionel; EL EMAM, Khaled; MELO, Walcélio L. An InductiveMethod for Software Process Improvement: Concrete Steps andGuidelines. In: Elements of Software Process Assessment andImprovement. 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. LosAlamitos, 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 forSmall Businesses, Small Organizations, and Small Projects. In: Elements


29

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. SoftwareProcess 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; ComputerSciences 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 EstimatesForm 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. TheCapability Maturity Model for Software. In: Elements of SoftwareProcess 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 AdvancedEngineering Study, MIT Press, Cambridge, MA, 1986


30


ANEXO I

Modelo GQM aplicado ao desenvolvimento de sistemas no TCDF

Considerando o contexto e as razões acima descritos estabeleceu-se oseguinte modelo Goal, Question, Metric, adiante detalhado, para a área de desenvolvimentode sistemas do Tribunal de Contas do DF.

Objetivo Propósito Melhoria

G1 Aspecto Qualidade

Objeto Sistemas Desenvolvidos (produto)

Ponto de vista Gerente

Questão Q1 Quantidade de erros encontrados pelo usuário?

Métricas M1 # mensal de ocorrências de manutenções corretivas

M2 # mensal de ocorrências de erros que afetam odesempenho dos sistemas

M3 # mensal de ocorrências de erros que afetam ofuncionamento de pelo menos uma função

M4 # mensal de ocorrências de erros que afetam ofuncionamento de pelo menos um sistema

M5 # mensal de ocorrências de erros que geraminformações inconsistentes

Questão Q2 A qualidade dos produtos está melhorando?

Métricas M6 % de variação do último mês com relação a médiaacumulada para M1

M7 % de variação do último mês com relação a médiaacumulada para M2





Objetivo Propósito Avaliar

G2 Aspecto Tempo

Objeto Conversão dos sistemas em Visual Basic (VB) paraJava


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

Questão Q4 Qual o tamanho dos sistemas convertidos?

Métricas M13 Quantidade de arquivos dos sistemas convertidos paraJava

M14 Quantidade de linhas de código (LOC) dos sistemasconvertidos para Java

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 paraJava

Métricas M17 M16 por arquivo VB


G3 Aspecto Planejamento

Objeto Processo de Desenvolvimento de Sistemas



Questão Q6 Qual a diferença entre o esforço (tempo) estimado e orealizado?

Métricas M18 (Esforço real - Esforço estimado) por ocorrência e fase

M19 (M18 / Esforço estimado) * 100 por ocorrência e fase

M20 Média de M19 por objetivo e fase

Questão Q7 Qual a diferença entre os prazos previstos e realizados?

Métricas M21 (Data de início real - Data de início estimada) em diaspor ocorrência e fase


M23 (Data de fim real - Data de fim estimada) em dias porocorrência e fase



G4 Aspecto Qualidade

Objeto Processo de Desenvolvimento de Sistemas


Questão Q8 Qual o número de erros identificados pela equipe dedesenvolvimento durante a elaboração do sistema?

Métricas M25 # mensal de erros encontrados na leitura de código

M26 # mensal de erros encontrados na leitura de código queafetam o desempenho dos sistemas


M27 # mensal de erros encontrados na leitura de código queafetam o funcionamento de pelo menos uma função

M28 # mensal de erros encontrados na leitura de código queafetam o funcionamento de pelo menos um sistema

M29 # mensal de erros encontrados na leitura de código queque geram informações inconsistentes

M30 # mensal de erros encontrados nos testes de integraçãoe implantação

M31 #mensal de erros encontrados nos testes de integração eimplantação que afetam o desempenho dos sistemas

M32 # mensal de erros encontrados nos testes de integraçãoe implantação que afetam o funcionamento de pelomenos uma função

M33 # mensal de erros encontrados nos testes de integraçãoe implantação que afetam o funcionamento de pelomenos um sistema

M34 # mensal de erros encontrados nos testes de integraçãoe implantação que que geram informaçõesinconsistentes

Questão Q9 Qual a relação entre os erros encontrados pelo usuário eos erros identificados durante a elaboração do sistema?

M35 M1 / (M25 + M30)

M36 M2 / (M26 + M31)

M37 M3 / (M27 + M32)

M38 M4 / (M28 + M33)

M39 M5 / (M29 + M34)

Questão Q10 Qual a origem (fonte) dos erros encontrados?

M40 # mensal de erros encontrados pelos usuários por fontede erro

M41 # mensal de erros encontrados na leitura de código porfonte de erro

M42 # mensal de erros encontrados nos testes de integraçãoe implantação por fonte de erro

M43 M40 / (M41 + M42)


Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos

Procura-se aqui ter condições de dimensionar a melhoria dos produtosentregues aos usuários finais, utilizando-se como indicador principal a quantidade de errospercebida pelos usuários. Para esse objetivo foram definidas duas questões:

1. Q1 - Qual a quantidade de erros encontrados pelos usuário? - procura dimensionar osvazamentos de erros não encontrados na produção do sistema, permitindo quantificar ostranstornos causados aos usuários. Em resposta a essa questão foram extraídas asseguintes medidas:

1.1. M1 = Número mensal de ocorrências de manutenções corretivas - contabilizatodas as ocorrências de erros encontradas pelos usuários independentemente de suagravidade;

1.2. M2 = Número mensal de ocorrências de erros que afetam o desempenho dossistemas - constituem um subgrupo de M1 e foram destacadas pois prejudicam odesempenho do sistema;

1.3. M3 = Número mensal de ocorrências de erros que afetam o funcionamento depelo menos uma função - constituem outro subgrupo de M1 e foram destacadaspois prejudicam o desempenho de pelo menos uma função (tipicamente uma tela detransação) do sistema;

1.4. M4 = Número mensal de ocorrências de erros que afetam o funcionamento depelo menos um sistema - constituem outro subgrupo de M1 e foram destacadas poisprejudicam 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çõesinconsistentes - constituem outro subconjunto de M1 e foram destacadas poisprovocam o armazenamento ou exibição de informações inconsistentes.

2. Q2 - A qualidade dos produtos está melhorando? - visa avaliar a evolução daqualidade dos produtos entregues por meio da comparação das métricas da Q1 acimadescritas ao longo do tempo. Em resposta a essa questão foram extraídas as métricasabaixo:

2.1. M6 = Percentual de variação do último mês com relação a média acumuladapara M1 - obtida pela divisão da medida de M1 para o último mês pela média deM1 nos meses anteriores ao último mês multiplicado por 100;

2.2. M7 = Percentual de variação do último mês com relação a média acumuladapara M2 - cálculo idêntico ao de M6 utilizando como parâmetro M2;

2.3. M8 = Percentual de variação do último mês com relação a média acumuladapara M3 - cálculo idêntico ao de M6 utilizando como parâmetro M3;

2.4. M9 = Percentual de variação do último mês com relação a média acumulada


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 acumuladapara 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 sistemaoperacional utilizado no TCDF, faz-se necessário reescrever todos os sistemas em produçãona linguagem Java para que os mesmos possam continuar sendo utilizados. Esse objetivovisa aperfeiçoar as estimativas de conversão dos sistemas por meio da análise das seguintesquestõ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 dossistemas desenvolvidos e em desenvolvimento em diretórios de trabalhoespecíficos e procede-se a contagem. Essa métrica é extraída por apuraçãoautomática em lote, pelo próprio sistema de apoio ao processo, não necessitando depreenchimento 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 deinformação. Essa métrica é extraída por apuração em lote não necessitando depreenchimento de formulários.

2. Q4 - Qual o tamanho dos sistemas convertidos em Java? - assim, pode-se avaliar oimpacto de substituição da linguagem em termos de tamanho (LOC) dos sistemasconvertidos e acompanhar o progresso do processo de conversão. Para responder a essaquestão são medidos:

2.1. M13 = Número de arquivos dos sistemas - contagem efetuada de forma idêntica aM11 para os diretórios dos sistemas em Java; e

2.2. M14 = Número de linhas de código por sistema - soma efetuada de formaidêntica a M12 para os diretórios dos sistemas em Java.

3. Q5 - Qual o tempo para conversão dos sistemas? - questão principal para o objetivopretendido pois informa o esforço realizado até o momento e permite estimar a tarefarestante. Para responder a essa questão são extraídas as seguintes medidas:

3.1. M15 = Tempo total de conversão por sistema - soma das horas de trabalhadas paraconversão de cada sistema até o momento;

3.2. M16 = Tempo médio de conversão de uma linha de código em VB para Java -


soma de todo o tempo de codificação em Java para conversão dividida pelotamanho (em linhas de código VB) de todos os arquivos convertidos até omomento; e

3.3. M17 = Tempo médio de conversão de uma linha de código em VB para Java porarquivo VB - soma de todo o tempo de codificação em Java para conversão doarquivo dividida pelo tamanho (em linhas de código VB) do arquivo - possibilitaavaliar a evolução da eficiência do trabalho e a complexidade da conversão de cadaarquivo.

Objetivo G3 - Avaliar o planejamento do processo de desenvolvimento de sistemas

O processo de desenvolvimento de sistemas implantado contempla oplanejamento 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 quepossibilita verificar a precisão do planejamento de recursos; no caso do TCDF, oprincipal 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 (entenda-se fase do processo de desenvolvimento como: especificação, codificação, leiturade código, e teste de integração e implementação) - diferença em minutos entre oesforço real e o esforço estimado - valores negativos expressam estimativas a maiore valores positivos estimativas a menor;

1.2. M19 = (M18 / esforço estimado) * 100 agrupado por ocorrência e fase - indica opercentual 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 daequipe de desenvolvimento em cada ocorrência: manutenção corretiva,manutenção evolutiva ou desenvolvimento de um novo sistema) e fase - permiteavaliar se há discrepâncias significativas entre as previsões feitas para cada tipo deobjetivo e dentro de cada objetivo por fase do processo de desenvolvimento desistemas.

2. Q7 = Qual a diferença entre os prazos previstos e reais? - possibilita aferir a precisãodas estimativas de datas de início e fim de cada fase do processo de desenvolvimento.Para essa aferição são computados:

2.1. M21 = (data de início real - data de início estimada) em dias agrupado porocorrência e fase - mede a precisão no planejamento do início de cada fase doprocesso de desenvolvimento - valores negativos indicam fases iniciadas antes dadata estimada;

2.2. M22 = Média de M21 agrupada por objetivo e fase - indica se há variaçãosensível entre as previsões de início por objetivo e/ou fase do processo de


desenvolvimento de sistemas;

2.3. M23 = (data de fim real - data de fim estimada) em dias agrupado por ocorrênciae fase - mede a precisão no planejamento do fim de cada fase do processo dedesenvolvimento - valores negativos indicam fases concluídas antes da dataestimada; e

2.4. M24 = Média de M23 agrupada por objetivo e fase - indica se há variaçãosensível entre as previsões de término por objetivo e/ou fase do processo dedesenvolvimento de sistemas.

Objetivo G4 - Avaliar a qualidade do processo de desenvolvimento de sistemas

Com a implantação do processo de desenvolvimento de sistemaspretende-se reduzir o número de erros encontrados pelo usuário, ou seja, erros após aentrada do sistema em produção, estabelecendo-se pontos de teste no processo dedesenvolvimento de sistemas com a execução das atividades de leitura de código e teste deintegração e implantação. Assim, para avaliar a efetividade do processo em termos deidentificação de erros e redução de vazamentos (erros encontrados pelos usuários) foramdefinidas as seguintes questões:

1. Q8 - Qual o número de erros identificados pela equipe de desenvolvimento durante aelaboração do sistema? - possibilita aferir a eficácia das atividades de teste implantadascom 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 aquantidade de erros identificados na fase de leitura de código pela equipe dedesenvolvedores a cada mês;

1.2. M26 = Número mensal de erros encontrados na leitura de código que afetam odesempenho dos sistemas - indica a quantidade de erros identificados na fase deleitura de código que prejudicam o desempenho do sistema pela equipe dedesenvolvedores a cada mês;

1.3. M27 = Número mensal de erros encontrados na leitura de código que afetam ofuncionamento de pelo menos uma função - indica a quantidade de errosidentificados na fase de leitura de código que prejudicam o desempenho de pelomenos uma função (tipicamente uma tela de transação) do sistema pela equipe dedesenvolvedores a cada mês;

1.4. M28 = Número mensal de erros encontrados na leitura de código que afetam ofuncionamento de pelo menos um sistema - indica a quantidade de errosidentificados na fase de leitura de código que prejudicam o desempenho de pelomenos um sistema (toda uma aplicação) pela equipe de desenvolvedores a cadamês;

1.5. M29 = Número mensal de erros encontrados na leitura de código que geraminformações inconsistentes - indica a quantidade de erros identificados na fase de


leitura de código que provocam o armazenamento ou exibição de informaçõesinconsistentes pela equipe de desenvolvedores a cada mês;

1.6. M30 = Número mensal de erros encontrados nos testes de integração eimplantação - totaliza a quantidade de erros identificados na fase testes deintegraçã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 eimplantação que afetam o desempenho dos sistemas - indica a quantidade de errosidentificados na fase testes de integração e implantação que prejudicam odesempenho do sistema pela equipe de desenvolvedores a cada mês;

1.8. M32 = Número mensal de erros encontrados nos testes de integração eimplantação que afetam o funcionamento de pelo menos uma função - indica aquantidade de erros identificados na fase testes de integração e implantação queprejudicam o desempenho de pelo menos uma função (tipicamente uma tela detransaçã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 eimplantação que afetam o funcionamento de pelo menos um sistema - indica aquantidade de erros identificados na fase testes de integração e implantação queprejudicam o desempenho de pelo menos um sistema (toda uma aplicação) pelaequipe de desenvolvedores a cada mês;

1.10. M34 = Número mensal de erros encontrados nos testes de integração eimplantação que geram informações inconsistentes - indica a quantidade de errosidentificados na fase testes de integração e implantação que provocam oarmazenamento ou exibição de informações inconsistentes pela equipe dedesenvolvedores a cada mês;

2. Q9 - Qual a relação entre o número de erros identificados pelo usuário e os errosidentificados durante a elaboração do sistema? - possibilita a comparação entre asquantidades de erros encontrados pelos usuários dos sistemas (vazamentos) e de errosencontrados pela equipe de desenvolvimento de sistemas nas fases de leitura de códigoe 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áriocom 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 aequipe de desenvolvimento;

2.2. M36 = M2 / (M26 + M31) - análoga a métrica anterior limitando a comparação aoserros que afetam o desempenho dos sistemas;

2.3. M37 = M3 / (M27 + M32) - análoga a métrica anterior limitando a comparação aoserros 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


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 aoserros que geram informações inconsistentes

3. Q10 - Qual a origem (fonte) dos erros encontrados? - visa caracterizar a origem doserros para auxiliar na redução dos mesmos. As fontes de erro possíveis no processo dedesenvolvimento implantado são: codificação, especificação, modificação anterior erequerimentos 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 deerro 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 deerro - agrupa mensalmente os erros encontrados pela equipe de desenvolvimentona 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 eimplantação por fonte de erro - agrupa mensalmente os erros encontrados na fasede testes de integração e implantação pela equipe de desenvolvimento de sistemaclassificados de acordo com o técnico responsável; e

3.4. M43 = M40 / (M41 + M42) - compara os erros encontrados pelos usuários e pelaequipe técnica de acordo com a fonte de erro indicada.

Todas essas métricas são obtidas automaticamente por meio dos sistemasde apoio ao processo de desenvolvimento implantado, descrito no próximo capítulo.


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 envolvemdesde 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 oacompanhamento das mesmas tanto pela gerência como pelos próprios usuários. Para issofoi implantado, em maio de 1999, um aplicativo na intranet do TCDF que possibilita aosusuários efetuarem suas solicitações e acompanharem o andamento dos serviços.

Esse sistema se mostrou adequado para as demandas relativas amanutenção de equipamentos, dúvidas de usuários, instalação de programas, etc., mas nãopermitia maior detalhamento das fases relativas ao processo de desenvolvimento desistemas.

Assim, considerando a importância de disciplinar o processo dedesenvolvimento, as razões que motivaram sua implantação descritas no item contexto daaplicação do processo, o modelo GQM definido e a maturidade da equipe dedesenvolvimento, foram criados os documentos contendo o processo de desenvolvimentode sistemas, os formulários que suportam esse processo e desenvolvido o Sistema deAcompanhamento do Desenvolvimento de Sistema no TCDF - SADS - que permite oregistro do processo e a extração das métricas estabelecidas (anexo 4).

Abaixo, apresenta-se de forma esquemática o diagrama do processo dedesenvolvimento praticado no TCDF.

Universidade Católica de Brasília, Mestrado em Informática, Qualidade de Software, UCB-QSW-TR-2001/07InícioAbertura de chamado ao

NIPD na intranet por usuário

É relativo aodesenvolviment

o de sistemas

Elaboração deCronograma de Desenvolvimento

de Sistemas - CDS

Sim

Não Processos quefogem ao

escopo destetrabalho

Análise de Requerimentos dousuário

Elaboração da especificação(projeto)

Projetoaprovado

Não

Codificação

Leitura de Código

Correções

Sim

Não

Correção após leitura de código

Fim

Teste de integração e implementação

Correções

Sim

Não

Correção após teste

Fim

1

1


As atividades realizadas pelos participantes do processo, segundo o papelque exercem, são as seguintes:

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;

Usuário Analista Equipe Prog.1 1 Prog. 2 Prog. 3 Secretária Gerência

Abrechamado Abre CDS2

Analisarequeri-mentos

Elaboraprojeto

RTF3 Codifica Lê código Testa

Implantação

PreencheRSA5

PreencheRSA

PreencheRSA

PreencheRSA

ConcluiCDS

PreencheREF4

PreencheREF

DigitaRSA

DigitaREF

DigitaCDS

Extraimétrias

Avaliaresultados


Vale notar que esse processo vem sendo ajustado, desde setembrode 1999, para se adequar às necessidades do setor de informática. Inicialmente, foramutilizados formulários mais detalhados para as fases de codificação, baseados nos utilizadospelo SEL/NASA (anexo 3), que se mostraram de difícil preenchimento e aceitação porparte da equipe técnica. Assim, complementarmente ao registro de tempo feito por meio doRSA, o registro do tamanho dos sistemas e programas é feito por rotina de apuraçãosemanal.

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 doprocesso permitiu conhecer melhor a forma de atuação da equipe e promover ajustes deprocedimentos.

Análise da aplicação do processo

O acompanhamento do processo de desenvolvimento de sistemasrealizado a partir de novembro de 1999 possibilitou obter os resultados apresentados nestetópico, segundo o modelo GQM apresentado anteriormente. Para melhor compreensão dosmesmos as análises serão realizadas para cada objetivo definido, tomando-se por base asmétricas obtidas até 23 de junho do corrente relacionadas no anexo 2.

Os resultados obtidos da análise dessas métricas não necessariamenterepresentam uma tendência neste momento, uma vez não há ainda uma base consolidadapara comparação. Restando dizer que essas medidas passam a representar a formação deconjunto de indicadores para análises futuras mais consistentes.

Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos

Da observação das métricas apuradas para este objetivo pode-se constataro 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 melhoracompanhamento do processo de desenvolvimento estabelecido.

Há que se considerar, porém, que a grande maioria dos erros encontradosnão se originam de produtos do atual processo de desenvolvimento, resultam de sistemasem 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étricaM16 que representa o tempo médio de conversão de uma linha de código VB para Java. Poressa medida cada linha de código VB é convertida para Java em 1,71 minutos, em média.


Assim, pode-se comparar o tempo médio de conversão com a média deconversão por arquivo (M17) e identificar quais funções consumiram mais recursos ou sãomais 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 temponecessário para a completa conversão dos sistemas. Por exemplo, o Sistema de Acesso àsBases de Dados - SABD, atualmente em conversão, por essa medida, requer 550 horas paraestar totalmente convertido em Java. Uma vez que já foram realizadas 216 horas deconversão para esse sistema (M15), pode-se deduzir que resta um esforço de 334 horas paraconclusã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çãomé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 paramanutenção (corretiva ou evolutiva) tendem a ser maiores que os tempos realizados. Poroutro lado, as estimativas para desenvolvimento de novas funcionalidades tem sidomenores que os tempos reais.

Relativamente às estimativa de datas para início e conclusão de cada fasepor objetivo (M22 e M24), verifica-se uma tendência de acerto para a previsão de início ede superestimação das datas de término.

Os erros de estimativa, de um modo geral, decorrem do fato de a base deinformações do processo estabelecido estar ainda em construção. Além disso, observa-seuma 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 curtoperíodo de observação e a falta de hábito dos técnicos, os números apontados nesseobjetivo mostram-se muito modestos, o que inviabiliza uma melhor análise e indicanecessidade de reforçar a orientação para uso correto do processo.


MODELOS DE FORMULÁRIOS APLICADOS NO TCDF


Cronograma para Desenvolvimento/Manutenção de Sistema – CDS

Nº OCORRÊNCIA: DATA CONCLUSÃO: / /

Descrição :

OBJETIVO:

� Desenvolvimento � Manutenção Evolutiva � Manutenção CorretivaFonte do erro Gravidade do erro

� Requerimento do Usuário � não permite funcionamento do sistema

� Especificação � não permite funcionamento de alguma função� Codificação � compromete desempenho do sistema� Modificação Anterior � gera informações inconsistentes

� erro menor ou desvio dos padrões

Cronograma:PERÍODO ESTIMADO PERÍODO REAL

FASEInício Fim Início Fim

ESFORÇOESTIMADO

Responsável(eis)

Requerimentos / / / / / / / /

Especificação / / / / / / / /

Codificação / / / / / / / /

Leitura de Código / / / / / / / /

Testes / / / / / / / /

Detalhes sobre: Banco de Dados; Acessos; Serviço; Configuração de Servidor; Estação de Trabalho; etc.

Elaborado por:

Cadastrado por: Em: / /


INSTRUÇÃO DE PREENCHIMENTO DO CRONOGRAMApara DESENVOLVIMENTO/MANUTENÇÃO DE SISTEMAS -

CDS

ObjetivoFormulário destinado ao acompanhamento do atendimento às solicitaçõesregistradas no SSUF.

Campos

Nº Ocorrência número de registro da ocorrência no SSUFData Conclusão: indique a data de conclusão da implementação da

funcionalidadeMatrícula matrícula do funcionário que preenche o formulário.Nome nome do funcionárioDescrição resumo do que está sendo desenvolvido/modificado.Objetivo indique o objetivo da implementação, conforme o caso:

Desenvolvimento, Manutenção Evolutiva ou ManutençãoCorretiva

Fonte do erro somente em caso de manutenção corretiva, indique a origemdo erro.

Gravidade do erro somente em caso de manutenção corretiva, indique o nívelde gravidade do erro

Cronograma para cada fase informar:

Período estimado data de início e término previstos dos trabalhos;Período real preenchimento posterior, indicando as datas reais de

realização dos trabalhosEsforço estimado tempo em minutos previsto para consecução de cada faseResponsáveis nome do responsável pela execução da fase

Detalhes informar detalhes que devem ser observados quando dacolocação do sistema em produção, tais como: tabelas,stored procedure, views etc, que devem ser atualizadas nobanco de dados; configurações específica para o servidor derede ou estação de trabalho; alteração de serviços auxiliares,compilação simultânea de outros sistema, etc.


Relatório de Erros e Falhas – REF

TIPO DE VERIFICAÇÃO : � Leitura de Código � Teste de Integração Matrícula: Nome:

Nº OCORRÊNCIA: ARQUIVO FONTE:

Linha REFERÊNCIA FONTE1 GRAVIDADE2 Descrição

1 Fonte do Erro:REQ – Requerimento do Usuário; ESP – Especificação ; COD – Codificação; MOA – Modificação Anterior

2 Gravidade do Erro: 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


INSTRUÇÃO DE PREENCHIMENTO DO RELATÓRIO DEERROS E FALHAS - REF

ObjetivoFormulário destinado ao registro de erros ou falhas detectados durante a Leiturade 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, conformeo caso.

Matrícula matrícula do funcionário que preenche o formulário.Nome nome do funcionárioNº Ocorrência número de registro da ocorrência no SSUFArquivo fonte nome do arquivo fonte, inclusive extensão, que está sendo

criado ou alterado. Deve ser escrito com a maior nitidezpossível.

Referência informar o número a que se refere o erro de acordo com alista de verificação de erros e falhas

Linha número da linha do código a que se refere o erroFonte origem do erro, conforme legenda abaixo no formulárioGravidade nível de gravidade do erro, conforme legenda abaixo no

formulário


Relatório Semanal de Atividades – RSA

Matrícula.: Nome:

Dia Atividade1 Tempo nº Ocorrência Arquivo Fonte (inclusive extensão) Arquivo VB (somente em caso de conversão p/

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


INSTRUÇÃO DE PREENCHIMENTO DO RELATÓRIOSEMANAL DE ATIVIDADES - RSA

ObjetivoFormulário de preenchimento manual para inserção semanal de dados no Sistemade Acompanhamento do Desenvolvimento de Sistemas – SADS, com a finalidadede acompanhar o dispêndio de tempo no atendimento às ocorrências registradasno Sistema de Solicitações do Usuário Final - SSUF.

Campos

1. Matrícula: matrícula do funcionário que preenche o formulário.2. Nome: nome do funcionário3. Mês/ano: mês e ano de referência4. Dia: dia de referência do preenchimento5. Atividade: indicar sigla de acordo com a legenda abaixo do formulário6. Tempo: tempo gasto na execução da atividade em minutos, já descontadas

todas as interrupções7. Nº Ocorrência: número de registro da ocorrência no SSUF8. 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 SADS11.Por: assinatura ou nome do responsável pela digitação do formulário no

sistema.

Documents

Resumo Processo de Implantação de Gestão de · 1 Universidade Católica de Brasília – UCB Mestrado em Informática Qualidade de Software Processo de Implantação de Gestão