Categorie: ISO 25010 Categorien

Samen met je collega’s nadenken over de non-functional requirements van een systeem? Speel de 2B4QA Quality Game!

Samen met mijn collega’s binnen 2B4QA heb ik de 2B4QA Quality Game ontwikkeld om in een speelse setting  na te denken over non-functional aspecten van een systeem. Op een luchtige manier brengen we de  niet functionele aspecten van een systeem onder de aandacht. De 2B4QA Quality Game wordt gebruikt om met medeprojectleden te leren wat belangrijke non-functionals zijn en hierover met elkaar in gesprek te gaan.

Naast wat een systeem moet doen, is het van belang om te bepalen hoe het systeem moet functioneren. Bijvoorbeeld hoe snel, hoe betrouwbaar en hoe onderhoudbaar is het systeem? Wij gebruiken daarvoor de ISO 25010 norm , zoals die hieronder is weergegeven. Leer meer over deze norm via de oplossingen op onze website.

Hoe werkt de 2B4QA Quality Game?

Het doel van het spel is om alle risico’s af te dekken met maatregelen en zo het project tot een succesvol einde te brengen. Met de 2B4QA Quality Game worden  op kaartjes verschillende risico’s aan de spelers uitgedeeld. Op een kaartje staat een specifiek risico met uitleg over dit risico en enkele voorbeelden. De spelers kunnen om beurten maatregelkaarten aanwenden om voor de opgetreden risico’s maatregelen te nemen. Er kan dus worden gespeeld tot er een winnaar bekend is en ondertussen leren de deelnemers welke non-functional requirements er zijn, welke risico’s kunnen optreden en welke maatregel ingezet kan worden om het risico te beperken.

Wanneer speel ik de 2B4QA Quality Game?

De 2B4QA Quality Game kan gespeeld worden met teamgenoten of andere collega’s die geïnteresseerd zijn in non-functional requirements. Het spel heeft op zichzelf staande voorbeelden en hoeft niet gespeeld te worden door mensen die aan hetzelfde systeem werken. Het kan goed gebruikt worden om, tijdens het spel of daarna, een discussie te houden over welke non-functionals belangrijk zijn, welke risico’s deze met zich meebrengen en welke daarbij passende maatregelen ingezet kunnen worden.

TestNet Leergang: Share your Brains

De vereniging TestNet verbindt testprofessionals uit het gehele land, van diverse bedrijven en van ieder niveau. Zij doen dit door op regelmatige basis Thema-avonden te organiseren, door trainingsmogelijkheden zoals de werkgroepen en TestNet Summerschool. Daarnaast is TestNet voortdurend op zoek naar nieuwe vormen waarbinnen de leden met en van elkaar kunnen leren. Zo kwam het dat 2B4QA, begin 2017 gevraagd werden om pilot uit te werken voor een nieuwe werkvorm: De TestNet Leergang.

 Ons concept was vrij simpel: Vijf avonden lang werken vier parallelle groepen aan een specifiek topic binnen een vastgesteld kader. Het doel is een concreet, bruikbaar eindproduct. Iedere deelnemer kiest op de avond zelf aan welk onderwerp hij of zij wil bijdragen. Je kiest zelf aan welk product jij je hersenen wilt uitlenen: Share your Brains.

 Het benoemen van het onderwerp, het schetsen van de context en het definiëren van de verschillende vraagstellingen en het daadwerkelijke eindproduct is feitelijk het lastigste van de gehele leergang. Wat is actueel? Wat is voor een ieder interessant? Wat is nog niet eerder volledig uitgewerkt? Bernd en ik besloten op de toepassing van kwaliteitszorg binnen een continuous integration pipeline eens onder de loep te nemen. Dit leidde tot de volgende beschrijving:

 ISO-SQuaRe binnen CI/DevOps

Functionaliteit is de meest belangrijke eigenschap van ieder object. De functionaliteit bepaalt of dit object nuttig is of juist niet. Zo’n object kan van alles zijn: bijvoorbeeld een koffiezetapparaat, een auto, een mobiele telefoon, een stoel of software. In het kader van leergang doelen we op de functionaliteit van de laatste, de software. Deze software kan een interface, een Graphical User Interface (GUI), een webapplicatie of zelfs een compleet informatiesysteem zijn. Voor al deze onderdelen geldt: de functionaliteit beschrijft ‘wat’ de software moet doen. Vervolgens zijn het de compleetheid, correctheid en toepasbaarheid die bepalen op welk niveau de software geschikt is voor haar doel. Dus functionaliteit is uitermate belangrijk. Maar hoe zit het met de andere categorieën, de hoedanigheden van de software? Hoe krijgen we de overall kwaliteit op orde?

 Hoe kunnen we verschillende non-functional testen integreren in een continuous delivery pipeline of een continuous integration proces? Want moeten testen als installability, maintainability niet naast performance en security in een CI-pipeline? Tijdens deze leergang ontwikkelen we samen een wijze waarop verschillende onderdelen van ISO-SQuaRE en de toepassing van de  kwaliteitsattributen (ISO 25010) binnen DevOps-team worden samengevoegd.

De nadruk ligt op de testfase (model 2501x). Hoe kunnen we bijvoorbeeld een PRA uitvoeren binnen een Agile omgeving? Hoe gaan we om met risico-classificatie aan de hand van pokerkaarten en hoe kunnen we functionaliteit en hoedanigheden beoordelen vanuit verschillende rollen (product owner, beheer, development team, architectuur) binnen een continuous integration pipeline?

De Uitvoering

22 maart vond de kick-off plaats. Als vanzelf ontstonden vervolgens de parallelle groepen waarbinnen in de opeenvolgende avonden interessante discussies plaatsvonden, menig idee werd uitgewerkt en het eindproduct langzaam maar zeker vorm begon te krijgen. Wat is de minimale uitgangspositie voor een continuous integration pipeline? Hoe ga je om met een product risico analyse in een DevOps-organisatie? Hoe verhouden de functionaliteiten zich ten opzichte van de karakteristieken van de te ontwikkelen software? Welke relatie bestaat er tussen productkwaliteit, datakwaliteit en de kwaliteit van het informatiesysteem in gebruik?

 Het resultaat

Wat ons betreft is de pilot geslaagd. Het is gebleken dat het oprecht gebruik maken van elkaars kennis en kunde zonder de vraagstelling ter discussie te stellen en met de vrijheid om op ieder moment van onderwerp te kunnen wisselen het mogelijk maakt om heel snel resultaten op te leveren. Het rouleren zorgt voor dynamiek en frisse, verrassende inzichten. Een van te voren vastgestelde doorlooptijd (in dit geval 5 avonden) zorgt voor een duidelijke deadline en vergroot de betrokkenheid. Je weet per slot van rekening waaraan je je verbindt. En dat was dan alleen nog maar de werkvorm. Wat dacht je van de eindproducten?

Op de laatste avond zijn de resultaten gepresenteerd. Een modulaire opbouw voor een continuous integration pipeline, een PRA binnen DevOps-teams en een matrix waarbinnen het verband tussen de verschillende ISO 250xx-normen is uitgewerkt. Mooie, bruikbare producten. Ben jij nieuwsgierig naar het resultaat? Neem dan eens een kijkje in de bibliotheek van TestNet of kom naar TestNet Werkgroepen Presentatie. Wij zullen daar onze resultaten nogmaals aan een breder publiek presenteren

 

ISO Square

ISO 25010

De ISO 25010 is een van de normen binnen de 250xx serie, die tezamen ook wel ISO SQuaRE worden genoemd. Voordat we de diepte ingaan met de 25010 norm, schets ik eerst de 25010.


Hoewel er in de 250xx reeks nog een aantal normen zijn (25050 en hoger) beperk ik me tot de normen zoals die hierboven schematisch zijn weergegeven. De hogere normen richten zich op internationale standaards en technische eisen, die ik in mijn projecten niet tegenkom.

In onze weergave van de ISO SQuaRE hebben we management (ISO 2500x) in het midden geplaatst. Deze richt zich op de kwaliteit van het proces. In Kwaliteit op Maat had ik dit naast de productkwaliteit opgenomen. De kwaliteit van het proces wordt bepaald door Management en Planning. Deze twee (hoofd)categorieën zijn dan ook in de cirkel rond de 2500x opgenomen.


Hoewel je in eerste instantie uit de nummering van de ISO normen een andere volgorde zou opmaken, hanteren wij de volgorde zoals je met de klok mee kunt lezen van rechtsboven naar linksboven. Beginnen met Requirements (2503x), dan Model (2501x) en Kwaliteitsmeting (2504x) om uit te komen bij Evaluatie (2502x). In de buitenste rand lees je per ISO norm de (hoofd)categorieën waarbinnen uiteindelijk via een categorie de kwaliteitsattributen zijn opgenomen. In de 2501x zie je als (hoofd)categorie Product (ISO 25010), deze heeft bijvoorbeeld de categorie Onderhoudbaarheid maar daarbinnen het attribuut Wijzigbaarheid. Hopelijk duizelt het je nog niet. Als dit wel het geval is, neem ik je stap voor stap mee naar de diverse normen.


Ik loop kort de normen na. Requirements (2503x) heeft als (hoofd)categorieën Stakeholder en Software, Model (2501x) heeft Product en Gebruik/Data, Kwaliteitsmeting (2504x) heeft Indicatoren en Referentiemodel en uiteindelijk Evaluatie (2502x) heeft Proces en Herstelbaarheid.


Jullie hebben wel in de gaten dat ik voorlopig stof genoeg heb om over te bloggen. Volgende blog ga ik in op de ISO 25010, Productkwaliteit.

ISO 25010 – Functionaliteit en Hoedanigheid

Functionaliteit en Hoedanigheid – ISO 25010


In mijn vorige blog heb ik de ISO 25010 in de context van ISO SQuaRE geschetst. Deze keer gaan we een eerste stap maken binnen ISO 25010 en wel binnen productkwaliteit. Zoals in de schematische weergave in de vorige blog zagen jullie dat de ISO 25010 is opgedeeld in Productkwaliteit en Gebruik & Data. Natuurlijk ga ik in de toekomst op Gebruik & Data dieper in, maar nu eerst productkwaliteit.


De ISO 25010 is dus in mijn terminologie een hoofdcategorie van ISo SQuaRE en bevat op zichzelf acht categorieën die de eigenschappen van het systeem beschrijven. In het midden staat de categorie Functionele Geschiktheid die bestaat uit Correctheid, Toepasbaarheid en Compleetheid. Nu is Functionele Geschiktheid altijd de belangrijkste eigenschap. Een razendsnelle applicatie die niet toepasbaar is, compleet is of correct functioneert, wordt niet gebruikt en zal zeker niet gaan renderen. Daarom positioneer ik deze ook in het midden. In verschillende presentaties op seminars zie ik een variant op de pyramide van Maslov terugkomen, waarbij Functionele Geschiktheid de onderste laag is. Een mooie vergelijking, want eerst aan de functionele requirements voldoen en pas daarna aan de andere (hoedanigheids) eigenschappen. Ik hanteer hier wederom de indeling die ik in Kwaliteit op Maat heb gehanteerd, namelijk productkwaliteit bestaat uit Functionaliteit en Hoedanigheid.


Als we rechtsboven beginnen en met de klok mee de overige categorieën langslopen, komen we achtereenvolgens Beveiligbaarheid, Overdraagbaarheid, Betrouwbaarheid, Uitwisselbaarheid, Bruikbaarheid, Prestatie-efficiëntie en Onderhoudbaarheid tegen. De komende weken ga ik ze allemaal in mijn blog behandelen. De positionering, volgorde en kleur op zich hebben geen diepere betekenis. Die zijn uitsluitend zo gekozen om de weergave mooi te kunnen opmaken.


Ongeacht welke betekenis een categorie exact heeft, het is belangrijk om in te zien dat voor de verschillende stakeholders van de applicatie de belangrijkheid van een categorie significant verschilt. Vanuit de beheerafdeling is bijvoorbeeld Onderhoudbaarheid belangrijker dan dat voor de gebruikers. Andersom zal voor de gebruikers de Bruikbaarheid weer belangrijker zijn. Iedereen stelt dus zijn eigen eisen en aan alle eisen voldoen is voor een projectmanager niet te doen. Zijn belangrijkste stakeholder, de opdrachtgever, heeft hem meegegeven dat er een goede, bruikbare en onderhoudbare applicatie moet worden ontwikkeld maar wel binnen budget en op tijd. De duivelsdriehoek uit een van mijn vorige blogs.


Hoe bepaal je nu welke categorie belangrijker is en welke stakeholder heeft het meest te zeggen over de totale hoedanigheid. Voor dat ik daar op inga, de komende blog(s) eerst de verschillende categorieën toelichten.


ISO 25010 – Bruikbaarheid

Bruikbaarheid – ISO 25010


De mate waarin een product of systeem gebruikt kan worden door gespecificeerde gebruikers om effectief, efficiënt en naar tevredenheid gespecificeerde doelen te bereiken in een gespecificeerde gebruikscontext.


Bruikbaarheid van een applicatie is wat mij betreft het meest ongrijpbare en dus het moeilijkste te specificeren van alle categorieën. Een ieder die een applicatie gebruikt, ervaart het gebruik nu eenmaal anders. Ben je onervaren, heb je meer behoefte aan ondersteuning, bel je zeer ervaren wil je het liefst zo min mogelijk ondersteuning. Ik heb niet veel HTML-kennis, maar als ik de pagina’s op de website aanpas vind ik het erg handig dat ik dit direct in de HTML kan doen. Als je weet welke statements er nodig zijn, gaat dat gewoon veel sneller dan via de user interface.


Door de steeds verdere integratie van ICT in onze werkzaamheden en privé, worden we steeds meer ervaren in toepassen van de ICT. Digibeten zijn er nog maar nauwelijks, zeker na de introductie van de IPad. Dit heeft natuurlijk als voordeel dat applicaties complexer mogen zijn dan vroeger. Als er nu wordt gezegd met de muis naar de rechter bovenkant van het scherm, houdt niemand meer de muis zelf tegen het scherm aan, maar weet dat je de cursor daarheen moet bewegen met de muis. Toch worden er door de vele apps ook nieuwe impliciete eisen aan een applicatie gesteld. De eis dat het de look and feel van een apple-app moet hebben, heb ik al geregeld gezien. Wat is de look and feel van een Apple-app? Tja, eenzelfde vraag als voorheen roepen dat de applicatie gebruikersvriendelijk moet zijn. Bruikbaarheid is vooral van belang bij online informatiesystemen waar de gebruiker zelf van achter (of is het voor) een beeldscherm systeemhandelingen moet verrichten. Hoe meer deze aansluiten bij de beleving en de dagelijkse praktijk van de gebruiker, hoe bruikbaarder zij het geautomatiseerde informatiesysteem vinden. Borgen dat het informatiesysteem optimaal gebruikt kan worden, draagt bij aan het terugverdienen van de investering voor het verkrijgen van het informatiesysteem.


De nieuwe generatie gebruikers stellen hele andere eisen aan de bruikbaarheid van een applicatie. Een app moet snel duidelijk maken dat deze uitstekend geschiktheid is voor datgene te doen dat de gebruiker verwacht. Hoe snel is een app tegenwoordig niet weer verwijderd en een andere geïnstalleerd? Geen lange selectietrajecten, klikken, installeren, proberen en dan verwijderen of blijven gebruiken. Alles binnen de minuut. Hoewel bruikbaarheid lastig is te specificeren, draagt het wel heel veel bij aan de gebruiksbeleving. Een belangrijke categorie voor de motivatie van de gebruikers derhalve. Er zijn functioneel correcte applicaties vroegtijdig vervangen omdat er niet mee gewerkt kon worden. (of de gebruiker dit niet wilde).


Definities attributen


Herkenbaarheid van geschiktheid (Appropriateness recognisability)

  • De mate waarin gebruikers kunnen herkennen of een product of systeem geschikt is voor hun behoeften.

Leerbaarheid (Learnability)

  • De mate waarin een product of systeem gebruikt kan worden door gespecificeerde gebruikers om gespecificeerde leerdoelen te bereiken met betrekking tot het gebruik van het product of systeem met effectiviteit, efficiëntie, vrijheid van risico en voldoening, in een gespecificeerde gebruikscontext.

Bedienbaarheid (Operability)

  • De mate waarin een product of systeem attributen heeft die het makkelijk maken om het te bedienen en beheersen.

Voorkomen gebruikersfouten (User error protection)

  • De mate waarin het systeem gebruikers beschermt tegen het maken van fouten.

Volmaaktheid gebruikersinteractie (User interface aesthetics)

  • De mate waarin een gebruikersinterface het de gebruiker mogelijk maakt om een plezierige en voldoening gevende interactie te hebben.

Toegankelijkheid (Accessibility)

  • De mate waarin een product of systeem gebruikt kan worden door mensen met de meest uiteenlopende eigenschappen en mogelijkheden om een gespecificeerd doel te bereiken in een gespecificeerde gebruikscontext

Contact

  • Telefoon

    0318 - 240 044

  • Email

    info@2b4qa.nl

  • KVK

    601.397.73

  • Postadres

    Cuneraweg 322
    3911 RT Rhenen

  • Bezoekadres

    Plesmanstraat 59
    Kamer 21
    3905 KZ  Veenendaal

2B4QA BV  (c) 2018