Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

504 Глава 10

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

таксономию риска SEI [2], модифицированный вопросник, представленный в при-

ложении 6, и подход к ранжированию рисков, применяемый фирмой BMPC и опи-

санный ниже.

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

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

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

Каждому вопросу приписан максимальный вес, отражающий важность дан-

ного вопроса для снижения общего риска по соответствующему атрибуту. Чем вы-

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

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

чтобы на каждый из них можно было дать однозначный ответ: «Да», «Нет», «Час-

тично», «Не знаю» или «Не применим».

Ответ «Да» свидетельствует об отсутствии риска, суть которого сформули-

рована в вопросе.

Ответ «Нет» или «Не знаю» свидетельствует о наличии риска.

Ответ «Частично» также свидетельствует о наличии риска, но дает возмож-

ность эксперту, оценивающему риск, указать вес вопроса, отличный от предлагае-

мого максимального веса.

Ответ «Не применим» соответствует неправомерности задания вопроса для

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

Процедура идентификации и анализа рисков не отличается от представлен-

ной в предыдущих разделах этой главы.

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

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

Метод оценки риска BMPC включает следующие шаги.

Шаг 1. Вычисление ранга риска по одному атрибуту. Ранг риска атрибута

вычисляется исходя из количества вопросов, на которые был дан ответ «Да» или

«Частично». Определяется сумма весов этих ответов. Затем вычисляется общая

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

ответами «Не применим». После этого находится процентное соотношение этих

сумм по следующей формуле

100))(/(

111

⋅−=

∑∑∑

===

VнVVдR

где

Vд

– вес вопроса с ответом «Да» или «Частично»,

к – количество таких ответов,

– вес каждого вопроса,

n – общее количество вопросов, ассоциируемых с атрибутом,

Vн

– вес вопроса с ответом «Не применим»,

t – количество таких ответов.

Шаг.2. Вычисление уровня риска атрибута. Зависимость ранга и уровня рис-

ка представлена в таблице 10.9.

Глава 10 505

Таблица 10.9. Уровни риска

Уровень риска

Низкий Средний Высокий

Ранг

100%-70% 69%-30% 29%-0%

Шаг 3. Вычисление ранга и уровня риска каждого атрибута.

Шаг 4. Вычисление комбинированного риска элемента таксономии путем

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

(или столбиковой диаграммы).

Например, элемент «Требования» состоит из 7 атрибутов. Если по пяти ат-

рибутам был получен высокий риск, а по 2 – средний, то соотношение рисков на

шкале будет 2/7 для среднего и 5/7 для высокого риска (рисунок 10.14).

Низкий (2/7) Высокий (5/7)

Рис. 10.14. Столбиковая диаграмма риска

Шаг 5. Вычисление комбинированного риска по всем элементам.

Шаг 6. Аналогичным образом может быть установлен комбинированный

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

сономии.

Литература к главе 10

1. Higuera R., Haimes Y. Software Risk Management // CMU/SEI-96-TR-012, Pittsburg, Pa.:

Software Engineering Institute, Carnegie Mellon University. –1996. – 49 p.

2. Carr M. et al. Taxonomy-Based Risk Identification // CMU/SEI-93-TR-006, Pittsburg, Pa.:

Software Engineering Institute, Carnegie Mellon University. – 1993. –90 p.

3. ISO/IEC 12207:1995 / Amd.2:2004 Information technology – Software life cycle processes

4. Sisti F., Joseph S. Software Risk Evaluation Method Version 1.0 // CMU/SEI-94-TR-19,

Pittsburg, Pa.: Software Engineering Institute, Carnegie Mellon University. – 1994. – 175 p.

5. Gallagher B et al. Software Acquisition Risk Management Key Process Area (KPA)- A

Guidebook Version 1.0 // CMU/SEI-97-HB-002, Pittsburg, Pa.: Software Engineering Insti-

tute, Carnegie Mellon University. – 1997. – 102 p.

506

Глава 11. МЕТОДОЛОГИИ ПОВЫШЕНИЯ КАЧЕСТВА В

СОВРЕМЕННОЙ ПАРАДИГМЕ

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

11.1.1. Подход к управлению качеством в старой парадигме. Система

Ф.Тейлора

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

чает:

– планирование качества;

– выполнение работы по плану;

– проверку качества и

– регулирование (корректирующие действия).

Несмотря на то, что этот цикл, называемый циклом PDCA (Plan-Do-Check-

Action, План-Работа-Проверка-Корректировка), присутствует и в старой (продукто-

ориентированной), и в новой (процессо-ориентированной) парадигме качества, ме-

ханизмы его осуществления различны.

В старой парадигме качества, представленной системой Ф. Тейлора, доми-

нирующей в управлении производством в первой половине ХХ века, цикл управле-

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

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

лий. Рабочий изготавливал образцы изделий (иногда с дефектами). Технический

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

ровал нарушение допусков («избыток» дефектных образцов). Администратор

«принимал меры» (применял санкции) в виде наказаний или поощрений, утилиза-

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

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

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

тор. Ответственность за качество нес контролер. Администратор заботился о коли-

чественных показателях выпуска, а рабочий – о выполнении личного плана. При

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

лия, плохой технологический процесс, плохое снабжение, плохая обученность) ос-

тавались не выявленными.

В.А. Лапидус в [1] так характеризует этот порок системы Тейлора: «Система

Тейлора предполагает, что если ударить по последнему элементу – исполнителю,

то он либо сам все исправит, либо вытянет всю цепь причин. Но это и есть самое

большое заблуждение. Да, если результат – это ошибка или халатность…самого

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

бом, постарается не повторить ошибку. Но если причина не в нем, то ему наносится

травма, которая лишь усугубляет дело…Когда он (исполнитель) начинает показы-

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

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

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

ее на других, в том числе и на них самих. А это надо пресекать в корне. Система

Тейлора неэффективна, потому что наказывать исполнителей не просто бесполезно,

Глава 11 507

но и вредно, т.к. они лишаются интереса к работе…, их труд превращается в нака-

зание».

Несмотря на недостатки, система Ф. Тейлора «была великолепна для своего

времени… Такие ее элементы, как допуски, наверное, переживут еще многие поко-

ления новых менеджеров».

К сожалению, в сфере отечественного производства программной продукции

(как и, от части, в промышленности), система Тейлора продолжает существовать,

почему и приходится вспоминать о ней в данной работе.

11.1.2. Подход к управлению качеством в новой парадигме. Статистиче-

ское управление процессами

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

и статистическое мышление. Этот подход был предложен в 1924 году В. Шухартом

и далее развивался Э. Демингом, Дж. Джураном, К. Исикавой, Ф. Кросби и др.

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

ся производственный процесс, а цель – попасть в допуск – заменяется новыми: 1)

обеспечить стабильность (устойчивость) процесса; 2) непрерывно уменьшать

вариации стабильного процесса, являющиеся источниками дефектов и несоответ-

ствий.

Почти все характеристики процессов и продуктов демонстрируют изменчи-

вость при многократном измерении. Эта изменчивость имеет два источника:

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

щие для всех измерений заданного атрибута процесса (общие причины);

• явления, причины которых могут быть объяснены и устранены (особые

причины).

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

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

остается постоянной во времени (модель нормального распределения).

Вариации, связанные с общими причинами (нормальные вариации процесса)

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

(людей, машин, материалов, методов). Они случайны, однако находятся в предска-

зуемых пределах (рисунок 11.1 а). Предсказуемость здесь является синонимом кон-

тролируемости (подконтрольности).

Особые причины, вызывающие вариации процесса, находятся за пределами

процесса - неправильный вход процесса, неподготовленные исполнители, непри-

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

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

процессов и изменяют параметры кривой распределения (рисунок 11.1 б). Если все

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

считается стабильным.

Стабильность процесса по отношению к любому заданному атрибуту опреде-

ляется с помощью измерения атрибута и слежения за результатом во времени. Если

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

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

Предложив перенести акцент с отдельных дефектов продукции на вариации

процессов, В.Шухарт указал тем самым на два важных момента:

508 Глава 11

x x

Вариация в

измеренных

значениях

Время

Частость

измеренных

значений

Вариация в

измеренных

значениях

Время

Частость

измеренных

значений

а б

Рис. 11.1. Контролируемые и неконтролируемые вариации процесса

• нужно искать не виновных в дефектах, а определять причины дефектов,

устранять их и предотвращать появление в будущем;

• источниками дефектов являются вариации процессов. Уменьшение ва-

риаций – главная цель управления процессами. Для ее достижения необходимо со-

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

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

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

сом, SPC (от Statistical Process Control). Этот метод также был предложен Шухар-

том в 20-годы и далее использовался его последователями как основа для повыше-

ния качества продукции (см., например, работы К.Исикавы [2], Х.Кумэ [3], а также

электронный учебник по промышленной статистике компании StatSoft, Inc. [4],

доступный в Интернет).

В настоящее время метод SPC применяется в инженерии качества ПС для

контроля стабильности и улучшения отдельных процессов ЖЦ ПС, о чем свиде-

тельствуют работы Э. В. Флорака [5], Веллера [6] и др.

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

SPC и других методов управления процессами и совершенствования процессов, ре-

шаются не только в интересах конкретного проекта ПС, но и всей организации. По-

этому, их решение находится в сфере ответственности, как группы качества, так и

группы инженерии процесса разработки.

11.2. Всеобщее управление качеством

11.2.1. Философия TQM

Всеобщее управление качеством, TQM (от Total Quality Management) – это

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

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

Американское Сообщество контроля качества (ASQC, American Society for

Quality Control) определяет TQM как такой подход к управлению, который приво-

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

Глава 11 509

на удовлетворение потребностей потребителя. TQM базируется на участии всех

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

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

В рамках философии TQM традиционные цели максимизации дохода или

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

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

потребителя продукции, повышения его удовлетворенности изготовленной про-

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

Философия TQM внесла фундаментальное изменение в определение и трак-

товку качества продукции. Она заменила лозунг «все, что ни будет сделано – ку-

пят» другим: «будет делаться то, что купят». А это значит, что качество опреде-

ляется и оценивается потребителем. Стратегия управления процессами обеспечива-

ет достижение «всеобщего качества» во всех аспектах бизнеса, а не только приме-

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

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

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

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

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

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

лица 11.1).

Таблица 11.1. Отличие традиционных и современных подходов к качеству

Принципы традиционного подхода Принципы TQM

Продуктивность и качество - кон-

фликтующие цели

Продуктивность и качество не есть конфлик-

тующими целями

Качество определяется степенью

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

спецификациям или стандартам

Качество определяется способностью продукта

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

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

Качество измеряется степенью не

соответствия продукта специфика-

ции и стандартам

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

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

непрерывно совершенствовать процессы и про-

дукты

Качество продукта достигается бла-

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

Качество достигается благодаря эффективному

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

Если продукт отвечает минималь-

ным стандартам качества, отдельные

дефекты допускаются и остаются не

устраненными

Появление дефектов в продуктах предотвраща-

ется посредством применения технологий управ-

ления процессами

Обеспечение качества - это отдель-

ный вид деятельности (функция),

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

Обеспечение качества – это составляющая всех

видов деятельности (каждой функции) на всех

стадиях жизненного цикла продукта

В плохом качестве продуктов ви-

новны исполнители

За качество продукта ответственно руководство

Деловые отношения между членами

коллектива производителей продук-

та непродолжительны и основаны на

личной финансовой заинтересован-

ности

Командная организация труда. Команду состав-

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

филей. Их деловые отношения основаны на раз-

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

продукта

510 Глава 11

11.2.2. Метод управления Э. Деминга

Философия TQM связывается с именем Э. Деминга, а впервые аббревиатура

TQM была использована NAVAIR (Naval Air Systems Command, Командование

системами морской авиации) в 1985 году при описании японского стиля управле-

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

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

Теперь они известны как положения метода управления Деминга:

1) Обеспечьте постоянство намерений усовершенствования продукции и

услуг.

2) Примите новую философию всеобщего качества.

3) Устраните зависимость качества от массовой инспекции продукта.

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

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

5) Совершенствуйте систему производства и обслуживания непрерывно и на

все времена.

6) Внедрите систему производственного обучения.

7) Назначайте руководителей исходя из принципа реального лидерства в кол-

лективе.

8) Искорените страх потери рабочего места.

9) Поломайте преграды между организационными подразделениями.

10) Не используйте лозунгов, увещеваний и понуканий рабочей силы.

11) Не устанавливайте количественных норм и стандартов работы.

12) Поощряйте гордость за собственное мастерство и качество выполненной

работы.

13) Учредите мощную программу образования и индивидуальной переподго-

товки.

14) Подвигните каждого на то, чтобы преобразить свой труд.

Практические подходы к достижению TQM разнообразны. Например, в

Hughes Aircraft Company для этого последовательно используются такие методоло-

гии, как QFD (см. главу 3), планирование промышленных экспериментов и SPC [7].

В основе выполнения процесса в рамках TQM лежит расширенный цикл

PDCA:

определить потребности потребителя;

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

требностей потребителя;

провести цикл усовершенствования;

зафиксировать успехи (предотвратить отступление назад, обеспечить повто-

ряемость);

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

Подходы PDCA и TQM направлены на повышение качества продукта по-

средством совершенствования производственного процесса - единственного про-

цесса или производственной линии (т.е. варианта модели процессов, включающей

один процесс).

Глава 11 511

11.3. Лестницы восхождения к качеству

Подходы, условно названные здесь «лестницами восхождения», принципи-

ально отличаются от ранее представленных подходов PDCA и TQM, для которых

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

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

В данном случае предполагается, что существует множество идеализирован-

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

Оцениваются не характеристики продуктов, а степень приверженности уста-

новленным процессам. Постепенно внедряя определенное множество процессов (и

подтверждая их внедрение), организация как бы «поднимается» по ступенькам к

вершинам качества – бездефектной разработке ПС и непрерывному совершенство-

ванию процессов.

Примерами таких «лестниц» могут служить модели зрелости:

• СММ (включая SW-CMM, SE-CMM, CMMI) (разработчик SEI, США) (гла-

ва 12),

• BOOTSTRAP (Bootstrap Institute, Великобритания) [8],

• TRILLIUM (Bell Canada, Канада) [9] и др.

Все они предлагают 5-уровневую шкалу зрелости и отличаются спектром

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

Нужно отметить, что «с возрастом» эти модели несколько видоизменились,

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

том ISO/IEC 15504. Однако и сам стандарт, представляющий собой стандартизо-

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

SPICE (Software Process Improvement and Capability determination), продолжает раз-

виваться рабочей группой ISO/IEC JTC1/SC7/WG10 по оцениванию процессов раз-

работки ПО (адрес ее сайта в Интернете: http://www.sqi.gu.edu.au/sc7/wg10).

Наиболее известная и широко применяемая модель зрелости – СММ - уже

была представлена в главе 1, а ее обобщение – СММI рассматривается в главе 12.

11.4. Гибкие технологические линии

11.4.1. Технологическая подготовка разработки

Цель построения гибких технологических линий (ТЛ) – создание условий

быстрой разработки каждой конкретной ПС.

Архитектура ТЛ определяется на этапе технологической подготовки разра-

ботки (ТПР) совместно группой инженерии процесса разработки, группой качества,

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

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

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

низации [10]. По существу, качество создаваемого продукта определяется качест-

вом проведения ТПР (в частности, возможностями приобретения знаний и повтор-

ного использования опыта).

В задачи ТПР входит:

512 Глава 11

• определение состава используемых процессов ЖЦ (из числа регламентиро-

ванных эталонной моделью процессов ЖЦ из ISO/IEC 12207) и минимального на-

бора действий и задач

в этих процессах,

• определение модели ЖЦ и методологии разработки, адекватной потребно-

стям проекта,

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

выполнение процессов (или отдельных действий в процессах).

Инструментально-технологический модуль (ИТМ) - это совокупность

операций, которые:

• выполняются по установленной технологии, реализующей соответствую-

щий метод выполнения действий;

• объединены технологическим маршрутом их выполнения (операционным

сценарием);

• имеют известные предпосылки выполнения, входы и выходы;

• обеспечены информационной, программной и методической поддержкой

выполнения.

Общая структура ИТМ показана на рисунке 11.2.

Вход Выход

Программное, информационное обеспечение

Методическое обеспечение Ресурсы проекта

Технологический маршрут

Рис. 11.2. Структура ИТМ

ИТМ конкретизируют общие профили процессов применительно к отдель-

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

На практике ИТМ представляют собой программные комплексы и методики,

разрабатываемые группой инженерии разработки и/или группой качества в инициа-

тивном порядке (вне договоров с заказчиками). Пример ИТМ для поддержки реги-

страции дефектов в процессе Верификации показан в таблице 11.2 (описание ТМ) и

на рисунке 11.3 (форма для регистрации дефектов в программном комплексе «Ме-

неджер_Якості»).

Таблица 11.2. Состав ИТМ для поддержки процесса верификации

Состав ИТМ Описание составляющих ИТМ

Базовый метод Сквозной контроль, коллегиальная проверка, метод Ортогональ-

ной классификации дефектов (ODC).

Информационная

поддержка

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

данных о выполнении проверок, взгляды (view) для формирова-

ния итоговых отчетов о дефектах. Методики по методам.

В терминологии ДСТУ 3918-99 (и, соответственно, ISO/IEC 12207-95) внутренняя

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

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

Глава 11 513

Состав ИТМ Описание составляющих ИТМ

Инструменталь-

ная поддержка

СУБД Oracle. Oracle Designer’2000. Книга Excel с собственной

панелью инструментов (с макросами на VBA), API-функции для

работы с репозиторием Oracle Designer.

Вход Планы проверок в период выполнения текущего этапа проекта.

Выход Данные о дефектах (в БД). Печатные отчеты о верификации.

Операции 1. Сбор данных о дефектах.

2. Регистрация дефектов по шаблонам форм и сохранение в БД.

3. Получение регламентных отчетов о дефектах.

4. Получение регламентных отчетов о выполнении проверок.

5. Оценка эффективности проверок по метрикам.

Рис. 11.3. Фрагмент ИТМ для поддержки процесса Верификации

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

например, LSD [11] и QIP [12].

Метод LSD (Lean Software Development) (метод «суженной» разработки

ПС) заключается в отсеивании «мало значимых» видов деятельности по разработ-

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

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

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

Метод QIP (Quality Improvement Paradigm) подобен LSD тем, что также ос-

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

вий. Однако кроме цели разработки конкретного программного продукта с необ-