среда, 21 марта 2012 г.

О качестве


Точнее об управлении качеством в IT проектах

Наивное представление о качестве

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

Чуть более продвинутое представление о качестве

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

Качество программной системы.  Две группы качеств.

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

  • Качества, важные пользователям системы (функциональность, удобство, скрорость и надежность работы и т п) 
  • Качества, важные для дальнейшего развития системы (понятность, простота, ремонтопригодность, расширяемость)

Здесь часто смешивают эти два набора качеств и делают обобщенный ошибочный вывод. Вот такой

Если для достижения целей проекта достаточно иметь качество, скажем 80% то именно такое качество и надо обеспечивать с самого начала.

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

Жизненный цикл программной системы

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

При этом, очевидно , не происходит аналогичного роста умственных способностей ее создателей.

А значит маленькая и огромная программы с одинаковым уровнем качества (здесь говорим о группе показателей качества, важных для развития системы) 80% - абсолютно не одинаковы с точки зрения стоимости их развития. В первой будет скажем 50 недочетов, а во второй, если она в 100 раз больше их будет уже 5000. Все недочеты влияют друг на друга, создавая множество "степеней свободы". Поэтому, считая сложность системы, нужно не складывать недочеты, а перемножать - рост функции "сложность(количество недочетов)" - экспоненциален. А чем выше сложность - тем больше будет новых недочетов.

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

Можно сказать и проще - программист Вася Пупкин может осмыслить систему если в ней есть не более 50 недочетов. В системе из 100 строк кода 50 недочетов будет соответсовать 50% му качеству. В системе из миилиона строк - 99.995%

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

Но это еще не все. Есть еще

Закон стоимости повышения качества

Который, звучит так "повышать качество намного дороже, чем его поддерживать"

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

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

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

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

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

Ступенчатое повышение качества

Обычно мы поступаем так:

Имеем систему из 10000 строк кода. В ней 100 недочетов. Вася Пупкин перестает осознавать эту систему целиком из-за возросшей сложности. Требуется понизить сложность до приемлемого уровня. Вопрос - как это сделать?

Плохой ответ - исправить 50 недочетов.

Хороший ответ - разделить систему на две слабосвязанные подсистемы.
Тогда в каждой будет 50 недочетов и условный Вася Пупкин справится со сложностью в обоих случаях.

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

Планируя качество надо представлять
  • Срок жизни системы
  • Ее предполагаемый объем
  • Целевую функцию затрат на ее создание (какие затраты мы хотим минимизировать)
Исходя из этого можно планировать
  • Несколько этапов развития системы
  • Рефакторинг - пересмотр архитектуры системы с дроблением ее на модули в конце каждого этапа
  • Планку качества, оптимальную для каждого этапа и для каждого модуля
Зачем нужен план

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

Другими словами пойти на снижение планки качества (ради скорости или снижения стоимости) можно только если возникающие затраты будут покрыты полученной от этого выгодой.


P.S. Очевидно, если вы пишете систему управления для атомной станции, реактивного истребителя или чего-то в том же духе, рассуждения будут "несколько" другими :-)

Комментариев нет: