CC BY
77
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
УДК 004.78:005.7(075.8); 004.9:681.5; 621.3.068 Дата подачи статьи: 27.07.15
DOI: 10.15827/0236-235X. 112.126-132
ПОДХОД К РАЗВИТИЮ СИСТЕМЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ
ПРОГРАММНЫХ СРЕДСТВ
В.Ф. Корнюшко, д.т.н., профессор, зав. кафедрой (Московский государственный университет тонких химических технологий им. М.В. Ломоносова,
просп. Вернадского, 86, г. Москва, 119571, Россия);
А.В. Костров, д.т.н., профессор, akostrov@fambler.ru;
П.А. Породникова, аспирант, polina.porodnikova@mail.ru (Владимирский государственный университет им. Александра Григорьевича и Николая Григорьевича Столетовых:, ул. Горького, 87, г. Владимир, 600000, Россия)
В статье поставлена задача формирования подхода к управлению уровнем развития системы управления тестированием (СУТ) в составе системы управления бизнес-процессами разработки ПО в условиях проектного предприятия. Предложено выделить в составе бизнес-процессов разработки ПО бизнес-процесс тестирования, а в составе системы управления разработкой - подсистему управления тестированием как самостоятельные. Рассмотрены особенности организации тестирования в типовых моделях разработки ПО, для различных моделей разработки построены варианты организации выполнения по этапам основных процессов: рецензирование, Review (R); разработка тестов, Test Design (D); выполнение тестов, Test Execution (E); отчетность о тестировании, Test Report (O). Показана роль оценки уровня развития СУТ в процессах управления развитием, предложен подход к определению оценки уровня развития СУТ. Подход основан на определении оценки уровня развития СУТ в условиях различных моделей разработки ПО, прежде всего с использованием экспертной оценки. В качестве методической основы использована классификация стадий зрелости проектного управления. Рассмотрены особенности и возможности применения как прямой, так и многокритериальной экспертной оценки. Предложено отображать вербальное описание стадий зрелости СУТ множеством частных количественных критериев, часть из которых может определяться инструментальными методами; для оценки значений других предлагается проводить многокритериальную экспертизу с участием узких специалистов по профилю каждого из критериев. Рассмотрены варианты алгоритмов одноуровневого определения глобального критерия уровня развития на основе множества оценок частных критериев: вычисление длины вектора в эвклидовом пространстве и определение суммы взвешенных оценок частных критериев. Предложены двухуровневый вариант упорядочения частных критериев и соответствующие алгоритмы обработки множества их оценок, а также наглядная визуализация результатов оценки уровня развития СУТ. Разработанный на основе многокритериальной экспертной оценки подход позволяет определять степень зрелости СУТ ПО и целенаправленно управлять ее развитием.
Ключевые слова: оценка, подход, тестирование, глобальный критерий, частный критерий, уровень развития, программные средства, многокритериальная оценка, экспертная оценка, система управления, бизнес-процесс.
Разработка и производство программных средств (ПС) обрели все черты специальной отрасли, основу которой составляют соответствующие бизнес-процессы. От качества ПС существенно зависит эффективность выполнения бизнес-процессов во многих отраслях. Как следствие, в этой отрасли в полном объеме возникают и требуют решения задачи обеспечения и повышения эффективности или развития процессов и систем управления производственными бизнес-процессами. Управление бизнес-процессами становится все более сложным во всех сферах деятельности как по составу, так и функционально. Это обусловлено, прежде всего, усложнением выполняемых в составе бизнес-процесса задач, расширением их круга, повышением уровня требований к качеству их исполнения, причем число требований - критериев качества - постоянно растет. В основу современных систем управления положены информационные технологии (ИТ). Однако даже высокоэффективные ИТ не гарантируют успех управления, если бизнес-процессы и системы управления в целом как системы, обеспечивающие информационный менеджмент, не обладают уровнем развития,
достаточным для того, чтобы эффективно применять высокотехнологичные средства и процессы обработки информации (ОИ) [1-4].
Вследствие этого в отношении уровня развития систем управления может быть поставлена типовая задача управления, то есть задача целенаправленного формирования в системах управления заданного, или целевого, уровня развития: задание целевого уровня как стратегический план развития, оценка фактического уровня, сравнение его с целевым и внесение изменений в информационный менеджмент, то есть в систему управления. При этом должны быть формально поставлены и последовательно решены следующие задачи: определить понятие «уровень развития»; установить набор характеристик систем управления, определяющих ее уровень развития; описать связь значений характеристик системы с показателем уровня развития; сформировать воздействия на характеристики систем управления в нужном направлении. Специфика решения этих задач определяется условиями соответствующей сферы деятельности [2-4]. В настоящей статье эти вопросы рассматриваются применительно к особенностям управления разви-
126
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
тием системы управления тестированием при разработке ПС [5].
Тестирование ПС - это, с одной стороны, этап разработки ПО; с другой - специализированный бизнес-процесс в совокупности бизнес-процессов этой области деятельности. Понятие «тестирование ПС» определяется по-разному, однако бизнес-процессы тестирования по сути являются многофункциональными, а задачи управления развитием систем управления тестированием многокритериальными.
Как и в любой другой ИТ, в бизнес-процессе тестирования важным является экономический аспект, или эффективность ИТ: чем выше планируемые показатели качества тестирования, тем больше будут их трудоемкость и стоимость [6, 7]. Чем больше трудозатрат вкладывается в процесс тестирования, тем меньше ошибок в продукте остаются незамеченными. Однако совершенство в индустриальном программировании имеет пределы, которые прежде всего связаны с доступными затратами на получение программного продукта. В связи с этим определение трудоемкости бизнес-процесса тестирования конкретного продукта является оптимизационной задачей.
Стремление к уменьшению дефектов, или к повышению качества продукта, приводит к необходимости применения различных методов отладки и тестирования в процессе создания продукта. По мере обнаружения сложных ошибок и дефектов эффективность низкозатратных методов падает вместе с количеством обнаруживаемых ошибок. Отсюда следует, что каждый из методов тестирования имеет свою нишу, где он хорошо обнаруживает ошибки; вне этой ниши его эффективность падает. Поэтому необходимо совмещать различные методы и стратегии тестирования с целью обеспечения запланированного качества программного продукта при ограниченных затратах; это достигается при формировании адекватной системы управления тестированием.
Тестирование не является изолированным процессом, оно связано с другими работами по созданию ПС. Различные модели разработки ПС требуют различных подходов к тестированию.
Тестирование в каскадной модели. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, чтобы предоставить разработчикам свободу как можно лучшей с технической точки зрения их реализации.
Последовательная модель разработки (V-модель). Основная особенность V-модели - планомерное обеспечение тестирования на ранних стадиях проекта. V-модель является разновидностью каскадной модели: она также имеет последовательную структуру разработки, каждый новый шаг в ней начинается после завершения предыдущего.
Основная особенность V-модели заключается в том, что детализация проекта с течением времени возрастает при движении слева направо, и ни то, ни другое нельзя повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы. В модели в соответствии с введенными основными процессами выделены четыре уровня тестирования: компонентное (модульное), интеграционное, системное, приемочное.
Тестирование в спиральной модели. Спиральная модель - это модель, сочетающая в себе проектирование и постадийное прототипирование. В процессе создания ПС для каждого витка спирали заново проводится исследование, ставятся цели, определяются конкретные характеристики проекта и составляется план проведения работ для следующего витка.
Процессная модель тестирования. Основной процесс тестирования состоит из следующих направлений деятельности:
- планирование и управление;
- анализ и проектирование;
- внедрение и реализация;
- оценка критериев выхода и создание отчетов;
- действия по завершению тестов.
Несмотря на логическую последовательность,
действия в процессе могут накладываться друг на друга или происходить одновременно. Для конкретных системы и проекта обычно требуется адаптация этих направлений деятельности.
Функции процессной модели:
- определение, анализ, реинжиниринг и документирование производственных и организационных процессов отдела обеспечения качества;
- стандартизация процессов, ролей, артефактов и шаблонов, используемых в отделе;
- ускорение производственных процессов при сохранении высокого уровня качества;
- оптимизация производственных и организационных активностей, направленная на повышение их эффективности и сокращение трудозатрат отдела обеспечения качества.
Можно выделить шесть основных групп процессов тестирования (ГПТ), внутри которых можно произвести декомпозицию и выявить подпроцессы в рамках каждой ГПТ; рисунок 1 иллюстрирует декомпозицию ГПТ до подпроцессов.
Подход к оценке уровня развития системы управления тестированием
Тестирование - это подмножество, или поднабор, множества бизнес-процессов разработки ПО. Рассматривая тестирование как обособленный бизнес-процесс, в составе системы управления разработкой ПО в качестве подсистемы можно выделить систему управления тестированием, совершенствование которой обеспечивает повышение
127
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
03
S
т
со
03
03
со
I
03
ш
о
ю
0
о.
Группа 1 - Инструментальная поддержка процессов обеспечения качества
Выбор средств
инструментальной поддержки 1.1
Применение средств инструментальной поддержки 1.2
_т
Группа 2 - Планирование и контроль тестирования
Определение стратегии Создание плана Создание графика
тестирования 2.1 тестиро вания 2.2 тестирования 2.3
Рецензирование плана и графика тестирования 2.4
Контроль
выполнения
тестирования
2.5
1_
Создание тестовой модели
_____31
Создание и актуализация матрицы покрытия тестовых условий 3.2
Группа 3 - Тестовая модель
Рецензирование тестовой модели 3.3
Управление тестовой моделью 3.4
Управление тестовыми данными
3.5
Функционал ьное тестиро вание 4.1
LT
_1'
Грурпа 4 - Выполнение тестирования
Тестирование Повторное
НФТ тестирование
4.2 4.3
Регрессионное Автоматизированное Статическое
тестирование тестирование тестирование
4.4 4.5 4.6
Группа 5 - Отчетность тестирования
Оперативная отчетность Итоговая отчетность
о тестировании 5.1 о тестировании 5.2
Г руппа 6 - Управление изменениями
L
Актуализация знаний о проектных требованиях 6.1
Управление дефектами
6.2
Д
д
го
со
с5
0
т
пз
1
пз
со
о
ю
0
о.
н
о;
го
?
2 о; о. о со
I—
го
Ц
со
о
>
0
сЗ
S
О
Рис. 1. Процессная модель тестирования Fig. 1. Testing process model
качества выполнения бизнес-процесса тестирования. В задаче управления развитием системы управления тестированием, то есть в задаче целенаправленного формирования в системе управления тестированием заданного, или целевого, уровня развития, важное место занимает оценка фактического значения уровня развития. В качестве методической основы такой оценки в литературе достаточно широко используются классификации уровня развития или стадий зрелости (Maturity Model, MM - модель зрелости, англ.) различных систем и процессов [1, 6].
Известные модели оценки зрелости процессов разработки ПО - Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), Test Maturity Model (TMM) - относятся к оценке процессов разработки ПО в целом, не выделяя и не оценивая отдельно систему управления тестированием. В настоящей работе в качестве методической основы оценки уровня развития, или стадии зрелости, систем управления тестированием предпринята попытка применения в условиях тестирования ПС классификации уровня развития проектного менеджмента IT Portofolio Management Maturity Model по М. Джеффри, которая содержит описание
четырех уровней развития по мере их повышения: случайный, определенный, управляемый, согласованный [6].
Данная модель носит вербальный характер и основана на качественных оценках характеристик процессов и систем управления, оценивая которые, можно сделать заключение о том, на какой стадии находится рассматриваемая система. Ввиду качественного характера вербальной модели в этих условиях естественным является использование экспертной оценки.
Вербальную классификацию стадий зрелости как множество уровней развития можно представить в виде формальной модели - множества MM, каждому из элементов SM | i = 1,4 которого ставится в соответствие некий глобальный критерий GM; его значение определяет уровень развития; по существу это отображение множества классов на пространство значений глобального критерия:
MM = {SM | i = 14} f° > GM е 14 . (1)
Операция отображения f G может быть реализована в виде прямой экспертной оценки (ПЭО), когда эксперт прямо называет номер класса в качестве оценки [6]. В сложных условиях, характерных
128
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
для такой экспертизы, обычно достаточно трудно найти компетентного эксперта, оценка которого вызывает безоговорочное доверие.
Степень доверия к оценке повышается при проведении коллективной экспертизы. Однако при участии в экспертизе нескольких экспертов оценки могут относиться к разным классам, из-за чего при обработке результатов опроса экспертов будут получены дробные значения классов. Поэтому значение глобального критерия, получаемое в результате экспертизы, будет принадлежать интервалу
0,4, то есть будет иметь вид числа GM30 е 0,4 . Таким образом, окончательное определение уровня развития - отображение значения глобального критерия на множество классов
ОМэо е 0,4 ——> SM, i = 14, (2)
необязательно может давать целочисленную оценку, могут использоваться и дробные числа; при этом шкала классов служит как бы «каркасом» модели при реализации отображения fS.
Однако на практике увеличить число экспертов сложно, поскольку безоговорочно авторитетных пока мало. К тому же такие эксперты требуют высокой оплаты; для многих компаний, прежде всего в сфере малого и среднего бизнеса, проведение экспертизы будет неподъемной затратой. Для решения этой проблемы предлагается метод многокритериальной экспертной оценки (МЭО): на основе вербального описания стадии зрелости вводятся количественные частные критерии PM, отражающие развитие того или иного качества системы; значение каждого из критериев оценивается соответствующим профессиональным экспертом или измеряется; на основании их оценок уже расчетным путем определяется некий глобальный критерий -МЭО стадии зрелости 0^0, значение которой показывает уровень развития [6]. При этом вербальная классификация MM отображается множеством частных критериев PM:
mm = {sf | i = 1~4} — > pM =
г —л (3)
= {PjM, Dp\j = l, n},
где f P - функция отображения; N - число введенных частных критериев; Dp - множество атрибутов частного критерия (наименование, описание и т.д.).
Экспертиза осуществляется в два этапа. На первом формируется состав множества частных критериев, его полнота и адекватность в отношении вербального описания определяются компетентностью состава привлеченных экспертов. Для повышения единообразия множество критериев целесообразно упорядочить следующим образом:
- все критерии нормировать и привести в диапазон значений [0, 1]: 0 - соответствующее свойство не проявляется, 1 - свойство проявляется в максимальной степени;
- критерии, отражающие в вербальной классификации убывающие свойства (недостатки), инвертировать и обратить в противоположные растущие свойства (достоинства).
На втором этапе экспертизы интервал значений [0, 1] для каждого из критериев Pf представляется
в виде строки, состоящей из 4 субинтервалов по числу уровней развития; при этом границы субинтервалов определяются экспертами по каждому из критериев. Следует отметить, что границы субинтервалов для разных критериев могут быть различными, то есть разбиение интервала [0, 1] в общем случае неравномерно. Таким образом, состав множества критериев как структурная основа модели уровня развития принимает вид таблицы 1.
Таблица 1
Состав множества критериев
Table 1
The structure of the set of criteria
Критерий Уровень развития
1 2 3 4
PM
Pnm
Оценка уровня развития формируется отображением множества частных критериев на значение глобального критерия:
PM = {pM,Dp \ j = Щ—^ОМэо , (4)
где операция отображения f PG осуществляется на основе того или иного расчетного алгоритма; при этом могут использоваться различные подходы и методы. Далее для определения оценки уровня развития полученное значение G^0 отображается на множество уровней развития sf \i = l,Iм по шкале значений G^0:
G’Msc SM\i = 14, (5)
для чего должна быть построена шкала соответствия значений G M и номеров уровней развития. Иначе говоря, для применения (4) и (5) необходимо разбить интервал возможных значений GM на
4 субинтервала и присвоить им номера уровней развития от 1 до 4. Такая шкала строится на основе граничных значений частных критериев с использованием алгоритма, положенного в основу операции отображения fPG. При этом будет осуществлен переход от вербального описания системы управления тестированием к формированию множества критериев системы и получению числового показателя стадии зрелости.
В условиях малого проектного предприятия применительно к специфике одного из проектов ПО сформировано множество N=12 частных критериев; для всех критериев определены шкалы из 4 субинтервалов (см. табл. 2).
129
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
Структурная основа модели уровня развития A common framework of a development level model
Таблица 2 Table 2
Критерий Вес Значение критерия по стадиям зрелости
1 2 3 4
Группа 1. Проектные характеристики
Планирование тестирования 0,2 0 [0;0,7] [0,7; 0,8] [0,8; 1]
Бюджет тестирования 0,3 [0; 0,3] [0,3; 0,7] [0,7; 0,8] [0,8; 1]
Финансовые параметры 0,4 0 [0; 0,7] [0,7; 0,9] [0,9; 1]
Отчетность 0,1 0 [0; 0,5] [0,5; 0,7] [0,7; 1]
Границы субинтервалов ОГК по группе 1 - CrM [0; 0,09] [0,7; 0,68] [0,68; 0,83] [0,83; 1]
Группа 2. Организационные характеристики
Роль процесса обеспечения качества в проекте 0,2 0 [0; 0,5] [0,5; 0,7] [0,7; 1]
Место ООК в организационной структуре предприятия 0,2 0 [0; 0,6] [0,6; 0,7] [0,7; 1]
Персонал ООК 0,4 [0; 0,5] [0,5; 0,6] [0,6; 0,8] [0,8; 1]
Ценность данных и знаний для организации 0,2 0 [0; 0,5] [0,5; 0,7] [0,7; 1]
Границы субинтервалов ОГК по группе 2 - СГМ [0; 0,20] [0,20; 0,56] [0,56; 0,74] [0,74; 1]
Группа 3. Общие характеристики
Обмен информацией 0,2 [0; 0,4] [0,4; 0,5] [0,5; 0,7] [0,7; 1]
Анализ деятельности 0,2 [0; 0,3] [0,3; 0,4] [0,4; 0,7] [0,7; 1]
Производственные процессы 0,5 0 [0; 0,5] [0,5; 0,8] [0,8; 1]
Инновационная деятельность 0,1 0 0 [0; 0,5] [0,5; 1]
Границы субинтервалов ОГК по группе 3 - CrM [0; 0,14] [0,14; 0,43] [0,43; 0,73] [0,73; 1]
Радиусы граничных сфер GM303 [0; 0,26] [0,26; 0,98] [0,98; 1,33] [1,33; 1,73]
Для применения (4) и (5) на множестве полученных значений частных критериев, или для реализации операций отображения fPG и fS, необходимо задать вид этих операций, то есть сформировать алгоритм расчета количественной оценки уровня развития системы управления тестированием [6].
Так, в качестве глобального критерия может использоваться длина вектора в эвклидовом пространстве, базисом которого являются значения частных критериев, то есть будет
ОМ™ =||(j )2. (6)
В качестве алгоритма определения глобального критерия может использоваться также взвешенное суммирование значений частных критериев:
12
ОМэо2 = ЕФj • PM , (7)
J=1
где фу, j = 1,12 - весовой коэффициент, отражающий значимость j-го критерия в составе множества частных критериев, конкретные значения фу определяются экспертным путем; на сумму весовых коэффициентов налагается условие нормировки:
12
!ф j = 1. (8)
j=1
Правда, наглядность таких глобальных критериев - вектора в 12-мерном пространстве и суммы взвешенных 12 слагаемых - невелика. В связи с этим множество частных критериев целесообразно представить в виде дерева, разбив его на группы по тем или иным признакам и сохраняя при этом наглядность как по числу критериев в группах, так и по числу групп. В этом случае алгоритм определения глобального критерия становится двухуровневым: сначала определяется в каждой группе обобщенный групповой критерий (ОГК), на основе множества которых далее определяется глобальный критерий. При этом на уровнях могут использоваться разные алгоритмы.
На основе исследования и анализа практики рассматриваемого проектного предприятия, процессной модели разработки ПС на предприятии, в частности, в сфере обеспечения качества программных продуктов в составе множества из 12 частных критериев, характеризующих деятельность отдела обеспечения качества, сформированы следующие группы характеристик - частных критериев по 4 критерия в каждой (см. табл. 2): проектные, организационные, общие.
Далее в условиях рассматриваемого предприятия в качестве алгоритма расчета ОГК использу-
130
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
ется взвешенное суммирование значений частных критериев, включенных в группу:
CrT =!aft • Pf, l = 1Д (9)
k=1
где ait - весовые коэффициенты, отражающие значимость k-го критерия в составе множества частных критериев i-й группы, конкретные значения at определяются экспертным путем; на сумму весовых коэффициентов в группе налагается условие нормировки:
£aft = 1, l = 13 . (10)
k=1
В этих условиях значения всех обобщенных групповых критериев Grf, l = 1,3, попадают в интервал [0, 1]. Для каждого Grf, I = 1,3, на основе алгоритма (9) с учетом условия нормировки (12) интервал [0,1] разделен на 4 субинтервала, отражающих стадии зрелости в отношении данного ОГК (см. табл. 2).
Далее по аналогии с (5) выполняется отображение множества обобщенных групповых критериев на значение глобального критерия:
G, Df \1 = 13} J—^Gfc, (11)
где DGr - множество атрибутов ОГК (наименование, описание и т.д.); fGrG - функция отображения; при этом значение глобального критерия GM определяется расчетным путем с использованием алгоритма, положенного в основу операции отображения fGrG. Интервал возможных значений глобального критерия G M разбивается на 4 субин-
тервала, отражающих стадии зрелости системы, с использованием алгоритма отображения f GrG.
В условиях рассматриваемого предприятия в качестве глобального критерия используется длина вектора в эвклидовом пространстве, базисом которого являются значения ОГК, то есть в данном случае глобальный критерий имеет вид
G"03 =Ji(GnM)2 . (12)
С использованием этого алгоритма на основе граничных значений субинтервалов на шкалах ОГК интервал возможных значений глобального критерия Gf^3 разбивается на 4 субинтервала. Таким образом, оценка уровня развития системы определяется по шкале соответствия субинтервалов значений глобального критерия Gf и шкалы уровней зрелости, то есть выполняется отображение значения GM303 на шкалу классов:
Gfo Sf\i = 1,4, (13)
где f S - функция отображения, заключающаяся в применении правила соотнесения шкал значений
Gf^3 и номеров классов Sf \ i = 1,4.
Точность экспертизы повышается при увеличении числа частных критериев N, что характеризует более детальное отражение вербального описания множеством количественно оцениваемых, пусть и экспертным путем, величин.
Здесь важно подчеркнуть, что для оценки того или иного частного критерия существенно проще найти компетентного эксперта, то есть узкого специалиста по данному критерию, оценка которого не подвергается сомнению и от которого не требуется столь широкая эрудиция, как от эксперта при проведении ПЭО.
В качестве визуальной иллюстрации модели оценки зрелости управления тестированием построена номограмма (рис. 2), на которой представлены области в пространстве глобальных критериев, отражающие все стадии зрелости.
В порядке управления развитием систем управления тестированием полученное фактическое значение уровня развития сравнивается с его целевым значением. В случае, если целевой уровень не достигнут, необходимо выяснить, какие частные критерии вносят наибольший вклад в отставание в развитии, и провести мероприятия, обеспечивающие преодоление этого отставания. При этом важно оценить ресурсоемкость и стоимость соответствующих мероприятий, то есть эффективность процессов управления [7].
Таким образом, в статье поставлена задача формирования подхода к управлению уровнем развития системы управления тестированием в составе системы управления бизнес-процессами разработки ПС в условиях проектного предприятия. Подход основан на определении оценки уровня развития систем управления тестированием в условиях различных моделей разработки ПО, прежде всего с использованием многокритериальной экс-
131
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
пертной оценки. В качестве методической основы использована классификация стадий зрелости проектного управления. Предложено отображать вербальное описание стадий зрелости множеством частных количественных критериев, для оценки значений которых предлагается проводить многокритериальную экспертизу. Рассмотрены варианты алгоритмов по этапам определения глобального критерия уровня развития. Предложенный на основе многокритериальной экспертной оценки подход позволяет оценивать степень зрелости систем управления тестированием ПО и целенаправленно управлять ее развитием.
Литература
1. Жданович О.А., Корнюшко В.Ф., Иванчук И.С., Костров А.В. Степень готовности системы управления бизнес-про-
цессами к внедрению информационных технологий (методика оценки) // Прикладная информатика. № 2 (50). 2014. С. 14-22.
2. Мухин К.О., Костров А.В. Описание моделей базовых элементов объектно-ориентированной модели производственных процессов для нахождения оптимального управления // Наукоемкие технологии. 2013. Т. 14. № 4. С. 62-67.
3. Мухин К.О., Костров А.В. Метод применения объектно-ориентированных имитационных моделей для управления сложными производственными процессами // Нелинейный мир. 2013. Т. 11. № 5. С. 332-337.
4. Решетников В.Н. Космические телекоммуникации. Системы спутниковой связи и навигации. СПб, 2010. 134 с.
5. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения; [пер. с англ.]. СПб: Питер, 2002. 496 с.
6. Костров А.В., Егорова И.В., Жданович О.А. Подход к управлению уровнем развития информационных систем // Динамика сложных систем. 2015. Т. 9. № 1. C. 24-31.
7. Костров А.В., Матвеев Д.А. Информационный менеджмент. Оценка эффективности информационных систем. Владимир: Изд-во ВлГУ, 2004. 116 с.
DOI: 10.15827/0236-235X.112.126-132 Received 06.07.15
AN APPROACH TO SOFTWARE TESTING MANAGEMENT SYSTEM DEVELOPMENT Kornyushko V.F., Dr.Sc. (Engineering), Professor, Head of Chair (Lomonosov Moscow State University of Fine Chemical Technologies,
Vernadsky Ave. 86, Moscow, 119571, Russian Federation);
Kostrov A. V., Dr.Sc. (Engineering), Professor, akostrov@rambler.ru;
Porodnikova P.A., Postgraduate Student, polina.porodnikova@mail.ru (Alexander and Nikolay Stoletovs Vladimir State University,
Gorkogo St. 87, г. Vladimir, 600000, Russian Federation)
Abstract. The paper considers the problem of creating an approach to testing management system (TMS) development control as a part of software development business process management system in a project company. The authors suggest to separate software testing process as an independent business process, so software development management system has a testing management subsystem. The paper reviews the features of testing management in typical software development models. There are the variants of basic testing processes implementation: Review (R); Test Design (D); Test Execution (E); Test Report (O). The article shows the role of TMS development evaluation in the development management processes, and provides the approach to its evaluation. The approach is based on TMS development evaluation for different software development models, expert evaluation in particular. Classification of project management maturity stages is used as a methodological basis. The paper considers the features and applicability of both direct and multi-criteria expert evaluation. The authors suggest displaying a verbal description of TMS maturity stages as a set of private quantitative criteria; some of them can be determined by instrumental methods. To evaluate the others it is proposed to make multi-criteria assessment with the assistance of field experts according to each criterion. The paper considers the variants of single-level algorithms to determine a development level global criteria based on multiple assessments of partial criteria: calculation of the length of the vector in Euclidean space and determining the amount of the weighted assessments of partial criteria. The paper proposes a two-level ordering of the partial criteria and corresponding algorithms for processing their set of estimates, as well as a visualization of the results of the TMS development evaluation. The described approach allows assessing the software TMS maturity and managing its development.
Keywords: estimate, approach, testing, global criterion, partial criterion, development level, software, multi-criteria estimate, expert estimate, management system, business process.
References
1. Zhdanovich O.A., Kornyushko V.F., Ivanchuk I.S., Kostrov A.V. The estimate methodics of business process management system readiness level to information technology introduction. Prikladnaya informatika [Applied Informatics]. 2014, no. 2 (50), pp. 14-22 (in Russ.).
2. Mukhin K.O., Kostrov A.V. Model description of the basic elements of object-oriented model of the production process for determining optimal control. Naukoemkie tekhnologii [Science Intensive Technologies]. 2013, vol. 14, no. 4, pp. 62-67 (in Russ.).
3. Mukhin K.O., Kostrov A.V. The Method of a object-oriented simulation models Application for the complex production process Control. Nelineyny mir [Nonlinear World]. 2013, vol. 11, no. 5, pp. 332-337 (in Russ.).
4. Reshetnikov V.N. Kosmicheskie telekommunikatsii. Sistemy sputnikovoy svyazi i navigatsii [Space telecommunications. Satellite Communication Systems and Navigation]. St.-Petersburg, 2010, 134 p.
5. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language. User Guide. Addison Wesley Publ., 1999, 482 p. (Russ. ed.: St.-Petersburg, Piter Publ., 2002, 496 p.).
6. Kostrov A.V., Egorova I.V., Zhdanovich O.A. The approach to information system development level control. Dina-mika slozhnykh system [Dynamics of Complex Systems]. 2015, vol. 9, no. 1, pp. 24-31 (in Russ.).
7. Kostrov A.V., Matveev D.A. Informatsionny menedzhment. Otsenka effektivnosti informatsionnykh sistem [Information management. Information system performance evaluation]. Vladimir, VlSU Publ., 2004, 116 p.
132
