1. Einleitung: Warum wird die Arbeit von Programmierern beobachtet?

1. Seminar „Komponenten“Programmierern über die Schulter gesehenFrederik BässmannFreie Universität Berlin, Institut für Informatikhttp://www.inf.fu-berlin.de/inst/ag-se/ Frederik Bässmann, baessman@inf.fu-berlin.de

2. Inhalt • 1. Einleitung: Warum wird die Arbeit von Programmierern beobachtet? • 1.1. Motivation von Entwicklungsstudien • 1.2. Studien in der Softwareentwicklung • 2. die Arbeit von Programmierern und Softwareentwicklern • 2.1. Ueberblick über die Arbeit von SEs und Programmierern • 2.2. Arbeitsumfeld am Beispiel einer Softwarefirma • 3. Studien von Entwicklungsprozessen: empirische, analytische und arbeitspraktische Ansätze • 3.1. Betrachtung von Entwicklungsarbeit • 3.2. Vergleich von empirischen und arbeitspraktischen Studien • 4. Vorbereitung und Organisation von Recherchen • 4.1. Planung der Recherche • 4.2. Statistik von Arbeitsschritten • 5. Vorgehensarten und Methoden bei Recherchen • 6. Auswertung • 6.1. Umgang mit gewonnenen Studiendaten • 6.2. Use Case Maps (UCMs) • 7. Von der Analyse zum Entwickler-Tool Frederik Bässmann, baessman@inf.fu-berlin.de

3. 1. Einleitung 1.1. Motivation von Entwicklungsstudien • Es handelt sich nicht um oberflächliche Reportagen sondern um einen wichtigen Bereich der Software-entwicklung • Durch die Beobachtung und Analyse der Arbeit von Softwareengineers (SEs) wird eine effizientere Arbeitsweise unterstützt • Es werden Erfahrungen gesammelt und Entwicklungsprozesse optimiert Frederik Bässmann, baessman@inf.fu-berlin.de

4. 1. Einleitung • Eines der Hauptziele ist die Vereinfachung der Arbeit von SEs -> Entwicklung von Tools zur Optimierung des Arbeitsprozesses • Untersuchung der Benutzerfreundlichkeit von Tools zur Verbesserung und einfacheren Handhabung derselben -> Recherechen der Arbeit von SEs werden so angelegt, dass eine spätere Auswertung der gewonnen Daten für diese Ziele möglich ist Frederik Bässmann, baessman@inf.fu-berlin.de

5. 1. Einleitung 1.2. Studien in der Softwareentwicklung • je grösser der Umfang der Beobachtungen, desto repräsentativer die Studie • oft können jedoch aus Zeit- und Aufwandsgründen nur einzelne Unternehmen betrachtet werden • Recherchen von Studien in der Softwareentwicklung müssen sorgfältig geplant und umgesetzt werden, um späteren Nutzen der Informationen zu gewährleisten Frederik Bässmann, baessman@inf.fu-berlin.de

6. 2. die Arbeit von Programmierern und SEs • 2.1. Überblick über die Arbeit von • SEs und Programmierern • ‘Programmierer’ ist nicht gleich ‘SE’ • SEs haben vielfältige Aufgaben, nicht nur ‘Coden’ • Programmierer sollten mehrere Programmier-sprachen beherrschen, mindestens eine professionell, haben oft geringere Graduierung • Softwareentwicklung besteht neben Codierung aus Planung, Organisation, Management usw., was von SEs ebenso gefordert wird wie Programmierkenntnisse Frederik Bässmann, baessman@inf.fu-berlin.de

7. 2. die Arbeit von Programmierern und SEs • Softwareentwickler müssen in der Lage sein, Projekte effizient umzusetzen: • Fähigkeiten von Mitarbeitern einschätzen • Gruppen von Entwicklern zusammenstellen • Planung den Arbeitsumständen anpassen und realistische Meilensteine setzen • für die Einhaltung der geplanten Teilziele sorgen, die den Vereinbarungen mit dem Auftraggeber entsprechen • > Management des gesamten Projekts • je mehr Erfahrung, desto mehr Verantwortung Frederik Bässmann, baessman@inf.fu-berlin.de

8. 2. die Arbeit von Programmierern und SEs 2.2. Arbeitsumfeld am Beispiel einer Softwarefirma • Hauptprojekt: ein umfangreiches Telekommunikationssystem • ist bereits seit den 80er Jahren in ständiger Entwicklung und Anpassung • mehrere Millionen Lines of Code, über 16000 einzelne Methoden in über 8000 Dateien • Projekt ist von existentieller Bedeutung für die Firma • bereits über 100 Personen waren an der Entwicklung beteiligt Frederik Bässmann, baessman@inf.fu-berlin.de

9. 2. die Arbeit von Programmierern und SEs • Mitarbeiter haben die Aufgabe, das System zu erhalten und zu erweitern • haben viel Handlungsfreiheit bei der Arbeit • permanente Kommunikation mit Kollegen, um Verständnis fremder Arbeit zu erlangen und zu vertiefen -> gegenseitige Beratung • dürfen hierzu zwischen dem eigenen und anderen Arbeitsplätzen pendeln • Freiheit bei der Wahl der eigenen Aufgaben aus TODO-Listen Frederik Bässmann, baessman@inf.fu-berlin.de

10. 3. Studien von Entwicklungsprozessen 3.1. Betrachtung von Entwicklungsarbeit • Recherchearbeit bildet die Grundlage für die spätere Toolentwicklung • grundlegender Einblick in die Arbeit der Entwickler ist notwendig • verschiedene Recherchevarianten: • analytische Studien (‘analytical Studies’) • empirische Studien (‘empirical Studies’) • arbeitspraktische Studien (‘Studies of Work Practices’) Frederik Bässmann, baessman@inf.fu-berlin.de

11. 3. Studien von Entwicklungsprozessen • analytische Studien • Erschliessung logischer Zusammenhänge durch Interpretation von gewonnenen Daten • empirische Studien (am häufigsten angewendet) • Herauskristallisierung von Mustern in den Daten, also Suche nach typischen Konstellationen • arbeitspraktische Studien • Sammlung möglichst umfangreicher Daten für möglichst repräsentative Statistik Frederik Bässmann, baessman@inf.fu-berlin.de

12. 3. Studien von Entwicklungsprozessen • die drei Dimensionen empirischer Studien: Quelle: Paper ‘Studies of the Work Practices of Software Engineers’ Frederik Bässmann, baessman@inf.fu-berlin.de

13. 3. Studien von Entwicklungsprozessen 3.2. Vergleich: empirische vs. arbeitspraktische Studien • durch empirische Studien kann ein guter Eindruck erarbeitet werden, aber Nachteile: • Umgebung meist künstlich (artificial environment), experimentelle Projekte • daher sind die Programmierer oft noch unerfahren, beispielsweise Studenten – haben andere Arbeitsge-wohnheiten • nicht immer realistische Arbeitsbedingungen, daher oftmals nicht repräsentativ genug (Labor) Frederik Bässmann, baessman@inf.fu-berlin.de

14. 3. Studien von Entwicklungsprozessen • arbeitspraktische Studien sind hauptsächlich statistisch orientiert, aber dafür weiträumiger angesetzt • Motivation: ein erkanntes Arbeitsmuster spiegelt nicht unbedingt Bedürfnisse hinsichtlich Tools wider • wichtiger: wie oft macht der Entwickler was? • welche Arbeitsschritte machen den meisten Aufwand? • daher sollten die Details der Arbeitsabläufe erfasst werden, nicht unbedingt immer bestimmte Abfolgen Frederik Bässmann, baessman@inf.fu-berlin.de

15. 3. Studien von Entwicklungsprozessen • arbeitspraktische Recherchen sollten in realen Umgebungen (natural work environment) durchgeführt werden • bessere Rückschlüsse auf die Notwendigkeiten der Beschaffenheit der Tools hinsichtlich der Arbeits-umgebung möglich • Tools müssen nicht nur gut handhabbar sein, sondern sich auch in Arbeitsumgebung einfügen • Entwickler müssen sich schnell mit neuen Tools vertraut machen können, daher Einblick in deren Gewohnheiten sinnvoll Frederik Bässmann, baessman@inf.fu-berlin.de

16. 3. Studien von Entwicklungsprozessen • Vorteile field study (Recherche in realem Umfeld): • reale Arbeitsbedingungen, ‘echtes’ Projekt, industrielle Grössenordungen • aber: Umstände sind auch nicht der Recherche anpassbar • Hindernisse im laufenden Betrieb, Mitarbeiter können keine Rücksicht auf Reporter nehmen • Recherche ist auf Gunst der Mitarbeiter angewiesen • manchmal keine Recherche möglich (Datenschutz, zu starke Eingebundenheit der Mitarbeiter…) Frederik Bässmann, baessman@inf.fu-berlin.de

17. 4. Vorbereitung und Organisation von Recherchen 4.1. Planung der Recherche • Durchführung einer arbeitspraktischen Studie • mehrere Möglichkeiten, Informationen zu sammeln: Fragebögen, Beobachtung (Observierung) • im Vorfeld abwägen, welche Möglichkeit wann am geeignetsten ist • Manager und Mitarbeiter konsultieren, die bereit sind, zu kooperieren Frederik Bässmann, baessman@inf.fu-berlin.de

18. 4. Vorbereitung und Organisation von Recherchen • Fragebogen: • wieviel Zeit und Aufwand für welche Aktivitäten? • Mitarbeiter können freiwillig Einträge vornehmen • aufgrund der ungezwungenen Teilnahme kann ernsthafte Bearbeitung angenommen werden • Betrachtung von einzelnen Mitarbeitern: • Beobachtung bis zu mehreren Monaten • Zeitabstände werden später grösser • Besprechung und Beobachtung bei den Meetings Frederik Bässmann, baessman@inf.fu-berlin.de

19. 4. Vorbereitung und Organisation von Recherchen • Betrachtung von Gruppen: • die Gruppenmitglieder fertigen Diagramme an, die ihr Verständnis des Systems darstellen • Interviews, wie Aufgaben und Probleme gelöst werden • Observierungen der Gruppen bei der Arbeit und Protokollierung ihrer Tätigkeiten • Mitarbeiter mit unterschiedlichen Arbeitsweisen und verschieden langer Erfahrung sinnvoll Frederik Bässmann, baessman@inf.fu-berlin.de

20. 4. Vorbereitung und Organisation von Recherchen • manche Arbeitsschritte können auch automatisch erfasst werden: • Verwendung von bestimmten Anwendungen kann regsitriert werden • Beispiel: Suchtools für Dateien und Inhalte, Editoren • Nachteil: Nutzungsdauer wird meist nicht miterfasst, ausserdem wird oft nur erster Aufruf registriert, da Anwendung geöffnet bleibt • bei automatischen Erfassungen auf Tätigkeiten verzichten, die ohnehin vom System ausgeführt werden, wie Kompilierungen Frederik Bässmann, baessman@inf.fu-berlin.de

21. 4. Vorbereitung und Organisation von Recherchen • Beobachtungen von SEs haben prinzipiell einschrän-kende Wirkung auf deren Arbeit • die ‘Belästigung’ der SEs so gering wie möglich halten • auch im Interesse der Authentizität der Studie, Ergebnisse werden sonst möglicherweise verfälscht • Beobachtungen in Stressphasen vermeiden, wie vor anstehenden Meilensteinen • möglichst nur freiwillige Mitarbeiter miteinbeziehen Frederik Bässmann, baessman@inf.fu-berlin.de

22. 4. Vorbereitung und Organisation von Recherchen 4.2. Statistik von Arbeitsschritten Fragebogen: Ereignisse in %: Quelle: Paper ‘An Examination of Software Engineering Work Practices’ Frederik Bässmann, baessman@inf.fu-berlin.de

23. 5. Vorgehensarten und Methoden bei Recherchen • nach den genannten grundlegenden Ansätzen nun zur Durchführung: • detaillierte Planung des genauen Vorgehens sowohl bei empirischen, als auch bei analytischen und arbeitspraktischen Studien notwendig • besonders bei empirischen Studien ist auf die Nachvollziehbarkeit der Zusammenhänge hinterher zu achten • Zweck und Ziele von Arbeitsschritten müssen später bei Auswertung noch erkennbar sein Frederik Bässmann, baessman@inf.fu-berlin.de

24. 5. Vorgehensarten und Methoden bei Recherchen • spez. Methode bei SE-Recherchen: Observierungen • Vorgehen: SE wird auf Schritt und Tritt begleitet (shadowing) • zwei Techniken zur Protokollierung: • Aufzeichnen der Arbeit auf Video • Vorteil: alle Informationen vorhanden • Nachteil: sehr zeitaufwändige Auswertung hinterher • manuell Notizen während der Arbeit aufnehmen • Vorteil: gezielte Protokollierung von wichtigen Schritten möglich, besser auszuwerten • Nachteil: Gefahr des Versäumens von Informationen bei schnellem Arbeitsablauf, Zeitpunkte schwerer erfassbar Frederik Bässmann, baessman@inf.fu-berlin.de

25. 5. Vorgehensarten und Methoden bei Recherchen • Alternative: synchronized shadowing, entwickelt von Lethbridge und Singer • Vorteile des Video- und des Notizverfahrens sollen in einem Verfahren vereint werden • Verwendung eines speziell entwickelten Programms zur schnellen Erfassung von einzelnen Arbeits-schritten • typische Tätigkeiten werden vorcodiert und im Programm für spätere Protokollierung hinterlegt • die Arbeitsschritte können nun per Tastendruck inclusive genauer Zeiterfassung protokolliert werden Frederik Bässmann, baessman@inf.fu-berlin.de

26. 5. Vorgehensarten und Methoden bei Recherchen • oberservierende Reporter Nutzen das Programm auf einem Notebook während der Observierung • zur umfangreicheren Informationsgewinnung wird die Observierung durch zwei Personen durchgeführt, daher ‘synchronized’ • kleiner Nachteil: Reaktionszeit der Recher-chierenden führt zu kleinen Verzögerungen, daher nicht ganz genaue Zeiterfassungen • Nachteil unterliegt den Vorteilen deutlich Frederik Bässmann, baessman@inf.fu-berlin.de

27. 5. Vorgehensarten und Methoden bei Recherchen • Protokoll einer Observierung mit synchronized shadowing: Quelle: Paper ‘Studies of the Work Practices of Software Engineers’ • die Tastenbelegung lässt sich sehr leicht durch Macros in Microsoft Word realisieren Frederik Bässmann, baessman@inf.fu-berlin.de

28. 6. Auswertung 6.1. Umgang mit gewonnenen Studiendaten • Auswertung generell knifflig, sehr zeitaufwändig • Daten müssen zunächst in Bereiche eingeteilt werden – Kategorisierung • auch hier verschiedene Ansätze: • Tätigkeiten können gezählt und ihre zeitliche Dauer insgesamt ermittelt werden (Statistik) • interessant bei grösseren Datenmengen aus verschiedenen Bereichen • aufschlussreich bei der Beobachtung von SEs oder Gruppen mit unterschiedlichen Aufgaben Frederik Bässmann, baessman@inf.fu-berlin.de

29. 6. Auswertung von gewonnenen Studiendaten • die gewonnenen Daten können auf Arbeitsmuster untersucht werden: • wann treten welche Schritte auf, welche wieder-kehrenden Abfolgen zeichnen sich ab? • welche zeitlichen Abstände liegen zwischen bestimmten Schritten? • bereits bekannte Arbeitsmuster werden in n-grams (kleine Teilprozesse) zerlegt, und nach diesen gezielt in den Daten gesucht • verschiedene Auswertungsmethoden können getrennt oder zusammen verwendet werden Frederik Bässmann, baessman@inf.fu-berlin.de

30. 6. Auswertung von gewonnenen Studiendaten 6.2. Use Case Maps (UCMs) • entwickelt von Buhr und Casselmann zur Darstellung von realtime – Prozessen, eignen sich auch zur Veranschaulichung von Arbeitsprozessen • Arbeitsprozess durchläuft Diagramm, durch eine Linie symbolisiert • Schritte werden aufsteigend nummeriert und durch die Linie verbunden • Schleifen, Verästelungen etc. darstellbar • Diagramm ist in Kontexte unterteilt, jeder Schritt in einem Kontext • können in weitere UCMs unterteilt werden Frederik Bässmann, baessman@inf.fu-berlin.de

31. 6. Auswertung von gewonnenen Studiendaten • Beispiel eines UCM-Diagramms: • modelliert wurde eine Suchanfrage über einen Editor • Pfeile symbolisieren Datentransferrichtung (User/System) • Uhr steht für Ver- zögerung Quelle: Paper ‘Studies of the Work Practices of Softwareengineers’ Frederik Bässmann, baessman@inf.fu-berlin.de

32. 7. Von der Analyse zum Tool • zunächst muss geklärt werden, welcher Bedarf an Arbeitshilfsmitteln besteht • Erkenntnisse aus Studien werden herangezogen • sowohl statistische als auch Arbeitstechnische Aspekte werden betrachtet • ein Beispiel: JITC (Just In Time Comprehension) ist eine Arbeitsweise erfahrener SEs: • man arbeitet sich zielgerichtet immer nur in gerade relevante Bereiche ein, etwa zur Optimierung und Ergänzung von Sourcecode Frederik Bässmann, baessman@inf.fu-berlin.de

33. 7. Von der Analyse zum Tool • Hintergrund: es kann nie alles von einer einzigen Person nachvollzogen werden können (16000 Methoden…) • es ist nicht möglich, den gesamten Quellcode zu kennen oder alle Zusammenhänge der Methoden • die Einarbeitung ist mit häufigen Suchanfragen verbunden • Notwendigkeit eines Suchtools erscheint gegeben • Klärung der Anforderungen an das Tool… • Funktionen müssen den Arbeitsprinzipien entsprechen, in diesem Fall JITC Frederik Bässmann, baessman@inf.fu-berlin.de

34. 7. Von der Analyse zum Tool • Tool muss sich ausserdem in die bereits vorandene Arbeitsumgebung einfügen lassen • darf bereits vorhandene Tools nicht beeinträ-chtigen, sollte Ergänzung darstellen • muss dem Entwickler ‘nützlich erscheinen’, sonst wird er sich nicht die Mühe machen, sich einzu-arbeiten • technische Leistung des Tools festlegen: • grosse Quellcodemengen sollen schnell durchsucht werden können • Sourcecode verschiedener Sprachen sollte erkannt werden • muss mit Systemen kompatibel sein Frederik Bässmann, baessman@inf.fu-berlin.de

35. 7. Von der Analyse zum Tool • Limite bereits bei der Planung abstecken: • Installationsmöglichkeit auf nur einem Betriebssystem oder bestimmten Rechnern akzeptabel • in unserem Beispiel muss keine Objektorientierung erkannt werden können, da es sich hauptsächlich um ein Suchtool handelt • Laufzeitabhängige Daten brauchen nicht berück-sichtig zu werden • durchdachtes Tooldesign ist wichtig hinsichtlich ‘Konkurrenztools’, dortige Schwächen berück-sichtigen und übertreffen Frederik Bässmann, baessman@inf.fu-berlin.de

36. 7. Von der Analyse zum Tool • Screenshot des ‘tksee’ - Tools Quelle: Paper ‘An Examination of Software Engineering Work Practices’ Frederik Bässmann, baessman@inf.fu-berlin.de

37. Zusammenfassung • Arbeit von Softwareentwicklern und Programmierern • Zweck von SE-Studien (Tools…) • empirische, analytische und arbeitspraktische Studien • Organisation und Durchführung von Studien • Auswertung gewonnener Informationen (UCMs) • Entwicklung von Tools auf Basis von Recherchen Frederik Bässmann, baessman@inf.fu-berlin.de

38. Literatur Paper “An Examination of Software Engineering Work Practices” von Janice Singer, Timothy Lethbridge, Norman Vinson, Nicolas Anquetil Paper “Studies of the Work Practices of Software Engineers” von Dr. Timothy Lethbridge, Dr. Janice Singer http://de.wikipedia.org/wiki/Softwareentwicklung Frederik Bässmann, baessman@inf.fu-berlin.de

39. Danke! Frederik Bässmann, baessman@inf.fu-berlin.de