Veröffentlichen auch Sie Ihre Arbeiten - es ist ganz einfach!
Mehr InfosDiplomarbeit, 2010, 68 Seiten
Diplomarbeit
1,7
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Ausgangssituation und Problemstellung
1.2 Ziel der Arbeit- Forschungsfrage
1.3 Methodisches Vorgehen
2 Standardisierung von Software
2.1 Grundlagen der Standardisierung
2.1.1 Notwendigkeit der Standardisierung
2.1.2 Vor- und Nachteile der Standardisierung
2.1.3 Der Standardisierungsprozess
2.1.4 Das KANO-Modell
2.2 Standardisierung mittels "`De- Kontextualisierung"'
2.2.1 Identifikation der Wiederverwendbarkeit
2.2.2 Identifikation der Kontextgrenze
2.2.3 Identifikation der Allgemeingültigkeit
2.2.4 Identifikation der Stakeholder
2.3 Formalisierung von Anforderungen
2.3.1 Das Dilemma der Softwareentwicklung
2.3.2 Grundlagen der Formalisierung
2.3.3 Formalisierung von Anforderungen
2.4 Formalisierungsmethoden
2.4.1 Ontologie-basierende Formalisierung
2.4.2 Normsprachliche Formalisierung
2.4.3 Modellierung
2.4.4 Eigenschaften der Formalisierungsmethoden
2.4.5 Zusammenfassung
3 Wissensmanagement
3.1 Grundlagen zum Thema "`Wissen"'
3.2 Bausteine des Wissensmanagements
3.3 Die Wissensträger im WM
3.3.1 Der Stakeholder
3.3.2 Der Wissensarbeiter
3.3.3 Die Wissenstreiber - Community of Practice (COP)
3.3.4 Die Wissensnutzer - Community of Interest (COI)
3.4 Methoden des Wissensmanagement
3.4.1 Wissenskarten nach Probst
3.4.2 Lessons Learned
3.4.3 Best Practice Sharing
3.4.4 Wissensmanager
3.4.5 Unterstützende Kreativitätstechniken
3.4.6 Befragungsmethoden
3.4.7 Beobachtung
3.4.8 Methode der Wissensfabriken-Experience Factory
3.5 Ausgewählte Instrumente des Wissensmanagements
3.5.1 Systematisierung
3.5.2 Intranet
3.5.3 Groupware
3.5.4 Weblogs
3.5.5 Enterprise Wiki
3.5.6 Knowledge-Mail
3.5.7 Enterprise Lösungen
4 Forschungsergebnis und Erkenntnisgewinn
4.1 Arbeitshypothese auf Basis der Forschungsfrage
4.2 Lösungsansatz zur Forschungsfrage
4.3 Perspektive 1-Analogiesuche
4.3.1 Analogie der Strukturen
4.3.2 Analogie des Prozesses
4.3.3 Analogie der Methoden
4.4 Perspektive 2- Bewertung der Methoden
4.4.1 Motivation
4.4.2 Terminologie der Bewertung
4.4.3 Bewertung der Methoden
4.4.4 Bewertung der Instrumente
4.5 Perspektive 3-Fallbeispiel
4.6 Zusammenfassung
5 Fazit und Ausblick
Literaturverzeichnis
Abkürzungsverzeichnis
Anlage 1 -Einzelbewertung der Wissensmanagement Methoden
Anlage 2 -Einzelbewertung der Wissensmanagement Instrumente ??
Das Bestreben in der klassischen Investitions- und Konsumgüterproduktion, im Handwerk, in der Landwirtschaft oder im Dienstleistungssektor permanent standardisierte Fertigungsverfahren zu entwickeln und anzuwenden, ist fast so alt wie diese Wirtschaftszweige selbst. In Standards wurde und wird noch immer das Wissen von wirtschaftlichen Einheiten kumuliert. So werden Produktentwicklungs- und Folgekosten gemindert, Ressourcen geschont und vor allem Kompatibilität zu anderen Produkten hergestellt.
Auch in der Softwareentwicklung ist man bestrebt, über standardisierte Produkte Entwicklungskosten zu senken und die Produkte so zu gestalten, dass sie einem breiten Markt zugänglich sind. Dem Standardisierungsgedanken steht jedoch entgegen, dass Unternehmen als Softwareanwender immer individuelle Vorstellungen haben und sich dementsprechend genau angepasste Software wünschen. Die Interessen des Herstellers und die des Nutzers weisen zunächst widersprüchlichen Charakter auf.
Kleine Hersteller oder Entwicklergruppen haben mit Individualentwicklungen häufig auch kein Problem, da sich alle Informationen über das Wissensgebiet bei einer kleinen Teamgröße organisatorisch gut handhaben lassen bzw. ein eigenständiger Selbstorganisationsprozess die Entwicklung trägt. Externe Eingriffe in die Arbeitsprozesse nach Taylor'schen Prinzipien wirken hier eher störend als fördernd.
Größere Hersteller mit vielen organisatorisch, inhaltlich und z.T. räumlich verteilten Teams können aus Effizienzgründen nicht permanent auf die individuellen Anforderungen und das spezielle Wissen des Nutzers eingehen. Hinzu kommt, dass Individuallösungen zahlreiche Nachteile aufweisen. Sie sind teurer, ihre Implementierung dauert länger und sie sind fehleranfälliger als Standardlösungen. Das sind Gründe, die auch die Anwender bei ihrer Entscheidung über Softwareanschaffungen berücksichtigen müssen. Denn sie haben die Folgekosten von nicht-standardisierten Lösungen zu tragen, indem sie eigenverantwortlich für den Support und die Weiterentwicklung aufkommen müssen. Dies bindet Ressourcen und ist technologisch kaum noch aufrechtzuerhalten. Hier treffen sich die Interessen von Hersteller und Nutzer wieder. Hersteller und Nutzer streben nun doch eine Konfliktlösung im Sinne von Produktstandards an, um die daraus resultierenden Vorteile in einer Win-win-Strategie zu nutzen.
Die Herausforderung und Problemstellung besteht in der Praxis darin, das verfügbare Wissens hinsichtlich der Kundenanforderungen und Software-Elemente aus den unterschiedlichen personellen und technischen Wissensträgern effektiv und so vollständig wie möglich zu gewinnen. Ohne Standardisierung werden immer wiederkehrende Fragestellungen immer und immer wieder neu durchdacht und programmiert. Die Ursachen hierfür liegen häufig in der heterogenen Verteilung des Wissens im Softwareunternehmen.
Diese für alle am Entwicklungsprozess beteiligten Personen unbefriedigende Situation gilt es zu überwinden, insbesondere um die Wissensaggregation und -organisation in Form der Standardisierung von Unternehmenssoftware voranzutreiben. Nur so können die Entwicklungskosten reduziert werden und die Produkte eine gefestigte breite Marktstellung erreichen. Einen möglichen Lösungsansatz bietet in diesem Zusammenhang das WM. Denn es sind bezogen auf die jeweilige Entwicklungsphase die Methoden, Ansätze und Tools des Umgangs mit Wissen auszuwählen und anzuwenden, die den Entwicklungsprozess hin zur Standardisierung effizient unterstützen.
Bisher fehlt eine Einschätzung der Möglichkeiten des Einsatzes von Methoden und Instrumenten des WM für die Standardisierung von Softwarelösungen. Ein entscheidender Faktor ist dabei jedoch auch die Anwendung der Methoden. Denn das Wissen über ihre Eignung und die Auswahl allein genügen nicht. Eine systematische Übersicht soll Entscheider, Projektmanager oder Entwickler bei den Standardisierungsbemühungen mit WM unterstützen. Dadurch soll der Umgang mit Wissen in Softwareprojekten professionalisiert werden.
Die aus der geschilderten Problemstellung abgeleitete Fragestellung findet ihren Ausdruck in der Forschungsfrage und soll im letzten Kapitel als Forschungsergebnis mit dem erforderlichen Erkenntnisgewinn dargestellt werden.
Forschungsfrage:
Kann im Zuge des Software- Entwicklungsprozesses die gezielte Anwendung von Methoden und Instrumenten des Wissensmanagement die Entwicklung standardisierter Softwareprodukte fördern und in welcher Phase der Softwareentwicklung sind diese einzusetzen?
Im ersten Kapitel werden die Ausgangssituation und Problemstellung, das Ziel und die Vorgehensweise sowie der Aufbau der Arbeit vorgestellt. Darauf folgt im zweiten Kapitel eine Darstellung der grundlegenden Ansätze und Anforderungen der Produkt- und Softwarestandardisierung. Anschließend wird ein Modell zum Umgang mit Standards mit Ausrichtung auf die Problemstellung entwickelt. Es soll die Anforderungen, die der Entwicklungs- und Standardisierungsprozess an das WM zur Identifikation von Standards stellt aufzeigen. Die darauf folgenden Abschnitte zur Formalisierung beschreiben die Anforderungen der Standardisierung an das WM zur Gewinnung von unternehmensbezogenem Wissen.
Abbildung in dieser Leseprobe nicht enthalten
Figure 1: Vorgehensweise schematisch (Quelle: Eigene Erstellung)
Im dritten Kapitel wird zur Entwicklung eines einführenden Verständnisses auf die theoretischen Grundlagen des WM eingegangen. Daran schließt sich die Erläuterung der Phasen im WM an. Mit der weiteren Präzisierung der Forschungsfrage wird der Lösungsansatz im vierten Kapitel eingeleitet. Die Lösung soll mit der Einnahme von drei Lösungsperspektiven, die die Fragestellung unter unterschiedlichen Sichtweisen erörtern, entwickelt und dargestellt werden. Mit der Zusammenfassung der Ergebnisse und einem Ausblick wird die Arbeit abgeschlossen.
Der Hersteller einer Softwarelösung ist auf den Input und das Fachwissen des Anwenders angewiesen, um sein Produkt wettbewerbsfähig zu halten. So ist schon während des Entwicklungsprozesses von Unternehmensanwendungen die Basis für die Entwicklung standardisierter Komponenten von Anwendungssoftware aus dem betriebswirtschaftlichen und technischen Wissen der Anwender zu legen. Das Standardisierungsproblem[1] bezüglich historisch gewachsener Softwarelösungen für spezielle Anwendungen stellt für die Softwarebranche eine der komplexesten organisatorischen und wirtschaftlichen Herausforderungen dar.
Softwareentwickler mit individuellen Lösungen für Unternehmensanwender kommen im Falle wachsender Verbreitung ihres Produkts und steigender Nachfrage nach ihren Entwicklungsleistungen nicht an einer Standardisierung der Funktionen ihres Softwareproduktes vorbei. Gründe dafür sind drohende Kapazitätsengpässe bei Projekten und ungenutzte Produktivitätssteigerungspotenziale. Die Gefahr vonseiten potenzieller Wettbewerber, mit einfacheren, funktionierenden Second-Best-Standard-Lösungen die Kunden zu gewinnen, lässt den Standardisierungsdruck ansteigen.
Es geht nicht zuletzt darum, Wissen, das in Form von speziellen Lösungen ausgeprägt wurde, auf ein verallgemeinertes erweitertes Spektrum von Problemstellungen anwendbar zu machen, um dadurch eine größere Wertschöpfung zu erreichen.
Die Standardisierung wirkt sich prinzipiell vorteilhaft auf den gesamten Produktzyklus und die Qualität von Software aus. Wie Hufgard dazu ausführt[2], determinieren die gesetzlichen Rahmenbedingungen eines nationalen Marktgebietes die zu standardisierenden Regeln und Methoden von Unternehmenssoftware in diesem Gebiet. Dies trifft beispielsweise in Deutschland zu, wo Steuergesetzgebung und Abgabenordnungen die Berechnungsmethoden stark standardisieren. Im internationalen Marktgefüge tragen Normen wie ISO, W3C etc. zur Standardisierungsentwicklung bei Anwendungssoftware bei. Für die Standardisierung spricht nach Hufgard auch ein einheitliches betriebswirtschaftliches Konzept, das standardisierend wirkt und nicht von Pseudo-Standards eines Anbieters in den Markt "`geschleust"' wird[3]. Ähnliche Unternehmenstypen konvergieren auch zu ähnlichen Anforderungen an Software und Softwarestandards. Hannig, Müller verbinden in diesem Sinne die Erhöhung der Produktzuverlässigkeit (Qualitätsaspekt) mit der Standardisierung und empfehlen die Anwendung von Quality Improvement Paradigm (OIP)[4]. Betriebswirtschaftliche Anwendungen wie SAP oder Oracle sind ein Ausdruck einer Produktstrategie mit hohem Standardisierungsanteil.
Nachteilig ist, dass die unmittelbare Wettbewerbswirksamkeit einer Lösung durch Standards verringert wird, da Anforderungen aus dem Vertrieb oder der Entwicklung nicht ungehindert auf spezielle Kundenwünsche mit nahe liegenden Lösungsansätzen umgesetzt werden können. Untersuchungen zufolge wirkt die Existenz unternehmensspezifischer Organisations- und Prozessstrukturen mit individuellen Benutzeranforderungen am stärksten gegen die Standardisierung[5]. Weitere Aspekte, die die Anwendung eines Standard konterkarrieren stellen unterschiedliche Betriebsgrößen und -typen sowie Branchenunterschiede dar.
So kommt es in der Praxis häufig vor, dass nicht in einer Standardsoftware vorhandene Funktionen in individuellen Zusatzschichten (mithilfe von Datenbank- oder Webprogrammierung) entwickelt werden, wodurch eine unmittelbare Wettbewerbswirksamkeit hergestellt werden kann. Hierunter werden jedoch die Vorteile des Einsatzes von Standardsoftware gemindert, da diese Funktionen immer individuell nachgeführt und besonders gewartet werden müssen. So kommt es wieder zu Wissensfragmentierung, da in diesem Zuge erworbenes Wissen um die Aufgabenstellung und Lösung der Verwendung ähnlich gelagerter Aufgabenstellungen entzogen wird.
Der Erfolg der industriellen Entwicklung des vergangenen Jahrhunderts beruhte u.a. zum großen Teil darauf, dass einzelne Produktfunktionen und Einzelelemente einer Standardisierungsstrategie unterzogen wurden, die letztlich deren Verbreitung und Akzeptanz förderte[6]. So zielt die Standardisierung nach Vahrenkamp auf eine auf den Markt ausgerichtete Anpassung von Produkten unter der Prämisse der Optimierung des Herstellungsprozesses[7]. Es bedarf also einer Möglichkeit, die Standardisierung der Funktionen und Produkte in den Herstellungsprozess zu integrieren. Nur so kann die erforderliche Marktdurchdringung erreicht werden.
So arbeiten derzeit beispielsweise verschiedene Hersteller von Fernsehgeräten daran, diese mittels eigener Technologien internetfähig zu machen. Die Marktdurchdringung bleibt jedoch aus, da die Kunden zunehmend keine proprietären Standards mehr akzeptieren[8]. Vor diesem Hintergrund stellt sich auch in der Softwareentwicklung die Frage nach der Standardisierbarkeit einzelner Funktionen oder ganzer Produkte und Produktfamilien, die die Wissenszusammenhänge immer wiederkehrender Kundenanforderungen in sich vereinen.
Herbig stellt Standards als eine Art "`kristallisiertes Wissen"', das die Basis für die Speicherung, Abfrage und Auswertung weiterer Informationen und letztlich Wissenszusammenhänge bildet, dar[9]. Dieser "`Kristallisationsprozess“ soll kurz näher betrachtet werden, da sich Brüsemeister in ähnlicher Weise äußert[10] und somit einen Hinweis für eine Zusammenhang zwischen der Wissensentwicklung und Standardisierung erkennbar ist: Brüsemeister stellt hierzu fest, dass experimentell gewonnenes (wissenschaftliches) Wissen im Labor durch Herauslösung der Forschungsgegenstände aus ihrem zeitlichen, räumlichen und inhaltlich reduzierten Kontext gewonnen wird. Somit wird Wissen überhaupt vergleichbar, reproduzierbar und einer Verallgemeinerbarkeit zugeführt.
Diese Betrachtung lässt sich auch auf die Gewinnung von Wissen im Software- Entwicklungsprozess übertragen. Bei der Standardisierung von Softwarefunktionen müssen komplexe Kundenanforderungen zunächst in Einzelteile zerlegt und abstrahiert werden, um sie auf ihre Allgemeingültigkeit prüfen und ihre Reproduzierbarkeit in anderen Anwendungsfällen gedanklich durchspielen zu können. Durch die Auftrennung der komplexen Aspekte in voneinander abgetrennte Einzelaspekte, können diese im Rahmen anderer komplexer Aspekte wiederverwendet werden. Aus einer aus Sicht des Kunden scheinbar trivialen Anforderung wie "`das System muss die jeweils gültige Energiesteuer richtig berechnen"' kann leicht ein umfangreiches Anforderungskonstrukt entstehen, das in Einzelfunktionen "`de-kontextualisiert"', also aus dem spezifischen Zusammenhang heraus gelöst werden muss.
Diesen Prozess, der De- Kontextualisierung führt Brüsemann unter dem Aspekt der "`Unwissenheit"' an[11]. Das ist so zu erklären, dass lokales, anwendernahes Wissen durch die Standardisierung zunächst in diesem untergeht. Erst nach der Standardisierung müssen diese Funktionen im Sinne von Brüsemann"`re- kontextualisiert"' werden. In diesem Sinne stellt auch der Einführungsprozess von Software beim Anwender eine "`Re- Kontextualisierung"' dar. Beispielsweise können die Auswahl der Software mittels Lastenheft, eine Datenmigration und im besonderen Maße kann auch das Customizing und die Schulung als "`Re-Kontextualisierung"' verstanden werden, da hier die anwendernahe die Ausprägung (Einstellung) der (Standard-) Softwarefunktionen auf das spezielle Anwendungsgebiet des Benutzers bzw. des Unternehmens stattfindet.
Die Kenntnis dieses Prozesses legt die Vermutung nahe, dass ein qualitativ hochwertiges auf Basis eines systematischen Wissenssmanagement getriebenes Verfahren der De- Kontextualisierung wiederum das Verfahren und die Möglichkeiten der Re-Kontextualisierung von Software verbessert. Fleischmann führt hierzu an[12], dass ca. 44 % aller Softwareprojekte aufgrund unzureichend definierter Anforderungen scheitern. Der Zeitaufwand für die Behebung von Fehlern in der Anforderungsbeschreibung steigt dabei in der Implementierungsphase auf über das 100-fache, im Falle einer Korrektur nach Auslieferung beim Kunden auf das 600-fache gegenüber dem Zeitaufwandes in der Anforderungsphase an.
Die De- Kontextualisierung kann dabei als Synonym für die hier betrachtete Gewinnung von Wissen und dessen Überführung in Standardfunktionen verstanden werden. Dies soll hier unter dem "`Prozess des organisierten Wissenstransfers"' bei der Standardisierung von Softwarefunktionen verstanden werden, die im Abschnitt 10 auf Seite ?? als Probst‘sche Bausteine des Wissensmanagements anzutreffen sind. Nachdem auf die Vor- und Nachteile der Standardisierung (siehe Abschnitt 2.1.2 auf Seite ??) eingegangen werden soll, wird im darauf folgenden Abschnitt auf das Prinzip der "`De- Kontextualisierung"' eingegangen, da damit u.a. die Basis für die Lösung der Forschungsfrage entwickelt werden soll.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2: Der Kontextualisierungsprozess (Eigene Erstellung)
Aus Abbildung 2 wird deutlich: Die Standardisierung führt zu einer Formalisierung von Wissen, welches implementiert in Software, einer Nutzung zugeführt wird. Die Formalisierung führt zu einer Strukturierung der Wissensinhalte des Fachgebietes, die sich mithilfe des KANO-Modells im nachfolgenden Abschnitt beschreiben lassen.
Das KANO-Modell wurde von Dr. Noriaki Kano 1978 vorgestellt. Es unterscheidet drei Kategorien von Produktfeatures, die die Zufriedenheit eines Kunden mit einem Produkt ausdrücken[13]. Im Modell wird eine Unterscheidung vorgenommen zwischen:
- Basisfaktoren, - diese repräsentieren vom Kunden als selbstverständlich vorausgesetzte Funktionen,
- Leistungsfaktoren, - diese werden bewusst verlangt bzw. vom Kunden als Sonderausstattung genannt und
- Begeisterungsfaktoren, welche der Kunde nicht kennt und erst während der Benutzung bemerkt und als positive Überraschung versteht
Abbildung in dieser Leseprobe nicht enthalten
Figure 3: KANO-Modell (Quelle:C.Rupp)
Es kann davon ausgegangen werden, dass es zunächst um die Standardisierung der Basis- und Leistungsfaktoren gehen kann, um die entsprechende Kunden- und Marktakzeptanz eines Produktes zu erlangen. Aus diesem Grund muss eine Vorstellung von einer Vorgehensweise entwickelt werden, um die Basis- und Leistungsfaktoren aus dem Fachgebiet des Anwenders zu erkennen und zu ermitteln.
Eine wesentliche Voraussetzung für die Identifikation eines Standards ist der wiederkehrende Charakter einer einzelnen oder einer geschlossenen Funktionalität. Hufgard beschreibt Standards und Normen [16] als etablierte Vorgehensweisen, die sich durch ihren vielfältigen Gebrauch von Vorgehensweisen mit individuellem Charakter unterscheiden. Der individuelle Charakter einer solchen Vorgehensweise ist dadurch gekennzeichnet, dass ein Akteur bestimmte Handlungen in immer gleicher Abfolge oder Grundstruktur durchläuft, diese aber fall- oder situationsbedingt variiert. Durch die ständige Variation ist die Handlung zunächst nicht "`immer gleich"' und so auch nicht ohne weiteres auf ein Computersystem übertragbar. Dies erklärt beispielsweise den Erfolg von Tabellenkalkulationsprogrammen, die dem Anwender immer Freiräume zur Variation ihrer wiederkehrenden Aufgaben "`erlauben"'. Diese Variationen von Standardfunktionen dienen in Softwareprojekten häufig als Vorlage oder Anforderungsbeschreibung. Die programmtechnische Umsetzung in Standardfunktionalität geht dann mit dem Verlust der Variationsmöglichkeiten einher.
Es stellt sich daher die Frage, wie die fachlich-technische Wiederverwendbarkeit von Softwarefunktionalität festgestellt werden kann. Böhm zieht[14] zu diesem Zweck drei Kontrollfragen zur Überprüfung der Wiederverwendbarkeit in einer Ex-post Betrachtung heran, die sich aber auch für eine Ex-ante Betrachtung nutzen lassen:
- Lassen sich Daten kapseln oder abstrakte Datentypen bilden?
- Ist die Isolierung von Ein- und Ausgabefunktionen erkennbar?
- Lassen sich anwendungs- und hardwarebezogene Funktionalität unabhängig voneinander realisieren?
Ergänzende Kriterien zur Sicherung der Beachtung (ex post) von Wiederverwendbarkeit von Softwarefunktionen stellt Böttcher auf[15]:
- Die Lösung soll alles einschließend, also allgemein sein.
- Die Lösung soll sauber von der speziellen Programmumgebung trennbar sein.
- Ist die Funktionalität getrennt von der Implementierung?[16]
Hannig stellt die Erfahrung der Wissensträger, die aus Softwareentwicklungsprojekten hervorgehen, in den Mittelpunkt der Erkennung von Wiederverwendbarkeit[17].Diese sollten in der Lage sein, unter Anwendung o.g. Kriterien Standards zu identifizieren
Welche ist nun eine geeignete Vorgehensweise, wiederverwendbare Funktionalität zu ermitteln?
Hierzu wird vom Autor folgendes Identifikationsmodell entwickelt:
Zunächst muss die Funktion durch Abstraktion vom konkreten Anwendungsbereich (beispielsweise dem Erfahrungskontext nach Hannig, Müller) getrennt werden. Die Komplexität wird dabei verringert. Dabei vollzieht sich ggf. eine Verfeinerung der ursprünglich identifizierten Funktion der Einzelbestandteile.
Anschließend sind diese Elemente auf ihre Verwendbarkeit in mindestens einem oder mehreren Anwendungsbereichen zu überprüfen (probeweise "`Re- Kontextualisierung"'). Hierzu eigenen sich Szenarios oder die Entwicklung von Testfällen für ähnliche Anwendungsgebiete. Die Funktionen sind möglichst einer Typisierung (entsprechend ihrer Bedeutung) zu unterziehen, um sie so besser innerhalb des Entwicklungsprozesses auffindbar und zuordenbar machen zu können.
Daran schließen sich ein Vergleich und eine Auswahl der ermittelten Funktionselemente unter Verwendung der Typisierung an.
Im letzten Schritt wird die Integrierbarkeit und Skalierbarkeit der invarianten Funktionselemente in mindestens einem oder auch mehr System- und Anwendungsbereichen geprüft. Dabei spielen neben den fachlich-technischen Kriterien (siehe Seite ?? die Wirtschaftlichkeit der Implementierung und der Wartung eine wichtige Rolle. Zur Überprüfung können die o.g. Kontrollfragen von Böttcher und Kriterien von Böhm herangezogen werden.
Die identifizierten Anforderungen mit Standardisierungspotenzial besitzen die Eigenschaft, zunächst einmal nur innerhalb der fachlichen, technischen und organisatorischen Systemgrenzen des konkreten Anwendungsbereiches uneingeschränkt gültig zu sein. Im Rahmen des Entwicklungsprozesses gilt es, die Grenzen dieser Gültigkeit auszuloten. Nach dem Schritt der De- Kontextualisierung kann dies leicht vorgenommen werden, da durch die Trennung vom ursprünglichen Anwendungskontext eine stufenweise Prüfung der Gültigkeit mittels Anwendung auf verwandte Anwendungsgebiete (z.B. durch einen Analogieschluss) vorgenommen werden kann. Mit dieser Vorgehensweise kann auch überprüft werden, inwieweit vorhandene Standardfunktionen auch in andere Anwendungsbereiche "`re- kontextualisiert"' werden können. Mit anderen Worten: Es soll geprüft werden, ob eine vorhandene Funktion auch woanders einsetzbar ist.
Pohl bezeichnet diese Einordnung als Kontextgrenze[18], da einerseits ein Anwendungsbereich nicht ohne Betrachtung seines Umfeldes existieren kann, andererseits aber eine Abgrenzung von dieser Umwelt vorgenommen werden muss. Wie aus der nachfolgenden Abbilung ?? erkennbar ist, misst Rupp der klaren Abgrenzung des Systems von seiner Umgebung in Form der Kontextgrenze und der Systemgrenzen fundamentale Bedeutung bei und geht soweit, von diesem Schritt den gesamten Projekterfolg abhängig[19] zu machen.
Abbildung in dieser Leseprobe nicht enthalten
Figure 4: Die Kontextbildung (Quelle: Rupp)
Das System hebt sich durch die Betrachtung der Stakeholder (siehe Abschnitt 2.2.4 auf Seite ??), der fließenden Nachrichten und Objekte von seiner Umwelt ab bzw. wird dadurch überhaupt identifizierbar. Gleiches gilt durch die Abgrenzung der Systemnutzung zu angrenzenden Systemen. Der Stakeholder stellt also die zentrale Figur bei der Identifikation oder Bestimmung der Kontextgrenzen dar.
Welche sind nun die Schritte, um eine Beschreibung der Kontextgrenze eines Systems und seiner Funktionen aus dem Fokus des Stakeholders vorzunehmen? Hierzu wird vom Autor folgendes Modell zur Identifikation der Kontextgrenze entwickelt:
Durch die Begrenzung eines Wissensgebietes auf eine Person oder Gruppe von Personen (Wissensträger) lassen sich wiederkehrende Handlungen und Anforderungen identifizieren und als Standard innerhalb einer Rolle qualifizieren (rollenbezogene Standardisierungsgrenze).
Durch die Festlegung einer organisatorischen Systemgrenze auf Personen (Akteure) oder Gruppen (Rollen) von Personen kann ein innerhalb dieser Systemgrenze liegendes Handlungselement der Person potenziell einer Standardisierung unterzogen werden (handlungsbezogene Standardisierungsgrenze). Dies setzt eine Einigung der beteiligten Akteure auf eine Handlungsabfolge voraus.
Die Standardisierung ist immer unter dem Aspekt der Begrenzung auf ein wirtschaftliches System (Person oder Organisationseinheit) zu betrachten. Die Grenze stellt ein definiertes Marktgebiet dar, auf das ein Wissensgebiet durch die Rollen- oder Wissensträger seine Anwendung findet (wirtschaftliche Standardisierungsgrenze).
Nach Feststellung des System-Kontextgrenze ist die Identifikation der Allgemeingültigkeit einer geforderten Funktionalität erforderlich. Hier kann die Klassifizierung nach Hufgard herangezogen werden[20]. Dabei wird eine Unterscheidung nach Verfahrensnormierung, Verwendungsstandardisierung und Ebene der Standardisierung vorgenommen. Diese Unterscheidung soll helfen, Softwarestandards von allgemeinen Unterscheidung nach Standards und Normen etwas loszulösen. Damit würden Gestaltungsfreiräume in der IT-Industrie geschaffen, so argumentiert Hufgard. Die Klassifizierung stellt sich wie folgt dar:
Die Verfahrensnormierung fokussiert vom Standpunkt des Entwicklers die Formalisierung und Algorithmierung betriebswirtschaftlicher Methoden wie z.B. Brutto-/Nettorechnung. Ziel des Entwicklers ist es, diese änderungsstabilen Funktionen in festen Verfahrensabläufen in Programmbausteine zu überführen und bereitzustellen. Dabei werden die Schichten "`Datenstruktur"', "`Funktionsgestaltung"' und "`Ablaufgestaltung"' gebildet.
Die Verwendungsstandardisierung grenzt die zu entwickelnden Funktionsbausteine von Individualsoftware ab, indem die vielseitige Verwendung innerhalb verschiedener Umwelt- und Unternehmensbedingungen fokussiert wird. Für den einzelnen Programmbaustein sind die gültigen Umwelt- und Organisationsbedingungen abzustecken und einzugrenzen.
Die Ebene der Standardisierung aggregiert die Ebene der Funktion. Starre Lösungen, die "`out of the box"' verwendet werden, lassen keinen Spielraum für spezielle organisations- oder technisch bedingte anderweitige Verwendung. Eine Absenkung der Ebene erhöht die Flexibilität und Anpassbarkeit und damit das Einsatzgebiet um den Preis der Steigerung der Komplexität und des Anpassungsaufwandes.
Wie kann die Einschätzung der Allgemeingültigkeit einer Funktion vorgenommen werden? Hierzu wird folgendes Modell zur Identifikation der Allgemeingültigkeit einer Funktionalität entwickelt (siehe Abb. 5 auf Seite ??):
Zunächst wird eine Einstufung der Normierbarkeit der Funktion innerhalb des informationstechnischen Verfahrenskontextes nach "`gering"', "`mittel"' und "`hoch"' vorgenommen. Bewährt hat sich hier eine Betrachtung bzw. Vergleichsabstraktion der Funktion mit betriebswirtschaftlichen Standards oder etablierten Lösungsmustern (Stand der Technik oder Design Patterns), wie sie auch Hass aufgreift[21].
Die darauf folgende Einordnung der Ebene der Standardisierung schließt ausgeprägte Komplettlösungen aus, da hier lediglich Betrachtungen auf Funktions- und Komponentenebene durchgeführt werden.
Eine abschließende Einordnung in der Verwendungsstandardisierung ist durch die hier behandelte Themenstellung fixiert, da nur Standardlösungen betrachtet werden sollen.
Abbildung in dieser Leseprobe nicht enthalten
Figure 5: Klassifizierung des Standardisierungsgrades (Quelle: Eigene Erstellung, angelehnt an Hufgard)
Es kann also in Bezug auf Abb. 5 festgestellt werden: Eine Funktion lässt sich als allgemeingültig und standardisierbar identifizieren, wenn:
1. diese einen mittleren bis hohen Grad der Verwendungsnormierung aufweist,
2. durch die Funktion ein Trägersystem oder eine modulare Funktionsbibliothek repräsentiert wird,
3. wenn der Grad der Konvergenz der Anwendungsgebiete (zwischen Unternehmen) sehr hoch ist.
Wie im Abschnitt 2.1 ab Seite ?? dargestellt, ist eine Anforderung nur klar beschrieben, wenn die benötigten Bedingungen und Eigenschaften durch eine Person (Stakeholder) oder eine diese repräsentierende institutionelle Dokumentation legitimiert sind. Zusammengefasst wird dies unter dem Begriff Stakeholder der Anforderung, der ein Interesse an einer Standardfunktion hat[22]. Beispiele für Stakeholder sind Anwender, Entwickler, Business Consultants. Dem oft anzutreffenden Shareholder-Begriff ist in dieser rein fachlichen Sichtweise Sichtweise keine Bedeutung beigemessen.
Als Stakeholder sind in dem hier betrachteten Zusammenhang Wissensträger zu verstehen, die mit der zu entwickelnden Standardfunktion in Beziehung stehen. Sie sind Bestandteil des funktionalen Kontextes des Wissenszusammenhangs, ohne zwangsläufig direkt in Bezug zur Anwendungsfunktion zu stehen. Sie können aus einem übergeordneten Interessenkontext wie Daten- oder Rechtsschutz, Unternehmensstrategien oder als Repräsentanten einer Norm (z.B. DIN ISO) Einfluss auf die Standardisierung nehmen. Sie lassen sich auch als "`externe Stakeholder"' verstehen.
Die Funktionsanforderungen externer Stakeholder, die z.B. in Ausprägung einer der Normung (DIN, ISO, etc.) als Dokumente vorliegen und so als de facto standardisierbar gelten, müssen im Kontext des Wissens- bzw. des Anwendungsgebietes des bestehenden Softwaresystems interpretiert und in dieses transformiert werden. Andernfalls bestände die Gefahr, nicht integrierbare Funktionen zu entwickeln. Es ist also in der Regel nicht sinnvoll und einleuchtend, einen Einzelbestandteil einer Norm ohne Berücksichtigung des bestehenden Systemkontextes einer Anwendung 1:1 auszuprogrammieren.
In Bezug auf den hier verwendeten Betrachtungsgegenstand der Identifizierung von Standardfunktionen ist es wichtig, dass eine Einbeziehung der Wissensträger, die aufgrund ihrer fachlichen Kompetenz legitimiert sind, in den Prozess des Wissenstransfers stattfindet. Eine wichtige Anforderung besteht deshalb in der Auffindung und Einbeziehung der legitimierten Wissensträger. Anhand der fachlichen Kompetenz kann die "`Wertigkeit"' des Wissensträgers bzw. seiner Anforderungen bewertet werden, andernfalls besteht die Gefahr, dass unzulänglich qualifizierte Funktionen in den Standardisierungs- und Entwicklungsprozess einbezogen werden.
Potenzielle Standards müssen zunächst erkannt und eingegrenzt werden. Hierbei hilft die vorgestellte "`De- Kontextualisierung"' der Aktivitäten (Abstraktion und Abtrennung) der Anforderungen vom spezifischen Handlungskontext des Stakeholders. Die Identifikation beginnt unter der Berücksichtigung der Kompetenz mit der Ermittlung der geeigneten Stakeholder. Diese nehmen eine Kontextabgrenzung vor, in deren Rahmen verallgemeinerbare wiederkehrende Funktionen mittels geeigneter Methoden "`aufzuspüren"' sind.
Der sich anschließende Schritt besteht nun in der Formalisierung der zunächst in natürlicher Sprach vorliegenden Beschreibungen der Stakeholder in einer für den Software- Entwicklungsprozess geeigneten Form.
Die Probleme der Softwareentwicklung, unabhängig von der Frage nach Standard- oder Sonderfunktionen, bestehen immer in der polaren Position zwischen Anwender (dem Wissensträger des fachlichen Kontextes) und Entwickler (dem Wissensträger des softwaretechnischen Kontextes). Der fachliche Wissensträger denkt in seiner Fachdomäne mit Begriffen und Regeln, die der Entwickler im schlimmsten Fall kaum oder gar nicht kennt. Der softwaretechnisch geprägte Wissensträger kann im Extremfall "`nur codieren"'.
[...]
[1] vgl. [5, 39]
[2] vgl. [16]
[3] vgl. [28]
[4] vgl. [12, S.194]
[5] vgl. [19, S.60]
[6] vgl. [5, S.131]
[7] vgl. [29, S.47]
[8] vgl. [28]
[9] [14, S.159]
[10] [4, S.30 ff.]
[11] vgl. [4, S.30]
[12] vgl. [8, S.15]
[13] vgl. [25, S.82]
[14] vgl. [6, S.116]
[15] vgl. [7, S.232]
[16] vgl. [7, S.232]
[17] vgl. [12, S.192]
[18] vgl. in [21, S.59]
[19] vgl. [25, S.72]
[20] vgl. [16]
[21] vgl. [11, S.23 ff.]
[22] vgl. [21, S.14]
Kommentare