MIP40 Methoden der Softwaredokumentation

CHM (compiled Help Modul) ist das Datei-Format für Windows Hilfe-Files. Als Systeme für PHP kämen z.B. – Doxygen, – phpDocumentor und – ROBODoc infrage.

Die Doxygen-Tags param und return heißen im phpDocumentor ebenfalls param und return.

Die den Doxygen-Tags author, version und todo entsprechenden Tags heißen im php- Documentor ebenfalls author, version und todo.

Die Doxygen-Tags class, union und def bedeuten:
– class <name>: Mit class wird eine Klasse dokumentiert
– union <name>: Mit union wird ein Datentyp union dokumentiert
– def <name>: Mit def werden Makros dokumentiert

Kriterien für eine betriebswirtschaftliche Sicht : – Wie hoch sind die Anschaffungskosten? – Wie hoch sind die Lizenzgebühren? – Wie hoch sind die Wartungskosten – Was wird für Anpassungen bezahlt? – Was kosten Schulungen?

Wie der Name schon sagt, ist ein Translation Memory, oder auch TM-System genannt, ein Speicher für Übersetzungen und zwar für die Übersetzungen, die durch einen menschlichen Übersetzer erstellt wurden. Es handelt sich hier also nicht um maschinelle Übersetzung: Das System speichert nur das, was der Übersetzer einträgt, es kann nicht selbst übersetzen. Es dient lediglich als Hilfsmittel für den Übersetzer.

XML ist eine Metasprache wie SGML, die es erlaubt, Inhalt und Layout strikt zu tren- nen. Dies wiederum ist eine wesentliche Eigenschaft, um verschiedene Ausgaben von Dokumenten aus einem Inhaltselement erstellen zu können. XML ist bedeutend einfa- cher als SGML und es gibt viele preiswerte Werkzeuge, die die Erstellung von XML- Dokumente erleichtern.

Task:
+ Statt topic heißt es nun task und statt body taskbody.
+ In taskbody gibt es 3 wesentliche Elemente context, steps und result.
   – In context werden Hintergrundinformationen zu dem Task gespeichert.
   – In steps werden die einzelnen Schritte hinterlegt, um den Task auszuführen.
   – In result wird das erwartete Ergebnis nach Ausführung angegeben.

Reference:
- Statt topic heißt es nun reference und statt body refbody.
- In refbody gibt es drei wesentliche Elemente properties, refsync, examples.
   + In properties werden kurze Informationen zu dem reference-Element hinterlegt.
   + In refsyn wird die Syntax für die Verwendung des reference-Elements hinterlegt.
   + In examples werden Beispiele für die Verwendung angegeben.

Software ist im Gegensatz zu materiellen Produkten immateriell, unterliegt keiner Abnutzung und ist formal leicht änderbar. Inhaltlich korrekte Änderungen sind dagegen schwierig und aufwendig.

Software besteht nicht nur aus Programmcode, sondern aus zahlreichen Dokumenten und Unterlagen (beispielsweise Entwicklungs- und Benutzerdokumentation, Testproto- kolle, Testdaten, Entwürfe, Geschäftsprozessdarstellungen usw.). Diese Begleitunterlagen werden unter dem Begriff Artefakte zusammengefasst.

Der Softwarelebenszyklus lässt sich in die Phasen Entstehung, Entwicklung, Evolution, Erhaltung und Entsorgung unterteilen.

Refaktorierung ist die Änderung einer Software, bei der, äußerlich nicht erkennbar, nur das interne Design des Programmcodes verändert wird, ohne jedoch die Funktionen des Programms zu verändern.

Beim Management der Softwareentwicklung steht das Projektmanagement im Mittel- punkt. Es gibt klare Vorgaben der Ziele, der Zeiten, des Budgets und der Qualität für die Erstellung des Prototyps eines Softwareprodukts. Das Produktmanagement ist umfassender. Es müssen zusätzlich zu der Prototypentwicklung Weiterentwicklungsprojekte, laufende Wartungsprozesse und Produkteigenschaften geplant und gesteuert werden.

Man kann sich hierbei an den Maßnahmen des ISO/IEC Standards 12207 orientieren, der das folgende Vorgehen empfiehlt:
- Außerbetriebnahmeplan für
      + Archivierung der Software (inkl. Dokumentation),
      + Zeiträume des vollen oder teilweisen Supports,
      + Verantwortung für künftige Supportanfragen,
      + evtl. Übergang zu einem neuen System,
      + Zugriffe auf die archivierte Software,
- Absichtserklärung,
- Abkündigung,
- Außerbetriebnahme der Software,
- Archivierung der Baseline.

Der Schwerpunkt des Begriffs SW-Engineering lässt sich der Entstehungsphase der Software, also der (Neu-)Entwicklung des Prototyps eines Softwareprodukts zuordnen. SW-Reengineering ist auf die Weiterentwicklung, also die Evolution fokussiert. Diese Phase ist meist umfangreicher und aufwendiger als die Neuentwicklung, obwohl umfangreiche Reengineering-Projekte eher selten durchgeführt werden.

Es können hinsichtlich der Beurteilung der Alterung und des hieraus resultierenden Aufwands für Pflege und Wartung drei Typen von Software unterschieden werden: Wegwerfsoftware vom Typ S, statische Software mit geringem Wartungsbedarf vom Typ P (Problem Solving) und dynamische Softwareprodukte vom Typ E (Embedded), die eine permanente Anpassung und einen hohen Aufwand für die Maintenance erfordern.

Dynamische Software vom Typ E erfordert eine permanente Anpassung an veränderte Rahmenbedingungen. Werden diese Anpassungen unterlassen, entsteht ein lack of movement, der die Gebrauchsfähigkeit der Software beeinträchtigt. Eine zunehmende Anzahl von Wartungseingriffen befördert aufgrund der zunehmenden Komplexität die Gefahr unqualifizierter Eingriffe (ignorant surgery). Die wachsende Fehleranfälligkeit manifestiert sich als Phänomen der Alterung der Software.

Der Anteil des Aufwands für die Maintenance einer Software liegt bei ca. 2/3 des Gesamtaufwands der Softwarenutzung. Häufig wird die Lebensdauer der Software und damit der Anteil des Aufwands für die Maintenance unterschätzt.

Wir unterscheiden korrektive, präventive, adaptive und perfektionierende Wartung. Die Prozessgestaltung ist unabhängig von diesen Zielsetzungen. Sofern korrektive und adaptive Wartung überwiegend reaktiv ist und präventive und perfektionierende Wartung überwiegend proaktiv und damit besser planbar ist, lassen sich hierfür auch unterschiedliche Wartungsprozesse gestalten.

Mit zunehmender Alterung der Software kann man gegen Ende der SW-Lebensdauer aufgrund der Gesetzmäßigkeiten ignorant surgery, wachsender Entropie und sinkender Produktivität bei Wartungseingriffen von progressiv steigenden Wartungskosten ausgehen.

Die perfektionierende Wartung beansprucht mehr als die Hälfte (56 Prozent) des gesamten Aufwands der Softwarenutzung. Insgesamt verursacht die Maintenance ca. 2/3 der Kosten der Softwarenutzung.

Wenn der Index der Kosten für die Entdeckung und Beseitigung von Fehlern während der Testphase der Entwicklung bei 20 liegt, steigt dieser Index während des Betriebs auf 200 an, sodass man von einem Faktor 10 ausgehen kann. Für Designfehler steigen die Kosten der Fehlerbehebung mit Faktor 200/5 = 40 an.

Die Aufbauorganisation der Wartung kann aus Entwicklungs-, Instandhaltungs-, Test- und Architekturgruppe bestehen. Die maximale personelle Ausstattung kann jeweils eine Stelle für das Konfigurationsmanagement, die Produkt- und Anwenderbetreuung sowie das Qualitätsmanagement vorsehen.

Wartungsmaßnahmen werden in der Regel durch ein SPR oder ein CR eingeleitet. Das CCB muss, abhängig von der Dringlichkeit, über die Behandlung des SPR bzw. CR, das weitere Vorgehen, die Art der Umsetzung und die Paketierung der Auslieferung sowie über die Finanzierung (Kostenübernahme, Kostenstelle) entscheiden.

Üblicherweise werden drei Eskalationsstufen in Form des First, Second und Third level Support eingerichtet. Dies erleichtert die Benutzerunterstützung, sorgt für eine optimale Klassifizierung von SPRs und CRs und ermöglicht eine sinnvolle Nutzung der verfügbaren personellen Qualifikationen.

Im Wartungsprozess sollten Wartungsmitarbeiter, Testmanager, Konfigurationsmanager, Qualitätsmanager, Produktmanager und Validierer verfügbar sein. Eine rollenspezifische Stellenzuordnung ist nicht erforderlich, da für eine Stelle die Übernahme mehrerer Rollen und Funktionen möglich sein sollte.

Wartungsprozesse sind regelmäßige, gleich ablaufende Routineprozesse.

Projekte sind einmalige Vorhaben, bei denen innerhalb einer Zeitspanne mit einem vorgegebenen Budget ein definiertes Projektziel erreicht werden soll. Die Nutzung der Projektorganisation konzentriert sich auf die Weiterentwicklung in Form von Erweiterungs-, Sanierungs-, Migrations- und Integrationsprojekten.

Das SWKM übernimmt Verwaltungs-, Steuerungs- und Überwachungsmaßnahmen bei der Entwicklung, Weiterentwicklung und der Wartung von Softwaresystemen. Hierzu gehören die Definition der zu verwaltenden Komponenten, die Festlegung von Verantwortlichkeiten und Zuständigkeiten für die Versionsverwaltung sowie die Festlegung von Verfahren, Werkzeugen und der Dokumentation. Zu den zahlreichen Elementen, die vom SWKM verwaltet werden, gehören Artefakte wie Dokumentationen, Projektunterlagen, Spezifikationen, Testpakete, Testergebnisse usw.

Das Änderungsmanagement übernimmt die Bearbeitung der Softwareproblemreports (SPR) und der Change Requests (CR) sowie die Vorbereitung der Entscheidungen des CCB. Hiefür sind Änderungsanträge zu prüfen, Aufwandschätzungen vorzunehmen sowie Bearbeitungszeiten zu schätzen und Prioritäten festzulegen.

Das Versions- und Releasemanagement übernimmt die Verwaltung von Programmkomponenten und den zugehörigen Artefakten, die bei den Entwicklungs- und Wartungsarbeiten anfallen. Das sind: Programmversionen, Varianten, Konfigurationen, Releases sowie Service Packs (Paketierungen).

Die Hauptkriterien der Wartbarkeit, die noch weiter untergliedert werden können, sind Änderbarkeit, Prüfbarkeit und Portabilität.

Zu den Produktstandards gehören die konstruktiven Maßnahmen der Qualitätssicherung, beispielsweise die Vorgabe von Dokumentationsstandards, die Einhaltung von Konstruktionsmerkmalen der Softwarearchitektur (z.B. Modularisierung, Kapselung, Wiederverwendung, Objektorientierung), Codierungsrichtlinien usw. Prozessstandards definieren Abläufe, die bei der Softwareentwicklung einzuhalten sind. Sie umfassen beispielsweise Vorgaben für die Spezifikations-, die Entwurfs-, die Validierungs- und die Testprozesse.

Die interne Dokumentation ist in den Programmcode integriert, die externe wird als gesonderte Dokumente getrennt geführt. Interne Dokumentation hat den Vorteil, dass sie dem Entwickler und Wartungsingenieur unmittelbar zur Verfügung steht, das Programmverstehen erleichtert und bei Änderungen einfacher zu pflegen und nachzuführen ist.

Die Dokumentation ist Mittel der Kommunikation, des Transfers und der Konservierung von Know-How sowie Grundlage systematischer Prüfungen und Reviews. Sie kann als Nachweis von Arbeitsergebnissen dienen. Nicht zuletzt ist die Dokumentation die wichtigste Informationsgrundlage der Maintenance.