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

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

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

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

• удаление дефектов;

• указание общих показателей качества.

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

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

• цели, связанные качеством программирования (удобная для чтения структура, комментарии и их полнота, соответствие спецификаци­ям, переиспользуемость и эффективность кода);

• использование инструментов (какие, для чего, как влияют на каче­ство);

• модель исправления дефектов (организационная процедура поиска дефектов и их устранения);

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

• соглашение об описании процессов в виде, удобном для измене­ния и исправления программ;

• представление порядка отслеживания качества;

• специфичные для проекта соглашения.

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

При составлении плана управления качеством нельзя не учитывать тесную связь этого плана с общим планом проекта. Так, некоторые про­ектные решения могут влиять на критерии качества, и наоборот, то, что для данного проекта выдвинуты априорные критерии качества, влияет на предпочтение одних решений другим и даже на выбор стратегии реализа­ции программного продукта. И хотя конкретизация этого положения не­возможна без рассмотрения особенностей конкретного проекта, стоит обратить внимание на ключевые общие моменты, которых следует избе­гать в связи с заботой о качестве программного продукта. В приведенном ниже перечне указаны некоторые довольно типичные ошибки проекти­рования, относящиеся к качеству:

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

Чтобы избежать этой ошибки, необходимо предусмотреть время на исследование автоматизируемой деятельности, возможно, ее ре­конструкцию (когда автоматизируется новая, еще не существую­щая деятельность) с целью определения типовых пользовательских шагов и их последовательности. Это аспект общего плана проекта. В плане управления качеством следует предусмотреть мероприятия по проверке результативности проведенного исследования, с од­ной стороны, а с другой — контроль соответствия между фиксиро­ванными типовыми ситуациями и реализуемыми возможностями пользователя действовать в этих ситуациях.

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

• Пользовательский интерфейс, не соответствующий автоматизируемой деятельности; непривычный, эргономически неточный и т.д. При­ чина этого недостатка все та же: просчеты с исследованием автома­тизируемой деятельности. Но кроме того — игнорирование в об­щем плане проекта задачи специальной настройки интерфейса. Этот недостаток с трудом поддается измерению. Тем не менее для его преодоления в плане управления качеством полезно предусма­тривать процедуру сравнения вариантов интерфейсных решений;

• Неадекватная реакция системы на ошибки пользователя. Правильная точка зрения на пользовательские ошибки — считать их не исклю­чениями, а обычными явлениями, возникающими при работе про­ граммы. В этом случае можно добиться в диагностике ответа на три вопроса, возникающие у пользователя, когда система фиксирует ошибку:

• Что случилось? В диагностическом сообщении причина ошибки и ее последствия должны разъясняться в пользовательских тер­ минах.

• Что можно сделать? Пользователю должна быть предоставлена возможность получить информацию о возможных действиях, на корректное выполнение которых он может рассчитывать.

• Как исправить положение? Следует дать пользователю возмож­ность получить сведения о пути исправления ошибки с уточне­нием, какие потери его ожидают.

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

Подобный критерий можно определить для предупреждающих со­общений.

• Неадекватная реакция на системные ошибки (ошибки разработчиков).

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