Softwaretechnik: Vorlesung: Vorgehensmodelle PDF

Vorlesung Softwaretechnik 2. Vorgehensmodelle Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Warum? Was? Wie? Wo...

Vorlesung Softwaretechnik 2. Vorgehensmodelle Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Warum? Was? Wie? Wozu? Selbst überlegen, welches Modell für Sie Es werden gut anwendbar ist Betrachten verschiedene, Die wichtigsten Vertreter problemadäquate Prozessschritte, Vorgehensmodelle in kennenlernen Akteure, zeitliche Verläufe Fragen stellen beim der Praxis angewandt Bewerbungsgespräch und beurteilen ob Sie damit arbeiten können/wollen 2 Software Engineering | RWTH Aachen Softwaretechnik 2. Vorgehensmodelle 2.1 Einleitung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Literatur: Sommerville 1.2 Aktivitäten in der Softwareentwicklung Trennung der Aktivitäten: − zeitlich abgegrenzten Phasen − Analyse und der darin stattfindenden − Entwurf − Implementierung − inhaltlich bestimmten Aktivitäten. − Test (einschließlich Integration, synonym: Validierung) − Deployment (Installation, Schulung) − Evolution (incl. Wartung) − und viele weitere (Versionsmanagement, Reviews, Tooling, Variantenmanagement, Prozessoptimierung,...) 4 Software Engineering | RWTH Aachen  Vorgehensmodelle …organisieren einen Entwicklungsprozess in strukturierte Abläufe − Methoden und Techniken − auftretende Aufgabenstellungen und Aktivitäten in einer sinnfälligen logischen Ordnung darzustellen. Vorgehensmodelle sind organisatorische Hilfsmittel, die für konkrete Projekte individuell angepasst werden und in die konkrete Maßnahmenplanung überleiten. Bekannte Vorgehensmodelle? − V-Modell, RUP − Agile Softwareentwicklung, Extreme Programming, Scrum,... discuss − OMT, OOSE (Jacobson), − Open Source (als Vorgehensweise), Hacking 5 Software Engineering | RWTH Aachen Arten von Vorgehensmodellen Klassische Vorgehensmodelle − Wasserfall Model − V-Modell (Berry Boehm + Deutsche Norm) − Rational Unified Process (RUP) − Spiral-Modell Agile Vorgehensmodelle − Extreme Programming (XP) (Kent Beck) − Crystal (Alistair Cockburn) − Kanban (Taiichi Ohno - Toyota) − Scrum (Ken Schwaber, Mike Beedle) − Agile Modeling (Scott Ambler) − Adaptive Software Development (Peter Coad) 6 Software Engineering | RWTH Aachen Softwaretechnik 2. Vorgehensmodelle 2.2 Klassische Vorgehensmodelle Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Das klassische Wasserfall-Modell Analyse Produkt- definition Entwurf Entwurfs- Spezifikation Implementierung Code Test, geprüfter Code Integration Wartung Änderungswünsche W. Royce (1970) 8 Software Engineering | RWTH Aachen Ungefähre Verteilung des Arbeitsaufwands Analyse Produkt- 10 % definition 20 % Entwurf Entwurfs- Spezifikation 20 % Implementierung Code 50 % Test, geprüfter Code Integration Wartung Änderungswünsche W. Royce (1970) 9 Software Engineering | RWTH Aachen Qualitätssicherung im V-Modell Analyse Testfälle Abnahmetest Grobentwurf Testfälle Systemtest Feinentwurf Testfälle Integrationstest Implementierung Modultest Boehm 1979 (erstes, altes „V-Modell“) 10 Software Engineering | RWTH Aachen Evolutionäre Entwicklung Typisch für kleinere Projekte oder experimentelle Systeme Zunehmend auch für größere Projekte angewendet Aufgabe Analyse Prototypen, Vorversionen Entwurf Validierung Implementierung 11 Software Engineering | RWTH Aachen Rational Unified Process (RUP) Der Rational Unified Process hat vier Phasen: − Entstehung (Inception) – Definiert den Rahmen des Projekts − Ausarbeitung (Elaboration) – Planung des Projekts, Spezifikation der Features, Grundlegende Architektur − Erstellung (Construction) – Erstellung des Produkts − Übergang (Transition) – Einführung des Produkts in der Endbenutzer-Community Meilensteine 12 Software Engineering | RWTH Aachen RUP | Zweidimensionales Modell Zeit Entstehung Ausarbeitung Erstellung Übergang (inception) (elaboration) (construction) (transition) Analyse Entwurf Implementierung Test Konfigurations- management Projekt- management Tätigkeit Rational Unified Process 1999 (Jacobson et al., Kruchten) 13 Software Engineering | RWTH Aachen RUP | Aufwandsverteilung und Schwerpunkte Zeit Entstehung Ausarbeitung Erstellung Übergang (inception) (elaboration) (construction) (transition) Analyse Entwurf Implementierung Test Konfigurations- management Projekt- management Tätigkeit Rational Unified Process 1999 (Jacobson et al., Kruchten) 14 Software Engineering | RWTH Aachen Aufwandsverteilung in Iterationen Prozess Business Modeling Inception Elaboration Construction Transition Phasen Workflows Requirements Analysis & Design Implementation Test Deployment Unterstützende Configuration Mgmt Workflows Management Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Environment Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterationen 15 Software Engineering | RWTH Aachen Softwaretechnik 2. Vorgehensmodelle 2.3 Agile Vorgehensmodelle Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ eXtreme Programming (XP): eine agile Methode Konsequente evolutionäre Entwicklung in sehr kleinen Inkrements Tests + Programmcode sind das Analyseergebnis, das Entwurfsdokument und die Dokumentation. Code wird permanent lauffähig gehalten Diszipliniertes und automatisiertes Testen als Qualitätssicherung Paar-Programmierung als QS-Maßnahme Refactoring zur evolutionären Weiterentwicklung Codierungsstandards Aber auch: Weglassen einiger traditioneller Aktivitäten − kein explizites Design, ausführliche Dokumentation, Reviews „Test-First“-Ansatz − Zunächst Anwendertests definieren, dann den Code dazu entwickeln Konsequenz: nur für kleinere Projekte geeignet 17 Software Engineering | RWTH Aachen Scrum (engl. „Gedränge“): eine agile Methode inkrementell und iterativ Komplexität durch drei Prinzipien reduzieren: − Transparenz: Fortschritt / Probleme täglich festhalten − Überprüfung: iterativ werden Funktionen geliefert und beurteilt. − Anpassung: flexibel Anforderungen bewerten & ändern Drei Rollen − Product Owner, Entwicklungsteam, ScrumMaster Aktivitäten: − Sprint Planning, Sprint Review, Sprint-Retrospektive und Daily Scrum Alle Aktivitäten in Scrum sind zeitlich fest beschränkt („timeboxed“), also keine klassischen Meilensteine 18 Software Engineering | RWTH Aachen Scrum Artefakte − Product Backlog − Sprint Backlog − auslieferbares Produktinkrement Sprint − zeitlich begrenzte Phase, um das Produkt zu entwickeln Sprint Backlog − Liste der zu realisierenden User Stories Quelle: https://www.neonrain.com/agile-scrum-web-development/ 19 Software Engineering | RWTH Aachen Scrum Burndown Chart: − Zeigt Ist- und Planung der Zielerreichung an. 20 Software Engineering | RWTH Aachen Continuous Integration Ständiges, automatisiertes Integrieren und Testen des Systems Zerteilung der großen Integrationsaufgabe in kleine Einheiten Möglich dank − Versionsverwaltung − Build-Automatisierung − Automatischer Testfallausführung Regelmäßiges Einchecken in kurzen Schritten System muss nach jedem Einchecken − zu kompilieren sein − Tests bestehen Quelle: https://www.silverstripe.org/blog/developers-how-we-use- continuous-integration-at-silverstripe/ 21 Software Engineering | RWTH Aachen DevOps Development and Operations − Software Development/ Engineering (Dev) − Software Operations (Ops) ▪ “A process of putting into use, and supporting end user(s) in the use of software production in operational environment. Its activities include: installation, upgrade, migration, operational control, monitoring, configuration management, alerting , availability and support.” [Lwakatare 17] − Getrennten Rollen wie Entwicklung, IT-Betrieb, Qualitätstechnik und Sicherheit, müssen zusammenarbeiten − Methoden: ▪ CI/CD ▪ Versionskontrolle ▪ Agile Softwareentwicklung ▪ Infrastruktur als Code (IaC) ▪ Konfigurationsverwaltung ▪ Continuous Monitoring 22 Software Engineering | RWTH Aachen Softwaretechnik 2. Vorgehensmodelle 2.4 Vergleich der Vorgehensmodelle Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Aktivitäten in der Software Entwicklung Anforderungsermittlung Parallel dazu verfeinert Systemmodellierung Projekt- Management Analyse Grobentwurf Konfigurations- Entwurf Feinentwurf Management Implementierung Unit-Test Varianten/Versions- Management Test, Integration Integrations-Test Änderungs- System-Test Management Wartung Deployment Tool- Management Schulungen 24 Software Engineering | RWTH Aachen Klassische vs. Agile Prozesse Wasserfall Modell (V-Model, RUP) Agile Prozesse Aktivitäten sind chronologisch in Aktivitäten sind kurze Sprints/ Intervalle Phasen unterteilt Leben von vielen kleinen Iterationen Analyse Analyse Zeit / Fortschritt Entwurf Entwurf 70% Fortschritt 0% verwendbar Implementierung Implementierung Test, Integration Test, Integration Wartung Wartung 30% Fortschritt 30% verwendbar Zeit / Fortschritt 25 Software Engineering | RWTH Aachen Literatur (neben Balzert, Sommerville) Philippe Kruchten: − Rational Unified Process. Addison-Wesley. 2000 Kent Beck: − Extreme Programming Explained. Addison-Wesley. 1999 Jeff Sutherland, Ken Schwaber: − The Scrum Guide Klaus Leopold, Siegfried Kaltenecker − Kanban in der IT: Eine Kultur der kontinuierlichen Verbesserung schaffen. Carl Hanser Verlag. 2018 Testframework JUnit − www.junit.org 26 Software Engineering | RWTH Aachen Was haben wir heute gelernt? Unterschiedliche Anwendung in der Vorgehensmodelle Arten Zeitlicher Verlauf Praxis … organisieren einen Wasserfall bzw. V- Sequenziell, Meist agil Entwicklungsprozess Modell chronologisch …aber in in strukturierte Rational Unified Agil, iterativ unterschiedlichen Abläufe Process Ausprägungen und Abwandlungen … sind eXtreme organisatorische Programming Hilfsmittel, die an das jeweilige Projekt Scrum angepasst werden Kanban müssen 27 Software Engineering | RWTH Aachen Softwaretechnik Analyse Entwurf Implemen- Test, Wartung tierung Integration 2.5 Einschub: Testfälle mit JUnit aus: 10. Qualitätsmanagement Prof. Bernhard Rumpe Literatur: Sommerville 19-20 Software Engineering Balzert Band II, LE 14-15 RWTH Aachen Vorgezogener Einschub: Speziell: Logisch gehört dieser Robert V. Binder: Testing object-oriented http://www.se-rwth.de/ Einschub zu systems, Addison-Wesley 2000 10. Qualitätsmanagement Was ist Testen? „Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.“ - Glenford J. Myers (1979) - Testen ist eine Form der dynamischen Qualitätssicherung: das Programm wird ausgeführt „Program testing can be used to show the presence of bugs, but never to show their absence!“ - Edsger W. Dijkstra (1970) - Vollständiges Testen ist unmöglich Testen kann die Korrektheit eines Programms nicht beweisen Ein Test führt das Programm aus und ist erfolgreich, wenn Fehler gefunden werden 29 Software Engineering | RWTH Aachen Inkrementelles Testen Programmierer testen meist nicht gerne. − „Testen ist zerstörerische Tätigkeit.“ − Zu spätes Testen führt zu komplizierten Fehlersuchen! Inkrementelles Testen / Test-First-Ansatz: Tests entstehen parallel zum Code (oder sogar vor dem Code) Programmierer schreiben Tests für praktischen Nutzen: − Klare Spezifikation von Schnittstellen − Beschreibung kritischer Ausführungsbedingungen − Dokumentation von Fehlerbeseitigung − Festhalten von notwendigem Verhalten vor größerem Umbau ("Refaktorisierung") Tests archiviert und automatisch ausführbar Weitere Information: − K. Beck, E. Gamma: Programmers love writing tests (JUnit) − K. Beck: Extreme programming explained, Addison-Wesley 2000 30 Software Engineering | RWTH Aachen Testfall-Definition mit JUnit Testen ist wichtige Qualitätssicherungsmaßnahme Wichtig: wiederholbare, automatisierbare Testfallausführung Unit Test − Testen von (kleinen) Einheiten in Isolation von anderen (seiteneffektfrei) − Unit Test in OO ist typischerweise ein Methodentest White Box Test − Implementierungsdetails des Prüflings sind bekannt JUnit − kleines Test Framework − hat für Java schnell weite Verbreitung gefunden − Testfälle werden in Java kodiert (kein Sprachwechsel für Tests) − Framework kümmert sich um automatisierte Testfallausführung 31 Software Engineering | RWTH Aachen JUnit & Test-First Test-First ist Grundsatz von XP (eXtreme Programming) „Test a little, code a little“ − Wir überlegen uns erste Testfälle für die geforderte Funktionalität. − Wiederholung der Schritte 1-6: XP 1. Auswahl des nächsten Testfalls. 2. Wir entwerfen einen Test, der zunächst fehlschlagen sollte. 3. Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt (Signatur). 4. Wir prüfen, ob der Test fehlschlägt. 5. Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte. 6. Wir prüfen, ob der Test durchläuft. − Die Entwicklung ist abgeschlossen, wenn uns keine weiteren Tests mehr einfallen, die fehlschlagen können. 32 Software Engineering | RWTH Aachen Anwendungsbeispiel: Konto Wir überlegen uns erste Testfälle − Erzeuge neues Konto (Account) für Kunden − Mache eine Einzahlung (deposit) − Mache eine Abhebung (withdraw) − Überweisung zwischen zwei Konten,... 1. Auswahl des nächsten Testfalls: Erzeuge Konto 33 Software Engineering | RWTH Aachen 2. Wir entwerfen einen Test 21 // file AccountTest.java Java 22 import org.junit.*; Ausführung der Tests durch Eclipse Plugins, 23 public class AccountTest { CI-System oder Kommandozeile möglich: 24 25 @Test 26 public void testCreateAccount() { 27 Account account = new Account("Anna"); Kommandozeile: 28 assertEquals("Anna", account.getCustomer()); − java -cp junit.jar 29 assertEquals(0, account.getBalance()); org.junit.runner.JUnitCore 30 } AccountTest 31 } Annotation markiert Konventionen, z.B.: Testmethode − Testmethoden beginnen mit „test“: d.h. wird automatisch von − Sie führen die getesteten Methoden aus und prüfen das assert*-Methoden JUnit aufgerufen Ergebnis prüfen Ergebnisse 34 Software Engineering | RWTH Aachen 3. Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt 1 // file Account.java Java 21 // file AccountTest.java Java 2 public class Account { 22 import org.junit.*; 3 public Account(String customer) { 23 public class AccountTest { 4 } 24 5 public String getCustomer() { 25 @Test 6 return null; 26 public void testCreateAccount() { 7 } 27 Account account = new Account("Anna"); 8 public int getBalance() { 28 assertEquals("Anna", account.getCustomer()); 9 return 42; 29 assertEquals(0, account.getBalance()); 10 } 30 } 11 } 31 } Die zu testende Klasse kennt die Testklasse nicht und kann daher auch ohne Tests eingesetzt werden. 4. Wir prüfen, ob alles compiliert und der Test fehlschlägt: Übersetzbarkeit bedeutet: Signaturen + Default-Return- Werte sind vorhanden 35 Software Engineering | RWTH Aachen 5. Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte 1 public class Account { Java 21 // file AccountTest.java Java 2 private String customer; 22 import org.junit.*; 3 private int balance; 23 public class AccountTest{ 4 public Account(String customer) { 24 5 this.customer = customer; 25 @Test 6 this.balance = 0; 26 public void testCreateAccount() { 7 } 27 Account account = new Account("Anna"); 8 public String getCustomer() { 28 assertEquals("Anna", account.getCustomer()); 9 return customer; 29 assertEquals(0, account.getBalance()); 10 } 30 } 11 public int getBalance() { 31 } 12 return 0; 13 } 14 } 6. Wir prüfen, ob der Test durchläuft: Im Beispiel werden deshalb Konstruktor, getCustomer und die notwendigen Attribute (customer, balance) definiert. 36 Software Engineering | RWTH Aachen Weiterer Test: Abheben 1 public class AccountTest{ Java Initialisieren: @Before – Methode wird vor jedem Test aufgerufen 2... Aufräumen: @After – Methode wird nach jedem Test aufgerufen 3 private Account account; 4 5 @Before 6 protected void setUp() { Mehrere „tests“ in einer Testklasse sind möglich 7 account = new Account("Anna"); 8 } 9 @Test 10 public void testWithdraw() throws Exception { 11 account.deposit(100); 12 account.withdraw(60); Achtung: Dieser eine Test reicht nicht aus, 13 assertEquals(40, account.getBalance()); um Randfälle abzudecken! 14 try { 15 account.withdraw(46); 16 fail("Missing AmountNotCoveredException"); 17 } catch (AmountNotCoveredException expected) {} 18 } 19 } Auch erwartete Exceptions können getestet werden 37 Software Engineering | RWTH Aachen TestSuite – Testfälle organisieren 1 import org.junit.runners.Suite; Testklassen können in TestSuiten organisiert werden Java 2 import org.junit.runner.RunWith; 3 4 @Suite.SuiteClasses({AccountTest.class,...}) 5 public class AllMyTests { 6 Wird einmalig vor Ausführung der Testfälle 7 @BeforeClass in den Testklassen ausgeführt 8 public static void myInitTestSuite(){ 9 // Daten für Testsuite vorbereiten 10 } 11 @AfterClass Wird nach Ausführung aller Testfälle ausgeführt 12 public static void myTearDowntestSuite(){ 13 // Daten nach Ausführung der Testsuite aufräumen 14 } 15 } 38 Software Engineering | RWTH Aachen Übersicht Junit Annotationen Annotationen für Klassen − @RunWith(Suite.class) // deklariert die Klasse als Testsuite − @Suite.SuiteClasses({..}) // deklariert die Testklassen der Suite Annotationen für Methoden − @Test // kennzeichnet einen Test public void testWithdrawCash(){..} − @Before // wird vor jedem Test ausgeführt public void initDataset(){..} − @After // wird nach jedem Test ausgeführt public void resetDataset(){..} − @BeforeClass // wird einmalig, vor dem ersten Test ausgeführt public static void initTestDatabase() {..} − @AfterClass // wird einmalig, nach dem letzten Test ausgeführt public static void cleanupTestDatabase(){..} 39 Software Engineering | RWTH Aachen