Котов С.Л., Палюх Б.В. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем

Подождите немного. Документ загружается.

Статья 22. Знаки соответствия

Маркировка осуществляется знаком соответствия системы

добровольной сертификации в соответствии с порядком применения знака,

установленным правилами системы добровольной сертификации.

Статья 23. Обязательное подтверждение соответствия

Оно проводится только в случаях, установленных соответствующим

ТРегл, и исключительно на соответствие требованиям регламента.

Объектом обязательного подтверждения соответствия может быть только

продукция, выпускаемая

на территории РФ.

Декларация о соответствии и сертификат соответствия имеют

равную юридическую силу.

Статья 24. Декларирование соответствия

Оно осуществляется по одной из схем:

а) принятие декларации на основе собственных доказательств;

б) принятие декларации на основе доказательств, полученных с

участием органов по сертификации и (или) аккредитованной

испытательной лаборатории (центра).

первом случае заявитель самостоятельно формирует

доказательные материалы, а во втором – заявитель включает протоколы

испытаний в испытательном центре и предоставляет сертификат качества,

в отношении которого предусмотрен контроль (надзор) органа

сертификации, выдавшего данный сертификат.

Статья 25. Обязательная сертификация

Она осуществляется на основании договора с заявителем.

Соответствие продукции требованиям регламентов подтверждается

сертификатом соответствия,

включающим в себя:

наименование и местонахождение заявителя, изготовителя

продукции и органа, выдавшего сертификат;

информацию об объекте сертификации, позволяющую идентифи-

цировать объект;

наименование ТРегл, на соответствие требованиям которого

проводилась сертификация;

информацию о проведенных испытаниях и документах заявителя,

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

соответствия требованиям регламентов;

срок действия

сертификата.

Статья 26. Организация обязательной сертификации

Орган по сертификации:

привлекает на договорной основе аккредитованные испытательные

центры (лаборатории);

осуществляет контроль объектов сертификации;

ведёт реестр выданных им сертификатов;

информирует органы госконтроля за соблюдением требований ТРегл

о продукции, поступившей на сертификацию, но не прошедшей её;

приостанавливает или прекращает действие выданного им ранее

сертификата.

Статья 27. Знак обращения на рынке

Используется для маркировки продукции, прошедшей

подтверждение соответствия (в информационных целях) и осуществляется

заявителем самостоятельно любым удобным для него способом.

ГЛАВА 7

Статья 37. Информация о несоответствии продукции требованиям

ТРегл

Изготовитель (продавец), которому стало известно о несоответствии

продукции, обязан сообщить об этом в орган госнадзора в течение 10 дней.

Продавец, получивший такую информацию, обязан довести её в течение 10

дней до изготовителя. При получении такой информации органом

госконтроля от других лиц последний должен

известить об этом

изготовителя (продавца) в течение 5 дней.

ГЛАВА 9

Статья 46. Переходные положения

До вступления в силу новых регламентов (в течение 7 лет)

требования к объектам ТР устанавливаются нормативно-правовыми

актами РФ и подлежат обязательному исполнению только в части,

соответствующей целям:

защиты жизни и здоровья граждан;

охраны окружающей среды;

предупреждения

действий, вводящих в заблуждение приобретателя.

Обязательное подтверждение соответствия осуществляется только в

отношении отечественной продукции.

Правительством РФ до вступления в силу ТРегл ежегодно

дополняется перечень объектов ТР, в отношении которых обязательная

сертификация заменяется добровольной.

Обязательные требования к объектамТР, в отношении которых

ТРегл в течение 7 лет не будут приняты, прекращают

своё действие.

Выданные сертификаты и документы об аккредитации до данного

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

4.3. Особенности сертификации программного обеспечения

Рекомендованные в [9] шесть характеристик качества ПО

представляют основу для оценки и сертификации программ различных

классов. При этом необходимо предварительно решить вопросы

установления метрик, важности каждой характеристики

, уровней

ранжирования, критериев оценки и разработки моделей оценивания

применительно к конкретным условиям применения ПО в определённой

организации. Важность каждой характеристики качества меняется в

зависимости от класса ПО, а также от различных точек зрения на их

важность со стороны пользователя, разработчика и руководителя. В

соответствии с этим разработчиками могут использоваться различные

метрики для одних и тех же характеристик ПО,

потому что одни и те же

метрики не применимы для всех фаз ЖЦ ПО. Так, если пользователя

интересует только качество конечной продукции, то разработчики

заинтересованы и в качестве промежуточных результатов на всех фазах

ЖЦ, так как без этого конечный результат может быть не оптимальным

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

более

заинтересованы в общем качестве ПО, чем в конкретных характеристиках,

и поэтому для них важнее вопросы сопоставления повышения качества с

критериями управляемости, такими как плановая задержка или перерасход

стоимости, так как для них основная задача состоит в оптимизации

качества в пределах ограниченной стоимости, трудовых ресурсов и

установленного времени [9].

Для шести

вышеназванных характеристик качества ПО используют

несколько достаточно апробированных метрик, но стандартами предусмат-

ривается возможность разработки организациями дополнительной

номенклатуры характеристик и показателей, своих собственных моделей

процесса оценивания и методов формирования метрик, связанных с этими

характеристиками. Это делается для более широкого охвата различных

областей применения ПО с определённой спецификой решаемых задач.

Считается общепринятым

, что наиболее объективным путём опреде-

ления важности характеристик является путь проведения экспертных оце-

нок на предмет выявления свойств, определяющих качество ПО конкрет-

ного применения, включая и те, которые не вошли в шесть обязательных

характеристик [9], и упорядочение их по предпочтительности.

Руководствуясь этим, в интересах оценки и сертификации ИС

специального назначения одним

из авторов при выполнении

соответствующей НИР был проведен опрос, в основу которого была

положена анкета с включённой в неё совокупностью характеристик

(свойств), полученной в результате анализа требований к ПО данной ИС.

Объективность опроса достигалась участием в нём 35 ведущих

специалистов из 10 организаций заказчиков и разработчиков ИС, а также

проверкой согласованности ответов

экспертов и исключением крайне

противоположных оценок. Результаты обработки такой информации с

учётом некоторой корректировки названий свойств, в соответствии с

рекомендациями [9] приведены в табл. 4.1.

Таблица 4.1

Характеристики свойств ПО

Наименование свойств Коэффициент

важности

Ранг свойства

Функциональные возможности

Надёжность

Сопровождаемость

Эффективность

Мобильность

Практичность

0,35

0,25

0,20

0,15

0,03

0,02

С учётом полученных данных применительно к рассмотренному

классу ПО можно выделить:

а) основные свойства – функциональные возможности, надёжность,

сопровождаемость, эффективность;

б) дополнительные свойства – мобильность, практичность.

Большинство из приведенных свойств присуще ПО и других

классов. Однако степень их важности будет отличаться, и не исключено

выявление новых свойств. Так, для ИС военного назначения

наиболее

важным свойством может быть надёжность, для систем управления

технологическими процессами – эффективность, а для ПО универсальных

ИС широкого применения – мобильность и функциональные возможности.

Следует отметить, что цель проведения таких экспертных оценок

состоит не столько в обеспечении «свёртки» комплексных показателей

качества в обобщённый, сколько в выделении основных и дополнительных

свойств и их

показателей, в возможном дополнении их новыми, что

допускается требованиями ГОСТов, ОСТов и других регламентирующих

документов.

Для таких сложных систем, как ПО ИС, нет возможности описать

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

испытаниях, сертификации и эксплуатации ПО приходится использовать

две группы показателей качества (ПК):

1) объективные (количественные) ПК, характеризуемые реально

измеряемыми

физическими величинами;

2) субъективные (качественные) ПК, характеризуемые, как правило,

фактом практического наличия или отсутствия того или иного свойства у

ПО и оцениваемые соответственно 1 или 0.

Использование качественных показателей хотя и вносит элемент

субъективизма в оценку ПО, но позволяет с определённой достоверностью,

зависящей от опыта и квалификации разработчика, заказчика или

пользователя, учесть степень

влияния таких свойств на качество всей ИС.

Степень субъективизма может быть значительно снижена при

использовании метода групповых экспертных оценок. Поскольку

стандартом [9] определено, что предложенные в нём характеристики – не

истина в последней инстанции, а только образуют основу для дальнейшего

уточнения и описания качества ПО, допустимо расширять состав

соответствующих свойств и номенклатуры показателей их оценки,

устанавливать свои собственные модели процесса оценивания и методы

формирования и проверки метрик, связанных с этими показателями, для

охвата различных областей применения и стадий ЖЦ. С учётом этого в

качестве примера совокупности показателей качества ПО для одной из ИС

может служить следующая совокупность:

1) количественные ПК:

а) функциональные ПК решения задач, определяемые назначением

ИС, – среднее время решения задачи, пропускная способность, время

ответа и другие;

б) среднее время наработки на

программный отказ;

в) среднее время восстановления после программного отказа;

г) коэффициент загрузки оперативной памяти;

д) коэффициент загрузки производительности;

е) ёмкость программ;

ж) время изменения логической структуры базы данных и выходных

форм;

2) качественные ПК:

а) информативность текстов;

б) соответствие программной документации требованиям

стандартов;

в) защищённость от НСД;

г) степень «дружественности» пользовательского

интерфейса и ряд

других.

Модель процесса оценивания качества и сертификации ПО должна

отражать основные этапы, требуемые для оценивания по характеристикам,

рекомендуемым стандартом [9], в соответствии с которым процесс состоит

из трёх стадий:

1) установление (определение) требований к качеству,

2) подготовка к оцениванию,

3) процедура оценивания.

Требования должны формулироваться в установленных ГОСТом

терминах характеристик

качества и комплексных показателей.

Подготовка к оцениванию включает в себя:

а) выбор метрик (показателей), сводящийся к установлению

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

иного признака свойств ПО;

б) определение уровней ранжирования, представляющее собой

разделение всей шкалы выбранных метрик на диапазоны, соответ-

ствующие различным степеням удовлетворения требований по конкрет-

ным показателям;

в) определение критериев оценки, позволяющих подытоживать

результаты оценивания различных характеристик с помощью специальных

таблиц решений, среднего взвешивания или других приёмов, для

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

признаков свойств и качества ПО в целом, о приёмке или отбраковке

программной продукции.

Процедура оценивания включает:

а) измерение, результатом которого является получение измеренного

признака свойств в масштабе выбранной метрики;

б) ранжирование, устанавливающее отнесение измеренного признака

к тому или иному уровню;

в) оценка, являющаяся последним этапом процесса оценивания ПО,

на котором обобщается множество установленных уровней и результатом

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

после

сравнения с другими факторами, такими как время и стоимость,

принимается решение о выпуске (или невыпуске) программной продукции

и её сертификации.

5. МЕТОДЫ ОЦЕНКИ ТЕХНИКО-

ЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ ПРОГРАММНЫХ СРЕДСТВ

НА РАЗЛИЧНЫХ ЭТАПАХ ИХ ЖИЗНЕННОГО ЦИКЛА

5.1. Порядок и методология проведения статического анализа

программных средств

Статический анализ проводится в соответствии со

стандартом [12],

все положения которого подлежат обязательному применению в

испытательных центрах (лабораториях), аккредитованных в системе

РОСИНФОСЕРТ. Данный стандарт распространяется на все программные

средства независимо от их назначения и области применения. Проведение

СА начинается обычно с построения графа вызовов, который отражает

модульную структуру ПС. Вершины графа изображаются в виде

прямоугольников, содержащих имена

компонент (модулей), ребра – в виде

стрелок. Затем формируется список путей вызовов.

Путь вызова представляет собой последовательность соприкаса-

ющихся ребер из графа вызовов (конечная вершина ребра является

начальной вершиной следующего ребра), где начальная вершина первого

ребра есть корень графа, а конечная вершина всегда представляет собой

компоненту, которая не содержит последующих вызовов, т

.е. если

иерархия вызовов является древовидной структурой, то это лист дерева.

Обычно в списке путей вызовов представлены все пути, которые

подлежат тестированию. Кроме того, этот список содержит полезную

информацию для сопровождения программы:

на основании последовательности вызовов компонент можно

непосредственно указать возможные результаты некоторой модификации;

можно немедленно узнать длину пути вызовов, а также

местонахождение и частоту появления компонент, что важно при

определении компонент, которые могут быть модифицированы;

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

Более наглядное и удобное представление о логической структуре

даёт матрица вызовов и достижимости, которая содержит информацию о

двух основных типах структур вызова между произвольными парами

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

взаимосвязей:

одна

из них непосредственно вызывает другую;

в графе вызовов существует путь, начинающийся на одном из

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

рассматриваемой пары не могут быть вызваны друг из друга

непосредственно, а лишь через цепочку последовательных вызовов.

Матрица вызовов и достижимости позволяет ответить на вопросы:

Если изменить

модуль А, то может ли это как-то повлиять на модуль

В (так называемый волновой эффект)?

Каково число модулей, вызываемых модулем А, и что это за модули?

Каково число модулей, достижимых модулем А, но не вызываемых

из него, и что это за модули?

Какие модули являются недостижимыми (никогда не

вызываемыми)?

Какие вершины графа являются конечными (не содержащими

вызова)?

Какие вызовы являются рекурсивными?

Строки и столбцы матрицы содержат имена компонент в иерархии

вызовов и упорядочены по иерархическим уровням сверху вниз. Крестик

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

вызывает компоненту, специфицированную столбцом. Точкой обозначен

факт косвенного вызова (достижение реализуется через цепочку

вызовов).

Диагональные элементы обозначены дефисами за исключением случая

рекурсивного вызова, при котором в качестве соответствующего

диагонального элемента матрицы будет стоять крестик или точка.

Эта информация используется при тестировании и сопровождении, в

частности при построении путей тестирования. Так как операторы

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

выбранного набора

входных данных, то существует много способов

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

определяется как маршрут в графе управления, начальная вершина

которого является входной вершиной графа, а конечная вершина –

выходной вершиной графа. Программа может иметь бесконечно большое

число возможных путей тестирования. В этом случае тестирование

сводится к исполнению некоторого набора маршрутов, покрывающего

каждую ветвь хотя бы один раз.

Оценка тестируемости ПС–(T) может быть

проведена с

использованием формул

Nв

Т = [(1 / N

) · (∑1 / P

)]

-1

i = 1

где N

– количество путей вызовов в графе вызовов модулей;

– тестируемость i-го пути вызовов, равная

= [∑1 / A(M

)]

-1

j = 1

где k – количество модулей в пути вызовов; А (М

) – доступность модуля

, принадлежащего пути Р

, определяется следующим образом:

А (М

) = ∑ А (М

) / C (М

x = 1

где А (М

) – доступность x-го модуля, вызывающего М

;

C (М

) – количество всех модулей, которые вызывает М

;

n – количество модулей, которые вызывают M

;

А(М) = 1, если модуль М является самым верхним (головным)

модулем.

Рассмотренный выше ручной метод статического анализа,

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

специальным экспертом, имеет следующие недостатки:

приводит к большим затратам времени и человеческих ресурсов;

требует привлечения эксперта высокой квалификации (как

программиста и как эксперта качества);

точность

результатов не всегда удовлетворительна из-за больших

объемов и сложности программ (в ряде случаев человеческие возможности

не позволяют применить ручной анализ).

Автоматизированные средства способны вычислить или помочь в

определении самых трудоемких характеристик, позволяя таким образом

эксперту сосредоточить внимание на интерпретации полученных

характеристик и уровне качества программы.

Независимо от способа

проведения СА (автоматизированного или

ручного) следует учитывать особенности СА на различных этапах.

1) Анализ и проектирование

Применение статического анализа на этих этапах требует прежде

всего наличия инструментального средства формальной спецификации,

обеспечивающего хранение результатов в машинообрабатываемой форме.

Статический анализ на этих этапах применяется прежде всего для

выявления ошибок и аномалий, т.е. является средством управления качест-

вом в отличие от этапа программирования, где

имеет оценочный характер.

Применение статического анализа на этапах анализа и

проектирования, несмотря на ограниченность измеряемых характеристик,

способствует раннему обнаружению ошибок, трудноисправимых на

последующих этапах.

2) Программирование

На этом этапе статический анализ используется для оценки качества

программы, а также для документирования (при разработке документов

сопровождения).

3) Тестирование и отладка

На этом этапе статический

анализ применяется для получения

исходной информации при подготовке и оценки полноты тестов.

Пример оценки тестируемости

Пусть граф вызовов имеет вид

A( i=1

i=1,2,3 i=2

i=4

, j = 0,1

i=4,5 i=5

i=6 i=3

i=6

Для данного графа N

= 6, C(M

x=0

) = 3, C(M

x=1

) = 3, C(M

x=2

) = 2,

C(M

x=3

) = 1, n = 3. n = 0

Тогда A(M

) = 1, A(M

) = A(M

) = ∑ A(M

x=0

) / C(M

x=0

) = 1/3

x = 0

n = 3

A(M

) = ∑ A(M

) / C(M

) = 1/3:3 + 1/3:2 + 1/3:1 = 11/18

x = 1

x=0

x=2

x=1

x=3

x=6

x=5

x=4

n = 2

A(M

) = ∑ A(M

) / C(M

) = 1/3:3 + 1/3:2 = 5/18

x = 1

n = 1

A(M

) = ∑ A(M

) / C(M

) = 1/3:3 = 1/9

x = 1

i=1

= [ ∑1/ A(M

)]

-1

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

j = 1

= [1/1+1:1/3 + 1:11/18]

-1

= 11/62

i=2

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

= [1/1 + 1:1/3 + 1:5/18]

-1

= 5/38

i=3

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

= [1/1 + 1:1/3 + 1:1/9]

-1

= 1/13

i=4

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

= [1/1 +1:1/3+1:18/11]

-1

=11/62

i=5

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

= [1/1 + 1:1/3 + 1:18/5]

-1

= 5/38

i=6

= [1/ A(M

) + 1/ A(M

) + 1/A(M

)]

-1

= [1/1 +1:1/3+1:18/11]

-1

=11/62

в 6

T = [1/N

·∑1/P

]

-1

= [1/6 ·∑1/P

]

-1

= [7,52]

-1

= 0,133.

i = 1 i = 1

5.2. Методика оценки трудоёмкости разработки программных средств

Трудоемкость разработки ПС рассчитывается с учетом объективных

и субъективных факторов [7]:

количество строк исходного текста, написанных разработчиком

(без учета текста, сгенерированного автоматически, использованного из

библиотек и т.д.);

сложность разрабатываемого ПС;

степень новизны разрабатываемого ПС;

уровень требований к показателям качества ПС;

условия и средства

разработки ПС;

опыт и квалификация разработчика.

5.2.1. Нормы времени и порядок расчета трудоемкости разработки ПС

Базовая трудоемкость разработки ПС (Т

) определяется по формуле

= Норм · К

сложн

где Норм – норма времени на разработку, определяемая в соответствии

с п. 5.2.2;

сложн

– коэффициент сложности ПС, определяемый в соответствии

с п. 5.2.4.

5.2.2. Норма времени на разработку ПС (Норм) определяется

по табл. 5.1 в

зависимости от исходного объема ПС (V

), определяемого в

соответствии с п. 5.2.3. Нормы времени, указанные в табл. 5.1, рассчитаны

на количество строк исходного текста, написанных разработчиком