CC BY
23
и
Подход к проектированию технических средств технологических процессов
Ю. И. Рогозов, В. С. Лапшин, А. С. Свиридов, С. А. Кучеров, А. Н. Беликов, Ю. Ю. Липко Южный федеральный университет, Ростов-на-Дону
Аннотация: В работе представлено исследование проблем организации процесса проектирования технических средств, которые задействованы в технологическом процессе выпуска продукции производственными предприятиями. Под техническими средствами предлагается понимать как программные, аппаратные, так и программно-аппаратные решения. Определена главная проблема - несоответствие функционала технических средств технологическому процессу. В этой связи проводится исследование процессов связывания технологического процесса выпуска продукции производственных предприятий с процессами проектирования и разработки технических средств. Обосновывается необходимость и выдвигается гипотеза о возможности решения выявленных проблем.
Ключевые слова: технологический процесс, актор, разработчик, функции технологического процесса, процедуры выполнения функций, модель формирования потребности в техническом средстве, модель использования технических средств, модель проектирования технических средств, технологии проектирования.
Введение
Существует фундаментальная проблема организации или усовершенствования технологических процессов выпуска продукции производственных предприятий, приводящих к достижению поставленной цели с заданными критериями эффективности [1]. Примером такой проблемы может быть организация технологического процесса выпуска летательных аппаратов, сборка которых не требует привлечения иностранных технических средств. Решение данной фундаментальной проблемы состоит, в первую очередь, в обеспечении технологического процесса выпуска продукции производственных предприятий техническими средствами, адекватными данному процессу. Для этого ставится задача связывания технологического процесса выпуска продукции производственных предприятий с процессами проектирования и разработки технических средств.
и
Технологический процесс выпуска продукции производственных предприятий представляет собой сложную организацию (организованное единство) технических средств, акторов (сотрудников предприятия, участвующих в процессе), сырья, материалов, регламентов и т. д. Задачи формирования регламентов, привлечения акторов (найма сотрудников), обеспечения сырья и материалов успешно решаются в отечественной и мировой практике. В то же время задача формализации процесса проектирования технических средств, которые были бы реально востребованы в технологических процессах, остается решенной не в полной мере. Несмотря на разнообразие и развитость методов и технологий создания и производства (проектирования и разработки) технических средств, они по-прежнему слабо и неэффективно формально связываются с технологическими процессами, для которых создаются и в которых эксплуатируются. Причины этого состоят в организации процесса проектирования, его ориентации на разработчика и утрате принципиальных, но не очевидных на первый взгляд деталей.
Связывание технологического процесса выпуска продукции производственных предприятий и процессов проектирования и разработки технических систем осуществляется через формирование потребности в техническом средстве. В существующих методологиях данная задача ставится перед разработчиком (в широком смысле этого слова) и включает в себя:
1. Выяснение того, какое техническое средство требуется актору для осуществления своей профессиональной деятельности с достижением целевых показателей в рамках технологического процесса выпуска продукции производственных предприятий;
и
2. Выяснение того, каким образом будет использоваться техническое средство в рамках технологического процесса выпуска продукции производственных предприятий.
Обобщенное представление фактического подхода к решению задачи формирования потребности в техническом средстве представлено на рис. 1.
Рис.1 - Фактически существующая организация процесса формирования
потребности в техническом средстве Фактический процесс формирования потребности в техническом средстве, согласно рисунку 1, есть не что иное, как совокупность действий разработчика по фиксации внешних проявлений деятельностей акторов (наименований функций), участвующих в осуществлении технологического процесса выпуска продукции производственных предприятий. Следовательно, при решении задачи формирования потребности в техническом средстве разработчик в качестве входных данных получает:
1. Модели функциональных и иных требований к технологическому средству, которое по мнению проектировщика моделей применимо в рамках исследуемого технологического процесса.
и
2. Набор сценарных моделей и алгоритмов использования функций из модели функциональных требований в некоторой части технологической деятельности актора.
В таком наборе входных данных (входных моделей) для разработчика технического средства формально не отражаются детали технологических процедур выполняемых актором функций. Например, в технологическом процессе оценивания достижений студентов важной является технологическая функция определения и оценки разницы между исходными знаниями студента в начале процесса обучения и текущими знаниями на момент оценивания. Некоторые студенты, имея нулевой уровень знаний в начале процесса обучения, проделывают колоссальную работу и к концу обучения обретают все необходимые для отличной оценки знания. Другие студенты могут иметь средний уровень знаний и, не прикладывая значительных усилий, к концу обучения остаются на прежнем уровне. Однако существующие технические средства оценивания студента зачастую формально не учитывают такой особенности процедуры выполнения функции оценивания, как учет разницы между начальным и текущим уровнем знаний студента. Зачастую, существующие технические средства предлагают реализацию обобщенного варианта функции выставления оценки - оценивание всех одинаково, например, от «0» до «5». В таком случае, на этапе формального описания функциональных, нефункциональных требований, сценарных моделей и алгоритмов системы контроля успеваемости студентов, не отражаются детали приведенных в примере технологических процедур выполняемых актором (преподавателем) функций, подлежащие реализации в техническом средстве. Данные детали, соответственно, не отражаются в создаваемых разработчиком моделях и реализуемых составляющих технических средств.
и
Модели, которые получает разработчик технического средства, содержат только наименования логически организованных функций (например, в виде блок-схем или диаграмм последовательности ЦЫС и т.д.), представленных на разных уровнях декомпозиции и иерархии, а также содержащих функциональные и нефункциональные (иные) требования к будущим техническим средствам. По сути, в таких моделях отсутствуют описания процедур выполнения функций и их логической организации в технологическом процессе актора.
Использование таких моделей на этапе формирования потребности в техническом средстве приводит к утрате его специфики, выраженной особенностями (смыслом) выполнения функций. В итоге, создаваемые по таким моделям технические средства, чаще всего оказываются не адекватными технологическому процессу выпуска продукции производственных предприятий.
В связи с этим, возникают следующие значимые научные задачи:
1. Задача построения модели процесса формирования потребности в технических средствах (МФПТС), учитывающая процедуры выполнения функций акторами с помощью требуемого технического средства.
2. Задача преобразования такой модели МФПТС в модель технического средства, которая учитывает особенности процедур выполнения актором функций.
Деталями выполнения функций, необходимыми для построения МФПТС, обладает актор технологического процесса. Чтобы разработчик был способен создать МФПТС такого типа, ему необходимо самому стать актором, получив значительный опыт в собственноручном осуществлении технологических процессов выпуска продукции производственных предприятий. Очевидно, что данный способ решения задачи связывания технологического процесса и процессов проектирования и разработки
и
является чрезмерно трудозатратным и не может рассматриваться в качестве действенного варианта. Следовательно, построением МФПТС такого типа должен заниматься сам актор, для чего требуется разработка соответствующих методов и инструментальных средств их создания.
МФПТС такого типа, в свою очередь, требуют изменения традиционных процессов проектирования и разработки технических средств, в которых на сегодняшний день не учитываются детали процедур выполнения (осуществления) функций актором. Фактически, в процессе конструирования выполняемых в технологических процессах инструментальными средствами функций, не учитываются правила выполнения или осуществления этих функций. Поэтому второй задачей является разработка новых методов проектирования МФПТС, в которых будет обеспечена ориентация на актора и преобразование (или переход) МФПТС такого типа в модели технических средств, учитывающих как технологические особенности, так и особенности процедур выполнения функций технологического процесса выпуска продукции производственных предприятий.
В данной статье подробно рассмотрены и проанализированы особенности существующих подходов к организации связи технологического процесса выпуска продукции производственных предприятий и процессов проектирования и разработки технических средств, а также обосновывается необходимость и выдвигается гипотеза о возможности решения двух вышеобозначенных задач.
Обзор существующих подходов к связыванию
Существует множество подходов, использующих технологии, с помощью которых организуется взаимосвязь технологического процесса выпуска продукции производственными предприятиями и проекта создания
и
технического средства. В большинстве случаев, эти технологии представлены CASE-средствами, которые используются, в частности, для: а) создания моделей процесса формирования потребности в технических средствах технологического процесса выпуска продукции производственными предприятиями (МФПТС); б) модели проектирования технических средств технологического процесса выпуска продукции производственными предприятиями (МПрТС); в) моделей использования технических средств технологического процесса выпуска продукции производственными предприятиями (МИТС).
Традиционно, МФПТС ориентируются на разработчиков и акторов - они редко самостоятельно (чаще совместно со специалистом IT) описывают желаемые потребности в функциях будущих инструментальных средствах, и представляют результат такого описания в виде диаграмм. В свою очередь, МПрТС и МИТС ориентируются на разработчиков и представляют им соответствующий синтаксический функционал для проектирования и верификации структуры и логики функционирования средств.
Таким образом, связывание технологического процесса выпуска продукции производственных предприятий с процессом проектирования и разработки технических средств должно осуществляться за счет единства моделей МФПТС, МПрТС и МИТС. Однако, на сегодняшний день, процессы создания и использования данных моделей формально не связаны между собой, а эмпирически используются разработчиками для создания технических средств.
Так, например, с точки зрения представления модели МФПТС можно обратиться к методологии исполняемых моделей. В рамках методологии исполняемых моделей выделяют подходы Workflow (поток работ) и BPM (управление бизнес-процессами). Отличаются данные подходы детализацией применения с точки зрения процесса (Workflow ориентирован на выполнение
и
одного процесса, ВРМ направлен на управление бизнес-процессами и всеми их составляющими). Системы, реализованные на основе данных подходов, позволяют эмпирически реализовать функции моделирования, исполнения, контроля и поиска способов оптимизации процессов. В настоящее время, разработаны различные стандарты для описания рабочих процессов, такие как: WSFL, XPDL, BPM и другие [2-4];
Так, например, разработчики стандарта XPDL характеризуют его как «формальную модель для описания рабочих процессов, относящихся к любым сферам деятельности» [5]. Основными компонентами стандарта (спецификации) XPDL являются следующие (рис. 2):
• Рабочий процесс - основной компонент, взаимодействующий со всеми остальными компонентами, отвечает за контекст выполняемых процессов;
• Действия - элементарная единица процесса, отвечающая за изменения содержания объектов процесса;
• Переходы - связи между действиями;
• Оперативные данные - данные, доступные всем компонентам процесса в ходе его выполнения;
• Участники процесса - субъекты выполняющие действия над объектами и осуществляющие переходы между ними;
• Приложения - объекты ^-инфраструктуры, позволяющие участникам выполнять действия над объектами (данными).
и
Рабочий процесс -Workflow Process
Рис. 2 - Компоненты спецификации XPDL
Однако, применения на практике спецификации в виде графической нотации (понятной актору) накладывает ограничения на компоненты. В настоящее время, для представления стандарта XPDL в графическом виде де-факто принято применять нотацию BPMN, которая, в первую очередь, ориентирована на разработчиков систем (в частности бизнес-аналитиков) [6].
Если проецировать модель МФПТС на модель процесса нотации BPMN, то можно увидеть, что BPMN позволяет отобразить поведенческий аспект актора процесса, и, частично, информационный аспект (документы, хранилища данных и их взаимосвязь с процессом). Однако такой подход не позволяет формально отобразить деятельность актора, который владеет знаниями о правилах выполнения или осуществления функций технологического процесса. Правила осуществления функций должны формально учитываться в технических средствах, используемых в процессе выполнения актором своей профессиональной деятельности в технологическом процессе производства.
Другим подходом к проектированию МФПТС, является построение диаграммы вариантов использования языка UML (Use Case Diagram) [7-9], пример которой представлен на рис. 3. В этом случае модель МФПТС описывает событийный характер задействования акторами некоторых частей
технологического процесса, используя при этом функционал будущего технического средства. В рамках нотации Use Case диаграммы, такие части технологического процесса определяются, как прецеденты использования будущего средства или просто «прецеденты» (овалы на рис. 3).
То есть, моделируется набор прецедентов, которые в некоторый момент времени (в зависимости от того, или иного события) могут быть использованы акторами (человечки на рис. 3), для реализации технологического процесса. Под акторами понимается либо конкретный индивидуум - сотрудник предприятия заказчика, либо техническое средство, нуждающееся в результатах выполнения функционала проектируемого технического средства. Важно отметить, что в таком подходе к представлению МФПТС формально не учитываются процедуры или правила выполнения функций технологического процесса актора и его соотношения с поведением проектируемой системы.
«расширить»
Клиент
Рис. 3. - Пример модели процесса формирования потребности в инструментальных средствах
и
Важно отметить, что в таком подходе к представлению МФПТС формально не учитываются процедуры или правила выполнения функций технологического процесса актора и его соотношения с поведением проектируемой системы. Правила выполнения/осуществления действий актора по использованию технических средств в технологическом процессе производства и достижению технологических целей (создания продукции) ни графически, ни как-либо ещё не представляется. Задействование того или иного прецедента носит событийный характер, и в данной модели не отображается. Также в данном подходе к представлению МФПТС, не определяются точки перехода (синхронизации) на модель процесса проектирования системы. Процесс достижения актором технологической-цели по средствам МФПТС зависит от модели МПрТС, однако в данном подходе к представлению МФПТС нет возможности формально связать МФПТС и МПрТС.
В попытке устранить проблемы традиционного подхода, был предложен подход [10,11], который предполагает дополнение МФПТС представляемой диаграммой вариантов использования языка UML диаграммами последовательностей и кооперативными диаграммами языка UML.
Так, в подходе [10,11], описывается процесс проектирования моделей МФПТС и МПрТС. Модель МФПТС состоит из:
a. Модели бизнес-прецедентов, которая в свою очередь описывается:
i. UML Use-case диаграммой;
ii. UML диаграммами деятельности.
b. Модели бизнес-объектов, которые, в свою очередь, описывается:
i. Кооперативной диаграммой UML;
ii. UML Диаграммами последовательности;
и
c. Концептуальной моделью данных, которая описывается UML диаграммой классов. В свою очередь, модель МПрТС состоит из:
a. Модели системных прецедентов, которая описывается:
i. Use-case диаграммой UML;
ii. Диаграммой последовательности UML.
b. Модели структуры системы
i. Диаграмма классов UML.
c. Модели базы данных и других компонентов системы.
Диаграмма последовательностей строится для конкретного прецедента и определяет логику сценария достижения технологической цели, задействуя функционал технического средства.
Рис 4. Пример диаграммы последовательностей, дополняющей МИС. На данной диаграмме отображаются действия актора с техническим средством (горизонтальные стрелки на рис. 4). По сути диаграммы - это
и
некоторые «урывки» формального представления полного технологического процесса, в которых делается попытка описать правила выполнения актором функций, взаимодействуя с будущим техническим средством. Предполагаем, что формально представляются не правила, а их составляющие, которые отражаются на диаграмме в виде бизнес-сущностей - сущностей, с которыми работает актор в рамках технологического процесса (прямоугольники). По сути, бизнес-сущности должны отображаться в структуре технического средства, а поэтому процесс их выявления ложится на специалистов -разработчиков.
На кооперативных диаграммах бизнес-сущности показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного прецедента. Временная последовательность сообщений отражается их нумерацией.
Рис. 5. - Пример кооперативной диаграммы, дополняющей МИС Таким образом, можно сделать вывод, что традиционный подход доступен актору, поскольку предполагает представление МФПТС в виде набора процессов достижения технологической цели с использованием функционала будущего технического средства, однако его существенным минусом является отсутствие формального представления правила
и
осуществления функций актора по достижению технологических целей, которые определяют процедуры выполнения им функций технологического процесса с помощью требуемого технического средства. Также в данном подходе отсутствует связь с моделью процесса проектирования технических средств.
В подходе [10,11] предпринята попытка устранить данные проблемы, но, при этом, модель процесса формирования потребности в технических средствах превращается в модель процесса проектирования, поскольку в ней появляются элементы требуемого средства - сущности, выявление которых доступно только специалисту по разработке технических средств. Единство в соответствии с подходом [10,11] обуславливается тем, что МФПТС и МПрТС связываются через модели бизнес-объектов, которые преобразуются в сущности концептуальной модели данных, а она затем становится основой для частей МПИС, образуя единство указанных моделей. Противоречие заключается в том, что если на этапе построения бизнес-прецедентов у актора есть возможность отображать свои желания и потребности в функциях технических средств, то при построении бизнес-объектов актор не может единолично участвовать в этом процессе, поскольку бизнес-сущности уже имеют системный характер, по сути являясь сущностями технического средства. Данное обстоятельство говорит о том, что в существующих подходах попытки формально представить единство МФПТС и МПрТС осуществляются за счет смещения ориентации МФПТС не на актора, а на разработчика. По сути, в этом случае, МФПТС становится частью МПрТС, приобретая явно системный характер, теряя суть своего предназначения -быть ориентированной на актора, что означает доступность создания МФПТС, учитывающая процедуры выполнения акторами функций технологического процесса с помощью требуемого технического средства,
и
только за счет ресурсов акторов. В этом заключается существующее противотечение процесса проектирования.
В работе [12] представлена MSF технология создания технических средств, в соответствии с которой, МФПТС состоит из:
1. Краткого (в одну страницу) концептуального представления проекта - составляет бизнес- аналитик во время анализа ПО -документ word.
2. Стереотипы пользователей системы - роли пользователей -документ word.
3. Сценарии будущего использования систем с приоритетами (потребность в функциях) (только названия).
МПрТС состоит из:
1. Модель рабочих элементов в ADOS (Azure DevOps Server) -задачи на основе сценариев.
2. Модель нефункциональных требований (QoS), связанная со сценариями.
3. Модели архитектуры системы и др.
Рис. 6 - Модель ADOS со сценариями, интегрированными в нее, как
задачи.
В соответствии с технологией [13], формально представленное единство обуславливается тем, что МФПТС и МПрТС связываются через сценарии будущего использования технических средств, которые в дальнейшем преобразуются в задачи на модели ADOS (рисунок 5), а она, в свою очередь, является отправной точкой для разработчиков, реализующих инструментальные средства.
Противоречие заключается в том, что, как и в предыдущем примере, формально представленное единство моделей достигается за счет смещения ориентации МФПТС в сторону процесса проектирования, за счет того, что актору сразу предлагается участвовать в процессе определения сценариев взаимодействия с еще не созданным техническим средством. Актору предлагается мыслить в контексте того, как должно функционировать средство, без относительной привязки к правилам выполнения функций. Таким образом, в существующей модели МФПТС должны формально
и
отражаться процедуры выполнения функций технологического процесса с помощью требуемого технического средства, о которых знает и которые выполняет актор. Однако, на сегодняшний день, возможность для актора формально отразить процедуры выполнения функций своего технологического процесса с помощью требуемых ему технических средств отсутствует. В этом заключается существующее противотечение процесса проектирования.
В работе [9] представлена XP-технология (экстремальное программирование) создания технических средств. В рамках данной технологии модель МФПТС представляется моделью User Stories [13] (пер. модель пользовательских историй) - это краткое описание (обычно в двух-трех предложениях) определенной функции будущего технического средства. Эти истории не дают достаточно информации, чтобы превратить их в проектные задачи. В экстремальном программировании они используются для создания планов выпуска технического средства. План выпуска — это документ, который содержит пользовательские истории и определяет количество времени, необходимое для добавления необходимых функций в продукт.
Пользовательские истории часто представлены в виде простого предложения следующего вида:
«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».
Данные предложения должны составлять пользователи.
Что касается связи с моделью МПрТС, то она проявляется в двух местах:
1) На этапе, когда проектировщик оценивает историю и в процессе общения с заказчиком составляет на ее основе требования в технических терминах.
2) На этапе тестирования, когда пользовательские истории являются основой для составления сценариев тестирования программных продуктов.
и
Одной из проблем в образовании единства является отсутствие формального связывания с моделью проектирования, но наличие формализованного связывания с моделями тестирования, что графически представлено на рис. 7.
Рис. 7. Проблема единства моделей МФП и МПИС
Таким образом, из анализа рассмотренных подходов можно сделать вывод, что фактически модели МФПТС формально представляются в виде набора функций. Во-первых, модели МФПТС конструируются разработчиками средств, а не акторами. Во-вторых, модели МФПТС формально представляются не в виде описания процедур выполнения акторами функций технологического процесса с помощью требуемого технического средства, а в виде модели того, как функции будущих инструментальных средств будут использоваться акторами.
Эти обстоятельства не позволяет реализовать связь технологического процесса выпуска продукции производственных предприятий и процессов проектирования и разработки технических систем.
Заключение
Выявленное несоответствие между реальной потребностью акторов процессов производства в технических средствах и моделями их проектирования и использования, требует разработки новой модели МФПТС,
и
которая позволит осуществить связывание технологического процесса выпуска продукции производственных предприятий и процессов проектирования и разработки технических систем.
Такая модель МФПТС — это модель, которая отражает особенности выполнения функций вместе с их логической организацией в профессиональной деятельности актора. Она должна отражать информацию о:
1. субъектах (акторах), функции которых они выполняют, и правилах выполнения функций;
2. технических средствах, в которых отражается возможность не просто выполнять функции, но изменять правила их выполнения. Для описания единства «троицы»: субъектов, функций и технических средств должна использоваться определённая форма организации их единства, которую следует использовать актору для построения модели МФПТС;
3. процедурах или правилах выполнения функций технологического процесса акторов, с помощью требуемого технического средства.
Данные составляющие предлагаемой модели МФПТС будут способны организовать единство - динамический процесс построения модели использования технических средств, в котором отражаются процедуры выполнения функций технологического процесса с использованием требуемого технического средства.
При этом, технологии построения такой модели должны быть доступны непосредственному носителю потребности - формировать ее должен сам актор, деятельность которого исследуется.
Такая модель должна описывать деятельность, как последовательность выполняемых действий с отображением элементов, над которыми производится действие (материальные и информационные), функций, выполняемых с элементами при совершении действия и требуемых для
и
реализации функции технических средств. Данное описание может быть использовано для построения модели проектирования технических средств, которые требуются для реализации описываемой деятельности сотрудника.
Данная модель может рассматриваться как модель деятельности актора, но, в силу своей структуры, она является также моделью, специфицирующей потребности в технических средствах, которые должны быть использованы в технологическом процессе производства продукции.
С учетом этого предлагается по-новому организовывать процесс формирования потребности в техническом средстве, схема которого представлена на рис. 8.
При переходе к процессу создания технических средств, переложенная модель МФПТС будет являться основой для модели проектирования. При внедрении разработанных средств МФПТС должна соответствовать и модели применения разработанных средств. Можно утверждать, что эти три модели -модель формирования потребности в инструментальных средствах, модель проектирования и модель применения образуют единство, которое обеспечивает согласованность в процессе создания технических средств для цифровизации деятельности предприятия.
и
Рис. 8. - Предлагаемая организация процесса формирования потребности в техническом средстве
Благодарности
Исследование выполнено за счет гранта Российского научного фонда № 22-21-00670.
Литература
1. Марыгина Л. В., Пестрикова О. А. Повышение эффективности управления инвестиционно-строительными проектами на основе цифровизации //Инженерный вестник Дона, 2022, №. 2. URL: ivdon.ru/ru/magazine/archive/n2y2022/7483.
2. Lübke D., Pautasso C. Empirical Research in Executable Process Models //Empirical Studies on the Development of Executable Business Processes. -Springer, Cham, 2019. - pp. 3-12.
3. Leimeister J. M. Service-Modellierung //Dienstleistungsengineering und-management. - Springer Gabler, Berlin, Heidelberg, 2020. - pp. 215-277.
4. Weske M. Business process management architectures //Business Process Management. - Springer, Berlin, Heidelberg, 2019. - pp. 351-384.
5. Wil M. P. van der Aalst. Patterns and xpdl: A critical evaluation of the xml process definition language //BPM Center report BPM-03-09, BPMcenter. org. -2003. - pp. 1-30.
6. Filograna, A., Giunta, G., Ingraffia, N., Loiacono, L., Corallo, & Za, D. An integrated approach for modelling business processes using bpmn and xpdl standards //2th KMO Conference, Knowledge Management in Organization, Lecce. - 2007. - pp. 1-5.
7. Jacobson I. Object-oriented software engineering: a use case driven approach. - Pearson Education India, 1993. pp.1-552.
и
8. Jacobson I. Use cases-Yesterday, today, and tomorrow //Software & Systems Modeling. - 2004. - Т. 3. - pp. 210-220.
9. Simons A. J. H. Use cases considered harmful //Proceedings Technology of Object-Oriented Languages and Systems. TOOLS 29 (Cat. No. PR00275). - IEEE, 1999. - pp. 194-203.
10. Яловой И. О. Анализ требований и управление изменениями программных проектов // Инженерный вестник Дона, 2008, №. 4 URL: ivdon. ru/ru/magazine/archive/n4y2008/102.
11. Этапы проектирования ИС с применением UML // НОУ ИНТУИТ URL: intuit.ru/studies/courses/2195/55/lecture/1640?page=2 (дата обращения: 20.01.2023).
12. Проекты MSF Agile // Заметки консультанта URL: ashamray.wordpress.com/stati_hf/microsoft_vs/tfsguide/glava14/ (дата обращения: 20.01.2023).
13. Lucassen G. et al. The use and effectiveness of user stories in practice //International working conference on requirements engineering: Foundation for software quality. - Springer, Cham, 2016. - pp. 205-222.
References
1. Marygina L. V., Pestrikova O. A. Inzhenernyj vestnik Dona, 2022, №. 2. URL : ivdon.ru/ru/magazine/archive/n2y2022/7483.
2. Lübke D., Pautasso C. Empirical Studies on the Development of Executable Business Processes. Springer, Cham, 2019. pp. 3-12.
3. Leimeister J. M. Dienstleistungsengineering und-management. Springer Gabler, Berlin, Heidelberg, 2020. pp. 215-277.
4. Weske M. Business Process Management. Springer, Berlin, Heidelberg, 2019. pp. 351-384.
и
5. Wil M. P. van der Aalst. BPM Center report BPM-03-09, BPMcenter. org. 2003. pp. 1-30.
6. Filograna, A., Giunta, G., Ingraffia, N., Loiacono, L., Corallo, & Za, D. An integrated approach for modelling business processes using bpmn and xpdl standards. 2th KMO Conference, Knowledge Management in Organization, Lecce. 2007. pp. 1-5.
7. Jacobson I. Pearson Education India, 1993. pp.1-552
8. Jacobson I. Software & Systems Modeling. 2004. T. 3. pp. 210-220.
9. Simons A. J. H. Proceedings Technology of Object-Oriented Languages and Systems. TOOLS 29 (Cat. No. PR00275). IEEE, 1999. pp. 194-203.
10. Yalovoj I. O. Inzhenernyj vestnik Dona, 2008, №. 4 URL: ivdon. ra/ru/magazine/archive/n4y2008/102.
11. Etapy proektirovaniya IS s primeneniem UML [Stages of IC design using UML]. NOU INTUIT. URL: intuit.ru/studies/courses/2195/55/lecture/1640?page=2 (date accessed: 20.01.2023).
12. Proekty MSF Agile [MSF Agile Projects]. Zametki konsul'tanta URL: ashamray.wordpress.com/stati_hf/microsoft_vs/tfsguide/glava14/ (date accessed: 20.01.2023).
13. Lucassen G. et al. The use and effectiveness of user stories in practice. International working conference on requirements engineering: Foundation for software quality. Springer, Cham, 2016. pp. 205-222.
