Tööstuse digitaliseerimine on ainus võimalus majandustegevuse kaasajastamiseks. Seejuures võib sobilike lahenduste väljatöötamine osutuda suureks katsumuseks.
Digitaliseerimise aluseks on vajaliku riist- ja tarkvara hankimine. Kui riistvara puhul on tavapärane, et tehakse vajalikud tehnilised joonised ja nende abil lepitakse täpsemalt kokku, mida arendada on vaja, siis tarkvara puhul on olukord keerulisem.
Tarkvara arendamisel on arenduseks ja juurutuseks kasutusel mitmeid erinevaid meetodeid. Meetodi valikust sõltub olulisel määral see, kuidas projekti juhtida tuleks ja kuidas sõlmitakse projekti käigus erinevaid kokkuleppeid tarkvarale esitatavate, nii funktsionaalsete kui ka mittefunktsionaalsete, nõuete osas. Arendusprotsess kipub tihtipeale olema loominguline ja elav protsess, mille käigus otsustatakse algsete nõuete osas ümber, tekivad uued nõuded või langevad mõned nõuded ära. Sellest tulenevalt on äärmiselt oluline dokumenteerida, milles tellija ja arendaja kokku lepivad ning seda juba alates lähteülesandest. Vastasel juhul võib tekkida näiteks olukord, kus tellija soovib tarkvara, mis ühilduks ka tellija teiste süsteemidega, kuid kui arendaja seda ei tea, ei tea ta ka sellist lahendust pakkuda. Tulemina võib juhtuda näiteks olukord, kus vajalikud andmed ei jõua õigesse kohta ja selle tulemina ei vasta toodang näiteks toiduohutuse nõuetele. See võib aga kaasa tuua nii varalise kui ka maine kahju.
Dokumenteerimise vajadus ilmneb eriti selgelt siis, kui on vaja asuda kontrollima, kas tehtu vastab sellele, mida sooviti ehk siis testimisel. Testimisega ei saa tuvastada küll kõiki vigu, kuid metoodiliselt lähenedes aitab see vigu varakult avastada ja seeläbi ennetada võimalikku kahju. Näiteks olukorras, kus tarkvara on vajalik metallist komponente lõikava masina juhtimiseks, võib tarkvara viga luua olukorra, kus komponendid ei ole tegelikkuses nõutud suurusega ja tellija ei saagi neid oma toodete valmistamisel kasutada. Samuti võib puudustega tarkvaras olla turvariske, mis võivad viia ärisaladuse lekkeni.
Kokkulepe, kuidas ja millises ulatuses dokumenteerimine toimub, kuidas see üle antakse ning kes ja kuidas testimist teostab, tuleb pooltel selgelt lepingusse kirja panna. Selle tegemata jätmisel võib tekkida olukord, kus tellijal endal puudub arusaam, kuidas süsteem toimib, millised on selle nõuded ning puudub võimekus süsteemi testida. Kokkuleppeta puudub aga arendajal teadmine ja kohustus, mida arendamise käigus teha: kas ja millises ulatuses dokumenteerida, kas on testimise kohustus ja kuidas toimub vigade parandamine. Seadusest tulenevalt on arendajal küll kohustus tarnida lepingutingimustele vastav töö, kuid selge kokkuleppe puudumisel on keeruline tõendada, millised kohustused arendajal täpsemalt olid ja millistele nõuetele töö vastama pidi. Dokumentatsiooni puudumisel ja tarkvara testimata jätmisel ei pruugi aga puudused õigeaegselt välja tulla ning tellijal ei pruugi olla võimalik arendaja vastu nõudeid esitada.
Testimise kohustuses kokkuleppimisel on võimalik kasutada erinevaid lahendusi: kohustada selgelt arendajat testima (ja kokku leppida mahus, ajaplaanis ja metoodikas) või tellida testimine kolmandalt osapoolelt. Juhul, kui testimise kohustus panna arendajale, tuleks läbi mõelda, kuidas reguleerida olukorda, kus arendaja seda kohustust kohaselt ei täida ning see tingib tellijale täiendavat aja- ja rahakulu. Ette võib tulla olukordi, kus arendaja tarnib töö, millel ilmneb puuduseid, mis testimise käigus oleks kindlasti välja tulnud – näiteks mõnele kohustuslikule väljale ei saa midagi sisestada – kuid arendaja on siiski sellise puudusega töö tellijale tarninud. Lahenduseks võib olla leppetrahvis kokku leppimine. Tellides testimise kolmandalt osapoolelt, võiks kaaluda sanktsioone arendaja osas juhul, kui arendaja ei suuda testimise käigus tuvastatud probleeme korduvate katsete järel lahendada ning see tingib täiendavat arendamise ja testimise vajadust.
