Введение
Создание прототипов программных приложений – это деятельность по созданию прототипов программных приложений, то есть неполных версий разрабатываемого программного обеспечения. Это этап в процессе разработки программного обеспечения, аналогичный прототипированию в других областях, таких как машиностроение или производство. Прототип обычно имитирует лишь некоторые аспекты и может существенно отличаться от конечного продукта. Прототипирование дает ряд преимуществ: разработчики и инженеры могут получить ценную обратную связь от пользователей на ранних стадиях проекта. Заказчик и исполнитель могут сравнить, соответствует ли разработанное программное обеспечение техническому заданию, на основе которого оно создается. Кроме того, это позволяет оценить точность первоначальных оценок проекта и возможность успешного соблюдения сроков и этапов реализации. Методы и степень детализации прототипов разрабатывались и обсуждались с момента появления этой практики в начале 1970-х годов.
Software prototyping is the activity of creating prototypes of software applications, i. e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing. A prototype typically simulates only a few aspects of, and may be completely different from, the final product. Prototyping has several benefits: the software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in prototyping have been in development and debate since its proposal in the early 1970s.
Обзор
Цель прототипа – позволить пользователям программного обеспечения оценивать предложения разработчиков по дизайну конечного продукта, опробовав их на практике, а не интерпретируя и оценивая дизайн на основе описаний. Прототипирование программного обеспечения обеспечивает понимание функций программного обеспечения и потенциальных угроз или проблем. Прототипирование также может использоваться конечными пользователями для формулирования и подтверждения требований, которые не были учтены, что может быть ключевым фактором в коммерческих отношениях между разработчиками и их клиентами. Особенно активно прототипирование используется в проектировании взаимодействия. Этот процесс противоположен монолитному циклу разработки 1960-х и 1970-х годов, когда сначала создавалась вся программа целиком, а затем устранялись несоответствия между проектированием и реализацией, что приводило к увеличению стоимости программного обеспечения и неточным оценкам сроков и затрат. Монолитный подход получил название техники "Убийства (программного) Дракона", поскольку подразумевает, что разработчик программного обеспечения – это единственный герой, которому предстоит в одиночку справиться со всей задачей. Прототипирование также позволяет избежать значительных затрат и сложностей, связанных с внесением изменений в готовый программный продукт. Практика прототипирования – один из ключевых аргументов, выдвигаемых Фредериком П. Бруксом в его книге 1975 года "Мифический человеко-месяц" и в статье, посвященной десятилетнему юбилею книги, "Нет серебряной пули". Ранним примером крупномасштабного прототипирования программного обеспечения стала реализация транслятора Ada/ED Нью-Йоркского университета для языка программирования Ada. Он был реализован на языке SETL с целью создания исполняемой семантической модели языка Ada, с акцентом на ясность дизайна и пользовательского интерфейса, а не на скорость и эффективность. Система NYU Ada/ED стала первой валидированной реализацией Ada, получившей сертификат 11 апреля 1983 года.
Типы
Прототипирование программного обеспечения имеет множество вариантов. Однако все методы в той или иной степени основаны на двух основных формах прототипирования: прототипирование с отбрасыванием и эволюционное прототипирование.
Эволюционное прототипирование
Эволюционное прототипирование (также известное как прототипирование на макетной плате) существенно отличается от одноразового прототипирования. Главная цель при использовании эволюционного прототипирования – создать очень надёжный прототип структурированным способом и постоянно его совершенствовать. Причина такого подхода заключается в том, что эволюционный прототип, после создания, становится основой новой системы, и дальнейшие улучшения и требования будут строиться на его базе. При разработке системы с использованием эволюционного прототипирования система непрерывно дорабатывается и перестраивается. "Эволюционное прототипирование признаёт, что мы не понимаем всех требований и реализует только те, которые хорошо определены". Этот метод позволяет команде разработчиков добавлять функции или вносить изменения, которые невозможно было предвидеть на этапах определения требований и проектирования. Чтобы система была полезной, она должна развиваться в процессе использования в реальной рабочей среде. Продукт никогда не бывает "завершённым"; он постоянно совершенствуется по мере изменения условий эксплуатации. Мы часто пытаемся определить систему, опираясь на наиболее привычную нам точку отсчёта – текущую ситуацию. Мы делаем предположения о том, как будет вестись бизнес и на какой технологической базе он будет реализован. Разрабатывается план для развития необходимых возможностей, и рано или поздно создаётся система, похожая на задуманную. Эволюционные прототипы превосходят одноразовые прототипы тем, что представляют собой функциональные системы. Хотя они могут и не обладать всеми функциями, запланированными пользователями, их можно использовать временно до поставки финальной версии. "В среде прототипирования нередки случаи, когда пользователь начинает практическое использование первоначального прототипа, ожидая более продвинутой версии. Пользователь может решить, что даже "несовершенная" система лучше, чем её отсутствие".
" evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood." This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase. For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes we often try to define a system using our most familiar frame of reference—where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered. Evolutionary prototypes have an advantage over throwaway prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered. "It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version The user may decide that a 'flawed' system is better than no system at all."
Инкрементальное прототипирование
Конечный продукт создается в виде отдельных прототипов. В итоге эти отдельные прототипы объединяются в единый дизайн. Благодаря инкрементальному прототипированию сокращается временной промежуток между пользователем и разработчиком программного обеспечения.
Экстремальное прототипирование
Экстремальное прототипирование как процесс разработки особенно эффективно при создании веб-приложений. По сути, оно разделяет веб-разработку на три фазы, каждая из которых строится на основе предыдущей. Первая фаза – это статический прототип, состоящий преимущественно из HTML-страниц. На второй фазе экраны программируются и становятся полностью функциональными благодаря использованию имитированного уровня сервисов. На третьей фазе происходит реализация самих сервисов. "Процесс называется экстремальным прототипированием, чтобы подчеркнуть важность второй фазы, на которой разрабатывается полностью функциональный пользовательский интерфейс с минимальным вниманием к сервисам, за исключением их интерфейса."
Преимущества
Существует множество преимуществ использования прототипирования в разработке программного обеспечения – как ощутимых, так и неосязаемых. Сокращение времени и затрат: прототипирование позволяет улучшить качество требований и спецификаций, предоставляемых разработчикам. Поскольку внесение изменений обходится экспоненциально дороже по мере их обнаружения на более поздних этапах разработки, ранжное выявление реальных потребностей пользователя может привести к созданию более быстрого и менее дорогостоящего программного обеспечения.
Операционное прототипирование
Операционное прототипирование было предложено Аланом Дэвисом как способ интеграции одноразового и эволюционного прототипирования с традиционной разработкой систем. "Оно сочетает в себе преимущества быстрого и гибкого подхода и традиционной разработки, делая это разумным образом. Разработчики реализуют только хорошо изученные функции при создании эволюционной базовой линии, а для экспериментов с недостаточно понятными функциями используют одноразовое прототипирование." было разработано Консорциумом повышения производительности программного обеспечения – агентством по разработке и интеграции технологий для Управления информационных технологий Агентства передовых исследовательских проектов Министерства обороны (DARPA). В основе ERD лежит концепция построения программных систем на основе повторного использования компонентов, применения шаблонов программного обеспечения и архитектурных шаблонов. Эволюционирующая архитектура, представляющая собой класс решений, подчеркивает непрерывное развитие возможностей системы в оперативном реагировании на изменяющиеся потребности пользователей и технологические новшества. Процесс ориентирован на использование небольших, специализированных команд, объединяющих специалистов по разработке программного обеспечения и системной инженерии, работающих в несколько коротких, часто параллельных итераций с частым взаимодействием с заказчиком. Ключом к успеху проектов на основе ERD является параллельный исследовательский анализ и разработка функций, инфраструктуры и компонентов с применением передовых технологий, обеспечивающих быстрое реагирование на изменения в технологиях, на рынке или в требованиях заказчика. Для моделирования приложений также можно использовать программное обеспечение, имитирующее работу реальных программ, например, для компьютерного обучения, демонстраций и поддержки клиентов, такое как программы для записи экрана, поскольку эти области тесно связаны.
Требования Инженерная среда
Инженерная среда разработки требований (REE), разрабатываемая в Римской лаборатории с 1985 года, предоставляет интегрированный набор инструментов для быстрого представления, построения и выполнения моделей критически важных аспектов сложных систем. В настоящее время инженерная среда разработки требований используется ВВС США для разработки систем. Она представляет собой:
интегрированный набор инструментов, позволяющий системным аналитикам быстро создавать функциональные прототипы, прототипы пользовательского интерфейса и прототипы производительности компонентов системы. Эти действия по моделированию выполняются для более глубокого понимания сложных систем и снижения влияния неточных спецификаций требований на стоимость и сроки разработки системы. Модели могут быть построены легко и на различных уровнях абстракции или детализации, в зависимости от конкретных поведенческих аспектов моделируемого поведения. Эта система также известна как Advanced Requirements Engineering Workstation или AREW.
Нереляционные среды
Нереляционное определение данных (например, с использованием Caché или ассоциативных моделей) может повысить эффективность прототипирования для конечных пользователей, откладывая или устраняя необходимость нормализации данных на каждом этапе моделирования. Это может способствовать более раннему и четкому пониманию бизнес-требований, однако не гарантирует их технической и экономической реализуемости в целевой производственной системе.
PSDL
PSDL — это язык описания прототипов, предназначенный для описания программного обеспечения реального времени. Сопутствующий инструментарий — CAPS (Система автоматизированного прототипирования). Прототипирование программных систем с жёсткими требованиями к реальному времени представляет собой сложную задачу, поскольку временные ограничения накладывают зависимости на реализацию и аппаратное обеспечение. PSDL решает эти проблемы, вводя управляющие абстракции, включающие декларативные ограничения по времени. CAPS использует эту информацию для автоматической генерации кода и соответствующих расписаний реального времени, мониторинга временных ограничений в процессе выполнения прототипа и моделирования выполнения в пропорциональном реальному времени относительно набора параметризованных моделей аппаратного обеспечения. Система также предоставляет значения по умолчанию, позволяющие выполнять неполные описания прототипов, интегрирует создание прототипов с репозиторием повторного использования программного обеспечения для быстрой реализации эффективных решений и обеспечивает поддержку быстрого изменения требований и проектов.