WikiDer > Создание прототипов программного обеспечения

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

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

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

Обзор

Цель прототипа - позволить пользователям программного обеспечения оценивать предложения разработчиков по дизайну конечного продукта, фактически опробовав их, вместо того, чтобы интерпретировать и оценивать дизайн на основе описаний. Создание прототипов программного обеспечения позволяет понять функции программного обеспечения и потенциальные угрозы или проблемы.^[1] Конечные пользователи могут также использовать прототипирование для описания и подтверждения требований, которые не были учтены, и это может быть ключевым фактором в коммерческих отношениях между разработчиками и их клиентами.^[2] Интерактивный дизайн в частности, для этой цели активно используется прототипирование.

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

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

Ранним примером крупномасштабного прототипирования программного обеспечения была реализация переводчика Ada / ED в NYU для Язык программирования Ада.^[3] Это было реализовано в SETL с целью создания исполняемой семантической модели для языка Ada, делая упор на ясность дизайна и пользовательского интерфейса выше скорости и эффективности. Система NYU Ada / ED была первой проверенной реализацией Ada, сертифицированной 11 апреля 1983 года.^[4]

Схема процесса прототипирования

Процесс прототипирования включает следующие этапы^{[нужна цитата]}

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

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

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

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

3. Рассмотрение

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

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

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

Размеры прототипов

Nielsen резюмирует различные размеры прототипов в своей книге Юзабилити-инженерия:

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

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

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

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

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

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

Виды прототипирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества прототипирования

Использование прототипов при разработке программного обеспечения дает множество преимуществ - некоторые материальные, некоторые абстрактные.^[11]

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

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

Недостатки прототипирования

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

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

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

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

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

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

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

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

Лучшие проекты для использования прототипирования

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

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

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

Прототипирование особенно полезно для создания хороших человеко-машинный интерфейс. «Одно из наиболее эффективных применений быстрого прототипирования на сегодняшний день - это инструмент для итеративного проектирования пользовательских требований и проектирования человеко-машинного интерфейса».^[8]

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

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

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

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

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

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

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

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

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

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

Конкретная методология включает следующие шаги: ^[5]

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

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

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

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

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

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

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

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

Эволюционное быстрое развитие (ERD)^[12] был разработан Software Productivity Consortium, агентом по разработке и интеграции технологий для Управления информационных технологий Агентство перспективных оборонных исследовательских проектов (DARPA).

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

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

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

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

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

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

Инструменты

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

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

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

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

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

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

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

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

Требования к среде разработки

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

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

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

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

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

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

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

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

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

PSDL

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

Примечания

1. ^ К. Мелисса Макклендон, Ларри Регот, Джерри Акерс: Анализ и создание прототипов эффективных графических пользовательских интерфейсов. Октябрь 1996 г. [1]
2. ^ Д.А. Стейси, профессор Университета Гвельфов. Гуэлф, Онтарио. Конспект лекций по быстрому прототипированию. Август 1997 г. [2]
3. ^ Стивен Дж. Андриоле: Принципы проектирования информационных систем для 90-х: все правильно. AFCEA International Press, Фэрфакс, Вирджиния. 1990. Стр. 13.
4. ^ Р. Шаретт, Анализ и управление рисками программной инженерии. Макгроу Хилл, Нью-Йорк, 1989.
5. ^ Алан М. Дэвис: Операционное прототипирование: новый подход к разработке. Программное обеспечение IEEE, сентябрь 1992 г. Стр. 71.
6. ^ Тодд Гримм: Состояние человека: обоснование быстрого прототипирования. Технологии сжатия времени, т. 3 шт. 3. Accelerated Technologies, Inc., май 1998 г. Страница 1. [3]
7. ^ Джон Криннион: Развитие эволюционных систем, практическое руководство по использованию прототипирования в рамках методологии структурированных систем. Plenum Press, Нью-Йорк, 1991. Стр. 18.
8. ^ С. П. Овермайер: Революционное и эволюционное быстрое прототипирование: баланс производительности программного обеспечения и проблем проектирования HCI. Центр передового опыта в области командования, управления, связи и разведки (C3I), Университет Джорджа Мейсона, 4400 University Drive, Фэрфакс, Вирджиния.
9. ^ Консорциум производительности программного обеспечения: эволюционная быстрая разработка. Документ SPC SPC-97057-CMC, версия 01.00.04, июнь 1997 г. Херндон, Вирджиния, стр. 6.
10. ^ Дэвис. Стр. 72-73. Цитирование: Э. Берсофф и А. Дэвис, Влияние моделей жизненного цикла управления конфигурацией программного обеспечения. Comm. ACM, август 1991 г., стр. 104–118.
11. ^ По материалам C. Melissa Mcclendon, Larry Regot, Gerri Akers.
12. ^ По материалам Консорциума по продуктивности программного обеспечения. ППС 10–13.
13. ^ Джозеф Э. Урбан: Создание прототипов программного обеспечения и разработка требований. Римская лаборатория, Рим, Нью-Йорк.
14. ^ Пол У. Парри. Быстрое создание прототипов программного обеспечения. Университет Шеффилда Халлама, Шеффилд, Великобритания. [4]
15. ^ Доктор Рамон Акоста, Карла Бернс, Уильям Жепка и Джеймс Сидоран. Применение методов быстрого прототипирования в среде разработки требований. IEEE, 1994. [5]
16. ^ Software Productivity Solutions, Incorporated. Рабочая станция для разработки расширенных требований (AREW). 1996 г. [6]
17. ^ от GE Research and Development. https://web.archive.org/web/20061013220422/http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html
18. ^ Консорциум методов разработки динамических систем. https://web.archive.org/web/20060209072841/http://na.dsdm.org/
19. ^ Алан Дикс, Джанет Финли, Грегори Д. Абоуд, Рассел Бил; Взаимодействие человека и компьютера, третье издание

Рекомендации