Was ist zu planen, bevor mit der Entwicklung eines Projekts begonnen wird? [geschlossen]

Angenommen, ich habe die Spezifikationen für ein Projekt von einem Kunden erhalten, und jetzt ist es an der Zeit, mit der Entwicklung zu beginnen. Normalerweise beginne ich einfach mit dem ersten Modul (normalerweise Benutzerregistrierung) und gehe dann von einem Modul zum nächsten. Ich plane erst in meinem Kopf, bevor ich mit einem Modul beginne, wie es funktionieren soll, aber vorher gibt es keine Planung.

Ich denke jedoch, es wäre besser, wenn ich die Spezifikationen durchgehen und planen würde, wie das System funktionieren soll, bevor ich es codiere, z. B. was die Hauptkomponenten sind, wie sie interagieren sollen usw. Ich weiß nicht genau, was ich planen soll.

Um eine bessere Vorstellung davon zu bekommen, wonach ich frage, wie soll ich-

a) Teilen Sie das Projekt in Komponenten auf,

b) Planen Sie ihre Interaktionen, z. B. sollte ich Klassendiagramme erstellen, Komponententests schreiben usw.?

Irgendwelche Ideen?

Wenn Sie das Privileg haben, mit einem neuen Projekt zu beginnen, haben Sie eine leere Leinwand - was gleichzeitig aufregend und entmutigend ist. Ich arbeite in Iterationen, und so teile ich die Arbeit auf:

• Beginnen Sie mit den Zielen für das Projekt. Die Ziele sind notwendigerweise die vage, aber Sie können sich besser darauf konzentrieren, was der Kunde oder Benutzer mit der Software vorhat. Letztendlich möchten Sie diese Ziele erreichen - auch wenn das bedeutet, dass Sie einige wirklich coole Features fallen lassen müssen.
• Dann beginne ich, die Anwendung in ihre Unterdomänen aufzuteilen. Es gibt wahrscheinlich hundert verschiedene Wege, weshalb wir mit den Projektzielen beginnen. Wir möchten die Anwendung in einige verwandte Subsysteme aufteilen, die diese Ziele unterstützen. Dies hilft uns, uns auf die nächste Aufgabe zu konzentrieren.
• Identifizieren Sie, wie und wann die Subsysteme interagieren müssen. Wir kümmern uns nicht um Details, sondern nur um Informationen auf hoher Ebene, um sicherzustellen, dass wir ein integriertes System von Subsystemen haben. Sie benötigen eine allgemeine Vorstellung davon, damit Sie die Details ausarbeiten können, die die Gesamtziele des Projekts unterstützen.
• Geben Sie nur Details für das Subsystem an, an dem ich gerade arbeite (ähnlich Ihrer aktuellen Strategie). Ich weiß bereits, wie dieses Subsystem mit anderen Subsystemen interagieren muss, aber ich muss möglicherweise ein paar Alternativen ausarbeiten, damit es am sinnvollsten ist. Jedes Subsystem ist durch eine Schnittstelle getrennt, sodass ich die Implementierung so weit wie möglich anpassen kann, ohne das System als Ganzes zu beschädigen.
• Überprüfen Sie, wie die Dinge in meinem aktuellen Subsystem implementiert sind, verglichen mit der Implementierung in anderen Subsystemen. Jeder Ansatz, der nicht konsistent ist, muss der Benutzer lernen. Es ist in Ordnung, wenn wir über ein brandneues Konzept sprechen. Aus Gründen der Benutzerfreundlichkeit möchten wir nicht, dass Informationen, die vorhanden sind, auf fünf verschiedene Arten gelöscht werden, nur weil wir faul waren. Die Wiederverwendung der gleichen Benutzeroberflächenelemente ist der schnellste Weg, um die Anwendung intuitiver zu gestalten. Das Erlernen von drei Konzepten ist viel einfacher als das Erlernen von 20.

Im Wesentlichen hat mir dieser Ansatz, ein Projekt schrittweise von einem sehr hohen Niveau zu einem detaillierteren Design zu definieren, gut getan. Sogar die Interaktionen zwischen Subsystemen werden verfeinert, wenn Sie tatsächlich versuchen, sie zu implementieren. Das ist gut.

Ich denke, es wäre besser, wenn ich die Spezifikationen durchgehen würde

Richtig. Gute Idee.

plante, wie das System funktionieren würde, bevor ich es codierte.

Gut. Mach mehr davon.

was sind die Hauptkomponenten,

Ausgezeichnet.

wie sie interagieren werden,

Richtig.

Ich bin mir nur nicht sicher, was ich genau planen soll.

Wie können Sie nicht sicher sein, ob Sie bereits ein paar Sachen aufgelistet haben? Wenn das die Dinge sind, die dich betreffen, warum konzentrierst du dich dann nicht einfach auf diese Dinge?

Lesen Sie mehr zum 4 + 1-Ansichtsmodell: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Lesen Sie mehr über das Zachman-Framework: http://en.wikipedia.org/wiki/Zachman_Framework

Das ist es, was Sie planen müssen.

Wie soll ich a) das Projekt in Komponenten aufteilen,

Verwenden Sie gängige Entwurfsmuster für andere, ähnliche Projekte.

Im Zweifelsfall lesen Sie die J2EE-Pläne für Ideen.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

Wie soll ich b) ihre Interaktionen planen, z. B. Klassendiagramme erstellen, Komponententests schreiben usw.?

Ja. Gute Ideen, alle.

Das Wichtigste: Überprüfen Sie die Spezifikationen, interagieren Sie mit dem Kunden, um genauere Spezifikationen zu erhalten.

Die Anforderungen sind zweifellos unvollständig, vage oder falsch. Die größte Zeitverschwendung ist das Falsche. Kunden sind keine professionellen Softwareentwickler, und es kann nicht erwartet werden, dass sie gut darin sind, eine Reihe guter Anforderungen zu entwickeln.

Sie sollten also die technischen Daten überprüfen, den Kunden befragen und herausfinden, ob er / sie diese wirklich benötigt und möchte und sich diese leisten kann usw.

Entwickeln Sie Test- / Anwendungsfälle und überprüfen Sie diese mit dem Kunden. Wenn eine Anforderung nicht testbar ist, werfen Sie sie weg.

Entwickeln Sie das Design und stellen Sie sicher, dass alle Teile ordnungsgemäß funktionieren und theoretisch das tun, was Sie benötigen.

Entwickeln Sie einen Architekturprototyp, der die gesamte Technologie testet, die in jeder Ebene verwendet werden soll, ohne die Funktionalität zu berücksichtigen. Sie testen die Architektur, nicht die Funktionsspezifikation. Wenn Sie die falsche Architektur haben, müssen Sie alles neu schreiben. Daher ist es wichtig, die richtige Architektur zu finden. Stellen Sie sicher, dass es Ihre Anforderungen hinsichtlich Geschwindigkeit, Effizienz, Sicherheit usw. erfüllt.

Sie möchten auf jeden Fall ein Design haben, bevor Sie mit dem Codieren beginnen.

Sobald Sie das haben, bevorzuge ich normalerweise eine anfängliche Architekturphase, um zu definieren, wie Ihre App-Ebenen zusammenpassen. Dazu gehören Backbone-Dinge wie Sicherheit und Protokollierung.

Dann baue ich 1 Feature von oben nach unten, so dass Sie etwas vollständig implementiert haben.

Dann geh von dort aus.

Alles

Planen Sie alles, es ist einfacher, es auf Papier zu ändern, als wenn ein Teil davon bereits codiert ist. Sie erhalten eine hervorragende Grundlage für die Dokumentation und viele andere Vorteile.