62
Проектная часть
1.5 Разработка проекта автоматизации
1.5.1 Этапы жизненного цикла проекта автоматизации
Методология разработки ИС описывает процесс внедрения и сопровождения
систем в виде жизненного цикла (ЖЦ) ИС, представляя его как отдельную
последовательность стадий и исполняемых на них процессов. Каждый этап имеет свой
состав и последовательность реализуемых работ, получаемые результаты, средства и
методы, нужные для успешного завершения работ, ответственность и роли участников
и т.д. Подобное описание ЖЦ ИС предоставляет возможность планировать и
организовывать процесс совместной разработки и управления этим процессом.
Жизненный цикл ИС представляет собой ряд событий, происходящих с
системой за время ее создания и эксплуатации.
Модель ЖЦ показывает разные состояния системы, причем начальным
(исходным) принято считать возникновение потребности в этой ИС, а завершающим
(исходным) – момент ее окончательного выхода из использования. Модель ЖЦ – это
некоторая структура, включающая в себя процессы, действия и задачи, которые
реализуются в ходе создания, работы и поддержки программного продукта за все
время жизни системы, от выявления требований до окончания ее использования.
На сегодняшний день известны и активно применяются следующие модели
жизненного цикла:
• Каскадная модель, представляющая последовательное выполнение всех
этапов и фаз проекта в заранее определенной последовательности, причем переход на
последующий этап говорит о полном завершении всех работ на текущем этапе.
• Поэтапная модель с дополнительным контролем. Создание ИС построено
на итерациях с циклами обратной связи между этапами. Поэтапные корректировки
дают возможность отследить реально существующее взаимные влияния результатов
разработки на разных этапах; а время жизни любого этапа продлевается на всю
продолжительность разработки.
• Спиральная модель. Каждый виток спирали включает в себя создание
очередной версии продукта, определяются и дорабатываются требования проекта,
определяется его качество и устанавливаются работы следующего витка. Главное
63
внимание уделяется первым этапам разработки — проектированию и анализу, где
необходимость создания тех или иных технических решений заранее обосновывается
и проверяется методом создания прототипов и макетов.
Каскадный подход прекрасно зарекомендовал себя в процессе создания
относительно несложных ИС, когда изначально можно очень точно и полно указать
все требования к системе. Главным недостатком подобного подхода становится то, что
реальный процесс разработки системы не сможет полностью уложится в такую
сложную схему, поскольку всегда будет потребность в возврате к уже завершенным
этапам для уточнения или пересмотра ранее определенных решений. Поэтому
реальный процесс разработки ИС соответствует поэтапной модели с пошаговым
контролем. Но данные недостатки не могут играть основную роль при проектировании
системы контроля технического состояния оборудования, поэтому принято решение
выбрать именно этот подход.
Любая из стадий разработки системы включает в себя реализацию некоторого
объема работ, которые отображаются в виде процессов ЖЦ. Процесс описывается в
виде совокупности взаимосвязанных действий, модифицирующих исходные данные в
выходные. Описание каждого отдельного процесса состоит из перечня решаемых
задач, заданных данных и результатов.
Есть целый перечень стандартов, определяющих не только ЖЦ ПО, но иногда
даже и процессы его разработки.
Среди наиболее известных стандартов можно выделить:
• ГОСТ 34.601-90 - распространяется на АИС и отражает в себе стадии и
этапы их создания. Также в нем есть описание содержания работ на всех этапах.
Стадии и этапы работы, показанные в стандарте, зачастую соответствуют каскадной
модели ЖЦ.
• ІSO/ІEC 12207:1995 - стандарт на процессы и реализацию ЖЦ.
Используется во всех видах заказного ПО. Стандарт не включает в себя описания
стадий, фаз и этапов.
• Custom Development Method по разработке прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных документов,
рассчитанных на применение в проектах совместно с Oracle. Применяется CDM для
64
типовой модели ЖЦ (имеются все работы/задачи и этапы), а также в проектах с
"быстрой разработкой" (Fast Track) или "облегченным подходом", которые являются
самыми доступными в малых проектах.
• Ratіonal Unіfіed Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование. Все эти
фазы могут быть разделены на этапы (итерации), по итогу которых имеется версия для
внутреннего или внешнего использования. Реализация четырех основных фазы
считается циклом разработки, и любой такой цикл завершается созданием версии
системы. В случае, если работа над проектом не прекращается и после этого,
полученный продукт продолжает оптимизироваться и снова проходит те же фазы. Суть
реализации в рамках RUP - это разработка и сопровождение моделей на базе UML.
• Mіcrosoft Solutіon Framework (MSF) схож с RUP, так же имеет четыре
фазы: исследование, построение, создание, стабилизация, является итерационным,
включает в себя использование объектно-ориентированного моделирования. MSF в
отличии от RUP сильнее ориентирован на разработку бизнес-приложений.
• Extreme Programmіng (XP). Экстремальное программирование (самая
молодая среди остальных методологий) реализовалось в 1996 году. В основе
методологии состоит командная работа, четкая коммуникация между исполнителем и
заказчиком за все время ведения проекта, а сама разработка построена на методах
последовательной доработки прототипов.
• Стандарт ІSO/ІEC серии 15288.
В связи с небольшим объемом разрабатываемой автоматизированной системы,
ее назначением и характером, необходимо использовать именно этот стандарт, то есть
ІSO/ІEC серии 15288. Для создаваемой системы актуален следующий перечень стадий
реализации проекта
Формирование концепции
Разработка
Реализация
Эксплуатация
Поддержка
Снятие с эксплуатации
65
Основной задачей внедрения ИС выступает создание (адаптация) и запуск в
эксплуатацию эффективных составляющих ИС. Создание и разработка подобной ИС
будет осуществлена на предприятии с привлечением только собственных сил и
возможностей, поэтому внешние специалисты привлекаться не будут.
Выбранная нами стратегия внедрения – Скачек.
Было предложено этап внедрения разделить на такие подэтапы:
1. Предпроектное обследование. На данном этапе должны быть выявлены
базовые информационные потоки компании и происходит сверка базы всей
нормативной документации. Важным моментом здесь выступает наличие всех
необходимых для функционирования корпоративных информационных систем
справочников и классификаторов и соответствие принципов их организации
требованиям системы. В ходе выполнения этапа обязательным является анализ на
полноту корпоративных стандартов учета и отчетности. На данном этапе также
выполняется диагностирование проблем, которые могут возникнуть при внедрении,
разрабатывается и согласовывается настройка справочников и классификаторов
системы в соответствии со сформулированными требованиями. Если необходимо, то
осуществляется корректировка способов учета или функциональных моделей. По
результатам этапа формируется подписываемый всеми участниками проекта
внедрения документ, который описывает все выявленные проблемы и намечает пути
их ликвидации.
2. Построение информационно-функциональной модели деятельности
предприятия, описание и оптимизация процессов, подлежащих автоматизации.
Моделирование должно проводиться хорошо обученными сотрудниками
рассматриваемого предприятия с привлечением высококвалифицированных
консультантов и экспертов, с привязкой созданной модели к стандартам бизнеса и к
будущей системе.
3. Адаптация ИС на предприятии. В ходе данного этапа производится настройка
системы и тестирование отдельных модулей и функций группой внедрения. Также
очень важным является наличие корпоративных стандартов, так как именно они
являются основой настроек системы.
66
4. Опытная эксплуатация информационной системы, которая осуществляется
для тестирования полного соответствия функциональности, полученной в результате
настройки системы, требованиям предприятия. На этом этапе сохраняется двойной
ввод данных в старую и новую системы. В ходе опытной эксплуатации: генерируются
стандартные отчеты (с помощью ИС и обычными способами) и производится
верификация данных; система постепенно вводится в эксплуатацию, по отдельным
участкам учета; документируются инструкции по ведению рабочих мест и
корректируются должностные инструкции участников учетного процесса. В
отдельных подразделениях предприятия в систему вводятся фактические данные (в
ограниченном объеме) и последовательно тестируются бизнес-функции путем
моделирования реальных ситуаций функционирования предприятия (в условиях,
максимально приближенных к действительности). Отрабатывается взаимная работа
подразделений на основе тестовых пилотных примеров. Конечные пользователи
(сотрудники отдела ИТ) обучаются работе с настроенной системой непосредственно
на своих рабочих местах. После обучения конечных пользователей отрабатывается
интегрированный пилотный пример и полностью моделируется деятельность
предприятия. На основе результатов выполнения пилотного примера руководством
предприятия принимается решение о переводе ИС в промышленную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное использование
информационной системы для выполнения ею тех функций, для которых она
предназначена.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две группы:
плановые и неплановые.
Плановые работы будут включать:
инсталляцию программного обеспечения;
базовую настройку и проверку работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверку надежности работы системы;
окончательную донастройку.
Данные работы будут выполнять специалисты сектора программирования.
67
1.5.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект создания ИС, как и все остальные проекты по созданию ПО, включает
множество неопределенных моментов, которые могут повлечь за собой риски срыва
реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер, которые
позволят либо 100% предотвратить их возникновение, либо значительно уменьшат
шанс их появления и возможные последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить возможность
появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все риски
третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей проекта,
реализуется постоянный мониторинг симптомов их проявления, часто дорабатывается
план действий в случае возникновения рисков.
Целесообразно рассмотреть две базовые категории рисков – прямые и
косвенные. На прямые риски проектная команда еще как-то можно повлиять, а вот
косвенные риски нельзя проконтролировать в принципе.
Риски принято подразделять на два основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно ли
проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
68
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится, если
ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или она
только что разработана, есть ли необычные или инновационные технические решения,
с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других проектов,
зависит ли успех проекта от сторонних продуктов или поставщиков и т.п.).
В нашем проекте можно выделить следующие основные риски на каждом этапе
разработки (таблица 2.1).
Таблица 1.10
Основные риски на этапах реализации системы
Этап
Риск
Мероприятия
Предпроектное
исследование
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Неформализуемая задача
(невозможно
автоматизировать те или иные
бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
69
Этап
Риск
Мероприятия
Проектирование
базы данных и
приложения
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов
решения поставленных задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная идентификация
проектных рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям;
Разработка базы
данных и
приложения
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Увеличить количество
привлекаемых специалистов
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать
систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей;
- трудности с обучением
персонала заказчика из-за
нежелания работать с новой
системой;
- отсутствие поддержки
внедрения ИС со стороны
отдельных ключевых
участников проекта;
- неучастие руководителей
высшего звена в проекте.
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС;
- доведение до персонала
заказчика смысла внедрения
автоматизированной системы;
- активное вовлечение высшего
руководства в проект, активное
взаимодействие с ним в ходе
проекта и своевременное
принятие решений,
необходимых для нормальной
реализации проекта.
70
1.5.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает в
себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика разделения
прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 1.11
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль «Учет»
Модуль
«Ввод»
Модуль
«Отчеты»
Сотрудник
Чтение
Нет
Нет
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
использование программно-аппаратных комплексов защиты от
несанкционированного доступа;
разработка и соблюдение политик безопасности;
использование антивирусных средств;
физическая защита помещений с наиболее ценной информацией.
В качестве основного средства защиты от проникновений используется СКУД
«Elsys».
СКУД Elsys предназначена для автоматического контроля пропускного режима
и управления исполнительными устройствами (автоматическими воротами,
шлагбаумами, лифтами, турникетами, замками и т. п.) в соответствии с заданными
полномочиями и расписаниями.
Аппаратной основой системы являются контроллеры Elsys-MB, выпускаемые в
различных по характеристикам вариантах исполнения Pro, Pro4, Standard, Lіght и SM.
71
Наличие этих вариантов, а также модулей расширения памяти различной емкости к
ним, позволяет при проектировании оптимизировать технико-экономические
характеристики систем различного масштаба.
Контроллеры Elsys-MB объединяются в сеть по двухпроводному интерфейсу
RS-485 (до 63 контроллеров в одной линии связи). Линии связи RS-485 подключаются
к серверу оборудования СКУД через преобразователи интерфейсов RS-232/RS-485 или
USB/232-485 (до 15 линий на один ПК), либо по компьютерной сети предприятия через
коммуникационные сетевые контроллеры (КСК) Elsys-MB-Net (до 256 КСК на один
ПК). Кроме того, в системе может быть несколько серверов оборудования,
объединенных компьютерной сетью, что обеспечивает практически неограниченные
возможности масштабирования системы.
Также в компании разработана политика безопасности, включающая себя
следующие частные документы:
1. Правила парольной защиты;
2. Правила защиты от вирусов и злонамеренного программного
обеспечения;
3. Требования по контролю за физического доступом;
4. Инструкция по безопасному уничтожению информации или
оборудования;
5. Правила осуществления удаленного доступа;
6. Требования резервного сохранения информации;
7. Требование мониторинга доступа и использования систем и ведения лог
файлов;
8. Требования при обращении с носителями данных;
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Требования по контролю доступа в операционную систему;
12. Требование к процедуре входа в систему (log on);
13. Правила использования системных утилит;
14. Правила удаленной работы мобильных пользователей;