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

Präsentation zum Thema: "Projektplan: Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University."—  Präsentation transkript:

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

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

3 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 © Albert Zündorf, Kassel University

4 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 © Albert Zündorf, Kassel University

5 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 © Albert Zündorf, Kassel University

6 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 © Albert Zündorf, Kassel University

7 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 © Albert Zündorf, Kassel University

8 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: (1-Blank5), , Notizen zuletzt geändert am: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

9 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: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

10 Defect Density against Inspection Rate
15 12 9 Defect density (defects/page) 6 3 „Bereich der Illusion von QS“. Nicht ungerecht sein * 1 = 10 * 6 Gilb/Ebenau/Leserate einzeichnen Folie zur Seite legen Folie zuletzt geändert am: 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 © Albert Zündorf, Kassel University

11 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: (animiert, Notizen verkürzt), , Notizen zuletzt geändert am: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

12 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: (nur Animation geändert), (neu erstellt) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

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

14 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: (animiert), Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

15 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: Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

16 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: Source: Tom Gilb, Team Leader Course Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

17 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 April 2003 lagen alle bis auf eine Ausnahme im Bereich 71%±7%] Folie zuletzt geändert am: , Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

18 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 © Albert Zündorf, Kassel University

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

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

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

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

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

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

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

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

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

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

29 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 © Albert Zündorf, Kassel University

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