44
средств для моделирования бизнес-процессов на этапе выявления требований
пользователей.
Следующим риском этапа анализа являются ошибки при выявлении
функций системы. При реализации этого риска возникает новый риск
неправильного выбора способа приобретения системы. Предотвращение этого
риска возможно с помощью проведения тщательного анализа всех способов
приобретения системы. Если риск все-таки осуществился, нужно провести
повторный анализ способов приобретения системы.
Опишем риски этапа проектирования. Одним из них является создание
неэффективного плана-графика работ проекта. Это влечет за собой либо
избыточность ресурсов, либо, наоборот, их дефицит. Этот риск относится к
группе финансовых рисков. Устранить его можно с помощью использования
программного обеспечения, автоматизирующего процесс планирования проекта
по разработке системы (например, MS Project, Lotus, GanntPro). При повторном
появлении этого риска потребуется повторная корректировка плана-графика
работ.
На этапе реализации существует риск разработки неправильной
информационной модели и неудобных для пользователя прототипов экранных
форм. Этот риск можно предотвратить с помощью согласования прототипов
экранных форм с пользователями системы. Устранение риска осуществляется при
помощи доработки экранных форм.
На этапе проектирования системы основным риском является
неправильный расчет показателей. Этот риск можно устранить на этапе
тестирования системы.
На этапе реализации системы основным риском является некорректная
разработка программного кода. Этот риск можно устранить на этапе согласования
технического задания. Каждый раздел технического задания должен быть
разъяснен заказчику и только после полного согласования технического задания
стоит приступать к разработке системы.
Риском этапа тестирования системы является не полное выявление ошибок
в функционировании системы. Эти ошибки могут быть выявлены на этапе
эксплуатации и потребуют дополнительных затрат на их устранение. Такая
45
ситуация достаточно часто встречается, минимизировать этот риск можно с
помощью высококвалифицированных специалистов, задействованных не только
на этапе тестирования, но и на этапе реализации. Это может потребовать
увеличения бюджета проекта, но снизит риск дополнительных затрат при
обнаружении ошибок в ходе эксплуатации системы.
Риском этапа внедрения системы являются: некорректное тестирование
технического обеспечения программных модулей. Этот риск предотвращается с
помощью использования лицензионного оборудования, а его устранение
осуществляется с помощью дополнительного тестирования.
Рисками этапа сопровождения являются поломка оборудования, моральное
устаревание программного обеспечения и программных средств. Поломку
оборудования можно предотвратить при помощи регулярного мониторинга
состояния оборудования. Риск морального устаревания можно предотвратить с
помощью гибко разработанной системы и своевременного осуществления
доработки программной архитектуры системы. Эта группа рисков ложится на
заказчиков программного обеспечения.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает
добавление в существующую Политику безопасности организации раздела о
разграничении прав доступа к разрабатываемой системе.
Пользователями системы будут все сотрудники организации. Все
сотрудники организации могут создавать в системе заявки на получение доступа
к какому-либо объекту. Но только сотрудники управления безопасности могут
просматривать эти заявки и разрешать доступ или отклонять заявки, потому что
именно специалисты этого отдела отвечают за безопасность организации.
Рассмотрим задачи, которые будут осуществлять специалисты управления
безопасности в процессе контроля и управления доступом:
1. Заполнение справочников.
2. Управление доступом.
46
3. Формирование отчетов.
Все остальные сотрудники могут создавать заявки на получение доступа к
какому-либо объекту и просматривать созданные заявки.
На основании действий пользователей системы, описанных выше,
определим правила разграничения доступа к разрабатываемой системе. Для того,
чтобы определить правила разграничения доступа, выделим группы
пользователей, которые будут работать с разрабатываемой системой:
1. Администратор.
2. Специалист управления безопасности.
3. Сотрудник организации.
Затем составим список разделов системы и опишем права доступа для
каждой категории пользователей. Права доступа представлены в таблице 8.
Таблица 8
Разграничение прав доступа
Раздел
Администратор
Специалист
управления
безопасности
Сотрудник
организации
Справочник
«Сотрудник»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Отдел»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Должность»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Система»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Объект»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Право
доступа»
Запись,
удаление
Просмотр
Просмотр
Справочник
«Статус заявки»
Запись,
удаление
Просмотр
Просмотр
Заявки
Просмотр,
изменение,
удаление
Просмотр,
изменение
Создание
Отчеты
Просмотр
Просмотр
-
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к
серверу осуществляется с помощью «Remote desktop protocol», в том числе и
сервер приложений и СУБД, где будет установлена серверная версия
47
разрабатываемой информационной системы. Доступ к серверу осуществляется
только авторизованный.
Для каждого пользователя системы необходима процедура авторизации для
защиты от внутренних угроз информационной безопасности. Ежеквартально
система должно запрашивать изменение пароля при авторизации для каждого
пользователя, при этом необходимо осуществлять проверку того, не ввел ли
пользователь пароль, который уже им использовался для доступа к системе.
Для защиты от внешних угроз необходимо хранение паролей в
зашифрованном виде и обеспечить надежность каналов связи для того, чтобы
избежать перехвата информации [12].
Для обеспечения информационной безопасности в организации
используется программное обеспечение «Kaspersky Internet Security», который
обеспечивает защиту от вредоносного программного обеспечения, и фильтрует
сетевой трафик, благодаря встроенному брандмауэру.
Также необходимо обеспечить следующие механизмы обеспечения
информационной безопасности:
защиту базы данных;
систему резервного копирования.
Защита базы данных обеспечивается использованием алгоритмов
шифрования данных. Резервное копирование осуществляется созданием
резервных копий системы лицом, ответственным за обеспечение
информационной безопасности.
Защиту от хищения данных злоумышленниками обеспечивает пропускная
система контроля доступа в служебные помещения организации. Защита от порчи
данных регламентируется Политикой информационной безопасности, которая
принята в организации.
На основании вышеперечисленного можно заключить, что в компании
использованы все возможные методы защиты информации, так как нет
уникального одного метода, который смог бы обеспечить полную
информационную безопасность, а сочетание всех методов позволяет реализовать
максимальную информационную безопасность.
48
2.2. Управление проектом автоматизации
2.2.1. Описание системы принятия управленческих решений
В соответствии с выбранным стандартом разработки программного
обеспечения и моделью жизненного цикла сформулируем список работ по
проекту. Проект разработки системы централизованного управления доступом
будет включать следующие процессы:
1. Начальная стадия:
Обследование объекта автоматизации;
Сбор требований к системе;
Оформление отчета о проделанной работе.
2. Уточнение:
Разработка эскизного проекта системы;
Разработка технического проекта системы;
Утверждение проектных решений;
Оформление технического задания.
3. Конструирование:
Кодирование программных модулей;
Разработка базы данных;
Разработка пользовательского интерфейса;
Тестирование;
Отладка.
4. Внедрение:
Проведение подготовительных работ;
Установка и настройка системы;
Обучение пользователей;
Проведение приемочных испытаний.
Для создания плана работ по проекту будет использовано программное
обеспечение MS Project 2013. Для каждой из выделенных задач была определена
длительность (рисунок 9).
49
Рисунок 9. Длительность задач проекта
Согласно перечню запланированных работ по проекту и длительностям
работ построим модель «узел-связь», которая отражает последовательность
выполнения работ и взаимосвязь между ними. Каждый блок модели
пронумерован и соответствует номеру задачи на рисунке 10. Также в блоках
указана плановая длительность каждой задачи. Стрелками обозначена
последовательность выполнения задач проекта.
Осуществим расчет критического пути проекта. Критический путь
представляет собой наиболее длительную последовательность задач с момента
начала проекта и до его окончания, учитывая взаимосвязи между задачами.
Задачи, которые лежат на критическом пути, не имеют резервов времени
выполнения, поэтому при изменении их длительности будет изменена
длительность проекта. Поэтому задачи, составляющие критический путь проекта,
необходимо особенно тщательно контролировать. Согласно модели «узел-связь»
критический путь проекта будет равен 81 рабочему дню.
50
5
5
3
5
8
5
4
5
9
5
10
5
11
5
14
20
15
10
16
20
17
10
18
5
21
3
22
2
23
5
24
1
Рисунок 10. Модель «узел-связь»
Свободный резерв времени является промежутком времени, на который
можно задержать выполнение плановой операции без задержки раннего начала
последующих операций. Величина свободного резерва времени для задач
представлена в таблице 9.
Таблица 9
Расчет свободного резерва времени
Работа
Длительность
Свободный
резерв
времени
Обследование объекта автоматизации
5
0
Сбор требований
5
0
Оформление отчета
5
0
Разработка эскизного проекта
5
0
Разработка технического проекта
5
0
Утверждение проектных решений
5
0
Оформление технического задания
5
0
Кодирование программных модулей
20
0
Разработка базы данных
10
10
Разработка пользовательского
интерфейса
20
0
Тестирование
10
0
Отладка
5
0
51
Работа
Длительность
Свободный
резерв
времени
Подготовительные работы
3
0
Установка и настройка приложения
2
0
Обучение пользователей
5
0
Проведение приемочных испытаний
1
0
На рисунке 11 представлен план работ проекта. Длительность проекта
составляет 81 рабочий день. Полный резерв времени проекта составил 10 дней.
Свободный резерв времени (10 дней) есть только у работы «разработка базы
данных».
Рисунок 11. План работ проекта
2.2.2. Формирование команды проекта автоматизации
Рассмотрим процесс формирования проектной команды для автоматизации
централизованного управления доступом. Поскольку способом приобретения
информационной системы является разработка своими силами, команда проекта
будет формироваться из специалистов отделения связи. К работе над проектом
разработки системы должны быть привлечены следующие специалисты:
1. Для контроля и управления проектом разработки системы
управления документооборота необходим менеджер проекта. В обязанности
52
менеджера проекта будет входить контроль выполнения работ проекта,
корректировка сроков, формирование документооборота и ведение переговоров с
начальником группы делопроизводства и режима.
2. Для осуществления предпроектного обследования, разработки
проектных решений и формирования технического задания необходим
технический писатель.
3. На основании технического задания группа программистов будут
осуществлять разработку интерфейса системы, базы данных и программного
кода.
4. Готовый программный продукт необходимо протестировать для
выявления несоответствий техническому заданию и ошибок при работе с
системой. Для этого в команде проекта должны присутствовать тестировщик
программного обеспечения. На основании проделанной работы должен быть
составлен отчет по выявленным ошибкам, который передается менеджеру
проекта для дальнейшей работы.
5. Внедрение программного обеспечения будет осуществляться
программистами отделения связи, которые выполнят установку и настройку
программного обеспечения.
2.2.3. Средства коллективной работы над проектом автоматизации
После того как создана проектная команда и произошло распределение
ролей, необходимо осуществить выбор средств коллективной разработки (СКР).
Существуют коммерческие и бесплатные СКР. Коммерческие СКР могут иметь
достаточно высокую стоимость, однако их вендоры оказывают качественную
техническую поддержку. Поскольку проектируемая система управленческого
учета является масштабным проектом, который будет применяться во всей
организации, для обеспечения качества будет использована коммерческая СКР. В
таблице 8 представлен обзор функциональных возможностей коммерческих СКР.
Таблица 10
Обзор коммерческих СКР
Название
программы
VC
Cnf
Brn
Shr
Net
FS
Srv
cmd
GUI
jc
Bc
Bt
Price
Perforce
+
+
+
-
+
-
S
+
-
+
-
-
$500
GP-Version
+
-
+
+
+
+
S
-
+
-
P
+
$325
53
Название
программы
VC
Cnf
Brn
Shr
Net
FS
Srv
cmd
GUI
jc
Bc
Bt
Price
MKS Source
Integrity
P.E
+
+
+
?p
+
+
S
+
+
+
+
?-
$599
Code Co-op
2.0
+
+
-
-
*
+
W
-
+
-
-
-
$150
CS-RCS
+
-
+
-?
+
+
S
-
+
-
-
-
$75
PVCS
Version
Manager
+
-
-
-
-
+
S
=
+
-
-
-
~$620
StarTeam
+
+
+
+?
+
+
S
?-
+
+
-
+
~$650
VERSIONS
2.0
+
+
+
-?
-
+
S
-
+
-
-
-
~$220
TLIB 5.5
+
+
+
-
-
+
S
+
=
-
-
-
$225
Visual
SourceSafe
6.0
+
+
+
+
*
+
S
+
+
-
-
-
$549
В обзоре были использованы следующие обозначения:
VC – поддержка контроля версий;
Cnf – автоматизация разрешения конфликтов;
Brn – поддержка ветвления версий;
Shr – возможность использования одного файла в нескольких
проектах;
Net – доступ к БД проекта по сети (TCP/IP);
FS - доступ к БД проекта с использованием файловой системы;
Srv – серверный ли тип этой СКР (S - серверный, W - бессерверный,
B - работа в обоих режимах);
Cmd – наличие интерфейса командной строки;
GUI – наличие графического интерфейса;
jc - автоматизация управления распределением обязанностей;
bc - контроль и ускорение сборки проекта;
bt - встроенная система поиска ошибок;
Lic – условия распространения (для некоммерческих средств).
Наиболее удовлетворяющей соотношению «цена – функциональные
возможности» является СКР «TLIB 5.5», которая будет использована в работе над
проектом.