Der Mythische Arbeitsmonat: Aufsätze auf der Softwaretechnik sind ein Buch auf der Software Technik- und Projektmanagement durch Fred Brooks, dessen Hauptthema ist, dass "das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt es später macht". Diese Idee ist als das Gesetz von Brooks bekannt, und wird zusammen mit der Wirkung des zweiten Systems und Befürwortung für prototyping präsentiert.

Die Beobachtungen von Brooks basieren auf seinen Erfahrungen an IBM, während sie die Entwicklung von OS/360 führen. Er hatte mehr Programmierer zu einem Projekt hinzugefügt, das hinter Liste, eine Entscheidung zurückbleibt, die er später gegenintuitiv schließen würde, um das Projekt noch weiter verzögert zu haben. Er hat auch den Fehler des Erklärens gemacht, dass ein Projekt - das Schreiben eines ALGOL-Bearbeiters - sechs Monate, unabhängig von der Zahl von Arbeitern beteiligt verlangen würde (es hat länger verlangt). Die Tendenz für Betriebsleiter, solche Fehler in der Projektentwicklung zu wiederholen, hat Brooks dazu gebracht zu witzeln, dass sein Buch "Die Bibel der Softwaretechnik" genannt wird, weil "jeder es ansetzt, lesen einige Menschen es, und einige Menschen gehen dadurch."

Das Buch wird als ein Klassiker auf den menschlichen Elementen der Softwaretechnik weit betrachtet.

Die Arbeit wurde zuerst 1975 (internationale Standardbuchnummer 0-201-00650-2) veröffentlicht, mit Korrekturen 1982 nachgedruckt, und in einer Jahrestag-Ausgabe mit vier Extrakapiteln 1995 (internationale Standardbuchnummer 0-201-83595-9), einschließlich eines Nachdrucks des Aufsatzes "Keine Silberkugel" mit dem Kommentar vom Autor neu veröffentlicht.

Ideen präsentiert

Der mythische Arbeitsmonat

Brooks bespricht mehrere Probleme dieser Einfluss auf Terminplanung von Misserfolgen. Das am meisten fortdauernde demonstriert das Gesetz von Brooks:

Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später.

Komplizierte Programmierprojekte können in getrennte Aufgaben nicht vollkommen verteilt werden, die auf ohne Kommunikation zwischen den Arbeitern gearbeitet werden können und ohne eine Reihe komplizierter Wechselbeziehungen zwischen Aufgaben und den Arbeitern zu gründen, die sie durchführen.

Deshalb wird das Zuweisen von mehr Programmierern zu einem Projekt, das hinter der Liste läuft, es noch später machen. Das ist, weil die für die neuen Programmierer erforderliche Zeit, über das Projekt und die vergrößerte Kommunikation zu erfahren, oben eine jemals zunehmende Menge der verfügbaren Kalender-Zeit verbrauchen wird. Wenn n Leute unter sich, als n Zunahmen, ihre Produktionsabnahmen kommunizieren müssen, und wenn es negativ wird, kommt das Projekt später mit jeder Person, hat beigetragen.

• Gruppenformel der Gegenseitigen Verbindung: n (n  1) / 2
• Beispiel: 50 Entwickler geben 50 · (50 - 1) / 2 = 1225 Kanäle der Kommunikation.

Die Wirkung des zweiten Systems

Die Wirkung des Zweiten Systems schlägt vor, dass, wenn ein Architekt ein zweites System entwirft, es das gefährlichste System ist, das er jemals entwerfen wird, weil er dazu neigen wird, alle Hinzufügungen zu vereinigen, die er hervorgebracht hat, aber (wegen innewohnender zeitlicher Einschränkungen) zum ersten System nicht hinzugefügt hat. So, wenn er ein zweites System unternimmt, sollte ein Ingenieur aufmerksam sein, dass er gegen die Übertechnik es empfindlich ist.

Die Tendenz zur nicht zu vereinfachenden Zahl von Fehlern

Der Autor macht die Beobachtung dass in einem angemessen komplizierten System es gibt eine bestimmte nicht zu vereinfachende Zahl von Fehlern. Jeder Versuch, beobachtete Fehler zu befestigen, neigt dazu, auf die Einführung anderer Fehler hinauszulaufen.

Das Fortschritt-Verfolgen

Brooks hat "Frage geschrieben: Wie kommt ein großes Softwareprojekt, um ein Jahr spät zu sein? Antwort: Eines Tages auf einmal!" Zusätzliche Schlüpfrigkeiten auf vielen Vorderseiten wachsen schließlich an, um eine große gesamte Verzögerung zu erzeugen. Die fortlaufende Aufmerksamkeit auf das Treffen mit kleinen individuellen Meilensteinen ist an jedem Niveau des Managements erforderlich.

Begriffsintegrität

Um ein benutzerfreundliches System zu machen, muss das System Begriffsintegrität haben, die nur durch das Trennen der Architektur von der Durchführung erreicht werden kann. Ein einzelner Hauptarchitekt (oder eine kleine Anzahl von Architekten), dem Interesse des Benutzers folgend, entscheidet, was ins System hineingeht, und was bleibt. Der Architekt oder die Mannschaft von Architekten sollten eine Idee davon entwickeln, was das System tun und sicherstellen sollte, dass diese Vision durch den Rest der Mannschaft verstanden wird. Eine neuartige Idee durch jemanden darf nicht eingeschlossen werden, wenn sie nahtlos mit dem gesamten Systemdesign nicht passt. Tatsächlich, um ein benutzerfreundliches System zu sichern, kann ein System weniger Eigenschaften absichtlich zur Verfügung stellen, als es dazu fähig ist. Es ist nämlich so, dass, wenn ein System zu kompliziert wird, um zu verwenden, dann werden viele seiner Eigenschaften unbenutzt gehen, weil keiner die Zeit hat, um zu erfahren, wie man sie verwendet.

Das Handbuch

Was der Hauptarchitekt erzeugt, sind schriftliche Spezifizierungen für das System in der Form des Handbuches. Es sollte die Außenspezifizierungen des Systems im Detail, d. h., alles beschreiben, was der Benutzer sieht. Das Handbuch sollte verändert werden, als Feed-Back von den Durchführungsmannschaften und den Benutzern eingeht.

Das Versuchssystem

Wenn

sie eine neue Art des Systems entwerfen wird, wird eine Mannschaft ein System zum Wegwerfen entwerfen (ob es vorhat oder nicht). Dieses System handelt als ein "Versuchswerk", das Techniken offenbart, die nachher eine ganze Umgestaltung des Systems verursachen werden. Dieses zweite, klügere System sollte an den Kunden geliefertes dasjenige sein, da die Übergabe des Versuchssystems nichts als Kummer dem Kunden verursachen, und vielleicht den Ruf des Systems und vielleicht sogar die Gesellschaft zerstören würde.

Formelle Dokumente

Jeder Projektbetriebsleiter sollte einen kleinen Kernsatz von formellen Dokumenten schaffen, die die Projektziele definieren, wie sie erreicht werden sollen, wer dabei ist, sie zu erreichen, wenn sie dabei sind, erreicht zu werden, und wie viel sie dabei sind zu kosten. Diese Dokumente können auch Widersprüchlichkeiten offenbaren, die sonst hart sind zu sehen.

Projektbewertung

Wenn

man Projektdauern schätzt, sollte es nicht vergessen werden, dass die Programmierung von Produkten (der an das Zahlen von Kunden verkauft werden kann) und Programmierung von Systemen beide dreimal so hart ist zu schreiben wie innerbetriebliche Programme. Es sollte beachtet werden, wie viel der Arbeitswoche wirklich für technische Probleme im Vergleich mit administrativen oder anderen nicht technischen Aufgaben wie Sitzungen ausgegeben wird.

Kommunikation

Um Katastrophe zu vermeiden, sollten alle Mannschaften, die an einem Projekt arbeiten, im Kontakt mit einander auf so viele Weisen wie möglich — E-Mail, Telefon, Sitzungen, Merkzettel usw. bleiben. Anstatt etwas anzunehmen, sollte der implementer stattdessen die Architekten bitten, ihre Absicht auf einer Eigenschaft zu klären, die er, vor dem Fortfahren mit einer Annahme durchführt, die sehr gut völlig falsch sein könnte. Die Architekten sind dafür verantwortlich, ein Gruppenbild des Projektes zu formulieren und es anderen mitzuteilen.

Die chirurgische Mannschaft

Viel, als eine chirurgische Mannschaft während der Chirurgie von einem Chirurgen geführt wird, der die kritischste Arbeit selbst durchführt, während sie seine Mannschaft leitet, um zu helfen mit oder weniger kritische Teile einzuholen, scheint es angemessen, einen "guten" Programmierer kritische Systembestandteile entwickeln zu lassen, während der Rest einer Mannschaft zur Verfügung stellt, was rechtzeitig erforderlich ist. Zusätzlich, Bach-Musen, dass "gute" Programmierer allgemein fünf bis zehnmal so produktiv sind wie mittelmäßige. Siehe auch Organisation und Mannschaft-Muster.

Codestopp und System versioning

Software ist unsichtbar. Deshalb werden viele Dinge nur offenbar, sobald ein bestimmter Betrag der Arbeit auf einem neuen System getan worden ist, einem Benutzer erlaubend, es zu erfahren. Diese Erfahrung wird Einblicke nachgeben, die Bedürfnisse eines Benutzers oder die Wahrnehmung der Bedürfnisse des Benutzers ändern werden. Das System sollte deshalb geändert werden, um die geänderten Voraussetzungen des Benutzers zu erfüllen. Das kann nur bis zu einem bestimmten Punkt vorkommen, sonst darf das System nie vollendet werden. Zu einem bestimmten Datum sollte keinen Änderungen mehr dem System erlaubt werden, und der Code sollte eingefroren werden. Alle Bitten um Änderungen sollten bis zur folgenden Version des Systems verzögert werden.

Spezialwerkzeuge

Statt jedes Programmierers, der sein eigenes spezielles Instrumentarium hat, sollte jede Mannschaft einen benannten Werkzeugmacher haben, der Werkzeuge schaffen kann, die für den Job hoch kundengerecht angefertigt werden, dass Mannschaft, z.B, ein Codegenerator-Werkzeug tut, das auf einer Spezifizierung gestützten Code schafft. Außerdem sollten weites System Werkzeuge von einer allgemeinen Werkzeug-Mannschaft gebaut werden, die vom Projektbetriebsleiter beaufsichtigt ist.

Das Senken von Softwareentwicklungskosten

Es gibt zwei Techniken, um zu sinken, Softwareentwicklung kostet diesen Brooks schreibt über:

• Implementers kann nur angestellt werden, nachdem die Architektur des Systems vollendet worden ist (ein Schritt, der mehrere Monate nehmen kann, während deren Zeit vorzeitig gemieteter implementers nichts haben kann, um zu tun).
• Eine andere Technik, die Brooks erwähnt, soll Software überhaupt nicht entwickeln, aber einfach es "vom Bord", wenn möglich, zu kaufen.

Bibliografie

Außenverbindungen

• Frederick P. Brooks der Jüngere. Einstiegsseite
• Einleitung zur 20. Jahrestag-Ausgabe, wie gefunden, auf der Safari. Informit.com
• Organisation und Mannschaft-Muster
• Eine Rezension von Hector Correa auf Kapiteln "Der Mythische Arbeitsmonat" und "Keine Silberkugel - Essenz und Unfall"