Журнал опытной эксплуатации гост 34 шаблон

ЖУРНАЛ ПРОВЕДЕНИЯ ОПЫТНОЙ ЭКСПЛУАТАЦИИ СИСТЕМЫ ЗАЩИТЫ ИНФОРМАЦИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

В период с (дата начала и окончания работ) (место проведения) была проведена опытная эксплуатация системы защиты информации информационной системы (далее — СЗ).

В ходе проведения опытной эксплуатации были проведены следующие работы:

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

Опытная эксплуатация длилась (указать продолжительность). Во время опытной эксплуатации Исполнителем совместно с представителями Заказчика был заполнен журнал опытной эксплуатации, в котором содержатся сведения об отказах, сбоях, аварийных ситуациях, замечаниях и предложениях, возникших в ходе проведения опытной эксплуатации с указанием даты (таблица 1).

В результате анализа результатов опытной эксплуатации был сформирован список доработок. Порядок устранения недостатков прописан в пункте 8 документа «Программа и методика опытной эксплуатации».

Таблица 1 – Журнал опытной эксплуатации СЗ

(должность руководителя организации)

«___»_____________ 2017 г.

(Заместитель руководителя органа по аттестации)

ПРОГРАММА ПРОВЕДЕНИЯ ОПЫТНОЙ ЭКСПЛУАТАЦИИ СИСТЕМЫ ЗАЩИТЫ ИНФОРМАЦИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Объектом опытной эксплуатации является система защиты информации информационной системы (название ИС) – далее СЗ.

В информационной системе обрабатывается (указать вид информации).

(указать компоненты и топологию информационной системы).

Целями опытной эксплуатации СЗ являются:

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

Задачи, решаемые в ходе опытной эксплуатации:

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

1 Документы, на основании которых проводится опытная эксплуатация

Опытная эксплуатация проводится на основании следующих документов:

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

Опытная эксплуатация проводится в соответствии с требованиями, содержащимися в следующих нормативных документах:

• ГОСТ 21552-84 Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение;
• ГОСТ 34.603-92 Виды испытаний автоматизированных систем;
• ГОСТ 34.003-90 Автоматизированные системы. Термины и определения;

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

Продолжительность опытной эксплуатации СЗ в целом должна составлять (указать продолжительность).

В проведении опытной эксплуатации участвуют:

• Заказчик – (наименование организации, юридический адрес организации).
• Исполнитель (разработчик) – (наименование организации, юридический адрес организации).

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

По итогам тестовой эксплуатации оформляется Акт приемки СЗ в опытную эксплуатации.

Перечень проверок, включенных в программу опытной эксплуатации, включает:

• проверка работоспособности СЗ;
• проверка соответствия настроек СЗ требованиям технического задания.

Проверка работоспособности СЗ оценивается по следующим градациям:

• работоспособность обеспечена — общая продолжительность периодов неработоспособности СЗ не превышает требований Технического задания;
• работоспособность не обеспечена — общая продолжительность периодов неработоспособности СЗ превышает требования технического задания.

Проверка соответствия настроек СЗ требованиям технического задания описана в разделах оценивается отдельно по каждой функции по следующим градациям:

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

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

Таблица 1 – Порядок проведения опытной эксплуатации СЗ

При проведении опытной эксплуатации СЗ работа с СЗ должна проводиться в соответствии с эксплуатационными документами.

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

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

Также в журнале фиксируются сбои, ошибки, недостатки, возникающие и выявленные в ходе опытной эксплуатации.

Опытная эксплуатация программных средств должна проводиться в соответствии с методикой испытаний, установленной настоящим документом.

Исполнитель должен провести все необходимые для штатного функционирования комплекса настройки (подготовки).

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

По завершении опытной эксплуатации Исполнитель должен предоставить «Журнал проведения опытной эксплуатации», не содержащий критических замечаний, а также план-график устранения замечаний, выявленных на этапе проведения опытной эксплуатации.

На основании «Журнала проведения опытной эксплуатации» оформляется Акт завершения опытной эксплуатации, предоставляемый комиссии по проведению комплексных приемочных испытаний.

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

• Условия и порядок проведения опытной эксплуатации Условия проведения опытной эксплуатации
• Условия проведения опытной эксплуатации

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

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

Опытная эксплуатация проводится в условиях штатного функционирования СЗ.

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

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

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

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

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

Присутствие экспертов со стороны Заказчика необходимо на всех этапах опытной эксплуатации.

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

• в работе с ПК;
• в работе с графическим интерфейсом целевой операционной системы.
• в работе с Web-браузерами, пакетом MS Office.

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

Таблица 2 – Навыки пользователей по работе со средствами защиты

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

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

Руководитель (должность, наименование предприятия — заказчика АС)

Личная подпись Расшифровка подписи

Наименование вида АС

Наименование объекта автоматизации

Сокращенное наменование АС

На 22 листах

Действует с «___»________2007 г.

Руководитель (должность, наименование согласующей организации)

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

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

2.1 Полное наименование системы и ее условное обозначение 5

2.2 Номер договора (контракта) 5

2.3 Наименования организации-заказчика и организаций-участников работ 5

2.4 Перечень документов, на основании которых создается система 5

2.5 Плановые сроки начала и окончания работы по созданию системы 5

2.6 Источники и порядок финансирования работ 5

2.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы 5

2.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ 5

2.9 Определения, обозначения и сокращения 5

3 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ 6

3.1 Назначение системы 6

3.2 Цели создания системы 6

4 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 7

5 ТРЕБОВАНИЯ К СИСТЕМЕ 8

5.1 Требования к системе в целом 8

5.1.1 Требования к структуре и функционированию системы 8

5.1.1.1 Перечень подсистем, их назначение и основные характеристики 9

5.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы 9

5.1.2 Требования к численности и квалификации персонала системы 9

5.1.3 Показатели назначения 9

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

5.1.5 Требования к безопасности 10

5.1.6 Требования к эргономике и технической эстетике 10

5.1.7 Требования к транспортабельности для подвижных АС 10

5.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы 10

5.1.9 Требования к защите информации от несанкционированного доступа 11

5.1.10 Требования по сохранности информации при авариях 11

5.1.11 Требования к защите от влияния внешних воздействий 11

5.1.12 Требования к патентной частоте 11

5.1.13 Требования по стандартизации и унификации 11

5.1.14 Дополнительные требования 11

5.2 Требования к функциям (задачам), выполняемым системой 12

5.3 Требования к видам обеспечения 12

5.3.1 Требования к математическому обеспечению системы 12

5.3.2 Требования информационному обеспечению системы 13

5.3.3 Требования к лингвистическому обеспечению системы 13

5.3.4 Требования к программному обеспечению системы 13

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

5.3.6 Требования к метрологическому обеспечению 14

5.3.7 Требования к организационному обеспечению 14

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

6 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ 16

7 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ 17

7.1 Виды, состав, объем и методы испытаний системы 17

7.2 Общие требования к приемке работ по стадиям 17

7.3 Статус приемочной комиссии 17

8 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ 18

9 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 19

10 ИСТОЧНИКИ РАЗРАБОТКИ 20

ПРИЛОЖЕНИЕ А 21

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

В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

3НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

1) назначение системы;

2) цели создания системы.

1Назначение системы

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

2Цели создания системы

В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

4ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

5ТРЕБОВАНИЯ К СИСТЕМЕ

Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

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

1Требования к системе в целом

В подразделе «Требования к системе в целом» указывают:

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

1Требования к структуре и функционированию системы

В требованиях к структуре и функционированию системы приводят:

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

2) требования к способам и средствам связи для информационного обмена между компонентами системы;

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

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

Данной раздел можно разбить на подразделы:

1Перечень подсистем, их назначение и основные характеристики

В требованиях к численности и квалификации персонала на АС приводят:

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

3Показатели назначения

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

Для АСУ указывают:

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

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

В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

5Требования к безопасности

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

6Требования к эргономике и технической эстетике

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

7Требования к транспортабельности для подвижных АС

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

8Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

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

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

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

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

О чем статья

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

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

Кстати, ТЗ — это не первый документ, который разрабатывается в ходе проекта автоматизации. Об этом прямо говорится в пункте 1.5. ГОСТ 34.602-89: «ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии “Исследование и обоснование создания АС”». Подробнее см. в моей статье

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

ВНИМАНИЕ: ЦЕЛЬ ЭТОЙ СТАТЬИ — НЕ ЗАМЕНИТЬ ГОСТ, А РАЗЪЯСНИТЬ НЕКОТОРЫЕ ЕГО ПОЛОЖЕНИЯ.

Характерные особенности Технического задания по ГОСТ 34

Полное наименование стандарта на ТЗ по ГОСТ 34 следующее: ГОСТ 34.602-89 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

Действительно, в стандарте используется много непонятных терминов. Что, например, имеется в виду под лингвистическим обеспечением? Для прояснения использующихся понятий следует обратиться к ГОСТ 34.003-90 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».

Зачем нужен ГОСТ на Техническое задание?

Наверное, когда вам нужно составить какой-то новый для вас документ, вы ищете в Интернете шаблон такого документа или просите его у коллег. Так вот, ЛЮБОЙ стандарт на документы или процессы — это шаблон. Причем шаблон очень сильно упрощает разработку документа: за тебя уже продумали структуру и содержание, кроме того, в таком шаблоне учитываются такие моменты, про которые вы бы и не вспомнили.

Какую роль Техническое задание занимает в проекте?

Согласно пункту 1.7 стандарта РД 50-682-89, «техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком». И это действительно главный документ. В нем должно описываться все, что необходимо для разработки и внедрения системы.

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

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

Не составляйте ТЗ формально. Если вы не знаете, что писать, значит ТЗ разрабатывать еще рано, у вас нет понимания системы, еще не понятен сам автоматизируемый процесс, объект автоматизации. Вам следует составить

, об этом мы говорили в самом начале статьи.

Насколько ГОСТ 34. 602-89 устарел и есть ли более новые стандарты?

Ни насколько не устарел. Мне почти не удалось найти каких-то неактульных вещей. И никто из тех, кто заявляет об устаревании ГОСТ 34, не могут привести ни одного примера (наверное, просто не хватило квалификации для его прочтения?) Дело в том, что ГОСТ описывает общий подход к проекту автоматизации, там не идет речь о программировании, ГОСТ 34 не об этом.

Ну а если говорить о сравнении с другими стандартами, то сравнивать-то особо и не с чем. ГОСТ 34 представляет настолько широкий взгляд на проект автоматизации, что остальные стандарты в подметки не годятся (на мой взгляд). Да, они проще (поэтому и популярнее), но и глубина не та. Вот список стандартов, с которыми стоило бы ознакомиться при разработке собственных стандартов для проекта автоматизации:

• IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению.
• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
• ISO/IEC/IEEE 29148-2011. Systems and software engineering — Life cycle processes — Requirements engineering.
• ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.

Общие принципы составления ТЗ по ГОСТ 34

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницыПредпроектное обследования при разработке информационной системы

Техническое задание должен составлять бизнес-аналитик, потому что он является «переводчиком» между заказчиком и командой разработки. Задача бизнес-аналитика — разобраться в том, что нужно заказчику и выразить это так, чтобы было понятно команде. И выразить это в виде технического задания. Причем от бизнес-аналитика требуется не просто выслушать заказчика и его сотрудников, а узнать то, о чем они не сказали (а такого обычно более 50%). Поэтому аналитик должен хорошо знать автоматизируемые процессы и за счет своего знания заполнять пробелы, которые остались по результатам обследования.

Какая сторона должна составлять Техническое задание?

В основном Техническое задание составляется исполнителем? Почему?

Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34-602-89. На самом деле, у заказчика, как правило, отсутствуют соответствующие специалисты. Но ТЗ в обязательном порядке прорабатывается и согласовывается заказчиком. И вот здесь нужно обязательно добиться того, чтобы согласование не было формальным. Я всегда стараюсь настоять на том, чтобы мы вместе с заказчиком подробно разобрали каждый пункт. Ваша цель — вовлечь заказчика в проект. Иначе он так и не сформирует свои ожидания от системы, а значит, во-первых, будет недоволен любым результатом, а, во-вторых, не сможет провести необходимые организационные мероприятия.

Насколько далеко можно отходить от ГОСТ 34?

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

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

Не верите? Тогда читайте пункт 2.2 ГОСТ 34.602-89 (кстати, цифры после дефиса — год публикации стандарта или его редакции): «В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы».

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

Зачем в ТЗ по ГОСТ 34 описывается так много требований, напрямую не относящихся к функциям системы?

Действительно, в ТЗ из 30-и страниц может только 7-10 страниц быть посвящено функциям. У этого есть объяснение. Дело в том, что разработчики ГОСТ 34 совершенно по-другому смотрели на проект автоматизации, чем мы. И смотрели более правильно, более комплексно.

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

Во-вторых, составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система — это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. И правда, отбери у бухгалтеров компьютеры, они с трудом, но смогут выполнять свою работу, пусть и с бумажными реестрами. А вот 1С без бухгалтера самостоятельно работать не будет. Отсюда и множество разделов ТЗ, посвященных организационным мерам. Как говорят, ИТ-система на 20% — это ИТ, все остальное — организационные мероприятия. То есть ТЗ — это документ, в котором прописывается все необходимое для внедрения системы, от А до Я.

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

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

В-пятых, как мы уже говорили выше, ненужные подразделы можно исключать, это допускается. Например, если вы точно знаете, что в ваших разработках не может быть ничего патентованного, то зачем приводить требования к патентной чистоте? Это не тот случай, когда без воды и не туды, и не сюды.

Зачем в разных разделах говорится об одном и том же?

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

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

Нужно ли качественно оформлять ТЗ?

Хотя требования к оформлению ТЗ приводятся в пункте 3 ГОСТ 34.602-89, скажем несколько слов о данном аспекте.

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

Приведем несколько пожеланий к оформлению больших документов, как ТЗ.

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

В-четвертых, каждое отдельное требование должно быть изложено в отдельном пронумерованном абзаце. Если в одном фрагменте 2-3 требования, то читается только первое, а остальные наш мозг пропускает. ТЗ — это документ, в котором напротив каждого абзаца можно поставить галочку, выполнено ли требование или нет.

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

Заметим, что, по строгим правилам, ТЗ оформляется без рамки (об этом сказано в п. 3), а вот остальные документы — с рамкой. Это установлено в ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов (с Изменениями № 1, 2)». Данный стандарт устанавливает правила оформления всех документов, кроме ТЗ и документов, создаваемых на предпроектных стадиях. Хотя лично мне рамка не нравится ни в каких документах.

Раздел 1. «Общие сведения» /п. 3 ГОСТ 34. 602-89/

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

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

Раздел 2. «Назначение и цели создания (развития) системы» /п. 4 ГОСТ 34. 602-89/

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

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

С целью все по-другому. Цель — это ради чего мы затеваем проект. Можно назвать это бизнес-целями. Я выделяю следующие возможные цели проектов автоматизации:

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

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

Раздел 3. «Характеристики объекта автоматизации» /п. 5 ГОСТ 34. 602-89/

Очень важный, и при этом часто описываемый чисто формально раздел. Хотя, на мой взгляд, это самый важный раздел ТЗ, без него мы просто не понимаем, о чем вообще создаваемая система.

Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.

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

В данном разделе следует приводить:

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

У меня бывали случаи, когда на описание данного раздела уходило более половины времени разработки ТЗ, потому что приходится долго и скрупулезно собирать разные сведения, анализировать их и тщательно описывать.