Managed hosting door True

NEN maakt richtlijn voor oplevering software

 

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4996227). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


Partnerinformatie
 

Reacties

Hop gaan we weer. We bedenken gewoon weer een norm voor de reeds bestaande normen. Kan men straks weer tegen professionals zeggen dat men daar aan moet voldoen. Geen enkel gevoel voor gevolgen die dat straks zakelijk weer met zich mee brengt.

@NumoQuest: ik snap je reactie, maar hij is niet terecht. Een praktijkrichtlijn is juist een combinatie van bestaande normen die in samenhang 'werkbaar' worden gemaakt.
En zeker is er gevoel voor de gevolgen, omdat zoals het artikel zegt "zaken uit open standaarden en relevante publicaties van andere partijen en/of initiatieven in de sector" worden meegenomen.

Ik werk mee aan deze praktijkrichtlijn en weet daardoor dat er behoefte aan bestaat.

"normcommissie ‘Software and systems engineering’, het nationale platform voor normalisatiewerk op het gebied van software- en systeemontwikkeling"

Aan de hand van de naam weet je al wat je er aan heb :-P
Laat nu de buitenlandse concurrentie maar komen. Nederland kennisland.

@ Leen Blom
Waarom zou je een verzameling moeten gaan maken wanneer men heel vaak de wetmatigheden van de materie, waarop IT telkens word gebouwd, niet kent en niet volgt?

Je hebt namelijk al een 'werkbare' norm die in 75% van d gevallen niet eens word gehanteerd omdat met 'o zo graag' bezig is met het bedenken van nieuwe normen of methoden.

Laat men eerst maar eens gewoon bij de basis beginnen en die goed uitvoeren, dan heb je de meest krachtige norm.

@mauwerd en @NumoQuest: waar zijn jullie nu precies op tegen? Het gaat om het bundelen van kennis en praktisch maken daarvan voor bedrijven. Precies wat je wilt NumoQuest.
Als je het zo goed weet, kom dan met die kennis en bring het in. Je hebt hiermee een platform dat veel groter is dan de lezers van fora van Computable.nl
En voor @mauwerd: NEN - CEN - ISO/JTC1 is international dus wat bedoel je? Ook erg Nederlands om de goede dingen van ons landje altijd maar af te breken. In Nederland gebeuren op IT-gebied best goede dingen, ik denk dat we ons vermogen om globale zaken te combineren en op kleinere schaal uit te voeren niet moeten bagatelliseren, dat kan een prima exportproduct worden.

@Leen,
Mijn reacties komen niet tot stand na een gedegen hoogstaand onderzoek met hoor en wederhoor.

Het is meestal meer iets wat me zomaar te binnen schiet.
En dat is in dit geval dat ik in de loop der jaren nogal wat documenten heb gelezen, waar ik na zo'n 30 pagina's van dacht, waar ging dit over ?
Meestal hebben die documenten volgende kenmerken :
- abstracte naam, een code of nummer.
- weinig mensen weten van het bestaan ervan.
- als ze er al van weten, dan hebben ze het niet gelezen.
- een of ander bureau/overheid/organisatie heeft belang bij het schrijven van het document.
- een of andere goed betaalde professionele schrijver heeft belang bij het schrijven van het document.
- Inhoud is voor meerdere uitleg vatbaar zijn, zodat iedereen het in eigen voordeel kan gebruiken.
- Inhoud is stijf, zo ver mogelijk van agile manifesto (, dat direct tot doel heeft om werkende software af te leveren waar de klant om gevraagd heeft).

Maar misschien zijn die NEN docs wel heel anders.

@Mauwerd
Je reacties zijn dus 'onderbuikgevoelens' die het resultaat zijn van de gebruikelijke uitkomsten van dit soort initiatieven: We drinken een glas, doen een plas en alles bleef zoals het was. Je scepsis is voor mij begrijpelijk omdat we al een heleboel richtlijnen hebben die genegeerd worden omdat keuzen vaak niet rationeel gemaakt worden. Niet zelden door de 'bullshit bingo' die ons door marketing op de mouw gespeld worden.

@Leen
Mijn grootste bezwaar aangaande richtlijn is dat deze vroeg of laat weer misbruikt doordat er niet meer nagedacht wordt en blind vertrouwd wordt op allerlei nietzeggende nummertjes. Neem als voorbeeld onze voedingsindustrie waar je gek wordt van alle E-nummers en hierdoor niet meer weet wat je nu eigenlijk allemaal eet. Hetzelfde zie je nu al vaak bij aanbestedingen waar dit soort richtlijnen voor leveranciers gewoon een tik in de box zijn en de klant nog niet veel geholpen is.

Ik vind het ook een interessant artikel en ook erg benieuwd naar de NEN standaarden maar waar kan ik die vinden?

@mauwerd Misschien zit er ook iets tussen die heel veel pagina's met teveel detail en dat agile manifesto. Daar ben ik dan benieuwd naar. De onderwerpen lijken wel aardig die beschreven worden, bijvoorbeeld over overdracht en kwaliteit van software.

Richtlijnen zijn prima, maar op het moment dat er veel geld moet worden neergeteld om een hele dure samenvatting in de vorm van een zwart/wit classificatie (zoals met ISO standaarden) te bemachtigen, is de schade al enorm voor middelgrote en kleine bedrijven.. de motor zijn voor nieuwe economie en innovatie. Bijna net zo erg als software patenten.

Het is als religie; op een gegeven moment gaat het niet meer om de inhoud maar alleen nog over de regels zelf.

@Ewout: ik begrijp je bezwaar als het gaat om nietszeggendheid. Zo'n praktijkrichtlijn is een handreiking om bepaalde bestaande normen eens in het kader te zetten voor de klus die je moet klaren.

Een voorbeeld: iedereen kent de nummers van de normen voor kwaliteit: vroeger 9126 en nu de normen 250xx. Ik denk dat weinig mensen ze lezen. Toch worden ze gebruikt als een soort garantie of het afdwingen daarvan.
De richtlijn die wordt opgesteld pakt dit op voor de volgende klus: de ene partij neemt een software system van de andere partij over om te onderhouden (functioneel en technisch applicatiebeheer, niet per se operations). Dat betekent dat de overnemende partij een heleboel risico's moet inschatten.

Wanneer weet je nu dat je voldoende in kaart hebt gebracht?
Dat wordt voor twee kwaliteitsattributen uit 25010 uitgewerkt, namelijk maintainability en portability. De andere attributen zijn belangrijk bij de totstandkoming van een systeem en zijn daarom voor deze klus van minder belang (worden wel als voldoende voor de eigenaar beschouwd, als die het al een slecht functionerend systeem vindt dan moet je je achter de oren krabben).
Wat de praktijkrichtlijn ook aangeeft is hoe en waar je bepaalde dingen kunt laten toetsen: certificering, een audit of gewoon goed het inventarisboek doorakkeren.
Het resultaat van zo'n bepaling is dat je weet waar welke risico's zitten. De overnemende partij en de eigenaar van het systeem kunnen daardoor meer objectief over de toekomstige kosten onderhandelen.

Ik denk dat een aantal van de reageerders dit best op eigen kracht en met de eigen kennis en ervaring ook zouden kunnen. De meerwaarde van de praktijkrichtlijn is dat niet-it-bedrijven die een systeem uitbesteden handvatten hebben om zo'n advies te beoordelen.
En ik hoop dat sommige experts er nog wat van zullen opsteken... Ik heb er veel van geleerd in ieder geval.

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.

Vacatures bij NEN
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×