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

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

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

выпуск машинных носителей, испытания ПС.

Все виды работ и задач, выполняемых на этих этапах,

сгруппированы для оценки трудоёмкости разработки ПС в 5 групп [2]:

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

внедрение.

Подробное рассмотрение состава и содержания работ в каждой

группе приведено в соответствующей литературе [7],

использованной при

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

(подразделы 6.1, 6.2). Важное значение для успешного их проведения

имеют результаты статического анализа.

2.4. Основные понятия и определения статического анализа

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

Статический анализ (СА) – это процесс анализа исходного текста

программы без её выполнения на ЭВМ [12]. СА программ проводится:

– для проверки модульной

структуры программного средства, а

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

структур с приведенными в программной документации;

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

анализа ПС и разработки плана тестирования ПС;

– оценки конструктивных характеристик программы, степени

простоты модификации и сопровождения программы;

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

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

лишних переменных;

– оценки текстовой сложности программы, затрат на ее разработку и освоение;

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

разрешении правовых споров;

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

качества программы.

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

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

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

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

получение следующих характеристик (графических и метрических):

модульная структура ПС;

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

характеристика текста программы.

Модульная структура анализируемого ПС представляется в виде

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

точек вызовов; метрик иерархии вызовов.

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

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

структуры управления.

Характеристики текста программ включают в себя: статистические

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

Граф вызовов – это ориентированный граф, в котором вершины – модули

ПС, а рёбра ориентированы от вызывающего модуля к вызываемому.

Граф

управления −это ориентированный граф, вершинами которого

являются логические блоки, а направленные ребра ориентированы в

направлении передачи управления между блоками.

Логический блок программы – это участок программы, состоящий из

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

вызовов и достижимости – это матрица, характеризующая отношение

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

компонент (модулей).

Путь вызовов – это последовательность соприкасающихся ребер из

графа вызовов, где начальная вершина есть корень графа, а конечная −

лист дерева.

Путь тестирования – это маршрут в графе управления программного

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

конечная вершина − выходной вершиной графа.

Точка вызовов – это местоположение вызова программной

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

расположения оператора вызова.

Кроме этого СА предусматривает определение ряда количественных

характеристик, таких как иерархическая и структурная сложность,

тестируемость и др.

Иерархическая сложность: I = N / L, где N – количество вершин в

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

Иерархическая сложность характеризует среднюю ширину уровня в

графе вызовов, т.е. количество

проектных решений, принимаемых на

отдельном шаге разработки программы.

Структурная сложность: S = D / N, где D – количество ребер в

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

Тестируемость – это свойство ПС, заключающееся в их

приспособленности к эффективному применению контрольных тестов,

зависящей от степени разветвления вычислительного процесса и

доступности модулей.

Доступность узла (модуля) характеризует структурную вероятность

вызова этого

модуля, зависящую от разветвленности дерева вызовов.

Если показатель тестируемости имеет малое значение, то

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

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

3. ЭФФЕКТИВНОСТЬ ТЕХНОЛОГИЙ ПРОЕКТИРОВАНИЯ

ПРОГРАММНЫХ СРЕДСТВ

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

Эффективность (полезность) технологий характеризуется в основном

трудоёмкостью и длительностью создания ПС, а также достигаемым

качеством. Критерии оценки качества ПС и ТЭП позволяют осуществлять

целевое управление их разработкой при применении конкретных технологий.

В процессе разработки ТЗ выявляются основные

показатели,

устанавливается относительная важность каждого из них и строится

обобщённая целевая функция требуемого качества, а также устанав-

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

должны обеспечить соответствующие технологии.

После завершения отладки и испытаний эти показатели и

обобщённая функция уточняются на предмет их соответствия ТЗ.

Различают функциональные и конструктивные критерии качества

ПС.

Первые отражают специфику применения и степень соответствия ПС их

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

результатов, разнообразие функций редактирования и т.д.). В ряде случаев

их можно свести к показателям обобщённой экономической

эффективности применения ПС в ЖЦ, характеризуемой величиной

экономии труда, энергии, материалов и т.п.

Вторые критерии оценивают

сложность программ, надёжность

функционирования, ресурсы ЭВМ, корректность программ и др.

Особо следует выделить временные показатели ЖЦ программ

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

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

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

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

характеристик на всех этапах ЖЦ.

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

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

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

критериев качества ПС и влияющих на них факторов. Управление

качеством ПС включает:

анализ системных требований к ПС и ранжирование критериев качества,

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

модульно-иерархического

построения ПС,

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

заданных требований к качеству ПС,

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

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

создание ПС с заданными значениями критериев качества.

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

формирования ТЗ.

При этом необходимо учитывать 2 типа ограничений:

1) ограничения знаний о методах решения задач,

2) ограничения ресурсов, доступных для реализации ПС.

3.3. Составляющие затрат в жизненном цикле программных средств

Почти всегда критерии качества связаны с экономическим эффектом

от применения ПС [10, 14, 15]. Его можно выразить доходом, повышением

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

энергопотребления и др. экономическими показателями. Во многих

случаях наиболее просто и обобщённо экономический эффект можно

описать доходом Э от использования ПС

в течение ЖЦ

продолжительностью t: Э = Э

ид

– C

сум

где Э

ид

– идеальная эффективность применения программ;

сум

– суммарные потери и затраты, снижающие предельный доход.

Это снижение происходит вследствие затрат на разработку C

сопровождение C

, эксплуатацию С

и из-за потерь в результате

недостаточной надёжности С

. Тогда Э = Э

ид

– С

Динамику совершенствования программ характеризует величина

экономической эффективности, отнесенная к общим затратам, при

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

больших затратах.

3.4. Основные факторы, влияющие на трудоёмкость разработки

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

Качество и эффективность технологии определяется прежде всего

затратами на разработку:

= С

1р

+ С

2р

+ С

3р

+ С

4р

+ С

5р

где С

1р

– затраты, связанные с непосредственной разработкой ПС;

2р

– затраты на изготовление опытного образца (5 – 10 %), часто не

учитываемые из-за малости;

3р

– затраты на программные средства автоматизации технологии;

4р

– затраты на аппаратные средства автоматизации технологии

(машинное время работы ЭВМ);

5р

– затраты на повышение квалификации специалистов (часто не

учитываются из-за малого значения и трудностей формализации, но

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

1р

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

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

= С

1р

+ С

3р

+ С

4р

В этой сумме при создании средних и крупных ПС все три

составляющие примерно равны, но основное внимание при анализе

следует обращать на С

1р

, так как на неё наиболее сильно влияет объём

разработки ПС. Приближённо можно считать, что затраты на разработку

должны быть прямо пропорциональны объёму создаваемых ПС (Пк) при

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

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

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

и разработчиков

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

3.5. Длительность разработки программных средств

Диапазон приемлемых длительностей разработок T

ограничен

сверху 10 годами (рациональными сроками создания самых сложных ИС),

а снизу – 1 – 3,5 года (сроками естественного технологического процесса).

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

зависимостью

= 0,8 П

1/3

, или Т

= 1,4 П

лет,

где П

– объём ПС в тысячах команд.

3.6. Распределение затрат по этапам разработки

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

различается в 2 – 4 раза, а загрузка отдельных категорий специалистов на

них – в 3 – 5 раз. Это надо учитывать при планировании и организации

проектирования ПС, а также при прогнозировании затрат на

непосредственную разработку программ. Так же

неравномерно в

зависимости от этапов изменяется и потребность в машинном времени

С4р, причём для разных ЭВМ (моделирующих, технологических,

реализующих) эта потребность находится в широком диапазоне и является

максимальной для этапа динамической отладки. Такие оценки затрат

машинного времени позволяют рационально планировать и

прогнозировать необходимую аппаратную оснащённость разработок по

этапам и

в целом на весь ЖЦ. Упорядоченный подход к организации

проектирования сложных ПС с учётом вышеизложенного позволяет

создавать ПС с высоким качеством и допустимыми затратами, если

использовать современные технологии, методы и системы автоматизации

проектирования, выбирая их на основе системного и технико-

экономического анализа достигаемого эффекта и ресурсов на весь ЖЦ.

4. ОБЩИЕ СВЕДЕНИЯ О СЕРТИФИКАЦИИ ИНФОРМАЦИОННЫХ

СИСТЕМ И ИХ ПРОГРАММНЫХ СРЕДСТВ

4.1. Основные понятия и определения

Сертификация – это деятельность определённого органа

(организации), независимого (ой) от изготовителя (продавца) и

потребителя продукции, по подтверждению её соответствия

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

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

удостоверение достигнутого качества и

надёжность функционирования

созданных ИС [11, 13].

С технической точки зрения, качество – это совокупность свойств

продукции, обуславливающих её способность удовлетворять

определённые потребности в соответствии с её назначением. Одним из

важнейших компонентов ИС, определяющих ее качество, является

программная продукция. Весь объём признаков и характеристик

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

потребностям пользователей ИС

, определяет качество программного

обеспечения (ПО) ИС.

Такие признаки и характеристики определяют свойства ПО, по

которым его качество описывается и оценивается. К ним относятся:

функциональные возможности, надёжность, практичность, эффективность,

сопровождаемость, мобильность. Каждая из этих характеристик может

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

(подхарактеристик), определяемых с учётом разрабатываемых для этих

целей метрик качества. Метрика качества – это количественный масштаб

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

значений признаков или характеристик конкретного ПО и последующей

оценки уровня качества ИС.

Уровень качества – это относительная характеристика, основанная

на сравнении совокупности характеристик качества продукции с

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

исходные (эталонные).

Для осуществления такого сравнения используют

ранжирование (действие по отнесению измеренного значения

характеристики к соответствующему уровню ранжирования).

Уровень ранжирования – это диапазон значений характеристики в

масштабе, позволяющем классифицировать (ранжировать) ПО в

соответствии с потребностями пользователей и принятыми критериями

оценки качества ПО.

Критерии оценки качества ПО – это набор определённых и

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

условий, которые используются для

решения о приемлемости общего качества конкретного ПО, принимаемого

в результате сертификации. При таком положительном решении выдаётся

сертификат соответствия установленным требованиям.

Кроме этого сертифицированная продукция маркируется знаком

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

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

продукции.

Орган, возглавляющий систему сертификации однородной

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

центром по сертификации. В

его подчинении находятся органы,

проводящие сертификацию соответствия, и испытательные лаборатории,

проводящие испытания определённой продукции. При объединении этих

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

«сертификационный центр». Эти органы подвергаются периодически

аккредитации – процедуре официального признания (соответствующим

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

конкретных работ в заданной области.

Взаимоотношения между участниками – разработчиками

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

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

№ 184-ФЗ от 27.12.02 «О техническом регулировании». Ниже

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

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

нововведениях.

4.2. Основные положения закона «О техническом регулировании» (ТР)

4.2.1.

Структура закона

Закон состоит из 9 глав, которые включают в себя 48 статей:

1. Общие положения.

2.Технические регламенты (ТРегл).

3. Стандартизация.

4. Подтверждение соответствия.

5. Аккредитация органов по аккредитации.

6. Государственный контроль за соблюдением требований ТРегл.

7. Информация о нарушениях требований ТРегл и отзыв продукции.

8. Информация о ТРегл и документах по стандартизации.

9. Финансирование в

области ТР.

4.2.2. Содержание закона

ГЛАВА 1

Статья 1. Сфера применения

Пункт 1. Закон регулирует отношения, возникающие при разработке,

принятии, применении и исполнении:

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

эксплуатации, хранения, перевозки, реализации и утилизации;

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

другим объектам ТР, а также при оценке соответствия.

Пункт 3. Действие закона не распространяется на государственные

общеобразовательные стандарты, положения о бухучёте и правила

(стандарты) аудиторской деятельности, стандарты

эмиссии ценных бумаг

и проспектов их эмиссии.

Статья 2. Основные понятия

Декларация о соответствии – документ, удостоверяющий

соответствие продукции требованиям ТРегл.

ТРегл – документ, принятый международным ратифицированным

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

РФ) и устанавливающий обязательные для применения и исполнения

требования к объектам ТР.

Статья 3. Принципы ТР:

применение

единых правил установления требований к объектам ТР;

соответствие ТР уровню национальной экономики и научно-

технического развития;

независимость органов по аккредитации и сертификации от

субъектов – изготовителей, продавцов, исполнителей и приобретателей;

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

(надзора) и органа сертификации, а также полномочий на сертификацию и

аккредитацию.

Статья 4. Законодательство РФ

о ТР

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

сфере ТР акты только рекомендательного характера, за исключением

случаев, определённых в статье 5.

Статья 5. Особенности ТР в отношении оборонной продукции и

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

В отношении такой продукции вышеуказанные акты могут носить

обязательный характер.

ГЛАВА 2

Статья

6. Цели принятия ТР:

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

охрана окружающей среды, жизни животных и растений;

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

Статья 7. Содержание и применение ТРегл

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

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

отсутствие не противоречит

целям принятия регламентов, изложенным в

статье 6.

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

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

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

приобретателя о вреде и факторах, от которых вред зависит.

Статья 8. Виды ТРегл

В РФ действуют общие ТРегл и специальные ТРегл.

Требования общих регламентов обязательны

для применения ко

всем объектам ТР, а требованиями специальных регламентов учитываются

технологические и иные особенности отдельных объектов ТР.

Статья 9. Порядок разработки, принятия, изменения и отмены ТРегл

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

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

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

полученных замечаний

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

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

регламентов.

Статья 10. Особый порядок разработки и принятия ТР

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

жизни, здоровью и т.п., президент РФ вправе издать регламент без его

публичного обсуждения.

ГЛАВА 3

Статья 11. Цели стандартизации:

повышение

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

повышение уровня безопасности объектов;

обеспечение научно-технического прогресса;

повышение конкурентоспособности продукции;

рациональное использование ресурсов;

техническая и информационная совместимость;

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

взаимозаменяемость продукции.

Статья 12. Принципы стандартизации:

добровольное применение стандартов;

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

разработке

стандартов;

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

национальных стандартов;

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

обеспечение условий для единообразного применения стандартов.

Статья 13. Документы в области стандартизации:

национальные стандарты;

правила стандартизации, нормы и рекомендации;

классификации, общероссийские классификаторы социальной и

технико-экономической информации;

стандарты организаций.

ГЛАВА 4

Статья 18. Цели подтверждения соответствия:

удостоверение соответствия продукции ТРегл, стандартам и

условиям договоров;

содействие приобретателям в выборе продукции и других объектов ТР;

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

российском рынках;

создание условий для свободного перемещения товаров по РФ

, а

также для международного сотрудничества и торговли.

Статья 19. Принципы подтверждения соответствия:

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

подтверждения соответствия;

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

соответствия к объектам, для которых не установлены требования ТРегл;

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

соответствия определённых видов продукции ТРегл;

недопустимость принуждения к

добровольному подтверждению

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

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

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

Статья 20. Формы подтверждения соответствия:

подтверждение соответствия на территории РФ может носить

добровольный или обязательный характер;

добровольное подтверждение соответствия осуществляется в форме

добровольной сертификации;

обязательное подтверждение соответствия осуществляется в формах

принятия

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

Статья 21. Добровольное подтверждение соответствия:

может осуществляться для установления соответствия наци-

ональным стандартам, стандартам организаций, системам добровольной

сертификации и условиям договоров;

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

объекты ТР, для которых стандартами, системами добровольной

сертификации и договорами устанавливаются соответствующие

требования.

Орган по сертификации подтверждает соответствие

объектов ТР;

выдаёт сертификат соответствия; приостанавливает или прекращает

действие выданных им сертификатов соответствия.