CC BY
136
регіону: проблема, концепція та шляхи її реалізації. Харків: Видавництво ХарРІ НАДУ “Магістр”. 2008. 138 с. 4. Доктрина інформаційної безпеки України. Затверджена Указом Президента України від 8 липня 2009 року № 514/2009.11. 5. Программы анализа и лингвистической обработки текстов [Электронный ресурс]. Режим доступу: http://www.rvb.ru/soft/catalogue/index.html. 6. Психолингвистическая экспертная система ВААЛ [ Электронный ресурс]. Режим доступу: http://www.vaal.ru.
7. Журавлев А.П. Фонетическое значение - Л.: ЛГУ, 1974. 8. Журавлев А.П. Звук и смысл. М., 1981. 9. Самые читающие страны мира [Электронный ресурс] Режим доступа: http://ria.ru/spravka/ 20080611/110842173.html.
Поступила в редколлегию 28.11.2013
Сидченко Сергей Александрович, канд. техн. наук, старший научный сотрудник научного центра Харьковского университета Воздушных Сил. Научные интересы: обработка и передача информации. Адрес: Украина, 61023, Харьков, ул. Сумская, 77/79. Сапрыкина Татьяна Вячеславовна, соискатель ХНУРЭ. Научные интересы: анализ информационно-психологических операций на социум. Адрес: Украина, 61023, Харьков, ул. Сумская, 77/79.
Школяренко Виталий Александрович, студент Национального технического университета «Харьковский политехнический институт». Адрес: Украина, 61002, Харьков, ул. Фрунзе, 21.
УДК 519.68
С.Ф. ЧАЛЫЙ, И.Б. БУЦУКИНА, И.А.КРИВОРОТЕНКО
ФОРМИРОВАНИЕ МОДЕЛИ ГИБКОГО ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СРЕДСТВАМИ PROCESS MINING КАК ЗАДАЧА УДОВЛЕТВОРЕНИЯ ОГРАНИЧЕНИЙ
Рассматривается проблема адаптации гибких методологий управления программными проектами, в частности методологии Scrum, с использованием процесса ретроспективы. Предлагается подход к проведению ретроспективы с использованием модели процесса разработки, полученной методами process mining. Описывается задача формирования модели гибкого процесса разработки программного обеспечения. Предлагается обобщенный алгоритм решения данной задачи с учетом ограничений по исполнителям, задачам и по времени. Ключевые слова: гибкие методологии разработки, Scrum, ретроспектива, process mining, задача удовлетворения ограничений.
1. Введение
В настоящее время на разработку программного обеспечения затрачивается большая часть средств, выделенных на проектирование информационной системы в целом. В течение всего жизненного цикла разработки программного продукта необходимо осуществлять контроль своевременности и качества разработки. Эффективное построение процесса разработки программного продукта позволит снизить риски к минимуму, а также максимально учесть требования заказчика. В связи с этим использование эффективных методологий разработки программного продукта является актуальным.
Современные методологии разработки обеспечивают широкий диапазон подходов к созданию программных систем - от традиционной, водопадной модели до гибких, адаптируемых методологий.
Традиционный подход к управлению проектами направлен на последовательную, линейную разработку. Формируются требования, разрабатывается проект, выполняется кодирование и тестирование. По результатам выполнения всех этапов жизненного цикла проект сдается заказчику целиком. Существенным недостатком данного подхода является необходимость детального описания требований до начала разработки. В то же время на практике, в процессе разработки продукта могут возникать новые требования, уточняться уже существующие. Однако при традиционном подходе требования и сроки должны быть зафиксированы до начала разработки.
117
Альтернативой традиционному подходу являются гибкие методологии, при использовании которых на каждом этапе планируется разработка лишь ограниченной функциональности программного продукта. После завершения очередного этапа разработки заказчик может видеть работающую версию программного продукта, а также оценить ее соответствие сформулированным ранее требованиям. Это позволяет заказчику определить новые либо переопределить существующие требования.
Указанный подход к разработке предусматривает возможные изменения в требованиях заказчика и позволяет адаптировать методологию во время разработки проекта с учетом изменяющихся требований [1].
Процесс разработки программного обеспечения в соответствии с гибкой методологией целесообразно рассматривать как процесс преобразования ресурсов. Построение и уточнение моделей таких реально выполняющихся процессов связано с решением задач process mining. Формализация гибких методологий разработки путем построения модели процесса методами process mining с учетом имеющихся ограничений позволяет своевременно и эффективно вносить изменения в проект в соответствии с новыми требованиями (ограничениями). Также это дает возможность выявить и устранить отклонения от желаемого результата на ранних этапах разработки продукта и откорректировать ограничения за счет постоянной верификации продукта заказчиком.
Изложенное выше и определяет актуальность рассматриваемой в статье проблематики.
2. Анализ литературы
Сущность гибких(Agile) методологий разработки программного обеспечения была представлена в документе «Манифест гибкой методологии разработки программного обеспечения» в виде 4 основных идей и 12 принципов [2]. Гибкие методологии использовалась многими компаниями и до принятия манифеста, однако именно после этого события Agile подход стал активно применяться при разработке программного обеспечения.
Гибкий, эволюционный процесс разработки программного обеспечения в общем случае представляет собой задачу удовлетворения ограничений [3,4]. Целью последней является нахождение таких значений переменных, которые бы удовлетворяли заданным ограничениям. Рассматриваемая парадигма основана на декларативном описании системы ограничений и используется, в частности, для решения задач распределения ресурсов и планирования [5]. Agile- процесс в общем случае включает в себя итеративно выполняющуюся задачу планирования на ближайший цикл разработки.
Наиболее популярной методологией Agile - разработки является Scrum. В основе методологии Scrum лежит разбиение процесса разработки на короткие этапы, именуемые спринтами. По окончании каждого спринта программное обеспечение с разработанной на данном этапе функциональностью предоставляется заказчику. Также по завершению спринта может выполняться ретроспектива.
Ретроспектива предназначена для совместного обсуждения членами команды прошедшей итерации, выявления узких мест и усовершенствования процесса разработки. В целом ретроспектива является одним из ключевых элементов методологии Scrum, поскольку именно она позволяет адаптировать Scrum, делая из него по-настоящему гибкий подход к управления проектами [6].
В то же время, существующие подходы к выявлению узких мест в процессе разработки являются скорее искусством, они не формализованы и связаны с выделением ограничений человеком, что приводит к значительному влиянию человеческого фактора при решении поставленной задачи. Все это и определяет важность формализованного выявления процесса разработки на основе описания ограничений по наборам, задачам и характеристикам исполнителей.
3. Цель исследования
В процессе разработки программного обеспечения и последующей ретроспективы могут возникать следующие проблемы, снижающие производительность команды разработчиков:
- размер спринта может быть переоценен/недооценен;
118
- производительность команды/отдельных членов команды может быть ниже/выше ожидаемой;
- конкретные задачи спринта могут быть переоценены или недооценены.
Все эти проблемы в первую очередь возникают у молодых команд, которые еще не сработались и только начинают формироваться либо же на первых спринтах, когда еще не определена средняя производительность команд [6].
В связи с этим основной целью исследования является построение модели динамически изменяющегося процесса разработки с учетом ограничений по размеру спринта, производительности членов команды, уровню сложности разрабатываемых во время спринта задач. Применение данной модели создает условия для автоматизации выявления причин проблем и узких мест процесса разработки при проведении ретроспективы.
4. Задача удовлетворения ограничений при построении модели процесса
разработки программного обеспечения средствами process mining
Process mining (интеллектуальный анализ процессов, ИАП) - это процесс извлечения знаний о бизнес-процессах из журналов событий (логов). ИАП позволяет в автоматизированном режиме построить модель процесса, использовав журнальные данные. Следует отметить, что указанная технология базируется на интеллектуальном анализе данных (Data mining) [7].
Методы интеллектуального анализа процессов (process mining) используют в качестве исходных данных наборы последовательностей событий, отражающих выполнение процесса. Предполагается, что можно последовательно записывать события, и каждое из них относится к некоторой активности (т. е. к четко определенному шагу в процессе) и связано с экземпляром процесса. Такие записи, составляющие исходные данные для анализа, содержатся в журнале регистрации событий (логе).
Результатом использования методов process mining является модель исходного(выпол-нявшегося) процесса.
Такой процесс является дискретным (изменения состояний происходят только в дискретные моменты времени), который на входе получают ресурсы (финансовые, человеческие, материальные), во время своего выполнения преобразуют ресурсы в выходные программные продукты. Траектория (путь) выполнения рассматриваемых процессов отображается в виде дискретной последовательности событий. Каждое из них фиксирует выполнение соответствующего действия процесса.
Один из первых алгоритмов process mining основывался на обработке вероятностей наступления последовательностей событий. Основные шаги алгоритма состоят в следующем: создаются таблицы вероятностей для последовательностей событий путем подсчета числа появлений одинаковых последовательностей в потоке событий. После этого последовательности, вероятность и число появлений которых ниже установленного пользователем порога, отсекаются, а оставшиеся используются для создания конечного автомата [8].
Ведущий ученый в данной области Ван дер Аалст разработал наиболее часто используемый алгоритм process mining - б-алгоритм. Его основное отличие состоит в том, что заранее можно сказать, c каким классом моделей алгоритм будет гарантированно работать. Необходимое условие для работы алгоритма - отсутствие шума в исходных данных.
В основе алгоритмов ИАП лежит допущение, что все вершины графов должны иметь уникальные метки (т. е. одному уникальному событию должна соответствовать ровно одна вершина на модели). Это затрудняет извлечение дублируемых задач.
Все типовые конструкции распознает генетический алгоритм, однако его выполнение занимает очень много времени.
В целом, б-алгоритм является наиболее подходящим для решения поставленной задачи построения модели процесса разработки программного обеспечения, поскольку класс моделей известен заранее.
Типовая структура лога исходных, которая необходима для работы методов ИАП, включает в себя следующие элементы:
- событие, отражающее выполнение действия (задачи);
- временная метка;
119
- дополнительные параметры (например, исполнитель, объект, с которым работает процесс).
Для процессов быстрой разработки программного обеспечения файл лога включает следующие составляющие:
- временная метка;
- задача (идентификатор задачи);
- состояние события;
- пользователь (идентификатор пользователя);
- дополнительные атрибуты действия (сложность, затраченное время, приоритет).
Использование средств интеллектуального анализа процессов позволяет построить модель процесса разработки, которую впоследствии можно применять для анализа при проведении ретроспективы.
Процесс описывается графом, вершины которого отражают состояния моделируемой динамической системы, дуги - переходы между этими состояниями. Переходы связаны с выполнением действий над объектами процесса.
Выполнение одного из возможных в текущем состоянии действий процесса зависит от входного состояния процесса и набора выполненных действий.
Конечным состоянием является такое, из которого отсутствуют дуги в другие состояния процесса.
Реализация каждого процесса (след, трасса) представляет собой последовательность действий, переводящих процесс из начального состояния в конечное. В общем случае каждый процесс обладает множеством трасс. След процесса отражается в рассмотренном выше файле лога.
Учитывая рассмотренные особенности задачи построения модели процесса гибкой разработки программного обеспечения, можно сделать вывод о том, что данная задача
определяется набором дискретных переменных V={vt,vs,vp}, которые соответствуют продолжительности спринта, набору задач спринта и исполнителям (членам команды). Множества значений для каждой из переменных D={Dt,Ds,Dp} определяются соответственно требованиями заказчика к срокам сдачи проекта, к функциональности разрабатываемого программного обеспечения, а также составом и квалификацией команды разработчиков.
Для задания ограничений определим на множестве значений отношение R с Dt xDs xDp, задающее допустимые сочетания значений рассмотренных переменных. Множество переменных D с D, на котором определено отношение R, задает возможный диапазон отношений, а пара C=(R,D*) определяет набор ограничений рассматриваемой задачи. Тогда задача построения модели гибкого процесса разработки программного обеспечения средствами process mining представляет собой задачу удовлетворения ограничений, которая имеет следующий вид: M={vt,vs,vp,Dt,Ds,Dp,C}, где C={Ct,Cs,Cp} - набор ограничений по срокам, задачам на один спринт и возможностям исполнителей.
Для решения задачи необходимо найти такие значения переменных vt ,vs ,vp, которые бы удовлетворяли ограничениям C .
При решении данной задачи необходимо учитывать, что отношение R является пересечением отношений для сроков, исполнителей, задач: R=Rt n Rs n Rp.
Технология анализа процесса разработки заключается в предварительном анализе лога событий, структурировании/фильтрации данных, построении графиков на основе полученных данных. Предварительный анализ процесса разработки позволяет формализовать/ визуализировать его с различных сторон:
1. Формализация/визуализация процесса выполнения конкретной задачи. Сравнение реального времени выполнения с оцененным.
2. Формализация/визуализация процесса выполнения задач конкретным членом команды. Сравнение производительности члена команды с ожидаемыми оценками.
3. Формализация/визуализация процесса выполнения спринта в целом.
Таким образом, применение методов анализа процессов позволит обеспечить эффективное проведение ретроспектив с выявлением проблемных мест в процессе разработки.
120
Для решения рассмотренной задачи удовлетворения ограничений по длительности цикла разработки на каждой итерации, по исполнителям, функциональности необходимо выполнить следующие шаги:
1. Трансформация исходных данных для построения модели процесса разработки методами process mining в требуемый формат.
2. Модификация названий задач с учетом их статуса и исполнителя.
3. Формирование ограничений по размеру спринта, по исполнителям, по функциональности.
4. Формирование исходных данных для построения модели с учетом имеющихся ограничений.
5. Построение модели процесса разработки на основе выделенных исходных данных.
6. Анализ модели и при необходимости уточнение ограничений.
Алгоритм решения задачи формирования модели гибкого процесса разработки программного обеспечения средствами process mining представлен на рисунке.
5. Выводы
Формирование модели гибкого процесса разработки программного обеспечения средствами интеллектуального анализа процессов представлено как задача удовлетворения ограничений. Данная задача определяется следующим набором дискретных переменных: продолжительность спринта (базового цикла разработки), допустимый набор задач спринта, требуемый уровень квалификации исполнителей (членов команды разработчиков).
Множества значений для каждой из переменных задачи определяются уровнем требований заказчика (владельца проекта) к срокам его разработки, к его функциональным возможностям, а также квалификации разработчиков.
Ограничения для рассматриваемой задачи определяются с учетом отношения, задающего допустимые сочетания значений указанных переменных, а также их подмножества, на котором определено данное соотношение.
Выделена базовая последовательность этапов метода построения разработки и предложен обобщенный алгоритм решения данной задачи с учетом ограничений по исполнителям, задачам и
Начало
3
Модификация названий задач с учетом статуса и исполнителя
Преобразование данных в формат ИАД
Построение модели с помощью алгоритма ИАП
Нет
2LC
Конец
3
Алгоритм решения задачи построения модели процесса разработки программного обеспечения с учетом ограничений по исполнителям, задачам и по времени
по времени.
121
В практическом плане полученные результаты дают возможность усовершенствовать гибкую методологию разработки программных проектов Scrum путем построения модели и использования ее в процессе ретроспективы. Применение модели дает возможность автоматизировать выявление причин проблем, возникших во время проведения спринта. Поэтому применение методов process mining позволяет увеличить эффективность ретроспективы и вследствие этого улучшить процесс разработки программного продукта в целом.
Список литературы: 1. Мартин, Р. Быстрая разработка программ. Принципы, примеры, практика. Tennessy, 2011. 264 с. 2. Книберг, Х. Scrum и XP для тренеров. Вильямс, 2010. 268 с. 3. Apt K. R. Principles of Constraint Programming. New York: Cambridge University Press, 2003. 407 p. 4. RossiF., van BeekP., Walsh T. (eds.) Handbook Of Constraint Programming. Elsevier, 2006. 978 p. 5. KautzH., Selman B. Planning as Satisfiability // Proceedings of European Conference on Artificial Intelligence ECAI-92 (Vienna, 1992). Chichester: John Wiley and Sons, 1992. P. 359-363. 6. Мартин, Р. Чистый код. Висконсин, 2010. 201 с. 7. Van der Aalst W. Process Mining: Discovery, Conformance and Enhancement of Business Processes Y.: Springer Verlag, 2011. 370 р. 8. БарсегянА. Анализ данных и процессов. Спб: БХВ-Петербург, 2009. 513 c.
Поступила в редколлегию 28.11.2013
Чалый Сергей Федорович, д-р техн. наук, профессор кафедры ИУС ХНУРЭ. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 70-21-451.
Буцукина Инна Борисовна, доцент кафедры экономической кибернетики и управления экономической безопасностью ХНУРЭ. Научные интересы: моделирование бизнес-процессов, интеллектуальный анализ процессов. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, е-mail: inessa_@list.ru
Криворотенко Иван Алексеевич, магистр кафедры ІУС ХНУРЭ. Научные интересы: гибкие методологии разработки программного обеспечения, интеллектуальный анализ процессов. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, е-mail: ivan.krivorotenko@gmail.com
122
