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

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

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

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

Рис. 1.1. Уровни моделей данных

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

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

Такие базы данных называют операционными или транзакционными, поскольку они характеризуются огромным количеством небольших транзакций, или операций записи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступ к базам транзакций, принято называть системами оперативной обработки транзакций (OLTP - On-Line Transactional Processing) или учетными системами.

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

Реляционная архитектура. С появлением персональных компьютеров получил распространение способ обработки данных, ориентированный на пользователя. Наиболее простыми в реализации оказались системы управления реляционными базами данных (DB2, Oracle, Sybase, Interbase, Access, Microsoft SQL Server и т.д.), использующие наглядные двумерные модели данных (таблицы). Кажущаяся легкость разработки породило серьезное заблуждение, что с помощью непроцедурного языка запросов (SQL) можно реализовать практически все. И если информационный объект простой (например справочник), то проблем нет. Но проблема возникает, когда разработчик приложений пытается втиснуть отношения внутри сложного информационного объекта (реального мира) в рамки, ограниченные простыми реляционными технологиями. Результатом становится нагромождение таблиц, сложным образом взаимодействующих между собой и плохо отражающих реальные отношения между данными. Также связи между этими таблицами часто находятся не в базах данных, где ими можно управлять более эффективно, а скрыты в прикладных программах. И, конечно, все это требует значительных вычислительных ресурсов. Не секрет, что реляционная модель данных - одно из самых серьезных препятствий для эффективной работы приложений. Поэтому закономерно появление постреляционных СУБД, в которых быстродействие и масштабируемость транзакционной многомерной модели данных сочетаются с мощностью и гибкостью объектной технологии. Многомерные модели данных значительно упрощают задачи моделирования данных, поскольку сложные структуры реального мира можно отображать, не игнорируя реальность с учетом доступности для технологии. Кроме того, такие модели обеспечивают значительный выигрыш в скорости при выполнении сложных задач обработки данных. В качестве примера можно привести полетное задание как информационный объект. Если в реляционной СУБД это набор таблиц (файлов) с реквизитами, то в многомерной базе данных все реквизиты полетного задания находятся в как бы одном файле со всеми необходимыми связями. И доступ к ним осуществляется напрямую методом навигации. Поэтому скорость доступа не зависит от объема базы данных.

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

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

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

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

Этим объясняется интерес к объединению и анализу данных учетной системы с помощью технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка). Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации. Исходные данные преобразуются таким образом, чтобы наглядно отразить структуру деятельности предприятия.

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

расчеты и вычисления по нескольким измерениям, иерархиям и/или членам;

анализ трендов;

выборка подмножеств данных для просмотра на экране;

углубление в данные (drill down), для просмотра информации на более детализированном уровне;

переход к детальным данным, лежащим в основе анализа;

поворот таблицы отображаемых данных.

2.2 Сравнение архитектур

Как правило, учетные системы работают с реляционными базами данных. Для OLAP-приложений же разработана специальная многомерная модель, которая позволяет более эффективно использовать данные, накопленные в оперативных системах. Технология оперативной аналитической обработки ориентирована на представление данных в виде массивов. Под массивом понимается последовательность элементов, например продажи продукта по рынкам/временным периодам, или доход по времени/региону [3].

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

Табл. 2.1 Сравнение реляционных и OLAP терминов и понятий

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

Табл. 2.2 Cравнение системных характеристик OLTP и OLAP

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

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

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

Данные в учетных системах часто "зашумленные", неполные и несогласованные.

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

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

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

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

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

2.3 Обоснование выбранной архитектуры

3. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ БД И ОРГАНИЗАЦИИ ИНФОРМАЦИОННОГО ОБМЕНА

3.1 Технологические возможности сбора и хранения данных в ФОМС

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

1. Основные процедуры обмена информацией осуществляются с учетом федерального регистра лиц, имеющих право на ГСП (далее - Федеральный регистр), на уровне ОПФР и ТФОМС с подключением, в случае необходимости, районных управлений ПФР и филиалов территориальных фондов ОМС.

2. Территориальные фонды ОМС по результатам проведения медико-экономической экспертизы счетов и реестров, переданных фармацевтическими организациями, направляют запрос в ОПФР по установленной форме на бумажном носителе и файл с перечнем лиц, указанных в запросе, в формате, утвержденном в действующей редакции настоящего Порядка, с целью подтверждения факта права на получение гражданами ГСП в виде набора социальных услуг в соответствии со ст. 6.2. п. 1 пп. 1 Федерального закона от 22.08.2004 N 122-ФЗ, в следующих случаях:

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

- полного отсутствия сведений о СНИЛС гражданина;

- прибытие гражданина с территории другого субъекта Российской Федерации.

Срок оформления запроса по установленной форме - не более 10 календарных дней с момента завершения медико-экономической экспертизы. Форма запроса и формат файла приведены в Приложении N 1.

3. Отделения Пенсионного фонда Российской Федерации:

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

- направляют в ТФОМС ответ на запрос, подписанный уполномоченным сотрудником ОПФР, и файл с данными на граждан, указанных в запросе по установленной форме, в формате, утвержденном в действующей редакции "Порядка обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами обязательного медицинского страхования в ходе реализации Федерального закона от 22.08.2004 N 122-ФЗ "О внесении изменений в законодательные акты Российской Федерации и признании утратившими силу некоторых законодательных актов Российской Федерации в связи с принятием Федеральных законов "О внесении изменений и дополнений в Федеральный закон "Об общих принципах организации законодательных (представительных) и исполнительных органов государственной власти субъектов Российской Федерации" и "Об общих принципах организации местного самоуправления в Российской Федерации" (Приложение N 2). Срок обработки запроса и передачи в ТФОМС ответа не более 10 дней с момента поступления запроса.

4. После получения ответа на запрос от ОПФР территориальные фонды ОМС:

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

- готовят и передают (отдельными файлами) сведения о суммарных фактических показателях объемов и стоимости медицинской помощи по программе ОМС и дополнительном лекарственном обеспечении, предоставленных указанным гражданам, в ОПФР, в соответствии с форматами, указанными в действующей редакции "Порядка обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами обязательного медицинского страхования в ходе реализации Федерального закона от 22.08.2004 N 122-ФЗ "О внесении изменений в законодательные акты Российской Федерации и признании утратившими силу некоторых законодательных актов Российской Федерации в связи с принятием Федеральных законов "О внесении изменений и дополнений в Федеральный закон "Об общих принципах организации законодательных (представительных) и исполнительных органов государственной власти субъектов Российской Федерации" и "Об общих принципах организации местного самоуправления в Российской Федерации".

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

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

3.2 Использование каналов связи

Передача данных регистров и реестров осуществляется одним пакетом в виде архивированного ZIP-, RAR- или ARJ-файла. Состав файлов в пакете соответствует виду регистра или реестра.

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

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

ЛПУ передает в ТФОМС информационную посылку, содержащую три файла (П, М, Р). ФО передает в ТФОМС информационную посылку, содержащую два файла (П и Л), отдельно - по гражданам, зарегистрированным на территории данного субъекта Российской Федерации, и отдельно - по гражданам, временно прибывшим с территорий других субъектов Российской Федерации. ТФОМС передает в ФО информационную посылку, содержащую два файла (П и ОЛ), отдельно - по гражданам, зарегистрированным на территории данного субъекта Российской Федерации, и отдельно - по гражданам, временно прибывшим с территорий других субъектов Российской Федерации.

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

Таблица ПРОТОКОЛ СИНТАКСИЧЕСКОГО КОНТРОЛЯ

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

4. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

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

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

4.1 Анализ трудового процесса создания функциональной модели ФОМС

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

· Подготовка к предпроектному обследованию ФОМС;

· Проведение сбора материалов;

· Обработка и систематизация полученной информации;

· Построение организационной модели;

· Анализ информационных и функциональных связей в модели.

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

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

4.2 Анализ этапов разработки и получение некоторых количественных характеристик трудового процесса

Оценим те вредные факторы, которым подвергается разработчик в процессе разработки модели и эксплуатации комплекса программно-аппаратных средств [10].

В процессе анализа мы будем опираться на руководство - «Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса», утвержденные Госкомсанэпиднадзором РФ Руководство- Р 2.2.755-99. По нему труд классифицируется по четырем классам: оптимальные условия труда (класс 1.0); допустимые условия труда (класс 2.0); вредные условия труда (класс 3). Вредные условия труда по степени превышения гигиенических нормативов и выраженности изменении в организме работающих, подразделяются на 4 степени вредности: 1 степень 3 класса (3.1); 2 степень 3 класса (3.2); 3 степень 3 класса (3.3); 4 степень 3 класса (3.4). Опасные (экстремальные) условия труда (класс 4.0).

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

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

Табл. 5.1. Воздействующие факторы

4.3 Разработка мероприятий, снижающих воздействие выявленных вредных факторов. Анализ опасности на этапе проектирования, построение «дерева опасностей»

В результате подсчёта общей напряжённости труда она равняется 3.1 единиц. Число факторов с оценкой 1.0 составило 7, с оценкой 2.0 составило 5, с оценкой 3.1 составило 8 и с оценкой 3.2 составило 1. Данный показатель характеризует в целом уровень вредности условий труда и указывает на то, что если не прибегать к организационным мероприятиям по снижению влияния вредных факторов на организм разработчика, у него могут развиться профзаболевания [11].

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

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

2. Восприятие сигналов (информации) и их оценка, степень сложности задания. Разработчику на каждом шаге необходимо учитывать влияние принятых решений на всю модель в целом. При этом необходимо оценивать множество параметров - функциональность, информативность, степень взаимодействия функциональных элементов и т.д. Эта задача значительно более сложная, чем рассмотренная в п.1. С целью эффективного решения данных проблем при разработке сложной организационной структуры создается группа разработчиков. Часть группы занимается сбором опросных материалов, системным анализом, другая часть занимается проектированием элементов структуры. Для эффективного обмена информацией внутри и между группами необходима поддержка со стороны CASE-инструментария (групповые проекты).

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

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

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

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

5. Наблюдение за экранами видеотерминалов. В процессе проектирования устройства с помощью CASE-инструментария разработчик большую часть времени проводит за экраном монитора, которым оснащено его рабочее место. Как правило, монитор построен на базе ЭЛТ. Излучения такого монитора оказывают самое пагубное влияние на здоровье человека, в первую очередь на глаза. Гигиенические требования к видиодисплейным терминалам изложены в «Санитарные правила и нормы СанПиН 2.2.2.542-96».

Согласно гигиеническим нормам освещенность на поверхности стола и клавиатуре должна быть не менее 300 люкс, а вертикальная освещенность экрана - всего 100-250 люкс. Исследования физиологов и гигиенистов убедительно доказали, что и полутьма, и слишком высокая освещенность экрана приводят к быстрому зрительному утомлению. Размещать компьютер рекомендуется так, чтобы свет (естественный или искусственный) падал сбоку, лучше слева, это избавит от мешающих теней и поможет снизить освещенность экрана. В качестве источников освещения рекомендуется применять люминесцентные лампы типа ЛБ со светильниками серии ЛПО36 с зеркализованными решетками. Лампы накаливания лучше использовать для местного освещения зоны рабочего документа

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

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

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

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

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

4.4 Экологичность проекта

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

1. Низкоэнергетическое рентгеновское излучение, генерируемое монитором с ЭЛТ. Спектр излучений генерируемых монитором с ЭЛТ очень широк. В него попадает и рентгеновское излучение. Использование всевозможных экранирующих устройств не даёт ощутимых результатов по значительному снижению уровня рентгеновского излучения. Для устранения влияния на оператора ЭВМ рентгеновского излучения необходимо применять мониторы с жидкокристаллическими экранами или что-то подобное.