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.
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 😛
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.