Lösung zu Entwickeln und Bereitstellen von Anwendungssystemen - IT-Buchreihe Band 3. Seite 232

Transkript

1 Seite Software umfasst nach IEEE Standard alle Programme, vorgeschriebenen Abläufe, auch Dokumentation und Daten, die mit dem Betrieb eines Rechnersystems zu tun haben. Das ist eine sehr allgemeine, aber für die weiteren Betrachtungen nützliche Betrachtungsweise. Software wird dadurch nicht beschränkt auf ein Programm, Software kann als Produkt verstanden werden. Der IEEE Standard fügt dem Programm noch vorgeschriebene Abläufe, Dokumentationen und Daten bei. Letztere sind notwendig, um aus dem Programm ein Produkt zu machen, welches von einem Anwender erfolgreich genutzt werden kann. 2 Der Inhalt und damit die Art der Dokumentation richten sich zuerst nach den Zielgruppen. Zielgruppe Entwickler Anwender/Kunde Anwender/Benutzer (user) Prüfer Technisches Personal Wartungspersonal Spezieller Inhalt der Dokumentation Die Entwickler benötigen die Dokumente zur Planung, Durchführung und Absicherung des Entwicklungsprozesses sowie im späteren Lebenszyklus zur Wartung der Software. Die Anwender als Kunden benötigen eine Beschreibung der Leistungen der Software, damit sie wissen, wofür sie bezahlen. Sie sollten auch Informationen zu den Betriebskosten erhalten, denn sie müssen die Software installieren und betreiben können Die Anwender als Benutzer (user) benötigen Material zum Erlernen und Bedienen der Software Für die Prüfer wird keine gesonderte Dokumentation erstellt. Sie prüfen die erstellte Software und deren Dokumentationen auf die Einhaltung ihrer spezifischen Prüfkriterien, z. B. zur Zertifizierung. Das technische Personal braucht Beschreibungen, um die Software installieren und betreiben zu können. Das Wartungspersonal benötigen die Dokumente im späteren Lebenszyklus zur Wartung der Software. Vertriebsmitarbeiter Die Vertriebsmitarbeiter brauchen eine Beschreibung der Leistungen der Software, damit sie wissen, was sie ihren Kunden anbieten und empfehlen können. Marketingunterlagen müssen optisch ansprechend, kurz und aussagekräftig zu inhaltlichen Aspekten informieren. Wichtig sind auch Referenzen auf andere erfolgreiche Anwender der Software.

2 3 Ein Programm ohne Dokumentation ist keine Software und kann nicht an unbekannte Nutzer zur langfristigen erfolgreichen Verwendung übergeben werden. Dieser Satz ruft viel Widerspruch hervor. Gegen eine Dokumentation werden meistens folgende Argumente genannt: Das Programm ist klein, verständlich geschrieben und im Quelltext gut kommentiert. Aber für wen ist dieses Programm gedacht? Versteht der Kunde den Quelltext? Der Kunde muss hier ebenfalls ein Entwickler sein, der die Programmbausteine für seine Programmierarbeiten nutzt. Viele gute Programme gehen so von Hand zu Hand. Das Programm wird nur einmal eingesetzt und ist generell nur für den internen Gebrauch gedacht. Derartige Wegwerf-Programme werden beispielsweise zur Konvertierung von Daten für die Übernahme in ein neues Softwaresystem benötigt. Befindet sich die neue Software erfolgreich im Einsatz und sind alle Daten im neuen System verfügbar, dann verliert das Konvertierungsprogramm seine Bedeutung und wird nicht mehr gebraucht. Hier kann wirklich auf eine aufwendige Dokumentation verzichtet werden. Allein für die Qualitätssicherung sollten jedoch die Konvertierungsalgorithmen dokumentiert werden. Tauchen später Fehler in den Daten auf, können hier mögliche Ursachen aufgedeckt werden. Interne Programme, oft Ergebnis von User-Development, werden kaum dokumentiert. Wenn ein Mitarbeiter für sich selbst ein VBA-Makro zur Rationalisierung seiner Office-Arbeit schreibt, dann verbleibt das Wissen bei ihm. Vielleicht könnte man aber im gesamten Unternehmen große Effekte durch den Einsatz dieses kleinen Makros erreichen. Hier muss allerdings vom Management der Publikationsaufwand für das Dokumentieren der Lösung entsprechend honoriert werden. Das Programm ist selbsterklärend. Bei diesem Argument muss bedacht werden, dass erheblich mehr an Aufwand notwendig ist, um eine gute, selbsterklärende Benutzeroberfläche zu erstellen. Damit entsteht die Benutzerdokumentation quasi online. Aber wo befinden sich die Installationshinweise? Dafür ist eine aufwendige Installationsroutine mit einem langen Dialog und dem Abtesten aller erdenklichen Konstellationen notwendig. Auch das kostet viel Zeit. Schließlich werden beim Benutzer Kenntnisse und Fertigkeiten im Umgang mit der Software vorausgesetzt, die er sich aus anderen Dokumentationen und Schulungsunterlagen bereits angeeignet hat. Selbsterklärende Software wird vom Markt nur dann angenommen, wenn es sich um den Nachbau bekannter Softwaresysteme handelt. Es mag spezielle Situationen geben, wo eine Dokumentation entfallen kann. In den meisten Fällen kann man bei einer Softwareentwicklung im großen Stil nicht auf eine Dokumentation verzichten, denn der Markt verlangt danach. Die Dokumentation schafft die Voraussetzung für eine langfristige, sichere Nutzung der Software. Der Entwickler kennt die Anwender in den meisten Fällen nicht. Erst mit der Dokumentation vermittelt der Entwickler sein Wissen über die Software an die Anwender.

3 4 Fast alle Vorgehensmodelle zur Softwareentwicklung verlangen eine strenge Verbindung von Entwicklungs- und Dokumentationsarbeiten. Die im Ergebnis des einen Schrittes erstellten Dokumente sind die Ausgangsbasis für die Arbeit im nächsten Entwicklungsschritt., womit man eine Grundphilosophie des Wasserfallmodells formulieren kann. Während des gesamten Entwicklungsprozesses entstehen Dokumente, und aus diesen Dokumenten lassen sich die oben beschriebenen Elemente der Softwaredokumentation schnell ableiten. Die Softwaredokumentation entsteht somit parallel zu den gesamten Entwicklungsarbeiten. 5 Formulardokumentationen werden durch Formularsätze realisiert, die Seite für Seite auszufüllen sind. An vielen Stellen ist der Eintrag nicht relevant zu finden, was durchaus berechtigt sein kann. Die Formulardokumentation entstand noch in der Zeit vor der Verbreitung der PCs und erfreute sich besonders in Großunternehmen einer hohen Akzeptanz. Sie sichert die Vollständigkeit und Einheitlichkeit der unternehmensinternen Dokumentation. Heute wird das Formular auf den Computer übertragen und ist dort auszufüllen, wobei zahlreiche Texte, wie Datumsangaben, Versionsnummern oder Namen der Autoren, automatisch generiert werden. Auch der Projektassistent zum V-Modell XT ist ein derartiger Formulargenerator. Zahlreiche Dokumente werden als Dateien in einem kompatiblen Textformat (*.rtf) erstellt und können dann mit einem Office-Editor ergänzt werden.

4 6 Die folgende Liste enthält eine Auswahl von anerkannten Normen zur Dokumentation in der Softwareentwicklung (Lehrbuch, Seite 322) Dokumentation Bezeichnung DIN EN ISO/IEC 6592:2000 ISO/IEC 18019:2004 ISO/IEC TR 9294:2005 DIN DIN DIN IEEE 1063 Inhalt Erstellen von Anleitungen; Gliederung, Inhalt und Darstellung (In dieser Norm sind allgemeine Grundlagen, detaillierte Anforderungen für den Entwurf und die Erstellung aller Arten von Anleitungen enthalten.) Information technology Guidelines for the documentation of computer-based application systems (Informationstechnik Leitfaden für die Dokumentation von computergestützten Anwendungssystemen) Software und System-Engineering-Richtlinien für die Gestaltung und Vorbereitung von Benutzerdokumentationen für Anwendungssoftware Richtlinien für die Handhabung der Softwaredokumentation Informationsverarbeitung; Sinnbilder und ihre Anwendung Informationsverarbeitung; Entscheidungstabelle, Beschreibungsmittel Informationsverarbeitung; Sinnbilder für Struktogramme nach Nassi-Shneiderman Standard for Software User Documentation 7 Die Installationshinweise fallen vom Umfang her sehr unterschiedlich aus. Früher sprach man in der DIN sogar vom Datenverarbeitungstechnischen Handbuch (DV-Handbuch). Heute geht es hauptsächlich um die Festlegung der systemtechnischen Voraussetzungen, die sehr genau beschrieben sein müssen. Für die Arbeit mit Java muss zum Beispiel klar definiert sein, dass die Laufzeitumgebung zu installieren ist, welche Bibliotheken in welcher Version zur Verfügung stehen und wie die Zugriffspfade vereinbart werden müssen. Simple Office-Anwendungen mit VBA-Makros scheitern hingegen regelmäßig an folgenden fehlenden Installationsvoraussetzungen: Verweise auf Objektbibliotheken, die nicht installiert sind feste Zugriffspfade im Quelltext Zu oft entsteht folgende Situation: Beim Entwickler funktioniert die Software, beim Kunden läuft nichts mehr, weil hier andere Einsatzbedingungen herrschen. Spätestens hier muss dem Entwickler bewusst werden, dass er sein Programm einem fremden Kunden in einer fremden Umgebung überlässt. Für die korrekte Einrichtung dieser notwendigen Umgebung sind dem Kunden die erforderlichen Hinweise zu geben.

5 8 Als Darstellungsmittel können in den Projektplanungsdokumenten beispielsweise eingesetzt werden: Netzplan Balkendiagramm Projektstrukturplan 9 Als Darstellungsmittel der Systemarchitektur in der Systemdokumentation eignen sich: Komponentenkataloge Schnittstellenübersichten Datenkataloge Design-Entwürfe 10 Das Tool javadoc erzeugt aus dokumentierenden Kommentaren innerhalb des Java-Quelltextes klassische HTML-Seiten. Dokumentierende Kommentare beginnen mit "/**" und enden mit "*/". Innerhalb des dokumentierenden Kommentars können HTML-Tags verwendet werden, um die Texte der HTML- Seiten speziell zu formatieren. Ferner gibt es eine Reihe von vorgefertigten javadoc-tags, die weitere Features in die HTML-Seiten integrieren. Die javadoc-tags beginnen mit dem Zeichen "@". 11 Alle Tools aus dem Bereich des Model Driven Developments erzeugen Quelltexte aus den modellmäßigen Beschreibungen, die wiederum sehr gut geeignet sind für die Dokumentation. Von den behandelten Tools sei hier nur auf SiSy verwiesen, wo man aus dem Entwurf den Quelltext generieren lassen kann. Natürlich ist das meistens kein direkt lauffähiger Quelltext, sondern nur ein logisches Gerüst. Das Quelltextgerüst muss noch vom Entwickler präzisiert werden. Ein anderes Beispiel bietet Microsoft Access, wo man bei Abfragen in der Entwurfsansicht ein grafisches Modell erstellt und in der SQL-Ansicht sofort den Quelltext der dazugehörenden SQL-Anweisung zu sehen bekommt. Das funktioniert in beiden Richtungen: Änderungen am SQL-Quelltext ändern auch die Grafik.

6 12 Der Projektassistent zum V-Modell XT kann zum Generieren zahlreicher Teile der Softwaredokumentation genutzt werden. Der Projektassistent bietet damit die Möglichkeit zur Formulardokumentation. Hier können nur einige Beispiele aufgeführt werden: 1. Planungsdokumente: Projekthandbuch Projektplan Risikoliste Qualitätssicherungshandbuch (QS-Handbuch) 2. Dokumente für Entwurf und Implementierung Systemarchitektur Datenbankentwurf Mensch-Maschine-Schnittstelle Programmdokumentation 3. Anwenderdokumentation Ausbildungsunterlagen Nutzungsdokumente