|
|
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.
|
|