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

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

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

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

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

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

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

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

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

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

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

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

  Подобный критерий можно определить для предупреждающих сообщений.
• Неадекватная реакция на системные ошибки (ошибки разработчиков).

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