Übungsaufgaben zu Kapitel Vorgehensmodelle Was sind die Vorteile eines unternehmensspezifischen Vorgehensmodells? Unternehmensspezifische Vorgehensmodelle dienen neuen Projekten als eine Art „Werkzeugkasten“. Sie bieten unerfahrenen als auch erfahrenen Projektleitern die Sicherheit, richtig im Projekt fortzuschreiten. Sie können daher als Vorlage für die tägliche Arbeit im Projekt angesehen und als Grundlage für einen Projektstatus verwendet werden (welche im Vorgehensmodell definierten Meilensteine wurden erreicht?).

Was sind typische Bestandteile eines Software-Entwicklungsprozesses? Die typischen Bestandteile eines Software-Entwicklungsprozesses sind: Phasen, Aktivitäten, Rollen, Dokumente, Methoden. Was versteht man unter Prozess-Tailoring? Prozess-Tailoring ist eine Anpassung des Prozesses an die projektspezifischen Erfordernisse. Jegliche Software-Entwicklungsprozesse für die unterschiedlichsten Projektklassen (z.B. Vorfeldentwicklung, Variantenentwicklung etc.) lassen sich so bezüglich der Projektziele, des Projektcharakters und der Projekteigenschaften flexibel anpassen. Gerade bei umfangreichen Vorgehensmodellen wie z.B. dem V-Modell benötigt man diese Tailoring-Funktion, um es ökonomisch nutzbar zu machen.

Was sind die Vorteile einer inkrementellen Entwicklungsweise? Die Vorteile einer inkrementellen Entwicklungsweise bestehen in der Minimierung von Risiken im Projekt sowie einer optimierten Analyse der Anforderungen. Dies wird durch schrittweise Erweiterung und Integration des Systems erreicht. Nach jeder Iteration steht ein lauffähiges Produkt zur Verfügung, welches vom Entwickler und Anwender neu evaluiert werden kann. Was unterscheidet Extreme Programming vom Rational Unified Process? Im Gegensatz zu dem Vorgehensmodell RUP wird beim XP (Extreme Programming) weniger Wert auf Rollen, Dokumente und Phasen gelegt. Entscheidungen, wie im Projekt weiter vorgegangen werden soll, sind im RUP meist mit deutlichem Managementaufwand verbunden. XP verringert diesen hohen Aufwand durch eine Reihe von Praktiken. Ein Unterschied besteht etwa durch die sogenannten Stories sowie dem zugehörigen „Planning Game“: Stories werden zwischen Benutzer und Entwickler „verhandelt“. Das Projekt wird in Releases aufgeteilt, welche diese vereinbarten Stories beinhalten. XP eignet sich vor allem für kleinere Projekte und Projektteams. RUP hingegen ist unter anderem durch die Verwendung von UML sowie der im RUP beschriebenen CASE Werkzeuge sehr gut für komplexe Projekte geeignet. XP stellt keine ausführliche Dokumentation zu dem entwickelten System zur Verfügung und ist personenabhängig.

Übungsaufgaben zu Kapitel Projektstart Was sind typische Probleme beim Projektstart? Zeitknappheit in der Phase des Projektstarts führt zu einer Reihe von Risiken bzw. Problemen. Typische Probleme sind unrealistisches und mangelndes einheitliches Verständnis der Projektziele, fehlende organisatorische Regeln, unverbindliche Projektpläne und mangelhafte Unterstützung durch das Management. Was sind die Eigenschaften eines gut definierten Projektziels? Projektziele sollten sowohl quantifizierbar als auch erreichbar sein und im Einklang zu übergeordneten strategischen Unternehmenszielen stehen.

Skizzieren sie den Projektstartprozess in Ihrem Unternehmen Szenario „Aufwandsprojekt Software-Entwicklung für klassische Auftragnehmer-Auftraggeber-Situation“:

1. Kunde stellt eine Anfrage. 2. Anfrage wird innerhalb des Unternehmens an den Vertrieb weitergeleitet. 3. Entscheidung durch Vertrieb: Falls Anfrage prinzipiell interessant ist

(Unternehmensstrategie), wird ein Vertriebsprojekt gestartet. 4. Vertriebsmitarbeiter führt ersten Kundentermin durch (Vorstellung Firma,

Austausch über Ziele im Projekt, erste Klärung finanzieller Randbedingungen). 5. Vertriebsmitarbeiter stellt zusammen mit dem zukünftigen Projektleiter das

Anfangsteam für die Anforderungsanalyse zusammen. 6. Projektteam analysiert die Projektziele es entsteht eine erste Frageliste. 7. Zweiter Termin beim Kunden: Vertriebsmitarbeiter stellt das Anfangsteam

bzw. deren Profile vor. Der Termin dient auch der weiteren Klärung der Projektziele sowie der Stundensätze.

8. Vertrieb erstellt und verschickt das Angebot. 9. Bei Eingang der Beauftragung: Auftragsbestätigung wird verschickt, Projekt

wird beginnend mit der Anforderungsanalyse abgearbeitet. 10. Falls keine Beauftragung: Gegebenenfalls werden Verhandlungen über

Inhalte und Stundensätze geführt. Vertrieb überarbeitet Angebot (zurück zu Schritt 8) oder Projektstartprozess wird beendet (falls keine Einigung erreichbar).

Welche Arten der Kommunikation werden speziell im Projektstartprozess durchgeführt? Einzelgespräche finden zwischen dem Projektleiter und den Projektbeteiligten statt. Einzelgespräche können Einstellungsgesprächen sehr ähnlich sein und dienen der Klärung von Verantwortlichkeiten im Projektteam und zur Information der Beteiligten über die Projektziele. Die Kick-off Veranstaltung ist eine Informationsveranstaltung und dient dem ersten kommunikativen Austausch unter den Projektbeteiligten, zur Schaffung einer einheitlichen Sichtweise auf Projektziele und Stärkung des Teamgefühls. Workshops dienen nicht nur dem reinen Sammeln von Informationen, sondern auch der Erarbeitung und/oder

Verfeinerung von Projektzielen, Meilensteinen, Projektplanung, Projektorganisation, Vorgehensplanung und Terminfestlegung oder anderen Themen. Was sind die Eigenschaften für gut formulierte Anforderungen? Gut formulierte Anforderungen sind eindeutig bezüglich der Sprache, vollständig, widerspruchsfrei und überprüfbar bezüglich der Forderungen. Ferner sind sie konsistent im Hinblick auf die Begrifflichkeiten (Terminologie, keine Synonyme), Standards und Folgerungen. Verfolgbar hinsichtlich der getroffenen Entscheidungen gut begründet. Verbesserte Anforderungen:

- Die Analyse eines Duftes darf nicht mehr als drei Sekunden dauern, ansonsten wird die Analyse abgebrochen sowie eine Fehlermeldung auf dem Display angezeigt.

- Die Inhalte der referenzierten Dokumente sind im Pflichtenheft zu integrieren.

- Unrealistische Forderung! - Nach Analyse eines Duftes muss dieser mit Werten in der Tabelle T

verglichen werden. Bei Werten, die nicht in dieser Tabelle zu finden sind, wird von fehlerhaften Gerüchen ausgegangen und sie sind mit der Fehlermeldung F zu quittieren.

- Im Administrator-Mode muss durch Signalton B und Aufleuchten des Signals C eine Reaktion des Subsystems auf folgende Fälle erfolgen ... (konkrete Nennung der Bedingungen erforderlich!)

- Der Signalton B muss bei einer Überschreitung eines Zeitintervalls von X Sekunden ausgelöst werden. Dieses Zeitintervall kann im Administrator-Mode auf einen Wert zwischen 2 und 60 Sekunden (2 <= X <= 60) gesetzt werden.

Übungsaufgaben zu Kapitel Projektplanung Warum ist eine saubere Projektplanung unbedingt notwendig?

• Um typische Planungsfehler wie unrealistische Pläne, zu ehrgeizige Pläne, nicht mit den Beteiligten abgestimmte Pläne, etc zu vermeiden.

• Eine gute Planung dient dazu… o Vermeiden oder Verringern von Redundanzen. o Verbesserung der Effizienz der Projektabwicklung. o Erhalten eines besseren Verständnisses der Projektziele. o Bereitstellen einer Basis für die Kontrolle und Steuerung der Arbeiten.

• Eine gute Projektplanung ist das Fundament für das Gelingen des Projektes. • Vermeiden von Fehlplanungen. • Eine gute Projektplanung zu Projektbeginn kann Änderungen während des

Projektverlaufs durch äußere Einflüsse oder projektinterne Entwicklungen nicht ausschließen, sie kann aber die Anzahl der Änderungen aufgrund von Planungsfehlern erheblich reduzieren.

Was sind die wesentlichen Planungsschritte?

In welcher / welchen Phasen finden Planungsaktivitäten statt? In welcher Intensität?

Startph. Planungsphase Durchführungsphase

Erste Grobplanungim Rahmen

der Angebots-abgabe

Grobplanung

DetailliertePlanung

weitereDetaillierungz.B. nächste

Iteration

Planungs-Intensität

t

Was sind Meilensteine? Ein Meilenstein ist das Erreichen eines messbaren, bedeutenden Ereignisses im Projekt wie z.B. der Abschluss eines Liefergegenstandes (engl.: deliverable) oder das Ende einer Phase zu einem bestimmten (geplanten) Termin. Meilensteine werden basierend auf den Projektzielen festgelegt und können mit entsprechenden Reviews <ref=“siehe Abschnitt QS“> oder der Übergabe eines Liefergegenstandes gekoppelt sein. Was ist der Projektstrukturplan (PSP)? Was ist der Inhalt eines PSP?

o Die Praxis der Projektstrukturplanung präzisiert den PSP gemeinhin als „die vollständige hierarchische Anordnung aller Elemente eines Projektes".

o Ein PSP ist eine in der Regel an den Liefergegenständen oder Projektphasen orientierte Anordnung von Projektelementen, die den Gesamtinhalt und -umfang des Projektes strukturiert und definiert. Jede niedrigere Ebene beinhaltet eine detaillierte Beschreibung eines Projektelementes. Liefergegenstände, die nicht im PSP stehen, sind außerhalb des Projektumfangs.

Welche Schätzmethoden kennen Sie? 1) Analogieschätzungen

o Multiplikatormethode o Projektsatzmethode

2) Expertenschätzungen o Delphi-Methode (Top Down) o Informelle Expertenschätzung (Top Down und Bottom Up) o Drei-Punkt-Schätzung (Bottom Up)

3) Fortgeschrittene Methoden o Cocomo o Function Point

Wie berechnet sich der gewichtete Schätzwert PERT?

Was ist der Zusammenhang zwischen Größen- / Aufwand- / und Kostenschätzung? Größenschätzung: Bei Schätzungen für Software-Komponenten sollte eine Größenschätzung durchgeführt werden (z.B. Lines of Code, Anzahl Module, etc.). Aber nicht nur Software-Komponenten können geschätzt werden. Auch die Größen von Dokumenten und anderen Arbeitsprodukten können und sollten basierend auf einfachen, qualitativen Komplexitätsmaßen (z. B Anzahl Seiten bei Dokumenten, Anzahl Testfälle, etc. ) geschätzt werden. Aufwandschätzungen sollten, wenn möglich, auf Größenschätzungen basieren und mittels einer Schätzmethode ermittelt werden. Basierend auf den geschätzten Größen werden die Aufwände zur Erstellung der einzelnen Arbeitsprodukte geschätzt. Kostenschätzung: Der größte Kostenfaktor in der Software-Entwicklung sind die personellen Kosten. Die Personalkosten werden durch Multiplikation des geschätzten Arbeitsaufwands mit den zugehörigen Personalkostensätzen ermittelt. Betrachtet werden müssen aber auch die Kosten für weitere Ressourcen wie technische Ausrüstung, Gerätenutzung, Materialien, Schulungen, Subunternehmer etc.. Diese Kosten können meistens relativ präzise ermittelt werden. Reihenfolge: 1. Größenschätzung 2. Aufwandschätzung 3. Kostenschätzung Was sind die wesentlichen Schritte zur Erstellung eines Aktivitätenzeitplans? 1. Liste der Aktivitäten aus dem PSP ableiten 2. Erstellen des Aktivitätenzeitplans durch Durchführen der Teilschritte o Abhängigkeiten einbringen o Aufwände einbringen o Ressourcen zuordnen o Zeitdauer einbringen o Meilensteine einbringen o Start- und Ende-Termine ermitteln … bis die (terminlichen) Ziele des Projektes erfüllt werden. 3. ggf. wird die Planung nochmals optimiert

Gewichteter Schätzwert (PERT)=

Opt. + 4xReal. + Pess.

6

Welche Anordnungsbeziehungen gibt es zwischen Aktivitäten im Rahmen eines Aktivitäten(zeit-)plans? o Zwingende Anordnungsbeziehungen o Wahlfreie Anordnungsbeziehungen o Externe Anordnungsbeziehungen Für alle Anordnungsbeziehungen können bestimmte Vor- und Nachlaufzeiten erforderlich sein, um eine Beziehung zu definieren. Was wird unter Ressource Leveling verstanden? Ressourcen mit den notwendigen Qualifikationen stehen oft nur in begrenztem Umfang zur Verfügung. Häufige Wechsel von Ressourcen und deren optimale Zuordnung im Sinne der Minimierung der Projektdauer sind schwer zu beherrschen, daher ist ein möglichst schwankungsarmer Verlauf anzustreben. Man spricht in diesem Zusammenhang von Ressource Leveling. Berechnen Sie den Netzplan Abbildung 18 Beispielnetzplan neu für den Fall, das Aktivität 3 aufgrund einer neuen Schätzung nun 3 Wochen dauert. Was ist nun der kritische Pfad? Neue Dauer : 8 Wochen Kritischer Pfad : 1=>3=>7=>10=>11 Welche Möglichkeiten zur Planungsoptimierung kennen Sie?

o Struktur des Plans ändern / Parallelisieren o Personaleinsatz ändern / Mehr Personal o Outsourcing o Zukauf von Standardkomponenten o Leistungsumfang ändern / reduzieren o Terminverschiebung

Welche Dokumente kann ein Projektplan beinhalten?

Projekt-plan

Kosten-planung

Projekt-definition

Projekt-strukturplan

Meilen-steinplan

Aktivitäten-zeitplan

Aufwand-schätzung Größen-

schätzung

Kosten-schätzung

Projekt-ziele

Projektspez.Vorgehensmodell

Projektvorgaben

Risiko-planung

Kommunikations-plan

Personal-einsatzplanung

Offene Punkte, ausstehende

Entscheidungen

Welche wesentlichen Fragen muss eine Projektplanung bei iterativer Entwicklung beantworten?

o Wie viele Iterationen werden benötigt? o Wie lange soll eine Iteration dauern? o Was soll der Inhalt einer Iteration sein? o Wie sollen Iterationen kontrolliert werden?

Übungsaufgaben zu Kapitel Projektkontrolle Welche wesentlichen Aufgaben werden im Rahmen der Projektkontrolle und –steuerung durchgeführt?

o Lenken, koordinieren und steuern o Überwachen des Projektfortschritts o Fortschrittsberichte o Änderungsmanagement o Anpassen des Projektplans

Was beinhaltet die Fortschrittsüberwachung auf Aktivitätenebene? Auf der untersten Ebene berichten die Entwickler ihren Fortschritt an die nächst höhere Ebene. Im kleineren Projekt ist dies der Projektleiter selbst, im größeren Projekt sind Ebenen dazwischengeschaltet (z.B. Team oder Teilprojektleiter). Hier werden die Rohdaten erhoben, die für die Fortschrittsüberwachung auf Projektebene benötigt werden. Was beinhaltet die Fortschrittsüberwachung auf Projektebene? Hier werden die Fortschrittsdaten von unten nach oben über die verschiedenen Ebenen verdichtet, damit der Projektleiter ein klares Bild des Fortschritts auf Gesamtprojektebene gewinnt und dieses auch nach außen (Management, Kunde) vermitteln kann.

Welche Arten von Meetings sollten im Rahmen der Projektkontrolle und –steuerung in der Regel durchgeführt werden?

Art von Besprechung Zweck TeilnehmerTeambesprechungen, techn. Projektbesprechung

Probleme u. Lösungen auf Aktivitätenebene, Arbeitsfortschritt

Projekt-/Teamleiter, Entwickler

Interne Fortschrittsreviews Arbeitsfortschritt im Vergleich zum Plan, Maßnahmen, ausgewählte Probleme, Risiken, Change Requests

Projekt-/Teamleiter, Entwickler

Formale Fortschrittsreviews Arbeitsfortschritt im Vergleich zum Plan, in Kürze: ausgewählte Probleme, Maßnahmen, Risiken

Projekt-/Teamleiter, Management

Meilensteinreviews Arbeitsfortschritt im Vergleich zum Plan, Prüfung formaler Voraussetzungen, Freigabe der nächsten Phase

Projekt-/Teamleiter, Management, QS, ggf. Kundenvertreter

Projektsteuerkreis bzw. Lenkungsausschuss

Rechenschaftsbericht, ausgewählte Probleme, strategische Fragen, Koordination verschiedener Interessen, Treffen wichtiger Projektentscheidungen

Projekt-/Teamleiter, Management, Kundenvertreter

Was sind typische Probleme bei der Interpretation von Aufwandszahlen / Fertigstellungsgrad / Restaufwand?

o Interpretationsproblematik bei nur Aufwandskennzahlen => Ergänzung durch Fertigstellungsgrad bzw. Restaufwand nötig.

o Die Problematik beim Fertigstellungsgrad liegt im sogenannten 90 % Syndrom. Gemeint ist, das oftmals der Fertigstellungsgrad zunächst einen unauffälligen, linearen Verlauf nimmt, um dann gegen Ende hin nur noch langsam vorwärts zu gehen.

o Das 90 % Syndrom gilt sinngemäß auch beim Restaufwand. Was ist eine Meilenstein-Trendanalyse? Wie funktioniert diese? Die Meilenstein-Trendanalyse ( abgekürzt: MTA) wird gelegentlich auch als „Termin-Trendanalyse“ oder als „Zeit/Zeit-Diagramm“ bezeichnet. MTA erlaubt einen schnellen Überblick, wie sich in der Zukunft liegende Meilensteine (oder andere Termine) während der Projektlaufzeit entwickeln, d.h. ob die Terminvorhersagen stabil sind oder ob die Termine „weglaufen“ bzw. ob die Planungen realistisch sind. Das Prinzip ist einfach: In einem Diagramm stellt die eine Achse die Berichtszeitpunkte dar, die andere Achse die Plantermine. Ein Datenpunkt im Diagramm steht also für einen Plantermin zu einem bestimmten Berichtszeitpunkt.

Plan

term

ine

Berichtszeitpunkte

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03

31.10.

30.11.

31.12.

Was ist Earned Value? Wie berechnet sich der Earned Value? Wie berechnen sich Cost Variance und Schedule Variance? Was sagen diese Kenngrößen über ein Projekt aus? Earned Value Analysis (kurz EVA) ist eine relativ weit verbreitete Methode zur Fortschrittsbewertung. EVA erlaubt es, mit einem kleinen Satz von Kenngrößen treffsichere Aussagen über die Termin- und Kostensituation eines Projekts zu machen. Earned Value (EV): bezeichnet den tatsächlichen Wert der geleisteten Arbeit bzw. genauer: Die geplanten Kosten für die tatsächlich geleistete Arbeit, d.h. was die Aktivität laut Plan hätte kosten sollen, gemessen an dem tatsächlichen Arbeitsfortschritt. Dieser Wert berechnet sich aus den Plankosten der Aktivität für deren Gesamtdauer (laut Kostenplanung), multipliziert mit dem Fortschrittsgrad der Aktivität. Planned Value (PV), bezeichnet, was die Aktivität laut Plan für einen bestimmten Zeitraum hätte kosten sollen. Diese Information kommt aus der Kostenplanung. Actual Cost (AC), bezeichnet, was die Aktivität für einen bestimmten Zeitraum tatsächlich gekostet hat. Cost Variance CV = EV – AC. CV ist die Differenz zwischen dem Wert der geleisteten Arbeit und den tatsächlichen Kosten. CV ist also ein Maß für die Kosteneinhaltung. Schedule Variance SV = EV – PV. SV ist die Differenz zwischen dem Wert der geleisteten Arbeit und den für den Berichtszeitpunkt geplanten Kosten. SV ist also ein Maß für die Termineinhaltung bzw. auch für den Fortschritt gegenüber dem Plan.

Welche Informationen sollte ein Projektfortschrittsbericht an das Management beinhalten?

o Kostensituation o Terminsituation o Leistungsumfang o Qualitätssituation o Personalstatus o Risiken o Ausgewählte technische Probleme, soweit sie für Kosten, Termine und

Funktionsumfang relevant sind Welche Eingriffsmöglichkeiten sollte ein Projektleiter im Falle von Termin- / Kosten- / Funktionalitäts- / Qualitätsproblemen haben?

Terminproblem o Mehr Personal, aber es gilt oft „Adding manpower to a late project makes it

even later.“(Murphy’s law) o Funktionsumfang reduzieren o Abstriche bei Qualität o Kritischen Pfad kürzen

Kostenproblem Betrifft das Kostenproblem die Stückkosten des Endprodukts (z.B. bei embedded systems), so gibt es verschiedene Methoden, die wir aber hier nicht weiter behandeln können. Wir beschränken uns auf Kostenprobleme beim Entwicklungsprojekt. Wird der in der Kostenplanung gesetzte Rahmen gesprengt, sind meistens Aufwandssteigerungen die Ursache, die in der Projektplanung noch nicht vorhersehbar waren. Diese Aufwandssteigerungen haben normalerweise mit technischen Problemen zu tun und Patentrezepte dagegen gibt es nicht. Eine Verminderung der Entwicklungskosten ist nur auf Kosten der Funktionalität (d.h. Projektumfang reduzieren) oder der Qualität (z.B. weniger Testen) möglich. Ansonsten muss das Kostenproblem mit dem Management diskutiert und ein neuer Kostenplan verhandelt werden.

Funktionalitätsproblem Lassen sich Funktionalitäten des Produkts nicht wie gewünscht realisieren, sind normalerweise technische Probleme oder Anforderungsprobleme die Ursache, die immer individuell behandelt werden müssen. Einige allgemeine Möglichkeiten, die das Team prüfen kann, sind: o Ist es sinnvoll, projektexterne Experten hinzuzuziehen? o Sind alternative Realisierungskonzepte möglich? o Kann das Problem durch Outsourcen an einen erfahrenen Subunternehmer

gelöst werden? o Können Eigenentwicklungen durch zugekaufte Komponenten ersetzt werden?

Qualitätsproblem Qualitätsprobleme treten naturgemäß erst in späten Projektphasen auf und dann bleibt als einzige Strategie entsprechend gründliches Testen und Beseitigen der

Probleme. Das Projekt tut daher gut daran, Qualitätsprobleme erst gar nicht auftreten zu lassen, indem bewährte Software Engineering-Methoden schon im Vorfeld angewendet werden. Hierzu gehört z.B. der konsequente Einsatz von Reviews während aller Entwicklungsphasen: Review des Pflichtenhefts, Design-Reviews, Code-Reviews etc.. Die Erfahrung zeigt, dass insbesondere Reviews in frühen Entwicklungsphasen einen besonders hohen Kosten-/Nutzen-Effekt haben, indem Folgefehler in mehreren nachfolgenden Phasen vermieden werden. Was ist bei Änderungen des Projektumfangs zu beachten? Änderungen am Projektumfang müssen wegen der weitreichenden Konsequenzen auf jeden Fall sorgfältig und systematisch behandelt werden. => Sorgfältige Analyse => Abwägung der Auswirkung der Änderungen auf laufende und zukünftige Aktivitäten => Bewusste Entscheidung Was ist die Aufgabe eines Change Control Boards? Das CCB ist das Gremium im Projekt, das entscheidet, ob Änderungen am Projektumfang durchgeführt werden oder nicht.

Übungsaufgaben zu Kapitel Software-Qualitätssicherung Was sollte ein Software-Qualitätssicherungsplan enthalten? Zuständigkeit und Befugnisse des QS-Personals Benötigte Ressourcen Budgetierung der QS-Aktivitäten Qualitätssichernde Maßnahmen und Zeitplan Bei den Prüfungen zugrunde zu legende Normen und Verfahren Verfahren zur Behandlung von Abweichungen (inklusive Eskalation zum Management) Zu erstellende Dokumentation Art und Weise des Feedbacks an das Projektteam Welche zwei Rollen sollte ein QS-Verantwortlicher inne haben? Was beinhalten diese Rollen? In der Praxis hat sich bewährt, dass der QS-Verantwortliche neben der „unabhängigen, prüfenden Rolle“ auch eine „unterstützende Rolle“ wahrnehmen sollte, auch wenn dies z.B. in den Reifegradmodellen nicht explizit gefordert wird. Als unterstützende Rolle hilft er der Projektleitung bei der Projekt- und Software-QS-Planung, bei der Auswahl der Projektstandards sowie bei der Durchführung von QS-Maßnahmen im Projekt. Dadurch erreicht er die notwendige Akzeptanz im Projekt. Weiter hat er als unabhängige, prüfende Rolle folgende Aufgaben: o Prüfung der Einhaltung der Vorgaben und Kundenanforderungen für Arbeitsprodukte und Prozesse (z.B. durch Audits, Reviews,…) o Verfolgung der Beseitigung entdeckter Mängel o Berichtswesen an das Management o Prüfung von Unterauftragnehmern Welche Software-Qualitätssicherungsmaßnahmen kennen Sie?

Prozessqualität

Produktqualität

Qualitätssicherende Maßnahmen

19.05.2003 - v6

ReviewsAudits

AssessmentsDokumentensichtungBetriebsbesichtigung

Interviews

AnalysierendMetriken

Graphen und Tabellen...

VerifizierendProgrammverifikation

Symbol. Programmausführung

AnalysierendMetriken

Graphen und TabellenAnomalieanalyse

Statisches TestenStruk. Gruppenprüfungen

ReviewInspektion

Statische Analyse

Dynamisches TestenBlack-Box...

White-Box...

SimulationDokumentensichtung

Worin unterscheidet sich ein Audit von einem Review? Ein Audit ist eine systematische und unabhängige Untersuchung mit formalem Charakter. In einem Audit wird festgestellt, ob die zu prüfenden Tätigkeiten und die damit zusammenhängenden Ergebnisse den geplanten Vorgaben entsprechen und diese Vorgaben geeignet sind, die Ziele zu erreichen. Wir verstehen unter Audit in diesem Sinne eine formale QS-Maßnahme zur Sicherung der Prozessqualität. In einem Audit wird also die Konformität der Prozesse mit den Vorgaben überprüft. Ein Review ist eine manuelle Prüfmethode mit mehr oder weniger festgelegtem Ablauf, die nach einer individuellen Vorbereitung der Gutachter in einer Teamsitzung Stärken und Schwächen eines schriftlich vorliegenden Prüfobjekts identifiziert. Wir verstehen unter Review in diesem Sinne eine QS-Maßnahme zur Sicherung der Produktqualität. Reviews können sowohl als formale QS-Maßnahme als auch im Rahmen von V&V-Maßnahmen eingesetzt werden. Prüfobjekte können dabei jegliche Arbeitsprodukte (Dokumente, Code,…) sein. Es gibt mehrere <ind=“Review-Arten“> wie Walkthrough, Inspektion und informelles Review. Welche Kriterien sollte ein informelles Review zumindest erfüllen? Auch informelle Reviews sollten zumindest zwei Kriterien erfüllen: 1. Das Review sollte geplant werden, d.h. geeignete Gutachter sind auszuwählen und das Vorgehen wie Verteilung, Termine, etc. sollte im Vorfeld vereinbart werden. 2. Das Review-Ergebnis muss dokumentiert werden, d.h. zumindest die Mängel sind festzuhalten (z.B. mittels Notizen auf dem Dokumentenausdruck).

Übungsaufgaben zu Kapitel Projektabnahme und -abschluss Was ist der Unterschied zwischen Validierung und Verifikation? Validierung ist die Technik, um am Projektende (bei der Projektabnahme) herauszufinden, ob das richtige Produkt entwickelt wurde. Das Produkt wird gegen die Anforderungen des Kunden geprüft. Verifikation ist die Technik, die verwendet wird um herauszufinden, ob das Produkt richtig entwickelt wurde. Verifikation wird nicht erst am Projektende bzw. bei der Projektabnahme durchgeführt, sondern während der Projektlaufzeit. Verifiziert wird gegen die Spezifikationen (niedergeschriebene Anforderungen, Design-Dokumentation) des Produkts und der einzelnen Arbeitsprodukte. Was gehört typischerweise zu einem Abnahmeprotokoll? In ein Abnahmeprotokoll gehören: • Projektdaten wie Projektbezeichnung, Auftragsnummer, Auftragsdatum,

Auftraggeber. • Die Benennung der Software inklusive der Versionsnummer plus aller

abzunehmender Produkte, auch Dokumentation und Begleitmaterial sowie Datum, Ort und Teilnehmer der Abnahme (Zuordnung zu Firma bzw. Auftragnehmer oder Auftraggeber).

• Art der Abnahme (Teilabnahme oder Gesamtabnahme). • Verweise auf weitere Eingangs- und/oder Ergebnisdokumente der durchgeführten

Abnahme. • Abnahmeergebnisse und Dokumentation des Datums • Unterschrift des Auftraggebers und Auftragnehmers Wann sollte das Vorgehen zur Abnahme definiert werden? Das Vorgehen zur Abnahme sollte bereits im Projektvertrag festgelegt werden, oder zumindest in einer frühen Projektphase. Dies führt dazu, dass von Anfang an effizient auf die Abnahme hingearbeitet werden kann und dass am Projektende keine Unklarheiten oder Konflikte aufgrund unklarer Vorgehensweise bei der Abnahme entstehen. Wann sollten die Abnahmekriterien feststehen? Die Abnahmekriterien müssen vor der Durchführung einer Projektabnahme definiert werden. Idealerweise geschieht dies bereits zu Beginn eines Projektes, sobald die Kundenanforderungen definiert sind. • Erstellen Sie eine Gliederung für einen Projektabschlussbericht • Zielbetrachtung (welche sind erreicht, welche nicht) • Projektnachkalkulation • Generell:

o Was ist gut gelaufen? o Was ist verbesserungsfähig? o Was haben wir für die Zukunft gelernt?

• Aktionspunkte (z.B. Aktualisierung von Prozessen, etc.)

Übungsaufgaben zu Kapitel Personalmanagement Was können die Ursachen für einen Team-Selbstmord sein? Einem Team-Selbstmord kann eine mangelhafte Kommunikation vorausgehen. Im betroffenen Projekt wird nicht ausreichend mit Kunden, Kollegen, Vorgesetzten und Stakeholdern kommuniziert. Ursache können unklare Kommunikationswege, aber auch endlose unproduktive Meetings sein. Unrealistische Projektziele, lange Projektlaufzeit, das Feindbild Kunde und ständige Einmischungen und Kontrollen durch das Management führen ebenfalls leicht zu einem Team-Selbstmord.

Worin besteht die Gefahr, wenn eine Qualitätsreduktion zugunsten der Projektlaufzeit angeordnet wird? Die Selbstachtung von Entwicklern / Projektbeteiligten sinkt, wenn ein Produkt mit geringerer Qualität ausgeliefert werden muss.

Worin unterscheidet sich ein Sportteam von einem Projektteam, das Software entwickeln soll? Eine Sportmannschaft steht mit anderen Teams im Wettstreit und Teammitglieder des selben Sportteams konkurrieren um Ruhm und Gehalt untereinander. Ein gutes Software-Entwicklungsteam zieht an einem Strang und wird im Ganzen betrachtet und nicht wie beim Sportteam durch seine Stars definiert.

Wodurch unterscheidet sich „Wissen“ von „Können“ und von „Erfahrung“?

Wissen kann durch Lesen eines Buches oder Besuchen eines Trainings (Vorlesung, Seminar, Workshop) angeeignet werden. Erst wenn dieses erlernte Wissen z.B. in einem Projekt umgesetzt werden kann, spricht man von Können. Erfahrung wird mit dem mehrmaligen Einsatz von Wissen und Können z.B. in Projekten gewonnen.

Erstellen Sie Ihre eigenen Führungsgrundsätze für Ihr aktuelles oder nächstes Projekt?

• Führen durch Vorbild • Motivation durch Lob und Anerkennung • Mitarbeiter zu Helden machen • Sich um ALLE Mitarbeiter bemühen (nicht nur die neuen).

Worin besteht die Gefahr beim „Führen durch Vorbild sein“? Die eigentliche Aufgabe der Führung, das Management, verliert sich hinter dem bestreben einen Vorbildcharakter zu schaffen. Skizzieren Sie den Geschäftsverlauf einer „Idealen Anweisung“.

• Positiver Einstieg o klar, konkret, Sicherheit geben, Atmosphäre schaffen

• Reizvolles, konkretes Ziel formulieren o Mitarbeiterbedürfnisse berücksichtigen

o Attribute: erreichbar, erstrebenswert, vollständig, widerspruchsfrei, nicht interpretierbar, prüfbar, lösungsneutral, dokumentiert

o Wir wollen - machen Sie mit? • Bereitschaft des Mitarbeiters erfragen • Anerkennung durch den Chef • Ideen erfragen

o Möglichst viele Ideen des Mitarbeiters erfragen o Die Idee des Mitarbeiters ist gesucht!

• Weg vereinbaren o Auf was legen wir uns fest?

• Verbindlich bleiben und positiver Ausstieg o Ziel, Termin, bis wann/ wer/ was?

Übungsaufgaben zu Kapitel Projektorganisation Was sind die Ziele der Projektorganisation? Regelung der Aufbau- und Ablauforganisation bzw. der statischen und dynamischen Aspekte sowie die Regelung der Verantwortlichkeiten im Projekt. Hierzu gehören beispielsweise folgende Aspekte:

• Wer hat welche Rolle im Team? • Wer ist für was verantwortlich? • Wer ist Stellvertreter für wen? • Welche (Teil-)Teams gibt es überhaupt? • Welche externen Zulieferer gibt es? • Wer muss wann mit welchen Informationen (Berichtswesen) versorgt

werden? • Wie setzt sich der Lenkungsausschuss zusammen? • Wie ist das Thema Eskalation geregelt? • Wie ist das Projekt im zeitlichen Ablauf strukturiert?

Nennen Sie die Vor- und Nachteile der verschiedenen Organisationsformen.

• Stammorganisation: o Vorteil: Aufwandsarm, da keine Eingriffe in die

Projektorganisation. o Nachteil: Das längerfristige Projektgeschäft geht meist im

kurzfristigen Tagesgeschäft unter, da typischerweise das Projektgeschäft neben dem Tagesgeschäft erledigt wird. Interdisziplinäre Projekte sind schwieriger abzuwickeln.

• Stabs-/Einfluss-Projektorganisation: o Vorteil: Kein Eingriff in die Linienorganisation des Unternehmens

und daher aufwendungsarm. o Nachteil: Entscheidungsbefugnis verbleibt beim

Linienmanagement, der Projektleiter hat nur koordinierende Funktionen. Folge: Der Projektleiter ist auf die Kooperationsbereitschaft der einzelnen Fachabteilungen angewiesen und hat mit Akzeptanzproblemen gegenüber dem Projektteam zu kämpfen. Abteilungsinteressen haben Vorrang gegenüber dem Projekt.

• Matrix-Projektorganisation: o Vorteil: Der Projektleiter hat Führungsbefugnis (Personifizierung

der Verantwortung). Keine Umorganisation des Unternehmens wie z. B. bei der reinen Projektorganisation und daher aufwendungsärmer.

o Nachteil: Mitarbeiter bekommen Weisungen von zwei Vorgesetzten (Projektleiter/Abteilungsleiter). Ein Konflikt entsteht, wenn der Projektleiter und der Abteilungsleiter zwei Aufgaben mit gleicher Priorität an den Mitarbeiter delegieren.

• Reine Projektorganisation: o Vorteil: Klare Verantwortlichkeiten bzw. klare Zuordnung von

Ressourcen zum Projekt und eine optimale Ausrichtung der Ressourcen und Aktivitäten auf die Projektziele. Der Projektleiter besitzt weitreichende Befugnisse.

o Nachteil: Aufwand für die Umorganisation des Unternehmens. Unsicherheit bei Mitarbeitern und die sich daraus ergebende Fluktuationsrate.

Wer sitzt typischerweise im Lenkungsausschuss? Im Lenkungsausschuss befinden sich der Gesamtprojektleiter und Entwicklungsleiter von Auftragnehmerseite, der Projektleiter, weitere Personen vom auftraggebenden Unternehmen und eventuell weitere kooperierende Unternehmen. Üblicherweise sind auch wichtige Stakeholder, Kostenverantwortliche und Vertreter aus der Geschäftsleitung anwesend.

Was wird im Lenkungsausschuss besprochen? Im Lenkungsausschuss werden wichtige und strategische Entscheidungen, Projektrisiken und der Projektfortschritt besprochen sowie finanzielle Fragen und schwerwiegende organisatorische Probleme erörtert.

Übungsaufgaben zu Kapitel Risikomanagement Warum ist Risikomanagement notwendig?

o Risikomanagement ist ein kontinuierlicher, projektbegleitender Prozess und ein wichtiger Bestandteil der Projektmanagementaktivitäten. Dabei ist es besonders wichtig, Risiken frühzeitig zu entdecken und etwas dagegen zu unternehmen, da z. B. Änderungen an Plänen oder Konzepten in frühen Projektphasen einfacher und kostengünstiger sind und weniger Folgeänderungen nach sich ziehen als später.

o Gesetzliche Verpflichtung für ein systematisches Risikomanagement bei Aktiengesellschaften.

Welche Methoden zur Risikoermittlung gibt es? Was ist das Ergebnis einer Risikoermittlung? Methoden:

o Risikomanagement Workshops !!! o Aber auch Interviews, Befragungen,… o Analyse von Projektplänen und Projektdokumenten o Analyse von gesetzlichen Vorgaben

Ergebnis der Risikoermittlung:

o Die Risiken sind identifiziert und dokumentiert o Am Ende soll jedes Risiko verständlich charakterisiert sein und alle

Teilnehmer ein gemeinsames Verständnis haben. o Gegebenenfalls Gruppierung von Risiken

Wie werden Risiken typischerweise bewertet? Was ist das Ergebnis der Risikobewertung? Risiken werden typischerweise nach drei Bewertungsparametern bewertet und priorisiert: Bewertungsparameter o Eintretenswahrscheinlichkeit (EW): Wie wahrscheinlich ist es, dass der Risikofall eintritt? o Schadenshöhe (PSH): Welchen Schaden wird das Risiko verursachen? o Risikopriorität Ergebnis der Risikobewertung:

o Die Risiken sind bewertet hinsichtlich EW und PSH o Die Risiken sind priorisiert

Dokumentation der Risiken in der Risikoliste, die u.a. eine Beschreibung des Risikos und die Bewertungsparameter enthält. Welche möglichen Arten von Gegenmaßnahmen gibt es?

o Präventive oder vorbeugende Maßnahmen („Risk mitigation plans“) und o Notfallmaßnahmen („Contingency plans“)

Was ist zu tun im Rahmen einer Risikoverfolgung? 1) Verfolgung der Gegenmaßnahmen => wie alle anderen Aktivitäten des Projekts

sollten diese regelmäßig verfolgt werden, d.h. ihr Fortschritt wird geprüft, der

Aufwand wird verfolgt, der für die Maßnahme Verantwortliche berichtet regelmäßig, etc.

2) Verfolgung der Risiken: Auch Risiken dürfen nicht aus den Augen verloren werden. Z.B. könnten sich neue Sachverhalte ergeben, die ein neues Licht auf Scha-denshöhe oder Eintretenswahrscheinlichkeit werfen. Im positiven Fall können z.B. Gegenmaßnahmen abgebrochen werden. Im negativen Fall müssen neue Gegenmaßnahmen geplant oder vorhandene intensiviert werden. Außerdem könnte sich das Eintreten eines Risikos ankündigen und Notfallmaßnahmen müssten initiiert werden. Unter Umständen kann es im Sinne einer besseren Überwachung sinnvoll sein, die Symptome, mit denen sich das Eintreten eines Risikos ankündigt, bereits vorab zu ermitteln und zu dokumentieren.

Übungsaufgaben zu Kapitel Reifegradmodelle Was sind Reifegradmodelle? Wie funktionieren diese prinzipiell? Dies sind Modelle zur Messung, Bewertung und Verbesserung des Software-Entwicklungsprozesses. Diese beinhalten Best Practices, gegen die die realen Prozesse verglichen werden. Anhand der Ergebnisse des Vergleichs werden neben Reifegradstufen auch Stärken und Verbesserungspotentiale identifiziert und konkrete Empfehlungen gegeben. Reifegradmodelle enthalten Best Practices, die sich in der Industrie über Jahrzehnte hinweg in vielen Projekten als erfolgreich erwiesen haben und deren Implementierung erfahrungsgemäß zu Verbesserungen hinsichtlich z.B. Qualität, Termin- und Budgeteinhaltung führen. Unternehmen können diese Praktiken adaptieren, um somit besser und erfolgreicher Software zu entwickeln und dabei schrittweise verschiedene Reifegradstufen erreichen. Was sind die 5 bzw. 6 Reifegradstufen der Reifegradmodelle CMM(I) und ISO 15504 und was bedeuten diese sinngemäß?

"Optimizing"

“Managed"

“Defined"

“Repeatable"

5

4

3

2

CMM

“Initial"1

"Optimizing"

"Predictable"

"Established"

"Managed"

SPICE

"Performed"

“Incomplete"

5

4

3

2

1

0

Was ist der wesentliche Unterschied zwischen CMM und ISO 15504? CMM ist ein Stufenmodell (staged Model), ISO 15504 ist ein durchgängiges Modell (continuous Model). Weitere Unterschiede:

o Das Prozessmodell von ISO 15 504 ist feiner gegliedert (40 Prozesse vs. 18 Schlüsselprozessbereiche).

o Das Prozessmodell von ISO 15 504 enthält Inhalte, die bei CMM nicht enthalten sind (wie z.B. Betrieb, Wartung). Abgesehen davon gibt es in vielen Prozessen Forderungen, die über CMM hinaus gehen. (z.B. „Identify Interfaces“ in Project Management)

o Das Prozessmodell von CMM enthält Inhalte, die bei ISO 15 504 nicht enthalten sind (z.B. Intergroup Coordination). Abgesehen davon gibt es viele Forderungen, die über ISO 15 504 hinaus gehen.

o Die Detaillierungstiefe und Ausführlichkeit ist bei CMM größer. o CMM deckt nur den Umfang des Software-Projekts ab, ISO 15 504 deckt auch

Schnittstellen zur Systemebene (Systemanforderungsanalyse und -design, Systemintegration und -test) ab.

Was ist ein Assessment? In einem Assessment (ähnlich einem mehrtägigen Audit) werden die betrieblichen Abläufe mit den Anforderungen des Reifegradmodells verglichen. Ergebnis ist u.a. eine Reifegradaussage (je nach Reifegradmodell für die einzelnen Prozesse oder für die untersuchte Organisation) sowie Stärken und Schwächen in den einzelnen Prozessen. Anhand der Assessment-Ergebnisse können konkrete Verbesserungsmaßnahmen definiert werden. Reifegrade können also auch dem Nachweis der Güte der (Entwicklungs-) Prozesse dienen und werden zunehmend von Unternehmen bei der Lieferantenbeurteilung eingesetzt.