Создание прототипов программного обеспечения - Software prototyping

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

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

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

Обзор

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

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

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

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

Контур

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

Определите основные требования
Определите основные требования, включая желаемую входную и выходную информацию. Детали, такие как безопасность, обычно можно игнорировать.
Разработать начальный прототип
Разработан первоначальный прототип, включающий только пользовательские интерфейсы. (См. Горизонтальный прототип ниже)
Рассмотрение
Заказчики, включая конечных пользователей, изучают прототип и предоставляют отзывы о возможных дополнениях или изменениях.
Пересмотреть и улучшить прототип
Используя отзывы, можно улучшить как спецификации, так и прототип. Могут потребоваться переговоры о том, что входит в объем контракта / продукта. Если вносятся изменения, может потребоваться повторение шагов №3 и №4.

Габаритные размеры

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

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

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

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

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

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

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

Типы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определить прототип
Согласитесь с планом
Создайте прототип
Просмотрите прототип

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

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

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

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

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

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

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

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

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

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

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

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

Evolutionary Rapid Development (ERD) был разработан консорциумом Software Productivity Consortium, агентом по разработке и интеграции технологий Управления информационных технологий Управления перспективных исследовательских проектов Министерства обороны США (DARPA).

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

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

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

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

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

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

Инструменты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PSDL

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

Languages

In other projects