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

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

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

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

Обзор [ править ]

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

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

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

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

Схема процесса создания прототипа [ править ]

Процесс создания прототипа включает следующие шаги ^{[ необходима цитата ]}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы прототипов [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты [ править ]

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

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

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

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

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

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

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

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

Среда разработки требований [ править ]

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

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

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

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

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

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

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

Нереляционные среды [ править ]

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

PSDL [ править ]

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

Примечания [ править ]

1. ^ К. Мелисса Макклендон, Ларри Регот, Джерри Акерс: Анализ и создание прототипов эффективных графических интерфейсов пользователя. Октябрь 1996 г.[1]
2. ^ DA Стейси, профессор Университета Гвельфов. Гуэлф, Онтарио. Конспект лекций по быстрому прототипированию. Август 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. Мелисса МакКлендон, Ларри Regot, GERRI Акерс.
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. ^ Алан Дикс, Джанет Финли, Грегори Д. Эбоуд, Рассел Бил; Взаимодействие человека и компьютера, третье издание

Ссылки [ править ]