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