CC BY
69
Информатика, вычислительная техника и управление
УДК 004.052
МУЛЬТИПАРАДИГМАЛЬНОСТЬ УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ ДЕФЕКТОВ ПРОГРАММНЫХ И АППАРАТНЫХ СИСТЕМ
А.О. Данилин, М.Д. Кол, Г.В. Петрухнова
В статье рассмотрен жизненный цикл дефектов в перспективе современной методологии управления инцидентами программных и аппаратных систем. Осуществлён анализ существующих на данный момент парадигм управления жизненным циклом дефектов. Предложен мультипарадигмальный подход при работе с базой данных дефектов
Ключевые слова: обеспечение качества, жизненный цикл дефектов, макро-описание, мультипарадигмальная методология, база данных дефектов
Введение. Дефектом принято считать изъян, некорректное поведение как программных, так и аппаратных систем на то или иное действие. Причиной возникновения дефектов могут быть ошибки программные, технические и архитектурные. К программным ошибкам следует относить все недочёты, связанные с несовершенством исходного кода конечного продукта.
Для предотвращения дефектов разработчики программного обеспечения (ПО) и специалисты в области схемотехники как правило используют одни и те же информационные средства, которые, по сути, относятся к категории систем, предназначенных для отслеживания ошибок. Главным компонентом таких систем является база данных дефектов (БДД), которая содержит сведения обо всех выявленных в процессе жизненного цикла продукта дефектах. Все записи представляются в текстовом виде. В большинстве случаев подобного функционала недостаточно, чтобы воспроизвести найденную проблему на стороне разработчика.
Анализ современной методологии управления жизненным циклом дефектов. Полный цикл жизнедеятельности дефектов и работы с БДД может быть представлен в виде универсальной пятиступенчатой структуры (рис. 1).
Рис. 1. Функциональная схема жизнедеятельности дефектов
Данилин Артем Олегович - ВГТУ, аспирант, e-mail: pushnir@rambler. ru
Кол Максим Дмитриевич - ВГТУ, магистрант, e-mail: kolmax93@gmail.com
Петрухнова Галина Викторовна - ВГТУ, канд. техн. наук, доцент, e-mail: petruhnova@pochta.ru
На представленном рисунке продемонстрировано взаимодействие компонентов для типового процесса обработки единичного дефекта. Приведённая схема представляет собой упрощённый механизм работы с БДД, и может быть применима как для единичного инцидента, так и для десятка выявленных дефектов. Несмотря на кажущуюся универсальность, данная модель взаимодействия имеет свои специфические недостатки, которые, так или иначе, сводятся к проблеме принятия решений непосредственно разработчиками. Так, после выявления дефекта (специалистом по качеству или разработчиком/схемотехником) ему назначается приоритет и определяется критичность. После того, как описание дефекта получил разработчик, начинается процесс воспроизведения инцидента. В случае если удалось добиться воспроизведения, разработчик переходит к устранению проблемы, по окончании чего снова проверяет дефект на воспроизводимость. В случае, когда дефект не удаётся повторить на стороне разработчика, он переходит в состояние «Закрыт», т.е. считается устранённым или отсутствующим. При этом на каждом из этапов затрачивается время, не относящиеся к технической стороне выявления или устранения дефекта, например, время создания первичного описания инцидента (1) складывается из времени воспроизведения выявленного дефекта (ТВ), времени непосредственной разработки описания (ТО) и времени настройки (ТН), затрачиваемое на создание описания конфигураций:
(1)
Аналогичным образом складывается время воспроизведения на стороне разработчика и время проверки устранения дефекта, рассчитываемые по формуле (2):
Тр/П = ТИ + ТВ + ТС , (2)
где ТИ - время идентификации, затрачиваемое на восприятие описания и понимание сути описываемой проблемы; ТС - время проверки соответствия реального поведения с описанием выявленного дефекта.
Описываемые выше формулы подтверждают, что происходит увеличение временных затрат на
Тс = ТВ + ТН + ТО
действия, которые по своей сути являются наименее трудоёмкими из всех задействованных в технологическом процессе разработки. Причина этого кроется в отсутствии оптимизации и нехватки возможностей существующих систем отслеживания дефектов.
Помимо неоправданного увеличения времени процессов разработки и обеспечения качества конечного продукта современная методология управления жизненным циклом дефектов (ЖЦД) не обладает способами контроля изменения состояния каждого из выявленных дефектов. Более того данные об устранённых дефектах, как правило, не фигурируют в дальнейшем технологическом процессе, что может провоцировать увеличение трудозатрат на те проблемы, которые были выявлены прежде. Так, среди средств микроэлектроники наглядно прослеживаются все описанные выше недостатки (табл. 1 и 2). Аналогичная ситуация обстоит с ПО в области информационных систем и вШ-разработок (табл. 3 и табл. 4).
Таблица 1
Конкретизация БДД проектов микроэлектроники на момент сдачи учитываемых при оставлении
статистики проектов.
Масштаб проектов (размер БДД) Активные дефекты на момент сдачи проекта Дефекты, открытые после устранения, %
Несколько десятков записей В диапазоне от 11,1% до 16,1% БДД: 8,3 АБДД: 72,7
Несколько сотен записей В диапазоне от 5,8% до 10,8% БДД: 0,4 АБДД: 40,4
Несколько тысяч записей В диапазоне от 11,9% до 16,9% БДД: 4,8 АБДД: 6,3
Таблица 2
Конкретизация БДД проектов микроэлектроники на момент сдачи учитываемых при оставлении
статистики проектов.
Масштаб проектов (размер БДД) Дефекты, требующие детализации, % Дефекты, которые не удалось повторить, %
Несколько десятков записей БДД: 5,5 АБДД:13,8 БДД: 5,5 АБДД: 13,8
Несколько сотен записей БДД: 0,5 АБДД: 4,9 БДД: 5,8 АБДД: 42,8
Несколько тысяч записей БДД: 0,5 АБДД: 8,5 БДД: 5,1 АБДД: 10
Приведённые данные табл. 1 и табл. 2 основаны на статистических сведениях проектов, введённых в эксплуатацию и используемых на предприятиях на территории России [2]. Были проанализированы проекты с количеством записей в БДД от нескольких десятков до десятка тысяч с длительностью жизненного цикла проектов до 7 лет. Указанные числовые значения после аббревиатуры БДД
показывают процентное соотношение к числу всех записей дефектов; значения после аббревиатуры АБДД - процентное соотношение к числу записей активных дефектов.
На примере проектов сферы микроэлектроники прослеживается следующая тенденция. Во-первых, количество активных дефектов на момент сдачи учитываемых при оставлении статистики проектов в среднем составляет десятую часть от общего числа выявленных. Указанный в табл. 1 диапазон значений зависит от процента «специальных» дефектов, т.е. тех дефектов, которые не могут быть исправлены в соответствие с внутренними политиками организации или имеют специфическую отметку в БДД. При этом для исследуемых групп проектов процент «специальных» дефектов составил 5%. Обращаясь к оценкам уровня качества [3], следует отметить, что технические проекты или ПО, содержащие 10% активных дефектов, могут удовлетворять критериям качества (так, с ними может согласиться заказчик), но при условии, что нет ни одного дефекта с приоритетом устранения выше среднего.
Таблица 3
Конкретизация БДД проектов разработки ПО.
Масштаб проектов (размер БДД) Активные дефекты на момент сдачи проекта Дефекты, открытые повторно, %
Несколько сотен записей В диапазоне от 1,3% до 6,3% БДД: 0,5 АБДД: 40,0
Несколько тысяч записей В диапазоне от 10,5% до 15,5% БДД: 2,8 АБДД: 26,6
Таблица 4 Конкретизация БДД проектов разработки ПО.
Масштаб проектов (размер БДД) Дефекты, требующие детализации, % Дефекты, которые не удалось повторить, %
Несколько сотен записей БДД: 0,7 АБДД:60,0 БДД: 5,1 АБДД: 40,0
Несколько тысяч записей БДД: 0,5 АБДД: 4,7 БДД: 5,1 АБДД: 48,5
При составлении статистики учитывались все группы дефектов (от низкого приоритета устранения до максимального). Во-вторых, следует отметить, что отсутствие устойчивых механизмов воспроизведения дефектов не позволяет в автоматическом режиме осуществлять их контроль, тем самым увеличивается время «жизни» дефектов. Подобная взаимосвязь формирует ложное представление о трудоёмкости исправления подобных инцидентов и не позволяет получить корректную статистику, как по работе сотрудников, так и по проекту в целом. В-третьих, определённый процент дефектов, требующих детализации, свидетельствует, что созданное описание инцидента оказалось вне понимания разработчика, а также что на попытку его воспроизведения было затрачено время, которое снизило веро-
ятность своевременной сдачи проекта или качества разработки как такового. Под открытыми повторно дефектами понимают инциденты активные на момент сдачи проекта, которые в ходе тестирования были устранены (или должны были быть устранены), но по каким-либо причинам возникли вновь.
На основании сведений приведённых выше таблиц очевидно, что количество инцидентов, которые не удалось повторить, превышает 5% (по отношению ко всей базе дефектов) и составляет практически половину активных дефектов как для проектов аппаратных систем, так и для ПО. Если учитывать, что ряд дефектов, которые не удалось воспроизвести, был автоматически исправлен в течение жизненного цикла разработки, то следует также обратить внимание на то, что инциденты могли всего лишь стать скрытыми или перерасти в более критичные.
Данные табл. 1 и 2 также свидетельствуют о наличии от 6,3% (для проектов с БДД в несколько тысяч записей) до 72,7% (для небольших проектов) повторно открытых дефектов в АБДД. Наличие подобных инцидентов значительно сказывается как на качестве конечного продукта (ставит под сомнения достигнутый уровень качества), так и на сроках сдачи проекта, увеличивая время разработки, на длительность периодов повторного выявления обнаруженных ранее дефектов, их поиска в БДД, что в полной мере свойственно парадигме текстового описания.
Перечисленные выше аргументы и недостатки современной методологии управления ЖЦД тормозят развитие сферы высоких технологий и препятствуют продуктивному менеджменту на проектах, связанных с разработкой программно-аппаратных систем. Переломить столь «порочный» путь дальнейшего развития возможно через изменение подхода к ведению и обработки данных БДД. Для этого следует пересмотреть существующую методологию в сторону расширения возможностей средств работы с БДД, их применения, а также использования конечных результатов в процессах управления и обеспечения качества.
Методология расчётов уровня качества ПО. Текстовое описание выявленных дефектов породило одну единственную парадигму в цепи управления ЖЦД. Её преимущества и недостатки были освещены выше. О мультипарадигмальности в отношении работы с дефектами целесообразно говорить при существовании нескольких идеологий или парадигм создания дефектов, их обработке в БДД и дальнейшем использовании после подтверждения или признания их наличия.
Следует также понимать, что каждый дефект может иметь множество зависимостей и способов воспроизведения, особенно если доступ к БДД конкретного проекта открыт для десятка, сотни или тысячи сотрудников. Учесть все особенности влияния возникших дефектов на разрабатываемый продукт возможно посредством детализации блока принятия решений. Подробный механизм обработки
дефектов [4] согласно методологии мультипарадиг-мального управления представлен на рис. 2.
Данный механизм включает в себя две многоступенчатые задачи (создание описание нового дефекта и корректировка уже созданного), причём между ними существует различие в области технической реализации системы обработки: с точки зрения подхода к созданию новой записи БДД - задействованы одни процессы, а с точки зрения приори-тизации устранения - совершенно иные. Так, при создании описания нового дефекта этап «Анализ и корректировка дефектов» может быть включён в блок «Разработка описания выявленного дефекта». В данном случае блок приоритизации устранения дефекта также будет относиться к этапу разработки описания. Здесь следует заметить, что приоритиза-ция устранения выявленных дефектов является не только гибким средством воздействия на БДД, но и настраиваемым инструментом, отвечающим требованиям конкретного проекта. Также при создании описания нового дефекта блок анализа и корректировки может следовать после приоритизации, которая находится в тесной зависимости от данного блока управления ЖЦД.
Рис. 2. Функциональная схема обработки единичного дефекта с учётом ситуационной вариативности и многопользовательского доступа к БДД
В таком случае любое изменение на этапе анализа и корректировки будет оказывать прямое воздействие на приоритизацию устранения дефектов. При установке же приоритетов ролью, имеющей расширенные функциональные возможности (по статусу), все изменения будут находиться в рамках назначенных приоритетов. Подобная обработка каждого созданного дефекта позволяет выделить
следующие рычаги управления блока «Анализ и корректировка дефектов»:
- настройки и данные приоритизации устранения дефекта, в частности, и на уровне проекта в целом;
- настройки и политики ролей как ответственных лиц по отношению к созданному инциденту, так и каждого участника проекта в совокупности;
- внутренние и глобальные настройки программной системы, используемой в качестве инструмента управления БДД.
Мультипарадигмальность управления жизненным циклом как программных, так и аппаратных систем может быть представлена средствами как ручного ввода описания выявленных инцидентов (текстовое описание), так и средствами видеофиксирования и создания последовательности воспроизведения посредством группы скриншотов, что позволяет лишь отойти от сложностей восприятия текстового материала и упростить механизм описания сложных ситуаций повтора. Наибольшую эффективность применения мультипарадигмального подхода к разработке предлагает способ выполнения макросов. Такой вариант позволяет в несколько раз увеличить эффективность обработки ситуаций, свидетельствующих о наличии одного или нескольких дефектов. Полученный программистом или специалистом по качеству сценарий может в дальнейшем использовать в процессах обеспечения и управления качеством, а также отладке и формировании тестовых БД. Создание подобных сценариев способно стать не только основой при формировании регрессионных тестов, но и базисом автоматизированных тестов, а также тест-кейсов для дымового тестирования.
Заключение. Применение мультипарадиг-мальной методологии при разработке программных и аппаратных комплексов способно повысить как эффективность контроля дефектов, так и качество готового продукта, превосходящее прогнозируемые расчёты. Об этом свидетельствует сокращение временных расходов и трудоёмкости разработки/тестирования за счёт применения информационных средств и специализированных программных инструментов, благодаря которым возможно наращивание потенциала для дымового и регрессионного тестирования, а также поддержка актуальности БДД на заранее заданном уровне.
Прогнозирование обозначенных перспектив от применения мультипарадигмальной методологии позволяет говорить о том, что роль автоматизации в цепи управления ЖЦД довольно велика. Полезный
Воронежский государственный технический университет
MULTI-PARADIGM CONCEPT LIFECYCLE MANAGEMENT OF DEFECTS OF HARDWARE AND
SOFTWARE SYSTEMS
A.O. Danilin, M.D. Kol, G.V. Petruhnova
Discusses the life cycle of defects in the prospects of modern methodology of incident management software and hardware
systems. It is carried out an analysis of the currently existing paradigms of life cycle management of defects. Proposed multi-
paradigmatic approach to work with the database of defects
эффект от внедрения данной методологии порождает ряд причин, по которым необходимо осуществление автоматизации на проектах разработки ПО:
- предотвращение ситуаций ложного обнаружения дефектов;
- использование универсального «языка» описания воспроизводимых дефектов с целью унификации БДД;
- сокращение времени поиска обнаруженных дефектов;
- сокращение трудоёмкости отладки;
- содержание базы дефектов в актуальном состоянии.
Останавливаясь на обозначенных выше направлениях автоматизации, следует сделать акцент, на формировании единообразия и унификации методов обнаружения/воспроизведения. Результатом применения мультипарадигмальной методологии может стать и создание интеллектуальных баз данных, но главное преимущество её заключается в улучшении уже существующего технологического производства в конкретной организации и разработке программных и аппаратных систем в целом.
Литература
1. Черников, Б.В. Управление качеством программного обеспечения [Текст] / Б.В. Черников. - М. : Форум, 2012. - 240 с.
2. Проекты - Разработка. [Электронный ресурс] : Режим доступа : http://www.radix-tools.ru/projects
3. Данилин, А.О. Формализация определения уровня качества программного обеспечения [Текст] / А.О. Данилин, Г.В. Петрухнова // Вестник Воронежского государственного технического университета. - 2014. - Т.10. 11. - № 5-1. - С. 52-56.
4. Данилин, А.О. Обеспечение надёжности программных решений [Текст] / А.О. Данилин, М.Д. Кол, Г.В. Петрухнова // Информатика: проблемы, методология, технологии : мат-лы XV Международной науч.-методич. конф. - Воронеж. - 2015. - Т. 2. - С. 265-268.
5. Подвальный, С.Л. Многоальтернативные системы: обзор и классификация / С.Л Подвальный // Системы управления и информационные технологии. - 2012. - Т. 48. - № 2. - С. 4-13.
6. Акинин, А.А. Сравнительная оценка вычислительных алгоритмов полиномиального преобразования булевых функций [Текст] / А.А. Акинин, С.Л. Подвальный // Вестник Воронежского государственного технического университета. - 2013. Т. 9. - № 1. - С. 31-35.
7. Тюрин, С.В. Способ тестопригодного проектирования логических преобразователей [Текст] / С.В. Тюрин, С. Л. Подвальный, Ю.С. Акинина // Проблемы разработки перспективных микро- и наноэлектронных систем (МЭС). - 2010. - № 1. - С. 36-41.
Key words: quality assurance, defect lifecycle, macro-description, a multi-paradigmatic methodology, database defects
