Жизненный цикл (далее – ЖЦ) программного обеспечения (далее – ПО) состоит из ряда этапов, начинающихся стадией зарождения и заканчивающихся прекращением применения (рис. 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% функционала иностранных КИС требуют доработки, пока многопроходная модель применяется в России достаточно редко. Возможно, причина кроется в том, что предпочтение отдаётся максимальному использованию стандартного функционала КИС, то есть кастомизации, против его доработки.
Литературный источник:
Гудков Е.А., Деревнина А.М., Катасонова Н.С. Анализ каскадной, итерационной и спиралевидной моделей внедрения корпоративных информационных систем // Корпоративные информационные системы. – 2018. – №1. – C. 18-29. – URL: http://corpinfosys.ru/archive/issue-1/48-2018-1-models.