66
Возможность планирования сроков завершения всех работ и
соответствующих затрат.
Недостатками данной модели являются:
Отсутствия обратных связей между этапами;
Несоответствие реальной разработке, так как возникает потребность в
возврате к предыдущему этапу.
Таким образом, данная модель эффективна для проектов с высокими
требованиями к качеству при отсутствии жестких ограничений затрат и
графика работ.
Спиральная модель жизненного цикла допускает начало работы на
следующем этапе, не завершая предыдущего (рис. 9). Таким образом, суть
спиральной модели состоит в возможности цикличного прохождения всех
этапов жизненного цикла системы в несколько повторений, или «витков»,
каждый раз создавая новый образец и проверяя актуальность требований, по
которым он создавался. На каждом «витке» вносятся технические доработки в
интерфейс и функциональность системы. Такая гибкость позволяет использовать
модель на предприятиях любого масштаба. [12]
Рис. 9 Спиральная модель ЖЦ
67
В спиральной модели делается упор на начальные этапы жизненного цикла:
анализ требований, проектирование. На этих этапах в каждом «витке»
проверяется работоспособность технических решений, а также соблюдение
плана и функционала проекта. Каждый пройденный круг соответствует
поэтапной модели создания фрагмента или версии системы, на нем определяется
качество, планируются работы следующего витка спирали. [7]
Данная модель используется для того, чтобы как можно быстрее показать
пользователям системы работоспособный продукт, в результате чего более
очевидны требования к системе.
Преимущества спиральной модели:
накопление и повторное использование программных средств, моделей
и прототипов;
ориентация на развитие и модификацию системы в процессе ее
проектирования;
анализ риска и издержек в процессе проектирования. [7]
Недостатком спиральной модели является отсутствие регламентаций стадий
разработки. Основная проблема спирального цикла - определение момента
перехода на следующий этап. Для разрешения данной проблемы требуется
введение временных ограничений на каждый из этапов жизненного цикла.
В итоге считаю лучшим выбором каскадную модель, так как в начале
разработки можно достаточно точно и полно сформулировать все требования к
системе. Однако в качестве вариации целесообразней выбрать каскадную модель
с промежуточным контролем, чтобы предусмотреть возможность возвращения к
предыдущим этапам для внесения определенных изменений и пересмотра
отдельных вопросов.
Теперь остановимся более детально на анализе и выборе одного из
общеизвестных стандартов ЖЦ. Среди них ГОСТ 34, ISO 12207, ISO 15288,
MSF, RUP, COBIT, Oracle CDM, XP.
ГОСТ 34.601-90. Отличается высокой степенью формализации и
предполагает каскадный подход. На сегодняшний день ГОСТ многократно
68
становился основой для доработок и частичного использования в других
стандартах / методологиях и в целом в исходном виде не является
исчерпывающим как единственный источник информации для выполнения
проекта разработки / внедрения. Благодаря своей структурированности, ГОСТ
34.601-90 до сих пор служит базой для адаптации, которую можно адаптировать
к конкретным условиям деятельности предприятия. [7] Приложение к стандарту
содержит детальное описание работ, включая списки формируемых по
завершении этапа документов.
ISO/IEC 12207. В РФ был разработан и принят идентичный ISO 12207
стандарт ГОСТ Р ИСО/МЭК 12207-2010. Основной идеей разработчиков ГОСТ
12207 являлось создание единого общекорпоративного стандарта, которым было
бы возможно воспользоваться при возникновении любой задачи из тех, которые
описаны в документе. Данный ГОСТ предполагает, что процессы состоят из
этапов, для которых определены задачи (а также цели и результаты). Тем не
менее, допускается адаптация процессов к уже имеющимся стандартам
предприятия. [12]
ISO/IEC 15288. В отличие от рассмотренного ранее стандарта, ISO 15288
распространяется на системы в целом, охватывая такие их элементы. Согласно
данному стандарту, любой процесс ЖЦ может быть начат в любой момент, без
ограничения порядка использования. Имеет более высокий уровень абстракции в
сравнении с ISO 12207, так как данный стандарт не приводит ролей, конечных
результатов в виде списка выходных документов, либо же состава работ, лишь
оставаясь на уровне концепции. [4]
Microsoft Solution Framework, (MSF). Важным преимуществом MSF
является ее практическая направленность и простота. Для MSF очень важно
взаимодействие внутри проектной команды и несмотря на то, что минимальное
число ее участников официально в методологии ограничено всего тремя,
выделяются шесть основных ролей внутри команды, и связь между участником
и ролью имеет тип «многие-ко-многим». Среди шести упомянутых кластеров:
‒ управление программой (архитектурным решением);
‒ разработка (программной и технической архитектуры);
69
‒ тестирование (планирование, разработка, отчетность);
‒ управление релизами;
‒ управление требованиями заказчика (в части интерфейса решения, а также,
конечно, обучения и технической поддержки);
‒ управление продуктом.
MSF представляет собой более гибкий и универсальный подход для
внедрения других систем / программных продуктов. [12]
Rational Unified Process, (RUP). Является одним из наиболее
ориентированных на пользователя подходов. Предполагает итеративную
разработку, большое внимание к архитектуре, к потенциальным рискам и
управлению. Широкий диапазон возможностей и инструментов, предлагаемый
методологией, является общей моделью «конструктора», необходимые элементы
которого можно выбрать – и таким образом, значительно снизить стоимость и
сроки внедрения.
Control Objectives for Information and related Technology, (COBIT).
Предоставляет сохранение единого подхода к сбору, анализу информации,
подготовке выводов и заключений на всех уровнях управления, контроля и
аудита ИТ, возможность сравнения существующих ИТ процессов с лучшими
практиками.
Custom Development Method, Oracle CDM. Данная методология опирается
на использование инструментария Oracle. Все модели жизненного цикла
являются каскадными. Для различных систем CDM предусматривает три
модели жизненного цикла. При условии, что предусмотрены все этапы и работы,
выбирается «классическая» модель. В случае, если проект небольшой,
выбирается «облегченный подход», а в условиях быстрой разработки,
выбирается «Fast track».
eXtreme Programming, (XP). Основная особенность данной методологии
состоит в ее эффективности в условиях неопределенных или нечетких
требований. Методология предлагала простой дизайн, переработку кода для
контроля затрат, постоянное присутствие заказчика, разработку через тесты и
другие аспекты, выгодно отличавшие ее. [12]
70
Проанализируем основные критерии выбора стандарта жизненного цикла
системы:
Характеристика требований к проекту.
Характеристика пользователей.
Характеристика типов проекта и рисков.
Мною выбран стандарт Oracle CDM, так как данная методология опирается
на инструментарий Oracle, а в качестве сервера приложений используется
промышленный сервер приложений Oracle WebLogic server, и в качестве СУБД
используется промышленная СУБД Oracle 11G.
Согласно данной методике жизненный цикл состоит из определенных этапов
проекта и процессов, каждый из которых выполняется в течение нескольких
этапов.
Как известно, выделяются следующие этапы жизненного цикла:
1) Анализ. На данном этапе происходит формулирование детальных
требований к проектируемой системе. Для этого выполняется уточнение
требований заказчиков, которые формализуются и документируются.
Фактически на этом этапе определяется, что должна делать будущая система. В
формулировании четких целей лежит ключ к успеху всего проекта. Данные
задачи решаются системным аналитиком. Результатом данного этапа является
модель требований к системе. [7]
2) Проектирование. На данном этапе происходит преобразование требований,
полученных в результате анализа системы. Этап проектирования определяет,
каким образом система будет удовлетворять предъявленным к ней требованиям.
Менеджер проекта на данном этапе продумывает всю архитектуру ИС, а
программист выбирает язык программирования. Результатом этапа будет
построенная модель реализации, демонстрирующая, как система будет
удовлетворять предъявленным к ней требования, без описания технических
подробностей. Фактически модель реализации является развитием и уточнением
модели требований, а само проектирование является мостом между анализом и
реализацией. Конечным результатом будет схема базы данных и набор
спецификаций модулей системы. [1]
71
3) Реализация. На этом этапе выполняются проверка корректности системы,
посредством написания и тестирования приложений. Тестирование представляет
собой набор процедур и действий для выявления и отладки ошибок системы.
Результатом данного этапа является исходный и исполнимый код приложения и
окончательное описание функционала системы.
4) Внедрение. На данном этапе осуществляется установка уже проверенной
новой прикладной системы и подготовка к началу ее эксплуатации.
Руководитель окончательно внедряет систему в эксплуатацию, устанавливает
программный продукт на компьютерах и проводит обучение персонала
алгоритму работы системы. Результатом внедрения будет отчет о завершении
проекта, показатели удовлетворенности заказчика и потребителей.
Существует несколько способов внедрения системы:
Параллельная стратегия. Этот способ применяется, когда старую
систему необходимо заменить новой. При этом одновременно
работают старая и новая система, а их выходные документы
сравниваются. Если они согласуются длительное время, можно
переключиться на новую систему.
«Скачок». Данный подход подразумевает резкий переход к новой
системе без функционирования старой. Однако, если данные не
окажутся точны, а люди должным образом не обучены, существует
риск остановки процесса.
«Пилотный проект». В этом способе применяется стратегия «скачка»,
но применяется она к ограниченному участку деятельности.
Соответственно, такой подход более надежен, так как снижает риски.
«Узкое место». В данном случае план внедрения выполняется только
для людей, работающих в конкретной малой части производственного
процесса. Этот способ служит успешным примером, помогающим
внедрению во всем офисе.
При рассмотрении данных тактик внедрения, я выбрала «Пилотный проект»
как самый оптимальный и надежный способ.
72
5) Эксплуатация. На данном этапе происходит поддержка и слежение за
приложением, планирование будущих функциональных расширений.
Основные задачи этапа эксплуатации и сопровождения:
обеспечение устойчивости работы системы и сохранности информации
- администрирование;
своевременная модернизация и ремонт отдельных элементов —
техническая поддержка;
адаптация возможностей эксплуатируемой системы к текущим
потребностям бизнеса предприятия — развитие системы. [7]
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Под риском обычно понимается вероятность того, что какие-то цели при
реализации проекта автоматизации деятельности предприятия не будут
достигнуты. Грамотное управление рисками способно спасти проект, в то время
как неверные действия по отношению к которым могут его «потопить». [12]
Анализ факторов риска предваряют: планирование мероприятий для
снижения влияния факторов риска на исход проекта и принятие решений на
различных этапах процесса создания автоматизированной системы. Риски,
связанные с реализацией жизненного цикла, как правило, рассматриваются на
этапе разработки проекта автоматизации деятельности предприятия. Кроме того,
они могут рассматриваться на различных этапах реализации проекта. [7]
Риски можно разделить на группы:
1. Технические риски – связаны с реализацией технических решений и
внедрением системы.
2. Организационные – связаны с корректностью этапа обследования
бизнес- архитектуры организации.
3. Риски проектного управления.
Рассмотрим наиболее характерные риски для данного проекта и методы из
минимизации.
На этапе анализа возможны следующие риски:
Отсутствие согласованных требований к ИС.
73
Недальновидный анализ сроков и стоимости проекта.
Для устранения и минимизации данных рисков необходимо на стадии
постановки задачи как можно более подробно уточнить требования у заказчика с
предоставлением макетов входных и выходных форм. Также необходимо более
детально прорабатывать задачи и цели проекта.
На этапе проектирования возможно столкнуться со следующими рисками:
Нехватка необходимого уровня знаний у проектной команды.
Ежедневная отчетность и составление графика согласования / утверждения
решений и результатов во избежание риска слишком длительного процесса
оформления документов.
Неправильное понимание технического задания, что может привести к
неправильному программированию архитектуры и потере времени.
Для уменьшения вероятности данного риска необходимо более чёткое
написание технического задания, понятного программисту.
На этапе реализации выявлены следующие риски:
Обнаружение невозможности реинжиниринга бизнес-процессов в
текущих условиях.
Программные риски при приобретении ПО третьих фирм.
Технологические риски.
Для решения данных проблем необходимо соответствие нормативной
конфигурации компьютера и совместимость с приложениями инфраструктуры.
На заключительных этапах возможны следующие риски:
Изменение как внешних рыночных условий, так и внутренних
процессов компании.
Для минимизации данного риска необходимо перед началом проекта
внедрения четко уяснить, что может помешать достижению результата, и
разработать меры по предотвращению возможных негативных последствий.
74
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Цель информационной безопасности – обеспечить бесперебойную работу
организации и свести к минимуму ущерб от событий, таящих угрозу
безопасности, посредством их предотвращения и сведения последствий к
минимуму. С точки зрения безопасности все виды информации, включая
бумажную документацию, базы данных, информационные системы, съемные
носители, разговоры и другие способы, используемые для передачи знаний и
идей, требуют надлежащей защиты. Информация и поддерживающие еѐ
информационные системы и сети являются ценными производственными
ресурсами организации. Их доступность, целостность и конфиденциальность
является приоритетными направлениями программы развития информационной
безопасности. [12]
Контроль и обеспечение защиты осуществляется на всех уровнях
предприятия в зависимости от потенциальных угроз и включает такие
механизмы, как:
1) Защита от внутренних угроз. Для обеспечения защиты информации
осуществляется создание централизованной системы идентификации и
управления доступом пользователей к корпоративным информационным
ресурсам:
Централизованное ведение учетных записей пользователей.
Поддержка ролевой модели предоставления доступа пользователям.
Поддержка механизмов согласования со средствами локального
администрирования систем.
Права пользователей описаны в таблице № 7.
75
Таблица № 7
Разграничение прав пользователей
Группы
пользовател
ей
Создание
и ведение
заявки
Редактирован
ие заявки
Перенап
равление
заявки
Работа с базой
знаний
Доступ в
Internet
Руководител
и
Чтение
Чтение
Чтение
Чтение
Не
ограничен
Ведущий
специалист
Чтение/со
здание/уд
аление
Чтение/созда
ние/удаление
Чтение/с
оздание
Полный
Ограниче
н
Менеджер
Чтение/со
здание
Чтение/созда
ние
Чтение/с
оздание
Чтение
Нет
Специалист
по IT
Чтение/со
здание
Чтение/созда
ние/
удаление
Чтение/с
оздание/
удаление
Полный
Не
ограничен
2) Защита от внешних угроз. В систему СУВК возможен вход только
авторизированным пользователям. Если же субъект пытается использовать
неавторизованный ресурс или авторизованный ресурс недозволенным способом,
то функция будет блокировать попытку и дополнительно может оповещать об
инциденте.
Защита информации от утечки по техническим каналам – это комплекс
организационно-технических и технических мероприятий исключающих или
ослабляющих бесконтрольный выход конфиденциальной информации за
пределы контролируемой зоны. Наиболее эффективным средством
предотвращения утечки информации по электромагнитным каналам является ее
шифрование. В этом случае даже если злоумышленник сможет перехватить
передаваемую информацию потребуется значительное время для ее
расшифровки. [13]