Der beste Weg, um die Kosten für den Portierungscode von Sprache A nach Sprache B zu schätzen?

Lassen Sie einen Kunden darüber nachdenken, die Kosten für die Portierung eines Projekts von Sprache A nach Sprache B abzuschätzen. Wie kann eine entsprechende Aufforderung zur Einreichung von Vorschlägen am besten zusammengestellt werden?

Wenn das Ziel einfach darin besteht, eine Anwendung genau in einer neuen Sprache zu reproduzieren, würde ich vorschlagen, dass Sie Ihrem Kunden davon abraten. Die Portierung ist eines der gefährlichsten Dinge, die Sie tun können, da sich die Endbenutzer möglicherweise auf all diese Macken verlassen, die durch die Implementierung in Sprache A entstanden sind, und Sie sie plötzlich in Sprache B neu erstellen müssen . Böses Zeug. Ganz zu schweigen davon, dass die Portierung völlig gesunkene Kosten sind, auf deren Wiederherstellung sie niemals hoffen können.

Ich würde vorschlagen, das Projekt wie jedes andere zu behandeln und Anforderungen zu sammeln und zu schätzen, als ob das Original nicht vorhanden wäre. Sie werden wahrscheinlich feststellen, dass der Endbenutzer seit seiner Verwendung eine neue Perspektive auf das Produkt hat. Wenn Sie es neu schreiben, können Sie es auch verbessern.

Wenn Sie bereits über eine Perl-Codebasis verfügen, kennen Sie die Anzahl der Codezeilen (LOC). Sehen Sie nach, ob Sie einen Vergleich der Ausdruckskraft zwischen Perl und Sprache B finden. Hier ist zum Beispiel einer.

Angenommen, Sprache B ist Java. Dann beträgt der geschätzte LOC für den Port etwa das Vierfache des LOC des Originals (Ausdruckskraft 6 gegenüber 1,5).

Verwenden Sie dann so etwas wie die Construx Estimate- Software im LOC-Modus, um abzuschätzen, wie lange Sie brauchen werden (und wie viele Personen es dauern wird).

Auf diese Weise erhalten Sie Kosten- und Zeitschätzungen für das Baseballstadion sowie eine Vorstellung davon, wie wahrscheinlich es ist, dass Sie überschießen.

Wenn Sie bereits mit Sprache B vertraut sind und mehrere gemessene Projekte darin ausgeführt haben, können Sie die Construx Estimate-Software verwenden, um für Ihr Team zu kalibrieren.

Joels beliebtester Artikel , "Dinge, die Sie niemals tun sollten", sagt es am besten: Sie haben es getan, indem sie den schlimmsten strategischen Fehler gemacht haben, den jedes Softwareunternehmen machen kann:

Sie beschlossen, den Code von Grund auf neu zu schreiben.

Wenn Sie es am Ende neu schreiben, schreiben Sie es richtig und portieren Sie es nicht einfach:

• Welche Teile des Programms werden nicht mehr verwendet? Überspringen Sie diese Teile.
• Welche Teile des Programms sind am wichtigsten? Portieren Sie diese zuerst.
• Ein neues Programm, Zeit, die GUI zu aktualisieren und sie benutzerfreundlicher und "sexy" zu machen.
• Oh, wird die enorme Zeitinvestition nicht besser genutzt, um dem alten Code einfach mehr Funktionen hinzuzufügen?

Ich denke, es wird viel Zeit in Anspruch nehmen. Sie sollten sicher sein, dass es sich lohnt. Versuchen Sie, einen Teil des Codes zu übernehmen und zu portieren. Multiplizieren Sie die Dauer mit dem Verhältnis der von Ihnen portierten Codezeilen zu den gesamten Codezeilen. Es wird Ihnen eine Baseball-Figur geben, die reale wird höchstwahrscheinlich um ein Vielfaches höher sein.

Tatsächlich schreiben Sie die App erneut von Grund auf neu, haben jedoch die Anforderungen in einer anderen Sprache angegeben. Dies ist nicht trivial.

Ich denke in erster Linie, Sie sollten wirklich überlegen, ob dies eine gute Wahl ist. Was sind die Vorteile der Verwendung von Sprache B anstelle von Sprache A?

Ich denke, IBM hatte eine Untersuchung, die besagte, dass Programmierer durchschnittlich 100 LOC pro Stunde schreiben. Es gibt noch mehr in der Entwicklung als das, aber die alte Architektur ist noch geplant. Nehmen wir an, 50% schreiben den Code, da das Programm sonst noch ziemlich genau geplant ist, oder? (Es könnte sein, dass Sie ein strukturiertes Programm haben und ein objektorientiertes Programm möchten, und das wäre eine größere Aufgabe).

Wenn man jedoch 100 LOC / Stunde schreiben würde, dividiere die Menge des aktuellen LOC im System und multipliziere sie mit dem durchschnittlichen Verkauf eines Programmierers und multipliziere diese mit 2. Dies könnte eine grobe Schätzung ergeben. Nehmen Sie die Zahlen, die Sie bekommen, nicht sehr ernst. (Noch besser, nimm sie überhaupt nicht ernst). Was Sie tun möchten, hängt davon ab, wie viele Dinge einfach gemessen werden können, z.

• Die Kompetenz des Programmierers in der neuen Sprache
• Wie gut das alte Projekt dokumentiert ist
• Aus welcher Sprache wird konvertiert und in welche wird konvertiert?

Es hängt davon ab, wie viel Zeit Ihnen zur Verfügung steht. Einige Optionen:

• Keine Zeit, erledigen Sie es einfach - Nehmen Sie den Rücken einer Serviette und gehen Sie dorthin. Es ist so, als wäre es weniger als nötig, um es überhaupt zu machen, und mehr als nur, es in einer anderen Syntax neu zu tippen.
• 1-3 Tage - Finden Sie heraus, welche Überarbeitung der Architektur erforderlich sein könnte, und versuchen Sie es mit einer Schätzung. Finden Sie heraus, wie viel Logik portiert werden muss, und ermitteln Sie ein Verhältnis. Fügen Sie zusätzliche Zeit für sicherheitsrelevante Aufgaben hinzu, die Hoffnung geben, dass Sie die Sicherheit in diesem Prozess erhöht haben. Fügen Sie Zeit für Integrationstests hinzu, basierend auf der Komplexität der Arbeit und der Einfachheit Ihrer Architektur.
• 1 Monat - versuchen Sie es einmal - inszenieren Sie eine Testarchitektur und versuchen Sie, etwas zu portieren . Finden Sie heraus, welchen Bruchteil des Codes Sie portiert haben, und schätzen Sie weiter. Es ist wahrscheinlich, dass Sie auch einige Dinge herausfinden, die in der neuen Sprache völlig unmöglich waren, und es wird eine bessere Grundlage für die tatsächliche Arbeit bieten, die mit dem Übergang verbunden ist.

In einer idealen Welt würde ich dem Kunden vorschlagen, dass er für eine Ermittlungsaufgabe bezahlt, um diesen einen Monat Arbeit abzudecken, damit Sie genau das prototypisieren können, was Sie tun würden. Das gibt ihnen die Möglichkeit anzuhalten und nicht weiterzumachen, wenn die Kosten zu hoch sind. UND Sie werden immer noch für Ihre Arbeit bezahlt.

Es gibt nur einen Weg, um eine anständige Schätzung für eine Softwareaufgabe zu erhalten. Weisen Sie das verfügbare Personal zu, um einen kleinen, aber testbaren Teil der Aufgabe VOLLSTÄNDIG zu erledigen, und sehen Sie, wie lange es dauert. Teilen Sie die verbleibende Arbeit in so viele Anwendungsfälle wie möglich auf und lassen Sie die gleichen Mitarbeiter jede Iteration im Vergleich zu der bereits geleisteten Arbeit schätzen. Bitten Sie sie nicht, die Zeit zu schätzen, sondern bitten Sie sie, Ihnen zu sagen, wie sie mit der ersten Iteration verglichen wird. Dies gibt Ihnen die bestmögliche Schätzung für den Rest des Projekts.