kwaliteitskenmerken in softwarearchitectuur

Afbeelding 1. Monument Valley spel

laten we de softwarearchitectuur verder onderzoeken. We hebben overwogen wie een softwarearchitect is, welke soorten softwarearchitecten er bestaan en wat de architect moet doen aan het begin van een project. Wanneer belanghebbenden worden geïdentificeerd en eisen worden verzameld, rijst de vraag wat te doen. Nadat functionele eisen zijn geformuleerd — of het antwoord op de vraag “wat het systeem moet doen” is gevonden, begint de software-architect te zoeken naar het antwoord op de vraag “hoe het systeem moet werken.”Niet-functionele eisen helpen in dat geval.

  1. het pad om softwarearchitect te worden
  2. Stakeholders in softwarearchitectuur
  3. typen softwarearchitecten
  4. kwaliteitskenmerken in softwarearchitectuur
  5. documentatie in softwarearchitectuur
  6. certificaten in softwarearchitectuur
  7. boeken in softwarearchitectuur
  8. spiekbrief systeemontwerp

Wat zijn de niet-functionele vereisten?

niet-functionele vereisten (NFRs) definiëren de criteria die worden gebruikt om het hele systeem te evalueren, maar niet voor een specifiek gedrag, en worden ook wel kwaliteitskenmerken genoemd en in detail beschreven in architecturale SPECIFICATIES.

alle NFRs kunnen in twee hoofdcategorieën worden verdeeld:

  • NFRs die het systeemgedrag, het ontwerp en de gebruikersinterface tijdens het werk beïnvloeden.
  • NFR ‘ s die van invloed zijn op de ontwikkeling en ondersteuning van het systeem.

een situatie waarin het systeem de gewenste combinatie van kwaliteitskenmerken heeft, bijvoorbeeld bruikbaarheid en prestaties of betrouwbaarheid, toont het succes van de architectuur en de kwaliteit van de software. Bij het ontwerpen om aan alle eisen te voldoen, is het essentieel om rekening te houden met de impact op andere attributen en compromissen te vinden tussen de eisen. Samen met dit, de waarde of prioriteit van elk kenmerk verschilt van systeem tot systeem. Dit artikel behandelt niet alle bestaande attributen, maar die gedekt kan een goede start voor het ontwerpen van uw systeem.

typen kwaliteitskenmerken (ISO/IEC FCD 25010 diagram)

om de typen kwaliteitskenmerken te bekijken, kunnen we een diagram van ISO gebruiken 25010:

Afbeelding 2. ISO / IEC FCD 25010 diagram

deze standaard beschrijft de kwaliteitskenmerken van een softwareproduct. Vervolgens zullen we kijken naar wat precies elk attribuut afzonderlijk betekent.

Performance toont de reactie van het systeem op het uitvoeren van bepaalde acties voor een bepaalde periode.

er zijn twee manieren om prestaties te meten:

  • latentie: tijd besteed aan het reageren op een gebeurtenis
  • kanaalcapaciteit. Het aantal gebeurtenissen dat op een bepaald moment plaatsvindt.

in de praktijk omvatten de mogelijke prestatie-indicatoren bijvoorbeeld::

  • gemiddeld / maximum aantal systeemgebruikers per tijdseenheid.
  • gemiddelde laadtijd van pagina ‘ s.
  • gemiddelde uitvoeringstijd van de methode.

hier vindt u interessante latency nummers die elke ontwikkelaar zou moeten kennen.

prestatieproblemen groeien vaak uit tot problemen die alles kunnen beïnvloeden, van de capaciteit van de server of hoe u uw front-end ontwikkelt tot de efficiëntie van databasevragen of de capaciteit van communicatiekanalen.

prestaties worden bijna altijd opgenomen in de lijst van kritische kwaliteitskenmerken die door de architect in aanmerking moeten worden genomen, aangezien het het gehele systeem beïnvloedt en vele delen van de architecturale oplossing kan beïnvloeden. Daarom kunt u op internet een groot aantal voorbeelden vinden van hoe om te gaan met prestatieproblemen.

interoperabiliteit is een kenmerk van het systeem of een deel van het systeem dat verantwoordelijk is voor de werking ervan en de overdracht van gegevens en de uitwisseling ervan met andere externe systemen. Een goed ontworpen systeem vergemakkelijkt de integratie met systemen van derden. Om de interoperabiliteit te verbeteren, kunt u gebruik maken van goed ontworpen externe interfaces, standaardisatiesystemen, enz.

natuurlijk zijn er veel problemen voor interactie:

  • verouderde externe systemen.
  • verschillende formaten van gegevens in soortgelijke externe systemen.
  • verschillende versies van de API in externe systemen.
  • achterwaartse compatibiliteit van de API voor integratie.
  • slechte kwaliteit en gebrek aan normen voor externe systemen.

interoperabiliteit kan niet worden genegeerd. In het beste geval moet u extra lagen maken voor de interaction API. In het slechtste geval zal het nodig zijn om het hele systeem opnieuw op te bouwen.

Usability is een van de meest essentiële attributen, omdat gebruikers, in tegenstelling tot andere attributen, direct kunnen zien hoe goed dit attribuut van het systeem is uitgewerkt. Een van de kritieke problemen van bruikbaarheid is te veel interactie of te veel acties die nodig zijn om een taak te volbrengen. Incorrecte opeenvolgingen van stappen in meertraps interfaces zijn ook een probleem van bruikbaarheid. Gegevenselementen en besturingselementen kunnen worden ontworpen niet volgens de geaccepteerde patronen van gebruikerservaring, wat ook de interactie compliceert. Als u bijvoorbeeld een iOS — toepassing ontwikkelt, is het belangrijk om de richtlijnen van Apple of de richtlijnen van Microsoft te gebruiken-voor Windows-bureaubladtoepassingen.

voorbeelden van belangrijke indicatoren voor deze eigenschap zijn:

  • Lijst met ondersteunde apparaten, OS-versies, schermresoluties en browsers en hun versies.
  • elementen die gebruikersinteractie versnellen, zoals “sneltoetsen”, “lijsten met suggesties”, enzovoort.
  • de gemiddelde tijd die een gebruiker nodig heeft om individuele acties uit te voeren.
  • ondersteuning van toegankelijkheid voor mensen met een handicap.

betrouwbaarheid is een kenmerk van het systeem dat verantwoordelijk is voor het vermogen om te blijven werken onder vooraf gedefinieerde omstandigheden. Meestal, het systeem mislukt als gevolg van de ontoegankelijkheid van externe elementen, zoals databases, systemen, en netwerkverbindingen.

beschikbaarheid maakt deel uit van betrouwbaarheid en wordt uitgedrukt als de verhouding tussen de beschikbare systeemtijd en de totale werktijd. Belangrijke indicatoren voor deze eigenschap zijn:

  • beschikbaarheid.
  • geplande downtime.
  • de tijd die nodig is om de software bij te werken, enzovoort.

beschikbaarheid wordt vaak uitgedrukt in het aantal negens na de komma, dat wil zeggen negens van beschikbaarheid (uren / minuten / seconden)):

  • 2 9 ‘ s (99%) = tot 87,6 h / 5256,0 m / 315360,0 seconden downtime per jaar.
  • 3 9 ‘ s ( 99,9%) = tot 8,76 h / 525,6 m / 31536,0 seconden downtime per jaar.
  • 4 9 ‘ s (99,99%) = tot 0,876 h / 52,559999999999995 m / 3153,6 seconden downtime per jaar.
  • 5 9 ‘ s (99,999%) = tot 0,0876 h / 5,256 m / 315,36 seconden downtime per jaar.
  • 6 9 ‘ s (99,9999%) = tot 0,00876 h / 0,5256000000000001 m / 31.536 seconden downtime per jaar.
  • 7 9 ‘ s ( 99,99999%) = tot 8,76 E-4h / 0,05256 m / 3,1536 seconden downtime per jaar.

beschikbaarheid is bijvoorbeeld een van de belangrijkste criteria voor de tier-ranking van datacenters in de VS.

Security is verantwoordelijk voor het vermogen van het systeem om de kans op kwaadaardige of toevallige handelingen en de mogelijkheid van diefstal of verlies van informatie te verminderen. Verschillende maatregelen worden gebruikt om systemen te beschermen: authenticatie, encryptie, audit, en anderen.

voorbeelden van deze eigenschap in het werk van het systeem zijn::

  • het vermogen van het systeem om DDoS-aanvallen te detecteren en hierop te reageren.
  • beperkingen van gebruikerstoegang door authenticatie/autorisatie.
  • preventie van SQL-injectie.
  • versleuteling van wachtwoorden en inhoud.
  • beveiligde verbinding.

onderhoudbaarheid is het vermogen van het systeem om veranderingen te ondersteunen. Wijzigingen kunnen verband houden met nieuwe bedrijfsvereisten of het corrigeren van oude fouten en van invloed zijn op systeemcomponenten of afzonderlijke methoden. Ook, onderhoudbaarheid van invloed op de tijd die nodig is om het systeem te herstellen na een storing. Overmatige afhankelijkheden tussen componenten hebben een zeer negatief effect op de onderhoudbaarheid. Bij het programmeren is er een notie van anti-patroon spaghetti code, wat overmatige samenhang in de code betekent. In de architectuur bestaat zoiets niet, maar architectuur is in deze zin heel dicht bij programmeren. Het is vanwege de maintainability attribuut dat dergelijke concepten als scheiding van verantwoordelijkheid, microservice architecturen, en modulariteit zijn verschenen. Tegelijkertijd beïnvloedt dit kenmerk niet alleen ontwikkelingsprocessen, maar ook managementprocessen (bijvoorbeeld het splitsen van teams in productgerelateerde onderdelen).

Modifiability bepaalt hoeveel veelvoorkomende wijzigingen in het systeem moeten worden gemaakt om wijzigingen aan te brengen aan elk item. Het ideaal is het geval waarin elke verandering slechts één element beïnvloedt.

testbaarheid laat zien hoe goed het systeem het uitvoeren van tests mogelijk maakt, volgens vooraf gedefinieerde criteria. Naast het testen van de prestaties maakt testbaarheid het mogelijk om het systeem effectief op te splitsen in subsystemen.

de belangrijkste indicatoren voor deze eigenschap zijn:

  • percentage van de dekking met modulaire, integratie-of eenheidstests.
  • de definitieve lijst van vereiste testomgevingen en de definitieve lijst van gebruikte testmethoden (handmatig/automatisch, regressie, integratie, enz.).

andere fundamentele kwaliteitskenmerken vallen niet onder de standaard, maar kunnen in dit artikel niet worden genegeerd.

schaalbaarheid is het vermogen van het systeem om belastingstijgingen te verwerken zonder de prestaties te verminderen, of de mogelijkheid om de belasting snel te verhogen.

er zijn twee manieren om schaalbaarheid te verbeteren:

  • verticaal: om te vergroten voegen we meer bronnen toe, zoals geheugen, schijven of processors in één systeem.
  • horizontaal: we verhogen het aantal rekeneenheden en delen de belasting.

de sleutelindicatoren voor het meten van deze eigenschap zijn::

  • als het systeem zorgt voor horizontale schaling.
  • de tijd die nodig is om de schaalgrootte te verhogen, in seconden.
  • beperkingen bij het schalen: het aantal servers of de netwerkcapaciteit.
  • mogelijkheid om te schalen: de toename van het aantal transacties of de hoeveelheid inhoud.

en dit is slechts een klein deel van de indicatoren die u moet volgen bij het ontwerpen. Schaalbaarheid is een van de meest essentiële kenmerken, ongeacht wat de fase van het project is.

herbruikbaarheid is een kans op het gebruik van een component of systeem in andere componenten/systemen met kleine of geen verandering. Scheiding van verantwoordelijkheden, modularisatie, het verminderen van copy-paste gaat allemaal over herbruikbaarheid. Het kopiëren van code, of erger nog, het gebruik van verschillende componenten voor hetzelfde resultaat in verschillende modules, is een van de grootste problemen van herbruikbaarheid.

Supportability is het vermogen van het systeem om nuttige informatie te verstrekken voor het identificeren en oplossen van problemen. De belangrijkste problemen bij het waarborgen van de draagbaarheid kunnen met de volgende middelen worden aangepakt::

  • geen diagnose: hoe de activiteit en prestaties van het systeem worden gecontroleerd. Het omvat verschillende soorten logging.
  • geen hulpmiddelen voor het oplossen van problemen: dit omvat back-ups, verschillende systemen voor het maken van snapshots van het systeem, en hulpmiddelen voor het controleren van het systeem. Wanneer het systeem uitvalt, is het altijd prettiger om te wachten op een automatische herstart dan om het probleem handmatig op te lossen.
  • geen statuscontrole: dit omvat een verscheidenheid aan systemen voor het meten van compilatietijd, implementatietijd, databasegrootte of grootte van mobiele toepassingen.

meestal worden deze in eerste instantie niet in aanmerking genomen bij startende ondernemingen of kleine projecten. De kosten voor het behoud van het attribuut supportability zijn hoog en het resultaat is alleen zichtbaar op grote schaal. Echter, met de groei van het team en het product, Deze eigenschap wordt een van de belangrijkste.

dit artikel bestaat uit twee delen. In het tweede deel, laten we eens kijken naar de benaderingen over het prioriteren van kwaliteitskenmerken en de vraag beantwoorden waarom het zo belangrijk is om de juiste prioriteiten te kiezen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.