Projektvorgehen, Steuerung, Koordination

Projektvorgehen, Steuerung, Koordination • Vorgehen:erfolgt nach Vorgehensmodell (siehe Vorgehensmodelle);Modell bietet Strukturierung der Gesamtkomplexität der Entwicklungsarbeiten und erleichtern diszipliniertes Vorgehen. • beachte: Projekthandbuch sollte mehrere Vorgehensmöglichkeiten zur Auswahl bieten, damit die Charakteristika des Projektes berücksichtigt werden können! • CASE- Tools sollten gewähltes Vorgehen unterstützen;daher: Bevorzugen von Tools mit flexiblem (auswählbarem oder programmierbarem) Prozess!

Projektvorgehen, Steuerung, Koordination • Projektsteuerung:umfasst alle projektinternen Aktivitäten des Projektleiters, die notwendig sind, um das Projekt innerhalb der Planungswerte abzuwickeln und erfolgreich durchzuführen. • Voraussetzungen:- klare Abwicklungs- und System-Zieldefinition;- aufgabengerechte Qualifikation von Projektleiter und -team;- genau definierte Rahmenbedingungen;- zweckmäßige Methoden und Tools;- genaue und umfassende Kontrolle;- möglichst detaillierte Planung. • wesentlich: Erfahrung und Geschick des Projektleiters!dennoch: einige Regeln/Zusammenhänge existieren:

Projektvorgehen, Steuerung, Koordination • Vorsicht: Effekte von Steuerungsmaßnahmen sind vernetzt; Maßnahmen haben daher mehrere Effekte;Beispiel: “Teufelsquadrat” nach [Daenzer,1992]; (Jenny, Abb. 3.71, S. 292)

Projektvorgehen, Steuerung, Koordination • Gliederung der Tätigkeiten zur Steuerung: a) direkt wirksame Steuerung:Einsatz: bei Differenzen zwischen Planung und Gegenwart;Maßnahmen:- Anleiten/Anordnen- Motivieren (intrinsisch, extrinsisch)- Abschirmen von Mitarbeitern (vor Interventionen, Intrigen,...)- Kontrollbewußtsein b) indirekt wirksame Steuerung:Einsatz: für langfristige Beeinflussung des Leistungsverhaltens; Maßnahmen, Elemente:- Führungsstil und -Verhalten - Motivation- Stellenbeschreibungen - Mitarbeiterförderung- Mitarbeiterbeurteilung (Standortbestimmung, Zielbestimmung)

Projektvorgehen, Steuerung, Koordination c) Qualitätslenkung (QL):beinhaltet Korrekturmaßnahmen, um die gewünschte Qualität trotz entstandener Abweichungen zu erreichen; • Definition: Unter QL versteht man die Steuerung, Überwachung und Korrektur der Realisierung einer Arbeitseinheit mit dem Ziel, die vorgegebenen Anforderungen zu erfüllen.Tätigkeiten zur Qualitätslenkung:- Ausführungsplanung, z.B.: Wer ist für die Qualitätssicherung zuständig und was sind seine Aufgaben; wann/wie werden Reviews durchgeführt;..- Ausführungsüberwachung: Überprüfung der Qualitätskontrolle;

Projektvorgehen, Steuerung, Koordination • - Ausführungskorrektur: Bereiche von Maßnahmen:+ Konstruktive Maßnahmen: konsequente Anwendung von Methoden und Techniken; Einsatz adäquater Werkzeuge; striktes Anlegen von Dokumentationen; ...+ Analytische Maßnahmen: systematische Durchführung von Prüftechniken; systematische Testplanung/Testdokumentation;...+ Organisatorische Maßnahmen: Einsatz von Vorgehensmodellen; Ausbildung der Mitarbeiter; Institutionalisierung des Qualitätssicherungskonzeptes;..+ Psychologische Maßnahmen: Förderung der Kommunikation; Zusammensetzung des Projektteams; gutes Verhältnis Projektteam - Anwender;...

Projektvorgehen, Steuerung, Koordination d) Koordination (im Projektmanagement): • Zielgerichtetes Aufeinander-Abstimmen aller Tätigkeiten, die in Zusammenhang mit dem Projekt stattfinden. • Koordinationsaufwand: steigt mit steigender Anzahl arbeitsteiliger Aktivitäten; • Aspekte der Koordination (K):- introvertierte Koordination: K innerhalb eines Projektes;- extrovertierte Koordination: K mit Umsystemen wie: Benutzersystem; vor- und nachgelagerte Projekte; Projektlenkungsausschuß; Ämter; ...

Projektkontrolle • Zweck und Ergebnisse der Projektkontrolle:- frühzeitige Fehlerbehebung; dadurch: Reduktion der Kosten;- Beteiligte werden auf gleichen Informationsstand gebracht;- Klärung, wie Vorgaben vom Projekthandbuch angepasst bzw. übergangen werden können;- Überprüfung von Änderungs/Verbesserungsvorschlägen hinsichtlich Anwendbarkeit und Auswirkungen;- Aufdecken unbekannter Abhängigkeiten und äußerer Einflüsse;- Überprüfung der Ziele auf ihre Gültigkeit; ggf. Revision;- Verbesserung der Beziehungen zwischen Projektteam und künftigen Benutzern;- Prüfung der Verträglichkeit der Pläne, Mittel und Ziele; etc.

Projektkontrolle (PK) • Wann wird kontrolliert?- ergebnisbezogen: z.B. bei Abschluss eines Meilensteins- aufwandbezogen: um eine sinnvolle Kontrolle zu ermöglichen, soll der zu kontrollierende Umfang nicht zu groß sein; Daumenregel: Kontrollintervall soll so gewählt werden, daß einKontroll- volumen von ca. 300 Personentagen nicht überschritten wird.- zeitbezogen: max. Intervall: 5 Monate • Regel: PK’s sollen alle Teile des Projektes umfassen.daher: - Unterscheidung zwischen Planungs- und RealisierungsPK- Gliederung des Projektes in Kontrollbereiche (s. Abb.)

Projektkontrolle - Bereiche • a) Planungskontrolle (Managementkontrolle, -review) (Jenny, Abb. 3.82, S. 311)

Planungskontrolle -Prozeß Teilschritte bei der Planungskontrolle:(Durchführung meist durch Auftraggeber oder Gremium) (Jenny, Abb. 3.79, S. 307)

Projektkontrolle - Bereiche • b) Realisierungskontrolle (umfasst alle Phasen, auch Planung) (Jenny, Abb. 3.85, S. 319)

Realisierungskontrolle - Prozess Teilschritte bei der Realisierungskontrolle:(Durchführung meist durch Projektleiter oder ausgewählte Person wie Benutzer,...) (Jenny, Abb. 3.81, S. 310)

Projektkontrolle • Kontrollverfahren: siehe PM-Techniken-Qualitätssicherung;Auswahl des geeigneten Verfahrens je nach Kontrollbereichund Prüfsicht; • Prüfsichten:- Benutzersicht: Kontrolle z.B. mit Tests und techn. Reviews;- Projektteam-Leistungssicht: K. mit Inspektionen und Audits;- Auftraggeber-Sicht: K. des gesamten Projektes; Projektreview;- Schnittstellenkontrolle; • Prüfplan: enthält alle Prüfungen im Projektverlauf;zu jeder Prüfung sind anzuführen:- Zeitpunkt; - Bereich; - Verfahren; - Prüfsicht; - Beteiligte;

Projektkontrolle - Prüfplan • Beispiel einer Kontrollübersicht (vereinfachter Prüfplan): (Jenny, Abb. 6.16)

Projektabschluss • Ziele bei der Projektauflösung:- offizielles Auflösen der Projektgruppe und Neuzuteilung von Verantwortlichkeiten;- Sichern der Erfahrungswerte;- Festhalten des Systemzustandes zum Projektendzeitpunkt. • Projektabschluß-Tätigkeiten:Produktabnahme Abschlussbeurteilung Abschlussbericht Erfahrungssicherung Einführungsnachbearbeitung Projektauflösung t

Projektabschluß - Produktabnahme • Tätigkeiten bei der Abschluss-Kontrolle:- Systemabnahme: Prüfung auf Funktionalität, Leistung und Qualität;- Integrationsabnahme: Das System als Ganzes sowie Subsysteme/Module werden bzgl. interner Schnittstellen und Schnittstellen zur bestehenden Systemumgebung geprüft;- Akzeptanzprüfung (Abnahmetest): Durchführung von Benutzern, Kunden; Auftraggeber; Voraussetzung: Kenntnis des Produktes, daher Zeitrahmen zum Arbeiten mit dem System bieten; • Ergebnis: Systemtestabnahme-ProtokollInhalt: Ergebnisse aus allen Prüfungen und Unterschriftender Teilnehmer mit Bemerkung erfüllt/nicht erfüllt

Projektabschluß - Abschlußbeurteilung • Abschlußbeurteilung: Aspekte: System, Abwicklungsprozess • a) System- (=Produkt-) beurteilung: Basis: Ergebnisse der Produktabnahme • Beurteilungskriterien:- welche Anforderungen sind unzureichend erfüllt;- entspricht das System den aktuellen Spezifikationen;- klare Aufführung der Kenngrößen;- Sammeln und Begründen aller Abweichungen;- Gegenüberstellung des geplanten/tatsächlichen Nutzens, etc.; • b) Beurteilung des Abwicklungsprozesses:Zweck: (u.a.) Erfahrungssammlung für weitere Projekte; - Stärken/Schwächen des gewählten Vorgehensmodells;- Bewertung aller beteiligten/betroffenen Personen bzgl. Leistung, Verhalten, Kommunikationskanälen, etc.

Projektabschluss - Abschlussbericht • Abschlussbericht:Struktur und Inhalt:- kurze Projektbeschreibung (Problemstellung/Ziele);- getroffene Entscheidungen während der P.Abwicklung;- Aussagen von Beteiligten/Betroffenen;- Wirtschaftlichkeit (Planung vs. Ergebnis);- Mängelliste: noch offene Punkte/Mängel;- Gegenüberstellung sämtlichen SOLL-IST-Werte;- Abweichungen gegenüber ursprünglichen Zielsetzungen;- Übernahme-Szenario;- Schlußfolgerungen.Abschlussbericht wird bei der Projektauflösung unterzeichnet und verteilt;

Projektabschluss - Erfahrungssicherung • Erfahrungssicherung: • Tätigkeiten: - gut strukturiertes Sammeln/Auswerten aller Erfahrungsdaten;- Überprüfung/Anpassung der Daten zu Projektende • Zweck: wichtig für - Aufwandschätzverfahren und Kennzahlensysteme;- Verwendung in späteren Projekten eines Unternehmens;- persönlichen Nutzen der Projektleitung; • auch Fehler, Fehlinterpretationen und Fehlentscheide sollten aufgezeichnet werden, da sie die Basis für Verbesserungen bieten;

Projektabschluss - Einführungs-Nachbearbeitung, Projektauflösung • Nachbearbeitungsphase: • Aufgabe:- Aufarbeitung von Mängeln, die beim Abnahmetest und in den ersten Betriebsmonaten festgestellt wurden;- Sicherung der geforderten Funktionalität und Qualität. • Zeithorizont: Abschluß: 3-6 Monate nach d. Systemeinführung; • Projektauflösung: • Voraussetzung: alle für die Wartung erforderlichen Grundlagen wurden erstellt: • Arbeiten: Übergabe der bereinigten Dokumentation; Projektauflösungsprotokoll erstellen; Abschlussbericht unterzeichnen/verteilen; offizielle Abschlußsitzung;Projektpersonal auf neue Aufgaben vorbereiten; ...

Wartung(siehe Sommerville, Kap. 28: 4.Auflage, oder Kap. 32: 5.Auflage) • Wartung: Prozess der Änderung eines im Einsatz befindlichen Sytems (nach der Systemeinführung). • Arten: Perfektive -, Adaptive -, Korrektive Wartung; • zentraleFragestellungen zur Wartung: • Kostenfaktoren (siehe auch Software Engineering I) • Messen/Schätzen der Wartbarkeit • Dynamik der Evolution von Programmen • Konfigurationsmanagement (siehe auch SW Eng. I) • Änderungsmanagement (siehe auch SW Eng. I) • Versions- und Release Management (Tools s. SW Eng. I)

Wartung - Kostenfaktoren technische Faktoren: nicht-technische Faktoren:----------------------------------------------------------------------Modul Unabhängigkeit AnwendungsgebietProgrammiersprache Stabilität des PersonalsProgrammierstil Motivation des PersonalsValidierung und Testen Alter des Systems/ProgrammsDokumentationsqualität Abhängigkeit von derTool-Einsatz externen UmgebungKonfigurationsmngmt. Stabilität von Hardware/ Betriebssystem

Wartung - Schätzung der Kosten • 2 Klassen: Wartungs- vs. Prozess-Metriken: • Wartungs-Metriken (“Maintainability Metrics”): • Basis: Annahme, daß der Wartungsaufwand mit steigender Komplexität des Programms steigt; • Beispiele für Wartungs-Metriken:Zyklomatische Komplexität; Kennzahlen nach Halstead;Fan-in/Fan-out, div. OO-Metriken, etc. • Prozess-Metriken: • Basis: Messungen während des Wartungsprozesses; • Beispiele für Prozess-Metriken: Anstieg/Abnahme der- Anzahl der Fehlermeldungen;- durchschnittlichen Zeit für die Behebung eines Fehlers;- Anzahl der noch offenen Probleme (Änderungsaufträge).

Wartung - Dynamik der Evolution von Programmen • Studien zu Änderungen in komplexen Systemen: “Dynamik der Evolution von Programmen” (Lehman & Belady, 1985) • Material der Studien: Untersuchungen des Wachtums und der Evolution zahlreicher großer Systeme; • Motivation: Herausfinden von Gesetzmäßigkeiten bzgl. des Verhaltens solcher Systeme bei Änderungen/Evolution; • Ergebnis: 5 Lehman’sche Gesetze (eigentlich Hypothesen) • Relevanz :Lehman’s “Gesetze” scheinen allgemeine Gültigkeit zu besitzen; sie sollten daher bei der Planung des Wartungsprozesses einkalkuliert werden. (weitere Untersuchungen wären erstrebenswert!)

Wartung - Dynamik der Evolution von Programmen 1) “Fortwährende Änderungen”Ein in (einer realen Welt in) Verwendung befindliches Programm muss angepasst werden, oder es wird zusehendst weniger brauchbar.Folgerung: Wartung ist unverneidbar! 2) “Steigende Komplexität”Die Struktur eines in Evolution befindlichen Programms wird komplexer. Extra-Aufwand ist erforderlich, um die Struktur zu erhalten oder wieder zu vereinfachen.Folgerung: Einplanen von Restrukturierungs/ReengineeringAktivitäten im Wartungsprozess.

Wartung - Dynamik der Evolution von Programmen • 3) “Evolution großer Programme”Die Programmevolution ist ein selbst-regulierender Prozeß.Attribute wie Anzahl der Fehlermeldungen, Größe, Zeit zwischen Releases, sind für jedes Release in etwa gleich.Folgerung: Die groben Trends bezüglich Wartbarkeit werden zu einem frühen Entwicklungszeitpunkt festgelegt und können nur in beschränktem Rahmen beeinflußt werden. (vgl: Massenträgheit) • 4) “Organisatorische Stabilität”Die Rate der Weiterentwicklung eines Programms ist während dessen Lebenszeit in etwa konstant und unabhängig von den für die Entwicklung eingesetzten Ressourcen.Folgerung: Grenzen bzgl. Größe des Projektteams und der Entwicklungszeit;

Wartung - Dynamik der Evolution von Programmen 5) “Erhaltung des bekannten Zustandes”Die inkrementellen Änderungen in jedem Release des Systems sind während der gesamten Lebenszeit des Systems in etwa konstant.Folgerung für das Konfigurationsmanagement:Innerhalb eines Release sollte nicht zu viel an Funktionalität geändert werden! Grund: Der Einbau vieler neuer Funktionen ist mit vielen Fehlern gekoppelt; deren Korrektur verlangt wiederum nach einem baldigen neuen Release.Günstige Strategie bzgl. Releases: Release mitErweiterungen Release mit Korrekturen Release mitErweiterungen Release mit Korrekturen ...

Evolution/Wartung - Konfigurationsmanagement • große Software-Systeme können als Konfigurationen von Komponenten gesehen werden;Gründe für Verschiedenheiten: versch. HW/Betriebssystem;versch. Umfang; Spezialmodule; etc. • Evolution während des SW-Lebenszyklus:- in Wartungsphase;- bei inkrementellem Vorgehen auch in Entwicklungsphase;Folgerung: viele verschiedene Versionen, bestehend aus verschiedenen Konfigurationen (“Zusammenstellungen”) von Komponenten existieren; • Konfigurationsmanagement (KM):Prozeß der Verwaltung der Änderungen an einem System und des Managements der verschiedenen Versionen eines in Evolution befindlichen Software Produktes.

Evolution/Wartung -Konfigurationsmanagement • Aufgaben des KM: Entwicklung und Anwendung von - Prozeduren/Abläufen für das Konfigurieren von Systemen und deren Releases;- Standards für die Verwaltung/Verarbeitung von Änderungswünschen sowie die Identifikation/Speicherung verschiedener Systemversionen; • Beispiele für Festsetzungen:- Namensschema für Dokumente; Dokumenthierarchie; z.B.: Projektname/Teilprojekt/Komponente/Dok.Aspekt/Dok.Art;- Welche Dokumente unterliegen dem KM;- Formular für einen Änderungsauftrag (s. später);- Schema für KM Informationen der KM-Datenbank; ... • das KM ist häufig ein Aspekt der allgem. Qualitätssicherung;

Evolution/Wartung -Konfigurationsmanagement • Vorgaben: im KM-Plan (Inhalt siehe Planung) • “Konfigurationsitem”: Dokument oder Gruppe verwandter Dokumente, über die Konfigurationsinfo. verwaltet wird. • Konfigurationsdatenbank: verwaltet Konfigurationsinformation;dient der Beantwortung von Anfragen wie:- An welche Kunden wurde welche Systemversion ausgeliefert?- Welche HW und Betriebssystem sind für die Installation einer bestimmten Version erforderlich?- Welche Versionen können bei Änderung einer bestimmten Komponente betroffen sein?- Wie viele Fehlermeldungen betreffen eine bestimmte Version?... • ad KM-Tools: siehe Sommerville, Abschnitt SW-Management oder Skriptum zu Software Engineering I, Kap. Wartung;

Evolution/Wartung - Änderungsmanagenment • Änderungen sind unumgänglich; • Strategie: Tatsache, daß Änderungen stattfinden, einplanen; • Änderungsmanagement (AM) : (“change management”)Ziel: Änderungen gezielt und effektiv durchführen/verwalten;Beginn des AM-Prozesses: bei Einreichung eines Dokumentes/Programms an das KM; • AM-Prozeß umfaßt:- Ausfüllen/Einreichen eines Änderungsauftragsformulars;- technische Analyse der Änderung;- Kosten/Nutzen Analyse;- Verwaltung der Änderungen und Anträge; • Änderungsanträge sind Konfigurationsitems; sie werden in der KM-Datenbank verwaltet

Evolution/Wartung - Änderungsmanagenment - Änderungsantragsformular Beispiel eines Änderungsantragsformulars nach Sommerville, Abb. 29.4, S. 557

Evolution/Wartung - Änderungsmanagenment - Prozeß Pseudocode zum AM-Prozess: Antragsteller füllt zutreffende Felder des Änderungs-Antrags-Formulars aus und reicht das ÄAF ein; Änderungsantrag wird analysiert (z.B von Wartungsteam); Falls Änderung gerechtfertigt schlage Implementierung vor und schätze Kosten; leite an Entscheidungsträger weiter; Falls akzeptiert implementiere und validiere solange, bis Qualität o.k.; ggf. kreiere neue Version; speichere ÄAF bzw. lege ÄAF als formales Dokument ab; sonst weise zurück; sonst weise zurück.

Evolution/Wartung -Versions- und Release Management • Versions/Release Management:Prozeß der Identifikation und Verwaltung verschiedener Versionen/Releases; • Version: Instanz eines Systems, die sich in irgend einer Eigenschaft (bestimmten Eigenschaften) von anderen Instanzen dieses Systems unterscheidet.Beispiele für Unterschiede: Funktionalität, Qualität, Zielarchitektur/Betriebssystemfalls minimale Unterschiede: Variante (“variant”) • Release: Version, die an Kunden weitergegeben wird; • Identifikation: jede Version soll (neben ihrer Nummer) durch eine Menge von Attributen eindeutig identifizierbar sein; Verwaltung in Konfigurationsdatenbank

Projektvorgehen, Steuerung, Koordination