Clashing Cultures. Wenn Software-Ingenieure auf Wissenschaftler treffen Seminarvortrag Beiträge SE

Größe: px

Ab Seite anzeigen:

Download "Clashing Cultures. Wenn Software-Ingenieure auf Wissenschaftler treffen Seminarvortrag Beiträge SE"

Stefanie Junge
vor 8 Jahren
Abrufe

1 Clashing Cultures Wenn Software-Ingenieure auf Wissenschaftler treffen Seminarvortrag Beiträge SE Andre Breitenfeld

2 Agenda 1. Thematische Einordnung 2. Scientific Software Development 3. Papers 1. Feldstudie 2. Fallstudie 4. Retrospektive 5. Zusammenfassung 2

3 Thematische Einordnung Scientific Software Development Softwareentwicklung im Rahmen von Forschungstätigkeiten Scientific Software: Software von und für Forscher Berührungspunkte mit End-User Development 3

4 Scientific Software Development Herausforderungen: Komplexe Domäne, u.u. Domänenwissens noch unvollständig Erschwerte Kommunikation durch wissensreiches Umfeld Unsichere bzw. ständig ändernde Anforderungen Kann aus zwei Richtungen betrieben werden Wissenschaftler Software-Ingenieur 4

5 (A) J. Segal; 2008 (B) J. Segal, C. Morris;

6 Feldstudie Semi-strukturierte Interviews mit Experten und Software-Ingenieuren aus verschiedenen Bereichen Forschungsgebiete: - Finanzmathematik - Molekularbiologie - Geowissenschaften und Planetologie - Weltraumforschung 6

7 Grundtenor in der Forschung Geringe Wertschätzung gegenüber Software Engineering Skills Software wird nicht als nachhaltiger Wert verstanden Mittel um die Forschung voranzutreiben Messbare Qualitätsanforderung werden vernachlässigt Risikofaktor für gute Forschung 7

8 Profil des Wissenschaftlers Verfolgt ein übergeordnetes Ziel Besitzt mindestens Grundkenntnisse im Programmieren Kann im Softwareentwicklungsprozess zwei Rollen einnehmen End-User End-User Developer 8

9 Quelle: 9

10 The term professional end-user developers refers to people such as scientists and engineers working in highly technical, knowledge-rich domains who develop software in order to further their own professional goals [ ] Judith Segal (2007) 10

11 Vorgehensmodell des Professional End-User Developer Quelle: [3] 11

12 Probleme des Vorgehensmodells Phase der Anforderungsermittlung wird übersprungen Keine Trennung zwischen Entwurf und Umsetzung Evaluation und Ermittlung aufkommender Anforderungen geschieht in einem Schritt Oberflächlicher abschließender Test 12

13 Profil des Software-Ingenieurs Verantwortlich für die Planung und Umsetzung der Software Besitzt groben Einblick in die jeweilige Domäne Interessiert an einer nachhaltigen Lösung Identifiziert Qualitätsziele, z.b. Robustheit Identifiziert potentielle Nutzerkreise 13

14 Variante 1 Der Software-Ingenieur orientiert sich streng am Prozess Quelle: [3] 14

15 Problem von Variante 1 Anforderungen sind nicht expliziert Software-Ingenieur geht nach Plan vor Wissenschaftler geht explorativ vor, um Anforderungen zu ermitteln upfront requirements vs. emerging requirements 15

16 Variante 2 Der Software-Ingenieur nähert sich dem Wissenschaftler an Quelle: [3] 16

17 Problem von Variante 2 Software-Ingenieur reagiert auf neue Anforderung Anforderung auf zu hohem Abstraktionsniveau Funktionale Anforderungen sind unbekannt 17

18 Unterschiede in den Kulturen Wissenschaftler Besitzt keine formale SE Ausbildung Eingeschränkter Anschluss an eine Entwickler-Community aufgrund der komplexen Domäne Vorrangiges Interesse gilt eigener Forschungstätigkeit Software-Ingenieur Besitzt formale SE Ausbildung Wissen wird aus breiter Entwickler-Community gewonnen und geteilt Interessiert an nachhaltiger Software 18

19 Agile Methodology Durch Feldstudie nicht abgedeckt Autorin empfiehlt agile und traditionelle Elemente zu verbinden und anzupassen Identifikation von agilen und plan-getriebenen Projekten Plan-getriebenen Projekte durch agile Elemente, z.b. Pair Programming, anreichern 19

20 Fallstudie: LIMS Laboratory Information Management System (LIMS) Sechsjähriges Entwicklungsprojekt Community Platform für Biologen zur Förderung der Kollaboration im Bereich Proteinstrukturen Entwicklungsteam bestehend aus: Software-Ingenieuren Strukturbiologen 20

21 Lessons Learned (I) Lesson 1: Choose Carefully between Soon and Good Auftraggeber einer Software versteht nicht immer die Bedürfnisse der Nutzer Ermittlung von Anforderungen vom Nutzer ist nicht immer zielführend Fange da an wo die Nutzer bereits sind 21

22 Lessons Learned (II) Lesson 2: Good Communication between Developers Can t Be Taken for Granted Verschiedene personelle Hintergründe haben Kommunikation erschwert Verbesserung der Kommunikation durch regelmäßige Treffen 22

23 Lessons Learned (III) Lesson 3: Plan for Sustainability from the Beginning Nutzerkreis sollte so schnell wie möglich wachsen, um eine praktische und nachhaltige Software zu entwickeln Lesson 4: If Adopting Software Changes Work Practices, Its Development Has Special Challenges Inkrementelles Vorgehensmodell hat sich bewährt 23

24 Retrospektive Gleiche Erkenntnisse: High-Level Anforderungen Schwierigkeiten eine gemeinsame Sprache zu finden Verantwortung für Nachhaltigkeit liegt auf Seiten des Software-Ingenieurs Forscher vorrangig am eigenen Nutzungsszenario interessiert 24

25 Retrospektive Hat sich die Wertschätzung gegenüber Softwareentwicklung und Software in der Forschung geändert? 25

26 Zusammenfassung Komplexe Domänen sind eine Herausforderung bei Entwicklung wissenschaftlicher Software Entwicklungsprozess ist durch kulturelle Unterschiede zwischen Wissenschaftlern und Software-Ingenieuren geprägt Ansätze zur Verbesserung der Zusammenarbeit existieren, z.b. agile Methoden 26

27 fin

28 Diskussion (I) Können Wissenschaftler nicht einfach Software-Ingenieure sein?

29 Diskussion (II) Rechtfertig eine prototypische Umsetzung einen schlechten Softwareentwurf?

30 Literatur 1. Chris Morris and Judith Segal. Lessons learned from a scientific software development project. IEEE Software, 29(4):9 12, Judith Segal. When software engineers met research scientists: A case study. Empirical Software Engineering, 10(4): , Judith Segal. Scientists and software engineers: A tale of two cultures. In Proceedings of the Psychology of Programming Interest Group PPIG 08,

Ähnliche Dokumente

Benötigen wir einen Certified Maintainer?

Benötigen wir einen Certified Maintainer? Stefan Opferkuch Universität Stuttgart Institut für technologie, Abteilung Engineering Bestehende Qualifizierungsprogramme Qualifizierungsprogramme existieren