Home >Documents >Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
Date post:02-Jan-2016
Category:Documents
View:33 times
Download:1 times
Share this document with a friend
Description:
Qualittssicherung von Software (SWQS). Prof. Dr. Holger Schlingloff Humboldt-Universitt zu Berlin und Fraunhofer FOKUS. 18.6.2013: Reviews. Fragen zur Wiederholung. Welche Produktmae kennen Sie fr prozedurale Sprachen fr objektorientierte Sprachen? Was misst die Halstead-Metrik - PowerPoint PPT Presentation
Transcript:
  • Qualittssicherung von Software (SWQS)Prof. Dr. Holger Schlingloff

    Humboldt-Universitt zu BerlinundFraunhofer FOKUS18.6.2013: Reviews

    Folie *H. Schlingloff, Software-Qualittssicherung

    Fragen zur WiederholungWelche Produktmae kennen Siefr prozedurale Sprachenfr objektorientierte Sprachen?Was misst die Halstead-MetrikWie ist die zyklomatische Zahl definiert, was besagt sie?Pro und Contra Coding-Rules?

    Folie *H. Schlingloff, Software-Qualittssicherung

    Wo stehen wir?Einleitung, Begriffe, Software-QualittskriterienTestverfahren, Teststufen, Testberdeckungautomatisierte TestfallerstellungVerifikation und Validierung, Modellprfungstatische und dynamische AnalysetechnikenSoftwarebewertung, SoftwaremetrikenCodereview- und andere InspektionsverfahrenZuverlssigkeitstheorie, FehlerbaumanalyseQualittsstandards, Qualittsmanagement, organisatorische Manahmen

    Folie *H. Schlingloff, Software-Qualittssicherung

    Software-ReviewsVerschiedene ArtenFormales (Design) ReviewStatusreport, HearingAudit, BegehungEntscheidungsgremium entscheidet nach Aktenlage, Vortrag und Anhrung ber Fortsetzung der ArbeitPeer ReviewWalkthrough(Fagan) InspektionGutachter beraten das Entwicklungsteam ber Verbesserungsmglichkeiten

    Folie *H. Schlingloff, Software-Qualittssicherung

    Wozu ist manuelle QS notwendig?Abgleich mit den ursprnglichen Zielenz.B. substantielle Notwendigkeit versus Korrektheit von Modulen (statische Analysen)Aufzeigen von inhaltlichen (nichtformalen) Fehlernz.B. intuitive Bedeutung versus textuelle Gestalt eines Identifiers (Codierstandards)Verbesserung von Lesbarkeit und Verstndlichkeit

    externe BeratungFaktor MenschKommunikation, Lernenoft einzige Mglichkeit

    Folie *H. Schlingloff, Software-Qualittssicherung

    Capability Maturity Model (CMM)Source: www.software.org/quagmire/descriptions/sw-cmm.aspHeroesNo KPAs at this timeProject managementRequirements Management, SW Project Planning SW Project Tracking and Oversight SW Subcontract Management, SW Quality Assurance SW Configuration ManagementEngineering processOrganization Process Focus, Org. Process Definition Peer Reviews, Training Program Intergroup Coordination, SW Product Engineering Integrated Software ManagementProduct and process qualitySoftware Quality Management Quantitative Process ManagementContinuous improvementProcess Change Management Technology Change Management Defect Prevention

    LevelFocusKey Process AreasLevel 5 Optimizing

    Level 4 ManagedLevel 3 Defined

    Level 2 RepeatableLevel 1Initial

    Folie *H. Schlingloff, Software-Qualittssicherung

    Ziele eines Peer ReviewsEntdeckung von Design- und Analysefehlern in den zu untersuchenden DokumentenAufzeigen von Risiken, die den Projektfortschritt beeintrchtigen knntenLokalisierung von Abweichungen gegenber externen und internen Vorgaben und RichtlinienBewertung bzw. Verbesserung der Qualitt der Artefakte

    Kommunikationsmglichkeit fr die BeteiligtenDatenbasis von Befunden fr knftige Projekte

    Folie *H. Schlingloff, Software-Qualittssicherung

    Artefakte fr den ReviewJedes Artefakt, welches als Ergebnis eines Entwicklungszyklusses vorliegt, kann per Review bewertet werden:Anforderungsbeschreibung, VermarktungsplanEntwicklungsplan, RessourcenverteilungEntwurfsdokumente (Grob/Feinarchitektur)Algorithmen und Datenstrukturen, CodeTestplne, TestergebnisseManuale, Handbcher, Versions- und ReleasedokumenteWichtig: es muss eine stabile Version des Artefakts vorliegen

    Folie *H. Schlingloff, Software-Qualittssicherung

    TeilnehmerFormales ReviewEntscheidungstrgerSchriftfhrer und Review-Teamdrfen nicht mit dem Projekt zu tun habenAutor(en) des ArtefaktsSachbearbeiter, Chef des Entwicklungsteams, Peer Reviewexterne Berater: Designer, Implementierer, Tester, Benutzer, Qualittsbeauftragter, Produktlinienmanager, Schriftfhrer sollte Erfahrung mit Reviews und Moderation habenAutor(en)Optimale Gre: 3-5 Reviewer + Autor(en), optimale Zeitdauer: 2h (max. 2 mal pro Tag)

    Folie *H. Schlingloff, Software-Qualittssicherung

    Durchfhrung ReviewPrsentation des DokumentsKommentare des Review-TeamsDiskussion der einzelnen KritikpunkteErgebnisFormales Review: Beratung mit Entscheidung ber Fortfhrung, bedingte Fortfhrung oder Ablehnung (mit Begrndung)Peer Review: Eintrag der gefundenen Issues in Defektverfolgungssystem, Protokoll der Sitzung fr knftige Projekte

    Folie *H. Schlingloff, Software-Qualittssicherung

    Inspektionsprotokoll

    Folie *H. Schlingloff, Software-Qualittssicherung

    Walkthrough und InspektionWalkthrough: gefhrtes Vorlesen vor aufmerksamem Publikumdetaillierte Erklrung durch den Autor keine bzw. minimale Vorbereitung der Reviewergemeinsames Verstndnis als HauptzielInspektion: Frage- und AntwortstundeVorbereitung von Fragen durch Reviewer (3:1) (anhand Checklisten, 30-90% individuelle Findungen)Beantwortung durch Autor so weit mglich

    Inspektion ist aufwndiger aber effektiver!

    Folie *H. Schlingloff, Software-Qualittssicherung

    Fagans Inspektionsmethode1. berall im Entwicklungsprozess2. alle Arten von Fehlern3. ohne big boss4. mehrere Einzelschritte5. Checklistenbasiert6. max. 2 Stunden7. Rollen werden zugewiesen8. trainierter Moderator9. Statistiken werden gefhrt10. Inspektionsrate wird einhalten

    Folie *H. Schlingloff, Software-Qualittssicherung

    Checklistenessenziell fr die Vorbereitung des Reviewsselbe Form, aber deutlich andere Schwerpunktsetzung als Codierrichtliniensind vor Beginn der Entwicklung bekannt, werden den Reviewern bekannt gemachtdienen als Richtlinie bei der Durchfhrung des Reviews

    Kategorisierung der Defekte, Fokus auf Probleme mit hohen konomischen Auswirkungen!

    Folie *H. Schlingloff, Software-Qualittssicherung

    Erfahrungenrichtig angewandt, sind Reviews ein extrem effizientes Mittel der QSAngaben aus der Literatur:An AT&T Bell Laboratory project with 200 professionals instituted several changes, including inspections. Productivity improved by 14% and quality by a factor of ten.Aetna Insurance Company: inspections found 82% of errors in a COBOL program, productivity was increased by 25%.Another COBOL example (Gilb, Software Metrics): 80% of the development errors were found by inspections, productivity was increased by 30%.

    Folie *H. Schlingloff, Software-Qualittssicherung

    Relative FehlerbehebungskostenSource: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank

    Diagramm4

    1.5

    1

    10

    60

    100

    &A

    Seite &P

    Cost units

    Cost Units

    Tabelle1

    RequirementsPreliminary DesignDetailed DesignCode & Unit TestIntegration & System TestAverage errors found / hr

    Production6%12%16%12%10%17.5

    Rework1%4%8%12%19%19.4

    20.8

    20.4

    18.2

    17.8

    13.8

    14.2

    11.2

    10.1

    During DesignBefore CodeBefore TestDuring TestIn ProductionDuring DesignBefore CodeBefore TestDuring TestIn Production

    Cost units1.511060100Cost units92042173

    &A

    Seite &P

    Tabelle1

    00

    00

    00

    00

    00

    &A

    Seite &P

    Production

    Rework

    Tabelle2

    0

    0

    0

    0

    0

    &A

    Seite &P

    Cost units

    Cost Units

    Tabelle3

    0

    0

    0

    0

    0

    &A

    Seite &P

    Cost units

    Errors found

    Tabelle4

    0

    0

    0

    0

    0

    0

    0

    0

    0

    0

    &A

    Seite &P

    Average errors found / hr

    Tabelle5

    &A

    Seite &P

    Tabelle6

    &A

    Seite &P

    Tabelle7

    &A

    Seite &P

    Tabelle8

    &A

    Seite &P

    Tabelle9

    &A

    Seite &P

    Tabelle10

    &A

    Seite &P

    Tabelle11

    &A

    Seite &P

    Tabelle12

    &A

    Seite &P

    Tabelle13

    &A

    Seite &P

    Tabelle14

    &A

    Seite &P

    Tabelle15

    &A

    Seite &P

    Tabelle16

    &A

    Seite &P

    &A

    Seite &P

    &A

    Seite &P

    &A

    Seite &P

    Folie *H. Schlingloff, Software-Qualittssicherung

    Inspektionsrate und ErgebnisprotokollInspektionsratefr Programme: 100 150 NLOC / h (1-2 Seiten / h)fr Textdokumente Gilb/Graham: ca. 1 Seite / hStrauss/Ebenau: 3 5 Seiten / hZum Vergleich: Rechtschreibfehler-Leserate betrgt ca. 7 25 Seiten / hhhere Rate, falls es sich blo um eine berprfung handelt

    ErgebnisprotokollDokument wird geprft, nicht der Autor!keine Diskussion von Fehlern und Lsungswegenhohe Protokollrate (zum Teil mehr als 1 Eintrag pro Minute)

    Folie *H. Schlingloff, Software-Qualittssicherung

    Defektaufdeckungs- und InspektionsrateSource: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB) maximal 2-5 Seiten pro Stunde!

    Folie *H. Schlingloff, Software-Qualittssicherung

    Checklisten fr CodereviewsBeispiel: Java Code Inspection Checklist von Christopher Fox

    Variable and Constant Declaration DefectsAre descriptive variable and constant names used in accord with naming conventions?Are there variables with confusingly similar names?Is every variable properly initialized?Could any non-local variables be made local?Are there literal constants that should be named constants?Are there macros that should be constants?Are there variables that should be constants?

    Folie *H. Schlingloff, Software-Qualittssicherung

    Function Definition Defects (FD)Are descriptive function names used in accord with naming conventions?Is every function parameter value checked before being used?For every function: Does it return the correct value at every function return point?Class Definition Defects (CD)Does eac

Embed Size (px)
Recommended