Autor: Indrek Keskküla, Krakuli elektroonikainsener
Taaskord avaldame Indrek Keskküla Elektroonika Disaini blogist postituse, mis seekord tutvustab lähemalt spetsifikatsiooni loomist. Kui on huvi lugeda juba järgmiseid mõtteid ja soovitusi elektroonika arendus protsessist, siis leiad need tema kodulehelt. Head lugemist!
Esimene samm elektroonika arendamise protsessis on spetsifikatsiooni loomine. Spetsifikatsioon on dokument, mis kirjeldab tellitud elektroonikasüsteemi kliendi vaatepunktist lähtudes. Spetsifikatsioon peab olema spetsiifiline. Ideaalne spetsifikatsioon ei jäta ruumi kahetiseks arusaamiseks ja see peaks olema kõigi osapoolte huvides, et saada vastav dokument nii täpseks kui oskused lubavad.
Kliendi huvi on kindlustada, et ta saab seda, mille ta on tellinud.
Inseneri huvi on arendada seda, mida kliendil vaja on.
Oluline on mõista, et klient ei ole ilmtingimata keegi mõnest teisest ettevõttest. See võib olla tooteomanik või vastutav projektijuht sinu tööandja juures.
Inseneri vaatest on spetsifikatsiooni saamiseks laias laastus kolm viisi.
Kui läheb väga hästi on kliendil märkimisväärne kogemus elektroonikadisaini tellimisel ja ta tuleb sinu juurde valmis spetsifikatsiooniga. Sellel juhul saab kohe alustada projekti planeerimisega ja töö mahu üsna täpselt ära hinnata. Saab planeerida arendusmeeskonna töökoormust, teha detailsed ajaplaanid, defineerida selged tööväljundid ja verstapostid. Sellisele kliendile on võimalik pakkuda kliendi lemmikut ehk fikseeritud eelarvega projekti.
On kliente, kes soovivad, et talle pakutakse abi spetsifikatsiooni kirjutamisel. Siis tuleb tutvuda süvitsi tema vajadustega ja koostöös kliendi meeskonnaga luua selline spetsifikatsiooni, mille alusel suudaksid teha fikseeritud hinnapakkumise. Kliendi jaoks on võlu selles, et tekkinud spetsifikatsiooniga võib küsida hinnapakkumisi erinevatelt arendusbüroodelt.
Täitsa tavaline on ka korraldus, kus spetsifikatsioon tekib töö käigus. See on jagatud ja elav dokument, kuhu pannakse kirja viimased kokkulepped vastavalt sellele, kuidas need tekivad. Projektiga hakatakse pihta, insener tuvastab koha, kus on vaja teha strateegiline tehnoloogiavalik, toimuvad arutelud, tehkase otsus ja jätkatakse kuni järgmise otsustuskohani. Arusaadavalt ei ole sellisel juhul võimalik kuidagi prognoosida, kui palju aega ja raha projekti lõpetamiseks kulub. See lähenemine sobib kliendile, kellel on palju raha, aega ja kes alles otsib seda õiget lahendust, mida turule pakkuda.
Veendu, et klient saaks aru, millise lähenemise ta valib. Samuti veendu, et klient saaks aru, mis on valiku mõju projekti eelarvele ja ajakavale.
Elektroonika spetsifikatsiooni sisu
Nõuete haldus on tegelikult omaette teadus ja viimistletud eriti kõrge tasemeni ennekõike tarkvaraga tegelevates organisatsioonidses. See on süsteem, kus igal nõudel on dokumeteeritud allikas, olulisusmõõdik, kontrollimehhanism, vastutav isik, kontrollija ja omanik. Kui satud tööle projekti, kus selline spetsifikatsiooni ja nõuete haldust rakendatakse, ei pea sina nende nõuetega tavaliselt liiga palju tegelema. Sellistes projektides on enamasti rohkem kui kaks osapoolt ja nõuete halduseks hoopis eraldi rollid ning inimesed.
See, millest siin räägime on projekt, kus kokkulepe on kahepoolne – sinu ja su kliendi vahel. Spetsifikatsiooni eesmärk on kokku leppida, mida looma hakatakse.
Mõistlik on alustada elektroonikasüsteemi konteksti joonisest. See on illustratsioon, mis näitab seadet tema ökosüsteemis. Milliste teiste seadmetega see liidestub ja kuidas? Kas sellele on nuppe, kõlareid, ekraane, antenne? Kuidas nendega liidestutakse? Kust tuleb toide?
Näide allpool
Seda joonist koos kliendiga arendades saab tekitada kindlustunde, et kõik liidesed, mida toode vajab, on kaardistatud. See tekitab ühise arusaamise, mis on toote funktsioonid.
Selles protsessis on inseneril vaja küsida küsimusi. Kahjuks on nii, et küsimuste kvaliteet kipub olema seda parem, mida rohkem on sul kogemust erinevate arendusprojektidega. Ma ei tea metoodikat, mis aitaks garanteeritult küsida paremaid küsimusi. Nõuanne oleks, et ära karda välja näha rumal ja küsi kõike, mis kahtlane tundub. Ära kiirusta hinnangutesse ja ära karda kliendi ideid pehmelt öeldes küsimärgi alla seada, kui need sulle ebaloogilised tunduvad. Küsimuste eesmärk on veenduda ühises arusaamises kliendi vajadustest ja nende vajaduste tagamaadest. Seejuures tuleb loomulikult jääda tagasihoidlikuks. Klient tunneb oma äri tõenäoliselt paremini kui sina. Juhtub, et kliendi ja sinu nägemus ei kattu ning sinu argumendid klienti ei veena, lase oma mõttest lahti ja implementeeri kliendi soov. Lihtsalt ära unusta otsust hoolega dokumenteerida.
Kui kontekst on selge, tuleb vaadata igat liidestust eraldi ja kirja panna selle täpsed tehnilised nõuded. Kirjeldada tuleb kõik elektrilised ühendused, nende pistiku tüübid ja signaalide asukohad pistikus. Ja siis iga signaali või signaalide komplekti (nt liidestus Arduinoga) olulised parameetrid, standardid, ja muu, mis nimetatud liidesega seotud võib olla (bitikiirus, pingenivood, terminatsioonitakisti asukoht, open-collector vs push-pull, vms).
Näiteks peab tootel olema kolm lülitit. Kas piisab, kui paneme plaadile kolm pindmontaaži surunuppu või tuleb kaasata tööstusdisainer, kellega koos õige tehnoloogia valida? Kui oleme tuvastanud ühe tundmatu, milline saab olema seadme füüsiline väljanägemine? Milline saab olema nupuvajutuse füüsiline tagasiside? Milline klõps? Kui tugev vajutus?
Parim viis tundmatut kõrvaldada on eksperiment. Ehita prototüüp ja katseta seda. Simulatsiooni või oletuste teel on raske otsustada kui tugev peab olema display taustavalgus või mis peab olema PWM sagedus selleks, et lambi värelus tajutav ei oleks?
Ka tarkvara funktsioone tuleks spetsifikatsiooni loomise käigus arutada. Riistvara spetsifikatsisoonis tarkvara nõudeid tavaliselt ei käsitleta, kuid töö tarkvara funktsioonide spetsifitseerimisega peaks toimuma paralleelselt riistvara spetsifitseerimisega. Tarkvara nõuetest võib tulla nõudeid riistvarale ja vastupidi. Samuti võib sedasi leida võimalusi toote optimeerimiseks, viies mingeid funktsioone riistrvaralt tarkvarale ja vastupidi. Tuleta seda ülejäänud meeskonnale meelde ja korralda vastavad koosolekud juhul, kui keegi teine ei tee.
Kõik elektriline on kirjeldatud, tuleb mehaaniline pool. Kas eksisteerib nõudeid trükkplaadi kujule, kinnitusmeetoditele ja mehaanilistele koormustele? Kas eksisteerib keskkonnast tulenevaid nõudeid vibratsioonikindlusele, temperatuuridele, IP-klassile? Seejuures, tuleb kokku leppida, kuidas nõuetele vastavust kontrollitakse. Võimalik, et selle osaga ei saagi väga süvitsi minna, sest projekti osa on ka tööstusdisaini loomine.
Siin kirjeldatu ei ole kindlasti ammendav. Spetsifikatsioon võib sisaldada ka nõudeid toodetavusele, testitavusele tootmises, remonditavusele ja toote elueale. See võib sisaldada ka nõudeid sinu organisatsioonile – kas on olemas ISO 9001 vastavustunnistus või kui kiiresti tuleb reageerida tootmisseisakule, kvaliteediprobleemile või nõudele garantiiperioodil, et katki läinud seadet analüüsida.
Samuti ei pruugi kõik siin kirjeldatu olla sinu projektis asjakohane ja vajalik. Lähtu põhimõttest, et kõik projekti jaoks oluline peab saama läbi arutatud.
Spetsifikatsiooni dokument
Kogu eelmises peatükis kirjeldatud ja loodud info peab saama paberile. Tee iga liidese või funktsiooni kohta eraldi peatükk ja kirjelda sinna nummerdatult iga nõue eraldi. Pane igale nõudele number. Sedasi on hiljem lihtsam viidata ja dokumendi ajalugu säilitada.
All üks näide
4. Elektrilised nõuded
4.1 PWM väljundid
4.1.1 Nominaalsagedus on 200Hz
4.1.2 Täitetegur peab olema reguleeritav 1% sammuga 0-100 % -ni.
4.1.3 Maksimaalne väljundvool on 0,5A
4.1.4 Maksimaalne väljundvõimsus on 6W
4.1.5 Väljund peab olema lühise kindel
4.1.6 Väljundi lühis ei tohi häirida ülejäänud seadme tööd
4.1.7 Lühisekaitse ei tohi rakenduda madalamal voolul kui 1A
4.1.8 Väljundi tavaline koormus on 6W 12V GU5,3 LED lambipirn
Ja niimoodi iga liidese ja funktsiooni kohta senikaua, kuni kõik oluline on kirjas. Lihtsalt toores kirjutamise töö sinu lemmik tekstitöötlustööriistas. Ka lihtsa toote spetsifikatsioon võib olla pigem pikk.
Kokkuvõtteks
Ühel hetkel projekti käigus tuleb spetsifikatsioon kliendi ja sinu poolt heaks kiita. Eriti uhke oleks spetsifikatsiooni dokument allkirjastada, aga ka e-kirjas öeldud kinnitus sobib. Tähtis on, et see oleks kontrollitav. Sellest saab alus, millele toetudes saab teha projekti planeerimist. See on osa kokkuleppest, mida klient saab ja mille eest ta maksab ning kuskohast jookseb see piir projektis, millest algab ja lõppeb sinu vastutus. Tekivad konkreetsed tööülesanded, tööväljundid ja üleandmiskohad.
Spetsifikatsiooni mõte on saavutada koos kliendiga võimalikult suur ühine arusaamine kliendi ootustest projektile. On inseneri ja kliendi ühine huvi, et ootused projektile oleks üheselt mõistetavad. Kui tekib vasturääkivus kliendi soovi ja sinu loodu vahel, on tüli kiire tulema. Algavad vaidlused, mida keegi ütles, mida keegi mõistis ja kelle süü on valesti mõistmine. Ükskõik kuidas sellised vaidlused lõppevad, on suhe kliendiga ja sinu maine professionaalina viga saanud. Esimene samm, mida sellise olukorra tekkimise vastu ette võtta on spetsifikatsiooni loomine.
.
Kontakt:
press@krakul.eu
