Menschen, die Programmieren als Hobby pflegen,In vielen Bereichen der Technik kommen Menschen vor allem als Kunden, Abnehmer vor, die Produktion und selbst der Entwurf der Systeme werden automatisiert und benötigen nur noch wenige Spezialisten. Software Engineering ist davon weit entfernt, denn es findet im Kopf von Menschen statt, die Software haben wollen oder entwickeln. Der Mensch steht im Mittelpunkt; das ist für uns keine Floskel, sondern eine sachliche Feststellung. Die einzelnen Menschen, ihre Rollen, Leistungen, Motive und Wertvorstellungen sind Gegenstand dieses Kapitels.
Sowohl der Software-Hersteller als auch der Kunde sind meist juristische Personen. Konkret sind an einem Software-Projekt Mitarbeiter des Herstellers und des Kunden beteiligt. Wir bezeichnen die Menschen, die im Auftrag eines Kunden auf der Seite des Software-Herstellers in einem Software-Projekt arbeiten, als Software-Leute; das sind vor allem Entwickler und Manager. Wir fassen die Personen, die den Kunden repräsentieren (z.B. Fachexperten), mit dem Wort Klienten zusammen (siehe Abschnitt 6.2.3).
Die Software-Leute, so unterschiedlich sie sind, bilden eine spezielle soziale Gruppe, die sich durch ihre Denkweise und ihre Sprache von anderen Gruppen unterscheidet. Auch zwischen den Klienten gibt es große Unterschiede; wir unterscheiden zunächst trotzdem nur diese beiden einfachen Kategorien.
Auch diese Unterscheidung ist nicht immer möglich: Fälle, in denen Entwickler zugleich Kunden sind, lassen sich drei (überlappenden) Gruppen zuordnen:
Menschen, die Programmieren als Hobby pflegen,
Software-Leute, die sich selbst Werkzeuge schaffen,
Menschen, die, geographisch verteilt, gemeinsam an Software-Systemen arbeiten.
Bei der dritten Gruppe (Linux, Free Software usw.) ist es nicht zwingend, dass der Hersteller die Software auch verwendet, dies ist aber der Regelfall.
Auf beiden Seiten gibt es eine Reihe verschiedener Rollen. In vielen Fällen übernimmt eine Person genau eine Rolle, in vielen anderen Fällen hat eine Person mehrere Rollen; eine Rolle kann auch von mehreren Personen gemeinschaftlich übernommen werden. Beispielsweise kann in einem kleinen Projekt eine Person die beiden Rollen Konfigurationsverwalter und Qualitätssicherer übernehmen, während im großen Projekt mehrere Leute ausschließlich für die Qualitätssicherung arbeiten. Wir machen hier keine Aussagen über die Abbildung zwischen Personen und Rollen. Daher hat die Entscheidung für Singular- oder Pluralformen hier keine Bedeutung.
In der Praxis finden sich viele sinnvolle und noch mehr andere Rollenverteilungen. Die nachfolgend genannten Rollen sind sinnvoll und weithin üblich.
Die Aufgabe des Entwicklers ist durch seine Bezeichnung beschrieben: Er entwickelt Software. Da wir von einem weiten Software-Begriff ausgehen (Abschnitt 2.3.1), gibt es eine Reihe von Tätigkeiten, die dieser Rolle zugeordnet sind: Spezifizieren, Entwerfen, Testen, auch Prüfen und Verwalten. Entsprechende Spezialisierungen können definiert werden. So wurde beispielsweise für den Tester eine spezielle Ausbildung und Zertifizierung eingeführt (Spillner, Linz, 2005).
Das Erheben der Anforderungen, die Analyse, ist in vielen Organisationen Sache der Analytiker, die sich nicht als Entwickler sehen. Sind die Aufgaben der Entwickler auf Feinentwurf, Codierung und Test eingeengt, so werden sie als Programmierer bezeichnet; oft (aber nicht in diesem Buch) wird Programmierer aber auch als Synonym für Entwickler verwendet.
Eine weitere Spezialisierung ist die des (Software-)Architekten. Der Architekt hat im Software-Projekt eine ähnliche Rolle wie der Architekt auf dem Bau, er entwirft nicht nur die Struktur des zu Schaffenden, sondern leitet und überwacht auch die Realisierung. Allerdings ist mit dem Begriff des Architekten auch die Konnotation des Künstlers verbunden, die hier ausdrücklich nicht übernommen wird.
Bislang gibt es keine berufliche Spezialisierung für die Software-Wartung. Wir sprechen hier von Wartungsingenieuren (Abschnitt 22.4.3), die nach ihrer Ausbildung und Qualifikation nicht von den Entwicklern zu unterscheiden sind. In vielen Organisationen ist es üblich, dass die Entwickler zugleich die Rolle des Wartungsingenieurs übernehmen.
Ein Arbeitskreis des BMBF (Bundesministerium für Bildung und Forschung) hat für die Weiterbildung einen umfassenden Katalog von Informatik-Berufen vorgelegt (Altmann, Feuerstein, 2002), dessen praktische Relevanz angezweifelt werden darf, denn die Spezialisierung ist darin so weit getrieben, dass man Berufsanfänger eher davor warnen muss. In jedem Falle ist die Entscheidung für englische Bezeichnungen wie Business Systems Advisor und IT Quality Management Coordinator, die zudem alles andere als eingängig sind, zu bedauern.
Der (Software-)Projektleiter (synonym: Projektmanager) leitet das Projekt und fungiert als Mittler und Übermittler zwischen dem (oberen und) mittleren Management der Herstellerfirma und den Entwicklern. Je nach Organisationsform (siehe Abschnitt 7.5) kann er auch in der Linienorganisation des Unternehmens als Gruppenleiter der Vorgesetzte der Entwickler sein. Weil die Rolle des Projektleiters besonders wichtig ist, gehen wir in Kapitel 8 detailliert auf seine Aufgaben ein.
In der Praxis findet man – ohne formale Unterschiede – zwei sehr verschiedene Interpretationen der Rolle eines Vorgesetzten: Der eine sieht sich in einer Stabsfunktion; er versteht sich als Repräsentant der Geschäftsleitung gegenüber den Mitarbeitern, d. h., er wirkt wie der Statthalter des Königs von oben nach unten. Der andere lebt seine Linienfunktion, sieht sich als »Räuberhauptmann«, der »seine Leute« gegenüber den Vorgesetzten vertritt. Kaum ein Mensch wird sich bewusst für das eine oder das andere Rollenverständnis entscheiden; aber natürlich gehört unsere Sympathie dem, der sich vor allem als Vertreter der Gruppe versteht.
Software wird im Allgemeinen für einen Auftraggeber, den Kunden, entwickelt. In Ausnahmefällen ist dieser Kunde eine natürliche Person, die später auch das System benutzt; in der Regel ist der Kunde eine Firma, eine Behörde oder sonst eine juristische Person. In diesem Fall gibt es dort Fachleute für die Anwendung; ist das System fertiggestellt, so wird es von Anwendern benutzt. Schließlich sind von vielen Systemen indirekt auch Menschen betroffen, die zu keiner der genannten Gruppen gehören.
Wir betrachten als Beispiel ein Auskunftssystem der Bahn. Kunde ist in diesem Fall die Bahngesellschaft, praktisch ein hoher Manager; er unterschreibt den Auftrag und gibt damit den Preis und die Termine vor. Fahrplan-Experten tragen die zahlreichen Details bei. Bahnbenutzer sind die Anwender des Systems; auch die Fahrplan-Macher sind Anwender, weil sie Daten einfüttern. Die Betreiber anderer Verkehrsmittel sind Betroffene, weil das Auskunftssystem ihre Angebote berücksichtigt oder nicht. Die Klienten bilden also eine im Allgemeinen große und sehr heterogene Gruppe.
In vielen Fällen gibt es neben den genannten auch noch unsichtbare Klienten, nämlich den Gesetzgeber oder Kontrollgremien. Sie wirken durch Gesetze, Vorschriften und Normen auf die Arbeit der Software-Leute ein.
Für die Produktivität eines Software-Projekts gibt es einige grobe Anhaltspunkte (siehe Abschnitt 14.2.3). In Modellen zur Kostenschätzung wie COCOMO (siehe Abschnitt 8.4.3) sind solche Erfahrungswerte eingearbeitet, aber auch andere Effekte werden berücksichtigt, insbesondere die Komplexität der Software und die Kompetenzen derer, die sie entwickeln.
Manche Zahlen in den folgenden Abschnitten beruhen auf Angaben, die schon in den Sechzigerjahren publiziert wurden; wir müssen darum vermuten, dass sie nicht mehr aktuell sind. Aber es handelt sich nicht um technische Daten, sondern um Eigenschaften von Menschen, die sich in wenigen Jahrzehnten kaum ändern. Natürlich ist die Ausbildung besser geworden, aber auch im 21. Jahrhundert fehlt vielen Software-Leuten eine einschlägige Ausbildung. Wir stützen uns also mangels neuerer Daten mit den gebotenen Vorbehalten auf die alten Zahlen.
Die Leistung der Entwickler in einem Software-Projekt wird von vielen verschiedenen Faktoren bestimmt; da die Abgrenzung der Begriffe willkürlich ist, kann eine Liste der Faktoren nur den Charakter eines Vorschlags haben. Auch die Gruppierung ist willkürlich: Ist beispielsweise die Motivation des Entwicklers ihm persönlich zuzuordnen, oder hängt sie davon ab, wie gut Entwickler und Projekt zueinander passen?
Wir kommen auf Basis der expliziten und impliziten Aussagen in den Büchern von Fairley (1985) und Boehm (Boehm, 1981; Boehm et al., 2000) zur Tabelle 6–2. Offensichtlich ist es ideal, wenn
versierte, teamfähige Leute unter kompetenter Leitung räumlich eng zusammenarbeiten,
der Kunde, der aus demselben Kulturkreis stammt, vollständige und stabile Anforderungen liefert,
das Projektteam bereits in gleicher Technologie ähnliche Systeme erfolgreich erstellt hat.
Viel schwieriger ist es, unter den realen, leider nie idealen Bedingungen eines Projekts den besten Kompromiss zu finden: Ist es sinnvoller, das Werkzeug zu wechseln, weil ein anderes für diese Aufgabe besser geeignet ist, oder überwiegen die Vorteile der Kontinuität? Sollte der Star unter den Entwicklern möglichst vielen Projekten nützen, oder sollte er sich auf ein einziges konzentrieren? Wiegen die firmenpolitischen Vorteile einer verteilten Entwicklung die Kommunikationsprobleme auf? Auf Fragen dieser Art gibt es keine einfachen Antworten. Wenigstens sollten sie aber (vor allem im Zuge der Risikoanalyse) gestellt und diskutiert werden. Eine schnelle Antwort »aus dem Bauch« ist sehr wahrscheinlich falsch.
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 |
Rahmenbedingungen des Projekts |
– Personelle Kontinuität – Arbeitsklima – Verteilung der Aufgaben und Kompetenzen – Kommunikationswege und -hindernisse (inkl. räumlich verteilte Entwicklung, Kulturbrüche) – 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 (Vorgehensmodell, Werkzeuge, Programmierparadigma, Programmiersprache, Methoden) |
Individuelle Faktoren |
– Fähigkeiten als Entwickler – Fähigkeiten zur Arbeit im Team – Disziplin – Motivation |
Tab. 6–1 Produktivitätsfaktoren
Wenn es um die Variationsbreite der Produktivität geht, werden noch immer die Resultate einer Untersuchung von Sackman, Erikson und Grant (1968) zitiert. Dabei wurde die gleiche Aufgabe von verschiedenen Programmierern bearbeitet. Die Tabelle 6–2 zeigt jeweils das Verhältnis zwischen maximalem und minimalem Zeitbedarf. Man sieht, dass die Unterschiede dramatisch sind: Das Zahlenverhältnis 1 zu 25 beim Codieraufwand im zweiten Versuch bedeutet, wenn es denn stimmt und extrapoliert werden kann, dass der extrem langsame Programmierer fünf Wochen für eine Aufgabe braucht, die der sehr schnelle an einem einzigen Tag erledigt.
Performance Measure |
Ratio (#1) |
Ratio (#2) |
Debugging hours |
28 : 1 |
26 : 1 |
Coding hours |
16 : 1 |
25 : 1 |
Tab. 6–2 Leistung verschiedener Programmierer nach Sackman, Erikson, Grant (1968)
Diese Untersuchung wurde später oft zitiert, aber auch kritisiert. Nach Prechelt (1999), der auf die frühere Arbeit von Grant und Sackman (1966) mit den Rohdaten zurückgegriffen hat, ist die Streuung tatsächlich nur etwa halb so groß wie von Sackman behauptet, aber auch das bedeutet eine volle Größenordnung. Experimente an der Universität Stuttgart (Wetzel, 2007) liefern Aussagen, die mit denen von Prechelt zusammenpassen. Allerdings erweist es sich als fast unmöglich, ein wirklich sauberes Experiment mit allgemeingültigen Resultaten durchzuführen: Man müsste entweder sehr spezielle Gruppen bilden, also z. B. nur Studenten der Softwaretechnik im 4. Semester, die alle Prüfungen des ersten Studienjahres bestanden haben (was die Zahl der möglichen Probanden drastisch reduziert und die Allgemeingültigkeit der Resultate stark einschränkt) oder sehr viele Probanden heranziehen (was den Aufwand und je nach Probanden auch die Kosten in die Höhe treibt).
Jeder, der die Praxis kennt, hat überraschende Leistungsunterschiede gesehen. Wir können also annehmen, dass die qualitative Aussage, die sich aus den Daten von Sackman, Erikson und Grant ergibt, weiterhin gilt: Kein anderer Faktor im Software Engineering streut so stark wie die individuelle Leistung. Beobachtungen in studentischen Projekten und auch in Firmen legen aber die Vermutung nahe, dass die Variationsbreite innerhalb einer bestimmten Arbeitsumgebung deutlich kleiner ist, als Sackmans Zahlen vermuten lassen (höchstens 1 zu 3). Der Grund könnte sein, dass sich Gruppen aus ähnlichen Individuen bilden und dass sich die Individuen der Gruppe anpassen, positiv oder negativ. Nimmt man diese Vermutung als Tatsache, dann erhält die Erkennung und Förderung schwächerer Mitarbeiter ein wesentlich höheres Gewicht: Sie hat einen günstigen Einfluss auf die Arbeit der ganzen Gruppe.
Gerade angesichts der großen Unterschiede zwischen den Leistungen der einzelnen Programmierer erscheint es sehr attraktiv, die Leistungen zu messen. Dazu bietet sich die Zählung der codierten Zeilen an. Auf diese Weise kommt man zu einer Angabe der Form »Programmierer X schreibt y Zeilen Code pro Stunde« (LOC/h). Eine solche Aussage ist aus mehreren Gründen problematisch und meist schädlich:
Programmierer verbringen nur einen kleinen Teil ihrer Zeit mit Codierung im engeren Sinne. Fairley (1985) zitiert eine Untersuchung bei Bell Labs, nach der 13 % der Zeit wirklich dem Programmieren gewidmet sind. Damit haben kleine Änderungen bei den übrigen Tätigkeiten, beispielsweise eine verstärkte Unterstützung anderer, unerfahrener Programmierer, eine erhebliche Wirkung auf die Programmierleistung. Aber nur die Programmierleistung wird gemessen, nicht die höchst sinnvolle Unterstützung anderer.
Unterschiedliche Programmiersprachen erfordern unterschiedlich viele Code-Zeilen für die gleiche Funktionalität. Wer in primitiven Sprachen codiert, schreibt in der gleichen Zeit mehr Zeilen, löst dabei aber weniger Probleme als ein gleich guter Programmierer in einer hohen Sprache.
Die Bewertung der Code-Zeilen, die durch Vererbung in einem objektorientierten Programm integriert werden, ist noch immer unklar. Offensichtlich erfordern auch sie Aufwand, aber weniger als neu entwickelte.
Wo nicht Richtlinien die Formatierung der Programme sehr strikt regeln, wirkt sich der individuelle Programmierstil auf die für ein bestimmtes Programm erforderliche Zeilenzahl aus.
Wenn die Produktivität gemessen wird, stellen sich die Programmierer darauf ein, indem sie die Zeilenzahl mit wenig Aufwand in die Höhe treiben; sie unterlaufen die Metrik. Wer eine mehrfach benötigte Sequenz kopiert, statt daraus ein Unterprogramm zu machen, hat mit gleichem Aufwand mehr Code produziert. Die Programme werden dadurch nicht besser, sondern unübersichtlicher, und die gemessenen Zahlen sind wertlos.
Aus diesen Gründen ist von einer Leistungsbewertung der Entwickler durch Erhebung der codierten Zeilen dringend abzuraten. Code-Zeilen sind als Metrik nicht so schlecht, wie oft behauptet wird, aber sie sollten nur zur Charakterisierung der Produkte, niemals zur Bewertung der Entwickler verwendet werden.
Ganz allgemein gilt, dass Metriken nicht geeignet sind, Daten für die Leistungsbewertung zu liefern. Darum sollte man zwischen diesen beiden Themenkreisen eine organisatorische Brandmauer errichten, ohne Lücken und Löcher, und dies auch allen Beteiligten nachdrücklich klarmachen.
Software-Leute werden zwar je nach Konjunktur mehr oder minder intensiv gesucht und relativ gut bezahlt; damit endet aber in vielen Organisationen bereits die Fürsorge. Den Entwicklern und Projektleitern wird stillschweigend unterstellt, dass sie mit ihren Problemen, dem chronischen Mangel an Information und Motivation, allein fertig werden und auch rechtzeitig reagieren, wenn ihre Qualifikation den Anforderungen ihrer Arbeit nicht mehr genügt. Auch in anderen Berufen gibt es dieses Problem. Aber die Zahl der Quereinsteiger ist nirgends so hoch wie in der Informatik. Betrachten wir den Programmierer P. als Muster:
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.).
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.
Diese Geschichte ist nicht nur für P. traurig, auch seine Firma nimmt Schaden, wenn er zunächst innerlich und ein paar Jahre später auch offiziell in den Vorruhestand geht. Denn P. hat viel Erfahrung und möchte eigentlich nützliche Arbeit leisten. Er könnte, angemessene Förderung vorausgesetzt, seiner Firma noch viel geben, und sie ihm.
Zur Diskussion der Motivation betrachten wir jeden Punkt der Ebene als eine spezielle Tätigkeit. Dann gibt es eine Teilmenge A der Punkte, die alle Tätigkeiten umfasst, die eine bestimmte Person beherrscht. Abbildung 6–1 zeigt als Teilmenge von A die Menge B. B enthält die Tätigkeiten, die der Entwickler nicht ungern tut. Darin steckt die These, dass kein Mensch gern tut, was er nicht kann, und umgekehrt im Allgemeinen kein Problem damit hat, zu tun, was er kann.
Abb. 6–1 Was der Entwickler kann und was er nicht ungern tut
Jeder Mensch braucht für seine Arbeit eine Bestätigung von außen, es sei denn, sie macht ihm einfach Spaß. Darum zeigt Abbildung 6–2 auch die Tätigkeiten, die Spaß machen (C), und diejenigen, die von der Umgebung anerkannt werden (D). Natürlich gilt: C ⊆ B ⊆ A. (Davon gibt es Ausnahmen. Manche Leute halten beispielsweise gern Reden, obwohl sie das nicht können.)
Abb. 6–2 Was dem Entwickler Spaß macht und was seine Umgebung anerkennt
Die Folgerung aus dieser Betrachtung ist simpel: Der Entwickler wird in aller Regel tun, was in C oder in der Schnittmenge von B und D liegt, mit anderen Worten: was ihm Spaß macht oder was er sowohl nicht ungern tut als auch von der Umgebung honoriert bekommt. Das ist also die Menge C ∪ (B ∩ D). Sie ist in Abbildung 6–3 mit »was der Entwickler wirklich tut« bezeichnet.
Abb. 6–3 Was der Entwickler tatsächlich tut
Mit diesen Diagrammen lassen sich einige bekannte Typen leicht charakterisieren:
Der »Workaholic« ist einer, bei dem C in der sehr großen Schnittmenge B ∩ D liegt. Was ihm Spaß macht, ist auch anerkannt. Warum sollte er etwas anderes tun als zu arbeiten? Sein Gegenstück ist ein Mitarbeiter, der nichts zustande bringt, nach üblichem Urteil eine Niete: Bei ihm ist B ∩ D sehr klein oder leer.
Sehr problematisch ist die Situation, in der C anders als hier angenommen nicht (vollständig) in A liegt. Das ist bei Leuten der Fall, die sich einer Selbsttäuschung über ihre Arbeit hingeben. Beispielsweise programmieren manche Leute gern, aber schlecht. Natürlich erwarten auch sie Anerkennung für ihre Leistung
Was kann das Management aus dieser Betrachtung lernen? Damit jeder Mitarbeiter leistet, was er im Interesse der Firma leisten kann, sollte zunächst die Menge D mit den Interessen der Firma zur Deckung gebracht werden. In vielen Firmen ist ein Verhalten hoch geachtet, das durchaus schädlich ist, vor allem das sogenannte Fire fighting, also die Rettung eines Projekts in letzter Minute. Man sollte nicht vergessen, dass eine solche Rettung nur notwendig ist, wenn das Projekt zuvor in die Krise geführt wurde. Wer stattdessen sein Projekt sicher steuert und gar nicht erst in eine Krisensituation gerät, bekommt deutlich weniger Anerkennung. Das ist falsch!
Ähnlich verhält es sich mit der Dokumentation: Viele Manager beklagen, dass nicht oder schlecht dokumentiert wird. Sie haben aber weder dafür gesorgt, dass die Mitarbeiter gut dokumentieren können (dazu sind Ausbildung und Vorbilder nötig), noch erhalten Leute, die sich um gute Dokumentation bemühen, die verdiente Anerkennung. Diese Tätigkeit liegt also im Sinne des Diagramms im Niemandsland, weder in C noch in D.
Dann sollte sichergestellt werden, dass D den Mitarbeitern bekannt ist und auch sichtbar wird, z. B. durch die Belohnung derer, die sich entsprechend verhalten. Welchen Charakter diese Belohnung hat (Prämie, Beförderung, Mitarbeiter des Monats oder was auch immer), ist zweitrangig. Auch die soziale Anerkennung, die der kompetente Entwickler in regelmäßigen Review-Sitzungen von seinen Kollegen bekommt, darf man nicht unterschätzen.
Und schließlich sollte die gezielte und individuell ausgewählte 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 sogar gelingt, das Ziel innerhalb von C zu platzieren (oder C so zu beeinflussen, dass es das Ziel einschließt), dann hat es gewonnen!
Wo immer Probleme, Fehlentwicklungen und Mängel erkannt werden, sind Veränderungen erforderlich. In einem technischen Prozess können sie darin bestehen, dass Maschinen ausgewechselt oder Parameter anders eingestellt werden, wovon die Arbeit der Menschen kaum betroffen ist. Bei der Software-Bearbeitung spielen solche rein technischen Änderungen nur eine untergeordnete Rolle; dann und wann kann ein Problem durch ein Hilfsprogramm oder durch den Übergang auf die neue Version eines Werkzeugs gelöst oder entschärft werden. In fast allen Fällen kommt die Veränderung dadurch zustande, dass Menschen anders arbeiten als zuvor, dass sie also sich ändern. Lehnen sie die Veränderung ab oder sabotieren diese gar, so wird sie nicht gelingen. Beispiele aus dem Bereich der Werkzeugeinführung oder der Prozessverbesserung sind Legion: Formal kann man vieles durchsetzen, aber praktisch ergibt sich daraus kein Nutzen, wenn die Betroffenen nicht kooperieren. Dass sie dies in der Regel nicht offen sagen, sondern oft sogar ihre positive Einstellung betonen, macht die Situation keineswegs einfacher.
Darum ist es die Aufgabe derer, die über Veränderungen entscheiden, dafür zu sorgen, dass jeder einzelne Beteiligte davon profitiert, dass also zwischen der Organisation und den Mitarbeitern eine Win-win-Situation entsteht. Der Nutzen für die Organisation reicht nicht aus, das Argument, das Wohl der Firma sei auch das Wohl der Mitarbeiter, ist allzu abstrakt – und in der Praxis auch oft falsch, wenn beispielsweise eine Rationalisierung zum Personalabbau führt.
Der individuelle Nutzen kann ganz unterschiedlich aussehen, er reicht von einer simplen Prämie oder Gehaltserhöhung über bessere Arbeitsbedingungen und den Erwerb neuer Kenntnisse bis hin zur öffentlichen Auszeichnung und einem Sprung auf der Karriereleiter. Dabei hat ein junger, hoch qualifizierter Mitarbeiter völlig andere Wünsche als einer, der sich auf seinen nahen Ruhestand freut. Die unterschiedlichen Interessen wahrzunehmen und bei allen Veränderungen zu berücksichtigen, ist eine Schlüsselqualifikation jedes guten Managers.
Software wird überwiegend von Gruppen entwickelt, nicht von »Einzelkämpfern« (vgl. Abschnitt 7.4.1). Das gilt natürlich verstärkt für große Systeme. Darum setzen die meisten Versuche, den Entwicklungsprozess zu verbessern, an den Gruppen an, nicht an den Individuen. Solche Versuche werden ausführlich in Kapitel 11 vorgestellt.
Andererseits gibt es auch kleine Projekte, die von Einzelnen oder von Gruppen aus zwei oder drei Personen bearbeitet werden. Das gilt für die Industrie und mehr noch für die Hochschulen, wo Studenten oft allein Übungsaufgaben bearbeiten, Praktika absolvieren oder Diplomarbeit schreiben. Hier greifen Regelungen für Organisationen nicht.
Darum hat Watts Humphrey ein Regelwerk geschaffen, das er unter der Bezeichnung »Personal Software Process« (PSP) erprobt und publiziert hat (Humphrey, 1997, 2005). Die erste Zielgruppe des PSP waren 1993 die Studenten, denen Humphrey die Ideen des Capability Maturity Models (CMM/CMMI, siehe Abschnitt 11.2) nahe bringen wollte.
Die Grundidee des PSP kann wie folgt ausgedrückt werden: 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. Die Abbildung 6–4 zeigt die Darstellung des PSP von Humphrey. Die Teilung jeder Stufe (außer PSP3) in zwei Schritte ist wohl durch die Anlehnung an die CMM-Stufen begründet.
Abb. 6–4 Der Personal Software Process nach Humphrey
Humphrey vermittelt den PSP durch Unterricht einzelner Software-Engineering-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. Die Studenten wenden das Gehörte Woche für Woche in Übungen an, die zuerst sehr klein sind und von Woche zu Woche größer werden. Dabei steigen sie von Ebene zu Ebene durch die Stufen des PSP auf (Tab. 6–3).
Der PSP ist relativ bürokratisch und allzu sehr auf die Codierung fixiert. Es erscheint darum zweifelhaft, ob man ihn allgemein in die Hochschullehre übernehmen sollte. Völlig unstrittig ist die Grundidee: 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, dass Code-Lesen mehr bringt als Testen. Wer es selbst ausprobiert hat, zweifelt nicht mehr.
Humphrey hat unter der Bezeichnung »Team Software Process« (TSP) einen ähnlichen Ansatz für Entwicklergruppen vorgelegt (Humphrey, 2000).
PSP-Schritt |
Eingesetzte Formulare und Metriken |
|
Baseline |
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 Problemen über die Inkremente hinweg) |
Tab. 6–3 Stufen und eingesetzte Metriken des PSP, stark vergröbert
Jedes Artefakt verändert die Welt, in der wir leben. Software tut dies in erheblichem Maße. Die Wirkungen sind vielfältig und vielfach auch ambivalent; nur in speziellen Fällen, etwa bei einem Programm zur Steuerung eines Herzschrittmachers oder bei einem Computervirus, kann man Software uneingeschränkt als gut oder böse einstufen. (Aber selbst in diesen Fällen gibt es Szenarien, die eine andere Wertung nahe legen, beispielsweise, wenn ein Computervirus bewirkt, dass sich die Mitglieder eines Tauschrings für Kinderpornografie quasi selbst bei der Staatsanwaltschaft melden.)
Die Zersplitterung unserer Arbeit in viele Teile trägt wesentlich zur hohen Produktivität in den Industriegesellschaften bei, sie hat aber auch zur Folge, dass die einzelnen Teile in der Regel nicht mehr separat zu bewerten sind. Wer einen Compiler schreibt, hat keine Kenntnis der Ziele, die später die Anwender des Compilers verfolgen werden; typischerweise realisieren auch diese ein Werkzeug (z. B. ein Datenbanksystem), das wiederum den Zielen anderer Menschen dienen wird. Die Forderung, beim Software Engineering ethische Prinzipien zu beachten, läuft also hinsichtlich der Software-Verwendung in vielen Fällen ins Leere.
Damit ist das Thema aber nicht erledigt. Denn zum einen gibt es neben den erwähnten Basissystemen viel Software, deren Sinn und Anwendung klar sind und die daher auch bewertet werden können. Wer an Schießspielen arbeitet oder an einem Programm, das die Angestellten einer Firma ausspioniert, weiß genau, was er tut. Und auch in vielen nicht ganz so klaren Fällen hat der Entwickler durchaus die Möglichkeit, die Implikationen seiner Arbeit abzuschätzen.
Zum anderen gelten die Regeln der Moral auch für die Arbeit selbst; die Beachtung der Urheberrechte, der Respekt vor der Intimsphäre der Kollegen und Kunden, die Fairness gegenüber einem Partner: Dies alles sind Forderungen, die täglich an uns gestellt sind.
Die Diskussion über ethische Aspekte unserer Arbeit hat in den Neunzigerjahren in den Berufsverbänden dazu geführt, dass ethische Leitlinien aufgestellt wurden (so von der Gesellschaft für Informatik (GI, 2004) wie auch von der IEEE-Computer Society und der ACM, IEEE-CS/ACM, 1999). Wir respektieren den Versuch, sehen aber im Resultat keine erhebliche Verbesserung. Die Leitlinien sind nicht Fisch noch Fleisch: Einerseits setzen sie erkennbar auf die Codifizierung der Verhaltensregeln. Das leisten auch Gesetze. Aber die Formulierungen sind zu unbestimmt, um im konkreten Fall eine klare Richtung vorzugeben. Andererseits schrecken sie vor Sanktionen zurück. Wir haben damit Regeln, die nichts Genaues sagen und auch niemals durch eine Jury, ein Schiedsgericht, konkretisiert und angewendet werden.
Diese Kritik gilt nicht für alle Leitlinien in gleichem Maße. Ausgesprochen rührend lesen sich die Regeln im Australian Computer Society Code of Ethics (Australian Comp. Society, 2004); man hat den Eindruck, sie seien aus einem Pfadfinder-Buch entlehnt. Zitat:
• 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.
Besonders ergreifend ist die Regel 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.
Da haben unsere Kollegen down under ja eine Menge zu tun!
Die deutschen Leitlinien gehören zu den besseren, weil sie gar nicht erst den Anspruch erheben, ihren Lesern einen Verhaltenskatechismus zu liefern. Zitate:
• 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 Kundenorganisationen in Konflikt mit der Verantwortung gegenüber anderweitig Betroffenen stehen, mit Zivilcourage zu handeln.
Jeder, der Informatik treibt, sollte sich diese Leitlinien ansehen. Vermutlich wird kaum einer dadurch zu einem besseren Menschen; aber vielleicht erkennt mancher kritische Punkte, die er bislang übersehen hatte.
Der britische Philosoph Bertrand Russell (1872–1970) hat geschrieben, dass wir Liebe und Wissen brauchen, um gut miteinander leben zu können (Russell, 1925: »The good life is inspired by love and guided by knowledge.«). Das ist unmittelbar auf das Software Engineering anwendbar: 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.