Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.02.1985

Software im Praxistest: Der Anwender ist oft der Lackierte

Bei der Software-Einführung kommt das böse Erwachen spätestens dann, wenn die Testphase abgeschlossen ist: Es wird alles teurer als vorgesehen. Zu diesem Zeitpunkt, so warnt der saarländische Unternehmensberater Jules Barrois, ist der Anwender hardwaremäßig aber schon festgelegt. Es bleibt also nichts anderes übrig, als in den sauren Apfel weiterer Software-lnvestitionen zu beißen. Um einer solchen Krisensituation vorzubeugen, fordert Franz Grote von der Kirchlichen Beratungs- und Entwicklungsgesellschaft für EDV die strikte Einhaltung von "Spielregeln", die für Jeden Mitarbeiter verbindlich sind. außerdem erscheint ihm eine kritische Beobachtung der Testaktivitäten in DV- und Fachabteilung unabdingbar. Künftig sei nämlich eher mit einer Verminderung der Testqualität als mit einer Verbesserung der Entwicklung zu rechnen.

Joachim Schmid

Gesellschafter, OSYS GmbH, Stuttgart

Qualitätssicherung ist bei der Erstellung und Pflege der hauseigenen Software unverzichtbar. Ohne seriöses Testen findet Qualität nicht statt. Die notwendigen Ressourcen und die benötigte Zeit müssen zur Verfügung gestellt werden, wenn erfolgreich DV betrieben werden soll.

Diese fast schon trivialen Grundsätze werden im DV-Alltag jedoch häufig vernachlässigt. Daß dem nicht so sein muß, soll am Beispiel eines unserer Kunden verdeutlicht werden: Die völlige Neuorganisation des Unternehmensbereiches Abrechnung hatte hier zur Folge, daß die dafür benötigte Software komplett neu zu erstellen war (zirka 220 000 lines of code, davon 90 Prozent Online-Programme - 18 Mannjahre). Die Einführung der neuen Software war nur en bloc zu einem bestimmten Stichtag möglich. Der "point of no return" lag vier Monate vor der Einführung. Nach diesem Zeitpunkt durften wesentliche Softwarefehler nicht mehr auftreten.

Aus diesem Grunde führten wir zunächst ein Sieben-Phasen-Kozept für die Entwicklung von Individualsoftware ein. Unter anderem mußte eine kontinuierliche und vollverantwortliche Beteiligung der DV-User über alle Projektphasen sichergestellt sein. Diese Funktion wurde innerhalb der Stabstelle Organisation etabliert und mit einem erfahrenen Abteilungsleiter aus der Fachabteilung besetzt. Dieser betreut das Projekt benutzerseitig und koordiniert die Verbindung Fachabteilung - DV.

Im Rahmen der Phasen 5 und 6 wird die neue oder geänderte Software einem zweistufigen Test unterzogen.

Test durch die DV (Phase 5):

- Stabilität und Verträglichkeit mit dem Online-Monitor und dem DB-System (keine CICS-Abstürze),

- keine unkontrollierten Ab-normal-End-Situationen,

- Datenintegrität und Datensicherheit sind gewährleistet,

- die Anforderungen der Fachabteilung werden erfüllt,

- Einhaltung der Programmier-Richtlinien und Standards.

Test durch die Projektkoordination (Phase 6):

- die Anforderungen der Fachabteilung werden erfüllt,

- Verträglichkeit mit der Projektumgebung,

- Auswirkungen auf andere Projekte,

- Anforderung zusätzlicher Ressourcen in Abstimmung mit der DV,

- Durchführen von Parallelläufen.

Ohne Freigabe durch die Projektkoordination Wird kein Programm in die Produktion übernommen. Damit ist auch die Verantwortung für Fehler in der Produktion festgelegt.

Diese Vorgehensweise benötigt systemseitig einige Voraussetzungen. Dazu gehört ein von der Produktion völlig getrenntes Test-Environment. Mit Ausnahme des kleineren Datenvolumens unterscheidet sich die Testumgebung nicht von der Produktionsumgebung. Besonders wichtig ist auch die strikte Trennung der Programmbibliotheken für Test und Produktion. Die Übernahme der Programme in Produktion (nach Freigabe durch die Projektkoordination) erfolgt mit CMS-Prozeduren, die automatisch entsprechende Log-Files führen.

Die in den vergangenen drei Jahren gewonnenen Erfahrungen zeigen, daß der in der Anwendungsentwicklung und -pflege angefallene Mehraufwand durch die damit erzielte Stabilität und Verfügbarkeit des Abrechnungssystems unbedingt gerechtfertigt ist.

Jules Barrois

Barrois & Partner GmbH, Merzig

Das böse Erwachen kommt spätestens dann, wenn die Testphase abgeschlossen ist: Es wird alles teurer als vorgesehen, es läuft alles nicht so wie ursprünglich geplant, und einiges geht überhaupt nicht. Jetzt aber ist es zu spät. Der Anwender ist hardwaremäßig gebunden und hat schon so viel in die Umorganisation investiert, daß er in den sauren Apfel weiterer Software-Investitionen beißt.

Das Problem muß früher angepackt werden. Denn bei der Auswahl von DV-Systemen wird die Software-Frage vernachlässigt. Mindestens zu 70 Prozent sollte die Anbieter- und Hardware-Auswahl von der Software beeinflußt werden.

Grundsätzlich wird zu oft Software gleich Software gesetzt und alles in einen Topf geworfen. Von Anfang an ist zunächst einmal nach den folgenden Software-Gruppen zu unterscheiden:

- systemnahe Software wie Datenbanksysteme, Kommunikationsprozeduren, Netzwerk-Software,

- persönliche Software wie Tabellenkalkulation, Textverarbeitung, Grafik,

- horizontale Standard-Software wie Finanzbuchhaltung, Lohn und Gehalt, Auftragsbearbeitung, Kostenrechnung,

- vertikale Standard-Software wie Branchenpakete der unterschiedlichsten Art.

Denn nur aus der unzulänglichen Abgrenzung und Bewertung dieser Software-Gruppen ergeben sich die drei hauptsächlichen Schwachstellen:

Verharmlosung des Problems Software

Die Wünsche des Anwenders nach individuellen Lösungen werden als einfach zu realisieren hingestellt. Die Kosten dafür sind dem Anwender nicht in hinreichendem Maße bekannt. Mit dem Hinweis auf Kompatibilitäten von Betriebssystemen und ähnlichen Faktoren wird auf den freien Markt der Softwareanbieter verwiesen und so getan, als ob alles problemlos zu haben wäre.

Der Begriffswirrwarr kann weidlich ausgenutzt und dem Anwender ein X für ein U vorgemacht werden. So ist ein noch so gut funktionierendes DatenverwaItungssystem keine Datenbank.

Präsentation von Einzelsoftware

Dabei handelt es sich in vielen Fällen um "Persönliche Software". Damit wird der Eindruck erweckt, als ob auch andere Bereiche hervorragend gelöst seien. Über systemnahe Software wird fast gar nicht gesprochen. Obwohl das, was bei ihr fehlt, später über teure Individualsoftware ausgeglichen werden muß. Und oft ist das nicht mehr möglich. Die horizontale Standardsoftware ist oft nicht komplett und die Übergänge zwischen Teilpaketen sind nicht standardisiert. Vertikale Software, die sogenannten Branchenpakete, haben oft mit der Branche nur den Namen gemein. Sie entpuppen sich meistens als sehr beschränkte Teillösung.

Anbieten von nicht-erprobter Software

Die angebotene Software hat ihre Feuertaufe noch nicht bestanden, da sie kaum oder noch gar nicht gelaufen ist. Wer spielt schon gerne Versuchskaninchen? Deshalb wird kaum ein Anbieter den Zeitpunkt verraten, wenn Programme zum ersten Mal beim Benutzer den Praxisbeweis antreten.

Oft wird Software aus ähnlichen Betrieben als Standardbranchenlösung mit all ihren Ungereimtheiten angeboten.

Eine Reihe von Punkten ist deshalb zu beachten:

- Trennen Sie nach den beschriebenen Softwaregruppen und bewerten Sie sie einzeln.

- Legen sie besonderen Wert auf die systemnahe Software.

- Kaufen oder leasen Sie nur Software, von der Ihnen bekannt ist, wie oft, bei wem und wie lange sie schon läuft.

- Achten Sie darauf, daß Hard- und Software aus einer Hand kommen.

- Der Anbieter muß über eigene Programmierer verfügen, um zumindest notwendige Modifikationen vorzunehmen.

- Lassen Sie sich die exakten Kosten für Programmierung, Änderung und Modifikation nennen und die Konditionen schriftlich geben.

- Lassen Sie sich die deutsche Dokumentation zur Software zeigen.

- Lassen Sie die Software und unterzeichnen Sie die Abnahme erst, wenn sie wirklich läuft.

- Wirklich hieb- und stichfest testen können Sie Software nur dort, wo sie schon läuft. Sprechen Sie mit den Anwendern.

- Für systemnahe und persönliche Software gibt es hervorragende Checklisten mit Mindestanforderungen. Nutzen Sie sie.

Und nicht zuletzt: Streben Sie nicht nach einer optimalen Lösung. Wenn Sie mit Standardsoftware 60 bis 70 Prozent Ihrer Probleme in den Griff bekommen, ist das schon sehr gut. Machen Sie Abstriche von Ihren Träumen. Individualsoftware ist teuer und gefährlich. Es gibt in Deutschland über 10 000 Softwarepakete zu kaufen. Glauben Sie wirklich, daß Ihr Betrieb in seinen Abläufen und der Organisation so einmalig ist, daß die Lösung sonst nicht vorkommt? Wenn ja, sollten Sie als allererstes Ihre Organisation prüfen. Denn dann stimmt dort etwas nicht.

Franz Grote

Bereichsleiter D/C und Systeme, KIGST-KIBEG Kirchliche Beratungs- und Entwicklungsgesellschaft für EDV mbH, Frankfurt

Die Softwarewartung und -pflege wird immer umfangreicher, immer kostenintensiver. So oder ähnlich klingen die meisten Kritiker, die in ihren DV-Teams die für Neuentwicklungen verfügbare Kapazität schwinden sehen. Eine Ursache dafür ist auch in oft mangelhaft und sogar unqualifiziert ausgeführten Programmtests zu sehen. Hier wird zwangsläufig Kapazität gebunden, die in der doch so sorgfältig erstellten Planung verlorengeht.

Welchen Status hat ein Programm, das vom Programmierer als "ausgetestet" bezeichnet wird? Nach den ersten negativen Erfahrungen mit der Vokabel "ausgetestet" wird schnell der Schluß gezogen, daß eine Differenzierung in der Einschätzung des Programm-Status erforderlich ist. Mindestens drei Ebenen der Qualitätskontrolle sind sinnvoll, wenn auch nicht zwingend:

- Programm-/Funktionstest durch den Programmierer; Schwerpunkte sind hier die Lauffähigkeit, die Kompatibilität, die Integration im System und im Verfahren.

- Funktions- und Verfahrenstests durch die Fachabteilung (Anwender, Benutzer) mit Unterstützung durch die DV-Abteilung.

- Massen- und Abnahmetest durch Fachabteilung und DV gemeinsam.

Das klingt gut, erfordert aber die strikte Einhaltung beziehungsweise Vorgabe von Spielregeln. Der Programmierer ist, je nach Qualität und Aussagekraft seiner Vorgaben, in der Lage, durchaus einen realitätsnahen Test durchzuführen. Doch mit welchem Material testet er? Im Regelfall sind es selbsterzeugte Testdaten, die eben kaum Bezüge zur Realität haben. Ein Musterhaus, also ein kompletter beispielhafter Datenbestand für die Anwendung des gesamten Verfahrens, kann da schon sehr hilfreich sein. Ist das Musterhaus auch noch mit den Fachabteilungen gemeinsam erstellt worden, kann man schon von ziemlich guten Testvoraussetzungen sprechen. Gleichzeitig bietet das Musterhaus die Grundlage für entsprechende Ausbildungsmaßnahmen.

Die Zufälle und Wechselfälle der Praxis können aber auch in einem Musterhaus nicht festgeschrieben werden. Schließlich handelt es sich ja um ein Muster, nicht um Darstellung der für Tests auch erforderlichen Extreme. Oft wird versucht, die Lösung in Test-Generatoren zu finden, die nach entsprechenden Vorgaben gezielt oder auch zufällig das Testmaterial erzeugen.

Wichtig ist: Wenn solche Generatoren eingesetzt werden, muß man beachten, daß dadurch nicht die fachlichen Erfordernisse des Programmtests abgedeckt werden. Gemeinsam mit der Fachabteilung oder sogar durch die Fachabteilung selbst (mit Unterstützung durch die DV-Abteilung) kann in Anschluß an die durch den Programmierer erreichte Funktions- und Lauffähigkeit der Test nach fachlichen Gesichtspunkten erfolgen.

Darüber hinaus kann die Absprache mit der Benutzerseite den Massentest wie auch den Abnahmetest vorsehen. Beide Partner schaffen ein befriedigendes Klima in der Zusammenarbeit, wenn die Test-Inhalte und die Test-Strategien abgestimmt sind.

Die Verantwortung der Fachabteilung darf nicht erst in der Abnahme des fertigen Programms beziehungsweise Verfahrens beginnen. So wie die Fachabteilung zwingend in die Analyse und Konzeption einzubinden ist, muß ebenso zwangsläufig auch die Definition des Tests mit den jeweiligen Prozeduren der Vorgehenweise, Inhalte, Abhängigkeiten und Freigabe gemeinsam erarbeitet werden. Diese Richtlinie ist in der Folge nicht nur auf den Test neuer Programme, sondern auch auf den Test geänderter Programme anwendbar.

Tools und Systeme/Sprachen der x-ten Generation erleichtern die Entwicklung von Programmen, auch die Erstellung von Testgrundlagen. Die Gefahr dieser Produkte liegt in der einseitgen Erkenntnis einer als Produktivitäts-Steigerung verstandenen Erhöhung der Quantität.

Die beinahe schon historisch gewachsenen Probleme der fehlenden oder mangelhaften Dokumentation sowie die daraus folgenden Probleme der Programmwartung und Tests werden erneut festgeschrieben. Im Wissen um die sehr viel leichter möglichen Performance-Schwierigkeiten, die bei Einsatz von komplexen Tools entstehen können, müssen die Strategien der Entwicklung und der Testabläufe sinnvollerweise eine andere Betrachtungsweise der Tools ergeben.

Dabei können die Vorteile der Tools in der Steigerung der Qualität der Verfahren und Programme gesehen werden. Natürlich erzeugt diese Form der Interpretation in nahezu allen Beziehungen einen massiven Widerstand, sie ist ja schließlich unwirtschaftlich.

Die "Intelligenz am Arbeitsplatz" mit den vom Benutzer zu formulierenden Anforderungen schafft hier nur vordergründig Linderung.

Die DV-Abteilung als Dienstleistung wird von Verantwortungsteilen entlastet. Die Qualität der neu entstehenden Abläufe scheint zukünftig unerheblich zu sein. Erst mit steigernder Komplexität der vom Benutzer selbst formulierten Anwendungen erscheint ein umfassendes Testen der Abläufe sinnvoll zu werden.

Auch wenn es widersprüchlich klingt: Erst die Sachzwänge von Terminen und Kosten führen zu der gemeinsam getragenen Erkenntnis, daß Tests von Software qualitativ höheren Ansprüchen genügen müssen und von daher als ein wesentlicher Teil der Entwicklung von Programmen zu sehen sind.

Die kritische Beobachtung der Entwicklung des Testgebarens in DV- und Fachabteilung erscheint mir unabdingbar denn die Zukunft läßt aus heutiger Sicht eher eine Verminderung der Testqalität als eine Besserung des Zustandes befürchten.