Прототипирование программного обеспечения

Основная цель прототипа — предоставить пользователям возможность непосредственно оценить предлагаемые проектировочные решения, а не судить о них по описаниям. Прототипирование содействует пониманию функций программного продукта и помогает выявить потенциальные угрозы или проблемы^[2]. Конечные пользователи могут формировать и уточнять требования, что часто является ключевым фактором во взаимоотношениях между заказчиком и исполнителем^[3]. Особенно широко прототипирование применяется в проектировании взаимодействия (interaction design).

Этот подход контрастирует с распространённым в 1960-х—1970-х годах монолитным циклом, при котором создавалась целая программа, после чего выявлялись несоответствия между проектом и реализацией, что зачастую приводило к удорожанию разработки и неточным оценкам времени и стоимости. Такой метод иногда называют «Убийство (программного) дракона»: предполагается, что дизайнер и разработчик одни разрабатывают весь продукт. Прототипирование позволяет избежать затрат и трудностей, связанных с доработкой завершённого ПО.

Использование прототипирования обсуждается Фредериком Бруксом (Frederick P. Brooks) в его книге «The Mythical Man-Month» (1975) и юбилейной статье «Нет серебряной пули».

Ранним примером масштабного использования прототипирования стало создание переводчика Ada/ED в Нью-Йоркском университете (NYU) для языка Ada^[4]. Система, реализованная на языке SETL, была ориентирована на создание исполняемой семантической модели языка, акцентируя внимание на ясности дизайна и пользовательском интерфейсе. NYU Ada/ED стала первым сертифицированным реализацией Ada (11 апреля 1983 года)^[5].

Процесс прототипирования обычно включает следующие этапы:

1. Определение базовых требований

   Определяются основные требования, включая необходимые входные и выходные данные. Детали (например, аспекты безопасности) на этом этапе обычно опускаются.

2. Разработка начального прототипа

   Разрабатывается начальная версия, как правило, охватывающая только пользовательский интерфейс (см. Горизонтальный прототип).

3. Ознакомление и анализ

   Заказчики и конечные пользователи тестируют вариант прототипа и дают свои замечания и предложения.

4. Переработка и совершенствование прототипа

   На основе обратной связи уточняются как техническое задание, так и сам прототип. Проводится согласование относительно объёма продукта. При необходимости цикл повторяется.

Нильсен в книге «Usability Engineering» выделяет ряд аспектов прототипирования:

Горизонтальным прототипом называют прототип пользовательского интерфейса, обеспечивающий широкий обзор системы или подсистемы с акцентом на взаимодействие пользователя и лишь косвенным учётом низкоуровневых функций (например, доступа к БД). Такой прототип полезен для:

• Подтверждения требований к UI и охвата системы;
• Демонстрации продукта для получения поддержки бизнеса;
• Предварительных оценок затрат, сроков и трудоёмкости.

Вертикальный прототип — это подробная проработка одного подсистемы или функции. Данный вид прототипа даёт:

• Уточнение структуры БД;
• Данные о масштабе и интерфейсах компонентов, необходимых для планирования сети и производительности;
• Прояснение сложных требований через концентрацию на реальной функциональности.

Прототипирование программного обеспечения встречается в различных вариантах, однако все они восходят к двум главным подходам: одноразовое (выбрасываемое) прототипирование и эволюционное прототипирование.

Также называется ограниченным прототипированием. Предполагает создание модели, которая впоследствии отбрасывается, не становясь частью финального продукта. После первичного сбора требований разрабатывается простая рабочая модель, чтобы наглядно продемонстрировать их реализацию пользователям. Этот подход также относят к быстрой разработке прототипов.

Быстрое прототипирование подразумевает быстрое создание рабочего макета отдельных участков системы почти сразу после экспресс-анализа требований. Главной целью здесь является скорость получения результата. Макет служит отправной точкой для уточнения ожиданий и требований. Когда цель достигнута, прототип удаляется, и ведётся формальная реализация системы по уточнённым требованиям^[6].

Основное преимущество данного подхода — его быстрота. Быстрая обратная связь даёт возможность оперативно скорректировать требования. Внесение изменений на ранней стадии обходится значительно дешевле, чем на поздних этапах, когда даже незначительные корректировки требуют больших затрат из-за множества зависимостей. Поэтому критически важна скорость — на прототип, который будет впоследствии удалён, не тратят много ресурсов.

Ещё одним достоинством является возможность визуализации пользовательского интерфейса, что помогает понять, каким будет использование системы.

…считается, что революционное быстрое прототипирование наиболее эффективно для работы с требованиями пользователей и существенно повышает общую производительность разработки ПО. Требования могут быть выявлены, смоделированы и протестированы значительно быстрее и дешевле, если на данном этапе вопросы развития, поддержки и структуры ПО не учитываются. Это позволяет точно зафиксировать требования и впоследствии создать удобную систему для пользователя на базе традиционных моделей разработки^[7].

Прототипы подразделяют по степени их соответствия внешнему виду и поведению целевого продукта. Для низкоуровнего быстрого прототипа часто используют бумажное моделирование (paper prototyping) — интерфейс создаётся вручную на бумаге. Для высокоточного прототипирования — инструменты визуального проектирования GUI и создание «кликабельных макетов», имитирующих внешний вид, но не обладающих реальной функциональностью.

Использование сторибордов, аниматиков и эскизов формально не является прототипированием, но также относится к этой группе существенно визуальных предварительных методов.

Итоговая схема метода: создаётся прототип "на выброс" с целью уточнения требований, после чего финальная система создаётся с нуля. Этапы таковы:

1. Составление предварительных требований
2. Проектирование прототипа
3. Тестирование прототипа пользователем, формулировка новых требований
4. Повторение этапа (по необходимости)
5. Фиксация финальных требований

Эволюционное прототипирование (также прототипирование на макетах) существенно отличается от выбрасываемого: здесь задача — создать рабочий прототип в структурированном виде, который впоследствии дорабатывается до финальной системы.

В данной парадигме система разрабатывается и совершенствуется итеративно:

«…эволюционное прототипирование признаёт невозможность полного понимания всех требований заблаговременно и реализует только те функции, которые уже хорошо прояснены»^[8].

Это позволяет по мере эксплуатации добавлять функции и модифицировать систему в ответ на новые запросы.

«Для того чтобы система была полезной, она должна развиваться в своей целевой среде. Продукт никогда не "завершён"; его развитие продолжается по мере изменений окружающей среды и пользовательских потребностей…»^[9]

Преимущество эволюционного прототипирования — наличие рабочей системы ещё до появления всех необходимых функций. На практике пользователь может начать эксплуатацию такой системы в ожидании разработки более полной версии.

«Нередко в условиях прототипирования пользователь начинает реально применять прототип в ожидании последующих доработок… „несовершенная“ система может быть лучше отсутствия системы вообще»^[6].

Данный подход позволяет сосредоточиться на проработанных частях, не тратя ресурсы на непрояснённые функции. Частичная система передаётся пользователям, которые генерируют новые пожелания — они фиксируются и реализуются в дальнейших итерациях наряду с предложениями разработчиков, при строгом управлении изменениями^[10].

Финальная система собирается из отдельных прототипов, которые затем интегрируются в единую архитектуру. Такой подход позволяет сократить разрыв во взаимодействии между пользователями и разработчиками.

Применяется, в основном, для веб-приложений и состоит из трёх фаз: статический HTML-прототип, проработка UI с эмуляцией сервисного слоя и, наконец, реализация всех сервисов.

«Процесс назван экстремальным прототипированием, поскольку акцент делается на создании полноценного пользовательского интерфейса ещё до реализации бизнес-логики»^[11].

Применение прототипирования даёт множество преимуществ, как практически измеримых, так и косвенных^[12].

Сокращение сроков и затрат: Улучшение качества и полноты требований приводит к уменьшению стоимости изменений на поздних этапах и позволяет быстрее и дешевле реализовать рабочую систему^[7].

Повышение вовлечённости пользователей: При прототипировании пользователи активно участвуют в процессе, взаимодействуя с макетами, что способствует формулировке точных и полных требований^[6]. Наличие прототипа наглядно снижает число взаимных недопониманий. В итоге финальная система лучше отвечает ожиданиям пользователей.

С неоправданным или некорректным использованием прототипирования связаны и возможные недостатки.

Недостаточный анализ: Фокусировка на прототипе может отвлечь команду от анализа всей системы, что приведёт к пропуску лучших вариантов или созданию неполных спецификаций. Если прототип станет базой продукта — возможно появление трудностей с масштабируемостью и сопровождением.

Путаница между прототипом и финальной системой у пользователей: Пользователи могут принять прототип за готовую систему, не понимая, что доработка (например, внедрение безопасности, обработка ошибок) требует больших усилий. Это может вызвать завышенные ожидания и конфликты из-за удаления временных функций.

Недопонимание целей между разработчиками и пользователями: Разработчики могут ошибочно полагать, что пользователи разделяют их приоритеты (например, соблюдение сроков и бюджета), в то время как для бизнеса важны другие аспекты, такие как полнота функций или производительность. Это может приводить к неконтролируемому росту требований (feature creep).

Привязанность разработчиков к прототипу: Потратив значительные силы на прототип, разработчики могут попытаться превратить его в финальную систему без должной архитектуры, что проблематично (предпочтительнее чёткий переход к эволюционному прототипированию).

Чрезмерное время разработки прототипа: Если забыть о приоритетности скорости, создание прототипа может затянуться, и сумма полученных преимуществ будет недостаточна для компенсации затрат. Пользователи могут застрять в обсуждениях деталей.

Стоимость внедрения прототипирования: Формирование команды с нужной экспертизой и инструментами требует затрат; внедрение новых методов сопряжено с необходимостью дополнительного обучения и перестройки процессов, что ведёт к временным потерям продуктивности^[13].

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

Особенно эффективна методология при анализе и проектировании интерактивных систем — например, систем с обработкой транзакций, где большое значение имеют экранные диалоги. Чем выше степень диалога с пользователем, тем больше выигрыш от быстрого построения макета^[6].

Если система предполагает минимум взаимодействий с пользователем (например, batch processing), то прототипирование малоэффективно^[6].

Наиболее перспективно прототипирование себя проявило в дизайне интерфейсов человек — компьютер. «Наиболее продуктивное применение быстрого прототипирования — это итерационное проектирование пользовательских требований и интерфейсов.»^[7].

DSDM — это система гибкой разработки бизнес-решений, в основе которой лежит прототипирование и которая сертифицирована по ISO 9001. Прототип в DSDM может быть диаграммой, бизнес-процессом или даже опытной производственной системой. Прототипы в DSDM строятся пошагово — от простых к более сложным, могут быть как выбрасываемыми, так и эволюционными (по горизонтали или вертикали). В итоге эволюционный прототип может перерасти в рабочую систему.

DSDM выделяет четыре типа прототипов:

• Бизнес-прототипы — моделируют автоматизируемые бизнес-процессы;
• Прототипы удобства/юзабилити — проработка пользовательского интерфейса, визуализации и доступности;
• Прототипы производительности и ёмкости — для моделирования и тестирования производительности системы и других нефункциональных аспектов;
• Прототипы технических возможностей — для проверки и демонстрации новых решений.

Жизненный цикл прототипа в DSDM:

1. Идентификация прототипа
2. Согласование плана
3. Создание прототипа
4. Анализ и обсуждение

Операционное прототипирование (Alan Davis) интегрирует одноразовое и эволюционное прототипирование с формальной системой разработки: «Это сочетание гибкости и формальных методов, при котором эволюционный прототип служит базисом, а выбрасываемые прототипы позволяют экспериментировать с новыми и неясными функциями»^[8].

Суть метода:

• Создаётся эволюционный прототип только по понятным требованиям (базис).
• Базисные прототипы распространяются между заказчиками, где прототипер наблюдает за работой пользователя.
• Любое новое пожелание или замечание прототипер фиксирует.
• После сеанса создаётся выбрасываемый (throwaway) прототип над базисом.
• Пользователь тестирует; если изменения неудачны — их удаляют.
• Если изменения понравились — они оформляются как официальный запрос и передаются команде, и цикл повторяется.

Метод требует хорошей подготовки прототиперов и оправдывает себя в сложных системах с неясными требованиями.

Evolutionary Systems Development — класс методологий официального оформления эволюционного прототипирования. Одна из методик — Systemscraft, описанная Дж. Криннионом. Systemscraft — «методология-прототип», которую адаптируют к целевой среде.

«Systemscraft не жёсткий рецепт, а гибкий инструмент, подходящий под широкое множество ситуаций…»^[6]

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

Evolutionary Rapid Development (ERD)^[14] — концепция, разработанная консорциумом Software Productivity Consortium для агентства DARPA. Её суть в поэтапном построении систем на основе повторного использования компонентов, шаблонов и архитектурных решений, малыми командами с постоянным взаимодействием с заказчиками.

Основные черты процесса ERD:

• параллельный анализ и разработка разных компонентов;
• интенсивное внедрение новых технологий;
• частые встречи и демонстрации для оперативной корректировки требований;
• частые промежуточные релизы (в т.ч. беты);
• архитектура строится на опубликованных или де-факто стандартах;
• реализуется основа с возможностями расширения, с регулярной интеграцией компонентов.

Особенностью ERD является использование промежуточных рабочих систем — не моделей или документов, а демонстрируемого ПО. Ключевой метод — жёсткое ограничение временем (timeboxing): задачи выполняются в заранее определённые сроки, что предотвращает разрастание требований и нецелесообразное затягивание проекта. После установления архитектуры программное обеспечение интегрируется и тестируется каждый день, что даёт своевременное обнаружение дефектов; система всегда находится в демонстрируемом состоянии.

Эффективное использование прототипирования требует соответствующих инструментов и квалифицированного персонала. Среди инструментов отмечают отдельные средства, такие как языки 4-го поколения (например, Visual Basic, ColdFusion), которые просты в освоении и позволяют быстро создавать рабочие макеты, а также интегрированные CASE-средства для поддержки анализа требований (например, Requirements Engineering Environment для военного применения). Появляются и объектно-ориентированные системы, такие как LYMB от GE. Для простейших прототипов пользователи часто используют электронные таблицы.

С развитием веб-технологий активно используются фреймворки типа Bootstrap, Foundation, AngularJS, которые предоставляют средства для быстрой сборки макетов с проработанными контролами и стилем.

Screen generators позволяют показать пользователю макеты интерфейсов еще до создания реального функционала, что важно при проектировании HCI. Software factories совмещают готовые модули, что облегчает быстрое построение нужных функций.

Класс программ под названием средства моделирования или симуляции приложений позволяет техническим и нетехническим пользователям быстро создавать анимированные имитации программ без программирования. Это обеспечивает тестирование, совместную работу и валидацию, а также формирование отчётов (аннотации, скриншоты, схемы). Такой инструмент занимает промежуточную нишу между простейшими макетами (wireframes) и полноценными прототипами на коде, позволяя заранее подтвердить требования и архитектурные решения и тем самым снизить риски и затраты^[15].

Для этих целей используются и программы для демонстраций и обучения (screencasting software).

«Requirements Engineering Environment (REE), разрабатываемая с 1985 года в Rome Laboratory, предоставляет набор инструментов для быстрого моделирования ключевых аспектов сложных систем»^[16]. REE используется ВВС США для разработки сложных систем и состоит из трёх частей: CASE-инструмента για rapid прототипирования (proto), набора инструментов создания UI (RIP) и графического интерфейса пользователя к обоим компонентам.

Особенности методики Rome Laboratory:

• сбор требований из разных источников, спецификация и проверка согласованности;
• анализ на предмет противоречий и технической реализуемости;
• валидация — сравнение требований с реальными потребностями пользователя^[16].

В 1996 году REE дорабатывалась фирмой Software Productivity Solutions до коммерчески зрелой версии AREW, получившей средства симуляции, прототипирования, генерации кода и трассировки требований^[17].

Использование нереляционных моделей данных (например, Caché или ассоциативные структуры) при прототипировании позволяет быстрее экспериментировать с требованиями и макетами, отсрочив нормализацию данных и повысив прозрачность бизнес-смыслов — хотя это не гарантирует реализуемость требований в целевом окружении.

PSDL — язык описания прототипов для построения real-time программ. Ассоциированный пакет — CAPS (Computer Aided Prototyping System). Прототипирование систем с жёсткими требованиями по времени сопряжено с специфическими трудностями; PSDL вводит дополнительные абстракции для управления временными ограничениями, а CAPS использует эту информацию для автоматической генерации кода и расписаний, эмуляции выполнения в реальном времени и оптимизации неокончательных прототипов.