Липаев В.В. Сертификация программных средств. Учебник

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

Лекция

11.

Удостоверение

качества и завершение ...испытаний... 311

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

предлагаемого

изменения

рисков комплекса программ, целесообраз-

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

• насколько данное изменение риска может улучшить эксплуа-

тационные характеристики и функциональную пригодность про-

граммного продукта в целом;

• каковы затраты на выполнение корректировок комплекса

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

и их распространение пользователям;

• какова срочность извещения пользователя о разработанной

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

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

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

изменение риска;

• как данное изменение риска отразится на эксплуатации поль-

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

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

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

го продукта.

Выше анализировалось и оценивалось преимущественно изме-

нение функциональной пригодности и снижение риска при совер-

шенствовании характеристик программного продукта. Однако для за-

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

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

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

трат и определяют основной эффект и риск от применения программ-

ного продукта, а также потенциальный уровень спроса на рынке.

Испытания эксплуатационной документации на

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

Эксплуатационная документация должна обеспечивать эффектив-

ное применение программного продукта и точно отражать его назначе-

ние,

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

фицированными специалистами - пользователями. Для этого эксплуа-

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

выполнения всей совокупности требований на программный про-

дукт,

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

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

312

В. В.

Липаев. Сертификация программных средств

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

третий эталон

(кроме требо-

ваний

тестов - см. лекцию 7), для

квалификационного тестирования

и испытаний реализации функций и характеристик продукта. Практи-

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

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

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

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

ментов должны обеспечивать комфортное и корректное применение

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

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

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

тов при эксплуатации.

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

стандарты, процедуры, распределение ресурсов и планы создания, из-

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

общем случае должны быть выделены

специалисты,

которые обязаны

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

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

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

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

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

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

четных документов.

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

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

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

типовых

структур

шаблонов

для двух классов продуктов, которые в

наибольшей степени различаются особенностями эксплуатации [15].

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

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

масштабе времени. В процессе их применения допускается минималь-

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

нием, и необходим, соответственно, небольшой объем эксплуатацион-

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

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

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

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

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

Лекция

11.

Удостоверение

качества и завершение.,.испытаний... 313

Документация администрирования при эксплуатации систе-

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

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

сле сбоев. Администратор системы и программного продукта должен

быть информирован о всех изменениях функционирования устройств

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

вению аварийной ситуации, и предпринимать соответствующие про-

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

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

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

мощью специальных программных средств, поддерживающих адми-

нистрирование и управление системой. Каждый из документов адми-

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

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

ми данных, на защиту и обеспечение безопасности информации.

Документация для оперативных пользователей программ-

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

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

различными аппаратно-программными реализациями терминалов.

Для этого необходима унификация концепции, архитектуры, функций

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

формы-шаблоны документов и процедуры работы с ними, расс-

матриваемые как объекты стандартизации, относятся в основном к

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

телей с системами и программными продуктами [15].

Стандарты ISO 15910 и ISO 18019 являются наиболее современ-

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

дания

эксплуатационной документации

для

пользователей

крупных

программных

продуктов.

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

нов документирования, ориентированных на разработчиков докумен-

тов,

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

цедуры контроля реализации плана. Эксплуатационная документация

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

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

характеристикам, а также

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

реального программного продукта.

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

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

314

В. В.

Липаев.

Сертификация программных

средств

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

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

документации,

реализация которого

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

Стандарты также определяют виды информации, представляемой заказ-

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

пространения документации. Стандарты определят реализацию про-

цесса документирования, описанного в ISO 12207, и могут быть

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

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

пример, с использованием ISO 12207

и/или

ISO 6592), что должно

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

Описание требований эксплуатационной концепции для сис-

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

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

существующими системами и процедурами. Его используют при соз-

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

лями. Данный документ фиксирует текущее состояние системы и

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

раничения в зависимости от режима или конкретного состояния экс-

плуатации и включает

описания:

• конкретной эксплуатационной среды

ее характеристики;

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

системы и связей между ними;

• внешних интерфейсов программного продукта

системы;

• возможностей, функций и характеристик программного про-

дукта

системы;

• состава эксплуатационного персонала, его организационной

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

действия;

• форм регистрации обнаруженных дефектов

ошибок;

• соглашений о внесении изменений, возникающих в процессе

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

• концепцию поставки новой или модифицированной версии

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

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

разработчика и предприятия, осуществляющего поддержку про-

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

Лекция

11.

Удостоверение

качества и завершение... испытаний... 315

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

ных контактов заказчика

с разработчиками программного продукта,

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

ции и соответствующих ей аудиторий. Обязанностью разработчика

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

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

ряде случаев требуется сохранить конфиденциальность

секретность пре-

доставленных материалов. В договоре должны быть установлены уровни

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

мых заказчиком документатору.

План документирования должен включать определение ауди-

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

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

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

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

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

документацией. Каждый тип пользователей, включая их характери-

стики и задачи, решаемые ими при помощи документации, должен

определяться отдельно.

План документирования должен быть официально согласован и

утвержден, что подтверждает полный учет и тестирование в доку-

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

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

няемые при разработке документации. План документирования дол-

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

ции,

чтобы гарантировать согласование всеми сторонами содержания

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

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

рон,

включая разработчиков документации, а также заказчика и суб-

подрядчиков [15].

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

заказчиком с привлечением документаторов. Целью проверки являет-

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

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

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

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

плана документирования. Про-

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

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

316

В. В.

Липаев. Сертификация программных средств

ментах и их утверждению. Заказчик должен хранить копии всех вноси-

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

тов.

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

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

соответствии с планом-проспектом ее со-

держания. План документирования должен быть проверен и утвержден

до начала работ над первым проектом документации.

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

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

пов.

Для этого необходимо, чтобы разработчики документации полу-

чали учтенные копии изменений требований к программному про-

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

данную версию после конкретной даты ее пересмотра.

Испытания эксплуатационной документации на практич-

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

кам и анализам документации. При необходимости в плане докумен-

тирования следует определить внешнюю среду тестирования, которая

должна полностью соответствовать эксплуатационной среде конеч-

ного пользователя и требованиям к программному продукту. При

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

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

программному продукту.

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

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

дартах ISO 9126 и ISO 25000. Практичность -применимость: свой-

ства программного продукта и документации, отражающие слож-

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

ных пользователей при применении в указанных условиях. Требова-

ния к практичности и ее характеристикам - понятности и простоте

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

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

обеспечения удобной и комфортной эксплуатации. Для обеспечения

полноценного изучения процессов применения программного про-

дукта специалистами необходима эксплуатационная документация,

объем которой существенно зависит от назначения и функций, и мо-

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

проектов. Для некоторых проектов, подлежащих широкому тиражи-

рованию, могут быть желательны адекватные по содержанию элек-

тронные учебники, требования к объему и функциям которых целе-

Лекция

11.

Удостоверение

качества и завершение... испытаний.., 317

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

малый объем эксплуатационной документации может снизить качест-

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

большой объем - также может ухудшить эксплуатацию из-за трудно-

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

наиболее существенных свойств и особенностей его применения.

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

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

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

результатов функционирования комплекса программ. Примени-

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

документации - понятие достаточно субъективное и трудно фор-

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

функциональную пригодность и эффективность применения продук-

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

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

простоту использования. Некоторые характеристики можно оцени-

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

циалистов на реализацию соответствующих функций.

Понятность: свойства, обеспечивающие пользователю пони-

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

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

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

и субъективных впечатлений от функций и характеристик программ-

ного продукта. Ее можно описать качественно четкостью функцио-

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

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

ционной документации возможных функций и особенностей их реа-

лизации.

Простота

использования:

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

комфортно эксплуатировать и управлять программным продуктом.

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

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

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

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

лей. Эта характеристика учитывает физические и психологические

особенности пользователей и отражает уровень комфортности усло-

вий эксплуатации, возможность предотвращения ошибок пользовате-

318

В. В.

Липаев. Сертификация программных средств

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

намических параметров: временем ввода и отклика на задание, дли-

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

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

ками временной эффективности. Простоту использования комплексов

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

теризует корректность и адекватность описаний интерактивных ди-

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

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

атрибуты этой характеристики доступны для более полной количест-

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

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

пользователей к полноценной и эффективной эксплуатации про-

граммного продукта.

Изучаемость: свойства программного продукта и документа-

ции, обеспечивающие удобное освоение его применения достаточно

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

доемкостью и длительностью подготовки пользователя к полноцен-

ной эксплуатации продукта. Качество изучаемости зависит от внут-

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

также от субъективных характеристик квалификации конкретных

пользователей. На значения изучаемости существенно влияют демон-

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

объем эксплуатационной документации.

Приобретение, поставка, разработка, функционирование и со-

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

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

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

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

разработке или сопровождении. Для достижения высокого качества

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

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

испытаний

програлшного про-

дукта.

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

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

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

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

что трудно учесть в достаточно общем виде. Эти затраты сопутст-

Лекция

11.

Удостоверение

качества и завершение...испытаний... 319

вуют в некоторой степени всем этапам разработки, однако, оформ-

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

альном этапе работ. Затраты на разработку комплекта эксплуатации-

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

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

ми на объем текста документов ориентировочно 5-10 страниц на

тысячу строк программы.

Завершение сертификационных испытаний

программных продуктов

Предъявляемый заявителем на сертификацию программный

продукт должен представляться в комплекте с соответствующей до-

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

ориентированы на общий случай удостоверения качества версий

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

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

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

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

рые документы могут объединяться в интегрированные отчеты с чет-

кой ответственностью определенных специалистов за их выполнение

[15].

Ориентировочный комплект основных документов при сер-

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

групп:

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

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

разработчикам на их основе Программа, Руководство и инструкции,

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

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

рис.

11.2;

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

тельных испытаний и характеристики сертифицируемого программно-

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

(заявителем) для сертификации его качества - рис. 11.3;

• результирующие документы сертификационных испытаний

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

ции, заявителю и руководству производства для утверждения серти-

фиката

знака качества - рис. 11.4.

320

В. В.

Липаев. Сертификация программных средств

Базовые

нормативные

документы

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

качества

программного продукта

и их

производства:

- концепция, требования и Руководство по улучшению деятельно-

сти - Системы менеджмента качества - ISO 9000:2000 или версия

модели зрелости CMMI;

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

разрабатывающего программный продукт - ISO 900003;

- жизненный цикл программных средств - ISO 12207, ISO 15504;

- сопровождение и конфигурационное управление версиями про-

граммного продукта ISO 14764, ISO 15846;

- характеристики качества программных продуктов - ISO 9126,

ISO 14598, ISO 25000;

- функциональной безопасности программных продуктов - IEC

61508, ISO 15408;

- документирования программных продуктов - ISO 15910, ISO

18019;

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

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

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

Рис.

11.2

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

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

качеству, а также от характеристик проектирования, разработки и мо-

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

среды. Поэтому необходимый комплект документов для каждого

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

вать профиль стандартов, применительно к этим характеристикам.

Заявитель должен подготовить и предъявить испытательной ла-

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

вержденный комплект исходных документов для проверки их досто-

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

вии с нормативными документами (см. рис. 11.2).

При подготовке для сертификационных испытаний про-

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

следует зафиксировать результаты [3, 11]:

• завершена разработка всех функций комплекса программ и

исправление всех выявленных ошибок;

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