Управление качеством – что я для себя вынес

Раньше, когда доходило дело до разговора об управлении качеством, я всегда терялся. Для меня качество системы и количество найденных баг (или баг, дошедших до прода) были абсолютными синонимами. Но теперь, когда с управлением качеством я столкнулся самым непосредственным образом и при этом вспомнил, что качество системы определяется не только качеством кода, а еще и полнотой ее обеспеченности и качеством видов обеспечения, у меня получилась некоторая модель того, как в треугольнике цена – сроки – качество управлять ценой и сроками путем манипуляций с качеством системы.

Последовательность действий управления качеством системы (в общем случае) получается следующая:

1. Определить контекст системы – автоматизируемая деятельность, смежные системы, общие принципы интеграции со смежными системами, основные пользователи (группы пользователей) и их общая идея их взаимодействия с системой, среда эксплуатации (доступные платформы, уровень квалификации сисадминов и т.п.), необходимость в разработке или изменении нормативной базы Заказчика.
2. Определить виды обеспечения, обязательные для проектируемой системы (т.е. те, без которых система не сможет работать и при этом Заказчик будет готов за них заплатить).
3. Определить необходимые элементы видов обеспечения. Например:
   • для нормативного обеспечения – это должностные инструкции, стандарты предприятия и т.п.;
   • для документационного обеспечения – это виды документов, которые должны быть разработаны, и их содержание;
   • для программного обеспечения – это сценарии использования (почти читай – функциональность) и архитектура системы;
   • и т.д.
4. Для каждого вида обеспечения определить, по каким элементам Разработчик должен гарантировать качество результата. Например:
   • для нормативного и документационного обеспечения – какие документы / инструкции должны согласовываться и утверждаться Заказчиком (а значит – соответсвующим образом дорабатываться), а какие достаточно предоставить в черновом варианте;
   • для программного обеспечения – какие компоненты приложения / сценарии должны тестироваться (и как тщательно), а какие нет. Например:
     • Сценарии, лежащие на критическом пути использования приложения, должны гарантированно работать. Иначе система попросту будет не пригодна для эксплуатации. По остальному функционалу уже можно смотреть. Скажем, справочники, которые регулярно правятся пользователями, нужно тестировать в полном объеме. Остальные можно на уровне смок-теста. Редко используемые можно вообще не тестировать (если любой админ сможет залезть и ручками чего-то в нем подправить).

Таким образом получается, что эти 4 пункта позволяют задать на ранних  этапах создания системы такой уровень ее качества, который позволит с одной стороны эксплуатировать систему (и Заказчик будет понимать, почему она такая вышла), а с другой – уложиться в приемлемые для Заказчика сроки и бюджет.

Возможно, что это уже очевидные вещи, но ведь я и не претендую на что-то, просто делюсь мыслью :) Поэтому буду рад любым откликам на эту тему.