68
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл определяется как непрерывный процесс, который
обычно начинается с момента принятия решения о важности его реализации и
заканчивается сразу же после его изъятия из эксплуатации.
Среди наиболее популярных стандартов обычно выделяют следующие:
• ГОСТ 34.601-90 – применим к автоматизированным системам и
устанавливает все стадии и этапы их разработки. Также в этом стандарте есть
описание содержания работ для каждого этапа. Этапы и стадии, которые
закреплены в данном стандарте, чаще всего соответствуют каскадной модели
жизненного цикла.
• ISO/IEC 12207 – стандарт, определяющий процессы и организацию
жизненного цикла. Применим к любому виду заказного ПО. В стандарте нет
описания стадий, фаз и этапов.
• Custom Development Method (Oracle) – технологический материал по
разработке прикладных ИС, который детализирован до уровня заготовок
проектных инструкций, которые будут использоваться в проектах с участием
Oracle. Используется CDM для классической модели ЖЦ (имеются все этапы и
задачи), а также при технологии быстрой разработки или облегченного прохода,
которые используются в случае малого проекта.
• Rational Unified Process (RUP) – использует некую интерактивную
модель разработки, которая включает 4 фазы: начало, исследование, построение
и внедрение. Любая из этих фаз может разбиваться на этапы, в результате
которых исполняется версия для внутреннего или внешнего использования.
Проход по всем 4 фазам – это цикл разработки, и каждый такой цикл завершается
генерацией версии системы. Если после этого проект продолжается, то сам
продукт также видоизменяется и проходит эти фазы еще раз. Суть работы в
рамках RUP - разработки и сопровождение моделей на базе UML.
69
• Microsoft Solution Framework (MSF) – поход на RUP, также имеет 4
фазы: анализ, проектирование, разработка и стабилизация, является
итерационным и предполагает применение объектно-ориентированных моделей.
MSF в сравнении с RUP в большей степени предназначен для создания бизнес-
приложений.
• Extreme Programming (XP) – экстремальное программирование
(новейшая методология, сформировалась в 96 году). Основу методологии
составляют командная работы, активная коммуникация с заказчиком в течение
всего проекта по созданию ИС, ведение разработки с применением
последовательно обрабатываемых прототипов.
Для выбора стандарта основным фактором будет являться более
подробное и полное описание работы на стадиях и этапах разработки АС.
Стандарт ISO/IEP 12207 не имеет подробного описания работы на разных
стадиях и этапах создания АС.
Стандарт CDM рассчитан на проекты с использованием Oracle-
технологий, которые не применяются в данном проекте.
Стандарт MSF, как было сказано выше, ориентирован на бизнес-сферу.
Стандарт XP больше рассчитан на команду. Поэтому в данном проекте
используется ГОСТ 34.601-90, поскольку именно у него есть описание работы на
каждом этапе разработки АС.
Базовыми стадиями создания АС являются:
1) Выведение требований к системе;
2) Создание концепции;
3) Написание ТЗ;
4) Составление технического проекта;
5) Подготовка документации;
6) Внедрение.
На стадии «Выведение требований к системе» делаются следующие
работы:
• Обследуется объект;
70
• Формируются требования пользователя;
• Обосновывается необходимость разработки.
В данном этапе задействованы следующие участники: IT-менеджер,
начальник отдела производства. После реализации всех задач составляет ся отчет
о проделанной работе – описание объекта автоматизации, требований к системе,
выражение затрат на создание, введение в эксплуатацию и поддержку,
ожидаемый эффект от внедрения и требуемые условия для нормальной работы
системы.
После выполнения этапа «Выведение требований к системе» создается
вариант концепции. Разрабатывают несколько вариантов концепции и плана
реализации, оценивают ресурсы, необходимые на реализацию ИС и ее
нормальную работу, оценивают недостатки и достоинства каждого метода,
сопоставляют требования пользователей и функциональности возможной
системы.
На этапе «Создание концепции» участвует только IT-менеджер. После
того, как работа выполнена, выбирается наиболее удачный из всех подходящих
вариантов, который полностью удовлетворяет всем требованиям.
После этапа «Создание концепции» составляется ТЗ проекта
автоматизации. По его завершению важно его утвердить и согласовать. На
данном этапе участвуют: IT-менеджер и начальник отдела делопроизводства. По
итогам данный пункт может определять - функции ИС и подсистем, состав
отдельных и комплексных задач, концепцию информационной базы, состав
системы управления БД, функции и параметры программных средств.
После утверждения ТЗ идет разработка проектного решения. ITменеджер
и программист разрабатывают логическую и физическую модель БД, а также
определяют общую организацию данных.
После завершения этапа «Составление технического проекта» IT-
менеджер и программист оформляют рабочую документацию, которая
включает: технические и программные требования, руководство пользователя.
71
После завершения всех работ и написания документации остаётся только
внедрить систему.
Этап внедрения включает в себя: подготовку объекта автоматизации,
обучение сотрудников, проведение строительно–монтажных работ,
пусконаладочных работ, проведение испытаний, опытная эксплуатация и
приемочные испытания. В этом этапе участвуют: IT-менеджер, системный
администратор, начальник делопроизводства. После этого происходит анализ
испытаний ИС, проверка на соответствие ТЗ, устраняются неполадки или
подписываются все акты.
Для внедрения системы выбираем стратегию Пилотный проект.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут выполнять специалисты отдела ИТ.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект разработки информационной системы учета рабочего времени,
как любой другой проект разработки программного обеспечения, содержит в
себе много неопределенных моментов, которые влекут за собой риски
реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
72
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот
косвенные риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений,
точно ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что
случится, если ключевые поставщики в силах будут выполнить свои
обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
73
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В нашем проекте можно выделить следующие основные риски на каждом
этапе разработки (таблица 12).
Таблица 12
Основные риски на этапах реализации системы
Этап
Риск
Мероприятия
Предпроектное
исследование
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия
в проекте
Неформализуемая задача
(невозможно
автоматизировать те или
иные бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач,
поддающихся автоматизации.
Провести детальный анализ
бизнес-процессов и
предложить комплекс
мероприятий по их
реорганизации.
Проектирование
базы данных и
приложения
- неправильное определение
рамок и масштабов проекта;
- проектирование
ошибочных функций и
интерфейсов будущей
системы;
- выбор неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям;
Разработка
базы данных и
приложения
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Увеличить количество
привлекаемых специалистов
74
Этап
Риск
Мероприятия
Недостаточно опыта у
персонала заказчика,
который будет
эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность
действий персонала
исполнителя и сотрудников
предметных областей;
- трудности с обучением
персонала заказчика из-за
нежелания работать сновой
системой;
- отсутствие поддержки
внедрения ИС со стороны
отдельных
ключевыхучастников
проекта;
- неучастие руководителей
высшего звена в проекте.
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС;
- доведение до персонала
заказчика смысла внедрения
автоматизированной системы;
- активное вовлечение
высшего руководства в проект,
активное взаимодействие с
ним в ходе проекта и
своевременное принятие
решений, необходимых для
нормальной реализации
проекта.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе
включает в себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 13.
75
Таблица 13
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авториза
ция»
Модуль
«Учет»
Модуль
«Ввод»
Модуль
«Отчеты»
Сотрудник
Чтение
Нет
Нет
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
разработкой и соблюдение политик безопасности;
использованием антивирусных средств;
физической защитой помещений с наиболее ценной информацией.
В качестве основного средства защиты от проникновений используется
СКУД «Elsys».
СКУД Elsys предназначена для автоматического контроля пропускного
режима и управления исполнительными устройствами (автоматическими
воротами, шлагбаумами, лифтами, турникетами, замками и т. п.) в соответствии
с заданными полномочиями и расписаниями.
Аппаратной основой системы являются контроллеры Elsys-MB,
выпускаемые в различных по характеристикам вариантах исполнения Pro, Pro4,
Standard, Light и SM. Наличие этих вариантов, а также модулей расширения
памяти различной емкости к ним, позволяет при проектировании
оптимизировать технико-экономические характеристики систем различного
масштаба.
Контроллеры Elsys-MB объединяются в сеть по двухпроводному
интерфейсу RS-485 (до 63 контроллеров в одной линии связи). Линии связи RS-
485 подключаются к серверу оборудования СКУД через преобразователи
интерфейсов RS-232/RS-485 или USB/232-485 (до 15 линий на один ПК), либо по
компьютерной сети предприятия через коммуникационные сетевые
76
контроллеры (КСК) Elsys-MB-Net (до 256 КСК на один ПК). Кроме того, в
системе может быть несколько серверов оборудования, объединенных
компьютерной сетью, что обеспечивает практически неограниченные
возможности масштабирования системы.
Также в компании разработана политика безопасности, включающая себя
следующие частные документы:
1. Правила парольной защиты;
2. Правила защиты от вирусов и злонамеренного программного
обеспечения;
3. Требования по контролю за физического доступом;
4. Инструкция по безопасному уничтожению информации или
оборудования;
5. Правила осуществления удаленного доступа;
6. Требования резервного сохранения информации;
7. Требование мониторинга доступа и использования систем и ведения
лог файлов;
8. Требования при обращении с носителями данных;
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Требования по контролю доступа в операционную систему;
12. Требование к процедуре входа в систему (log on);
13. Правила использования системных утилит;
14. Правила удаленной работы мобильных пользователей;
15. Требование распределения ответственности при обеспечении
безопасности;
16. Правила безопасности при выборе персонала;
17. Требования контроля оперативных изменений;
18. Требования к применению криптографических средств управления;
19. Требования по контролю доступа к исходным текстам программ и
библиотек;
77
20. Требования контроля вносимых изменений;
21. Ограничения на изменения прикладного ПО.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рисунке 12.
ИС
Т права
доступа
Спр Отделы *
Спр виды
документов
Т права
доступа *
Спр разделы
Спр
Пользователи*
Спр статусы
документов
Спр виды
документов*
Т файлы
Спр
Номенклатура
*
Т папки
Спр Папки*
Администратор
Перечень отделов
Список
сотрудников
Номенклатура дел
Учет отделов
Учет
пользователей
Составление
номенклатуры
Учет видов
документов
Учет прав
доступа
Сотрудник
Документ
Регистрация
документа
Создание папки
Спр
пользователь
Т документы
Т Файл*
Т Документ*
Список
сотрудников
Номенклатур
а дел
Список
документов,
находящихся
в архиве
Список
документов
по видам
АдминистраторСотрудник
Спр отделы
Спр Разделы *
учетная
карточка
документа
Рисунок 12 Информационная модель системы документооборота