Eine Methode zur kollaborativen Anforderungserhebung und entscheidungsunterst¨ utzenden Anforderungsanalyse Michael Geisser and Tobias Hildenbrand Working Paper 6/2005 August 2005 Working Papers in Information Systems University of Mannheim Department of Information Systems 1 D-68131 Mannheim/Germany Phone +49 621 1811691, Fax +49 621 1811692 E-Mail: [email protected]Internet: http://www.bwl.uni-mannheim.de/wifo1
25
Embed
Eine Methode zur kollaborativen Anforderungserhebung und ... · 1 „Eine Methode zur kollaborativen Anforderungserhebung und entscheidungsunterstützenden Anforderungsanalyse“
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Eine Methode zur kollaborativen Anforderungserhebung
und entscheidungsunterstutzenden Anforderungsanalyse
Michael Geisser and Tobias Hildenbrand
Working Paper 6/2005August 2005
Working Papers in Information Systems
University of Mannheim
Department of Information Systems 1D-68131 Mannheim/Germany
Da Anforderungen untereinander Abhängigkeiten aufweisen können, dürfen sie nicht unter
Vernachlässigung dieser Abhängigkeiten miteinander verglichen werden. Enthält eine Kate-
gorie voneinander abhängige Anforderungen, so werden für diese jeweils so genannte „An-
forderungssets“ gebildet, die in einer entsprechenden Applikation mittels eines gerichteten
Graphen grafisch dargestellt werden können. Zur Anschauung sei auf Abbildung 3 verwiesen:
15
Hier ist Anforderung A2 Voraussetzung für A3, letzte wiederum zusammen mit A0 Voraus-
setzung für A4 und A5. Zusammen bilden sie ein abgeschlossenes Anforderungsset.
Abbildung 3: Darstellung von Abhängigkeiten mittels gerichteten Graphen2. Schritt: Kosten und Nutzen schätzen
Sind innerhalb der Kategorien die Anforderungssets gebildet, so können die Kosten und der
Nutzen der Anforderungen geschätzt werden. Während es den IT-Experten des Systemhauses
obliegt, realistische Kostenschätzungen für die Anforderungen zu geben, sind ausschließlich
die Stakeholder auf Kundenseite für die Schätzung des Nutzens verantwortlich. Während die
Kosten unter Einbeziehung einer Mengenkomponente (z.B. Mannmonate oder -tage) und ei-
ner Wertkomponente (Tagessatz je Mitarbeiter) geschätzt werden, wird der Nutzen mittels
hierarchischen Einsatzes des AHP bestimmt.
3. Schritt: Grafische Darstellung der Ergebnisse
Die Ergebnisse des zweiten Schritts werden unter Berücksichtigung der Abhängigkeiten gra-
fisch dargestellt, indem vom Wurzelelement der gerichteten Graphen ausgehend alle mögli-
chen Kombinationen mit ihren aggregierten Nutzenwerten und Kosten in ein Kosten-Nutzen-
Diagramm eingetragen werden (siehe Abbildung 4, Fortführung des Beispiels aus Abb. 3).
Abbildung 4: Kosten-Nutzen-Diagramm
16
Um die Schätzung der Kosten und des Nutzen zu unterstützen, wurde an der Universität
Mannheim eine prototypische webbasierte Anwendung entwickelt. Sie ermöglicht es, die Sta-
keholder sicher durch den Prozess zu führen und die Nutzenwerte mit Hilfe des AHP zu be-
rechnen und grafisch in einem Kosten-Nutzen-Diagramm auszugeben (siehe Anhang 1).
4. Schritt: Entscheidung über die Auswahl
Abschließend findet ein physisches Treffen aller Stakeholder statt, bei dem der Moderator das
Kosten-Nutzen-Diagramm mit den eingetragenen Anforderungen und Anforderungssets prä-
sentiert. Auf Basis dieser objektivierten Entscheidungsgrundlage wird nun diskutiert und ent-
schieden, welche Anforderungen implementiert, und welche Anforderungen verworfen bzw.
für eine spätere Version des Produkts vorgehalten werden.
Um die Entscheidung zu vereinfachen, enthält das Kosten-Nutzen-Diagramm zwei Geraden:
Anforderungen, die oberhalb der Gerade mit y = 2x liegen, sollten auf jeden Fall implemen-
tiert werden, während Anforderungen, die unterhalb der Gerade y = 1/2 x liegen, nicht be-
rücksichtigt werden sollten (siehe Abbildung 4). Die Einteilung des Diagramms mittels der
zwei Geraden hat sich empirisch bewährt, um Anforderungen mit einem hohen Nutzen-
Kosten-Verhältnis von solchen mit einem niedrigen abzugrenzen [Karlsson und Ryan 1997].
4. Zusammenfassung und Ausblick
In diesem Beitrag wurde, aufbauend auf einer kritischen Evaluation bestehender Ansätze, eine
entscheidungsunterstützende Methode für eine kollaborative Anforderungserhebung und -
analyse in einem verteilten Umfeld entwickelt. Diese setzt sich aus zwei aufeinander folgen-
den Phasen zusammen. Während in der ersten Phase die Anforderungen iterativ und mög-
lichst vollständig erhoben werden, erfolgt in der zweiten Phase die Auswahl der tatsächlich zu
implementierenden Anforderungen (siehe Anhang 2).
Mit Hilfe dieser Methode kann für eine kollaborative Anforderungserhebung ein systemati-
scheres Vorgehen während der RE-Phase und eine stärkere Fokussierung ebendieser in ver-
teilten Softwareentwicklungsprojekten ermöglicht werden. Dies bedeutet einen weiteren
Schritt in Richtung des Ziels des SE, nämlich zuverlässige und qualitativ hochwertige Soft-
ware innerhalb planbarer monetärer und zeitlicher Budgets zu erstellen.
Systemhäuser werden somit in die Lage versetzt, als ersten Schritt des RE die Anforderungen
eines Konsortiums von Auftraggebern mit teilweise verschiedenen Interessen systematisch zu
erheben. Dies wird erreicht, indem die Methode den bereits etablierten WinWin-Ansatz auf
17
ein verteiltes Umfeld überträgt und ihn insgesamt intuitiver sowie bei der Auswahl von An-
forderungen objektiver gestaltet.
Durch diese Vorgehensweise kann auf die zahlreichen theoretischen und empirischen Er-
kenntnisse des WinWin-Ansatzes zurückgegriffen werden. Durch Analyse bestehender Prak-
tiken in der verteilten Softwareentwicklung, insbesondere im Open Source-Umfeld, sowie
durch Einbeziehung quantitativer Methoden konnten die bekannten Schwachstellen der Ea-
syWinWin-Methodik behoben werden. Neben Vermeidung der Nachteile des WinWin-
Ansatzes ist es zudem zum ersten Mal gelungen, Abhängigkeiten zwischen Anforderungen in
Form von Sets systematisch bei der Anforderungsanalyse zu berücksichtigen.
Um die Entwicklung der Methode abzuschließen, muss diese nun in Fallstudien prototypen-
basiert evaluiert werden. Hierzu muss zunächst der bereits entwickelte Prototyp für die An-
forderungsanalyse erweitert werden, um wie in der Methode gefordert Abhängigkeiten von
Anforderungen auch werkzeugseitig zu unterstützen. Aufgrund der dann in der Praxis gewon-
nenen Erkenntnisse kann die Werkzeugunterstützung verbessert und die Methode angepasst
werden.
Neben der prototypischen Evaluierung kann es auch interessant sein, die Methode um weitere
theoretische Konzepte zu ergänzen. So sind zwar domänenspezifische Methoden im RE
schwierig zu gestalten, doch es sollte zumindest untersucht werden, ob domänenspezifische
Instanzen durch den Einsatz von Ontologien und anderen semantikbasierten Technologien
erzeugt und in der Praxis eingesetzt werden können.
Die Auswahl der Anforderungen könnte in der vorliegenden Methode zudem um Zeitaspekte
erweitert werden, indem nicht nur der Nutzen und die Kosten, sondern auch die Entwick-
lungszeiten auf Ebene der Anforderungen einbezogen werden.
Des Weiteren kann eine Integration der Methode in das Produktlinien-Konzept [Böckle u.a.
2004] untersucht werden, um eine pro-aktive Wiederverwendung von Anforderungen zu er-
möglichen. Hierbei ist insbesondere der Abgleich von Standardanforderungen mit wieder
verwendbaren Komponenten ein spannendes Forschungsgebiet.
Um eine ganzheitliche kollaborative Methodik für das RE zu entwickeln, müssen in zukünfti-
gen Arbeiten auch für die weiteren Phasen des RE Methoden für ein verteiltes Umfeld konzi-
piert werden. Eine solch ganzheitliche Methodik für das RE erlaubt dann eine stärkere Fokus-
sierung von frühen Phasen der Softwareentwicklung, um so die zwischenbetriebliche Ar-
beitsteilung im Softwareentwicklungsprozess besser zu unterstützen, neue betriebliche Pro-
18
dukte und Prozesse schneller umzusetzen und die Qualität durch Einbeziehung mehrerer Ak-
teure mit unterschiedlichen Fähigkeiten zu erhöhen. Zudem können durch eine stärkere Fo-
kussierung des RE teure Folgefehler in späteren Phasen vermieden werden.
Die hier behandelte Problemstellung gilt aber nicht nur auf den RE-Prozess sondern erstreckt
sich auf den gesamten Softwarelebenszyklus. Verteiltes Arbeiten – organisatorisch und/oder
geographisch – spielt im weiteren Verlauf des Industrialisierungsprozesses in der Software-
branche eine entscheidende Rolle. Es besteht daher Bedarf an einer durchgängigen methodi-
schen und softwaretechnischen Unterstützung kollaborativer Softwareerstellung.
Literaturverzeichnis
[Alexander 1999] Alexander, Ian: Supporting a Co-operative Requirements EngineeringProcess. In: Proceedings of the 10th International Workshop on Database and Expert SystemApplications (DEXA’99), IEEE (1999), S. 340–344
[Beyer und Holtzblatt 1995] Beyer, Hugh R. ; Holtzblatt, Karen: Apprenticing With the Cus-tomer. In: Communications of the ACM 38 (1995), Nr. 5, S. 45–52
[Böckle u.a. 2004] Böckle, Günter ; Knauber, Peter ; Pohl, Klaus ; Schmid, Klaus : Software-Produktlinien: Methoden, Einführung und Praxis. dpunkt.verlag, 2004
[Boehm 2000] Boehm, Barry: Requirements that Handle IKIWISI, COTS, and Rapid Change.In: Computer 33 (2000), Nr. 7, S. 99–102
[Boehm und Bose 1994] Boehm, Barry W. ; Bose, Prasanta: A Collaborative Spiral SoftwareProcess Model Based on Theory W. In: Proceedings of the 3rd International Conference onthe Software Process, Applying the Software Process, IEEE (1994)
[Boehm und Ross 1989] Boehm, Barry W. ; Ross, Rony: Theory W Software Project Man-agement: Principles and Examples. In: IEEE Transaction of Software Engineering (1989), S.902–916
[Briggs und Gruenbacher 2002] Briggs, Robert O. ; Gruenbacher, Paul: EasyWinWin: Man-aging Complexity in Requirements Negotiation with GSS. In: Proceedings of the 35th HawaiiInternational Conference on System Sciences (2002)
[Capgemini 2005] Capgemini: Studie IT-Trends 2005 – Paradigmenwechsel in Sicht. 2005. –Forschungsbericht. http://www.de.capgemini.com/servlet/PB/menu/1556859/ (30.08.2005)
19
[Cook und Churcher 2003] Cook, C. ; Churcher, N.: An Extensible Framework for Collabo-rative Software Engineering. In: Proceedings of the 10th Asia-Pacific Software EngineeringConference (APSEC’03), IEEE (2003), S. 290–301
[Damian 2001] Damian, Daniela: An empirical study of requirements engineering in distrib-uted software projects: is distance negotiation more effective? In: Proceedings of the AsiaPacific Software Engineering Conference (APSEC) (2001)
[Damian u. a. 2003] Damian, Daniela E. ; Eberlein, Armin ; Shaw, Mildred L. ; Gaines, BrianR.: An exploratory study of facilitation in distributed requirements engineering. In: Require-ments Engineering Journal: Special Issue on Selected Papers from RE’01 8 (2003), Nr. 1, S.23–41
[Davis 1990] Davis, Alan M.: Software Requirements - Analysis and Specification. Prentice-Hall, 1990
[Dean u. a. 1998] Dean, Douglas L. ; Lee, James D. ; Pendergast, Mark O. ; Hickey, Ann M. ;Jay F. Nunamaker, Jr.: Enabling the Effective Involvement of Multiple Users: Methods andTools for Collaborative Software Engineering. In: Journal of Management Information Sys-tems 14 (1998), Nr. 3, S. 179–222
[ESI 1996] ESI: ESI Project No. 1100: ESPITI / European Software Institute. 1996. – For-schungsbericht. http://www.esi.es/en/Projects/VASIE/Reports/All/11000/ESPITI.doc(30.08.2005)
[French und Layzel 1998] French, Andy ; Layzel, Paul: A Study of Communication and Co-operation in Distributed Software Project Teams. In: IEEE Int. Conference on SoftwareMaintenance, Bethesda (1998), S. 146–155
[Gruenbacher 2000] Gruenbacher, Paul: Collaborative Requirements Negotiation with Easy-WinWin. In: Proceedings of the 11th International Workshop on Database and Expert Sys-tems Applications (DEXA’00) (2000)
[Gruenbacher und Braunsberger 2003] Gruenbacher, Paul ; Braunsberger, Patrick: Coopera-tive methods and tools for distributed software processes. Kap. Tool Support For DistributedRequirements Negotiation, S. 56–66, Franco Angeli, Milano, Italy, 2003
[Gruenbacher und Briggs 2001] Gruenbacher, Paul ; Briggs, Robert O.: Surfacing TacitKnowledge in Requirements Negotiation: Experiences Using Easy Win Win. In: Proceedings
20
Hawaii International Conference on System Sciences, IEEE Computer Society (2001)
[Herbsleb u.a. 2001] Herbsleb, James D. ; Mockus, Audris ; Finholt, Thomas A. ; Grinter,Rebecca E.: An empirical study of global software development: distance and speed. In: Pro-ceedings of the 23rd International Conference on Software Engineering, IEEE Computer So-ciety (2001), S. 81–90
[Herlea und Greenberg 1998] Herlea, Daniela ; Greenberg, Saul: Using a Groupware Spacefor Distributed Requirements Engineering. In: Proceedings of the Seventh IEEE InternationalWorkshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (1998), S.57–62
[Highsmith 2000] Highsmith, James A.: Adaptive software development: a collaborative ap-proach to managing complex systems. Dorset House Publ., New York, 2000
[Karlsson und Ryan 1997] Karlsson, Joachim ; Ryan, Kevin: A Cost-Value Approach for Pri-oritizing Requirements. In: IEEE Software 14 (1997), Nr. 5, S. 67–74
[Karlsson u. a. 1998] Karlsson, Joachim ; Wohlin, Claes ; Regnell, Björn: An evaluation ofmethods for prioritizing software requirements. In: Information and Software Technology 39(1998), S. 939-947
[Karolak 1998] Karolak, Dale W.: Global software development: managing virtual teams andenvironments. Wiley-IEEE Computer Society Pr, 1998
[Leffingwell und Widrig 2000] Leffingwell, Dean ; Widrig, Don: Managing Software Re-quirements - A Unified Approach. Addison-Wesley, 2000
[Leuf und Cunningham 2001] Leuf, Bo ; Cunningham, Ward: The Wiki way: quick collabo-ration on the Web. Addison-Wesley, 2001
[Lloyd u.a. 2002] Lloyd, Wesley J. ; Rosson, Mary B. ; Arthur, James D.: Effictiveness ofElicitation Techniques in Distributed Requirements Engineering. In: Proceedings of the IEEEJoint International Conference on Requirements Engineering (RE’02) (2002)
[Mahmood 2003] Mahmood, M. A.: Advanced topics in end user computing. Idea GroupPublishing, 2003
[Massey 2002] Massey, Bart: Where do open source requirements come from (and whatshould we do about it)? In: Proceedings of the 2nd ICSE Workshop On Open Source Soft-ware Engineering (2002)
[Massey 2003] Massey, Bart: Why OSS Folks Think SE Folks Are Clue-Impaired. In: Pro-ceedings of the 3rd Workshop on Open Source Software Engineering, International Confer-ence on Software Engineering (ICSE’03) (2003)
[Ocker u.a. 1995] Ocker, R. ; Hiltz, S.R. ; Turoff, M. ; Fjermestad, J.: Computer Support forDistributed Asynchronous Software Design Teams: Experimental Results on Creativity and
21
Quality. In: Proceedings of the 28th IEEE International Conference on System Sciences(1995), S. 4–13
[Pfahl 2001] Pfahl, Dietmar: An Integrated Approach to Simulated-Based Learning in Sup-port of Strategic and Project Management in Software Organisation, Universität Kaiserslau-tern, Dissertation, 2001
[Ruhe u. a. 2002] Ruhe, Günther ; Eberlein, Armin ; Pfahl, Dietmar: Quantitative WinWin - ANew Method for Decision Support in Requirements Negotiation. In: Proceedings of the 14thInternational Conference on Software Engineering and Knowledge Engineering (SEKE 2002)(2002), S. 159-166
[Ruhe u. a. 2003] Ruhe, Günther ; Eberlein, Armin ; Pfahl, Dietmar: Trade-Off Analysis ForRequirements Selection. In: International Journal of Software Engineering and KnowledgeEngineering 13 (2003), Nr. 4, S. 345-366
[Saaty 1980] Saaty, Thomas L.: The Analytic Hierarchy Process. McGraw-Hill, 1980
[Scacchi 2002] Scacchi, Walt: Understanding the Requirements For Developing Open SourceSoftware Systems. In: IEE Proceedings – Software, 149 (1) (2002), S. 24–39
[Scacchi u. a. 2004] Scacchi, Walt ; Jensen, Chris ; Noll, John ; Elliott, Margaret: Multi-modal Modeling, Analysis and Validation of Open Source Software Requirements Processes.September 2004. – working paper, Institute for Software Research
[Seyff u. a. 2004] Seyff, Norbert ; Gruenbacher, Paul ; Maiden, Neil ; Tosar, Amit: MobileWerkzeuge im Requirements Engineering. In: Softwaretechnik-Trends 24 (2004), 1