Зачем нужны гост 19 и гост 34

Стандартизация документации разработки

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

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

Пример 1. Если в утвержденном техническом задании (ТЗ) на автоматизированную систему сказано, что посетитель сайта должен видеть лозунг «Слава труду», заказчик не имеет права вдруг потребовать еще и демонстрации рекламного ролика на эту тему. Вполне возможно, что показывать ролик — неплохая идея, но заказчику следовало высказать ее раньше, когда разработчик согласовывал с ним техническое задание. С другой стороны, если вместо положенного текста система будет выдавать рекламу ночного клуба, у заказчика появятся все основания потребовать от разработчика внесения в систему необходимых изменений, и не платить ему денег, пока система не будет приведена в соответствие техническому заданию.

Пример 2. Если в утвержденном техническом проекте зафиксировано, что для реализации автоматизированной системы используется скрипт на PHP , разработчик не имеет права огорошить заказчика предложением вместо бесплатного интерпретатора этого языка приобрести Lotos Domino. Но, с другой стороны, и заказчик не может потребовать от разработчика вместо нормального сервера использовать компьютер БК 0010, завалявшийся в кладовке с советских времен.

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

Всякая бюрократизация подразумевает соблюдение определенных форм. Формы договоров и основных финансовых документов продиктованы законодательством. Аналогично, формы технических документов продиктованы гостами. При этом техническая документация на программы описывается Единой системой программной документации (ГОСТ 19), а техническая документация на автоматизированные системы Комплексом стандартов на автоматизированные системы (ГОСТ 34).

ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

3.1. Каждому разработанному документу должно быть присвоено
самостоятельное обозначение. Документ, выполненный на разных носителях данных,
должен иметь одно обозначение. К обозначению документов, выполненных на
машинных носителях, добавляют букву «М».

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

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

3.3. Обозначение документа имеет следующую структуру:

3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.

3.3.2. Код документа состоит из двух буквенно-цифровых знаков. Код для
документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 табл. 2. Код дополнительных
документов формируют следующим образом: первый знак — буква, означающая вид
документа согласно табл. 1, второй знак — цифра или буква, указывающая порядковый номер документа
данного вида.

Код документа отделяют от
предыдущего обозначения точкой.

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

3.3.4. Номер редакции документа присваивают, начиная со второй в порядке
возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной
номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей
редакции.

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

3.3.6. Признак документа, выполненного на машинных носителях, вводят при
необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

Обязательность соблюдения гостов

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

2.3 Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?

Во-первых, требования ГОСТ 34 серии (в частности ГОСТ 34.201-89, определяющий виды документов, ГОСТ 34.602-89, определяющий содержание технического задания на создание системы) – остаются действующими. Таким образом, после отмены РД 50-34.698-90 не произошло отмены всей системы стандартов ГОСТ 34 серии. Изменилась только ситуация с наличием действующего регламента по содержанию документации. Действительно, РД 50-34.698-90 нуждался в серьезной переработке, поскольку был рассчитан на применение устаревших методов обработки информации. А оставшиеся действующими документы определяют структуру всей системы документации и содержание основных проектных документов, в том числе Технического задания.

Во-вторых, на необходимость учета требований ГОСТ 34 серии при создании систем указывает действующая нормативная база, в частности:

• ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»;
• Приказ ФСТЭК России от 11.02.2013 №17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
• Постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции 07.08.2019) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

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

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

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

Хорошо, если имеется отраслевой стандарт, или внутри организации заказчика системы утвержден корпоративный стандарт, определяющий правила изложения и оформления документации технического проекта. В качестве основы для подготовки такого стандарта хорошо подходят требования РД 50-34.698-90 вместе с ГОСТ 34.201-89 (в качестве мастер-таблицы), если убрать из них ненужные документы и разделы.

Заказчику, приступающему к созданию системы по ГОСТ 34 при отсутствии корпоративного стандарта организации, следует в технических требованиях на проектирование системы, вместо привычной ссылки на РД 50-34.698-90, указывать (цитатами из руководящего документа) конкретные требования к содержанию разрабатываемых документов (например, документ «Пояснительная записка к техническому проекту (П2), содержащая разделы: «Общие положения», «Описание процесса деятельности», «Основные технические решения», «Мероприятия по подготовке объекта автоматизации к вводу системы в действие»). Разработчик, увидев требования (в данном случае процитированные не из ГОСТ 2.120-2013 ЕСКД / ГОСТ 19.404-79 ЕСПД, а именно из ранее действующего РД 50-34.698-90), должен из соображений здравого смысла и своего опыта разработки, подготовить документацию по ГОСТ 34.

ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И ИХ ЧАСТЕЙ

1. Структура обозначения автоматизированной системы или ее части имеет
вид:

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

3. Код классификационной характеристики системы или ее части
(подсистемы, комплекса, компонента) присваивают в соответствии с правилами,
установленными в отрасли на основе 425 подкласса общесоюзного классификатора
продукции и/или общесоюзного классификатора подсистем и комплексов задач
АСУ-184154.

4. Порядковый регистрационный номер системы (части системы) присваивает
служба организации разработчика, ответственная за ведение картотеки и учет
обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду
регистрационной характеристики.

ИНФОРМАЦИОННЫЕ
ДАННЫЕ*

__________

* См. примечание ФГУП
«СТАНДАРТИНФОРМ»

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом
СССР по стандартам Министерством приборостроения, средств автоматизации и
систем управления СССР

2. УТВЕРЖДЕН И ВВЕДЕН В
ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от
24.03.89 № 664

3. Срок проверки — 1999 г.;
периодичность проверки — 10 лет

4. ВЗАМЕН ГОСТ 24.101-80,
ГОСТ 24.102-80, РД 50-617-86

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Обозначение НТД, на который дана ссылка	Номер пункта
	1.3, 1.3.3, 2.3
	1.3.4
	1.3.3, 2.3
	1.3, 1.3.2, 2.4
	Вводная часть, 1.1
	1.2

6. ИЗДАНИЕ с Изменением № 1,
утвержденным в декабре 1990 г. (ИУС 4-91)

Переиздание (по
состоянию на август 2008 г.)

ПРИМЕЧАНИЕ ФГУП «СТАНДАРТИНФОРМ»

На первой
странице дополнить кодом: МКС 35.240 (указатель «Национальные стандарты», 2008).
Информационные данные. Ссылочные нормативно-технические документы: ГОСТ 2.601-95
заменен на ГОСТ
2.601-2006.

1. Виды и наименование документов. 1 2. Комплектность документации. 6 3. Обозначения документов. 6 Приложение 1 Пояснения терминов, применяемых в настоящем стандарте. 7 Приложение 2 Правила обозначения систем и их частей. 7

ПРИЛОЖЕНИЕ 2 (справочное). ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС

ПРИЛОЖЕНИЕ 2Справочное

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

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

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

4. Организация-генпроектировщик объекта автоматизации;

5. Организации-проектировщики различных частей проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС;

6. Организации строительные, монтажные, наладочные и другие.Примечания:

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

2. Стадии и этапы выполняемых ими работ по созданию АС определяются на основании настоящего стандарта.

ПОЯСНЕНИЯ ТЕРМИНОВ, ПРИМЕНЯЕМЫХ В НАСТОЯЩЕМ СТАНДАРТЕ

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

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

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

Перепечатка воспрещена

D Издательство стандартов, 1991 СТАНДАРТИНФОРМ, 2009

Стадия	Этап работ
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. Структура
обозначения автоматизированной системы или ее части имеет вид:

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

3.
Код классификационной характеристики системы или ее части (подсистемы, комплекса,
компонента) присваивают в соответствии с правилами, установленными в отрасли на
основе 425 подкласса общесоюзного классификатора продукции и/или общесоюзного
классификатора подсистем и комплексов задач АСУ
— 1 84 154.

4. Порядковый
регистрационный номер системы (части системы) присваивает служба организации
разработчика, ответственная за ведение картотеки и учет обозначений.
Регистрационные номера присваивают с 001
до 999 по каждому коду регистрационной
характеристики.

ИНФОРМАЦИОННЫЕ
ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН

Государственным комитетом СССР по стандартам
Министерством приборостроения, средств автоматизации и систем управления СССР

ИСПОЛНИТЕЛИ

И. П. Вахлаков; Я. Г.
Виленчик; Н. М. Вицын, канд. техн. наук; Ф. Р. Выдра, канд. техн. наук; С. В. Гаршина;
Б. А. Дюков; Л. М. Зайденберг, канд. техн. наук; А. П. Игошин, канд. техн.
наук; Ю. Б. Ирз, канд. техн. наук (руководитель темы);
В. Ю. Королев; И. А. Коротеева; Е. С. Кранков, канд. техн. наук; В. И.
Махнач, д-р техн. наук; И. С. Митяев; А. М. Мустафина; Е. И. Некрылов, канд.
техн. наук; В. Ф. Попов; Е. Г. Савина; Н. В. Степанчикова; В. К. Чистов, канд. техн. наук; П. А. Шалаев, канд.
техн. наук

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ
Постановлением Государственного комитета СССР по стандартам от 24.03.89 № 664

3. Срок проверки
— 1999 г.; периодичность проверки — 10 лет

4. ВЗАМЕН ГОСТ 24.101-80, ГОСТ
24.102-80, РД 50-817-86

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Обозначение НТД, на который дана ссылка	Номер пункта
ГОСТ 2.102-68	1.3, 1.3.3, 2.3
ГОСТ 2.113-75	1.3.4
ГОСТ 2.601-68	1.3.3, 2.3
ГОСТ 19.101-77	1.3, 1.3.2, 2.4
ГОСТ 24.601-86	Вводная часть, 1.1
ГОСТ 34.602-89	1.2

ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

3.1.
Каждому разработанному документу должно быть присвоено самостоятельное
обозначение. Документ, выполненный на разных носителях данных, должен иметь
одно обозначение. К обозначению документов, выполненных на машинных носителях,
добавляют букву «М».

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

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

3.3. Обозначение
документа имеет следующую структуру:

3.3.1.
Правила обозначения системы (части системы) приведены в приложении 2.

3.3.2. Код документа состоит
из двух буквенно-цифровых знаков. Код для документов, определенных настоящим
стандартом, проставляют в соответствии с графой 3
табл. 2.
Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно
табл. 1,
второй знак — цифра или буква,
указывающая порядковый номер документа данного вида.

Код документа отделяют от
предыдущего обозначения точкой.

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

3.3.4.
Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9,
и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают
в случаях сохранения (не аннулирования) предыдущей редакции.

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

3.3.6.
Признак документа, выполненного на машинных носителях, вводят при
необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

ПРИЛОЖЕНИЕ 2 (рекомендуемое). ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И ИХ ЧАСТЕЙ

ПРИЛОЖЕНИЕ 2Рекомендуемое

1. Структура обозначения автоматизированной системы или ее части имеет вид:

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

3. Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли на основе 425 подкласса общесоюзного классификатора продукции и (или) общесоюзного классификатора подсистем и комплексов задач АСУ — 1 84 154.

4. Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведение картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

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

2.2. На каждый комплект должна быть составлена ведомость документов.

2.3. Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства — по ГОСТ 2.601.

2.4. Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.

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

ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

3.1. Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».Заимствованным документам сохраняют ранее присвоенные обозначения.

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

3.3. Обозначение документа имеет следующую структуру:

3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.

3.3.2. Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 табл.2. Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно табл.1, второй знак — цифра или буква, указывающая порядковый номер документа данного вида.Код документа отделяют от предыдущего обозначения точкой.

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

3.3.4. Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

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

3.3.6. Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

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

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

1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

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

Программы и автоматизированные системы

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

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

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

• выделяет в здании министерства кабинет;
• ставит в этот кабинет компьютер и подключает его к Интернету;
• устанавливает на этот компьютер HTTP-сервер Apache, интерпретатор PHP и ваш скрипт;
• вменяет в обязанность кому-нибудь из сотрудников раз в неделю менять текст лозунга.

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

2.1 В чем суть требований ГОСТ 34 и какова их польза?

ГОСТы 34 серии и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:

1. стадии проекта создания системы;
2. состав проектной документации;
3. проектной документации;
4. оформление проектной документации;
5. последовательность приемки системы.

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

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

СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС

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. Стадии и этапы, выполняемые организациями — участниками работ по
созданию АС, устанавливаются в договорах и техническом задании на основе
настоящего стандарта.

Допускается исключать стадию
«Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии
«Технический проект» и «Рабочая документация» в одну стадию «Технорабочий
проект». В зависимости от специфики создаваемых АС и условийихсоздания допускается выполнять отдельные этапы работ до завершения
предшествующих стадий, параллельное во времени выполнение этапов работ,
включение новых этапов работ.

КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

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

Примечание. Комплектность проектно-сметных документов определяют
в соответствии с правилами, установленными системой проектной документации для
строительства (СПДС).

2.2.
На каждый комплект должна быть составлена ведомость документов.

2.3. Комплектность документации, обеспечивающей
разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной
документации на эти средства — по ГОСТ 2.601.

2.4. Комплектность
документации на программные средства вычислительной техники — по ГОСТ 19.101.

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