Softwareentwicklung: 3. Warm und weich

    In einer früheren Anmerkung bin ich zu dem Schluss gekommen, dass die Softwareentwicklung ein so einzigartiges Gebiet ist, dass von „ähnlichen Bereichen“ menschlicher Aktivitäten nur gesprochen werden kann, um das Verständnis einiger der mit den Entwicklungs- und Verwaltungsstadien verbundenen Begriffe zu vereinfachen.

    Bild

    Seltsam, aber die Methoden, die direkt im Bereich der Softwareentwicklung geboren wurden, sind denen, die von außen kamen, überhaupt nicht ähnlich.

    Zum Beispiel ein ziemlich einfaches SCRUM, dessen Beschreibung leicht auf Blatt A4 passt, das CERN jedoch verwendet. Oder Agile, das in zehn Absätzen beschrieben werden kann und sehr allgemeine und idealistische Prinzipien enthält, nach denen GitHub und viele andere coole Stücke hergestellt wurden. Können sie im Bauwesen eingesetzt werden? Und beim Flugzeugbau?

    Nein, warten Sie, aber was ist mit der Zerlegung und Formalisierung von Geschäftsprozessen, ohne die es unmöglich wäre, denselben Prozess der Gebäudeplanung zu automatisieren? Aber wie steht es mit der Arbeitsplanung, ohne die es nicht möglich gewesen wäre, auf organisierte Weise tausend Tabellen, logische Strukturen und Schnittstellen für ein solches Projekt zu erstellen?

    (Zur Veranschaulichung das Gesicht der typischen universellen Methodik der Autorenschaft RuxxSilver, die auf den ersten Blick sehr attraktiv und glaubwürdig aussieht)



    Während wir am Horizont weiterhin die materielle Produktion sehen und die Zusammenhänge der Einheiten reproduzieren, aus denen sie besteht, ist all dies äußerst wichtig, um die Landschaft zu sehen und sie auf ein Skizzenbuch zu zeichnen. IDEF, UML und ein Platoon von Beratern und Business Analysten helfen uns dabei. Mit dem Verschwinden der Landschaft kommen ganz andere Prinzipien ins Spiel. Großprojekte zur Produktionsautomatisierung schlagen nicht fehl, da das Automatisierungsobjekt überhaupt nicht modelliert werden konnte. Der Betrieb eines Hochofens oder die Abwesenheit der Mitarbeiter der Abteilung sind kaum zu übersehen. Oder verstehe nicht, wie man dies im Modell widerspiegelt und was dies mit sich bringt.

    Sie scheitern und schöpfen aus dem Budget, weil die Software zu oft über Projektdetails summt und sie ablehnt. Nun, die Verbindung von einer halben Million Teilen passte nicht in das System, aber alles wurde unter der Annahme aufgebaut, dass es passen würde. Die Logik, die ausgestellte Quittung aufgrund der Beschränkungen des ursprünglichen Systems plötzlich zurückzugeben, zu schreiben, dauerte nicht 10 Mannstunden, sondern 10.000. Mehr als 19 Verknüpfungen in der Abfrage zur Datenbank haben das gesamte Berichtssystem zerstört, und das Modul eines Drittanbieters erkennt nur drei Gigabyte Arbeitsspeicher, und vier werden benötigt.

    Wenn wir die reale Welt in einem Softwareprodukt widerspiegeln, erstellen wir im Wesentlichen eine Chimäre und ihre Komponenten, die nach unterschiedlichen Gesetzen leben, unterschiedlichen Gesetzen unterliegen und in einem unvorhersehbaren Moment beginnen können, sich gegenseitig abzulehnen. Die Entwicklung einer großen universellen Datenbank unterscheidet sich grundlegend von der Erstellung einer Beschreibung der Beziehungen zwischen Fahrzeugteilen. Leider verwechseln viele Manager dies öfter als wir möchten.

    Jede spezifische Organisation mit ihren spezifischen Produkten und ihrer Arbeitsweise löst das Problem der Chimäre auf ihre eigene Weise. Es entstehen sehr komplexe Methoden, die eine gemeinsame Eigenschaft haben: Sie hören auf zu funktionieren, wenn sie die Schwelle des Vorläuferunternehmens überschreiten.

    Sagen Sie mir nur ehrlich, wer setzt RUP erfolgreich ein, damit es mehr als eine Reihe allgemeiner Prinzipien sind, die auf ein Blatt Papier passen? In meinem Regal liegt ein Buch über RUP und ein paar weitere in elektronischer Form. Leider heißt es nicht, wer das tut. Das Internet hat mir auch nicht sehr geholfen, diese Frage zu beantworten.

    Beim Überschreiten der IBM-Schwelle wird er wie ein Ball weggeblasen und verliert alles, was ihn von viel informelleren Methoden unterscheidet. In einem formalisierten Projekt, das stark mit der realen Welt verbunden ist, verliert es fast immer an Methoden, die zumindest einen Teil der Entwicklung in eine vollständig formalisierte Kaskade verwandeln und nicht an sehr spezifische Softwareprodukte, ihre Stärken und Schwächen gebunden sind.

    Vielseitigkeit ist nicht immer gut, aber es hört sich immer gut an.

    Wenn wir einen Hund ausbilden wollen, werden wir auf eine Art und Weise handeln. Wenn wir mit dem Auto irgendwohin wollen - zu einem anderen. Und Sie sollten sich keine allgemeinen Prinzipien für die Lösung dieser beiden Probleme einfallen lassen, nur weil im ersten und zweiten Fall jemand etwas kontrolliert.

    Wenn wir ein Softwareprodukt erstellen, beschäftigen wir uns hauptsächlich mit den abstrakten Entitäten, aus denen es besteht, den externen Schnittstellen und der Hardware- und Softwareumgebung, in der es vorhanden ist.

    Wenn wir die reale Welt modellieren, beschäftigen wir uns mit ihren Objekten, ihren messbaren Eigenschaften und ihren Beziehungen.

    Ein Softwareprodukt kann vorschlagen, dass ein Modell eines bestimmten Teils der realen Welt darin eingebettet wird. Die reale Welt kann wiederum so beschrieben werden, dass ihr Modell leichter in das Programm eingegeben werden kann.

    Wenn wir dies für identisch halten, beginnen wir warm und weich zu verwirren.

    Zumindest wegen eines Konflikts, der die Natur der Informationstechnologie betrifft. Ein Computer und seine Programme sind ein Kind von Computersystemen (insbesondere der statistischen Verarbeitung) und eines Kopiergeräts.

    Zum Beispiel: Wenn wir uns mit der Klassifizierung und Verwaltung von Steinen befassen möchten, müssen wir eine Steinklasse oder eine Tabelle in der Datenbank erstellen, die die Steine ​​beschreibt.

    In der günstigsten Form werden die Steine ​​vereinheitlicht: Stein Nr. 1, Stein Nr. 2, Stein Nr. 3 ... In der realen Welt gibt es keine identischen Steine. Um alle Steine ​​zu beschreiben, müssen Sie sie vollständig reproduzieren. Wir können viele Steine ​​in unser System einführen, die nach Gewicht gruppiert sind, und aus ihrer Sicht wird die Einheitlichkeit der Steine ​​stark abnehmen, und es wird uns leichter fallen, festzustellen, zu welcher Gruppe ein bestimmter Stein in der realen Welt gehört. Für einige Aufgaben kann die Angabe hilfreich sein, ob diese Gruppe von Steinen in einen LKW passt. Die Frage ist, welcher Detaillierungsgrad sinnvoll ist und wie viel dieser Nutzen mit den Kosten verbunden ist.

    Je zirkulierender und unspezifischer ein Objekt ist, desto einfacher ist es, Informationen darüber zu verarbeiten. Und je weniger Arbeit erforderlich ist, um Software zu erstellen, die diese verarbeitet und konvertiert.

    Und wenn wir wirklich universelle Methoden beanspruchen wollen, müssen wir höchstwahrscheinlich nach ihren Grundprinzipien suchen, ausgehend von der Mengenlehre. Solche Versuche bilden nun einen derart komplexen Apparat, dass er nur mikroskopische Anwendung in der Risikobewertung und in Projekten sehr spezifischer Expertensysteme findet. In der Praxis können sie in Form einer „launischen“ Black Box verwendet werden, deren Meinung berücksichtigt wird, wenn die Autorität aller anderen Meinungen zweifelhaft ist.

    Zusammenfassend: Es gibt verschiedene Ziele, und in Übereinstimmung mit diesen gibt es einige Prinzipien: wie man gute Software schreibt, wie man Modelle der realen Welt erstellt und wie man aus dem Ergebnis wirtschaftlichen Profit zieht. Wenn jemand behauptet, diese Dinge mit universellen Methoden zu mischen, dann bezieht sich dies auf die Zone wirtschaftlicher Ziele, denn „universal“ klingt cool und verkauft sich besser als „nicht universal“.

    Eine universelle Anwendbarkeit für verschiedene Organisationen und Projekte ist nicht möglich. Je höher der Grad einer solchen Portabilität ist, desto ähnlicher ist die Technik einem kompakten Code von vagen Empfehlungen.

    Die schlechte Nachricht: Sie müssen sich selbst für Ziele entscheiden, nach Kompromissen suchen, optimale Ergebnisse erzielen und heimtückische Fragen wie „Brauchen wir einen guten Code?“ Beantworten. Die Wahrscheinlichkeit eines schönen Wasserfallprozesses wie beim Bau ist auf absehbare Zeit nicht gegeben.

    Mit abnehmendem Marktwachstum und zunehmendem Wettbewerb innerhalb der einzelnen Teilbranchen werden persönliche Entscheidungen bestimmter Personen mit persönlicher Verantwortung eine immer wichtigere Rolle spielen. Das Management der Softwareentwicklung wird nicht aussterben, aber die meisten vorhandenen IT-Manager mit ihren Ansätzen werden aussterben oder professionell wachsen. Der Rest wird entscheiden, dass die Branche für sie in Bezug auf eine leichte Karriere und Geld vielversprechend geworden ist und verschwinden wird. Es ist unwahrscheinlich, dass wir dabei etwas verlieren werden.

    Und wenn uns ein junger IT-Projektmanager oder Leiter eines Entwicklungsteams als wirklich junge Leute im Alter von 15 bis 30 Jahren erscheint, dann fällt ein junger Architekt (der Gebäude entwirft) in die Altersspanne von 30 bis 45 Jahren und eröffnet zuerst das Album „20 junge Architekten“ Ihr Gedanke wird sein: "Und wer sind all diese alten Fürze?!". Nur weil 5-7 Jahre Studium und 10 Jahre Praxis nicht ausreichen, um selbst Chruschtschow gut zu designen.

    Im nächsten Artikel möchte ich die Stärken solcher Konzepte, die wir als Kunden und Anforderungen geerbt haben, weiter unten erläutern.

    Jetzt auch beliebt: