Home

Prototyping

1. Das Swaps Manager Projekt ist ein gutes Beispiel f r ein Entwicklungsprojekt im Rahmen dessen verschiedene Arten von Prototyping auftraten Bemerkenswert sind dabei die folgenden Aspekte e Zu Beginn diente Prototyping nicht dazu den Benutzern Wissen zu vermitteln sondern dazu das Verst ndnis des Anwendungsbereich durch die Entwickler zu validieren e Die Entwicklung des Pilotsystems war ein evolution rer Proze in dem der Prototyp zu einer praktisch einsetzbaren Anwendung ausgebaut wurde Es darf aber nicht bersehen werden da dies nur durch regelm iges Redesign m glich war Application Frameworks unterst tzen dieses Vorgehen weil sie eine Standardarchitektur vorgeben Der Aufwand f r die Redesigns darf aber nicht untersch tzt werden Wir glauben nicht da die Anwender bereit gewesen w ren die effektiven Kosten f r den gew hlten Ansatz zu tragen Wenn aber nicht eine gewisse Anzahl Anwender bereit dazu ist dann wird es nie m glich sein f r spezifische Anwendungsgebiete wie f r Handleranwendungen wiederverwendbare Frameworks zu erstellen 5 4 4 Auswertung der Werkzeuggruppe Application Frameworks werden meistens eingesetzt um interaktive Anwendungen zu erstellen deren Benutzungsoberfl chen nicht einfach aus Standardoberfl chen elementen Kn pfe Textfenster usw zusammengesetzt werden k nnen So enthalten alle drei Anwendungen einen interaktiven grafischen Editor der jeweils ganz speziell
2. nur sehr bedingt tauglich Evolution res Prototyping ist mit solchen Systemen kaum durchf hrbar da jeder Entwicklungszyklus mit umfangreichen Editiervorg ngen verbunden ist Als absolutes Minimum mu vorausgesetzt werden da zwei unabh ngige Programm Module Oberfl che und fachliche Emor Bookmark not defined Interface Builder Projekte Komponente entstehen die ohne weitere Modifikationen bersetzt und gebunden werden k nnen Auch die M glichkeit den Interface Builder und seine Oberfl chenelemente w hrend der Benutzung interaktiv zu erweitern ist wichtig f r den Einsatz eines solchen Werkzeugs im Prototyping Prozefs Die M glichkeit Templates oder Klassen von hnlichen Objekten zu definieren ist unabdingbar da sonst der Aufwand f r Modifikationen an gr eren Systemen mit vielen Oberflachenelementen unkalkulierbar wachsen kann vor allem wenn diese Modifikationen erst sp t im Prototyping Proze durchgef hrt werden sollen Nach unserer Einsch tzung l t sich der berwiegende Teil aller Benutzungsoberflachen mit einer klar umrissenen Menge unterschiedlicher Oberfl chenelemente erstellen ohne da die Werkzeuge erweitert werden m ssen Man mu jedoch abw gen ob die Komplexit t eines m chtigen Werkzeugs oder die Komplexit t des Erweiterungsprozesses sich in der Arbeitsweise der Oberfl chen Designer st rker st rend bemerkbar macht Der vergleichsweise hohe Lernaufwand der bei der Einf hrung vieler
3. M glichkeit geben komplexe Oberfl chen zu entwerfen ohne da ihm die Komplexit t der Umgebung bewu t zu werden braucht 4G System Projekte Enor Bookmark not defined 5 3 Projekte mit 4 Generationssystemen 4 Generationssysteme eignen sich zur Entwicklung von Prototypen f r Informationssysteme auf Basis von quasi relationalen Datenbanken Die Prototypen lassen sich in einem evolution ren Proze zum Zielsystem weiter entwickeln In diesem Abschnitt berichten wir ber zwei Projekte bei denen Prototypen mit 4 Generationssystemen erstellt wurden Die Entwicklung eines Projekt abwicklungssystems wurde mit 4th Dimension durchgef hrt ein Bank Arbeitsplatz mit Windows 4GL 5 3 1 Ein System zurVorprojektkalkulation und Projektabwic klung Das untersuchte Projekt Der Bereich Proze automatisierung einer Firma die Industrieanlagen baut suchte schon seit langem nach einem System f r die Projektabwicklung und Vorprojektkalkulation im weiteren PuV System genannt Ein f r diesen Bereich passendes System konnte nicht gefunden werden Die Adaptierung von hnlichen Systemen auf Grofsrechnerbasis h tte nach Sch tzung ca ein Jahr erfordert Aus der Zusammenarbeit der Firma mit der Software Engineering Abteilung einer Hochschule entstand die Idee das PuV System auf Arbeitsplatzrechnern zu realisieren Aufgabe des PuV Systems ist bei der Planung und Durchf hrung von Projekten die notwendigen Daten zu erfassen und so aufzuber
4. als da sie technische Grundlage der weiteren Entwicklung h tten sein k nnen Erfahrungen aus anderen Projekten belegen da der Versuch durch schrittweise Nachbesserungen zu einem tragf higen Anwendungssystem zu kommen in solchen F llen oft zu fachlich und software technisch unakzeptablen L sungen f hrt die ein Projekt insgesamt zum Scheitern bringen k nnen Die berichteten Erfahrungen ber die Einstellungs nderungen der beteiligten Personengruppen bei der Evaluierung der verschieden Prototypen scheinen uns ebenfalls typisch zu sein Die wachsende Integration der verschiedenen Gruppen in ein kooperatives und produktives Team l ft sich nur langsam erreichen Hier wird besonders die ge nderte Rolle der Anwender deutlich die nicht mehr vorrangig K ufer oder Informationslieferanten sondern konzeptionell mitwirkende Mitglieder des Entwicklungsteams wurden Dieses kooperative Team erm glichte es dann auch das Anwendungssystem evolution r zu entwickeln Allerdings stellt sich mit Blick auf den Beteiligungsaspekt die Frage wie gr ere Anwendergruppen effektiv an einem Entwicklungsproze teilnehmen k nnen Hier und aus anderen Projekten l ft sich feststellen da kleine Entwicklergruppen von etwa 10 bis max 15 Personen die Anwender eingerechnet optimal produktiv sind Ein 4G System vom Typ 4D scheint gut geeignet um evolution res Prototyping bei der Konstruktion von Informationssystemen einzusetzen Charakteristisch ist E
5. am bestehenden Prototyp aus Kostengr nden nur die im Rahmen des alten Konzepts m glichen nderungen durchgef hrt werden So wurden beim PuV System mehrere Prototypen entwickelt in die zwar die Erfahrung der vorhergehenden Prototypen aber nicht dessen Programmcode eingeflossen sind Die Leistungsf higkeit der eingesetzten Werkzeuge unterscheidet sich durch die zugrunde liegenden Basissysteme Oberfl che 4 GL Datenbank So bietet z B 4D keine Modularisierungskonzepte f r den erstellten Code an Soll der Prototyp evolution r bis zum Zielsystem weiterentwickelt werden so m ssen bei der Emor Bookmark not defined 4 Generationsystem Projekte Werkzeugauswahl neben der Eignung f r das Prototyping auch diese Anforderungen ber cksichtigt werden Framework Projekte Emor Bookmark not defined 5 4 Applicaton Frameworks Objektorientierte Application Frameworks werden immer popul rer um funktionsf hige Prototypen zu erstellen die anschlie end evolution r zum fertigen Zielsystem weiterentwickelt werden k nnen Wir zeigen in diesem Abschnitt drei Fallstudien f r Prototyping Projekte bei denen Application Frameworks eingesetzt wurden Bei allen Projekten war die Gestaltung der Benutzungsoberfl che von sehr gro er Bedeutung Bei den ersten beiden Projekten wurden grafische Editoren entwickelt ein Editor f r SWIFT Nachrichten und ein Editor um technische Systeme zu modellieren In beiden Projekten wurde mit dem Applicatio
6. aus der Oberfl chenkomponente nicht unmittelbar Operationen der fachlichen Komponente gerufen werden sondern da die Ereignisse des Fenstersystems z B Mausklick in der Oberfl chenkomponente in fachliche und interaktionsbezogene Programmereignisse z B Auswahl erfolgt umgesetzt werden Bei der Wahl einer der hier beschriebenen Formen der Ereignisbehandlung mu also abgewogen werden zwischen einer software technisch w nschenswerten Entkopplung von fachlicher und Oberfl chenkomponente einerseits und den Anforderungen des Prototyping andererseits Die software technische Entkopplung hat generell zur Folge dafs die fachlichen Komponenten und damit die eigentliche Ereignisbehandlung in einer konventionellen Programmiersprache implementiert werden mu Die f r das Prototyping sinnvolle Verwendung einer Skriptsprache nimmt dagegen die beschriebenen Nachteile in Kauf Zusammenfassend stellen wir fest da die Ereignisbehandlung mit einer integrierten interpretativen Sprache am besten f r ein exploratives Vorgehen geeignet ist Die Oberfl chenkomponente gibt aufgrund ihrer Struktur vor wie die Teile der fachlichen Komponente angebunden werden k nnen Die zur Verf gung stehenden Skript sprachen erlauben mit wenig Aufwand auf Ereignisse zu reagieren Die Ereignisbehandlung mit einer Skriptsprache st t dort an ihre Grenzen wo komplexe fachliche Komponenten geschrieben werden m ssen oder wo neuartige Interaktionsformen implementier
7. einzelne der bereits genannten Oberfl chenelemente sein Ein typisches Ereignis ist beispielsweise ein Mausklick ber einem Oberfl chenelement OK Knopf Das Ereignis Mausklick wird also dem Oberfl chenelement mitgeteilt Kann das Oberfl chenelement dieses Ereignis interpretieren d h gibt ein zu diesem Ereignis passendes Programmst ck zur Ereignisbehandlung event handler dann reagiert das System In unserem Beispiel k nnte der OK Knopf Teil einer Dialogbox sein in der der Benutzer zuvor bestimmte Einstellungen vorgenommen hat Im Zusammenspiel von Oberfl chenkomponente und fachlicher Komponente reagiert das Anwendungssystem auf dieses Ereignis d h es wird zun chst fachlich gepr ft ob die gew hlten Einstellungen zul ssig und umsetzbar sind Als interaktive Reaktion f r den Benutzer zeigt die Oberfl che dann ggf eine ver nderte Darstellung die dem Benutzer als R ckkopplung f r weitere Aktivit ten dient Dieser Zyklus aus Aktion und Reaktion vermittelt ber Ereignisse wird auch Interaktion genannt Grundlagen Emor Bookmark not defined 2 3 2 Angrenzende Themen Wir betrachten Oberfl chen Prototyping im Kontext einiger Themen Objektorientierung Oberfl chen Prototyping bedeutet unter den skizzierten technischen Rand bedingungen da die Anforderungen an die verwendete Architektur in vollem Umfang nur von objektorientierten Systemen erf llt werden k nnen Wir kennen kein erfolgreiches Fenstersystem auf Arbeitspl
8. um Systemvisionen zu erstellen Interface Builder Projekte Enor Bookmark not defined PARTS ist ein in Smalltalk V geschriebener Interface Builder verf gbar unter Windows und OS 2 der ein Laufzeitmodul erzeugen kann PARTS unterst tzt unter OS 2 die gesamte Funktionalit t des Presentation Managers was insofern nicht unproblematisch ist als da damit Demonstrationsprototypen gebaut werden k nnen die mehr an Handhabungsm glichkeiten zeigen als sich mit dem eingeschr nkten M glichkeiten der im Projekt verwendeten CommonView Bibliothek realisieren l t Erfahrungen der Entwickler CASE PM hat sich aus Sicht der Entwickler weniger zum Prototyping als mehr zur Einarbeitung in CommonView und Presentation Manager geeignet Zwar ist das Werkzeug einfach zu handhaben aber der angebotene Leistungsumfang in der 1991 verf gbaren Version entsprach nicht den Anforderungen des Teams Da CASE PM ein einziges gro es Programmskelett generiert konnten nur Wegwerf Prototypen konstruiert werden Schon kleinere nderungen an der Oberfl che machten eine Neuimplementation des jeweiligen Prototyps notwendig Zudem waren die Entwickler gezwungen das Programmskelett manuell in kleinere Klassen zu zerlegen um arbeitsteilig weiterentwickeln zu k nnen Nachdem die Entwickler einmal im Umgang mit CommonView ge bt waren wurde deshalb auf den Einsatz von CASE PM ganz verzichtet Der Einsatz von PARTS f r Demonstrationsprototypen war technisch
9. Anwender zu diskutieren Der Gestaltung einer anspruchsvollen Benutzungssoberfl che mu ebenso viel Aufmerksamkeit geschenkt werden was aber nicht allein von den Entwicklern gel st werden konnte Die Einbeziehung von Fachkr ften auf diesem Gebiet war notwendig und f hrte zu einer tberarbeitung der gesamten Benutzungsoberfl che Der damit verbundene Aufwand w re nach Aussagen der Entwickler geringer ausgefallen wenn der Spezialist f r die Gestaltung der Oberfl che bereits fr hzeitig am Projekt beteiligt gewesen w re F r das Oberfl chen Prototyping wurde das Werkzeug SX Tools verwendet Den Erfahrungen der Entwickler nach hat sich dieses Werkzeug als sehr geeignet erwiesen um anspruchsvolle Benutzungssoberfl chen zu entwickeln SX Tools eignet sich aufgrund seiner M chtigkeit nicht nur f r die Entwicklung von reinen Oberfl chenprototypen sondern auch zum Entwurf von Prototypen mit weiterf hrender Funktionalit t Im untersuchten Projekt zeigte es sich da das urspr ngliche Vorhaben verschiedene Medien miteinander zu kombinieren erweitert werden konnte Das entstandene System ist funktional wesentlich umfangreicher als zu Beginn geplant 5 2 3 Ein Kundenberatungssystem Das untersuchte Projekt Im weiteren gehen wir nochmals auf das in Abschnitt 5 1 1 beschriebene gleichnamige Projekt unter dem Aspekt der Verwendung von Interface Buildern ein Im Laufe des Gesamtprojektes wurden Interface Builder in den einzelnen Emor Bo
10. Bookmark not defined konstruierten Prototypen wurden die erstellten Booch Templates dokumentiert und die Klassen und Objektdiagramme aktualisiert Eine Benutzungsdokumentation wurde nicht erstellt Die konstruierten Prototypen Der erste Prototyp realisierte folgende Aspekte e Er zeigte wie das geplante Werkzeug aussehen wird indem das Layout der Fenster im Werkzeug und ihre Interdependenzen betrachtet werden konnten e Er demonstrierte wie mit dem Werkzeug gearbeitet werden kann Es konnten Bankfunktionen plaziert werden und mit der Maus konnten Nachrichtenfl sse zwischen den Arbeitspl tzen eingerichtet werden Die gesamte fachliche Komponente und insbesondere der Generierungs mechanismus f r die Entscheidungstabellen fehlten jedoch Der erste Prototyp wurde von den Spezialisten des SWIFT Systems von den Entwicklern und von Mitarbeitern des Marketing bewertet Dabei wurden W nsche eingebracht die die Pr sentation des Editors betrafen Weiterhin wurden auch Funktionen identifiziert die der Editor noch nicht zeigte die aber ben tigt werden F r die Bewertung des Prototyps gab es keine definierten Kriterien sie geschah mehr oder weniger intuitiv Der erste Prototyp wurde anschlie end iterativ zu einem funktionalen Prototyp in engeren Sinn weiterentwickelt Der Aufwand daf r betrug 32 Personentage der Prototyp besteht aus 60 100 Klassen Dieser Prototyp zeigte nicht nur die Oberfl che und die Handhabung des Werkzeugs
11. Daten ben tigt wurden Im Bezug auf den Qualit tssicherungsproze ergaben sich keine nderungen im System Der Aufwand f r den dritten und vierten Prototyp wird auf ca ein Personenjahr gesch tzt Erfahrungen der Entwickler Insgesamt waren die Entwickler mit der Durchf hrung des Projektes zufrieden Sie empfanden es allerdings als nachteilig da die Benutzer erst sehr sp t in den Entwicklungsproze eingezogen wurden Als Grund daf r geben sie an da die Benutzer nicht berzeugt werden konnten da der damit verbundene Aufwand letzlich rentabel ist Der Einsatz von Smalltalk 80 bei der Entwicklung des Systems wurde insgesamt positiv bewertet Die schlechte Unterst tzung der Teamarbeit und die Schwierigkeiten bestehende Systeme in Smalltalk 80 zu integrieren wurden als Kritikpunkte genannt Bei einer erneuten Durchf hrung des Projekts w rden die Entwickler auf eine bessere Dokumentation des Entwurfs achten Hier w re ihrer Meinung nach eine bessere Unterst tzung des Smalltalk Systems hilfreich So wurde es als negativ empfunden da Entwurfsentscheidungen nicht geeignet abgelegt werden k nnen Sie k nnen nach Meinung der Entwickler nicht an eine Klasse gekn pft werden Zudem besteht nicht die M glichkeit Kategorien von Klassen zu dokumentieren Unsere Einsch tzung Der erste Prototyp diente dazu auf der Seite der Entwickler ein erstes Bild des sp teren Systems zu schaffen und die verwendete Entwicklungsumgebung
12. Framework bereits eine umfangreiche Klassenbibliothek die verwendet werden kann um die Oberfl che zu realisieren e Smalltalk bietet einen Satz von Entwicklungswerkzeugen und wird interpretativ ausgef hrt dies erleichert die schnelle Konstruktion von Prototypen Der Entwic klungsproze Das Projekt wurde so geplant da nach einer Analyse und Entwurfsphase ein erster Prototyp erstellt werden sollte der das Arbeiten mit SNE und die Oberfl che von SNE zeigen sollte Anschlie end sollte dieser erste Prototyp der den Charakter eines Labormusters hatte zu einem funktionalen Prototyp im engeren Sinn weiterentwickelt werden der den Anwendern pr sentiert werden kann Die Finanzierung des Projekts war bis zur Demonstration des zweiten Prototyps gesichert Anschlie end sollte entschieden werden wie weiter zu verfahren ist Der Aufwand f r die Analyse betrug acht Personentage der f r den Entwurf 12 Personentage Auf der Basis des Entwurfs wurde der erste Prototyp in 14 Personentagen entwickelt Als Vorbild f r die Konstruktion der Oberfl che dienten existierende Nachrichten Szenarien die auf Papier vorlagen Es wurde angestrebt deren Aussehen auch mit dem Werkzeug zu erzielen In der Analyse und im Entwurf wurde die Booch Notation f r Klassen und Objektdiagramme eingesetzt Dies wurde ohne Werkzeugunterst tzung getan was nachtr glich als Manko bewertet wird Schritthaltend mit der Entwicklung der Framework Projekte Enor
13. Management das Beratungssystem objektorientiert auf PCs mit grafischer Benutzungsoberfl che zu entwickeln HyperCard Projekte Error Bookmark not defined Benutzte Werkzeuge Zu Wiederbeginn des Projektes wurde von externen Beratern ein Demonstrationsprototyp konstruiert Die Entwicklungsumgebung f r den Demonstrationsprototyp bestand aus einem Apple Macintosh IIcx mit HyperCard 2 0 HyperCard wurde gew hlte weil die Berater bereits umfangreiche Entwicklungserfahrung hatten und sie dieses System als besonders geeignet f r einen schnellen Demonstrationsprototyp einer B roanwendung einsch tzten Die weiteren Prototypen und das ausgelieferte System wurden mit folgender Umgebung entwickelt e PCs 386 und 486 unter OS 2 e Glockenspiel C Pre Compiler mit Debugger und selbsterstelltem Trace Tool e Common View von Glockenspiel als GUI Bibliothek CASE PM und Digitalk PARTS als Interface Builder e Professional Workbench PWB von Microsoft e PVCS f r die Versionenverwaltung e Profiler f r Zeitmessungen Der Entwic klungsproze Der Projektablauf l t sich wie gesagt in zwei Abschnitte gliedern e ein konventioneller Entwicklungsabschnitt nach einem klassischen Life Cycle Modell e ein objektorientierter Abschnitt nach Prinzipien des evolution ren Prototyping Im Verlauf des objektorientierten Projektabschnitts wurde die objektorientierte Entwicklung im Rahmen einer expliziten evolution ren Vorgehensweise erprobt
14. OOD eingef hrt und neue Werkzeuge Smalltalk eingesetzt werden Prototyping wird evolution r durchgef hrt und es werden Prototypen f r die unterschiedlichen Zwecke erstellt zum einem konnte mit einem Prototyp die Handhabung der Anwendung gezeigt werden zum anderen wurde ein funktionaler Prototyp erstellt der den potentiellen Anwendern gezeigt werden konnte Das Application Framework Smalltalk hat den Aufwand f r die Entwicklung der Prototypen gering gehalten weil sowohl im Bereich der Oberfl chenkomponente als auch im Bereich der fachlichen Komponente existierende Klassen wiederverwendet oder durch Subklassenbildung angepa t werden konnten Allerdings f hrt das Arbeiten mit einer Entwicklungsumgebung wie sie von Smalltalk zur Verf gung gestellt wird h ufig dazu da zu fr h mit der Implementierung begonnen wird ohne da ein tragf higer Entwurf vorliegt Dies mag an den sehr kurzen Entwicklungszyklen einer interpretativen Sprache liegen Dies f hrt dann zu Strukturen die nicht als Basis f r die evolution re Entwicklung Framework Projekte Emor Bookmark not defined zum Zielsystem verwendet werden k nnen Ein technisches Redesign ist dann unumg nglich Smalltalk als Prototyping Werkzeug Smalltalk kann unter verschiedenen Aspekten betrachtet werden Dazu z hlen beispielsweise die Programmiersprache selbst oder die Entwicklungsumgebung Nachfolgend soll Smalltalk unter dem Aspekt eines Application Frameworks bewertet
15. Oberfl chenkomponenten formal zu spezifizieren Das hei t da ein systematischer formaler Weg von der fachlichen Spezifikation zum korrekten lauff higen Softwaresystem schon konzeptionell nicht gangbar ist Nur in wenigen eingeschr nkten Bereichen wie der Entwicklung standardisierter Datenbankanwendungen ist es dar berhinaus m glich aus dem fachlich logischen Anwendungsmodell eine brauchbare Ober fl che zu generieren Auch dies macht Prototyping zur unumg nglichen Projekt aktivit t 6 2 2 Prototyparten und Oberfl chenprototypen Wir haben einleitend gesagt da sich die Einteilung in Prototyp Arten f r die Klassifikation von Projektaktivit ten bew hrt hat Die untersuchten Projekte lassen Analyse Enor Bookmark not defined einen Trend zu einer Differenzierung beim Bau von Prototypen erkennen Es wird nicht mehr nur ein Prototyp gebaut sondern die unterschiedlichen Prototyparten werden gezielt eingesetzt Einige Projekte zeigen da es billiger und insbesondere fachlich besser ist ein Ensemble verschiedener Prototypen zu bauen Dadurch k nnen die verschiedenen Prototyparten besser auf die jeweils im Projekt relevanten Fragestellungen zugeschnitten werden Viele der Fallstudien zeigen da die ersten Prototypen entweder direkt zur Projektakquisition oder zumindest als Demonstrationsprototypen f r das mittlere bzw obere Management bestimmt sind um hier ein Verst ndnis f r das zu entwickelnde System zu schaffen Diese
16. Prototypen werden allerdings oft nicht ausreichend mit den Benutzern diskutiert wobei dies allerdings auch nicht ihr vorrangiger Zweck ist Interessant in diesem Zusammenhang ist da Prototyping zu Akquisitionszwecken meist eine h here Akzeptanz beim Management hat als sein Einsatz bei der anwendungsorientierten Entwicklung in integrierten Teams W hrend die begriffliche Differenzierung nach Prototyparten n tzlich ist hat die konzeptionelle und analytische Betrachtung der Projekte gezeigt dafs Oberfl chen Prototyping kein homogener Begriff ist Die dabei entwickelten Prototypen k nnen als reine Demonstrationsprototypen oder als funktionale Prototypen ausgelegt sein Ebenso differenziert ist der Proze selbst Bei genauer Betrachtung finden wir alle drei Arten des Prototyping explorativ experimentell und evolution r Was ist also Oberfl chen Prototyping letztlich Wir haben gesehen da dabei das Anwendungsgebiet und die verwendete DV Technologie eine gro e Rolle spielen Im Bereich der von uns eingegrenzten interaktiven Anwendungssysteme die wir heute sowohl bei Informationssystemen als auch in der Prozefssteuerung finden kommt dem Zusammenspiel von fachlicher Komponente und Oberfl che eine besonders gro e Bedeutung zu Dazu kommt da sich dieses Zusammenspiel den bisher propagierten formalen Ans tzen der Softwaretechnik entzieht und da daher ein besonders gro er Bedarf nach experimentellen Ans tzen und R ckkopplung mit
17. Prototyping eingesetzt werden wenn es einen darauf abgestimmten Interface Builder gibt Fehlt der Interface Builder oder reicht sein Leistungsumfang nicht aus so entsteht ein entsprechend h herer Programmieraufwand f r die Oberfl chenkomponenten Generell gilt da ein nicht unerheblicher Lernaufwand notwendig ist um ein Application Framework im intendierten Sinn verwenden zu k nnen Dieser Aufwand darf nicht untersch tzt und mu eingeplant werden Analyse Enor Bookmark not defined Kapitel 6 Analyse und Bewertung In diesem abschlie enden Kapitel wollen wir res mieren was aus unserer Sicht Erfahrungen Konzepte und Entwicklungslinien beim Prototyping von Oberfl chen sind Dabei beziehen wir uns zun chst auf die Gespr che und Analysen die unmittelbar zu dieser Studie gef hrt haben Dar ber hinaus haben wir nat rlich unseren jeweiligen beruflichen Hintergrund einflie en lassen Alle Mitglieder des Autorenteams besch ftigen sich seit l ngerer Zeit intensiv in verschiedenen Bereichen mit Fragen des Prototyping der benutzerorientierten Software entwicklung und mit der Konstruktion und dem Einsatz von Werkzeugen zum Oberfl chen Prototyping Wir sprechen aber nicht nur Fragen an die sich auf Oberfl chen Prototyping im engeren Sinnen beziehen In diesem Res mee wollen wir insgesamt aufzeigen wo Prototyping heute steht d h wie Prototyping Projekte heute gestaltet werden und welche Erfahrungen sich dabei verallgemeinern
18. So sind z B Oberfl chenprototypen bei denen werkzeugbedingt die fachliche Komponente in der Form von interpre tierbaren Programmfragmenten eng in die Oberfl chenkomponente integriert ist nur begrenzt f r gro e und komplexe Anwendungen ausbauf hig Ein weiterer wesentlicher Aspekt zum Thema objektorientierter Software Architekturen wird unter dem Stichwort Designmuster diskutiert Es geht darum bestimmte wiederkehrende Muster bei der L sung hnlicher Probleme so zu beschreiben da daraus eine Sprache f r die Software Entwicklung unter Verwendung vorgefertigter Architekturkonzepte entsteht Als Beispiel sei der in dieser Studie wiederholt angesprochene Mechanismus von Ereignis und Reaktion in Systemen mit Ereignisbehandlung genannt Zumindest f r Prototyping Werkzeuge die bei der Arbeit mit Application Frameworks eingesetzt werden sollen wird es ein relevantes Auswahlkriterium werden ob sich mit solchen Werkzeugen Prototypen konstruieren lassen die der gew nschten Architekur entsprechen Diese Architektur mu konform zu den im Entwicklerteam ausgew hlten Designmustern sein 6 4 Prototyping und Werkzeugunterst tzung F r den Einsatz der verschiedenen Werkzeuge ist neben der vorrangigen konzeptionellen Klarheit sehr wichtig ihren Einsatzschwerpunkt zu kennen d h den Typ von Anwendung f r den das jeweilige Werkzeug entwickelt worden ist Denn Analyse Enor Bookmark not defined entgegen anderer Behauptungen beso
19. als zwanzig Jahren Erfahrung im Software Engineering begleitet wird Ein weiterer Grund f r eine ablehnende Haltung gegen ber Prototyping r hrt oft daher da Prototyping mit einem nicht geplanten Vorgehen in der Software Entwicklung gleich gesetzt wird Wir haben die Zusammenh nge aufgezeigt und Probleme dort identifiziert wo Prototyping nicht durch eine entsprechende Vorgehensweise unterst tzt wird Ma geblich ist hierbei der Einsatz von anwendungsorientierten Dokumenttypen die wie Szenarien oder Glossare f r alle Analyse Enor Bookmark not defined beteiligten Gruppen verst ndlich sind Dadurch werden erst die Analysen eines Anwendungsbereichs und eine fachliche Modellierung des zuk nftigen Systems diskutierbar und bewertbar Dazu kommt die sorgf ltige Planung von R ckkopplungs und Bewertungsprozessen Wir haben in den Fallstudien gesehen da des fteren Zeit oder Mittel f r diese zentralen Aktivit ten fehlten und dadurch erhebliche fachliche und technische Probleme entstanden Ein in diesem Zusammenhang gelegentlich ge u erter Vorbehalt gegen das Prototyping ist da sich Benutzer und Entwickler durch einen Prototyp in einem fr hen Projektstadium auf eine technische L sung fixieren ohne da grunds tzliche Alternativen in Erw gung gezogen werden Dies kann dazu f hren da ausgehend von einem Prototyp nur noch Details angepasst werden ohne die fachliche und software technische Gesamtlinie infrage zu stellen od
20. berhaupt zulassen 6 4 3 Auswahl und Einsatz Die Auswahl des f r den Anwendungsfall richtigen Werkzeugs ist differenzierter zu sehen als dies in einigen Projekten geschehen ist Zum Teil wurde aus fehlender Marktkenntnis nicht das Optimum der vorhandenen Werkzeuge eingesetzt Als Beispiel k nnen die Smalltalk Projekte gelten F r den angestrebten Zweck h tte es eine ganze Reihe von Werkzeugen gegeben z B Interface Builder Klassen bibliotheken etc die das Oberfl chen Prototyping wesentlich vereinfacht h tten Dabei mu differenziert werden F r standardisierte d h h ufige Anwendungen sind entsprechende Oberfl chenkomponenten vorhanden und werden zusammen mit gut einsetzbaren Werkzeugen angeboten Aber berall dort wo ma ge schneiderte L sungen komplexe oder neue Oberfl chenkomponenten erfordern ist auch heute noch Handarbeit gefragt Dann erweisen sich Werkzeuge die die Programmierung von Oberfl chen erleichtern gegen ber Werkzeugen zur Komposition parametrisierbarer Bausteinsammlungen als berlegen Die Auswahl der Prototyping Werkzeuge ist keiner festen Gruppe zuzuordnen Nat rlich ist dies oft eine Aufgabe der Entwickler Daneben gibt es aber eigene Methoden und Werkzeuggruppen die in einer Entwicklerorganisation f r Auswahl und Installierung aller Entwicklungswerkzeuge zust ndig sind Hier ist oft ein genauer Blick angesagt Wir kennen F lle in denen mit dem Argument der unternehmenseinheitlichen Softwa
21. der Oberfl chen weitere Anforderungen an die resultierende Architektur von Prototypen gestellt werden Dies bedeutet folgendes Beim Bau funktionaler Prototypen werden Oberfl chenkomponenten mit den funktionalen Teilen des Systems verbunden Als Konsequenz der Auswertungsprozesse werden dann sowohl die funktionalen als auch die Oberfl chenkomponenten eines Prototyps weiterentwickelt Welche konstruktiven Auswirkungen diese Weiterentwicklung hat wird durch die Art des Werkzeugs und die Architektur des Prototyps bestimmt Sind die funktionalen Teile z B als Zus tze in ein generiertes Rahmenwerk f r die Interaktion eingef gt dann f hren nderungen an der Benutzungsoberfl che meist dazu da die funktionalen Codesegmente per Hand in das neu generierte Ger st bertragen werden m ssen Einfacher ist die Weiterentwicklung wenn das Werkzeug die interaktiven Oberfl chenkomponenten der Prototypen so kapselt da sie eine definierte Schnittstelle zur den ebenfalls gekapselten fachlichen Komponente besitzen siehe dazu auch 2 3 1 Architektur von Oberfl chen 2 1 4 Arten des Prototyping In der europ ischen Diskussion ber Prototyping hat sich die von Floyd 84 vorgeschlagene Begrifflichkeit der drei E durchgesetzt Differenzierungen ergeben sich bei der Interpretation dessen was unter explorativ experimentell und evolution r verstanden wird Wir stellen zwei Richtungen fest Die Sichtweise die den Proze und die dabei angestr
22. die Entwickler sammeln Erfahrungen ber Machbarkeit und Zweckmafsigkeit eines Anwendungssystems Dies geschieht meist anhand von funktionalen Prototypen und Labormustern Beim experimentellen Prototyping lafst sich eine klassische Phasentrennung kaum noch aufrecht erhalten e Experimentelles Prototyping produktbezogen Es betrachtet die Konstruktion und Bewertung der Prototypen durch die Entwickler Durch experimentelles Prototyping sollen die Machbarkeit einer DV L sung gekl rt und ber Designalternativen entschieden werden Da diese Aussagen auch auf das Zielsystem zutreffen m ssen sind funktionale Prototypen und Labormuster der Gegenstand des experimentellen Prototyping Dabei ist es nicht vorrangig von Interesse ob die Anwender in den Proze integriert sind e _ Evolutiondres Prototyping proze bezogen Es ist Teil eines kontinuierlichen Verfahrens in dem ein Anwendungssystem innerhalb einer Organisation an die sich ndernden Randbedingungen angepa t wird Dabei wird Prototyping nicht mehr in einem einzelnen in sich geschlossenen Projekt eingesetzt sondern dient zur Unterst tzung der kontinuierlichen Weiterentwicklung der DV technischen Infrastruktur einer Organisation Beim evolution ren Prototyping kann das ganze Spektrum der Prototyparten zum Einsatz kommen Gro e Bedeutung haben Pilotsysteme da selten Zielsysteme im traditionellen Sinne entwickelt werden Enor Bookmark not defined Grundlagen e _ Evolutiondres Pro
23. praxisgerecht empfunden Zudem unterst tzt es den evolution ren Prototyping Proze gut Allerdings mu die integrierte Programmiersprache mit einem gewissen Ma an Disziplin eingesetzt werden Positiv wurde die M glichkeit bewertet externe Routinen einzubinden sowie ein Laufzeitsystem abgekoppelt von der Entwicklungsumgebung erzeugen zu k nnen Unsere Einsch tzung Dieses Projekt kann unter verschiedenen Gesichtspunkten als typisches Prototyping Projekt gesehen werden Hier w re zun chst das Pflichtenheft als Ausgangspunkt des ersten Prototyps Dabei wird deutlich da es schwierig ist interaktive Systeme ausreichend und f r alle beteiligten Personengruppen verst ndlich in Pflichtenheften zu beschreiben Gleichzeitig mu aber festgestellt werden da trotz dieser mittlerweile verbreiteten Einsicht das Pflichtenheft eine gro e Bedeutung f r Vertragsabschl sse und Projektinitiierung hat Wir folgern daraus da neue Dokumenttypen und eine andere Art der Vertragsgestaltung f r Prototyping Projekte erforderlich sind Bemerkenswert ist weiterhin da obwohl die evolution re Weiterentwicklung der Prototypen zum Anwendungssystem geplant war die ersten beiden Prototypen nur als Diskussionsbasis f r die beteiligten Personengruppen dienten Hier wurde die richtige Konsequenz aus der Einsicht gezogen da die ersten Prototypen in einem komplexen neuen Anwendungsbereich noch zu weit von den Vorstellungen der Anwender entfernt waren
24. sich jenseits des Modells eines elektronischen Karteikastens bewegen So war es relativ einfach einen Modellrechner auf Formularen zu skizzieren aber deutlich aufwendiger einen Formularkopierer zu realisieren Die eigentlichen direkt manipulativen Komponenten des HyperCard Systems werden unterschiedlich beurteilt W hrend es recht problemlos war neue interaktive Oberfl chenelemente wie Kn pfe und Schreibfelder anzulegen und zu ndern wurde der Entwurf von Hintergr nden Inschriften und Dekorationen als mangelhaft bezeichnet Es wurde als unbefriedigend empfunden wie die Oberfl chenelemente positioniert werden und wie sie sp ter ver ndert werden k nnen Dafs Demonstrationsprototyp und Anwendungssystem auf v llig unterschiedlichen Systemplattformen realisiert wurden hatte zun chst Vorteile da keine Mi verst ndnisse ber noch ausstehende Aufwendungen f r das fachliche und technische Design bei den Beteiligten aufkamen L ngerfristig zeigte sich aber der Nachteil da in der dann verwendeten OS 2 Entwicklungsumgebung kein entsprechendes Werkzeug f r ein schnelles Oberfl chenprototyping zur Verf gung stand mit dem Entwurfsskizzen erstellt werden konnten Unsere Einsch tzung Das Projekt kann als ausgepr gtes Prototyping Projekt in einem typischen Anwendungsbereich Arbeitsplatzsysteme f r eine B roanwendung bezeichnet werden Die Vorgehensweise beruhte auf einer expliziten Methodik die Prototyping HyperCard Projekt
25. sondern er generierte auch die gew nschten Assemblerteile Weiterhin wurde bereits berpr ft ob die mit dem Werkzeug erstellten Nachrichten Szenarien korrekt definiert sind Ein kontextsensitives Hilfesystem wurde ansatzweise implementiert Der funktionale Prototyp wurde den potentiellen Anwendern gezeigt Daraufhin wurde entschieden auf dessen Basis die Produktentwicklung zu beginnen Es werden daf r zwei Personenjahre gesch tzt Die Produktentwicklung ist zur Zeit noch nicht abgeschlossen F r die endg ltige Entwicklung der Benutzungsoberfl che sind Grafiker und Spezialisten f r Software Ergonomie aber auch Anwender am Projekt beteiligt worden In den Entwicklungsproze werden fachliche und technische Reviews eingeplant dies ist w hrend der Prototypenentwicklung nicht geschehen In der Produktentwicklung arbeitet ein Kern des Teams mit das die beiden Prototypen erstellt hat Erfahrungen der Entwickler Der Einsatz der Booch Methode wurde als sehr hilfreich bewertet jedoch sollte sie werkzeugunterst tzt eingesetzt werden damit die Systemdokumentation vereinfacht und vereinheitlicht wird Emor Bookmark not defined Framework Projekte e Die eingeplante Zeit f r die Entwicklung der beiden Prototypen wurde deutlich unterschritten weil einiges aus der Klassenbibliothek wiederverwendet werden konnte und das interaktive System die Arbeit erleichtert Der Laborprototyp wurde bereits nach 2 3 der eingeplanten Zeit fertig
26. und bewertet werden konnten Verschiedene Gr nde f hrten zur negativen Beurteilung e W hrend des gesamten Prototyping Prozesses war keiner der potentiellen Entwickler des Zielsystems das sind die Mitarbeiter des Software Hauses an der Prototyp Entwicklung beteiligt Daf r wurden Kostengr nde genannt So kam nat rlich kein Wissenstransfer zustande e Durch die mangelnde Zusammenarbeit zwischen der Abteilung der Hochschule und dem Software Haus fehlte beim letzteren das n tige Wissen um den Prototyp warten und weiterentwickeln zu k nnen e Nach der gro en Feldstudie mit den zwei funktionalen Prototypen wurde der eine ohne nderungen als Teil des Angebots eingereicht Das gewonnene Wissen konnte nicht mehr in einen verbesserten Prototyp einflie en so da die Feldstudie keinen Einflu auf den Prototyp hatte Im methodischen Bereich wurden folgende Erfahrungen gemacht e Beim Design der reinen Oberfl chenprototypen hat sich die Zusammenarbeit in einem interdisziplin ren Team gelohnt Dies war deshalb so wichtig weil das Aussehen des Prototyps v llig frei entworfen wurde und so neue Ideen ausprobiert werden konnten e Die gezielte Bewertung der Interaktionselemente war sehr wichtig da keine Vorgaben f r die Benutzungsoberfl che bestanden und die Entwickler fr h sicherstellen wollten da die wichtigsten Interaktionselemente gut zu handhaben sind HyperCard Projekte Error Bookmark not defined e Mindestens ein Ent
27. unwissenschaftlich und soft abqualifiziert werden Nach wie vor wird dort die Hoffnung gehegt durch umfassende formale Methoden eine vollst ndige Spezifikation der Systemanforderungen in korrekte Software berf hren zu k nnen Auch hier sind Ans tze die sich um eine Komplementarit t von formalen Methoden und experimentell evolution rer Vorgehensweise bem hen eher die Ausnahme Erfreulicher sieht das Bild aus wenn wir die Unternehmen betrachten die sich auf aktuelle Trends wie Client Service Computing Objektorientierung und Software f r kooperative verteilte Arbeit spezialisiert haben In diesen Bereichen sind Prototyping und die damit verbundenen Entwicklungsstrategien zur Alltagspraxis geworden Auch DV Abteilungen von Organisationen die verst rkt auf kunden zentrierte Dienstleistungen umstellen haben diesen Trend erkannt Von diesen Bereichen werden neue Impulse f r das Prototyping ausgehen Wir erwarten da sich hier die wechselseitige Beziehung von Entwicklungsstrategie und Unter nehmensorganisation am st rksten zeigen wird Prototyping f r Anwendungssysteme ist heute berwiegend Oberflachen Prototyping Dies ist schon durch die ver nderte DV Landschaft eine Notwendigkeit geworden Dazu kommt da Benutzer heute durchg ngig interaktive Anwendungssoftware in dem von uns beschriebenen Rahmen fordern Die Mittel zur Realisierung von Oberfl chen Prototyping sind vorhanden Die Werkzeug unterst tzung hat sich in den
28. werden F r ein tieferes Studium von Smalltalk verweisen wir auf die vorhandene Literatur Smalltalk enth lt das MVC Framework um interaktive Anwendungen zu erstellten Es bietet alle die Vorteile die wir bereits in allgemeiner Form in Abschnitt 4 4 4 f r Application Frameworks beschrieben haben MVC definiert eine Standard Architektur f r diese Anwendungen Smalltalk stellt im Sinne eines Application Frameworks Klassen zur Verf gung die der Programmierer entweder direkt verwenden kann oder Unterklassen dazu bildet Ist dieses Konstruktionsprinzip einmal verstanden k nnen Oberfl chen architektonisch sehr sauber erstellt werden die bereits eine Schnittstelle zur fachlichen Komponente der Anwendung definieren Einen eigenen Interface Builder um die Oberfl chenkomponente nach dem MVC Konzept zu definieren ist standardm ig jedoch nicht in Smalltalk vorhanden auf dem Software Markt werden solche Werkzeuge allerdings angeboten Digitalk PARTS VisualWorks von ParcPlace oder VisualAge von IBM Smalltalk bietet als Programmierumgebung eine Vielzahl von Werkzeugen Diese und die interpretative Ausf hrung f hren zu kurzen Entwicklungszyklen die auch f r das Oberfl chen Prototyping von Vorteil sind Die von den Entwicklern ge u erten Probleme im Bereich Versionen und Varianten Management wenn mehr als zwei Personen an der Entwicklung beteiligt sind stimmen mit unseren Erfahrungen berein Es existieren jedoch Systeme f r Sm
29. werden in diesem Kapitel explizit nicht betrachtet Da Oberfl chen mit diesen Bibliotheken auf dem Niveau konventioneller imperativer Sprachen programmiert werden m ssen sind sie f r das Oberfl chen Prototyping weniger geeignet Enor Bookmark not defined Werkzeugeigenschaften 3 1 Gestaltung der Oberfl chen Werkzeuge k nnen danach klassifiziert werden wie mit ihnen Benutzungsoberfl chen definiert werden k nnen In Myers 92b werden zwei wesentliche Klassen unter schieden e Direkt manipulative Werkzeuge erlauben da die angebotenen grafischen Elemente einer Oberfl che beim Entwurf durch direkte Interaktion d h durch Auswahl und Positionierung auch direkte Manipulation genannt mit der Maus zu einem Ganzen zusammengesetzt werden k nnen e Sprachbasierte Werkzeuge stellen eine eigene Sprache zur Verfiigung mit der die Elemente einer Oberflache und deren Positionen textuell aber auf einem hohen Abstraktionsniveau definiert werden k nnen Es ist wesentlich komfortabler einfacher und schneller Benutzungsoberflachen direkt manipulativ am Bildschirm zusammenzubauen als diese in einer eigenen Sprache zu spezifizieren Da die Geschwindigkeit mit der eine Oberflache definiert und weiterentwickelt werden kann von gro er Wichtigkeit f r das Prototyping ist sind grafische Werkzeuge den sprachbasierten Werkzeugen vorzuziehen Im folgenden gehen wir ausschlie lich auf solche Werkzeuge ein Da das Spektrum der Funk
30. Benutzungsoberfl chen erm glichen die Realisierung beliebiger Grafiken auf Bitmap Displays Auf diesen Bildschirmen werden nicht mehr ganze Zeichen sondern einzelne Bildpunkte Pixel angesprochen Derartige Benutzungsoberfl chen sind die Voraussetzung f r sogenannte WYSIWYG Systeme What you see is what you get und f r die ganze Klasse der WIMP Oberfl chen Window Icons Menus Pointers F r ihre Gestaltung gibt es verschiedene Arten von Werkzeugen wie Interface Builder Application Frameworks etc Das aus unserer Sicht charakteristische Merkmal ist da grafische Benutzungsoberfl chen auf die Darstellung am Bildschirm festgelegt sind Neben den Bitmap basierten Systemen gibt es f r Anwendungen besonders im CAD Bereich sog Vektorgrafik Systeme die wir aber hier nicht weiter betrachten 3 Multimodale Benutzungsoberfl chen erlauben da die Benutzer mit dem System ber verschiedenste Kommuni kationskan le interagieren und dabei mehr als nur grafische Bildschirm darstellungen verwenden z B Gestik Sprache Datenhandschuhe Virtual Reality F r diese Oberfl chen gibt es noch keine kommerziell einsetzbaren Entwurfswerkzeuge Die Gestaltung solcher Oberfl chen ist derzeit noch weitgehend ein Forschungs und Entwicklungsthema Enor Bookmark not defined Grundlagen F r den Kontext dieser Studie sind also prim r grafische Benutzungsoberfl chen interessant Uns ist klar da in der industriellen Praxis vielfach noch zeiche
31. Enor Bookmark not defined Einleitung Kapitel 1 Einleitung Der Entwurf von Benutzungsoberfl chen f r interaktive Software Systeme gewinnt im Rahmen der Systementwicklung immer gr ere Bedeutung Erfahrungen aus einer Vielzahl von Projekten Myers 92a zeigen da h ufig mehr als die H lfte des gesamten Entwicklungsaufwands f r die Gestaltung der Benutzungsoberfl che aufgebracht wird Um die Konstruktion von Benutzungsoberfl chen zu unterst tzen wurden in den letzten Jahren eine Vielzahl von Entwicklungswerkzeugen und umgebungen realisiert Diese sollen es den Entwicklern gestatten den Entwurf ihrer Oberfl chen auf einer Abstraktionsebene zu machen die von der Hardware Umgebung und von der Betriebssystem Software unabh ngig ist Mit der gr eren Verbreitung von grafikf higen Arbeitsstationen und PCs hat sich aber auch noch ein anderer Wandel vollzogen W hrend fr her die Betonung darauf lag die M glichkeiten eines Software Systems dem Benutzer zug nglich zu machen r cken heute ergonomische Fragestellungen immer st rker in den Vordergrund Die ergonomische Gestaltung von Benutzungsoberfl chen ist jedoch eine Aufgabe die nicht ohne die Beteiligung der sp teren Benutzer erfolgreich bew ltigt werden kann Erschwert wird diese Aufgabe dadurch da auch die Anwender meist nicht in der Lage sind ihre Gestaltungvorstellungen zu artikulieren und abzusch tzen wie ein entstehendes System in ihre Arbeitsabl ufe integrier
32. Im Projektverlauf wurden zahlreiche Prototypen gebaut Das Spektrum reichte vom Demonstrationsprototyp bis zu Pilotsystemen In der folgenden tbersicht sind die wesentlichen Etappen des Projektes aufgef hrt lheute Computer Associates heute Computer Associates Enor Bookmark not defined HyperCard Projekte Beginn Bezeichnung Prototyp Dauer Mitarbeiter Oktober 90 Einarbeitung in die Demonstrations 2 Monate Projektberater objektorientierte Methode prototyp April 91 Pr sentation auf Haus Messe Prototyp 2 5 2 externe o Februar 91 Konstruktion des ersten Prototyp 1 2 Monate eigenen Prototyps Juni 91 Erster Bankenarbeitskreis GE e Juli 91 Interviews bei den Banken Tr nad August 91 Zweiter Bankenarbeitskreis fe ind September 91 Fachliches Redesign Prototyp 3 8 Oktober 91 Technisches Redesign Prototyp 4 8 Marz 92 Ausbau des Prototyps Prototyp 5 8 Marz 92 Dritter Bankenarbeitskreis Oberflachen 0 2 Monate 1 prototyp Mai 92 Testeinsatz und Prasentation Prototyp 6 3 Monate 8 auf einer Haus Messe Juni 92 Vierter Bankenarbeitskreis 8 Da der Schwerpunkt dieser Studie auf Oberfl chen Prototyping liegt und hier im wesentlichen HyperCard zur Generierung von Prototypen untersucht werden soll konzentrieren wir uns im weiteren auf den Demonstrationsprototyp und den ersten funktionalen Prototyp der bereits in der Zielumgebung realisiert wurde Beim Wiederbeginn des Projektes stellte sich heraus dafs die Entwickler nur s
33. Interface Builder zu erbringen ist kann f r den Prototyping Einsatz dieser Werkzeuge st rend sein Im Grunde gibt es dabei nur zwei Gruppen auf der einen Seite stehen die einfach zu bedienenden Systeme deren M chtigkeit f r den Bau von Prototypen nicht ausreicht wenn diese mehr als das Layout der Oberfl che zeigen sollen Auf der anderen Seite sind m chtige Werkzeuge zum Entwurf von Layout und Verhalten die hervorragend f r das Oberfl chen Prototyping geeignet sind deren Benutzung jedoch mehr oder weniger m hsam erlernt werden mu In den von uns betrachteten F llen war der Lernaufwand f r die Entwickler nicht wirklich von Bedeutung da sie entweder selbst an der Entwicklung der Werkzeuge beteiligt oder Experten in der Benutzung hnlicher Werkzeuge waren Dies l t sich aber mit Sicherheit nicht verallgemeinern Der in Abschnitt 5 2 3 beschriebene positive Nebeneffekt der Nutzung von Interface Buildern n mlich bei der Einarbeitung in die Fenstersystemarchitektur und programmierung sollte nach unserer Auffassung nicht berbewertet werden Die Tatsache da dies positiv bewertet wurde zeigt nur da das verwendete System nicht hinreichend m chtig war Die Eigenheiten der Fenstersysteme sollen durch Interface Builder vor dem Benutzer verborgen bleiben ohne die Entwurfsm glichkeiten zu sehr einzuschr nken Die Qualit t von Interface Buildern im Prototyping Proze zeigt sich nicht zuletzt daran ob sie dem Benutzer die
34. Kieback H Lichter M Schneider Hufschmidt H Ziillighoven Prototyping in industriellen Software Projekten Erfahrungen und Analysen Informatik Spektrum Vol 15 Nr 2 pp 65 77 Literatur Error Bookmark not defined Lichter 93 H Lichter M Schneider Hufschmidt H Ziillighoven Prototyping in Industrial Software Projects Bridging the Gap between Theory and Practice Proceedings of the 15th ICSE IEEE Computer Society Press pp 221 229 Linton 89 M A Linton J M Vlissides P R Calder Composing User Interfaces with Interviews IEEE Computer February L bbecke 93 H L bbecke Prototyping als Entwicklungsmethode f r ein Anwendungstteil projekt in Requirements Engineering 93 Prototyping German Chapter of the ACM Berichte 41 B G Teubner Stuttgart pp 41 48 Maaf 92 S Maa Oberquelle H Perspectives and meatphors for human computer interaction In Floyd C Z llighoven H Budde R Keil Slawik R eds Software Development and Reality Construction Berlin Springer Meyer 88 B Meyer Object Oriented Software Construction Prentice Hall New York Myers 92a B A Myers M B Rosson Servey on User Interface Programming Proceedings of the SIGCHI 92 Monterey May 3 7 Myers 92b B A Myers State of the Art in User Interface Software Tools In H R Hartson D Hix eds Advances in Human Computer Interaction Volume 4 Ablex Publishing Norwood N K J Schmucker Object Oriented Progra
35. Projekte zeigt da 4G Systeme gut geeignet sind um Prototypen zu erstellen Sie erm glichen da Oberfl chen schnell entworfen und ver ndert werden k nnen und da rasch zwischen Entwicklungs und Ausf hrungsmodus hin und her gewechselt werden kann Aufwendig ist es lediglich das Datenbankschema zu ndern da dies von den Werkzeugen kaum oder gar nicht unterst tzt wird Mit den ausgew hlten 4G Systemen konnten s mtliche Arten von Prototypen entwickelt und in einem evolution ren Proze zum Pilotsystem ausgebaut werden Aufgrund ihrer Eigenschaften sind jedoch eng und lose gekoppelte 4G Systeme f r unterschiedliche Einsatzgebiete pr destiniert Die Benutzungsoberfl che einer Anwendung die mit Hilfe eines eng gekoppelten 4G Systems entwickelt wird kann aus der Definition des physischen Datenmodells generiert werden siehe Kapitel 4 3 1 Damit ist die Verwendung eines eng gekoppelten 4G Systems nur f r solche Anwendungen geeignet bei denen die Sicht der Benutzer auf die Daten mit dem physischen Datenmodell bereinstimmt In eng gekoppelten 4G Systemen mufs die Datenmanipulation nicht explizit programmiert werden Das hat zur Folge da sich Prototypen schnell entwickeln lassen Diese Eigenschaft beg nstigt es Demonstrationsprototypen zu erstellen Sie kommt aber auch dann zum Tragen wenn eine konzeptionelle nderung durchgef hrt werden soll da sich ein neuer Prototyp leicht entwickeln l t So ist die Gefahr gering da
36. Proze sicht die in der Softwareentwicklung vor allem als Lern und Kommunikationsproze aller beteiligten Gruppen gesehen wird Die Folgen f r das Prototyping sind offensichtlich W hrend die Produktsicht Prototyping vorrangig als Instrument der Anforderungsanalyse einsetzt versteht die Proze sicht Prototyping als grund legendes Mittel zur F rderung von Lernprozessen und als Grundlage der Kommunikation und Kooperation im gesamten Entwicklungsproze Dies hat seinerseits Auswirkungen auf die Organisation da sich die klassische Abteilungs struktur als sperrig f r solche anwendungs und proze orientierten Projekte mit integrierten Teams erweist Wir werden auch darauf im weiteren noch eingehen Wenn Softwareentwicklung anwendungs und benutzerorientiert gesehen wird dann mu Prototyping als Bestandteil einer evolution ren Vorgehensweise Ausdruck einer neuen Projektkultur sein Eine Projektkultur ist dann entstanden wenn diese Vorgehensweise der Normalfall ist und nicht speziell betont werden mu Dazu m ssen traditionelle Vorgehensmodelle ersetzt werden aber die Entwicklerorganisation mu das neue Konzept auch ihren Kunden gegen ber verdeutlichen Dies hat Auswirkungen bis in die Vertragsgestaltung 6 1 2 Vorgehensmodell Werkzeuge k nnen nur dort einen Nutzen erbringen wo sie in einem stimmigen Gesamtkonzept eingesetzt werden Das hei t zun chst und vor allem da die Vorgehensweise klar und auf den Einsatz von Prototyping au
37. Realisierung von Teilen der Funktionalit t optional war Diese Phase konnte damit termingerecht abgeschlossen werden Der f r ein halbes Jahr geplante Piloteinsatz des Windows 4GL Prototyps begann am Tag nach Durchf hrung des Interviews Ergebnisse liegen daher noch keine vor Die konstruierten Prototypen Es wurden drei Arten von Prototypen erstellt 1 Explorative Prototypen mit Intermedia und SuperCard in der Konzeptphase Sie waren Teil der Spezifikation und dienten zur Demonstration und Diskussion mit den Benutzern Die eingesetzten Werkzeuge wurden im wesentlichen zum Zeichnen verwendet Intermedia ein Werkzeug zur Verarbeitung von Hypertext Dokumenten wurde dabei nicht bestimmungsgem eingesetzt s auch Philosophie nderung in der Kl rungsphase In einem weiteren Projekt mit gleicher Aufgabenstellung k me dieses Werkzeug wegen seiner beschr nkten M glichkeiten nicht mehr zum Einsatz obwohl es sehr schnell zu erlernen ist Aufwand lt 1 Tag SuperCard wurde bestimmungsgem verwendet Der im Vergleich zu Intermedia h here Lernaufwand einige Tage ist durch die gr ere M chtigkeit des Werkzeugs gerechtfertigt Es wird im Wiederholungsfall erneut eingesetzt Bei den Benutzern erlangten diese Prototypen eine hohe Akzeptanz da sie beim Durchspielen einzelner Szenarien sofort die Handhabbarkeit sowie den m glichen Nutzen des Prototyps erkennen konnten Entsprechend ihrer Bestimmung wurde ber diesen Prototypen nur eine B
38. System Interaktives System Reagiert auf eine Benutzeraktion die ber ein Eingabeger t erfolgt mit einer entsprechenden Reaktion auf einem Ausgabeger t Aktionen in reaktiven Systemen k nnen dabei nur vom Benutzer und nicht vom System ausgehen Im Gegensatz dazu stehen sogenannte ablauforientierte Systeme bei denen die Steuerung der Anwendung vom System ausgeht Glossar Eror Bookmark not defined Skriptsprac he Interpretative Programmiersprache die dazu verwendet wird kleine Codefragment zu schreiben die Ereignisse behandeln wie z B das Diicken eines Knopfs Solche Codefragemente werden Event Handler genannt Skriptsprachen sind werkzeug spezifisch Toolbox Modul Bibliothek die abstrakte Datentypen zur Verf gung stellt mit denen man Oberfl chenelemente wie Fenster oder Men s auf relativ hoher Abstraktionsebene handhaben kann UIMS User Interface Management System Erlaubt direkt manipulativ Oberfl chen zu definieren und zu erzeugen Dazu enth lt ein UIMS einen Interface Builder Ein UIMS kann aus einer Entwicklungs und aus einer Laufzeitumgebung bestehen Umgangsform Handhabungsform Beschreibt wie der Benutzer mit einem Oberfl chenelement bzw mit allen Exemplaren einer Oberfl chenelementart umgeht So kann beispielsweise ein Knopf gedr ckt und in einer Liste selektiert sowie gebl ttert werden Enor Bookmark not defined Literatur Literatur Bischofberger 92 W R Bischofberger G Pomberger Prototypi
39. X Claim zur Tabellenkalkulation email voicemail e Radio z B zum Abrufen der letzten Nachrichten IPS Retrieval System mit Anschlu an Handelsblatt Handelsamtsblatt per Diskette und Direktanschlufs an Dow Jones Emor Bookmark not defined 4 Generationsystem Projekte Der Entwic klungsproze Das Projekt hatte eine Laufzeit von vier Jahren und war in sechs Phasen unterteilt Evaluierung des Problemumfelds Ein Benutzer und zwei Entwickler arbeiteten sich in die fachliche Thematik ein indem sie die t gliche Arbeit der Benutzer beobachteten Ergebnis war der Konzeptentwurf f r das Projekt der als Entscheidungsvorlage f r das Management diente Zusammenwachsen eines interdisziplin ren Projektteams Das Team bestand aus Benutzern Entwicklern und einem externen Unternehmensberater Die zwei bis zehn Mitglieder ben tigten ein ganzes Jahr um zu einem gefestigten Projektteam zusammenzuwachsen und ein gemeinsames Verst ndnis des Problems zu haben Die Dauer dieses Abschnitts war f r alle Beteiligten erstaunlich hoch Sie war gepr gt durch systematische Benutzerbefragungen in die auch die Kunden der Bankberater einbezogen wurden Bei den ersten technischen Diskussionen ergaben sich z T heftige Meinungsverschiedenheiten ber das weitere Vorgehen was wesentlich zur Dauer dieser Phase beigetragen hat f r den Erfolg des Gesamtprojekts aber unerl lich war Konzeptphase Aufbauend auf dem nun gefestigten Problemver
40. alltalk wie z B ENVY Developer Team V oder TeamBase die Abhilfe schaffen oder wenigstens das Problem entsch rfen 5 4 2 Ein integriertes Werkzeug zur funktionalen Beschreibung technischer Systeme Das untersuchte Projekt Eine Firma die mechatronische Systeme herstellt h lt regelm ig Qualit ts sicherungs Sitzungen ab Diese QS Sitzungen dienen dazu um Fehlerquellen in den Systemen aufzudecken und um die Abh ngigkeiten zwischen verschiedenen Bausteinen zu untersuchen An diesen QS Sitzungen sind die Entwickler der Systeme und Mitarbeiter der Qualit tssicherung beteiligt Die Ergebnisse einer solchen QS Sitzung werden in speziell daf r vorgesehenen Formularen festgehalten Anhand dieser Formulare wird das System bewertet was zu Verbesserungsma nahmen f hren kann Zudem dienen die Formulare als Qualit tsnachweis f r ausgesuchte Kunden Enor Bookmark not defined Framework Projekte Aus einer Forschungsabteilung kam nun die Idee ein System zu entwickeln mit dem mechatronische Systeme interaktiv am Bildschirm entwickelt werden k nnen Dieses System soll aus zwei Komponenten bestehen e Mit einem Editor sollen die einzelnen Komponenten eines Systems am Bildschirm angeordnet und der Signalflu unter ihnen festgelegt werden k nnen e Ein Modul soll zur Verf gung gestellt werden mit dem die Fehler und Signalflu analyse des Systems durchgef hrt werden kann Die Ergebnisse der Fehler und Signalflu analyse sollen benut
41. anuell bertragen und angepa t werden m ssen oder verloren gehen CASE PM bot zwar in der verwendeten Version eine Option zur automatischen tbertragung von benutzergeschriebenen Programmteilen in eine neue Oberfl chenversion an diese war aber f r ernsthafte Anwendungen nicht brauchbar Dagegen leistete CASE PM gute Dienste um Mitarbeitern die noch keine Erfahrung in der Programmierung mit CommonView und Presentation Manager hatten anhand des generierten Codes Einblick in die Funktion solcher interaktiver Oberfl chen zu bieten Das Wertpapier Projekt In einem Nachfolgeprojekt geht es um die Unterst tzung des Wertpapiergesch fts in den Banken Auch in diesem Projekt stellte der Anwendungsbereich sehr komplexe Anforderungen an eine software technische Unterst tzung Daher wurde gro er Wert auf die Analyse und einen guten fachlichen Entwurf gelegt Dazu wurde die in Grycan 93 beschriebene dokumentenorientierte Analyse und Entwurfstechnik mit Szenarien Glossar und Systemvisionen gew hlt In Erg nzung zu den Systemvisionen wurden einige Oberfl chenprototypen mit dem Interface Builder PARIS erstellt Diese wurden zun chst als Labormuster in der internen Diskussion um Werkzeuge und Materialien verwendet Bei der Auswertung von Szenarien und Systemvisionen wurden sie allerdings auch schon einzelnen Bankenvertretern als Demonstrationsprototypen gezeigt Schlie lich dienten die mit PARTS konstruierten Oberfl chen als grafisches Material
42. ationen wird Anwendungsentwicklung noch nicht vorrangig als Lern und Kommunikationsproze sondern als technischer Entwicklungsproze gesehen Deshalb werden Aufwendungen f r das Erlernen neuer Methoden und die Einarbeitung in neue Werkzeuge nicht richtig eingesch tzt und tendenziell als negativ betrachtet 6 5 Trends und Fazit Schon bei der Vorstellung der einzelnen Werkzeugarten in diesem Bericht hat sich gezeigt da tendenziell die Unterschiede zwischen den einzelnen Werkzeugarten verschwinden Interface Builder Application Frameworks 4 Generationssysteme mit partieller interpretativer Ausf hrung verschmelzen Beispiele sind der NeXT Interface Builder oder die kommerziellen Smalltalk Systeme VisualWorks PARTS VisualAge etc Diese Kombination von aufeinander abgestimmten Werkzeugen f hrt dank der integrierten Interface Builder zu einfach konstruierbaren Oberfl chen Prototypen zur flexiblen Erweiterbarkeit dank der Application Frameworks und aufgrund der entsprechenden Abfragesprachen zur standardisierten Datenabfrage Anzeige und Manipulationsfunktionalit t Die Analyse der Interface Builder zeigt einen interessanten Aspekt Offenbar gibt es mittlerweile ein konsoldiertes Erfahrungswissen dar ber wie die elementaren Elemente einer grafisch interaktiven Oberfl che aussehen sollten Trotz aller Unter schiede im Detail lassen sich quer zu den unterschiedlichen Fenstersystemen und Rechnerfamilien sehr hnliche Grundbaust
43. atzf higes Pilotsystem zu entwickeln Die Entwickler hatten weiterhin das Ziel aufgrund der Erfahrung aus Phase I und II allgemein wiederverwendbare Bausteine f r Handler Anwendungen zu entwickeln Phase II dauerte ca ein Jahr In dieser Zeit haben zwei Entwickler zu 100 am Pilotsystem gearbeitet Folgende Aktivit ten wurden in Phase II durchgef hrt e _ Erarbeiten der exakten bankfachlichen und mathematischen Grundlagen durch die Entwickler In dieser Phase haben sich die Entwickler in enger Zusammenarbeit mit dem zust ndigen Finanzanalytiker und durch extensive Lekt re der Fachliteratur ein vollst ndiges Verst ndnis der Materie erarbeitet Entwickeln einer Datenbankschnittstelle die es der objektorientiert konstruierten Anwendung transparent erm glicht auf Informationen in einer bestehenden und einer zu entwickelnden relationalen Datenbank zuzugreifen e Integration von B rsendaten in Realzeit e Implementierung und Test der Rechnungskomponente e Inkrementelle Weiterentwicklung der Benutzungsoberfl che In Phase II wurden die Anwender nicht mehr zur Evaluation des Systems beigezogen Der Entwicklungsproze war nur noch dort zyklischh wo man verschiedene technische L sungen ausprobierte und wo _ Generalisierungs m glichkeiten gefunden wurden Phase III Weiterentwicklung des Pilotsystems zu einem Produkt Diese Phase hat noch nicht begonnen Erfahrungen der Entwickler Der Aufwand um das ben tigte Fachwi
44. atzrechnern das nicht zumindest in seiner Konzeption objektorientiert aufgebaut ist Wieweit sich dieses Prinzip nach au en in der Verwendung oder beim Ausbau eines Prototyps zeigt ist heute noch sehr unterschiedlich Hier werden oft hybride L sungen angeboten die auch in Zukunft noch ihre Bedeutung bei der Integration interaktiver Anwendungen in bestehende Systeme haben werden Wir werden Anforderungen an die Architektur von Oberfl chenprototypen diskutieren und die jeweiligen Konsequenzen f r den Entwicklungsproze aufzeigen Oberfl chenprototyp und Zielsystem In diesem Zusammenhang stellt sich allgemein die Frage nach dem Verh ltnis von Oberfl chenprototyp und Zielsystem Aus dem bisher Gesagten l ft sich ableiten da ein evolution rer Ansatz d h der schrittweise Ausbau eines Prototyps zum eingesetzten Zielsystem die erw nschte Variante ist Alle konzeptionellen oder architektonischen Br che die sich beim Wechsel der Implementationsplattform der Zielsprache oder sogar des Fenstersystems ergeben machen Abstriche an den Aussagen und Vorgaben die durch das Prototyping gewonnen wurden Benutzerbeteiligung Oberflachen Prototyping bedeutet da die Benutzer in den Entwicklungsproze integriert werden Wenn schon Prototyping als Prinzip aus unserer Sicht eng mit der Bewertung der Prototypen durch die sp teren Benutzer verkn pft so macht Oberflachen Prototyping erst recht wenig Sinn wenn die Benutzer nicht in den Proze
45. au zu wissen was fachlich notwendig ist Notfalls werfen wir es weg Diese Meinung finden wir bei Prototyping gesch digten Managern Grundlage sind in der Regel Erfahrungen die aus Projekten stammen bei denen Prototyping nicht methodisch also im hier vertretenen Sinne durchgef hrt wurde sondern als Etikett f r diese Taktik des Durchwurstelns mi braucht wurde Was neben der Vorgehensweise f r das Gelingen von Prototyping Projekten von gro er Bedeutung ist sind die bereits angesprochenen geeigneten Managementstrategien Wir haben bereits in einer fr heren Studie darauf hingewiesen da ein solches Projekt nicht allein mit den konventionellen Mitteln der Projektf hrung gesteuert werden kann Schlechte Erfahrungen in diesem Bereich k nnen ebenfalls beim Management zur Ablehnung von Prototyping f hren Enor Bookmark not defined Analyse 6 2 Prototypen als Produkt Wir haben Prototypen als Produkte des Prototyping Prozesses sowohl konzeptionell als auch in der Projektpraxis diskutiert Dabei haben wir festgestellt da sich die verschiedenen Prototyparten gut f r eine Klassifizierung der unterschiedlichen Projektaktivit ten eignen Zudem lassen sich Verbindungen zwischen den Prototyparten und Architekturkonzepten erkennen 6 2 1 Systemumgebung Anwendungsentwicklung findet zunehmend in einer sich ver ndernden Systemumgebung statt Wenn wir heute ber interaktive Software sprechen meinen wir vorrangig interaktive Software
46. auf grafischen dezentralen Systemen am Arbeitsplatz ob dies jetzt Arbeitsplatzrechner im Sinne von PCs oder UNIX Workstations sind oder ob sie heute zu den Laptops oder Notebooks gerechnet werden Bei dieser von uns vorrangig betrachteten Form von Anwendungssystemen wachsen die Anforderungen an fachliche Stimmigkeit und die benutzungsgerechte Handhabung Fachliche Stimmigkeit umfa t hier sowohl die fachliche Logik also die interne Funktionalit t als auch die an der Oberfl che sichtbare Begrifflichkeit und Darstellung Dazu kommt die Handhabung als die Art und Weise wie Benutzer mit dem System umgehen mit ihm hantieren k nnen Hierbei kommen dann auch die unterschiedlichen Ein und Ausgabemedien zum tragen und es stellt sich die Frage wie gut ein System f r die Erledigung der entsprechenden fachlichen Aufgaben in der Hand liegt Damit wird auch f r die Softwareentwicklung die Dualit t von Form und Inhalt deutlich Dies bedeutet da Oberfl chengestaltung heute nicht mehr ein nachrangiger Aufsatz auf ein an sich funktionst chtiges System sein kann sondern da sich Handhabung Darstellung und fachlich logische Aspekte gegenseitig bedingen Hier kann u E nur das experimentell empirische Vorgehen des Prototyping weiterf hren Dazu kommt da die formalen Verfahren der Spezifikation f r interaktive Anwendungssoftware besonders schlecht greifen Es gibt u E absehbar keinen Formalismus um reale interaktive Systeme mit ihren
47. b die so konstruierten Oberfl chenprototypen noch in den Projektrahmen passen und keine falschen Vorstellungen erzeugen Schlie lich wollen wir noch auf zwei Aspekte eingehen die als Abfallprodukt des Prototyping mit Interface Buildern in diesem Projekt auff llig sind Die Oberfl chenlayouts werden als Grafiken in Entwicklungsdokumenten verwendet Dies ist kein Einzelfall Wir kennen Projekte in denen solche Entw rfe nicht nur als Illustrationen in Dokumenten sondern auch als Folienvorlagen f r Systempr sentationen und Abstimmungsdiskussionen mit den Anwendern verwendet werden Tendenziell erweist sich aber die parallele Fortschreibung von Oberfl chenentw rfen und Textillustrationen als sehr aufwendig da die Illustrationen in den Texten nicht mehr ver ndert werden k nnen und daher stets der Weg ber den Interface Builder und einen Konversionsschritt z B Bildschirmabzug gegangen werden mu Der zweite Aspekt ist die Verwendung von Interface Buildern als Lerninstrument wenn neue Fenstersysteme eingesetzt werden Dies unterstreicht sehr sch n unsere These da Software Entwicklung ein Lernproze aller beteiligten Gruppen ist der durch Prototyping gef rdert wird Denn in diesem Fall haben die Entwickler den Oberfl chenprototyp als Labormuster genutzt um sich die Arbeitsweise des Fenstersystems zu verdeutlichen Haupts chlich werden Interface Builder aber in diesem und einigen uns bekannten hnlichen Projekten zum Bau von D
48. bar ist Prototyping ist ein Proze modell der Software Entwicklung das speziell auf die oben skizzierten Randbedingungen unklare Aufgabenstellung und komplexe Entwurfsaufgaben abgestimmt ist Prototyping setzt voraus da die sp teren Benutzer in den Entwurfsproze von Systemen einbezogen werden Gerade bei der Entwicklung von Benutzungsoberfl chen ist dies eine unabdingbare Voraussetzung um tragf hige Ergebnisse zu erzielen In diesem Bericht untersuchen wir inwieweit Werkzeuge und Umgebungen f r den Entwurf von Benutzungsoberflachen geeignet sind Prototyping Proze e zu unterst tzen Es geht also darum Konzepte und Praxis des Prototyping und der dabei verwendeten Werkzeuge zu diskutieren Damit wollen wir einen Beitrag zur Bewertung und Weiterentwicklung von grunds tzlichen Aspekten des Prototyping und keine aktuelle Werkzeug bersicht bieten Entsprechend haben wir bei unseren Einsch tzungen der Werkzeuge und ihres Einsatzes auch nur diejenigen Merkmale hervorgehoben die relevant f r die gesamte Werkzeugart sind UBILAB Technical Report 1994 No 94 9 2 Einleitung Enor Bookmark not defined Eine derartige Untersuchung mu Erfahrungen aus Entwicklungsprojekten ebenso ber cksichtigen wie die Analyse der technischen Gegebenheiten der einzelnen Werkzeuge Wir st tzen uns aber nicht nur auf die Erfahrungen unserer Interview partner aus verschiedenen Projekten wir haben auch unsere pers nlichen Erfahrungen aus viele
49. che entworfen Die fachliche Komponente des Gesamtsystems lag zum Beginn der Entwicklung bereits vor und sollte nicht mehr ver ndert werden Zum anderen waren die Entwickler auf der Auftragnehmerseite in der Benutzung eines UIMS erfahren Sie hatten zwar noch nie mit dem SNI DialogBuilder Oberfl chen entworfen hatten aber mit anderen UIMS gearbeitet und waren an der Entwicklung eines anderen UIMS beteiligt Dadurch wurde der Lernaufwand reduziert und vermutlich auch die Qualit t des Endprodukts entscheidend verbessert Aufgrund dieser Randbedingungen lassen sich die Erfahrungen dieses Projekts nicht einfach bertragen Sicher w re die Einarbeitungszeit f r andere Entwickler wesentlich h her gewesen Auch war das UIMS selbst von vornherein ausgew hlt es wurde deswegen keine Zeit ben tigt um ein geeignetes Werkzeug zu suchen Auch Kostenfaktoren spielten bei diesem Projekt keine Rolle da das UIMS vom Auftraggeber selbst entwickelt und den Entwicklern zur Verf gung gestellt wurde Die Einsch tzung des Werkzeugs durch die Entwickler deckt sich weitgehend mit unserer Beurteilung Die in den DialogBuilder eingebaute Skriptsprache die die rasche Simulation der entworfenen Oberfl che ohne tbersetzung und erneutes Binden zul t macht das Werkzeug sowohl f r die Entwicklung von Demonstrationsprototypen als auch f r evolution res Prototyping von Pilotsystemen geeignet 5 2 2 Ein Multimediasystem zur Verkaufsberatung Das untersuchte Pro
50. chitektur zur Verf gung Botsc haften Botschaften im objektorientierten Sinn dienen zur Kommunikation zwischen Objekten Sie werden an Objekte geschickt und l sen dort das Ausf hren einer Methode aus Sie sind den Prozeduraufrufen in tradionellen imperativen Sprachen vergleichbar Callback Werden als eine Variante der Ereignisbehandlung bei interaktiven Systemen verwendet um verschiedene Anwendungsteile wie z B die Oberfl chenkomponente und die fachliche Komponente zu integrieren Dabei gibt die eine Komponente der anderen bekannt welche ihrer Funktionen als Reaktion auf ein Ereignis aufgerufen werden soll Design Muster Abstrakte Beschreibung einer Software Architektur In objektorientierten Systeme legen Design Muster semantische Beziehungen auf Klassenebene mit Hilfe der Vererbungs und Benutzt Beziehung fest Verschiedene Aspekte von Application Frameworks k nnen im Normalfall durch Design Muster beschrieben werden Direktmanipulative Interaktion Interakative Manipulation von Oberfl chenelementen und den durch sie re pr sentierten fachlichen Elementen mit einer Maus oder hlichen Eingabeger ten Im Gegensatz dazu bilden Kommandosprachen oder hnliche indirekte Mechanismen Glossar Enor Bookmark not defined Entwic klungsumgebung Werkzeuge f r das Oberfl chen Prototyping k nnen aus einer Entwicklungs und einer Laufzeitumgebung bestehen In der Entwicklungsumgebung wird die Benutzungsoberflache der Anwendung erst
51. chtlich Zu einem gewissen Grad ist dieses Problem modellinh rent Es kann nicht vollst ndig dadurch gel st werden daf die software technische Qualit t der integrierten Programmiersprachen verbessert wird Die Anbindung von Programmtexten an Oberfl chenelemente und ihre Ereignisse verhindert da bergreifende Strukturen und Zusammenh nge ad quat behandelt werden k nnen Verschiedene L sungen bieten sich an um diesen Nachteil zu beheben Im folgenden beschreiben wir die Mechanismen mit denen die verschiedenen L sungen realisiert werden k nnen 3 7 2 Zeichenkettenbasiertes Protokoll Bei dieser Art kommuniziert die Oberfl chenkomponente ber ein zeichenketten basiertes Protokoll mit der fachlichen Komponente die in einem anderen Proze l uft Die Oberfl chenkomponente erzeugt dazu f r bestimmte Ereignisse eine beschreibende Zeichenkette und bergibt sie einer Schnittstelle zur Interprozefskommunikation Diese Zeichenkette wird dann vom Proze der fachlichen Komponente gelesen und analysiert Die fachliche Komponente reagiert auf das Ereignis und setzt dann wiederum eine Zeichenkette zusammen die die gew nschte Reaktion der Benutzungsschnittstelle beschreibt und schickt diese an die Oberfl chenkomponente Ein Vorteil dieses Ansatzes ist seine Flexibilit t da der Proze der fachlichen Komponente in einer beliebigen Sprache implementiert sein kann Dazu kommt daf beide Komponenten als vollst ndig getrennte Programmeinhe
52. ckkopplungsstrategie hat z B Invertierung eines mit Mausklick angew hlten Textelements in diesem Auswahlmen Wieder bezogen auf Fenstersysteme wie Motif oder Windows spricht man h ufig vom Look amp Feel wenn man charakterische Darstellungs und Umgangsformen auf die einzelnen Oberfl chenelemente bezieht Oberfl chenelementarten Im Entwurfsproze also bei der Anordnung der Oberfl chenelemente zu einem Layout entwickeln wir nicht jedes einzelene Elemente von neuem sondern greifen auf einen vorgegebenen Satz solcher Elemente zur ck Die Mengen gleichartiger Elemente bezeichnen wir als Oberflachenelementarten oder entsprechend Interaktionselementarten Man k nnte sie auch Elementtypen nennen Allerdings kollidiert das gelegentlich mit dem Verst ndnis des Typbegriffs in Programmiersprachen Entscheidend f r die Gestaltung von Oberfl chen ist welche Oberfl chen elementarten vom jeweiligen Entwicklungswerkzeug angeboten werden und mit welchem Aufwand dieser Vorrat vergr ert werden kann Architektur von Oberfl chen Wenn Oberfl chen also mehr sind als ihre u ere statische Darstellung wenn Verhalten dazukommt und wenn schlie lich die Oberfl che in Verbindung mit einer fachlichen Anwendung gebracht werden mu dann schl gt sich das in unterschiedlichen Architekturen von Oberfl chenprototypen nieder Wir unterscheiden zwei konzeptionelle Komponenten auf die wir uns im weiteren immer wieder beziehen Es bietet sich a
53. d analysiert ist als GMD Studie erschienen Kieback 91 Die wesentlichen Ergebnisse sind in einem Beitrag des Informatik Spektrums Kieback 92 sowie im Tagungsband der International Conference on Software Engineering 93 Lichter 93 zusammen fassend dargestellt Abschlie end soll darauf hingewiesen werden da dieser Bericht ohne die Unterst tzung der einzelnen Projektteams deren Erfahrungen beim Oberfl chen Prototyping in Kapitel 5 beschrieben sind nicht zustande gekommen w re Im einzelnen danken wir daf r den beteiligten Mitarbeitern der im folgenden aufgef hrten Unternehmen und Instituten IBM Entwicklungsgesellschaft Bablingen Robert Bosch GmbH Stuttgart RWG GmbH Stuttgart Schweizerische Bankgesellschaft Z rich Siemens AG M nchen Voest Alpine Linz Weiterhin danken wir Josef B sze SBG Z rich und Dmitri Hartmann PSI Berlin Sie haben die Entstehung dieses Berichts durch Beitr ge und kritische Anmerkungen unterst tzt Grundlagen Emor Bookmark not defined Kapitel 2 Grundlagen In diesem Kapitel beschreiben wir die Grundlagen die nach unserer Meinung f r das Verst ndnis des Berichtes ben tigt werden Wir f hren zun chst unsere Terminologie im Bereich Prototyping ein und erl utern die wesentlichen Konzepte und Ziele Anschlie end beschreiben wir die Arten von Benutzungsoberfl chen die heute vorwiegend in Anwendungen vorgefunden werden Im letzten Teil dieses Kapitels haben wir unsere Auffas
54. den Benutzern besteht In diesem gesamten Umfeld kommt solchen Prototypen eine besondere Rolle zu die Oberfl che und Handhabung gemeinsam modellieren also solche Prototypen die wir als Oberfl chen Prototypen bezeichnet haben Im Sinne des gerade Besprochenen ist es besonders wichtig reine Oberfl chen Layouts Mock Ups von Oberfl chenprototypen zu unterscheiden Oberfl chen Layouts sind als Entwurfsskizze im Diskussionsproze des Entwicklerteams oft n tzlich Sie sollten aber ihren Skizzencharakter behalten und als Wegwerfprodukte im Sinne der Code Wiederverwendung konzipiert sein Oberfl chen Layouts sind immer dann problematisch wenn sie in der Diskussion mit Benutzern eingesetzt werden da die Aussagen die auf ihrer Grundlage ber das zuk nftige System gewonnen werden k nnen wenig zuverl ssig sind Solche Oberfl chen Layouts haben wie Demonstrationsprototypen den gro en Nachteil da bei ihnen der fachliche Anteil im Kopf der Benutzer oder Entwickler mitgedacht werden mu wenn sie auf das Zusammenspiel von fachlicher Komponente und Oberfl che untersucht werden sollen Zudem mu beachtet werden da mit Oberfl chen Layouts oft ein Eindruck vom Zielsystem erweckt wird der dann nicht realisiert Enor Bookmark not defined Analyse werden kann Oberfl chenprototypen sollten neben der Oberfl che zumindest eine rudiment re fachliche Komponente zeigen Erst dann ist es m glich die Handhabbarkeit eines Prototyps zu
55. der guten Unterst tzung einer interaktiven zyklischen Prototypentwicklung Die elementare Handhabung der Systeme ist so einfach da sie auch dem engagierten Laien relativ rasch beigebracht werden kann Die Grenzen der HyperCard Systeme sind in den Fallbeispielen schon angedeutet Da ist zum einen die geringe Zuverl ssigkeit von Aussagen ber einen reinen Oberfl chenprototypen Wir haben dies auch schon in anderen Kontexten festgestellt und warnen davor prototyping unerfahrene Benutzer mit derartigen Prototypen zu konfrontieren da sie die schlechtesten Voraussetzungen mitbringen die Begrenztheit eines solchen Systems einzusch tzen Dies ndert sich im Laufe eines partizipativ angelegten Software Projektes wenn sich genug Erfahrung im Umgang mit funktionalen Prototypen angesammelt hat Dann sind Benutzer und Entwickler viel besser in der Lage einen reinen Oberfl chenprototyp als Skizze des eigentlichen Prototyps einzusch tzen Prototypen im eigentlichen Sinne lassen sich mit HyperCard Systemen bis zu einer bestimmten Obergrenze an Komplexit t und Datenvolumen realisieren Dies deutete sich im Fahrkartenautomaten Projekt schon an Dort wurde das Ablaufverhalten im Feldversuch als kritisch bezeichnet Wir kennen HyperCard Prototypen f r komplexe Anwendungen die allenfalls f r die Entwickler als Labormuster dienen k nnen da sie ein indiskutables Ablaufverhalten zeigen Dies liegt an der schlichten softwaretechnischen Struktur und Konz
56. dhabbarkeit in den Vordergrund der Qualit tsdiskussion ger ckt In den Staaten sehen wir dagegen eine Renaissance m glichst quantitativer Ans tze die sich auf die unmittelbare Messung von Softwarequalit t oder der Qualit t des Konstruktionsprozesses beziehen Auch in der europ ischen Diskussion um Prototyping lassen sich Tendenzen feststellen Das traditionelle Software Engineering und die an formalen Methoden orientierten Ans tze stehen der Idee nach wie vor mi trauisch gegen ber Mit dem immer noch vorherrschenden Bild von der Informatik als einer der Mathematik und Enor Bookmark not defined Grundlagen damit der formalen Analyse verpflichteten Disziplin scheint sich der an Experiment und Erfahrung orientierte Ansatz des Prototyping schlecht zu vertragen Nur so k nnen wir uns erkl ren da die methodische und disziplinierte Verwendung von Prototyping Konzepten so wie wir sie auch hier vorstellen oft ignoriert oder mifsinterpretiert wird 2 1 1 Prototyping und Prototyp Was verstehen wir unter den Begriffen Prototyping ist die spezielle Auspr gung des Prozesses der Systementwicklung bei dem Prototypen entworfen konstruiert bewertet und revidiert werden Ziele des Prototyping sind e eine Kommunikationsbasis f r alle beteiligten Gruppen insbesondere zwischen Benutzern und Entwicklern zu schaffen um zu einer gemeinsamen Projektsprache zu gelangen e durch Experimente und praktischen Umgang Erfahrungswissen ber di
57. dokumentierende Aktivit ten festgelegt werden Betrachten wir diese Festlegungen auf der konzeptionellen Ebene dann sprechen wir von einer Entwicklungsstrategie Prototyping ist in diesem Sinne immer Teil einer Entwicklungsstrategie Da Prototyping R ckkopplungsprozese explizit vorsieht und in diesen R ckkopplungsproze bewu t auch die Gruppe der Benutzer einbezieht ist die gew hlte Entwicklungsstrategie nicht unabh ngig von Prototyping Obwohl versucht wird Kieback 92 den Bau von Prototypen in ein konventionelles Phasenmodell zu integrieren hat sich diese Einbettung von Prototyping als problematisch erwiesen vergl L bbecke 93 Vorteilhaft erweisen sich dagegen sog evolution re Entwicklungsstrategien vergl Budde 92 bei denen sich entwerfende konstruierende und bewertende Aktivit ten zyklisch abwechseln Wir halten fest dafs Prototyping je nach Entwicklungsstrategie gef rdert oder in seinen Wirkm glichkeiten behindert werden kann Wenn wir Prototypen unter statischen Aspekten betrachten sprechen wir von ihrer Architektur Ist eine solche Architektur f r die Entwickler strukturell unverst ndlich dann ist der Prototyp nicht weiterentwickelbar Jeder revidierte Prototyp mu dann von vorne entwickelt werden Wir werden mit Blick auf dieses Problem Anforderungen an die verwendeten Werkzeuge ableiten Damit sind wir beim Thema der Entwicklungswerkzeuge zu denen wir auch entsprechende Sprachen rechnen Hand codierte Pro
58. dung integriert werden sollten wurde erst mit erheblicher Versp tung geliefert Gr ere Probleme entstanden als es eingebaut und die dazu notwendige Steuerungssoftware in den vorhandenen Prototyp integriert werden sollte Der Prototyp diente einerseits zur Demonstration vor dem Auftraggeber andererseits auch als Labormuster f r die Entwickler um technische Details und gangbare Wege zu untersuchen und um Erfahrungen bei der Entwicklung von Anwendungen dieser Art zu sammeln Der Prototyp zeigte die gesamte Benutzungsoberfl che der Anwendung Einige Teile der fachlichen Komponente wurden jedoch nicht implementiert Auf ergonomische Aspekte wie beispielsweise dem g nstigsten Einsatz von Farben wurde bei diesem Prototyp keine R cksicht genommen Als Dokumentation liegen im wesentlichen die zu Beginn erstellte und berarbeitete Studie mehrere Ver ffentlichungen sowie Beschreibungen zur Ansteuerung verschiedener Ger te vor Die Struktur der Benutzungsoberfl che wurde nicht dokumentiert Erfahrungen der Entwickler e SX Tools hat sich als ein geeignetes Werkzeug erwiesen um anspruchsvolle Benutzungsoberfl chen zu entwickeln e SX Tools ist geeignet um multimediale Erweiterungen in Benutzungs oberfl chen zu integrieren Die offene Entwicklungsumgebung von SX Tools sowie die Client Server Architektur die die Einbindung von Fremdsoftware wie beispielsweise FrameMaker zul t wurden als besonders wichtig erkannt Interface Bu
59. e Betrachten wir wie HyperCard Systeme im Software Entwicklungsproze verwendet werden dann stellen wir fest da diese meist als reines Prototyping Werkzeug eingesetzt werden Die starke Integration der Entwicklungsumgebung und die enge Anbindung an den jeweiligen Rechner meist Macintosh schr nken die Portabilit t eines HyperCard Prototypen und den evolution ren Ausbau zu einem Anwendungssystem sehr stark ein Damit kommen diese Werkzeuge im wesentlichen f r Demonstrationsprototypen und f r das explorative Prototyping in Frage Wenn im Rahmen des experimentellen Prototyping Fragen der Architektur und der software technischen Umsetzung von L sungsideen zur Diskussion stehen dann ist fraglich in welchem Umfang ein HyperCard Prototyp noch verl liche Aussagen bezogen auf das Zielsystem erlaubt Sind diese Einschr nkungen aber akzeptiert dann erweisen sich HyperCard Systeme als sehr effektive Prototyping Werkzeuge Wir haben gesehen da sich dabei zwei Varianten von Oberfl chenprototypen anbieten der reine Oberfl chenprototyp der bis zum Layout mit v llig simulierter Interaktion reduziert sein kann und der funktionale Prototyp der mit Hilfe der Programmiersprache z B HyperTalk realisiert wird Enor Bookmark not defined HyperCard Projekte Die wesentlichen Vorz ge der HyperCard Systeme beim Einsatz f r die genannten Prototyping Arten liegen in der Schnelligkeit mit der Prototypen erstellt werden k nnen und in
60. e Konstruktion und den m glichen Einsatz des Softwaresystems zu schaffen e eine dynamische Beschreibung des angestrebten Systems zu erhalten und den sich ndernden Bed rfnissen und Einsichten anzupassen Ein Prototyp ist eine spezielle Auspr gung eines ablauff higen Softwaresystems Er realisiert ausgew hlte Aspekte des Zielsystems d h des zuk nftigen Softwaresystems im Anwendungsbereich Das bedeutet e Ein Prototyp ist immer ablauff hig Eine reine Bildschirmmaske die mit einem Grafikeditor erstellt wurde sollte dementsprechend nicht als Prototyp bezeichnet werden e Ein Prototyp realisiert Aspekte des Zielsystems Welche Aspekte in einem Prototyp umgesetzt werden richtet sich nach den jeweils im Entwicklungsproze anstehenden Fragen Zumeist insbesondere bei interaktiven Anwendungen werden sich diese Fragen auch auf die Benutzungsoberfl che kurz die Oberfl che des Systems beziehen Allerdings ist das nicht zwingend Ein Prototyp kann sehr wohl modellieren wie eine Anwendung mit einer Datenbank zusammenarbeitet wobei von der Darstellung der sp teren Oberfl che weitgehend abgesehen wird Derartige Prototypen sind im Entwicklungsproze wichtig stehen aber in dieser Studie nicht weiter zur Diskussion e Prototypen repr sentieren ausgew hlte Aspekte d h diese Aspekte m ssen schon bei der Entwicklung des Prototyps festgelegt werden Dies ist wichtig weil die Auswahl bestimmt welche Fragen von einem Prototyp beantwo
61. e Error Bookmark not defined in den Zusammenhang evolution rer Systementwicklung stellte Eine Serie unterschiedlicher Prototypen dienten den verschiedenen in Abschnitt 2 1 angesprochenen Fragestellungen Dabei wurde der funktionale Prototyp evolution r zum Anwendungssystem ausgebaut Der Einsatz von HyperCard als Prototyping Werkzeug f r einen Demonstra tionsprototyp hat in diesem Projekt exemplarischen Stellenwert Der Demon strationsprototyp vermittelte den Entwicklern und dem DV Management eine Vision des zuk nftigen Systems Die eigentliche Prototypentwicklung fand in einer anderen Umgebung statt HyperCard wurde entsprechend als Werkzeug f r einen Oberfl chenprototyp und nicht als Entwicklungsumgebung f r ein Hypertext System verwendet Dabei wurden schon f r rudiment re Funktionalit t umfangreiche HyperTalk Programmteile geschrieben Der Schwerpunkt des Prototyps lag bei der Modellierung eines reaktiven Systems Dazu eignet sich HyperCard mit seiner Verkn pfung von Oberfl chenelementen und Event Handlers gut 5 1 2 Ein Fahrkartenautomat Das untersuchte Projekt Ein gro es Verkehrsunternehmen plant seit l ngerem eine neue Generation von Fahrkartenautomaten einzuf hren Es hat deshalb verschiedene auf diesem Gebiet spezialisierte Firmen in einer informellen Ausschreibung um Angebote gebeten Aufgrund der hohen ergonomischen Anforderungen war ein Oberfl chenprototyp verpflichtender Bestandteil des Angebots Ein Soft
62. e am Anfang prim r dazu verwendet zwischen verschiedenen Design Alternativen zu entscheiden An der dabei gew hlten Oberfl che wurden sp ter fast keine nderungen mehr gew nscht Erfahrungen der Entwickler Nach Einsch tzung der Entwickler ist das Projekt sehr gut gelaufen Das gew hlte Verfahren w rde von den Entwicklern wieder eingesetzt werden Die Aufgabenstellung hat sich im Verlauf des Projekts nicht ge ndert Allerdings wurden Emor Bookmark not defined Interface Builder Projekte Teile der urspr nglichen Aufgabenstellung w hrend der Anforderungsanalyse fallengelassen Kritisch wurde von den Entwicklern lediglich die zumindest in der Anfangsphase mangelhafte Kommunikation zwischen Auftraggebern und Auftragnehmern gewertet Die Hauptgr nde f r dieses Problem waren die hohe zeitliche Belastung des Auftraggeber Teams Das Werkzeug das zum Prototyping der Benutzungsoberfl che eingesetzt wurde wurde von den Entwicklern sehr positiv bewertet Vor allem die M glichkeit der direkt manipulativen Gestaltung der Definition des Verhaltens in der Benutzungsoberflache durch interpretierbare Skripten und die dadurch entstehenden sehr kurzen Entwurf Simulation Zyklen haben die Entwicklung des Systems positiv beeinflu t Unsere Einsch tzung Das hier beschriebene Projekt ist in mancher Hinsicht untypisch f r das Arbeiten mit einem UIMS im Prototyping Prozefs Zum einen wurde im Laufe dieses Projekts nur eine Benutzungsoberfla
63. e organisatorische Vereinheitlichung von Projektplanung und Emor Bookmark not defined 4 Generationsystem Projekte abwicklung erreicht was das Management bereits als internes Ziel angestrebt hatte Zudem nderte sich die Hardware Ausstattung von einer Monokultur zu einer vernetzten heterogenen Netzarchitektur von Arbeitsplatzrechnern mit grafischer Benutzungsoberfl che und Gro rechnern Der Einsatz und die Weiterentwicklung des PuV Systems wurde vertraglich zwischen den beteiligten Parteien auf mindestens f nf Jahre festgelegt Dabei verpflichtet sich der Hersteller einen Arbeitsaufwand von mindestens drei Tagen im Monat f r die Wartung bereitzustellen Die konstruierten Prototypen Prototyp I Er wurde anhand eines Pflichtenheftes entwickelt entsprach dann aber weder von der Handhabung noch von der Funktionalit t den Vorstellungen des Auftraggebers Obwohl er nicht so geplant war diente er ausschlie lich als Demonstrationsprototyp Er modellierte einen Ausschnitt des Systems Vorprojekt und besa bereits vertikale Elemente Prototyp II Er war bereits eine bessere N herung zwischen den Vorstellungen der Benutzer und dem Verst ndnis der Entwickler Da seine Auswertung aber noch zahlreiche M ngel zeigte erwies es sich aufgrund des eingesetzten Werkzeugs als einfacher diesen Prototyp wegzuwerfen statt ihn evolution r weiterzuentwickeln Prototyp III Er wurde ebenfalls komplett neuentwickelt und kann als Prototyp im enge
64. ebten Ziele betrachtet vergl Budde 92 und die Sicht die den Prototyp als Produkt in den Mittelpunkt stellt vergl Bischofberger 92 Wir charakterisieren im folgenden beide Sichten durch Gegen berstellung Grundlagen Emor Bookmark not defined e _ Exploratives Prototyping proze bezogen Es soll die Problemstellung kl ren Diskutiert werden ver nderte Arbeitsinhalte und die M glichkeiten der DV Unterst tzung Dazu werden ggf alternative Prototypen konstruiert Als Prototypart kommen meist Demonstrationsprototypen und funktionale Prototypen in Frage Exploratives Prototyping eignet sich am ehesten zur Integration in ein konventionelles Vorgehensmodell Es wird eingesetzt um die Anforderungsanalyse zu unterst tzen e Exploratives Prototyping produktbezogen Es betrachtet die Bewertung der Prototypen durch die Anwender und Benutzer Damit ist so etwas wie die Au ensicht auf den Prototyp charakterisiert Gegenstand der Betrachtung ist die Art und Weise wie die verschiedenen Prototyparten von den Anwendern fachlich bewertet werden k nnen Damit steht als Fragestellung die fachliche Ausrichtung und die Handhabbarkeit im Vordergrund Exploratives Prototyping ist nicht auf eine bestimmte Prototypart eingeschr nkt e Experimentelles Prototyping prozefsbezogen Es kl rt die technische Umsetzung der Anforderungen an ein System Dabei konkretisieren die Benutzer experimentell ihre Vorstellungen von der DV L sung und
65. edien insbesondere Videos zu realisieren Um die Texte darzustellen wurde das Textverarbeitungsprogramm FrameMaker verwendet Bilder wurden mit X View angezeigt Entwickelt wurde auf Workstations von Sun Microsystems und Silicon Graphics Der Entwic klungsproze Da in der Entwicklungsabteilung des Software Hauses keine Erfahrung mit multimedialen Anwendungen und kein Wissen ber deren Realisierung existierte wurde der Auftrag an eine entsprechende Forschungsabteilung weitergegeben Ende 1991 wurde eine Studie erstellt in der die Leistungen des zu entwickelnden Systems definiert waren Dazu wurden Szenarien ber fiktive Verkaufsgespr che erstellt in denen typische Abl ufe und Handlungen beschrieben sind Um eine bessere Vorstellung von der geplanten Benutzungsoberfl che zu erhalten wurden mit Hilfe des UIMS SX Tools einige Ausschnitte der Benutzungsoberfl che erzeugt Nachdem die Studie fertig gestellt war wurde sie an die Entwicklungsabteilung und an den Automobilhersteller weitergereicht Nachdem diese Studie vom Automobilhersteller durchgesehen wurde sind weiterf hrende Gedanken und neue Ideen wie eine Verkaufsberatung unterst tzt werden k nnte in die Entwicklung des Prototyps eingeflossen Im Mai 1992 wurde mit dem Prototyping begonnen Der Zweck des Prototyps bestand darin am Beispiel der Verkaufsberatung zu demonstrieren wie verschiedene Medien in einer Anwendung eingesetzt und kombiniert werden k nnen Um die Benu
66. ehr vage Vorstellungen hatten wie ein interaktives Arbeitsplatzsystem aussehen k nnte Dazu kam da das Entwicklermanagement von der gew hlten objektorientierten Methode und ihrer durchg ngigen technischen Realisierbarkeit berzeugt werden mu te In dieser Phase war der Demonstrationsprototyp f r die Entscheidungsfindung von gro er Bedeutung Da die weiteren Prototypen in der Zielumgebung unter OS 2 mit C realisiert wurden diente der Demonstrationsprototyp anschlie end noch als Diskussionsgegenstand und als skizzenhaftes Modell f r die weitere Entwicklung Der Demonstrationsprototyp wurde zun chst zwischen den Entwicklern und den externen Beratern in mehreren Arbeitssitzungen besprochen Im Rahmen einer Projektpr sentation wurde er dann als gemeinsames Ergebnis dem DV Management vorgestellt Die zuk nftigen Benutzer waren zu diesem Zeitpunkt noch nicht in den Bewertungsproze einbezogen Der anschlie ende erste funktionale Prototyp wurde bereits auf PCs entwickelt In Abgrenzung zum Demonstrationsprototyp standen jetzt zwei Aspekte im Vordergrund e die fachliche Komponente die technische Umsetzbarkeit HyperCard Projekte Error Bookmark not defined Dieser funktionale Prototyp war der erste in einer Reihe sich evolution r entwickelnder Prototypen auf dessen Fundament das System aufgebaut werden konnte Der erste funktionale Prototyp wurde auf einer Hausmesse pr sentiert Die positive Reaktion der Benutzer gab f r d
67. einbezogen sind Diese Einsicht st t innerhalb von Entwickler organisationen bisweilen noch auf Widerst nde Entwicklung durch Benutzer In eine ganz andere Richtung gehen demgegen ber Forderungen Oberfl chen f r Prototypen oder gar das Zielsystem von den Benutzern selbst erstellen zu lassen Zun chst sollte bei diesem Thema zwischen der Konfiguration und der parametrisierten Einstellung einer Benutzungsoberfl che und ihrem vollst ndigen Entwurf durch Benutzer unterschieden werden W hrend ersteres auf eine bew hrte Praxis zur ckgreifen kann sind der Benutzerprogrammierung enge technische und konzeptionelle Grenzen gesetzt Wir gehen davon aus da der Entwurf und die Konstruktion komplexer interaktiver Anwendungen auch noch in absehbarer Zukunft in der Zusammenarbeit von Anwendungsfachleuten und Software Technikern geschieht Enor Bookmark not defined Grundlagen Evolution re Systementwic klung Wir haben gesagt dafs Prototyping in eine Entwicklungsstrategie eingebettet ist Dabei ist es wir haben auch darauf hingewiesen durchaus denkbar dafs Prototyping als Ausweitung der Anforderungsanalyse verstanden wird Aber je intensiver sich die Funktionalit t einer Anwendung und ihre Oberflachengestaltung durchdringen desto deutlicher wird da prototypische Entwicklungszyklen den gesamten Proze bestimmen m ssen Daher sollte Oberflachen Prototyping vor dem Hintergrund der Konzepte evolution rer Systementwicklung disku
68. eine feststellen Die Differenzierungen dieser Werkzeuge setzen bei der jeweiligen Philosophie bezogen auf die fachlichen Komponenten ein d h welche fachlichen Anteile sind schon in den Oberfl chen elementen enthalten und wie werden weitere fachliche Anteile hinzugef gt Wir erwarten in der Zukunft da sich die unterschiedlichen Anwendungsbereiche expliziter auf die Zusammenstellung fachlicher Bausteine und dazu passenden komplexen Oberfl chenelementen auswirken Beispielsweise gehen einige der beschriebenen Application Frameworks in diese Richtung Enor Bookmark not defined Analyse Wir erwarten eine klarere Trennung von offenen Entwicklungsumgebungen und Anwendungssoftware Dies bedeutet zum einen da Application Frameworks angeboten werden in die verschiedene miteinander kommunzierende interaktive Komponenten eingeh ngt werden k nnen Dann k nnen Werkzeuge zum Oberfl chen Prototyping sinnvoll mit anderen Werkzeugen zur Modellierung und zur Implementierung der fachlichen Komponenten kombiniert werden Zum anderen werden Entwicklungsumgebungen nicht mehr gleichzeitig die Laufzeit umgebung des Prototypen oder des Zielsystems darstellen Diese Tendenz hat sich etwa schon beim Smalltalk System gezeigt Werkzeuge zur Oberfl chenentwicklung werden tendenziell sowohl architektonisch gut strukturierte Programmtexte in einer Hochsprache generieren als auch wieder auf solchen Programmtexten aufsetzen k nnen Damit entfallen zwei derzeit
69. eine weiteren Werkzeuge eingesetzt Der Entwic klungsproze Die gesamte Entwicklung wurde als Prototyping Projekt geplant obwohl dies von der Auftraggeberseite her urspr nglich nicht so gew nscht war Ziel der Auftraggeber war ein mit konventionellen SE Methoden erstelltes Produkt Da die Planung jedoch fast ausschlie lich vom Auftragnehmer durchgef hrt wurde waren dessen Erfahrungen bei der Entwicklung von Oberfl chen entscheidend Innerhalb der Auftragnehmer Gruppe gilt Prototyping als die Methode der Wahl daman aus anderen Projekten gelernt hatte da bei der Entwicklung von Benutzungsoberfl chen andere Verfahren nicht zum gew nschten Ziel f hren Interface Builder Projekte Enor Bookmark not defined In einer ersten Stufe wurde ein reiner Oberfl chenprototyp entworfen der den Auftraggebern zur Begutachtung vorgelegt wurde Dieser Prototyp wurde in ungef hr drei Wochen von zwei Personen entwickelt An ihm wurden Design Entscheidungen f r die Gestaltung der Benutzungsoberfl che erprobt Nachdem dieser Prototyp positiv bewertet war wurde die Schnittstelle des User Interface Management Systems zum eigentlichen Anwendungssystem dem dbx Debugger entwickelt Im Rahmen dieser T tigkeit entstanden mehrere Labormuster mit denen Kommunikationsmechanismen erprobt und auf ihre Eignung getestet wurden Gleichzeitig wurde die Benutzungsoberfl che ausgehend von dem begutachteten Oberfl chenprototyp weiterentwickelt Dabei konnte
70. eiten da ein solches Projekt vorab kalkuliert und nach erfolgreichem Vertragsabschlu durchgef hrt werden kann Dabei m ndet die Vorkalkulation in einem Angebot Bei der Projektdurchf hrung werden die Verwaltung von Projekten auf der Basis der Vorprojekte und deren Revisionen unterst tzt Gegenstand von Planung und Durchf hrung sind die Materialwirtschaft einschlie lich gew nschter Hardware und Software Vorgaben der Einsatz der verf gbaren Mitarbeiter und die Kostenkalkulation Dabei lag der Schwerpunkt des PuV Systems auf einer speziell auf die Benutzer zugeschnittenen Informationserfassung und unterschiedlichen Auskunftsm glichkeiten Das System hat geringe algorithmische Komplexit t Die Erfassung von externen Daten wie Grafiken oder Spreadsheets ist nicht notwendig Vertragsbestandteile f r die Entwicklung eines solchen PuV Systems waren der Kosten und Zeitrahmen sowie die allgemeine Aufgabenstellung f r das Entwicklungsprojekt Rechnerauswahl Werkzeugeinsatz und Vorgehensweise wurden zwischen Entwicklern und Anwendern abgestimmt wobei die Vorschl ge von den Entwicklern kamen Emor Bookmark not defined 4 Generationsystem Projekte Benutzte Werkzeuge Entwickelt werden sollte das PuV System als Informationssystem auf Basis einer relationalen Datenbank Nach der Evaluierung der auf dem Markt erh ltlichen 4G Systeme entschieden sich die Entwickler 4th Dimension auf Apple Macintosh Rechnern einzusetzen Die einzelnen Rec
71. ellt Abh ngig vom eingesetzten Werkzeug wird in der Entwicklungsumgebung zudem die fachliche Komponente einer Anwendung beschrieben Entwurfsmetapher Bildliche oder sprachliche Vorstellung die als Anleitung bei der Gestaltung eines Systems dient z B Werkzeug oder intelligenter Assistent Ereignis Event Aktion oder Aktivit t die in Softwaresystemen repr sentiert und behandelt wird Man unterscheidet zwischen Systemereignissen und anwendungsspezifischen Ereignissen Beispiele f r Systemereignisse sind das Dr cken eines Kopfes das Selektieren eines Listenelements oder die Ankunft einer Nachricht von einer anderen Anwendung Beispiele f r anwendungsspezifische Ereignisse sind das Anlegen eines Kontos oder das Verschieben eines graphischen Objektes in einem Graphikeditor Ereignisbehandlung Event Handling Ist die Art und Weise wie Komponenten eines interaktiven Systems auf Ereignisse reagieren Wird im allgemeinen durch Event Handler durchgef hrt Event Handler Ist eine software technische Komponente die Ereignisse analysiert auf sie reagiert oder deren Behandlung ausl st Event Handler werden beim Oberfl chen Proto typing h ufig in einer werkzeugspezifischen Skriptsprache implementiert Fachliche Komponente Alle Komponenten einer Anwendung die fachliche Aspekte realisieren Weitere Komponenten sind die Datenbank und die Oberfl chenkomponente HyperC ard System Werkzeug das auf dem Modell des elektronischen Kar
72. elt ist S mtliche Prototypen wurden mit 4D entwickelt Die Benutzungsoberfl che die vom Entwicklungswerkzeug generiert wurde wurde durch eine eigene Oberfl che ersetzt F r die Gestaltung der Oberfl che wurde ein Spezialist f r Software Ergonomie einbezogen W hrend des Prototyping Prozesses wurde ein Projekttagebuch gef hrt in dem alle Besprechungen zwischen den Benutzern und den Entwicklern Prototyping Sessions protokolliert sowie davon abgeleitete Entwurfsentscheidungen festgehalten sind Die kurze Systemdokumentation enth lt eine Beschreibung der Systemarchitektur das Datenmodell Programmierkonventionen sowie Erkl rungen von komplexeren Programmteilen Neben dieser Dokumentation waren vor allem auch Werkzeuge der Entwicklungsumgebung Cross Referencer und Struktureditor sehr hilfreich um eine effiziente Wartung des Systems durchzuf hren Nach einem Jahr wurde begonnen das PuV System zu optimieren Dabei konnten 4 5 der von den Benutzern und Anwendern genannten Probleme einfach behoben werden Der Rest mu te zun chst durch Messungen genauer lokalisiert werden Das System wird heute im Top Management durchweg positiv bewertet was unter anderem auch an den guten Reportm glichkeiten von 4D liegt die auch Gesch ftsgraphiken einschlie en Der Einsatz des PuV Systems innerhalb der Firma f hrte zu einer Reorganisation da das System einheitlich f r die gesamte Abteilung eingesetzt wird Auf diesem Wege wurde auch ein
73. em Entwickler ohne Einbeziehung der Benutzer erstellt Er besteht funktional aus einem Werkzeug mit dem interaktiv mechatronische Systeme modelliert werden k nnen Die Klassenbibliotheken NEDT und VICK wurden dabei verwendet und auf die speziellen Bed rfnisse f r das Projekt angepa t Der Aufwand betrug ca vier Personenmonate Der Prototyp besteht aus ca 10 15 Klassen Framework Projekte Emor Bookmark not defined Prototyp II Aus der durch den ersten Prototyp gewonnenen Spezifikation wurde von zwei Entwicklern innerhalb eines 1 2 Jahres ein zweiter Prototyp erstellt Der erste Prototyp diente dabei als Steinbruch Am Erscheinungsbild und an der Handhabung des Editors nderte sich im Bezug auf den ersten Prototypen nichts Der Aufwand betrug ca sieben Personenmonate Prototyp III Er wurde evolution r aus dem zweiten Prototyp entwickelt und deckt die von den Benutzern geforderte Funktionalit t Formulare alter Art zu erstellen und bestehende Simulationsmodelle einzulesen ab Der Prototyp besteht aus ca 50 60 Klassen Prototyp IV Nachdem der dritte Prototyp fertig gestellt war stellten die Entwickler fest da dieser so realisiert war da die fachliche Komponente und die Oberfl che sehr stark gekoppelt waren Um das System flexibler gestalten zu k nnen wurde von den Entwicklern ein technische Redesign vorgenommen was zu einer strikten Trennung der beiden Teile f hrte Dies war n tig da verschiedene Sichten auf dieselben
74. em nicht vermarktet und gewartet werden konnte Dieses sollte der externe Partner tun Der potentielle Kundenstamm f r das Produkt ist derzeit aber nur firmenintern An einer Vermarktung des Produkts au erhalb der Firma wird derzeit noch nicht gedacht Der Aufwand der bis jetzt von der externen Firma innerhalb des Projekts geleistet wurde betr gt ca vier Personenmonate Um die Oberfl che der Werkzeuge zu gestalten wurden keine Designer oder Grafiker eingesetzt Die Entwickler entwarfen sie aufgrund der Erfahrungen aus fr heren T tigkeiten Weiterhin wurde die Gestaltung der Oberfl che von anderen Systemen wie dem Macintosh beeinflu t Speziell die Oberfl che des ersten Prototyps lehnte sich stark an ein regeltechnische Simulationswerkzeug an das bereits innerhalb der Firma entwickelt wurde Derzeit sind nur Teile des Systems dokumentiert Es existiert eine Entwurfsspezifikation f r den zweiten Prototyp sowie f r Teile des dritten Prototyps F r den vierten Prototyp ist die Spezifikation in Arbeit Entwurfsdokumente und ein Benutzungshandbuch sind noch nicht vorhanden Ausf hrlich wurden nur die Auftr ge an die externe Firma beschrieben Allerdings ist sich die Entwicklungsmannschaft bewu t da eine bessere Dokumentation des Systems erforderlich ist Die konstruierten Prototypen Prototyp I Dieser Prototyp wurde in ca 1 2 j hriger Arbeit fertiggestellt und kann als horizontales Labormuster bezeichnet werden Er wurde von ein
75. emonstrationsprototypen oder reinen Oberfl chenprototypen eingesetzt Dazu eignen sie sich sehr gut Eine kontinuierliche Weiterentwicklung ber Prototypen im engeren Sinne zu Pilotsystemen und dem Anwendungssystem findet selten mit ihrer Hilfe statt Daf r sehen wir zwei Gr nde Interface Builder Projekte Enor Bookmark not defined e Interface Builder sind durch ihre Sprache oder ihre Gestaltungsm glichkeiten zu eingeschr nkt Interface Builder liefern Ergebnisse die durch ihre Software Architektur nicht in den Rahmen eines Entwicklungsprojektes passen F r gr ere und komplexe Anwendungen sind weder Programmskelette noch ein reiner Callback Mechanismus geeignet 5 2 4 Auswertung der Werkzeuggruppe Aufgrund der stark unterschiedlichen Auspr gungen von Interface Buildern ist es nahezu unm glich allgemeing ltige Aussagen f r deren Einsatz beim Oberfl chen Prototyping zu machen Insgesamt konnten wir feststellen da sowohl den Bau von Demonstrations und Akquisitions Prototypen als auch das evolution re Prototyping von Pilotsystemen durch Interface Builder gut unterst tzt werden wenn einige wichtige Voraussetzungen von den Werkzeugen erf llt werden Abh ngig von Hardware Umgebung und Betriebssystem ist das Angebot an guten Interface Buildern sehr unterschiedlich Die Bewertung der Entwickler aus der PC Welt f llt gegen ber der Bewertung der UNIX basierten Entwicklungsprojekte deutlich ab Ausschlaggebend daf r
76. en Jede werkzeugspezifische Fallstudiensammlung wird mit einer Auswertung abgeschlossen in der wir die Merkmale und Erfahrungen formuliert haben die nach unserer Meinung f r die Werkzeugart generell gelten Enor Bookmark not defined HyperCard Projekte 5 1 Projekte mit HyperCard Systemen Wir haben bereits in Kapitel 4 darauf hingewiesen da HyperCard im wesentlichen ein Entwicklungssystem f r Prototypen ist Dies l t sich schon aus den Angaben seiner Entwickler ablesen Weiterhin haben wir gesagt da HyperCard selten im eigentlichen Anwendungsbereich n mlich als Hypertext System nach der Metapher des Karteikastens eingesetzt wird Die nachfolgenden Beispiele verdeutlichen dies Wir erl utern in der ersten Fallstudie da HyperCard f r den Bau eines Demonstrationsprototyps im Rahmen der Projektinitialisierung eine wichtige Rolle spielte Im zweiten Projekt kann man nur auf den ersten Blick von einem Demonstrationsprototyp sprechen da dort der HyperCard Prototyp wesentliche Ausschnitte der gew nschten Funktionalit t der fachlichen Komponente modellierte obwohl er zun chst ausschlie lich zur Projektakquisition verwendet wurde 5 1 1 Ein Kundenberatungssystem Das untersuc hte Projekt Die Entwicklerorganisation ist ein Servicezentrum das Rechenleistung Beratung und Anwendungsentwicklung fiir einen Bankenverbund von rund 500 selbstandigen Banken entwickelt Als Systemplattform werden IBM _ Grofsrechner mit konventionell
77. en Das Einarbeiten in die finanzmathematischen Grundlagen war selbst f r einen Wirtschaftsinformatiker sehr aufwendig e Entwickeln eines ersten Prototyps mit moderner Benutzungsoberfl che mit dem schnell und einfach Portfolios verwaltet definiert und bewertet werden konnten Diese Aktivit t war ein zyklischer Proze in dem die Entwickler Vorschl ge erarbeiteten und sie dann zusammen mit den Anwendern evaluierten Um eine enge Zusammenarbeit sicherzustellen haben die Entwickler zeitweise bei den Swaps H ndlern programmiert Aufgrund der technischen Komplexit t dauerten die Implementierungs Evaluations Zyklen von wenigen Tagen bis zu einem Monat e Weiterentwickeln dieses Prototyps bis er von beiden Seiten als Spezifikation f r das Pilotsystem akzeptiert wurde Der Schwerpunkt bei der Entwicklung des Prototyps lag eindeutig auf der Benutzungsoberfl che Die Funktionalit t wurde nur soweit implementiert da die Standardf lle korrekt unterst tzt wurden Der Anschlu an die bestehenden Daten und die Sonderf lle in der Abwicklung wurden nicht ber cksichtigt Der Entwickler des ersten Prototyps verlie die Forschungsabteilung nachdem die Phase I abgeschlossen war Es dauerte deshalb ca sechs Monate bis Phase II mit einem neuen Entwickler beginnen konnte Phase II Weiterentwicklung des Prototyps zu einem Pilotsystem Emor Bookmark not defined Framework Projekte Das Ziel der zweiten Phase war aus dem Prototyp ein eins
78. en Der Nachteil ist da die eigentliche Ereignisbehandlung wesentlich m hsamer wird Weiterhin sind die Namen von fachlichen Operationen in der Oberfl chenkomponente bekannt Meist m ssen sie explizit im Programm festgelegt werden Dazu kommt da das f r komplexere Interaktionen notwendige Ged chtnis nur schwer lokalisierbar und fortzuschreiben ist Die Anbindung der fachlichen Komponente ber Callbacks ist deshalb nur schlecht f r das Prototyping geeignet 3 7 4 Versenden von Botschaften Die heute modernste Art um eine Oberfl chenkomponente mittels Ereignissen an die fachliche Komponente anzubinden besteht darin in einem objektorientierten System Botschaften an fachliche Objekte zu schicken Dies ist beispielsweise in NeXTStep realisiert Die Benutzungsoberfl che wird grafisch in Form von Oberfl chenobjekten spezifiziert und gleichzeitig werden fachliche Objekte erzeugt Dann l t sich grafisch angeben bei welchen Ereignissen welche Botschaften an diese fachlichen Objekte gesandt werden sollen Informationen ber den Zustand der Oberfl chenobjekte erhalten die fachlichen Objekte vom Sender der Botschaften auf eine entsprechende Anfrage Die Zusammenarbeit zwischen Oberfl chenobjekten und fachlichen Objekten ist jederzeit ohne vorhergehende tbersetzung testbar Die Vorteile dieses Ansatzes sind da beide Komponenten des Prototyps objekt orientiert implementiert werden k nnen und da die ereignisbasierte Kommunikation a
79. en Wir m chten uns auch an dieser Stelle nochmals f r ihre Mitwirkung bedanken Wir haben die Fallstudien zweistufig gegliedert In der ersten Gliederungsstufe haben wir sie gem den in Kapitel 4 vorgestellten Werkzeugarten zusammengefa t Dementsprechend ist in diesem Kapitel zu jeder Werkzeugart auch eine Fallstudiensammlung zu finden In der zweiten Gliederungsstufe haben wir die Fallstudien so strukturiert da die enthaltenen Informationen und Erfahrungen inhaltlich zusammengefa t sind Dadurch werden die Fallstudien vergleichbar Im einzelnen haben wir folgende wesentlichen Aspekte identifiziert nach denen wir die Fallstudien gegliedert haben e das untersuchte Projekt e die verwendeten Werkzeuge oder Entwicklungsumgebungen e der Entwicklungsproze e die konstruierten Prototypen e die Erfahrungen Bei der Darstellung des Entwicklungsprozesses haben wir versucht das Projekt zu charakterisieren die wesentlichen Aktivit ten und Phasen zu identifizieren und den Einsatz von Prototyping zu betrachten Bei der detaillierten Betrachtung der konstruierten Prototypen geben wir zuerst eine Klassifikation gem der in Kapitel 2 eingef hrten Terminologie an und beschreiben anschlie end die gefundenen Merkmale der Prototypen Am Ende jeder Fallstudie haben wir die Projekterfahrungen ausgewertet soweit diese projektspezifisch sind Die Auswertung enth lt sowohl die Meinung der Projektmitglieder als auch unsere Schlu folgerung
80. en Anforderungen gen gen mu In der ersten Fallstudie ist dies der Swift Nachrichten Editor in der folgenden ein Editor zum Gestalten von mechatronischen Systemen und in der dritten Fallstudie ist es ein Editor um Portfolios definieren verwalten und bewerten zu k nnen Prototypen die mit Hilfe eines Application Frameworks erstellt werden unterliegen meistens einem evolution ren Zyklus Dies liegt sicherlich an dem gro en Anteil an Handarbeit der bei der Erstellung eines Prototyps mit Hilfe eines Application Frameworks notwendig ist Application Frameworks k nnen aber auch verwendet werden wenn ein Demonstrationsprototyp konstruiert werden mu der neben der Oberfl che auch Teile der Funktionalit t zeigen soll Dieser kann bei Kenntnis des Frameworks mit vertretbarem Aufwand erstellt werden Der resultierende Prototyp Code ist in Emor Bookmark not defined Framework Projekte diesem Fall jedoch nicht als Basis f r einen evolution ren Entwicklungsproze geeignet quick and dirty und mu weggeworfen werden Er kann letztlich nur als Steinbruch f r weitere Prototypen dienen Herausragendes Merkmal von Application Frameworks ist die gute Wieder verwendbarkeit von Bausteinen und Architekturprinzipien Dies wird sicherlich durch die Verwendung von objektorientierten Programmiertechniken beg nstigt was die geschilderten Fallstudien best tigt haben Application Frameworks k nnen besonders effizient f r das Oberfl chen
81. en Datenbanken und Cobol f r die zentrale Datenhaltung sowie IBM und SNI Server f r dezentrale Informationssysteme verwendet Ende der 80er Jahre kamen tberlegungen auf mit PCs Anwendungssysteme am Arbeitsplatz verf gbar zu machen Auf Initiative der Banken wurde ein System zur Unterst tzung von Kundenberatern und beraterinnen entwickelt Dabei wurde als l ngerfristiges Ziel ein integriertes Sachbearbeitungssystem mit einheitlicher Oberfl che in mehreren Ausbaustufen angestrebt Mittelfristige Zielvorstellung war die umfassende Unterst tzung von Sachbearbeitert tigkeit im Investmentbereich Teilbereiche dieser T tigkeiten waren bereits von bestehenden DV Systemen abgedeckt aber ein durchg ngiges System fehlte Die Kundenberater mu ten z B Kontonummern oder Kundenadressen wiederholt eingeben und bearbeiten Komplexe kundenorientierte Vorg nge konnten nur mit wechselnden Arbeitsmitteln erledigt werden Soweit daf r bereits Anwendungssysteme eingesetzt wurden zeichneten sie sich untereinander durch deutlich verschiedene Oberfl chen aus Aufgrund dieser unbefriedigenden Situation forderten die Banken ein integriertes Sachbearbeitungssystem mit einheitlicher Oberfl che das eine durchg ngige Verwendung vorhandener Daten erm glichen sollte Das Projekt wurde Ende 1989 konventionell begonnen aber aufgrund zahlreicher konzeptioneller und technischer Schwierigkeiten im Juli 1990 unterbrochen Nach einer Analyse der Probleme entschied das
82. en explizit oder implizit eine bestimmte Vorgehensweise Enor Bookmark not defined Analyse und eigene Modellierungskonzepte fest Dies bedeutet f r viele Entwickler organisationen eine erhebliche organisatorische und strategische Umstellung Neben den hohen Kosten die dies zur Folge hat darf nicht bersehen werden da dadurch eine neue Form von Herstellerabh ngigkeit eingegangen wird Wir haben erlebt da Entwicklerorganisationen sich auf der einen Seite m hsam von der Bindung an einen Hardwarehersteller gel st haben um andererseits sich nicht minder intensiv einem Werkzeughersteller zu verpflichten Bezogen auf den Einsatz von Prototyping Werkzeugen wollen wir vor der Illusion warnen da die Ver nderung und Weiterentwicklung eines Prototyps in der Diskussion zwischen Benutzern und Entwicklern vor Ort interaktiv am Bildschirm erfolgen kann Dies mag f r einzelne Aspekte der Oberfl chengestaltung der Fall sein Aber schon bei fachlichen oder grunds tzlich konzeptionellen nderungen ist dies nicht mehr in Realzeit m glich und im Regelfall nach unserer Erfahrung auch nicht erforderlich Sehr viel wichtiger ist da die Entwickler verstehen welche nderungen erw nscht sind um diese dann in absehbarer Zeit zu realisieren Die eigentlichen Prototyping Sitzungen sollten der Diskussion und dem Ausprobieren vorbehalten sein Im brigen sind nur wenige Prototyping Werkzeuge so gebaut da sie extrem kurze nderungszyklen
83. en wir Eigenschaften von Werkzeugen mit denen Benutzungsoberfl chen gestaltet werden k nnen Diese Werkzeuge erm glichen die Oberfl chenkomponente auf einem hohen Abstraktionsniveau mit der fachlichen Komponente der Anwendung zu verbinden Bei der Auswahl der Merkmale haben wir besonders die Eignung f r das Oberfl chen Prototyping ber cksichtigt Folgende Fragestellungen die sich in den Merkmalen der Werkzeuge widerspiegeln scheinen uns in diesem Zusammenhang relevant e Welche M glichkeiten bieten Werkzeuge um beim Entwurf Oberflachenelemente anzuordnen e Welche Arten von Oberflachenelementen werden angeboten und welche Funktionalit t bieten sie Wie k nnen die vorhandenen Oberfl chenelementarten durch den Benutzer des Werkzeugs erweitert werden e Wie interagieren die Elemente einer Oberfl che e Welche Datenmodelle unterst tzt das Werkzeug an der Schnittstelle zur Anwendung e Wie k nnen erstellte Oberfl chen dynamisch ausgef hrt werden e Wie kann die fachliche Komponente der Anwendung an die Oberfl che angebunden werden e Kann ein Oberflachenprototyp f r das Zielsystem weiterverwendet werden e Welchen Anteil hat die Entwicklungsumgebung an der Laufzeitumgebung f r den Oberflachenprototyp e Kannen mit den Werkzeugen Oberfl chen gestaltet werden die vorgegebenen Richtlinien entsprechen Eigenschaften von Programmbibliotheken mit denen ebenfalls Benutzungsoberflachen konstruiert werden k nnen
84. enutzer einnehmen ist entscheidend Zun chst gilt da die Benutzer aktiv und gleichberechtigt mit einbezogen werden m ssen Negativ erweist sich wenn Benutzer nur als Informationslieferanten und als Versuchs kaninchen eingesetzt werden d h wenn sie den Eindruck erhalten da Prototyping nur dazu dient aus ihnen Fachwissen herauszuziehen ohne da sie an konzeptionellen Entscheidungen ber die Gestaltung der Prototypen beteiligt sind Diese Rolle der Benutzer als Informationslieferanten zeigt sich oft daran da sie in entscheidenden Sitzungen durch sog Benutzervertreter aus dem mittleren Manage ment ersetzt werden Von dort bis hin zu gleichberechtigten Partnern in einem integrierten Team ist gedanklich und organisatorisch ein weiter Weg Die Einbeziehung der Benutzer in den Entwicklungsproze sollte nicht nur unter dem Gesichtspunkt betrachtet werden fr hzeitig auf die Bed rfnisse der Benutzer zu reagieren Die Projekterfahrungen best rken unsere Sichtweise Prototyping als Hilfsmittel in einem Lernproze aller beteiligten Gruppen zu verstehen Dies bedeutet da Anwender und Benutzer ein Verst ndnis von dem zugrundegelegten Entwicklungsmodell und von der gew hlten Vorgehensweise haben m ssen Ohne Analyse Enor Bookmark not defined dieses Verst ndnis bleiben die Aufgaben und Einflu m glichkeiten der Beteiligten unklar und es entstehen immer wieder Mi verst ndnisse Auf Entwicklerseite mu die M glichkeit erkann
85. eption der Systeme Eine nur auf dem Ereignismechanismus gegr ndete Anwendung die zudem keine echte Kapselung oder Modularisierung kennt ist ab einer bestimmten Gr e und Komplexit t eben im wesentlichen mit der Ereignisbehandlung besch ftigt und wird f r die Entwickler zunehmend undurchschaubar Interessant an den beiden Fallstudien ist weiterhin da die verwendeten HyperCard Systeme in keinem Fall in ihrem intendierten Anwendungsbereich eingesetzt wurden Kann man die B roanwendung noch einigerma en m hevoll auf die Arbeit mit Karten und K sten reduzieren so liegt das Prototyping von Fahrkartenautomaten deutlich jenseits der urspr nglichen Entwurfsmetapher Aber dies trifft wohl f r HyperCard Anwendungen in vielen F llen zu Die bereits erw hnte St rke der HyperCard Systeme wenn Demonstrations prototypen erstellt werden sollen resultiert nicht nur aus der guten technischen Unterst tzung Das B robeispiel hat gezeigt da gerade die klare Trennung von Prototyp und Anwendungssystem f r den Prototyping Proze sehr vorteilhaft sein kann weil allen Beteiligten die Vorl ufigkeit des Prototyps deutlich ist und daher unrealistische Erwartungen an den Projektverlauf weniger wahrscheinlich sind Interface Builder Projekte Enor Bookmark not defined 5 2 Projekte mit Interface Builldem User Interface Management Systeme werden in der letzten Zeit immer h ufiger verwendet um Benutzungsoberflachen zu gestalten Aus der Vielzah
86. er sogar zu ver ndern Dieser Vorbehalt trifft sicherlich f r das rapid Prototyping mit Interface Buildern und anderen m chtigen Oberfl chenwerkzeugen zu Wir haben darauf hingewiesen da dazu die problematische Vorgehensweise von der Oberfl che nach unten kommt Als Gegenmittel dienen vor allem eine sorgf ltige Analyse der vorhandenen Arbeitsaufgaben und t tigkeiten und eine Zielfindungs diskussion die sich an den fachlichen Aspekten und nicht an der Gestaltung einer Softwareoberfl che orientiert Nach unserer Erfahrung ist nicht das Prototyping selbst die Gefahr die zu diesem technischen Tunnelblick f hrt sondern die generelle Untersch tzung des Aufwands und der Notwendigkeit einer sorgf ltigen fachlichen Analyse des Anwendungsbereichs F r den Entwurf des zuk nftigen Anwendungssystems gibt es dann ebenfalls mehr Methoden als ein rein implementationsorientiertes Prototyping Soll Szenarien und Zukunftswerkst tten bei denen in Rollenspielen und Gruppenarbeit eine zuk nftige Neuorganisation und Umstrukturierung eines Anwendungsbereichs insgesamt entwickelt wird k nnen hier nur als Stichw rter genannt werden Eine Fallstudie zeigt da Prototyping vom Entwicklerteam durchgef hrt wurde obwohl dies vom Management nicht explizit vorgesehen war Dies kann folgende Gr nde haben Der Begriff Prototyping ist im Management negativ besetzt da er als Synonym f r folgende Herangehensweise steht Wir konstruieren etwas ohne gen
87. erfl che verf gen damit alle Werkzeuge flexibel miteinander kombiniert werden k nnen Zudem war man sich in der Forschungsabteilung einig da sich die Oberfl chen der Werkzeuge nicht nur aus grundlegenden Oberfl chenelementen Kn pfe Listen etc aufbauen lassen An die verwendete Entwicklungsumgebung wurden deshalb zwei Anforderungen gestellt e Die Oberfl chen der Werkzeuge sollten schnell und einfach gestaltet werden k nnen Framework Projekte Emor Bookmark not defined e Die Entwicklungsumgebung sollte um grafische Oberfl chenelemente erweitert werden k nnen die selbst erstellt werden mu ten Der Einsatz von Smalltalk 80 auf UNIX Workstations wird wie folgt begr ndet e Das System sollte objektorientiert entwickelt werden e Smalltalk 80 ist auf verschiedenen Hardware und Betriebssystemplattformen vorhanden Smalltalk 80 bietet mit dem MVC Application Framework eine gute Architektur f r die Oberfl chenkomponenten e Smalltalk 80 besitzt bereits eine sehr umfangreiche Klassenbibliothek Zudem k nnen f r viele Anwendungsbereiche Klassenbibliotheken erworben werden e Der Quell Code f r s mtliche Klassen ist vorhanden und kann gegebenenfalls angepafst werden e Die Entwickler hatten bereits Erfahrung mit Smalltalk 80 Da Smalltalk 80 die Teamarbeit nicht unterst tzt wurde das Werkzeug Application Organizer und eine darauf aufbauende eigene Versionenverwaltung eingesetzt Dazu wurde der UNIX make Mec
88. erten Systemen oft dazu da die fachliche Komponente software technisch explizit als reine Datenobjekte abgebildet wird wobei dann gro e Teile der fachlichen Dynamik implizit in der Oberfl chen komponente realisiert werden Architekturen dieser Art sind schwer verst ndlich und kaum weiterentwickelbar Ein zus tzliches Problem stellt die analysierte Form Inhalt Problematik dar So verlockend es f r Entwickler sein mag zun chst ein Oberfl chen Layout mit den Benutzern abzustimmen und dieses dann schrittweise mit fachlicher Funktionalit t anzureichern so wenig tragf hig ist diese Vorgehens weise wenn die fachlichen Inhalte der zuk nftigen Anwendung den Beteiligten prinzipiell noch nicht klar sind Wir sehen allerdings da es am Markt viele Werkzeuge gibt die dieses Vorgehen nahelegen Eine der wenigen positiven Ausnahmen stellen eng gekoppelte 4G Systeme wie 4th Dimension dar Bei diesen 4G Systemen mufs zun chst graphisch ein Datenmodell entworfen werden ehe dazu passende Oberfl chenkomponenten erzeugt werden k nnen Dies soll allerdings nicht den Umkehrschlu nahelegen da gute Anwendungen dadurch entstehen zuerst ein vollst ndiges fachliches Modell zu entwerfen und dann davon eine Oberfl che abzuleiten Gute Oberfl chen zeichnen sich unseres Erachtens nach nicht dadurch aus dem Benutzer ein 1 1 Abbildung des fachlichen Modells zu pr sentieren sondern ihm die Informationen eines solchen Modells geeignet darzustel
89. eteiligten Personen m ssen die notwendige Zeit zum Lernen und f r die Kooperation erhalten Da jenseits dieser Probleme Benutzerbeteilung heute immer noch nicht selbstverst ndlich ist ist f r uns ein Zeichen mangelnden Problembewufstseins Es fehlt das Verst ndnis f r die wesentlichen Probleme die Dynamik von Software Projekten und auch f r eine unabdingbare gemeinsame Kommunikationsbasis zwischen den beteiligten Gruppen Ist dieses Problembewufstsein vorhanden so ist die Hemmschwelle f r eine Benutzerbeteiligung deutlich niedriger Dies ist nicht nur ein Problem der Entwicklerorganisation Wir stellen fest da viele Anwender organisationen die Meinung bernommen haben da die Entwickler wohl schon wissen was die Benutzer wirklich brauchen und deshalb auch zugeschnittene Anwendungssysteme in Auftrag geben in der Hoffnung vom eigentlichen Entwicklungsproze m glichst wenig betroffen zu sein 6 1 4 Akzeptanz In der Praxis treffen wir immer wieder auf Vertreter des DV Management die Benutzerbeteiligung und Prototyping f r eine Modewelle halten Zu dieser Haltung haben sicherlich die berzogenen Versprechungen beigetragen die etwa im Zusammenhang mit Expertensystemen und CASE Tools aber auch mit Objekt orientierung gemacht wurden Wir haben gelegentlich die Meinung geh rt Diese Welle sitzen wir auch noch aus Hier wird bersehen da der Weg zu Prototyping als Teil der evolution ren Systementwicklung von mehr
90. evaluieren denn reine Handhabung ohne eine inhaltlich fachliche Basis kann nicht sinnvoll bewertet werden 6 2 3 Architektur und Designmuster Die zunehmend wichtiger werdende Diskussion um moderne Softwarearchitekturen hat auch Auswirkungen auf das Prototyping Da ist zun chst der starke Einflu den die Objektorientierung auf die Konstruktion interaktiver Software genommen hat Wir haben darauf hingewiesen da praktisch alle graphischen Fenstersysteme nach objektorientierten Gestaltungsprinzipien entworfen worden sind auch wenn sie dann letztendlich konventionell modulorientiert implementiert wurden Dazu kommt da zur Bew ltigung der Komplexit t umfangreicher interaktiver Anwendungen kein anderes Entwicklungsparadigma geeignet erscheint Deshalb wird heute verst rkt die Frage an Werkzeuge zum Oberfl chen Prototyping ge richtet in welchem Umfang sie in ein solches objektorientiertes Entwicklungsumfeld passen Bis auf die Application Frameworks oder einige wenige Interface Builder wie VisualWorks kann aber aus unserer Sicht noch keine wirklich positive Antwort gegeben werden Damit stellt sich f r uns die Frage welche von den in einem Projekt entwickelten Prototypen berhaupt die Architektur und die software technischen Grund prinzipien des zuk nftigen Anwendungssystems modellieren m ssen Wenn diese tbereinstimmung gew nscht wird dann haben wir bei einigen Werkzeugen f r das Oberfl chen Prototyping Probleme identifiziert
91. gestellt e Bei der iterativen Weiterentwicklung h tten h ufiger Entwurfsphasen eingeschoben werden sollen Design nderungen mu ten deshalb w hrend der Implementierungsphase durchgef hrt werden Die objektorientierte Konstruktion erleichterte jedoch dieses Die Oberflache von SNE wurde nach der MVC Architektur realisiert die Smalltalk VPM in seiner Klassenbibliothek unterst tzt Da diese den Entwicklern zu Beginn unbekannt war ergaben sich Probleme die im Entwurf definierten Klassen f r die Interaktion in das System zu integrieren Es f hrte letzlich dazu da Teile des Entwurfs der Oberfl che nichtig wurden Die bei der Analyse definierten Begriffe und Begriffshierachien im Bereich der zentralen Datenstrukturen des Werkzeugs konnten jedoch direkt in Klassenhierachien umgesetzt werden e Smalltalk VPM ist als Werkzeug f r diese Art von Anwendungen geeignet da die Klassenbibliothek im Bereich der Benutzungsoberfl chen die Konstruktion der Oberfl che wesentlich erleichtert hat e Smalltalk VPM ist nicht f r die Teamarbeit geeignet da es keine Versionen und Konfigurationsunterst tzung gibt e Die mitgelieferte Dokumentation zu Smalltalk VPM ist unzureichend Es bedarf eines erheblichen Aufwands um die Klassenbibliothek und die darin implementierten Architekturkonzepte zu verstehen Unsere Einsch tzung Dieses Projekt zeigt die Merkmale eines typischen Prototyping Projekts bei dem gleichzeitig neue Methoden
92. gnen sich meist sowohl f r exploratives als auch f r evolution res Prototyping Hier ist von Vorteil da eine formularartige Darstellung an der Oberfl che sehr einfach auf das Datenmodell abgebildet werden kann und umgekehrt Der haupts chliche Unterschied zwischen den beiden Werkzeugarten ist da bei Werkzeugen f r ein quasi relationales Modell die Kopplung zwischen Datenhaltung und Benutzungsoberfl che wesentlich enger ist als bei Werkzeugen f r das rein relationale Modell Quasi relationale Werkzeuge k nnen blicherweise aus graphischen Entw rfen ein Datenmodell ableiten und daraus standardisierte Formulare f r die Darstellung und Bearbeitung der Daten generieren Werkzeuge die ein rein relationales Modell unterst tzen kommunizieren meist ber SOL mit einer Datenbank Aufgrund k rzerer Entwicklungszeiten sind Werkzeuge f r ein quasi relationales Modell besser geeignet um explorativ vorzugehen Werkzeuge die nur Dateien mit Daten einheitlicher Struktur unterst tzen sind aufgrund ihrer eingeschr nkten Funktionalit t kaum f r allgemeine Prototyping Zwecke einsetzbar F r einfache Anwendungen werden zugeschnitte Werkzeuge angeboten Enor Bookmark not defined Werkzeugeigenschaften e Hypertext Systeme auf der Basis von Stapeln einheitlich strukturierter Karten bieten eine grofe Flexibilit t bei der Datenmodellierung da die einzelnen Karten auch ber Stapelgrenzen hinaus durch Hypertext Referenzen miteinander
93. h einen Handel abschlie t Aufgrund dieser offensichtlichen M ngel wurden zwei Projekte gestartet Das Ziel des ersten Projektes war innerhalb relativ kurzer Zeit WASP ein finanzmathematisch vollst ndiges Nachfolgeprodukt des existierenden Systems zu entwickeln Das Ziel des zweiten Projektes war mittelfristig den SWAPSMANAGER ein finanzmathematisch vollst ndiges Produkt das auch w hrend des telefonischen Handels eingesetzt werden kann zu entwickeln In dieser Fallstudie gehen wir nur noch auf die Entwicklung des SWAPSMANAGERSs ein An diesem Projekt waren die Swaps Abteilung und die DV Forschungsabteilung der Bank beteiligt Es kam aufgrund informeller Kontakte zustande Dabei wurden zwei Ziele verfolgt e Die Swaps H ndler erwarten als Resultat einen ergonomisch und funktional wesentlich verbesserten Arbeitsplatz der es ihnen erlaubt w hrend des telefonischen Handels Swaps und Portfolios von Swaps zu definieren und unter verschiedenen Annahmen zu bewerten Die Forschungsabteilung will mit dem Projekt zeigen da die intern entwickelte Technologie einen gewissen Reifegrad erreicht hat Vor Beginn des Projekts mu ten keine Vertr ge abgeschlossen werden da die Forschungsabteilung die Entwicklungskosten tr gt Es wurden einzig zwei Sollbruchstellen definiert nach denen jede der beteiligten Parteien die Zusammenarbeit einstellen konnte Sollbruchstelle eins war die Fertigstellung des ersten Prototyps Mit ihm sollte be
94. hanismus und eigene entwickelte Werkzeuge verwendet Der Entwic klungsproze Mit der Implementierung des ersten Prototyps wurde im Dezember 1990 begonnen Weder die Auftraggeber noch die Benutzer haben diesen Prototyp evaluiert Aus ihm wurde eine textuelle Spezifikation des zuk nftigen Systems erstellt die dem Auftraggeber vorgelegt wurde Die Entwickler sammelten bei der Konstruktion des Prototyps Vorstellungen und Ideen wie eine optimale Werkzeugunterst tzung f r das angestrebte System aussehen k nnte Zudem erwarb man Erfahrungen wie das System mit Smalltalk 80 software technisch realisiert werden konnte Aufbauend auf diesem Prototyp wurde ein weiterer Prototyp mit dem Ziel entwickelt ihn dem Auftraggeber und den Benutzers zur Evaluation zu pr sentieren Begonnen wurde mit ihm Mitte des Jahres 1991 Die Pr sentation erfolgte auf einer firmeninternen Vorf hrung im Fr hjahr 1992 Die Demonstration f hrte zu sehr unterschiedlichen Meinungen bei den Benutzern von sehr gut bis was soll das Dies war auf den bis dahin geringen Einsatz der Informationstechnik in den Arbeitsbereichen der Qualit tssicherung zur ckzuf hren Die durch die Pr sentation entstandene Diskussion ergab die Anforderung das System besser in die im Unternehmen bestehende Vorgehensweise einzubetten Dies bedeutet da die Ergebnisse der Fehler und Signalflu analyse eines Systems in der f r das Unternehmen bestehenden Formularform ausgedruckt werden s
95. hner sind in ein LAN eingebunden Eine externe Datenbank ist bis jetzt noch nicht im Einsatz Der Entwic klungsproze Die Anzahl der am Entwicklungsproze beteiligten Personen wurde von vornherein bewu t klein gehalten um die Arbeitsf higkeit der Gruppe nicht einzuschr nken Neben drei Benutzern war auf Seite der Anwender ein Projektleiter und gelegentlich ein Vertreter des obersten Managements beteiligt Das Entwicklerteam bestand im wesentlichen aus zwei Personen Zun chst wurde vom Auftraggeber ein ca 40 seitiges Pflichtenheft mit einem durchformulierten Beispiel erstellt Dieses schien auch den Entwicklern ausreichend zu sein um das Projekt zu beginnen Anhand dieses Pflichtenheftes wurde in drei Wochen ein erster Prototyp konstruiert und dem Auftraggeber vorgestellt Dabei stellten die beteiligten Personengruppen fest da das Pflichtenheft falsch interpretiert bzw nicht detailliert genug geschrieben war Der Prototyp war bez glich der Funktionalit t noch ungen gend und auch in der Gestaltung der Oberfl che gab es noch gro e Abweichungen Daher diente er nur als Demonstrationsprototyp f r die generelle Entwicklungsrichtung Auch der zweite funktionale Prototyp wurde komplett von seinem Nachfolger abgel st Erst der dritte Prototyp bildete die Grundlage f r den weiteren evolution ren Proze der zun chst ein halbes Jahr dauerte Parallel zu den Prototypen wurde das Datenmodell entworfen das ebenfalls evolution r weiterentw
96. hnischen Weiterentwicklung m ssen diese Werkzeuge aber nicht mehr unbedingt den aller neuesten Stand der Technik repr sentieren Dies schm lert aber ihren Wert in keiner Hinsicht um die relevanten Konzepte zu verdeutlichen da auf der Ebene der Werkzeugarten keine grunds tzlichen Weiterentwicklungen stattgefunden haben Kapitel 5 enth lt eine umfangreiche Sammlung von industriellen Fallstudien die nach der im Kapitel 4 eingef hrten Werkzeugklassifikation strukturiert ist In den vorgestellten Projekten wurden verschiedene Auspr gungen der Werkzeugarten eingesetzt um Oberflachen Prototypen zu konstruieren Wir berichten welche Werkzeuge wie eingesetzt wurden welche Ergebnisse erzielt wurden und welche Erfahrungen die Entwickler dabei gemacht haben Im Kapitel 6 formulieren wir auf der Basis der vorgestellten Fallstudien unsere Analysen und bewerten den Einsatz von Werkzeugen beim Oberfl chen Prototyping Weiterhin beschreiben wir Trends auf diesem Gebiet die sich unserer Meinung nach abzeichnen Dieser Bericht dokumentiert die Ergebnisse der Arbeit des GI AK 4 3 2 Prototyping Dieser Arbeitskreis hat in den letzten vier Jahren den Einsatz und die Akzeptanz von Prototyping in der industriellen Software Entwicklung untersucht Enor Bookmark not defined Einleitung Die vorliegende Studie die speziell das Oberf chen Prototyping betrachtet ist die zweite dieser Art Die erste Studie die allgemeine Prototyping Projekte vorstellt un
97. hrt werden kann Wichtig ist in diesem Zusammenhang ob die grafisch erstellte Benutzungsoberfl che sp ter mit demselben Prototyping Werkzeug erweitert und angepa t werden kann oder ob dann handgeschriebene Anpassungen vorgenommen werden m ssen 3 9 Konformitat zu Gestaltungsrichhtlinien Je nach Ausrichtung erzwingen Werkzeuge zum Oberfl chen Prototyping da Oberfl chen entsprechend vorgegebener Gestaltungsrichtlinien entworfen werden m ssen Diese Gestaltungsrichtlinien k nnen sich auf das allgemeine Look amp Feel eines Oberfl chensystems wie Windows oder Motif beziehen sie k nnen aber auch dar ber hinaus Richtlinien f r die Handhabung in bestimmten Anwendungssituationen enthalten Man spricht im letzten Fall von Style Guides Es ist erstrebenswert die jeweils gew nschte Form von Konformit t zu erzwingen wenn das Prototyping Werkzeug dieselbe Art von Benutzungsoberfl che unterst tzt wie das Zielsystem Sollen im Prototyp neue Formen von Benutzungsoberfl chen erprobt werden oder soll der Prototyp f r eine andere Art von Oberfl che gebaut werden so ben tigt man ein flexibles Werkzeug das nicht auf bestimmte Gestaltungsrichtlinien festgelegt ist Fallstudien Enor Bookmark not defined Kapitel 5 Fallstudien Einen zentralen Teil dieses Berichtes bilden die nachfolgend aufgef hrten Fallstudien Diese Fallstudien sind das Ergebnis von Interviews die wir mit den entsprechenden Projektmitarbeitern f hren durft
98. hrte bei den Entwicklern zu einer hohen Sensibilit t f r die fachlich Problematik Die Entwicklung der Prototypen hat wesentlich dazu beigetragen Ein Hauptproblem des Projekts war die Teambildung bei den Entwicklern siehe Phase II Dies lag an der Neuigkeit des Vorgehens und der eingesetzten Werkzeuge sowie an der Spannung zwischen Forschungsauftrag und dem Ziel ein einsetzbares Produkt zu erstellen Man ben tigte daher viel Zeit f r die Diskussion der Methodik des Entwicklungsstils sowie die Verteilung von sinnvollen Arbeitsgebieten f r die einzelnen Entwickler F r den Ablauf des Projekts war es sehr wichtig in dieser Phase gen gend Zeit zu haben Nach den prinzipiell positiven Erfahrungen mit Windows 4GL w rden die Entwickler bei einem erneuten Projektstart das Pilotsystem versuchsweise mit dem DB Kit von NeXT entwickeln Sie versprechen sich davon eine h here Entwicklungsgeschwindigkeit durch die enge Kopplung an die Datenbank und gr ere Flexibilit t durch die bereits vorhandenen Werkzeuge zur Biiroautomatisierung So sind dort z B Werkzeuge wie Textverarbeitung Tabellenkalkulation Terminplaner verf gbar und ber Schnittstellen in die Anwendung einzubinden Eine Entscheidung zwischen Windows 4GL und NeXT kann aus heutiger Sicht nicht gef llt werden Unsere Einsch tzung Das Projekt nimmt mit seiner langen Laufzeit vier Jahre eine Sonderstellung ein Dadurch bedingt konnten vier Werkzeuge eingesetzt werden um die Pro
99. ickelt wurde In dieser Zeit wurde etwa im zweiw chigen Rhythmus eine neue Version des Prototyps erstellt und mit Anwendern und Benutzern diskutiert Nach einem halben Jahr wurde ein Pilotsystem bei drei Benutzern installiert Dieses umfa te allerdings nur Vorprojekt und Mitarbeiterverwaltung Ein Pilotsystem das die gesamte Funktionalit t abdeckte wurde nach einem weiteren halben Jahr fertiggestellt und beim Kunden installiert F r den weiteren Ausbau ist geplant eine Laptopversion zu erstellen in der nur die Daten einzelner f r den jeweiligen Bearbeiter interessanten Vorprojekte bernommen werden Zwischen den beteiligten Personengruppen wurde vereinbart nach einer Laufzeit von ca einem Jahr ein technisches und fachliches Redesign einzuplanen Dadurch sollte sowohl die Akzeptanz des Systems beim Anwender als auch die software technische Architektur des Systems verbessert werden Die verschiedenen Prototypen wurden bzgl Entwurf und Konstruktion in folgendem Proze bewertet Zun chst fand ein internes Review im Entwicklerteam statt Danach wurden die Prototypen von einem Team das sich aus den Entwicklern drei Benutzern und einem Vertreter des mittleren Anwendermanagements Projektleiter zusammensetzte evaluiert Im Rhythmus von zwei Monaten wurde 4G System Projekte Enor Bookmark not defined das Projekt mit dem Top Management des Auftraggebers abgestimmt Anfangs gab es Reibungsverluste zwischen Entwicklern und den anderen be
100. ie Entwicklergruppe und das Management den Ausschlag einen funktional weiter ausgebauten Prototyp zu entwickeln wobei die Benutzer explizit in den Proze integriert sein sollten Entsprechend wurde mit den Anwendern Kundenberatern und DV Organisatoren von Banken die sich bei der Messe besonders interessiert gezeigt hatten ein Arbeitskreis gegr ndet der die Grundlage der weiteren Zusammenarbeit zwischen Entwicklerteam und Anwendern im Prototyping Proze war In diesem Arbeitskreis wurde nicht nur mit den verschiedenen Prototypen und den damit zusammenh ngenden Entwicklungsdokumenten gearbeitet sondern das Prototyping Verfahren selbst die objektorientierte Methode und die Vorgehensweise des Projektes vorgestellt und diskutiert Zum Berichtszeitpunkt wird das Beratungssystem nach einer Pilotphase an die ersten Banken ausgeliefert Nachfolgeprojekte im beschriebenen Gesamtrahmen im Schalter Kredit und im Wertpapierbereich laufen Die konstruierten Prototypen Der HyperCard Demonstrationsprototyp wurde wie gesagt auf einem Macintosh nach einer l ngeren Diskussion mit den Entwicklern in ca einer Woche entwickelt und wurde anschlie end noch zweimal berarbeitet Dieser Prototyp zeigte kaum fachliche Komponenten sondern eher allgemeine Arbeitsformen und Gegenst nde der B roarbeit Neben den in HyperCard unmittelbar zu konstruierenden Formularen waren Ordner als Stapel von Formularen realisiert Dazu kamen Werkzeuge wie ein Modellrech
101. ieren Werkzeugeigenschaften Enor Bookmark not defined 3 5 Datenmodellunterstutzung Gute Werkzeuge zum Prototyping gibt es besonders in klar abgrenzbaren Anwendungsgebieten Dort lassen sich Benutzungsoberfl chen aus einem vorde finierten Satz von Oberfl chenelementarten aufbauen In solchen Anwendungsgebieten kann das gew nschte Anwendungsverhalten auf einem hohen Abstraktionsniveau definiert und sofort mit einem Prototyp experimentiert werden Ein typischer Fall f r ein gut abgrenzbares Anwendungsgebiet das ber Benutzungsoberfl chen hinausgeht sind Informationssysteme die auf Datenbanken basieren Dort kommt es im wesentlichen auf das Eingeben Verwalten und Sichten von strukturierten Informationsmengen an Werkzeuge die dieses Anwendungsfeld abdecken k nnen aufgrund des unterst tzten Datenmodells klassifiziert werden Die derzeit kommerziell erh ltlichen Werkzeuge unterst tzen eines der folgenden vier Datenmodelle das relationale Datenmodell e das quasi relationale Datenmodell e eine Datei mit Daten einheitlicher Struktur Records Stapel von einheitlich strukturierten Karten in Hypertext Systemen Mittlerweile gibt es erste Werkzeuge die das objektorientierte Datenmodell unter st tzen Normalerweise wirkt sich das unterst tzte Datenmodell wie folgt auf die Eignung eines Werkzeugs f r das Prototyping aus Werkzeuge die ein relationales bzw ein quasi relationales Datenmodell unter st tzen ei
102. ifische Version des dbx eine grafische Benutzungsoberfl che realisiert werden wobei gewisse Designvorschriften Motif Umgebung Company Style Guide etc eingehalten werden mu ten Eine weitere Randbedingung bei der Entwicklung war da die Oberfl che mit Standard dbx kompatibel sein mu te Das Standard dbx Programm sollte nicht modifiziert sondern nur mit einem Front End versehen werden Dazu mu ten die dbx Meldungen erkannt und interpretiert werden die teilweise mehrdeutig sind Es wurde keine eigene Schnittstelle zwischen der fachlichen Komponente und der grafischen Oberfl che entworfen Zus tzlich wurde verlangt da die Oberfl che auch f r Debugger anderer Programmiersprachen und auf anderen Host Rechnern einsetzbar sein sollte Eine genauere Analyse der aus dieser Forderung resultierenden Entwicklungsprobleme f hrte dazu da der Auftraggeber nach ca drei Monaten diese Forderung fallen lie Emor Bookmark not defined Interface Builder Projekte Als der Auftrag erteilt wurde gab es bereits mehrere hnliche Produkte f r UNIX Umgebungen die als Vorbilder f r die gew nschte Oberfl che verwendet werden konnten Allerdings mufste das System v llig neu realisiert werden da alle Konkurrenzprodukte aus rechtlichen Gr nden nicht verwendet werden durften und auch nicht den Erwartungen der Auftraggeber entsprachen Auf der Seite der Auftragnehmer waren zwei Entwickler beteiligt Die Auftraggeberseite bestand aus mehrere
103. ilder Projekte Enor Bookmark not defined e Die Arbeit am Prototyp hat gezeigt da es sehr aufwendig ist externe Ger te zur Wiedergabe und Speicherung von Videos Audio Sequenzen und Bilder anzusteuern und zu integrieren da aufgrund fehlendes Standards jeweils Einzell sungen realisiert werden m ssen e Im Nachhinein wurde erkannt da es g nstiger gewesen w re schon fr hzeitig Spezialisten zur Gestaltung der Benutzungsoberfl che einzube ziehen um den Aufwand f r nderungen zu senken bzw zu vermeiden Unsere Einsch tzung Mit der Entwicklung des Prototyps wurden zwei wesentliche Ziele verfolgt Zum einen diente der Prototyp zur Demonstration vor dem Auftraggeber zum anderen als Labormuster f r die Entwickler um technische L sungen zu untersuchen und Erfahrungen bei der Entwicklung von Multimedia Anwendungen zu sammeln Im Verlaufe des Projektes zeigte sich da es schwierig ist Aufbau und Funktionsweise einer Oberfl chenkomponente f r alle verst ndlich zu beschreiben Bemerkenswert an dem Projekt ist da der Auftraggeber in den Entwicklungsprozefs mit einbezogen wurde Unzul nglichkeiten und Schwachstellen am System wurden auf diese Weise schon zu einem sehr fr hen Zeitpunkt erkannt wodurch der Aufwand f r sp tere nderungen reduziert werden konnte Die Erfahrungen der Entwickler belegen jedoch dafs es nicht ausreichte nur ber funktionale und technische Gesichtspunkte mit dem Auftraggeber und sp terem
104. im r nur die Oberfl che ohne Funktionalit t aber mit einigen Navigationsm glichkeiten Aus diesen Varianten wurde eine Art Fotoroman gestaltet Dieser wurde 20 zuf llig ausgew hlten Personen zur Bewertung vorgelegt Die Befragung f hrte zu der Erkenntnis da die Testpersonen nicht in der Lage waren aufgrund von Fotos die Qualit t eines Prototyps zu beurteilen Phase II Implementierung lauff higer Prototypen und Feldtest Da die Entwickler aufgrund dieser Bewertung nicht sicher waren welche Art von Handhabung und Verhalten des Systems f r den zuk nftigen durchschnittlichen Benutzer eines Fahrkartenautomats am besten geeignet war wurden zwei alternative Prototypen konstruiert Der eine realisierte nicht modale Handhabungsformen w hrend der zweite eine starre Benutzerf hrung vorsah Diese Prototypen wurden dann in einem Feldversuch von mehr als 250 Personen benutzt Dieses wurde HyperCard Projekte Enor Bookmark not defined gefilmt Parallel dazu wurden ausf hrliche Protokolldateien generiert und Frageb gen ausgef llt Der Feldversuch erbrachte da der freie Dialog zu kompliziert war Dies hatten die Entwickler erwartet da die Testpersonen keine Erfahrung im Umgang mit dem Prototyp hatten Der gef hrte Dialog wurde als gut verst ndlich aber recht kompliziert bewertet Aus finanziellen Gr nden war ein weiterer Feldversuch nicht m glich Ebenso wenig konnten die Resultate des Feldversuchs in einen revidierten Prototyp u
105. in ihrer Zielsetzung prim r anwendungsorientiert d h die Qualit t des zu entwickelnden Softwareprodukts wird vorrangig an der Benutzbarkeit im An wendungsbereich ausgerichtet Aber Prototyping bedeutet heute nicht nur Anwen dungsorientierung sondern auch Benutzerbeteiligung Gerade beim Oberfl chen Prototyping ist diese Ausrichtung f r den Projekterfolg entscheidend Eine Konsequenz der Anwendungsorientierung ist da sich die Entwickler selbst intensiv mit den Aufgaben und T tigkeiten im Anwendungsbereich besch ftigen und die dahinstehenden Konzepte verstehen m ssen Benutzerbeteiligung bedeutet da diejenigen einbezogen werden m ssen die sp ter zumindest potentiell das Softwaresystem benutzen denn nur sie k nnen letztlich die Qualit t der Oberfl che und die fachliche Stimmigkeit beurteilen Die Integration der Benutzer sollte daher nicht nur zur Gestaltung und Bewertung eines Oberfl chen prototyps erfolgen Um gutes Prototyping zu betreiben ist es wichtig die Benutzer so fr h wie m glich aber dann auch f r den gesamten Projektverlauf zu beteiligen Dies hat wie oben angedeutet Auswirkungen auf die gesamte Durchf hrung eines Projekts Neben der Diskussion ber Prototypen m ssen generell neue Wege und Mittel eingesetzt werden um ein Projekt f r alle beteiligten Gruppen verst ndlich durchzuf hren Kontinuierliche Benutzerbeteiligung f hrt nicht als solche schon zum Erfolg Die Position oder Rolle die die B
106. ist nach unserer Meinung da im Workstation Bereich auf der Basis von UNIX wesentlich mehr Werkzeugentwicklungen mit entsprechend gr erem Aufwand gemacht wurden Die entstandenen Werkzeuge sind m chtiger und besser f r gr ere Software Entwicklungen geeignet als Werkzeuge auf PC Basis Eine an der Benutzungsoberfl che verwendbare interpretierbare Sprache mit der das Oberfl chenverhalten definiert werden kann ist eine unabdingbare Notwendigkeit wenn Prototypen jeglicher Art erstellt werden sollen selbst f r reine Akquisitions und Demonstrationsprototypen Ohne eine solche M glichkeit wird Prototyping durch die dann notwendigen l ngeren tbersetzungs und Bindevorg nge sehr m hsam wenn nicht unm glich Systeme die die M glichkeit anbieten rasch vom Entwurf zur Simulation einer Oberfl che zu wechseln erlauben da Prototypen in einem sehr kurzen Design und Evaluations Zyklus erstellt werden k nnen Interface Builder die prinzipiell nur Source Code erzeugen der sp ter mit der fachlichen Komponente zusammen bersetzt und gebunden werden mu sind f r das Prototyping von Benutzungsoberfl chen nur sehr eingeschr nkt geeignet Man ben tigt zus tzlich zu dieser Eigenschaft die M glichkeit die Interaktion mit den Oberfl chen zu simulieren und zu evaluieren Wie Abschnitt 5 2 3 gezeigt hat sind Systeme bei denen Programmskelette entstehen in die anschlie end manuell Anwendungsfunktionalit t integriert werden mu
107. iten konstruiert werden Der Nachteil ist da es teilweise aufwendig sein kann die Zeichenketten aufzubauen und zu interpretieren Der Anschlu der fachlichen Komponente an die Ober fl chenkomponente ber ein zeichenkettenbasiertes Protokoll ist somit keine wirklich brauchbare Technik f r das Prototyping Mit Blick auf das Zielsystem kommt dazu da es keinerlei Typsicherheit beim Austausch der Zeichenketten gibt Damit m ssen alle Daten zwischen Oberfl che und fachlicher Komponente als Zeichenfolgen ausgetauscht Enor Bookmark not defined Werkzeugeigenschaften werden so dafs das Protokoll zwischen den beiden Komponenten oft unangemessen primitiv und gegen Ver nderungen und Fehlinterpretationen sehr anf llig ist 3 7 3 Callbacks In der Oberfl chenkomponente oder in der fachlichen Komponente werden sogenannte Callback Routinen definiert die aufgerufen werden wenn bestimmte Ereignisse auftreten Informationen ber Daten und Zust nde der Oberfl chenkomponente k nnen von der fachlichen Komponente ber eine prozedurale Schnittstelle abgerufen werden Im Vergleich zur Ereignisbehandlung mit einer Skriptsprache hat die Anbindung der fachlichen Komponente ber Callbacks den Vorteil da die Programmtexte zur Ereignisbehandlung meist in einer software technisch vern nftigen Sprache geschrieben werden k nnen Dazu kommt da sich Oberfl chenkomponente und fachliche Komponente auch als software technische Komponenten kapseln lass
108. jekt Um die Beratung beim Verkauf von Fahrzeugen zu verbessern erteilte ein Automobilhersteller einem Software Haus den Auftrag ein interaktives System zu entwickeln das Kunden zu einem gew nschten Fahrzeug Texte Bilder Videobilder Interface Builder Projekte Enor Bookmark not defined Sprache und drei dimensionale Graphik pr sentiert Das System sollte Prospekte und technische Beschreibungen die blicherweise w hrend einer Beratung verwendet werden erg nzen Der Verk ufer sollte das System interaktiv bedienen k nnen Zus tzlich sollte auf Wunsch des Kunden eine standardisierte Demonstration zu einem Fahrzeug abrufbar sein Weiterhin sollte es m glich sein die Kundenw nsche zu erfassen z B Sonderausstattungen und direkt in die Vertragsgestaltung mit aufzunehmen Es war von Anfang an geplant kein Produkt zu entwickeln sondern lediglich einen Prototyp zu erstellen Dieser Prototyp sollte demonstrieren inwieweit ein Multimediasystem geeignet ist um bei der Verkaufsberatung sinnvoll eingesetzt zu werden Der Auftraggeber finanzierte nur die Entwicklung des Prototyps Benutzte Werkzeuge F r die Entwicklung der Benutzungsoberflache wurde das UNIX Werkzeug SX Tools verwendet Es wurde gew hlt weil es leicht verf gbar war und weil es aufgrund seiner m chtigen Skriptsprache geeignet schien sowohl die Benutzungsoberfl che zu erzeugen als auch die notwendigen Anbindungen der Ausgabeschnittstellen f r die verschiedenen M
109. kennenzulernen Dieser sollte deshalb innerhalb in einer kurzen Entwicklungszeit erstellt werden k nnen da er sp ter als Steinbruch verwendet wird Dieses Projekt zeigt dieselben zentralen Probleme beim Einsatz von Smalltalk die schon im ersten beschriebenen Smalltalk Projekt von den Entwicklern ge u ert Enor Bookmark not defined Framework Projekte wurden Mangelnde Dokumentation die das Einarbeiten in das Framework und in die Klassenbibliothek erschweren und eine fehlende Unterst tzung beim team orientierten Entwickeln Ebenfalls typisch f r das evolution re Arbeiten mit einem Framework ist unserer Meinung nach da sich das Design der Anwendung im Rahmen der vorgegebenen Architektur weiterentwickelt Dabei mu jedoch darauf geachtet werden da die Qualit t der Architektur nicht abnimmt Notwendige technische Redesigns sind wie das Projekt zeigt dazu erforderlich 5 4 3 Ein Swaps Manager Das untersuchte Projekt Die Swaps Abteilung einer Bank handelt mit derivativen Zinsprodukten Abschl sse werden dabei telefonisch get tigt Zu Beginn des Projektes setzten die Swaps H ndler ein PC basiertes System ein mit dem nach Abschlu eines Handels gewisse Aspekte nachgerechnet werden k nnen Die gro en Schw chen dieses Systems sind die finanzmathematische Unvollst ndigkeit und die mangelhafte Benutzungsoberfl che Diese lie es nicht zu da ein H ndler mit dem System Bewertungen durchf hrt w hrend er telefonisc
110. kquisitionsphase eines Projektes um Entscheidungen vorzubereiten und zu helfen eine Vision ber das zuk nftige System zu entwickeln Sie sind daher Weewerfprodukte die schnell und einfach gebaut werden k nnen Ihre fachliche Detailtreue oder ihr software technischer Standard ist nachrangig e Funktionale Prototypen also Prototypen im eigentlichen Sinne modellieren in der Regel Ausschnitte der Benutzungsoberfl che und Teile der Funktionalit t Sie sind entlang einer horizontalen und einer vertikalen Dimension konstruiert Als horizontale Dimension wollen wir in diesem Zusammenhang die Benutzungsoberfl che bezeichnen die vertikale Dimension bezieht sich auf die Tiefe der Implementierung ausgehend von der Oberfl che bis zur untersten Schicht des Zielsystems Diese Prototypen k nnen in ihrer Architektur bereits dem Zielsystem entsprechen e Ein Labormuster modelliert einen technischen Aspekt des sp teren Anwendungssystem Dieser Aspekt kann sich je nach Fragestellung auf die Architektur oder auf die Funktionalit t beziehen Labormuster sind f r die Entwickler ein Experimentalsystem und eine Form von Machbarkeitsstudie Sie m ssen daher nicht zwingend in das Zielsystem eingehen e Ein Pilotsystem ist ein Prototyp von solcher Ausbaustufe und Reife da er im Anwendungsbereich und nicht nur unter Laborbedingungen eingesetzt werden Grundlagen Enor Bookmark not defined kann Er realisiert innerhalb eines Entwicklungsrahme
111. l von verschiedenen Werkzeugen haben wir zwei UNIX und zwei PC basierte Werkzeuge ausgew hlt die aufgrund ihrer technischen M glichkeiten f r das Prototyping besonders geeignet erscheinen Dies soll jedoch keine Wertung dieser oder anderer Werkzeuge darstellen 5 2 1 Grafische Benutzungsoberfl che f r UNIX Programmierwerkzeuge Das untersuchte Projekt Die Entwicklungsabteilung eines gr eren Software Herstellers pafst Standard UNKK Werkzeuge f r ihre Hardware Plattformen an Im Rahmen dieser Anpassungsarbeiten sollen auch die in der Originalversion meist kommando orientierten Programmierwerkzeuge mit optionalen grafischen Oberfl chen ausgestattet werden Da der Auftraggeber weder Wissen noch Erfahrungen im Bereich grafisch interaktiver Benutzungsoberflachen hatte wurde der Auftrag an eine Entwicklergruppe eines assoziierten Software Herstellers vergeben Diese Abteilung entwickelt schwerpunktm ig Werkzeuge f r den Entwurf von Benutzungsoberfl chen und ber t Kunden wenn diese selbst Oberfl chen realisieren wollen F r den Berkeley Unix Debugger dbx sollte eine grafische Oberfl che hnlich der von xdbx entwickelt werden dbx ist ein Werkzeug mit dem in C und C Programmen Fehler lokalisiert werden k nnen Es ist standardm ig in allen UNIX Systemen mit einer zeilenorientierten Kommando Schnittstelle vorhanden Um mit den Systemen verschiedener Mitbewerber konkurrenzf hig zu sein mu te f r die herstellerspez
112. lassen Deshalb sprechen wir auch Aspekte an die in den vorausgegangenen Teilen dieser Studie nicht behandelt wurden die aber u E das Bild abrunden 6 1 Prototyping als Proze Prototyping darf und kann nicht als ein rein technisches Verfahren verstanden werden das sich beliebig in den Software Entwicklungsproze einbauen l t und dabei so wenig Seiteneffekte zeigt wie die Auswahl eines Texteditors oder eines Darstellungsmittels f r Programmentw rfe Prototyping ist nicht nur eng mit einer bergreifenden Entwicklungsstrategie verkn pft es mu auch immer im Zusam menhang mit einer bestimmten Sichtweise der Softwareentwicklung gesehen werden Dies bedeutet in der Praxis da die Art der Projektorganisation die Wahl eines Leitbildes f r die Softwareentwicklung und die Vorgehensweise mit dar ber entscheiden ob Prototyping als Verfahren nutzbringend und zielf hrend ist Im weiteren werden wir dies erl utern 6 1 1 Leitbild und neue Sichtweise Das Leitbild bei der Softwareentwicklung pr gt den Prototyping Prozefs entscheidend Daher ist in jedem Projekt zum fr hest m glichen Zeitpunkt zu kl ren welche Wert Vorstellungen und damit leitenden Ideen mit dem Entwicklungsproze verbunden sind Grunds tzliche Orientierungen sind auf der einen Seite die Idee der m glichst vollst ndigen Ablaufsteuerung und Automa tisierung d h das Bild der Flie bandarbeit und auf der anderen Seite die Idee von Software als unterst tzende
113. len und sie damit bearbeitbar zu machen So ist es z B in Bankanwendungen blich dem Benutzer Bankmitarbeiter mit Hilfe eines EDV Systems einen Gesamt berblick ber die Verm gensverh ltnisse eines Kunden zu geben obwohl sich ein Gesamt berblick normalerweise nicht als Objekt in der fachlichen Komponente der Anwendung befindet Um somit Anwendungen zu entwickeln deren fachlicher Kern stimmig ist und deren Handhabung und Pr sentation der Oberfl che den W nschen der Benutzer entspricht ist eine Benutzerbeteiligung und ein insgesamt evolution res Vorgehen unumg nglich Prototyping als Vorgehensweise mu selbst zum Gegenstand der Diskussion zwischen Entwicklern und den anderen Gruppen werden Denn nur wenn der Stellenwert eines Oberfl chenprototyps klar ist und wenn die einzelnen Gruppen um ihre Einflu m glichkeiten im Prototyping Proze wissen kann das Potential dieser Vorgehensweise voll ausgesch pft werden Erfahrungen zeigen da der implizite oder verdeckte Einsatz von Prototypen eher kontraproduktiv ist Damit meinen wir Enor Bookmark not defined Analyse eine Situation in der die Entwickler den Benutzern nicht klarmachen da sie einen Prototyp bewerten sollen und daher die Benutzer den Eindruck haben mit einem unausgereiften Zielsystem konfrontiert zu sein 6 1 3 Anwendungsorientierung und Benutzerbeteiligung Wir haben Prototyping als Proze in eine evolution re Strategie eingeordnet Diese Strategie ist
114. letzten Jahren wesentlich verbessert auch wenn f r einzelne Rechnerfamilien ein breites Angebot noch aussteht Generell stellen wir fest da die softwaretechnischen M glichkeiten der Umsetzung in der Praxis noch weit voraus sind Dieser Trend k nnte sich in der n chsten Zeit noch verst rken Integrierte Entwicklungswerkzeuge sowie die Verwendung von Designmustern und dedizierten Anwendungsbibliotheken sind in ihren M glichkeiten f r das Prototyping bei weitem noch nicht ausgesch pft Enor Bookmark not defined Glossar Glossar AGL 4 Generationssprache Abfrage und Auswertungssystem mit dem Benutzer und Entwickler einfach auf eine Datenbank zugreifen k nnen 4 Generationssprachen sind Bestandteile von 4 Generationssystemen 4GS 4 Generationssystem Vollst ndige Entwicklungsumgebung f r Informationssysteme auf Basis von Datenbank Managementsystemen Dazu geh ren u a Editoren um das Datenmodell und die Benutzungsoberfl che zu erstellen Programmiersprache n Report Genera toren und das Datenbank Managementsystem selbst Application Framework Objektorientiert konstruierte Standardanwendung Ein Framework besteht aus objektorientierten Basisklassen die Oberfl chenkomponenten und andere Dienst leistungen realisieren und aus Klassen die die eigentliche fachliche Standard anwendung implementieren Im Gegensatz zu einer Toolbox stellt ein Framework nicht nur Bausteine sondern auch eine flexibel erweiterbare Standardar
115. llen Sprache durch Kombination vorhandener grafischer Elemente und der Erweiterung ihres Verhaltens durch Programmtexte in einer speziellen Sprache durch Zukauf von auf dem Markt angebotenen Elementarten Unter den hier betrachteten Gesichtspunkten gen gt es nicht wenn ein Werkzeug eine prozedurale Schnittstelle bietet damit neue Elementarten als Programme eingebracht werden k nnen Dieses Verfahren erfordert meist sehr genaue Kenntnisse der inneren Werkzeugstruktur Enor Bookmark not defined Werkzeugeigenschaften Wesentlich einfacher ist es wenn neue Elementarten mit vorhandenen Mechanismen in das grafische Entwurfswerkzeug integriert werden k nnen Das kann zum einen durch explizite Beschreibung einer neuen Elementart in einer speziell daf r geeigneten Sprache geschehen Eine solche Beschreibung wird dann als Datei in ein vordefiniertes Verzeichnis gelegt Noch einfacher ist es wenn die gew nschte Oberfl chenelementart interaktiv direkt mit dem Werkzeug aus vorhandenen Elementteilen kopiert oder mit einem speziellen Editor erstellt werden kann Eine wesentliche Unterst tzung des Prototyping bieten Werkzeuge f r die neue Oberfl chenelementarten auf dem Markt angeboten werden die dann einfach eingebaut werden k nnen Dadurch w chst die Wahrscheinlichkeit da bei Bedarf auch relativ komplexe Elementarten in kurzer Zeit zur Verf gung stehen 3 4 Kooperation zwischen den Oberfl chenelementen Um Oberfl chenprot
116. m Hilfsmittel f r qualifizierte menschliche Arbeit d h das Bild vom gut ausgestatteten Arbeitsplatz Jedes Softwareprojekt wird sich seinen Enor Bookmark not defined Analyse Platz in diesem Spektrum suchen m ssen Dieser Platz bestimmt aber die M glichkeiten die anwendungs und benutzungsorientiertes Prototyping bietet Eine rigide Ablaufsteuerung und Proze automatisierung als Leitbild wird selten zu einer kooperativen und offenen Arbeit mit Prototypen zwischen Anwendern Benutzern und Entwicklern f hren da nur wenige Anwender und Benutzer eine flie bandartige T tigkeit als ihre Wunschvorstellung bei der Softwareentwicklung haben werden Entwickler die eine solche Art von Software anstreben haben sicherlich ein positives Bild von Anwendern Neben dem Leitbild spielt die Sichtweise auf den Entwicklungsproze eine wichtige Rolle Vielfach dominiert die sog Produktsicht d h Softwareentwicklung wird als ein Produktionsproze verstanden der hnlich der industriellen Herstellung von Konsumg tern in einem festgelegten und m glichst arbeitsteiligen Produktions proze zu einem vorab definierten Produkt f hrt Entsprechend sind viele Entwicklerorganisationen in Abteilungen wie Kundenbetreuung Entwicklung Organisation Vertrieb Infrastruktur etc aufgeteilt In den letzten Jahren ist deutlich geworden da Software so kaum anwendungsorientiert entwickelt werden kann An die Stelle der Produktsicht tritt vermehrt eine Projekt oder
117. mgesetzt werden Statt dessen wurde der Prototyp der die starre Benutzerf hrung implementierte und von Mitarbeitern der Hochschule erstellt war vom Software Haus als Teil des Angebots eingereicht Die konstruierten Prototypen Die nachfolgende Abbildung zeigt schematisch den Projektablauf und die dabei erstellen Prototypen Die kreisf rmigen Symbole bedeuten ein zyklisches Vorgehen Enor Bookmark not defined HyperCard Projekte Phase I Es wurden die zwei erw hnten Arten von Prototypen entwickelt e Die als Bausteine verwendeten voll funktionsf higen SuperCard Prototypen der Interaktionselemente wie Datenauswahl und Ortswahl e Die reinen Oberfl chenprototypen mit denen verschiedene Gestaltungs m glichkeiten bewertet wurden Phase II In dieser Phase wurde iterativ mit SuperCard ein funktionaler Prototyp erstellt Bei diesen Iterationen wurden jedoch die potentiellen Benutzer des Systems nicht beteiligt Als die Entwickler mit dem Prototyp zufrieden waren wurden zwei Varianten entwickelt eine mit freiem und eine mit gef hrtem Dialog Die Grundidee war aus diesen Varianten mittelfristig einen Prototyp mit einem Anf nger und einem Expertenmodus zu entwickeln Dazu kam es aber aus Finanzierungsgr nden nicht mehr Erfahrungen der Entwickler Das Projekt hinterlie bei den Entwicklern gemischte Gef hle Als positiv wurde eingesch tzt da im Rahmen des Projekts Erkenntnisse der Forschung praktisch angewendet
118. mming for the Macintosh Hayden Book Company Vlissides 89 J M Vlissides M A Linton Unidraw A Framework for Building Domain Specific Graphical Editors Proc of the ACM SIGGRAPH SIGCHI User Interface Software and Technologies Conference A Weinand E Gamma R Marty Design and Implementation of ET a Seamless Object Oriented Application Framework Structured Programming Vol 10 No 2 A Weinand Objektorientierte Architektur f r graphische Benutzungsoberfl chen Realisierung der portablen Fenstersystemschnittstelle von ET Springer Verlag
119. mor Bookmark not defined 4 Generationsystem Projekte hierbei da eine getrennte Diskussion der Oberfl che nicht sinnvoll und m glich war Als Tendenz zeichnet sich ab da bei komplexen Anwendungen die Gestaltung der Benutzungsoberfl che eher von der fachlichen Komponente der Anwendung her erfolg als da sich umgekehrt die fachliche Komponente von der Oberfl chengestaltung her entwickeln l t Da 4D eine direkte Verzahnung von Datenbankschema und Oberfl chengestaltung erm glicht kann dieser Zusammenhang leicht aufrechterhalten werden Dazu kommt da der rasche Wechsel zwischen Entwicklungsmodus f r Schema und Oberfl che und experimenteller Erprobung f r Prototyping Prozesse sehr f rderlich ist Schlie lich scheint uns bemerkenswert da nach l ngerem Piloteinsatz bewu t ein tiefgreifendes Redesign eingeplant und umgesetzt wurde Dadurch wird vermieden da sich durch die schrittweise Entwicklung eines Systems ein Strukturverlust einstellt und da tiefergreifende nderungswtinsche st ndig aufgeschoben werden 5 3 2 Ein Arbeitsplatz fur Konzembetreuer Das untersuchte Projekt Die Qualit t der Beratung im Bankgewerbe ist stark davon abh ngig wie schnell aktuelle Informationen verf gbar sind Da diese von unterschiedlichen Anbietern bereitgestellt werden mu ein Berater mehrere Informationssysteme mit verschiedenen Benutzungsoberfl chen und oft auch unterschiedlicher Hardware benutzen Neben dem geringen Komfor
120. n alle Bestandteile einer Anwendung oder eines separierbaren Teils einer Anwendung die die Oberfl che mit ihren Darstellungsformen und ihrem interaktiven Verhalten realisiert in einer Komponente zusammenzufassen wir nennen sie Oberfl chenkomponente Davon getrennt gruppieren wir die fachlichen Anteile der Anwendung in der fachlichen Komponente F r einige Formen von Oberfl chen Prototyping ist es wichtig da sowohl die Oberfl chen als auch fachlichen Komponenten mit einer Datenbankkomponente interagieren Wir halten fest da dies zun chst nur eine konzeptionelle Einteilung ist Ein wesentlicher Gesichtspunkt in der weiteren Diskussion wird sein inwieweit sich besonders die Oberfl chenkomponente und die fachliche Komponente auch software technisch getrennt in eigenen Modulen Klassen oder Subsystemen fassen lassen Interaktive Anwendungssysteme Mit der rasch wachsenden Verbreitung grafischer Arbeitsplatzrechner kommt der Oberfl chengestaltung und damit auch dem Oberfl chen Prototyping zentrale Bedeutung zu Hier sind es wie gesagt die interaktiven Arbeitsplatzsysteme oft im Zusammenspiel mit Serverrechnern die nach dem Leitbild des elektronischen Schreibtischs f r B roanwendungen im Mittelpunkt stehen Aber auch im Produktionsbereich werden heute bei Echtzeitsystemen f r Proze steuerung und kontrolle wachsende Anforderungen an die Oberfl chengestaltung gestellt Deshalb Enor Bookmark not defined Grundlagen soll die
121. n Framework Smalltalk gearbeitet Die dritte Fallstudie beschreibt ein Projekt bei dem ein Arbeitsplatz f r einen SWAPS H ndler entwickelt wurde Dazu wurde das Application Framework ET eingesetzt 5 4 1 Ein Editor fur SMFFNachrichten Das untersuchte Projekt Seit l ngerer Zeit wird ein Software System bei Banken eingesetzt mit dem SWIFT Nachrichten sowohl innerhalb einer Bank versendet als auch zwischen Banken ausgetauscht werden k nnen SWIFT ist ein normiertes Nachrichtenformat f r Transaktionen im Bankensektor Das System ist eingef hrt und weltweit im Einsatz Es ist in Assembler realisiert Eine Entwicklungsabteilung des Herstellers gab zusammen mit der Marketing abteilung den Auftrag einen Teil des Systems zu verbessern Das neu zu entwickelnde Subsystem ist eine Komponente mit der definiert werden kann wie SWIFT Nachrichten zwischen den einzelnen Funktionen z B Arbeitspl tzen in einer Bank ablaufen sollen Zudem sollte es m glich sein den Nachrichtenflu zwischen den einzelnen Bankfunktionen z B Eingang Drucken Verifizieren durch Vorgesetzten usw durch Bedingungen zu definieren die als Entscheidungstabellen betrachtet werden k nnen Diese T tigkeit wurde bisher folgenderma en durchgef hrt Es wurden auf Papier entsprechende Szenarien erstellt die den Nachrichtenflu zeigen und die Bedingungen enthalten Diese Szenarien wurden dann direkt in Assemblermakros umgesetzt Das Projekt wurde initiiert um fe
122. n Jahren als Software Entwickler in die Studie eingebracht Wir haben diesen Bericht folgenderma en aufgebaut Im zweiten Kapitel f hren wir die Terminologie ein die wir in diesem Bericht verwenden und beschreiben den Stellenwert von Prototyping im Software Entwicklungsproze Weiterhin gehen wir speziell auf die verschiedenen Arten von Benutzungsoberfl chen sowie auf das Oberfl chen Prototyping ein Kapitel 3 beschreibt Merkmale und Eigenschaften von Werkzeugen zum Prototyping von Oberfl chen Wir konzentrieren uns dabei besonders auf die Werkzeugeigen schaften die unserer Meinung nach wesentlich sind wenn mit ihnen Oberfl chen prototypen erstellt und diese anschliessend f r ein Zielsystem weiterentwickelt werden Kapitel 4 enth lt eine Klassifikation verschiedener Werkzeuge Im Zusammenhang mit Oberfl chen Prototyping unterscheiden wir vier Gruppen die Interface Builder die 4 Generationssysteme Hypercard basierte Werkzeuge und Objektorientierte Frameworks Die verschiedenen Werkzeugarten werden anhand der in Kapitel 3 formulierten Eigenschaften vorgestellt F r jede Werkzeugart werden ein bis zwei Werkzeuge vorgestellt um die Konzepte zu verdeutlichen Wir haben solche Werkzeuge als repr sentative Beispiele f r die einzelnen Werkzeuggruppen ausgew hlt die auch in den in Kapitel 5 vorgestellten Projekten eingesetzt wurden Dadurch wird es f r den Leser einfachen die geschilderten Fallstudien zu verstehen Aufgrund der tec
123. n Software Entwicklern sowie Mitarbeitern der Qualit tskontrollee der Handbuch Redaktion und aus Benutzervertretern Au erdem k nnen die Entwickler auf beiden Seiten als Benutzer des Systems betrachtet werden Dies hat wesentlich zur Akzeptanz auf der Seite der Auftragnehmer beigetragen Das gesamte Projekt wurde auf Festpreisbasis vereinbart Allerdings wurde der genaue Funktionsumfang durch die Entwickler in der ersten Projektphase festgelegt Termine und Kosten wurden folglich sehr genau eine Woche Verz gerung keine finanzielle Abweichung eingehalten Das Pilotsystem wurde nur durch Gremien des Auftraggebers evaluiert und akzeptiert nicht durch sp tere Benutzer W hrend des Projektes wurde eine Reihe von Dokumentationen vom Auftraggeber verlangt Anforderungskatalog Pflichtenheft Wartungsdokument Benutzerhandbuch Die beiden letzten Dokumente wurden am Ende der Entwicklung erstellt Benutzte Werkzeuge Zielsysteme fiir die Entwicklung waren auf Intel 80368 80486 und SPARC basierte UNIX Workstations Das System wurde auf Sun Workstations und X Terminals entwickelt Die Software des Gesamtsystems wurde auf X11R4 und Motif 1 1 in C implementiert F r das Prototyping der Benutzungsoberflache wurde das Werkzeug DialogBuilder der Firma SNI in den Versionen 1 1 und 2 0 eingesetzt Dieses Werkzeug produziert alternativ Oberflachenbeschreibungen in Motif UIL bzw C Code f r die Ablaufumgebung Au er Editoren und Debuggern wurden k
124. n gro e Teile des bereits entstandenen Systems bernommen werden Bevor das System endg ltig abge nommen wurde wurde die entstandene Benutzungsoberflache von der Qualit tssicherung des Auftraggebers die auch ergonomische Eigenschaften der Systeme pr fte analysiert Nachdem einige nderungswiinsche integriert waren wurde das System akzeptiert Die Oberfl che wird nachdem das Projekt abgeschlossen war von Software Entwicklern des Auftraggebers weiterentwickelt Dazu wurde ein Mitarbeiter des Auftraggebers im Verlauf des Projekts eingearbeitet Der Wissenstransfer vom Auftragnehmer zum Entwicklerteam des Auftraggebers war von Anfang an vorgesehen und eingeplant Das Entwicklerteam des Auftraggebers sollte in die Lage versetzt werden bei weiteren Werkzeugentwicklungen die Benutzungsoberfl chen selbst gestalten zu k nnen Die konstruierten Prototypen Es wurden verschiedene Labormuster gebaut um vor allem Fragen der Realisierbarkeit der Schnittstelle zur fachlichen Komponente zu kl ren Weiterhin wurde ein funktionaler Prototyp entwickelt der auch dem Auftraggeber Entwickler Benutzer Qualit tssicherung demonstriert und sp ter evolution r zum Zielsystem weiterentwickelt wurde Das verwendete Werkzeug unterst tzte die Entwickler dabei gro e Teile des ersten Prototyps weiterzuverwenden Dies war jedoch nur m glich da die Aufgabenstellung bereits hinreichend gekl rt war bevor der Prototyp erstellt wurde Der Prototyp wurd
125. nd m glicher technischer L sungen W hrend der ersten drei Monate des Projektes wurden drei Ziele verfolgt e Einarbeiten in das Anwendungsgebiet e Prototyping von Interaktionselementen d h elementarer Bausteinprototypen f r spezielle wichtige Handhabungsformen wie Datenauswahl oder Ortswahl e Experimentelle Bewertung verschiedener Gestaltungsalternativen der Benutzungsoberfl che Um das Anwendungsgebiet kennen zu lernen wurde zuerst das Tarifsystem des Verkehrsunternehmens anhand schriftlicher Unterlagen studiert Da dieses sehr kompliziert war besuchte ein Entwickler anschlie end einen Kurs mit dem das Verkehrsunternehmen intern seine Mitarbeiter schult Parallel dazu wurden SuperCard Prototpyen f r verschiedene generische Interaktionselemente entwickelt Dabei sollten f r h ufig vorkommende Handhabungsformen effiziente L sungen gefunden werden Diese Prototypen wurden zyklisch von einem Programmierer und einem Ergonomen entwickelt Diese experimentell erstellten Prototypen wurden mehrfach von Studenten bewertet Um das Aussehen des Systems zu modellieren wurden reine Oberfl chenprototypen mit unterschiedlichen Werkzeugen entwickelt Da weitgehende Freiheit bei der grafischen Gestaltung erw nscht war lie man die Prototypen von Personen mit unterschiedlichem beruflichen Hintergrund erstellen einem Grafiker einem Designer einem Programmierer und einem Ergonomen Die vier resultierenden Oberfl chenprototypen zeigten pr
126. nders von Seiten der Hersteller sind auch die von uns untersuchten Werkzeuge zum Oberfl chen Prototyping keine Universalwerkzeuge Wir haben mehrfach darauf hingewiesen da die Arbeit mit den jeweiligen Werkzeugen sehr schnell unhandlich und aufwendig wird wenn sie im Grenzbereich ihres Einsatzschwerpunktes eingesetzt werden Dabei kann der Einsatzschwerpunkt sich sowohl auf den Anwendungsbereich als auch auf die verwendete Entwurfsmetapher z B elektronischer Karteikasten beziehen 6 4 1 Grenzen des Werkzeugeinsatzes Es hat sich in unserer Studie wieder einmal deutlich gezeigt da die Hoffnung tr gerisch ist mit Hilfe von Werkzeugen grundlegende konzeptionelle Probleme der Anwendungsentwicklung zu l sen Grundlegend sind etwa die Sichtweise und ein dazu passendes Leitbild die Wahl einer geeigneten Methode und Entwicklungs strategie sowie die Analyse der Anwendungssituation Werkzeuge k nnen immer nur unterst tzend auf einer vorhandenen konzeptionellen und methodischen Basis eingesetzt werden Wenn diese Basis fehlt kann der Einsatz von Werkzeugen mehr schaden als n tzen Gefahren eines verfehlten Werkzeugeinsatzes zeigen sich vor allem an zwei Stellen Zum einen kann die rasche Erstellung von Oberfl chen Prototypen dar ber hinwegt uschen dafs die fachlich konzeptionelle Grundlage fehlt Auch in diesem Sinne warnen wir vor einem Rapid Prototyping Erfahrungen zeigen da Prototypen auf dieser mangelnden fachlichen und oft a
127. ner der als Kombination einer spreadsheet artigen Anwendung mit Druckkn pfen und Men s Berechnungen auf Formularen durchf hren konnte Ein anderer skizzierter Werkzeugtyp war ein Formularkopierer der nach Markierung von Quell und Zielformular Inhalte zwischen gleichen Feldern kopieren konnte Die tberarbeitung des Demonstrationsprototyps geschah nicht mit Blick auf die fachliche Korrektheit von Formularinhalten oder Berechnungsalgorithmen sondern richtete sich auf eine grunds tzlich verst ndliche Terminologie der dargestellten Gegenst nde und auf eine in groben Umrissen CUA vertr gliche Gestaltung des Oberflachenlayouts Der erste funktionale Prototyp wurde mit Hilfe des Interface Builders CASE PM auf PCs entwickelt Seine fachliche Komponente umfa te bereits Ans tze zur Unterst tzung der Beratert tigkeit Erste Arbeitsmittel und gegenst nde wurden sowohl in ihrer Funktionalit t als auch in ihrer Darstellung an der Benutzungsoberfl che entworfen Der Prototyp war entsprechend breit angelegt d h es war schon viel Funktionalit t angedeutet ohne da sie jedoch bis in die Tiefe implementiert war Bei der Implementierung dieses Prototyps gab es erhebliche Schwierigkeiten da die Entwicklungsumgebung den Entwicklern noch wenig bekannt und von den Enor Bookmark not defined HyperCard Projekte Produkten her wenig ausgereift war Es zeigte sich da CASE PM nicht sehr flexibel f r eine komplexe Oberfl chengestaltung verwendet we
128. ng Oriented Software Development Concepts and Tools Springer Verlag Budde 92 R Budde K Kautz K Kuhlenkamp H Z llighoven Prototyping an Approach to Evolutionary System Development Springer Verlag Berlin Heidelberg New York L P Deutsch Design Reuse and Frameworks in the Smalltalk 80 System Floyd 84 Chr Floyd A Systematik Look at Prototyping In Budde er al eds Approaches to Prototyping Springer Verlag pp 105 122 E Gamma R Marty ET An Editor Toolkit for Bitmap Oriented Workstations Research Report Nr 86 01 Institut f r Informatik Universit t Z rich 1986 E Gamma Objektorientierte Software Entwicklung am Beispiel von ET Springer Verlag 1992 Goldberg 83 A Goldberg D Robson Smalltalk 80 The Language and its Implementation Addison Wesley Goldberg 84 A Goldberg Smalltlalk 80 The Interactive Programming Environment Addison Wesley Grycan 9 G Grycan H Z llighoven Objektorientierte Systementwicklung Leitbild und Entwicklungsdokumente Informatik Spektrum Vol 15 No 5 pp 264 272 R E Johnson B Foote Designing Reusable Classes JOOP June July R E Johnson V F Russo Reusing Object Oriented Designs University of Illinois tech report UIUCDCS 91 1696 Kieback 91 A Kieback H Lichter M Schneider Hufschmidt H Ziillighoven Prototyping in industriellen Software Projekten Erfahrungen und Analysen GMD Studie Nr 184 St Augustin Kieback 92 A
129. nisse und Erfahrungen aus mehr als einem Jahrzehnt Praxis mit Prototyping ignoriert Noch immer sind die Projekte in denen auf einer halbwegs soliden konzeptionellen Grundlage Prototyping eingesetzt wird gegen ber den konventionell und teilweise konzeptionslos durchgef hrten Projekten in der verschwindenden Minderzahl In Anbetracht der heftigen Diskussion um neue Methoden und Werkzeuge ist das ein auf den ersten Blick unverst ndlicher Umstand da die Ergebnisse von Prototyping Projekten durchweg als ermutigend zu bezeichnen sind Schauen wir allerdings in das organisatorische Umfeld wird dieses Mi verh ltnis verst ndlicher Dann stellen wir n mlich fest da die westlichen industriellen Gro unternehmen generell in einer Strukturkrise stecken Wir sehen enge Verbindungen zwischen den Ans tzen des Business Process Reengineering und den Ideen der evolution ren und anwendungsorientierten Softwareentwicklung Analyse Enor Bookmark not defined Daher bef rchten wir da sich eine ver nderte Denkweise in den Unternehmens leitungen insgesamt durchsetzen mu ehe sich an der Software Entwicklung auf breiter Front etwas entscheidendes ndert Erg nzend zu dieser eher pessimistischen Einsch tzung sehen wir die Situation im Forschungs und Wissenschaftsbereich Zumindest f r den deutschsprachigen Raum gilt da Prototyping und damit Ans tze zur experimentellen und partizipativen Softwareentwicklung von der vorherrschenden Informatik als
130. norientierte Oberfl chen die mit Maskengeneratoren erstellt werden berwiegen In Kieback 92 wird z B ber ein Prototyping Projekt berichtet in dem eine gro e Anzahl von Masken f r eine zeichenorientierte Benutzungsoberfl che erstellt wurde Allerdings kann diese Technologie heute als berholt bezeichnet werden und wird tendenziell auch stark an Bedeutung verlieren Eine detaillierte Einsch tzung findet sich in Budde 92 2 3 Oberfl chen Prototyping Bei der Arbeit an dieser Studie ber Oberfl chen Prototyping haben wir festgestellt da uns eine einheitliche Terminologie fehlt Jeder der in einer Anwendungs oder Entwicklungswelt zu Hause ist verwendet mitunter sehr unterschiedliche Begriffe teils deutschsprachige teils als Anglizismen Wir haben deshalb in den folgenden Abschnitten die Terminologie im Bereich Oberfl chen Prototyping erl utert die Grundlage dieses Berichts ist 2 3 1 Begriffe Oberfl chenelemente Eine Oberfl che ist mehr als das Bildschirm Layout Oberfl chen zeigen nat rlich zun chst bestimmte grafische Darstellungsformen also das was auf dem Bildschirm unmittelbar sichtbar ist Heute sind diese Darstellungsformen nicht mehr beliebig sondern lassen sich meist derjenigen Fenstersystemfamilie zuordnen mit deren Hilfe sie realisiert worden sind Oft spricht man in diesem Zusammenhang auch von dem charakteristischen Look einer Oberfl che Oberfl chen sind aber nicht nur durch statisch angeordne
131. ns einen abgeschlossenen Teil des Zielsystems und wird schrittweise ausgebaut Auch seine komfortable und sichere Bedienbarkeit und ein Mindestma an Benutzungsdokumentation unterscheiden ihn qualitativ von anderen Prototypen In dieser Studie sprechen wir sehr oft von Oberfl chenprototypen Damit ist keine weitere Art von Prototyp gemeint sondern wir betrachten solche Demonstrationsprototypen funktionalen Prototypen und Labormuster bei denen die Modellierung der Benutzungsoberfl che im Vordergrund steht Inwieweit dazu fachliche Funktionalit t kommt richtet sich nach der jeweiligen Prototypart Bei Pilotsystemen gehen wir davon aus da dort Oberfl che und fachliche Funktionalit t gleicherma en vorhanden sind 2 2 Benutzungsoberfl chenarten Zur groben Klassifikation von Benutzungsoberfl chen unterscheiden wir drei Gruppen 1 _ Zeichenorientierte Benutzungsoberfl chen bieten meist keine oder nur sehr eingeschr nkte M glichkeiten um Grafik darzustellen Ihr wichtigster Vorteil ist da sie auf sehr vielen Hardware Plattformen eingesetzt werden k nnen da sie nur geringe Anforderungen an die Bildschirmger te stellen Andererseits sind die m glichen Benutzungsoberfl chen nat rlich sehr einfach und f r viele Anwendungen z B Visualisierung von Prozessen nicht ausreichend Um zeichenorientierte Oberfl chen zu erstellen werden schon seit l ngerer Zeit Werkzeuge wie die sog Maskengeneratoren eingesetzt 2 Grafische
132. nutzer mit dem System ber verschiedene Kommunikationskan le interagieren Als Kommunikationskan le k nnen z B Sprache Gestik Datenhandschuhe und Virtual Reality genannt werden Model View Controler Framework Standardarchitektur f r graphische Benutzungsschnittstellen Diese definiert drei Komponenten und deren Koordination Die Komponenten sind die fachlichen Informationen Model deren graphische Repr sentation View und die Ereignisbehandlung Controler Oberfl c henelement Interaktionselement Atomare Elemente aus denen Oberfl chen aufgebaut werden k nnen Beispiele sind ein Knopf ein Men oder ein Eingabefeld Oberfl chenelementart Interaktionstyp Beschreibt einen Typ von Oberfl chenelementen Ein Oberfl chenelement ist immer ein Exemplar der dazugeh renden Oberfl chenelementart Beispiel der OK Knopf und der CANCEL Knopf sind Exemplare der Oberfl chenelementart Knopf Oberfl chenkomponente Alle Komponenten einer Anwendung die deren Oberfl che realisieren Weitere Komponenten sind die fachliche Komponente und die Datenbankkomponente Palette In Anlehnung an die Farbpalette aus denen ein K nstler Farben ausw hlt um ein Bild zu malen stellt ein Interface Builder die angebotenen Oberfl chenelementarten in einer Palette dem Designer einer Oberfl che zur Verf gung Durch Selektion mit der Maus aus der Palette erh lt er ein Oberfl chenelement das er auf der Entwurffl che plazieren kann Reaktives
133. okmark not defined Interface Builder Projekte Teilprojekten mit unterschiedlichen Zielen eingesetzt In der Anfangsphase des bereits beschriebenen initialen Teilprojekts wurde CASE PM f r den ersten funktionalen Prototyp verwendet In Nachfolgeprojekten z B im Bereich Wertpapiergesch fte wird Digitalk PARIS f r Demonstrationsprototypen eingesetzt Wir gehen hier nur auf diese spezifischen Aspekte ein Das initiale Projekt Den Projektablauf des initialen Teilprojektes haben wir in Abschnitt 5 1 1 geschildert Der erste funktionale Prototyp wurde mit Hilfe des Interface Builders CASE PM auf PCs entwickelt Neben seiner fachlichen Komponente auf die wir in eben erw hntem Abschnitt schon eingegangen sind sollte anhand des Prototyps technisch erprobt werden wie die Vorstellungen der Entwickler mit Hilfe einer interaktiven Oberfl che unter OS 2 und mit Presentation Manager realisiert werden konnten Es zeigte sich da CASE PM nicht sehr flexibel f r eine komplexe Oberfl chengestaltung verwendet werden konnte Zwar lie en sich Standardlayouts rasch erstellen aber geschachtelte Fenster mit Men leisten und Kn pfen konnten nicht in der gew nschten Anordnung erstellt werden Dazu kam da CASE PM ein komplexes C Programmskelett generiert in das die verschiedenen Systemreaktionen auf die u eren Ereignisse integriert werden m ssen Das f hrt dazu da handprogrammierte Teile bei der Ver nderung des Oberfl chenlayouts entweder m
134. ollen Zudem ergab sich die Forderung da das Werkzeug Simulationsmodelle die bereits vorhanden waren verarbeiten kann An der Gestaltung der Oberfl che gab es wenig Kritik Die informationstechnische Verarbeitung der Ergebnisformulare einer Fehler und Signalflu analyse l ste bei Emor Bookmark not defined Framework Projekte den Benutzern erstmals eine intensive Diskussion ber die Semantik dieser Formulare aus Dies bezog sich auf den Zusammenhang der einzelnen Daten die auf dem Formular erfa t wurden Erstaunlich ist dabei daf die Mitarbeiter schon lange Zeit mit den Formularen in Papierform gearbeitet haben Der dritte Prototyp wurde von den Entwicklern mit dem Ziel erstellt ihn als Pilotsystem einzusetzen Es konnten jedoch keine Benutzer f r den Piloteinsatz des Systems gefunden werden Dies wurde grafsenteils mit Zeitmangel begr ndet Um die Flexibilit t und die Erweiterbarkeit des Systems zu verbessern entstand durch ein tiefgreifendes fachliches und technisches Redesign ein weiterer vierter Prototyp F r ihn gibt es innerhalb der Firma vier Pilotinterssenten Eine erste Installation bei einem Benutzer war f r Ende 1992 geplant Bei der Entwicklung des Systems war von Anfang an eine externe Firma integriert Die erste Zusammenarbeit fand auf der Basis von konkreten Teilauftr gen statt Mitarbeiter des externen Partners nahmen auch am technischen und fachlichen Redesign des Systems teil weil in der Firma selbst das Syst
135. otypen schnell zu erstellen ist es wichtig da die Handhabung der Oberfl chenelemente und deren Zusammenarbeit auf einfache Weise in der Ober fl chenkomponente definiert werden kann ohne da daf r eine konventionelle Programmiersprache verwendet werden mu Soll eine vollst ndige Anwendung aus Oberfl chen und fachlicher Komponente erstellt werden ist dieses Kriterium hingegen nachrangig Es gibt die folgenden Ans tze um die Handhabung einer Oberfl che auf einfache Art und Weise beschreiben zu k nnen Ein verbreiteter Ansatz ist die Verwendung spezieller auf die Ereignisbehandlung zugeschnittener Programmiersprachen oft Skriptsprachen genannt Programmtexte der Skriptsprache werden den einzelnen Oberfl chenelementen zugeordnet Mit ihrer Hilfe l t sich die Handhabung die Weiterleitung von Ereignissen und oft auch die Darstellung der Oberfl chenelemente beschreiben e Der Entwickler kann grafisch spezifizieren welche Ereignisse wie von einem Oberfl chenelement an ein anderes weitergeleitet werden sollen Beispielsweise kann f r einen Knopf spezifiziert werden da er einem Fenster die Nachricht ffne dich schickt wenn er gedr ckt wird e Hypertext Referenzen erlauben da aufgrund einer vordefinierten Verbindung von einem Kontext des Hypertexts in einen anderen gesprungen werden kann Hypertext basierte Werkzeuge eignen sich deshalb speziell um reine Benutzungs oberfl chen ohne fachliche Komponente zu modell
136. pielsweise Matrizen Tabellenkalkulationen Diagramme und Datenbank Browser Ein Schritt in Richtung Abstraktion bieten solche Systeme bei denen nicht konkrete Oberfl chenelemente sondern abstrakte Interaktionstypen ausgew hlt werden D h im Entwurfsproze wird z B nicht ein bestimmtes Auswahlmen mit seiner konkreten Darstellung beschrieben sondern nur seine 1 aus n Auswahl mit den jeweiligen Auswahlelementen und eine relative Anordnung innerhalb des Layouts Die konkrete Umsetzung auf eine bestimmte Oberfl che und ein Fenstersystem geschieht dann erst im konkreten Generierungsproze und kann ber Parameter gesteuert werden Auf diese Weise lassen sich aus einem Entwurf Oberfl chenprototypen f r unterschiedliche Systemplattformen realisieren 3 3 Emeiterbarkeit der Oberfl chenelementarten W hrend die meisten Werkzeuge einen hnlichen Grundvorrat von Oberfl chen elementarten zur Verf gung stellen ist die Flexibilit t der Werkzeuge und die Qualit t der angebotenen Elementarten durchaus unterschiedlich Da ein Werkzeug nur die f r sehr einfache oder sehr zugeschnittene Anwendungen ben tigten Arten von Ober fl chenelementen standardm ig zur Verf gung stellen kann ist es wichtig da die Palette der angebotenen Oberfl chenelementarten einfach erweitert werden kann Grunds tzlich sehen wir drei M glichkeiten die vorhandenen Elementarten zu erweitern durch Programmierung einer neuen Elementart in einer konventione
137. rden konnte vergl auch Abschnitt 5 2 3 Weitere teils sehr tiefsitzende Probleme mit der Entwicklungsumgebung k nnen sicherlich auf die noch geringe Verbreitung der OS 2 Plattform zur ckgef hrt werden Trotzdem konnte der erste funktionale Prototyp in rund sechs Wochen implementiert werden Erfahrungen der Entwickler Der Demonstrationsprototyp hat f r die grunds tzlichen Entscheidungen zu Projektwiederbeginn eine gro e Bedeutung Doch die Entwickler sch tzen als besonders wichtig ein da rasch eine Vision ber das jetzt angestrebte System pr sentiert werden konnte Denn beim tbergang von der konventionellen zu einer objektorientierten Entwurfsmethode fehlte den Entwicklern vor allem ein Leitbild nach dem sie ihre Modelle und Entw rfe h tten ausrichten k nnen HyperCard eignete sich als Prototyping Werkzeug gut da in kurzer Zeit ein Demonstrationsprototyp gebaut werden konnte der ausreichend viel an Handhabung und Basisfunktionalit t zeigte Insbesondere das Prinzip eines reaktiven Systems konnte daran sehr gut gezeigt werden Die Berater hoben hervor da HyperTalk als Programmiersprache softwaretechnisch zwar wenig berzeugend ist aber auch nach l ngeren Programmierpausen noch gut lesbar ist Daraus resultiert eine typische Art der HyperCard Entwicklung bei der vorhandene Programmteile ber Editorvererbung f r die aktuelle Anwendung modifiziert werden Problematisch wird die HyperCard Entwicklung nur in Bereichen die
138. recht gravierende Probleme Die mangelnde M glichkeit generierte Oberfl chen als verst ndliche Bausteine f r die Softwareentwicklung auch jenseits von Prototypen zu verwenden und die Schwierigkeiten die die nderung von Oberfl chen bereitet wenn sie um fachlichen Komponenten erg nzt worden sind Die sich immer st rker durchsetzende Idee des Client Server Computing gibt der Trennung von Oberfl che und fachlicher Anwendung eine neue Dimension Wir sehen verschiedene Tendenzen Zum einen werden unterschiedliche fachliche Funktionalit ten als gekapselte Dienste angeboten werden die dann in der Anwendung in spezifische fachliche und Oberfl chenkomponenten integriert werden Die heutigen Application Frameworks werden sich in diesem Sinne ver ndern Neben White Box Frameworks die durch Reimplementierung spezialisiert werden m ssen werden in Zukunft auch Black Box Frameworks treten die durch geeignete Werkzeuge oder Umgebungen zu spezifischen Anwendungen konfiguriert und komponiert werden k nnen Die Konstruktion eines passenden Oberfl chenprototyps wird dann eine Teilaufgabe bei der Konfigurierung einer solchen Anwendung sein Systeme dieser Art werden derzeit aber erst in Forschungseinrichtungen erprobt Was k nnen wir nach Abschlu der Studie und mit Blick auf die aktuelle Diskussion ber Stand und Zukunft des Prototyping sagen Zun chst ist erstaunlich in welch gro em Umfang die industrielle Software Entwicklung die Erkennt
139. relandschaft von einer solchen Abteilung generell der Einsatz von Prototyping Werkzeugen unterbunden wird was in der Konsequenz das Prototyping unm glich macht Gelegentlich haben auch die Kunden als Auftraggeber eine dezidierte Vorstellung ber den Werkzeugeinsatz In der Regel ist dies eher nachteilig da diese Vorstellung in den seltensten F llen auf den fachlichen und software technischen Notwendigkeiten des jeweiligen Projektes beruhen Wir bef rworten die Werkzeugauswahl in die Kompetenz der einzelnen Analyse Enor Bookmark not defined Entwicklungsprojekte zu geben die ihre Wahl allerdings mit den projekt ber greifenden Randbedingungen der Entwicklungsorganisation abstimmen m ssen Die in den Projekten verwendeten Werkzeuge wurden i a im intendierten Einsatzschwerpunkt eingesetzt Dies gilt jedoch nicht f r die Hypertext Systeme die h ufig nicht als elektronischer Karteik sten sondern als flexible Werkzeuge zur Oberfl chengestaltung verwendet werden Der Aufwand f r die Einarbeitung in das Werkzeug und in die Methodik wird h ufig nicht vom Projektaufwand getrennt Dies kann dazu f hren da der Prototyping Ansatz gelegentlich als sehr aufwendig eingesch tzt wird Zwei Einflu gr en sind hier zu nennen Zum einen haben viele der von uns untersuchten Entwicklerorganisationen noch keine gro e Prototyping Erfahrung und setzen Werkzeuge zum erstenmal ein Der zweite Grund h ngt mit dem ersten zusammen In vielen Organis
140. ren Sinne bezeichnet werden Er zeigte bereits gro e Teile der Oberfl che und der Funktionalit t Auf seiner Basis wurden evolution r in kurzen Abst nden ca zwei bis drei Wochen eine Folge von weiteren Prototypen entwickelt und mit den Benutzern diskutiert Dabei wechselten sich die Modellierung des Datenmodells und der Ausbau der Funktionalit t zyklisch ab Nach insgesamt einem halben Jahr stabilisierten sich die Anforderungen an die Prototypen Pilotsystem I Es wurde bei drei Benutzern mit jeweils unterschiedlichen Arbeitsaufgaben eingesetzt Das Pilotsystem unterst tzte allerdings nur Vorprojektabwicklung und Mitarbeiterverwaltung Es wurde laufend weiterentwickelt da st ndig Anregungen der Benutzer besonders im Bezug auf die Oberfl chengestaltung kamen Diese Abstimmung der Oberfl che auf die Anforderungen der einzelnen Benutzer f hrte zu einer sehr hohen Akzeptanz des Systems Prototyp IV Er wurde parallel zum Pilotsystem I entwickelt und modellierte die eigentliche Projektverwaltung Pilotsystem II Es umfa t die gesamte gew nschte Funktionalit t Der Einsatz dieses Pilotsystems f hrte nach einer Projektlaufzeit von insgesamt einem Jahr zu gr eren nderungsw nschen die haupts chlich in der gew nschten Trennung zwischen der Verwaltung von Kunden und Mitarbeitern begr ndet ist 4G System Projekte Enor Bookmark not defined Erfahrungen der Entwickler Das 4G System 4th Dimension wurde von den Entwicklern als
141. rosch re erstellt aber keine technische Dokumentation geschrieben 2 Ein explorativer und experimenteller Prototyp mit ET Dieser Prototyp der ebenfalls in der Konzeptphase erstellt wurde diente dazu die Besitzstrukturen in Gro konzernen zu visualisieren sowie ihre Manipulation zu erproben Es handelte sich dabei um einen grafischen Editor Browser Die Entwicklung erfolgte mit dem ET Application Framework Der Entwickler des Prototyps hatte Schwierigkeiten sich in einem vertretbaren Aufwand in das Framework einzuarbeiten Ein nochmaliger Einsatz dieser Technologie w rde deshalb nur unter g nstigeren Zeitbedingungen oder bereits vorhandenen ET Kenntnissen erwogen 3 Ein evolution rer Prototyp mit Windows 4GL Emor Bookmark not defined 4 Generationsystem Projekte Mit diesem Prototyp wurde das gefestigte Konzept realisiert Er wurde als Prototyp im engeren Sinn entwickelt und bis zum einsetzbaren Pilotsystem weiterentwickelt Die Entwicklung erfolgte unter st ndiger R cksprache mit den Benutzern so daf auch die Oberfl che erst jetzt ihr endg ltiges Gesicht bekam Der Einsatz von Windows 4GL wurde von den Entwicklern positiv betrachtet W hrend der Pilotphase wird bei der Schulung und beim Einsatz des Systems beobachtet inwieweit die Benutzer das System akzeptieren Parallel zum Prototyp wurde die Entwicklungsdokumentation erstellt Erfahrungen der Entwickler Der enge Kontakt zwischen Entwicklern und Benutzern f
142. rpr ft werden ob es berhaupt m glich ist eine Benutzungsoberfl che zu entwickeln die man w hrend des telefonischen Handels Framework Projekte Emor Bookmark not defined verwenden kann Sollbruchstelle zwei war das Fertigstellen der Spezifikation des Pilotsystems das als explorativer Prototyp dienen sollte Die Entwicklungs und Zielsysteme sind UNIX Workstations Als Entwicklungs werkzeug wurde das Application Framework ET eingesetzt Der Entwic klungsproze Phase I Studium des Anwendungsgebiets und m glicher technischer L sungen In der ersten Phase ging es f r die Entwickler darum das Anwendungsgebiet kennenzulernen und in einem iterativen Proze zusammen mit den Anwendern einen Prototyp zu erstellen Dieser sollte bei beidseitiger Zufriedenheit als Spezifikation und Basis f r ein Pilotsystem dienen Diese Phase dauerte sieben Monate In dieser Zeit war ein Entwickler vollst ndig mit der Implementierung des Prototyps besch ftigt An der Entwicklung neuer Ideen f r die Benutzungsoberfl che haben zwei weitere Entwickler mitgewirkt Dies aber nur in einem Bruchteil ihrer Arbeitszeit Folgende Aktivit ten wurden in Phase I durchgef hrt e Erarbeiten der bankfachlichen und mathematischen Grundlagen durch die Entwickler in enger Zusammenarbeit mit den Anwendern Die Entwickler mu ten sich so weit in die Materie einarbeiten da sie die Arbeitsabl ufe verstanden und in der Lage waren realistische Prototypen zu bau
143. rt des vorhandenen Fachwissens Eine weite r umliche Verteilung erfordert eine eigenst ndige Koordination f r Projekttreffen und Prototyping Sitzungen Liegt das Fachwissen der Anwender und Benutzer vorrangig im ingenieurwissenschaftlichen und naturwissenschaftlichen Bereich dann kann die Arbeit mit Prototypen oft durch eine eher formal ausgerichtete Spezifikation von Systemteilen erg nzt werden ohne da die gemeinsame Kommunikationsgrundlage von Benutzern und Entwicklern zerst rt wird Wir sind uns im klaren dar ber da in vielen F llen die Entwickler nicht ganz leicht festzustellen k nnen wer die tats chlichen Anwender und Benutzer eines Systems sind Damit ist nicht nur das Problem angesprochen da die Identifikation der potentiellen und tats chlichen Benutzer bei der Produktion von Softwareprodukten f r den anonymen Markt ein eigenes Problem ist Gelegentlich finden wir auch in zugeschnittenen Entwicklungsprojekten die Situation da die Entwickler nicht von der richtigen Benutzergruppe ausgehen oder keinen unmittelbaren Zugang zu ihnen erhalten Erfahrungen mit Oberfl chen Prototyping machen deutlich da neben den Be nutzern und anderen Gruppen der Anwendungsseite auch Spezialisten f r Benutzungsoberfl chen involviert werden m ssen Dies sind sowohl Software Ergonomen als auch Graphiker Auch auf diesem Gebiet existiert ein eklatantes Manko Die Entwickler von Oberfl chen sind h ufig der Meinung da sie genau wis
144. rtet werden k nnen und insbesondere welche nicht sinnvoll an ihn zu stellen sind Grundlagen Emor Bookmark not defined 2 1 2 Die beteiligten Gruppen Im Prototyping Proze sind unterschiedliche Personengruppen mit verschiedenen Verantwortlichkeiten beteiligt Da wir auf diese Gruppen an anderer Stelle Kieback 92 genauer eingegangen sind hier nur eine kurze Begriffskl rung e Auftraggeber und Softwarehersteller sind Vertragspartner eines Entwicklungsprojektes auch wenn dies innerhalb einer Organisation abgewickelt wird e Die Entwickler d h alle Mitglieder des Entwicklerteams ungeachtet ihrer Position als Analytiker Designer oder Programmierer repr sentieren das softwaretechnische Wissen die Verantwortung ber ein Entwicklungsprojekt tr gt das DV Management Die Anwender die sp ter das System direkt und indirekt einsetzen repr sentieren das Fachwissen Auf der fachlichen Seite macht es Sinn noch das Anwendermanagement und die Gruppe der unmittelbaren Benutzer des Systems zu unterscheiden 2 1 3 Kontext des Prototyping Prototyping ist wie gesagt ein Proze in dem Produkte also Prototypen und das Zielsystem entwickelt werden Damit ist der Systementwicklungsproze aber noch nicht insgesamt bestimmt Offen bleibt wann welche Prototypen zu welchem Zweck gebaut werden und von wem sie wie bewertet werden Neben der Art und Weise wie Software entwickelt wird m ssen noch weitere analytische organisatorische und
145. sehen Wir sehen da der Bruch dort entsteht wo Anwendungsfunktionalit t Enor Bookmark not defined Interface Builder Projekte hinzugef gt werden soll Bei vielen Interface Buildern bedeutet dies da in der Zielsprache programmiert werden mu im Beispiel CASE PM also C Die Fallstudie zeigt da dieser Programmieraufwand f r Demonstrationsprototypen kaum investiert wird Erschwerend kam hinzu da CASE PM in der verwendeten Fassung ein einziges komplexes Programmskelett erzeugte was weder f r das Prototyping noch f r die arbeitsteilige und zyklische Software Entwicklung tragbar war PARTS hat unter diesem Aspekt gro e Vorteile Allerdings steht in diesem Projekt die Programmiersprache Smalltalk einer evolution ren Weiterentwicklung des Prototyps vielfach im Wege So stellt sich auch f r PARTS die Frage wieviel Anwendungslogik die Entwickler in einen nicht weiterverwendbaren Prototyp einprogrammieren wollen Im vorliegenden Fall machte sich zudem bei beiden Interface Buildern die Differenz in den Gestaltungsm glichkeiten gegen ber der Zielumgebung bemerkbar CASE PM schr nkte die Entwickler schon beim Layout zu stark ein Daher konnte der funktionale Prototyp nur mit einer manuell erweiterten Oberfl che gebaut werden Demgegen ber stellte PARTS f r das Nachfolgeprojekt mehr an Handhabungs und Layoutm glichkeiten zur Verf gung als die verwendete Fensterbibliothek zul t Daher mu te st ndig berpr ft werden o
146. sen wie gute Oberfl chen aufgebaut sein sollten Dies stimmt aber in der Regel nicht Das daraus resultierende Problem versch rft sich aktuell durch die ver nderte Rechtslage bezogen auf die Gestaltung und den Einsatz von Anwendungssoftware in Enor Bookmark not defined Analyse Unternehmen Die einschl gigen Normen f r die Systemgestaltung und die Ber cksichtigung der arbeitswissenschaftlichen und sofware ergonomischen Erkenntnisse werden zunehmend verbindlich Wir wissen da die Einf hrung von neuen Systemen die diesen Richtlinien widersprachen in einzelnen Unternehmen verhindert wurde Hier ergeben sich neue Forderungen und M glichkeiten des Oberfl chen Prototyping da solche Prototypen bereits im Vorfeld der eigentlichen Systemeinf hrung entsprechen auf Konformit t gepr ft werden k nnen Beim Prototyping innerhalb einer evolution ren Strategie sollte die Chance genutzt werden unterschiedliche Personengruppen in den Entwicklungsproze einzu beziehen und interdisziplin re Teams zu bilden Diese Teams sollten neben den Entwicklern und den Benutzern speziell f r die Konstruktion von Oberfl chen prototypen auch Designer Graphiker und Software Ergonomen enthalten Hier ist vor allem das Projektmanagement gefordert das zun chst heterogene Projektteam mu systematisch integriert werden d h eine gemeinsame Projektsprache und kultur mu gefardert werden geeignete Benutzer und Entwickler m ssen ausgew hlt werden die b
147. ser Bereich in seiner Bedeutung f r das Oberfl chen Prototyping ebenfalls diskutiert werden Oberfl chen Prototyping so wie wir es verstehen bezieht sich auf interaktive Anwendungssysteme die auf grafischen Arbeitsplatzrechnern oder vergleichbaren Rechnern eingesetzt werden Meist sind diese Rechner in Netze eingebunden Nat rlich sind auch die im Gro rechnerbereich auf Datenbanken arbeitenden Informationssysteme zu den interaktiven Anwendungen zu rechnen Wir haben schon darauf hingewiesen da sich dabei die Oberfl che auf Bildschirmmasken mit Cursor oder Funktionstastensteuerung reduziert Ebenso haben die auf Spezialhardware im Grofsrechnerbereich laufenden traditionellen CAD CAM Anwendungen f r unsere Betrachtung geringere Bedeutung da hier die M glichkeiten des Prototyping sehr begrenzt sind und im Regelfall Handarbeit bei der Oberfl chengestaltung vorherrscht Reaktive Systeme Ein wesentliches Merkmal der von uns betrachteten interaktiven Anwendungssysteme ist da sie zumindest was ihr Verhalten an der Oberfl che anbetrifft als reaktive Systeme bezeichnet werden k nnen In reaktiven Systemen geht jede Aktivit t vom Benutzer aus tber die entsprechenden Eingabeger te wird eine Aktion des Benutzers in ein Ereignis des Systems umgesetzt Dieses Ereignis oft event genannt wird vom Fenstersystem einem als aktiv bezeichneten Ereigniskontext zugewiesen Solche Ereigniskontexte k nnen Fensterfl chen oder wie heute blich
148. sgerichtet ist Weiterhin ist wichtig da die fachliche Zielsetzung eines Softwareprojektes gekl rt ist oder wenn dies beim Projektstart noch nicht der Fall ist da diese fachliche Kl rung vorrangig im Projekt angestrebt wird In solchen F llen kommt dem Werk zeugeinsatz auch f r das Oberfl chen Prototyping nur nachrangige Bedeutung zu Klarheit des konzeptionellen Rahmens ist vielfach dort gegeben wo die Anwendung von der fachlichen Seite her gut bekannt ist und wo Benutzer und Anwender bereits Analyse Enor Bookmark not defined selbstverst ndlich mit DV Unterst tzung arbeiten In solchen Standardanwen dungen finden wir auch viele bew hrte Werkzeuge die es erlauben in relativ kurzer Zeit durch Komposition vorhandener Bausteine Teile von Anwendungen zu bauen Bei den untersuchten Projekten k nnen 4 Generationssysteme als Beispiel genommen werden Die zeitlich logische Abfolge beim Bau von Oberflachenprototypen ist von Bedeutung Obwohl vielfach noch propagiert wird macht es u E wenig Sinn zuerst die Benutzungsoberfl che zu entwerfen und dann daraus die fachliche Komponente der Anwendung abzuleiten Dies f hrt in der Regel zu Softwarearchitekturen die keine saubere Trennung von Darstellung und Handhabung an der Oberfl che sowie fachlicher Funktionalit t haben Zudem wird bei diesem Vorgehen die Diskussion ber die fachliche Substanz des Anwendungssystems vollkommen vernachl ssigt Dies f hrt z B in objektorienti
149. ssen zu erarbeiten war wesentlich gr er als zuerst angenommen Dieser Proze konnte nicht sinnvoll mit Prototyping unterst tzt werden Prototyping war aber in Phase I und II wichtig um das Fachwissen zu tberpriifen e Es war schwer die Anwender f r dieses Projekt zu interessieren da es lange dauerte bis der erste Prototyp erstellt war mit dem man zeigen konnte da die geplante Art von Benutzungsoberfl che ihre Bed rfnisse wirklich befriedigt Dies war aufgrund der Neuartigkeit und Komplexit t der Benutzungsoberfl che nicht zu vermeiden e Der erste Prototyp wurde inkrementell und evolution r zum Pilotsystem weiterentwickelt W hrend dieser Zeit war der Prototyp zeitweise explorativ experimentell und evolution r Ohne einen evolution ren Prototyping Ansatz w re die Entwicklung eines solchen Produktes kaum m glich gewesen e Der Einsatz des ET Application Frameworks wird als sehr positiv bewertet Es erlaubt durch seine wiederverwendbaren Bausteine relativ schnell Framework Projekte Enor Bookmark not defined Standardbenutzungssoberfl chen zu bauen Komplexe neuartige Komponenten konnten aufbauend auf den Framework und Visualisierungsklassen in relativ kurzer Zeit implementiert werden Der wichtigste Aspekt war aber da die in weiten Teilen vorgegebene Anwendungsarchitektur erm glichte den Prototyp evolution r weiterzuentwickeln ohne da regelm ig grafsere Redesigns n tig waren Unsere Einsch tzung
150. st ndnis wurde in nur drei Monaten das endg ltige Konzept erstellt Beteiligt daran waren f nf Benutzer und f nf Entwickler Parallel dazu entstanden drei Prototypen mit Intermedia SuperCard und ET die das Konzept ma geblich beeinflu ten Zum Abschlu der Phase fiel die Entscheidung des Managements da der eigentliche Prototyp mit Windows 4GL gebaut wird Kl rungsphase Nachdem das Konzept feststand r ckte jetzt die Realisierung in den Mittelpunkt des Interesses Als Konsequenz daraus verringerte sich der Anteil der Benutzer im Projektteam deutlich einem bis zwei Benutzern standen vier Entwickler gegen ber Es entstanden mehrere Labormuster mit Windows 4GL mit denen die zu verwendenden externen Schnittstellen untersucht wurden Nach einem dreiviertel Jahr stand das Vorgehen f r die Realisierung fest Urspr nglich wurde das gesamte Problem als Dokumentenverwaltung betrachtet das unter Verwendung von Hypertext Ans tzen gel st werden kann Inzwischen hat man jedoch erkannt da die L sung aus einer Sammlung von Datenbankanwendungen besteht 4G System Projekte Enor Bookmark not defined Realisierung Die Entwickler 2 12 ben tigten dazu ein knappes Jahr Die Benutzer standen als Berater und Auskunftspersonen zur Verf gung Schwerpunkte der Realisierung waren Datenbankanwendungen Schnittstellen zu externen Systemen Doku mentenverwaltung und Systemaspekte im Hinblick auf die Pilotphase Hier kam zum Tragen da die
151. stzustellen ob die Banken bereit sind dieses Produkt zu erwerben und einzusetzen Die Marketingabteilung erteilte den Auftrag die Komponente so zu realisieren da die Definition des Nachrichtenflu es interaktiv grafisch mit einem Werkzeug geschehen soll das anschlie end die entsprechenden Assemblerteile generiert Weiterhin sollte es in der Lage sein Emor Bookmark not defined Framework Projekte bestehende Entscheidungstabellen einzulesen und zu visualisieren Diese Komponente wird im weiteren als SNE SWIFT Nachrichten Editor bezeichnet Da es kein Vorbild f r eine solche Anwendung gab war von vorne herein geplant innerhalb eines evolution ren Entwicklungsmodells Prototyping durchzuf hren damit ein Prototyp der die Darstellungsform die Handhabung und das Verhalten von SNE zeigt den potentiellen Anwendern demonstriert werden kann Die potentiellen Anwender sind die Banken die bereits das existierende SWIFT System im Einsatz haben Benutzte Werkzeuge Es wurde entschieden Smalltalk VPM der Firma Digitalk unter OS 2 mit Presentation Manager auf einem PC einzusetzen Die Entscheidung f r Smalltalk VPM hatte folgende Gr nde e SNE sollte objektorientiert implementiert werden e Diese Version erlaubt Oberfl chen nach den CUA91 Regeln Common User Access zu erstellen Die Einhaltung dieser Regeln war eine Anforderung die mit Smalltalk umgesetzt werden konnte e Smalltalk bietet mit dem Model View Controler Application
152. sung vom Prototyping von Benutzungsoberfl chen formuliert 2 1 Methodische Grundbegriffe Obwohl die Diskussion zum Thema Prototyping schon seit mehr als 10 Jahren mehr oder minder intensiv gef hrt wird k nnen wir einige konzeptionelle oder methodische Besonderheiten dieser Diskussion feststellen Da ist zun chst ein deutlicher Unterschied zwischen der europ ischen und der u s amerikanischen Interpretation der Prototyping Idee In Europa ist es kaum noch umstritten da Prototyping ein ad quates und gezielt eingesetzes Mittel zur Kommunikation und Kooperation zwischen Entwicklern und den anderen beteiligten Gruppen vor allem den Benutzern darstellt Dagegen gehen die Interessen in den Vereinigten Staaten in eine ganz andere Richtung die auch durch den dort h ufig verwendeten Begriff Rapid Prototyping angedeutet wird die m glichst rasche Konstruktion einer lauff higen Softwareversion Dies hat allerdings zur Folge da die Nicht Entwickler nur selten in den R ckkopplungsproze mit einbezogen werden Hinter beiden Sichtweisen steht sicherlich das Bestreben nach mehr Softwarequalit t Unterschiedlich sind jedoch die mit Softwarequalit t verbundenen Merkmale In Europa stellen wir fest dafs Software nicht mehr nur nach den traditionellen quantitativen Merkmalen wie Ablaufeffizienz Speicherverbrauch und Fehlerfreiheit beurteilt werden Eher wird die Dualit t von anwendungsbezogener Funktionalit t und benutzungsorientierter Han
153. t z B mehrere Terminals auf dem Schreibtisch kommt vor allem der Nachteil zum Tragen da einmal eingegebene Daten nicht oder nur mit gro em Aufwand von anderen Informationssystemen weiterverarbeitet werden k nnen Ziel dieses Projektes war es Erkenntnisse ber die Gestaltung und Realisierung eines elektronischen Bankarbeitsplatzes zu gewinnen Dieser sollte so gestaltet sein da alle ben tigten Dienste B rofunktionen Hilfsmittel zur Kreditprotokollierung Auswertungen zur Berechnung der Kundenrentabilit t Zugriff zu aktuellen Kunden und Finanzmarktinformationen an einem einzigen Terminal und ber eine einheitliche Benutzungsoberfl che zug nglich sind Als Anwendungsgebiet wurde die T tigkeit eines Konzernbetreuers ausgew hlt An einem solchen Arbeitsplatz stehen zur Zeit noch vier verschiedene Terminals Zwischen den dort laufenden Anwendungen bestehen keine oder nur unbefriedigende tberg nge Am Projekt waren die k nftigen Benutzer die Entwickler und zu Review und Genehmigungszwecken auch der Auftraggeber beteiligt Die Gr nde f r die Entwicklung verschiedener Prototypen waren vielschichtig e Ein vorangehendes Projekt mit hnlicher Aufgabenstellung scheiterte mit dem Ansatz der systematischen Funktionsanalyse 4G System Projekte Enor Bookmark not defined e Es mu ten Verst ndigungsprobleme zwischen Benutzern und Entwicklern beseitigt werden die Oberfl che der verwendeten Werkzeuge waren den meisten Ben
154. t werden durch Prototyping einen guten und einfachen Zugang zum bestehenden Anwendungswissen zu erhalten Denn ohne dieses Fach wissen kann auch mit Hilfe von Prototyping keine fachlich hochwertige Anwendung erstellt werden Eine wichtige Voraussetzung f r einen effektiv gestalteten Lernproze ist allerdings eine m glichst gro e personelle Kontinuit t innerhalb des integrierten Entwicklungsteams Benutzerbeteiligung beim Prototyping innerhalb einer evolution ren Vorgehens weise kann nicht undifferenziert erfolgen Verschiedene Dimensionen sind zu ber cksichtigen Da ist wie gesagt zu unterscheiden ob das Softwareprojekt f r ein zugeschnittenes Anwendungssystem innerhalb einer Organisation geplant ist oder f r ein marktg ngiges Produkt Im ersten Fall steht der Kreis der potentiellen Ansprechpartner f r das Projektteam fest im zweiten Fall mu berlegt werden wer auf welche Weise als potentieller Anwender oder Benutzer angesprochen werden kann Die Vielfalt und Anzahl der beteiligten Gruppen ist ein weiterer Gesichtspunkt So macht beispielsweise eine kleine homogene Benutzergruppe kein eigenst ndiges Problem beim Prototyping dagegen erfordern dutzende von unterschiedlichen Benutzergruppen in verschiedenen Teil Organisationen eigene tberlegungen bezogen auf ihre Beteiligung an einem Prototyping Projekt Weitere Dimensionen der Beteiligung am Prototyping Proze sind z B die r umliche Verteilung der einzelnen Gruppen oder die A
155. t werden sollen In diesen F llen ist der Anschlu bei dem Botschaften an Objekte und fachliche Ereignisse verschickt werden am elegantesten Schlie lich ist mit Blick auf evolution res Prototyping die software technisch saubere Trennung von Oberfl chen und fachlicher Komponente von gro er Bedeutung da sonst nderungen an einer Komponente unmittelbare Auswirkungen auf die andere Komponente haben Enor Bookmark not defined Werkzeugeigenschaften 3 8 Weiterverwendung Das zuletzt angesprochene Kriterium der schrittweisen Weiterentwicklung eines Prototyps zum Zielsystem ist von so zentraler Bedeutung da wir die Prototyping Werkzeuge insgesamt unter dieses Kriterium einordnen wollen So k nnen beispielsweise Hypertext basierte Prototyping Werkzeuge praktisch nur innerhalb des produktbezogen explorativen Prototyping eingesetzt werden die mit ihnen erstellten Prototypen k nnen selten weiterverwendet werden Kann ein Prototyp weiterverwendet werden gibt es je nach Werkzeug die folgenden M glichkeiten wie er in das Zielsystem integriert werden kann e Der Prototyp kann evolution r mit demselben Werkzeug weiterentwickelt werden e Aus dem Prototyp wird mit Hilfe des Werkzeugs Programmtext generiert der bersetzt und mit dem Rest der Anwendung zusammengebunden wird e Eine Bibliothek wird zu den zus tzlich erstellten Anwendungskomponenten gebunden mit deren Hilfe der Oberfl chenprototyp zur Laufzeit interpretativ ausgef
156. te grafische Elemente charakterisiert sondern auch durch die Art und Weise wie sich diese Elemente verhalten und wie sie unter Verwendung der verf gbaren Eingabeger te gehandhabt werden k nnen Wenn Benutzer die Elemente einer Oberfl che interaktiv ver ndern oder beeinflussen k nnen sprechen wir von den Umgangsformen die eine Oberfl che erm glicht Dieses wird h ufig auch als das Feel einer Oberfl che bezeichnet Viele Oberfl chen z B zur Steuerung technischer Systeme enthalten aber auch Elemente die sich nicht durch Benutzeraktionen sondern durch Anwendungsprozesse ver ndern Sie zeigen in diesem Fall ein interaktives Verhalten Bei der Gestaltung einer interaktiven Oberfl che h ngen Darstellungsformen und Umgangsformen oder Verhalten immer eng zusammen Wir sprechen von einem Oberfl chenelement wenn wir die kleinste im Entwurf und in der Anwendung verf gbare Einheit meinen Ein Knopf ein Auswahlmen oder ein Fenster mit Rollbalken sind solche Oberfl chenelemente Gelegentlich ist es sinnvoll von Interaktionselementen als den interaktiven Einheiten und von passiven grafischen Elementen oder von Dekorationen als den nicht interaktiven Elementen zu sprechen In diesem Bericht behandeln wir aber vorrangig Interaktionselemente wie eine Men auswahl die als Umgangsform eine entsprechende Handhabung mit Maus Grundlagen Emor Bookmark not defined oder Tastatur bietet aber auch eine charakteristische Darstellungs und Rti
157. teikastens basiert Die Elemente eines Karteikastens sind Karten die Texte Grafiken oder andere Ober fl chenelemente enthalten k nnen Karten und ihre Elemente k nnen mit Hyper Links untereinander verbunden werden Mit einer Skriptsprache k nnen f r jede Komponente Event Handler implementiert werden Interface Builder Werkzeug mit dem Benutzungsoberfl chen auf hohem Abstraktionsniveau in textueller oder direkt manipulativer Form konstruiert werden k nnen Interface Builder unterst tzen die Definition von Oberfl chenelementen sowie deren Verhalten bei der Handhabung Laufzeitumgebung Erm glicht die in der Entwicklungsumgebung beschriebenen Benutzungsoberfl chen darzustellen und die fachliche Komponente auszuf hren Modifikationen an einer bestehenden Anwendung sind in der Laufzeitumgebung nicht m glich Enor Bookmark not defined Glossar Leitbild Grundlegende Idee oder Vorstellung die Anleitung gibt wie Gegenst nde bei der Analyse eines Anwendungsbereiches als relevant erkannt werden und wie das angestrebte System und die zuk nftigen Arbeitsformen aussehen k nnen Look amp Feel Darstellungs und Umgangsformen der Oberfl chenelementeeeines Fenstersystems modal multimodal modal Interaktionsform bei der der Benutzer aus einer Anzahl vorgegebener Aktionen ausw hlen mu z B OK oder CANCEL Knopf w hlen bevor das System weitere Interaktion erm glicht In multimodalen Benutzungsoberfl chen kann der Be
158. teiligten Gruppen wobei die Rollentrennung in Anbieter und K ufer im Vordergrund stand Dazu kam da die Anwender Grenzen und M glichkeiten des neuen Systems noch nicht einsch tzen konnten und oft zu detaillierte Forderungen stellten ein neuer Prototyp f r jeden m glichen neuen Knopf Mit dem gegenseitig wachsenden Verst ndnis nderte sich dieses Verh ltnis der Gruppen zueinander Heute besteht der Eindruck eines integrierten Teams mit unterschiedlichen Qualifikationen und Aufgaben Die Benutzer f hlen sich voll in den Entwicklungsproze einbezogen und identifizieren sich mit dem System Zudem werden neue Anforderungen an das PuV System auf der Anwenderseite heute genauer auf ihre N tzlichkeit untersucht Obwohl die letztliche Entscheidung ber Entwurfsalternativen beim Anwendermanagement liegt stellen sich in der Diskussion ber solche Alternativen anhand von Prototypen die Forderungen der Benutzer meist als berzeugend heraus Die Entwickler stellten fest da nach ca einem Jahr verst rkt konstruktive Vorschl ge von der Benutzerseite kamen Es war aber auch festzustellen da in der reinen Prototyping Phase Systemteile gefordert wurden die dann im Piloteinsatz nicht verwendet wurden Insgesamt verlief der Proze von der anf nglichen Diskussion der Handhabung und Funktionalit t zur Diskussion des Datenmodells und der geeigneten Pr sentation durch die Oberfl che wobei dies nat rlich eng mit der Funktionalit t gekopp
159. tiert werden Entwurfsmetaphem In den letzten Jahren hat die Diskussion um Entwurfsmetaphern im Software Engineering eine wachsende Bedeutung gewonnen Dahinter steht die Einsicht da Entwufsmethoden und Entwicklungswerkzeuge noch keine Anleitung geben wie ein Anwendungssystem konkret gestaltet werden soll Wir stellen immer wieder fest da den Entwicklern trotz methodischen Wissens und vorhandener Werkzeuge eine Orientierung fehlt die ihnen eine Grundlage f r Entwurfsentscheidungen und eine Vision des zuk nftigen Systems gibt Eine solche orientierende Vision f r die Gestaltung eines Systems nennen wir Leitbild z B das papierlose B ro oder die gutsortierte Werkbank Ein Leitbild wird durch plastische bildhafte Entwurfsmetaphern z B der elektronische Karteikasten erst wirklich umsetzbar Untersuchungen Maa 92 haben gezeigt da in vielen erfolgreichen Software Systemen Entwurfsmetaphern eingegangen sind Wir wollen in diesem Bericht keine eigene Diskussion ber Entwurfsmetaphern f hren Aber an den Stellen wo es sich anbietet werden wir darauf hinweisen welche Entwurfsmetaphern hinter den von uns untersuchten Werkzeugen stehen Denn diese Entwurfsmetaphern geben einen guten Eindruck vom Einsatzschwerpunkt eines Werkzeugs und sie helfen geeignet mit den Werkzeugen umzugehen Werkzeugeigenschaften Error Bookmark not defined Kapitel 3 Werkzeuge zum Oberfl chen Prototyping In diesem Kapitel diskutier
160. tionalit t direkt manipulativer Werkzeuge sehr breit ist untersuchen wir im weiteren folgende Anforderungen Der Entwickler mu unterst tzt werden wenn er Oberfl chenelemente relativ zu anderen Elementen positionieren will e Da es oft m hsam ist Oberfl chenelemente absolut zu positionieren mu das Werkzeug dies erleichtern Sinnvolle Unterst tzungsmechanismen sind Ein Raster das verhindert da Oberfl chenelemente gegeneinander nur um wenige Bildpunkte verschoben sind Explizites Gruppieren der Oberfl chenelemente wobei definiert werden kann wie die Elemente untereinander ausgerichtet werden sollen Hierarchischer Aufbau der Oberflachenelemente wobei das tibergeordnete Element festlegt wie die von ihm eingeschlossenen Elemente positioniert werden Mit dem Werkzeug mu definiert werden k nnen wie sich die Oberfl chen elemente verhalten sollen wenn sich die Gr e des Fensters ndert das die Benutzungsoberfl che begrenzt Werkzeugeigenschaften Error Bookmark not defined 3 2 Funktionalit t der Oberfl chenelemente Werkzeuge zum Prototyping von Oberfl chen k nnen dahingehend unterschieden werden welche Arten von Oberfl chenelementen vom Entwickler verwendet werden k nnen und ob die Menge der angebotenen Oberfl chenelementarten erweitert werden kann Praktisch alle Werkzeuge bieten die Elementarten Textfeld Texteditor Men und Druckknopf an Komplexere Oberfl chenelemente sind beis
161. totypen sind mit vertretbarem Aufwand nur in einer interpretativen Hochsprache sinnvoll d h einer Sprache die die unmittelbare Ausf hrung kleiner Konstruktionseinheiten Prozeduren Enor Bookmark not defined Grundlagen Funktionen erlaubt Die Konstruktion einer interaktiven grafischen Oberfl che mu auf jeden Fall durch vorgefertigte Bausteine und Anschl sse an bestehende Fenstersysteme unterst tzt werden Steht f r das Prototyping eine Entwicklungsumgebung zur Verf gung mit der interaktive Software schnell durch Generatoren und Bausteinsammlungen konstruiert werden kann so kommt der Auswahl der Zielsprache nicht mehr die vorrangige Bedeutung zu da diese oft von der Entwicklungsumgebung generiert wird Bezogen auf unser Thema bleibt die Frage nach dem Leistungsumfang und der Beherrschbarkeit der vorgefertigten interaktiven Komponenten Wir untersuchen entsprechend in welchem Umfang Benutzungsoberfl chen flexibel gestaltet werden k nnen und welche vorgefertigten Bausteine die Werkzeuge f r die Oberfl chenentwicklung anbieten Eng damit verbunden ist die Frage nach dem Aufwand mit dem eine Benutzungsoberfl che entwickelt werden kann und wie aufwendig es ist diese zu modifizieren Und schlie lich betrachten wir wie eine Oberfl che mit den anderen Teilen eines Softwaresystems verbunden werden kann Mit Blick auf die von uns f r sinnvoll gehaltenen zyklischen Entwicklungsprozesse k nnen f r die jeweiligen Werkzeuge zum Bau
162. totypen zu entwickeln Intermedia SuperCard EI und Windows 4GL Mit Ausnahme von Intermedia wurden alle bestimmungsgem eingesetzt Mit den drei erstgenannten Werkzeugen wurden Prototypen zur Konzeptkl rung erstellt Wichtig war dabei die M glichkeit die Oberfl che und ihr interaktives Verhalten schnell zu implementieren so da sie als Grundlage f r die Diskussion mit den Benutzern dienen konnte Zur Erstellung des Pilotsystems wurde Windows 4GL verwendet Auch hier k nnen Oberfl chen schnell und komfortabel entwickelt werden Ein schnelles Wechseln vom Entwicklungs in den Ausf hrungsmodus sowie die 4G System Projekte Enor Bookmark not defined Unterst tzung der Teamarbeit durch eine entsprechende Versionenverwaltung beg nstigen den Einsatz von Windows 4GL zum Prototyping Die integrierte 4GL erm glicht es auch komplexe Codest cke zu strukturieren und damit gut wartbare Software zu entwickeln Hervorzuheben ist an diesem Projekt da das Ziel eine gemeinsame Benutzungsoberfl che f r bereits bestehende Anwendungen zu entwickeln nur erreicht werden konnte indem entgegen der urspr nglichen Absicht eine komplette Anwendung d h Benutzungsoberfl che einschlie lich der zugeh rigen fachlichen Komponenten entwickelt wurde 5 3 3 Auswertung der Werkzeuggruppe Bei den hier betrachteten Projekten wurden Prototypen entwickelt weil neue Entwicklungsumgebungen eingef hrt wurden Die Auswertung der untersuchten
163. totyping produktbezogen Es bedeutet die kontinuierliche Weiterentwicklung eines Prototyps bis zum Zielsystem Je nach gew hlter Strategie kann dies den horizontalen oder vertikalen Ausbau oder die Erweiterung von relativ selbst ndigen Prototyp komponenten in einem Anwendungsrahmen bedeuten Evolution res Prototyping wird meist funktionale Prototypen und Pilotsysteme zum Gegenstand haben Wenn wir in dieser Studie die Begriffe explorativ experimentell und evolution r ohne weitere Qualifikation gebrauchen dann beziehen wir uns auf die proze orientierte Interpretation wollen wir die produktbezogene Sicht in den Mittelpunkt stellen machen wir dies ausdr cklich klar In der Praxis der Software Entwicklung finden wir spezifische Auspr gungen dieser Arten des Prototyping je nachdem ob ein Standardprodukt f r einen mehr oder minder anonymen Markt oder ob ein zugeschnittenes Anwendungssystem entwickelt werden soll 2 1 5 Arten von Prototypen W hrend die Arten des Prototyping sich auf Fragestellungen beziehen die im Prototyping Proze aufkommen richtet sich die Einteilung nach Prototyparten auf die Gestaltung eines Prototyps im Sinne eines Produktes dieses Entwicklungsprozesses Wir unterscheiden folgende Arten von Prototypen e Ein Demonstrationsprototyp zeigt nur die prinzipiellen Einsatzm glichkeiten meist nur die m glichen Handhabungsformen des k nftigen Systems Demonstrationsprototypen dienen besonders in der Start oder A
164. tzungsoberfl che zu gestalten wurden keine Designer oder Grafiker eingesetzt Zu einem sp teren Zeitpunkt wurde die Benutzungsoberfl che durch einen Spezialisten aus der Filmbranche bewertet Von ihm kamen Anregungen um Emor Bookmark not defined Interface Builder Projekte die Benutzungsoberfl che besser aufzubauen Insbesondere sollten nicht alle Informationen zu einem Zeitpunkt sichtbar sein und es sollte auf berlappende Fenster verzichtet werden Die nderungsvorschl ge wurden daraufhin in den Prototyp eingearbeitet Die Arbeiten am ersten Prototyp wurden im September 1992 vorl ufig abgeschlossen Bis dahin hatte der Prototyp eine solche Qualit t erreicht da er zu verschiedenen Anl ssen pr sentiert werden konnte Der Aufwand betrug ca zwei Personenjahre Die konstruierten Prototypen Die einzelnen vorgesehenen Medien Textdokumente Videobilder einfache Grafiken Bilder Audio und 3D Grafik wurden nacheinander in den Prototyp integriert In vorbereitende Arbeiten wie das Bespielen einer Bildplatte wurde viel Zeit investiert Der Entwicklungsflu wurde im wesentlichen durch technische Schwierigkeiten behindert Beispielsweise mu te SX Tools f r die Realisierung des Prototyps auf eine andere Hardware Plattform portiert werden SX Tools war zum damaligen Zeitpunkt noch unvollst ndig sowie auch durch die notwendige Portierung bedingt instabil und wurde weiterentwickelt Ein Videoboard mit dem die Videos in die Anwen
165. uch kommu nikativen Grundlage nicht konvergieren d h da in den auswertenden Diskussionen mit den Benutzern immer neue und andere Anforderungen aufkommen Dies ist ein deutliches Zeichen da keine gemeinsame Basis f r ein Softwareprojekt vorhanden ist wir weisen nochmals auf unsere Anmerkungen zu einer neuen Projektkultur hin Zum zweiten k nnen neue Werkzeuge auch als Argument f r das DV Management gelten sich nicht mit grunds tzlichen Problemen der Anwendungsentwicklung auseinanderzusetzen Auch hier sehen wir eine Mitschuld von Werkzeuganbietern und einigen Beratungsunternehmen die den Eindruck erwecken durch Werkzeugeinsatz lie en sich unter Beibehaltung der traditionellen Vorgehens und Sichtweise grundlegende Probleme meistern Kennzeichen dieser Problemlage sind v llig illusion re Terminplanungen unter besonderer Vernachl ssigung einer ausreichenden Analyse des Anwendungs bereichs Dazu kommt oft eine personelle Unterdeckung des Projekts Dies alles geschieht mit dem Hinweis auf die zu erwartende ungeheure Effizienz des neuen Werkzeugs Dabei wird gelegentlich sogar auf eine eigene Einarbeitungsphase f r ein solches Werkzeug verzichtet da dies ja f r die einfache Anwendung beim Rapid Prototyping gedacht sei 6 4 2 Auswirkungen auf den Proze Viele Werkzeuge zur Obenfl chenentwicklung haben Auswirkungen auf den Entwicklungsproze weit jenseits der Konstruktion eines Oberflachenprototyps Besonders 4G Systeme leg
166. uf hoher Abstraktionsebene spezifiziert wird Die Nachteile sind der syntaktische Aufwand f r den Ereignismechnismus der relativ gro ist falls die jeweilige Ereignisbehandlung nur aus wenig Programmtext besteht Weiterhin kann die grafische Art der Spezifikation bei komplexen Benutzungsoberfl chen un bersichtlich werden Werkzeugeigenschaften Error Bookmark not defined 3 7 5 Zusammenfassende Wertung Mit Blick auf Prototyping und die software technischen Anforderungen an die sp teren Anwendungssysteme stellt sich bei den beschriebenen Ans tzen die Frage wie weit die Ereignisbehandlung von der Zuordnung zu Oberfl chenelementen entkoppelt wird W hrend die reine Verwendung von Skriptsprachen ganz darauf verzichtet lassen sich mit den anderen Mechanismen unterschiedliche Formen der Trennung realisieren Eine M glichkeit sind die zeichenbasierten Protokolle die zwar Oberfl chenkomponente und fachliche Komponente entkoppeln aber den Austausch zwischen ihnen auf ein software technisch sehr fragw rdiges Zeichenkettenprotokoll reduzieren Eine andere M glichkeit bieten Callbacks oder Botschaften wenn dabei Oberfl chenelemente aufgrund von Ereignissen direkt Operationen der fachlichen Komponente rufen Dieser Ansatz bietet aber oft keine software technisch saubere Trennung der Komponenten und ist f r komplexe Anwendungen ungeeignet Schlie lich kann mit Hilfe von Callbacks oder Nachrichten die Trennung noch so verallgemeinert werden da
167. ung in reaktiven Systemen vergl 2 3 1 Bei dieser Anbindungsart wird die Ereignisbehandlung einschie lich der fachlichen Komponente in die Oberfl chenkomponente integriert Mit dem Prototyping Werkzeug werden einzelnen Oberfl chenelementen oder einer ganzen Oberfl che Programmst cke zugeordnet die in der Regel in einer Skriptsprache formuliert sind Werkzeugeigenschaften Error Bookmark not defined Diese Programmst cke werden interpretiert wenn ein Ereignis eintritt das auf das entsprechende Oberfl chenelement zutrifft Was bei dieser Art von Ereignisbehandlung zusammenkommt ist die Verwendung einer Skriptsprache einerseits und die Aufteilung der fachlichen Komponente auf die einzelnen Oberfl chenelemente Der Vorteil Funktionalit t so anzubinden besteht darin da die Programmteile zur Behandlung von Ereignissen die von der Oberfl che kommen direkt bei den Oberfl chenelementen untergebracht sind Die entsprechenden Bausteine die Oberfl chenkomponente und die Ereignisbehandlung sind eng gekoppelt Die Programmtexte k nnen einfach verwaltet werden und soweit sich die Funktionalit t unmittelbar auf Ereignisse einzelner Oberfl chenelemente bezieht kann sie ohne gro en Aufwand programmiert werden Der Nachteil ist da die verwendeten Sprachen meist keine h heren Strukturierungs m glichkeiten im Sinne von Modulen oder Klassen anbieten Dadurch werden Programme zur Behandlung komplexer Abl ufe m hsam und un bersi
168. utzern unbekannt e Die Ideen und Visionen der Entwickler mu ten schnell umgesetzt werden k nnen so da sie von den Benutzern beurteilt werden k nnen e Daes sich um ein Innovationsprojekt handelt und das gesamte Vorgehen neu war sollte auch das vorl ufige Endprodukt das Pilotsystem mit Prototyping Ans tzen entwickelt werden Die Prototypen wurden in den verschiedenen Projektphasen entsprechend ihrer Zielsetzung mit einem jeweils passenden Werkzeug entwickelt Das Ziel des Auftraggebers war eine gemeinsame Benutzungsoberfl che f r eine gr ere Anzahl bestehender Anwendungen entwickeln zu lassen Im Laufe der Projektplanung und durch Diskussion mit den Entwicklern entschlo man sich jedoch da nur ein komplettes Produkt d h Benutzungsoberfl che und die zugeh rige Funktionalit t die gestellte Aufgabe befriedigend l sen kann Benutzte Werkzeuge Neben fachlichen L sungen sollte das Projekt auch dazu dienen Erfahrungen mit verschiedenen Prototyping Werkzeugen zu gewinnen So kamen f r die ersten Prototypen die Werkzeuge Intermedia SuperCard und ET zum Einsatz Weitere Entwicklungswerkzeuge waren DB Designer und DEFT zur Erstellung von Entity Relationship Diagrammen und des Data Dictionaries Das Pilotsystem wurde mit Windows 4GL von Ingres unter UNIX entwickelt tber externe Schnittstellen sind folgende Informationsdienste und Werkzeuge zug nglich e X Desktop e Framemaker zur Textverarbeitung e
169. verbunden werden k nnen Dadurch ist es m glichh auch komplexe Datenstrukturen zu verwalten z B relationale Datenmodelle Der Aufwand dazu ist aber wesentlich gr er als wenn Werkzeuge eingesetzt wird die das relationale Modell direkt unterst tzen 3 6 Ausf hrbarkeit Es gibt drei Arten um Oberfl chenprototypen auszuf hren e Die Oberfl chenkomponente und die fachliche Komponente sind jederzeit inter pretativ ausf hrbar e Die Oberfl chenkomponente ist jederzeit interpretativ ausf hrbar die fachliche Komponente mu jedoch selbst ndig bersetzt und zur Oberfl chenkomponente gebunden werden e Aus der Oberflachenbeschreibung mu Code generiert werden der dann zusammen mit der fachlichen Komponente bersetzt und zu einem ausf hrbaren Programm gebunden wird F r exploratives Oberfl chen Prototyping ist die erste Ausf hrungsart am besten geeignet da sie erlaubt den Prototyp jederzeit ohne zeitraubende Vorbereitungen auszuf hren 3 7 Anbindung der Funktionalit t Es gibt eine gro e Vielfalt wie die fachliche Komponente an einen Oberfl chen Prototyp angebunden werden kann Die verschiedenen Anbindungsarten lassen sich grob in die folgenden Kategorien einteilen e Ereignisbehandlung mit einer interpretativen Sprache zeichenkettenbasiertes Protokoll Callbacks Versenden von Botschaften 3 7 1 Ereignisbehandlung mit einer Skriptsprache Das grundlegende Schema hierf r ist die Ereignisbehandl
170. ware Haus das ein Angebot einreichen wollte verf gte nicht ber das n tige Wissen um Oberfl chenprototypen herzustellen Es suchte deshalb nach einem Kooperationspartner der diesen Teil bernehmen sollte Als Partner wurde eine Abteilung an einer Hochschule gefunden die sich speziell mit Software Ergonomie der Gestaltung von Benutzungsoberfl chen und Prototyping besch ftigt Ziel der Kooperation war einen Funktionsprototyp zu entwickeln der die gesamten Anforderungen die in der Ausschreibung aufgef hrt waren erf llen sollte Das Projekt wurde zu 50 vom Software Haus und zu 50 durch ffentliche Forschungsmittel finanziert Benutzte Werkzeuge Das Software Prototyping von Hardware erfordert eine sehr flexible Gestaltung von Benutzungsoberfl chen Deshalb entschied sich das Team f r SuperCard ein HyperCard artiges Werkzeug das bei der Gestaltung von Benutzungsoberfl chen weitgehende Freiheit bietet Neben SuperCard wurden in der Anfangsphase verschiedene Interface Builder mit Blick auf die dort vorgegeben M glichkeiten Benutzungsoberfl chenarten zu erstellen evaluiert Enor Bookmark not defined HyperCard Projekte Daneben wurde in einer klassischen imperativen Programmiersprache eine einfache Datenbank entwickelt Es wurde spezielle Hardware eingesetzt um ausgew hlte Aspekte wie das Drucken von Fahrscheinen realistisch modellieren zu k nnen Der Entwic klungsproze Phase I Analyse des Anwendungsgebiets u
171. wesentlich problemloser da er in seiner Struktur dem Interace Builder von NeXT sehr hnlich ist Er unterst tzt somit nicht nur den Bau der Benutzungsoberfl che sondern auch die Konstruktion der fachlichen Komponente Die Einarbeitung wurde ebenfalls als relativ einfach bezeichnet Durch die deutliche Trennung von Prototyping Werkzeug in Smalltalk und Zielsystem Umgebung in C gab es keine Probleme mit der potentiellen Weiterverwendung von Demonstrationsprototypen dies stand nie zur Diskussion Problematisch war aus Sicht der Entwickler nur der h here Funktionsumfang von PARTS gegen ber der CommonView Bibliothek Da PARTS auch von Nicht Entwicklern im Team eingesetzt wurde bestand die Gefahr da Oberfl chenprototypen mehr an Handhabung zeigten als hinterher umzusetzen war Die Verwendung von PARTS um Systemvisionen d h Entwurfsdokumente zu erstellen wurde als etwas aufwendig aber gegen ber anderen M glichkeiten als befriedigend eingesch tzt So konnten in diesen Dokumenten nicht nur Textbeschreibungen sondern auch gute grafische Entw rfe der Oberfl chen k nftiger Prototypen dargestellt werden Unsere Einsch tzung Die beiden in diesem Bankenprojekt eingesetzten Interface Builder repr sentieren das Spektrum dessen was heute g ngig in industriellen Entwicklungsprojekten eingesetzt wird Beide Systeme erlauben im vorgegebenen Rahmen Oberfl chenlayouts zu gestalten und diese mit elementaren Handhabungsformen zu ver
172. wickler der sp ter den Prototyp in das Anwendungssystem umsetzen soll mu auch beim Prototyping beteiligt sein Die Erfahrungen mit dem Werkzeug SuperCard wurden als durchweg positiv bezeichnet Als einziger negativer Aspekt wurde die nicht ganz befriedigende Laufzeiteffizienz w hrend des Feldversuchs genannt Unsere Einsch tzung An diesem Projekt lassen sich unterschiedliche Aspekte des Prototyping von Benutzungsoberfl chen aufzeigen e Offensichtlich ist da ein reines Oberfl chen Prototyping d h die Beurteilung einer funktionslosen Oberfl che keine verwertbaren Aussagen erbringt Prototyping mit unterschiedlichen Werkzeugen ist dann sinnvoll wenn ein gro er Spielraum f r die Systemgestaltung besteht wenn also neue Ideen generiert werden m ssen e Die Integration von Experten unterschiedlicher Fachrichtung in ein Team gelingt wenn die Werkzeugunterst tzung ihre aktive Mitarbeit erm glicht e HyperCard artige Werkzeuge lassen sich au er zur reinen Oberfl chen gestaltung dann gut zum Prototyping einsetzen wenn der Prototyp nicht software technische Grundlage des Zielsystems sein mu e Prototyping ohne eine sorgf ltige Planung der Rtickkopplungs und Bewertungsprozesse f hrt nicht zu optimalen Ergebnissen da die gewonnenen Erfahrungen entweder nicht in revidierte Prototypen oder das Zielsystem einflie en oder der Lernproze aller beteiligten Gruppen unterbrochen wird 5 1 3 Auswertung der Werkzeuggrupp
173. zt werden um eine QS Sitzung des Systems vorzubereiten Dies war unter Einsatz der herk mmlichen Methoden bis jetzt sehr zeitintensiv Die mit Hilfe des Systems modellierten Baugruppen oder Teilsysteme sollten so gestaltet sein da sie in sp teren gr eren Systemen jederzeit wiederverwendet werden k nnen Ein weiterer Gedanke ist das erstellte Modell des Systems als Spezifikation f r den sp teren Entwicklungsproze zu verwenden Diese Idee wurde Abteilungen innerhalb der Firma unterbreitet um interne Auftraggeber zu finden die das Projekt finanzieren Eine Abteilung aus dem Bereich Qualit tssicherung zeigte Interesse an der Idee Sie erkl rte sich bereit das Projekt f r die Dauer eines Jahres zu finanzieren tber die weitere Finanzierung des Projekts sollte dann in einem Jahresrhythmus entschieden werden Prototyping wurde aus folgenden Gr nden f r die gesamte Systementwicklung vorgesehen e Innerhalb der Entwicklungsmannschaft waren keine Erfahrungen auf dem Gebiet der Qualit tssicherung speziell Fehler und Signalflu analyse von mechatronische Schaltungen vorhanden e Zu Beginn des Projekts konnten aus den entsprechenden Abteilungen der Qualit tssicherung keine Mitarbeiter integriert werden e Es konnte keine detaillierte Spezifikation des gew nschten Systems erstellt werden Benutzte Werkzeuge Das zu entwickelnde System sollte nach Ansicht der Forschungsabteilung ber eine einheitliche grafische Benutzungsob

Prototyping

Contents

Download Pdf Manuals

Related Search

Related Contents