Стандарты и шаблоны для ТЗ на разработку ПО

Содержание

Анализ и проектирование систем

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • ГОСТ 34 • ГОСТ 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы. Согласно ГОСТ 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6. Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9. Источники разработки При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО. Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы: 1. Введение; 2. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5. Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9. Приложения. Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий. Согласно стандарту техническое задание должно включать следующие разделы: 1. Введение

  • 1. Назначение
  • 2. Область действия
  • 3. Определения, акронимы и сокращения
  • 4. Ссылки
  • 5. Краткий обзор

2. Общее описание

  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователя
  • 4. Ограничения
  • 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3. Требования к производительности
  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998. Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34. SyRS может содержать следующие разделы: 1. Введение

  • 1. Назначение системы
  • 2. Содержание системы (границы системы)
  • 3. Обзор системы
    • 1. Содержание системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки 3. Системные требования

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1. Введение

  • 1. Назначение
  • 2. Содержание (границы)
    • 3. Обзор продукта
    • 1. Взаимодействие продукта (с другими продуктами и компонентами)
    • 2. Функции продукта (краткое описание)
    • 3. Характеристики пользователей
    • 4. Ограничения
  • 4. Термины и определения

2. Ссылки 3. Детальные требования

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований. Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта: • Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

  • 1. Цель.
  • 2. Краткая сводка возможностей.
  • 3. Определения, акронимы и сокращения.
  • 4. Ссылки.
  • 5. Краткое содержание.

2. Обзор системы

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

3. Детальные требований

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

4. Вспомогательная информация. Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты. Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя. Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО. Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA). Также рекомендую ознакомиться со следующими материалами:

  • Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
  • Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
  • Правила составления Software requirements specification (читать вместе с комментариями)
  • Примеры ТЗ и другой документации по разработке АС для МЭР
  • ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
  • Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

1.jpg

Введение

Какие бывают ГОСТы?

  1. Международные стандарты (ISO, IEEE Std);
  2. Российские или Советские ГОСТы.

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

  1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» — стандарт для написания руководства пользователя;
  2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» — стандарт для написания технического описания программы;
  3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» — ещё один стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Так сказать, это больше похоже на руководство по написанию руководства пользователя. Начинающим специалистам будет особенно полезен;
  4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» — ещё один стандарт для дизайнеров и разработчиков пользователей документации.

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

Российские стандарты Российские стандарты разрабатываются на государственном уровне. Они все абсолютно бесплатны и каждый из них легко найти в интернете. Для написания документации на программу используются две серии ГОСТов 19 и 34. Именно о них и будет идти речь дальше.

Чем отличаются ГОСТы серий 19 и 34?

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

В ГОСТе 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» указано определение:

  1. Организационное;
  2. Методическое;
  3. Техническое;
  4. Математическое;
  5. Программное обеспечение;
  6. Информационное;
  7. Лингвистическое;
  8. Правовое;
  9. Эргономическое.

ГОСТ 34

Серия ГОСТов 34 (ГОСТ 34.ххх Стандарты информационной технологии) состоит:

  1. ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем — данный стандарт устанавливает виды, наименование, комплектность и номера документов. Является одним из основных документов серии ГОСТов 34. По сути, это базовый документ, так что новичкам необходимо ознакомиться с ним в первую очередь.
  2. ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы — настоящий стандарт устанавливает основные понятия и термины концептуальных схем и информационных баз, охватывающие разработку, описание и применение концептуальных схем и информационных баз, манипулирования информацией, а также описание и реализацию информационного процесса. Стандарт определяет роль концептуальной схемы. Положения, изложенные в нём, носят рекомендательный характер и могут использоваться для оценки систем управления базами данных (СУБД). Этот документ не описывает конкретные методы применения средств поддержки концептуальных схем. Описанные в стандарте языки концептуальных схем не следует рассматривать как стандартные.
  3. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания — стандарт устанавливает стадии и этапы создания АС.
  4. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем — стандарт устанавливает виды испытаний АС автономные, комплексные, приёмочные испытаний и опытная эксплуатация) и общие требования к их проведению.
  5. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов — один из важнейших документов 34 ГОСТа, так как именно в нём описано содержание практически всех документов, а также описание каждого пункта документа.
  6. ГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один — настоящий стандарт является частью абстрактной синтаксической нотации версии 1 (АСН.1) и устанавливает нотацию для спецификации ограничений, определённых пользователем, и табличных ограничений.
  7. ГОСТ Р ИСО/МЭК 10746-3-2001 Управление данными и открытая распределённая обработка. В настоящем стандарте:
    • определено, как специфицируются системы открытой распределённой обработки (ОРО) с использованием понятий, введённых в ГОСТ Р ИСО/МЭК 10746-2;
    • идентифицированы характеристики, по которым системы относятся к системам ОРО.

    В стандарте установлен каркас для координации разработки стандартов по системам ОРО.

    </ul>

  8. ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства — определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.

Перечень документов 34 ГОСТа

Наименование документа Код Дополнительные указания
ЭП Ведомость эскизного проекта ЭП* ОР
П1 ОР
ЭП, ТП Схема организационной структуры СО ОР Допускается включать в документ П3 или ПВ
С1* ТО Х Допускается включать в документ П9
Схема функциональной структуры С2* ОР При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1
В9 ТО Х
Схема автоматизации С3* ТО Х
ТО В состав проекта не входят
ТП ТО Х В состав проекта не входят
Ведомость технического проекта ТП* ОР
Ведомость покупных изделий ВП* ОР
В1 ИО
В2 ИО
В3 ТО Х Допускается включать в документ П2
П2 ОР
П3 ОР
П4 ОР
П5 ИО
П6 ИО
ТП П7 ИО
П8 ИО
П9 ТО Для задачи допускается включать в документ 46 по ГОСТ 19.101
ПА ПО
ПБ МО Допускается включать в документы П2, П3 или П4
ПВ ОО
План расположения С8 ТО Х Допускается включать в документ П9
ТО Х
Локальный сметный расчёт Б2 ОР Х
ТП, РД Б1 ОР
С9 ИО Х
РД ДП* ОР
ЭД* ОР Х
Спецификация оборудования В4 ТО Х
В5 ТО Х
ВМ* ИО Х
Массив входных данных В6 ИО Х
РД Каталог базы данных В7 ИО Х
В8 ИО Х
Локальная смета Б3 ОР Х
И1 ОО Х
Технологическая инструкция И2 ОО Х
Руководство пользователя И3 ОО Х
И4 ИО Х
Инструкция по эксплуатации КТС ИЭ ТО Х
Схема соединений внешних проводок С4* ТО Х
С5* ТО Х То же
Таблица соединений и подключений С6 ТО Х
Е1* ТО
Чертёж общего вида ВО* ТО Х
Чертёж установки технических средств СА ТО Х
Схема принципиальная СБ ТО Х
С1* ТО Х
План расположения оборудования и проводок С7 ТО Х
ПГ ОО Х
Общее описание системы ПД ОР Х
ПМ* ОР
Формуляр ФО* ОР Х
Паспорт ПС* ОР Х
*Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД

Примечание к таблице:

  1. В таблице приняты следующие обозначения:
    • ЭП — эскизный проект;
    • ТП — технический проект;
    • РД — рабочая документация;
    • ОР — общесистемные решения;
    • ОО — решения по организационному обеспечению;
    • ТО — решения по техническому обеспечению;
    • ИО — решения по информационному обеспечению;
    • ПО — решения по программному обеспечению;
    • МО — решения по математическому обеспечению.
  2. Знак Х — обозначает принадлежность к проектно-сметной или эксплуатационной документации.
  3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

ГОСТ 19

Серия ГОСТов 19 (ГОСТ 19.ххх Единая система программной документации (ЕСПД)) состоит:

    1. ГОСТ 19.001-77 Общие положения — слишком общий документ, практической пользы он не несёт. Поэтому его можно пропустить.
    2. ГОСТ 19781-90 Термины и определения — хороший список определений в области программного обеспечения систем обработки информации. Кроме как определений больше не содержит ничего.
    3. ГОСТ 19.101-77 Виды программ и программных документов — один из главных документов 19 ГОСТа. Именно с него следует начинать работу с 19 ГОСТом, так как в нём содержится полный перечень и обозначения документов ГОСТа.

Перечень документов 19 ГОСТа

Код Вид документа Стадии разработки
Рабочий проект
компонент комплекс
Спецификация
05 Ведомость держателей подлинников
12 Текст программы
13 Описание программы
20 Ведомость эксплуатационных документов
30 Формуляр
31 Описание применения
32 Руководство системного программиста
33 Руководство программиста
34 Руководство оператора
35 Описание языка
46
51 Программа и методика испытаний
81 Пояснительная записка
90-99 Прочие документы

Условные обозначения:

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

  1. ГОСТ 19.102-77 Стадии разработки — содержит описание стадий разработки. Полезен в образовательных целях. На мой взгляд, особой практической пользы не несёт.
  2. ГОСТ 19.103-77 Обозначения программ и программных документов — содержит описание присвоения номера (кода) документу. Даже после прочтения этого ГОСТа остаётся куча вопросов о том, как же присвоить этот самый номер документу.
  3. ГОСТ 19.104-78 Основные надписи — устанавливает формы, размеры, расположение и порядок заполнения основных надписей листа утверждения и титульного листа в программных документах, предусмотренных стандартами ЕСПД, независимо от способов их выполнения. Так как документы 19 ГОСТа оформляются в рамочках, то данный документ очень важен.
  4. ГОСТ 19.105-78 Общие требования к программным документам — устанавливает общие требования к оформлению программных документов. Требования слишком общие. Как правило для разработки документа этот ГОСТ почти не применяется, так как хватает специального ГОСТа на документ, но для общих знаний в данный ГОСТ все же лучше заглянуть разок.
  5. ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом — содержит требования к оформлению всех документов 19 ГОСТа.
  6. ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению — устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия. Пункты ТЗ 34 ГОСТа и 19 ГОСТа отличаются.
  7. ГОСТ 19.601-78 Общие правила дублирования, учёта и хранения — общие правила дублирования, обращения, учёта и хранения программных документов. В ГОСТе в нескольких пунктах описано как сделать так, чтобы документы не потерялись.
  8. ГОСТ 19.602-78 Правила дублирования, учёта и хранения программных документов, выполн-х печ. Способом — дополнение к ГОСТу 19.601-78.
  9. ГОСТ 19.603-78 Общие правила внесения изменений — устанавливает общие правила внесения изменений в программные документы. По сути, описывает длинный бюрократический алгоритм внесения изменений в документы.
  10. ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом — описывает порядок работы и заполнения с Листа регистрации изменений.

Список специализированных ГОСТов, то есть в каждом из них описано содержание и требования к определённому документу:

  1. ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению;
  2. ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению;
  3. ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению;
  4. ГОСТ 19.402-78 Описание программы;
  5. ГОСТ 19.403-79 Ведомость держателей подлинников;
  6. ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению;
  7. ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению;
  8. ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению;
  9. ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению;
  10. ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению;
  11. ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению;
  12. ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению;
  13. ГОСТ 19.507-79 Ведомость эксплуатационных документов;
  14. ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

Порядок работы с 19 ГОСТом:

  1. В ГОСТе 19.101-77 выбрать документ и его код согласно стадии разработки.
  2. Согласно ГОСТу 19.103-77 присвоить номер документу.
  3. Затем по ГОСТам 19.104-78 и 19.106-78 оформить документ.
  4. Из специализированного списка ГОСТов следует выбрать тот, который соответствует разрабатываемому документу.

Заключение

ГОСТ — это не страшно и несложно! Главное понять, что нужно написать и какой для этого ГОСТ используется. Наши основные ГОСТы 19 и 34 для написания документации очень старые, но и по сей день актуальны. Написание документации по стандарту снимает множество вопросов между исполнителем и заказчиком. Следовательно, несёт в себе экономию времени и денег.

Обозначение:Наименование:Средства программные систем вооружения. Порядок разработкиСтатус:ДействуетДата введения:07.01.1999Дата отмены:-Заменен на: -Код ОКС:35.080Скачать:

Текст ГОСТ Р 51189-98 Средства программные систем вооружения. Порядок разработки

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Software for military systems. The order of creating

Предисловие

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

2 НОРМАТИВНЫЕ ССЫЛКИ

3 ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

В настоящем стандарте применяют следующие термины с соответствующими определениями:Программное обеспечение — по ГОСТ 19781.Программа — по ГОСТ 19781.Программное средство — по ГОСТ 28806.Программное изделие — изделие межотраслевого применения вида «программной продукции», прошедшее испытание, имеющее соответствующий комплект программных документов и готовое к серийному производству.Программное изделие автоматизированных систем (программное изделие AC) — по ГОСТ 34.003.Программно-аппаратное средство — по ГОСТ Р ИСО/МЭК 9126.Программный компонент и комплекс (ПКиК) — по ГОСТ 19.101.Программный продукт — по ГОСТ 28806.Программные средства систем вооружения — виды программных компонентов, изготовленные на различных стадиях их жизненного цикла, снабженные установленным комплектом программных документов и предназначенные для применения в составе систем вооружения.Продукция производственно-технического назначения — по ГОСТ Р 15.201.Комплекс средств автоматизации АС (КСА АС) — по ГОСТ 34.003.Общее программное обеспечение АС (ОПО AC) — по ГОСТ 34.003.Специальное программное обеспечение АС (СПО AC) — по ГОСТ 34.003.Качество программного средства — по ГОСТ 28806.Сопровождение программного средства — процесс модификации программного средства, включая программную документацию, обусловленный необходимостью устранения выявленных ошибок и изменения его функциональных возможностей.Фондирование программных средств — по ГОСТ 26553.Сертификация программной продукции — деятельность независимой (третьей) стороны, направленная на подтверждение соответствия программной продукции установленным требованиям.Технологическая линия производства программ (ТЛПП) — комплекс технических и программных средств, предназначенных для автоматизации процессов проектирования и разработки программ.Комплекс программных средств проектирования и разработки — совокупность программных средств, предназначенных для автоматизации процессов проектирования и разработки программ.Спецификация — по ГОСТ 19.101.Спецификация программы — по ГОСТ 19781.Защита программного обеспечения — комплекс мер, направленных на предотвращение несанкционированного доступа к защищаемым программным компонентам и ресурсам ЭВМ.Руководящие указания главного конструктора системы вооружения — документ, содержащий сведения, не регламентированные нормативными документами, и устанавливающий единые требования для всех участников проекта программных средств систем вооружения.В настоящем стандарте приняты следующие сокращения:

4 ОСНОВНЫЕ ПОЛОЖЕНИЯ

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

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

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

ПРИЛОЖЕНИЕ А (рекомендуемое). ТРЕБОВАНИЯ К ПРОГРАММАМ, ПЕРЕДАВАЕМЫМ В ФОНД АЛГОРИТМОВ И ПРОГРАММ МИНИСТЕРСТВА ОБОРОНЫ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРИЛОЖЕНИЕ Б (рекомендуемое). СОДЕРЖАНИЕ РАБОТ ПО ФАЗАМ, СТАДИЯМ И ЭТАПАМ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ СИСТЕМ ВООРУЖЕНИЯ

ПРИЛОЖЕНИЕ В (обязательное). СОСТАВ ДОКУМЕНТАЦИИ, ВЫПУСКАЕМОЙ НА РАЗЛИЧНЫЕ КОМПОНЕНТЫ ПРОГРАММНОЙ ПРОДУКЦИИ ВОЕННОГО НАЗНАЧЕНИЯ

Примечание — Условные обозначения:* — документ обязательный;+ — документ обязательный для компонентов, имеющих самостоятельное применение; — необходимость выпуска документа определяют при разработке и утверждении ТЗ;»-» — документ не разрабатывается.

ПРИЛОЖЕНИЕ Г (справочное). БИБЛИОГРАФИЯ

Руководящий документ. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. — М.: Гостехкомиссия, 1992

О повышении эффективности функционирования и использования Государственного фонда алгоритмов и программ: Постановление Государственного комитета СССР по науке и технике N 581 от 10 октября 1979 г.*

amp_logo.pngallgosts.ruПревью ГОСТ Р 51189-98 Средства программные систем вооружения. Порядок разработкиИспользуемые источники:

  • https://m.habr.com/ru/post/328822/
  • https://docplace.ru/gost34/
  • https://allgosts.ru/35/080/gost_r_51189-98

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116