Einordnung: Wasserfallmodell. Übersicht. Softwaretechnik- Praktikum: 2. Vorlesung. II Ergänzungen zur Software-Entwicklung

Transkript

1 Softwaretechnik- Praktikum: 2. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung V2-2 Softwaretechnikpraktikum: II Ergänzungen zur Software- Entwicklung (Fortsetzung) Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de II Ergänzungen zur Software-Entwicklung II.1 Reverse Engineering II.2 Machbarkeitsstudie II.3 Anforderungsdefinition II.4 Analyse II.5 Diskussion & Zusammenfassung II.6 Literaturhinweise V2-4 II.2 Machbarkeitsstudie Ziel der Phase: Planen eines Produktes: Auswählen des Produktes Voruntersuchung des Produkts Durchführbarkeitsuntersuchung Prüfen der ökonomischen Durchführbarkeit Einordnung: Wasserfallmodell Ergebnis: Stop or go Entscheidung Entwurf Machbarkeitsstudie Anforderungsdefinition Analyse Implementierung & Test Wartung V2-5 V2-6 1

2 Planen des Produktes (1/2) Auswählen des Produktes Trendstudien, Marktanalysen, Forschungsergebnisse, Kundenanfragen, Vorentwicklungen. Voruntersuchung des Produkts u.u. gezielte Ist-Aufnahme, wenn bereits Vorgängerprodukt vorhanden (siehe. Reverse Engineering); anschl. Ist-Analyse Festlegen der Hauptanforderungen Planen des Produktes (2/2) Durchführbarkeitsuntersuchung Prüfen der fachlichen Durchführbarkeit Prüfen alternativer Lösungsvorschläge Prüfen der personellen Durchführbarkeit Prüfen der Risiken Prüfen der ökonomischen Durchführbarkeit Aufwands- und Terminschätzung Wirtschaftlichkeitsrechnung. V2-7 V2-8 Ergebnis der Phase Machbarkeitsstudie (Engl. feasibility study) (1) Lastenheft (grobes Pflichtenheft) Grobe Liste der Anforderungen (2) Aufwandsschätzung (Kalkulation) Technische Abschätzung des Aufwandes (3) Projektplan (siehe Kap. III.2) Ablauf und Ressourcenverbrauch (1) Lastenheft Das Lastenheft enthält eine Zusammenfassung aller fachlichen Basisanforderungen, die das zu entwickelnde Software-Produkt aus Sicht des Auftraggebers erfüllen muss. beschreibt die wesentlichen Anforderungen des Produkts aus fachlicher Sicht (Anwendungsgebiet) beschreibt insbesondere die wesentlichen Funktionen und Daten liefert die Grundlage für die Aufwandsschätzung und die Erstellung des Projektplanes. Umfang: wenige Seiten V2-9 V2-10 Lastenheft Die wesentlichen Funktionen werden durch die Use Cases definiert (o. alle Details): Klassisch: Wie interagiert der Nutzer mit dem Produkt (Anwendungsszenarien) Manchmal auch: Wie interagieren die verschiedenen Komponenten? (z.b. im SOPRA) Das Lastenheft entspricht einem groben Pflichtenheft und kann später zu diesem verfeinert werden. V2-11 Lastenheft: Gliederung Deckblatt: Projekt, Auftraggeber, Auftragnehmer Produkteinsatz Einsatzbereich des zu entwickelnden Systems klarzustellen Beschreibung des Problembereichs Glossar Modell des Problembereichs Beschreibung der Geschäftsprozesse nur durch Text P d ktf kti V2-12 2

3 (2) Aufwandsschätzung [Balzert1996] Sicht des Software-Herstellers bzw. des Auftragnehmers bzgl. Kosten eines Software- Systems: Entwicklungskosten sind hauptsächlich Personalkosten Anteilige Umlegung der CASE-Umgebungskosten (einschl. Hardware und Systemsoftware) für die Produktentwicklung Kosten für andere Dienstleistungen, Büromaterial, Druckkosten, Dokumentation, Reisekosten usw. sind im Verhältnis zu den Personalkosten bedeutungslos. Grundlage der Aufwandsschätzung Auf der Basis des Lastenheftes, insbesondere der Produktfunktionen und der Produktdaten läßt sich der Aufwand schätzen Tatsächlich wird dazu meist die Größe des resultierenden Softwareprodukts geschätzt Wir haben: Grundlegende Schätzmethoden Konkreten Schätzverfahren V2-13 V2-14 Grundlegende Schätzmethoden Analogiemethode Schätzung aufgrund der Ähnlichkeit des geplanten Produkts mit einem Produkt das bereits früher erstellt wurde und für das der Aufwand bekannt ist Grundlegende Schätzmethoden Relationsmethode Anpassung der Analogiemethode durch Umrechnungsfaktoren (Programmiersprache, Entwicklungs-methode) gemäß bestimmter Richtlinen Bewertung: - viel Erfahrung nötig - Mangel an vergleichbaren Projekten - Ähnlichkeit ist subjektiv Bewertung: - Erfahrung nötig - Immer noch schwierig: Mangel an vergleichbaren Projekten V2-15 V2-16 Grundlegende Schätzmethoden Grundlegende Schätzmethoden Multiplikationsmethode Zerlegung des Produkts in Teilprodukte Bewertung anhand vergleichbarer Teilprodukte Bewertung: + vergleichbare Teilprodukte sind eher vorhanden - Bewertung noch nicht in der Planungsphase (Teilprodukte werden frühestens im Pflichtenheft definiert) Gewichtungsmethode Die Produktfunktionen werden kategorisiert und gemäß Komplexität klassifiziert. Aus der Anzahl der jeweiligen Funktionen wird gemäß einer festen Rechenvorschrift ein Wert berechnet. Dieser Wert wird über eine Tabelle (der gesammelten Erfahrungswerte) in den Aufwand übersetzt. (Bsp. siehe später Function-Point-Methode) Bewertung: + Schätzung in der Planungsphase + keine vergleichbaren Projekte nötig + über die Anpassung der Tabelle anpaßbar an die eigene Firmenkultur und - methodik + verfeinerte Schätzung bei verfeinerten Anforderungen möglich + Kochrezept das (relativ) wenig Erfahrung erfordert V2-17 V2-18 3

4 Grundlegende Schätzmethoden Prozentsatzmethode Der Aufwand einer Phase wird auf das Gesamtprojekt hochgerechnet (Hypothese: Der prozentuale Anteil jeder Phase ist immer gleich) Bem.: Geht beim Erstellen des Projektplanes auch umgekehrt Grundlegende Schätzmethoden Expertenmethode Mehrere Experten schätzen unabhängig voneinander den Aufwand für jede Funktion Dann vergleichen und diskutieren sie die Resultate Danach gibt jeder Experte nochmals eine Schätzung ab (ggf. wird iteriert). Am Ende werden die Schätzungen gemittelt. Bewertung: + sehr einfach - Bewertung erst in späteren Phasen möglich Bewertung: - Experten erforderlich + relativ genaue Schätzung V2-19 V2-20 Schätzverfahren Es gibt viele verschiedene konkrete Verfahren (und weitere Basismethoden) Die konkreten Schätzverfahren kombinieren verschiedenen dieser Methoden, um deren Nachteile auszumerzen und das Schätzergebnis zu verbessern Auch das ausgeklügelste Verfahren kann die Erfahrung nicht ersetzen Beispiel: Function-Point-Methode (1/6) 1. Kategorisierung jeder Anforderung 2. Klassifizierung jeder Anforderung 3. Gewichtete Aufsummierung der FPs 4. Bewertung der Einflussfaktoren 5. Berechnung der bewerteten FPs 6. Ableitung des Aufwands aus früher gewonnenen Aufwandskurve 7. Bestimmung des tatsächlichen Aufwands und Aktualisierung der Aufwandskurve [Balzert1996] V2-21 V2-22 Beispiel: Function-Point-Methode (2/6) 1. Kategorisierung jeder Anforderung Mögliche Kategorien Eingabedaten Abfragen Ausgaben Datenbestand (fachlich) Referenzdaten (fachlich) Bemerkung: Die Funktion-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter läßt sich aber auf andersartige Systeme übertragen. Beispiel: Function-Point-Methode (3/6) 2. Klassifizierung jeder Anforderung Mögliche Klassifizierung (der Komplexität): einfach mittel komplex 3. Gewichtete Aufsummierung der FPs Die Anzahl in jeder Kategorie und Klasse wird mit einem bestimmten Faktor gewichtet und aufsummiert. V2-23 V2-24 4

5 Beispiel: Function-Point-Methode (4/6) 4. Bewertung der Einflussfaktoren Berücksichtigung von Einflussfaktoren wie Verflechtung mit anderen Systemen Verteiltheit der Daten Wiederverwendung Anpaßbarkeit Die Einflußfaktoren modifizieren die Bewertung um max. +/- 30%. Das Ergebnis ist die Function-Point-Bewertung. Beispiel: Function-Point-Methode (5/6) 5. Ableitung des Aufwands aus früher gewonnenen Aufwandskurve (mit bisherigen Erfahrungswerten des Unternehmens) Aufwand Ermittelte FPs FPs V2-25 V2-26 Beispiel: Function-Point-Methode (6/6) 6. Bestimmung des tatsächlichen Aufwands und Aktualisierung der Aufwandskurve Aufwand tatsächlicher Aufwand Abschlussbemerkungen Alle Schätzverfahren erfordern: Viel Erfahrung Aufwandsdaten aus vorangegangenen Softwareprojekten: in ähnlichem Anwendungsgebiet mit ähnlichen Entwicklungsmethoden mit ähnlicher Firmenkultur Ermittelte FPs FPs Bemerkung: sonst stimmt die Hypothese mit der konstanten Produktivität nicht (die fast allen Verfahren zugrunde liegt) V2-27 V2-28 II.3 Anforderungsdefinition Ziel: Festlegung aller Anforderungen an das Produkt (qualitativ und quantitativ). Basis für Analyse und Entwurf Einordnung: Wasserfallmodell Machbarkeitsstudie Anforderungsdefinition Analyse Wichtig: Ist normalerweise die Vertragsgrundlage Bildet die Basis für die Abnahme am Ende des Projekts Entwurf Implementierung & Test Wartung V2-29 V2-30 5

6 Rolle: Systemanalytiker Aufgaben des Systemanalytikers Interaktion mit Auftraggeber / Marketingabteilung Endnutzern / Fachabteilungen Vorgehen/Methoden: Zuhören (Lesen / Reverse-Engineering), Nachfragen, Formulieren (sprachlich oder graphisch), Modellieren (formal z.b. UML), Simulieren / Animieren und ggf. Revidieren die richtigen Fragen stellen und zuhören sicherstellen, daß Antworten richtig verstanden wurden Probleme bewußt machen und formulieren Sachverhalte auf den Punkt bringen Unklarheiten aufdecken und ansprechen zwischen den Zeilen lesen alles im Blick behalten auf den Gesprächspartner einstellen Abstrahieren (Wichtiges von Unwichtigem trennen) Kurz: Unsystematische unzusammenhängende Angaben systematisieren und abstrahieren V2-31 V2-32 Daumenregel für Systemanalytiker Dokumente Ausreden wie Der Benutzer bzw. Auftraggeber hat mir das nicht genau genug erzählt! Dazu hat mir der Benutzer bzw. Auftraggeber nie etwas gesagt! Woher soll ich denn wissen, daß der Benutzer was ganz anderes im Kopf hatte!... gelten für einen Systemanalytiker nicht! (1) Produktmodell (aus Anwendersicht) (2) Konzept für Benutzungsoberfläche (3) Benuzungshandbuch (4) Abnahmetests (5) Pflichtenheft (enthält oft teilw. die anderen Dokumente) V2-33 V2-34 (3) Benutzerhandbuch (5) Pflichtenheft stellt das Produkt aus der Sicht des und für den Benutzer dar hilft, das gemeinsame Verständnis vom Produkt zu sichern hilft, die Vollständigkeit aus Sicht des Benutzers zu sichern Zusammenhängende Darstellung aller fachlichen Anforderungen an das Produkt (Sicht des Benutzers). Es sollte beschrieben, was das Produkt leisten sollte, nicht wie es das leistet hilft, Abnahmetest zu formulieren V2-35 V2-36 6

7 Pflichtenheft: Gliederung (1/3) Deckblatt Projekt Auftraggeber Auftragnehmer Zielbestimmung Überblick und Einbettung in den Kontext Was soll mit dem Produkt erreicht werden. Was soll mit dem Produkt erreicht werden Obligatorisch Optional Abgrenzung (Was muß das Produkt nicht leisten) Pflichtenheft: Gliederung (2/3) Produkteinsatz Beschreibung des Problembereichs Aufgabe dieses Abschnittes ist es, den Laien mit der Terminologie und den Zusammenhängen im Problembereich vertraut zu machen. Glossar Zusammenfassung der wichtigsten Begriffe und ihre Definition So wenig wie möglich, so viel wie nötig einheitliche Terminologie Modell des Problembereichs Beschreibung der Geschäftsprozesse Reverse Engineering (Ist-Zustand) Nur bei Änderungen existierender Systeme benötigt Architektur und die Schnittstellen des Systems V2-37 V2-38 Pflichtenheft: Gliederung (3/3) Produktcharakteristiken Eigenschaften, die nicht direkt die zu leistende Funktionalität betreffen Systemumgebung Hardwareumgebung Softwareumgebung Nicht-funktionale Anforderungen Qualität der Anforderungsdefinition Die Beschreibung der Anforderungen sollten u. a. die folgenden Eigenschaften erfüllen: Vollständigkeit (keine Anforderung vergessen) Konsistenz (keine widersprüchlichen Anforderungen) Eindeutigkeit (nicht verschieden interpretierbar) Realisierbarkeit (mit vertretbarem Aufwand technisch machbar) V2-39 V2-40 II.4 Analyse Ziele: Geeignete Architektur ermitteln Benötigtes Verhalten verstehen (Szenarien) Daten und benötigter Datenaustausch identifizieren Schritte: Architektur bestimmen Wesentliche Interaktionen identifizieren Wesentliche Schnittstellen und Schnittstellenklassen festlegen Analysedokument: Gliederung Deckblatt Projekt, Auftraggeber, Auftragnehmer Architektur Dieser Abschnitt beschreibt die Architektur der zu entwickelnden Anwendung mittels Paketen und Analyseklassen. Interaktion Die Interaktion zwischen den Analyseklassen der Architektur während der Ausführung eines Use Case wird durch Sequenzdiagramme aus Instanzen der Analyseklassen beschrieben. Klassendiagramme Alle eingeführten Analyseklassen und alle als Parameter der in den Schnittstellen deklarierten Operationen erforderlichen Klassen werden in dem folgenden Klassendiagramm beschrieben. V2-41 V2-42 7

8 II.5 Diskussion & Zusammenfassung (1/2) Unter Reverse-Engineering versteht man den Prozess, die einem fertigen (und meist schlecht dokumentierten) Softwaresystem zugrundeliegenden Ideen und Konzepte aufzuspüren und zu dokumentieren (dabei wird der Entwicklungsprozess gewissermaßen rückwärts durchlaufen). Die Machbarkeitsstudie führt zur Auswahl des Produktes, dessen Voruntersuchung sowie einer technischen, organisatorischen und ökonomischen Durchführbarkeitsuntersuchung. stop or go Die Machbarkeitsstudie umfasst ein Lastenheft, eine Aufwandsschätzung sowie einen Projektplan. Diskussion & Zusammenfassung (2/2) Die Anforderungsdefinition legt aller Anforderungen an das Produkt (qualitativ und quantitativ) fest und ist die Basis für Analyse und Entwurf. Das während der Anforderungsdefinition entwickelte Pflichtenheft ist die Vertragsgrundlage mit dem Kunden und ist Basis für die Abnahme am Ende des Projekts. Die Analyse führt zur Identifikation einer geeigneten Architektur, des benötigten Verhaltens und der Analyseklassen. V2-43 V2-44 II.6 Literaturverzeichnis [Balzert1996] Helmut Balzert: Lehrbuch der Software-Technik: Software- Entwicklung. Spektrum Akademischer Verlag Helmut Balzert: Lehrbuch der Software-Technik: Software- Management, Software- Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Softwaretechnikpraktikum: III Software-Management Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de V2-45 Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software-Management IV Software-Qualitätssicherung V Zusammenfassung III Software-Management III.1 Grundlagen III.2 Planung III.3 Organisation III.4 Personal/Leitung III.5 Kontrolle III.6 Diskussion & Zusammenfassung III.7 Literaturhinweise V2-47 V2-48 8

9 III.1 Grundlagen Software Management umfasst alle Aktivitäten und Aufgaben, die von einem oder mehreren Managern durchgeführt werden, um die Aktivitäten von Mitarbeitern zu planen und zu kontrollieren damit ein Ziel oder der Abschluss einer Aktivität erreicht wird, die durch die Mitarbeiter alleine nicht erreicht werden können Dies umfasst Aufgaben wie Planung, Organisation, Leitung und Überwachung Kurzform: Das Management sorgt dafür, dass gewählte Ziele durch Mitarbeiter erreicht werden. Gewinn & Produktivität Primäres Ziel ist es Gewinn zu machen und diesen auch noch zu maximieren Maximales Ergebnis Bei minimalem Aufwand Ergebnis Produktivität = Aufwand Fragen: (1) Welche Faktoren beeinflussen die Produktivität? (2) Wie misst man Produktivität? (3) Wie steigert man die Produktivität? V2-49 V2-50 (1) Welche Faktoren beeinflussen die Produktivität? Externe Einflüsse Qualität Wert Quantität Produktivität Zeit Kosten Komplexität Schwierigkeitsgrad Personalaufwand Randbedingungen Weitere Einflussfaktoren Produkt Anwendungsgebiet Techniken Prozesse, Methoden, Werkzeuge Wiederverwendung Mitarbeiter Ausbildung & Erfahrung (Anwendungsgebiet oder Methodik) Individuelle Produktivität (schlechtester : bester = 1 : 10; durchschnitt : bester = 1 : 2,5) Management Arbeitsplatz (Einzelzimmer, Telefon (andere Störungen) Teamgröße (je größer desto schlechter) Firmenkultur Qualifikation / Fortbildung Motivation V2-51 V2-52 Einflussfaktoren der Aufwandsschätzung Qualität + Produktivität Quantität Einflußfaktoren Quantität Qualität Entwicklungsdauer Kosten Produktivität ist normalerweise immer eine gleichbleibende Fläche (2) Wie misst man das Ergebnis? Antworten: Marktwert des Produktes Erzielbarer Umsatz bzw. Gewinn Aber: Schwer meßbar und noch schwerer prognostizierbar Kein inhärentes Maß des Produkts (z.b. Marktlage) nicht Informatik Bewertung durch Marketing/Vertrieb Entwicklungsdauer Kosten Das Teufelsquadrat [Balzert1996] V2-53 V2-54 9

10 Pragmatische Lösung Wert: Man misst nur die Quantität nicht den Wert Qualität wird durch extra Maßnahmen gewährleistet (siehe später Kapitel IV) Quantität : Meist wird das Ergebnis durch die Anzahl der Programmzeilen der resultierenden Software quantifiziert: LOC = lines of code (Sourcecode ohne Kommentare) LOC: Bewertung - abhängig von der Programmiersprache (aber es gibt Umrechnungsfaktoren) - abhängig vom Programmierer - ignoriert andere Dokumente (die sind aber oft proportional zu LOC) - Qualität des Codes wird nicht bewertet + einfach meßbar + relativ gutes Maß für das Ergebnis V2-55 V2-56 Wie misst man den Aufwand? Summe aller entstandenen Kosten! Beobachtungen: Personalkosten sind der Hauptanteil dieser Kosten Andere Kosten sind i.w. proportional zu den Personalkosten Deshalb: Der Aufwand wird meist durch die gesamte investierte Arbeitszeit an der resultierenden Software quantifiziert (MM = Mitarbeitermonate, PJ = Personenjahre) Produktivität (pragmatisch) Beobachtungen: Wert ist kein inhärentes Maß des Produkts, so dass es zweckmäßiger ist nur die Quantität zu messen Personalkosten sind der Hauptanteil der Entwicklungskosten und andere Kosten sind i.w. zu diesen proportional LOC Produktivität MM _ V2-57 V2-58 (3) Wie steigert man die Produktivität? Typische Maßnahmen zur Steigerung der Produktivität durch das Softwaremanagement sind: Verbesserte Methoden einsetzen Abläufe (Prozesse) verbessern Wiederverwendung Einsatz von CASE-Tools Wir können dabei unterscheiden zwischen kurzfristigen Maßnahmen, die innerhalb eines Projekts oder einer Phase wirken, und langfristigen Maßnahmen, die über mehrere Projekte hinweg wirken. Produktivität & Maßnahmen Produktivität Langfristige Maßnahme Beispiele für Maßnahmen: Einsatz von CASE-Tools Neue SE-Methode Wiederverwendung Beobachtung: Kurzfristige Maßnamen führen oft zu langfristigem Produktivitätsverlust Langfristige Maßnahmen führen oft zu kurzfristigem Produktivitätsverlust Zeit V2-59 V

11 Management Aktivitäten III.2 Planung Zeitplanung Personalplanung Kostenplanung III.3 Organisation Aufgaben festlegen organisatorische Strukturen definieren Verantwortlichkeiten festlegen III.4 Personal/Leitung Personalmanagement Mitarbeiter führen und motivieren Kommunikation fördern Konflikte lösen III.5 Kontrolle Versions- und Konfigurationsverwaltung Zeiterfassung / Fehlererfassung / Fortschritte kontrollieren (Metriken) Probleme (frühzeitig) identifizieren Abhilfemaßnahmen einleiten III.2 Planung Planung bedeutet im voraus zu entscheiden, was zu tun ist, wie es zu tun ist, wann es zu tun ist und wer es zu tun hat (frei nach in Anlehnung an /Koontz, O Donnell 72/) Planung ist keine einmalige Angelegenheit, sondern sie muss sich dynamisch und flexibel anpassen, wenn sich die Umgebung oder die Entwicklung ändert Jede erfolgreiche Software-Entwicklung beginnt mit einem guten Plan Zukünftige Unsicherheiten und Änderungen, sowohl innerhalb der Entwicklungsumgebung als auch von externer Quelle, erfordern eine sorgfältige Planung, um die Risiken zu reduzieren. V2-61 V2-62 Prozessmodell z.b. Wasserfallmodell Prozessmodelle sind die destillieren Projektpläne erfolgreicher Softwareprojekte Sie sind stark idealisiert und abstrahieren von Details Gerade darin liegt die Stärke von Prozessmodellen Machbarkeitsstudie Anforderungsdefinition Analyse Entwurf Ein Projektplan verfeinert, konkretisiert, ergänzt und modifiziert ein gewähltes Prozeßmodell Das Wasserfallmodell ist ein extrem idealisiertes Modell! Implementierung & Test Wartung V2-63 V2-64 V-Modell (Vereinfachte Version) Systemtest Abnahme Weitere Prozessmodelle Prototypenmodelle Evolutionäre bzw. inkrementelles Modelle Spiralmodell Anforderungsdefinition Grobentwurf Feinentwurf Modulimplement. Modultest Integrationstest Idee: Schrittweise Entwicklung des Produkts Frühzeitige Prototypen (lauffähige Meilensteine) Softwarepflege ist Teil der Entwicklung V2-65 V

12 Prozessmodell Projektplan eine Phase in weitere Vorgänge aufteilen In einem Projektplan werden die Vorgänge weiter konkretisiert (u. evtl. weiter verfeinert): Beginn / Ende Zuweisung von Personen zu Rollen Aufwand für die beteiligten Personen in ihren Rollen Bearbeitungsdauer Meilensteine Zur Kontrolle des Projektfortschritts werden im Projektplan Meilensteine definiert Ein Meilenstein ist eine Menge von Dokumenten in einem bestimmten Zustand, die zu einem bestimmten Zeitpunkt vorliegen müssen typischerweise sind es die Dokumente, die am Ende einer Phase oder eines Vorgangs vorliegen kennzeichnen den Beginn und das Ende eines Projekts den Abschluss jeder Phase den Abschluss einer Gruppe von Vorgängen innerhalb einer Phase V2-67 V2-68 Kriterien für Meilensteine Überprüfbarkeit Es ist überprüfbar, ob der Meilenstein erreicht ist (nicht: Dokument ist zu 75% fertig) Überschaubarkeit Die Dokumente können in überschaubarer Zeit erstellt werden (Wochen oder Monat, nicht Jahr) Regelmäßigkeit Die Meilensteine treten in regelmäßigen Abständen auf Projektpläne Es gibt verschiedene Notationen: Gantt-Diagramm Auswertungen von Netzplänen in Form von Balkendiagrammen Vorgangsbezogenes bzw. aufgabenbezogenes Gantt-Diagramm Vorgänge auf der Vertikalen und Personen/Stellen auf dem Balken Personalbezogenes Gantt-Diagramm Mitarbeiter auf der Vertikalen. Netzplantechnik (z.b. meta potential method (MPM)) Vorgänge als Knoten Verbindungspfeile symbolisieren Abhängigkeiten Meilensteine als Vorgänge mit der Dauer 0 V2-69 V2-70 Eigenschaften von Vorgänge Zeiten für einen Vorgang Vorgangsdauer = Arbeitszeit, die ein Vorgang prinzipiell erfordert Arbeitsdauer = Zeit, die eine Ressource dafür aufwendet Gesamtzeitraum = Kalenderzeit, die für den Vorgang benötigt wird Termintypen für einen Vorgang/Meilenstein Geplante Termine Legen fest, wann ein Vorgang beginnen und enden muß Tatsächliche Termine Errechneter oder tatsächlicher Start- oder Endtermin Späteste Termine Spätester Zeitpunkt, an dem ein Vorgang beginnen darf, ohne das Projektende zu verzögern. Beziehungen zwischen Vorgängen Vorgangsbeziehungen Legen die Reihenfolge von Vorgängen fest Normalfolge: Ende-Anfang (EA) Anfangsfolge: Anfang-Anfang (AA) Endfolge: Ende-Ende (EE) Sprungfolge: Anfang-Ende (AE). Zusätzlich kann eine positive/negative Wartezeit angegeben werden V2-71 V

13 Netzplantechnik Gantt-Diagramm Meilenstein Review des Lastenheftes 2. Version Lastenheftes t 3t 1. Version Lastenheftes t EE+3t Aufwandschätzung Machbarkeitsstudie t Analysemodell t 5.10 Legende: t 6.10 Name Frühster Anfang Frühstes Ende Dauer Notizen V2-73 V2-74 Termindurchrechnung Puffer und Kritischer Pfad Zeitliche Anordnung der Vorgänge unter Berücksichtigung der gegenseitigen Abhängigkeiten Vorwärtsrechnung Bestimmen der frühesten Termine Anfangszeitpunkt + Dauer = frühestes Ende Rückwärtsrechnung Bestimmen der spätesten Termine Endzeitpunkt - Dauer = spätester Anfang Ein Netzplan ist zeitkonsistent, wenn keine negativen Puffer auftreten. V2-75 V2-76 Einsatzmittelplanung Erweiterung um Ressourcen Einsatzmittel dienen zur Durchführung der Vorgänge Personal, Betriebsmittel (Maschinen, Materialien), Geldmittel Ressourcen = Personal und Betriebsmitteln Einsatzmittelplanung Bedarf an Einsatzmitteln vorhersagen Einsatzoptimierung durch Aufzeigen von Engpässen und Leerläufen. Einsatzplanung des Personals Personalplanung Termintreue Einsatzplanung Welche Personalkapazität bei festen Terminen nötig? Kapazitätstreue Einsatzplanung Welcher frühester Endtermin bei feststehendem Personal?. Einsatzplanung des Personals: 1 Ermitteln des Personalvorrats 2 Errechnen des Personalbedarfs 3 Vergleich von Bedarf und Vorrat 4 Optimierung der Auslastung. V2-77 V

14 Gantt-Diagramm mit Ressourcen Ressourcentabelle V2-79 V2-80 Kostenplanung Zusammenfassung Kostenplanung stützt sich auf Daten der technischen Planung kaufmännischen Planung Gemeinkosten (indirekte Kosten) Mietkosten Kosten der Verwaltung Ressourcenkosten Hängen mit Ressource zusammen Beispiel: Stundensatz des Mitarbeiters Summieren sich über den Zeitraum, den die Ressource für die Arbeit an einem Vorgang aufbringt. Prozessmodell auswählen und Projektplan ableiten (mit Meilensteine) Aufwandsschätzung durchführen und Bedarfsüberlegungen anstellen Netzplan Vorgangsdauer = Aufwand / Bedarf Netzplan durchrechnen Terminbeschleunigung prüfen Risiko minimieren Vorgangsbezogenes Gantt-Diagramm Ressourcen schätzen und zuordnen Ressourcenauslastung überprüfen Bedarfsoptimierung vornehmen Kosten zuordnen V2-81 V2-82 Softwaretechnikpraktikum: Informationen, Aufgaben für die nächste Woche und Fragerunde Org: Werkzeuge für das SOPRA UML Werkzeuge: Fujaba, IBM Rational Rose, Together Architect und Designer, Poseidon for UML, Omondo EclispeUML Studio, Entwicklungsumgebungen: Eclipse, Emacs, XEmacs, Homepage JBuilder, NetBeans, Werkzeuge für den Projektplan MS Project (siehe nächste Folie) (von den Webseiten des SOPRA) V

15 Org: MS Projekt Lizenzen Zugang zu MS Projekt: Alle Teilnehmer, die noch nicht im Programm der Microsoft Academic Alliance (MSAA) sind und MS Projekt nutzen möchten, schicken den vollständigen Uni- -Account an ihren Projektleiter. Der Projektleiter erstellt eine Textdatei, die pro Zeile genau einen der Uni- -Account enthält. Der Projektleiter schickt die Liste per mit dem Betreff SWT Pra 05 MSAA Gruppe <zweistellige Gruppennummer> als Attachment bis zum an Binnen weniger Tage werden alle Interessierten per von Microsoft informiert und können sich das Werkzeug dann runterladen. Org: CVS (letzte Warnung!) Machen Sie sich mit CVS vertraut: Einrichtung eines Logins unter GForge: 1. Die Seite aufrufen New Account rechts oben auf der Seite aufrufen und Loginname und Loginpasswort sowie Name und -Adresse eintragen. 2. Loginname an euren Gruppenbetreuer schicken ( -Adresse des Gruppenbetreuers ist auf der Homepage bei der Gruppenübersicht angegeben) [Der Gruppenbetreuer trägt die Teilnehmer in zugehöriges Projekt ein] Deadline war: Fr. den 22. April 12:00 Uhr!!! Konsequenz: Solange nicht alle angemeldet sind, können wie die verteiler nicht einrichten! Letzte Deadline: Mo. den 25. April 10:00 Uhr!!! (ansonsten kann man nicht am Praktikum teilnehmen; im Notfall Mo Uhr im E3.343 erscheinen) Hilfe zu MS Projekt: V2-85 V2-86 Aufgabe: Aufwandsschätzung Alle Schätzverfahren erfordern Viel Erfahrung Aufwandsdaten aus vorherigen Softwareprojekten (Basis für die Hypothese der konstanten Produktivität) Im Praktikum wird deshalb Die Aufwandsschätzung nicht bewertet! Am Ende das Schätzergebnis mit dem tatsächlichen Umfang bzw. Aufwand nur vergleichen Stundenzettel Zählen der LOC (CVS) The Kassel Challenge Software Engineering I (Kassel): Semesterbegleitende Projektarbeit (8er Gruppen) in Kooperation mit der Universität t Paderborn /se/index.php?sei Die Kasseler werden mit ca. 10 Gruppen am Turnier teilnehmen! V2-87 V2-88 Fragen? V