Software-Entropie erklärt: Ursachen, Auswirkungen und Abhilfemaßnahmen

Dieser Artikel richtet sich an Softwareentwickler oder Projektmanager, die wissen möchten, was Softwareentropie ist, welche praktischen Auswirkungen sie auf ihre Arbeit hat und welche zugrunde liegenden Faktoren zu ihrem Wachstum beitragen.

Primäres Ziel ist es, ein Bewusstsein für die Softwareentropie zu schaffen, da diese ein Faktor in allen Formen der Softwareentwicklung ist. Darüber hinaus erforschen wir eine Möglichkeit, der Software-Entropie einen konkreten Wert zuzuordnen. Nur wenn wir die Software-Entropie quantifizieren und ihr Wachstum über aufeinanderfolgende Releases beobachten, können wir das Risiko, das sie für unsere aktuellen Ziele und Zukunftspläne darstellt, wirklich verstehen.

Was ist Software-Entropie?

Die Software-Entropie hat ihren Namen von der Haupteigenschaft der Entropie in der realen Welt: Sie ist ein Maß für Chaos, das entweder gleich bleibt oder mit der Zeit zunimmt . Anders ausgedrückt, es ist ein Maß für die inhärente Instabilität, die in ein Softwaresystem eingebaut ist, in Bezug auf dessen Änderung.

Leider wird der Softwareentropie selten die Bedeutung beigemessen, die sie verdient.

Es wird nicht berücksichtigt, wenn jemand aus einem Entwicklungsteam abgezogen wird, ein Entwicklungszyklus vorzeitig gestartet wird oder „Schnellkorrekturen“ implementiert werden – Momente, in denen es tatsächlich am wahrscheinlichsten ist, dass es wächst.

Softwareentwicklung ist eine Kunst und ein Beruf, deren Kernbausteine ​​schlecht definiert sind. Während Baumeister mit Zement und Nägeln arbeiten, arbeitet der Softwareentwickler mit logischen Behauptungen und einer Reihe von Annahmen. Diese können nicht in der Hand gehalten und untersucht werden, noch können sie auf den Achtelzoll bestellt werden. Obwohl der flüchtige Beobachter versucht sein mag, Softwareentwicklung mit Konstruktion zu vergleichen, ist dies abgesehen von ein paar oberflächlichen Ähnlichkeiten kontraproduktiv.

Trotz dieser Schwierigkeiten können wir dennoch die Richtlinien aufstellen, die es uns ermöglichen, die Quellen der Softwareentropie zu verstehen, das Ausmaß des Risikos zu messen, das sie für unsere Ziele darstellt, und (falls erforderlich) welche Schritte unternommen werden können, um ihr Wachstum zu begrenzen.

Die vorgeschlagene Definition der Softwareentropie lautet wie folgt:

wobei I von der Anzahl der unerwarteten Probleme abgeleitet wird, die während der letzten Entwicklungsiteration eingeführt wurden, C die wahrgenommene Wahrscheinlichkeit ist, dass die Implementierung von Änderungen am System jetzt zu einem neuen I > 0 führt, und S der Umfang der nächsten Entwicklungsiteration ist. Im Allgemeinen werden Werte von E unter 0,1 als gut angesehen. Ein E von 0,5 gilt als hoch, und Werte über 1,0 sind überwältigend.

Das Konzept einer Entwicklungsiteration ist ein wesentlicher Bestandteil unseres Verständnisses von Softwareentropie. Dies sind Aktivitätszyklen, die von einem Verhalten des Systems zu einem anderen führen. Die Ziele, die wir uns während der Software-Iteration setzen, werden als Scope bezeichnet. In der Softwareentwicklung beinhalten solche Zyklen das Ändern oder Erweitern des zugrunde liegenden Codes der Software.

Alle Änderungen am Code treten in einer Entwicklungsiteration auf, auch wenn diejenigen, die sie ausführen, nicht so darüber denken. Das heißt, kleinere Organisationen, die stolz darauf sind, ihre Systeme mit einer „Quick and Dirty“-Methode aufzubauen – mit wenig oder gar keiner Erfassung von Anforderungen oder Analysen – verwenden immer noch Entwicklungsiterationen, um ihre Ziele zu erreichen. Sie planen sie einfach nicht. Auch wenn das Verhalten eines modifizierten Systems in irgendeiner Weise von unseren Absichten abweicht, wurde es dennoch durch eine Entwicklungsiteration erreicht.

Tatsächlich ist das Risiko, dass dies geschieht, genau das, was unser Bewusstsein für die Software-Entropie erklären und unser Wunsch, sie zu messen, begrenzen soll. In der Praxis können wir Software-Entropie also wie folgt definieren.

Jedes gegebene System hat eine endliche Menge bekannter, offener Probleme I ₀ . Am Ende der nächsten Entwicklungsiteration wird es eine endliche Menge bekannter, offener Probleme I ₁ geben. Die inhärente Entropie des Systems gibt an, wie stark unsere Erwartung von I ₁ wahrscheinlich von seinem tatsächlichen Wert abweicht und wie stark der Unterschied in nachfolgenden Iterationen wahrscheinlich anwächst.

Auswirkungen der Software-Entropie

Unsere praktische Erfahrung mit den Auswirkungen der Software-Entropie hängt davon ab, wie wir mit dem betreffenden System interagieren.

Benutzer haben eine statische Ansicht der Software; Sie kümmern sich darum, wie es sich jetzt verhält, und kümmern sich nicht um die Interna eines Systems. Durch das Ausführen einer vordefinierten Aktion gehen die Benutzer davon aus, dass die Software mit einem entsprechenden vordefinierten Verhalten reagiert. Allerdings sind die Nutzer am wenigsten bereit, auf den Entropiegrad der von ihnen verwendeten Software zu schließen.

Die Softwareentropie ist an den Begriff der Veränderung gebunden und hat in einem statischen System keine Bedeutung. Wenn keine Absicht besteht, das System zu verändern, können wir nicht von seiner Entropie sprechen. Ebenso hat ein System, das noch nicht existiert (dh die nächste Iteration ist tatsächlich die erste seiner Existenz), keine Entropie.

Software mag vom Standpunkt eines Benutzers aus als „fehlerhaft“ empfunden werden, aber wenn Softwareentwickler und -manager während nachfolgender Iterationen ihre Ziele wie geplant erreichen, müssen wir daraus schließen, dass die Entropie im System tatsächlich ziemlich niedrig ist! Die Erfahrung der Benutzer sagt uns daher, wenn überhaupt, nur sehr wenig über die Software-Entropie:

• Softwareentwickler haben eine fließende Sicht auf Software. Sie befassen sich nur damit, wie ein System derzeit funktioniert, soweit es geändert werden muss, und sie befassen sich mit den Details seiner Funktionsweise, um eine geeignete Strategie zu entwickeln.

• Manager haben vielleicht die komplizierteste Sicht auf Software, sowohl statisch als auch fließend. Sie müssen die kurzfristigen Erfordernisse mit den Anforderungen eines weiter in die Zukunft reichenden Geschäftsplans in Einklang bringen.

Menschen in diesen beiden Rollen haben Erwartungen. Software-Entropie manifestiert sich immer dann, wenn diese Erwartungen verdorben werden. Das heißt, Softwareentwickler und -manager geben ihr Bestes, um Risiken einzuschätzen und einzuplanen, aber – wenn ihre Erwartungen dennoch enttäuscht werden – abgesehen von externen Störungen – können wir von Softwareentropie sprechen. Es ist die unsichtbare Hand, die Komponenteninteraktionen unterbricht, die nicht im Umfang waren, Produktionsserver unerklärlicherweise zum Absturz bringen und einen zeitnahen und kostengünstigen Hotfix zurückhalten.

Viele Systeme mit hoher Entropie sind auf bestimmte Personen angewiesen, insbesondere wenn es jüngere Mitglieder des Entwicklungsteams gibt. Diese Person verfügt über ein solches Wissen, dass die anderen ihre Aufgaben ohne seinen „wertvollen“ Beitrag nicht erfüllen können. Es kann nicht in Standard-UML-Diagrammen oder technischen Spezifikationen erfasst werden, da es aus einer Mischung von Ausnahmen, Ahnungen und Tipps besteht. Dieses Wissen hängt nicht von einem logisch konsistenten Rahmen ab und ist daher schwierig – wenn nicht gar unmöglich – auf andere zu übertragen.

Nehmen wir an, dass eine solche Organisation mit großer Entschlossenheit und Anstrengung in der Lage ist, sich umzudrehen und ihre IT-Abteilung zu stabilisieren. Die Situation scheint sich verbessert zu haben, denn wenn die Softwareentwicklung ins Stocken gerät, ist jeder Fortschritt ermutigend. Doch in Wirklichkeit sind die erfüllten Erwartungen gering und die Errungenschaften uninteressant im Vergleich zu den hochgesteckten Zielen, die bei noch geringer Entropie zum Greifen nah waren.

Wenn die Softwareentropie ein Projekt überwältigt, friert das Projekt ein.

Es kann keine Entwicklungsiterationen mehr geben. Glücklicherweise tritt diese Situation nicht sofort ein. Der langsame, aber steile Marsch zum Rand einer Klippe ist etwas, das jedes System durchmacht. Unabhängig davon, wie gut organisiert und effizient die erste Version sein mag, wird ihre Entropie – und damit das Risiko, dass etwas unerwartet schief geht – über aufeinanderfolgende Entwicklungsiterationen wachsen, es sei denn, es werden spezifische Schritte unternommen, um dies zu verhindern.

Software-Entropie kann nicht reduziert werden. Genau wie die Entropie in der realen Welt wächst sie nur oder bleibt gleich. Seine Auswirkungen sind zunächst vernachlässigbar. Wenn sie sich zu manifestieren beginnen, sind die Symptome mild und können maskiert oder ignoriert werden. Aber wenn ein Unternehmen erst dann versucht, die Software-Entropie zu bekämpfen, wenn sie zum dominierenden Risiko in einem Projekt geworden ist, wird es leider feststellen, dass seine Bemühungen vergebens sind. Die Kenntnis der Softwareentropie ist daher am nützlichsten, wenn ihr Ausmaß gering und die nachteiligen Auswirkungen minimal sind.

Daraus folgt nicht, dass jede Organisation Ressourcen darauf verwenden sollte, das Wachstum der Entropie in ihren Produkten zu begrenzen. Ein Großteil der heute entwickelten Software – insbesondere verbraucherorientierte Software – hat eine relativ kurze erwartete Lebensdauer, vielleicht einige Jahre. In diesem Fall müssen die Beteiligten die Auswirkungen der Softwareentropie nicht berücksichtigen, da sie selten zu einem ernsthaften Hindernis wird, bevor das gesamte System verworfen wird. Es gibt jedoch weniger offensichtliche Gründe, die Auswirkungen der Software-Entropie zu berücksichtigen.

Betrachten Sie die Software, die die Routing-Infrastruktur des Internets betreibt oder Geld von einem Bankkonto auf ein anderes überweist. Zu jedem Zeitpunkt befinden sich eine oder mehrere Versionen dieser Software in der Produktion, und ihr kollektives Verhalten kann mit angemessen hoher Genauigkeit dokumentiert werden.

Die Risikotoleranz eines Systems ist ein Maß dafür, wie viel und welche Art von unerwartetem Verhalten wir problemlos von einer Entwicklungsiteration zur nächsten zulassen können. Bei den eben genannten Systemtypen ist die Risikotoleranz weitaus geringer als beispielsweise bei der Software, die Telefongespräche weiterleitet. Diese Software wiederum hat eine geringere Risikotoleranz als die Software, die den Einkaufswagen vieler kommerzieller Websites antreibt.

Risikotoleranz und Softwareentropie hängen insofern zusammen, als die Softwareentropie minimal sein muss, um sicher zu sein, dass wir während der nächsten Entwicklungsiteration innerhalb der Risikotoleranz eines Systems bleiben.

Quellen der Software-Entropie

Software-Entropie entsteht aus einem Mangel an Wissen . Sie ergibt sich aus der Divergenz zwischen unseren gemeinschaftlichen Annahmen und dem tatsächlichen Verhalten eines bestehenden Systems. Diese Tatsache erklärt, warum Software-Entropie nur im Zusammenhang mit der Modifikation eines bestehenden Systems Bedeutung hat; es ist das einzige Mal, dass unser Mangel an Verständnis praktische Auswirkungen haben wird. Software-Entropie findet den fruchtbarsten Boden in einem System, dessen Details nicht von einer einzelnen Person verstanden werden können, sondern über ein Entwicklungsteam verteilt sind. Auch die Zeit ist ein mächtiger Auslöscher von Wissen.

Code ist der Ausdruck einer Reihe logischer Behauptungen. Wenn das Verhalten der Software (und damit ihr Code) nicht der Logik entspricht, die sie ausdrücken soll, können wir von ihrer inhärenten Entropie sprechen. Diese Situation kann auf drei Arten entstehen: Die Logik ist bekannt und weicht von ihrem Ausdruck ab, es gibt mehrere Verständnisse der Logik, die der Code ausdrücken soll, oder die Logik ist nicht bekannt.

• Die erste Situation – die Logik ist allgemein bekannt und weicht von ihrem derzeitigen Ausdruck ab – ist am einfachsten zu behandeln, aber auch am seltensten. Nur sehr kleine Systeme, die von vielleicht zwei Beteiligten, einem Entwickler und einem Verantwortlichen für den Geschäftsplan, gepflegt werden, fallen in diese Kategorie.

• Die zweite Situation – die Logik ist nicht bekannt – ist selten. Die Entwicklungsiteration kann praktisch noch nicht einmal beginnen. Wenn sich irgendwann alle Beteiligten einigen können, stehen sie wahrscheinlich vor der ersten Situation.

Der menschliche Verstand interpretiert seine Erfahrungen, indem er sie effektiv filtert und modifiziert, um sie in einen persönlichen Rahmen einzupassen. In Ermangelung effektiver Entwicklungsgewohnheiten – basierend auf einem freien Austausch von Ideen, gegenseitigem Respekt und klaren Erwartungen – kann es so viele Interpretationen darüber geben, wie ein System derzeit funktioniert, wie es Teammitglieder gibt. Die Ziele des Teams für die aktuelle Entwicklungsiteration können selbst umstritten sein.

Viele Entwickler schützen sich vor dieser Situation, indem sie ihr eigenes, einzigartiges Verständnis dessen stärken, was von ihnen verlangt wird und wie das System organisiert „sollte“. Auf der anderen Seite könnten Manager und andere Stakeholder unwissentlich versuchen, die Annahmen anderer Teammitglieder zu ändern, in einem fehlgeleiteten Versuch, ihr eigenes Leben einfacher zu machen.

Wir sind jetzt bei der häufigsten Quelle der Software-Entropie angelangt: Es gibt mehrere, unvollständige Interpretationen der Logik, die das System ausdrücken soll. Da es immer nur eine einzige Manifestation dieser Logik gibt, ist die Situation per definitionem problematisch.

Wie kommt es zu diesem Mangel an Wissen? Inkompetenz ist ein Weg. Und wie wir bereits gesehen haben, ist ein Mangel an Einigkeit über die Ziele der nächsten Entwicklungsiteration ein weiterer. Aber es gibt noch andere Faktoren zu berücksichtigen. Eine Organisation kann vorgeben, eine Entwicklungsmethodik anzuwenden, dann aber willkürlich einige oder alle ihrer Aspekte offen preisgeben. Softwareentwickler werden dann damit beauftragt, vage Aufgaben zu erfüllen, die oft offen für Interpretationen sind. Organisationen, die Änderungen an ihrer Entwicklungsmethodik vornehmen, sind besonders anfällig für dieses Phänomen, obwohl sie keineswegs die einzigen sind. Auch persönliche Konflikte, die dem Management nicht bekannt sind oder anderweitig nicht gelöst werden können, können zu einer gefährlichen Abweichung zwischen Erwartungen und Ergebnissen führen.

Es gibt einen zweiten, wichtigeren Weg, wie wir technisches Wissen über ein Produkt verlieren: durch Übertragung. Das Festhalten von technischem Wissen auf Papier ist selbst für die erfahrensten Autoren eine Herausforderung. Der Grund dafür ist, dass es genauso wichtig ist, was zu transkribieren ist wie wie . Ohne die richtige Disziplin kann ein Technischer Redakteur zu viele Informationen aufzeichnen. Alternativ können sie Annahmen treffen, die dazu führen, dass sie wesentliche Punkte auslassen. Nach der Erstellung muss die technische Dokumentation akribisch auf dem neuesten Stand gehalten werden, ein schwieriges Unterfangen für viele Organisationen, die Dokumente fast schon nach ihrer Erstellung aus den Augen verlieren. Aufgrund dieser Schwierigkeiten wird technisches Wissen selten allein in Dokumenten übertragen, sondern auch in Paaren oder anderen Formen der engen, zwischenmenschlichen Interaktion.

Software-Entropie macht Sprünge und Grenzen, wann immer ein aktiver Teilnehmer ein Entwicklungsteam verlässt. Sie nehmen ein wertvolles Stück Know-how mit. Dieses Know-how zu replizieren ist unmöglich, und es erfordert erhebliche Anstrengungen, es anzugleichen. Mit ausreichender Aufmerksamkeit und Ressourcen kann jedoch genügend Wissen bewahrt werden, um das Wachstum der Entropie des Systems zu minimieren.

Es gibt andere Quellen für Entropie, aber diese sind relativ gering. Zum Beispiel ist Software Fäulnis der Prozess, durch den ein System unerwartet von Änderungen in seiner Umgebung beeinflusst wird. Wir können an Software von Drittanbietern denken, auf die es sich stützt (z. B. Bibliotheken), aber es gibt andere, heimtückischere Ursachen für Softwarefäule, die normalerweise aus Änderungen der Annahmen resultieren, auf denen das System basierte. Wenn beispielsweise ein System mit bestimmten Annahmen zur Speicherverfügbarkeit entworfen wurde, kann es in unerwarteten Momenten zu Fehlfunktionen kommen, wenn der verfügbare Speicher reduziert wird.

So berechnen Sie die Entropie: Zuweisen von Werten zu C, S und I

I ist die Anzahl ungelöster Verhaltensprobleme in einem Softwaresystem, einschließlich des Fehlens versprochener Funktionen. Dies ist eine bekannte Größe, die häufig in einem System wie JIRA verfolgt wird. Der Wert von I wird direkt daraus abgeleitet. I ist die Anzahl der „Arbeitseinheiten“, die während der letzten Entwicklungsiteration aufgegeben oder unvollständig gelassen wurden, zusätzlich zu der Anzahl der Arbeitseinheiten, die aus neu eingeführten und unerwarteten Verhaltensproblemen resultieren. Da I ​​als Anzahl von Arbeitseinheiten gezählt wird, können wir es mit dem Wert von S in Beziehung setzen, der den Umfang der nächsten Entwicklungsiteration in denselben Arbeitseinheiten darstellt. Was genau eine „Arbeitseinheit“ umfasst, hängt von der Entwicklungsmethodik ab.

C ist die wahrgenommene Wahrscheinlichkeit, dass, wenn die Arbeitseinheiten im Geltungsbereich implementiert wurden, die Anzahl der tatsächlich offenen Probleme I1 in der nächsten Iteration größer sein wird als jetzt geschätzt. Dieser Wert lebt in der Domäne 0 <= C <= 1.

Man könnte argumentieren, dass die Wahrscheinlichkeit C genau das ist, was die Software-Entropie zu messen vorgibt. Es gibt jedoch grundlegende Unterschiede zwischen diesem Wert und unserem Maß für die Software-Entropie. Die wahrgenommene Wahrscheinlichkeit, dass etwas schief geht, ist genau das: Es ist kein realer Wert. Es ist jedoch insofern nützlich, als die Gefühle der Menschen, die an einem Projekt teilnehmen, eine wertvolle Informationsquelle darüber sind, wie stabil es ist.

Der Umfang S berücksichtigt die Größe der vorgeschlagenen Änderungen und muss in denselben Einheiten wie I ausgedrückt werden. Ein größerer Wert von S verringert die Entropie, da wir den Umfang der vorgeschlagenen Änderungen erhöhen. Auch wenn dies kontraintuitiv klingen mag, müssen wir bedenken, dass die Entropie ein Maß dafür ist, wie die Entwicklung des Systems möglicherweise nicht unseren Erwartungen entspricht. Es reicht nicht zu sagen, dass die Entropie ein Maß für die Möglichkeit ist, Probleme einzuführen. Wir versuchen natürlich, Risiken zu antizipieren und berücksichtigen sie in unserer Planung (und damit in unserer Schätzung von I1, die durchaus über ₀ steigen kann). Je zuversichtlicher wir sind, einen großen Änderungsumfang anzunehmen, desto weniger Entropie kann man im System sagen – es sei denn, diejenigen, die die Änderungen planen und/oder durchführen, sind inkompetent. Diese Möglichkeit spiegelt sich jedoch wahrscheinlich im aktuellen Wert von I wider.

Beachten Sie, dass wir nicht versuchen müssen, die Größe der Differenz zwischen dem tatsächlichen Wert von I ₁ und seinem erwarteten Wert anzugeben. Wenn wir davon ausgehen, dass unsere Pläne richtig sind, wenn wir sie machen, ist es auch nicht vernünftig anzunehmen, dass wir vorhersagen können, inwieweit das Ergebnis nicht unseren Erwartungen entsprechen wird; wir können nur eine wahrgenommene Wahrscheinlichkeit C spezifizieren, dass dies nicht der Fall ist. Wie stark jedoch der tatsächliche Wert I ₁ von seinem erwarteten Wert abweicht, geht in Form des abgeleiteten Werts I in die Berechnung der Entropie in der nächsten Iteration ein.

Theoretisch ist es möglich, dass I einen negativen Wert hat. In der Praxis wird diese Situation jedoch niemals eintreten; normalerweise lösen wir Probleme nicht zufällig. Negative Werte für I sind kein beruhigendes Zeichen. Sie implizieren, dass die Mittel, mit denen die Entropie berechnet wird, fehlerhaft sind. Das Wachstum der Software-Entropie kann natürlich durch gezielte Maßnahmen, wie unten beschrieben, reduziert werden. Allerdings sollte ich in solchen Fällen nicht von negativen Werten ausgehen, da wir unsere Erwartungen immer in unsere Entwürfe einfließen lassen.

C ist ein subjektiver Wert. Es existiert in den Köpfen der Teilnehmer einer Entwicklungsiteration und kann durch Befragung und Mittelung der Ergebnisse abgeleitet werden. Die Frage sollte positiv gestellt werden. Zum Beispiel: „Wie würden Sie auf einer Skala von 0 bis 10 mit 10 am wahrscheinlichsten die Chancen des Teams einschätzen, alle seine Ziele in dieser Entwicklungsiteration zu erreichen?“

Beachten Sie, dass die Frage nach den Zielen des Teams als Ganzes gestellt wird, nicht nach einer Teilmenge. Eine Antwort von 10 würde einen Wert von 0 für C anzeigen, während eine Antwort von 7 einen Wert von 0,3 anzeigen würde. In größeren Teams kann jede Antwort in Abhängigkeit von relevanten Faktoren gewichtet werden, z. B. wie lange eine Person in das Projekt involviert ist und wie viel Zeit tatsächlich dafür aufgewendet wird. Kompetenz sollte jedoch kein Faktor bei der Gewichtung der Antworten sein. Selbst ein junges Mitglied des Teams wird nach kurzer Zeit ein Gefühl dafür haben, wie effektiv es bei der Erreichung seiner Ziele ist. Ausreichend große Teams möchten möglicherweise die höchsten und niedrigsten gemeldeten Werte verwerfen, bevor sie den Rest mitteln.

Fachleute zu fragen, wie wahrscheinlich es ist, dass ihr Team scheitert, ist eine heikle und provokante Angelegenheit. Dies ist jedoch genau die Frage, die sich jede Organisation stellen muss, die Entropie quantifizieren möchte. Um ehrliche Antworten zu gewährleisten, sollten die Teilnehmer ihre Schätzung von C anonym und ohne Angst vor Konsequenzen abgeben, selbst wenn sie einen horrend hohen Wert angeben.

S muss in denselben „Arbeitseinheiten“ wie I ein Wert zugewiesen werden und ist daher stark von der Entwicklungsmethodik abhängig. Für Teams, die Aspekte einer agilen Methodik anwenden, scheinen Geschichten die offensichtlichste „Arbeitseinheit“ für S und I zu sein. In diesem Fall erstreckt sich der Umfang einer Entwicklungsiteration über jede regelmäßig geplante Veröffentlichung in der Produktion, entweder als Neben- oder als Hauptversion. I sollte quantifiziert werden als die Summe der Anzahl von Stories, die während jedes Sprints vor der Veröffentlichung nicht erfolgreich abgeschlossen wurden, und der Anzahl von Stories, die für die Aufnahme in zukünftige Sprints als Ergebnis unerwarteter Probleme generiert wurden, die sich nach der Veröffentlichung manifestierten.

Beachten Sie, dass wir Hotfixes oder andere ungeplante Veröffentlichungen für die Produktion nicht als Definition des Umfangs einer Entwicklungsiteration betrachten und auch keine zugehörigen Geschichten von I abziehen sollten.

Die Schwierigkeit bei diesem Ansatz besteht darin, dass eine Phase der Entdeckung und Analyse erfolgen muss, bevor Fehler anschließend in Geschichten unterteilt werden können. Der wahre Wert von I kann daher erst mit Verzögerung bestimmt werden. Außerdem findet das Polling für C natürlich zu Beginn jedes Sprints statt. Die erhaltenen Ergebnisse müssen daher noch einmal über die gesamte Freisetzung gemittelt werden. Trotz dieser Schwierigkeiten wird jedes Team, das Aspekte einer agilen Methodik anwendet, wahrscheinlich feststellen, dass Geschichten die genaueste Einheit zur Quantifizierung von S (und daher von I ) sind.

Heutzutage werden andere Entwicklungsmethoden verwendet. Unabhängig von der angewandten Methodik bleiben die Prinzipien zur Messung der Software-Entropie dieselben: Die Software-Entropie sollte zwischen Releases bis zur Produktion gemessen werden, S und I sollten in denselben „Arbeitseinheiten“ gemessen werden, und Schätzungen von C sollten von direkten Teilnehmern genommen werden nicht bedrohlich und vorzugsweise anonym.

Reduzierung des Wachstums von E

Ist das Wissen über ein System einmal verloren gegangen, kann es nie wiedergewonnen werden. Aus diesem Grund kann die Software-Entropie nicht reduziert werden. Alles, was wir hoffen können, ist, sein Wachstum einzudämmen.

Das Wachstum der Entropie kann durch geeignete Maßnahmen bei der Softwareentwicklung begrenzt werden. Der Pair-Programming-Aspekt der agilen Entwicklung ist in dieser Hinsicht besonders nützlich. Da beim Schreiben des Codes mehr als ein Entwickler beteiligt ist, wird das Wissen über wesentliche Details verteilt und die Auswirkungen von ausscheidenden Teammitgliedern abgemildert.

Eine weitere nützliche Praxis ist die Erstellung einer gut strukturierten und leicht konsumierbaren Dokumentation, insbesondere in Organisationen, die eine Wasserfallmethode anwenden. Eine solche Dokumentation muss durch strenge und klar definierte Grundsätze unterstützt werden, die von allen verstanden werden. Organisationen, die sich auf die Dokumentation als wichtigstes Kommunikationsmittel verlassen und technisches Wissen sichern, sind für diesen Ansatz gut geeignet. Nur wenn es keine Richtlinien oder Schulungen zum Schreiben und Verwenden intern geschriebener Dokumente gibt – wie es häufig in jüngeren Organisationen der Fall ist, die RAD- oder Agile-Methoden einsetzen –, wird ihr Wert verdächtig.

Es gibt zwei Möglichkeiten, das Entropiewachstum in einem System zu reduzieren: Änderungen ausführen, die darauf abzielen, I zu reduzieren, oder Änderungen ausführen, die darauf abzielen, C zu reduzieren.

Die erste beinhaltet Refactoring. Maßnahmen, die darauf abzielen, I zu reduzieren, sind eher technischer Natur und dem Leser wahrscheinlich bereits bekannt. Es muss eine Entwicklungsiteration stattfinden. Der Teil dieser Iteration, der das Wachstum der Entropie reduzieren soll, bringt keine greifbaren geschäftlichen Vorteile, während er Zeit und Ressourcen verbraucht. Diese Tatsache macht die Reduzierung des Entropiewachstums in jeder Organisation oft zu einem Verkaufsargument.

Die Reduzierung des C-Werts ist eine wirkungsvollere Strategie, da die Wirkung längerfristig ist. Darüber hinaus fungiert C als wichtiger Kontrollfaktor für das Wachstum des Verhältnisses von I zu S. Maßnahmen zur Reduzierung von C konzentrieren sich in der Regel auf menschliches Verhalten und Denken. Obwohl diese Aktionen per se keine Entwicklungsiteration erfordern, verlangsamen sie nachfolgende Iterationen, da die Teilnehmer neue Verfahren akzeptieren und sich daran anpassen. Der scheinbar einfache Akt, sich darauf zu einigen, welche Verbesserungen vorgenommen werden sollten, ist ein Weg, der mit eigenen Gefahren behaftet ist, da die unterschiedlichen Ziele der Projektteilnehmer und -beteiligten plötzlich ans Licht kommen.

Einpacken

Softwareentropie ist das Risiko, dass das Ändern vorhandener Software zu unerwarteten Problemen, nicht erreichten Zielen oder beidem führt.

Obwohl sie bei der Erstellung von Software vernachlässigbar ist, wächst die Softwareentropie mit jeder Entwicklungsiteration. Wenn man sie ungehindert weiterlaufen lässt, wird die Software-Entropie die weitere Entwicklung schließlich zum Erliegen bringen.

Allerdings sollte nicht jedes Projekt mit den Auswirkungen der Software-Entropie rechnen. Viele Systeme werden aus der Produktion genommen, bevor die Entropie spürbare und schädliche Auswirkungen haben kann. Für diejenigen, deren Lebenszeit so lang ist, dass die Entropie ein glaubwürdiges Risiko darstellt, bietet die Schaffung eines Bewusstseins dafür und die Messung ihres Ausmaßes, obwohl es noch gering ist, ein Mittel, um sicherzustellen, dass die Entwicklung nicht vorzeitig abgebrochen wird.

Ist ein System vollständig von den Auswirkungen der Softwareentropie überwältigt, können keine Änderungen mehr vorgenommen werden und die Entwicklung ist im Wesentlichen abgeschlossen.