54
Внедрение — самый ответственный момент проекта замены информационной
системы. Есть несколько способов начала использования новой системы:
• Параллельная стратегия — для случая, когда старую работающую систему
необходимо заменить новой;
• Скачок — когда прежняя система работала еще в пятницу, а в понедельник
начала работать новая система;
• Опытная эксплуатация пилотного проекта — это стратегия скачка, но
применяется к небольшому числу процессов;
• Узкое место — это наиболее критичная малая часть производственного
процесса. При внедрении узкого места план внедрения выполняется только для
узкого места и для людей, работающих в нем;
Хотя стратегия опытной эксплуатации наиболее надежен и снижает риск, старая
система чересчур неэеффективна. В хучшем случае, в нашей конкретной задаче
мы всегда сможем вернуться к старой системе, соответственно стратегия
параллельного внедрения подходит нам как нельзя лучше.
Создание ИС стартует с выражения цели проекта. ИС обязана
поддерживать требуемую функциональность системы и уровень адаптации к
корректирующим требованиям ее работы; достаточную пропускную способность;
минимальные задержки реакции на запрос; полноценную работу; круглосуточную
готовность (24/7) и доступность системы для анализа запросов от пользователей;
удобство поддержки и использования; должный уровень ИБ.
Исходя из исследований, создание ИС включает изучение 3 областей:
• Подготовку объектов данных, которые будут внедрены в БД;
• Подготовку программ, экранных графиков, форм, отвечающих за
запросы к данным;
• Изучение имеющейся технологичной среды, к примеру: топологии
сети, настройки используемого оборудования, применяемой архитектуры
(файловой или клиент-ориентированной), последовательной или параллельной
обработки данных.
55
В реальных построение системы — это нахождение варианта,
устраивающего требованиям рабочей среды системы посредством доступных
технологий исходя из заданных ограничений.
Создание ИС включает описание всей систем не нескольких уровнях.
Уровень концепции состоит из основных элементов, связей и дополнительных
систем. Уровень логического описания создает модели, включающие структуру
отдельных дополнительных систем и функционирующие связи между ними. На
уровне физического взаимодействия проходит реализация структуры в рамках
программного и аппаратного компонента.
Исходя из цели ИС системы выделяет круг функций, которые нужно этой
системе реализовать. И по факту данного списка функций ИС готовится
конкретная структура, которая именуется как формальная. Подобный тип
структуры включает совокупность активных элементов и отношений между ними,
требуемых и необходимых для реализации указанной цели для системы.
Подобная структура идеальна, т.к. не имеет физической формы восприятия. Она
создается различными средствами, поэтому ей может состоять в совокупности
дополнений. Внешняя среда, работая с ИС, выступает в роли доп. системы, ставя
перед ней конкретные задачи и определяя цели.
Методология реализации прикладных АИС заключается в: процессе
реализации, включающем конкретный набор этапов; вариантов реализации
этапов; средств отображения исходной и итоговой информации всех этапов.
Выполнение анализа классического процесса решения предметных задач на
этапе изначального обследования компании помогает отразить элементы ее
основополагающей деятельности, а именно: определить структуру задач
компании; отразить наиболее значимые задачи, требующие автоматизации;
показать их место обшей структуре задач; разделить (декомпозировать)
конкретную область задачи на отдельные элементы и упорядочить данные для
выбранной задачи в совокупности из каждой составляющей подзадачи.
Начальными данными для реализации данного этапа выступает информация,
принимаемая от специалистов предметной области и рукописных источников
изучаемой компании. Нюансом процесса деления задачи становится применение
56
совокупных принципов и правил разделения, базирующихся на использовании
типичных и классических алгоритмом.
Концепция предметных задач помогает создать систему знаний выбранной
предметной области и захватить ее в требуемой форме. Суть создания концепции
включает использование процедур, которые связаны с генерацией концепций
исходя из совокупности требуемых предметных задач, изучения и синтеза
моделей. Подготовка отражения концепции предметной задачи поддерживает
нахождение базы для корректировки данных, применяемых при автоматическом
варианте и смысловое единство для обобщённых языковых влияний данной
задачи.
Инфологическое построение задач помогает создать их знаковое
отражение, не зависящее от технических и программных методик реализации
АИС, и зафиксировать его в требуемой форме.
Даталогическое моделирование задач связано с необходимостью прямой
адаптации разно уровневых инфо-моделей задач к доступны возможностям
технических и программных средств и методов реализации вычислительной
среды и процесса вычислений. Суть адаптации инфологических моделей данного
вида задач связано с переводом разно-уровневых структур к моно-уровневым
структурам (БД, столбец, таблица), которые возможны в реальных технических и
программных средах и методиках их планирования, а также в изменении
алгоритма исчисления с учетом корректив по доступу к данным. Еще одним
компонентом даталогической модели становится компонент визуализации,
который показывает изменения данных и действий в форме, которая адекватна
для работы и восприятия конечного пользователя в требуемой программной
среде.
И
т
о
г
о
в
к
а
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
57
Проект создания ИС взаимоотношений с клиентами, как и все остальные
проекты по созданию ПО, включает множество неопределенных моментов,
которые могут повлечь за собой риски срыва реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот косвенные
риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно
ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится,
если ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
58
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
Таблица 2.1
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Заказ
Неформализуемая задача
(невозможно автоматизировать
те или иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
59
Проектирование
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов решения
поставленных задач;
- несоблюдение требований
заказчика при проектирование
будущей системы или
постоянное изменение
требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС
Кроме того, в процессе эксплуатации и сопровождения разработанной ИС
могут возникнуть:
технические риски;
риски персонала.
Причинами технических рисков становятся:
• Использование вредоносных программ (логические бомбы, вирусы,
трояны, черви, шифровальщики), активированные в корыстных целях внутри
найденных ошибок (дыр) в ПО,
60
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера Интернет
услуг), что влечет за собой недоступность передачи отчетов из филиалов и
контроля работы филиалов;
• Расхождение функциональных возможностей системы текущим
бизнес-процессам в комплекс задач ввиду проведенных реорганизационных
изменений.
Минимизировать данные обстоятельства можно, соблюдая некоторые
моменты:
• Подробное тестирование и выявление ошибок на этапе создания
проекта;
• Устранение всех недочетов и ошибок в минимальные сроки силами
прошедших подготовку на этапе внедрения технических специалистов;
• Сам администратор сети обязан следить за безопасностью данных,
применять и вовремя обновлять антивирусное ПО, грамотно настроить FireWall,
разделяющий локальную и внешнюю сеть, давать работникам компании
возможность работы только с той информацией, которая им нужна для
реализации своих служебных обязанностей;
• Разделение клиентского и серверного оборудования, а также
привлечение обученного работе с системой опытного персонала;
• Доступность альтернативных средств выхода в Интернет или
наличие других способов отправки информации;
• Запись и фиксирование всех технических условий и их утверждение
со всеми основными участниками проекта;
• Обязательное утверждение проведенных изменений.
Факторами реализации риска персонала становится такие обстоятельства,
как:
• Нарушение режима ИБ – есть вариант утечки данных из-за
злоумышленных действий сотрудников и не желании взаимодействовать с новой
системой;
61
• Не отражен этап выхода их проекта представителей заказчика.
В противовес этому выступает:
• Реализация системы поощрений персонала заказчика,
применяющего систему;
• Прием на работу сотрудников при условии сохранения
коммерческой тайны, в противном случае – использование штрафных или иных
санкций;
• Грамотное планирование сроков проекта и момента завершения
работы над проектом со стороны исполнителя.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
При эксплуатации разработанной информационной системы для
обеспечения её безопасности от внешних и внутренних угроз используется
комплекс мер по защите информации. В этот комплекс прежде всего входят
средства, позволяющие ограничить доступ пользователей к различным модулям
системы.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователе
й
ПМ
Авторизаци
я
ПМ
формировани
е заявок
ПМ
формировани
я отчетов
ПМ работы со
справочникам
и
Сотрудник
отдела оп
работе с
клиентами
Чтение
Чтение
Чтение
Полный
В целях защиты информационной системы проводятся следующие
мероприятия:
обеспечение сетевой безопасности;
обеспечение локальной безопасности;
62
обеспечение физической безопасности.
Для обеспечения сетевой безопасности используются следующие средства:
фильтрация трафика;
ограничение доступа в интернет и во внутреннюю сеть;
антивирусная фильтрация;
система обнаружения атак;
контроль содержания трафика;
протоколирование и регулярный мониторинг доступа.
Локальная безопасность обеспечивается осуществлением следующих
мероприятий:
антивирусный контроль;
аппаратная защита от несанкционированного доступа;
криптографическая защита данных;
защита персональным файрволом;
резервирование данных;
протоколирование доступа.
Для обеспечения физической информации файрвол, веб-сервер, сервера
IDS и контроля за трафиком и все сервера данных находится в отдельном
помещении, доступ в которое разрешен только администраторам, у которых есть
ключ или магнитная карта к этой комнате (комната закрыта). Помещение
оборудовано принудительной вентиляцией и пожарной защитой
(полуавтоматической). Вход в офис компании должен осуществляться только по
магнитным картам.
ИБ реализуется на стороне клиента и стороне сервера.
Главной задачей поддержания ИБ на стороне клиента является
минимизация вероятности возникновения НСД или кражи учетных данных.
Пользователи обязаны соблюдать указанные процедуры поддержания
уровня безопасности при выборе и применении паролей. Они должны следовать
следующим рекомендациям:
1. Создавать персональные пароли для поддержания подотчетности;
2. Сохранять все пароли в секрете;
63
3. Не пользоваться записанными паролями, даже в случае, если нельзя
хранить их в защищенном месте;
4. Менять пароль в случае, если есть указания на некую
компрометацию систем или паролей;
5. Подбирать пароли, имеющие не менее 6 символов;
6. Менять пароль периодически (не более чем через 180 суток), не
повторяться и не использовать «циклическое» применение старых паролей;
7. Заменять пароли для отдельных важных системных ресурсов, к
примеру, коды доступа к определенным системным утилитам;
8. Менять временные пароли при начальной авторизации в системе;
9. Не сохранять пароли в открытых сценариях автоматического входа в
системы, к примеру, в макросах или отдельных функциональных клавишах.
Выбирая пароль, нельзя применять;
1. День, месяц и год рождения;
2. ФИО, ID, регистрационный номер авто;
3. ID на название рабочего отдела;
4. Телефон или группу символов, которая включает только цифры;
5. ID пользователей, их имена, а также ID групп и другие системные ID;
6. Много одинаковых символов, которые стоят друг за другом;
7. Символы, включающие только буквы.
Главным средством, которое значительно усложняет кражу учетных
данных, является антивирусная защита.
Пользователям необходимо следовать указанным процедурам
поддержания антивирусной защиты при вводе данных в систему с подключенных
флэш-носителей, применении электронной почты и копировании данных их
глобальной сети.
Также не следует отключать работающие на ПК средства антивирусной
защиты и применять внешние флэш-носители без их начальной антивирусной
проверки.
Важно четко следовать следующим рекомендациям: