Обеспечение качества ПО основная цель деятельности по стандартизации, метрологии и сертификации.

Введение.

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

Хрестоматийным стал случай, произошедший с ракетой-носителем ARIANE Европейского сообщества. Первый запуск закончился через 40 секунд взрывом. Непосредственно причиной взрыва явилась остановка процессора вследствие исключительной ситуации в работе программы, которую программисты не предусмотрели. Во время старта возникла ситуация, приведшая к тому, что один из параметров получил значение не уместившееся в предусмотренные переменной 16 битов.

Даже если и удается избежать чрезвычайных происшествий, использование некачественных программ наносит ущерб эффективности работы, что особенно негативно сказывается на коммерческих предприятиях, поскольку снижает их конкурентоспособность. Предприятия наиболее уязвимы в период внедрения на них новых информационных систем. Именно в это время ущерб от некачественного программного обеспечения наиболее вероятен. По данным Департамента по Торговле и Промышленности Великобритании (DTI) при внедрении проектов информационных технологий на предприятиях потери из-за низкого качества программного обеспечения составляют в среднем около 20% от общего объема потерь. По разным оценкам аналогичный показатель для России достигает величины от 30 до 50%.

Для решения проблем, связанных с ошибками в ПО, прилагаются значительные усилия. По данным зарубежных компаний стоимость тестирования составляет до 50% всей цены начальной разработки и до 70 % всех расходов по поддержке программ. Многие крупные компании на одного программиста-разработчика имеют одного и более специалиста-тестировщика (Microsoft).

При разработке программного обеспечения заказчик, как правило, требует соответствия следующим условиям:

• технические требования (функциональность, надежность и т.д.),

• стоимость,

• сроки.

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

Фирма IBM провела исследования состояния дел в 24 ведущих компаниях США, разрабатывающих крупные программные системы (ПС). В ее отчете указывалось, что:

• в 55% проектов превышена изначально запланированная стоимость разработки;

• в 68% проектов нарушены договорные сроки разработки;

• 88% проектов пришлось существенно переделывать.

Аналогичные исследования, проведенные Standash Group по 8380 программным проектам, разрабатываемым в государственном и частном секторах США, показали, что:

• 31% всех программных проектов закрываются до их полного завершения;

• 53% успешно завершенных проектов в среднем на 18% превышают начальную стоимость;

• из этих 53% проектов только 42% обеспечивают в программных продуктах все изначально требуемые свойства и функции;

• только 9% проектов завершаются в срок и укладываются в предусмотренные для проекта денежные средства.

Важные проблемы, с которыми приходится сталкиваться порождены интеллектуальной природой процесса создания ПО. Несмотря на то, что программирование более или менее формализуется применением стандартных языков программирования и структурированием данных, сам процесс до сих пор является более искусством, чем ремеслом [McConnell, 2001]. Одну и ту же программу разные разработчики напишут по-разному, но очень немногие из полученных вариантов будут совершенными. Недаром капитальный труд в этой области назван "Искусство программирования" [Knuth, 1998]. Компьютерная программа является материальным объектом, но она строится на абстрактных идеях и состоит из сложнейших виртуальных конструкций. Это в корне отличает ее от физических объектов, с которыми имеет дело обычное производство, и поэтому невозможно создать качественное ПО, не решив ряд типичных проблем:

• команда разработчиков, как правило, состоит из творческих личностей и часто бывает очень трудно привести их к "общему знаменателю";

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

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

• по сходной причине трудно поставить производство сложного и уникального ПО на поток, так как часто для его разработки требуется создание сопутствующего специфического программного "инструментария" [Оносовский, Терехов, 2000];

• одна из специфических проблем программирования состоит в том, что его продуктивность растет очень медленно, если растет вообще - по некоторым оценкам средний программист способен создать 10-50 строк операторов в день. Кроме того, эти оценки должны быть уменьшены для больших систем, так как увеличенная нагрузка требует увеличения затрат (в относительных единицах) [Jones, 1986]. Это обстоятельство резко отделяет программирование от другого вида деятельности, где поточное производство радикально уменьшает цену единицы продукта. По существу, вся экономика строится на этом далеко не новом принципе - но только не производство программного обеспечения!

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

Следующую проблему можно рассмотреть на неком примере:

• Программисты и коммерсанты говорят и мыслят разными категориями, поэтому им трудно найти общий язык.

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

• Заказы принимались "на слух", многие из них так никогда и не были записаны.

• Техническое задание не было подготовлено в полном объеме.

• "Вечные" проблемы с внедрением (даже не будем цитировать, так это все банально - ошибки, разногласия по поводу ТЗ, нежелание операторов учиться…).

• Как результат: "снижение доверия к разработчику, которое усугубилось неприятным фактом, когда вместо того, чтобы изменить настройки принтера, разработчик выставил счет за ремонт материнской платы принтера на 250 фунтов стерлингов".

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

В решении этой проблемы заинтересованы все стороны и руководители организаций разработчиков ПС, и менеджеры проектов, и заказчики и потребители. Что же мешает? Нет эффективной системы управления разработкой ПС. Т.е необходима эффективная инфраструктура для поддержки процесса разработки ПО и его оценки.

Раздел 1. Качество программного обеспечения.

1.1 Основные понятия

Качество программ - понятие, аккумулирующее противоречивые природы самих программ и противоречия, возникающие при их создании.

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

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

Иногда определяют понятие качества ПО через фиксированный набор свойств программ: качество ПО представляет собой степень соответствия ПО установленным критериям качества. Критерии качества включают следующие характеристики:

1. экономичность; 2) документированность; 3) гибкость; 4) модульность; 5) надежность; 6) обоснованность; 7) тестируемость; 8) упругость; 9) ясность; 10) портативность; 11) полноту; 12) понятность; 13) способность к взаимодействию; 14) точность; 15) модифицируемость; 16) общность; 17) легкость применения; 18) легкость сопровождения; 19) эффективность.

Приведенный набор характеристик не является исчерпывающим и может быть расширен.

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

Исходя из изложенного, дадим определение качеству ПО.

Качество ПО- это совокупность свойств, определяющих полезность изделия(программы) для пользователей в соответствии с функциональным назначением и предъявленными требованиями.

При изучении проблем качества ПО, можно выделить два взаимосвязанных направления исследований:

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

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

Оценка качества ПО включает два основных этапа:

1) получение информации о фактическом состоянии контролируемого объекта;

2) сопоставление этой информации с предъявленными требованиями , т.е. установление факта соответствия реальных свойств требуемым.

Следовательно, необходимо располагать некоторой системой измеряемых показателей качества, которая позволила бы как сформировать требования, так и контролировать их выполнение в ходе разработки ПО. Как правило, для построения такой системы применяются иерархические многоуровневые модели. Использование принципа иерархии объясняется двояким назначением системы оценки качества программы. С одной стороны, система должна предоставлять максимум информации непосредственным исполнителям, чтобы дать последним возможность выявлять причины ухудшения той или иной характеристики качества программы. Это обуславливает высокую размерность системы оценок и большую степень их детализации. С другой стороны, система оценки качества программы должна быть пригодна для определения требований к ПО на самых ранних этапах разработки, для чего необходимы обобщенные оценки. Немаловажную роль при этом играют простота формулировки и понятность требований, а это достигается путем снижения размерности задачи и использования легко воспринимаемых оценок качества.

С иерархическими многоуровневыми моделями связано несколько основных терминов.

Свойства программы – это объективные особенности программы, проявляющиеся при ее разработке, эксплуатации или сопровождении.

Показатель качества программы – понятие, отражающее определенную часть свойств программы и поддающееся интуитивной оценке. Характеризует одно или несколько свойств программы.

Характеристика качества программы – понятие, отражающее отдельные факторы, влияющие на качество программы и поддающиеся изменению.

Критерий качества – численный показатель, характеризующий степень, в которой программе присуще оцениваемое свойство.

Основные требования к критериям качества программ:

А) критерий должен численно характеризовать основную целевую функцию программы;

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

В) критерий должен быть по возможности простым, хорошо измеримым и иметь малую дисперсию.

Для измерения характеристик и критериев качества необходим соответствующий математический аппарат. В качестве такого аппарата используются метрики.

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

Введение метрики весьма важно, поскольку позволяет говорить о формализации оценки разработки ПО.

В исследовании метрики ПО различают два основных направления:

1. Поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;

2. Использование метрик для оценки технических характеристик и факторов разработки программ, т.е. метрик оценки условий разработки программ.

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

1. Метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов;

2. Метрики, позволяющие прогнозировать качество разрабатываемого ПО;

3. Метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям.

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

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы. Существует три вида шкал: номинальная, порядковая и интервальная.

Номинальной шкале – соответствуют метрики, классифицирующие программы на типы по принципу наличия или отсутствия некоторой характеристики без учета градаций. Например, программы можно группировать как “нетрудные для понимания”, “умеренно трудные для понимания”, “трудные для понимания”, “очень трудные для понимания”.

Второму виду шкалы – порядковой шкале соответствуют метрики, позволяющие ранжировать некоторые характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ. Например, мы могли бы не только сказать, что некоторые программы A, B и С относятся к разряду “умеренно трудных для понимания”, но и то, что программа В труднее программы А, а программа А труднее программы С.

Метрики интервальной шкалы показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга. Например, мы могли бы сказать, что программа В труднее программы А на 10 единиц.

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

Вариант взаимосвязи показателей и критериев качества программы можно описать с помощью двухуровневой модели:

Корректность
				
Прослеживаемость		Согласованность		Полнота

Надежность
						
Устойчивость к ошибкам		Согласованность		Точность		Простота

Эффективность
		
Эффективность по времени		Эффективность по памяти

Целостность
		
Контроль доступа		Регистрация доступа

Применимость
								
Управляемость		Объем ввода-вывода		Изучаемость		Интенсивность ввода-вывода		Коммертативность

Удобство сопровождения
								
Согласованность		Простота		Компактность		Способность к самоописанию		Модульность

Гибкость
						
Модульность		Общность		Расширяемость		Способность к самоописанию

Тестируемость
						
Простота		Модульность		Оснащенность средствами		Способность к самоописанию

Мобильность
						
Модульность		Машинонезависимость		Независимость от системного ПО		Способность к самоописанию

Адаптируемость
						
Общность		Модульность		Машинонезависимость		Независимость от системного ПО

Совместимость
				
Модульность		Обобщенность средств коммуникации		Обобщенность представления данных

Рис. 1.1 Модель связи критериев и показателей качества ПО.

(Показатели качества обведены рамками)

Критерий выступает как независимый атрибут ПО или процесса его создания. С помощью такого критерия можно определить и измерить характеристику качества ПО. Структура показателей и критериев ориентирована на использование модели в процессе управления разработкой ПО, что требует количественного измерения характеристик, которое обеспечивается метриками. Роль показателя – чисто информационная, а качество программ оценивается с помощью пары “критерий-метрика”.

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

Развитием иерархического подхода можно также считать модель классификации критериев качества:

Критерии качества программ
Функциональные критерии качества программ			Конструктивные критерии качества программ			Факторы и параметры, влияющие на основные критерии качества программ
Критерии этапа проектирования программ			Критерии этапа эксплуатации программ			Критерии этапа сопровождения программ

Рис.1.2 Модель классификации критериев качества

При сохранении общего принципа иерархичности критерии классифицированы на несколько групп по характеру оценок и признаку связи с конкретным этапом разработки программного комплекса. Наиболее интересным в этой модели представляется введение двух основных групп критериев: функциональных и конструктивных.

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

Конструктивные критерии белее универсальны и предназначены для оценки системы аспектов разработки программ, не зависящих от целевого назначения.

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