Классификационные группы стандартов ЕСПД

Теоретическая часть

Общие сведения о ЕСПД

Когда требуется автоматизировать некоторый бизнес-процесс, и для этой цели внедрить и/или разработать некоторые программные изделия (ПИ), перед руководителем встают вопросы:

· что должно быть сделано, кроме программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям, а что службе сопровождения?

· как управлять всем этим процессом?

· что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

На эти и массу других вопросов в той или иной степени отвечают государственные стандарты. Основу отечественной нормативной базы в области документирования ПИ составляет комплекс стандартов ЕСПД (ГОСТ19). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ, действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПИ, и связаны, по большей части, с документированием функциональных характеристик ПИ. Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПИ (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПИ.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

· ориентацию на единственную, "каскадную" модель жизненного цикла (ЖЦ);

· отсутствие четких рекомендаций по документированию характеристик качества ПИ;

· отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, единой системой конструкторской документации (ЕСКД);

· нечетко выраженный подход к документированию ПИ как товарной продукции;

· отсутствие рекомендаций по самодокументированию ПИ, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");

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

Итак, ЕСПД нуждается в пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы ЖЦ. Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПИ. Эта позиция основана на следующем:

· стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПИ;

· предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как некоторым кажется: стандарты позволяют вносить в комплект документации на ПИ дополнительные виды

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

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

Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведенные в таблице 1.1.

Обозначение стандарта ЕСПД строят по классификационному признаку. Обозначение стандарта ЕСПД должно состоять из:

· числа 19 (присвоенных классу стандартов ЕСПД);

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

· двузначного числа (после тире), указывающего год регистрации стандарта.

 

 

Таблица 1.1

Общая постановка задачи

Выберите согласно своему варианту и согласуйте с преподавателем прикладную задачу. Список задач приведен в следующем разделе. Используя дополнительную информацию (книги, Internet и др. источники) изучите прикладную область соответствующую выбранной задаче. Согласно требованиям ЕСПД сформулируйте ТЗ на разработку ПИ для решения данной задачи.

Пример выполнения работы

В данном разделе приведем пример ТЗ на разработку автоматизированной системы платной автостоянки. Приведенный текст основан на реальном ТЗ и приведен практически без сокращений. Однако для сокращения объема опущены приложения. Всего было определено три приложения. В первом рассматривалась методика расчета стоимости ПО. Во втором - перечень документов, предоставляемых при сдачи этапов работ и стоимость каждого этапа. В третьем - виды испытаний системы. Раздел «Основание для разработки» лишен конкретного содержания.

 

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

 

Введение

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

 

Основание для разработки

Здесь должен быть перечень документов, на основании которых ведется разработка. В учебном проекте допустимо написать, что основанием для разработки является задание в рамках курса «Проектирование информационных систем».

 

Назначение разработки

Автоматизированная система предназначена для решения следующих задач:

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

2. Фиксация всех происходящие в системе событий.

3. Формирование и учет пропусков.

4. Контроль доступа на автостоянку.

5. Расстановка автомобилей по машиноместам.

 

Требования к ПИ

Требования к функциональным характеристикам

Система должна обеспечивать следующие функции:

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

· ФИО оператора;

· имя в системе;

· пароль;

· полномочия.

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

· ФИО арендатора;

· уровень доступа;

· срок действия пропуска;

· возможная система скидок на данный товар;

· уровень доступа.

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

· государственный номер;

· марка;

· цвет;

· год выпуска.

4.Ввод, вывод, редактирование, хранение, печать, экспорт в другие форматы информации о машиноместах стоянки и группах машиномест:

· характеристика машиноместа;

· описание и состав группы машиномест.

5.Ввод, вывод, редактирование, хранение, печать, экспорт в другие форматы информации о закрепленных за клиентом машиномест.

6.Формирование, хранение, печать, экспорт в другие форматы журнала событий:

· код события;

· дата события;

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

Входной информацией системы является:

1.Бухгалтерская информация:

· информация о сроке действия договора клиента с автостоянкой

· информация об оплате клиентом машиномест оговоренных в договоре

2.Информация о нажатии кнопки RTE (Request To Exit) или по другому кнопки “ВЫХОД”. Данная кнопка служит для принудительного разрешения пересечения точки прохода, т.е. открытия ворот (шлагбаума) автостоянки.

3.Регистрационная информация:

· информация о машиноместах и группах машиномест автостоянки;

· информация о сотрудниках автостоянки;

· информация о клиентах автостоянки и их транспортных средствах.

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

Выходной информацией системы является:

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

2.Отчеты. Минимальный перечень формируемых в системе отчетов следующий:

· список свободных машиномест;

· список занятых машиномест;

· список событий;

· список клиентов;

· задолжности клиентов.

 

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

Система должна:

· проводить контроль вводимой информации;

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

· обеспечивать целостность данных.

 

Условия эксплуатации

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

 

Требования к составу и параметрам технических средств

Настоящая система должна работать на процессорах совместимых с процессором IBM.

Оперативная память на каждой ЭВМ, не менее 32 Мб.

Сетевые карты.

Необходимо наличие видеокарты не менее 32 Мб на ЭВМ клиента.

Мышь. Клавиатура на ЭВМ клиента.

Свободное место на жестком диске не менее 10Мб. А так же место для хранения баз данных.

 

Требования к информационной и программной совместимости

Система должна работать под управлением ОС семейства Win32.

Для приложения клиента необходимы:

· СУБД Microsoft SQL Server;

· Microsoft SQL Server ServicePack3

 

Требования к маркировке и упаковке

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

 

Требования к транспортированию и хранению

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

 

Требования к программной документации

Программная документация должна содержать следующие документы (см. ГОСТ 19.101-77):

1.Программные документы:

· Спецификация (ГОСТ 19.202-78);

· Текст программы (ГОСТ 19.401-78);

· Описание программы (ГОСТ 19.402-78);

· Пояснительная записка (ГОСТ 19.404-79);

2.Эксплуатационные документы:

· Ведомость эксплуатационных документов (ГОСТ 19.507-79);

· Формуляр (ГОСТ 19.501-78);

· Описание применения (ГОСТ 19.502-78);

· Руководство системного программиста (ГОСТ 19.503-79);

· Руководство программиста (ГОСТ 19.504-79);

· Руководство оператора (ГОСТ 19.505-79);

Требования к перечисленным документам не отличаются от требований, определенных в ЕСПД.

 

Стадии и этапы разработки

Общая продолжительность разработки и внедрения системы составляет 12 месяцев с 10/01/2006 по 10/01/2007. Общая стоимость работ составляет 203190,47 руб. График реализации проекта представлен в таблице 1.3.

По завершении этапа составляется двухсторонний акт приемки-сдачи работ. Перечень документов, предоставляемых при сдачи каждого этапа представлен в приложении 2^[2]. Там же приведена стоимость каждого этапа работ.

 

Таблица 1.3

График реализации проекта

Этапы реализации проекта

Годы / месяцы

1

1 2 3 4 5 6 7 8 9 10 11 12 1. Разработка ПО.                         1.1. Техническое задание.                         1.2. Эскизный проект.                         1.3. Технический проект.                         1.4. Рабочий проект.                         1.5. Внедрение.                         2. Покупка ЭВМ, оборудования     и инструментальных средств для заказчика (осуществляется за средства заказчика).                         3. Обучение персонала (осуществляется за средства заказчика, согласно отдельному договору).                         4. Эксплуатация АРМ (пробная эксплуатация сотрудниками заказчика под контролем разработчика).                        

 

Порядок контроля и приемки

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

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

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

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

 

[1] Для сокращения объема приложение 1 опущено

[2] Для сокращения объема приложение 2 опущено

Теоретическая часть

Общие сведения о ЕСПД

Когда требуется автоматизировать некоторый бизнес-процесс, и для этой цели внедрить и/или разработать некоторые программные изделия (ПИ), перед руководителем встают вопросы:

· что должно быть сделано, кроме программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям, а что службе сопровождения?

· как управлять всем этим процессом?

· что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

На эти и массу других вопросов в той или иной степени отвечают государственные стандарты. Основу отечественной нормативной базы в области документирования ПИ составляет комплекс стандартов ЕСПД (ГОСТ19). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ, действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПИ, и связаны, по большей части, с документированием функциональных характеристик ПИ. Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПИ (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПИ.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

· ориентацию на единственную, "каскадную" модель жизненного цикла (ЖЦ);

· отсутствие четких рекомендаций по документированию характеристик качества ПИ;

· отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, единой системой конструкторской документации (ЕСКД);

· нечетко выраженный подход к документированию ПИ как товарной продукции;

· отсутствие рекомендаций по самодокументированию ПИ, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");

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

Итак, ЕСПД нуждается в пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы ЖЦ. Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПИ. Эта позиция основана на следующем:

· стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПИ;

· предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как некоторым кажется: стандарты позволяют вносить в комплект документации на ПИ дополнительные виды

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

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

Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведенные в таблице 1.1.

Обозначение стандарта ЕСПД строят по классификационному признаку. Обозначение стандарта ЕСПД должно состоять из:

· числа 19 (присвоенных классу стандартов ЕСПД);

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

· двузначного числа (после тире), указывающего год регистрации стандарта.

 

 

Таблица 1.1

Классификационные группы стандартов ЕСПД

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

 

Единая система программной документации включает следующие документы:

· ГОСТ 19.001-77 Общие положения

· ГОСТ 19.002-80 Схемы алгоритмов и программ. Правила выполнения

· ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению

· ГОСТ 19.004-80 Термины и определения

· ГОСТ 19.005-85 Р-схемы алгоритмов и программ

· ГОСТ 19.507-79 Ведомость эксплуатационных документов

· ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению

· ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению

· ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению

· ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению

· ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению

· ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению

· ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению

· ГОСТ 19.403-79 Ведомость держателей подлинников

· ГОСТ 19.402-78 Описание программы

· ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению

· ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению

· ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению

· ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

· ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом

· ГОСТ 19.104-78 Основные надписи

· ГОСТ 19.105-78 Общие требования к программным документам

· ГОСТ 19.103-77 Обозначения программ и программных документов

· ГОСТ 19.102-77 Стадии разработки

· ГОСТ 19.101-77 Виды программ и программных документов

· ГОСТ 19.003-80 Схемы алгоритмов и программ. Обозначения условные графические

· ГОСТ 19.601-78 Общие правила дублирования, учета и хранения

· ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом

· ГОСТ 19.603-78 Общие правила внесения изменений

· ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом

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

 

Процесс определения требований и целей разработки ПИ

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

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

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

1. Выявить наличие информации, необходимой для выполнения планируемых функций.

2. Определить трудоемкость и стоимость предстоящей работы.

3. Определить полноту и точность определения функций, и их взаимосвязь.

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

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

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

При описании целей возможно возникновение следующих ошибок:

· противоречивость в описании сформулированных целей;

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

· цели создания ПИ с точки зрения пользователя и цели проекта с точки зрения проектировщика противоречивы.

В общем случае цели разработки ПИ могут быть сгруппированы в 10 достаточно самостоятельных категорий:

1. Универсальность.

2. Человеческие факторы.

3. Адаптируемость.

4. Сопровождаемость.

5. Безопасность.

6. Документация.

7. Стоимость.

8. Календарный план.

9. Производительность.

10. Надежность.

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

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

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

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

 

Документирование требований. Техническое задание

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

Согласно Единой системе программной документации таким документом является ТЗ на разработку ПИ. Оно устанавливает основное назначение, технические характеристики, показатели качества и технико-экономические требования к ПИ. ТЗ является одним из основополагающих документов проекта ПИ.

Согласно ГОСТ 19.201-78 ТЗ должно содержать следующие разделы.

Техническое задание должно содержать следующие разделы:

1. Введение.

2. Основания для разработки.

3. Назначение разработки.

4. Требования к программе или ПИ.

5. Требования к программной документации.

6. Технико-экономические показатели.

7. Стадии и этапы разработки.

8. Порядок контроля и приемки.

Так же в ТЗ допускается включать приложения. Рассмотрим кратко содержание каждого из разделов.

1. В разделе "Введение" указывают наименование, краткую характеристику области применения ПИ и объекта, в котором оно используется.

2. В разделе "Основание для разработки" должны быть указаны:

· документ (документы), на основании которых ведется разработка;

· организация, утвердившая этот документ, и дата его утверждения;

· наименование и (или) условное обозначение темы разработки.

3. В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение ПИ.

4. Раздел "Требования к программе или ПИ" должен содержать следующие подразделы:

· требования к функциональным характеристикам;

· требования к надежности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

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

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

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

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

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

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

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

5. В разделе ТЗ, названном "Требования к программной документации", должен быть указан состав программной документации и, при необходимости, специальные требования к ней.

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

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

8. В разделе "Порядок контроля и приемки" должны быть указаны виды испытаний и общие требования к приемке работы.

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

Общая постановка задачи

Выберите согласно своему варианту и согласуйте с преподавателем прикладную задачу. Список задач приведен в следующем разделе. Используя дополнительную информацию (книги, Internet и др. источники) изучите прикладную область соответствующую выбранной задаче. Согласно требованиям ЕСПД сформулируйте ТЗ на разработку ПИ для решения данной задачи.