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

Transcrição

1 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 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 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 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 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 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. 5 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. 6 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 7 Figura 3: Gráfico de Dispersão Fonte: Adaptado de DINSMORE; CAVALIERI, 2009, p 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 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 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 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 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: Código Nome Descrição Objetivo Perguntas Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em Forma de Cálculo (Algoritmo) Resultado Esperado (Percentual) menor que -12% entre -12% e -6% entre -6% e 6% entre 6% e 20% Tabela 1: Tabela de Métricas de Projetos Release MPR1 Percentual de Desvio de Evolução (Previsto x Realizado) Medida que visa apresentar o percentual previsto do projeto comparado com o trabalho realizado Verificar o andamento do projeto O andamento das atividades estão conforme o planejado? COLETA DE DADOS Dados coletados através da ferramenta Redmine Através do percentual de evolução do Gantt Semanalmente conforme previsto no cronograma do projeto Gerente de Projetos DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Toda a equipe do Projeto/Divulgação semanal através do Status Report do projeto ARMAZENAMENTO E ANÁLISE Na ferramenta Redmine através do Mapa de Medição Previsto = total de dias corridos da fase correspondente / total de dias da fase correspondente Realizado = Percentual de evolução da tarefa Resultado = (Realizado - Previsto) Procedimento de Análise (Orientação / Feedback) 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 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 Gerente de Projetos registrar e divulgar resultado a equipe. 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 10 Objetivo: validar a viabilidade do projeto junto a equipe Código Nome Descrição MPR2 Percentual de Desvio do Custo Previsto x Realizado Medida que visa apresentar o custo total gasto comparado com a sua previsão no momento da coleta Objetivo Perguntas Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em Verificar o custo do projeto O custo do projeto está conforme o planejado? COLETA DE DADOS Dados coletados na ferramenta RedMine, Relatório de Custos, disponível no Plano de Projeto Através do Relatório de Custos nas colunas custo de Evolução Planejado e Custo Apontado Semanalmente conforme previsto no cronograma do projeto Gerente de Projetos DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Toda a equipe do Projeto/Divulgação Semanal através do Status Retport do projeto ARMAZENAMENTO E ANÁLISE Na ferramenta Redmine através do Mapa de Medição Forma de Cálculo (Algoritmo) (Custo Apontado / Custo evolução planejado * 100) Resultado Esperado (Percentual) abaixo de 10% de 10.1% a 20% acima de 20% Procedimento de Análise (Orientação / Feedback) registrar e divulgar a equipe registrar e reunir com equipe, levantar motivos de variação 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 Nome Descrição Objetivo Perguntas Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em MPR3 Percentual de Não Conformidades de Processo Medida que visa mensurar o percentual de Não Conformidades (NC) encontradas através das Auditorias de Qualidade Verificar o cumprimento do processo estabelecido Qual o percentual de Não Conformidades (NC) encontradas versus total de itens verificados? COLETA DE DADOS Dados coletados através da ferramenta Redmine Através do Plano de Qualidade aba Estatística, obter o valor de Bugs e Casos de teste executados Semanalmente conforme previsto no cronograma do projeto Gerente de Projetos DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Toda equipe do Projeto/Divulgação Semanal através do Status Report do projeto ARMAZENAMENTO E ANÁLISE Na ferramenta Redmine através do Mapa de Medição

11 11 Forma de Cálculo (Algoritmo) Bugs / Casos de teste * 100 Resultado Esperado (Percentual) de 0% a 10% de 10.1% a 30% acima de 30% Código Nome Descrição Objetivo Perguntas Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em Procedimento de Análise (Orientação / Feedback) registrar e divulgar a equipe abrir tarefa problema ao projeto para análise das NC relatadas junto ao Analista de Qualidade 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 MPR4 Disponibilidade e Alocação no Projeto Medida que visa mensurar a quantidade de pontos de função alocados no projeto e disponíveis para alocação Verificar a alocação e disponibilidade da equipe do projeto Quantos pontos de função são possíveis de serem alocados na equipe do projeto? COLETA DE DADOS Dados coletados através da ferramenta Redmine 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 Semanalmente conforme previsto no cronograma do projeto Gerente de Projetos DIVULGAÇÃO DE RESULTADOS 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 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) de 80% a 100% abaixo de 80% Procedimento de Análise (Orientação / Feedback) registrar e divulgar a equipe 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 Nome Descrição Objetivo Perguntas Origem MPR5 Percentual de problemas de Requisitos / Pontos de Função Medida que visa mensurar a qualidade dos Requisitos do produto através da quantidade de erros encontrados na Fase de Construção Verificar a qualidade dos Requisitos na construção Qual percentual de problemas de requisitos do produto por ponto de função? COLETA DE DADOS Dados coletados através da ferramenta Redmine

12 12 Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em Forma de Cálculo (Algoritmo) Resultado Esperado (Percentual) de 0% a 5% de %5.1% a 10% acima de 10% 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 DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento ARMAZENAMENTO E ANÁLISE Na ferramenta Redmine através do Mapa de Medição Quantidade de Erros de Requisitos dividido pela quantidade PF produzida * 100 Procedimento de Análise (Orientação / Feedback) registrar e divulgar a equipe registrar e reunir com equipe, levantar motivos de variação 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 Nome Descrição Objetivo Perguntas Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em MPR6 Medidas fora do resultado esperado Medida que visa mensurar se os resultados esperados estão sendo alcançados Verificar a assertividade das medidas Quantas medidas estão fora do resultado esperado? COLETA DE DADOS Dados coletados no Redmine através do Mapa de Medição Através da contagem das medidas fora do resultado esperado no mapa de medição X total de medidas Ao final do projeto Gerente de Projetos DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento ARMAZENAMENTO E ANÁLISE 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) de 0% a 20% acima de 20% Procedimento de Análise (Orientação / Feedback) registrar e divulgar com SEPG solicitar reunião com SEPG para rever as expectativas de todas as medidas. Código Nome Descrição Objetivo Perguntas MPR7 Percentual problemas de Configuração / Pontos de Função Medida que visa mensurar a qualidade/assertividade através da quantidade de erros encontrados de configuração Verificar a qualidade do trabalho na construção Qual o percentual de erros reportados sobre configuração por ponto de função?

13 13 Origem Como Periodicidade (Frequência de coleta) Por quem Responsável/Para quem/periodicidade(divulgação) Armazenar em Forma de Cálculo (Algoritmo) Resultado Esperado (Percentual) de 0% a 5% de 5.1% a 10% acima de 10% COLETA DE DADOS Dados coletados através da ferramenta Redmine 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 Gerente de Projetos DIVULGAÇÃO DE RESULTADOS Gerente de Projetos/Equipe do Projeto/Ao final do projeto na Reunião de Encerramento ARMAZENAMENTO E ANÁLISE Na ferramenta Redmine através do Mapa de Medição Quantidade de Erros de Configuração dividido pela quantidade de PF produzida * 100 Procedimento de Análise (Orientação / Feedback) registrar e divulgar a equipe registrar e reunir com equipe, levantar motivos de variação 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, 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: MPR1 Tabela 2: Lista de Medidas Coletadas - Projeto PROJETO Código Nome Resultado Esperado Percentual de Desvio de Evolução Previsto x Realizado por Núcleo entre -6% e 6% Cálculo Resultado Obtido Coleta Ações geradas 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 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$ ,43 MPR3 Percentual de Não Conformidades de Processo entre 0% e 10% -19,5% #49745 Projeto com variação de custo positiva de 19,5% 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 14

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: % #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% 15 3% #49730 Conforme resultado final apresentado, registrar e divulgar.

16 16 Problemas: 4 Pontos de Função: 133 MPR6 Medidas Fora do Resultado esperado: 16 Total de Medidas: 17 MPR 7 Problemas: 0 Pontos de Função: ANÁLISE DOS DADOS Medidas fora do resultado esperado Percentual problemas de Configuração / Pontos de Função entre 0% e 20% entre 0% e 5% Fonte: Dados da pesquisa, % #49730 Previsto ocorrer nova consolidação de medidas de projetos no qual os valores do resultado esperado deverão ser reavaliados 0% #49730 Conforme resultado final apresentado, registrar e divulgar. 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 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. 18 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, 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, PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional; tradução Ariovaldo Griesi ; 7. ed. Porto Alegre: Bookman, PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books, SAMPIERI, Roberto; COLLADO, Carlos; LUCIO, María. Metodologia de pesquisa. 5º ed. São Paulo: Mc Graw Hill, SOMMERVILLE, Ian. Engenharia de Software. 9º ed. São Paulo: Pearson Education, TOZONI-REIS, Marília F. C. Metodologia da pesquisa. 2.ed. Curitiba: IESDE, 2010.