Personalauswahl in der Softwareentwicklung

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Aufbau der Arbeit

2 Softwaremanagement
2.1 Der Software-Lebenszyklus
2.2 Das Software-Projektmanagement
2.3 Softwareentwicklung als Projektarbeit im Team
2.4 Software-Qualitätsmanagement
2.5 Risiken in IT-Projekten
2.5.1 Die Entwicklungsrisiken im Software-Projekt
2.5.2 Die Managementrisiken im Software-Projekt
2.5.3 Die sozialen Risiken im Software-Projekt
2.5.4 Aktuelle Studie zur Thematik: SUCCESS 2010
2.6 Ausgewählte Modelle und Methoden
2.6.1 CMMI™ Capability Maturity Model Integration
2.6.2 P-CMM™ People Capability Maturity Model
2.6.3 COCOMO Constructive Cost Modell

3 Das Personal in der Softwareentwicklung
3.1 Einordnung der Personalgruppen
3.1.1 Die Situation am Arbeitsmarkt in Deutschland
3.1.2 Die Sicht des Software Engineering
3.1.3 Die Softwareentwicklung im Unternehmen Microsoft™
3.2 Analyse der festgelegten Rollen
3.2.1 Anforderungsprofil für den Manager
3.2.2 Anforderungsprofil für den Entwickler
3.2.3 Anforderungsprofil für den Tester

4 Psychologische Grundlagen
4.1 Hard Skills vs. Soft Skills
4.2 Persönlichkeitsmodelle
4.2.1 Das Persönlichkeitsmodell nach Riemann
4.2.2 Das „Big Five“ Persönlichkeitsmodell
4.3 Erfahrung und Motivation
4.4 Psychologie in Teamstrukturen
4.4.1 Die Kommunikation
4.4.2 Koordination und Kooperation
4.5 Die Psychologie des Programmierers
4.6 Kommunikationstypen in der Softwareentwicklung
4.6.1 Entwickler-Kommunikationstypen
4.6.2 Projektleiter-Kommunikationstypen
4.6.3 Weitere Kommunikationstypen der Softwareentwicklung
4.7 Arbeitstätigkeitsanalyse

5 Exkurs: Auswahlverfahren im Personalmanagement
5.1 Schwerpunkt des HRM: Personalbeschaffung
5.2 Auswertung der Bewerbungsunterlagen
5.3 Das Einstellungsinterview
5.4 Assessment Center
5.4.1 Die Bedeutung von Assessment Centern in der Praxis
5.4.2 Aufbau und Konzeption
5.4.2.1 Die Postkorbübung
5.4.2.2 Vorträge und Präsentationen
5.4.2.3 Gruppendiskussionen
5.4.2.4 Rollenspiele und Gruppenaufgaben
5.4.2.5 Selbstvorstellung und Selbsteinschätzung
5.5 Eignungsdiagnostische Testverfahren
5.5.1 Test von Intelligenz und allgemeiner Leistungsfähigkeit
5.5.2 Persönlichkeitstests
5.5.2.1 Überblick
5.5.2.2 Das NEO Fünf-Faktoren Inventar
5.5.3 Fachliche Tests und Arbeitsproben
5.5.4 Das Leistungsmotivationsinventar nach Schuler & Prochaska

6 Die Vorbereitung der Expertenbefragungen
6.1 Grundlagen von Umfragetechniken
6.2 Festlegung von Befragungsmethodik
6.3 Die Gestaltung des Fragebogens
6.4 Die Interviewpartner

7 Auswertung der Interviews
7.1 Risiken in der Softwareentwicklung
7.2 Anforderungen an fachliche und soziale Kompetenzen
7.2.1 Anforderungen an den Manager
7.2.2 Anforderungen an den Entwickler
7.2.3 Anforderungen an den Tester
7.2.4 Zusammenfassung und Vergleich der Anforderungsprofile
7.3 Situation und Methoden im Personalmanagement

8 Konkrete Maßnahmen im HRM und Softwaremanagement
8.1 Optimierung der Personalauswahl für die Softwareentwicklung
8.1.1 Auswahlverfahren für den Manager
8.1.2 Auswahlverfahren für den Entwickler und Tester
8.1.3 Zwischenfazit
8.2 ICP – Individual Competence Portfolio
8.2.1 Inhalt und Struktur von ICP
8.2.2 Integration von ICP in den Software-Entwicklungsprozess

9 Abschluss
9.1 Zusammenfassung
9.2 Ausblick

Verzeichnis der verwendeten wissenschaftlichen Quellen

Anhang 1: Beispiel - Anforderungsprofil Web-Entwickler

Anhang 2: Fragebogen bzw. Leitfaden für Interviews

Abstract

Die vorliegende Diplomarbeit analysiert verschiedene personelle Aspekte in der Softwareentwicklung. Ein Schwerpunkt leitet sich direkt aus der Themenstellung ab und liegt damit bei der Personalauswahl und Eignungsdiagnostik für die unterschiedlichen Personengruppen. Zu diesem Zweck werden die einzelnen Aufgabenbereiche umfassend beschrieben und in ein verallgemeinertes Modell eines Entwicklungsteams mit 3 Rollen überführt. Insbesondere die sozialen Kompetenzen der Mitarbeiter begleiten den gesamten Verlauf der Thesis. Weiterhin werden typische Risiken mit personellen Einflussfaktoren in der Softwareentwicklung herausgearbeitet und bewertet. Ausgewählte Grundlagen der berufsorientierten Psychologie und des Personalmanagements bilden den Mittelteil dieser Ausarbeitung. Erkenntnisse aus verschiedenen aktuellen Studien fließen im Verlauf an passender Stelle ein. Auf Basis dieses Bearbeitungsstandes erfolgt die Vorbereitung, Durchführung und Auswertung von Experteninterviews zur vorliegenden Thematik. Abschließend werden konkrete Maßnahmen vorgestellt, wie eine optimierte Personalauswahl in das Risikomanagement der Softwareentwicklung integriert werden kann und damit langfristig die Softwarequalität und den Projekterfolg positiv beeinflusst.

Abbildungsverzeichnis

Abbildung 1: Das Software-Entwicklungsteam

Abbildung 2: Persönlichkeitsmodell nach Riemann (Marré, 1995)

Abbildung 3: Die drei großen „K“ der Teamarbeit (Marré, 1995)

Abbildung 4: Das Fünf-Phasen-Modell der Kommunikation (Marré, 1995) (Jenny, 1998)

Abbildung 5: Fünf Phasen der Personalauswahl (Lindner-Lohmann, et al., 2008)

Abbildung 6: Das Programm GrafStat 2010

Abbildung 7: Interviewpartner für Expertengespräche

Abbildung 8: Bewertung der Risiken in Softwareprojekten

Abbildung 9: Anforderungen an die Rolle „Projektmanager“

Abbildung 10: Anforderungen an die Rolle „Entwickler“

Abbildung 11: Anforderungen an die Rolle „Tester“

Abbildung 12: Vergleich der Anforderungsprofile

Abbildung 13: Auswertung eines DNLA Persönlichkeitstests

Abbildung 14: Auswahlverfahren für den Manager bzw. Projektleiter

Abbildung 15: Auswahlverfahren für den Entwickler bzw. Tester

Abbildung 16: Integration von ICP in den Entwicklungsprozess

Tabellenverzeichnis

Tabelle 1: Der Software-Lebenszyklus (Dumke, 2001)

Tabelle 2: Einteilung von Softwareprojekten (Ludewig, et al., 2010) (Jenny, 1998)

Tabelle 3: Merkmale von Teamstrukturen (Ludewig, et al., 2010) (Dumke, 2001)

Tabelle 4: Qualitätsmerkmale der ISO/IEC 9126-1 (Balzert, 2008)

Tabelle 5: Entwicklungsrisiken in der Softwareentwicklung

Tabelle 6: Managementrisiken in der Softwareentwicklung

Tabelle 7: Soziale Risiken in der Softwareentwicklung

Tabelle 8: Bestätigte Hypothesen der SUCCESS-Studie (Buschermöhle, et al., 2010)

Tabelle 9: Ausgewählte Prozessbereiche des Modells CMMI (Wallmüller, 2007)

Tabelle 10: Die grundlegenden Prinzipien des People CMM (Curtis, et al., 2009)

Tabelle 11: Einflussfaktoren in COCOMOII (Balzert, 2008) (Ludewig, et al., 2010)

Tabelle 12: Die Rollen in der Softwareentwicklung

Tabelle 13: Räumliche Dimension nach Riemann (Marré, 1995)

Tabelle 14: Zeitliche Dimension nach Riemann (Marré, 1995)

Tabelle 15: Das Fünf-Faktoren Persönlichkeitsmodell „Big Five“

Tabelle 16: Persönlichkeitsbedingte Einflüsse in Team und Projekt (Balzert, 2008)...

Tabelle 17: Entwickler-Kommunikationstypen (Vigenschow, et al., 2007)

Tabelle 18: Projektleiter-Kommunikationstypen (Vigenschow, et al., 2007)

Tabelle 19: Weitere spezielle Kommunikationstypen (Vigenschow, et al., 2007)

Tabelle 20: Auswertungskriterien von Bewerbungsunterlagen (Schuler, 2000 S. 80).

Tabelle 21: Das Multimodale Interview (Schuler, 2002) (Lindner-Lohmann, et al., 2008)

Tabelle 22: Die Anforderungsdimensionen in Assessment Centern

Tabelle 23: Berufsorientierte FFM-Persönlichkeitsprofile (Howard, et al., 2008 S. 140 f.)

Tabelle 24: Dimensionen des Leistungsmotivationsinventars LMI (Schuler, et al., 2001)

Tabelle 25: Merkmale von Befragungen (Berekoven, et al., 2006)

Tabelle 26: Inhaltliche Strukturierung des Fragebogens

Tabelle 27: Spezielle Persönlichkeitsprofile in der Softwareentwicklung

Tabelle 28: Modell eines speziellen ICP

Tabelle 29: Werte der personenbezogenen COCOMO-Faktoren (Ludewig, et al., 2010)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation

„Eine ganz e Menge Chaos in IT-Projekten hat ihren Ursprung darin, dass man diese Rollen 1 vermisch t oder falsch besetzt. Wenn man einen Entwickler, dem sch o n das Wort ‚Dokumentation‘ Unwohlsein hervorruft, zum Projektmanager und damit aus seiner Sicht zum Bürokraten macht, ist der Untergang vorprogrammier t.“ nach (Janßen, 2005 S. 268)

Dieses einleitende Zitat hat direkten Bezug zur Motivation der vorliegenden Arbeit. Es existieren zahlreiche wissenschaftliche Analysen und Methoden zur technischen und organisatorischen Verbesserung des gesamten Software- Lebenszyklus. Ganze Wirtschaftsbereiche leben von der Forschung, Produktion und Vermarktung von Werkzeugen bzw. Modellen, die den Prozess der Softwareentwicklung schneller, billiger, präziser, risikoärmer usw. gestalten können. Alle diese Produkte haben sicher ihre Berechtigung und in vielen Fällen einen nachweisbaren Nutzen. Grundsätzlich wird es aber auch in absehbarer Zukunft dabei bleiben, dass jedes Softwareprodukt ein indirektes Abbild der geistigen Tätigkeit von Menschen ist, wobei die Funktionalität die sichtbare Umsetzung der virtuellen Ideen darstellt. Die unterschiedlichen Programmiersprachen sind dabei lediglich eine gemeinsame Kommunikations- ebene zwischen Mensch und Maschine.¹

Was bedeutet das für die Organisationen, die sich mit der Entwicklung und Verbreitung von Softwareprodukten beschäftigen? Das beteiligte Personal ist einerseits ihr wichtigstes und wertvollstes Vermögen, gleichzeitig aber auch der größte Kosten- und Risikofaktor (Sommerville, 2001). Zwar trifft dieses Merkmal ebenfalls auf andere produzierende Bereiche in der Wirtschaft zu. Softwareentwicklung hat aber einige Besonderheiten, die sich so z. B. im klassischen Handwerk oder der Industrie nicht wiederfinden².

Aus diesen besonderen Eigenheiten resultiert, dass die Konsequenzen personeller Fehlentscheidungen im Bereich der Softwareentwicklung erst erheblich später erkennbar sind, als beispielsweise im oben erwähnten klassischen Handwerk. Entsprechend höher sind die Kosten bzw. Verluste, die aus solchen Fehlbesetzungen resultieren. Dass allein die finanziellen Verluste innerhalb kürzester Zeit fünf- oder sechsstellige Summen erreichen können, sollte schnell klar werden. Eine genaue Untersuchung und Bewertung der möglichen materiellen und ideellen Risiken gehört aber nicht zur Zielstellung. Wesentlichen Einfluss auf die Qualität von Entwicklungsprozess und Produkt haben die persönlichen Kompetenzen aller beteiligten Mitarbeiter und deren optimaler Einsatz in den verschiedenen Bereichen der Gesamtorganisation.

1.2 Zielsetzung

Ziel dieser Arbeit ist u.a. eine Analyse der unterschiedlichen Aufgaben und speziellen fachlichen bzw. sozialen Anforderungen an das Personal in der Softwareentwicklung. Dazu sollen einleitend die wesentlichen Risikobereiche herausgearbeitet werden, hier insbesondere diejenigen Risiken mit personellen Einflussgrößen. Diesbezüglich bereits bestehende Modelle und Methoden sollen in die Betrachtungen einfließen. Da sich der gesamte Softwareentwicklungsprozess wesentlich auf interpersonelle geistige Aktivitäten stützt, sollen die entsprechenden psychischen Grundlagen erarbeitet werden. Besondere Aufmerksamkeit muss dabei den sozialen Kompetenzen und der Kommunikation zukommen. Richtungsentscheidend für eine optimale Teamzusammenstellung ist die Personalauswahl. Dazu sollen mit Blick auf die Softwareentwicklung allgemein übliche Methoden der Berufseignungsdiagnostik analysiert und vorgestellt werden. Für die soeben beschriebene Thematik existieren nur wenige aktuelle wissenschaftliche Unterlagen. Um einen Überblick über die momentane personelle Situation in der Softwareentwicklung zu bekommen, soll die Anfertigung dieser Diplomarbeit durch Experteninterviews begleitet werden. Insbesondere eine tendenzielle Gewichtung der fachlichen und sozialen Kompetenzen an ausgewählte Rollen im Entwicklungsteam soll ermittelt werden. Am Ende der Arbeit sollen Möglichkeiten vorgestellt werden, wie diese Erkenntnisse innerhalb einer optimierten Personalauswahl und Eignungsdiagnostik den gesamten Entwicklungsprozess positiv beeinflussen können. Gleichzeitig soll damit die Grundlage geschaffen werden, um personell bedingte Risiken bei der Softwareentwicklung früher zu erkennen, besser zu bewerten, effektiver zu behandeln und ggf. vollständig vermeiden zu können.

1.3 Aufbau der Arbeit

Kapitel 2 : Einleitend werden ausgewählte Bereiche des Softwareprojekt- managements, insbesondere diejenigen mit Bezug auf personelle und qualitative Aspekte behandelt. Der zweite Teil beschäftigt sich mit aktuellen Risiken in IT-Projekten und betrachtet weiterhin ausgewählte Rahmen- und Prozessmodelle mit personellen Einflussgrößen.

Kapitel 3 : In diesem Teil der Arbeit werden die verschiedenen typischen Personengruppen der Softwareentwicklung herausgearbeitet und analysiert. Für den weiteren Verlauf der Arbeit wird ein allgemeines Modell mit den drei Rollen Manager, Entwickler und Tester vorgeschlagen und mit den entsprechenden fachlichen und sozialen Anforderungsprofilen ausgestattet.

Kapitel 4 : Dieses Kapitel behandelt den Softwareentwicklungsprozess im Team aus psychologischer Sicht und bringt dem Leser wichtige Begriffe und Zusammenhänge näher. Nachdem zwei Persönlichkeitsmodelle vorgeschlagen wurden, widmen sich die weiteren Abschnitte schwerpunktmäßig der Kommunikation und den speziellen Charakteren im Entwicklungsteam.

Kapitel 5 : Personalauswahlverfahren und die unterstützenden Methoden der Eignungs-Diagnostik fallen in den Bereich des Personalmanagements. Um ein besseres Gesamtverständnis dieser Arbeit zu ermöglichen und als Basis für nachfolgende Inhalte wird ein Exkurs in diesen Wissenschaftsbereich unternommen.

Kapitel 6 : Die bis zu diesem Zeitpunkt herausgearbeiteten Erkenntnisse sollen mit Informationen und Erfahrungen aus der IKT-Praxis untermauert bzw. ergänzt werden. Zu diesem Zweck wird eine Expertenbefragung vorbereitet und durchgeführt.

Kapitel 7 : Die verwertbaren Ergebnisse der Experteninterviews werden vorgestellt und beurteilt. Die drei Hauptschwerpunkte sind dabei: die Projektrisiken, die personellen Anforderungen und das praktische Vorgehen in der Personalauswahl.

Kapitel 8 : Im letzten Kapitel dieser Diplomarbeit werden Möglichkeiten für eine Optimierung der Auswahlverfahren und Eignungsdiagnostik für das Personal der Softwareentwicklung vorgestellt. Der zweite Abschnitt befasst sich mit einer Idee zur ganzheitlichen Verbesserung des Risikomanagements und weiterer, personell beeinflusster Prozesse über das Bewerberverfahren hinaus.

2 Softwaremanagement

Gemäß Balzert (2008) lässt sich das Softwaremanagement in elf voneinander abgrenzbare Segmente gliedern. Für einen zügigen Einstieg in die gesamte Problematik bietet es sich an, zunächst einen Überblick über diejenigen Bereiche des Softwaremanagements zu geben, welche für den weiteren Verlauf der Arbeit von Bedeutung sind. Hierzu gehören neben dem eigentlichen Projektmanagement das Risikomanagement und die Qualitätssicherung, wobei Balzert (2008) letztere vom direkten Softwaremanagement klar trennt. Begleitet, standardisiert und qualifiziert werden die Entwicklungsprozesse zunehmend durch Rahmenmodelle, deren Betrachtung den Abschluss dieses Kapitels bildet. Im Fokus des Softwaremanagements stehen selbstredend unterschiedlichste Softwareprodukte. Sie durchlaufen, ähnlich wie jedes harte Produkt, einen speziellen Lebenszyklus. Dieser umfasst deutlich mehr als den reinen Prozess der Entwicklung. Auch wenn die Zielstellung dieser Arbeit primär auf eine positive Beeinflussung des Entwicklungsprozesses abzielt, soll einleitend ein Blick auf den gesamten Lebenszyklus eines Softwareprodukts geworfen werden.

2.1 Der Software-Lebenszyklus

Gemäß der Norm ISO/IEC 12207 als allgemeines Prozessmodell ist der gesamte Lebenszyklus eines Softwareproduktes in diese drei Hauptkategorien eingeteilt.

1. Primäre Prozesse
2. Unterstützungsprozesse
3. Organisationsweite Prozesse

Der primäre Prozess beschreibt die grundlegenden unternehmerischen Aktivitäten und Aufgaben wie Akquise, Entwicklung, Betrieb, Wartung usw. Daneben gelagert finden sich die sog. Unterstützungsprozesse, wie z.B. Verifikation, Dokumentation oder Qualitätssicherung. Die dritte, darüber gelagerte Prozessgruppe bezieht sich auf organisationsweite Strategien hinsichtlich des Managements, der Prozessverbesserung, der Infrastruktur oder des Personaltrainings (Wallmüller, 2007). Aus Produktsicht umfasst der Software-Lebenszyklus die drei Phasen Entwicklung, Anwendung und Softwarewartung. Den Zusammenhang stellt die folgende Tabelle Nr. 1 dar.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Der Software-Lebenszyklus (Dumke, 2001)

Die Softwareanwendung und -wartung sind parallele Prozesse, die sich unmittelbar der Entwicklung anschließen bzw. sich zyklisch mit dieser abwechseln. Da es im aktuellen Kontext wesentlich um das Personal bei der Softwareentwicklung geht, müssen die Merkmale und Inhalte der einzelnen Stufen (z.B. Prozess- und Vorgehensmodelle, Methoden, Paradigma, Organisationsformen, Tools etc.) nicht weiter erläutert werden. Einem ganzheitlichen Blick auf den Entwicklungsprozess und seinen Teilnehmern soll aber etwas Raum gewährt werden. Zwischen Frick (1995) und Balzert (2001) besteht Übereinkunft, dass die gesamte Softwareentwicklung auf den drei Säulen Management, Entwicklung und Qualitätssicherung ruht. Der gesamte Lebenszyklus wird über alle Phasen zwischen diesen drei Instanzen organisiert und begleitet. Die vierte aktive, aus Entwicklungssicht externe Instanz ist der Anwender, wobei dieser oft gleichzeitig direkter oder indirekter Auftraggeber ist. Für das personelle Management innerhalb der Softwareentwicklung hat er natürlich keine Bedeutung, die Kommunikation zum Anwender ist aber essentiell für einen erfolgreichen Entwicklungsprozess. Hingewiesen sei hier besonders auf die Inhalte der Unternehmenskultur. Diese haben maßgeblichen Anteil am Entwicklungserfolg und beruhen dabei zum großen Teil auf den verschiedenen sozialen Kompetenzen der Beteiligten. An dieser Stelle wird gleichzeitig sehr deutlich, dass Softwareentwicklung maßgeblich auf vielfältigen Kommunikationsprozessen ruht.

2.2 Das Software-Projektmanagement

Es ist üblich, im Zusammenhang mit der Softwareentwicklung von Projekten bzw. Projektmanagement zu reden. Hierbei existieren neben partiellen Gemeinsamkeiten, große Unterschiede gegenüber der klassischen Entwicklung, Fertigung und Vermarktung von „harten“ Produkten. In den dortigen Bereichen dominiert eher das typische Produktmanagement. Folglich sind auch Differenzen bei den Anforderungen an die jeweiligen Personalgruppen zu erwarten. Die besonderen Eigenschaften von Softwareprojekten und Anforderungen an das Softwaremanagement sollen in diesem Abschnitt beleuchtet werden, zumal es auch Überschneidungen mit dem Personalmanagement gibt. Schon die Bedeutung des Wortes „Projekt“ impliziert eine gewisse Einmaligkeit und Abgrenzung (Lebenszyklus). In Ludewig et al. (2010 S. 92 f.) wird das Projekt, insbesondere aus der Sicht der Softwareentwicklung, allgemein wie folgt definiert.

- Die gesamte Laufzeit ist begrenzt.
- Ein „Erzeuger“ (gleich Projekteigentümer oder Vertreter, oft höheres Management) initiiert das Projekt und bestimmt den Projektleiter.
- Ein Projektzweck (meist Produkt) ist definiert und als Bündel von Zielen beschrieben. Die Zielerreichung ist Maß für den Projekterfolg.
- Die Entwicklung erfolgt für einen oder mehrere Abnehmer (gleich Auftraggeber, Kunde) und verschiedene Anwendergruppen.
- Durch das Projekt werden Menschen, Resultate und Hilfsmittel (Ressourcen) verbunden. Alle Rollen, Beziehungen und Schnittstellen des Projekts werden durch die Organisation definiert

Die wesentlichen Besonderheiten im Management der Softwareentwicklung werden u.a. durch Balzert (2008) und Sommerville (2001) aufgegriffen und sind nachstehend zusammengefasst. Diese beschreiben gleichzeitig die spezielle Abgrenzung zum klassischen Produktmanagement.

- Das Ergebnis (Produkt) ist nicht greifbar, der Entwicklungsfortschritt ist schlecht kontrollierbar und nur indirekt aus den Dokumentationen ableitbar.
- Besonders große Projekte neigen zur Einmaligkeit und sind schlechter vergleichbar mit früheren Entwicklungen.
- Technologien entwickeln sich rasant weiter bzw. sind schnell überholt.
- Prozess- und Qualitätsmodelle des Software Engineerings sind vergleichsweise jung und es existieren keine standardisierten Herstellungsprozesse.
- Teilaufgaben sind oft hochspezifisch und schlecht delegierbar und/oder teilbar.
- Es besteht ein hoher Grad der Abstraktion und Formalisierung.
- Softwareentwicklung basiert auf keiner Naturwissenschaft mit beweisbaren Prinzipien und nur Teilbereiche sind empirisch bestätigt.

Verschiedene Projekte lassen sich in Abhängigkeit ihrer Zielsetzung und des Auftraggebers formal klassifizieren. Die nach Jenny (1998) und Ludewig et al. (2010) verbreitetesten Projekttypen sind in der folgenden Tabelle Nr. 2 aufgeführt und kurz beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Einteilung von Softwareprojekten (Ludewig, et al., 2010) (Jenny, 1998)

Wenn in den folgenden Betrachtungen allgemein von Softwareprojekten gesprochen wird, so sei dabei speziell das Auftragsprojekt gemeint. Mit Blick auf die Besonderheiten des Software-Projektmanagements ergeben sich innerhalb der verschiedenen Projekttypen eine Reihe wiederkehrender und allgemeingültiger Aufgaben für das Management. Die speziellen fachlichen und persönlichen Anforderungen an die verschiedenen Personengruppen incl. der Rolle Manager sind Gegenstand der nachfolgenden Kapitel. Auch wenn die Aufgabenverteilung zwischen verschiedenen Organisationen und einzelnen Projekten sehr variiert, sollen nun die grundlegenden und wichtigsten Aufgaben zusammengefasst werden. Nach Jenny (1998 S. 62) lassen sich drei Hauptaufgabengebiete abgrenzen. Diese lauten:

- Institutionelles Projektmanagement (Ressourcenplanung, Infrastruktur)
- Funktionelles Projektmanagement (Ablaufplanung, Controlling)
- Projektleitung/Projektführung (zwischenmenschliche Aspekte)

Mit Blick auf den Schwerpunkt dieser Arbeit sei hier auf eine weitere Analyse und Beschreibung der Teilaufgaben verzichtet bzw. auf das folgende Kapitel 3, dabei speziell auf den Abschnitt 3.2.1 (S. 34 ff.), hingewiesen.

2.3 Softwareentwicklung als Projektarbeit im Team

Moderne, effiziente und damit wettbewerbsfähige Softwareentwicklung lässt sich ohne organisierte Team- und Führungsstrukturen kaum noch realisieren. Nach Dumke (2001) gibt es mehrere Motivationen oder Notwendigkeiten, die zur Bildung von Entwicklungsteams führen. Im Wesentlichen liegen diese in der Komplexität, Zeitbegrenzung und Vielschichtigkeit der Aufgabenstellung resp. im Bedarf nach umfangreicher fachlicher Kenntnis und Erfahrung begründet. Im vorangegangenen Abschnitt wurde einführend das Softwaremanagement beschrieben. Eine der wesentlichen Aufgaben dieser Instanz ist die Zusammenstellung und Arbeitsorganisation funktionierender Entwicklungsteams und deren synergetische Integration in das Gesamtprojekt. Die Aufgabenverteilung innerhalb eines speziellen Teams soll später intensiver beleuchtet werden. Zu diesem Zeitpunkt ist es aber nützlich, einen grundlegenden Blick auf die möglichen Formen der Teamorganisation zu werfen. Auch hier ist zu bemerken, dass es sich um idealisierte Modelle handelt, die sich gleich dem Projektmanagement an jeweilige Anforderungen und Umgebungen dynamisch anpassen. Ab einer bestimmten Projektgröße werden innerhalb des Gesamtteams wieder kleinere Einheiten (Teilprojekt) gebildet, um neben einer Spezialisierung eine effektive Kommunikation zu gewährleisten.³ In Anlehnung an Dumke (2001) und Ludewig, et al. (2010) gibt die folgende Tabelle Nr. 3 eine Übersicht über mögliche Kriterien der Einteilung und Unterscheidung von Teamstrukturen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Merkmale von Teamstrukturen (Ludewig, et al., 2010) (Dumke, 2001)

Die Bedeutung des Software-Managements bei der Zusammensetzung und Führung von Entwicklungsteams wird von Balzert (2008) besonders hervorgehoben und untermauert dabei gleichzeitig auch die Notwendigkeit einer optimalen Personalauswahl und von günstigen Rahmenbedingungen (hier am Beispiel der Spezifikation) für eine erfolgreiche Softwareentwicklung:

1. Auch mit fachlich durchschnittlichem Personal kann ein Projekt durch gute Führung sehr erfolgreich sein.
2. Ein schlecht geführtes Projekt wird auch mit bestem Personal niemals zum Erfolg führen.
3. Ein fachlich durchschnittliches Entwicklerteam kann ein System mit guter Architektur erstellen.
4. Aus einer schlechten Architektur kann auch ein Expertenteam kein erfolgreiches Produkt entwickeln.

Die hier erstmalig erwähnten sozialen Kompetenzen „Teamfähigkeit“ und „Kommunikation“ werden als wichtige Voraussetzungen erfolgreicher Projekttätigkeit im Zentrum der weiteren Betrachtungen stehen.

2.4 Software-Qualitätsmanagement

Im einleitenden Kapitel wurde unter anderem die Sicherung bzw. Steigerung der Softwarequalität als erwartete Konsequenz einer optimierten Personalauswahl aufgeführt. Es bietet sich daher an, dieser Thematik etwas genauere Aufmerksamkeit zu widmen. Insgesamt stellt sich die Softwarequalität aus dem Zusammenspiel verschiedener Qualitätsaspekte über den gesamtem Projektzeitraum dar. Nach Ludewig, et al. (2010) gruppieren sich diese Aspekte in Projektqualität, Wartungsqualität und Gebrauchsqualität. Dabei wird direkt der Zusammenhang mit der Tabelle 1 (Software- Lebenszyklus, S. 5) ersichtlich. Einen übergeordneten Einfluss auf alle Phasen hat die Prozessqualität, auch wenn sie direkt nur auf den Projektablauf (Softwareentwicklung) wirkt. An genau dieser Stelle kommen auch die personellen Einflüsse, bedingt durch individuelle Kompetenzen, Teamzusammensetzung, Projektmanagement usw., zum Tragen. Die einzelnen Aspekte werden durch das Qualitätsmanagement entsprechend den Anforderungen in weitere Bereiche mit zahlreichen Unterkategorien aufgeteilt. Dieses soll hier aber nicht weiter betrachtet werden, der interessierte Leser sei hier auf (Ludewig, et al., 2010 S. 65 ff.) hingewiesen. Eine inhaltliche Erläuterung des Begriffs „Softwarequalität“ erscheint jedoch angebracht. Es ist nicht möglich, die Softwarequalität per se allgemeingültig zu definieren, um daraus eine direkte Messbarkeit oder Vergleichbarkeit abzuleiten. Daher wurden für eine praktikable Anwendung verschiedene Qualitätsmodelle entwickelt, die verschiedene Qualitätsmerkmale (factors) enthalten. Letztere werden solange in weitere Teilmerkmale (criterions) verfeinert, bis jedes einzelne Kriterium am Ende ein messbarer Indikator (metrics) ist. Daraus ergibt sich ein hierarchisches Konstrukt, welches auch als FCM-Modell bezeichnet wird (Factor-Criteria-Metrics-Model). Meist handelt es sich um baumartige Strukturen, an deren Wurzel die Softwarequalität als abstrakter Ausgangspunkt zu finden ist. Das wohl bekannteste FCM-Modell ist die internationale Norm ISO/IEC 9126-1, über welche die Softwarequalität mit Schwerpunkt der Produktqualität beschrieben und abgesichert werden kann. Die Norm ist derart angelegt, dass sie auf alle erdenklichen Softwareprodukte angewendet werden kann. Die ISO/IEC 9126-1 setzt sich formal aus sechs Qualitätsmerkmalen (factors) mit insgesamt 26 Untergruppen (subcharacteristics) zusammen (Balzert, 2008). Eine Übersicht dieses Qualitätsmodells stellt die folgende Tabelle Nr. 4 dar.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Qualitätsmerkmale der ISO/IEC 9126-1 (Balzert, 2008)

Alle definierten 26 Untergruppen sind in dieser Form so noch nicht messbar und müssen entsprechend des FCM-Modells in weitere Kriterien zerlegt werden. Ein Beispiel für ein messbares Kriterium der Effizienz ist der Bedarf von Hardwareressourcen (Speicherbedarf, Prozessorlast) über die Laufzeit. Interne Metriken (z.B. Fehlerentdeckungsrate, Installationsaufwand, Schnittstellenklarheit etc.) werden in der ISO/IEC 9126-3 beschrieben, externe Maße beschreibt die ISO/IEC 9126-2 beispielsweise über Latenzverhalten oder Testüberdeckung (Balzert, 2008).

Die bis hierhin beschriebenen Vorgehensweisen einer Qualitätssicherung für das Softwareprodukt sind weitgehend analytischer Natur, wobei hier noch zwischen statischen und dynamischen Maßnahmen unterschieden wird. Für die Gewährleistung einer gesamten Prozessqualität⁴ beschreibt Frick die konstruktive Qualitätssicherung als wichtige Voraussetzung:

„ Kon st ru ktive Qu alit ätssich er ung zielt […] darauf ab, den Entwicklungsprozeß in organisatorischer, technischer und sozialer Hinsicht so zu gestalten, daß die En twickl ung von Softwareprodukten mit spezifizierten Qualitätsanforderungen mög lich wird. I m Brennpunkt stehen dabei Maßnahmen die es ermöglichen, von vornherein Fehler zu vermeiden anstatt sie später mühsam herauszufinden.“

(Frick, 1995 S. 301)

Insbesondere die Maßnahmen und Bedingungen im sozialen Bereich sollen hier hervorgehoben werden. Dazu gehören zunächst eine bewusste und aktive Auseinandersetzung und Identifikation mit internen Gepflogenheiten bzw. Leitsätzen, den Geschäftspartnern, der Kultur, der Geschichte, dem Gesamtportfolio und der Marktpositionierung des Unternehmens. Als wichtigste Punkte des sozialen Bereiches sind eine zielführende und nutzenorientierte Kommunikation, Kooperation und Koordination zu nennen. Diese Merkmale werden intensiver im Kapitel 4.4 (Psychologie in Teamstrukturen, S. 49 ff.) behandelt. Beeinflusst und gesteuert werden die sozialen Rahmenbedingungen durch verschiedene Ebenen des Managements, insbesondere durch die Bereiche Personal (HRM) und Projektmanagement (Frick, 1995).

2.5 Risiken in IT-Projekten

Dieser Themenblock behandelt die möglichen Risiken im Zuge einer Softwareentwicklung. Es geht hier zunächst um eine theoretische Recherche auf Basis aktueller Literatur. Der Schwerpunkt muss natürlich bei den personell bedingten Risiken liegen. Speziell für das Projektrisiko gibt es unterschiedliche Definitionen. In Anlehnung an Jenny (1998) und Gaulke (2002) sei hier folgende eigene Definition zu Grunde gelegt.

Das Projektrisiko beschreibt die Höhe des materiellen oder ideellen Schadens, den eine Organisation durch unvollständiges Erreichen oder komplettes Verfehlen der vereinbarten Projektziele, resultierend aus unvorhersehbaren oder unterbewerteten Risikofaktoren, erleidet.

Um die Projektrisiken innerhalb einer Organisation zu minimieren, müssen alle erdenklichen Risikofaktoren erfasst, bewertet und berücksichtigt werden. Diese Arbeit ist der Instanz „Risikomanagement“ im Verantwortungsbereich des Projektmanagements zugeordnet. Bei einer Forsa-Umfrage zu den wichtigsten Störfaktoren innerhalb der Projektentwicklung steht die „Fehleinschätzung von Projektrisiken“ an dritter Stelle, nach „unrealistischer Zeitschiene“ als wesentlichster Punkt und „externen Einflüssen“ auf Platz zwei. Aber auch die „personellen Fehlbesetzungen“ haben mit dem sechsten Platz eine entscheidende Bedeutung (Gaulke, 2002). In der aktuellen und sehr umfangreichen Studie SUCCESS (Buschermöhle, et al., 2010) wurden alle möglichen Risiken und somit Erfolgsfaktoren für deutsche IT-Projekte ermittelt und bewertet. Abschnitt 2.5.4 (S. 18 ff.) stellt einige Ergebnisse dar.

Auf Grund des unterschiedlich hohen Einflusses aller Risikofaktoren auf den gesamten Projekterfolg gibt es in der Literatur verschiedene Ansätze zur Kategorisierung, Bewertung und Kontrolle. Unter Betrachtung aller beteiligten internen bzw. externen Rollen und Bedingungen kommt Jenny (1998) zu dem Schluss, eine Aufteilung in Entwicklungsrisiken, Managementrisiken und sozialen Risiken vorzunehmen. Gleichzeitig wird dort von polarisierenden Werten gesprochen. Damit ist ein positiv wirkender Paradigmenwechsel vom Projektrisiko zum Erfolgsfaktor gemeint und bestätigt die Wichtigkeit eines ganzheitlichen Risikomanagements. Bei der vorgeschlagenen Einteilung der Faktoren sind gewisse Überschneidungen bzw. unterschiedliche Blickwinkel bei den Zuordnungen möglich. Dieses Modell soll aber dennoch aufgegriffen und insbesondere der Bereich „Soziale Risiken“ weiter verfolgt werden.

2.5.1 Die Entwicklungsrisiken im Software-Projekt

Die Faktoren des Entwicklungsrisikos beziehen sich hauptsächlich auf das erwartete Softwareprodukt und dessen Entwicklungsprozess. Die folgende Tabelle Nr. 5 gibt eine Zusammenstellung der wichtigsten Faktoren.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Entwicklungsrisiken in der Softwareentwicklung (Jenny, 1998) (Gaulke, 2002) (Sommerville, 2001) (Balzert, 2008)

2.5.2 Die Managementrisiken im Software-Projekt

In den Risiken des Projektmanagements liegen unbestritten die wesentlichen Ursachen für Misserfolge in Entwicklungsprojekten. Auch die beiden weiteren Risikogruppen⁵ sind zum Teil direkt oder indirekt vom Projektmanagement abhängig. Die sich nun anschließende Tabelle Nr. 6 vermittelt einen Überblick der wesentlichen Managementrisiken.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Managementrisiken in der Softwareentwicklung (Jenny, 1998) (Gaulke, 2002) (Sommerville, 2001) (Balzert, 2008)

2.5.3 Die sozialen Risiken im Software-Projekt

Wie bereits festgelegt, muss den sozialen Risiken eine erhöhte Aufmerksamkeit gewidmet werden, um später für verschiedene Rollen in der Softwareentwicklung spezielle Aussagen zur Eignungsdiagnostik tätigen zu können. Zunächst muss herausgearbeitet werden, welche personellen Risiken insgesamt in diesem Segment dominieren. Daher beinhaltet die folgende

Tabelle Nr. 7 auch die sozialen Risiken, die nicht direkt von den persönlichen Kompetenzen der einzelnen Projektbeteiligten abhängen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Soziale Risiken in der Softwareentwicklung (Jenny, 1998) (Gaulke, 2002) (Sommerville, 2001) (Balzert, 2008)

Es wird schnell ersichtlich, welche große Bedeutung dieser Risikogruppe im Projektmanagement zukommt. Einige in Tabelle 7 aufgeführte Faktoren werden über dieses Kapitel hinaus nicht weiter analysiert. Zum Beispiel ist eine hohe Mitarbeiterfluktuation durch ständige Überforderung ein wichtiger Risikofaktor und großes aktuelles Problem in vielen Unternehmen. Allerdings sind die Ursachen dafür oft im höheren Management angesiedelt und lassen sich kaum durch eine optimierte Personalauswahl abstellen. Hinsichtlich der bereits angedeuteten polarisierenden Werte für die einzelnen Risiken kann nun direkt auf folgende soziale bzw. persönliche Erfolgsfaktoren für die Zielerreichung geschlossen werden:

- Fachliche Kompetenz
- Kommunikation
- Soziale Kompetenz und Teamfähigkeit, auch interkulturell
- Charakter
- Erfahrung
- Motivation
- Identifikation mit dem Projekt bzw. der Organisation

Dies ist zunächst nur eine sehr allgemeine Auflistung individueller Eigenschaften. Wie diese eingeteilt, ermittelt und bewertet werden können, soll in den späteren Kapiteln intensiver untersucht werden.

2.5.4 Aktuelle Studie zur Thematik: SUCCESS 2010

Im Jahr 2006 wurde durch das OFFIS Institut für Informatik deutschlandweit eine Studie zu IT-Projektrisiken durchgeführt und in 2010 einer erweiterten Analyse unterzogen. Um die Bedeutung der Gesamtthematik dieser Arbeit weiter zu unterstreichen, werden nun ausgewählte Erkenntnisse vorgestellt.

Insgesamt wurden Daten über 378 Hard- und Softwareprojekte erhoben und weitere vergleichbare Studien (z.B. CHAOS-Report) bewertet. Es wurde ermittelt, dass etwa 51% aller Projekte komplett erfolgreich abgeschlossen wurden. Als Benchmark wurde dabei eine 100%ige Erfüllung aller geforderten Funktionen sowie die vollständige Einhaltung von Zeiträumen und Budgets angesetzt. Ca. 28% aller betrachteten Projekte wurden zu über 90% erfüllt und mit „gut“ oder „befriedigend“ benotet. Die restliche Menge verteilt sich auf die Noten „ausreichend“ (ca. 10%) bzw. „mangelhaft“ (ca. 11%), wobei die letzte Bewertung ein Nichterreichen von 68 Erfolgspunkten bedeutet (Buschermöhle, et al., 2010). Auch wenn die Situation zunächst nicht besorgniserregend scheint, so ist doch festzuhalten, dass jedes zweite IT-Projekt die drei festgelegten Bewertungskriterien für einen erfolgreichen Abschluss nicht vollständig erfüllte. Um die Gründe dafür erforschen zu können, wurden zu Beginn der Studie eine Reihe von insgesamt 22 Behauptungen hinsichtlich typischer Projekterfolgsfaktoren aufgestellt. Die Menge aller 12 nach Auswertung empirisch bestätigten Hypothesen wird in der folgenden Tabelle Nr. 8 vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Bestätigte Hypothesen der SUCCESS-Studie (Buschermöhle, et al., 2010)

Die personell resp. sozial beeinflussten Risikofaktoren sind in der Aufstellung durch einen dunkleren Hintergrund markiert. Auch an dieser Stelle bestätigt sich die Notwendigkeit, diesen Faktoren im Rahmen des Risikomanagements von IT-Projekten eine besondere Aufmerksamkeit zu widmen. Bemerkenswert sind abschließend zwei weitere Erkenntnisse. Hier wurde festgestellt, dass sich ein Anteil zwischen 20 und 40% an Auszubildenden insgesamt positiv auf die Teammotivation und somit auf den Grad des Projekterfolgs auswirkt. Weiterhin muss fehlende Erfahrung des Projektmanagers nicht zwingend negativ sein.

2.6 Ausgewählte Modelle und Methoden

Alle in diesem Kapitel bisher beschriebenen Aspekte haben das gemeinsame Ziel, Softwareprojekte erfolgreich in der geforderten Qualität zum Abschluss zu führen. Wie bereits durch die eben erläuterten Risiken deutlich wird, hat nicht nur der Entwicklungsprozess allein einen erheblichen Einfluss auf die Softwarequalität. Die Gesamtheit aller direkt oder indirekt beteiligten Prozesse und Rahmenbedingungen wirken sich auf das endgültige Entwicklungsergebnis aus. Daher ist es notwendig, sich über die Zusammenhänge, die Bedeutung, die Abgrenzung und natürlich die Qualität aller beteiligten Prozessbereiche (Anforderungsmanagement, Qualitätssicherung, Projektplanung usw.) ausreichend Klarheit zu verschaffen. Indem zunächst jeder dieser Bereiche separat beschrieben und vor allem bewertet wird, kann folglich für die gesamte Organisation eine qualitative IST-Situation erhoben werden. Zu diesem Zweck einer Bewertung und Verbesserung des gesamten Softwareprozesses wurden eine Reihe verschiedener Rahmen- bzw. Referenzmodelle entwickelt die durch spezielle Methoden, z. B. zur Kosten- und Aufwandsabschätzung, unterstützt bzw. in die Praxis umgesetzt werden können.

Ein allgegenwärtiges und aktuelles Modell ist zum Beispiel das Bewertungsverfahren SPICE (Software Process Improvement and Capability Determination), welches in der Norm ISO/IEC 15504 hinterlegt ist. Es wurde auf Basis der Erfahrungen aus dem Capability Maturity Model (CMM) und weiteren Ansätzen entwickelt und definiert sechs Reifegrade. Es besteht ein enger Zusammenhang zum definierten Software-Lebenszyklus gemäß ISO/IEC 12207, zudem existieren auch branchenspezifische Referenzmodelle, wie zum Beispiel Automotive SPICE™ (Ludewig, et al., 2010). Für aktuelle Arbeit soll der Schwerpunkt auf das Modell CMMI gelegt werden, welches nun etwas genauer erläutert wird. Im zweiten Teil wird Bezug auf das Reifegradmodell P-CMM genommen, mit welchen die personellen Ressourcen und Risiken in Projekten bzw. Organisationen gemanagt werden können. Den Abschluss bildet eine Betrachtung von COCOMO, einem Kosten- und Aufwandschätzmodell für Softwareentwicklungen mit großer Beachtung personeller Einflussgrößen.

[...]

---

¹ Anmerkung des Verfassers: sprich Verantwortlichkeiten/Aufgabenverteilung

² vgl. Abschnitt 2.2 (S. 6): Software-Projektmanagement

³ vgl. Abschnitt 4.4 (S. 49 ff.): Psychologie in Teamstrukturen

⁴ vgl. Abschnitt 2.6 (S. 19 ff.) Ausgewählte Modelle und Methoden

⁵ vgl. Abschnitt 2.5.1 (S. 14) bzw. 2.5.3 (S. 16)