Моделирование аварийных ситуаций на опасных производственных объектах

_i - продолжительность эксплуатации оборудования в течение года, ч.

Выполненные расчеты показали, что частота исходного события для каждого технологического блока - разгерметизация или разрушение оборудования с выходом жидкой фазы, при реализации аварийных ситуаций составляет: блок №1 - 6,8510^-61/год; блок №2 - 1,3710^-41/год; блок №3 - 8,510^-51/год; блок №4 - 3,6510^-41/год; блок.

Для построения деревьев событий использовались условные вероятности приведенные в таблице 1.7.

"Дерево событий" анализа причины аварии и вероятности ее проявления в каждом блоке приведены на рисунках 1.8, 1.9, 1.10, 1.11

.

Таблица 1.7 - Условная вероятность мгновенного воспламенения и воспламенения с задержкой

Массовый расход истечения, кг/с	Условная вероятность мгновенного воспламенения	Условная вероятность последующего воспламенения при отсутствии мгновенного воспламенения	Условная вероятность сгорания с образованием избыточного давления при образовании горючего газопаровоздушного облака и его последующем воспламенении
Диапазон	Номинальное среднее значение	Газ	двухфазная смесь	жидкость	газ	двухфазная смесь	жидкость	газ	двухфазная смесь	жидкость
Малый (<1)	0,5	0,005	0,005	0,005	0,005	0,005	0,005	0,080	0,080	0,050
Средний (1 - 50)	10	0,035	0,035	0,015	0,036	0,036	0,015	0,240	0,240	0,050
Большой (>50)	100	0,150	0,150	0,040	0,176	0,176	0,042	0,600	0,600	0,050
Полный разрыв	Не определено	0,200	0,200	0,050	0,240	0,240	0,061	0,600	0,600	0,100

Рисунок 1.8 - "Дерево событий" анализа причины аварии и вероятности ее проявления на блоке №1

Рисунок 1.9 - "Дерево событий" анализа причины аварии и вероятности ее проявления на блоке №2



Рисунок 1.10 - "Дерево событий" анализа причины аварии и вероятности ее проявления на блоке №3

Рисунок 1.11 - "Дерево событий" анализа причины аварии и вероятности ее проявления на блоке №4

1.4 Математическая модель поражающих факторов при реализации различных сценариев развития аварийных ситуаций

При расчете значений критериев пожарной опасности при сгорании нефтепродуктов в качестве расчетного выбираем наиболее неблагоприятный вариант развития аварии (нормальной работы, аварии аппаратов или технологического процесса), при котором в открытое пространство поступает (или постоянно находится) максимальное количество наиболее опасных в отношении последствий пожара нефтепродуктов. Производим расчет для блока №3, так как в этом блоке находиться наибольшее количество вещества в одном аппарате (резервуар №48, V = 3000 м³).

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

а) происходит полное разрушение резервуара;

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

в) длительность испарения жидкости принимаем равной времени ее полного испарения, но не более 3600 с

Масса жидкости, поступившей в окружающее пространство при разгерметизации резервуара, определяем по формуле:

, (1.2)

где - масса жидкости, кг;

с_L - плотность жидкости, кг/м³;

V_R - объем жидкости в резервуаре, м³.

При проливе на неограниченную поверхность площадь пролива S (м²) жидкости определяем по формуле:

S = f_Р V_Ж, (1.3)

где f_Р - коэффициент разлития, м^-1 (допускаем равным 20 м^-1 при проливе на грунтовое покрытие);

V_Ж - объем жидкости, поступившей в окружающее пространство при разгерметизации резервуара, м³.

Интенсивность теплового излучения q, кВт/м², рассчитываем по формуле

q = E_f F_q , (4)

где E_f - среднеповерхностная плотность теплового излучения пламени, кВт/м²;

F_q - угловой коэффициент облученности;

- коэффициент пропускания атмосферы.

E_f принимаем на основе имеющихся экспериментальных данных из таблицы 8.

Таблица 8 - Среднеповерхностная плотность теплового излучения пламени

Топливо	Еf, кВт/м2, при d,	т, кг/(м2 с)
	10	20	30	40	50
Бензин	60	47	35	28	25	0,06
Дизельное топливо	40	32	25	21	18	0,04
Нефть	25	19	15	12	10	0,04

Рассчитываем эффективный диаметр пролива d, м, по формуле

, (5)

где S - площадь пролива, м².

Рассчитываем высоту пламени Н, м, по формуле

, (6)

где т - удельная массовая скорость выгорания топлива, кг/(м²·с);

_в - плотность окружающего воздуха, кг/м³;

g - ускорение свободного падения, равное 9,81 м/с².

Определяем угловой коэффициент облученности F_q по формуле

, (1.7)

где , (1.8)

где , (1.9)

S₁ = 2r/d, (1.10)

(r - расстояние от геометрического центра пролива до облучаемого объекта)

h = 2H/d; (1.11)

, (1.12)

B = (1 + S²)/(2S). (1.13)

Определяем коэффициент пропускания атмосферы по формуле

= exp [-7,0·10^-4 (r - 0,5d)]. (1.14)

Испарение жидкости из пролива

Интенсивность испарения W (кг/(м²с)) для ненагретых жидкостей с поверхности определяем по формуле:

, (1.15)

При проливе жидкости вне помещения допускается принимать = 1;

М - молярная масса жидкости, кг/кмоль;

Р_Н - давление насыщенного пара при расчетной температуре жидкости, кПа.

Массу паров жидкости т, поступивших в открытое пространство рассчитываем по формуле

т = W S_и T, (1.16)

где W- интенсивность испарения, кг/(с·м²);

S_и - площадь испарения (пролива), м².

Параметры волны давления при сгорании газопаровоздушных смесей в открытом пространстве

Избыточное давление р, кПа, развиваемое при сгорании газопаровоздушных смесей, рассчитываем по формуле

, (1.17)

где p₀ - атмосферное давление, кПа (допускается принимать равным 101 кПа);

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

m_пр - приведенная масса газа или пара, кг, рассчитанная по формуле

, (1.18)

где Q_сг - удельная теплота сгорания газа или пара, Дж/кг;

Z - коэффициент участия, который допускается принимать равным 0,1;

Q₀ - константа, равная 4,52·10⁶ Дж/кг;

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

Импульс волны давления i, Па·с, рассчитываем по формуле

. (1.19)

Произведем моделирование вероятных зон действия поражающих факторов для сценария наиболее опасного по последствиям развития аварийной ситуации (разгерметизация резервуара №48). Определение зон действия поражающих факторов при аварии, как избыточное давление и тепловое излучение при сгорании нефтепродукта, проводился с помощью программного обеспечения. Программа разработана на основе ГОСТ Р 12.3.047-98 "Пожарная безопасность технологических процессов".

Результаты расчета количества вещества участвующего в аварийной ситуации приведены в таблице 1.9.

Таблица 1.9 - количество вещества участвующего в аварийной ситуации

Поражающий фактор	Основной поражающий фактор	Количество опасного вещества, т
		участвующего в аварийной ситуации	участвующего в создании поражающих факторов
Блок №3
Пожар пролива	Тепловое излучение	1938	1938
Взрыв ТВС	Ударная волна	1938	?38,4
Огненый шар	Термическое поражение	1938	1938

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

В качестве исходных данных вводится:

- наименование вещества - бензин

- масса вещества, кг - 1938000

- площадь пролива, м² - 13500

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

Рисунок 1.12 - Набор данных

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

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

Рисунок 1.13 - Ввод максимального расстояния для расчета

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

Радиусы зон поражения при воздействии избыточного давления и при воздействии теплового излучения пожаров пролива приведены в таблицах 1.10, 1.11.

Рисунок 1.14 - Результаты расчета

Рисунок 1.15 - График зависимости избыточного давления от расстояния



Рисунок 1.16 - График зависимости избыточного давления от расстояния

Рисунок 1.17 - График интенсивности теплового излучения при пожаре пролива

Таблица 1.10 - Радиусы зон поражения при воздействии избыточного давления

Степень поражения	Избыточное давление, кПа	Радиус зоны, м
Полное разрушение зданий	100	89
50%-ное разрушение зданий	53	125
Средние повреждения зданий	28	183
Умеренные повреждения зданий	12	327
Нижний порог повреждения человека волной давления	5	653
Малые повреждения (разбита часть остекления)	3	1000

Таблица 1.11 - Радиусы зон поражения при воздействии теплового излучения пожаров пролива

Степень поражения	Интенсивность теплового излучения, кВт/м2	Радиус зоны, м
1	2	3
Без негативных последствий в течение длительного времени	1,4	200
Безопасно для человека в брезентовой одежде	4,2	132
Непереносимая боль через 20-30 с Ожог 1-й степени через 15-20 с Ожог 2-й степени через 30-40 с Воспламенение хлопка-волокна через 15 мин	7,0	106
Непереносимая боль через 3-5 с Ожог 1-й степени через 6-8 с Ожог 2-й степени через 12-16 с	10,5	89
Воспламенение древесины с шероховатой поверхностью (влажность 12%) при длительности облучения 15 мин	12,9	82
Воспламенение древесины, окрашенной масляной краской по строганой поверхности; воспламенение фанеры	17,0	74

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

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

Рисунок 1.18 - Ситуационный план при аварии в резервуарном парке хранения светлых нефтепродуктов

2. Технология отладки программы

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

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

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

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

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

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



Рисунок 2.1 - Процесс отладки программы

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

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

2.1 Причины возникновения ошибок

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

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

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

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

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

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

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

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

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

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

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

Существуют два типа программных ошибок:

а) Синтаксические ошибки, которые являются нарушениями правил языка программирования, они обычно выявляются во время компиляции.

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

2.2 Анализ синтаксических ошибок

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

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

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

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

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

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

2.3 Семантические (логические) ошибки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а) формирование критериев выделения маршрутов для тестирования;

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

2.4.1 Критерии выделения маршрутов

Критерии выделения маршрутов для тестирования соответствуют критериям определения структурной сложности программных модулей.

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

2.4.2 Стратегии упорядочения маршрутов

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



Рисунок 2.2 - Стратегии упорядочения маршрутов

Эти стратегии тестирования позволяют сосредоточить внимание разработчиков на анализе наиболее важных компонент программ. При стратегии 1 первоочередному тестированию подлежат маршруты, наиболее длинные по числу команд и по времени исполнения. Им соответствуют обычно маршруты с наибольшим объемом вычислений и преобразований переменных. Эта стратегия целесообразна при планировании тестирования программ, имеющих вычислительный характер обработки данных при небольшом числе логических условий и маршрутов исполнения программ. При стратегии 2 приоритет отдается маршрутам, наиболее сложным по числу анализируемых условий. Такая стратегия предпочтительна при тестировании логических программ с небольшим количеством вычислений. При обеих стратегиях на завершающие этапы тестирования остаются простые по вычислениям или по логике маршруты, для которых необходимы относительно короткие тесты. Данные о вероятности (частности исполнения) маршрутов или операторов программ помогают выделить интенсивно исполняемые компоненты программы, которые целесообразно подвергать наиболее тщательной проверке при стратегии 3. Априорно на базе представлений разработчика о динамике функционирования создаваемой программы может быть составлен первоначальный профиль программы. В профиле обычно содержится следующая информация: частота и длительность выполнения каждого оператора, вероятность выполнения каждого логического условия, предельные значения некоторых переменных, количество итераций в циклах. Эти данные для каждой программы могут получаться автоматически в процессе ее исполнения или обобщаться и уточняться по мере развития отладки и испытаний программ. В результате: выделяются наиболее активные компоненты программы, прошедшие наиболее тщательную проверку, а также компоненты, требующие повышенного внимания и подлежащие дополнительному тестированию вследствие малой частоты исполнения; статистика условных переходов и число итераций циклов дает информацию для обнаружения некоторых типов ошибок; длительность исполнения маршрутов позволяет оценивать среднюю длительность исполнения всего модуля, что особенно, важно для систем реального времени.

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

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

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

Затраты на разработку программных средств (З_пс) могут быть рассчитаны по следующей формуле:

З_пс = М+П_ок+З_о+З_д+О_сн+Р_пр+Р_н (руб.), где (3.1)

М - стоимость сырья и материалов;

П_ок - стоимость покупных комплектующих (руб.);

З_о - основная заработная плата разработчиков ПС (руб.);

З_д - дополнительная заработная плата разработчиков ПС (руб.);

О_сн - отчисления на социальные нужды (руб.);

Р_п - прочие прямые расходы (руб.);

Р_н - накладные расходы (руб.).

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

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

М = SQ_i*Ц_i*К_Т,i (руб.), где (3.2)

n - количество видов используемых материалов;

i - наименование соответствующего вида используемых материалов;

Q_i - расход на разработку материалов i-го наименования в соответствующих единицах измерения;

Ц_i - цена приобретения единицы материала i-го наименования (руб.);

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

Примем К_Т,i = 1,12

Расчет стоимости используемых материалов представлен в таблице 3.1.

Таблица 3.1 - Расчет стоимости используемых материалов

Наименование Материала	Ед. изм.	Цена за единицу (руб.)	Расход на разработку	Коэффициент, КТ	Сумма, руб.
Бумага для принтера А4 Папка для бумаг	пачка шт.	100,00 30,00	2 2	1,12 1,12	224,00 67,20
ИТОГО:					291,20

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

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

Пок = S N_i*Ц_i*К_Т,i (руб.), где (3.3)

i - наименование покупных изделий;

n - количество видов покупных комплектующих;

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

Ц_i - цена приобретения единицы покупных комплектующих i-го наименования (руб.).

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

Таблица 3.2 - Расчет стоимости покупных комплектующих

Наименование покупных комплектующих	Цена за ед-цу, руб.	Расход на разработку, шт.	Коэффициент, Кн	Сумма, руб.
USB-накопитель 1Гб CD MS Office 2000 C++Builder 6 Professional Windows XP Home Edition	250,00 2990,00 29300,00 2150,00	1 1 1 1	1,15 1,15 1,15 1,15	287,50 3438,50 33695,00 2472,50
ИТОГО:				39893,50

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

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

, где (3.4)

i - наименование категории разработчиков;

n - кол-во категорий разработчиков;

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

- часовая тарифная ставка разработчика i-ой категории.

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

- консультант (руководитель дипломного проекта);

- инженер-программист (дипломник).

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

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

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

,руб./час, где (3.5)

- месячный оклад разработчика i-ой категории, руб.;

- месячный фонд времени работы разработчика в часах.

Для данных расчетов примем:

=168 час;

Месячный оклад консультанта 12500 руб.

Месячный оклад инженера-программиста 6100 руб.

Тогда часовые ставки программиста и консультанта составляют, соответственно,

l_к = 12500/168 = 74,40 руб.

l_пр= 6100/168 = 36,30 руб.

Таблица 3.3 - Перечень этапов разработки и удельные веса в % их трудоемкости

Наименование этапов	Удельный вес трудоемкости этапа в % по категориям разработчиков
	Инженер-программист	Консультант
	%	Час.	%	Час.
Предпроектный анализ задач и формирование требований пользователя: постановка производственных задач.	7%	41,2	37%	8,88
Разработка концепции создания программного изделия, системы.	6%	35,3	12%	2,88
Разработка и согласование технического задания на создание программного средства	14%	82,3	11%	2,64
Разработка математического обеспечения (моделей, методов, алгоритмов)	1%	5,8	8%	1,92
Разработка структур данных	6%	35,3	5%	1,2
Разработка и отладка программного средства	33%	194,1	9%	4,86
Тестирование программы	5%	29,4	8%	1,92
Оформление проектной и эксплуатационной документации	28%	164,6	10%	2,4
Итого	100%	588	100%	24

Расчет основной заработной платы приведен в таблице 3.4.

Таблица 3.4 - Расчет основной заработной платы разработчиков информационной системы

Наименование этапов	Инженер-программист	Консультант	Всего по этапу
	Т, час	L руб./час	сумма, руб.	Т, час	l руб./час	сумма, руб.
Предпроектный анализ задач и формирование требований пользователя: постановка производственных задач.	41,2	36,3	1495,56	8,88	74,4	660,67	2156,23
Разработка концепции создания программного изделия, системы.	35,3	36,3	1281,39	2,88	74,4	214,27	1495,66
Разработка и согласование технического задания на создание программного средства	82,3	36,3	2987,49	2,64	74,4	196,41	3183,9
Разработка математического обеспечения (моделей, методов, алгоритмов)	5,8	36,3	210,54	1,92	74,4	142,85	353,39
Разработка структур данных	35,3	36,3	1281,39	1,2	74,4	89,28	1370,67
Разработка и отладка программного средства	194,1	36,3	7045,83	4,86	74,4	361,58	7407,41
Тестирование программы	29,4	36,3	1067,22	1,92	74,4	142,85	1210,07
Оформление проектной и эксплуатационной документации	164,6	36,3	5974,98	2,4	74,4	178,56	6153,54
Итого	588,00	Х	21344,4	24	Х	1986,47	23330,87

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

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

З_Д = З_о* К_Д% /100% (руб.), где (3.6)

З_о - основная заработная плата разработчиков (руб.);

К_Д% - коэффициент дополнительной заработной платы.

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

З_Д =23330,87* 20%/100%=4666,17 руб.

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

О_сн = (З_о+З_Д)*К_сн% /100% (руб.),где (3.7)

К_сн % - коэффициент отчислений на социальные нужды.

К_сн в настоящее время составляет 34%

Отчисления на социальные нужды составят:

О_сн = ( 23330,87 + 4666,17) * 34 % / 100%=8090,99 руб.

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

К прочим прямым расходам, понесенным разработчиком, следует отнести:

- затраты на приобретение специальной литературы, а именно книги "C++ Builder 6 справочное пособие" стоимостью 450 руб.;

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

Всего прочие прямые расходы составили 630 руб.

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

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

Они рассчитываются по формуле:

Р_н= З_о* К_н% /100% (руб.), где (3.8)

К_н% - коэффициент накладных расходов.

При К_н=65 % сумма накладных расходов составит :

Р_н= 23330,87 * 65% /100% = 15165,07 руб.

Все расчеты затрат на разработку сведены в таблицу (таблица 3.5)

Таблица 3.5 - Общие расчеты затрат

Наименование статьи расходов	Сумма, руб.
Материалы	291,20
Покупные комплектующие	39893,50
Основная заработная плата разработчиков данного программного средства	23330,87
Дополнительная заработная плата разработчиков данного программного средства	4666,17
Отчисления на социальные нужды	8090,99
Прочие прямые расходы	630,00
Накладные расходы	15165,07
ИТОГО: 7279,23	92067,80

По обобщенным технико-экономическим показателям разработка программного обеспечения является экономически целесообразной.

4. Разработка мероприятий по снижению зрительного утомления оператора персонального компьютера

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

Анализ исследований жалоб пользователей ПЭВМ проводимых в различных странах (России, Германии, США, Японии, Болгарии, Дании, Франции) начиная с 2000 г, позволил разделить их на следующие группы:

а) зрительный дискомфорт;

б) дискомфорт в области опорно-двигательного аппарата: шее, спине;

в) дискомфорт в области кисти и/или кистей рук;

г) нервно-эмоциональный дискомфорт.

4.1 Зрительный дискомфорт

Работа за дисплеями негативно влияет на глаза пользователя. С 80-х годов у пользователей компьютеров отмечается специфическое зрительное утомление, получившее общее название "компьютерный зрительный синдром" (КЗС) (CVS-Computer Vision Syndrome). Причин его возникновения несколько, и, прежде всего - сформировавшаяся за миллионы лет эволюции зрительная система человека, которая приспособлена для восприятия объектов в отраженном свете (картин природы, рисунков, печатных текстов), а не для работы с дисплеем. Изображение на дисплее принципиально отличается от привычных глазу объектов наблюдения и не соответствует естественным цветам.

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

Компьютерный зрительный синдром может привести к более тяжелым последствиям: снижению остроты зрения, замедленной перефокусировке, двоению предметов. Эти явления объединяются одним термином "астенопия" - отсутствием силы зрения. Астенопия - это любые субъективные зрительные и глазные симптомы, являющиеся результатом зрительной деятельности. Симптомы астенопии можно классифицировать следующим образом:

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

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

Практически все пользователи при непрерывной, в течение шести часов, работе за компьютером жалуются на появление признаков КЗС. У некоторых пользователей признаки астенопии наступают гораздо раньше - через 4 или 2 часа непрерывной работы за ПЭВМ. Для снижения риска появления КЗС и зрительного утомления необходимо выполнять требования к видеодисплейным терминалам (ВДТ), выполнение общих требований к организации рабочего места оператора ПЭВМ.

4.2 Требования к устройствам отображения информации (мониторам)

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

Нормативные документы требуют от монитора предусматривать регулирование яркости и контрастности, которые позволяют уменьшить зрительное утомление у оператора ПЭВМ (СанПин 2.2.2/2.4.1340-03).

Обеспечение яркости должно быть не менее 35 кд/м², и практически все современные устройства это требование легко выполняют. Максимальная яркость ЭЛТ-мониторов составляет 100-120 кд/м², у ЖК-мониторов в этой области нет конкурентов, так как ограничений для повышения яркости нет. Максимальная величина яркости ЖК-мониторов определяется характеристиками люминесцентных ламп, которые используются для подсветки экрана. Не является проблемой получение яркости в диапазоне 200-250 кд/м². Хотя технически вполне возможно её увеличение до значительно более высоких значений, этого не делают, чтобы не ослепить пользователя. Не стоит забывать, что яркость светящихся поверхностей, находящихся в поле зрения не должна превышать 200 кд/м².

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

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

Рисунок 4.1 - Точки измерения яркости белого поля экрана

Определяем среднее значение яркости рабочего поля:

Находим точку с максимально отличающейся от средней яркостью и определяем эту разницу: ДL=42?39,6=2,4 кд/м²

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

(4.1)

В данном случае, дLэ = 2,4 / 39,6 *100% = 6 %, это значение является допустимым, значит, дополнительные мероприятия не требуются.

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

Изображение на ЭЛТ-мониторах неустойчиво, оно только кажется постоянным вследствие низкой частотной восприимчивости глаза. Временная нестабильность изображения (мерцание) - это восприятие изменяющейся яркости с течением времени. Мерцание зависит от различных факторов, таких как свойства свечения, степень яркости мерцающего изображения и т. д. Для дисплеев с ЭЛТ частота обновления изображения должна быть не менее 75 Гц при всех режимах разрешения экрана, и не менее 60 Гц для ЖК.

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