III Software-Management

Transkript

1 Softwaretechnik- Praktikum: 7. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung V7-2 Softwaretechnikpraktikum: III Software-Management Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de III Software-Management III.1 Grundlagen III.2 Planung III.3 Organisation III.4 Personal/Leitung III.5 Kontrolle III.6 Diskussion & Zusammenfassung III.7 Literaturhinweise V7-4 III.3 Organisation Grundlegende organisatorische Aufgaben: Mittelfristig: Geeignete Aufbauorganisation identifizieren und etablieren die folgendes umfasst: Organisatorische Positionen Verantwortungsbereiche disziplinarische Vollmachten Qualifikationsprofile für die Positionen Kurzfristig: Projektspezifische Festlegungen beim Start eines Projekts. Wie die Abläufe koordinieren? Koordination von Arbeitsabläufen durch... gegenseitige Abstimmung persönliche Weisung Standardisierung der Arbeitsprozesse Standardisierung der Arbeitsprodukte Standardisierung der Qualifikationen Bemerkungen: Deckt Kontrolle und Kommunikation mit ab Meist Kombination der 5 Mechanismen Faktisch Immer vorhanden: Persönliche Weisung und gegenseitige Abstimmung V7-5 V7-6 1

2 Wie die Aufgaben aufteilen? Aufgabenspezialisierung vs. Aufgabenerweiterung Horizontale Aufgabenspezialisierung Enges Aufgabengebiet (z.b. Systemanalyse, Analyse, Entwurf, Implementierung, Testen, ) + Standardisierung wird erleichtert - Führt zu Kommunikations- und Koordinationsproblemen - Kann zu Auslastungsproblemen führen Vertikale Aufgabenspezialisierung Trennung von Planung, Arbeit und Kontrolle + oft wirksamere Überwachung - Kann Motivation schwächen (keine eigene Verantwortung) Die fünf Teile einer Organisation Betrieblicher Kern: Ausführende Mitarbeiter die direkt an der Erstellung von Produkten bzw. der Bereitstellung von Dienstleistungen arbeiten. Strategische Spitze: operative, repräsentative und strategische Leitung strategische Spitze Betrieblicher Kern Mittellinie: Verbindet die strategische Spitze mit dem betrieblichen Kern - Komprimierung der Ereignisse - Umsetzung der Weisungen Technostruktur: Gestaltung der Arbeitsabläufe Hilfsstab: Unterstützt die Organisation außerhalb des betrieblichen Arbeitsablaufs V7-7 V7-8 Software-Organisation Stand der Dinge in der Software-Technik: Arbeit oft wenig horizontal und vertikal spezialisiert Verstärkte horizontale Spezialisierung ist notwendig! Soll-Zustand: Im betrieblichen Kern und in der Technostruktur sind professionelle Arbeiten (horizontal spezialisiert, vertikal erweitert) durchzuführen Für jede Position sind die notwendigen Qualifikationen und Kenntnisse zu definieren Bei unzureichender horizontaler Spezialisierung ist diese vorzunehmen Beispiel: Positionen Strategische Spitze Manager Mittellinie Manager Betrieblicher Kern Systemanalytiker Software-Architekt Programmierer Tester Anwendungsspezialist Vertriebsbeauftragter Marketingspezialist Technostruktur Methodenberater Prozessplaner Qualitätskontrolle Hilfsstab Software-Ergonom Rechtsabteilung Öffentlichkeitsarbeit Buchhaltung V7-9 V7-10 Zerlegung nach Funktion Softwareergonom Technostruktur Technostruktur Hilfsstab Mittellinie Methodenberater Prozessberater Qualitätsbeauftragter Geschäftsführung Buchhaltung Hilfsstab Kommunikationsaufwand Zeit (t) Entwicklungsdauer Anteil der Kommunikation Marketing Systemanalyse Konstruktion Vertrieb Anteil der Produktion 2 Personen 4 Personen 4 Personen 2 Personen Anzahl der Mitarbeiter Weniger Arbeitsteilung möglich Mehr Abstimmung (Koordination) notwendig V7-11 V7-12 2

3 Anzahl der Mitarbeiter Effizienz wird verringert durch abhängige Aufgaben, die durch gegenseitige Abstimmung koordiniert werden müssen Koordinationsbedarf kann durch Standardisierung und gute Ausbildung der Mitarbeiter verringert werden Brooks sches Gesetz: Adding manpower to a late software project makes it later III.4 Personal/Leitung Problem: 15% aller Projekte schlagen fehl Sie wurden abgebrochen, zurückgestellt oder haben Ergebnisse geliefert, die nicht gebraucht wurden. Bei größeren Projekten, mit mehr als 25 Personenjahren, wurden 25% nicht fertiggestellt Analyse der Ursachen: Überwältigende Mehrheit der Projekte sind nicht aufgrund von technischen Problemen gescheitert sondern wegen personenbezogenen Problemen. Problem: Zusätzliche Mitarbeiter müssen von den vorhandenen geschult und eingearbeitet werden Es muss eine weitere Aufgabenteilung und erneute Abstimmung vorgenommen werden Die optimale Mitarbeiterzahl muss rechtzeitig zur Verfügung stehen Bedeutung von Personalfragen Erfolgreiche Software-Entwicklungen lassen sich auf gute menschliche Zusammenarbeit zurückführen Fehler ergeben sich oft aus schlechter menschlicher Kooperation V7-13 V7-14 Allgemeinen Qualifikationen (Software) Fähigkeit zum Abstrahieren (Bewältigung komplexer Systeme/Probleme) Sprachliche und schriftliche Kommunikationsfähigkeit (Teamarbeit & Dokumentation) Wille zum lebenslangen Lernen (rasante technologische Entwicklung) Teamfähigkeit Kreativität Intellektuelle Flexibilität und Mobilität Hohe Belastbarkeit (häufig hoher Termin- und Kostendruck sowie knappen Personalressourcen) Englisch lesen und sprechen Schreibmaschine schreiben Spezialisierung in der Softwaretechnik (1/3) Horizontale Spezialisierung Horizontal = spezialisiert auf eine Phase; beherrscht breiteres Spektrum an Techniken z.b. Systemanalytiker, Software-Architekt, Programmierer, Tester, Bewertung: + Volle Nutzung der Qualifikationen + Gleiche Tätigkeiten in kurzen Abständen + Höhere Chancen für die Wiederverwendung vorhandener Komponenten + Chance, ständig den»stand der Technik«auf dem Spezialisierungsgebiet zu halten Gefahr, dass zwischen den jeweiligen Ebenen das Produkt nicht zusammenpasst Mehr Spezialisierungsgebiete als bei der vertikalen Spezialisierung V7-15 V7-16 Spezialisierung in der Softwaretechnik (2/3) Vertikale Spezialisierung deckt mehrere Phasen ab; aber sehr spezielle Techniken pro Phase z.b. Datenbankspezialist (ER-Entwurf, relationale DB-Modelle, SQL- Programmierung) Bewertung: + Weniger Spezialisierungsgebiete als bei der horizontalen Spezialisierung Nicht bei jeder Software-Methode einsetzbar Verlangt vom Spezialisten sehr unterschiedliche Qualifikationen Jede Tätigkeit wird nur selten durchgeführt Gefahr, dass auf der jeweiligen Ebene die Produktteile nicht zusammenpassen Spezialisierung in der Softwaretechnik (3/3) Allgemeine Probleme der Spezialisierung: Auslastung des Personals schwieriger Einsatzmöglichkeiten einzelner Personen eingeschränkter Speziell Software-Technik: Problem: es überwiegt heute noch der Generalist, aber wegen der notwendigen fachlichen Qualifikationen und der hohen Innovationsgeschwindigkeit ist Spezialisierung unvermeidlich Die Vielzahl der Vorteile spricht für eine horizontale Spezialisierung Die Nachteile müssen durch das Software-Management vermieden werden. V7-17 V7-18 3

4 Rollen & Qualifikationen (1/4) Systemanalytiker (Anforderungsdefinition) Abstraktes Denken Hohe Kommunikationsbereitschaft Hineindenken in andere Begriffs- und Vorstellungswelten Fachwissen aus den Anwendungsgebieten Flexibilität Software-Entwerfer / Software-Architekt (Analyse- und Entwurfsphase) Abstraktes Denken Vom fachlich Abstrakten zum software-technisch Konkreten Konzeptionelles Denken nicht im Detail versinken. Rollen & Qualifikationen (2/4) Programmierer / Algorithmenkonstrukteur (Implementierung) Mathematisches Denkvermögen (Verifikation, Aufwand) Abstraktionsvermögen Kreativität Präzision Qualitätssicherer (Testphase) Geduld Hartnäckigkeit Mathematisches Denkvermögen. V7-19 V7-20 Rollen & Qualifikationen (3/4) Software-Ergonom Interdisziplinäres Wissen aus kognitiver Psychologie, Arbeitswissenschaft und Software-Technik Fähigkeit zu konzeptioneller, experimenteller und evaluatorischer Tätigkeit Hohe Kommunikationsbereitschaft. Anwendungsspezialist Breites Modellierungswissen über das Anwendungsgebiet Hohe Kommunikationsbereitschaft Abstraktes Denken Fähigkeit, das Anwendungsgebiet aufgabengerecht zu strukturieren Vorhandene Softwaresysteme des Anwendungsgebiets kennen Automatisierungsmöglichkeiten des Anwendungsgebiets anhand von wirtschaftlichen und ergonomischen Gesichtspunkten einschätzen können Ganzheitliches Denken. Rollen & Qualifikationen (4/4) Software-Manager Kooperativer und mitarbeiterorientierter Führungsstil Fähigkeit zum strategischen Denken Mitarbeiter zum selbständigen und eigenverantwortlichen Handeln anleiten Kenntnisse in Problemlösung und Konfliktmanagement Initiieren und Fördern von Innovationen Fachübergreifendes Denken Entwickler und Förderer seiner Mitarbeiter Fähigkeit und Bereitschaft zum Delegieren Kreativität. V7-21 V7-22 Projektmanager (Manager) Aufgaben Festlegung der Rahmenbedingungen für die Projektorganisation Initialisierung und Koordination des Projekts, gegebenenfalls Koordination mehrerer Projekte Mitarbeit bei Durchführungsentscheidun gen und Umsetzung der getroffenen Entscheidungen Geforderte Kenntnisse und Fähigkeiten: Kenntnisse auf betriebswirtschaftlichem Gebiet, aber auch technisches Verständnis Kenntnis über Anwendung und Einsatzgebiet des Systems Führungsqualitäten Fähigkeit zu Organisation und Delegation Fähigkeit zu positiver Sichtweise. Aus dem V-Modell nach Projektleiter (Verantwortlicher) Aufgaben Planung, Steuerung und Kontrolle des Projekts Erstellung des Projekthandbuchs und -plans (Aufwand, Termine und Einsatzmittel) basierend auf den Projektzielen und den organisatorischen Rahmenbedingungen Beauftragung der Projektmitarbeiter Berichterstattung gegenüber dem Projektmanager und gegebenenfalls weiteren Lenkungsgremien Geforderte Kenntnisse und Fähigkeiten: Erfahrung in der Projektabwicklung Kenntnis über Anwendung und Einsatzgebiete sowie Methoden und Werkzeuge Durchsetzungsvermögen und Akzeptanz bei den Projektmitarbeitern Fähigkeit zur Führung, Motivation und Moderation Fähigkeit zu Organisation und Kommunikation. Aus dem V-Modell nach V7-23 V7-24 4

5 Projektadministrator (Durchführender) Aufgaben: Unterstützung des Projektleiters Koordination und Verwaltung von Arbeitsaufträgen Erstellung und Verwaltung von Berichtsdokumenten Mitarbeitermotivation Ziel: Mitarbeiter über lange Zeit motivieren Perspektiven und Aufstiegschancen eröffnen Nicht alle können/wollen Manager werden Es muss auch eine Fachlaufbahn geben Geforderte Kenntnisse und Fähigkeiten: Kenntnis und Erfahrung in Methoden und Werkzeugen des Projektmanagements Fähigkeit zu Organisation und Kommunikation. Aus dem V-Modell nach Führungslaufbahn: Ermöglicht zunehmend Personalverantwortung zu übernehmen Fachlaufbahn: Ermöglicht größere fachliche Verantwortung zu übernehmen. V7-25 V7-26 Personalaufgaben Auswahl von Bewerbern für die verfügbaren Stellen (extern/intern) Die Aus- und Weiterbildung sowohl der neuen Mitarbeiter als auch der Stelleninhaber Die Mitarbeiterbeurteilung, -bezahlung und - entwicklung Das Versetzen und Entlassen von Mitarbeitern Das primäre Ziel besteht darin, die definierten Rollen mit Mitarbeitern zu besetzen, die fähig und motiviert sind, diese Rollen auszufüllen. Faktoren bei der Stellebesetzung Ausbildung Erfahrung Training Motivation Engagement & Loyalität Selbständigkeit Gruppenaffinität Intelligenz Persönlichkeit Bemerkung: Schwächen auf einigen dieser Gebiete können durch Stärken auf anderen Gebieten ausgeglichen werden Gravierende Schwächen sollten zu einer Ablehnung führen. V7-27 V7-28 Personalentwicklung (1/2) Ziel: Für die Durchführung der aktuellen und der zukünftigen Entwicklungsaufgaben Personal in ausreichender Qualität und Quantität Verfügung zu stellen Problem Fluktuation (speziell in der Softwaretechnik) USA: durchschnittliche Verweildauer von Monate bei Projekten, die oft länger als 3 Jahre dauern Verlust des Wissens während des Projektes! Lösungsmöglichkeiten Gute personenunabhängige Dokumentation (standardisiert, abgenommen, rechnergestützt) Unabhängige Qualitätssicherung Attraktive Arbeitsbedingungen Nur mittelfristige Personalplanung Personalentwicklung (2/2) Problem Qualifikation (speziell in der Software-Technik): Nicht fortbildungsfähige Mitarbeiter aufgrund der hohen Innovationsgeschwindigkeit und/oder fachfremden Berufen es kann nicht mehr auf dem Stand der Technik entwickelt werden + qualifizierte Mitarbeiter werden abgeschreckt 2 Lösungsalternativen: 1. Es wird bei den alten Sprachen und Methoden geblieben Man ist sich darüber im klaren, dass ein Produktivitäts- und Qualitätsverlust eintritt und neue Mitarbeiter abgeschreckt werden 2. Einsatz dieser Kräfte bei der Wartung etc. Nicht fortbildungsfähige Mitarbeiter pflegen und warten die vorhandene Software oder werden für andere Aufgaben eingesetzt Neue Mitarbeiter entwickeln neue Systeme entsprechend dem Stand der Technik V7-29 V7-30 5

6 Was ist ein Team? Teams: Stärken Ausgeprägteste Form der Gruppenarbeit Eine gemeinsame Aufgabe Mitarbeiter mit verschiedenen Qualifikationen Regelmäßige und kontinuierliche Kommunikation zur gegenseitigen Abstimmung Gleichberechtigte Mitbestimmung aller Teammitglieder (Netzwerk und keine Hierarchie) Verschiedene Teammitglieder übernehmen zeitweise die Führungsrolle, jeweils auf dem Gebiet, auf dem sie ihre Stärken haben. Geeignete Teamgröße 3-4 Manager sind normalerweise nicht Teil des Teams, das sie leiten + Hoher Problemlösungsgrad bei schwierigen Problemen + Verschiedene Standpunkte und Meinungen kommen zur Sprache + Das unterschiedliche»know-how«der Teammitglieder wird genutzt + Die Gefahr, in eine Sackgasse zu geraten, ist geringer als bei Einzelarbeit. + Hohe Arbeitszufriedenheit + Hohe Risikobereitschaft + Gegenseitige Anregung und Verstärkung + Vielfältige Informationen werden in relativ kurzer Zeit vermittelt + Zwischenmenschliche Bedürfnisse werden in hohem Maße befriedigt V7-31 V7-32 Teams: Schwächen Erfolgreiche Teambildung Hoher Zeit- und Kommunikationsaufwand Hoher Konformitäts- und Normierungsdruck Informationsfülle erfordert lange Diskussionen und zögert Entscheidungsfindungen hinaus Konkurrenzdenken und individuelle Profilierung können Leistung verringern Es laufen gruppendynamische Prozesse ab, die nur schwer zu kontrollieren und zu beeinflussen sind Gruppendruck kann Teammitglieder zu leistungsabträglichem Verhalten veranlassen. Team auf gemeinsames Ziel ausrichten Team zu Erfolgen verhelfen Elitegefühl stärken Qualität zum Kult machen Vielfalt ins Team bringen Strategische Richtlinien vorgeben, keine taktischen Never change a winning team V7-33 V7-34 Probleme für Teams Faktoren für Teambildung Kontrolle statt Vertrauen und Autonomie Bürokratie Räumliche Trennung statt räumlicher Nähe Gleichzeitige Mitarbeit in mehreren Teams, statt nur in einem Scheintermine statt Vertrauen Eigenschaften teamfähiger Mitarbeiter Positive Einstellung zur Teamarbeit Kritik- und Konflikttoleranz Gegenseitige Anerkennung und Respektierung der fachlichen Qualifikation und persönlichen Integrität Partnerschaftliches Verhalten Fähigkeit, widersprüchliche und voneinander abweichende Informationen zu verarbeiten Bereitschaft, sich voll im Team zu engagieren Mit sich selbst zufrieden sein Merkmale eingeschworener Teams Niedrige Fluktuationsrate Ausgeprägtes Identifikationsbewusstsein Freude an der Arbeit Bewusstsein einer Elitemannschaft. V7-35 V7-36 6

7 Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde Wiederholung: Reverse-Engineering (1/3) Fragen: Welche Daten sollen beim Reverse Engineering der anderen Plug-ins erworben werden? Nur Klassendiagramm oder auch Verhaltensdiagramme? Welche Abläufe zwischen den Schnittstellen sollen wie im Verhaltensdiagramm erfasst werden? Welche Tools, die sich zum Reverseengineering eignen, sind empfehlenswert? Sollen wir beim Reverse Engineering des Design Teile des Pflichtenhefts, die Klassendiagramme, Aktivitätendiagramme und Teile des Analyseheftes mit seinen Sequenzdiagramme erstellen? Oder reichen UML Diagramme.? Müssen alle beginn-user-doc an denen more description here steht, die in den Klassen sind, von uns dokumentiert werden? Wenn ja wie genau? Mir unklare Fragen: Wie genau sollen die Klassen zb. Actor in ComponentAndBehavior von uns dokumentiert werden? Geht es hier um Das Was oder auch um das Wie? V7-38 Was ist Reverse Engineering? Was Was wird wird mit mit Design in in V5- V5-9 gemeint? **Entwurf** [Chikofsky&Cross1990] E. J. Chikofsky and J. H. Cross, Reverse Engineering and Design Recovery: A Taxonomy IEEE Software, vol. 7, pp , Jan./Feb Wiederholung: Reverse-Engineering (2/3) Anmerkungen Es sind keine Fragen aufgekommen, zu mindest nicht zu dem konzeptionellen Rahmen zu diesem Thema, der in den Materialien und der Vorlesung dargelegt wurde. Auf der anderen Seite haben wir bei den Arbeiten für das Analyse- Entwurfs-Dokument versucht Reverse-Engineering an dem Beispiel- Editor zu betreiben, um uns an diesem orientieren zu können. Dabei haben wir gemerkt, das der theoretische Background schön und gut ist, uns aber konkrete praktische Methoden fehlen, die es uns ermöglichen, systematisch eine Dokumentation aus einem gegebenen Quellcode abzuleiten. Wegen mangelnder Zeit und genau wegen diesen fehlenden Methoden gestalteten sich die Arbeiten dann recht chaotisch und dementsprechend ist das Analyse-Entwurfs-Dokument ausgefallen. Naja, meine Frage ist nun, ob wir zu diesem Thema noch praktische Methoden kennen lernen werden? Deswegen haben wir ja das Tutorial gemacht, aber V7-39 V7-40 Wiederholung: Reverse-Engineering (3/3) Adressiert beim Tutorial: Was sind gute Startpunkte für das Reverse Engineering? Welches Vorgehen ist sinnvoll? Da alle Quellen, die ich mir angeschaut habe (Vorlesungsfolien, Wikipedia (deutsch + englisch), Dokumente der Uni Bremen) sehr vage in Bezug auf das Vorgehen beim Reverse Engineering waren, würde ich mir ein kleines, praktisches Beispiel für das Tutorium wünschen. Aufgaben/Abgaben: Sonstiges: 3x fehlt! 2 x Test statt Reverse-Engineering 1x unklar wer der Verantwortliche ist V7-41 V7-42 7

8 Hinweis Heute 15 Uhr ct Tutorial zu Subversion (E3.327) Programmierberatung wöchentlich Mittwochs Uhr ct in E3.327 Fragen? V7-43 V7-44 8