1.1 Проблемная область
Действительно трудная сторона разработки программного обеспечения - формализовать проблему, которую собираешься решить.
На языке progstone картостроители - те, кто выполняет формализацию.
Существуют виды человеческой деятельности, которые чрезвычайно сложно формализовать. Любимый пример - автопилот для внедорожного автомобиля (или танка? - С.К.): даже
не шибко умный человек обычно в состоянии выбрать подходящий маршрут движения вне дороги, чтобы не врезаться, в то же время самые умные на Земле инженеры-программисты тратят годы на то, чтобы только приблизиться к созданию программы, делающей то же самое.
Во многих случаях нет надежды,
что инженер-программист будет когда-либо способен понять проблемы заказчика (пользователя) достаточно хорошо, чтобы выполнить формализацию самостоятельно.
Во всех случаях заказчик (пользователь) не полностью понимает, что он хочет.
Во всех случаях
пользователь не способен адекватно выразить свое понимание в виде спецификации, достаточной для успешного проектирования.
Другими словами, очень трудно заниматься картостроением за пределами непосредственно технической области.
Итак, проблема в том, как расколоть трудное, не поддающееся построению карты приложение ?
1.2. Процесс автоформализации знания
Общая идея в том, что единственный способ решить ее - создать среду, где продвинутый пользователь может выразить себя через программирование. Черт сидит в деталях (There devil is in the details).
1.2.1 Пользователь-пилот (Pilot User)
Обычно можно найти "пользователя-пилота":
пользователя с продвинутым знанием в предметной области, который также имеет некоторый опыт программирования (например, в пределах институтского курса) или способный усвоить азы программирования.
1.2.2
инженер поддержки (Support Engineer)
Инженер поддержки создает и поддерживает среду для пользователя-пилота. Очевидно, что мы не можем ожидать многого от пользователя-пилота, кроме способности организовывать готовые вызовы функций в программу. Ключевой элемент в том, что он не обязан делать ничего за пределами этой очень ограниченной области. Всю трудную работу делает инженер поддержки.
1.2.3 Процесс
Инженер поддержки оценивает начальные потребности пользователя-пилота (например, интерфейс к аппаратуре, с которой придется начинать, какие функции ему придется вызывать и т.д.).
Например, в моем собственном опыте, я начал с простой программы с меню, позволяющей пользователю-пилоту выполнять элементарные функции управления оборудованием посредством набора меню, а пользователь-пилот модифицировал ее шаг за шагом до полнофункционального прототипа.
(*)
Пользователь-пилот начал играть с этими вещами. Каждый раз, когда он сталкивался с программной/аппаратной проблемой, то решать ее было ответственностью инженера поддержки: добавлять новые компоненты, улучшать производительность, обсуждать результаты и т.д. После этого шел следующий цикл работы пользователя-пилота и т.д.
Другими словами, пользователь-пилот разбивает проблему на части. Некоторые из них он решает самостоятельно, некоторые передаются инженеру поддержки. Ключевой момент в том, что инженер поддержки не обязан понимать всю проблему, а пользователь-пилот не обязан хорошо программировать.
В конце получится (грубый и медленный, но работающий) прототип разрабатываемой вещи, который можно использовать как основу для формальной спецификации и затем команда паковщиков с ней разберется.
More abstracts about the Автоформализация знания