Hallo Bewohner! Nur wenige Bücher über Projektmanagement sind so bedeutend wie The Mythical Man-Month. Eine Mischung aus Beispielen, Meinungen und Gedanken der realen Softwareentwicklung schafft ein lebendiges Bild der Verwaltung komplexer Projekte. Diese Aufsätze stützen sich auf Brooks fünfzigjährige Erfahrung als Projektmanager bei IBM System / 360 und anschließend bei OS / 360. Die erste Ausgabe des Buches wurde vor 45 Jahren veröffentlicht, die zweite vor 25 Jahren. Es entstehen neue Methoden, neue Programmiersprachen, die Anzahl der Prozessoren wächst, aber dieses Buch ist weiterhin relevant. Warum? Ein halbes Jahrhundert später wiederholen wir weiterhin die von Brooks beschriebenen Fehler. Einige der im Buch behandelten Themen scheinen veraltet zu sein, aber dies ist nur ein Anschein. Die grundlegenden Probleme, die dahinter stehen, sind bis heute relevant. Es ist wichtig, Ihre Vergangenheit zu kennen, um zu verstehenwo sich die Softwareentwicklungsbranche entwickelt. Daher lesen wir nach 45 Jahren Brooks. In der Welt hat sich viel verändert, aber neun Frauen können in einem Monat immer noch kein Baby gebären.
. ,
. , , , …
, , , , .
, ', , , . .
Die meisten europäischen Kathedralen wurden nach und nach gebaut, und die Teile, die von Bauherren verschiedener Generationen gebaut wurden, unterscheiden sich hinsichtlich des architektonischen Stils. Nachfolgende Bauherren waren versucht, das Design früherer zu „verfeinern“, wobei sie sich auf Veränderungen in der architektonischen „Mode“ und im persönlichen Geschmack konzentrierten. Daher stößt das friedliche normannische Querschiff * an das hoch aufragende gotische Kirchenschiff und widerspricht ihm. Das Ergebnis ist, die Herrlichkeit Gottes ebenso zu preisen wie den Stolz der Erbauer.
Vor ihrem Hintergrund steht die architektonische Einheit von Reims in großem Kontrast. Die Freude, die den Betrachter begeistert, kommt sowohl von der Integrität des Designs als auch von individuellen Vorzügen. Wie im Leitfaden angegeben, wurde diese Integrität durch die Selbstverleugnung von acht Generationen von Bauherren erreicht, von denen jede einige ihrer Ideen für die Reinheit des Gesamtentwurfs opferte. Das Ergebnis verkündet nicht nur die Herrlichkeit des Herrn, sondern auch seine Macht, sündige Menschen vor ihrem Stolz zu retten.
Während der Bau der meisten Programmiersysteme nicht Jahrhunderte dauerte, weisen sie eine weitaus schlimmere konzeptionelle Uneinigkeit auf als Kathedralen. Dies geschieht normalerweise nicht aufgrund eines Designerwechsels, sondern aufgrund der Aufteilung des Projekts in zahlreiche Aufgaben, die von vielen Menschen ausgeführt werden.
Ich bestehe darauf, dass konzeptionelle Integrität die wichtigste Überlegung in einem Systemdesign ist. Es ist besser, ein System zu haben, dem einige Funktionen und Verbesserungen fehlen, das jedoch eine Reihe von Designideen widerspiegelt, als ein System, das viele gute, aber unabhängige und inkonsistente Ideen enthält. In diesem und den nächsten beiden Kapiteln werden wir die Auswirkungen dieses Themas auf den Entwurf von Programmiersystemen untersuchen:
- Wie kann konzeptionelle Integrität erreicht werden?
- Ist dieses Argument nicht eine Entschuldigung für den Elitismus oder die Aristokratie der Architekten vor einer Horde plebejischer Implementierer, deren kreative Talente und Ideen unterdrückt werden?
- Wie kann verhindert werden, dass Architekten mit nicht implementierten oder teuren Spezifikationen ins Blaue treiben?
- Wie kann sichergestellt werden, dass der Implementierer auf jedes Detail der Architekturspezifikation aufmerksam gemacht, richtig verstanden und genau in das Produkt integriert wird?
Konzeptionelle Integrität erreichen
Der Zweck des Programmiersystems besteht darin, den Computer benutzerfreundlich zu machen. Zu diesem Zweck werden Sprachen und verschiedene Support-Tools bereitgestellt, bei denen es sich tatsächlich um Programme handelt, die von Sprachfunktionen aufgerufen und gesteuert werden. Diese Tools sind jedoch mit einem Preis verbunden: Die externe Beschreibung des Programmiersystems ist 10 bis 20 Mal größer als die externe Beschreibung des Computersystems selbst. Es ist für den Benutzer viel einfacher, eine einzelne Funktion festzulegen, aber die Auswahl ist umfangreich, und es gibt viel mehr Optionen und Formate, die berücksichtigt werden müssen.
Die Verwendung wird nur vereinfacht, wenn die in der Funktionsspezifikation gewonnene Zeit größer ist als die Zeit, die beim Assimilieren, Speichern und Durchsuchen des Referenzhandbuchs verloren geht. In modernen Programmiersystemen übersteigt dieser Gewinn zwar die Kosten, aber in den letzten Jahren scheint das Verhältnis von Gewinn zu Kosten gesunken zu sein, da immer komplexere Funktionen hinzugefügt werden. Ich bin von der Erinnerung an die Benutzerfreundlichkeit des IBM 650 heimgesucht, auch ohne Assemblersprache oder andere Software.
Da Benutzerfreundlichkeit das Ziel ist, ist dieses Verhältnis von Funktionalität zu konzeptioneller Integrität der ultimative Test für das Systemdesign. Funktionalität und Einfachheit allein definieren kein gutes Design.
Diese These wird weitgehend missverstanden. Das Betriebssystem OS / 360 wird von seinen Entwicklern als das beste bezeichnet, das jemals entwickelt wurde, da es zweifellos das funktionalste ist. Es ist die Funktionalität, nicht die Einfachheit, die für ihre Designer immer das Maß der Exzellenz war. Auf der anderen Seite wird das Time-Sharing-System des PDP-10 von seinen Entwicklern aufgrund der Einfachheit und Zurückhaltung der Konzepte als das beste bezeichnet. Die Funktionalität gehört jedoch keineswegs zur selben Klasse wie die von OS / 360. Sobald die Benutzerfreundlichkeit als Kriterium herangezogen wird, wird jeder dieser Ansätze nur auf halbem Weg zum Ziel aus dem Gleichgewicht gebracht.
Für ein bestimmtes Funktionsniveau ist das beste System jedoch eines, in dem die Dinge mit größter Einfachheit und Unkompliziertheit spezifiziert werden können. Einfachheit allein reicht nicht aus. Die Sprachen TRAC Mooers und Algol 68 erreichen Einfachheit, gemessen an der Anzahl unterschiedlicher Elementarkonzepte. Unmittelbarkeit ist jedoch nicht charakteristisch für sie. Um Ihre Absichten auszudrücken, müssen Sie häufig grundlegende Tools auf komplexe und unerwartete Weise kombinieren. Es reicht nicht aus, die Elemente und Regeln für ihre Kombination zu studieren; Es ist auch notwendig, den idiomatischen Gebrauch zu studieren, um eine ganze Reihe von Kenntnissen darüber aufzunehmen, wie die Elemente in der Realität kombiniert werden. Einfachheit und Unkompliziertheit entstehen durch konzeptionelle Integrität. Jedes Stück sollte dieselbe Philosophie und denselben Spagat widerspiegeln.Jeder Teil muss sogar dieselbe Technik in der Syntax und ähnliche Konzepte in der Semantik verwenden. Die Benutzerfreundlichkeit bestimmt daher die Einheit des Designs und die konzeptionelle Integrität.
Aristokratie und Demokratie
Die konzeptionelle Integrität erfordert wiederum, dass das Projekt von einem einzelnen Entwickler oder einer kleinen Anzahl von Entwicklern stammt, die gemeinsam und gemeinsam handeln.
Der Druck des Zeitplans erfordert wiederum die Einbeziehung von mehr Arbeitnehmern. Es gibt zwei Methoden, um dieses Problem zu lösen. Die erste ist die sorgfältige Arbeitsteilung zwischen Architektur und Implementierung. Die zweite ist eine neue Methode zur Strukturierung von Programmierimplementierungsanweisungen, die im vorherigen Kapitel erläutert wurde.
Die Trennung des Architekturaufwands von der Implementierung ist eine leistungsstarke Methode, um in großen Projekten konzeptionelle Integrität zu erreichen. Ich selbst habe gesehen, dass es mit großem Erfolg in der IBM Stretch- und System / 360-Produktlinie von Computern verwendet wurde. Und ich habe gesehen, wie es bei der Entwicklung von Operating System / 360 nicht funktioniert hat, weil es nicht genug verwendet wurde.
Mit Systemarchitektur meine ich eine vollständige und detaillierte Spezifikation der Benutzeroberfläche. Für einen Computer ist dies im Programmierreferenzhandbuch enthalten. Für den Compiler - im Sprachreferenzhandbuch. Für ein Steuerungsprogramm das Referenzhandbuch für die Sprache oder Sprachen, die zum Aufrufen seiner Funktionen verwendet werden. Für das gesamte System handelt es sich um eine Sammlung von Referenzhandbüchern, mit denen der Benutzer sein Ziel erreichen kann.
Der Systemarchitekt ist wie der Gebäudearchitekt der Benutzeragent. Zu seinen Aufgaben gehört die Verwendung von Fachwissen und technischem Wissen im Interesse des Verbrauchers und nicht im Interesse des Verkäufers, Herstellers usw. Die
Architektur muss klar von der Implementierung unterschieden werden. Wie Blaauw bemerkte: "Wo Architektur darüber spricht, was passiert, spricht die Implementierung darüber, wie es getan wird, um dies zu erreichen." Als einfaches Beispiel nennt er eine Uhr, deren Architektur aus einem Zifferblatt, Zeigern und einer Krone besteht. Wenn ein Kind diese Architektur lernt, kann es die Zeit sowohl mit seiner Armbanduhr als auch mit der Uhr auf dem Kirchturm mit der gleichen Leichtigkeit anzeigen. Die Implementierung und ihre Implementierung beschreiben, was intern geschieht: die Übertragung von Aufwand und die Kontrolle der Präzision durch jeden der vielen Mechanismen.
Beispielsweise wird in System / 360 eine separate Computerarchitektur in jedem der neun Modelle sehr unterschiedlich implementiert. Die separate Implementierung, der Datenfluss, der Speicher und der Mikrocode des Modells 30 zu unterschiedlichen Zeiten dienen wiederum vier verschiedenen Architekturen: dem System / 360-Computer, dem Multiplexkanal mit 224 logisch unabhängigen Unterkanälen, dem Auswahlkanal und dem 1401-Computer.
Die gleiche Unterscheidung gilt auch für Programmiersysteme. Die USA haben den Fortran IV-Standard übernommen. Es ist die Architektur für viele Compiler. Innerhalb dieser Architektur sind verschiedene Implementierungen möglich: In-Memory-Text oder Compiler, schnell oder optimierend, syntaktisch oder ad hoc. Ebenso ermöglicht jede Assembly- oder Jobsteuerungssprache viele Assembly- oder Scheduler-Implementierungen. Jetzt können wir das zutiefst emotionale Problem von Aristokratie und Demokratie angehen. Sind Architekten nicht die neue Aristokratie, die intellektuelle Elite, eingerichtet, um armen, hirnlosen Implementierern zu sagen, was zu tun ist? Hat diese Elite nicht alle kreativen Aktivitäten übernommen und die Darsteller nur zu Zahnrädern im Mechanismus gemacht? Können Sie nicht ein besseres Produkt bekommen?gute Ideen des gesamten Teams nach einer demokratischen Philosophie umsetzen, anstatt die Entwicklung von Spezifikationen auf einige wenige zu beschränken?
Die letzte Frage ist die einfachste. Ich behaupte nicht, dass nur Architekten gute architektonische Ideen haben. Oft kommt ein neues Konzept vom Implementierer oder vom Benutzer. Alle meine Erfahrungen überzeugen mich jedoch und ich habe versucht zu zeigen, dass die konzeptionelle Integrität eines Systems seine Benutzerfreundlichkeit bestimmt. Gute Funktionen und Ideen, die sich nicht in die zugrunde liegenden Konzepte des Systems integrieren lassen, sollten am besten beiseite gelassen werden. Wenn viele derart wichtige, aber inkompatible Ideen auftauchen, wird das gesamte System als Ganzes verworfen und die Arbeit an einem integrierten System mit anderen Grundkonzepten beginnt erneut.
Was den Vorwurf der Aristokratie betrifft, muss die Antwort "Ja" und "Nein" sein. Ja, in dem Sinne, dass es nur wenige Architekten geben sollte, sollte ihr Produkt länger halten als das Produkt des Implementierers, und der Architekt steht im Zentrum der Kräfte, die er letztendlich im Interesse des Benutzers lenken muss. Wenn das System konzeptionelle Integrität haben soll, muss eine Person die Führung übernehmen. Dies ist eine Aristokratie, die keiner Entschuldigung bedarf.
Das Entwickeln externer Spezifikationen ist ebenso kreativ wie das Entwerfen von Implementierungen. Es ist Kreativität, nur eine andere Art. Architekturbewusstes Implementierungsdesign erfordert und ermöglicht so viel Designkreativität, so viele neue Ideen und so viel technische Brillanz wie Design für externe Spezifikationen. In der Tat hängt das Kosten-Leistungs-Verhältnis eines Produkts am meisten vom Implementierer ab, ebenso wie die Benutzerfreundlichkeit am meisten vom Architekten abhängt.
Es gibt viele Beispiele aus dem Kunsthandwerk, die zu der Überzeugung führen, dass Disziplin das Handwerk verbessert. In der Tat heißt es im Aphorismus des Künstlers: "Die Form befreit sich." Die schlimmsten Strukturen sind diejenigen, deren Budget zu groß war, um den Service zu bedienen. Bachs schöpferische Tätigkeit wurde durch die Notwendigkeit, eine in ihrer Form begrenzte wöchentliche Kantate zu veröffentlichen, kaum unterdrückt. Ich bin sicher, dass der Stretch-Computer eine bessere Architektur hätte, wenn er restriktiver wäre. Die Budgetbeschränkungen des System / 360 Model 30 waren meiner Meinung nach in jeder Hinsicht für die Model 75-Architektur von Vorteil.
In ähnlicher Weise finde ich, dass das Auslagern der Architektur den kreativen Stil des Implementierungsteams eher verbessert als negiert. Sie konzentrieren sich sofort auf den Teil der Aufgabe, den niemand gelöst hat, und Erfindungen beginnen wie ein Fluss zu fließen. In einer uneingeschränkten Implementierungsgruppe geht der größte Teil des Denkens und der Diskussion in architektonische Lösungen mit kurzen Implementierungsfristen.
Dieser Effekt, den ich schon oft gesehen habe, wird von RW Conway bestätigt, dessen Gruppe in Cornell einen PL / C-Compiler für PL / 1 erstellt hat. Er stellt Folgendes fest: "Am Ende haben wir beschlossen, die Sprache ohne Änderungen und Verbesserungen zu implementieren, da die Diskussion der Sprache unsere ganze Energie in Anspruch nehmen würde."
Was soll der Implementierer während des Wartens tun?
Es ist demütigend, einen Fehler in Höhe von einer Million Dollar zu machen, aber es ist so unvergesslich. Ich erinnere mich lebhaft an die Nacht, in der wir beschlossen haben, das eigentliche Schreiben externer Spezifikationen für OS / 360 zu organisieren. Der Architekturmanager und der Manager des Steuerungsprogramms und ich haben den Plan, den Zeitplan und die Zuweisung von Verantwortlichkeiten ausgearbeitet.
Der Architekturmanager hatte 10 talentierte Leute. Er argumentierte, dass sie Spezifikationen schreiben und es richtig machen können. Dies dauert 10 Monate, drei mehr als der Zeitplan zulässt.
Der Manager für die Umsetzung des Kontrollprogramms hatte 150 Mitarbeiter. Er argumentierte, dass sie Spezifikationen in Abstimmung mit dem Architektur-Team erstellen könnten; es wäre gut gemacht und praktisch und würde in den Zeitplan passen. Wenn das Architektenteam dies tun würde, würden seine 150 Mitarbeiter 10 Monate lang untätig bleiben.
Darauf antwortete der Architekturmanager, dass, wenn ich die Verantwortung auf das Kontrollprogrammteam übertrage, das Ergebnis tatsächlich 3 Monate später und von viel geringerer Qualität eingeht. Ich habe die Verantwortung an das Implementierungsteam des Kontrollprogramms übergeben, und es stellte sich heraus, wie er sagte. In beiden Fällen hatte er recht. Darüber hinaus hat die mangelnde konzeptionelle Integrität die Erstellung und Änderung des Systems erheblich verteuert, und ich schätze, dass sich das Debuggen um ein Jahr verzögert hat.
Natürlich haben viele Faktoren diese fehlerhafte Entscheidung beeinflusst; Die überwältigenden waren jedoch zeitliche Einschränkungen des Zeitplans und ein Aufruf, all diese 150 Implementierer zur Arbeit zu bringen. Es ist dieses Sirenengesang, das mit tödlichen Gefahren behaftet ist, das ich jetzt sichtbar machen werde.
Gegen den Vorschlag, dass ein kleines Architekturteam tatsächlich alle externen Spezifikationen für einen Computer oder ein Programmiersystem schreibt, erheben die Implementierer drei Einwände:
- Die Spezifikationen sind zu funktionsreich und spiegeln nicht die praktischen Kosten wider.
- Architekten werden das ganze kreative Vergnügen haben und den Einfallsreichtum der Implementierer aufgeben.
- Zahlreiche Künstler müssen untätig zusehen, während die Spezifikationen den Engpass des Architektenteams durchlaufen.
Das erste ist eine echte Gefahr, und wir werden es im nächsten Kapitel betrachten. Die anderen beiden sind schlicht und einfach Illusionen. Wie wir oben gesehen haben, ist die Implementierung auch eine kreative Aktivität erster Ordnung. Die Fähigkeit, kreativ und erfinderisch im Design zu sein, wird geringfügig durch die Notwendigkeit eingeschränkt, innerhalb vorgegebener externer Spezifikationen zu arbeiten, und diese Disziplin kann sogar die Kreativität fördern. Dies gilt zweifellos für das gesamte Projekt.
Der letzte Einwand betrifft das Timing und die Phasen. Die schnelle Antwort lautet, Implementierer erst einzustellen, wenn die Spezifikationen vollständig sind. Im Bau arbeiten sie nach dem gleichen Prinzip.
Im Geschäft mit Computersystemen ist das Tempo jedoch schneller und jeder möchte den Zeitplan so weit wie möglich einschränken. Inwieweit können sich Spezifikation und Entwicklung überschneiden?
Wie Blaau betont, umfasst der gesamte kreative Aufwand drei verschiedene Phasen: Architektur, Implementierung und Implementierung. Es stellt sich heraus, dass sie tatsächlich parallel beginnen und gleichzeitig fortfahren können.
Beispielsweise kann der Implementierer beim Computerdesign loslegen, sobald er relativ vage Annahmen über das Referenzhandbuch, mehr oder weniger klare Vorstellungen über die Technologie und genau definierte Ziele für Kosten und Leistung hat. Er kann Datenströme, Steuerungssequenzen, grobe Verpackungskonzepte usw. entwerfen. Er entwickelt oder passt die Tools an, die er benötigt, insbesondere ein Buchhaltungssystem, einschließlich eines Entwurfsautomatisierungssystems.
Gleichzeitig sollten auf Implementierungsebene die Entwürfe von Schaltkreisen, Karten, Kabeln, Rahmen, Netzteilen und Speicher erstellt, verbessert und dokumentiert werden. Diese Arbeit verläuft parallel zur Architektur und Implementierung.
Gleiches gilt für den Entwurf von Programmiersystemen. Lange bevor die externen Spezifikationen fertiggestellt sind, hat der Implementierer viel zu tun. Mit einigen groben Vereinfachungen der Funktionalität des Systems, die schließlich in externen Spezifikationen enthalten sein werden, kann er weiterarbeiten. Es sollte klar definierte räumliche und zeitliche Ziele haben. Er muss die Konfiguration des Systems kennen, auf dem sein Produkt ausgeführt werden soll. Anschließend kann er Modulgrenzen, Tabellenstrukturen, Durchlauf- und Phasenaufschlüsselungen, Algorithmen und alle Arten von Werkzeugen entwerfen. Es sollte auch einige Zeit für die Kommunikation mit dem Architekten aufgewendet werden.
Auf der Implementierungsebene bleibt noch viel zu tun. Programmierung hat auch Technologie. Wenn die Maschine neu ist, gibt es viel zu tun, was Konventionen für Unterprogrammaufrufe, Supervisor-Technologie, Such- und Sortieralgorithmen betrifft.
Die konzeptionelle Integrität erfordert, dass das System eine einzelne Philosophie widerspiegelt und dass eine vom Benutzer sichtbare Spezifikation von mehreren Personen geschrieben wird. Aufgrund der tatsächlichen Arbeitsteilung in Architektur, Implementierung und Implementierung folgt daraus jedoch keineswegs, dass die Montage eines auf diese Weise geplanten Systems länger dauern wird. Die Erfahrung zeigt das Gegenteil: Das gesamte System konvergiert immer schneller und benötigt weniger Zeit zum Testen. Tatsächlich wurde die weit verbreitete horizontale Arbeitsteilung durch die vertikale Arbeitsteilung stark eingeschränkt, und das Ergebnis war eine radikale Vereinfachung der Kommunikation und eine verbesserte konzeptionelle Integrität.
»Weitere Details zum Buch finden Sie auf der Website des Herausgebers.
» Inhaltsverzeichnis
» Auszug
für Einwohner 25% Rabatt auf den Gutschein - Brooks
Nach Zahlung der Papierversion des Buches wird ein E-Book an die E-Mail gesendet.