V9 SCR, Basismodelle, Prozessmodelle

Transkript

1 V9 SCR, Basismodelle, Prozessmodelle Spiralmodell (risikogetrieben, generisch) - Ziel: Flexible Anpassung des Prozessmodells, Risikominimierung, Kostenminimierung - Keine Trennung in Entwicklung und Wartung, iterative Zyklen 1. Ziele, Alternativen, Randbedingungen > Identifikation der Ziele (Leistung, Funktionalität) > Identifikation von Alternativen (Wiederverwendung, Kauf) > Randbedingungen (Schnittstellen, Kosten) 2. Evaluierung, Risikomanagement > Evaluierung der Alternativen > Risikoidentifikation und Beherrschung 3. Entwicklung und Verifikation der nächsten Generation > Risiko, Festlegung des Prozessmodells > Ggf. Kombination verschiedener Modelle 4. Planung der nächsten Phase > Planung > Überprüfung > Einverständnis Vorteile: - Periodische Überprüfung und in Abhängigkeit von den Risiken Neufestlegung des Prozessablaufs - Keine Festlegung auf ein einziges Prozessmodell für die gesamte Entwicklung - Integration anderer Prozessmodelle als Spezialfälle - Frühzeitiges eliminieren von Fehlern und ungeeigneten Alternativen - Flexibles Modell - Einfachere Neuausrichtung der Entwicklung - Unterstützung der Wiederverwendung durch Betrachtung von Alternativen Nachteile: - Hoher Managementaufwand - Weniger gut für kleine und mittlere Projekte geeignet - Wissen über das Identifizieren und Managen von Risiken noch nicht weit genug verbreite Zusammenfassung Basismodelle (zur kurzen Wiederholung): - Sequentielles Modell: Phase beginnt erst nach Abschluss der jeweiligen Vorgängerphase (z.b. Wasserfall- Modell) - Nebenläufiges Modell: Überlappende Phasen (First time right), - Inkrementelles Modell: Aufbau aus Teilprodukten oder schalenförmig - Evolutionäres Modell: Kernanforderungen -->Nullversion --> weitere Versionen - Komponenten: Verwendung eigener oder zugekaufter Komponenten - Prototypen: Konzeptbestätigung bei nicht vollständig bekannten Anforderungen bzw. zur Validierung technischer Lösungen - Produktfamilien,-linien: Modellierung eines Anwendungsbereichs, Erstellung abgeleiteter Kundenprodukte aus dem allgemeinen Modell - V-Modell: Erstellung von Testfällen in jeder Entwicklungsphase - Spiralmodell: Metamodell, mehrfaches Durchlaufen von Zyklen, Entscheidungen abhängig vom jeweiligen Risiko

2 Vergleich Basismodelle (laut Foren wichtig für Klausur): Prozessmodelle: Fehlende Aussage bei Basismodellen zu: Personelle Organisation Gliederung der Dokumentation Verantwortlichkeiten für Aktivitäten und Dokumente Ziele von Prozessmodellen: Planungen (halbfertig) von der Stange zu verwenden Werkzeuge und Methoden gemeinsam einzuführen Resultate zu vergleichen und auszutauschen Schwachstellen zu erkennen und aus Erfahrungen zu lernen Bestandteile von Prozessmodellen: Organisation und Verantwortlichkeiten, Rollenverteilung Struktur und Merkmale der Dokumente Einzusetzende Verfahren, z.b. für Erhebung der Anforderungen auszuführenden Schritte der Entwicklung, ihre Reihenfolgen und ihre Abhängigkeiten Projektphasen und Meilenstein, Prüfkriterien, Notationen und Sprachen, Werkzeuge monumentales Modell: sehr umfassende, detaillierte und formale Beschreibung von Aktivitäten Tailoring: anpassen von Modellen auf aktuelle Projektsituation - statisch: Anpassung vor Projektstart - dynamisch: Anpassung während des Projektes

3 V-Modell 97: Ziele: - Standardisierung der Software-Erstellung - Zusammenführung und Standardisierung der ingenieurmäßigen Ansätze - Leitfaden zum systematischen Planen und Durchführen von komplexen und umfangreichen Entwicklungsprojekten - Beschreibung der Vorgehensweisen für die Softwareentwicklung - Festlegung von: Wer, was, wann in einem Projekt zu tun hat - Minimierung der Projektrisiken - Verbesserung und Gewährleistung der Qualität - Kostenreduktion - Verbesserte Kommunikationsbasis für die beteiligten Parteien - Regelung der Kooperation zwischen Aufraggebern und Auftragnehmern - Vertragungsgrundlage bei der Auftragsvergabe - Breite Verfügbarkeit - Beinhaltet auch die Entwicklung von Hardware - Keine Behandlung von Dienstleitungen Ebenen: Vorgehensweise --> Was ist zu tun? Methoden --> Wie ist etwas zu tun? Werkzeuganforderungen --> Womit ist etwas zu tun? Projektmanagement Systemerstellung Qualitätssicherung Konfigurationsmgmt. --> Projektmanagement: Planung, Steuerung und Kontrolle des Vorgehens --> Systemerstellung: Aktivitäten für die Erstellung des Softwareproduktes --> Qualitätssicherung: Unabhängige Prüfung, Einhaltung von Qualitätsstandards und Normen --> Konfigurationsmanagement: Verwaltung der Produkte, Versionsverwaltung Entwicklungsphilosophie: Inkrementelle Entwicklungsmethode, Abgrenzung der Gesamtfunktionalität Definition von Ausbaustufen gemäß Priorität Sukzessive Detaillierung und Umsetzung der Ausbaustufen Bereitstellung der Zwischenstufe an den Endanwender Überarbeitung von Gesamtplan und erneute Detailplanung gemäß Anwenderfeedback Standard für unterschiedliche Anwendungsaspekte (ohne technische und organisatorische Einschränkungen) Umfangreiche Erfahrungen und Modellkenntnisse erforderlich, hoher Aufwand bei der Erstanwendung Vorschläge zu passenden Methoden sowie Anforderungen an einzusetzende Werkzeuge Verbesserte Kommunikation, Produktivitätsgewinn, bessere Kalkulation V-Modell XT (Überarbeitung von Modell 97): XT = Extreme Tailoring (Modell kann für verschiedene Prototypen maßgeschneidert werden) Ziele: - Bessere Anpassungs- und Anwendungsmöglichkeiten bei unterschiedlichen Projekten und Organisationen, Anpassung an organisationsspezifische Gegebenheiten - Skalierbarkeit hinsichtlich verschiedener Projektgrößen - Bessere Änderungs- und Erweiterungsmöglichkeiten des Modells - Anpassung an die aktuellen Normen und Vorschriften, Betrachtung des gesamten Systemlebenszyklus - Unterstützung der Einführung sowie Verbesserung des Modells selbst

4 - HW-System: Hauptgegenstand des Projektes ist ein System, das sich aus Hardwarebestandteilen - zusammensetzt (z.b. CAN-Bus-Controller). - SW-System: Hauptgegenstand des Projektes ist ein Softwaresystem (z.b. E-Commerce-Anwendung) - Komplexes System: Besteht im Allgemeinen aus Hardware, Software und eingebetteten Komponenten (z.b. Eurofighter) - Eingebettetes System: System das über Sensoren und Aktoren mit seiner physischen Umgebung interagiert (z.b. Mikrocontroller zur Steuerung der Airbagauslösung) - Systemintegration: Integration von Einheiten zu einem System (z.b. Airbus-Fertigung) - Einführung und Pflege eines organisationsspezifischen Vorgehensmodell: Einführung und Pflege eines Entwicklungsprozesses innerhalb einer Organisation (z.b. V-Modell) Vorgehensbausteine: Zentrale Einheiten des V-Modells XT - Fassen Disziplinen oder Teile davon zusammen, die inhaltich zusammengehören - Obligatorische Vorgehensbausteine (V-Modell Kern): 1.Projektmanagement 2.Qualitätssicherung 3.Problem- /Änderungsmanagement 4.Konfigurationsmanagement - Vorgehensbausteine bauen aufeinander auf Bearbeitungszustandsmodell: - Zustände: in Bearbeitung, vorgelegt, fertig gestellt - Grundsätzliche Prüfung des erzeugten Produkts am Ende einer jeden Aktivität - enthält alle Bestandteile, die zur Bearbeitung einer konkreten Aufgabe notwendig sind - änder- und erweiterbar - Hierarchisch strukturierte Produkte, jedes Produkt wird von genau einer Aktivität fertiggestellt Projektfortschrittsstufen: - Gelten für jede Projektdurchführungsstrategie und müssen in einer festgelegten Reihenfolge erreicht werden

5 Entscheidungspunkte: - Markieren das Erreichen einer Projektfortschrittsstufe und legen fest welche Produktmenge zu einem Zeitpunkt fertig gestellt sein muss - Produkte bilden Entscheidungsgrundlage für das Management bzgl. der Erreichung einer Projektfortschrittsstufe und ggf. der Fortsetzung mit dem nächsten Projektabschnitt. - Beispiele für: a) alle Projektarten: Projekt genehmigt -->Projekt definiert -->Iteration geplant -->Projekt abgeschlossen b) Systementwicklung: Anforderungen festgelegt --> System spezifiziert --> System entworfen --> Feinentwurf abgeschlossen -->Systemelemente realisiert --> System integriert Produktvorlagen (Beispiele): 1 Projektmanagement (PM) Arbeitsauftrag Projektabschlussbericht Projektplan Besprechungsdokument Projektstatusbericht 3 Qualitätssicherung (QS) Prüfprotokoll und Prüfspezifikation Systemelement Benutzbarkeit Prozess Lieferung Dokument Prüfprozedur Systemelement QS-Handbuch 2 Systemerstellung (SE) Anforderungen (Lastenheft) Gefährdungs- und Systemsicherheitsanalyse System-, Externe-Einheit-, SWSpezifikationen Systemarchitektur SW-Architektur 4 Konfigurationsmanagement (KM) Problemmeldung/Änderungsantrag Änderungsentscheidung Änderungsstatusliste Projekthandbuch Produktkonfiguration Projekttagebuch Merkmale XT Modell: - Umfassendes Prozess- und Qualitätsmodell (Unternehmensebene, Team- und Rollenebene) - für alle Entwicklungsprojekte vorgesehen - Straffer organisatorischer Rahmen mit detaillierten Produktvorlagen und Entscheidungspunkten (Meilensteinen) in festgelegter Reihenfolge - Produkte stehen im Mittelpunkt und stellen die zentralen Projektergebnisse dar - Einfach bedienbarer V-Modell XT-Editor und Projektassistent, mit eingeschränkten Funktionsumfänge --> wenig sinnvoller Einsatz in laufendem Projekt Vor-/Nachteile: Vorteile Nachvollziehbar, konsistent und im Referenzteil ausführlich und anwendbar beschreiben. Modell, das verschiedene Projektgegenstände, Projektrollen, Projekttypen und weitere Projektmerkmale unterscheidet und entsprechende Durchführungsstrategien anbietet. Gute Trennung zwischen Auftraggeber- und Auftragnehmersicht, deren Zusammenspiel und zeitliche Verknüpfung. Werkzeuge ermöglichen das Maßschneidern (Tailoring) des Modells In der Regel gute Produktvorlagen mit Hinweisen zu den einzelnen zu erfassenden Punkten. Nachteile Für kleiner Projekte unwirtschaftlich (erst ab > 500 Personentage und > Eigenanteil) Läßt sich für kleine Projekte nicht Maßschneidern Extrem dokumentenbasiert Aufwändiger Formalismus, bestehend aus der laufenden Kette von Produkten und den Anforderungen an die Qualitätssicherung Nur vage Hinweise auf die Struktur und die Inhalte der Produkte, ebenso hierzu fast keine Musterschablonen (templates) Hoher Projektmanagementaufwand Abwicklung von Projekten erfordert weitgehende Unterstützung von Werkzeugen Rudimentäres eigentliches Projektmanagement Hoher Overhead falls nur ein Softwareprodukt entwickelt wird Grundlage bildet eine hierarchische Produktstruktur (kein Schichtenmodell)

6 Zusammenfassung XT: Vorgehen Projektgegenstand (SW-System, HW-System, usw.) und Projektrolle (AG, AN) bestimmen den Projekttyp: Entwicklungsprojekt (AG, AN, AG/AN), Einführung Vorgehensmodell, dieser bestimmt gemeinsam mit anderen Projektmerkmalen die Projektdurchführungsstrategie Bausteine Ein Vorgehensbaustein besteht aus einem Produkt, einer Aktivität und zugeordneten Rollen. Jedes Produkt besitzt einen Bearbeitungszustand. Meilensteine (Entscheidungspunkte) legen Projektfortschrittstufen fest. Anpassung In Abhängigkeit vom Projekttyp, vom Projektgegenstand und von der Projektrolle kann das V-Modell XT manuell oder mit Hilfe von Werkzeugen an die aktuellen Projekterfordernissen angepasst werden (statisches/dynamisches Tailoring) Struktur Systementwicklung mit hierarchisch angeordneten Segmenten, Komponenten und Modulen. Auftragnehmer und Auftraggeber Detaillierte Regelung der Zusammenarbeit zwischen AG und AN Vergleich mit anderen Modellen Ähnlich zu den Reifegradstufen 2 und 3 des CMMI-Modells Resümee Das V-Modell XT ist ein umfassendes, anpassbares Modell für Entwicklungsprojekte mit Werkzeugunterstützung und vielen Dokumentvorlagen, das sich für umfangreiche und teure Projekte lohnt. RUP-Modell: - Rational Unified Process = rational geschlossener Prozess - enger Zusammenhang mit UML - generischer Prozessrahmen für oo. Entwicklung - optimaler Einsatz von UML - Unterstützung der Projekt- und Unternehmensebene - iterativ, Use-Case getrieben, architekturzentriert, industriell geprägtes Prozessmodell Prinzipien einer geschäftsorientierten Entwicklung: Prozesse anpassen Konkurrierende Prioritäten von Projektbeteiligten (Stakeholder) ausgleichen Teamübergreifende Zusammenarbeit Nutzen iterativ nachweisen Abstraktionsgrad erhöhen Ständige Konzentration auf die Qualität Werkzeuge: Verlinkte Wissensbasis mit Mustervorlagen und ausführlichen Beschreibungen für die verschiedenen Aktivitätstypen Six Best Practices: - Software iterativ entwickeln (Frühes Überprüfen von Risiken, Berücksichtigung neuer bzw. geänderter Anforderungen oder Anpassung von Plänen) - Anforderungen managen (Erfassen, Dokumentieren, Organisieren und Nachverfolgen von sich ändernden Anforderungen) - Komponentenbasierte Architekturen verwenden (Reduzierung von Größe und Komplexität der Architektur sowie Erhöhung von Stabilität und Flexibilität) - Software visuell modellieren (Besseres Verständnis komplexer Systeme) - Softwarequalität kontinuierlich prüfen (Minimierung von Softwarefehlern) - Änderungen kontrolliert in die Software einbringen (Managen, Nachverfolgen und Überwachen von Änderungen) Vorgehensstrategie: Dynamische Dimension (horizontal) Zeitliche Struktur des Prozesses Verteilung von Phasen, Iterationen und Meilensteine auf den Entwicklungszyklus eines Softwareprojekts Phase besteht aus einer oder mehrerer Iterationen Top-Level Meilenstein am Ende einer Phase zur Messung des Projektfortschritts Statische Dimension (vertikal) Inhaltliche Struktur des Prozesses Einteilung von Prozesselementen (Rollen, Artefakte und Aktivitäten)in Disziplinen

7 RUP - Phasen: Konzeption (inception) Vorbereitungsphase Projektvision erste Risikoabschätzung Anforderungen größtenteils bekannt Festlegung von Projektbudget und Projektplan Abschluss mit Meilenstein Lifecycle Objective (LCO) --> Definition des Projektzwecks Ausarbeitung (elaboration) Detaillierte Erhebung der Anforderungen Entwicklung einer prototypischen Architektur Testen unterschiedlicher Lösungsansätze Vertiefen von Kenntnisse über Techniken und Werkzeuge des Lösungsbereich Abschluss mit Meilenstein Lifecycle Architecture (LCA)--> Etablierung der Architektur des Projektes Konstruktion (construction) Entwickeln eines lauffähigen Softwaresystems Testung des Softwaresystems Abschluss mit Meilenstein Initial Operational Capability (IOC) --> Produktiv einsetzbares Produkt Übergabe (transition) Transfer des Softwaresystems zum Auftraggeber Test beim Kunden, Fehlerbehebung, Anwenderschulung Abschluss mit Meilenstein Product Release (PR)-->Ende des Projektes Zusammenfassung RUP: Zentrale Ziele Frühphase des Projektes: Konzeption einer funktionsfähigen Architektur und Realisierung durch Prototypen Frühe Minimierung der Projektrisiken Ablauf Pro Phase: Optionales Durchlaufen mehrerer Iterationen Nach Durchlauf aller Phasen: Abschluss eines Entwicklungszyklus Ergebnis: Software-Generation Neues Produkt: zunächst initialer Entwicklungszyklus Weiterentwicklung: Evaluationszyklen (mit anderer Verteilung der Schwerpunkte innerhalb der Phasen) Prozessbeschreibung Wer: Rollen (ca. 27) Was: Arbeitsergebnisse (ca. 25) Wie: Aktivität Wann: Arbeitsablauf Werkzeug IBM Rational Method Composer Einsatzbereiche inhaltlicher Erweiterungen SOA (serviceorientierte Architektur) (RUP for SOA) Systementwicklung (RUP SE) Standardsoftware (RUP for COTS) Vor-/Nachteile: Vorteile Gut geeignet für die objektorientierte und modellbasierte Neuund Weiterentwicklung von Individualsoftware Gute Flexibilität und Anpassbarkeit Umfangreiche Erweiterungen verfügbar Klare Handlungsanweisungen, Schablonen und Werkzeug- Mentoren verfügbar Nachteile Standardmodell nur für sehr umfangreiche Entwicklungen einsetzbar (spezielle Konfigurationen für kleinere Projekte) Zuschneiden des RUPs auf individuelle Projektbedürfnisse erfordert sehr gute Kenntnisse des gesamten RUP Keine Trennung der Auftraggeber- und Auftragnehmersicht Varianten: - Vereinfachung: AUP (Agile Unified Process) - OpenUP/Basic (RUP Light): kleinere Teams, mit 3-6 Monaten Entwicklungszeiten - EssUP (Essentiell Unified Process)

8 Scrum Modell: - agiles Prozessmodell - Scrum basiert auf Grundannahmen einer schlanken, hyper-produktiven Produktion und überträgt Erfahrungen aus der Automobilbranche auf den Softwarebereich - Iteratives, inkrementelles Prozessmodell um ein beliebiges Produkt zu entwickeln oder eine beliebige Arbeit zu managen zentrale Werte: - Hohe Produktivität - Hohe Anpassungsfähigkeit - Geringes Risiko und wenig Unsicherheit größerer Komfort für die Projektmitglieder Grundidee: empirische Prozesssteuerung Geführt über ständige Rückkoppelungen Regelmäßige Überprüfung, Adaptierung und Sichtbarkeit des aktuellen Zustandes Ablauf: - Product Backlog: Sammlung aller funktionalen und nichtfunktionalen Anforderungen - Festlegung der Prioritäten - Vor jedem Sprint findet ein Sprint Planning Meeting statt - Übertragung der Anforderungen mit Prioritäten aus dem Product Backlog in den Sprint Backlog - Bestimmung eines Sprint Goals (Ergebnis des Sprints) - Entwicklung in kleinen Scrum Teams (7 +/- 2 Personen) - Entwicklung erfolgt in 30-tägigen Sprints - Während des Sprints sind keine Änderungen an den Anforderungen oder den Zielen erlaubt, ggf. Reduktion der Funktionalität - Tägliches Treffen (Daily Scrum Meeting), geleitet durch den Scrum Master zur Bestimmung des Fortschritts und eventueller Hindernisse - Burndown Chart ermöglicht die Verfolgung des Fortschritts während eines Sprints - Sprint ReviewMeeting am Ende eine Sprints: Präsentation des Inkrements und Überprüfung des Sprint Goals --> Entscheidung: Aufbauen oder Verwerfen - Festlegung des neuen Sprint Backlog und Durchführung des nächsten Sprints - Aufgetretene Probleme werden nicht im Scrum Meeting gelöst, sondern später nur von den Betroffenen diskutiert. - Sprintergebnis wird (nach jeweils 30 Tagen) in einer Besprechung demonstriert und einem Review unterzogen. - Auf der Basis dieser Besprechung und dem product backlog wird der nächst Sprint geplant. - Tägliches Abschätzen der erforderlichen Restaufwände durch Entwickler: Backlog Graph oder Feature Burndown Chart - Keine Festlegung wie die Arbeit unter den Entwicklern aufgeteilt wird (Eigenverantwortlichkeit). Elemente: Product backlog (Dynamisches Dokument) - Sammlung aller funktionalen und nichtfunktionalen Anforderungen - Nach Dringlichkeit geordnete Liste aller Anforderungen - Kann von allen Projektbeteiligten jederzeit eingesehen werden - Änderungen dürfen nur von dem Product Owner vorgenommen werden Daily Scrum - täglich 15 Minuten Besprechung zur selben Zeit am selben Ort, unterstützt vom Scrum-Master - Beantwortung von: Was habe ich seit der letzten Besprechung getan/erreicht? Welche Schwierigkeiten hatte ich zu überwinden? Was will ich bis zur nächsten Besprechung tun? Sprint - schnelle Erreichung des Sprint Goals, das Team entscheidet über die Art und Weise (Prozessmodelle). Keine Vorgaben bzgl. der Dokumentation. Sprint liefert ein potenziell auslieferbares Softwaresystem Increment - Softwareprodukt entsteht in Inkrementen; Spätestens der 2. Sprint liefert ein lauffähiges System Burndown Chart Diagramm in dem vom Scrum Master tagesaktuelle Aufwandsschätzungen für den aktuellen Sprint eingetragen werden Fortschrittskontrolle, Frühzeitiges Erkennung von Problemen und Hindernissen (Sprint Signature)

9 Rollen: Product Owner Erstellung und Priorisierung des Product & Release Backlogs Freihalten des Teams von Störungen und Unterbrechungen Scrum Team Umsetzung der über den Sprint Backlog geforderten Funktionalität Erreichung der über das Sprint Goal bestimmten Ziels Selbst organisierend und autonom Lediglich durch organisatorische Standards und Konventionen sowie durch die gewählte zu realisierende Funktionalität eingeschränkt. Scrum Master Dynamik von Scrum zur ungestörten Entfaltung bringen Umsetzung der Grundsätze und Regeln von Scrum Abschottung des Teams vor äußeren Einflüssen Zusammenfassung Scrum: - Framework, der lediglich Vorgaben hinsichtlich des generellen Ablaufs eines Projektes gibt - Keine Richtlinien bezüglich der zu verwendenden Software- Entwicklungsmethoden oder zu erstellender Dokumente Charakteristika Teams können sich selbst organisieren Produktentwicklung erfolgt über Sprints. Funktionierende Softwaresysteme werden somit regelmäßig geliefert Anforderungen werden in einer Liste gesammelt (Product Backlog) Geänderte Anforderungen werden begrüßt )auch zu einem späten Zeitpunkt des Projektes) keine spezifischen Software-Entwicklungsmethoden vorgeschrieben. Regeln fördern ein agiles Umfeld für die Erstellung von Softwaresysteme Vor-/Nachteile: Vorteile Gut geeignet, wenn die Anforderungen nicht im Voraus festgelegt werden können und chaotische Rahmenbedingungen antizipiert werden müssen Leicht erlernbar und schnell einsetzbar, auf ein paar Seiten Beschreibbar Nachteile Erfolg hängt stark von den Teammitgliedern und ihrer Persönlichkeit ab Keine Hilfestellungen für die Entwicklung von Software Vergleich Monumentale vs. Agile Modelle: Monumentale Modelle Charakterisierung Erstellung vieler Dokumente und Teilprodukte Vorschreibung detaillierter Prozessschritte, Planung! Vorteile Oft gut durchdachte, aufeinander abgestimmte Prozesse, die durch das Entwicklungsgeschehen führen Gleichartiger Aufbau und gleichartige Dokumente für jeden Projekttyp Nachteile Gefahr der Bürokratisierung der Softwareerstellung. Viele Dokumente erschweren die Änderbarkeit (Konsistenzforderung) Prozessbeschreibungen zu Lesen und zu Lernen erfordert hohen Aufwand Agile Modelle Charakterisierung Kompromiss zwischen keinem Prozess und zu viel Prozess Iterative Entwicklung mit häufig ausgelieferten lauffähigen Versionen des Zielsystems (Teilmengen der geforderten Eigenschaften). Vertrauen bilden, sorgfältige Integration und Tests. Stabile kurzzeitige Pläne (Iteration) Vorteile Flexible Anpassung an sich ändernden Anforderungen Codeorientiert, häufige Auslieferung von Teilprodukten Wenig Aufwand bei Änderungen aufgrund geringer Dokumentenanzahl Nachteile Voraussetzung: Teammodell und Mitarbeiterprofil Keine Festpreisverträge möglich - Teamstruktur: Höhere erforderliche Qualifikation beim Einsatz agiler Methoden - Dynamik der Anforderungen: Agile Modelle sind auf Anforderungsänderungen ausgelegt - Entwicklungskultur: Agile Modelle erfordern eine spezielle Entwicklungskultur - Teamgröße: Agile Modelle sind für kleinere Teams besser geeignet (direkte Kommunikation) - Kritikalität: Hoher Anspruch an Prüfung und Nachvollziehbarkeit (agile Modelle weniger geeignet)

10 12 von 54 Folien nicht verwendet und versucht andere zu kürzen. Einsparung: 23% Bei den Modellen ist es schwer zu kürzen. Wenn hier etwas fehlt wird es sonst schwer zu verstehen.