Präsentation zum Thema: ""—  Präsentation transkript:

56 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!

57 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:

58 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)

59 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)

60 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;

61 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;...

62 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; ...

63 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.

64 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.)

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

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

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

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

69 Projektkontrolle Kontrollverfahren: siehe PM-Techniken-Qualitätssicherung; Auswahl des geeigneten Verfahrens je nach Kontrollbereich und 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;

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

71 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

72 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-Protokoll Inhalt: Ergebnisse aus allen Prüfungen und Unterschriften der Teilnehmer mit Bemerkung erfüllt/nicht erfüllt

73 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.

74 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;

75 Projektabschluss - 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;

76 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; ...

77 Wartung (siehe Sommerville, Kap. 28: 4. Auflage, oder Kap. 32: 5
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; zentrale Fragestellungen 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)

78 Wartung - Kostenfaktoren
technische Faktoren: nicht-technische Faktoren: Modul Unabhängigkeit Anwendungsgebiet Programmiersprache Stabilität des Personals Programmierstil Motivation des Personals Validierung und Testen Alter des Systems/Programms Dokumentationsqualität Abhängigkeit von der Tool-Einsatz externen Umgebung Konfigurationsmngmt Stabilität von Hardware/ Betriebssystem

79 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).

80 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!)

81 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/Reengineering Aktivitäten im Wartungsprozess.

82 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;

83 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 mit Erweiterungen Release mit Korrekturen Release mit Erweiterungen Release mit Korrekturen ...

84 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.

85 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;

86 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;

87 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

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

89 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.

90 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/Betriebssystem falls 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