Trabalho apresentado à disciplina Pesquisa Operacional, do curso Tecnologia em Sistemas de Informações, setor Escola Técnica da Universidade Federal do Paraná.

Professora: Maria Valéria da Costa

1 INTRODUÇÃO

Para entender as métricas de qualidade, antes é preciso entender o que é qualidade em projetos de tecnologia de Informação. Por ser um assunto muito subjetivo e é encontrada certa dificuldade, principalmente por pessoas da área de informática, por ter o conceito de lógica como um de seus fundamentos. Mas essa subjetividade não é tão problemática assim, pois todos os caminhos podem levar ao caminho correto. Isso mostra que essa subjetividade é relativa, portanto um processo que pode ser o ideal para contexto de trabalho pode não ser bom para o outro.

Por isso começaremos tentando entender o que é qualidade, e o como seriam extraídas as métricas que devemos utilizar.

As métricas possuem como principal objetivo, se ter um controle da situação e melhorar o contexto até atingir um lugar ideal, o qual seria uma melhoria continua. De nada serve a extração de métricas e não usá-las para nada. Por isso é importante se começar um trabalho de extração de métricas já com o objetivo de saber o que se quer medir e no que se quer melhorar.

Existem diversos órgãos e nomes importantes nessa área, pois não é um assunto tão novo como se pensam, como no livro Qualidade de Software de Koscianski & Soares antigos relatos que os egípcios tinham um controle de qualidade para fazer suas pirâmides, utilizando cordas com nós, garantindo assim que o tamanho de suas pirâmides fossem sempre proporcional.

2 QUALIDADE EM PROJETOS DE SOFTWARE

Com o mundo tão volátil que temos hoje em dia, de constantes mudanças, causado principalmente pela globalização e competitividade do mercado, têm demandado um crescimento em quase todas as áreas, e esse crescimento é necessário para se ter competitividade nesse mundo dos negócios. Sendo eles os clientes que demandam os serviços em diversas áreas, não seria diferente na área de tecnologia da informação, eu diria, ainda mais, que essa demanda é principalmente na área de tecnologia da informação. Pois a melhor maneira de encurtar distâncias na globalização e ter um maior controle sobre os negócios em desenvolvimento, é o uso da internet e das ferramentas informatizadas.

Mas essas demandas exigem tempo para serem compridas, ou melhor, prazos para serem entregues os produtos. E juntando essas duas peças que já falamos requisito e prazos, deduzindo que prazos faz parte dos requisitos do cliente, portanto os projetos de desenvolvimento de software precisam atender o que o cliente quer e no prazo em que foi prometido entregar o software.

Qualquer área de vendas de qualquer tipo de negocio é importante conhecer o produto, para não se vender um produto impossível ser entregue no prazo desejado, e para possibilitar a negociação com o cliente.

Eu me perguntaria, e na área de desenvolvimento de software onde esse produto ainda não existe? No caso de projetos de software para se conhecer o “produto” é importante definir as métricas dos principais processos, e obter isso de outros projetos que já foram terminados, para assim finalizar com uma estimativa concreta, e conseguir uma boa comercialização. Esse é o desafio das estimativas dos projetos de software.

Bom, em nosso caso já temos dois fatores importantes que devem ser controlados em projetos, os prazos e os requisitos, pois se eles estão sendo atendidos, influenciam na qualidade do sistema, portando dois fatores que influenciam diretamente na qualidade.

3 PROCESSOS DE MÉTRICAS

Falando de requisitos, prazos e custos, ainda soam como um assunto muito subjetivo, portanto para haver algo mais palpável, tem que transformar esses fatores que influenciam na qualidade, em controles mais precisos e menos subjetivos, ou seja, se ter a capacidade de medir isso.

Uma maneira de transformar um desses fatores que queremos medir é definindo processos e documentá-los, pois um processo deve ser seguido por todos de maneira correta, por isso a importância de documentar.

Agora não é necessário começar tudo de zero, pois para isso existem metodologias e normas de qualidades e de engenharia de software, onde já define diversos processo e boas práticas. Inclusive, com processos de extração de métricas.

Alguns principais relatórios que existem para controlar a qualidade são os relatórios de Saúde do Projeto, os relatórios de aderência aos processos, as pesquisas de satisfação, etc.

Existem infinitas bibliotecas de métricas que podem ser usadas, da melhor maneira, certamente existirá um calculo que poderá ser útil, para cada situação.

4 COMO AS MÉTRICAS DEVEM SER?

O trabalho de extração de métricas, será utilizado para diversos objetivos, desde servir de apoio para futuros projetos, até saber se será necessário contratar mais recursos para o projeto, ou seja, será usado para tomar decisões importantes. Portanto é necessário que as métricas tenham qualidade.

Como citado anteriormente à importância da se documentar um processo, para que sejam seguido iguais por todos e garantam que os dados gerados tenham um padrão para se extrair métricas disso. Isso seria para se garantir um dos quesitos que uma métrica deve ter, que seria uma fonte confiável.

Também existem outros quesitos para que os números gerados sejam confiáveis e trabalháveis.

As métricas precisam ter algum significado, se extrair métricas que não tenha algum objetivo ou sentido de uso, seria uma perca de tempo, e esforço.

É importante que as métricas contenham uma freqüência, pois de nada serve extrair dados uma só vez. Quando há uma freqüência, se pode verificar uma evolução do objeto que está sendo medido, e saber se estão melhorando, ou se está piorando. Nessa freqüência geralmente é usado o tempo.

As métricas devem ser as mesmas, independente de quem as esteja extraindo, pois isso livra a métrica de alguma influência pessoal ou de algum momento, ou seja, uma pessoa pode achar que esta boa em um momento e em outro achar que está ruim, são diferentes visões, isso faz das métricas menos confiável.

Elas devem possuir evidencias, para sua validação, e ter rastreabilidade, pois será através delas que se localizarão os problemas.

5 ALGUNS EXEMPLOS DE MÉTRICAS

Eu citarei alguns modelos e métricas muito utilizados na área de projetos de tecnologia de informação, que está em diversas metodologias de Engenharia de Software.

Lógico que para medir coisas diferentes, se mede de maneiras diferentes, assim como um trabalho de medir uma substancia liquida se usa litros, uma substancia sólida se usa quilogramas, no nosso caso, temos algumas diferenças também, porém algumas coisas são as mesmas e podem ser medidas da mesma maneira.

Vejamos, um projeto de desenvolvimento possui métricas de prazos, custos, defeitos encontrados, assim como um projeto de suporte, porém em um projeto de suporte, são contados quantos atendimentos foram feitos, e quantos foram resolvidos, também se percebe um contato maior com o cliente também. Percebe-se a diferença de algumas métricas que podem ser extraídas.

Vejamos algumas métricas particulares de cada tipo de projeto:

5.1 DESENVOLVIMENTO

Um projeto de desenvolvimento acontece de uma maneira, onde tem inicio e fim, e a cada tempo que passa o sistema que esta sendo desenvolvido tende a crescer. Nesse caso se faz uma medida pelo tamanho do projeto, que pode ser usado, pontos de função, linhas de códigos, etc. E o controle é feito periodicamente, podendo-se saber o quanto o projeto está crescendo, e se está avançando como foi o planejado. É importante fazer a medida entre o planejado e o que realmente está acontecendo, podendo-se encontrar falhas e dar atenção para os problemas.

Outra medida interessante no caso de um projeto de desenvolvimento, é o índice de remoção de defeitos, pois significa que está sendo encontrados os defeitos, esse índice acompanhado de alguns fatores como causa do defeito, pode-se rastrear onde esta acontecendo um maior número de defeitos, se foi na fase de construção, pode haver algum problema com os programadores, e algum treinamento poderia resolver. Se a causa do problema for à fase de análise, foram os analistas. O importante dessa métrica é que saber dar mais atenção as fases do projeto, e quanto mais tarde se encontrar os defeitos, mais custo se terá para arrumá-los. Por exemplo, se na fase de desenvolvimento se encontrar um defeito que foi causado na fase de analise, o trabalho de mudar tudo, tem um custo, agora se o mesmo defeito for encontrado na fase de testes, esse custo será ainda maior, e assim por diante.

5.2 SUPORTE

Um projeto de suporte ou de manutenção, com eu disse anteriormente, ele tem um contato maior com o cliente, e pode ter uma duração grande, ou até sem data pra terminar. Por isso é importante focar a melhoria no atendimento ao cliente, como a quantidade de problemas solucionados, e até a quantidade de problemas solucionados no prazo em que está em contrato. Existe um acordo que é chamado de SLA – Service Layer Agreement (Acordo de Nível de Serviço) no qual trata um acordo que deve ser comprido, cada vez que aquele serviço é solicitado, é uma maneira de se garantir a qualidade do serviço prestado.

5.3 TESTES

Um projeto de teste possui uma perspectiva diferente de um suporte que é concertar, ou de um projeto de desenvolvimento, que é criar, um projeto de teste tem como perspectiva encontrar defeitos. Nesse caso métricas importantes, são relacionadas a defeitos, causas de defeitos, importância dos defeitos, impacto dos defeitos.

Mas um projeto de teste também pode incluir as remoções desses defeitos, pois parar isso que servem os testes. Podendo-se utilizar métricas parecidas com as de projetos de suporte.

E ainda um índice de Eficiência dos testes.

6 NÍVEL GLOBAL

Para se ter uma visão ampla e clara em um contexto de muitos projetos, ou mesmo de apenas um, é feito um trabalho juntando as métricas, para formar um valor geral, uma média, ou uma escala. Existem diversas maneiras e técnicas de se fazer isso, essa área é muito alinhada com a estatística.

Veremos o Diagrama de Shewart, e como se montar um painel de projetos.

6.1 DIAGRAMAS SHEWHART

Como diz no Livro Qualidade de Software de Koscianski & Soares, Walter Shewhart lecionou e trabalhou com W. E. Deming e é conhecido pelo desenvolvimento do (Controle Estatístico de Qualidade) CEP, que utiliza métodos estatísticos para alcançar o estado de controle de um sistema e para julgar quando este estado foi alcançado.