Kapitel 2 Softwareentwicklung

Transkript

1 Inhalt 1 Einleitung Kapitel 2 Softwareentwicklung 2 Vorgehensmodelle 3 Hilfsmittel zur Projektplanung 36 Wolf Zimmermann 38 Wolf Zimmermann Literatur VDI-Norm 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte, VDI-Handbuch Konstruktion, Beuth-Verlag, 1993 Das V-Modell. Der Standard in der Softwareentwicklung mit Praxisleitfaden. Hrsg. A.-P. Bröhl und W. Dröschel. Oldenbourg-Verlag, Einleitung 1 Ziele 2 Anforderungen an Softwareentwicklungsmethoden 3 Programmieren im kleinen vs. Programmieren im großen 4 Organisation der Softwareentwicklung 5 Probleme bei der Softwareentwicklung 6 Die ISO-9000 Norm 37 Wolf Zimmermann 39 Wolf Zimmermann

2 2.1.1Ziele Systematische Strukturierung von Entwicklungsprozessen Technische Unterstützung der Managementprozesse Qualitätssicherung, Wartung/Pflege einbeziehen Programmieren im Großen Komplexität der Aufgabe Im Detail nicht überschaubar für eine Person Qualitätssicherung auf allen Managementebenen Ariane-5 Fehler Entwicklerteams Problemzerlegung, Dokumentation Lebensdauer Notwendigkeit der Organisation des Softwareentwicklungsprozesses 40 Wolf Zimmermann 42 Wolf Zimmermann Anforderungen an Softwareentwicklungsmethoden Anwendbar auf große und kleine Probleme Heterogenität der Entwicklungsmannschaft: unterschiedliche Vorbildung und Erfahrung Informatiker Anwendungsspezialist angelernte Mitarbeiter Produktstruktur vs. Organisationsstruktur Risikoabschätzung Transparenz des Prozesses auf verschiedenen Managementebenen Kontrolle des Kommunikationsaufwands Organisation der Softwareentwicklung Reihenfolge des Arbeitsablaufs Durchzuführende Aktivitäten Definition der Teilprodukte einschließlich Form und Inhalt Fertigstellungskriterien Notwendige Mitarbeiterqualifikationen Verantwortlichkeiten und Kompentenzen Standards, Richtlinien, Methoden und Werkzeuge 41 Wolf Zimmermann 43 Wolf Zimmermann

3 Phasen des Problemlösens Klären und Präzisieren der Aufgabenstellung Anforderungsliste Ermitteln von Funktionen und Strukturen Funktionale Strukturen Lösungsprinzipien Zerlegung in realisierbare Module Modulare Systemstruktur Gestaltung (engl. Design) der Module Vorentwurf Gestaltung des Produkts Gesamtentwurf Aufbereitung der Ausführungs- und Nutzungsangaben Produktdokumentation Ziele: Die ISO-9000 Norm Qualitätskontrolle des Produktes Qualitätskontrolle des Herstellungsprozesses auch für Zulieferer von Teilprodukten Auftraggeber-Lieferanten Verhältnis: wird festgelegt Allgemeiner übergeordneter, organisatorischer Rahmen zur Qualitätssicherung materieller und immaterieller Produkte Keine Festlegung der spezifischen Qualitätssicherungsmaßnahmen 44 Wolf Zimmermann 46 Wolf Zimmermann Probleme bei der Softwareentwicklung Produkt- vs. Organisationsstruktur Mangelnde Erfahrung in Teamarbeit Abwehrhaltung gegenüber bürokratischen Formalien Schönrednerei statt Ehrlichkeiten Vernetzung und gegenseitige Abhängigkeit der Teilaufgaben Zusammenarbeit über Grenzen von Abteilungen/Standorten/Firmen Notwendigkeit von Zeit- und Organisationsplanung Struktur der ISO-9000 Norm ISO Allgemeine Einführung, Leitfaden zur Auswahl und Anwendung ISO Allgemeiner Leitfaden zur Anwendung von 9001, 9002 und 9003 ISO Leitfaden zur Anwendung von 9001 auf Software ISO Leitfaden zum Management von Zuverlässigkeitsprogrammen ISO 9001 beschreibt Modelle zur Qualitätssicherung in allen Phasen ISO 9002 definiert Modelle zur Qualitätssicherung in Produktion und Installation ISO 9003 Qualitätssicherung in Endprüfung ISO 9004 Erläuterung der Qualitätssicherungselemente 45 Wolf Zimmermann 47 Wolf Zimmermann

4 Anwendung der ISO 9000 Norm Verbesserung bzw. Aufbau von Qualitätsmanagement (intern) Darlegung gegenüber Dritten Systemzertifizierung nach ISO 9001 Audit durch unabhängige Zertifizierungsstelle (nach DIN EN ) jährliche Überwachungsaudits nach drei Jahren: Wiederholungsaudit Vertrag Auftraggeber-Lieferant Spezifikation Entwicklungsplan Dokumente nach ISO Qualitätssicherungsplan Qualitätsaufzeichnungen Festlegung von Regeln, Praktiken Nutzung von Werkzeugen Unterauftragsmanagement: Validierung von beschafften Produkten Testplan Wartungsplan Konfigurationsmanagementplan 48 Wolf Zimmermann 50 Wolf Zimmermann Maßnahmen nach ISO Einmalige Maßnahmen: Geschäftsleitung Verpflichtung zur Qualitätspolitik Beauftragter zur Überwachung der Einhaltung der Norm regelmäßige Überprüfung Mitarbeiter Festlegung der Verantwortlichkeiten und Kompetenzen Beauftragte für Qualitätskontrolle (unabhängig von Entwickler) Einrichtung, Aufrechterhaltung und Dokumentation von Qualitätsmanagement Integration in gesamten Lebenszyklus Maßnahmen pro Projekt: Softwareentwicklung in Phasen Festlegung der Vorgaben für jede Phase Festlegung der zu erzielende Ergebnisse für jede Phase Festlegung des Verifizierungsverfahrens für jede Phase keine Festlegung auf bestimmtes Verfahren Diskussion Vorteile: Aufmerksamkeit und Bewusstsein für Qualitätssicherung Zwang zur Beibehaltung der Qualitätssicherung Festlegung der Anforderungen, Freiheit bei deren Realisierung Erleichtert Aquisitation von Aufträgen Geeignet für Werbung Reduktion des Produkthaftungsrisikos Nachteile: Unsystematischer Aufbau Keine saubere Trennung zwischen Fach-, Management- und Qualitätssicherungsaufgaben Software-Bürokratie Einsatz von nicht vorhandenen CASE-Werkzeugen Noch keine standardisierten Verfahrensabläufe und Dokumente Qualifikation der Auditoren Mittlerer Bildungsabschluss mit spezieller Schulung genügt Schlechte Übersetzung deutscher Fassung 49 Wolf Zimmermann 51 Wolf Zimmermann

5 1 Einleitung 2.2 Vorgehensmodelle Vorgehen: Programmieren durch Probieren 2 Programmieren durch Probieren 3 Wasserfallmodell 4 V-Modell 5 Prototypenmodell 6 Versionsmodell (auch evolutionäres/inkrementelles Modell) 7 Transformationsmodell 8 Objekt-orientiertes Prozessmodell 9 Nebenläufiges Modell 10 Spiralmodell 52 Wolf Zimmermann 54 Wolf Zimmermann Ein Prozessmodell definiert Reihenfolge des Arbeitsablaufs Durchzuführende Aktivitäten Einleitung Teilprodukte einschließlich Form und Inhalt Fertigstellungskriterien Notwendige Mitarbeiterqualifikationene Verantwortlichkeiten und Kompentenzen Standards, Richtlinien, Methoden und Werkzeuge Programmieren durch Probieren Vorgehen: 1 Schreibe Programm 2 Finde und behebe Fehler im Programm Vorteile: Schnell (?) Nachteile: Gefahr von Spaghetti- und Ravioli-Code Mangelhafte Aufgabenerfüllung Teure Wartung und Pflege Keine Dokumentation Ungeeignet für Teamarbeit 53 Wolf Zimmermann 54 Wolf Zimmermann

6 Anforderungs analyse Wasserfallmodell Lastenheft, Pflichtenheft, Projektplan vorläufiges Benutzerhandbuch, Verifikationsplan Beispiel: Web-Content-Managementsystem der MLU (bearbeitet durch Dipl.-Inform. Andreas Both) 1 Zielsetzung Validierung Entwurf Validierung Implementierung Validierung Systemarchitektur,Benutzer handbuch, Verifikationsplan Validierung Module, Testdaten Dokumentation Betrieb und Wartung Revalidierung funktionsfähiges System, Rückblick 55 Wolf Zimmermann Test 2 Produkteinsatz 3 Produktfunktionen 4 Produktdaten 5 Produktleistungen 6 Qualitätsanforderungen 7 Ergänzungen both/project/ 57 Wolf Zimmermann A) Lastenheft Ziel: Grobe Festlegung der Ziele und Anforderungen des Projekts Aufbau: 1 Ziel des Projekts 2 Produkteinsatz a Anwendungsbereich b Zielgruppe 3 Produktfunktionen (grobe Schilderung) 4 Produktdaten (die permanent gespeichert werden) 5 Produktleistungen (Zeit, Umfang, Genauigkeit) 6 Qualitätsanforderungen (Zuverlässigkeit, Benutzbarkeit, Effizienz, Ergonomie) 7 Ergänzungen 1. Zielsetzung 1.1 Allgemein: Es soll ein Web-Content-Management-System erstellt werden, mittels dem es den Mitarbeitern der Martin-Luther-Universität Halle-Wittenberg ermöglicht wird, Internetseiten selbstständig (ohne Zutun einer weiteren Instanz z.b. in Form eines Administrators) zu erstellen und zu pflegen. Dadurch soll eine Verringerung der Arbeitsschritte bei der Pflege von Internetseiten sowie eine Verbreiterung, Verbesserung und höhere Aktualität des Internetauftritts der Martin-Luther-Universität Halle-Wittenberg erreicht werden. 1.2 Speziell: Das Web-Content-Management-System soll auf einem Web-Server laufen und mittels einer Datenbank die Internetseiten der Martin-Luther- Universität Halle-Wittenberg verwalten. Es soll vollständig über einen Internetbrowser bedienbar sein. Für die Benutzung des Produkts sollen nur Grundkenntnisse im Umgang mit dem Computer vorausgesetzt werden und auf keinen Fall Kenntnisse in einer Programmier- oder Auszeichnungssprache. Für Mitarbeiter mit höherer Sicherheitsstufe sind Schulungen bzw. Einweisungen vorgesehen. 56 Wolf Zimmermann 58 Wolf Zimmermann

7 2. Produkteinsatz 2.1 Anwendungsbereiche: Das Produkt wird für den täglichen Gebrauch durch die Mitarbeiter der Martin-Luther-Universität Halle-Wittenberg entwickelt und dient dort der Erstellung, Pflege, Verwaltung und Ansicht von Internetseiten. 2.2 Zielgruppen: Das Produkt dient den Mitarbeitern der Martin-Luther- Universität Halle-Wittenberg zur Erstellung, Pflege und Verwaltung von Internetseiten. Diese Mitarbeiter besitzen allgemeine Grundkenntnisse in der EDV. Sie erhalten die Möglichkeit zusätzlich zu den inhaltlichen Daten noch Meta- Daten anzugeben, sowie die Seiten nach bestimmten Merkmalen zu klassifizieren und Zugangsbeschränkungen zu aktivieren. Eine Ausweitung dieser Nutzergruppe auf Studenten oder Firmenvertreter ist vorerst nicht vorgesehen. Die normalen Internetnutzern soll das Web-Content-Management-System Unterstützung bei der Suche nach Informationen helfen, bzw. durch eine History die Navigation erleichtern und fehlerhafte Links verhindern. 59 Wolf Zimmermann 3. Produktfunktionen (Fortsetzung) 3.2 für Benutzer mit Rechten zur Änderung von Seiten /LF2 10/ Einfügen von Layoutelementen /LF2 20/ Bearbeiten von Layoutelementen /LF2 30/ Löschen von Layoutelementen /LF2 40/ Erstellen einer lokalen Kopie von externen Seiten /LF2 50/ Einfügen von Formularen /LF2 60/ Bearbeiten von Formularen /LF2 70/ Löschen von Formularen /LF2 80/ Anfordern von Übersetzertätigkeit /LF2 90/ Bestätigen von Änderungen 3.3 für Benutzer mit Rechten zur Änderung Zugriffsrechten /LF3 10/ Einfügen von Rechten zur Pflege für Mitarbeiter /LF3 20/ Bearbeiten von Rechten zur Pflege für Mitarbeiter /LF3 30/ Löschen von Rechten zur Pflege für Mitarbeiter /LF3 40/ Bearbeiten von Zugriffsrechten (uni-intern,...) 3.4 für Benutzer mit Rechten zur Änderung des Bereichslayout /LF4 10/ Bearbeiten des Bereichsdesigns 3.5 für Administratoren des Web-Content-Management-System /LF5 10/ Erstellen von Bereichen /LF5 20/ Bearbeiten von Bereichen /LF5 30/ Löschen von Bereichen 61 Wolf Zimmermann 3. Produktfunktionen 3.0 allgemeine Funktionen: /LF0 10/ Korrespondenz mit anderen Systemen der Universität (z. B.: Tk-Anlage) /LF0 20/ Kontrollieren der Konsistenz der Seiten (Links, Bilder,...) /LF0 30/ Erstellen von Übersichten /LF0 40/ Kontrollieren der Aktualität der Inhalte /LF0 50/ Speichern von persönlichen Daten /LF0 60/ Speichern von Rechten /LF0 70/ Speichern von Seiteninhalten /LF0 80/ Speichern von Layoutelementen /LF0 90/ Speichern von Bereichszugehörigkeiten /LF0 100/ Speichern von Metadaten /LF0 110/ Speichern von Dokumenten in Fremdformaten /LF0 120/ Speichern von Bildern in verschiedenen Formaten /LF0 130/ Speichern von Cascading Style Sheets (css) 3.1 für normale Internetnutzer /LF1 10/ Abrufen der Seiteninhalte /LF1 20/ Abrufen der Meta-Daten /LF1 30/ Abrufen der Informationen zur Aktualität /LF1 40/ Informationen an Seitenverantwortliche schicken /LF1 50/ Druckversion abrufen /LF1 60/ Übersichten abrufen /LF1 70/ Suchabfrage stellen 60 Wolf Zimmermann 3.4 Produktdaten 4.1 Daten von Nutzer /LD1 10/ persönliche Daten (Datenschutz) /LD1 20/ Rechte 4.2 Daten von Seiten /LD2 10/ Seiteninhalte (Texte, Links, Bilder,...) /LD2 20/ Layoutelemente (Tabellen, Absätze,...) /LD2 30/ Bereichszugehörigkeit der verschiedenen Seiten /LD2 40/ beschreibende Daten (Meta-Daten) der verschiedenen Seiten (kategorisierter Seiteninhalt, Autor(en), Änderungsdatum,...) 4.3 Allgemeine Daten /LD3 10/ Dokumente in Fremdformaten (pdf, xls, doc,...) /LD3 20/ Bilder in verschiedenen Formaten (jpg, png, gif,...) /LD3 30/ Cascading Style Sheets (css) für die einzelnen Bereiche 62 Wolf Zimmermann

8 5. Produktleistungen /LL10/ Langlebigkeit und Plattformunabhängigkeit /LL20/ spezielle Benutzerrechte für die einzelnen Benutzergruppen /LL30/ es soll verschiedene Ansichten für Nutzer und Redakteure bzw. Administratoren geben /LL40/ Fernwartung via Webbrowser (siehe Anhang) /LL50/ der Benutzer soll zu jeden Zeitpunkt wissen, wo er sich befindet /LL60/ die Ausführungszeit der Skripte darf nicht wesentlich größer als die Netzwerklatenz sein /LL70/ Die Layoutelemente sollen klassifiziert sein /LL80/ Hilfestellung zu Suchmöglichkeiten und Eingabefeldern /LL90/ Unterstützung für verschiedene Sprachen /LL100/ Die erzeugte Quellcodegröße sollte 15 KB nicht übersteigen /LL110/ Ein Datenaustausch mit der Tk-Anlage sollte möglich sein /LL120/ Daten müssen über Sicherheitsmechanismen gesichert sein /LL130/ Nutzungsrechte sollen rekursiv und zeitabhängig vergeben werden können /LL140/ Der Datenschutz soll gewahrt werden /LL150/ Schlechtestenfalls müssen ca Mitarbeiter und Studenten verwaltet werden /LL160/ Die gespeicherten Daten sind synchron mit denen per HTML angezeigten Daten 63 Wolf Zimmermann 7. Ergänzungen 7.1 Server Als Plattform wird aus Gründen der Performanz, Stabilität und Kosten der ApacheÔ Webserver gewählt. Alle relevanten Daten werden in einer Datenbank gespeichert. Der Typ und Hersteller sind noch festzulegen. 7.2 Client Das Produkt soll vollständig durch einen SSL-fähigen Webbrowser bedienbar sein. Es werden keine Plugins vorausgesetzt. Folgende Browser-Versionen müssen unterstützt werden. Microsoft Internet Explorer ab Version 4.0 Netscape Navigator ab Version 4.6 Opera ab Version 5.0 Außerdem kann von einer Mindestfarbtiefe von 256 Farbe ausgegangen werden. 65 Wolf Zimmermann 6. Qualitätsanforderungen Qualität sehr gut gut normal irrelevant 6.1 Funktionalität Angemessenheit Korrektheit Interoperabilität Sicherheit 6.2 Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit 6.3 Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit 6.4 Effizienz Zeitverhalten Verbrauchsverhalten 6.5 Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit 6.6 Portabilität Anpassbarkeit Installierbarkeit Konformität Austauschbarkeit 64 Wolf Zimmermann B) Pflichtenheft (engl. requirements specification) Ziele: Definition aller Anforderungen, die das System erfüllen muss Überprüfbar z.b. durch Inspektion, Demonstration, Analyse oder Test Definition externer Schnittstellen Vertrag zwischen Auftraggeber und Auftragnehmer Juristisches Dokument Anforderungen: Korrekt Vollständig Konsistent Eindeutig Funktional ( was und nicht wie ) Verifizierbar (Spezifikation der Kundenwünsche) Verfolgbar (ableitbar und systemspezifisch) Leicht änderbar (indizierbar, Querverweise) 66 Wolf Zimmermann

9 Beispiel: Web-Content-Managementsystem der MLU (bearbeitet durch Dipl.-Inform. Andreas Both) 1 Zielbestimmung 2 Produkteinsatz 3 Nutzerklassen 4 Produktfunktionen 5 Produktdaten 6 Produktleistungen 7 Qualitätsanforderungen 8 Benutzeroberfläche 9 Entwicklungsumgebung 10 Globale Testszenarien/Testfälle 11 Ergänzungen 12 Anhänge 13 Glossar 67 Wolf Zimmermann 2. Produkteinsatz 2.1 Anwendungsbereiche: Das Produkt wird für den täglichen universitätsinternen Gebrauch durch die Mitarbeiter der Martin-Luther-Universität Halle-Wittenberg entwickelt und dient dort der Erstellung, Pflege, Verwaltung und Ansicht von Internetseiten. Diese Tätigkeiten sollen selbstständig und ohne Aufsicht eines Administrators erfolgen können. 2.2 Zielgruppen: Mitarbeiter der Martin-Luther-Universität Halle-Wittenberg mit allgemeinen Grundkenntnissen in EDV bzw. PC-Grundausbildung keine Firmenvertreter oder Studenten Normale Internetnutzer sollen durch das Web-Content-Management-System bei Suche nach Informationen unterstützt werden, Betriebsbedingungen: Software: Ein SSL-fähigen Interbrowser wird vorausgesetzt, z.b. Microsoft Internet-Explorer ab Version 4.0 Netscape Navigator ab Version 4.6 Opera ab Version 5.0 Hardware: Darstellung von 256 Farben, sonst keine besonderen Anforderungen an Anwenderhardware. Leistungsfähige Serverhardware Orgware: Verwendung von Apache ab Version PHP-Interpretierer ab Version MySQL ab Version Wolf Zimmermann 1. Zielbestimmung Durch das zu entwicklende Web-Content-Management-System sollen die Mitarbeiter der Martin- Luther-Universität Halle-Wittenberg in die Lage versetzt werden, selbstständig Internetseiten zu erstellen bzw. zu pflegen. Das Web-Content-Management-System - im folgenden auch Produkt genannt - soll dabei ohne Installation besonderer Programme bedienbar sein. Des weiteren soll die Verwaltung der Internetseiten konsistent erfolgen, die Integration von Dokumenten anderer Formate ermöglicht werden, sowie das Layout der Internetpräsentation austauschbar gespeichert werden. 1.1 Musskriterien: müssen auf jeden Fall implemtiert werden Verwalten der Internetseiten Verwalten der Nutzer Verwalten der Zugriffsrechte Bedienbarkeit mit einem Internetbrowser der 4. Generation persistente und konsistente Speicherung der Internetseiten Suche innerhalb der gespeicherten Internetseiten austauschbares Layout für einzelnen Bereiche 1.2 Wunschkriterien: Erfüllung angestrebt, aber nicht unabdingbar Schaffung großer Spielräume zur Gestaltung des Layouts Integration bestehender Wartungsmöglichkeiten direkte Übernahme bestehender Internetseiten 1.3 Abgrenzungskriterien: Ziele, die bewusst nicht erreicht werden sollen keine integrierte Verwaltungssoftware für Geschäftsprozesse keine Implementierung von Drag and Drop 68 Wolf Zimmermann 4. Produktfunktionen (Ausschnitt) 4.0 allgemeine Funktionen: /F0 20/ Korrespondenz mit anderen Systemen der Universität /F0 25/ mit anderem System der Universität verbinden /F0 30/ Kontrollieren der Konsistenz der Seiten (Links, Bilder,...) /F0 40/ Erstellen von Übersichten /F0 50/ Kontrollieren der Aktualität der Inhalte. 4.1 Funktionen für Internetnutzer: /F1 10/ Abrufen der Seiteninhalte /F1 20/ Abrufen der Metadaten /F1 30/ Abrufen der Aktualität /F1 40/ Infos an Seitenverantwortliche schicken. 4.2 Funktionen für Mitarbeiter der MLU: /F2 10/ Einfügen von Layoutelementen /F2 20/ Bearbeiten von Layoutelementen /F2 30/ Löschen von Layoutelementen /F2 35/ Verschieben von Layoutelementen /F2 40/ Erstellen einer lokalen Kopie einer externen Seite. (insgesamt ca. 250 Funktionen) 70 Wolf Zimmermann

10 5. Produktdaten Daten von Nutzern: /D1 10/ persönliche Daten (unter Einhaltung des Datenschutzes) /D1 20/ Zugriffsrechte Daten von Seiten: /D2 10/ Seiteninhalte (Texte, Verweise, Bilder,...) /D2 20/ Layoutelemente (Tabellen, Absätze,...) /D2 30/ Bereichszugehörigkeit verschiedener Seiten /D2 40/ beschreibende Daten (Meta-Daten) der Seiten (kategorisierter Seiteninhalt, Autor,...) Allgemeine Daten: /D3 10/ Dokumente in Fremdformaten (pdf, cls, doc,...) /D3 20/ Bilder in verschiedenen Formaten (jpg, png, gif,...) /D3 30/ Cascading Style Sheets (css) für die einzelnen Bereiche C) Projektplan Ziel: Festlegung des Projektablaufs Entwicklungsmodell Zeit Personal Methoden Werkzeuge Beispiel: Web-Content-Managementsystem der MLU Vorstudie Lastenheft Allgemeine Analyse 2 Monate 1 Monat Pflichtenheft OO Analyse 1 Monat Allg. Funkt. OO Analyse 1 Monat Internetnutzer. OO Analyse Mitarbeiter 3 Monate OO Analyse Verantw. 1 Monat träger OO Analyse Layout verantwort. 1 Monat OOA Modell OO Analyse Webmaster 1 Monat 71 Wolf Zimmermann Andreas Both Vorstudie Allg. Analyse OOA Mitarbeiter OOA Layout N.N 73 OOA Allgemein OOA Internetnutz. OOA Verantw. OOA Webmaster Wolf Zimmermann 6. Produktleistungen /L10/ Langlebigkeit und Plattformunabhängigkeit /L20/ spezielle Nutzerrechte für einzelne Nutzergruppen /L30/ verschiedene Ansichten für Nutzer und Redakteure bzw. Administratoren /L40/ Fernwartung via Webbrowser /L50/ Benutzer sollen immer wissen, wo sie sich befinden /L60/ Ausführungszeit der Skripte nicht wesentlich größer als Netzwerklatenzzeiten /L70/ Klassifikation der Layoutelemente /L80/ Hilfestellung zu Suchmöglichkeiten und Eingabefeldern /L90/ Unterstützung für verschiedene Sprachen /L100/ erzeugte Quellcodegröße höchstens 15 KByte /L110/ Datenaustausch mit TK-Anlage /L120/ Datensicherung /L130/ rekursive und zeitabhängige Nutzungsrechte /L140/ Wahrung des Datenschutzes /L150/ bis zu 4000 Mitarbeiter und Studenten müssen verwaltet werden /L160/ gespeicherte Daten müssen synchron mit den per HTML angzeigten Daten sein D) Benutzerhandbuch Ziel: Beschreibung der Benutzerschnittstelle des Systems Rolle des Benutzerhandbuchs: Während der Erstellung: Kommunikation zwischen Auftraggeber und Entwickler Nach Auslieferung: Schulung der Benutzer Inhalt des Benutzerhandbuchs: Teile der Systembeschreibung Ergebnisse mit Prototypen Studien der Bildschirmanzeigen und dialoge 72 Wolf Zimmermann 74 Wolf Zimmermann

11 E) Verifikationsplan Ziel: Definition von Methoden zum Überprüfen der Anforderungen im Pflichtenheft Beispiel: 1 Zu überprüfende Anforderungen 2 Entwurfsverifikationsplan 3 Quellcodetestplan 4 Testvollständigkeitskriterien 5 Dokumentationsverifikation 6 Werkzeuge und Methoden 75 Wolf Zimmermann F) Systemarchitektur Ziel: Beschreibung der Module Implementierer können Module unabhängig voneinander entwickeln Warter können von Änderung betroffene Module identifizieren und abändern Inhalt: 1 Grobentwurf (enthält alle Module und Subsysteme): Funktionale Beschreibung, Entwurfsentscheidungen, Gliederung der Subsysteme 2 Modulschnittstellen a Liste der verfügbaren Komponenten: Typen, Konstanten, Variable, Köpfe der Unterprogramme mit Parameter b Ein-/Ausgabeformate c Beschreibung der Effekte der Unterprogramme d Qualitätsmerkmale: z.b. Laufzeitanforderungen, Speicherplatzbeschränkungen, Genauigkeit e Fehlerbeschreibung und behandlung 3 Benutztrelation (Verbindungsstruktur der Module) 4 Feinentwurf: Modulinterne Datenstrukturen, Grundalgorithmen, Initialisierungen, Fehlerüberprüfng und behandlung, Programmiertechniken, Werkzeuge 5 Begriffsverzeichnis 6 Quellenverzeichnis 77 Wolf Zimmermann Abnahmetestplan Ziel: Festlegung konkreter Testfälle samt erwarteten Ergebnisse für jede Anforderung Beispiel: 1 Zu überprüfende Anforderungen 2 Testfälle für diese Anforderungen 3 Für jeden Testfall: Demonstrierte Eigenschaften Erwartete Ergebnisse Beispiel: Web-Content-Managementsystem der MLU Grobentwurf: Aufbau des Gesamtsystems (mit Benutztrelation) Allgemeine Funktionen Funktionen fúr Internetnutzer Benutzerschnittstelle Webbrowser, Editor... Funktionen für Mitarbeiter Funktionen für Verantwort. Layout funktionen Funktionen für Webmaster Datenbank Webseiten, Layoutlemente,Nutzerdaten,Nutzerrechte,Meta Daten,Dokumente in Fremdformaten, Bilder,ccs 76 Wolf Zimmermann 78 Wolf Zimmermann

12 Beispiel: Web-Content-Managementsystem der MLU Funktionale Beschreibung der Datenbank: relationale Datenbank mit Anfragesprache mysql Funktionale Beschreibung allgemeine Funktionen: z.b. Speicherung von Informationen über einen langen Zeitraum Pre: Verbindung zu Datenbasis existiert Relationenschema für zu speichernde Information existiert Post: alle Anfragen ausgeführt Datenbank ist konsistent G) Rückblick Ziel: Erfahrungsbericht zum Lernen aus Erfolgen und Misserfolgen Beispiel: 1 Projektbeschreibung 2 Ursprüngliche Erwartungen 3 Gegenwärtiger Projektstand 4 Problemgebiete 5 Erfahrungen aus der Entwicklung 6 Technische Erfahrungen 7 Managementerfahrungen 8 Empfehlungen 79 Wolf Zimmermann 81 Wolf Zimmermann Beispiel:Web-Content-Managementsystem der MLU Klassendiagramm für Anfragen: StorageInformation insert(a:information) queryhandler 1 DatabaseProxy submitquery(q:query):bool * origin Database execquery(q:query) consistent?(q:query):bool Algorithmus für submitquery: res = origin.consistent?(q) prüft, ob q Konsistenz erhält. if res then origin.execquery(q); im Erfolgsfall ausführen return res Rückgabe der Erfolgsmeldung 1 images H) Diskussion des Wasserfallmodells Vorteile: Dokumentengetriebenes Modell Aktivitäten enden mit fertiggestellten Dokumenten Orientiert an top-down-vorgehen Einfach, verständlich, wenig Managementaufwand Einfache Anpassung an projektspezifische Anforderungen Benutzerbeteiligung nur in Definitionsphase Nachteile: Sequentielle Reihenfolge der Entwicklungsschritte nicht immer sinnvoll Vollständige Durchführung der Entwicklungsschritte nicht immer sinnvoll Gefahr der Bürokratisierung Dokumente wichtiger als eigentliches System Zu geringe Berücksichtigung der Risikofaktoren 80 Wolf Zimmermann 82 Wolf Zimmermann

13 Anforderungs definition Grobentwurf Feinentwurf Implementierung V-Modell Anwendungsszenarien Testfälle, Verifikation Testfälle, Verifikation Testfälle Verifikation Modultest Integrations test System test Abnahme test Tests (Forts.) Systemtest: Abschließender Test ohne Auftraggeber Nur externe Schnittstellen des Systems z.b. Benutzungsoberfläche Basis: Pflichtenheft Funktionstest (Vollständigkeit, Korrektheit) Leistungstest Massentest (verarbeitbare Datenmengen) Zeittest (Einhaltung von Zeitbedingungen) Lasttest (Zuverlässigkeit im erlaubten Grenzbereich des Systems) Stresstest (Auslotung der Grenzen des Systems) Benutzbarkeitstest Sicherheitstest Interoperabilitätstest (Zusammenarbeit mit anderen Systemen) Installationstest (Inbetriebnahme des Systems gemäß Benutzerhandbuch) 83 Wolf Zimmermann 85 Wolf Zimmermann Tests Modultest: Überprüft Korrektheit der Module Funktionalität Leistungsmerkmale Zuverlässigkeit Änderbarkeit Black-box Test vs. white-box-test Integrationstest: Überprüft fehlerfreies Zusammenwirken der Systemkomponenten Voraussetzung: Modultest Black-box-Test Diskussion Vorteile: Integration der Qualitätssicherung in Wasserfallmodell Einfache Anpassung an projektspezifische Anforderungen Standardisierte Abwicklung von Systemerstellungsprojekten Gut geeignet für große Projekte, insbesondere eingebettete Systeme Implementiert ISO 9000 Nachteile: Nur eingeschränkt übertragbar auf kleinere und mittlere Projekte Hohe Produktvielfalt und Bürokratie Ohne CASE-Werkzeuge praktisch nicht handhabbar Nicht methodenneutral 84 Wolf Zimmermann 86 Wolf Zimmermann

14 Anforderungs analyse Prototyp, Entwurf Implementierung Vorführung Anforderungs analyse Validierung Entwurf Validierung Prototypenmodell Prototyp Klärung wichtiger Fragen und Unsicherheiten Systembeschreibung, Pflichtenheft, Projektplan vorläufiges Benutzerhandbuch, Verifikationsplan Implementierung Validierung Systemarchitektur,Benutzer handbuch, Verifikationsplan Test Validierung Module, Testdaten Dokumentation funktionsfähiges System, Rückblick Diskussion Vorteile: Erleichtert Aquisitation von Aufträgen Unterstützt Auftraggeber und Entwickler bei Anforderungsanalyse Leicht in andere Prozessmodelle integrierbar Erleichtert Planung von Softwareprojekten Werkzeugunterstützung für schnelle Erstellung von Prototypen rapid prototyping Nachteile: Höherer Entwicklungsaufwand Gefahr, dass Wegwerfprototyp doch Bestandteil des Produkts wird Verträge zur Softwareerstellung berücksichtigen keine Prototypen Prototypen als Ersatz für fehlende Dokumentation Unbekannte Grenzen und Beschränkungen des Prototyps Betrieb und Wartung Revalidierung 87 Wolf Zimmermann 89 Wolf Zimmermann Verschiedene Prototypen Demonstrationsprototyp: Vermittelt Eindruck über zu erstellendes Produkt Dient zur Auftragsaquisitation Vernachlässigung softwaretechnischer Standards Prototyp im engeren Sinn: Provisorisches ablauffähiges System Parallel zur Modellierung Dient der Analyse des Anwendungsbereichs Labormuster: Demonstriert technische Umsetzbarkeit Antwort auf konstruktionsbezogene Fragen und Alternativen Pilotsystem: Kern des Produkts Weiterentwicklung in Zyklen Erhöhung des Reifegrads partielles Modell Versionsmodell Nullversion n :=0 n := n + 1 Definition der Version n partielle Architektur Entwurf der Version n Änderungen Implementierung der Versionn Änderungen Einbetten der Version n Wünsche auch inkrementelles oder evolutionäres Modell 88 Wolf Zimmermann 90 Wolf Zimmermann

15 Diskussion Vorteile: Auftraggeber erhält in kürzeren Zeitabständen einsatzfähige Produkte Einfache Kombination mit Prototypenmodell (Pilotsystem) Unterstützt Studium der Auswirkungen des Produkts auf Arbeitsabläufe Leichtere Korrekturen der Entwicklungsschritte Keine einseitige Ausrichtung auf Endabnahmetermin Nachteile: Teuer Gefahr der Komplettüberarbeitung Unflexible Nullversion Anforderungs analyse Formalisierung Transformationsmodell Entwurf formale Spezifikation Konsistenz Vollständigkeit Änderungswünsche (halb) automat. Generieren Implementierung praktischer Einsatz 91 Wolf Zimmermann 93 Wolf Zimmermann Verbesserung des Versionsmodells Beispiel: Übersetzer vollständiges Modell Anforderungs analyse Nullversion n :=0 modifiziertes Modell n := n + 1 partielle Architektur geänderte Anforderungen Entwurf der Version n Änderungen falls n >0 Implementierung der Versionn Änderungen Einbetten der Version n Wünsche Spezifikation Generator Modul reguläre Ausdrücke konkrete Syntax (Grammatik) abstrakte Syntax (Grammatik) attributierte Grammatik Abbildung abstrakt > Zwischensprache LEX REX yacc LALR ELL AST AG Puma lexikalische Analyse syntaktische Analyse Syntaxbaum semantische Analyse Transformation Zwischensprache (Grammatik) AST Zwischen sprache Abbildung Zwischensprache > Assembler BEG Codegenerator 92 Wolf Zimmermann 94 Wolf Zimmermann

16 Diskussion Vorteile: Wartung auf Spezifikation Automatisierung der Implementierung Werkzeuge zur Konsistenz- und Vollständigkeitsprüfung Nachteile: nur in wenigen Bereichen anwendbar oft nur auf kleine Programme anwendbar ungeschulte Mitarbeiter Diskussion Vorteile: Höhere Produktivität und Qualität Außer-Hausentwicklungen Einsatz und Produktion von Standardsoftware Gut kombinierbar mit Versionsmodell und Prototypenmodell Schult Blick über den Tellerrand Nachteile: Gebunden an objektorientierte Technologie Vorhandene Wiederverwendungsinfrastruktur Zusätzliche Kosten für Erweiterung firmeninterner Wiederverwendungsinfrastruktur Aufbau einer Firmenphilosophie zur Wiederverwendung Technische Probleme, z.b. Inkompatibilitäten in und zwischen Klassenbibliotheken 95 Wolf Zimmermann 97 Wolf Zimmermann Objektorientiertes Modell Nebenläufiges Modell Anforderungs analyse Wiederverwendung OOA Modell Suchen Definition Kernsystem Änderungen Änderungen OOA Modell Entwurf Wiederverwendung OOD Modell Implementierung Wiederverwendung Auswählen OOD Modell Auswählen Klassen Subsystem klassen Suchen OOD Modell Suchen Ablegen Ablegen w i e d e r v e r w e n d b a r e K o m p o n e n t e n partielles Modell Entwurf Kernsystem partielle Architektur Implementierung Kernsystem Kernsystem Änderungen Änderungen Definition Ausbaustufe 1 erweitertes Modell Entwurf Aufbaustufe 1 erweiterte Architektur Implementierung Aufbaustufe 1 Änderungen Änderungen Definition Ausbaustufe 2 erweitertes Produktmodell Entwurf Aufbaustufe 2 erweiterte Produktarchitektur OO Produkt 1 OO Produkt 2 OO Produkt Analysieren Überarbeiten Verallgemeinern Auswählen Klassen Komponenten Ablegen Ablegen erweitertes Kernsystem Implementierung Aufbaustufe 2 erweitertes Produkt Produkt 96 Wolf Zimmermann 98 Wolf Zimmermann

17 Charakteristika des nebenläufigen Modells Parallelisieren des Entwicklungsprozesses Das Spiralmodell Grundsätzliche Struktur: Förderung der zielgerichteten Zusammenarbeit der Personengruppen Reduktion von Zeitverzögerungen Parallelisierung von Aktivitäten Minimierung des Ausprobierens Reduktion von Wartezeiten zwischen organisatorisch verbundenen Aktivitäten Frühe Integration der Erfahrungen der betroffenen Arbeitsgruppen Bestimme Ziele, Alternativen Beschränkungen Verpflichtung nächste Runde Überprüfung Plane nächste Runde Evaluiere Alternativen Bestimme und behebe Risiken Erstelle und verifiziere Produkt 99 Wolf Zimmermann 101 Wolf Zimmermann Diskussion Spiralmodell Vorteile: Frühes Erkennen und Beseitigen von Problemen Optimale Zeitausnutzung Bestimme Ziele, Alternativen Beschränkungen Risikoanalyse (RA) Risikoanalyse (RA) Evaluiere Alternativen Bestimme und behebe Risiken Nachteile: Realisierbarkeit bei Softwareprojekten? Risiko, kritische Entscheidungen zu spät zu treffen Hoher Planungs- und Personalaufwand 100 Wolf Zimmermann Plane nächste Runde Entwicklungs plan Integrations und Testplan Risikoanalyse (RA) R Prototyp Anforderungen A 1 Lebenszyklus Vorgehens plan konzept Software anforderungen Validierung der Anforderungen Software produkt entwurf Validierung und Verifikation des Entwurfs Abnahmetest Implementierung Prototyp 2 Prototyp 3 Integration und Test Pilotsystem Simulationen, Modelle, Vergleiche Detailentwurf Codierung und Modultest Erstelle und verifiziere Produkt 102 Wolf Zimmermann

18 Merkmale des Spiralmodells Alle bisherigen Modelle sind Speziallfälle des Spiralmodells Risikogetriebenes Modell Risikominimierung Jede Spirale ist iterativer Zyklus durch dieselben Schritte Ziele für Zyklus aus vorhergehendem Zyklus Separate Spiralzyklen für verschiedene Softwarekomponenten möglich Keine Trennung von Entwicklung und Wartung Erreiche Entwicklungsziele mit minimalen Kosten Berücksichtigt Qualitätsziele Pro Aktivität und Ressourcenverbrauch wird gefragt: Wieviel ist genug? 103 Wolf Zimmermann Die Top-Ten Risiken und Maßnahmen: 1 5 Risikoelement Risikomanagement-Techniken 1 Personelle Defizite hochtalentierte Mitarbeiter einstellen Teams zusammenstellen 2 unrealistische Terminund Kostenvorgaben 3 Entwicklung von falschen Funktionen und Eigenschaften 4 Entwicklung der falschen Benutzerschnittstelle detaillierte Kosten und Zeitschätzung (mehrere Methoden) Produkt an Kostenvorgaben orientieren Inkrementelle Entwicklung Wiederverwendung Anforderungen streichen Benutzerbeteiligung Prototypen frühzeitiges Benutzerhandbuch Prototypen Aufgabenanalyse Benutzerbeteiligung 5 über das Ziel hinausschießen Anforderungen streichen Prototypen Kosten/Nutzen-Analyse Entwicklung an Kosten orientieren 105 Wolf Zimmermann Risikomanagement Die Top-Ten Risiken und Maßnahmen: 6 10 Risikobewertung Risikobeherrschung Risiko Identifikation Risikoanalyse Risiko prioritätenbildung Risiko management planung Risiko überwindung Risiko überwachung Checklisten Vergleich mit Erfahrungen Zerlegung Leistungsmodelle Kostenmodelle Analyse der Qualitätsanforderungen Risikofaktoren bestimmen Risikowirkung bestimmen Reduktion zusammengesetzter Risiken Kaufen von Informationen Risikovermeidung oder verringerung Risikoelementplanung Risikoplanintegration Prototypen Simulationen Leistungstests Mitarbeiter Analysen Verfolgung der Top Ten Risiken Verfolgung der Meilensteine Risiko Neueinschätzung korrigierende Aktionen Risikotechniken Risikoelement 6 kontinuierliche Anforderungsänderungen 7 Defizite bei extern gelieferten Komponenten 8 Defizite bei extern erledigten Aufträgen Risikomanagement-Techniken hohe Änderungsschwelle inkrementelle Entwicklung (Änderungen nach hinten schieben) Leistungstest Inspektionen Kompatibilitätsanalyse Prototypen frühzeitige Überprüfung Verträge auf Erfolgsbasis 9 Defizite in Echtzeitleistung Simulation Prototypen Leistungstest Instrumentierung Modellierung Tuning 10 Überfordern der Software-Technik technische Analyse Kosten/Nutzen Analyse Prototypen 104 Wolf Zimmermann 106 Wolf Zimmermann

19 Beispiel: Risikofaktoren bei Steuerung eines Satellitenexperiments unbefriedigendes Ergebnis Wahrscheinlichkeit Schaden Risikofaktor 1 Softwarefehler tötet Experiment Softwarefehler verursacht Verlust von Schlüsseldaten fehlertolerante Eigenschaften führen zu unannehmbarer Leistung Überwachung ergibt, dass unsichere Bedingungen als sicher gemeldet werden Überwachung ergibt, dass sichere Bedingungen als unsicher gemeldet werden Verzögerung bei Hardwarelieferung verursacht Zeitüberschreitungen zusätzliche Arbeit durch Softwarefehler bei Datenreduktion ineffiziente Bedienung durch schlechte Benutzeroberfläche Prozessorspeicher nicht ausreichend Datenbanksoftware verliert gespeicherte Daten Metriken Ziel: Objektive Identifikation von Risiken bei Software durch quantitative Angaben über SW-Entwicklung und Software Vorgehensweise: Schritt Def./Interpr. Beispiel 1 Messziel # nicht-kommentierter Quellanweisungen (NCSS) 2 Messaufgaben zählen der NCSS eines Programms 3 Messobjekt Auswahl des zu vermessenden Programms 4a Messgröße # Quellanweisungen einschließlich Übersetzerdirektiven ohne Leerzeilen, Kommentarzeilen zweifaches Zählen jeder Codezeile einfaches Zählen jeder enthaltenen Datei 4b Messeinheit KNCSS (1000 NCSS) 5 Messwerkzeug automatischer Zeilenzähler 6 Messwerte durch Messen mit autom. Zeilenzähler 7 Interpretation Umfang der produz. Software 107 Wolf Zimmermann 109 Wolf Zimmermann Beispiel: Risikoüberwachung bei Steuerung eines Satellitenexperiments Monatsrang Fortschritt bei Risikoelement dieser M. letzter M. # M. Risikoüberwindung Ersetzen des Entwicklers für die gewünschter Ersatzkandidat Sensorkontrollsoftware nicht verfügbar Auslieferung der Zielhardware Verzögerungen beim verzögert Beschaffungsverfahren Aktionen des Software- und undef. Datenformat für Sensorteams nötig; fällig Sensoren nächster Monat Schlüsselperson verpflichtet; Personal für Qualitätssicherung Fehlertoleranzprüfer benötigt Fehlertoleranz gefährdet erfolgreicher Leistung Fehlertoleranzprototyp Datenbusänderungen Termin für Treffen der 6 1 berücksichtigen Datenbusentwerfer Schnittstellendefinitionen für Testumgebung Unsicherheiten in der Benutzungsoberfläche Prototyp erfolgreich Betriebskonzept erstellen 7 3 erledigt Unsicherheiten in der wiederverwendeten 9 3 Überwachungssoftware einige Verzögerungen; Treffen terminiert geforderte Entwurfsänderungen erfolgreich Diskussion Vorteile: Festlegung und Änderung des Prozessablaufs risikoabhängig Prozessmodell nicht für gesamte Entwicklung festgelegt Frühe Erkennung und Beseitigung von Fehlern Frühzeitige Erkennung und Auswahl von Alternativen Flexibel gegenüber Änderungen in Anforderungen, Entwicklung Unterstützt Wiederverwendung Nachteile: Hoher Managementaufwand Ungeeignet für kleinere und mittlere Projekte Wissen über Identifizieren und Beherrschen von Risiken noch nicht weit verbreitet 108 Wolf Zimmermann 110 Wolf Zimmermann

20 Zusammenfassung Primäres Ziel antreibendes Benutzer Prozeßmodell Moment beteiligung Merkmale minimaler Dokumente gering Wasserfallmodell Managementaufwand sequentiell, volle Breite V-Modell maximale Qualität Dokumente gering sequentiell, volle Breite, Verifikation, Validation Prototypenmodell Risikominimierung Code hoch nur Teilsysteme minimale Entwicklungszeit Code mittel Versionsmodell Risikominimierung volle Definition, dann zunächst Kernsystem Transformations maximale Qualität Spezifikation gering modell Automatisierung Kostenminimierung Wiederverwendbare unklar OO-Modell Komponenten volle Breite abhängig von Bibliothek nebenläufiges minimale Entwicklungszeit Zeit hoch Modell volle Breite, nebenläufig Spiralmodell Risikominimierung Risiko mittel Entscheidung pro Zyklus über weiteres Vorgehen 111 Wolf Zimmermann Meilenstein Meilenstein: Ziel eines Planungs oder Entwicklungsschritts Dient der Projektüberwachung Inhaltliche Definition Definition der Form Dokumente, erfolgreiche Tests etc. Anforderungen: Überprüfbares Ziel Klare Zuständigkeit für die Durchführung des Schritts Klare Zuständigkeit für die Abnahme Klare Abhängigkeiten Was wird vorausgesetzt? Wer ist dafür verantwortlich? Wann wird das Ergebnis benötigt? Von wem? Schätzung der Zeit bis zum Erreichen des Meilensteins Schätzung fortschreiben 113 Wolf Zimmermann 1 Meilensteine 2 Netzpläne 3 Zeitplanung 4 Einsatzmittelplanung 5 Kostenplanung 2.3 Hilfsmittel zur Projektplanung Netzpläne Netzplan: Markierter gerichteter azyklischer Graph Zwei Arten von Ecken: Tätigkeiten und Meilensteine Markierungen Tätigkeiten: Dauer Meilensteine: spätester Termin Kanten bezeichnen kausale Abhängigkeiten Balkendiagramme: (auch: Gantt-Diagramme) x-achse: Zeiten, y-achse: Mitarbeiter Balken entsprechen Tätigkeiten (Länge entspricht Dauer, Breite Anzahl der Mitarbeiter) 112 Wolf Zimmermann 114 Wolf Zimmermann

21 Beispiel: Netzplan-Graph Tage 15 Tage Risikominimierung Aufgaben Start 8 Tage T1 15 Tage T2 M M3 T3 5 Tage T6 20 Tage T M4 T9 M6 7 Tage T Zeitplanung Einsatzmittelplanung 10 Tage Tage M8 T4 M2 T5 M7 15 Tage T Tage T M5 25 Tage T8 Ende Wolf Zimmermann 117 Wolf Zimmermann Beispiel:Gantt-Diagramm Zeitplanung mit Netzplänen T1 T2 T4 T3 T5 Zeit 1 Ermittle kritischer Pfad im Graphen 2 Ermittle für Tätigkeiten und Meilensteine maximal zulässige Verzögerungen Vorwärtsrechnung bestimmt früheste Anfangs- und Endtermine Rückwärtsrechnung bestimmt späteste Anfangs- und Endtermine Keine Variationsmöglichkeiten für Tätigkeiten auf kritischem Pfad 9 10 Mitarbeiter Termin 116 Wolf Zimmermann 118 Wolf Zimmermann

22 Start 10 Tage T4 8 Tage T1 15 Tage T2 Beispiel: Kritischer Pfad Tage 15 Tage M1 T3 T Tage M3 T6 M4 20 Tage T Tage M2 T5 M7 15 Tage T M6 7 Tage T M8 10 Tage T Einsatzmittelplanung (engl. scheduling) Einsatzmittel: Personal Betriebsmittel, z.b. Maschinen, Materialien Geldmittel Technik: Gantt-Diagramme kapazitätskritischer Pfad auslastungsoptimale Ausnutzung der Einsatzmittel Hier: Personalplanung Betriebsmittelplanung analog M5 25 Tage T8 Ende Wolf Zimmermann 121 Wolf Zimmermann Tolerierbare Verzögerungen T4 T1 Schritte der Personalplanung 1 Ermitteln des Personalvorrats Qualifikationen, geographische und organisatorische Randbedingungen T2 T7 T3 2 Ermitteln des Personalbedarfs pro Tätigkeit Verhältnis Personalkapizität vs. Zeitdauer T8 T6 3 Vergleich von Bedarf und Vorrat T5 T9 T10 T11 T12 4 Optimierung der Auslastung termingetreue Einsatzplanung Welche Personalkapazität ist in welcher zeitlichen Belegung erforderlich? kapazitätsgetreue Einsatzplanung früheste Fertigstellung bei optimalem Personaleinsatz M5 M3 M2 M7 M1 M5 M3 M4 M7 M6 M8 M2 120 Wolf Zimmermann 122 Wolf Zimmermann

23 Beispiel: Vergleich Bedarf Vorrat Termingetreue Optimierung T1 T2 T3 T5 Zeit Vorrat T1 T2 T3 T4 T5 Zeit Vorrat Mitarbeiter T4 Termin Bedarf Mitarbeiter Termin Bedarf 123 Wolf Zimmermann 125 Wolf Zimmermann Optimierung der Auslastung Termingetreue Einsatzplanung Gleichmäßige Auslastung innerhalb Zeitpuffer Bedarf kann größer als Anzahl der zur Verfügung stehenden Mitarbeiter sein Kapazitätsgetreue Einsatzplanung berücksichtigt Anzahl der zur Verfügung stehenden Mitarbeiter verschiebt evtl. Termin nach hinten Mitarbeiter Kapazitätsgetreue Optimierung Zeit T5 T3 T1 T4 T2 Vorrat Termin Fertigstellung 124 Wolf Zimmermann 126 Wolf Zimmermann

24 2.3.5 Kostenplanung Voraussetzung: Kostenschätzung (nächstes Kapitel) Gemeinkosten: Indirekte Kosten z.b. Mieten für Bürogebäude, Gehälter für Verwaltungspersonal Fixe Kosten: einmalige Kosten z.b. Kauf von Werkzeugen, Rechnern Fixe Erlöse: Einmalige Erlöse (im Zusammenhang mit Tätigkeiten) z.b. bestimmter Teil der Vertragssumme fällig mit Pflichtenheft Ressourcenkosten: Laufende Kosten z.b. Gehälter von Mitarbeiter Tätigkeitskosten = Summe fixe Kosten + Summe Ressourcenkosten fixer Erlös 127 Wolf Zimmermann Kostenverteilung im Softwarezyklus Analyse (3%) Spezifikation (3%) Entwurf 5 % Implementierung 7 % 15 % Test 67 % Wartung 128 Wolf Zimmermann