Projektplan: Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Tätigkeiten bei der Softwareentwicklung Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Ein an den Haaren herbeigezogenes Beispiel aus der Fertigungstechnik (siehe [Klaus Pohl, erstes Kapitel]) Eine Firma stellt Diaprojektoren her. Wenn ein Kunde an einem Gerät einen Defekt feststellt, dann kann er das Gerät innerhalb von 14 Tagen anstandslos umtauschen oder reparieren lassen. Die Firma ist für Kulanz und guten Kundendienst berühmt. Alle sind glücklich und zufrieden. Eines Tages stellt das Controlling fest, dass der Absatz zurückgeht. Die Projektoren kosten ungefähr das Doppelte wie vergleichbare Geräte der Konkurrenz. Man stellt fest, dass fast die Hälfte der Kosten vom Kundendienst verursacht werden. Der häufigste Defekt sind kaputte Birnen bei 16 % der neu ausgelieferten Geräte. Ein Techniker fährt zum Kunden und ersetzt die Birne. Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Fortsetzung Beispiel Die Firma führt eine explizite Abschlusskontrolle aller Geräte vor Auslieferung ein. Eine eigene Testabteilung prüft alle Geräte und führt gegebenenfalls Reparaturen durch. Bei 14 % der Geräte ersetzt die neue Testabteilung kaputte Birnen. Die Fehlerrate bei Kunden sinkt auf 2%. Die Kundendienstabteilung kann um 87,5 % verkleinert werden. Alle sind glücklich und zufrieden. Nur der Absatz geht immer noch zurück. Die Projektoren kosten ungefähr 50 % mehr als vergleichbare Geräte der Konkurrenz Man wirbt zu horrenden Kosten einen Mitarbeiter der Konkurrenz ab und stellt fest, dass die eigene Test- und Reparaturabteilung 33 % der Mitarbeiter beschäftigt, bei der Konkurrenz sind es nur 5 %. Die meiste Zeit geht für’s Birnenwechseln drauf. Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Fortsetzung Beispiel Die Firma überprüft den Mitarbeiter, der die Birnen in der Fertigung einbaut. Direkt nach dem Einbau sind nur 1 % der Birnen defekt. Weitere Überprüfungen ergeben, dass die Birnen auf dem Weg von der Vormontage zur Gehäusemontage kaputt gehen: Die Stufe im Förderband wird ausgebaut. Die Fehlerrate bei der Testabteilung sinkt auf 1 %. Die Testabteilung kann auf 7 % ihrer Größe verkleinert werden. Alle sind glücklich und zufrieden, nur . . . Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Kernaussagen des Projektmanagements und der Qualitätssicherung Wartung und Fehlerbehebung sind die Hauptkostenpunkte  Qualitätsverbesserung senkt die Kosten Qualitätsverbesserung muss am Herstellungsprozess ansetzen ( Qualitätssicherung und Projektmanagement sind eigentlich das gleiche) Grundlagen für die Prozessverbesserung sind: Messungen, Metriken, Controlling, Prüfungen, . . . klar definierte Prozesse => projektübergreifende Vergleichbarkeit (formale Prozessdefinition) Planung und Überwachung der Prozessausführung Management Commitment … Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Qualitätssicherungsmaßnahmen: Debuggen ≈ 1 Fehler pro Woche Testen ≈ 1 Fehler pro Woche Reviews ≈ 1 Fehler pro Woche Verifikation ≈ 1 Fehler pro Woche Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Merkmale 1- 5 von Fagan’s Reviewmethode Michael Fagan, “Erfinder” der Reviewtechnik, IBM ca. 1975 1. überall im Entwicklungsprozeß 2. alle Arten von Fehlern 3. ohne big boss 4. mehrere Einzelschritte 5. Checklisten 1. nicht nur Codereading, Baupläne 2. schlechte Wartbarkeit; wenn Hauptspeicher vollläuft 3. stellvertretend für psychologische Aspekte; nicht mißverstehen: auch Manager machen Reviews „Da hat sich ein Fehler eingeschlichen“ Folie zuletzt geändert am: 10.07.01 (1-Blank5), 18.09.99, Notizen zuletzt geändert am: 26.12.01 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Merkmale 6-10 von Fagan’s Reviewmethode 6. max. 2 Stunden 7. Rollen werden zugewiesen 8. trainierter Moderator 9. Statistiken werden geführt 10. optimale Inspektionsrate in Seiten/h oder NLOC/h 7. Umfangreiche Checklisten werden unter den Reviewern aufgeteilt. 8. - nur trainierte Moderatoren stellen krit. Erfolgsfaktoren sicher - Moderatoren werden zertifiziert - Moderatoren, nicht Autoren stehen unter Erfolgsdruck 9. rückgekoppelter Prozeß. LIDS 10. checking UND logging rate, aus opt. Inspektionsrate folgt max. upper size des Pakets! Folie zuletzt geändert am: 18.09.99 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Defect Density against Inspection Rate 15 12 9 Defect density (defects/page) 6 3 „Bereich der Illusion von QS“. Nicht ungerecht sein ... 60 * 1 = 10 * 6 Gilb/Ebenau/Leserate einzeichnen Folie zur Seite legen Folie zuletzt geändert am: 18.09.99 20 40 60 80 100 Inspection rate (pages/hour) Source: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Empfohlene Inspektionsraten Programme 100 – 150 NLOC / h Textdokumente Gilb/Graham: ca. 1 Seite / h Strauss/Ebenau: 3 – 5 Seiten / h Zum Vergleich: „Rechtschreibfehler-Leserate“ beträgt ca. 7 – 25 Seiten / h Folie zuletzt geändert am: 09.06.02 (animiert, Notizen verkürzt), 30.12.00, Notizen zuletzt geändert am: 29.03.02 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

3 Wochen weniger Laufzeit für Integrationstest Programmierung (inkl. Modultest bzw. Review) Integrations-test eingesparte Laufzeit ca. 7 Wo 2 Wo 3 Wo (Schätzung) Integrationstest dauerte 6 Tage für Testfall-Spezifikation und 4 Tage für Testdurchführung (inkl. Korrektur von 10 Mj defects) Ohne Reviews wären es 6 Tage + ca. 19 Tage (für 47 Mj defects) gewesen! Folie zuletzt geändert am: 26.05.02 (nur Animation geändert), 04.06.01 (neu erstellt) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Weitere Informationsquellen www.reviewtechnik.de : Kostenlose „Reviewtechnik-Sprechstunde“ Linksammlung zu Reviewtechnik Checklisten „Software Inspection“ von Tom Gilb und Dorothy Graham, ISBN 0-201-63181-4 Folie zuletzt geändert am: 25.05.02, 20.05.02 „Peer Reviews in Software: A Practical Guide“ von Karl E. Wiegers, ISBN 0-201-73485-0 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Dr. Juran’s Test “The Game Rules” No questions! No discussion! Make your best interpretation of these rules. You will get 30 seconds to check. Count all defects for Rule F: no instances of “F” (any type) allowed on the screen. Advice: count even “remote cousins” (example “f” and “F ”). Write down your count of “defects” on paper. You may move to any position in the room to see better. Do not interfere with the view of others. Gilb Mai 2001: „Gilb‘s variation of Juran‘s test“ Folie zuletzt geändert am: 26.05.02 (animiert), 28.12.01 Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Juran's “80%” Test "FEDERAL FUSES ARE THE RESULTS OF YEARS OF SCIENTIFIC STUDY COMBINED WITH THE EXPERIENCE OF YEARS." How many letter F's can you find on this page? Write the number down in this box Folie zuletzt geändert am: 27.12.01 Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Checklist for "F" Searching All questions support “Rule F” F1. Do you find the word "of"? F2. Did you look outside borders? F3. Do you find large graphic patterns resembling F ? F4. Did you find all "F" shapes within other symbols, for example in letter "E"? F5. Did you find all numbers and shapes pronounced "F", for example 55 and "frames"? F6. Did you examine things under a microscope? F7. Did you check the back of the screen? F8. Did you look for lettering on the screen casing? F9. Did you see the upside-down, backwards letter “t” (= “f”)? Rule F: no instances of “F” (any type) allowed on the screen. In Gilb’s Folien gibt es noch Folie “F Test Predictions”: Prediction (made in advance, we will check it out later): The group average for “obvious” F’s will be 55%±7% for software people 65%±8% for engineers The group average for ‘really obscure’ F’s will be less than 10%. Und Folie “The F-test ‘Lessons’”: Defect finding is difficult Even when a simple clear Rule defines a defect Tools (Checklists) might be necessary to understand a simple Rule. Checklists supplement but do not change the Rule Time might be necessary to use the Tools. We can predict number of defects NOT found! Folie zuletzt geändert am: 27.12.01 Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Dr. Juran’s Test: Gilb’s Prediction Gilb: The group average for “obvious” F’s will be 55%±7% for software people, 65%±8% for engineers. The group average for ‘really obscure’ F’s will be less than 10%. [Peter Rösler's 16 Kurse/Vorträge von Feb 2002 - April 2003 lagen alle bis auf eine Ausnahme im Bereich 71%±7%] Folie zuletzt geändert am: 29.04.03, 25.05.02 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Source Code Reviews Check-Liste mit typischen Fehlern Code ist schon Unit getestet => suche nur nach typischen Fehlerquellen: Division durch 0 null-Pointer Dereferenzierung Speicher-Lecks Array-Grenzen bei for-Schleifen deckt kompliziertes if alle Fälle richtig ab Terminiert die Schleife / Rekursion sicher Dead-Lock-Gefahren Racing Conditions . . . Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Tätigkeiten bei der Softwareentwicklung Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Das V Modell Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

V-Modell: Management Anteile Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Der Rational Unified Process: Requirements Capturing Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Requirements Elicitation Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Analyse Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Design Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Implementierung Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Testen Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP: Übersicht Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

RUP Zusammenfassung „Stand der (konservativen) Technik“ Iterativ Viele Rollen, Tätigkeiten, Dokumentarten Testen kommt relativ spät Aktivitäten münden immer in Dokumenten Gegenentwurf: eXtreme Programming / Agile Methoden Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Wintersause 2007 Nordhessens größte Uni-Party Helfer gesucht Türsteher Thekendienst Kasse Orga-Team Helfer-Party im CC info@wintersause.de Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University