Разработка прототипа по доклад

Обновлено: 30.06.2024

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

Содержание

Обзор

Процесс создания прототипа обычно состоит из шагов:

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

Типы прототипирования

Прототипирование имеет множество различных вариантов. Тем не менее, все методы в какой-то степени основаны на двух основных типах.

Быстрое прототипирование

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

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

Быстрое прототипирование не обязательно выполняется в рамках той же платформы и тех же технологий, что и разрабатываемая система. Для прототипа графического интерфейса пользователя (GUI) могут использоваться как стандартные HTML-страницы, либо прототип может подготавливаться в программе, специально предназначенной для создания макетов (например: Axure RP, Microsoft Expression Blend и др.).

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

Эволюционное прототипирование (англ. evolutionary prototyping ) ставит своей целью последовательно создавать макеты системы, которые будут все ближе и ближе к реальному продукту.

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

Преимущества и недостатки

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

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

Является спорным, применимо ли прототипирование, в той или иной форме, ко всем типам проектов. Однако, известно, что наибольшие преимущества прототипирование дает при разработке систем, имеющих развитый пользовательский интерфейс [источник не указан 1248 дней] . Системам, основная работа которых состоит в вычислениях, например, системам с интерфейсам командной строки, прототипирование почти не дает реальных преимуществ. Хорошие результаты дает прототипирование при проектировании интерфейсов человек-компьютер.

Нет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.

Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ.

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

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

Когда и как использовать прототипы? Теории и практики

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

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

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

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

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

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

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

В цикле статей Юрия Ветрова об интерактивных прототипах я встретил мысль об использовании прототипов на этапе реализации. Он предлагает разработчикам использовать прототип в качестве образца, поскольку он намного проще и правильнее понимается, нежели многостраничное ТЗ.

Промежуточные итоги. Выжимка из теории

Как инструмент извлечения, проверки и утверждения требований на этапе работы с требованиями
Как основу для написания SRS и ТЗ на этапе проектирования
Как технику проверки программного дизайна на этапе проектирования
Как объект исследования юзабилити-тестирования на этапе тестирования
Как образец для разработчиков на этапе реализации (конструирования)

Как ещё можно использовать прототип?

На этапе коммерческого предложения

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

Для чего мы это делаем? Тут всё просто: прототип позволяет нам выделиться из десятка похожих коммерческих предложений и расположить к себе заказчика.

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

Как образец при тестировании готового ПО

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

Как образец при приёмке-сдаче работ

Здесь уже больше используем прототип не мы, а наши заказчики. При приёмке работ они теперь помимо, а иногда и вместо проверки функций по ТЗ, сравнивают реализованную систему с прототипом. Это выгодно обеим сторонам. Заказчик вправе предъявить претензии, если в реализованной системе что-то не так, как в прототипе. Но и мы как исполнитель можем защитить себя от претензий, если реализуем систему точно так же, как в прототипе. У заказчика просто не будет оснований быть недовольным. Таким образом, исполнитель отдаёт, а заказчик получает ровно то, что было согласовано – ни больше, ни меньше. Никто не делает лишней работы, и все довольны.

Как пример решения для демонстрации потенциальным заказчикам

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

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

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

Установление контакта с потенциальным заказчиком и получение предварительной информации от него. Менеджер создаёт небольшой интерактивный прототип. Сам, пока без привлечения дизайнера. Отправляем коммерческое предложение вместе с видеозаписью прототипа.
Если мы выбраны в качестве исполнителя проекта, то поручаем дизайнеру отрисовать UI-компоненты и дорабатываем прототип. Идём к заказчику с обновлённым прототипом. При этом, если заказчик и пользователи – разные лица, мы просим допустить нас к конечным пользователям: они прямо на прототипе показывают, что им нравится, а что они хотят изменить. Таким образом мы собираем требования, в соответствии с ними изменяем прототип и опять идём к пользователям. За несколько итераций прототип, и, соответственно, функциональность, согласована.
Когда функциональность согласована, мы просим пользователей указать функции, которые им выполнять неудобно, некомфортно, непривычно. Исправляем прототип в соответствиями с замечаниями. Это своего рода юзабилити-тестирование.
Параллельно с общением с пользователем согласовываем прототип и с разработчиками. Узнаём, возможно ли и насколько сложно реализовать то, что показано в прототипе. Если какую-то функцию реализовать невозможно – тогда придумываем альтернативный вариант и согласовываем с заказчиком. В конце концов получаем прототип, согласованный как с заказчиком, так и с разработчиками.
Снимаем с прототипа скриншоты и делаем на их основе ТЗ.
Отдаём ТЗ и прототип разработчикам. Разработчики реализуют систему, используя прототип в качестве образца.
Готовая система и её прототип отдаются тестировщикам. Они также используют прототип в качестве образца.
Сдаем систему заказчику. Он проверяет, соответствует ли реализованная система прототипу.
Прототип уходит в архив. Но если заказчик просит доработку, ты мы достаём прототип и дорабатываем его с учётом новых требований. И дальше вновь по циклу со второго шага.

Последствия прототипирования

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

Если раньше процесс передачи информации выглядел примерно так:

то сейчас он представляет собой что-то вроде этого:

Картинки позаимствовал из презентации Геннадия Драгуна, за что ему премного благодарен.

Прототипы бывают разные.

Существует множество мнений о том, что нужно/можно считать прототипом и какими характеристиками он должен обладать. Чтобы не выставлять своё субъективное видение за истину, я опять обращусь к своду знаний SWEBOK. Он говорит, что прототипом могут считаться как “бумажные” модели, так и пилотные подсистемы, реализуемые как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов.

Одноразовые прототипы
Эволюционные прототипы

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

Какие прототипы мы используем?

Одноразовые прототипы делятся в свою очередь по:

степени интерактивности,
детализации, точности, близости к конечному дизайну.

Прототипирование на постсоветском пространстве

Теперь краткая информация о распространении и тенденциях прототипирования в России и странах СНГ. Как показывает опрос, проведённый Павлом Коноплицким на Хабре, в половине компаний процесс прототипирования вообще отсутствует.

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

Кто должен прототипировать?

Вернёмся к первому опросу. Если смотреть на исполнителей, прототипированием в большинстве проектов занимаются технические специалисты. Для меня это стало неожиданностью: как я уже сказал, большинство стандартов и публикаций рассматривают прототипирование в первую очередь как инструмент для извлечения и утверждения требований. А кто занимается сбором требований? Менеджер или аналитик, но никак не технический специалист. Если это будет делать он – у нас опять появятся большие потери информации, менеджер будет играть роль сломанного телефона. Поэтому мы считаем, что прототипировать должен именно менеджер, как центральное звено команды проекта и как лицо, непосредственно контактирующее с заказчиком. В нашей компании должность менеджера и аналитика объединена, что является ещё одним фактором в пользу прототипирования менеджерами.

Как мы делаем прототипы?

Мы поставили перед собой два условия: во-первых, прототипы должны быть интерактивными, во-вторых, прототипировать должны менеджеры. Нам нужен был инструмент, который позволяет создавать интерактивные прототипы без программирования, т.к. менеджеры в общем случае не умеют программировать. Пробовали Visio – но интерактивность созданных в нём прототипов была невысокой. Пробовали GUI Design Studio. Но и он не прижился.

В итоге мы пришли к собственной разработке и сделали её такой, какой хотим видеть инструмент прототипирования. Если не хватало каких-либо функций – добавляли. В итоге разработка доросла до качественного продукта, и мы выпустили его на рынок. Назвали GUI Machine. Сейчас это кроссплатформенный инструмент прототипирования, который позволяет создавать интерактивные прототипы декстоп и веб-приложений без программирования.

Использование для создания прототипов собственного инструмента имеет как положительные, так и отрицательные стороны. Минусом для компании является необходимость выделения ресурсов на развитие GUI Machine. С выводом продукта на рынок количество необходимых ресурсов только увеличиваются: инструмент нужно продвигать, развивать, поддерживать. Преимущества своего продукта в том, что мы можем сделать инструмент таким, каким мы хотим его видеть. Кроме того, продукт начал приносить коммерческую прибыль.

Зри в корень. Ищи ответы

для чего прототипировать?
кто должен прототипировать?
когда нужно прототипировать?

Прототипировать ли?

В качестве итогов – плюсы и минусы от внедрения процесса прототипирования.

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

Цифры

Сроки на работу с требованиями и проектирование увеличились на 50%
Сроки реализации сократились на величину от 20 до 35%
Сроки тестирования сократились на 30%

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

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

Необходимость модели прототипирования —

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

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

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

Итеративная разработка. Как только заказчик одобряет прототип, само программное обеспечение разрабатывается с использованием итеративного подхода с использованием водопада. Несмотря на наличие рабочего прототипа, документ SRS обычно необходимо разрабатывать, поскольку документ SRS имеет неоценимое значение для проведения анализа пригодности, проверки и разработки тестового примера на более поздних этапах.

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

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

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

Обзор

Процесс создания прототипа обычно состоит из шагов:

Типы прототипирования

Быстрое прототипирование

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

Эволюционное прототипирование (англ. evolutionary prototyping) ставит своей целью последовательно создавать макеты системы, которые будут все ближе и ближе к реальному продукту.

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

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

Тем не менее, использование прототипирования создаёт ряд дополнительных рисков.

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

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

Читайте также: