Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
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 Retport do projeto
ARMAZENAMENTO E ANÁLISE
Armazenar em Na ferramenta Redmine através do Mapa de Medição
Forma de Cálculo (Algoritmo) (Custo Apontado / Custo evolução planejado * 100) - 100
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
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
Origem Dados coletados através da ferramenta Redmine
Como Através do Plano de Qualidade aba Estatística, obter o valor de Bugs e Casos de teste executados
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 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
11
Forma de Cálculo (Algoritmo) Bugs / Casos de teste * 100
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
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
Origem Dados coletados através da ferramenta Redmine
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
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/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.
ARMAZENAMENTO E ANÁLISE
Armazenar em Na ferramenta Redmine através do Mapa de Medição
Forma de Cálculo (Algoritmo) (PF alocados no projeto / PF total disponível) * 100
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
de 80% a 100% registrar e divulgar a equipe
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
Origem Dados coletados através da ferramenta Redmine
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.
Periodicidade (Frequência de coleta)
Na conclusão do projeto
Por quem Gerente de Projetos
DIVULGAÇÃO DE RESULTADOS
Responsável/Para quem/Periodicidade(divulgação)
Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento
ARMAZENAMENTO E ANÁLISE
Armazenar em Na ferramenta Redmine através do Mapa de Medição
Forma de Cálculo (Algoritmo) Quantidade de Erros de Requisitos dividido pela quantidade PF produzida * 100
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
de 0% a 5% registrar e divulgar a equipe
de %5.1% a 10% registrar e reunir com equipe, levantar motivos de variação
acima de 10% 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 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
Periodicidade (Frequência de coleta)
Ao final do projeto
Por quem Gerente de Projetos
DIVULGAÇÃO DE RESULTADOS
Responsável/Para quem/Periodicidade(divulgação)
Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento
ARMAZENAMENTO E ANÁLISE
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
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
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
Origem Dados coletados através da ferramenta Redmine
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.
Periodicidade (Frequência de coleta)
Na conclusão do projeto
Por quem Gerente de Projetos
DIVULGAÇÃO DE RESULTADOS
Responsável/Para quem/Periodicidade(divulgação)
Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento
ARMAZENAMENTO E ANÁLISE
Armazenar em Na ferramenta Redmine através do Mapa de Medição
Forma de Cálculo (Algoritmo) Quantidade de Erros de Configuração dividido pela quantidade de PF produzida * 100
Resultado Esperado (Percentual) Procedimento de Análise (Orientação / Feedback)
de 0% a 5% registrar e divulgar a equipe
de 5.1% a 10% registrar e reunir com equipe, levantar motivos de variação
acima de 10% registrar e reunir com líderes e diretoria, levantar os motivos de variação e estabelecer ações para mitigar a 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.