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

Тип:
Добавлен:

АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ

ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ОКТЯБРЬСКИЙ ЭКОНОМИЧЕСКИЙ ТЕХНИКУМ

ОТЧЕТ

по производственной практике

ПМ.03. Участие в интеграции программных модулей

Выполнил

студент группы 4ПР1-13 Л.З. Каримов

Принял

преподаватель А.Ю. Рамазанова

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1.ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1Жизненный цикл программного продукта

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

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

.4Проектирование и разработка программного обеспечения

.5Интеграция системы

.6Среды разработки приложений

.7Язык SQL

.8Защита информации в базах данных

.9Стандартизация защищенности программ

.10Сертификация и порядок её проведения

.11Подготовка к эксплуатации

2.ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1Техническое задание

2.1.1Основание для разработки

2.1.2Назначение разработки

.1.3Требования к программе

2.1.3.1Требования к функциональным характеристикам

2.1.3.2Требования к надежности

.1.3.3Требования к составу и параметрам технических средств

.1.3.4Требования к информационной и программной совместимости

.1.3.5Требования к транспортированию и хранению

.1.3.6Специальные требования

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

2.2Описание программы

2.2.1Общие сведения о программе

2.2.2Функциональное назначение

.2.3Описание логической структуры

2.3Руководство оператора

.3.1Назначение программы

2.3.2Условия выполнения программы

.3.3Выполнение программы

.3.4Сообщения оператору

2.4Сертификация

.4.1Подготовка перечня документации для прохождения сертификации

2.4.2Проверка соответствия требованиям

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

.4.4Приемка и эксплуатация программного обеспечения

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

.4.6Определение состава документации

.4.7Подготовка руководства пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ А

ВВЕДЕНИЕ

История ОЗНА началась в начале 1950-х годов, в период послевоенного восстановления народного хозяйства и бурного развития нефтяной промышленности СССР. В марте 1953 года в г. Октябрьском (Башкирия) был построен ремонтно-механический завод, ставший основой Компании. Его продукция была востребована на нефтепромыслах республики, где шла интенсивная добыча черного золота.

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

В 1950-1960 гг. оборудование ОЗНА поставлялось преимущественно нефтяникам Башкирии, показывавшим самый значительный рост нефтедобычи в стране, за что республика была удостоена почётного наименования «второе Баку».

С 1970-х гг. Компания начала серийные поставки блочных кустовых и нефтеперекачивающих насосных станций, блоков дозирования реагентов, замерных установок и другого нефтепромыслового оборудования. В число заказчиков продукции ОЗНА, помимо отечественных нефтяников, вошли предприятия стран Совета экономической взаимопомощи (СЭВ): Болгарии, Румынии, Югославии.

Трансформации 1990-х годов потребовали новых подходов к организации деятельности: 1990 год - создано арендное предприятие (АП) «ОЗАО и П»; 1991 год - внедрена блочная система управления производством; 1992 год - принято решение о приватизации путем акционирования; 1993 год - на базе АП «ОЗАО и П» образовано «Акционерное общество открытого типа «ОЗНА». 12 июля 1996 года создано ОАО «Акционерная компания ОЗНА».

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

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

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

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

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

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

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

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Жизненный цикл программного продукта

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

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1.Формирование требований к автоматизированной системе

1.1.Обследование объекта и обоснование необходимости создания автоматизированной системы

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

.3.Оформление отчета о выполнении работ и заявки на разработку автоматизированной системы

2.Разработка концепции автоматизированной системы

2.1.Изучение объекта

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

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

.4.Оформление отчета о проделанной работе

3.Техническое задание

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

4.Эскизный проект

4.1.Разработка предварительных проектных решений по системе и её частям

4.2.Разработка документации на автоматизированную систему и её части

5.Технический проект

5.1.Разработка проектных решений по системе и её частям

5.2.Разработка документации на автоматизированную систему и её части

.3.Разработка и оформление документации на поставку комплектующих изделий

.4.Разработка заданий на проектирование в смежных частях проекта

6.Рабочая документация

6.1.Разработка рабочей документации на автоматизированную систему и её части

6.2.Разработка и адаптация программ

7.Ввод в действие

7.1.Подготовка объекта автоматизации

7.2.Подготовка персонала

.3.Комплектация автоматизированной системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

.4.Строительно-монтажные работы

.5.Пусконаладочные работы

.6.Проведение предварительных испытаний

.7.Проведение опытной эксплуатации

.8.Проведение приёмочных испытаний

8.Сопровождение автоматизированной системы

8.1.Выполнение работ в соответствии с гарантийными обязательствами

8.2.Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Модель кодирования и устранения ошибок.

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают лабораторные работы.

Данная модель имеет следующий алгоритм:

-постановка задачи;

-выполнение;

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

-при необходимости переход к первому пункту.

Модель ужасно устаревшая и характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями практически не имеет, а недостатки на лицо.

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

Рисунок 1 Каскадная модель жизненного цикла программного обеспечения

Преимущества:

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

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

Недостатки:

-отсутствие обратных связей между этапами;

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

Каскадная модель с промежуточным контролем (водоворот).

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

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования. Изображение представлено на рисунке 2.

Рисунок 2 V модель

Модель на основе разработки прототипа.

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

-Прояснить не ясные требования;

-Выбрать одно из ряда концептуальных решений;

-Проанализировать осуществимость проекта.

Классификация протопипов:

-Горизонтальные и вертикальные;

-Одноразовые и эволюционные;

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

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

Вертикальные прототипы - проверка архитектурных решений.

Одноразовые прототипы - для быстрой разработки.

Эволюционные прототипы - первое приближение эволюционной системы.

Спиральная модель жизненного цикла программного обеспечения.

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

Преимущества:

Быстрое получение результата

Повышение конкурентоспособности

Изменяющиеся требования - не проблема

Недостатки:

Отсутствие регламентации стадий

Изображение модели представлено на рисунке 3.

.

Рисунок 3 Спиральная модель жизненного цикла

1.3 Организация процесса разработки программного обеспечения

Maturity Model - модель зрелости возможностей (модель полноты потенциала) создания программного обеспечения: эволюционная модель развития способности компании разрабатывать программное обеспечение.

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

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

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки программного обеспечения с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области программного обеспечения, и членами общества разработчиков.

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки программного обеспечения. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration).

.4 Проектирование и разработка программного обеспечения

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

Целью проектирования является определение внутренних свойств системы и детализации её внешних (видимых) свойств на основе выданных заказчиком требований к программному обеспечению (исходные условия задачи). Эти требования подвергаются анализу.

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

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

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

Проектированию обычно подлежат:

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

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

-Пользовательские интерфейсы.

В российской практике проектирование ведется поэтапно в соответствии со стадиями, регламентированными ГОСТ 2.103-68:

-техническое задание(по ГОСТ 2.103-68 к стадиям разработки не относится);

-техническое предложение;

-эскизный проект;

-технический проект;

-рабочий проект.

На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).

В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document.

Разработка программного обеспечения (англ. software development) - деятельность по созданию нового программного обеспечения.

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

1.5 Интеграция системы

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

Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграция приложений и интеграция данных. Без интеграции данных невозможно провести интеграцию приложений.

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

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

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

.6 Среды разработки приложений

Интегрированная среда разработки, ИСP/IDE (англ. Integrated development environment) - комплекс программных средств, используемый программистами для разработки программного обеспечения.

Первые IDE были созданы для работы через консоль или терминал, которые сами по себе были новинкой: до того программы создавались на бумаге, вводились в машину с помощью предварительно подготовленных бумажных носителей (перфокарт, перфолент) и т. д.BASIC был первым языком, который был создан с IDE, и был также первым, который был разработан для использования в консоли или терминале. Эта IDE (часть Dartmouth Time Sharing System) управлялась при помощи команд, поэтому существенно отличалась от более поздних, управляемых с помощью меню и горячих клавиш, и тем более графических IDE, распространённых в XXI веке. Однако она позволяла редактировать исходный код, управлять файлами, компилировать, отлаживать и выполнять программы способом, принципиально подобным современным IDE.I - продукт от Softlab Munich, был первой в мире интегрированной средой разработки для программного обеспечения в 1975 г.[2] и, возможно, мировым лидером в этой рыночной нише в течение 1970-х и 1980-х годов. Он был установлен у 22000 программистов во всем мире. До 1989 года 6000 копий было установлено в Федеративной Республике Германия. Ныне Maestro I принадлежит истории и может быть найден разве что в Музее Информационной технологии в Арлингтоне.

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

Среда разработки включает в себя:

-текстовый редактор;

-компилятор и/или интерпретатор;

-средства автоматизации сборки;

-отладчик.

Иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов - для использования при объектно-ориентированной разработке программного обеспечения. IDE обычно предназначены для нескольких языков программирования - такие как IntelliJ IDEA, NetBeans, Eclipse, Qt Creator, Geany, Embarcadero RAD Studio, Code::Blocks, Xcode или Microsoft Visual Studio, но есть и IDE для одного определённого языка программирования - как, например, Visual Basic, Delphi, Dev-C++.

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

.7 Язык SQL

SQL (Structured Query Language - Структурированный язык запросов) - язык управления базами данных для реляционных баз данных. Сам по себе SQL не является Тьюринг-полным языком программирования, но его стандарт позволяет создавать для него процедурные расширения, которые расширяют его функциональность до полноценного языка программирования.

Язык был создан в 1970х годах под названием SEQUEL для системы управления базами данных System R. Позднее он был переименован в SQL во избежание конфликта торговых марок. В 1979 году SQL был впервые опубликован в виде коммерческого продукта Oracle V2.

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

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

1.Язык определения данных (DDL) используется для определения структур данных, хранящихся в базе данных. Операторы DDL позволяют создавать, изменять и удалять отдельные объекты в базе данных. Допустимые типы объектов зависят от используемой системы управления базами данных и обычно включают базы данных, пользователей, таблицы и ряд более мелких вспомогательных объектов, например, роли и индексы.

Основными его командами являются:

-CREATE DATABASE (создать базу данных);

-CREATE TABLE (создать таблицу);

-CREATE VIEW (создать виртуальную таблицу);

-CREATE INDEX (создать индекс);

-CREATE TRIGGER (создать триггер);

-CREATE PROCEDURE (создать сохраненную процедуру);

-ALTER DATABASE (модифицировать базу данных);

-ALTER TABLE (модифицировать таблицу);

-ALTER VIEW (модифицировать виртуальную таблицу);

-ALTER INDEX (модифицировать индекс);

-ALTER TRIGGER (модифицировать триггер);

-ALTER PROCEDURE (модифицировать сохраненную процедуру);

-DROP DATABASE (удалить базу данных);

-DROP TABLE (удалить таблицу);

-DROP VIEW (удалить виртуальную таблицу);

-DROP INDEX (удалить индекс);

-DROP TRIGGER (удалить триггер);

-DROP PROCEDURE (удалить сохраненную процедуру.

2.Язык манипуляции данными (DML) используется для извлечения и изменения данных в базе данных. Операторы DML позволяют извлекать, вставлять, изменять и удалять данные в таблицах. Иногда операторы select извлечения данных не рассматриваются как часть DML, поскольку они не изменяют состояние данных. Все операторы DML носят декларативный характер.

Основными его командами являются:

-SELECT (выбрать);

-INSERT (вставить);

-UPDATE (обновить);

-DELETE (удалить).

3.Язык определения доступа к данным (DCL) используется для контроля доступа к данным в базе данных. Операторы DCL применяются к привилегиям и позволяют выдавать и отбирать права на применение определенных операторов DDL и DML к определенным объектам базы данных.

Основными его командами являются:

-GRANT (дать права)

-REVOKE (забрать права)

4.Язык управления транзакциями (TCL) используется для контроля обработки транзакций в базе данных. Обычно операторы TCL включают commit для подтверждения изменений, сделанных в ходе транзакции, rollback для их отмены и savepoint для разбиения транзакции на несколько меньших частей.

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

1.8 Защита информации в базах данных

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

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

Методы защиты баз данных в различных системах управления базами данных условно делятся на две группы (анализ современных фирм Borland и Microsoft): основные и дополнительные.

К основным средствам защиты относится:

-защита паролем;

-шифрование;

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

-защита полей и записей таблиц базы данных.

Защита паролем - это самый простой способ защиты базы данных от несанкционированного доступа.

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

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

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

Шифрование обеспечивает три состояния безопасности информации:

-конфиденциальность;

-целостность;

-идентифицируемость.

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

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

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

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

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

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

-обеспечения целостности связей таблиц:

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

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

1.9 Стандартизация защищенности программ

Общие критерии оценки защищённости информационных технологий, Общие критерии, ОК (англ. Common Criteria for Information Technology Security Evaluation, Common Criteria, CC) - российский и международный стандарт по компьютерной безопасности. В отличие от стандарта FIPS 140, Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.

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

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.

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

-FAU - аудит, безопасность (требования к сервису, протоколирование и аудит);

-FIA - идентификация и аутентификация;

-FRU - использование ресурсов (для обеспечения отказоустойчивости).

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

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

-FPR - приватность;

-FDP - защита данных пользователя;

-FPT - защита функций безопасности объекта оценки.

Третья группа классов связана с инфраструктурой объекта оценки:

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

-FMT - управление безопасностью;

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

-FTP - доверенный маршрут/канал;

Требования гарантии безопасности (доверия) - требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.

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

-APE - оценка профиля защиты;

-ASE - оценка задания по безопасности.

Вторая группа связана с этапами жизненного цикла объекта аттестации:

-ADV - разработка, проектирование объекта;

-ALC - поддержка жизненного цикла;

-ACM - управление конфигурацией;

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

-ATE - тестирование;

Copyright © 2018 WorldReferat.ru All rights reserved.