[IT kompakt] Systemanalyse kompakt || Das wichtige Wissen richtig verwalten

5Das wichtigeWissenrichtig verwalten

Wie Sie das für die Analyse Ihres Systems relevante Wissen ermittelnund dokumentieren können, haben Sie in den vorangegangenen Kapi-teln erfahren. Nun werden wir uns darauf konzentrieren, was es beimVerwalten von Wissen zu beachten gilt. Aber was bedeutet eigentlich„verwalten“ im Zusammenhang mit der Systemanalyse? Das Verwaltenvon Wissen bedeutet hier:

• eine Unmenge von Informationen unterschiedlichster Ausdrucksfor-men und Inhalte aktuell zu halten,

• Informationen miteinander zu verknüpfen,• Widerspruchsfreiheit über die Gesamtheit aller Informationen zu ge-

währleisten,• die optimale Sichtweise auf Informationsinhalte für verschiedene Le-

ser sicherzustellen,• die gewonnenen Informationen so zu strukturieren, dass benötigte In-

formationen schnell auffindbar sind.

Verwalten ist ein andauernder Prozess, der vor dem Projektstart mit demErheben der ersten Visionen, Ideen oder Probleme beginnt, bis zumLebensende des Systems andauert und die Ordnung all Ihrer Dokumen-tationen zu diesem System sichert.

In den folgenden Abschnitten werden Sie erfahren, welche Informa-tionen verwaltet werden, was es bei der Strukturierung der Informationenzu beachten gilt und wie Sie aktuell benötigte Informationen aus der Ge-samtheit aller Dokumente herausfiltern können.

89SOPHIST GmbH, C. Rupp, Systemanalyse kompakt, IT kompakt,DOI 10.1007/978-3-642-35446-5_5, © Springer-Verlag Berlin Heidelberg 2013

90 5 Das wichtige Wissen richtig verwalten

Es sei hier darauf hingewiesen, dass der Begriff Informationen in die-sem Kapitel allgemein für jegliche Arten von Repräsentation von Wissen(Text-Dokumente, Modelle usw.) steht.

5.1 Wegwerfen, Aufheben oder Aktualisieren?

Was sollte lieber weggeworfen oder gleichweggelassen werden?

Um die Aufwände für das Verwalten von Wissen möglichst gering zuhalten, sollten Sie sich auf die Informationen beschränken, die im Projektwirklich benötigt werden. Die Praxis zeigt, dass oft Wissen gepflegt wird,das eigentlich nicht, oder nicht mehr, gebraucht wird. Dies geschieht oftnur, um Vorschriften Folge zu leisten, ohne diese zu reflektieren und siegegebenenfalls abzuschaffen. Wenn Sie Dokumentationen „wegwerfen“,können Sie Zeit gewinnen und sich verstärkt um das essenzielle Wissenkümmern. Um herauszufinden, welche Dokumente Sie verwalten müs-sen, sollten Sie sich folgende Fragen für jedes Dokument stellen:

• Welche Lesergruppe besteht auf die Informationen?• Gibt es einen Sponsor für dieses Dokument (jemanden, der sich für

das Dokument/den Inhalt des Dokuments verantwortlich fühlt)?• Gibt es eine andere Repräsentation des Dokuments, die den gleichen

Inhalt ebenfalls wiedergibt? (Redundanzen zwischen Dokumenten er-schweren die Pflege!)

• Gibt es Redundanzen innerhalb eines Dokumentes? (Redundanzen in-nerhalb eines Dokumentes können zwar die Lesbarkeit erleichtern,erschweren aber die Pflege!)

• Benötigen Sie dieses Dokument als Basis für konkrete Tätigkeiten:– für die Planung der Systementwicklung?– für die Entwicklung des Systems?– für den Test des Systems?– für die Wartung/Weiterentwicklung des Systems?– für die Anbindung des Systems an andere Systeme?– für die Kommunikation mit Ihren Stakeholdern?

5.1 Wegwerfen, Aufheben oder Aktualisieren? 91

• Was kann im schlimmsten Fall passieren, wenn dieses Dokumentnicht verwaltet, also weggeworfen wird?

• Kann dieses Dokument ad hoc, mit wenig Aufwand aktualisiert wer-den, falls es plötzlich benötigt wird?

Wenn diese Fragen für jedes Dokument beantwortet sind, werden Siefeststellen, welche Dokumente Sie wegwerfen können, welche Doku-mente prinzipiell zu welchem Zweck benötigt werden und welche Do-kumente besonders wichtig sind. Nach dieser Gewichtung der einzelnenDokumente nach ihrer aktuellen Wichtigkeit für Ihr Projekt können Siesich entscheiden, welche Dokumente verwaltet werden müssen. Über-flüssige Dokumente können erst einmal weggelassen werden. Besonderswichtigen Dokumenten widmen Sie besondere Aufmerksamkeit. Fallses in Ihrem Projektumfeld naheliegt, dass Sie später Dokumente für einanderes System wieder verwenden können, sollten Sie allerdings die-ses Wissen aufheben, auch wenn es aktuell nicht benötigt wird. Dadurchkönnen Sie in nachfolgenden Projekten einiges an Entwicklungskostensparen.

Wissen, das oftmals weggeworfen werden kann:

• Redundanzen zwischen Dokumenten (unterschiedliche Dokumentegeben den gleichen Inhalt wieder; trennen Sie sich vom umfangrei-cheren),

• Redundanzen innerhalb eines Dokumentes (erhöht in den meisten Fäl-len die Lesbarkeit, aber auch den Pflegeaufwand),

• Informationen, die von niemandem benötigt werden (z. B. Dokumen-te, die ihre Gültigkeit verloren haben).

Allerdings sollten Sie sich bewusst sein, dass gewisse Informationen red-undant sein sollten. Dazu gehören besonders Analyseergebnisse, die einehohe Kritikalität aufweisen (siehe dazu auch Kapitel „Systemanalyseim Überblick“, Abschnitt „Produkte der Analyse systematisch“). Diesebeleuchten eine Problemstellung häufig aus unterschiedlichen Blickwin-keln und in verschiedenen Detaillierungsgraden, um die Informationenmöglichst vollständig und für jeden Stakeholder verständlich zu be-schreiben. Sorgen Sie dafür, dass solche Dokumente nicht weggeworfen,sondern ständig aktualisiert werden.


Welches Wissen sollte aktualisiert werden?

Was zwingt Sie eigentlich dazu, Ihr Wissen ständig zu aktualisieren?Dass sich Anforderungen und damit die zu verwaltenden Informationenim Laufe der Projektlaufzeit ändern, hat viele Ursachen. Bei Dokumenta-tion der meisten Informationseinheiten wird von vornherein inkrementellvorgegangen, da das notwendige Wissen nicht in einem Zug erhobenwerden kann und einem gewissen Abstimmungsprozess unterliegt. AuchFortschritte in der Technik zwingen einen Systemanalytiker vor allembei längeren Projektlaufzeiten zu Änderungen an bereits ermitteltem unddokumentiertem Wissen. Weitere Faktoren, die Änderungen hervorru-fen, sind: veränderte Kundenbedürfnisse, neue politische, rechtliche odertechnische Randbedingungen oder auch Änderungen an der unterneh-mensinternen Organisation.

Unabhängig vom Änderungsgrund spielt die Art, wie dokumentiertwurde, eine große Rolle für den Änderungsaufwand. Generell gilt, dassDokumentationen umso häufiger geändert werden müssen, je konkreterund detaillierter sie sind.

Wohingegen Informationsinhalte weniger Änderungen unterworfensind, wenn

• sie abstrakt sind (also keine Beispiele oder konkrete Werte enthalten),• sie technikneutral sind (also keine Realisierungsentscheidungen ent-

halten),• sie unterschiedliche Systemebenen klar trennen (Verarbeitungslogik,

Präsentation, Speicherung),• sie keine Prozessabläufe enthalten.

Um den Aufwand für durchzuführende Änderungen möglichst gering zuhalten, sollte deshalb versucht werden, Informationen möglichst nachdiesen Faktoren zu gestalten. Vielleicht müssen Sie an einigen Stellendavon abweichen. Wenn es möglich ist, sollte jedoch dokumentiertesWissen so lange wie möglich in dieser Form gehalten und erst dann kon-kretisiert werden, wenn dies aktuell verlangt wird.

Pflicht-Anforderungen sollten Sie, unabhängig von der Art und Wei-se, wie Sie diese Informationen dokumentieren, ständig aktualisieren.Pflicht-Anforderungen sind letztendlich rechtlich verbindlich und solltendemnach nicht veralten.

5.1 Wegwerfen, Aufheben oder Aktualisieren? 93

Wissen, das oft ständig aktualisiert wird:

• Pflicht-Anforderungen an das neu zu erstellende System,• Pflicht-Anforderungen von/an andere Systeme (die sich auch ändern),• Pflicht-Anforderungen aus externen Quellen wie Standards (z. B.

GSM),• alle Arten von Modellen, auch Codes,• Testfälle.

Welches Wissen sollte aufgehoben werden?

Für ein paar Repräsentationen Ihres systemrelevanten Wissens müssenSie nur wenig Aufwand in deren Verwaltung investieren. In der Re-gel sind dies Dokumente, die im Vorfeld schon existiert haben unddie für das aktuelle Projekt relevant sind. Dazu zählen einzuhaltendeRichtlinien, Normen, Standards und Styleguides, auf die Sie sich be-ziehen müssen, oder auch Dokumentationen, die Sie für die Ist-Analyseeines bestehenden (Alt-)Systems heranziehen (Benutzerhandbuch, An-forderungsdokumente, Code). Bei solchen Repräsentationen von Wissengenügt eine einfache Archivierung, da sie nicht geändert werden müssenund auch keinem Abstimmungsprozess unterliegen, der die dort hinter-legten Informationen im Detail validiert.

Zu weiteren Dokumenten, in die kein besonderer Verwaltungsauf-wand investiert wird, zählen häufig Wunsch-, Absichts- und Vorschlags-anforderungen. Diese sind im Verhältnis zu den rechtlich verbindlichenDokumenten meist recht wenig und überschaubar zu verwalten. Falls Sieim aktuellen Projekt nicht dazu kommen, Wunsch-, Absichts- und Vor-schlagsanforderungen umzusetzen, heben Sie sie für das nächste Releaseoder für die nächste Version Ihres Systems auf.

Je nach Projektumfeld und Unternehmensstruktur sollten Sie sich ge-nerell überlegen, ob Wissen, das in dem aktuellen Projekt ermittelt wird,vielleicht später oder in einem zukünftigen Projekt benötigt wird (Wis-sen über wiederverwendbare Module, nicht funktionale Anforderungenetc.).

Wiederverwendung von Wissen ist ein sehr wichtiger Aspekt, der lei-der sehr häufig nicht genügend überdacht wird, da das Hauptaugenmerkmeistens auf das momentane Projekt gelenkt wird und keine Zeit daran


„verschwendet“ werden soll, für ein zukünftiges Projekt Zeit und Kos-ten zu investieren. Wenn Sie später allerdings auf bereits vorhandenesWissen zurückgreifen, kann bei der Verwendung von schon erprobtenSystemkomponenten viel Zeit, Geld und Aufwand gespart werden. Wie-derverwendbares Wissen sollte möglichst abstrakt und technikneutralbeschrieben sein, um das Anpassen des Wissens an den neuen Pro-jektkontext so einfach wie möglich zu gestalten. Insbesondere nichtfunktionale Anforderungen eignen sich zur Wiederverwendung.

Wissen, das meist aufgehoben werden sollte:

• Bestehende Beschreibungen eines Altsystems (Benutzerhandbücher,Anforderungsdokumente, Schulungsunterlagen),

• Codes,• Verträge,• einzuhaltende Normen, Richtlinien, Standards,• Konzeptunterlagen.

5.2 Rollen- undWorkflow-Modell

Dokumente werden in der Regel von vielen unterschiedlichen Personenerstellt, gelesen, weiterbearbeitet und abgezeichnet. Um Verantwor-tungsbereiche für die Bearbeitung von Dokumenten und einen Workflowfestlegen zu können, entwerfen Sie ein Rollenmodell. Dafür werden diebei der Systemanalyse involvierten Personen in Gruppen zusammen-gefasst, wenn sie ähnliche Aufgaben und Verantwortlichkeiten haben.Ziel des Rollenmodells ist es, alle Rollen zu identifizieren und ihnenEigenschaften zuzuordnen. Aufgabenbereiche und -abgrenzungen wer-den für jede Rolle definiert. Der Vorteil für die Projektbeteiligten liegtin der Transparenz, da ihnen klar gezeigt wird, für welchen Bereich siezuständig sind und was von ihnen erwartet wird. Abhängig von demvon Ihnen verwendeten Vorgehensmodell wird Ihnen eine Anzahl vonRollen vorgegeben (z. B. V-Modell 97). Falls Sie ein Vorgehensmodellgewählt haben, welches die Rollen ungenügend beschreibt, müssen Sieselbst Rollen definieren. Auf jeden Fall müssen Sie aber darauf achten,dass Sie das Rollenmodell auf die Schwerpunkte Ihres Projektes ausrich-ten.

5.2 Rollen- und Workflow-Modell 95

Abb. 5.1 Workflow einer Anforderung

Das Workflow-Modell legt die Lenkung von Dokumenten fest unddamit welche Rolle in welchem Teil des Lebenszyklus (Zustand) einesDokuments für dessen Bearbeitung zuständig ist. Durch den Entwurfdes Workflow-Modells stellen Sie sicher, dass alle notwendigen Ar-beitsschritte in einem festgelegten Ablauf durchgeführt werden. Denbeteiligten Personen wird dadurch die Möglichkeit gegeben, diejeni-gen Informationen zu suchen, die sie als nächstes bearbeiten müssen.Nach der Bearbeitung ordnet der Beteiligte dann die Informationen demnächsten Bearbeiter zu und so weiter. Bestandteil des Workflow-Modellsist auch ein definiertes Freigabewesen. Beispielhaft ist in Abb. 5.1 einWorkflow-Modell dargestellt.

Dabei geht es um die fachliche Freigabe von Dokumenten. Oftbearbeiten die für ein bestimmtes Problemgebiet verantwortlichen Per-sonen die Dokumente, für die sie die Verantwortung tragen, gar nicht.Allerdings müssen sie Dokumente abzeichnen und freigeben. Nur frei-gegebene Dokumente können weiterverarbeitet werden.

Je mehr Personen an dem Projekt beteiligt sind, und je mehr In-formationen verwaltet werden müssen, desto wichtiger ist es, dasWorkflow-Konzept zu etablieren. Dabei ist die Akzeptanz der betei-ligten Personen sehr wichtig. Deshalb sollten Sie bei der Einführungeines Workflow-Modells unter anderem fachliche, psychologische undgeografische Aspekte beachten.


5.3 Verbindungen zwischenAnforderungenmanagen – Traceability

Das Wissen, das für Ihre Systemanalyse benötigt wird, wird in einergewissen Struktur verwaltet (siehe dazu auch unten „Struktur der Ge-samtinformationen“). Allerdings wird dabei nicht bei A begonnen undbei Z aufgehört, sondern gerade zur Verfügung stehende oder eben erho-bene Informationen werden in diese Struktur einsortiert.

Um den Überblick über Ihr erhobenes Wissen nicht zu verlieren, soll-te zum einen der Lebenszyklus eines Dokumentes nachvollziehbar sein.Zum anderen muss ersichtlich sein, welche anderen Dokumente auf einerInformation aufbauen.

Bei der Erstellung einer Systemspezifikation beschreiben Sie einenTeil der realen Welt mit allen für Sie wichtigen Informationen. Dabeientsteht ein komplexes Werk, das möglichst in sich vollständig, frei vonRedundanzen und eindeutig sein sollte. Jedes Hinzufügen, Ändern odergar Löschen bringt diese Harmonie durcheinander. Sie brauchen also einVerfahren, mit dessen Hilfe Sie die Komplexität dieses Gebildes beherr-schen können und mit dem Sie nur den für die Ergänzung, Änderungoder Löschung relevanten Bereich betrachten können.

Aber wie funktioniert das? Jede neue Information basiert auf eineranderen. Jede Änderung hat einen Grund. Diese Zusammenhänge machtman sich zunutze und erreicht durch Verweise (engl. traces) zwischendiesen Informationen, dass die Entstehung eines Dokumentes bis zumaktuellen Stand nachvollziehbar ist und Redundanzen vermieden wer-den. Allerdings sollte man sich darüber im klaren sein, dass das Erstellenund Pflegen von Verweisen generell sehr viel Aufwand bedeutet.

Wir unterscheiden zwei Arten der Traceability: die horizontale unddie vertikale Traceability.

Vertikale Traceability

Durch die vertikale Traceability werden Anforderungen miteinanderverknüpft, die einen Sachverhalt auf verschiedenen Detailebenen bzw.aus verschiedenen Sichtweisen beschreiben. Dadurch können Sie die

5.3 Verbindungen zwischen Anforderungen managen – Traceability 97

Abb. 5.2 Vertikale Traceability

Historie einer Wissensrepräsentation nachvollziehen. Wenn z. B. eineAnforderung an das System implementiert wird, soll zum einen dereigentliche Grund für ihre Existenz ausgehend von den ursprünglich ein-mal formulierten Zielen an das System (oder an Teile davon) ableitbarsein. Zum anderen sollten diejenigen Dokumente, die auf den Anforde-rungen aufbauen, wie z. B. Testfälle oder ein OOA-Modell, ebenfalls mitden dazugehörigen Anforderungen verknüpft sein. Dieser Sachverhalt istin Abb. 5.2 schematisch dargestellt.

Wichtig wird die vertikale Traceability, wenn sich ganze Rahmen-bedingungen für ein System ändern: Wenn sich beispielsweise in einerspäteren Phase der Systemanalyse herausstellen sollte, dass eine ganzeBenutzergruppe des Systems wegfällt, kann dasjenige Wissen herausge-filtert werden, das für diese Benutzergruppe einmal definiert wurde.


Horizontale Traceability

Bei der horizontalen Traceability geht es darum, nachvollziehen zu kön-nen, welche weiteren Wissensrepräsentationen noch geändert werdenmüssen, falls eine bestimmte Wissensrepräsentation geändert wird. Dasheißt, man kann ein Verknüpfungsnetzwerk zwischen allen Wissensre-präsentationen oder sogar einzelnen Wissenseinheiten ziehen, die sichgegenseitig beeinflussen.

Im Gegensatz zur vertikalen steht bei der horizontalen Traceabilityder Aufwand in keinem Verhältnis zu dem zu erwartenden Nutzen. Eskostet immens viel Geld und dauert unverhältnismäßig lange, all dieseVerknüpfungen zu erstellen und zu pflegen. Eine Alternative dazu ist,sich darauf zu beschränken, sich im Bedarfsfall bei durchzuführendenÄnderungen an einem Dokument zu überlegen, welche weiteren von Än-derungen betroffen sind und diese dann zu aktualisieren. Seien Sie sichjedoch darüber im Klaren, dass die Gefahr größer ist, etwas Wichtiges zuübersehen.

Bei der horizontalen Traceability unterscheidet man die Pre-Requirements-Specification Traceability und die Post-Requirements-Specification Traceability. Pre bezeichnet dabei die Traceability von denAnforderungen zu den vorgelagerten (vor den Anforderung entstehen-den) Artefakten und Post die Traceability zu den nachgelagerten (nachden Anforderungen entstehenden) Artefakten.

5.4 Konfigurationen

Durch ein Konfigurationsmanagement können Sie dem bei der System-analyse entstehenden Chaos der unterschiedlichen Dokumentenständeund deren Bezug zu einzelnen Software-Produkten entgegenwirken.Durchgeführte Änderungen an Dokumenten und Software-Elementenhalten Sie mit dem Änderungsgrund, Zeitpunkt der Änderung und derverantwortlichen Person fest. Änderungswünsche und durchgeführte Än-derungen werden notiert.

Die während der Systemanalyse verwendeten Dokumente ordnenSie in einem Konfigurations-Identifikationsdokument den einzelnenSoftware-Produkten (definierte Bestandteile des Systems) zu. Dadurch

5.5 Änderungsmanagement 99

können Sie definierte Gesamtstände aller Produkte reproduzieren undWeiterentwicklungen rückgängig machen, falls sich diese als fehlerhafterwiesen haben.

Baseline

Eine Baseline wird erstellt, um den Inhalt und den Zustand einer Infor-mation zu einem gewissen Zeitpunkt festzuhalten.

Baselines werden häufig beim Erreichen von Meilensteinen erzeugt.Das herausragende Merkmal ist, dass die Informationen in einer Baselinenicht verändert werden können. Es ist also jederzeit möglich, den Standder Baseline einzusehen oder wiederherzustellen.

Versionsverwaltung

Eine wesentliche Rolle bei der Konfigurationsverwaltung spielen Ver-sionsnummern. Die Versionsverwaltung liefert ein definiertes Verfahrenfür deren Vergabe. Die Version eines Dokuments stellt den Stand einesDokuments zu einem bestimmten Zeitpunkt dar.

Generell sollten Sie für ein Dokument bei jeder größeren Änderung,mit Angabe des Grundes, eine neue Version erstellen. So bleibt dieEntwicklung des Dokuments nachvollziehbar, und durchgeführte Ände-rungen an dem Dokument können im Bedarfsfall rückgängig gemachtwerden. Wichtig neben dem Grund für die neue Version sind auch dieInformationen, wer die neue Version erstellt hat und wann diese neueVersion entstanden ist.

Bei der Erzeugung einer neuen Version von Dokumenten wird gleich-zeitig eine Kopie des Dokuments erzeugt. Veraltete Versionen bleiben soreproduzierbar.

5.5 Änderungsmanagement

Der Gedanke, dass einmal erhobenes Wissen über die gesamte Dauerdes Projektes seine Gültigkeit behält, würde zwar die Projektplanung


wesentlich erleichtern; aber Änderungen von Anforderungen und Sys-temzielen sind in der Systementwicklung unvermeidlich. Wenn dasÄnderungsmanagement nicht sorgfältig durchgeführt wird und die sichergebenden Änderungen nicht ordentlich im System berücksichtigt wer-den, kann das sehr große Auswirkungen auf das Projekt haben und denProjekterfolg massiv gefährden.

Die Gründe für sich ständig ändernde Anforderungen sind verschie-den. Der Kunde des Systems ändert mitunter im Laufe der Zeit seineWünsche an das System, die Technik entwickelt sich weiter, es werdenfachliche Fehler in den Dokumenten erkannt, das System soll erweitertwerden usw. Unabhängig vom Grund der Änderung gilt es, die Ände-rungswünsche definiert und strukturiert abzuwickeln. Es muss festgelegtwerden, wie die Änderungswünsche (Change Requests) erfasst werden,wie und durch wen diese bewertet werden und wie die Durchführung vonÄnderungen zu erfolgen hat. So formulieren Sie z. B. einen Änderungs-wunsch in einem extra dafür vorgesehenen Formular und geben dabeialle notwendigen Attribute an. Die wichtigsten Parameter dafür sind:

• Beschreibung der Änderung,• Änderungsgrund,• Hinweis auf die Dokumente und deren Baseline, auf die sich der Än-

derungsantrag bezieht,• Auswirkungen auf Systemkomponenten,• Darstellung des Ist-Zustandes,• Darstellung des Soll-Zustandes,• grobe Realisierungsvorschläge inkl. Aufwandsabschätzung(en) zur

Unterstützung der Entscheidung.

Der eingereichte Änderungsantrag wird anschließend beurteilt. Wennder Änderungsantrag angenommen wird, wird daraus ein Änderungsvor-schlag gemacht, der die durchzuführenden Änderungen im Hinblick aufdie Durchführung weiter konkretisiert. Der Änderungsvorschlag wird an-schließend in Auftrag gegeben und realisiert.

5.6 Sichten 101

Ziel

Use-Case 1

Anforderung 1 -Version 2

Version 1

Use-Case 2

Anforderung 2

Anforderung 2.1

Anforderung 2.2

Use-Case 3

Abb. 5.3 Zentrale Gliederung

5.6 Sichten

Struktur der Gesamt-Informationen

Um den Überblick über die Gesamtheit des dokumentierten Wissensnicht zu verlieren, ist die Strukturierung des Wissens immens wichtig.Prinzipiell gibt es dafür zwei Möglichkeiten. Entweder gibt es einen zen-tralen Einstiegspunkt über die Dokumente einer Dokumentationstechnikfür alle Gruppen von Dokumenten. Oder die Dokumente werden entspre-chend ihres Dokumenttyps getrennt voneinander strukturiert.

Strukturierung nach zentraler Dokumentationstechnik: Abhängig da-von, welche Dokumentationstechniken eingesetzt werden, wählen Sie alsEinstiegspunkt ein Dokument, das Ihr System grob beschreibt (z. B. Use-Case-Diagramme oder Anwendungsfälle).

Von diesen Überblicksdokumenten aus werden die nachfolgenden,detaillierteren Dokumente (Dokumente der anderen Dokumentations-techniken, wie z. B. natürlichsprachliche Anforderungen, Klassendia-gramme etc.) verlinkt. Dies ist schematisch in der Abb. 5.3 darge-


Abb. 5.4 Getrennte Gliederung

stellt. Die Dokumentationstechnik, die Sie als zentralen Einstiegspunktgewählt haben, gibt somit die Struktur vor (z. B. nach funktionalenGesichtspunkten, wenn die Use-Case-Diagramme die grundlegendenFunktionen des Systems beschreiben). Die dadurch entstehende Struk-tur kann gut bei der Navigation zu den verlinkten Dokumenten genutztwerden.

Wenn Sie Dokumente nach einem zentralen Einstiegspunkt struktu-rieren, sollten Sie auf eines achten: Die Struktur, die Sie durch die Wahldes Einstiegsdokumentes vorgeben, sollte die Sichtweise widerspiegeln,die für Sie am wichtigsten ist.

Strukturierung für getrennte Dokumentengruppen: Werden die ver-schiedenen Dokumentgruppen getrennt strukturiert, bestehen zwischenden einzelnen Dokumentationstechniken keine Verlinkungen (vgl. hier-zu Abb. 5.4). Der Zusammenhang zwischen den Dokumentgruppen wirddann nur über eine entsprechende Attribuierung der einzelnen Dokumen-te erreicht. Dabei wird jedes Dokument z. B. einer bestimmten Funktiondes Systems oder einer bestimmten Systemschicht zugeordnet. Das fol-gende Beispiel zeigt Dokumente, die nach dem Attribut „Workflow“sortiert angezeigt werden.

Bei dieser Art der Strukturierung ist es besonders wichtig, dass Siefür die einzelnen Dokumente diejenigen Attribute pflegen, nach denenSie Sichtweisen auf die Gesamtheit aller Informationen richten wollen.Unterstützung bei dem Finden von zusammengehörigen Dokumenten

5.6 Sichten 103

könnte Ihnen ein Suchmechanismus bieten, der Ihnen die erforderlichenInformationen aus allen Dokumentgruppen anzeigt.

In der Realität werden die Gesamt-Informationen in einer Mischformdieser beiden Möglichkeiten strukturiert. So sind alle Informationen übereinen zentralen Einstiegspunkt strukturiert und miteinander verlinkt. Dieeinzelnen Dokumente werden aber noch zusätzlich attributiert. Dadurchkönnen Sie sich z. B. alle zu einer bestimmten Funktionalität gehören-de Dokumente anzeigen lassen und durch Filtern der Dokumente nachbestimmten Attributwerten gleichzeitig die Informationen weiter ein-grenzen.

Für natürlichsprachliche Anforderungen gibt es einige Standards, diehäufig für die Strukturierung eines Anforderungsdokumentes benutztwerden (z. B. Volere, IEEE oder auch firmeninterne Standards). DieseStandards geben Ihnen Hinweise darauf, nach welchen Kriterien Spezi-fikationen gegliedert werden können.

Sichtweisen auf Dokumente

Meistens werden Sie es bei der Verwaltung von Informationen mit wirk-lich großen und in der Masse unübersichtlichen Datenbeständen zu tunhaben. Deshalb ist es wichtig, verschiedene Sichtweisen auf die zu ver-waltenden Dokumente einnehmen zu können.

Je nachdem zu welchem Zweck Informationen gebraucht werden, be-nötigt jeder Leser seine eigene spezielle Sichtweise. So wird z. B. einAnalytiker bei der Überprüfung der Korrektheit von Anwendungsfällenund den daraus abgeleiteten Anforderungen nur diese Dokumente ein-sehen wollen. Anforderungen, die nicht auf Anwendungsfällen basieren,sollten dabei ausgeschlossen werden. Oder ein Designer möchte dieje-nigen Anforderungen betrachten, aus denen ein OO-Modell abgeleitetwurde. Zu einer anderen Zeit wird er aber nur ganz bestimmte OO-Modelle aus der Gesamtheit aller Modelle bearbeiten.

Wie und welche Sichtweisen auf Dokumente gesetzt werden können,hängt stark von der zur Verfügung stehenden Infrastruktur ab. Falls dieVerwaltung von Informationen über die Ablage in einem File-System ge-löst wurde, werden Probleme entstehen. Die gewonnenen Informationen


können Sie dann nicht über Kriterien suchen, die über den Namen desFiles, Größe oder Ersteller hinausgehen.

Im Idealfall haben Sie zur Verwaltung von Wissen ein Werkzeug zurVerfügung, in dem Sie alle Ausprägungen von Wissen möglichst redun-danzfrei speichern können, unabhängig davon, ob es sich dabei „nur“ umText-Dokumente handelt oder auch um mit Grafik angereicherte. Dabeihat jedes Dokument Attribute, nach denen Sichten auf die Gesamtheitaller Dokumente gesetzt werden können, die jeder Stakeholder-Gruppedie benötigten Sichtweisen liefern.

Außerdem sollte dieses Werkzeug die Abhängigkeiten von Informa-tionen untereinander aufzeigen können und deren Verwaltung möglichstvereinfachen. Von Vorteil wäre die Unterstützung von Standardvor-gängen, z. B. eine automatische Versionierung, die bei Änderungen anDokumenten selbstständig den Bearbeiter, Datum und Änderungsgrunderfasst.

Attribute

Unabhängig von der Art der Wissensrepräsentation gibt es einige At-tribute, die für jede Information gepflegt werden müssen. Dadurch istsichergestellt, dass jedes Dokument anhand dieser Kriterien wiederge-funden werden kann.

Für alle Dokumente erforderliche Attribute sind:

• Zustand/Status:klassifiziert den Fertigstellungsgrad des Dokumentes (geplant, in Be-arbeitung, vorgelegt, akzeptiert, ...)

• Version:ermöglicht das Nachvollziehen der Entwicklung eines Dokumentsund warum es sich verändert hat

• Eindeutige Identifizierung:jedes einzelne Dokument ist anhand dieses Attributes eindeutig iden-tifizierbar und referenzierbar

• Kapitelstruktur:dient der Strukturierung des Dokuments

5.6 Sichten 105

• Autor:der Erfasser der Informationen

• Verantwortlicher:der fachlich Verantwortliche des Dokuments

• Workflow:für den nächsten Bearbeitungsschritt zuständige Person oder Rolle

• Signatur:gibt Auskunft darüber, wer das Dokument zu welchem Zeitpunkt ineinen anderen Zustand versetzt hat

• Änderungshistorie:gibt Auskunft darüber, wer das Dokument zu welchem Zeitpunkt ge-ändert hat

Die Attribute Zustand und Version sollten Sie in möglichst kleinen Ein-heiten pflegen, also z. B. bei einzelnen Anforderungen und nicht nurbei ganzen Anforderungsdokumenten. Dies hat den Vorteil, dass Sie dieArbeitsschritte, welche ein einzelnes Dokument durchläuft, sehr genausteuern können.

Wenn die definierten Zustände eines Dokuments dessen Fertigstel-lungsgrad möglichst präzise beschreiben, kann die Abschätzung desProjektfortschritts anhand der Zustände genau errechnet werden. BeiZustandsübergängen ist zudem eine gleichzeitige Versionierung des Do-kuments von Vorteil. So lässt sich jederzeit der Zustand eines Dokumentsvor dem Zustandsübergang reproduzieren.

Speziell für Anforderungen gibt es fünf weitere Attribute, die fachlichnotwendig sind:

• Detaillierungsebene (Level 0 bis maximal Level 4)• Art (funktional, technisch, Benutzerschnittstelle, Dienstqualität, sons-

tige Lieferbestandteile, Durchführung der Entwicklung, rechtlich/ver-traglich)

• rechtliche Verbindlichkeit (z. B. Wunsch, Absicht, Pflicht, Kommen-tar, Vorschlag)

• Rolle des Stakeholders (Management, Anwender,. . . )• Priorität bzw. Kritikalität (Hoch, Mittel, Gering, Keine)

Bei der Verwaltung dieser Attribute sollten Sie besonders auf die Festle-gung der rechtlichen Verbindlichkeit von Anforderungen achten. Pflicht-


Anforderungen müssen eindeutig als solche gekennzeichnet werden, umsich bei Termindruck ausschließlich auf sie konzentrieren zu können.

Auch Anforderungen, die eine hohe Priorität bzw. Kritikalität aufwei-sen, sollten sofort erkennbar sein. Ihnen wird besondere Aufmerksamkeitgewidmet, um den Projekterfolg nicht zu gefährden. Durch die Be-schreibung von Anforderungen auf verschiedenen Detaillierungsebenenermöglichen Sie es, das Anforderungsdokument zielgruppengerecht zulesen. So umreißen Sie z. B. mit Anwendungsfällen das System rechtgrob, und der Leser kann sich sehr schnell ein Bild vom Umfang desSystems machen. Ein Entwickler wird sich aber auf detailliertere An-forderungen konzentrieren, da er die Feinheiten von Funktionalitätenverstehen muss.

Anforderungen, die Sie nach deren Art unterscheiden, erhöhen dieLesbarkeit von Anforderungsdokumenten, forcieren die Wiederverwend-barkeit und erleichtern das Analysieren von Anforderungen. Insgesamtverbessern Sie dadurch auch die Sichtenbildung auf das Anforderungs-dokument.

Durch die Zuordnung von Stakeholder-Rollen zu Anforderungen er-möglichen Sie den einzelnen Projektbeteiligten die direkte Suche nachden für sie relevanten Dokumenten.

5.7 Tools

Es gibt viele Dinge, die bei der Verwaltung der Anforderung beachtetwerden müssen. Und viele lassen sich ohne Unterstützung durch einTool gar nicht oder nur unzureichend bewerkstelligen. Somit ist die Ver-wendung eines Tools für die Verwaltung von Anforderungen gerade ingroßen Projekten unerlässlich.

Das Tool muss mindestens folgende Aufgaben unterstützen:

• Verwalten verschiedener Informationen (Anforderungen, Modelle,Diagramme, . . .)

• Verwalten von Beziehungen zwischen den Informationen• Reports und Auswertungen erstellen• Bearbeiten der verwalteten Informationen• Organisieren der Informationen (Hierarchien, Gruppierungen).

5.7 Tools 107

Toolkategorien

Je nach ursprünglichem Einsatzzweck und Herkunft lässt sich die großeVielzahl an Tools in drei Kategorien einteilen: Platzhirsche, Mutantenund Stubenfliegen.

PlatzhirscheAls Platzhirsche werden Tools bezeichnet, die speziell für die Tätigkeitenund Herausforderungen in der Systemanalyse entwickelt wurden. DieseTools können Anforderungen und andere Informationen modellbasiertverwalten und diese meist hierarchisch organisieren. Tools aus die-ser Kategorie bieten ein ausgereiftes Versionsmanagement. Sie basierenüberwiegend auf Datenbanken mit einem Konfigurationsmanagementund der Möglichkeit, dass mehrere Benutzer daran arbeiten können. Zu-sammenfassend lässt sich sagen, dass diese Kategorie die Verwaltung derAnforderungen am besten unterstützt.

MutantenUnter Mutanten versteht man Tools, die in erster Linie nichts mit der Sys-temanalyse zu tun haben oder lediglich am Rande damit in Berührungkommen. Häufig handelt es sich dabei um Tools, die einen anderen Be-reich der Systementwicklung, wie zum Beispiel das Testen, unterstützen.Die Besonderheit ist, dass diese Tools mit Funktionalitäten angereichertworden sind, die in der Systemanalyse verwendet werden können.

Häufig existiert bei den Mutanten das Problem, dass bei weitem nichtalle Basisfunktionen eines Analysetools erfüllt werden. Das Interessantean diesen Mutanten ist aber, dass die Schnittstellenproblematik zwischenSystemanalyse und anderen Tools kaum noch gegeben ist.

StubenfliegenMit Stubenfliegen sind alle Arten von Standardtools gemeint, die anden meisten Arbeitsplätzen vorhanden sind. Hierzu zählen die diver-sen Textverarbeitungs-, Tabellenkalkulations- und Zeichenprogramme.Wichtig ist, dass diese Werkzeuge vordergründig nicht für die System-analyse entwickelt worden sind. Folglich kann man auch nicht erwarten,dass diese Werkzeuge mit einem für Systemanalyse-Belange umfangrei-chen Repertoire an Funktionalitäten ausgestattet sind. Für sehr kleine und


kurze Projekte in einem überschaubaren Team können diese Tools abergenutzt werden. Der Vorteil dieser Art von Tools ist, dass die meistenPersonen den Umgang mit diesen Tools bereits kennen und die Tools anden meisten Arbeitsplätzen auch vorhanden sind.

5.8 DerWeg zum richtigen Tool

Der Einsatz neuer Werkzeuge ist eine Entscheidung, die wohlüberlegtund gut vorbereitet sein sollte. Schließlich bedeutet ein neues Werk-zeug einen hohen finanziellen und administrativen Aufwand. Auch isthäufig viel Überzeugungsarbeit innerhalb des Teams, das mit dem Werk-zeug arbeiten muss, notwendig. Wichtig bei der Entscheidung für einoder mehrere Tools ist es, den Menschen, der damit arbeiten soll, nichtaus dem Blick zu verlieren. Auch muss das Tool die Methoden, die imProjekt verwendet werden sollen, unterstützen. Hierbei gilt immer, dieMethode bestimmt das Tool und nicht anders herum. Am einfachstenmerkt man sich die MMT-Regel. Erst die Menschen (M) zu einem Teamzusammenstellen, dann die Methode (M) festlegen und zuletzt ein geeig-netes Tool (T) auswählen.

Wie kommtman nun zum richtigen Tool?

Phase 1: Die VorauswahlIn der ersten Phase wird ein Fragebogen erstellt, um eine grobe Voraus-wahl der Tools zu treffen. Dieser Fragenbogen beinhaltet:

• Firmendaten des Herstellers• Markstellung• Lizenzinformationen• Supportdienstleistungen• Schulungsmöglichkeiten• Technische Voraussetzungen für den Tooleinsatz

Anhand der Antworten kann aus der Vielfalt der Hersteller und der Toolsbereits eine Vorauswahl getroffen werden. Der Sinn liegt darin, dass bei

5.8 Der Weg zum richtigen Tool 109

der detaillierteren Prüfung der Tools nicht mehr so viele Tools infragekommen und somit Aufwand reduziert wird.

Phase 2: Der KriterienkatalogFür die detaillierte Evaluierung der infrage kommenden Tools ist es not-wendig, verschiedene Sichtweisen in Betracht zu ziehen.

• Technische Sicht– Datenbank/Dateisystem– Betriebsystem– Andere Tools

• Prozesssicht (Methodendefinition)• Benutzersicht (Benutzer – Benutzer)• Produktsicht

– Dokumente– Reports

• Projektsicht (Management)• Betriebswirtschaftliche Sicht

– Folgekosten– Anschaffungskosten

Allerdings müssen Sie nicht zwangsläufig immer alle Sichtweisen be-trachten. Wählen Sie nur die aus, die für Sie wichtig erscheinen. Zuden gewählten Sichtweisen müssen Sie nun Anforderungen erheben (vgl.Kap. 3: Wissen professionell erheben). Das Ergebnis ist ein Katalog anAnforderungen an das zukünftige Tool. Allerdings sind nicht alle An-forderungen gleich wichtig. Es gibt Anforderungen, die wirklich einK.-o.-Kriterium darstellen, und andere, bei denen auch mal ein Auge zu-gedrückt werden kann. Diesbezüglich lohnt es sich, die Anforderungenzu gewichten (z. B. mittels Prozentzahlen oder Werten von eins bis drei).Als letzten Schritt für die Erstellung des Anforderungskatalogs müssenSie noch die Bewertungsskala festlegen (z. B. 0 = Anforderung nicht er-füllt, 1 = Anforderung zum Teil erfüllt und 2 = Anforderung vollständigerfüllt).

Phase 3: Die BewertungIn der letzten Phase der Toolauswahl müssen die infrage kommendenTools anhand des Kriterienkatalogs bewertet werden. Dafür müssen meh-


rere Tester bestimmt werden, die die einzelnen Kriterien in den Toolsabprüfen. Die Ergebnisse des Testens werden in den Kriterienkatalogübertragen. Zum Schluss können Sie die Ergebnisse miteinander verglei-chen. Hier sollten Sie auf jeden Fall die Gewichtung berücksichtigen.Beachten Sie auch, dass üblicherweise die Standardausführung des Toolsgetestet wird. Viele Tools bieten einige Anpassungsmöglichkeiten, wasdazu führen kann, dass eine gewünschte Funktionalität des Tools überAnpassungen erreicht werden kann. So kann aus einem Bewertungser-gebnis 0 einer Anforderung doch noch eine 1 werden.

Seien Sie nicht überrascht, wenn am Ende mehr als ein Tool als gleichgeeignet bewertet wird. Sie gehören zu einer glücklichen Minderheit,wenn das Gegenteil eintreten sollte. Um nun aus den zwei oder drei Sie-gern das passende Tool herauszupicken, gibt es nur noch einen letztenSchritt zu tun. Sie müssen sich für eins entscheiden.

5.9 Zusammenfassung

• Pflegen und aktualisieren Sie nur das, was jemandem explizit etwaswert ist!

• Sie sparen Zeit, Geld und Aufwand durch– Minimierung der Dokumentation (nur das Erzeugen und Pflegen,

was Ihrem Projekt wirklich konkret hilft oder dringend verlangtwird)

– Vermeidung von Redundanz (außer sie ist für die Akzeptanz not-wendig).

• Vermischen Sie nie aktuelle (= glaubwürdige) Dokumentation mitevtl. veralteter (= unglaubwürdiger) Dokumentation. Sie verspielendas Vertrauen in den Wahrheitsgehalt des Inhalts.

• Überlegen Sie sich von Anfang an, ob Sie eine Dokumentation zurWissenserhebung anlegen oder ob die Dokumente den Produktlebens-zyklus überleben sollen. Der Qualitätsanspruch unterscheidet sichdeutlich!

• Erarbeiten Sie sich für die Verwaltung von Wissen eine Vorge-hensweise, die Ihrem Projekt angepasst, dem Arbeitsprozess ihrer

5.9 Zusammenfassung 111

Mitarbeiter entgegenkommt und Ihnen das effektive Verwalten vonDokumenten ermöglicht.

• Wenn Sie sich über das in Ihrem Projekt relevante Vorgehen im Kla-ren sind, können Sie zehn geeignete Werkzeuge auswählen, die dasVerwalten erleichtern (dabei sollte Ihnen ein Werkzeug die Mög-lichkeit geben, beliebig durch Ihr Wissensnetz über einen einfachenEinstiegspunkt zu navigieren und die Dokumente nach der Sichtwei-se zu filtern, die Ihr aktuell benötigtes Wissen darstellt).

[IT kompakt] Systemanalyse kompakt || Das wichtige Wissen richtig verwalten

Documents

Transcript of [IT kompakt] Systemanalyse kompakt || Das wichtige Wissen richtig verwalten