Управление качеством в процессах разработки программного обеспечения
 
21.02.2003
Компьютерра
Михаил Македонский Александр Попов

 Стандарт ISO 9000-2000
По ISO, качество — это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям [1]. Современные способы обеспечения качества базируются на подходах TQM (Total Quality Management). Это управление ресурсами и применение количественных методов анализа для улучшения материалов и услуг, поставляемых в организацию, всех процессов внутри организации, а также степени удовлетворенности настоящих и будущих потребностей клиентов.1
Активное внедрение подходов качества в США и Европе началось в начале 1960-х годов. Если говорить о программировании, то идеи качества пришли сюда из промышленности в ответ на кризис конца 1960-х годов [2].
В основу построения организационной системы по ISO 9000-2000 закладываются следующие принципы:
1.  Концентрация на потребностях заказчика.
2. Активная лидирующая роль руководства.
3.  Вовлечение исполнителей в процессы совершенствования.
4.  Реализация процессного подхода.
5.  Системный подход к управлению.
6.  Обеспечение непрерывных улучшений.
7.  Принятие решений на основе фактов.
8.  Взаимовыгодные отношения с поставщиками.
При этом методически, в полном соответствии с дисциплиной построения сложных систем, стандарт ISO 9000-2000 предусматривает, с одной стороны, построение организационной системы «сверху вниз»: от целей предприятия и его политики — к организационной структуре и формированию бизнес процессов, и с другой — итеративное развитие организационной системы через механизмы измерения и улучшения.

Цена качества
В программировании в цене качества выделяют согласованную (conformance) и несогласованную (non-conformance) цену. Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий. Несогласованная цена — это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т. д.
Статистические исследования на реальных проектах показывают, что несогласованная цена качества уменьшается существенно быстрее, чем увеличивается согласованная цена [2]. Фактически это означает, что затраты на качество, безусловно, выгодны и должны окупаться не только в перспективе через расширение рынка, но и непосредственно в каждом текущем проекте.
Трудность в том, чтобы спланировать и отслеживать затраты на качество в прямой зависимости от получаемых результатов. То есть речь идет об управлении качеством. Одна из основополагающих идей TQM состоит в том, что мы можем управлять качеством разрабатываемого продукта в основном через процесс его изготовления.
Качество продукта возрастает на каждой стадии процесса: во-первых, как прямое следствие зрелости и технологичности самого процесса, и во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей стадии, более высокого качества. То есть при сложном производстве качество накапливается в продукте кумулятивным образом, причем вклад в качество, сделанный на ранних стадиях, больше влияет на конечный продукт, чем вклад, сделанный на заключительных этапах [4]. Если говорить о цифрах, то прибыль от затрат на качество в бюджетах проектов может составлять от 50 до 200%, при условии их адресности и своевременности [5].
Что касается более долгосрочных инвестиций, например, в индустриальную систему качества, соответствующую стандарту качества CMM (capability maturity model), то, по данным Software Engineering Institute, уровень возврата инвестиций при внедрении систем качества в среднем достигает значения 5 [6].

Формирование процесса разработки программного обеспечения
Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP). Однако если под качеством понимать степень удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование всех требований и возможность измерения степени выполнения требований в готовящейся версии программы. Возможная «утечка» качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.
В полной мере управлять качеством можно, если оно измеряется на всех этапах жизненного цикла. Качество к промежуточному продукту может быть установлено на основе отраслевых стандартов, в данном случае стандартов программирования (например, ISO или IEEE).
Вероятно, одной из самых больших трудностей, связанных с формированием процессов разработки ПО, является обеспечение целостности и согласованности всех действий и требуемых результатов. Особенно это важно для проектов, которые выполняются многочисленной командой разработчиков. Например, обычной ситуацией является изменение требований или проектных решений в процессе разработки; в этом случае должны быть каскадно изменены и приведены в соответствие все связанные, разработанные к этому времени промежуточные продукты и документы. Беда в том, что это требует высоких трудозатрат, нередко выполняется не полностью и приводит к потере качества продукта. Поэтому важно, чтобы процесс был высоко автоматизирован и поддерживался инструментальными средствам не только в части основных программных процессов, но и в отношении вспомогательных процессов, таких как конфигурационное управление, документирование и т. п. При этом важно использовать интегрируемые между собой инструментальные средства для обеспечения автоматической прослеживаемости связанных промежуточных результатов проекта. В качестве примера таких инструментальных средств можно назвать семейство продуктов Rational Software.

Сертификация системы менеджмента качества
В ISO 9000-2000 заложена идея разделения контроля по уровням управления. Мониторинг, внутренние аудиты должны проводиться в рамках проектов и на уровне руководства фирмы. По сути, существует еще и управление со стороны клиентов. Если говорить о профессиональном контроле систем менеджмента качества, то его выполняют внешние аудиторы, которые могут рассматриваться как представители клиентов и партнеров компании. Таким образом, без внешнего сертификационного аудита внедрение систем качества на предприятиях не может быть полным.

За пределами ISO 9000-2000
На вопрос, гарантирует ли внедрение системы качества и успешная сертификация выпуск качественного продукта, следует ответить обескураживающее «нет». Подчеркивая, что ISO 9000 — «превосходная идея», Gartner Group рекомендует рассматривать сертификацию на ISO 9000-2000 только как исходную точку на пути к качеству [7]. Стандарт ISO 9000 является достаточно простым и общим. Постоянное наполнение системы качества профессиональным содержанием на основе уже специальных, отраслевых стандартов и методологий может обеспечить уровень качества, соответствующий растущим требованиям рынка. Поэтому главное, что должна выполнять компания в области качества, — это не останавливаться на достигнутом.


Литература
[1] ISO 8402:1994. Quality Management and Quality Assurance — Vocabulary.
[2] Wheeler Sh., Duggins Sh., Improving Software Quality. — ACM Proceedings of the 36th Annual Conference on South-East Regional Conference, April 1998.
[3] Sedigh-Ali S., Ghafoor A., Paul R. A. Metrics-Guided Quality Management for Component-Based Software Systems. — Proceedings of the 25th Annual International Computer Software and Applications Conference.
[4] Harter D. E., Slaughter S. A. Process Maturity and Software Quality: A Field Study. — Proceedings of the Twenty First International Conference on Information Systems, December 2000.
[5] Slaughter S. A., Harter D. E., Krishnan M. S. Evaluating the Cost of Software Quality. — Communications of the ACM, August 1998/Vol. 41, No. 8.
[6] Herbsleb J., Carleton A., Rozum J., Siegel J., Zubrow D. Benefits of CMM-Based Software Process Improvement: Initial Results. — Technical Report CMU/SEI-94-TR-013.
[7] Furlonger J. ISO 9000 Is No Guarantee of Quality: Research Note Tactical Guidelines. — Gartner Group, August 2000.



 Все работы хороши? [ "13-я КОМНАТА" ]
 Новости [ "НОВОСТИ" ]
 Дорога домой [ "НОВОСТИ" ]
 Микрофишки [ "НОВОСТИ" ]
 Слесаря вызывали? [ "НОВОСТИ" ]
 Умная пыль на сапогах [ "НОВОСТИ" ]
 Лишь бы работало [ "НОВОСТИ" ]
 Производство варева [ "ТЕМА НОМЕРА" ]
 «ERP»для программистских проектов [ "ТЕМА НОМЕРА" ]
 Управление качеством в процессах разработки программного обеспечения [ "ТЕМА НОМЕРА" ]
 От хвоста до головы Практика разработки средних и крупных программных проектов [ "ТЕМА НОМЕРА" ]
 Символическая новизна [ "SOFTТЕРРА LITE" ]
 Зимний прорыв [ "SOFTТЕРРА LITE" ]
 События [ "SOFTТЕРРА LITE" ]
 Синергия [ "КОМПЬЮFЕРРА LITE" ]
 Перст указующий [ "КОМПЬЮFЕРРА LITE" ]
 Дважды два [ "КОМПЬЮFЕРРА LITE" ]
 Баскетбол для зомби [ "ОПЫТЫ" ]
 Размер имеет значение [ "АНАЛИЗЫ" ]
 Миф в окошке [ "АНАЛИЗЫ" ]
 Где прячется квантовое сознание? [ "КАФЕДРА ВАННАХА" ]
 Масяня и Директора [ "КАРАУЛ" ]
 Что путного сможет сделать тысяча собранных под одной крышей программистов? [ "ВОПРОС НЕДЕЛИ" ]
 Женщины тоже способны мыслить [ "ПИСЬМОНОСЕЦ" ]


Все материалы номера