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

Лекция №7. Управление качеством Цель настоящей лекции — представить основные принципы управления качеством и мероприятия, выполняемые в этой области. Прочитав эту главу, вы должны: 1. знать основные процессы управления качеством, а также основные составляющие процесса управления качеством, а именно: обеспечение качества, планирование качества и контроль качества; 2. понимать важность применения стандартов в процессе управления качеством; 3. иметь представление о метрических показателях ПО и о различиях между прогнозируемыми и контролирующими показателями; 4. понимать необходимость систем измерения при оценке показателей качества и знать об ограничениях в процессе измерения показателей ПО. Для многих организаций основным критерием деятельности является достижение высокого уровня качества производимой продукции либо предоставляемых услуг. В наше время невозможна поставка продуктов низкого качества, требующих устранения недоработок после доставки заказчику. К программным продуктам это относится не в меньшей мере, чем к таким промышленным товарам, как автомобили, телевизоры или вычислительная техника. Однако качество программного продукта является достаточно сложным понятием, трудным для определения. Традиционно продукт считается качественным в том случае, если полностью соответствует техническим требованиям. В идеале такое определение должно быть применимо ко всем продуктам, в том числе и к программным, однако здесь нас подстерегают некоторые проблемы. 1. Технические требования ориентированы на те свойства продукта, которые необходимы заказчику. Однако организация-разработчик может также иметь свои требования к разрабатываемому программному продукту (например, удобство сопро­вождения), которые обычно не включаются в технические требования заказчика. 2. Неизвестно, как точно определить и измерить определенные показатели качества (например, то же удобство сопровождения). 3. Трудно создать полную спецификацию программного продукта. Поэтому, хотя созданный программный продукт будет полностью соответствовать спецификации, заказчик все равно может не получить высококачественного продукта. Очевидно, необходимо прилагать усилия для совершенствования спецификации, однако на данном этапе следует смириться с тем, что она будет не лишена недостатков. Таким образом, следует признать существование проблемы несовершенства спецификаций и привести в действие ряд процедур для улучшения качества ПО в рамках ограничений, возникающих вследствие этой проблемы. Особенно это касается таких определяющих качественных характеристик программных продуктов, как удобство сопровождения, переносимость и эффективность, которые детально не определены в технических требованиях, однако оказываются критическими показателями для качества программных систем. В разделе 2, раскрывающем вопросы планирования качества, эти показатели рассматриваются более подробно. Достижение необходимого уровня качества зависит от менеджеров по качеству компании-разработчика. Теоретически управление качеством основывается на принципе определения стандартов и процедурных норм, в соответствии с которыми должно разрабатываться программное обеспечение, а также на проверке выполнения этих норм всеми разработчиками. На практике, однако, понятие управления качеством имеет более емкое содержание. Хорошие менеджеры по управлению качеством стремятся к созданию в компании атмосферы «культивирования качества», где каждый, кто занимается разработкой продукта, берет на себя обязательство достичь наивысшего уровня качества создаваемого продукта. Такие менеджеры стимулируют команду к качественному выполнению работы и к постоянному поиску идей повышения качества. При том, что стандарты и процедурные нормы являются основой качества, опытные менеджеры по управлению качеством осознают значение тех неосязаемых аспектов качества программных продуктов, которые не могут быть включены в стандарты (например, изящество, читабельность и т.п.). Они поддерживают служащих, заинтересованных именно в таких нематериальных аспектах, а также поощряют профессиональное отношение к работе всех членов команды. Процесс управления качеством состоит из трех основных видов деятельности. 1. Обеспечение качества. Определение множества организационных процедур и стандартов в целях создания ПО высокого качества. 2. Планирование качества. Выбор из этого множества соответствующего подмножества процедур и стандартов и адаптация их к данному проекту разработки ПО. 3. Контроль качества. Определение и проведение мероприятий, гарантирующих выполнение нормативных процедур и стандартов качества всеми членами команды разработчиков ПО. Управление качеством предполагает возможность независимого контроля за процессом разработки ПО. Контрольные проектные элементы, получаемые в процессе разработки ПО, являются основой контроля качества. Они тщательно проверяются на соответствие стандартам и целям проекта (рис. 1.). Так как работы, выполняемые по обеспечению и контролю качества, в определенной степени независимы, это предполагает возможность объективного взгляда на процесс разработки ПО, благодаря чему руководство компании может своевременно получить информацию о проблемах или трудностях, которые возникают в работе над проектом. Рис. 1. Управление качеством и разработка ПО (буквой D обозначены контрольные проектные элементы) Процесс управления качеством необходимо отделять от процесса управления проектом с тем, чтобы не ставить вопрос о компромиссе между качеством создаваемого ПО и бюджетом или графиком выполнения проекта. Над контролем качества должна работать независимая команда, которая отчитывается непосредственно руководству компании, минуя звено менеджера проекта. Команда контроля за качеством не должна быть также связана с группами разработки ПО, вместе с тем она берет на себя ответственность за качество на уровне всей организации. Международно признанным стандартом, который любая компания в любых сферах производства может принять за основу развития системы управления качеством, можно назвать серию стандартов ISO 9000, разработанный Международной организации по стандартизации (ISO). ISO 9000 — это целый ряд всевозможных стандартов, применимых как в промышленности, так и в сфере услуг. ISO 9001 является наиболее обобщенным из этих стандартов и относится к организациям, занимающимся разработкой, производством и сопровождением различных товаров. Поддерживающая документация (ISO 9000-3) адаптирует ISO 9000 к разработке программных продуктов. Стандарт ISO 9000 описан во многих книгах. Стандарт ISO 9001 является типовой моделью для процесса обеспечения качества. В этом нормативе описываются разнообразные аспекты данного процесса, а также определяются те стандарты и нормативы, которые должны быть приняты за основу производственной деятельности компании. Так как процесс обеспечения качества не относится к разряду производственных видов деятельности, нормативы здесь детально не описаны. Любая организация, специализирующаяся на определенном виде услуг, должна самостоятельно провести детализацию своих нормативов и представить ее в специальном руководстве по управлению качеством. В табл. 1 показаны те виды деятельности, которые охвачены в модели ISO 9001. Рис. 2. Стандарт ISO 9000 и управление качеством Нормативы по обеспечению качества занесены в специальное руководство, определяющее ход процесса по управлению качеством. В некоторых странах существуют специальные органы, подтверждающие соответствие процесса обеспечения качества, описанного в руководстве организации, стандарту ISO 9001. Более того, заказчики часто требуют от поставщиков сертификат по стандарту ISO 9001 как подтверждение того, насколько серьезно компания относится к изготовлению качественной продукции. Взаимосвязь между ISO 9000, управлением качества и планами обеспечения качества отдельных проектов показана на рис. 2. 1. Обеспечение качества и стандарты Деятельность по обеспечению качества направлена на достижение определенного уровня качества при разработке программного обеспечения. Она предполагает определение или выбор стандартов, применяемых либо к самому процессу разработки ПО, либо к готовому продукту. Эти стандарты могут быть частью процессов производства ПО. В ходе выполнения таких процессов могут применяться средства поддержки, учитывающие выбранные (или разработанные) стандарты качества. В процессе обеспечения качества могут применяться два вида стандартов. 1. Стандарты на продукцию. Применимы к уже готовым программным продуктам. Они включают стандарты на сопроводительную документацию, например структуру документа, описывающего системные требования, а также такие стандарты, как, например, стандарт заголовка комментариев в определении класса объекта, стандарты написания программного кода, определяющие способ использования языка программирования. 2. Стандарты на процесс создания ПО. Определяют ход самого процесса создания программного продукта, например разработку спецификации, процессы проектирования и аттестации. Кроме того, они могут описывать документацию, создаваемую в ходе выполнения этих процессов. Между стандартами на продукцию и стандартами на процесс существует очень сильная взаимосвязь. Стандарты на продукцию применимы к результату процесса разработки ПО, а стандарты на процесс в большинстве случаев подразумевают выполнение определенных действий, направленных на получение товара, соответствующего стандартам на продукцию. Более подробно этот вопрос рассматривается в разделе 1.2. Стандарты в разработке программной продукции важны по целому ряду причин, основные из которых перечислены ниже. 1. Стандарты аккумулируют все лучшее из практической деятельности по созданию ПО. Как правило, практические знания приобретаются путем долгого поиска и ошибок. Привнесение этого опыта в определенный стандарт помогает избежать повторения прошлых ошибок. Стандарты в данном случае собирают знания и опыт, имеющие значение для организации-разработчика. 2. Стандарты предоставляют необходимую основу для реализации процесса обеспечения качества. Имея в наличии стандарты, обобщающие лучшие знания и опыт, для обеспечения качества достаточно контролировать, чтобы они выполнялись в процессе создания ПО. 3. Стандарты незаменимы, когда работа переходит от одного сотрудника к другому. В этом случае деятельность всех специалистов в организации подчиняется единому нормативу. Следовательно, требуется меньше затрат на изучение сотрудником новой работы. Создание стандартов по разработке ПО — процесс долгий и утомительный. Такие национальные и международные организации, как Министерство обороны США, Американский национальный институт стандартизации (ANSI), Британский институт стандартов (BSI), НАТО, Институт инженеров по электротехнике и электронике (IEEE), специализируются на создании общих стандартов, которые могут применяться к широкому диапазону возможных программных проектов. Такие органы, как НАТО, или другие оборонные организации могут требовать соблюдения их собственных стандартов в контрактах на соз­дание программного обеспечения. Национальные (американские) и международные стандарты были разработаны для таких сфер программной деятельности, как терминология инженерии ПО, языки программирования типа Ada и C++, система обозначений, например для символов в схемах и чертежах, процедуры для разработки системных требований, деятельность по обеспечению качества, а также для аттестации ПО. Группы обеспечения качества, которые занимаются составлением стандартов, обычно основывают нормативы организации на общих национальных и международных стандартах. Используя их в качестве отправного пункта, группа обеспечения качества разрабатывает свой «справочник» по стандартам. В нем содержатся стандарты, отражающие специфику деятельности данной организации. В табл. 2 приведены примеры стандартов, которые могут входить в состав такого справочника. Таблица 2. Стандарты на продукцию и процесс разработки ПО Стандарты на продукцию Стандарты на процесс разработки ПО Форма пересмотра архитектуры ПО Руководство по проведению пересмотра архитектуры ПО Структура документа, содержащего системные требования Представление документации по нормативам ЕЭС Формат заголовков программ и процедур Процесс выпуска версии ПО Стиль программирования языка Java Процесс утверждения плана реализации проекта Формат плана реализации проекта Процесс контроля изменений Форма запроса на изменения Процесс регистрации выполнения тестов Отметим, что в Советским Союзе процесс создания ПО регламентировался стандартами ГОСТ ЕСПД (Единая система программной документации - серия ГОСТ I9.XXX). В настоящее время в России принят ряд стандартов создания автоматизированных систем, в состав которых входит программные компоненты: ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» и др. Однако эти стандарты имеют ряд недостатков, а некоторые их положения просто устарели. Поэтому отечественные разработчики ПО чаще используют современные международные стандарты. Иногда специалисты по разработке ПО относятся к стандартам как к бюрократическому наследию, неприменимому к разработке ПО. Особенно это проявляется при выполнении такой утомительной и скучной (однако необходимой для соблюдения стандартов) процедуры, как заполнение всевозможных форм и регистрация работ. Конечно, с общей идеей полезности стандартов все согласны, однако при этом разработчики находят любую удобную причину, по которой именно для их проекта эти стандарты не так уж необходимы. Чтобы не возникало подобных проблем в работе, менеджеры по качеству, отвечающие за разработку стандартов, должны быть достаточно подготовленными и действовать следующим образом. 1. Вовлечь самих программистов в разработку стандартов. Они должны ясно понимать, с какой целью разрабатывается стандарт, и четко следовать установленным правилам и нормативам. Важно, чтобы документ с описанием стандарта включал не только изложение самого норматива качества, но и объяснение необходимости именно этого норматива. 2. Регулярно просматривать и обновлять стандарты, чтобы идти в ногу с быстро развивающимися технологиями. Как только стандарт разработан, его помещают в справочник организации по стандартам, где его холят и лелеют, меняя с большой неохотой. Справочник по стандартам — вещь для организации необходимая, однако он должен развиваться по мере развития новых технологий. 3. Подумать о том, чтобы обеспечить поддержку стандартов программными средствами везде, где только можно. Всяческие «канцелярские» стандарты вызывают огромное количество жалоб, связанных с нудной и утомительной работой по их выполнению. Если же имеются в наличии средства поддержки, выполнение стандартов не требует больших усилий. Стандарты на процессы разработки ПО также могут вызвать ряд проблем, если ставят перед командой разработчиков практически неосуществимые задачи. Такие стандарты дают руководящие советы по выполнению работы, при этом менеджеры проектов могут интерпретировать их каждый по-своему. Нет смысла указывать определенное направление работы, если оно неприменимо к данному проекту или к самой команде разработчиков. Поэтому менеджер проекта должен иметь право изменять стандарты процесса создания ПО в соответствии со специфическими условиями именно данного проекта. Здесь следует оговориться, что это утверждение не относится к стандартам на качество готовой продукции и на процесс сопровождения программной системы, которые могут быть изменены только после глубокого изучения данного вопроса. Менеджер проекта и менеджер по управлению качеством могут легко избежать подводных камней, связанных с «неподходящими» стандартами, путем тщательной разработки плана мероприятий по обеспечению качества. Именно они должны решить, какие стандарты из справочника можно использовать без изменений, какие из них подлежат изменению, а какие следует исключить. Иногда возникает необходимость в разработке нового стандарта, что может быть вызвано условиями выполнения определенного проекта. Например, требуется установить стандарт для формальной спецификации, если прежде в проектах он не использовался. Такие стандарты должны разрабатываться в процессе вы­полнения проекта. 1.1. Стандарты на техническую документацию Необходимость стандартов на документацию в программном проекте становится очевидной, если не существует никакого другого реального способа отображения процесса разработки ПО. Стандартные документы имеют четкую последовательную структуру, вид и качество, а значит, их легко читать и воспринимать. Существует три типа стандартов па документацию. 1. Стандарты па процесс создания документации. Определяют способ создания технической документации. 2. Стандарты на документ. Определяют структуру и внешний вид документов. 3. Стандарты на обмен документами. Гарантируют совместимость всех электронных версий документов. Стандарт на процесс создания документации предоставляет описание способа изго­товления документов. Он включает описания действий по созданию документов и предполагает программные средства для их создания. Кроме этого, нужно описать процедуры проверки и редактирования документов, благодаря которым обеспечивается необходимый уровень их качества. Стандарты качества на процесс документирования должны быть достаточно гибкими, чтобы их можно было применять ко всем типам документации. Естественно, совсем необязательно проводить детальные проверки качества рабочей документации или служебных записок. Однако при работе с официальными документами, имеющими отношение к дальнейшей разработке продукта либо предназначенными для заказчика, нужно иметь установленную процедуру проверки их качества. На рис. 3 показана одна из возможных моделей такого процесса. Рис. 3. Процесс создания документации, включающий проверку качества документов Этапы сбора, учета и внесения замечаний в проект или очередную версию документа повторяются до тех пор, пока не будет создан документ соответствующего уровня качества. Уровень качества документа зависит от типа документации и от того, кому предназначен данный документ. Стандарты на документацию следует применять ко всем документам, которые создаются в процессе работы над программным продуктом. Такие документы должны быть одинаковыми по стилю изложения и внешнему виду, а документы, которые относятся к одному типу, должны также иметь одинаковую структуру. Несмотря на то, что стандарты на документацию могут быть адаптированы к определенного вида проектам, все же для организации неплохо было бы выработать собственный «фирменный» стиль, применяемый ко всем документам. Приведем примеры различных стандартов на документацию. 1. Стандарты идентификационных документов. В процессе создания больших систем производятся тысячи документов, каждому из которых должно быть присвоено уникальное имя, т.е. каждый документ должен быть идентифицирован по определенной системе. Для формальных документов может применяться формальный идентификатор, определенный менеджером по конфигурации. Для неформальных документов идентификатор может быть определен менеджером проекта. 2. Стандарты на структуру документа. Каждый класс документов, создаваемый в процессе разработки ПО, должен иметь стандартную структуру. Стандартами на структуру определяются разделы, которые входят в документ, а также элементы форматирования и макетирования документа, например нумерация страниц, содержание верхнего и нижнего колонтитулов, нумерация разделов и подразделов. 3. Стандарты внешнего вида документации. Эти стандарты определяют «фирменный» стиль документов: использование шрифтов и стилей, логотипов, названия фирмы, цветовых выделений для элементов структуры документа и т.д. 4. Стандарты на обновление документации. Так как документы должны отображать изменения, возникающие в процессе разработки системы, желательно применять последовательный способ обозначения изменений в документации. Чтобы выделить новую, измененную версию документа, для печатных документов можно использовать обложки разных цветов, а для выделения изменений в тексте можно делать цветовые указатели на полях. Особая роль отводится стандарту на совместимость документов, так как часто приходится работать с разными электронными версиями документов. Использование стандартов на совместимость позволяет осуществлять передачу документов в электронном виде и при необходимости восстанавливать их в первоначальном виде. Поскольку стандартами на процесс создания документации предусмотрено использование инструментальных средств, стандарты на совместимость очерчивают сферу и способ использования таких средств в работе над документами. В качестве примера подобных стандартов на совместимость можно привести согласованный стандарт на комплект макросов при форматировании текста документа или на использование стандартной таблицы стилей (шаблонов) при работе с системами обработки текстов. Кроме того, введение в действие стандартов на совместимость может ограничить количество используемых шрифтов и стилей, что вызвано различными возможностями принтеров и компьютерных дисплеев. 1.2. Качество процесса создания ПО и качество программного продукта Правило, лежащее в основе успешного управления качеством, гласит, что качество процесса производства ПО влияет и на качество готового программного продукта. Это предположение первоначально появилось в сфере промышленного производства, где качество продукции напрямую связано с качеством процесса ее изготовления. Разумеется, если говорить об автоматизированных системах массового производства, то должный уровень качества их работы автоматически обеспечивает высокое качество продукции. Такой подход показан на рис. 4. Рис. 4. Обеспечение качества продукции путем достижения должного уровня качества производственного процесса В сфере разработки ПО качество процесса имеет особое значение. Это вызвано трудностью оценивания таких свойств программного обеспечения, как, например, удобство сопровождения, поскольку его можно оценить только после длительного периода использования программы. В данной области процесс улучшения качества начинается с изучения качественных продуктов и процессов их разработки, далее следует обобщение результатов исследования с последующим применением их в других проектах. Однако взаимосвязь между качеством процесса и качеством готового продукта не так проста, как кажется на первый взгляд. Изменение процесса производства не всегда ведет к появлению качественного программного продукта. В промышленных отраслях связь между процессом производства и качеством продукта более очевидна, поскольку эти процессы относительно легко поддаются стандартизации и управлению. Сразу после проверки произведенных пробных изделий можно запускать серийное изготовление качественной продукции. Совсем другое дело с программным обеспечением, которое не изготавливается в прямом смысле этого слова, а разрабатывается. Поэтому процесс разработки ПО скорее относится к созидательным, нежели к механическим процессам, что многократно увеличивает значимость индивидуальных навыков и опыта разработчиков ПО. Кроме того, на качество программного продукта, независимо от использованного процесса создания ПО. могут оказывать влияние и внешние факторы, такие, как новизна проекта или коммерческое давление в целях более быстрого выпуска программного продукта. Несмотря на все эти сложности, качество процесса создания ПО имеет большое значение для разработки качественных программных продуктов. Поэтому управление качеством включает в себя следующие функции. 1. Определение стандартов на процесс разработки ПО, например способ проведение проверок создаваемого ПО, времени, когда их следует проводить, и т.д. 2. Наблюдение над процессом разработки с тем, чтобы обеспечить выполнение стандартов. 3. Создание отчетности о ходе процесса разработки для менеджера проекта и заказчика программного обеспечения. Самая большая сложность в обеспечении качества, основанном на стандартизации процесса создания ПО, состоит в том, что не всегда предписанный процесс создания подходит к данному типу разрабатываемого программного продукта. Например, стандарты на процесс создания ПО предусматривают завершение работы над требованиями и их утверждение до начала этапа написания программного кода. Однако для некоторых систем может потребоваться прототипирование, что подразумевает написание соответствующих программ. Группа по обеспечению качества может предложить не выполнять прототипирования, так как все равно его качество невозможно проверить. В таких случаях требуется вмешательство старшего руководства компании, чтобы удостовериться в том, что процесс обеспечения качества служит поддержкой, а не помехой в выполнении проекта. 2. Планирование качества Планирование качества нужно начинать на самой ранней стадии проекта. План обес­печения качества должен основываться на предполагаемых свойствах продукта, требуется также определить метод их проверки. Для этого необходимо определить понятие «должный уровень качества» программного продукта. Без этого программисты могут работать, делая акценты на разных свойствах продукта. Результат процесса планирования качества — это план обеспечения качества. Из всех организационных стандартов в плане обеспечения качества должны быть ото­бражены наиболее подходящие к создаваемому программному продукту или процессу его разработки. Если в проекте используются новые методы или инструментальные средства, то могут быть добавлены новые стандарты к уже существующим. Основываясь на опыте разработки ПО, можно предложить приведенную ниже структуру плана обеспечения качества. 1. Представление продукта. Описание продукта, намечаемый рынок его сбыта, а также ожидаемые свойства. 2. Планы выпуска продукта. Назначение крайних сроков выпуска версий программного продукта, распределение ответственности за разработку продукта и его обслуживание. S. Описания процессов. Представление процессов разработки и обслуживания про­граммного продукта в ходе выполнения проекта и управления им. 4. Цели качества. Планы и цели обеспечения качества продукта, включая описание наиболее важных его характеристик. 5. Риски и управление рисками. Описание основных видов риска, которые могут оказать влияние на уровень качества продукта, и мероприятия, направленные на снижение рисков. При работе над планами обеспечения качества важно, чтобы они были как можно более краткими. Если документ будет слишком длинным, то специалисты вряд ли дочитают его до конца, что сведет на нет идею создания плана обеспечения качества. Существует ряд потенциальных показателей качества продукта (табл. 3), которые должны учитываться при составлении плана обеспечения качества. На практике трудно создать настолько совершенную систему, чтобы она идеально удовлетворяла всем этим показателям, однако для конкретного проекта можно выбрать наиболее важные показатели и спланировать пути их достижения. План обеспечения качества должен определять основные качественные показатели разрабатываемого продукта. Например, эффективность системы может иметь первосте­пенную важность, но сравнению с другим показателями. Если это будет отображено в плане, то специалисты смогут найти компромисс между различными показателями системы. В плане также должен быть указан процесс оценивания уровня качества. Таблица 3. Показатели качества программных продуктов Надежность Понятность Переносимость Безопасность Возможность тестирования Удобство эксплуатации Безотказность Адаптируемость Возможность повторного использования Устойчивость к внешним воздействиям Модульность Эффективность 3. Контроль качества Контроль качества предусматривает наблюдение за процессом разработки ПО с тем, чтобы гарантировать соблюдение определенных нормативных процедур и стандартов. Как отмечалось раннее (см. рис. 1), контрольные проектные элементы проверяются согласно четко определенным стандартам процесса контроля качества. Процесс контроля качества имеет собственный набор процедур и отчетов, которые могут быть использованы в процессе разработки ПО. Они должны иметь четкую структуру и быть понятными специалистам по разработке ПО. Существует два взаимодополняющих подхода к процессу контроля качества. 1. Проверки качества, когда программный продукт, сопровождающая документация и процесс разработки анализируются группой проверяющих. Эта группа ответственна за проверку соблюдения стандартов проекта, а также за соответствие документации этим стандартам. Любые отклонения от стандартов регистрируются и подаются на рассмотрение менеджеру проекта. 2. Автоматизированная оценка ПО, когда программный продукт и его документация проверяются специальной компьютерной программой, которая сопоставляет их со стандартами данного проекта. В такую автоматизированную проверку можно вклю­чить количественный контроль некоторых характеристик ПО. Проблема измерения показателей качества ПО обсуждается в разделе 4. 3.1. Проверки качества Проверки — это наиболее распространенный способ оценивания качества процесса разработки и создаваемого продукта. В проверку, как правило, включена группа специалистов, которые изучают отдельный этап или процесс разработки в целом, создаваемую систему и сопровождающую документацию для выявления возможных проблем. Результаты такой проверки обычно заносятся в официальный отчет и передаются разработчикам системы либо лицу, ответственному за исправление ошибок. В табл. 4 представлены некоторые типы проверок. Промежуточные проверки являются частью процесса управления проектом. В этой лекции проверки рассматриваются как часть процесса управления качеством. Таблица 4. Типы проверок Тип проверки Основная цель проверки Инспекция структуры и программного кода системы Выявить ошибки в требованиях, структуре и программном коде. Проверка проводится в соответствии с технологической картой возможных ошибок Промежуточные проверки Предоставить руководству отчеты о ходе выполнения проекта. Это может быть проверка и процесса разработки, и создаваемого продукта, а также выполнения бюджета и графика проекта Проверки качества Провести технический анализ компонентов продукта и документации с тем, чтобы найти несоответствия между спецификацией и структурой системы, программным кодом и документацией, а также гарантировать выполнение определенных стандартов качества Целью команды проверки качества является обнаружение ошибок и противоречий с тем, чтобы довести их до сведения разработчика или автора документации. Все проверки основаны на документации, однако они не ограничены только спецификацией, структурой системы или программным кодом. Проверке подвергаются и такие документы, как модель процесса разработки, планы тестирования, процедура управления конфигурацией, стандарты процесса разработки и руководство пользователя. В команду проверки качества должны быть включены те специалисты, которые могут принести наибольшую пользу. Например, при проверке структуры подсистем в такую ко­манду должны входить программисты, которые участвовали в разработке подобных под­систем. Благодаря таким специалистам может появиться, например, новый взгляд на ин­терфейсы подсистем. Ядром команды по проверке качества должно быть не более 3-4 человек, отобранных в качестве основных проверяющих. Один из них должен быть старшим, т.е. ответственным за принятие технический решений. Основные проверяющие могут приглашать других разра­ботчиков проекта для участия в проверке. Им не обязательно принимать участие во всей проверке. Достаточно, чтобы они проверяли те части проекта, которые могут непосредст­венно повлиять на их работу. Кроме того, команда проверки качества может раздать тести­руемый документ, чтобы получить письменные комментарии от других членов проекта. Документы должны быть розданы до начала проверки с тем, чтобы рецензенты могли ознакомиться с ними и понять их суть. Хотя такие задержки и затягивают иногда процесс разработки, но проверка не будет иметь смысла, если команда не разберется в документации перед проведением проверки. Сама проверка должна быть достаточно короткой (не более двух часов). Автор анализируемого документа должен «пройтись» по документу вместе с командой проверки. Один из членов команды должен руководить процессом проверки, а другой — записывать все ее результаты. Во время проведения проверки возглавляющий ее специалист ответственен за то, чтобы были рассмотрены все письменные замечания. По окончании проверки все действия проверяющих должны быть занесены в отчет, который подписывается проверяемым и лицом, возглавляющим проверку. В дальнейшем эти отчеты составят официальную документацию по проекту. Если были обнаружены лишь незначительные недостатки, проводить следующую проверку нет необходимости. Возглавляющий проверку специалист также несет ответственность за выполнение необходимых изменений в проекте. При необходимости внесения больших изменений нужно провести еще одну проверку. 4. Измерение показателей ПО Измерения в области программного обеспечения —это получение числовых значений определенных показателей программного продукта или процесса его разработки. Значения этих показателей сравнивают между собой и со стандартами, применяемыми в данной организации. На основе этих сравнений можно сделать выводы о качестве продукта или процесса разработки. Например, организация планирует ввести новое программное средство для тестирования ПО. Перед тем как это средство будет введено в стандарт, нужно определить количество дефектов программной системы, обнаруженных за определенный период времени другими средствами тестирования. Затем следует повторить процесс тес­тирования новым средством. Если при этом будет обнаружено большее количество ошибок за то же время, значит, это средство окажется действительно полезным для проведения проверки правильности программного кода. Ряд крупных компаний, таких, как Hewlett-Packard и AT&T, ввели свои системы измерения показателей ПО и используют их в процессе управления качеством. Основное внимание в этих системах уделяется определению показателей, указывающих на присутствие дефектов в ПО, а также показателям, используемым в процессе проверки и аттестации программных продуктов. В литературе рассмотрен вопрос введения таких систем в промышленное производство. В руководстве компании AMI дается подробное описание такой системы измерений и ее применения для усовершенствования процесса разработки ПО. Вместе с тем системы измерения показателей ПО пока не получили широкого распро­странения. Основной причиной является отсутствие очевидной пользы от этих систем — во многих организациях-разработчиках процесс создания программных продуктов все еще организован не лучшим образом и недостаточно развит для ведения подобных систем измерений. Кроме того, нет четких стандартов показателей ПО, отсюда ограниченный уровень технической поддержки по сбору и анализу подобных данных. Большинство компаний не готовы к введению систем измерений показателей ПО, поскольку не разработа­ны соответствующие стандарты и отсутствуют средства их поддержки. Показатели программного обеспечения — это количественные показатели, которые можно измерить и которые характеризуют программную систему, процесс разработки ПО или сопровождающую документацию. Например, это может быть размер программного продукта, равный количеству строк кода, индекс непонятности, который является мерой читабельности письменного текста, количество зарегистрированных ошибок в программном продукте, а также количество человеко-дней, требующихся для создания системных компонентов. Показатели делятся на два вида: контрольные и прогнозируемые. Контрольные показатели обычно соотносятся с процессом разработки ПО, а прогнозируемые — с готовым программным продуктом. Примером контрольного показателя (показателя процесса) может быть среднее значение затрат и времени, расходуемых на исправление зарегистрированных неполадок. В качестве примера прогнозируемого показателя можно привести цикломатическую сложность программных модулей (цикломатическая сложность программного модуля характеризуется цикломатическим числам графа, отображающего структуру этого модуля, когда каждой точке ветвления программы соответствует вершина графа), среднюю длину идентификаторов в программе, а также количество атрибутов и операторов, относящихся к объектам системной структуры. На решения по управлению проектом могут оказать влияние как контрольные, так и прогнозируемые показатели (рис. 5). Рис. 5. Контрольные и прогнозируемые показатели Часто невозможно провести прямое оценивание таких показателей качества программного продукта, как удобство сопровождения, сложность или понятность, поскольку они слагаются из самых разных факторов. Поэтому для их оценивания не существует прямой системы показателей. Отсюда следует вывод, что для начала необходимо измерить какой-либо внутренний показатель ПО (например, размер программы), а затем предположить, что существует взаимосвязь между тем, что мы можем измерить, и тем, что мы в действительности хотели бы узнать, В идеале между внутренними и внешними характеристиками программного продукта должна быть четкая прямая взаимосвязь, поддающаяся проверке. На рис. 6 показаны внешние показатели качества, которые нас заинтересуют, и внутренние показатели ПО, которые можно измерить и соотнести с внешними свойствами. Между внешними и внутренними показателями ПО предполагается определенная взаимосвязь, однако неизвестно, какого вида эта взаимосвязь. Если необходимо определить внешние характеристики ПО путем измерения внутренних показателей, следует соблюсти три обязательных условия. 1. Точное и аккуратное проведение измерения внутренних показателей. 2. Наличие взаимосвязи между измеренными показателями и внешними поведенческими характеристиками ПО. 3. Обязательное изучение этой взаимосвязи, ее проверка и выражение в виде формулы или модели. Формулировка модели предусматривает определение вида функциональной зависимости между внешними и внутренними показателями (линейный, экспоненциальный или другой вид зависимости), что осуществляется путем анализа собранных данных, определения параметров, которые должны быть включены в модель, а также калибровки существующих данных. При построении такой модели необходим в первую очередь достаточный опыт работы со статистическими методами. Поэтому в такую деятельность следует вовлечь специалистов по математической статистике. Рис. 6. Взаимосвязь между внутренними и внешними показателями ПО 4.1. Процесс измерения Процесс измерения показателей ПО, который может быть частью контроля качества, показан на рис. 7. Каждый компонент системы анализируется отдельно, значения одинаковых показателей сравниваются между собой, а иногда и с аналогичными статистическими данными других проектов. Аномальные данные измерений по какому-либо системному компоненту должны стать поводом для проведения мероприятий по обеспечению качества этого компонента. Рис. 7. Процесс измерения показателей, программного продукта Процесс измерений состоит из пяти основных этапов. 1. Выбор показателей для измерения. Для начала следует сформулировать те вопросы, на которые необходимо получить ответ посредством измерения, после чего опреде­ляются измеряемые показатели. Не нужно выбирать показатели, которые не соот­ветствуют поставленным задачам. Парадигма «цель-вопрос-измерение»" является одним из лучших подходов к выбору измеряемых показателей. 2. Отбор системных компонентов. Часто совсем необязательно оценивать показатели всех компонентов программной системы. В одних случаях для анализа целесообразно сделать представительную выборку компонентов; в других достаточно оценить наиболее важные (критические) компоненты системы. 3. Измерение показателей компонентов. Это процесс измерения значений выбранных показателей для отобранных компонентов. Для этого обычно используются средства автоматического сбора данных. Они могут быть либо отдельными специальными средствами, либо встроенными в CASE-средства. 4. Определение аномальных данных. Значения измеренных показателей нужно сравнить между собой и с предыдущими измерениями, занесенными в базу данных. Важно отследить необычно высокие или, наоборот, низкие значения каждого вида показателей, так как компоненты с такими показателями могут быть причиной возникновения последующих проблем. 5. Анализ аномальных компонентов. Определив компоненты с аномальными показателями, их следует изучить для выявления возможного отрицательного влияния на качество программного продукта в целом. Например, аномальное значение такого показателя, как сложность компонента, не обязательно будет означать его плохое качество. Может быть другая причина для высокого значения этого показателя, которая не ведет к снижению качества. Все собранные данные должны сохраняться в качестве ресурса организации, при этом обязателен анализ архивных данных по всем проектам, даже если они не используются в текущем проекте. После создания достаточно большой базы данных измерений на основе сравнения информации по различным проектам можно организовать специальную систему измерения показателей, которая отвечает нуждам данной организации. 4.2. Показатели программного продукта Эти показатели отображают свойства программного продукта в целом. К сожалению, такие легко измеримые показатели, как размер и цикломатическая сложность программы, не имеют прямой и универсальной взаимосвязи с такими показателями качества, как надеж­ность или удобство сопровождения. Эти взаимосвязи могут изменяться в процессе разработки продукта, зависят от технологии разработки и типа разрабатываемой программной системы. Организации-разработчики обязательно должны вести базу статистических данных. Именно такая база данных поможет в дальнейшем разобраться, какие свойства продукта соотносятся с теми показателями качества, в которых заинтересована организация. Показатели программного продукта можно разделить на два класса. 1. Динамические показатели, которые измеряются в процессе выполнения программы. 2. Статические показатели, которые отражают статические представления системы, например структуру, программный код или документацию. Эти два класса показателей соотносятся с разными свойствами продукта. Динамические показатели помогают в оценке эффективности и надежности программы, тогда как с помощью статических показателей можно оценить сложность, понятность и удобство эксплуатации программной системы. Динамические показатели тесно связаны с показателями качества ПО. Относительно легко измерить время выполнения определенных функций и оценить время, необходимое для запуска системы. Именно эти показатели соотносятся с эффективностью системы. Таким же образом можно регистрировать количество системных ошибок и их типы, что напрямую связано с надежностью системы. Статические показатели, как правило, имеют отдаленное отношение к качественным характеристикам ПО. Было предложено достаточное количество таких показателей, с которыми был проведен ряд экспериментов для выявления и оценки возможных взаимосвязей между этими показателями и такими свойствами, как сложность, понятность и удобство эксплуатации системы. В табл. 5 приведено несколько статических показателей, которые могут использоваться при оценке качества. Среди них объем программного кода и сложность управления являются наиболее надежными показателями для прогнозирования сложности, понятности и удобства сопровождения программного продукта. С начала 90-х годов был проведен ряд исследований для объектно-ориентированных показателей. Одни из них совпадают с показателями, приведенными в табл. 5, другие являются следствием объектно-ориентированного подхода к созданию ПО. Некоторые объектно-ориентированные показатели представлены в табл. 6. Они менее показательны по сравнению с аналогами из табл. 5, которые ориентированы на функциональный подход к созданию систем. Множество показателей, выбираемых для измерения, зависят от проекта, целей команды управления качеством и типа разрабатываемого ПО. Все показатели, описанные в табл. 5 и 6, могут использоваться в тех или иных случаях. Однако бывают ситуации, когда эти по­казатели неприменимы. В этом случае компания-разработчик должна экспериментировать с различными показателями для поиска наиболее полно отвечающих ее потребностям. Таблица 6. Объектно-ориентированные показатели Показатели Описание Глубина дерева наследования Представляет количество дискретных уровней в дереве наследования, когда подклассы наследуют свойства и функции (методы) родительских классов. Чем глубже дерево наследования, тем сложнее структура системы Метод ветвления по входу и выходу Этот метод тесно связан с нагрузочными множителями по входу и выходу, описанными ранее, и означает, по существу, то же самое. Однако может оказаться полезным разделение вызовов от методов внутри объекта и вызовов от внешних методов Взвешенные методы на класс Означает количество методов, включенных в класс, средневзвешенных по сложности каждого метода. Таким образом, простой метод может иметь сложность 1, у более сложного метода будет более высокое значение сложности. Чем выше значение этого показателя, тем сложнее будет класс объектов. Сложные объекты более трудны для понимания Количество игнорируемых операций (методов) Это количество операций класса, которые игнорируются в подклассе. Высокое значение этого показателя говорит о том, что используемые классы плохо подходят в качестве родительских для данных подклассов