ООО «Техническая документация. Применение гостов при проектировании информационных систем

М. Острогорский , 2008

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

Автоматизированная система, ее функции и задачи

Определение автоматизированной системы

ГОСТ 34.003-90 содержит следующее определение автоматизированной системы: система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Что это определение означает на деле? Разобраться в этом можно, только вчитываясь в другие определения этого стандарта и сопоставляя их друг с другом. Чем мы сейчас и займемся.

Цели деятельности

Автоматизированная система может существовать только там, где имеется персонал, занятый определенной деятельностью. Как правило, речь идет о деятельности, результаты которой полезны кому-то вне зависимости от применяемых инструментов. Например, в театральную кассу я обращаюсь за билетом, и меня вполне устроит, если кассирша выпишет мне его ручкой на бланке, лишь бы меня по нему пустили в зал. Кассирше, по большому счету, тоже все равно, как именно изготовить билет. Ее устроит любой способ, если он будет не слишком трудоемок и обеспечит ей возможность продать мне билет. Иначе говоря, у нас с ней есть общая цель. В ГОСТ 34.003-90 для ее обозначения используется термин цель деятельности . Всякий раз, когда очередной зритель отходит от окошка с билетом в руках, а театр становится чуточку богаче, эта цель деятельности достигается.

Функции автоматизированной системы

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

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

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

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

Задачи автоматизированной системы

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

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

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

Состав автоматизированной системы

Подсистемы

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

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

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

Компоненты

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

Компоненты — это части, из которых мы в объективной реальности строим автоматизированную систему. Система физически состоит из своих компонентов, поэтому деление автоматизированной системы на компоненты носит наиболее объективный характер.

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

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

Виды обеспечения

Одно из наиболее сложных понятий для начинающего пользователя ГОСТ 34 — вид обеспечения . Что за обеспечение такое? Можно ли его увидеть или пощупать? Продать или купить?

Каждый вид обеспечения объединяет в себе компоненты или технические решения определенного характера. В ГОСТ 34 упоминается много разных видов обеспечения, последовательно описывать здесь каждый из них мы не будем, а перечислим только наиболее заметные:

• информационное обеспечение — все данные и метаданные, с которыми работает система;
• программное обеспечение — все программы, которые входят в состав системы;
• техническое обеспечение — все технические средства (иначе говоря, оборудование, аппаратура), которые входят в состав системы.

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

1. Формирование требований к АС (1.Обследование объекта и обоснование необходимости создания АС; 2.Формирование требований пользователя к АС; 3.Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)). 2.Разработка концепции АС (1.Изучение объекта; 2.Проведение необходимых научно-исследовательских работ; 3.Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя; 4.Оформление отчёта о выполненной работе.); 3.Техническое задание (Разработка и утверждение технического задания на создание АС.); 4.Эскизный проект (1.Разработка предварительных проектных решений по системе и её частям.; 2.Разработка документации на АС и её части.); 5.Технический проект (1.Разработка проектных решений по системе и её частям. 2.Разработка документации на АС и её части. 3.Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (ТЗ) на их разработку. 4.Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.); 6.Рабочая документация (1.Разработка рабочей документации на систему и её части. 2.Разработка или адаптация программ.); 7.Ввод в действие. (1.Подготовка объекта автоматизации к вводу АС в действие. 2.Подготовка персонала. 3.Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, инфо изделиями). 4.Строительно-монтажные работы. 5.Пусконаладочные работы. 6.Проведение предварительных испытаний. 7.Проведение опытной эксплуатации. 8.Проведение приёмочных испытаний.); 8.Сопровождение АС (1.Выполнение работ в соответствии с гарантийными обязательствами. 2.Послегарантийное обслуживание.)

На этапе 1.1. "Обследование объекта и обоснование необходимости создания АС" проводят: сбор данных об объекте автоматизации и осуществляемых видах деятельности; оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; оценку целесообразности создания АС.

На этапе 1.2. "Формирование требований пользователя к АС" проводят: подготовку исходных данных для формирования требований АС; формулировку и оформление требований пользователя к АС.

На этапе 1.3. "Оформление отчёта о выполненной работе и заявки на разработку АС" проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС.

На этапах 2.1. "Изучение объекта" и 2.2. "Проведение научно-исследовательских работ" разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР.

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

На этапе 2.4. "Оформление отчёта о выполненной работе" подготавливают и оформляют отчет, содержащий описание выполненных работ.

На этапе 3.1. "Разработка и утверждение ТЗ на создание АС" проводят разработку, оформление, согласование и утверждение ТЗ.

На этапе 4.1. "Разработка предварительных проектных решений по системе и её частям" определяются: функции АС; функции подсистем, их цели и эффекты; задачи; концепция инфо базы, её структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры программных средств.

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

На этапах 4.2. и 5.2. "Разработка документации на АС и её части" проводят разработку, оформление, согласование и утверждение документации.

На этапе 5.3. "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для АС; определение технических требований и составление ТЗ на разработку изделий.

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

На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации.

На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор и адаптацию приобретаемых программных средств.

На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие.

На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

На этапе 7.4 "Строительно-монтажные работы" проводят: выполнение работ по строительству специализированных помещений для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи, их испытание.

На этапе 7.5 "Пусконаладочные работы" проводят: наладку технических и программных средств.

На этапе 7.6 "Проведение предварительных испытаний" осуществляют: испытания АС на работоспособность и соответствие ТЗ; устранение неисправностей и внесение изменений в документацию на АС; оформление акта о приёмке АС в опытную эксплуатацию.

На этапе 7.7 "Проведение опытной эксплуатации" проводят: опытную эксплуатацию АС; анализ результатов эксплуатации; доработку ПО АС; дополнительную наладку технических средств АС; оформление акта о завершении опытной эксплуатации.

На этапе 7.8 "Проведение приёмочных испытаний" проводят: испытания на соответствие ТЗ; анализ результатов испытания АС и устранение недостатков; оформление акта о приёмке АС в постоянную эксплуатацию.

На этапе 8.1 "Выполнение работ в соответствии с гарантийными обязательствами" осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении гарантийных сроков; внесению изменений в документацию на АС.

На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по: анализу функционирования системы; выявлению отклонений от проектных значений; установлению причин этих отклонений и их устранение; внесению изменений в документацию на АС.

ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Дата введения
с 01.01.1992г.

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

Стандарт устанавливает стадии и этапы создания АС. В приложении 1 приведено содержание работ на каждом этапе.

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

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

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

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

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

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

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

2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

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

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

ПРИЛОЖЕНИЕ 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-89 .

11. На этапе 5.3. "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно.

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

13. На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201-89 .

14. На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101 .

15. На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе:

• реализацию проектных решений по организационной структуре АС;
• обеспечение подразделений объекта управления инструктивно-методическими материалами;
• внедрение классификаторов информации.

16. На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

18. На этапе 7.4 "Строительно-монтажные работы" проводят:

• выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС;
• сооружение кабельных каналов;
• выполнение работ по монтажу технических средств и линий связи;
• испытание смонтированных технических средств;
• сдачу технических средств для проведения пусконаладочных работ.

19. На этапе 7.5 "Пусконаладочные работы" проводят:

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

20. На этапе 7.6 "Проведение предварительных испытаний" осуществляют:

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

21. На этапе 7.7 "Проведение опытной эксплуатации" проводят:

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

22. На этапе 7.8 "Проведение приёмочных испытаний" проводят:

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

23. На этапе 8.1 "Выполнение работ в соответствии с гарантийными обязательствами" осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по АС.

24. На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по:

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

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

ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС.

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

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

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

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

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

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

Примечания:

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

Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 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), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение.

Помимо вышеприведенной таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ , включая указание на документы, возникающие в результате этих работ , а также Приложение 2 - "Перечень организаций, участвующих в работах по созданию АС ". Это подсказывает способ адаптации стандарта к конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Причем опять-таки эта работа под силу обычному управленцу.

Стандарт ГОСТ 34.602-89

Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).

1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.

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

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

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

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

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

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

С течением времени стали видны и оборотные стороны стандарта:

• стандарт ориентирован на полностью заказную разработку системы "с нуля" и не рассчитан на внедрение готового решения с помощью типовой методологии или на комбинацию заказных разработок и внедрений;
• стандарт предлагает одну-единственную модель жизненного цикла системы, называемую каскадной, когда все работы по созданию системы линейно упорядочены и этот порядок заранее определен;
• стандарт имеет слишком формальный характер. На практике это приводит к появлению Технических заданий, по форме удовлетворяющих требованиям ГОСТ 34.602-89, но по сути малосодержательных.

Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта.

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

Зачем, в принципе, нужны при проектировании?

Получается так, что ГОСТы помогают самому проектировщику.

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

Возникает интересный вопрос: а кому нужно и все эти пояснительные записки, ТЗ и т.п.? И вот какой интересный ответ у нас получится: на 85% документирование необходимо исполнителю. Оставшиеся 15% нужны заказчику для некоего общего понимания происходящего. Но исполнителю надо четко обозначить как границы проекта, так и признаки его выполнения. Исполнитель должен уметь защищать себя от хаотичности мышления заказчика.

Итак, обратимся к ГОСТам разработчика. Основных у нас их два: ГОСТ 34й серии и ГОСТ 19й серии. 34я серия относится к разработке автоматизированных систем, а 19й – к разработке программного обеспечения.
Мы будем говорить о ГОСТе 34й серии.

В 34й серии много различных ГОСТов. Нас будут интересовать лишь некоторые из них. А именно:

1. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения
2. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
3. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
4. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем
5. ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
6. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

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

А теперь более подробно. Основным ГОСТом, вокруг которого идет т.н. пляска является ГОСТ 34.601-90 (Стадии создания). Давайте более подробно посмотрим на этот документ.

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

Как я говорил выше, ГОСТы содержат в себе перекрестные ссылки. И чтобы пойти дальше в наших рассуждениях, мы чуть-чуть заглянем в ГОСТ 34.003-90 (Термины и определения). В нем интересует определение автоматизированной системы. Это важно, т.к. нам все же надо иметь представление, что же мы собираемся создавать.

ГОСТ 34.003-90 в определении автоматизированной системы говорит нам следующее: автоматизированная система; АС: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Т.е. другими словами, АС состоит из

1. Персонала
2. комплекса средств
3. некой деятельности, подлежащей автоматизации.

Так же уточним у ГОСТа 34.003-90

1. комплекс средств автоматизации автоматизированной системы; КСА АС: Совокупность всех компонентов АС, за исключением людей
2. пользователь автоматизированной системы; пользователь AC: Лицо, участвующее в функционировании АС или использующее результаты ее функционирования
3. эксплуатационный персонал автоматизированной системы; эксплуатационный персонал АС
4. компонент автоматизированной системы; компонент AC: Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое

Итак, что же у нас получается? А получается, что мы почувствовали под ногами некоторый фундамент, на который будем опираться. Нам известно, из чего состоит автоматизированная система и уточнили, что персонал бывает двух видов: пользовательский и эксплуатационный. И логически выведем, что компонент АС, выделенный по определенному признаку будет т.с. «hardware» и «software», если совсем просто. И совокупность программы+железо будет комплекс средств автоматизации АС.

Значит, если заказчик, например, скажет «А установите мне Exchange», то это не будет АС по одной простой причине: как минимум в таком задании отсутствует вид автоматизируемой деятельности. А может быть заказчику вообще нужен не Exchange. А может ему совсем нужен не Exchange. А это значит, что требуется обследование объекта автоматизации. А значит начинается стадия первая ГОСТ 34.601-90 (Стадии создания). «Формирование требований к АС»

На этой стадии ГОСТ требует от нас сделать несколько этапов. Если перевести это на человеческий язык, то тут мы должны определить надо ли вообще что-либо разрабатывать. Целесообразно ли это различных точек зрения. В общем, провести оценку необходимости начала работ. Итогом работы по этой стадии становится отчет, который фиксирует результат.

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

В концепции нам необходимо изучить объект, где требуется произвести внедрение. Если в первой стадии мы искали причину создания АС вообще(исходя лишь из бизнес-целей, просто ГОСТ писался тогда, когда таких слов не употребляли), то на второй стадии нам необходимо найти возможные варианты, которые удовлетворяют требованиям заказчика. Например, если заказчик хочет почтовую систему, то это можно реализовать как на Exchange, так и на Postfix или на чем ни будь еще. Со своими плюсами, минусами и вариантами развития. Проводится общая экспертиза объекта и предварительно оцениваются трудозатраты. Мы, как исполнители, тоже ищем для себя наиболее оптимальный вариант.
После того, как мы придем с заказчиком к определенному единому мнению о том, какой именно вариант решения ему подходит в общих чертах больше всего, мы переходим к, не побоюсь этого слова, самому важному пункту проекта «Техническое задание»

Техническое задание, если посмотреть определение ГОСТ 34.602-89, является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

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

Оставьте свой комментарий!