Жизненный цикл программных систем. Cтандартизация в области информационных технологий Стандарт ieee 90 элементы сопровождения

Структура ЖЦ ПО в соответствии со стандартом ISO/IEC 12207 базируется на трех группах процессов (рис. 1):

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Рис. 1. Процессы жизненного цикла программного обеспечения.

Процесс приобретения (acquisition process). Он состоит из действий

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

1) инициирование приобретения;

2) подготовку заявочных предложений;

3) подготовку и корректировку договора;

4) надзор за деятельностью поставщика;

5) приемку и завершение работ.

Процесс поставки (supply process). Он охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой. Данный процесс включает следующие действия:

1) инициирование поставки;

2) подготовку ответа на заявочные предложения;

3) подготовку договора;

4) планирование;

5) выполнение и контроль;

6) проверку и оценку;

7) поставку и завершение работ.

Процесс разработки (development process). Он предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д.

Процесс разработки включает следующие действия:

1) анализ требований к системе;

2) проектирование архитектуры системы;

3) анализ требований к ПО;

4) проектирование архитектуры ПО;

5) детальное проектирование ПО;

6) кодирование и тестирование ПО;

7) интеграцию ПО;

8) квалификационное тестирование ПО;

9) интеграцию системы;

10) квалификационное тестирование системы;

11) установку ПО;

12) приемку ПО.

Процесс эксплуатации (operation process). Он охватывает действия и задачи оператора - организации, эксплуатирующей систему. Данный процесс включает следующие действия:

1) эксплуатационное тестирование;

2) эксплуатацию системы;

3) поддержку пользователей.

Процесс сопровождения (maintenance process). Он предусматривает действия и задачи, выполняемые сопровождающей организацией (службой сопровождения). Данный процесс активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации либо адаптации ПО. В соответствии со стандартом IEEE-90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или

требованиям. Изменения, вносимые в существующее ПО, не должны нарушать

его целостность. Процесс сопровождения включает перенос ПО в другую среду (миграцию) и заканчивается снятием ПО с эксплуатации.

Процесс сопровождения охватывает следующие действия:

1) анализ проблем и запросов на модификацию ПО;

2) модификацию ПО;

3) проверку и приемку;

4) перенос ПО в другую среду;

5) снятие ПО с эксплуатации.

В группу вспомогательных процессов включены:

Документирование;

Управление конфигурацией; обеспечение качества;

Верификация; аттестация;

Совместная оценка;

Разрешение проблем.

Процесс документирования (documentation process). Он предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Процесс документирования включает следующие действия:

1) проектирование и разработку;

2) выпуск документации;

3) сопровождение документации.

Процесс управления конфигурацией (configuration management process). Он предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических ха-

рактеристик, установленных в технической документации и реализованных в ПО.

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.

Configuration Management for Software". Процесс управления конфигурацией включает следующие действия:

1) идентификацию конфигурации;

2) контроль конфигурации;

3) учет состояния конфигурации;

4) оценку конфигурации;

5) управление выпуском и поставку.

Процесс обеспечения качества (quality assurance process). Он обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПО понимается совокупность свойств, которые характеризуют способность ПО удовлетворять заданным требованиям. Для получения достоверных оценок создаваемого ПО процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПО. При этом могут использоваться результаты других вспомогательных процессов, таких, как верификация, аттестация, совместная оценка, аудит и разрешение проблем. Процесс обеспечения качества включает следующие действия:

1) обеспечение качества продукта;

2) обеспечение качества процесса;

3) обеспечение прочих показателей качества системы.

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

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

Процесс совместной оценки (joint review process). Он предназначен для оценки состояния работ по проекту и ПО, создаваемого при выполнении данных работ (действий). Он сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.

Процесс аудита (audit process). Он представляет собой определение соответствия требованиям, планам и условиям договора.

Процесс разрешения проблем (problem resolution process). Он предусматривает анализ и решение проблем (включая обнаруженные несоответствия) независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена.

В группу организационных процессов ЖЦ ПО входят:

Управление;

Создание инфраструктуры;

Усовершенствование;

Выпуск новых версий;

Обучение.

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

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

Процесс усовершенствования (improvement process). Он предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Усовершенствование процессов ЖЦ ПО направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения

персонала.

Процесс обучения (training process). Он охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Барышникова Марина Юрьевна
МГТУ им. Н.Э. Баумана
Каф. ИУ-7

Лекция 3

Жизненный цикл программного
обеспечения

Жизненный цикл программного обеспечения

это период времени, который начинается с
момента принятия решения о
необходимости создания программного
обеспечения и заканчивается в момент
его полного изъятия из эксплуатации
(IEEE Std. 610.12 – 19990 Standard Glossary of Software
Engineering Terminology)

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

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

Жизненный цикл ПО согласно стандарту ISO/IEC 12207: 1995
«International Technology – Software Life Cycle Processes»
(ГОСТ ИСО МЭК 12207-99 Информационные технологии.
Жизненный цикл программного обеспечения)
Жизненный цикл
Организационные
процессы
Управление
проектом
Создание
инфраструктуры
Оценка и улучшение
жизненного цикла
Обучение
Основные
процессы
Приобретение
Вспомогательные
процессы
Документирование
Поставка
Управление
конфигурацией
Разработка
Обеспечение
качества
Эксплуатация
Верификация
Сопровождение
Аттестация
Совместная
оценка
Аудит
Разрешение
проблем

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

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

Процесс разработки

Определяет действия, выполняемые разработчиком в
процессе создания программного обеспечения и его
компонентов в соответствии с заданными требованиями
Данный процесс включает, в том числе:
оформление проектной и эксплуатационной
документации;
подготовку материалов, необходимых для проверки
работоспособности программного продукта и его
соответствия стандартам качества;
разработку материалов (методических и учебных),
необходимых для подготовки и обучения персонала и
т.д.

Процесс разработки

Выбор модели жизненного цикла
Анализ требований к системе
Проектирование архитектуры системы
Анализ программных требований
Детальное конструирование ПО
Кодирование и тестирование ПО
Интеграция ПО
Квалификационное тестирование ПО
Интеграция системы
Квалификационное тестирование системы
Установка ПО
Приемка ПО

10. Анализ требований к системе

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

11. Анализ требований к ПО

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

12. Проектирование архитектуры ПО

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

13. Детальное конструирование ПО (рабочий план разработки ПО)

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

14. Кодирование и тестирование ПО подразумевает решение следующих задач:

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

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

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

16. Квалификационное тестирование ПО

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

17. Установка и приемка ПО

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

18. Эксплуатация ПО

Эксплуатация системы выполняется в
предназначенной для этого среде в
соответствии с пользовательской
документацией
Включает установление
эксплуатационных стандартов и
проведение эксплуатационного
тестирования

19. Сопровождение ПО (согласно стандарту IEEE – 90)

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

20. Вспомогательные процессы жизненного цикла ПО

Документирование
Управление конфигурацией
Обеспечение качества
Верификация
Аттестация
Совместная оценка
Аудит
Разрешение проблем

21. Процесс документирования

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

22. Управление конфигурацией

Конфигурация программного обеспечения – это
совокупность его функциональных и физических
характеристик, установленных в технической
документации и реализованных в программах
Процесс позволяет организовать, систематически
учитывать и контролировать внесение изменений в
ПО на всех стадиях жизненного цикла
Общие принципы и рекомендации по управлению конфигурацией отражены
в стандарте ISO/IEC CD 12207 – 2:1995 “Information Technology – Software
Cycle Processes. Part 2. Configuration Management for Software”

23. Процесс обеспечения качества

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

24. Верификация

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

25. Аттестация

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

26. Организационные процессы жизненного цикла ПО

Управление
Создание инфраструктуры (инфраструктура
программного проекта включает в себя технологии и
стандарты, а также совокупность аппаратных,
программных и инструментальных средств для
разработки, эксплуатации или сопровождения ПО)
Усовершенствование
Обучение (первоначальное обучение и
последующее постоянное повышение
квалификации персонала, включая разработку
методических материалов)

27. Группы стандартов ЕСПД

Kод группы
0
1
2
3
4
5
6
7
8
9
Наименование группы
Общие положения
Основополагающие стандарты
Правила выполнения документации разработки
Правила выполнения документации изготовления
Правила выполнения документации сопровождения
Правила выполнения эксплуатационной документации
Правила обращения программной документации
Резервные группы
Прочие стандарты
Обозначение стандарта ЕСПД состоит из:
числа 19 (присвоенного классу стандартов ЕСПД);
одной цифры (после точки), обозначающей код классификационной группы стандартов,
указанный в таблице;
двузначного числа (после тире), указывающего год регистрации стандарта

28. Перечень документов ЕСПД

ГОСТ 19.001-77 ЕСПД. Общие положения
ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов
ГОСТ 19.102-77 ЕСПД. Стадии разработки
ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов
ГОСТ 19.104-78 ЕСПД. Основные надписи
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам
ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом
ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению
ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний
ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению
ГОСТ 19.402-78 ЕСПД. Описание программы
ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению
ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению
ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению
ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и
оформлению
ГОСТ 19.504-79 ЕСПД. Руководство программиста
ГОСТ 19.505-79 ЕСПД. Руководство оператора
ГОСТ 19.506-79 ЕСПД. Описание языка
ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и
оформлению
ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые
печатным способом
ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и
правила выполнения
ГОСТ 19.781-90. Обеспечение систем обработки информации

29. Преимущества использования стандартов ЕСПД

стандарты ЕСПД вносят элемент упорядочения в
процесс документирования программных средств
(ПС);
несмотря на наличие требований к комплекту
документации на ПС, предусмотренной стандартами
ЕСПД, они позволяют вносить дополнительные виды
документов;
стандарты ЕСПД позволяют мобильно изменять
структуры и содержание установленных видов
программных документов исходя из требований
заказчика и пользователя

30. Недостатки стандартов ЕСПД

ориентация на единственную, «каскадную» модель жизненного
цикла ПО;
отсутствие четких рекомендаций по документированию
характеристик качества программного средства;
отсутствие системной увязки с другими действующими
отечественными системами стандартов по жизненному циклу и
документированию продукции в целом, например, ЕСКД;
нечетко выраженный подход к документированию ПС как
товарной продукции;
отсутствие рекомендаций по самодокументированию ПС,
например, в виде экранных меню и средств оперативной помощи
пользователю («хелпов»);
отсутствие рекомендаций по составу, содержанию и оформлению
документов на программные средства, согласованных с
рекомендациями международных и региональных стандартов

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

1.
Формирование требований к АС
2.
Разработка концепции АС
3.
Изучение объекта
Проведение необходимых научно-исследовательских работ
Разработка вариантов концепции АС и выбор варианта концепции АС,
удовлетворяющего требованиям пользователей
Оформление отчета о проделанной работе
Техническое задание
4.
Обследование объекта и обоснование необходимости создания АС
Формирование требований пользователя к АС
Оформление отчета о выполнении работ и заявки на разработку АС
Разработка и утверждение технического задания на создание АС
Эскизный проект
Разработка предварительных проектных решений по системе и ее частям

32.

Стандарт ГОСТ 34.601-90: стадии и этапы
создания автоматизированной системы
5.
Технический проект
6.
Рабочая документация
7.
Разработка рабочей документации на АС и ее части
Разработка и адаптация программ
Ввод в действие
8.
Разработка проектных решений по системе и ее частям
Разработка документации на АС и ее части
Разработка и оформление документации на поставку комплектующих изделий
Разработка заданий на проектирование в смежных частях проекта
Подготовка объекта автоматизации
Подготовка персонала
Комплектация АС поставляемыми изделиями (программными и техническими средствами,
программно-техническими комплексами, информационными изделиями)
Строительно-монтажные работы
Пусконаладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний
Сопровождение АС
Выполнение работ в соответствии с гарантийными обязательствами
Послегарантийное обслуживание

Международный стандарт IEEE Std 830-1993. Рекомендации по разработке спецификаций требований программного обеспечения.

Одобрено 2 декабря, 1993 Комитетом Стандартов IEEE

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

Ключевые слова: контракт, клиент, прототипирование, спецификация требований программного обеспечения, поставщик, спецификация требований системы

Введение

(Введение не является частью «IEEE Std 830-1993 Рекомендации по разработке спецификаций требований программного обеспечения») Этот документ описывает рекомендуемые подходы к созданию спецификации требований программного обеспечения. Он основан на модели, в которой результатом процесса разработки спецификации требований программного обеспечения является однозначный и полный документ спецификации. Это должно помочь

a) Клиентам программного обеспечения точно описать, что они желают получить

b) Поставщикам программного обеспечения понять точно, чего хочет заказчик

c) Индивидуумам выполнить следующие цели:

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

2) Определить формат и содержание собственных спецификаций требований программного обеспечения

3) Включить дополнительные пункты требований, такие как спецификация требований контроля качества (quality checklist) или спецификация требований к написанию руководства (writer"s handbook).

Хорошие спецификации должны обеспечить клиентам, поставщикам и другим индивидуумам несколько определенных преимуществ, таких как:

a) Установить основание для соглашения между клиентами и поставщиками о том, что программное обеспечение должно делать. Полное описание функций, которые будут выполнены программным обеспечением, указанным в СТПО поможет потенциальному пользователю определить, выполняет ли программное обеспечение их потребности или как программное обеспечение должно быть изменено, чтобы выполнить их потребности.

b) Уменьшить усилия на разработку. Подготовка СТПО вынуждает различные заинтересованные группы в организации клиента строго рассматривать все требования до начала разработки проекта и уменьшает в дальнейшем объем работ по перепроектированию, перекодированию, и повторному тестированию. Внимательное рассмотрение требований в СТПО может выявить упущения, недоразумения и нелогичности на ранних стадиях разработки, когда эти проблемы более легко исправляются.

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

d) Обеспечить основу для испытаний (validation) и проверок. Организации могут развивать собственные планы испытаний и проверок намного более продуктивно при наличии хороших СТПО. Как часть контракта на разработку, СТПО обеспечивает основу, у которой соответствие может быть измерено.

e) Облегчить передачу. СТПО обеспечивают более легкую передачу изделия программного обеспечения новым пользователям или установку на новые машины. Таким образом, заказчикам более легко передавать программное обеспечение другим частям их организации, а поставщикам более легко передавать программное обеспечение новым клиентам.

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

1 Краткий обзор (Overview)

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

Пункт 1 объясняет возможности этого стандарта.

Пункт 3 содержит используемые определения.

Пункт 4 обеспечивает информационную основу для разработки СТПО.

Пункт 5 обсуждает каждую из существенных частей СТПО.

Стандарт также имеет приложения, в которых приводятся альтернативные шаблоны форматов СТПО.

1.1 Возможности (Scope)

Дает рекомендации по созданию спецификаций требований программного обеспечения. Описывает содержание и признаки хорошей спецификации требований программного обеспечения (СТПО) и представляет несколько образцов схем СТПО.

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

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

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

Стандарт не определяет никаких специальных методов, терминологии (nomenclature) или инструментов для подготовки СТПО.

2 Ссылки (References)

ASTM 1340-90, Standard Guide for Rapid Prototyping of Computerized Systems

IEEE Std 610.12- 1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).

IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI).

IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans (ANSI).

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 983-1986, IEEE Guide to Software Quality Assurance Planning.

IEEE Std 1002-1987, IEEE Standard Taxonomy for Software Engineering Standards (ANSI).

IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans (ANSI).

IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Descriptions (ANSI).

IEEE Std 1028- 1988, IEEE Standard for Software Reviews and Audits (ANSI).

IEEE Std 1042-1987, IEEE Guide to Software Configuration Management (ANSI).

IEEE Std 1058.1-1987, IEEE Standard for Project Management Plans (ANSI).

IEEE Std 1074-1991, IEEE Standard for Developing Software Life Cycle Processes (ANSI).

3 Определения (Definitions)

Вообще определения терминов, используемых в этом документе соответствуют определениям, сформулированным в IEEE Std 610.12-1990.5. Ниже даны определения ключевых терминов, поскольку они используются в этом документе.

3.1 Контракт (contract).

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

3.2 Клиент (customer).

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

3.3 Поставщик (supplier).

Человек, или люди, которые производят изделие для клиента. В контексте этого документа, могут быть членами одной организации.

3.4 Пользователь (user).

Человек, или люди, которые работают или взаимодействуют непосредственно с изделием. Пользователь (и) и клиент (ы) - часто не тот же самый человек (люди).

4 Соображения по созданию хороших СТПО (Considerations for producing a good SRS)

Этот пункт обеспечивает информационную основу для разработки СТПО. Включает следующее:

a) Сущность СТПО

b) Контекст СТПО

c) Характеристики хороших СТПО

d) Совместная подготовка СТПО

e) Процесс изменения СТПО

f) Прототипирование

g) Включение проекта в СТПО

h) Включение требований проектирования в СТПО

4.1 Сущность СТПО (Nature of the SRS)

СТПО - технические условия для отдельного программного продукта, программы, или набора программ, которые выполняют определенные задачи в определенной окружающей среде. СТПО могут быть созданы одним или несколькими представителями поставщика, одним или несколькими представителями клиента или обоими. Подпункт 4.4 рекомендует разработку при участии представителей поставщика и клиента.

Основные вопросы, которые должен рассматривать разработчик СТПО:

a) Функциональные возможности. Что программа должна делать?

b) Внешние интерфейсы. Как программное обеспечение взаимодействует с людьми, системным аппаратным обеспечением, другим оборудованием и другим программным обеспечением?

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

d) Характеристики (Attributes). Какова переносимость, корректность, ремонтопригодность, безопасность, и т.д.?

e) Ограничения проекта, наложенные на реализацию. Требования любых существующих стандартов, язык выполнения, политика обеспечения целостности базы данных, ограничения на ресурсы, операционная среда (ы) исполнения и т.д.?

Разработчики СТПО должны избегать размещения в СТПО любых требований разработки или требований проекта.

4.2 Контекст СТПО (Environment of the SRS)

Важно учитывать роль, которую СТПО играет в общем плане проекта, что определено стандартом IEEE Std 610.12-1990. Программное обеспечение может содержать по существу все функциональные возможности проекта, или может быть частью большей системы. В последнем случае обычно имеется СТПО, которая определяет интерфейсы между системой и частью программного обеспечения и содержит требования к характеристикам и функциональности данной части программного обеспечения. Конечно, СТПО в этом случае должна быть согласована и расширена общесистемными требованиями.

IEEE Std 1074-1991 описывает этапы жизненного цикла программного обеспечения и соответствующие входы для каждого этапа. Другие стандарты, типа тех, которые включены в список в разделе 2, относятся к другим этапам жизненного цикла программного обеспечения и также могут дополнять требования программного обеспечения.

Так как СТПО играют особую роль в процессе развития программного обеспечения, то автор (ы) СТПО должны быть внимательными, чтобы не выходить за границы этой роли. Это означает, что СТПО

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

b) Не должен описывать никакого проектирования или деталей выполнения. Они должны быть описаны в стадии разработки проекта.

c) Не должны накладывать дополнительные ограничения на программное обеспечение. Правильно, если они определены в других документах типа плана обеспечения качества. Поэтому, правильно, если созданные СТПО ограничивают рамки проектирования, но не определяют никаких деталей проектирования.

4.3 Характеристики хороших СТПО (Characteristics of a good SRS)

СТПО должны иметь следующие характеристики

d) Правильный

e) Однозначный

g) Последовательный

h) Оцениваемы по важности и/или стабильности

i) Поддающийся проверке

j) Поддающийся изменению

k) Трассируемый

4.3.1 Правильный (Correct)

СТПО правильны, тогда и только тогда, когда каждое заявленное в них требование должно быть удовлетворено в программном обеспечении. Нет никакого инструмента или процедуры, которая определяет правильность. СТПО должны быть сравнены с любыми соответствующим спецификациями более высокого уровня, такими как спецификация требований системы, с другой проектной документацией и с другими соответствующими стандартами, чтобы убедиться, что имеется соответствие. Дополнительно, клиент или пользователь может определить, правильно ли СТПО отражает фактические потребности. Трассируемость делает эту процедуру более легкой и менее подверженной ошибкам (см. 4.3.8).

4.3.2 Непротиворечивый (Unambiguous)

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

СТПО - важная часть жизненного цикла программного обеспечения и используются при проектировании, реализации, контроле проекта, проверке, испытаниях и в обучении как описано в IEEE Std 1074-1991. СТПО должны быть интерпретированы однозначно, и теми, кто создают СТПО и теми, кто его использует. Однако эти группы часто не имеют одинаковой подготовки и поэтому имеют тенденцию интерпретировать требования программного обеспечения различным способом. Представления, которые улучшают спецификацию требований для разработчика, могут быть непродуктивными в понимании их пользователем и наоборот.

4.3.2.1 Сложности естественного языка (Natural language pitfalls)

Требования часто написаны на естественном языке (например, английском языке). Естественный язык неотъемлемо неоднозначен. Для того чтобы определить неоднозначное использование естественного языка, СТПО должны быть рассмотрены независимой стороной, с тем, чтобы выявленные неоднозначности были исправлены.

4.3.2.2 Языки спецификаций требований (Requirements specification languages)

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

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

4.3.2.3 Инструменты представления (Representation tools).

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

Степень полезности таких инструментов и методов при создании СТПО зависит от размера и сложности программы. Здесь не делается попыток описать или рекомендовать какой-либо конкретный инструмент.

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

4.3.3 Полный (Complete)

СТПО полны тогда, и только тогда, когда они включают следующие элементы:

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

b) Все реакции программного обеспечения на все возможные типы входных данных во всех возможных ситуациях. Важно определить реакции, как на допустимые значения данных, так и на недопустимые.

4.3.3.1 Использование фразы “будет определено” (Use of TBDs)

Любые СТПО, которые используют фразу “будет определено” (TBD) – не являются полными, однако, они иногда необходимы и должны сопровождаться следующим

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

b) Описанием того, что должно быть выполнено, чтобы устранить фразу “будет определено”, кто ответственен за устранение, когда должно быть устранено.

4.3.4 Целостный (Consistent)

Целостность относится к внутренней целостности. Если СТПО противоречат документам более высокого уровня, типа спецификации требований системы, то это неправильно (см. 4.3.1).

4.3.4.1 Внутренняя целостность (Internal consistency)

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

a) Указанные характеристики объектов могут находиться в противоречии. Например,

1) Выходной отчет может быть описан в одном требовании как табличный, а в другом как - текстовый.

2) Одно требование может установить, что все индикаторы должны быть зеленого цвета, а другое требование, что голубого.

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

1) Одно требование может определить, что программа сложит две входных величины, другое - умножит их.

2) Одно требование устанавливает, что событие “A” должно всегда следовать за событием “B”, в то время как, другое требование устанавливает, что события “А” и “B” происходят одновременно.

3) Два или более требований могут описывать один и тот же объект, но использовать различные термины для этого объекта. Например, запрос программы на ввод пользователя может называться "prompt" в одном требовании и "cue" в другом. Использование стандартных терминологии и определений улучшает целостность.

4.3.5 Оцениваемый по важности и/или стабильности (Ranked for importance and/or stability)

СТПО оценивается по важности и/или стабильности, если каждое требование имеет идентификатор, который определяет важность и/или стабильность данного требования.

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

Каждое требование в СТПО должно быть оценено для того, чтобы делать эти различия ясными и явными. Идентификация требований помогает:

a. Потребителям давать более точное толкование каждому требованию, что часто вскрывает неявные предположения,

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

4.3.5.1 Степень стабильности (Degree of stability)

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

4.3.5.2 Степень потребности (Degree of necessity)

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

a) Обязательный. Подразумевает, что программное обеспечение не будет приемлемо, если эти требования не будут включены и согласованы.

b) Условный. Подразумевает, что эти требования улучшат изделие программного обеспечения, но программный продукт будет приемлем и при их отсутствии.

c) Необязательный. Подразумевает класс функций, которые могут заслуживать внимания, а могут и не заслуживать внимания. Это дает поставщику возможность предложить какие-то возможности, выходящие за рамки СТПО.

4.3.6 Проверяемость (Verifiable)

СТПО проверяемо тогда и только тогда, когда каждое требование, определенное в нем, проверяемо. Требование проверяемо тогда и только тогда, когда существует конечный приемлемый по стоимости процесс, с помощью которого человек или машина может проверить, что программное обеспечение выполняет требование. Любое неоднозначное требование не проверяемо.

Непроверяемые требования включают утверждения типа "хорошо работать", "хороший человеческий интерфейс", "будет обычно случаться". Эти требования не проверяемы, потому что невозможно определить термины "хороший", "хорошо", или "обычно". Утверждение "программа никогда не должна входить в бесконечную рекурсию" не проверяемо, потому что испытание этого качества теоретически невозможно.

Пример проверяемого утверждения

Завершение программы должно быть произведено в пределах 20 с в 60 % случаев и в пределах 30 с в l00 % случаев

Это утверждение проверяемо, потому что использует конкретные термины, измеримые количественно.

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

4.3.7 Изменяемость (Modifiable)

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

a) Иметь последовательную и удобную в работе структуру с оглавлением, индексом, и явными взаимными ссылками

b) Не быть избыточным; то есть одно и то же требование не должно встречаться больше чем одном месте в СТПО

c) Выражать каждое требование предпочтительнее отдельно, чем смешанным с другими требованиями

Сама по себе избыточность не является ошибкой, но она может легко приводить к ошибкам. Избыточность может иногда помогать делать СТПО удобочитаемыми, но могут возникать проблемы при изменении документа. Например, если требование было изменено только одном из мест, где оно появляется, то СТПО становится неоднозначным. В случае необходимости избыточности, СТПО должны включить явные перекрестные ссылки.

4.3.8 Трассируемость (Traceable)

СТПО трассируемы, если происхождение каждого из требований ясно и если СТПО обеспечивает легкий доступ к каждому требованию из документации, создаваемой при последующей разработке или из документации, которая расширяет СТПО. Рекомендуется два типа трассируемости.

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

b) Трассируемость вперед (то есть ко всем документам, порожденным СТПО). Это зависит от каждого требования в СТПО, имеющего уникальное имя или ссылочный номер.

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

4.4 Совместная подготовка СТПО (Joint preparation of the SRS)

Процесс разработки программного обеспечения должен начинаться с соглашения поставщика и клиента о том, что законченное программное обеспечение должно делать. Это соглашение в виде СТПО должно быть совместно подготовлено. Это важно, потому что обычно ни клиент, ни поставщик не квалифицированы настолько, чтобы разработать хороший документ в отдельности.

c) Клиенты обычно недостаточно хорошо понимают процесс создания и развития программного обеспечения, чтобы создавать СТПО пригодные к употреблению.

d) Поставщики обычно недостаточно хорошо понимают предметную область клиента, чтобы определить требования для удовлетворительной системы.

Поэтому, клиент и поставщик должны работать вместе, чтобы произвести хорошо написанный и полностью понятный СТПО.

Существует ситуация, когда система и ее программное обеспечение разрабатываются одновременно. Тогда функциональные возможности, интерфейсы, производительность и другие характеристики и ограничения программного обеспечения заранее не определены, а совместно определяются более точно в процессе разработки и являются предметом переговоров и изменений. Это более трудно, но не менее важно, поскольку необходимо обеспечить характеристики, заявленные в 4.3. В частности СТПО, которые не исполняет требования родительской спецификации системы, являются неправильными.

Здесь не обсуждаются стиль, использование языка или методы хорошего языка. Это весьма важно, поскольку СТПО должны иметь хороший язык. Для руководства могут использоваться пособия по созданию технических книг.

4.5 Развитие СТПО (SRS evolution)

СТПО могут развиться, поскольку изделия программного обеспечения улучшается. Бывает не всегда возможным определить некоторые детали к тому времени, когда проект начинается. Например, бывает невозможным определить все форматы экрана для диалоговой программы на стадии разработки требований. Дополнительные изменения могут возникать при обнаружении в СТПО отсутствующих частей, недостатков и погрешностей.

В этом процессе необходимо учитывать два следующих главных момента:

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

b) Формальный процесс изменения должен быть начат, чтобы идентифицировать, управлять, отслеживать и формировать отчеты об изменениях. Утвержденные изменения в требованиях должны быть включены в СТПО так, чтобы

1) Обеспечить точный и полный контроль изменений.

2) Разрешить просмотр текущих и измененных частей СТПО

4.6 Прототипирование (Prototyping)

Прототипирование часто используется на этапе разработки требований проекта. Имеется много инструментов, которые позволяют из шаблона, путем задания параметров легко и быстро получать прототипы системы. См. также ASTM Std 1340-90.

Прототипы полезны по трем причинам:

a) Очень вероятно, что клиент захочет рассмотреть прототип и реагировать на него, а не читать СТПО и реагировать на него. Таким образом, опытный образец обеспечивает быструю обратную связь.

b) Опытный образец показывает непредвиденные аспекты поведения систем. Таким образом, он не только отвечает на возникшие вопросы, но и задает новые. Это помогает достичь завершения разработки СТПО.

c) Основанные на опытном образце СТПО имеют тенденцию подвергаться меньшему количеству изменений в течение разработки, таким образом, время разработки укорачивается.

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

4.7 Включение проекта в СТПО (Embedding design in the SRS)

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

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

a) Разделение программного обеспечения на модули

b) Распределение функций по модулям

c) Описание потока информации или взаимодействия между модулями

d) Выбор структур данных

4.7.1 Необходимые требования проекта (Necessary design requirements)

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

a) Держать некоторые функции в отдельных модулях

b) Разрешить ограниченную связь между некоторыми областями программы

c) Проверить целостность данных для критических переменных

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

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

4.8 Включение требований проектирования в СТПО (Embedding project requirements in the SRS)

СТПО должны определять изделие программного обеспечения, а не процесс его создания.

Проектные требования дают понимание между клиентом и поставщиком относительно договорных вопросов, имеющих отношение к производству программного обеспечения и таким образом не должны включаться в СТПО. Обычно это такие пункты

a) Стоимость

b) План-графики поставки

c) Отчетные мероприятия

d) Методы разработки программного обеспечения

e) Гарантии качества

f) Испытания и критерии проверки

g) Процедуры приемки

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

5 Разделы СТПО (The parts of an SRS)

В этом разделе обсуждается каждая из необходимых частей СПТО. Разделы расположенные на схеме, показанной на рис. 1 могут служить образцом для разработки СТПО.

1. Введение

1.2 Границы применения

1.3 Термины, акронимы, сокращения

1.5 Краткий обзор

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

2.1 Перспективы изделия

2.2 Функции изделия

2.3 Характеристики пользователя

2.4 Ограничения

2.5 Предположения и зависимости

3. Детальные требования (См. 5.3.1-5.3.8 для объяснений возможных детальных требований. См. также приложение A для нескольких различных структур этого раздела СТПО)

Приложения

Индексы

Рисунок 1 Образец схемы СТПО

Хотя СТПО не обязательно должна следовать приведенному плану или использовать данные названия разделов, правильная СТПО должна включать всю информацию, которая здесь обсуждается.

5.1 Введение (Introduction) (Раздел 1 СТПО)

Введение СТПО должно обеспечить краткий обзор всего СТПО. Оно должно содержать следующие подразделы:

b) Границы применения

c) Определения, акронимы (аббревиатуры) и сокращения

d) Краткий обзор

5.1.1 Цели (Purpose) (1.1 из СТПО)

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

a) Очертить цель детальных СТПО

b) Определить аудиторию, для которой предназначено СТПО

5.1.2 Границы применения (Scope) (1.2 из СТПО)

Этот подраздел должен

c) Идентифицировать изделие (я) программного обеспечения, которое будет произведено, наименование (например, “Серверная СУБД”, “Генератор Отчетов” и т.д.)

d) Объяснить, что изделие (я) программного обеспечения будет, и, если необходимо, не будет делать

e) Описать применения определяемого программного обеспечения, включая важные преимущества, объекты и цели

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

5.1.3 Термины, акронимы (аббревиатуры), сокращения (Definitions, acronyms, and abbreviations) (1.3 из СТПО)

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

Этот подраздел должен

a) Обеспечить полный список всех документов, упомянутых в каком либо месте в СТПО

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

Эта информация может быть обеспечена посредством ссылок на одно или большее количество приложений к СТПО или посредством ссылок на другие документы.

5.1.5 Краткий обзор (Overview) (1.5 из СТПО)

Этот подраздел должен

a) Описать, что содержит остальная часть СТПО

b) Объяснить, как СТПО структурировано

5.2 Общее описание (Overall description) (Раздел 2 из СТПО

Эта раздел СТПО должен описать общие факторы, которые затрагивают изделие и требования. Этот раздел не определяет специфические требования. Вместо этого, он обеспечивает, основу для их подробного определения в разделе 3, и делает их более легкими для понимания.

Этот раздел обычно состоит из шести следующих подразделов:

a) Описание изделия

b) Функции изделия

c) Характеристики пользователей

d) Ограничения

e) Предположения и зависимости

f) Поднаборы требований

5.2.1 Описание изделия (Product perspective) (2.1 из СПТО)

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

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

Этот подраздел должен также описать, как программное обеспечение соответствует различным внутренним ограничениям. Например, он мог бы включать:

a) Интерфейсы системы

b) Интерфейсы пользователя

c) Интерфейсы аппаратных средств ЭВМ

d) Интерфейсы программного обеспечения

e) Интерфейсы коммуникаций

f) Ограничения памяти

g) Функционирование (Operations)

h) Требования настройки рабочих мест

5.2.1.1 Интерфейсы системы (System interfaces)

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

5.2.1.2 Интерфейсы пользователя (User interfaces)

Необходимо определить:

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

b) Все аспекты оптимизации интерфейса между продуктом программного обеспечения и пользователями, которые этот продукт используют. Это может просто включать список того, что система должна и чего она не должна делать с точки зрения пользователя. Одним из примеров является требование выбора длинных или коротких сообщений об ошибках. Аналогично другим требованиям эти требования должны быть проверяемыми, например, " машинистка 4-го разряда может выполнять функцию X за Z минут после 1 часа обучения" предпочтительнее, чем "машинистка может выполнять функцию X" (Это может также быть определено в системных характеристиках программного обеспечения под разделом, озаглавленным “Удобство использования” (Ease of Use)).

5.2.1.3 Интерфейсы аппаратных средств ЭВМ (Hardware Interfaces)

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

5.2.1.4 Интерфейсы программного обеспечения (Software Interfaces)

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

a) Наименование

b) Мнемоническое наименование

c) Номер спецификации

d) Номер версии

e) Источник Для каждого интерфейса необходимо обеспечить следующее:

a) Обсуждение назначения взаимодействующих программ по отношению к данному продукту.

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

5.2.1.5 Интерфейсы коммуникаций (Communications interfaces)

Здесь необходимо определить различные интерфейсы средств связи типа протоколов локальной сети и т.д.

5.2.1.6 Ограничения памяти (Memory constraints)

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

5.2.1.7 Действия (Operations)

Здесь необходимо определить нормальные и специальные действия, необходимые пользователям, типа

a) Различные способы действий в организации пользователя; например операции, инициируемые пользователем

b) Периоды диалоговых действий и периоды оставленных без отклика действий

c) Функции поддержки обработки данных

d) Действия резервного копирования и восстановления

ПРИМЕЧАНИЕ – этот пункт иногда определяется как часть раздела интерфейсов пользователя.

5.2.1.8 Требования настройки рабочих мест (Site adaptation requirements)

Здесь необходимо

a) Определить требования для любых данных или командных строк (initialization sequences), которые определяются для данного рабочего места, задачи, или режима эксплуатации, например, разрешение экрана (grid values), пределы безопасности (safety limits) и т.д.

b) Определите характеристики рабочего места или решаемых задач, которые должны быть изменены, чтобы настроить программное обеспечение на специальную конфигурацию.

5.2.2 Функции изделия (Product functions) (2.2 из СТПО)

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

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

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

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

5.2.3 Характеристики пользователей (User characteristics) (2.3 из СТПО)

Этот подраздел СТПО должен описывать те общие характеристики пользователей, для которых предназначены изделия, включая образовательный уровень, опыт, и техническую квалификацию. Не следует использовать этот раздел для того, чтобы Стр.22

Внешние стандарты

IEEE Std 830-1993

сформулировать детальные требования, здесь скорее необходимо объяснить причины, по которым эти требования появятся позже в разделе 3 СТПО.

5.2.4 Ограничения (Constraints) (2.4 из СТПО)

Этот подраздел СТПО должен обеспечить общее описание любых других факторов, которые ограничивают выбор разработчика. Они включают:

a) Регулирующую политику

b) Ограничения аппаратных средств ЭВМ (например, требования по времени выбора)

c) Интерфейсы с другими приложениями

d) Параллельную работу

e) Функции протоколирования

f) Функции управления

g) Требования к языкам высокого уровня

h) Протоколы интерфейсов синхронизации сигналов (например, XON-XOFF, ACK-NACK)

i) Требования надежности

j) Критичность приложения

k) Соображения безопасности и секретности

5.2.5 Предположения и зависимости (Assumptions and dependencies) (2.5 из СТПО)

Этот подраздел СТПО определяет перечень факторов, которые затрагивают требования, определенные в СТПО. Эти факторы не являются ограничениями на программное обеспечение проекта, но любое их изменение может затронуть требования в СТПО. Например, может быть предположение, что на аппаратных средствах ЭВМ, предназначенных для изделия программного обеспечения, будет доступна определенная операционная система. Если, фактически, операционная система не доступна, СТПО должны были бы измениться.

5.2.6 Распределение требований (Apportioning of requirements) (2.6 из СТПО)

Этот подраздел СТПО должен определить требования, которые могут быть отсрочены до будущих версий системы.

5.3 Детальные требования (Specific requirements) (Секция 3 из СТПО)

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

Поскольку это - часто самая большая и наиболее важная часть СТПО, то необходимо применять следующие принципы:

a) Детальные требования должны быть заявлены в соответствии с правилами, описанными в 4.3 данного стандарта.

b) Детальные требования должны иметь перекрестные ссылки к более ранним документам, к которым имеют отношение.

c) Все требования должны быть уникально идентифицированы.

d) Для повышения удобочитаемости необходимо особое внимание уделить структурированию требований.

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

5.3.1 Внешние интерфейсы (External interfaces)

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

a) Наименование пункта

b) Описание цели

c) Источник входных или назначение выходных данных

d) Диапазон допустимых значений, точность и/или допустимые отклонения

e) Единицы измерения

f) Временные характеристики

g) Отношения к другим входам / выходам

h) Форматы / организация экрана

i) Форматы / организация окна

j) Форматы данных

k) Форматы команд

l) Конечные сообщения

5.3.2 Функции(Functions)

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

Описание включает:

a) Проверку допустимости данных на входах

b) Точную последовательность действий

c) Действия при возникновении исключительных ситуаций, включая

1) Переполнение

2) Средства связи (Communication facilities)

3) Обработку ошибок и восстановление

d) Влияние параметров

e) Отношения входных данных к выходным данным, включая

1) Последовательности Входных данных / выходных данных

2) Формулы для преобразования входных данных в выходные

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

5.3.3 Требования исполнения (Performance requirements)

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

a) Число терминалов, которое должны быть поддержаны

b) Количество одновременно работающих пользователей, которое должно быть поддержано

c) Количество и тип информации, которая должна обрабатываться

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

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

Все эти требования должны быть заявлены в терминах единиц измерения.

Например, 95 % сделок должны быть обработаны меньше чем 1 s предпочтительнее чем, оператор не должен ждать, чтобы завершить сделку.

ПРИМЕЧАНИЕ - численные ограничения, применяемые к одной специфической функции обычно определяются как часть подпараграфа описания работы этой функции.

5.3.4 Требования логики базы данных (Logical database requirements)

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

d) Типы информации, используемые различными функциями

e) Частота использования

f) Способы доступа.

g) Сущности данных и их отношения

h) Ограничения целостности

i) Требования хранения данных

5.3.5 Ограничения проекта (Design constraints)

Здесь определяются ограничения разработки, которые могут накладываться другими стандартами, ограничениями аппаратных средств ЭВМ и т.д.

5.3.5.1 Соглашение о стандартах (Standards compliance)

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

a) Формат сообщений

b) Именование данных

c) Отчетные процедуры (Accounting procedures)

d) Протоколирование (Audit tracing)

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

5.3.6 Характеристики программного обеспечения системы (Software system attributes)

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

5.3.6.1 Надежность (Reliability)

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

5.3.6.2 Эксплуатационная готовность (Availability)

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

5.3.6.3 Безопасность (Security)

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

a) Использовать некоторые методы шифрования

c) Назначать некоторые функции в различные модули

d) Ограничить связи между некоторыми областями программы

e) Проверять целостность данных для критических переменных

5.3.6.4 Ремонтопригодность (Maintainability)

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

5.3.6.5 Переносимость (Portability)

Здесь определяются параметры программного обеспечения, которые касаются легкости переноса программного обеспечения на другие машины и/или операционные системы. Может включать:

f) Процент компонентов с машинозависимым кодом

g) Процент кода, который является машинозависимым

h) Использование проверенного переносимого языка

i) Использование конкретного компилятора или поднабора языков

j) Использование конкретной операционной системы

5.3.7 Структурирование детальных требований (Organizing the specific requirements)

Для нетривиальных систем детальные требования могут быть обширными. По этой причине, рекомендуется обеспечивать такое их структурирование, которое делает их оптимальными для понимания. Не существует оптимальной структуры для всех систем. Различные способы структурирования требований для различных классов систем предоставлены в разделе 3 СТПО. Некоторые структуры описаны в следующих подразделах.

5.3.7.1 Режим системы (System mode)

Некоторые системы ведут себя весьма различно в зависимости от режима работы. Например, система управления может иметь различные наборы функций в зависимости от использования: обучение, нормальная или аварийная ситуация. При организации деления на режимы используйте схемы, показанные в разделах 1 или 2 приложения A. Выбор определяется тем, зависят ли интерфейсы и выполнение программы от режима работы.

5.3.7.2 Классы пользователей (User class)

Некоторые системы обеспечивают различные наборы функций для различных классов пользователей. Например, система управления подъемника представляет различные возможности пассажирам, рабочим обслуживания и пожарным. При организации этого раздела используйте схему, показанную в разделе 3 приложения A.

5.3.7.3 Объекты (Objects)

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

показанную в разделе 4 приложения A. Обратите внимание, что наборы объектов могут разделяться по атрибутам и услугам. Они сгруппированы вместе как классы.

5.3.7.4 Особенности (Feature)

Особенность – желаемый извне сервис, предоставляемый системой, который может требовать последовательность входных данных, чтобы произвести желательный результат. Например, в телефонной системе особенности включают внутригородской звонок, ускоренный вызов и вызов конференции. Каждая особенность вообще описывается в последовательности пар воздействие - реакция. При организации этого раздела используйте схему, показанную в разделе 5 в приложении A.

5.3.7.5 Воздействие (Stimulus)

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

5.3.7.6 Реакция (Response)

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

5.3.7.7 Функциональные иерархии (Functional hierarchy)

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

5.3.8 Дополнительные комментарии (Additional comments)

Когда определено новое требование, оно может соответствовать нескольким способам структурирования, описанным в 5.3.7.7. В таких случаях, структурируйте детальные требования во множественные иерархии, приспособленные к специальным потребностям специфицируемой системы. Например, см. 8 в приложении A для организации, объединяющей класс пользователя и особенность. Любые дополнительные требования могут быть помещены в отдельный раздел в конце СТПО.

Существует большое количество доступных описаний, методов и автоматизированных инструментов поддержки, помогающих в документировании требований. Главным образом, их ценность - это функция структурирования. Например, при структурировании по режимам (when organizing by mode), могут быть полезными конечные автоматы или диаграммы состояний; при структурировании по объектам, может быть полезным объектно-ориентированный анализ; при структурировании по особенностям могут быть полезными последовательности «воздействие – реакция»; при

структурировании по функциональной иерархии могут быть полезными диаграммы потоков данных и словари данных.

В любой из схем, приведенных в 1-8, разделы, которые именуются как "Функциональные Требования", могут быть написаны на родном языке (например, Английский язык), в псевдокодах, на языке описания систем, или в виде четырех подразделов: Введение, Входы, Обработка (Processing), Выходы.

5.4 Информационная поддержка (Supporting information)

Информационная поддержка облегчает использование СТПО. Она включает

b) Индексы

c) Приложения

5.5 Приложения (Appendixes)

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

a) Образцы форматов ввод - вывода, описания анализа стоимости обучения, или результатов обследования пользователей

b) Сопровождающая или подготовительная информация, которая может помочь читателям СТПО

c) Описание проблем, которые будут решены с помощью программного обеспечения

d) Специальные упаковочные инструкции (Special packaging instructions) для кода и информационные средства, необходимые для обеспечения безопасности, экспорта, начальной загрузку или другие требования

Если имеются приложения, СТПО должны явно объявить, рассматриваются или нет приложения как часть требований.

6 Приложение A (Информативно)

6.1 Шаблон раздела 3 СТПО организованный по режимам: Версия 1
3 Детальные требования
3.1 Требования на внешние интерфейсы



3.1.4 Интерфейсы связи

3.2.1 Режим 1

3.2.2 Режим 2
3. 2. m. Режим m
3. 2. m.1 Функциональное требование м.
3. 2. m.n Функциональное требование m.n
3.3 Требования исполнения
3.4 Ограничения проекта

3.6 Другие требования
6.2 Шаблон раздела 3 СТПО организованный по режимам: Версия 2
3. Детальные требования
3.1. Функциональные требования
3.1.1 Режим 1
3.1.1.1 Внешние интерфейсы
3. 1.1.1.1 Интерфейсы пользователя
3. 1.1.1.2 Интерфейсы аппаратных средств ЭВМ
3. 1.1.1.3 Интерфейсы программного обеспечения
3. 1.1.1.4 Интерфейсы связи
3.1.1.2 Функциональные требования
3.1.1.2.1 Функциональных требование 1
3.1.1.2.n Функциональное требование n
3.1.1.3 Требования исполнения
3.1.2 Режим 2
3.1.m. Режим m.
3.2 Ограничения проекта
3.3 Характеристики программного обеспечения системы
3.4 Другие требования
6.3 Шаблон раздела 3 СТПО организованный по классам пользователей
3 Детальные требования

3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Класс пользователя 1
3.2.1.1 Функциональное требование 1.1
3.2.1.n Функциональное требование 1. n
3.2.2 Класс пользователя 2
3.2.m. Класс пользователя m.


3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.4 Шаблон раздела 3 СТПО организованный по объектам
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Классы / объекты
3.2.1 Класс / объект 1
3.2.1.1 Атрибуты (собственные или унаследованные)
3.2.1.1.1 Атрибут 1
3.2.1.1.n Атрибут n
3.2.1.2 Функции (методы. Собственные или унаследованные)
3.2.1.2.1 Функциональное требование 1.
3.2.1.2.m Функциональное требование m
3.2.1.3 Сообщения (полученные или отправленные)
3.2.2 Класс / объект 2
3.2.p Класс / объект p
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.5 Шаблон раздела 3 СТПО организованный по особенностям
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Особенности системы
3.2.1 Особенность системы 1
3.2.1.1 Введение / цель
3.2.1.2 Последовательность воздействие / реакция
3.2.1.3 Связанные функциональные требования
3.2.1.3.1 Функциональное требование 1
3.2.1.2.n Функциональное требование n
3.2.2 Особенность системы 2
3.2.m Особенность системы m.
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.6 Шаблон раздела 3 СТПО организованный по воздействиям
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Воздействие 1
3.2.1.1 Функциональное требование 1.1
3.2.1.n Функциональное требование l.n
3.2.2 Воздействие 2
3.2.m Воздействие m
3.2.m.1 Функциональное требование m.1
3.2.m.n Функциональное требование m.n
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.7 Шаблон раздела 3 СТПО организованный по функциональной иерархией
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Информационные потоки
3.2.1.1 Диаграмма потока данных 1
3.2.1.1.1 Сущности данных
3.2.1.1.2 Подходящие процессы (Pertinent processes)
3.2.1.1.3 Топология (Topology)
3.2.1.2 Диаграмма потока данных 2
3.2.1.2.1 Сущности данных
3.2.1.2.2 Подхордящие процессы (Pertinent processes)
3.2.1.2.3 Топология (Topology)
3.2.1.n Диаграмма потока данных n
3.2.1.n.1 Сущности данных
3.2.1.n.2 Подходящие процессы (Pertinent processes)
3.2.1.n.3 Топология (Topology)
3.2.2 Описание процессов
3.2.2.1 Процесс 1
3.2.2.1.1 Сущности данных на входе
3.2.2.1.2 Алгоритм или формула процесса
3.2.2.1.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.2.2 Процесс 2
3.2.2.2.1 Сущности данных на входе
3.2.2.2.2 Алгоритм или формула процесса
3.2.2.2.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.2.m Процесс m
3.2.2.m.1 Сущности данных на входе
3.2.2.m.2 Алгоритм или формула процесса
3.2.2.m.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.3 Спецификации структур данных
3.2.3.1 Структура 1
3.2.3.1.1 Тип записи
3.2.3.1.2 Элементарные поля
3.2.3.2 Структура 2
3.2.3.2.1 Тип записи
3.2.3.2.2 Элементарные поля
3.2.3.p Структура p
3.2.4 Словарь данных
3.2.4.1 Элемент данных 1
3.2.4.1.1 Наименование
3.2.4.1.2 Представление
3.2.4.1.3 Единицы / формат
3.2.4.1.4 Точность представления / точность округления (Precision/Accuracy)
3.2.4.1.5 Диапазон значений
3.2.4.2 Элемент данных 2
3.2.4.2.1 Наименование
3.2.4.2.2 Представление
3.2.4.2.3 Единицы / формат
3.2.4.2.4 Точность представления / точность окрудления (Precision/Accuracy)
3.2.4.2.5 Диапазон значений
3.2.4.1.q Элемент данных q
3.2.4.q.1 Наименование
3.2.4.q.2 Представление
3.2.4.q.3 Единицы измерения / формат
3.2.4.q.4 Точность представления / точность округления (Precision/Accuracy)
3.2.4.q.5 Диапазон
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.8 Шаблон раздела 3 СТПО показывающий множественную организацию
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Класс пользователей 1
3.2.1.1 Особенность 1.1
3.2.1.1.1 Введение / цель
3.2.1.1.2 Последовательность воздействие / реакция
3.2.1.1.3 Связанные функциональные требования
3.2.1.2 Особенность 1.2
3.2.1.2.1 Введение / цель
3.2.1.2.2 последовательность Стимула / ответа
3.2.1.2.3 Связанные функциональные требования
3.2.1.m. Особенность 1.m
3.2.1.m.1 Введение / цель.
3.2.1.m.2 Последовательность воздействие / реакция
3.2.1.m.3 Связанные функциональные требования
3.2.2 Класс пользователей 2
3.2.n Класс пользователей n
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования

• Вконтакте

ГОСТ Р 56376-2015/IEEE С37.92(2005)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Преобразователи электрические измерительные

АНАЛОГОВЫЕ ВХОДЫ ЗАЩИТНЫХ РЕЛЕ ОТ ЭЛЕКТРОННЫХ ПРЕОБРАЗОВАТЕЛЕЙ НАПРЯЖЕНИЯ И ТОКА

Electrical transducers. Analog inputs to protective relays from electronic voltage and current transducers

ОКС 17.020

Дата введения 2016-01-01

Предисловие

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт метрологической службы" (ФГУП "ВНИИМС") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 445 "Метрология энергоэффективной экономики"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 марта 2015 г. N 192-ст

4 Настоящий стандарт идентичен международному стандарту IEEE Standard С37.92(2005)* "Стандарт к аналоговым входам терминалов релейной защиты, подключаемых к электронным преобразователям напряжения и тока" (IEEE Standard С37.92(2005) "IEEE Standard for analog inputs to protective relays from electronic voltage and current transducers", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей . - Примечание изготовителя базы данных.


Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Апрель 2019 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации" . Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

1.1 Общие положения

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

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

1.2 Цели

Нормированный измерительный сигнал между системой измерения и системами релейной защиты является аналоговым электрическим сигналом с максимальной амплитудой ±11,3 В и с максимальной мощностью 3,2 мВт.

Примером измерительной системы с аналоговым электронным выходом является оптическая система трансформаторов напряжения или тока с оптико-электронным интерфейсом. На рисунке 1 изображена типовая конфигурация элементов оптической системы измерения тока на высоковольтной подстанции. В данной конфигурации оптические датчики трансформаторов тока располагаются на шине высокого потенциала. В других случаях датчики могут быть вмонтированы внутрь силового трансформатора или изолятора. Оптические сигналы передаются через волоконно-оптические кабели до потенциала земли, где преобразуются в масштабированные и нормированные электрические сигналы, используемые реле защиты и другими интеллектуальными электронными устройствами (ИЭУ).

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

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

Рисунок 1 - Оптическая система измерения тока с нормированным аналоговым интерфейсом

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок используют только указанное издание. Для недатированных - последнее издание (включая все поправки и изменения).

IEEE Std 525™, IEEE Guide for the Design and Installation of Cable Systems in Substations (Руководство по конструкции и установке кабельных систем на подстанциях)
_______________
IEEE публикации можно приобрести в Институте инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers), расположенном по адресу: Inc., 445 Hoes Lane, Piscataway, NJ 08854, США (http://standards.ieee.org/).


IEEE Std 1050™, IEEE Guide for Instrumentation and Control Equipment Grounding in Generating Stations (Руководство по оснащению и заземлению контрольно-измерительной аппаратуры на электростанциях)

IEEE Std С37.90™, IEEE Standard for Relays and Relay Systems Associated with Electric Power Apparatus (Реле и релейные системы, используемые для защиты и управления силовыми аппаратами)

IEEE Std С37.90.1™, IEEE Standard Surge Withstand Capability (SWC) Tests for Relay and Relay Systems Associated with Electric Power Apparatus (Испытания на устойчивость к скачкам напряжения реле и релейных систем, используемых для защиты и управления силовыми аппаратами)

IEEE Std С37.90.2™, IEEE Standard for Withstand Capability of Relay Systems to Radiated Electromagnetic Interference from Transceivers (Устойчивость релейных систем к излучаемым электромагнитным помехам от приемопередатчиков)

IEEE Std С57.13™, IEEE Standard Requirements for Instrument Transformers. IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/) (Требования к измерительным трансформаторам)

3 Термины и определения

В настоящем стандарте приняты следующие термины и определения. Термины, не представленные в настоящем стандарте, можно найти в седьмой редакции официального словаря стандартов IEEE (The Authoritative Dictionary of IEEE Standards, Seventh Edition).

3.1 одна относительная единица (one per unit (сокращенно: 1 p.u.): Измеренное выходное значение или выход измерительной системы, которые соответствуют номинальному первичному действующему (rms) измеряемому значению напряжения или тока в схеме измерения.

3.2 вход реле (relay input): Аналоговый электронный вход любого терминала релейной защиты, счетчика, измерительного или контрольного прибора, а также интеллектуального электронного устройства, соответствующий настоящему стандарту.

3.3 измерительная система (sensing system): Электронный датчик, прибор, оптико-электронный интерфейс или источник аналогового сигнала, формирующий значения измеряемого напряжения или тока в электрической сети, выход которых соответствует настоящему стандарту.

4 Общие требования

4.1 Соединительные устройства

Выход измерительной системы и вход реле должны быть оснащены широкодоступными стандартными разъемами, выдерживающими высокопотенциальные выбросы в соответствии с требованиями 4.4. Разъемы должны быть спроектированы таким образом, чтобы обеспечить простоту подключения и концевой заделки кабеля. Клеммы с винтовым креплением являются предпочтительным решением. Каждый вход или выход включает в себя пару сигнальных клемм, маркируемых согласно 4.3. Поставщик оборудования должен обеспечить дополнительные незаземленные клеммы или средства для подключения экранов согласно 7.

4.2 Гальваническая изоляция от земли

Обе выходные клеммы измерительной системы и любой вход реле должны быть изолированы от защитного заземления или заземления корпуса при воздействии сигналов постоянного тока или тока промышленной частоты. Емкость, допустимая между любой клеммой и землей, не должна превышать 0,01 мкФ.

4.3 Маркировка полярности и устойчивость к реверсивной полярности

Интерфейсы должны иметь маркировку полярности, состоящую из традиционных "cts" и "vts". См. IEEE Std С57.13.
_______________
Информация по ссылкам указана в разделе 2.


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

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

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

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

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

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

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

Примечание - Внутренние или программные настройки конкретного реле защиты могут изменять полярность входа;


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

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

Симметричные или реверсируемые выходные клеммы должны быть симметричны по отношению к земле.

4.4 Дополнительные выходы измерительных систем

4.4.1 Выход сигнала предупреждения

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

Этот выход должен быть выполнен в виде контакта типа "С", непотенциального, и специфицирован производителем измерительной системы. При нормальных корректных рабочих условиях эксплуатации обмотка (катушка) реле должна быть всегда запитана для того, чтобы при потере питания подать сигнал тревоги, так же как и при наличии неисправности измерительной системы.

4.4.2 Выход сигнала корректности передаваемых данных

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

Этот выход может быть выполнен в виде одной или обеих из перечисленных ниже форм:

- контакт типа "А", без потенциала, и специфицирован производителем измерительной системы. При нормальных корректных рабочих условиях эксплуатации обмотка (катушка) реле должна быть всегда запитана для того, чтобы подать сигнал или обеспечить защитную блокировку некорректного сигнала на выходе. Контакт должен быть выполнен согласно IEEE Std С37.90. Задержка блокировки выхода при триггерном эффекте (дребезге контактов) не должна превышать 12 мс;

- логический ТТЛ-уровень (от 0 до 5 В) имеет отклик 1 мс или быстрее (см. 5.8). При этом логический уровень (5 В) означает корректность передаваемых данных.

4.5 Испытание на электромагнитную совместимость

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

4.5.1 Диэлектрические испытания

Эти испытания должны проводиться согласно методам проведения диэлектрических испытаний, описанных в IEEE Std С37.90. Испытательное напряжение прикладывают только в синфазном режиме между каждой парой входных или выходных клемм и защитным заземлением или заземлением корпуса. Сигнальные цепи до 50 В испытывают более низким испытательным диэлектрическим напряжением, согласно IEEE Std С37.90.

5.1.1 Описание сигнала для измерительной системы тока

Динамический диапазон: от 0,05 до 40 номинального значения;

Номинальный уровень на выходе ( или 1 р.u.): 200 мВ (rms);

Максимальное мгновенное значение: 0,200х40х1,414=11,3 В (пиковое).

Амплитудная и фазовая погрешности - это максимальное отклонение от действительного значения масштабированного первичного сигнала при 50 или 60 Гц.

Таблица 1 - Описание сигнала для токовой измерительной системы

Диапазон тока	Амплитудная погрешность	Фазовая погрешность
От 0,05 p.u. до 0,1 p.u.
От 0,10 p.u. до 1,0 p.u.
От 1,0 p.u. до 5,0 p.u.
От 5,0 p.u. до 40 p.u.

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

Соотношение сигнал - шум должно быть больше или равно 54 дБ при сигнале более 0,1 p.u. Измерение должно проводиться на сигнале промышленной частоты и полоса измерения шума должна находиться в пределах 120 Гц.

Система измерения тока может быть снабжена дополнительным выходом с номинальным уровнем 2 В (действующее) при 1 p.u., с максимальным значением выхода в 4 p.u. Этот выход предназначен для тех применений, где необходимая величина точности измерения выше общепринятой. Для применения в целях коммерческого учета производитель датчика должен отдельно подтвердить его соответствие с соответствующим стандартом на точность, таким как IEEE Std С57.13 или его частями.

5.1.2 Описание сигнала для измерительных систем напряжений

Динамический диапазон от 0,05 до 2,0 номинального значения.

Номинальный уровень на выходе ( или 1 р.u.): 4 В (действующее).

Максимальный выход: 4,0х2,0х1,414=11,3 В (пиковое).

Амплитудная и фазовая погрешности - это максимальное отклонение от значения действительного масштабированного первичного сигнала при 50 или 60 Гц.

Таблица 2 - Описание сигнала системы измерения напряжения

Диапазон напряжения	Амплитудная погрешность	Фазовая погрешность
От 0,05 p.u. до 0,85 p.u.
От 0,85 p.u. до 1,15 p.u.
От 1,15 p.u. до 2,0 p.u.

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

Соотношение сигнал - шум должно быть больше или равно 70 дБ при сигнале более 0,85 p.u. Измерения должны быть выполнены с использованием сигнала промышленной частоты и полосы частот пропускания измерения уровня шума как минимум 120 Гц.

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

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

5.2 Фазовая коррекция

Для достижения более высокой точности, производитель измерительной системы может указать значение фазовой коррекции на промышленной частоте, значение которой вводят в виде поправки ко всем значениям для получения более высокой точности, чем указана выше.

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

5.3 Номинальная нагрузка

Точность измерительной системы должна соответствовать требованиям настоящего стандарта при подключении нагрузки порядка 5 кОм и емкостной нагрузки до 5 нФ. Один выход измерительной системы может быть подключен к нескольким реле или другим измерительным устройствам параллельно. Реле или другое подключенное устройство должно иметь входное сопротивление не менее 50 кОм, но и не более 200 кОм.

5.4 Ослабление синфазного сигнала

Ослабление синфазного сигнала для входов и выходов цепей измерения должно быть более, чем 86 дБ при частоте 50 или 60 Гц для сигнала помех общего вида с уровнем до ±50 В. Это значение определено для помех напряжения с уровнем 20 В на входе системы измерения тока, при котором значение тока составляет 0,5 p.u., и когда помеха общего вида составляет менее 10% от измерительного уровня сигнала.

5.5 Отклонение выходного сигнала от нулевой зоны

Установившееся отклонение выходного сигнала от нулевой зоны (смещение постоянной составляющей сигнала на выходе) должно составить менее чем 3 мВ. Это имеет отношение к требованиям к электронике с постоянной составляющей на выходе усилителя, однако это не относится к экспоненциальному затуханию "постоянного смещения сигнала" сигналов токов короткого замыкания.

Установившееся отклонение выходного сигнала от нулевой зоны усилителя должно составить менее чем 3 мВ. Это относится к электронным характеристикам с наличием длительной постоянной составляющей тока на выходе усилителя, но не связано с экспоненциальным затуханием "постоянного смещения сигнала" для сигналов тока короткого замыкания.

5.6 Ширина полосы пропускания и переходная характеристика

Поставщик измерительной системы должен указать частотную характеристику. Отклонение промышленной частоты (частоты сети), указанное в 5.1, должно находиться в пределах от 45 до 65 Гц. Отклик должен быть, по крайней мере, от 0 до -1 дБ в диапазоне до 3 кГц и от 0 до -3 дБ в диапазоне до 5 кГц. Нижняя граничная частота (если таковая присутствует) должна быть установлена такой, что система может соответствовать следующему требованию для ответной реакции по постоянному смещению сигнала.

Для полного смещения экспоненциальной затухающей переходной характеристики первичного тока ("постоянное смещение сигнала") со значением 20 p.u. мгновенная погрешность коэффициента масштабного преобразования не должна превышать 10% для любой постоянной времени в пределах до 100 мс.

Для первичного напряжения переходная характеристика определяется реакцией на ступенчатый импульс, т.е. изменением значения формы импульса в пределах диапазона до нуля, при этом сигнал на выходе измерительной системы должен понижаться до уровня менее чем 10% от его начального значения за время в пределах 4 мс и опускаться ниже 10% только после этого времени.

Некоторые заказчики могут потребовать функционирование системы для частот в диапазоне от 65 до 75 Гц с уменьшенными требованиями к точности. При этом рекомендуется, чтобы поставщик измерительной системы определил требования к техническим характеристикам ее функционирования в этом диапазоне частот.

5.7 Настройка детектирования сигнала ошибки

Выход интерфейса измерительной системы должен быть зафиксирован на нуле в момент определения внутренней неполадки, чтобы не вызвать серьезные неполадки или ложные срабатывания. Это обеспечивается резервным питанием измерительной системы или отключением при переходных режимах. Время от выявления проблемы до ее устранения должно составлять не более 0,2 мс.

Обычно выявление проблемы проводят тем же методом, что и при обнаружении погрешностей, как это делают при проверке корректности при передаче данных с выхода, описанной в 4.4.2.

5.8 Описание сигнала корректности передаваемых данных

Опциональный сигнал, передающий информацию о корректности данных 4.4.2, должен быть сигналом ТТЛ-уровня (0 или 5 В), изолированный от защитного заземления и предназначенный для передачи с использованием того же метода соединения, как и при передаче аналоговых сигналов измерительной системы (см. раздел 7). Логическая единица от 3,0 до 5,5 В информирует о наличии на выходе измерительной системы корректных данных. Логический ноль в диапазоне от 0 до 0,5 В должен сообщать об ошибке данных на выходе измерительной системы. Выход данного опционального сигнала должен обеспечивать напряжения в пределах указанной спецификации при сопротивлении нагрузки 200 Ом или выше. Задержка с момента запускающего события до изменения состояния выхода должна не превышать 1 мс.

Входные цепи в защитном реле для приема данного сигнала должны быть изолированы от защитного заземления и иметь входное сопротивление более чем 2 кОм. При этом сигналы только с уровнем свыше 2,5 В должны быть восприняты как логическая единица.

6 Промежуточные устройства

6.1 Назначение

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

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

6.2 Требования к рабочим характеристикам промежуточных устройств

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

Таблица 3 - Требования к рабочим характеристикам промежуточных устройств

Коэффициент гармоник (суммарное значение коэффициента нелинейных искажений)	Менее 0,1% от 1 p.u. тока в диапазоне от 1 Гц до 20 кГц
Погрешность коэффициента усиления	Менее 0,1% от 1 p.u. тока в диапазоне от 45 Гц до 75 кГц
Фазовая погрешность	Менее 0,1° в диапазоне от 45 Гц до 75 кГц
Частотная характеристика	Устанавливается производителем; линейная в пределах 0 ... -1 дБ в диапазоне от 15 Гц до 10 кГц
Соотношение сигнал - шум	Лучше, чем 80 дБ при 1 p.u. токе или напряжении, с полосой пропускания в пределах до 120 Гц

Требования к рабочим характеристикам усилителя должны быть выполнимы совместно к входным и выходным разъемам. Требования к рабочим характеристикам должны быть определены для единичного коэффициента усиления. Производитель должен указать рабочие характеристики при неединичном коэффициенте усиления.

6.3 Другие требования к промежуточным устройствам

Промежуточные устройства должны соответствовать всем остальным требованиям разделов 4 и 5, но не указанным в 6.2. Они должны соответствовать требованиям в диапазоне рабочих условий применения, условий транспортировки и хранения, указанных в IEEE Std С37.90.

7 Инструкции по монтажу промежуточных устройств

Рисунки 2, 3 и 4 показывают примеры подключения для единичных и множественных источников и нагрузок. Они представлены для того, чтобы проиллюстрировать соответствующие подключения при расстояниях менее 50 м между измерительной системой и наиболее отдаленным входом реле. Экранированные проводники витой пары как правило выполняются в пределах общеподстанционного пункта управления, где разности между нулевыми потенциалами подключенных систем при возникновении короткого замыкания не превышают 20 В. Проводники сечением 24 AWG и больше вполне приемлемы для этих целей. Если несколько витых пар заключены в один общий экран, то взаимное влияние между каналами при дифференциальном включении не должно превышать уровня 70 дБ.

Следует обратить внимание на следующие основные характеристики, общие для всех рисунков:

- проводное подключение предполагает, что оборудование прошло испытание на подавление синфазных сигналов, как указано в разделе 4, и известен коэффициент ослабления синфазного сигнала, как указано в разделе 5;

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

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

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

Рисунок 2 - Одна измерительная система и один вход реле

Рисунок 3 - Одна измерительная система с несколькими входами реле

Рисунок 4 - Несколько измерительных систем и промежуточное устройство

- для обеспечения улучшения высокочастотного электромагнитного экранирования дополнительные керамические дисковые конденсаторы емкостью 10 нФ могут быть установлены между экраном и землей в каждой незаземленной точке подключения экрана. Они могут быть установлены пользователем или располагаться внутри оборудования производителей. Обратите внимание, что установка таких конденсаторов, как правило, приемлема для коротких контрольных кабелей, но представляет проблему для высокочастного экранирования для более длинных контрольных кабелей.

Для подключения коммутационного оборудования, расположенного в ОРУ, где отсутствуют благоприятные условия по качественной высокочастотной электромагнитной экранировке, заказчик должен более тщательно изучить схемы экранирования, заземление экранов и изоляции элементов. См. IEEE Std 525.

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

Приложение А (справочное). Безопасное применение

Приложение А
(справочное)

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

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

А.1 Амплитудно-частотная характеристика в области низких частот

Традиционные преобразователи с железным сердечником реагируют на низкие частоты до тех пор, пока не происходит насыщение устройства переменным током свыше определенного предела вольт на герц. То есть только очень низкие уровни сигнала воспроизводятся такими преобразователями без искажения на низких частотах. Насыщение происходит резко во время текущего полупериода, при этом выходной сигнал полностью и внезапно исчезает вплоть до обратной полярности. Аналоговые электронные измерительные системы, указанные в настоящем стандарте, напротив, могут иметь спад амплитудно-частотной характеристики в области низких частот или полностью пропускать постоянную составляющую сигнала. Включение же низкочастотного фильтра может привести к различным и непредсказуемым переходным процессам, для которых реле и другие высокоскоростные измерительные системы не предназначены. Из специфических явлений можно выделить: смещение точки отсчета, неточный отклик на экспоненциально-затухающие переходные характеристики (появление постоянного напряжения смещения) и низкочастотный затухающий колебательный процесс как реакция на входные переходные характеристики.

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

А.3 Переходная характеристика

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

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

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

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

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

А.4 Фазовая задержка

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

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

В 5.2 описана дополнительная возможность по выбору фазовой коррекции, предоставляемая производителем.

А.5 Нагрузочная способность

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

А.6 Неисправности и аварийные сигналы

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

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

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

А.7 Калибровка

Поставщик обязан обучить пользователя методам, при помощи которых проводится первичная калибровка измерительной системы и поддерживается в дальнейшем. В частности, удостовериться, что поставляемый ИЭУ имеет характеристики, которые могут потребоваться для выполнения методики калибровки.

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

А.8 Цифровые интерфейсы

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

Цифровые интерфейсы требуют спецификации процессов дискретизации, производительности и многоуровневости слоев протокола передачи данных для обмена между измерительной системой и реле. Интерфейсы цифровых данных для предоставления информации об электрической сети представлены в стандартах IЕС 61850-9-1, IEC 61850-9-2, IEC 60044-7 и IEC 60044-8.

Приложение ДА (обязательное). Сведения о соответствии ссылочных международных стандартов национальным стандартам

Приложение ДА
(обязательное)

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
IEEE Std C37.90.1
IEEE Std C37.90.2
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.

Библиография

IEEE Р1331 Draft 8.3, April 1999: Trial use standard for low energy analog signal inputs to protective relaying (Проект 8.3, апрель 1999. Пробный стандарт для защитных реле со слаботочными аналоговыми входами)

УДК 621.3.089.6:006.354
Ключевые слова: преобразователи электрические измерительные, аналоговые входы, защитные реле, преобразователи напряжения и тока

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2019

Цели и задачи методологии проектирования ПО . Основные области проектирования ПО . Этапы создания ПО .

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

Программные средства (Software product) - набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных.

Программный продукт (Software product) - любой набор компьютерных программ, процедур и связанных с ними документации и данных, получаемых в результате разработки ПП и предназначенных для поставки пользователю [ИСО/МЭК 12207]. Примечание. Продукты включают промежуточные продукты и продукты, предназначенные для пользователей типа разработчиков и персонала сопровождения.

Разработка ПО (Software engineering) - форма разработки, которая применяет принципы информатики, информационной технологии, математики и прикладной области к достижению экономичных решений для практических проблем посредством ПО.

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

Программирование - это один из видов деятельности, входящих в цикл разработки программного обеспечения.

Этапы создания ПО

1. Понять природу и сферу применения предлагаемого продукта.

2. Выбрать процесс разработки и создать план.

3. Собрать требования.

4. Спроектировать и собрать продукт.

5. Выполнить тестирование продукта.

6. Выпустить продукт и обеспечить его сопровождение.

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

Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)

Проектирование структуры программы

Кодирование (набор программного кода согласно проектной документации)

Тестирование и отладка

Внедрение программы

Сопровождение программы

Утилизация

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Основные процессы ЖЦ ПО.

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

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

Основные процессы ЖЦ :

Заказ (приобретение);

Действие - инициирование приобретения

Действие – подготовка заявочных предложений

Действие - подготовка и корректировка договора

Действие - надзор за деятельностью поставщика

В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки

Поставка;

Инициирование поставки

Планирование

Разработка;

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

Подготовительная работа

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

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

Анализ требований к ПО

Проектирование архитектуры ПО

Кодирование и тестирование ПО

Интеграция ПО

Квалификационное тестирование ПО

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

Установка ПО

Приемка ПО

Эксплуатация; охватывает действия и задачи оператора – организации, эксплуатирующей систему и включает действия:

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

планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;

определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

Эксплуатация системы

Поддержка пользователей

Процесс сопровождения предусматривает действия и задачи, выполняемые службой сопровождения. В соответствии со стандартом IEEE-90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

Подготовительная работа службы сопровождения включает в себя следующие задачи:

планирование действий и работ, выполняемых в процессе сопровождения;

определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

Анализ проблем и запросов на модификацию ПО

Модификация ПО

Проверка и приемка

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Вспомогательные процессы ЖЦ ПО.

См. пункт 2

Вспомогательные процессы ЖЦ :

Документирование ; формализованное описание информации, созданной в течение ЖЦ ПО.

Процесс документирования включает действия:

подготовительную работу;

проектирование и разработку;

выпуск документации;

сопровождение

Управление конфигураци ей; для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности ПО, управления хранением и поставкой ПО. Согласно стандарте IEEE - 90 под конфигурацией ПО понимается совокупность ее функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.

подготовительную работу

идентификацию конфигурации устанавливает правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПО и их версии

контроль конфигурации предназначен для систематической оценки предполагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение

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

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

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

Обеспечение качества;

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

Процесс обеспечения качества включает действия:

подготовительная работа

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

обеспечение качества процесса соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным обеспечение прочих показателей качества системы

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

подготовительную работу;

верификацию;

В процесс верификации проверяются следующие условия:

непротиворечивость требований к системе и степень учета потребностей пользователей;

возможности поставщика выполнять заданные требования;

соответствие выбранных процессов ЖЦ ПО условиям договора;

адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

соответствие проектных спецификаций ПО заданным требованиям;

корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

соответствие кода проектным спецификациям и требованиям;

тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

корректность интеграции компонентов ПО в систему;

адекватность, полнота и непротиворечивость документации.

Аттестация ;

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

Совместная оценка (Совместный анализ); для оценки состояния работ по проекту и ПО.

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

Процесс совместной оценки включает действия:

подготовительную работу;

оценку (анализ) управления проектом;

техническую оценку.

Аудит ;

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

Разрешение (Решение) проблем .

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Организационные процессы ЖЦ ПО. Взаимосвязь между процессами ЖЦ ПО.

См пункт2

Организационные процессы ЖЦ :

Управление;

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

Процесс управления включает следующие действия:

подготовка и определение области управления . Менеджер должен убедиться, что необходимые для управления ресурсы (персонал, оборудование и технология) имеются в его распоряжении в достаточном количестве;

планирование подразумевает выполнение, как минимум, следующих задач:

составление графиков выполнения работ;

оценку затрат;

выделение требуемых ресурсов;

распределение ответственности;

оценку рисков, связанных с конкретными задачами;

создание инфраструктуры управления.

выполнение и контроль;

проверка и оценка;

завершение.

Создание инфраструктуры;

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

Усовершенствование;

предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

Обучение.

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

Взаимосвязь между процессами ЖЦ ПО

Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (рис.1). Такими аспектами являются:

договорный аспект;

аспект управления;

аспект эксплуатации;

инженерный аспект;

аспект поддержки.

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

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

Понятие модели и стадии ЖЦ ПО. Характеристика стадий создания ПО .

1) Международный стандарт ISO / IEC 12207: 1995 так определяет модель ЖЦ:

Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий, задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

2) ГОСТ Р ИСО/ МЭК 12207-99 так определяет модель ЖЦ:

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

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

В состав ЖЦ ПО обычно включают следующие стации:

Формирование требований к ПО.

Проектирование.

Реализация.

Тестирование.

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

Эксплуатация и сопровождение.

Снятие с эксплуатации.

Понятие модели жизненного цикла программного обеспечения. Водопадная (каскадная) модель жизненного цикла программного обеспечения.

См пункт 5

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 2). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена командой специалистов на следующем этапе.

Преимущества применения каскадного способа :

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

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

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

В то же время этот подход обладает рядом недостатков, вызванных, прежде всего тем, что реальный процесс создания программного обеспечения никогда полностью не укладывается в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер : результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на предыдущих стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид (рис.2).

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

Понятие модели жизненного цикла программного обеспечения. Модель быстрой разработки приложений. См. п. 5

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

Выделяют следующие этапы процесса RAD-разработки :

Бизнес-моделирование . Моделируются информационные потоки между бизнес-функциями.

Моделирование данных . Информационный поток отображается в набор объектов данных.

Моделирование обработки . Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций.

Генерация приложения . Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

Тестирование и объединение . Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD :

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

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

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

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

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

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

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

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

Рис. . V-модель жизненного цикла

Ниже дано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:

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

анализ требований к продукту и его спецификации – анализ существующей на данный момент проблемы с программного обеспечения, завершается полной спецификацией ожидаемой внешней линии поведения создаваемой программной системы;

архитектура или проектирование на высшем уровне – определяет, каким образом функции ПО должны применяться при реализации проекта;

детализированная разработка проекта – определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;

разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое программного обеспечения;

модульное тестирование – выполняется проверка каждого закодированного модуля на наличие ошибок;

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

системное и приемочное тестирование – выполняется проверка функционирования программной системы в целом (полностью интегрированная система), после помещения в ее аппаратную среду в соответствии со спецификацией требований к ПО;

производство, эксплуатация и сопровождение – программное обеспечение запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок;

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

преимуществ:

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

в модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;

в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения - перед разработкой компонентов;

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

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

модель проста в использовании (относительно проекта, для которого она является приемлемом).

недостатки :

с ее помощью непросто справиться с параллельными событиями;

в ней не учтены итерации между фазами;

в модели не предусмотрено внесение требования динамических изменений на разных этапах ЖЦ;

тестирование требований в ЖЦ происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта;

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

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

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

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

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

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

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

Как показано на рис. 3, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

Планирование - определение целей, вариантов и ограничений.

Анализ риска - анализ вариантов и распознавание/выбор риска.

Конструирование - разработка продукта следующего уровня.

Оценивание - оценка заказчиком текущих результатов конструирования.

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