6 Menschen im Software Engineering

Präsentation zum Thema: "6 Menschen im Software Engineering"—  Präsentation transkript:

1 6 Menschen im Software Engineering
6.1 Software-Leute und Klienten 6.2 Rollen und Verantwortlichkeiten 6.3 Die Produktivität des Projekts 6.4 Motivation und Qualifikation 6.5 The Personal Software Process 6.6 Moralische und ethische Aspekte

2 Beim Software Engineering steht der Mensch (tatsächlich
Beim Software Engineering steht der Mensch (tatsächlich!) im Mittelpunkt, weil Software Engineering nur mit ihm möglich ist.

3 6.1 Software-Leute und Klienten

4 Software-Leute und Klienten
Software-Hersteller und Kunde sind meist juristische Personen. Software-Leute Menschen, die auf der Seite des Software-Herstellers in einem Software-Projekt arbeiten (vor allem Entwickler und Manager). Klienten Personen, die den Kunden repräsentieren (z. B. Fachexperten). Manchmal sind die Software-Leute gleichzeitig auch die Klienten: Menschen, die Programmieren als Hobby pflegen, Software-Leute, die sich selbst Werkzeuge schaffen, Menschen, die, geographisch verteilt, gemeinsam an Software-Systemen arbeiten.

5 6.2 Rollen und Verantwortlichkeiten

6 Rollen Am einfachsten: eine Person ↔ eine Rolle Oft:
eine Person ↔ mehrere Rollen Auch: mehrere Personen ↔ eine Rolle In der Praxis finden sich viele sinnvolle und noch mehr andere Rollenverteilungen. Die nachfolgend genannten Rollen sind sinnvoll und weithin üblich.

7 Entwickler und seine Spezialisierungen
Der Entwickler entwickelt Software. Er befasst sich vor allem mit Spezifizieren, Entwerfen, Testen, auch Prüfen und Verwalten. Derzeit entstehen Spezialisierungen; vgl. „Certified Tester“. Analytiker: Erhebung der Anforderungen (Analyse) (betrachten sich eher nicht als Entwickler!) Programmierer: Nur Feinentwurf, Codierung und Test (Software-)Architekt: Der Architekt hat im Software-Projekt eine ähnliche Rolle wie der Architekt auf dem Bau, er entwirft nicht nur die Struktur, sondern leitet und überwacht auch die Realisierung. Kein Künstler! Wartungsingenieur: Entwickler in der Wartung

8 Projektleiter und Gruppenleiter
Der (Software-)Projektleiter (synonym: Projektmanager) leitet das Projekt fungiert als Mittler und Übermittler zwischen dem Management der Herstellerfirma und den Entwicklern kann auch in der Linienorganisation als Gruppenleiter der Vorgesetzte der Entwickler sein. Zwei sehr verschiedene Interpretationen der Vorgesetzten-Rolle Stabsfunktion: Repräsentant der Geschäftsleitung gegenüber den Mitarbeitern Linienfunktion: Vertreter der Gruppe gegenüber dem Management

9 Kunde, Anwender und andere Betroffene
Software wird meist für einen Auftraggeber, den Kunden, entwickelt. Beispiel: Auskunftssystem der Bahn. Kunde = die Bahngesellschaft, vertreten durch einen hohen Manager Klienten = Fahrplan-Experten, Fahrplan-Macher, Betreiber anderer Verkehrsmittel Klienten sind eine im Allgemeinen große und sehr heterogene Gruppe. „Unsichtbare Klienten“ Gesetzgeber, Kontrollgremien Sie wirken durch Gesetze, Vorschriften und Normen auf die Arbeit ein.

10 6.3 Die Produktivität des Projekts

11 Einflussfaktoren der Produktivität - 1
Merkmale Arbeitsbedingungen – Technische Ausstattung (Hardware und Software) – Störungen – Vielfalt der Aufgaben (Zersplitterung der Arbeitsleistung) Schwierigkeiten der Aufgabe – Neuigkeitsgrad der Aufgabe, Verfügbarkeit von Lösungen – Komplexität des Zielsystems – Spezielle Anforderungen wie hohe Zuverlässigkeit, extreme Anforderungen zur Datensicherheit oder zur Rechengenauigkeit – Verfügbarkeit klarer und stabiler Anforderungen

12 Einflussfaktoren der Produktivität - 2
Merkmale Rahmenbedingungen des Projekts – Personelle Kontinuität – Arbeitsklima – Verteilung der Aufgaben und Kompetenzen – Kommunikationswege und -hindernisse – Stabilität und Zuverlässigkeit der Führung – Zeit- und Kostendruck Eignung der Entwickler für das Projekt – Verständnis für den Kunden, Kulturbarrieren – Erfahrung im Anwendungsgebiet, Problemverständnis – Erfahrung in der verwendeten Technologie Individuelle Faktoren – Fähigkeiten als Entwickler – Fähigkeiten zur Arbeit im Team – Disziplin – Motivation

13 Ideale Verhältnisse Versierte, teamfähige Leute arbeiten unter kompetenter Leitung eng zusammen, sind auch räumlich zusammen. Der Kunde, der aus demselben Kulturkreis wie die Entwickler stammt, liefert vollständige und stabile Anforderungen. Die Gruppe hat in gleicher Technologie ähnliche Systeme bereits erfolgreich erstellt. Es ist einfach, solche idealen Verhältnisse zu beschreiben. Viel schwieriger ist es, unter den realen, leider nie idealen Bedingungen eines Projekts den besten Kompromiss zu finden Beispielsweise ist es manchmal fraglich, ob durch einen weiteren, als schwierig bekannten Mitarbeiter das Projekt gefördert oder behindert wird. Eine Risikoanalyse kann in manchen Fällen helfen.

14 Variationsbreite der Produktivität
Performance Measure Ratio (#1) Ratio (#2) Debugging hours 28 : 1 26 : 1 Coding hours 16 : 1 25 : 1 Achtung, diese Zahlen sind sehr alt. Aber neuere gibt es kaum. Diese Untersuchung (Sackman, Erikson und Grant, 1968) wurde oft zitiert und kritisiert. Nach Prechelt sind die Unterschiede nur etwa halb so groß. In der Praxis sieht man überraschende Leistungsunterschiede. Die qualitative Aussage der Daten von Sackman et al. gilt weiterhin: Kein anderer Faktor im Software Engineering streut so stark wie die individuelle Leistung. Vermutlich ist die Variationsbreite innerhalb einer bestimmten Arbeitsumgebung deutlich kleiner (höchstens 1 zu 3).

15 Messung der individuellen Produktivität
Die Leistungen der einzelnen Programmierer kann man durch Zählung der Codezeilen messen: „Programmierer X schreibt y Zeilen Code pro Stunde“ (LOC/h). Dieses Aussage ist problematisch und meist schädlich: Nur ein geringer Teil der Zeit dient der Programmierung. Andere, wichtige Tätigkeiten bleiben unberücksichtigt. Die Qualität des Codes spielt keine Rolle. Programmiersprachen haben unterschiedliche „Dichte“. Die Bewertung der wiederverwendeten Codezeilen (v.a. in oo Programmen) ist noch immer unklar. Der individuelle Programmierstil wirkt sich auf die Zeilenzahl aus. Die Metrik ist leicht zu unterlaufen. Allgemein: Metriken taugen nicht zur individ. Leistungsbewertung !

16 6.4 Motivation und Qualifikation

17 Die übliche Programmiererkarriere - 1
Software-Leute verdienen meist gut; viele haben aber persönliche Probleme mit ihrer Situation. Sie haben als Quereinsteiger ein Grundlagendefizit. Wie sieht der typische Programmierer P aus? P. kommt aus der Elektronik, er ist durch die Änderungen an seinem Arbeitsplatz langsam in die Software hineingerutscht. P. hat darum auch Programmierkurse besucht. Die Leute um P., auch sein Chef, sind ähnlich zur Informatik gekommen. P. kann leidlich C++ programmieren und kennt sich mit dem Prozessor aus, der in seiner Arbeit regelmäßig eingesetzt wird. Von Zeit zu Zeit erreichen P. sensationelle Ankündigungen (AI, Objektorientierung, Windows-XX, Extreme Programming) und Verheißungen (zehnfache Produktivität, fehlerfrei usw.).

18 Die übliche Programmiererkarriere - 2
Was können wir über P. vermuten? P. hat Angst vor Veränderungen, bekämpft sie, vor allem, wenn sie die Transparenz verbessern. Denn P. fürchtet mit gutem Grund, dass jede Änderung das Risiko birgt, ihn zu überfordern. P. glaubt nichts. Insbesondere glaubt er seinem Chef nichts. P. wünscht sich größere Sicherheit bei seiner Arbeit. Er hat aber selbst keine Idee, wie diese aussehen könnte. P. vermutet, dass die Situation in seiner Firma besonders ungünstig ist. P. wird an seinem Arbeitsplatz vermutlich nicht das Pensionsalter erreichen. Traurig für P. und auch für seine Firma!

19 Ein Modell der Motivation
Betrachten wir die Fähigkeiten und Tätigkeiten eines Menschen in einer schematischen Darstellung. Ein Mensch wird eine Arbeit nur ausführen (notwendiges Kriterium), wenn sie innerhalb seiner Möglichkeiten liegt (Gebiet A) oder (besser, aber fast gleichbedeutend) wenn er keine Abneigung dagegen hat (L).

20 Was dem Entwickler Spaß macht
Ein starker Grund, eine Tätigkeit auszuführen, ist, dass sie ihm Spaß macht (C) oder dass sie ihm Anerkennung oder eine andere Art von Belohnung bringt (D). Typisch gilt C Í B Í A, aber nicht D Í B

21 Was der Entwickler tatsächlich tut
Damit beschreibt die grüne Fläche C ∩ (B ∩ D), was der Mensch wirklich (und leidlich gut) macht. Es ist die Aufgabe des Managements, dafür zu sorgen, dass seine Aufgaben in diesem Gebiet liegen.

22 Spezialfall: Der Versager
Ein trauriger Spezialfall ist der Versager, die Niete: B ∩ D ist klein oder leer

23 Spezialfall: Der Workaholic
Ein anderer Spezialfall, eigentlich auch traurig, ist der Workaholic: C ∩ (B ∩ D), ist sehr groß oder sogar C Í (B ∩ D) Viele Probleme im Software Engineering können mit diesen einfachen Diagrammen erklärt werden, denn sie haben mit Können und Motivation zu tun.

24 Folgerungen für das Management
Damit jeder Mitarbeiter leistet, was er leisten kann, sollte die Menge D mit den Interessen der Firma zur Deckung gebracht werden. Es sollte sichergestellt werden, dass D den Mitarbeitern bekannt ist und auch sichtbar wird, z. B. durch die Belohnung derer, die sich entsprechend verhalten. Es sollte die gezielte Weiterbildung der Entwickler die Schnittmenge B ∩ D vergrößern, sodass es für alle Entwickler attraktive Arbeiten gibt, die in ihrer Kompetenz liegen. Wenn es dem Management gelingt, das Ziel innerhalb von C zu platzieren (oder C so zu beeinflussen, dass es das Ziel einschließt), dann hat es gewonnen! Im günstigsten Falle macht die Entwicklung guter Software Spaß !

25 Beispiel: Dokumentation
Wo liegt in diesem Bild die Dokumentation? Im Niemandsland!

26 6.5 The Personal Software Process

27 Verbesserung der SW-Entwicklung
Software, vor allem große Software, ist typisch das Produkt einer Gruppe, nicht von Einzelkämpfern. Die Arbeit der Gruppe ist durch den (Bearbeitungs-)Prozess geprägt. Darum ist die Verbesserung der Prozesse ein wichtiges Thema im Software Engineering. Kleine Gruppen und Leute, die allein arbeiten, können davon kaum profitieren; sie sind nicht in eine (Arbeits-)Organisation eingebettet. Das betrifft insbesondere Studenten. Watts Humphrey hat für diese Zielgruppe den „Personal Software Process“ (PSP) erfunden. Er ist an das CMM (Capability Maturity Model) des SEI angelehnt. Erste Versuche 1993 mit Studenten der CMU.

28 Vorüberlegungen Traditionell
Programmieren erlernt man bottom-up. Stößt man an Grenzen (Fehler, Komplexität), sucht man sich Wege, diese zu überwinden. Das geschieht typisch planlos, intuitiv. Gegenentwurf PSP: Der mit elementaren Programmierkenntnissen ausgestattete Programmierer erlernt sukzessive Techniken, die aus industriellen Prozessen abgeleitet sind. Er entwickelt sich auf diese Weise einen ihm spezifischen Personal Software Process. Damit ist er auch in der Lage, größere Aufgaben anzugehen. Missverständnisse Falsch: PSP ersetzt CMM. Im Gegenteil wird CMM 2 empfohlen. Falsch: PSP ist nur für Ein-Personen-Gruppen geeignet. Im Gegenteil sollen die Lehren des PSP auch in Gruppen nützen.

29 Grundidee Ein Entwickler, der mit möglichst geringem Aufwand gute Arbeit leisten will, sollte planmäßig vorgehen und wissen, wie sich sein Vorgehen auf die Resultate auswirkt. Darum sollte er verschiedene Vorgehensweisen erproben und dabei seinen Aufwand, sein Vorgehen und seinen Erfolg präzise dokumentieren. Auf diese Weise wird er unvermeidlich erkennen, dass bestimmte Techniken erfolgreicher sind als andere, und dann die erfolgreichen Techniken bevorzugt einsetzen. Er wird also besser arbeiten.

30 Der Personal Software Process nach Humphrey
Stufen des PSP Der Personal Software Process nach Humphrey

31 Eingesetzte Lerntechniken
Unterricht einzelner SE-Themen, z.B. Planung, Messen und Schätzen, Design and Code Reviews, Software-Qualitätsmanagement, Software-Entwurf, Ausweitung des Ansatzes für größere Systeme Metriken Formulare zur Erfassung der Metriken statistische Methoden formale Notationen eine Aufgabensammlung

32 Stufen und eingesetzte Metriken des PSP
PSP-Stufe PSP-Schritt Eingesetzte Formulare und Metriken Baseline Personal Process PSP 0 – Project Plan Summary (Übersetzungs- und Testzeit, Fehler entdeckt / behoben) – Time Recording Log – Defect Recording Log PSP 0.1 – Project Plan Summary (Änderungen in LOC real) Personal Planning Process PSP 1 – Project Plan Summary (Schätzungen für LOC) – Size Estimating Template PSP 1.1 – Project Plan Summary (Planeinhaltung, Wiederverwendung) – Task and Schedule Planning Templates Personal Quality Management PSP 2 – Project Plan Summary (Fehler und Aufwand) PSP 2.1 – Project Plan Summary (Qualitätsaufwand und -kosten) – State Specification Template Cyclic Personal Process PSP 3 – Cycle Summary (Metriken-Übersicht für jedes Inkrement) – Issue Tracking Log (Verfolgung von)

33 Diskussion PSP Kritik am PSP:
relativ bürokratisch, allzu sehr auf die Codierung fixiert. Unstrittig: Jeder Student sollte sich daran gewöhnen, seine Aufwände und deren Wirkungen zu notieren und daraus zu lernen. Fast jeder Student zweifelt an der Botschaft: Code-Lesen bringt mehr als Testen. Ausprobieren und wundern! Humphrey hat unter der Bezeichnung „Team Software Process“ (TSP) einen ähnlichen Ansatz für Entwicklergruppen vorgelegt.

34 6.6 Moralische und ethische Aspekte

35 Unsere Arbeit als Software-Entwickler
Jedes Artefakt verändert die Welt. Software tut dies in erheblichem Maße. Die Wirkungen sind vielfältig und vielfach auch ambivalent. Die Zersplitterung unserer Arbeit in viele Teile hat zur Folge, dass die Teile (die Einzelarbeiten) nicht separat zu bewerten sind. Beispiel: Entwicklung eines Compilers Konsequenz: Die Forderung, beim SE ethische Prinzipien zu beachten, läuft hinsichtlich der Software-Verwendung oft ins Leere. Das gilt aber in vielen konkreten Fällen nicht. Außerdem gelten die Regeln der Moral auch für die Arbeit selbst (z.B. Beachtung der Urheberrechte, Respekt vor der Intimsphäre, Fairness gegenüber einem Partner).

36 Ethische Leitlinien Folge der Diskussion über ethische Aspekte:
der IEEE-Computer Society und der ACM (1999) der Gesellschaft für Informatik (2004) vieler anderer nationaler oder internationaler Berufsverbände. Praktisches Problem: Die Leitlinien setzen einerseits auf die Codifizierung der Verhaltensregeln (wie Gesetze). Aber die Formulierungen sind zu unbestimmt. Andererseits schrecken sie vor Sanktionen zurück. Wir haben damit Regeln, die weder Genaues sagen noch durch eine Jury konkretisiert und angewendet werden.

37 Extremes Beispiel Die Regeln im Australian Computer Society Code of Ethics (2004): Priorities: I must place the interests of the community above those of personal or sectional interests. Competence: I must work competently and diligently for my clients and employers. Honesty: I must be honest in my representations of skills, knowledge, services and products. (...) I must take appropriate action if I discover a member, or a person who could potentially be a member, of the Society engaging in unethical behaviour.

38 Leitlinien der GI Deutlich besser: Die deutschen Leitlinien:
Art. 8 Lehre: Vom Mitglied, das Informatik lehrt, wird zusätzlich erwartet, dass es die Lernenden auf deren individuelle und gemeinschaftliche Verantwortung vorbereitet und selbst hierbei Vorbild ist. Art. 10 Zivilcourage: Die GI ermutigt ihre Mitglieder in Situationen, in denen ihre Pflichten gegenüber Arbeitgebern oder Kundenorgansationen in Konflikt mit der Verantwortung gegenüber anderweitig Betroffenen stehen, mit Zivilcourage zu handeln. Sie sollten sich diese Leitlinien ansehen und darüber nachdenken.

39 Fazit The good life is inspired by love and guided by knowledge
Bertrand Russell ( ) Das bedeutet: Wir müssen die Folgen unserer Handlungen überblicken. Dazu brauchen wir gute fachliche Kenntnisse. Und wir sollten uns bemühen, unsere Handlungen so auszurichten, dass wir damit uns und anderen nützen, nicht schaden. Dazu brauchen wir die Liebe zu unseren Mitmenschen und zu uns selbst.