2008-06-23 - SDN - Kwaliteit van software, wat is dat nu eigenlijk?

815 views

Published on

General discussion about what software quality is, how to measure it and how to build it.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
815
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Copyright CIBIT Adviseurs|Opleiders 2005 Werkveld: Kerncentrales Luchtverkeersleiding Stormvloedkeringen Fouten kosten veel mensenlevens
  • Kwaliteit doe je er niet even bij. Bij strikter wordende kwaliteitseisen neemt de inspanning die (achteraf) benodigd is om aan deze eisen te voldoen, vaak nog meer toe! Het toevoegen van extra functionaliteit aan een informatiesysteem is vaak makkelijker dan het verdubbelen van de performance, aangezien kwaliteitseisen vaak ‘verspreid door het systeem’ worden ge ïmplementeerd. Liggen kwaliteitseisen anders, dan had wellicht een heel ander ontwerp gemaakt worden!
  • Still not perfect
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Copyright CIBIT Adviseurs|Opleiders 2005
  • Ook tijdens het ontwikkelproces kun je continue aandacht houden voor kwaliteit, door op de maatregelen te monitoren.
  • Truc is natuurlijk wel om te zorgen dat de juiste risico’s worden afgedekt met de juiste testmethoden: Bepaald faalgedrag kun je alleen onderzoeken door middel van een combinatie van formele methoden, Dynamischa analyses en Failure analysis Voorbeelden: Faalgedrag van individuele PLC’s op de Oosterschelde is eerst getest door Simulatie en vervolgens tijdens testen nogmaals getest Uitval van radarbeelden van een luchtverkeersleidingcentrum worden getest door een combinatie van Dynamische analyse, performance testing en failure testing Functioneel veiligheids-gedrag van Beveiligins PLC’s voor zware industrie worden bijvoorbeeld met probabalistische methoden en Dynamische analyses volledig getest (zijn klein genoeg
  • 2008-06-23 - SDN - Kwaliteit van software, wat is dat nu eigenlijk?

    1. 1. Softwarekwaliteit Wat is dat eigenlijk? Jaap van Ekris Det Norske Veritas
    2. 2. Mijn achtergrond Slide
    3. 3. Agenda <ul><li>Wat is kwaliteit? </li></ul><ul><li>Hoe specificeer je het? </li></ul><ul><li>Hoe bouw je het? </li></ul>
    4. 4. Softwarekwaliteit?
    5. 5. Wat is kwaliteit? <ul><ul><li>The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs’ </li></ul></ul><ul><ul><li>(ISO 8402) </li></ul></ul>© 2006 CIBIT
    6. 6. Wat is kwaliteit? <ul><li>Een systeem moet de goede dingen doen </li></ul><ul><li>Maar ook moet het de dingen goed doen! </li></ul>
    7. 7. Bijvoorbeeld <ul><li>Versus </li></ul>
    8. 8. Kwaliteit heeft een historie <ul><li>‘ 70 : Als de code compileert kan het niet fout zijn </li></ul><ul><li>‘ 80 : Het moet ook nog doen wat is beloofd </li></ul><ul><li>‘ 90 : Het moet ook nog gebruiksvriendelijk zijn </li></ul><ul><li>‘ 00 : Het moet wel secure zijn </li></ul><ul><li>‘ 10 : ??? </li></ul>Slide 10 June 2011
    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 direct terug” </li></ul></ul><ul><li>Het niet leveren van kwaliteit kost vaak meer </li></ul><ul><ul><li>Cost of quality versus cost of non-quality </li></ul></ul>© 2006 CIBIT
    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>Reparatiekosten van Failures </li></ul></ul><ul><ul><li>Afwijzing (en aansprakelijkheid) </li></ul></ul><ul><ul><li>Imagoschade </li></ul></ul>© 2006 CIBIT
    11. 11. Kosten van van problemen req’s design code developm. acceptance operation tests tests 200 100 50 20 10 5 1 Relative cost to fix fault Phase in which fault was detected
    12. 12. Een bekend voorbeeld?
    13. 13. Een call-graph… Slide
    14. 14. Beter? Slide
    15. 15. Wat is dan softwarekwaliteit?
    16. 16. 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>
    17. 17. Begin te ontwerpen vanuit kwaliteit <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 testen </li></ul></ul>
    18. 18. Hulpmiddelen: Quintworkshop
    19. 19. Alhoewel het niet altijd werkt… Slide
    20. 20. Trade-offs Slide Relaties tussen Behoeften en eisen Prioriteiten kwaliteits eisen prioriteiten Kwaliteitseisen Gebruikers behoeften Interacties tussen kwaliteitseisen
    21. 21. Kwaliteit is situationeel <ul><li>Bijna nooit alles even belangrijk </li></ul><ul><li>Veel is afhankelijk van de context </li></ul><ul><li>Bijna altijd herkenbaar beeld voor belanghebbenden </li></ul><ul><li>Discussie over verrassingen: waar is security gebleven ? </li></ul>© 2006 CIBIT Air Traffic Control Systeem Webapplicatie voor luchtvaartmaatschappij
    22. 22. Tastbare kwaliteitseisen <ul><li>Functionality </li></ul><ul><li>“ The system should fit the workprocess” </li></ul><ul><li>of </li></ul><ul><li>“ Function XYZ should be implemented….” </li></ul><ul><li>“ The workflow is ….” </li></ul><ul><li>“ All financial data must have an accuracy of 2 digits” </li></ul>Slide
    23. 23. Tastbare kwaliteitseisen <ul><li>Reliability </li></ul><ul><li>“ The system should have an availability of 99%” </li></ul><ul><li>of </li></ul><ul><li>“ The system should survive single failure of network components, servers and software failures” </li></ul>Slide
    24. 24. Tastbare kwaliteitseisen <ul><li>Usability </li></ul><ul><li>“ All users should be able to use the system” </li></ul><ul><li>of </li></ul><ul><li>“ For trained, frequent, users the system should contain keyboard shortcuts” </li></ul><ul><li>“ For untrained, infrequent, users the system should be usable with mouse and all fields and buttons must contain context sensitive help” </li></ul>Slide
    25. 25. Tastbare kwaliteitseisen <ul><li>Efficiency </li></ul><ul><li>“ The response time of the system will be 3 seconds” </li></ul><ul><li>of </li></ul>Slide 1 sec 3 sec Progr. Bar Batch Function 1 X Function 2 X Function 3 X Function 4 X Function 5 X …
    26. 26. Tastbare kwaliteitseisen <ul><li>Maintainability </li></ul><ul><li>“ The system should be maintainble” </li></ul><ul><li>or </li></ul><ul><li>“ The website should allow for the following modification scenario’s: </li></ul><ul><li>Multiple application/webservers </li></ul><ul><li>Dynamic usergroup matching </li></ul><ul><li>Internationalisation in European, Slavic and Latin anguages </li></ul><ul><li>Multiple skins, theme’s </li></ul>Slide
    27. 27. Tastbare kwaliteitseisen <ul><li>Portability </li></ul><ul><li>“ The system should be portable” </li></ul><ul><li>or </li></ul><ul><li>“ The system should work under Windows and Linux with recompiling and only changing the graphic libraries” </li></ul>Slide
    28. 28. Hoe in te bouwen? <ul><li>Denken over het ontwerp van je systeem/applicatie </li></ul><ul><li>Denken over de manier van samenwerken met je klant </li></ul><ul><li>Bespreekbaar maken is het belangrijkst </li></ul>
    29. 29. 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
    30. 30. Luchtverkeersleiding: De architectuur © 2006 CIBIT
    31. 31. 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
    32. 32. Waterval methode ‘to the extreme’ © 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>Functional requirements
    33. 33. 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 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
    34. 34. <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>Website: Agile aanpak met maatregelen © 2006 CIBIT
    35. 35. Het kan dus 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><ul><li>Moet eigenlijk wel voor dit soort systemen! </li></ul>© 2006 CIBIT
    36. 36. <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 Definieer kwaliteitsmaatregelen
    37. 37. Definieer kwaliteitsmaatregelen © 2006 CIBIT 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
    38. 38. Definieer kwaliteitmaatregelen <ul><li>Metrieken geven inzicht in de kwaliteit van software, bijvoorbeeld metrieken ten behoeve van analyseerbaarheid: </li></ul>© 2006 CIBIT
    39. 39. 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
    40. 40. 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
    41. 41. 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
    42. 42. Prioriteit van softwarekwaliteit? © 2006 CIBIT
    43. 43. 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
    44. 44. Vragen <ul><li>? </li></ul>

    ×