Wat is een geweldig ontwerp

Hoe weet je instinctief wat een geweldig ontwerp is?? We hebben allemaal een gevoel in onze verschillende culturen van wat een geweldig staaltje architectuur is. We waarderen allemaal mooie, Scandinavisch ontworpen huishoudelijke voorwerpen. In technologie accepteren we nu allemaal de grafische gebruikersinterface als normaal, maar het was een briljante openbaring toen het voor het eerst verscheen (uitgevonden door Xerox maar eerst met succes geëxploiteerd door Apple). En Apple is uitgegroeid tot 's werelds grootste bedrijf qua marktkapitalisatie op basis van deze gebruiksvriendelijke interfaces en zijn elegant ontworpen i-pods, i-telefoons, enzovoort.

De gemeenschappelijke kenmerken van geweldige ontwerpen zijn geschiktheid voor een bepaald doel (of ‘functionele geschiktheid’) gecombineerd met eenvoud en elegantie, of zelfs schoonheid, als dat mogelijk is.

De basisprincipes van de COSMIC-methode

Het is interessant om tegen deze achtergrond na te denken over de ontwikkeling van de COSMIC-methode. De uitgangspunten zijn voor het eerst uitgewerkt tijdens een informele bijeenkomst in 1999 bij Mont-Tremblant, ten noorden van Montreal, Canada door een aantal experts op het gebied van softwarestatistieken met een lange ervaring in het meten van functionele afmetingen. Een aantal van ons was lid geweest van de ISO-werkgroep over de principes van FSM.

Ons doel was om een ​​FSM-methode te ontwikkelen die op bedrijven kan worden toegepast, realtime- en infrastructuursoftware met dezelfde concepten voor alle domeinen. We hebben snel gekozen voor een softwaremodel dat bestaat uit functionele processen die moeten reageren op gebeurtenissen in de wereld van de gebruiker. En functionele processen bestaan ​​uit ingangen en uitgangen die gegevens in en uit de software verplaatsen en schrijf- en leesbewerkingen die gegevens van en naar permanente opslag verplaatsen. De maateenheid was een enkele gegevensverplaatsing. De maatschaal was open. Hoewel om praktisch bruikbaar te zijn, COSMIC-gemeten maten moeten correleren met ontwikkelingsinspanningen, we zagen geen noodzaak om gewichten toe te passen op de vier soorten gegevensbewegingen. Instinctief, we waren van mening dat de vier soorten gegevensbewegingen elk ongeveer dezelfde hoeveelheid functionaliteit voor hun rekening namen.

Praktische problemen

In sommige opzichten, dit eerste ontwerp was de gemakkelijke taak; het ontwerp leek elegant eenvoudig. Echter, we moesten nu een ‘Meethandboek’ schrijven met daarin de principes, regels en definities zodat Meters de methode in de praktijk kunnen toepassen. Hier begonnen de problemen. Bijvoorbeeld:

• Omdat we ernaar streefden om software in elke laag van een architectuur te kunnen meten, we hadden een definitie nodig van een 'laag'. Onze eerste poging in v2.1 resulteerde in een definitie van: 94 woorden en 8 Principes voor het onderscheiden van lagen. En deze karakterisering van een laag was uniek voor COSMIC; het kan bijvoorbeeld niet worden gebruikt om de lagen van een architectuur met drie lagen te beschrijven. Door v4.0.1 van de methode, de definitie is vereenvoudigd tot: 8 woorden, er zijn 5 principes, en we kunnen deze gebruiken om de lagen van elke architectuur te beschrijven.
• We realiseerden ons al snel dat de methode verschillende groottes van dezelfde software kon meten, afhankelijk van het 'gezichtspunt' van wie of wat wordt gedefinieerd als de 'gebruikers'. In v2.2 van de methode, we hebben twee standaard gezichtspunten gedefinieerd, die van de Eindgebruiker en van de Ontwikkelaar, en erkende dat er misschien andere gezichtspunten zijn. Maar tegen v3.0 realiseerden we ons dat deze terminologie onbevredigend was. Bovendien zou de uitdrukking 'FUR' kunnen worden geïnterpreteerd als de 'vereisten van de functionele gebruikers'. Dus nu specificeert de Meetstrategie-fase dat u eerst de functionele gebruikers moet definiëren, waarna u de functionaliteit meet (de vacht') dat die gebruikers nodig hebben. door te generaliseren, we zouden de noodzaak kunnen vermijden om 'meetstandpunten' te definiëren.
• Aanvankelijk hadden we moeite om regels te beschrijven om interessante objecten te onderscheiden, vooral bij in- en uitgangen. We introduceerden het concept van 'voorbijgaande objecten van belang', in tegenstelling tot de objecten van belang waarover persistente gegevens worden opgeslagen. Dit was een vergissing. Het is de gegevensgroepen verplaatst door in- en uitgangen die van voorbijgaande aard kunnen zijn, niet de objecten van belang. The latter are real things in the real world that are of interest to the functional users. Whether data describing an object of interest is stored persistently or exists only transiently when moved by an Exit is immaterial.
• We initially defined the measurement unit as a ‘COSMIC functional size unit’ (or Cfsu) to be precise but the abbreviation was not easy to pronounce. Later we accepted it was much simpler to call the measurement unit a ‘COSMIC Function Point’ (or CFP).

Improvement by simplification

There are many other examples like these. The lesson from this experience is that each step along the road to improve the method description has been achieved by simplification. The basic design and its principles have barely changed since the method was first designed. Inmiddels is de methode toegepast om de FUR van een enorm scala aan software uit alle domeinen te bepalen, op alle niveaus van ontbinding. En ondanks dat er geen inspanningsgerelateerde gewichten worden toegepast op de vier soorten gegevensverplaatsing, we hebben nu veel ervaring dat functionele maten gemeten in CFP zeer goed correleren met ontwikkelingsinspanningen.

Het is in de loop der jaren enorm bevredigend geweest dat wanneer we een probleem hebben ondervonden bij het definiëren van wat we bedoelen of bij het oplossen van een bepaald meetprobleem, de oplossing is altijd gevonden door terug te gaan naar de basisontwerpprincipes en te zoeken naar de eenvoudigste verklaring of oplossing. Dit suggereert voor mij dat we een geweldige, ‘toekomstbestendig’ ontwerp.

Over de auteur

Charles Symons is oprichter en voormalig voorzitter van de Common Software Measurement International Consortium. lAls u delen van de Meethandleiding of enige andere COSMIC-publicatie moeilijk te begrijpen vindt, laat het hem weten aub, via mpc-chair@cosmic-sizing.org. COSMIC is altijd op zoek naar vereenvoudiging en verbetering.

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.