PABW-56 Projektvorgehen, Steuerung, Koordination *Vorgehen: erfolgt nach Vorgehensmodell (siehe...
-
Upload
fritz-pfaff -
Category
Documents
-
view
217 -
download
1
Transcript of PABW-56 Projektvorgehen, Steuerung, Koordination *Vorgehen: erfolgt nach Vorgehensmodell (siehe...
PABW-1
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!
PABW-2
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:
PABW-3
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)
PABW-4
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)
PABW-5
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;
PABW-6
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;...
PABW-7
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; ...
PABW-8
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.
PABW-9
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.)
PABW-10
Projektkontrolle - Bereiche• a) Planungskontrolle (Managementkontrolle, -review)
(Jenny, Abb. 3.82, S. 311)
PABW-11
Planungskontrolle -ProzeßTeilschritte bei der Planungskontrolle:(Durchführung meist durch Auftraggeber oder Gremium)
(Jenny, Abb. 3.79, S. 307)
PABW-12
Projektkontrolle - Bereiche• b) Realisierungskontrolle (umfasst alle Phasen, auch Planung)
(Jenny, Abb. 3.85, S. 319)
PABW-13
Realisierungskontrolle - Prozess
Teilschritte bei der Realisierungskontrolle:(Durchführung meist durch Projektleiter oder ausgewählte Person wie Benutzer,...)
(Jenny, Abb. 3.81, S. 310)
PABW-14
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;
PABW-15
Projektkontrolle - Prüfplan• Beispiel einer Kontrollübersicht (vereinfachter Prüfplan):
(Jenny, Abb. 6.16)
PABW-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
AbschlussbeurteilungAbschlussberichtErfahrungssicherungEinführungsnachbearbeitungProjektauflösung
t
PABW-17
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
PABW-18
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.
PABW-19
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;
PABW-20
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;
PABW-21
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; ...
PABW-22
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)
PABW-23
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
PABW-24
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).
PABW-25
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!)
PABW-26
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.
PABW-27
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;
PABW-28
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 mitErweiterungen
Release mit Korrekturen
Release mit Korrekturen
...
PABW-29
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.
PABW-30
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;
PABW-31
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;
PABW-32
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
PABW-33
Evolution/Wartung - Änderungsmanagenment - Änderungsantragsformular
Beispiel eines Änderungsantragsformulars nach Sommerville, Abb. 29.4, S. 557
PABW-34
Evolution/Wartung - Änderungsmanagenment - Prozeß
Pseudocode zum AM-Prozess:Antragsteller füllt zutreffende Felder des Änderungs-Antrags-Formularsaus und reicht das ÄAF ein;
Änderungsantrag wird analysiert (z.B von Wartungsteam);
Falls Änderung gerechtfertigtschlage Implementierung vor und schätze Kosten;leite an Entscheidungsträger weiter;
Falls akzeptiertimplementiere 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.
PABW-35
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