Wie viel und welche Planung wird für Softwareprojekte verwendet?

Question

Wie viel und welche Planung wird für die Softwareprojekte verwendet, die Sie oder Ihr Unternehmen entwickeln?

Der Grund für meine Frage ist wegen einer Klasse, die ich auf UML und andere ähnliche Dinge dieser Art nehme. Aus der Art, wie die Klasse aufgebaut ist, haben wir mit Programmen wie Visual Paradigm ausgiebig ein Schein-Bibliothekssystem erstellt, aber für alle bisherigen Arbeiten haben wir noch keine Programmierung gemacht (und wir beabsichtigen auch nicht, dies zu tun) Projekt).

Vielleicht ist es nur so, wie die Klasse unterrichtet wird, aber es scheint mir, dass viele der Dinge, die im Kurs gelehrt werden, sehr wuschig in der Präsentation wichtiger Planung für Softwareprojekte sind. Ich kann sehen, wie nützlich Objektdiagramme sind, aber die anderen Diagramme lassen viel zu wünschen übrig. Wie nützlich sind Sequenzdiagramme oder Zustandsdiagramme in der Praxis?

Also, wie viel und welche Planung wird für die von Ihnen oder Ihrem Unternehmen entwickelten Softwareprojekte verwendet? Ist es umfangreich oder ist es minimal? Sie vertiefen sich tief in die Planung von allem oder erhalten Sie das allgemeine Gefühl für das Projekt, bevor Sie Code schreiben?

Answer 1

Ich denke, du verwirrst Planung und Design/Architektur. Planung bezieht sich normalerweise auf die geschäftliche Seite der Dinge - wie viele Leute werden etwas in wie lange tun. Design/Architektur sollte beschäftigen, wie man Dinge richtig macht, vorausgesetzt, Sie hatten genug Zeit und Budget.

In Bezug auf das Design, die meisten Entwickler kennen UML zu einem gewissen Grad, aber nicht unbedingt verwenden. Wenn ihnen CASE-Tools zur Verfügung gestellt werden, verwenden sie möglicherweise Klassendiagramme für die individuelle Verwendung, verwenden die anderen jedoch nicht häufig. CASE-Tools erzwingen die Verwendung der "formalen Form" von UML, sodass sie ziemlich streng sind und ihre kreative Verwendung einschränken. Ein CASE-Modell wird häufig erstellt, um von der Codegenerierung zu profitieren. In meiner eigenen Firma produzieren wir eine Tonne Code, aber benutzen UML überhaupt nicht.

Für kollaboratives Design und Überprüfung (z. B. Zeichnen an der Tafel) ist UML häufiger, weil "jeder es spricht". Aus den Beobachtungsstudien, die ich gemacht und veröffentlicht habe, ist UML, die an die Tafel gezeichnet wurde, lediglich Mittel zum Zweck - Menschen leihen bestimmte Notationen aus, verwenden sie aber, um Ideen zu kommunizieren. Sie würden also Dinge wie Sequenzen und Kontrollfluss in einem Klassendiagramm sehen. Die resultierenden Artefakte können Sie nicht einfach in einem CASE-Tool erfassen. Sie können sehen, my dissertation für viele Fotos von wie diese Dinge aussehen, wenn Sie eine Gruppe von erfahrenen Entwicklern für Design zu gruppieren.

In Bezug auf die Planung ist meine Erfahrung, dass dies sehr unterschiedlich zwischen Software-Unternehmen und Unternehmen, die auch Software entwickeln. In letzterem (was die Mehrheit ist) wird die Planung auf der Makroebene oft auf der Grundlage der Unternehmenskultur und der Planung des Geschäftsstils durchgeführt, die Art von Dingen, die Sie in MBAs lernen. Es ist typischerweise nicht spezifisch für Software, und was das Management betrifft, könnten Sie Software oder Backmuffins bauen, es sind nur Zahlen. Auf der Mikroebene gibt es kein offizielles System. Tools wie Gantt-Diagramme und Tabellenkalkulationen werden verwendet, um die im Wesentlichen bestmöglichen Vermutungen und verschobenen Zeitpläne zu verfolgen. Aber am Ende kommt es auf die Erfahrung des Managements an - frühere Entwickler sind meist stärker darin. Bestimmte Praktiken wie Agile vereinfachen die Planung in mancher Hinsicht.