Стандарт ISO 9000-2000
По ISO качество – это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям [1]. Современные способы обеспечения качества базируются на подходах TQM (Total Quality Management). Это управление ресурсами и применение количественных методов анализа для улучшения: материалов и услуг, поставляемых в организацию; всех процессов внутри организации; степени удовлетворенности настоящих и будущих потребностей клиентов.
Инициативы внедрения систем качества в широких масштабах в Японии в начале 50-х годов, поддержанные правительственными программами, обеспечили быстрый рост конкурентоспособности, и выход страны на лидирующие позиции в мире в ряде областей промышленности. Активное внедрение подходов качества в США и Европе началось в начале 60-х годов. Если говорить о программировании, то идеи качества разработки программного обеспечения пришли в эту область из промышленности в ответ на программный кризис конца 60 –х годов[2].
В основу построения организационной системы по ISO 9000-2000 закладываются следующие принципы:
Концентрация на потребностях заказчика;
Активная лидирующая роль руководства;
Вовлечение исполнителей в процессы совершенствования;
Реализация процессного подхода;
Системный подход к управлению;
Обеспечение непрерывных улучшений;
Принятие решений на основе фактов;
Взаимовыгодные отношения с поставщиками.
При этом методически в полном соответствии с дисциплиной построения сложных систем в стандарте ISO 9000-2000 предусматривается с одной стороны построение организационной системы «сверху - вниз»: от целей предприятия и его политики - к организационной структуре и формированию бизнес процессов, и с другой – итеративное развитие организационной системы через механизмы измерения и улучшения.
Цена качества
В разработке программного обеспечения в цене качества выделяют согласованную (conformance) и несогласованную (non-conformance) цену. Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий, несогласованная цена – это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т.д.
Статистические исследования на реальных проектах показывают, что несогласованная цена качества уменьшается существенно более быстрыми темпами, чем увеличиваются согласованная цена[2]. Фактически это означает, что затраты на качество, безусловно, выгодны и должны окупаться не только в перспективе через расширение рынка, но и непосредственно в каждом текущем проекте.
Трудность состоит в том, чтобы спланировать и отслеживать затраты на качество в прямой зависимости от получаемых результатов. То есть речь идет об управлении качеством. Одной из основополагающих идей TQM, которая в явном, можно сказать - подчеркнутом, виде вошла в ISO 9000-2000 состоит в том, что мы можем управлять качеством разработки программного обеспечения в основном через процесс его изготовления.
Качество продукта возрастает на каждой стадии процесса, во-первых, как прямое следствие зрелости и технологичности самого процесса, во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей стадии, более высокого качества. То есть, качество накапливается в продукте при сложном производстве кумулятивным образом, причем, вклад в качество, осуществленный на ранних стадиях, имеет более сильное влияние на конечный продукт, чем на заключительных этапах [4].Если говорить о цифрах, то прибыль от затрат на качество в бюджетах проектов может составлять от 50% до 200%, при условии их адресности и своевременности [5].
Что касается более долгосрочных инвестиций, например, в индустриальную систему качества, соответствующую стандарту качества CMM (capability maturity model), то по данным Software Engineering Institute уровень возврата инвестиций при внедрении систем качества в среднем достигает значения 5 [6].
Формирование процесса разработки программного обеспечения
Процесс разработки программного обеспечения должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования наиболее часто в качестве метрики качества продукта используется остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP). Однако, если мы говорим о качестве в более точном понимании этого слова, то есть о степени удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки программного обеспечения, в котором на основе требований к продукту предусматривается создание плана тестирования, цель которого состоит в обеспечении полноты тестирования всех утвержденных требований. Далее на основе плана тестирования должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование программного обеспечения всех требований и возможность измерения степени выполнения требований в готовящейся версии программы. Возможная «утечка» качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.
В полной мере управлять качеством можно, если качество измеряется на всех этапах жизненного цикла. Качество к промежуточному продукту может быть установлено на основе отраслевых стандартов, в данном случае стандартов программирования, в качестве которых могут быть использованы соответствующие нормативные документы ISO или IEEE. В частности, качество требований к продукту определяется такими их свойствами как идентифицируемость, однозначность, непротиворечивость, полнота, тестируемость, стабильность и пр.
Вероятно одна из самых больших сложностей, связанных с формированием процессов разработки программного обеспечения является обеспечение целостности и согласованности всех действий и требуемых результатов. В особенности это важно для проектов, которые выполняются многочисленной командой разработчиков. Например, обычной ситуацией является изменение требований или проектных решений в процессе разработки программного обеспечения; в этом случае должны быть каскадно изменены и приведены в соответствие все связанные, разработанные к этому времени промежуточные продукты и документы проекта. Сложность в том, что это требует высоких трудозатрат, нередко выполняется не полностью и приводит к потере качества продукта. Поэтому важно, чтобы процесс в целом был высоко автоматизирован и поддерживался инструментальными средствам не только в части основных программных процессов, но и в отношении вспомогательных процессов, таких как конфигурационное управление, документирование и т.п. При этом важно использовать интегрируемые между собой инструментальные средства для обеспечения автоматической прослеживаемости связанных промежуточных результатов проекта. В качестве примера таких инструментальных средств можно назвать семейство продуктов Rational Software.
Сертификация системы менеджмента качества
В ISO 9000 – 2000 заложена идея разделения контроля по уровням управления. Мониторинг, внутренние аудиты, должны проводиться соответственно в рамках проектов и на уровне руководства фирмы. По сути существует еще один контур управления – управление со стороны клиентов. Если говорить о профессиональном контроле систем менеджмента качества, то его выполняют внешние аудиторы, которые таким образом могут рассматриваться как представители клиентов и партнеров компании. Таким образом, без внешнего сертификационного аудита внедрение систем качества на предприятиях не может быть полным.
Для фирмы Аплана в качестве сертифицирующего органа были выбраны организация TUV-Cert (Германия) и ее российский партнер – компания Интерсертифика. Обучение менеджеров, организация промежуточных аудитов, позволили уверенно реализовать плановые сроки внедрения системы качества и избежать риски, связанные с корректировками в системе управления.
За пределами 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 Southeast 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 (COMPSAC’01)
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.