# Глава 1. Введение. Понятие безопасной разработки программного обеспечения
###### tags: `Разработка безопасного программного обеспечения`
author: @0x41
reviewed: 2022-09-20
Латыпов Ильдар Танисович
+79264747459
lit@inbox.ru
illey.t.me
0. История развития защиты безопасности
1. Цели и задачи технологий разработки программного обеспечения
2. Обеспечение современных крупных информационных систем
3. Основные определения
4. Основные понятия безопасности информации: конфиденциальность, целостность, доступность
5. Виды защиты информации
6. Модель Белла-Лападулы
7. Понятие ошибки и уязвимости в ПО
8. Классификация ошибок в ПО
9. Классификатор CWE
10. Оценка критичности ошибки по CVSS
{%pdf https://online-edu.mirea.ru/pluginfile.php?file=%2F552787%2Fmod_resource%2Fcontent%2F2%2F%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5.%20%D0%9F%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B5%20%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D0%B9%20%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F %}
---
::: info
В этой главе описываем основные определения, термины
:::
Список литературы:
1. [ГОСТ Р 56939-2016 РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ](https://docs.cntd.ru/document/1200135525)
2. [Безопасность приложений. Основные понятия](https://docs.cntd.ru/document/1200112883)
3. [Безопасность приложений. Пример](https://docs.cntd.ru/document/1200179560)
4. [Общие критерии безопасной разработки](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8)
5. [Оранжевая книга](https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8_%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC)
6. [ISO/IEC 15408 Introduction and general model](https://ipsec.pl/files/Contrib/cc/c040612_ISO_IEC_15408-1_2005(E).pdf)
7. [ISO/IEC 15408 Security functional requirements](http://comsec.spb.ru/matherials/is/iso15408-2.pdf)
8. [ISO/IEC 15408 Security assurance requirements](http://comsec.spb.ru/matherials/is/iso15408-3.pdf)
9. [28 МАГИЧЕСКИХ МЕР РАЗРАБОТКИ БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ](https://cyberrus.com/wp-content/uploads/2015/12/02-10-513-15_1.-%D0%91%D0%B0%D1%80%D0%B0%D0%B1%D0%B0%D0%BD%D0%BE%D0%B2.pdf)
## Исторические вехи
### Оранжевая книга
**Критерии определения безопасности компьютерных систем** ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Trusted Computer System Evaluation Criteria) — стандарт [Министерства обороны](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D0%B5%D1%80%D1%81%D1%82%D0%B2%D0%BE_%D0%BE%D0%B1%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%A1%D0%A8%D0%90 "Министерство обороны США") [США](https://ru.wikipedia.org/wiki/%D0%A1%D0%A8%D0%90 "США"), устанавливающий основные условия для оценки эффективности средств компьютерной безопасности, содержащихся в компьютерной системе. Критерии используются для определения, классификации и выбора компьютерных систем, предназначенных для обработки, хранения и поиска важной или секретной информации.
Критерии, часто упоминающиеся как **Оранжевая книга**, занимают центральное место среди публикаций [«Радужной серии»](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D1%83%D0%B6%D0%BD%D0%B0%D1%8F_%D1%81%D0%B5%D1%80%D0%B8%D1%8F "Радужная серия") Министерства обороны США. Изначально выпущенные [Центром национальной компьютерной безопасности](https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BD%D1%82%D1%80_%D0%BD%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%BE%D0%B9_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%A1%D0%A8%D0%90 "Центр национальной компьютерной безопасности США") — подразделением [Агентства национальной безопасности](https://ru.wikipedia.org/wiki/%D0%90%D0%B3%D0%B5%D0%BD%D1%82%D1%81%D1%82%D0%B2%D0%BE_%D0%BD%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(%D0%A1%D0%A8%D0%90) "Агентство национальной безопасности (США)") в [1983 году](https://ru.wikipedia.org/wiki/1983_%D0%B3%D0%BE%D0%B4 "1983 год") и потом обновлённые в [1985](https://ru.wikipedia.org/wiki/1985 "1985").
Аналогом Оранжевой книги является международный стандарт [ISO/IEC 15408](https://ru.wikipedia.org/wiki/ISO/IEC_15408 "ISO/IEC 15408"), опубликованный в 2005 году. Это более универсальный и совершенный стандарт, но вопреки распространённому заблуждению, он не заменял собой Оранжевую книгу в силу разной юрисдикции документов — Оранжевая книга используется исключительно [Министерством Обороны](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D0%B5%D1%80%D1%81%D1%82%D0%B2%D0%BE_%D0%BE%D0%B1%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%A1%D0%A8%D0%90 "Министерство обороны США") [США](https://ru.wikipedia.org/wiki/%D0%A1%D0%A8%D0%90 "США"), в то время как [ISO/IEC 15408](https://ru.wikipedia.org/wiki/ISO/IEC_15408 "ISO/IEC 15408") ратифицировали множество стран, включая Россию.
#### Основные сведения
**Критерии оценки доверенных компьютерных систем** — стандарт [Министерства обороны](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D0%B5%D1%80%D1%81%D1%82%D0%B2%D0%BE_%D0%BE%D0%B1%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_%D0%A1%D0%A8%D0%90 "Министерство обороны США") [США](https://ru.wikipedia.org/wiki/%D0%A1%D0%A8%D0%90 "США") ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Department of Defense Trusted Computer System Evaluation Criteria, TCSEC, DoD 5200.28-STD, December 26, 1985), более известный под именем «Оранжевая книга» ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") "Orange Book") из-за цвета обложки.
Данный стандарт получил международное признание и оказал исключительно сильное влияние на последующие разработки в области [информационной безопасности](https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C "Информационная безопасность") (ИБ).
Данный стандарт относится к оценочным стандартам (классификация [информационных систем](https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 "Информационная система") и [средств защиты](https://ru.wikipedia.org/w/index.php?title=%D0%A1%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%B7%D0%B0%D1%89%D0%B8%D1%82%D1%8B&action=edit&redlink=1 "Средство защиты (страница отсутствует)")) и речь в нём идёт не о безопасных, а о [доверенных системах](https://ru.wikipedia.org/w/index.php?title=%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0&action=edit&redlink=1 "Доверенная система (страница отсутствует)").
Каких-либо абсолютных систем (в том числе и безопасных) в нашей жизни не существует. Поэтому и было предложено оценивать лишь степень доверия, которое можно оказать той или иной системе.
В стандарте заложен понятийный базис ИБ ([безопасная система](https://ru.wikipedia.org/w/index.php?title=%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0&action=edit&redlink=1 "Безопасная система (страница отсутствует)"), [доверенная система](https://ru.wikipedia.org/w/index.php?title=%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0&action=edit&redlink=1 "Доверенная система (страница отсутствует)"), [политика безопасности](https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8 "Политика безопасности"), [уровень гарантированности](https://ru.wikipedia.org/w/index.php?title=%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B3%D0%B0%D1%80%D0%B0%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8&action=edit&redlink=1 "Уровень гарантированности (страница отсутствует)"), [подотчетность](https://ru.wikipedia.org/w/index.php?title=%D0%9F%D0%BE%D0%B4%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C&action=edit&redlink=1 "Подотчетность (страница отсутствует)"), [доверенная вычислительная база](https://ru.wikipedia.org/w/index.php?title=%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B0%D0%B7%D0%B0&action=edit&redlink=1 "Доверенная вычислительная база (страница отсутствует)"), [монитор обращений](https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80_%D0%BE%D0%B1%D1%80%D0%B0%D1%89%D0%B5%D0%BD%D0%B8%D0%B9&action=edit&redlink=1 "Монитор обращений (страница отсутствует)"), [ядро безопасности](https://ru.wikipedia.org/w/index.php?title=%D0%AF%D0%B4%D1%80%D0%BE_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8&action=edit&redlink=1 "Ядро безопасности (страница отсутствует)"), [периметр безопасности](https://ru.wikipedia.org/w/index.php?title=%D0%9F%D0%B5%D1%80%D0%B8%D0%BC%D0%B5%D1%82%D1%80_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8&action=edit&redlink=1 "Периметр безопасности (страница отсутствует)")).
Безопасность и доверие оцениваются в данном стандарте с точки зрения управления доступом к информации, что и является средством обеспечения [конфиденциальности](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C "Конфиденциальность") и [целостности](https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%B8 "Целостность информации").
Вслед за «Оранжевой книгой» появилась целая «[Радужная серия](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D1%83%D0%B6%D0%BD%D0%B0%D1%8F_%D1%81%D0%B5%D1%80%D0%B8%D1%8F "Радужная серия")». Наиболее значимой в ней явилась интерпретация «Оранжевой книги» для сетевых конфигураций ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") National Computer Security Center. Trusted Network Interpretation, NCSC-TG-005, 1987), где в первой части интерпретируется «Оранжевая книга», а во второй части описываются сервисы безопасности, специфичные для сетевых конфигураций.
Основные цели и средства
-------------------------
### Политики
Политики безопасности должны быть подробными, чётко определёнными и обязательными для компьютерной системы. Есть две основных политики безопасности:
- Мандатная политика безопасности — обязательные правила управления доступом напрямую, основанные на индивидуальном разрешении, разрешении на доступ к информации и уровне конфиденциальности запрашиваемой информации. Другие косвенные факторы являются существенными и окружающими. Эта политика также должна точно соответствовать закону, главной политике и прочим важным руководствам, в которых устанавливаются правила.
- Маркирование — системы, предназначенные для обязательной мандатной политики безопасности, должны предоставлять и сохранять целостность меток управления доступом, а также хранить метки, если объект перемещён.
- Дискреционная политика безопасности — предоставляет непротиворечивый набор правил для управления и ограничения доступа, основанный на идентификации тех пользователей, которые намерены получить только необходимую им информацию.
### Ответственность
Индивидуальная ответственность в независимости от политики должна быть обязательной. Есть три требования по условиям ответственности:
- [Аутентификация](https://ru.wikipedia.org/wiki/%D0%90%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F "Аутентификация") — процесс, используемый для распознавания индивидуального пользователя.
- [Авторизация](https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F "Авторизация") — проверка разрешения индивидуальному пользователю на получение информации определённого рода.
- Аудит — контролируемая информация должна избирательно храниться и защищаться в мере, достаточной для отслеживания действий аутентифицированного пользователя, затрагивающих безопасность.
### Гарантии
Компьютерная система должна содержать аппаратные и/или программные механизмы, которые могут независимо определять, обеспечивается ли достаточная уверенность в том, что система исполняет указанные выше требования. Вдобавок уверенность должна включать гарантию того, что безопасная часть системы работает только так, как запланировано. Для достижения этих целей необходимо два типа гарантий и соответствующих им элементов:
- Механизмы гарантий
- Операционная гарантия — уверенность в том, что реализация спроектированной системы обеспечивает осуществление принятой стратегии защиты системы. Сюда относятся системная архитектура, целостность системы, анализ скрытых каналов, безопасное управление возможностями и безопасное восстановление.
- Гарантия жизненного цикла — уверенность в том, что система разработана и поддерживается в соответствии с формализованными и жёстко контролируемыми критериями функционирования. Сюда относятся тестирование безопасности, задание на проектирование и его проверка, управление настройками и соответствие параметров системы заявленным.
- Гарантии непрерывной защиты — надёжные механизмы, обеспечивающие непрерывную защиту основных средств от преступных и/или несанкционированных изменений.
### Документирование
В каждом классе есть дополнительный набор документов, который адресован разработчикам, пользователям и администраторам системы в соответствии с их полномочиями. Эта документация содержит:
- Руководство пользователя по особенностям безопасности.
- Руководство по безопасным средствам работы.
- Документация о тестировании.
- Проектная документация
Основные понятия
-----------------
### Безопасная система
Это система, которая обеспечивает управление доступом к информации таким образом, что только авторизованные лица или процессы, действующие от их имени, получают право работы с информацией.
### Доверенная система
Под доверенной системой в стандарте понимается система, использующая аппаратные и программные средства для обеспечения одновременной обработки информации разной категории секретности группой пользователей без нарушения прав доступа.
### Политика безопасности
Это набор законов, правил, процедур и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. Причём, политика безопасности относится к активным методам защиты, поскольку учитывает анализ возможных угроз и выбор адекватных мер противодействия.
### Уровень гарантированности
Подразумевает меру доверия, которая может быть оказана архитектуре и реализации информационной системы, и показывает, насколько корректны механизмы, отвечающие за реализацию политики безопасности (пассивный аспект защиты).
### Подотчетность
В группе «Подотчетность» должны быть следующие требования:
- **1) Идентификация и аутентификация.** Все субъекты должны иметь уникальные идентификаторы. Контроль доступа должен осуществляться на основании результатов идентификации субъекта и объекта доступа, подтверждения подлинности их идентификаторов (аутентификации) и правил разграничения доступа. Данные, используемые для идентификации и аутентификации, должны быть защищены от несанкционированного доступа, модификации и уничтожения и должны быть ассоциированы со всеми активными компонентами компьютерной системы, функционирование которых критично с точки зрения безопасности.
- **2) Регистрация и учет.** Для определения степени ответственности пользователей за действия в системе, все происходящие в ней события, имеющие значение с точки зрения безопасности, должны отслеживаться и регистрироваться в защищённом протоколе (то есть должен существовать объект компьютерной системы, потоки от которого и к которому доступны только субъекту администрирования). Система регистрации должна осуществлять анализ общего потока событий и выделять из него только те события, которые оказывают влияние на безопасность для сокращения объёма протокола и повышения эффективности его анализа. Протокол событий должен быть надёжно защищён от несанкционированного доступа, модификации и уничтожения.
### Доверенная вычислительная база
Это совокупность защитных механизмов информационной системы (как программные, так и аппаратные), реализующих политику безопасности.
### Монитор обращений
Контроль за выполнением субъектами (пользователями) определённых операций над объектами, путём проверки допустимости обращения (данного пользователя) к программам и данным разрешенному набору действий.
Обязательные качества для монитора обращений:
1. Изолированность (неотслеживаемость работы).
2. Полнота (невозможность обойти).
3. Верифицируемость (возможность анализа и тестирования).
### Ядро безопасности
Конкретная реализация монитора обращений, обладающая гарантированной неизменностью.
### Периметр безопасности
Это граница доверенной вычислительной базы.
Механизмы реализации безопасности
----------------------------------
### Произвольное управление доступом
Иначе — добровольное управление доступом.
_Добровольное управление доступом_ — это метод ограничения доступа к объектам, основанный на учёте личности субъекта или группы, в которую субъект входит. Добровольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению давать другим субъектам или отбирать у них права доступа к объекту.
Большинство операционных систем и СУБД реализуют именно добровольное управление доступом. Главное его достоинство — гибкость, главные недостатки — рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы или секретные файлы в незащищённые каталоги.
### Безопасность повторного использования объектов
Безопасность повторного использования объектов — важное на практике дополнение средств управления доступом, предохраняющее от случайного или преднамеренного извлечения секретной информации из «мусора». Безопасность повторного использования должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т. п.), для дисковых блоков и магнитных носителей в целом. Важно обратить внимание на следующий момент. Поскольку информация о субъектах также представляет собой объект, необходимо позаботиться о безопасности «повторного использования субъектов». Когда пользователь покидает организацию, следует не только лишить его возможности входа в систему, но и запретить доступ ко всем объектам. В противном случае, новый сотрудник может получить ранее использовавшийся идентификатор, а с ним и все права своего предшественника.
Современные интеллектуальные периферийные устройства усложняют обеспечение безопасности повторного использования объектов. Действительно, принтер может буферизовать несколько страниц документа, которые останутся в памяти даже после окончания печати. Необходимо предпринять специальные меры, чтобы «вытолкнуть» их оттуда.
### Метки безопасности
Предусмотрены метки для субъектов (степень благонадёжности) и объектов (степень конфиденциальности информации). Метки безопасности содержат данные об уровне секретности и категории, к которой относятся данные. Согласно «Оранжевой книге», метки безопасности состоят из двух частей — уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:
- совершенно секретно;
- секретно;
- конфиденциально;
- не секретно.
Для разных систем набор уровней секретности может различаться. Категории образуют неупорядоченный набор. Их назначение — описать предметную область, к которой относятся данные. В военном окружении каждая категория может соответствовать, например, определённому виду вооружений. Механизм категорий позволяет разделить информацию по отсекам, что способствует лучшей защищённости. Субъект не может получить доступ к «чужим» категориям, даже если его уровень благонадёжности «совершенно секретно». Специалист по танкам не узнает тактико-технические данные самолётов.
Главная проблема, которую необходимо решать в связи с метками, это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными. В особенности это относится к экспорту и импорту данных. Например, печатный документ должен открываться заголовком, содержащим текстовое и/или графическое представление метки безопасности. Аналогично при передаче файла по каналу связи должна передаваться и ассоциированная с ним метка, причём в таком виде, чтобы удалённая система могла её разобрать, несмотря на возможные различия в уровнях секретности и наборе категорий.
Одним из средств обеспечения целостности меток безопасности является разделение устройств на многоуровневые и одноуровневые. На многоуровневых устройствах может храниться информация разного уровня секретности (точнее, лежащая в определённом диапазоне уровней). Одноуровневое устройство можно рассматривать как вырожденный случай многоуровневого, когда допустимый диапазон состоит из одного уровня. Зная уровень устройства, система может решить, допустимо ли записывать на него информацию с определённой меткой. Например, попытка напечатать совершенно секретную информацию на принтере общего пользования с уровнем «несекретно» потерпит неудачу.
### Принудительное управление доступом
Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, «конфиденциальный» субъект может писать в секретные файлы, но не может — в несекретные (разумеется, должны также выполняться ограничения на набор категорий). На первый взгляд подобное ограничение может показаться странным, однако оно вполне разумно. Ни при каких операциях уровень секретности информации не должен понижаться, хотя обратный процесс вполне возможен.
Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов, на месте которых могут оказаться даже системные администраторы. После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение «разрешить доступ к объекту Х ещё и для пользователя Y». Конечно, можно изменить метку безопасности пользователя Y, но тогда он скорее всего получит доступ ко многим дополнительным объектам, а не только к Х.
Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД, отличающихся повышенными мерами безопасности. В частности, такие варианты существуют для SunOS и СУБД Ingres. Независимо от практического использования принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее мыслить в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа. Впрочем, в реальной жизни добровольное и принудительное управление доступом сочетается в рамках одной системы, что позволяет использовать сильные стороны обоих подходов.
Разделы и классы
-----------------
Критерии делятся на 4 раздела: D, C, B и A, из которых наивысшей безопасностью обладает раздел A. Каждый дивизион представляет собой значительные отличия в доверии индивидуальным пользователям или организациям. Разделы C, B и A иерархически разбиты на серии подразделов, называющиеся классами: C1, C2, B1, B2, B3 и A1. Каждый раздел и класс расширяет или дополняет требования указанные в предшествующем разделе или классе.
### D — Минимальная защита
Системы, безопасность которых была оценена, но оказалась не удовлетворяющей требованиям более высоких разделов.
### C — Дискреционная защита
- C1 — Дискреционное обеспечение секретности.
- Разделение пользователей и данных
- [Дискреционное управление доступом](https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BE%D0%BC "Дискреционное управление доступом"), допускающее принудительное ограничение доступа на индивидуальной основе.
- C2 — Управление доступом
- Более чётко оформленное дискреционное управление доступом.
- Индивидуальные учётные записи, вход под которыми возможен через процедуру авторизации.
- Журнал контроля доступа к системе.
- Изоляция ресурсов.
### B — Мандатная защита
- B1 — Защита с применением мета-безопасности
- [Мандатное управление доступом](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BD%D0%B4%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BE%D0%BC "Мандатное управление доступом") к выбранным субъектам и объектам.
- Все обнаруженные недостатки должны быть устранены или убраны каким-либо другим способом.
- Маркировка данных
- B2 — Структурированная защита
- Чётко определённая и документированная модель правил безопасности.
- Применение расширенного дискреционного и мандатного управления доступом ко всем объектам и субъектам.
- Скрытые каналы хранения.
- B3 — Домены безопасности
- Соответствие требованиям [монитора обращений](https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80_%D0%BE%D0%B1%D1%80%D0%B0%D1%89%D0%B5%D0%BD%D0%B8%D0%B9&action=edit&redlink=1 "Монитор обращений (страница отсутствует)").
- Структурирование для исключения кода, не отвечающего требованиям обязательной политики безопасности.
- Поддержка администратора системы безопасности.
- Примером подобной системы является [XTS-300](https://ru.wikipedia.org/w/index.php?title=XTS-300&action=edit&redlink=1 "XTS-300 (страница отсутствует)"), предшественница [XTS-400](https://ru.wikipedia.org/wiki/XTS-400 "XTS-400").
### A — Проверенная защита
- A1 — Проверенный дизайн.
- По функциям идентично B3.
- Формализованный дизайн и проверенные техники, включающие высокоуровневую спецификацию.
- Формализованные процедуры управления и распространения.
- Примером подобной системы является [SCOMP](https://ru.wikipedia.org/w/index.php?title=SCOMP&action=edit&redlink=1 "SCOMP (страница отсутствует)"), предшественница XTS-400.
- Выше A1
- Системная архитектура демонстрирующая, что требования самозащиты и полноценности для мониторов обращений были выполнены в соответствии с «Базой безопасных вычислений» (коллекцией программного и аппаратного обеспечения необходимых для обязательной политики безопасности в операционных системах ориентированных на безопасность).
Классы безопасности
--------------------
В критериях впервые введены четыре уровня доверия — D, C, B и A, которые подразделяются на классы. Классов безопасности всего шесть — C1, C2, B1, B2, B3, A1 (перечислены в порядке ужесточения требований).
### Уровень D
Данный уровень предназначен для систем, признанных неудовлетворительными.
### Уровень C
Иначе — произвольное управление доступом.
#### Класс C1
Политика безопасности и уровень гарантированности для данного класса должны удовлетворять следующим важнейшим требованиям:
1. доверенная вычислительная база должна управлять доступом именованных пользователей к именованным объектам;
2. пользователи должны идентифицировать себя, причём аутентификационная информация должна быть защищена от несанкционированного доступа;
3. доверенная вычислительная база должна поддерживать область для собственного выполнения, защищённую от внешних воздействий;
4. должны быть в наличии аппаратные или программные средства, позволяющие периодически проверять корректность функционирования аппаратных и микропрограммных компонентов доверенной вычислительной базы;
5. защитные механизмы должны быть протестированы (нет способов обойти или разрушить средства защиты доверенной вычислительной базы);
6. должны быть описаны подход к безопасности и его применение при реализации доверенной вычислительной базы.
#### Класс C2
В дополнение к C1:
1. права доступа должны гранулироваться с точностью до пользователя. Все объекты должны подвергаться контролю доступа.
2. при выделении хранимого объекта из пула ресурсов доверенной вычислительной базы необходимо ликвидировать все следы его использования.
3. каждый пользователь системы должен уникальным образом идентифицироваться. Каждое регистрируемое действие должно ассоциироваться с конкретным пользователем.
4. доверенная вычислительная база должна создавать, поддерживать и защищать журнал регистрационной информации, относящейся к доступу к объектам, контролируемым базой.
5. тестирование должно подтвердить отсутствие очевидных недостатков в механизмах изоляции ресурсов и защиты регистрационной информации.
### Уровень B
Также именуется — принудительное управление доступом.
#### Класс B1
В дополнение к C2:
1. доверенная вычислительная база должна управлять метками безопасности, ассоциируемыми с каждым субъектом и хранимым объектом.
2. доверенная вычислительная база должна обеспечить реализацию принудительного управления доступом всех субъектов ко всем хранимым объектам.
3. доверенная вычислительная база должна обеспечивать взаимную изоляцию процессов путём разделения их адресных пространств.
4. группа специалистов, полностью понимающих реализацию доверенной вычислительной базы, должна подвергнуть описание архитектуры, исходные и объектные коды тщательному анализу и тестированию.
5. должна существовать неформальная или формальная модель политики безопасности, поддерживаемой доверенной вычислительной базой.
#### Класс B2
В дополнение к B1:
1. снабжаться метками должны все ресурсы системы (например, ПЗУ), прямо или косвенно доступные субъектам.
2. к доверенной вычислительной базе должен поддерживаться доверенный коммуникационный путь для пользователя, выполняющего операции начальной идентификации и аутентификации.
3. должна быть предусмотрена возможность регистрации событий, связанных с организацией тайных каналов обмена с памятью.
4. доверенная вычислительная база должна быть внутренне структурирована на хорошо определённые, относительно независимые модули.
5. системный архитектор должен тщательно проанализировать возможности организации тайных каналов обмена с памятью и оценить максимальную пропускную способность каждого выявленного канала.
6. должна быть продемонстрирована относительная устойчивость доверенной вычислительной базы к попыткам проникновения.
7. модель политики безопасности должна быть формальной. Для доверенной вычислительной базы должны существовать описательные спецификации верхнего уровня, точно и полно определяющие её интерфейс.
8. в процессе разработки и сопровождения доверенной вычислительной базы должна использоваться система конфигурационного управления, обеспечивающая контроль изменений в описательных спецификациях верхнего уровня, иных архитектурных данных, реализационной документации, исходных текстах, работающей версии объектного кода, тестовых данных и документации.
9. тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации.
#### Класс B3
В дополнение к B2:
1. для произвольного управления доступом должны обязательно использоваться списки управления доступом с указанием разрешённых режимов.
2. должна быть предусмотрена возможность регистрации появления или накопления событий, несущих угрозу политике безопасности системы. Администратор безопасности должен немедленно извещаться о попытках нарушения политики безопасности, а система, в случае продолжения попыток, должна пресекать их наименее болезненным способом.
3. доверенная вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально простой защитный механизм с точно определённой семантикой.
4. процедура анализа должна быть выполнена для временных тайных каналов.
5. должна быть специфицирована роль администратора безопасности. Получить права администратора безопасности можно только после выполнения явных, протоколируемых действий.
6. должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты.
7. должна быть продемонстрирована устойчивость доверенной вычислительной базы к попыткам проникновения.
### Уровень A
Носит название — верифицируемая безопасность.
#### Класс A1
В дополнение к B3:
1. тестирование должно продемонстрировать, что реализация доверенной вычислительной базы соответствует формальным спецификациям верхнего уровня.
2. помимо описательных, должны быть представлены формальные спецификации верхнего уровня. Необходимо использовать современные методы формальной спецификации и верификации систем.
3. механизм конфигурационного управления должен распространяться на весь [жизненный цикл](https://ru.wikipedia.org/wiki/%D0%96%D0%B8%D0%B7%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D1%86%D0%B8%D0%BA%D0%BB_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B "Жизненный цикл информационной системы") и все компоненты системы, имеющие отношение к обеспечению безопасности.
4. должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами.
Краткая классификация
----------------------
Такова классификация, введённая в «Оранжевой книге». Коротко её можно сформулировать так:
- уровень C — произвольное управление доступом;
- уровень B — принудительное управление доступом;
- уровень A — верифицируемая безопасность.
Конечно, в адрес «Критериев …» можно высказать целый ряд серьёзных замечаний (таких, например, как полное игнорирование проблем, возникающих в распределённых системах). Тем не менее, следует подчеркнуть, что публикация «Оранжевой книги» без всякого преувеличения стала эпохальным событием в области информационной безопасности. Появился общепризнанный понятийный базис, без которого даже обсуждение проблем ИБ было бы затруднительным.
Отметим, что огромный идейный потенциал «Оранжевой книги» пока во многом остаётся невостребованным. Прежде всего это касается концепции технологической гарантированности, охватывающей весь жизненный цикл системы — от выработки спецификаций до фазы эксплуатации. При современной технологии программирования результирующая система не содержит информации, присутствующей в исходных спецификациях, теряется информация о семантике программ.
### Общие критерии
**Общие критерии оценки защищённости информационных технологий**, **Общие критерии**[\[1\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-1), **ОК** ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Common Criteria for Information Technology Security Evaluation, Common Criteria, CC) — [принятый в России](https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F#Нормы_Государственной_системы_стандартизации_России "Международная стандартизация")[\[2\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated4-2) [международный стандарт](https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82 "Международный стандарт")[\[3\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated1-3) по [компьютерной безопасности](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C "Компьютерная безопасность"). В отличие от стандарта [FIPS](https://ru.wikipedia.org/wiki/FIPS "FIPS") 140[\[4\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-4), _Common Criteria_ не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает [инфраструктуру](https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0 "Инфраструктура") (_framework_), в которой _потребители_ компьютерной системы могут описать требования, _разработчики_ могут заявить о свойствах безопасности продуктов, а _[эксперты](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%B5%D1%80%D1%82 "Эксперт")_ по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.
Основные понятия
----------------
Стандарт содержит два основных вида требований безопасности: **функциональные**, предъявляемые к функциям безопасности и реализующим их механизмам, и **требования доверия**, предъявляемые к технологии и процессу разработки и эксплуатации.
Чтобы структурировать пространство требований, в стандарте используется иерархия класс-семейство-компонент-элемент: классы определяют наиболее общую, «предметную» группировку требований, семейства в пределах класса различаются по строгости и другим нюансам требований, компонент — минимальный набор требований, фигурирующий как целое, элемент — неделимое требование.
### Функциональные требования
Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.
1. Первая группа определяет элементарные сервисы безопасности:
1. FAU — [аудит](https://ru.wikipedia.org/wiki/%D0%90%D1%83%D0%B4%D0%B8%D1%82 "Аудит"), безопасность (требования к сервису, протоколирование и аудит);
2. FIA — [идентификация](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F "Идентификация") и [аутентификация](https://ru.wikipedia.org/wiki/%D0%90%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F "Аутентификация");
3. FRU — использование ресурсов (для обеспечения отказоустойчивости).
2. Вторая группа описывает производные сервисы, реализованные на базе элементарных:
1. FCO — связь (безопасность коммуникаций отправитель-получатель);
2. FPR — приватность;
3. FDP — защита данных пользователя;
4. FPT — защита функций безопасности объекта оценки.
3. Третья группа классов связана с инфраструктурой объекта оценки:
1. FCS — [криптографическая поддержка](https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F "Криптография") (обеспечивает управление криптоключами и крипто-операциями);
2. FMT — управление безопасностью;
3. FTA — доступ к объекту оценки (управление сеансами работы пользователей);
4. FTP — доверенный маршрут/канал;
### Классы функциональных требований к элементарным сервисам безопасности
К элементарным сервисам безопасности относятся следующие классы FAU, FIA и FRU.
Класс FAU включает шесть семейств (FAU\_GEN, FAU\_SEL, FAU\_STG, FAU\_SAR, FAU\_SAA и FAU\_ARP), причём каждое семейство может содержать разное число компонентов.
Назначение компонентов данного класса следующее.
FAU\_GEN — генерация данных аудита безопасности. Содержит два компонента FAU\_GEN.1 (генерация данных аудита) и FAU_GEN.2 (ассоциация идентификатора пользователя).
### Требования доверия
Требования гарантии безопасности (доверия) — требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.
1. Первая группа содержит классы требований, предшествующих разработке и оценке объекта:
1. APE — оценка профиля защиты;
2. ASE — оценка задания по безопасности.
2. Вторая группа связана с этапами жизненного цикла объекта аттестации:
1. ADV — разработка, проектирование объекта;
2. ALC — поддержка жизненного цикла;
3. ACM — управление конфигурацией;
4. AGD — руководство администратора и пользователя;
5. ATE — тестирование;
6. AVA — оценка [уязвимостей](https://ru.wikipedia.org/wiki/%D0%A3%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C "Уязвимость");
7. ADO — требования к поставке и эксплуатации;
8. АMA — поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.
История разработки
-------------------
Разработке _«Общих критериев»_ предшествовала разработка документа _«Критерии оценки безопасности информационных технологий»_ ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Evaluation Criteria for IT Security, ECITS), начатая в [1990 году](https://ru.wikipedia.org/wiki/1990_%D0%B3%D0%BE%D0%B4 "1990 год"), и выполненная рабочей группой 3 подкомитета 27 первого совместного технического комитета (или JTC1/SC27/WG3) Международной организации по стандартизации ([ISO](https://ru.wikipedia.org/wiki/ISO "ISO")).
Данный документ послужил основой для начала работы над документом _Общие критерии оценки безопасности информационных технологий_ ([англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Common Criteria for IT Security Evaluation), начатой в 1993 году. В этой работе принимали участие правительственные организации шести стран ([США](https://ru.wikipedia.org/wiki/%D0%A1%D0%A8%D0%90 "США"), [Канада](https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B0%D0%B4%D0%B0 "Канада"), [Германия](https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D1%80%D0%BC%D0%B0%D0%BD%D0%B8%D1%8F "Германия"), [Великобритания](https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BB%D0%B8%D0%BA%D0%BE%D0%B1%D1%80%D0%B8%D1%82%D0%B0%D0%BD%D0%B8%D1%8F "Великобритания"), [Франция](https://ru.wikipedia.org/wiki/%D0%A4%D1%80%D0%B0%D0%BD%D1%86%D0%B8%D1%8F "Франция"), [Нидерланды](https://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B4%D0%B5%D1%80%D0%BB%D0%B0%D0%BD%D0%B4%D1%8B "Нидерланды")). В работе над проектом принимали участие следующие институты:
1. Национальный институт стандартов и технологии и Агентство национальной безопасности ([США](https://ru.wikipedia.org/wiki/%D0%A1%D0%A8%D0%90 "США"));
2. Учреждение безопасности коммуникаций ([Канада](https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B0%D0%B4%D0%B0 "Канада"));
3. Агентство информационной безопасности ([Германия](https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D1%80%D0%BC%D0%B0%D0%BD%D0%B8%D1%8F "Германия"));
4. Органы исполнения программы безопасности и сертификации ИТ ([Англия](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D1%8F "Англия"));
5. Центр обеспечения безопасности систем ([Франция](https://ru.wikipedia.org/wiki/%D0%A4%D1%80%D0%B0%D0%BD%D1%86%D0%B8%D1%8F "Франция"));
6. Агентство национальной безопасности коммуникаций ([Нидерланды](https://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B4%D0%B5%D1%80%D0%BB%D0%B0%D0%BD%D0%B4%D1%8B "Нидерланды")).
Стандарт был принят в 2005 году комитетом ISO и имеет статус международного стандарта, идентификационный номер [ISO/IEC 15408](https://ru.wikipedia.org/wiki/ISO/IEC_15408 "ISO/IEC 15408")[\[2\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated4-2)[\[3\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated1-3). В профессиональных кругах за этим документом впоследствии закрепилось короткое название — [англ.](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Английский язык") Common Criteria, CC; [рус.](https://ru.wikipedia.org/wiki/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA "Русский язык") «Общие критерии», ОК.
Модель угроз при сертификации
------------------------------
Прохождение сертификации неким продуктом в соответствии со стандартом _Common Criteria_ может подтверждать или не подтверждать определенный уровень [защищённости](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D1%89%D0%B8%D1%89%D1%91%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C "Защищённость") продукта, в зависимости от модели угроз и окружения.
В соответствии с методикой сертификации производитель сам определяет окружение и [модель злоумышленника](https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B7%D0%BB%D0%BE%D1%83%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%BD%D0%B8%D0%BA%D0%B0&action=edit&redlink=1 "Модель злоумышленника (страница отсутствует)"), в которых находится продукт. Именно в этих предположениях и проверяется соответствие продукта заявленным параметрам. Если после сертификации в продукте обнаружатся новые, неизвестные ранее [уязвимости](https://ru.wikipedia.org/wiki/%D0%A3%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C "Уязвимость"), производитель должен выпустить [обновление](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5 "Обновление") и провести повторную сертификацию. В противном случае сертификат должен быть отозван.
[Операционная система](https://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 "Операционная система") [Microsoft](https://ru.wikipedia.org/wiki/Microsoft "Microsoft") [Windows XP](https://ru.wikipedia.org/wiki/Windows_XP "Windows XP") (Professional SP2 и Embedded SP2), а также Windows Server 2003[\[5\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated2-5)[\[6\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated3-6)[\[7\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-7)[\[8\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-8) были сертифицированы на уровень Common Criteria EAL4+ по профилю CAPP[\[9\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-9) в 2005-2007 годах, после чего для них были выпущены пакеты обновлений (_service pack_) и регулярно выпускались новые критические обновления безопасности. Тем не менее, Windows XP в проверявшейся версии по-прежнему обладал сертификатом EAL4+,[\[5\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated2-5)[\[6\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-autogenerated3-6). Это факт свидетельствует в пользу того, что условия сертификации (окружение и модель злоумышленника) были подобраны весьма консервативно, в результате чего ни одна из обнаруженных уязвимостей не применима к протестированной конфигурации.
Разумеется, для реальных конфигураций многие из этих уязвимостей представляют опасность. Microsoft рекомендует пользователям устанавливать все критические обновления безопасности.
Общие критерии в России
------------------------
В 2002 году приказом председателя Гостехкомиссии России были введены в действие следующие руководящие документы[\[10\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-10), разработанные на основе международных документов Common Criteria версии 2.3:
- «Безопасность информационных технологий. Критерии оценки безопасности информационных технологий»;
- «Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. Часть 2\. Функциональные требования безопасности»;
- «Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. Часть 3\. Требования доверия к безопасности».
С этого момента в отечественной системе сертификации была формально разрешена сертификация изделий информационных технологий по требованиям заданий по безопасности. Поскольку область применения (классы автоматизированных систем) подобных сертификатов соответствия не была определена в явном виде, подобная сертификация в большинстве случае носила рекламных характер – производители предпочитали сертифицировать свои изделия по требованиям классических руководящих документов.
С 2012 года ФСТЭК России ведет активную работу по актуализации нормативной и методической базы сертификации средств защиты информации. В частности, были введены в действие требования к следующим типам средств защиты информации:
- система обнаружения вторжений;[\[11\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-11)
- средство антивирусной защиты;[\[12\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-12)
- средство доверенной загрузки;[\[13\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-13)
- средство контроля съемных машинных носителей информации;[\[14\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-14)
- межсетевой экран;[\[15\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-15)
- операционная система.[\[16\]](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8#cite_note-16)
Требования для отдельного типа средств защиты информации оформлены в виде комплекта документов:
- документ «Требования …»: документ имеет пометку «для служебного пользования» и определяет классы и типы для отдельного типа изделий;
- профили защиты, определяющие номенклатуру функциональных требований безопасности и требования доверия к безопасности в зависимости от типа и класса изделия.
### ГОСТ 56939
Стандарт был принят летом 2016 и вступил в силу с 1 июля 2017 года. Разработчиком стандарта является ЗАО «НПО «ЭШЕЛОН». Целевой аудиторией стандарта являются разработчики ПО, а также организации, выполняющие оценку соответствия.
В стандарте можно выделить следующие ключевые моменты:
- Стандарт устанавливает _общие_ требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. Детали соответствующих процессов в стандартом не регламентируются.
- Меры по разработке безопасного ПО применяются в течение всего жизненного цикла ПО. Есть связь с процессами, описанными в ИСО/МЭК 12207-2010.
- Стандартом вводится базовый набор мер по разработке безопасного ПО. При невозможности реализации в среде разработки ПО отдельных мер из базового набора, разработчик имеет право реализовать компенсирующие меры.
- В стандарте предусмотрено целых 6 видов испытаний ПО: статический анализ и экспертиза кода, функциональное тестирование программы, тестирование на проникновение, динамический анализ кода и фаззинг-тестирование.
- Учитывается необходимость защиты инфраструктуры среды разработки ПО.
- Учитывается необходимость обеспечения конфиденциальности информации, получаемой в ходе анализа кода и тестирования ПО
Всего в стандарте описано 23 меры. По каждой мере четко описаны цели, результат реализации, а также требования к реализации меры (т.е. что именно нужно сделать). Радует, что все меры описаны достаточно однозначно.
"Базовый набор мер" по ГОСТ Р 56939-2016 выглядит следующим образом:
**1.** **Меры по разработке безопасного программного обеспечения, реализуемые при выполнении анализа требований к программному обеспечению:**
1.1. При выполнении анализа требований к ПО разработчик ПО должен определить требования по безопасности, предъявляемые к разрабатываемому ПО.
**2\.** **Меры по разработке безопасного программного обеспечения, реализуемые при выполнении проектирования архитектуры программы:**
2.1. Моделирование угроз безопасности информации.
2.2. Уточнение проекта архитектуры программы с учетом результатов моделирования угроз безопасности информации.
**3\.** **Меры по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения:**
3.1. Использование при разработке ПО идентифицированных инструментальных средств.
3.2. Создание программы на основе уточненного проекта архитектуры программы.
3.3. Создание (выбор) и использование при создании программы порядка оформления исходного кода программы.
3.4. Статический анализисходного кода программы.
3.5. Экспертизаисходного кода программы.
**4.** **Меры по разработке безопасного программного обеспечения, реализуемые при выполнении квалификационного тестирования программного обеспечения:**
4.1. Функциональное тестирование программы.
4.2. Тестирование на проникновение.
4.3. Динамический анализ кода программы.
4.4. Фаззинг-тестирование программы.
**5.** **Меры по разработке безопасного программного обеспечения, реализуемые при выполнении инсталляции программы и поддержки приемки программного обеспечения:**
5.1. Обеспечение защиты ПО от угроз безопасности информации, связанных с нарушением целостности в процессе его передачи пользователю.
5.2. Поставка пользователю эксплуатационных документов.
**6.** **Меры по разработке безопасного программного обеспечения, реализуемые при решении проблем в программном обеспечении в процессе эксплуатации:**
6.1. Реализация и использование процедуры отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
6.2. Систематический поиск уязвимости программы.
**7\.** **Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента документацией и конфигурацией программы:**
7.1. Реализация и использование процедуры уникальной маркировки каждой версии ПО.
7.2. Использование системы управления конфигурацией ПО.
**8.** **Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента инфраструктурой среды разработки программного обеспечения:**
8.1. Защита от несанкционированного доступа к элементам конфигурации.
8.2. Резервное копирование элементов конфигурации.
8.3. Регистрация событий, связанных с фактами изменения элементов конфигурации.
**9.** **Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента людскими ресурсами**
9.1. Периодическое обучение сотрудников.
9.2. Периодический анализ программы обучения сотрудников.
Далее рассмотрим примерный набор документов, которые должны быть в наличии в соответствии со стандартом.
- Политика информационной безопасности в соответствии с ИСО/МЭК 27001.
- Руководство по разработке безопасного ПО.
- Перечень требований по безопасности (могут быть включены в ТЗ).
- Модель угроз безопасности.
- Проект архитектуры программы (логическая структура программы).
- Перечень инструментальных средств разработки ПО.
- Описание проектных решений, обеспечивающих выполнение требований по безопасности;
- Порядок оформления исходного кода программы.
- Регламент и протоколы статического тестирования программы.
- Регламент и протоколы экспертизы исходного кода программы.
- Регламент и протоколы функционального тестирования программы.
- Регламент и протоколы тестирования на проникновение.
- Регламент и протоколы динамического анализа кода программы.
- Регламент и протоколы фаззинг-тестирования программы.
- Эксплуатационная документация.
- Регламент передачи ПО пользователю.
- Регламент отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
- Регламент приема и обработки сообщений от пользователей об ошибках ПО и уязвимостях программы.
- Регламент доведения до пользователей информации об уязвимости программы и рекомендаций по их устранению.
- Журнал ошибок и уязвимостей программы.
- Регламент экстренного выпуска обновлений ПО.
- Регламент, протоколы и журналы поиска уязвимостей программы.
- Регламент доведения до пользователей сведений об уязвимостях программы.
- Регламент маркировки версий ПО.
- Регламент управления конфигурацией ПО.
- Регламент защиты инфраструктуры среды разработки ПО.
- Регламент резервного копирования конфигурации ПО.
- Регламент регистрации событий изменений конфигурации ПО.
- Журнал регистрации изменений конфигурации ПО.
- Программа обучения сотрудников в области разработки безопасного ПО.
- Журнал обучения сотрудников в области разработки безопасного ПО.
Перечень примерный. В самом стандарте допускается компоновка документов по усмотрению разработчика.
Подводя итог, хочется отметить достоинства документа:
- продуманный набор мер, хорошее объяснение по сути каждой меры;
- разрешается использовать компенсирующие меры;
- предусмотрен широкий перечень проверок кода и тестирования ПО;
- связь с ГОСТ Р ИСО/МЭК 15408, ИСО/МЭК 12207-2010.
# Основные определения
**безопасность информации:** Состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность.
**безопасное программное обеспечение:** Программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы.
**динамический анализ кода программы:** Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
**документация разработчика программного обеспечения:** Совокупность программных документов, предназначенных для организации работ по созданию программного обеспечения, выполняемых в рамках процессов жизненного цикла программного обеспечения, и/или подтверждения соответствия требованиям настоящего стандарта.
**инструментальное средство:** Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
**компьютерная атака:** Целенаправленное несанкционированное воздействие на информацию, на ресурс автоматизированной информационной системы или получение несанкционированного доступа к ним с применением программных или программно-аппаратных средств.
**недостаток программы:** Любая ошибка, допущенная в ходе проектирования или реализации программы, которая в случае ее неисправления может являться причиной уязвимости программы.
**объект среды разработки программного обеспечения:** Аппаратные средства, программы, программно-аппаратные средства и документы, используемые разработчиком для разработки программного обеспечения.
**пользователь (программного обеспечения):** Лицо, применяющее программное обеспечение или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного обеспечения.
**программа:** Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
**программное обеспечение:** Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
**сетевая атака:** Компьютерная атака с использованием протоколов межсетевого взаимодействия.
**система управления конфигурацией программного обеспечения:** Совокупность процедур и инструментальных средств (включая их документацию), используемая разработчиком программного обеспечения для разработки и поддержки конфигураций программного обеспечения в течение его жизненного цикла.
**среда разработки программного обеспечения:** Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения.
**статический анализ исходного кода программы:** Вид работ по инструментальному исследованию программы, основанный на анализе исходного кода программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем реального выполнения кода.
**тестирование на проникновение:** Вид работ по выявлению (подтверждению) уязвимостей программы, основанный на моделировании (имитации) действий потенциального нарушителя.
**угроза (безопасности информации):** Совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации.
**управление конфигурацией программного обеспечения:** Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.
**уязвимость программы:** Недостаток программы, который может быть использован для реализации угроз безопасности информации.
**функциональное тестирование программы:** Вид работ по исследованию программы, направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
**фаззинг-тестирование программы:** Вид работ по исследованию программы, направленный на оценку ее свойств и основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
**экспертиза исходного кода программы:** Вид работ по выявлению недостатков программы (потенциально уязвимых конструкций) в исходном коде программы, основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода.
**электронный документ:** Документ, выполненный программно-техническим средством на электронном носителе.
**элемент конфигурации:** Объект конфигурации, выполняющий законченную функцию.
### Разработка программного обеспечения в целом
Обзор разработки программного обеспечения
=========================================
Давайте сначала поймем, что означает разработка программного обеспечения. Термин состоит из двух слов, программного обеспечения и техники.
**Программное обеспечение** – это больше, чем просто программный код. Программа представляет собой исполняемый код, который выполняет некоторые вычислительные задачи. Программное обеспечение считается коллекцией исполняемого программного кода, связанных библиотек и документации. Программное обеспечение, если оно изготовлено для конкретного требования, называется **программным продуктом.**
**С** другой стороны, **инжиниринг** – это разработка продуктов с использованием четко определенных научных принципов и методов.
**Программная инженерия** – это инженерная отрасль, связанная с разработкой программного продукта с использованием четко определенных научных принципов, методов и процедур. Результатом разработки программного обеспечения является эффективный и надежный программный продукт.
Определения
-----------
IEEE определяет разработку программного обеспечения как:
> (1) Применение систематического, дисциплинированного, количественного подхода к разработке, эксплуатации и обслуживанию программного обеспечения; то есть применение техники к программному обеспечению.
>
> (2) Изучение подходов, как в приведенном выше утверждении.
(1) Применение систематического, дисциплинированного, количественного подхода к разработке, эксплуатации и обслуживанию программного обеспечения; то есть применение техники к программному обеспечению.
(2) Изучение подходов, как в приведенном выше утверждении.
Фриц Бауэр, немецкий программист, определяет разработку программного обеспечения как:
> Программная инженерия – это создание и использование принципов звуковой инженерии для получения экономически выгодного программного обеспечения, которое эффективно работает на реальных машинах.
Программная инженерия – это создание и использование принципов звуковой инженерии для получения экономически выгодного программного обеспечения, которое эффективно работает на реальных машинах.
Эволюция программного обеспечения
---------------------------------
Процесс разработки программного продукта с использованием принципов и методов разработки программного обеспечения называется **эволюцией программного обеспечения.** Это включает в себя первоначальную разработку программного обеспечения, его обслуживание и обновление до тех пор, пока не будет разработан желаемый программный продукт, который удовлетворяет ожидаемым требованиям.
Эволюция начинается с процесса сбора требований. После чего разработчики создают прототип предполагаемого программного обеспечения и показывают его пользователям, чтобы получить их отзывы на ранней стадии разработки программного продукта. Пользователи предлагают изменения, по которым несколько последовательных обновлений и обслуживания также продолжают изменяться. Этот процесс изменяется на исходное программное обеспечение, пока не будет выполнено желаемое программное обеспечение.
Даже после того, как пользователь получил желаемое программное обеспечение, передовая технология и изменяющиеся требования вынуждают программный продукт соответствующим образом меняться. Пересоздать программное обеспечение с нуля и идти один на один с требованием невозможно. Единственное возможное и экономичное решение – обновить существующее программное обеспечение, чтобы оно соответствовало последним требованиям.
Законы об эволюции программного обеспечения
-------------------------------------------
Lehman дал законы для развития программного обеспечения. Он разделил программное обеспечение на три категории:
- **S-тип (статический тип) –** это программное обеспечение, которое работает строго в соответствии с определенными спецификациями и решениями. Решение и способ его достижения сразу же понимаются перед кодированием. Программное обеспечение s-типа меньше всего подвержено изменениям, поэтому это самое простое из всех. Например, программа-калькулятор для математических вычислений.
- **P-тип (практический тип) –** это программное обеспечение с набором процедур. Это определяется именно тем, что могут делать процедуры. В этом программном обеспечении спецификации могут быть описаны, но решение не очевидно сразу. Например, игровое программное обеспечение.
- **Электронный тип (встроенный) –** это программное обеспечение тесно связано с требованиями реальной среды. Это программное обеспечение имеет высокую степень эволюции, поскольку в реальных ситуациях происходят различные изменения в законах, налогах и т. Д. Например, программное обеспечение для онлайн-торговли.
Эволюция программного обеспечения E-Type
----------------------------------------
Lehman дал восемь законов развития программного обеспечения E-Type –
- **Продолжающиеся изменения.** Программная система электронного типа должна продолжать адаптироваться к изменениям реального мира, иначе она становится все менее полезной.
- **Возрастающая сложность.** По мере развития системы программного обеспечения типа E ее сложность возрастает, если не проводится работа по ее обслуживанию или уменьшению.
- **Сохранение фамильярности –** знакомство с программным обеспечением или знание о том, как оно разрабатывалось, почему оно разрабатывалось именно таким образом и т. Д., Должно сохраняться любой ценой для реализации изменений в системе.
- **Продолжающийся рост.** Для того, чтобы система E-типа предназначалась для решения какой-либо бизнес-проблемы, ее размер для реализации изменений увеличивается в соответствии с изменениями образа жизни бизнеса.
- **Снижение качества.** Система программного обеспечения типа E ухудшает качество, если не будет тщательно поддерживаться и адаптироваться к изменяющейся операционной среде.
- Системы обратной связи. Программные системы E-типа представляют собой многоконтурные многоуровневые системы обратной связи и должны рассматриваться как таковые, чтобы успешно модифицироваться или улучшаться.
- **Саморегулирование –** процессы эволюции системы E-типа являются саморегулируемыми с распределением продуктов и мер, близких к нормальным.
- **Организационная стабильность** . Средний эффективный глобальный уровень активности в развивающейся системе электронного типа не меняется в течение срока службы продукта.
Программные парадигмы
---------------------
Программные парадигмы относятся к методам и шагам, которые предпринимаются при разработке программного обеспечения. Есть много методов, предложенных и работающих в настоящее время, но мы должны увидеть, где эти парадигмы стоят в разработке программного обеспечения. Они могут быть объединены в различные категории, хотя каждая из них содержится в одной:
Парадигма программирования – это подмножество парадигмы разработки программного обеспечения, которая является еще одним подмножеством парадигмы разработки программного обеспечения.
### Парадигма разработки программного обеспечения
Эта парадигма известна как парадигма разработки программного обеспечения, в которой применяются все инженерные концепции, относящиеся к разработке программного обеспечения. Он включает в себя различные исследования и сбор требований, которые помогают построить программный продукт. Это состоит из –
- Сбор требований
- Разработка программного обеспечения
- программирование
### Парадигма разработки программного обеспечения
Эта парадигма является частью разработки программного обеспечения и включает в себя –
- дизайн
- техническое обслуживание
- программирование
### Парадигма программирования
Эта парадигма тесно связана с программным аспектом разработки программного обеспечения. Это включает –
- кодирование
- тестирование
- интеграция
Необходимость разработки программного обеспечения
-------------------------------------------------
Необходимость разработки программного обеспечения возникает из-за более высокой скорости изменения требований пользователя и среды, в которой работает программное обеспечение.
- **Большое программное обеспечение.** Построить стену легче, чем дом или здание, так же, как размер программного обеспечения становится большим, и инжиниринг должен сделать научный процесс.
- **Масштабируемость –** если процесс программного обеспечения не основывается на научных и технических концепциях, было бы легче воссоздать новое программное обеспечение, чем масштабировать существующее.
- **Затраты.** Поскольку индустрия оборудования продемонстрировала свое мастерство, а огромное производство снизило цены на компьютерное и электронное оборудование. Но стоимость программного обеспечения остается высокой, если надлежащий процесс не адаптирован.
- **Динамическая природа** . Постоянно растущая и адаптирующаяся природа программного обеспечения в значительной степени зависит от среды, в которой работает пользователь. Если природа программного обеспечения постоянно меняется, необходимо внести новые улучшения в существующий. Это где разработка программного обеспечения играет хорошую роль.
- **Управление качеством –** лучший процесс разработки программного обеспечения обеспечивает лучший и качественный программный продукт.
Характеристики хорошего программного обеспечения
------------------------------------------------
О программном продукте можно судить по тому, что он предлагает и насколько хорошо его можно использовать. Это программное обеспечение должно удовлетворять следующим основаниям:
- эксплуатационный
- переходный
- техническое обслуживание
Ожидается, что хорошо спроектированное и созданное программное обеспечение будет иметь следующие характеристики:
### эксплуатационный
Это говорит нам, насколько хорошо программное обеспечение работает в операциях. Это может быть измерено на:
- бюджет
- Юзабилити
- КПД
- правильность
- функциональность
- надежность
- Безопасность
- безопасности
### переходный
Этот аспект важен, когда программное обеспечение перемещается с одной платформы на другую:
- портативность
- Interoperability
- Повторное использование
- адаптируемость
### техническое обслуживание
В этом аспекте кратко описывается, насколько хорошо программное обеспечение способно поддерживать себя в постоянно меняющейся среде:
- модульность
- Ремонтопригодность
- гибкость
- Масштабируемость
Короче говоря, разработка программного обеспечения – это отрасль компьютерных наук, которая использует четко определенные концепции разработки, необходимые для создания эффективных, надежных, масштабируемых, бюджетных и своевременных программных продуктов.
Жизненный цикл разработки программного обеспечения
==================================================
Жизненный цикл разработки программного обеспечения, для краткости SDLC, представляет собой четко определенную, структурированную последовательность этапов разработки программного обеспечения для разработки предполагаемого программного продукта.
Деятельность SDLC
-----------------
SDLC предлагает ряд шагов, которые необходимо выполнить для эффективной разработки и разработки программного продукта. Каркас SDLC включает в себя следующие этапы:
### связь
Это первый шаг, когда пользователь инициирует запрос на желаемый программный продукт. Он связывается с поставщиком услуг и пытается договориться об условиях. Он подает свой запрос в организацию, предоставляющую услуги, в письменном виде.
### Сбор требований
Этот шаг вперед команда разработчиков программного обеспечения работает над продолжением проекта. Команда проводит дискуссии с различными заинтересованными сторонами из проблемной области и старается предоставить как можно больше информации об их требованиях. Требования рассматриваются и разделяются на пользовательские требования, системные требования и функциональные требования. Требования собраны с использованием ряда методов, как указано –
- изучение существующей или устаревшей системы и программного обеспечения,
- проведение опросов пользователей и разработчиков,
- ссылаясь на базу данных или
- Сбор ответов из анкет.
### Технико-экономическое обоснование
После сбора требований команда разрабатывает примерный план процесса разработки программного обеспечения. На этом этапе команда анализирует, можно ли создать программное обеспечение для удовлетворения всех требований пользователя и существует ли вероятность того, что программное обеспечение больше не будет полезным. Выясняется, является ли проект финансово, практически и технологически осуществимым для организации. Существует множество доступных алгоритмов, которые помогают разработчикам сделать вывод о целесообразности программного проекта.
### Системный анализ
На этом этапе разработчики решают план своего плана и стараются найти лучшую модель программного обеспечения, подходящую для проекта. Системный анализ включает в себя понимание ограничений программного продукта, проблем, связанных с системой обучения, или изменений, которые необходимо сделать в существующих системах, заранее, выявление и учет воздействия проекта на организацию и персонал и т. Д. Команда проекта анализирует масштаб проекта и планирует график и ресурсы соответственно.
### Разработка программного обеспечения
Следующим шагом является полное знание требований и анализа на столе и разработка программного продукта. Входные данные от пользователей и информация, собранная на этапе сбора требований, являются входными данными этого этапа. Результат этого шага представлен в виде двух проектов; логический дизайн и физический дизайн. Инженеры производят метаданные и словари данных, логические диаграммы, диаграммы потоков данных и в некоторых случаях псевдокоды.
### кодирование
Этот шаг также известен как этап программирования. Реализация разработки программного обеспечения начинается с написания программного кода на подходящем языке программирования и эффективной разработки безошибочных исполняемых программ.
### тестирование
По оценкам, 50% всего процесса разработки программного обеспечения должно быть проверено. Ошибки могут испортить программное обеспечение с критического уровня до его удаления. Тестирование программного обеспечения выполняется разработчиками во время кодирования, а тщательное тестирование проводится экспертами на разных уровнях кода, таких как тестирование модулей, тестирование программ, тестирование продукта, внутреннее тестирование и тестирование продукта на стороне пользователя. Раннее обнаружение ошибок и их устранение – ключ к надежному программному обеспечению.
### интеграция
Может потребоваться интеграция программного обеспечения с библиотеками, базами данных и другими программами. Этот этап SDLC связан с интеграцией программного обеспечения с объектами внешнего мира.
### Реализация
Это означает установку программного обеспечения на компьютерах пользователей. Иногда программное обеспечение нуждается в настройках после установки на стороне пользователя. Программное обеспечение тестируется на мобильность и адаптивность, а проблемы, связанные с интеграцией, решаются в ходе реализации.
### Эксплуатация и техническое обслуживание
Этот этап подтверждает работу программного обеспечения с точки зрения большей эффективности и меньшего количества ошибок. При необходимости пользователи проходят обучение или получают помощь по документации о том, как работать с программным обеспечением и как его поддерживать. Программное обеспечение поддерживается своевременно путем обновления кода в соответствии с изменениями, происходящими в пользовательской среде или технологии. Эта фаза может столкнуться с проблемами из-за скрытых ошибок и реальных неопознанных проблем.
### диспозиция
С течением времени программное обеспечение может ухудшиться в плане производительности. Это может полностью устареть или может потребовать интенсивного обновления. Следовательно возникает насущная необходимость устранить основную часть системы. Этот этап включает в себя архивирование данных и необходимых программных компонентов, закрытие системы, планирование действий по утилизации и завершение работы системы в соответствующее время окончания системы.
Парадигма разработки программного обеспечения
---------------------------------------------
Парадигма разработки программного обеспечения помогает разработчику выбрать стратегию разработки программного обеспечения. Парадигма разработки программного обеспечения имеет свой собственный набор инструментов, методов и процедур, которые четко выражены и определяют жизненный цикл разработки программного обеспечения. Несколько парадигм разработки программного обеспечения или моделей процессов определены следующим образом:
### Модель водопада
Модель «Водопад» – самая простая модель парадигмы разработки программного обеспечения. В нем говорится, что все фазы SDLC будут функционировать один за другим линейно. То есть, когда первая фаза закончена, тогда только вторая фаза начнется и так далее.
Эта модель предполагает, что все выполнено и выполнено идеально, как и планировалось на предыдущем этапе, и нет необходимости думать о прошлых проблемах, которые могут возникнуть на следующем этапе. Эта модель не работает гладко, если на предыдущем шаге остались некоторые проблемы. Последовательный характер модели не позволяет нам вернуться назад и отменить или повторить наши действия.
Эта модель лучше всего подходит, когда разработчики уже проектировали и разрабатывали подобное программное обеспечение в прошлом и знают все его области.
### Итерационная модель
Эта модель ведет процесс разработки программного обеспечения в итерациях. Он проектирует процесс разработки циклически, повторяя каждый шаг после каждого цикла процесса SDLC.
Программное обеспечение сначала разрабатывается в очень небольших масштабах, и выполняются все этапы, которые принимаются во внимание. Затем на каждой следующей итерации все больше функций и модулей разрабатываются, кодируются, тестируются и добавляются в программное обеспечение. Каждый цикл производит программное обеспечение, которое само по себе полно и имеет больше возможностей и возможностей, чем в предыдущем.
После каждой итерации управленческая команда может выполнить работу по управлению рисками и подготовиться к следующей итерации. Поскольку цикл включает в себя небольшую часть всего процесса разработки программного обеспечения, легче управлять процессом разработки, но он потребляет больше ресурсов.
### Спиральная модель
Спиральная модель представляет собой комбинацию итерационной модели и модели SDLC. Это может выглядеть так, как будто вы выбираете одну модель SDLC и комбинируете ее с циклическим процессом (итерационная модель).
Эта модель учитывает риск, который часто остается незамеченным большинством других моделей. Модель начинается с определения целей и ограничений программного обеспечения в начале одной итерации. Следующим этапом является создание прототипа программного обеспечения. Это включает в себя анализ рисков. Затем для построения программного обеспечения используется одна стандартная модель SDLC. На четвертом этапе готовится план следующей итерации.
### V – модель
Основным недостатком модели водопада является то, что мы переходим к следующему этапу только тогда, когда предыдущий завершен, и не было возможности вернуться назад, если что-то будет найдено неправильно на более поздних этапах. V-модель предоставляет средства тестирования программного обеспечения на каждом этапе в обратном порядке.
На каждом этапе создаются планы тестирования и тестовые наборы для проверки и валидации продукта в соответствии с требованиями этого этапа. Например, на этапе сбора требований группа тестирования подготавливает все контрольные примеры в соответствии с требованиями. Позже, когда продукт будет разработан и готов к тестированию, контрольные примеры этого этапа проверяют программное обеспечение на соответствие требованиям на данном этапе.
Это позволяет и проверке, и проверке идти параллельно. Эта модель также известна как модель верификации и валидации.
### Модель большого взрыва
Эта модель является самой простой моделью по форме. Это требует мало планирования, много программирования и много средств. Эта модель концептуализирована вокруг большого взрыва вселенной. Как говорят ученые, после большого взрыва множество галактик, планет и звезд эволюционировали как событие. Аналогично, если мы соберем много программ и средств, вы сможете получить лучший программный продукт.
Для этой модели требуется очень небольшое количество планирования. Это не следует ни за каким процессом, или время от времени клиент не уверен в требованиях и будущих потребностях. Таким образом, входные требования являются произвольными.
Эта модель не подходит для больших программных проектов, но хороша для обучения и экспериментов.
Для подробного изучения SDLC и его различных моделей, [нажмите здесь.](https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.ru&sl=en&sp=nmt4&tl=ru&u=http://www.tutorialspoint.com/sdlc/index.htm&xid=17259,15700022,15700186,15700190,15700256,15700259,15700262&usg=ALkJrhjd0ijMADyxFtwZsOQyRVMq7kf3tg)
Управление проектами программного обеспечения
=============================================
Структура работы ИТ-компании, занимающейся разработкой программного обеспечения, можно разделить на две части:
- Создание программного обеспечения
- Управление проектами программного обеспечения
Проект – это четко определенная задача, представляющая собой совокупность нескольких операций, выполняемых для достижения цели (например, разработка и поставка программного обеспечения). Проект можно охарактеризовать как:
- Каждый проект может иметь уникальную и особую цель.
- Проект не является рутинной деятельностью или повседневными операциями.
- Проект поставляется с временем начала и окончания.
- Проект заканчивается, когда его цель достигнута, следовательно, это временный этап в жизни организации.
- Проекту необходимы адекватные ресурсы с точки зрения времени, рабочей силы, финансов, материалов и банка знаний.
Программный проект
------------------
Программный проект – это полная процедура разработки программного обеспечения от сбора требований до тестирования и обслуживания, выполняемая в соответствии с методологиями выполнения, в течение определенного периода времени для достижения предполагаемого программного продукта.
Необходимость управления программным проектом
---------------------------------------------
Программное обеспечение считается нематериальным продуктом. Разработка программного обеспечения является своего рода новым потоком в мировом бизнесе, и у нас очень мало опыта в создании программных продуктов. Большинство программных продуктов разработаны с учетом требований клиента. Наиболее важным является то, что базовая технология изменяется и развивается настолько часто и быстро, что опыт одного продукта может не применяться к другому. Все такие деловые и экологические ограничения создают риск при разработке программного обеспечения, поэтому крайне важно эффективно управлять программными проектами.
Изображение выше показывает тройные ограничения для программных проектов. Это важная часть организации программного обеспечения для предоставления качественного продукта, сохранения затрат в рамках бюджета клиента и выполнения проекта в соответствии с графиком. Существует несколько факторов, как внутренних, так и внешних, которые могут повлиять на этот треугольник тройного ограничения. Любой из трех факторов может серьезно повлиять на два других.
Следовательно, управление проектами программного обеспечения имеет важное значение для учета требований пользователей, а также бюджета и временных ограничений.
Менеджер программных проектов
-----------------------------
Менеджер проекта программного обеспечения – это человек, который берет на себя ответственность за выполнение проекта программного обеспечения. Менеджер проекта программного обеспечения полностью осведомлен обо всех этапах SDLC, которые должно пройти программное обеспечение. Менеджер проекта может никогда напрямую не участвовать в производстве конечного продукта, но он контролирует и управляет деятельностью, связанной с производством.
Менеджер проекта внимательно следит за процессом разработки, готовит и выполняет различные планы, организует необходимые и адекватные ресурсы, поддерживает связь между всеми членами команды для решения вопросов стоимости, бюджета, ресурсов, времени, качества и удовлетворенности клиентов.
Давайте посмотрим, какие обязанности несет руководитель проекта –
### Управление людьми
- Выступать в качестве руководителя проекта
- Уход с заинтересованными сторонами
- Управление человеческими ресурсами
- Настройка иерархии отчетов и т. Д.
### Управление проектом
- Определение и настройка масштаба проекта
- Управление деятельностью по управлению проектами
- Мониторинг прогресса и производительности
- Анализ рисков на каждом этапе
- Сделайте необходимый шаг, чтобы избежать или выйти из проблем
- Выступать в качестве представителя проекта
Деятельность по управлению программным обеспечением
---------------------------------------------------
Управление программным проектом включает в себя ряд мероприятий, которые включают планирование проекта, определение объема программного продукта, оценку стоимости в различных терминах, планирование задач и событий и управление ресурсами. Деятельность по управлению проектом может включать в себя:
- **Планирование проекта**
- **Управление областью**
- **Оценка проекта**
Планирование проекта
--------------------
Планирование проекта программного обеспечения – это задача, которая выполняется до фактического начала производства программного обеспечения. Он существует для производства программного обеспечения, но не включает никакой конкретной деятельности, которая имеет какое-либо отношение к производству программного обеспечения; скорее это набор из нескольких процессов, который облегчает производство программного обеспечения. Планирование проекта может включать в себя следующее:
Управление областью
-------------------
Определяет масштаб проекта; это включает в себя все действия, процесс должен быть выполнен, чтобы сделать поставляемый программный продукт. Сфера управления очень важна, потому что она создает границы проекта, четко определяя, что будет сделано в проекте, а что нет. Это заставляет проект содержать ограниченные и измеримые задачи, которые могут быть легко задокументированы и, в свою очередь, позволяют избежать перерасхода средств и времени.
Во время управления содержанием проекта необходимо:
- Определите сферу
- Решите его проверку и контроль
- Разделите проект на различные более мелкие части для удобства управления.
- Проверьте область
- Управляйте областью, внося изменения в область
Оценка проекта
--------------
Для эффективного управления точная оценка различных мер является обязательным. При правильной оценке менеджеры могут управлять проектом более эффективно и результативно.
Оценка проекта может включать в себя следующее:
- **Оценка размера программного обеспечения**
Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.
- **Оценка усилий**
Менеджеры оценивают усилия с точки зрения потребности в персонале и человеко-часов, необходимых для производства программного обеспечения. Для оценки усилий должен быть известен размер программного обеспечения. Это может быть получено из опыта менеджеров, исторические данные организации или размер программного обеспечения могут быть преобразованы в усилия с использованием некоторых стандартных формул.
- **Оценка времени**
Как только размер и усилия оценены, можно оценить время, необходимое для производства программного обеспечения. Требуемые усилия подразделяются на подкатегории в соответствии со спецификациями требований и взаимозависимостью различных компонентов программного обеспечения. Задачи программного обеспечения подразделяются на более мелкие задачи, действия или события с помощью Work Breakthrough Structure (WBS). Задачи запланированы на ежедневной основе или в календарных месяцах.
Сумма времени, необходимого для выполнения всех задач в часах или днях, – это общее время, потраченное на завершение проекта.
- **Оценка затрат**
Это может считаться самым сложным из всех, потому что это зависит от большего количества элементов, чем любой из предыдущих. Для оценки стоимости проекта необходимо учитывать –
- Размер программного обеспечения
- Качество программного обеспечения
- аппаратные средства
- Дополнительное программное обеспечение или инструменты, лицензии и т. Д.
- Квалифицированный персонал с конкретными навыками
- Путешествие участвует
- связь
- Обучение и поддержка
Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.
Менеджеры оценивают усилия с точки зрения потребности в персонале и человеко-часов, необходимых для производства программного обеспечения. Для оценки усилий должен быть известен размер программного обеспечения. Это может быть получено из опыта менеджеров, исторические данные организации или размер программного обеспечения могут быть преобразованы в усилия с использованием некоторых стандартных формул.
Как только размер и усилия оценены, можно оценить время, необходимое для производства программного обеспечения. Требуемые усилия подразделяются на подкатегории в соответствии со спецификациями требований и взаимозависимостью различных компонентов программного обеспечения. Задачи программного обеспечения подразделяются на более мелкие задачи, действия или события с помощью Work Breakthrough Structure (WBS). Задачи запланированы на ежедневной основе или в календарных месяцах.
Сумма времени, необходимого для выполнения всех задач в часах или днях, – это общее время, потраченное на завершение проекта.
Это может считаться самым сложным из всех, потому что это зависит от большего количества элементов, чем любой из предыдущих. Для оценки стоимости проекта необходимо учитывать –
Методы оценки проекта
---------------------
Мы обсудили различные параметры, связанные с оценкой проекта, такие как размер, усилия, время и стоимость.
Менеджер проекта может оценить перечисленные факторы, используя два широко признанных метода –
### Техника Разложения
Эта методика предполагает использование программного обеспечения как продукта различных композиций.
Есть две основные модели –
- Оценка **строки кода** производится от имени ряда строк кода в программном продукте.
- Оценка **функциональных точек** выполняется от имени количества функциональных точек в программном продукте.
### Методика эмпирической оценки
Этот метод использует эмпирически полученные формулы для оценки. Эти формулы основаны на LOC или FP.
- **Модель Putnam**
Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.
- **COCOMO**
COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.
Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.
COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.
Планирование проекта
--------------------
Планирование проекта в проекте относится к дорожной карте всех действий, которые должны быть выполнены с указанным порядком и в пределах временного интервала, выделенного для каждого действия. Менеджеры проектов, как правило, имеют тенденцию определять различные задачи, и основные этапы проекта, и они организуют их с учетом различных факторов. Они ищут задачи, лежащие на критическом пути в расписании, которые необходимо выполнить определенным образом (из-за взаимозависимости задач) и строго в отведенное время. Расположение задач, лежащих вне критического пути, с меньшей вероятностью повлияет на весь график проекта.
Для составления расписания проекта необходимо:
- Разбейте задачи проекта на меньшую, управляемую форму
- Узнайте различные задачи и соотнесите их
- Расчет времени, необходимого для каждой задачи
- Разделите время на рабочие единицы
- Назначьте достаточное количество рабочих единиц для каждой задачи
- Рассчитать общее время, необходимое для проекта от начала до конца
Управление ресурсами
--------------------
Все элементы, используемые для разработки программного продукта, могут рассматриваться как ресурсы для этого проекта. Это может включать человеческие ресурсы, продуктивные инструменты и библиотеки программного обеспечения.
Ресурсы доступны в ограниченном количестве и остаются в организации в виде пула активов. Нехватка ресурсов тормозит развитие проекта и может отставать от графика. Выделение дополнительных ресурсов в конечном итоге увеличивает стоимость разработки. Поэтому необходимо оценить и выделить адекватные ресурсы для проекта.
Управление ресурсами включает в себя –
- Определение правильного организационного проекта путем создания команды проекта и распределения обязанностей для каждого члена команды
- Определение ресурсов, необходимых на определенном этапе, и их доступность
- Управляйте ресурсами, генерируя запрос ресурсов, когда они требуются, и отменяя их распределение, когда они больше не нужны.
Управление рисками проекта
--------------------------
Управление рисками включает в себя все действия, связанные с идентификацией, анализом и обеспечением предсказуемых и непредсказуемых рисков в проекте. Риск может включать в себя следующее:
- Опытный персонал, покидающий проект, и новый персонал.
- Изменения в организационном управлении.
- Изменение требования или неверное толкование требования.
- Недооценка необходимого времени и ресурсов.
- Технологические изменения, экологические изменения, деловая конкуренция.
Процесс управления рисками
--------------------------
В процессе управления рисками участвуют следующие виды деятельности:
- **Идентификация –** запишите все возможные риски, которые могут возникнуть в проекте.
- **Категоризировать –** классифицировать известные риски по высокой, средней и низкой интенсивности риска в соответствии с их возможным влиянием на проект.
- **Управлять –** анализировать вероятность возникновения рисков на разных этапах. Составьте план, чтобы избежать или столкнуться с рисками. Попытайтесь минимизировать их побочные эффекты.
- **Монитор –** внимательно отслеживать потенциальные риски и их ранние симптомы. Также следите за последствиями шагов, предпринятых для смягчения или предотвращения их.
{"metaMigratedAt":"2023-06-15T19:45:08.560Z","metaMigratedFrom":"Content","title":"Глава 1. Введение. Понятие безопасной разработки программного обеспечения","breaks":true,"contributors":"[{\"id\":\"28bdeb02-22a2-4b6a-9a15-1e260764592e\",\"add\":101049,\"del\":1149}]"}