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


* 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


• 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


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


• - 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


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


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


• 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


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

pabw-56 projektvorgehen, steuerung, koordination *vorgehen: erfolgt nach vorgehensmodell (siehe...

Documents