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

1.

О стандартизации программного
обеспечения
СТУДЕНТ ГР.ИБ-21
Телятниченко Федор

2.

Цель и задачи доклада
Цель доклада:
1. Ознакомиться с процессом стандартизации ПО в
РФ.
Задачи:
1. Рассмотреть жизненный цикл ПО
2. Ознакомиться с требованиями к осуществлению
разработки ПО

3.

Понятие о жизненного цикла программной
системы
Жизненный цикл ПС – период времени, включающий в себя стадии: разработки
требований к программному обеспечению, разработки программного обеспечения,
кодирования, тестирования, интеграции, установки, а также стадию модификации (по
ГОСТ Р 53195.4-2010).

4.

Стадии создания автоматизированной системы
Автоматизированная система – система, состоящая из персонала и
комплекса средств автоматизации, реализующая технологию выполнения
установленных функций (определение по ГОСТ 34.003-90).
Стадии создания согласно ГОСТ 34.601-90:
• формирование требований к АС;
• разработка концепции АС;
• техническое задание (ГОСТ 34.602-89);
• эскизный проект;
• технический проект;
• рабочая документация;
• ввод в действие;
• сопровождение АС.

5.

Стандарты в области оценки качества
программных продуктов
ГОСТ 28195-89
Оценка качества программных средств. Общие положения.
ГОСТ 28806-90
Качество программных средств. Термины и определения.
ГОСТ Р 51904-2002
Общие требования к разработке и документированию.

6.

Категории отказных ситуаций
Категория Е: Невлияющая отказная ситуация, которая не влияет на
эксплуатационные возможности объекта управления или не увеличивает
рабочую нагрузку персонала.
Категория D: Несущественная отказная ситуация, которая приводит к
деградации производительности или функциональности объекта
управления, но не приводит к его отказу.
Категория C: Существенная отказная ситуация, которая приводит к
значительному снижению производительности или функциональности
объекта управления, но не приводит к его полному отказу.
Категория B: Опасная/критическая отказная ситуация, которая приводит к
частичному или полному отказу объекта управления, но не приводит к его
полному разрушению.
Категория A: Катастрофическая отказная ситуация, которая приводит к
полному отказу объекта управления и его разрушению..
6

7.

Уровни ПО
Уровень A: ПО, аномальное поведение которого может привести к
катастрофической отказной ситуации.
Уровень B: ПО, аномальное поведение которого может привести к
опасной/критической отказной ситуации.
Уровень C: ПО, аномальное поведение которого может привести к
существенной отказной ситуации.
Уровень D: ПО, аномальное поведение которого может привести к
несущественной отказной ситуации.
Уровень E: ПО, аномальное поведение которого не влияет на
эксплуатационные возможности объекта и работоспособность персонала.

8.

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

9.

Анализ требований к системе.
Разработчик должен участвовать в анализе требований к системе.
1. Анализ должен включать:
○ Анализ информации о потребностях пользователя
○ Определение эксплуатационной концепции
○ Разработку спецификации системы/подсистемы
○ Требования к модифицируемому пользователем ПО, ПО с
возможностью выбора вариантов и коммерчески
доступному ПО.
○ Требования к ПО, загружаемому в полевых условиях.

10.

Проектировании системы.
Разработчик должен участвовать в проектировании
системы.
1. Проектирование должно включать:
○ Определение проектных решений системного уровня
○ Разработку проекта архитектуры системы
2. Стратегии архитектурного проектирования системы:
○ Разбиение
○ Многоверсионное неидентичное ПО
○ Мониторинг безопасности

11.

Библиотека разработки ПО
Разработчик должен создать, контролировать
и сопровождать Библиотеку разработки ПО.
1. Библиотека разработки ПО должна
содержать:
● Шаблоны документов
● Инструменты разработки
● Стандарты кодирования
● Руководства по тестированию

12.

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

13.

Результаты по проделанной работе
1. Рассмотрели жизненный цикл ПО
2. Ознакомились с требованиями по
разработке ПО

14.

Список использованных источников
● ГОСТ 34.601-90
● ГОСТ 34.602-8
● ГОСТ 28195-89
● ГОСТ Р 51904-2002

15.

Спасибо за внимание