logo
lekciya_8

25.1. Обеспечение качества и стандарты

Деятельность по обеспечению качества направлена на достижение определенного уровня качества при разработке программного обеспечения. Она предполагает определение или выбор стандартов, применяемых либо к самому процессу разработки ПО, либо к готовому продукту. Эти стандарты могут быть частью процессов производства ПО. В ходе выполнения таких процессов могут применяться средства поддержки, учитывающие выбранные (или разработанные) стандарты качества.

В процессе обеспечения качества могут применяться два вида стандартов:

1. Стандарты на продукцию. Применимы к уже готовым программным продуктам. Они включают стандарты на сопроводительную документацию, например структуру документа, описывающего системные требования, а также такие стандарты, как, например, стандарт заголовка комментариев в определении класса объекта, стандарты написания программного кода, определяющие способ использования языка программирования.

2. Стандарты на процесс создания ПО. Определяют ход самого процесса создания программного продукта, например разработку спецификации, процессы проектирования и аттестации. Кроме того, они могут описывать документацию, создаваемую в ходе выполнения этих процессов.

Между стандартами на продукцию и стандартами на процесс существует очень сильная взаимосвязь. Стандарты на продукцию применимы к результату процесса разработки ПО, а стандарты на процесс в большинстве случаев подразумевают выполнение определенных действий, направленных на получение товара, соответствующего стандартам на продукцию.

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

1. Стандарты аккумулируют все лучшее из практической деятельности по созданию ПО. Как правило, практические знания приобретаются путем долгого поиска и ошибок. Привнесение этого опыта в определенный стандарт помогает избежать повторения прошлых ошибок. Стандарты в данном случае собирают знания и опыт, имеющие значение для организации-разработчика.

2. Стандарты предоставляют необходимую основу для реализации процесса обеспечения качества. Имея в наличии стандарты, обобщающие лучшие знания и опыт, для обеспечения качества достаточно контролировать, чтобы они выполнялись в процессе создания ПО.

3. Стандарты незаменимы, когда работа переходит от одного сотрудника к другому. В этом случае деятельность всех специалистов в организации подчиняется единому нормативу. Следовательно, требуется меньше затрат на изучение сотрудником новой работы.

Создание стандартов по разработке ПО – процесс долгий и утомительный. Такие национальные и международные организации, как Министерство обороны США, Американский национальный институт стандартизации (ANSI), Британский институт стандартов (BSI), НАТО, Институт инженеров по электротехнике и электронике (IEEE), специализируются на создании общих стандартов, которые могут применяться к широкому диапазону возможных программных проектов. Такие органы, как НАТО, или другие оборонные организации могут требовать соблюдения их собственных стандартов в контрактах на создание программного обеспечения.

Национальные (американские) и международные стандарты были разработаны для таких сфер программной деятельности, как терминология инженерии ПО, языки программирования типа Ada и C++, система обозначений, например для символов в схемах и чертежах, процедуры для разработки системных требований, деятельность по обеспечению качества, а также для аттестации ПО.

Примечание: в Советском Союзе процесс создания ПО регламентировался стандартами ГОСТ ЕСПД (Единая система программной документации - серия ГОСТ 19.ХХХ). В настоящее время в России принят ряд стандартов создания автоматизированных систем, в состав которых входит программные компоненты: ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания " и др. Однако эти стандарты имеют ряд недостатков, а некоторые их положения просто устарели. Поэтому отечественные разработчики ПО чаще используют современные международные стандарты. В Украине также принято несколько государственных стандартов на разработку ПО, в том числе ряд стандартов по обеспечению качества.

Группы обеспечения качества, которые занимаются составлением стандартов, обычно основывают нормативы организации на общих национальных и международных стандартах. Используя их в качестве отправного пункта, группа обеспечения качества разрабатывает свой "справочник" по стандартам. В нем содержатся стандарты, отражающие специфику деятельности данной организации. В табл. 24.2 приведены примеры стандартов, которые могут входить в состав такого справочника.

Таблица 25.2. Стандарты на продукцию и процесс разработки ПО

Стандарты на продукцию

Стандарты на процесс разработки ПО

Форма пересмотра архитектуры ПО

Руководство по проведению пересмотра архитектуры ПО

Структура документа, содержащего системные требования

Представление документации по нормативам ЕЭС

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

Процесс выпуска версии ПО

Стиль программирования языка Java

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

Формат плана реализации проекта

Процесс контроля изменений

Форма запроса на изменения

Процесс регистрации выполнения тестов

Иногда специалисты по разработке ПО относятся к стандартам как к бюрократическому наследию, неприменимому к разработке ПО. Особенно это проявляется при выполнении такой утомительной и скучной (однако необходимой для соблюдения стандартов) процедуры, как заполнение всевозможных форм и регистрация работ. Конечно, с общей идеей полезности стандартов все согласны, однако при этом разработчики находят любую удобную причину, по которой именно для их проекта эти стандарты не так уж необходимы.

Чтобы не возникало подобных проблем в работе, менеджеры по качеству, отвечающие за разработку стандартов, должны быть достаточно подготовленными и действовать следующим образом.

1. Вовлечь самих программистов в разработку стандартов. Они должны ясно понимать, с какой целью разрабатывается стандарт, и четко следовать установленным правилам и нормативам. Важно, чтобы документ с описанием стандарта включал не только изложение самого норматива качества, но и объяснение необходимости именно этого норматива.

2. Регулярно просматривать и обновлять стандарты, чтобы идти в ногу с быстро развивающимися технологиями. Как только стандарт разработан, его помещают в справочник организации по стандартам, где его холят и лелеют, меняя с большой неохотой. Справочник по стандартам – вещь для организации необходимая, однако он должен развиваться по мере развития новых технологий.

3. Подумать о том, чтобы обеспечить поддержку стандартов программными средствами везде, где только можно. Всяческие "канцелярские" стандарты вызывают огромное количество жалоб, связанных с нудной и утомительной работой по их выполнению. Если же имеются в наличии средства поддержки, выполнение стандартов не требует больших усилий.

Стандарты на процессы разработки ПО также могут вызвать ряд проблем, если ставят перед командой разработчиков практически неосуществимые задачи. Такие стандарты дают руководящие советы по выполнению работы, при этом менеджеры проектов могут интерпретировать их каждый по-своему. Нет смысла указывать определенное направление работы, если оно неприменимо к данному проекту или к самой команде разработчиков. Поэтому менеджер проекта должен иметь право изменять стандарты процесса создания ПО в соответствии со специфическими условиями именно данного проекта. Здесь следует оговориться, что это утверждение не относится к стандартам на качество готовой продукции и на процесс сопровождения программной системы, которые могут быть изменены только после глубокого изучения данного вопроса.

Менеджер проекта и менеджер по управлению качеством могут легко избежать подводных камней, связанных с "неподходящими" стандартами, путем тщательной разработки плана мероприятий по обеспечению качества. Именно они должны решить, какие стандарты из справочника можно использовать без изменений, какие из них подлежат изменению, а какие следует исключить. Иногда возникает необходимость в разработке нового стандарта, что может быть вызвано условиями выполнения определенного проекта. Например, требуется установить стандарт для формальной спецификации, если прежде в проектах он не использовался. Такие стандарты должны разрабатываться в процессе выполнения проекта.