Quanto custa seu software, quanto tempo vai levar para terminar ?

Analise de ponto de função

É uma metodologia baseada na técnica de contagem de ponto de função, usada para dar "metros" ao seu software, e
assim poder estimar preços e prever um tempo para o término do mesmo.

Com essa técnica um software feito por mim terá X pontos de função, entenda ponto de função como uma medida, e se
eu der este mesmo software para você contar ele deverá ter estes mesmos X pontos de função que eu contei.

Com isso ele terá o mesmo "tamanho" e poderá ser cobrado igualmente, isso em si é ótimo pois os clientes poderão
escolher qual empresa fará o seu software baseado nos gastos e no tempo, cada empresa tem um preço e tempo para
um ponto de função, em geral varia de 400 reais a 750 reais e de 8 Horas/Homens a 20Horas/Homens.

Objetivos fundamentais:

 Medir a funcionalidade requisitada e recebida pelo usuário.

 Medir projetos de desenvolvimento e manutenção de software independente da tecnologia utilizada (JAVA,
.NET, COBOL ...), quer dizer antes de começar a implementação posso estimar o valor e o tempo.

Procedimento de contagem

1.1 – Contar função de dados (Referente ao projeto do banco de dados, modelo D.E.R.)

1.2 – Contar funções transacionais (Referente ao sistema , modelagem UML )

1.1 - Contar função de dados

Para realizar esta primeira contagem é necessário determinar a complexidade de cada arquivo lógico (Tabelas do banco).

A complexidade é calculada com base:

- No número de itens de dados.

- No número de registros lógicos do arquivo.

Tabela de complexidade de funções de dados.

Numero de itens de dados

De 1 a 19 De 20 a 50 51 ou +

1 è SIMPLES SIMPLES MÉDIA

2 A 5 è SIMPLES MÉDIA COMPLEXA

5 OU + è MÉDIA COMPLEXA COMPLEXA

Deverá ser feita uma classificação para cada arquivo ou Tabela, em dois tipos A.L.I. e A.I.E.

ALI è Arquivo Lógico Interno, os arquivos ou tabelas do "seu sistema".

AIE è Arquivos Interface Externa, são arquivos ou tabelas mantidos por "outros sistemas" que são acessados pela sua
aplicação.
Sistemas em avaliação è Arquivos ou BD do sistema ALI

Sistemas em avaliação è Arquivos ou BD de outro sistema, acessado pelo seu. AIE

Logo, se o arquivo em questão for SIMPLES, MÉDIA ou COMPLEXO, receberá pontos adicionais conforme a tabela:

Tipo de função SIMPLES MÉDIA COMPLEXA

ALI 7 P.F 10 P.F 15 P.F

AIE 5 P.F 7 P.F 10 P.F

Vamos a contagem de um exemplo simples.

Exemplo simples:

O diagrama abaixo ilustra um D.E.R., diagrama entidade relacionamento, com uma entidade chamada Cliente, tendo
Código , Nome , Endereço , Telefone, Tipo e Número como atributos, sendo que Telefone é um atributo multivalorado, ou
seja, poderá haver mais de um valor para o mesmo atributo.

Arquivo : Cliente (A.L.I.)

Uma tabela do próprio sistema e não externo ao sistema.

Itens de dados : 5 ( Código, Nome, Endereço, Número e Tipo)

Todo atributo exceto multivalorado pois será contado.

Reg. Lógicos : 2 (Cliente e Telefone)

A própria entidade Cliente é um Registro lógico e o atributo multivalorado Telefone também é um Registro lógico, toda
entidade e atributo multivalorado são registros lógicos.

Complexidade : SIMPLES

Olhando na tabela de complexidade de funções de dados, podemos obter esta descrição, veja, o arquivo possui 2 reg.
lógicos e 5 itens de dados , logo terá uma complexidade simples.

Então teremos:

Itens de dados : 5

Reg. lógicos : 2

Complexidade : 7 (SIMPLES em ALI , veja a tabela de complexidade)

Esta parte do sistema terá 14 P.F.

Quer dizer: Se eu cobrar R$750,00 por P.F. por esta parte obterei o equivalente a 750 * 14 igual R$10.500,00, sei que
devem estar se perguntando: Mas vale isto mesmo? Sim vale, levando em consideração que existem outras questões a
serem avaliadas. Se meu P.F. fosse R$450,00 sem os devidos ajustes custaria ao cliente R$5.600,00.

Porem a contagem do sistema não é só isto, há muitas coisas a serem observadas, que serão mostrados , como um
"ajuste" de preços.

Bem este exemplo é trivial, portanto segue-se outro.

Exemplo um pouco mais complicado:

Um DER, com três entidades e dois relacionamentos entre elas, são:

Entidades:

CLIENTE,VENDA E PRODUTO

Relacionamento:

ITEM_VENDA, FAZ ( ENTRE CLIENTE E VENDA)

E vários atributos relacionados as entidades.

O desenho abaixo ilustra este DER, logo abaixo da figura esta a analise de cada arquivo e depois uma contagem geral.
Arquivo : Cliente (A.L.I.)

Uma tabela do próprio sistema e não externo ao sistema.

Itens de dados : 21 (Todos atributos exceto os multivalorados)

Todo atributo exceto multivalorado pois será contado.

Reg. Lógicos : 6 (Email, Cliente, Referencia, Telefone, venda, Item_venda e Produto)

A própria entidade Cliente é um Registro lógico e o atributo multivalorado Telefone também é um Registro lógico, toda
entidade e atributo multivalorado são registros lógicos.

Complexidade : COMPLEXA

Olhando na tabela de complexidade de funções de dados, podemos obter esta descrição, veja, o arquivo possui 2 reg.
lógicos e 5 itens de dados , logo terá uma complexidade simples.

Então teremos:

Itens de dados : 21

Reg. lógicos : 6
Complexidade : 15 (COMPLEXO em ALI , veja a tabela de complexidade)

Esta parte do sistema terá 42 P.F.

Bem mas a contagem do sistema também têm outros aspectos , que serão abordados na segunda parte deste artigo,
será sobre o item contagem transacionais , contagem sobre as saídas e entradas do sistema. Até mais.

Quanto vale o software que você produz ?

Se você é um desenvolvedor de software , quer como consultor independente quer trabalhando em uma empresa de
desenvolvimento de software , com certeza já ouviu muitas vezes as seguintes indagações :

Quanto custa o desenvolvimento deste sistema ? ou Quanto você cobra para desenvolver este sistema ?

Qual o prazo de entrega do sistema ? ou Quanto tempo você leva para desenvolver este sistema ?

Isto é perfeitamente normal e previsível , afinal um cliente tem o direito de saber quanto vai custar e em quanto tempo
vai ficar pronto o produto que ele deseja receber.

O que não é normal é o fato de que mesmo convivendo com estas indagações no seu dia dia a tanto tempo , você , quer
como gerente de projeto ou desenvolvedor , não ter condições de responder com segurança a nenhuma delas.

Quando você contrata o serviço de um pedreiro , ele , após saber exatamente o que tem que fazer faz alguns cálculos e
lhe da o preço final do seu trabalho. O mesmo ocorre nas áreas de engenharia civil , mecânica , etc.

Por que é tão difícil estimar o valor de um projeto de software ? Por que é tão complexo fazer estimativas nesta área ?

Seria porque software não têm peso , nem cheiro ? ou seria o fato de que não vemos e nem sentimos um software ?
Creio que as respostas a estas indagações seriam feitas se você soubesse responder a seguinte pergunta:

Qual o tamanho do sistema?

Para saber o tamanho do sistema é necessário realizar medições ou medidas. Certo ?

Certo, pois, "não se consegue controlar o que não se consegue medir". (Tom DeMarco)

A métrica é o número que você vincula a uma idéia. Para o projeto de software comum , os aspectos quantitativos onde
mais precisamos usar a métrica são: escopo, tamanho, custo, risco e tempo empregado.[1]

Para que a métrica usada seja útil ela deve possuir as seguintes características: ser mensurável , ser independente, ser
explicável e precisa.

Creio que agora você concorda em que há fortes motivos para medir o seu sistema , dentre estes motivos temos:

 Fornecer subsídios para determinar o esforço, os recursos, a duração e os custos de desenvolvimento

 Avaliar a produtividade do processo de desenvolvimento adotado

 Formar uma base histórica para embasar estimativas futuras

 Indicar a qualidade do produto

Então qual a medida que você deve usar para determinar o tamanho do seu sistema ?

Tipos de medidas de tamanho de software

1- SLOC - linhas de código

Medir software contando as linhas de código (SLOC) é uma das medidas mais antigas para determinar o tamanho,
esforço e produtividade no desenvolvimento de software.

È muito fácil de usar e aplicar; basta contar a quantidade do número de linhas de código de um programa.

A medida de SLOC é considerada uma medida física do tamanho de software por medir o volume de código-fonte de um
programa.

Ela tem no entanto as seguintes desvantagens :

 Depende da linguagem de programação usada (o número de linhas de um programa Cobol é totalmente diferente
de um em Java)
 Ausência de padrões de contagem. (Cada linguagem possui suas características de sintaxe e semântica)

 Não pode ser aplicada nas fases iniciais de desenvolvimento (No início o programa ainda não esta escrito)

Nota: No site http://sunset.usc.edu/research/COCOMOII/ você pode fazer o download de um aplicativo demo da Softstar
para realizar estimativas de tamanho usando SLOC.

2- APF - Análise de Pontos por função

Podemos dizer que atualmente á a técnica mais usada para medir o tamanho de projetos de software. Foi criada por Alan
Albrecht na IBM na década de 70 e consiste em determinar o tamanho funcional (o que é entregue) do sistema através
da visão do usuário.

Ela possui as seguintes vantagens:

 Independe da tecnologia utilizada

  É simples de usar e ser entendida pelo usuário e desenvolvedores

 é consistente e intercambiável

 Pode ser utilizada desde o início do sistema.

A APF (Análise de Pontos por Função) pode ser vista como um técnica que permite dimensionar o tamanho de um
software a ser desenvolvido , melhorado ou adquirido; e também um técnica para realizar estimativas de custo e
recursos para o desenvolvimento e manutenção de software.

A utilização da APF esta normalizada em um manual de contagem de pontos de função da IFPUG (International Function
Point Users Group) constituída em 1996.

Obs: O chapter do IFPUG no Brasil é o BFPUG - Brazilian Function Point Users Group. (Constituído em 1998)

O esquema do processo de contagem de pontos por função é dado na figura abaixo:

Para que você tenha uma idéia dos PF como medida de volume de software abaixo é apresentada uma tabela que
mostra o tamanho aproximado de algumas aplicações tipos em pontos por função.[2]

Aplicação PF Aplicação PF

1. Produtos de Software 2. Sist. Comerciais Diversos

Ferramenta CASE IEF (Texas) 20.000 Imposto de Renda Pessoal 2.000

Compilador Visual Basic (Microsoft) 3.000 Contabilidade Geral 1.500

SGBD IMS (IBM) 3.500 Processamento de Pedidos 1.250

Gerenciador de TP CICS (IBM) 2.000 Recursos Humanos 1.200

Word 7.0 (Microsoft) 2.500 Suporte a Vendas 975

Excel 6.0 (Microsoft) 2.500 Preparação de Orçamento 750

MS Project (Microsoft) 3.000

Eu não vou dar detalhes sobre como usar o manual de contagem mas vou dar um exemplo de como você pode usar o
resultado obtido usando a APF para estimar esforço , prazo e custo de um software.

Vamos supor que você foi consultado sobre o desenvolvimento de um sistema cadastro de clientes onde é possível
realizar as seguintes tarefas:

 Listagem por ordem alfabética

 exportar o cadastro para outro sistema via arquivo texto

Usando o manual de contagem da APF teríamos:

ALI - 01 ( o arquivo de clientes )

AIE - 0
EE - 01 ( inclusão de cliente )
SE - 01 ( listagem por ordem alfabética )
CE - 01 ( exportar arquivo texto)

Se considerarmos todos os tipos de função como de complexidade Baixa teremos:

Pontos de função Brutos não ajustados :

PFB = ALI x 7 + AIE x 5 + EE x 3 + SE x 4 + CE x 3 = 1 x 7 + 0 x 5 + 1 x 3 + 1 x 4 + 1 x 3 = 17

Contando os fatores de ajustes teremos um total igual a 45.

Valor de fator de ajuste :

VFA = 0,65 + (0,001 x 45 ) = 1.1

Valor dos pontos de função Ajustados:

PFA = VFA x PFB = 1,1 x 17 = 18,7

Pronto !

Usando APF chegamos ao tamanho do sistema.

O seu tamanho é 18,7 pontos por função.

E agora ?
Nota: Dizer que o tamanho de um projeto é de 1000 PF nada significa. Quando podemos comparar medidas
feitas em APF é que as coisas começam a fazer sentido. Assim se temos dois projetos , um com 1000 PF e
outro com 2000 PF, podemos concluir que o segundo temo o dobro do tamanho do primeiro.

Assim como dizer que uma construção possui 400 metros quadrados de área construída não nos permite
estimar , apenas levando em conta esta medida , valor da mesma; dizer que um projeto possui 3000 PF
também não nos dá a idéia do custo do projeto.

Agora podemos estimar esforço , prazo e custo. Para isto iremos usar as seguintes considerações:

1- Considerando que uma produtividade média de 10 hs / PF.

2- Considerando que a média de jornada de trabalho é de 6 horas.

3- Considerando que o valor de uma hora de trabalho é de R$ 25,00.

Concluímos que :

Esforço = 10hs / PF = 10 x 18,7 = 187 horas

Prazo = 187 h / ( 4 x 6 ) = 7,8 dias

Custo = 187 h x R$ 25,00 = R$ 4.675,00

Foram usadas as seguintes fórmulas:

Produtividade no desenvolvimento = Horas por PF

Esforço de desenvolvimento = Produtividade(H/PF) * Tamanho(PF)
Custo de software = Tamanho (PF) * Custo(R$/PF)

Neste artigo procurei abordar de forma simples e objetiva a importância da utilização de métricas no desenvolvimento de
projetos software com a finalidade de realizar estimativas.

A métrica de software e suas implicações é um assunto muito vasto que você poderá pesquisar nos links dos sites
indicados e também em:

NESMA - http://www.nesma.nl/english/nesma&ifpug.htm
COCOMO - http://www1.jsc.nasa.gov/bu2/COCOMO.html
FATHO - http://www.fattocs.com.br/
Aplicativo para auxiliar na contagem APF - http://www.bsb.netium.com.br/mecenas/apf.htm

Por enquanto lembre-se sempre que:

"Se você não sabe para onde deseja ir, um mapa não vai lhe ajudar."
Quanto vale o seu serviço ?

Se você desenvolve um sistema e não sabe o preço que vai cobrar pelo seu serviço com certeza você já esta perdendo
dinheiro. Eu estou supondo que você é um profissional sério que optou trabalhar como desenvolvedor , analista ou
consultor free-lancer e que espera viver do seu trabalhar de forma digna e condizente.

A primeira coisa que você deve fazer é valorizar o seu trabalho , e realmente batalhar para que ele seja da melhor
qualidade possível quer como programador quer como analista ou consultor. Então não tenha receio de estipular o preço
do seu serviço , apenas faça isto de forma justa e consciente. É certo que existem muitas pessoas na área de TI que
cobram um preço muito baixo e oferecem também um serviço de péssima qualidade. Você não deve se balizar por estas
pessoas nem temer em estar cobrando um preço elevado e perder o seu cliente. Também não deve cobrar um preço
absurdo que esta muito acima do valor médio do mercado.

Então , quanto você deve cobrar ? Depende de quanto você gasta e de quanto deseja ganhar.

Primeiro você deve saber qual é o seu custo , quanto você vai gastar para realizar o serviço. Aqui você deve considerar
os custos fixos e o custo do seu trabalho. Tenha em mente que o preço deve estar compatível com a região aonde você
esta trabalhando.

A primeira coisa a fazer para calcular o preço do seu serviço é estipular o seu salário. Isto mesmo você define , por
exemplo que quer ter um salário de R$ 3.000,00 ; acrescente a este valor a carga tributária (INSS, impostos , etc.) da
ordem de 30% e teremos R$ 3.900,00. (Se você contratar mais uma pessoa para lhe ajudar você deve somar o salário
que vai pagar acrescidos dos 30%; se tiver despesas com terceiros também considere-as aqui.).

Defina o preço do seu serviço apresentando um orçamento que leve em conta a estimativa de horas que você vai gastar
para o desenvolvimento , testes e implantação do sistema. Assim se o você calculou que o sistema vai demandar 30 dias
de trabalho para desenvolvimento , 5 dias para testes e 5 dias para implantação terá no total 40 dias ; trabalhando 8
horas por dia chegamos a 120 horas. (Leve em consideração as mudanças nas regras de negócio durante o
desenvolvimento do projeto que irão com certeza ocorrer)

Para calcular o valor da sua hora de trabalho basta dividir o seu custo total pelas horas trabalhadas , ou seja: R$
3.900,00 / 120 horas ; o que nos dá um valor de R$ 32,50 a hora.

Tudo certo ? Não , esta faltando os custos fixos que você tem com água , luz , telefone , combustível , etc..Vamos supor
que este valor fique em torno de R$ 1.000,00. Vamos então calcular o valor do seu custo fixo por hora . Divida o valor do
custo fixo pelas horas trabalhadas: R$ 1.000,00 /120 horas ; pronto chegamos ao valor de R$ 8,30.

Agora some o valor da sua hora de trabalho com o valor da seu custo fixo por hora: R$ 32,50 + R$ 8,30 ; o que irá dar
um total de R$ 40,80 . Este é o valor mínimo que você deve cobrar pelos seus serviços (supondo que o valor do salário
estipulado para você esta dentro dos padrões do mercado onde você trabalha)

Então chegamos ao valor final do seu custo operacional ? Não , ainda esta faltando um detalhe. Você deve acrescentar a
este valor a margem de lucro que você deseja ganhar. Esta margem de lucro refere-se a investimentos que você com
certeza terá que fazer em equipamentos, cursos , propaganda ,etc. Para definir o percentual sonde o seu mercado de
trabalho mas creio que uma valor entre 10% e 20% seja razoável. Este valor deverá ser aplicado em cima do valor do
seu custo operacional ; calculando chegamos a R$ 46,90 ( R$ 40,80 acrescidos de 15% de margem de lucro).

Agora para calcular o valor que você deve cobrar multiplique o valor do seu custo operacional mais margem de lucro , R$
46,90, pelas horas trabalhadas no projeto e você terá o valor de R$ 5.620,00. Este é o valor que você deverá cobrar por
este serviço.

Os valores são fictícios e eu não tomei como base nenhum mercado referencial fiz apenas um exercício querendo mostrar
uma forma simples mas realista de você calcular qual o valor do seu serviço. Você pode se basear neste exemplo para
fazer os seus próprios cálculos.

Para terminar lembre-se de fazer um contrato estipulando todos os prazos e valores considerando também os acréscimos
em decorrência do atraso na entrega do projeto devido a mudanças de última hora nas regras de negócios. Se não fizer
isto pode estar trabalhando de graça.

Valorize o seu serviço e lembre-se: "Quem não quer pagar por um bom serviço com certeza não terá um bom serviço."
Os requisitos e o sucesso do seu projeto.

Antes de começar de fato este artigo, preste atenção à algumas informações:

 Mais de 30% dos projetos são cancelados antes de serem completados

 Mais de 70% dos projetos falham na entrega das funcionalidades esperadas
 A média de falhas de projetos estoura em mais de 189% do orçamento e extrapola em 222% do cronograma previsto

 Os seguintes fatores ajudam:

o Falta de informações dos usuários: 12,8%
o Requisitos/especificações incompletos 12,3%
o Ausência de gerência de mudanças e especificações 11,8%

O propósito da gerência de requisitos é estabelecer um entendimento comum entre o cliente/usuário e a equipe de

IT/desenvolvimento em relação aos requisitos do cliente/usuário.

Parece simples mas não é! O desafio é tão grande que está presente até nas especificações do CMM (Capability Maturity
Model). Além disto, estes requerimentos não ficam somente com a equipe de desenvolvimento: eles se propagam por
todo o IT. Áreas como suporte, produção, telecom e outras são impactadas pelos requisitos que têm relação somente
com aspectos internos destas áreas e que advêm dos requisitos básicos da aplicação em questão.

Os pontos onde falhamos:

1-Uma pobre gerência de requisitos:

Normalmente há a continuidade dos projetos mesmo com falhas nas informações dos usuários e sem a uma clara visão
do problema que estamos tentando resolver

2-Falhas na gerência de mudanças:

Mudanças nos requerimentos e outras modificações são inevitáveis, apesar de raramente rastrearmos e entendermos o
impacto destas mudanças

3-Controle de qualidade pobre

Temos fracas métricas de qualidade, pequeno conhecimento dos processos que afetam a qualidade, nenhum feedback
para modificar o processo após testemunharmos os efeitos de uma estratégia de desenvolvimento particular (Web por
exemplo)

4-Pequeno controle de cronogramas e custos

Planejamento cuidadoso é a exceção enquanto expectativas irreais são a norma.

Com base nestes dados acima, acho que temos tema suficiente para conversarmos.

Vamos examinar o primeiro ponto:

Uma das coisas mais comuns é a falta de entendimento entre os clientes e os analistas. Acho que todos já viram um
desenho muito comum nas áreas de desenvolvimento que mostra as várias fases de um projeto ilustrado por uma árvore
e um balanço.

As perspectivas e a visão que os vários interessados no projeto têm nem sempre estão ajustadas. E para o pessoal de TI
as coisas são um pouco mais difíceis porque o entendimento vai além de simplesmente entender qual é o negócio. Passa
por verificar quais os impactos que a nova aplicação vai trazer para o ambiente já estabelecido, quais tecnologias serão
envolvidas e etc...

Temos então vários tipos de requisitos: funcionais, de teste, de performance, de ambiente, uma gama enorme que
precisa ser gerenciada e distribuída entre a equipe de TI em suas respectivas responsabilidades.
Passa a existir um grande problema que é gerenciar os múltiplos requisitos. Não importa se você usa papel, planilha, ou
alguma ferramenta. O principal desafio é garantir os seguintes pontos:

 Você e os seus entenderam o que o cliente quer ?

 Você e os seus têm a mesma percepção do problema ?
 Você consegue compartilhar com outros os problemas que vem da solução proposta ?
 Você consegue acompanhar a execução e a implementação dos requisitos ?

Você já pensou nisto? Como resolveu? Quais foram os problemas que enfrentou? Quanto custou?

Vamos para o segundo ponto:

Temos a certeza de que vão ocorrer mudanças, sejam elas advindas do negócio, dos problemas enfrentados para sua
implementação, pela ausência de recursos ou outro motivo que os gerentes conseguem pensar sem fazer força.

O problema em questão é como acompanhá-las. Mais uma vez os recursos para fazer o acompanhamento são vários,
apesar de raramente se faz algumas análises importantes.
Entender o que cada mudança significa para cada parte do seu projeto é difícil, mas calcular o impacto que elas trazem
para o todo é quase impossível.

A análise de impacto que cada mudança traz é uma atribuição da equipe envolvida no projeto e que normalmente não
ocorre na sua total extensão. O que as pessoas fazem é calcular o tempo adicional ou alguns outros itens, sem ter
também um rastreamento de que requisitos serão atingidos com as mudanças. E normalmente de forma manual... e
sem que outras equipes de TI que vão suportar a futura aplicação tenham acesso às mudanças.

Com isto se têm uma perda de produtividade enorme. Aqueles que receberam a solicitação de mudança, seja ela
evolutiva, corretiva ou emergencial, precisam comunicar as decisões de mudanças rapidamente para os outros de forma
que haja uma diminuição da perda de recursos gastos em re-trabalhos ou conflitos. E não somente no desenvolvimento
mas no suporte, produção e etc...

Este controle de mudanças traz também outros benefícios como começar a ter um histórico do projeto para servir de
base de conhecimento para os próximos. Entender quanto tempo se investiu em determinada atividade motivada por
uma mudança e melhorar as métricas gerais. Na realidade até ter algumas informações como qual é a carga de trabalho
por elemento da equipe, quais são as solicitações em aberto, por prioridade, criticidade, tempo: bom uma infinidade de
métricas e dados podem vir desta gerência, que é barata e efetiva.

Quando chegamos a este ponto, entendemos melhor o item 3 lá atrás.

Quais são as métricas de qualidade que você usa hoje nos seus projetos?

A pergunta é dolorosa mas normalmente mostra uma realidade muito pior do que queremos ver. Normalmente temos
muito poucas e confiáveis métricas para saber onde estamos e o quanto já fizemos. É normal termos um projeto que
está 80% pronto mas só falta um pouquinho. Só que este pouquinho às vezes se torna outro projeto. Mostrei as
estatísticas no início do texto.

Gosto do que o Gartner chama de qualidade: Qualidade nos requisitos, no controle das mudanças e nos testes. Acho um
tripé bastante claro e simples e que com ele dá para fazer várias análises em relação a se estabelecer métricas e pontos
de controle.

O desafio mais uma vez é como implementar este tripé. Até mesmo porque a maioria não tem histórico para saber
quanto custo não ter.

Nos meus contatos com os clientes há uma constatação de que está havendo uma maturidade em relação ao tripé
descrito acima. Mais e mais empresas precisam ter diferenciais competitivos e rever seus processos de produção, seja no
desenvolvimento seja na produção, são fatores de aumento de lucratividade ou diminuição de prejuízos.

Há vários institutos tratando do assunto métricas e meu intento aqui é só realçar a importância de ser ter algum, mesmo
que depois se mude. Criar a consciência da importância de se medir e ter histórico que foi feito.

Independente das métricas que você pode escolher, é importante que você tenha ferramentas para fazer as duas
gerências que trato desde o início deste texto: Requisitos e Mudanças

Sempre falo sobre o custo de não se ter ou ter alguma coisa e sempre tento analisar este fato. Penso que você também
pode fazer esta mesma análise. E acho que você pode chegar a conclusões incríveis.
Agora vamos finalizar com os problemas de cronogramas e custos.

Várias vezes somos simplesmente informados de que temos uma tarefa a realizar e que temos um determinado prazo
para tal. Este prazo foi gerado a partir de um desejo, nem sempre realista.

Não temos métricas ou históricos para antecipar a duração ou o custo de determinada atividade. Nossas informações são
muitas vezes baseadas na experiência pessoal de cada um. Isto faz com que o nível de erro fique muito alto de acordo
com as estatísticas do início do texto.

Não podemos nos eximir de ter algum planejamento. Porém o como vamos fazê-lo é determinante para diminuir a
margem de erros. Os riscos associados à falta de planejamento são críticos para todo o IT, não somente para o
desenvolvimento.

O custo dos riscos é proporcional à ausência ou cuidado no planejamento. E para fazermos este planejamento é
fundamental termos todo cuidado na gerência dos requisitos e das mudanças.

Pensando simplesmente: O sucesso do projeto é proporcional à qualidade gerencial que investimos nele.