Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering

Größe: px

Ab Seite anzeigen:

Download "Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12."

Anke Kneller
vor 8 Jahren
Abrufe

1 Talk im Schloss Zusammenbringen was zusammen gehört Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering F.Riemenschneider

erfolgreiches Usability Engineering 10.12.2007 F.

2 Inhalt Problemstellung Beispiel für ungünstigen Project Lifecycle Besserer Project Lifecycle 2

3 Der Usability Engineering Prozess Analyse Nutzungskontext Prüfung Entwicklung von Nutzungsanforderungen Prototypisches Design 3

4 Geht das irgendwie zusammen? Usability Engineering Prozess Fachkonzept Analyse Nutzungskontext? Entwicklung von Prüfung Nutzungsanforderungen DV-Konzept Implementierung Test Prototypisches Design Einführung Softwareentwicklung nach "Wasserfall"-Modell 4

5 Oder eher das? Usability Engineering Prozess Iterationsplanung Implementierung Analyse Nutzungskontext? Entwicklung von Prüfung Nutzungsanforderungen Review Prototypisches Design Einführung Agile Softwareentwicklung 5

6 Software Project Lifecycle Die richtige Frage lautet nicht: "Gestalte ich das Projekt nach Wasserfall oder agil?" Die richtige Frage ist vielmehr: "Wie sieht ein individueller Software Project Lifecycle aus, der zu meinen Rahmenbedingungen passt?" 6

" Die richtige Frage ist vielmehr: "Wie sieht ein

7 Beispiel Projekt für Finanzverwaltung Antrag auf Stundung oder Erlass erfassen Entscheidung bearbeiten Bescheid drucken 7

8 Beispiel Projekt für Finanzverwaltung Projektrahmen Bestehende technische + fachliche(!) Frameworks Umfang scheinbar festgelegt (aber nicht definiert) Fixer Termin, fixes Budget Vorgehen nach V-Modell (leicht angepasst, aber im Grunde ein Wasserfall) 8

) Frameworks Umfang scheinbar festgelegt (aber nicht

9 Zeitlicher Ablauf Konzeption der Geschäftsprozesse durch Steuerfachleute nach AO und anderen Verfahrensanweisungen. Erstellung und Versand von Oberflächenscreenshots in Powerpoint. Abstimmung mit Sachbearbeitern an zwei großen Besprechungsterminen. Spezifikation des Systems. Entwicklung und Vorstellung der ersten Ergebnisse 9

Erstellung und Versand von Oberflächenscreenshots in Powerpoint.

10 Schmerzliche Erkenntnisse Fachwissen war im Projekt nur scheinbar vorhanden. Bearbeiter/Auftraggeber waren bzgl. Fachlichkeit selbst unsicher. Lösungen in Frameworks z.t. nicht dem Problem angemessen. Oberflächen im Gebrauch ineffizient bis ineffektiv. 10

Fachlichkeit selbst unsicher. Lösungen in Frameworks z.t. nicht dem Problem angemessen.

11 Konsequenzen Review der Oberfläche ergibt umfangreichen Änderungsbedarf. Neukonzeption Neue Realisierung der Oberflächen Budget gesprengt. Beim Versuch, den Termin zu halten, wurden viele Defekte eingebaut. Notwendige Stabilisierung führt zu deutlicher Terminverschiebung. Die Neukonzeption hat sich trotzdem gelohnt. Heute ist die Software im Land Niedersachsen im Einsatz. 11

Beim Versuch, den Termin zu halten, wurden viele Defekte eingebaut.

12 Beispiel für Effizienzgewinn vorher nachher 12

13 Lehren 1 Rahmenbedingungen analysieren ( Risikoanalyse) 2 Project Lifecycle festlegen! 3 Feedback-Schleifen einbauen, um den Kurs anpassen zu können. 13

14 Fragen zu Rahmenbedingungen Frage Wie kritisch ist die Gebrauchstauglichkeit für den Projekterfolg? Antwort Besitzt das Projekt echtes, aktuelles Fachwissen von Benutzern? Was ist tatsächlich fix? Umfang, Termin, Kosten? Gibt es mögliche Lieferstufen? Wieviel Agilität lässt das Umfeld zu (Projektmitarbeiter, Stakeholder, Betrieb, QM, Architektur, )? Wieviel Übung besitzt das Projektteam in diesem Umfeld? 14

Umfang, Termin, Kosten? Gibt es mögliche Lieferstufen?

15 Sinnvolle Feedback-Schleifen Benutzungstests! Pflege der Beziehung zu Stakeholdern (insbesondere Benutzergruppen). Change-Prozess etablieren. Ist-Kosten für Herstellung sammeln. Qualität (#Bugs) früh messen. 15

Benutzergruppen). Change-Prozess etablieren.

16 Rahmenbedingungen Beispiel Projekt Frage Wie kritisch ist die Gebrauchstauglichkeit für den Projekterfolg? Besitzt das Projekt echtes, aktuelles Fachwissen von Benutzern? Was ist tatsächlich fix? Umfang, Termin, Kosten? Gibt es mögliche Lieferstufen? Antwort Sehr kritisch. Nein, nicht ausreichend. Umfang angeblich, Termin politisch gewünscht, Budget fix. Nicht erwünscht. Wieviel Agilität lässt das Umfeld zu (Projektmitarbeiter, Stakeholder, Betrieb, QM, Architektur, )? Wieviel Übung besitzt das Projektteam in diesem Umfeld? Kaum Spielraum. Keine. 16

Gibt es mögliche Lieferstufen? Antwort Sehr kritisch. Nein, nicht ausreichend. Umfang angeblich, Termin politisch gewünscht, Budget fix.

17 Passende Heuristiken (1/2) Zyklische Entwicklung eines Oberflächenprototypen zusammen mit Benutzern. Auf Build-to-Budget vorbereiten: Umfang ist Manövriermasse ( Req.+Change Management) Sinnvolle Lieferstufen stichwortartig formulieren. Konservativ die Featuremengen festlegen. 17

Auf Build-to-Budget vorbereiten: Umfang ist Manövriermasse ( Req.

18 Passende Heuristiken (2/2) Größere Implementierungszyklen (ca. 3-4 Monate) Grob planen. Mit Budget-Tracking steuern. Stabilisierung gegen Ende mittels Systemtest. Benutzungstests. Interne Meilensteine alle vier Wochen setzen. In diesen Abständen fein planen sowie Reviews von Qualität und Schätzgüte durchführen. 18

Stabilisierung gegen Ende mittels Systemtest. Benutzungstests.

19 Angemessener Project Lifecycle Analyse Nutzungskontext Prüfung Entwicklung von Nutzungsanforderungen Prototypisches Design 19

20 Software Architektur Entwurfsprinzip: Design-for-Change "Was sich stark ändern kann, sollte gekapselt werden." User Interface benutzt Business Service Facade implementieren Dummy Domain Logic benutzt Database 20

21 Zusammenfassung Der Software Project Lifecycle muss an individuellen Rahmenbedingungen ausgerichtet werden. Wenn Usability ein kritischer Erfolgsfaktor ist, muss der Software Prozess beweglicher werden, um Prototypentwicklung und Berücksichtigung der Ergebnisse von Benutzungstests zu erlauben. Bewegliche Prozesse benötigen eine Software Architektur, die Bewegungsfreiheit bietet. Das erfordert sehr hochwertiges Design! 21

22 Vielen Dank für die Aufmerksamkeit! Fragen? Kontakt Falko Riemenschneider itemis AG Niederlassung Bonn Bundeskanzlerplatz Bonn 22

Ähnliche Dokumente

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee