ООО «Техническая документация. Применение гостов при проектировании информационных систем
Введение
В настоящем стандарте термины расположены в систематизированном порядке, отражающем систему понятий в области электронного обмена информацией. Термины сгруппированы в подразделы, объединяющие несколько тематически связанных терминов.
Для каждого понятия установлен один стандартизованный термин.
Стандартизованные термины набраны полужирным шрифтом, их краткие формы, представленные аббревиатурой, - светлым, а синонимы - в скобках курсивом.
Часть многословного термина, которая может быть опущена в его краткой форме, приведена в скобках светлым шрифтом.
В квадратных скобках после определения приведено обозначение стандарта, в соответствии с которым дано определение вводимого термина.
В ряде случаев после термина приводят необходимые уточнения определяемого термина (в квадратных скобках).
В основной части настоящего стандарта термины, заимствованные из других стандартов, заключены в рамки. В квадратных скобках помещены ссылки на эти стандарты с указанием порядкового номера по библиографии.
В приложениях к настоящему стандарту использованы следующие термины:
Юридическая сила документа, правила документирования, документооборот (ГОСТ Р 51141-98);
Взаимосвязь открытых систем, базовая эталонная модель, уровень, уровень представления, прикладной уровень (ГОСТ Р ИСО/МЭК 7498-1-99);
Байт, цифра, цифровые данные, буква, знак, число, информация (ИСО/МЭК 2382-1-93).
6.4 Тип ЭлД
Примечание - Приведенные определения протокола в контексте настоящего стандарта эквивалентны. Второе из них является традиционным, но излишне детализированным в данном контексте.
документ: Информация и соответствующий носитель.
документ: Уникально обозначенный блок информации для использования человеком, такой как отчет, спецификация, руководство или книга.
документ: Структурированная информация, прямо или косвенно предназначенная для восприятия человеком, которая может передаваться, храниться, разыскиваться и обрабатываться с помощью учрежденческих приложений.
Примечание - Это определение используется и в ГОСТ Р ИСО/МЭК 10166 , ГОСТ Р ИСО/МЭК 10740 .
документ (элемент документации): Целевая информация, предназначенная для конкретной аудитории, размещенная на конкретном носителе (например, в книге, на диске, в краткой справочной карте) в заданном формате.
документ: Структурированный объем информации, предназначенный для визуального восприятия, которым можно обмениваться как единым целым между пользователями и/или системами.
документ: Совокупность информации, которая обрабатывается как единое целое. Документы классифицируются в соответствии с конкретными типами документов.
Примечание - В настоящем стандарте этот термин почти всегда означает (без потери точности) документ SGML.
электронный документ: Документ на машиночитаемом носителе, для использования которого необходимы средства вычислительной техники.
документ электронный (ДЭ): Информационный объект, состоящий из двух частей:
Реквизитной, содержащей идентифицирующие атрибуты (имя, время и место создания, данные об авторе и т.д.) и электронную цифровую подпись;
При необходимости ДЭ может приобретать различные формы визуального отображения: на экране или бумаге.
А.2 Концептуальная модель, принятая в ИСО 2382 - , ИСО 14662 , ИСО/МЭК 10746-1
Существование приведенных (но не исчерпывающих) примеров несогласованных друг с другом определений одного и того же понятия связано, прежде всего, с тем, что каждое из приведенных выше определений ограничено областью применения отдельного стандарта и ориентировано на решение одной частной задачи документооборота. Терминология настоящего стандарта согласована с подходами, принятыми в базовых стандартах по терминологии в области ИТ (стандарты серии ИСО 2382), электронному обмену данными (ИСО 14662) и обработке информации в распределенных системах (стандарты серии ИСО/МЭК 10746).
Принятый в этих стандартах современный подход к спецификации ИТ основывается на разделении двух разных аспектов явлений: социального (в данном случае - назначение, информация, документ и т.д.) и технологического (в данном случае - носитель, формат, данные и т.д.). Стандарты устанавливают правила, обеспечивающие согласование вопросов, относящихся к социальным аспектам электронного документооборота (деловая информация, договоры, соглашения и правила, принятые между организациями, в т.ч. вопросы конфиденциальности, достоверности и т.д.) и собственно вопросов ИТ (функциональные возможности, интерфейсы услуг, протоколы и т.д.).
Вводимые в настоящем стандарте понятия отражают социальную природу понятия «документ» и дают возможность связать документ с его реализацией методами ИТ на основе ИСО 14662 и стандартов серии ИСО/МЭК 10746.
Приложение Б
Документ может существовать в виде материального объекта или процесса, выступающего в роли посредника информационного взаимодействия.
Деление документов на аналоговые, дискретные, электронные обусловлено используемыми технологиями. Различие между ними есть различие в среде существования, а значит, в форме их существования и представления. При этом один и тот же документ независимо от формы отражает одни и те же социальные отношения и выполняет одни и те же социальные функции.
Примечание - В некоторых случаях требования к документу ограничивают возможные формы существования документа. Например, денежная купюра может существовать только в бумажной форме (аналоговый документ) и в единственном экземпляре.
Аналоговый документ является объектом аналоговой среды. Например, традиционный текстовый бумажный документ относится к аналоговым документам. Понятие АнД включает в себя все традиционные формы представления документов на аналоговых носителях: бумаге, фото- и кинопленке и т.п. Аналоговая форма представления может быть преобразована в дискретную с помощью оцифровки (термин ).
Понятие «электронный документ» относится к обработке данных с использованием ИТ. Характерной особенностью ИТ является преобразование обрабатываемых данных из одной формы представления (реализации, термин ) в другую и, возможно, одновременное существование нескольких эквивалентных представлений одних и тех же данных. Основным методом обработки данных в ИТ является цифровая обработка. ЭлД в цифровой форме является дискретным документом.
В силу законов электронной среды ЭлД может существовать в этой среде только как множество эквивалентных реализаций, каждая из которых может быть преобразована в другую на основе формальных правил, и все они отображают одну и ту же информацию. Идентификация ЭлД, т.е. множества эквивалентных реализаций, возможна на основе любого подмножества, в том числе по одной реализации.
Любая работа с электронным документом является преобразованием одной реализации в другую, при этом одновременно могут существовать несколько реализаций. Например, при воспроизведении на экране монитора ЭлД, хранящегося в файле на диске, одновременно существуют как минимум две реализации: файл на диске и изображение на экране. Кроме того, в зависимости от архитектуры технического и программного обеспечения могут существовать: файл в оперативной памяти компьютера, файл в памяти видеоустройства, файл в памяти дискового накопителя, потоки данных в каналах, связывающих разные устройства, и т.д. Все эти реализации являются эквивалентными, т.к. представляют один и тот же документ. Свойства этих реализаций, отношения со средой существования и правила преобразования их друг в друга определяются законами электронной среды.
Как в секторе действенности документа есть требования к документу, так и в секторе действенности ЭлД есть требования к реализации ЭлД в электронной и цифровой средах. Специфика требований к (реализации) ЭлД по отношению к общим требованиям к документу в его секторе действенности определяется законами среды его существования.
Последние, в частности, устанавливают, что в электронной среде ЭлД может существовать только в виде множества взаимосвязанных реализаций. Взаимосвязанность реализаций означает, что одна реализация может быть получена из другой в результате формально определенного преобразования. Каждая из этих реализаций может существовать только в части электронной среды. Законы этой среды устанавливают ограничения на выбор допустимого сектора действенности реализации, которая является подсектором действенности ЭлД.
Среди реализаций выделено подмножество воспроизведений в силу их особого значения для человека есть возможность их непосредственного восприятия. В приведенном выше примере только реализация ЭлД на экране монитора доступна для непосредственного восприятия, и она является представителем всего множества реализаций данного ЭлД, в т.ч. файла на диске компьютера.
Сектор действенности ЭлД является объединением секторов действенности его реализаций, в каждом из которых установлены единые (в пределах сектора) правила обработки и преобразования данных.
Сектор действенности ЭлД разделен на подсекторы «по вертикали» и «по горизонтали». Деление по вертикали определено уровнями модели ВОС (ГОСТ Р ИСО/МЭК 7498-1), которые соответствуют, в частности, разной степени подробности описания электронной среды. Деление по горизонтали определяется наличием разных областей обработки данных. В качестве областей обработки данных выступают отдельные устройства обработки, хранения и передачи данных. Реализации существуют в отдельных ячейках, получившихся в результате такого деления. Преобразование одной реализации в другую, расположенную в соседней ячейке, осуществляется на основе формальных правил (алгоритмов) и является обратимым.
Примечание - Несколько устройств могут рассматриваться как одно целое, как объединенные в одну область обработки, внутреннее строение которой несущественно для данного рассмотрения. В частности, любая система обработки данных является такой областью, состоящей из нескольких устройств; на том уровне рассмотрения, на котором детали внутреннего строения системы не представляют интереса, система рассматривается как единое целое.
В социальной среде документ должен иметь указанные выше свойства, которые необходимы для исполнения документом его социальной роли. Наличие этих свойств у документа формулируется в виде требований социальной среды, а выполнение этих требований должно обеспечиваться техническими средствами. Требования к реализации документа являются производными от законов технологической среды и социальных требований к документу.
Фиксированность документа означает, что передаваемое им сообщение фиксирует некоторый факт, событие, отношение, и смысл этого сообщения не зависит от материальной реализации (неформально говоря, «зафиксирован» смысл документа). Для АнД фиксированность означает, например, что содержание (смысл) закона не должно зависеть от типографского исполнения. Для ЭлД фиксированность означает, например, что содержание (смысл) закона не должно зависеть от реализации - в виде файла на диске, изображения на мониторе или потока сигналов в сети.
Таким образом, фиксированность документа не означает фиксированности формы представления, а должна обеспечиваться выбранной(ыми) формой(ами) представления (разделы , - ) и соответствующими процессами обработки (разделы , и ). В электронной среде социальное требование фиксированности существует в виде формального требования сохранения в ходе работы с документом некоторого инварианта (который зависит от типа документа и используемой технологии).
Доступность документа подразумевает, что в нем могут быть отдельные элементы (параметры), значения которых могут быть измерены. Для ЭлД доступность обеспечивается на основе использования установленных форматов (разделы , - ), которые определяют структуру конкретных реализаций.
Значения параметров, входящих в требования целостности, могут быть специфицированы в нормативных документах или могут быть получены заданным способом из значений некоторых параметров представления документа в некоторый предшествующий момент времени. Для ЭлД целостность обеспечивается на основе применения установленных методов обработки реализаций, т.е. на основе технологии, сохраняющей заданные параметры неизменными (разделы , и ).
Примечание - Требования к параметрам реализации ЭлД, соответствие которым обеспечивает наличие свойств доступности и целостности документа, зависит от социальных требований к документу. В простейшем случае может оказаться достаточным получить визуальное воспроизведение ЭлД (доступность) и визуально убедиться в совпадении полученного текста с некоторым образцом (целостность). При более строгих социальных требованиях к документу необходимо обеспечить, например, наличие и доступность атрибутов защиты и их соответствие установленным техническим требованиям.
Легитимность документа означает, что в ходе работы с ним использовались только допустимые операции в допустимой последовательности. Легитимность ЭлД обеспечивается методами защиты.
Возможность демонстрации документа является необходимым, а собственно демонстрация - достаточным условием для выполнения документом его социальной функции. Место, время и другие условия демонстрации могут быть не определены заранее, но должны быть определены на момент самой демонстрации с точностью, обеспечивающей возможность повторной демонстрации при аналогичных условиях. Параметры (характеристики), которые могут быть измерены для данной реализации, и способы их измерения должны быть заранее установлены для этого типа реализации.
Тип документа определяется его функциональным назначением, которое определяет также и технологические требования к материальной реализации документа. В частности, понятия «копия документа», «заверенная копия документа», «дубликат документа» по ГОСТ Р 51141 относятся к функциональному назначению документа в социальной среде (через понятие «юридическая сила»), не содержат указаний на техническую реализацию и должны рассматриваться как определения типов документов. В случае аналогового (бумажного) документа создание документа нового типа («копии») совпадает с технологической процедурой копирования. В случае ЭлД, в силу специфики обработки данных в электронной среде, документ существует в виде множества (термин ) эквивалентных реализаций (термин 5.3.1), а любая работа с документом, в т.ч. просмотр его на экране дисплея, заключается в непрерывном создании этих реализаций (), т.е. в «копировании» документа. При этом технологическая операция копирования не приводит к созданию документа нового типа («копии»), а лишь к созданию новой реализации, эквивалентной любой другой реализации ЭлД.
В цифровой среде информация представляется в виде битовой строки - набора нулей и единиц. Понимание этой информации (ее интерпретация) относится к сфере деятельности человека. В самой цифровой (и электронной) среде «понимание» информации отсутствует. В этой среде могут быть заданы (человеком) только формальные правила обработки данных.
Иначе данные можно определить как реализацию ЭлД в цифровой среде. Данные состоят из упорядоченной последовательности блоков - элементов. Для каждого элемента должен быть задан его тип, позволяющий интерпретировать (понимать) данные. Тип элемента данных не является свойством данных, а предписывается человеком в стандартах, спецификациях и других технических документах. Один и тот же элемент данных может интерпретироваться различными способами, т.е. ему может быть предписано несколько разных типов. Например, последовательность из 16 бит может быть интерпретирована как двоичное, восьмиричное, десятичное, шестнадцатиричное число, код символа (буквы) или машинной команды. Каждой из этих интерпретаций соответствует свой способ воспроизведения данных, свой набор допустимых операций и значений. Тип данных может использоваться для определения аппаратного, программного обеспечения или другого оборудования, необходимого для воспроизведения или работы с этими данными.
Часть интерпретации данных, представляемая в виде формальных правил, может быть введена в компьютер, а также представлена в виде формализованного алгоритма. Это не означает, что компьютер будет «понимать» информацию. Он будет лишь выполнять заданные команды.
Примечание - Правила обработки данных (алгоритм) сами являются информацией, которая в цифровой среде может быть представлена только в виде данных.
Воспроизведение данных в виде битовой строки неудобно для восприятия человеком. Поэтому обычно данные воспроизводятся в другом, удобном для восприятия, виде. Этот вид определяется типом данных, который предписан для конкретного элемента данных: буква, число, текст, изображение, аудиозапись и т.д.
Примечание - Воспроизведение является одним из методов интерпретации данных. Обычно эта часть интерпретации передается компьютеру.
Пример - Может быть задано, что некоторый элемент данных (в форме нулей и единиц) должен интерпретироваться как дата. Интерпретация этого элемента данных компьютером может означать, что в компьютер введена программа, обеспечивающая такое преобразование данных, что они могут быть выведены на экран в виде, понятном человеку. Иначе, в компьютер может быть введена программа, которая проверяет значение элемента данных и при определенных условиях (равенство заданному значению или превышение заданного значения) передает управление другой программе.
Тип составного элемента данных является упорядоченной последовательностью типов его подэлементов.
Текст является привычным для человека представлением информации в аналоговой среде. Интерпретация этого представления основывается на знаниях читателя: чтобы прочитать текст, нужно, как минимум, знать язык, на котором он написан. Для понимания текста нужно иметь знания в той предметной области, к которой он относится.
Текст в привычном для человека понимании мало пригоден для автоматизированной обработки компьютерными программами. Для того чтобы компьютерная программа могла интерпретировать и соответствующим образом обрабатывать текст, он должен содержать специальные, невидимые человеку при «обычном» воспроизведении, знаки, которые называются разметкой (термин ).
Типы данных, определенные в различных стандартах (цифра, буква, знак, число, изображение, аудиоданные, видеоданные, аудиовизуальные данные), являются предписанием для интерпретации одного и того же базового представления данных в цифровой среде - битовой строки. Формат данных конкретизирует метод интерпретации битовой строки, задавая такие детали, как размеры отдельных полей, способы визуализации (в общем случае - воспроизведения) данных и т.п.
Определение атрибута объекта электронной или цифровой среды должно, как правило, содержать имя атрибута, его формат (или, как минимум, тип).
Сервисные атрибуты не обязательно являются элементами данных ЭлД. Например, атрибуты «имя файла», «дата создания файла», «размер файла» и т.п., характеризующие конкретную реализацию ЭлД, не обязательно должны присутствовать в данных документа.
Различие между справочными и сервисными атрибутами имеет принципиальный характер: справочные атрибуты описывают документ как объект социальной среды, сервисные - реализацию документа как материального предмета или процесса в конкретной среде существования. Например, атрибут «дата создания документа» относится к документу, характеризует момент появления документа независимо от формы, в которой документ был первоначально создан и существует в текущий момент, и должен пониматься в таком смысле, независимо от технической реализации. С другой стороны, атрибут «имя файла» носит чисто технический характер, его интерпретация зависит от реализации (например, в разных операционных системах «имя файла» может по-разному обрабатываться) и поэтому является сервисным атрибутом. Как следствие «имя файла», как и любой другой сервисный атрибут, не может быть реквизитом документа, а «дата создания документа» - может.
ГОСТ 34.601-90
Группа П87
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
Комплекс стандартов на автоматизированные системы
АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ
СТАДИИ СОЗДАНИЯ
Information technology. Set of standards for automated systems. Automated systems. Stages of development
МКС 35.080
ОКСТУ 0034
Дата введения 1992-01-01
ИНФОРМАЦИОННЫЕ ДАННЫЕ
1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по управлению качеством продукции и стандартам
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 N 3469
3. ВЗАМЕН ГОСТ 24.601-86 , ГОСТ 24.602-86
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Номер пункта, приложения |
|
ГОСТ 19.101-77 | Приложение 1 |
ГОСТ 34.201-89 | Приложение 1 |
6*. ПЕРЕИЗДАНИЕ. Июль 2009 г.
________________
* Нумерация соответствует оригиналу. - Примечание изготовителя базы данных.
Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее - организациях).
Стандарт устанавливает стадии и этапы создания АС.
В приложении 1 приведено содержание работ на каждом этапе.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.
1.2. Стадии и этапы создания АС выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом.
1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.
1.4. Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяют в соответствующей документации организаций, участвующих в создании конкретных видов АС.
Перечень организаций, участвующих в работах по созданию АС, приведен в приложении 2.
2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС
2.1. Стадии и этапы создания АС в общем случае приведены в таблице.
Этапы работ |
|
1. Формирование требований к АС | 1.1. Обследование объекта и обоснование необходимости создания АС |
1.2. Формирование требований пользователя к АС |
|
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания) |
|
2. Разработка концепции АС | 2.1. Изучение объекта |
2.2. Проведение необходимых научно-исследовательских работ |
|
2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя |
|
2.4. Оформление отчета о выполненной работе |
|
3. Техническое задание | 3.1. Разработка и утверждение технического задания на создание АС |
4. Эскизный проект | 4.1. Разработка предварительных проектных решений по системе и ее частям |
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. Проведение приемочных испытаний |
|
8. Сопровождение АС | 8.1. Выполнение работ в соответствии с гарантийными обязательствами |
8.2. Послегарантийное обслуживание |
2.2. Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.
Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
ПРИЛОЖЕНИЕ 1 (справочное). СОДЕРЖАНИЕ РАБОТ
ПРИЛОЖЕНИЕ 1
Справочное
1. На этапе 1.1 "Обследование объекта и обоснование необходимости создания АС" в общем случае проводят:
- сбор данных об объекте автоматизации и осуществляемых видах деятельности;
- оценку качества функционирования объекта и осуществляемых видов деятельности, выявление проблем, решение которых возможно средствами автоматизации;
- оценку (технико-экономической, социальной и т.п.) целесообразности создания АС.
2. На этапе 1.2 "Формирование требований пользователя к АС" проводят:
- подготовку исходных данных для формирования требований к АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы);
- формулировку и оформление требований пользователя к АС.
3. На этапе 1.3 "Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)" проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего ее документа с аналогичным содержанием.
4. На этапах 2.1 "Изучение объекта" и 2.2 "Проведение необходимых научно-исследовательских работ" организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчеты о НИР.
5. На этапе 2.3 "Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя" в общем случае проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; сопоставление требований пользователя и характеристик предлагаемой системы и выбор оптимального варианта; определение порядка оценки качества и условий приемки системы; оценку эффектов, получаемых от системы.
6. На этапе 2.4 "Оформление отчета о выполненной работе" подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии, описание и обоснование предлагаемого варианта концепции системы.
7. На этапе 3.1 "Разработка и утверждение технического задания на создание АС" проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.
8. На этапе 4.1 "Разработка предварительных проектных решений по системе и ее частям" определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.
9. На этапе 5.1 "Разработка проектных решений по системе и ее частям" обеспечивают разработку общих решений по системе и ее частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решений задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
10. На этапах 4.2 и 5.2 "Разработка документации на АС и ее части" проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201 .
11. На этапе 5.3 "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготавливаемых серийно.
12. На этапе 5.4 "Разработка заданий на проектирование в смежных частях проекта объекта автоматизации" осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.
13. На этапе 6.1 "Разработка рабочей документации на систему и ее части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддерживания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение. Виды документов - по ГОСТ 34.201 .
14. На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101 .
15. На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.
16. На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС.
17. На этапе "Комплектация АС поставляемыми изделиями" обеспечивают получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий. Проводят входной контроль их качества.
18. На этапе 7.4 "Строительно-монтажные работы" проводят: выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи; испытание смонтированных технических средств; сдачу технических средств для проведения пусконаладочных работ.
19. На этапе 7.5 "Пусконаладочные работы" проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы ее ведения; комплексную наладку всех средств системы.
20. На этапе 7.6 "Проведение предварительных испытаний" осуществляют:
- испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний;
- устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний;
- оформление акта о приемке АС в опытную эксплуатацию.
21. На этапе 7.7 "Проведение опытной эксплуатации" проводят: опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.
22. На этапе 7.8 "Проведение приемочных испытаний" проводят:
Испытания на соответствие техническому заданию в соответствии с программой и методикой приемочных испытаний;
- анализ результатов испытаний АС и устранение недостатков, выявленных при испытаниях;
- оформление акта о приемке АС в постоянную эксплуатацию.
23. На этапе 8.1 "Выполнение работ в соответствии с гарантийными обязательствами" осуществляют работы по устранению недостатков, выявленных при эксплуатации АС в течение установленных гарантийных сроков, внесению необходимых изменений в документацию на АС.
24. На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по:
- анализу функционирования системы;
- выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений;
- установлению причин этих отклонений;
- устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС;
- внесению необходимых изменений в документацию на АС.
ПРИЛОЖЕНИЕ 2 (справочное). ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС
ПРИЛОЖЕНИЕ 2
Справочное
1. Организация-заказчик (пользователь), для которой создается АС и которая обеспечивает финансирование, приемку работ и эксплуатацию АС, а также выполнение отдельных работ по созданию АС;
2. Организация-разработчик, которая осуществляет работы по созданию АС, представляя заказчику совокупность научно-технических услуг на разных стадиях и этапах создания, а также разрабатывая и поставляя различные программные и технические средства АС;
3. Организация-поставщик, которая изготавливает и поставляет программные и технические средства по заказу разработчика или заказчика;
4. Организация-генпроектировщик объекта автоматизации;
5. Организации-проектировщики различных частей проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС;
6. Организации строительные, монтажные, наладочные и другие.
Примечания:
1. В зависимости от условий создания АС возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АС.
2. Стадии и этапы выполняемых ими работ по созданию АС определяются на основании настоящего стандарта.
Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2009
Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 34: ГОСТ 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, а также руководящий документ РД 50-34.698-90 и два стоящих особняком стандарта, относящихся к узкоспециальной теме криптозащиты - ГОСТ 34.10 -01 и ГОСТ 34.11-94.
Все эти стандарты появились в конце 80-х - начале 90-х годов (год выпуска обозначен числом после дефиса), заменив или дополнив более ранние стандарты 19-й и 24-й серий.
Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 "Концепции и терминология для концептуальной схемы и информационной базы", ГОСТ 34.321-96. "Эталонная модель управления данными", ГОСТ 34.10 -01 "Криптографическая защита информации . Процессы формирования и проверки электронной цифровой подписи" и ГОСТ 34.11-94 "Криптографическая защита информации . Функция хэширования" я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:
- ГОСТ 34.201-89. "Виды, комплектность и обозначение документов при создании автоматизированных систем";
- ГОСТ 34.003-90 "Термины и определения";
- ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";
- ГОСТ 34.603-92 "Виды испытаний автоматизированных систем";
- ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания";
- Руководящий документ РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".
ГОСТ 34.003-90, помимо того что содержит многочисленные ошибки, полностью устарел и потерял актуальность, поэтому о нем я говорить не буду. Таким образом, далее рассматривается четыре последних документа.
Стандарт ГОСТ 34.201-89
Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС 1АС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно - такие документы, упомянутые в стандарте, как " Техническое задание ", " Эскизный проект ", " Технический проект ", " Инструкция " (пользователя), " Программа и методика испытаний" прочно вошли в практику создания систем. С другой стороны, "Ведомость машинных носителей информации", "Каталог базы данных " или "Ведомость держателей подлинников" вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.
Короче говоря, при "творческом" подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.
Стандарт ГОСТ 34.601-90
Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.
| Стадии | Этапы |
|---|---|
| 1. Формирование требований к АС | 1.1. Обследование объекта и обоснование необходимости создания АС |
| 1.2. Формирование требований пользователя к АС | |
| 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания) | |
| 2. Разработка концепции АС | 2.1. Изучение объекта |
| 2.2. Проведение необходимых научно-исследовательских работ | |
| 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя | |
| 2.4. Оформление отчета о выполненной работе | |
| 3. Техническое задание | 3.1 Разработка и утверждение технического задания на создание АС |
| 4. Эскизный проект | 4.1. Разработка предварительных проектных решений по системе и ее частям |
| 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. Проведение приемочных испытаний | |
| 8. Сопровождение АС | 8.1. Выполнение работ в соответствии с гарантийными обязательствами |
| 8.2. Послегарантийное обслуживание |
Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение.
Помимо вышеприведенной таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ , включая указание на документы, возникающие в результате этих работ , а также Приложение 2 - "Перечень организаций, участвующих в работах по созданию АС ". Это подсказывает способ адаптации стандарта к конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Причем опять-таки эта работа под силу обычному управленцу.
Стандарт ГОСТ 34.602-89
Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).
- Общие сведения.
- Назначение и цели создания (развития) системы.
- Характеристика объектов автоматизации.
- Требования к системе.
- Состав и содержание работ по созданию системы.
- Порядок контроля и приемки системы.
- Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
- Требования к документированию.
- Источники разработки.
Попробуем разобраться в причинах неизменной популярности этого стандарта, возраст которого перевалил уже за 20 лет. Собственно, весь стандарт представляет собой расшифровку перечисленных девяти пунктов. Размер его - всего 11 страниц, но объем сообщаемой полезной информации на удивление велик. Если выбросить явные архаизмы, вроде существовавших когда-то фондов алгоритмов и программ, окажется, что практически все, о чем идет речь, полностью применимо до сих пор. Вот пример одного из разделов.
"2.6.2. В подразделе "Требования к функциям (задачам)", выполняемым системой, приводят:
- по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
- временной регламент реализации каждой функции, задачи (или комплекса задач);
- требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации , характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
- перечень и критерии отказов для каждой функции, по которой задаются требования по надежности".
Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации , т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.
С течением времени стали видны и оборотные стороны стандарта:
- стандарт ориентирован на полностью заказную разработку системы "с нуля" и не рассчитан на внедрение готового решения с помощью типовой методологии или на комбинацию заказных разработок и внедрений;
- стандарт предлагает одну-единственную модель жизненного цикла системы, называемую каскадной, когда все работы по созданию системы линейно упорядочены и этот порядок заранее определен;
- стандарт имеет слишком формальный характер. На практике это приводит к появлению Технических заданий, по форме удовлетворяющих требованиям ГОСТ 34.602-89, но по сути малосодержательных.
Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта.
Другое интересное явление, которое продемонстрировала практика, состоит в том, что, как оказалось, далеко не каждый ИТ-специалист способен разработать Техническое задание , удовлетворяющее требованиям стандарта. Фактически появление ГОСТ 34.602-89 стимулировало возникновение новых специалистов - бизнес-аналитиков и консультантов в сфере информационных технологий, основной работой которых стали разработка и согласование Технических заданий с заказчиками автоматизированных систем.
Стандарты по АСУ, не объединенные в серии.
ГОСТ 15971-90. Системы обработки информации. Термины и определения.
ГОСТ 19781-90. Обеспечение систем обработки информации программное. Термины и определения.
ГОСТ 28806-90. Качество программных средств. Термины и определения. Введен с 1.01.92.
ГОСТ 28195-89. Оценка качества программных средств. Общие положения.
ГОСТ 25868-91. Оборудование периферийное систем обработки информации. Термины и определения. М. Издательство стандартов. 1992, 34 с. Введен с 1.01.93.
ГОСТ 28147-89. Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования.
ГОСТ 28803-90 (ИСО 6523-84). Обмен данными. Структура идентификации организаций. Введен с 01.01.93.
ГОСТ Р ИСО/МЭК 9125-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
ГОСТ Р ИСО/МЭК ТО 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения.
ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.
РИСО 9126-93. Системы обработки информации. документация пользователя и информация на упаковке для потребительских программных пакетов.
ГОСТ РИСО/МЭК 12207. Процессы жизненного цикла программного обеспечения. Введен с 01.07.2000.
ГОСТ Р50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования.
ГОСТ Р51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.
ГОСТ 28140-89. Системы обработки информации. Язык программирования Паскаль.
ГОСТ Р 51169-98. Качество служебной информации. Система сертификации информационных технологий в области качества служебной информации. Термины и определения.
ГОСТ Р 51168-98. Качество служебной информации. Условные обозначения элементов технологических процессов переработки данных.
ГОСТ Р 51170-98. Качество служебной информации. Термины и определения.
ГОСТ Р 51171-98. Качество служебной информации. Правила предъявления информационных технологий на сертификацию.
ГОСТы серии 34. "Информационная технология (ИТ)".
РД 50-680-88. Автоматизированные системы. Основные положения.
РД 50-682-89. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения.
ГОСТ 34.003-90. ИТ. Автоматизированные системы. Термины и определения.
ГОСТ 34.201-89. ИТ. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.
ГОСТ 34.601-90. ИТ. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, 24.602-86).
ГОСТ 34.602-89. ИТ. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
ГОСТ 34.603-89. ИТ. Виды испытаний автоматизированных систем.
РД 50-34.698-90. ИТ. Автоматизированные системы. Требования к содержанию документов.
ГОСТ 34.1501.1-92 (ИСО/TR 10314-1-90). ИТ. Промышленная автоматизация. Основное производство. Часть 1. Эталонная модель стандартизации и методология идентификации требований к стандартизации.
ГОСТы серии 19. "Единая система программной документации (ЕСПД)".
ГОСТ 19.001-77. Единая система программной документации. Общие положения.
ГОСТ 19.701-90. (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. (Взамен ГОСТ 19.002-80, 19.003-80).
ГОСТ 19.005-85. ЕСПД. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения.
ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов.
ГОСТ 19.102-77. ЕСПД. Стадии разработки.
ГОСТ 19.103-77. ЕСПД. Обозначения программ и программных документов.
ГОСТ 19.104-78. ЕСПД. Основные надписи.
ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам.
ГОСТ 19.106-78. ЕСПД. Требования к программным документам, выполненным печатным способом.
ГОСТ 19.201-78. ЕСПД. Техническое задание. Требование к созданию и оформлению.
ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.301-78 ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению.
ГОСТ 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. ЕСПД. Правила дублирования, учета и хранения документов, выполненных печатным способом.
ГОСТ 19.603-78. ЕСПД. Общие правила внесения изменений.
ГОСТ 19.604-78. ЕСПД. Правила внесения изменений в документы, выполненные печатным способом.
ГОСТы серии 24. "Единая система стандартов автоматизированных систем управления (ЕССАСУ)".
ГОСТ 24.104-85. ЕССАСУ. Автоматизированные системы управления. Общие требования.
ГОСТ 24.301-80. Система технической документации на АСУ. Общие требования к выполнению текстовых документов.
ГОСТ 24.302-80. Система технической документации на АСУ. Общие требования к выполнению схем.
ГОСТ 24.701-86. ЕССАСУ. Надежность автоматизированных систем управления. Основные положения.
ГОСТ 24.702-85. Эффективность автоматизированных систем управления. Основные положения.
ГОСТ 24.703-85. Типовые проектные решения в АСУ. Основные положения.
Вместо ГОСТ 24.601-86 и 24.602-86 см. ГОСТ 34.601-90.
Стандарты в области защиты информации.
ГОСТ Р 50922-96. Защита информации. Основные термины и определения.
ГОСТ Р 50934-96. Защита информации. Организация и содержание работ по защите информации об образцах военной техники от технических разведок. Общие положения.
ГОСТ Р 50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования.
ГОСТ Р 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.
ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.
ГОСТ Р 51241-98. Средства и системы управления доступом. Классификация. Общие технические требования. Методы испытаний.
ГОСТ Р 51583-2000. Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие требования.
ИСО/МЭК 15408-99. Критерии безопасности информационных технологий.
Классификация и кодирование информации.
Материалы по стандартизации.
Правила стандартизации. Основные положения и порядок проведения работ по разработке, ведению и применению общероссийских классификаторов. ПР 50.1.024-2005. Федеральное агентство по техническому регулированию и метрологии. Приказ №311-ст от 14.12.2005.
Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора - в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.
Что такое стандарты на документацию?
В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
Минусы стандартов
Основной минус всем очевиден - стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:- приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
- структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
- пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
- Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
- Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
- администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.
«Видеокадр» - это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
Что в стандарте хорошо
Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.
А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель - максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.
Как читать и понимать стандарты документации по ГОСТ серии 34
Стандарт делит все документы по двум осям - время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»
Стадии создания АСУ
Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:- Эскизный проект (ЭП)
- Технический проект (ТП)
- Разработка рабочей документации (РД)
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Части (разделы) проектной документации по созданию АСУ
Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО) , отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса - почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО) . Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО) . Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО) . Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО) . Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры », в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя . Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования . В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция . В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы - все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим . Мы эти бизнес-процессы автоматизируем .
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку) . Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция - для них. Что в нее писать в XXI веке - я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР) . Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала - менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
- Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
- Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
- Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).
Заключение
Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.
Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).
