1 / 35

Projektvorgehen, Steuerung, Koordination

Projektvorgehen, Steuerung, Koordination. Vorgehen : erfolgt nach Vorgehensmodell (siehe Vorgehensmodelle); Modell bietet Strukturierung der Gesamtkomplexität der Entwicklungsarbeiten und erleichtern diszipliniertes Vorgehen.

felton
Download Presentation

Projektvorgehen, Steuerung, Koordination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

  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:

  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)

  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)

  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;

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

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

  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.

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

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

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

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

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

  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;

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

  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

  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

  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.

  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;

  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;

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

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

  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

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

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

  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.

  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;

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

  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.

  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;

  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;

  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

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

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

  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

More Related