SELF-SPEC-003 — План разработки

Метаданные

Тип: Спецификация

Автор: analyst

Статус ЖЦ: baseline

Экспорт

CSV DOCX PDF

Версии

Базовая версия

2026-03-20T18:37:01+00:00

План разработки
Содержание
1. Введение2
1.1 Назначение2
1.2 Область применения2
1.3 Ссылки2
2 Организация жизненного цикла ПО4
3 Процессы разработки ПО6
3.1 Стандарты6
3.2 Разработка требований к ПО6
3.2.1 Входные данные процесса разработки требований к ПО6
3.2.5 Выходные данные процесса разработки требований к ПО7
3.3 Проектирование ПО7
3.3.1 Входные данные процесса проектирования ПО7
3.3.2 Условия входа в процесс проектирования ПО7
3.3.3 Описание процесса проектирования ПО8
3.3.4 Условия выхода из процесса проектирования ПО8
3.3.5 Выходные данные процесса проектирования ПО8
3.4 Кодирование ПО8
3.4.1 Входные данные процесса кодирования ПО8
3.4.2 Условия входа в процесс кодирования ПО8
3.4.3 Описание процесса кодирования ПО9
3.4.4 Условия выхода из процесса кодирования ПО9
3.4.5 Выходные данные процесса кодирования ПО9
3.5 Интеграция ПО9
3.5.1 Входные данные процесса интеграции ПО9
3.5.2 Условия входа в процесс интеграции ПО9
3.5.3 Описание процесса интеграции ПО10
3.5.4 Условия выхода из процесса интеграции ПО10
3.5.5 Выходные данные процесса интеграции ПО10
4 Среда разработки ПО11
4.1 Инструменты разработки ПО11
4.2 Инструменты разработки требований к ПО и описаний проектов12
4.3 Языки программирования12
Введение
Назначение
Данный документ определяет ЖЦ разработки ПО “Система управления требованиями” и описывает взаимодействие между различными процессами разработки ПО
Область применения
Текущий документ существует для демонстрации мероприятий, которые могут использоваться при достижении целей процессов, определенных рамками практикума в соответствии с КТ-178B. Положения, описанные в данном документе, могут быть неприменимыми при выполнении реальных проектов и должны быть пересмотрены с учетом нужд реального проекта в каждом конкретном случае.
В данном документе использована упрощенная (каскадная) схема организации ЖЦ ПО. Для использования более сложных схем организации ЖЦ, которые могут потребоваться в реальных проектах, потребуется переработка раздела 3 документа.
Ссылки
КТ-178В. Квалификационные требования. Часть 178В. Требования к ПО бортовой аппаратуры и систем при сертификации авиационной техники.
План управления конфигурацией ПО.
Стандарт на разработку требований к ПО.
Стандарт на проектирование ПО.
Стандарт на кодирование ПО.
Термины, определения и соглашения
Таблица 1. Термины, определения и соглашения
Термин
Определение, толкование
Сообщение о проблеме
Документ процесса УК ПО, содержащий описание несоответствия в данных ЖЦ ПО или в описании процессов ЖЦ ПО.
Запрос на изменение
Документ процесса УК ПО, созданный для внесения изменений в данные ЖЦ ПО с целью устранения несоответствия, описанного в СП.
Артефакт
Атомарное данное ЖЦ ПО. Артефактом может быть, например, требование или файл исходного кода.
Конфигурация
Составное данное ЖЦ ПО, которое может включать в себя любые артефакты, агрегации и конфигурации.
Спецификация программных требований
Совокупность всех требований, предъявляемых к программному обеспечению, и дополнительных сведений, необходимых для правильной интерпретации этих требований. Спецификация требований организована как агрегация в.
Формальная инспекция
Способ верификации документов, основанный на экспертной оценке их правильности, выполняемой одним или несколькими инспекторами, как правило, с использованием проверочных перечней.
Задача
Единица работы в системе управления проектом, связанная с выполнением конкретного Запроса на изменение (ЗНИ)
Таблица 2. Сокращения
Термин
Определение, толкование
ГК
Гарантия качества
ЖЦ
Жизненный цикл
ЗНИ
Запрос на изменение
ПО
Программное обеспечение
УК
Управление конфигурацией
ФИ
Формальная инспекция
СоП
Сообщение о проблеме
СПР
Система поддержки разработки
Организация жизненного цикла ПО
Ответственность
Руководитель проекта ответствен за распределение задач сотрудникам посредством назначения запроса на изменение ответственным разработчикам. Назначение запроса на изменение ответственным разработчикам должно проводиться таким образом, чтобы исключить одновременную работу различных сотрудников над одними и теми же частями документов.
Ответственный разработчик, назначенный руководителем проекта, ответствен за выполнение соответствующих мероприятий в соответствии с положениями данного раздела.
В рабочем процессе выделены несколько направлений, которые независимы друг от друга.
Взаимодействие процесса разработки  с другими процессами ЖЦ ПО
На вход процесса разработки ПО поступают базовые версии данных ЖЦ ПО:
требования к системе
требования к ПО
описание проекта ПО
исходный код ПО.
В результате выполнения мероприятий процесса разработки появляются новые версии указанных данных ЖЦ ПО, которые передаются в процесс верификации ПО. По результатам выполнения процесса верификации в процесс разработки передается результат верификации, который может потребовать дополнительного изменения данных ЖЦ ПО или же, если в процессе верификации не найдено несоответствий, устанавливается новая базовая версия для данных ЖЦ ПО.
Также на входы подается ЗНИ и данные, разработанные ранее.
Выходами являются:
Сообщения о проблемах.
Данные ЖЦ ПО (передаются на верификацию).
Базовые версии данных ЖЦ ПО.
Также следует помнить, что все входы и выходы взаимодействующих процессов проходят через процесс УК ПО. Сам процесс разработки ПО состоит из процессов, показанных в таблице 3.
Таблица 3. Процессы при разработке ПО
Процесс
Вход
Выход
Разработка требований ПО
Требования к системеСтандарт на разработку требований
ЗНИ
Требования к ПОСообщение о проблемах
Проектирование ПО
Требования к ПО
План разработкиСтандарт на проектирование
ЗНИ
Описание проекта ПОСообщение о проблемах
Написание кода
Описание проекта ПОСтандарт на кодирование
ЗНИ
Исходный кодСообщение о проблемахИнструкция по запуску
Интеграция ПО
Исходный кодЗНИ
Исполняемый код
Сообщение о проблемах
Процессы разработки ПО
Стандарты
При разработке ПО “Система управления требованиями” необходимо руководствоваться следующими стандартами:
Стандарт на разработку требований к ПО [3];
Стандарт на проектирование ПО [4];
Стандарт на кодирование ПО [5].
Разработка требований к ПО
Целями процесса разработки требований к ПО являются:
Разработка требований к ПО высокого уровня;
Разработка производных требований к ПО высокого уровня;
Входные данные процесса разработки требований к ПО
План разработки ПО.
Системные требования.
Стандарт на разработку требований.
ЗНИ(опционально).
Запись о ФИ требований к ПО (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс разработки требований к ПО
А. Первая итерация разработки требований в процессе ЖЦ. Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом задачи получения входных данных процесса разработки требований к ПО находятся в статусе “Решена“.Б. Последующие итерации разработки требований, инициированные по итогам проверки ФИ, сопровождающиеся запросом на изменение. Задача находится в статусе “На доработку“.
Описание процесса разработки требований к ПО
Задача разработки требований переводится в статус “В работе“. Далее выполняются действия, описанные в запросе на изменение. Если вход осуществлен по A, то в системе создается новый Документ, если по Б, то осуществляется модификация существующего.
Осуществляется процесс извлечения системных требований из источников.
По системным требованиям формируются требования к разрабатываемому ПО и по мере необходимости производные требования.
Каждое непроизводное требование трассируется на системные требования.
Каждое функциональное требование формулируется в канонической форме (см. Стандарт на разработку требований)
Условия выхода из процесса разработки требований к ПО
Выход из процесса разработки требований к ПО происходит при выполнении всех следующих условий:
Руководитель проекта извещен о завершении работ в соответствии с 3.2.3.
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Задачи, описанные в запросе на изменение, решены и в системе опубликована новая базовая версия требований.
Выходные данные процесса разработки требований к ПО
Спецификация программных требований
Сообщение о проблемах.
Требования к ПО.
Проектирование ПО
Цели процесса проектирования состоят в том, чтобы:
Разработать архитектуру ПО и требования низкого уровня на основе требований высокого уровня.
Разработать производные требования к ПО низкого уровня.
Все производные требования считаются не влияющими на безопасность системы.
Входные данные процесса проектирования ПО
Требования к ПО.
План разработки ПО.
Стандарт на проектирование ПО.
Результаты формальной инспекции (при повторном входе).
ЗНИ.
Условия входа в процесс проектирования ПО
Вход в процесс проектирования ПО осуществляется в случае выполнения любого из приведенных ниже условий.
А.  Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом установлены базовые версии всех входных данных процесса проектирования ПО
Б. В результате формальной инспекции ЗИ описания проекта ПО обнаружены несоответствия и связанная задача находится в состоянии “На доработку“.
Описание процесса проектирования ПО
Процесс аналогичен тому, который описан в пункте 3.2.3 с учетом изменения входных данных.
Основным методом при разработке описания проекта ПО является метод структурного проектирования, представляющий собой процесс последовательного разбиения ПО на компоненты, а компонента на подкомпоненты и функции.
Условия выхода из процесса проектирования ПО
Выход из процесса проектирования ПО происходит при выполнении всех следующих условий:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“;
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Задачи, описанные в запросе на изменение, решены и в системе опубликована новая базовая версия.
Выходные данные процесса проектирования ПО
Основным результатом процесса проектирования ПО являются:
Описание проекта ПО.
Сообщения о проблемах.
Кодирование ПО
Цель процесса процесса кодирования - разработать исходный код трассируемый, непротиворечивый и правильно реализующий требования к ПО низкого уровня.
Входные данные процесса кодирования ПО
План разработки ПО.
Стандарт на кодирование ПО.
ЗНИ.
Требования к ПО.
Описание проекта ПО.
Запись о ФИ исходного кода (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс кодирования ПО
Вход в процесс кодирования ПО осуществляется в случае выполнения любого из приведенных ниже условий.
А. Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом задачи получения входных данных находятся в статусе “Решена“;
Б.  Последующие итерации процесса кодирования ПО, инициированные по итогам проверки ФИ, сопровождающиеся запросом на изменение. Задача находится в статусе “На доработку“.
Описание процесса кодирования ПО
Процедура внесения изменений в файлы модулей исходного кода аналогична процессу разработки требований (п. 3.2.3). Разработчик вносит изменения в исходный код, руководствуясь стандартом на кодирование ПО и используя в качестве входных данных описание проекта ПО и требования к ПО. При выполнении мероприятий ответственный разработчик использует инструментарий процесса кодирования (см. раздел 4.1).
Условия выхода из процесса кодирования ПО
Выход из процесса кодирования ПО происходит при выполнении всех следующих целей:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“.
Работы, начатые по ЗИ или по результатам ФИ, завершены и измененный исходный код ПО и командные файлы для компиляции кода помещены в СПР.)
Руководитель проекта извещен о завершении работ, т.е. выполнены действия, аналогичные описанным в 3.2.3.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Выходные данные процесса кодирования ПО
Основным результатом этого процесса являются:
Исходный код.
Инструкция для запуска системы.
Сообщения о проблемах.
Интеграция ПО
Цель процесса интеграции ПО - загрузить на сервер исполняемый код ПО
Входные данные процесса интеграции ПО
План разработки ПО.
Описание проекта ПО.
Исходный код ПО.
Инструкция для запуска системы: скрипты сборки (командные файлы с директивами для компилятора).
ЗНИ.
Запись о ФИ результатов интеграции ПО (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс интеграции ПО
Вход в процесс интеграции ПО осуществляется в случае выполнения любого из приведенных ниже условий.
Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен ЗНИ. При этом задачи получения входных данных уже решены.
Последующие итерации процесса кодирования ПО, инициированные по итогам проверки, сопровождающиеся ЗНИ. Задача находится в статусе “На доработку“.
Описание процесса интеграции ПО
Ответственный разработчик извлекает указанную в задаче версию исходного кода и выполняет сборку кода, получая из него исполняемый код. Если в ходе выполнения компиляции, сборки или загрузки возникают проблемы, то разработчик открывает соответствующие сообщения о проблемах и завершает процесс интеграции по назначенной задаче.
Если компиляция, сборка и загрузка кода прошли успешно, разработчик сохраняет полученные выходные данные интеграции и завершает процесс интеграции по назначенной задаче.
При неуспешном завершении процесса, разработчик извещает об этом путем создания соответствующего сообщения о проблеме. В этом случае повторный вход в процесс интеграции будет осуществлен по новой задаче.
Условия выхода из процесса интеграции ПО
Выход из процесса происходит при выполнении всех следующих условий:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено”.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Работы, начатые по ЗНИ, завершены и все выходные данные процесса интеграции ПО помещены в систему поддержки разработки.
Выходные данные процесса интеграции ПО
Исполняемый объектный код;
Команды сборки исполняемого кода, загрузки на сервер и запуска на нем.
Сообщения о проблемах.
Среда разработки ПО
Процесс разработки программного обеспечения осуществляется с использованием интегрированных сред разработки (IDE — Integrated development environment) PyCharm (серверная часть) и WebStorm (клиентская часть), включающих следующие возможности:
1. Средства для написания программного кода, такие как автодополнение кода и организация файловой структуры.
2. Средства для компиляции кода.
3. Интеграция с системой контроля версий GitLab.
4. Интеграция с системой управления базой данных.
5. Автоматический вывод и проверка типов.
6. Средства для сборки артефактов компонентов программной системы.
Инструменты разработки ПО
На компьютерах разработчиков ПО устанавливаются следующие инструменты.
Таблица 4. Программные средства, устанавливаемые на рабочих местах разработчиков ПО
Название
Разработчик
Назначение
Linux Ubuntu
Canonical Ltd.
Операционная система
Yandex Wiki
Yandex
Подготовка документов, подготовка тест-планов
Draw.io
JGraph Ltd.
Создание схем, рисунков, диаграмм
PyCharm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на Python
JetBrains WebStorm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на JavaScript, CSS & HTML
PostgreSQL
Opensource-проект
Система управления базами данных
pgAdmin
Opensource-проект
Клиент для упрощения использования PostgreSQL
Git
Opensource-проект
Система контроля версий
React
Opensource-проект
Набор готовых библиотек для построения пользовательских интерфейсов
Flask
Opensource-проект
Набор готовых библиотек для разработки серверной части веб-приложения
Инструменты разработки требований к ПО и описаний проектов
Разработка требований к ПО и описания проекта проводится с помощью Yandex Wiki, тиражируемой вики-системой для внутреннего использования организациями с целью создания единой базы знаний от компании Yandex. Для доступа к базе знаний через веб-интерфейс на компьютерах разработчиков устанавливаются браузеры Google Chrome. Каждому разработчику в зависимости от его обязанностей будут установлены соответствующие права на доступ к данным в Yandex Wiki.
Языки программирования
Основным языком программирования при разработке исходного кода серверной части приложения должен являться язык программирования Python. Разработка исходного кода ПО должна вестись в соответствии со стандартами на кодирование ПО.
Основным языком для программирования при разработке исходного кода клиентской части приложения должен являться язык JavaScript.
Для запросов к базе данных должен использоваться язык SQL.

Рабочая версия

Рабочей версии нет.

Сохранить новую рабочую версию

Содержимое

План разработки
Содержание
1. Введение2
1.1 Назначение2
1.2 Область применения2
1.3 Ссылки2
2 Организация жизненного цикла ПО4
3 Процессы разработки ПО6
3.1 Стандарты6
3.2 Разработка требований к ПО6
3.2.1 Входные данные процесса разработки требований к ПО6
3.2.5 Выходные данные процесса разработки требований к ПО7
3.3 Проектирование ПО7
3.3.1 Входные данные процесса проектирования ПО7
3.3.2 Условия входа в процесс проектирования ПО7
3.3.3 Описание процесса проектирования ПО8
3.3.4 Условия выхода из процесса проектирования ПО8
3.3.5 Выходные данные процесса проектирования ПО8
3.4 Кодирование ПО8
3.4.1 Входные данные процесса кодирования ПО8
3.4.2 Условия входа в процесс кодирования ПО8
3.4.3 Описание процесса кодирования ПО9
3.4.4 Условия выхода из процесса кодирования ПО9
3.4.5 Выходные данные процесса кодирования ПО9
3.5 Интеграция ПО9
3.5.1 Входные данные процесса интеграции ПО9
3.5.2 Условия входа в процесс интеграции ПО9
3.5.3 Описание процесса интеграции ПО10
3.5.4 Условия выхода из процесса интеграции ПО10
3.5.5 Выходные данные процесса интеграции ПО10
4 Среда разработки ПО11
4.1 Инструменты разработки ПО11
4.2 Инструменты разработки требований к ПО и описаний проектов12
4.3 Языки программирования12
Введение
Назначение
Данный документ определяет ЖЦ разработки ПО “Система управления требованиями” и описывает взаимодействие между различными процессами разработки ПО
Область применения
Текущий документ существует для демонстрации мероприятий, которые могут использоваться при достижении целей процессов, определенных рамками практикума в соответствии с КТ-178B. Положения, описанные в данном документе, могут быть неприменимыми при выполнении реальных проектов и должны быть пересмотрены с учетом нужд реального проекта в каждом конкретном случае.
В данном документе использована упрощенная (каскадная) схема организации ЖЦ ПО. Для использования более сложных схем организации ЖЦ, которые могут потребоваться в реальных проектах, потребуется переработка раздела 3 документа.
Ссылки
КТ-178В. Квалификационные требования. Часть 178В. Требования к ПО бортовой аппаратуры и систем при сертификации авиационной техники.
План управления конфигурацией ПО.
Стандарт на разработку требований к ПО.
Стандарт на проектирование ПО.
Стандарт на кодирование ПО.
Термины, определения и соглашения
Таблица 1. Термины, определения и соглашения
Термин
Определение, толкование
Сообщение о проблеме
Документ процесса УК ПО, содержащий описание несоответствия в данных ЖЦ ПО или в описании процессов ЖЦ ПО.
Запрос на изменение
Документ процесса УК ПО, созданный для внесения изменений в данные ЖЦ ПО с целью устранения несоответствия, описанного в СП.
Артефакт
Атомарное данное ЖЦ ПО. Артефактом может быть, например, требование или файл исходного кода.
Конфигурация
Составное данное ЖЦ ПО, которое может включать в себя любые артефакты, агрегации и конфигурации.
Спецификация программных требований
Совокупность всех требований, предъявляемых к программному обеспечению, и дополнительных сведений, необходимых для правильной интерпретации этих требований. Спецификация требований организована как агрегация в.
Формальная инспекция
Способ верификации документов, основанный на экспертной оценке их правильности, выполняемой одним или несколькими инспекторами, как правило, с использованием проверочных перечней.
Задача
Единица работы в системе управления проектом, связанная с выполнением конкретного Запроса на изменение (ЗНИ)
Таблица 2. Сокращения
Термин
Определение, толкование
ГК
Гарантия качества
ЖЦ
Жизненный цикл
ЗНИ
Запрос на изменение
ПО
Программное обеспечение
УК
Управление конфигурацией
ФИ
Формальная инспекция
СоП
Сообщение о проблеме
СПР
Система поддержки разработки
Организация жизненного цикла ПО
Ответственность
Руководитель проекта ответствен за распределение задач сотрудникам посредством назначения запроса на изменение ответственным разработчикам. Назначение запроса на изменение ответственным разработчикам должно проводиться таким образом, чтобы исключить одновременную работу различных сотрудников над одними и теми же частями документов.
Ответственный разработчик, назначенный руководителем проекта, ответствен за выполнение соответствующих мероприятий в соответствии с положениями данного раздела.
В рабочем процессе выделены несколько направлений, которые независимы друг от друга.
Взаимодействие процесса разработки  с другими процессами ЖЦ ПО
На вход процесса разработки ПО поступают базовые версии данных ЖЦ ПО:
требования к системе
требования к ПО
описание проекта ПО
исходный код ПО.
В результате выполнения мероприятий процесса разработки появляются новые версии указанных данных ЖЦ ПО, которые передаются в процесс верификации ПО. По результатам выполнения процесса верификации в процесс разработки передается результат верификации, который может потребовать дополнительного изменения данных ЖЦ ПО или же, если в процессе верификации не найдено несоответствий, устанавливается новая базовая версия для данных ЖЦ ПО.
Также на входы подается ЗНИ и данные, разработанные ранее.
Выходами являются:
Сообщения о проблемах.
Данные ЖЦ ПО (передаются на верификацию).
Базовые версии данных ЖЦ ПО.
Также следует помнить, что все входы и выходы взаимодействующих процессов проходят через процесс УК ПО. Сам процесс разработки ПО состоит из процессов, показанных в таблице 3.
Таблица 3. Процессы при разработке ПО
Процесс
Вход
Выход
Разработка требований ПО
Требования к системеСтандарт на разработку требований
ЗНИ
Требования к ПОСообщение о проблемах
Проектирование ПО
Требования к ПО
План разработкиСтандарт на проектирование
ЗНИ
Описание проекта ПОСообщение о проблемах
Написание кода
Описание проекта ПОСтандарт на кодирование
ЗНИ
Исходный кодСообщение о проблемахИнструкция по запуску
Интеграция ПО
Исходный кодЗНИ
Исполняемый код
Сообщение о проблемах
Процессы разработки ПО
Стандарты
При разработке ПО “Система управления требованиями” необходимо руководствоваться следующими стандартами:
Стандарт на разработку требований к ПО [3];
Стандарт на проектирование ПО [4];
Стандарт на кодирование ПО [5].
Разработка требований к ПО
Целями процесса разработки требований к ПО являются:
Разработка требований к ПО высокого уровня;
Разработка производных требований к ПО высокого уровня;
Входные данные процесса разработки требований к ПО
План разработки ПО.
Системные требования.
Стандарт на разработку требований.
ЗНИ(опционально).
Запись о ФИ требований к ПО (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс разработки требований к ПО
А. Первая итерация разработки требований в процессе ЖЦ. Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом задачи получения входных данных процесса разработки требований к ПО находятся в статусе “Решена“.Б. Последующие итерации разработки требований, инициированные по итогам проверки ФИ, сопровождающиеся запросом на изменение. Задача находится в статусе “На доработку“.
Описание процесса разработки требований к ПО
Задача разработки требований переводится в статус “В работе“. Далее выполняются действия, описанные в запросе на изменение. Если вход осуществлен по A, то в системе создается новый Документ, если по Б, то осуществляется модификация существующего.
Осуществляется процесс извлечения системных требований из источников.
По системным требованиям формируются требования к разрабатываемому ПО и по мере необходимости производные требования.
Каждое непроизводное требование трассируется на системные требования.
Каждое функциональное требование формулируется в канонической форме (см. Стандарт на разработку требований)
Условия выхода из процесса разработки требований к ПО
Выход из процесса разработки требований к ПО происходит при выполнении всех следующих условий:
Руководитель проекта извещен о завершении работ в соответствии с 3.2.3.
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Задачи, описанные в запросе на изменение, решены и в системе опубликована новая базовая версия требований.
Выходные данные процесса разработки требований к ПО
Спецификация программных требований
Сообщение о проблемах.
Требования к ПО.
Проектирование ПО
Цели процесса проектирования состоят в том, чтобы:
Разработать архитектуру ПО и требования низкого уровня на основе требований высокого уровня.
Разработать производные требования к ПО низкого уровня.
Все производные требования считаются не влияющими на безопасность системы.
Входные данные процесса проектирования ПО
Требования к ПО.
План разработки ПО.
Стандарт на проектирование ПО.
Результаты формальной инспекции (при повторном входе).
ЗНИ.
Условия входа в процесс проектирования ПО
Вход в процесс проектирования ПО осуществляется в случае выполнения любого из приведенных ниже условий.
А.  Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом установлены базовые версии всех входных данных процесса проектирования ПО
Б. В результате формальной инспекции ЗИ описания проекта ПО обнаружены несоответствия и связанная задача находится в состоянии “На доработку“.
Описание процесса проектирования ПО
Процесс аналогичен тому, который описан в пункте 3.2.3 с учетом изменения входных данных.
Основным методом при разработке описания проекта ПО является метод структурного проектирования, представляющий собой процесс последовательного разбиения ПО на компоненты, а компонента на подкомпоненты и функции.
Условия выхода из процесса проектирования ПО
Выход из процесса проектирования ПО происходит при выполнении всех следующих условий:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“;
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Задачи, описанные в запросе на изменение, решены и в системе опубликована новая базовая версия.
Выходные данные процесса проектирования ПО
Основным результатом процесса проектирования ПО являются:
Описание проекта ПО.
Сообщения о проблемах.
Кодирование ПО
Цель процесса процесса кодирования - разработать исходный код трассируемый, непротиворечивый и правильно реализующий требования к ПО низкого уровня.
Входные данные процесса кодирования ПО
План разработки ПО.
Стандарт на кодирование ПО.
ЗНИ.
Требования к ПО.
Описание проекта ПО.
Запись о ФИ исходного кода (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс кодирования ПО
Вход в процесс кодирования ПО осуществляется в случае выполнения любого из приведенных ниже условий.
А. Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен запрос на изменение. При этом задачи получения входных данных находятся в статусе “Решена“;
Б.  Последующие итерации процесса кодирования ПО, инициированные по итогам проверки ФИ, сопровождающиеся запросом на изменение. Задача находится в статусе “На доработку“.
Описание процесса кодирования ПО
Процедура внесения изменений в файлы модулей исходного кода аналогична процессу разработки требований (п. 3.2.3). Разработчик вносит изменения в исходный код, руководствуясь стандартом на кодирование ПО и используя в качестве входных данных описание проекта ПО и требования к ПО. При выполнении мероприятий ответственный разработчик использует инструментарий процесса кодирования (см. раздел 4.1).
Условия выхода из процесса кодирования ПО
Выход из процесса кодирования ПО происходит при выполнении всех следующих целей:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено“.
Работы, начатые по ЗИ или по результатам ФИ, завершены и измененный исходный код ПО и командные файлы для компиляции кода помещены в СПР.)
Руководитель проекта извещен о завершении работ, т.е. выполнены действия, аналогичные описанным в 3.2.3.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Выходные данные процесса кодирования ПО
Основным результатом этого процесса являются:
Исходный код.
Инструкция для запуска системы.
Сообщения о проблемах.
Интеграция ПО
Цель процесса интеграции ПО - загрузить на сервер исполняемый код ПО
Входные данные процесса интеграции ПО
План разработки ПО.
Описание проекта ПО.
Исходный код ПО.
Инструкция для запуска системы: скрипты сборки (командные файлы с директивами для компилятора).
ЗНИ.
Запись о ФИ результатов интеграции ПО (при повторных входах в процесс по результатам ФИ).
Условия входа в процесс интеграции ПО
Вход в процесс интеграции ПО осуществляется в случае выполнения любого из приведенных ниже условий.
Задача находится в статусе “Передана в работу“ и назначена на исполнителя, получен ЗНИ. При этом задачи получения входных данных уже решены.
Последующие итерации процесса кодирования ПО, инициированные по итогам проверки, сопровождающиеся ЗНИ. Задача находится в статусе “На доработку“.
Описание процесса интеграции ПО
Ответственный разработчик извлекает указанную в задаче версию исходного кода и выполняет сборку кода, получая из него исполняемый код. Если в ходе выполнения компиляции, сборки или загрузки возникают проблемы, то разработчик открывает соответствующие сообщения о проблемах и завершает процесс интеграции по назначенной задаче.
Если компиляция, сборка и загрузка кода прошли успешно, разработчик сохраняет полученные выходные данные интеграции и завершает процесс интеграции по назначенной задаче.
При неуспешном завершении процесса, разработчик извещает об этом путем создания соответствующего сообщения о проблеме. В этом случае повторный вход в процесс интеграции будет осуществлен по новой задаче.
Условия выхода из процесса интеграции ПО
Выход из процесса происходит при выполнении всех следующих условий:
Объявлено о завершении работ посредством установки статуса задачи “Утверждено”.
Все найденные во входных данных несоответствия зарегистрированы в сообщениях о проблемах.
Работы, начатые по ЗНИ, завершены и все выходные данные процесса интеграции ПО помещены в систему поддержки разработки.
Выходные данные процесса интеграции ПО
Исполняемый объектный код;
Команды сборки исполняемого кода, загрузки на сервер и запуска на нем.
Сообщения о проблемах.
Среда разработки ПО
Процесс разработки программного обеспечения осуществляется с использованием интегрированных сред разработки (IDE — Integrated development environment) PyCharm (серверная часть) и WebStorm (клиентская часть), включающих следующие возможности:
1. Средства для написания программного кода, такие как автодополнение кода и организация файловой структуры.
2. Средства для компиляции кода.
3. Интеграция с системой контроля версий GitLab.
4. Интеграция с системой управления базой данных.
5. Автоматический вывод и проверка типов.
6. Средства для сборки артефактов компонентов программной системы.
Инструменты разработки ПО
На компьютерах разработчиков ПО устанавливаются следующие инструменты.
Таблица 4. Программные средства, устанавливаемые на рабочих местах разработчиков ПО
Название
Разработчик
Назначение
Linux Ubuntu
Canonical Ltd.
Операционная система
Yandex Wiki
Yandex
Подготовка документов, подготовка тест-планов
Draw.io
JGraph Ltd.
Создание схем, рисунков, диаграмм
PyCharm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на Python
JetBrains WebStorm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на JavaScript, CSS & HTML
PostgreSQL
Opensource-проект
Система управления базами данных
pgAdmin
Opensource-проект
Клиент для упрощения использования PostgreSQL
Git
Opensource-проект
Система контроля версий
React
Opensource-проект
Набор готовых библиотек для построения пользовательских интерфейсов
Flask
Opensource-проект
Набор готовых библиотек для разработки серверной части веб-приложения
Инструменты разработки требований к ПО и описаний проектов
Разработка требований к ПО и описания проекта проводится с помощью Yandex Wiki, тиражируемой вики-системой для внутреннего использования организациями с целью создания единой базы знаний от компании Yandex. Для доступа к базе знаний через веб-интерфейс на компьютерах разработчиков устанавливаются браузеры Google Chrome. Каждому разработчику в зависимости от его обязанностей будут установлены соответствующие права на доступ к данным в Yandex Wiki.
Языки программирования
Основным языком программирования при разработке исходного кода серверной части приложения должен являться язык программирования Python. Разработка исходного кода ПО должна вестись в соответствии со стандартами на кодирование ПО.
Основным языком для программирования при разработке исходного кода клиентской части приложения должен являться язык JavaScript.
Для запросов к базе данных должен использоваться язык SQL.

Связанный ЗИ

source_file

Трассировка артефактов

Тип связи	Связанный артефакт
Исходящих связей нет.

Связанный артефакт Тип связи Комментарий

Связи с кодом

Репозиторий	Файл	Строки
Связей с кодом нет.

История версий

Время	Тип версии	Автор	Атрибуты
2026-03-20T18:37:01+00:00	baseline	analyst	{'source_file': 'План разработки.docx'}