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

Другие варианты использования см. в разделе Программирование на основе прототипов .

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

Прототип обычно имитирует лишь несколько аспектов конечного продукта и может полностью отличаться от него.

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

Обзор

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

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

Практика прототипирования — один из моментов, которые Фредерик П. Брукс делает в своей книге 1975 года «Мифический человеко-месяц» и в статье « Нет серебряной пули », посвященной 10-летнему юбилею компании.

Ранним примером крупномасштабного прототипирования программного обеспечения была реализация переводчика Ada/ED Нью-Йоркского университета для языка программирования Ada . Он был реализован в SETL с целью создания исполняемой семантической модели для языка Ada, в которой ясность дизайна и пользовательского интерфейса важнее скорости и эффективности. Система Ada/ED Нью-Йоркского университета была первой проверенной реализацией Ada, сертифицированной 11 апреля 1983 года.

Контур

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

1. Определить основные требования

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

2. Разработать первоначальный прототип

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

3. Обзор

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

4. Пересмотреть и улучшить прототип

   Используя обратную связь, можно улучшить как спецификации, так и прототип. Могут потребоваться переговоры о том, что входит в объем контракта/продукта. Если внесены изменения, может потребоваться повторение шагов №3 и №4.

Размеры

Нильсен резюмирует различные аспекты прототипов в своей книге «Инженерия юзабилити» :

Горизонтальный прототип

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

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

Вертикальный прототип

— Вертикальный прототип это расширенная полная разработка одной подсистемы или функции. Это полезно для получения подробных требований к заданной функции и имеет следующие преимущества:

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

Типы

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

Одноразовое прототипирование

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

Быстрое прототипирование предполагает создание рабочей модели различных частей системы на самом раннем этапе, после относительно короткого исследования. Метод, используемый при ее построении, обычно весьма неформальный, причем наиболее важным фактором является скорость, с которой предоставляется модель. Затем модель становится отправной точкой, благодаря которой пользователи могут пересмотреть свои ожидания и уточнить свои требования. Когда эта цель достигнута, модель-прототип «выбрасывается», а система формально разрабатывается на основе выявленных требований.

Самая очевидная причина использования одноразового прототипирования заключается в том, что его можно сделать быстро. Если пользователи смогут быстро получить обратную связь по своим требованиям, они смогут уточнить их на ранних этапах разработки программного обеспечения. Внесение изменений на ранних этапах жизненного цикла разработки чрезвычайно экономически эффективно, поскольку на этом этапе переделывать нечего. Если проект изменяется после того, как был проделан значительный объем работы, то небольшие изменения могут потребовать больших усилий для реализации, поскольку программные системы имеют множество зависимостей. Скорость имеет решающее значение при реализации одноразового прототипа, поскольку при ограниченном бюджете времени и денег мало что можно потратить на прототип, который будет выброшен.

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

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

Прототипы можно классифицировать по степени точности, с которой они напоминают реальный продукт с точки зрения внешнего вида, взаимодействия и времени. Одним из методов создания одноразового прототипа низкой точности является прототипирование на бумаге . Прототип реализован с использованием бумаги и карандаша и, таким образом, имитирует функции реального продукта, но совсем не похож на него. Другой метод легкого создания высокоточных одноразовых прототипов — использовать GUI Builder и создать манекен клика — прототип, который выглядит как система целей, но не обеспечивает никакой функциональности.

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

Резюме: При таком подходе прототип создается с учетом того, что он будет отброшен, а окончательная система будет построена с нуля. Шаги этого подхода следующие:

1. Напишите предварительные требования
2. Создайте прототип
3. Пользовательский опыт/использует прототип, задает новые требования
4. При необходимости повторите
5. Напишите окончательные требования

Эволюционное прототипирование

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

При разработке системы с использованием эволюционного прототипирования система постоянно совершенствуется и перестраивается.

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

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

Чтобы система была полезной, она должна развиваться посредством использования в предполагаемой операционной среде. Продукт никогда не «готов»; она постоянно совершенствуется по мере изменения среды использования… мы часто пытаемся определить систему, используя наиболее знакомую нам систему координат — ту, где мы находимся сейчас. Мы делаем предположения о том, как будет вестись бизнес, и о технологической базе, на которой этот бизнес будет реализован. Принимается план развития потенциала, и рано или поздно нечто, напоминающее предполагаемую систему, будет реализовано.

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

«В среде создания прототипов нет ничего необычного в том, что пользователь применяет первоначальный прототип для практического использования, ожидая более развитой версии… Пользователь может решить, что «испорченная» система лучше, чем отсутствие системы вообще».

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

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

Инкрементное прототипирование

Конечный продукт создается в виде отдельных прототипов. В конце отдельные прототипы объединяются в общий дизайн. С помощью инкрементального прототипирования сокращается разрыв во времени между пользователем и разработчиком программного обеспечения.

Экстремальное прототипирование

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

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

Преимущества

Использование прототипирования при разработке программного обеспечения имеет множество преимуществ – некоторые материальные, некоторые абстрактные.

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

Улучшенное и расширенное участие пользователей . Создание прототипов требует участия пользователей и позволяет им видеть прототип и взаимодействовать с ним, что позволяет им предоставлять более качественные и полные отзывы и спецификации. Наличие прототипа, изучаемого пользователем, предотвращает многие недопонимания и недопонимания, которые возникают, когда каждая сторона считает, что другая понимает то, что они сказали. Поскольку пользователи знают проблемную область лучше, чем кто-либо из команды разработчиков, более активное взаимодействие может привести к тому, что конечный продукт будет иметь более высокое материальное и нематериальное качество. Конечный продукт с большей вероятностью удовлетворит пожелания пользователя по внешнему виду, ощущениям и производительности.

Недостатки

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

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

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

Непонимание разработчиками целей пользователей . Разработчики могут предполагать, что пользователи разделяют их цели (например, предоставить основные функции вовремя и в рамках бюджета), не понимая более широких коммерческих проблем. Например, представители пользователей, посещающие мероприятия по корпоративному программному обеспечению (например, PeopleSoft ), возможно, видели демонстрации «аудита транзакций» (когда изменения регистрируются и отображаются в виде таблицы различий), но им не сообщали, что эта функция требует дополнительного кодирования и часто требует большего количества оборудования для работы. обрабатывать дополнительные обращения к базе данных. Пользователи могут полагать, что они могут требовать аудита в каждом поле, тогда как разработчики могут подумать, что это полнейшая функциональность , поскольку они сделали предположения о степени требований пользователей. Если разработчик взял на себя обязательства по доставке до того, как были рассмотрены требования пользователей, разработчики оказываются между молотом и наковальней, особенно если управление пользователями получает некоторую выгоду от своей неспособности реализовать требования.

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

Чрезмерное время разработки прототипа . Ключевым свойством прототипирования является тот факт, что оно должно выполняться быстро. Если разработчики упустят этот факт из виду, они вполне могут попытаться разработать слишком сложный прототип. Когда прототип выбрасывается, точно разработанные требования, которые он обеспечивает, могут не дать достаточного увеличения производительности, чтобы компенсировать время, затраченное на разработку прототипа. Пользователи могут застрять в дебатах по поводу деталей прототипа, задерживая работу команды разработчиков и задерживая выпуск конечного продукта.

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

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

Применимость

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

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

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

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

Метод разработки динамических систем

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

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

Четыре категории прототипов, рекомендованные DSDM:

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

Жизненный цикл DSDM прототипа заключается в следующем:

1. Определить прототип
2. Согласитесь с планом
3. Создайте прототип
4. Обзор прототипа

Оперативное прототипирование

Оперативное прототипирование было предложено Аланом Дэвисом как способ интеграции одноразового и эволюционного прототипирования с разработкой традиционных систем. «Он разумно предлагает лучшее из мира быстрой и грязной разработки и традиционной разработки. Дизайнеры разрабатывают только хорошо понятные функции при построении эволюционной основы, одновременно используя одноразовое прототипирование для экспериментов с плохо понятными функциями».

Дэвис убежден, что попытка «улучшить качество быстрого прототипа» — неправильный метод при попытке объединить два подхода. Его идея состоит в том, чтобы использовать методологию эволюционного прототипирования и быстро создавать прототипы функций системы после каждой эволюции.

Конкретная методология состоит из следующих шагов:

• Эволюционный прототип создается и превращается в базовую версию с использованием традиционных стратегий разработки, определяющих и реализующих только хорошо понятные требования.
• Копии базового плана отправляются на несколько объектов заказчика вместе с обученным прототипировщиком.
• На каждом сайте прототипировщик наблюдает за пользователем в системе.
• Всякий раз, когда пользователь сталкивается с проблемой или думает о новой функции или требовании, разработчик прототипа записывает это. Это освобождает пользователя от необходимости фиксировать проблему и позволяет ему продолжить работу.
• После завершения сеанса пользователя создатель прототипов создает одноразовый прототип поверх базовой системы.
• Теперь пользователь использует новую систему и оценивает ее. Если новые изменения неэффективны, разработчик прототипа удаляет их.
• Если пользователю нравятся изменения, создатель прототипа пишет запросы на улучшение функций и отправляет их команде разработчиков.
• Команда разработчиков, получив запросы на изменения со всех сайтов, затем создает новый эволюционный прототип, используя традиционные методы.

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

Развитие эволюционных систем

Разработка эволюционных систем — это класс методологий, которые пытаются формально реализовать эволюционное прототипирование. Один конкретный тип, названный Systemscraft , описан Джоном Криннионом в его книге «Развитие эволюционных систем» .

Systemscraft был разработан как «прототип» методологии, который должен быть изменен и адаптирован в соответствии с конкретной средой, в которой он был реализован.

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

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

Эволюционное быстрое развитие

Эволюционное быстрое развитие (ERD) был разработан Консорциумом по продуктивности программного обеспечения, агентом по разработке и интеграции технологий Управления информационных технологий Агентства перспективных оборонных исследовательских проектов (DARPA).

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

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

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

Основа проектирования системы основана на использовании существующих опубликованных или фактических стандартов. Система организована таким образом, чтобы обеспечить возможность развития набора возможностей, включающих соображения производительности, емкости и функциональности. Архитектура определяется в терминах абстрактных интерфейсов, которые инкапсулируют службы и их реализацию (например, COTS-приложения). Архитектура служит шаблоном, который можно использовать для разработки более чем одного экземпляра системы. Это позволяет использовать несколько компонентов приложения для реализации сервисов. Также определяется и устанавливается основной набор функциональных возможностей, которые вряд ли изменятся.

Процесс ERD построен таким образом, чтобы использовать продемонстрированную функциональность, а не бумажные продукты, как способ сообщить заинтересованным сторонам о своих потребностях и ожиданиях. Центральным элементом этой цели быстрой доставки является использование метода « таймбокса ». Временные рамки — это фиксированные периоды времени, в течение которых должны быть выполнены конкретные задачи (например, разработка набора функций). Вместо того, чтобы позволять времени расширяться для достижения какого-то расплывчатого набора целей, время фиксируется (как в терминах календарных недель, так и в человеко-часах), и определяется набор целей, которые реально могут быть достигнуты в рамках этих ограничений. Чтобы не допустить вырождения разработки в « случайное блуждание », определяются долгосрочные планы, определяющие итерации. Эти планы обеспечивают видение всей системы и устанавливают границы (например, ограничения) проекта. Каждая итерация процесса проводится в контексте этих долгосрочных планов.

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

Инструменты

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

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

Генераторы экранов, инструменты проектирования и фабрики программного обеспечения

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

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

Программное обеспечение для определения приложения или моделирования

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

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

Требования к инженерной среде

«Среда разработки требований (REE), разрабатываемая в Римской лаборатории с 1985 года, предоставляет интегрированный набор инструментов для быстрого представления, построения и выполнения моделей критических аспектов сложных систем».

Среда разработки требований в настоящее время используется ВВС США для разработки систем. Это:

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

REE состоит из трех частей. Первый, называемый proto, представляет собой инструмент CASE, специально разработанный для поддержки быстрого прототипирования. Вторая часть называется системой быстрого прототипирования интерфейсов или RIP и представляет собой набор инструментов, облегчающих создание пользовательских интерфейсов. Третья часть REE — это графический пользовательский интерфейс для RIP и прототипа, предназначенный для простоты использования.

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

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

В 1996 году Rome Labs заключила контракт с Software Productivity Solutions (SPS) на дальнейшее совершенствование REE с целью создания «REE коммерческого качества, которое поддерживает спецификацию требований, моделирование, прототипирование пользовательского интерфейса, сопоставление требований с аппаратными архитектурами и генерацию кода...». Эта система называется рабочей станцией разработки расширенных требований или AREW.

Нереляционные среды

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

PSDL

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