Pesquisa da Maturidade das Boas Práticas de Estimativas e Métricas em Organizações Paraenses

Fábio L. Figueiredo1, Luiz O. Barata1

1Especialização em Gerência de Projetos de Software – Instituto de Ciências Exatas Universidade Federal Pará (UFPa)

Caixa Postal 66075 – 110 – Belém – PA – Brasil

fabiolima.net@gmail.com, luiz.ufpa@gmail.com

Resumo. Este trabalho consiste em elaborar uma pesquisa da maturidade de boas práticas de estimativas e métricas em organizações paraenses, visando também citar algumas ferramentas e metodologias que visam auxiliar na melhoria do uso de medições e favorecer à possíveis estimativas. É importante ressaltar que para a realização da pesquisa foi elaborado um questionário baseado nos resultados esperados do modelo MPS.BR, no que tange estimativas e métricas.

Abstract. The meaning of this work is to make a research about the maturity of good estimates and metrics in Paraenses organizations but also to offer some tools and methodologies to help the improvement the use of measurements and encourage possible estimates. It is important to emphasize that to conduct the study a questionnaire was developed based on expected results of the model MPS.BR in regard estimates and metrics.

1. Introdução

1.1. Contexto do Trabalho

Segundo Kaplan (KAPLAN, 2004 apud OLIVEIRA, 2005), o que não se pode medir, não se pode gerenciar. A frase traduz a necessidade, cada vez maior, que os atuais gestores têm de se servir de metodologias e indicadores que lhes permitam estabelecer objetivos, monitorar os resultados e verificar, de forma objetiva, como essas metas propostas foram atingidas.

Deste modo, o presente trabalho tem como objetivo apresentar a importância do uso de estimativas e métricas dentro da gestão de gerência de projetos de software, enfatizando a diferença entre medição e estimativa assim como os resultados esperados dentro do modelo MPS.Br (Melhoria de Processo de Software Brasileiro), apresentando recomendações para aplicação de estimativas e métricas através da descrição de ferramentas de software específicas relacionadas ao tema e por fim apresentar uma análise estatística da maturidade das organizações ou empresas de software paraenses no uso de estimativas e métricas, através da elaboração e aplicação de um questionário baseado nos resultados esperados no que diz respeito às recomendações do modelo MPS.Br.

1.2. Justificativa

A falta de maturidade e até mesmo a falta de conhecimento sobre a importância do uso de métricas e estimativas para se obter qualidade no desenvolvimento de software vem ser o grande motivo para a elaboração deste trabalho, procurou-se verificar como as empresas ou organizações paraenses vem desenvolvendo seus projetos no que cerne o bom uso de estimativas e métricas.

1.3. Motivação

Devido a grande quantidade de questionamentos sobre como utilizar métricas e estimativas para possíveis obtenções de sucesso em projetos de software, surgiu a necessidade de se verificar como se encontra a maturidade das organizações paraenses nesse meio. E quais os recursos para se chegar a um nível de qualidade.

1.4. Objetivo

Obter um levantamento da maturidade das boas práticas de métricas e estimativas em organizações paraenses, tendo como base as orientações dos resultados esperados do MPS.BR (Modelo de Processo do Software Brasileiro). Citar algumas ferramentas e métodos para o uso de métricas e estimativas, bem como servir de apoio para que seja dada a importância e mostrar a boa utilidade de medições para estimar projetos com qualidade.

1.5. Organização do Trabalho

Este trabalho foi estruturado em sete capítulos, incluindo este, que foram distribuídos como descrito a seguir:

Capítulo 1: introdução.

Capítulo 2: tem por objetivo fazer uma síntese sobre gerência de projetos, passando pelas definições formais, suas formas e práticas, algumas das principais atividades, bem como sua importância e sua relação com medição de software.

Capítulo 3: descreve conceitos de métricas e estimativas, como se relacionam, as melhores práticas, a importância do uso em favor da qualidade e os cenários em que podem ser utilizadas.

Capítulo 4: faz uma introdução ao MPS.BR descrevendo seu conceito, sua base em modelos internacionais, das vantagens, motivação para criação do modelo e descrição os níveis.

Capítulo 5: discursa sobre a análise da maturidade das empresas pesquisadas, apresenta um resumo dos resultados esperados do MPS.BR que serviram de base para o questionário, descreve sobre a estrutura do questionário avaliativo, organizações avaliadas e a apresentação dos resultados.

Capítulo 6: trata das recomendações para aplicação de estimativas e métricas, ferramentas que podem ser usadas, procedimentos e técnicas mais utilizadas.

Capítulo 7: faz as considerações finais do trabalho, abordando as principais contribuições e limitações, enunciando as perspectivas para futuras pesquisas que possam ajudar as empresas paraenses nas boas práticas de métricas e estimativas.

2. Gerência de Projetos

Hoje o uso de melhores práticas em gerenciamento de projetos já é encarada como um fator de aumento de chances dos empreendimentos darem certo, pois é uma ação estratégica de cada empresa. O entendimento do objetivo da gerência de projetos e sua importância são esclarecidos por muitos autores.

Segundo (PMI, 2004), o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos.

O gerenciamento de projetos de software é uma parte essencial da engenharia de software. Um bom gerenciamento não pode garantir o sucesso de um projeto. No entanto, um mau gerenciamento geralmente resulta em falha do projeto: o software é entregue com atraso, custa mais do que foi originalmente estimado e falha ao atender seus requisitos (Sommerville, 2007).

Para Pressman (2006), a gestão do projeto envolve o planejamento, a monitoração e o controle do pessoal, processo e eventos que ocorrem à medida que o software evolui de um conceito preliminar para uma implementação operacional. SOMMERVILLE (2003) apresenta algumas atividades que são consideradas comuns entre diversos projetos de software: Elaboração de Propostas, Planejamento e programação de projetos, custo do projeto, Monitoramento e revisões de projeto, Seleção e avaliação de pessoal e Elaboração de relatórios e apresentações. A atividade e o número de atividades podem variar de projeto para projeto de software devido às especificidades de cada projeto. Entretanto, é fundamental para o desenvolvimento profissional de projetos de software que ocorra um planejamento mínimo dos passos que deverão ser realizados para concluir com sucesso um projeto de software.

Atividade: Elaborar Proposta

A proposta é um documento (artefato) que descreve como o projeto de software será executado. Entre os seus principais tópicos estão: Objetivo do Projeto, Estimativas de Custo e Programação. A proposta, portanto, é um documento apresentado a um provável cliente que especifica como o desenvolvedor pretende conduzir o desenvolvimento do produto de software. Caso a proposta seja aprovada, pode ser transformado em um contrato entre desenvolvedor e cliente. Então, trata-se de um documento que deve ser elaborado por pessoas experientes, pois erros nas estimativas de custo ou prazos, por exemplo, podem resultar em prejuízos para o cliente e/ou desenvolvedor.

Atividade: Planejar e Programar o Projeto

Essa atividade tem como foco principal identificar e descrever as atividades que serão executadas para atingir o objetivo especificado na Proposta (Ciclo de Vida detalhado) e estimar o tempo e custos relacionados a esse projeto. Portanto, pressupõe-se que o cliente aprovou a proposta e foi firmado um contrato entre ambos.

Atividade: Monitorar o Projeto

O monitoramento do projeto de software é uma atividade que procura acompanhar o andamento do projeto e comparar o progresso e custos reais aos previstos inicialmente no Plano de Projeto. Dependendo da complexidade, tamanho e processo de software padrão de uma empresa de desenvolvimento (entre outros fatores), o Monitoramento também pode envolver a observação, por parte do Gerente de Projetos, de possíveis riscos que poderiam comprometer o projeto de software. Desta forma, a atividade de Monitoramento deve definir quais mecanismos serão utilizados para realizar essas tarefas, por exemplo: reuniões periódicas com a equipe, consulta a relatórios técnicos e gerenciais, controle do tempo (cronograma) etc.

Atividade: Selecionar e Avaliar Pessoal

Dependendo do tipo de projeto, a seleção de pessoal é uma atividade empregada no gerenciamento de projeto e tem por objetivo formar uma equipe capaz em número (quantidade de pessoas) e habilidade para executar o projeto. Na seleção e avaliação do pessoal, são considerados aspectos como tempo de experiência, habilidade com as tecnologias que serão utilizadas no projeto, custo da hora do profissional etc.

Atividade: Elaborar Relatórios e Apresentações

Nessa atividade o Gerente de Projeto deve produzir relatórios que apresentem o andamento do projeto de forma concisa e objetiva. Os relatórios podem ser destinados tanto para o cliente como à empresa. Portanto, o Gerente deve ser hábil em redigir e apresentar as informações em reuniões contidas nos relatórios.

As atividades descritas anteriormente sofrerão variações para cada projeto, dependendo também da maturidade do gerente de projetos. Vale ressaltar que uma organização pode adotar processos baseados em padrões da engenharia de software para auxiliar na área de gerência.

Na área de TI, os sucessivos fracassos observados nos projetos de software ao longo das últimas décadas (CHAOS, 1994 apud OVIGLE et al., 2007), levaram grande parte das organizações a adotarem uma abordagem mais disciplinada para o desenvolvimento do software. O Rational Unified Process (RUP) é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento, buscando garantir a produção de software de alta qualidade que atenda às necessidades de negócio dentro dos prazos e custos estimados. Por ser um processo de engenharia de software, o RUP é uma tecnologia em camadas, onde a camada do “Processo” é

sustentada pelas camadas de “Métodos” e “Ferramentas”, podendo ser adaptado para atender as necessidades de cada organização focando na qualidade dos produtos produzidos, tornando-se um instrumento útil para a aplicação de controles e técnicas de gerenciamento. (RUP, 2003; PRESSMAN, 2002 apud OVIGLE et al., 2007).

Para CASTOR (2003), O RUP não cobre todos os aspectos de gerência de projetos de software, como: recursos humanos, custo e orçamento, contratação e etc. Porém para os aspectos relacionados ao produto de software, o RUP descreve algumas das atividades e técnicas desempenhadas pelo gerente de projeto.

Uma visão mais detalhada do fluxo de atividades na gerência de projetos pode ser observada na Figura 1, de acordo com o RUP.

Figura 1. Gerenciamento de Projeto: Fluxo de Trabalho (RUP.2001)

2.1. A Importância da Gerência de Projetos de Software

Segundo (AMARAL, 2008), gerenciar projetos corretamente é uma questão de sobrevivência empresarial, as empresas necessitam de uma posição competitiva no mercado, oferecendo produtos e serviços com qualidade, preços justos e dentro dos prazos. As disciplinas de gerenciamento de projetos têm se mostrado comprovadamente, eficientes em aumentar as probabilidades de sucesso de projetos, em todas as indústrias. É importante salientar que não se utiliza gerência de projetos apenas

para reduzir os riscos de fracasso total do projeto, mas sem dúvida este é seu objetivo maior. O fracasso de um projeto é o maior pesadelo de gerentes de projetos, equipes, patrocinadores e envolvidos em geral. Os motivos que podem levar ao fracasso de um projeto são inúmeros e obras inteiras têm sido escritas sobre este assunto. Porém existem razões mais comuns que levam ao fracasso o maior número de projetos na indústria em geral. Fergus O’Connell, em sua obra How to Run Successful High-Tech Project-Based Organizations (Artech House, 1999 apud AMARAL, 2008) apresenta uma relação dos dez principais motivos que levam projetos ao fracasso:

• Os objetivos do projeto não são bem definidos e/ou os envolvidos não são identificados;

• Os objetivos do projeto são definidos de forma apropriada, mas as mudanças não são controladas de forma apropriada;

• O projeto não é planejado de forma apropriada;

• O projeto não é gerenciado de forma apropriada;

• O projeto é planejado de forma apropriada, porém seus recursos não são gerenciados;

• Não são criados planos de contingência;

• As expectativas dos envolvidos com relação ao projeto não são gerenciadas;

• O projeto é planejado de forma apropriada, mas seu progresso não é monitorado e controlado;

• Relatórios de progresso são inadequados ou inexistentes;

• Quando ocorre problemas no projeto, as pessoas acreditam que os mesmos podem ser resolvidos de forma simples.

Problemas como esses estão presente na indústria de software à anos. Após algumas décadas de evolução a Standish Group, publicou o Chaos Report em 1994 (Standish, 1994) mostrando o resultado de uma pesquisa realizada em mais de 175.000 projetos de software pelo mundo. Segundo a pesquisa somente 16% dos projetos são finalizados com sucesso. O critério para ser considerado de sucesso é o cumprimento do prazo, custo e escopo. Projetos que não cumprem pelo menos uma dessas variáveis são considerados “Desafiados”. Como pode ser visto na Figura 2, 53% dos projetos não cumprem alguma das variáveis supracitadas. Por fim, 31% dos projetos, denominados “Cancelados”, são cancelados por completo.

Chaos Report 1994

16%

31%

53%

Sucesso

Cancelados

Desafiados

Figura 2. Resultado do Chaos Report de 1994

Mais espantoso ainda é fato de que os relatórios subsequentes (Standish, 2004) não mostram uma melhora significativa no número de projetos que são entregues fora do prazo, acima do orçamento ou com menos funcionalidades do que proposto, ou seja, os “Desafiados”. A Figura 3 mostra que apesar de ter havido uma diminuição no número de projetos cancelados e aumento nos que obtiveram sucesso, muitos projetos ainda são “Desafiados”. Inclusive o número de projetos de sucesso ficou, em geral, abaixo de 1/3 do total de projetos pesquisados. Isto demonstra que mesmo depois de mais de 35 anos de evolução, os projetos continuam com os mesmos problemas do passado.

Chaos Report

16%

27%

26%

28%

34%

29%

31%

40%

28%

23%

15%

18%

53%

33%

46%

49%

51%

53%

0% 20% 40% 60% 80% 100%

1994

1996

1998

2000

2002

2004

Sucesso

Cancelados

Desafiados

Figura 3. Resultado do Chaos Report entre 1994 e 2004

Em 2004, o Relatório Chaos Report, ao analisar os projetos de T.I (Tecnologia da Informação) que falharam, afirma que, para a maioria deles, a principal causa não foi a falta de recursos financeiros ou acesso à tecnologia, mas sim, falta de conhecimento em gestão de projetos. E este conhecimento não se aplica somente à figura do Gerente de Projetos, mas a toda equipe.

2.2. Gestão e Medição

Já foram discutidos diversos problemas relacionados ao desenvolvimento de software, os quais são resultantes da omissão ou do mau uso de metodologias e técnicas adequadas a esta importante tarefa de engenharia.

No entanto, boa parte dos fracassos no que diz respeito aos projetos de software deve-se, principalmente, a problemas de administração ou gerenciamento do desenvolvimento de software.

Mas especificamente na medição dentro da gerência de projetos, percebemos que muitas empresas não adotam, desconhecem ou não possuem maturidade para realizar técnicas de medições, sendo elas de tão fundamental importância.

Segundo De Marco (1993, apud Fernandes, 1995), “You cannot control what you cannot measure”, ou seja, não gerenciamos nada sem as medições necessárias, até mesmo projetos de software.

Para Contador (2008), um dos motivos da baixa adesão ao uso de medidas na área de software é o alto custo da coleta de dados dentro da organização. Além disso, a definição do que deve ser medido pela empresa representa uma das grandes dificuldades do processo. Embora exista uma gama variada de atividades a serem controladas, é necessário focar a coleta em um grupo restrito de dados, contemplado apenas as medidas necessárias, tornando o processo de coleta menos trabalhoso.

3. Medição versus Estimativa

Quando se fala em métricas, então, deve-se ter em mente que se trata de dados (números) quantitativos que irão mostrar em forma de indicadores o estado atual de um determinado projeto. A busca pela qualidade utilizando métricas de software deve ser aplicada tanto às pessoas que produzem o produto, quanto para o processo em que se desenvolve o mesmo produto. Com métricas podemos estimar prazos de entregas finais e ter uma visão global do projeto. É muito importante que os gerentes de projetos de software tenham o hábito de sempre estar medindo seus projetos para saberem como o mesmo está evoluindo e apresentar de forma clara os resultados obtidos para as pessoas envolvidas.

A utilização de métricas tem como objetivo medir a produtividade e qualidade de software, assim como para planejar e estimar projetos de software. Segundo Fernandes (1995, apud Oliveira, 2006), a medição está associada a vários aspectos do desenvolvimento de software:

Durante a fase de planejamento, as informações coletadas nas medições de projeto anteriores poderão ser utilizadas na estimativa do novo projeto;

Durante o desenvolvimento de software, as medições são coletadas e analisadas em relação às estimativas propostas inicialmente;

Ao término do desenvolvimento, medições são coletadas e analisadas, gerando as métricas do produto, como por exemplo, a taxa de defeito (que refletirá a qualidade do software produzido).

Assim as métricas podem ser definidas como o resultado extraído de determinadas medições coletadas ao longo do desenvolvimento.

Já uma desvantagem é que a métrica de software não oferece 100% (cem por cento) de confiança em seus resultados. A métrica serve de base para o conhecimento no campo da medição na gestão de projetos, com ajuda de projetos que já foram concluídos no passado, e não uma base de dados a qual se pode confiar e fazer estimativas que futuramente não serão aceitas e tomarão boa parte do tempo tentando adivinhar quanto tempo irá se gastar para produzir tal produto ou refazendo todo o trabalho.

     Segundo Kozak (1997, apud Oliveira, 2006), as métricas de software podem ser classificadas de várias maneiras:

Objetivas/Subjetivas. As métricas objetivas são facilmente quantificadas e medidas através de expressões numéricas ou representações gráficas dessas expressões, e calculadas de documentos de software. Já as subjetivas são medidas relativas baseadas em estimativas pessoais ou de grupo, sendo obtidas por termos linguísticos como alto, médio e baixo;

Absolutas/Relativas. Métricas absolutas não sofrem variação com a adição de novos itens. O tamanho de um programa, por exemplo, é uma medida absoluta (independente do tamanho de outras). Métricas relativas modificam-se com a influência de outras. Métricas objetivas são geralmente absolutas, enquanto que métricas subjetivas tendem a ser relativas;

Explícitas/Derivadas. Métricas explícitas são coletadas diretamente, enquanto que métricas derivadas são computadas a partir de outras métricas explícitas ou derivadas. Um exemplo de uma medida explícita pode ser "programador-mês", enquanto que "produtividade" (ou "linhas de código") por "programador-mês" seriam métricas derivadas;

Dinâmicas/Estáticas. Métricas dinâmicas possuem a dimensão tempo, como por exemplo, erros encontrados por mês. Assim, os valores tendem a se modificar dependendo quando as métricas são realizadas dentro do ciclo de vida do produto. Métricas estáticas, entretanto, permanecem sem variação, como por exemplo, o esforço total despendido ou total de defeitos encontrados durante o desenvolvimento de um produto;

Preditivas/Explanatórias. Métricas preditivas podem ser obtidas ou geradas antes do evento ocorrer, enquanto que as métricas explanatórias são produzidas após a ocorrência do fato.

     De uma forma geral, as métricas são especialmente úteis quando um histórico detalhado dos desenvolvimentos anteriores está disponível na organização. Adicionalmente, ferramentas estão disponíveis para auxiliar na automação da coleta de métricas. (Oliveira, 2000 apud Oliveira, 2006).

Dependendo do ambiente existe uma possibilidade de métrica a ser adotada e analisada, a Figura 4 apresenta onde pode ser empregado métricas dentro de uma organização de desenvolvimento de software.

Figura 4. Ambientes para Aplicação de Métricas (NETO, 2006)

A princípio, é necessário determinar o que se quer medir, a fim de se definir como os dados serão coletados. Essas decisões devem ser compatíveis com o processo de desenvolvimento. Uma metodologia de métrica e estimativa não vai solucionar de imediato os problemas de um processo de desenvolvimento, no entanto esta deve ser utilizada para tornar possível o entendimento do processo, para facilitar a previsão de suas fases e mostrar como controlá-las.

Uma das grandes dificuldades nas organizações de desenvolvimento e software principalmente para o gerente de projetos é entender da necessidade de se utilizar métricas em favor da qualidade dos serviços desenvolvidos.

A medição favorece um autoconhecimento interno da organização em termos quantitativos, podendo ser um ponto culminante para tomada de decisões em uma pressão imediata tanto interna quanto externa à organização. Vale ressaltar que toda a base de medidas organizadas adequadamente servirá para preparar-se para o futuro, podendo prever tendências e realizar uma boa estimativa.

Para Martinho (2007), a busca pela melhoria na qualidade do processo de desenvolvimento de software através de padrões, normas e ferramentas, está fazendo com que a empresa que tenha estabelecido e cumprido prazos de entrega, e os mesmos sejam reduzidos, mantendo a qualidade do software, obtenham vantagens consideráveis sobre suas concorrentes. Porém estimar o tempo de projeto e desenvolvimento de um software e a data de entrega do mesmo para o cliente é um processo delicado o qual envolve muita sensibilidade do Gerente de Projetos de Software e, principalmente, uma excelente capacidade de estimativa. É um cenário comum dentro das empresas desenvolvedoras de software.

Estimar prazos, custos e recursos para o projeto talvez seja uma das tarefas mais nobres e importantes quando do planejamento do projeto, pois é com base nela que negociamos as condições necessárias para gerenciar um projeto, assim como

encontrarmos os argumentos para revisão de prazos, custos e recursos (FERNANDES; KUGLER, 1989).

As estimativas e as premissas utilizadas para sua geração devem ser documentadas para possibilitar o acompanhamento do plano, conforme o progresso do projeto. O processo de Estabelecer Estimativa abrange, dentre outras, as seguintes atividades (SEI, 2002 apud HAZAN et al., 2005):

Estabelecer e manter as estimativas dos atributos dos artefatos e das tarefas: as estimativas de tamanho constituem o insumo principal para a maioria dos modelos usados para estimar custo, esforço e cronograma. As estimativas de tamanho devem ser consistentes com os requisitos do projeto para determinar-se esforço, custo e cronograma adequados. Assim, sempre que ocorrerem mudanças além do tolerado (relevantes) nos requisitos, as estimativas precisam ser revistas e o projeto replanejado. Sugere-se a utilização da métrica Pontos de Função (PF) (IFPUG, 2004 apud HAZAN et al., 2005) para as estimativas de tamanho. Os PF fornecem uma métrica de tamanho do projeto de software, quantificando as suas funcionalidades, sob o ponto de vista lógico, observando os requisitos do usuário (Garmus, 2001 apud HAZAN et al., 2005);

Determinar as estimativas de esforço e de custo para os artefatos e tarefas: as estimativas de esforço e custo devem ser geradas baseando-se em dados objetivos, ou seja, utilizando métodos e dados históricos. Os projetos com ausência de dados históricos de esforço de projetos similares disponíveis possuem um risco maior, necessitando de mais pesquisas para desenvolver bases racionais de estimativas;

Incluir a necessidade de uma infra-estrutura de suporte nas estimativas de esforço e custo: considerar a necessidade de recursos computacionais críticos no ambiente de desenvolvimento, no ambiente de teste, no ambiente de produção, ou em qualquer combinação destes. Estimativas de recursos computacionais incluem o seguinte: identificar os recursos computacionais críticos; e basear estimativas de recursos computacionais críticos em requisitos alocados. Exemplos de recursos computacionais incluem: memória, processador, espaço em disco, periféricos, capacidade da rede e do banco de dados.

Segundo (CESAR et al., 2008) o desconhecimento por parte do gerente de projeto, da natureza do produto, também contribui para falhas na estimativa. Defeitos são corriqueiramente encontrados no sistema demandando mais tempo em uma determinada funcionalidade. A produtividade por parte dos desenvolvedores varia ao longo da implementação. Tudo isso pode levar ao cancelamento do contrato ou em atrasos na entrega do produto. Portanto, o processo de estimativa de software deve ser contínuo e está sujeito a mudanças.

Um dos principais riscos que atinge o processo de estimativas é a falta de credibilidade nas estimativas pelas equipes de desenvolvimento (BOEHM, 2000 apud HAZAN et al., 2005). Isto ocorre quando as estimativas são irreais, ou seja, quando os projetos são subestimados ou superestimados. A acurácia das estimativas de tamanho torna-se fundamental para a elaboração de um cronograma e orçamento realistas, pois

as estimativas de tamanho constituem a base para a derivação das estimativas de custo e de esforço (SEI, 2002 apud HAZAN et al., 2005).

Estimativas podem ser vistas em macro e micro estimativas. Cabendo a primeira uma previsão do todo. Para esta estimativa conhece-se avaliação de especialistas (subjetivas, sujeitas a modificações), matemáticas (usando dados históricos), comparação e analogia (projetos com atributos simulares e os principais atributos análogos). Já na visão micro da estimativa acrescenta-se um esforço associado com cada componente ou atividade do processo separadamente. Neste caso, faz-se uma decomposição em menores partes do projeto (ARAUJO et al., 2005).

As estimativas de software realizadas dentro do PD (Processo de Desenvolvimento) são necessárias para a construção dos cronogramas, definições de escopo de versão, previsão de alocação de recursos, de pessoas, e realização de orçamentos (CISS, 2006 apud PEREIRA et al., 2007). Uma correta e bem realizada estimativa é fundamental para a qualidade do processo, do produto e para a viabilidade da execução das atividades (PEREIRA et al., 2007).

4. MPS.BR

O MPS.BR (Melhoria de Processos do Software Brasileiro) é um modelo de qualidade de processo de software direcionado à realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil coordenado pela Associação para Promoção da Excelência do software Brasileiro (SOFTEX).

Este modelo é baseado no CMMI (Capability Maturity Model Integration – Integração de Modelos de Maturidade da Capacidade para Desenvolvimento), nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro.

Uma das principais vantagens do MPS.BR é seu custo reduzido de certificação em relação às normas estrangeiras, sendo ideal para micro, pequenas e médias empresas.

O projeto tem apoio do Ministério da Ciência e Tecnologia, da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).

4.1. Motivação para criação do MPS.BR

A partir da crescente demanda de produtos de software onde, a cada dia, aumenta o nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos. A partir deste ponto, pode-se observar que as empresas estão buscando cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para a sobrevivência no mercado de TI.

Porém, o custo de uma certificação para uma empresa pode ser de até US$ 400 mil, o que se torna inviável para empresas de micro, pequeno e médio porte. Então, através da uma parceria entre a SOFTEX, Governo Brasileiro e Universidades, surgiu o projeto MPS.BR (Melhoria de Processo do Software Brasileiro), que é a solução brasileira compatível com o modelo CMMI, está em conformidade com as normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira.

4.2. Descrição geral do ModeloO MPS.BR está dividido em três (3) componentes (Figura 5): Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou de documentos do MPS.BR.

Figura 5. Componentes do MPS.BR (SOFTEX.2006)

O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém as definições dos níveis de maturidade, processos e atributos do processo. O MR-MPS está em conformidade com os requisitos de modelos de referência de processo da norma ISO/IEC 15504-2.

O MPS.BR apresenta 7 níveis de maturidade que são:

• A - Em Otimização;

• B - Gerenciado quantitativamente;

• C - Definido;

• D - Largamente Definido;

• E - Parcialmente Definido;

• F - Gerenciado;

• G - Parcialmente Gerenciado.Cada nível de maturidade possui suas áreas de processo, onde são analisados os

processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento).

Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistos.

• AP 1.1 - O processo é executado;

• AP 2.1 - O processo é gerenciado;

• AP 2.2 - Os produtos de trabalho do processo são gerenciados;

• AP 3.1 - O processo é definido;

• AP 3.2 - O processo está implementado;

• AP 4.1 - O processo é medido;

• AP 4.2 - O processo é controlado;

• AP 5.1 - O processo é objeto de inovações;

• AP 5.2 - O processo é otimizado continuamente.

O Guia de Aquisição é um documento complementar destinado a organizações que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém requisitos do MR-MPS, mas boas práticas para a aquisição de software e serviços correlatos.

O Guia de Implementação, composto de 7 partes descreve como implementar cada um dos níveis do MR-MPS. O Guia de Avaliação contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). O processo e o método de avaliação MA-MPS estão em conformidade com a norma ISO/IEC 15504-2.

O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de empresas para implementação do MR-MPS e avaliação MA-MPS pelas Instituições Organizadoras de Grupos de Empresas (IOGE), certificação de consultores de aquisição e programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR.

5. Análise da Maturidade

5.1. Resultados Esperados do MPS.BR

De acordo com a análise feita nos guias de referência e de implementação do MPS.BR, procurou-se verificar quais são os processos e resultados esperados que tratam de estimativas e métricas. A Tabela 1 apresenta toda a base de análise.

Tabela 1. Estrutura dos resultados esperados

Processos Resultados Esperados

Gerência de Projetos – GPR (Nível G) GPR2, GPR4, GPR5, GPR6.

Medição – MED (Nível F)MED1, MED2, MED3, MED4,

MED5, MED6, MED7.

Processos Resultados Esperados

Gerência de Projetos – GPR (Evolução) (Nível B)

GPR21, GPR22, GPR23, GPR24, GPR25.

Gerência de Projetos – GPR (Evolução) (Nível E) GPR4, GPR19.

No Apêndice A é apresentado uma tabela com os processos e resultados esperados, com um detalhamento maior, sendo especificado cada resultado e o entendimento do mesmo.

5.2. Questionário Avaliativo

O questionário do Apêndice B tem como objetivo obter informações sobre o nível de maturidade no uso de  estimativas e métricas das empresas de TI do estado do Pará para desenvolver um levantamento estatístico. Sua estrutura esta baseada nas orientações dos resultados esperados que contemplam estimativas e métricas do MPS.BR, tornando o questionário também uma forma de medir a qualidade nos processos de medição das organizações.

Foram criadas 17 perguntas que auxiliam na validação do processo de maturidade das empresas, tendo como possíveis respostas justificadas ou comentadas.

5.3. Organizações Avaliadas

No período de 3 à 15 de abril de 2009 foi enviado o questionário que consta no Apêndice B deste trabalho para 20 organizações paraenses, sendo que foi recebido 10 questionários respondidos.

Das organizações participantes:

a) LABES – UFPA: Laboratório de Engenharia de Software da UFPA (Universidade Federal do Pará) têm como objetivo incentivar e aprofundar a

pesquisa na área de Engenharia de Software na UFPA, mais especificamente em gerência de processos de software.

b) CTIC – UFPA: O Centro de Tecnologia da Informação e Comunicação da UFPA (CTIC), responsável por desenvolver e administrar atividades didáticas, científicas e administrativas desempenhadas pela Universidade; fazer o processamento dos dados estatísticos através da computação e realizar a computação dos dados de que necessita a Universidade no campo de pesquisa, ensino e administração.

c) CESUPA: Centro Universitário do Pará é uma unidade de ensino/serviço responsável por associar técnicas e tecnologias na prestação de serviços e/ou pesquisa na área de computação. Atua fortemente em projeto e desenvolvimento de software.

d) Cobra Tecnologia: Fundada em 1974, a COBRA foi a primeira empresa a desenvolver, produzir e comercializar tecnologia genuinamente nacional, no segmento de informática. Nos anos 90, já fazendo parte do conglomerado Banco do Brasil, torna-se integradora de soluções: especifica, comercializa, implanta, treina e presta assistência técnica em todo o País para equipamentos das maiores empresas desenvolvedoras mundiais.

e) FÓTON: É uma empresa de automação, consultoria, serviços e treinamentos com foco no mercado financeiro de pequeno e médio porte.

f) DETRAN: Departamento Estadual de Trânsito do Pará, também chamado DETRAN-PA, é um órgão público estadual, vinculado ao Governo do Estado do Pará, responsável pelo gerenciamento do trânsito de veículos em todo o estado do Pará.

g) SERPRO: Serviço Federal de Processamento de Dados - é uma empresa pública, vinculada ao Ministério da Fazenda. A Empresa, cujo negócio é a prestação de serviços em Tecnologia da Informação e Comunicações para o setor público, é considerada uma das maiores Organizações do setor, na América Latina.

h) PDCASE: Fornece soluções para o mercado financeiro, serviço de fábrica de software, outsourcing, desenvolvimento de projetos sob medida e capacitação de profissionais da área de TI (Tecnologia da Informação).

i) AmazonCop: Amazon Corporation é uma empresa genuinamente paraense que está a mais de 10 anos no mercado do norte do país, possui mais de 100 colaboradores, fornecendo soluções em TI voltadas para empresas de médio porte.

j) Versatilit: Empresa de desenvolvimento e prestação de serviços de Tecnologia da Informação.

k) Albras: A Alumínio Brasileiro SA é uma companhia brasileira, de capital fechado, que foi instalado em 1985, no município de Barcarena, a 40 quilômetros de Belém, em linha reta, capital do Estado do Pará, na Amazônia (ao Norte do Brasil). A empresa é resultado de uma associação da Companhia Vale do Rio Doce (51%) e da Nippon Amazon Aluminium Co. Ltd. (49%),

consórcio de empresas japonesas, entre trading companies, consumidoras e produtoras de alumínio e o Japan Bank for International Cooperation, organismo do governo japonês, sendo este o maior participante do consórcio.

l) Alunorte: Alumina do Norte do Brasil S.A, é uma empresa formada a partir de acordo realizado pelos governos do Brasil (representado pelo diplomata Gilbert Ducry) e do Japão em 1978 (com a participação da Companhia Vale do Rio Doce) para a criação da empresa. Atualmente é a maior refinaria de alumina do mundo.

m) FAPESPA: Fundação de Amparo à Pesquisa do Estado do Pará fomenta a pesquisa e fortalece o sistema regional de Ciência, Tecnologia e Inovação, CT&I.

n) Ministério Público do Pará: É o órgão criado para defender os direitos da sociedade, garantindo a ordem jurídica e o regime democrático.

o) Tribunal Regional Eleitoral do Pará: Garantir a efetividade, a celeridade e a transparência dos processos eleitorais.

p) Tribunal de Justiça do Estado o Pará: Responsável por processos judiciais do estado do Pará, possui um núcleo de desenvolvimento de sistemas internos.

q) Museu Paraense Emílio Goeldi: é uma instituição de pesquisa vinculada ao Ministério da Ciência e Tecnologia do Brasil.

r) CINBESA: Companhia de Informática de Belém desenvolve sistemas de informação coorporativos e específicos para a Prefeitura Municipal de Belém.

s) SEDUC: Secretaria de Estado de Educação, órgão de administração direta do Estado do Pará, têm por finalidade estudar, planejar e executar o controle e a avaliação dos assuntos relativos à política educacional do Governo do Estado.

5.4. Apresentação dos Resultados

De acordo com os resultados da pesquisa e levantamento dos dados, procurou-se representar as informações estatísticas através do gráfico apresentado abaixo, onde encontra-se organizado as questões e o número de empresas que adotam ou não algum tipo de métrica e estimativa:

Figura 6. Análise Geral dos Resultados por Perguntas

Abaixo consta a análise detalhada dos resultados obtidos em cada pergunta sequenciado de acordo com o questionário:

a) Quando se foi feita a pergunta do uso de WBS (Work Breakdown Structure), também conhecida no Brasil como EAP (Estrutura Analítica de Trabalho), tivemos 70% das empresas ou organizações afirmando que utilizam nas fazes iniciais de projeto para se ter uma visão macro do escopo do projeto, possibilitando saber quais os objetivos a serem alcançados.

b) Quando se foi feita a pergunta se a organização possui uma base de dados ou histórico de projetos para servir de apoio a uma análise de esforço e custo de tarefas, tivemos 80% das empresas ou organizações dizendo que possuem uma base histórica que serve para analisar o fluxo de atividades passadas, bem como analisar processos e pessoas envolvidas nos projetos e também reaproveitar códigos ou módulos para projetos futuros.

c) Com respeito ao uso de um cronograma incluindo marcos ou pontos de controle, 90% das organizações responderam que baseado no escopo do projeto definido na WBS e posteriormente repassado ao cronograma, no final de cada iteração ocorre uma análise de riscos e seus impactos, bem como aprovação de requisitos, homologação, etc. Em geral os pontos de controle ou milestones são utilizados para monitorar o andamento do projeto para possíveis tomadas de decisão.

d) Em relação à organização possuir uma lista de possíveis riscos para os projetos, bem como seus devidos impactos e tratamentos, 70% responderam que para cada projeto possuem uma lista de riscos com seus respectivos impactos, sendo que essa lista consta no plano de mitigação e contingência.

e) Em relação se a organização possui um método de medida e as medições dos projetos são baseadas nos objetivos da organização, 70% responderam que utilizam alguma metodologia como: GQM (Goal Question Metric), COCOMO

(Costructive Cost Model), etc, para realizar as medições dos projetos sempre indo a favor dos objetivos estratégicos da organização.

f) Em relação à organização possuir uma documentação detalhada do conjunto de medidas e se constantemente são revisadas de acordo com os objetivos da organização, 60% responderam que possuem um conjunto de métricas sendo essas revisadas procurando seguir os objetivos da organização no tange tomadas de decisões futuras.

g) Em relação à organização possuir uma documentação especifica para os procedimentos de como serão coletados e armazenados os dados dos projetos, 70% responderam que possuem um plano de medição que detalha como deve ser procedido a coleta e o armazenamento dos dados dos projetos.

h) Na questão que trata se de acordo com cada medida do projeto a organização possui uma documentação com as respectivas atividades e seus responsáveis, bem como um meio de comunicação entre eles, 50% das organizações responderam que possuem um plano de medição e que as atividades são delegadas pelo gerente de projetos bem como o meio de comunicação que se deverá seguir.

i) Em relação à coleta e análise dos dados dos projetos serem realizados de acordo com o cronograma, 70% das organizações responderam que o processo de análise e coleta de dados são realizados como esta definido no cronograma do projeto, essas atividades são repassadas para os coordenadores dos projetos que posteriormente repassa para um responsável da equipe.

j) Em relação às informações produzidas serem usadas para apoiar decisões do projeto indo de acordo com os objetivos da organização, 70% das organizações responderam que no final de cada iteração os resultados das medições são apresentados a toda equipe, servindo como tomada de decisões para o projeto, em se tratando de atraso da entrega, custo, renegociação com o cliente, entre outros.

Pode-se concluir que a grande maioria das organizações utiliza algum tipo de métrica e estimativa para o desenvolvimento de projetos de software, o que não justifica possuir um bom nível de maturidade, pois muitas organizações conhecem técnicas e metodologias, mas não utilizam de maneira correta ou contínua, muitas por não terem uma devida orientação das melhorias que poderiam ser feitas se o uso fosse feito corretamente, dando um maior nível qualidade a seus produtos.

6. Recomendações para Aplicação de Estimativas e Métricas

6.1. Ferramentas

Para o auxílio na gestão de projetos de software existe uma grande necessidade do uso de ferramentas. Este trabalho buscou elaborar uma lista com algumas dessas ferramentas e suas características:

a) Ferramenta: MSProject

Tipo: Proprietária Desenvolvedor: Microsoft

• Baseia-se no modelo Diagrama de Precedências. Portanto, as atividades do

projeto são criadas na forma de blocos, não na forma de setas;

• Utiliza o Gráfico de Gantt ou de barras como ferramenta básica a ser utilizada durante a entrada de dados;

• Aceita relações de precedências tipo Fim-Início, Início-Início, Fim-Fim e Início-Fim;

• Permite tarefas recorrentes: Inclusão de tarefas que ocorrem de forma repetitiva. Por exemplo, em um projeto pode haver reuniões todas as segundas-feiras;

• Permite estabelecer níveis hierárquicos para as tarefas, isto é, admite a existência de tarefas de resumo;

• Permite uso de subprojetos;

• Permite uso de "datas programadas" para as atividades;

• Permite uso do modelo probabilístico.

• Os custos são ligados diretamente às atividades na forma de custos fixos ou de custos dos recursos;

• Visualmente, se apresenta como um conjunto de planilhas e de gráficos.Disponível em: http://office.microsoft.com/pt-br/project/HA101656381046.aspx

b) Ferramenta: MrProject

Tipo: Livre Desenvolvedor: CodeFactory

Área de trabalho com suporte a: Gráfico de Gantt;

Visualização de Tarefas;

Visualização de Recursos;

Integrante da suíte de aplicativos Gnome Office.

Disponível em: http://ftp.gnome.org/pub/GNOME/sources/mrproject/0.10/

c) Ferramenta: Open Workbench

Tipo: Opensource Desenvolvedor: Niku Corporation

Para o plano de projeto: definir projetos e criar trabalhos relacionados com as atividades, fases, tarefas;

Criar dependências como: quando iniciar e quando terminar;

Criar subprojetos e vinculá-los ao projeto principal;

Criar e gerir dependências entre projetos;

Associar orientações referente às tarefas;

Criar, editar e apagar agendas.

Para a programação de projeto: agendar tarefas, manual ou automaticamente usando o Auto Schedule;

Esquema geral ou individualizado dos calendários;

Para gestão de recursos: definir recursos como: humanos, equipamentos, materiais ou financeiro;

Atribuir recursos a tarefas;

Análise do projeto;

Controlar o status do projeto, a porcentagem realizada e o que ainda falta realizar;

Definir, comparar e redefinir as configurações básicas do projeto;

Personalizar o projeto incluindo: coluna, layouts, filtros, classificar e basear em regras de formatação.

Disponível em: http://www.myclarity.com/

d) Ferramenta: GanttProject

Tipo: Livre Desenvolvedor:Projeto GanttProject

Com GanttProject você pode quebrar o seu projeto em uma árvore de tarefas e atribuir os recursos humanos e financeiros que têm de ser alocados em cada tarefa.

Você também pode criar dependências entre tarefas, como "essa tarefa não pode começar até que esta tenha acabado".

GanttProject trabalha seu projeto usando duas cartas: Gantt chart de tarefas e de recursos gráficos.

Você pode imprimir os seus gráficos, gerar relatórios em PDF e HTML, trocar dados com o Microsoft(R) Project(TM) e aplicações de planilha eletrônica.

Disponível em: http://ganttproject.biz/

e) Ferramenta: Jmetric

Tipo: GPL Desenvolvedor: Swinburne University of Technology

JMetric é um analisador de métricas. Este analisa arquivos de origem Java e fornece métricas de qualidade e tamanho.

Disponível em: http://www.it.swin.edu.au/projects/jmetric/products/jmetric/default.htm

f) Ferramenta: Scope

Tipo: Proprietária Desenvolvedor: Total Metrics

Permite um escalonamento de projeto usando IFPUG 4.2 análise por ponto de função.

Disponível em: http://www.totalmetrics.com/function-point-software/scope-project-sizing-software

g) Cost Xpert

Tipo: Proprietária Desenvolvedor: Cost Xpert

Implementa vários métodos de estimativa. A ferramenta utiliza dados coletados de 7.000 projetos, comerciais e militares, para assegurar maior precisão nas estimativas.  Para estimar o tamanho do projeto, a ferramenta implementa uma variedade de métodos. Pode-se utilizar linhas de código, pontos de função, pontos de característica, métricas GUI, métricas de objeto e as abordagens heurísticas top down e bottom up.

             Além do ajuste dos direcionadores de custo do COCOMO II, a ferramenta possibilita um ajuste ainda mais refinado da estimativa, baseado em um conjunto de 8 fatores. Além dos relatórios de divisão de esforço por fases e atividades, a ferramenta gera gráficos da estrutura de divisão funcional do trabalho e gráficos de distribuição do esforço.

Disponível em: http://www.costxpert.com/en/index.html

h) Ferramenta: Softstar

Tipo: Proprietária Desenvolvedor: Soft Star

Para cálculo de estimativa de esforço, custo, prazo e distribuição de equipe. A ferramenta implementa os modelos COCOMO original, Ada COCOMO e COCOMO II. O tamanho do sistema pode ser expresso em pontos de função ou em linhas de código. Após a inserção dos dados de pontos de função, deve-se informar a linguagem escolhida para implementação do sistema. A ferramenta Costar gera uma série de relatórios para estudo das estimativas calculadas. Apresenta o relatório em detalhes da distribuição do esforço em fases e sua duração. As ferramentas que implementam o modelo COCOMO levam em consideração as atividades de Gerenciamento de Configuração e Garantia de Qualidade de Software (CM/QA) na distribuição de esforço e cálculo de custo do projeto.

Disponível em: http://www.softstarsystems.com/

i) Ferramenta: USC COCOMO II

Tipo: Gratuita Desenvolvedor: University of

Southern Califórnia

É uma implementação do modelo Post Architecture do COCOMO II. Ela calcula esforço, prazo e distribuição do esforço e encontra-se disponível para plataformas Sun Sparc Unix, Microsoft Windows e plataformas que habilitam a linguagem Java. Os parâmetros dos direcionadores de custo podem ser calibrados na ferramenta. Vários tipos de relatórios podem ser gerados pela ferramenta.

Disponível em: http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

j) Ferramenta: WinFPA

Tipo: Proprietária Desenvolvedor: CSP CONSULTORIA & SISTEMAS

Software multi-usuário especializado em Dimensionamento e Planejamento de Projetos de Desenvolvimento e Manutenção de Sistemas

Ideal para quem precisa criar:

-Histograma de Mão-de-obra;

-WBS;

-Cronogramas (alto-nível e detalhado);

-Análise de Riscos;

-Modelagem dos processos/dados;

-Simulações: Equipe, Duração, Prazo, Defeitos, Manutenção;

-Composição do Preço de Venda;

Principais funcionalidades:

- Contagem dos Pontos de Função;

- Geração do Histograma de Mão-de-obra;

- Simulações: Equipe e Duração;

- Geração da EAP(WBS): Estrutura Analítica do Projeto;

- Geração do Cronograma do Projeto: Macro e Detalhado;

- Comparativos entre projetos;

- Visão 3D do projeto;

- Exportações: XML, MS-Excel, ASCII, MDL, MPP 2002/03 (desktop);

- Importações: XML, ASCII, MDL, MPP 2002/03 (desktop);

- Análise de Riscos (disponível na versão CORPORATE);

- Composição do Preço de Venda;

- Determinação dos feriados nacionais;

- Distribuição do Esforço do Projeto;

- Estatística de Taxas de Entrega e Custos;

- Classificação do Tamanho do Projeto;

- Estimativa de Casos de Testes;

- Estimativa de Defeitos;

- Fluxo de Caixa mensal e acumulado;

- Assistente de Inclusão de funções;

- Revisor automático de parâmetros;

- WMM – Macro Modeler (modelagem em alto-nível);

- Cálculo da Taxa de Produtividade.

Disponível em: http://www.winfpa.com.br/index.htm

O primeiro obstáculo a ser superado para que tais ferramentas sejam utilizadas é a efetiva implementação das métricas nas empresas desenvolvedoras de software para poderem gerar os dados necessários e essenciais. O segundo é a obtenção de uma ferramenta que auxilie o Gerente de Projetos de Software na compilação e analise dos dados gerados, que não seriam poucos (MARTINHO, 2007).

6.2. Procedimentos e Técnicas

As diversas técnicas de estimativa de esforço de desenvolvimento do produto de software descritas na literatura especializada obtêm em geral uma estimativa do valor da métrica de software relacionada à quantidade de trabalho ou esforço a ser realizado. Nesse sentido, algumas destas técnicas utilizam como entrada o valor de uma métrica de software relacionada ao tamanho. É recomendável a utilização de mais de uma técnica de estimativa a fim de comparar-se o resultado das diferentes técnicas e possibilitando chegar a uma estimativa melhor (MACEDO, 2003).

De acordo com Martinho (2007), Existem diversas metodologias de métricas como: Métricas orientadas a seres humanos, Métricas orientadas a função, Métricas orientadas ao tamanho, Métricas de produtividade, Métricas de qualidade, Métricas técnicas, etc.

A seguir é apresentada uma descrição de algumas metodologias:

a) GQM (Goal Question Metric).

Segundo (SOUSA; OLIVEIRA e ANQUETIL, 2003), o GQM baseia-se na suposição de que para se medir de maneira eficaz, alguns objetivos devem ser estabelecidos para que estes sirvam de rota para o estabelecimento de questões que orientarão a definição de métricas em um contexto particular.

O objetivo do método GQM é caracterizar e fornecer um melhor entendimento dos processos, produtos, recursos e ambientes e, assim, estabelecer bases para comparação com trabalhos futuros (BRASILI, 1994 apud SOUSA; OLIVEIRA; ANQUETIL, 2003).

b) PSM (Practical Software Measurement).

O modelo PSM surgir para auxiliar a gerência na mensuração de projetos de software em relação a custos, prazos e requisitos, dentre eles: horas trabalhadas no projeto, funcionalidades oferecida pelo projeto e ainda permitindo obter o esforço do projeto e seu tamanho funcional através da contagem de pontos de função. O PSM é uma abordagem para melhorar a maturidade dos processos de desenvolvimento de software na sua qualidade e consequentemente dos seus atributos (COPPOLA, 2008).

O PSM é um modelo para a estruturação da mensuração em um projeto de software. De um ponto de vista prático, o PSM procura resolver dois problemas: 1- como especificar formalmente as medidas a serem usadas e 2- como conduzir o processo de medição. O PSM alcança esses objetivos através de dois modelos: de informação e processo (AGUIAR, 2002).

Figura 7. Modelo de Processo do PSM

Uma forma de melhor utilizar o PSM é utilizando a o PSM INSIGHT que é uma ferramenta desenvolvida pelo departamento de defesa norte americano, junto com o ASMO (Army Software Metrics Office), para a implantação do modelo PSM. Atualmente na sua versão 4.2.2, a ferramenta auxilia profissionais para a aplicação das técnicas PSM e para o acompanhamento de métricas (US ARMY, 2003 apud COPPOLA, 2008).

c)Estimativa por analogia

Segundo (TAVARES, 2005), pesquisas comprovaram que o julgamento especialista é o método de estimativas mais comumente utilizado. Mas comprovaram também que, em geral, o especialista utiliza a própria memória para relembrar as estimativas de projetos anteriores necessárias para uma nova estimativa. Isso ocorre porque, ou ele tem dificuldade de acesso aos documentos dos projetos anteriores, ou não entende como tais projetos podem ajudá-lo. Sendo assim, os riscos de erros desse método são menores quando uma equipe de especialistas é adotada. Ou seja, um método mais estruturado de julgamento especialista é a abordagem Delphi Banda-larga, que se utiliza de, no mínimo, quatro especialistas por projeto.

d)Delphi

Requisitos detalhados são passados para especialistas para que cada um faça uma avaliação privada e produza uma estimativa. Os resultados são coletados e um resumo anônimo é produzido. Este resumo é então repassado para os especialistas que refazem suas estimativas. Um coordenador decide quando um nível suficiente de consenso foi atingido e a interação deve parar. Uma explicação mais detalhada pode ser encontrada em (PMI, 1996 apud MACEDO, 2003).

A seguir é apresentada uma descrição de algumas técnicas para métricas:

a) LOC – Lines of Code

Segundo (PARO, 2005), a técnica de mensuração por linhas de código (LOC – Lines of Code) é uma das medidas mais antigas para determinação do tamanho, esforço e, conseqüentemente, produtividade no desenvolvimento de software. Ela consiste basicamente na contagem da quantidade do número de linhas de código de um programa de software. É uma técnica de fácil automação, eliminando esforços manuais. Porém, é uma técnica que conta com muitas desvantagens. Podemos citar, entre elas, o fato de que é inexato ter que medir a produtividade de um projeto de desenvolvimento com a saída de somente uma das fases (fase de codificação); a experiência do desenvolvedor, pois o número de linhas de código pode variar de pessoa a pessoa; a diferença entre linguagens (o número de linhas de código de uma aplicação desenvolvida em Cobol certamente é diferente da quantidade de linhas de código da mesma aplicação desenvolvida em linguagem C).

A seguir é apresentado alguns tipos de métricas:

a)Métricas de Halstead

Estima o esforço empenhado na programação. Ela baseia-se em medidas objetivas de código, e está relacionada com a teoria da informação, possuindo as seguintes qualidades mensuráveis, definidas para um dado programa codificado em qualquer linguagem de programação.

b)Métricas de McCabe

Segundo (SILVA; GARCIA; RINALDI e PONTES, 2007) ainda nos meados de 1970, foi desenvolvida a métrica da “complexidade ciclomática” de McCabe, baseada no número de condições de fluxo em um programa (em um conceito estrito de complexidade).

A métrica de McCabe (MCCABE, 1976 apud TIMÓTEO, 2008) foi selecionada por ter uma solida validação teórica baseada na teoria dos grafos, esta métrica foi definida de modo independente de tecnologias, ou seja, ela pode ser aplicada para qualquer linguagem de desenvolvimento de software.

c) Métrica de Pontos de Casos de Uso (PCU)

O Ponto de Casos de Uso (PCU) foi definido por Gustav Karner (KARN, 93 apud ANDRADE e OLIVEIRA) para estimar projetos OO (Orientado a

Objetos). O processo de contagem dessa métrica consiste de seis passos conforme mostra o a Figura 8.

Figura 8. Passos do processo de contagem de PCU

d) Análise por Pontos de Função (APF)

A idéia fundamental da análise por ponto de função consiste em medir o tamanho de qualquer produto de software baseado em termos lógicos, orientados ao usuário. A análise por ponto de função não se preocupa diretamente com a plataforma tecnológica, ferramentas de desenvolvimento e linhas de código. Ela simplesmente mede a funcionalidade entregue ao usuário final. Nesse sentido, a métrica de pontos de função de acordo com o IFPUG (International Function Point Users Group) avalia o produto de software e mede o seu tamanho baseando-se em características funcionais bem definidas deste sistema (MACEDO, 2003).

Para obtenção de qualidade de software (TABORDA e BIERHALS, 2003) descrevem que, as medidas utilizadas para quantificar as características que atestam a qualidade de um software podem ser obtidas através da avaliação de aspectos como: polimorfismo, encapsulamento, coesão, acoplamento e complexidade.

Métrica de Polimorfismo: polimorfismo refere-se a métodos com a mesma assinatura em classes herdadas. São avaliados aspectos como fatores de polimorfismo, que em um índice que vai de 0 a 1, verifica a existência de polimorfismo de métodos na especificação. O polimorfismo puro ou sobrecarga em classes isoladas mede o número de métodos com assinaturas diferentes, mas com o mesmo nome, já o polimorfismo estático nos ancestrais identifica se foi implementado algum método com mesmo nome, porém com argumentos ou tipos diferentes na classe de suas ancestrais. São levados em conta também fatores como polimorfismo estático nos descendentes e em relação de herança, polimorfismo dinâmico nos ancestrais e nos descendentes e polimorfismo em relação à herança.

Métrica de Encapsulamento: aqui encontramos o fator de atributos ocultos, que indica, em um índice que vai de 0 (não uso) a 1(máximo uso), o quanto os atributos são restritos somente a classe, não sendo possível o acesso a outras classes, pois o acesso é permitido pelos métodos públicos e o fator de métodos ocultos que avalia a quantidade de métodos acessíveis por outras classes.

Métrica de Coesão: avalia se as características realmente são pertinentes a classe. E auxilia na abstração do seu tipo. Trata basicamente da falta de coesão nos métodos que é descrito por Pressman como o número de métodos que tem acesso a um ou mais dos mesmos atributos.

Métrica de Acoplamento: característica que se refere à interdependência entre as classes. A busca de uma baixa dependência entre módulos facilita a reutilização dos módulos em outras aplicações e ameniza a implementação de mudanças tanto no desenvolvimento quanto na manutenção. O acoplamento entre as classes ocorre pela interação entre elas.

Métrica de Complexidade: avalia aspectos que se referem ao grau de entendimento do software como um todo. Isso é um fator muito importante na hora de fazer uma manutenção no caso da ausência ou má documentação. São avaliados fatores como tamanho e número de argumentos nos métodos, número de métodos nas classes, profundidade da arvore de herança, fator de herança de métodos e atributos e referência a subclasses.

7. Conclusão

O Processo de Desenvolvimento de Software deve ser continuamente medido durante seu desenvolvimento. Para isso é necessário criar uma “cultura” de medição e métrica (desenvolvimento com bases técnicas), pois essa tarefa se estende a todos os profissionais envolvidos no projeto.

Segundo Martinho (2007), o mais importante a ser ressaltado é que as métricas devem ser muito bem feitas pelos gerentes de projetos e que devem ser mostradas de uma forma clara e que todos possam entender os resultados gerados. Feito isso, o resultado que se tem é um conjunto de dados que darão a idéia do processo e um entendimento do projeto. Permitirá aos Gerentes de Projetos de Software aperfeiçoar e melhorar o processo de desenvolvimento do produto e avaliar a qualidade do produto que está sendo produzido. Mas o mais importante é que sem existir uma ferramenta que auxilie os Gerentes de Projetos de Software na analise dos dados coletados através das métricas podemos cair novamente em um dilema: existem métricas adequadas, mas os dados coletados são tantos e a análise dos mesmos, complicada e demorada que os Gerentes de Projetos de Software não as utilizam.

A pesquisa apresentada neste trabalho procurou mostrar o nível de maturidade das organizações paraenses no uso de estimativas e métricas, o resultado foi satisfatório, pois a grande maioria utiliza técnicas e ferramentas ao longo do desenvolvimento de projetos, mas há uma grande necessidade de como utilizar de maneira mais correta garantindo boas práticas e sempre procurando crescer no nível de qualidade.

Este trabalho fica como referência para esclarecer dúvidas no que envolve processos, técnicas e ferramentas para medir e estimar o desenvolvimento de projetos de software.

Para pesquisas futuras fica a necessidade de envolver um maior número de organizações paraenses, obtendo com isso um verdadeiro quadro analítico da maturidade dessas organizações, possibilitando fornecer uma maior visibilidade do quanto é importante e onde precisa ser melhorado. Cabe também ressaltar que o resultado dessa pesquisa poderá servir para elaboração de um estudo de caso para cada organização paraense visando apresentar onde a empresa ou organização pode melhorar no uso das melhores práticas de técnicas e metodologias. Quebrando esse paradigma no que envolve o uso de métricas e estimativas de software.

Referências

AMARAL, F. (2008) “Por que projetos de software falham?” Disponível em: <http://www.fernandoamaral.com.br/Default.aspx?Artigo=52>. Acesso em: 15 abr. 2009.

AGUIAR, M. (2002) “Pratical Software Measurement: O CMM da Mensuração?” Disponível em: <http://www.metricas.com.br/Downloads/PSM_CMM_Mensuracao_Software.pdf>. Acesso em: 16 abr. 2009.

ANDRADE, E. L. P; OLIVEIRA, K. M. (2004) “Aplicação de Pontos de Função e pontos de Casos de uso de Forma Combinada no Processo de Gestão de Estimativas de Tamanho de Projetos de Software Orientado a Objetos”. Disponível em: <http://www.ip.pbh.gov.br/ANO7_N1_PDF/IP7N1_andrade.pdf>. Acesso em:17 abr. 2009.

ARAUJO, D. G; ANNA, N. S; KIENBAUM, G. S. (2005) “Proposta de um Ambiente de Apoio a Estimativas em Projetos de Software Através Simulação de Simulação”. Anais do V WORKCAP. São José dos Campos-SP.

CONTADOR, D. C. T. (2008) “A importância das medições no controle de um projeto de software”. IETEC. Disponível em: <http://www.ietec.com.br/site/techoje/artigos_autor/artigos/63>. Acesso em: 16 mar. 2009.

CASTOR, E. M. (2003) Gerenciando Projetos de Software com RUP e PMBOK. Trabalho de Conclusão de Curso (Especialização em Tecnologia da Informação) - UFPE, orientado pelo Prof. Hermano Perreli, Recife-PE.

COPPOLA, E. J. (2008) Uma contribuição à melhoria da maturidade dos processos de desenvolvimento de software: um estudo de caso da utilização do Practical Software And Systems Measurement - PSM INSIGHT. Dissertação de Conclusão de Mestrado em Inovação Tecnológica e Desenvolvimento Sustentável do Centro Estadual de Educação Tecnológica Paula Souza, orientada pelo Prof. Dr. Napoleão Verardi Galegale, São Paulo-SP.

CESAR, A; RIBEIRO, F; LUIZ, L; ARRUDA, T; BRAYNER, T. 2008 Métricas de Software. Monografia de Qualidade de Software. Centro de Informática – Universidade Federal de Pernambuco - UFPE. Disponível em: <www.cin.ufpe.br/~tmb/%5BQualidade%5D_Monografia_de_Qualidade.doc>. Acesso em: 20 mai. 2009.

FERNANDES, A. A. Gerência de software através de métricas: Garantindo a qualidade do projeto, processo e produto. Compreendendo a dimensão do software e de sua gestão. São Paulo: Atlas, 1995. Cap. 1, p. 18.

FERNANDES, A. A; KUGLER, J. L. C. Gerência de projetos de sistemas: uma abordagem prática. Rio de Janeiro: LTC - Livros Técnicos e Científicos Editora Ltda, 1989. p. 12.

HAZAN, C; STAA, A. VON. (2005) Análise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software. Monografia do curso de Ciência

da Computação da Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro-RJ.

MARTINHO, F. (2007) Métricas de Software como Ferramenta de Apoio ao Gerenciamento de Projetos de Software. Disponível em: <http://www.testexpert.com.br/?q=node/403>. Acesso em: 03 abr. 2009.

MACEDO, M. V. L. R. (2003) Uma Proposta de Aplicação da Métrica de Pontos de Função em Aplicações de Dispositivos Portáteis. Trabalho Final de Mestrado Instituto de Computação Universidade Estadual de Campinas, orientado pelo Prof. Dr. Paulo Lício de Geus, Campinas-SP.

MELO, M. A. V. (2002) Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Departamento de Ciência da Computação - Universidade Federal de Minas Gerais, Belo Horizonte-MG.

NETO, P. A. S. Planejamento e Gerência de Projetos. (2006) Trabalho de Apresentação Métricas de Software do Curso (Gerência Educacional de Tecnologia da Informação) – Centro Federal de Educação e Tecnologia do Rio Grande do Norte, Natal-RG.

OLIVEIRA, S. R. B. (2006) Processos de Software: Princípios, Ambientes e Mecanismos de Execução. Exame de Qualificação do Programa de Doutorado do CIn/UFPE, orientado pelo Prof. Dr. Alexandre Marcos Lins de Vasconcelos, Recife-PE.

OLIVEIRA, J. P. F. (2005) Gerenciamento de Projetos de Software. Monografia de Conclusão do Curso de Ciência da Computação - Centro de Ciências Exatas e da Natureza da Universidade Federal da Paraíba, orientado pelo Prof. Dr. Glêdson Elias, João Pessoa-PB.

OVIGLE, O; COSTA, A. G; KIMIE, P; ITO, M. (2007) Utilizando o Rational Unifield Process para atender a Lei Sarbanes-Oxley. In: Primeiro Workshop de Desenvolvimento Rápido de Aplicações, Porto de Galinhas, 2007. Disponível em: <http://reuse.cos.ufrj.br/wdra2007/index.php?option=com_content&task=view&id=5&Itemid=6>. Acesso em: 13 abr. 2009.

PMI - PROJECT MANAGEMENT INSTITUTE, Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. Guia PMBOK® . 3.ed, 2004.

PRESSMAN, Roger S. Engenharia de software. Conceitos de gestão de projetos. 6.ed. São Paulo: McGraw-Hill, 2006. Cap. 21, p. 482.

PRADO, Darcy, Gerenciando Projetos nas Organizações, Belo Horizonte MG, EDG, 2000.

PEREIRA, R; TAIT, T. F. C; CASTRO, C. Y. H; TRINDADE, D. F. G; SILVA, J. V. (2007) Estimavas de Software: O Estudo de uma Aplicação Prática Utilizando a Técnica de Use Case Points. Departamento de Informática - Universidade Estadual de Maringá. Maringá-PR. FFALM - Faculdades Luiz Meneghel. Bandeirantes-PR.

PARO, C. J. (2005) Medidas de tamanho de desenvolvimento e de melhorias de software. Disponível em: <http://www.bfpug.com.br/>. Acesso em: 16 abr. 2009.

RUP. Rational Unified Process. Gerenciamento de Projeto: Fluxo de Trabalho. 2001. Disponível em:

<http://www.wthreex.com/rup/process/workflow/manageme/wfd_pm.htm>. Acesso em: 18 mar. 2009.

SILVA, D; GARCIA, M. N; RINALDI, H. M. R; PONTES, C. C. C. Análise das Possíveis Diferenças entre Contratantes e Contratados em Terceirização de Serviços de Software Segundo a Métrica de Análise de Ponto de Função. BASE - Revista de Administração e Contabilidade da Unisinos, São Leopoldo-RS, p. 49, abr. 2007.

SOUSA, K. D; OLIVEIRA, K. M; ANQUETIL, N. Aplicação de GQM para avaliação de processo de manutenção de software. In: Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimiento, 2003, Valdivia. 3a Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimiento, JIISIC, 2003.

STANDISH (1994) Chaos Report. Software Development Report, The Standish Group, West Yarmouth, MA, Disponível em: <http://www.standishgroup.com>.

STANDISH (2004) Chaos Report. Software Development Report, The Standish Group, West Yarmouth, MA, Disponível em: <http://www.standishgroup.com>.

SOMMERVILLER, Ian. Engenharia de software. Gerenciamento de projetos. 8.ed. São Paulo: Person Addison-Wesley, 2007. Cap. 5, p. 61.

SOMMERVILLE, Ian. Engenharia de software. Tradução Maurício de Andrade. 6.ed. São Paulo: Addison-Wesley, 2003.

TAVARES, C. F. O. K. (2005) Projetos de Estimativa de Software. Departamento de Informática e Matemática Aplicada - Universidade Federal do Rio Grande do Norte, Natal-RN.

TIMÓTEO, A. L. (2008) Plano de Dissertação de Mestrado em Ciência da Computação. Universidade Federal de Pernambuco - Centro de Informática, Recife-PE.

TABORDA, L. B; BIERHALS, L. (2003) Métricas de Qualidade de Produto. Trabalho apresentado na Universidade Federal de Santa Catarina - Departamento de Informática e Estatística, orientado pelo Prof. Ricardo Pereira e Silva, Florianópolis-SC.

Apêndice A – Processos e Resultados Esperados

Guia de Referência MPS-BR e Guia de Implementação

PROCESSO RESULTADO RESUMO (ENTENDIMENTO)

Gerência de Projetos –

GPR (Nível G)

GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

Após ser definido o escopo do projeto, deve haver uma decomposição em partes menores utilizando-se de uma EAP ou WBS. Essa decomposição favorece a visualização do tamanho do projeto, não só para a equipe do projeto, mas para o cliente, dando uma maior facilidade para medir cada parte, desenvolver o cronograma, estimar o custo de cada parte, bem como a divisão e distribuição das tarefas.

GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

Para se estimar o esforço e o custo é necessário ter uma base de dados de projetos anteriores, é preciso que esses dados sejam consistentes para que os resultados da estimativa sejam satisfatórios.

GPR5 - O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.

Primeiramente é necessário criar uma matriz de criticidade, para identificar o grau de relacionamento entre as tarefas, para então posteriormente estabelecer um cronograma de duração do projeto sempre levando em consideração a WBS. E após esses processos poderá se fazer uma estimativa de custo e elaboração do orçamento do projeto. Fazer uma manutenção desses processos é fundamental para se ter controle e qualidade no projeto.

GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de

É necessária a identificação de possíveis riscos para o projeto. A criação de uma lista dos possíveis

ocorrência e prioridade de tratamento são determinados e documentados.

riscos é criada, sendo posteriormente analisado quais destes riscos têm uma maior chance de ocorrer, bem como verificar o seu impacto e seu devido tratamento. Cabe ao gerente fazer um monitoramento desses riscos.

Medição – MED

(Nível F)

MED1 - Objetivos de medição são estabelecidos e mantidos a partir dos objetivos da organização e das necessidades de informação de processos técnicos e gerenciais.

Após o levantamento dos objetivos da organização, os objetivos de medição são estabelecidos baseados nesse levantamento e então alguns aspectos podem ser medidos, como: processos, produtos e recursos. A documentação gerada a partir desses objetivos de medição servirá para tomada de decisões e é de extrema necessidade a criação de um método para as medições, para que os resultados possam realmente atender os objetivos da organização.

MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado.

Deve-se estabelecer um conjunto de medidas baseadas em critérios de medição. Essas medidas devem ser detalhadas, documentadas e principalmente revisadas para que então os objetivos de medição da organização sejam atingidos.

MED3 - Os procedimentos para a coleta e o armazenamento de medidas são especificados.

A partir da documentação especificada de cada medida, todos os procedimentos para coleta de dados devem ser definidos para que os objetivos de cada medição sejam atendidos. É importante que a entrada dos dados, bem como a integração com os processos sejam automatizados para facilitar a verificação, a validação e acesso a

essa base de dados.

MED4 - Os procedimentos para a análise da medição realizada são especificados.

De acordo com cada medida especificada, será necessário criar uma documentação com as respectivas atividades e seus responsáveis, bem como estabelecer um meio de comunicação com os participantes. Esse processo facilitará uma análise mais adequada e com qualidade.

MED5 - Os dados requeridos são coletados e analisados.

De acordo com os procedimentos de coleta de dados já definidos, os dados efetivamente passam a ser coletados e analisados por seus respectivos responsáveis. É importante que essa coleta seja realizada em suas datas já definidas no cronograma, para não afetar o andamento do projeto. A partir da análise os resultados deverão ser apresentados aos seus interessados para possíveis conclusões.

MED6 - Os dados e os resultados de análises são armazenados.

Todos os resultados e dados coletados e analisados devem ser armazenados para possíveis analises futuras. Tudo deve estar bem especificado para facilitar as verificações futuras principalmente em relação às interpretações de medidas de como elas poderão ser utilizadas. Todo esse processo facilitará a criação de uma base

histórica.

MED7 - As informações produzidas são usadas para apoiar decisões e para fornecer uma base objetiva para comunicação aos interessados.

Os responsáveis pelas medições devem utilizar as informações produzidas para ter apoio nas tomadas de decisão. É importante a confidencialidade com essas informações, não permitindo uso indevido. As medições servirão para que as tomadas corretivas e riscos avaliados sejam realizados com sucesso para os objetivos da organização e do projeto. A clareza da comunicação deve estar bem relacionada a cada objetivo, facilitando a utilização dos resultados com os objetivos.

Gerência de Projetos –

GPR (evolução) (Nível B)

GPR 21 - (A partir do nível B) Subprocessos do processo definido para o projeto e que serão gerenciados estatisticamente são escolhidos e são

identificados os atributos por meio dos quais cada subprocesso será

gerenciado estatisticamente.

É realizada uma seleção dos subprocessos que serão gerenciados estatisticamente, sendo necessário ter uma relevância para o alcance dos objetivos de qualidade e desempenho do projeto. Posteriormente à seleção dos subprocessos, será necessário identificar os atributos do produto e do processo para o gerenciamento estatístico.

GPR22 - (A partir do nível B) O projeto é monitorado para determinar se

seus objetivos para qualidade e para o desempenho do processo serão atingidos. Quando necessário, ações corretivas são identificadas.

É necessário um monitoramento constante dos objetivos de cada subprocesso como qualidade e desempenho, se realmente estão sendo alcançados. É interessante utilizar métodos que possam antecipar as chances de se obter resultados futuros, baseados nos dados atuais ou históricos.

GPR 23 - (A partir do nível B) O entendimento da variação dos subprocessos escolhidos para gerência

É necessária a utilização de métodos estatísticos para avaliar cada subprocesso selecionado. Uma gerência estatística deve estar

quantitativa, utilizando medidas

e técnicas de análise estatística previamente selecionadas, é estabelecido e mantido.

em funcionamento para analisar cada medida e técnica utilizada estatisticamente. Devem ser selecionadas e analisadas medidas que estejam associadas aos objetivos de qualidade e desempenho do projeto e do processo respectivamente.

GPR 24 - (A partir do nível B) O desempenho dos subprocessos escolhidos para gerência quantitativa é monitorado para determinar a sua capacidade de satisfazer os seus objetivos para qualidade e para o desempenho. Ações são identificadas quando for necessário tratar deficiências dos subprocessos.

É preciso haver um monitoramento de cada subprocesso para verificar se os objetivos de qualidade e desempenho estão sendo alcançados e em paralelo buscando tomar ações corretivas nas possíveis deficiências encontradas. É interessante a utilização de gráficos para representar os resultados de forma clara, facilitando com isso a comunicação entre os interessados.

GPR 25 - (A partir do nível B) Dados estatísticos e de gerência da qualidade são incorporados ao repositório de medidas da organização.

Todos os dados estatísticos e de qualidade do projeto conforme sua evolução devem ser introduzidos ao repositório de medidas da organização, construindo com isso uma base histórica para análises futuras.

Gerência de Projetos –

GPR (evolução) (Nível E)

GPR4 - (A partir do nível E) O planejamento e as estimativas das atividades do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processo organizacional.

De acordo com o repositório de estimativas o planejamento do projeto será baseado. Toda a base histórica de dados bem organizada, facilitará nos próximos planejamentos ou tomada de decisões de projetos. Com essa base histórica, uma análise de tempo ou esforço para determinadas atividades poderão ser bem mais sucedidas e principalmente justificadas. Os métodos de estimativas como Pontos por Casos de uso ou Pontos por Função, poderão ser calibrados de acordo com os valores da base

histórica, facilitando um replanejamento ou verificar possíveis riscos para com os objetivos do projeto e da organização.

GPR19 - (A partir do nível E) Produtos de trabalho, medidas e experiências documentadas contribuem para os ativos de processo organizacional.

A partir do resultado das medidas de projetos já executados, será possível realizar um levantamento de propostas de melhorias para projetos futuros. Sendo de fundamental importância a manutenção do repositório de medidas, pois nesse momento a organização poderá estabelecer padrões para os projetos, bem como as experiências adquiridas nos projetos terão também um valor para a melhoria dos ativos de processo.

Apêndice B – Questionário avaliativo das empresas

Pesquisa da Maturidade das Estimativas e Métricas em Organizações Paraenses

Com intuito de realizar uma análise da maturidade das organizações ou empresas de software paraenses no uso de estimativas e métricas, foi elaborado esse questionário baseado nos resultados esperados no que diz respeito às recomendações do modelo MPS.Br (Melhoria de Processo de Software Brasileiro).

O questionário conta com 17 perguntas, sendo de fundamental importância uma justificativa ou um comentário de como é realizado o processo na empresa, para que a pesquisa obtenha sucesso.

Obs: Ressaltamos que as informações contidas no questionário não serão divulgadas, sendo de uso exclusivo para elaboração estatística.

O resultado do respectivo questionário faz parte do trabalho final para obtenção de título do curso de Pós-Graduação em Gerência de Projetos de Software da Universidade Federal do Pará ano 2008.

Alunos: Fábio Lima de Figueiredo e Luiz Otávio Barata.

Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira.

Questionário

1Para estruturar os projetos a organização utiliza uma EAP (Estrutura Analítica de Projetos) ou WBS (Work breakdown structure)? Caso Sim, Justifique ou comente.

R:

2A organização possui uma base de dados ou histórico de projetos para servir de apoio a uma análise de esforço e custo de tarefas? Caso Sim, Justifique ou comente.

R:

3 A organização utiliza um cronograma incluindo marcos ou pontos de controle? Caso Sim, Justifique ou comente. R:

4 A organização possui uma lista de possíveis riscos para os projetos, bem como seus devidos impactos e tratamentos? Justifique ou comente.R:

5 A organização possui um método de medida e as medições dos projetos são baseadas nos objetivos da organização? Caso Sim, Justifique ou comente. R:

6A organização possui uma documentação detalhada do conjunto de medidas e constantemente são revisadas de acordo com os objetivos da organização? Caso Sim, Justifique ou comente.R:

7A organização possui uma documentação especifica para os procedimentos de como serão coletados e armazenados os dados dos projetos? Caso Sim, Justifique ou comente.R:

8De acordo com cada medida do projeto a organização possui uma documentação com as respectivas atividades e seus responsáveis, bem como um meio de comunicação entre eles? Caso Sim, Justifique ou comente.R:

9 A coleta e análise dos dados dos projetos são realizados de acordo com o cronograma? Caso Sim, Justifique ou comente.

R:

10 As informações produzidas são usadas para apoiar decisões do projeto indo de acordo com os objetivos da organização? Caso Sim, Justifique ou comente.R:

11 É realizada uma seleção de subprocessos e identificação dos atributos do produto para um gerênciamento estatístico? Caso Sim, Justifique ou comente.R:

12O projeto é monitorado para determinar se seus objetivos para a qualidade e desempenho do processo estão sendo atingidos? Caso Sim, Justifique ou comente.R:

13Os projetos possuem uma Gerência Estatística para analisar cada medida e técnica utilizada, indo de acordo com os objetivos de qualidade e desempenho do projeto e do processo respectivamente? Caso Sim, Justifique ou comente.R:

14É realizada uma monitoração de cada subprocesso para verificar se os objetivos de qualidade e desempenho estão sendo alcançados, tomando ações corretivas nas possíveis deficiências encontradas? Caso Sim, Justifique ou comente.R:

15Os dados estatísticos e de qualidade do projeto conforme suas evoluções são incorporados ao repositório de medidas da organização? Caso Sim, Justifique ou comente.R:

16O planejamento de novos projetos é baseado através do repositório de estimativas e do conjunto de ativos do processo organizacional? Caso Sim, Justifique ou comente.R:

17A partir dos resultados das medidas de projetos já executados a organização realiza um levantamento de propostas de melhorias para projetos futuros? Caso Sim, Justifique ou comente.R: