A melhor maneira de estimar o custo relacionado à portabilidade do código do idioma A para o idioma B?

Faça um cliente pensar em estimar o custo de portar um projeto do idioma A para o idioma B. Qual é a melhor maneira de reunir uma solicitação de proposta para fazer isso?

Se o objetivo é simplesmente reproduzir um aplicativo exatamente em um novo idioma, sugiro que você fale com seu cliente sobre isso. Portando é uma das coisas mais perigosas que você pode fazer, porque todas essas peculiaridades que surgiram porque implementado em Língua A pode ser invocado pelos usuários finais, e de repente você tem que recriá-los em Língua B . Coisas desagradáveis. Sem mencionar que a transferência é um custo completamente irrecuperável que eles nunca podem esperar recuperar.

Eu sugeriria tratar o projeto como qualquer outro e reunir requisitos e estimar como se o original não existisse. Você provavelmente descobrirá que o usuário final tem uma nova perspectiva do produto desde a sua utilização. Se você vai reescrevê-lo, é melhor fazê-lo.

Se você já possui uma base de código Perl, conhece as linhas de código (LOC) contadas. Veja se você pode encontrar uma comparação de expressividade entre Perl e Idioma B. Aqui está um, por exemplo.

Diga que a linguagem B é Java. Em seguida, o LOC estimado para a porta será cerca de quatro vezes o LOC do original (expressividade 6 versus 1,5).

Em seguida, use algo como o software Construx Estimate no modo LOC para estimar quanto tempo levará (e quantas pessoas serão necessárias).

Isso fornecerá estimativas de custo e tempo, bem como uma idéia de como é provável que você ultrapasse.

Se você já é proficiente no idioma B e já executou vários projetos medidos, pode usar o software Construx Estimate para calibrar para sua equipe.

O artigo mais popular de Joels , 'Coisas que você nunca deve fazer', diz o melhor: eles cometeram o pior erro estratégico que qualquer empresa de software pode cometer:

Eles decidiram reescrever o código do zero.

Se você acabar reescrevendo-o, reescreva-o corretamente e não apenas o porte:

• Quais partes do programa não são mais usadas? Pule essas peças.
• Quais partes do programa são mais importantes? Port estes primeiro.
• Um novo programa, hora de atualizar a GUI e tornar mais fácil o uso e mais 'sexy'.
• Ah, o enorme investimento de tempo não é melhor usado apenas para adicionar mais recursos ao código antigo?

Acho que vai demorar muito tempo. É melhor você ter certeza de que vale a pena. Tente pegar uma seção do código e portá-lo. Multiplique quanto tempo levou pela proporção das linhas de código que você portou versus o total de linhas de código. Isso fornecerá um valor aproximado, o real será mais alto em alguns múltiplos provavelmente.

Efetivamente, você está escrevendo o aplicativo novamente do zero, mas possui os requisitos especificados em outro idioma, não é trivial.

Penso, em primeiro lugar, que você realmente deve considerar se essa é uma boa escolha. Quais são as vantagens de usar o idioma B em vez do idioma A?

Acho que a IBM teve uma investigação que disse que os programadores escrevem, em média, 100LOC por hora. Ainda há mais em desenvolvimento do que isso, mas a arquitetura antiga ainda está planejada. Digamos que 50% escreverão o código, pois, caso contrário, o programa ainda está bem planejado, certo? (Pode ser que você tenha um programa estruturado e deseje um orientado a objetos, o que seria uma tarefa maior).

Mas se alguém escrever 100LOC / hora, divida a quantidade de LOC atual no sistema e multiplique pela venda média de um programador e multiplique por 2. Isso pode fornecer uma estimativa aproximada. Não leve os números que você leva muito a sério. (melhor ainda, não os leve a sério). O que você quer fazer depende de muitas coisas para medir, como:

• A competência dos programadores no novo idioma
• Quão bem documentado é o projeto antigo
• De qual idioma está sendo convertido e para o qual está sendo convertido?

Depende de quanto tempo você tem disponível. Algumas opções:

• Não há tempo, faça-o - Pegue a parte de trás de um guardanapo e vá até ele. É como ser menor do que o necessário para torná-lo em primeiro lugar, e mais do que simplesmente redigitá-lo em uma sintaxe diferente.
• 1-3 dias - descubra qual retrabalho de arquitetura pode ser necessário, avalie a estimativa. Descobrir quanta lógica deve ser portada, descobrir algum tipo de proporção. Adicione um tempo extra para tarefas relacionadas à segurança que fornecerão alguma esperança de que você tenha aumentado a segurança no processo. Adicione tempo para testes de integração com base na complexidade do trabalho e na simplicidade da sua arquitetura.
• 1 mês - experimente - realize uma arquitetura de teste e tente portar alguma coisa. Descubra qual fração do código você portou e faça uma estimativa mais detalhada. É provável que você também descubra algumas coisas que eram totalmente impossíveis no novo idioma, e isso fornecerá uma base melhor do trabalho real envolvido na realização da transição.

Em um mundo ideal, proponho ao cliente que pague por uma tarefa de investigação que cubra esse mês de trabalho para permitir que você protótipo exatamente o que faria. Isso lhes dá a opção de interromper e não avançar se o custo for muito alto. E você ainda é pago pelo trabalho que fez.

Existe apenas uma maneira de obter uma estimativa decente para uma tarefa de software. Designe a equipe disponível para executar uma parte pequena mas testável da tarefa COMPLETAMENTE e veja quanto tempo leva. Divida o trabalho restante no maior número possível de casos de uso e faça com que a mesma equipe estimar cada iteração em comparação com o trabalho já realizado. Não peça a eles para estimarem o tempo, apenas peça que eles lhe digam como ele se compara à primeira iteração. Isso fornecerá a melhor estimativa possível para o restante do projeto.