RECSS als ganzheitliches Vorgehensmodell zur Softwareauswahl

Inhaltsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Einsatzpotentiale und Grenzen in der Praxis

3 Beurteilung und Empfehlung zur Erweiterung

Literaturverzeichnis

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1 EINLEITUNG

Die vorliegende Abhandlung betrachtet die Einsatzmöglichkeiten von Vorgehensmodellen zur Anforderungsgewinnung sowie den Abgleich von An-forderungen mit möglichen Commercial-Off-The-Shelf (COTS) Softwarepaketen. Im Fokus steht das von Carvallo, Franch und Quer (2008) entwickelte Requirements Engineering for COTS-based Software Systems (RECSS) Modell.

Die Autoren stellen an das RECSS-Vorgehensmodell den Anspruch, ein generalisiertes Modell zu sein, welches sich dadurch auszeichnet, dass es durch die Betrachtung der Interdependenzen und Restriktionen innerhalb der Softwarelandschaft des betrachteten Unternehmens eine bessere Auswahl von COTS-Systemen ermöglicht. Fraglich ist dabei, ob das Modell diesem Anspruch in unterschiedlichen organisatorischen Umgebungen sowie im Hinblick auf aktuelle Entwicklungen der IT-Branche gerecht werden kann. Im Bereich der organisatorischen Umgebung fällt die Betrachtung auf die Umsetzbarkeit des RECSS-Vorgehensmodells für Unternehmen unterschiedlicher Größe, da davon aus-gegangen werden kann, dass gerade kleine und mittelständische Unternehmen (KMU) häufig nicht in der Lage sind, verschiedene Plattformstrategien zu evaluieren bzw. mehrere, sich teilweise gegenseitig ausschließende, Szenarien umzusetzen. Im Verlauf der Abhandlung wird gezeigt, dass der RECSS-Ansatz hinsichtlich der generellen An-wendbarkeit und dem Alleinstellungsmerkmal der Betrachtung der zugrundeliegenden Plattformstrategie zu hohe Anforderungen stellt und deshalb nur sehr eingeschränkt eingesetzt werden kann. Weiterhin ist davon auszugehen, dass im Rahmen der Ent-wicklung der IT-Branche zur Bereitstellung von Funktionen ,,on-demand" sowie neuen Modellen zum Softwareeinsatz, wie Software as a Service (SaaS) und Cloud Computing, das RECSS-Vorgehensmodell durch die steigende Komplexität nicht der Entwicklung zu schlanken, flexiblen Prozessen in Agilen Unternehmen standhalten kann (vgl. Schacher / Grässle 2006; vgl. Böhmann / Krcmar 2004; vgl. Weinhardt et al. 2009; vgl. Schmidt 2008).

Im Folgenden wird das RECSS-Vorgehensmodell kurz vorgestellt. Im Anschluss daran wird ermittelt, ob das Modell in der Praxis tatsächlich anwendbar ist und ob Ent-wicklungstendenzen für das Sourcing von Software mit dem Modell dargestellt und effizient umgesetzt werden können. Darüber hinaus wird betrachtet, ob ein Vergleich der Strategien zweckmäßig ist und gerade in Hinblick auf die Auslagerung von An-wendungen bzw. Funktionen sowie ganzer Infrastrukturbereiche zielführende Ergeb-nisse liefern kann. Im dritten Teil der Abhandlung wird eine abschließende Bewertung vorgenommen und es werden Vorschläge entwickelt, die durch Anpassungen des RECSS-Vorgehensmodells dessen Anwendbarkeit steigern können.

2 EINSATZPOTENTIALE UND GRENZEN IN DER PRAXIS

Das Vorgehensmodell des Requirements Engineering for COTS-based Software Systems ist durch ein vierschrittigen Ablauf gekennzeichnet. In einem ersten Schritt wird die Systemumgebung mit allen Abhängigkeiten und Beziehungen zu weiteren Systemen der betrachteten Applikationsarchitektur erhoben (vgl. Winter / Schelp 2005; vgl. Hafner et al. 2004). Diese Informationen werden zentral in dem Environmental Pattern Repository hinterlegt. Zusätzlich werden ausgehend von dem allgemein anerkannten Qualitäts-modell der ISO/IEC 9126-1 den Elementen Kriterien zugordnet, die von diesen direkt beeinflusst werden können (vgl. Behkamal et al. 2009; vgl. Jung et al. 2004). Dabei erfolgt auch eine Beurteilung, wie die Kriterien die qualitative Kenngröße beeinflussen (vgl. Carvallo et al. 2008).

In der zweiten Phase wird die Anwendungsdomäne ausgehend von der allgemeinen Zieldefinition in einzelne Teilziele heruntergebrochen. Dies geschieht, bis die Teilziele das Abstraktionsniveau den Unterkategorien des ISO/IEC Standards 9126-1 ent-sprechen. Diese Teilziele werden daraufhin mit den Abhängigkeiten, die im Environmental Pattern Repository hinterlegt sind, verknüpft (vgl. Carvallo et al. 2008).

Im Rahmen der dritten Phase werden Qualitätsmodelle für die zuvor definierten Teil-bereiche nach ISO/IEC Standards 9126-1 definiert. Dabei wird zwischen Umgebungs-und Plattform Parametern unterschieden. Der Fokus liegt bei dem RECSS-Vorgehensmodell auf den Plattform Parametern, da hier ein Alleinstellungsmerkmal gegenüber anderen Vorgehensmodellen von den Autoren gesehen wird. In diesem Schritt werden verschiedene Plattformen für die einzuführende Software evaluiert. Die Bewertung erfolgt dabei in einer Zuordnung als positiven oder negativen Einfluss (vgl. Carvallo et al. 2008).

Abschließend werden in einem vierten Schritt die zu Projektbeginn erhobenen An-forderungen mit den Anforderungen, die in den vorangegangenen Phasen entwickelt worden sind, abgeglichen und gegebenenfalls erweitert. Dabei werden die An-forderungen durch die wiederholte Betrachtung und die hierarchische Gliederung besser strukturiert, wodurch die Auswahl einer konkreten Software für die An-forderungen erleichtert wird (vgl. Carvallo et al. 2008).

Alles in allem bietet das RECSS-Vorgehensmodell also die Möglichkeit, Anforderungen an Software geordnet zu erheben und diese in der jeweils benötigten Granularität und im Unternehmenskontext darzustellen.

Es stellt sich also heraus, dass das RECSS-Vorgehensmodell ein weiteres Modell zur Auswahl von COTS Systemen ist, wie es sie schon in großer Anzahl gibt (vgl. Wayama / Far 2005; vgl. Alves / Finkelstein 2002). Das Alleinstellungsmerkmal, das Carvallo, French und Quer(2008) besonders hervorheben, ist die integrierte Betrachtung der Systemplattformen der jeweiligen Unternehmen. Dies soll es ermöglichen, eine Vergleichbarkeit verschiedener Plattformstrategien zu schaffen und ausgehend davon die beste Strategie im Einklang mit der Applikationsarchitektur auszuwählen (vgl. Carvallo et al. 2008). Dazu ist allerdings festzustellen, dass bspw. Zarnekow et al (2007) ebenfalls die gesamte Applikationsarchitektur bei der Softwareauswahl einbezieht. Dennoch ist vor dem Hintergrund, dass der Einsatz von COTS zumeist dadurch getrieben ist, schnell und kosteneffizient Anforderungen abzudecken, diese ganzheitliche Be-trachtung mit einer umfangreichen Bewertung von nachrangigen Einflussfaktoren gerade für KMUs wenig relevant, da es in diesem Umfeld regelmäßig kaum Freiheits-grade bei dem Einsatz unterschiedlicher Plattformstrategien gibt (vgl. Lin et al. 2006; vgl. Wayama / Far 2005; vgl. Keil / Tiwana 2005).

Die Autoren des RECSS-Vorgehensmodells schränken jedoch sogleich die Nutzbarkeit des Plattformvergleichs ein, da es in der Regel nicht möglich ist, die zugrundeliegende Plattform bei der Einführung einer neuen Software zu ändern, da sämtliche Applikationen der betrieblichen Systemlandschaft davon betroffen sind (Carvallo et al. 2008). Neben diesen Einschränkungen gibt es bei diesem Ansatz weitere Kritikpunkte, die die Umsetzbarkeit des RECSS-Vorgehensmodells in der Praxis stark einschränken. Dies betrifft besonders die Entwicklungen zu einer verstärkten Nutzung von sowohl Software als auch Plattformen und Infrastruktur mittels Cloud Computing (vgl. Berke / Kroker 2009, vgl. Weinhardt et al. 2009). Durch diese Art der Bereitstellung von Soft­ware, Plattformen und Infrastruktur als Dienstleistungen ergibt sich für Unternehmen die Möglichkeit, sich flexibel an sich ändernde Marktbedingungen bzw. Anforderungen anzupassen. Diese gesteigerte Flexibilität impliziert, dass Unternehmen Software un-abhängig von bestehenden Restriktionen hinsichtlich Plattformen und Infrastruktur eingesetzt können. Idealtypisch kann derartige als Service bezogene Software im Rahmen einer serviceorientierten Architektur (SOA) eingebunden werden, da bei der Verwendung dieses Architekturparadigmas die Funktionen über Schnittstellen genutzt werden und durch Kapselung die konkrete technische Umsetzung verborgen bleibt (vgl. Erl 2008; vgl. Heutschi 2007; vgl. Pulier/ Taylor 2006; vgl. BITKOM 2008). Vor diesem Hintergrund können Dienstleistungen, die durch Cloud Computing bezogen werden, konsistent in die Unternehmenssoftwarearchitektur integriert werden. Durch diese ge-stiegene Flexibilität erhöht sich allerdings der Aufwand des Vergleichs unterschiedlicher Plattformen dramatisch, da nun nicht nur die Software anhand der Anforderungen evaluiert werden muss, sondern bei der Plattformstrategie auch die Möglichkeiten eines Bezugs als Dienstleistung besteht. Weiter erhöht wird die Komplexität dadurch, dass ebenfalls die komplette Infrastruktur „as a Service" bereitgestellt werden kann und somit auch in diesem Bereich eine Evaluation und Entscheidung erfolgen muss. Folglich sind bei einer konsequenten Anwendung des RECSS-Vorgehensmodells unter Ein-beziehung neuerer technologischer Entwicklungen bei einer Softwareauswahl zugleich die gesamte dahinterliegende Plattform sowie die Infrastrukturstrategie des Unter-nehmens in Frage gestellt. Auf der einen Seite steigert dies die geforderte Flexibilität des Unternehmens beträchtlich, da Beschränkungen hinsichtlich zu verwendender Platt-formen umgangen werden können. Auf der anderen Seite wird dadurch allerdings die Komplexität bei der Softwareauswahl stark erhöht, wodurch die Anwendbarkeit von RECSS gerade in KMUs erschwert wird, weil im Umfeld von KMUs COTS-Systeme ein-gesetzt werden, um schnell und möglichst kostengünstig benötigte Funktionen umzu-setzen.

[...]