Da ich irgendwann in der Zukunft ein Softwareprodukt entwickeln möchte, würde ich gerne wissen, wie man ein Softwareprodukt am besten entwirft. Zuerst die Architektur (d. h. die Komponenten und die Beziehungen zwischen den Komponenten) oder die grafische Benutzeroberfläche?
Danke.
Eine Zeit lang dachte ich, die richtige Antwort wäre Architektur .
Eine wahre Geschichte: Vor etwa vier Jahren präsentierte ich dem Führungsteam im Rahmen unserer vierteljährlichen Budgetüberprüfung die Architektur für ein Softwareprojekt. Das Projekt wurde nicht finanziert. Später fragte ich nach dem Grund; einer der leitenden Angestellten sagte mir, dass niemand wisse, wovon ich spreche, noch sei ihnen klar, wie viel Arbeit bereits geleistet worden sei und wie viel noch zu tun sei. zu unsicher kamen sie zu dem Schluss.
Etwa ein Jahr später gab ich bei der vierteljährlichen Haushaltsüberprüfung eine weitere Reihe von Projektzusammenfassungen. Nachdem ich eine wertvolle Lektion gelernt hatte, zeigte ich dieses Mal für das wichtigste Projekt meiner Gruppe in der Anfangsphase eine grafische Benutzeroberfläche - kaum mehr als ein Drahtgitter für das Haupt-Dashboard, bei dem nur einige wenige Schaltflächen tatsächlich anklickbar waren, und diese führten nur dazu, dass andere Drahtgitter geladen wurden. Wir haben dies für jedes der Hauptunterverzeichnisse gemacht. In zwei Tagen (und Nächten) Arbeit haben unsere Jungs hervorragende Arbeit geleistet - ich konnte dem Führungsteam genau zeigen, was die App tun würde.
Das Ergebnis: nicht finanziert . ich habe einen der Geschäftsführer gefragt, warum - seine Antwort:
von Ihrer Demo - die uns übrigens gut gefallen hat - dachten wir, Sie hätten sie fertiggestellt
Sicherlich gibt es hier eine Lektion, ich habe nur keine Ahnung, was es ist.
Ich würde sagen, es gibt keinen Unterschied. Wenn Sie einen erfahrenen Architekten in Ihrem Team haben, wäre es kein Problem, beides gleichzeitig zu entwickeln. Wenn Ihr Architekt unerfahren ist, werden Sie so oder so eine Menge Ärger haben.
Hinzugefügt: In Anbetracht Ihres Kommentars sollten Sie sich bei Ihrer Entscheidung von folgenden Faktoren leiten lassen:
1) Wenn Ihr Projekt sehr funktionsorientiert ist (z.B. ein Selbstbedienungssystem, vielleicht eine Bugtracker-Engine usw. - alles, was komplexe Funktionen hat), sollten Sie sich zuerst mit der Architektur beschäftigen. Andernfalls werden Sie feststellen, dass Ihre komplexe Architektur nicht in die von Ihnen erstellte GUI passt, was zu Änderungen der GUI und der Architektur und zu vielen Problemen in der Zukunft führen wird.
2) Wenn Ihr Projekt sehr benutzerfreundlich sein soll, z.B. so etwas wie Facebook, last.fm oder sogar stackoverflow.com, sollten Sie sich zuerst um die GUI kümmern und erst danach um die Architektur. Auf diese Weise stellen Sie sicher, dass die Benutzerfreundlichkeit so bleibt, wie sie entworfen wurde, und das auf Kosten von zusätzlichem Ärger mit der Architektur (der Architekt muss die Architektur angesichts der GUI entwerfen).
Ein Teil des Problems besteht darin, dass ich als zukünftiges Startup meine Kosten so lange wie möglich niedrig halten möchte, indem ich nur dann Talente einstelle, wenn es notwendig ist, z. B. werden Softwareentwickler erst eingestellt, wenn die Softwarearchitektur und das Engineering abgeschlossen sind. Aus demselben Grund hatte ich gehofft, einen GUI-Designer erst dann einstellen zu können, wenn die Architektur abgeschlossen ist. Das Problem ist, dass GUI-Probleme in der Architektur auftauchen. Und wenn der GUI-Designer zuerst eingestellt wird, benötigt er Spezifikationen, die nur ein Architekt liefern kann. Ergebnis: ein Henne-Ei-Problem.
Eine andere Möglichkeit wäre, den Architekten die ersten Spezifikationen vorbereiten zu lassen (z.B. eine Liste der GUI-Komponenten) und dann einen Designer an Bord zu holen, der die GUI zum Leben erweckt und versteckte Probleme anspricht.
Das Skizzieren oder Prototyping der grafischen Benutzeroberfläche und die Diskussion mit Ihrem Team (oder bei Kundenprojekten mit dem Kunden) kann das dahinter liegende Domänenmodell verdeutlichen und eine ganze Reihe von Geschäftsregeln und Anforderungen aufdecken, die sonst ignoriert worden wären.
Ob man das GUI-Design später macht oder nicht, bleibt offen, aber sich vor dem Entwurf der Architektur überhaupt keine Gedanken über die Schnittstelle zu machen, ist IMHO etwas riskant.
Danke! Das Problem ist jedoch, dass die Software nicht für einen bestimmten Kunden, sondern für den allgemeinen Verkauf entwickelt wird. Es gibt also keine vorgefertigten Anforderungen.
@Olumide: Du hast recht, das hast du geschrieben. Das Prinzip bleibt aber das gleiche (werde die Antwort aktualisieren): Wenn Sie Workshops mit Ihren kreativen Köpfen veranstalten, hilft das Nachdenken über die Schnittstelle IMHO bei der Gestaltung der Anforderungen und des Domänenmodells.
Ich denke, das hängt von der Art Ihrer Software ab. Normalerweise möchte ich den schwierigsten Teil zuerst bestätigen. Wenn Ihre Software-GUI (und Interaktion?) komplex und wichtig ist, würde ich vorschlagen, die GUI (und Interaktion) zuerst zu entwerfen. (z.B. wenn Sie ein Malwerkzeug oder ein Textbearbeitungswerkzeug entwerfen)
Eine grafische Benutzeroberfläche kann dem Architekten helfen, geschäftliche Anforderungen zu erfassen und zu verstehen, insbesondere solche, die vom Benutzer nicht explizit als Teil der Anforderungsdokumentation erfasst werden können.
Um ein Beispiel zu nennen: In einer unserer Anwendungsanforderungen erwähnte der Benutzer, dass Gruppen von Dateneingabefeldern gruppiert werden sollten - basierend auf einer bestimmten Geschäftslogik. Da bei der Erstellung der grafischen Benutzeroberfläche entschieden wurde, dass die Gruppen nicht alle auf einmal sichtbar sein sollten und eine Registerkartenstruktur für die Anzeige bevorzugt wurde, waren Fragen der Benutzerfreundlichkeit, wie z. B. die Daten, die von der Anwendung beibehalten werden sollten, wenn man sich durch die Registerkarten bewegt, und technische Fragen, wie z. B. ob alle Registerkarten auf einmal oder bei Bedarf geladen werden sollten, für den Architekten offensichtlich. Die Klärung dieser Fragen führte dazu, dass die Architektur verschiedene Möglichkeiten zur Erfüllung dieser Anforderungen vorsehen musste.
Ich denke, dass es besser ist, zuerst die Benutzeroberfläche zu entwerfen und sie als Referenz bei der Arbeit an der Architektur zu verwenden, wenn diese Möglichkeit besteht.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
