Ieguvumi:
- Iespēja pārveidot neskaidrus biznesa pieprasījumus skaidrās, pārbaudāmās programmatūras prasībās un lietotāju stāstos ar AI atbalstu
- Spēja strukturētā veidā salīdzināt sistēmas projektēšanas, datu modeļa un arhitektūras lēmumu priekšrocības un trūkumus ar AI
- Spēja kritiski pārbaudīt AI piedāvāto dizainu attiecībā uz prasībām, mērogojamību un ierobežojumiem
Lielākā daļa programmatūras projektu neizdodas nevis slikta koda, bet gan pārprastu prasību dēļ. Viena teikuma pieprasījums, piemēram, “Ļaut lietotājiem lejupielādēt pārskatus”, atstāj aiz sevis desmitiem neatbildētu jautājumu: kādā formātā? Kurš ir atbildīgs? Cik ierakstu? Ko darīt, ja tas ir lēns? Prasību analīze (biznesa pieprasījuma pārveidošana skaidrās, pārbaudāmās tehniskās vajadzībās) un programmatūras projektēšana (struktūras izveidošana uz papīra, lai apmierinātu šīs vajadzības) ir posms, kurā tiek novērstas visdārgākās kļūdas pirms koda rakstīšanas. Šajā nodaļā mēs šajā posmā iemācīsimies izmantot AI kā “domu partneri”: partneri, kas novērš nenoteiktību, izšķir iespējas, bet galīgo lēmumu atstāj jūsu ziņā.
AI šeit rada divas lielas vērtības. Pirmkārt, tas uzdod jautājumus, kurus jūs izlaižat; Tas pieprasījumā izceļ slēptus pieņēmumus un malas gadījumus. Otrkārt, tajā ātri apkopoti dizaina lēmuma plusi un mīnusi. Bet tas ir briesmas: AI sniegs vispārīgus ieteikumus kā "labāko praksi", pilnībā nezinot jūsu kontekstu (budžets, komanda, esošā sistēma, juridiskie ierobežojumi). Jūsu uzdevums ir filtrēt šo padomu pret savu patiesību.
Jēdzieni: Lietotāja stāsts: Īss teikums, kas izsaka vajadzību formā "... kā, es gribu, lai varētu... jo...". Pieņemšanas kritēriji: Pārbaudāmi nosacījumi, kas jāievēro, lai darbu uzskatītu par "paveiktu". Nefunkcionāla prasība: prasības, kas saistītas ar “kā tas darbosies”, nevis “ko tas darīs”, piemēram, ātrums, drošība, mērogojamība.
No neskaidra pieprasījuma līdz pārbaudāmai prasībai
Laba prasība ir izmērāma un pārbaudāma. Nevis "ļaujiet sistēmai būt ātrai", bet "ļaujiet meklēšanas rezultātiem atgriezties 500 ms laikā". Tālāk ir sniegts detalizēts veids, kā izmantot AI, lai samazinātu nenoteiktību.
- Sniedziet pieprasījumu tādu, kāds tas ir, un ģenerējiet jautājumu. Nejautājiet AI par risinājumu, bet vispirms "uzskaitiet visu neskaidro šajā pieprasījumā kā jautājumu".
- Jūs sniedzat atbildes. Tikai jūs zināt kontekstu; Atbildiet uz AI jautājumiem, norādot savus patiesos biznesa ierobežojumus.
- Lieciet to pārvērst lietotāju stāstos un pieņemšanas kritērijos. Pārvērtiet noskaidroto vajadzību pārbaudāmos priekšmetos.
- Pievienojiet malas gadījumus un negatīvus scenārijus. "Tukšs rezultāts", "neautorizēts lietotājs", "pārāk liels fails" utt.
Neskaidrības izvilkšanas uzvedne: "Mēs pārveidosim šādu biznesa pieprasījumu programmatūras prasībā. Vēl nepiedāvājiet risinājumu. Vispirms kā jautājumu sarakstu izņemiet VISAS neskaidrības un slēptos pieņēmumus, uz kuriem nav atbildēts šajā pieprasījumā. Grupējiet jautājumus šādos virsrakstos: tvērums, lietotājs/iestāde, datu apjoms, veiktspēja, kļūdu apstākļi, drošība. Pieprasīt lietotāju lejupielādi.
Lietotāja stāsts + pieņemšanas kritēriju uzvedne: "Sadaliet šādu noskaidroto vajadzību lietotāju stāstos, kas atbilst INVEST principiem. Katram stāstam uzrakstiet 3-5 pārbaudāmus pieņemšanas kritērijus (formātā Dots-Kad-Tad). Pievienojiet vismaz 2 negatīvus scenārijus (nesankcionēta piekļuve, tukši dati). Nepieciešams: [rakstīt precizēto nepieciešamību šeit]"
Dizaina lēmumu salīdzināšana ar AI
Dizains ir pastāvīgs kompromiss: ātrums pret elastību, vienkāršība pret mērogojamību? AI šos kompromisus ievieto ātrā izklājlapā. Piemēram, par funkciju “Nosūtīt paziņojumu”, varat apspriest, vai izmantot sinhrono (nosūtīt pēc pieprasījuma) vai asinhrono (rinda, sūtīšana fonā) pieeju.
Dizaina salīdzināšanas uzvedne: "Es izstrādāju funkciju "Nosūtīt e-pasta paziņojumu lietotājam". Salīdziniet abas pieejas: (A) sinhronā piegāde HTTP pieprasījuma laikā, (B) asinhronā piegāde fonā, ievietojot to ziņojumu rindā. Izveidojiet tabulu par šādām asīm: lietotāja gaidīšanas laiks, kļūdu tolerance, sarežģītība, viena teikuma debugging, kas man būtu grūti. galu galā, nepieņemiet lēmumu manā vietā.
ass
sinhronā pārraide
Asinhrons (rinda)
Lietotāja gaidīšanas laiks
Ilgi (gaida sūtījumu)
Īss (atgriežas nekavējoties)
Kļūdu tolerance
Zems (pieprasījums eksplodē, ja sūtījums eksplodē)
Augsts (iespējams mēģināt vēlreiz)
sarežģītība
zems
Vidēji augsta (rindas infrastruktūra)
Infrastruktūras izmaksas
zems
Nepieciešamas papildu sastāvdaļas
Kur tas der
Mazs skaļums, vienkārša pielietošana
Liels apjoms, kritiska piegāde
Padoms. Sakot AI “nepieņemiet lēmumu manā vietā, vienkārši parādiet man iespējas un nosacījumus”, jūs piespiežat domāt un samazina risku akli pieņemt ieteikumu. Labāko dizaina lēmumu pieņem persona, kas zina jūsu kontekstu (jūs).
Vāja uzvedne / spēcīga uzvedne
VĀJS: "Izstrādājiet datubāzi pasūtījumu sistēmai." (Rezultāts: kāds mērogs, kuras attiecības, kādi ierobežojumi nav skaidri; vispārēja, nereāla shēma.) STRONG: "Ieteikt datu modeļa uzmetumu nelielai e-komercijai. Entītijas: Klients, Pasūtījums, Produkts, Pasūtījuma vienība. Ierobežojumi: pasūtījumā var būt daudz produktu; preces cena laika gaitā var mainīties, bet pašreizējā pasūtījuma cena jāsaglabā 0 dienā. un kāpēc "Paskaidrojiet, ka pieņēmāt lēmumu. Norādiet, kā atrisinājāt cenu vēstures problēmu. Dodiet to kā entītiju un lauku sarakstu, nevis kodu."
Spēcīgas uzvednes atšķirība; mērogs (500 pasūtījumi dienā), biznesa noteikums (jāsaglabā iepriekšējā cena) un vēlamais izvades formāts. Viens teikums, piemēram, "Iepriekšējā cena ir jāsaglabā" pilnībā maina dizainu; Ja jūs to nenorādīsit, AI izveidos neprecīzu, bet ticama izskata diagrammu.
Mini futrāļi
1. gadījums — slēpts pieņēmums. Komanda tieši kodē pieprasījumu "lietotājs var augšupielādēt profila fotoattēlu". Cita komanda jautāja AI par nenoteiktību: "maksimālais izmērs? atļautie formāti? neatbilstoša satura kontrole? Vai izdzēst veco fotoattēlu?" Tas rada 8 līdzīgus jautājumus. Pirmā komanda uzzina par problēmu ražošanā, kad serveri aizpilda 20 MB faili; Otrā komanda to atrisina dizainā.
2. gadījums — nepareizs mēroga pieņēmums. AI piedāvā sarežģītu kešatmiņas slāni ziņošanas funkcijai. Kad inženieris norāda, ka reālie dati ir tikai 30 ziņojumi dienā, AI vienkāršo ieteikumu. Mēroga nenorādīšana rada nevajadzīgas sarežģītības izmaksas; norādot ietaupa 2 nedēļas no nevajadzīga darba.
3. gadījums. Pieņemšanas kritēriju trūkums. "Kas notiek, ja maksājums neizdodas?" Tā kā jautājums nekad netika uzdots, pasūtījumu sistēma joprojām atzīmēs pasūtījumu kā "apstiprinātu" neveiksmīga maksājuma gadījumā. AI radītais negatīvo scenāriju saraksts atspoguļo šo trūkumu; 1 rindas pieņemšanas kritēriji novērš reālu naudas zaudējumu.
Biežas kļūdas
- Pieprasījuma nosūtīšana tieši uz kodu. Kods, kas uzrakstīts pirms neskaidrības novēršanas, ātri atrisina nepareizo problēmu.
- Akli ievēro vispārējo mākslīgā intelekta “labāko praksi”. Ja nenorādīsiet savu kontekstu (mērogs, budžets, komanda), ieteikums jums nederēs.
- Nefunkcionālo prasību izlaišana. Ja ātrums, drošība un mērogs nav norādīti, dizains būs nepilnīgs.
- Vienkārši domāju par laimīgo scenāriju. Negatīvie scenāriji, piemēram, tukši dati, neautorizēts lietotājs, kļūdas statuss, ir jāiekļauj dizainā.
- Lēmuma pieņemšanas deleģēšana AI. AI ģenerē opcijas; Jūs izlemjat, kurš kompromiss ir piemērots jūsu biznesam.
Rezumējot
Prasību analīze un projektēšana ir posms, kurā tiek konstatētas lētākās kļūdas. Šeit mākslīgais intelekts ģenerē jautājumus, kas atklāj nenoteiktību, izstrādā lietotāju stāstus un pieņemšanas kritērijus, kā arī diagrammas dizaina kompromisus. Bet tikai jūs zināt kontekstu; Jūsu uzdevums ir filtrēt AI ieteikumus, pamatojoties uz jūsu mērogu, budžetu, komandu un juridiskajiem ierobežojumiem, un pieņemt galīgo lēmumu. Disciplīna “nepieņem lēmumu manā vietā, parādi man iespējas” nodrošina gan labāku dizainu, gan dziļāku mācīšanos.
Lietojumprogrammas uzdevums
Izvēlieties viena teikuma darba pieprasījumu no sava konteksta. Pirmkārt, piemērojiet neskaidrības uzvedni AI un atbildiet uz jautājumiem ar saviem patiesajiem ierobežojumiem. Pēc tam tulkojiet precizēto vajadzību vismaz 2 lietotāju stāstos un 3 pieņemšanas kritērijos katram; Iekļaujiet vismaz 1 negatīvu scenāriju. Visbeidzot izveidojiet salīdzināšanas tabulu dizaina lēmumam (sinhrons/asinhrons, tabulas struktūra utt.) un uzrakstiet savu lēmumu 2 teikumos.
kontrolsaraksts
- [ ] Es noņēmu neskaidrības kā jautājumus pirms pieprasījuma nodošanas kodā.
- [ ] Es sniedzu AI kontekstu (mērogs, autoritāte, veiktspēja, juridisks ierobežojums).
- [ ] Es sadalīju lietotāju stāstus pārbaudāmos pieņemšanas kritērijos.
- [ ] Es pievienoju vismaz vienu mīnusa/malas scenāriju.
- [ ] Es novērtēju dizaina lēmumu ar kompromisu tabulu.
- [ ] Galīgo lēmumu pieņēmu, pamatojoties uz savu kontekstu, neatstāju to AI ziņā.