10 padomi par to, kā pareizi dokumentēt dizainu, lai citi varētu sekot

Our Miss Brooks: Business Course / Going Skiing / Overseas Job (Maijs 2019).

$config[ads_text] not found
Anonim

Tātad jūs vēlētos izveidot elektronikas ierīces, bet vai jūs zināt, kas nepieciešams, lai kļūtu par profesionālu dizaineru? Padoms: ne tikai labas dizaina prasmes.

Richard Quinnell, galvenais redaktors

Jautājiet lielākajai daļai elektronikas izstrādātāju par to, ko viņi dara, lai dzīvotu, un lielāko daļu laika jūs saņemsit atbildi, kurā aprakstīti to izstrādājumu veidi. Bet jautājuma patiesība ir daudz ikdienišķāka. Vissvarīgākais rezultāts produkta izstrādes beigās nav aparatūras prototips vai lietojumprogrammatūra. Tas ir projektēšanas dokumentācija, un, lai to izdarītu pareizi, var tikt maksāti milzīgi ieguvumi no līnijas.

Profesionāli izstrādātāji ir tie, kas izveido produktus, kas paredzēti ražošanai, izplatīšanai un pārdošanai. Lielākajā daļā gadījumu šiem produktiem būs nepieciešama arī lauka uzturēšana, kļūdu labojumi, jauninājumi un lietotāju atbalsts, kā arī nārsta produktu variācijas, un bieži vien daļa no projekta ir kopēta un atkārtoti izmantota pilnīgi jaunā produktā. Nekas no tā nevar notikt, ja sākotnējais dizains nav pareizi dokumentēts. Protams, ir iespējams kaut ko mainīt, bez jebkādas projektēšanas dokumentācijas, un pēc tam virzīties uz priekšu, lai iesaistītos šajās darbībās. Bet pat tad, pirmā iznākuma reversās inženierijas pūles ir pamatdokumentācija par esošo dizainu.

Kā lielākā daļa projektu aiziet, dizaineri pāriet uz kaut ko jaunu, tiklīdz izstrāde ir pabeigta, atstājot atbildību par visām šīm turpināšanas darbībām citiem. Bet pat tad, ja sākotnējais dizainers tiek saukts, lai palīdzētu, iespējams, ka liela daļa to sākotnējās dizaina domāšanas ir aizmirsta. Tātad abos gadījumos pienācīgas dokumentācijas izrādīšana nenovērtējama, palielinot pūles.

Tomēr tas, kas veido "pienācīgu" dokumentāciju, ir nedaudz subjektīvs un ir atkarīgs no attīstības komandas kultūras aizspriedumiem. Turklāt ir daudzi dokumentācijas veidi, kas jāiziet no ražošanas centieniem, kas paredzēti ražošanai, tostarp, bet ne tikai, lietotāja rokasgrāmatas, testēšanas procedūras, produktu apraksti un dizaina specifikācijas. Šī patiesība noved pie pirmā no desmit galvenajiem elementiem, kas veido noderīgu dokumentāciju:

1. Mērķauditorija. Sīkāka informācija par to, ko dokuments jāiekļauj, būs atkarīgs no dokumenta nolūka, tāpēc pirmā lieta, kas jāzina, ir tas, kam dokumentācija tiek rakstīta. Jautājiet (vai paredzat) savas informācijas vajadzības un to, ko viņi izmantos, lai palīdzētu viņiem to paveikt. Atbildes uz šiem jautājumiem var palīdzēt jums izvēlēties, kāda veida un cik daudz informācijas jāiekļauj dokumentā. Šajā rakstā es pieņemu, ka mēs runājam par sistēmas dokumentācijas sagatavošanu, kas vajadzīga, lai palīdzētu nākamajam izstrādātājam pielāgot, paplašināt vai piemērot jūsu dizainu, lai atbilstu jaunām prasībām vai novērstu neparedzētu uzvedību (ti, kļūdas). Lielu daļu neapstrādātās informācijas, kas tiek prasīta tālāk minētajos ieteikumos, var uztvert reāllaikā, piemēram, piezīmjdatoros, bet tie joprojām būs jāorganizē un jāuzrāda veidos, kas atbilst konkrētai auditorijai, tiklīdz projektēšanas fāze ir pabeigta.

2. Saglabāt uzdevumu koncentrēšanu. Koncentrējiet savu dokumentāciju, lai palīdzētu lasītājam sasniegt paredzēto mērķi. Viens veids, kā to izdarīt, ir uzdot sev jautājumu, ko jūs vēlaties uzzināt par dizainu, lai palīdzētu paātrināt spēju veikt izmaiņas, neieviešot neparedzētas sekas, un pēc tam sniedziet šo informāciju. Tam būs nepieciešams vairāk nekā vienkārši norādīt, kas ir paveikts; tai būs vajadzīgs dizaina izvēles iemeslu apraksts.

Attēlu avots: Morguefile.
Aparatūras dokumentācija
3. Aprakstiet aparatūras funkciju un nodomu. Attiecībā uz aparatūras dizainu dokumentālo lasītāju sniedziet informāciju, kas var palīdzēt viņiem saprast gan dizaina detaļas, gan tā vispārējo struktūru un darbību. Daudzi izstrādātāji izvēlas, piemēram, organizēt shēmas ar punktētām līnijām, lai aptvertu funkcionālos blokus vai apakšsistēmas (piemēram, modulatoru, barošanas pārvaldību vai signāla kontūrētāju) vai novietotu tos uz atsevišķām lapām un nodrošinātu rakstzīmes, kas šos blokus risina atsevišķi. Tad viņi sagatavo vispārēju diagrammu dizainam, izmantojot šos pašus blokus, un apraksta, kā bloki darbojas kā ansamblis, lai nodrošinātu sistēmas pārskatu. Atsevišķie bloķēšanas raksturlielumi ir īpaši noderīgi izstrādātājiem, kas vēlas atkārtoti izmantot segmenta dizainu kaut ko jaunu.

4. Aprakstiet saskarnes. Sīkāka informācija par galvenajiem elektriskiem un laika raksturlielumiem attiecībā uz signāliem, kas nonāk funkcionālajā blokā un tiek izvadīti no tā, ieskaitot elektroenerģiju. Vēlreiz tas atvieglo vēlāku aparatūras bloka atkārtotu izmantošanu, taču tas arī palīdz atkļūdošanas un pārbaudes laikā, norādot galvenos signālus. Ja ir kritiskās laika prasības (piemēram, iestatīšanas un turēšanas laiks) vai ierobežojumi, piemēram, slodzes pretestība vai sprieguma / jaudas līmeņi, pārliecinieties, ka tie ir iekļauti. Daži izstrādātāji apraksta savas shēmas tieši ar piezīmēm, kas norāda signālu līnijas vai konkrētas sastāvdaļas, kas iesaistītas, lai sniegtu šādu informāciju.

5. Apspriediet komponentu izvēli. Daudzos gadījumos, kāpēc tika izvēlēts konkrēts komponenta veids vai vērtība, ir tikpat svarīga kā komponenta izvietojums ķēdē. Vai ir iemesls, kāpēc poliestera kondensatora vietā izmantot oglekļa kompozītmateriālu vai keramikas vietā stiepļu sveķu rezistoru? Ne katram komponentam ir jāpamato, bet jāņem vērā šādas izvēles un to iemesli, kad tie ir nozīmīgi. Tāpat, ja ir norādīti jaudas novērtējumi, frekvences raksturlielumi, izmēru prasības vai citi būtiski iemesli konkrētai izvēlei, atzīmējiet tos. Tas novērsīs problēmas līnijā, ja kāds būs kārdinājums (vai nepieciešams), lai aizstātu ērtības vai ietaupītu izmaksas. Šādas piezīmes var būt iekļautas materiālu rēķinā vai tieši shēmās, kā šķiet vispiemērotākā.

6. Iekļaujiet attiecīgos aprēķinus. Risinot tādus jautājumus kā jaudas izkliedēšana, frekvences reakcija, aizsargājošās shēmas, laika konstantes, impedances saskaņošana, iestatījumu iegūšana un tamlīdzīgi, dizaineriem parasti ir jāaprēķina atbilstošās vērtības. Saglabājot šos aprēķinus nākamajiem izstrādātājiem pārskatīšanai, tas lielā mērā var palīdzēt izprast ķēdes funkcijas un darbību, īpaši, ja viņi vēlas mainīt vienu vai vairākas no šīm īpašībām. Visizplatītākais veids, kā saglabāt šos aprēķinus, ir dizaina piezīmju grāmatiņā (vai tiešsaistes dokumentā), ko izstrādātāji, veidojot savu dizainu, glabā kā domāšanu par viņu domām. Piezīme pats pati noderēs sākotnējam projektētājam savai nākotnes atsaucei, taču kritisko aprēķinu kopsavilkums arī jāiekļauj sistēmas dokumentācijā, lai vadītu jebkuru nākamo ārpakalpojumu sniedzēju. Piezīmju grāmatiņa ļauj vienkārši atkārtot šo informāciju citā dokumentā, neveicot atkārtotu aprēķinu.

Attēlu avots: Pixabay.
Programmatūras dokumentācija
Daudzi no iepriekš minētajiem ieteikumiem attiecas arī uz programmatūras dokumentāciju, taču ar nelielu vērpjot. Programmatūra nav jāveido, tādēļ nav nepieciešams paredzēt iespējamos aizstājējus, un galīgais prototips (pirmkods) var arī veidot lielu daļu savas dokumentācijas. Tikai ne visi.

7. Aprakstiet augstākā līmeņa arhitektūru. Labi komentēts pirmkods ir noderīgs, lai vēlāk izstrādātos kodus mēģinātu sekot atsevišķu funkciju un procedūru loģikai un īstenošanai, taču ir arī vajadzīgi augstākā līmeņa apraksti, kas apraksta, kā šie elementi iekļaujas kopējā sistēmā. Šie apraksti var būt blokshēmu, stāvokļa diagrammu vai teksta veidā, un to nolūks ir ļaut izstrādātājiem īsumā redzēt, ka izmaiņas atsevišķā koda blokā var ietekmēt citas sistēmas darbības daļas.

8. Aprakstiet mainīgos lielumus. Kopā ar komentāriem koda blokiem jāietver kopsavilkuma apraksti par mainīgajiem lielumiem, kurus izmanto kods, to mērķi, veidu un izmēru un paredzamo vērtību diapazonu. Aprakstošie nosaukumi var palīdzēt mainīgo lielumu mērķu precizēšanā un ir vēl noderīgāk, lai palīdzētu izstrādātājam izpildīt koda loģiku, bet nevajadzētu būt vienīgam aprakstam

9. Uzvariet līdzsvaru. Einšteins ir apstiprināts, sakot: "Padarīt lietas pēc iespējas vienkāršāk, bet ne vienkāršāk." Koda dokumentācija ir ideāls mērķis šim ieteikumam. Long, verbose apraksti, kas ļauj attīstītājam vairāk informēt, nekā to jāzina, ir ne tikai laikietilpīgi, lai izveidotu un grūti saglabātos, jo kods attīstās, tos arī ir grūti lasīt un absorbēt. Pareizais līdzsvars starp pilnīgumu un īsu brīdi var būt sarežģīts, bet tas ir vērts pievērst uzmanību.

10. Sadarbojieties. Viens no veidiem, kā palīdzēt panākt nepieciešamo līdzsvaru, ir sadarboties ar citiem, izstrādājot un pārskatot dokumentāciju. Cilvēks, kurš apraksta to dizaina domāšanu, ir pavisam vienkāršs aizmirst, ka citi nedēļām un mēnešiem nav dzīvojuši ar šo dizainparaugu. Ja kāds cits izskata lietas, it kā viņi būtu nākamais, kurš strādā pie dizaina, palīdzēs nodrošināt, ka visa nepieciešamā informācija ir klāt un pietiekama. Alternatīvi, strādājot ar kādu, kas ir kvalificēts dokumentācijas izveidē, var palīdzēt uztvert dizaina nodomu.

Visai šai dokumentācijas darbībai, izmantojot jebkuru aplēsi, ir vajadzīgs ievērojams darbs, taču tas var izmaksāt skaisti vēlāk, ja dizainparaugs ir jāatjaunina, jāpārveido, jāpārveido vai jāiestata. Pūles arī ir viena no nozīmīgākajām atšķirībām starp amatieru / hobija dizainparaugiem un profesionāliem. Profesionāļiem, izveidojot sistēmu, kas darbojas, nav to gala mērķis. Patiesais mērķis ir nodot citu personu rokās paketi, kas ļauj efektīvi ražot, uzstādīt, uzturēt un attīstīt šo dizainu bez dizainera papildu iesaistīšanās.

Lai uzzinātu, kā izstrādāt un attīstīt motora vadības programmas ar NXP MagniV MCU, izmantojot modeli balstītu dizainu, reģistrējieties bezmaksas seminārā , kuru sponsorē NXP

Richard Quinnell