CC BY
9Решетневские чтения
среднюю точность вычислений при близких скоростях вычислений.
Таким образом, ничуть не отрицая достоинства и возможности чисто технологических улучшений, авторы обращают внимание читателей на возрастающую значимость системного подхода к проблеме по-
вышения производительности, особенно для предмет ной области ВИСУ.
Библиографическая ссылка
1. Кофман А. Введение в теорию нечетких множеств. М. : Радио и связь, 1982.
■
Альтернативный
а б
Диаграммы сравнения реализаций алгоритмов по скорости (а) и точности (б)
A. I. Bratolyubova, A. E. Vasiliev, A. V. Dontsova, A. I. Murgo Saint-Petersburg State Polytechnical University, Russia, Saint-Petersburg
ALGORITHMS OF FUZZY PROCESSING FOR EMBEDDED MCU-BASED CONTROL SYSTEMS
The authors consider the problem of algorithmic approach to increase of effectiveness of the subsystems of fuzzy algorithms for embedded applications, and offer a new algorithm for implementation of the mechanism of fuzzy inference, analysis of achieved performance.
© Братолюбова А. И., Васильев А. Е., Донцова А. В., Мурго А. И., 2011
УДК 004.413
Е. Н. Булакина, А. В. Кетов, П. В. Лебедкин, Д. О. Почуфаров, О. Н. Булакина Сибирский федеральный университет, Россия, Красноярск
УПРАВЛЕНИЕ ПРАКТИКАМИ В ГИБКОМ ПРОЦЕССЕ КАК СРЕДСТВО ПОВЫШЕНИЯ ВЗАИМОДЕЙСТВИЯ В КОМАНДЕ РАЗРАБОТЧИКОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Практики гибких методологий, например Daily Scrum или ретроспектива, иногда позволяют вскрыть причины возникновения ошибок, но ввиду своей ориентированности на текущие проблемы в рамках одной итерации они редко позволяют выявить ошибки, связанные с интеграциями, которые проходят по окончанию нескольких итераций. Проблему также усугубляет отсутствие или ограниченное применение архитектурного планирования во многих гибких методологиях.
В настоящее время существует множество программных продуктов, предназначенных для повышения эффективности процесса создания программного обеспечения (ПО). Однако этот процесс является во многом творческим процессом. Его невозможно пол -ностью строго формализовать, как невозможно раз -решать возникающие проблемы, полагаясь только на технические средства и не учитывая особенностей социального взаимодействия в команде разработчи-
ков ПО и индивидуальных особенностей каждого из них. Всегда существует множество решений одной и той же задачи, которые обладают различной эффективностью, сложностью интеграции и стоимостью сопровождения. Отдельно следует рассматривать ошибки интеграции, так как эти ошибки являются одними из самых дорогих и сложных в прогнозировании. Они возникают, когда два или более корректных компонента системы, полностью работоспособных и
Информационно-управляющие системы
протестированных, начинают взаимодействовать и поведение одних не соответствует поведению, ожидаемому другими. Ошибки интеграции, помимо собственного негативного действия, могут спровоцировать еще два вида ошибок: системные и модульные, большинство из которых легко находятся модульным тестированием и тестированием интеграции.
Основными причинами возникновения ошибок интеграции и спровоцированных ими ошибок других типов являются:
- недостаточное планирование интеграции на стадии проектирования;
- недостаточное общение между группами разработчиков, реализующими различные компоненты ПО;
- различия в применяемых среди разработчиков шаблонах проектирования;
- отсутствие видения полной картины проекта.
Некоторые практики гибких методологий, как, например, Daily Scrum или ретроспектива, иногда позволяют вскрыть причины возникновения таких ошибок, но ввиду своей ориентированности на текущие проблемы в рамках одной итерации они редко позволяют выявить ошибки, связанные с интеграцией, которые проходят по окончанию нескольких итераций. Проблему выявления этих ошибок также усугубляет отсутствие или ограниченное применение архитектурного планирования во многих гибких методологиях. Особенно остро эта проблема встает в тех проектах, в которых невозможно организовать четкий итеративный процесс ввиду постоянно меняющихся задач, требований и приоритетов.
Авторами было проведено исследование работы двух команд разработчиков программного обеспечения, к которым предъявлялись одинаковые требования. Рабочий процесс первой команды не имел выраженной методологии и был близок к тому, что разработчики называют Code & Fix. Рабочий процесс второй команды основан на практиках и принципах Lean, т. е. бережливого производства.
Обе команды работали в условиях непрогнозируемого появления задач, внезапного изменения приоритетов, жестких ограничений по времени, интеграции несколько релизов за день, т. е. в условиях, не позволяющих организовать четкий и отлаженный итеративный процесс. При этом команда, использующая практики и принципы Lean, очень редко не укладывалась в сроки и испытывала намного меньше проблем с ошибками интеграции.
Авторами был проведен анализ рабочих процессов в этих командах и предпринята попытка внедрить практики и принципы Lean, в результате чего было доказано, что полноценное и плодотворное общение внутри команды возможно только при принятии общих ценностей и основных принципов гибких методологий. Однако в условиях стрессовой ситуации, ожидания существенного роста производительности, пропорционального увеличению количества членов команды, и т. п., обучение разработчиков новой методологии не представлялось возможным. На основании этого было принято решение создать алгоритм для успешной интеграции, не требующий больших затрат на внедрение, и упростить процесс обучения и эффективной передачи практик между разработчиками ПО.
Исходя из наблюдений за процессом интеграции был создан пакет хороших и плохих практик, обязательных для ознакомления разработчиками. Это решение дало определенный положительный результат, но несколько ниже ожидаемого, поскольку пакет практик довольно быстро вышел из регулярного обращения и вспоминали о нем только тогда, когда кто-нибудь из разработчиков совершал грубую ошибку [1]. Кроме того, в большинстве случаев не было личной мотивации для того, чтобы пересмотреть этот пакет еще раз или зайти на корпоративный сетевой ресурс для получения нужной информации.
Таким образом, задача состоит не в том, чтобы разработчики были знакомы с хорошими и плохими практиками, а в том, чтобы они применяли эти практики в своей работе. После создания алгоритма для успешной интеграции, внедрения практики мягкого ознакомления с ним, формирования пакета хороших практик лидеру команды необходимо систематически, но ненавязчиво, в виде советов и рекомендаций, напоминать разработчикам о последовательности действий для того, чтобы эти практики превратились в хорошие привычки. Систематическое формирование подобных привычек требует от лидера и старших разработчиков соответствующих коммуникационных проявлений, что позволит значительно сократить количество ошибок, особенно тех, которые допускаются новыми сотрудниками. В дальнейшем при таком подходе практики гибких методологий смогут надежно закрепиться в командах разработчиков ПО.
Библиографическая ссылка
1. Мэйндональд Дж. Вычислительные алгоритмы в прикладной математике. М. : Статистика, 2005.
E. N. Bulakina, A. V. Ketov, P. V. Lebedkin, D. O. Pachufarov, O. N. Bulakina Siberian Federal University, Russia, Krasnoyarsk
MANAGEMENT OF EXPERTS IN FLEXIBLE PROCESS AS MEANS OF INCREASE OF INTERACTION IN THE COMMAND OF SOFTWARE DEVELOPERS
Experts flexible методологий as, for example, Daily Scrum or a retrospective show sometimes allow to open the reasons of occurrence of errors, but in view of the on current problems within the limits of one iteration similar experts seldom allow to reveal errors connected with интеграциями which pass on the termination of several iterations. As aggravates a problem absence or the limited application of architectural planning in many flexible.
© Булакина Е. Н., Кетов А. В., Лебедкин П. В., Почуфаров Д. О., Булакина О. Н., 2011
