Сборник лекций по МДК "Документирование и сертификация"

УЧЕБНОЕ   ПОСОБИЕ	Ульяновский авиационный колледж - МЦК
	ПРОФЕССИОНАЛЬНЫЙ ЦИКЛ
	МДК 03.03 ДОКУМЕНТИРОВАНИЕ И СЕРТИФИКАЦИЯ КУРС ЛЕКЦИЙ для специальности СПО базовой подготовки 09.02.03 Программирование в компьютерных системах Ульяновск  2018
ОДОБРЕНО на заседании ЦМК программирования и ИТ Протокол № 6 от «10» января 2018 г. Председатель ЦМК: ____________ М.М. Чубыкина		УТВЕРЖДАЮ Заместитель директора по учебно- методической  работе: _______________ Л.Н. Подкладкина «10» января 2018 г.
СОСТАВИТЕЛЬ: Мардамшина А.А., преподаватель первой категории ОГАПОУ «УАвиаК-МЦК»

СОДЕРЖАНИЕ

	стр
СТАНДАРТИЗАЦИЯ ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ……..	4
ДОКУМЕНТИРОВАНИЕ ОСНОВНЫХ ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ………………………………………………………...	16
ДОКУМЕНТИРОВАНИЕ ВСПОМОГАТЕЛЬНЫХ ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ………………………………………………	33
ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ……………………………...	58
СЕРТИФИКАЦИЯ ПРОГРАММНЫХ СРЕДСТВ…………………………………………...	62
ИСПОЛЬЗОВАННАЯ ЛИТЕРАТУРА……………………………………………………….	70

СТАНДАРТИЗАЦИЯ ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-команда разработчиков ПС, получает представление о сложности и размере создаваемого продукта и составе его документации;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-адаптация состава и содержания документов к данной деловой, проблемно-ориентированной области, например, авиационной, медицинской, военной, финансовой или административной;

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

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

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

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

 -размер и относительная доля готовых программных компонентов и документов, которые могут быть заимствованы из предшествовавших проектов и повторно использованы в новом проекте ПС;

 -относительные затраты ресурсов на создание проекта с оцененным масштабом: труда специалистов, времени, бюджета на единицу размера (на строку тек- ста программ) или полные затраты на разработку всего ПС и комплекса документов.

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

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

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

 -общую структуру комплекта документов;

-номенклатуру и содержание (или ссылки на шаблоны) каждого документа;

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

-регламент комплектования и хранения документов;

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

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

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

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

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

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

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

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

Адаптация номенклатуры и содержания документов ПС к особенностям системы и пользователей может базироваться на выборе подходящих шаблонов из набора документов, представленных в главе 3. В процессе адаптации состава и содержания документов должны быть учтены особенности пользователей, поддерживающего персонала, руководителей контракта, потенциальных покупателей. Процессы, работы шаблоны и задачи ЖЦ должны селектироваться и включать в себя перечень документов, которые нужно разработать и информацию о персональной ответственности за них. Выбранные процессы, работы и задачи, не обеспечиваемые конкретными документами, следует оговаривать в самом контракте и утвержденном ЖЦ ПС. При адаптации документирования ПС необходимо также учитывать особенности проекта: стоимость, планирование, производительность специалистов, размеры проекта и интерфейс с человеком-пользователем. Все исходные данные и решения по адаптации номенклатуры, структуры и содержания документов должны быть документированы и утверждены руководством проекта вместе с обоснованием их целесообразности.

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

Важнейшим фактором при оценивании затрат на документирование в ЖЦ ПС являются люди – специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности, повышение требований и ответственности за качество документов комплексов программ привели к появлению новых требований к специалистам, обеспечивающим все этапы жизненного цикла ПС. Каждый специалист ограничен в своих возможностях, способностях и квалификации, что отражается на специфических дефектах результатов и документах его деятельности. Специалисты в соответствии со своей квалификацией и ролью в проекте вносят в него специфические дефекты и ошибки достаточно определенных категорий, что целесообразно учитывать при прогнозировании документов проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными ресурсами в стандарте, для документирования выделяются: персонал; инструментальные средства; финансирование.

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

Стандарт ISO 12182 – описывает схему классификации программных средств, охватывающую существенные характеристики и атрибуты, отражающие и определяющие ПС, их виды и классы. Установленная в стандарте классификация предназначена для определения классов конкретных ПС, и связей программных задач, процессов или продуктов и их документов со стандартами программной инженерии. В настоящем стандарте установлена схема классификации, помогающая:

 - уточнить области применения используемого стандарта или ПС;

 - определить, выбрать стандарты и шаблоны документов, применимые к конкретному проекту ПС;

 -определить классификационные характеристики новых стандартов.

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

В стандарте ISO 12207 документированию посвящен специальный раздел 6.1 в группе вспомогательных процессов. Кроме того, почти все процессы и работы основного, пятого раздела стандарта, представляющего этапы и работы жизненного цикла ПС, отражают конкретные требования к документированию соответствующих работ. Специальный раздел стандарта по документированию ПС имеет следующее содержание (c небольшими сокращениями нумерации).

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

Реализация процесса – должен быть разработан, документирован и реализован план, идентифицирующий документы, которые должны быть произведены в течение жизненного цикла программного продукта. Для каждого идентифицированного документа должно быть определено следующее: заглавие (титул) или название; цель; предназначенная аудитория; процедуры и обязательства для вводов, разработки, обзора, модификации, утверждения, производства, хранения, распределения, сопровождения и управления конфигурацией; план, режим, программа для промежуточных и конечных (заключительных) версий.

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

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

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

Стандарт ГОСТ Р 51904 регламентирует документы, которые создаются в течение всего жизненного цикла ПС. Эти документы позволяют реализовать процессы и модификацию программного средства.

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

Эксплуатационная документация должна обеспечивать эффективное применение программных средств в соответствии с их назначением и функциями квалифицированными специалистами-пользователями. Состав и содержание комплекта документов конкретного программного продукта, следует адаптировать разработчиками к его особенностям и свойствам на основе использования стандартов и типовых структур – шаблонов. Разработчики документов должны обеспечивать комфортное и корректное применение ПС пользователями, на основе ясного и непротиворечивого изложения в документах технологических процедур и операций для функционирования и получения требуемых результатов. На базе представленного в стандарте набора и содержания документов следует выделять из них необходимые для двух классов ПС, которые в наибольшей степени различаются особенностями эксплуатации. Первый класс характеризуется комплексами программ автоматизированного управления динамическими объектами и процессами в реальном масштабе времени. В процессе их применения допускается минимальное вмешательство и процедуры пользователей, и необходим, соответственно, небольшой объем эксплуатационных документов, выделяемых из базового комплекта (малый – в таблице 3.7). Для ПС второго класса воз- можно применение пользователями широкого набора процедур управления, которые должны быть регламентированы достаточно полным набором и подробным содержанием документов. Все последующее изложение ориентировано на этот класс ПС и в п. 3.7 представлен широкий набор шаблонов базовых документов (крупный – в таблице 3.7).

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

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

- операторы – пользователи, реализующие функционирование и применение программных средств в системе, обработку и анализ результатов.

Стандарт ISO 15910 является наиболее современным нормативным документом, регламентирующим процессы создания эксплуатационной документации для пользователей сложных программных средств. Целью стандарта является стимулирование разработчиков программных средств к методичному использованию процесса документирования. Он построен по традиционной схеме стандартов ISO и первые семь разделов являются вводными, а также определяют терминологию. Основное, функциональное содержание стандарта сосредоточено в 8-м разделе – Требования к документированию ПС. В разделе 8.1 – Процессы документирования программных средств – представлена общая схема процессов и их взаимодействие. Изложена детальная структура плана документирования, ориентированного на разработчиков документов, и процедуры контроля реализации плана. Обзоры – описания документов, рекомендуется подготавливать в виде двух последовательно уточняющихся и детализирующихся редакций с окончательной корректурой и проверкой их адекватности путем тестирования. Пользовательская документация должна проходить испытания на достоверность, которые должны быть спланированы и реализованы типовыми пользователями на базе применения эксплуатационных процедур реального программного средства. Описана координация документирования у субподрядчиков, а также конфигурационное управление изменениями и сопровождение документов. Раздел 8.2 посвящен требованиям к содержанию и стилю изложения типовой спецификации. Изложены требования к языку и грамматике составления документов, к оформлению содержания текста, рисунков и таблиц, к характеристикам и качеству используемой бумаги. Подробно описаны технические правила оформления твердой копии документов и правила структурирования и представления схем компонентов, окружения, иллюстраций и основного текста документов. Специальный подраздел посвящен подготовке электронных документов: общей схеме, размещению материала и комментариев, помощи подсказками, навигации по тексту, использованию клавиатуры.

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

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

Процесс документирования должен быть выполнен в два этапа. Поэтапные работы выполняются не одновременно. На отдельных этапах работы могут проводиться параллельно. Возможные итерации работ показаны пунктирными линиями. Минимальный состав документации определяется заказчиком (например, с использованием ISO 12207 или ISO 6592), что должно быть учтено документатором при разработке плана документирования.

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

В стандарте ISO 15910 представлено восемь приложений, содержащих примеры и расширяющих некоторые концепции базовой части стандарта: Приложение А. Перекрестные ссылки с стандартом ISO 12207.

Приложение В. Использование настоящего стандарта в договоре и практическое применение настоящего стандарта.

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

С.1. Введение

С.2. Область применения и ограничения

С.З. Оформление и стиль описания

С.4. Аудитория

С. 5. Проект содержания документации

С. 6. Номенклатура поставки

С.7. Авторские права

С.8. Транспортирование

С.9. Процесс разработки и контроль

С. 10. Тиражирование

С. 11. Проектанты

С. 12. Ресурсы

С. 13. Тестирование на практичность

С. 14. График работ

Приложение D. Отношения между аудиториями, выданными заданиями, бумажной и диалоговой документацией.

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

Приложение F. Оценка ресурсов для проекта документирования. Приложение G. Оценка плана документирования.

Приложение Н. Образец спецификации стиля.

Стандарт IEEE 1063-1987 (подтвержден 1993) отражает общие требования к пользовательской документации на программные средства широкого применения. Стандарт определяет минимальные требования к структуре и содержанию комплекта документов для пользователей программных продуктов. Стандарт ориентирован на документы, применяемые при инсталляции, эксплуатации и поставке ПС любого размера и назначения, но без изменения и сопровождения программ. Он не применим для технологической документации, используемой при проектировании, разработке, тестировании, испытаниях и сопровождении ПС, а также для оформления коммерческих пакетов прикладных программ. Использование стандарта не должно препятствовать применению более строгих и широких требований к документам, а также собственных стандартов предприятия по стилю изложения документов.

Стандарт ISO 9127 рекомендуется для создания пользовательской документации на коммерческие пакеты (закрытые коробки) программных средств, поставляемых на рынок. Пользовательская и рекламная документация на пакеты программ должна включать:

Общие сведения: введение; ограничения; область применения; определения; ссылки.

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

В Советском Союзе в 70-е годы была разработана Единая Система Программной Документации (ЕСПД) в составе группы стандартов ГОСТ 19.ХХХ. Большинство этих стандартов устарело, не соответствует современным требованиям и их применение не целесообразно. Более качественно стандартизация документирования программ и данных отражена в некоторых стандартах по автоматизированным системам ГОСТ 34.ХХХ, утвержденных в конце 80-х годов. В настоящее время наиболее полезно освоить и использовать некоторые их фрагменты, которые можно отнести к документированию программ и данных, из стандартов:

ГОСТ 34.201-89 – Информационная технология. Виды, комплектность и обозначение документов при создании автоматизированных систем;

ГОСТ 34.602-90 – Информационная технология. Техническое задание на создание автоматизированных систем;

РД 50-34.698-90 – Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.

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

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

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

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

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

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

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

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

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

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

ДОКУМЕНТИРОВАНИЕ ОСНОВНЫХ ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

- определение профиля заказчика или пользователя:

* имя, компания, отрасль;

* что в основном производится;

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

* какие проблемы влияют на успешность деятельности пользователя;

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

* почему существует эта проблема;

 * как она решается в настоящее время;

* как заказчик (пользователь) хотел бы ее решать;

- пользовательская среда:

* имеют ли пользователи опыт работы с данным типом программных средств;

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

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

* в каком виде должна быть представлена справочная информация для пользователя (в интерактивном или в виде печатной копии);

- предположения аналитика – разработчика относительно проблемы заказчика:

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

* каковы причины проблемы;

* как она решается в настоящее время;

* насколько важно для заказчика (пользователя) решение этой проблемы в сравнении с другими;

 - оценка предлагаемого аналитиком метода решения проблемы;

- оценка возможности:

* кто в организации – заказчика нуждается в данном ПС;

* сколько пользователей указанных типов может использовать ПС;

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

* каковы ожидания относительно надежности;

* какой должна быть производительность;

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

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

* существуют ли специальные требования по лицензированию;

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

 - заключение аналитика – потребности или проблемы, с наивысшими приоритетами, выявленные в беседе с заказчиком (пользователем).

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

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

* результаты её функционирования;

* тенденции развития;

* требования к номенклатуре и качеству результатов функционирования;

* характеристики взаимодействия системы с внешней средой;

* существующие характеристики качества системы и тенденции их изменения во времени;

 - описание существующей системы:

* функциональной и информационной структуры системы;

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

 - описание недостатков существующей системы:

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

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

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

 - обоснование необходимости совершенствования системы:

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

* степень соответствия прогнозируемых характеристик требуемым;

* необходимость совершенствования системы путем создания нового или модернизации существующего ПС;

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

* производственно-хозяйственные, научно-технические и экономические цели создания ПС;

* критерии оценки эффективности создания ПС;

* ограничения ресурсов при создании нового ПС;

- функции и задачи создаваемого, нового ПС:

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

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

* требования к характеристикам реализации функций и задач;

- ожидаемые технико-экономические результаты создания ПС:

* перечень основных источников экономической эффективности, получаемых в результате создания ПС;

* оценка ожидаемых изменений основных технико-экономических и социальных показателей функционирования системы;

* оценка ожидаемых затрат на создание и эксплуатацию ПС с распределением их по очередям создания системы и по годам;

* ожидаемые обобщающие показатели экономической эффективности системы с новым ПС;

 - выводы и предложения:

* о производственно-хозяйственной необходимости и технико- экономической целесообразности создания нового ПС;

* о совершенствовании организации и технологии процесса деятельности системы и ПС;

* обобщенные рекомендации по созданию нового или модернизированного ПС.

Технико-экономическое обоснование проекта программного средства:

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

- стандарты и методы, которые должны быть применены при разработке требований к структуре и компонентам ПС;

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

 - общие исходные данные:

* класс и общие функции проекта ПС;

* цели анализа и возможная достоверность исходных данных;

* новизна проекта и функций комплекса программ;

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

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

* требуемый уровень обобщенной слаженности и организованности коллективной разработки проекта;

* возможный уровень обеспечения и оснащения технологии разработки по методике СММ;

* наличие значительного ограничения сроков разработки ПС;

- выбор методики и сценария первичной оценки требований технико-экономических характеристик ПС;

* оценка размера - масштаба программного продукта проекта;

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

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

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

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

- оценка влияния технико-экономических факторов на качество проекта ПС;

 * оценка влияния требования надежности ПС;

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

* оценка влияния уровня и стабильности коллектива специалистов проекта ПС;

* тематическая квалификация специалистов;

* технологическая квалификация проектировщиков и программистов;

* оценка влияния технологической среды разработки на технико-экономические показатели проекта ПС;

* оценка влияния вычислительной среды и ограничения ресурсов объектной ЭВМ реального времени на технико-экономические показатели проекта ПС;

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

- предварительная оценка результирующих технико-экономических характеристик проекта ПС:

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

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

* уточненный расчет необходимого числа специалистов для разработки проекта ПС;

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

- обобщение основных технико-экономических характеристик и полной стоимости разработки проекта ПС;

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

Концепция и основные предложения по созданию базовой версии программного средства:

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

- перечень базовых стандартов проекта программного продукта;

- описание потребностей потенциальных пользователей ПС;

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

* назначение комплекса задач;

 * перечень объектов (технологических объектов управления, подразделений предприятия и т. п.), при управлении которыми решают комплекс задач;

* периодичность и продолжительность решения;

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

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

 - входная информация:

* источники информации и их идентификаторы;

* перечень и описание входных сообщений (идентификаторы, формы представления, сроки и частота поступления);

* перечень и описание структурных единиц информации входных сообщений или ссылка на документы, содержащие эти данные;

- выходная информация:

* получатели и назначение выходной информации;

* перечень и описание выходных сообщений;

* периодичность их выдачи;

* допустимое время задержки решения.

 - описание и оценка преимуществ и недостатков разработанных альтернативных вариантов функций в концепции создания ПС;

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

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

- общее описание постановки выбранных задач и функций нового ПС;

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

- ожидаемые результаты и возможная эффективность реализации выбранного варианта концепции ПС;

- ориентировочный план реализации выбранного варианта концепции ПС;

- требования к составу и содержанию документации проекта ПС;

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

- предварительный состав требований, гарантирующих качество ПС;

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

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

- общее назначение и сфера действия плана;

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

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

* наименование работы;

* контролируемые характеристики объекта разработки;

* контролируемые показатели процесса выполнения плана;

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

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

* дата начала и окончания работы;

* наименование специалистов и подразделений - участников работы;

* фамилия и должность ответственного исполнителя этапа работ;

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

Системный проект, общее описание программного средства и среды разработки для согласования между заказчиком и разработчиком:

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

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

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

- функции частей программного средства – назначение и описание основных проблем и функций для каждой части и компонента ПС;

- содержание решаемой проблемы:

* соглашение с заказчиком по определению проблемы;

* заинтересованные лица и пользователи;

* границы системы решений;

* ограничения, которые необходимо наложить на решения;

- содержание потребностей заказчика и пользователей:

* структурированное интервью, используя 10 – 15 наиболее часто упоминавшихся потребностей и функций пользователей;

* сформулированные описания потребностей для начала создания комплекса требований;

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

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

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

* важное ПС – для которого проявление дефекта или возникновение от- казовой ситуации может существенно снизить качество выпускаемой продукции и заметно увеличить риск и цену грубых ошибок при обработке информации;

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

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

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

* атрибуты приоритетов функций (критический, важный, полезный), риска (высокий, низкий, средний);

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

- управление и согласование масштаба проекта и контроль изменений:

* соглашение с заказчиком относительно масштаба проекта и решений по изменению масштаба;

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

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

- построение корректной системы и комплекса программ:

* анализ и оценка рисков, чтобы определить, план действий по верификации и проверке корректности требований, основываясь на результатах этих оценок;

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

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

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

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

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

Техническое задание на предварительное (детальное ) проектирование программного средства:

- общие сведения:

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

* полное наименование проекта ПС;

* назначение и цель разработки (развития) ПС;

* основание для выполнения и финансирования проекта ПС;

* организация - заказчик проекта;

* организация - головной исполнитель и соисполнители проекта;

* общие сроки выполнения проекта;

- общие технические требования, стандарты и базовые нормативные документы для выполнения проекта ПС;

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

* общие требования к системе и внешней среде;

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

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

* требования к функциям и основным задачам проекта ПС;

* требования к внешней среде проекта ПС;

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

- детальные спецификации требований к функциям, компонентам и эксплуатационным характеристикам ПС:

* требования к структуре и функционированию ПС;

* требования к надежности и безопасности применения;

* требования к защите информации;

* требования к стандартизации и унификации;

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

- специальные требования к аппаратной и операционной платформам для реализации ПС;

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

- требования к составу и содержанию работ по внедрению ПС в эксплатацию;

- этапы, сроки и график выполнения основных работ;

- ожидаемые результаты применения ПС и форма их представления;

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

- предложения по применению и развитию проекта ПС.

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

Стандарты, и ограничения на процессы проектирования программного средства:

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

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

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

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

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

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

-                   возможности использование динамических задач;

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

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

·                    ограничения на проектирование структуры программ — запрещение использования рекурсий, динамических объектов, альтернативных имен, сокращенных выражений;

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

Спецификация требований к системе и к комплексу программ:

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

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

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

·                    спецификация требований верхнего уровня, производные требования к компонентам ПС и требования к интерфейсам между системными компонентами, элементами конфигурации ПС и аппаратуры;

·                    описание распределения системных требований по компонентам ПС с учетом требований, которые обеспечивают характеристики качества;

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

·                    требования концепции совместного целостного функционирования компонентов ПС, описание их динамических связей;

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

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

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

-                   к режимам работы;

-                   производительности системы;

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

-                   к внутреннему интерфейсу системы;

-                   к внутренним данным системы;

-                   по возможности адаптации к внешней среде;

-                   по обеспечению безопасности системы и внешней среды;

-                   по обеспечению защиты и секретности данных;

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

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

-                   по обучению и уровню квалификации персонала;

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

Предварительное описание и контроль согласованности требований компонентов проекта программного средства:

·                    описание архитектуры и контроль согласованности требований компонентов нижнего уровня ПС, которые должны удовлетворять требованиям верхнего уровня к комплексу программ;

·                    детализированное описание того, как компоненты ПС удовлетво5IСТ специфицированным требованиям верхнего уровня к ПС, включая алгоритмы, структуры данных, и описание распределения требований по процессорам и задачам для реализации;

·                    описание архитектуры комплекса программ в составе системы, которая определяет структуру компонентов ПС, предназначенного для реализации заданных требований на систему;

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

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

·                    ограничения на использование ресурсов, стратегия для управления каждым ресурсом, границы рабочего диапазона и методы измерения времени выполнения и использования памяти при функционировании ПС;

·                    обоснование тех решений проекта, которые относятся к перечисленным требованиям, связанным с применением системы и ПС.

Описание функционирования программного средства, взаимодействия с объектами внешней среды и человеко-машинного диалога:

·                    исходные данные:

-                   перечень исходных материалов и документов, использованных при разработке функциональной части проекта ПС;

-                   особенности системы, влияющие на проектные решения и компоненты ПС по автоматизированным функциям;

-                   данные о системах, взаимосвязанных с разрабатываемым ПС;

-                   сведения об информации, которой ПС должно обмениваться с абонентами и другими системами;

-                   описание информационной модели системы;

·                    цели комплекса программ и автоматизируемые функции;

·                    характеристика функциональной структуры:

-                   перечень компонентов ПС с указанием функций и задач, реализуемых в каждом компоненте;

-                   описание процессов выполнения функций;

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

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

·                    типовые решения с указанием функций и задач, для выполнения которых они применены;

·                    функциональная пригодность:

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

-                   соответствие назначения целям применения ПС;

-                   соответствие требований к заданным функциям назначению ПС;

-                   соответствие исходной информации требованиям к функциям ПС;

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

Описание алгоритмов компонентов (модулей) программного средства:

·                    назначение и характеристики компонента (модуля) ПС:

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

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

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

-       ограничения на возможность и условия применения алгоритма;

-       требуемые характеристики качества решения;

-       состав и общие требования к входным и выходным данным;

·                    используемая информация и ее характеристики:

-       массивы информации, сформированные из входных сообщений системы;

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

·                    результаты решения:

-       перечень и содержание массивов информации, формируемых в результате реализации алгоритма;

·                    математическое описание:

-       математическая модель или экономико-математическое описание процесса (объекта);

-       перечень принятых допущений и оценки степени соответствия

-       принятой модели реальному процессу (объекту);

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

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

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

-       формирования результатов решения;

-       последовательности этапов счета, расчетные и логические

-       формулы, используемые в алгоритме;

·                    требования к разработке программы для реализации алгоритма:

-       диагностические сообщения при работе с программой;

-       требования к контролю данных в процессе выполнения операций алгоритма;

-       ограничения, связанные с машинной реализацией программы

-       алгоритма;

-       требования к контрольной задаче алгоритма.

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

·                    состав информационного обеспечения комплекса программ;

·                    наименования и назначения всех баз и наборов данных;

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

·                    интерфейсы базы данных с другими системами, элементами конфигурации ПС и аппаратуры;

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

·                    алгоритмы работы с базами данных и возможные ограничения;

·                    организация интерфейсов и информационного обеспечения программного средства:

-       принципы организации информационного обеспечения системы ПС;

-       обоснование выбора носителей данных и принципы распределения информации по типам носителей;

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

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

·                    организация сбора и передачи информации:

-       перечень источников и носителей информации;

-       оценки интенсивности и объема потоков информации;

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

·                    система классификации и кодирования информации в комплексе программ:

-       описание классификации объектов в действующих классификаторах;

-       методы кодирования объектов во вновь разработанных классификаторах;

·                    организация информации баз данных:

-       характеристики состава и объема баз данных;

-       описание структуры баз данных;

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

·                    организация ведения и изменения каждой информационной базы:

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

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

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

Требования к характеристикам качества проекта программного средства:

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

-       соответствие требований к функциям ПС требованиям к системе;

-       соответствие требований к функциональным компонентам ПС требованиям к функциям комплекса программ;

-       соответствие текстов программ требованиям к функциональным компонентам ПС;

-       соответствие объектного кода исходному тексту программ функциональных компонентов ПС;

-       степень покрытия тестами возможных маршрутов исполнения программ;

·                    требования к способности и качеству взаимодействия компонентов системы и ПС:

-       с операционной системой;

-       с аппаратной средой;

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

-       между программными компонентами;

-       между компонентами распределенных информационных систем;

·                    требования к защищенности — безопасности ПС:

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

-       соответствие критериям и требованиям защиты от предумышленных несанкционированных угроз безопасности ПС;

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

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

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

·                    требования к характеристикам надежности функционирования ИС:

-       к завершенности — наработке на отказ при отсутствии рестарта;

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

-       к восстанавливаемости — допустимой длительности восстановления;

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

·                    требования к эффективности функционирования ПС:

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

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

-       к используемости ресурсов: относительная величина использования ресурсов ЭВМ при нормальном функционировании программного средства;

·                    требования к практичности применения ПС:

-       к понятности: четкость концепции ПС; демонстрационные возможности; наглядность и полнота документации;

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

-       к изучаемости: трудоемкость изучения применения ПС; продолжительность изучения; объем эксплуатационной документации; объем электронных учебников;

·                    требования к сопровождаемости ПС:

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

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

-       к тестируемости: трудоемкость тестирования изменений; длительность тестирования изменений;

·                    требования к мобильности ПС:

-       к адаптируемости: трудоемкость адаптации; длительность адаптации;

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

-       к замещаемости: трудоемкость замены компонентов; длительность замены компонентов.

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

·                    общие положения:

-       наименование проектируемой системы и наименования документов, их номера и дату утверждения, на основании которых ведется проектирование ПС;

-       цели, назначение и области использования ПС;

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

-       ПС;

-       сроки выполнения основных этапов и проекта ПС в целом;

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

-       сведения о НИР и изобретениях, использованных при разработке проекта;

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

·                    описание процесса функционирования и применения ПС:

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

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

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

-       функционирования системы;

·                    основные технические решения:

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

-       условия связи ПС с взаимодействующими системами, обеспечение их совместимости;

-       функции комплексов задач, реализуемых ПС и компонентами;

-       состав обрабатываемой информации, размер и способы ее организации;

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

-       компонентов;

-       ВИДЫ машинных носителей, входные и выходные документы и сообщения, последовательность обработки информации;

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

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

-       сведения о реализации заданных в спецификациях требований к потребительским характеристикам ПС и компонентов, определяющих их качество и безопасность применения;

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

·                    описание логической и физической структуры баз данных проектирования компонентов и ПС в целом:

-       состав, форматы и содержание данных версий компонентов и процессов проекта ПС;

-       взаимосвязи между компонентами и версиями проекта ПС и данными;

-       описание принятого варианта расположения компонентов проекта ПС и данных на конкретных машинных носителях;

·                    мероприятия по подготовке системы и ПС к вводу в действие и к эксплуатации:

-       мероприятия по адаптации и приведению внешней, исходной информации к виду, пригодному для обработки ПС;

-       мероприятия по обучению и проверке квалификации обслуживающего персонала и пользователей;

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

Описание концепции технологии автоматизированного проектирования программного средства:

·                    общие положения:

-       класс процессов и этапов жизненного цикла ПС, на которые распространена технология;

-       состав и квалификация специалистов-пользователей технологии;

-       требования и ограничения на условия применения технологии;

·                    постановка задач и цели автоматизации проектирования ПС:

-       основные пути и направления решения задач проектирования

-       ПС;

-       требования к качеству технологии проектирования ПС;

-       ограничения на применение технологии проектирования;

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

·                    методика проектирования ПС:

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

-       ПС;

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

-       порядок взаимодействия проектных процедур в процессе их выполнения в жизненном цикле ПС;

·                    инструментальные средства:

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

-       рекомендуемые функции инструментальных средств;

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

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

-       исходные данные для использования технологии:

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

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

-       критерии оценки качества исходных данных проекта ПС;

·                    описания проектных процедур в жизненном цикле ПС:

-       состав исходных данных;

-       правила доступа к ним;

-       порядок выполнения проектных процедур;

-       состав и форма результирующих сообщений;

·                    оценка качества результатов проектирования:

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

План и поддерживающее его Руководство по документированию проекта жизненного цикла программного средства:

·                    общая структура комплекта документов;

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

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

·                    требования к качеству, оформлению и обозначению исходных и результирующих документов;

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

·                    регламент комплектования и хранения документов;

·                    правила обращения, изменения и сопровождения документов;

·                    план и графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов для каждого этапа жизненного цикла:

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

-       контролируемые и документируемые данные о состоянии компонента и процесса разработки, регистрируемые после завершения этапа проекта;

-       содержание процедур контроля состояния и качества компонентов и проекта ПС в целом и документов в процессе выполнения работ этапов;

-       критерии оценки результатов выполненных работ и качества отчетных документов при завершении этапа и проекта ПС в целом;

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

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

качество конкретных документов;

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

Ведомость предварительного или детального проекта программного средства:

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

·                    оценка соответствия комплекта, содержания и качества документов проекта требованиям спецификаций, технического задания и/или контракта (договора) на проектирование по разделам проекта программного средства.

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

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

·                    описание целей, стандартов и модели жизненного цикла, которые должны быть использованы в процессах разработки компонентов ПС;

·                    идентификация стандартов на разработку компонентов ПС:

-       требований к компоненту ПС;

-       на процесс проектирования компонента ПС;

-       на кодирования компонентов ГТС для данного проекта;

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

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

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

-       методов и средств разработки требований к компонентам ПС;

-       методов и средств проектирования компонентов ПС;

-       языков программирования компонентов ПС;

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

·                    аппаратная поддержка для инструментальных средств программирования компонентов ПС;

·                    план-график разработке компонентов ПС по этапам проекта.

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

·                    методы, которые должны быть использованы для того, чтобы достичь требуемое качество компонента ПС;

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

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

·                    перечень и план-график работ обеспечения качества, которые должны быть выполнены для каждого процесса жизненного цикла компонента ПС и на протяжении всего жизненного цикла, включая:

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

-                   работы, связанные с отчетностью о дефектах, трассируемостью и системой корректирующих действий компонентов ПС;

·                    синхронизация работ процесса обеспечения качества компонентов, относительно работ других процессов жизненного цикла ПС;

·                    определение отчетов, которые будут подготовлены в процессах обеспечения качества компонентов ПС.

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

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

·                    перечень языков программирования и/или какое-либо их под- множество;

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

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

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

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

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

·                    соглашения по наименованию для компонентов, подпрограмм, переменных, констант, версий.

Руководство по программированию компонентов проекта комплекса программ:

·                    описание среды программирования:

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

-                   длина слова, объем памяти и ее характеристики;

-                   перечень команд, прерываний, режимов работы;

-                   рабочие регистры, характеристики ввода/вывода;

-                   описание носителей данных;

·                    информация о возможностях применения языка программирования:

-                   представление данных;

-                   формат команд и методы адресации;

-                   команды передачи управления;

-                   процедуры и подпрограммы;

-                   обработка прерываний;

-                   синхронизация и таймеры;

-                   возможности защиты памяти;

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

-                   программирование управления вводом/выводом.

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

·                    идентификатор, техническое задание и/или спецификация требований на разработку компонента; включая, имя автора и дату создания версии компонента;

·                    текст компонента ИС, написанный на исходном языке программирования, и команды компилятора, генерирующие объектный код из исходного текста, информация для редактирования связей и загрузки, а также текст комментариев;

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

·                    описание программы в виде печатного документа и/или машинных файлов в составе:

-                   краткая аннотация;

-                   описание решаемых задач;

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

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

-                   описание и схема иерархии модулей сложного программного

-                   компонента;

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

-                   описание пользовательских интерфейсов компонента;

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

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

-                   описание способов проверки работоспособности и качества

-                   программного компонента и тестовые задачи;

·                    фрагмент руководства пользователя — описание применения программного компонента (при необходимости);

·                    исходный текст программы на языке программирования в виде печатного документа и/или машинных файлов с комментариями;

·                    исходный текст и исполняемый объектный код программы на машинных носителях.

ДОКУМЕНТИРОВАНИЕ ВСПОМОГАТЕЛЬНЫХ ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Состав базовых документов, регламентирующих верификацию и тестирование программных компонентов:

·                    руководство программистам по применению методологии, средств автоматизации и стандартов программирования при разработке компонентов ПС;

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

·                    план обеспечения процессов верификации и тестирования средствами генерации тестов и обработки результатов функционирования компонентов ПС;

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

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

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

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

·                    образцы текстов компонентов на языке программирования и в объектном коде реализующей ЭВМ после завершения верификации тестирования.

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

·                    требования к функциональности, эффективности и к качеству системы, детализированные в исходных требованиях высокого уровня к ПС, производные требования к компонентам и обоснование их необходимости;

·                    каждое требование высокого уровня к ПС трассировано точными, однозначными и достаточно детализированными требованиями к компонентам, и они не конфликтуют друг с другом;

·                    отсутствуют неоднозначности и конфликты между требованиями к компонентам и к возможностями аппаратных и программных средств объектного вычислителя, особенно такими, как время реакции системы и характеристики аппаратуры ввода/вывода;

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

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

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

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

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

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

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

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

-                   архитектура ПС и спецификации требований к компонентам низкого уровня корректно переработаны, в удовлетворяющие им, исходные тексты программных и информационных модулей;

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

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

·                    формализованы методы, которые будут использованы на каждом этапе процесса верификации ПС:

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

-                   формализованы методы проверки трассируемости и оценки полноты покрытия верификацией компонентов ПС;

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

Исходные данные для тестирования компонентов:

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

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

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

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

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

·                    выбранные методы верификации и тестирования компонентов:

-       статические или динамические;

-       детерминированные или стохастические;

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

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

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

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

·                    доступные ресурсы на тестирование компонента:

-       доступные финансовые, трудовые и временные затраты на тестирование компонента;

-       оснащенность процесса тестирования компонента программными и аппаратными средствами автоматизации;

-       доступный состав и квалификация специалистов;

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

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

Организация, подготовка тестирования а обеспечение качества компонентов:

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

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

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

·                    методы и средства объективного измерения требуемого покрытия тестами и достигнутого качества каждого компонента на фиксированных этапах его разработки;

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

·                    структура и содержание (шаблон) каждого документа отражающего результаты этапа тестирования компонента, качество выполненных работ и полноты покрытия тестами.

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

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

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

·                    спецификация общей схемы сценариев тестирования компонента:

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

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

·                    описания контрольных сценариев тестирования — набор конретных тестовых значений и соответствующих им эталонов:

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

-                   ожидаемые, эталонные выходные значения результатов тестирования;

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

·                    спецификация конкретного сценария тестирования, которая идентифицирует все этапы, требуемые для работы системы в целом или компонента, и для выполнения контрольных сценариев, чтобы реализовать связанные с ними тесты;

·                    задание на верификацию и тестирование с указанием контролируемых параметров, исходных данных и результирующих эталонов;

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

·                    сравнения результатов тестирования с эталонами и обнаруженные отклонения (дефектов или ошибок) для проведения дополнительного тестирования с целью диагностики и локализации дефектов;

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

·                    оценка характеристик качества компонента, исходных и выходных данных в спецификациях и сценариях;

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

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

План тестирования программного компонента:

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

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

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

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

·                    организация работ, основной график их выполнения:

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

-                   методы и критерии оценки качества тестирования;

-                   входные и результирующие данные тестирования;

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

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

·                    номенклатура и содержание оформляемых отчетных документов;

·                    взаимодействие плана тестирования компонентов с планами обеспечения качества и с управлением конфигурацией и корректировками компонентов и ПС в целом;

·                    детализация и документирование процесса тестирования на каждом этапе ЖЦПС:

-                   графики решения частных задач тестирования компонентов;

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

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

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

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

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

-                   сценариев и операций, которые имели место во время выполнения тестирования компонента;

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

-                   изменений и корректировок, которые произведены в компонентах;

·                    результаты верификации и тестирования:

-                   результат выполнения (прошел/не прошел) для каждого про- смотра, анализа и выполненного теста и заключительный результат верификации и тестирования компонента;

-                   элемент конфигурации и/или версия ПС, которые прошли просмотр, анализ или верификацию соответствующих компонентов;

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

·                    итоговый обобщенный отчет верификации и тестирования компонентов ПС:

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

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

-       компоненты комплекса программ выполняют все (частично) декларируемые в документации функции;

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

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

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

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

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

·                    комплексирование в статике модулей и компонентов, входящих и функциональный компонент, проверка интерфейсов между модулями и выявлены их нестыковки с описаниями в спецификациях на функциональный компонент;

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

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

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

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

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

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

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

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

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

-                   для каждой из функций компонента существует непустое множество маршрутов ее реализации;

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

-                   не обнаружено нереализованных и тупиковых функциональных маршрутов;

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

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

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

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

·                    завершение тестирования функционального компонента с другими группами программ, наращивание состава компонентов до полного комплекта реализуемых функциональных задач в ПС;

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

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

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

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

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

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

·                    определение корректности использования ресурсов памяти и производительности вычислительной системы при оценке качества и безопасности исполнения функциональных компонентов при ограниченности ресурсов ЭВМ;

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

·                    оценки эффективности защиты от сбоев аппаратуры и не выявленных ошибок программ и данных для проверки качества средств контроля и оперативного восстановления (рестарта) при различных, непреднамеренных искажениях функционирования компонентов ПС;

·                    измерение достигнутых значений надежности и безопасности базовых версий функциональных компонентов ПС и определение основных характеристик качества комплекса программ;

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

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

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

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

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

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

Методика генерации тестов имитирующих внешнюю среду и обработку результатов квалификационного тестирования:

·                    выбор и установление статуса испытания ПС и соответствующих тестов:

-                   ординарные испытания, которым подвергается широкий спектр ПС с относительно невысокими требованиями к качеству, которые предстоит эксплуатировать в не критических системах;

-                   аттестационные испытания, которым подвергаются ответственные категории ПС, чьи ошибки могут нанести большой ущерб;

-                   сертификационные испытания критических ПС, эксплуатация которых недопустима без высоких гарантий качества, удостоверяемых уполномоченным государственным или ведомственным органом;

·                    имитация конкретных тестов с реальными характеристиками, адекватными объектам внешней среды, с учетом:

-                   статуса испытаний;

-                   глубины знаний об алгоритмах функционирования объектов внешней среды;

-                   характеристик компонентов внешней среды;

-                   выбор средств имитации внешней среды, обеспечивающих реальный масштаб времени при тестировании и включающих:

-                   аналоги объектов внешней среды для генерации тестов, представляющих коррелированные логические переменные, которые трудно описать и смоделировать на ЭВМ;

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

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

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

·                    математическое моделирование внешней среды — поддержка процесса тестирования с помощью имитации данных из внешних для ПС компонентов системы, что позволяет:

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

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

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

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

·                    регистрация характеристик тестовых данных на соответствие заданным обобщенным характеристикам каждого объекта внешней еды и исходным данным сеанса испытаний:

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

-                   выходные эталонные результаты тестирования;

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

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

-                   характеристики превышения допустимого использования различных ресурсов объектной ЭВМ;

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

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

Методика применения проблемно-ориентированной системы квалификационного тестирования и испытаний комплексов программ:

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

·                    выявления причин сбоев и отказов функционирования компонентов и ПС в целом;

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

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

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

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

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

·                    анализ и обработка тестовых результатов — использование возможности средства тестирования автоматически анализировать тестовые результаты: сравнение ожидаемых и реальных результатов; сравнение файлов; статистическую обработку результатов;

·                    анализ покрытия тестами объектного кода комплекса программ для обнаружения: операторов, которые не были выполнены; процедур, которые не были вызваны; переменных, к которым не были обращения;

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

Методика, содержание и сценарии квалификационного тестирования и испытаний программных средств:

·                    содержание тестовых сценариев и процедур, которые используют для выполнения квалификационного тестирования системы или функциональных компонентов ПС:

-       каждый тест должен иметь уникальный для проекта идентификатор и ссылку на соответствующий пункт в документе Программа квалификационного тестирования;

-       инструкции для проведения тестирования, описание аппаратуры и ПС, а также инструкции для возможности повторного тестирования;

-       ссылки на проверяемые требования спецификаций, условия выполнения (конфигурация аппаратуры и ПС), входные данные, ожидаемые результаты, критерии оценки результатов, процедуры тестирования для каждого тестового сценария, допущения и ограничения испытаний;

·                    план квалификационного тестирования комплекса программ:

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

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

-       организации, принимающие участие в квалификационном тестировании ПС, их роли и ответственность;

-       план-график тестирования и матрица трассирования квалификационных тестов с отношением к конкретным требованиям спецификаций компонентов и ПС.

·                    квалификационное тестирование программного средства вне системы:

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

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

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

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

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

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

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

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

-       установление соответствия достигнутых характеристик качества ПС и системы требованиям контракта и спецификаций;

-       удостоверение адекватности и качества технологической и

-       эксплуатационной документации на систему и ИС результатам квалификационного тестирования;

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

·                    опытная эксплуатация системы и комплекса программ разработчиками с участием испытателей и некоторых пользователей, назначаемых заказчиком (результаты могут учитываться при проведении совместных испытаний для их сокращения);

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

·                    исходные документы комиссии при испытаниях:

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

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

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

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

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

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

·                    отчет о квалификационном тестировании (испытаниях) ПС, выполненном для системы и комплекса программ:

-       общая оценка результатов квалификационного тестирования, идентификация всех дефектов, несоответствий и ограничений;

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

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

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

-       описание обнаруженных и устраненных дефектов;

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

Программа испытаний комплекса программ:

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

·                    объект испытаний (компонент или комплекс программ), его назначение и перечень основных документов, определивших его разработку;

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

·                    ограничения на проведение испытаний (экономические, технологические, временные, ресурсы специалистов);

·                    этапы жизненного цикла, на которых должно проводиться тестирование компонентов или ПС в целом;

·                    собственно Программа испытаний комплекса программ:

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

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

-                   сценарии проверок ПС соответствия техническому заданию и оценки степени выполнения требований функционального назначения системы и комплекса программ;

-                   оценка комплектности, достаточности состава и качества документации на комплекс программ;

-                   определение потребности в количестве и квалификации пользователей и обслуживающего персонала;

·                    основы методик испытаний, однозначно определяющие:

-                   содержание проверяемых характеристик;

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

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

-                   испытаний;

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

Методики проведения испытаний комплекса программ по отдельным характеристикам качества:

·                    объект испытаний — полное наименование комплекса программ, обозначение и комплектность испытываемого функционального компонента или ПС в целом;

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

·                    общие положения методов испытаний:

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

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

-                   идентификаторы организаций, участвующих в испытаниях;

-                   перечень математических и комплексных моделей, применяемых для имитации внешней среды и оценки характеристик ПС;

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

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

·                    размеры испытаний по разделам Программы:

-                   перечень этапов тестирования, испытаний и оценок;

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

-                   последовательность проведения этапов тестирования и режимы испытаний;

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

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

·                    условия и порядок проведения испытаний:

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

-                   имеющиеся ограничения в условиях проведения этапов испытаний;

-                   требования к техническому обслуживанию системы в процессе испытаний;

-                   необходимые меры, обеспечивающие безопасность и безаварийность проведения испытаний системы и ПС;

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

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

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

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

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

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

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

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

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

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

·                    акт содержания технического состояния ПС и системы после испытаний.

Протоколы по результатам испытаний функциональных компонентов и/или комплекса программ:

·                    идентификатор объекта испытаний;

·                    цель испытаний;

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

·                    список должностных лиц и их квалификации, проводивших испытания;

·                    перечень пунктов Программы испытаний, по которым успешно

·                    проведены испытания;

·                    перечень методик, в соответствие с которыми успешно проведены испытания, обработка и оценка результатов;

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

·                    отчет об отказах, сбоях и аварийных ситуациях, выявленных при испытаниях;

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

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

·                    протоколы просмотров и аудитов, протоколы совещаний, регистрация отклонений от санкционированных процессов и протоколы проверки соответствия комплекса программ требованиям спецификаций;

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

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

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

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

·                    функции ПС с акцентированием на обеспечение характеристик качества, безопасности и используемую концепцию разбиения компонентов ПС;

·                    основные характеристики ПС - размер исполняемого объектного кода, ограничения по времени и памяти, ограничения ресурсов разработки, значения и способы измерения каждой характеристики;

·                    связь между представляемыми документами комплекса программ и документами, определяющими систему, а также способы передачи комплекса документов жизненного цикла ПС заказчику;

·                    идентификация конфигурации ПС, посредством указания регистрационного номера и версии;

·                    обзор изменений и корректировок в ЖЦ ПС с указанием изменений, вызванных отказами, влияющими на качество и безопасность, с идентификацией изменений, выполненных после сдачи предыдущей версии;

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

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

Акт завершения работ по проекту программного средства (п. 3.5.7):

·                    идентификатор проекта и завершенной работы;

·                    список представителей организации-разработчика и организации заказчика, составивших акт;

·                    дата завершения проекта и работ;

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

·                    осуществлен проект и проводилась работа:

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

·                    результаты выполненного проекта ПС;

·                    основные результаты завершенного проекта ПС;

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

·                    рекомендации по развитию и внедрению результатов проекта ПС;

·                    приложения:

-                   комплект технологической и эксплуатационной документации на комплекс программ;

-                   исходные документы на разработку проекта ПС;

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

Акт приемки программного средства в промышленную эксплуатацию:

·                    идентификатор системы и/или ПС, принимаемых в эксплуатацию;

·                    сведения о статусе приемочной комиссии (государственная, межведомственная, ведомственная), ее составе и основании для работы;

·                    период времени работы комиссии приемки в эксплуатацию;

·                    идентификаторы организации-разработчика, организации-соисполнителя и организации заказчика;

·                    перечень и наименования исходных документов, на основании которых разработано ПС;

·                    состав и описание функций ПС, принимаемых в эксплуатацию;

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

·                    информационного и организационного обеспечения, принимаемых в эксплуатацию;

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

·                    заключение о результатах опытной эксплуатации ПС;

·                    оценка соответствия принимаемого ПС техническому заданию,

·                    спецификации требований и контракт на его создание;

·                    краткая характеристика и основные результаты выполненной работы по созданию ПС;

-                   оценка научно-технического уровня комплекса программ;

-                   оценка экономической эффективности от возможного внедрения комплекса программ;

·                    решение комиссии о возможности принятия ПС в промышленную эксплуатацию;

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

·                    приложения:

-                   Программа и протоколы испытаний;

-                   протоколы заседаний комиссии;

-                   перечень технических средств и характеристик внешней среды, которые использовала комиссия при испытаниях и приемке ПС;

-                   справка о применении в ПС нормативных документов и унифицированных форм (шаблонов) документов.

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

Описание среды жизненного цикла и конфигурации программного средства:

·                    аппаратная и программная среда разработки, генерации, повтор­ной верификации или модификации ПС на протяжении всего жиз­ненного цикла;

·                    инструментальные средства разработки ПС: компиляторы, редак­торы связей и загрузчики, средства обеспечения целостности дан­ных;

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

·                    аттестованные инструментальные средства обеспечения и кор­ректировки жизненного цикла ПС и соответствующая документация об аттестации этих средств;

·                    идентификаторы конфигурации функциональных компонентов и программного средства; исходные тексты программ и исполняемый объектный код;

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

·                    комплекс технологических документов обеспечения жизненного цикла ПС;

·                    инструкции для компоновки исполняемого объектного кода,  ин­струкции для компилирования и редактирования связей; процедуры, используемые для восстановления при регенерации, тестировании
или модификации компонентов и ПС;

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

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

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

·                    описание процессов управления  конфигурацией в жизненном цикле ПС, которые обеспечивают реализацию целей данного про­цесса; компоненты  изменения конфигурации,  которые должны быть
идентифицированы, методы идентификации документов жизненного цикла ПС, связь идентификации компонентов, ПС и системы;

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

·                    контроль изменений и базовая версия, обеспечивающие целост­ность компонентов конфигурации и базовой версии ПС;

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

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

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

·                    контроль среды жизненного цикла, инструментальных средств для разработки, комплексирования, верификации, тестирования и загрузки ПС;

·                    контроль целостности технологических документов жизненного цикла ПС;

·                    определение состава документов жизненного цикла ПС, генери­руемых в  процессе управления конфигурацией,  включая  отчеты управления конфигурацией компонентов, указатели состояния кон­
фигурации и среды жизненного цикла ПС.

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

·                    рекомендации пользователям по выявлению и регистрации ус­ловий проявления и содержания дефектов эксплуатируемых версий ПС;

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

·                    идентификатор пользователя, представившего отчет о дефектах
и/или предложениях;

·                    дата фиксирования дефекта или предложения на изменение ПС;

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

·                    идентификация компонента конфигурации и/или этапа жизнен­ного цикла ПС, где был обнаружен дефект;

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

·                    предположение о причине, вызвавшей проявление дефекта;

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

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

·                    предложение по модификации ПС и его компонентов для устра­нения   дефекта  или   совершенствования   функционирования   про­грамм.

Описания выявленных дефектов и предложений по совершенствованию функций версии программного средства:

·                    отчеты пользователей о дефектах и предложениях в рубрикации
раздела 6.3;

·                    идентификатор   разработчика,   которому   передан   отчет   поль­зователя для анализа дефекта или предложения;

·                    дата начала анализа отчета пользователя;

·                    идентификатор сценария проявления повторяемости дефекта на
пользовательской версии и необходимости дальнейшего анализа де­фекта на базовой версии ПС;

·                    тесты, исходные данные и сценарий, при которых проявляется
выявленный дефект;

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

·                    оценки сложности, трудоемкости, эффективности и срочности
модификации программ и базы данных;

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

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

·                    идентификатор специалиста, который разработал модификацию
компонентов программ и базы данных;

·                    дата разработки предлагаемой модификации;

·                    причина изменения программ и/или базы данных (дефект, совер­шенствование);

·                    содержание изменений программ и базы данных;

·                    содержание изменений документации на компоненты или версию ПС;

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

·                    дата и ответственное лицо, утвердившее реализацию модифика­ции версии ПС;

·                    квалификация   решения   на   изменение:   частная   модификация
вследствие исправления дефекта или издание новой версии ПС;

·                    результаты испытаний модификации и обобщенные характери­стики базовой версии ПС после внесения изменений;

·                    решение по распространению пользователям результатов прове­денной модификации или новой версии ПС;

·                    решение по целесообразности сохранения сопровождения пред­шествующих версий ПС;

·                    адрес хранения корректировок, документов и квалификационных
тестов выполненной модификации и/или новой базовой версии ПС;

·                    идентификация новой конфигурации, протоколы об установле­нии новой базовой версии и её регистрации в архиве;

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

·                    отчеты об истории выполнения изменений версий ПС;

·                    протоколы о передаче новой версии ПС в архив;

·                    протоколы о выпуске новой версии ПС для применения пользо­вателями.

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

·                    краткое обоснование причин модификации или прекращения сопровождения версии ПС;

·                    описание содержания и характеристики основных изменений в
новой версии ПС;

·                    рекомендации по корректировке, приобретению или замене поль­зовательской версии ПС.

Описание новой базовой версии программного средства:

·                    идентификация системы и комплекса программ, к которым применяется данный документ, включая регистрационные номера про­цедур утверждения конфигураций и номера базовых версий ПС;

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

·                    идентификация физических носителей, содержащих новую заре­гистрированную и утвержденную базовую версию ПС и связанную с
ней документацию;

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

·                    перечень всех изменений, внесенных в файлы и документы после
выпуска предыдущей базовой версии ПС;

·                    полный комплект документов новой базовой версии ПС;

·                    инструкция по установке и инсталляции новой версии ПС.

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

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

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

·                    запланированные сроки установки новой версии ПС у опреде­ленных пользователей;

·                    комплект системы файлов и документов, относящихся к передаваемой новой базовой версии ПС;

·                    детальное описание ресурсов, необходимых для инсталляции передаваемого ПС, требования к квалификации и составу персонала,
чтобы специфицировать,  разработать, документировать, тестиро­вать, оценивать, контролировать, копировать и распространять но­вую базовую версию ПС;

·                    перечень рекомендуемых мероприятий, в том числе консульта­ции и лекции, которые должен проводить разработчик в целях под­держки применения передаваемого нового ПС;

·                    описание процесса подготовки персонала, который будет осуществлять поддержку передаваемого ПС: тематика,   дата, продолжительность и место проведения теоретических и практических занятий;

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

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

·                    причины и дата решения о прекращении сопровождения опреде­ленной базовой версии ПС и извещение пользователей;

·                    идентификатор ответственного лица, принявшего решение о прекращении сопровождения определенной версии ПС;

·                    дата и идентификатор лица, выполнившего архивацию опреде­ленной версии ПС;

·                    идентификаторы физических носителей информации архива, со­держащих подлинники и дубликаты файлов и документов, снятой с
сопровождения базовой версии ПС.

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

·                    идентификаторы базовых версий ПС, поддерживаемых сопро­вождением и распространяемых пользователям;

·                    адреса архивов, содержащих физические носители файлов и до­кументации каждой базовой версии ПС распространяемой пользова­телям;

·                    краткая характеристика и адреса архивов, содержащих квали­фикационные тесты базовых версий ПС;

·                    перечень идентификаторов пользователей, которым передана на
эксплуатацию определенная базовая версия ПС;

·                    идентификатор базовой версии, которая адаптировалась для экс­плуатации каждым пользователем;

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

·                    характеристики активности обращений пользователей к постав­щику за консультациями и модификациями комплекса программ.

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

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

·                    назначение и идентификатор системы:

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

−                    перечень объектов автоматизации и внешней среды, на которых используется система и ПС;

·                     описание системы:

−                    структура системы и назначение ее частей;

−                    сведения о программном продукте в целом и его частях, необходимые для корректной эксплуатации системы;

−                    описание функционирования системы и ее частей;

·                 описание взаимосвязей программного продукта с другими системами и ПС:

−                    перечень компонентов систем и ПС, с которыми связано данный программный продукт; *описание регламента связей между системами и ПС;

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

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

·                 режимы работы программного продукта;

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

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

·                 форматы представления входной и выходной информации, их назначение, тип, объем;

·                 точность представления, скорость передачи, ожидаемое время реакции на операции пользователя;

·                 способ задания конца обработанной информации и другие требуемые соглашения;

·                 ограничения и наиболее типичные ошибки задания информации;

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

Общие требования к формированию Пользовательской
документации программных средств по стандарту ISO 15910:1999 (ГОСТР-2002).

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

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

·                 документы, детализирующие концепцию процессов управления системой и ПС и требования к реализации каждой функции;

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

·                 руководства для формализации и описания объектов управления системы и ПС;

·                 формализация непосредственной передачи управляющей информации между компонентами системы и ПС;

·                 документы, описывающие:

−   передаваемые типы данных;

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

·                 классификатор объектов управления, отражающий взаимосвязь между классами объектов управления и правилами их применения;

·                 функции администратора программных средств:

−      общие функции администрирования при применении данного ПС;

−      процедуры по инсталляции и подготовке ПС к эксплуатации;

−      контроль ввода заданий и выработки запроса на их выполне­ние;

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

−      способы и формы контроля исполнения заданий;

−      динамическое управление процессом реализации заданий.

Руководство системного администратора программного средства:

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

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

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

·                 структура, обзор назначения и функционирования каждого компонента комплекса программ;

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

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

·                 типовые времена выполнения основных функций ПС;

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

·                 перечень требуемых библиотек поддержки и интерфейсов системы;

·                 форма и средства регистрации дефектов и ошибок, возникающих
в процессе эксплуатации ПС;

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

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

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

·                    краткое описание функций и характеристик ПС;

·                    описание внешней программной среды;

·                    перечень файлов, включая файлы базы данных, необходимых для применения ПС;

·                    порядок действий для продолжения или возобновления функционирования ПС в случаях возникновения непредвиденных ситуаций;

·                    организация и функционирование ПС с точки зрения пользователя;

·                    описание процедур, позволяющих фиксировать дефекты и ошибки;

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

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

·                    перечень и пояснение выводимых системой сообщений.

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

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

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

·                    введение:

−   область применения ПС;

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

−   требования к уровню подготовки пользователя;

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

·                                 назначение и условия применения комплекса программ:

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

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

−   условия, при соблюдении (выполнении, наступлении), которых обеспечивается применение программного средства в соответствии с назначением, спецификациями требований и ха­рактеристиками системы;

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

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

−   метод решения каждой задачи, их взаимодействие и ограничения;

·                     подготовка к работе:

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

−   описание всех выполняемых функций, задач, процедур;

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

−   порядок загрузки данных и программ;

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

·                     описание функциональных операций ПС для каждой операции
обработки данных должно быть указано:

−   идентификатор и наименование операции;

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

−   подготовительные действия;

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

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

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

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

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

−   заключительные действия для завершения требуемой задачи;

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

·                     аварийные ситуации:

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

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

−   действия в случаях обнаружения несанкционированного вмешательства в данные;

·                        гарантии и обязательства по контракту на комплекс программ, а также условия отказа от них;

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

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

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

·                        правила подготовки информации данных:

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

−   правила подготовки и кодирования информации базы данных;

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

−   порядок внесения изменений в информацию базы данных;

·                                                                                                                                                                                     порядок и средства заполнения базы данных:

−   состав технических средств;

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

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

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

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

−   описание средств защиты базы от разрушения и несанкционированного доступа;

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

Паспорт на программное средство:

·   общие сведения о программном средстве:

−   идентификатор и наименование ПС;

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

−   наименование предприятия-поставщика;

·   основные характеристики ПС:

−   состав функций, реализуемых ПС;

−   описание принципов функционирования ПС;

−   общий регламент и режимы функционирования ПС;

−   сведения о возможности выбора и изменения режимов его работы;

−   сведения о совместимости ПС с другими системами и внешней средой;

·   комплектность:

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

−   все непосредственно входящие в состав ПС компоненты;

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

·   свидетельство (акт) о приемке:

−   содержание и дата подписания акта о приемке ПС в промышленную эксплуатацию;

−   фамилии и должности лиц, подписавших акт о приемке;

·   гарантийные обязательства изготовителя (поставщика):

−   сроки и ограничения гарантии на комплекс программ в целом;

−   сроки и ограничения гарантии отдельных составных частей, если они не совпадают с условиями гарантии ПС в целом;

·   сведения о текущем состоянии комплекса программ:

−   сведения о выявленных дефектах;

−   замечания по эксплуатации и аварийным ситуациям, принятые меры;

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

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

Пользовательская документация на коммерческие пакеты и закрытые коробки программных средств по стандарту ISO 9127:

·   документация внутри коробки:

−   цель и назначение ПС;

−   справочная документация;

−   идентификация пакета ПС;

−   составные части пакета ПС;

−   функциональное описание ПС;

−   инсталляция (сборка) ПС;

−   использование ПС;

−   технологическая информация по ПС;

−   тестирование при применении;

−   информация по контрактам;

−   глоссарий;

−   индекс;

−   замечания для конечного пользователя;

·   обучающая документация;

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

·   документация на внешней упаковке пакета:

−   цель ПС;

−   содержание пакета:

−   идентификация пакета;

−   цель и область применения;

−   окружение;

−   вход; выход;

−   ограничения на данные в файлах;

−   инструкция для пользователя;

−   дополнительная информация;

−   информация по контрактам;

−   адреса сервиса для потребителя;

−   предметное обеспечение (спецификация);

−   стандарты и законы;

−   независимая сертификация;

−   код продукта;

·   цена.

Руководство по подготовке документации и обучению специалистов применению программного средства:

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

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

·   документация планов и требований по обучению специалистов;

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

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

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

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

Качество программного продукта определяется по нескольким критериям. Качественный программный продукт должен отвечать функциональным и нефункциональным требованиям, в соответствии с которыми он создавался, иметь ценность для бизнеса, отвечать ожиданиям пользователей [37].

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

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

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

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

Тестирование программного обеспечения

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

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

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

Для разработчика программного обеспечения в VisualStudio 2012 предоставлена возможность создавать модульные и нагрузочные тесты, а также тесты пользовательского интерфейса. В VisualStudio 2012 имеются следующие шаблоны тестовых проектов[38]:

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

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

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

Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг. MTM интегрирован с TeamFoundationServer. С помощью Microsoft TestManager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft TestManager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения. При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены.

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

Рефакторинг

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

Для улучшения качества кода программных приложений применяют рефакторинг [39, 40]. По определению Фаулера М. рефакторинг определяется как "процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается". Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода.

Некачественный дизайн кода определяется по ряду признаков [39]:

·                 жесткость - характеристика программы, затрудняющая внесение изменений в код;

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

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

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

·                 ненужные повторения, которые состоят в повторяющихся фрагментах кода в программе;

·                 непрозрачность, которая характеризует трудность кода для понимания.

Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО[41, 42].

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

Принцип открытости/закрытости определяет, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.

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

Принцип инверсии зависимостей определяет два положения:

·                 модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций;

·                 абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

Паттерны проектирования предлагают универсальные, проверенные практикой решения. В [40] приведен обширный перечень паттернов. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда, Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/шлюз, Заместитель и Шлюз, Посетитель и Состояние.

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

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

Ключевые термины

Модульное тестирование	тестирование, предназначенное для проверки правильности функционирования методов классов ПО.
Исследовательское тестирование	тестирование, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки.
Интеграционное тестирование	тестирование, предназначенное для проверки корректности совместной работы компонентов программного продукта.
Функциональное тестирование	тестирование, предназначенное для проверки конкретных требований к ПО, которое проводится после добавление к системе новых функций.
Нагрузочное тестирование	тестирование, предназначенное для проверки работоспособности программного продукта при предельной входной нагрузке.
Регрессионное тестирование	тестирование, применяемое при внесении изменений в программное обеспечение, с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом.
Комплексное тестирование	тестирование, предназначенное для проверки соответствия функциональных и нефункциональных требований всей системы программного продукта.
Приемочное тестирование	тестирование, представляющее собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков.
MicrosoftTestManager	инструментарий Microsoft, предназначенный для управления жизненным циклом тестирования программного обеспечения.
LabManagement	диспетчер виртуальной среды тестирования.

Краткие итоги

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

СЕРТИФИКАЦИЯ ПРОГРАММНЫХ СРЕДСТВ

Основные понятия и термины в области сертификации

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

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

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

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

Сертификат соответствия — документ, выданный по правилам системы сертификации для подтверждения соответствия сертифицированной продукции установленным требованиям.

Общие правовые основы сертификации продукции и услуг в Российской Федерации установлены Законом "О сертификации продукции и услуг", где определены права и ответственность в области сертификации органов государственного управления, а также изготовителей (продавцов, исполнителей) и других участников сертификации. В этом Законе, в частности, указано, что сертификация проводится в целях:

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

Ø  содействия потребителям в компетентном выборе продукции;

Ø  защиты потребителя от недобросовестности изготовителя (продавца, исполнителя);

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

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

Сертификация средств и систем информатизации является элементом общей системы сертификации продукции в Российской Федерации.

Основные цели сертификации средств информатизации, информационных технологий и услуг:

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

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

Ø  обеспечение информационного обмена между государственными   системами   информатизации (налоговая служба, правоохранительные органы, службы управления трудом и занятостью, образование, здравоохранение и др.);

Ø  обеспечение условий для информационного взаимодействия субъектов негосударственной принадлежности с субъектами государственной принадлежности;

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

Ø  содействие созданию условий для вхождения России в мировое информационное пространство.

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

Система сертификации — система, располагающая собственными правилами процедуры и управления для проведения сертификации.

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

Испытательная лаборатория — лаборатория (центр), который проводит испытания в процессе сертификации.

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

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

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

Технические условия (ТУ) — документ, устанавливающий технические требования, которым должна удовлетворять продукция, процесс или услуга. ТУ могут быть стандартом, частью стандарта или самостоятельным документом.

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

Организационная структура системы сертификации в России включает:

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

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

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

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

Ведомственные органы сертификации выполняют те же функции в ограниченном объеме для конкретных видов продукции.

 Национальным органом по сертификации продукции в Российской Федерации является Госстандарт России, который осуществляет следующие функции:

Ø  организует ведение обязательной сертификации продукции по поручению органов законодательной или исполнительной власти;

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

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

Ø  проводит аккредитацию испытательных центров (лабораторий) совместно с ведомственными органами по сертификации и выдает аттестат аккредитации;

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

Ø  регистрирует и аннулирует сертификаты соответствия и сертификационные лицензии, рассматривает спорные вопросы, возникающие в процессе сертификации;

Ø  организует периодическую публикацию информации по сертификации.

Основой сертификации продукции в Российской Федерации является Система сертификации ГОСТ Р Госстандарта России. Этой системой, в частности, определяются правила создания и регистрации ведомственных систем сертификации для конкретных классов продукции.

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

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

Во-вторых, собственно процедура сертификации регламентируется действующими нормативными документами (стандартами).

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

Ø  нормативные документы на объекты сертификации, где устанавливаются характеристики объектов, подтверждаемые при сертификации;

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

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

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

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

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

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

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

Общие принципы лицензирования видов деятельности в сфере информатизации России можно сформулировать следующим образом:

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

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

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

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

Сертификация средств информатизации в Российской Федерации

В соответствии с действующими законодательными и нормативными документами сертификация средств информатизации проводится в Российской Федерации в следующих основных направлениях:

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

обязательная сертификация средств защиты информации;

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

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

В соответствии с действующими законодательными и нормативными документами выполнение работ по сертификации средств информатизации в данном направлении возложено на Госстандарт России. В 1994 году Госстандарт России ввел в действие нормативный документ "Номенклатура продукции и услуг, подлежащих обязательной сертификации в Российской Федерации". Этот документ ежегодно пересматривается и уточняется с учетом практики, условий торговли, производства и тенденций научно-технического развития.

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

Ø  вычислительные машины и комплексы;

Ø  персональные ЭВМ;

Ø  устройства внешней памяти, ввода-вывода и отображения информации;

Ø  устройства подготовки и телеобработки данных.

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

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

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

Сертификация средств информатизации по требованиям электромагнитной совместимости и параметрам  безопасности возложена на Госстандарт России и проводится органами  (центрами) сертификации, аккредитованными Госстандартом в рамках Системы сертификации ГОСТ Р.

Вы, вероятно, не раз встречали в рекламных объявлениях по продаже компьютеров фразу "Товар сертифицирован". Иногда в рекламе указывается и регистрационный номер сертификата соответствия, например, "Сертификат соответствия № РОСС RU.ME67.B00373". Речь в этих случаях идет именно о сертификации по требованиям электромагнитной совместимости и параметрам безопасности.

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

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

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

Обязательная сертификация средств защиты информации

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

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

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

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

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

Целями защиты информации упомянутый Закон определяет:

Ø  предотвращение утечки, хищения, утраты, искажения, подделки информации;

Ø  предотвращение угроз безопасности личности, общества, государства;

Ø  предотвращение несанкционированных действий по уничтожению, модификации, искажению, копированию, блокированию информации;

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

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

Ø  сохранение государственной тайны, конфиденциальности документированной информации в соответствии с законодательством;

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

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

Необходимость сертификации средств защиты, применяемых при обработке информации, составляющей государственную тайну, закреплены в Законе Российской Федерации "О государственной тайне". Сертификации подлежат защищенные технические, программно-технические, программные средства, системы, сети вычислительной техники и связи, средства защиты и средства контроля эффективности защиты. Обязательной сертификации подлежат средства, в том числе и иностранного производства, предназначенные для обработки информации с ограниченным доступом, и прежде всего составляющей государственную тайну, а также ис-" пользующиеся в управлении экологически опасными объектами, вооружением и военной техникой и средства их защиты. Наличие у владельца информационной системы сертифицированных средств обработки информации является гарантией надежности ее защиты и дает ему преимущества при осуществлении страхования.

Порядок сертификации средств защиты информации в Российской Федерации и ее учреждениях за рубежом установлен Положением "О сертификации средств защиты информации", утвержденным Постановлением Правительства Российской Федерации от 26 июня 1995 года № 608 (текст этого Положения приводится во второй части книги). Это Положение определяет области деятельности и сферу компетенции различных государственных органов при сертификации средств защиты информации. Основной объем работ по сертификации  средств защиты информации в пределах Российской Федерации возлагается на Гостехкомиссию России и Федеральное агентство правительственной связи и информации (ФАПСИ). Координация работ по организации сертификации этой продукции возложена на Межведомственную комиссию по защите государственной тайны.

Мы думаем, что на роли и общих задачах ФАПСИ здесь нет необходимости останавливаться подробно, поскольку они, в допустимых пределах, достаточно широко освещаются в печати. А вот название такого государственного органа, как Гостехкомиссия России, некоторым из наших читателей, возможно, незнакомо.

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

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

Директивными документами, в частности уже упоминавшимся Положением "О сертификации средств защиты информации", текст которого приводится во второй части книги, установлено, что:

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

В соответствии с установленным распределением сфер деятельности Гостехкомиссии России и ФАПСИ в Российской Федерации созданы и функционируют две системы сертификации средств защиты информации:

"Система сертификации средств защиты информации по требованиям безопасности информации", разработанная Гостехкомиссией России и зарегистрированная Госстандартом за № РОСС RU.OOOI.OIBHOO;

"Система сертификации средств криптографической защиты информации (СКЗИ)", разработанная ФАПСИ и зарегистрированная Госстандартом за № РОСС RU.OOO 1.030001.

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

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

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

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

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

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

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

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

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

ИСПОЛЬЗОВАННАЯ ЛИТЕРАТУРА:

1.      Бахтизин В.В. Технология разработки программного обеспечения: учеб. пособие / В.В.Бахтизин, Л.А.Глухова. – Минск: БГУИР, 2010. – 267 с. [с.242 - 244] С. – 2006г.- 609 с. [с. 551-558]

2.      Либерти Дж. Программирование на C#. Создание .NET приложений. Изд. 2-е. / Дж.Либерти. - М.:Символ-плюс. – 2013г. 684с. [c. 21-26]

3.      Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения / С.А.Орлов, Б.Я.Цилькер. – СПб.: Питер, 2012. – 608 с. [с. 488-500]

4.      Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. / А.С.Орлов, Б.Я.Цилькер, 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.230-240]

5.      Рудаков А.В. Технология разработки программных продуктов. Практикум: учеб.посоие для студ.учреждений сред.проф.образхования / А.В. Рудаков, Г.Н.Федорова. – 4-е изд., стер. – М.: Издательский центр «Академия», 2014. – 192с.  [с.85-97].

6.      Фленов М.Е. Библия Delhpi / М.Е.Фленов. – БХВ-Петербург, 2004г. – 880с. [с. 45-55]