53
формируются результатные сводки, которые печатаются машиной на бумаге или
отображаются на экране.
На первом этапе исследования выявлено, что одним из приоритетных
направлений в повышении эффективности управления является создание
автоматизированной информационной системы, объединяющей предприятие в
единое информационное пространство. Наибольшее применение
информационные системы на предприятии находят при автоматизации
следующих задач:
управление рабочим процессом;
документооборот (формирование приказов, контроль исполнения);
подготовка оперативной и внешней отчетности.
На втором этапе исследования был проведен детальный анализ и
характеристика предметной области – ООО «Алмаз». Это позволило определить
характер документооборота для последующей его автоматизации.
Для успешного решения этой задачи на третьем этапе был проведен
функционально-структурный анализ технологии документооборота.
Структурный анализ позволяет избежать ошибок при построении реальной
системы и является фундаментом, от которого зависит качество и
функционирование системы в дальнейшем.
На четвертом этапе был произведен выбор технологии проектирования
технического, информационного, программного, технологического и
организационного обеспечения.
54
2 Практическая часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл
информационной системы представляет собой непрерывный процесс,
начинающийся с момента принятия решения о создании информационной
системы и заканчивается в момент полного изъятия ее из эксплуатации.
Жизненный цикл информационной системы охватывает все стадии и
этапы ее создания, сопровождения и развития:
- исследование предметной области с последующим формированием
функциональной и информационной моделей объекта, для которого
предназначена информационная система;
- проектирование системы, заключающееся в разработке проектных
решений, удовлетворяющих всем требованиям ТЗ;
- разработку системы (в том числе программирование и тестирование
прикладных программ на основании проектных спецификаций подсистем,
выделенных на стадии проектирования);
- тестирование информационной системы и выявление сбоев с
последующим их устранением;
- эксплуатацию системы и ее сопровождение;
- развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в
некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
- ГОСТ 34.601-90 – распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла;
- ISO/IEC 12207:1995 – стандарт на процессы и организацию
55
жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не
содержит описания фаз, стадий и этапов;
- Custom Development Method (методика Oracle) по разработке
прикладных информационных систем – технологический материал,
детализированный до уровня заготовок проектных документов, рассчитанных на
использование в проектах с применением Oracle. Применяется CDM для
классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также
для технологий "быстрой разработки" (Fast Track) или "облегченного подхода",
рекомендуемых в случае малых проектов;
- Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате
которых выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки,
каждый цикл завершается генерацией версии системы. Если после этого работа
над проектом не прекращается, то полученный продукт продолжает развиваться
и снова минует те же фазы. Суть работы в рамках RUP - это создание и
сопровождение моделей на базе UML.
- Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
- Extreme Programming (XP). Экстремальное программирование (самая
новая среди рассматриваемых методологий) сформировалось в 1996 году. В
основе методологии командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке ИС, а
разработка ведется с использованием последовательно дорабатываемых
прототипов.
В стандарте ISO/IEC 12207 не предлагается конкретной модели
жизненного цикла и методов разработки, его рекомендации являются общими
для любых моделей жизненного цикла. Под моделью обычно понимается
56
структура, определяющая последовательность выполнения и взаимосвязи
процессов, действий и задач на протяжении жизненного цикла.
В настоящее время существует две основные модели жизненного цикла –
это каскадная и спиральная модели. В каскадной модели процесс разработки
идет поэтапно, шаг за шагом. Переход к следующему этапу происходит только
после завершения предыдущего. В спиральной модели разработка проходит по
нарастающей. На начальном этапе разрабатывается система с высоким уровнем
абстракции, а на последующих витках эта разработка все больше и больше
конкретизируется. Для жизненного цикла текущего проекта была выбрана
каскадная модель, так как для разрабатываемой системы больше подходит
поэтапная разработка. Переход к следующему этапу происходит только после
завершения всех работ на предыдущем этапе (рис. 1), включая подготовку
полного пакета документации, достаточной для того, чтобы разработка могла
быть продолжена другой группой разработчиков и есть возможность
планирования сроков завершения работ и затрат на их выполнение.
Рис.1 Каскадная схема разработки ПО
Каскадный метод хорошо подходит для построения систем, где в самом
начале разработки можно достаточно точно и полно сформулировать все
57
требования, с тем, чтобы предоставить разработчикам свободу реализовывать их
как можно лучше с технической точки зрения. Однако в случае, если в середине
разработки вскрываются ошибки, допущенные в начале, то приходится
прибегать к энтраверсии проекта и реальная схема каскадной модели
приобретает другой вид (рис. 2.). Таким образом, каскадный метод более всего
подходит к конкретной разработке.
Рис. 2. Реальный процесс разработки ПО по каскадной схеме
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Под риском проекта понимают потенциальную, численно измеримую
возможность неблагоприятных ситуаций и связанных с ними последствий в виде
ущерба, убытков, неблагоприятного изменения основных управляемых
параметров проекта. Такие ситуации могут возникать в связи с
неопределенностью, то есть со случайными изменениями условий
экономической деятельности, неблагоприятными, в том числе форс-мажорными,
обстоятельствами, а также в связи с возможностью получения непредсказуемого
результата в зависимости от предпринятого или не предпринятого действия.
При разработке проекта автоматизации документооборота предприятия
58
могут возникнуть проектные и технические риски.
Проектные риски – связаны с ошибками в бюджете, графике работ, с
проблемами персонала, изменением требований, вызванных как изменением
текущих условий проекта, так и желанием заказчика. К проектным рисками в
данном случае будут относится:
- изменение регистрации документов;
- потери документов.
Ответственным за данный тип рисков исключительных ситуаций
является делопроизводитель преприятия, способность которого улаживать
подобного рода конфликты и определяет его профессиональную подготовку.
Технические риски – связаны с проблемами реализации технических
решений. К техническим рисками в данном случае будут относится:
- проблемы разработки, то есть способность разработчиков реализовать
ту или иную задачу;
- неудовлетворительная производительность системы;
- внедрение и затруднения, связанные с окончательной адаптацией
системы под конечных пользователей.
Ответственное лицо за решение подобных проблем – обычно
технический руководитель проекта.
Снижение потерь возможно за счет трех действий: профилактики
(предотвращения), мониторинга (своевременного распознавания ситуации) и
управления критической ситуацией (правильными действиями в случае ее
возникновения).
Любой проект по созданию информационной системы предприятия
всегда включает множество задач, связанных с общим управлением проектом,
разработкой ПО, проектированием ИС, внедрением, каждая из которых сама по
себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки существуют различные риски.
Риски заказчика связаны с неполным достижением целей проекта и не
эффективно израсходованными средствами, а риски исполнителя – с
возможностью резкого превышения фактической себестоимости работ по
сравнению с плановой. Необходимость ведения параллельных и подчас
59
принципиально отличающихся по своему характеру работ приводит к тому, что
многократно возрастает уровень риска проекта.
Наиболее характерные риски и методы из минимизации приведены в
таблице 3
Таблица 3
Возможные риски проекта и способы их минимизации
Виды
рисков/варианты
менеджмента
рисков
Снижение видов риска
Снижение вероятности
возникновения риска
Риски, связанные с
масштабом
проекта
Детальный анализ каждого этапа
работ, взаимодействия
участников, организации работ
Детально проработанная
программа качества,
отработанное управление
конфигурацией проекта,
специальные процедуры
взаимодействия участников
Риски, связанные с
недостаточным
опытом в сфере
ИТ
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы
Разработка и утверждение
концепции проекта на
возможно более ранней его
стадии
Технические риски
проекта
Строгий отбор проектной
команды по квалификационным
критериям. Обучение
участников проекта технологии
проектных работ,
инструментальным средствам
Использование стандартов
предприятия на проектные
работы, разработка
стандартов проекта
Организационные
риски проекта
Обучение участников проекта,
тренинги команды, как можно
более полная формализация
деятельности
Включение в команду
администратора проекта,
детальное распределение
ролей в проекте
Операционные
риски проекта
Многократное тестирование
созданных продуктов,
тщательная экспертиза
документов
Строгое выполнение
процедур программы
качества
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
В Российской Федерации к нормативно-правовым актам в области
информационной безопасности относятся:
Акты федерального законодательства:
- международные договоры РФ;
60
- конституция РФ;
- законы федерального уровня (включая федеральные конституционные
законы, кодексы);
- указы Президента РФ;
- постановления правительства РФ;
- нормативные правовые акты федеральных министерств и ведомств;
- нормативные правовые акты субъектов РФ, органов местного
самоуправления и т. д.
К нормативно-методическим документам можно отнести методические
документы государственных органов России:
- доктрина информационной безопасности РФ;
- руководящие документы ФСТЭК (Гостехкомиссии России);
- приказы ФСБ;
Стандарты информационной безопасности, из которых выделяют:
- международные стандарты;
- государственные (национальные) стандарты РФ;
- рекомендации по стандартизации;
- методические указания.
Система информационной безопасности строится на основе
международного стандарта по обеспечению информационной безопасности ISO
17799 ("Нормы и правила при обеспечении безопасности информации").
Стандарт ISO 17799 содержит общие рекомендации по организации системы
информационной безопасности, обеспечивающей базовый уровень безопасности
информационных систем, характерный для большинства организаций. При этом
стандарт описывает вопросы, которые должны быть рассмотрены при
проектировании системы информационной безопасности, и не накладывает
ограничений на использование конкретных средств обеспечения безопасности
компонентов инфраструктуры. Стандарт ISO 17799 содержит следующие
разделы, описывающие различные аспекты безопасности информационных
систем:
- стратегия информационной безопасности – описывает необходимость
иметь поддержку высшего руководства компании путем утверждения стратегии
61
информационной безопасности;
- организационные вопросы – дает рекомендации по форме управления
организации, оптимальной для реализации системы информационной
безопасности;
- классификация информационных ресурсов – описывает необходимые
меры по обеспечению безопасности информационных ресурсов и носителей
информации;
- управление персоналом – описывает влияние человеческого фактора
на информационную безопасность и меры, направленные на снижение
соответствующего риска;
- обеспечение физической безопасности – описывает мероприятия по
обеспечению физической безопасности компонентов информационной
инфраструктуры;
- администрирование информационных систем – описывает основные
аспекты безопасности при работе с серверами, рабочими станциями и другими
информационными системами;
- управление доступом – описывает необходимость четкого
разграничения прав и обязанностей при работе с информацией;
- разработка и сопровождение информационных систем – описывает
основные механизмы обеспечения безопасности информационных систем;
- обеспечение непрерывности бизнеса – описывает мероприятия по
обеспечению непрерывной работы организаций;
- обеспечение соответствия предъявляемым требованиям – описывает
общие требования к системам информационной безопасности и мероприятия по
проверке соответствия систем информационной безопасности этим требованиям.
Организационные (административные) меры защиты – это меры,
регламентирующие процессы функционирования АСОЭИ, использование ее
ресурсов, деятельности персонала, а также порядок взаимодействия
пользователей системой таким образом, чтобы максимально затруднить или
исключить возможность реализации угроз безопасности информации.
Они регламентируют процессы создания и эксплуатации
информационных объектов, а также взаимодействие пользователей и систем
62
таким образом, чтобы несанкционированный доступ к информации становился
либо невозможным, либо существенно затруднялся. Организационно-
административные методы защиты информации охватывают все компоненты
автоматизированных информационных систем на всех этапах их жизненного
цикла: проектирования систем, строительства зданий, помещений и сооружений,
монтажа и наладки оборудования, эксплуатации и модернизации систем. К
организационно-административным мероприятиям защиты информации
относятся:
- выделение специальных защищенных помещений для размещения
ЭВМ и средств связи и хранения носителей информации;
- выделение специальных ЭВМ для обработки конфиденциальной
информации;
- организация хранения конфиденциальной информации на
специальных промаркированных магнитных носителях;
- использование в работе с конфиденциальной информацией
технических и программных средств, имеющих сертификат защищенности и
установленных в аттестованных помещениях;
- организация специального делопроизводства для конфиденциальной
информации, устанавливающего порядок подготовки, использования, хранения,
уничтожения и учета документированной информации;
- организация регламентированного доступа пользователей к работе на
ЭВМ, средствам связи и к хранилищам носителей конфиденциальной
информации;
- установление запрета на использование открытых каналов связи для
передачи конфиденциальной информации;
- разработка и внедрение специальных нормативно-правовых и
распорядительных документов по организации защиты конфиденциальной
информации, которые регламентируют деятельность всех звеньев объекта
защиты в процессе обработки, хранения, передачи и использования информации;
- постоянный контроль за соблюдением установленных требований по
защите информации.
Информационная безопасность организации – состояние защищённости