Entwicklung einer Software

Softwareentwicklung

Bei der eigentlichen Softwareentwicklung müssen Regeln aufgestellt, befolgt und überwacht werden. Und wie sieht der richtige Softwareentwicklungsprozess aus? Die Entwicklung von Software ist nach Ansicht vieler Menschen ein klarer Prozess.

mw-headline" id="Distinction_from_Product_Lifecycle">Distinction_from_Product_Lifecycle[Verarbeitung | < Quelltext bearbeiten]

Exemplarische, einfache Abbildung des Software-Lebenszyklus. Der Software-Lebenszyklus bezeichnet den Ablauf der Software-Entwicklung mit dem Zweck, dem Auftraggeber Software zur Verfügung zu stellen. Der Kreislauf fängt in der Regelfall mit einem Kundenproblem und dessen Problemanalyse an und hört auf der Auftraggeberseite mit dem Austausch der Software durch einen anderen auf. Je nach eingesetztem Prozessmodell kann ein Software-Lebenszyklus die Stufen "Planung", "Analyse", "Design", "Entwicklung", "Test", "Lieferung" oder andere ausmachen.

Die Phase des Kreislaufs startet mit der Herausbildung eines durch Software zu bearbeitenden Problemfeldes, z.B. einer Verbraucheranfrage. Diese Problematik wird untersucht und die zu implementierende Software projektiert. Danach erfolgt die Umstellung der projektierten Software auf Coding (Implementierung). Auf die Implementierungs- und Testphasen folgen der Produktivbetrieb der Software, in dem auch Instandhaltungsarbeiten durchgeführt werden.

Auf jeden Falle ist die Software einem Alterungsprozess unterworfen. Aus Sicht des Kunden ist ein Software-Lebenszyklus beendet, wenn das System durch ein Folgeprodukt ersetzt wird. Der Kreislauf schließt aus Sicht des Herstellers mit der Einstellung des Support und/oder der Einstellung des Softwareproduktes. Nahezu alle Stufen des Software-Lebenszyklus, einschließlich des Abschlusses der Software-Wartung, lassen sich planen.

Tendenzen in der heutigen Softwareentwicklung

Die Frage, wie die Software-Entwicklung mit modernen Verfahren rascher, effektiver und gezielter gestaltet werden kann. Die Software-Entwicklung war schon immer ein Feld mit schnellen Änderungen und Weiterentwicklungen. Während diese Entwicklung in der vergangenen Zeit jedoch meist auf technologischer Basis stattgefunden hat, erfahren wir derzeit die stärksten Änderungen im Prozessbereich und in der Gestaltung der IT.

Es ist das Bestreben, nach Auswertung eines Teilergebnisses in kurzen Abständen die Entscheidung für die weiteren Prozessschritte zu fällen und so den Entwicklungsnutzen zu maximieren. Zahlreiche Gebiete der Softwareentwicklung sind unmittelbar oder mittelbar davon berührt, und um dieses Leitbild sinnvoll umsetzen zu können, sind mehrere grundlegende Änderungen erforderlich. Obwohl wir in der Regel schon in der Praxis versuchten, ein Softwareprojekt so gut wie möglich zu gestalten und dann so gut wie möglich zu implementieren, geht das Unternehmen davon aus, dass wir nur einige Fragestellungen im Zeitablauf richtig lösen können.

Anstelle der Erstellung eines Plans und dessen Befolgung wird beschlossen, was der nächstmögliche angemessene Ausstieg aus der gegenwärtigen Lage ist, der den größtmöglichen Gewinn bringen wird. Eine viel grössere Bedeutung hat dabei der Auftraggeber, da er durch sein Rückmeldungen einen unmittelbaren Einfluß auf diese Entscheide hat. Dieser Funktionsumfang wird den Benutzern oder einer kleinen Testgruppe zur Verfuegung gestellt und wir bestimmen ueber den Measure Step Data ueber die Nuetzlichkeit dieser Funktionen.

Es folgt der Learn-Schritt, in dem wir aus diesen Erkenntnissen erfahren, wie wir unsere Softwareanwendung optimieren können. Dabei wird auch berücksichtigt, dass nicht alle Voraussetzungen in der Softwareentwicklung richtig sind und dass wir auch Irrtümer machen. Build-Measure-Learning ist besonders effektiv, wenn es in kürzester Zeit eingesetzt wird. Somit eröffnet das Erlernen die Möglich-keit, die Funktionalität unserer Applikation auf das zu konzentrieren, was dem Benutzer den größten oder den größten Vorteil verschafft und eine nicht verwendete Funktion zu beseitigen.

Natürlich stellt dieser Aspekt spezielle Ansprüche an die Bauphase, um in diesen schnellen Phasen hochqualitativen und wartungsfreundlichen Quellcode zu erhalten. Die Forderung, die optimale Software zu projektieren und später zu implementieren, ist heute als realitätsfern zu betrachten, unabhängig davon, wie viel Aufwand in die Planung gesteckt wird. Vielmehr erwies es sich als viel gelungener, die Funktionalitäten in sehr schnellen Zeitabständen durch kleine Versuche zu ergänzen und dann zu ergründen, wie die Software weiter verbessert werden kann.

Vor Beginn der Arbeiten im Entwicklungsteam werden die Anliegen und Vorstellungen der jeweiligen Interessengruppen (Stakeholder wie Kunden, Nutzer, etc.) erfasst und in eine für die anschließende Implementierung günstige Gestaltung überführt, die das Resultat so anschaulich wie möglich wiedergibt. Das Koordinieren der Ideenfindung und die Erarbeitung einer Zielvorstellung und der angestrebten Resultate wird von einem zentralem Produktverantwortlichen (PO) begleitet.

Zum einen erarbeitet er gemeinsam mit den Beteiligten die Idee und zum anderen fungiert er dem Entwicklungsteam als zentrale Anlaufstelle für technische Auskünfte. Die Bestellung vermittelt auch die Sichtweise, d.h. für wen die Software erstellt wird (Zielgruppe) und welche Vorteile damit zu realisieren sind (Business Value).

Ein populäres und in den vergangenen Jahren etabliertes Verfahren ist die Erarbeitung von Anforderungsprofilen in Gestalt einer "User Story". Sämtliche erfassten Produktideen werden - oft unfiltriert - auf eine große Auswahlliste, den sogenannten Produkthaft. Weil die meisten Projekte mehr Vorstellungen haben, als das Projektteam selbst umsetzen kann, wird die Auswahlliste zu einer Warteliste.

Deshalb wertet der Produktmanager in Kooperation mit den Interessengruppen und dem Entwicklungsteam den Produktrückstand aus und ordnet ihn so um, dass immer das "Wichtigste" zuerst bearbeitet wird. Dies erfordert vor allem zwei Angaben zu jedem Element: die Grösse und den Vorteil für den Anwender oder das Verarbeiter.

Das Entwicklungsteam trägt die Grösse in Gestalt einer Relativschätzung bei, d.h. es werden im Produktrückstand einzelne Komponenten miteinander verglichen, ohne sich Gedanken über die Implementierung zu machen (Beispiel: "Ich weiss nicht, wie viel ein Äpfel wog, aber wenn ich ihn mit einer Erdberitze verglich, ist es zumindest das 5fache").

Nach Möglichkeit werden für den Mehrwert/Nutzen die Menschen gefragt, die es am besten wissen sollten: die Interessenvertreter. Das Entwicklungsteam implementiert die Bestandteile der Produkt-Backlog-Items. Im Idealfall ist dies nicht zu groß, so dass Sie sich gut koordinieren, am selben Platz sein und über alle notwendigen Kenntnisse zur Fertigstellung der Software verfügen, einschließlich aller qualitativen Aspekte und Tests.

So ist beispielsweise die Zahl der Produktrückstände, die das Projektteam innerhalb einer Wocheneinheit erledigt, dann die Schnelligkeit des Projekts (Geschwindigkeit). Auf diese Weise kann der Produktverantwortliche früh erkennen, welche Merkmale bis wann zu vermuten sind und die Anforderungen richtig einstellen. Manche Arbeitsgruppen legen eine Grenze von "Work in Progress" fest und legen damit fest, dass beispielsweise nur fünf Komponenten vom Arbeitsteam parallel verarbeitet werden dürfen.

Oft wird die Zahl so gewählt, dass es genügt, das Gespann ständig zu besetzen, aber nicht zu viel, damit sich das Gespann klar konzentrieren kann. Das Projektteam ist dafür zuständig, dass der Quellcode dauerhaft geschrieben wird und kein "technischer Fehler" entsteht. Es sollte das Bestreben sein, dass Sie auch nach sechs Monaten noch Spaß an der Arbeit mit dem Quellcode haben.

Wenn die Qualität des Codes beeinträchtigt wird oder nicht darauf achtet wurde, erweiterungsfähigen und prüfbaren Quellcode zu verfassen, wird es immer komplexer, Veränderungen vorzunehmen. Der Einsatz von neuen Funktionalitäten nimmt dann mehr Zeit in Anspruch und verlangsamt die Schnelligkeit des Teams auf mittlere Sicht (auf nahezu Null). Der für alle sichtbare Produktrückstand spiegelt wider, was das Projektteam vorhat und an dem es arbeitet.

Grundvoraussetzung ist, dass alle Aspekte tatsächlich im Produktrückstand vermerkt sind. Vor allem aber sind es die Gespräche, die während der Erstellung oder Verfeinerung von Elementen für den Produktrückstand ablaufen. Sie sind es, die letztendlich zu einem Wissensgewinn für die Betroffenen anregen. Dabei hat jede Funktion einen eindeutigen Fokus: Der Produktverantwortliche als zentrale Kontaktperson und verantwortlich für die Aussortierung des Produktrückstandes vertritt die Interessengruppen.

Interessenvertreter sind Menschen, die ein erhebliches Interessengebiet am Vorhaben haben und es in irgendeiner Form beeinflussen wollen, z.B. Nutzer, Verwaltung, Vermarktung, Support, etc. Die Entwicklungsabteilung ist für die korrekte Umsetzung der Vorgaben zuständig. In einigen Gruppen gibt es auch einen Prozess-Moderator (bei uns "Scrum Master" genannt), der das gesamte System betreut und dazu beiträgt, die Abläufe - von der Ideenfindung bis zum Endprodukt - zu beschleunigen und die Schnelligkeit und damit den Datendurchsatz des Systems weiter zu steigern.

Eine sehr wichtige Aufgabe der modernen Softwareentwicklung ist die Einbindung von Kundenrückmeldungen in den Entstehungsprozess. Als " Interessenvertreter " werden neben den traditionellen Nutzern alle an einem konkreten Vorhaben interessierten Menschen, d.h. Geschäftsleitung, Vermarktung, Vertrieb, etc. verstanden. Interessengruppen teilen ihre Anliegen dem Product Owner mit, der sie in einem Rückstand zusammenfasst, steuert und auf der Grundlage der Beiträge ihrer Interessengruppen bestimmt, welche Funktionalitäten als nächste umgesetzt werden sollen.

Die Funktionalitäten werden im Entwicklungsteam implementiert und am Ende einer verkürzten Wiederholung als nutzbare Software-Inkrement zur Verfügung gestellt. Oftmals mangelt es in der Realität an dem nächsten - entscheidenden - Arbeitsschritt, dass die Beteiligten und die PO mit dem Resultat umgehen und ihre Bedürfnisse auf der Grundlage der Ergebnisse adaptieren. Daher sollten die Beteiligten nicht - wie in einer One-Way-Street - nur ihre Bedürfnisse in diesen Prozeß einzubringen, sondern sich auch mit dem Resultat auseinandersetzen, um zu erfahren, wie die Software derzeit auszusehen hat.

Die Betreuung eines Softwareprojektes ist in der Regel nicht ihre Hauptaufgabe. Es sind keine Software-Experten, und die Entwickler-Teams erleben oft, wie ihre Arbeit getan wird, wenn sie zugeben können: "Wir haben die neueste Version auf einem Netzwerklaufwerk, Sie können sie von dort downloaden und aufspielen. "Die Interessengruppen wollen sich nicht mit den auftretenden Schwierigkeiten befassen.

Dabei ist es von Bedeutung, dass die Entwicklerteams die Verantwortlichkeit erkennen, ihre Interessengruppen dabei zu unterstuetzen, bestmoeglich Rückmeldungen zu geben. Developer haben das Fachwissen und die Tools, um zu Hilfe zu kommen, und, was noch viel bedeutender ist, Developer verlassen sich auf dieses Feed-back. Interessengruppen sollten daher nicht als "Störfaktoren" betrachtet werden, die ohnehin nicht wissen, was sie wollen, sondern die Existenzgrundlage für Softwareentwickler sind.

Nur wenn die Beteiligten von der Software profitieren, wird Geldmittel für die Entwicklung zur Verfügung gestellt. Daher ist es die Aufgabe der Softwareentwickler, die Interaktion mit den Interessengruppen zu verbessern und so für ein optimales Ergebnis zu sorgen. der Softwareentwickler ist es, die Qualität der Arbeit zu verbessern. Diese Rückmeldungen können vom Entwicklungsteam am Ende einer Wiederholung angefordert und bearbeitet werden.

So ist z.B. immer verständlich, wie sich ein korrespondierendes Feed-back auf Anforderungsänderungen auswirkt oder welcher Interessenvertreter noch gar kein Feed-back gibt. Eine weitere Facette der Zusammenarbeit zwischen dem Entwicklungsteam und den Interessengruppen ist die Fragestellung, wie Benutzeranforderungen und Kundenwünsche effektiv umgesetzt werden können.

Zusätzlich zu einer schlankeren textuellen Darstellung, z.B. in Gestalt von User Stories mit Akzeptanzkriterien, verwenden immer mehr Vereine auch Storyborde. Sie zeigen in einfacher und bildlicher Darstellung, wie ein Benutzer mit der zu realisierenden Funktion arbeitet, vergleichbar mit einem Drehbuch zu einem Spielfilm. Mit Hilfe dieser Art von Unterlagen können Interessenvertreter und PO ihre Bedürfnisse besser beschrieben und damit die Chancen erhöht werden, ihre Erwartungen bereits bei der ersten Umsetzung zu erfüllen.

In anderen Worten, das Team nutzt diese Methodik, um seine Umsetzungsvision zu erfassen und vor der Umsetzung mit den Beteiligten zu überprüfen. Für Entwicklungsteams ist die Interaktion mit Interessengruppen ein grundlegender Baustein für ein erfolgreiches Softwareprojekt. Softwareentwickler müssen sich dieser Aufgabenstellung annehmen und diesen Tausch mit passenden Verfahren und Werkzeugen nach besten Möglichkeiten vorantreiben, anstatt sich "im Verborgenen zu vergraben".

Allerdings sollen beide Verfahren zur Kommunikationsoptimierung mit Stakeholdern die unmittelbare Information nicht ablösen, sondern vervollständigen. Gerade bei großen Vorhaben mit einer großen Zahl von Stakeholdern ist jedoch eine unmittelbare Verständigung zwischen allen Teilnehmern nicht immer mit der geforderten Effizienz möglich. Technisch gesehen bringt ein kürzerer Zyklus auch "frischen Wind" in die Softwareentwicklung, indem er die Zeit zwischen der Programmerstellung eines Merkmals und dessen Verfügbarkeit für Testpersonen und Anwender reduziert.

Anstatt Tage oder sogar mehrere Monate später Rückmeldungen zu bekommen, dass ein Merkmal den Prüfungstest aus irgendeinem Grund nicht bestand, bekommen Sie rechtzeitig ein Rückmeldungen, während der Speicher noch frei ist. Das Beste wäre natürlich, wenn Sie bei der Eingabe in Visual Studio erfahren würden, dass die gerade geschriebene Codezeile aufgrund von Abhängigkeit etwas anderes unterbricht.

Eine schnelle Rückmeldung (in chronologischer Reihenfolge) ist erhältlich bei: Er überprüft, ob alle notwendigen Beziehungen bestehen und übersetzt den Quellcode. Selbst wenn ein Teil des Codes übersetzt wird, bedeutet das nicht, dass er das macht, was er tun soll (oder was der Programmierer beabsichtigt), also..... Der Bauherr verfasst Programmcode mit Komponententests (Unit-Tests), um zu überprüfen, ob sich der Seriencode wie erhofft verhält.

Der Unit-Test dient auch anderen Mitarbeitern als Schutznetz für Codeänderungen und als Grundlage für die Erstellung einer technischen Dokumentierung, wie sich der Kodex verhält. Der Check-in-Prozess mischt die vom jeweiligen Entwickler vorgenommenen Veränderungen mit den vom Gesamtentwicklung. Bei der Eincheckung wird der Kode vom Builder-Server, der dem Projektteam in einer reinen Arbeitsumgebung in zentraler Weise zur VerfÃ?gung steht, erneut überprüft.

Der Quellcode wird zumindest übersetzt, oft gefolgt von Testverfahren oder anderen Tools zur Qualitätsanalyse. Sie können nicht glauben, wie oft der Fehler vorkommt, dass es auf einem Entwicklercomputer zu funktionieren scheint, aber der Build-Server zeigt einen Kompilierungsfehler an - zum Beispiel wegen fehlender oder nicht vorhandener Bibliotheken. Ob die Software überhaupt gestartet wird, lässt sich anhand von Integrationstests oder User Interface-Tests feststellen.

Natürlich bevorzugen die Anwender schnellere Zykluszeiten, da dies oft mit verkürzten Wartezeiten für das neue Leistungsmerkmal einhergeht. Letztendlich ist ein Merkmal erst dann einsatzbereit, wenn es vollständig ausgearbeitet, geprüft und geliefert wurde und der Anwender es vernünftig einsetzen kann. Stoppen Sie die Zeit zwischen dem Erhalt einer Ideen und dem Zeitpunkt, zu dem das Merkmal vom Auftraggeber akzeptiert wird, erhalten Sie die Zykluszeit.

Zuerst sollten Sie aus Sicht des Entwicklers das Word "finished" im Projektteam eintragen. In der " Definition of Done " sind die Mindestvoraussetzungen enthalten, die ein Merkmal erfüllen muss, um als "fertig" eingestuft zu werden - und es schützt das System auch davor, dass etwas zurückgeschoben oder ausgelassen wird ("weil es dann nicht "fertig" sein würde).

Am besten ist es also, sich gleich nach dem Feiertag mit dem Gespann zu treffen, eine "Definition of Done" zu erarbeiten und diese anschliessend in schriftlicher Form aufzunehmen.

Die Denkweise, d.h. die Haltung der Softwareentwickler zur Qualitätssteigerung. Derzeit haben viele Firmen eine deutliche Abgrenzung zwischen Entwicklungs- und Qualitätssicherungs-Teams oder Abteilungen. Developer erzeugen Quellcode, geben ihn an die Testpersonen weiter und beseitigen dann Bugs, die der Testpersonen auffallen. Dieser Ansatz hat jedoch eine Vielzahl von Vorteilen, wie z.B. die hohen Transaktionsgebühren (Kosten der Zusammenarbeit zwischen dem Prüfer und dem Entwickler) oder das Verlustrisiko, dass gewisse Risiken unbemerkt bleiben, da der Prüfer nicht über das notwendige Wissen über die Applikation verfügt.

Im Idealfall werden bei der Implementierung des Quellcodes die Qualitätsanforderungen der Entwicklungsabteilung berücksichtigt. Ja, so tiefgreifend und unglaubwürdig es auch klingt, das Entnehmen von Tester aus Softwareprojekten steigert die Produktqualität - vorausgesetzt, dies wird von der Entwicklerqualifikation im modernen Testing untermauert. Das Gegenteil ist die These, dass ein Programmierer niemals seinen eigenen Quellcode ausprobieren sollte.

Obwohl diese Feststellung in mancher Hinsicht durchaus zutreffend ist (z.B. Nutzen des Vier-Augen-Prinzips), ist sie oft eine Begründung oder Entschuldigung für Entwickler, nicht selbst Tester durchführen zu müssen. Denn Entwickler mögen es nicht zu prüfen und sind daher nicht hoch motiviert, ihre Fähigkeiten in diesem Gebiet zu erweitern. Allerdings haben Entwickler oft vielfach viel einfachere und effizientere Methoden, um Testergebnisse zu erstellen, insbesondere im Hinblick auf die Testautomatisierung.

Schließlich werden die Programmierer auch anderen, besserem Quellcode folgen, wenn sie wissen, dass sie die Testergebnisse selbst durchführen müssen. Auch wenn in einigen Arbeitsgruppen die Softwareentwicklung ohne eigene Testpersonen nicht möglich scheint, sollte man versuchen, diesem Leitbild so nah wie möglich zu kommen und so viel Eigenverantwortung wie möglich für die Anwendungsqualität zu tragen, wie die Programmierer den Quellcode ausarbeiten.

Um in diesem Anwendungsszenario die Transaktions-Kosten zu senken, sollten die Testpersonen unbedingt Teil des Entwicklungsteams sein, am besten im selben Ort wie die Entwickler, und nicht in organisatorischer Hinsicht voneinander abgetrennt. Denn nur so können Teammitglieder am Ende jeder einzelnen Phase in einem Zyklus von wenigen Tagen oder gar mehreren Monaten hochqualitative Software aufbereiten.

Der Testautomatisierungsprozess startet mit dem Erstellen von Komponententests. Komponententests sind heute ein absolutes Muss in der Softwareentwicklung. Bei richtiger Vorgehensweise müssen die Entwickler keine zusätzlichen Zeit mit dem Verfassen von Unit-Tests verbringen, da viele andere Aufgaben effektiver werden. Für die effektive Gestaltung von Unit-Tests ist jedoch eine entsprechende Infrastruktur erforderlich - eine Vorbedingung, bei der Gruppen mit einer großen Anzahl von Legacy-Codes oft ausfallen.

Belastungs- und Leistungstests tragen dazu bei, unliebsame Überaschungen des Runtime-Verhaltens im produktiven Betrieb zu vermeiden, indem sie diese Fehler frühzeitig im Entwicklungsablauf erkennen und beseitigen. Wenn wir Software in immer kürzer werdenden Zeitabständen entwickeln, benötigen wir neue Wege der Qualitätskontrolle. Entwickler müssen bei der ersten Umsetzung mehr Eigenverantwortung wahrnehmen und die notwendigen Vorgehensweisen lernen und umsetzen.

Die Belohnung dafür ist eine neue Security und ein Ende des "Tauziehens" zwischen Entwicklung und Qualitätskontrolle, insbesondere am Ende eines Release. In der Regel bietet die konventionelle Bauweise spezielle Lösungsansätze für spezifische Problemstellungen oder Erfordernisse. Aus diesem Grund ist der klassiche Wasserfallprozess so strukturiert, dass zunächst alle Voraussetzungen bekannt sein müssen, um dann die optimale Bauart zu gestalten.

Dagegen arbeitet die heutige Baukunst eher mit allgemeinen Mustern, die auf unterschiedliche Vorhaben und Gegebenheiten angewendet werden können. Jeder Bauherr muss diese Muster meistern, weil er sie in seiner alltäglichen Entwicklungstätigkeit einsetzen muss; d.h. dass sich die Struktur in diesem Kontext sehr deutlich unmittelbar auf der Code-Ebene auswirkt. Weitere Architekturaspekte beziehen sich auf Techniken und Modellierung.

Das Codelevel verweist auf die Struktur im Quelltext und liefert Lösungsmuster für Fragestellungen wie "Wie gestalte ich meine Unterricht? Auf technologischer Ebene gibt es zwei Punkte in der Struktur. Andererseits muss die Struktur auch die Beschränkung von Techniken auf eng begrenzte Codebereiche zulassen, so dass bei einem Technologiewechsel die notwendigen Adaptionen auf diesen Anwendungsbereich beschränkt werden können.

Models repräsentieren die Veranschaulichung von Bauwerken. Das ist heute wohl der häufigste Zusammenhang mit dem Terminus Architekur. Im Rahmen des traditionellen Ansatzes werden Modellierungen verwendet, damit ein Fachmann (der Softwarearchitekt) seine Entwürfe und Vorstellungen an die Programmierer weitergeben kann, die diese in Quellcode umwandeln sollen. Auf klassische Architekturen können sich die modernen Arbeitsgruppen jedoch verzichten, da das Arbeitsteam die Mitverantwortung für die Struktur trägt und jeder im Arbeitsteam an deren Entwurf teilnimmt.

Genau hier erfüllt das Modell einen wesentlichen Punkt, und zwar die Darstellung von Konstruktionen und die Reduzierung des Codes auf unterschiedliche Abstraktionsebenen. Für die Modellierung ist es wichtig, dass die Modellierung der Struktur auf verschiedenen Ebenen erfolgt. Dadurch wird eine deutlich effektivere Teamkommunikation über die Systemarchitektur ermöglicht. Als Coach für die Entwicklung stellt er sicher, dass die Entwicklung die nötigen Muster kennt und richtig einbringen kann.

Denn es gibt ständige Verbesserungs- und Weiterentwicklungsmaßnahmen und überträgt dieses neue Wissen nach einer Auswertung auf das Projektteam. Die heutige Baukunst muss drei wesentliche Punkte erfüllen: Das Wartbarkeitsniveau ermöglicht es beispielsweise auch, dass Bugs von allen Entwicklern im Projektteam repariert werden können, egal wer den Quellcode erstellt hat.

Mit jeder Applikation nimmt der Arbeitsaufwand für das Hinzufügen neuer Funktionen mit der Gesamtzahl des Quellcodes zu. Die Testfähigkeit ermöglicht die Bereitstellung von hochqualitativen Kodes in kürzester Zeit, die Wartungsfähigkeit sorgt für eine rasche Adaption der bestehenden Funktionen und die Erweiterungsfähigkeit für eine rasche und effiziente Implementierung von Benutzeranfragen, die sich aus unserem Learn-Schritt ergeben. Es ist an dieser Position erfreulich, dass die gleichen Muster, die die Testfähigkeit erhöhen, auch zu einer verbesserten Erweiterungs- und Wartungsfreundlichkeit mitführen.

Auch interessant

Mehr zum Thema