1 Software Engineering

Transkript

1 1 Sftware Engineering Inhalt 1. Vrgehensmdelle Begriff Ziele Kmpnenten eines Vrgehensmdells Vrgehensmdell-Varianten Anwendung der Vrgehensmdells Phasen der Sftwareentwicklung: Phasenmdell Planungsphase Anfrderungsdefinitin und Analyse Entwurf Implementatin und Test Einsatz und Wartung Kriterien für die Auswahl vn Vrgehensmdellen Unterschiedliche Phasenmdell-Typen Wasserfallmdell Cde und Fix-Mdell Evlutinäre Entwicklung Transfrmatische Entwicklung Spiralmdell Clustermdell Prttyping Vergleich Wasserfall, Evlutinäres Mdell und Prtyping The Synchrnize und Stabilize Develpment Mdel Phasenmdell vs. Vrgehensmdell Beschreibung vn Vrgehensmdellen Wartung vn Vrgehensmdellen Standardisierung vn V Mdellen Werkzeuge V-Mdell XT Ziele Vrgehensbausteine Prjektdurchführungsstrategie und Entscheidungspunkt... 16

2 2 Sftware Engineering 2.4. VMdell Philsphie Prjekttypen und Tailring im VMdell XT Schnittstellen zwischen Auftraggeber und Auftragnehmer VMdell Referenz Rllen VMdell Referenz Prdukte VMdell Referenz Aktivitäten Vrgehensbaustein Prjektmanagement Agile Sftwareentwicklung Extreme Prgramming Pair Prgramming Test Driven Develpment RUP Ratinal Unified Prcess Open Surce Sftware-Entwicklung Requirements Engineering Begriff: Anfrderung Zielgruppen Eigenschaften einer guten Anfrderungsspezifikatin Typische Prbleme mit Anfrderungen Requirement Engineering Funktinale und nicht-funktinale Anfrderungen Systemziele vs. Verifizierte nicht-funktinale Anfrderungen Prbleme beim Einsatz natürlicher Sprache Werkzeuge zur Strukturierung Anfrderungsspirale Validierung Kriterien für Anfrderungsprüfung Methden zur Anfrderungsprüfung Evlutin vn Anfrderungen The Requirement Activity Cde Anfrderungsanalyse im VMdell XT Requirement Prcess in RUP Sftware Architekturentwurf Architektursichten Sftware-Architekturen Einflussfaktren Qualitätsanfrderungen: Einfluss der System-Architektur... 35

3 3 Sftware Engineering 4.4. Aktivitäten im Architekturentwurfsprzess Systemstrukturierung: Datenspeichermdell Systemstrukturierung: Client/Server Mdell Systemstrukturierung: Mdell aus abstrakten Maschinen (Schichtenmdell) Steuerungsmdelle Zentrale Steuerung Aufruf/Rückgabe Mdell Managermdell Ereignisbasierte Steuerung Bradcast Mdell Interrupt-basiertes Steuerungsmdell Prinzipien des Architekturentwurfs Mdularisierung Infrmatin Hiding Trennung vn Zuständigkeiten Trennung vn Funktin und Interaktin Inhalte eines Architekturentwurfs Entwurfsziele Kmpnenten Externe Systeme Ressurcen Przesse Betriebsknzept Architekturentwurf eines Bankautmaten Abstraktinsebenen Dkumentatin vn Sftware-Architektur Kmpnentendiagramm Sequenzdiagramme Architekturmuster Pipe-Filter-Architekturmuster Mdel-View-Cntrller Plug-in-Architekturmuster Servicerientierte Architektur (SOA) Qualitätsmanagement Bestandteile der Sftware Qualitätssicherung... 46

4 4 Sftware Engineering Knstruktive (aktive) QS-maßnahmen Analytische (passive) QS-Maßnahmen Begutachtungen Prdukt- und Przessrientiertes QM Prinzip der unabhängigen QS Sftware Testen Begriffe/Klassifikatin Techniken zum Erstellen vn Testfällen Äquivalenzklassenbildung Grenzwertanalyse Entscheidungstabellentechnik Kntrllflussrientierte Testverfahren Datenflussrientierte Testverfahren... 54

5 5 Sftware Engineering 1. Vrgehensmdelle 1.1. Begriff Festlegung, der bei der Entwicklung eines Sftwaresystems durchzuführenden Aktivitäten swie Beziehung zwischen den Aktivitäten Anfrderungen an die Ergebnisse 1.2. Ziele Verbesserung der Kmmunikatin zwischen AG/AN Verringerung Anzahl Wartungsfälle (bessere Prduktqualität) Verbesserung des Wartungsaufwands (leichter verständlich, besser dkumentiert) Verbesserung Systementwicklungsprzess (Einbeziehung der Erfahrungen) 1.3. Kmpnenten eines Vrgehensmdells Resultatstypen Beschreiben Resultate, die erzeugt werden sllen Resultatsstruktur Beschreibt Beziehung, die zwischen Resultate bestehen müssen Aktivitätstypen Beschreiben Aktivitäten die auszuführen sind Aktivitätenstruktur Wann und in welcher Reihenflge die Aktivitäten auszuführen sind Vrgehensmdell-Varianten Dachmdell Enthält alle ntwendigen Aktivitäts- und Resultatstypen Zwecks Adaptierung wird Benutzer gewisse nicht benötigte Teile des Mdells entfernen Kernmdell Enthält, die im jedem Fall benötigten Aktivitäts- und Resultatstypen Muss ergänzen Bausteinmdell Besteht aus Anzahl relativ unabhängiger Teilmdelle 1.5. Anwendung der Vrgehensmdells Für jede knkrete Anwendungsentwicklung muss aus dem Vrgehensmdell knkreter Sftwareentwicklungsprzess abgeleitet werden. Przess Schema 1.6. Phasen der Sftwareentwicklung: Phasenmdell Grundidee: Sftware wird nicht in einem Schritt entwickelt, sndern durchläuft gewisse Phasen Gliederung der langen Laufzeit eines Prjektes in überschaubare Intervalle Phasen Planungsphase Anfrderungsdefinitin/Analyse Implementatin und Test

6 6 Sftware Engineering Einsatz und Wartung Planungsphase Ziel Prüfung, b System hergestellt werden sll Teilaktivität Auswahl des Sftwaresystems, unterstützt durch Trendstudien, Marktanalyse, Frschungsergebnisse, Vrentwicklungen Vruntersuchungen Ist-Aufnahme, wenn Vrgängerprdukt vrhanden Festlegen der Hauptfunktin, Hauptanfrderungsgruppen, wichtigsten Aspekte der Benutzerschnittstellen Durchführbarkeitsuntersuchung Alternative Lösungsvrschläge Technische, öknmische, persnelle Durchführbarkeit Anfrderungsdefinitin und Analyse Definitin der Anfrderungen u.u. Durchführung vn Bedarf und Ist-Analyse Festlegen vn Funktinen, Qualitätsmerkmale Definitin Benutzerschnellstellen Bestimmen vn Entwicklungs- und Zielumgebung Analyse der Anfrderungen Überprüfen der Anfrderungen auf Redundanz, Knsistenz, Vllständigkeit und Durchführbarkeit u.u Vrnahme vn Simulatinen, Durchführen vn Rapid Prttyping Entwurf Grbentwurf Entwicklung einer sftwaretechnischen, rganisatrischen Lösung im Sinne der Systemarchitektur. Bestehend aus Mdulen und Schnittstellen zwischen diesen (auch Umgebung) Feinentwurf (Mdulentwurf) Entwurf benötigter Datenstrukturen und Algrithmen für einzelne Mdule Implementatin und Test Umsetzung eines Systementwurfs in eine ablauffähigen Prgramm(mehrere) Systematisches Testen der Prgramme um Fehler aufzudecken Einsatz und Wartung Fertiggestelltes SW-Prdukt wird beim Anwender installiert, abgenmmen und eingesetzt. Im Laufe der Zeit werden Fehler krrigiert und Anpassungsmaßnahmen durchgeführt. Regelmäßige Sicherung Daten Einrichtung und Pflege vn Benutzerkennungen Verwaltung vn Plattenspeicher Gewährleistung Datenschutz, Erteilung/Überprüfung vn Zugriffsrechten

7 7 Sftware Engineering Benutzerbetreuung, Schulung Erweiterung der Funktinalität Fehlerkrrektur Anpassungsmaßnahmen Kriterien für die Auswahl vn Vrgehensmdellen Analyse der Prjektbegebenheiten Berücksichtigung vn vrhandenem Wissen und Erfahrungen mit Vrgehensmdellen Einarbeitungsaufwand Unklare der sich häufig ändernde Anfrderungen Einschätzung der Prblemstellung Kmplexität der Aufgabe (neuartig, knventinell) Interne Vrgaben Vertragliche Vrgaben Vrhandene Werkzeuge und Methden Analyse der Vrgehensmdelle Sprache, Bekanntheitsgrad, Verfügbarkeit und Kmplexität Ksten der Einführung, Möglichkeiten des Tailrings, Flexibilität Verfügbare Werkzeugunterstützung Unterstützter Prjekttyp 1.7. Unterschiedliche Phasenmdell-Typen Wasserfallmdell jede Aktivität in richtigen Reihenflge und vller Breite vllständig durchzuführen. Am Ende jeder Aktivität steht ein fertiges Dkument Sequentieller Entwicklungsablauf (bevr neu, das andere Ende) Auftraggeberseite ist nur in Definitinsphase vrgesehen. Vrteil Geregelter Ablauf der Phasen Nachteil Immer vllständige sequenzielle Durchführung der Entwicklungsschritte Risikfaktren werden unter Umständen zu wenig berücksichtigt, da zu Beginn festgelegter Entwicklungsablauf durchgeführt wird Cde und Fix-Mdell Evlutinäre Entwicklung Kernanfrderungen definieren Prdukt- Kern, der implementiert wird

8 8 Sftware Engineering Nullversin, dient zur Ermittlung neuer Anfrderungen SW-Prdukt wird stufenweise entwickelt, gesteuert durch Erfahrungen, die AG und Benutzer mit Prdukt machen. Gut, wenn AG Anfrderungen nicht vllständig kennt. Entwicklung ist Cde getrieben, Knzentratin auf lauffähige Prdukte. Vrteile AG erhält in kurzen Zeitabständen einsatzfähige Prdukte Frühzeitiger Einsatz einer eingeschränkten Prduktversin Prdukt wird in überschaubare Zyklen erstellt Krrektur der Neudefinitin der Entwicklungsrichtung möglich. Nachteile Falls Kernanfrderungen fehlen ist eventuell eine kmplette Überarbeitung der Systemarchitektur ntwendig Transfrmatische Entwicklung Spiralmdell Vrgehen bei Verwendung des Spiralmdells 1. Schritt Identifikatin der Ziele des Teilprdukts (Leistung, Funktinalität, Anpassbarkeit) Alternative Möglichkeiten zur Realisierung des Teilprdukts identifizieren (Entwurf A, B, Kauf) Identifikatin vn Randbedingungen, die bei versch. Alternativen zu beachten sind (Ksten, Zeit, Schnittstellen) 2. Schritt Evaluatin der Alternativen unter Berücksichtigung der Ziele und Randbedingungen Bei vrhanden Risiken: Entwicklung einer ksteneffektiven Strategie zur Überwindung der Risiken (Prttyping, Simulatin) 3. Schritt Festlegung des Przessmdells (Kmbinatin möglich) 4. Schritt Planung des nächsten Zyklus inkl. benötigter Ressurcen Review Schritte 1-3 Cmmitment über nächsten Zyklus herstellen Merkmale Risikgetriebenes Mdell Oberstes Ziel: Minimierung des Risiks

9 9 Sftware Engineering Ziele für jeden Zyklus werden aus Ergebnissen des Letzten abgeleitet Keine Trennung vn Entwicklung und Wartung Zielbestimmung umfasst auch Q-Ziele Vrteile Zyklische Überprüfung und u.u erneute Festlegung des Przessablaufs in Abhängigkeit vn Risiken Ein Przessmdell wird nicht für gesamte Entwicklung festgelegt. Integratin anderer Przessmdelle möglich Flexibel Krrektur der Entwicklungsrichtung möglich Nachteile Hher Managementaufwand Wissen über Identifizierung und Management vn Risiken nicht überall vrhanden Geeignet für Risikreiche Prjekte Grßprjekte Neuartige Prjekte, für die nch keine Erfahrung vrliegen Clustermdell Orientiert sich an Bttm-up Vrgehensweise Unterstütz inkrementelle Entwicklung vn Systemen Gesamtaufgabe wird in Cluster geteilt Cluster = Gruppe vn Prgrammen Werden unabhängig vneinander entwickelt Vrgehensmdelle der einzelnen Mdelle können sich überlappen und gegenseitig beeinflussen Einzelne Cluster sind auf Wiederverwendung hin ausgelegt. Bei Realisierung der Cluster wird im Wesentlichen das Wasserfallmdel angewendet. (Übergänge der Phasen aber fließend) Spezifikatin Design und Implementierung (Zusammenfassung der einzelnen Phasen) Validierung und Generalisierung (Sicherstellen der Wiederverwendbarkeit) Prttyping Prblem: fehlende Einbeziehung der Endbenutzer in den Entwicklungsprzess Flgen Fehlerhafte und unvllständige Anfrderungen Geänderte/zusätzliche Anfrderungen, während des Entwicklungsprzesses der erst bei Bedienung des Systems auftreten werden nicht rechtzeitig der gar nicht erkannt. System gehen an den Anfrderungen des Endbenutzers vrbei und stßen auf Ablehnung.

10 10 Sftware Engineering Idee Bereitstellung eines ablauffähigen Mdells an dem Knsequenten vn Entwurfsentscheidungen aufgezeigt werden können Überprüfen erfasster Anfrderungen Benutzer frühzeitig Erfahrung im Umgang mit System sammeln können Demnstratinen technischer Möglichkeiten Charakteristika Reales, lauffähiges, benutzbares System wird in perativer Weise überprüft/bewertet Unvllständig Wird als Reaktin auf Anfrderungen der Benutzer möglichst schnell und wirtschaftlich realisiert Flge vn Arbeitsschritten Entwicklung Überprüfung Bewertung Thrw-Away-Prttyping Vrteile Reduzieren Entwicklungsrisik durch frühzeitige Einsatz vn Prttypen Können sinnvll in andere Przessmdelle integriert werden Durch Werkzeuge schnell erstellt Starke Rückkpplung mit Auftraggeber und Endbenutzer Nachteil Höherer Entwicklungsaufwand Gefahr, dass ein Wegwerf-Prttyp aus Termingründen Teil des Endprdukt wird Werden als Ersatz fehlender Dkumentatin angesehen Vergleich Wasserfall, Evlutinäres Mdell und Prtyping Przessmdell Primäres Ziel Antreibendes Benutzerbeteiligung Charakter Mment Wasserfall Minimaler Managementsaufwand Dkument Niedrig Sequentiell, vll Breite Evlutinär Minimale Entwicklungszeit Cde Mittel Sfrt, nur Kernsystem Prttyping Risikminimierung Cde hch Nur Teilsysteme Kmbinatinsmöglichkeiten Evlutinär Wasserfall nein Evlutinär Prttyping ja Ja

11 11 Sftware Engineering Einsatz vn Prttypen Prblemanalyse: Machbarkeitsstudien Spezifikatin: UI-Prttyp Entwurf: Architektur und Kmpnententyp Implementierung: experimentelle Prttypen The Synchrnize und Stabilize Develpment Mdel Aus Visin Beginnt mit der Visin des Teams: Was sll das Prdukt können? Prduktmanager entwickelt grbe funktinale Spezifikatin für ganzen Prjektablauf Zeitplan hat mehrere Stabilisatinspunkte(Meilensteine) Jeder Punkt repräsentiert Entwicklungszyklus: Design, Cde, Benutzertest, Test, daily builds, debugging, Integratin und Stabilisatin Jeder Subzyklus wird mehrere Male wiederhlt. (Alpha der Betarelease) Die Pufferzeit(in jedem Release) sichert das jedes Team genug Flexibilität hat Marktanfrderungen und Änderungen an System anzupassen Im letzten Meilensteint ist das User Interface gefrren und der Cde kmplett. Letzter Test, Debug und Stabilisatin wird durchgeführt Final Release Anmerkung Nur wenn das Prjekt fertig gestellt ist, ist die funktinale Spezifikatin abgeschlssen. Vs. Wasserfallmdell (hier Spezifikatin bereits anfangs festgelegt)

12 12 Sftware Engineering Vergleich mit Wasserfallmdell Synchrnize und Stabilize Mdel Specificatin, Develpement and Testing are dne in parallel Visin statement is created and specificatin evlves Wasserfallmdell Phase are cmplete sequentielly Cmplete specificatin dcument and detailed design is dne befre cding Priritized feature are build in ¾ milestnes All prduct pieced are built simultaneusly Synchs are dne frequently (daily builds) with intermediate stabilizatin (milestnes) Ship dates are fixed, but there are cmplete release cycles Custmer feedback is cnsidered during develpment Large teamwrk like small teams regardless f prject size One late, large integratin and test phase ccurs at the prject ends An attempt is made t achieve feature and prduct perfectin Custmer feedback serves as input fr feature prjects Many individuals in large functinal grups t scale up prjects 1.8. Phasenmdell vs. Vrgehensmdell Phasenmdell Zerlegt Entwicklungsprzess in Phasen Vrgehensmdell beschreibt detailliert den Ablauf der Phasen in die Resultate 1.9. Beschreibung vn Vrgehensmdellen Zweck Dkumentatin, Arbeitsanweisungen Grundlage für Rechnerunterstützung während Entwicklungsprzess (Aktivitäten Mgmt) Analyse (Vllständig, Widerspruchsfreiheit, Redundanzfreiheit) Ausgangspunkt f. Verbesserungsmaßnahmen Resultatstypen/Resultatsstruktur - Textuell - Tabellarisch - Grafisches Datenmdell (ERP) - Prgramsprachliche Ntatin Aktivitätstypen, Aktivitätsstruktur - textuell - tabellarisch - prgrammsprachliche Ntatin - Patenflussdiagramme - Petrinetze

13 13 Sftware Engineering Beschreibungssprachen für Vrgehensmdelle Frmale Beschreibung: eindeutig/analysierbar Prgrammsprachliche Ntatin: direkt ausführbar (prcess prgramming) Grafische Beschreibung: leicht verständlich aber nicht eindeutig Ideal: KOMBINATION Auswahlkriterien für Beschreibungssprachen Ausdrucksmächtigkeit (Objekte, Aktivitäten, Rllen, Ressurcen, Regeln, Zeitaspekte, Annahmen, Kmmunikatinsaspekte) Möglichkeiten der Visualisierung Ausführbarkeit Detaillierungsgrad Frmulierungsgrad Wartbarkeit Bsp. Semantisches Datenmdell, Petri netze Wartung vn Vrgehensmdellen Initiale Anpassung an die Begebenheiten des jeweiligen Unternehmens Langfristige Wissensakkumulierung V-Mdell ist nicht statisch Darstellung Erfahrungsbasis der SW-Entwicklung des U. Kurzfristige prjektspezifische Adaptierung Durchführung lkaler Anpassungen des etablierten Vrgehensmdells an spezifische Anfrderungen des Prjekt Dynamische Anpassung Während Prjektdurchführung wegen Festgestellter Fehler Neue unvrhergesehene Situatinen Änderung äußerer Bedingungen (Standard, Vrschriften, Vertrags-Partner, neue Werkzeuge) Bewusste Ausklammerung bestimmter Aspekte bei Prjektbeginn Änderungsarten Parametrisierte Änderungen: Mdell enthält Parameter die autmatisch Änderungen durchführen Resultats-Aktivitätennamen Hilfetexte Methden und Werkzeuge Interpretatin Mdifizierte Schablnen Ergänzung und Streichung der Resultats und Aktivitätstypen

14 14 Sftware Engineering Standardisierung vn V Mdellen Ziele AUFTRAGGEBERSICHT - Austauschbarkeit Entwicklerteams - Verringerung Schulungsaufwand - Vergleichbarkeit Angebte AUFTRAGNEHMERSICHT - Nutzung Erfahrung anderer - Verfügbarkeit vn erprbten Methden und Werkzeuge

15 15 Sftware Engineering Werkzeuge Werkzeugtyp Beispiele Spezifikatin Entwurf Implementierung Verifikatin und Validierung Planungs-Werkzeuge Tabellenkalkulatin, Kstenund Aufwandsschätzwerkzeuge x x x x Editren Werkzeuge für das Änderungs- Management Text-, Diagrammeditren, Textverarbeitungsprgramme Werkzeuge zur Verflgung Anfrderungen, Änderungskntrllsysteme x x x x x x x x Werkzeuge für das Knfiguratins- Management Versinskntrllsysteme, Werkzeuge zur Systemerstellung x x Prttyping- Werkzeuge Generatren für Benutzerberflächen x x x Werkzeuge zur Methden- Unterstützung Entwurfseditren, Cdegeneratren x x Sprachverarbeitende Werkzeuge Cmpiler, Interpreter x x Werkzeuge zur Prgrammanalyse Statische und dynamische Analyseprgramme x x Testwerkzeuge Generatren für Testdaten, Prgramme zum Vgl. vn Daten x x Werkzeuge zur Fehlerbehebung Interaktive Debugging x x Dkumentatin- Werkzeuge Reengineering Werkzeuge Seitenlayut-, Bildbearbeitungsprgramme Systeme zur Neustrukturierung vn Prgrammen x x x x x

16 16 Sftware Engineering 2. V-Mdell XT 2.1. Ziele Minimierung vn Prjektrisiken Prjekttransparenz Planbarkeit vn Prjekten Frühzeitige Erkennung vn Abweichungen und Risiken bessere Steuerbarkeit weniger Risik Verbesserung und Gewährleistung der Qualität Definierte Zwischenergebnisse werden überprüft Einheitliche Prduktinhalte lesbarer, verständlicher, überprüfbar Eindämmung der Gesamtksten über den ganzen System/Prjektlebenszyklus Aufwand lässt sich besser einschätzen, kalkulieren und damit steuern Abhängigkeit vn AG und AN geht runter Verminderte Aufwand in anschließenden Prjekten Verbesserung der Kmmunikatin Durch Standardisierung Weniger Reibungsverluste Ziele der Neuentwicklung des V-Mdells XT Verbesserung der Unterstützung vn Anpassbarkeit, Anwendbarkeit, Skalierbarkeit und Änderungs- und Erweiterungsmöglichkeit Berücksichtigung: Standards der Technlgie, Anpassung aktueller Vrschriften/Nrmen Erweiterung der Anwendbarkeit (gesamter Systemlebenszyklus) Einführung rganisatinsspezifischen Verbesserungsprzess 2.2. Vrgehensbausteine Deckt eine knkrete Aufgabenstellung ab im Entwicklungsprzess Festlegung in der Aufgabenstellung Erarbeitende Prdukte Aktivitäten (zur Prdukterstellung) Rllen Vrgehensbaustein ist in sich abgeschlssen (Abhängigkeiten und Querbeziehungen zu anderen sind definiert) Sind die Mdularen Bausteine aus denen das VMdell aufgebaut ist Ein Vrgehensbaustein kapselt Prdukte, Aktivitäten und Rllen ab Ist eine Einheit die unabhängig verwend, veränder- und entwickelbar ist Prjektdurchführungsstrategie und Entscheidungspunkt PDS: definiert die Reihenflge der Prjekt zu erreichenden Frtschrittsstufen Entscheidungspunkt definiert Zeitpunkt an dem Frtschrittsentscheidung (ja/nein) getrffen wird Legt die Menge der Prdukte fest, die fertiggestellt werden müssen

17 17 Sftware Engineering 2.4. VMdell Philsphie Prdukte = Mittelpunkt = Prjektergebnisse P-Durchführungsstrategie und Entscheidungspunkte legen Reihenflge der Prduktfertigstellung fest grundlegende Prjektstruktur Detaillierte Planung und Steuerung wird auf Basis der Bearbeitung und Fertigstellung vn Prdukten durchgeführt Prduktqualität ist überprüfbar durch definierte Prduktanfrderungen und die Beschreibung ihrer Abhängigkeiten 2.5. Prjekttypen und Tailring im VMdell XT Auswahl des Prjekttyps Auswahl anzuwendender Vrgehensbausteine Auswahl der Prjektführungsstrategie und Entscheidungspunkte Tailring mit Prjektmerkmalen Auf Basis der Prjektmerkmale wird ein Anwendungsprfil erstellt Anwendungsprfil legt die Auswahl fest, der Vrgehensbausteine(Aktivitäten, Prdukte) Prjektdurchführungsstrategie(muss nch instanziert werden) Die Begründung der Auswahl liegt in der Festlegung des Anwendungsprfils fest, die im Prjekthandbuch dkumentiert wird Schnittstellen zwischen Auftraggeber und Auftragnehmer

18 18 Sftware Engineering 2.7. VMdell Referenz Rllen Überblick alle Rllen des VMdells Inhalt: detaillierte Rllenbeschreibung (Prdukte, Aktivitäten zugerdnet) Für Prjektabwicklung erfrderlich, MA in Teams und Rllen festzugelegen damit diese gemeinschaftlich den Prjektauftrag realisieren unter den Zeit, Ksten und Qualitätsvrgaben Definitin Rllen Organisatinsunabhängige Definitin Hat Fähigkeiten und Kenntnisse Aufgaben und Befugnisse zugerdnet Basis des Fähigkeitsprfils (Rlle) werden MA ausgewählt Besndere erfrderliche Randbedingungen der Rlle werden in der Rllenbesetzung angegeben. Rllenausprägungen werden jeder Rlle zugerdnet verantwrtlich Für Erstellung eines Prdukts im Ksten, Zeit, Qualität Rahmen Übergabe der erstellten/geänderten Prdukte an das KM Krdinatin beteiligter Rllen Meldung über Beginn/Abschluss einer (Teil-)Aktivität des zu erstellten/ändernden Prdukt/Thema an den P-Admin. mitwirkend Beteiligt an der Erstellung vn Prdukten/Themen Beteiligt an Abstimmung Prdukterstelllung nur durch Mitwirkung Einbringen vn Kenntnissen/Erfahrung vn Prdukten bezüglich Ksten, Zeit, Qualität vranbringen 2.8. VMdell Referenz Prdukte Beschreibt Themen, Prduktgruppen und Prdukte entsprechende den hierarchischen Prduktmdells Zusammenhänge werden durch Prduktabhängigkeiten beschrieben 2.9. VMdell Referenz Aktivitäten Beschreibt entsprechend dem hierarchischen Aktivitätenmdell alle Aktivitäten, Teilaktivitäten und Aktivitätengruppen, gibt Überblick Innerhalb der Aktivitäten wird die Reihenflge der Teilaktivitäten festgelegt (kmplexe werden durch Teilaktivitätenfluss grafisch dargestellt) Dabei bearbeitende Prdukte werden festgelegt detaillierte Anleitung zur Bearbeitung und Beschreibung der Prdukte

19 19 Sftware Engineering Vrgehensbaustein Prjektmanagement Rllen Prjektleiter Operative Leitung Plant, krdiniert, überwacht, steuert Prjektablauf Bebachtet Prjektergebnisse anderer Prjektteilnehmer Event. Nachbesserung Terminüberwachung Regelmäßiger Bericht an Lenkungsausschuss Prjektmanager Verantwrtung ggü Lenkungsauschuss Kntrlle vn Einhaltung der vertraglichen Abmachungen Prjektvertreter nach außen Legt Rahmenbedingungen fest Prdukte und Aktivitäten Prdukt Verantwrtlic her (rllen) Be- Prjektleiter sprechungs- dkument Aktivität Besprechung durchführen Ziel Dkumentatin der Besprechungen, Einladung und Prtkll, Prjektstatusbericht Prjekttagebuch Prjektleiter Prjekttagebuch führen Dkumentatin aller gesammelten Erfahrungen zur Nutzung vn weiteren Prjekten Prjektleiter Prjektstatusbericht Prjektstatusbericht erstellen Regelmäßige Überprüfung des Prjektfrtschritts Prjektabschlussbericht Prjektleiter Prjektabschlussbe richt erstellen Übersicht über Mtivatin, Zielsetzung und erreichte Ergebnisse swie Prjekt gewnnene Erfahrung Prjekthandbuch Prjektleiter Prjekthandbuch erstellen Legt die für das Management ntwendigen Entwicklungen und Anpassungen fest, dient als Infquelle und Richtlinie für alle Prjektbeteiligten Prjektleiter Prjektmanagementinfrastruktur Prjekt- management- Infrastruktur einrichten und pflegen Schätzung Prjektleiter Schätzung durchführen Nutzung eines Knglmerats vn Werkzeugen zur Planung und Durchführung des Prjekts Schätzung des Prjektaufwandes

20 20 Sftware Engineering Risikliste Prjektleiter Risiken managen (identifizieren, bewerten, Gegenmaßnahmen planen) Verwaltung identifizierter Risiken und Festhalten der geplanten Gegenmaßnahmen Prjektplan Prjektleiter Prjekt planen Gesicherte und gerdnete Durchführung des Prjekts, detaillierte Beschreibung des Ablaufs Arbeitsauftrag Prjektleiter Arbeitsauftrag vergeben Instrument für interne Prjektsteuerung enthält Aufgabenstellung, Verantwrtliche und Fertigstellungstermin, anhängig vm Prjektplan Prjektfrtschrittsentscheidungen Prjektmanager Prjektfrtschrittsentscheidung herbeiführen Definitin vn Qualitätsmerkmalen, Überprüfung Prjektfrtschritts, Prtkllierung der Prjektentscheidungen Agile Sftwareentwicklung Feststellung Zunehmende Bürkratie durch zu umfangreiche Vrgehensmdelle Entmenschlichung durch Entwicklungsprzess durch zu detaillierte Planung Schnelle Änderungen der I&K Technlgie Frderung Beschränkung aufs Wesentliche, kein vllständiger Verzicht auf Planung Individuen/Interaktin wichtiger als VMdell und Werkzeuge Prdukt wichtiger als Dkumentatin Vertrauensvlle Zusammenarbeit statt Vertragsverhandlungen Reaktin auf Veränderungen statt Planen Merkmale eines agilen Verfahrens Inkrementell (kleine Releases in kurzen Abständen) Kperativ (Kunde und Entwickler arbeiten eng zusammen) Geradlinig (Methde selbst einfach zu lernen und ändern) Adaptiv (Fähig, auch Änderungen im letzten Mment) Punkte für ein erflgreiches Prjekt bei agiler Sftwareentwicklung Zwei bis acht Persnen in einem Raum Anwender vr Ort Kurze inkrementelle Phasen Vll autmatisierter Test Erfahrene Entwickler

21 21 Sftware Engineering Vergleich Agile Verfahren mit Klassische Verfahren Rllen Agile Verfahren Klassische Verfahren Entwickler Kunden Anfrderungen Verlass auf implizites Wissen der Entwickler Hhe Anfrderungen an die Entwickler Gefahr des fehl- und kurzsichtigen Entscheidens. Bereitschaft zum hhen Einsatz nötig Aktiver, invlvierter Kunde Wissen des Kunden vr Ort muss ausreichen, um Anfrderungen zu beschreiben Wirkungsvll bei sich ständig verändernden Anfrderungen Anfrderungen müssen nicht zu Beginn feststehen Reduzierung der Risiken durch Verlass auf Pläne und Architekturen Experteninterview der Dkumente möglich Kunde erbringt seinen Teil beim Frmulieren der Anfrderungsdkumente Kunde bei Meilenstein und Abnahme invlviert Wirkungsvll bei klaren Anfrderungen zu Prjektbeginn Unflexibel bei Änderungswünschen des Kunden Prjektgröße Effektiv bei kleinen mittelgrßen Prjekten (max. 20 Entwickler) Benötigt räumliche Nähe Zielsetzung Frühe Auslieferungen der Sftware als Ziel Dadurch entstandenes Design skaliert evtl. nicht genug(kurzsichtige Entscheidungen) Wartbarkeit Design und Dkumentatin nur in den Köpfen des Teams verfügbar Smit eher für interne Prjekte geeignet Einsatz bei grßen Prjekten Geringer Kmmunikatinsaufwand bei verteilten Prjekten Krrekte Implementierung der Anfrderungen als Ziel Einsatz bei sicherheitskritischen Prjekten Jede Phase endet mit Dkumentatin Dkumentatin als Grundlage für Wartung und Erweiterung Extreme Prgramming Grundprinzipien Unmittelbare Rückkpplung Streben nach Einfachheit Inkrementelle Weiterentwicklung Qualitätsarbeit leisten Änderungen willkmmen heißen

22 22 Sftware Engineering Regeln des Extreme Prgramming Planning User Stries are written Release planning creates the release schedule Make frequent small releases The Prject is divided int iteratins Iteratin planning stars each iteratin Managing Give each member a dedicated wrk space Set a sustainable pace A stand up meeting starts every day The prject velcity is measured Mve peple arund Fix XP when it breaks Designing Simplicity Chse a system metaphr Use CRC cards fr design decisins Create spike slutins t reduce risks Cding N functinality is added early Refactr wherever whenever pssible The custmer is always available Cde must be written t agreed standards Cde the unit test first All prductin cde is pair prgrammed Only n pair integrates cde at time Integrate ften Set up a dedicated integratin cmputer Use cllective wnership Testing All cde must have unit test All cde pass all unit test befre it can released When a bug is fund tests are created Acceptance tests are created

23 23 Sftware Engineering Iterativ- evlutinäres Mdel Verzicht auf strikten Anfrderungskatalg des Kunden Dafür Berücksichtigung vn Kundenwünschen, die sich nch während der Entwicklung ergeben Entwicklungsprzess durchläuft immer wieder in kurzen Zyklen sämtliche Disziplinen der klassischen Sftwareentwicklung Nur die im aktuellen Iteratinsschritt benötigten Merkmale werde implementiert Durch Verzicht auf reguläres Anfrderungsmanagement nicht für umfangreiche Prjekte geeignet Gefahr: keine belastbaren Abnahmekriterien für das erstellte Prdukt Prbleme bei der Sftwareentwicklung und Lösungen des XP Prblem Nichtbenutzbarkeit aufgrund vn Prgrammierfehlern Lösung durch XP Viele und frühe Tests Nichtbenutzbarkeit aufgrund vn Fehlentwicklung Unwartbarkeit Zeitplan nicht einhaltbar Featuritis Einbeziehung des Kunden in den Entwicklungsprzess Viele und frühe Tests Nur implementieren, was höchstes Nutzen/Aufwand-Verhältnis hat Nur wirklich ntwendigen Kmpnenten implementieren Nutzen vn XP für Kunden Prgrammierer Prjektleitung - Durch kurze Iteratinszyklen und Release-Planung steuernde Einwirkung auf Prjekt möglich - Prdukt passt sich aktuellen Anfrderungen an - Bereits nach kurzer Zeit kann unvllständiges aber funktinstüchtiges Prdukt eingesetzt werden. - Verbesserter Wissensaustausch durch ständig wechselnde Paare - Dadurch besserer Prjektüberblick und mehr Fachwissen - Bessere Steuerungsmöglichkeiten durch Einführung vn Metriken

24 24 Sftware Engineering Pair Prgramming Prgrammzeile wird vn Prgrammiererpaar geschrieben (einer implementiert, der andere prüft) Ziel: bessere Cdequalität Test Driven Develpment Testfälle werden knstruiert vr Implementatin Vrgehen für alle Mdule Testfall wird für Mdul knstruiert dann implementiert Ausführung und Fehlerbehebung Testfälle übernehmen Rlle vn funktinalen Spezifikatin (bei XP nicht vrhanden) Vraussetzung: disziplinierte Entwickler Gefahr: Missbrauch zur Chas Prgrammierung Rahmenbedingungen Vage sich ändernde Anfrderungen Kleine Entwicklerteams Wenn time t market wichtig ist Vermeidet Bürkratie im Entwicklungsprzess RUP Ratinal Unified Prcess Idee: erprbte Ansätze zur SW Entwicklung allgemein nutzbar machen RUP definiert Wrkflws Ablauf parallel der in Phasen Innerhalb Phase sind Iteratinen und inkrementelle Verbesserung möglich Persn übernimmt bestimmt Rlle führt Aktivität aus und das Ergebnis ist Artefakt Guidelines und Templates für Gestaltung der Artefakte werden zu Verfügung gestellt 4 Phasen der Sftwareentwicklung

25 25 Sftware Engineering Phase Ziel Aufgabe Knzeptinalisierung Entwurf Planen und Entscheidungsmöglichkeiten schaffen Erfassen wichtigsten Anfrderungen Validierte, stabile, ausführbare Architektur - Vrstudie Machbarkeit - Definitin Ziele und Abgrenzung - Realisierungsalternativen - Überblick Prblembereich Aufgaben - grbe Prjektplanung - Identifikatin vn Risiken Entwicklung Systemteile hher Prirität und hhem Risik Use-Case-Vervllständigen (Anfrderungsanalyse) Anwendungsarchitektur festlegen Feinplanung Iteratin Knstruktin und Realsierung Stabiles Prdukt ausliefern Inkrementelle Entwicklung des Subsystems und Integratin Test aller Kmpnenten, Schnittstellen und Dienste Dkumentatin Einführung und Betrieb Prdukt in Betrieb nehmen Auslieferung, Installatin, Schulung und Weiterbildung RUP Wrkflws Erfahrungen stehen frmalisiert zur Verfügung Umsetzung/Bedeutung der Schritte muss Fall- zu Fall festgelegt werden (Tailring) 2 Arten Cre Wrkflws Decken Entwicklungsaufgaben ab (Anfrderungsmanagement, Analyse/Design, Implementierung, Test, Einführung, Betrieb) Supprting Wrkflws Unterstützende Aufgaben (Knfiguratinsmanagemet, Prjektmanagement, Infrastrukturbereitstellung) RUP-Iteratinen Kennzeichen vn RUP Kann in jeder Phase vrkmmen

26 26 Sftware Engineering Entspricht kleinem Wasserfallmdell Jede Iteratin mit Release abgeschlssen Jeder Iteratin legt unterschiedliche Schwerpunkte hinsichtlich Wrkflws (iterativ/inkrementelles Verfahren) RUP-Rllen Definiert Verhalten/Verantwrtlichkeiten Verhalten = Aktivität: jede Rlle ist mit Menge vn Aktivitäten verbunden Verantwrtlichkeiten durch Artefakte (Verbindung) (kntrlliert, erstellt, mdifiziert) Persn kann mehrere Rllen übernehmen RUP-Aktivitäten Jede Rlle Aktivität Definiert zu verrichtende Arbeit Aktivität = Einheit vn Arbeitsschritten mit knkreten Ziel Aktivität sll nur mit kleiner Anzahl an Artefakten verbunden sein Können mehrfach ausgeführt werden RUP-Artefakte Aktivitäten besitzen Eingangs- und Ausgangsartefakte Infrmatin veränderbar, prduziert, verwendet vn Przess Stellen Neben- und Teilprdukte des Przesses dar Können unterschiedl. Frmen annehmen Können wiederum aus anderen Artefakten bestehen Entwickelt sich weiter RUP-Best Practices Sftware iterativ entwickeln Anfrderungsmanagement Verwendung kmpnentenbasierter Architekturen Visuelle Mdellierung Verifikatin der Qualität Kntrllieren der Änderungen

27 27 Sftware Engineering Vergleich vn VMdell XT und RUP VMdell XT RUP Orientierung Resultatsrientiert Aktivitätsrientiert Handlungsweise Nicht detailiert beschrieben Detailliert beschrieben Tailring Erweitertes Prjekt Tailring Einfaches Prjekttailring Werkzeug Rlle, Dkumentatin, Tätigkeiten Methden Prjektassistent: sichert Persistenz des Vrgehensmdells Anpassung auch während Prjektlaufzeit möglich Rllen sind Prdukte z u- gerdnet, Rlle-Prdukt- Aktivität Im Mittelpunkt stehen die Prdukte Kein knkreter Methdenvrschlag, stattdessen Vrschlag eines Methdensets, dadurch an Unternehmen anpassbar RUP Builder ermöglicht maßgeschneiderten RUP erstellten Rlle- Aktivität Artefakt Im Mittelpunkt stehen Aufgaben und Tätigkeit Use Case bezgen UML; Vrteil für kurzfristige knkrete Anwendung im Prjekt Inwieweit kann der RUP durch das VMdell XT abgedeckt werden Zurdnung vn RUP-Meilensteinen zu VMdell XT Entscheidungspunkten Knzept Entscheidungspunkte VMdell XT flexibler als Knzept Phasen und Meilensteine Abdeckung RUP Elemente mit VMdell XT Vrgehensbaustein RUP fasst Aktivitäten und Rllen in Wrkflws zusammen VMdell XT gruppiert diese Elemente in Vrgehensbausteinen Abdeckung der RUP-Artefakte mit VMdell XT Prdukten Artefakte haben nur teilweise Entsprechung im VMdell XT Abdeckung RUP durch VMdell XT Prjektdurchführungsstrategien RUP: iterative Vrgehensweise der einzelnen Phasen Prjektdurchführungsstrategie: inkrementelle Systementwicklung

28 28 Sftware Engineering Open Surce Sftware-Entwicklung Merkmale Kein VMdell sndern Menge vn Regeln für Entwicklung vn Sftware in sehr grßen, dezentralen Teams Vergleichbar mit Spiralmdell Ausgangspunkt ist die Minimalversin eines Prduktes dessen Cde öffentlich und kstenls ist Für Änderungen und Nutzung der Prgramme werden Regeln festgestellt Vrteile Keine Lizenzgebühren für Anwender Surce Cde wird mit geliefert Nachteile Keine Garantie Funktinalität/Haftung Individuelle Anpassung schwer durchzuführen Anpassungen möglich Unabhängigkeit Anwender / SW-Anbieter Effektive schnelle Fehlerbehandlung Ineffiziente Frm der Fehlerbehandlung Fehlerbehandlung direkt Surce Cde Wenig Entwurfsdkumente Qualitätssicherung durch Vielzahl Entwickler Erzwingt mdulare Systementwicklung mit relativ kleinen Mdulen Unüberschaubare Anzahl an untersch. Versinen Benutzerfreundlichkeit vs. Technische Eleganz 3. Requirements Engineering 3.1. Begriff: Anfrderung 2 Interpretatinen Abstrakte, allg. Fragestellung eines Dienstes, den das System leisten sll. Detaillierte, mathematisch-frmale Spezifikatin eines Systemdienstes. Zweck Typen Basis für Ausschreibung Vertrag (Interpretatinsspielraum lassen, Lastenheft) Basis für Vertrag (genau, Pflichtenheft) Anfrderungen an die zu entwickelnde Sftware Anfrderungen an den Entwicklungsprzess Aussagen in natürlicher Sprache und Diagramm (Beschreibung der Dienste und Randbedingungen) Geschrieben für Kunden Strukturiertes Dkument (Festlegung der Dienste und Beschränkung) Definiert Was sll implementiert werden Teil des Vertragen AG/AN

29 29 Sftware Engineering Zielgruppen Benutzeranfrderungen - Endbenutzer System - Techniker auf Kundenseite - Systemarchitekten - Manager auf Kundenseite - Manager der SW-Hersteller Systemanfrderungen - Endbenutzer System - Techniker auf Kundenseite - Systemarchitekten - Sftwareentwickler (Was sll das System tun, nicht wie Implementatin, Trennung in praxi schwierig) Eigenschaften einer guten Anfrderungsspezifikatin Krrekt Knsistent Eindeutig Vllständig Änderbar Gewichtet Verifizierbar Nachvllziehbar Typische Prbleme mit Anfrderungen Kmmunikatinsprbleme Mangelnde Abstimmung zwischen System und Sftwareentwicklungsprzess Keine Trennung System/Benutzeranfrderungen Unklare Verantwrtlichkeiten Vermischung Entwurfsentscheidungen Häufig Änderungen Schlechte Dkumentatin Mangelnder Bezug zum Testen 3.2. Requirement Engineering Przess Dienste zu ermitteln, die der Kunde braucht und die Rahmenbedingungen unter welchen es arbeitet und sich weiterentwickelt Anfrderungen selber sind Beschreibung der Systemdienste und die Rahmenbedingungen, die während des Przesses auftauchen Mderne Sicht Iterativer Przess, der den gesamten Lebenszyklus eines Sftwaresystems begleitet Traditinelle Sicht Einmalige Phase zu Beginn des Entwicklungsprzesses Funktinale und nicht-funktinale Anfrderungen Funktinale Anfrderungen Aussagen zu Diensten, die das System leisten sll bspw. Reaktin auf Eingaben, Verhalten des Systems in bestimmten Situatinen Was sll das System nicht tun Beschränkungen angebtener Dienste Nicht-funktinale Anfrderungen Prduktanfrderungen: legen Verhalten des System fest

30 30 Sftware Engineering Beispiele Antwrtzeiten Für die Erledigung einer Aufgabe Last Vn Daten Vn Benutzer Hardwareanfrderungen Rechnerkapazität Speicherkapazität Übertragungskapazität Zuverlässigkeit Verfügbarkeit Maximale Ausfallzeit Benutzbarkeit Verständlichkeit Erlernbarkeit Prtierbarkeit Anpassbarkeit in andere Umgebung Austauschbarkeit Unternehmensanfrderungen: Ergeben sich aus Plitik und Arbeitsweise des Unternehmens (Kunde/Entwicklerseite) Technisch: Plattfrmen, Schnittstellen, Nachbarsysteme Organisatrisch: Przesse und Organisatinsfrmen, die unverändert bleiben müssen Externe Anfrderungen: ergeben sich aus Faktren außerhalb des Systems und aus Systementwicklungsprzess Nrmativ: Gesetze, Verrdnungen, Nrmen Kulturell: Sprache, Gebräuche, Traditinen Besnderheiten sind wichtiger als funktinale Anfrderungen (können ganzes System lahmlegen bei nicht-erfüllung) Nicht gut Überprüfbar Systemziele vs. Verifizierte nicht-funktinale Anfrderungen Systemziel: Aussagen über allgemeine Ziele des Systems, schwer zu quantifizieren/verifizieren Verifizierte nicht-funktinale Ziele: beinhaltet Maß, überprüfbare Aussage

31 31 Sftware Engineering Prbleme beim Einsatz natürlicher Sprache Mehrdeutigkeiten Ungenauigkeiten Redundante Ausdrucksmöglichkeit Unzureichende Strukturierung Werkzeuge zur Strukturierung Mindmap Excel Geschäftsprzess-Mdell Use Cases Anfrderungsspirale Validierung Sll zeigen, das Anfrderungen das System definieren, die Kunde haben will Flgeksten Nicht-Erkennung sind hch Validierung und Früherkennung Kriterien für Anfrderungsprüfung 1) Eindeutig? a. Gibt es Aussagen, die stärker, schwächer der gar widersprüchlich zu dieser ist? 2) Präzise? a. Werden klar definierte Begriff verwendet? Ist alles innerhalb der Aussage klar beschrieben? 3) Begrenzt? a. Klare mathematische Grenzen? 4) Für alle Beteiligten verständlich? a. Benutzer und Entwickler? 5) Herkunft/Begründung klar beschrieben? a. Wies sll Anfrderungen erfüllt werden? 6) Gibt es Risiken bzgl. Der Realisierung und Stabilität des Systems? 7) Ist die Aussage Überprüfbar? Beispiel: "Die Antwrtzeit des Systems sll für alle kritischen Transaktinen immer zumutbar sein 1. Ja, die Aussage selbst enthält keine Widersprüche. Snst liegen keine weiteren Infs vr. 2. Nein, alle kritischen Transaktinen ist nicht weiter definiert. Alternative: Die Antwrtzeit des Systems sll für alle Einfüge-, Aktualisierungs- und Lösch- Transaktinen zumutbar sein. 3. Nein, zumutbare Antwrtzeit ist keine klare Schranke. Alternative: Die Antwrtzeit des Systems sll für alle Einfüge-, Aktualisierungs- und Lösch-Transaktinen weniger als 3 Sekunden betragen. 4. Ja, nach Verbesserung in 2. und 3.

32 32 Sftware Engineering 5. Nicht angegeben, muss ergänzt werden, z. B. zeitkritische Anwendung. 6. Keine Angaben, muss nch ergänzt werden vn Entwicklern. 7. Es fehlen nch die äußeren Umstände für die Messung. Alternative: Die Antwrtzeit des Systems sll bei 25 gleichzeitigen Benutzern für alle Einfüge-, Aktualisierungs- und Lösch-Transaktinen weniger als 3 Sekunden betragen. Endversin: Die Antwrtzeit des Systems sll bei 25 gleichzeitigen Benutzern für alle Einfüge-, Aktualisierungs- und Lösch-Transaktinen weniger als 3 Sekunden betragen, da es sich um eine zeitkritische Anwendung handelt Methden zur Anfrderungsprüfung Anfrderungsreview Anfrderungen werden vn Team vn Gutachtern analysiert vn Hand Prttypen Endbenutzer/Kunde wird funktinsfähiges Mdell gegeben anhand geprüft werden kann Testfallerzeugung Wenn Test nur unter grßen Aufwand der gar nicht zu entwerfen ist Anfrderungen zu schwierig zu implementieren überdenken!! Autmatische Knsistenzanalyse Wenn Anfrderungen in frmaler Ntatin ausgedrückt Werkzeuge zum Testen der Knsistenz können verwendet werden Evlutin vn Anfrderungen