Beiträge
Themengruppen
Recherche
Service
- Was ist Wissensmangement?
- Open Journal of Knowledge Management
- Artikel-Guidelines
- Newsletter
- Kalender
- Wissensmanagement-Anbieter
- Partner
- Mediadaten
Community
Sponsoren
- die Automatisierung des Softwareentwicklungsprozesses
- besseres Planen der Projekte und bessere Qualifikation der Mitarbeiter
- und die Wiederverwendbarkeit bereits entwickelter Komponenten in nachfolgenden Projekten.
- Entwicklungsrichtlinien und Projektpläne
- Anforderungen
- Designspezifikationen
- Quell- oder Objektcode
- Testpläne oder Testprogramme
- sowie Dokumentenstrukturen oder eine ganze Dokumentation.
- Spezifikation, in der die Funktionalität beschrieben ist,
- der Implementierung der Funktionen und des
- Datenmodells,
- Objektorientiertes Entwicklung von Programmen und Designelementen
- Formalisierte Beschreibungen der Anforderungen, des Design und eine möglichst darauf aufbauende automatisierte Quellcodeerzeugung.
- Verwendung von Hypertext
- Einsatz von Content Management Systemen zur Verwaltung von textuellen Objekten
- Subsystem-orientierte Entwicklungsmethoden
- Formalisierte Schnittstellenbeschreibungen
- Unter Konfigurationsmanagement stehende Wiederverwendungsbibliotheken
Wissensmanagement und Software Engineering - Wiederverwendbarkeit
13. September 2001 von Dr. Bernhard von GuretzkyDieses Papier ist der dritte Teil einer Serie von Artikeln, in der die Bedeutung des Wissensmanagement für das Software Engineering beschrieben wird. Die diesem Ziel dienenden Schlüsseltechnologien sind `Expert Assistance`, das `Kooperative Arbeiten`, `Projektmanagement und Decision Support`, die `Wiederverwendbarkeit` und das `Reverse Engineering`. Dieser Teil ist der `Wiederverwendbarkeit` gewidmet.
KM is the systematic and explicit management of policies, programs, practices and activities in the enterprise, which are involved in sharing, creating and applying of knowledge. The management of knowledge aims to enhance existing knowledge and its networking and reuse.
Josef Hofer-Aleis
1. Problemstellung
Die Anforderungen an den Softwareentwicklungsprozess wachsen ständig. Kürzere Entwicklungszeiten, bessere Qualität und Produktivität sowie höhere Komplexität bestimmen die Wettbewerbsfähigkeit in der Softwareindustrie. Hinzu kommt die in allen westlichen Industrieländer zur Zeit herrschende Knappheit an qualifizierten Softwareingenieuren (Stichwort `Greencard`). Prinzipiell gibt es drei Möglichkeiten, diesen äußeren und inneren Problemen zu begegnen:
Die beiden ersten Punkte und die Rolle, die das Wissensmanagement dabei spielt, sind in vorangegangenen Papieren bereits angerissen worden (`Reverse Engineering`: [2] und `Expert Assistance`: [1]).
Im Folgenden wird beschrieben, wie mit Hilfe des Wissensmanagements das vorhandene intellektuelle Kapital im Unternehmen genutzt werden kann, um durch Kombination der Methoden, Prozesse und Softwarewerkzeuge das Wissen – auch im `eingefrorenen` Zustand in Form von bereits entwickelten Objekten – aufzubereiten, in Projektteams zu verteilen und damit wiederzuverwenden.
2. Wiederverwendbare Komponenten
Mit Wiederverwendbarkeit (`reuse`) wird der Prozess bezeichnet, in dem bereits entwickelte, validierte und verifizierte Elemente katalogisiert und gespeichert werden, um sie in nachfolgenden Anwendungen und in anderen Systemumgebungen wieder zu benutzen. Solche Elemente heißen wiederverwendbare Komponenten - die Begriffe `Artefakt` oder `Objekt` werden i. F. als Synonym für `Komponente` benutzt - und sollten stets unter Konfigurationskontrolle stehen. Durch das Wiederverwenden von Objekten beginnt der Entwicklungsprozess nicht immer wieder von vorn, sondern bessere (bessere Qualität, höhere Zuverlässigkeit) Produkte können i.A. mit weniger Aufwand erstellt werden.
Historisch gesehen basiert der Softwareentwicklungsprozess schon seit langem auf der Wiederverwendbarkeit von Objekten. Betriebssysteme, Compiler, Bibliotheken mit Softwaremodulen, Text- oder Bildvorlagen sind bekannte Beispiele. Das Problem, das in diesem Papier adressiert wird, ist die Erstellung und die Benutzung von Objekten im Softwareentwicklungsprozess. Dabei geht es um folgende Typen von Komponenten:
Diese Komponenten sind nicht nur Teil des Entwicklungsprozesses, sondern auch integraler Bestandteil des Endprodukts.
3. Das Komponentenmodell
Die Wiederverwendbarkeit von Objekten wird nur dann erfolgreich praktiziert werden können, wenn sich sowohl die funktionalen als auch die nicht funktionalen Eigenschaften der Objekte auf die aktuellen Aufgaben des Benutzers abbilden lassen. Die Entwicklung wiederverwendbarer Objekte muss demnach auf dem Wissen über alle Eigenschaften dieser Artefakte basieren. In dem sog. `Komponentenmodell` wird die Komponente mitsamt ihren Eigenschaften beschrieben. Das Modell enthält sowohl den Definitionsteil, der zur späteren Identifizierung des Objekts notwendig ist als auch den Implementierungsteil, der zur Instantiierung (s.u.) des Objekts in anderer Umgebung benötigt wird:
Definitionsteil: | |
Funktionalität: | Welche Funktionen oder Dienste erfüllt das Objekt? |
Schnittstellen: | Wie kann die Funktionalität von außen erkannt werden? |
Analogien: | Eine Liste vergleichbarer Objekte |
Kosteninformation: | Welche Entwicklungskosten sind mit dem Objekt verbunden, welche Lizenzkosten fallen möglicherweise an? |
Sicherheitsinformation: | Enthält eine Liste von berechtigten Individuen, Funktionen oder Rollen und gibt Informationen über Nutzungsbeschränkungen in bestimmten Umgebungen. |
Anwendungsgebiet: | Für welche Anwendungen und in welchem Umfeld kommt das Objekt zum Einsatz? |
Implementierungsteil: | |
Anforderungen: | Welche Anforderungen und Systemressourcen sind für ein reibungsloses Funktionieren des Objektes notwendig? |
Innere Struktur: | Nach welchen Entwicklungsprinzipien wurde gearbeitet, welche Restriktionen gelten für das Objekt? |
äußere Struktur: | Was sind die wesentlichen Bausteine und Funktionsmerkmale, die das Objekt wiederverwendbar machen. |
Effizienz: | Wie effizient erfüllt das Objekt die Funktionen und welche funktionalen oder nicht funktionalen Einschränkungen sind im Einsatz zu berücksichtigen? |
Referenzen: | Welche anderen Komponenten werden benutzt und von welchen Komponenten wird es benutzt? |
Adaptierungsmöglichkeiten: | Wie kann das Objekt verändert bzw. angepasst werden? |
All diese Informationen sind wiederum integraler Bestandteil wiederverwendbarer Komponenten und müssen wenn möglich in objektorientierter Form mit ihnen zusammen verwaltet und gespeichert werden. Der Definitionsteil sollte dabei in standardisierter Form beschrieben werden, um die Vergleichbarkeit bei der Identifikation individueller Komponenten sicherzustellen.
4. Identifikation wiederverwendbarer Objekte
Der entscheidende Prozess ist das Identifizieren wiederverwendbarer Komponenten. Dies kann etwa durch einen Abgleich der Aufgaben und Ziele des Entwicklers - dem Benutzermodell (siehe [1]) - mit den Eigenschaften der Komponenten erfolgen, die in Projekt- oder Unternehmensbibliotheken beschrieben sind. Dieser Prozess ist im Grunde genommen nichts anderes als ein `Pattern matching`, setzt allerdings eine Metrik voraus, nach der `ähnliche` Komponenten als Kandidaten ausgewählt werden können, falls eine hundertprozentige Übereinstimmung der geforderten Eigenschaften nicht zu erzielen ist. Selbst wenn kein geeignetes Objekt ausgewählt werden kann und damit eine Neuentwicklung notwendig wird, ist es sinnvoll geeignete Kandidaten als Entwicklungsbeispiele (lessons learnt, oder good practices) identifizieren zu können.
Dazu ist es notwendig, alle wiederverwendbaren Objekte zusammen mit dem zugehörigen Definitions- und Implementierungsteil dieser Objekte in sog. Wiederverwendungsbibliotheken (`reuse library`) zu verwalten. Neben diesem `Komponentenwissen‘ muss das Wissen über die zu entwickelnde Anwendung (`Anwendungswissen`) und über das Unternehmen und seine relevanten Funktionsbereiche (`Kontext- bzw. organisationales Wissen`) in den Such- und Auswahlprozess mit einfließen. Derartiges Wissen ist zwar implizit in den Komponenten enthalten, die Nutzung für Schlussfolgerungen oder eine spätere Wiederverwendung bedingt jedoch eine explizite Darstellung und Verwaltung dieses Wissens. Das Anwendungswissen ist deshalb so wichtig, da Software ein abstraktes Gebilde ist, das nicht wie der Grundriss eines Hauses von einem Architekten gezeichnet werden kann. Benutzer und Entwickler haben unterschiedliche Sichtweisen und setzen verschiedene Schwerpunkte. Beide Sichtweisen müssen angeglichen werden können: das Geschäftsmodell des Benutzers muss beispielsweise in ein Daten-, Funktions- oder Ablaufmodell des Entwicklers transformiert werden können.
Folgende Funktionen hat eine solche Wiederverwendungsbibliothek unabhängig von ihrer physischen Implementierung als Entity-relationship, relationaler oder objektorientierter Datenbank zu erfüllen:
Katalogisieren | ist die Beschreibung des Definitions- Implementierungsteils der Komponente und die Formalisierung der Charakteristiken der Wiederverwendbarkeit |
Speichern | ist das Speichern der Komponente in der Datenbank entsprechend der Katalogisierungskriterien |
Wiederfinden | ist der Suchprozess in der Datenbank nach der gewünschten Komponente. Üblicherweise führt dieser Suchprozess zu einer ganzen Auswahl möglicher Komponenten. |
Instantiieren | ist die Konstruktion einer maßgeschneiderten Komponente. |
Die beiden Prozesse `Katalogisieren` und `Wiederfinden` werden durch die Charakteristika des Definitionsteils und der Wiederverwendbarkeit bestimmt. Da jedoch der physische Zugriff auf die Wiederverwendungsbibliothek u.a. durch Sicherheits- oder Kostenrestriktionen bestimmt wird, kann das von Fall zu Fall zu unterschiedlichen Ergebnissen führen, selbst wenn die Auswahlkriterien dieselben sind.
5. Instantiierung wiederverwendbarer Komponenten
Mit Instantiierung einer Komponente bezeichnet man den Prozess, ein auf die Anforderungen zugeschnittenes Objekt aus der Bibliothek wiederverwendbarer Komponenten zu erstellen. Man unterscheidet drei verschiedene Arten der Instantiierung von Komponenten. Vom
(i) | Erzeugen | spricht man, wenn eine Prozedur existiert, die geforderte Komponente aus einer vorhandenen Spezifikationen oder Implementierung zu entwickeln. Diese Prozedur muss ebenfalls Regeln und Parameter für die Instantiierung des Objekts enthalten. |
|
(ii) | Anpassen | spricht man, wenn eine vorhandene Komponente schon `fast` den Anforderungen entspricht. Eine angepasste Komponente ist eine Variante einer bereits existierenden. Der Term `fast` impliziert sowohl das Vorhandensein einer Metrik, nach der die Passgenauigkeit der geforderten Eigenschaften beurteilt werden kann als auch die Möglichkeit, `geringfügige` funktionale oder nicht funktionale Änderungen durchführen zu können. |
|
(iii) | Konfigurieren | spricht man, wenn die Anforderungen zu einer Spezifikation führen, diese jedoch noch implementiert werden muss, d.h. die geforderte Komponente kann aus einer Bibliothek bereits vorhandener Objekte konfiguriert werden. |
|
Beim Erzeugen und beim Anpassen von Komponenten ist vorher zu prüfen, ob diese Prozesse aufwendiger sind als eine komplette Neuentwicklung. Beim Konfigurieren tritt dieses Problem selten auf, da mit Hilfe eines Konfigurationsmanagements der Instantiierungsprozess weitgehend automatisiert werden kann.
6. Entwicklung wiederverwendbarer Komponenten
Wiederverwendbarkeit ist keine Eigenschaft, die nachträglich einer Komponente hinzugefügt werden kann. Die Entwicklung einer wiederverwendbaren Komponente muss von Anfang an als solche geplant werden. Die Wahrscheinlichkeit, dass ein Objekt in nachfolgenden Projekten wiederverwendet wird, steigt, wenn es zur Lösung einer allgemeine Klasse von Problemen entwickelt wurde, anstatt ein ganz spezielles Problem zu behandeln. Andererseits kann der Aufwand für die Anpassen des Objekts zu groß werden, wenn das Anwendungsgebiet zu allgemein und zu wenig eingegrenzt ist.
Bei der Entwicklung wiederverwendbarer Komponenten müssen die sich aus dem Komponentenmodell abgeleiteten Aufgaben Bestand des Softwareentwicklungsmodell sein. Folgende Prinzipien sind dabei zu berücksichtigen:
(a) | Verständlichkeit: | Die Funktionalität muß vom potentiellen Nutzer leicht verstanden werden können |
(b) | Modularität und Parametrisierung: | Funktions-, Daten- oder Textelemente sind in disjunkten Gruppen zusammenzufassen und einer Objekthierarchie unterzuordnen |
(c) | Integrität und Kapselung: | Jeglicher Daten- oder Informationsaustausch darf nur über definierte Schnittstellen erfolgen. Die definierten Schnittstellen sind der einzige `Zugang` zu der Komponente. |
(d) | Information hiding: | Die Ausführung der Funktionen und die Verarbeitung der Ein- und Ausgangsdaten erfolgt nur innerhalb der Komponente und bleibt dem Nutzer verborgen. Einen direkten Zugang zum Objekt außerhalb der Schnittstellen ist nicht möglich. Dadurch kann die Funktionalität innerhalb der Komponente angepasst werden ohne eine Änderung der Schnittstellendefinition |
(e) | Anpassbarkeit: | In jeder weiteren Anwendung einer Komponente werden i.A. nur einige Funktionen vom Benutzer benötigt. Daher muss die Möglichkeit bestehen, eine personalisierte Funktionalität des Objekts zu definieren, wobei jedes Objekt aus drei Teilen besteht, nämlich der wobei das Objekt von `außen` mit seinen Anforderungen und von `innen` mit seiner funktionalen Darstellung der Anforderungen betrachtet werden kann |
(f) | Lesbarkeit durch Werkzeuge: | Der Prozess der Wiederverwendbarkeit sollte mechanisiert, d.h. durch Datenbanktechniken unterstützt werden können. Der Beschreibung der Eigenschaften muss daher formalisierbar sein. |
Die folgenden Methoden dienen gewöhnlich der Entwicklung wiederverwendbarer Objekte:
Infolge der unzureichenden Importmöglichkeiten von Altanwendungen in derartige Wiederverwendungsbibliotheken bezieht sich die Wiederverwendbarkeit oft nur auf solche Komponenten, die mit Hilfe der entsprechenden Werkzeuge zum Computer Aided Software Engineering entwickelt wurden. Daher ist die systematische Unterstützung bei der Entwicklung wiederverwendbarer Objekte so wichtig. Zum einen müssen die im vorangegangenen Abschnitt aufgeführten Punkte (a) bis (f) Teil des Vorgehensmodell sein und jede Abweichung dieser Regeln bei der Erstellung von Komponenten zur Ablehnung des Systems führen. Zum anderen muss die Entwicklungsumgebung das Erzeugen, Anpassen und Konfigurieren von Objekten unterstützen.
Das Wiederverwenden von Komponenten wird gewöhnlich zu Restriktionen an das zu entwickelnde System führen. Darüber hinaus ist die Entwicklung wiederverwendbarer Komponenten i.A. aufwendiger als die von Objekten, die nicht wiederverwendet werden sollen. Daher ist möglichst früh im Softwareentwicklungsprozess die Frage zu klären, ob Komponenten prinzipiell wiederverwendet werden sollen. Die Entscheidung dafür sollte auf Basis einer Kosten-Nutzen-Analyse erfolgen, wobei allerdings neben den Kosten- und Produktivitätsfaktoren auch die Zuverlässigkeit und Qualität möglicher Kandidaten berücksichtigt werden müssen.
7. Reverse Engineering und Wiederverwendbarkeit
Unter Reverse Engineering (siehe [2]) versteht man die Identifizierung von Systemkomponenten und deren Beziehungen untereinander sowie die Erstellung von Dokumenten auf einer höheren Abstraktionsstufe aus dem Quellcode `ähnlicher` Systeme. Bezogen auf die Entwurfs- und Analysephase bedeutet Reverse Engineering die Wiedererlangung des vollständigen Softwareentwurfs und der Spezifikation aus dem Quellcode und anderen Dokumentationsmaterialien (`Re-Spezifikation`). Re-Spezifizierungs-Systeme können mit Hilfe von Anwendungswissen und Wissen über die Methoden der Anforderungsanalyse derartige Prozesse steuern und unterstützen.
Allgemein gesprochen ist Reverse Engineering also nichts anderes als eine Programmtransformation zur Entwicklung validierter und verifizierter Komponenten. Durch Anwendung von Transformationsregeln werden aus einer oder mehreren existierenden und bereits validierten Komponenten neue erzeugt, die dem Anforderungskatalog entsprechen. In diesem Sinne ist das Reverse Engineering nichts anderes als das Anpassen oder Konfigurieren wiederverwendbarer Komponenten.
8. Problemfelder
Wiederverwendbarkeit bedeutet Teilen von Wissen und Nutzen von fremden Wissen, daher spielen noch andere als technische Aspekte sowohl bei der Entwicklung als auch bei der Benutzung von wiederverwendbaren Komponenten eine Rolle (siehe dazu die Ausführungen in [4]). So gibt es immer noch kulturelle Barrieren sowohl im Management wie bei den Systemanalysten oder Programmieren, den ganzen Softwareentwicklungsprozess vor dem Hintergrund der Wiederverwendbarkeit zu durchleuchten (`not invented here`).
Darüber hinaus sind politische oder rechtliche Hürden sowie unterschiedliche Dokumentations- und Entwicklungsstandards zu berücksichtigen. Auch das Copyright und Lizenzregelungen für außerhalb des Unternehmens entwickelte Objekte oder bei unternehmensübergreifenden Projekten ist zu beachten (s.a. [5]). So ist es auch eher unwahrscheinlich, dass Firmen Wiederverwendungsbibliotheken, die durch jahrelange Arbeit erworbenes propreritäres Wissen enthalten, mit Konkurrenten teilen oder austauschen, da deren Inhalt einen signifikanten kommerziellen Wert und damit einen möglichen Wettbewerbsvorteil darstellen.
9. Links
[1] www.c-o-k.de/cp_artikel_d.htm
[2] www.c-o-k.de/cp_artikel_d.htm
[3] www.iese.fhg.de/home/althoff/documents/pdf_files/seke99-handout.pdf
[4] www.c-o-k.de/cp_artikel.htm
[5] www.c-o-k.de/cp_artikel.htm
Kommentare
Das Kommentarsystem ist zurzeit deaktiviert.
Verwandte Beiträge
Schlagworte
Dieser Beitrag ist den folgenden Schlagworten zugeordnet