Наскільки поширене прототипування як перший етап розвитку?

Протягом останніх семестрів я проходив кілька курсів дизайну програмного забезпечення, і, хоча бачу користь у великому формалізмі, я відчуваю, що він нічого не говорить про саму програму:

• Ви не можете сказати, як програма працюватиме з специфікацією Use Case, навіть якщо вона обговорює, що програма може зробити.
• Ви не можете нічого розповісти про досвід користувача з документа про вимоги, навіть якщо він може містити вимоги до якості.
• Діаграми послідовності - це хороший опис того, як програмне забезпечення працює як стек викликів, але вони дуже обмежені і дають дуже часткове уявлення про загальну систему.
• Діаграми класів чудово описують, як побудована система, але абсолютно марні, щоб допомогти вам зрозуміти, яким програмним забезпеченням повинно бути.

Де в усьому цьому формалізм є підсумком: як програма виглядає, функціонує та який досвід вона дає? Хіба немає сенсу розробляти це? Хіба не краще зрозуміти, як програма повинна працювати через прототип, і намагатися реалізувати її реально?

Я знаю, що я, мабуть, страждаю від того, що навчають інженерії теоретиками, але мені потрібно запитати, чи роблять вони це в галузі? Як люди з'ясовують, що насправді програма, а не те, що вона має відповідати? Чи багато людей прототипу чи вони в основному використовують формальні інструменти, такі як UML, і я просто ще не отримав їх використання?

Якщо ми будуємо додаток GUI, ми майже ВЖЕ завжди створюємо прототип або POC (доказ концепції). Ми встановимо, якою буде візуальна лексика програми. Зазвичай ми залучаємо нашого клієнта частково через POC і переконуємось, що він розуміє, яка мета і на що слід зосередити увагу. Я ніколи не шкодував, що виготовив прототип. Будьте впевнені, що ви не намагаєтесь перетворити код прототипу у виробничий код, почніть виробничий код з нуля, виходячи з того, що ви дізналися з прототипу.

Сказавши все це, ми майже ніколи не прототипуємо додатки на сервері (сервіси, проміжне програмне забезпечення тощо). Я не бачу рентабельності інвестицій для цього (якщо ви не використовуєте якусь нову технологію і не потрібно доводити різні концепції).

У світі бізнесу це має велике значення

Я теж думаю про це, поки ти не потрапиш у діловий світ. Тоді це вже не досить просто, щоб просто прийняти вимоги та продовжувати та будувати.

У бізнесі, що користувач "обтікає" діаграми та прототипи lo-fi дійсно має сенс.

Те, як діє "програма", ймовірно, є легкою частиною. У додатках LOB (Line Of Business) більшість це лише CRUD. Завдання полягає в бізнес - логіці і правилах . Саме тут діаграми потоків користувачів та потоки бізнес-процесів стають надзвичайно важливими для розуміння та ефективного планування.

Що ви маєте на увазі під тим, як програма "працює"? Ви, здається, шукаєте точні деталі впровадження в чомусь іншому, ніж конкретна остаточна реалізація, що не має сенсу. Елементи вищого рівня повинні керувати реалізацією, а не визначати її.

З мого досвіду, прототипування є дещо рідкісним. Мене, безумовно, навчали разом із специфікаціями, вимогами, архітектурою тощо, і це може бути дуже корисно.

Щодо "яким програмним забезпеченням повинно бути", то це вимоги. Здається, вам не вистачає всієї точки.

Інтерфейси часто накреслюються заздалегідь, і випадки використання можуть бути використані для "потоку" інтерфейсу. Користувальницького досвіду взагалі не бракує. Якщо ви відчуваєте, що якогось елемента не вистачає, то зробіть щось інше, що ваші професори не згадали. Дизайн не складається з чіткого набору правил, переданих з неба.

Моє особисте зауваження полягає в тому, що прототипуванню надається багато послуг, але занадто часто прототип, коли він показує ознаки життя, просто ребрендується як "бета" або, що ще гірше, v1.0.

Існує два види прототипування - три, власне:

1. ми будуємо прототипи для вдосконалення дизайну та зменшення ризиків перед запуском "реального" кодування (Engineering)

2. ми будуємо проект як серію вдосконалених прототипів (Agile)

3. ми будуємо прототип і відправляємо його, як тільки він працює (ковбой)

Те, що ви шукаєте, називається специфікацією - опис цього ви можете прочитати тут, в одній зі статей Джоела

http://www.joelonsoftware.com/articles/fog0000000035.html

Прототипом також можна вважати "ітерацію 0" того, що вам потрібно зробити. Він виконує кілька речей:

• Це доводить, що концепцію можна зробити. Це може бути вашому начальнику або платіжному клієнту.
• Це дозволяє визначити речі, до яких може бути важко дістати виробничу силу, і дати загальне уявлення про необхідну кількість роботи.
• У вас фактично є код, який щось робить . Це надзвичайно важливо!

Загалом, прототип повинен з великою часткою ймовірності бути корисним для побудови кінцевого продукту, якщо тільки ви не виявили, що необхідний зовсім інший підхід.