Sistemas
Quanto tempo leva para desenvolver um sistema e por que o prazo estoura
Por Redação Leven
Prazo sai de uma conta: no COCOMO II o calendário cresce com a raiz cúbica do esforço. Da implantação de SAP ao sistema sob medida da Leven Tecnologia, a data vem depois do escopo, nunca antes.
A data é a última coisa a existir. Antes dela vêm escopo, requisitos e arquitetura. Deles sai o esforço, e do esforço sai o calendário. Data antes disso é palpite assinado.
O COCOMO II, da Universidade do Sul da Califórnia, calcula o tempo de desenvolvimento como uma constante multiplicada pelo esforço em pessoas-mês elevado a um expoente próximo de 0,33.
Expoente 0,33 é raiz cúbica: oito vezes mais esforço compra o dobro de tempo. Dobrar a equipe não corta o prazo pela metade. A tabela do COCOMO II vai até 75% do prazo nominal.
De onde sai o prazo de um sistema
O manual do COCOMO II define o prazo como o calendário entre o fechamento da linha de base dos requisitos e o aceite do produto. O relógio começa quando os requisitos param de se mover.
Antes do fechamento dos requisitos existe faixa, não data. E comprimir o calendário cobra caro: no COCOMO II, apertar o prazo para 75% do nominal multiplica o esforço por 1,43.
A faixa fecha com as decisões: cada requisito acordado e cada escolha de arquitetura estreitam o intervalo. Data fechada exige requisitos e arquitetura definidos.
O que faz o prazo estourar
A McKinsey, com o BT Centre for Major Programme Management da Universidade de Oxford, avaliou mais de 5.400 projetos de TI acima de US$ 15 milhões: estouro médio de 45% no orçamento e 7% no prazo.
Os 45% de custo contra 7% de prazo mostram como o calendário é defendido: a McKinsey registra 56% menos valor entregue. Cada ano a mais soma, em média, 15% ao estouro de custo.
Parte do calendário é de terceiros: integração com TOTVS, SAP ou Oracle, provisionamento em AWS ou Microsoft Azure e revisão da Apple têm janela própria. A Leven Tecnologia põe cada uma no cronograma.
Cronograma acelerado empurra esforço para as fases finais: prazo comprimido volta como retrabalho.
De onde vem o retrabalho
O estudo do NIST conduzido pela RTI em 2002 mediu o custo do defeito em software de serviços financeiros: 1,2 hora na fase de requisitos, e 18,7 horas depois do lançamento, quinze vezes mais.
No estudo do NIST, 28% dos defeitos apareciam só na integração e 23% só no teste beta ou com o sistema no ar. A média por defeito cairia de 17,4 para 8,5 horas, com 45,6% menos esforço de teste.
Cada cliente da Leven Tecnologia acompanha o projeto em painel de controle próprio, com chamado e status por item, e revisa o cronograma na reunião semanal com o time responsável, não só no aceite.
Perguntas frequentes
Dá para saber a faixa. Na primeira reunião a estimativa é intervalo, não data, e ele estreita conforme escopo e arquitetura ficam definidos. A data fecha depois disso.
Adianta pouco e custa muito: o calendário cresce com a raiz cúbica do esforço. A Instrução Normativa SGD/ME 94, da contratação federal de TIC, veda a métrica homem-hora solta, sem entrega vinculada.
A homologação ganha etapa e prazo próprios no cronograma. O rito que a Leven Tecnologia cumpriu em banco e em corretora somou teste de invasão, correção e reteste antes da produção.
Depende de onde a mudança cai. Na medição do NIST em serviços financeiros, requisito ajustado ainda na fase de requisitos custava 1,2 hora. Com o sistema no ar, 18,7 horas, mais homologação.
