34
распределение ролей и ответственности;
политики и процедуры; требования нормативной базы;
существующие механизмы управления;
существующая отчетность.
На этапе оценки механизмов управления производится оценка
эффективности существующих механизмов управления при выполнении задач
управления, их целесообразность и пригодность сравнивается с установленными
критериями, промышленными стандартами и критическими факторами успеха.
При помощи методов экспертных оценок определяется, для каких механизмов
управления на следующем этапе должно быть протестировано соответствие
установленным процедурам. Аудитору необходимо убедиться в том, что
существующие ИТ-процессы документированы, ответственность и
подотчетность четко определены, а там, где необходимо, предусмотрены
компенсирующие механизмы управления.
Тестом соответствия называют этап аудита, задачей которого является
получение гарантий пригодности существующих механизмов управления для
решения задач управления. Проверка осуществляется путем получения прямых и
косвенных свидетельств надлежащего выполнения установленных процедур
управления за оцениваемый период. На этом этапе выполняется также
ограниченное исследование адекватности результатов процессов управления,
определяется уровень детального тестирования и объем дополнительной работы,
необходимой для получения гарантий адекватности ИТ-процесса.
Детальным тестом называют заключительный этап аудита, целью
которого является оценка и обоснование рисков невыполнения задач управления
путем использования аналитических методов и экспертных оценок. Его
конечная цель - побудить руководство к выполнению корректирующих действий
для улучшения состояния системы управления ИТ. На данном этапе аудитор
производит документирование недостатков механизмов управления, угроз и
уязвимостей, являющихся следствием этих недостатков, реальных и
потенциальных последствий реализации угроз путем причинно-следственного
анализа и проведения сравнительного тестирования.
Методика Oracle CDM является развитием CASE-технологий.
35
Методика Oracle CDM выделяет следующие процессы, протекающие на
протяжении жизненного цикла информационной системы:
определение производственных требований;
исследование существующих систем;
определение технической архитектуры;
проектирование и построение базы данных;
проектирование и реализация модулей;
конвертирование данных;
тестирование;
обучение;
переход к новой системе;
подтверждение и сопровождение.
Для разрабатываемого дополнительного программного модуля больше
подходит стандарт ISO/IEC 12207 и ГОСТ 34.601-90. Эти стандарты имеют
набор процессов, действий и задач, охватывающий наиболее широкий спектр
возможных ситуаций при максимальной адаптируемости. Стандарт содержит
предельно мало описаний, направленных на проектирование БД.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Процесс разработки программного обеспечения связан с определенными
рисками, возникающими на всех этапах работ - от этапа Управления
требованиями и до внедрения готового продукта.
Процесс управления рисками представляет собой процесс выявления,
контроля и устранения или минимизации последствий непредсказуемых
событий.
Процессы анализа и сокращения рисков должны сопутствовать основным
этапам разработки и обеспечения жизненного цикла программных средств в
соответствии с международными стандартами. При формулировании постановки
задачи и требований к системе могут возникнуть ошибки и неточности, которые
приведут к полному несоответствию разработанного программного продукта
потребностям учебного учреждения. Для снижения данного риска необходимо
36
привлечь к выполнению задачи наиболее опытных специалистов, а также
руководство ВУЗа. На этапах проектирования и реализации системы имеются
риски: ухода одного или нескольких ключевых специалистов. В этом случае
разработка системы может оказаться под угрозой срыва. Руководству ВУЗа
необходимо предпринимать меры для снижения этих рисков, в частности
обеспечивать более тесное сотрудничество сотрудников, обмен ключевой
информацией, взаимозаменяемость сотрудников. Затягивания процесса
разработки, соответственно удорожание разработки. Для снижения этого риска
необходим строгий контроль соблюдения графика разработки. К разработке ИС
специалист не должен привлекаться к прочим обязанностям и заданиям которые
не входят в его плановую нагрузку, его рабочее время должно быть полностью
посвящено разработке ИС.
Таблица 3 Характеристики дефектов программного продукта
Этапы возникновения дефектов и
ошибок
Типы первичных дефектов и ошибок
программного средства и
документации
Разработка требований к ПО
Дефекты исходных требований
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование архитектуры системы
Ошибки планирования и системного
проектирования программного
средства
Детальное проектирование ПО
Системные и алгоритмические
дефекты и ошибки проекта
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Разработка документации
Дефекты и ошибки обобщающих
документов
37
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.)
2) Случайных негативных проявлений внешней среды, дефектов системы
или ошибочных действий пользователей. Основными источниками отказовых
ситуаций могут быть некорректные исходные требования, сбои и отказы в
аппаратуре, дефекты или ошибки в программе и данных функциональных задач,
проявляющиеся при их исполнении в соответствии с назначением. При таких
воздействиях внешняя, функциональная работоспособность системы может
разрушаться не полностью, однако невозможно полноценное выполнение
заданных функций и требований к качеству информации для пользователя. Для
снижения рисков, связанных с дефектами системы, необходимо проводить
тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Под информационной безопасностью (ИБ) АИС понимается состояние
защищенности информационной среды АИС, обеспечивающее её формирование,
использование и развитие, которое не приводит к искажению, разрушению или
несанкционированному использованию информационных ресурсов, включая
хранимую, обрабатываемую и передаваемую информацию, а также
программные средства. Выделяют следующие основные цели ИБ:
конфиденциальность (доступность информации только определенному
кругу лиц);
доступность (возможность получения информации авторизованными
пользователями в нужное для них время);
38
целостность (гарантия существования информации в неискаженном,
истинном виде).
Информация, обрабатываемая и сохраняемая в автоматизированной
системе, является ценной:
- технологическая – это нагрузка и распределения часов на профессорско-
преподавательский состав, виды занятий и расписание; остаток часов, кому
предназначаются. Эта информация не является конфиденциальной, но в любой
момент она должна быть целостной и доступной, иначе работа ВУЗа
остановится, и будет крайне сложно восстановить прежнюю информацию.
- деловая – списки отчетной нагрузки, ставки преподавателей. Эта
информация должна быть конфиденциальной, доступной и целостной. Само
функционирование системы также относится к ценным активам учреждения, т.к.
нарушение работы ИС приведет к потере доступа к ценной информации. Отчет
по нагрузке будет сорваны, рабочее время потеряно.
Определим, какие угрозы имеются с точки зрения информационной
безопасности :
- Внутренние угрозы (исходящие от так называемых «инсайдеров» -
сотрудников учреждения). Это может быть умышленная и непредумышленная
порча или удаление файлов с ценной информацией, ввод неверных данных, а
также незаконное копирование (хищение) информации;
- Внешние угрозы: действия хакеров, промышленный шпионаж, вирусы и
т.п.;
- Нарушение связи по вычислительной сети с отделами;
- Отключения электропитания, пожары, наводнения и т.п.
Административно-правовой уровень.
Для того чтобы снизить риски от внутренних угроз, в ОЧУ ВО «Академия
МНЭПУ» действует политика безопасности учебного учреждения. Необходимо
доработать нормативно-правовые акты о внутренней политике безопасности с
учетом внедряемой ИС в Академии, в политику предоставления прав доступа к
информационным ресурсам необходимо добавить правила предоставления прав
доступа к ИС. Ответственным за соблюдение политики безопасности в
39
подразделении «Институт» должен быть назначен ответственный, курирующий
эту систему. Организационно-процедурный уровень.
Для обеспечения информационной безопасности в системе необходимо:
- разграничить права доступа пользователей к информации системы;
- защитить от несанкционированного доступа папки с файлами и базами
данных системы;
- регулярно проводить архивирование данных.
Во-первых, доступ к АРМ системы должен быть только у следующих
пользователей:
- директоров институтов;
- заместителей директоров институтов;
- заведующих кафедрой;
- преподавателей;
- специалистов института, которые непосредственно занимаются подачей
отчетной нагрузки;
- начальника планово-финансового;
- начальника учебно-методического управления;
- сотрудников учебно-методического управления;
- главного бухгалтера;
- сотрудников бухгалтерии.
На их компьютерах будет установлено ПО, через которое будет возможен
доступ к отдельным функциям системы, в зависимости от занимаемой
должности. В таблице 4 приведены данные о разграничении прав доступа для
разных групп пользователей.
Во-вторых, каждый пользователь должен иметь учетную запись,
защищенную паролем, состоящим из латинских букв и цифр, длиной не менее 8
символов. Пароль следует менять не реже 1 раза в год. За учетными записями
должен следить системный администратор. Должно быть установлено
ограничение числа неудачных попыток входа в систему (не более 3 попыток),
чтобы затруднить расшифровку паролей. Кроме того, необходимо ограничить
доступ к файлу паролей.
40
В-третьих, необходимо физически защитить сервер системы от
несанкционированного доступа. Его необходимо установить в специальном
серверном помещении, которое запирается на ключ, либо в запираемом шкафу.
Доступ к файлам на жестком диске сервера должен быть закрыт для всех
пользователей локальной сети. Также в надежном месте должны храниться
носители с резервными копиями базы данных.
Таблица 4 Разграничение прав пользователей (доступ)
Группы
пользователей
Общая
папка
«Часы
по УП»
Общая папка
«Расписание»
Общая
папка
«Наимен
ование
дисципл
ины»
Общая папка
«Преподаватели»
Доступ в
Internet
Директор
института
Чтение
Полный
Чтение
Полный
Полный
Заместитель
директора
института
Чтение
Полный
Чтение
Полный
Полный
Специалист
института
Чтение
Чтение/создание
Чтение
Чтение
Ограничен
Заведующий
кафедрой
Чтение
Чтение
Чтение
Чтение/создание
Ограничен
Преподаватель
Чтение
Чтение
Чтение
Ограничен
Ограничен
Начальник
УМУ
Полный
Полный
Полный
Чтение
Полный
Сотрудник
УМУ
Чтение/
создание
Чтение/создание
Чтение/
создание
Чтение
Ограничен
Главный
бухгалтер
Чтение
Чтение
Чтение
Чтение
Полный
Сотрудник
бухгалтерии
Чтение
Чтение
Чтение
Чтение
Ограничен
Начальник
планово-
Чтение
Чтение
Чтение
Чтение
Полный
41
финансового
отдела
2.2. Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
В общей постановке задача составления расписания представляет собой
процесс распределения некоторого конечного набора событий во времени в
условиях ресурсных и других ограничений.
В качестве исходных данных для составления расписания выступают
перечень специальностей, списки групп студентов, дисциплин, а также учебная
нагрузка на группы. Имеющийся ресурс выражен в качестве списка
профессорско-преподавательского состава, которые могут читать некоторые
предметы в заданных группах, списка аудиторий, количества учебных дней в
неделю, максимального количества занятий в день.
Необходимо составить оптимальное расписание занятий для каждой
группы по дням недели, распределить учебные аудитории в каждый из дней
недели, распределить нагрузку на преподавателей по дням с учетом их
пожеланий. То есть наиболее удобным образом распределить имеющиеся
ресурсы в соответствии с запросами и выделить время для занятий каждой
группы.
Существование удачно составленных расписаний говорит о том, что
задача составления оптимального расписания разрешима, или хотя бы о том, что
для нее существуют допустимые решения.
Составление расписания относится к задачам целочисленного
программирования, сложность решения которых растет экспоненциально с
ростом числа и возможных значений варьируемых. Кроме того, для нее
характерно наличие большого объема различной по своему составу исходной
информации и большого числа трудноформализуемых требований. Указанные
сложности препятствуют автоматизации процедуры составления расписания,
несмотря на наличие широкого спектра методов целочисленного
программирования.
42
С помощью точных (классических) методов и алгоритмов целочисленного
программирования возможно получение точной математической модели,
отвечающей всем ограничениям, но в сложного характера задачи составления
расписания эта модель будет громоздкой и сложной. Чтобы избежать этого,
применяется имитационное моделирование. В этом случае алгоритм оперирует
непосредственно расписанием и списком занятий, которые необходимо
включить в расписание (учебным планом). Процесс составления начинается с
пустого расписания, когда все занятия находятся в списке неучтенных занятий.
Далее алгоритм переходит от одного незаконченного расписания к
другому, стремясь наилучшим образом расставить все занятия, включенные в
список.
Процесс продолжается до тех пор, пока не будет сформировано полное
расписание или выполнится фиксированное количество итераций.
При реализации алгоритма, основанного на принципах имитационного
моделирования, особое внимание уделяется разработке эвристических правил
выбора очередного занятия из списка, определения наилучшей для него позиции
в расписании и оценке получаемого расписания.
К положительным чертам такого подхода можно отнести возможность
детального учета специфики решаемой задачи в случае составления расписания
для конкретного вуза. Однако при этом сильно ограничивается возможность
применения разработанной системы в других учебных заведениях. Кроме того,
по-видимому, понадобится вносить существенные изменения в алгоритм при
незначительных внутренних изменениях в ВУЗе.
Так как алгоритм основан на действиях, совершаемых специалистом при
составлении расписания, то существует возможность организации деятельного
диалога между пользователем и системой при поиске оптимального расписания.
Подходы к автоматизации составления расписания.
Во многих университетах расписание формируется в ручном режиме,
составляется оно на картонных планшетах, мелким почерком карандашом на них
наносится сетка расписания. В таком же виде они распространяются по
факультетам и кафедрам. Найти нужную информацию или сделать
определенную выборку в такой ситуации крайне затруднительно. Поэтому как
43
минимум необходимо автоматизировать ввод и хранение информации о
расписании занятий.
Программные продукты позволяют достаточно успешно формировать
расписание занятий в автоматическом режиме, но при этом теряются опыт и
устойчивая привычная структура расписания, полученные при ручном
составлении.
Кроме того, такие программы чаще всего используют локальный подход,
т.е. автоматизацию только одного отдела, ответственного за составление
расписания. Сотрудникам этого отдела требуется провести трудоемкий процесс
ввода исходной информации в единую базу данных.
Рисунок 2 Потоки данных при локальном подходе
Как видно из схемы на рисунке 2, соотношение объема входных и
выходных данных настолько велико, что имеют место необоснованные потери
времени, возникающие при подготовке значительного объема входных данных
только для составления расписания. Возможность же использования базы
данных для решения других задач отсутствует.