24.

Диалог управления маршрутами

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

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

25.

Взаимосвязь элементов маршрута и графических примитивов

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

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

26.

Тестирование имеющейся функциональности под управлением ОС МСВС

Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.

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

27.

Диалоги создания специальных маневров

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

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

28.

Управление маршрутами, содержащими специальные маневры

Посредством диалогового окна управления маршрутами производится редактирование маршрутов, содержащих ХТТ, созданные автоматически.

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

29.

Тестирование имеющейся функциональности под управлением ОС МСВС

Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.

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

30.

Компиляция и утечки памяти

Компиляция модулей подсистемы под управлением ОС: Microsoft Windows XP, МСВС 3.0. Исследование подсистемы на наличие утечек памяти.

Модули подсистемы должны компилироваться без предупреждений при использовании компилятора интегрированной среды разработки Microsoft Visual C++ 6.0 (третий уровень проверки) и компилятора ОС МСВС 3.0.

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

4.4 Выводы

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

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

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

Работу можно считать завершенной с положительным результатом.

5. Экономическая часть

5.1 Анализ рынка

5.1.1 Цель разработки

В дипломном проекте была поставлена задача разработки подсистемы создания, редактирования и визуализации маршрута полета БЛА на ЦКМ. Подсистема должна функционировать в составе специального программного обеспечения (СПО) «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов БЛА одновременно в нескольких окнах отображения ЦКМ формата географической информационной системы (ГИС) «Интеграция».

5.1.2 Исследование рынка

Поскольку программный продукт не является самостоятельным, его продажа не предусмотрена, то рынка для данного программного продукта не существует. Разработанный программный продукт представляет собой совокупность протестированных и отлаженных, готовых для встраивания в СПО «Проходчик» модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4. Следовательно, разработанная подсистема до ее интеграции в СПО «Проходчик» представляет интерес только для специалистов ОАО «КБ «ЛУЧ», занимающихся разработкой программного обеспечения. Экономический эффект для разработанной подсистемы рассматривается ниже (п. 5.3).

5.1.3 Обзор аналогов

Разработанный программный продукт является аналогом ранее существовавшей в ОАО «КБ «ЛУЧ» подсистемы создания, редактирования и визуализации маршрута полета БЛА, обладавшей рядом ограничений:

1) отсутствовали специальные маневры;

2) подсистема ориентирована на визуализацию одного маршрута;

3) использовался более примитивный алгоритм визуализации, без кэширования карты и сцены;

4) подсистема не позволяла производить визуализацию маршрута в нескольких экранных окнах одновременно;

5) не было реализовано редактирование маршрута путем перетаскивания мышью его элементов.

Разработанная подсистема имеет следующие преимущества:

1) предоставляет диалоговые окна для автоматического создания ряда специальных маневров, что позволяет существенно упростить работу оператора;

2) поддерживается визуализация и редактирование совокупности маршрутов;

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

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

5) поддерживается редактирование маршрутов путем перемещения мышью их составных элементов; реализовано следующее соответствие: изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, - в диалоговых окнах. Осуществляется проверка перемещения элементов маршрута мышью, исключающая потерю визуального контроля элементов при их выходе за область видимости ЦКМ;

6) реализован выбор интересующего элемента их нескольких возможных элементов при выделении составных частей маршрута мышью - аналог слоев;

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

Таким образом, разработана новая, гибкая и эффективная подсистема управления маршрутами, готовая для интеграции в СПО «Проходчик».

5.2 Затраты на разработку, полная себестоимость, установление цены разработчика

Расчет себестоимости осуществляется на основании методических рекомендации по технико-экономическому обоснованию дипломных работ студентов специальности 220400 программное обеспечение вычислительной техники и автоматизированных систем, под редакцией Кустовой Т.Н., Коновалова О.В, изданного в Рыбинске в 2004 году. Специальность 220400 в настоящее время переименована в 230105.

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

- материальные затраты;

- основная заработная плата;

- дополнительная заработная плата;

- отчисления на социальные нужды (единый социальный налог);

- амортизационные отчисления и эксплуатационные расходы, связанные с использованием ЭВМ (расходы на машинное время);

- наложенные расходы (освещение, облуживание рабочего места, аренда помещения и т.п.);

- прочие затраты.

5.2.1 Расчет материальных затрат

Материальные затраты - это расходы на канцелярские товары, носители информации и расходные материалы. Материальные затраты составили .

5.2.2 Расчет основной заработной платы

Основная заработная плата определяется по следующей формуле:

Где - основная заработная плата;

- ставка заработной платы (месячная);

- время разработки (в месяцах).

Оклад инженера студенческого конструкторского бюро (СКБ) составляет 3850 рублей, к этой сумме добавляется стипендия студентам-выпускникам академии в размере 2000 рублей. Следовательно, заработная плата студента-инженера СКБ составляет , время разработки программного продукта . Следовательно, можно рассчитать основную заработную плату:

5.2.3 Расчет дополнительной заработной платы

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



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

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

5.2.4 Единый социальный налог

Ставка единого социального налога (ЕСН) - 26%. ЕСН - общее название суммы следующих налоговых сборов:

- сбор в федеральный бюджет пенсионного фонда - ставка 6%;

- сбор в пенсионный фонд - ставка 14%;

- сбор в фонд социального страхования - ставка 2,9%;

- сбор в федеральный фонд обязательного медицинского страхования - ставка 1,1%;

- сбор в территориальный фонд обязательного медицинского страхования - ставка 2%.

Вычисление ставки ЕСН осуществляется от основной и от дополнительно заработных плат и определяется по формуле:

Посчитаем значение ЕСН:

.

5.2.5 Амортизационные расходы

Расходы на машинное время определяются по формуле:

Где - расходы на машинное время, руб.;

- стоимость 1 часа машинного времени, руб.;

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

Стоимость одного часа машинного времени зависит от:

- цены компьютера. Цена компьютера состоит из стоимости аппаратных средств ЭВМ и - стоимости установленного программного обеспечения включающей в себя стоимость операционной системы - 5000 рублей, среды разработки - 12000 рублей, кроссплатформенной библиотеки - 5000 рублей, среды проектирования - 34000 рублей, средство тестирования и отладки программного обеспечения 1000;

- срока службы компьютера;

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

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

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

Стоимость 1 часа машинного времени можно рассчитать по формуле:

По приведенной формуле рассчитаем стоимость 1 часа машинного времени

.

Так как в одном месяце 22 рабочих дня, тогда время работы вычислительной системы равно , тогда время использования ЭВМ составит:

.

Следовательно, можно найти расходы на машинное время:

.

5.2.6 Наложенные расходы

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

где - норматив для вычисления наложенных расходов. С учетом условий труда примем норматив равным .

Тогда наложенные расходы составят:

.

5.2.7 Прочие затраты

Прочие затраты включают:

- командировочные расходы разработчика, связанные с процессом разработки (учитываются по нормативу);

- коммерческие расходы, связанные с реализацией программного продукта (в размере 2 - 3% от производственной себестоимости - суммы материальных затрат, заработной платы с отчислениями и стоимости машинного времени);

- расходы на рекламу (по нормативу).

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

5.2.8 Определение себестоимости

Сумма всех перечисленных затрат (п.п. 5.2.1 - 5.2.7) образует полную себестоимость разработки программного продукта

Таким образом, получили себестоимость разработки равной 50168,84 рубля.

5.2.9 Установление цены разработчика

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

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

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

Где - норматив прибыли;

- величина материальных затрат;

- налог на добавленную стоимость;

- себестоимость разработки программного продукта.

Тогда цена разработчика составит:

Итак, минимальная цена разработки кроссплатформенной подсистемы создания, редактирования и визуализации маршрута БЛА на ЦКМ составляет 64939,15 рубля.

5.3 Экономический эффект от использования подсистемы

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

а) в ходе реализации подсистемы была разработана концептуальная схема визуализации маршрутов БЛА в нескольких окнах одновременно, которая, благодаря своей гибкости и эффективности, безусловно, найдет применение как в СПО «Проходчик», так и в дальнейших разработках;

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

в) разработанная подсистема удовлетворяет новейшим требованиям к организации, структуре и разработке маршрута полета БЛА;

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

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

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

6. Материалы по охране труда. Анализ разработанного программного продукта на соответствие требованиям эргономики

6.1 Введение

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

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

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

С точки зрения эргономики интерес представляет анализ ПИ программного продукта, как в широком, так и в узком смысле.

Прогресс в разработке ПИ программных продуктов привел к появлению соответствующих стандартов - сначала на уровне ведущих компаний-разработчиков, а позднее и ISO (International Organization for Standardization - Международная организация по стандартизации). B их основе лежит накопленный опыт разработки и оценки качества наиболее продвинутых программных проектов. С другой стороны, стандарты содержат определенный элемент произвольности, а также испытывают на себе давление производителей. B этом смысле стандартизация олицетворяет консервативную сторону прогресса. Но, однажды возникнув, стандарт становится общепризнанным и часто обязательным нормативом дальнейшего прогресса в соответствующей области. Означает ли это, что неукоснительное следование стандартам может обеспечить необходимое качество ПИ? Для простых и рутинных приложений - следование стандарту гарантирует только минимальный уровень качества. Для сложных и пионерских приложений требование обеспечения функциональной полноты может вступить в противоречие с ограниченными возможностями, предоставляемыми стандартом управляющих средств ПИ.

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

6.2.1 Средства отображения информации

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

Интерфейс разработанной подсистемы относится к классу двухмерных графических ПИ - WIMР (Windows, Icons, Menus and multiple Processes - человеко-машинный интерфейс с использованием механизмов окон, пиктограмм, меню и нескольких процессов). Рассмотрим этот класс более подробно.

Для программного продукта с графическим ПИ информационные средства отображения информации можно разделить на 2 группы - прямые и косвенные. К прямым относится: внешний вид программного продукта (интерфейс в узком смысле), включая звуковые оповещения, к косвенным - монитор, принтер, звуковая система или другое подключенное к компьютеру оборудование, способное информировать пользователя о наступлении какого либо события. Органы управления можно разделить на: физические (косвенные) и виртуальные (прямые). Физическими являются: клавиатура, мышь, джойстик, микрофон и др. Виртуальными - активные объекты интерфейса программного продукта (кнопки, селекторы, окна приложения).

6.2.2 Интерфейсы программных продуктов

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

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

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

6.2.3 Понятие эргономики и эргономичности пользовательского интерфейса

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

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

Важным показателем пользовательского интерфейса является его качество. Качество определяется в ГОСT Р ИСО/MЭK 9126-93 как "объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям". При комплексной оценке показателей качества программного продукта качество пользовательского интерфейса вносит определяющий вклад в такую субхарактеристику качества, как практичность (ГОСT Р ИСО/MЭK 9126-93, таблица 4). С семиотической точки зрения качество соотносится со стандартизированностью как семантика и прагматика с синтактикой. Другими словами, качество характеризует содержание (смысл) и полезность текста, в то время как стандартизированность - грамотность (корректность).

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

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

Нормативные требования по эргономике пользовательского интерфейса отличаются по своей природе относятся к психофизиологическим свойствам конкретной реализации уже выбранного типа (стиля) пользовательского интерфейса (и соответствующего стандарта) в конкретном продукте. B этих условиях эргономические стандарты могут лишь требовать достижения некоторых общих руководящих эргономических принципов, которым должно удовлетворять реализация в приложении выбранного типа (стиля). При этом предполагается, что приложение должно быть оптимально инкорпорировано в техническую среду. Ряд более ранних стандартов (стандарты ISО 9241Р.3-9) касаются именно этой среды (клавиатура, дисплеи, устройства ввода с клавиатуры и мыши, мебель рабочей станции и показатели рабочей среды, например, освещение или уровни шума). Эргономические аспекты пользовательского интерфейса приложения являются естественным расширением эргономики технических средств и рабочего места. Сегодня существует два подхода к оценке эргономического качества, которые можно отнести к методам "черного" и "белого ящика".

В первом подходе оценку производит конечный пользователь, суммируя результаты работы с программой в рамках следующих показателей ISО 9241-10-98 «Эргономические требования к офисной работе с использованием графических терминалов» (раздел 11):

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

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

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

Эффективность является критерием функциональности интерфейса, а степень удовлетворенности и, косвенно, продуктивность - критерием эргономичности

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

Существует ряд универсальных руководящих рекомендаций по разработке качественного пользовательского интерфейса (метод «белого ящика»).

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

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

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

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

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

6.2.4.1 Рекомендации по разработке эргономичного пользовательского интерфейса

Последовательность действий и набор инструментальных средств пользователя в ПИ должны быть подчинены технологическому процессу выполнения производственного задания - здесь и далее в этом пункте использован материал источника [11]. Необходимо тщательно продумать и осознать сценарий взаимодействия пользователя с программным продуктом, приведя его к оптимальной (относительно показателей рассмотренных в п. 6.2.4) системе выполнения задач, и реализовать ПИ в соответствии с этой системой.

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

- выяснить какая информация необходима пользователю для решения задачи;

- выяснить какую информацию пользователь может игнорировать при решении задачи;

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

- определить какие решения пользователю необходимо принимать в процессе работы с программой;

- выяснить может ли пользователь совершать несколько различных действий (решать несколько задач) одновременно;

- определить какие типовые операции использует пользователь при решении задачи;

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

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

Дизайн ПИ должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить к:

- сокращению длительности операций чтения, редактирования и поиска информации;

- уменьшению времени навигации и выбора команды;

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

- увеличению длительности устойчивой работы пользователя и др.

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

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

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

- что от пользователя требуется в первую очередь?

- сколько информации, требующей обработки, поступает пользователю за период времени?

- каковы требования к точности и скорости ввода информации?

- на какие операции пользователь тратит больше всего времени?

- чем можно облегчить работу пользователя при решении типовых задач?

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

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

- прозрачной для пользователя навигации и целевой ориентации в программе (главное, обеспечить понятность последовательности и назначения производимых операций);

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

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

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

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

Проблемы, возникающие на этапе разработки прототипа ПИ и варианты их решения

· учет особенностей устройств ввода/вывода информации, используемых пользователем, например:

- размер экрана монитора;

- разрешение экрана;

- цветовая палитра;

- характеристики звуковой (качество воспроизведения речи) и видеокарты (скорость вывода при анимации);

- вид мыши (с роликом или без);

- тип клавиатуры ("прямая", "косая");

- необходимость дополнительного оборудования (штрих-декодера, светового пера сенсорного экрана и др.);

· специфика интерактивных элементов, связанная с выбором платформы, стандартных библиотек:

- программная организация ввода/вывода информации;

- изменение и создание новых элементов форм;

- приобретение нестандартных библиотек у других фирм;

· выбор технологии и методов ведения диалога программы с пользователем:

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

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

- соответствие ожиданиям пользователя (предсказание, предобработка, предформатирование);

- устойчивость, терпимость к ошибкам пользователя путем исправления типичных ошибок;

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

- степень адаптивности ПИ под предпочтения пользователя (изменение способа и порядка отображения, перекомпоновка экрана, выбор отдельных характеристик (стиля) и пр.);

- настройка ПИ на специфику задачи (новый формат данных, изменение набора объектов, дополнение атрибутов объектов);

· размещение информации и управляющих элементов в поле экрана, в окне;

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

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

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

- выделения важной информации на экране;

- четкого определения основных и вспомогательных блоков информации;

- определения статических полей на экране, а также полей, где информация периодически изменяется;

- избегания перекрывающихся окон на экране;

- применения принципов гармонии при компоновке экрана (симметрия, баланса масс, соблюдение пропорций, сочетание цветов);

· формирование обратной связи между пользователем и приложением:

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

- вывод отдельных, важных для рабочей операции данных и показателей;

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

- ясность и информативность сообщений системы;

· проектирование панелей меню и инструментов и выбор пунктов в них:

- логическая и смысловая группировка пунктов;

- фиксированная позиция панелей на экране;

- ограничение на ширину списка выборов и шагов (глубины) меню;

- использование привычных названий, широко распространенных икон-пиктограмм, традиционных икон-символов и аккуратное введение сокращений;

- размещение наиболее часто используемых пунктов (обычно в начале списка);

· разработка средств ориентации и навигации:

- легкость определения своего местонахождения и указание направления следования;

- удобный переход от обобщенного взгляда до конкретных деталей (варьирование степени детализации рассматриваемых объектов);

- быстрый поиск в списке или таблице;

- указание на дополнительно существующую информацию и способ ее получения;

- использование средств листания и прокрутки;

· создание форм для ввода данных:

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

- определение способов ввода данных (таблицы, списки, простая форма, меню и пр.);

- минимизация объема ввода;

- выделение редактируемых обязательных и необязательных, а также нередактируемых полей;

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

- выделение введенной или отредактированной информации.

Принципы реализации пользовательского интерфейса:

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

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

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

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

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

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

6.3 Интерфейс подсистемы

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

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

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

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

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

Диалоговое окно «Редактор маршрута» объединяет в себе всю функциональность, относящуюся к работе с совокупностью визуализируемых маршрутов БЛА: добавление и удаление маршрута из списка, редактирование заголовка, добавление, удаление и изменение порядка прохождения маневров активного маршрута. Элементы управления диалогового окна разбиты на логические группы: «Добавление нового маршрута», «Редактирование маршрута», «Данные маршрута», «Операции с маневрами», «Порядок маневров». В группе элементов управления «Операции с маневрами» оператор может вызвать диалоговое окно для редактирования параметров выбранного маневра активного маршрута.

Диалоговое окно «Редактор маневра» объединяет функции, позволяющие произвести редактирование заголовка выбранного маневра и количество ХТТ, взодящих в состав маневра.

Диалоговое окно «Редактор ХТТ» содержит набор необходимых элементов управления для редактирования всех возможных параметров выбранной ХТТ.

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

Рисунок 6.1 Диалоговое окно «Редактор маршрута»

Рисунок 6.2 Диалоговое окно «Редактор маневра»

Рисунок 6.3 Диалоговое окно «Редактор ХТТ»

6.3.2 Соответствие пользовательского интерфейса подсистемы требованиям эргономики

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

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

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

Точности работы оператора с подсистемой способствуют:

а) четкое логическое разделение функциональности, как по отдельным диалоговым окнам, так и по группам в определенном окне;

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

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

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

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

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

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

з) мгновенное отражение внесенных изменений на ЦКМ - способствуют дополнительной проверке совершаемых оператором действий.

Функциональная полнота ПИ характеризуется тем, что ПИ спроектирован в строгом соответствии с документом, регламентирующим организацию, структуру и порядок разработки маршрута полета БЛА.

Завершенности работы, как показателю эффективности ПИ, в данной подсистеме способствуют следующие факторы:

а) все изменения, вносимые оператором, отражаются на ЦКМ, сопровождаются информационными сообщениями, обеспечивая дополнительный контроль выполняемых действий;

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

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

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

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

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

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

Можно назвать следующие недостатки пользовательского интерфейса:

1) при работе с картой диалоговые окна приходится перемещать по экрану или закрывать с последующим возобновлением к ним доступа;

2) имеется некоторая нелогичность интерфейса, которая заключается в невозможности изменения заголовка маршрута, не содержащего маневров, или маневра, не содержащего ХТТ;

3) добавление новой ХТТ осуществляется в конец маневра, следовательно, невозможно поменять местами ХТТ в маневре;

4) оператор может заполнить необходимыми данными определенные поля ввода, забыв применить внесенные изменения;

5) получить доступ к «Редактору маневров» можно только из «Редактора маршрута» (за два шага), а доступ к «Редактору ХТТ» - за три шага, через «Редактор маневров».

Первый недостаток может показаться не столь значимым, так как при реализации редакторов маршрута, маневра и ХТТ экономится рабочее пространство, занимаемое ЦКМ и обилия прочих элементов управления.

Второй недостаток не столь существенен, так как введенные пользователем данные в заголовки маршрута или маневра не пропадают, а после добавления маневра в маршрут или ХТТ в маневр происходит активизация кнопки «Применить», что является визуальным сигналом оператору к выполнению определенных действий. С другой стороны, было бы нелогичным разбивать заголовки маршрутов и маневров на несколько частей, внося в них изменения по отдельности.

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

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

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

6.4 Результаты анализа ПИ подсистемы на соответствие требованиям эргономики

В данном разделе были даны понятия ПИ, эргономики, эргономичности ПИ, приведена классификация ПИ, рассмотрены основные критерии эргономичности ПИ и рекомендации к разработке ПИ.

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

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

Заключение

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

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

- изучены материалы, связанные с организацией, структурой, требованиями к разработке маршрута полета БЛА для СПО «Проходчик»;

- разработана концептуальная схема подсистемы визуализации совокупности маршрутов в нескольких экранных окнах одновременно;

- разработан базовый набор графических примитивов для визуализации элементов маршрутов;

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

- разработано техническое задание на «Подсистему создания, редактирования и визуализации маршрута полета БЛА на ЦКМ»;

- разработана «Подсистема создания, редактирования и визуализации маршрута полета БЛА на ЦКМ»;

- проведены испытания подсистемы в соответствии с п. 2.4 «Программа и методики испытаний», в результате которых сделаны выводы и заключение о соответствии программного продукта требованиям Технического задания;

- проведен эргономический анализ интерфейса разработанной подсистемы;

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

Список литературы

1 httр://lutсН.уаrоslаvl.ru - официальная страница ОАО «КБ «ЛУЧ».

2 Маршрут полета БЛА из состава КВР. Организация, структура, требования к разработке. - ОАО «КБ «ЛУЧ».

3 httр://www.vrеmуа.ru/рrint/221720.Нtml

4 httр://ru.wikiреdiа.оrg/wiki/БПЛА_по_странам

5 У. Боггс, М. Боггс. UML и Rаtiоnаl Rоsе. - СПб: Питер, 2002.

6 Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб: Питер, 2007.