Каскадная, итерационная и спиралевидная модели внедрения программного обеспечения, а также метод дизайн-мышления в условиях бизнес-неопределенности

Подробности

Опубликовано: 31.03.2025 10:25

Автор: Степанов Дмитрий Юрьевич

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

Аннотация: в статье рассматривается применение классических моделей внедрения программного обеспечения и метода дизайн-мышления в условиях неопределенности бизнес-требований. Выполняется обзор каскадной, итерационной и спиралевидной моделей, а также их механизмов для работы с плохо сформулированными, изменяющимися и неоднозначными требованиями. Анализируется метод дизайн-мышления, ориентированный на решение инновационных задач при отсутствии видения конечного результата и требований к нему. Уточняется содержание матрицы неопределенности Ральфа Стейси с учетом метода дизайн-мышления. Делается вывод о том, что каскадная и спиралевидная модели подходит для проектов с фиксированными и практически неизменяющимися бизнес-требованиями в отличие от итерационной модели, в то время как дизайн-мышление используется при невозможности формулирования требований к будущему программному продукту.
Ключевые слова: водопадный подход, водопадные проекты, водопадная разработка, итерационный метод разработки, итерационная разработка, итерационный подход к разработке, метод дизайн мышления это, метод design thinking, дизайн мышление процесс, ценность метода дизайн мышления, запрос на изменение, управление запросами на изменение, запрос на изменение в системе, бэклог продукта, управление бэклогом продукта, бэклог спринта это, матрица неопределенности, матрица стейси, техническая неопределенность, бизнес неопределенность.
Скачать: PDF (статья), PDF (выпуск №29).

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

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

Общеизвестные методологии, такие как: ASAP, ADM, MDSS, Agile Scrum, являются лишь прикладными методами указанных моделей. Основное назначение методологии состоит в том, чтобы детально описать алгоритм действий, уточняя и дополняя модель. Поэтому верхнеуровневые шаги методологий схожи между собой, а различие кроется в деталях [2]. Каждая модель имеет свою область применения, в той или иной степени зависящую от предъявляемых к продукту бизнес-требований, а вернее их характеристик. Требования могут быть детально описанными, структурированными, понятными и, наоборот, витиеватыми, двусмысленными, нечеткими. Последнее задает состояние бизнес-неопределенности, когда до конца не понятно, что именно необходимо реализовать.

Последние несколько лет на устах термин и одноименная дисциплина под названием дизайн-мышление, упоминание которого/которой датируется еще 1960 годом [3]. Дизайн-мышление позволяет техническому специалисту мыслить категориями конечного пользователя, для которого разрабатывается будущий продукт. По аналогии с методами решения творческих задач (проб и ошибок, психологической активизации, систематизированного и направленного поисков), данный способ не ограничен какой-либо предметной областью. Правильное использование дизайн-мышления позволяет решать задачи с высоким уровнем неопределенности входных/выходных параметров, наоборот, его применение в типовых инициативах, вероятнее всего, не даст ощутимых выгод. Доступны работы, описывающие применение данного способа в проектах внедрения корпоративных информационных систем [4-6]. Действительно ли это целесообразно, как метод соотносится с классическими схемами внедрения? В этих и прочих вопросах мы попытаемся разобраться в текущей работе.

Цель данной статьи состоит в анализе применимости классических моделей внедрения и метода дизайн-мышления в условиях неопределенности бизнес-требований. Достижение цели потребует решения следующих задач:

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

 1. Каскадная и спиралевидные модели имплементации

Водопадная модель разработки программных решений, пожалуй, является самой распространённой и упоминаемой, так как история работы над софтверными продуктами началась именно с нее [1]. Следуя названию, данная модель подразумевает последовательное выполнение проектных работ, где переход на следующий этап осуществим при условии завершения предыдущей фазы (рис. 1). Современные тенденции внесли свои коррективы, введя гибридные методы разработки программного обеспечения и предложив параллельное выполнение сразу нескольких этапов работ, однако суть модели от этого принципиально не поменялась [7].

Рис. 1. Пример каскадной методологии ADM, используемой для внедрения корпоративных информационных систем

Несмотря на частую критику данной схемы за отсутствие контура обратной связи, что замедляет оперативное решение возникших программных ошибок, каскадная модель хорошо зарекомендовала себя при имплементации комплексных платформенных информационных систем. Успешное применение водопадной модели подразумевает неизменчивость требований к программному продукту в течение его жизненного цикла вплоть до момента продуктивного запуска. Возможные девиации требований разрешаются за счет использования процедуры управления изменения: формируются запросы на изменения, в контексте которых реализуются новые бизнес-потребности за отдельные деньги.

Здесь же стоит рассмотреть спиралевидную модель имплементации, подразумевающую реализацию программного продукта частями [8]. В случае большого числа требований, не всегда возможно сразу доставить программный продукт, для чего выбирают тактику итеративной реализации. Все множество требований приоритизируют и разбивают на волны внедрения. Волны внедрения могут прорабатываться на основе каскадной или итерационной модели, однако в практике имплементации ERP-систем преимущественно применяют водопадную модель, тогда число волн задают от 1 до 3, каждая из которых длится от полугода до 1,5 лет. Изначально предполагалось, что спиралевидная модель устраняет недостатки всех прочих моделей внедрения (отсутствие контура обратной связи, неопределенности в остановке цикла разработок, сложности в прогнозировании стоимости, трудозатрат и стоимости и др.), однако ее использование в ERP-проектах упрощается и фактически сводится к многократному выполнению проекта на основе каскадной схемы. В рамках данной модели работа над требованиями к ERP-системе ведется аналогично каскадной схеме:

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

Наглядным примером данной модели имплементации служит методология 1С: ТКВ (Технология корпоративного внедрения), этапы проектных работ которой даны на рисунке ниже (рис .2).

Рис. 2. Спиралевидная методология 1С: ТКВ для имплементации ERP-систем

 2. Итерационная модель

Итерационная модель внедрения задумывалась как улучшение каскадной схемы [9]. Принимая во внимание минусы последней, о которых сказано выше, предлагалось их устранить за счет реализации программного продукта путем одинаковых по продолжительности итераций разработки (обычно 1-4 недели), каждая из которых доставляла бы часть работоспособного решения. Ожидалось, что получение ранней версии продукта, позволит получить быструю обратную связь от пользователей и оперативно устранить дефекты. Данная модель тесно связана с манифестом Agile [10], содержащем 12 ключевых принципов. Почувствуйте принципиальное отличие итерационной модели от водопадной, следуя части ее заявленных принципов:

• ранняя поставка продукта;
• регулярные проставки;
• изменения приветствуются.

Несмотря на очевидные преимущества, рассматриваемая схема также имела и недостатки: неясные критерии остановки, а также сложности прогнозирования параметров проекта, которые были решены уже в спиралевидной модели внедрения.

С точки зрения применимости, итерационная съема хорошо себя зарекомендовала в проектах разработки программных продуктов «с нуля». Проекты же имплементации коробочных софтверных решений, схожих по сложности с классом ERP, используют данный подход крайне редко по причине необходимости трансформации и переучивания всей проектной команды. Стоит отметить, что минимальное изменение структуры проектной команды позволяет применять данную схему в проектах развития уже внедренных корпоративных информационных систем. Наиболее популярной методологией на основе итерационной схемы является Agile Scrum, о которой не слышал разве что ленивый (рис. 3).

Рис. 3. Концептуальная схема реализации проекта на основе Agile Scrum

Обращаясь к вопросу неопределенности в требованиях, необходимо заметить, что итерационная модель как раз ориентирована на решение подобных задач. Ее особенность состоит в том, что весь пул требований образует беклог продукта, который в дальнейшем разделяется на беклоги итераций, содержащие выбранную и подтвержденную к разработке часть из первого. На каждой итерации выполняется проработка требований из соответствующего беклога итерации, при этом состав потребностей последующей может меняться: добавляться новые и изменяться/замещаться ранее определенные. Поэтому одной из предпосылок применения данной схемы внедрения в литературных источниках часто упоминается как раз изменчивость требований.

 3. Метод дизайн-мышления

Метод дизайн-мышления прошел долгий путь от понимания дизайна как науки до формализации его в образ мышления [3]. Существует множество определений данного метода, наиболее подходящим из которых является следующее. Дизайн-мышление – это образ мышления, культура и процесс создания продуктов, услуг и бизнес-моделей, основанный на итеративном проектировании и обширных исследованиях, ориентированных на пользователя. Обобщая, можно сказать, что это один из способов решения творческих, сложных и инновационных задач. Поэтому разрешение рутинных противоречий, предполагающих применение известных методов по определению не релевантно применению данного метода.

Рис. 4. Типовые этапы работ метода дизайн-мышления

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

Если итеративные методы разработки программного обеспечения позволяют реализовывать проекты в условиях частого изменения требований, то дизайн-мышление в ИТ-проектах идет еще дальше: обеспечивает работу в условиях отсутствия требований, а итогом его использования может служить формализация требований.

 4. Использование моделей и методов в условиях неопределенности

Наиболее полно ситуация неопределенности демонстрируется в матрице Ральфа Стейси, вводящей два ее вида [11]. Применительно к проектам разработки и внедрения программного обеспечения это бизнес и технологические неопределенности. Бизнес неопределенность задает ситуацию плохо проработанных требований к программному продукту: нечеткое формулирование, не структурированность, разночтение, противотечения, затрудняющие понимание того, что конкретно должно быть реализовано. Технологическая неопределенность описывает степень непонимания того, как технически должна быть реализована программная разработка.

Различный уровень указанных неопределенностей задает содержание матрицы Стейси (рис. 5), предлагающей наиболее подходящую модель внедрения. Так каскадная/спиралевидная модель используется в условиях низких бизнес и технологической неопределенностей, во всех остальных – итерационная [12]. Содержание матрицы подтверждает исходные утверждения: каскадные схемы работают с четко определенными и неизменчивыми требованиями в отличие от итерационных. Конечно, в водопадной модели допускается разумная степень неопределенности, для чего предусмотрен процесс обработки запросов на изменения, однако это больше вынужденная и исключительная мера. Если в ходе проекта возникаем множество подобных запросов на изменение, вероятнее всего, выбрана нерелевантная модель внедрения.

Рис. 5. Матрица Ральфа Стейси для бизнес и технологической неопределенностей

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

Рис. 6. Матрица Ральфа Стейси и метод дизайн-мышления

Как видно из рисунка, метод дизайн-мышления смещает границы применения итерационной модели внедрения, занимая область абсолютной неопределенности в бизнес и технологических требованиях.

5. Применение моделей и методов в ERP-проектах

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

Табл. 1. Особенности использования моделей внедрения и метода дизайн-мышления в условиях бизнес-неопределенности

Необходимо отметить, что использование наиболее релевантного метода сокращает трудозатраты, время и стоимость усилий. В случае известных требований к продукту применимы каскадная и спиралевидные схемы внедрения, однако, если потребности слабо формализуемы, допускают высокую степень изменчивости и обязуют быстрое получение результата, подойдет итерационная модель. Если же требования неизвестны и отсутствует понимание того, какие результаты должны быть достигнуты, применим метод дизайн-мышления.

Следуя работе [13], жизненный цикл программного продукта представляется спиралью и содержит три вида подпроектов: предпроектное обследование, известное как бизнес-кейс, проект имплементации и проект пост-внедрения. Используя рис. 6 и данные табл. 1, выходит, что:

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

Заключение

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

Литература

1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
2. Олейник П.П. Корпоративные информационные системы: учебник для вузов. – СПб.: Питер, 2012. – 175 с.
3. Кемпкенс О. Дизайн-мышление. Все инструменты в одной книге. – М.: Издательство Эксмо, 2023. – 317 с.
4. Солдатов С.А. Дизайн-мышление – вовлечение пользователей при разработке продуктов // Корпоративные информационные системы. – 2019. – №1(5). – с. 1-6. – URL: https://corpinfosys.ru/archive/issue-5/71-2019-5-designthinking.
5. Юмашева А.О. Дизайн-мышление в проектах внедрения информационных систем (часть 1) // Корпоративные информационные системы. – 2020. – №3(11). – с. 38-48. – URL: https://corpinfosys.ru/archive/issue-11/101-2020-11-designthinkingis.
6. Юмашева А.О. Дизайн-мышление в проектах внедрения информационных систем (часть 2) // Корпоративные информационные системы. – 2020. – №4(12). – с. 38-51. – URL: https://corpinfosys.ru/archive/issue-12/102-2020-12-designthinkingis.
7. Кудин Н.С. Гибридные методы внедрения корпоративных ERP-систем // Корпоративные информационные системы. – 2022. – №3 (19) – с. 29-37. – URL: https://corpinfosys.ru/archive/issue-19/202-2022-19-erphybridmethods.
8. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
9. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
10. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. – 448 c.
11. Schwaber K., Beedle M. Agile software development with scrum. Pearson, 2001. – 176 p.
12. Степанов Д.Ю. Бизнес и технологическая неопределенности в проектах имплементации корпоративных информационных систем на основе каскадной и многопроходных моделей внедрения // Высокопроизводительные вычислительные системы и технологии. – 2021. – №2 (66). – c.118-128. – URL: http://stepanovd.com/science/article/110-2021-2-uncertanties.
13. Stepanov D.Yu. The lifecycle of corporate information systems // Proceedings of 6th International Conference on Control Systems, Mathematical Modeling, Automation and Energy Efficiency. – 2024. – p.593-597. – URL: https://stepanovd.com/science/article/197-2024-4-thelifecyclecis.

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

Степанов Д.Ю. Каскадная, итерационная и спиралевидная модели внедрения программного обеспечения, а также метод дизайн-мышления в условиях бизнес-неопределенности. – 2025. – №1 (29) – c. 11-15. – URL: https://corpinfosys.ru/archive/2025/issue-29/296-2025-29-implementationmodelsdesignthinking.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №29

1. Модели внедрения ПО и дизайн-мышление при бизнес-неопределенности;
2. О налогообложении расходов на покупку российского ПО и баз данных;
3. Low-code платформы и приложения.