МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение

высшего образования «УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» 

    

Т. В. Афанасьева А. Н. Афанасьев

 

Основы управления качеством программных средств 

Учебное пособие

 

            

Ульяновск УлГТУ 2017

   

УДК 004.8 (075) ББК 32.813 я7 А 94   

Рецензенты: профессор кафедры «Информационные технологии» УлГУ профессор, д-р техн. наук И. В. Семушин; кафедра «Телекоммуникационные технологии и сети» УлГУ.

Утверждено редакционно­издательским советом  

Ульяновского государственного технического университета в качестве учебного пособия 

         

Афанасьева, Татьяна Васильевна Основы управлеия качеством программных средств : учебное

пособие / Т. В. Афанасьева, А. Н. Афанасьев. – Ульяновск : УлГТУ, 2017. – 85 с.

ISBN 978-5-9795-1687-5 Содержание пособия включает изложение основ в области управления

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

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

                                                                                                     УДК 004.8 (075) 

          ББК 32.813 я7  

 © Афанасьева Т. В.,

Афанасьев А. Н., 2017 ISBN 978-5-9795-1687-5 © Оформление. УлГТУ, 2017

А 94

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ .......................................................................................................... 4 ГЛАВА 1. ОСНОВЫ КАЧЕСТВА ПРОГРАММНЫХ СИСТЕМ .................. 7

1.1. Качество как объект измерения .............................................................. 7 1.2. Структурно-функциональная модель оценивания качества

программных средств ............................................................................ 11 1.3. Функции агрегации показателей качества ......................................... 18 1.4. Контрольные вопросы .......................................................................... 20

ГЛАВА 2. ПРОЦЕССЫ ОЦЕНИВАНИЯ КАЧЕСТВА ПС ......................... 21 2.1. Основы процесса оценивания качества ПС ........................................ 21 2.2. Оценивание ПС в стандартизированных процессах управления

качеством ........................................................................................................... 25 2.3. Процессы обеспечения и подтверждения качества ........................... 26 2.4. Контрольные вопросы .......................................................................... 32

ГЛАВА 3. МЕТОДОЛОГИИ УПРАВЛЕНИЯ КАЧЕСТВОМ ПС .............. 33 3.1. Классификация методологий управления качеством ПС ................. 33 3.2. Модель зрелости организации ............................................................. 36 3.3. Контрольные вопросы .......................................................................... 44

ГЛАВА 4. ПРАКТИКИ УПРАВЛЕНИЯ И ОЦЕНИВАНИЯ ПРОЦЕССАМИ РАЗРАБОТКИ ПС ............................................................... 46

4.1. Показатели и метрики в управлении качеством разработки ПС ..... 47 4.2. Инструменты анализа вариабельности критичных метрик ............. 53 4.3. Контрольные карты в управлении вариабельностью

критичных факторов ........................................................................................ 58 4.4. Контрольные вопросы ......................................................................... 60

ЗАКЛЮЧЕНИЕ ................................................................................................ 62 БИБЛИОГРАФИЧЕСКИЙ СПИСОК ............................................................ 63 Приложение 1. .................................................................................................. 66 Приложение 2. .................................................................................................. 67 Приложение 3. .................................................................................................. 68 Приложение 4. .................................................................................................. 83 Приложение 5. .................................................................................................. 85

3

ВВЕДЕНИЕ

Скорость изменения компьютерных и программных технологий

создает потребность в новых и эволюционирующих программных

продуктах.

Пользовательские ожидания и конкурентная борьба, возникающие в

таких условиях, существенно затрудняют возможность выпускать

качественное программное обеспечение (ПО) в приемлемые сроки.

Программная инженерия – это наука, которая занимается

разработкой систематических моделей и надежных методов производства

высококачественного программного обеспечения.

Разработка программных средств (ПС) успешна, если в ней за

запланированные время и стоимость качественно материализована

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

приводящие к снижению качества разрабатываемого программного

продукта и «неуспешности» проекта в целом. Причинами таких проблем

являются:

• Недостаточно эффективное использование бюджета.

• Неполная и некачественная функциональность.

• Малоэффективный тайм-менеджмент.

• Изменение требований и функционала.

• Изменение состава разработчиков и/или отсутствие корпоративной

культуры.

• Недостаточная коммуникация с заказчиком.

• Отсутствие необходимых ресурсов и опыта.

• Неполнота планирования. «Забытые» работы.

• Ошибки в оценках трудоемкостей и сроков работ.

4

Для управления такими проблемами активно развивается направ-

ление управления проектами, в рамках которого управление качеством

программных средств занимает важное место, так как никому не нужен

продукт низкого качества, даже если он произведен в рамках бюджета и

лимита времени.

Управление качеством программного обеспечения нацелено на

повышение качества конечных продуктов, являющихся результатом

коллективной деятельности специалистов в области программной

инженерии. Это повышение качества представляет собой непрерывный

процесс, на первом этапе который сфокусирован на уменьшение риска

«неуспешности» производства и обеспечение постоянного повышения

качества программных средств.

Любое управление основывается на оценивании и анализе

исторически накопленных данных, причем оценивание первично и зависит

от выбора оцениваемых характеристик.

В настоящее время накоплен опыт в применении различных практик

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

формализованному подходу, ведущему к автоматизации процессов

управления качеством программных средств.

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

три основных аспекта для построения моделей оценивания и управления

качества программных средств:

1. Качество результата R. Под результатом будем понимать

программное средство, созданное в некоторой среде и в

исследуемый временной период.

2. Качество системы S. Среда в виде технических, организационно-

управляющих и информационных ресурсов, а также персонала

образует систему, в которой создается программное средство.

5

3. Качество процессов P. Совокупность изменений характеристик

системы и ее продуктов разработки с течением времени образуют

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

управленческих решений по улучшению качества процессов

создания результата.

Очевидно, что на качество результатов влияют качество системы и

качество процессов, и в то же время качество результатов, системы и

процессов является не статичной, а динамичной сущностью, характери-

зующейся изменениями во времени. Тогда

R(t) = G(S(t), P(t)),

где G – это функция преобразующая качество системы и протекающих в

ней процессов в качество результатов в некоторый момент времени.

Все это указывает на сложность проблемы управления качеством

программных средств, на рассмотрении основ решения которой

направлено данное пособие.

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

управления качеством с акцентом на оценивание качества разраба-

тываемых программных средств как сложных объектов R, обладающих

заданными или ожидаемыми свойствами (характеристиками). На основе

известных стандартов приведена обобщенная структурно-функциональная

модель оценивания степени качества программного средства.

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

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

Третья глава посвящена вопросу оценивания и управления качеством

системы, целенаправленно создающей программные средства, на основе

моделей зрелости системы. При этом под системой понимается

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

6

Некоторые инструменты управления качеством программных

средств приведены в четвертой главе.

Каждая глава сопровождается примерами, вынесенными в

приложения, ввиду большого объема, и контрольными вопросами,

позволяющими задуматься над проблемой автоматизации систем

управления программными средствами.

ГЛАВА 1. ОСНОВЫ КАЧЕСТВА ПРОГРАММНЫХ СИСТЕМ

1.1. Качество как объект измерения

Понятие качества относится к сложным категориям в силу его

множественной интерпретации, зависящей от цели управления качеством,

этапов жизненного цикла и модели оцениваемого объекта.

Как сложное понятие, в общем случае качество целесообразно

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

области управления качеством программных средств в последующих

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

1. Свойство измеримости. Одной из проблем управления

качеством является определение эффективных показателей

качества для автоматизации процессов их оценивания.

Качество всегда нужно рассматривать во взаимосвязи с

количеством, так как количество отражает степень развития

качества.

Количество, характеризующее некоторое свойство объекта,

тогда будет определять качество этого свойства, если есть база

для сравнения или некоторый эталон. База для сравнения

может иметь градации, тогда результат измерения качества

может быть выражен и количественно, и качественно.

7

Выделим два основных подхода в измерении качества

объектов и процессов с точки зрения квалиметрии (науки о

качестве):

a. Подход, основанный на решении проблемы построения

модели комплексной оценки качества на основе частных

показателей качества.

b. Подход, рассматривающий не только модели комплекс-

ной оценки качества, но и модели метрик, оценочных

шкал, оптимизации оценки и классификации (интерпре-

тации) уровня качества.

2. Свойство иерархичности. Как сложное понятие, качество

целесообразно декомпозировать на уровни, следовательно,

представить в виде иерархической системы. В такой системе

существует уровень, характеризующий единичное качество, и

уровень, характеризующий интегральное качество. В области

управлении качества программных средств иерархичность

определяет многоуровневую структуру характеристик качеств

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

оценивающих.

3. Свойство изменчивости. Качество – это динамическая

категория. Качество создаваемых объектов и процессов

устанавливается, формируется (планируется, обеспечивается и

поддерживается) и применяется. Динамичность качества

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

в развитии свойств и изменении их интенсивности во времени.

Процессный подход в области управлении качеством

ориентирован на управлении вариабельностью процессов

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

стандартизованные процессы планирования, обеспечения и

контроля качества формируют условия такого управления.

8

Чем определяется качество программного средства, как результата

целенаправленного процесса? С точки зрения программной инженерии

управление качеством программного обеспечения опирается на три

«кита»: основы качества, процессы управления и практики (см. рисунок 1).

Рис. 1. Качество ПО с точки зрения программной инженерии

В первую очередь на качество разработки программных средств

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

ном, мотивированном коллективе, придерживающемся общечеловеческих

и корпоративных ценностей, ориентированном на качество, разработка

9

востребованных и конкурентоспособных программных продуктов

«обречена» на успех. Осознание этого факта привело к созданию

всеобщего Кодекса этики и профессиональной практики программной

инженерии, в котором определены специфические профессиональные

нормы поведения разработчиков. Кодекс разработчиков ПО разработан

такими профессиональными объединениями как ACM, IEEE и CS (British

Computer Society) и зафиксирован в документе IEEE-CS/ACM Software

Engineering Code of Ethics and Professional Practices. Основные положения

Кодекса этики и профессиональной практики программной инженерии

приведены в Приложении 1.

Рассмотрим основные понятия в области качества программных

средств с точки зрения действующих стандартов:

1. Качество программного обеспечения (Software Quality) – это степень,

в которой программное обеспечение обладает требуемой комби-

нацией свойств (1061-1998 IEEE Standard for Software Quality Metrics

Methodology).

2. Качество программного обеспечения (Software Quality) – это

совокупность характеристик программного обеспечения, относя-

щихся к его способности удовлетворять установленные и

предполагаемые потребности (ISO 8402:1994 Quality management and

quality assurance).

3. Качество программного обеспечения (Software Quality) это степень

удовлетворения программным продуктом заявленных и подразу-

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

(ИСО/МЭК 25000). Условия использования это контекст исполь-

зования (context of use): пользователи, задачи, оборудование

(аппаратные средства, программные средства, материалы),

физическая и социальная среда, в которых используют продукцию.

10

Основными государственными стандартами, регламентирующими в

нашей стране использование терминологии по качеству программного

обеспечения, являются:

1. ГОСТ 28806-90 «КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ.

Термины и определения (Software quality. Terms and definitions)» [1].

2. ГОСТ 28195-89 «ОЦЕНКА КАЧЕСТВА ПРОГРАММНЫХ

СРЕДСТВ. Общие положения (Quality control of software systems.

General principles)» [2].

3. ГОСТ Р ИСО/МЭК 25000. Требования и оценка качества систем и

программного обеспечения (SQuaRE). Модели качества систем и

программных продуктов [3].

Согласно ГОСТ 28806-90 качество программного средства – это

совокупность свойств, которые обуславливают его пригодность удовле-

творять заданные или подразумеваемые потребности в соответствии с его

назначением.

Программное средство (ПС) определяется как объект, состоящий их

программ, процедур, правил, а также, если предусмотрено в

сопутствующих им документации, и данных, относящихся к

функционированию системы обработки информации. Чтобы измерить или

оценить качество такого объекта, необходима модель, описывающая

основные свойства и характеристики ПС.

1.2. Структурно-функциональная модель оценивания качества

программных средств

Модель качества (quality model) – это определенное множество

характеристик и взаимосвязей между ними, которые обеспечивают

основу для определения требований к качеству и оценки качества

(ИСО/МЭК 25000) [3].

11

На основе стандартизованных определений понятия качества

определим формальную модель качества ПС в виде общесистемной

модели качества результата деятельности (продукта, услуги, процесса).

Качество ПС оценивается функцией следующего вида:

Sq = F(X1, X2, … , Xn; Р1, Р2, … , Рn), (1)

где Sq – это степень качества; F – это функция, вычисляющая степень

качества, в которой характеристики X1, X2, … , Xn программного средства

соответствуют требуемой комбинации свойств Р1, Р2, …, Рn,

а именно, установленным потребностям и зафиксированным требованиям.

Характеристики качества ПС часто называют свойствами,

атрибутами, показателями или факторами качества. Давайте уточним

соотношение этих понятий.

Характеристика качества ПС является структурным многоуровневым

объектом, и, в самом общем виде, определяется как набор свойств,

которые могут быть выражены числовыми и лингвистическими оценками.

Согласно ГОСТ 28195-89 [2] характеристика качества декомпо-

зируется на 4 уровня (рис. 2):

1. Фактор качества определяет группу основных показателей качества,

характеризующую потребительские свойства (требования) ПС.

2. Критерий качества задает программно-ориентированные свойства

(требования) ПС. Для вычисления значения критерия используют

одну или несколько метрик. 3. Метрика используется для количественной оценки качества ПО по

заданному критерию. Она определяется как шкала и метод

измерения свойства.

4. Оценочный элемент (элемент показателя качества) измеряет

заданное в метрике свойство числом от 0 до 1 (ГОСТ 28195-89).

12

Рис. 2. Структурная модель характеристик качества согласно ГОСТ 28195-89

Фактор качества ПС – это нефункциональное требование к

программе, которое обычно не описывается в договоре с заказчиком, но,

тем не менее, является желательным требованием, повышающим качество

программы.

Некоторые из факторов качества приведены в Приложении 2.

В модели оценивания качества ПС (1) требуемые наборы свойств Р1,

Р2, …, Рn представляют собой те же вышерассмотренные характеристики,

которые необходимо выбрать в качестве базовых (эталонных) для

сопоставления при оценке качества ПС.

Функция F, вычисляющая степень соответствия ПС требуемым

наборам свойств Р1, Р2, …, Рn, является функцией агрегации, в основе

которой лежат операции свертки характеристик качества X1, X2, … , Xn,

начиная с четвертого до первого (или второго) уровня. Примером

функции агрегации на каждом уровне могут служить среднее,

средневзвешенное, минимум и т. д.

Часто совокупность и структура характеристик качества X1, X2, …,

Xn называют структурной моделью качества ПС, так как их состав и

отношения определяют в значительной степени результат применения

выбранной функции оценивания степени качества.

13

Многоуровневая модель качества программного обеспечения,

представлена и в наборе стандартов ISO 9126 [3, 4, 5]. На верхнем уровне

выделено шесть основных характеристик (факторов) качества ПО, каждый

из которых определяют набором критериев (субхарактеристик), имеющих

соответствующие метрики для последующей оценки (рис. 3).

Рис. 3. Основные факторы и критерии качества ПС в наборе стандартов ISO 9126 [4]

Существует множество и других структурных моделей качества ПС,

таких как модели Мак-Колла, Боэма (рис. 4), FURPS/FURPS+, Гецци,

Дроми, SATC, QMOOD (подробнее смотрите в работах [6, 7]).

Модель качества ПС набора стандартов ISO/IEC 9126-2, 9126-3,

9126-4 различает следующие понятия:

• внутреннее качество, связанное с характеристиками ПС самого по

себе, без учета его поведения;

14

• внешнее качество, характеризующее ПС с точки зрения его

поведения;

• качество процесса разработки ПС;

• эксплуатационное качества ПС при использовании в различных

контекстах – того качества, которое ощущается пользователями при

конкретных сценариях работы ПО.

Рис. 4. Структурная модель качества программного продукта Боэма (1978 г.) в виде

«дерева». Справа приведены русскоязычные термины критериев качества

Важным элементом структурной модели характеристик качества ПС

являются метрики и оценочные элементы, для которых должны быть

определены шкалы и методы оценивания. Модели характеристик качества

с фокусом на метрический подход и соответствующие модели качества

15

(модель Миллса, модель Шумана, модель Джелинского-Моранды

модель Вейбулла и еще 22 модели и метрики для обнаружения

вероятностей ошибок или их количества) детально рассмотрены в учебных

изданиях [8, 9].

На рисунке 5 изображена структурная модель качества на основе

стандартов ISO/IEC 9126 с указанием классов метрик по типам факторов

качества.

Рис. 5. Структурная модель качества стандартов ISO/IEC 9126

Показатель качества в ГОСТ Р ИСО/МЭК 25000-2015

интерпретируется как результат некоторого измерения свойства или

функционального преобразования такого измерения [3]. Пример,

демонстрирующий взаимосвязь между характеристиками (факторами)

(Надежность и Зрелость), показателями качества и способом измерения

показателей качества, приведен согласно модели качества [10] на рис. 6.

16

Рис. 6. Взаимосвязь характеристики (свойства) ПС и его показателей качества согласно ГОСТ Р ИСО/МЭК 25000-2015: ЭПК – элемент показателя качества, ПК – показатель

качества ПС для свойств «Надежность» и «Зрелость»

Учитывая вышеизложенное, модель оценивания (1) может

рассматриваться как структурно-функциональная модель качества ПС.

Эту модель необходимо спроектировать и зафиксировать на этапе

разработки спецификаций и технического задания ПС.

При проектировании структурно-функциональной модели оценива-

ния качества, согласно выражению (1), необходимо последовательно

решить следующие задачи:

1. Выбрать реальный или идеальный прототип (эталон) разрабаты-

ваемого ПС и построить его структурную модель (1) до уровня

базовых оценочных элементов. Базовое значение – это реально

достижимое значение метрики, отражающее современный уровень

развития программного обеспечения.

17

2. Определить на основе прототипа структурную модель оценивания

качества разрабатываемого ПС в виде структуры характеристик

качества X1, X2, … , Xn.

3. Выбрать методику оценивания соответствия структурных моделей

вариантов разрабатываемого ПС и его прототипа (на основе разности

соответствующих значений или их отношений).

4. Определить функцию агрегации итоговой степени качества F

согласно модели (1).

1.3. Функции агрегации показателей качества

На основе стандартизованных характеристик качества имеется

возможность автоматизации вычисления показателей качества,

которые в дальнейшем можно анализировать и использовать в

управлении качеством. Вычисленные частные показатели могут

содержать отклонения реальной характеристики качества от эталона.

Для вычисления отклонений используют функции разности, деления,

вычисления абсолютных и среднеквадратичных отклонений.

В результате формируется вектор отклонений, по которому с

помощью функции агрегации можно резюмировать качество.

В математике известны несколько классов функций, позволяющих

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

функциям относят:

1. Функцию взвешенной суммы, с помощью которой реализуют

агрегацию показателей качества на основе линейной

аддитивной функций свертки. Данный вид агрегации можно

трактовать как скалярное произведение двух векторов: вектора

частных показателей качества в определенной шкале и вектора

18

весов (приоритетов). Вектора весов можно определить,

применяя регрессионный анализ, если есть данные о значениях

частных и обобщенного показателей качества по определенной

серии объектов. Другие способы определения весов для

функции свертки могут быть основаны на субъективных

вероятностей, эвристических алгоритмах и экспертном

оценивании.

2. Пороговую функцию, отображающую множество значений

показателей качества в нескольких заранее заданных

значениях. Такая функция может быть задана системой четких

или нечетких правил «Если-То».

3. Функцию логического объединения для показателей альтерна-

тивного типа на основе логических операций умножения,

суммирования и отрицания.

4. Функцию обобщенного логического свертывания с использо-

ванием функций максимума и минимума.

В результате оценивания соответствия между структурной моделью

прототипа (или эталона) получают матрицу оценок. В этом случае

интегральную оценку объекта оценивания целесообразно вычислять,

опираясь на методы выбора оптимального решения. К таким методам

относят методы на основе критериев Вальда, Байеса-Лапласа, Сэвиджа,

Гурвица и т. д.

В Приложении 3 приведен пример экспертного оценивания качества

вариантов проектов коммерческого web-сервиса относительно прототипа.

19

1.4. Контрольные вопросы

1. Приведите основные компоненты понятия управления качеством

ПО.

2. Зачем, когда и кем был введен Кодекс этики и профессиональной

практики программной инженерии?

3. Приведите основные положения Кодекса этики и профессиональной

практики программной инженерии, в которых упоминается понятие

качества.

4. Приведите стандартизованные определения понятия качества ПО.

5. Сформулируйте формализованное определение качества

программных средств.

6. Охарактеризуйте структурную модель качества ПС.

7. Опишите многоуровневую структуру характеристик качества ПС.

8. Какие классы качества выделены в стандартах ISO/IEC 9126-2,

9126-3, 9126-4?

9. Перечислите и охарактеризуйте факторы качества программных

средств.

10. Опишите схему структурной модели качества Боэма.

11. Проведите сравнительный количественный и качественный анализ

модели качества ГОСТ 28195-89, модели качества Боэма.

12. Какие задачи необходимо решать при проектировании структурно-

функциональной модели качества ПС?

13. Охарактеризуйте понятие показателя качества.

14. Перечислите виды функций агрегации показателей качества.

15. Какие функции агрегации рекомендованы в ГОСТ 28195-89?

Примените эти функции для оценивания одного из стандартных

факторов качества программных средств.

16. Сформулируйте выводы к этой главе.

20

ГЛАВА 2. ПРОЦЕССЫ ОЦЕНИВАНИЯ КАЧЕСТВА ПС

2.1. Основы процесса оценивания качества ПС

Процессы оценивания качества ПС как результата некоторой

деятельности рассмотрим в виде стандартизированных методик измерения

характеристик (метрик) качества. В этом процессе объектом оценивания

выступает ПС, а субъектом оценивания коллектив экспертов.

На рисунке 7 изображен процесс оценивания [9], ориентированный

на внутреннее и внешнее качество ПС. Важным элементом в этом

процессе является процесс и система измерений характеристик,

сфокусированные на фактор полезность.

Рис. 7. Процесс оценивания свойств ПС на основе внешнего и внутреннего качества

и полезности [9]

21

На рисунке 8 представлен более детальный процесс оценивания

качества ПС как результата, в котором выделены такие понятия, как

требования, потребности, стандарты, метрики, спецификации, измерение,

ранжирование измеренных значений и критерии оценивания. Заметим, что

в рассматриваемом процессе объектом оценивания является разработка

ПО. Результат оценивания представлен в бинарной форме. В этой схеме

процесса не представлена иерархия характеристик качества, оценивание

сводится к оцениванию метрик. Отметим, что любую многоуровневую

структуру можно линеаризовать, преобразовав в одномерную последова-

тельность. Так, согласно ГОСТ 28195-89 [2] обозначение оценочных

элементов кодируется пятью символами:

1 символ указывает на принадлежность элемента фактору.

2 символ обозначает номер критерия.

3 символ указывает номер метрики.

4 и 5 символы задают номер порядкового элемента оценочного

элемента в метрике.

Например, код оценочного элемента К1204 обозначает, что это

четвертый оценочный элемент во второй метрике первого критерия

фактора Корректность («К»).

Рассматриваемый процесс оценивания на рисунке 8 имеет две

стадии: подготовка и оценивание. Сначала определяются требования к

качеству ПС (верхняя часть схемы процесса), а затем проводится

оценивание ПС на основе результатов первой стадии.

22

Рис. 8. Детализированный процесс оценивания качества ПС

Рис. 9. Эталонная модель измерения качества [3]

23

В стандарте ГОСТ Р ИСО/МЕС 25010-2015 [3] приведена эталонная

модель измерения качества ПС, изображенная на рисунке 9. В этой модели

рассматриваются характеристики (факторы), субхарактеристки (критерии),

показатели качества (метрики) и элементы показателей качества

(оценочные элементы).

Проблема измерения и оценивания качества является сложной и

обычно решается экспертными методами. В то же время в последних

версиях стандартов в области управления качеством ПС явно

прослеживается тенденция к количественному оцениванию и измерению

качества. Это отражается в основном в формулировках характеристик и

субхарактеристик качества (см. стандарт [3]), выражаемых в виде степени

соответствия. Данная тенденция послужила основанием для формали-

зации процессов измерения и оценивания качества ПС, ведущим к возмож-

ности автоматизации этой деятельности. Примером может служить работа

В.В. Буракова [11], в которой предложены математически обоснованный

метод оценивания качества на основе теории категорий и методология

оценивания качества ПС по набору метрик (рис. 10).

Рис. 10. Обобщенная модель оценивания качества ПС [11]

24

2.2. Оценивание ПС в стандартизированных процессах

управления качеством

Стандартизация процессов оценивания качества ПС также важна,

как и унификация методов оценивания и модели качества. Выделяют

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

процессах управления качеством ПС (Software Quality Management, SQM).

Рассмотрим их ниже.

Процессы управления качеством исследуют вопросы, насколько

хорошо продукт будет удовлетворять потребностям заказчика и требо-

ваниям заинтересованных лиц.

Приведем выдержку из учебника И.И. Савенко [9]:

«Основное содержание концепции управления качеством сводится к

следующим положениям:

- требования к уровню качества по каждому фактору определяют

базовым значением показателя качества;

- требуемый уровень качества обеспечивается процессом и в

процессе производства;

- измерение, оценка и контроль уровня качества производится на

всех стадиях жизненного цикла;

- управление качеством есть непрерывный, информационный и

целенаправленный процесс воздействия на программы и документацию, а

также на коллективы разработчиков ПС в целях обеспечения требуемого

качества при изменяющихся внешних и внутренних условиях путем

принятия управленческих решений».

Общие вопросы управления качеством на основе международных

стандартов рассмотрены в работах [16, 18]. Следуя стандарту ISO 12207,

приведем основные стандартизованные процессы SQM, ориентированные

на оценивание ПС как результата разработки:

25

1. Процесс обеспечения и подтверждения качества (software quality

assurance, SQA), включающий процессы:

1.2. Планирование качества. Этот процесс ориентирован на создание

условий разработки продукта, характеристики которого удовлет-

воряют требованиям, и уменьшение возможных рисков снижения

качества.

1.3. Процесс верификации (verification process). Процесс определения

соответствия программного обеспечения предназначению.

1.4. Процесс аттестации (validation process). Процесс подтверждения

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

2. Процесс совместного анализа (joint review process).

3. Процесс аудита (audit process).

2.3. Процессы обеспечения и подтверждения качества

Рассмотрим процессы обеспечения и подтверждения качеством,

используя информацию из источника [19]. Процессы SQA обеспечивают

подтверждение того, что программные продукты и процессы жизненного

цикла проекта соответствуют заданным требованиям. Такое подтвержде-

ние проводится на основе планирования (planning), постановки работ

(enacting) и исполнения (performing) набора действий, направленных на то,

чтобы качество стало неотъемлемой частью программного обеспечения

SQA, как это сформулировано SWEBOK, концентрируется на процессах.

Роль SQA состоит в том, чтобы обеспечить соответствующее

планирование процессов, дальнейшее исполнение процессов на основе

заданного плана и проведение необходимых измерений процессов с

передачей результатов измерений заинтересованным сторонам (организа-

ционными структурам и лицам). Пример плана и шаблоны документов

обеспечения качества разработки ПС, ориентированные на предотвра-

щение снижения потерь, приведены в учебном издании [17].

26

Согласно стандарту IEEE 1059-93 «IEEE Standard for Software

Quality Assurance Plans» SQA-план определяет метрики, которые будут

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

заданным пользовательским требованиям с максимальным уровнем

качества, возможным при заданных ограничениях проекта (то есть с

приемлемым уровнем качества). Также в плане необходимо указать

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

проверок, ресурсы, типы документов, фиксирующих отклонения,

ответственных и рекомендации.

Процессы верификации и аттестации

Процессы верификации и аттестации (V&V) используют

соответствующие техники тестирования для обнаружения тех или иных

дефектов. Стандарт IEEE 1059-93 дает такое определение верификации и

аттестации: «Верификация и аттестация программного обеспечения – это

упорядоченный подход в оценке программных продуктов, применяемый

на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках

работ по проверке и аттестации, направлены на обеспечение качества как

неотъемлемой характеристики программного обеспечения и

удовлетворение пользовательских требований». Целью планирования

V&V является обеспечение процессов верификации и аттестации

необходимыми ресурсами, четкое назначение ролей и обязанностей.

Получаемый план V&V документирует и детально описывает различные

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

Подробно процессы и методики тестирования и верификации

представлены в работе [19].

27

Процессы совместного анализа и аудита

Процессы совместного анализа (joint review process) и аудита (audit

process) описаны в стандарте IEEE 1028-97 «IEEE Standard for Software

Reviews», в котором представлено пять типов оценок и аудитов:

- Управленческие оценки (management reviews).

- Технические оценки (technical reviews).

- Инспекции (inspections).

- «Прогонки» (walk-throughs).

- Аудиты (audits).

Назначение управленческих оценок (management reviews) состоит в

отслеживании развития проекта/продукта, определения статуса планов и

расписаний, утверждения требования и распределения ресурсов, или

оценки эффективности управленческих подходов, используемых для

достижения поставленных целей. Управленческие оценки поддерживают

принятие решений о внесении изменений и выполнении корректирующих

действий в случае обнаружения отклонений и аномалий в процессе

создания программного проекта.

Технические оценки (technical reviews) используются для

определения пригодности разрабатываемого ПС для использования в

надлежащих целях. Цель технических оценок состоит в идентификации

расхождений с утвержденными спецификациями и стандартами.

Техническая оценка требует наличия следующих входных данных:

- Формулировки целей.

- Конкретного программного продукта (подвергаемого оценке).

- Заданного плана проекта (плана управления проектом).

- Списка проблем (вопросов), ассоциированных с продуктом.

- Процедуры технической оценки. Для этой процедуры часто

применяют технику Code Review.

28

Процесс инспекций (inspections) сфокусирован на обнаружении и

идентификации аномалий (отклонений) в программном продукте. Отличие

инспекций от вышерассмотренных процессов оценивания (управленческих

и технических) заключается в составе экспертов, привлекаемых для

инспектирования: это эксперты, независимые от проекта и его целей,

обученные техникам инспектирования.

В заданный момент (промежуток) времени инспекции проводятся в

отношении отдельного небольшого фрагмента продукта, например,

интерфейса. Любая найденная аномалия должна документироваться.

Общим инструментом, используемым при инспектировании, является

проверочный лист (checklist), содержащий аномалии и вопросы, связанные

с аспектами программного продукта, вызывающими интерес.

Результирующий поверочный лист часто классифицирует аномалии

(см. стандарт IEEE 1044-93 «IEEE Standard for the Classification of Software

Anomalies»).

Решение о завершении инспекции принимается в соответствии с

одним (любым) из трех критериев:

- Принятие продукта с отсутствием либо малой необходимостью

переработки.

- Принятие продукта с последующей проверкой переработанных

фрагментов.

- Необходимость повторной инспекции.

Инспекционные встречи занимают обычно несколько часов, в отли-

чие от технической оценки и аудита, предполагающих, в большинстве

случаев, больший объем работ и, соответственно, длящиеся дольше.

29

Назначение прогонки (walk-throughs) состоит также в оценке

программного продукта. Прогонка может проводиться с целью ознаком-

ления (обучения) аудитории с программным продуктом. Главные цели

процесса прогонки состоят в:

- Поиске аномалий.

- Улучшении продукта.

- Обсуждении альтернативных путей реализации.

- Оценке соответствия стандартам и спецификациям.

Прогонка похожа на инспекцию, однако обычно проводится менее

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

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

как одного из элементов (техник) обеспечения качества.

Целью аудита (audits) программного обеспечения является

независимая оценка программных продуктов и процессов на предмет их

соответствия применяемым регулирующим документам, стандартам,

руководящим указаниям, планам и процедурам, утвержденным в данной

организации.

Аудит является формально организованной деятельностью,

участники которой выполняют определенные роли. В аудите принимает

участие представитель оцениваемой организации или ее организационной

единицы. В результате аудита идентифицируются случаи несоответствия и

формируется отчет, полезный для принятия корректирующих действий.

Пример аудита проекта JIRA.MONGODB.COM приведен в

Приложении 4.

В целом рассмотренные процессы сфокусированы на контроле

качества продукта и процессов и, согласно рекомендации Сомервиля [9],

должны функционировать параллельно с разработкой ПС (рис. 11).

30

Рис. 11. Процесс управления качеством разработки ПО [9]

Таким образом, управление качеством при разработке ПС включает

следующие аспекты [9]:

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

процедур, ресурсов и стандартов в целях создания ПО высокого

качества.

Планирование качества. Выбор из этого множества соответству-

ющего подмножества и адаптация его к данному проекту разработки

ПО.

Мониториг и контроль качества. Определение и проведение

мероприятий, гарантирующих выполнение нормативных процедур и

стандартов качества всеми членами команды разработчиков ПО.

В работе В. В. Буракова [11] рассмотрена общая схема процесса

управления качеством ПС, объединяющая процессы планирования,

обеспечения и контроля (рис. 12) на основе формализованных моделей

качества, измерений и оценки ПС. Использование на каждом из этих

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

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

системности работ по улучшению качества программных средств [11].

31

Рис. 12. Архитектура системы управления качеством ПС [11]

2.4. Контрольные вопросы

1. Приведите способы кодирования характеристик качества ПС.

2. Приведите графическую схему процесса оценивания качества ПС.

3. Перечислите и кратко охарактеризуйте основные стандарти-

зованные процессы SQM, ориентированные на оценивание ПС как

результата разработки и сопоставьте их с жизненным циклом ПС.

4. Что включают в планирование качества ПС? Приведите пример

плана. Предложите способы автоматизации планирования качества

ПС.

5. Охарактеризуйте процессы верификации и аттестации ПС. Какие

способы автоматизации этих процессов можно предложить?

6. Охарактеризуйте процессы совместного анализа ПС и приведите

варианты их автоматизации.

7. Чем отличаются управленческие оценки ПС от технических?

8. Сопоставьте процесс инспекции и процесс прогонки ПС. Какие

решения по автоматизации этих процессов целесообразны?

9. Сформулируйте основные аспекты управлении качеством ПС.

10. Приведите архитектуру системы автоматизации управления

качеством ПС на основе формализованных моделей.

32

ГЛАВА 3. МЕТОДОЛОГИИ УПРАВЛЕНИЯ КАЧЕСТВОМ ПС

3.1. Классификация методологий управления качеством ПС

Выделим следующие группы методологий управления качеством

ПС, рассматриваемых в работе [13]:

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

является успешное выполнение отдельного проекта. К этой группе

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

адаптивные методологии. Логика успешного функционирования

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

активов за счет последовательного выполнения успешных проектов.

• Вторая группа включает в себя методологии, обеспечивающие

устойчивое функционирование компании-разработчика ПО, наце-

лены на последовательное развитие компетенций. К этой группе

относятся модели зрелости (CMM, CMMI). Логика успешного

функционирования предполагает создание, контроль и непрерывное

улучшение способностей организации к выполнению проектов, и,

как следствие, успешное выполнение проектов [13].

По характеру знаний и фокусу: инженерные, управленческие и

интегрированные методологии:

• Инженерные методологии (software engineering) основываются на

технологических принципах и направлены на совершенствование

конечных продуктов, таких как программный код, тестовые

примеры, прототипы, документация. Инженерные инструмен-

тальные необходимы квалифицированному разработчику.

• Управленческие инструментальные средства (software project

management and process management) основываются на принципах

теории управления (менеджмента), в их основе лежат такие

33

концепции, как тотальное управление качеством, управление

проектами, управление знаниями.

• Интегрированные инструментальные средства объединяют инженер-

ные концепции и концепции управления.

В инженерных методологиях управление качеством нацелено на

уменьшения риска «неуспешности» разработки ПО, среди них выделяют

следующее [13]:

• Прогнозируемые методологии основываются на предпосылке о

возможности и целесообразности детального планирования

будущего. Для ИТ-проекта формулируются требования к

разрабатываемой системе, формируется план проекта и определяется

потребность в ресурсах. Изменения в плане проекта и требованиях

считаются нежелательными. Проектные методологии этого класса

используют каскадную модель жизненного цикла.

• Адаптивные методологии нацелены на преодоление ожидаемой

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

адаптивных методологий лежит итерационная модель жизненного

цикла. Примером адаптивных методологий являются Scrum, Канбан,

Crystal, Extreme Programming. Адаптивные методологии учитывают

психологические особенности процесса разработки ПО. Одним из

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

является высокая квалификация специалистов, в первую очередь –

разработчиков.

В управленческих методологиях управление качеством нацелено на

обеспечение постоянного движения к повышению качества ПО. Эта мето-

дология опирается на факт, что на качество результата (программного

продукта) в первую очередь влияют процессы и деятельность, связанные с

его получением.

34

Созданная Фейгенбаумом система всеобщего (тотального) управ-

ления контроля качества была внедрена в практику работы японских

предприятий Э. Демингом. 14 принципов совершенствования качества

этой методологии приведены в Приложении 5.

Всеобщее (тотальное) управление качеством (TQМ), осуществля-

емое фирмами, предполагает три обязательных условия:

1) Качество как основная стратегическая цель деятельности признается

высшим руководством фирм. При этом устанавливаются конкретные

задачи и выделяются средства для их решения. Поскольку требования к

качеству определяет потребитель, не может существовать такого

понятия, как постоянный уровень качества. Качество должно

постоянно возрастать, ибо качество – это постоянно меняющаяся цель и

непрерывный процесс.

2) Мероприятия по повышению качества должны затрагивать все

подразделения без исключения. Опыт показывает, что 80–90%

мероприятий не контролируется отделами качества и надежности.

3) Не прекращающийся процесс обучения (ориентирован на

определенное рабочее место) и повышение мотивации персонала

(рисунок 13).

Рис. 13. Цикл постоянного улучшения качества Деминга-Шухарта PDCA

35

3.2. Модель зрелости организации

Среда в виде технических, организационно-управляющих и

информационных ресурсов, а также персонала образует систему, в которой

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

называть организацией.

Задачу управления качеством ПС с точки зрения управления

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

соответствии с отдельным компонентом исследуемой системы.

Очевидно, что процессы оценки качества ПС, рассмотренные в

первой главе, в силу общности применимы и к отдельным компонентам

таких систем. В то же время организация может использовать

организационные модели, чтобы упростить определение целей и

приоритетов усовершенствования процессов, а также как руководство,

позволяющее получить стабильные способные и зрелые процессы.

Необходимо отметить, что качество ПС в значительной степени

зависит от зрелости системы, в которой оно разрабатывается, то есть от

зрелости организации и стандартизации протекающих в ней процессов.

Зрелость организации является основным понятием группы стандартов

Capability Maturity Model Integration (CMM/CMMI), которые переведены на

русский язык как стандарты на основе комплексной модели

производительности и зрелости организации. Незрелость организации, в

части управления процессами разработки ПО, означает, что проекты

выполняются без необходимых правил и методик, а результаты проекта в

значительной степени зависят от возможностей команды и менеджера

проекта.

Целью стандартов CMMI является совершенствование процессов

разработки ПС для получения улучшенных программных продуктов.

36

Комплексная модель производительности и зрелости организации

представляет собой описание идеального направления развития

организации (или отдельного подразделения) к желаемому уровню

реализации процесса разработки ПС, заданное в виде нескольких

последовательных этапов (которые нужно выполнить) или уровней

(которых нужно достичь), дополненное средствами оценивания полноты

выполнения описанных этапов или соответствия процесса организации

описанным уровням. Такая модель позволяет организации оценить свою

реализацию процесса разработки ПС путем ее сравнения с лучшими

вариантами такой реализации (или с вариантами конкурентов).

С некоторыми свободно распространяемыми материалами по СММ

можно познакомиться на сайте Software Engineering Institute

(http://www.sei.cmu.edu/cmm). Система стандартов СММ/CMMI содержит

ключевые элементы процессов разработки ПО на разных уровнях зрелости

организации. Каждый уровень зрелости организации определяет

конкретные характеристики процессов разработки ПО, и более высокие

уровни зрелости обладают более развитыми характеристиками,

свойственными более зрелым процессам.

Существуют два вида моделей зрелости организации согласно

CMMI: поэтапные и непрерывные модели [12, 13]. На рисунке 14

представлена непрерывная модель зрелости организации согласно CMMI.

Непрерывная форма представления модели CMMI рассматривает не

уровни зрелости организации (Maturity Levels), а уровни возможностей

(Capability Levels), которые оцениваются для отдельных областей

процессов в исследуемой организации. В этом представлении делается

упор на самые лучшие практики, которые может использовать организация

для совершенствования процессов в тех областях процессов, которые

находятся в рамках тех уровней зрелости, которых она стремится достичь.

37

Поэтапное представление модели CMMI предназначено для

описания отдельных уровней совершенствования процессов и этапов

приближения к более высокому уровню зрелости. Уровень зрелости

организации обеспечивает способ прогнозирования будущего поведения

организации. Каждый уровень зрелости стабилизирует существенную

часть процессов организации.

Рис. 14. Непрерывная модель зрелости организации согласно CMMI [12]

Рассмотрим модель CMMI с поэтапным представлением на пяти

уровнях зрелости организации:

1. Начальный.

2. Управляемый (повторяемый).

3. Определенный.

4. Количественно управляемый.

5. Оптимизируемый.

Ниже приведено содержание пяти уровней стандартов оценивания

зрелости организации, детально описанных в работах [4, 12, 13].

38

Уровень зрелости 1: Начальный

Выполнение проекта управляемо посредством распределения ролей

(разработчики и менеджер проекта). Начальный уровень описан в

стандарте в качестве основы для сравнения со следующими уровнями. В

организации начального уровня не существует стабильных условий для

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

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

опыта программистов, причем успех одного проекта может быть повторен

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

следующий проект. Более того, если такие менеджеры или программисты

уходят с предприятия, то с их уходом резко падает качество производимых

программных продуктов. Чаще всего процесс разработки сводится к

написанию кода и его минимальному тестированию. Несмотря на такую

неупорядоченную и не регламентированную среду, организации,

относящиеся к уровню зрелости 1, часто создают продукты и услуги,

которые работают, но при этом зачастую выходят за рамки сметы и

графиков работ.

Для организаций с уровнем зрелости 1 характерно стремление брать

на себя лишние обязательства и неспособность повторить свои прошлые

успехи.

Уровень зрелости 2:

Управляемый (по CMMI) или Повторяющийся (по CMM)

На втором уровне зрелости в организации введены формализованные

элементы управления:

• Реализовано управление проектами, а также планирование и

измерение характеристик процессов. Дисциплина процессов,

отраженная в уровне зрелости 2, помогает гарантировать сохранение

существующих процессов в напряженные моменты.

39

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

оказываемых услуг в определенных контрольных точках.

Чтобы организации достигнуть второго уровня, в ней необходимо

внедрить технологии управления проектами. Планирование проектами в

зрелой организации основывается на накопленном опыте, в ней действуют

стандарты на разрабатываемое ПО и функционирует специально

созданная группа обеспечения качества.

Уровень зрелости 3: Определенный

На третьем уровне зрелости в организации всем процессам дана

четкая характеристика, они понятны и описаны в стандартах, процедурах,

инструментальных средствах и методах.

Отличия уровня зрелости 3 от уровня зрелости 2 заключаются в

следующем:

На уровне зрелости 2 стандарты, описания процессов и процедуры

могут абсолютно отличаться в каждом конкретном экземпляре

процесса (например, в конкретном проекте).

На уровне зрелости 3 стандарты, описания процессов и процедуры

типовые, но могут настраиваются с помощью набора стандартных

процессов на конкретный проект.

На уровне зрелости 3 процессы обычно описаны более подробно и

строго, чем на уровне зрелости 2. Дополнительно описаны

взаимосвязи процессов, поэтому на этом уровне зрелости процессы

выполняются с опережением, благодаря пониманию взаимосвязей

между задачами и подробными критериями процесса, его рабочих

продуктов и услуг.

40

Для достижения организацией̆ этого уровня зрелости необходимо

внедрить документированный ̆ стандартный ̆ процесс создания и

сопровождения ПС, который включает и разработку ПС, и управление

проектами. На третьем уровне (в процессе стандартизации) происходит

переход на наиболее эффективные практики и технологии, то есть

используется накопленный опыт и история разработки. Создание и

поддержку стандартов осуществляет специальная группа. Обязательным

условием для достижения данного уровня является наличие в организации

программы постоянного повышения квалификации и обучения

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

от качеств конкретных разработчиков.

Уровень зрелости 4: Количественно управляемый̆

На этом уровне зрелости в процессе разработки ПС реализована

обратная связь по управлению:

• Оцениваются процессы по производительности и качеству.

Из подпроцессов выбираются те, которые существенно влияют на

общую производительность и качество процесса. Управление

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

статистических и других количественных методов.

• Критерии управления количественные, установленные для

определения характеристик качества и производительности

процесса.

• Количественные цели основываются на потребностях клиентов,

конечных пользователей, организации и разработчиков процессов.

Качество и производительность процесса понимаются с точки

зрения статистики и контролируются на протяжении всего

срока существования процессов.

41

• Выявляются особые случаи колебания процесса (аномалии) и, по

мере возможности, источники особых случаев устраняются, чтобы

предотвратить их возникновение в дальнейшем (контрольные

карты).

• Критерии измерения качества и производительности процесса

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

дальнейшем принятие решений, подкрепляемых фактами и

историей.

Главным отличием между уровнем зрелости 3 и уровнем зрелости 4

является предсказуемость производительности процесса. На уровне

зрелости 4 производительность и качество процессов не только

контролируется но и прогнозируется. На уровне зрелости 3 можно

прогнозировать только качественную оценку процессов. Чтобы органи-

зации достигнуть четвертого уровня, в ней устанавливаются

количественные показатели качества на разрабатываемые виды

программных продуктов и на производимые продукты в целом.

Достигаемые на данном уровне зрелости результаты управления

проектами выполняются за счет уменьшения отклонений значений

параметров различных показателей проекта от заданных.

Уровень зрелости 5: Оптимизируемый

Главной задачей всей организации на этом уровне зрелости является

постоянное улучшение существующих процессов:

• Идет постоянное усовершенствование процессов на базе количест-

венного представления об общих причинах колебания, свойствен-

ного процессам (контрольные карты, метод «Шесть сигм»).

42

• Основное внимание уровня зрелости 5 сосредоточено на

непрерывном совершенствовании производительности и качества

процесса путем небольших постепенных усовершенствований.

Количественные цели усовершенствования процессов, установлен-

ные для данной организации, постоянно пересматриваются, чтобы

отразить изменение коммерческих целей, и используются в качестве

критериев управления усовершенствованием процессов. Результа-

ты введенных усовершенствований процесса измеряются, оцени-

ваются, прогнозируются и сопоставляются с количественными

целями.

• Способность организации быстро реагировать на изменения и

возможности повышается за счет отыскания способов ускоренного и

коллективного обучения. Усовершенствование процессов является

составной частью роли любого работника, в результате чего цикл

усовершенствования никогда не прерывается.

Отличия уровня зрелости 5 от уровня зрелости 4 заключаются в типе

анализа вариабельности рассматриваемого процесса:

• На уровне зрелости 4 занимаются рассмотрением особых случаев

колебания процессов и обеспечением статистической

предсказуемости результатов.

• Несмотря на то, что процессы могут выдавать предсказуемые

результаты, эти результаты могут оказаться недостаточными для

достижения поставленных целей улучшения качества.

• На уровне зрелости 5 анализируются и контролируются общие

случаи вариаций процесса.

43

Организации могут добиться постепенного усовершенствования

организационной ̆ зрелости, прежде всего, добившись стабильности

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

осуществляя непрерывное совершенствование процессов в масштабах всей

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

принятия решений.

Более гибкой методологией в управлении качеством ПС является

стандарт SPICE [4]. В этом стандарте акцент сделан не на уровнях

зрелости, а на возможностях, применительно к отдельному процессу.

Это позволяет по множеству процессов, то есть в векторной форме,

создать профиль организации и отслеживать для каждого процесса

возможности его улучшения.

В следующей главе будут рассмотрены вопросы как контролировать

процессы и обнаруживать неслучайную вариабельность.

3. 3. Контрольные вопросы

1. Изобразите графическую схему классификации методологий в

управлении качеством ПС.

2. Сопоставьте инженерные и управленческие методологии в управлении

качеством ПС.

3. Сформулируйте принципы всеобщего управления качеством продукции.

4. Приведите три условия для реализации тотального управления

качеством.

5. Охарактеризуйте назначение стандартов, ориентированных на модели

зрелости организации, и приведите их виды.

6. Сопоставьте первый и второй уровень зрелости организации согласно

стандартам CMM/CMMI.

44

7. Сравните второй и третий уровни зрелости организации согласно

стандартам CMM/CMMI. Приведите задачи и процессы, требующие

автоматизации на третьем уровне зрелости организации.

8. Сопоставьте третий и четвертый уровни зрелости организации согласно

стандартам CMM/CMMI. Приведите задачи и процессы, требующие

автоматизации на четвертом уровне зрелости организации.

9. Чем отличается пятый уровень зрелости от четвертого согласно

стандартам CMM/CMMI? Приведите задачи и процессы, требующие

автоматизации на пятом уровне зрелости организации.

10. На каком уровне зрелости находятся организации, с которыми Вы

знакомились на практиках?

11. Приведите задачи и процессы, требующие автоматизации на разных

уровнях зрелости организации, и вариант архитектуры системы

классификации организации по уровням зрелости.

45

ГЛАВА 4. ПРАКТИКИ УПРАВЛЕНИЯ И ОЦЕНИВАНИЯ ПРОЦЕССА РАЗРАБОТКИ ПС

Процессный подход в управлении качеством производства завоевал

широкую признательность в связи с тем, что он позволяет в организациях с

одинаковой структурой разрабатывать разные по качеству ПС. При этом

качество ПС определяется уровнем управляемости процессов. Под управ-

лением качества процессов понимается управление изменчивостью

(вариабельностью) показателей качества. Для этого необходимо органи-

зовывать наблюдение (мониторинг), диагностику, контроль и планиро-

вание процессов. Процессы представимы упорядоченными по моментам

времени показателями качества метрик (в дальнейшем, метриками для

простоты). Такие последовательности метрик образуют временные ряды

(рис. 15).

Рис. 15. Пример временного ряда метрики (планируемой и реальной)

Согласно Jochen Krebs, автору книги Agile Portfolio Management,

существуют три основные характеристики (фактора) состояния проекта,

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

совершенствования процесса разработки [14]:

• Прогресс (это качество процессов),

• Качество (это качество результата) и

• Мотивация группы (это качество системы).

46

В методологии бережливого производства наиболее важным

показателем прогресса является увеличение ценности продукта и

снижение потерь, то есть уменьшение активности, не приносящей

увеличение ценности. Спектр потерь достаточно разнообразен: от

переключения между задачами до реализации лишнего функционала [20].

Здесь действует правило 20/80: 20% функционала продукта приносят 80%

ценности заказчику, и именно гибкие методологии позволяют эти 20%

функционала выявить и назначить им максимальную важность.

Рассмотрим основные показатели и метрики, временные ряды

которых наиболее важны с точки зрения успешности процесса гибкой

разработки ПС.

4.1. Показатели и метрики в управлении качеством разработки ПС

Прогресс рассматривается как функция, конвертирующая требования

в работоспособную версию ПО. Он начинается с плана, который

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

требованиями, и фактическое значение, которое представляет собой

реальную работу по разработке.

Сравнения планов и результатов позволяют проектной команде

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

итерации. В таблице 1 представлены основные метрики прогресса,

временные ряды которых позволяют обнаружить аномалии (узкие места) и

неравномерности разработки [14]. Как можно отметить, все метрики

таблицы 1 связаны или с объем задач или со временем их выполнения.

Эти показатели качества прогнозируют в первую очередь фактор

успешности проекта.

Для оценивания времени выполнения задачи проекта одним

человеком в рабочих днях рекомендуется применять формулу

Т = 1,3×(количество баллов по всем историям)×(время одного балла).

47

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

Средняя производительность в итерацию.

Производительность по типам историй.

Производительность по типам работ.

Оценка производительности команды при выполнении проекта

выполняется на основе формулы:

Р = 1,1×(количество баллов за все реализованные истории)

Это позволяет определить для команды (см. таблицу 2):

Среднюю (максимальную, минимальную) производительность за

несколько итераций.

Производительность по типам историй.

Производительность по типам работ. Таблица 1

Основные метрики прогресса в гибкой методологии

48

Таблица 2

Средние оценки производительности команд по типам работ и этапам жизненного цикла

Производительность команды – это мера объема задач для одного

спринта в баллах (story points). На рисунке 16 представлена иллюстрация

определения производительности (максимальная производительность

достигнута в третьем спринте).

Рис. 16. Сравнение производительности по спринтам [12]

Метрика оценки времени (на анализ, проектирование, разработку,

тестирование) может опираться на показатель эффективности.

Эффективность проекта по времени выполнения на основе

прошлого опыта вычисляется по формуле

Е = |Tплан – Тфакт|/Tплан,

где Tплан – время планируемое; Tфакт – фактическое время.

49

Практика оценивания эффективности показывает, что необходимо

стремиться к значению Е<0,15.

Для оценивания эффективности по времени выполнения проекта

рекомендуется применять шкалирование. Например, в качестве диапазона

для шкалы эффективности проекта по времени, согласно ГОСТ 28195-89

целесообразно выбрать E = [0,1], со следующими градациями:

Высокоэффективный = [0, 0.15].

Эффективный = [0.15, 0.3].

Неэффективный = [0.3, 0.6].

Неуспешный = [0.6, 1].

Кроме фактора успешности, связанного с производительностью

команды, важным фактором качества является наличие дефектов (ошибок,

обнаруженных в результате тестирования). Рассмотрим метрику качества

ПС по уровню ошибок. Для ее оценивания рекомендуется применять

показатель результативность тестирования:

R = d1/(d2+ d1),

где d1 – количество обнаруженных ошибок при тестировании;

d2 – количество обнаруженных ошибок при эксплуатации.

Рекомендуемая результативность тестирования R>0,75. Также

целесообразно определить шкалу для результативности тестирования с

диапазоном R = [0,1] и градациями:

Высокоэффективная = [1, 0.75].

Эффективная = [0.75, 0.5].

Неэффективная = [0.5, 0.25].

Неуспешная = [0.25, 0].

50

В результате оценивания метрик создаются таблицы метрик

проектов, которые хранятся в базах данных (пример в таблице 3).

Таблица 3 Таблица метрик проекта

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

качества ПС, искать прототипы, находить критичные метрики и факторы.

Пример оценивания проекта ПС по двум метрикам (оценки времени

и качества ПС по уровню ошибок) в виде матрицы решений представлен

на рисунке 17.

Рис. 17. Матрица анализа эффективности проекта по двум метрикам

51

В этой матрице каждая оценка с П1 до П16 интегрирует качество ПС

с точки зрения факторов успешности (производительности) и бездефект-

ности (по уровню ошибок). При составлении такой таблицы от числовых

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

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

множествами и в каждом конкретном случае дополнительно иметь степень

принадлежности к выделенным градациям качества. Для выделенных

оценок качества с П1 до П16 на каждой итерации в гибких методологиях

легко предложить решение (правило), направленное на улучшение

процесса или на поиск причин их возникновения. Формирование

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

применения методов прогнозирования для предикативной аналитики.

Следует отметить, что в области оценивания качества ПС накоплено

большое количество метрик, однако для управления качеством процессов

рекомендуется сконцентрироваться только на критичных, ключевых

метриках. Необходимо контролировать вариацию только тех метрик,

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

качества ПС. Поиск критичных факторов – это поиск причинно-

следственной зависимости в метриках.

Вариация в метриках неизбежна, но необходимо, чтобы она

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

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

– причин, следствием которых они возникли,

– случайности или системности таких событий,

– тенденции, серий, сдвигов или периодичности.

Рассмотрим основные практики для такого анализа.

52

4.2. Инструменты анализа вариабельности критичных метрик

Процессы обычно изображаются в виде графиков временных рядов

изменения соответствующих метрик.

На рисунке 18 показана диаграмма, на которой изображены два

временных ряда, показывающие плановый и реальный процессы

выполнения задач и время ожидания.

Рис. 18. Плановый и реальный процессы выполнения задач

На рисунке 19 представлены временные ряды, характеризующие

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

(в баллах завершенных задач) по спринтам.

Рис. 19. Диаграмма общей и проектной производительности

53

Общая производительность и производительность по проектам

подсчитаны как количество Story Points, завершенных за неделю. Общая

производительность определяется в виде суммы по всем столбцам kanban-

доски и в целом характеризуется положительной динамикой. Производи-

тельность по проектам представляет собой часть, посвященную

«проектам» (большим кускам работы, например, обновлению аппаратной

платформы). Два спада на диаграмме в общей производительности и

проектной производительности связаны с неделей, когда почти все члены

команды разъехались по отпускам, и с выпуском новой версии от команды

разработки.

Используются следующие инструменты в управлении качеством

процессов:

• Гистограмма как инструмент определения частотностей появления

дефектов, отклонений и аномалий.

• Карта потока создания ценности (Value Stream Mapping) – инстру-

мент, который отображает стадии производственного процесса и

время между ними (рис. 20). Затем производится подсчет эффектив-

ности процесса, как частное от полезного времени, когда добав-

лялась ценность продукту, и общего времени работы процесса [20].

Рис. 20. Карта потока создания ценности [20]

54

• Диаграмма Парето, или ABC-анализ, позволяет выявить основные

причины, оказывающие наибольшее влияние на возникновение той

или иной ситуации. Этот инструмент позволяет выявить модули,

которые содержат определенный процент дефектов. Обычно полу-

чается соотношение, близкое к 20/80 : 20% модулей содержат 80%

дефектов.

Именно на эти модули и необходимо в первую очередь обратить

внимание: покрыть их дополнительно тестами и провести

дополнительные инспекции кода. Диаграмму Парето можно

использовать для анализа модулей по дефектам, но можно этим и не

ограничиваться: аналогичный анализ можно провести по количеству

вносимых изменений (рис. 21). Модули, в которые часто вносятся

изменения, экономически выгодно сделать более гибкими [20]:

сделать более гибкую и настраиваемую архитектуру и активно

использовать шаблоны проектирования для дополнительной

гибкости.

Рис. 21. Диаграмма Парето. По оси У кривая указывает накопленный процент

частоты изменений в проекте [20]

55

Рис

. 22.

Пример

диаграммы

Исикава

для

выявления причинно

-следственны

х связей

возникновения

дефектов в проекте

[20]

56

• Схема Исикава (причинно-следственная диаграмма) позволяет

формализовать и структурировать причины возникновения того или

иного события, например, появления несоответствия, а также

устанавливать причинно-следственные связи (рис. 22).

• Контрольные карты являются эффективным инструментов контроля

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

границ свидетельствует о необходимости введения регулирующих

и/или предупреждающих действий. Пример контрольной карты, на

которой указано изменение метрики, оценивающей дефекты в

различных проектах, приведен на рисунке 23.

Рис. 23. Пример контрольной карты по дефектам [20]

В следующем подразделе рассмотрим немного подробнее контроль-

ные карты как инструмент контроля стабильностью процессов.

57

4.3. Контрольные карты в управлении вариабельностью

критичных факторов

Существуют различные варианты контрольных карт, наибольшее

распространение получили контрольная карта Шухарта [15].

Контрольная карта Шухарта – это визуализация процесса, позволя-

ющая аналитику увидеть его вариабельность/изменчивость и классифи-

цировать эту вариабельность на вариабельность, вызванную общими

(случайными) и специальными/особыми причинами. На контрольной карте

Шухарта помимо временного ряда процесса, представленного изменением

значений критичной метрики, изображают три дополнительные линиии:

центральную линию, линии верхнего и нижнего контрольных пределов

(рис. 24).

Предложенное Шухартом правило чтения этой картинки очень

просто: если все точки находятся между верхним и нижним контрольным

пределом, то специальные причины отсутствуют, и процесс по

определению считают статистически управляемым (стабильным), что

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

нижний контрольные пределы, то специальные причины присутствуют, и

процесс по определению предлагается считать неуправляемым

(нестабильным) [15]. На четвертом и пятом уровнях зрелости организации

часто применяют уровне метод «Шесть сигм» в управлении качеством

процессов создания ПС. Этот метод ориентирован на достижение качества,

при котором из 100 проектов только 3,4 неуспешных. Основное

назначение метода «Шесть сигм»: контролировать вариацию в критичных

факторах (метриках), понять причины этой вариации и минимизировать ее

влияние на результат, сделав результат стабильным.

58

Рис. 24. Пример применения контрольных карт в контроле процесса. ЦЛ – центральная

линия, ВКП и НКП – верхний и нижний контрольные пределы

Применение метода «Шесть сигм» к контрольным картам Шухарта

требует построения дополнительных (предупреждающих) линий между

центральной линией и контрольными пределами (по три линии выше и

ниже центральной линии). Эти дополнительные линии строятся обычно на

основе среднеквадратичного отклонения, тогда расстояние между верхней

и нижней контрольной границами составляет шесть сигм (рис. 25).

Рис. 25. Контрольные карты и анализ на основе метода «Шесть сигм».

Bav – центральная линия, UCL, LCL – верхний и нижний контрольные пределы, Sb – стандартное отклонение

59

Опыт применения контрольных карт позволил сформулировать

правила обнаружения критичного поведения процесса, на которое следует

обратить внимание (таблица 4). На рисунке 25 кроме точек временного

ряда указаны номера правил таблицы, которым они удовлетворяют, и на

которые необходимо обратить внимание с целью улучшения стабильности

и качества процесса.

Таблица 4

Правила обнаружения нежелательной вариабельности метрик

 

4.4. Контрольные вопросы

1. Согласно процессному подходу какие основные характеристики

качества выделяют в гибкой методологии разработки ПС?

2. Приведите основные метрики характеристики качества Прогресс. Какие

временные ряды можно им сопоставить?

3. Приведите выражения для оценки метрик времени выполнения проекта,

оценки производительности (по типам историй, по типам работ) и уровня

ошибок (по типам историй, по типам работ).

60

4. Какие шкалы целесообразно применять для оценивания метрик и какие

значения этих метрик рекомендуются?

5. Каким образом можно получать комплексную оценку качества на основе

множества метрик качества (по типам историй, по типам работ)?

Предложите вариант автоматизации принятия решения по матричной

форме показателей успешности и бездефектности ПС.

6. Перечислите и проиллюстрируйте инструменты управления качеством

процессов, образованных изменениями значений метрик. Как можно

встроить эти инструменты в архитектуру управления качеством ПС?

7. Что является объектом, субъектом, целью и результатом контрольных

карт Шухарта применительно к качеству ПС?

8. Приведите иллюстрацию карты Шухарта применительно к некоторому

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

9. Опишите особенность, цель и проиллюстрируйте на контрольной карте

метод «Шесть сигм».

10. Приведите правила, классифицирующие возможную нестабильность

процесса. Если три последовательные точки лежат выше центральной

линии в карте Шухарта, каков характер процесса? Если все точки лежат на

центральной линии, это стабильный процесс?

13. Предложите архитектуру системы автоматизации управлением

качеством ПС на основе предикативной аналитики вариабельности

ключевых метрик.

14. Сформулируйте выводы к этой главе.

61

ЗАКЛЮЧЕНИЕ

В настоящем пособии рассмотрены основы управления качеством

ПС с акцентом на системное изложение, позволяющее сформировать

понимание важности и необходимости такой деятельности. Практическая

линия пособия направлена на модели оценивания качества ПС как

системы, в которой выделены компоненты (например, программный

продукты), их характеристики (в виде структурных моделей) и процессы

(в виде временных рядов). В пособии не затрагиваются вопросы качества

ПС с точки зрения методик тестирования и методов бездефектного

проектирования, управления персоналом и техническими ресурсами, хотя

такие компоненты качества безусловно важны.

Рассмотрены вопросы представления структурных моделей харак-

теристик ПС, основанных на стандартах, и их обобщенные методики

оценивания. Такое оценивание характеризует текущее состояние качества

ПС. В то же время на качество ПС значительно влияют уровень зрелости

организации и качество процессов. Поэтому процессам управления с

точки зрения стандартизованных процессов обеспечения качества ПС

посвящена отдельная глава. Безусловно управление качеством ПС является

сложной и слабоструктурированной областью исследования и может быть

автоматизировано в настоящее время на уровне систем, основанных на

правилах и рекомендациях. Такие правила и рекомендации опираются на

понятие стабильности процессов и методов контроля вариабельности

процессов разработки ПС.

62

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. ГОСТ 28806-90 «КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. Термины

и определения (Software quality. Terms and definitions)».

2. ГОСТ 28195-89 «ОЦЕНКА КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ.

Общие положения (Quality control of software systems. General

principles)».

3. ГОСТ Р ИСО/МЭС 25010-2015. Информационные технологии

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. Требования и

оценка качества систем и программного обеспечения (SQuaRE).

Модели качества систем и программных продуктов. (Information

technology. Systems and software engineering. Systems and software

Quality Requirements and Evaluation (SQuaRE). System and software.

4. Основные факторы качества ПС [Электронный ресурс]. – Режим

доступа: http://www.protesting.ru/qa/quality.html (дата обращения

28.08.2017).

5. Генельт, А. Е. Управление качеством разработки ПО : учебно-

методическое пособие / А. Е. Генельт. – Санкт-Петербург : Изд-во

ИТМО, 2007. – 187 с.

6. Software quality attributes and trade-offs. Editors: Lars Lundberg, Michael

Mattsson, Claes Wohlin, Blekinge Institute of Technology, 2005.

7. Жарко, Е. Ф. Сравнение моделей качества программного обеспечения:

аналитический подход // Труды XII Всероссийского совещания по

проблемам управления (ВСПУ-2014). – Москва : ИПУ РАН. – 2014. –

С. 4585-4594.

8. Черников, Б. В. Управление качеством программного обеспечения :

учебник / Б. В. Черников. – Москва : ИД «ФОРУМ»: ИНФРА-М,

2012. – 240 с.

63

9. Технология разработки программного обеспечения : конспект лекций

/ сост. И. И. Савенко. – Томск : Изд-во Томского политехнического

университета, 2014. – 67 с.

10. ГОСТ Р ИСО/МЭС 25021-2014.

11. Бураков, В. В. Управление качеством программных средств / В. В.

Бураков. – Санкт-Петербургский государственный университет

аэрокосмического приборостроения. – 2009. – 287 с.

12. Chrissis, M. B. CMMI: Guidelines for Process Integration and Product

Improvement / M. B. Chrissis, M. Konrad. – Addison-Wesley. – 2003.

13. Колтунова, Е. Выбор методов, моделей и стандартов управления

разработкой программного обеспечения : дис. ... канд. эконом. наук. –

Санкт-Петербург : Питер, 2007. – Режим доступа:

http://www.koltunova.com/wp-content/uploads/2015/02/Kate-DISS2.pdf

(дата обращения 24.08.2017).

14. Krebs, J. Agile Portfolio Management. Microsoft Press, Redmond,

Washington, 2009.

15. Адлер, Ю. П. Контрольные карты Шухарта в России и за рубежом.

ЧАСТЬ 1 / Ю. П. Адлер, О. В. Максимова, В. Л. Шпер // Стандарты и

качество. – №7. – 2011. – С. 82-87.

16. Ефимов, В. В. Основы обеспечения качества : учебное пособие / В. В.

Ефимов, М. В. Самсонова. – Ульяновск, УлГТУ. – 2008.

17. Грекул, В. и др. Методические основы управления ИТ-проектами

[Электронный ресурс]. – Режим доступа:

http://www.intuit.ru/studies/courses/646/502/lecture/11395 (дата

обращения 28.08.2017).

18. Липаев, В. В. Проектирование и производство сложных заказных

программных продуктов / В.В. Липаев. – Москва : СИНТЕГ, 2011.

64

19. Орлик, С. Введение в программную инженерию и управление

жизненным циклом ПО. Программная инженерия. Качество

программного обеспечения. 2004-2005. [Электронный ресурс]. –

Режим доступа: http://msk.software-testing.ru/files/se/3-10-

software_engineering_quality.pdf (дата обращения 28.08.2017).

20. Вольфсон, Б. Гибкое управление проектами и продуктами / Б. Вольф-

сон. – Санкт-Петербург : Питер, 2014. – Режим доступа:

http://loveread.me/view_global.php?id=51822 (дата обращения

28.08.2017).

65

ПРИЛОЖЕНИЕ 1

Основные положения Кодекса этики и профессиональной практики программной инженерии

В настоящее время определены специфические профессиональные

нормы поведения, которые зафиксированы в Кодексе этики и

профессиональной практики программной инженерии (IEEE-CS/ACM

Software Engineering Code of Ethics and Professional Practices),

разработанном такими профессиональными объединениями, как ACM,

IEEE и CS (British Computer Society).

Основные положения Кодекса этики и профессиональной практики

программной инженерии:

1. Программные инженеры будут действовать соответственно

общественным интересам.

2. Программные инженеры будут действовать в интересах клиентов и

работодателя, соответственно общественным интересам.

3. Программные инженеры будут добиваться, чтобы произведенные ими

продукты и их модификации соответствовали высочайшим

профессиональным стандартам.

4. Программные инженеры будут добиваться честности и независимости

в своих экспертных суждениях.

5. Менеджеры и лидеры программных инженеров будут руководство-

ваться этическим подходом к руководству разработкой и сопровож-

дением ПО, а также будут продвигать и развивать этот подход.

6. Программные инженеры будут улучшать целостность и репутацию

своей профессии соответственно с интересами общества.

7. Программные инженеры будут честными по отношению к своим

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

8. Программные инженеры в течение всей своей жизни будут учиться

практике своей профессии и будут продвигать этический подход к

практике своей профессии.

66

ПРИЛОЖЕНИЕ 2

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

и документации.

Полнота. Все необходимые части ПС должны быть представлены и

полностью реализованы.

Краткость. Отсутствие лишней, дублирующей информации.

Повторяющиеся части кода должны быть преобразованы. То же касается и

документации.

Портируемость. Легкость в адаптации ПС к другому окружению: другой

архитектуре, платформе, операционной системе или ее версии.

Согласованность. По всей программе и в документации должны

использоваться одни и те же соглашения, форматы и обозначения.

Сопровождаемость. Насколько сложно изменить программу для

удовлетворения новых требований? Это требование также указывает, что

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

иметь резерв роста по использованию ресурсов (память, процессор).

Тестируемость. Позволяет ли программа выполнить проверку

приемочных испытаний, поддерживается ли возможность измерения

производительности?

Удобство использования. Простота и удобство использования программы.

Это требование относится прежде всего к интерфейсу пользователя.

Надежность. Отсутствие отказов и сбоев в работе программ, а также

простота исправления дефектов и ошибок.

Эффективность. Насколько рационально программа относится к ресурсам

(память, процессор) при выполнении своих задач.

67

ПРИЛОЖЕНИЕ 3

Пример оценивания качества вариантов проекта коммерческого

web-сервиса

Постановка задачи.

Дано: Шесть вариантов проекта коммерческого web-сервиса и один

прототип. Используя три фактора качества («юзабилити», навигация по

сайту, наличие и качество триггеров), сравнить варианты проекта

коммерческого web-сервиса между собой и по отношению к прототипу.

Исследуемые web-сервисы:

Kypi – прототип,

Варианты проекта коммерческого web-сервиса:

1. Wild.ru

2. Bond.ru

3. Q.com

4. zuzu.com

5. ladno.com

6. moda.ru

Рассматриваемые факторы качества web-сервисов:

1. Юзабилити

Термин «юзабилити» вошел в употребление как синоним понятий

«эргономичность», «удобство использования», «дружественность»,

поэтому если речь идет о юзабилити сайтов, то под ним подразумевается

удобство и простота использования сайта.

Важность данного показателя можно объяснить следующим образом:

При одинаковом уровне расходов на рекламу поток клиентов больше

у сайта с высоким уровнем юзабилити, следовательно, стоимость

обращения через сайт – ниже.

68

Продолжение прил. 3

Повышение комфорта пользователя на сайте ведет к повышению

лояльности клиента к компании, поэтому клиенты лучше относятся к

компаниям, у которых удобные сайты.

Компания с более удобным сайтом снижает нагрузку (а, следова-

тельно, и издержки) на менеджеров и call-центр, так как клиенты находят

ответы на нужные им вопросы на сайте.

Уже сейчас высокий уровень юзабилити сайта можно рассматривать

как конкурентное преимущество для компаний, для которых Интернет –

один из способов привлечения клиентов.

2. Навигация по сайту

Система навигации на сайте – это набор гиперссылок, созданный для

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

Навигация по сайту должна быть удобной. Любой пользователь,

потерявшись на сайте или не сумев найти необходимую информацию из-

за запутанных переходов, просто уйдет к конкурентам. Именно поэтому

грамотная навигация – основной критерий для удобства сайта.

3. Наличие и качество триггеров

Продающий триггер – маркетинговый комплекс, который

функционирует по принципу «спускового крючка». Иными словами, мы

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

совершению тех, или иных действий. Триггером могут быть обороты

речи – купить товар, заказать услугу, подписать на канал/рассылку.

Как итог, использование таких оборотов существенно увеличивает уровень

продаж, а также эффективность портала в целом.

К триггерам можно отнести:

Всевозможные награды поощрительного характера, дипломы и т. п.

Возможность обменять купленный товар, вернуть затраченные

средства или оформить страховку.

Информативные и развернутые отзывы о товаре или услуге.

Лайки, репосты или комментарии.

69

Продолжение прил. 3

Детализация факторов качества по критериям:

1. Юзабилити

Приспособленность для людей с плохим зрением

Для людей с плохим зрением важна возможность увеличить шрифты,

иконки или чтобы они изначально были относительно крупного размера,

так как в условиях большого выбора люди предпочтут пропустить

трудночитаемый текст.

Информативность интерфейса

Пользователям нравятся сайты с хорошо организованной

информацией. Большинство людей, ищущих что-то в Интернете,

ограничены во времени. Для них главное – найти интересующую

информацию как можно скорее. Они предпочитают сайты, на которых

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

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

перемещаться по различным разделам сайта.

Общая удовлетворенность

Сайт может иметь высокие оценки по отдельным характеристикам,

однако общее впечатление от сайта может быть не столь высоким.

Браузерная совместимость

Во время разнообразия выбора браузеров важно, чтобы сайт

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

популярных.

2. Навигация по сайту

Простота выполнения заказа

Основной задачей рассматриваемых ресурсов является покупка

одежды по сети, поэтому «Заказ» можно считать ключевой функцией, и

насколько просто и быстро можно ее выполнить может стать

определяющей характеристикой для пользователя.

70

Продолжение прил. 3

Простота поиска и перехода к товарам распродаж

Многие люди предпочитают экономить и выбирать товары,

предложенные на распродажах, и то, насколько быстро люди смогут

увидеть весь ассортимент, предлагаемый на текущих распродажах, тем

лучше у них будет впечатление об интернет-магазине.

Простота перехода к регистрации и личному кабинету

Сложность входа, регистрации и заполнения личной информации, ее

редактирования может стать определяющей для отказа от использования

ресурса.

Структура каталога товаров

Грамотная и понятная организация каталога товаров позволяет

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

оформить на него заказ, что и является ключевым действием пользователя

для интернет-магазина.

3. Наличие и качество триггеров

Возможность обменять/вернуть товар

Зачастую заказанный товар приходит ниже ожидаемого качества, или

если говорить про одежду и обувь, неподходящего размера. Если

пользователи будут знать, что в случае неудачного заказа они смогут

вернуть или обменять товар на более подходящий, они будут смелее

заказывать и выбирать более дорогие товары, так как они не рискуют

своими средствами.

Качество системы отзывов

Качество системы отзывов включает в первую очередь ее наличие в

принципе, а также организацию пространства отзывов и возможность

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

описания своих впечатлений от полученного товара.

71

Продолжение прил. 3

Наличие обратной связи (в том числе в отзывах)

Возможность задать вопросы администратору сайта является важной,

так как многим людям нужна консультация о параметрах товара и других

вопросах, связанных с заказом и получением товара.

Частота появления триггеров

Возникновение подсказок, ярких баннеров может задержать

пользователя на сайте и в результате повышается возможность

выполнения им заказа товара.

Каждый критерий оценивается по метрике с аналогичным названием

с помощью нижеприведенной шкалы в Таблице П1.

Таблица П1. Шкала оценивания

Отлично 5 Хорошо 4

Удовлетворительно 3 Неудовлетворительно 2

Отсутствует 1

Для исследования качества сайтов и выставления оценок используется

метод экспертных оценок.

Экспертная оценка – это оценка параметров процессов или предметов,

которые невозможно непосредственно измерить, применить любые точные

науки, поэтому оценка проводится на основании профессионального опыта

специалиста, как одного, тогда экспертная оценка будет индивидуальной,

так и нескольких, тогда экспертная оценка будет коллективной.

Расчетный метод – использует теоретические или эмпирические

(опытные) знания (базовые знания верстки сайтов).

Для составления рейтинга сайтов и выполнения заключительного

вывода о конкурентоспособности вариантов по сравнению между собой и

прототипу Kypi используется агрегирующая функция в виде взвешенной

суммы.

72

Продолжение прил. 3

Теоретико-множественная структурно-функциональная модель:

M = F(X,P),

где X = (A,B,C) – это множество характеристик качества вариантов

проекта; A – юзабилити; В – навигация; С – качество триггеров.

A = (A1, A2, A3, A4),

где

A1 – Приспособленность для людей с плохим зрением;

A2 – Информативность интерфейса;

A3 – Общая удовлетворенность;

A4 – Браузерная совместимость.

B = (B1, B2, B3, B4),

где

B1 – Простота выполнения заказа;

B2 – Простота поиска и перехода к товарам распродаж;

B3 – Простота перехода к регистрации и личному кабинету;

B4 – Структура каталога товаров.

C = (C1, C2, C3, C4),

где

C1 – Возможность обменять/вернуть товар;

C2 – Качество системы отзывов;

C3 – Наличие обратной связи (в том числе в отзывах);

C4 – Частота появления триггеров.

Переменная Р характеризует вышеприведенные характеристики

качества для прототипа.

Переменная F – это агрегирующая функция в виде взвешен-

ной суммы. Веса в этой функции выбраны экспертно и представлены

в таблице П2.

73

Продолжение прил. 3

Таблица П2. Веса факторов качества

Характеристика Вес Описание Юзабилити 0,5 Описывает в первую очередь удовлетворенность

сайтом, поэтому имеет наивысший вес Навигация 0,3 Описывает простоту выполнения основных

функций, поэтому так же имеет высокий вес Триггеры 0,2 Описывает особенности сайта, которые могут

задержать пользователя, но при этом не выполняют основную задачу ресурса

Результаты оценивания web-сервисов с комментариями представлены ниже.

1. Kypi – прототип Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

2 Абсолютно не приспособлен для людей с плохим зрением. Шрифты мелкие. Отсутствуют кнопки пере-ключения в режим для слабови-дящих. Верстка не приспособлена для экранного диктора

Информативность интерфейса

4 Интерфейс вполне информативен, но могло быть и лучше

Общая удовлетворенность

4 В принципе хорошо

Браузерная совместимость

4 На всех браузерах отображается одинаковая верстка, за исключением Internet Explorer 8, где верстка хоть и сбилась, но не критично

Навигация по сайту Простота выполнения заказа

5 Проще оформить заказ просто не представляется возможным

Простота поиска и перехода к товарам распродаж

5 Довольно просто находить товары, глобальная полоса навигации есть везде

Простота перехода к регистрации и личному кабинету

5 Перейти к личному кабинету можно в 1 клик, а регистрация довольно тривиальна

Структура каталога товаров

4 Отличная структура каталогов, за исключением пары не очевидных пунктов

74

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

4 Возможность возврата есть, но она довольно трудоемкая

Качество системы отзывов

1 Системы отзывов нет

Наличие обратной связи (в том числе в отзывах)

5 Обратная связь работает по телефону и электронной почте. Также есть живой онлайн чат

Частота появления триггеров

4 Триггеров нет, но есть онлайн чат

2. Wild.ru

Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

2 Шрифты мелкие. Отсутствуют кноп-ки переключения в режим для слабовидящих. Верстка не приспо-соблена для экранного диктора

Информативность интерфейса

2 Интерфейс слишком перегружен

Общая удовлетворенность

4 В принципе неплохо

Браузерная совместимость

3 Между браузерами заметны некото-рые, некритичные графические артефакты

Навигация по сайту Простота выполнения заказа

3 Для заказа необходимо быть зарегистрированным, а так же нельзя заказать товар в один клик

Поиск и переход к товарам распродаж

4 Есть система поиска, есть отдельный каталог акций, но крайне скудный

Простота перехода к регистрации и лично-му кабинету

3 Регистрация требует подтверждение по смс

Структура каталога товаров

3 Слишком много категорий первого уровня, плохое дробление категорий

75

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

4 Есть строгая система возврата, но можно вернуть через свою курьер-скую службу

Качество системы отзывов

5 Есть пятизвездочная система отзы-вов, в которой кроме оценки, можно указать такие атрибуты как соответ-ствие размеру, фото, описанию

Наличие обратной связи (в том числе в отзывах)

5 Можно делать звонок с сайта, можно оценивать полезность отзывов, есть форум

Частота появления триггеров

5 Подсказки появляются в меру часто

3. Bond.ru Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

2 Шрифты мелкие. Отсутствуют кноп-ки переключения в режим для слабо-видящих. Верстка не приспособлена для экранного диктора

Информативность интерфейса

4 В меру информативный, не пере-груженный интерфейс. Не хватает иконок

Общая удовлетворенность

3 Много раздражающих всплывающих окон, и перезагрузка страницы по каждому клику

Браузерная совместимость

5 На всех браузерах сайт выглядит одинаково

Навигация по сайту Простота выполнения заказа

5 Довольно просто можно выполнить заказ. Оформление заказа через смс, так же есть подробная инструкция

Поиск и переход к товарам распродаж

5 Есть возможность поиска по названию, есть отдельная категория скидок

Простота перехода к регистрации и личному кабинету

5 Регистрация простая, переход к лич-ному кабинету труда не составляет

Структура каталога товаров

5 Отличная структура каталога, в меру подробная и не перегруженная

76

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

4 Есть возможность вернуть и обме-нять товар, но довольно ограничен-ными вариантами

Качество системы отзывов

4 Реализована 5-балльная система отзывов, есть шкала «Соответствия размеру». Отзывов мало

Наличие обратной связи (в том числе в отзывах)

4 Есть обратная связь, как по телефону так и по электронной почте

Частота появления триггеров

1 Подсказок нет

4. Q.com Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

4 Шрифты среднего размера. Верстка адаптирована для экранного дикто-ра. Отсутствуют кнопки переклю-чения в режим для слабовидящих

Информативность интерфейса

4 Хороший интерфейс, но мало иконок

Общая удовлетворенность

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

Браузерная совместимость

4 Под internet explorer’ом возникают некоторые проблемы

Навигация по сайту Простота выполнения заказа

4 Нельзя сразу же купить товар, нужно обязательно добавлять его в сумку

Простота поиска и перехода к товарам распродаж

5 В виджете поиска всплывают пред-варительные результаты по набран-ному тексту. Также можно посмот-реть акции по категориям

Простота перехода к регистрации и личному кабинету

5 Зарегистрироваться на сайте не составляет труда, личный кабинет доступен в любой части сайта

Структура каталога товаров

4 Каталог в целом приемлемый, но немного нелогичный

77

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

4 Вернуть товар можно всего лишь двумя способами

Качество системы отзывов

4 Есть стандартная 5-балльная систе-ма отзывов

Наличие обратной связи (в том числе в отзывах)

5 Продавец может прокомментировать отзыв, так же с магазином можно связаться при помощи телефона иe-mail

Частота появления триггеров

3 Примерно каждые 10–15 минут всплывает акция на весь экран

5. zuzu.com Характеристика Оценка Комментарий

Юзабилити Приспособленность для людей с плохим зрением

2 Шрифты мелкие. Отсутствуют кноп-ки переключения в режим для слабовидящих. Верстка не приспо-соблена для экранного диктора

Информативность интерфейса

1 Ужасный, урезанный интерфейс

Общая удовлетворенность

1 Обязательная регистрация для про-смотра сайта, урезанный интерфейс

Браузерная совместимость

5 Сайт выглядит везде идентично

Навигация по сайту Простота выполнения заказа

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

Простота поиска и перехода к товарам распродаж

3 Есть полоса поиска, но нельзя посмотреть акционные товары

Простота перехода к регистрации и личному кабинету

3 Без регистрации на сайт невозможно попасть

Структура каталога товаров

1 Категории есть только общие, отображаются в виде картинок

78

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

1 Нет возможности ни обменять ни вернуть товар

Качество системы отзывов

1 Системы отзывов нет

Наличие обратной связи (в том числе в отзывах)

4 Можно связаться по телефону, почте, онлайн-чату для определенного заказа

Частота появления триггеров

1 Подсказок нет

6. ladno.com

Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

1 Абсолютно не приспособлен для людей с плохим зрением. Даже с хорошим зрением текст нечита-бельный

Информативность интерфейса

4 Интерфейс в целом довольно информативный

Общая удовлетворенность

3 Удовлетворительно

Браузерная совместимость

4 Сайт совместим со всеми современ-ными браузерами, но есть некоторые артефакты на ie

Навигация по сайту Простота выполнения заказа

3 Нельзя сразу же купить товар, нужно обязательно добавлять его в сумку

Простота поиска и перехода к товарам распродаж

5 Есть виджет поиска, есть специаль-ная акционная категория

Простота перехода к регистрации и личному кабинету

4 В личный кабинет можно зайти из любой части сайта. Мудреная регистрация

Структура каталога товаров

4 Слишком избыточная структура каталога

79

Продолжение прил. 3

Характеристика Оценка Комментарий Качество триггеров

Возможность обменять/вернуть товар

5 Есть довольно наглядная инструкция как вернуть товар

Качество системы отзывов

4 Система отзывов есть, самих отзывов нет

Наличие обратной связи (в том числе в отзывах)

2 Есть система обратной связи только по телефону

Частота появления триггеров

1 Подсказок нет, вообще

7. moda.ru

Характеристика Оценка Комментарий Юзабилити

Приспособленность для людей с плохим зрением

3 Шрифты среднего размера. Верстка не адаптирована для экранного дик-тора. Отсутствуют кнопки переклю-чения в режим для слабовидящих

Информативность интерфейса

4 Интерфейс достаточно подробный и понятный

Общая удовлетворенность

5 Очень приятный интерфейс и навигация

Браузерная совместимость

5 Совместим со всеми браузерами

Навигация по сайту Простота выполнения заказа

5 Оформить заказ, дело 2 минут

Простота поиска и перехода к товарам распродаж

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

Простота перехода к регистрации и личному кабинету

5 Регистрации проста, можно привя-зать аккаунт к соц. сетям и входить по нажатию одной кнопки

Структура каталога товаров

5 Довольно подробная и понятная структура

80

Продолжение прил. 3

Характеристика Оценка КомментарийКачество триггеров

Возможность обменять/вернуть товар

5 Есть возможность вернуть заказ многими образами

Качество системы отзывов

5 Существует пятизвездочная система отзывов. Сами отзывы есть практи-чески на каждом товаре в том числе негативные

Наличие обратной связи (в том числе в отзывах)

5 Можно напрямую задать вопрос из сайта

Частота появления триггеров

5 Подсказки появляются только тогда, когда они нужны и не раздражают

Общий результат в виде суммарных оценок представлен в таблице

П3, а в таблице П4 представлены результаты оценивания на основе

функции агрегации в виде взвешенной суммы.

Таблица П3. Суммарные оценки

Характерис-тика Kypi Wild.ru Bond.ru Q.com zuzu.com

ladno.com moda.ru

Юзабилити Всего: 14 11 14 12 9 12 17Навигация по сайту Всего: 19 13 20 18 10 16 20Качество триггеров Всего: 14 19 13 16 7 12 20ИТОГО 47 43 47 46 26 40 57

Таблица П4. Результаты оценивания на основе функции агрегации в виде взвешенной суммы

Характерис-тика Kypi Wild.ru Bond.ru Q.com zuzu.com

ladno.com moda.ru

Юзабилити Всего: 7 5,5 7 6 4,5 6 8,5Навигация по сайту Всего: 5,7 3,9 6 5,4 13 4,8 6Качество триггеров Всего: 2,8 3,8 2,6 3,2 1,4 2,4 4ИТОГО 15,5 13,2 15,6 15,6 8,9 13,2 18,5

81

Окончание прил. 3

Выводы.

Согласно приведенному оцениванию по трем факторам качества,

представленным в таблицах П3 и П4, вариант проекта коммерческого

web-сервиса moda.ru демонстрирует лучшие значения итогового качества

по сравнению с прототипом (Kypi) и другими вариантами. Два варианта

Bond.ru и Q.com демонстрируют сравнимое качество с прототипом.

82

ПРИЛОЖЕНИЕ 4

Пример процесса аудита проекта

JIRA.MONGODB.COM

Рассматривается объект аудита – развитие проекта MongoDB за

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

отслеживания задач.

MongoDB – документоориентированная СУБД, которую можно

классифицировать как NoSQL базу данных. Разработка данной СУБД

началась в 2007 году. В 2009 состоялся первый релиз и тогда же проект

перешел в OpenSource – весь исходный код проекта был выложен на

GitHub.

Если рассматривать задачи в проекте по приоритету, можно

отметить, что 76% задач имеют средний приоритет, 17% – низкий и 6% –

высокий.

Такое соотношение в целом говорит о том, что процесс разработки

достаточно качественный и высокоприоритетные задачи появляются

достаточно редко. Что еще более важно – задачи, которые блокируют

работу какого-то функционала, появляются крайне редко. Это говорит о

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

тестируется. Возникающие блокирующие проблемы в основном являются

очень редко встречающимися ситуациями и не затрагивают большую часть

пользователей. Выполнение большого количества задач откладывается

(в среднем 19% и за последний год 26%). Выявлена тенденция к

накоплению задач:

• 4.5 года назад средний возраст невыполненных задач составлял

250 дней;

• 2015-16 год: средний возраст невыполненных задач составляет

825 дней. Он означает, что в проекте значительная нехватка

разработчиков. В проекте оперативно выполняются только самые

простые, быстрые и срочные задачи.

83

Продолжение прил. 3

Отмечается увеличение возраста невыполненных задач более чем

в 3 раза!

Среднее время, которое прошло с момента создания задачи до ее

выполнения, составляет примерно 1.5 месяца. К тому же значительное

количество задач не выполняется даже за 5 месяцев. И это только

усредненные показатели.

В декабре 2015 года были закрыты самые старые задачи: среднее

время жизни задачи среди закрытых доходило до 1.5 лет.

В данный момент проект MongoDB занимает одну из лидирующих

позиций на рынке. Вокруг проекта сформировалось крупное сообщество,

развита инфраструктура. Все это говорит о том, что проект будет

оставаться популярным еще долгое время.

В начале развития проекта компания очень удачно выбрала не только

саму архитектуру проекта, но также и модель распространения, модель

взаимодействия с пользователями.

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

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

отметить, что средний возраст задач в проекте со временем значительно

увеличивается.

Задачи, выполнение которых было отложено, описывают редко

используемый функционал или случаи использования. Большое количество

пользователей не заметит отсутствие функционала, описанного в

отложенных задачах, или же некорректную работу на одной из редких

конфигураций (например, миграция с очень старой версии БД

на текущую).

84

ПРИЛОЖЕНИЕ 5

14 принципов совершенствования качества Всеобщего управления

качеством:

1. Соблюдайте постоянство целей.

2. Примите новую философию: откажитесь от низкого качества

во всем.

3. Откажитесь от повсеместного контроля.

4. Откажитесь от партнерства, основанного только на цене продукции;

установите долгосрочные партнерские отношения; уменьшите

количество поставщиков.

5. Постоянно совершенствуйте систему производства и обслуживания.

6. Практикуйте в организации наставничество и обучение.

7. Внедрите современные методы руководства: функции управления

должны смещаться от контроля количественных показателей

к качественным.

8. Устраните страх: способствуйте тому, чтобы сотрудники

высказывались открыто.

9. Устраните барьеры между подразделениями и сотрудниками

организации.

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

11. Откажитесь от количественных оценок работы.

12. Поддерживайте чувство профессиональной гордости в сотрудниках.

13. Внедрите в организации систему образования

и самосовершенствования сотрудников.

14. Добейтесь приверженности руководства организации идее качества.

85

Учебное электронное издание

АФАНАСЬЕВА Татьяна Васильевна

АФАНАСЬЕВ Александр Николаевич

ОСНОВЫ УПРАВЛЕНИЯ КАЧЕСТВОМ ПРОГРАММНЫХ СРЕДСТВ

Учебное пособие

Редактор Н. А. Евдокимова Технический редактор Ю. С. Лесняк

ЛР № 020640 от 22.10.97.

ЭИ 984. Объем 3,4 Мб.

Печатное издание

Подписано в печать 00.09.2017. Формат 60×84/16. Усл. печ. л. 5,11. Тираж 75 экз. Заказ 814.

Ульяновский государственный технический университет

432027, г. Ульяновск, Сев. Венец, 32. ИПК «Венец» УлГТУ, 432027, г. Ульяновск, Сев. Венец, 32.

Тел.: (8422) 778-113 E-mail: venec@ulstu.ru

venec.ulstu.ru