Поиск подходящего инструмента прототипирования (об этом мы достаточно подробно написали в предыдущем посте) занял у нас довольно много времени и… окончился ничем. Нам так и не удалось найти инструмент, который в полной мере покрывал бы все наши потребности. Похоже, что программы для прототипирования, полностью отвечающей всем нашим представлениям и пожеланиям, в природе просто не существовало… Единичные кандидаты были близки к победе, но в любом из них был какой-нибудь неприятный и неприемлемый для нас «нюанс», который не позволял честно и без кривляния душой сказать: «Это именно то, что мы искали». Конечно, можно было закрыть глаза и пойти на компромисы, но это не наш путь. Недосказанность — это то, чего мы очень не любим.

На этой почве мы приняли не самое лёгкое решение попробовать собственноручно воплотить все наши идеи в жизнь и создать свой инструмент прототипирования. Подспорьем для разработки нашего собственного продукта стали также результаты анализа перспектив рынка инструментов прототипирования: существовало решений немного и покрывали они не все требования IT-компаний (по крайней мере — нашей компании, ну а мы, стоит ли сомневаться, далеко не единственные в своём роде). Ещё одним ощутимым толчком являлась перспектива выпустить первый российский полноценный инструмент прототипирования. Вобщем, плюсов мы насчитали больше, чем минусов.

Создание собственного инструмента прототипирования началось не с чистого листа, а на основе… впрочем, историю создания нашего инструмента опишу ниже.

История

2005 год

Основной продукт компании АЛЕЕ Софтвер представляет собой корпоративную систему класса ERM (система управления электронными записями) . Система состоит из двух тонких клиентов, через которые работают пользователи: десктопное приложение и веб. Веб-представление системы нередко требует кастомизации ее графического интерфейса под стандарты заказчика, а также под другие используемые им корпоративные информационные системы. Для выполнения этой задачи у нас родилась идея создать специальный инструмент — конструктор, с помощью которого можно было бы легко перестраивать графический интерфейс веб-составляющей системы. Предполагалось сделать его простым в использовании настолько, чтобы Заказчик своими силами смог кастомизировать интерфейс системы без написания программного кода и без привлечения сторонних специалистов. Так, ведомые этой идеей, мы начали экспериментальную работу по созданию подобного инструмента. Мы планировали сделать конструктор составной частью системы. Естественно, в таком случае его следовало бы и написать на языке основной системы, т.е. на Java. Впоследствии, однако, стало ясно, что существовавшие на тот момент технологии и возможности Java поставленную задачу решить не позволяют. Почему? Во-первых, на проектах большого размера скорость интерпретации Java-классов в нативный код Java-машиной была слишком низкой; значительно замедлялась и скорость работы приложения. Во-вторых, в стандартной сборке JDK отсутствовали нативные компоненты различных операционных систем. Эту проблему можно решить путем привлечения дополнительных библиотек, но это было бы связано и с дополнительными сложностями. К тому же качество и цены нас не устраивали. В-третьих, в самом языке Java не было многих необходимых для создания нового инструмента средств, на тот момент уже реализованных во многих других языках программирования. Список проблем и ограничений можно продолжать, вдаваясь в глубокие подробности и мелкие детали, но речь не о том. В конце концов мы решили отложить планируемую разработку, что называется, до лучших времен. В результате проведённых работ были созданы экспериментальные наработки, применение которым на тот момент мы не нашли. А проблема кастомизации интерфейсов системы была решена другим способом. В процессе разработки нами было создано запускаемое приложение, включавшее: область редактирования графического интерфейса, минимальный набор компонентов для тестирования графического редактора, отдельный фрейм для управления слоями и отдельный фрейм для настройки компонентов.

2006-2008

Около трёх лет наши экспериментальные наработки, как говорится, «лежали на полке» и терпеливо ждали своего часа.

2009

В определённый момент перед нашей компанией остро встал вопрос выбора инструмента прототипирования. Мы активно занялись поиском такового, о чём в подробностях повествует первая часть цикла. Именно в это время у нас родилась идея создания своего собственного инструмента прототипирования. И тут мы вспомнили про наши экспериментальные наработки: они подходили в качестве основы будущего инструмента наилучшим образом. Началась активная разработка инструмента прототипирования, который впоследствии получил название GUI Machine.

Постановка требований

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

• возможность прототипирования как десктоп-, так и веб-приложений; не обязательно, но желательно — возможность прототипирования приложений для мобильных устройств;
• более высокая (по сравнению с существующими аналогами) степень интерактивности создаваемых прототипов, большой набор обрабатываемых событий и выполняемых действий;
• наличие большого набора готовых графических элементов, как платформно-зависимых (т.е. «подстраивающихся» под вид операционной системы и ее оформление), так и платформно-независимых. В этот набор должны входить элементы для десктоп-, веб- и мобильных приложений. Они должны быть максимально кастомизируемыми;
• высокая реалистичность создаваемых прототипов;
• возможность просмотра прототипов собственными средствами, без привлечения сторонних программных продуктов;
• простота освоения: инструмент должен быть таким, чтобы с его помощью смог создавать прототипы человек, вообще не обладающий навыками программирования;
• высокая скорость создания прототипов;
• кросс-платформенность (инструмент должен работать по крайней мере в основных операционных системах — Windows, Mac OS, Linux).

Способ разработки

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

2010

Работу по созданию собственного инструмента прототипирования мы начали 22 ноября 2009 года. Уже в мае 2010, задолго до выпуска релизной версии, надежность и функциональность продукта достигли такого уровня, что он был успешно опробован на реальном проекте компании. Этот факт, кстати, стал еще одним свидетельством того, что мы сделали правильный выбор, обратившись к экстремальному программированию.

Эксплуатация продукта

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

Разработка веб-интерфейса CRM системы

Впервые инструмент был использован для разработки прототипа веб-интерфейса CRM системы (Customer Relationship Management System — система управления взаимодействием с клиентами) — сложной системы корпоративного уровня. Основой для него была существовавшая десктопная CRM система (внутренняя разработка компании). Для того, чтобы заказчик мог увидеть интерфейс будущей системы и высказать свои пожелания еще до фактического начала разработки, был создан его высокоточный и интерактивный прототип. Он адекватно и реалистично представлял как дизайн, так и функциональность системы:

Разработка внутрикорпоративного портала

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

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

2011

24 января 2011 года мы провели семинар «Проблемы и решения проектирования и прототипирования графических пользовательских интерфейсов», на котором впервые был представлен разработанный нами инструмент под названием GUI Machine.

Что получилось?

Результатом нашей работы стал продукт, получивший название GUI Machine. К числу несомненных плюсов продукта мы относим:

• возможность прототипирования как веб, так и десктоп-приложений;
• высокую интерактивность создаваемых прототипов;
• высокую визуальную точность и эстетическую привлекательность создаваемых прототипов;
• простоту освоения и работы в инструменте: GUI Machine могут использовать в своей работе не только и не столько программисты, но и менеджеры, аналитики, осуществляющие взаимодействие с клиентом, и даже сами клиенты;
• высокую скорость создания прототипирования;
• кросс-платформенность: работает на Windows, MacOS и Linux;
• полную русскую локализацию продукта (интерфейс продукта, руководство пользователя на русском языке) и русскоязычную поддержку (обучение, консультации).

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

• пока нет возможности полноценной совместной работы над прототипом;
• пока нет возможности генерации спецификации на основе прототипа;
• пока отсутствуют компоненты для прототипирования приложений для мобильных ОС;
• пока нет инструментов рисования UML-диаграмм;
• инструмент достаточно требовательный.

Почему во многих пунктах фигурирует слово «пока»? Дело в том, что сейчас мы динамично развиваемся, расширяем функциональность инструмента и, конечно, планируем избавиться от перечисленных недостатков.

P.S.

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

В следующей статье цикла будет представлен подробный обзор инструмента прототипирования GUI Machine