Software Engineering

© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.

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!) im Mittelpunkt, weil Software

Engineering nur mit ihm möglich ist.

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 Software-Systemen 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

11

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

Einflussfaktoren der Produktivität - 2

12

Faktoren 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

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

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

Performance Measure Ratio (#1) Ratio (#2)

Debugging hours 28 : 1 26 : 1

Coding hours 16 : 1 25 : 1

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 PSPPSP-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)

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

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

The good life is inspired by love and guided by knowledgeBertrand Russell (1872-1970)