Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:
каскадная/водопадная;
итерационная;
спиралевидная,
Общеизвестные методологии, такие как: ASAP, ADM, MDSS, Agile Scrum, являются лишь прикладными методами указанных моделей. Основное назначение методологии состоит в том, чтобы детально описать алгоритм действий, уточняя и дополняя модель. Поэтому верхнеуровневые шаги методологий схожи между собой, а различие кроется в деталях [2]. Каждая модель имеет свою область применения, в той или иной степени зависящую от предъявляемых к продукту бизнес-требований, а вернее их характеристик. Требования могут быть детально описанными, структурированными, понятными и, наоборот, витиеватыми, двусмысленными, нечеткими. Последнее задает состояние бизнес-неопределенности, когда до конца не понятно, что именно необходимо реализовать.
Последние несколько лет на устах термин и одноименная дисциплина под названием дизайн-мышление, упоминание которого/которой датируется еще 1960 годом [3]. Дизайн-мышление позволяет техническому специалисту мыслить категориями конечного пользователя, для которого разрабатывается будущий продукт. По аналогии с методами решения творческих задач (проб и ошибок, психологической активизации, систематизированного и направленного поисков), данный способ не ограничен какой-либо предметной областью. Правильное использование дизайн-мышления позволяет решать задачи с высоким уровнем неопределенности входных/выходных параметров, наоборот, его применение в типовых инициативах, вероятнее всего, не даст ощутимых выгод. Доступны работы, описывающие применение данного способа в проектах внедрения корпоративных информационных систем [4-6]. Действительно ли это целесообразно, как метод соотносится с классическими схемами внедрения? В этих и прочих вопросах мы попытаемся разобраться в текущей работе.
Цель данной статьи состоит в анализе применимости классических моделей внедрения и метода дизайн-мышления в условиях неопределенности бизнес-требований. Достижение цели потребует решения следующих задач:
обзор каскадной, итерационной и спиралевидной моделей имплементации п��ограммных продуктов;
анализ метода дизайн-мышления;
рассмотрение ситуации бизнес-неопределенности и использования в ней указанных выше моделей и методов;
уточнение области применения классических моделей внедрения и дизайн-мышления в проектах имплементации ERP-систем.
1. Каскадная и спиралевидные модели имплементации
Водопадная модель разработки программных решений, пожалуй, является самой распространённой и упоминаемой, так как история работы над софтверными продуктами началась именно с нее [1]. Следуя названию, данная модель подразумевает последовательное выполнение проектных работ, где переход на следующий этап осуществим при условии завершения предыдущей фазы (рис. 1). Современные тенденции внесли свои коррективы, введя гибридные методы разработки программного обеспечения и предложив параллельное выполнение сразу нескольких этапов работ, однако суть модели от этого принципиально не поменялась [7].
Несмотря на частую критику данной схемы за отсутствие контура обратной связи, что замедляет оперативное решение возникших программных ошибок, каскадная модель хорошо зарекомендовала себя при имплементации комплексных платформенных информационных систем. Успешное применение водопадной модели подразумевает неизменчивость требований к программному продукту в течение его жизненного цикла вплоть до момента продуктивного запуска. Возможные девиации требований разрешаются за счет использования процедуры управления изменения: формируются запросы на изменения, в контексте которых реализуются новые бизнес-потребности за отдельные деньги.
Здесь же стоит рассмотреть спиралевидную модель имплементации, подразумевающую реализацию программного продукта частями [8]. В случае большого числа требований, не всегда возможно сразу доставить программный продукт, для чего выбирают тактику итеративной реализации. Все множество требований приоритизируют и разбивают на волны внедрения. Волны внедрения могут прорабатываться на основе каскадной или итерационной модели, однако в практике имплементации ERP-систем преимущественно применяют водопадную модель, тогда число волн задают от 1 до 3, каждая из которых длится от полугода до 1,5 лет. Изначально предполагалось, что спиралевидная модель устраняет недостатки всех прочих моделей внедрения (отсутствие контура обратной связи, неопределенности в остановке цикла разработок, сложности в прогнозировании стоимости, трудозатрат и стоимости и др.), однако ее использование в ERP-проектах упрощается и фактически сводится к многократному выполнению проекта на основе каскадной схемы. В рамках данной модели работа над требованиями к ERP-системе ведется аналогично каскадной схеме:
ведется реест�� требований, содержащий приоритизированные потребности;
требования распределяются по волнам внедрения;
по итогам выполнения волны внедрения, состав и содержание существующих требований может меняться;
в случае, если в ходе реализации волны появляются срочные новые требования, применяется механизм запросов на изменение.
Наглядным примером данной модели имплементации служит методология 1С: ТКВ (Технология корпоративного внедрения), этапы проектных работ которой даны на рисунке ниже (рис .2).
2. Итерационная модель
Итерационная модель внедрения задумывалась как улучшение каскадной схемы [9]. Принимая во внимание минусы последней, о которых сказано выше, предлагалось их устранить за счет реализации программного продукта путем одинаковых по продолжительности итераций разработки (обычно 1-4 недели), каждая из которых доставляла бы часть работоспособного решения. Ожидалось, что получение ранней версии продукта, позволит получить быструю обратную связь от пользователей и оперативно устранить дефекты. Данная модель тесно связана с манифестом Agile [10], содержащем 12 ключевых принципов. Почувствуйте принципиальное отличие итерационной модели от водопадной, следуя части ее заявленных принципов:
ранняя поставка продукта;
регулярные проставки;
изменения приветствуются.
Несмотря на очевидные преимущества, рассматриваемая схема также имела и недостатки: неясные критерии остановки, а также сложности прогнозирования параметров проекта, которые были решены уже в спиралевидной модели внедрения.
С точки зрения применимости, итерационная съема хорошо себя зарекомендовала в проектах разработки программных продуктов «с нуля». Проекты же имплементации коробочных софтверных решений, схожих по сложности с классом ERP, используют данный подход крайне редко по причине необходимости трансформации и переучивания всей проектной команды. Стоит отметить, что минимальное изменение структуры проектной команды позволяет применять данную схему в проектах развития уже внедренных корпоративных информационных систем. Наиболее популярной методологией на основе итерационной схемы является Agile Scrum, о которой не слышал разве что ленивый (рис. 3).
Обращаясь к вопросу неопределенности в требованиях, необходимо заметить, что итерационная модель как раз ориентирована на решение подобных задач. Ее особенность состоит в том, что весь пул требований образует беклог продукта, который в дальнейшем разделяется на беклоги итераций, содержащие выбранную и подтвержденную к разработке часть из первого. На каждой итерации выполняется проработка требований из соответствующего беклога итерации, при этом состав потребностей последующей может меняться: добавляться новые и изменяться/замещаться ранее определенные. Поэтому одной из предпосылок применения данной схемы внедрения в литературных источниках часто упоминается как раз изменчивость требований.
3. Метод дизайн-мышления
Метод дизайн-мышления прошел долгий путь от понимания дизайна как науки до формализации его в образ мышления [3]. Существует множество определений данного метода, наиболее подходящим из которых является следующее. Дизайн-мышление – это образ мышления, культура и процесс создания продуктов, услуг и бизнес-моделей, основанный на итеративном проектировании и обширных исследованиях, ориентированных на пользователя. Обобщая, можно сказать, что это один из способов решения творческих, сложных и инновационных задач. Поэтому разрешение рутинных противоречий, предполагающих применение известных методов по определению не релевантно применению данного метода.
Обратимся к этапам работ, составляющих основу метода дизайн-мышления (рис. 4), здесь можно увидеть, что детальный анализ проблемы и всевозможные исследования подобных задач и способов их решения являются ключевой частью метода. Следующим важным пунктом является то, что по итогам применения метода создается не конечный продукт, а выполняется подтверждение гипотез о продукте/идеи за счет формирования прототипов и/или их пилотирования.
Если итеративные методы разработки программного обеспечения позволяют реализовывать проекты в условиях частого изменения требований, то дизайн-мышление в ИТ-проектах идет еще дальше: обеспечивает работу в условиях отсутствия требований, а итогом его использования может служить формализация требований.
4. Использование моделей и методов в условиях неопределенности
Наиболее полно ситуация неопределенности демонстрируется в матрице Ральфа Стейси, вводящей два ее вида [11]. Применительно к проектам разработки и внедрения программного обеспечения это бизнес и технологические неопределенности. Бизнес неопределенность задает ситуацию плохо проработанных требований к программному продукту: нечеткое формулирование, не структурированность, разночтение, противотечения, затрудняющие понимание того, что конкретно должно быть реализовано. Технологическая неопределенность описывает степень непонимания того, как технически должна быть реализована программная разработка.
Различный уровень указанных неопределенностей задает содержание матрицы Стейси (рис. 5), предлагающей наиболее подходящую модель внедрения. Так каскадная/спиралевидная модель используется в условиях низких бизнес и технологической неопределенностей, во всех остальных – итерационная [12]. Содержание матрицы подтверждает исходные утверждения: каскадные схемы работают с четко определенными и неизменчивыми требованиями в отличие от итерационных. Конечно, в водопадной модели допускается разумная степень неопределенности, для чего предусмотрен процесс обработки запросов на изменения, однако это больше вынужденная и исключительная мера. Если в ходе проекта возникаем множество подобных запросов на изменение, вероятнее всего, выбрана нерелевантная модель внедрения ...
Литературный источник
Степанов Д.Ю. Каскадная, итерационная и спиралевидная модели внедрения программного обеспечения, а также метод дизайн-мышления в условиях бизнес-неопределенности. – 2025. – №1 (29) – c. 11-15. – URL: https://corpinfosys.ru/archive/2025/issue-29/296-2025-29-implementationmodelsdesignthinking.
