Адаптация процессов контроля команды разработчиков программ с использованием логических правил Текст научной статьи по специальности «Компьютерные и информационные науки»

J

чалый С. Ф., Цимбаленко Р. н., Буцукина И. Б.

УДК 004.89

адаптация процессов контроля команды разработчиков программ с использованием логических правил

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

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

1. Введение

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

Правильное построение рабочего процесса при разработке программного средства позволяет свести до минимума риск невыполнения сроков, на которые рассчитывает заказчик и учесть все необходимые потребности, которые он выдвигает для команды разработчиков.

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

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

Изложенное подчеркивает актуальность использования гибких методологий разработки программных продуктов.

2. Анализ литературных данных и постановка проблемы

Впервые основная идея гибких методологий разработки была описана ее основным идейным вдохновителем

Хенриком книбергом [1]. Принципы гибких методологий разработки и, в частности, SCRUM также описаны в работах Р. Мартина, Ремси, Субраманиама, [2—4]. Особенности планирования и оценивания времени выполнения отдельных задач описаны в работах Д. Хамб-ла [5]. Описаниям взаимодействия методологии SCRUM и принципов KANBAN в своих трудах занимался Д. Рас-смуссон [6].

Во многих организациях типичный гибкий (Agile) процесс работает вполне успешно. Однако есть некоторые часто встречающиеся проблемы.

Так как одна итерация разработки приложения занимает обычно не более одного календарного месяца, то такой процесс принято считать разработкой в «короткой фазе».

При разработке в режиме «короткой фазы» возможно возникновение следующих трудностей [7—10]:

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

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

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

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

TECHNOLOGY AUDiT AND PRODUCTiON RESERVES — № 3/1(11], 2013, © Чалый С. Ф., Цимбаленко Р H.,

Буцукина И. Б.

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

3. Цель и задачи исследования

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

Достижение цели обеспечивается решением следующих задач:

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

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

4. Решение задачи с использованием бизнес-правил

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

Бизнес-правила при описании процессов и управлении процессами могут подразделяться на 4 основные группы: определение объектов, с которыми работает процесс; классификация объектов процесса; управление ходом выполнения процесса; определение структурных взаимосвязей между элементами процесса.

Ключевыми для предлагаемого подхода являются правила управления процессами. Они включают в себя правила изменения статуса процедур процесса.

Реализация рассмотренных правил при адаптации процессов контроля разработчиков выполняется следующим образом. Типовое правило (1) состоит из двух структурированных компонент:

— условий запуска правила;

— набора взаимосвязанных действий D по адаптации процесса разработки.

Условия запуска правила в общем случае подразделяются на два типа:

— обязательные условия е/, принимающие истинное значение при возникновении определенного события во время выполнения процесса;

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

e/ а C ^ D,

e¡ єЕ, C = ас, D = аjdj, Ує/ЗЩ :e¡ = true,

Как видно из (1), все действия D правила должны быть реализованы совместно. Такая реализация согласно предлагаемому подходу выполняется внешним приложением.

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

Основанный на правилах подход позволяет в перспективе реализовать парадигму Constraint Programming.

Таким образом, для управления потоком процесса достаточно задать определенный набор связанных непротиворечивых ограничений. Схема обработки бизнес правил представлена на рис. 1.

»

Scala

Program

■<

CSP Instance

SAT Instance

Solution of CSP

SAT Solver

Solution of SAT (File)

(1)

где Е — множество событий, возникающих при выполнении текущего процесса;П - k — путь реализации рассматриваемого процесса.

CoprisAPI Sugar API

Рис. 1. Схема обработки бизнес-правил

На этом рисунке приняты следующие условные обозначения:

а) SAT — задача выполнимости из пропозициональной логики.

б) CSP — задача удовлетворения ограничений.

Целью решения задачи УО является нахождение значений переменных, удовлетворяющих заданным ограничениям.

Для создания бизнес-правил предлагается программная реализация, которая способна заносить новые правила, привязанные к определенным процессам, в базу данных, перед этим проверив их непротиворечивость. Проверка правил на непротиворечивость производится двигателем бизнес правил.

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

5. Практическая значимость работы

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

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

— обеспечить согласованную обработку данных процесса;

— обеспечить согласованность информации, хранящейся в корпоративной базе данных;

технологический аудит и резервы производства — № 3/1(11], 2013

— сосредоточить внимание работников организации

на проблемах развития бизнеса, а не на выполнении

рутинных задач.

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

6. Выводы

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

Литература

1. Книберг, Х. Scrum и XP для тренеров [Текст] / Х. Кни-берг. — Вильямс, 2010. — 268 с.

2. Мартин, Р. Быстрая разработка программ. Принципы, примеры, практика. [Текст] / P. Мартин. — Tennessy, 2011.— 264 с.

3. Ремси, A. Getting Real [Текст] / A. Ремси. — NY, 2011. — 191 с.

4. Субраманиам, В. Этюды на тему быстрой разработки программного обеспечения [Текст] / В. Субраманиам. — Москва,

2009. — 302 с.

5. Хамбл, Д. Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ [Текст] / Д. Хамбл. — Вильямс, 2011. — 361 с.

6. Расмуссон, Дж. Гибкое управление IT-проектами. Руководство для настоящих самураев [Текст] / Дж. Расмуссон. — Вильямс, 2009. — 312 с.

7. Мартин, Р. Чистій код [Текст] / Р. Мартин. — Висконсин,

2010. — 201 с.

8. Поппедикс, К. Реализация разработки программного обеспечения: от концепции к деньгам [Текст] / К. Поппедикс. — Даллас, 2011. — 233 с.

9. Ларман, C. Масштабирование Agile разработки [Текст] / C. Ларман. — Чикаго, 2012. — 259 с.

10. Уэллс, Д. Производство без потерь. Канбан для рабочих [Текст] / Д. Уэллс. — NY, 2003. — 233 с.

адаптація процесів контролю команди розробників програм з використанням логічних правил

Дана робота описує основні принципи виробничого процесу у розробці програмних продуктів з використанням гнучких методологій, а також розкриває їх недоліки. Пропонується удосконалення SCRUM-методології шляхом використання логічних правил для автоматизованої адаптації процесів з метою підвищення ефективності управління процесом розробки. Рішення полягає у використанні двигунів бізнес-правила для управління обмеженнями бізнес-процесів.

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

Чалый Сергей Федорович, доктор технических наук, профессор, кафедра информационных управляющих систем, Харьковский национальный университет радиоэлектроники, Украина. Цимбаленко Роман Николаевич, кафедра информационных управляющих систем, Харьковский национальный университет радиоэлектроники, Украина, е-mail: gurut.91@gmail.com. Буцукина Инна Борисовна, кафедра экономической кибернетики, Харьковский национальный университет радиоэлектроники, Украина.

Чалий Сергій Федорович, доктор технічних наук, професор, кафедра інформаційних управляючих систем, Харківський національний університет радіоелектроніки, Україна. Цимбаленко Роман Миколайович, кафедра інформаційних управляючих систем, Харківський національний університет радіоелектроніки, Україна.

Буцукіна Інна Борисівна, кафедра економічної кібернетики, Харківський національний університет радіоелектроніки, Україна.

Chalyi Sergii, Kharkiv National University of Radio Electronics, Ukraina. Tsymbalenko Roman, Kharkiv National University of Radio Electronics, Ukraina, e-mail: gurut.91@gmail.com.

Butsukîna Inna, Kharkiv National University of Radio Electronics, Ukraina

УДК 004.048

ульяновська Ю. В. моделювання процесів пошуку

та класифікації службових документів в автоматизованих інформаційно-пошукових системах

У роботі розглядається вирішення важливої практичної задачі класифікації, пошуку та ранжу-вання службових документів. Виявлена й обґрунтована можливість застосування для вирішення завдання методу латентно-семантичного аналізу та аналізу взаємозв’язків Google Page Rank. Проведено моделювання за зазначеними методами.

Ключові слова: класифікація документів, латентно-семантичний аналіз

1. Вступ

Дослідження процесів класифікації та пошуку даних в системах обробки та передачі інформації є актуальним питанням для органів державної служби, які виконують фіскальні, контролюючі функції і робота яких

спрямована на запобігання порушенню законодавства. Використання передових інформаційних технологій з метою забезпечення оперативного і кваліфікованого реагування на події — це основи захисту інтересів держави. Ефективність прийняття управлінського рішення безпосередньо залежить від оперативності і своєчасності

TECHNOLOGY AUDiT AND PRODUCTiON RESERVES — № 3/1(11], 2013, © Ульяновська Ю. В.