Instituto de Educação Tecnológica Pós-graduação em ... · Segundo Pressman (1995), na maioria dos empreendimentos técnicos, como os projetos de software, as medições e as

Instituto de Educação Tecnológica

Pós-graduação em Engenharia de Software – Turma 06

Outubro / 2014

Estudo de indicadores como apoio à análise de desempenho em projetos de

Software

Fábio Leandro Pio

Flávio Teixeira Nascimento

Leonardo Silva Barbosa

RESUMO

Este artigo apresenta uma pesquisa exploratória sobre indicadores e análise de

desempenho, bem como a importância de se medir e coletar informações em projetos de

software. Por meio de um estudo de caso de uma empresa de software de Belo Horizonte

são analisados o seu processo de medição bem como as métricas utilizadas,

demonstrando assim a importância das análises de indicadores e métricas para uma

empresa do mundo real, onde tais ações apoiam fortemente como suporte ao modelo de

qualidade aderido pela empresa analisada.

Palavras-chave: Medição de projetos, análise de desempenho de projetos de software,

métricas de projetos de software, indicadores de desempenho de projetos.

1. INTRODUÇÃO

Para Dinsmore e Neto (2012), a execução de qualquer projeto requer controle. Não

basta um bom planejamento para que ele seja bem executado, é necessário a existência

2

de informações que permitam ao gerente de projeto e a equipe de desenvolvimento

manterem sob controle o andamento e a execução daquilo que foi planejado.

Dinsmore e Cavalieri (2009) complementam que na busca por aumentar a

qualidade de software, a área de Engenharia de Software tem produzido ferramentas para

auxílio ao desenvolvimento, assim como tem estudado e produzido formas de controlar o

processo de desenvolvimento e de utilização de indicadores na análise de desempenho

de projetos. Embasado na importância de se compreender as práticas da adoção de

técnicas de controle e gerenciamento de projetos por meio da medição e análise de

indicadores, neste estudo serão abordadas situações em que o uso de indicadores

numéricos reflita o desempenho e mostre um conjunto de análises através dos quais o

gerente e a equipe de desenvolvimento possam, a qualquer tempo, criar novos

indicadores com o intuito de revelar a atual situação do projeto, além de proporcionar a

melhoria continuada do processo.

O estudo está apresentado em tópicos, onde serão elucidados nas páginas seguir,

os conceitos considerados importantes a cerca do tema sugerido, numa abordagem

generalizada, com o objetivo de investigar práticas de coleta de indicadores e criação de

métricas que possam apoiar a gestão de projetos na análise de desempenho dos projetos

de desenvolvimento de software.

2. METODOLOGIA

Segundo Sampieri, Collado e Lucio (2013), os estudos exploratórios servem para

nos tornar mais familiarizados com determinado assunto ou problema, e na maioria das

vezes, são realizados quando o tema ou problema de pesquisa ainda não são altamente

explorados ou conhecidos.

Assim, o estudo em questão, foi desenvolvido com base em uma pesquisa

exploratória com a finalidade de oferecer maior intimidade com o tema e problema

expostos, possibilitando a realização de levantamento bibliográfico, análise de dados e

revisões de diversas fontes de informação a cerca da temática proposta.

Para Tozoni-Reis (2010), a pesquisa qualitativa dá uma abordagem interpretativa

aos itens estudados, superando a abordagem descritiva mais comum entre as pesquisas

qualitativas e experimentais. Tal definição fomentou o interesse em abordar neste estudo

tal perspectiva da pesquisa de nível mais interpretativo, caracterizando a como uma

pesquisa qualitativa.

3

Como parte integrante e complementar deste estudo, busca-se evidenciar os itens

aqui estudados por meio de um estudo de caso, realizado através de informações a cerca

dos processos de medição e controle de uma empresa do ramo de tecnologia da

informação, desenvolvedora de Software na cidade de Belo Horizonte.

3. REFERÊNCIAL TEÓRICO

3.1 A importância de se medir e coletar informações

Segundo Pressman (1995), na maioria dos empreendimentos técnicos, como os

projetos de software, as medições e as métricas ajudam a entender o processo técnico

usado para se desenvolver um produto, como também o próprio produto. O processo é

medido num esforço para melhora-lo, assim como o produto também é medido com tal

finalidade.

Dinsmore e Cavalieri (2009) discorrem que os projetos permeiam todas as

organizações, pois são instrumentos fundamentais para qualquer atividade de mudança e

geração de produtos e serviços. Projetos podem envolver desde uma única pessoa a

milhares e podem ter a duração de alguns dias ou vários anos. Um projeto é um

empreendimento único, com início e fim determinados, que utiliza recursos e é conduzido

por pessoas, visando atingir objetivos predefinidos.

Para Dinsmore e Neto (2012), a execução de qualquer projeto requer

acompanhamento. Não basta um bom planejamento para que ele seja bem executado, é

necessário a existência de informações que permitam ao gerente de projeto e a equipe de

desenvolvimento manterem sob controle o andamento e a execução daquilo que foi

planejado. O registro de todos os passos executados enriquece o histórico para uso em

futuros projetos.

3.1.1 O que medir

Pressman (1995) discorre que entre as medidas diretas do processo de engenharia

de software incluem-se o custo e os esforços aplicados. Em suma, as medidas diretas do

produto incluem as linhas de código produzidas, velocidade de execução, tamanho da

memória e defeitos registrados ao longo de certo espaço de tempo. As medidas indiretas

do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade,

manutenibilidade, etc.

4

Segundo Dinsmore e Neto (2012), as informações sobre serviços em execução

(dados reais) são comparadas com do planejamento (dados previstos), e também com

padrões existentes e reconhecidos. Apoiados também num plano de contingência,

desenhado a partir de um bom gerenciamento de riscos elaborado durante o

planejamento do projeto. Assim, é possível gerar alternativas para análise e decisão sobre

ações corretivas que já se façam necessárias.

3.1.2 Definição de métricas

Para Sommerville (2011), as métricas de software podem ser métricas de controle

ou métricas de previsão. Onde as primeiras suportam os processos de gerenciamento e

as outras ajudam a prever características do software. As métricas de controle e de

previsão podem influenciar a tomada de decisão de gerenciamento (ver Figura 1:

Medições de previsão e de controle).

Figura 1: Medições de previsão e de controle Fonte: SOMMERVILLE, 2011, p. 466.

Métricas de Software: Segundo Sommerville (2011), os gerentes usam métricas

de processo para decidir se devem ser feitas alterações no processo, enquanto as

métricas de previsão são usadas para ajudar a estimar o esforço necessário para fazer

alterações no software.

Pressman (2011) complementa ainda que um engenheiro de software coleta

medidas e desenvolve métricas para obter indicadores. Um indicador é uma métrica ou

combinação de métricas que proporcionam informações sobre o processo de software,

em um projeto de software ou no próprio produto. Segundo Sommerville (2011), existem

duas maneiras para uso das medições de um software de sistema:

5

Para atribuir um valor aos atributos de qualidade do sistema: Ao medir as

características dos componentes de sistema, bem como sua complexidade

ciclomática e, em seguida agregar essas informações, é possível avaliar os

atributos de qualidade do sistema, como a manutenibilidade.

Para identificar os componentes de sistema cuja qualidade não atinja o padrão: As

medições podem identificar componentes individuais com características que se

desviem das normas. Como por exemplo, medir componentes para descobrir

aqueles com mais alta complexidade, estes seriam mais passíveis de conter bugs.

Métricas do Produto: Segundo Sommerville (2011), as métricas de produto são

métricas de previsão usadas para medir atributos internos de um sistema de software. O

tamanho do sistema, medido em linhas de código, ou o número de métodos associados a

cada classe de objeto são exemplos de métricas de produto. As métricas de produto se

dividem em duas classes:

Métricas dinâmicas: As quais são coletadas por meio de medições efetuadas de

um programa em execução. Estas métricas podem ser coletadas através do teste

de sistema ou após o sistema estar em uso. Por exemplo, o número de relatórios

de bugs ou o tempo necessário para concluir uma tarefa de desenvolvimento.

Métricas estáticas: São coletadas por meio de medições feitas de representações

do sistema, como o projeto. Por exemplo: Tamanho do código e comprimento

médio de identificadores usados.

Ainda segundo Sommerville (2011), esses tipos de métricas estão relacionados com

diferentes atributos de qualidade. Métricas dinâmicas ajudam a avaliar a eficiência e

confiabilidade de um programa. Métricas estáticas ajudam a avaliar a complexidade,

compreensibilidade e manutenibilidade de um sistema ou componentes de um sistema de

software.

3.2 Exposição dos resultados

O controle da qualidade abrange um conjunto de métodos e atividades adotados

com o objetivo de melhoria e manutenção da qualidade. No ambiente de projetos,

controlar a qualidade significa, na prática, o monitoramento dos resultados específicos do

projeto a fim de determinar se eles satisfazem os padrões relevantes de qualidade.

(Dinsmore e Cavalieri, 2009).

6

O controle da qualidade deve ser realizado durante todo o projeto, fazendo-se

fundamental o auxílio por ferramentas de qualidade. Para um controle adequado é

desejável utilizar técnicas largamente utilizadas, cujo domínio é fundamental para

avaliação e análise dos resultados obtidos. A seguir algumas das mais conhecidas formas

de apresentação de dados:

Diagrama de Pareto: Consiste em um gráfico de barras, onde os dados são

exibidos geralmente em ordem decrescente de importância. Mostra ainda a curva

de percentagens acumuladas. Esta disposição facilita a identificação das regiões

mais significativas, nas quais os esforços do processo decisório devem se

concentrar prioritariamente. Por meio da análise de Pareto, um gerente de projeto

pode, por exemplo, identificar a concentração de maior influência em relação às

causas potenciais de um problema.

Figura 2: Diagrama de Pareto Fonte: Adaptado de DINSMORE; CAVALIERI, 2009, p. 147

Gráfico de Dispersão: Utilizado para visualização do tipo de relacionamento

existente entre os valores correspondentes a uma série de duas variáveis, plotando

as mesmas em um eixo XY, no sentido de prover a correlação entre elas. Esses

valores podem, por exemplo, ser relativos a duas causas de um processo, uma

causa e um efeito ou dos efeitos do processo, onde é possível determinar se uma

variável afeta a outra e observar a sua intensidade. Os gráficos de dispersão são

muito utilizados para a análise de tendências.

7

Figura 3: Gráfico de Dispersão Fonte: Adaptado de DINSMORE; CAVALIERI, 2009, p. 150.

Diagrama de Ishikawa (Espinha de Peixe ou Causa e Efeito): Apresenta um

efeito principal associado graficamente às suas potenciais causas. As causas

situam-se à esquerda do efeito, podendo ainda ser subdivididas em subcausas

(secundárias e terciárias), conforme a complexidade da situação em estudo. Um

exemplo da sua utilização seria a exibição das causas e subcausas associadas a

um risco potencial, para facilitar ao gerente de projeto o entendimento do

relacionamento existente entre estes, na elaboração de um plano de contingências.

Figura 4: Diagrama de Ishikawa Fonte: Adaptado de DINSMORE; CAVALIERI, 2009, p. 149.

Lista de Verificação (Checklist ou Tabelas de Dados): Contém uma relação

de itens a serem verificados, coletados e/ou exibidos, sendo geralmente

utilizados para inspeções, avaliações, etc. Podem assumir tanto o formato de

uma lista, quanto de uma figura ou tabela de dados, podendo ainda conter

espaço para anotações, cálculos, marcações, etc., dependendo da necessidade

de sua utilização. Proporcionam uma abordagem efetiva e simples para

8

obtenção, organização e exibição de dados para análise e revisões. Um

exemplo da sua utilização seria uma lista de itens a serem avaliados durante a

aceitação dos produtos entregues em uma determinada fase do projeto.

4. ESTUDO DE CASO

4.1. Caracterização da empresa

Empresa sediada em Belo Horizonte, atuante no segmento de desenvolvimento de

softwares voltados para Gestão em Rental (Mercado de locações de equipamentos) há

mais de 20 anos. Possui atualmente em sua carteira mais de 350 clientes presentes em

todos os estados brasileiros, representando cerca de 3500 usuários do sistema que

fornece.

No que se refere ao seu PDS (Processo de Desenvolvimento de Softwares), possui

certificação nível F no modelo MPSBr (Melhoria de Processo do Software Brasileiro), o

que significa que atende ao processo de “Medição” requerido para o nível e, desta forma,

possui informações relevantes para o estudo de caso. Possui, em seu quadro atual, cerca

de setenta funcionários, onde vinte e cinco destes atuam no departamento denominado

Fábrica e participam dos projetos seguindo o referido modelo MPSBr, participando

portanto das medições realizadas.

4.2. Processo de desenvolvimento de software da empresa

A empresa trabalha com customizações de seu sistema para atender às

necessidades específicas de seus clientes. Para entrega das customizações, são

recebidas solicitações chamadas de demandas. Antes de fazer parte do PDS, as

demandas de customizações do sistema são recebidas por meio de um registro no

sistema de tickets o qual todos os clientes têm uma conta de acesso.

A partir do registro o analista de requisitos recebe a solicitação e realiza um

detalhamento da demanda, gerando a primeira documentação referente a uma possível

solução, bem como uma estimativa de esforço contabilizada por meio da técnica de

Pontos de Função. Esta documentação é enviada à equipe de arquitetos de software que

ficam responsáveis por aprovar tecnicamente a solução (analisar a viabilidade técnica da

solução). Se necessário, revisões da documentação são realizadas pelos analistas de

requisitos enquanto não existir uma aprovação técnica. Dois tipos de projetos fazem parte

do PDS da empresa: Projetos Release e Projetos de Versão:

9

Projetos Release: São projetos com duração média de um mês, cuja entrega

representa uma lista de demandas desenvolvidas que podem ser

disponibilizadas somente aos clientes que solicitaram a customização.

Projetos de Versão: Representa um projeto executado a cada seis meses com

duração média de um mês com o objetivo de integrar todas as demandas que

serão efetivamente incorporadas ao produto.

Neste estudo de caso, serão verificados dados referentes aos Projetos Release.

4.3. Dados de medição dos projetos

Com relação ao uso de métricas a empresa utiliza em seu PDS uma “Lista de

Verificação”, cujas informações mais relevantes são apresentadas na tabela a seguir:

Tabela 1: Tabela de Métricas de Projetos Release

Código MPR1

Nome Percentual de Desvio de Evolução (Previsto x Realizado)

Descrição Medida que visa apresentar o percentual previsto do projeto comparado com o trabalho realizado

Objetivo Verificar o andamento do projeto

Perguntas O andamento das atividades estão conforme o planejado?

COLETA DE DADOS

Origem Dados coletados através da ferramenta Redmine

Como Através do percentual de evolução do Gantt

Periodicidade (Frequência de coleta)

Semanalmente conforme previsto no cronograma do projeto

Por quem Gerente de Projetos

DIVULGAÇÃO DE RESULTADOS

Responsável/Para quem/Periodicidade(divulgação)

Gerente de Projetos/Toda a equipe do Projeto/Divulgação semanal através do Status Report do projeto

ARMAZENAMENTO E ANÁLISE

Armazenar em Na ferramenta Redmine através do Mapa de Medição

Forma de Cálculo (Algoritmo)

Previsto = total de dias corridos da fase correspondente / total de dias da fase correspondente Realizado = Percentual de evolução da tarefa Resultado = (Realizado - Previsto)

Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)

menor que -12% Gerente de Projetos realizar Análise de Viabilidade do projeto, após, realizar reunião com equipe do projeto. Objetivo: validar a viabilidade do projeto junto a equipe

entre -12% e -6% Gerente de Projetos realizar reunião com equipe do projeto. Objetivo: verificar situação do projeto e definir ações, em caso de atraso será necessário a realização de horas extras a equipe do projeto

entre -6% e 6% Gerente de Projetos registrar e divulgar resultado a equipe.

entre 6% e 20% Gerente de Projetos realizar reunião com equipe do projeto. Objetivo: verificar situação do projeto e definir ações.

maior que 20% Gerente de Projetos verificar com o CPROD a possibilidade de aumento de escopo do projeto após realizar reunião com equipe do projeto.

10

Objetivo: validar a viabilidade do projeto junto a equipe

Código MPR2

Nome Percentual de Desvio do Custo Previsto x Realizado

Descrição Medida que visa apresentar o custo total gasto comparado com a sua previsão no momento da coleta

Objetivo Verificar o custo do projeto

Perguntas O custo do projeto está conforme o planejado?

COLETA DE DADOS

Origem Dados coletados na ferramenta RedMine, Relatório de Custos, disponível no Plano de Projeto

Como Através do Relatório de Custos nas colunas custo de Evolução Planejado e Custo Apontado






Gerente de Projetos/Toda a equipe do Projeto/Divulgação Semanal através do Status Retport do projeto



Forma de Cálculo (Algoritmo) (Custo Apontado / Custo evolução planejado * 100) - 100


abaixo de 10% registrar e divulgar a equipe

de 10.1% a 20% registrar e reunir com equipe, levantar motivos de variação

acima de 20% registrar e reunir com líderes e diretoria, levantar os motivos de variação e estabelecer ações para mitigar a variação

Código MPR3

Nome Percentual de Não Conformidades de Processo

Descrição Medida que visa mensurar o percentual de Não Conformidades (NC) encontradas através das Auditorias de Qualidade

Objetivo Verificar o cumprimento do processo estabelecido

Perguntas Qual o percentual de Não Conformidades (NC) encontradas versus total de itens verificados?

COLETA DE DADOS


Como Através do Plano de Qualidade aba Estatística, obter o valor de Bugs e Casos de teste executados






Gerente de Projetos/Toda equipe do Projeto/Divulgação Semanal através do Status Report do projeto



11

Forma de Cálculo (Algoritmo) Bugs / Casos de teste * 100


de 0% a 10% registrar e divulgar a equipe

de 10.1% a 30% abrir tarefa problema ao projeto para análise das NC relatadas junto ao Analista de Qualidade

acima de 30% Abrir tarefa problema ao projeto para análise das NC relatadas junto ao Analista de Qualidade. Realizar comunicação a equipe do projeto apresentando o grande número de NC relatadas

Código MPR4

Nome Disponibilidade e Alocação no Projeto

Descrição Medida que visa mensurar a quantidade de pontos de função alocados no projeto e disponíveis para alocação

Objetivo Verificar a alocação e disponibilidade da equipe do projeto

Perguntas Quantos pontos de função são possíveis de serem alocados na equipe do projeto?

COLETA DE DADOS


Como

Colher a informação registrada na Solicitação de Projeto sobre a disponibilidade de desenvolvimento dos Pontos de Função. Colher a quantidade de Pontos de Função alocada ao Projeto através da página de Configuração






Gerente de Projetos/Equipe do Projeto/Após planejamento do projeto, através da tarefa de comunicação, posteriormente divulgação semanal através do Status Report do projeto.



Forma de Cálculo (Algoritmo) (PF alocados no projeto / PF total disponível) * 100



abaixo de 80% solicitar reunião com CPROD para solicitar SM para o projeto. Gerente de Projetos avaliar se existem problemas que impedem a alocação de novas demandas

Código MPR5

Nome Percentual de problemas de Requisitos / Pontos de Função

Descrição Medida que visa mensurar a qualidade dos Requisitos do produto através da quantidade de erros encontrados na Fase de Construção

Objetivo Verificar a qualidade dos Requisitos na construção

Perguntas Qual percentual de problemas de requisitos do produto por ponto de função?

COLETA DE DADOS


12

Como

Na ferramenta Redmine utilizar o Filtro "Erros de Requisitos" (composto por: Situação: "Todos", Tipo igual a "problema", Encontrado por: diferente de "Auditoria" e "Configuração", Responsável área: "CPROD/Requisito". Considerar o total de PF do projeto contido na última versão da PQH.


Na conclusão do projeto




Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento



Forma de Cálculo (Algoritmo) Quantidade de Erros de Requisitos dividido pela quantidade PF produzida * 100



de %5.1% a 10% registrar e reunir com equipe, levantar motivos de variação


Código MPR6

Nome Medidas fora do resultado esperado

Descrição Medida que visa mensurar se os resultados esperados estão sendo alcançados

Objetivo Verificar a assertividade das medidas

Perguntas Quantas medidas estão fora do resultado esperado?

COLETA DE DADOS

Origem Dados coletados no Redmine através do Mapa de Medição

Como Através da contagem das medidas fora do resultado esperado no mapa de medição X total de medidas


Ao final do projeto






Armazenar em Na ferramenta Redmine através do mapa de medição

Forma de Cálculo (Algoritmo) Quantidade de medidas fora do resultado esperado / medidas totais * 100


de 0% a 20% registrar e divulgar com SEPG

acima de 20% solicitar reunião com SEPG para rever as expectativas de todas as medidas.

Código MPR7

Nome Percentual problemas de Configuração / Pontos de Função

Descrição Medida que visa mensurar a qualidade/assertividade através da quantidade de erros encontrados de configuração

Objetivo Verificar a qualidade do trabalho na construção

Perguntas Qual o percentual de erros reportados sobre configuração por ponto de função?

13

COLETA DE DADOS


Como

Na ferramenta Redmine, utilizar o filtro "Erros de Configuração" (composto por: Situação: "Todos", Tipo igual a "Problema", Encontrado por: diferente de "Auditoria" e "Configuração", Responsável área: "Configuração". Considerar o total de PF do projeto contido na última versão da PQH.


Na conclusão do projeto







Forma de Cálculo (Algoritmo) Quantidade de Erros de Configuração dividido pela quantidade de PF produzida * 100



de 5.1% a 10% registrar e reunir com equipe, levantar motivos de variação


Fonte: Dados da pesquisa, 2014.

Com relação às medições efetivamente realizadas em projetos, para análise dos

dados, são apresentados abaixo dados coletados de um dos Projetos Release da

empresa:

Tabela 2: Lista de Medidas Coletadas - Projeto 14.10

PROJETO 14.10

Código Nome Resultado Esperado

Cálculo Resultado Obtido

Coleta Ações geradas

MPR1 Percentual de Desvio de Evolução Previsto x Realizado

por Núcleo

entre -6% e 6%

11% #49738 Projeto adiantado em 11%

Previsto: 16% 18% #49740 Projeto adiantado em 18%

Realizado: 27% 24% #49745 Projeto adiantado em 24%

Previsto: 37%

Realizado: 55%

Previsto: 59%

Realizado: 83%

14 MPR2 Percentual de

Desvio do Custo Previsto x Realizado

entre 0% e 10%

-19% #49738 Projeto com variação de custo positiva de 19%. Algumas atividades de processo não foram realizadas até o momento o que contribui para o desvio

Custo apontado: R$ 2.707,25 -15% #49740 Projeto com variação de custo positiva de 15%

Custo Evolução Planejado: R$ 3.352, 79

-19,5% #49745 Projeto com variação de custo positiva de 19,5%

Custo apontado: R$ 5.756,72

Custo Evolução Planejado: R$ 6.815,31

Custo apontado: R$ 9.360,07

Custo Evolução Planejado: R$ 11.629,43

MPR3 Percentual de Não Conformidades de

Processo

entre 0% e 10%

35% #49738 Conforme resultado apresentado foi aberta a tarefa problema #50336 para análise e ações.

Bugs: 7 31% #49740 Conforme resultado apresentado foi aberta a tarefa problema #50336, na última auditoria realizada foram verificados 6 itens, sendo registrado 1 Não Conformidade

15 Total de itens verificados: 20 20% #49745 Conforme

resultado apresentado foi aberta a tarefa problema #50336, na última auditoria realizada foram verificados 14 itens, sem registro de Não Conformidades

Bugs: 8

Total de itens verificados: 26

Bugs: 8

Total de itens verificados: 40

MPR4 Disponibilidade e Alocação no Projeto

entre 80% e 100%

58% #49694 Será solicitado ao CPROD alocação de escopo ao projeto

PF alocados: 99 58% #49738 Será solicitado ao CPROD alocação de escopo ao projeto

PF disponíveis: 170 64% #49740 Conforme resultado apresentado será solicitado ao CPROD adição de escopo ao projeto.

PF alocados: 99 78% #49745 Não será solicitado adição de escopo ao projeto devido conclusão da fase nesta data.

PF disponíveis: 170

PF alocados: 109

PF disponíveis: 170

PF alocados: 133

Disponíveis: 170

MPR5 Percentual de problemas de Requisitos / Ponto de Função

entre 0% e 5%

3% #49730 Conforme resultado final apresentado, registrar e divulgar.

16 Problemas: 4

Pontos de Função: 133

MPR6 Medidas fora do resultado esperado

entre 0% e 20%

94% #49730 Previsto ocorrer nova consolidação de medidas de projetos no qual os valores do resultado esperado deverão ser reavaliados

Medidas Fora do Resultado esperado: 16

Total de Medidas: 17

MPR 7 Percentual problemas de Configuração / Pontos de Função

entre 0% e 5%

0% #49730 Conforme resultado final apresentado, registrar e divulgar.

Problemas: 0

Pontos de Função: 133

Fonte: Dados da pesquisa, 2014.

5. ANÁLISE DOS DADOS

Como pôde ser exemplificado através do estudo de caso apresentado, o

acompanhamento do projeto é um dos itens mais importantes no tocante ao PDS. Fica

clara a importância de que a execução de qualquer projeto seja seguida do

acompanhamento, uma vez que não basta um bom planejamento para que ele seja bem

executado, é necessário a existência de informações que permitam ao gerente de projeto

e a equipe de desenvolvimento manterem sob controle o andamento e a execução

daquilo que foi planejado.

Tal contexto foi elucidado por Dinsmore e Neto (2012) e que muito fez sentido na

observação dos dados coletados para este estudo de caso, considerando ainda que são

fatores primordiais para a correta utilização do modelo de maturidade assumido pela

empresa em questão (MPS.Br - F).

A empresa optou por utilizar uma “Lista de Verificação” como formato de exposição

dos resultados dos indicadores coletados em seus projetos. Como descrevem Dinsmore e

Cavalieri (2009), a Lista de Verificação, Checklist ou “Tabela de Dados” contém uma

relação de itens a serem verificados, coletados e/ou exibidos, que podem assumir tanto o

formato de uma lista, quanto de uma figura ou tabela de dados. Proporcionam uma

abordagem efetiva e simples para obtenção, organização e exibição de dados para

análise e revisões. Neste caso, os dados são obtidos em várias fases do projeto da

empresa, seja durante o planejamento, construção ou na fase conclusão.

17

Observa-se também que as informações sobre projetos em execução (resultados

obtidos) são comparadas com do planejamento (resultados esperados), sempre apoiados

por um plano de contingência, desenhado a partir de um gerenciamento de riscos

elaborado durante o planejamento do projeto.

Sobre as métricas de software, analisa-se que são coletados indicadores com

relação à qualidade do produto desenvolvido, demonstrando a preocupação com relação

ao índice de bugs e não conformidades encontradas durante a release de

desenvolvimento do produto. Tais abordagens vão de encontro com o proposto por

Sommerville (2011) na defesa de que as coletas de métricas do software colaboram para

apontar um valor aos atributos de qualidade do sistema ou ainda para identificar os

componentes de sistema cuja qualidade não atinja o padrão esperado, fazendo então

necessário a tomada de ações corretivas.

6. CONSIDERAÇÕES FINAIS

Projetos de software em geral, são motivados pela proposta de se atender

necessidades específicas, a maioria de ideias que refletem um contexto que satisfaz os

problemas do mundo real.

Para tanto, a necessidade de se medir surge como um guia que permite a

informação quantificada do que tem sido desenvolvido, tanto em níveis de processo

quanto a níveis de qualidade investidos. Saber em que estado às coisas se apresentam e

se o caminho escolhido tem sido o correto, são aspectos básicos de qualquer

gerenciamento.

Através deste, evidencia-se que é possível começar a entender a dimensão dos

problemas e a evolução das necessidades utilizando métricas pouco sofisticadas, mas à

medida que a maturidade e o entendimento aumentam, novas formas e mais detalhadas

de medir as características dos atributos envolvidos se tornam possíveis e até mesmo

necessárias. Algumas ferramentas e técnicas como as citadas neste estudo podem

contribuir para a análise de indicadores como fonte de informação para os projetos de

software.

Em geral, quando avaliadas do ponto de vista individual podem ser úteis para

encontrar tendências e prever comportamentos futuros. Porém, analisadas em conjunto,

as métricas podem prover uma representação mais precisa do mundo real onde o

contexto geral do projeto pode ser deslumbrado. Quanto mais precisas, melhores serão

como fontes para uma boa tomada de decisão.

18

O estudo de caso apresentado ilustra a aplicação e a importância das análises de

indicadores e métricas para uma empresa do mundo real onde tais ações apoiam

fortemente como suporte ao modelo de qualidade aderido pela empresa analisada. São

deixadas, como proposta de estudos posteriores, a análise de indicadores e métricas de

softwares em outras empresas, para que seja traçado um comparativo das abordagens

elencando aquelas práticas mais utilizadas e que melhor visibilidade oferecem no

contexto de gestão de projetos de software.

REFERÊNCIAS BIBLIOGRÁFICAS

DINSMORE, Paul C.; CAVALIERI Adriane. Como se tornar um profissional em gerenciamento de projetos: livro-base de “Preparação para Certificação PMP© - Project Management Professional”. 3. ed. Rio de Janeiro: Qualitymark, 2009. DINSMORE, Paul C.; NETO, Fernando H. S. Gerenciamento de Projetos: Como gerenciar seu projeto com qualidade, dentro do prazo e custos previstos.1.ed. Rio de Janeiro: Qualitymark, 2012. PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional; tradução Ariovaldo Griesi ; 7. ed. Porto Alegre: Bookman, 2011. PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books, 1995. SAMPIERI, Roberto; COLLADO, Carlos; LUCIO, María. Metodologia de pesquisa. 5º ed. São Paulo: Mc Graw Hill, 2013. SOMMERVILLE, Ian. Engenharia de Software. 9º ed. São Paulo: Pearson Education, 2011. TOZONI-REIS, Marília F. C. Metodologia da pesquisa. 2.ed. Curitiba: IESDE, 2010.

Documents

Instituto de Educação Tecnológica Pós-graduação em ... · Segundo Pressman (1995), na maioria dos empreendimentos técnicos, como os projetos de software, as medições e as