Подсистема эксплуатационного обслуживания в ИС СН

Реферат

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

 
Содержание
Реферат 3
Введение 7
1 Анализ структуры ИС СН и структуры системы контроля функционирования 8
1.1 Назначение и основные структурные элементы информационной системы специального назначения 8
1.2 Автоматизированный информационно-управляющий комплекс 11
1.3 Система передачи данных 13
1.4 Система контроля и управления функционированием 13
1.5 Система хранения данных 14
1.6 Система защиты информации 14
1.7 Программное обеспечение 14
1.8 Комплекс программ «Системный КТТ» 21
2 Постановка задачи на разработку подсистемы эксплуатационного обслуживания 27
2.1 Недостатки существующей системы 27
2.2 Требования к подсистеме эксплуатационного обслуживания и управления функционированием. 27
2.3 Библиотека ITIL 34
2.4 Этапы разработки подсистемы 41
3 Анализ существующих программных решений в области контроля и управления функционированием программно-технических средств 42
3.1 Описание существующих программных решений 42
3.2 Выбор программного решения 50
3 Анализ систем управления базами данных для подсистемы эксплуатационного обслуживания в ИС СН 51
4 Разработка программных решений по созданию подсистемы, разработка программного модуля. 53
4.1 Существующие алгоритмы функций эксплуатационного обслуживания 53
5 Экономический раздел дипломного проекта 69
5.1 Общие сведения 69
5.2 Бизнес-план 69
5.3 Организационный план 71
5.4 Расчет договорной цены 75
5.5 Экономическая целесообразность 83
5.6 Вывод по пятому разделу 85
6 Экологичность и безопасность 86
6.1 Общие сведения 86
6.2 Характеристика условий труда 86
6.3 Анализ условий труда на рабочем месте 87
6.4 Постановка задачи 89
6.5 Разработка технических средств и организационных мероприятий 90
6.6 Расчетная часть 91
6.7 Вывод по седьмому разделу 99


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

Анализ структуры ИС СН и структуры системы контроля функционирования

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

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


Рисунок 1.1– Структурно-функциональная организация ИС СН
Головной объект ИС СН - управляющий объект, с которого обеспечивается управление главными объектами ИС СН.
Главный объект (ГО) - управляющий объект, с которого обеспечивается управление промежуточными объектами ИС СН.
Главный объект подчиняется непосредственно головному объекту и находится на втором уровне иерархии ИС СН. Совокупность ГО и подчиненных объектов, образуют подсистему управления. Таким образом, ГО располагается на верхнем уровне иерархии каждой подсистемы управления.
Промежуточный объект (ПО) - управляющий объект, с которого обеспечивается управление объектами исполнителями ИС СН.
Промежуточный объект располагается на уровне между ГО и объектами-исполнителями (ОИ). ПО может непосредственно управлять любым подчиненным ему ОИ или совокупностью подчиненных ему ОИ.
Объект исполнитель (ОИ) - объект нижнего уровня иерархии в подсистеме управления и не имеет подчиненных и таким образом не может управлять никакими объектами и является оконечным элементом в иерархии системы управления.
ИС СН состоит из:
автоматизированных информационно-управляющих комплексов (АИУК);
системы передачи данных (СПД);
системы контроля и управления функционированием (СКУФ);
системы хранения данных;
системы защиты информации;
программного обеспечения.



Автоматизированный информационно-управляющий комплекс

Основным элементом ИС СН является автоматизированный информационно-управляющий комплекс (АИУК). АИУК – аппаратно-программный комплекс, предназначенный для сопряжения и взаимодействия с системами управления органов исполнительной власти. АИУК устанавливаются на всех объектах ИС СН различных уровней.
АИУК представляет собой аппаратно-программный комплекс, разрабатывается по единому замыслу, характеризуются цельной архитектурой и комплексным алгоритмом функционирования аппаратных и программных средств, имеет оптимально сбалансированную архитектуру, которая предусматривает возможность наращивания и модернизации аппаратных и программных средств в процессе эксплуатации.
АИУК организована по модульному принципу, что обеспечивает возможность изменения состава технических средств АИУК в зависимости от возлагаемых на него функций и возможность использования его на объектах системы всех уровней управления.
Аппаратный контур АИУК состоит из:
унифицированного сервера инфокоммуникаций в защищенном исполнении (УСК);
унифицированного сервера обработки и хранения данных (УСОХД);
коммутатор;
средство передачи данных;
автоматизированных рабочих мест должностных лиц (АРМ ДЛ);
автоматизированного рабочего места администратора безопасности информации (АРМ АБИ).
Организационно-техническая структура АИУК представлена на рисунке 1.2. Передача информации между АИУК осуществляется через цифровую сеть связи.


Рисунок 1.2 – Организационно-техническая структура АИУК

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

Система передачи данных

Система передачи данных обеспечивает обмен информацией между взаимодействующими АИУК различных уровней управления в ИС СН по существующим каналам связи и передачи данных.

Система контроля и управления функционированием

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

Система хранения данных

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

Система защиты информации

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

Программное обеспечение

Программное обеспечение (ПО) АИУК (см. рисунок 1.3) в соответствии с функциональным назначением подразделяется на следующие компоненты:
общее программное обеспечение (ОПО);
общесистемное программное обеспечение (ОСПО);
специальное программное обеспечение (СПО).
Структура программного обеспечения АУИК представлена на рисунке 1.3.
Общее программное обеспечение АИУК (см. рисунок 1.3) включает в себя:
операционная система (ОС);
системы управления базами данных (СУБД);
программный компонент гипертекстовой обработки данных (ПК ГОД).
Операционная система – обеспечивает управление аппаратными ресурсами и средствами общесистемного и специального программного обеспечения.
Функционирование программных средств АИУК осуществляется в среде защищенной ОС «AstraLinux Special Edition» РУСБ.10015-01.
ОС AstraLinux Special Edition является сертифицированной ОС по требованиям безопасности. Она предназначена для применения в информационных (автоматизированных) системах в защищенном исполнении, обрабатывающих информацию ограниченного распространения.
Система управления базами данных (СУБД) - комплекс средств в составе общего программного обеспечения, реализующий функции организации и хранения информации, а также доступа к хранимой информации. База данных АИУК управляется СУБД «PostgreSQL».
PostgreSQL – это объектно-реляционная система управления базами данных. PostgreSQL поддерживает стандарт SQL и предлагает множество возможностей, таких как:
комплексные запросы;
внешние ключи;
триггеры;
представления (views);
транзакционная целостность;
мандатный и дискреционный способ разграничения доступа к данным;
многоверсионное управление параллельным доступом.
 
Рисунок 1.3 – Структура программного обеспечения АИУК

Также, возможности PostgreSQL могут быть расширены путём добавления новых:
типов данных;
функций;
операторов;
агрегатных функций;
индексных методов;
процедурных языков.
Комплекс программ гипертекстовой обработки данных (КП ГОД) предназначен для обеспечения доступа к гипертекстовым данным расположенным на сервере УСОХД и просмотра этих данных на АРМ ДЛ с использованием веб-браузера Mozilla FireFox.
Общесистемное программное обеспечение представляет собой совокупность программных средств, обеспечивающих унифицированную среду и программные интерфейсы для функционирования задач СПО, обеспечивающих:
гарантированные услуги по защищенному хранению и обработке данных в едином адресном пространстве ИС СН,
синхронный/асинхронный обмен документами и сообщениями, автоматическую адаптивную маршрутизацию информационных потоков с использованием разнородных транспортных сетей и каналов связи,
реализация управления средствами коммуникаций на уровне ЛВС;
наличие управления средствами коллективного пользования (электронная почта, видеоконференция, IP-телефония, табло коллективного доступа);
управление средствами администрирования информационного обеспечения;
возможность управления средствами коммуникаций, поддерживающих распределенные приложения, приложения, нуждающиеся в доступе к удаленным данным, и взаимодействие приложений в гетерогенных или гомогенных сетевых средах;
реализация транзакций, обеспечивающих изменение данных и хранящих «историю» изменений в целях обеспечения возможности восстановления данных в случае невозможности выполнения всего блока операций.
ОСПО АИУК представлено на рисунке 1.4.


Рисунок 1.4 – Общесистемное ПО АИУК

Общесистемное программное обеспечение АИУК включает в себя следующие комплексы программ (КП):
КП «Средства ведения ИЛО», предназначенный для актуализации, поддержки целостности, полноты и непротиворечивости данных в системах: классификации и кодирования информации; нормативно-справочной информации; унифицированных форм документов;
КП «Программные средства единого геоинформационного обеспечения ИС СН», предназначенный для обеспечения должностных лиц АИУК средствами обработки геопространственных данных;
КП «Система отображения информации коллективного пользования», предназначенный для представления результатов решения оперативных и информационных задач СПО на средства отображения информации коллективного пользования;
КП «Удостоверяющий центр», предназначенный для управления ключами электронно-цифровой подписи должностных лиц АИУК и обеспечивает автоматизированный контроль выполнения сертификатов в удостоверяющих центрах;
КП «Средства ведения ИЛО», обеспечивающий ведение информационного и лингвистического обеспечения, а также предоставление доступа пользователей к информационным ресурсам ИС СН: классификаторам, унифицированным формализованным документам, нормативно-справочной информации, словарям терминов и определений, онтологиям.
КП «Видеоконференцсвязь», предназначенный для защищенной видео- и аудиосвязи между должностными лицами АИУК в режиме «видеоконференцсвязь»;
КП «Средства общесистемной сервисной шины», предназначенный для взаимодействия всех компонентов, а также для взаимодействия с СПО на основе веб-сервисов;
КП «Системный КТТ», предназначенный для обеспечения целостного и комплексного контроля за функционированием АИУК и эффективным управлением программно-техническими средствами, а также проведения технического обслуживания АИУК без нарушения функционирования и снижения показателей надёжности;
КП «Управление средствами защиты», предназначенный для обеспечения защиты от несанкционированного доступа к информации, содержащей конфиденциальные сведения, а также управления комплексом средств защиты ИС СН.
«Информационно-лингвистическое обеспечение» (ИЛО), включающее в свой состав информационную базу, представляющую собой совокупность баз данных и массивов (массивов документов) ИС СН с оперативной информацией и условно-постоянной информацией.
Специальное программное обеспечение (СПО) включает средства обеспечения информационной деятельности должностных лиц, а также информационно-расчетные задачи, обучающие и др. программные средства, предназначенные для решения функциональных задач автоматизации процессов повседневной и учебной деятельности должностных лиц ИС СН.
СПО АИУК включает в себя:
КП «Сбора и обработки информации», предназначенный для информационного обеспечения процессов подготовки и принятия решения, а также предоставления обобщенной информации о составе и состоянии объектов ИС СН;
КП «Экологической обстановки» предназначен для информационного обеспечения процессов подготовки и принятия решения, а также для предоставления обобщенной информации об экологической обстановке.
Инструментальные средства разработки ПО включают в себя:
среду разработки «Mono». Mono – проект по созданию системы .NET Framework на базе свободного программного обеспечения. Mono включает компилятор языка C#, среду исполнения .NET, отладчик, а также ряд библиотек, включая реализацию WinForms, ADO.NET и ASP.NET, а также компиляторы smcs (для создания приложений для Moonlight) и vbc (для приложений, написанных на VB.NET).;
среду разработки «Qt Creator» - кроссплатформенная свободная интегрированная среда разработки для разработки на С, С++ и QML. Включает в себя графический интерфейс отладчика и визуальные средства разработки интерфейса как с использованием QtWidgets, так и QML. Основная задача Qt Creator - упростить разработку приложения с помощью фреймворка Qt на разных платформах. Поэтому среди возможностей, присущих любой среде разработки, есть и специфичные, такие как отладка приложений на QML и отображение в отладчике данных из контейнеров Qt, встроенный дизайнер интерфейсов как на QML, так и на QtWidgets.;
среду разработки web-приложений. В web-приложения входят web-сервер Apache и модуль обработки web-сервер Mono. Apache позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и так далее. Web-сервер Mono предназначен для обработки запросов и обеспечения доступа к БД.

Комплекс программ «Системный КТТ»

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



Рисунок 1.7 - Структурная схема КП «Системный КТТ»

Система контроля и управления функционирования образует контрольно-технологический тракт (КТТ), объектами контроля которого являются:
ИС СН в целом;
программно-технический комплекс;
средства передачи данных;
информационные ресурсы;
программные процессы;
сервисы;
аппаратные средства до элементов замены.
Система контроля и управления функционированием имеет иерархическую организационно-техническую структуру, отражающую структуру системы. КП «Системный КТТ» контролирует и управляет как ИС СН в целом, так и отдельными АИУК. КП «Системный КТТ» имеет два уровня:
системный;
объектовый.
На системном уровне КП обеспечивается решение следующих задач:
непрерывный контроль состояния объектов системы, выдача данной информации по запросу или изменению состояния объекта на вышестоящие и взаимодействующие объекты системы;
приема информации о состоянии подчиненных и взаимодействующих объектов;
автоматического формирования графа системного уровня на основе оперативной структуры управления;
отображение на АРМ администратора структуры системы, состояния АИУК и системы в целом;
структура и состояние элементов системы должно отображаться, с использованием ГИС технологии, на картографическом фоне с привязкой к местам дислокации;
проведение необходимых расчетов, обобщений, подготовка справочной информации, функциональное преобразование информации в обобщенные показатели состояния работоспособности системы;
изменение структуры и режимов работы объектов системы.
Основная роль КП «Системный КТТ» системного уровня заключается в обеспечении администратора КП «Системный КТТ» интегрированной информацией о состоянии ИС СН в целом и ее элементов (АИУК) в отдельности. Общая схема системного уровня представлена на рисунке 1.8.


Рисунок 1.8 - Общая схема системного уровня КП «Системный КТТ»

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



Рисунок 1.9 - Общая схема объектового уровня КП «Системный КТТ»

Одной из основных задач КП «Системный КТТ» является интегрированная оценка состояния информационных ресурсов и объекта в целом. В качестве исходной информации для формирования состояния используется информация об элементах контроля: управляющем, информационно-аналитическом и контрольно-технологическом трактов, системы защиты информации.
Подсистема управления и дистанционного мониторинга аппаратным и программными средствами обеспечивает решение следующих задач:
контроль периферийных устройств;
контроль ресурсов и процессов на АРМ.
Подсистема управления и мониторинга сетевого обмена
сбор статистической информации о переданном и полученном трафике на коммутаторах;
поддержка постоянного соединения и обмена между клиентом и сервером, возобновление соединения в случае разрыва;
посылка оперативных сигналов о неисправностях сетевого обмена администратору.
Подсистема управления эксплуатационным обслуживанием обеспечивает решение следующих задач:
оперативная поддержка пользователей;
ведение базы знаний неисправностей и их устранений;
учет программно-аппаратных средств;
планирование работ по техническому обслуживанию.
Подсистема эксплуатационного обслуживания базируется на рекомендациях из библиотеки ITIL (Information Technology Infrastructure Library).
Подсистема хранения информации и формирования отчетов обеспечивает решение следующих задач:
хранение информации в БД о статусе системы в целом в моменты опроса;
хранение информации в БД о статусе ТС вплоть до периферийных устроств в моменты опроса;
хранения информации в БД о запущенных программных процессах в моменты опроса;
хранение сетевой статистической информации в БД;
хранение информации в БД о действиях системы контроля и управления функционированием над программными процессами и ТС.


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

Недостатки существующей системы

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

Требования к подсистеме эксплуатационного обслуживания и управления функционированием.

Подсистеме эксплуатационного обслуживания предъявляются следующие требования:
обеспечение повседневной деятельности эксплуатационной службы;
создание графиков рабочих смен;
создание графиков технического обслуживания;
ведение учетных данных по автоматизированным рабочим местам;
функционирование в ОС Astra Linux;
использование СУБД PostgreSQL.

Разрабатываемая подсистема эксплуатационного обслуживания и управления функционированием должна обеспечивать:
создание единой точки взаимодействия пользователей и сотрудников службы (на федеральном и региональном уровнях);
прием и регистрацию заявок пользователей;
определение срочности выполнения заявок и контроль сроков решения заявок;
информирование пользователей о статусе их заявок;
фиксирование способов решения заявок и инцидентов в базе знаний;
передачу заявок и инцидентов для решения между уровнями;
сбор статистики и анализ причин возникающих сбоев и отказов АИУК;
создание графиков рабочих смен;
создание графиков ТО;
ведение учетных данных по АРМ.
Подсистема эксплуатационного обслуживания и управления функционированием должна охватывать поддержку пользователей на федеральном и региональном уровнях.
В рамках федерального уровня осуществляется:
поддержка инфраструктуры федерального уровня;
решение инцидентов, возникающих на федеральном уровне;
решение инцидентов, которые не могут быть решены на региональном уровне.
В рамках регионального уровня осуществляется:
поддержка инфраструктуры регионального и территориального уровня;
решение инцидентов, возникающих на региональном и территориальном уровне;
передача инцидентов, которые не могут быть решены на федеральном уровне.
В рамках подсистемы эксплуатационного обслуживания и управления функционированием используются следующие основные понятия:
служба поддержки пользователей – совокупность сотрудников, ответственных за взаимодействие с пользователями (диспетчеры), а также из специалистов по направлением, ответственных за решение заявок (специалисты);
федеральная Служба поддержки пользователей – Служба поддержки пользователей, ответственная за поддержку пользователей на федеральном уровне и координирующая работу региональных служб поддержки пользователей. Данная Служба может быть создана, как на базе существующих подразделений (например, на базе вычислительных центров федерального уровня), так и в качестве выделенного подразделения;
региональная Служба поддержки пользователей – Служба поддержки пользователей, ответственная за поддержку пользователей на региональном и соответствующем территориальном уровнях и взаимодействующая с федеральной Службой поддержки пользователей. Данная Служба может быть создана, как на базе существующих подразделений (например, на базе вычислительных центров регионального уровня), так и в качестве выделенного подразделения;
рабочая группа – совокупность специалистов, ответственных за решение заявок и инцидентов в определенной области;
заявка – любое обращение пользователя ИС СН в Службу, связанное с обслуживанием ИС СН. Заявкой может являться обращение пользователя ИС СН в Службу на поддержку, предоставление информации, консультации, или документации, не являющейся сбоем в процессе функционирования ИС СН.
инцидент – любое событие, не являющиеся частью стандартных операций по функционированию ИС СН, которое привело или может привести к нарушению работы ИС СН. Инцидентом может являться сообщение пользователя ИС СН о сбое в работе ИС СН, сбоях аппаратного и программного обеспечения, функционирующего в рамках ИС СН.
В рамках функционирования подсистемы эксплуатационного обслуживания и управления функционированием осуществляется совместное решение заявок пользователей сотрудниками эксплуатационной службы федерального и регионального уровней. Схема взаимодействия служб поддержки и пользователей ИС СН представлена на рисунке 2.1.



Рисунок 2.1 - Схема взаимодействия служб поддержки и пользователей ИС СН

Взаимодействие пользователей АИУК ИС СН со службой эксплуатационного обслуживания производится с использованием программы «Служба эксплуатационного обслуживания», входящей в состав КП системного КТТ. Общая схема работы службы эксплуатационного обслуживания представлена на рисунке 2.2.



Рисунок 2.2 - Общая схема работы службы эксплуатационного обслуживания

При решении проблемы должны выполняться следующие действия:
прием, регистрация и классификация (в соответствии с поддерживаемой областью, срочностью и типом) заявки диспетчером службы;
определение приоритета заявки;
«быстрое» решение заявки диспетчером службы;
направление заявки в эксплуатационную службу, анализ заявки и ее решение;
выявление, регистрация инцидента на основе заявки пользователей и направление заявки в эксплуатационную службу;
исследование и решение инцидента, в том числе с использованием «Базы знаний» решений инцидентов;
запись решения инцидента в «Базе знаний», в случае его отсутствия;
выявление и устранение причин повторяющихся инцидентов;
закрытие инцидента;
ведение журнала событий;
создание отчетов.
Обращения пользователей в службу технической поддержки оформляются в виде заявок.
Процесс выявления и регистрации инцидента осуществляется:
специалистом службы;
КП системного КТТ.
Процесс исследования и решения произошедшего инцидента осуществляется после назначения инцидента для решения специалисту и включает следующие действия:
диагностика инцидента – определение и уточнение основных предпосылок и причин инцидента, что необходимо для поиска вариантов его решения. Предпосылки и причины инцидента выявляются путем анализа заявки пользователя, а также путем обследования компонент, затронутых инцидентом;
поиск решений инцидента в «Базе знаний»;
решение инцидента и фиксирование его хода решения. В процессе решения инцидента используется информация из конфигурационной базы данных о затронутых компонентах и Базы Знаний;
контроль сроков решения инцидентов и, при необходимости, передача инцидента другим специалистам службы или внешним организациям. Для своевременного выявления фактов, свидетельствующих о невозможности решения инцидента в установленные сроки, диспетчером службы осуществляется мониторинг срока выполнения перечисленных выше работ.
В программе предусмотрено создание базы данных по учету программно-аппаратных средств АИУК. Все программные и технические средства, эксплуатируемые в АИУК, подлежат регистрации в программе.
В программе предусмотрено планирование работ по техническому обслуживанию АИУК. Для этих целей оператор КТТ создает график проведения технического обслуживания. В график вносятся параметры проведения ежедневного технического обслуживания (ЕТО), ежемесячного технического обслуживания (ТО1) и ежегодного технического обслуживания (ТО2). В графике указывается, какие средства и когда должны пройти ТО.

Библиотека ITIL

Служба эксплуатационного обслуживания и управления функционированием тесно связана с библиотекой ITIL.
Библиотека ITIL (Information Technology Infrastructure Library) – это библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений, занимающихся предоставлением услуг в области информационных технологий. ITIL основывается на процессно-сервисном подходе к деятельности эксплуатационной служб, а логику процессов задает жизненный цикл сервиса. Для управления сервисом на каждом этапе его жизненного цикла, от разработки до аннулирования, вводится соответствующая группа процессов. Схема жизненного цикла сервиса представлена на рисунке 2.3.
Под процессом понимается совокупность взаимосвязанных и взаимодействующих целенаправленных действий (деятельности), преобразующих входы и выходы процессов. В ITIL предполагается, что любой процесс характеризуется наличием следующих понятий:
входы – то, что является исходным сырьем/данными;
выходы – результат/готовая продукция (информация);
механизм – кто (люди) и что (оборудование, программы) работает внутри процесса;
требования – условия, по которым можно отличить правильный процесс от брака.
Любые действия эксплуатационной службы АИУК представляются как процесс. Деятельность служб АИУК представляется как набор сервисов (решений функциональных задач) предоставляемых пользователям.




Рисунок 2.3 – Схема жизненного цикла сервиса.

Структура и функции процессов
Все процессы АИУК делятся на две категории:
процессы предоставления информационных услуг;
процессы поддержки информационных услуг.
В первую категорию входят процессы:
управление доступностью;
управление непрерывностью;
управление уровнем ВВХ.
управление мощностью;
управление финансами.
Во вторую категорию входят процессы:
управление инцидентами;
управление проблемами;
управление изменениями;
управление версиями;
управление конфигурацией.
Управление инцидентами. В АИУК процесс управления инцидентами служит для максимально быстрого восстановления работы, а также для минимизации воздействия неблагоприятных последствий на функционирование ИС СН. Инцидент представляет собой нарушение в функционировании АИУК ИС СН, исправление которого производится должностными лицами ИС СН в соответствии с инструкцией (руководством) по эксплуатации комплексов ИС СН. Управление инцидентами включает:
прием и регистрацию инцидента;
классификацию инцидента и его привязку к общей базе;
диагностику инцидента, решение по его устранению;
восстановление нарушенной функции и закрытие инцидента.
Это гарантирует поддержку максимально возможного уровня качества обслуживания и доступности услуг.
Управление проблемами. В АИУК процесс управления проблемами позволяет диагностировать причины, лежащие в основе инцидентов, выявленных посредством контрольно-технологического тракта АИУК. Это упорядочивает процедуру исправления ошибок и предотвращает появление потенциальных проблем.
Проблема представляет собой нарушение в функционировании АИУК ИС СН, исправление которого невозможно произвести на основании инструкции (руководства) по эксплуатации. Разрешение проблемы производится администратором КТТ. Управление проблемами включает:
идентификацию и регистрацию проблемы;
классификацию проблемы;
диагностику проблемы и ее исправление;
поиск источника возникновения проблемы (мониторинг), занесение сведений о выявленной проблеме и ее решении в базу знаний.
Управление Конфигурацией. В АИУК управление конфигурацией предоставляет логическую модель инфраструктуры объекта обслуживания при помощи идентификации, отслеживания, поддержки и проверки существующих элементов конфигурации.
Управление конфигурациями АИУК ИС СН осуществляется на основе хранилища, включающего:
данные о конфигурационных единицах аппаратно-программного обеспечения АИУК ИС СН;
знания по устранению инцидентов и решению проблем.
Управление изменениями. В АИУК процесс управления изменениями гарантирует использование стандартизованных методов и процедур для эффективной и быстрой обработки всех изменений (независимо от точки приложения этих изменений - будь то изменения связанные с аппаратной часть АИУК, программного обеспечения или эксплуатационной документации). Это позволяет минимизировать влияние инцидентов, связанных с изменениями, на качество услуг. Как следствие, целью управления изменениями является улучшение ежедневной работы служб обслуживания.
Управление изменениями включает:
планирование и координацию изменений;
регистрацию, обработку и классификацию изменений;
оценку изменений.
Управление релизами. Для АИУК планирование и управление ресурсами является неотъемлемой частью успешного оформления и доставки релизов пользователю. Управление релизами использует целостный подход к изменению. Это может случиться при миграции на новую программную платформу или на новую аппаратную платформу (обновление серверной части инфраструктуры).
В ITIL такое событие называется релизом. Релиз – совокупность одобренных изменений. Релизы делятся по масштабу (мелкий/обычный/крупный) и по срочности (экстренный/срочный/не срочный).
В рамках релиза определяется единица релиза – часть инфраструктуры которая изменяется целиком.
Релиз – это всегда достаточно существенное изменение в инфраструктуре. Суть этого процесса в том, что никакое изменение не может быть произведено в рабочей среде, пока оно не прошло тестирование и приемку, а инженеры поддержки и пользователи не прошли соответствующее обучение.
Процесс управления релизами гарантирует, что все аспекты релиза (технический или не технический) будут рассмотрены в комплексе и содержит:
планирование версии;
проектирование и конфигурирование (разработка) версии;
тестирование и прием версии;
распространение и инсталляция версии на АИУК ИС СН;
оповещение и обучение ДЛ АИУК ИС СН.
Управление уровнем обслуживания. В АИУК целью управления уровнем (качеством) обслуживания является обеспечение поддержание вероятностно-временных характеристик ИС СН (отдельных ее объектов) в заданных пределах, постоянный мониторинг основных характеристик (коэффициент готовности ИС СН, отдельного объекта) и оповещение о снижении количественного значения этих характеристик. Кроме того в этот процесс включается составление отчетов по результатам мониторинга ВВХ,
Управление нагрузкой. В АИУК управление нагрузкой (мощностью) позволяет управлять ресурсами ИС СН в первую очередь в случае возникновения пиковых нагрузок (планируемых и н внеплановых, частичного нарушения телекоммуникаций ИС СН), а также применительно к конкретному объекту обслуживания. Процесс управления нагрузкой при аналитической программной поддержке позволяет заранее предсказать необходимость привлечения дополнительных ресурсов.
Управление мощностью комплексов ИС СН включает:
мониторинг и анализ производительности АИУК ИС СН;
разработку планов модернизации АИУК ИС СН;
определение технических средств, необходимых для функционирования АИУК ИС СН.
Управления доступностью. В АИУК цель управления доступностью состоит в оптимизации нагрузки, объекта, обслуживание, с целью обеспечения доступности всех функциональных задач, возложенных на оперативную группу объекта при выполнении ими своих прямых обязанностей. Сюда же относят процедуры взаимодействия служб эксплуатации с системой защиты информации и выполнения процедур разграничения полномочий, принятых для объекта обслуживания.
Управление непрерывностью предоставления услуг. В АИУК процесс управления непрерывность описывает управление способностью ИС СН продолжать выполнение возложенных на нее задач с допустимым уровнем снижения качества в случае нарушения нормальной работоспособности ее отдельных элементов. В равной степени это относится и к отдельному объекту обслуживания АИУК.
Управление непрерывностью функционирования АИУК ИС СН включает:
мониторинг показателей непрерывной работы АИУК ИС СН;
разработку плана регламентных работ на АИУК ИС СН;
разработку процедур обеспечения непрерывности функционирования аппаратно-программного обеспечения АИУК ИС СН.
Управление финансами. В существующей организационной структуре службы эксплуатации принимали в нем косвенное участие (составление заявок на пополнение ЗИП), а основная финансовая деятельность входила в круг задач другой (финансовой) структуры Заказчика, отвечающей за серийные поставки. По результатам проектирования и формирования алгоритма этого процесса применительно к АИУК предложено следующее:
на основе базы данных запчастей и принадлежностей (с необходимой разработкой формы представления данного вида информации) возможна организация учета составляющих единиц, указание стоимости, реквизитов поставщиков, автоматизированное формирование заявок;
на основании базы данных инцидентов, в результате которых требовался ремонт изделий с отправкой на завод изготовитель (в ремонтные базы) возможно формирование учета затраченных средств на ремонт, реквизитов заводов, копий счетов, аналитическая обработка и прогнозирование затрат, связанных с ремонтом технических средств при планировании финансирования в следующем отчетном периоде. Развитие этого процесса возможно только на основании опыта использования и получения практических рекомендаций эксплуатирующей организации.
В основу разработки программы эксплуатационного обслуживания на основе ITIL положены международные стандарты серии ISO/IEC 20000, такие как:
ISO/IECTR 20000-1:2011 Управление услугами. Часть 1. Требования к системе управления услугами;
ISO/IECTR 20000-2:2012 Управление услугами. Часть 2. Руководство по применению систем управления услугами;
ISO/IECTR 20000-3:2012 Управление услугами. Часть 3. Руководство по определению области применения и применимости ISO/IEC20000-1;
ISO/IECTR 20000-4:2010 Управление услугами. Часть 4. Стандартная модель процесса;
ISO/IECTR 20000-5:2010 Управление услугами. Часть 5. Примерный план реализации ISO/IEC 20000-1.


Этапы разработки подсистемы

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

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

Описание существующих программных решений

Для выбора технических решений по реализации требований к подсистеме эксплуатационного обслуживания необходимо провести анализ следующих существующих программных решений:
HP Service Manager;
IBM Tivoli;
Microsoft System Center;
Итилиум;


ПО для автоматизации процессов службы поддержки и управления IT-услугами HP Service Manager.
Функции служб в области контроля и управления функционированием программно-технических средств можно автоматизировать с помощью специализированного ПО HP Service Manager.
HP Service Manager — флагманский продукт Hewlett-Packard для автоматизации процессов службы поддержки и управления IT-услугами.
HP Service Manager автоматизирует следующие IT-процессы:
управление инцидентами;
управление обращениями;
управление изменениями;
управление релизами;
управление конфигурациями;
управление проблемами;
управление уровнем услуг;
управление запросами на обслуживание;
управление знаниями;
управление регламентными работами.
ПО HP Service Manager позволяет обеспечивать:
наполнение и поддержание в актуальном состоянии конфигурационной базы данных;
предоставление информации о компонентах ИС СН для связи с заявками и инцидентами;
визуальное отображение структуры ИС СН в виде дерева, состоящего из логически и физически связанных между собой компонент ИС СН.
Наполнение базы знаний осуществляется двумя способами:
автоматизировано, с помощью наполнения конфигурационной базы данных информацией, полученной из подсистемы администрирования;
вручную сотрудниками федеральной и региональных Служб (в случае, если автоматизированный сбор невозможен).
При регистрации оборудования для хранения актуальной информации в HP Service Manager обязательно указывается:
инвентарный номер;
местоположение;
информация о производителе и поставщике;
сроки эксплуатации;
гарантийные сроки;
ответственные за оборудование сотрудники.
При регистрации ПО хранения актуальной информации в HP Service Manager обязательно указывается:
название ПО;
версия;
разработчик;
расположение дистрибутива.

Реализация технического решения на платформе ПО HP Service Manager.
Для федеральной Службы и каждой региональной Службы устанавливается серверная часть ПО HP Service Manager, которая предназначена для:
формирования логики работы Службы соответствующего уровня;
хранения информации обо всех заявках и инцидентах, относящихся к данной Службе;
хранения базы знаний решений инцидентов.
Все серверы Службы включают в себя следующий состав программного обеспечения:
Microsoft Windows Server 2003 R2;
Microsoft SQL Server 2005;
HP Service Manager 7.01 server;
HP Service Manager 7.01 help server;
JDK 5.0_15;
Apache Tomcat 5.5;
Apache HTTP Server 2.0.63;
scsmtp_1.0.2.0;
Connect-IT.
Серверы региональной Службы находятся в одной сетевой инфраструктуре с сервером федеральной Службы с целью реализации возможности передачи заявок с регионального уровня на федеральный уровень.
Сотрудники Службы для выполнения своих непосредственных обязанностей используют клиентское ПО для доступа к серверу Службы.
Клиентское ПО, используемое сотрудниками Службы:
HP Service Manager Client;
веб-обозреватель Internet Explorer.
ПО HP Service Manager обладает трехуровневой архитектурой. Схема архитектуры HP Service Manager представлена на рисунке 3.1.
ПО HP Service Manager Client (веб-клиент) в процессе работы обращается напрямую к ПО HP Service Manager server (веб-сервер).
Доступ специалистов Службы и пользователей ИС СН через веб обозреватель к ПО HP Service Manager server осуществляется в два этапа:
веб-сервер Apache HTTP Server обрабатывает http запросы веб-обозревателя и направляет их веб-серверу приложений Apache Tomcat;
веб-сервер Apache Tomcat интерпретирует запросы и использует JAVA для взаимодействия с ПО HP Service Manager server.


Рисунок 3.1 – Схема архитектуры HP Service Manager

ПО HP Service Manager server взаимодействует с СУБД Microsoft SQL Server для записи, чтения и хранения информации в структурированном виде.
ПО HP Service Manager 7.01 help server хранит справочную документацию и предоставляет к ней веб-доступ. Специалисты Службы также могут использовать веб обозреватели для доступа к ПО HP Service Manager 7.01 help server.
Пользователи ИС СН могут самостоятельно регистрировать и просматривать заявки, воспользовавшись интерфейсом самообслуживания ПО HP Service Manager server.

Семейство программных продуктов IBM Tivoli System Automation предназначено для обеспечения высокой доступности, а также автоматизации IT ресурсов в компьютерных кластерах. Под кластером понимается совокупность компьютеров с разделяемыми ресурсами.
IBM Tivoli — это кроссплатфоменное ПО для управления информационными ресурсами в следующих областях:
оперативный мониторинг, основные продукты: Monitoring, Network Manager, Composite Application Manager;
мониторинг производительности, основные продукты: Monitoring, Composite Application Manager, Netcool/Proviso;
управление рабочими станциями: продукты семейства Provisioning Manager;
управление идентификационными данными сотрудников предприятия и управление доступом, основные продукты: Identity Manager, семейство Access Manager, Security Compliance Manager;
управление системами хранения: продукты Storage Manager, Productivity Center, Storage Volume Control;
управление активами предприятия (EAM): продукты семейства Maximo;
мониторинг бизнес-процессов предприятия, мониторы для руководителей ИТ-отделов предприятий: продукты Business Service Manager.
Схема архитектуры IBM Tivoli представлена на рисунке 3.2.


Рисунок 3.2 – Схема архитектуры IBM Tivoli

Microsoft System Center — пакет продуктов, предназначенных для мониторинга и управления корпоративной IT-средой, а также для создания, управления и мониторинга приватными и гибридными облачными сервисами и интеграции корпоративной инфраструктуры и облачных сервисов.
В состав пакета входят 8 отдельных продуктов. Несмотря на это продажи, лицензирование и издание новых версий продукта производится в составе единого пакета. Продукты, входящие в пакет:
Configuration Manager;
Operation Manager;
Virtual Machine Manager;
Data Protection Manager;
Orchestrator;
Service Manager;
Application Controller;
Endpoint Protector.
Продукт Microsoft System Center Configuration Manager позволяет лучше контролировать IT-инфраструктуру и IT-активы организации благодаря применению аналитических технологий, с помощью которых генерируется информация о том, какое аппаратное и программное обеспечение у нее имеется, кто его используется и где оно установлено. Встроенное аналитическое средство (Asset Intelligence) преобразует учетные данные в необходимую информацию, обеспечивая формирование подробных отчетов. Эти отчеты помогают IT-специалистам оптимизировать использование программного и аппаратного обеспечения и способствуют принятию обоснованных решений по покупке лицензий для ПО и соблюдению условий лицензионных соглашений.
Средство анализа данных об IT-активах дает возможность отслеживать почти все ПО на подключенных к сети компьютерах, включая ПО в виртуализированной и физической средах в масштабе всей организации. После сбора данных о применении установленного ПО, выполненного с помощью Configuration Manager, IT-администраторы могут воспользоваться различными опциями для их просмотра, включая просмотр наборов данных, запросов и отчетов. Эти данные, в сочетании с данными, полученными в результате инвентаризации ПО, помогут выяснить:
сколько копий программного продукта определенного наименования установлено в организации и какое количество сотрудников пользуется этим продуктом;
сколько лицензий на программный продукт определенного наименования необходимо приобрести при продлении срока действия лицензионных соглашений;
пользуется ли еще кто-либо из сотрудников организации компьютерной программой определенного наименования. После получения всей нужной информации IT-администраторы могут легко отслеживать использование программного обеспечения по серверным лицензиям Windows Server и клиентским лицензиям Exchange CAL. Интеграция с функциональностью онлайновых сервисов обеспечивает обновления каталога и получение клиентами Microsoft Volume License Service (MVLS) предупреждений об изменениях и сравнительных отчетов, в которых сопоставляются используемые программные продукты и приобретенные лицензии.

Система Итилиум предназначена для автоматизации управления ИТ-процессами на основе библиотек ITIL v2 и ITIL v3. Кроме того, в системе реализованы функции службы Service Desk (ранее HelpDesk). Продукт включает в себя опыт конкретной реализации десятков проектов внедрения, как в малых, так и в больших структурах.
Возможности системы Итилиум:
управление уровнем услуг (включая SLA);
управление каталогом услуг;
управление событиями;
управление обращениями (инцидентами, запросами на обслуживание);
управление проблемами;
управление активами и конфигурациями;
управление изменениями;
управление релизами;
управление знаниями;
управление ИТ-финансами (сервисный бюджет, учет затрат).
Кроме того, в системе поддерживаются процессы управления работами, компетенциями, элементы управления персоналом.
В системе Итилиум реализована система метрик и показателей, которая позволяет построить систему совершенствования процессов, повышения их качества, что дает возможность выстроить систему мотивации персонала на основе метрик и показателей (KPI). ПО системы Итилиум имеет трехвезнную архитектуру, аналогичную с HP Service Manager (см. рисунок 3.1).

Выбор программного решения

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





Рисунок 3.3 - Сравнительная диаграмма существующих решений



3 Анализ систем управления базами данных для подсистемы эксплуатационного обслуживания в ИС СН

3.1 Система управления базами данных — это система программного обеспечения, позволяющая обрабатывать обращения к базе данных, поступающие от прикладных программ конечных пользователей.
СУБД позволяют объединять большие объемы информации и обрабатывать их, сортировать, делать выборки по определённым критериям и т.п. Современные СУБД дают возможность включать в них не только текстовую и графическую информацию, но и звуковые фрагменты и даже видеоклипы. СУБД обеспечивают правильность, полноту и непротиворечивость данных, а также удобный доступ к ним.
Для выбора для использования в подсистеме эксплуатационного обслуживания можно выделить следующие СУБД: Microsoft SQL Server (MS SQL), SQLite, PostgreSQL, Oracle; и следующие критерии:
- поддерживаемая операционная система;
- поддержка распределенных БД;
- возможность хранения большого количества данных;
- наличие открытого исходного кода;
- наличие сертификата безопасности.
Критерий «поддерживаемая операционная система» важен, т.к. зачастую в системах, и, в частности, в подсистеме эксплуатационного обслуживания уже выбрана ОС, и переход на другую не возможен или затруднителен. Наличие открытого исходного кода позволяет в дальнейшем сертифицировать готовую программу, использующую СУБД с открытым исходным кодом. Характеристики перечисленных СУБД представлены в таблице 4.1.



Таблица 4.1
Поддерживаемая операционная система Поддержка распределенных БД Возможность хранения большого количества данных Наличие открытого исходного кода Наличие сертификата безопасности
MS SQL Windows + + - -
SQLite Windows и Linux - - + +
PostgreSQL Windows и Linux + + + +
Oracle Windows и Linux + + - -

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

Существующие алгоритмы функций эксплуатационного обслуживания

Прием, регистрация и классификация заявки.
Все заявки пользователей ИС СН регистрируются в специализированном ПО HP Service Manager.
Пользователь ИС СН может обратиться в Службу следующим образом:
позвонить по единому телефону Службы;
подать заявку при помощи специализированного ПО;
подать заявку при помощи электронной почты на единый адрес Службы;
подать заявку при помощи портала (при его наличии).
Все эти способы являются равнозначными.
В случае, если пользователь ИС СН обратился в Службу, позвонив по единому телефону или подав заявку на единый адрес электронной почты, то регистрация заявок в специализированном ПО HP Service Manager осуществляется диспетчером Службы. При этом пользователю ИС СН необходимо в заявке указать контактную информацию о себе и описание заявки.
В случае, если пользователь подал заявку с портала или при помощи специализированного ПО, то диспетчер Службы получает уведомление о поступлении новой заявки.
В процессе классификации заявок определяются:
направление, к которому относится заявка – область заявки;
тип запроса (запрос информации, сообщение о сбое, запрос на изменение);
срочность решения;
затронутые элементы и компоненты ИТ–инфраструктуры;
оценка области охвата заявки.
Структурная схема процесса приема, регистрации и классификации заявок представлена на рисунке 4.1.



Рисунок 4.1 – Структурная схема процесса приема, регистрации и классификации заявок

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


Рисунок 4.2 – Блок-схема процесса приема, регистрации и классификации заявок

Если «быстрое» решение диспетчером Службы было выполнено успешно, заявка закрывается.
Если сформированное решение отсутствует в Базе Знаний, то диспетчер Службы заносит решение в Базу Знаний.
Если «быстрое» решение заявки диспетчером Службы не возможно, заявка передается для решения соответствующим специалистам, обслуживающим заявки данной области. Структурная схема процесса «быстрое» решение заявки приведена на рисунке 4.3. Блок-схема работы процесса «быстрого» решения приведена на рисунке 4.4.



Рисунок 4.3 – Структурная схема процесса «быстрое» решение заявки


Рисунок 4.4 – Блок-схема процесса «быстрое» решение заявки

Назначение заявки для решения, ее анализ, решение и закрытие.
После классификации диспетчером Службы заявка при помощи специализированного ПО HP Service Manager назначается специалисту, ответственному за данную область. В случае если таких специалистов несколько, формируется рабочая группа и заявка назначается руководителю данной рабочей группы. При этом сотруднику, которому была назначена заявка, по электронной почте приходит уведомление о том, что ему назначена заявка. Сотрудник, получив заявку, должен либо решить заявку самостоятельно, либо, в случае невозможности ее решения, передать ее при помощи специализированного ПО HP Service Manager для решения другому сотруднику. Выбранному сотруднику приходит уведомление по электронной почте о том, что ему назначена заявка.
В случае если заявка относится к области обслуживания специалистов ЕСИБ, она назначается в соответствующую рабочую группу администраторов ЕСИБ.
В случае если заявка относится к области обслуживания специалистов центра мониторинга и управления ИМСТ, она назначается в соответствующую рабочую группу администраторов центра управления и мониторинга.
В случае если заявка никем не принята в работу в течение определенного времени, об этом уведомляется диспетчер Службы.
После решения заявки специалист закрывает заявку, об этом, в случае его наличия, уведомляется руководитель рабочей группы.
При необходимости, специалист, которому была назначена для решения заявка, при помощи специализированного ПО HP Service Manager, указывает способ ее решения в Базе Знаний.
В случае неудовлетворенности решением пользователь ИС СН может повторно подать заявку либо сообщить о своей неудовлетворенности диспетчеру Службы, который заново инициирует процесс ее решения.
В случае невозможности решения заявки специалист имеет право передать данную заявку либо другому специалисту, либо в федеральную Службу, либо уполномоченной организации, выполняющей гарантийные обязательства или оказывающей консалтинговые услуги по сопровождению компонента.
В случае если обращение пользователя ИС СН связано со сбоем в работе ИС СН, то диспетчер Службы на основе его заявки регистрирует инцидент. Структурная схема процесса назначения, анализа и решения заявки приведена на рисунке 4.5.



Рисунок 4.5 – Структурная схема процесса назначения, анализа и решения заявки

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

Рисунок 4.6 - Блок-схема работы процесса назначения, анализа и решения заявки

Выявление, регистрация инцидента и назначение его в рабочую группу.
Процесс выявления и регистрации инцидента осуществляется:
диспетчером Службы;
специалистом Службы;
системами мониторинга серверов и сетевого оборудования.
В случае если заявка определена диспетчером Службы как инцидент, диспетчер выполняет следующие действия:
регистрирует инцидент на основе заявки;
назначает инцидент специалисту, и с помощью специализированного ПО HP Service Manager специалисту направляется уведомление о назначении.
В том случае, если в результате анализа заявки или при проведении регламентных или профилактических работ специалистом был обнаружен сбой, то он классифицирует заявку, как инцидент. При помощи специализированного ПО HP Service Manager об этом направляется уведомление Руководителю данной рабочей группы и диспетчеру Службы. При необходимости, Руководитель данной рабочей группы может изменить ответственного за решение инцидента сотрудника, назначив ответственным за решение инцидента другого сотрудника своей рабочей группы. Назначение инцидента ответственному сотруднику осуществляется Руководителем данной рабочей группы. В случае если область зарегистрированного инцидента в рамках региональной Службы не поддерживается, инцидент передается для решения в федеральную Службу (в случае поддержки ею данной области), иначе он решается на региональном уровне.
В том случае, если инцидент обнаружен подсистемой мониторинга программно-технических средств, необходима дополнительная проверка достоверности инцидента. Целью этой проверки является выявление «ложных срабатываний», т.е. событий, не являющихся инцидентом. Проверка проводится специалистом, непосредственно обнаружившим инцидент, либо с привлечением других сотрудников Службы, компетентных в рассматриваемой области.
В случае если федеральной Службой был выявлен инцидент и его область поддерживается региональной Службой регионального уровня, то он передается для решения на региональный уровень.
Для ускорения процесса решения инцидента и повышения его качества, зарегистрированный инцидент связывается с затронутым им компонентом, информация о котором содержится в конфигурационной базе данных.
Конфигурационная база данных содержит информацию о компонентах ИС СН и их связях между собой. Под компонентами конфигурационной базы данных в данном случае понимаются элементы ИС СН, на базе которых реализуется функционирование ИС СН. Выделяются следующие семейства компонент ИС СН, отражающие специфику их использования:
аппаратное обеспечение (АРМ, серверы, сетевое оборудование и т.д.);
программное обеспечение;
документация, связанная с использованием и обслуживанием оборудования и ПО.
Конфигурационная база данных реализована на двух уровнях:
федеральный;
региональный.
Схема реализации конфигурационной базы данных на федеральном и региональном уровнях приведена на рисунке 4.7.

Рисунок 4.7 – Схема реализации конфигурационной базы данных на федеральном и региональном уровнях

В конфигурационной базе данных региональной Службы хранится информация о компонентах ИС СН регионального уровня.
В конфигурационной базе данных федеральной Службы хранится информация о компонентах ИС СН федерального и регионального уровней.
ПО HP Service Manager позволяют обеспечивать:
наполнение и поддержание в актуальном состоянии конфигурационной базы данных;
предоставление информации о компонентах ИС СН для связи с заявками и инцидентами;
визуальное отображение структуры ИС СН в виде дерева, состоящего из логически и физически связанных между собой компонент ИС СН.
Наполнение конфигурационной базы данных осуществляется двумя способами:
автоматизировано, с помощью наполнения конфигурационной базы данных информацией, полученной из подсистемы администрирования;
вручную сотрудниками федеральной и региональных Служб (в случае, если автоматизированный сбор невозможен).
Структурная схема процесса выявления, регистрации инцидента и назначения его в рабочую группу показана на рисунке 4.8.


Рисунок 4.8 – Структурная схема процесса выявления, регистрации инцидента и назначения его в рабочую группу

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

Рисунок 4.9 – Блок-схема процесса выявления, регистрации инцидента и назначения его в рабочую группу

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

Рисунок 4.10 – Блок-схема процесса исследования, решения и закрытия инцидента

4. Разработка…


Состав и структура

Описание программы

Структура БД

Структурно-функциональная схема

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

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

Общие сведения

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

Бизнес-план

Целью данного проекта является реализация подсистемы эксплуатационного обслуживания, которая будет входить в состав программного обеспечения комплекса программ «Системный КТТ». Основной задачей данной подсистемы является обеспечение мониторинга съёмных носителей и защиты от несанкционированного копирования информации.
Источником средств для основной и дополнительной заработной платы, приобретения материалов, техники и для прочих расходов являются выплаты заказчика. Однако в роли заказчика выступает государственное учреждение (Министерство промышленности и торговли Российской Федерации (МИНПРОМТОРГ России)), в свою очередь, получающее средства на договор с разработчиком и исполнителем (НИИАА В.С.Семенихина) из бюджета. Таким образом, можно сказать, что у проводимой разработки - прямое сметное бюджетное финансирование. Сметное бюджетное финансирование - это метод безвозмездного и безвозвратного отпуска денежных средств из соответствующего бюджета (в данном случае, федерального) для обеспечения деятельности государственных органов и учреждений, содержащихся за счет государства и осуществляемого на основании финансовых планов - смет расходов.
В широкой рекламе данный продукт не нуждается, так как ориентирован на конкретную организацию в дальнейшем на гос. заказ МИНПРОМТОРГ России. Он может быть освещён на соответствующих выставках, форумах и круглых столах, посвящённых защите информации. Этого будет достаточно для привлечения интересующегося количества клиентов.
Разрабатываемая подсистема эксплуатационного обслуживания войдет в состав комплекса программ «Системный КТТ», который поставляется в виде программного обеспечения для МИНПРОМТОРГ России. Кроме того, на данный момент решается вопрос о возможных поставках комплекса программ «Системный КТТ» в другие государственные органы, а также о возможном выходе на коммерческий рынок программного обеспечения для систем автоматизированного управления.
Комплекс программ «Системный КТТ» разрабатывается для работы под управлением операционной системы специального назначения «Astra Linux Special Edition», которая является сертифицированной системой. Она предназначена для применения в автоматизированных системах в защищенном исполнении, обрабатывающих информацию ограниченного распространения, включая государственную тайну до степени секретности "совершенно секретно".
В настоящее время, комплекс программ «Системный КТТ» является единственной разработкой, для работы с защищаемыми носителями информации, которая сертифицирована для работы с секретными носителями и может применяться в МИНПРОМТОРГ России.
При использовании данной разработки по её основному назначению конкуренция будет отсутствовать по причине ориентированности подсистемы на МИНПРОМТОРГ России.

Организационный план

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


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

Таблица 5.1 - Перечень основных этапов работы и их трудоемкость
№ Название этапа Исполнители Занятость,
(человеко-дней) Длительность этапа, (дней)
1 Разработка и утверждение технического задания Нач. сектора 1 5
Главный инженер 1
Инженер 3 кат. 5
2 Техническое предложение Нач. сектора 1 8
Главный инженер 2
Инженер 3 кат. 8
3 Эскизный проект 10
3.1 Постановка задачи Нач. сектора - 2
Главный инженер 1
Инженер 3 кат. 2
3.2 Разработка общего описания алгоритма функционирования Нач. сектора - 8
Главный инженер 2
Инженер 3 кат. 8
4 Технический проект 13
4.1 Определение формы представления входных и выходных данных Нач. сектора - 3
Главный инженер -
Инженер 3 кат. 3
№ Название этапа Исполнители Занятость,
(человеко-дней) Длительность этапа, (дней)
4.2 Разработка структуры программы Нач. сектора - 10
Главный инженер 2
Инженер 3 кат. 10
5 Рабочий проект 57
5.1 Программирование и отладка программы Нач. сектора - 32
Главный инженер 2
Инженер 3 кат. 32
5.2 Испытание программы Нач. сектора - 5
Главный инженер 2
Инженер 3 кат. 5
5.3 Корректировка программы по результатам испытаний Нач. сектора - 10
Главный инженер 1
Инженер 3 кат. 10
5.4 Подготовка технической документации на программный продукт Нач. сектора - 10
Главный инженер 2
Инженер 3 кат. 10
Итого 110 93

По данным таблицы 6.1 можно построить ленточный план-график разработки, который дает наглядное представление о ходе выполнения разработки, а также позволяет проследить параллельные участки разработки. Ленточный план-график представлен на рисунке 6.2. Общая длительность разработки по графику уложилась в 93 дней, основная нагрузка при этом ложится на инженера-программиста 3 категории – дипломника.



Рисунок 6.2 - Ленточный план-график

Расчет договорной цены

Договорная цена – это цена, которая устанавливается по взаимному соглашению между производителем (НИИАА) или продавцом и заказчиком (МО РФ) или покупателем продукции в порядке, определенном органами ценообразования. Основой договорной цены является себестоимость программной продукции или смета затрат на определенные виды работ. Смета затрат разрабатывается по единой номенклатуре однородных экономических элементов. Состав затрат предприятия конкретной отрасли определяется в соответствии с «Типовыми рекомендациями по учету и калькулированию себестоимости в промышленности, сельском хозяйстве, строительстве, торговле, общественном питании и в других отраслях, разрабатываемыми министерствами (ведомствами) по согласованию с Минфином РФ».
Смета затрат на разработку программного обеспечения включает в себя следующие параметры:
затраты на сырье и материалы;
затраты на спецоборудование;
основная заработная плата;
дополнительная заработная плата;
единый социальный налог;
оплата командировок;
накладные расходы.
Для расчета затрат на покупку материалов и изделий необходимо составить перечень всех затраченных расходных материалов, таких как: бумага, пишущие принадлежности, компакт диски и другие. Необходимо определить цену всей приобретенной для проектирования продукции и подсчитать её суммарную стоимость. Затраты по статье «Материалы, покупные изделия» представлены в таблице 5.2.






Таблица 5.2 - Затраты по статье «Материалы, покупные изделия»
№
п/п Наименование материалов Единицы измерения Кол-во, штук Цена за 1 единицу, руб. Сумма оплаты, руб.
1 Бумага (А-4) Пачка 1 180,00 руб. 180,00 руб.
2 Картридж (для лазерного принтера) шт. 1 2 700,00 руб. 2 700,00 руб.
3 Диск (CD-RW) шт. 3 50 руб 150,00 руб.
4 Канцелярские товары (ручки -1 упаковка, скрепки -2 упаковки, скоросшиватели -1 упаковка, степлер -1 штука) 400,00 руб.
Итого 3420,00 руб.

Транспортные расходы рассчитываются в размере 15% от стоимости материалов по формуле (5.1)

ТР = 0,15 ∙ МР, (5.1)

где ТР – транспортные расходы;
МР – расходы на материалы, покупные изделия и полуфабрикаты.
Подставляя в (6.1) итоговое значение из таблицы 6.1, получаем

ТР = 0,15 ∙ 3420= 513 (рублей)

Общие затраты на материалы составляет:

3420 + 513 = 3933 (рублей)

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

Таблица 5.3 – Основная заработная плата по проекту
Исполнители Должностной оклад
(руб. ) Трудоемкость (чел/дн.) Дневная заработная плата (руб.) Затраты на заработную плату (руб.)
Руководитель проекта 25000 7 1136 7952
Инженер-программист 1-й категории 17000 45 772 34740
Инженер-программист 3-й категории (дипломник) 12000 77 545 41965
Итого: 84657

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

Дзп = 0,2 ∙ Озп, (5.2)

где Дзп – дополнительная заработная плата;
Озп – основная заработная плата.
Подставляя в (5.2) итоговое значение из таблицы 5.2, получаем

Дзп = 0,2 ∙ 84657 = 16931 (рублей)

Таким образом, общий фонд оплаты труда, состоящий из основной и дополнительной заработной платы, составляет 101588 рублей.
Страховые взносы (СВ) определяются в процентном отношении от суммы основной и дополнительной заработной платы, представляющей собой фонд оплаты труда (ФОТ), СВ составляет 30%,рассчитывается по формуле (5.3)

ОТЧсн = 0,3 ∙ (Озп + Дзп), (5.3)

где ОТЧсн – значение отчисления на социальные нужды;
Озп – основная заработная плата;
Дзп – дополнительная заработная плата.
Подставляя в (5.3) значения, полученные ранее, получаем

ОТЧсн = 0,3 ∙ (84657 + 16931) = 30476 (рублей)

Расходов на научные и производственные командировки нет.
Расходов на оплату работ, выполняемых сторонними организациями и предприятиями, нет.
Накладные расходы определяются процентом от суммы основной заработной платы научного и производственного персонала и на разных предприятиях в зависимости от их структуры, технологического процесса и системы управления составляет 250%, рассчитываются по формуле (5.4)

НР = 2,5 ∙Озп, (5.4)

где НР – накладные расходы;
Озп – основная заработная плата.
Подставляя в (5.4) значение основной заработной платы получаем

НР = 2,5 ∙ 84657 = 211642 (рублей)

Плановая прибыль представляет собой планируемый доход предприятия за определённый период хозяйственной деятельности. Прибыль принимается равной 30% от себестоимости разработки, и рассчитываются по формуле (6.5)

ПР = СС ∙ 0,3 (5.5)

где ПР – плановая прибыль;
СС – себестоимость разработки.
Себестоимость проекта представлена в таблице 5.4.

Таблица 5.4 – Себестоимость проекта
№ п/п Статья расходов Сумма (руб.)
1 Материалы, покупные изделия и полуфабрикаты 3420
2 Транспортные расходы 513
3 Расходы на спецоборудование -
4 Основная заработная плата 84657
5 Дополнительная заработная плата 16931
6 Отчисления на социальные нужды 30476
7 Расходы на научные и производственные командировки -
8 Расходы на оплату работ, выполняемых сторонними организациями и предприятиями -
9 Накладные расходы 211642
Итого: 347639

Подставляя в формулу (5.5) значения, полученные ранее, получаем

ПР = 347639 ∙ 0,3 = 69527 (рублей)

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

ОЦ = СС + ПР. (5.6)

Оптовая цена предприятия составляет

ОЦ = 347639 + 69527 = 417166 (рублей)

Оптовые цены служат базой для начисления косвенных налогов (НДС и др.)
Налог на добавленную стоимость (НДС) – это косвенный налог, которым государство облагает по постоянной ставке (в 18%) добавленную стоимость товара или услуги.
НДС равен стоимости за вычетом материальных затрат умноженной на ставку НДС и деленную на 100% и рассчитывается по формуле (5.7)

НДС = ((СТ - М) • СтНДС)/100% (5.7)

Поскольку в финансирование ведется Министерством Обороны РФ за счет федерального бюджета (прямое сметное бюджетное финансирование), налог на добавленную стоимость не взимается, т.е. в нашем случае НДС равен:
НДС = (347639• 0%)/100% = 0

Договорная цена (ДЦ) определяется как сумма оптовой цены и НДС и рассчитывается по формуле (5.8)

ДЦ = ОЦ + НДС (5.8)


Договорная цена составляет:

ДЦ = 417166 + 0 = 417166 (рублей)

Смета затрат на разработку представлена в таблице 5.5.



Таблица 5.5 – Смета затрат на разработку
Наименование статьи расходов Затраты (руб.)
Материалы, покупные изделия, полуфабрикаты и транспортные расходы 3933
Расходы на спецоборудование -
Основная заработная плата разработчиков 84657
Дополнительная заработная плата разработчиков 16931
Отчисления на социальные нужды 30476
Расходы на научные и производственные командировки -
Расходы на оплату работ, выполняемых сторонними организациями и предприятиями -
Накладные расходы 211642
Себестоимость 347639
Прибыль 69527
Оптовая цена 417166
НДС 0
Договорная цена 417166

Источником финансирования является государственное учреждение Министерство промышленности и торговли Российской Федерации (МИНПРОМТОРГ России).

Экономическая целесообразность

В настоящее время эксплуатационное обслуживание представляет собой трудоемкий процесс, который обеспечивается отдельным подразделением, ответственным за структурирование, систематизирование и анализ данных по нахождению и устранению неисправностей на АРМ ДЛ.
Использование подсистемы эксплуатационного обслуживания позволит обеспечить автоматизированное структурирование, систематизирование и анализ данных по нахождению и устранению неисправностей. Подсистема позволяет удобно и эффективно работать с базой знаний в ИС СН. Также подсистема позволяет формировать статистику заявок об обслуживании и выборку по самым отказоустойчивым компонентам КТТ.
При ручной обработки информации о работе эксплуатационного обслуживания затраты составляют 13 500 рублей, необходимых на выплату зарплаты сотруднику, производящему обработку. При использовании подсистемы эксплуатационного обслуживания затрат нет, т. к. обработка информации о работе эксплуатационного обслуживания защищаемых носителей производиться автоматически (программой).
Чтобы сравнить автоматическую и ручную обработку информации о работе эксплуатационного обслуживания, была составлена таблица 5.6.

Таблица 5.6 - Оценка затрат на идентификацию защищаемых носителей
Ручная обработка информации
(руб/месяц) Автоматическая обработка информации
(руб/месяц)
Общие затраты на обработку информации 13500 0

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

Вывод по пятому разделу

Для проектирования подсистемы эксплуатационного обслуживания было решено задействовать трех исполнителей, входящих в состав подразделения, работающего над созданием и сопровождением комплекса программ «Системный КТТ»: начальника отдела, главного инженера и инженера-программиста 3 категории (дипломника). Основная нагрузка при этом ложится на инженера-программиста 3 категории, который занят над проектом в течение всех 93 дня, в то время, как общие трудозатраты составляют 110 человеко-дней. За свою работу инженер-программист 3 категории получит 48,5 тысяч рублей из всей суммы затраченной на проект в 417,2 тысяч рублей.

 
Экологичность и безопасность

Общие сведения

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

Характеристика условий труда

В данной работе будет рассматриваться офисное помещение размерами 10x4 м и высотой 2.75 м. В помещении находятся два рабочих места программиста. Окна помещения выходят на север.
План помещения представлен на рисунке 6.1.


Рисунок 6.1 – План помещения
Анализ условий труда на рабочем месте

Условия труда программистов характеризуются возможностью воздействия на них следующих опасных и вредных производственных факторов: шума и вибрации; тепловыделений, причем вред организму могут нанести нетолько высокие, но и низкие температуры (обморожения); ионизирующих и неионизирующих излучений: рентгеновское, электромагнитное излучение ВЧ и СВЧ диапазона, инфракрасного; статического электричества; недостаточной освещенности; визуальные факторы: яркость, контрастность, мерцание изображения, блики и т.д.
В соответствии с санитарными нормами все вредности в работе программиста можно разделить на три группы:
параметры рабочего места и рабочей зоны;
визуальные факторы (яркость, контрастность, мерцание, блики);
излучения (рентгеновское, электромагнитное излучение ВЧ и СВЧ диапазона, гамма-излучение, электростатические поля).
Под микроклиматом производственных помещений понимаются метеорологические условия внутренней среды помещений, которые определяются действующими на организм человека сочетаниями температуры, влажности, скорости движения воздуха и теплового излучения. Показатели микроклимата должны обеспечивать сохранение теплового баланса человека с окружающей средой и поддержание оптимального или допустимого теплового состояния организма. Показателями, характеризующими микроклимат являются: температура воздуха, температура поверхностей (ограждающих конструкций, устройств, технологического оборудования), влажность воздуха, скорость движения воздуха, тепловое облучение (при наличии источников лучистого тепла).
В помещениях, в которых работает программист, должны обеспечиваться оптимальные параметры микроклимата в соответствии с действующими санитарно-эпидемиологическими нормативами микроклимата.
Особенностью трудовой деятельности программистов является повышенное зрительное напряжение, связанное со слежением за информацией на экране монитора. Поэтому при такой работе имеет большое значение качество освещенности рабочего места. Трудовая деятельность программистов по задачам зрительной работы относится к работам высокой точности с наименьшим размером объектом 0,3-0,5 мм. Нормированный уровень освещенности для работы с ЭВМ принят 400 лк, КЕО = 4%.
Помещения должны иметь естественное и искусственное освещение, соответствующее требованиям нормативной документации. Для работы в дневное время предусмотрено естественное освещение, боковое одностороннее. Отсутствие естественного света не допускается.
В помещениях, оборудованных ЭВМ, предусматриваются меры для ограничения слепящего воздействия светопроемов, имеющих высокую яркость (800 кд/м2 и более), и прямых солнечных лучей для обеспечения благоприятного распределения светового потока в помещении и исключения на рабочих поверхностях ярких и темных пятен, засветки экранов посторонним светом, а также для снижения теплового эффекта от инсоляции. Это достигается путем соответствующей ориентации светопроемов, правильного размещения рабочих мест и использования солнцезащитных средств.
Рабочие места работающих с дисплеями располагают подальше от окон и таким образом, чтобы оконные проемы находились сбоку от них. Окна в помещениях преимущественно должны быть ориентированы на север и северо-восток. Оконные проемы должны быть оборудованы регулируемыми устройствами типа: светорассеивающих штор, регулируемыми жалюзи или солнцезащитной пленкой с металлическим покрытием, занавесей, внешних козырьков и др.
Площадь на одно рабочее место предусматривает: ЭВМ с ВДТ на базе электронно-лучевой трубки (ЭЛТ) - не менее 6 м2; ЭВМ с ВДТ на базе плоских дискретных экранов (жидкокристаллические, плазменные) - 4,5 м2.
На рабочем месте программиста размещены: дисплей, клавиатура и системный блок. При включении дисплея на электронно-лучевой трубке создается высокое напряжение в несколько киловольт. Поэтому запрещается прикасаться к тыльной стороне дисплея, вытирать пыль с компьютера при его включенном состоянии, работать на компьютере во влажной одежде и влажными руками.
На программистов, работа которых предполагает использование различной техники и оборудования, воздействуют и шум и вибрация.
Шум - беспорядочные звуковые колебания разной физической природы, характеризующиеся случайным изменением амплитуды, частоты и т.д. Шум в помещениях, где работают программисты, создают вентиляторы систем охлаждения и трансформаторы, принтеры, множительная техника, оборудование для кондиционирования воздуха и др. Уровень шума на рабочих местах программистов не должен превышать 50 дБА.
Шумящее оборудование (печатающие устройства, серверы и т.п.), уровни шума которого превышают нормативные, должны размещаться вне помещений с ПЭВМ.

Постановка задачи

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

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

Условия труда программиста определяются факторами трудового процесса и производственной среды. Факторы производственной среды по воздействию на человека делятся на вредные и опасные.
Помещения должны оборудоваться системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной вентиляцией.
В помещении, где работают программисты, должны поддерживаться следующие климатические условия: температура воздуха от плюс 15 °С до плюс 35 °С; относительная влажность воздуха от 10% до 80% без конденсации; вибрация max от 0,25 до 55 Гц.
Помещения, в которых работают программисты, должны иметь естественное и искусственное освещение. Окна должны быть ориентированы преимущественно на север и северо-восток. Искусственное освещение должно осуществляется системой общего равномерного освещения.
В случаях преимущественной работы с документами, допускается применение комбинированного освещения (дополнительно светильники местного освещения). Освещенность на поверхности стола должна быть от 300 до 500 лк. Следует ограничивать отраженную и прямую блёскость.
В качестве источников искусственного освещения должны применяться преимущественно люминесцентные лампы тип ЛБ. Применение светильников без рассеивателей и экранирующих решеток не допускается.
В помещениях следует проводить чистку стекол оконных рам и светильников не реже двух раз в год и проводить своевременную замену перегоревших ламп. В помещениях ежедневно должна производится влажная уборка. Звукоизоляция помещений должна отвечать гигиеническим требованиям и обеспечивать нормируемые параметры шума не более 50 дБА.

Расчетная часть

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

G=(3600∙Q)/(C_р∙ρ∙(t_уд-t_пр ) ) (6.1)

где Ср— массовая удельная теплоёмкость воздуха (С = 103 Дж/кг*°С);
ρ— плотность приточного воздуха (р = 1,2 кг/м3);
tуд—температура удаляемого воздуха;
tпр — температура приточного воздуха (tnp = 20°С по СНиП-11-33-75). Температура удаляемого воздуха определяем по формуле (6.2)

t_уд=t_рз+a∙(H-2) (6.2)
где tрз, — температура в рабочей зоне (tpз = 22°С по ГОСТ 12.1.005-88); а — нарастание температуры на каждый метр высоты (а = 1,5 °С/м); Н — высота помещения (Н = 3,3 м).
Подставив значения в формулу (6.2) получим tуд=24°С. Количество избыточного тепла определяется по формуле (6.3)

Q=Q_пост-Q_ух (6.3)

Поступающее в помещение тепло определяется по формуле (6.4)

Q_пост=Q_обор+Q_л+Q_осв+Q_рад (6.4)

где Qобор – тепло от работы оборудования;
Qл – тепло, выделяемое людьми;
Qосв – тепло от источников освещения;
Qрад – тепло от солнечной радиации через окна.
Тепло от работы оборудования рассчитывается по формуле (6.5)

Q_обор=N∙η∙〖10〗^3 Вт (6.5)

Где N - суммарная мощность вычислительной техники (N = 0,45 кВт);
η — коэффициент тепловых потерь (η = 0,4).
Подставив значения в формулу (6.5) получим Qобор = 180 Вт.
Тепло, выделяемое людьми на рабочем месте, рассчитывается по формуле (7.6)

Q_л=n∙q (6.6)

где n — количество людей (n = 2);
q —количество тепла, выделяемое одним человеком (q = 75 Вт). Подставив значения в формулу (7.6) получим Qл = 150 Вт.
Тепло от источников освещения рассчитывается по формуле (6.7)

Q_осв=N∙η∙〖10〗^3 Вт (6.7)

где N—суммарная мощность источников освещения (N = 0,22 кВт);
η - коэффициент тепловых потерь (η = 0,55 для ламп дневного освещения).
Подставив значения в формулу (6.7) получим Qocв =121 Вт.
Тепло от солнечной радиации через окна рассчитывается по формуле (6.8)

Q_рад=F_ост∙q_ост∙A_ост (6.8)

где Fост - площадь поверхности остекления (Focт = 3,2 м2);
qост тепловыделение от солнечной радиации (qocт = 145 Вт/м2 для окон с двойным остеклением и с деревянными переплётами при ориентации их на юг);
Aост — коэффициент учёта характера остекления (Aост = 0,25, так как используется зашторивание окон).
Подставив значения в формулу (6.8) получим Qрад= 116 Вт.
Подставив вычисленные значения выделяемого тепла в формулу (6.4) получим поступающее тепло Qпост = 567 Вт.
Тепло, удаляемое из помещения, находим по формуле (6.9)

Q_ух=0,1∙Q_пост (6.9)

Подставив значения в формулу (6.9) получим Qyх< = 57 Вт.
Отсюда, по формуле (6.3), находим избыточное тепло Q = 510 Вт.
И, в результате, по формуле (6.1) находим необходимый воздухообмен G = 383 м3/ч.
Имея данные о необходимом расходе воздуха, приступим к проектированию системы меж обменной механической вентиляции. Определим и выберем:
конфигурацию вентиляционной сети;
поперечные размеры воздуховодов на участках сети;
величину максимального сопротивления сети;
вентиляторы и электродвигатели для их привода.
Вентиляционная система для помещения, где расположено Рассматриваемое рабочее место программиста, будет состоять из следующих элементов:
приточной камеры, в состав которой входят вентилятор с электродвигателем и жалюзийная решётка для регулирования объёма поступающего воздуха; круглого стального воздуховода длиной 1,5 метра;
воздухораспределителя для подачи воздуха.
Схема вентиляционной сети представлена на рисунке 6.2.


Рисунок 7.2 - Схема вентиляционной сети

Поперечные размеры воздуховода определим исходя из формулы (6.10)

f= G/(3600∙V) (6.10)

где G – необходимый расход воздуха (G=383 м3 /ч);
V – допустимая скорость движения воздуха в воздуховоде (V=3 м/с).
Подставив значения в формулу (6.10) получим f=0,44 м2. Исходя из поперечного размера круглого воздуховода, определим его диаметр, который получается равным 0,2 м и соответствует значениям СНиП.
Для расчета сопротивления в вентиляционной системе воспользуемся формулой (6.11)

P=Rl+ε∙ (V^2∙ρ)/2 (6.11)

где R — удельные потери давления на трение в воздуховоде, Па/м,
l — длина воздуховода (l = 1,5 м);
ε— сумма коэффициентов местных потерь;
V — скорость воздуха в воздуховоде (V = 3 м/с);
ρ — удельная плотность воздуха (ρ=1,2кг/м2),
Так как d = 0,2 ми V = 3 м/с, то по справочной таблице, приведённой в книге В.П. Титова «Курсовое и дипломное проектирование по вентиляции гражданских и промышленных зданий», удельные потери давления на трение R = 0,8 Па/м.
Местные потери возникают в железной решетке (ε_1=1,2), воздухораспределителе (ε_2=1,4) и калорифере (ε_3=2,2). Отсюда сумма коэффициентов местных потерь ε=4,8.
Подставив полученные значения В формулу (7.11), получаем Р=27Па.
Требуемое давление, создаваемое вентилятором, с учётом запаса на непредвиденное сопротивление н сети в размере 10%, определяется по формуле (6.12)

P_тр=1,1∙P (6.12)

Требуемая производительность, с учётом возможных дополнительных потерь или подсоса воздуха в воздуховодах, определяется по формуле (6.13)

G_тр=1,1∙G (6.13)

И отсюда Ртр= 30 Па и Gтр= 421 м3/ч.
Основываясь на вышеприведённых расчётах, в качестве вентилятора меж обменной вентиляционной системы на рабочем месте дляпрограммиста выберем осевой канальный вентилятор низкого давления ВОК-2.0. Данный вентилятор имеет следующие характеристики:
производительность 450 м3/ч;
мощность электродвигателя 10 Вт;
частота вращения 1500 об/мин;
уровень шума 55 дБ;
питание 220 В 50 Гц;
масса 2,5 кг.
Корпус вентилятора изготовлен из черной стали с порошковым покрытием. С обеих сторон корпуса имеются фланцы стандартных размеров для крепления к воздуховодам. Рабочее колесо вентилятора изготавливается из алюминия. Вентилятор оборудован двигателем с управляемой скоростью вращения, класс защиты IP 42. Термоконтакты внутри двигателя предохраняют от перегрева.
Сначала определим теплопритоки от окна, стен, пола и потолка по формуле (6.14). Коэффициент q выберем равным 35, так как комната расположена на северной стороне:

Q_1=(S • H • q)/1000=(40м^2 • 2.75м • 35)/1000=3.85кВт (6.14)

Теплопритоки от одного человека в спокойном состоянии составят 0,1 кВт.

Q_2=0.2кВт

Далее, найдем теплопритоки от бытовой техники. Это компьютеры, тепловыделения от которых составляют 0,3 кВт от каждого.

Q_3=0.3кВ •2=0.6кВт

Теперь мы можем определить расчетную мощность кондиционера по формуле (6.15):

Q=Q_1+Q_2+Q_3=3.85 кВт+0.2 кВт+0.6 кВт=4.64 кВт (6.15)

Рекомендуемый диапазон мощности Q_range (от -5% до +15% расчетной мощности Q) определяется формулой (6.16):

4.4 кВт <Q_range<5.33 кВт (6.16)

Нам осталось выбрать модель подходящей мощности. Большинство производителей выпускает сплит-системы с мощностями, близкими к стандартному ряду: 2,0 кВт; 2,6 кВт; 3,5 кВт; 5,3 кВт; 7,0 кВт. Из этого ряда мы выбираем модель мощностью 5,3 кВт- ElectroluxEACS - 18 HС/N3.
Характеристики выбранного кондиционера представлены в таблице 6.1.




Таблица 6.1 – Характеристики кондиционера ElectroluxEACS - 18 HС/N3.
Наименование Значение
Мощность обогрева 5.7 кВт
Мощность охлаждения 5.2 кВт
Параметры питающей сети 220-240/50/1 фаза В/Гц
Потребляемая мощность охлаждения 1.64 кВт
Уровень шума внешнего блока 66/56 дБ
Уровень шума внутреннего блока 45/35 дБ
Гарантия производителя 2 г
Производительность 850 м3/час
Потребляемый ток в режиме обогрева 11.1 A
Потребляемый ток в режиме охлаждения 10.9 A
Максимальная длина трассы 25 м
Перепад высот 10 м
Режим работы обогрев и охлаждение
Площадь помещения 50 м2
Тип хладогена R410
Размер внешнего блока (ШxВxГ)913x378x680 мм
Размер внутреннего блока (ШxВxГ)940х298х200 мм
Вес внешнего блока 46 кг
Вес внутреннего блока 13 кг
Потребляемая мощность обогрева 1.94 кВт

Место расположения кондиционера, представлено на рисунке 7.3.



Рисунок 7.3 – Место расположения кондиционера

Вывод по седьмому разделу

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