И сертификация программного обеспечения 14 страница

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

· назначение и условия применения программы;

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

· обращение к программе;

· входные и выходные данные;

· сообщения.

В зависимости от особенностей ПС в документе допускается объединять отдельные разделы или вводить новые.

В разделе «Назначение и условия применения программы» должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т.п.).

В разделе «Характеристика программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.п.).

В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.).

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

В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.

В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.).

6.18. ГОСТ 19.505. Руководство оператора. Требования к содержанию и оформлению

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

Руководство оператора должно содержать следующие разделы:

· назначение программы;

· условия выполнения программы;

· выполнение программы;

· сообщения оператору.

В зависимости от особенностей ПС в документе допускается объединять отдельные разделы или вводить новые.

В разделе «Назначение программы» должны быть указаны сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации.

В разделе «Условия выполнения программы» должны быть указаны условия, необходимые для выполнения программы (минимальный и/или максимальный состав аппаратных и программных средств и т.п.).

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

В разделе «Сообщения оператору» должны быть приведены тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия оператора (действия оператора в случае сбоя, возможности повторного запуска программы и т.п.).

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

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

6.19. ГОСТ 19.508. Руководство по техническому обслуживанию. Требования к содержанию и оформлению

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

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

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

· введение;

· общие указания;

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

· описание функций;

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

В разделе «Введение» указывают назначение руководства, перечень эксплуатационных документов, которыми должны дополнительно к руководству пользоваться при техническом обслуживании.

В разделе «Общие указания» указывают порядок технического обслуживания, приводят указание по организации и особенностям его проведения.

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

В разделе «Описание функций» указывают:

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

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

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

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

Вопросы по теме

1. Краткая характеристика стандартов ЕСПД, их недостатки.

2. Структура стандартов ЕСПД.

3. Какие вы знаете виды программных документов?

4. Какие вы знаете стадии и этапы разработки программ и программной документации? Какие работы на них выполняются?

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

6. Из каких условных частей состоит программный документ?

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

8. Требования к оформлению программных документов.

9. Требования к содержанию и оформлению технического задания.

10. Требования к содержанию и оформлению спецификации.

11. Требования к содержанию и оформлению программы и методики испытаний. Показатели качества программных средств, определяемые стандартом ГОСТ 19.301-2000.

12. Требования к содержанию и оформлению текста программы.

13. Требования к содержанию и оформлению описания программы.

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

15. Требования к содержанию и оформлению описания применения.

16. Требования к содержанию и оформлению руководств системного программиста, программиста, оператора и по техническому обслуживанию.

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

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

7.1. Оценивание функциональных возможностей

7.1.1. Функциональная пригодность

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

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

· описание основных свойств и совокупности соответствующих понятий субхарактеристики функциональная пригодность при ее выборе подробно изложено в п.4.2 и проиллюстрировано табл.4.1;

· метрики качества ПС в использовании, представленные в стандарте ISO 9126–4 (см. п.3.2 и рис.3.3) и по существу отражающие особенности атрибутов функциональной пригодности, которые следует учитывать в первую очередь с позиции заказчика и пользователей;

· план и технология выполнения работ по оцениванию характеристик качества ПС для разработчиков, приобретателей и испытателей, изложенные в стандарте ISO 14598:3–5 (см. п.5.3);

· организации процессов оценивания основных характеристик качества ПС, изложенные в стандарте ISO 14598 (см. п.5.3 и рис.5.4).

Хотя исходные атрибуты качества функциональной пригодности конкретных проектов ПС в той или иной степени субъективны, их формализованные описания и согласование разработчиком и заказчиком способны предотвратить многие конфликты при оценивании соответствия требованиям комплексов программ. Для обеспечения достоверности оценивания функциональной пригодности особое значение имеет формализация на основе стандарта ГОСТ 19.301–2000 «Программы и методики испытаний ПС» и обработки результатов.

Все содержание стандарта ISO 14598 ориентировано на методологию и технологию оценивания, прежде всего, функциональной пригодности ПС, что отражается тесным взаимодействием этого стандарта со стандартами ISO 9126:1–4 и ISO/IEC 12207.

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

7.1.2. Корректность

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

В стандартах, регламентирующих ЖЦ ПС, значительное внимание уделяется процессам упорядоченного иерархического анализа корректности, исходящего от требований к информационной системе и к ПС. Этот процесс включает анализ, просмотр (обзор) и тестирование корректности выполнения требований. Он проводится сверху вниз, начиная от общих требований в ТЗ и/или спецификации на всю информационную систему до детальных требований на отдельные модули программ и их взаимодействие. Тестирование снизу вверх должно обеспечивать проверку степени корректности реализации всей совокупности требований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В стандарте ISO 9126:1–4 выделяются понятия и атрибуты внутренней и внешней корректности.

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

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

7.1.3. Способность к взаимодействию

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

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

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

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

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

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

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

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

· сложности переноса (мобильности) компонентов ПС и БД разработанных должным образом с минимальными изменениями на требуемый набор аппаратных и операционных платформ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.4. Защищенность

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

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

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

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

· оценивать опасность различных внешних и внутренних угроз безопасности;

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

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

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

Процессы проектирования и оценивания программ обеспечения безопасности информационных систем принципиально не отличаются от проектирования любых других программных комплексов (см. ISO/IEC 12207). Для этого необходимо анализировать, конкретизировать и оценивать задачи, исходные данные и факторы, определяющие безопасность функционирования программ:

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

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

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

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

· ресурсы, необходимые и доступные для разработки и размещения программных компонентов системы обеспечения безопасности информационной системы (финансово-экономические, ограниченная квалификация специалистов и вычислительные ресурсы ЭВМ);

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

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

Оценивание достигнутой эффективности реализованной системы защиты информационной системы начинается с анализа и регистрации (рис.7.1):

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

· требуемых критериев и характеристик качества защиты;

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

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

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

Рис.7.1. Процесс оценивания эффективности реализованной системы защиты

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

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

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

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

Качество комплексов защиты зависит от применения конкретных стандартов и нормативных документов и реализации их требований. Наиболее широко и детально методологические и системные задачи проектирования и оценивания комплексной защиты информационных систем изложены в стандарте ISO 15408:1999–1–3 «Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий». Стандарт представляет детальное комплексное руководство, охватывающее требования к функциям и методам гарантирования и оценивания качества основных современных методов и средств обеспечения безопасности. Его целесообразно использовать при практическом создании систем защиты ПС.

7.2. Оценивание надежности функционирования

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

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

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

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

Дата добавления: 2015-04-30