CC BY
2
ОБЗОР
ОС1: 10.21045/1811-0185-2024-12-77-89 УДК 614.2
СОЗДАНИЕ ПРОТОТИПОВ ПРОЦЕССОВ -ПРОДУКТ ФОРМАЛЬНОГО ЦИФРОВОГО ВЫРАЖЕНИЯ ТРЕБОВАНИЙ ДЛЯ СНИЖЕНИЯ РАЗРЫВА ОЖИДАНИЙ МЕЖДУ ПОЛЬЗОВАТЕЛЯМИ ПРОЕКТА В ЗДРАВООХРАНЕНИИ
А. В. Ахохова а: , М.Х. Тлакадугова ь, И.Х. Альмовас, З.Х. Нахушева Д.А. Шукурова е, Л.Д. Карданова К.Д. Джанкулаева д, А.Л. Бетуганова ь, З.А. Ульбашева М.М. Хавжокова А. И. Желдашева к
а Общество с ограниченной ответственностью Фирма «СЭМ», КБР, г. Нальчик, Россия;
ь с, d, в, ^ g, h, ^ ¡, к фгбОУ ВО «Кабардино-Балкарский государственный университет имени Х.М. Бербекова» Минобрнауки России, г. Нальчик, Россия. а https://orcid.org/0000-0003-2370-9701
с https://orcid.org/0009-0006-7051-2935 е https://orcid.org/0009-0003-3590-6961 g https://orcid.org/0009-0001-7415-8666 i https://orcid.org/0009-0002-8850-6948; k https://orcid.org/0009-0001-3138-7055.
b https://orcid.org/0000-0003-1329-6085; d https://orcid.org/0009-0008-9333-2755; f https://orcid.org/0000-0003-1570-2497; h https://orcid.org/0000-0002-5228-870X; j https://orcid.org/0009-0002-7400-2749;
И Автор для корреспонденции: Ахохова А.В.
АННОТАЦИЯ
Возрастающая трудоемкость эксплуатации и обеспечения технических систем в отрасли здравоохранения привели к необходимости решения задач, связанных с форсированием разработки, и повышению зрелости дизайна проекта. Риски возникновения упущенных возможностей и высокая вероятность непредсказуемости результатов потенциально влияют на стоимость и успех проектов, реализуемых в данной сфере. Это инициирует интеграцию новых методологий и инструментов, ориентированных на цифровизацию дизайна проекта. Поэтому методы формализации и процессы документирования требований прототипов процессов проекта являются ключом к управлению их поведением.
Целью настоящего исследования стала аргументация необходимости интеграции существующих процессов в цифровой формат в виде прототипов для извлечения максимальной выгоды и оптимально удобного использования. В настоящее время работы по разработке формальных требований выполняются вручную, на основе документов, без четкой структуризации и систематизации, носят по-прежнему текстовые форматы и выражаются естественным языком. Фреймворки моделирования предоставляют возможность импортировать требования и связывать их с элементами будущего прототипа модели проекта. Материалы и методы. Теоретическим обоснованием литературного обзора стали научные труды российских и зарубежных исследователей, посвященные изучению стейкхолдерского подхода, включающего теорию ресурсной зависимости, разработка интегрированных цифровых требований и реинжиниринг.
Результаты. Сбор, документирование, просмотр и управление требованиями проекта являются важными составляющими использования (планирования) ресурсов в отрасли здравоохранения: время, инвестиции и качество предоставляемых медицинских услуг. Соответственно применение полученных прототипов процессов проекта на протяжение его жизненного цикла является ценным инструментом проверки и совершенствования механизмов оптимизации (формализации) данных требований. Выводы. Разработка интегрированных решений в существующие рабочие процессы проекта устраняет потенциальную возможность внесения ошибок вручную и обеспечивает непрерывную цифровую работу, максимальную выгоду и оптимальное удобство использования. Таким образом, это обеспечивает мощный способ ранней, простой и интуитивно понятной проверки полученного в результате представления потребностей заинтересованных сторон продукта.
Ключевые слова: методы формализации требований, цифровизация, реинжиниринг, фреймворки моделирования, проекты здравоохранения, интегрированные цифровые требования
Для цитирования: Ахохова А.В., Тлакадугова М.Х., Альмова И.Х., Нахушева З.Х., Шукурова Д.А., Карданова Л.Д., Джанкулаева К.Д., Бетуганова А.Л., Ульбашева З.А., Хавжокова М.М., Желдашева А.И. Создание прототипов процессов - продукт формального цифрового выражения требований для снижения разрыва ожиданий между пользователями проекта в здравоохранении. Менеджер здравоохранения. 2024; 12:77-89. DOI: 10.21045/1811-0185-2024-12-77-89
© Ахохова А.В., Тлакадугова М.Х., Альмова И.Х., Нахушева З.Х., Шукурова Д.А., Карданова Л.Д., Джанкулаева К.Д., Бетуганова А.Л., Ульбашева З.А., Хавжокова М.М., Желдашева А.И. , 2024 г.
№12 Manager
2024 Zdravoochranenie ,
Введение
Формирование управленческого механизма и нахождение инструментов, для взаимодействия и выстраивания эффективных отношений между потребителями и исполнителями проекта остается актуальным вопросом. Как отмечают некоторые исследователи [1], существует противоречие, при котором важность стейкхолдер-ского подхода востребована, но отсутствуют методологические и практические рекомендации его использования [2].
«Ключевой остается проблема рассогласованности целей участников взаимодействия медицинских организаций: выгоды для одних акторов часто являются издержками и снижением производительности для других...» [2].
Проблема исследования и определения требований пользователей (потребителей и исполнителей проекта), отсутствие комплексной методологической основы, унифицированного перечня потребностей, включающих достижения стейкхол-дерского подхода, фрагментарность их оценки, требует изучения данного вопроса.
Целью настоящего исследования стала аргументация необходимости интеграции существующих процессов в цифровой формат в виде прототипов для извлечения максимальной выгоды и оптимально удобного использования. В настоящее время работы по разработке формальных требований выполняются вручную, на основе документов, без четкой структуризации и систематизации, носят по-прежнему текстовые форматы и выражаются естественным языком. Фреймворки моделирования предоставляют возможность импортировать требования и связывать их с элементами будущего прототипа модели проекта.
Материалы и методы
Теоретическим обоснованием обзора стали научные труды российских и зарубежных исследователей, посвященные изучению стейкхолдерского подхода, включающего теорию ресурсной зависимости, разработке интегрированных цифровых требований и реинжиниринга.
Проанализировано более 20 источников литературы, за период с 2009 года по настоящее время. Информационно-справочной и методической основой для изучения исследовательского вопроса стали нормативные правовые акты органов управления здравоохранения субъектов и РФ, размещенные
в кроссплатформенной справочной правовой системе, Консультант плюс, разработанной в России, электронные базы данных.
Методами исследования явились: системный анализ, сравнение, системный и комплексный подходы, а также метод проблемного моделирования. При оформлении статьи использованы обзоры и публикации многообразных авторских источников, нетрадиционных творческих работ по конструированию объектов посредством математического абстрактного проектирования и реинжиниринга.
Требования со стороны пациента (потребителя медицинских услуг)
Применение системного подхода в разработке прототипа проекта должно начинаться с получения достоверных требований к нему. Команда проектантов, участвующих в реализации проектов обязана в первую очередь понять требования получателя медицинских услуг (пациента) и определить собственные.
Задачами в рамках исследовательского вопроса стали описание требований команды проекта и пациентов, разделение их на проблемы разработки и управления, дальнейшая интерпретация и определение влияния на проект.
Особенностью проблем установления требования проекта является тот факт, что с одной стороны исполнитель(и) проекта (медицинские работники, руководитель медицинской организации, уполномоченные лица) могут не учитывать (не знать) всех требований пользователей в силу разных причин.
С другой стороны, пользователи в лице пациентов, описывая проблемы в рамках проекта, не способны компетентно перечислить функциональные требования для разработки и получения необходимых возможностей.
Поэтому критичность достижения соглашения о наборе требований, которые запланированы на определённый этап или итерацию разработки проекта между пользователями проекта, несомненна. Для проведения аналитической проработки, по мнению автора [3], необходимо выделить три основные составляющие для формирования требований проекта с уточнением: различий в ожиданиях, идентификации потребителей проекта, порядка взаимодействия исполнителя и потребителя медицинских услуг (пациента).
Различия в ожиданиях могут быть связаны с отсутствием контакта между исполнителями и потребителями медицинских услуг в рамках проекта
Менеджер / Мепедег №12
здравоохранения / 2с^гв\/аас:Ьгвпап'1в 2024
и невозможности оценки отклика пациента. Многими авторами [4, 5] проведены исследования для идентификации требований путем анкетирования потребителей услуг, рассмотрения обращений граждан, очных тестирований, с целью обнаружения дефектов оформления первичной медицинской документации, качества медицинских услуг, их анализ. Вместе с тем, отсутствие методологической базы и практических рекомендаций ее использования делает невозможным формирование управленческого аппарата, его применение в системе взаимодействия и выстраивания эффективных отношений конкретных организаций.
Каждый контакт с потребителем услуг направлен на сокращение неопределенностей реализации проекта путем адекватного реагирования и расширения функциональности исполняемого проекта, с учетом внесения новых данных в рабочий прототип его исполнителями (рис. 1).
Точки взаимодействия потребителя услуг и исполнителя проекта уменьшают разрыв ожиданий. Соответственно, чем больше контактов будет происходить в рамках реализации проекта, тем выше оцениваются и учитываются потребности потребителя. На рис. 1 видно, что после каждого взаимодействия с потребителем услуг, разрыв увеличивается, так как появляются новые требования, но к концу реализации проекта обнаруживается минимальное значение разницы в ожиданиях.
Использование гибких методологий (АдУе-методы) и подходов к разработке проектов, основанных на
конкретных принципах [6], ведут к минимизации рисков путем использования коротких итераций, что позволяет проводить систематический анализ требований необходимых для наращивания функциональности проекта. «.Итеративный подход позволяет легко тестировать качество работ на любом из этапов реализации проекта и производить настройку, используя новые элементы, переменные на небольших итерациях, что в свою очередь свидетельствует об организационной зрелости и стабильности» [7]. Необходимо отметить, что в проектах с гибкой методологией разработки невозможно получить одобрение потребителя сразу на полный перечень требований, он определяется с течением времени.
Авторами [7] ранее проведена оценка фундаментальной роли итеративных процессов при создании рабочего прототипа в медицинских организациях, реализующих проекты. По результату сделаны выводы, что выявление ритма или цикла итерации системы с обратной связью является главным шагом к пониманию эволюции изменений и появлению упорядоченной сложности. Итерационный подход решает вопросы одномерного способа организации, построенного на основе конструктивно обусловленных операций, сегментации и иерархической координации функции медицинской организации в пользу многомерной взаимозависимой структуры отрасли.
Основные принципы при формировании требований по результатам взаимодействия потребителя медицинских услуг и исполнителя представлены в таблице 1.
Рис. 1. Регулярное взаимодействие потребителя медицинских услуг и исполнителя проекта сокращает разрыв ожиданий
Таблица
Формализация требований для создания прототипа рабочего проекта на основе принципов взаимодействия потребителя медицинских услуг и исполнителя проекта
1
Наименование принципа [8, 9] Потребитель (заказчик) Исполнитель (команда проектантов)
Ранняя и бесперебойная поставка ценного программного обеспечения и работающее программное обеспечение (измеритель прогресса)
Изменение требований по результатам итераций в ходе реализации проекта, их регистрация, внесение изменений в план реализации проекта +
Совершенствование программного обеспечения с учетом новых изменений в содержании проекта определенных требованиями потребителей для гибкого + проектирования
Постоянная коммуникация исполнителя проекта с потребителями услуг на протяжении всего жизненного цикла проекта +
Создание условий для заинтересованных исполнителей проекта с целью возможности поддержания постоянного темпа на неопределённый срок + (спонсоры, заказчики, разработчики, исполнители)
Простота процессов проекта для всех заинтересованных сторон +
Оптимизация требований, архитектуры и проектных решений у самоорганизующихся команд для корректировки рабочих процессов
Интеграция формального цифрового выражения требований в виде прототипа в существующие рабочие процессы +
Как следует из таблицы 1 единственным условием, необходимым для формирования актуальных требований проекта в отношение потребителя услуг, является непосредственное систематическое общение с ним исполнителя и создание последними четких спецификаций потребностей пациента.
Заинтересованные лица (стейкхолдеры проекта) -группа или организации, активно участвующие в проекте и оказывающие прямое или опосредованное влияние на его процессы или результаты [10] (рис. 2.)
Анализ заинтересованных лиц, один из главных этапов разработки требований (Smith, 2000; Wiegers,
За пределами разрабатывающей и обеспечивающей команд:
Прямой пользователь (пациент)
Непрямой пользователь
Подрядчики (субподрядчики)
Поставщики
Регулирующие органы
Покупатель
Эксперт предметной области
Разрабатывающая организация на уровне региона
(органы управления здравоохранеши субъекта):
Руководитель проекта
Структурные подразделения
Службы поддержки
Обеспечивающие службы
Обеспечивающая организация проекта
МО (команда проекта):
Руководитель проекта (главный врач,
заместители)
Медпцннскне работники
Вспомогательный персонал
Рис. 2. Стейкхолдеры проекта (внутренние и внешние)
Менеджер / Meneger №12
здравоохранения / Zdravoochranania 2024 а
2007; 11ВА, 2009). Перечень возможных заинтересованных лиц с определением зон их участия в проекте (рис. 2) необходим для идентификации всех требований и ограничений проекта.
Пациент (конечный потребитель) является подмножеством заинтересованных лиц. «В итоге потребитель услуг - это заинтересованное лицо в проекте, запрашивающее, оплачивающее, выбирающее, определяющее, использующее и получающее результаты работы проекта.» [11]. С одной стороны, обсуждение проблем с требованиями со всеми стейк-холдерами проекта, с формированием и ведением реестра по текущим и предыдущим этапам проекта, их влияние, а также использование единой лексики при проведении тренингов в целях понимания общих приемов и поведения является одной из ключевых задач исследования.
С другой стороны, сосредоточение на «технических» требованиях, которые формализуют потребности, ожидания и ограничения, связанные с эксплуатацией конечного продукта: ожидаемое поведение, ожидаемая производительность, цели устойчивости и связанные с ними технические ограничения являются решающими факторами для оптимизации рабочих процессов [12].
Формализация требований для интеграции в существующие рабочие процессы посредством прототипов (формального цифрового выражения требований) обеспечивают непрерывную цифровую работу, максимальную выгоду от деятельности и оптимальное удобство использования [13].
Приемы формулирования требований для потребителей проекта
(таблица 2) должны основываться на общении с пользователями проекта, оформлении ясной спецификации на основе полученной информации и системных итерациях.
Итеративный процесс формулирования требований проекта будет продолжаться на протяжение всего жизненного цикла, поэтому разработка требований (выявление, анализ, документирование и тестирование) должна происходить поэтапно и циклично. Точное понимание концепции дает адекватную основу для оценки проектных требований, потому основные принципы проекта должны сохраняться от аналога к аналогу условно стабильными.
Вместе с тем, после пересмотра требований проекта (новая версия) необходимо формировать новый отдельный документ с корректированными границами проекта [11].
Неуклонное поступательное (итеративное) уточнение требований проекта, начиная с актуализации информации до более детального понимания и формирования требований на последующих этапах является главным условием процессов формулирования условий и нахождения прототипов процессов (рис. 3).
На рис. 3 представлена основная структура итераций по созданию требований. Результаты этапа выявления требований, интервьюирование пациентов (потребителей услуг) и наблюдение за ними, дают возможность классифицировать информацию и разнести ее на определенные категории с учетом вновь установленных потребностей, что определяет новые проектные требования (аналитический этап).
Необходимость уточнения данных требований ведет к возвращению и внесению дополнений в прежний перечень требований. Следующим этапом (рис. 3) становится структурирование информации от потребителей услуг, с последующим оформлением и утверждением письменных требований (оформление спецификации). Для этого предварительно необходимо заручиться поддержкой экспертов, возможно проанализировать вновь появившуюся информацию и исправить ошибки (этап проверки/тестирования).
Рис. 3. Основная структура итеративного процесса формулирования требований
для пользователей проекта
Таблица 2
Процессы формулирования требований для пользователей проекта
(нулевое приближение)
Обзор (анализ)
Спецификации
Тестирование
■ моделирование среды проекта / формирование прототипов
■ оценивание прогностической осуществимости
■ расстановка очередности для требований стейкхолдеров
■ формирование терминологического аппарата данных
■ моделирование требований
■ распределение требования по приоритетности и группам стейкхолдеров
■ использование стандартизованных образцов спецификаций требований
■ определение поставщиков требований
■ уникальная идентификация каждого требования
■ документирование и регистрация результатов правил проекта
■ определение ключевых характеристик, определяющих уровень качества процессов проекта (атрибуты)
■ изучение документов с требованиями
■ тестирование требований
■ определение критериев оптимальности (достаточности)
■ моделирование требований
Регулирование требованиями
■ установление процессов управления изменениями в проекте
■ аналитический обзор влияния изменений проекта
■ определение базовой и окончательной версии спектра требований
■ отслеживание хронологии изменений
■ наблюдение за состоянием требований
■ контроль за проблемами с требованиями
■ формирование матрицы связей требований
■ использование средств управления требованиями
Тренинги
■ обучение специалистов для анализа требований
■ ознакомление пользователей и менеджеров проекта с требованиями
■ подготовка разработчиков продукта базовым составляющим предметной области
■ установление процессов разработки требований
■ формирование терминологического словаря
Управление проектом
■ отбор соответствующего цикла разработки проекта
■ планирование методов работы с требованиями
■ оценивание объема работ по реализации требований
■ планирование мероприятий на основании требований
■ определение лиц, ответственных за принятие решений по т
■ своевременный пересмотр обязательств по проекту
■ управление рисками, связанных с требованиями
■ контроль исполнения объема работ по реализации требований
■ подведение итогов полученного опыта
Итерация 2
Итерация 3
Итерация N
Менеджер / Мепедег №12
здравоохранения / 2с^гв\/аас:Ьгвпеп'1а 2024
Далее приступить к следующему этапу проекта, для очередной итерации цикла [14, 15].
Этап «Аккумулирование информации от потребителей проекта» (таблица 2) осуществляется в основном на предпроектной стадии работы над проектом (вместе с тем, команде проектантов необходимо периодически проводить проверку и актуализацию). Другие этапы могут выполняться итеративно и попеременно со следующим/обновленным перечнем требований, который станет основой для следующего цикла итерации.
Процессы формулирования требований для пользователей проекта можно декомпозировать на отдельные процессы, дать им характеристики для возможности соотнесения требований стейкхол-деров с их (не)функциональными характеристиками (таблица 3), последующего создания пользовательских руководств к прототипам процессов в целях их интегрирования в систему.
Авторами настоящей статьи проведена декомпозиция по двум первым из семи приемам формулирования требований (с уточнением структуры работ для пользователей), так как именно в рамках данных процедур пациент является участником и субъектом управления процессами формирования требований проекта .
Для проверки (не)функциональных требований необходима разработка прототипа с последующим его автоматическим тестированием в системе.
Создание прототипов процессов - продукт формального цифрового выражения требований для снижения разрыва ожиданий между пользователями проекта. В данной части статьи рассмотрены виды прототипов, их применение в ходе разработки требований к проекту и использования в процессе их разработки.
Возможные дефекты при формулировании требований, особенно на ранних этапах создания проекта сопровождающиеся неопределённостью процессов, что требует уточнений посредством прототипов. Изучение альтернативных вариантов реализации взаимодействия пользователей проекта с применением прототипов процессов также может свидетельствовать об осуществимости соблюдения требований.
По сути, прототип является функциональной реализацией подмножества процессов проекта, которые трансформируются в готовый продукт посредством циклов итераций. Посредством продукта
осуществляется изучение методов концепции системы для будущего прототипирования процессов проекта.
Для понимания определения времени и цели создания прототипа необходимо описать атрибуты прототипов, которые могут иметь по две функциональные альтернативы: по назначению (модель прототипа для наглядного представления объекта исследования или для оценки технических характеристик продукта проекта); по применению (модель прототипа устраняется после извлечения пользы или эволюционирует в процессе итеративных преобразований); по внешнему виду (модель прототипа можно изобразить схематично на бумаге или в виде цифрового «двойника», состоящего из рабочего программного обеспечения конкретной части решения) [11].
Фреймворки моделирования (правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию - «каркас», который нужно будет расширять и изменять согласно указанным требованиям [16] уже предоставляют возможность импортировать требования и связывать их с элементами будущего прототипа модели. Например, инструменты БуэМЬ (инструмент системного проектирования) предоставляют такие возможности (АгтопаБ, 2011) [17] посредством трассировки, получения и удовлетворения взаимосвязей.
«... Предварительно необходимо обеспечить про-слеживаемость между требованиями и элементами модели прототипа, которая может быть расширена путем связывания терминов утверждений требований с более подробными элементами модели (например, свойствами или характеристиками). Это обеспечивает более детальную интеграцию требований и элементов модели, снижая риск неоднозначного понимания требований.» [18]. Следуя этим принципам, как только семантика моделей прототипа формально и в полной мере определена и ограничена, фреймворк автоматически определяет моделируемые потребности и генерирует улучшения. Требования возможно автоматически преобразовать в текстовой формат, что способствует пониманию и архивированию сгенерированных спецификаций (Дюпре, 2021).
Авторами предложено структурировать наборы требований на основе разбивки по моделям (табл. 4).
На рис. 4 показаны возможные способы синтеза различных примеров прототипов. Например, сведения, которые получены по итогам разработки ряда горизонтальных прототипов (одноразовых), возможно применять для верификации требований, которые реализовывались путем итеративных
Таблица 3
Декомпозиция процессов при формировании требований для пользователей проекта (пациенты и исполнители)
Приемы формулирования требований Определение/ проведение/выбор Пациент Команда проекта
Аккумулирование информации о пользователях проекта/Выявление требований (из 13 позиций, 8 для совместного формирования требований пользователями проекта) границ и плана проекта понимание концепции проекта
групп пользователей архетипы пользователей* проекта
помощника(ов) проекта - ответственное лицо за каждый раздел работы в проекте
целевых групп уточнение функциональности и качественных характеристик пользователей услуг в проекте с учетом предыдущего опыта реализации проекта
назначения продукта проекта для пользователя уточнение сценариев использования, задач или пользовательских историй для понимания взаимодействия с системой
структурных мероприятий внешние события и ожидаемая ответная реакция системы и реакция на них
интервьюирование обсуждение конкретных требований, имеющих значение для интервьюируемого заинтересованного лица
тренингов и семинаров совместные семинары по выявлению требований для выявления нужд пользователей для пересмотра требований
очного наблюдения очное наблюдение за пользователями, выявляет контекст возможного применения нового продукта/решения проекта
анкетирования качественные вопросы направлены на выявление (опросные листы) аналитической информации о потребностях
перечня документов для анализа анализ письменной информации о текущих системах и процессах проекта, спецификации требований
новой информации - источник идей о возможностях, которые можно и инсайта по результатам реализовать в следующей итеративной версии анализа документации
итеративного использования - пересмотр требований для использования новых компонентов
Тестирование/Анализ моделирования среды - карты маршрутизации пациентов, порядки требований (из 7 позиций, проекта взаимодействия субъекта и объекта управления 2 для совместного формирования требований пользователями проекта)
создания прототипов оценка прототипа для помощи разработчикам и пользователям для решения проблем и проверки требований
осуществимости требований - возможность реализации каждого требования с учетом затрат, производительности в предполагаемой среде проекта
приоритетов требований коррекция и приоритетность выбора требований проекта с учетом потребностей потребителей услуг, условий проекта и целей
терминологических словарей - использование согласованных определений данных участниками проекта
моделей анализа наглядное выявление некорректных, несогласованных, отсутствующих и избыточных требований проекта
программного обеспечения - обеспечение связи между программными и аппаратными компонентами для гладкой интеграции ПО в среду проекта
' создание архетипов пользователей для описания прогнозируемых потребителей услуг, которые будут представлять конкретные классы пользователей
Менеджер / Мепедег №12
здравоохранения / 2с^гв\/аас:Ьгвпвп'1в 2024
Таблица
Моделирование требований для формирования прототипов (одноразового и эволюционного) (грубое приближение)
о VO
; -е-
0 CD -f
■= £ >х О
1 О-
О с t О
о.
vo ¥
ГЛ
В этом макете требования вложенности расположены горизонтально. Вложенные требования располагаются ниже требования к владению путем выравнивания центра всего ряда требований по центру требования к владению. Этот тип макета удобен, когда тексты требований невелики (а они не должны быть большими; если они есть - они должны быть разделены на несколько требований).
В данном макете требования того же уровня вложенности расположены вертикально. Вложенные требования располагаются ниже требования к владению путем смещения всего столбца требований вправо относительно требования к владению. Этот тип макета удобен, если имеется список требований, тексты которых занимают значительное количество места.
поступательных уточненных требований эволюционных прототипов.
Следующий способ, указанный на рис. 4, это использование одноразовой модели прототипа для уточнения требований до подготовки завершающей версии дизайна проекта, который синхронно проверяет элементы архитектурной структуры системы и начальные алгоритмы посредством экспериментального прототипа. Необходимо отметить, что обеспечение устойчивости при использовании одноразовых прототипов в производственной системе добиться невозможно, что является причиной несбыточности масштабирования продукта на неограниченное число пользователей, без необходимых архитектурных преобразований.
Выводы
Проведенная формализация требований для создания прототипа рабочего проекта, построенная на основе принципов взаимодействия
Видимость функциональности, без воплощения.
Прототип ориентирован на определенную часть пользовательского взаимодействия и не вовлекает уровни архитектуры или подробности функциональности. Прототип позволяет оценить поведение системы исследования в различных ситуациях для уточнения требований, осуществлять частичную навигацию между ними, но не содержит реальной функциональности. Модель позволяет пользователям проекта оценить возможности использования системы в работе, основанной на прототипе. Параметры последовательности выполняемых действий, оценка поведения пользовательского интерфейса (цвета, планировка, графика, элементы управления) и структуры доступа к информации (структура навигации) - основные требования, предъявляемые к данному типу прототипа.
Воплощает срез функциональности приложения от интерфейса пользователя через все уровни технических сервисов, затрагивает все уровни реализации проектируемой системы. Разрабатывается в случаях, когда есть сомнения в осуществимости и стабильности предполагаемого подхода к архитектуре системы или, когда хотите оптимизировать алгоритмы, оценить предлагаемую схему базы данных или проверить критически важные временные требования. Экспериментальные образцы создают, используя средства разработки в среде, аналогичной среде разработки. Полезны для сбора информации для совершенствования способности команды оценивать усилия по реализации определенной пользовательской истории или блока функциональности. В проектах гибкой разработки (agile) вертикальный прототип называют спайком (spike).
потребителя медицинских услуг и исполнителя проекта, показала необходимость формализовать формулирование требований.
Синхронная разработка требований с моделями прототипов неизбежно потребует текстового сопровождения на естественном языке, но необходимо учитывать, что интерпретация данных может быть вариабельной. Поэтому решение перехода от неформальных требований к полностью формальным является важным этапов для решения задачи упорядочивания (кодификации). В целях оптимизации задач, использование моделирования, цифровых программ и инструментов позволят автоматизировать процессы.
Одним из примеров является EARS (Мавин и др., 2009), единый синтаксис (структура) с базовым набором правил. Для обозначения различных пунктов требований EARS используется небольшое количество ключевых слов. Пункты всегда располагаются в одном и том же порядке в соответствии
№12 Manager
2024 Zdravoochranania ,
Рис. 4. Возможные способы формализации процессов прототипов проекта
с временной логикой. Структурирование утверждений требований с использованием шаблонов является простым подходом к синтаксису требований.
Формализовать текстовые требования возможно также с использованием системного инженерного пакета (1?Е115Е, 2022), который обеспечивает ресурс для создания, идентификации происхождения, порождения или зависимости (трассируемость) и проверки требований, одновременно предлагая расширенные возможности для инсталляции и использования подобных шаблонов и онтологий. Это помогает интегрировать методы, основанные на естественном языке в цифровую платформу для автоматического анализа и проверки качества, согласованности и оптимизировать процессы проверки и архивирования.
Результатом решения проблем разработки и управления проектами в итоге становятся опти-
мизация требований: дефектов в требованиях, а значит в готовом продукте (медицинской услуге), процессов разработки, реализации и «расползания» границ проекта. Итогом является удовлетворение требований членов команды и потребителей услуг (пациентов), которые одновременно являются пользователями проекта.
Авторами настоящей статьи не найдены исследования, посвященные примерам завершенных проектов по созданию цифровых платформ (целостных технологических сред) в отрасли здравоохранения, где возможно конструирование и моделирование процессов в аутентичных средах. Исследователями планируется продолжить публикации статей, посвященных данной тематике, реализуя методологию «выращивания» недостающих видов обеспечений вокруг существующего технологического ядра в отрасли.
Менеджер / Мепедег №12
здравоохранения / 2с^гв\/аас:Ьгвпвп'1в 2024
СПИСОК ИСТОЧНИКОВ
1. Ткаченко И.Н., Злыгостев А.А. Оценка вклада стейкхолдеров в стоимость компании: пример российского банковского сектора. Управленец. 2018; 9(4):40-52. DOI: 10.29141/2218-5003-201 8-9-4-5.
2. Орехова С.В., Сафаров М.А. Стейкхолдерская бизнес-модель оказания медицинских услуг: иерархия, ресурсный обмен и баланс «издержки - выгоды». Вестник Челябинского государственного университета. 2023;8 (478):148-160. doi: 10.47475/1994-2796-2023-478-8-148-160.
3. Wiegers K.E. "Creating a Software Engineering Culture," Dorset House Publishing, New York, USA, 1996.
4. Калесник М.В., Ягелло К.Г. Анкетирование пациентов как способ оценки уровня оказания медицинской помощи в реанимации. FORCIPE. 2021;(1):153. URL: https://cyberleninka.ru/article/n/ anketirovanie-patsientov-kak-sposob-otsenki-urovnya-okazaniya-meditsinskoy-pomoschi-v-reanimatsii (Дата обращения: 22.10.2024).
5. Берсенева Е.А., Мендель С.А., Савостина Е.А., Таирова Р.Т. Результаты анкетирования пациентов с целью оценки организации процессов в медицинском учреждении. Вестник современной клинической медицины. 2018; 11(2):59-65. DOI: 10.20969/VSKM.2018.11(2).59-65.
6. Майк Кон. Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). М.: «Вильямс», 2011; 576 с. ISBN 978-5-8459-1731-7.
7. Ахохова А.В., Тхабисимова И.К., Филипченков О.В., и др. Фундаментальная роль итеративных процессов при создании рабочего прототипа в медицинских организациях, реализующих проекты. Медицинские технологии. Оценка и выбор. 2024;(2):61-68. https://doi.org/10.17116/ medtech20244602161.
8. Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика = Agile software development. Principles, Patterns, and Practices. Вильямс, 2004; 752 с. ISBN0-13-597444-5.
9. James A. Highsmith. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002. ISBN978-0-201-76043-9.
10. Ткаченко И.Н., Сивокоз К.К. Использование гибких технологий Agile и Scrum для управления стейкхолдерами проектов. Управленец. 2017;4(68):85-95.
11. Вигерс К., Битти Д Разработка требований к программному обеспечению. 3-е изд., дополненное. М.: Издательство «Русская редакция»; СПб.: БХВ-Петербург, 2014; 736 с.
12. AFNOR. 2015. IS0/CEI/IEEE15288:2015 Системы и программное обеспечение. Процессы жизненного цикла системы. AFNOR. www.afnor.org.
13. Садовникова Н.П., Парыгин Д.С., Щербаков М.В. Системы поддержки принятия решений: учеб. Пособие. ВолгГТУ. Волгоград, 2021; 108 с.
14. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД "Вильямс", 2002; 231с.
15. Кратчен Ф. Введение в Rational Unified Process. СПб.: Вильямс, 2002; 240 с.
16. Дюпре Дж. 2020. «На пути к семантическому подходу к спецификации Фреймворков MBSE», 30-й ежегодный Международный симпозиум INCOS, виртуальное мероприятие. DOI: 10.1002/ ¡2334-5837.2020.00794.х.
17. Дюпре Дж. 2016. «Эффективное решение на основе сценариев для обеспечения полноты и согласованности функциональных спецификаций. 'Matlab Expo 2016, Париж, Франция, 21 июня 2016 г., DOI: 10.13140/RG.2.2.16877.28647.
18. Дюпре Дж. 2020. «На пути к семантическому подходу к спецификации Фреймворков MBSE», 30-й ежегодный Международный симпозиум INCOS, виртуальное мероприятие. DOI: 10.1002/ ¡2334-5837.2020.00794.х.
19. The Systems Modeling Language (SysML: www.omgsysml.org) is a general-purpose graphical modeling language, defined by the Ob¡ect Management Group (OMG), based on the well-known Unified Modeling Language (UML: www.uml.org).
№12 Manager /Менеджер
2024 Zdravoochranenia / здравоохранения
REVIEW
PROCESS PROTOTYPING IS A PRODUCT OF FORMAL DIGITAL EXPRESSION OF REQUIREMENTS TO REDUCE THE EXPECTATION GAP BETWEEN PROJECT USERS IN HEALTHCARE
A.V. Akhokhova a : , M.H. Tlakadugova b, I. Kh. Almova c, Z.H. Nakhusheva d, D.A. Shukurova e, L.D. Kardanova f, K.D. Dzhankulaeva g, A.L. Betuganova h, Z.A. Ulbasheva M.M. Khavzhokova A.I. Zheldasheva k
a Limited liability company Firm «SEM», KBR, Nalchik, Russia;
a, b, c, d, e, f, g, h, |, ¡, k FSBEI HE «Kabardino-Balkarian State University named after H.M. Berbekov» Ministry of Education and Science of Russia, Nalchik, Russia. a https://orcid.org/0000-0003-2370-9701; E https://orcid.org/0009-0006-7051-2935;
e https://orcid.org/0009-0003-3590-6961; f https://orcid.org/0000-0003-1570-2497;
h https://orcid.org/0000-0002-5228-870X; j https://orcid.org/0009-0002-7400-2749;
b https://orcid.org/0000-0003-1329-6085 d https://orcid.org/0009-0008-9333-2755
g https://orcid.org/0009-0001-7415-8666; j https://orcid.org/0009-0002-8850-6948; k https://orcid.org/0009-0001-3138-7055.
] Corresponding author: Akhokhova A. V.
ABSTRACT
The increasing complexity of operating and maintaining technical systems in the healthcare industry has led to the need to solve problems associated with speeding up development and increasing the maturity of project design. The risks of missed opportunities, and the high probability of unpredictability of results, potentially affect the cost and success of projects implemented in this area. This initiates the integration of new methodologies and tools focused on the digitalization of project design. Therefore, formalization methods and processes for documenting the requirements of project process prototypes are key to managing their behavior. The purpose of this study was to argue for the need to integrate existing processes into a digital format in the form of prototypes to extract maximum benefits and optimal ease of use. Currently, work on developing formal requirements is carried out manually, based on documents, without clear structuring and systematization; they are still in text formats and expressed in natural language. Modeling frameworks provide the ability to import requirements and associate them with elements of a future prototype design model. Materials and methods. The theoretical basis for the literature review was the scientific works of Russian and foreign researchers devoted to the study of the stakeholder approach, including the theory of resource dependence, the development of integrated digital requirements and reengineering.
Results. Collecting, documenting, reviewing and managing project requirements are important components of resource utilization (planning) in the healthcare industry: time, investment and quality of healthcare services provided. Accordingly, the use of the obtained prototypes of project processes throughout its life cycle is a valuable tool for testing and improving mechanisms for optimizing (formalizing) these requirements. Conclusions. Developing integrated solutions into existing project workflows eliminates the potential for manual errors and ensures seamless digital work, maximum value and optimal usability. Thus, it provides a powerful way to validate the resulting representation of product stakeholders' needs early, easily, and intuitively.
Keywords: methods for formalizing requirements, digitalization, reengineering, healthcare projects, modeling frameworks, integrated digital requirements
For citation: Akhokhova A. V., Tlakadugova M.Kh., Almova I.Kh., Nakhusheva Z.Kh., Shukurova D.A., Kardanova L.D, Dzhankulaeva K.D., Betuganova A.L., Ulbasheva Z.A., Khavzhokova M.M., Zheldasheva A. I. Process prototyping is a product of the formal digital expression of requirements to reduce the expectation gap between project users in healthcare. Manager Zdravookhranenia. 2024; 12:77-89. DOT. 10.21045/1811-0185-2024-12-77-89
REFERENCES
1. Tkachenko I.N, Zlygostev A.A. Assessing the contribution of stakeholders to the value of the company: the example of the Russian banking sector. Manager. 2018; 9(4):40-52. DOI: 10.29141/2218-5003-2018-9-4-5.
2. Orekhova S.V., Safarov M.A. Stakeholder business model for the provision of medical services: hierarchy, resource exchange and cost-benefit balance. Bulletin of Chelyabinsk State University. 2023; 8(478):148-160. doi: 10.47475/1994-2796-2023-478-8-148-160.
3. Wiegers K.E. "Creating a Software Engineering Culture," Dorset House Publishing, New York, USA, 1996.
4. Kalesnik M.V., Yagello K.G. Questioning patients as a way to assess the level of medical care in intensive care. FORCIPE. 2021; (1): 153. URL: https://cyberleninka.ru/article/n/anketirovanie-patsientov-kak-sposob-otsenki-urovnya-okazaniya-meditsinskoy-pomoschi-v-reanimatsii (Date of access: 10/22/2024).
5. Berseneva E.A., Mendel S.A., Savostina E.A., Tairova R.T. Results of a patient survey to assess the organization of processes in a medical institution. Bulletin of modern clinical medicine. 2018; 11(2):59-65. DOI: 10.20969/VSKM.2018.11(2).59-65.
6. Mike Cohn. Scrum: Agile Software Development = Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). M.: "Williams", 2011; 576 p. ISBN 78-5-8459-1731-7.
7. Akhokhova A.V., Tkhabisimova I.K., Filipchenkov O.V., et al. The fundamental role of iterative processes in creating a working prototype in medical organizations implementing projects. Medical technologies. Evaluation and selection. 2024;(2):61 68. https://doi. org/10.17116/medtech20244602161.
8. Robert S. Martin, James W. Newkirk, Robert S. Koss. Fast program development. Principles, examples, practice = Agile software development. Principles, Patterns, and Practices. Williams, 2004; 752 pp. ISBN0-13-597444-5.
9. James A. Highsmith. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002. ISBN 978-0-201-76043-9.
10. Tkachenko I.N, Sivokoz K.K. Using flexible Agile and Scrum technologies to manage project stakeholders. Manager. 2017;4(68):85-95.
11. Wigers K, Beatty D. Development of software requirements. 3rd ed., expanded. M.: Publishing house «Russian edition»; St. Petersburg: BHV-Petersburg, 2014; 736 p.
12. AFNOR. 2015. IS0/CEI/IEEE15288:2015 Systems and software. System life cycle processes. AFNOR. www.afnor.org.
Менеджер / Meneger №12
здравоохранения / Zdravoochranenia 2024
13. Sadovnikova N.P., Parygin D.S., Shcherbakov M.V. Decision support systems: textbook. Benefit. Volga State Technical University. Volgograd, 2021; 108 p.
14. Leffingwell D., Widrig D. Principles of working with software requirements. M.: Publishing House "Williams", 2002; 231 p.
15. Kratchen F. Introduction to the Rational Unified Process. SPb: Williams, 2002; 240 p.
16. Dupré J. 2020, "Towards a Semantic Approach to the Specification of MBSE Frameworks", 30th Annual International INCOS Symposium, virtual event. DOI: 10.1002/j2334-5837.2020.00794.x.
17. Dupre J., 2016. «An efficient script-based solution for ensuring completeness and consistency of functional specifications.» Matlab Expo 2016, Paris, France, June 21, 2016, DOI: 10.13140/RG.2.2.16877.28647.
18. Dupre J. 2020, «Towards a Semantic Approach to the Specification of MBSE Frameworks», 30th Annual INCOS International Symposium, virtual event. DOI: 10.1002/j2334-5837.2020.00794. x.
19. The Systems Modeling Language (SysML: www.omgsysml.org) is a general-purpose graphical modeling language, defined by the Object Management Group (OMG), based on the well-known Unified Modeling Language (UML: www.uml.org).
ИНФОРМАЦИЯ ОБ АВТОРАХ / ABOUT THE AUTHORS
Ахохова Азис Владимировна - канд. мед. наук, доцент кафедры общественного здоровья, здравоохранения и профилактической медицины, ФГБОУ ВО «Кабардино-Балкарский государственный университет имени Х.М. Бербекова» Минобрнауки России, г. Нальчик, Россия; заместитель главного врача, ООО Фирма «СЭМ», г. Нальчик, Россия.
Azis V. Akhokhova - Candidate of Medical Sciences, Associate Professor of the Department of Public Health, Healthcare and Preventive Medicine, Federal State Budgetary Educational Institution of Higher Education «Kabardino-Balkarian State University named after Kh.M. Berbekov» Ministry of Education and Science of Russia, Nalchik, Russia; Deputy Chief Physician, SEM Firm LLC, Nalchik, Russia. E-mail: [email protected].
Тлакадугова Мадина Хажисмеловна - заведующая кафедрой нормальной и патологической анатомии человека, ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Беребекова», г. Нальчик, Россия.
Madina Kh. Tlakadugova - Head of the Department of Normal and Pathological Human Anatomy, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected].
Альмова Ирина Хаджиисмаиловна - канд. мед. наук, доцент кафедры общественного здоровья, здравоохранения и профилактической медицины Медицинской Академии ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Бербекова», г. Нальчик, Россия.
Irina Kh. Almova - of Public Health, Health and Preventive Medicine, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected]
Нахушева Залина Хамидбиевна - ассистент кафедры нормальной и патологической анатомии человека, ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Беребекова», г. Нальчик, Россия.
Zalina Kh. Nakhusheva - assistant at the Department of Normal and Pathological Human Anatomy FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected].
Шукурова Диана Айдыновна - ассистент кафедры виртуально-симуляционных и информационных технологий, ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Беребекова», г. Нальчик, Россия.
Diana A. Shukurova - Assistant, Department of Virtual Simulation and Information Technologies, Federal State Budgetary Educational Institution of Higher Education, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected].
Карданова Лейла Дадашевна - доцент кафедры общей врачебной подготовки и медицинской реабилитации, ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Бербекова», г. Нальчик, Россия.
Leila D. Kardanova - associate professor of the department of general medical training and medical rehabilitation FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected]
Джанкулаева Карина Джамбулатовна - ассистент кафедры общественного здоровья, здравоохранения и профилактической медицины, ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Бербекова», г. Нальчик, Россия. Karina Dz. Dzhankulaeva - assistant at the Department of Public Health, Healthcare and Preventive Medicine, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected]
Бетуганова Алина Латифона - старший преподаватель кафедры нормальной и патологической анатомии человека ФГБОУ ВО «Кабардино-Балкарский государственный университет им. Х.М. Беребекова», г. Нальчик, Россия.
Alina L. Betuganova - senior lecturer at the Department of Normal and Pathological Human Anatomy of the Federal State Budgetary Educational Institution of Higher Education FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. E-mail: [email protected]
Ульбашева Залина Азноровна - ассистент кафедры общественного здоровья, здравоохранения и профилактической медицины, ФГБОУ ВО «Кабардино-Балкарский государственный университет имени Х.М. Бербекова» Минобрнауки России, г. Нальчик, Россия. Zalina A. Ulbasheva - assistant at the Department of Public Health, Healthcare and Preventive Medicine, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov» Ministry of Education and Science of Russia, Nalchik, Russia. Е-mail: [email protected]
Хавжокова Маргарита Мухамедовна - старший преподаватель кафедры общественного здоровья, здравоохранения и профилактической медицины, ФГБОУ ВО «КабардиноБалкарский государственный университет им. Х.М. Бербекова», г. Нальчик, Россия. Margarita M. Khavzhokova - Senior Lecturer of the Department of Public Health, Health Care and Preventive Medicine of the Federal State Budgetary Educational Institution of Higher Education FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov», Nalchik, Russia. Е-mail: [email protected]
Желдашева Асият Исуфовна - ассистент кафедры общественного здоровья, здравоохранения и профилактической медицины, ФГБОУ ВО «Кабардино-Балкарский государственный университет имени Х.М. Бербекова» Минобрнауки России, г. Нальчик, Россия. Asiyat I. Zheldasheva - assistant of the department of public health, healthcare and preventive medicine, FSBEI HE «Kabardino-Balkarian State University named after Kh.M. Berbekov» Ministry of Education and Science of Russia, Nalchik, Russia. Е-mail: [email protected]
№12 Manager
2024 Zdravoochranania ,
