Fitimet:
- Aftësia për të transformuar kërkesat e paqarta të biznesit në kërkesa të qarta, të testueshme softuerësh dhe histori të përdoruesve me mbështetjen e AI
- Aftësia për të krahasuar të mirat dhe të këqijat e dizajnit të sistemit, modelit të të dhënave dhe vendimeve arkitekturore në një mënyrë të strukturuar me AI
- Aftësia për të vërtetuar në mënyrë kritike dizajnin e propozuar të AI kundrejt kërkesave, shkallëzueshmërisë dhe kufizimeve
Shumica e projekteve softuerike dështojnë jo për shkak të kodit të keq, por për shkak të kërkesave të keqkuptuara. Një kërkesë me një fjali si "Lëri përdoruesit të shkarkojnë raporte" lë pas dhjetëra pyetje pa përgjigje: Në çfarë formati? Kush është në krye? Sa rekorde? Po sikur të jetë i ngadalshëm? Analiza e kërkesave (përkthimi i një kërkese biznesi në nevoja teknike të qarta dhe të testueshme) dhe dizajni i softuerit (ndërtimi i strukturës në letër për të përmbushur këto nevoja) është faza ku parandalohen gabimet më të shtrenjta përpara se të shkruhet kodi. Në këtë njësi, ne do të mësojmë të përdorim AI si një "partner mendimi" në këtë fazë: një partner që çmitizon pasigurinë, zgjidh opsionet, por vendimin përfundimtar ia lë juve.
AI prodhon dy vlera të mëdha këtu. Së pari, ai bën pyetje që ju i kaloni; Ai nxjerr në sipërfaqe supozimet e fshehura dhe rastet e skajshme në një kërkesë. Së dyti, ai paraqet shpejt të mirat dhe të këqijat e një vendimi të projektimit. Por ky është rreziku: AI do të japë rekomandime të përgjithshme si "praktika më e mirë" pa e ditur plotësisht kontekstin tuaj (buxheti, ekipi, sistemi ekzistues, kufizimi ligjor). Është detyra juaj ta filtroni këtë këshillë kundër të vërtetës suaj.
Konceptet: Historia e përdoruesit: Një fjali e shkurtër që shpreh një nevojë në formën e "... si, dua të jem në gjendje... sepse...". Kriteret e pranimit: Kushtet e testueshme që duhet të plotësohen që një punë të konsiderohet "e kryer". Kërkesa jofunksionale: Kërkesat që lidhen me "si do të sillet" dhe jo "çfarë do të bëjë", si shpejtësia, siguria, shkallëzueshmëria.
Nga Kërkesa e Paqartë te Kërkesa e Testueshme
Një kërkesë e mirë është e matshme dhe e verifikueshme. Jo "le të jetë sistemi i shpejtë", por "le rezultatet e kërkimit të kthehen brenda 500 ms". Këtu është një mënyrë hap pas hapi për të përdorur AI për të kufizuar pasigurinë:
- Jepni kërkesën ashtu siç është dhe bëni pyetjen. Kërkojini AI jo zgjidhjen, por së pari të "renditni çdo gjë të paqartë në këtë kërkesë si pyetje".
- Ju jepni përgjigjet. Vetëm ju e dini kontekstin; Përgjigjuni pyetjeve të AI me kufizimet reale të biznesit tuaj.
- Përkthejeni atë në tregimet e përdoruesve dhe kriteret e pranimit. Përkthejeni nevojën e sqaruar në artikuj të testueshëm.
- Shtoni rastet e skajshme dhe skenarët negativë. "Rezultat bosh", "përdorues i paautorizuar", "skedar shumë i madh" etj.
Kërkesa për nxjerrjen e paqartësisë: "Ne do ta përkthejmë kërkesën e mëposhtme të biznesit në një kërkesë softueri. Mos propozoni ende një zgjidhje. Së pari, nxirrni TË GJITHA paqartësitë dhe supozimet e fshehura që nuk janë përgjigjur në këtë kërkesë si një listë pyetjesh. Grupojini pyetjet nën titujt e mëposhtëm: fushëveprimi, përdoruesi/autoriteti, vëllimi i të dhënave, performanca, historia e gabimeve: raporti i ripërdorimit si "aL".
Kërkesa për historinë e përdoruesit + kriteret e pranimit: "Ndani nevojën e mëposhtme të sqaruar në tregimet e përdoruesve që përputhen me parimet e INVEST. Shkruani 3-5 kritere pranimi të testueshme për secilën histori (në formatin Given-When-Then). Shtoni të paktën 2 skenarë negativë (qasje e paautorizuar, të dhëna boshe). Nevojë: [shkruaj nevojën e sqaruar këtu]"
Krahasimi i vendimeve të projektimit me AI
Dizajni është një kompromis i vazhdueshëm: shpejtësia kundrejt fleksibilitetit, thjeshtësia kundrejt shkallëzueshmërisë? Inteligjenca artificiale i vendos këto shkëmbime në një tabelë të shpejtë. Për shembull, për një veçori "dërgoni njoftim", mund të debatoni nëse do të përdorni një qasje sinkrone (dërgoni sipas kërkesës) ose asinkrone (radhë, dërgoni në sfond).
Prompt krahasimi i dizajnit: "Po dizajnoj një veçori "dërgoni një njoftim me email te përdoruesi". Krahasoni dy qasjet: (A) dërgimi sinkron gjatë kërkesës HTTP, (B) dërgimi asinkron në sfond duke e vendosur atë në radhën e mesazheve. Bëni një tabelë në akset e mëposhtme: koha e pritjes së përdoruesit, toleranca e gabimeve2. toleranca e gabimeve 2, vështirësia në infrastrukturën e cila debugg. Në fund do të zgjidhja në cilin rast mos e merrni vendimin për mua”.
boshti
transmetim sinkron
Asinkron (radhë)
Koha e pritjes së përdoruesit
E gjatë (në pritje të dërgesës)
E shkurtër (kthehet menjëherë)
Toleranca ndaj gabimeve
E ulët (kërkesa shpërthen nëse shpërthen dërgesa)
E lartë (riprovoni e mundur)
kompleksiteti
të ulëta
Mesatar-i lartë (infrastruktura e radhës)
Kostoja e infrastrukturës
të ulëta
Kërkohen komponentë shtesë
Aty ku përshtatet
Vëllim i ulët, aplikim i thjeshtë
Vëllim i lartë, shpërndarje kritike
Këshillë: T'i thuash AI "mos merr vendimin për mua, vetëm më trego opsionet dhe kushtet" ju detyron të mendoni dhe zvogëlon rrezikun e pranimit verbërisht të një sugjerimi. Vendimi më i mirë i dizajnit është ai që merret nga personi që njeh kontekstin tuaj (ju).
Prompt i dobët / Prompt i fortë
I DOBËT: "Dizajnoni një bazë të dhënash për sistemin e porosive." (Rezultati: cila shkallë, cilat marrëdhënie, cilat kufizime nuk janë të qarta; një skemë e përgjithshme, jorealiste.) FORTË: "Sugjeroni një model të dhënash draft për një tregti të vogël elektronike. Subjektet: Klienti, Porosi, Produkti, Artikulli i Porosisë. Kufizimet: mund të ketë shumë produkte në një porosi; çmimi i produktit mund të ndryshojë me kalimin e kohës; çmimi i produktit mund të ndryshojë me kalimin e kohës, por porosia aktuale është në çmimin e kaluar ~ 0 Marrëdhëniet e pritshme dhe pse ajo “Shpjegoni se e morët vendimin. Specifikoni se si e keni zgjidhur problemin e historisë së çmimeve. Jepni atë si një listë entitetesh dhe fushash, jo kod."
Dallimi i një prompt të fuqishëm; shkalla (500 porosi në ditë), rregulli i biznesit (çmimi i kaluar duhet të ruhet) dhe formati i dëshiruar i daljes. Një fjali e vetme si "Çmimi i kaluar duhet të ruhet" ndryshon plotësisht dizajnin; Nëse nuk e specifikoni këtë, AI do të prodhojë një diagramë të pasaktë, por të besueshme.
Mini Rastet
Rasti 1 - Supozimi i fshehur. Një ekip kodon drejtpërdrejt kërkesën "përdoruesi mund të ngarkojë foto të profilit". Një ekip tjetër pyeti AI në lidhje me pasigurinë: "madhësia maksimale? formatet e lejuara? kontrolli i papërshtatshëm i përmbajtjes? fshini foton e vjetër?" Ai prodhon 8 pyetje si. Ekipi i parë mëson për problemin në prodhim kur skedarët 20 MB mbushin serverin; Ekipi i dytë e zgjidh atë në dizajn.
Rasti 2 - Supozim i gabuar i shkallës. AI propozon një shtresë komplekse memorie për një veçori raportimi. Kur inxhinieri thekson se të dhënat reale janë vetëm 30 raporte në ditë, AI thjeshton sugjerimin. Mospërcaktimi i shkallës shkakton koston e kompleksitetit të panevojshëm; specifikimi kursen 2 javë punë të panevojshme.
Rasti 3 - Hendeku i kritereve të pranimit. "Çfarë ndodh nëse pagesa dështon?" Meqenëse pyetja nuk u bë kurrë, një sistem porosie do të vazhdojë të shënojë porosinë si "të konfirmuar" në rast të pagesës së pasuksesshme. Lista e skenarëve negativë të krijuar nga AI e kap këtë boshllëk; Kriteret e pranimit të 1 rreshtit parandalojnë humbjen reale të parave.
Gabimet e zakonshme
- Kalimi i kërkesës drejtpërdrejt në kod. Kodi i shkruar përpara se të zgjidhet paqartësia zgjidh shpejt problemin e gabuar.
- Duke marrë verbërisht "praktikën më të mirë" të përgjithshme të AI. Nëse nuk e specifikoni kontekstin tuaj (shkallën, buxhetin, ekipin), rekomandimi nuk do të funksionojë për ju.
- Kapërcimi i kërkesave jofunksionale. Nëse shpejtësia, siguria dhe shkalla nuk janë të specifikuara, dizajni do të jetë i paplotë.
- Vetëm duke menduar për skenarin e lumtur. Skenarët negativë si të dhënat boshe, përdoruesi i paautorizuar, statusi i gabimit duhet të përfshihen në dizajn.
- Delegimi i vendimit tek AI. AI gjeneron opsione; Ju vendosni se cili kompensim i përshtatet biznesit tuaj.
Në përmbledhje
Analiza dhe dizajni i kërkesave është faza ku kapen gabimet më të lira. Këtu, AI gjeneron pyetje që zbulojnë pasiguri, harton historitë e përdoruesve dhe kriteret e pranimit dhe grafikon shkëmbimet e dizajnit. Por vetëm ju e dini kontekstin; Është detyra juaj të filtrosh rekomandimet e AI bazuar në shkallën, buxhetin, ekipin dhe kufizimet ligjore dhe të marrësh vendimin përfundimtar. Disiplina e "mos merr vendimin për mua, më trego opsionet" të çon në dizajn më të mirë dhe mësim më të thellë.
Detyra e aplikimit
Zgjidhni një kërkesë pune me një fjali nga konteksti juaj. Së pari, aplikoni kërkesën e paqartësisë në AI dhe përgjigjuni pyetjeve me kufizimet tuaja reale. Më pas përkthejeni nevojën e sqaruar në të paktën 2 histori përdoruesish dhe 3 kritere pranimi për secilën; Përfshi të paktën 1 skenar negativ. Së fundi, krijoni një tabelë krahasimi për një vendim projektimi (sinkron/asinkron, struktura e tabelës, etj.) dhe shkruani vendimin tuaj në 2 fjali.
listë kontrolli
- [ ] I hoqa paqartësitë si pyetje përpara se ta kaloja kërkesën në kod.
- [ ] I dhashë kontekstin (shkallën, autoritetin, performancën, kufizimin ligjor) UA.
- [ ] Kam ndarë historitë e përdoruesve në kritere pranimi të testueshme.
- [ ] Unë shtova të paktën një skenar negativ/përparësor.
- [ ] Unë e vlerësova vendimin e projektimit me tabelën e shkëmbimit.
- [ ] Vendimin përfundimtar e mora në bazë të kontekstit tim, nuk ia lashë AI.