Inhaltsverzeichnis Abstract I Inhaltsverzeichnis II Abbildungsverzeichnis V Tabellenverzeichnis VI Abkürzungsverzeichnis VIII 1 Einleitung 1 1.1 Motivation 1 1.2 Zielsetzung 2 1.3 Aufbau der Arbeit 3 2 Softwaremanagement 4 2.1 Der Software-Lebenszyklus 4 2.2 Das Software-Projektmanagement 6 2.3 Softwareentwicklung als Projektarbeit im Team 8 2.4 Software-Qualitätsmanagement 10 2.5 Risiken in IT-Projekten. 13 2.5.1 Die Entwicklungsrisiken im Software-Projekt 14 2.5.2 Die Managementrisiken im Software-Projekt 15 2.5.3 Die sozialen Risiken im Software-Projekt 16 2.5.4 Aktuelle Studie zur Thematik: SUCCESS 2010 18 2.6 Ausgewählte Modelle und Methoden 20 2.6.1 CMMI Capability Maturity Model Integration 20 2.6.2 P-CMM People Capability Maturity Model 23 2.6.3 COCOMO Constructive Cost Modell 25 3 Das Personal in der Softwareentwicklung 27 3.1 Einordnung der Personalgruppen 27 3.1.1 Die Situation am Arbeitsmarkt in Deutschland 27 3.1.2 Die Sicht des Software Engineering 28 3.1.3 Die Softwareentwicklung im Unternehmen Microsoft 31 3.2 Analyse der festgelegten Rollen 33 3.2.1 Anforderungsprofil für den Manager 34 3 2 2 Anforderungsprofil für den Entwickler 36 Otto-von-Guericke-Universität Magdeburg III 3.2.3 Anforderungsprofil für den Tester 37 4 Psychologische Grundlagen 39 4.1 Hard Skills vs. Soft Skills. 40 4.2 Persönlichkeitsmodelle 41 4.2.1 Das Persönlichkeitsmodell nach Riemann 42 4.2.2 Das „Big Five“ Persönlichkeitsmodell 44 4.3 Erfahrung und Motivation 47 4.4 Psychologie in Teamstrukturen 48 4.4.1 Die Kommunikation 51 4.4.2 Koordination und Kooperation 53 4.5 Die Psychologie des Programmierers 54 4.6 Kommunikationstypen in der Softwareentwicklung 56 4.6.1 Entwickler-Kommunikationstypen 57 4.6.2 Projektleiter-Kommunikationstypen 59 4.6.3 Weitere Kommunikationstypen der Softwareentwicklung 60 4.7 Arbeitstätigkeitsanalyse 62 5 Exkurs: Auswahlverfahren im Personalmanagement 64 5.1 Schwerpunkt des HRM: Personalbeschaffung. 64 5.2 Auswertung der Bewerbungsunterlagen 66 5.3 Das Einstellungsinterview 68 5.4 Assessment Center 70 5.4.1 Die Bedeutung von Assessment Centern in der Praxis 71 5.4.2 Aufbau und Konzeption 72 5.4.2.1 Die Postkorbübung 74 5.4.2.2 Vorträge und Präsentationen 75 5.4.2.3 Gruppendiskussionen 75 5.4.2.4 Rollenspiele und Gruppenaufgaben 76 5.4.2.5 Selbstvorstellung und Selbsteinschätzung. 77 5.5 Eignungsdiagnostische Testverfahren 77 5.5.1 Test von Intelligenz und allgemeiner Leistungsfähigkeit 78 5.5.2 Persönlichkeitstests 79 5.5.2.1 Überblick 79 5.5.2.2 Das NEO Fünf-Faktoren Inventar 80 5.5.3 Fachliche Tests und Arbeitsproben 82 5 5 4 Das Leistungsmotivationsinventar nach Schuler & Prochaska 82 Otto-von-Guericke-Universität Magdeburg IV 6 Die Vorbereitung der Expertenbefragungen 85 6.1 Grundlagen von Umfragetechniken 85 6.2 Festlegung von Befragungsmethodik 86 6.3 Die Gestaltung des Fragebogens 87 6.4 Die Interviewpartner 89 7 Auswertung der Interviews 90 7.1 Risiken in der Softwareentwicklung 90 7.2 Anforderungen an fachliche und soziale Kompetenzen 92 7.2.1 Anforderungen an den Manager 92 7.2.2 Anforderungen an den Entwickler 94 7.2.3 Anforderungen an den Tester 95 7.2.4 Zusammenfassung und Vergleich der Anforderungsprofile 96 7.3 Situation und Methoden im Personalmanagement 97 8 Konkrete Maßnahmen im HRM und Softwaremanagement 100 8.1 Optimierung der Personalauswahl für die Softwareentwicklung 100 8.1.1 Auswahlverfahren für den Manager 101 8.1.2 Auswahlverfahren für den Entwickler und Tester 102 8.1.3 Zwischenfazit. 103 8.2 ICP - Individual Competence Portfolio 104 8.2.1 Inhalt und Struktur von ICP 105 8.2.2 Integration von ICP in den Software-Entwicklungsprozess 107 9 Abschluss 111 9.1 Zusammenfassung 111 9.2 Ausblick 112 Verzeichnis der verwendeten wissenschaftlichen Quellen 113 Anhang 1: Beispiel - Anforderungsprofil Web-Entwickler 117 Anhang 2: Fragebogen bzw Leitfaden für Interviews 118 Otto-von-Guericke-Universität Magdeburg 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 Otto-von-Guericke-Universität Magdeburg VI Tabellenverzeichnis Tabelle 1: Der Software-Lebenszyklus (Dumke, 2001) 5 Tabelle 2: Einteilung von Softwareprojekten (Ludewig, et al., 2010) (Jenny, 1998) 8 Tabelle 3: Merkmale von Teamstrukturen (Ludewig, et al., 2010) (Dumke, 2001) 10 Tabelle 4: Qualitätsmerkmale der ISO/IEC 9126-1 (Balzert, 2008) 12 Tabelle 5: Entwicklungsrisiken in der Softwareentwicklung 15 Tabelle 6: Managementrisiken in der Softwareentwicklung 16 Tabelle 7: Soziale Risiken in der Softwareentwicklung 17 Tabelle 8: Bestätigte Hypothesen der SUCCESS-Studie (Buschermöhle, et al., 2010) 19 Tabelle 9: Ausgewählte Prozessbereiche des Modells CMMI (Wallmüller, 2007) 22 Tabelle 10: Die grundlegenden Prinzipien des People CMM (Curtis, et al., 2009) 24 Tabelle 11: Einflussfaktoren in COCOMOII (Balzert, 2008) (Ludewig, et al., 2010) 26 Tabelle 12: Die Rollen in der Softwareentwicklung 30 Tabelle 13: Räumliche Dimension nach Riemann (Marré, 1995) 42 Tabelle 14: Zeitliche Dimension nach Riemann (Marré, 1995) 42 Tabelle 15: Das Fünf-Faktoren Persönlichkeitsmodell „Big Five“ 45 Tabelle 16: Persönlichkeitsbedingte Einflüsse in Team und Projekt (Balzert, 2008) 49 Tabelle 17: Entwickler-Kommunikationstypen (Vigenschow, et al., 2007) 59 Tabelle 18: Projektleiter-Kommunikationstypen (Vigenschow, et al., 2007) 60 Tabelle 19: Weitere spezielle Kommunikationstypen (Vigenschow, et al., 2007) 61 Tabelle 20: Auswertungskriterien von Bewerbungsunterlagen (Schuler, 2000 S. 80) 67 Tabelle 21: Das Multimodale Interview (Schuler, 2002) (Lindner-Lohmann, et al., 2008) 69 Tabelle 22: Die Anforderungsdimensionen in Assessment Centern 73 Tabelle 23: Berufsorientierte FF-MPersönlichkeitsprofile (Howard, et al., 2008 S. 140 f.) 81 Tabelle 24: Dimensionen des Leistungsmotivationsinventars LMI (Schuler, et al , 2001) Otto-von-Guericke-Universität Magdeburg VII 84 Tabelle 25: Merkmale von Befragungen (Berekoven, et al., 2006) 85 Tabelle 26: Inhaltliche Strukturierung des Fragebogens 87 Tabelle 27: Spezielle Persönlichkeitsprofile in der Softwareentwicklung 97 Tabelle 28: Modell eines speziellen ICP 106 Tabelle 29: Werte der personenbezogenen COCOMO-Faktoren (Ludewig, et al., 2010) 109 Otto-von-Guericke-Universität Magdeburg VIII Abkürzungsverzeichnis Otto-von-Guericke-Universität Magdeburg IX Otto-von-Guericke-Universität Magdeburg X Einleitung 1 1 Einleitung 1.1 Motivation 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 Kommunikationsebene 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 2 . 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 1 Anmerkung des Verfassers: sprich Verantwortlichkeiten/Aufgabenverteilung 2 vgl. Abschnitt 2.2 (S. 6): Software-Projektmanagement Einleitung 2 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. Einleitung 3 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. Softwaremanagement 4 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. 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 Softwaremanagement 6 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. x Die gesamte Laufzeit ist begrenzt. x Ein „Erzeuger“ (gleich Projekteigentümer oder Vertreter, oft höheres Management) initiiert das Projekt und bestimmt den Projektleiter. x Ein Projektzweck (meist Produkt) ist definiert und als Bündel von Zielen beschrieben. Die Zielerreichung ist Maß für den Projekterfolg. x Die Entwicklung erfolgt für einen oder mehrere Abnehmer (gleich Auftraggeber, Kunde) und verschiedene Anwendergruppen. x Durch das Projekt werden Menschen, Resultate und Hilfsmittel 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. Softwaremanagement 7 x Das Ergebnis (Produkt) ist nicht greifbar, der Entwicklungsfortschritt ist ableitbar. x Besonders große Projekte neigen zur Einmaligkeit und sind schlechter vergleichbar mit früheren Entwicklungen. x Technologien entwickeln sich rasant weiter bzw. sind schnell überholt. x Prozess- und Qualitätsmodelle des Software Engineerings sind x Teilaufgaben sind oft hochspezifisch und schlecht delegierbar und/oder teilbar. x Es besteht ein hoher Grad der Abstraktion und Formalisierung. x 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. 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: x Institutionelles Projektmanagement (Ressourcenplanung, Infrastruktur) x Funktionelles Projektmanagement (Ablaufplanung, Controlling) x 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. Softwaremanagement 9 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. 3 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. 3 vgl. Abschnitt 4.4 (S. 49 ff.): Psychologie in Teamstrukturen 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 Softwaremanagement 11 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. 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 4 beschreibt Frick die konstruktive Qualitätssicherung als wichtige Voraussetzung: 4 vgl. Abschnitt 2.6 (S. 19 ff.) Ausgewählte Modelle und Methoden 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. Um die Projektrisiken innerhalb einer Organisation zu minimieren, müssen alle erdenklichen Risikofaktoren erfasst, bewertet und berücksichtigt werden. Diese Softwaremanagement 14 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. 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 5 sind zum Teil direkt oder indirekt vom Projektmanagement abhängig. Die sich nun anschließende Tabelle Nr. 6 vermittelt einen Überblick der wesentlichen Managementrisiken. 5 vgl. Abschnitt 2.5.1 (S. 14) bzw. 2.5.3 (S. 16) 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
Posted on: Tue, 30 Jul 2013 15:38:03 +0000
Trending Topics
Recently Viewed Topics
© 2015