Was ist ein guter Software-Entwicklungsplan?

Question

Beim Durchstöbern der Antworten auf SO stieß ich auf etwas, das meiner Meinung nach zu den häufigsten Missverständnissen im Softwareentwicklungsmanagement gehört: "[Softwareentwicklung] -Plan ist eine ziemlich detaillierte Beschreibung aller Aktivitäten, die Sie unternehmen müssen".

Daher die Frage: Was ist ein guter Software-Entwicklungsplan? Kann es nur zu einer Arbeitsstruktur heruntergekocht werden; Ist WBS das wichtigste für einen Softwareentwicklungsplan überhaupt?

Answer 1

Ein Softwareentwicklungsplan ist ein Plan für die Entwicklung der Software, die Sie entwickeln und bereitstellen möchten.

Während ich weiß, dass Sie junge Whippersnapper alle denken, dass das Militär ein Haufen Idioten ist, haben sie in der Tat eine Menge Erfahrung in diesem Bereich, und sie, im Gegensatz zu vielen kommerziellen Firmen, überlegten, was sein musste erledigt. Das beinhaltete eine Menge sehr schmerzhafter Lektionen über Dinge, die berücksichtigt werden müssen, dank Projekten, die fehlgeschlagen sind, weil diese Dinge NICHT berücksichtigt wurden.

Ich aktualisiere dies am 10. April 2010. Die Quelle DOD-STD-2167A, die ich zuvor aufgeführt habe, ist dunkel geworden, daher ist es sinnvoll, Sie stattdessen auf MIL-STD-498 zu verweisen. Leider wurde MIL-STD-498 im Jahr 1998 gekündigt, und das DoD erwartet nun, dass Auftragnehmer stattdessen IEEE/EIA-12207 verwenden. IEEE-Standards sind jedoch nicht frei wie in Bier.

Siehe DI-IPSC-81427A für einen Überblick über den Softwareentwicklungsplan.

Während Sie die Liste der Dinge lesen, die adressiert werden müssen, könnten Sie den Eindruck bekommen, dass einige dieser Paragraphen, wie die Vorschriften der Navy, in Blut geschrieben sind. Es gibt einen Grund für diesen Eindruck: Sie sind. Projekte scheiterten, weil sie diese Bereiche nicht rechtzeitig ansprachen.

Siehe auch http://sepo.spawar.navy.mil/SW_Standards.html: Sie können eine .zip mit dem Standard und allen Datenelementbeschreibungen (Spezifikationen für die einzelnen Dokumente) herunterladen.

(Ja, ich bin mir bewusst, dass das DoD hat sich von DOD-STD-2167A, zugunsten der IEEE kommerziellen Standards entfernt. Allerdings lädt IEEE einen Arm, ein Bein und Transplantationsrechte auf Ihrer linken Niere für ihre Standards.DOD-Standards sind frei wie in Bier)

Edit:. Fest 1. Link

Answer 2

Artifact: Software Development Plan

Der Software-Entwicklungsplan ist ein umfassende, Composite Artefakt, dass alle zu verwalten das Projekt erforderlichen Informationen sammelt. Es umfasst eine Anzahl von Artefakten, die während der Inception-Phase entwickelt wurden und wird während des gesamten Projekts beibehalten.

Software Development Plan enthält

1. Problem Resolution Plan
2. Product Acceptance Plan
3. Measurement Plan
4. Risk Management Plan
5. Quality Assurance Plan

Guidelines: Software Development Plan

Answer 3

Ein Software-Entwicklungsplan eine bestimmte Art von Projektplan ist. Während ein WBS wichtig ist, kratzt es nur an der Oberfläche.

sollte ein umfassender Projektplan hat:

1. Scope Plan (enthält die WBS)
2. Zeitplan Plan
3. Kostenplan
4. Qualitätsplan
5. Personalplan
6. Kommunikationsplan
7. Risikoplan
8. Beschaffungsplan.

Weitere Informationen zu jeder dieser Pläne können in

The project Management Body of Knowledge.

Für spezifischere guidlines gefunden werden, siehe Code Complete 2.

Answer 4

"[Software-Entwicklung] Plan ist eine ziemlich detaillierte Beschreibung aller Aktivitäten, die Sie unternehmen müssen".

Was im Allgemeinen nicht existieren kann.

Wenn Sie tatsächlich alle Anforderungen haben voll verstanden, und Sie haben alle technologischen Fragen voll verstanden, könnten Sie ein solches Dokument schreiben.

Wenn Sie jedoch etwas tun neu - etwas, das die Benutzer nicht bereits installiert haben - oder Sie verwenden eine neue Technologie, können Sie nicht einmal eine "einigermaßen" detaillierte Beschreibung der Aktivitäten bereitstellen Sie müssen sich verpflichten.

Sie können eine Übersicht zur Verfügung stellen, die einige Ihrer Aufgaben zusammenfasst. Aber während Sie die Anforderungen erkunden, werden die Benutzer Dinge entdecken, lernen und ihre Meinung ändern. Überarbeitung des Plans. Während Sie die Technologie erkunden, werden die Entwickler Dinge entdecken, lernen und den Plan überarbeiten.

Es kann nicht so schwer sein - Leute machen das die ganze Zeit.

Die Zielgruppe des Plans ist das Management. Manager wünschen eine "einigermaßen" detaillierte Beschreibung aller Aktivitäten. Wenn die Benutzer und Entwickler die Anforderungen und die Technologie kennen lernen, ändern sich die Details. Dies macht den "vernünftigen" Test sehr, sehr schwer zu erfüllen. Wenn sich die Details ständig ändern, welcher Detaillierungsgrad ist "vernünftig"?

Änderungen am Plan können (und tun) täglich eintreffen. Die meisten Manager werden den Plan nicht täglich ändern wollen. So werden zu viele Details "unvernünftig". Um einen Plan zu erstellen, der sich nicht oft ändert, muss der Plan eigentlich eine Zusammenfassung der Aktivitäten sein.Die einzige praktikable Version eines "Software-Entwicklungsplans" ist eine Reihe von Zielen, die nicht in Bezug auf die Aktivitäten definiert sind, im Hinblick auf die Funktionalität, die den Benutzern zur Verfügung gestellt wird.

Kurz gesagt, Leute tun es schlecht die ganze Zeit. In mehr als 30 Jahren Softwareentwicklung (viel davon als militärischer Subunternehmer) gibt es eine Fantasie über Planung, die einfach nicht durch die Fakten entsteht. Projekte werden mit "einigermaßen detaillierten" Plänen, zu detaillierten Plänen und ohne Plan abgebrochen.

In der Tat ist ein Plan oft der Hauptgrund für die Stornierung. Warum? Mit einer "einigermaßen detaillierten" Liste von Aktivitäten bedeutet jedes Lernen, dass der Plan falsch ist. Da der Plan von der tatsächlichen Ausführung abweicht, muss etwas falsch sein. Wirf eine Münze. Wenn Sie annehmen, dass die Ausführung falsch ist, brechen Sie das Projekt ab, weil Sie den Plan nicht befolgt haben. Wenn Sie glauben, dass der Plan falsch ist, korrigieren Sie den Plan so, dass er der realen Welt entspricht. Je detaillierter der Plan ist, desto mehr scheint er "richtig" zu sein und umso wahrscheinlicher, dass die Ausführung als fehlerhaft angesehen wird.

Untere Zeile.

Ein Softwareentwicklungsplan kann ein Fantasy-Dokument sein, das als Teil einer "Wasserfall" -Entwicklungsmethodik geschrieben wird, in der alle Arten von Dingen im Vorfeld überspezifiziert sind und Änderungen (vom Lernen im Verlauf des Teams) bestraft werden.

OR

Ein Software-Entwicklungsplan ist ein Agile burndown chart, die einfach den Sprint zeigt abgeschlossen werden. Der "vernünftige" Detaillierungsgrad ist eigentlich ziemlich niedrig - es ist nur eine Zusammenfassung. Und es ändert sich während jeder Sprint-Retrospektive.

Answer 5

, was ich fühle, dass in der Software sollte Entwicklung Projekt in zwei Teile unterteilt werden

1. Software Management
2. Software Developement

In Projektmanagement alle zusätzlichen möglichen Dinge wie Unternehmensziel, Projekt Planung, Projektüberwachung, Schätzung, Arbeitszeittabellenbuchung, Fehlerverfolgung usw. können abgedeckt werden.

Im Projekt Deve lopement, Projekt Lebenszyklus wird beibehalten wie voller Wasserfall