Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Kwaliteit van Software Jaap van Ekris [email_address] © 2006 CIBIT
Kwaliteit van software? © 2006 CIBIT
Kwaliteit van software? (2) © 2006 CIBIT
Of wat abstracter… © 2006 CIBIT
Kwaliteit van software? (3) © 2006 CIBIT
Agenda <ul><li>Introductie </li></ul><ul><ul><li>Wat is kwaliteit? </li></ul></ul><ul><ul><li>QUINT </li></ul></ul><ul><li...
Kwaliteit <ul><li>Wat is kwaliteit? </li></ul><ul><ul><li>‘ The totality of characteristics of an entity that bear on its ...
It is all about the details ... <ul><li>NASA – Mars Climate Orbiter (1999) </li></ul><ul><ul><li>NASA lost a $125 million ...
Het belang van kwaliteit <ul><li>Kwaliteit is geen ‘add-on’ </li></ul><ul><ul><li>Je doet het er niet ‘even’ bij... </li><...
Kwaliteit kost geld <ul><li>Cost of Quality </li></ul><ul><ul><li>Andere werkprocessen, meer Quality Assurance </li></ul><...
Extended ISO 9126 - Quint © 2006 CIBIT Introductie Casussen Afsluiting
Eisen aan een softwareproduct <ul><li>Kwaliteit zo vroeg mogelijk expliciet maken! </li></ul><ul><li>We hebben Quint/ISO91...
Borging vooraf: definieer een kwaliteitskader <ul><li>Stel de kwaliteitscriteria vast inclusief te verwachten maatregelen ...
© 2006 CIBIT Air Traffic Control Systeem Webapplicatie voor luchtvaartmaatschappij <ul><li>Bijna nooit alles even belangri...
A tale of 2 systems... <ul><li>We begeven ons in het domein van een vliegveld </li></ul><ul><ul><li>Diverse informatiesyst...
De architectuur © 2006 CIBIT Casussen Introductie Afsluiting
Borging vooraf: via werk- processen en methodieken <ul><li>IEC61508 </li></ul><ul><ul><li>ISO9001 als basis </li></ul></ul...
The V-model © 2006 CIBIT Acceptance test Technical Specifications Detailed Design Coding Integration test unit test Systee...
Afbreukrisico’s  ≠ uitval van het systeem! <ul><li>Functioneel gedrag </li></ul><ul><li>Response-snelheid </li></ul><ul><l...
Borging vooraf: definieer een kwaliteitskader met maatregelen (2) <ul><li>Performance </li></ul><ul><ul><li>Performance Mo...
Het kan ook anders... <ul><li>Een verschuiving van een waterval-aanpak naar meer iteratief georganiseerde aanpak </li></ul...
Borging vooraf: definieer een kwaliteitskader met maatregelen (3) <ul><li>Er is een architectuurbeschrijving </li></ul><ul...
Borging vooraf: definieer een kwaliteitskader met maatregelen (3) <ul><li>Er is een architectuurbeschrijving </li></ul><ul...
Borging vooraf: definieer een kwaliteitskader met maatregelen (4) © 2006 CIBIT Casussen Introductie Afsluiting Detail Hoog...
Borging tijdens ontwikkeling:  definieer een kwaliteitskader met maatregelen <ul><li>Metrieken geven inzicht in de kwalite...
Risk based testing als a test-strategy <ul><li>IEC61508 vereist bewijs van compleetheid en bewuste beslissingen over rest-...
Kun je ook alles testen? <ul><li>Praktisch is niet alles haalbaar: </li></ul><ul><ul><li>TIjd en middelen zijn beperkt </l...
De praktijk ... <ul><li>Vanuit een reviewperspectief </li></ul><ul><ul><li>Kwaliteitseisen verkrijgen (of achteraf meehelp...
Afsluiting <ul><li>Zorg voor helderheid over verwachtingen vooraf </li></ul><ul><li>Borg die ook </li></ul><ul><li>Maar we...
Referenties <ul><li>http://c2.com/cgi/wiki?QualityAssuranceIsNotQualityControl </li></ul><ul><li>Architecten blinken uit i...
Vragen? <ul><li>Jaap van Ekris,  [email_address] </li></ul>© 2006 CIBIT Afsluiting Introductie Casussen
Upcoming SlideShare
Loading in …5
×

2006-04-19 - Platform voor Informatiebeveiliging - Kwaliteit van Software in context

543 views

Published on

presenatation about the practical application of quality models, as well as the methods to elicitate software quality requirements.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

2006-04-19 - Platform voor Informatiebeveiliging - Kwaliteit van Software in context

  1. 1. Kwaliteit van Software Jaap van Ekris [email_address] © 2006 CIBIT
  2. 2. Kwaliteit van software? © 2006 CIBIT
  3. 3. Kwaliteit van software? (2) © 2006 CIBIT
  4. 4. Of wat abstracter… © 2006 CIBIT
  5. 5. Kwaliteit van software? (3) © 2006 CIBIT
  6. 6. Agenda <ul><li>Introductie </li></ul><ul><ul><li>Wat is kwaliteit? </li></ul></ul><ul><ul><li>QUINT </li></ul></ul><ul><li>Twee casussen </li></ul><ul><ul><li>Vooraf borgen van softwarekwaliteit </li></ul></ul><ul><ul><li>Achteraf vaststellen van softwarekwaliteit </li></ul></ul><ul><li>Afsluiting </li></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  7. 7. Kwaliteit <ul><li>Wat is kwaliteit? </li></ul><ul><ul><li>‘ The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs’ (ISO 8402) </li></ul></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  8. 8. It is all about the details ... <ul><li>NASA – Mars Climate Orbiter (1999) </li></ul><ul><ul><li>NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday. </li></ul></ul><ul><ul><li>The units mismatch prevented navigation information from transferring between the Mars Climate Orbiter spacecraft team in at Lockheed Martin in Denver and the flight team at NASA's Jet Propulsion Laboratory in Pasadena, California. </li></ul></ul><ul><ul><li>http://www.cnn.com/TECH/space/9909/30/mars.metric.02/ </li></ul></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  9. 9. Het belang van kwaliteit <ul><li>Kwaliteit is geen ‘add-on’ </li></ul><ul><ul><li>Je doet het er niet ‘even’ bij... </li></ul></ul><ul><ul><li>Kwaliteit is echter wel vaak onderbelicht </li></ul></ul><ul><li>Kwaliteit kost geld </li></ul><ul><ul><li>“ Investeringen in kwaliteit zie je niet terug” </li></ul></ul><ul><li>Het niet leveren van kwaliteit kost vaak meer </li></ul><ul><ul><li>Quality is free (Crosby, 1979) </li></ul></ul><ul><ul><li>Cost of quality versus cost of non-quality </li></ul></ul><ul><li>Je kunt niet vroeg genoeg beginnen met kwaliteit! </li></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  10. 10. Kwaliteit kost geld <ul><li>Cost of Quality </li></ul><ul><ul><li>Andere werkprocessen, meer Quality Assurance </li></ul></ul><ul><ul><li>Meer aandacht voor testen </li></ul></ul><ul><ul><li>Ander design </li></ul></ul><ul><ul><li>Andere tools </li></ul></ul><ul><li>Cost of Non-Quality </li></ul><ul><ul><li>De kosten die volgen uit het niet hebben van voldoende kwaliteit op enig moment </li></ul></ul><ul><ul><li>Failures </li></ul></ul><ul><ul><li>Afwijzing (en aansprakelijkheid) </li></ul></ul><ul><ul><li>Imagoschade </li></ul></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  11. 11. Extended ISO 9126 - Quint © 2006 CIBIT Introductie Casussen Afsluiting
  12. 12. Eisen aan een softwareproduct <ul><li>Kwaliteit zo vroeg mogelijk expliciet maken! </li></ul><ul><li>We hebben Quint/ISO9126, dus waarom niet include Quint.*; </li></ul><ul><ul><li>Quint beschrijft geen eisen </li></ul></ul><ul><ul><li>Het implementeren van kwaliteitseisen kost (ook) tijd en geld </li></ul></ul><ul><ul><li>Kwaliteitseisen kunnen onderling conflicteren </li></ul></ul><ul><li>Dus: </li></ul><ul><ul><li>selectie/prioriteitstelling kwaliteitsaspecten noodzakelijk </li></ul></ul><ul><ul><li>aspecten met hoge prioriteit uitwerken tot concrete kwaliteitseisen </li></ul></ul><ul><ul><li>ten behoeve hiervan activiteiten opnemen in requirementsanalyseproces! </li></ul></ul>© 2006 CIBIT Introductie Casussen Afsluiting
  13. 13. Borging vooraf: definieer een kwaliteitskader <ul><li>Stel de kwaliteitscriteria vast inclusief te verwachten maatregelen </li></ul><ul><ul><li>Op basis van Quint, maar ook overige open of bedrijfsstandaarden </li></ul></ul><ul><li>De praktijk leert: </li></ul><ul><ul><li>Maar al te vaak zijn kwaliteitseisen niet ge ïdentificeerd ! </li></ul></ul><ul><ul><li>Dus dient ‘te verwachten kwaliteit’ achteraf geconcretiseerd gemaakt te worden, om te kunnen toetsen </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  14. 14. © 2006 CIBIT Air Traffic Control Systeem Webapplicatie voor luchtvaartmaatschappij <ul><li>Bijna nooit alles even belangrijk, veel is afhankelijk van de context </li></ul><ul><li>Bijna altijd herkenbaar beeld voor belanghebbenden </li></ul>Kwaliteit is situationeel bepaald Casussen Introductie Afsluiting
  15. 15. A tale of 2 systems... <ul><li>We begeven ons in het domein van een vliegveld </li></ul><ul><ul><li>Diverse informatiesystemen voor diverse doelgroepen </li></ul></ul><ul><li>Een luchtverkeersleidingssysteem ... </li></ul><ul><ul><li>... houdt de vliegtuigen uit elkaar, en leidt ze van of naar het vliegveld </li></ul></ul><ul><li>Een on-line vluchtboekingssysteem... </li></ul><ul><ul><li>... lok en leidt reizigers naar het vliegveld </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  16. 16. De architectuur © 2006 CIBIT Casussen Introductie Afsluiting
  17. 17. Borging vooraf: via werk- processen en methodieken <ul><li>IEC61508 </li></ul><ul><ul><li>ISO9001 als basis </li></ul></ul><ul><ul><li>German V-model </li></ul></ul><ul><ul><li>Risico-analyse drijft alle ontwerpbeslissingen </li></ul></ul><ul><ul><li>Customized process op basis van SIL-levels </li></ul></ul><ul><ul><li>Een geaccepteerde norm door overheid en industrie </li></ul></ul><ul><ul><li>Sterke correlatie met systeembetrouwbaarheid </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  18. 18. The V-model © 2006 CIBIT Acceptance test Technical Specifications Detailed Design Coding Integration test unit test Systeem test <ul><li>Formal design methods </li></ul><ul><li>Risk analysis </li></ul><ul><li>Design Validation </li></ul><ul><li>Design Verification </li></ul><ul><li>Reviews </li></ul><ul><li>Structured testing </li></ul><ul><li>Risk based testing </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul><ul><li>Only “Safe subsets” allowed </li></ul><ul><li>Coding standard </li></ul><ul><li>Automated verification </li></ul><ul><li>Peer Reviews </li></ul><ul><li>Code inspections </li></ul><ul><li>Formal design methods </li></ul><ul><li>Risk analysis </li></ul><ul><li>Design Validation </li></ul><ul><li>Design Verification </li></ul><ul><li>Reviews </li></ul><ul><li>Structured testing </li></ul><ul><li>Risk based testing </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul><ul><li>Fagan inspections </li></ul>Casussen Introductie Afsluiting Functional requirements
  19. 19. Afbreukrisico’s ≠ uitval van het systeem! <ul><li>Functioneel gedrag </li></ul><ul><li>Response-snelheid </li></ul><ul><li>Tolerantie van (gebruikers) fouten uit de omgeving </li></ul><ul><li>Faalgedrag van componenten </li></ul><ul><li>Begrijpbaarheid van het systeem </li></ul><ul><li>Accuraatheid gegevens </li></ul>© 2006 CIBIT Casussen Introductie Afsluiting Filedetectie faalt OR Detectie faalt Verwerking faalt Signalering faalt OR AND Lus faalt Detectorstat faalt Onderstation faalt Verwerking via VICNet faalt Verwerking via Partylijn faalt OR Inkomende Partylijn faalt Inkomende FEP faalt TOP faalt Uitgaande FEP faalt Uitgaande Partylijn faalt AND Beeldstand Onderstation 1 faalt Beeldstand Onderstation 2 faalt Beeldstand Onderstation 3 faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt
  20. 20. Borging vooraf: definieer een kwaliteitskader met maatregelen (2) <ul><li>Performance </li></ul><ul><ul><li>Performance Modelling, queueing networks) </li></ul></ul><ul><li>Changeability, Recoverability, Fault tolerance </li></ul><ul><ul><li>Scenario-analyse (change scenario’s, failure scenario’s, ...) </li></ul></ul><ul><li>Maintainability </li></ul><ul><ul><li>Refactoring, code-analyse </li></ul></ul><ul><li>Learnability </li></ul><ul><ul><li>Gebruikers-vragenlijsten </li></ul></ul><ul><li>Usability </li></ul><ul><ul><li>Aantal benodigde clicks </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  21. 21. Het kan ook anders... <ul><li>Een verschuiving van een waterval-aanpak naar meer iteratief georganiseerde aanpak </li></ul><ul><ul><li>Eisen zijn nooit volledig helder! </li></ul></ul><ul><ul><li>Frequenter belanghebbenden waaronder opdrachtgever) informeren </li></ul></ul><ul><ul><li>Continue integratie (‘altijd een werkend systeem’) </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  22. 22. Borging vooraf: definieer een kwaliteitskader met maatregelen (3) <ul><li>Er is een architectuurbeschrijving </li></ul><ul><li>Diagrammen zijn in UML opgesteld </li></ul><ul><li>Architectuur verdeelt systeem in lagen </li></ul><ul><li>Architectuur is service-georiënteerd </li></ul><ul><li>Interfaces zijn gedefinieerd met pre- en postcondities </li></ul><ul><li>Er staan geen literals (constanten) in statements </li></ul><ul><li>Namen van variabelen beginnen met een kleine letter </li></ul><ul><li>Ontwerpbeslissingen zijn onderbouwd </li></ul><ul><li>De werking van algoritmen is formeel correct bewezen </li></ul><ul><li>Uitwijk- en testomgevingen zijn beschreven </li></ul><ul><li>Afwezigheid van deadlocks is aangetoond </li></ul><ul><li>De applicatie is runtime schaalbaar (en dat is beschreven) </li></ul><ul><li>Architectuurbeslissingen zijn traceerbaar naar eisen </li></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  23. 23. Borging vooraf: definieer een kwaliteitskader met maatregelen (3) <ul><li>Er is een architectuurbeschrijving </li></ul><ul><li>Diagrammen zijn in UML opgesteld </li></ul><ul><li>Architectuur verdeelt systeem in lagen </li></ul><ul><li>Architectuur is service-georiënteerd </li></ul><ul><li>Interfaces zijn gedefinieerd met pre- en postcondities </li></ul><ul><li>Er staan geen literals (constanten) in statements </li></ul><ul><li>Namen van variabelen beginnen met een kleine letter </li></ul><ul><li>Ontwerpbeslissingen zijn onderbouwd </li></ul><ul><li>De werking van algoritmen is formeel correct bewezen </li></ul><ul><li>Uitwijk- en testomgevingen zijn beschreven </li></ul><ul><li>Afwezigheid van deadlocks is aangetoond </li></ul><ul><li>De applicatie is runtime schaalbaar (en dat is beschreven) </li></ul><ul><li>Architectuurbeslissingen zijn traceerbaar naar eisen </li></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  24. 24. Borging vooraf: definieer een kwaliteitskader met maatregelen (4) © 2006 CIBIT Casussen Introductie Afsluiting Detail Hoog Middel Laag Hoog Laag gebruik lagenarchitectuur gebruik J2EE patterns uit boek [xyz] gebruik Java Code Conventions gebruik MVC met listeners voor presentatielaag methoden moeten al hun gebruikte resources vrijgeven variabelen moeten bij declaratie geïnitialiseerd worden Inhoud Uitwerking Reference arch. regels
  25. 25. Borging tijdens ontwikkeling: definieer een kwaliteitskader met maatregelen <ul><li>Metrieken geven inzicht in de kwaliteit van software, bijvoorbeeld metrieken ten behoeve van analyseerbaarheid: </li></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  26. 26. Risk based testing als a test-strategy <ul><li>IEC61508 vereist bewijs van compleetheid en bewuste beslissingen over rest-risico’s </li></ul><ul><li>IEC61508 “verwacht” bepaalde methoden </li></ul><ul><ul><li>Simulation </li></ul></ul><ul><ul><li>Formal proofs </li></ul></ul><ul><ul><li>Static analysis </li></ul></ul><ul><ul><li>Dynamic analysis and Black Box testing </li></ul></ul><ul><ul><li>Probabilistic testing </li></ul></ul><ul><ul><li>Functional testing </li></ul></ul><ul><ul><li>Failure analysis </li></ul></ul><ul><ul><li>Performance testing </li></ul></ul><ul><ul><li>Interface testing </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  27. 27. Kun je ook alles testen? <ul><li>Praktisch is niet alles haalbaar: </li></ul><ul><ul><li>TIjd en middelen zijn beperkt </li></ul></ul><ul><ul><li>Complex systeemgedrag is moeilijk te doorgronden </li></ul></ul><ul><ul><li>Redundantie kan ook problemen maskeren </li></ul></ul><ul><li>Safety Critical kan ook betekenen: dodelijk voor testers </li></ul><ul><ul><li>Falen van het systeem </li></ul></ul><ul><ul><li>Falen van veiligheidssystemen </li></ul></ul><ul><ul><li>Onverwacht gedrag van het systeem </li></ul></ul><ul><li>Testen kan wel eens meer risico introduceren dan het reduceert </li></ul><ul><ul><li>Het kan altijd fout gaan, maar dat is wat je wilt voorkomen </li></ul></ul><ul><ul><li>Met testen haal je ook “gekke” dingen uit met een systeem </li></ul></ul><ul><ul><li>Je kunt een test-omgeving niet volledig beheersen </li></ul></ul>© 2006 CIBIT Casussen Introductie Afsluiting
  28. 28. De praktijk ... <ul><li>Vanuit een reviewperspectief </li></ul><ul><ul><li>Kwaliteitseisen verkrijgen (of achteraf meehelpen defini ëren) </li></ul></ul><ul><ul><li>Op zoek naar genomen maatregelen </li></ul></ul><ul><li>Symptomen </li></ul><ul><ul><li>Gebrekkige (geen?) documentatie </li></ul></ul><ul><ul><li>Architect is reeds van het project af </li></ul></ul><ul><ul><li>Dit project is zo uniek, dat .... (geen van de criteria van toepassing is) </li></ul></ul>© 2006 CIBIT Afsluiting Introductie Casussen
  29. 29. Afsluiting <ul><li>Zorg voor helderheid over verwachtingen vooraf </li></ul><ul><li>Borg die ook </li></ul><ul><li>Maar wel op een manier die past bij de werkwijze van het project </li></ul>© 2006 CIBIT Afsluiting Introductie Casussen
  30. 30. Referenties <ul><li>http://c2.com/cgi/wiki?QualityAssuranceIsNotQualityControl </li></ul><ul><li>Architecten blinken uit in onduidelijkheid, MvE, MM </li></ul><ul><li>Fagan, M.E., Design and Code inspections to reduce errors in program development , 1976, IBM Systems Journal, Vol. 15, No 3, Page 258-287 </li></ul>© 2006 CIBIT Afsluiting Introductie Casussen
  31. 31. Vragen? <ul><li>Jaap van Ekris, [email_address] </li></ul>© 2006 CIBIT Afsluiting Introductie Casussen

×