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

Основным стандартом качества в области инженерии программного обеспечения в настоящее время является является стандарт ISO/IEC 9126. Он определяет номенклатуру, атрибуты и метрики требований качества программного обеспечения. Относительно недавно этот стандарт стал одним из определяющих факторов при моделировании качества программного обеспечения и остаётся им до сих пор.

В дополнение к нему выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).

Общий подход к моделированию качества программного обеспечения заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении "сверху вниз" разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEC 9126 является типичным примером такого подхода.

В рамках модели SQuaRE выделяются следующие шесть основных характеристик качества.

1. Функциональность (точность, согласованность, интероперабельность, безопасность, пригодность). Функциональные требования традиционно составляют основной предмет спецификации, моделирования, реализации и аттестации программного обеспечения. Они формулируются в виде утверждений в императивной модальности, описывающих поведение системы. Ипользование формальных методов позволяет довести уровень отклонения фактического поведения системы от требуемого практически до нуля. Это достигается путем выражения функциональных требований в виде предложений подходящих формальных исчислений, так что верификация сводится к строгому доказательству.

2. Надежность (устойчивость, завершенность, восстанавливаемость). Показатели надежности характеризуют поведение системы при выходе за пределы штатных значений параметров функционирования по причине сбоя в окружении либо в самой системе. При оценке атрибутов надежности применяются методы теории вероятностей и математической статистики. Требования к надежности особенно важны при разработке критических систем обеспечения безопасности жизнедеятельности (dependable systems). Хотя использование формальных методов способствует снижению количества внутренних ошибок (т.е. росту завершенности системы), обеспечение надежности в целом требует специальных подходов, учитывающих специфику различных типов систем.
3. Удобство (эффективность освоения, эргономичность, понимаемость). Соответствие системы требованиям к удобству чрезвычайно трудно поддается оценке. Предлагаемые подходы включают замеры расхода нормативных единиц труда (нормо-часов), затрачиваемого пользователями на овладение системой, а также проведение и анализ экспертных оценок, в том числе с применением методов нечеткой логики (fuzzy logic). В контексте использования формальных методов наилучшим решением представляется изначальная ориентация на формализмы, способные максимально точно отразить структуру исходной предметной области. Например, при создании вычислительных систем критерием адекватности формализма с точки зрения будущего пользователя является поддержка абстрактного математического языка, не зависящего от концептуальных ограничений, накладываемых компьютерными технологиями.

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

5. Сопровождаемость (простота анализа, изменяемость, стабильность, проверяемость). Требования к сопровождаемости направлены в первую очередь на минимизацию усилий по сопровождению и модернизации системы, затрачиваемых эксплуатационным персоналом. Для их оценки используются различные методики прогнозирования затрат на выполнение типовых процедур сопровождения. Интегральная стоимость сопровождения долгоживущих систем может существенно превышать стоимость их разработки. Сопровождение существенно упрощаются в случае, когда разработка велась с использованием формальных методов, поскольку имеется в определенном смысле исчерпывающий комплект технологической документации и проверочных тестов.

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

Модель качества, создаваемая в рамках данного стандарта, определяется общими характеристиками продукта. Характеристики же в свою очередь могут быть уточнены, другими словами, иерархично разбиты на подхарактеристики качества. Так, например, характеристика сопровождаемости может быть представлена такими подхарактеристиками как простота анализа, изменяемость, стабильность, проверяемость.

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