56
катушки это и есть полный цикл программного обеспечения как каскадная
модель [11].
Этот подход называется также продолжающимся проектированием.
Позднее в цикл стали дополнительно включать стадии разработки или
опробования прототипа программ. Это называлось быстрым
прототипированием.
Но применение этих методов наряду с быстрым эффектом влечет
снижение управляемости проектом и стыкуемости разных фрагментов ПО.
Основная проблема спиральной модели – определение перехода на следующий
этап. Переход же осуществляется в соответствии с поставленным планом, даже
если вся запланированная работа закончена.
В настоящей работе для проектирования, исходя из всего
вышеперечисленного, выбрана каскадная модель ЖЦ, так как, несмотря на ее
недостатки, она наилучшим образом подходим для выполнения данной задачи.
Имеется полный ряд стандартов, в которых регламентируется жизненный цикл
ИС (и в целом программных систем) и предполагается конкретная модель
жизненного цикла. Базовым международным стандартом считается стандарт
ISO IEC 12205 принятый в 1995г. В нем регламентированы ключевые категории
процессов, охватываемых в жизненный цикл всего пять:
Договорные процессы, связанные с получением и поставкой ИС.
Процессы организации, которые будут отражены в системе.
Проектные процессы.
Технические процессы, связанные с сопровождением, а также с
внедрением и обеспечением функционирования информационной
системы.
Специальные процессы (никак не рассматриваем).
Имеется весь ряд стандартов, регламентирующих ЖЦ ПО, а в
определенных вариантах и процессы разработки [10].
Между более популярных стандартов возможно отметить следующие:
57
ГОСТ 34.601-90 – распространяется на автоматизацию
информационной системы и уточняет стадии и периоды их
формирования. Помимо этого, в стандарте находится представление
нахождения работ в любой стадии. Периоды и стадии работы,
зафиксированные в стандарте, в большей степени отвечают каскадной
модели жизненного цикла.
ISO/IEC 12207:2008 – стандарт на процессы и организацию
жизненного цикла.
Распространяется на все без исключения разновидности заказного ПО.
Стандарт никак не включает описания стадии, этапов и фаз.
Custom Development Method (методика Oracle) по разработке
прикладных информационных систем – научно-технический
использованный материал, детальный вплоть до уровня значения
проектных актов, рассчитанных на применение в проектах с
использованием Oracle. Используется CDM для традиционной модели
ЖЦ (учтены все без исключения работы/задачи и стадии), а кроме
того, с целью технологии "быстрой разработки" (Fast Track) либо
"облегченного подхода", подходящих в случае небольших проектов.
Rational Unified Process (RUP) дает итеративную модель разработки,
содержащую четыре фазы: начало, изучение, создание и введение.
Любая стадия способна являться разбитой на стадии (итерации), в
следствии каковых издается вариант с целью внешнего или
внутреннего применение. Освоение посредством четырех основных
фаз именуется циклом разработки, любой цикл заканчивается
генерацией версии системы. В случае, если уже после этого работа над
продуктом не прекращается, в таком случае приобретенный продукт
не прекращает совершенствоваться и вновь избегает эти же фазы.
Сущность деятельности в рамках RUP – это поддержание и
формирование моделей на базе UML.
58
Microsoft Solution Framework (MSF) похожа на RUP. Таким же образом
содержит четыре фазы: исследование, планирование, создание,
стабилизация, также является итерационной, подразумевает
применение объектно-ориентированного моделирования. MSF в
сопоставлении с RUP в большей степени нацелена на разработку
бизнес-приложении.
Extreme Programming (ХР). Экстремальное программирование
(наиболее новейшая из числа рассматриваемых методологии)
сформировалось в 1996 г. В базе методологии командная работа,
результативное общение между исполнителем и заказчиком на
протяжении всего проекта по разработке ИС, а разработка проводится
с применением поочередно дорабатываемых прототипов.
Модель ЖЦ зависит от специфики, масштаба и сложности проекта и
специфики условий, в которых система создается и функционирует. В
данной выпускной квалификационной работе рассмотрим один из
общеизвестных стандартов жизненного цикла ИС - стандарт
ISO/IEC 12207.Данный стандарт не предлагает какую - то конкретную
модель ЖЦ и методы ее разработки ИС. Положения стандарта
ISO/IEC 12207 являются общими для любых моделей ЖЦ, методов и
технологий разработки ИС.
В соответствии с базовым международным стандартом ISO/IEC 12207 все
без исключения процессы ПО разделяются на три категории. Процессы ЖЦ ПО
в соответствии со стандартом ISO/IEC 12207 представлены в таблице 2.1.
Таблица 2.1
Категории процессов ЖЦ ПО по стандарту ISO/IEC 12207
Основные процессы
Вспомогательные
процессы
Организационные
процессы
Приобретение
Документирование
Создание инфраструктуры
Поставка
Управление настройкой
Управление
Разработка
Обеспечение качества
Обучение
Эксплуатация
Решение проблем
Усовершенствование
Сопровождение
Анализ
Аттестация
59
Продолжение Таблицы 2.1
Совместная оценка
Верификация
Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ИС, не
конкретизируя, как реализовать или выполнить действия и задачи, включенные
в эти процессы.
В состав ЖЦ ИС обычно включаются следующие стадии [2]:
1. формирование требований к ИС;
2. проектирование (разработка системного проекта);
3. реализация;
4. тестирование;
5. ввод в действие (внедрение);
6. эксплуатация и сопровождение;
7. снятие с эксплуатации.
Рассмотрим подробнее эти стадии:
Стадия формирования требований. Эта стадия является очень важной, от
нее зависит успех проекта. В начале стадии одобряется и утверждается
архитектура системы, включаются основные соглашения о распределении
функций между аппаратурой и программами. Стадия формирования
требований включает несколько этапов:
1) Планирование работ. Основные задачи этапа: определение целей
разработки, предварительная экономическая оценка проекта, построение плана-
графика выполнения работ, создание и обучение совместной рабочей группы.
2) Проведение обследования автоматизируемой организации. Основные
задачи этапа: предварительное выявление требований к будущей системе,
определение структуры организации, определение перечня целевых функций
организации, анализ распределения функций по подразделениям и
сотрудникам, выявление функциональных взаимодействий между
подразделениями, информационных потоков внутри подразделений и между
ними, внешних по отношению к организации объектов и внешних
60
информационных воздействий, анализ существующих средств автоматизации
деятельности организации.
3) Построение модели деятельности организации. Задачами данного
этапа является обработка материалов обследования и построение двух видов
моделей:
o модели "AS-IS" ("как есть"), отражающей существующее на момент
обследования положение дел в организации и позволяющей понять,
каким образом работает данная организация, а также выявить узкие
места и сформулировать предложения по улучшению ситуации;
o модели "TO-BE" ("как должно быть"), отражающей представление
новых технологиях работы организации.
4)Разработка системного проекта
Данный этап является первой фазой разработки собственно системы
автоматизации (именно, фазой анализа требований к системе), на которой
требования заказчика уточняются, формализуются и документируются. На этом
этапе определяются:
архитектура системы, ее функции, внешние условия ее
функционирования, распределение функций между аппаратной и
программной частями;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам
системы, необходимые аппаратные ресурсы, требования к базе
данных, физические характеристики компонент системы, их
интерфейсы;
состав людей и работ, имеющих отношение к системе;
ограничения в процессе разработки (директивные сроки завершения
отдельных этапов, имеющиеся ресурсы, организационные процедуры
и мероприятия, обеспечивающие защиту информации)
5) Разработка предложений по автоматизации предприятия на основании
системного проекта осуществляется:
61
составление перечня автоматизированных рабочих мест предприятия и
способов взаимодействия между ними;
анализ применимости существующих систем управления
предприятиями для решения требуемых задач и формирование
рекомендаций по выбору такой системы;
совместное с заказчиком принятие решения о выборе конкретной
системы управления предприятием или разработке собственной
системы;
разработка требовании к техническим средствам;
разработка требований к программным средствам;
разработка предложений по этапам и срокам автоматизации.
6)Разработка технического проекта
На данном этапе на основе системного проекта и принятых решений по
автоматизации осуществляется проектирование системы.
Этот этап разделяется на два подэтапа:
проектирование архитектуры системы, включающее разработку
структуры и интерфейсов ее компонент (автоматизированных рабочих
мест), согласование функции и технических требовании к
компонентам, определение информационных потоков между
основными компонентами, связей между ними и внешними
объектами;
детальное проектирование, включающее разработку спецификаций
каждой компоненты, разработку требований к тестам и плана
интеграции компонент, а также построение моделей иерархии
программных модулей и межмодульных взаимодействий и
проектирование внутренней структуры модулей.
7) Разработка и тестирование
Тестирование представляет собой набор процедур и действий,
предназначенных для демонстрации корректной работы АСУП в заданных
62
режимах и внешних условиях. Цель тестирования - выявить наличие ошибок
или убедительно продемонстрировать их отсутствие, что возможно лишь в
отдельных тривиальных случаях.
8. Внедрение
Внедрение системы в эксплуатацию.
9. Эксплуатация и сопровождение
Основные задачи этапа эксплуатации и сопровождения:
обеспечение устойчивости работы системы и сохранности
информации - администрирование;
своевременная модернизация и ремонт отдельных элементов -
техническая поддержка;
адаптация возможностей эксплуатируемой системы к текущим
потребностям бизнеса предприятия - развитие системы.
Особое внимание на этапе эксплуатации и сопровождения следует
уделить вопросам обучения персонала и, соответственно, планированию
инвестиций в этот процесс.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На успех внедрения СЭД на предприятии могут повлиять многие
факторы, поэтому необходимо с самого начала учитывать все аспекты
внедрения системы.
Риск – это неопределенное событие или условие, наступление которого
может иметь как положительное, так и отрицательное влияние на проект.
Необходимо заметить, что риски связаны между собой и являются следствием
или причиной друг друга. Недооценка риска на одном этапе, может
отобразиться на другом этапе.
Если не учесть риски в начале внедрения СЭД, то впоследствии могут
увеличиться затраты на проект, затянутся сроки внедрения, не будет достигнут
запланированный результат.
63
При осуществлении любого проекта всегда возникает ситуация, связанная
с неопределенностью, неполнотой или неточностью информации об условиях
реализации проекта и связанных с ними затратах и результатах.
Для того чтобы снизить потери от возможных просчетов и избежать
провала проекта в целом, методология управления проектами предусматривает
специальные процедуры, помогающие учесть факторы неопределенности и
риска на всех фазах и этапах проекта. Зная виды и значимость рисков, можно на
них воздействовать, снижая их отрицательное влияние на эффективность
проекта.
Рассмотрим риски, которые могут возникнуть при внедрении СЭД на
предприятии, а также возможность их предотвращения или устранения.
Возможные риски, мероприятия по их предотвращению и устранению
приведены в таблице 2.2.
Таблица 2.2
Анализ рисков проекта
Некорректная постановка
задач и целей
Четко сформулировать
требования к результатам
внедрения проекта;
определить, какие
показатели считать
успешными, зафиксировать
в техническом задании
Согласование технического
задания со всеми
заинтересованными
сторонами
Недооценка важности
отдельных этапов проекта
Реализация проекта строго
по утвержденному плану
Возврат к уже
выполненным задачам, их
переоценка
Недостаточное изучение
объекта автоматизации
Исключить недостаточность
данных от сотрудников;
мотивировать их на
сотрудничество с командой
проекта
Вернуться к этапу
исследования объекта;
мотивировать сотрудников
на достоверное
предоставление
информации
Уровень квалификации
участников команды не
соответствует
поставленным задачам
Составлять команду
проекта из специалистов,
необходимой
квалификации
Обучение или наем
необходимого специалиста
Незапланированное
изменение требовании
заказчика
Соблюдение процедуры
внесения изменении в
проект; на этапе
согласования тз уточнить
все требования заказчика
Тщательное рассмотрение
каждого изменения целей и
задач проекта и оценка
возможностей внесения
изменении в проект
64
Продолжение Таблицы 2.2
Выход за рамки бюджета
Выполнять работу строго в
соответствии с
утвержденным планом;
промежуточный контроль
над ходом реализации
проекта
Провести оценку
возможности изменения
бюджета проекта
Недостаточное внимание
высшего руководства к
проекту
Разъяснение руководителя
проекта о необходимости
их участия;
выбор руководителя
проекта, который активно
поддерживает внедрение
СЭД и обладает большим
авторитетом
Наделение
дополнительными
полномочиями
руководителей,
заинтересованных в
успешной реализации
проекта.
Превышение сроков
реализации проекта
Промежуточный контроль
над ходом разработки
проекта; усиление
контроля над соблюдением
сроков проекта
Провести оценку
возможности изменения
сроков проекта;
проанализировать
возможность изменения
или сокращения задач
проекта
Слабая вовлеченность в
проект сотрудников
предприятия
Выбор руководителя
проекта, обладающего
высоким авторитетом и
активно поддерживающий
внедрение проекта
Повышение мотивации
сотрудников; разъяснение
выгод от реализации
проекта; ввод
поощрительных мер за
активное участие
Конфликт интересов
участников проекта
Формирование
организационных структур
управления проектом, в
которых обеспечено
представительство всех
заинтересованных сторон
на всех уровнях
управления
Привлечение к управлению
проектом высшего
руководства, в качестве
арбитра
Сложность освоения
новых технологии
сотрудниками
Разработка подробной
пользовательской
документации;
обеспечение технической
поддержки пользователям
Обучение персонала; наем
квалифицированных
сотрудников
Компьютерная техника,
сервера не соответствует
техническим
характеристикам,
необходимым для
работоспособности
системы.
Контроль над ходом
проекта со стороны
руководства
Проведение модернизации
компьютерной техники,
серверов до необходимого
уровня работы системы
Таким образом, имеются некоторые проблемы при реализации проекта,
но они не носят неразрешимого характера. При правильном подходе к
65
внедрению СЭД их можно избежать или решить с наименьшими потерями.
Здесь очень важную роль играет курирование процедуры внедрения на уровне
высшего руководства. Необходимо, чтобы был выражен высокий приоритет
преобразовании, и они носили системный характер, затрагивая как можно более
широкий круг производственных и организационных процессов.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе,
включает в себя следующие аспекты:
защита информации непосредственно в ИС от внутренних угроз;
защита информации от внешних гроз.
Для защиты от внутренних угроз в системе используется политика
разграничения прав доступа для пользователей. Характеристика политики
разграничения приведена в таблице 2.3
Таблица 2.3
Разграничение прав пользователей
Группы
пользова
телей
Модуль
авторизац
ии
Модуль
регистраци
и
документа
Модуль
постановки
на
контроль
Модуль
резолюции
Ввод
данных
Руководит
ель
Чтение
Нет
Полный
Полный
Нет
Сотрудни
к
Чтение
Полный
Чтение
Ограничен
Полный
Админист
ратор
системы
Полный
Полный
Полный
Полный
Полный
Делопрои
зводитель
Полный
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
методов:
– использование программно-аппаратных комплексов защиты
информации;