Kāpēc jums ir jāsaprot programmatūras prasības kā programmatūras inženierim

Šajā rakstā jūs uzzināsiet visu par programmatūras prasībām. Jūs saņemsiet izklāstu par tēmas jomu, procesu un vissvarīgāk, kādi ir jūsu pienākumi šajā jomā kā programmatūras inženierim.

Jums vajadzētu gūt nelielu ieskatu par savu lomu un darbībām, ievērojot programmatūras prasības. Ja kas, jums būs ko apspriest ar kolēģiem pēc nākamās stand-up?

Šis raksts lielā mērā aizņemas no tomāta, kas ir IEEE SWEBOK ceļvedis. Tas mēģina destilēt dažas no šīm zināšanām, precīzāk tās mērķējot. Ja jūs domājat, SWEBOK ir saīsinājums no programmatūras inženierijas zināšanu kopas, kuru uztur IEEE datoru sabiedrība.

Sākumā, kāpēc tas ir svarīgi?

Tiem, kas nav programmatūras inženierijas pārstāvji, ir kļūdains uzskats, ka programmatūras inženiera uzdevums ir vienkārši "ierakstīt kodu".

Jā, mēs esam tehnologi, kuriem parasti patīk mācīties programmēšanu. Patiesībā tas ir vienkāršots uzskats, kas nepietiekami novērtē to, ko programmatūras inženieru profesionālis faktiski dara savā ikdienas darbā un karjerā. Tas koncentrējas tikai uz viņu vispārējo pienākumu daļu.

Programmatūras inženiera uzdevums ir veidot biznesa risinājumus uzņēmuma mērogā. Tas ietver lielu skaitu pienākumu, kas nav saistīti ar viņu izveidoto kodu.

Viena atbildības joma, kas jums kā profesionālam programmatūras inženierim ir, ir programmatūras prasību joma.

Kādas ir programmatūras prasības?

Prasības programmatūrai uz virsmas izklausās vienkārši. Programmatūrai ir jādara X priekš Y, lai Z. Padomājiet par to pietiekami ilgi par jebkuru problēmu, ko programmatūra varētu atrisināt (vai par esošo programmatūru, kas jau risina problēmu), un jūs, iespējams, varētu domāt par daudzām prasībām. Viegli vai ne?

Nu nē, patiesībā lielākajai daļai uzņēmuma programmatūras.

Kā jūs apkopojat savas prasības? Vai apsverat ieinteresēto personu vajadzības un prioritātes? Vai tā patiešām ir prasība programmatūras lietotājiem? Vai apsvērumiem ir tehniski ierobežojumi? Kā jūs zināt, kad tas ir izdarīts? Vai prasību ieviešana atbilst noteiktam kritērijam? Un tā tālāk...

Sākot pētīt programmatūras prasību ideju, jūs atklājat, ka tās slēpj lielu un dziļāku zināšanu jomu.

Cik dziļas un lielas ir zināšanu jomas? SWEBOK definē, ka programmatūras prasību joma ir " saistīta ar programmatūras prasību ierosināšanu, analīzi, specifikāciju un apstiprināšanu, kā arī prasību pārvaldību visā programmatūras produkta dzīves ciklā ".

Šīs jomas lielums, piemēram, aktivitāšu skaits un katra iesaistīšanās, deva pietiekamu pārliecību, lai veltītu inženierzinātņu nozari, kas pazīstama kā " prasību inženierija ", un kas koncentrēta tikai uz prasību procesu.

Atsevišķas organizācijas var pieņemt darbā speciāli prasību inženiera lomai. Jūs to varat redzēt biežāk tiešām lielās organizācijās, kuras nodrošina, piemēram, sistēmas līmeņa risinājumus, kur viņu piedāvātie klientu problēmu risinājumi ietver kopējo risinājumu, kura programmatūra ir tikai viena sastāvdaļa.

Parasti organizācijas mēdz dalīt prasību inženiertehnisko atbildību, veicot darbības, kas piešķirtas starp dažādām citām projekta lomām, piemēram, dizaineri, biznesa analītiķi, produktu īpašnieki, piedāvājumu vai klientu vadība, tehniskie autori, programmatūras arhitekti / inženieri utt.

Parasti praksē ir grūti īstenot prasību procesu lineārā procesā, piemēram, ūdenskrituma metodikā. Tas prasītu, lai programmatūras izstrādes komanda no ieinteresētajām personām izvirzītu programmatūras prasības, tās klasificētu, piešķirtu un galu galā nodotu ieviešanai. Tas bieži vien nav iespējams ilgtermiņa veiksmīgiem risinājumiem.

Prasības šiem lielajiem programmatūras projektiem nekad nav pilnībā izprastas vai precīzi noteiktas. Tā vietā viņi parasti atkārtojas tieši tik kvalitatīvā un detalizētā līmenī, kas ļauj pieņemt lēmumus par projektēšanu un iepirkumu.

Prasību inženierija atšķiras no programmatūras inženierijas pēc darba veida, uz kuru koncentrējaties.

Ir svarīgi, lai jūs saprastu savu saistību ar prasību procesu, jo, iespējams, kādā brīdī jūs parasti iesaistīsities dažās prasību darbībās.

Kas ir saistīts ar programmatūras prasībām programmatūras inženierim?

Atkarībā no jūsu organizācijas prasību procesa un / vai prasību darbībām, par kurām atbild programmatūras inženieris, jūs varat būt iesaistīts jebkurā vai visos posmos. Tas varētu būt no prasību apkopošanas līdz to ieviešanas pārbaudei.

Vietas, kurās jūs varat iesaistīties:

  • Elicitation - prasību apkopošana programmatūrai
  • Klasifikācija - prasības kategorizēšana
  • Apstiprināšana - prasības apstiprināšana ar ieinteresētajām personām
  • Izstrāde un ieviešana - programmatūras veidošana atbilstoši prasībām
  • Sarunas - interešu konfliktu risināšana ar ieinteresētajām personām
  • Pārbaude - programmatūras funkcijas novērtēšana atbilst prasībām

Ir vērts atzīmēt, ka tas nav prasību inženierijas procesa dublikāts. Tie prasa dziļāku iesaistīšanos un darbības veidus noteiktās jomās, piemēram, prasību pārvaldību un dokumentēšanu.

Prasību pārvaldīšana un dokumentēšana parasti nav jūsu atbildība. Visticamāk, tās būs citas lomas, kas dalīs prasības.

Ir svarīgi zināt, kā piekļūt prasību pārvaldības sistēmai un to izmantot, lai novērtētu prasību izmaiņas un ietekmes analīzi.

Hm, nav prasību pārvaldības sistēmas ...

Dažos gadījumos prasību reģistrēšana un pārvaldība var nebūt specializētā sistēmā. Tos varētu ierakstīt cita veida ierakstīšanas sistēmās, piemēram, problēmu izsekošanas programmatūrā, projektu vadības rīkos vai varbūt pat versiju kontroles sistēmā.

Citos gadījumos organizācijas vai projektu grupas neizstrādā līdzekļus prasību dokumentēšanai un pārvaldībai. Viņi tā vietā var paļauties uz vadības redzējumu (indivīds vai komanda ar kopēju piemēru ir uzņēmuma dibinātājs) un / vai viņiem ir ierobežoti resursi. Viņi var apgalvot, ka prasību reģistrēšana vai pārvaldīšana nav nepieciešama.

Prasību nereģistrēšana un pārvaldīšana potenciāli var nopietni apdraudēt organizāciju un programmatūras risinājumu procesu.

Piemēram, jūsu organizācijai, kas izstrādā risinājumus klientu vajadzībām, būs jāpilda noteikti juridiski pienākumi. Viņi paziņos, ka jūsu programmatūras komponents ir veidots, lai nodrošinātu noteiktu funkcionalitāti un spēj sniegt noteiktu pakalpojumu līmeni (SLA).

Bet, ja rodas konflikts (juridisks vai cits), iespējams, trūkst funkcionalitātes, nefunkcionālas prasības nedarbojās, kā paredzēts, vai pat laiks / budžets tika iztērēts nevēlamām funkcijām, kā jūs varat parādīt, kas tika īstenots ieinteresētās personas vienojās pēc nepieciešamības un nepieciešamības?

Jūsu organizācijai jāspēj parādīt kartēšanu starp augsta līmeņa risinājumu prasībām (kas klientam ir vajadzīgs kā risinājums) un apstiprinātām programmatūras prasībām (ko ieinteresētās puses vienojās par risinājuma funkcionālo vajadzību apmierināšanu, ne vienmēr no 1 līdz vienam) 1) līdz dokumentācijas ieviešanai un pieņemšanas vai pakalpojuma līmeņa testu reģistrēšanai, kas parāda sniegto funkcionalitāti.

Vēl viens izplatītāks (un mazāk izdomāts) piemērs ir ietekmes novērtēšana. Jūsu organizācijai vai projekta komandai augot un attīstoties, pieaug arī jūsu izveidotā programmatūra. Ja vien programmatūra nav paredzēta iztukšošanai, tā jāiedomājas darboties noteiktā laika periodā, un tāpēc tā būs jāatjaunina, jāpapildina ar jaunām funkcijām un jāveic apkope.

Šis jaunais darbs var noliegt, ietekmēt vai mainīt esošo funkcionalitāti, kas paredzēta, lai dažādos veidos izpildītu vēsturiskās prasības (piemēram, mainot programmatūras arhitektūru vai komponenta dizainu).

Ja tā, jums būs jāpārskata vecās prasības, lai labāk izprastu motivāciju, kas to pamato. Piemēram, kāpēc tas tika īstenots šādā veidā? Vai pašreizējais darbs ir jāmaina? Vai vecā prasība joprojām ir aktuāla? utt.

Programmatūras prasību izsaukšana

Prasību izraisīšana attiecas uz darbību, kurā aprakstīts, kā tiek apkopotas vai savāktas prasības. Ne visas prasības ir “apkopotas” no klienta, un tās var atvasināt no sistēmas vai domēna, kurā programmatūra darbojas (piemēram, kritisko sistēmu darbspēja un uzticamība).

No projekta vadības viedokļa izsaukums ir kritisks, lai noteiktu projekta darbības jomu un klienta vai lietotāja vajadzībām svarīgos rezultātus, vispirms izvirzot svarīgākās vajadzības.

Kas ir saistīts ar programmatūras prasību izvirzīšanu?

Atkarībā no jūsu lomas iesaistīšanās prasību līmenī, jums, iespējams, būs jāņem prasības no avota.

Prasību izpēte palīdz informēt par vispārējā risinājuma dizainu un arhitektūru. Ir svarīgi saprast, no kurienes rodas prasības un kādi paņēmieni tiek izmantoti.

No kurienes rodas programmatūras prasības?

Prasībām ir daudz avotu, piemēram:

  • Mērķi (pazīstami arī kā biznesa rūpes, kritiskās veiksmes faktors utt.)
  • Domēna zināšanas
  • Ieinteresētās personas
  • Biznesa noteikumi
  • Darbības vide

Ja esat iesaistīts izsaukumā no avotiem, jums būs jāveic:

  • Pievērsiet īpašu uzmanību mērķiem.
    • Tie bieži ir neskaidri, piemēram, "Programmatūra jāievieš, izmantojot labāko praksi" vai "Programmatūrai jābūt lietotājam draudzīgai"
    • Novērtējiet risinājuma relatīvo vērtību un prioritāti. Izpētiet salīdzinoši zemu izmaksu sasniegšanas veidus.
  • Iegūstiet vai ir pieejamas zināšanas par lietojumprogrammas domēnu
    • Tas sniedz pamatinformāciju, kas ļauj izprast prasību iemeslus.
    • Labas programmatūras prasību analīzes pamatā ir reālās pasaules problēmu modeļu, piemēram, entītiju attiecību modeļu, izstrāde. Mēģiniet domāt, izmantojot ontoloģisku pieeju.
  • Identificējiet, pārstāviet un pārvaldiet daudzu dažādu ieinteresēto personu viedokļus
    • Prasības var būt pretrunīgas, pārklājas, vai arī tām var būt vajadzīga atšķirīga motivācija daļēji no dažādu ieinteresēto personu vajadzībām.
    • Ir svarīgi, lai jūs apzinātos dažādas vajadzības, īpaši ieviešanas iepriekšējā plānošanā, kur vajadzības ir iekļautas projektā.
  • Parādiet jutīgumu pret risinājuma darbības vidi
    • Darbības vide būs atkarīga no organizācijas struktūras, kultūras un iekšējās politikas.
    • Vispārējs princips, uz kuru jātiecas programmatūrai, nav ieviest neplānotas vai piespiedu izmaiņas organizācijas biznesa procesā.

Kā es varu iegūt programmatūras prasības?

Daži galvenie paņēmieni, ar kuriem jūs varētu būt saistīts (tehniskās ekspertīzes nodrošināšana), varētu būt:

  • veicot ieinteresēto personu intervijas
  • izklāstot scenārijus
  • prototipu veidošana
  • novērošana problemātiskajā zonā
  • lietotāju stāsti

Veidojot prototipus, vispārējs princips, kas jums jāmēģina ievērot, ir zemākas precizitātes prototipu biežāka izmantošana šajos iepriekšējos posmos.

Tie ir vēlami, lai izvairītos no ieinteresēto personu fiksēšanas par nelielām vai nejaušām īpašībām. Augstākas kvalitātes prototips var ierobežot dizaina elastību neparedzētos veidos.

Programmatūras prasību klasifikācija

Kad programmatūras prasības ir izvirzītas, projekta komanda tās var klasificēt vairākās kategorijās.

Tas palīdz dažādos veidos, piemēram, novērtējot projekta piepūli, identificējot risinājuma dizaina komponentus vai pat vienkāršus ieviešanas apsvērumus.

Klasifikācijas veidi var ietvert:

  • Funkcionāls / nefunkcionāls
    • Funkcionālās prasības apraksta funkcijas, kas programmatūrai jāpilda. Piemēram, saziņas kanāla nodrošināšana lietotājam vai datu pārsūtīšana no viena formāta uz citu. Tos var dēvēt arī par produkta īpašībām vai iespējām.
    • Nefunkcionālas prasības darbojas, lai ieviestu noteiktus risinājuma ierobežojumus, bieži vien kvalitātes ziņā. Tās var turpmāk klasificēt daudzos " lietderības " veidos, piemēram, pieejamība, uzticamība, atjaunojamība, uzturēšana, mērogojamība, veiktspēja, drošība utt.
  • Atvasināts / uzlikts / radies
    • Vai prasība izriet no citām prasībām?
    • Vai prasību skaidri nosaka ieinteresētā puse?
    • Vai prasība ir jauns īpašums? Citiem vārdiem sakot, to nevar novērst ar vienu komponentu, bet tas ir atkarīgs no tā, kā darbojas visi programmatūras komponenti.
  • Process / produkts
    • Vai prasība ir saistīta ar produktu? (piemērs: " Programmatūrai jāpārbauda personas atbilstība ")
    • Vai prasība ir saistīta ar procesu? (piemērs: " Programmatūra jāattīsta pakāpeniski un jāizmanto nepārtrauktas integrācijas un izvietošanas darbplūsmas )
  • Prioritāte
    • Izstrādes un ieviešanas izmaksu līdzsvarošana ar piegādes nepieciešamību.
    • Var izmantot fiksētas etiķetes skalu, piemēram, obligātu, ļoti vēlamu, vēlamu un neobligātu.
  • Darbības joma
    • Izmanto, lai apsvērtu ietekmi uz programmatūras arhitektūru un komponentu dizainu.
    • Nefunkcionālajiem bieži ir globāla darbības joma.
  • Nepastāvība / stabilitāte
    • Prasības potenciāls programmatūras dzīves cikla laikā mainīsies.
    • Tas palīdzēs ieviest dizainu, kas ir tolerants pret izmaiņām

Programmatūras prasību pārbaude

Kad programmatūras prasības ir noteiktas un klasificētas, tās ir jāapstiprina ar ieinteresētajām personām, lai iegūtu precizitāti un vai tās patiešām atbilst savām vajadzībām. Prasības, kuras nevar apstiprināt, ieinteresētās puses patiesībā ir tikai "vēlmes".

Ja jūs sekojat iteratīvai izstrādes metodei, prasību apstiprināšanu var veikt regulāri, atdalot pēc darbības jomas ap konkrētām risinājumu jomām, vai arī veikt gabalos vai kādu citu nošķiršanas veidu, kam ir loģiska jēga.

Prasību apstiprināšana parasti ietver risinājumu komandu, lai ieinteresētajām personām atkārtoti izprastu prasību. Tas var ietvert arī sākotnēju dizainu (biznesa vai tehnisko, vai abus), kas parāda, kā tiks īstenotas katras ieinteresētās puses vajadzības.

Šīs izpratnes iteratīvi tiek veidotas plānošanas posmos, un parasti tās sastāv no daudzfunkcionālas komandas (dizaineru, biznesa analītiķu, tehnisko ekspertu) uzskatiem.

Dažos gadījumos, lai labāk parādītu komandas sapratni, parasti funkcionāla prototipa veidā, dizains var būt nepieciešams pirms ieviešanas.

Apstiprināšanas laikā jūsu komanda, iespējams, nespēs pilnībā apmierināt visu ieinteresēto personu prasības. Jūsu kā tehniskā eksperta pienākums būs parādīt un risināt sarunas par kompromisiem, kas atbilst ierobežojumiem. Tam būs jābūt pieņemamam galvenajām ieinteresētajām personām, vienlaikus veicot arī budžeta, tehniskos, normatīvos un citus pasākumus.

Izmantojot funkcionālos prototipus

Funkcionālie prototipi ir noderīgi, jo ļauj:

  • apstiprinot, ka prasības ir saprotamas
  • vieglāk interpretēt inženiera pieņēmumus
  • atsauksmes, kas var sniegt jaunas prasības

Jums jāņem vērā, ka ieinteresētās puses var novērst kosmētikas vai kvalitātes problēmas. To var mazināt, konsekventi paziņojot par demonstrācijas patieso nozīmi - pamata funkcionalitāti.

Kā prototips tiek veidots, nosaka jūsu projekta komanda. Daži advokāti dod priekšroku prototipiem, kas pilnībā izvairās no programmatūras (līdzīgi tiem, kas izveidoti, izvirzot prasības). Citi dod priekšroku kāda veida programmatūras attēlošanai, izmantojot projektēšanas rīku komplektus vai ātri izveidotu programmatūras melnrakstu, kas atrodas funkciju kontrolē.

Neatkarīgi no izvēles, kuru izvēlas jūsu komanda, jāapsver prototipa izveides ātrums salīdzinājumā ar pamatfunkciju demonstrēšanas efektivitāti.

Programmatūras prasību izstrāde un ieviešana

Kad prasība ir apstiprināta ar ieinteresētajām personām, jūs varat sākt izstrādāt / ieviest prasību.

Daudzos gadījumos jūs darbosities kā programmatūras arhitekts, jo prasību analīzes un izstrādes process prasa identificēt arhitektūras / dizaina komponentus, kas būs atbildīgi par prasību izpildi.

Jūsu organizācijas galvenā interese ir gūt labumu no programmatūras risinājuma. Jūsu pienākums ir mēģināt izmantot metodes, kas samazina izstrādes un uzturēšanas izmaksas.

To var izdarīt, piemēram, izmantojot komponentu atkārtotu izmantošanu (iekšēji vai no citiem produktiem), izmantojot skaidri definētus modeļus un strādājot ar labi pārbaudītiem un labi dokumentētiem rīkiem / ietvariem.

Īpašas prasības, īpaši ierobežojumi, var ļoti ietekmēt programmatūras izmaksas. Piemēram, ja jūsu prasme, kas iestatīta ieviešanā, ir slikta vai varbūt prasība ir pretēja vai neatbilst pašreizējai arhitektūrai. Svarīgi kompromisi starp šādām prasībām būtu jāidentificē projekta komandai.

Visā prasību procesā svarīgs punkts, kas jums jāsaprot, ir cerība, ka ievērojama prasību daļa mainīsies. Atzīstiet izmaiņu neizbēgamību un mēģiniet veikt pasākumus savā dizainā, lai to atļautu.

Lietotāja stāsts

Programmatūras inženieris bieži strādā ar lietotāja stāstu. Lietotāja stāsts ir dabiska vārda atainojums konkrēta lietotāja tipa mijiedarbībai ar programmatūru un funkcionalitāti, kas tai viņiem jānodrošina. Parasti tas atbilst šādam formātam:

Kā es gribu, tā

Piemērs:

Kā kursu administrators es vēlos redzēt kursā reģistrēto cilvēku skaitu, lai es redzētu pašreizējo kursu ietilpību

Dažos gadījumos lietotāja stāstam būs dizains vai prototips, ja tie būs nepieciešami validācijas posmā.

Iespējams, ka lietotāja stāsts nav orientēts uz lietotāju, bet tas izriet no jauna īpašuma vai nefunkcionālas prasības. Šādos gadījumos jūs varat saņemt prasību citā piegādājamā kontekstā (piemēram, specifikācijā vai scenāriju komplektā).

Lietotāja stāsts ir paredzēts, lai saturētu tikai pietiekami daudz informācijas, lai jūsu inženieru komanda varētu sagatavot saprātīgu novērtējumu par centieniem to īstenot. Ja jūsu komanda nespēj uzrādīt saprātīgu aprēķinu, tas var liecināt par sliktu atbilstību zināšanām / prasmēm, individuālajiem pārliecības līmeņiem, piemērotības vai atkarības ierobežojumiem vai izšķiroši, ka lietotāja stāstam nav kvalitātes.

Programmatūras inženierus (obligāti) ierobežo projektu vadības plāni, tāpēc jums ir jācenšas veikt pasākumus, lai pārbaudītu, vai prasību kvalitāte ir pēc iespējas augstāka, ņemot vērā pieejamos resursus.

Pirms lietotāja stāsta ieviešanas pārbaudiet:

  • par atbilstošiem pieņemšanas kritērijiem, kas rakstīti vai saskaņoti ar ieinteresētajām pusēm, kas nosaka, kā ar lietotāja ieviešanu var sasniegt lietotāja stāsta mērķus.
    • Tas veidos pamatu funkcijas pieņemšanas testiem (citiem vārdiem sakot, testi, kas parāda prasību, ir izpildīti).
    • Tas var arī būt daļa no komandas definīcijas "pabeigts" vai pabeigts.
  • prototipa dizains (ja tāds ir izgatavots) ir iespējams un var atbilst pašreizējai arhitektūrai, inženiertehniskajām prasmēm un rīkiem, kas apstiprināti izmantošanai projektā.
  • visi pieņēmumi, kas pamato prasību.
    • Tas var izcelt nepilnības zināšanās, iespējamās problēmas vai citus neuzskatītus scenārijus / progresa gadījumus, kas no ieinteresētajām personām prasa papildu skaidrojumu.

Sarunas par programmatūras prasībām

Īstenojot prasību, iespējams, ka ne visu ieinteresēto personu intereses tiek apmierinātas perfekti. Tas var notikt, piemēram, starp funkcionālajām un nefunkcionālajām prasībām vai gadījumos, kad vienas prasības ieviešana ietekmē citas ieinteresētās puses intereses.

Vairumā gadījumu jums nav prātīgi pieņemt vienpusēju lēmumu.

Tā vietā jūs esat atbildīgs par problēmas novērtēšanu, vienkāršu saziņu un sarunām par kompromisiem, kas ir pieņemami galvenajām ieinteresētajām personām, vienlaikus ievērojot budžeta, tehniskos, normatīvos un citus ierobežojumus.

Programmatūras prasību pārbaude

Visas programmatūras prasības prasa, lai tā būtu pārbaudāma kā funkcija vai funkcionāla prasība vai globālā līmenī kā nefunkcionāla prasība. Prasības jāpārbauda attiecībā uz gatavo produktu.

Svarīgs uzdevums jums ir plānot, kā pārbaudīt katru prasību.

Programmatūras inženieris pārbauda prasību, izmantojot pieņemšanas testu. Pieņemšanas tests parāda, kā prasība ir izpildīta (izpildot pieņemšanas kritērijus), parādot galalietotāja rīcību, veicot uzņēmējdarbību ar programmatūru, kā noteikts prasībā.

Prasībās, kurās verifikāciju ir grūtāk pierādīt, piemēram, nefunkcionālas prasības, var būt nepieciešama konstruēta simulācija. Piemēram, lai pārbaudītu programmatūras veiktspējas slodzi, ieviešot ieplūdes procesu, testēšanas programmatūru var izveidot, lai simulētu vai tūkstošus lietojumprogrammu simulētu sistēmā melnās kastes pieņemšanas testā.

Tā kā programmatūra laika gaitā attīstās, jaunas prasības ieviešana var netīši ietekmēt iepriekš ieviesto prasību izpildi. Šo regresiju var pasargāt, automatizējot pieņemšanas testus. Jūs varat atrast daudzus rīkus un bibliotēkas, kas pieejamas programmēšanas valodām, kuras parasti izmanto uzņēmumi, kas ļauj automatizēt pieņemšanas testus.

Nejauciet pieņemšanas testu kā savu vienīgo testēšanas atbildību. Adekvāti mēģiniet aptvert ieviešanu ar citiem testiem, izņemot pieņemšanu, piemēram, vienības vai integrācijas testus.

Pieņemšanas testi sarežģītības pakāpē atšķiras atkarībā no pieņemšanas kritērijiem. Dažādas organizācijas var izmantot arī atšķirīgu terminoloģiju un praksi, kas nozīmē, ka to var sajaukt ar cita veida testiem vai uz tām var minēt dažādus nosaukumus, piemēram, end-to-end testēšanu, funkcionālo testēšanu vai scenāriju testēšanu. Jūsu organizācijai var būt arī stingri kritēriji vai formāti, kādos tiek demonstrēti pieņemšanas testi.

Atcerieties, ka katra pieņemšanas testa būtība ir tikai formāla pārbaude, vai ieviests risinājums atbilst programmatūras prasībām, atkārtojot lietotāja uzvedību, palaižot lietojumprogrammu pret gala produktu.

Īsumā tas viss

Jūs esat to paveicis. Slava jums!

Es ceru, ka šis raksts sniedza zināmu labumu, atzīstot jūsu kā programmatūras inženiera lomu ar programmatūras prasībām.

Vairāk manus rakstus varat izlasīt manā emuārā.

Šis raksts tiek kopīgots brīvi, un autors nesaņēma nekādu ieguldījumu vai peļņu, kā to nosaka SWEBOK autortiesību un atkārtotas izdrukāšanas atļaujas. Jebkurš izteiktais viedoklis vai viedoklis neatspoguļo IEEE vai jebkuras struktūras / organizācijas, ar kuru es esmu saistīts, viedokli vai viedokli, un IEEE to nav apstiprinājis, un tas pārstāv tikai manu viedokli un viedokļus.