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

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. Реализация

6.1 Сроки реализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для редактирования свойств, значением которых является текст, в приложение был встроен полноценный HTML редактор, представленный на рисунке 12.

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

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

6.3.4 Действия

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

Размещено на http://www.allbest.ru/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Размещено на http://www.allbest.ru/

6.4.3 Другие проекты

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

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

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



Размещено на http://www.allbest.ru/

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



Размещено на http://www.allbest.ru/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5.1 Pixel Grabber

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



Размещено на http://www.allbest.ru/

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

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

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



Размещено на http://www.allbest.ru/

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

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

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

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

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

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

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

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

6.6.3 Тестирование

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

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

6.6.4 Обфускация

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

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

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

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

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

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

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

6.7 Итоги реализации

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

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

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

Размещено на http://www.allbest.ru/

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

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

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

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

Размещено на http://www.allbest.ru/

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

Тип	Запросы	%
Улучшение функциональности	310	49%
Ошибка	226	35%
Запрос на новую функциональность	70	11%
Проблема с программой или операционной системой	18	2%
Личный вопрос или заявление	5	0%
Sub-task	1	0%

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

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

Размещено на http://www.allbest.ru/

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

Приоритет	Запросы	%
6	329	52%
8	171	27%
7	68	10%
10	42	6%
9	15	2%
НЕМЕДЛЕННО	5	0%



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

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

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



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

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

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

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

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

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



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

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

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

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

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

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

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

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

Наименование технико-эксплуатационного параметра продукции	Единица измерения	Проектируемая продукция	Наименование (марка) существующей продукции
			Axure RP	GUI Design Studio	iRise	Microsoft Expression Blend
Тип проектируемых приложений	веб, десктоп	веб, десктоп	веб	веб, десктоп	веб	десктоп
Возможность создания интерактивных прототипов	да, нет	да	да	да	да	да
Степень интерактивности прототипов	высокая, средняя, низкая	высокая	средняя	низкая	высокая	высокая
Наличие набора компонентов	есть, нет	есть	есть	есть	есть	есть
Внешний вид прототипа	Реалистичный, нереалистичный	реалистичный	реалистичный	не реалистичный	реалистичный	реалистичный
Скорость создания прототипа	Высокая, средняя, низкая	высокая	средняя	высокая	низкая	низкая
Возможность просмотра прототипа без установки программы	да, нет	да	да	да	да	нет
Поддерживаемые платформы	Windows, Mac OS, Unux, другие	Windows, Mac OS, Unix	Windows, Mac OS	Windows	Windows	Windows
Скорость работы приложения	высокая, средняя, низкая	высокая	высокая	средняя	средняя	низкая
			Axure RP	GUI Design Studio	iRise	Microsoft Expression Blend
Простота работы	высокая, средняя, низкая	высокая	средняя	высокая	средняя	низкая
Удобство работы	высокое, среднее, низкое	высокое	высокое	среднее	высокое	среднее
Цена	Рубль РФ	63960	17670	14970	209850	17970

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Специалист	Зi мес , заработная плата в месяц (рублей)	tразр , период разработки (месяцев)	Суммарные затраты (рублей)
Программист	25 000	13,33	333 250
Менеджер проекта	18 000		239 940
Всего	573190



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

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

Специалист	Часовая тарифная ставка (рублей/час)	Затрачено времени (часов)	Суммарные затраты (рублей)
Технический директор	250	40	10000
Коммерческий директор	400	40	16000
Маркетолог	100	100	10000
Тест-лидер	150	100	15000
Тестировщик	100	100	10000
Дизайнер	100	80	8000
Всего	69000

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

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

(5)

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

(6)

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

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

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

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

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

JIDE: 27000 рублей

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

10000 рублей

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

40000 рублей

Размещение контекстной рекламы на yandex.ru и google.com

10000 рублей

Итого постоянных затрат: 117000 рублей

Суммарные затраты: 926288 рублей

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

, (7)

где - выручка от реализации продукции в t-м интервале; - объем продаж продукции в в t-м интервале; - цена продукции в в t-м интервале.

Продажа программного обеспечения при передаче в нематериальном виде и заключении двухстороннего договора НДС не облагается.

Налог на прибыль составляет 24%.

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



Таблица 8 -- Производственно-сбытовые издержки

Специалист	Заработная плата в месяц (рублей)	Интервал (месяцев)	Суммарные затраты (рублей)
Программист	25 000	6	150 000
Менеджер проекта	18 000		108 000
Всего	258000

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

(8)

где - ставка единого социального налога, равная с 2011 года 34%

(9)

Итого производственно-сбытовые издержки за период в 6 месяцев (полугодие):

345720 рублей

8.4.2 Финансовые результаты проекта

Финансовые результаты проекта сведены в таблице 9.

Таблица 9 -- Финансовые результаты проекта

№ п/п	Наименование показателей	Интервалы (полугодие)
		1	2	3	4
1.	Объем продаж, шт.	20	30	40	50
2.	Цена реализации	23960	63960	63960	63960
3.	Выручка от реализации продукции	479200	1918800	2558400	3198000
4.	в том числе НДС	0	0	0	0
5.	Выручка от реализации без НДС	479200	1918800	2558400	3198000
6.	Производственно-сбытовые издержки, всего	345720	345720	345720	345720
7.	Прибыль от реализации продукции	133480	1573080	2212680	2852280
8.	Налог на прибыль	32035	377539	531043	684547
9.	Прибыль	101455	1195541	1681637	2167733

За 2 года прибыль составит:

5146366 рублей

8.5 Экономическая эффективность проекта

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

с рентабельность инвестиций;

с период возврата (срок окупаемости) инвестиций;

с чистая современная стоимость проекта;

с внутренняя рентабельность проекта.

Показатель рентабельности инвестиций (ROI - Return Оn Investments) определяется как отношение среднегодовой прибыли к суммарным инвестиционным затратам в проект:

, (10)

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

ROI = 2,04 > 1 (11)



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

ТОК = 1 год (12)

Расчёт чистой современной стоимости (дисконтированного дохода) проекта за 2 года.

, (13)

где I - единовременные затраты, совершаемые в инвестиционном (нулевом) интервале;

+At - чистый денежный поток с учётом амортизации. (14)

Амортизации подлежит оборудование в виде 1 компьютера стоимостью 30000 рублей. Нормативный срок использования оборудования: 5 лет. Соответственно, годовая амортизация составляет 6000 рублей. Амортизация последнего года инвестиционного периода включает остаточную стоимость оборудования.

С учётом принятой для оценки анализируемого проекта ставки дисконтирования R=0,2 чистая современная стоимость:

NPV = 2 849 382 рублей (15)



Положительное значение NPV свидетельствует о целесообразности принятия решения о финансировании и реализации проекта.

Показатель внутренней рентабельности проекта (IRR - Internal Rate of Return) определяет такую ставку дисконта, при которой дисконтированная стоимость поступлений денежных средств по проекту равна дисконтированной стоимости платежей:

, (16)

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