77
Рис. 2.2. Итерационная модель жизненного цикла
3. Спиральная модель – основной упор делается на начальные этапы:
анализ и проектирование, на которых проверяется и обосновывается
реализуемость технических решений путем создания прототипов. Каждый
виток спирали соответствует поэтапной модели создания фрагмента с
уточнением целей и характеристик проекта, определением качества и
планированием работ на следующем витке. Таким образом происходит
углубление и конкретизация деталей проекта с выбором из них
обоснованного варианта и доведением его до реализации.
Преимуществами спиральной модели выделяют:
• Возможность накопления и повторного использования программных
средств, прототипов и моделей;
• Упор на развитие системы в процессе проектирования;
• Анализ риска и издержек.
Модель представлена на рисунке 2.3.
78
Рис. 2.3. Спиральная модель жизненного цикла
Этап анализа требований является первой фазой разработки, которая
включает в себя уточнение, формализацию и документацию требований
заказчика. Список требований к системе должен включать в себя совокупность
условий, при которых предполагается эксплуатация будущей системы, описание
выполняемых системой функций и ограничения, накладываемые на процесс
разработки (сроки завершения отдельных этапов, расходование ресурсов,
требования к обеспечению безопасности информации). Целью анализа является
преобразование неточных пожеланий заказчика в максимально конкретные
определения. Результатом этапа должна являться модель требований к системе
(также – системный проект), определяющая:
• Общую архитектуру системы, её функции, внешние условия,
распределение функций между программной и аппаратной частью;
• Пользовательские интерфейсы и распределение выполняемых функций
между сотрудником и системой;
• Требования к программно-аппаратным и информационным ресурсам,
физическим характеристикам компонентов.
Модель требований должна включать в себя:
• Полную функциональную модель требований к будущей системе с высокой
глубиной проработки (до операций должностных лиц);
• Спецификации операций нижнего уровня;
79
• Полный пакет отчетов и документов по функциональной и
информационной моделям;
• Рекомендации по организационной структуре подразделений для
поддержки системы.
Использование модели жизненного цикла позволяет обеспечить ряд
существенных преимуществ по сравнению с традиционной моделью, в которой
начальные этапы осуществляются неформализованными способами. В противном
случае возможно значительное несовпадение ожиданий и результата, так как к
моменту реализации большей части системы проходит много времени, что влечет
за собой дополнительные итерации разработки и/или модификации, требующих
дополнительных финансовых и временных затрат.
Этап анализа требований считается основополагающим и важнейшим среди
всех остальных этапов жизненного цикла, так как оказывает существенное
влияние на все последующие этапы. Ключом к успешному завершению этого
этапа является, во-первых, четкое понимание того, что предполагается сделать, а
во-вторых, корректно задокументировать это, поскольку система будет
разрабатываться исходя из документации.
Выполнение действий на этапе проектирования разделяются на два
подэтапа:
• Проектирование архитектуры системы, включающее в себя разработку
структуры и интерфейсов, согласование функций;
• Проектирование с углубленной детальностью: разработка подробной
спецификации для каждой компоненты систем и создание интерфейсов
между ними.
Проектирование является этапом жизненного цикла, на котором
вырабатываются методы реализации требований к автоматизированной системе
управления предприятием, сформулированные на этапе анализа. Результатом
работы на этапе проектирования становится модель реализации,
иллюстрирующая, каким образом система будет удовлетворять предъявляемым к
ней требования (опуская технические подробности). Данный этап является, по
сути, связующим звеном между анализом и реализацией.
80
На этапе реализации осуществляется фактическое создание системы как
комплекса программно-аппаратных средств, начиная проектированием и
созданием глобальной телекоммуникационной инфраструктуры и заканчивая
разработкой и установкой приложений.
Этап тестирования и отладки. Корректность автоматизированной системы
является важнейшим её свойством и составляет основной предмет заботы
разработчиков. Под корректностью, в идеальном смысле, понимается отсутствие
в системе ошибок, что является невозможным для сложных программных
продуктов. Таким образом, главной целью данного этапа является установление
корректности. Тестирование – один из наиболее долгих этапов и временные
затраты на него увеличиваются прямо пропорционально масштабу системы.
Тестирование представляет собой набор процедур и действий,
предназначенных для проверки корректной работы системы в заданных режимах
и с соблюдением реальных условий. Целью тестирования ставится выявление
наличия ошибок, или, в идеальной ситуации, продемонстрировать их полное
отсутствие. Отладка является логичным продолжением этапа тестирования,
который начинается с момента выявления факта наличия ошибки и заключается в
проведении комплекса процедур и действий по установлению места и характера
ошибки и способов её удаления.
Для этапа эксплуатации и сопровождения выделяются следующие задачи:
• Администрирование системы, то есть обеспечение устойчивости работы
системы и сохранности хранимой информации;
• Техническая поддержка, то есть своевременная модернизация,
обслуживание и ремонт отдельных компонентов;
• Развитие системы, то есть оперативная адаптация возможностей
эксплуатируемой системы к текущим потребностям предприятия.
Данный список работ обязательно включается в оперативный план
информатизации предприятия, который формируется с соблюдением всех
условий плана стратегического. В противном случае, в рамках существующей
системы возможно возникновение компонентов, нарушающих эффективную
эксплуатацию системы.
81
На современном российском и зарубежном рынке широко развита практика
передачи функций по технической поддержке сторонним компаниям; общее
название подобной практики получило название аутсорсинг.
На заключительных этапах проводится организация тренингов и обучение
персонала, в чьи обязанности войдет использование автоматизированной
информационной системы.
При разработке проекта будет использоваться ГОСТ 34.601-90. Данный
стандарт позволит отслеживать и контролировать все этапы проектирования,
разработки и внедрения автоматизированной системы. Моделью жизненного
цикла была выбрана спиральная, так как её результатом становится наиболее
жизнеспособный и доработанный продукт, благодаря системе возврата к
предыдущим этапам для внесений изменений в процессы.
Этапы создания автоматизированной информационной системы по стандарту
ГОСТ 34.601-90 приведены в таблице 2.1.
Таблица 2.1.
Этапы создания АИС согласно стандарту ГОСТ 34.601-90
Стадии Этапы работ
1. Формирование
требований к АС
1.1. Обследование объекта и обоснование
необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки
на разработку АС (тактико-технического задания)
2. Разработка
концепции АС.
2.1. Изучение объекта.
2.2. Проведение необходимых научно-
исследовательских работ.
2.3. Разработка вариантов концепции АС,
удовлетворяющего требованиям пользователя.
2.4. Оформление отчёта о выполненной работе.
3. Техническое
задание.
Разработка и утверждение технического задания на
создание АС.
4. Эскизный проект. 4.1. Разработка предварительных проектных решений
по системе и её частям.
4.2. Разработка документации на АС и её части.
5. Технический
проект.
5.1. Разработка проектных решений по системе и её
частям.
5.2. Разработка документации на АС и её части.
82
5.3. Разработка и оформление документации на
поставку изделий для комплектования АС и (или)
технических требований (технических заданий) на их
разработку.
5.4. Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации.
6. Рабочая
документация.
6.1. Разработка рабочей документации на систему и её
части.
6.2. Разработка или адаптация программ.
7. Ввод в действие. 7.1. Подготовка объекта автоматизации к вводу АС в
действие.
7.2. Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями
(программными и техническими средствами,
программно-техническими комплексами,
информационными изделиями).
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний.
8. Сопровождение
АС
8.1. Выполнение работ в соответствии с гарантийными
обязательствами.
8.2. Послегарантийное обслуживание.
83
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Рисками обычно называют вероятность нереализованности некоторых целей
при реализации проекта автоматизации деятельности предприятия. Так как общая
совокупность условий, которые могут повлиять на конечный результат проекта,
чрезвычайно высока, она редко рассматривается на практике. Чаще всего, из всего
множества выделяется ограниченный перечень характеристик принятого
решения, которые могут касаться чисто технических аспектов, так и организации
работ по реализации.
Перед тем как проводить анализ факторов риска происходит планирование
мероприятий для снижения влияния этих факторов на результат и принятие
решений на различных этапах создания системы.
Всеми сторонами, принимающими участие в процессе (компания – заказчик и
фирма-подрядчик – поставщик), проводится анализ рисков со своей стороны.
Все риски можно разделить на две группы:
• Бизнес-риски;
• Риски, связанные с жизненным циклом системы.
Первая группа, как правило, анализируется на этапе формирования стратегии
автоматизации, то есть при выборе подхода к автоматизации и к выборе типа
системы.
Риски с реализацией жизненного цикла рассматриваются на этапе разработки,
хотя и могут рассматриваться на других этапах.
При анализе бизнес-рисков определяемыми проблемами являются: будут ли
устранены проблемы бизнеса, которые планируется решить внедрением
автоматизированной системы, и каким должен быть подход к автоматизации,
чтобы достичь желаемого эффекта.
Перечень факторов риска включает в себя следующие позиции:
• Необходимость и достаточность реализованных функций системы при
ведении бизнес-процесса;
• Влияние системы на бизнес;
• Инвестиционные риски;
• Способность предприятия выполнять график инвестиций, затрачиваемых
на реализацию.
84
Технические риски включают в себя следующие факторы:
• Количество внешних систем для взаимодействия;
• Наличие нестандартного оборудования;
• Степень новизны оборудования для заказчика и вендора;
• Уровень опыта по эксплуатации подобных систем у участников,
исполнителей и пользователей применительно к аппаратно-программной
части;
• Качество технической поддержки компании-поставщика решения;
• Уровень знаний пользователей в сфере информационных технологий;
• Степень новизны применяемых технических решений для системного
интегратора;
• Общая зависимость изменений в структуре бизнес-процессов,
организационной структуре компании и специфике работы пользователей
от глубины внедрения системы.
Риски, связанные с управлением процессом создания системы, включают
следующие факторы:
• Размеры системы, количество и географическое расположение
пользователей;
• Календарные сроки и величина трудозатрат по внедрению;
• Количество слабо связанных между собой проектов, которые необходимо
выполнить в рамках создания системы;
• Общее количество привлеченных вендоров (оборудование и программное
обеспечение);
• Количество проектов, от реализации которых зависит успех
автоматизации;
• Отношение пользователей и высшего управленческого персонала к проекту
автоматизации;
• Наличие сотрудничества между пользователями и исполнителями.
Большинство компаний-исполнителей проектов имеют собственные методы
управления рисками, которые включают в себя:
• Методы по выделению факторов риска;
85
• Методы количественной оценки влияния факторов на различные
параметры проекта, такие как увеличение стоимости решения или времени
по реализации всего проекта или отдельных компонентов.
Типовая схема процедуры управления рисками приведена на рисунке 2.4.
Рис. 2.4. Типовая схема процедуры управления рисками
Существует несколько подходов для минимизации бизнес-рисков:
• Минимизация инвестиционных рисков;
• Стандартизация всех компонентов решений настолько, насколько это
возможно.
Для минимизации рисков, связанных с нарушением графика, целесообразно
планировать процессы проведения автоматизации так, чтобы результатом
каждого этапа становилось законченное решение, представляющее конечную
ценность.
Перечень компонентов, поддающихся стандартизации имеет вид:
• Автоматизируемые бизнес-процессы предприятия;
• Процессы системы;
• Прикладное программное обеспечение;
• Стандарты на оборудование и рабочие станции.
86
Желательно также, чтобы структура автоматизируемых бизнес-процессов
удовлетворяла общепринятым рекомендациям (ERP), а также совокупности
государственных стандартов. Для прикладного программного обеспечения
желательно создание набора стандартов в плане архитектуры, шлюзов,
интерфейсов, включая графический интерфейс пользователя. На уровне систем
управления базами данных определяются требования к интерфейсам, поддержке
распределенности. Аналогичным образом формулируются наборы стандартов для
всех уровней, от операционных систем до телекоммуникаций. Заложение
поддержки стандартов позволяет в будущем затрачивать минимальные средства
для наращивания функциональных возможностей системы.
Для минимизации технических рисков рациональным является использование
поэтапного подхода:
• Составление графика работ таким образом, чтобы больший приоритет дать
компонентам, связанным с большим риском, и выполнить их на ранних
этапах;
• Использование макетов и прототипов для предварительного тестирования
технических решений;
• В целях исключения факторов риска целесообразным будет разработка
альтернативных вариантов.
Снижение рисков управления достигается путем применения жестких
стандартов на управление проектом в части планирования, документирования
хода проекта, мониторинга изменений и процедур контроля исполнения.[4]
Риски, возникновение которых возможно на различных этапах создания
автоматизированной информационной системы, предполагаемые последствия и
меры, предпринимаемые по их устранению, приведены в таблице 2.2.
Таблица 2.2.
Ожидаемые риски на этапах жизненного цикла программы
Этап Риск Последствие Меры
Анализ требований
Неполный учет
требований и
пожеланий
заказчика
Несоответствие
результата
ожиданиям
Использование
спиральной
модели разработки