Modelling by Example: Ein Ansatz zur Unterstützung der Vorvertragsphase Internet basierter Software Projekte

Transkript

1 Modelling by Example: Ein Ansatz zur Unterstützung der Vorvertragsphase Internet basierter Software Projekte Axel Kalenborn, Karin Fetzer Universität Trier, Wirtschaftsinformatik Universitätsring, Trier ICT Solutions AG Bahnhofstr , Trier Abstract: Vor der Umsetzung eines Software Projektes liegt die in der Literatur bisher wenig beachtete Phase der Angebotserstellung, während der eine Grobkonzeption der umzusetzenden Software in Form eines Angebotes erstellt werden muss. Bestandteile eines Angebots sind eine möglichst präzise Aufwandschätzung sowie eine Lösungsskizze. In der Angebotsphase erhalten die Anbieter keine Vergütung und stehen in Konkurrenz zueinander, weshalb unter hohem Zeit-, Erfolgsund Kostendruck gearbeitet werden muss. Viele Methoden des Requirements Engineering verursachen einen zu hohen Aufwand und liefern zu abstrakte Ergebnisse, sodass sie in dieser Phase noch nicht angewendet werden können. Im vorliegenden Beitrag wird ein Lösungsansatz zur Unterstützung der Angebotsphase bei dialogorientierten Anwendungen vorgestellt. 1 Einleitung Das Internet hat sich in den letzten Jahren als eine der wichtigsten Plattformen für die Umsetzung von IT Systemen etabliert. Der Markt für Unternehmenswebseiten, Intranet- Systeme, Sozialen-Netzwerken, ecommerce-systemen oder elearning-anwendungen wächst nachhaltig. Auf die Realisierung dieser Anwendungen haben sich Software Unternehmen, Internetagenturen, Beratungsunternehmen, Werbeagenturen und Freiberufler konzentriert. Die Zahl der Unternehmen, die in diesem Sektor tätig sind, wird in Deutschland auf deutlich mehr als geschätzt. Sie konkurrieren um Projekte aus der Wirtschaft und der öffentlichen-hand. 1 Vor der Umsetzung der Projekte liegt die Vorvertragsphase, während der ein verbindliches Angebotes für ein Projekt erstellt werden muss. In dieser Phase können noch keine detaillierten Analysen über die Anforderungen durchgeführt werden, da die Analyse nicht vergütet wird, eine Konkurrenzsituation zu anderen Anbietern besteht und ein 1 Basis sind die vom Statistischen Bundesamt im NACE-Code 74.4 und 74.8 aufgeführten Unternehmen.

2 Auftraggeber mehreren potentiellen Anbietern gegenübersteht. Erhält man als Anbieter keinen Zuschlag für das Software Projekt, dann ist der investierte Aufwand nicht gedeckt. Wie hoch dieser investierte Aufwand sein darf, hängt davon ab, wie hoch die Wahrscheinlichkeit eingeschätzt wird, den Zuschlag für das Projekt zu erhalten und ist schwer zu ermitteln. [Al05] Knapper werdende IT Budgets erfordern hier jedoch ein effizientes Vorgehen bei der Angebotserstellung. Die Unternehmen müssen daher die frühe Anforderungsanalyse möglichst wirtschaftlich durchführen, ohne dabei unpräzise zu arbeiten, da dies zu schlechten und risikoreichen Angeboten führt. Trotzdem muss bereits in dieser Phase eine möglichst genaue Anforderungserhebung stattfinden, um das Projekt zu verstehen und präzise kalkulieren zu können. Viele Methoden des Requirements Engineering, wie Befragungen, Beobachtungen oder strukturierte Interviews, verursachen jedoch einen zu hohen Aufwand, um in dieser Phase anwendbar zu sein [Po08]. Das Requirements Engineering beschränkt sich daher meist auf Meetings, Telefonate oder eine Dokumentenanalyse. Auch die Dokumentation der Anforderungen bereitet Probleme, da die bekannten formalen Methoden zur Modellierung von Software Systemen, wie die UML, nicht angewendet werden können [Ba09]. Sie überfordern die häufig fachfremden Entscheider sehr schnell mit abstrakten Beschreibungen und sind nur für IT affine Personen geeignet [Br08]. 2 Die Besonderheiten Internet basierter Projekte Bei Internet Projekten kommen weiter Besonderheiten hinzu, insbesondere die hohe Bedeutung der Gestaltung und der Usability sind hier zu nennen. Daher verlangen die Kunden häufig bereits in der Angebotsphase Mock-Ups zur Visualisierung ihrer Anwendung, um sich diese besser oder überhaupt vorstellen zu können. Im Rahmen von Wettbewerbspräsentationen zur Vergabe von Software Projekten sind Mock-Ups und Visualisierungen die Basis für eine Teilnahme und daher fester Bestandteil eines Angebotes. Die Erstellung von Mock-Ups ist jedoch sehr aufwendig, da diese meist in Programmen erstellt werden, die dazu ungeeignet sind, wie Bildverarbeitungen, HTML-Editoren oder auch Prototypingtools [La05]. An dieser Stelle ist der Angebotsprozess in vielen Unternehmen unstrukturiert und aufwendig. Doppelarbeiten sind an der Tagesordnung, da zunächst die Visualisierungen erstellt, dann in Angeboten spezifiziert und kalkuliert werden, um sie abschließend für Präsentationen aufzubereiten. Der Aufwand für die Erstellung von Mock-Ups kann schnell ihren Nutzen übersteigen, wenn sie nur einmal verwendet und dann weggeworfen werden. Daher ist eine neue Herangehensweise an die Anforderungsanalyse, Modellierung und Dokumentation der Systeme gefragt, speziell dann, wenn Mock-Ups ohnehin notwendig oder gefordert sind. Es stellt sich die Frage, wie Mock-Ups aufgebaut und modelliert werden müssen, um mehr als nur eine Visualisierung zu erhalten. Eine mögliche Lösung liegt in ihrer semantischen Anreicherung, um sie sowohl für die Visualisierung als auch für die Angebots- oder Pflichtenhefterstellung verwenden zu können. Prototypen müssen intelligenter gebaut werden, wozu Methoden und Werkzeuge nötig sind; Modelling bei Example (MbE) ist eine solche Methode.

3 3 Die Modelling by Example Idee Die sog. by example -Ansätze stammen aus dem Kontext von Datenbanken und wurden als Query by Example (QbE) eingeführt [Zl77]. Die QbE Technik gestattet es auch Laien ohne Erfahrung mit Datenbanksprachen, komplexe Auswertungen oder Änderungen in Relationalen-Datenbanken durchzuführen. Ein anderer Ansatz aus diesem Bereich, der Programming by Example Ansatz, ermöglicht es Benutzern eine Anwendung innerhalb der gewohnten Benutzeroberfläche ihrer Anwendung zu programmieren. Die Makrofunktionen der gängigen Office-Lösungen sind ein Beispiel hierfür. Allen Ansätzen gemein ist, dass konkrete Ausprägungen, also Beispiele, verallgemeinert werden. Auf diese Weise kann der Anwender die Aufgabe intuitiver formulieren, indem er seine Vorstellung des Ergebnisses angibt. Er ist nicht darauf angewiesen, grundlegend neue Konzepte zu erlernen. Modelling by Example (MbE) soll diesen Gedanken auf die Modellierung von Web-Anwendungen übertragen. Anstatt vom Benutzer zu fordern, neue Methoden oder Darstellungsformen zu erlernen, wird das Ergebnis, also die Ansicht der Benutzeroberfläche, als Ausgangspunkt für die Konzeption der Anwendung benutzt [Le04]. Das Erfassen zusätzlicher Informationen ermöglicht es, das Modell später durch versiertes Fachpersonal zu verfeinern und zu vervollständigen. 2.1 Zielsetzung des Modelling by Example Ziel des MbE ist die Unterstützung der Angebotserstellung in der Phase der Vorbereitung von dialogorientierten Software Projekten. In dieser Phase müssen die Anforderungen so erfasst werden, dass daraus ein konkurrenzfähiges Angebot entstehen kann, welches den Kunden überzeugt [Kl99]. Das Angebot kann als Grobkonzeption eines Pflichtenheftes verstanden werden, das in der Umsetzungsphase präzisiert wird. Die Überzeugung des Kunden von den eigenen Fähigkeiten ist das Ziel dieser Phase [Ko07]. Dabei ist eine möglichst einfache und bildhafte Dokumentation der Anforderungen wichtig, um IT fremde Entscheider zu erreichen und zu überzeugen. Die Kunden können Anforderungen am besten verstehen, wenn sie sie nach dem IKIWISI-Prinzip (I know it when I see it) visualisiert bekommen und prototypisch verwenden können [Bo00]. 2.2 Realisierung des Modelling by Example Zur Realisierung der MbE Idee, müssen Visualisierungen in Form von Mock-Ups effizienter erstellt und semantisch angereichert werden. Die Erstellung soll möglichst im Dialog mit dem Kunden erfolgen, um ein direktes Feedback zu der Umsetzung erhalten und aufwendige Protokolle und Abstimmungen zu vermeiden. Der Aufbau der Mock-Ups entspricht dem weitverbreiteten Schablonen Konzept von Web Anwendungen. Es basiert auf einem einheitlichen Layout, der sog. Schablone (Template), welches die Seitenstruktur und die grafische Gestaltung beschreibt, in der die Inhalte und Anwendungen integriert werden. Ein Template beinhaltet die Navigationsstruktur der Seite und legt den Look & Feel fest, welcher sich auf allen Unterseiten wiederfindet.

4 Web-Anwendungen bestehen aus Texten, Bildern sowie interaktiven Elementen und Modulen. Elemente interaktiver Web-Anwendungen sind dynamische Tabellen, Eingabefelder, Buttons, Auswahllisten Optionsfelder usw. Aus diesen elementaren Elementen werden Web-Anwendungen zusammengesetzt. Ein Kontaktformular ist ein solches Beispiel: Es besteht aus Eingabefeldern, einem Button für die Übertragung der Daten und eventuell einem CAPTCHA Element zur Vermeidung von SPAM. Zusätzlich können Regeln für die Syntaxprüfung der Eingabefelder angegeben und Reaktionen auf fehlerhafte Eingaben definiert werden. Da sich ein Kontaktformular auf fast jeder Webseite befindet, ist es auch ein gutes Beispiel für ein wiederverwendbares Modul innerhalb einer Web-Anwendung. Wiederverwendbare Module sind Schlüsselkomponenten im MbE-Ansatz. Sie werden einmalig angelegt, kalkuliert und systematisiert, um dann in allen Projekten als Angebotsartefakte Verwendung zu finden. Die Module sind so angelegt, dass sie sich in die Templates integrieren lassen und sich dadurch dem Look & Feel der Seite anpassen. Die Mock-Ups stellen im MbE Ansatz die visuelle eines MbE Moduls dar. Ein MbE Modul besteht konzeptionell gesehen noch aus drei weiteren Teilkomponenten, wie in Abbildung 1 dargestellt. Informationen für diese drei weiteren Teilkomponenten werden in Form von textuellen Spezifikationen dem MbE Modul zugewiesen. MbE Modul Visuelle Kalkulatorische Technische Fachliche Mock-Ups Aufwände Technologien Spezifikationen Präsentationen Lizenzkosten Best Practices Beschreibungen Videos Zeiten Testvorgaben Argumente Abbildung 1: n eines MbE Moduls. Um z.b. ein Angebot oder ein Pflichtenheft semiautomatisch aus einem MbE Modul heraus erstellen zu können, werden die semantischen Informationen aus den verschiedenen n zielgerichtet zu einem Output gebündelt, wobei den n folgende Inhalte hinterlegt werden: Die Kalkulatorische beinhaltet Informationen, die zur Ermittlung des Aufwands für die Umsetzung des Projektes und zur Zeitplanung relevant sind. Jedem Element eines Mock-Ups in einem MbE Modul können direkt unterschiedliche Arten von Aufwänden zugeordnet werden, darunter z.b. die Lizenzkosten für eine Datenbank, die benötigen Personentage für Umsetzung einer Anwendung oder deren den Test einer [Sn05]. Diese Aufwandsarten mit ihren entsprechenden Kostensätzen werden festgelegt und dann für die Kalkulation der Module verwendet. Dabei ist ein Schema realisiert, das

5 Aufwandsarten mit einer zeitlichen Dimension und einem Kostensatz verbindet. Ein wiederverwendbares MbE Modul muss nur einmal kalkuliert werden. Die fachliche beinhaltet die Beschreibung der Module, Seiten und Templates. Die Spezifikationen werden in Form von Texten zugewiesen und sollen die Funktionen der Mock-Ups erläutern. Auch hier liegt das Ziel darin, möglichst schnell verschiedene Outputs erzeugen zu können und dabei auf vordefinierte Spezifikationen zurückgreifen zu können. Die technische beinhaltet Informationen, welche zur Erstellung von Lastenheften, Pflichtenheftinhalten und Testspezifikationen genutzt werden können. Zusätzlich können Abläufe dargestellt werden, die die Interaktion der Module definieren. Eine Integration von ausgewählten UML Diagrammen ist vorgesehen. 2.3 Das Mobex-Werkzeug Das Mobex-Werkzeug unterstützt den MbE Ansatz und demonstriert die Umsetzbarkeit des Konzeptes in der Praxis. Das Werkzeug ist eine Mischung aus Grafikanwendung und Requirements Engineering Werkzeug. Mit dem Werkzeug werden die Oberflächen gestaltet und semantisch angereichert. Dazu stehen Maskenelemente, wie Textfelder, Schaltflächen oder Formen wie Rechtecke, Linien und Polygone zur Verfügung. Die Seitenstruktur wird als Baum angelegt. Ein Mock-Up beinhaltet verschiedene Module, die wiederum aus einzelnen Seiten bestehen. Alle Seiten können miteinander verlinkt werden. Dabei lassen sich auch Funktionen abbilden, um z.b. darstellen zu können, wie ein Formular auf einen Fehler reagieren soll. Die Spezifikationen für die weiteren, nicht-visuellen Teilkomponenten werden über die Eigenschaften der Objekte definiert. Dort können die fachlichen und technischen Beschreibungen sowie die für die Umsetzung geschätzten Kosten strukturiert hinterlegt werden. Die vorgefertigten Module werden zu einer Sammlung zusammengefasst, deren Elemente per Drag & Drop direkt in das aktuelle Projekt übernommen und dann modifiziert werden können. Um möglichst schnell einen Mock-Up definieren zu können, ist ein Set an Vorlagen für Module im Tool integriert, um n wie eine Bildergalerie, eine Sitemap oder eine interaktive Wegbeschreibung ohne großen Aufwand in den Prototypen integrieren zu können. Das Mobex-Werkzeug beinhaltet eine Modulsammlung mit ca. 30 häufig verwendeten n, die individuell erweiterbar ist. Dem Single Source Publishing Gedanken folgend, ist im Mobex-Werkzeug ein flexibler Report Generator integriert, der zur Erstellung der verschiedenen Dokumente dient. Der Report Generator beinhaltet Muster für Angebote, Lastenhefte, Pflichtenhefte, aber auch Testspezifikationen und Rechnungen. Die Vorlagen werden in ihrer Struktur hinterlegt und kombinieren die Seiten des Mock-Ups und deren Fachbeschreibungen bzw. Kalkulationen zum jeweiligen Output.

6 4 Zusammenfassung und Ausblick Der MbE Ansatz ist auf die Vorbereitung von dialogorientierten Software Projekten fokussiert. In diesem Rahmen muss unter hohem Zeitdruck ein professionelles Angebot erzeugt werden, das mit flankierenden Dokumenten und Präsentationen zu versehen ist. Der Ansatz stellt einen Mock-Up in den Mittelpunkt der Angebotserstellung. Durch semantische Erweiterung der Mock-Ups mit einer kalkulatorischen, technischen und fachlichen Angebotskomponente ermöglicht es der MbE Ansatz, dem Single Source Publishing Gedanken folgend, die MbE Module für die Angebotserstellung, die Präsentation und die interaktive Nutzung durch den Kunden verwenden zu können. Erste Erfahrungen im Praxiseinsatz sowie eine experimentelle Evaluation zeigen, dass sich mit der Methode und dem Werkzeug bis zu 50 % Zeit im Rahmen der Vorbereitung der Projekte einsparen lässt. Zusätzlich werden die Anforderungen für die Kunden verständlich dargestellt und präzise kalkuliert. Weitere Informationen zum Projekt finden sich Internet unter Literaturverzeichnis [Sn05] [Al05] Albers, S / Söhnchen, F. 2005: Akquisitionsmanagement im industriellen Projektgeschäft, in Zeitschrift für Betriebswirtschaftslehre, ZfB-Special Issues 2/2005, S [Ba09] Balzert, H. 2009: Lehrbuch der Software Technik: Basiskonzepte und Requirements Engineering, 3. Auflage, Spektrum Verlag, Bochum [Bo00] Boehm, B. 2000: Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, 33 (7): Seite , IEEE Computer Society, New York. [Br08] Brennan, R./Canning, L./McDowell, R. 2008: Business-to-Business-Marketing, SAGE Publications Ltd, London [Kl99] Kleinaltenkamp, M. 1999: Wettbewerbsstrategie, in: Kleinaltenkamp, M. / Plinke, W. (Hrsg): Strategisches Business-to-Business Marketing, Springer-Verlag, Berlin, Heidelberg, New York, [Ko07] Kotler, P. / Keller, K.L. / Bliemel, F. 2007: Marketing-Management: Strategien für wertschaffendes Handeln, 12. Aufl., Evanston, Hannover, Kaiserslautern [La05] Lauesen, S. 2005: User Interface Design - A Software Engineering Perspective, Adisson Wesley, Copenhagen [Le04] Lechner, S. 2004: Web-Scheme Transformers By-Example, Johann Kepler Universität, Linz, [Po08] Pohl, K. 2008: Requirements Engineering: Grundlagen, Prinzipien, Techniken, 2. Auflage, DPunkt Verlag, Essen Sneed, H. M. 2005: Software Projektkalkulation, praxiserprobte Methoden der Aufwandsschätzung für verschiedene Projektarten, Hanser-Verlag, Budapest [Zl77] Zloof, M. M. 1977: Query-by-Example: a data base language, IBM Systems Journal, 16 (4): Seite , IBM Corporation, New York.