63
3. Адаптация ИС на предприятии. В ходе этапа производится настройка
системы тестирование отдельных модулей и функций группой внедрения. На
данном этапе также очень важно наличие корпоративных стандартов, так как
именно они являются основой настроек системы.
4. Опытная эксплуатация информационной системы. Осуществляется для
тестирования полного соответствия функциональности, полученной в результате
настройки системы, требованиям предприятия. На этом этапе сохраняется
двойной ввод данных в старую и новую системы. В ходе опытной эксплуатации:
генерируются стандартные отчеты (с помощью ИС и обычными способами) и
производится верификация данных; система постепенно вводится в
эксплуатацию, по отдельным участкам учета; документируются инструкции по
ведению рабочих мест и корректируются должностные инструкции участников
учетного процесса. В отдельных подразделениях предприятия в систему вводятся
фактические данные (в ограниченном объеме) и последовательно тестируются
бизнес—функции путем моделирования реальных ситуаций деятельности
предприятия (в условиях, максимально приближенных к действительности).
Отрабатывается взаимная работа подразделений на основе тестовых пилотных
примеров. Конечные пользователи (сотрудники отдела ИТ) обучаются работе с
настроенной системой непосредственно на своих рабочих местах. После обучения
конечных пользователей отрабатывается интегрированный пилотный пример и
полностью моделируется деятельность предприятия. На основе результатов
выполнения пилотного примера руководством предприятия принимается
решение о переводе ИС в промышленную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное
использование информационной системы для выполнения ею тех функций, для
которых она предназначена.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
64
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут выполнять специалисты сектора программирования.
Затем производится выбор направления внедрения созданной системы.
Сегодня выделяют 4 стратегии внедрения ИС:
• Параллельная стратегия, которая подразумевает замену старой на
новую;
• Скачок – подразумевается резкий переход с одной системы сразу на
другую;
• Опытное использование пилотного проекта – та же тактика скачка,
только к некоторому количеству изделий, при этом очень успешна на малом
участке работы;
• Узкое место – внедрение узкого места план выполняется только для
него самого, и для сотрудников, которые там работают.
В качестве стратегии внедрения ИС в компании был выбран «Пилотный
проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также определить
и спланировать организационные и технические мероприятия на этапе
промышленного внедрения. Пилотный проект позволяет уменьшить затраты и
ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект создания ИС, как и все остальные проекты по созданию ПО,
включает множество неопределенных моментов, которые могут повлечь за собой
риски срыва реализации проекта.
65
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот косвенные
риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно
ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится,
если ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
66
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В нашем проекте можно выделить следующие основные риски на каждом
этапе разработки (таблица 2.1).
Таблица 2.1
Основные риски на этапах реализации системы
Этап
Риск
Мероприятия
Предпроектное
исследование
Несоответствие
выделенного бюджета
масштабу проекта
Переговоры по
увеличению бюджета или
отказ от участия в проекте
Неформализуемая
задача (невозможно
автоматизировать те или
иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть
область действия проекта с
целью выделения
отдельных задач,
поддающихся
автоматизации.
Провести детальный
анализ бизнес-процессов и
предложить комплекс
мероприятий по их
реорганизации.
67
Этап
Риск
Мероприятия
Проектирование
базы данных и
приложения
- неправильное
определение рамок и
масштабов проекта;
- проектирование
ошибочных функций и
интерфейсов будущей
системы;
- выбор
неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение
требований заказчика
при проектирование
будущей системы или
постоянное изменение
требований.
- обеспечение
стабильности границ
проекта, определенных на
начальном этапе, вплоть до
окончания проекта;
- качественное
планирование работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по
снижению рисков;
- обеспечение
проекта необходимыми
ресурсами;
- обязательное
утверждение и
согласование по
проектным решениям;
Разработка базы
данных и приложения
Недостаточно
ресурсов для
выполнения
комплексного и
нагрузочного
тестирования
Увеличить
количество привлекаемых
специалистов
Недостаточно
опыта у персонала
заказчика, который
будет эксплуатировать
систему
Предоставить
заказчику услуги
собственного специалиста
для первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
68
Этап
Риск
Мероприятия
Внедрение
- увеличение
нагрузки на персонал;
-
несогласованность
действий персонала
исполнителя и
сотрудников
предметных областей;
- трудности с
обучением персонала
заказчика из-за
нежелания работать
сновой системой;
- отсутствие
поддержки внедрения
ИС со стороны
отдельных
ключевыхучастников
проекта;
- неучастие
руководителей высшего
звена в проекте.
- проведение
обучения персонала
заказчика работы с
системой;
- составление плана
внедрения ИС;
- доведение до
персонала заказчика
смысла внедрения
автоматизированной
системы;
- активное
вовлечение высшего
руководства в проект,
активное взаимодействие с
ним в ходе проекта и
своевременное принятие
решений, необходимых
для нормальной
реализации проекта.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает
в себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Моду
ль
«Авторизаци
я»
Моду
ль «Учет»
Моду
ль
«Вво
д»
Модуль
«Отчет
ы»
69
Сотрудник
Чтени
е
Нет
Нет
Ограни
чен
Администра
тор системы
Полн
ый
Полн
ый
Полн
ый
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
разработкой и соблюдение политик безопасности;
использованием антивирусных средств;
физической защитой помещений с наиболее ценной информацией.
В качестве основного средства защиты от проникновений используется
СКУД «Elsys».
СКУД Elsys предназначена для автоматического контроля пропускного
режима и управления исполнительными устройствами (автоматическими
воротами, шлагбаумами, лифтами, турникетами, замками и т. п.) в соответствии с
заданными полномочиями и расписаниями.
Аппаратной основой системы являются контроллеры Elsys-MB,
выпускаемые в различных по характеристикам вариантах исполнения Pro, Pro4,
Standard, Light и SM. Наличие этих вариантов, а также модулей расширения
памяти различной емкости к ним, позволяет при проектировании оптимизировать
технико-экономические характеристики систем различного масштаба.
Контроллеры Elsys-MB объединяются в сеть по двухпроводному
интерфейсу RS-485 (до 63 контроллеров в одной линии связи). Линии связи RS-
485 подключаются к серверу оборудования СКУД через преобразователи
интерфейсов RS-232/RS-485 или USB/232-485 (до 15 линий на один ПК), либо по
компьютерной сети предприятия через коммуникационные сетевые контроллеры
(КСК) Elsys-MB-Net (до 256 КСК на один ПК). Кроме того, в системе может быть
несколько серверов оборудования, объединенных компьютерной сетью, что
обеспечивает практически неограниченные возможности масштабирования
системы.
70
Также в компании разработана политика безопасности, включающая себя
следующие частные документы:
1. Правила парольной защиты;
2. Правила защиты от вирусов и злонамеренного программного
обеспечения;
3. Требования по контролю за физического доступом;
4. Инструкция по безопасному уничтожению информации или
оборудования;
5. Правила осуществления удаленного доступа;
6. Требования резервного сохранения информации;
7. Требование мониторинга доступа и использования систем и ведения
лог файлов;
8. Требования при обращении с носителями данных;
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Требования по контролю доступа в операционную систему;
12. Требование к процедуре входа в систему (log on);
13. Правила использования системных утилит;
14. Правила удаленной работы мобильных пользователей;
15. Требование распределения ответственности при обеспечении
безопасности;
16. Правила безопасности при выборе персонала;
17. Требования контроля оперативных изменений;
18. Требования к применению криптографических средств управления;
19. Требования по контролю доступа к исходным текстам программ и
библиотек;
20. Требования контроля вносимых изменений;
21. Ограничения на изменения прикладного ПО.
2.2 Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
71
Нынешняя концепция управления проектом определена на понятии
«проект», где проект выступает не только в качестве объекта управления,
обладающего отдельными присущими только ему свойствами, но и как общая
характеристика сути, как основное свойство управления проектом.
Сейчас имеется большое количество трактовок понятия «проект». И все они
основаны на стандартных характеристиках проекта: единая цель, лимиты во
времени, ограниченность ресурсов. Существует два недостатка - недоступность
связи между проектом как заранее созданным планом и проектом как процедурой
внедрения этого плана, а также отсутствие отношения между проектом и
управлением проектом.
Исходя из указанного выше, имеем следующие определения.
Проект является системным комплексом плановых (технологических,
денежных, организационных и др.) документов, включающих в себя комплексно-
системную модель методик, направленных на следование указанной цели. При
этом не нужно понимать сам проект, как особый вид работ по управлению чем-
либо. Проект - это совокупный план, законченная модель действий. Его важно
создать и внедрить, что и составляет укрупненное содержание проектного
управления.
Управление проектом является уникальным типом управленческой
деятельности, определяемой предварительной коллегиальной реализацией
комплексно-системной модели действий по следованию исходной цели и
направленный на внедрение этой модели.
Отличие проекта от производственной системы состоит в том, что проект
можно назвать однократной нецикличной деятельностью. Массовый же выпуск
продукции не имеет заранее оказанных временных рамок и зависит только от
объема спроса. Когда он исчезает, цикл производства останавливается. Сами же
циклы в своем естественном виде проектами назвать нельзя. Но сейчас проектный
подход зачастую начинает использоваться в процессах, направленных на
постоянное производство. К примеру, проекты развития производства до
необходимого уровня в рамках некоторого определенного периода, опираясь на
заданный бюджет, или реализация определенных заказов с договорными сроками
поставки.
72
Проект как система деятельности живет лишь тогда, пока он требуется для
получения финального результата. Концепция проекта, однако, не идет в разрез
концепции фирмы или компании и может быть совместима с ней. Тем более,
проект иногда становится базовой формой деятельности компании.
2.2.2 Формирование команды проекта автоматизации
Среди общераспространенных проблем процесса разработки программного
обеспечения встречаются следующие:
Изменение требований непосредственно в процессе разработки.
Нечеткое распределение ответственности за выполняемую работу и
ее результат.
Наличие непрерывного потока мелких, «быстрых», наваливающихся
требований, отвлекающих разработчиков и менеджеров от основного
направления работ.
Как следствие, срыв сроков, раздувание бюджетов, потеря качества.
Для решения задачи успешной организации процесса разработки ПО была
создана гибкая методология разработки проектов.
Проектный отдел компании, как правило, включает в себя начальника
отдела, менеджеров проекта, технических специалистов по областям
проектирования. Организационно-штатная структура отдела представлена на
рисунке 2.5.