Medição de software – uma visão geral para CIOs

A medição de software é importante porque é difícil gerenciar o que você não mede. O trabalho de software é um trabalho de conhecimento. É um dos empreendimentos mais dispendiosos empreendidos pela humanidade, com mais de 50 milhões de pessoas em todo o mundo a trabalhar em funções de software altamente remuneradas e, para a maioria delas, os seus esforços não são medidos. Muitas pessoas não percebem que o tamanho do software pode ser medido. A maioria das outras formas de trabalho humano possui medidas padronizadas de tamanho e produtividade. Mas com o trabalho de software, embora existam métricas adequadas, elas raramente são usadas. Os líderes da indústria, os educadores, os executivos e até mesmo os governos têm estado relaxados relativamente a este fenómeno, mas com a crescente importância do software na sobrevivência empresarial, é necessária mais transparência e medição de software apropriada. A introdução da medição de software com dimensionamento COSMIC ajudará os CIOs a gerenciar de forma mais eficaz.

A medição de software ajuda a responder perguntas importantes

Ao tentar responder às questões de quanto esforço é necessário para entregar um projeto de software ou quando será concluído, a maioria das organizações confia nas opiniões de especialistas. Essas estimativas de software tendem a não ser científicas e sujeitas a manipulação. O que eles precisam é de um meio consistente de medição de software. Constituem uma base pouco sólida para decisões de gestão fiáveis e podem muitas vezes levar a comportamentos contraproducentes. No entanto, com estimativas de software válidas e padronizadas e métricas de software baseadas no dimensionamento funcional padronizado em pontos de função COSMIC (CFPs), os CIOs podem melhorar significativamente a visibilidade, a capacidade de gerenciamento, a produtividade e a relação custo-benefício do trabalho de software em sua organização. As métricas de software baseadas em CFP e as métricas de projeto correspondentes também são apropriadas para relatórios em nível de conselho. Esta leitura de 15 minutos será suficiente para você iniciar esta jornada rumo a níveis mais elevados de gerenciamento de software.

Medição de tamanho por software é importante.

Consideremos algumas características gerais específicas do trabalho de software:

• O trabalho de software é quase inteiramente impulsionado pelo esforço humano.
• Existem muitos fatores que determinam o esforço necessário para desenvolver algum software. O fator mais significativo é tamanho funcional.
• Tamanho funcional pode ser estimada e, em alguns casos, até medida antes do início da codificação.
• Existem dezenas de outros fatores que afetam o esforço necessário para desenvolver software, incluindo: competência da equipe, complexidade e suporte executivo, mas o tamanho é o mais significativo.
• Existe uma grande variabilidade na produtividade entre os desenvolvedores. 10x ou mais entre o menos e o mais produtivo – e o mesmo para as equipes.
• O trabalho de software não é escalável. Existem deseconomias de escala, causadas principalmente pela elevada proporção de tempo gasto na comunicação entre os membros da equipe. Uma linguagem comum e o conhecimento do tamanho de um projeto podem ajudar a conter esse problema.

Desde que o software se tornou uma indústria, o dimensionamento de software tem sido um tema de debates intermináveis entre desenvolvedores e gestores. Dado o número de pessoas envolvidas na indústria de software, é surpreendente que os executivos e os conselhos de administração tenham permitido que isto acontecesse.

Embora existam muitos fatores que afetam o custo e a duração de um projeto de software, o tamanho é o fator mais significativo. Se você analisou os requisitos e determinou o tamanho funcional dos CFPs, poderá prever, com razoável confiança, quanto tempo levará e quanto deverá custar. Estas são questões vitais que os gestores responsáveis precisam de responder para planearem eficazmente. Armar-se com o conhecimento do tamanho funcional no início do ciclo de vida de um projeto pode ajudar a melhorar a qualidade das decisões tomadas pelos gerentes e, portanto, pode reduzir o risco, o custo e a duração do projeto. Estão disponíveis benchmarks do setor ou as organizações podem estabelecer os seus próprios benchmarks de produtividade em PCP, a fim de responder à pergunta “quando terminaremos?” pergunta.

Medição de Software e Engenharia de Software

Todas as outras formas de engenharia adotam medidas de tamanho padronizadas (ISO). A Engenharia de Software é a única “disciplina” de Engenharia que não conseguiu fazê-lo. A engenharia de software deve adotar medidas de tamanho padronizadas.

Dimensionamento de software padronizado

Muitas pessoas pensam que a medição do tamanho do software só pode ser realizada após a conclusão do trabalho. Isto não é assim. O software pode ser medido antes mesmo de a codificação ser iniciada.

A maioria das pessoas envolvidas na indústria não sabe que a medição do tamanho do software é possível e fácil de fazer, mesmo antes de qualquer trabalho de codificação ser iniciado. O tamanho funcional pode ser determinado apenas examinando os requisitos do usuário.  

Você pode contar linhas de código depois que o software foi escrito, mas a contagem de linhas de código (LOC) tem pouco valor, exceto quando se considera o trabalho para manter o que já foi escrito. Além disso, considere dois desenvolvedores escrevendo alguma funcionalidade, o dev A pode escrevê-la em apenas 4 linhas de código, enquanto o dev B leva 40 linhas para obter a mesma funcionalidade. Qual é maior? O que é mais produtivo? Qual é mais sujeito a erros? Isso nos mostra que não podemos usar LOC de forma confiável como um preditor de tamanho, esforço ou estimativa de tempo.

A medição do tamanho funcional do software leva a decisões baseadas em dados sobre software

Como sociedade, estamos a avançar rapidamente para uma tomada de decisões baseada em dados. Mesmo para decisões em casa, analisamos avaliações e dados técnicos antes de tomar uma decisão de compra. Para que esta abordagem seja eficaz, precisamos de utilizar dados válidos, consistentes e fiáveis. Tendo examinado as principais medidas no espaço de software por muitos anos, concluímos que as métricas baseadas no tamanho COSMIC são as mais confiáveis.

• Tamanho ou escopo (CFP),
• Métricas de produtividade (CFP/tempo),
• Métricas de qualidade de software (Defeitos/CFP) e
• Recursos (recurso/CFP).

Mude para boas práticas de dimensionamento de software

Medir e estimar software tem sido um desafio desde o início da indústria de software. Iremos pular a lição de história e ir direto para a situação atual. A maioria das equipes ágeis de software estima o esforço usando indicadores de “equivalente ao esforço” não científicos e inconsistentes. pontos da história ou Tamanhos de camisetas.  Pontos da história e Tamanhos de camisetas são estimativas de proxy não confiáveis, não lineares e altamente utilizáveis para jogos sobre quanto tempo levará para realizar uma parte do trabalho. O número de pontos da história alocado por um estimador ou equipe será influenciado pelos motivos de quem está declarando o tamanho. Os “pontos históricos” são muitas vezes o único indicador que os gestores recebem para os ajudar a planear e gerir o trabalho, pelo que estes indicadores são usados em demasia e mal utilizados como uma espécie de métrica fiável, quando estão longe disso. Em alguns casos, a contagem de histórias é usada como um indicador de progresso e tamanho. Nossos estudos de mais de 250.000 histórias de usuários mostraram uma variação no tamanho das histórias de 2 a 120 CFP, evidenciando que o tamanho das histórias é inconsistente e, portanto, a contagem de histórias não é confiável.

A solução para este problema já está disponível há alguns anos: é a medição padrão ISO do tamanho funcional do software, conhecida como Ponto de Função COSMIC (CFP). O dimensionamento COSMIC é uma metodologia gratuita que é um padrão internacional estável, regido por uma organização sem fins lucrativos  https://www.cosmic-sizing.org/. O padrão COSMIC é uma adaptação do conceito original de dimensionamento funcional que foi inventado pelo IBMista Alan Albrecht em 1974.

O COSMIC Function Point (CFP) é uma unidade de medida de tamanho funcional que pode ser aplicada a QUALQUER projeto de software, trabalho DevOps, manutenção de software ou implementação de pacote. É uma medida de tamanho consistente e universal que pode ser usada independentemente dos métodos de codificação ou linguagens utilizadas. Ele está gradualmente sendo reconhecido como o principal padrão de dimensionamento e está sendo ministrado por um número crescente de cursos de engenharia da computação em todo o mundo.

O dimensionamento COSMIC permite estimar ou medir o tamanho funcional (o número de CFPs) dentro de um pedaço de software. Representa uma visão do tamanho da perspectiva do usuário, não de uma perspectiva técnica. (Observe que um “usuário” pode ser outro ator do sistema, portanto esta metodologia também pode ser usada para sistemas embarcados). É independente da tecnologia ou arquitetura usada para entregar o software e, portanto, pode ser usado em todo um portfólio de software e trabalhos de manutenção.  Como CIO, você pode avaliar cada um de seus projetos de software e atividades de manutenção de software. Você se beneficiará de métricas de software válidas e consistentes para tomar decisões bem informadas.  Você pode até medir projetos anteriores para fornecer referências de produtividade.

Queremos saber quando será concluído

Este é um desafio comum enfrentado pelos CIOs. E normalmente é muito difícil responder. Mas quando você usa CFPs como uma métrica de tamanho padrão e acompanha a produção das equipes de desenvolvimento em CFP por mês, ou CFP por sprint, a data de término se torna previsível. Medir o tamanho do software é a base para métricas de software válidas e responde à questão crucial de quanto tempo levará.

Tamanho do CFP e sua relação com esforço

O tamanho do CFP é um excelente preditor de esforço e, portanto, de custo. Estudos independentes demonstraram que o CFP é um preditor de custos mais consistente do que a estimativa da própria equipa em pontos de história (ver gráficos abaixo). As taxas de produtividade variam de equipe para equipe, mas qualquer equipe, com todas as outras coisas sendo iguais, provavelmente entregará um número consistente de CFP por sprint ou por mês. Assim, você pode determinar rapidamente o custo por CFP.

Adequado para contratos

Como o CFP é uma medida consistente e independente, também pode ser utilizado em contratos de software. Em vez de serem forçados a assinar um contrato de “tempo e materiais” com um fornecedor de desenvolvimento, os CIOs podem solicitar contratos baseados em custo por CFP. Isso pode proporcionar mais certeza de custo, mesmo que você ainda não conheça todos os requisitos. Os contratos de software terceirizados baseados em pontos de história provavelmente custarão 10% a mais e levarão cerca de 10% a mais do que aqueles baseados em um preço fixo firme por CFP. Nesses contratos deverão também incluir metas de produtividade (ex. CFP/mês) e qualidade (limites de defeitos/CFP encontrados em testes de aceitação, por criticidade).

Aprendendo a medir o tamanho

A técnica de dimensionamento da funcionalidade do software em CFP leva cerca de um dia para aprender o básico e cerca de três semanas para se tornar proficiente e certificado. Com experiência, você será capaz de determinar o tamanho equivalente de uma equipe-ano de trabalho de desenvolvimento em menos de um dia de dimensionamento. Se você optar por usar nossa ferramenta de dimensionamento automatizado, ScopeMaster, o dimensionamento CFP poderá ser realizado ainda mais rápido e com pouco esforço.

Dimensionamento padronizado de software em sua organização

Como em tudo, a utilização de pesos e medidas padronizados conduz a um mercado mais justo e transparente. O dimensionamento padronizado de software fará o mesmo com o mercado de serviços de software – é apenas uma questão de tempo. Até então, há vencedores e perdedores. Só os EUA gastam $500 mil milhões por ano em software empresarial. Estimamos que mais de 30% disso poderia ser economizado com a adoção de medição padronizada de tamanho de software.

Se você quer saber por que os humanos fazem o que fazem, vale sempre a pena seguir a trilha do dinheiro. Existem instituições multibilionárias que prosperam com contratos de “tempo e materiais” e cujos interesses comerciais serão ameaçados pela introdução de dimensionamento padronizado. Hoje em dia, a maior parte do trabalho de software é encomendado com base no tempo e no material, com pouco risco comercial para o fornecedor. Uma vez que as organizações compradoras começam a insistir em pagar saída em vez de esforço no trabalho de software, o equilíbrio do risco comercial mudará ligeiramente do fornecedor para o comprador.

Além disso, muitos consultores, treinadores ágeis, fornecedores de estruturas e até mesmo desenvolvedores se beneficiam da falta de transparência que advém do não dimensionamento formal do software.

Ao utilizar o dimensionamento CFP, os compradores poderão adquirir serviços de software, incluindo desenvolvedores, testadores, treinadores ágeis, arquitetos e até consultores, com um custo por CFP. No devido tempo, a ampla adoção do dimensionamento CFP será inevitável porque aqueles que comprarem os serviços de software descobrirão que não só é mais transparente e mensurável, mas que com o dimensionamento adequado é possível fornecer mais software, mais rapidamente. Eventualmente, isto levará à mercantilização do trabalho de software.

A capacidade de entregar projetos de mudança de software de forma mais rápida e melhor do que os concorrentes está se tornando um fator determinante para a sobrevivência corporativa. Ao usar medições válidas, você pode determinar quais equipes, fornecedores e projetos são realmente bem-sucedidos em comparação com aqueles que apenas fingem ser. Por exemplo, se a equipa A entregar 1000 CFP em 12 meses por $1 milhões de dólares, enquanto a equipa B entrega 700 CFP em 20 meses por $2m, poderá ver claramente quem está a fazer um trabalho melhor. Isto não é possível sem o dimensionamento do CFP.

Haverá resistência à adoção de um dimensionamento transparente do trabalho de software. A transparência e a mensurabilidade podem ser ameaçadoras para aqueles que beneficiam da sua ausência. Você deve esperar resistência de seus fornecedores de desenvolvimento e até mesmo de suas próprias equipes internas de desenvolvimento, que atualmente desfrutam de um grau de liberdade que advém do fato de não serem medidos.

Você ouvirá críticas como “não temos tempo para fazer isso”. Para uma típica história de usuário refinada, serão necessárias até 2 horas de conversação agregada para moldar, analisar e estimar os pontos da história. Já o CFP pode ser determinado em apenas alguns minutos.

Outra reação que você encontrará é “já temos muitas métricas”. Em resposta a isso, você precisará desafiar suas equipes quanto à validade das “métricas” que elas fornecem atualmente. Aqui estão algumas das chamadas métricas comumente usadas e suas falhas em relação aos equivalentes baseados em CFP. Estes são indicadores comumente usados, podem ser úteis, mas NÃO são métricas válidas com base em um sistema métrico.

• Pontos da história – estes são subjetivos, jogáveis, não científicos e inconsistentes dentro e entre equipes. Os pontos da história são essencialmente um proxy para uma estimativa de horas de esforço. Em vez disso, use CFP.
• Tamanhos de camisetas– são também indicadores de esforço subjetivos, jogáveis, não científicos e inconsistentes.
• Contagens de histórias – as histórias variam em tamanho absoluto, normalmente variando de 2 a 120 CFP, mediana de 6 CFP, portanto, contar histórias de tamanho desigual é um indicador de progresso não confiável.
• Velocidade Ágil – citado em histórias ou pontos da história ao longo do tempo. Ver Pontos de história, isso deve ser considerado um indicador de produtividade. Em vez disso, use: CFP por sprint ou mês`
• Burndown do Sprint ou queima semanal– com base em pontos da história ou contagens de histórias. Em vez disso, use PCP entregue.

N.º. Tempo de ciclo, lead time, taxa de correção de defeitos, complexidade do código, taxa de descoberta de defeitos, e cobertura de teste são exemplos de métricas válidas que encorajamos.

Usando CFP como métrica básica para controle de projetos

Além de usar CFP para dimensionar seu portfólio de software e projetos, você pode usar métricas baseadas em CFP como base para controlar o progresso do projeto:

• produtividade (PCP/mês),
• qualidade (defeitos encontrados/CFP)*
• agendamento de recursos humanos como a alocação de trabalho (em CFP) por indivíduo.
• escopo (CFP), mudança de escopo e volatilidade de escopo

*isso pode ser subdividido em defeitos por criticidade e defeitos por origem – tudo por CFP.

Todas essas são medidas vitais para controlar efetivamente os projetos de software. Você começará rapidamente a ver quais projetos estão indo bem e quais precisam de ajuda.

PCP e Qualidade

Vejamos a relação entre qualidade de software e dimensionamento ou conhecimento de tamanho (em CFP).

O processo de dimensionamento ajuda na qualidade

O processo de dimensionamento nos incentiva a pensar profundamente sobre os requisitos funcionais necessários para fornecer uma capacidade comercial valiosa. Esse pensamento ajuda a eliminar precocemente possíveis mal-entendidos. Caso contrário, esses mal-entendidos se manifestariam como defeitos. Portanto, o processo de dimensionamento do CFP é, na verdade, o “último teste no turno à esquerda”.

O conhecimento do tamanho ajuda a melhorar a qualidade

Saber o tamanho pode nos ajudar (ao usar benchmarks) a prever o número de defeitos que podemos esperar encontrar em um software. Esta previsão, por sua vez, nos ajudará a determinar quantos testes são necessários?   Ao trabalhar com defeitos por CFP, nossa apreciação pela qualidade melhora.

A análise automatizada também ajuda a melhorar a qualidade

Ao optar por usar o ScopeMaster® para analisar e testar requisitos, você descobrirá imediatamente cerca de 50% dos problemas de requisitos latentes que poderá descobrir rapidamente e com antecedência. Isso representa cerca de 8% de todos os defeitos de um projeto, e ainda mais em projetos maiores.

Gestão de qualidade de fornecedores com CFP

Ao usar um contrato que insiste em um nível máximo de defeitos aceitáveis por CFP, você pode incentivar os fornecedores a garantir a qualidade. Algo que nos contratos de T&M eles podem estar menos motivados a fazer.

Limitações da medição de tamanho funcional com CFP

Os CFPs são uma medida do tamanho funcional da perspectiva do usuário. Eles medem os movimentos de dados de um sistema de software. Eles não podem medir tamanho computacional de uma transação de software, nem podem ser usados para medir “não funcional”aspectos do trabalho de software, como desempenho, capacidade de manutenção, usabilidade (e outras funcionalidades). Isto não é apenas uma deficiência da PCP, mas uma falha de toda a indústria, ninguém ainda concebeu medidas válidas e consistentes destas duas dimensões (tamanho computacional, e NFRs) de software.

Mesmo com essas limitações, a correlação do CFP com o esforço necessário para realizar o trabalho é excepcional, o que significa que conhecer o tamanho do CFP lhe dará um indicador muito forte de quanto esforço é necessário e, portanto, de custos e prazos – as duas partes do conhecimento de planejamento que os gerentes de projeto e gerentes de desenvolvimento precisam para tomar decisões acertadas.

Quando você pode estimar ou medir o tamanho

A estimativa do CFP pode ser realizada a qualquer momento do ciclo de vida de desenvolvimento de software, mesmo logo no início, assim que os requisitos de negócio começam a surgir. As estimativas iniciais podem se tornar mais refinadas e precisas à medida que seu conhecimento sobre a funcionalidade do usuário aumenta. À medida que os requisitos evoluem, a certeza das estimativas aumenta e, eventualmente, as estimativas podem tornar-se uma medição precisa. Para realizar uma medição precisa, basta conhecer todas as movimentações de dados associadas a cada requisito funcional (ou história de usuário funcional). Com o CFP você pode dimensionar qualquer conjunto de requisitos, não precisa conhecer todos os requisitos antecipadamente, nem conhecer o projeto para determinar o tamanho do CFP. No máximo, você deve medir o tamanho do CFP de uma história de usuário pouco antes de ela ser aceita em um sprint. Você pode até estimar ou medir projetos anteriores para construir dados de referência para benchmarks internos de produtividade.

As desvantagens de adotar a PCP

Existem muitas pessoas no mundo do software cujo sustento se beneficia da ausência de medições consistentes de tamanho. Entre os maiores beneficiários estão as organizações que vendem serviços de desenvolvimento de software com base em tempo e materiais. Isto inclui algumas organizações muito grandes e influentes. Além disso, muitos consultores, treinadores ágeis, fornecedores de estruturas e até mesmo desenvolvedores se beneficiam da falta de transparência que advém do não dimensionamento formal do software. Os erros podem ser ocultados, a produtividade é difícil de avaliar e isso pode servir aos seus interesses. Por outro lado, para qualquer pessoa responsável pela compra ou gerenciamento do trabalho de software, não há realmente nenhuma desvantagem na medição com CFP. É preciso um esforço trivial para fazer a medição. Tanto o conhecimento do tamanho quanto o ato de dimensionar o CFP podem ajudar a reduzir problemas de escopo, melhorar a qualidade e melhorar a produtividade em qualquer projeto de software.

CFP é perfeito para Agile e Scaled Agile

Os requisitos completos de um projeto de software raramente são conhecidos no início do projeto. O fluxo de trabalho Agile permite lidar com essa incerteza inicial. Projetos ágeis são caracterizados pela evolução da consciência dos requisitos. Felizmente, o PCP pode ser medido com precisão mesmo antes de todos os requisitos de um sistema serem conhecidos. Você simplesmente mede apenas o que sabe. Você também pode estimar potencialmente o que ainda não se sabe com certeza. Com a experiência, você pode até estimar antecipadamente quando apenas os recursos amplos ou épicos são conhecidos. À medida que o projeto avança, os épicos são divididos em histórias de usuários funcionais, e essas estimativas iniciais tornam-se medidas mais precisas de CFP com uma margem de erro decrescente. Pense na certeza dos requisitos como um espectro que vai desde “sabemos tudo” até “sabemos muito pouco”. Embora seja mais fácil dimensionar um projeto se você conhece todos os requisitos, é surpreendente o quanto é possível saber desde o início. Em geral, simplesmente não trabalhamos o suficiente no início para descobrir aquilo que é cognoscível.

Em organizações com múltiplas equipes de software, os gerentes seniores precisam conhecer a produtividade de diferentes equipes, para ajudar a melhorar as equipes com baixo desempenho e aprender com as altamente produtivas. O CFP resolve o problema da falta de dimensionamento consistente entre as equipes. Ao adotar o CFP em todas as equipes, as taxas de produtividade podem ser comparadas. As taxas de produtividade também podem ser comparadas entre equipes internas e externas. Isso ajuda a fornecer aos executivos de software os dados de que precisam para tomar melhores decisões. Nunca se deve comparar equipes com pontos da história.

É hora de controlar o tamanho do software

Após 70 anos de suposições e abordagens não científicas, chegou a hora de os CIOs e líderes de software responsáveis insistirem na adoção de métricas de engenharia adequadas ao tamanho. Ao introduzir e insistir na adoção do CFP, você desfrutará de melhor visibilidade e previsibilidade de sua atividade de software. Haverá pessimistas em sua organização e entre os fornecedores, então você precisará estar pronto para incentivá-los a ver os méritos de uma medição de tamanho válida. A medição do tamanho do software é uma boa prática. Isso leva a uma melhor mensurabilidade e, em última análise, a uma gestão mais eficaz. No devido tempo, você poderá compartilhar métricas de CFP entregues e mantidas como parte de suas métricas no nível do conselho. Os CIOs com visão de futuro que desejam melhorar o desempenho através da medição se beneficiarão significativamente com a adoção do CFP.

A automação está aqui para ajudar

Nosso trabalho inovador no ScopeMaster fornece um dimensionamento automatizado, consistente e válido de histórias de usuários funcionais ou requisitos de usuários funcionais escritos sem esforço. O ScopeMaster estimará o número de CFP em uma história de usuário analisando a linguagem da história. A maioria dos projetos ágeis contém menos de 500 histórias de usuários. Eles podem ser dimensionados automaticamente em uma hora usando o ScopeMaster. As histórias de usuários podem então ser refinadas (melhoradas em qualidade) e a estimativa se tornará uma medição, o que normalmente leva um décimo do tempo usando o ScopeMaster® do que sem ele.

Próximos passos.

Se você quiser saber mais sobre como medir seu portfólio de software, aprender sobre métricas de software válidas e medir sua produtividade de desenvolvimento para trazer maior certeza aos seus projetos de software, aqui estão algumas sugestões de próximos passos:

1. Incentive sua equipe de gestão a descobrir o dimensionamento COSMIC no CFP, recomendamos o Guia para medição de software
2. Incentive seu PMO a introduzir o dimensionamento do CFP como uma métrica no gerenciamento de portfólio
3. Peça aos seus fornecedores para reportarem o CFP entregue por sprint ou por mês
4. Peça aos seus gerentes de qualidade que analisem os relatórios sobre os defeitos encontrados por CFP.
5. Peça à sua equipe de contratos para investigar os contratos de preço fixo por CFP e peça aos seus fornecedores que façam uma cotação de custo por CFP.
6. Antecipe a resistência de dentro da sua organização e dos fornecedores, esteja pronto para combatê-la com sua própria necessidade de melhorias na transparência de tamanho, produtividade, valor pelo dinheiro e medição de qualidade.

Entre em contato conosco da ScopeMaster para explorar nossa ferramenta de dimensionamento automatizado e orientação sobre a adoção de CFP em sua organização.

Sobre Colin Hammond

Colin Hammond é especialista em dimensionamento de software, garantia de projetos e análise automatizada de requisitos de software. Ele palestra regularmente em conferências sobre gerenciamento de projetos, testes de software, análise de negócios e análise de custos. Colin é o fundador e CEO da ScopeMaster, que fornece a premiada ferramenta automatizada de dimensionamento funcional EscopoMaster e serviços profissionais sobre como adotar e usar o dimensionamento funcional.

Graças a

Estou muito grato a Kirk Bryde (Agile Coach) e Lonnie Franks (Software Project Assurance Expert) pela valiosa contribuição editorial para este artigo.

Referências

McConnell, Steve. “Estimativa de software, desmistificando a arte negra”

Boehm, Barry et al 2000. “Estimativa de custos de software com COCOMO II”

Garmus, David e Herron, David. “Análise de Pontos de Função: Práticas de Medição para Projetos de Software Bem-sucedidos.”

Jones, Capers. “Medição de Software Aplicado: Garantindo Produtividade e Qualidade”

Symons, Carlos “Um guia para medição de tamanho de software”