Анализ каскадной, итерационной и спиралевидной моделей внедрения корпоративных информационных систем

Подробности

Опубликовано: 31.03.2018 10:26

Автор: Гудков Е.А., Деревнина А.М., Катасонова Н.С.

Просмотров: 30126

Аннотация: в работе приводится описание каскадной, итерационной и спиралевидной моделей внедрения корпоративных информационных систем. Анализируются достоинства и недостатки каждой из моделей, рассматривается применимость моделей при имплементации сложных информационных систем. 
Скачать: PDF (статья), PDF (выпуск №1).
Ключевые слова: модели жизненного цикла информационной системы, модель жизненного цикла ИС, стандарты жизненного цикла информационной системы, модели разработки ПО, поэтапная модель с промежуточным контролем, модель водопад, итерационная модель преимущества и недостатки, гибкие методологии, водопадная модель разработки ПО, гибкая модель жизненного цикла.

Жизненный цикл (далее – ЖЦ) программного обеспечения (далее – ПО) состоит из ряда этапов, начинающихся стадией зарождения и заканчивающихся прекращением применения (рис. 1). Любая информационная система (далее – ИС) представляется совокупностью программных продуктов или ПО, тем самым определение жизненного цикла ПО и ИС тождественны. Вследствие того, что современные корпоративные информационные системы (далее – КИС) состоят из множества ИС, последнее применимо также и к КИС.

Рис. 1. Жизненный цикл программного обеспечения

Процесс внедрения КИС является составной частью ЖЦ. В работе [1] приводится типизация стадий имплементации КИС, включающая этапы подготовки, проектирования, реализации, опытно-промышленной и продуктивной эксплуатации. Этапы внедрения КИС задают последовательность операций, необходимых для успешного использования программного решения на предприятии заказчика. Тем самым можно говорить о двух жизненных циклах: ЖЦ корпоративной информационной системы и ЖЦ процесса её внедрения. Следуя данным рис. 2, этапы циклов зачастую сопоставимы, однако акцент в первом случае сделан на программный продукт, а во втором – на ход его реализации. Часто процесс имплементации КИС называют моделью внедрения, которая задаёт порядок операций для имплементации системы, причём от модели к модели последовательность и содержание активностей разнится. Выделяют три базовые модели внедрения КИС, все прочие рассматриваются как их производные [2]:

• каскадная;
• итерационная;
• спиралевидная.

Целью данной работы является анализ моделей внедрения корпоративных информационных систем для обеспечения эффективного процесса имплементации. Реализация цели потребует отдельного детального рассмотрения каждой из моделей.

 Рис. 2. Сопоставление жизненного цикла системы  и этапов внедрения КИС 

Каскадная модель внедрения корпоративных информационных систем

Воспользуемся типовыми этапами ЖЦ проекта внедрения (рис. 2). Преобразуем линейную последовательность следующим образом: каждый предыдущий этап сместим влево вверх, а каждый последующий – вправо вниз, тем самым получим схему, следующую слева направо и сверху вниз. Каскадная модель внедрения КИС образуется путём соединения полученных этапов между собой (рис. 3). Данная модель или, как часто ее называют, модель водопад (Waterfall) была предложена в 1970 году У. Ройсом.Реализация проекта, согласно данной модели, ведётся путём строгого выполнения задач каждого из этапов (типовые этапы внедрения КИС), при этом переход к последующему этапу возможен лишь в случае успешного завершения предыдущей стадии [3]. Пропуск какого-либо из этапов, возврат к предыдущим стадиям и повторение этапов запрещены, именно по этой причине модель часто именуют последовательной или однопроходной. Следуя рис. 3, очевидны достоинства и недостатки водопадной модели. К плюсам можно отнести:

• прозрачность определения сроков, работ и затрат;
• наличие согласованной процедуры перехода между этапами;
• независимость выполнения этапов,

минусами являются:

• невозможность устранения ошибок предыдущих этапов;
• отсутствие гибкости.

Рис. 3. Переход от типовых этапов к каскадной модели внедрения КИС

Проект внедрения КИС на основе данной модели состоит из активностей:

• подготовка проекта, заключающаяся в формировании основных концепций, стратегий и подходов к реализации функционала КИС;
• идентификация и анализ требований, предъявляемых к КИС и их приоритезация;
• формирование проектных решений и спецификаций, описывающих способ реализации ранее сформированных требований к КИС;
• кастомизация и доработка КИС на основе ранее подготовленных решений и спецификаций, описывающих реализацию требований;
• функционально-модульное, интеграционное и приёмочное тестирование выполненных настроек и доработок КИС;
• переход к продуктивной эксплуатации и поддержка.

Кроме того, каждый из этапов заканчивается валидацией и согласованием активностей следующей стадии, а также подтверждением возможности перехода к последующему этапу. Вышеприведённый список демонстрирует закономерность: проектирование, реализация и тестирование КИС ведутся на основе требований, идентифицированных на ранних этапах. Тем самым, если изначальные требования были сформированы неверно, вся информационная система будет подготовлена некорректно (ранее отмеченный минус о невозможности устранения ошибок предыдущих этапов), что вероятнее всего потребует доделывания КИС. Отсутствие гибкости модели можно отнести как к минусу, так и плюсу: если ведётся частичное внедрение КИС незначительного по объёму функционала, возможные изменения требований по сравнению с начальными желательно включить в проект. Однако, когда имплементируется многофункциональная КИС, интегрированная с множеством как внешних, так и внутренних подсистем, незначительная корректировка требований может привести к значительным изменениям сроков, работ и затрат.

Именно поэтому каскадную модель часто применяют на проектах внедрения КИС «с нуля» и «тиражирования», когда объём выполняемых работ и их трудозатраты достигают внушительных величин. На подобных проектах возникает конфликт интересов между различными заинтересованными сторонами, поэтому результаты каждого из этапов тщательно документируются и согласуются во избежание разночтений и увеличения объёма работ. Невозможно запустить КИС в масштабах предприятия с учётом требований и пожеланий каждого из сотрудников. Поэтому объём задач фиксируется списком наиболее важных и подтверждённых требований ключевыми, но не конечными пользователями. В случае появления новых или изменения существующих требований предлагается регистрировать запрос на изменение. Суть последнего состоит в следующем: необходимые доработки КИС будут выполнены вне рамок проекта в отдельные сроки и бюджет. 

Итерационная модель имплементации информационных систем

Попытаемся устранить недостаток однопроходной модели. Для этого каждый из этапов схемы рис. 3 дополним контуром обратной связи, тем самым добавив возможность возврата на предыдущие стадии. Если внимательно проанализировать полученный результат, окажется, что каждый из этапов может выполняться несколько раз. Именно поэтому полученную модель (рис. 4) называют итерационной. Впервые применённая в США ещё в 1957 году, многопроходная итерационная модель основана на концепции IID (Iterative and Incremental Development), включающей принципы итеративности (уточнение и детализация разрабатываемого программного обеспечения шаг за шагом), инкрементальности (увеличение функциональности ПО для каждой итерации) и эволюционности (максимальное использование наработок предыдущих итераций для последующих) [4].

Рис.4. Переход от каскадной и итерационной модели внедрения КИС

Разработка ПО согласно концепции IDD сводится к разбиению этапа реализации на серию быстрых, лёгких и адаптивных итераций, оперативно приносящих результаты. Каждая итерация основана на PDCA-цикле Деминга (Plan-Do-Check-Act) и завершается демонстрацией потребителю полученного промежуточного продукта с целью скорейшего выявления потенциальных ошибок. Более того, в ходе выполнения итераций представление о конечном продукте изменяется, поэтому добавляются новые функциональные возможности. Продолжительность каждой итерации варьируется в пределах 1-6 недель, а начальный список требований к ПО вообще может отсутствовать.

Отметим плюсы итерационной модели:

• оперативная разработка и демонстрация ПО для устранения ошибок;
• допускается отсутствие требований к ПО,

а также минусы:

• отсутствие понимания объёма работ для завершения проекта;
• ориентированность на разработку, но не кастомизацию ПО.

Рассмотрим проект имплементации КИС согласно предлагаемой модели:

• идентификация и анализ требований, предъявляемых к КИС, а также приоритезация найденных требований (опционально);
• определение числа и продолжительности итераций разработки КИС, в случае наличия приоритезированных требований их распределение по итерациям разработки;
• доработка и кастомизация КИС, функциональное и интеграционное тестирование с последующей демонстрацией полученного продукта заказчику для уточнения требований (для всех итераций);
• проведение приёмочного тестирования;
• документирование реализованного программного решения;
• переход к продуктивной эксплуатации и поддержка.

Выполнение итераций подразумевает демонстрацию продукта заказчику, в результате чего выявляются дефекты и идентифицируются новые требования к ПО. Первый минус многопроходной модели формулируется достаточно просто: вновь появляющиеся требования и пожелания клиента могут выйти за временные рамки изначально обсуждённых итераций. Таким образом, необходимо некое мерило требований для отсекания маловажных, что в принципе противоречит самой концепции IID. 

Второй минус выглядит куда более серьёзно: раньше речь шла исключительно о доработке КИС, теперь же непонятно, как быть с кастомизацией и интеграцией. Сначала разберёмся с кастомизацией. Настройке в КИС подлежат уровни данных и бизнес-процессов: организационная структура, процессы, основные и переменные данные. Невозможно выполнить настройку, например, бизнес-процесса в КИС, следуя принципу итеративности. Разумнее всего применить инкрементальный подход: разбить процесс на части и настроить одну часть бизнес-процесса в заданной итерации, а остальные – в следующих. Данный подход применим также к оргструктуре и данным. В итоге получается некий аналог требований: процессы, организационная структура и данные должны быть декомпозированы на объекты и распределены по итерациям. Дальше необходимо понять, полученные объекты включать в начальные или завершающие итерации? Ответ связан с вопросом интеграции.

Интеграцию КИС можно разделить на внутреннюю и внешнюю. Под внутренней интеграцией подразумевается взаимодействие объектов и модулей КИС между собой, например, приход товара на склад должен порождать бухгалтерские проводки. В данном примере присутствуют две сущности различных модулей: приход и проводка, относящиеся к функциональности логистики закупки и финансам соответственно. Второй вид интеграции подразумевает взаимодействие КИС с внешними подсистемами, например, SRM, CRM, WMS и др. Если внутреннюю интеграцию в большей степени можно отнести к кастомизации КИС, то внешнюю – к настройке и доработке. Никакая доработка КИС не может вестись без наличия базовых компонентов системы, которые преимущественно заводятся путём настройки. Тем самым логично в начальные итерации включить кастомизацию КИС и интеграцию, и лишь затем доработку. Поэтому каждая итерация должна включать как функционально-модульное, так и интеграционное тестирование. Суммируя, видится следующая картина реализации итераций:

• начальные итерации должны включать настройку системы и внутреннюю интеграцию по инкрементальному принципу с целью подготовки основополагающего ядра КИС;
• последующие итерации содержат доработки КИС, использующие ранее подготовленные функции КИС путём кастомизации.

Резюмируя вышесказанное, применение итерационной модели вполне логично для доработки КИС, настройка же потребует дополнительных манипуляций. Не смотря на статистику [5], гласящую, что порядка 70% функционала иностранных КИС требуют доработки, пока многопроходная модель применяется в России достаточно редко. Возможно, причина кроется в том, что предпочтение отдаётся максимальному использованию стандартного функционала КИС, то есть кастомизации, против его доработки.

Спиралевидная модель внедрения КИС

Разрешая минус итерационной модели, касающийся отсутствия понимания объёма проекта, в 1986 году Б. Бэмом была предложена спиралевидная модель внедрения КИС (рис. 5). Данная схема сочетает в себе принципы как последовательной, так и многопроходной моделей. Основной акцент спиралевидной модели сделан на обработке 10 наиболее распространённых, по мнению Б. Бэма, рисков, (рис. 6) и оценивании степени готовности ПО [2].

Рис. 5. Переход от итерационной к спиралевидной модели внедрения КИС

Следует отметить, спиралевидную модель нередко рассматривают как частный случай итерационной. Поэтому каждый виток спирали сравним с итерацией одноимённой модели внедрения КИС и характеризуется:

• определением цели и задач;
• обработкой рисков;
• разработкой, настройкой и тестированием ПО;
• оцениванием результатов и планированием следующего витка разработки.

Проект имплементации КИС на основе спиралевидной модели сопоставим с итерационной с той лишь разницей, что каждый виток спирали (в контексте многопроходной модели виток – это итерация) помимо обработки рисков должен включать:

• проверку непревышения сроков и бюджета проекта;
• оценку необходимости выполнения ещё одного витка спирали;
• оценку уровня понимания требований к системе; 
• анализ целесообразности завершения проекта.

Обработка всевозможных параметров проекта (сроки, ресурсы, бюджет, качество, коммуникации и др.), а также оценивание необходимости выполнения следующих витков разработки и завершения проекта требуют значительных трудовых затрат. Именно поэтому применение данной модели целесообразно в больших проектах внедрения КИС. Для небольших проектов или частичного внедрения КИС время, потраченное на обработку и оценивание параметров проекта, будет несопоставимо больше самого процесса разработки системы, что делает применение спиралевидной схемы нецелесообразным.

Рис. 6. Типовые риски спиралевидной модели при внедрении КИС

Заключение

Несмотря на различие в порядке выполнения задач той или иной модели имплементации КИС, их содержание достаточно схоже: анализ требований, проектирование, разработка и тестирование. Если обратить внимание на итерационную и каскадную модели с точки зрения реализации проекта, можно заметить, что они уточняют и дополняют каскадную схему: стадии приёмочного тестирования, внедрения и поддержки в данных схемах идентичны однопроходной модели.

Фактически можно выделить лишь две модели внедрения КИС: однопроходная и многопроходная. Первая схема организована таким образом, что разработчик и функциональный консультант являются лицом принимающим решение по форме, содержанию и особенностям требуемого ПО. Мнение ключевого или конечного пользователя относительно программы поступают настолько поздно, что становится невозможным кардинально изменить уже подготовленный программный продукт. Более того однопроходная модель внедрения жёстко регламентирована с точки зрения документооборота и порядка выполнения работ, в частности согласно PMBoK [6].

Рис. 7. Базовые принципы итерационной и спиралевидной моделей внедрения ПО

Напротив, в многопроходной схеме конечное содержание программного продукта определяется пользователем, но не разработчиком. Если многопроходная схема включает чётко выраженный уровень проекта, отвечающий за управление ресурсами, сроками, рисками и прочими стратами, говорят о спиралевидной модели внедрения КИС, в противном случае – итерационной. Обе схемы базируются на принципах IID, наглядно продемонстрированных на рис.7.

Каскадная и спиралевидная модели преимущественно используются в больших проектах внедрения КИС, требующих тиражирования или внедрения решения «с нуля». Несмотря на наличие очевидных плюсов многопроходной схемы, на практике преимущественно используется однопроходная модель, адаптированная как к разработке, так и кастомизации функционала КИС. Область применения итерационной схемы видится в доработке существующих функциональных возможностей КИС.

Кроме описанных моделей внедрения существует огромное число прочих схем, организованных на основе их базовых принципов. В частности DSDM (Dynamic Systems Development Method - метод разработки динамических систем), XP (eXtreme Programming - экстремальное программирование), Scrum, FDD (Feature Driven Development - разработка, управляемая функциональностью) и другие. Подобные методы объединены в рамках методологии Agile [7], подразумевающей гибкую разработку программ [4]. Последняя является перспективной областью дальнейших исследований авторов.

Литература

1. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – С. 54-62.
2. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
3. Зараменских Е.П. Управление жизненным циклом информационных сисием.- М.: Юрайт, 2017. - 431 с. 
4. Larman C., Basili V.R. Iterative and Incremental Development: A Brief History // Computer. - 2003. – Vol.36, №6. – P.47-56.
5. Левочкина Г., Калянов Г., Васильев Р. Управление развитием информационных систем. – М.: Горячая Линия – Телеком, 2014. – 376 c.
6. Руководство к своду знаний по управлению проектами (Руководство PMBOK). Пятое издание. – М.: Олимп-Бизнес, 2014. – 586 с.
7. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. – 448 c.

Выходные данные статьи

Гудков Е.А., Деревнина А.М., Катасонова Н.С. Анализ каскадной, итерационной      и спиралевидной моделей внедрения корпоративных информационных систем // Корпоративные информационные системы. – 2018. – №1. – C. 18-29. – URL: http://corpinfosys.ru/archive/issue-1/48-2018-1-models.

Об авторах

Гудков Евгений Алексеевич – студент 4-го курса кафедры оптических и биотехнических систем и технологий МТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Применение спиралевидной модели внедрения информационных систем в городской поликлинике». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Деревнина Ангелина Михайловна – студентка 4-го курса кафедры оптических и биотехнических систем и технологий МТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Разработка автоматизированного рабочего места врача-невролога с использованием метода Agile Scrum». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Катасонова Наталья Сергеевна – студентка 4-го курса кафедры оптических и биотехнических систем и технологий МТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Автоматизация ключевых бизнес-процессов городской больницы на основе каскадной модели внедрения». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Содержание выпуска №1

1. Обзор открытой корпоративной информационной системы Odoo;
2. Применение Agile Scrum в проектах SAP;
3. Анализ каскадной, итерационной и спиралевидной моделей внедрения систем;
4. Особенности проекта внедрения MRP по точке перезаказа;
5. Сложности внедрения WMS-систем на примере SAP ERP.