Keerukate riist- ja tarkvaraökosüsteemide loomine, mis leiavad toote / turu sobivuse, on keeruline ülesanne. Ehkki enamik riistvaraga alustavaid ettevõtteid ebaõnnestub seetõttu, et neil on raha otsa saanud, väidavad a aruanne CB Insightsi andmetel on suurimaks põhjuseks tegelikult nende toodete nõudluse puudumine. See ainult rõhutab, kui oluline on tootehalduri roll riistvara alustajate jaoks, kuna nende peamine eesmärk on välja selgitada kliendi vajadused ja valupunktid eduka toote tarnimiseks.

Viimane minu juhitud ettevõte lõi parkimistööstuse jaoks veebi-, mobiil-, manustatud tarkvararakenduste ja riistvaraseadmete ökosüsteemi. Riistvaratoote strateegia oli osa minu igapäevatööst, mis viis mind katseteni mitmesuguste riistvara tootearenduse töövoogudega. Hoolimata kümnest aastast riistvaratoodetega töötamisest ning elektroonika ja telekommunikatsiooni erialal, oli mul siiski töökohal palju õppida. Olen loonud allpool oleva juhendi lootuses, et saate sisseehitatud tarkvararuumiga riistvara tootehalduses kiiremini käima kui mina.

Riistvara tootehalduse väljakutsed

Kuigi SaaS-i ja mobiilirakendusi saab hõlpsasti arendada vilgas raamistik , muudavad manustatud tarkvara ja riistvaraseadmete väljatöötamise ainulaadsed tingimused agiilsete põhimõtete rakendamise palju keerulisemaks. Selles esimeses osas käsitleme riistvara arendamise omadusi, mis loovad keerukuse. Kõigil neist pole otseseid lahendusi, kuid on olemas viise, kuidas raskusi vähendada, kasutades konkreetseid riistvaraarendusstrateegiaid, mida käsitletakse järgmises osas.

Spetsialiseeritud tehnilist annet on kohapeal raske leida

Uute riistvaratoodete loomine on oluliselt raskem kui olemasolevate kordamine. See hõlmab palju loovust ja kogemusi prototüüpide loomisel, mida ülikoolides harva õpetatakse. Mõnes ülikoolis pole nende oskuste arendamiseks isegi prototüüpimisvõimalusi ega vajalikke tööriistu ning selline kogemus on peaaegu eranditult suuremates riistvaraettevõtetes, kus on teadus- ja arenduskeskused. Asjakohase asjatundlikkusega kohalike spetsialistide leidmine võib seetõttu olla väga raske, mille tulemuseks on see, et paljud riistvara käivitamise asutajad peavad oma talentide arvu laiendama kaugtööga.

Versioonijuhtimissüsteeme ei kohandata riistvara kujundusega

Enamik versioonikontrollisüsteeme (VCS) on orienteeritud tekstivormingu toetamisele, kuna need loodi tarkvaraarenduse koostöös. Riistvaraarendusega projektides mähitakse teave hoopis disainifailidesse, mis on loodud spetsiaalsete tööriistade nagu OrCAD abil. Ja mõned neist tööriistadest toetavad ainult binaarfaile, mis pole isegi VCS-ides kasutamiseks optimeeritud. CADLAB on suhteliselt uus katse luua riistvaraga ühilduv VCS ja loodetavasti on lähitulevikus veel selliseid tööriistu.

Riistvara tootmise rajatised on ümber paigutatud

Riistvara tootmise rajatised asuvad sageli mõnes teises piirkonnas, riigis või mandril. Riistvaratootja ja tootja vaheline suhtlus vajab erilist tähelepanu ja on toote eduka tarnimise võti. Edukas suhtlus nõuab strateegilisemat kujundamist toote kvaliteedi tagamiseks ja toote turu dünaamilise valideerimise etapis toimuvate muutustega toimetulemiseks. Selle saavutamiseks peab riistvara tootja looma palju üksikasjalikke tootjale saadetud spetsifikatsioone. Koostööraamistik peab tagama teabe kiire edastamise ja spetsifikatsioonide olelusringi haldamise, kuna need võivad hõlpsasti kiiresti aeguda.

Riistvaramuudatused on vähem paindlikud

Tarkvara idufirmade populaarne töömudel ohverdab kvaliteedi kiiruse nimel varajases staadiumis. Isegi Facebook võitles mantrat 'liikuge kiiresti ja murda asju' juba mõnda aega. Teine tuttav lähenemisviis on 'võltsitud', kuni teete selle. ' See töötab tarkvara käivitamisel odavate infrastruktuurikulude ja sujuvamate programmeerimisraamistike tõttu, mis võimaldavad arendajatel iga päev koodivärskendusi juurutada.

Ehkki selline lähenemine arengule on aeglaselt riistvararuumi pugenud, on see selles valdkonnas kahetsusväärne trend, kuna riistvaramuutusi on palju raskem teha ja juurutada. Arenduskulud kompenseerivad kiirete ja sagedaste väljalaskete kaudu saadud väärtuse, seega on tegelikult palju soovitavam strateegia investeerida rohkem projekteerimisetappi, et luua usaldusväärseid riistvaraarhitektuure.

Ühisrahastuse lõks

Paljud idufirmad on lõksus ideest, et edukas käivitamine riistvara ühisrahastus kampaania võrdub turu valideerimisega. Ühisrahastus kipub kõige edukam olema riistvarakomponenti sisaldavate toodete puhul, eriti meie füüsilise objektiga seotud teadvuseta omandiõiguse soovi tõttu. Ühisrahastus ei ole aga mõeldud teie toote ulatuslikuks kinnitamiseks, vaid pigem demokraatlikuks viisiks varajases staadiumis tootearenduse rahastamiseks. Kahetsusväärne on see, et paljudel edukate ühisrahastuskampaaniatega ettevõtetel on hiljem olnud keeruline või peaaegu võimatu oma toodangut laiendada, kuna nad ei kinnitanud oma turgu ulatuslikult.

Sertifikaadid, eeskirjad ja kinnitused

Kõigi riistvaratoodete müümiseks on vaja mingisugust sertifikaati. See on riistvaratoodete turule toomise väga varases staadiumis üks tähelepanuta jäetud etappe. Kuidas mõjutab sertifitseerimise piirang tooteplaani ja arendamiseks rakendatavat raamistikku? Harvad pole plaanid projekti varajase etapi kavandamiseks koos projekti verstapostina sertifitseerimise ja muude heakskiitmistega, et siis alles tagasi minna tinglikult algusfaasi. Tootejuhid saavad selle asemel kose sarnasema lähenemisviisi korralikult analüüsida regulatsioone, sõltuvusi ja tooteplaani strateegiliste otsuste väravaid.

Riistvara tootehalduse võimalused

Nüüd, kui oleme käsitlenud mõningaid sisseehitatud tarkvaraga riistvaral esinevaid väljakutseid, vaatame nüüd, kuidas muuta arendusprotsess sujuvamaks ja prognoositavamaks, et kompenseerida riistvara arendamisega seotud olemuslikke raskusi.

Kaasake riistvara arendamisse vilgas

Kogenud tootejuhid on teadlikud väljakutsetest, mis seisnevad sisseehitatud tarkvaraga riistvaratoodete ehitamises, mis püüavad ära kasutada uue tehnoloogia arenguga loodud turuvõimalusi. Nad õpivad tasakaalustama turule jõudmise aja kiirendamist, ilma et see kavandamisest alates toote edu tõenäosust kahjustaks. Enamasti saab see vormi a kaudu vesi-scrum-kukkumine lähenemisviisi.

õppige c või c++

Toote idee faas laiendab toote põhimõtteid, eesmärke ja kõrgetasemelisi funktsioone võimalikult paljudes üksikasjades. Suurepärased tootejuhid kulutavad selle faasi tulemuste täpsustamisele rohkem aega: visioon, missioon, võimaluste hindamine, riistvaratoote eesmärgid ja funktsioonid. See on toote põhjatäht, mis peab olema enne riistvara prototüübi kallale asumist piisavalt selge, seetõttu on soovitatav kasutada juga.

Kriitilise tähtsusega on riistvaratoodete korralikult dokumenteeritud nõuded ja funktsionaalsed spetsifikatsioonid ning riistvaratoote juhtimiseks manustatud tarkvara hea tehniline arhitektuur. Nõuete ja spetsifikatsioonide muutmist tuleks karistada, mitte julgustada, kui kogu meeskond on need alla kirjutanud.

Manustatud tarkvara väljatöötamisel saab kasutada standardset uurimismetoodikat. Eelnevalt määratletud riistvaraarhitektuuriga töötamiseks on tarkvara juurutamist kohandada ja täpsustada nii aja kui ka rahaliselt odavam kui vastupidi.

Lõplik integreerimiskatse ja kasutajate aktsepteerimise test tuleks teha juga tingimustes. Selles etapis on arendusetapp lõppenud ning uued funktsioonid ja puuduvad funktsioonid registreeritakse järgmise planeerimisperioodi täiendavate töötaotlustena.

Kaasata manööverdatud tarkvara arendamisse vilgas

Sisseehitatud tarkvaraga keerukate riistvaratoodete ehitamine mõjutab traditsiooniliste tarkvaraarendusmetoodikate rakendamist. Paljud personaalarvutis töötava tarkvara tootmiseks kasutatavad süsteemid ei sobi manustatud tarkvara arendamiseks, kuna ressursside nappuse ja palju pikemate arendustsüklite osas on piiranguid.

kuidas ma tean, kas mul on mäluleke

Grupp Brasiilia akadeemikuid ja spetsialiste on pakkunud potentsiaalset lahendust: Platvormipõhine tarkvara väljatöötamise metoodika manussüsteemidele: vilgas tööriistakomplekt . See metoodika hõlmab vilgas sisseehitatud tarkvara arendamise põhimõtteid. Allpool on metoodika lühike kokkuvõte, kuid riistvaratoote juhtidel soovitatakse tungivalt seda lugeda täielik kirjeldus enne selle rakendamist oma praktikas.

Selle metoodikaga on seotud järgmised rollid:

• Platvormi omanik - Vastutab kvaliteedi, planeerimise ja kulude sihtmärkide määratlemise eest
• Toote juht - Vastutab toote juurutamise, integreerimise ja testimise eest
• Feature juht - Vastutab allsüsteemiprojektide haldamise ja funktsioonide edenemise jälgimise eest
• Arendustiim - Tootearenduse kallal töötamine

Metoodika jagab manustatud tarkvara arenduse kolme protsessigruppi:

1. Süsteemiplatvormi protsesside rühm. Süsteem valib platvormide teegist süsteemikomponendid, mis on osa arhitektuurist ja API-platvormidest, ning kohandab need vastama kõnealuse rakenduse piirangutele. Kohandamisprotsess viiakse läbi iteratiivsete tsüklitena, programmeerides disainerile konfigureeritavad protsessorid ja platvormi integreeritud käitamise ajal ümberkonfigureeritavad loogikad.
2. Tootearendusprotsesside rühm. Toote moodustavad funktsioonid jagunevad platvormi kas riist- või tarkvaraelementideks. Metoodika pakub jaotamise algoritme, et võtta arvesse rakenduse komponentide energiatarbimist, täitmisaega ja mälu suurust.
3. Tootejuhtimisprotsesside rühm jälgib ja kontrollib toote ulatust, aega, kvaliteeti ja kuluparameetreid. Soovitatavad lähenemisviisid koosnevad peamiselt nii Scrum Agile meetodi edendatavatest praktikatest kui ka agiilsetest mustritest.

Looge riistvaraarendusprogramm

Varase staadiumi riistvaraarendusprogrammi struktureerimine on võimaldanud ettevõtetel pakkuda kiiret pööratavat või plaani B. Äri seisukohast võib see küll vähendada finantsvaru, kuid annab lõpuks vajaliku nõtkuse pidevalt muutuva turuga toimetulekuks konkurentsi vallandatavate toodete ja tehnoloogiliste võimete edendamise osas.

Oletame, et ettevõte korraldab sisseehitatud tarkvaraga riistvaratoote eduka ühisrahastuskampaania. Nad töötavad suurepäraselt esimese tootepartii suunas, kuni suur asutatud ettevõte teatab midagi sarnast. Kõige olulisem on mitmekülgsus ja turuletuleku aeg ning pragmaatiline ja vilgas reageerimine sellele olukorrale suurendab eduka toote tõenäosust. Riistvara arendamise programmi rakendamise abil saab ettevõte oma konkurentidele reageerides kiiresti toote rikkalikuma versiooni tähelepanu keskpunkti panna.

Riistvara edukas testimine manustatud tarkvaraga

Testimine on riistvara tootehalduse ülioluline komponent, sest erinevalt kiire tarkvara testimine , saab enamiku riistvaralisi vigu parandada ainult uue tootepartii tootmisega. Samsung Galaxy Note 7 seadmed, mis olid tuld võtma on suurepärane näide sellest, miks riistvara testimine peaks olema kõigi tootehaldurite jaoks esmatähtis.

Funktsionaalsed testid on sisseehitatud tarkvaratoodetega riistvara tehnilise valideerimise põhieesmärk. Nende protseduuride keerukus tuleneb asjaolust, et vead tulevad tõenäoliselt süsteemi mis tahes osast.

Ühikute testimine tavaliselt juhtub simuleeritud keskkonnas pärast iga sprinti, kuna simuleeritud riistvara pakub eeliseks olla täiesti juhitav. Testskripte saab automatiseerida, nad võivad teostamise üle järelevalvet teostada ja tappa katseid, mis näivad kukkunud, kuid ei andnud tulemusi.

Integreerimise testimine peaks arvestama veebi- ja võrguühenduseta toiminguid ning riistvaratoote allumist tegelikele töötingimustele. Näiteks kui ettevõte arendab välitingimustes pea külge monteeritud aju seiresüsteemi, peaksid testimistingimused neid eripärasid arvesse võtma.

Süsteemi testimine hõlmab kogu süsteemi vigade ja vigade testimist. See test viiakse läbi kogu süsteemi riist- ja tarkvarakomponentide ühendamise kaudu (mida on varem testitud seadme ja integreerimise abil) ning seejärel testitakse tervikuna. See testimine on loetletud musta kasti testimismeetodi all, kus tarkvara kontrollitakse kasutaja eeldatavate stsenaariumide, võimalike erandite ja servajuhtumi tingimuste osas. Mainitavad testimise erikategooriad:

• Sündmuse käivitatud testimine: Algatas konkreetsed sündmused või olekumuutused riistvaratoote elus (nt käivitamine, lähtestamine, seiskamine). Selle eesmärk on tuvastada püsivad rikked.
• Ajaga käivitatud testimine: Algatatakse süsteemi tavapärases töös eelkonfigureeritud aegadel, perioodiliselt tehakse püsivate rikete tuvastamiseks. See on kasulik süsteemides, mis töötavad pikka aega, kus olulisi testi käivitavaid sündmusi ei toimu. Ajaga käivitatud testimine on kasulik ka katkendlike rikete tuvastamiseks.

Toote riistvara aktsepteerimine manustatud tarkvaraga

Toote väärtus Sisseehitatud tarkvaraga riistvaratoodete puhul valideeritakse tavaliselt pärast toote vastuvõtmise etappi veekogude langemise metoodikas. Sisseehitatud tarkvara ökosüsteemiga riistvara peab valideerimiseks ja aktsepteerimiseks seadma riistvara prioriteedile. Nagu varem öeldud, on riistvaramuutusi keerukam ja kulukam teostada. Tootejuhid mõtlevad tavapäraselt välja uuenduslikke lahendusi, mis on vajalikud aktsepteerimisprobleemide lahendamiseks või väärtuse kohandamiseks, võttes arvesse piirangut, et riistvara ei saa muuta, ja eelistades täiendavaid iteratsioone tarkvaraarenduse valdkonnas.

Suurepärastel tootejuhtidel on riistvara vajaduste prognoosimisel ja õigete kaasatavate funktsioonide tähtsuse järjekorda seadmisel toote nutikus ja suur visioon, et ärimudel oleks kindel, aktsepteerimine kindel ja kasutajad naudiksid toote kasutamist. Võttes arvesse manustatud tarkvara, ei tohiks riistvara 'kaunistamine' olla üllatav, kuna see peab järgima reegleid ja piiranguid, mille taga on riistvara arendusprotsessid, sertifitseerimisprotseduurid, tootmisprobleemid ja turu aktsepteerimine.

Riistvara arendamine nõuab hallatud väledust

Agile on võtnud tarkvaraarenduse maailma tormi kätte ja hakanud nüüd riistvararuumi pugema. Sisseehitatud tarkvaraarendusega riistvaratoote tingimustega kaasnevad aga erinevad väljakutsed:

• Spetsialiseeritud ande puudumine
• Versioonijuhtimissüsteemid, mis pole riistvara jaoks kohandatud
• Ümberpaigutatud tootmisrajatised
• Muudatused, mida on tarkvaraga võrreldes raskem teha
• Planeerimistõkkeid kehtestavad sertifitseerimis- ja reguleerimisnõuded

Need väljakutsed raskendavad agiilsete põhimõtete rakendamist samamoodi nagu tarkvaraettevõtted.

Nende väljakutsetega võitlemiseks on vaja hallatud agility lähenemisviisi, nagu vesi-alla-kukkumine. Manustatud tarkvaraarendus luuakse standardsete kontrolliprotseduuride järgi, teised sammud, nagu ideed, spetsifikatsioonide loomine ja testimine, rakendatakse juga seadistuses. See võimaldab riistvaraettevõtetel saada kasu, mida Agile pakub, säilitades samal ajal toimiva tootehalduse lähenemisviisi, mis peab arvestama erinevate eespool loetletud piirangutega. See juhitud agility lähenemisviis pakub kiirete muutuvate turutingimuste ja pideva tehnoloogilise täiustamise kontekstis edukat edasiliikumist.

Põhitõdede mõistmine

Kas riistvara arendamiseks saab kasutada väledust?

Kiire riistvara arendamiseks on soovitatav kasutada veekogude langemise lähenemist. Manustatud tarkvaraarendus luuakse standardsete kontrolliprotseduuride järgi, teised sammud, nagu ideed, spetsifikatsioonide loomine ja testimine, rakendatakse juga seadistuses.

Mida teeb riistvaraarenduse insener?

Riistvaraarenduse insener vastutab riistvarakomponentide, näiteks trükkplaatide, protsessorite, mäluseadmete jms loomise ja testimise eest.

Interneti-ettevõtete väärtus põhineb eelkõige

Mis vahe on tarkvara- ja riistvaraehitusel?

Peamine erinevus tarkvara ja riistvaratehnika vahel on füüsiline element. Tarkvarainsenerid töötavad arvutis ainult koodiga, riistvarainsenerid aga füüsiliste toodetega nagu protsessorid, trükkplaadid või mäluseadmed.

Mida mõeldakse manustatud süsteemi all?

Manustatud süsteemid on tarkvarakomponendid, mis töötavad riistvaratoote sees. Neid nimetatakse manustatud, kuna need on kohandatud töötama ainult selle konkreetse riistvaraga.