![]()
|
|||
Руководство пользователя GUI Machine
Практика прототипирования
Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ. Однако сделать процесс прототипирования полезным и эффективным — непростая задача. Встречаются подводные камни, появляются вопросы. Кто и когда должен прототипировать? Как делать прототипы? Как их использовать? Ответы на эти вопросы и последующие шаги определяют успешность и полезность нововведения. Если они будут неверными – прототипирование может стать не только вредным, но и крайне дорогостоящим процессом. В статье я хочу поделиться опытом построения процесса прототипирования в моей компании. Расскажу, как мы ответили на озвученные вопросы и каких успехов достигли. Когда и как использовать прототипы? Теории и практики
SWEBOK (Software Engineering Body of Knowledge). Свод знаний по программной инженерии
IEEE 830-1998. Рекомендации IEEE по разработке требований к программному обеспечению
Мнения специалистов
Промежуточные итоги. Выжимка из теории
· Как инструмент извлечения, проверки и утверждения требований на этапе работы с требованиями · Как основу для написания SRS и ТЗ на этапе проектирования · Как технику проверки программного дизайна на этапе проектирования · Как объект исследования юзабилити-тестирования на этапе тестирования · Как образец для разработчиков на этапе реализации (конструирования)
Как ещё можно использовать прототип?
На этапе коммерческого предложения
Для чего мы это делаем? Тут всё просто: прототип позволяет нам выделиться из десятка похожих коммерческих предложений и расположить к себе заказчика. Мы делаем это не всегда, т.к. всегда есть риск того, что исполнителями проекта выберут не нас, и, соответственно, работы по прототипированию оплачены не будут. Как образец при тестировании готового ПО
Как образец при приёмке-сдаче работ
Как пример решения для демонстрации потенциальным заказчикам
Жизненный цикл прототипа
1. Установление контакта с потенциальным заказчиком и получение предварительной информации от него. Менеджер создаёт небольшой интерактивный прототип. Сам, пока без привлечения дизайнера. Отправляем коммерческое предложение вместе с видеозаписью прототипа. 2. Если мы выбраны в качестве исполнителя проекта, то поручаем дизайнеру отрисовать UI-компоненты и дорабатываем прототип. Идём к заказчику с обновлённым прототипом. При этом, если заказчик и пользователи – разные лица, мы просим допустить нас к конечным пользователям: они прямо на прототипе показывают, что им нравится, а что они хотят изменить. Таким образом мы собираем требования, в соответствии с ними изменяем прототип и опять идём к пользователям. За несколько итераций прототип, и, соответственно, функциональность, согласована. 3. Когда функциональность согласована, мы просим пользователей указать функции, которые им выполнять неудобно, некомфортно, непривычно. Исправляем прототип в соответствиями с замечаниями. Это своего рода юзабилити-тестирование. 4. Параллельно с общением с пользователем согласовываем прототип и с разработчиками. Узнаём, возможно ли и насколько сложно реализовать то, что показано в прототипе. Если какую-то функцию реализовать невозможно – тогда придумываем альтернативный вариант и согласовываем с заказчиком. В конце концов получаем прототип, согласованный как с заказчиком, так и с разработчиками. 5. Снимаем с прототипа скриншоты и делаем на их основе ТЗ. 6. Отдаём ТЗ и прототип разработчикам. Разработчики реализуют систему, используя прототип в качестве образца. 7. Готовая система и её прототип отдаются тестировщикам. Они также используют прототип в качестве образца. 8. Сдаем систему заказчику. Он проверяет, соответствует ли реализованная система прототипу. 9. Прототип уходит в архив. Но если заказчик просит доработку, ты мы достаём прототип и дорабатываем его с учётом новых требований. И дальше вновь по циклу со второго шага.
Последствия прототипирования
Если раньше процесс передачи информации выглядел примерно так: то сейчас он представляет собой что-то вроде этого: Картинки позаимствовал из презентации Геннадия Драгуна, за что ему премного благодарен. Прототипы бывают разные...
Прототипы можно разделить на 2 большие группы в зависимости от способов их создания и последующего использования:
· Одноразовые прототипы · Эволюционные прототипы
Одноразовые прототипы являются макетом интерфейса, который в последствии не станет частью готовой системы и на определённом этапе будет «выброшен». Такие прототипы создаются и изменяются быстро, поскольку не требуют качественной реализации. Зачастую они создаются в специализированных инструментах без программирования. Эволюционный прототип – это предварительная реализация программы, альфа-версия, которая по мере своего развития становится всё ближе и ближе к готовому продукту и, в конце концов, становится им. Эволюционные прототипы менее гибкие, их создание и изменение более длительное и дорогое. Поскольку на начальном этапе не все требования известны и утверждены, прототип в ходе своего развития может обрасти «заплатками». При таком подходе есть большой риск получить на выходе продукт неудовлетворительного качества. Преимуществом эволюционных прототипов считается то, что, во-первых, уже на ранних стадиях заказчик получает работающую систему, во-вторых, не нужно тратить ресурсы на создание прототипа, который потом будет «выброшен». У каждого из подходов есть свои преимущества и недостатки. Каждый сам для себя решает, какие прототипы ему создавать в зависимости от решаемой задачи, от особенности процесса разработки ПО в компании, от квалификации сотрудников. Мы для себя решили использовать одноразовое прототипирование, как наиболее гибкий, эффективный и менее рискованный инструмент. На нём я и акцентирую внимание. Какие прототипы мы используем?
· степени интерактивности, · детализации, точности, близости к конечному дизайну.
Большинство из нас делает «бумажные» прототипы в самом начала этапа сбора требований. Затем по мере уточнения требований увеличивается точность прототипов. Кто-то останавливается на вайрфрейме (каркас интерфейса без конечного дизайна), кто-то доводит до мокапов с дизайном, близким к конечному. Но наибольший интерес представляют интерактивные прототипы. Именно они позволят полноценно вовлечь пользователя, показать систему целиком и в действии. Для нас интерактивные прототипы являются наиболее эффективными, поэтому именно их мы и используем в нашей деятельности. Прототипирование на постсоветском пространстве
Однако радует осознание того, что ситуация с прототипированием в компании неудовлетворительна. Это видно по результатам другого опроса: более 70% опрошенных не удовлетворены текущей ситуацией и почти половина из них находится на данный момент в поиске хорошей методики и инструмента. Хорошая тенденция. Кто должен прототипировать?
Как мы делаем прототипы?
Использование для создания прототипов собственного инструмента имеет как положительные, так и отрицательные стороны. Минусом для компании является необходимость выделения ресурсов на развитие GUI Machine. С выводом продукта на рынок количество необходимых ресурсов только увеличиваются: инструмент нужно продвигать, развивать, поддерживать. Преимущества своего продукта в том, что мы можем сделать инструмент таким, каким мы хотим его видеть. Кроме того, продукт начал приносить коммерческую прибыль. Зри в корень. Ищи ответы
· для чего прототипировать? · кто должен прототипировать? · когда нужно прототипировать?
Прототипировать ли?
- · Трата дополнительных усилий на этапе предпроекта, которые заказчик не всегда готов оплачивать · Время на обучение инструменту прототипирования.
+ · Новый уровень коммуникации с заказчиком и внутри компании · Ошибки, допущенные в начала проекта и обнаруженные в его конце – самые дорогие. Прототипирование позволяет обнаружить допущенные ошибки на ранней стадии и минимизировать появление новых · Повышение качества за счёт снижения количества ошибок · Уменьшение сроков и стоимости разработки за счёт разработки «с первого раза» без необходимости доработки – экономия дефицитного времени разработчика · У пользователей не возникает отторжения, поскольку они уже знакомы с прототипом, и интерфейс системы не становится для них сюрпризом · Пользователей, поработавших с прототипом, не нужно обучать работе с системой · Повышение лояльности заказчика.
Цифры
· Сроки на работу с требованиями и проектирование увеличились на 50% · Сроки реализации сократились на величину от 20 до 35% · Сроки тестирования сократились на 30%
Это только сухие цифры, но, как я уже говорил, прототипирование даёт далеко не только уменьшение сроков. Вывод
Если вы ещё не прототипируете – попробуйте, не пожалеете.
Руководство пользователя GUI Machine
|
|||
|