Реализация данного алгоритма была выполнена на ЭВМ на высокоуровневом языке программирования Matlab в среде Matlab R2008a с использованием стандартных библиотек C/C++.

2.1 Оценка целесообразности разработки алгоритмов и программных продуктов

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

· Выбрать аналог

· Сформулировать перечень характеристик качества разработки по предлагаемому варианту ПП

· Определить конкретные значения характеристик, их значимость

При выборе характеристик качества разрабатываемых алгоритмов и ПП следует учитывать систему характеристик качества программных средств по стандарту ISO 9126:1991.

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

Анализируемые функциональные характеристики отражены в таблице 2.1.1.

Таблица 2.1.1 Характеристики качества алгоритмов и ПП

Характеристики качества ПП	Значения характеристик качества ПП	Значимость характеристик
	Аналог	Новый вариант
Пригодность для применения	1	2	0,2
Отсутствие ошибок	1	3	0,2
Понятность	1	5	0,05
Простота использования	1	4	0,05
Временная экономичность	1	3	0,2
Ресурсная экономичность	1	3	0,1
Стабильность	1	2	0,1
Внедряемость	1	2	0,1

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

,

где Х_Hi, Х_Бi - уровень i-ой функциональной характеристики соответственно нового и базового ПП;

м_i - значимость i-ой функционально-технической характеристики;

n - количество рассматриваемых характеристик.

Таким образом, рассчитаем индекс технического уровня:

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

2.2 Планирование разработки

Определение трудоёмкости

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

,

где t_О - затраты труда на подготовку описания задачи;

t_И - затраты труда на изучение и постановку задачи;

t_А - затраты труда на разработку алгоритма решения задачи;

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



t_ОТ - затраты труда на отладку программы;

t_Д - затраты труда на подготовку документации по ПП.

Q - Условное количество операторов в программе:

,

q - предполагаемое количество команд;

К_С - коэффициент сложности программ;

К_К - коэффициент коррекции программы при ее разработке

n - количество коррекций программы в ходе ее разработки.

К - коэффициент квалификации разработчика

B - увеличение затрат на изучение и постановку задачи вследствие ее сложности и новизны

Для разрабатываемого ПП:

q = 2000

n = 5

K_K = 0,1

K_C = 1,5

B = 2,5

K = 1,1

Таким образом:

t_О = 16;

Результаты вычислений занесем в таблицу 2.2.1:

Таблица 2.2.1 структура трудовых затрат на разработку алгоритмов и ПП

№	Наименование этапа работ	Доля работ на этапе в общем объеме работ, %
1	Подготовка описания задачи	0,77
2	Изучение и постановка задачи	6,7
3	Разработка алгоритма решения задачи	9,9
4	Программирование по блок-схеме	19,8
5	Отладка программы	39,7
6	Подготовка документации по ПП	23,1
Итого:		100

Календарное планирование

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

Производственный цикл каждого этапа определяется по формуле:

где Т_j - трудоёмкость j-того этапа работ, чел./час;

t_рд - продолжительность рабочего дня, час;

q_j - количество работников одновременно участвующих в выполнении работ на j-том этапе, чел.

Таким образом, рассчитаем:

Пересчитаем в календарные дни:

2.3 Определение затрат, себестоимости и цены

Затраты на создание алгоритмов и ПП определяют по следующим статьям расходов:

1. Материалы;

2. Специальное оборудование;

3. Заработная плата основных исполнителей;

4. Отчисления на единый социальный налог основных исполнителей;

5. Страховые социальные расходы на производственный травматизм;

6. Накладные расходы;

7. Прочие расходы.

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

Затраты на материалы сведены в таблицу 2.3.1

Таблица 2.3.1 Затраты на материалы и покупные изделия

№ п/п	Наименование	Единицы измерения	Цена, руб.	Сумма, руб.
1	Внешний накопитель Kingston DataTraveler+	1 шт.	900	900
2	Ручки	3 шт.	10	30
3	Бумага (А4) SvetoCopy	1 пачка	200	200
	Итого			1130

Расчет затрат на спецоборудование

Затраты на спецоборудование отсутствуют.

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

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

Таблица 2.3.2 Заработная плата основного персонала

№ этапа	Трудоемкость стадий, чел.-дн	Исполнители	Дневн. ставка, р	Сред. дневная ставка, р	З/п, р	З/п с уч. Премий (15%), р
		должность	числ.
1	2	Ведущий инженер	1	350	350	700	805
2	17	Ведущий инженер	1	400	400	6800	7820
3	22,5	Ведущий инженер	1	400	400	9000	10350
4	22,5	Программист	2	350	350	15750	18112,5
5	51	Программист	1	350	375	19125	21993,75
		Ведущий инженер	1	400
6	30	Программист	1	350	375	11250	12937,5
		Ведущий инженер	1	400
Всего	145		62625	72018,75

Расчет отчислений на социальные нужды

Норматив отчислений на социальные нужды составляет 26,2% от заработной платы основных исполнителей.

Таким образом:

Расчет накладных расходов

Накладные расходы определяются по формуле

,

где K_НАКЛ = 1..2.

Примем K_НАКЛ = 1, тогда:

Расчет накладных расходов

Накладные расходы составляют 5% от расходов на заработную плату основных исполнителей:

Таким образом:

Общие результаты по статьям расходов приведены в таблице 2.3.3.

Таблица 2.3.3 Затраты на создание алгоритмов и ПП

Наименование элементов и статей расходов	Затраты, руб.	Удельный вес, %
материалы	1130	0,6
специальное оборудование	-	-
заработная плата основных исполнителей	72018,75	42,9
отчисления на единый социальный налог основных исполнителей	18868,91	11,3
накладные расходы	72018,75	42,9
прочие расходы	3600	2.1
Итого:	167636,41	100

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

,

где З_ПП - затраты на создание алгоритмов и программных продуктов;

ЗП_пп - заработная плата основных исполнителей - разработчиков ПП;

с_ЗП - рентабельность разработки ПП по отношению к оплате труда основных исполнителей, обеспечивающая безубыточную деятельность (с_ЗП = 200 - 400%).

Примем с_ЗП = 250%

2.4 Определение и оценка показателей экономической эффективности

Основными показателями экономической эффективности являются: экономический эффект (Э), уровень экономической эффективности (Е), срок окупаемости вложений (Т_ОК).

Использование разработанных в данном дипломном проекте алгоритмов и ПП приводит к сокращению времени решения задачи в связи с применением более совершенных. В этом случае Э_ПП.Г считается следующим образом:

где ДТ_мi - экономия машинного времени по i-ой задаче, час.;

С_вт - стоимость одного машинного часа, руб.;

n - количество задач, решаемых за год.

Разработанный алгоритм может использоваться до 50 раз в день. Таким образом, количество использований алгоритма в год составляет до 17800 раз в год. Время выполнения одной задачи при использовании разработанного ПП повышается примерно в снижается на 3 минуты. Таким образом, при стоимости одного машинного часа, равной 400 р., рассчитаем экономический эффект:

Уровень экономической эффективности и срок окупаемости вложений составляют в этом случае соответственно:



3. Охрана труда и окружающей среды

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

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

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

3.1 Особенности восприятия информации с дисплея

Компьютерный зрительный синдром

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

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

Изучая эту проблему, в 1998 году в США американские медики ввели в обиход новый термин - Компьютерный зрительный синдром (Сomputer Vision Syndrome, CVS). Это специфическое нарушение зрения (астенопия) у людей, проводящих много времени перед экраном компьютера. Считается, что этот синдром ежедневно возникает у 40% людей, работающих на компьютере, и периодически - у 92% пользователей.

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

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

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

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

В-четвертых, на наше зрение влияет и кадровая развертка.

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

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

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

3.2 Нормативные документы

Основными документами, нормирующими параметры видеодисплейных терминалов (ВДТ) являются СанПиН 2.2.2/2.4.2198-07 (изменение №1 к СанПиН 2.2.2/2.4.1340-03) «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организация работы» и ГОСТ Р 50948-2001 «Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности».

СанПиН 2.2.2/2.4.1340-03 регламентирует следующие параметры изображения ВДТ:

· Яркость белого поля и ее колебания в пределах рабочего поля

· Контрастность - отношение максимальной яркости изображения к минимальной с учетом отражений, возникающих за счет внешней освещенности экрана.

· Временная нестабильность изображения - непреднамеренное изменение во времени яркости изображения на экране дисплея

· Пространственная нестабильность изображения - непреднамеренные изменения положения фрагментов изображения на экране.

Согласно этому документу, визуальные параметры видеодисплейных терминалов должны удовлетворять требованиям, приведенным в таблице 3.2.1. [7]

Таблица 3.2.1 Визуальные параметры ВДТ, контролируемые на рабочих местах по СанПиН 2.2.2/2.4.1340-03

N	Параметры	Допустимые значения
1	Яркость белого поля	Не менее 35 кд/мІ
2	Неравномерность яркости рабочего поля	Не более +-20%
3	Контрастность (для монохромного режима)	Не менее 3:1
4	Временная нестабильность изображения (мелькания)	Не должна фиксироваться
5	Пространственная нестабильность изображения (дрожание)	Не более 2 х 10 (-4L), где L - проектное расстояние наблюдения, мм

ГОСТ Р 50948-2001 охватывает большее количество параметров ВДТ и выводимой на них информации. В этом документе рассмотрены следующие пункты, касающиеся эргономических характеристик ВДТ:

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

· Эргономические требования к цветовым параметрам.

· Требования безопасности к визуальным параметрам.

Далее рассмотрим подробнее некоторые пункты этого документа.

Требования к качеству восприятия информации, отображаемой на дисплеях

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

Допустимые диапазоны значений внешней освещенности экрана, углового размера знака и угла наблюдения экрана для типов дисплеев, на которые этот стандарт распространяется, - по ГОСТ Р 50923; для других типов дисплеев - по ТУ на конкретный тип дисплея.

В этой части ГОСТ Р 50923-96 предъявляет к дисплею следующие требования:

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

· Дисплей на рабочем месте должен быть установлен ниже уровня глаз оператора. Угол наблюдения экрана оператором относительно горизонтальной линии взгляда не должен превышать 60°;

· Отношение яркостей в зоне наблюдения должно быть не более 10:1.

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

Эргономические требования к цветовым параметрам

Данный пункт регламентирует:

· Максимальное количество цветов, при котором человек может комфортно воспринимать информацию.

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

· Благоприятные и неблагоприятные для восприятия цвета.

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

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

· Благоприятные и неблагоприятные сочетания цветов фона и текста.

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

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

Требования безопасности к визуальным параметрам

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

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

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

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

Таблица 3.2.2 Визуальные параметры ВДТ, контролируемые на рабочих местах по ГОСТ Р 50948-2001

N	Параметры	Допустимые значения
1	Яркость знака	Не менее 35 кд/мІ для дисплеев на ЭЛТ и не менее 20 кд/мІ для плоских дискретных экранов
2	Неравномерность яркости рабочего поля	Не более +-20%
3	Неравномерность яркости элементов знака	Не более +-20%
4	Яркостный контраст изображения	Не менее 3:1 (для плоских дискретных экранов при угле наблюдения от минус 40° до плюс 40°)
5	Яркостный контраст внутри знака и между знаками	Не менее 3:1
6	Ширина контура знака	от 0,25 до 0,5 мм
7	Степень несведения цветов в любом месте многоцветного экрана для дисплеев на ЭЛТ	не более 3,4 ў при проектном расстоянии наблюдения*
8	Временная нестабильность изображения (мелькания)	Не должна быть зафиксирована**.
9	Амплитуда смещения изображения (пространственная нестабильность изображения - дрожание)	не более 2Ч10-4l, где l - проектное расстояние наблюдения, мм
10	Изменение размеров однотипных знаков по рабочему полю	Не более ±5% высоты знака
11	Максимальная разность длин строк текста на рабочем поле	Не более 2% средней длины строки
12	Максимальная разность длин столбцов текста на рабочем поле	не более 2% средней длины столбца
13	Отклонение формы рабочего поля от прямоугольника по вертикали***	Не более 0,02
14	Отклонение формы рабочего поля от прямоугольника по горизонтали***	Не более 0,02
15	Отклонение формы рабочего поля от прямоугольника по диагонали***	Не более 0,04

* Если в документации на дисплей не оговорено проектное расстояние наблюдения, то его принимают равным 50 см для дисплеев с размером экрана по диагонали 14» - 17» и 75 см - для экранов 19» - 21».

** Для дисплеев на ЭЛТ частота обновления изображения должна быть не менее 75 Гц при всех режимах разложения, гарантируемых нормативной документацией на конкретный тип дисплея и не менее 60 Гц для дисплеев на плоских дискретных экранах.

*** Расчетные формулы для отклонений рабочего поля:

по вертикали:

,

где Н₁ - значение длины крайнего левого столбца;

H₂ - значение длины крайнего правого столбца;

по горизонтали:

,

где B₁ - значение длины верхней строки;

B₂ - значение длины нижней строки;

по диагонали:

,

где D₁, D₂ - значения длин диагоналей на рабочем поле.

На рабочем месте использовался дисплей Acer AL1916 (размер диагонали - 19»). Его настройки были выставлены следующим образом:

Контрастность: 50% от максимальной для данного дисплея;

Яркость: 50% от максимальной для данного дисплея;

Частота вертикальной развертки (частота обновления): 75 Гц.

Исходя из размера диагонали дисплея, величина проектного расстояния равна 75 см.

Проведем необходимые расчеты и измерения и занесем результаты в таблицу 3.2.3.

Таблица 3.2.3 Результаты измерений и расчетов визуальных параметров ВДТ

N	Параметры	Допустимые значения
1	Яркость знака	Не менее 26,5 кд/мІ
2	Неравномерность яркости рабочего поля	12,3%
3	Неравномерность яркости элементов знака	6,5%
4	Яркостный контраст изображения	Не менее 10:1 (для плоских дискретных экранов при угле наблюдения от минус 135° до плюс 135°)
5	Яркостный контраст внутри знака и между знаками	Не менее 10:1
6	Ширина контура знака	0,294 мм
7	Временная нестабильность изображения (мелькания)	Не фиксируется
8	Амплитуда смещения изображения (пространственная нестабильность изображения - дрожание)	Не фиксируется

Также следует заметить, что при проведении теста на качество антибликового покрытия отраженная яркость не превышала 0,2 кд/мІ, что составляет менее 1% минимальной яркости рабочего поля. [8]

3.3 Улучшение подачи информации оператору

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

Глаз человека, воспринимающий излучение, можно характеризовать следующими признаками:

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

· информационные - пропускная способность;

· пространственные - острота и поле зрения, объем восприятия;

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

Как видно, нормативы, приведенные в ГОСТ Р 50948-2001 и СанПиН 2.2.2/2.4.1340-03 затрагивают лишь первый, третий и четвертый признаки. Однако, принимая во внимание оставшийся информационный признак, а так же частично нерассмотренный пространственный, можно существенно улучшить продуктивность и качество работы оператора ПЭВМ, тем самым, снизив время его пребывания за ВДТ, а, следовательно, и воздействие вредных факторов.

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

Активизация внимания

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

Логические ударения

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

Например, в случае ошибки при написании программы, компилятор сообщает «В функции fprintf() пропущена скобка». При этом больше никакой информации не приводится (рисунок 3.3.1). На поиск данной ошибки уходит несколько секунд. Если же подсветить строку, в которой допущена ошибка другим цветом, то на поиск ошибки программист практически не затратит времени (рисунок 3.3.2).



Рисунок 3.3.1 Отсутствие логического ударения

Рисунок 3.3.2 Логическое ударение в виде выделения цветом

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

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

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

Графическое представление

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

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

Рисунок 3.3.3 Сравнение табличного и графического представления

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

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

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

4. Технологическая часть

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

Реализация данного алгоритма была выполнена на ЭВМ на высокоуровневом языке программирования Matlab в среде Matlab R2008a с использованием стандартных библиотек C/C++.

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

4.1 Понятие технологии программирования

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

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

4.2 Жизненный цикл программного продукта

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

Существуют несколько моделей жизненного цикла (ЖЦ), каждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают в себя пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем названия и кратное содержание каждого этапа в соответствии с ГОСТ 19.102-77.

1. Техническое задание:

· постановка задачи;

· выбор критериев эффективности;

· проведение предварительных научно-исследовательских работ (НИР);

· разработка ТЗ.

2. Эскизный проект:

· структура входных и выходных данных;

· уточнение методов решения;

· общий алгоритм;

· разработка документации эскизного проекта.

3. Технический проект:

· уточнение структуры входных и выходных данных;

· разработки алгоритмов;

· формы данных;

· семантика и синтаксис языка;

· структура программы;

· конфигурация технических средств;

· план работ.

4. Рабочий проект:

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

· разработки документации;

· подготовка и проведение испытаний;

· корректировка программы и документов по итогам испытаний.

5. Внедрение:

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

· оформление акта;

· передача в Фонд алгоритмов и программ (ФАП).

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

Каскадная модель

Эта модель является первой по времени появления. Последовательность выполнения ее этапов показана на рисунке 4.2.1.



Рисунок 4.2.1. Каскадная модель

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

· последовательным выполнением входящих в ее состав этапов;

· окончанием каждого предыдущего этапа до начала следующего;

· отсутствием временного перекрытия этапов;

· отсутствием (или определенным ограничением) возврата к предыдущим этапам;

· наличием результата только в конце разработки.

Выявление и устранение ошибок в каскадной модели производится только на стадии тестирования, которая может растянуться во времени или вообще никогда не завершиться. [11]

Итерационная модель

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

Рисунок 4.2.2 Итерационная модель

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

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

Инкрементная модель

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

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте - более сложные возможности редактирования и документирования; в 3-м инкременте - проверку орфографии и грамматики; в 4-м инкременте - возможности компоновки страницы.

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

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

По своей природе инкрементный процесс итеративен, но, в отличие от итерационной, инкрементная модель обеспечивает на каждом инкременте работающий продукт. [12]

Спиральная модель

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

Рисунок 4.2.3. Спиральная модель

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

Компонентно-ориентированная модель

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

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

Достоинства компонентно-ориентированной модели:

· уменьшает на 30% время разработки программного продукта;

· уменьшает стоимость программной разработки до 70%;

· увеличивает в полтора раза производительность разработки.

Итак, основными этапами разработки ПО являются:

1. Анализ требований;

2. Проектирование;

3. Реализация;

4. Тестирование и отладка;

5. Сопровождения

Кроме того, сюда в настоящее время сюда так же добавился такой пункт, как сертификация или аттестация ПО. [12]

Рассмотрим каждый из этих пунктов подробнее.

Анализ требований и определение спецификаций

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

Существует два вида требований, рассматриваемых на данном этапе:

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

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

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

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

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

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

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

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

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

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

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

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

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

Четко сформулировать спецификации требований к разрабатываемому ПО, чтобы затем занести их в техническое задание, - достаточно сложная и ответственная задача, которая требует проведения предпроектных исследований. [12]

Проектирование программного обеспечения

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

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

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

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

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

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

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

Функциональные схемы, как правило, более информативны, чем структурные.

При объектном подходе используется разделение на логическое и физическое проектирование программных продуктов. Логическое проектирование заключается в разработке классов для реализации их экземпляров - объектов. Для этого требуется подробное описание полей и методов классов, а также связей между ними. Для этого используются статические диаграммы классов и объектов и динамические диаграммы последовательностей состояний и кооперации. Физическое проектирование предполагает построение программных компонентов из ранее определенных классов и объектов и размещение их на конкретных вычислительных устройствах. Разрабатываемые на этом этапе диаграммы - компонентов и развертывания. [12]

Тестирование и отладка программных продуктов

При тестировании программных продуктов применяются два основных метода тестирования - тестирование «черного» и «белого» ящика. Рассмотрим каждый их них подробнее.

Тестирование «черного ящика»

Известны: функции программы.

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

Тесты «черного» ящика демонстрируют:

· как выполняются функции программ;

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

· как вырабатываются результаты;

· как сохраняется целостность внешней информации.

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 1010 тестовых вариантов. Отметим также, что тестирование «черного ящика» не реагирует на многие особенности программных ошибок. [12]

Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними.

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

Методика тестирования программных систем

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

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

Охарактеризуем каждый шаг процесса тестирования.

1. Тестирование элементов. Цель - индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».



Рисунок 4.2.4. Спираль процесса тестирования ПС

2. Тестирование интеграции. Цель - тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика».

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

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

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

Ответ практика обычно основан на статистическом критерии: «Можно с 95%-ной уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет по меньшей мере 0,995».

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

,

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

С помощью уравнения (8.1) можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов. [12]

Отладка программного продукта

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

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