15 Schritte bei Softwareentwicklung und -erweiterung

EINLEITUNG

Mit dieser Beschreibung „15 Schritte bei Softwareentwicklung und -erweiterung“ möchten wir Ihnen eine Hilfe an die Hand geben. Sie erfahren hier, welche Aktionen eingeleitet werden, wenn Sie Software entwickeln oder vorhandene Software erweitern lassen. Sie werden sehen, was alles vor und nach der eigentlichen Programmierung als Lieferleistung Ihres Softwarelieferanten erfolgt.

Wir würden uns darüber freuen, wenn Sie die „15 Schritte bei Softwareentwicklung und -erweiterung“ als Leitfaden und Orientierungshilfe betrachten. Es hilft Ihnen Kosten und im Endeffekt auch Zeit zu sparen, da spätere Änderungen, die im Vorfeld nicht beachtet wurden oder auch komplette „Fehlprogrammierungen“ nicht nur ärgerlich, sondern vor allem durch den entstandenen Termindruck meist mit Hektik und Stress verbunden und damit fehleranfällig sind. Das ärgert übrigens auch die beteiligten Programmierer, die darauf bedacht sind, qualitativ gute Arbeit zu liefern und dies nicht können,weil entscheidende Informationen gefehlt haben.

Lassen Sie uns einmal einen auf den ersten Blick trivialen Auftrag anschauen: Auf der Homepage soll anstatt der im System vorhandenen E-Mail Adresse die Möglichkeit geschaffen werden, dass eine weitere E-Mail Adresse für die Anzeige einer Kontaktadresse zur Verfügung stehen soll.

Bei einer „normalen“ Homepage gehen Sie oder Ihr Webmaster in den internen Bereich und tragen einfach auf den entsprechenden Seiten eine andere Adresse ein. Damit ist das erledigt und Sie können sich anderen Dingen zuwenden.

In einem Datenbanksystem, das die Anzeige mehrerer Homepages steuert, muss hier ein Feld in der Datenbank angelegt werden. Das ist zunächst kein Hexenwerk für den Programmierer. Es fügt das Feld einfach ein. Damit ist es aber noch nicht getan. Er muss es natürlich für Sie auch noch sichtbar machen und Regeln aufstellen, was hier eingegeben werden darf und wer hier was eingeben darf. Außerdem muss überlegt werden, wo dieses Feld auf der Homepage angezeigt werden soll, ob es auf der Homepage vom eingeloggten User geändert werden darf, ob es überhaupt angezeigt wird und so weiter und so fort. Vielleicht werden für einige Systemmails auch noch Platzhalter benötigt und es muss eventuell auch möglich sein, dass das Feld nicht angezeigt wird, wenn der Inhaber der Adresse das nicht will.

Sie sehen, dass so ein „kleines“ zusätzliches Feld unter Umständen viel Arbeit bedeuten kann. Vor allem bei einem komplexen Datenbank-System, mit dem nicht nur die Homepage dargestellt wird, sondern mit dem viele Geschäftsprozesse gesteuert werden.

Gerade wenn die Zeit drückt, sollte man sich etwas Zeit nehmen und nachdenken, was genau gefordert wird und was damit erreicht werden soll. Als normaler Nutzer eines Datenbanksystems ist man höchstwahrscheinlich nicht unbedingt in die Arbeitsweise eines Softwareherstellers eingeweiht. Ihr Geschäft ist es ja auch nicht Software zu entwickeln, sondern der Vertrieb von Produkten oder Dienstleistungen, für die Sie der Spezialist sind. Da muss die Software einfach „nur“ funktionieren.

Damit Sie in Zukunft zu den Menschen gehören, die wissen, worauf es ankommt, haben wir Ihnen diesen kleinen Leitfaden zusammengestellt, in dem Sie erfahren, welche 15 Schritte bei einer Softwareentwicklung oder –erweiterung angestoßen werden. Die einzelnen Schritte können je nach Art und Umfang der Aufgabe aufwändig oder weniger aufwändig sein.

Grundsätzlich sollten Sie die angeführten 15 Schritte auch bei anscheinend einfachen Anforderungen einhalten. Spätestens bei Warenwirtschaftssystemen, oder Systemen bei denen Warenwirtschaften mit einer Homepage und einer Provisionsabrechnung verbunden ist, sollten Sie sich als Kunde zur Regel machen, dass die Schritte eingehalten werden.

Vielleicht fragen Sie sich jetzt, warum für augenscheinlich kleinere Anpassungen, wie das Ändern der Ansicht einer Homepage, das Einfügen von zwei Zeilen in ein Rechnungsformular oder auch ein neues E-Mail Feld so ein großer Aufwand betrieben wird.

Als Softwarelieferant möchten wir möglichst immer auf der Basis der 15 Schritte arbeiten, denn so entstehen von der Auftragserteilung bis hin
zur Lieferung korrekte Eindeutigkeiten und es macht das Leben für alle Beteiligten wirklich einfacher und reduziert am Ende die Kosten. Wir
wissen, dass Sie als Kunde am Liebsten eine „One-Step“ Softwarebestellung wünschen. Wir wissen jedoch auch, dass am Ende Sie als Kunde sehr von den 15 Schritten proftieren werden.

WARUM DIE „15 SCHRITTE DER 15 SCHRITTE BEI SOFTWAREENTWICKLUNG UND -ERWEITERUNG“?

Ihre Software wird wachsen und irgendwann einmal fangen Sie als Kunde an, den Überblick zu verlieren. Das darf dem Anbieter der Software natürlich nicht passieren. Er wird deshalb jede Programmierarbeit im Rahmen des Qualitätsmanagements intern dokumentieren, damit bei Erweiterungen dieser Arbeit andere Programmierer (oder auch er selbst) nachschauen kann, was überhaupt gemacht wurde und wie die Prozesse zusammenhängen. Ein kleiner Fehler kann hier unter Umständen eine große Wirkung verursachen.

Es kommt immer wieder vor, dass ein Besteller sagt: „Ich benötige nur diese Kleinigkeit“ oder „…das Bisschen“. Er erklärt die geforderte Arbeit „ist nicht viel und soll mal eben schnell zwischendurch gemacht werden, weil es eben eilt“. Die Kontaktperson übernimmt gedanklich den Begriff „Nicht viel, mal eben, schnell und eilt“. Sie behandelt Ihre Anforderung dann auch so, erstellt eine Beschreibung der verbal formulierten Anforderung und übergibt dem Programmierer den Auftrag. Dieser programmiert nach der Beschreibung und wenn der Kunde etwas
vergessen oder die Kontaktperson etwas falsch verstanden hat, und dies dann nachträglich eingebaut werden muss, entstehen zusätzliche Kosten, die mit hoher Wahrscheinlichkeit niedriger ausgefallen wären, wenn der Programmierer gleich die entsprechenden Informationen gehabt hätte. Von der zeitlichen Verzögerung einmal ganz abgesehen.

Am Ende stellt sich also heraus, dass dieses „kleine“ Bisschen tiefe Einschnitte in das Gesamtsystem der Software bedeutet, und dass dadurch extrem hohe Kosten verursacht wurden. Jetzt wird nachgängig die Zeit investiert, die besser vorher für das Projekt investiert worden wäre. Da so etwas kein Einzelfall ist und in der Praxis bei jedem Softwarelieferanten vorkommt, möchten wir Ihnen helfen, dieses in Zukunft zu vermeiden. Mit den „15 Schritten bei Softwareentwicklung und -erweiterung“ geben wir Ihnen einen Standard an die Hand, der Ihnen und uns hilft, Software optimiert und in guter Qualität zu liefern.

Software ist ein komplexes Thema. Gerade in der heutigen Zeit, in der das Internet eine so große Rolle im Alltag spielt, ist es wichtig, dass die Systeme reibungslos laufen und vor allem optimal aufeinader abgestimmt sind.

Im Notfall gilt auch hier, wie bei der Feuerwehr:

Ruhe bewahren!

„ZWEI ZEI LEN “ – EINE IMAGINÄRE MUSTERBESTELLUNG

Lassen Sie uns ein Beispiel anschauen. Dieses Beispiel hat keinen Bezug zu einem tatsächlichen Auftrag. Sollte es tatsächlich doch einmal so oder so ähnlich gewesen sein, so ist in dem Beispiel weder der Kunde, noch das System zu erkennen.

Ein Kunde kontaktiert den Softwarelieferanten und erklärt, dass er gerne im Rechnungskopf zwei zusätzliche Zeilen eingefügt wünscht. Um diese beiden Zeilen darzustellen, müssen auch Rechenoperationen durchgeführt werden. Es eilt sehr und der Kunde hat schon alles, was gefordert ist, genau beschrieben.

Es ist wirklich eine fast perfekte Beschreibung vorhanden. Da es sehr eilig ist, wird der Auftrag als eilig deklariert. Da ja die Beschreibung zusammen mit den Erklärungen des Kunden schlüssig und klar sind, wird der Auftrag direkt an einen Programmierer weiter geleitet.

Dieser hatte sich die Beschreibung ohne die zusätzlichen Erklärungen des Kunden angesehen und es ist für ihn klar, was er zu tun hat (das denkt er zumindest). Er bestätigt den Auftrag direkt mündlich und programmiert fast sofort.

Da ohne mündliche Erklärungen aus der Beschreibung zu erkennen ist, dass die Zusatzzeilen auch unter dem Rechnungstext sein könnten, hat der Programmierer das auch genauso gemacht. Zusätzlich hatte er als Basis den Typ des Rechnungs-formulars genommen, der beim Kunden zu dem Zeitpunkt der Programmierung eingestellt war. Der Programmierer konnte nicht wissen, dass der Kunde nachgängig einen anderen Typ des Rechnungsformulars nehmen wird.

Am Ende wurde die Software geliefert, im Softwarehaus war alles perfekt. Beim Kunden nichts. Wären die „15 Schritte bei Softwareentwicklung und -erweiterung“ eingehalten worden, dann wäre diese Anforderung garantiert problemlos und schneller programmiert worden.

Verursacher des Problems: Es fehlte das Programmierer-Feedback, in dem der Programmierer beschreibt, was er verstanden hat und was er programmieren soll. Das war in diesem Fall das große Problem.

ÜBERBLICK - „15 SCHRITTE BEI SOFTWAREENTWICKLUNG UND – ERWEITERUNG“

Jetzt ist schon ein Begriff gefallen: „Programmierer-Feedback“. Damit lassen wir Sie nicht alleine stehen, sondern wir werden jetzt direkt in die Thematik der Softwareentwicklung einsteigen.

Diese „15 Schritte bei Softwareentwicklung und –erweiterung“ werden wir Ihnen nachfolgend erklären:

1. Kundenwunsch
2. Lastenheft
3. Arbeits-Ticket
4. Systemanalyse
5. Pflichtenheft
6. Erstes Kunden-Feedback
7. Abstimmungsphase
8. Prüfregeln
9. Programmierer-Programmieranweisung
10. Programmierer-Feedback
11. Programmieren
12. Prüfung
13. Handbuch
14. Übergabe an den Kunden
15. Abnahme durch den Kunden

Nebenbei bemerkt: Diese Regeln können im Geschäftsleben bei allen Bestellungen angewandt werden und führen am Ende zu einer sehr hohen Bestell- und Lieferqualität.

„Zwei Zeilen“
Wir werden in den Erklärungen immer wieder einen Bezug auf die Musterbestellung finden, so kann diese Thematik praxisnah erklärt werden. Der Bezug ist dann unter „Zwei Zeilen“ erklärt.

ÜBERSICHT DER SCHRITTE

Die „15 Schritte bei Softwareentwicklung und -erweiterung“ gliedern sich in 5 Hauptgruppen. So sehen Sie wie sinnvoll die einzelnen Schritte sind.

Sie als Kunde sollten niemals Ihren Lieferanten so drängen, dass er diese Regeln nicht einhalten kann. Am Ende wird es Ihnen als Kunde sicher zum Vorteil sein, wenn die 15 Schritte eingehalten werden können.

AUFTRAGSFINDUNG BEIM KUNDEN
1. Kundenwunsch
2. Lastenheft

DEFINIERUNG LEIS TUNGSUMFANG BEIM LIEFERANTEN
3. Arbeits-Ticket
4. Systemanalyse
5. Pflichtenheft

ABSTIMMUNGSPHAS E K UNDE UND LIEFERANT
6. Erstes Kunden-Feedback
7. Abstimmungsphase

AUFTRAGSBEARBEIT UNG BEIM LIEFERAN TEN
8. Prüfregeln
9. Programmierer-Programmieranweisung
10. Programmierer-Feedback
11. Programmieren
12. Prüfung
13. Handbuch

ABSCHLUSS DER ARBEITEN
14. Übergabe an den Kunden
15. Abnahmebestätigung durch den Kunden

1. KUNDENWUNSCH

In der Firma des Kunden wird gewünscht oder festgestellt, dass die bestehende Software erweitert werden muss. Das wird dem Softwarelieferant schriftlich oder mündlich mitgeteilt. Es wird in der Firma des Kunden ein so genanntes Lastenheft erstellt.

„Zwei Zeilen“
Es sollen im Rechnungsformular zwei Zeilen ausgegeben werden.

2. LASTENHEFT

Der Kunde beschreibt in einem Lastenheft möglichst präzise die Gesamtheit der Forderungen, was er entwickelt oder produziert haben möchte.

Idealerweise sollte das Lastenheft so gestaltet sein, dass ein Fachmann nach kurzer Einarbeitung in die Thematik die Last erkennt und diese umsetzen kann.

Das ist Wunschdenken und in der Praxis nur dort möglich, wo Kunden selber Fachpersonal eingestellt haben, die solche Aufgaben lösen können. Und auch unter den Fachleuten werden Dokumente für komplexe Anwendungen oft nicht ohne weitere Erkärungen korrekt verstanden.

Also wird in der Praxis so verfahren, dass der Lieferant angerufen wird. Ihm wird erklärt, was gewünscht ist. Dazu werden oft Schriftstücke mitgeschickt, die den Wunsch tiefergehend erklären. Im Regelfall wird die Arbeitslast, die zur Erstellung eines fertigen umfangreichen Lastenheftes notwendig ist, vom Kunden auf den Lieferanten verlagert.

„zwei Zeilen“
In unserem Beispiel mit den zwei Zeilen wurde eine gute schriftliche Beschreibung erstellt und an den Softwarelieferanten geleitet.

3. ARBEITS -TICKET

Der Softwarelieferant hat die Arbeitsanforderung erst einmal in sein System aufgenommen und ein Arbeits-Ticket erstellt. In der Regel wird dem Kunden die Ticket-Nummer mitgeteilt. So kann bei der weiteren Kommunikation eindeutig auf die geforderte Arbeit Bezug genommen werden.

Ab jetzt wird also immer dann, wenn über diese Arbeitsanforderung geschrieben wird, zur Klärung die Ticket-Nummer mit angegeben.

„zwei Zeilen“
Es wird ein Arbeits-Ticket erzeugt. Die Ticket-Nummer wird dem Kunden mitgeteilt.

4. SYSTEMANALYSE

Die Systemanalyse ist der Bereich, der sehr gerne übergangen wird. Besonders dann, wenn ein Auftrag eilig ist oder vermeintlich Kosten gespart werden sollen.

Gerade Kunden, die nicht wissen, wie Programmierung funktioniert, denken oft, dass dieser Schritt unnötig ist. Der Kunde denkt, dass dem Programmierer doch klar sein muss was geliefert werden soll. In der Regel kann man davon ausgehen, dass das dem Programmierer nicht ganz klar ist.

Bei großen Projekten können Kunden sehr viel Geld sparen, wenn in gemeinsamen Meetings die Projektaufgaben besprochen werden. Auf solchen Meetings wird der Kunde zusammen mit dem Softwarehaus angelaufene und neue Arbeits-Tickets so weit wie möglich analysieren. Hier läuft das geballte Wissen des Kunden und des Softwarehauses zusammen und unsere Erfahrung lehrt uns, dass am Ende solche Kunden optimierte Systeme zu kostenoptimierten Preise vorliegen haben. Auch im Zeitalter moderner Technik geht oft nichts über ein
gemeinsames Gespräch am Tisch. Uns ist kein solches Arbeitsmeeting bekannt, dass am Ende nicht mehr Kosten für den Kunden eingespart hat, als das, was das Meeting dem Kunden gekostet hat.

WAS WIRD BEI DER SYSTEMANALYSE AUSGEFÜHRT ?

Es wird untersucht in welchen Bereichen in der Software der Kundenwunsch umgesetzt werden kann und welche Stellen des Quellcodes durch die Anforderung des Kundenwunsches außerdem tangiert werden oder tangiert werden könnten.

- Welche Auswirkungen hat die Änderung an der gewünschten Stelle?
- Welche Auswirkungen hat die Änderung an anderen Stellen?

Wenn komplexe Anforderungen bestehen, erstellen die Programmierer so genannte Testcodes. Das ist Softwarecode, mit dem leichter zu beurteilen ist, was später programmiert werden soll. Auch kann es sein, dass der Programmierer sich das Kundensystem auf seinen Rechner lädt
und die Änderungen simuliert, um dann eventuell zu beurteilen, was alles bei Programmierung beachtet werden muss. Manchmal ist nur
über so einen Weg eine Machbarkeitsstudie der Kundenanforderung auszuführen.

„zwei Zeilen“
Wenn in unserem Fall der zwei Zeilen die Programmierer vorher in den Quellcode des Programms gegangen wären, so hätten sie das
Nachfolgende vorgefunden und nicht nur gedanklich eine Kleinigkeit.

Das Rechnungsformular soll erweitert werden, darum ist dieser Bereich anzusehen.

Das Rechnungsformular kann für beliebig viele Länder (sagen wir für 3 Länder) und beliebig viele Sprachen (sagen wir in 3 Sprachen) erstellt
werden.

Dazu gibt es als Vorlage für das Rechnungsformular bereits 5 verschiedene PDF-Designs und 6 veschiedene Inhaltsdesigns.

Zusammen sind das 3 (Länder) * 3 (Sprachen) * 5 (PDF) * 6 (Inhalt) tatsächlich 270 unterschiedliche Kombinationsmöglichkeiten des
Ausdrucks der Rechnung.

Dazu kann die Rechnung über den Auftrag der Warenwirtschaft, die Zahlungsarten, die Massenaktionen und den Massendruck erstellt
werden.

An dieser Stelle wäre der Programmierer sehr vorsichtig geworden und hätte sehr genau nachgefragt.

Er hätte die Problematik erkannt und hätte im Pflichtenheft differenziert beschrieben, in welcher Kombibation der 3 (Länder) * 3
(Sprachen) * 5 (PDF) * 6 (Inhalt) der Ausdruck mit den zwei Zeilen programmiert werden soll.

Dazu hätte er seinen Lösungsansatz beschrieben, die Zeilen unter den Rechnungstext zu legen. So hätte der Kunde im Lastenheft gesehen, was
der Programmierer falsch verstanden hatte, denn er positioniert die zwei Zeilen an falscher Stelle und auf dem zu diesem Zeitpukt
eingestellten Formular. Das ist in dem Beispiel nicht erfolgt, weil ja Eile geboten war.

5. PFLICHTENHEFT

Das Pflichtenheft ist eines der wichtigsten Dokumente für den Kunden und den Lieferanten.

Meist wird aus Kostengründen und besonders aus Geschwindigkeitsgründen auf dieses elemetare Element im Rahmen der Softwareentwicklung oder -erweiterung verzichtet.

Ein Pflichtenheft ist ein Dokument, in dem der Softwarelieferant seine Pflicht beschreibt, was er als Auftrag verstanden hat und was er als
Ergebnis liefern will. Damit haben beide Seiten ein Dokument an der Hand, an das sich beide Seiten halten können.

Bei Auftragsänderungen sind Lasten- und Pflichtenheft sofort zu ergänzen und es ist vom Kunden die Zustimmung zur Änderung
einzuholen.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde diese Phase übersprungen.

6. ERSTES KUNDEN -FEEDBACK

Der Kunde erhält das Pflichtenheft und prüft, ob er seine Anforderungen aus dem Lastenheft beschrieben sieht.

Manchmal müssen die Anforderungen erweitert oder präzisiert werden. Manchmal erkennt der Kunde auch, dass Teile seiner Anforderung für
die Funktionalität nicht unbedingt erforderlich sind.

Leider wird hier sehr oft ein Superfehler gemacht: Der Kunde fängt an im Pflichtenheft herumzuschreiben oder er beschreibt alles wieder neu.
Das ist ein absolutes No-Go.

Änderungen oder Unklarheiten wird der Kunde mit dem Softwarelieferanten besprechen. Das vorhandene Lastenheft wird vom Kunden ergänzt und der Vorgang wird von vorne aufgerollt. Das Gleiche macht der Softwarelieferant mit dem Pflichtenheft, bis alles so ist, wie der Kunde es wünscht.

Am Schluss sieht der Kunde seinen Auftrag im Pflichtenheft beschrieben. Er wird kurz schriftlich den Auftrag bestätigen oder jetzt die Gesamtkosten auf der Basis eines Angebotes anfordern. In dem Fall sollten die Kosten des Pflichtenheftes jetzt in Rechnung gestellt werden,
damit eine klare Grenze zwischen Vorarbeit und der tatsächlichen Programmierarbeit gezogen werden kann.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde diese Phase übersprungen.

7. ABSTIMMUNGSPHASE

Es liegt ein vom Kunden abgenommenes Pflichtenheft vor.

Jetzt wird intern im Softwarehaus genau abgestimmt wer die Anforderung wann umsetzt.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde diese Phase übersprungen und die
Arbeit wurde einem Programmierer direkt zugeteilt.

8. PRÜFREGELN

Eine Person, die nicht der zukünftige Programmierer ist, legt oft in Zusammenarbeit mit dem Kunden fest, wie die Programmierung geprüft
werden soll. Dazu kann es notwendig sein, dass Zweitsysteme zur Prüfung eines Auftrages installiert werden müssen.

Alle Prüfregeln werden im Auftrag eingetragen, so dass der Programmierer seine Arbeit selber einfacher prüfen kann.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde diese Phase übersprungen.

9. P ROGRAMMIERER -PROGRAMMIERANWEISUNG

In dieser Phase wird im Softwarehaus besprochen wie, was und wann genau programmiert wird. Der endgültige Programmierer für die Arbeit
erhält seine Programmieranweisung.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde dem Programmierer das Dokument des Kunden in die Hand gegeben.

10. PROGRAMMIERER-FEEDBACK

Zur Sicherheit wird der Programmierer hausintern der Person, die den Auftrag mit dem Kunden besprochen hat, ein Feedback geben. Er erklärt
was er programmieren wird.

Bei Kleinprojekten läuft dieses per Telefonkonferenz, ansonsten schriftlich.

„zwei Zeilen“
In dem Fall der zwei Zeilen war der Auftrag für den Programmierer seiner Meinung nach klar auf Grund des Dokumentes des Kunden, somit
ist auch diese Phase übersprungen worden, besonders weil das ja sehr eilig war.

11. PROGRAMMIEREN

Jetzt endlich wird programmiert. Die Programmierer haben nicht nur die Aufgabe zu codieren, sondern die von ihnen erstellten Codes auch
im Quellcode selbst zu kommentieren und nach Abschluss der Programmierung eine Dokumentation zu erstellen.

Der Sinn besteht darin, das später er selbst oder ein anderer Programmierer schnell erfassen kann, was genau gemacht wurde und
welche Funktionen ausgeführt werden.

Bei komplexen Projekten wird zudem der Code noch von einem anderen Programmierer gegengelesen, um die Qualität zu sichern.

Zusätzlich gehört in den Bereich Programmieren, dass die Software als erstes von dem Programmierer selber in seiner Enwicklungsumgebung
geprüft wird. Alle programmierten Funktionen sind anzusprechen und werden getestet. Das ist ein Funktionstest und nicht mit einer Prüfung
in einer Praxisumgebung zu verwechseln.

12. PRÜFUNG

Die vor der Programmierung festgelegten Prüfregeln werden jetzt gezogen und als Basis der Prüfung genommen.

Zusätzlich sollte der Prüfer der Software versuchen, eventuelle Fehler oder Abweichungen zum Auftrag zu finden.

Findet er Fehler oder Abweichungen zum Auftrag, so kontaktiert er den Programmierer und klärt die Angelegenheit. Eventuell ist auch der
Kunde mit hinzuzuziehen.

„zwei Zeilen“
In dem Fall der zwei Zeilen hatte der Programmierer die Arbeit als fertig gemeldet. Das wurde umgehend dem Kunden mitgeteilt, damit wurde
diese Phase übersprungen.

13. HANDBUCH

Jede Softwareänderung hat eine Systemänderung zur Folge.

Aus dem Grund muss das Systemhandbuch erweitert werden. Bei individuellen Spezialanwendungen wird ein Einzelhandbuch erstellt.

Das gehört zur Programmierung und ist eine vom Kunden zu zahlende Leistung.

„zwei Zeilen“
In dem Fall der zwei Zeilen wurde diese Phase übersprungen

14. ÜBERGABE AN DEN KUNDEN

Die Software wird im Lifesystem installiert oder es wird die neue Programmierung in einem Zweitsystem installiert.

Der Kunde prüft nun seinerseits die Software.

Es wird sehr oft vereinbart, dass eine ausreichende umfassende Prüfung in Praxisumgebung direkt vom Kunden ausgeführt wird, weil damit die
nicht unerheblichen Kosten der Prüfung im Softwarehaus wegfallen, oder diese drastisch minimiert werden. Bei Fehlern oder Abweichungen
zum Auftrag ist es im Falle der Kundenprüfung jedoch oft kompliziert für Rückmeldungen bis zum Programmierer.

Die Prüfung muss umgehend erfolgen, weil bei eventuellen Änderungen oder zusätzlichen Erweiterungen der ursächliche Programmierer den
Quellcode sozusagen noch im Kopf hat. So kann das schnell umgesetzt werden. Wird zu lange mit der Abnahme gewartet, so muss sich auch
der ursächliche Programmierer wieder neu einarbeiten.

Oft wird auch der Fehler begangen, die neue Software nicht zu prüfen. Der Kunde nimmt sich nicht die Zeit für die Prüfung, meint, dass alles in
Ordnung ist und setzt die Software sofort ein. Das kann fatale Folgen haben, wenn doch noch nicht alles so funktioniert wie gewünscht und
es wird mit Hochdruck an einer Lösung gearbeitet. Wird die Software ohne Prüfung eingesetzt, dann sind Fehler prinzipiell nicht als Mängel
der Software anzusehen. Auch wenn so manches mal darüber hinweggesehen wird.

„zwei Zeilen“
Die Software wurde übergeben, sie funktionierte beim Kunden anscheinend nicht. Der Grund der Nichfunktion war, dass der
Programmierer ein anderes PDF- und Inhaltsdesign genommen hatte als der Kunde, und auf Nachfragen sagte er zu der ihm vorliegenden
Beschreibung vom Kunden: „Sehen Sie selber, oben ist der Rechnungskopf und unten sind die zwei Zeilen“. Ihm konnte bei seiner
Betrachtungsweise nicht ganz widersprochen werden. Abschließend kann festgestellt werden, dass dem Programmierer die Anforderungen
nicht präzise genug mitgeteilt worden sind.

15. ABNAHME DURCH DEN KUNDEN

Ist die Prüfung der Software erfolgreich gewesen, erhält der Kunde die Software zur Abnahme. Dabei ist es unerheblich, ob die Prüfung durch
den Kunden oder das Softwarehaus erfolgt ist.

ZUSAMMENFASSUNG

Grundsätzlich muss immer mit dem Ziel geprüft werden, in wie weit ein Auftrag in das Schema der „15 Schritte bei Softwareentwicklung und
-erweiterung“ eingefügt werden kann.

Ist ein Auftrag in sich zu komplex, ist es vernünftig ihn in sinnvolle Komponenten zu zerlegen und diese Komponenten einzeln nach den
„15 Schritten bei Softwareentwicklung und -erweiterung“ auszuführen. Daran sollten weder Zeitdruck noch Kostengründe etwas ändern.

Umfangreiche Aufträge

Die Erfahrung lehrt, dass große Aufträge, die über Monate oder Jahre gehen, sich nicht in der Gesamtheit unter den Bedingungen der „15
Schritte bei Softwareentwicklung und -erweiterung“ ausführen lassen. Hier muss regelmäßig eine Kommunikation zwischen Kunde und
Softwarelieferant erfolgen. Auf diese Art wird sich ein Automatismus in Teilprojekten auf der Basis der „15 Schritte bei Softwareentwicklung
und -erweiterung“ einschleifen. Das hilft Großprojekte in kleine beschreibbare Einheiten zu zerlegen, die dann in sich nach den „15
Schritten bei Softwareentwicklung und -erweiterung“ ausgeführt werden.

Die „15 Schritte der Softwareentwicklung und -erweiterung“ führen zu einer hohen Qualitätskontrolle und Softwarequalität.