Erstelle einen, der gegen den Effekt des zweiten Systems weggeworfen werden kann

Auf der einen Seite gibt es einen Rat, der besagt "Baue einen zum Wegwerfen". Erst nachdem wir ein Softwaresystem fertiggestellt und das Endprodukt gesehen haben, erkennen wir, was in der Entwurfsphase schief gelaufen ist, und verstehen, wie wir es eigentlich hätten tun sollen.

Auf der anderen Seite gibt es den "Zweitsystemeffekt", der besagt, dass das zweite System der gleichen Art, das entworfen wurde, normalerweise schlechter ist als das erste. Es gibt viele Funktionen, die nicht in das erste Projekt passten und in die zweite Version verschoben wurden, was normalerweise zu übermäßig komplexen und übermäßig konstruierten Funktionen führte.

Gibt es hier keinen Widerspruch zwischen diesen Prinzipien? Was ist die richtige Sicht auf die Probleme und wo liegt die Grenze zwischen diesen beiden?

Ich glaube, dass diese "guten Praktiken" zum ersten Mal in dem wegweisenden Buch The Mythical Man-Month von Fred Brooks beworben wurden .

Ich weiß, dass einige dieser Probleme durch agile Methoden gelöst werden, aber im Grunde ist das Problem immer noch, dass die Prinzipien immer noch bestehen. Zum Beispiel würden wir 3 Sprints vor dem Go-Live keine wichtigen Designänderungen vornehmen.

Build One To Throw kommt von "Nicht wissen, was Sie nicht wissen" am Anfang, so dass Sie lernen, wie Sie gehen, was Sie am Anfang hätten tun sollen.

Der zweite Systemeffekt entsteht aus dem Wissen, was Sie nicht wussten, aber nicht wissen, was Sie noch immer nicht wissen. Das heißt, der zweite Systemeffekt entsteht aus dem Versuch, ein größeres, glänzenderes und komplexeres System als das erste zu erstellen, ohne das Wissen benötigt zu Beginn - klingt sehr nach dem, was mit dem ersten System passiert.

Daher ist der zweite Systemeffekt kein Widerspruch. Ein zweites System mit der gleichen Funktionalität wie das erste aufzubauen, ist (meines Wissens nach) noch nie geschehen. Das zweite System muss immer "besser" sein, daher komplexer, daher werden im Wesentlichen ähnliche Probleme wie beim ersten System erwartet - das sollte weggeworfen werden.

Bauen Sie also eines, um es wegzuwerfen, werfen Sie es weg und bauen Sie es erneut, ohne den Umfang zu vergrößern, und Sie werden kein zweites Systemproblem haben. (Dies wird häufig auf Planeten mit violettem Himmel, rosafarbenem Meer und fliegenden Schweinen gemacht.)

Das Problem, auf das Sie sich beziehen, bedeutet, dass mehrere Dinge übersprungen wurden und das resultierende System einen Fehler aufwies. Lassen Sie mich einige der fehlenden Schritte beschreiben:

Qualitätsmanagement - Machen Sie es gleich beim ersten Mal richtig! Verwenden Sie niemals temporäre Hacks oder temporäre Kompromisse. Es sind keine Nacharbeiten erforderlich. Alle Ressourcen werden effizient genutzt und alles, was Sie tun, ist ein angemessener Beitrag zum Projekt.

Machbarkeitsanalyse - Entdecken Sie die Geschäftsanforderungen. Erstellen Sie einen Business Case für das Projekt.

Projektplan - Definieren Sie Ihren anfänglichen Umfang klar, planen Sie, wie die Lösung geliefert wird, erstellen Sie eine Baseline und halten Sie sich an den Plan. Verbringen Sie keine Zeit mit etwas, das sich nicht auf dem kritischen Pfad befindet.

Requirements Engineering - Ermitteln Sie Geschäftsanforderungen (dh erfassen Sie Geschäftsprozesse und bestimmen Sie, welche Geschäftsvorgänge vom Computersystem unterstützt werden sollen, und übersetzen Sie 1: 1-Geschäftsvorgänge in Systemanwendungsfälle). Validieren und verifizieren! (Bauen wir das Richtige? Bauen wir das Richtige?) Alle Anforderungen müssen mit den ursprünglichen Geschäftsanforderungen verknüpft sein.

Software-Design - Übersetzen Sie Anwendungsfälle und Domänenmodelle in Komponentendesign und Lösungsarchitektur. Alle Komponenten müssen mit den Anforderungen von RE verknüpft sein.

Implementierung - Code der Software wie im Design. Der gesamte Code muss mit Komponenten aus SD verknüpft sein.

Validierung - Komponententest, Integrationstest, Leistung, ... (alle Anwendungsfälle von RE müssen jetzt getestet werden)

Dies sind einige Schlüsselaspekte eines Softwareprozesses. Erwähnte Aktivitäten sind Teil des Software Engineerings. Auf diese Weise erstellen Sie die richtige Softwarelösung für den tatsächlichen Geschäftsbedarf und erstellen sie pünktlich, im Rahmen des Budgets und der Spezifikation.

Schauen Sie sich diese Begriffe an, um bessere Software zu erstellen und sie beim ersten Mal richtig zu machen:

• Machbarkeitsanalyse (insbesondere wie man einen Business Case erstellt)
• Projektmanagement (insbesondere Projektplan und Risikoregister mit Risikominderung)
• Requirements Engineering (Ermittlung, Analyse, Spezifikation, Validierung)
• Software Design (UML und komponentenbasiertes Software Engineering)
• Softwarekonstruktion (Entwurfsmuster, Frameworks, defensive Programmierung)
• Software-Validierung (Komponententest, UAT usw.)