Создание инструмента прототипирования графических интерфейсов сложных информационных систем на базе программных разработок компании 'Алее Софтвер'

Создание инструмента прототипирования графических интерфейсов сложных информационных систем на базе программных разработок компании 'Алее Софтвер'

МИНОБРНАУКИ РОССИИ

Государственное образовательное учреждение высшего профессионального образования

“Санкт-Петербургский государственный электротехнический университет “ЛЭТИ” им. В.И.Ульянова (Ленина)” (СпбГЭТУ)

ЗАДАНИЕ

на дипломное проектирование

Студенту Гайфутдинову Рустему Талгатовичу, группа 5325

Место дипломного проектирования СПб ГЭТУ «ЛЭТИ», кафедра АПУ

. Тема дипломного проекта (работы)

“Создание инструмента прототипирования графических интерфейсов сложных информационных систем на базе программных разработок компании «Алее Софтвер»”

. Назначение разработки

Создание инструмента проектирования и прототипирования графических пользовательских интерфейсов сложных информационных систем, способного покрыть требования различных IT-компаний, на базе программных разработок компании «Алее Софтвер».

. Перечень подлежащих разработке разделов по теме

Анализ существующих инструментов прототипирования; постановка требований к разрабатываемому инструменту; выбор способа разработки; реализация инструмента; эксплуатация инструмента; проведение семинара; технико-экономическое обоснование; охрана интеллектуальной собственности.

. Состав технической документации проекта

Пояснительная записка к дипломному проекту.

. Консультанты (с указанием относящихся к ним разделов)

Консультант по экономическому обоснованию                  Кадиев И. Г.

Консультант по ОИС                                         Иванова Е. А.

Консультант по ГОСТ                                       Белаш О. Ю.

Консультант по программному обеспечению            Власенко С. В.

Руководитель …...............................................Кочетова Л. Б.

Студент ….......................................................Гайфутдинов Р.Т.

РЕФЕРАТ

Объем пояснительной записки - 90 страниц.

Пояснительная записка содержит 25 рисунков, 9 таблиц.

Ключевые слова - ГРАФИЧЕСКИЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ, ПРОТОТИПИРОВАНИЕ, ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ, GUI MACHINE, ПРОЕКТИРОВАНИЕ ИНТЕРФЕЙСА.

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

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

В результаты дипломного проекты был создан инструмент проектирования и прототипирования графических интерфейсов десктопных и веб-приложений, способный покрывать требования различных IT-компаний, в том числе - требования компании «АЛЕЕ СОФТВЕР».

Разработанный инструмент активно используется при реализации проектов компании «АЛЕЕ СОФТВЕР».

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

Термины и определения

Интерфейс - совокупность средств, методов и правил взаимодействия между элементами системы.

Интерфейс - совокупность средств и правил, обеспечивающих взаимодействие устройств вычислительной машины или системы обработки информации и (или) программ (определение по ГОСТ 15971-90 [1] ).

Человеко-машинный интерфейс (ЧМИ) - технические средства, предназначенные для обеспечения непосредственного взаимодействия между оператором и оборудованием и дающие возможность оператору управлять оборудованием и контролировать его функционирование (определение по ГОСТ Р МЭК 60447-2000 [2] ).

Интерфейс пользователя - интерфейс, обеспечивающий возможность обмена информацией между человеком и техническими или программными компонентами вычислительной системы (определение по ГОСТ Р ИСО/МЭК 15910-2002 [3] ).

Графический интерфейс пользователя (ГИП), графический пользовательский интерфейс (ГПИ), graphical user interface (GUI) - графическая среда организации взаимодействия пользователя с вычислительной системой. Графический интерфейс позволяет управлять поведением вычислительной системы через визуальные элементы управления.

Текстовый пользовательский интерфейс (ТПИ), Text user interface (TUI), Character User Interface (CUI) - разновидность интерфейса пользователя, использующая при вводе-выводе и представлении информации исключительно набор буквенно-цифровых символов и символов псевдографики.

Интерфейс командной строки, Command line interface (CLI) - разновидность текстового интерфейса (CUI) между человеком и компьютером, в котором инструкции компьютеру даются в основном путём ввода с клавиатуры текстовых строк (команд).

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

Пользователь - лицо или организация, которое использует действующую систему для выполнения конкретной функции (определение по ГОСТ Р ИСО/МЭК 12207-99 [4] ).

Юзабилити, usability - эргономическая характеристика того, насколько продукт может быть эффективно, экономично и с удовольствием использован определенными пользователями для достижения поставленных целей в заданном контексте использования (определение по стандарту Международной Организации по Стандартизации ISO 9241-11 "Руководство по юзабилити").

Прототип - модель или предварительная реализация части программного средства, пригодная для оценки проекта системы, её потенциальных рабочих характеристик, производства или лучшего понимания требований к программному средству (определение по ГОСТ Р ИСО/МЭК 15910-2002 [3] ).

Прототипирование - процесс создания прототипов.

Интерактивный режим - режим взаимодействия процесса обработки информации системы обработки информации с человеком, выражающийся в разного рода воздействиях на этот процесс, предусмотренных механизмом управления конкретной системы и вызывающих ответную реакцию процесса (определение по ГОСТ 15971-90 [1] ).

Режим реального времени - режим обработки информации, при котором обеспечивается взаимодействие системы обработки информации с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов(определение по ГОСТ 15971-90[1]).

Эмуляция - имитация функционирования одного устройства посредством другого устройства или устройств вычислительной машины, при которой имитирующее устройство воспринимает те же данные, выполняет ту же программу и достигает того же результата, что и имитируемое (определение по ГОСТ 15971-90 [1] ).

Готовый продукт - ранее разработанный и доступный для приобретения продукт, пригодный для использования в поставляемом или модифицированном виде (определение по ГОСТ Р ИСО/МЭК 12207-99 [4] ).

Программный продукт - набор машинных программ, процедур и, возможно, связанных с ними документации и данных (определение по ГОСТ Р ИСО/МЭК 12207-99 [4] ).

Программный модуль - отдельно компилируемая часть программного кода (программы) (определение по ГОСТ Р ИСО/МЭК 12207-99 [4] ).

Техническое задание - документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора (определение по ГОСТ Р ИСО/МЭК 12207-99 [4] ).

Версия-определенный экземпляр объекта(определение по ГОСТ Р ИСО/МЭК 12207-99[4]).

Lorem ipsum - классическое название условного, бессмысленного текста, заменяющего реальный контент.

Java - объектно-ориентированный язык программирования.

Байт-код - машинно-независимый код низкого уровня.

Виртуальная машина, ВМ - программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой платформы и исполняющая программы для этой платформы (target - целевая или гостевая платформа) на другой платформе (host - хост-платформа, платформа-хозяин).

Java Virtual Machine, JVM - виртуальная машина Java, интерпретирующая и исполняющая байт-код Java.

Java-приложение - приложение, написанное на языке программирования Java. Java-приложения обычно компилируются в байт-код, поэтому они могут работать на любой виртуальной Java-машине (JVM) независимо от компьютерной архитектуры.

Java Runtime Environment, JRE - минимальная реализация виртуальной машины, необходимая для исполнения Java-приложений, без компилятора и других средств разработки. Состоит из виртуальной машины - Java Virtual Machine и библиотеки Java-классов.

Кроссплатформенное программное обеспечение - программное обеспечение, работающее более чем на одной аппаратной платформе и/или операционной системе.

Операционная система, ОС - совокупность системных программ, предназначенная для обеспечения определенного уровня эффективности системы обработки информации за счет автоматизированного управления ее работой и предоставляемого пользователю определенного набора услуг (определение по ГОСТ 15971-90 [1] ).

Язык гипертекстовой разметки HTML - язык разметки исходного текста веб-документа, включающий специальные символы (теги), которые позволяют веб-браузеру сконструировать из текста дизайн. HTML предоставляет возможности форматирования и обработки форм, управления шрифтами, отображения информации в табличном виде,гипертекстовые связи, поддержку Java-апплетов.

HTML-файл - текстовый файл, содержащий внедрённый HTML-код.

Веб-браузер - программное обеспечение для просмотра веб-сайтов.- унифицированный язык моделирования - язык графического описания для объектного моделирования в области разработки программного обеспечения.

Portable Document Format, PDF - кроссплатформенный формат электронных документов.

Введение

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

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

Уже на ранних этапах развития концепции графического интерфейса был виден её огромный потенциал. Так, Билл Гейтс, сооснователь и бывший руководитель компании Microsoft Corporation, в своей книге «Дорога в будущее» [5] пишет:

«я полагал, что будущее за графическими интерфейсами и что для Microsoft очень важно выработать новый стандарт, в котором картинки и шрифты стали бы неотъемлемой частью простого в использовании интерфейса. Упростить работу с персональными компьютерами требовали интересы не только их нынешних владельцев, но и новых покупателей, которых часто пугало освоение сложного интерфейса»

Стив Джобс, сооснователь и генеральный директор корпорации Apple Inc после презентации возможностей компьютера Xerox Alto, в котором впервые был воплощён графический интерфейс, сказал:

“Я был так ослеплен первой штукой, которую они показали мне. Это был графический интерфейс. Я думаю, что это лучшая вещь, которую я когда-либо видел в жизни… Через 10 минут для меня стало ясно, что все компьютеры будут выглядеть именно так”

В настоящее время на рынке информационных систем фигурирует большое количество IT-компаний и программных продуктов для любых предметных областей. Зачастую функциональность различных программ является схожей, что привело к повышению значимости других характеристик продукта для конечного пользователя. Одним из наиболее весомых критериев выбора программ становится качество пользовательского интерфейса. Сейчас успех и популярность программных продуктов во многом определяется качеством пользовательского интерфейса и юзабилити.

Многие корпоративные информационные системы (КИС), такие как ERP, ECM, ERM, поставляются с базовым интерфейсом низкого качества, что влечёт за собой ряд негативных последствий для пользователей систем: усложнение работы, неполное и неоптимальное использование функциональности системы, снижение скорости работы, появление ошибок. Как следствие, значительно повышается риск получения отрицательного эффекта от внедрения и использования системы. В конечном итоге, многие компании вынуждены отказываться от использования системы. По вышеперечисленным причинам считаю, что пользовательский интерфейс КИС в большинстве случаев при внедрении нуждается в кастомизации.

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

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

Учитывая существующие проблемы графических интерфейсов современных информационных систем, я пришёл к выводу о необходимости и важности разработки графического прототипа системы на стадии проектирования. Однако для решения этой задачи требуется специализированный программный инструмент. На данный момент на рынке программных продуктов представлено немного инструментов проектирования и прототипирования интерфейсов. Анализ существующих средств показал, что они не способны покрывать все требования различных IT-компаний, в том числе требования компании «АЛЕЕ СОФТВЕР» по дизайну и интерактивности создаваемых прототипов, возможности прототипирования интерфейсов различных типов приложений и другим характеристикам. По этой причине было принято решение о создании собственного инструмента проектирования и прототипирования графических интерфейсов.

Задача: создание инструмента проектирования и прототипирования графических пользовательских интерфейсов сложных информационных систем, способного покрыть требования различных IT-компаний.

1 Анализ рынка инструментов прототипирования

Цель анализа инструментов проектирования и прототипирования графических интерфейсов:

ñ  поиск инструмента, способного покрыть требования различных IT-компаний, в том числе компании «АЛЕЕ СОФТВЕР»;

ñ  выработка требований к собственному инструменту;

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

.1 Виды прототипов

Перед тем, как приступить к непосредственному анализу, было изучено понятие прототипа. Прототипы характеризуются тремя основными критериями:

Ø Визуальная точность - степень близости внешнего вида прототипа к внешнему виду конечного продукта.

Ø  Функциональная точность - степень близости поведения прототипа к функциональности конечного продукта.

Ø  Точность контента - степень близости контента прототипа к реальному контенту.

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

Характеристики прототипов сведены в таблицу 1.

Таблица 1 - Характеристики прототипов

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

Интерактивный прототип описывает как внешний вид, так и функциональность разрабатываемой системы.

.2 Типы средств прототипирования

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

К непрограммным средствам прототипирования относят такие инструменты, как:

·     бумага и карандаш;

·        доска и маркер.

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

·   не обладает интерактивностью;

·        является схематичным;

·        способен описать функциональность системы в ограниченной форме.

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

К программным средствам прототипирования относятся компьютерные программы или комплекс программ нескольких видов:

ñ  редакторы скетчей;

ñ  графические редакторы;

ñ  специализированные редакторы графических интерфейсов;

ñ  интегрированная среда разработки.

Скетч - схематичный набросок, эскиз интерфейса.

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

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

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

Интегрированная среда разработки используется для создания программного прототипа. Для его создания реализуются некоторые функции проектируемой системы, для чего потребуется написание части программного кода. Созданный таким способом программный прототип позволит увидеть, как будет работать программа, однако его создание трудоёмко и занимает чрезмерное время.

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

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

.3 Определение критериев оценки

проектирование графический пользовательский интерфейс

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

Критерии оценки специализированных редакторов графических интерфейсов были условно разделены на:

·   первичные - самые весомые, значимые, важные критерии оценки;

·        вторичные - менее весомые критерии, которые позволят дать наиболее точную и всестороннюю оценку редакторов графических редакторов.

К первичным были отнесены следующие критерии:

1.       Способность прототипирования различных типов приложений:

·   десктопных приложений;

·        веб приложений;

·        приложений для мобильных операционных систем.

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

2.       Способность создания интерактивных прототипов.

Интерактивные прототипы - это прототипы, имитирующие работу реальной программы, способные реагировать на действия пользователя или определённые события.

3.       Степень интерактивности.

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

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

4.       Наличие набора компонентов.

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

5.       Внешний вид прототипа.

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

6.       Скорость создания прототипа.

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

7.       Возможность просмотра прототипа без установки редактора.

Просмотр прототипа должен быть доступен всем участникам проекта, в том числе заказчику, без установки редактора: при помощи дополнительной программы либо стандартными средствами операционной системы (например, в веб-браузере).

Критерии, имеющие меньший вес, были отнесены к вторичным:

1.       Скорость работы редактора.

Скорость работы программы определяется длительностью выполнения типовых операций: добавление/удаление/копирование/перемещение объектов, навигация по рабочей области, переключение между страницами проекта, сохранение проекта. Быстродействие редактора напрямую влияет на скорость создания прототипа.

2.       Поддерживаемые платформы.

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

3.       Простота работы.

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

4.       Удобство работы.

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

5.       Цена редактора.

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

6.       Развитие редактора.

Значимой характеристикой редактора является динамика его развития: регулярность добавления новой и расширения существующей функциональности.

7.       Техническая поддержка.

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

8.       Поддержка языков.

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

9.       Требуется стороннее ПО.

Для работы редактора не должно требоваться приобретение и установка стороннего программного обеспечения.

10.     Дополнительные инструменты.

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

После определения критериев оценки была выбрана методика анализа специализированных редакторов графических интерфейсов: прототипирование основного интерфейса существующей системы в анализируемых редакторах. В качестве такой системы была выбрана система Stor-M и веб-приложение к данной системе.

.4 Анализ

После определения критериев и методики оценки был выполнен поиск специализированных редакторов графических интерфейсов. Для анализа были запрошены демонстрационные (триальные) версии следующих редакторов:

1.       Axure RP

2.       Designer Vista

.        GUI Design Studio

.        iRise

.        Microsoft Expression Blend

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

.4.1 Axure RP

Инструмент для прототипирования веб-приложений и веб-сайтов.

Первичные критерии:

1.       Способность прототипирования различных типов приложений.

Редактор позволяет создавать прототипы только веб-приложений и веб-сайтов.

2.       Способность создания интерактивных прототипов.

Имеется возможность создания связи вида «событие-действие» между интерфейсами прототипа, что придаёт ему интерактивность.

3.       Степень интерактивности.

Интерактивность прототипа средняя, набор связей вида «событие-действие» ограничен несколькими экземплярами.

4.       Наличие набора компонентов.

Имеется небольшой набор компонентов. Нет возможности их детальной настройки. На сайте редактора имеется свободно распространяемая библиотека компонентов.

5.       Внешний вид прототипа.

Прототип представляет собой html-файл, выглядит реалистично.

6.       Скорость создания прототипа.

Приложение позволяет создавать прототип быстро.

7.       Возможность просмотра прототипа без установки редактора.

Для просмотра прототипа установка редактора не требуется, используется веб-браузер.

Вторичные критерии:

1.       Скорость работы редактора.

Редактор работает быстро, без продолжительных задержек и зависаний. Генерация прототипа также выполняется быстро.

2.       Поддерживаемые платформы.

Windows 2000, XP, 2003 Server, Vista, 7

Mac OS X 10.5+

3.       Простота работы.

Прототипирование доступно неподготовленным пользователям.

4.       Удобство работы.

Интерфейс редактора интуитивно понятный, но имеет большой недостаток: нет списка использованных в прототипе объектов. Также нет возможности привязывать объекты друг к другу на области редактирования прототипа. Нельзя сгенерировать в HTML-файл часть интерфейса, только прототип целиком. Есть возможность создания шаблонов объектов.

5.       Цена редактора.

Цена лицензии на 1 пользователя: $589.

6.       Развитие редактора.

Редактор развивается, часто выпускаются обновления.

7.       Техническая поддержка.

Техническая поддержка осуществляется по электронной почте. На веб-сайте редактора работает форум пользователей.

8.       Поддержка языков.

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

9.       Требуется стороннее ПО.

Для просмотра прототипа требуется веб-браузер (производителем рекомендуется IE 6.0+ или Firefox, но работает и на других). Для автоматической генерации спецификации интерфейсов требуется Microsoft Office Word 2000, XP, 2003, 2007.

10.     Дополнительные инструменты.

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

Вывод: редактор позволяет быстро и просто создавать прототипы интерфейсов простых веб-сайтов, но прототипирование веб-приложений со сложной функциональностью затруднено. Создание прототипов интерфейсов десктоп-приложений невозможно.

.4.2 Designer Vista

Приложение сочетает в себе 4 инструмента: редактор интерфейсов десктопных приложений, редактор интерфейсов веб-приложений, редактор скетчей и редактор интерфейсов Microsoft Office.

Первичные критерии:

1.      Способность прототипирования различных типов приложений.

Редактор позволяет создавать прототипы графических интерфейсов десктопных и веб-приложений, а также приложений Microsoft Office.

2.      Способность создания интерактивных прототипов.

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

3.      Степень интерактивности.

Степень интерактивности создаваемых прототипов - нулевая.

4.      Наличие набора компонентов.

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

5.      Внешний вид прототипа.

Прототип представляет собой файл html или pdf. Выглядит красиво и реалистично.

6.      Скорость создания прототипа.

Приложение позволяет создавать прототип очень быстро.

7.      Возможность просмотра прототипа без установки редактора.

Для просмотра прототипа редактор не нужен, используется веб-браузер или просмотрщик файлов pdf. Есть возможность просмотра созданных интерфейсов в виде слайд-шоу.

Вторичные критерии:

1.      Скорость работы редактора.

При выполнении некоторых операций в редакторе наблюдается задержка.

2.      Поддерживаемые платформы.

Windows XP, Vista, 7

3.      Простота работы.

Работа в редакторе проста, не требует специальной подготовки.

4.      Удобство работы.

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

5.      Цена редактора.

Цена лицензии на 1 пользователя: $199,96.

6.      Развитие редактора.

Редактор развивается, достаточно часто выпускаются обновления.

7.      Техническая поддержка.

Техническая поддержка осуществляется по электронной почте. На веб-сайте редактора работает форум пользователей.

8.      Поддержка языков.

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

9.      Требуется стороннее ПО.

Для просмотра прототипа требуется веб-браузер либо просмотрщик файлов pdf. Для автоматической генерации спецификации интерфейсов требуется Microsoft Office Word XP, 2003, 2007.

10.    Дополнительные инструменты.

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

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

.4.3 GUI Design Studio

Редактор ориентирован на прототипирование интерфейсов десктопных приложений, но также позволяет создавать прототипы интерфейсов веб-приложений.

Первичные критерии:

1.       Способность прототипирования различных типов приложений.

Редактор позволяет создавать прототипы интерфейсов десктопных и веб-приложений. Инструментарий для создания веб-приложений ограничен.

2.      Способность создания интерактивных прототипов.

Редактор позволяет создавать интерактивные прототипы.

3.       Степень интерактивности.

Степень интерактивности создаваемых прототипов - низкая. Приложение позволяет создавать связь только одного вида: появление объекта действия по нажатию на объект события.

4.       Наличие набора компонентов.

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

5.       Внешний вид прототипа.

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

6.       Скорость создания прототипа.

Приложение позволяет создавать прототип быстро.

7.       Возможность просмотра прототипа без установки редактора.

Есть возможность просмотра прототипа при помощи бесплатного просмотрщика GUI Design Viewer .

Вторичные критерии:

1.       Скорость работы редактора.

Редактор работает быстро, без продолжительных задержек и зависаний. Генерация прототипа также выполняется быстро.

2.       Поддерживаемые платформы.

Windows 2000, XP, 2003 Server, Vista, 7

3.       Простота работы.

Прототипирование доступно неподготовленным пользователям.

4.       Удобство работы.

Интерфейс редактора интуитивно понятный, но имеет несколько недостатков: нет списка использованных в прототипе объектов, нет возможности привязывать объекты друг к другу на области редактирования. Редактирование свойств объектов производится в отдельном всплывающем окне. Нет возможности выбирать запускаемый в просмотр объект.

5.       Цена редактора.

Цена лицензии на 1 пользователя: $499.

6.       Развитие редактора.

Редактор развивается, достаточно часто выпускаются обновления.

7.       Техническая поддержка.

Техническая поддержка осуществляется по электронной почте. Есть возможность оформления запроса на исправление найденной в программе ошибки на веб-сайте редактора.

8.       Поддержка языков.

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

9.       Требуется стороннее ПО.

Для корректной работы редактора стороннее ПО не требуется.

10.     Дополнительные инструменты.

Редактор имеет инструмент для рисования иконок Icon Express.

Вывод: редактор позволяет быстро и просто создавать прототипы несложных десктоп и веб-приложений, однако дизайн и интерактивность на невысоком уровне. Прототипирование приложений со сложной функциональность затруднительно.

.4.4 iRise

Редактор предназначен для прототипирования веб-приложений и веб-сайтов любой сложности.

Первичные критерии:

.        Способность прототипирования различных типов приложений.

Редактор позволяет создавать прототипы только веб-приложений и веб-сайтов.

.        Способность создания интерактивных прототипов.

Редактор позволяет создавать полностью интерактивные прототипы, благодаря способности создания связей типа «событие-действие».

.        Степень интерактивности.

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

.        Наличие набора компонентов.

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

.        Внешний вид прототипа.

Прототип представляет собой html-файл, выглядит реалистично.

.        Скорость создания прототипа.

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

.        Возможность просмотра прототипа без установки редактора.

Для просмотра прототипа установка редактора не требуется, используется веб-браузер.

Вторичные критерии:

.        Скорость работы редактора.

Редактор работает быстро, без продолжительных задержек и зависаний. Генерация прототипа также выполняется быстро.

.        Поддерживаемые платформы.2000, XP, 2003 Server, Vista, 7

.        Простота работы.

Для полноценного прототипирования необходима некоторая подготовка.

.        Удобство работы.

Интерфейс редактора интуитивно понятный, приятный, удобный.

.        Цена редактора.

Цена лицензии на 1 пользователя: от $6995.

.        Развитие редактора.

Редактор развивается, выпускаются обновления, но не часто.

.        Техническая поддержка.

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

.        Поддержка языков.

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

.        Требуется стороннее ПО.

Для просмотра прототипа требуется веб-браузер.

.        Дополнительные инструменты.

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

Вывод: мощный и удобный редактор для прототипирования веб-сайтов и веб-приложений со сложной функциональностью. Интерактивность прототипов высокая. Часть функционала приложения уникальна. Однако, не позволяет прототипировать десктоп-приложения. Стоимость редактора очень высокая.

.4.5 Microsoft Expression Blend

Редактор позволяет прототипировать графические интерфейсы SilverLight и WPF (Windows Presentation Foundation) приложений.

Первичные критерии:

.        Способность прототипирования различных типов приложений.

Редактор позволяет создавать прототипы интерфейсов как веб, так и десктоп-приложений с ограничением: только SilverLight и WPF приложения соответственно.

.        Способность создания интерактивных прототипов.

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

.        Степень интерактивности.

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

.        Наличие набора компонентов.

Имеется большой набор как нативных (воспринимающих дизайн операционной системы), так и платформо-независимых, детально настраиваемых компонентов.

.        Внешний вид прототипа.

Прототип запускается внутри приложения, выглядит реалистично.

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

.        Возможность просмотра прототипа без установки редактора.

Для просмотра прототипа требуется установка редактора.

Вторичные критерии:

.        Скорость работы редактора.

В работе редактора были зафиксированы замедления.

.        Поддерживаемые платформы.2000, XP, 2003 Server, Vista, 7

.        Простота работы.

Прототипирование сложное, требует обучения и подготовки.

.        Удобство работы.

Интерфейс редактора сложный и непривычный, требует привыкания.

.        Цена редактора.

Цена лицензии на 1 пользователя: $599.

.        Развитие редактора.

Редактор развивается, выпускаются обновления, но не часто.

.        Техническая поддержка.

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

.        Поддержка языков.

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

.        Требуется стороннее ПО.

Для просмотра прототипа стороннее ПО не требуется.

.        Дополнительные инструменты.

Редактор содержит полезный инструмент для создания карты связей интерфейсов. Автоматически генерируется программный код Visual Basic или Visual C#.

Вывод: мощный и удобный инструмент для прототипирования SilverLight и WPF

приложений со сложной функциональностью. Интерактивность и визуальная привлекательность прототипов - высокая. Часть функционала редактора уникальна. Однако, он не позволяет прототипировать приложения для других платформ. Сложен в освоении.

1.5 Результаты анализа

Результаты анализа специализированных редакторов графических интерфейсов показали, что не существует кроссплатформенного инструмента для прототипирования интерфейсов сложных веб и десктоп-приложений, который был бы способен покрыть требования, предъявляемые компанией «АЛЕЕ СОФТВЕР».

На основе данного анализа, с учётом преимуществ и недостатков существующих инструментов, был выработан список требований к разрабатываемому инструменту.

2. Требования к разрабатываемому инструменту

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

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

1.       Инструмент должен быть кроссплатформенным, должен работать, как минимум, на основных платформах: Windows, Linux, Mac OS.

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

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

.        Инструмент должен иметь широкий выбор готовых графических элементов. Должны присутствовать как платформо-зависимые (изменяющие свой внешний вид в зависимости от операционной системы и её оформления), так и платформо-независимые (нативные) компоненты. Должны присутствовать элементы для построения различных типов приложений: десктопных, веб-приложений и приложений для мобильных телефонов. Графические элементы должны быть детально настраиваемыми и максимально кастомизируемыми.

.        Прототип должен выглядеть как реальная работающая программа.

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

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

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

.        Контент прототипа должен быть способен содержать и корректно отображать символы национальных алфавитов, в том числе - русского.

.        Язык интерфейса: русский и английский.

Дополнительное требование: представить клиент-серверное Enterprise решение, которое позволит обеспечить совместную работу над проектом и организовать единое информационное пространство для всех участников проекта. Требование возникло для возможности реализации проектов, в которых задействовано несколько компаний, зачастую разделённых территориальными, временными, языковыми, поведенческими и культурными барьерами.

3. Существующие разработки

Основной продукт компании «АЛЕЕ СОФТВЕР» - корпоративная информационная система класса ERM (Enterprise Record Manager - система управления электронными записями). Система включает в себя два тонких клиента, через которые работают пользователи системы: десктопное (настольное) и веб.

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

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

На ранней стадии разработки выяснилось, что на Java версии 1.4 (на тот момент) выполнить поставленную задачу не удастся по следующим причинам:

ñ  низкая скорость интерпретации Java классов в нативный код Java-машиной на проектах большого размера, что очень сильно снижало общую скорость работы приложения (что совсем не позволительно для приложений ориентированных на проектирование интерфейсов);

ñ  отсутствие привычных нативных компонентов различных операционных систем в стандартной сборке JDK - лишь стандартный Java стиль (отдельные библиотеки, конечно, позволяли подключать что-то дополнительно, но их качество и цены были неприемлемыми);

ñ  отсутствие в самом языке многих удобных инструментов давно уже существовавших на тот момент в других популярных языках программирования (например, таких как: типизированные списки, generics), что весьма затрудняло использование языка для написания подобного инструмента.

В итоге было принято решение отложить разработку до момента достижения технологиями требуемого уровня. Для кастомизации веб-интерфейса системы было разработано альтернативное решение.

Описание разработок

Разработки представляли собой платформу для создания базового инструмента. Было создано запускаемое приложение, включающее:

·        область редактирования графического интерфейса

·        минимальный набор компонентов для тестирования графического редактора

·        отдельный фрейм для управления слоями

·        отдельный фрейм для настройки компонентов

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

Существующие разработки были написаны на языке программирования Java. Java-приложения компилируются в байт-код и могут работать на любой операционной системе, поддерживающей Java-машину (JVM), независимо от компьютерной архитектуры. Практически все современные платформы поддерживают Java-машины и, как следствие, могут исполнять Java-приложения (зачастую, для известных операционных систем имеются множества Java-машин различающиеся версией поддерживаемого языка, архитектуры и настройками, позволяющими оптимизировать работу приложения). Благодаря этому, в разработках уже было выполнено первое требование: кроссплатформенность.

4. Перечень функций для реализации

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

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

1.       Значительное расширение набора компонентов, добавление всех типовых (стандартных) элементов интерфейса:

·   кнопка (button);

·        список (list box);

·        раскрывающийся список (combo box);

·        флажок/переключатель (check box);

·        радио-кнопка (radio button);

·        поле редактирования (textbox, edit field);

·        значок (icon);

·        панель инструментов (toolbar);

·        строка состояния (status bar);

·        всплывающая подсказка (tooltip, hint);

·        полоса прокрутки (scrollbar);

·        вкладка (tab);

·        элемент для отображения табличных данных (grid view);

·        меню (menu):

Ø  главное меню окна (main menu);

Ø  контекстное меню (popup menu);

·   окно (window):

Ø  панель (panel);

Ø  диалоговое окно (dialog box);

Ø  модальное окно (modal window);

·   дерево - элемент для отображения иерархии (tree view).

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

Элементы интерфейса должны быть платформо-зависимыми, т.е. должны принимать оформление (дизайн) той операционной системы, на которой запущено приложение. В этом случае будет достигнуты высокие визуальные качества компонентов.

Для обеспечения возможности проектирования интерфейсов веб-приложений и приложений для мобильных телефонов необходимо добавить специализированные наборы компонентов. Эти элементы интерфейса должны быть платформо-независимыми (кроссплатформенными).

2.       Добавление механизма, позволяющего создавать интерактивные прототипы: при свершении определённого настраиваемого события должно автоматически выполняться определённое настраиваемое действие.

Список обрабатываемых событий:

·   нажатие кнопки;

·        получение/потеря фокуса объектом;

·        изменение состояние выбора объекта;

·        выбор элемента списка;

·        события мыши:

Ø  клик по объекту;

Ø  нажатие кнопки мыши;

Ø  отпускание кнопки мыши;

Ø  вход курсора мыши в область объекта;

Ø  выход курсора мыши из области объекта;

Ø  прокрутка колёсика мыши;

·   выбор ячейки таблицы;

·        закрытие окна;

·        выбор таба;

·        выделение элемента дерева;

·        истечение времени.

Список выполняемых действий:

·   блокировка/разблокировка объекта;

·        изменение контента объекта;

·        изменение видимости объекта;

·        вставка объекта в указанную область лэйаута;

·        очищение указанной области лэйаута;

·        открытие/закрытие окна;

·        выполнение клика;

·        выбор таба.

3.       Значительное расширение набора настраиваемых свойств объектов для их детальной кастомизации.

Свойства объекта - это совокупность его атрибутов, однозначно определяющих его тип, дизайн (внешний вид) и поведение.

Часть свойств объекта должна быть неизменяемой (должна иметь исключительно информативный характер):

·   тип объекта (автоматически задаётся при создании объекта и изменению не подлежит);

·        ID объекта - свойство объекта с уникальным значением, идентифицирующим его в проекте.

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

4.       Добавление истории.

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

5.       Добавление механизма создания и использования шаблонов.

Шаблон - заранее подготовленный макет часто используемых объектов или интерфейсов.

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

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

Шаблоны должны разделяться на два типа:

·   шаблоны компонента;

·        пользовательские шаблоны.

Шаблоны компонента - различные представления, макеты определённого компонента.

Пользовательские шаблоны - макеты любых интерфейсов.

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

6.       Создание отдельного инструмента для просмотра созданных прототипов в интерактивном режиме.

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

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

7.       Добавление инструмента для создания снимков (скриншотов) интерфейсов.

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

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

Части проекта должны быть представлены в виде страниц проекта аналогично тому, как это реализовано во многих различных редакторах (например, в Microsoft Excel). Должна быть возможность создания, задания и изменения имени, удаления и просмотра списка страниц.

9.       Добавление возможности настройки приложения.

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

·   язык интерфейса приложения;

·        объём выделяемой под приложение оперативной памяти;

·        периодичность автосохранения;

·        параметры сети и подключения к интернету;

·        настройки области редактирования (размер области, настройки сетки, настройки навигации по области);

·        настройка просмотра прототипов;

·        настройка свойств компонентов по умолчанию.

10.     Добавление возможности настройки проекта.

Должна быть возможность просмотра или изменения следующих настроек проекта:

·   название;

·        владелец;

·        описание;

·        статистика (количество объектов и действий, количество страниц, размер проекта, даты создания и изменения).

11.     Добавление поиска по проекту.

Должен быть добавлен быстрый поиск по всем объектам проекта и их свойствам, по событиям и действиям.

12.     Перевод приложения на английский язык.

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

13.     Увеличение быстродействия приложения.

В существовавших разработках было зафиксировано несколько случаев замедления работы приложения (значительное увеличение времени отклика программы):

·   При добавлении на область редактирования большого количества объектов (больше двухсот) заметно замедлялась навигация.

·        При многократном сохранении проекта скачкообразно увеличивается объём оперативной памяти, используемый приложением. При достижении верхнего предела диапазона выделенной под приложение оперативной памяти программа критически замедлялась (отклик на простейшие действия составлял от нескольких секунд до нескольких десятков секунд).

Принимая во внимание существующие проблемы и проанализировав случаи замедления других редакторов, были вынесены следующие требования к быстродействию:

·   Навигация по области редактирования прототипа должна выполняться без замедления в любых случаях, в том числе при наличии большого количества объектов на области. Любое замедление навигации делает работу в крайней степени некомфортной, поскольку это наиболее часто используемая операция при работе над проектом.

·        Должны быть исключены все случаи некорректного роста объёма используемой приложением оперативной памяти.

·        Сохранение любого проекта не должно длиться более 10 секунд и, тем более, не должно приводить к зависанию приложения.

·        Запуск любого прототипа в просмотр не должен длиться более 10 секунд.

·        Запущенный в просмотр прототип должен работать быстро, без замедлений. Предзаданные действия должны выполняться мгновенно после свершения определённых событий.

14.     Добавление инструмента для редактирования используемых в проекте изображений.

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

Встроенный графический редактор должен иметь, как минимум, следующие инструменты:

·   карандаш для рисования линий;

·        заливка для заполнения цветом областей;

·        ластик для точечного очищения;

·        инструмент для очищения областей;

·        кадрирование для обрезки изображения;

·        инструменты для изменения размера изображения или его области.

После реализации перечисленных выше пунктов для того, чтобы приложение обрело статус продукта, потребуется:

1.       Написание руководства пользователя инструмента.

Несмотря на то, что планировалось создание максимально простого и интуитивного инструмента прототипирования, он, ввиду своей специфики, может иметь сложную функциональность и в любом случае должен быть снабжён руководством пользователя. Для начала, оно должно быть на русском и английском языках, в перспективе - на других наиболее популярных языках: немецком, французском, китайском.

2.       Защита от нелегального копирования и распространения приложения.

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

3.       Создание демо (триальной) версии приложения.

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

4.       Обфускация - запутывание кода программы для того, чтобы его невозможно было декомпилировать с целью изменения или незаконного использования.

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

В качестве основы способа разработки была выбрана методика экстремального программирования (Extreem Programming, XP). Выбор был обусловлен следующими причинами:

·        компания требовала появления рабочего инструмента как можно раньше; XP предоставляет такую возможность;

·        требования к инструменту добавлялись и менялись уже в ходе реализации, так как одновременно с ней продолжалось проведение анализа существующих инструментов проектирования и прототипирования графических интерфейсов;

·        ограниченность в команде;

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

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

От других методик ХР отличается по следующим признакам:

·        Благодаря использованию коротких циклов разработки ХР предлагает быструю, реальную и постоянно функционирующую обратную связь.

·        В рамках ХР используется планирование по нарастающей, в результате общий план проекта возникает достаточно быстро, однако при этом подразумевается, что этот план эволюционирует в течение всего времени жизни проекта - игра в планирование (planning game). Она быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.

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

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

·        Система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи.

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

·        ХР основана на оральном обмене информацией, тестах и исходном коде. Три этих инструмента используются для обмена сведениями о структуре системы и ее поведении.

·        ХР базируется на процессе эволюционирующего дизайна, который продолжается столь же долго, сколько существует сама система.

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

Основным отличием от первоначальной методики стало наличие в команде проекта одного программиста. Соответственно не выполнялись требования попарного программирования и взаимной проверки кода. В остальном предписания XP выполнялись.

На начальном этапе реализации системы уже имелась рабочая версия приложения (существовавшие разработки). Разработка шла в тесном взаимодействии программиста, заказчика и пользователей системы. Использовались кратчайшие циклы разработки: ежедневно и даже несколько раз в день обсуждались ближайшие изменения программы, выпускались новые версии, тестировались. В течение всего этапа реализации избегались сложные изменения, внесение которых занимало бы продолжительный период (более трёх дней) - они делились на несколько намного более простых. Изменения, которые по той или иной причине не могли быть реализованы на конкретный момент, откладывались на более поздние версии. Список требований изменялся и пополнялся новыми требованиями, появлявшимися в ходе разработки. Таким образом, план проекта постоянно эволюционировал и обновлялся. Ещё до выпуска релизной версии программы она уже полноценно использовалась в различных проектах внутри компании. Разработка дизайна приложения откладывалась на самые поздние версии. Большинство промежуточных версий имели простой дизайн. Благодаря этому, удалось избежать ошибок, связанных со сложным дизайном, и, соответственно, ненужных и необязательных задержек. Работа была сфокусирована на реализации функционала.

6. Реализация

.1 Сроки реализации

Дата начала реализации: 22 октября 2009 года. Получив полную картину требований и приблизительно оценив длительность выполнения задач, был поставлен ориентировочный срок выпуска релизной версии продукта: 1 октября 2010 года. Однако, благодаря выбору способом разработки методики экстремального программирования, уже в мае 2010 года функциональность и надёжность инструмента достигла такого уровня, что он был опробован для прототипирования графического интерфейса сложного веб-приложения на реальном проекте компании и показал свою состоятельность. Это подтверждает и доказывает верность выбора XP способом разработки.

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

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

.2 Структурирование требований

Учитывая выработанные требования к разрабатываемому программному продукту, существовавшие разработки и схему реализации (XP - поэтапный итерационный способ разработки), на начальном этапе необходимо было определить последовательность реализации требований. Все требования были отсортированы с учётом их важности и взаимозависимости (некоторые требования невозможно было реализовать до выполнения других требований).

Требования были внесены в систему отслеживания ошибок (bag tracking system) для обеспечения быстрого взаимодействия участников команды проекта и структурирования требований. Для этого была использована внедрённая в компании система JIRA. Она уже активно использовалась в других проектах компании, все участники были обучены работе с ней, так что трудностей или задержек не возникало. Помимо требований, в систему вносились найденные в ходе использования и тестирования программы ошибки. Запросы могли иметь различный приоритет в зависимости от важности и критичности. Таким образом, была организована единая информационная среда, доступная всем участникам проекта в любой момент времени.

.3 Реализация базовой функциональности

.3.1 Добавление компонентов

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

На начальном этапе было реализовано только несколько наиболее часто используемых и простых компонентов: окно, лэйауты, панели, кнопки, текстовый ярлык, поля для ввода текста, чек-бокс и радио-кнопка, представленные на рисунке 4.

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

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

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

После наполнения набора компонентов для десктопных компонентов была поставлена задача добавления компонентов для веб-приложений. Для этого был использован фреймворк Vaadin. Выбор объясняется двумя причинами:

·        во-первых, компоненты Vaadin на тот момент уже активно использовались нашей компанией при разработке веб-интерфейсов систем, программист имел опыт работы с ними;

·        во-вторых, компоненты Vaadin обладают красивым и приятным дизайном.

Фрейм, хранящий компоненты, был представлен в виде дерева: компоненты (листья дерева) были распределены по группам (узлам дерева) Также появился альтернативный краткий вид представления компонентов. Оба вида фрейма представлены на рисунке 8.

.3.2 Структуризация интерфейсов

Разрабатываемое приложение должно было обеспечивать прототипирование сложных приложений. Их интерфейсы, как правило, состоят из нескольких логических частей. Намного удобнее и проще прототипировать эти логические части по отдельности, объединяя их впоследствии в единый прототип. Для обеспечения такой возможности был добавлен специальный компонент - заменитель объектов, применение которого показано на рисунке 9.

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

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

.3.3 Расширение набора свойств

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

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

Фрейм, отображающий свойства компонента, стал содержать 2 набора: стандартные свойства - одинаковые для всех компонентов, и свойства, присущие только конкретно данному компоненту, как показано на рисунке 10.

Для настройки сложных компонентов были созданы отдельные редакторы:

·        редактор таб-панели;

·        редактор таблицы;

·        редактор дерева;

·        редактор списка;

·        редактор чек-бокса;

·        редактор всплывающего меню;

·        редактор меню-бара.

Редакторы позволяют детально кастомизировать сложные компоненты. Они построены аналогично, в связи с чем для примера будет показан на рисунке 11 только редактор таб-панели.

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

Для редактирования свойств, значением которых является текст, в приложение был встроен полноценный HTML редактор, представленный на рисунке 12.редактор позволяет применять к тексту HTML-оформление (от англ. HyperText Markup Language - «язык разметки гипертекста»). Он предназначен для составления, редактирования и форматирования текста. Достоинство редактора заключается в высокой функциональности и простом, привычном интерфейсе. После редактирования текста есть возможность просмотреть автоматически сгенерированный HTML код, который может быть в перспективе использован при реализации системы.

Этот инструмент также редко встречается в инструментах прототипирования, несмотря на свою полезность. HTML редактор стал ещё одним значимым преимуществом разрабатываемого приложения.

.3.4 Действия

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

Описание механизма

Механизм был реализован следующим образом: для создания действия, которое будет срабатывать при просмотре прототипа в интерактивном режиме, необходимо выбрать объект события и объект действия. Для первого объекта выбирается событие из списка, которое инициирует свершение действия. Для второго объекта выбирается действие из списка, которое свершается при срабатывании события. Пример создания действия показан на рисунке 13.

Событиями могут являться события мыши, изменение фокуса объекта, изменение свойства объекта. Действиями могут быть изменение свойств объекта, открытие/закрытие окон, установка связей между объектами.

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

.3.5 Просмотр в интерактивном режиме

Для введения инструмента в промышленное использование требовалось создать механизм для просмотра прототипа в режиме реального времени. Реализован он был следующим образом:

·        Прототип запускается в отдельном независимом окне. Благодаря этому, прототип выглядит и работает как реальное работающее приложение.

·        В просмотр одновременно может быть запущено несколько прототипов.

·        В просмотр могут быть запущены как прототипы целиком, так и их части, и даже отдельные объекты.

Механизм получился намного более удобным и мощным, чем у существующих средств прототипирования.

6.4 Эксплуатация

На этот момент (май 2010 года) приложение было в достаточной степени наполнено функционалом, чтобы его можно было пускать в промышленное использование.

На данном этапе было принято решение о начале использования инструмента для внутренних разработок.

Таким образом, с данного момента параллельно шло 2 процесса, как показано на рисунке 14:

·        реализация;

·        эксплуатация.

Реализация и эксплуатация связаны друг с другом следующим образом: при эксплуатации инструмента появляются новые требования к нему, предложения по улучшению и обнаруживаются ошибки; процесс реализации вносит исправления в инструмент и выпускает новые версии, которые затем передаются на эксплуатацию.

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

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

Развитие прототипа происходило в тесном взаимодействии с заказчиком проекта. Заказчик - крупная межнациональная компания, постоянный и надёжный клиент «АЛЕЕ СОФТВЕР». Компания заказчика специализируется на продаже оборудования для мясоперерабатывающих комбинатов. Ввиду специфики деятельности, большую часть сотрудников компании составляют менеджеры по продаже оборудования. CRM система - основная система, используемая ими в своей работе. По этой причине заказчик крайне требователен к качеству графического пользовательского интерфейса этой системы. В ходе использования CRM-системы приходилось неоднократно изменять и модифицировать систему по запросу заказчика.

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

Он содержит 4092 объектов, 1380 действий, 575 изображений. На рисунках 15 и 16 представлены скриншоты прототипа.

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

Созданный прототип:

·        повысил степени удовлетворённости заказчика;

·        поспособствовал принятию им положительного для нашей компании решения;

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

·        позволил обнаружить несколько проблем, ошибок и недостатков инструмента.

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

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

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

Разработанный прототип стал главной предпосылкой принятия решения о начале реализации внутрикорпоративного портала.

.4.3 Другие проекты

GUI Designer также был использован в некоторых других проектах:

·        Разработка прототипа веб-приложения «Национальный удостоверяющий центр электронно-цифровых подписей», скриншот которого показан на рисунке 19.

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

·        Разработка прототипа веб-приложения для конфигурирования системы WebStorm (внутренняя разработка), скриншот которого показан на рисунке 20.

Промышленная эксплуатация инструмента:

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

·        дала ощутимый толчок развитию инструмента;

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

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

.5 Реализация расширенной функциональности

Для того, чтобы инструмент стал полноценным, более удобным и функциональным было реализованы:

·        История - механизм, позволяющий запомнить (сохранить) последовательность операций, выполненных пользователем, и вернуться к любому предыдущему состоянию проектного файла, кликнув по записи, соответствующей операции, до которой необходимо откатится.

·        Менеджер страниц - механизм, позволяющий делить проект на несколько частей (страниц). Он позволил располагать логические части прототипа или отдельный интерфейсы на разных страницах.

·        Менеджер шаблонов - механизм для управления шаблонами. Шаблон - заранее подготовленный макет часто используемых объектов или интерфейсов.

·        Менеджер скриншотов - механизм для быстрого создания скриншотов интерфейсов, незаменимый при разработке технического задания.

·        Поиск по проекту.

·        Настройки инструмента и настройки проекта, позволяющие детально кастомизировать инструмент и изменять параметры проекта.

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

.5.1 Pixel Grabber

При помощи Pixel Grabber можно определить цвет любой точки экрана в формате RGB. Pixel Grabber очень прост и удобен в использовании. Вид инструмента представлен на рисунке 21.

.5.2 Редактор изображений

Во время эксплуатации приложения часто приходилось рисовать и изменять иконки для прототипов. Сначала это выполнялось при помощи сторонних редакторов. Это было неудобно и занимало большое количество времени. Для решения этой проблемы был реализован и встроен в программу редактор изображений, получивший название Image Editor.editor содержит наиболее востребованные и популярные инструменты редактирования изображений, что показано на рисунке 22.

Редактор позволяет быстро и просто отредактировать изображение, изменить его размер, объединить и сохранить несколько изображений в одном. Для удобства работы инструмент снабжён историей (в правой части окна). С его помощью в любой момент имеется возможность вернуться к первоначальному состоянию изображения.

.6 Подготовка продукта и выпуск релиза

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

6.6.1 Языковая корректировка

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

.6.2 Интерфейс приложения

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

Интерфейс программы был сильно видоизменён, освободилось много пространства, был обновлён дизайн. Этап занял продолжительный период времени, однако был необходим.

.6.3 Тестирование

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

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

.6.4 Обфускация

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

Цели обфускации:

·        Оптимизация программы с целью уменьшения размера работающего кода и (если используется некомпилируемый язык) ускорения работы.

·        Затруднение декомпиляции проприетарных программ с целью предотвращения обратной разработки или обхода DRM и систем проверки лицензий.

·        Предотвращение нарушения авторских прав.

.6.5 Выпуск релиза

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

.7 Итоги реализации

.7.1 Функциональная схема инструмента

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

Совокупность функциональных модулей инструмента представлена в виде схемы на рисунке 23:

Модули, выделенные фиолетовой границей, встроены в инструмент и являются неотъемлемой его частью. Модули с оранжевой границей - Pixel Grabber и GUI Machine Viewer - также встроены в инструмент, но в то же время могут быть запущены независимо от него.

6.7.2 Отчёт системы отслеживания ошибок

За всё время реализации продукта в системе отслеживания ошибок было создано 630 запросов, распределённых по типам так, как показано на рисунке 24 и отображено в таблице 3.

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

Таблица 3 - Распределение запросов по типам

Распределение запросов по приоритету показано на рисунке 25 и отображено в таблице 4.

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

Таблица 4 - Распределение запросов по приоритету

6.7.3 Нерешённые проблемы

В релизной версии продукта не были реализованы некоторые требования и присутствовали проблемы.

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

7. Проведение семинара

Следствием разработки инструмента с использованием методики экстремального программирования, выпуска релизной версии, а также использования инструмента в проектах компании «АЛЕЕ СОФТВЕР» стало проведение семинара «Проблемы и решения проектирования и прототипирования графических пользовательских интерфейсов» 24 января 2011 года. На семинаре был впервые представлен разработанный инструмент под названием GUI Machine, в том числе:

·        проведено сравнение GUI Machine с конкурентами;

·        проведён мастер-класс по созданию прототипа в GUI Machine;

·        представлены созданные для проектов компании прототипы.

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

8. Технико-экономическое обоснование разработки научно-технического продукта

.1 Концепция экономического обоснования разработки научно-технического продукта

Целью дипломного проекта является создание инструмента проектирования и прототипирования графических пользовательских интерфейсов сложных информационных систем на базе разработок компании «АЛЕЕ СОФТВЕР». Причиной возникновения задачи разработки продукта является неспособность существующих инструментов покрывать требования компании по дизайну и функциональности создаваемых прототипов. Кроме того, предпосылкой создания собственного инструмента стала привлекательность рынка.

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

Цель экономического обоснования проекта: доказательство эффективности принятого решения о необходимости разработки программного продукта, а также оценка экономической привлекательности дипломного проекта.

.2 Потребительские свойства научно-технического продукта

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

Таблица 5 - Технико-экономические параметры проектируемой продукции

Выгоды, которые может получить потребитель от использования разрабатываемого продукта по сравнению с существующими:

ñ высокая степень интерактивности прототипов позволит детально описывать функциональность проектируемой системы;

ñ  доступно прототипирование как десктопных, так и веб приложений;

ñ  работа с любыми из наиболее популярных платформ, нет необходимости приобретать новую операционную систему;

ñ  простая работа, навыки программирования не требуются.

8.3 Рынок и план маркетинга

а) Сегментирование рынка

Рынок инструментов проектирования и прототипирования графических пользовательских интерфейсов:

·        новый: возраст менее 7 лет;

·        растущий, динамично развивающийся: большое количество компаний находятся в поисках удовлетворяющего инструмента прототипирования;

·        разреженный, неполный, неизбыточный: на рынке представлено не более 15 продуктов, среди которых отсутствуют Российские разработки;

·        свободный: нет ограничений или особых требований для вывода продукта на рынок

Группы потенциальных покупателей и анализ их требований к продукции, реализуемой на рынке:

·        Компании - разработчки программных продуктов. Предъявляемые требования: прототипирование различных типов приложений, высокая скорость создания прототипа, высокая степень интерактивности прототипов.

·        Компании - разработчики веб-сайтов, интернет порталов: веб-студии, дизайн-студии, юзабилити лаборатории. Предъявляемые требования: прототипирование веб-сайтов, реалистичный внешний вид, низкая цена.

·        Компании - внедренцы корпоративных информационных систем, интеграторы. Предъявляемые требования: прототипирование различных типов приложений, высокая степень интерактивности прототипов, реалистичный внешний вид.

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

Группировка потенциальных покупателей в рыночные сегменты:

·        Сегмент 1. Разработчиками программных продуктов, внедренцами корпоративных информационных систем и потребителями информационных систем предъявляются схожие требования. Это крупные компании, перед которыми стоят сложные и очень сложные задачи, готовые заплатить значительную цену за высококачественный инструмент, покрывающий их требования. Спрос на продукцию: высокий.

·        Сегмент 2. Требования, предъявляемые разработчиками веб-сайтов, отличаются. Это небольшие компании, разрабатывающие сайты, не обладающие сложной функциональностью. Большее внимание они уделяют дизайну. Высокую цену платить не готовы. Спрос на продукцию: средний.

б) Выбор целевого сегмента рынка

Разрабатываемый продукт покрывает требования сегмента 1, но не покрывают требования сегмента 2.

Барьеров при входе на сегмент 1 нет.

Барьеры при входе на сегмент 2: неспособность платить высокую цену, нежелание отступать от традиционных, устоявшихся средств проектирования интерфейсов, осваивать новый инструмент, перестраивать внутренние процессы.

Наиболее привлекательным является сегмент 1:

·        с высокой платёжеспособностью;

·        предъявляющий требования, реализованные в разрабатываемом продукте;

·        без барьеров при входе.

в) Выбор ценовой политики и оценка ожидаемых объемов продаж

Рынок сильно фрагментирован ценам на продукцию. Цена большинства продуктов на рынке не выше 20 000 рублей. В то же время цена одного продукта, предлагающего клиент-серверное решение, выше 200 000 рублей. Поскольку разрабатываемый продукт превосходит существующие инструменты по функциональности и другим характеристикам, но в то же время на данный момент не предлагает клиент-серверного решения, было принято решение занять промежуточную позицию в 1599 евро или приблизительно 63960 рублей. Дополнительной предпосылкой стала высокая платёжеспособность целевого сегмента. При установке заниженной цены, впоследствии было бы крайне тяжело её поднимать. Завышенную цену без клиент-серверного решения устанавливать бессмысленно.

г) Сбыт новой продукции

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

Сложившиеся каналы сбыта (заказчики и партнёры компании) необходимо комбинировать с новыми (крупные разработчики, внедренцы, интеграторы, потребители информационных систем).

д) Продвижение товара

Для продвижения товара требуется произвести ряд маркетинговых операций и мероприятий:

·        разработка сайта продукта;

·        разработка системы скидок;

·        поиск, регистрация и активное участие в тематических интернет сообществах и конференциях;

·        предоставление бесплатной технической поддержки на 1 год при покупке лицензии;

·        создание видео-уроков;

·        проведение тематических конференций;

·        разработка демонстрационной версии приложения;

·        разработка демонстрационных проектов;

·        размещение контекстной рекламы в поисковых сервисах;

·        размещение приложения в крупнейших программных архивах.

.4 Производство продукта

.4.1 Расчёт затрат на производство

Затраты на производство продукта состоят из:

·        переменных затрат;

·        постоянных затрат.

Переменные затраты составляют большую часть затрат на производство и состоят в данном проекте только из оплаты труда специалистов.

Ввиду специфики выбранного способа разработки основной объём работ распределяется между программистом и менеджером проекта. Они вовлечены в разработку в течение всего рабочего времени. Все работы производились с их участием. На различных этапах развития продукта часть работ выполнялась с привлечением других специалистов. В связи с этой особенностью в переменные затраты включается заработная плата программиста и менеджера проекта за всё время разработки проекта без расчёта их часовой тарифной ставки и трудоёмкости выполнения операций.

Расчёт этих затрат осуществляется по формуле:

Зс2 = Зпрог + Змен ,                                                                      (1)

где Зс2 - суммарная заработная двух специалистов за весь период разработки, Зпрог и Змен - суммарная заработная плата программиста и менеджера проекта соответственно за весь период разработки, которая рассчитывается по формуле:

Зi = Зi мес • tразр ,                                                                (2)

где Зi мес - заработная плата специалиста в месяц, tразр - период разработки.

Период разработки: с 22 октября 2009 года по 1 декабря 2010 года - 13 полных месяцев и 10 дней. Если учесть среднюю длину месяца в невисокосном году в днях:

Дв мес = Дв году/Мв году = 365/12 ≈ 30,42,                                  (3)

то период разработки равен:

разр = 13 + 10/Дв мес ≈ 13,33.                                              (4)

Расчёт затрат на оплату труда программиста и менеджера проекта сведён в таблицу 6:

Таблица 6 - Расчёт затрат на оплату труда программиста и менеджера проектов

Расчёт затраты на оплату труда других специалистов с учётом их часовой тарифной ставки и затраченного времени сведён в таблицу 7:

Таблица 7 - Расчёт затрат на оплату труда других специалистов

Итого суммарная оплата труда всех специалистов Зсум , задействованных в производстве программного продукта, составляет 642190 рублей

Отчисления на социальные нужды определяются по формуле:

                                                                           (5)

где  - размер страховых взносов, равный на момент разработки 26,02%.

                                                        (6)

Итого переменных затрат: 809288 рублей

Постоянные затраты

Затраты на оборудование:

Персональный компьютер: 30000 рублей

Затраты на использованные программные библиотеки:

JIDE: 27000 рублей

Покупка доменных имён guimachine.ru, gui-machine.ru, gui-machine.com:

рублей

Проведение конференции «Проблемы и решения проектирования и прототипирования пользовательских интерфейсов»:

рублей