Auteur: Andre Boeters

ISO 25010 – Efficiëntie

Efficiëntie – ISO 25010


De prestaties in verhouding tot de hoeveelheid middelen gebruikt onder genoemde condities


Performancetesten is na het testen van de functionaliteit de meest voorkomende testsoort. We raken steeds meer gewend (verwend) dat een applicatie snel reageert op onze handelingen. Als een webwinkel ons lang in de wachtrij laat staan, zappen we al naar een andere webwinkel. De gewenste functionaliteit van een webwinkel is nu wel bekend, nu gaan klanten verloren door de beperkte snelheid van de applicatie.

Meerdere geautomatiseerde informatiesystemen worden tegelijk gebruikt. Ieder van deze systemen legt beslag op een deel van de beschikbare capaciteit. Hoewel het tegenwoordig steeds ‘goedkoper’ wordt om de capaciteit uit te breiden, zijn er toch vaak bottle-necks die niet opgelost kunnen worden. Het netwerk heeft bijvoorbeeld een maximale bandbreedte en meer kan er echt niet over. In the cloud of juist lokaal, virtuele servers versus fysieke apparaten, Wifi of bedraad, allemaal keuzes die de performance beïnvloeden.

Het oplossen van de ene bottle-neck levert vaak op een andere plek weer een nieuwe bottle-neck op. Een spitsstrook zorgt dan wel voor een betere doorstroming op de snelweg, maar voor meer opstoppingen in de stad. Mocht een spitstrook al een bottle-neck oplossen, deze is vaak na verloop van tijd weer aanwezig. Er worden geen files meer gemeld en iedereen denkt dat dit een optimale route is om op het werk te komen. Het ‘zuigende’ effect van een betere doorstroming zorgt dan voor een groter aanbod en in het slechtste geval weer nieuwe en ditmaal grotere vertragingen. Ergo, het bijplaatsen van een server omdat de schrijfruimtes vol zijn, lost slechts een beperkte tijd het probleem op.


Wie een kaartje koopt voor de bus wordt geacht hooguit één zitplaats te gebruiken. Als een passagier ook plaatsen in beslag neemt voor zijn benen en rugzak, houdt hij zich niet aan deze afspraak en ontstaat er op zijn minst een fikse discussie als de bus vol raakt. Bij informatiesystemen geldt een vergelijkbaar verhaal. Wanneer verwacht mag worden, dat een systeem bovengemiddeld gebruik gaat maken van bijvoorbeeld het lokale netwerk, dan dient dit gebruik vooraf te worden gekwantificeerd.

Wanneer het informatiesysteem na de laatste ‘Enter’ van het invoerscherm de klantgegevens gaat bijwerken, is er even tijd voor een kop koffie. In bepaalde omstandigheden is dat acceptabel, in andere niet. Veel zal afhangen van de soort gebruikers en de aard van het gebruik. Een belangrijk element is ook (daar komt ie weer!) de verwachting van de gebruiker op dat moment.


Definities attributen


Snelheid (Time-behaviour)

  • De mate waarin antwoord- en verwerkingstijden en doorvoersnelheid van een product of systeem, tijdens de uitvoer van zijn functies, voldoet aan de wensen.

Middelenbeslag (Resource utilization)

  • De mate waarin de hoeveelheid en type middelen die gebruikt worden door een product of systeem, tijdens de uitvoer van zijn functies, voldoet aan de wensen.

Capaciteit (Capacity)

  • De mate waarin de maximale limieten van een product- of systeemparameter voldoet aan de wensen.

ISO 25010 – Beveiligbaarheid

Beveiligbaarheid – ISO 25010


De mate waarin een product of systeem informatie en gegevens beschermt zodat personen, andere producten of systemen de juiste mate van gegevenstoegang hebben passend bij hun soort en niveau van autorisatie.


Geregeld zien we nieuwsberichten over hackers die vertrouwelijke informatie hebben buitgemaakt. De toegang tot de data was onvoldoende afgeschermd. Hoe zit het dan met toegang tot de systemen zodat ongemerkt criminele activiteiten kunnen worden uitgevoerd onder valse naam. Ik vergelijk dit altijd maar met het rondrijden met mijn kentekenplaten op een andere auto. Ik heb er zolang er niets gebeurt geen last van, maar ik loop wel ongemerkt een risico.

In de productrisicoanalyse onderkennen we drie doelgroepen, namelijk de business (product owner), beheer(ders) en gebruik(ers). Iedere doelgroep heeft zijn eigen argumenten waarom met Beveiligbaarheid meer of minder risico wordt gelopen. Als we kijken naar de attributen binnen Beveiligbaarheid ligt dit meer genuanceerd. Onweerlegbaarheid is misschien voor de product owner belangrijk, maar voor een beheerder wellicht niet of nauwelijks. Hierover communiceren, zodat men van elkaar weet waarom wat voor de een belangrijk is en voor de ander niet, is dan ook zeer belangrijk.


In mijn komende blogs zal ik geregeld terugkomen op vaststellen de business value, welke prioriteit geven we aan het attribuut en hoeveel inspanning (omvang) denken we nodig hebben om de risico’s te elimineren of te minimaliseren. De business value komt met name van de product owner, risico’s is door alle doelgroepen gezamenlijk te bepalen, de omvang met name door de ontwikkelaars / testers. Als Onweerlegbaarheid belangrijk én risicovol is, dan is het zaak om de criteria met betrekking tot Onweerlegbaarheid te beschrijven, de risico’s die worden gelopen als we niets met Onweerlegbaarheid doen en welke kwaliteitsmaatregelen gaan we inzetten. Niet alles op testen laten aankomen in een van de laatste fasen van het project, dan is het namelijk in veel gevallen te laat.


Definities attributen


Authenticiteit (Authenticity)

  • De mate waarin bewezen kan worden dat de identiteit van een onderwerp of bron is zoals wordt beweerd.
  • De mate waarin een claim over de oorsprong of de auteur van de informatie verifieerbaar is, bijvoorbeeld aan handschrift.

Verantwoording (Accountability)

  • De mate waarin acties van een entiteit getraceerd kunnen worden naar die specifieke entiteit.

Onweerlegbaarheid (Non-repudiation)

  • De mate waarin kan worden bewezen dat acties of gebeurtenissen plaats hebben gevonden, zodat later deze acties of gebeurtenissen niet ontkend kunnen worden.

Integriteit (Integrity)

  • De mate waarin een systeem, product of component ongeautoriseerde toegang tot of aanpassing van computerprogramma’s of gegevens verhindert.

Vertrouwelijkheid (Confidentiality)

  • De mate waarin een product of systeem er voor zorgt dat gegevens alleen toegankelijk zijn voor diegenen die geautoriseerd zijn.

Beveiligbaarheid begint niet pas bij de applicatie of houdt juist op bij de applicatie. Beveiligbaarheid gaat over de gehele keten, van de start van een transactie tot het verwijderen van (verouderde) gegevens. Toegangscontroles door enkel controle op naam en wachtwoord is niet voldoende, dit strekt zich zelfs uit tot het beperken van fysieke toegang. Hoe waardevoller de gegevens zijn voor oneigenlijk gebruik, hoe hoger het risico is dat men loopt op Beveiligbaarheid.


Is Beveiligbaarheid belangrijk, bepaal dan op welke van de onderliggende attributen risico wordt gelopen. Is de kans dat het risico optreedt laag en zijn de faal- en herstelkosten laag, dan lijft Beveiligbaarheid van belang maar kan de inspanning om aan te tonen dat het risico niet aanwezig is, beperkt blijven tot de standaard maatregelen.

 

ISO 25010 – Onderhoudbaarheid

Onderhoudbaarheid – ISO 25010

De laatste (hoedanigheids)categorie in de reeks is onderhoudbaarheid, met name gericht op de ondersteuning tijdens het beheren van de applicatie. Dit is niet alleen relevant voor ná de oplevering aan de beheerorganisatie, maar ook tijdens de ontwikkeling. Dit laatste wordt nog wel eens vergeten. Agile/Scrum geeft bij de tweede sprint al regressie en er moet gezorgd worden dat het bereikte kwaliteitsniveau behouden blijft. Aanpassingen en regressietesten mag dan niet dé vertragende of zelfs de blokkerende factor worden. Continuous Delivery en Continuous Integration stelt zware eisen aan onderhoudbaarheid en beheer mag dan feitelijk ook niet ontbreken tijdens de ontwikkeling. (DevOps).

Definitie van Onderhoudbaarheid (Maintainability)

De mate waarin een product of systeem effectief en efficiënt gewijzigd kan worden door de aangewezen beheerders

Het onderhoud van mijn tuin vergt redelijk veel tijd. Een aantal weken op vakantie en het onkruid tiert welig. Om dit onderhoud te verminderen is het dan ook belangrijk om bij de aanleg van de tuin al rekening te houden met het onderhoud. Heb je dagelijks veel tijd om te tuinieren, dan kan je volstaan met een minder onderhoudsvriendelijke tuin. Als het tuinieren, zoals bij mij, beperkt is tot de zaterdagmiddag, dan het liefst een tuin die zichzelf onderhoudt. Wanneer men het snoeien en bemesten opneemt in de releaseplaning is het tuinonderhoudsplan is een goed eind op weg. TIP: Laat je tuin dus niet aanleggen door een hovenier, wiens businessmodel is gebaseerd op onderhouden van tuinen. Of je moet bijna met pensioen gaan en tijd over krijgen.

Wat geldt voor een tuin, geldt ook in bepaalde mate voor een informatiesysteem. Hier is ook een bepaalde vorm van life-cycle-management gewenst: Onderhoud dat er op is gericht een optimaal presterend systeem te leveren tegen minimale kosten, gerekend over de totale levensduur van het systeem. Een beheerder moet ook kunnen adviseren over verder investeren in het systeem of het vervangen. Om dit op een verantwoorde wijze te kunnen doen, is inzicht nodig in bijvoorbeeld de (te verwachten) operationele kosten van een systeem, de onderhoudskosten van een systeem en de mate waarin het systeem blijft voldoen aan de bedrijfsdoelstellingen. Naarmate de omvang, kosten en belang van het systeem groter worden en het aantal gebruikers, locaties en operationele systeemversies toeneemt, zullen er zwaardere eisen aan onderhoudbaarheid gesteld worden. ISO 25010 heeft een opsplitsing in producteigenschappen, die ik, behalve functionele geschiktheid, allemaal heb toegelicht, en de productkwaliteit tijdens het gebruik van de applicatie. Onderhoudbaarheid gaat vanuit de ontwikkeling, waar de producteigenschappen worden gespecificeerd en gerealiseerd, nagenoeg naadloos over in de kwaliteit tijdens het gebruik.

Definities attributen

Modulariteit (Modularity)

  • De mate waarin een systeem of computerprogramma opgebouwd is in losstaande componenten zodat wijzigingen van een component minimale impact heeft op andere componenten.

Herbruikbaarheid (Reusability)

  • De mate waarin een bestaand onderdeel gebruikt kan worden in meer dan één systeem of bij het bouwen van een nieuw onderdeel.

Analyseerbaarheid (Analysability)

  • De mate waarin het mogelijk is om effectief en efficiënt de impact, van een geplande verandering van één of meer onderdelen op een product of systeem, te beoordelen, om afwijkingen en/of foutoorzaken van een product vast te stellen of om onderdelen te identificeren die gewijzigd moeten worden.

Wijzigbaarheid (Modifiability)

  • De mate waarin een product of systeem effectief en efficiënt gewijzigd kan worden zonder fouten of kwaliteitsvermindering tot gevolg.

Testbaarheid (Testability)

  • De mate waarin effectief en efficiënt testcriteria vastgesteld kunnen worden voor een systeem, product of component en waarin tests uitgevoerd kunnen worden om vast te stellen of aan die criteria is voldaan.

Contact

  • Telefoon

    0318 - 240 044

  • Email

    info@2b4qa.nl

  • KVK

    601.397.73

  • Postadres

    Cuneraweg 322
    3911 RT Rhenen

  • Bezoekadres

    Kerkewijk 31
    3901 EB  Veenendaal

2B4QA BV  (c) 2018