Создание прототипов программного обеспечения — это деятельность по созданию прототипов программных приложений, т. е. неполных версий разрабатываемой программы . Это деятельность, которая может иметь место при разработке программного обеспечения и сопоставима с созданием прототипов, как известно из других областей, таких как машиностроение или производство . [1]
Прототип обычно имитирует лишь некоторые аспекты конечного продукта и может полностью отличаться от него.
Прототипирование имеет несколько преимуществ: разработчик и реализатор программного обеспечения может получить ценную обратную связь от пользователей на ранних этапах проекта. Клиент и подрядчик могут сравнить, соответствует ли созданное программное обеспечение спецификации программного обеспечения , в соответствии с которой оно создано. Это также позволяет инженеру-программисту получить некоторое представление о точности первоначальных оценок проекта и о том, могут ли быть успешно соблюдены предложенные сроки и этапы . Степень полноты и методы, используемые при прототипировании, находятся в стадии разработки и обсуждения с момента его предложения в начале 1970-х годов. [2]
Цель прототипа — позволить пользователям программного обеспечения оценить предложения разработчиков по дизайну конечного продукта, фактически опробовав их, вместо того, чтобы интерпретировать и оценивать дизайн на основе описаний. Прототипирование программного обеспечения обеспечивает понимание функций программного обеспечения и потенциальных угроз или проблем. [3] Прототипирование также может использоваться конечными пользователями для описания и подтверждения требований, которые не были рассмотрены, и это может быть ключевым фактором в коммерческих отношениях между разработчиками и их клиентами. [4] В частности, проектирование взаимодействия активно использует прототипирование с этой целью.
Этот процесс контрастирует с монолитным циклом разработки 1960-х и 1970-х годов, когда сначала создавалась вся программа, а затем устранялись любые несоответствия между проектированием и реализацией, что приводило к более высоким затратам на программное обеспечение и плохим оценкам времени и стоимости. [ необходима цитата ] Монолитный подход был назван методом «Убийства (программного) дракона», поскольку он предполагает, что проектировщик и разработчик программного обеспечения — это один герой, который должен в одиночку убить всего дракона. Прототипирование также может избежать больших расходов и трудностей, связанных с необходимостью изменения готового программного продукта.
Практика прототипирования — один из моментов, которые Фредерик П. Брукс поднимает в своей книге 1975 года «Мифический человеко-месяц» и в своей статье, посвященной 10-летнему юбилею, « Серебряной пули нет ».
Ранним примером крупномасштабного программного прототипирования была реализация транслятора Ada/ED Нью-Йоркского университета для языка программирования Ada . [5] Он был реализован в SETL с целью создания исполняемой семантической модели для языка Ada, подчеркивая ясность дизайна и пользовательского интерфейса, а не скорость и эффективность. Система Ada/ED Нью-Йоркского университета была первой проверенной реализацией Ada, сертифицированной 11 апреля 1983 года. [6]
Процесс создания прототипа включает в себя следующие этапы: [ необходима ссылка ]
Нильсен суммирует различные аспекты прототипов в своей книге «Инженерия удобства использования» :
Общим термином для прототипа пользовательского интерфейса является горизонтальный прототип . Он обеспечивает широкий обзор всей системы или подсистемы, фокусируясь на взаимодействии с пользователем больше, чем на низкоуровневой функциональности системы, такой как доступ к базе данных. Горизонтальные прототипы полезны для:
Вертикальный прототип — это расширенная полная разработка одной подсистемы или функции. Он полезен для получения подробных требований к заданной функции, со следующими преимуществами:
Прототипирование программного обеспечения имеет много вариантов. Однако все методы в той или иной степени основаны на двух основных формах прототипирования: одноразовое прототипирование и эволюционное прототипирование.
Также называется прототипированием с закрытым концом. Разовое или быстрое прототипирование относится к созданию модели, которая в конечном итоге будет отброшена, а не станет частью окончательного программного обеспечения. После завершения сбора предварительных требований создается простая рабочая модель системы, чтобы наглядно показать пользователям, как могут выглядеть их требования, когда они будут реализованы в готовой системе. Это также форма быстрого прототипирования.
Самая очевидная причина использования одноразового прототипирования заключается в том, что это можно сделать быстро. Если пользователи могут быстро получить обратную связь по своим требованиям, они могут улучшить их на ранних этапах разработки программного обеспечения. Внесение изменений на ранних этапах жизненного цикла разработки чрезвычайно экономически эффективно, поскольку на этом этапе нечего переделывать. Если проект изменяется после того, как был проделан значительный объем работы, то небольшие изменения могут потребовать больших усилий для внедрения, поскольку у систем программного обеспечения много зависимостей. Скорость имеет решающее значение при внедрении одноразового прототипа, поскольку при ограниченном бюджете времени и денег мало что можно потратить на прототип, который будет выброшен.
Еще одной сильной стороной одноразового прототипирования является его способность конструировать интерфейсы, которые пользователи могут тестировать. Пользовательский интерфейс — это то, что пользователь видит как систему, и, увидев его перед собой, гораздо легче понять, как система будет функционировать.
Прототипы можно классифицировать по точности, с которой они напоминают реальный продукт с точки зрения внешнего вида, взаимодействия и времени. Одним из методов создания низкоточного одноразового прототипа является бумажное прототипирование . Прототип реализуется с помощью бумаги и карандаша и, таким образом, имитирует функцию реального продукта, но совсем не выглядит как он. Другой метод легкого создания высокоточных одноразовых прототипов заключается в использовании GUI Builder и создании клик-манекена , прототипа, который выглядит как целевая система, но не предоставляет никакой функциональности.
Использование раскадровок , аниматик или рисунков не совсем то же самое, что и одноразовое прототипирование, но, безусловно, относится к тому же семейству. Это нефункциональные реализации, но они показывают, как будет выглядеть система.
Резюме: В этом подходе прототип создается с мыслью, что он будет отброшен, а окончательная система будет построена с нуля. Шаги в этом подходе следующие:
Эволюционное прототипирование (также известное как макетирование на макетной плате ) существенно отличается от одноразового прототипирования. Основная цель при использовании эволюционного прототипирования — построить очень надежный прототип структурированным образом и постоянно его совершенствовать. Причина такого подхода в том, что эволюционный прототип, когда он построен, формирует сердце новой системы, а затем будут построены улучшения и дальнейшие требования.
При разработке системы с использованием эволюционного прототипирования система постоянно совершенствуется и перестраивается.
Этот метод позволяет команде разработчиков добавлять функции или вносить изменения, которые не могли быть задуманы на этапе разработки требований и проектирования.
Эволюционные прототипы имеют преимущество перед одноразовыми прототипами в том, что они являются функциональными системами. Хотя они могут не иметь всех функций, которые запланировали пользователи, их можно использовать на временной основе до тех пор, пока не будет доставлена окончательная система.
При эволюционном прототипировании разработчики могут сосредоточиться на разработке тех частей системы, которые они понимают, вместо того, чтобы работать над разработкой целой системы.
Конечный продукт создается в виде отдельных прототипов. В конце отдельные прототипы объединяются в общий дизайн. С помощью инкрементального прототипирования сокращается временной разрыв между пользователем и разработчиком программного обеспечения.
Экстремальное прототипирование как процесс разработки используется, в частности, для разработки веб-приложений. По сути, оно разбивает веб-разработку на три фазы, каждая из которых основана на предыдущей. Первая фаза — это статический прототип, состоящий в основном из HTML-страниц. На второй фазе экраны программируются и полностью функциональны с использованием слоя имитированных сервисов. На третьей фазе сервисы реализуются.
Использование прототипирования при разработке программного обеспечения имеет множество преимуществ — некоторые из них ощутимы, некоторые абстрактны. [13]
Сокращение времени и затрат : прототипирование может улучшить качество требований и спецификаций, предоставляемых разработчикам. Поскольку изменения обходятся экспоненциально дороже при внедрении, поскольку они обнаруживаются на поздних этапах разработки, раннее определение того, что действительно нужно пользователю, может привести к более быстрому и менее дорогому программному обеспечению. [8]
Улучшенное и возросшее участие пользователей : прототипирование требует участия пользователей и позволяет им видеть и взаимодействовать с прототипом, что позволяет им предоставлять более качественную и полную обратную связь и спецификации. [7] Наличие прототипа, изучаемого пользователем, предотвращает множество недоразумений и недопониманий, которые возникают, когда каждая сторона считает, что другая понимает то, что они сказали. Поскольку пользователи знают проблемную область лучше, чем кто-либо в команде разработчиков, возросшее взаимодействие может привести к конечному продукту, который имеет более высокое материальное и нематериальное качество. Конечный продукт с большей вероятностью удовлетворит желание пользователя по внешнему виду, ощущениям и производительности.
Использование или, возможно, неправильное использование прототипирования также может иметь недостатки.
Недостаточный анализ : фокус на ограниченном прототипе может отвлечь разработчиков от надлежащего анализа всего проекта. Это может привести к игнорированию лучших решений, подготовке неполных спецификаций или превращению ограниченных прототипов в плохо спроектированные финальные проекты, которые трудно поддерживать . Кроме того, поскольку прототип ограничен по функциональности, он может плохо масштабироваться, если прототип используется в качестве основы для финального результата, что может быть не замечено, если разработчики слишком сосредоточены на создании прототипа как модели.
Путаница пользователей между прототипом и готовой системой : пользователи могут начать думать, что прототип, предназначенный для выбрасывания, на самом деле является окончательной системой, которую просто нужно доделать или отполировать. (Они, например, часто не знают об усилиях, необходимых для добавления функций проверки ошибок и безопасности, которых у прототипа может не быть.) Это может привести к тому, что они будут ожидать, что прототип будет точно моделировать производительность окончательной системы, когда это не является намерением разработчиков. Пользователи также могут привязаться к функциям, которые были включены в прототип для рассмотрения, а затем удалены из спецификации для окончательной системы. Если пользователи могут потребовать, чтобы все предлагаемые функции были включены в окончательную систему, это может привести к конфликту.
Непонимание разработчиком целей пользователя : разработчики могут предполагать, что пользователи разделяют их цели (например, поставлять основную функциональность вовремя и в рамках бюджета), не понимая более широких коммерческих вопросов. Например, представители пользователей, посещающие мероприятия Enterprise Software (например, PeopleSoft ), могли видеть демонстрации «аудита транзакций» (где изменения регистрируются и отображаются в виде сетки различий), не будучи осведомленными о том, что эта функция требует дополнительного кодирования и часто требует большего количества оборудования для обработки дополнительных обращений к базе данных. Пользователи могут полагать, что они могут требовать аудита в каждой области, тогда как разработчики могут думать, что это навязывание функций , поскольку они сделали предположения о степени требований пользователя. Если разработчик обязался поставлять до того, как требования пользователя были рассмотрены, разработчики оказываются между молотом и наковальней, особенно если управление пользователями извлекает некоторую выгоду из их неспособности реализовать требования.
Привязанность разработчика к прототипу: разработчики также могут привязываться к прототипам, на создание которых они потратили много усилий; это может привести к проблемам, таким как попытка преобразовать ограниченный прототип в окончательную систему, когда у него нет подходящей базовой архитектуры. (Это может указывать на то, что следует использовать одноразовое прототипирование, а не эволюционное прототипирование.)
Чрезмерное время разработки прототипа : Ключевым свойством прототипирования является тот факт, что оно должно быть сделано быстро. Если разработчики упускают из виду этот факт, они вполне могут попытаться разработать прототип, который будет слишком сложным. Когда прототип выбрасывается, точно разработанные требования, которые он предоставляет, могут не дать достаточного увеличения производительности, чтобы компенсировать время, потраченное на разработку прототипа. Пользователи могут застрять в дебатах по поводу деталей прототипа, задерживая команду разработчиков и задерживая конечный продукт.
Расходы на внедрение прототипирования : начальные затраты на создание команды разработчиков, ориентированной на прототипирование, могут быть высокими. Во многих компаниях есть методологии разработки, и их изменение может означать переподготовку, переоснащение или и то, и другое. Многие компании склонны просто приступать к прототипированию, не утруждая себя переподготовкой своих сотрудников в той мере, в какой это необходимо.
Утверждалось, что прототипирование, в той или иной форме, должно использоваться все время. Однако прототипирование наиболее полезно в системах, которые будут иметь много взаимодействий с пользователями.
Системы с небольшим взаимодействием с пользователем, такие как пакетная обработка или системы, которые в основном выполняют вычисления, мало выигрывают от прототипирования. Иногда кодирование, необходимое для выполнения функций системы, может быть слишком интенсивным, а потенциальные выгоды, которые может обеспечить прототипирование, слишком малы. [7]
Прототипирование особенно хорошо подходит для проектирования хороших интерфейсов человек-компьютер . «Одним из наиболее продуктивных применений быстрого прототипирования на сегодняшний день является его использование в качестве инструмента для итеративной разработки пользовательских требований и проектирования интерфейсов человек-компьютер». [8]
Метод разработки динамических систем (DSDM) [15] — это структура для предоставления бизнес-решений, которая в значительной степени опирается на прототипирование как на основную технику и сама по себе одобрена ISO 9001. Она расширяет наиболее понятные определения прототипа. Согласно DSDM, прототипом может быть диаграмма, бизнес-процесс или даже система, запущенная в производство. Прототипы DSDM предназначены для инкрементного развития, развиваясь от простых форм к более комплексным.
Прототипы DSDM иногда могут быть одноразовыми или эволюционными . Эволюционные прототипы могут развиваться горизонтально (ширина, затем глубина) или вертикально (каждый раздел строится подробно с дополнительными итерациями, детализирующими последующие разделы). Эволюционные прототипы могут в конечном итоге развиваться в окончательные системы.
DSDM рекомендует четыре категории прототипов:
Жизненный цикл прототипа DSDM включает в себя:
Оперативное прототипирование было предложено Аланом Дэвисом как способ интеграции одноразового и эволюционного прототипирования с разработкой традиционных систем. «Оно предлагает лучшее из обоих миров — быстрого и грязного и традиционного — разумным образом. Проектировщики разрабатывают только хорошо понятые функции при построении эволюционной базовой линии, используя одноразовое прототипирование для экспериментов с плохо понятыми функциями». [9]
Дэвис убежден, что попытка «модернизировать качество на быстром прототипе» не является правильным методом при попытке объединить два подхода. Его идея заключается в том, чтобы заняться эволюционной методологией прототипирования и быстро прототипировать функции системы после каждой эволюции.
Конкретная методология состоит из следующих шагов: [9]
Очевидно, что ключ к этому методу — иметь хорошо обученных прототипировщиков, которые могут выезжать на сайты пользователей. Методология операционного прототипирования имеет много преимуществ в сложных системах, имеющих мало известных заранее требований.
Разработка эволюционных систем — это класс методологий, которые пытаются формально реализовать эволюционное прототипирование. Один конкретный тип, называемый Systemscraft, описан Джоном Кринионом в его книге Разработка эволюционных систем .
Systemscraft был разработан как «прототип» методологии, который необходимо модифицировать и адаптировать в соответствии с конкретной средой, в которой он реализуется.
Основа Systemscraft, как и эволюционное прототипирование, заключается в создании рабочей системы из первоначальных требований и ее доработке в серии ревизий. Systemscraft уделяет большое внимание традиционному анализу, используемому на протяжении всей разработки системы.
Технология Evolutionary Rapid Development (ERD) [16] была разработана Консорциумом по производительности программного обеспечения, агентом по разработке и интеграции технологий Управления информационных технологий Агентства перспективных исследовательских проектов Министерства обороны США (DARPA).
Для получения информации от клиентов/пользователей проводятся частые запланированные и специальные/импровизированные встречи с заинтересованными сторонами. Демонстрации возможностей системы проводятся для получения отзывов до принятия решений по проектированию/внедрению. Частые релизы (например, бета-версии ) предоставляются для использования, чтобы предоставить представление о том, как система может лучше поддерживать потребности пользователей и клиентов. Это гарантирует, что система развивается для удовлетворения существующих потребностей пользователей.
Структура дизайна системы основана на использовании существующих опубликованных или фактических стандартов. Система организована так, чтобы обеспечить возможность развития набора возможностей, включающего соображения по производительности, мощностям и функциональности. Архитектура определяется в терминах абстрактных интерфейсов, которые инкапсулируют сервисы и их реализацию (например, COTS-приложения). Архитектура служит шаблоном, который будет использоваться для руководства разработкой более чем одного экземпляра системы. Она позволяет использовать несколько компонентов приложения для реализации сервисов. Также определяется и устанавливается основной набор функциональности, который вряд ли изменится.
Процесс ERD структурирован для использования продемонстрированной функциональности, а не бумажных продуктов в качестве способа для заинтересованных сторон сообщать о своих потребностях и ожиданиях. Центральным для этой цели быстрой поставки является использование метода « временных рамок ». Временные рамки — это фиксированные периоды времени, в течение которых должны быть выполнены определенные задачи (например, разработка набора функциональных возможностей). Вместо того, чтобы позволить времени расширяться для удовлетворения некоторого неопределенного набора целей, время фиксируется (как в календарных неделях, так и в человеко-часах) и определяется набор целей, которые реалистично могут быть достигнуты в рамках этих ограничений. Чтобы не допустить вырождения разработки в « случайное блуждание », определяются долгосрочные планы для руководства итерациями. Эти планы дают видение всей системы и устанавливают границы (например, ограничения) для проекта. Каждая итерация в рамках процесса проводится в контексте этих долгосрочных планов.
После того, как архитектура установлена, программное обеспечение интегрируется и тестируется ежедневно. Это позволяет команде объективно оценивать прогресс и быстро выявлять потенциальные проблемы. Поскольку небольшие объемы системы интегрируются одновременно, диагностика и устранение дефекта происходят быстро. Демонстрации для пользователей могут проводиться в короткие сроки, поскольку система, как правило, готова к упражнению в любое время.
Эффективное использование прототипирования требует, чтобы организация имела соответствующие инструменты и персонал, обученный использовать эти инструменты. Инструменты, используемые при прототипировании, могут варьироваться от отдельных инструментов, таких как языки программирования 4-го поколения, используемые для быстрого прототипирования, до сложных интегрированных инструментов CASE . Часто используются визуальные языки программирования 4-го поколения , такие как Visual Basic и ColdFusion, поскольку они дешевы, хорошо известны и относительно просты и быстры в использовании. Инструменты CASE, поддерживающие анализ требований, такие как среда разработки требований (см. ниже), часто разрабатываются или выбираются военными или крупными организациями. Также разрабатываются объектно-ориентированные инструменты, такие как LYMB из Центра исследований и разработок GE . Пользователи могут сами прототипировать элементы приложения в электронной таблице .
Поскольку популярность веб-приложений продолжает расти, растут и инструменты для прототипирования таких приложений. Такие фреймворки, как Bootstrap , Foundation и AngularJS, предоставляют инструменты, необходимые для быстрого структурирования доказательства концепции . Эти фреймворки обычно состоят из набора элементов управления, взаимодействий и руководств по проектированию, которые позволяют разработчикам быстро создавать прототипы веб-приложений.
Также широко используются программы генерации экранов, которые позволяют прототипистам показывать пользовательские системы, которые не функционируют, но показывают, как могут выглядеть экраны. Разработка человеко-машинных интерфейсов иногда может быть критической частью усилий по разработке, поскольку для пользователей интерфейс по сути является системой.
Фабрики программного обеспечения могут генерировать код, комбинируя готовые к использованию модульные компоненты. Это делает их идеальными для прототипирования приложений, поскольку этот подход позволяет быстро поставлять программы с желаемым поведением с минимальным количеством ручного кодирования.
Новый класс программного обеспечения, называемого программным обеспечением определения приложений или моделирования, позволяет пользователям быстро создавать легкие, анимированные симуляции другой компьютерной программы без написания кода . Программное обеспечение моделирования приложений позволяет как техническим, так и нетехническим пользователям испытывать, тестировать, сотрудничать и проверять смоделированную программу, а также предоставляет отчеты, такие как аннотации , снимки экрана и схемы . Как метод спецификации решения, моделирование приложений находится между малорискованными, но ограниченными, текстовыми или чертежными макетами (или каркасами ), иногда называемыми прототипированием на бумажной основе , и трудоемкими, высокорискованными прототипами на основе кода , что позволяет специалистам по программному обеспечению проверять требования и выбор дизайна на ранних этапах, до начала разработки. При этом риски и затраты, связанные с внедрением программного обеспечения, могут быть значительно снижены. [17]
Для моделирования приложений можно также использовать программное обеспечение, имитирующее реальные программы для компьютерного обучения , демонстрации и поддержки клиентов, например, программное обеспечение для создания скринкастов , поскольку эти области тесно связаны.
«Среда проектирования требований (REE), разрабатываемая в Римской лаборатории с 1985 года, предоставляет интегрированный набор инструментов для быстрого представления, построения и выполнения моделей критических аспектов сложных систем». [18]
В настоящее время среда разработки требований используется ВВС США для разработки систем. Она:
REE состоит из трех частей. Первая часть, называемая proto, представляет собой инструмент CASE, специально разработанный для поддержки быстрого прототипирования. Вторая часть называется Rapid Interface Prototyping System или RIP и представляет собой набор инструментов, облегчающих создание пользовательских интерфейсов. Третья часть REE представляет собой пользовательский интерфейс для RIP и proto, который является графическим и предназначен для простоты использования.
Rome Laboratory, разработчик REE, намеревался поддержать свою внутреннюю методологию сбора требований. Их метод состоит из трех основных частей:
В 1996 году Rome Labs заключила контракт с Software Productivity Solutions (SPS) на дальнейшее усовершенствование REE с целью создания «REE коммерческого качества, которая поддерживает спецификацию требований, моделирование, прототипирование пользовательского интерфейса, сопоставление требований с аппаратной архитектурой и генерацию кода...» [19] Эта система получила название Advanced Requirements Engineering Workstation (рабочая станция разработки расширенных требований) или AREW.
Нереляционное определение данных (например, с использованием Caché или ассоциативных моделей) может помочь сделать прототипирование конечным пользователем более продуктивным, откладывая или избегая необходимости нормализации данных на каждой итерации моделирования. Это может обеспечить более раннюю/большую ясность бизнес-требований, хотя это не подтверждает конкретно, что требования технически и экономически осуществимы в целевой производственной системе.
PSDL — это язык описания прототипов для описания программного обеспечения реального времени. [20] Сопутствующий набор инструментов — CAPS (Computer Aided Prototyping System). [21] Прототипирование систем программного обеспечения с жесткими требованиями реального времени является сложной задачей, поскольку временные ограничения вводят зависимости от реализации и оборудования. PSDL решает эти проблемы, вводя абстракции управления, которые включают декларативные временные ограничения. CAPS использует эту информацию для автоматической генерации кода и связанных с ним графиков реального времени, мониторинга временных ограничений во время выполнения прототипа и моделирования выполнения в пропорциональном реальном времени относительно набора параметризованных аппаратных моделей. Он также предоставляет предположения по умолчанию, которые позволяют выполнять неполные описания прототипов, интегрирует создание прототипа с репозиторием повторного использования программного обеспечения для быстрой реализации эффективных реализаций и обеспечивает поддержку быстрой эволюции требований и проектов. [22]