МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

федеральное государственное бюджетное образовательное учреждение

высшего образования
«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

В. Е. Шикина

ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ
Учебное пособие

Ульяновск
УлГТУ
2018
УДК 004.01 (075)
ББК 32.81+ 30ц я 7
Ш 57

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

Утверждено редакционно-издательским советом Ульяновского

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

Шикина, Виктория Евгеньевна

Ш 57 Техническая документация информационных систем : учебное пособие /
В.Е. Шикина. – Ульяновск : УлГТУ, 2018. – 92 с.

ISBN 978-5-9795-1852-7

Изложены основные понятия в области нормативно-методического

обеспечения информационных систем. Рассматриваются стандарты и
программные документы по фазам жизненного цикла информационных
систем. Представлены структура и требования к технической
документации, необходимой при разработке информационных
(автоматизированных) систем. Пособие включает вопросы и задания для
самостоятельной и практической работы и рекомендуемую литературу.
Учебное пособие предназначено для бакалавров укрупненной группы
направлений 09.00.00 «Информатика и вычислительная техника», включая
направление 09.03.02 «Информационные системы и технологии».
Приведенные рекомендации и материалы могут быть полезны при
выполнении выпускной квалификационной работы.
Учебное пособие подготовлено на кафедре «Измерительно-
вычислительные комплексы».

УДК 004.01 (075)

ББК 32.81 + 30ц я 7

 Шикина В.Е., 2018

ISBN 978-5-9795-1852-7  Оформление. УлГТУ, 2018

2
 
 

ВВЕДЕНИЕ

В современном мире каждый день появляются десятки и сотни

различных программ, приложений, информационных систем. Они
могут быть разработаны как для государственного или коммерческого
сектора, так и для обычных пользователей. Разработка
информационной системы (ИС) является достаточно сложным и
долгим процессом, в ходе и результате которого появляется большое
количество технической документации, содержащей описание
создаваемого продукта с различных точек зрения. Техническая
документация может включать в себя не только основание для
разработки и руководства по эксплуатации готового программного
продукта, но и другие артефакты, создаваемые на разных этапах
разработки.
При работе с крупными заказчиками практически всегда
необходимо сдать определенный пакет документов – руководств,
инструкций, проектных решений, оформленных по требованиям
нормативных документов.
Данное учебное пособие предназначено для студентов
направления 09.03.02 «Информационные системы и технологии» с
целью обеспечения их информацией о технической документации,
необходимой при разработке информационных систем, а также в
помощь при подготовке пояснительной записки выпускной
квалификационной работы с точки зрения оформления материала и
представления его на нормоконтроль.
Достаточно широкое понимание информационной системы
подразумевает, что ее неотъемлемыми компонентами являются
данные, техническое и программное обеспечение, а также персонал и
организационные мероприятия. Более узкое понимание
информационной системы ограничивает ее состав данными,
программами и аппаратным обеспечением. Информационные
3
 
системы во многих практически значимых случаях являются
системами автоматизации функций управления, то есть АСУ.
Поэтому в дальнейшем термины «информационная» и
«автоматизированная» будут считаться синонимами.
Для того чтобы в дальнейшем не было неоднозначного
толкования понятий, ниже приведены основные термины и их
определения согласно ГОСТ 34.003-90 Информационная технология.
Комплекс стандартов на автоматизированные системы.
Автоматизированные системы. Термины и определения, ГОСТ
34.321-96 Информационные технологии. Система стандартов по
базам данных. Эталонная модель управления данными и ГОСТ Р
51904-2002 Программное обеспечение встроенных систем. Общие
требования к разработке и документированию.

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

Автоматизированная система (АС) – система, состоящая из

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

4
 
 

Взаимодействие автоматизированных систем – обмен данными,

командами и сигналами между функционирующими АС.
Документация на автоматизированную систему – комплект
взаимоувязанных документов, полностью определяющих технические
требования к АС, проектные и организационные решения по
созданию и функционированию АС.
Жизненный цикл автоматизированной системы – совокупность
взаимосвязанных процессов создания и последовательного изменения
состояния АС от формирования исходных требований к ней до
окончания эксплуатации и утилизации комплекса средств
автоматизации АС.
Интегрированная автоматизированная система – совокупность
двух или более взаимоувязанных АС, в которой функционирование
одной из них зависит от результатов функционирования другой
(других) так, что эту совокупность можно рассматривать как единую
АС.
Информационная система – система, которая организует
хранение и манипулирование информацией о предметной области.
Информационная совместимость автоматизированных
систем – частная совместимость АС, характеризуемая возможностью
использования в них одних и тех же данных и обмена данными между
ними.
Информационное обеспечение автоматизированной системы –
совокупность форм документов, классификаторов, нормативной базы
и реализованных решений по объемам, размещению и формам
существования информации, применяемой в АС при ее
функционировании.

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

Программное изделие в автоматизированной системе –

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

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

8
 
 

использования при эксплуатации системы, определяющая правила

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

9
 
 1. ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. Назначение технической документации

Техническая документация является составляющей проекта по

созданию, внедрению, сопровождению, модернизации и ликвидации
информационной системы на всем протяжении жизненного цикла.
Комплекс технических документов, который регламентирует
деятельность разработчиков, называется нормативно-методическим
обеспечением (НМО). В данный комплекс входят [2]:
 стандарты;
 руководящие документы;
 методики и положения;
 инструкции и т. д.
НМО регламентирует порядок разработки, общие требования к
составу и качеству программного обеспечения (ПО), связям между
компонентами, определяет содержание проектной и программной
документации.
Основным назначением технической документации является
обеспечение эффективных процедур разработки и использования
информационной системы как программного продукта, а также
организация обмена между разработчиками и пользователями ИС.
Таким образом, можно выделить следующие функции
технической документации:
 дает описание возможностей системы;
 обеспечивает фиксацию принятых и реализованных
проектных решений;
 определяет условия функционирования ИС;
10
 
 

 предоставляет информацию об эксплуатации и обслуживании

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

11
 
 1.2. Требования к технической документации

Как правило, к технической документации предъявляются

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

Вопросы для самоконтроля:

1. Что такое нормативно-методическое обеспечение?
2. Каково основной назначение технической документации
информационных систем?
3. Каковы функции технической документации?
4. В чьи обязанности входят работы по документированию
информационной системы?

12
 
 

2. СТАНДАРТЫ В ОБЛАСТИ
ИНФОРМАЦИОННЫХ СИСТЕМ

2.1. Классификации стандартов

В настоящее время существует несколько классификаций

стандартов на проектирование и разработку информационных
(автоматизированных) систем. Классический способ классификации
группирует стандарты по двум признакам.
По объекту стандартизации:
 стандарты на продукты и услуги;
 стандарты на процессы и технологии.
По предмету стандартизации:
 функциональные стандарты (стандарты на языки
программирования, протоколы, интерфейсы);
 стандарты на организацию жизненного цикла (ЖЦ)
автоматизированных систем и программного обеспечения.
Альтернативная классификация группирует стандарты по
статусу:
 официальные стандарты;
 стандарты «де-факто».
В свою очередь официальные стандарты подразделяются на:
 международные стандарты (ISO, ANSI, IDEF0/1);
 стандарты Российской Федерации (ГОСТ);
 отраслевые стандарты;
 ведомственные стандарты.
Стандартами «де-факто» являются официально никем не
утвержденные, но фактически действующие стандарты (таким долгое

13
 
время был SQL и язык программирования С), а также фирменные
стандарты (Microsoft ODBC, IBM SNA).
Как правило, в каждую из этих групп входят документы,
существенно разные по степени обязательности для организаций,
конкретности и детализации содержащихся требований, открытости и
гибкости, а также адаптируемости к конкретным условиям.
Отдельно выделяют корпоративные стандарты.
Для большинства сложных проектов приходится создавать свои
комплексы нормативных и методических документов,
регламентирующих процессы, этапы, работы и документы
конкретных программных продуктов. Такие стандарты называют
корпоративными и представляют собой соглашение о единых
правилах организации технологии или управления в организации. К
таким стандартам относятся:
 стандарты проектирования;
 стандарты оформления проектной документации;
 стандарты пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
 набор необходимых моделей (диаграмм) на каждой стадии
проектирования и степень их детализации;
 правила именования объектов, оформления диаграмм,
включая требования к форме и размерам объектов и т. д.
 требования к конфигурации рабочих мест разработчиков,
включая настройки операционной системы;
 правила интеграции подсистем проекта, правила
поддержания проекта в одинаковом для всех

14
 
 

разработчиков состоянии, правила проверки проектных

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

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

2.2. Отечественные стандарты

Отечественными стандартами являются стандарты ЕСПД

(Единой Системы Программной Документации) серии ГОСТ 19.ХХХ
и комплекс стандартов на автоматизированные системы серии ГОСТ
34.ХХХ, созданные в 80-90-е годы двадцатого века. Кроме того,
существуют более современные стандарты на программное
обеспечение.
Перечень стандартов ГОСТ 19.ХХХ
Единая Система Программной Документации
 ГОСТ 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 Спецификация. Требования к содержанию и
оформлению

16
 
 

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

содержанию и оформлению
 ГОСТ 19.401-78 Текст программы. Требования к содержанию и
оформлению
 ГОСТ 19.402-78 Описание программы
 ГОСТ 19.403-79 Ведомость держателей подлинников
 ГОСТ 19.404-79 Пояснительная записка. Требования к
содержанию и оформлению
 ГОСТ 19.501-78 Формуляр. Требования к содержанию и
оформлению
 ГОСТ 19.502-78 Описание применения. Требования к содержанию
и оформлению
 ГОСТ 19.503-79 Руководство системного программиста.
Требования к содержанию и оформлению
 ГОСТ 19.504-79 Руководство программиста. Требования к
содержанию и оформлению
 ГОСТ 19.505-79 Руководство оператора. Требования к
содержанию и оформлению
 ГОСТ 19.506-79 Описание языка. Требования к содержанию и
оформлению
 ГОСТ 19.507-79 Ведомость эксплуатационных документов
 ГОСТ 19.508-79 Руководство по техническом обслуживанию.
Требования к содержанию и оформлению
 ГОСТ 19.601-78 Общие правила дублирования, учета и хранения
 ГОСТ 19.602-78 Правила дублирования, учета и хранения
программных документов, выполненных печатным способом

17
 
  ГОСТ 19.603-78 Общие правила внесения изменений
 ГОСТ 19.604-78 Правила внесения изменений в программные
документы, выполненных печатным способом
Стандарты ЕСПД практически не имеют содержательной
составляющей и дают формальные требования к составу, содержанию
и оформлению документов, описывающих программу на разных
стадиях ее жизненного цикла.
Комплекс ГОСТ 34 задумывался как всеобъемлющий комплекс
взаимоувязанных межотраслевых документов и рассчитанный на
взаимодействие заказчика и разработчика. Он должен был разрешить
проблему «вавилонской башни», при которой в различных отраслях и
областях деятельности использовалась плохо согласованная или
несогласованная нормативно-техническая документация. Объектами
стандартизации являются автоматизированные системы различных
видов и все виды их компонентов, а не только программное
обеспечение и базы данных. Комплекс рассчитан на взаимодействие
заказчика и разработчика, при этом в нем предусмотрено, что
заказчик может разрабатывать систему для себя сам.
Перечень стандартов ГОСТ 34.ХХХ
Стандарты информационной технологии
 ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс
стандартов на автоматизированные системы. Автоматизированные
системы. Термины и определения
 ГОСТ 34.201-89 Информационная технология (ИТ). Комплекс
стандартов на автоматизированные системы. Виды, комплектность
и обозначения документов при создании автоматизированных
систем

18
 
 

 ГОСТ 34.320-96 Информационные технологии (ИТ). Система

стандартов по базам данных. Концепции и терминология для
концептуальной схемы и информационной базы
 ГОСТ 34.321-96 Информационные технологии (ИТ). Система
стандартов по базам данных. Эталонная модель управления
данными
 ГОСТ 34.601-90 Информационная технология (ИТ). Комплекс
стандартов на автоматизированные системы. Автоматизированные
системы. Стадии создания
 ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс
стандартов на автоматизированные системы. Техническое задание
на создание автоматизированной системы
 ГОСТ 34.603-92 Информационная технология (ИТ). Виды
испытаний автоматизированных систем
 РД 50-34.698-90 Методические указания. Информационная
технология. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов
Многие авторы считают эти стандарты морально устаревшими,
однако ими продолжают активно пользоваться при оформлении
проектной документации. Если разрабатывается документация на
программу (систему), созданную под конкретную организацию,
следует воспользоваться требованиями ГОСТов 34. Если
разрабатывается документация на программу массового применения,
то следует использовать ГОСТы серии 19.
Если говорить о более поздних отечественных стандартах,
следует выделить ГОСТ Р 51904-2002 Программное обеспечение
встроенных систем. Общие требования к разработке и

19
 
документированию, который был разработан Государственным
научно-исследовательским институтом авиационных систем с
участием Научно-исследовательского института стандартизации и
унификации. Данный стандарт распространяется на процессы
разработки и документирования программного обеспечения
встроенных систем реального времени и все действия, имеющие
отношение к разработке программного обеспечения. Стандарт
подготовлен в развитие ГОСТ Р ИСО/МЭК 12207 Информационная
технология. Системная и программная инженерия. Процессы
жизненного цикла программных средств, о котором пойдет речь в п.
2.3. Отдельно стандарт ГОСТ Р 51904-2002 в части подготовки
документов будет рассмотрен в главе 9 «Программное обеспечение».

2.3. Международные стандарты

Международные стандарты применяются для разработки

документации международного уровня. Как правило, они не
бесплатные, так как разрабатываются не государственными
организациями, но, в отличие от отечественных, разработаны
недавно.
В основе практически всех современных промышленных
технологий создания программных средств лежит международный
стандарт ISO/IEC 12207 Information technology. System and software
engineering. Software life cycle processes (ГОСТ Р ИСО/МЭК 12207-
2010 Информационная технология. Системная и программная
инженерия. Процессы жизненного цикла программных средств).
Первая редакция стандарта ISO/IEC 12207 была опубликована в
августе 1995 г. и явилась первым международным стандартом,
содержавшим представительный набор процессов жизненного цикла
в отношении программного обеспечения, которое рассматривалось
как часть большой системы, а также применительно к программным

20
 
 

продуктам и услугам. Стандарт определяет процессы, виды

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

Кроме того, существуют международные стандарты (на

английском языке), которые направлены на написание документации:

1. IEEE Std 1063-2001 «IEEE Standard for Software User

Documentation» – стандарт для написания руководства
пользователя. В документе обозначены требования к
структуре, содержимому и формату инструкций пользователя.
2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software
Design Descriptions» – стандарт для написания технического
описания программы. Представлены рекомендации к
документам, описывающим архитектуру программного
обеспечения.
3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and
preparation of user documentation for application software» –
стандарт для написания руководства пользователя. В данном
документе есть большое количество примеров. Также в
приложениях есть чек-листы «что не забыть сделать в

21
 
 процессе разработки документации» и «что должно быть».
Документ особенно полезен начинающим специалистам.
4. ISO/IEC 26514:2008 «Requirements for designers and developers
of user documentation» – стандарт для дизайнеров и
разработчиков пользователей документации.
Международных стандартов довольно много, в каждой стране
они свои, так как один и тот же стандарт не всегда может подойти и
европейским, и азиатским компаниям.

Вопросы для самоконтроля:

1. Что такое стандарты «де-факто»?
2. Что такое корпоративные стандарты?
3. Что устанавливает стандарт проектирования?
4. Что определяет международный стандарт ISO/IEC 12207?

22
 
 

3. ПРОГРАММНЫЕ ДОКУМЕНТЫ ПО ФАЗАМ

ЖИЗНЕННОГО ЦИКЛА

3.1. Жизненный цикл информационной системы

Жизненный цикл информационной системы – это непрерывный

процесс, который начинается с момента принятия решения о
необходимости создания ИС и заканчивается в момент ее полного
изъятия из эксплуатации.
В определении количества фаз и их содержания имеются
некоторые отличия, поскольку эти характеристики во многом зависят
от условий осуществления конкретного проекта и опыта основных
участников.
1. Концептуальная фаза включает:
 формирование идеи, постановка целей;
 формирование ключевой команды проекта;
 сбор исходных данных и анализ существующего состояния
(предпроектное обследование объекта автоматизации);
 определение основных требований и ограничений,
требуемых материальных, финансовых и трудовых
ресурсов;
 сравнительную оценку альтернатив;
 представление предложений, их экспертизу и утверждение.
2. Разработка технического предложения включает:
 разработку основного содержания и базовой структуры
проекта;
 разработку и утверждение технического задания;

23
 
  планирование и декомпозицию базовой структурной
модели проекта;
 составление сметы и бюджета проекта;
 разработку календарных планов и укрупненных графиков
работ;
 подписание контракта с заказчиком.
3. Проектирование, в основе которого лежит моделирование
предметной области. Цель моделирования – избежать ошибок,
приводящих к экономическим потерям и затратам на последующее
перепроектирование системы. Оно включает:
 выполнение базовых проектных работ;
 разработку частных технических заданий;
 выполнение концептуального проектирования;
 представление проектной разработки, экспертизу и
утверждение.
4. Разработка включает:
 выполнение работ по разработке программного
обеспечения;
 выполнение подготовки к внедрению системы;
 контроль и регулирование основных показателей проекта;
 тестирование.
5. Ввод системы в эксплуатацию включает:
 комплексные испытания;
 подготовку кадров для эксплуатации создаваемой системы;
 подготовку рабочей документации, сдачу системы
заказчику и ввод ее в эксплуатацию;
24
 
 

 сопровождение, поддержку, сервисное обслуживание.

6. Изъятие из эксплуатации или замена включают:
 оценку результатов проекта и подготовку итоговых
документов;
 разрешение конфликтных ситуаций и закрытие работ по
проекту.
Согласно ГОСТ 34.601-90 Автоматизированные системы. Стадии
создания основными стадиями и этапами создания АС являются:
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости
создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на
разработку АС (тактико-технического задания)
2. Разработка концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских
работ
2.3. Разработка вариантов концепции АС, удовлетворяющей
требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание АС
3.1. Разработка и утверждение технического задания
4. Эскизный проект
4.1. Разработка предварительных проектных решений по
системе и ее частям
25
 
 4.2. Разработка документации на АС и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку
изделий для комплектования АС и/или технических
требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях
проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации в вводу АС в действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемыми изделиями
(программными и техническими средствами, программно-
техническими комплексами, информационными
изделиями)
7.4. Строительно-монтажные работы
7.5. Пуско-наладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний

26
 
 

8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными
обязательствами
8.2. Послегарантийное обслуживание
Следует отметить наиболее частые ошибки, допускаемые на
начальных стадиях разработки:
 ошибки в определении интересов заказчика;
 концентрация на маловажных, сторонних интересах;
 неправильная интерпретация исходной постановки задачи;
 неправильное или недостаточное понимание деталей;
 неполнота функциональных спецификаций (системных
требований);
 ошибка в определении требуемых ресурсов и сроков;
 редкая проверка на согласованность этапов и отсутствие
контроля со стороны заказчика.

3.2. Состав программных документов

по фазам жизненного цикла

Системную документацию по стадиям жизненного цикла можно

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

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

 руководство пользователя, план испытаний.

Программирование, испытание, сертификация
 руководство по эксплуатации;
 руководство по сопровождению.

Вопросы для самоконтроля:

1. Что такое жизненный цикл информационной системы?
2. Для чего нужно моделирование предметной области?
3. К какой стадии жизненного цикла относится составление
технического задания?
4. Какие работы, согласно ГОСТ 34.601-90, включает стадия
сопровождения автоматизированной системы?

29
 
 4. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ
ОБЪЕКТА АВТОМАТИЗАЦИИ

Сбор исходных данных и анализ существующего состояния

объекта автоматизации относится к концептуальной фазе жизненного
цикла и является важным и определяющим этапом проектирования
информационной системы. При правильном подходе предпроектное
обследование позволяет сократить эксплуатационные расходы и
время на исправление ошибок, обнаруживаемых после сдачи
системы.
Предпроектное обследование состоит из трех этапов:
 предварительное обследование (сбор сведений об объекте);
 анализ сведений (описание и моделирование предметной
области);
 оценка эффективности и целесообразности проекта.
Источником для получения сведений могут служить устав и
регламенты организации, государственные законы, постановления и
другие нормативно-правовые акты.
Обследование также должно провести анализ
автоматизированных систем, уже функционирующих в рамках
объекта автоматизации. Кроме того, необходимо определить степень
интеграции создаваемой АС с существующими системами. На базе
полученных данных необходимо выявить основные функциональные
и пользовательские требования к системе.
Результатом является аналитический отчет, который может быть
выполнен согласно требованиям ГОСТ 7.32-2017 «Отчет о научно-
исследовательской работе. Структура и правила оформления» и
должен содержать следующую информацию:

30
 
 

 Объект, цели исследования и методология проведения работ.

 Основные конструктивные, технологические и технико-
эксплуатационные характеристики.
 Основные требования пользователя к АС.
 Степень внедрения и рекомендации по внедрению АС.
 Область применения АС.
 Обоснование экономической эффективности создания АС.
 Прогнозы и предположения о развитии объекта исследования.
Документы, входящие в аналитический отчет, могут быть
представлены в виде текстового описания или таблиц с описанием
операций, исполнителей и документов бизнес-процессов.
Кроме того, аналитиками обычно формируется словарь терминов,
описывающий предметную область, а также процессы, протекающие
в организации.
Описание процессов может быть выполнено с помощью
диаграммы IDEF0 или диаграммы вариантов использования UML.
Диаграммы, размещенные в аналитическом отчете, следует
сопровождать текстовым описанием, где необходимо указать:
 краткое описание процесса;
 действующие лица;
 предусловие;
 постусловие;
 основной сценарий процесса;
 альтернативные сценарии.
Сценарии варианта использования в технической документации
могут быть дополнены диаграммой деятельности, что поможет

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

Вопросы для самоконтроля:

1. Для чего необходимо предпроектное обследование объекта
автоматизации?
2. Какие документы используют для сбора сведений об объекте?
3. Что включает в себя аналитический отчет?
4. В каком виде представляется информация в аналитическом
отчете?

32
 
 

5. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
К ИНФОРМАЦИОННОЙ СИСТЕМЕ

Техническое задание (ТЗ) – исходный документ для

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

33
 
  заказчику
 осознать, что именно ему нужно;
 требовать от исполнителя соответствия продукта всем
условиям, оговоренным в ТЗ;
 исполнителю
 понять суть задачи, показать заказчику технический облик
будущего программного изделия или автоматизированной
системы;
 спланировать выполнение проекта и работать по
намеченному плану;
 отказаться от выполнения работ, не указанных в ТЗ.
Основной нормативной базой для составления технического
задания на разработку автоматизированной (информационной)
системы является ГОСТ 34.602-89 Техническое задание на создание
автоматизированной системы. Согласно этому документу ТЗ на АС
содержит следующие разделы, которые могут быть разделены на
подразделы:
1. Общие сведения
1.1 Полное наименование системы и ее условное обозначение
1.2 Шифр темы или шифр (номер) договора
1.3 Наименование предприятий (объединений) разработчика и
заказчика (пользователя) системы и их реквизиты
1.4 Перечень документов, на основании которых создается
система
1.5 Плановые сроки начала и окончания работы по созданию
системы
1.6 Сведения об источниках и порядке финансирования работ
34
 
 

1.7 Порядок оформления и предъявления заказчику

результатов работ по созданию системы (ее частей), по
изготовлению и наладке отдельных средств (технических,
программных, информационных) и программно-
технических (программно-методических) комплексов
системы
2. Назначение и цели создания (развития) системы
2.1 Назначение системы
2.2 Цели создания системы
3. Характеристики объекта автоматизации
3.1 Краткие сведения об объекте автоматизации
3.2 Сведения об условиях эксплуатации
4. Требования к системе
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию
системы
4.1.2 Требования к численности и квалификации
персонала системы и режиму его работы
4.1.3 Показатели назначения
4.1.4 Требования к надежности
4.1.5 Требования безопасности
4.1.6 Требования к эргономике и технической эстетике
4.1.7 Требования к транспортабельности для подвижных
АС

35
 
 4.1.8 Требования к эксплуатации, техническому
обслуживанию, ремонту и хранению компонентов
системы
4.1.9 Требования к защите информации от
несанкционированного доступа
4.1.10 Требования по сохранности информации при авариях
4.1.11 Требования к защите от влияния внешних
воздействий
4.1.12 Требования к патентной чистоте
4.1.13 Требования по стандартизации и унификации
4.1.14 Дополнительные требования
4.2 Требования к функциям (задачам), выполняемым системой
4.2.1 Перечень функций для каждой подсистемы
4.2.2 Временной регламент реализации каждой функции
4.2.3 Требования к качеству реализации каждой функции
(задачи или комплекса задач), к форме представления
выходной информации
4.2.4 Перечень и критерии отказов для каждой функции
4.3 Требования к видам обеспечения
4.3.1 Математическое обеспечение
4.3.2 Информационное обеспечение
4.3.3 Лингвистическое обеспечение
4.3.4 Программное обеспечение
4.3.5 Техническое обеспечение
4.3.6 Метрологическое обеспечение

36
 
 

4.3.7 Организационное обеспечение

4.3.8 Методическое обеспечение
5. Состав и содержание работ по созданию (развитию) системы
5.1 Перечень стадий и этапов работ по созданию системы
5.2 Сроки выполнения
6. Порядок контроля и приемки системы
6.1 Виды, состав, объем и методы испытаний системы и ее
составных частей
6.2 Общие требования к приемке работ по стадиям
6.3 Статус приемочной комиссии
7. Требования к составу и содержанию работ по подготовке
объекта автоматизации к вводу системы в действие
7.1 Перечень основных мероприятий и их исполнителей
7.2 Изменения в объекте автоматизации
7.3 Создание условий функционирования объекта
автоматизации, при которых гарантируется соответствие
требованиям ТЗ
7.4 Сроки и порядок комплектования штатов и обучения
персонала
8. Требования к документированию
8.1 Согласованный перечень подлежащих разработке
комплектов и видов документов
9. Источники разработки
9.1 Перечень документов информационных материалов

37
 
 В ТЗ на АС могут включаться приложения, содержащие расчет
ожидаемой эффективности системы и оценку ее научно-технического
уровня.
Если разрабатывается только программное изделие, то при
составлении технического задания можно использовать ГОСТ 19.201-
78 Техническое задание, требования к содержанию и оформлению.
Согласно этому документу техническое задание на разработку
программного изделия должно содержать следующие разделы:
1. Введение (указывают наименование, краткую характеристику
области применения программы или программного изделия и
объекта, в котором используют программу или программное
изделие).
2. Основания для разработки. В разделе должны быть указаны:
 документ (документы), на основании которых ведется
разработка;
 организация, утвердившая этот документ, и дата его
утверждения;
 наименование и/или условное обозначение темы
разработки.
3. Назначение разработки. В разделе должно быть указано
функциональное и эксплуатационное назначение программы
или программного изделия.
4. Требования к программе или программному изделию.
Раздел должен содержать следующие подразделы:
 требования к функциональным характеристикам (к составу
выполняемых функций, организации входных и выходных
данных, временным характеристикам и т. п.);

38
 
 

 требования к надежности (к обеспечению устойчивого

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

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

Вопросы для самоконтроля:

1. Что такое техническое задание на создание системы?
2. Что позволяет техническое задание заказчику и исполнителю
как инструмент коммуникации?

40
 
 

6. ЭСКИЗНЫЙ И ТЕХНИЧЕСКИЙ ПРОЕКТЫ

6.1. Эскизный проект

Основная задача эскизного проекта – создать прообраз будущей

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

 Ведомость эскизного проекта (общая информация по

проекту).

 Пояснительная записка к эскизному проекту (вводная

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

 Схема организационной структуры (описание

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

 Структурная схема комплекса технических средств

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

41
 
  Схема функциональной структуры (описание задач, которые
будут использоваться в работе подсистем).

 Схема автоматизации (логический процесс создания

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

6.2. Технический проект

Технический проект – это пакет документации, который

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

 схема функциональной структуры;

 ведомость покупаемых дополнительных изделий;
 перечень данных и сигналов на входе;
 перечень сигналов на выходе;
 задание по разработке дополнительных разделов,
необходимых для разработки системы;
 пояснительная записка с планом подготовительных работ для
ввода системы в использование;
 описание функций автоматизации, поставленной задачи,
информационного обеспечения, организации базы
информации, системы кодировки и классификации,
информационных массивов, программного обеспечения,
проектных процедур;
 план расположения;
 ведомость на материалы и оборудование;
 локальный сметный расчет.
Технический проект на АС должен содержать все эти документы,
если ТЗ не предусмотрено иное. Содержание данных документов
описано в руководящей документации по стандартизации РД 50-
34.698-90 Методические указания. Информационная технология.
Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов.

43
 
 Вопросы для самоконтроля:
1. Какова основная задача эскизного проекта?
2. Какую информацию содержит документ «Схема
организационной структуры»?
3. Что такое «технический проект»?
4. На основании чего составляется технический проект?

44
 
 

7. СПЕЦИФИКАЦИЯ

Спецификация программы – это описание задачи, которую

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

45
 
 Таким образом, можно сказать, что без спецификации достаточно
сложно составить руководство для пользователей, а также велика
вероятность того, что потребуется переделывать части проекта
заново.
К основным свойствам спецификации можно отнести
следующее:
 спецификация не должна содержать деталей реализации, в
отличие от программы она указывает, что надо сделать, а не
как это делать;
 спецификация должна обладать формальностью
(однозначностью прочтения, точностью), причем диапазон
требований очень широк – от полностью формализованного
описания до слегка формализованного;
 спецификация должна быть понятной (ясной, читабельной), в
общем случае она должна быть более понятным описанием
задачи, чем программа, так как краткость не всегда
содействует ясности и понятности;
 спецификация должна обладать полнотой описания задачи,
ничто существенное не должно быть упущено.
В спецификации программы выделяют по меньшей мере две
существенно разные части:
1. Функциональная спецификация. Она описывает функции
программы, решающей задачу (разбиение задачи на подзадачи,
входные и выходные данные, связи между ними, процессы и
действия, реакции на исключительные ситуации и т. д.).
2. Эксплуатационная спецификация. Она касается таких
аспектов, как скорость работы программы или используемые
ею ресурсы, характеристики аппаратуры, на которой она

46
 
 

должна работать, специальные требования к надежности и

безопасности и т. д.
Как правило, спецификация содержит следующие разделы:
1. Введение (обзор содержимого спецификации)
1.1. Цели (детальная информация о целях, которые должны быть
достигнуты при помощи разрабатываемого продукта).
1.2. Масштаб проекта (описание того, что программа должна или
не должна делать).
1.3. Определения, сокращения и аббревиатуры (пояснения для
всех специфических терминов, чтобы все в документе было
понятным).
1.4. Организационное построение спецификации.
2. Общее описание (факторы, определяющие параметры
программного продукта и требования к нему)
2.1. Обзор программного продукта, его взаимосвязь с другими
продуктами или проектами, будет ли он независимым или станет
частью более крупной системы.
2.2. Функции продукта (краткое изложение функционала).
2.3. Характеристика пользователей и то, как она влияет на
требования к программному обеспечению.
2.4. Общие ограничения (содержат информацию о рамках и
стандартах, которые ограничивают опции разработчика при создании
системы).
3. Требования (основной раздел документа)
3.1. Функциональные требования (входные данные, их
трансформация, необходимые операции, результаты на выходе).

47
 
Также здесь может быть приведена аргументация необходимости тех
или иных требований.
3.2. Эксплуатационные требования, которые определяют
критерии для оценки важных параметров работы системы
(производительность, сохранность данных, безопасность).
4. Специальные требования
4.1. Схема информационных потоков (входные и выходные
данные, их источники, пункты назначения и хранения).
4.2. Диаграмма пользовательских сценариев. Ее основное
назначение – продемонстрировать то, как объекты будут
взаимодействовать с программным обеспечением и выделить
основной функционал.
5. Модели
Они помогут сформировать представление о базовой структуре и
пользовательском интерфейсе.
В последнее время появилось большое количество технологий и
методов построения функциональных спецификаций, а также языков
спецификаций. Для этих языков характерно следующее:
 разбиение на уровни абстракций;
 ограниченное число элементов, приходящихся на уровень
абстракции (не более 7);
 ограниченный контекст – включается лишь то, что входит в
процесс, а все остальное из рассмотрения исключается;
 в описание включаются как сами данные, так и действия над
ними.
Таким образом, можно сказать, что спецификациям уделяется все
большее внимание, их разработка рассматривается как

48
 
 

самостоятельная область технологии и методологии

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

Вопросы для самоконтроля:

1. Что такое спецификация программы?
2. В чем различие между функциональной и эксплуатационной
спецификациями?
3. Какие разделы должна содержать спецификация?

49
 
 8. РАБОЧАЯ ДОКУМЕНТАЦИЯ

В состав рабочей, или иначе эксплуатационной, документации

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

8.1. Руководство пользователя

Основной целью руководства пользователя является обеспечение

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

50
 
 

2. Перечень эксплуатационной документации

В данном разделе перечисляется документация, которая позволит
пользователю избежать определенного рода ошибок.
3. Назначение и условия применения
Раздел подразделяет основную задачу программы (системы) на
подзадачи и описывает каждую из них. В нем указывают:
 виды деятельности, функции, для автоматизации которых
предназначено данное средство автоматизации;
 условия, при соблюдении (выполнении, наступлении) которых
обеспечивается применение средства автоматизации в
соответствии с назначением (например, вид ЭВМ и
конфигурация технических средств, операционная среда и
общесистемные программные средства, входная информация,
носители данных, база данных, требования к подготовке
специалистов и т. п.).
4. Подготовка к работе
Данный раздел должен содержать пошаговую инструкцию для
запуска программы (системы). К этапу подготовки системы к работе
можно отнести установку дополнительных приложений,
идентификацию, аутентификацию. В данном разделе указывают:
 состав и содержание дистрибутивного носителя данных;
 порядок загрузки данных и программ.
5. Проверка работоспособности
В разделе описываются показатели, по которым можно
определить, что программное обеспечение работает нестабильно.
6. Описание операций
Это основной раздел, который содержит пошаговую инструкцию
для выполнения того или иного действия пользователем. Если работа

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

8.2. Руководство оператора

Нормативной базой для составления данного документа может

являться ГОСТ 19.505-79 «ЕСПД. Руководство оператора. Требования
к содержанию и оформлению», в котором выделяются следующие
разделы:
 назначение программы (сведения о назначении программы и
информация, достаточная для понимания функций программы
и ее эксплуатации);

52
 
 

 условия выполнения программы (минимальный и/или

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

53
 
 2. Установка локальная
В разделе описывается процесс настройки компьютеров,
использующих программное приложение, также даются
рекомендации по оптимизации настройки рабочих станций, чтобы
улучшить процесс взаимодействия сервера и компьютеров
пользователей.
3. Администрирование пользователей
В разделе подробно описывается процесс администрирования
учетных записей пользователей программного обеспечения.
Подробная инструкция описывает все ситуации, которые могут
возникнуть при управлении пользователями. Например, можно
централизованно завершать все активные соединения с
информационной базой и устанавливать блокировку новых
соединений на определенный период времени. Такая возможность
полезна при выполнении различных административных действий с
информационной базой.
4. Информационная база
В разделе рассматриваются вопросы администрирования,
сохранения, переноса базы данных. Описаны рекомендации по
настройке базы данных. Например, рассматривается ситуация
резервного копирования. Резервное копирование может выполняться
как в автоматическом режиме, так и в ручном. Для автоматического
режима предварительно необходимо выполнить настройки. В любой
момент можно восстановить данные информационной базы из
созданной ранее резервной копии.
5. Технические неполадки
Этот раздел содержит информацию о возможных технических
проблемах, которые могут возникнуть в процессе эксплуатации
программного обеспечения. Рассматриваются проблемы,
возникающие в результате некорректной работы оборудования, а
54
 
 

также ситуации, возникающие в результате некорректного

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

8.3. Руководство администратора

Обычно администратор считается пользователем системы, при

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

55
 
 Системы часто создаются на основе тиражируемых программных
продуктов или аппаратно-программных комплексов. В составе таких
решений нередко поставляется программный компонент под
названием «Администратор», предназначенный для управления
системой после ее развертывания.
Структура руководства администратора существенным образом
зависит от того, как устроена система, и какого обслуживания она
требует.
Типичная структура руководства администратора системы
следующая:
1. Назначение системы
2. Принципы функционирования системы
3. Обязанности и задачи администратора
4. Обслуживание системы
 настройка параметров работы системы;
 ведение нормативно-справочной информации;
 учетные записи пользователей и управление ими;
 назначение пользователям прав доступа;
 загрузка и выгрузка данных.
5. Проблемы в работе системы и способы их решения
Руководство по административному модулю программного или
программно-аппаратного комплекса содержит примерно те же
сведения, но в более общем виде. Например, в нем должно быть
объяснено, как создать учетную запись пользователя, но не может
быть указано, когда это следует делать. Такая конкретика возникает
только при внедрении продукта в некотором конкретном месте и
отражается в технологических инструкциях или регламентах.

56
 
 

Структура руководства по административному модулю

программного или аппаратно-программного комплекса может иметь
следующий вид:
1. Общие сведения о комплексе
2. Функционирование комплекса в рамках системы
(рассматриваются несколько наиболее типичных случаев
применения комплекса и перечисляются основные
обязанности администратора в каждом из них)
3. Интерфейс пользователя административного модуля
4. Задачи по обслуживанию
 настройка параметров работы системы;
 ведение нормативно-справочной информации;
 учетные записи пользователей и управление ими;
 назначение пользователям прав доступа;
 загрузка и выгрузка данных.
5. Типичные проблемы в работе и способы их решения
Руководство администратора не следует путать с руководством
системного администратора. Первый документ говорит о том, как
организовать и поддерживать целевое применение системы, второй –
как обеспечить ее техническую работоспособность.

8.4. Руководство системного администратора

Руководство системного администратора – вспомогательный

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

58
 
 

 порядок решения всевозможных вспомогательных задач;

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

1. Общие сведения о программе (комплексе)

2. Архитектура и принципы функционирования
3. Системные требования
4. Установка программы (комплекса)
5. Административная консоль и работа с ней

59
 
 6. Файл конфигурации. Составление и правка
7. Обязательная начальная настройка программы
(комплекса)
8. Проверка правильности функционирования программы
(комплекса)
9. Мероприятия по текущему обслуживанию программы
(комплекса)
10. Оптимизация работы программы (комплекса)
11. Аварийные ситуации и способы их устранения
Объем и особенности изложения информации в руководстве
системного администратора зависят от используемых технических
средств (ПК, серверных комплексов, планшетов, периферийных
устройств и т. д.), применяемого программного обеспечения и
решаемых с его помощью конкретных задач.

8.5. Руководство программиста

Программист – это специалист, который занимается разработкой

алгоритмов и компьютерных программ на основе специальных
математических моделей. Прикладные программисты занимаются в
основном разработкой программного обеспечения прикладного
характера, а также в их обязанности входит адаптация уже
существующих программ под нужды отдельно взятой организации
или пользователя.
Нормативной базой для составления данного документа может
являться ГОСТ 19.504-79 «ЕСПД. Руководство программиста.
Требования к содержанию и оформлению», в котором выделяются
следующие разделы:

60
 
 

 назначение и условия применения программы (назначение и

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

8.6. Руководство системного программиста

Системный программист – это разработчик операционных

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

61
 
оперативную память, выполнение прикладных программ и пр.) в
модули, а модули – в компьютерную сеть.
Нормативной базой для составления данного документа может
являться ГОСТ 19.503-79 «ЕСПД. Руководство системного
программиста. Требования к содержанию и оформлению», в котором
выделяются следующие разделы:
 общие сведения о программе (назначение и функции
программы и сведения о технических и программных
средствах, обеспечивающих выполнение данной программы);
 структура программы (сведения о структуре программы, ее
составных частях, о связях между составными частями и о
связях с другими программами);
 настройка программы (описание действий по настройке
программы на состав технических средств, выбор функций и
др.);
 проверка программы (описание способов проверки,
позволяющих дать общее заключение о работоспособности
программы: контрольные примеры, методы прогона,
результаты);
 дополнительные возможности (описание дополнительных
разделов функциональных возможностей программы и
способов их выбора);
 сообщения системному программисту (тексты сообщений,
выдаваемых в ходе выполнения настройки, проверки
программы, а также в ходе выполнения программы, описание
их содержания и действий, которые необходимо предпринять
по этим сообщениям).

62
 
 

В зависимости от особенностей документа допускается

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

Вопросы для самоконтроля:

1. Для чего необходимо руководство пользователя?
2. Чем руководство оператора отличается от руководства
пользователя?
3. Что включает в себя руководство программиста?

63
 
 9. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

В данном разделе более подробно рассмотрен

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

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

Жизненный цикл (ЖЦ) ПО состоит из:

 Процесса планирования.
 Процесса разработки, который включает:
 процесс определения требований к ПО;
 процесс проектирования ПО;
 процесс кодирования ПО;
 процесс интеграции.
 Интегральных процессов, к которым относятся:
 процесс верификации ПО;
 процесс управления конфигурацией ПО;
 процесс обеспечения качества ПО;
 процесс сертификационного сопровождения.
Документы создают в течение всего ЖЦ ПО, чтобы планировать
требуемые действия, управлять ими, объяснять, определять,
регистрировать выполнение требуемых действий или обеспечивать
доказательство процессов.

64
 
 

Характеристиками документов ЖЦ ПО являются:

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

65
 
 Согласно ГОСТ Р 51904-2002 в рамках каждого процесса ЖЦ
необходимо разработать и оформить соответствующий план.

9.2. План разработки ПО

План разработки ПО содержит описание целей, стандартов и

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

66
 
 

9.3. План верификации ПО

План верификации ПО включает в себя описание процедур

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

67
 
 описание методов верификации, удовлетворяющих этим
требованиям.
 Многоверсионное ПО: при использовании
многоверсионного ПО необходимо описание работ
процесса верификации для него.

9.4. План квалификационного тестирования ПО

План квалификационного тестирования ПО содержит

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

68
 
 

9.5. План управления конфигурацией ПО

План управления конфигурацией ПО устанавливает методы,

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

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

комплексирования, верификации и загрузки ПО. Кроме

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

9.6. План обеспечения качества ПО

План обеспечения качества ПО устанавливает методы, которые

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

71
 
  Состав работ: работы обеспечения качества, которые
должны быть выполнены для каждого процесса жизненного
цикла ПО и на протяжении всего жизненного цикла ПО.
 Критерии перехода: критерии перехода для начала процесса
обеспечения качества.
 Синхронизация: синхронизация работ процесса
обеспечения качества относительно работ других процессов
жизненного цикла ПО.
 Отчеты обеспечения качества: определение отчетов,
которые будут произведены процессом обеспечения
качества.

9.7. План сертификации в части ПО

План сертификации в части ПО, в первую очередь, предназначен

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

72
 
 

 Вопросы сертификации: описание сертификационного

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

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

9.8. План установки ПО

План установки ПО содержит описание работ для установки ПО

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

74
 
 

 Организация процесса обучения персонала: классные

комнаты, расписание теоретических и практических
занятий и т. д.

9.9. План передачи ПО

План передачи ПО определяет аппаратное и программное

обеспечение, а также другие ресурсы, необходимые для поддержки
жизненного цикла передаваемого ПО, и описывает планы
разработчиков для поставки передаваемых элементов через
организации, осуществляющие поддержку. Данный план
разрабатывают в том случае, если используют концепцию передачи
ПО отдельной организации, осуществляющей поддержку.
План должен содержать:
 Краткий обзор системы и документов, относящихся к
передаваемому ПО, общий обзор разработки системы и
сопровождения.
 Детальное описание ресурсов, необходимых для поддержки
передаваемого ПО.
 Перечень рекомендуемых мероприятий, в том числе
консультации и лекции, которые должен проводить
разработчик в целях поддержки передаваемого ПО и
соответствующей среды поддержки.
В плане должны быть указаны предполагаемые области
изменений передаваемого ПО.
Кроме рассмотренных планов, документация, согласно ГОСТ Р
51904-2002, должна включать ряд описаний.

75
 
 9.10. Описание проекта ПО

Документ «Описание проекта ПО» содержит описание

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

76
 
 

9.11. Описание проекта интерфейса

Описание проекта интерфейса содержит описание характеристик

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

9.12. Описание проекта базы данных

Описание проекта базы данных включает в себя описание базы

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

77
 
 9.13. Итоговый документ разработки ПО

Итоговый документ разработки ПО – основной документ по

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

78
 
 

 Документы жизненного цикла ПО. В этом разделе даны

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

79
 
 Вопросы для самоконтроля:
1. Из каких процессов состоит жизненный цикл программного
обеспечения?
2. Что содержит план обеспечения качества ПО?
3. Что включает в себя итоговый документ разработки ПО?
4. Что определяет план передачи ПО?
5. Для чего необходим план установки ПО?

80
 
 

10. НОРМОКОНТРОЛЬ

10.1. Процедура нормоконтроля

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

квалификационной работы, необходимо пройти процедуру
нормоконтроля технической документации, которая детально описана
в [3].
Выпускная квалификационная работа, подписанная студентом,
руководителем и консультантом по экономической части, должна
предъявляться на нормоконтроль комплектно:
 пояснительная записка;
 чертежи (схемы).
Листы пояснительной записки, начиная с содержания, имеют
рамку со штампом. Первый лист содержания помещается на
заглавном листе со штампом основной надписи, представленном на
рисунке 1.

Рисунок 1 – Основная надпись заглавного листа пояснительной записки

Остальные листы пояснительной записки имеют штамп,

показанный на рисунке 2.

81
 
 Рисунок 2 – Основная надпись листа пояснительной записки

Нормоконтролер проверяет работу по следующим показателям:

 соответствие темы ВКР теме, утвержденной согласно
приказу;
 комплектность документации в соответствии с
требованиями, установленными на ВКР;
 наличие необходимых подписей студента, руководителя и
консультанта;
 соответствие нумерации страниц разделов (подразделов,
пунктов, подпунктов) пояснительной записки, указанному в
содержании;
 соблюдение требований стандартов на текстовые
документы:
1 оформление текста:
 шрифт;
 межстрочный интервал;
 абзацный отступ;
 маркированные списки.
2 оформление заголовков разделов (подразделов), пунктов
(подпунктов):
 нумерация;
 отступы заголовков от основного текста;

82
 
 

 выравнивание.
3 оформление рисунков:
 нумерация;
 подрисуночная надпись;
 наличие ссылок на рисунки в тексте.
4 оформление таблиц:
 нумерация;
 заголовок;
 оформление шапки;
 наличие ссылок на таблицы в тексте.
5 оформление списка использованных источников;
6 оформление приложений;
 выполнение чертежей (схем) в соответствии с требованиями
стандартов:
 формат (размеры, обводка рамок);
 основная надпись (форма и размеры);
 шрифт;
 тип и толщина линий;
 соответствие условных графических обозначений
элементов, входящих в чертеж (диаграмму, схему),
требованиям стандартов;
 соответствие наименований, обозначений и количества
элементов, указанных на чертеже (диаграмме, схеме),
данным, приведенным в перечнях, а также в тексте
пояснительной записки.

83
 
 Следует отметить, что нормоконтролер не проверяет содержание
пояснительной записки, за которое полностью отвечает выпускник.
Требования к содержанию разделов пояснительной записки подробно
описаны в [1].

10.2. Оформление чертежей

Вместе с пояснительной запиской выпускной квалификационной

работы на нормоконтроль необходимо предоставить чертежи формата
А1, которые могут быть в горизонтальной и вертикальной
ориентации. Лист формата А1 имеет размеры 594×841 мм.
На рисунке 3 представлен вариант чертежа в вертикальной
ориентации. Все размеры даны в миллиметрах (мм). При любой
ориентации отступ от левого края листа равен 20 мм, отступы от
верхнего, нижнего и правого краев листа – по 5 мм. В графе 26
указывается обозначение выпускной квалификационной работы,
повернутое на 90° при расположении основной надписи вдоль
короткой стороны листа, и на 180°, если основная надпись
расположена вдоль длинной стороны листа.
На рисунке 4 детально представлена основная надпись чертежа
со всеми размерами (в мм), в скобках указаны номера граф для
заполнения.

84
 
 

Рисунок 3 – Форма листа чертежа формата A1

85
 
 Рисунок 4 – Основная надпись чертежа (по ГОСТ 2.104–2006)

В графах основной надписи указываются значения

соответствующих реквизитов:
в графе 1 – наименование документа. Для пояснительной записки
указывается «Пояснительная записка», для чертежа – название
чертежа;
в графе 2 – обозначение ВКР;
в графе 4 – литера, присвоенная документу (графу заполняют
последовательно, начиная с крайней левой клетки). Для работ без
внедрения указывается литера «У» (учебная работа), для работ с
внедрением – «УР» (учебная реальная работа);
в графе 7 – порядковый номер листа (на документах, состоящих
только из одного листа, графу не заполняют);
в графе 8 – общее количество листов документа. Для
графической части проекта учитывается только количество чертежей;
в графе 9 – учебная группа выпускника;
в графе 11 – фамилии лиц, подписывающих документ. В строке
«Разраб.» указывается фамилия выпускника, «Пров.» – руководителя
ВКР, «Н. контр.» – фамилия нормоконтролера. Остальные строки не
заполняются;

86
 
 

в графе 12 – подписи лиц, фамилии которых указаны в графе 11;

в графе 13 – даты подписания документа (с указанием года двумя
последними цифрами).
Оставшиеся графы не заполняются.
Оформлять чертежи к выпускной квалификационной работе
следует по ГОСТ 19.701-90 (ИСО 5807-85) Единая система
программной документации (ЕСПД). Схемы алгоритмов, программ,
данных и систем. Обозначения условные и правила выполнения.
Данный стандарт распространяется на условные обозначения
(символы) в схемах алгоритмов, программ, данных и систем и
устанавливает правила выполнения схем, используемых для
отображения различных видов задач обработки данных и средств их
решения.

10.3. Как правильно складывать чертежи

Согласно ГОСТ 2.501-2013 «Единая система конструкторской

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

87
 
Таблица 1 – Схема складывания чертежей
Складывание
Формат Схема складывания
продольное поперечное
 

А1  

(594×841)

После защиты выпускной квалификационной работы чертежи

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

88
 
 

11. ЗАДАНИЯ ДЛЯ ПРАКТИЧЕСКОЙ РАБОТЫ

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

пользоваться электронным ресурсом Техэксперт. Электронный фонд
правовой и нормативно-технической документации http://docs.cntd.ru/.

Задание №1
Составить техническое задание на разработку информационной
системы согласно требованиям ГОСТ 34.602-89 Техническое задание
на создание автоматизированной системы. За основу следует взять
курсовую работу по дисциплине «Методы и средства проектирования
информационных систем и технологий» или тему выпускной
квалификационной работы.

Задание №2
Составить руководство пользователя, используя структуру,
представленную в п.8.1.

Требования к оформлению практической работы

Техническое задание необходимо оформить согласно

требованиям к оформлению пояснительной записки к ВКР. Данный
документ должен иметь содержание. Листы ТЗ должны иметь рамку
со штампом.
Руководство пользователя оформляется без рамки со штампом.
Номера страниц проставляются внизу страницы посередине.
Шрифт Times New Roman, кегль 14, интервал 1,5.

89
 
 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Выполнение выпускной квалификационной работы

бакалавра : учебно-методическое пособие для студентов
направления 09.03.02 «Информационные системы и
технологии» / В.В. Родионов. – Ульяновск : УлГТУ, 2017. –
74 с.
2. Инюшкина, О.Г. Проектирование информационных систем
(на примере методов структурного системного анализа) :
учебное пособие / О.Г. Инюшкина. – Екатеринбург : Форт-
Диалог Исеть, 2014.
3. Нормоконтроль выпускных квалификационных работ и
дипломных проектов / сост. З.В. Степчева. – Ульяновск :
УлГТУ, 2015.
4. ГОСТ 19.201-78 Техническое задание, требования к
содержанию и оформлению. – М., 1978.
5. ГОСТ 19.503-79 Руководство системного программиста.
Требования к содержанию и оформлению. – М., 1979.
6. ГОСТ 19.504-79 Руководство программиста. Требования к
содержанию и оформлению. – М., 1979.
7. ГОСТ 19.505-79 Руководство оператора. Требования к
содержанию и оформлению. – М., 1979.
8. ГОСТ 34.601-90 Автоматизированные системы. Стадии
создания. – М., 1990.
9. ГОСТ 34.602-89 Техническое задание на создание
автоматизированной системы. – М., 1989.
10. ГОСТ Р 51904-2002 Программное обеспечение встроенных
систем. Общие требования к разработке и
документированию. – М., 2002.

90
 
 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ .................................................................................................. 3
1. ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ ..................................................... 10
1.1. Назначение технической документации ................................... 10
1.2. Требования к технической документации ................................ 12
2. СТАНДАРТЫ В ОБЛАСТИ
ИНФОРМАЦИОННЫХ СИСТЕМ ..................................................... 13
2.1. Классификации стандартов ........................................................ 13
2.2. Отечественные стандарты........................................................... 16
2.3. Международные стандарты ........................................................ 20
3. ПРОГРАММНЫЕ ДОКУМЕНТЫ
ПО ФАЗАМ ЖИЗНЕННОГО ЦИКЛА ............................................... 23
3.1. Жизненный цикл информационной системы .......................... 23
3.2. Состав программных документов
по фазам жизненного цикла....................................................... 27
4. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ
ОБЪЕКТА АВТОМАТИЗАЦИИ ......................................................... 30
5. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
К ИНФОРМАЦИОННОЙ СИСТЕМЕ ............................................... 33
6. ЭСКИЗНЫЙ И ТЕХНИЧЕСКИЙ ПРОЕКТЫ ................................. 41
6.1. Эскизный проект .......................................................................... 41
6.2. Технический проект..................................................................... 42
7. СПЕЦИФИКАЦИЯ ................................................................................ 45
8. РАБОЧАЯ ДОКУМЕНТАЦИЯ ............................................................ 50
8.1. Руководство пользователя .......................................................... 50
8.2. Руководство оператора ................................................................ 52
8.3. Руководство администратора ..................................................... 55
8.4. Руководство системного администратора................................. 57
8.5. Руководство программиста ......................................................... 60
8.6. Руководство системного программиста .................................... 61
9. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ................................................... 64
9.1. Процессы жизненного цикла ПО ............................................... 64
9.2. План разработки ПО .................................................................... 66
9.3. План верификации ПО ................................................................ 67
9.4. План квалификационного тестирования ПО ............................ 68
9.5. План управления конфигурацией ПО........................................ 69
9.6. План обеспечения качества ПО.................................................. 71
9.7. План сертификации в части ПО ................................................. 72
9.8. План установки ПО ..................................................................... 74
9.9. План передачи ПО ....................................................................... 75

91
 
 9.10. Описание проекта ПО ................................................................ 76
9.11. Описание проекта интерфейса .................................................. 77
9.12. Описание проекта базы данных ................................................ 77
9.13. Итоговый документ разработки ПО ......................................... 78
10. НОРМОКОНТРОЛЬ ............................................................................. 81
10.1. Процедура нормоконтроля ........................................................ 81
10.2. Оформление чертежей ............................................................... 84
10.3.Как правильно складывать чертежи .......................................... 87
11. ЗАДАНИЯ ДЛЯ ПРАКТИЧЕСКОЙ РАБОТЫ ............................... 89
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ .............................. 90

Учебное издание

ШИКИНА Виктория Евгеньевна

ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

Редактор Н. А. Евдокимова

ЛР №020640 от 22.10.97.

Подписано в печать 18.10.2018. Формат 60×84/16.

Усл. печ. л. 5,35. Тираж 75 экз. Заказ № 209.

Ульяновский государственный технический университет

432027, г. Ульяновск, ул. Северный Венец, д. 32.
ИПК «Венец» УлГТУ, 432027, г. Ульяновск, ул. Северный Венец, д. 32.

Тел.: (8422) 778-113

E-mail: [email protected]
venec.ulstu.ru

92
 
 Дата подписания к использованию 18.10.2018.
ЭИ № 1239. Объем данных 0,6 Мб. Заказ № 209.

Ульяновский государственный технический университет

432027, Ульяновск, Сев. Венец, 32.
ИПК «Венец» УлГТУ, 432027, Ульяновск, Сев. Венец, 32.

Тел.: (8422) 778-113

E-mail: [email protected]
venec.ulstu.ru