In de maakindustrie is product lifecycle management (plm) vanzelfsprekend en het hierbij horende configuratie management essentieel. Een plm-systeem bevat alle onderdelen en de samenhang hiertussen, voor bijvoorbeeld een te bouwen vliegtuig of auto. Zonder deze productinformatie backbone is productie en onderhoud niet mogelijk.
Zonder goed werkende plm-processen en -systemen is het onmogelijk om te herleiden welk van de duizenden componenten gebruikt moet worden bij onderhoud of reparatie. De monteur moet weten welke vervangende onderdelen hij moet gebruiken bij een bepaald type auto of vliegtuig en waar dit onderdeel relaties mee heeft. Daarom heeft bijvoorbeeld iedere auto een uniek serienummer, waarbij een lijst met voorgeschreven onderdelen hoort. Het is ondenkbaar, zelf onmogelijk, complexe producten zoals auto’s en vliegtuigen zonder de inzet van plm te maken en te onderhouden. Herleidbaarheid is hier het keyword.
Het ontwikkelen van grote it-systemen is een complexe aangelegenheid. In plaats van duizenden fysieke onderdelen worden honderdduizenden of miljoenen regels programmacode geschreven die gezamenlijk het product, het it-systeem vormen. Deze regels code moeten weer, via ontwerpen, terug te herleiden zijn naar de oorspronkelijke eisen. Het in de greep krijgen en houden hiervan op basis van de inzet van plm zou een vanzelfsprekendheid moeten zijn, maar is dat vandaag de dag nog steeds niet. Dit terwijl de complexiteit niet onder doet voor die van de maakindustrie en de maatschappelijke gevolgen van het niet herleiden verder toenemen. Bijvoorbeeld de Toyota Prius die stopt door software fouten, Pinautomaten die niet werken en medische apparatuur die op hol slaat.
Een belangrijk aspect van de productkwaliteit van applicaties is wederom herleidbaarheid of tracebility. Het gaat bij deze herleidbaarheid om het vermogen gerelateerde onderdelen in documentatie en software, zoals functionele en technische eisen, ontwerpen, broncode, documentatie en tests, te identificeren, aan elkaar te relateren en de wijzigingen ervan bij te houden. Bijvoorbeeld; per testsoort moeten de eisen kunnen worden gekoppeld aan de testdocumentatie, zoals het testplan, de specificatie van testontwerp, het testgeval, de testprocedure of het testscript. Traceerbaarheid vertaalt zich door naar alle aspecten van de ontwikkeling, van de manier waarop eisen opgezet worden, de documentatiestandaarden tot en met de installatiescripts en het release management. Vanaf de start van het software-ontwikkeltraject moet daarom met herleidbaarheid planmatig omgegaan worden.
Laten we leren van de maakindustrie en plm ook bij software ontwikkeling structureel inzetten om betere kwaliteit te bereiken.
IT systemen zijn ook complexe producten en de samenstelling moet herleidbaar en schreven zijn. Anders wordt het lastig te beheren en door te ontwikkelen..
auteur is Expert van Computable voor het topic Development.
en dan schrijftie dat. Welke doelgroep heeft computable eigenlijk ?
@Mauwerd
Auteur is directeur van een bedrijf dat geheel toevallig een PLM oplossing heeft.
Oef ik weet al niet eens meer welke revisioning control systemen ik in de loop der jaren ben tegen gekomen… heel wat in elk geval, en de meesten nog open source en gratisch verkrijgbaar ook.
Ik vind het wel opmerkelijjk dat Wilbert verwijst naar de ontwikkeling van embedded toepassingen.
…..
ik dacht zo : een expert vertelt iets nieuws.
Niet iets dat iedereen die een jaar in het vak zit, al lang weet. Nl dat grote ICT systemen gewoon een product zijn, meestal nog complexer dan fysieke en dat je dus deste meer voordeel hebt van een goede documentatie van requirements, design en afhankelijkheden.
@mauwerd: Een groot deel van wat beschreven wordt in het artikel heeft te maken met het ICT deelgebieden Change- en Configuration Management. Die 2 disciplines zijn de motor achter PLM. Ook in de beheerswereld van IT-systemen en infrastructuren zie je dit terug, bijvoorbeeld in de ITIL beschijvingen rondom het gebruik van een CMDB.
Een verschil wat ik meerdere malen heb gezien is dat de nauwkeurigheid en actualiteit van de data in de maakindustrie vele malen hoger is dan die aan de beheerskant.
Dit is op zich ook heel makkelijk te verklaren. Als er in de maakindustrie iets niet klopt in de data van je PLM systeem, loop je risico dat je productieproces stilvalt, en dat is doorgaans wel het laatste wat men wil.
@Ewout: zover is SQS ken bieden ze geen PLM oplossingen, maar hebben ze wel een aantal consultants op dat gebied.
Terug naar de inhoud: een leuk artikel dat me heel erg aanspreekt; niet in de laatste plaats omdat PLM één van mijn expertise-gebieden is.
Dat PLM toegevoegde waarde heeft is absoluut een feit. De uitdaging is echter om de goede gewoonten uit de PLM wereld te vertalen naar jouw ontwikkelomgeving. Voor een medisch apparaat is het formeel vastleggen van traceerbaarheid en bewijslast een must, bij een app om je boodschappenlijstje mee te kunnen maken zal niemand er om malen.
Ook het effect van een mogelijke fout speelt mee bij de keuzes. Als de app van computable een keer crasht op mijn telefoon is dat hooguit vervelend. Als de airbag van je auto spontaan opblaast tijdens het rijden, dan is het effect heel wat vervelender.
Dito voor de economische impact. Wanneer een fabriek stilvalt door een fout in het PLM systeem dan kunnen de kosten al snel de pan uitrijzen.
De naam PLM (Product Lifecycle Management) zelf geeft ook nog een criterium aan. Maak je een eenmalig product, maak je een product met daarop wat patches, maar wordt de vervolgversie weer vanaf de grond opgebouwd, of borduurt de nieuwe release van je product telkens voort op de vorige? De vorm van productontwikkeling is daarmee ook zeer sterk bepalend voor de mate waarin PLM iets bij kan dragen aan de kwaliteit, en vooral beheersbaarheid, van je werk.
PLM is net zo breed inzetbaar als een Zwitsers zakmes. Maar je moet wel weten hoe je het moet gebruiken!
@PaVaKe: Goede reactie. Als je dit soort dingen in opinie plaatst heb je volgens mij prachtige onderwerpen die graag gelezen worden! We hebben het er vaker over gehad, maar doe het eens een keer,misschien bevalt het en we hebben behoefte aan jouw kennis en inzicht. Door jou reactie ben ik het artikel nog een keer gaan lezen met andere ogen.
OnTopic: Ik zie de meerwaarde van PLM in software absoluut, zeker als deze embedded is. Bij de software die ik ontwikkel is dit wel een enorme uitdaging die de kosten wel flink omhoog zal drijven omdat je heel actief “governance” zal moeten uitvoeren omdat mijn software zeer veel externe componenten gebruikt zoals webservices en deze bijna maandelijks veranderen ook zitten er componenten in die automatisch updaten.
PLM principes zijn goed bruikbaar alleen in de Software zullen er wel aanvullende principes en methodes nodig zijn om dit mogelijk te maken omdat de uitdaging anders is.
@PaVeKa
Ik denk dat de kans op schadeclaims bij consumentenprodukten tengevolge van fouten in het produktieproces vele malen groter is dan in de software sector. In de softwaresector worden bugs nu eenmaal getolereerd zolang ze geen businessprocessen verstoren.
@PaVaKe
Hoewel ik je opmerking onderschrijf over ITIL is dat tegenwoordig echter een closed loop service lifecycle proces dat tot doel heeft om de dienstverlening continu te verbeteren. Hierbij gaat het dus niet zo zeer om de code zelf maar het geheel van alle CI’s die samen een oplossing vormen. En inderdaad zorgen alle snel wisselende oplossingen zoals mobiele apps, virtuele wereld van cloud en mobility inderdaad voor uitdagingen in Change- en Configuration Management. De uitdaging in informatieverwerking die ook in dit artikel zit omdat kennis macht is en daarom vind ik de titel fout omdat het om de herleidbaarheid van fouten zou moeten gaan.
Want bij niet werkende pinautomaten denk ik, mede door een aantal spraakmakende verstoringen hiermee vorig jaar, eerder aan een organisatorisch dan procesmatig probleem. Want uiteindelijk kunnen we nog zulke mooie processen hebben, de theoretische kaders dienen wel werkbaar en controleerbaar te zijn. Maar zoeken naar de ‘root cause’ wordt om economische en politieke reden nog weleens achterwege gelaten omdat het vervangen van een niet goed werkend product soms te duur is. Het is dan bijvoorbeeld goedkoper om slachtoffers van skimming achteraf te compenseren in plaats van een veiliger systeem uit te rollen.
@Henri
Ik vind je reactie nogal verwarrend omdat jij vaak juist het tegenovergestelde propageert, de herleidbaarheid van software(fouten) met de abstractie van cloud computing is helemaal niet meer interessant of in ieder geval grotendeels onmogelijk. En als het wel wenselijk of mogelijk is gaan de kosten blijkbaar omhoog waardoor de cloud misschien helemaal niet meer interessant is. En het gebruik van externe componenten die maandelijks veranderen zorgt ervoor dat je niet verder komt dan beheerSbaar en beheerbaarheid wel kunt vergeten;-)
@Pascal
Versiebeheer is slechts een onderdeel van PLM….
Daarbij zit er nogal een verschil tussen de diverse versiebeheers-tools en configuration management tools
In de hedendaagse ALM/PLM tools kun je alle artefacten van requirement tot release aan elkaar knopen in één geïntegreerde omgeving met één userinterface. Is net wat meer dan alleen versiebeheer zeg maar :p
Volgens mij worden er in dit artikel wel heel verschillende zaken over één kam geschoren. In de voorbeelden van de maakindustrie, vliegtuigen en autos, zijn er heel veel, net verschillende versies van hetzelfde. Die in de loop van de tijd veranderen. Door onderhoud, reparaties en in sommige gevallen upgrades.
Dat deelt slechts heel weinig karakteristieken met een groot software systeem, dat in zijn aard uniek is.
Daar waar voor de maak industrie configuratie management de kern is, is in de software industrie requirements management, en daarvan afgeleid test management, beheer van test data sts etc essentieel. Kortom, ik zie een betoog dat gericht is op het verkopen van eigen producten met een argumentatie die niet gehinderd wordt door veel praktisch inzicht.
BTW ik ben vliegtuigbouwlundig ingenieur met ervaring op het gebied van vliegtuig-onderhoud en heb tevens de afgelopen jaar in een grote veelheid van rollen bijgedragen aan software ontwikkeling en onderhoud.
Ik ken beide diciplines goed, en moet concluderen dat de verschillen aanmerkelijk groter zijn dan de overeenkomsten.
Mijn voorstel zou zijn: herleidbaarheid is cruciaal, dus requirements management en configuratie management zijn de belangrijkste gebieden voor software ontwikkeling, uiteraard onmiddelijk gevolgd door/aangevuld met test management