Software-Leute

Software Engineering
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
© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.
Beim Software Engineering steht der Mensch
(tatsächlich!) im Mittelpunkt, weil Software
Engineering nur mit ihm möglich ist.
2
6.1 Software-Leute und Klienten
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 SoftwareSystemen arbeiten.
4
6.2
Rollen und Verantwortlichkeiten
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.
6
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
7
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
8
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.
9
6.3 Die Produktivität des
Projekts
Einflussfaktoren der Produktivität - 1
Faktoren
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
11
Einflussfaktoren der Produktivität - 2
Faktoren
Merkmale
Rahmenbedingungen
des Projekts
–
–
–
–
–
–
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
–
–
–
–
Personelle Kontinuität
Arbeitsklima
Verteilung der Aufgaben und Kompetenzen
Kommunikationswege und -hindernisse
Stabilität und Zuverlässigkeit der Führung
Zeit- und Kostendruck
Fähigkeiten als Entwickler
Fähigkeiten zur Arbeit im Team
Disziplin
Motivation
12
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.
13
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).
14
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 !
15
6.4 Motivation und Qualifikation
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.).
17
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!
18
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).
19
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
20
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.
21
Spezialfall: Der Versager
Ein trauriger Spezialfall ist der Versager, die Niete:
B ∩ D ist klein oder leer
22
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.
23
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ß !
24
Beispiel: Dokumentation
Wo liegt in diesem Bild die Dokumentation?
Im Niemandsland!
25
6.5
The Personal Software Process
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.
27
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.
28
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.
29
Stufen des PSP
Der Personal Software Process nach Humphrey
30
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
31
Stufen und eingesetzte Metriken des PSP
PSP-Stufe
PSP-Schritt
Baseline
Personal
Process
PSP 0
Eingesetzte Formulare und Metriken
– Project Plan Summary
(Übersetzungs- und Testzeit, Fehler entdeckt / behoben)
– Time Recording Log
– Defect Recording Log
Personal
Planning
Process
PSP 0.1
– Project Plan Summary (Änderungen in LOC real)
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)
Cyclic
Personal
Process
PSP 3
– State Specification Template
– Cycle Summary (Metriken-Übersicht für jedes Inkrement)
– Issue Tracking Log (Verfolgung von)
32
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.
33
6.6
Moralische und ethische
Aspekte
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).
35
Ethische Leitlinien
Folge der Diskussion über ethische Aspekte:
ethische Leitlinien
● 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.
36
Extremes Beispiel
Die Regeln im Australian Computer Society Code of Ethics (2004):
● 4.3.1 Priorities: I must place the interests of the community
above those of personal or sectional interests.
● 4.3.2 Competence: I must work competently and diligently for my
clients and employers.
● 4.3.3 Honesty: I must be honest in my representations of skills,
knowledge, services and products.
● (...)
● 4.10.6 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.
37
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.
38
Fazit
The good life is inspired by love and guided by knowledge
Bertrand Russell (1872-1970)
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.
39