Saturs
- Programmatūras izstrādes dzīves cikls
- Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
- Programmatūras inženiera daudzveidīgā loma
- Programmatūras inženieris un projektu komandas
Avots: Dragonimages / Dreamstime.com
Izņemšana:
Programmatūras inženieris ir dziļi iesaistīts programmatūras izstrādes dzīves ciklā un tam ir liela loma projekta panākumos.
Ko dara programmatūras inženieris? Vienkārša atbilde ir tāda, ka viņš vai viņa ir iesaistīts programmatūras inženierijā, inženiertehnisko principu piemērošanas procesā programmatūras izstrādājumiem.
Tomēr, aprakstot to, ko programmatūras inženieri veic programmatūras pasaulē, ir patiešām daudz detaļu un nianšu. Mēs to apskatīsim, apskatot “dienu dzīvē” programmatūras inženierim, kurš strādā, lai radītu visas lieliskās digitālās lietas, kuras mēs izmantojam katru dienu. (Lai uzzinātu vairāk par kāda lauka lomu, apskatiet How I Got šeit: 12 jautājumi ar rakstnieku un programmatūras inženieri Deividu Auerbahu.)
Programmatūras izstrādes dzīves cikls
Lai izprastu programmatūras inženiera lomu, ir noderīgi zināt par programmatūras izstrādes dzīves ciklu (SDLC).
Programmatūras izstrādes dzīves cikls ietver dažādas galvenās fāzes, kuras bieži raksturo kā prasību plānošanu, projektēšanu, kodēšanu, testēšanu, ieviešanu un piegādi (dodiet vai veiciet dažas darbības atbilstoši patentētajiem procesiem).
“Programmatūra sākas ar problēmu, kuru cenšamies atrisināt,” saka Džons Kviglijs, Value Transformation LLC, aprakstot parasto programmatūras izstrādes dzīves ciklu, sākot ar dažiem no procesa sākuma posmiem. “Tas tiks formulēts kādā dokumenta formā, un tas ir rezultāts intervijām ar klientiem vai cilvēkiem, kuri cieš no šīs problēmas. Dokumentā tiks aprakstīts, kā izskatās šī problēma, un tas palīdzēs ģenerēt idejas, kuras varētu salīdzināt ar šo risinājumu. Tas būs šī darba mērķis, nosakot, ko mēs cenšamies paveikt. ”
Viņš saka, ka prasību posmā inženieri izklāsta konkrētu produkta tehnisko aprakstu - gan aparatūru (ja tāda ir), gan programmatūru.
Pēc tam ir kodēšana: “Programmatūras inženieri rakstīs īpašus paziņojumus kodā, kas ražos vēlamo produktu, kas atbilst īpašajām prasībām,” par kodēšanas posmu stāsta Kvigijs.
Pēc tam, viņš saka, notiek testēšana un pēc tam vēl viens darbību kopums, kas stabili virza programmatūru uz ražošanas vidi. Procesa beigās ir vieta dažādām idejām par ieviešanu un ieviešanu. Kvigijs arī piebilst, ka jauns “veikls” SDLC modelis darbojas mazliet savādāk.
Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Jūs nevarat uzlabot savas programmēšanas prasmes, kad nevienam nerūp programmatūras kvalitāte.
“Veiklajā pasaulē lietas izskatās daudz, bet atkārtojumi ir mazāki un tuvāk,” saka Kviglijs. "Prasību var izpildīt, izmantojot lietotāju stāstus, mazāk tehniska rakstura un vairāk rakstītus, lai izprastu lietojumprogrammu, lai programmatūras inženieri varētu izdarīt secinājumus un secināt nepieciešamos galvenos atribūtus, pamatojoties uz faktisko izmantošanu."
Programmatūras inženiera daudzveidīgā loma
Tā kā programmatūras izstrādes dzīves ciklam ir dažādas fāzes un darbības, ir jēga, ka mainās arī programmatūras inženiera darbs.
“Programmatūras inženierim programmatūras risinājumu izveidē ir lielāka loma nekā lielākajai daļai,” raksta Ročesteras Tehnoloģiju institūta profesors Samuels Malachovskis. “Katram SDLC elementam ir speciālisti: RE un pārdošana sākotnējiem soļiem, projektēšanas fāzes arhitekti, kodēšanas kodētāji / programmētāji, QA verifikācijai / testēšanai, IT ieviešanai / uzturēšanai un projektu vadītāji pārvietošanai un pārvaldībai katrs komandas loceklis / fāze, bet no programmatūras inženieriem tiek sagaidīts, ka viņi plaši izmantos visu procesu. Ņemot vērā šo viedokli, labāks varētu būt jautājums, ko nedara programmatūras inženieris. ”
Šeit ir vēl viens interesants fakts, ko Malachowsky izceļ par atšķirību starp IT un programmatūras inženieriju, kas daudz parāda, kāds ir vidējā programmatūras inženiera darbs:
"IT darbojas un atkārtojas, turpretī inženierzinātnes griežas ap jaunām problēmām, kuras jārisina kā unikāli projekti," viņš saka. “IT personāls šīs atkārtošanās dēļ daudz biežāk meklē individuālus uz rīkiem balstītus sertifikātus. Pretstatā kaut kam, piemēram, Computer Engineering, izskatās, kur tiek izpildītas prasības - CE mēdz koncentrēties uz problēmas risināšanu ar aparatūru, ar programmatūru, kas to atbalsta. SE problēmu risina ar programmatūru, ar aparatūru nodrošinot atbalstu. ”
Programmatūras inženieris un projektu komandas
Daudzos uzņēmumos programmatūras inženieri tiek grupēti un deleģēti, ņemot vērā viņu lomu sarežģītajā procesā.
Brennan Meagher apraksta piemēru no TeleTracking, uzņēmuma, kas veido virsrakstus veselības aprūpes inovāciju jomā Sīvajā veselības aprūpē, Amerikas ārkārtas ārstu koledžā, Veselības datu pārvaldībā, Veselības aprūpes IT ziņās un citur.
"TeleTracking programmatūras inženieri ir atbildīgi par visu moduļu un lietojumprogrammu, kas ietilpst TeleTracking platformā, kodēšanu un testēšanu," saka Meagher. “Viņi arī palīdz programmatūras risinājumu un iestudējumu izstrādē. Tas ietver jaunas programmatūras izpēti, projektēšanu, dokumentēšanu un izstrādi. Īsāk sakot, mūsu programmatūras inženieri rada programmatūras risinājumus, kas atbilst TeleTrackings tehniskajam redzējumam, lai uzlabotu piekļuvi pacientiem. ”
Jūs varat nofotografēt šos speciālistus korporatīvajā pilsētiņā, vispirms izstrādājot projektu, pēc tam pielāgojot modeli, pēc tam testējot komandās, rūpīgi vadot projektu līdz tā pabeigšanai.
“Piemērs tam, par ko programmatūras inženieri regulāri ir atbildīgi, var būt: rakstīšana, atkļūdošana, vienības pārbaude un veiktspējas pārbaudes kodi visos lietojumprogrammu slāņos,” saka Meaghan. “Tas ietver priekšējo daļu (tīmekli), vidējo slāni (tīmekļa pakalpojumi) un datu piekļuves slāņus.”
Galvenais ir tas, ka programmatūras inženieriem ir dažādi, specializēti darbi. Viņiem visiem ir jāsaprot daži kodēšanas pamati, bet daži no tiem ir jāiedziļinās testēšanas specifikā vai dizaina prasību caurspīdīgumā vai dažos gadījumos arī veiklās attīstības pasaulē.
Tad nāca klajā ar DevOps modeli, un tas apvienoja daudzus atkārtojošos procesus, kas tradicionālajā modelī bija ļoti īpaši ieskicēti un kategoriski. Tātad programmatūras inženiera loma mainās. (Lai uzzinātu vairāk par DevOps, skatiet DevOps vadītāju skaidrojumu, ko viņi dara.)
Tas ļauj jums nedaudz turpināt, kad jūs plānojat uzzināt vairāk par šo centrālo profesionāļu darbu programmatūras ražošanā. Programmatūras inženieris tika aprakstīts kā “Šveices armijas nazis” projektēšanā un programmatūras izveidē, un viņš var galu galā nēsāt daudzas cepures aizņemtā uzņēmumā.