Добивки:
- Способност да се трансформираат нејасните деловни барања во јасни, проверливи софтверски барања и кориснички приказни со поддршка за вештачка интелигенција
- Способност да се споредат добрите и лошите страни на дизајнот на системот, моделот на податоци и архитектонските одлуки на структуриран начин со ВИ
- Способност критички да се потврди предложениот дизајн на вештачката интелигенција во однос на барањата, приспособливоста и ограничувањата
Поголемиот дел од софтверските проекти не успеваат поради лош код, туку поради погрешно разбрани барања. Барањето од една реченица како „Дозволете корисниците да преземаат извештаи“ остава зад себе десетици неодговорени прашања: Во каков формат? Кој е одговорен? Колку рекорди? Што ако е бавно? Анализата на барањата (преведување на деловното барање во јасни технички потреби што може да се тестираат) и дизајнот на софтверот (конструирање на структурата на хартија за да се задоволат овие потреби) е фазата во која се спречуваат најскапите грешки пред да се напише код. Во оваа единица, ќе научиме да користиме вештачка интелигенција како „партнер на мислата“ во оваа фаза: партнер кој ја демистифицира несигурноста, ги средува опциите, но ја остава конечната одлука на вас.
ВИ произведува две големи вредности овде. Прво, поставува прашања што ги прескокнувате; Исфрла на површина скриени претпоставки и рабови во барањето. Второ, брзо ги прикажува добрите и лошите страни на одлуката за дизајн. Но, тоа е опасноста: вештачката интелигенција ќе даде генерички препораки како „најдобра практика“ без целосно да го знае вашиот контекст (буџет, тим, постоечки систем, законско ограничување). Ваша задача е да го филтрирате овој совет против сопствената вистина.
Поими: Корисничка приказна: Кратка реченица во која се изразува потреба во форма на „... како, сакам да можам... затоа што...“. Критериуми за прифаќање: Услови за тестирање кои мора да се исполнат за да се смета дека работата е „завршена“. Нефункционално барање: Барања поврзани со „како ќе се однесува“ наместо „што ќе прави“, како што се брзина, безбедност, приспособливост.
Од нејасно барање до услов за тестирање
Доброто барање е мерливо и проверливо. Не „системот нека биде брз“, туку „нека резултатите од пребарувањето се вратат во рок од 500 ms“. Еве чекор-по-чекор начин да се користи вештачката интелигенција за да се намали неизвесноста:
- Дајте го барањето како што е и нека се генерира прашањето. Прашајте ја вештачката интелигенција не за решението, туку прво „наведете нешто нејасно во ова барање како прашање“.
- Вие ги давате одговорите. Само вие го знаете контекстот; Одговорете на прашањата на вештачката интелигенција со вашите реални деловни ограничувања.
- Преведете го во кориснички приказни и критериуми за прифаќање. Преведете ја разјаснетата потреба во ставки што може да се тестираат.
- Додадете рабови и негативни сценарија. „Празен резултат“, „неовластен корисник“, „премногу голема датотека“ итн.
Прашање за извлекување нејаснотии: „Следното деловно барање ќе го преведеме во услов за софтвер. Сè уште не предлагајте решение. Прво, извлечете ги СИТЕ нејаснотии и скриени претпоставки што не се одговорени во ова барање како листа на прашања. Групирајте ги прашањата под следните наслови: опсег, корисник/авторитет, волумен на податоци, перформанси, историја на нарачка за грешки, како „АL“.
Прашај за корисничка приказна + критериуми за прифаќање: "Поделете ја следната разјаснета потреба на кориснички приказни кои се во согласност со принципите на INVEST. Напишете 3-5 критериуми за прифаќање што може да се тестираат за секоја приказна (во формат Given-When-Then). Додадете најмалку 2 негативни сценарија (неовластен пристап, празни податоци). Потребно: [напишете разјаснета потреба овде]"
Споредување на одлуки за дизајн со вештачка интелигенција
Дизајнот е постојан компромис: брзина наспроти флексибилност, едноставност наспроти приспособливост? Вештачката интелигенција ги става овие компромиси во брза табела. На пример, за функцијата „испрати известување“, можете да дебатирате дали да користите синхрон (испрати на барање) или асинхрон (редица, испраќање во заднина) пристап.
Програма за споредба на дизајнот: „Дизајнирам функција „испрати известување по е-пошта до корисникот“. Споредете ги двата пристапа: (А) синхрона испорака за време на барањето HTTP, (Б) асинхрона испорака во заднина со тоа што ќе ја ставите во редот за пораки. Направете табела на следните оски: време на чекање корисник, толеранција на грешки2, сложеност на реченицата, сложеност во инфраструктурата, дебугг На крајот би избрал во кој случај не ја донесувај одлуката наместо мене“.
оска
синхрони пренос
Асинхроно (редица)
Време на чекање на корисникот
Долго (се чека за испорака)
Кратко (се враќа веднаш)
Толеранција на грешки
Ниско (барањето експлодира ако праќањето експлодира)
Високо (можно е да се обиде повторно)
сложеност
низок
Средно-висока (инфраструктура на редица)
Трошоци за инфраструктура
низок
Потребни се дополнителни компоненти
Каде што одговара
Низок волумен, едноставна апликација
Висок волумен, критична испорака
Совет: Ако ѝ кажете на вештачката интелигенција „не ја донесувајте одлуката наместо мене, само покажете ми ги опциите и условите“ ве принудува да размислите и го намалува ризикот слепо да прифатите предлог. Најдобрата одлука за дизајн е онаа што ја носи личноста која го познава вашиот контекст (вие).
Слаба навестување / Силен навестување
СЛАБ: „Дизајнирајте база на податоци за системот за нарачки“. (Резултат: која скала, кои односи, кои ограничувања не се јасни; општа, нереална шема.) СИЛНО: "Предложете нацрт-модел на податоци за мала е-трговија. Ентитети: Клиент, Нарачка, Производ, Ставка на нарачка. Ограничувања: може да има многу производи во нарачката; цената на производот може да се промени со текот на времето; цената на производот може да се зачува со текот на времето, но тековната нарачка е 50 ден. очекуваните односи и зошто тоа „Објаснете дека сте ја донеле одлуката. Наведете како го решивте проблемот со историјата на цените. Дајте го како листа на ентитети и полиња, а не како код“.
Разликата на моќен промпт; скала (500 нарачки дневно), деловно правило (мора да се зачува претходната цена) и саканиот излезен формат. Една реченица како „Минатата цена мора да се одржи“ целосно го менува дизајнот; Ако не го наведете ова, вештачката интелигенција ќе произведе неточен, но веродостоен дијаграм.
Мини футроли
Случај 1 - Скриена претпоставка. Тим директно го шифрира барањето „корисникот може да постави фотографија на профилот“. Друг тим ја праша вештачката интелигенција за неизвесноста: „максимална големина? дозволени формати? несоодветна контрола на содржината? бришење стара фотографија? Таа создава 8 прашања како. Првиот тим дознава за проблемот во производството кога серверот го исполнуваат датотеките од 20 MB; Вториот тим го решава во дизајнот.
Случај 2 - Неточна претпоставка за скалата. Вештачката интелигенција предлага сложен слој за кеширање за функцијата за известување. Кога инженерот истакнува дека вистинските податоци се само 30 извештаи дневно, вештачката интелигенција го поедноставува предлогот. Непрецизирањето на скалата носи трошоци за непотребна сложеност; специфицирањето заштедува 2 недели непотребна работа.
Случај 3 - Јаз во критериумите за прифаќање. „Што ќе се случи ако плаќањето не успее? Бидејќи прашањето никогаш не беше поставено, системот за нарачки сепак ќе ја означи нарачката како „потврдена“ во случај на неуспешно плаќање. Списокот на негативни сценарија генерирани од вештачката интелигенција ја доловува оваа празнина; Критериумите за прифаќање 1 линија спречуваат вистинска загуба на пари.
Вообичаени грешки
- Пренесување на барањето директно на кодот. Кодот напишан пред да се реши нејаснотијата брзо го решава погрешниот проблем.
- Слепо преземање на општата „најдобра практика“ на вештачката интелигенција. Ако не го наведете вашиот контекст (скала, буџет, тим), препораката нема да работи за вас.
- Прескокнување на нефункционални барања. Ако брзината, безбедноста и обемот не се специфицирани, дизајнот ќе биде нецелосен.
- Само размислување за среќното сценарио. Во дизајнот треба да бидат вклучени негативни сценарија како празни податоци, неовластен корисник, статус на грешка.
- Делегирање на одлуката на АИ. ВИ генерира опции; Вие одлучувате кој компромис одговара на вашиот бизнис.
Сумирано
Анализата и дизајнот на барањата е фаза каде што се фатени најевтините грешки. Овде, вештачката интелигенција генерира прашања што откриваат несигурност, ги подготвува приказните за корисниците и критериумите за прифаќање, и ги прави графиконите за размени. Но, само вие го знаете контекстот; Ваша задача е да ги филтрирате препораките на вештачката интелигенција врз основа на вашата скала, буџет, тим и законски ограничувања и да ја донесете конечната одлука. Дисциплината „не донесувај ја одлуката наместо мене, покажи ми ги опциите“ води и до подобар дизајн и до подлабоко учење.
Задача за апликација
Изберете барање за работа со една реченица од вашиот контекст. Прво, применете го барањето за двосмисленост на вештачката интелигенција и одговорете на прашањата со вашите вистински ограничувања. Потоа преведете ја разјаснетата потреба во најмалку 2 кориснички приказни и 3 критериуми за прифаќање за секоја; Вклучете најмалку 1 негативно сценарио. Конечно, креирајте споредбена табела за одлука за дизајн (синхрона/асинхрона, структура на табела итн.) и напишете ја вашата сопствена одлука во 2 реченици.
листа за проверка
- [ ] Ги отстранив нејаснотијата како прашања пред да го пренесам барањето во кодот.
- [ ] Го дадов контекстот (скала, авторитет, перформанси, законско ограничување) на вештачката интелигенција.
- [ ] Ги скршив корисничките приказни во критериуми за прифаќање што може да се тестираат.
- [ ] Додадов барем едно сценарио за негативна страна/раб.
- [ ] Ја оценив одлуката за дизајн со табела за компромиси.
- [ ] Конечната одлука ја донесов врз основа на мојот контекст, не препуштив на вештачката интелигенција.