NEN is gestart met de ontwikkeling van de Nederlandse praktijkrichtlijn ‘Opleveren en overdragen van software’ (NPR 5325). De richtlijn gaat over het beoordelen van kwaliteit van software en is met name gericht op onderhoud en herbruikbaarheid van software.
Bij het overdragen van software van ontwikkelorganisatie naar beheerorganisatie worden in NPR 5325 twee aspecten ingebouwd: de fysieke overdracht van ‘de doos’ en de overdracht van kennis. Voor de inhoud van ‘de doos’ introduceert de richtlijn drie over te dragen onderdelen, namelijk de bronbestanden, de documentatie en de testware. Kwaliteitscontroles van deze onderdelen moeten het mogelijk maken om meer inzicht te krijgen in de kosten, risico’s, efficiënt en effectief toekomstig onderhoud van software voor de af te sluiten sla’s en contracten.
Consolideren en structureren
De praktijkrichtlijn is een handreiking en gebaseerd op het consolideren en structureren van kennis en het normaliseren van conceptuele zaken uit open standaarden en relevante publicaties van andere partijen en/of initiatieven in de sector. Enerzijds wordt er verwezen naar zaken zoals de kwaliteit van software (NEN-ISO/IEC 25010), software life cycle processen (NEN-ISO/IEC 12207), software onderhoud (NEN-ISO/IEC 14764) en de richtlijn bij outsourcing (NEN-ISO 37500). Anderzijds worden publicaties opgenomen van partijen en hun verschillende evaluatiemethoden voor software.
Input richtlijn
De richtlijn wordt opgesteld door de normcommissie ‘Software and systems engineering’, het nationale platform voor normalisatiewerk op het gebied van software- en systeemontwikkeling. De commissie organiseert binnenkort drie workshopsessie om input te verkrijgen van software-inkopers, kwaliteitsmanagers, ontwikkelaars, gecertificeerde instellingen, onafhankelijke auditors, testers en organisaties die software onderhouden. Gemiddeld duurt het ongeveer een jaar voordat een praktijkrichtlijn klaar is voor oplevering.
Leen, goed om te zien hoe je het voor een standaard opneemt en ben het voornamelijk met je eens.
Gebouwen, apparaten, infrastructuur zaken moeten aan bepaalde standaarden voldoen, als dit er niet was zou de wereld een stuk gevaarlijker zijn. Nu de digitale wereld steeds meer impact heeft op de realiteit lijkt het me dus ook logisch dat er standaarden voor komen of wettelijke plichten om aan die standaarden te voldoen. De impact van falen kan namelijk net zo desastreus zijn als falende apparaten of onderdelen van de infrastructuur,
Zou ik mijn werk nog net zo leuk vinden als ik aan deze standaarden moest voldoen? Waarschijnlijk niet.
However, ieder bedrijf dat voor het grote publiek of bedrijven software produceert doet er wijs aan om ervoor te zorgen dat de kennis over deze standaarden aanwezig is. Anders gezegd, het niet op de hoogte zijn van de standaarden of maar wat aan rommelen zou nog wel eens een duur risico blijken.
Software engineers kunnen zoals Leen zegt er nogal wat van opsteken om beter te worden in het werk dat ze doen. Daarnaast leer je daarmee ook kijken door een andere bril en niemand wordt daar dommer van.
Nu is ook meteen de kans om zonder kosten een workshop te volgen: http://goo.gl/mjRUud
Waar ik wel in geloof is dat de materie breder beschikbaar zou moeten zijn en hoewel de basis op schrift gesteld is vind ik dat het eigen maken van de stof laagdrempeliger gemaakt moet worden, bijvoorbeeld met Youtube-filmpjes die de principes gewoon in mensentaal uitleggen… de beste manier om een concept van draagvlak te voorzien…
Heb nog even rondgekeken op de NEN-site en dat was erg leerzaam en vermakelijk. Het gaat om standaarden op allerlei vakgebieden. Via de NEN kwam je bij de ISO normen terecht, het NEN als Nederlandse standaarden bureau. Vraag is ook, welke meerwaarden levert het NEN op die ISO norm? Maar als het over breder beschikbaar maken gaat dan zouden ze ermee moeten beginnen niet van die idiote bedragen te vragen voor ieder document. Want dat is nou wat je verwacht van standaarden, dat ze in ieder geval open zijn. Vraag die ik wel heb, als het over de ict-standaarden gaat, zijn het standaarden die echt praktisch toepasbaar zijn of gaat het meer om een stempel van goed gedrag voor de buitenwacht. Ik ben bang van het laatste.
De Wiki-pagina vond ik het meest informatief, daar kwam ook al naar voren dat meer mensen zich verbazen over dat zoveel betaald moet worden voor een document.
http://nl.wikipedia.org/wiki/NEN
@Henri Ik zag die uitnodiging om mee te praten over de NPR 5325 standaard ook staan en die was weer gratis. Dat is misschien wel verstandig om wat feedback te krijgen.
De leuke links van de NEN-site vond ik deze:
http://www.nen.nl/Normontwikkeling/Doe-mee/Normcommissies-en-nieuwe-trajecten/Normcommissies-ICT.htm
en deze:
http://www.nen.nl/Over-NEN/Organisatie-1.htm
Moest denken aan het Bureau van Voskuil denken, als surfend door de NEN-site.
@Leen
Ooit in het veld leerden ze me eens dat er richtlijnen en zichtlijnen zijn, doeltreffend en doelgericht zeg maar. Aangaande je voorbeeld van non-functionele kwaliteitsattributen heb ik al vele malen hier gezegd dat deze niet vergeten mogen worden. Praktijk is echter weerbarstiger om dat de business nu eenmaal alleen maar geïnteresseerd is in de functionele kwaliteitsattributen. En hopelijk onnodig te zeggen dat die keus vaak de uitwisselbaarheid en vervangbaarheid beperkt.
Als ik kijk naar je genoemde NEN-ISO/IEC 25010 dan verbaas ik me er altijd erover dat deze kwaliteitsattributen niet gecontroleerd worden door testen. Je stelt dat sommige reageerders – laten we ze experts noemen – in staat zijn om zonder een NEN richtlijn de juiste keus te maken. Maar vakmanschap heeft een prijs en elke poging om dat te vervangen door de papieren exercitie is kansloos, de lamme gaat de blinde leren lopen.
Ander euvel wat dus telkens weer de kop opsteekt is dat als de kwaliteit naar tevredenheid is er een discussie over de kosten begint. Hopelijk onnodig om te zeggen dat ‘penny wise and pound foolish’ hier nog weleens van toepassing is.
Waar ik mij als Agilist/DevOps’er weer over verbaas is het gemak waarmee mensen zo’n richtlijn als nuttig zien. Ja, ik weet dat er flink wat misgaat bij het overdragen van software, maar dat wordt niet veroorzaakt doordat er geen regels of richtlijnen zijn! Dus regels en richtlijnen zijn niet de juiste maatregel voor het probleem.
De oorzaak mijns inziens ligt in een gebrek aan samenwerking en het nemen van een gezamenlijke verantwoordelijkheid (“You’re on the same team!”). Zelfs al gaat het om een leverancier die iets oplevert: volgens mij ben je als opdrachtgever pas echt tevreden als hij ook in jouw doelen denkt en acteert.
Ergo: werk eerst aan de relatie tussen de mensen en de afdelingen, stem onderling het werk af gebaseerd op wederzijdse doelen, en gebruik zo’n richtlijn als kader rondom de afspraken.
Maar ik zal wel weer veel te simplistisch denken 😉
@Anko: daar gaat het dus niet om. We hebben het niet over de totstandkoming of zelfs het in stand houden van een systeem. Dat kan prima en ook beter op de manier die je schetst.
Het gaat hier over: welke risico’s loop je en hoe ga je daarmee om als je het systeem van de ene partij weghaalt en bij de andere partij neerlegt. Dat heeft niets met Agile of wat ook te maken.
@Ewout,
Het is heel leuk om met zo technisch mogelijke termen te smijten, die bovendien niet algemeen gebruikt worden. Resultaat: menigeen haakt na één regel al af. Als je daarnaast vakmanschap vergelijkt met een lamme en NEN-richtlijnen met een blinde, terwijl je beide verdedigt, dan spreek je jezelf niet alleen heel erg tegen, maar bedoel je ook iets heel anders dan je schrijft. En daar zit dus een enorme bottleneck. Al die werk- en projectgroepen van experts zijn vaak niet in staat hun bedoelingen zodanig op papier te krijgen dat een ander er snel naar grijpt en er iets (nuttigs) mee doet. Tussen haakjes, ik ben zelf auteur, maar dan van fantasy :-).
Nifra53,
Hierin zit hem dus de kneep. Het is niet erg als een standaard een onderliggend verhaal heeft wat erg technisch is en waar veel mensen op afhaken, maar vooral dat men ook de moeite neemt om de diepere boodschap op een manier te brengen dat het klikt.
Einstein kon heel droog allemaal dingen op het bord kalken die menigeen in slaap suste. Maar als hij praatte over zijn gedachtenexperimenten konden veel mensen hem niet alleen volgen, ze gingen mee in zijn gedachten zodat er discussie over kwam en dan is het ineens zinvol.
@Nifra53
Ik weet eerlijk gezegd niet precies wat je nu wilt zeggen, wat ik wil zeggen is dat het op papier zetten van een norm nog niet het toetsen ervan is. Betreffende de lamme en de blinde denk ik dat er meer dan genoeg voorbeelden zijn te vinden in alle sectoren als het gaat om normen en de NIET gemeten waarden.