Ввод в промышленную эксплуатацию информационных систем гост. Применение гостов при проектировании информационных систем. Консалтинг в области информационных технологий (ИТ-консалтинг) Ввод в промышленную эксплуатацию информационных систем регламент

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

Период времени работы комиссии

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

Начало проведения испытаний – 01 ноября 2010г.
Окончание проведения испытаний – 31 декабря 2010г.
Общая продолжительность проведения испытаний – 44 рабочих дня.

Наименование организации-заказчика, организации-исполнителя и организации-соисполнителя

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

Организация-заказчик – ОАО "Заказчик".
Организация-исполнитель – ЗАО "Исполнитель".
Организация-соисполнитель – ООО "Соисполнитель" (если есть).

Состав функций АИС, принимаемых в опытную эксплуатацию

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

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

В данном разделе акта приемки приводится перечень испытаний проводимых во время опытной эксплуатации. Перечень испытаний берется из раздела "Объем испытаний " Программы испытаний.

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

Перечень документов, предъявляемых комиссии

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

Инструкция по формированию и ведению базы данных (набора данных), версия 1 от 12.09.2010г.
- Руководство пользователя, версия 1 от 14.09.2010г.
- ...

Оценка соответствия принимаемой АИС техническому заданию

Приводятся оценка соответствия принимаемой АИС техническому заданию.

По результатам проведения предварительных испытаний Система соответствует требованиям, представленным в документе: « ». Версия 1.0.

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

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

По результатам проведения опытной эксплуатации должны быть получены следующие основные результаты:
- Система – работоспособна;
- Подсистемы Системы – взаимодействуют;
- Система соответствует требованиям документа «Техническое задание на создание автоматизированной системы ». Версия 1.0.;
- Все характеристики подлежащие оценке находятся в допустимых пределах.

Решение комиссии о принятии АИС в опытную эксплуатацию

Приводится решение комиссии о возможности или невозможности принятия информационной системы в опытную эксплуатацию.

Ковтун М.В. Октябрь 2010.

Главная / Провода и кабели

ГОСТ 34.601-90

Группа П87

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

СТАДИИ СОЗДАНИЯ

Information technology. Set of standards for automated systems. Automated systems. Stages of development

МКС 35.080
ОКСТУ 0034

Дата введения 1992-01-01

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

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

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 N 3469

3. ВЗАМЕН ГОСТ 24.601-86 , ГОСТ 24.602-86

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


	Номер пункта, приложения
ГОСТ 19.101-77	Приложение 1
ГОСТ 34.201-89	Приложение 1

6*. ПЕРЕИЗДАНИЕ. Июль 2009 г.
________________
* Нумерация соответствует оригиналу. - Примечание изготовителя базы данных.

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

Стандарт устанавливает стадии и этапы создания АС.

В приложении 1 приведено содержание работ на каждом этапе.

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

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

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

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

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

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

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

2.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.1. Разработка проектных решений по системе и ее частям
	5.2. Разработка документации на АС и ее части
	5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
	5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части
	6.2. Разработка или адаптация программ
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие
	7.2. Подготовка персонала
	7.3. Комплектация АС поставляемая изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
	7.4. Строительно-монтажные работы

	7.6. Проведение предварительных испытаний
	7.7. Проведение опытной эксплуатации
	7.8. Проведение приемочных испытаний
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами
	8.2. Послегарантийное обслуживание

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

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

ПРИЛОЖЕНИЕ 1 (справочное). СОДЕРЖАНИЕ РАБОТ

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

1. На этапе 1.1 "Обследование объекта и обоснование необходимости создания АС" в общем случае проводят:

Сбор данных об объекте автоматизации и осуществляемых видах деятельности;

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

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

2. На этапе 1.2 "Формирование требований пользователя к АС" проводят:

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

Формулировку и оформление требований пользователя к АС.

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

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

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

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

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

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

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

10. На этапах 4.2 и 5.2 "Разработка документации на АС и ее части" проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201 .

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

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

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

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

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

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

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

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

19. На этапе 7.5 "Пусконаладочные работы" проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы ее ведения; комплексную наладку всех средств системы.

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

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

Устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний;

Оформление акта о приемке АС в опытную эксплуатацию.

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

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

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

Анализ результатов испытаний АС и устранение недостатков, выявленных при испытаниях;

Оформление акта о приемке АС в постоянную эксплуатацию.

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

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

Анализу функционирования системы;

Выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений;

Установлению причин этих отклонений;

Устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС;

Внесению необходимых изменений в документацию на АС.

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

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

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

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

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

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

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

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

Примечания:

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

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

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2009

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

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

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

Возникает интересный: а кому нужно и все эти пояснительные записки, ТЗ и т.п.? И вот какой интересный ответ у нас получится: на 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 «Формирование требований к АС» и «Разработка концепции АС» были выполнены. От качества выполнения этих стадий зависит правильность и корректность создания ТЗ.

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

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

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

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

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

В справочнике приложении приведены пояснения и некоторые термины, применяемые в стандарте.

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

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

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

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

2.1. Стадии и этапы работ приведены в таблице.

Стадии	Этапы работ
1. Исследование и обоснование создания АС	1.1. Обследование (сбор и анализ данных) автоматизированного объекта, включая сбор сведений о зарубежных и отечественных аналогах
1. Исследование и обоснование создания АС	1.2. Разработка и оформление требований к системе (технико-экономическое обоснование, тактико-техническое задание, заявка)
2. Техническое задание	2.1. Научно-исследовательские работы*
	2.2. Разработка аванпроекта
	2.3. Разработка технического задания на АС в целом и, при необходимости, частных ТЗ на подсистемы АС
3. Эскизный проект	3.1. Разработка предварительных решений по выбранному варианту АС и отдельным видам обеспечения
4. Технический проект	4.1. Разработка окончательных решений по общесистемным вопросам, в том числе по структурам АС (функциональной, организационной); процедурам (задачам), реализуемым системой; процессу функционирования системы и, при необходимости, выдача частных технических заданий на разработку видов обеспечения АС или видов обеспечения подсистемы АС
	4.2. Разработка решений по организационному обеспечению, включая разработку плана мероприятий по подготовке к внедрению АС
	4.3. Разработка решений по техническому обеспечению
	4.4. Разработка или выбор алгоритмов автоматизируемой деятельности
	4.5. Разработка решений по информационному обеспечению
	4.6. Разработка решений по лингвистическому обеспечению
	4.7. Разработка решений по программному обеспечению
	4.8. Разработка решений по методическому обеспечению
	4.9. Разработка проектно-сметной строительной документации
	4.10. Согласование решений по связям видов обеспечения между собой и разработка общесистемной документации на АС в целом
	4.11. Составление заказной документации на поставляемые компоненты и комплексы средств автоматизации или технических заданий на их разработку
5. Рабочая документация	5.1. Разработка рабочей документации по информационному обеспечению
	5.2. Разработка рабочей документации по организационному обеспечению
	5.3. Разработка рабочей документации по методическому обеспечению
	5.4. Разработка рабочей документации по лингвистическому обеспечению
	5.5. Разработка или адаптация программ и программной документации
	5.6. Разработка документации на технические средства разового изготовления
	5.7. Разработка проектно-сметной строительной документации
6. Изготовление несерийных компонентов комплекса средств автоматизации (КСА)	6.1. Изготовление компонентов КСА
	6.2. Автономная отладка и испытание компонентов КСА
7. Ввод в действие	7.1. Подготовка организации к вводу АС в действие, обучение персонала пользователя *
	7.2. Строительно-монтажные работы *
	7.3. Комплектация АС * поставляемыми комплексами средств автоматизации, техническими средствами, программными средствами и др.
	7.4. Пуско-наладочные работы * (комплексная отладка КСА)
	7.5. Проведение опытной эксплуатации АС
	7.6. Проведение приемочных испытаний (государственных, межведомственных или ведомственных)
	7.7. Устранение замечаний, выявленных при испытаниях АС
	7.8. Приемка АС в промышленную эксплуатацию (внедрение АС)

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

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

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

Решение о возможности применения АС принимает комиссия при проведении приемочных испытаний системы.

2.4. При создании (развитии) АС обязательными стадиями являются: «Техническое задание», «Технический проект», «Рабочая документация» и «Вод в действие».

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

2.5. Обязательными этапами при создании АС являются: 1,2; 2.3; 4.1-4.5; 4.7; 4.9 - 4.11; 5.1; 5.2; 5.5; 7.1; 7.3 - 7.5; 7.6 и 7.8.

2.6. Допускается проводить научно-исследовательские работы (этап 2.1) на стадии «Исследование и обоснование создания АС», и, при необходимости, на других стадиях.

3. РЕЗУЛЬТАТЫ ВЫПОЛНЕНИЯ РАБОТ ПО СТАДИЯМ

3.1. Результатом выполнения стадии «Исследование и обоснование создания АС» является научно-технический отчет, тактико-техническое задание, технико-экономическое обоснование или заявка на создание АС.

3.2. Результатом выполнения стадии «Техническое задание» является техническое задание на создание АС.

3.3. Результатом выполнения стадии «Эскизный проект» является эскизный проект.

3.4. Результатом выполнения работ на стадии «Технический проект» является технический проект.

3.5. Результатом выполнения работ на стадии «Рабочая документация» является комплект рабочей документации АС.

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

3.7. Результатом выполнения работ на стадии «Ввод в действие» является приемка АС в промышленную эксплуатацию.

3.9. Развитие (модернизацию) или снятие системы с эксплуатации осуществляют на основании решений, принятых по результатам проведения анализа эксплуатации.

ПРИЛОЖЕНИЕ

Справочное

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

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

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

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

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

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

Стадии и Этапы работ

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

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

2. Разработка концепции АС.

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание.

Разработка и утверждение технического задания на создание АС.

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. Послегарантийное обслуживание.

ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы"

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

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

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

1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с... ».

2. СОСТАВ И СОДЕРЖАНИЕ

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

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

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

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

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

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

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

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

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

В ТЗ на АС могут включаться приложения.

ГОСТ 34.603-92 "Виды испытаний"

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

1.1. Испытания АС проводят на стадии "Ввода в действие" по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ).

1.2. Испытания АС представляют собой процесс проверки выполнения заданных функций системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик системы, выявления и устранения недостатков в действиях системы, в разработанной документации.

1.3. Для АС устанавливают следующие основные виды испытаний:

а) предварительные;

1) автономные;

2) комплексные.

б) опытная эксплуатация;

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

1) условия и порядок функционирования частей АС и АС в целом;

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

3) порядок устранения недостатков, выявленных в процессе опытной эксплуатации.

в) приемочные.

Приемочные испытания проводят в соответствии с программой, в которой указывают:

1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ);

2) критерии приемки системы и ее частей;

3) условия и сроки проведения испытаний;

4) средства для проведения испытаний;

5) фамилии лиц, ответственных за проведение испытаний;

6) методику испытаний и обработки их результатов;

7) перечень оформляемой документации.

http://www.franklin-grant.ru/ru/technologies/gost.asp

Особенности НГО. Характеристика объектов управления.

Структура НГО. Уровни и системы управления НГО.

Особенности ВТ в НГО:

1) Территориальная распределённость объектов НГО, ВТ и АС.

2) Непрерывный или дискретно-непрерывный характер технологических процессов.

3) Сложные климатические условия эксплуатации и высокая пожароопасность.

4) Низкоквалифицированный обслуживающий персонал.

5) Предприятия отрасли являются градообразующими.

Укрупнен схема взаимосвязи технологич комплексов НГО:

Этапы развития. Последовательность метасистемных переходов:

70-е гг – централизованные системы сбора и обработки информации на базе ЕС-ЭВМ: КИВЦ\РИВЦ.

80-е гг – микропроцессорная техника, появляются новые средства (децентрализованные): СМ-ЭВМ, TECHNIK, МикроДат.

90-е гг – кластерная система, множество относительно автономных подсистем: ПЭВМ.

2000 г. – клиент-серверные технологии, технологии искусственного интеллекта, зарубежные технические решения.

В наст время НГО на высоком уровне развития.

Фирменные концепции и решения по автоматизации НГО:

1) ERP (Enterprise Resource Planning) – АСУП, АС управления ресурсами предприятия.

2) EAM (Enterprise Asset Management) – АС управления производственными мощностями и фондами.

3) MES (Manufacturing Execution System) – АСУПП, системы оперативного управления производством.

4) SCADA – АСУТП, АС управления технологическими процессами.

PLC – программно-логические контроллеры.

DCS – распределенные системы управления.

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

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

4) разработка оптимальных технологических режимов;

5) расчет необходимых материальных ресурсов и их оптимальное распределение – оборудование;

6) сведение максимального баланса и анализ удельных затрат;

7) анализ простоев технологического оборудования и учет потерь;

8) автоматизированная обработка результатов исследований и технологической информации;

9) управление техническим обслуживанием и ремонтом технологического оборудования.

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

Решение этих задач направлено на поддержку принятия решений на предприятии (Средний уровень).

Функционал на уровне цеха:

1) сбор информации системами автоматизации технологических объектов;

2) создание и ведения БД;

3) формирование и передача информации на уровне предприятия;

4) контроль состояния оборудования технологических режимов;

5) оперативные расчеты эффективности мероприятия;

6) диагностика работы технологического оборудования и технических средств автоматизации;

7) ведение отчетных и плановых документов.

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

Требования к САУ на разных уровнях НГО. (рисунок)

Уровень технологического объекта:

(Нижний уровень)

1) сбор информации с датчиков и систем автоматизации по регламенту;

2) автоматическая обработка и хранения первичной информации;

3) автоматическое управление и регулирование технических объектов (задание уставов);

4) диалог с оператором технологом;

5) обеспечение контроля параметров безопасности.

Основные принципы построения АС на разных уровнях предприятия:

1) Инвариантность выполнения функций на каж уровне упр-я по отношению к колич-ву и типам технологич объектов: система д\б настраиваема на конкрет тех объекты открытой и дополняемой нов ф-ми. Дерево типов объектов => дерево конкретных объектов.

2) Интеллектуализация тех и программ ср-в путем автоматизац ф-й персонала.

3) Стандартизац, гарантирован-я совместимость аппарат и программ ср-в и как следствие снижение затрат на их эксплуатацию.

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

Виды обеспечений АС. Проблемы, модели и средства интеграции АСУ в НГО

В общем случае автоматизированные системы состоят из программно-технических комплексов(ПТК), программно-методических комплексов(ПМК) и компонентов техн. Программного и информационного обеспечения.

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

ПО АС – совокупность программ на носителях информации с программной документацией по ГОСТ 19.101.

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

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

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

Математическое обеспечение АС – совокупность математических методов моделей и алгоритмов обработки информации используемых при функционировании системы.

Лингвистическое обеспечение – совокупность языковых средств для построения и сочетания информационных единиц КСА.

Порядок ввода ЭИС в эксплуатацию.

ТИПОВОЕ АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ. СТАДИЯ ВВОДА В ЭКСПЛУАТАЦИЮ.

ЛЕКЦИЯ 10.

Согласно ГОСТ 34.601-90 «АС. Стадии создания» и ГОСТ 34.603-92 «Виды испытаний АС» В рамках стадии ввода системы в эксплуатацию проводят следующие работы:

1) организационная подготовка объекта автоматизации к вводу ИС в действие – реализация проектных решений по организационной структуре, обеспечение подразделений объекта управления инструктивно-методическими материалами, внедрение классификаторов информации;

2) подготовка персонала – обучение персонала и проверка его способности обеспечить функционирование ИС;

3) комплектация ИС поставляемыми изделиями (в случае описанной в ТЗ необходимости такой поставки) – получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий, проведение входного контроля их качества;

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

5) пусконаладочные работы – автономная наладка технических и программных средств, загрузка информации в базу данных и проверка ее ведения, комплексная наладка всех средств системы;

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

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

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

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

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

Стадия ввода в эксплуатацию включает в себя опытную эксплуатацию комплексов задач и прием их в промышленную эксплуатацию после проведения приемо-сдаточных испытаний. В промышленную эксплуатацию всю систему принимают после завершения приема в эксплуатацию всех комплексов задач.

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

1. Проверка подсистемы или комплекса задач на полном объеме реальных данных, но не в реальные сроки, необходимые для управления.

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

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

4. Окончательный переход на работу новой системы.

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

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

2) накопление информации;

3) выход на проектную мощность.

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

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

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

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

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

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

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

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

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

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

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

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

Примером организационной структуры проекта внедрения ERP-системы на крупном промышленном предприятии может служить следующая организационная структура:

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

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

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

Следует отметить, что в состав организационной структуры проекта внедрения обязательно входят продуктовые ИТ- консультанты. Так, в организационную структуру проекта SAP включают лидеров по модулям (Module Leaders ), которые несут ответственность за каждый из базовых модулей, планируемых к внедрению.

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

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

6.7.6. Работы при определении границ проекта и плана внедрения

Основой подготовки устава проекта является стандарт ANSI PMI PMBOK® 3-rd Edition (2004) - основной стандарт, описывающий все процессы управления проектами.

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

Устав может включать в себя:

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

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

Для определения рамок проекта необходимо выделить те виды деятельности и подразделения, которых коснется автоматизация.

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

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

Стратегия внедрения определяет подход к внедрению программного продукта в организации. Существуют различные стратегии внедрения, используемые ведущими разработчиками программных продуктов. Например, при внедрении ERP-систем обычно применяют стратегии "Большого взрыва", "Шаг за шагом", пилотное внедрение.

Принцип "Большого взрыва" предполагает одновременное внедрение всех функциональных модулей программного продукта и замен старых систем.

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

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

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

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

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

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

6.7.7. Разработка документа "Дизайн системы"

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

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

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

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

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

6.7.8. Управление процессом настройки программного продукта

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

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

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

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

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

6.7.9. Работы при управлении процессом создания пилотной версии информационной системы

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

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

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

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

По окончании работ продуктовый ИТ-консультант участвует в подготовке отчета, содержащего результаты пилотного проекта .

6.7.10. Обучение персонала организации методологии внедрения и использования выбранного ИТ - решения

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

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

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

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

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

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

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

6.7.11. Организация опытной эксплуатации информационной системы и разработка методики испытаний

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

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

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

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

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

При организации опытной эксплуатации информационной системы задачей продуктового ИТ-консультанта является разработка документа "Программа и методика проведения испытаний".

Документ "Программа и методика испытаний" включает:

условия и порядок функционирования частей информационной системы и информационной системы в целом;
продолжительность опытной эксплуатации , достаточную для проверки правильности функционирования информационной системы при выполнении каждой функции системы и готовности персонала к работе в условиях функционирования информационной системы;Работа завершается оформлением акта о завершении опытной эксплуатации и допуске к приемочным испытаниям.
6.7.12. Управление вводом информационной системы в промышленную эксплуатацию и разработка ее регламентов
Задача управления вводом информационной системы в промышленную эксплуатацию включает подготовку и утверждение детального плана перехода на новую систему и плана её дальнейшей поддержки, проведение приемочных испытаний информационной системы. В этих работах принимает участие продуктовый ИТ- консультант.
Как уже говорилось, приемочным испытаниям информационной системы должна предшествовать её опытная эксплуатация. На основе результатов опытной эксплуатации проводится распространение полученного опыта на все участки, входящие в границы проекта, в соответствии с принятой стратегией развертки информационной системы.
Приемочные испытания информационной системы проводят для определения её соответствия техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки информационной системы в промышленную эксплуатацию.
В соответствии с ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем" документ "Программа приемочных испытаний " содержит:
- перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты технического задания);
- критерии приемки системы и ее частей;
- условия и сроки проведения испытаний;
- средства для проведения испытаний;
- фамилии лиц, ответственных за проведение испытаний;
- методику испытаний и обработки их результатов;
- перечень оформляемой документации.
Приемочные испытания включают проверку:
- полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования информационной системы, указанных в техническом задании;
- выполнения каждого требования, относящегося к интерфейсу системы;
- работы персонала в диалоговом режиме;
- средств и методов восстановления работоспособности информационной системы после отказов;
- комплектности и качества эксплуатационной документации.
6.7.13. Организация мониторинга результатов внедрения информационной системы и внесения необходимых модификаций
В течении установленных сроков продуктовым ИТ-консультантом осуществляются работы по организации мониторинга работы информационной системы и внесения необходимых модификаций. Эти работы направлены на улучшение эффективности и производительности информационной системы. Обычно они включают следующие мероприятия:
- дополнительное обучение пользователей;
- консультирование пользователей;
- мониторинг характеристик работы информационной системы;
- анализ полученных результатов мониторинга и выработка рекомендаций по внесению необходимых изменений
- управление процессом внесения изменений и модернизацией информационной системы;
- разработка дополнительной документации, внесение изменений в существующую документацию.

УТВЕРЖДАЮ

Заместитель директора Департамента государственного регулирования в экономике

Министерства экономического развития Российской Федерации
______________ В.Н. Руденко
«09 » _ноября __ 2011 г

АКТ ВВОДА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ

Автоматизированной информационной системы управления проектами, разработанной в рамках государственного контракта от 7 ноября 2011 г. № ГК-158-ОФ/Д01.
В соответствии с совместным решением Заказчика (Минэкономразвития России) и Исполнителя (ООО «ОТР 2000») о введении в опытную эксплуатацию.

Комиссия в составе:

Председателя комиссии:

Заместителя директора Департамента государственного регулирования в экономике В.Н. Руденко,

Членов комиссии:

Исполняющего обязанности начальника отдела развития электронного общества Департамента государственного регулирования в экономике С.В.Пушакова,

Советника отдела методического обеспечения организации межведомственного взаимодействия Департамента государственного регулирования в экономике А.В. Матвеенко,

Ведущего консультанта отдела развития электронного общества Департамента государственного регулирования в экономике Н.Н. Кирсановой,

Руководителя направления ООО «ОТР 2000» А.И. Кулешова,

Руководителя проектов ООО «ОТР 2000» О.В. Страхова,

Ведущего аналитика ООО «ОТР 2000» Ю.М. Гудковой,

Научного сотрудника направления «Реальный сектор» ИЭП имени Е.Т. Гайдара Э.Р. Батаршина.
в период с "_08 _" ноября 2011 года по "_09 _" ноября 2011 года провела предварительные испытания прикладного программного обеспечения автоматизированной информационной системы «Портал проектного управления» (АИС ППУ), установленного в Минэкономразвития России.

Предварительные испытания признаны успешно завершенными.

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

Перечень функций, принимаемых в опытную эксплуатацию (раздел «Требования к функциям, выполняемым системой» технического задания):
1. Ведение перечня проектов.
2. Работа с проектными сущностями.
3. Работа с показателями по оценке состояния работ по проекту.
4. Аналитический модуль.
5. Библиотека документов.

Перечень предоставленных комиссии документов, необходимых для проведения опытной эксплуатации:
1. «Описание АИС «Портал проектного Управления»» (Паспорт системы);
2. «Инструкция администратора АИС ППУ»;
3. «Инструкция пользователя АИС ППУ»;
4. «Программа и методика испытаний АИС ППУ»;
5. «Тестовые задания для АИС ППУ»;
6. «Ролевая инструкция, описывающая порядок работы с АИС ППУ в качестве инструмента управления проектами «Межведомственное взаимодействие»».
Решение комиссии: Принять программное обеспечение в опытную эксплуатацию с 9 ноября 2011 года.

ПРИЛОЖЕНИЯ:

Протокол предварительных испытаний № 1
Протокол предварительных испытаний № 2

Члены комиссии:

В.Н. Руденко

С.В. Пущаков

А.В. Матвеенко

Н.Н. Кирсанова

А.И. Кулешов

О.В. Страхова

Ю.М. Гудкова

Э.Р. Батаршин

Период времени работы комиссии

Наименование организации-заказчика, организации-исполнителя и организации-соисполнителя

Состав функций АИС, принимаемых в опытную эксплуатацию

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

Перечень документов, предъявляемых комиссии

Оценка соответствия принимаемой АИС техническому заданию

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

Решение комиссии о принятии АИС в опытную эксплуатацию

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

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

ПРИЛОЖЕНИЕ 1 (справочное). СОДЕРЖАНИЕ РАБОТ

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

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

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

3. РЕЗУЛЬТАТЫ ВЫПОЛНЕНИЯ РАБОТ ПО СТАДИЯМ

ПРИЛОЖЕНИЕ

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

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

6.7.6. Работы при определении границ проекта и плана внедрения

6.7.7. Разработка документа "Дизайн системы"

6.7.8. Управление процессом настройки программного продукта

6.7.9. Работы при управлении процессом создания пилотной версии информационной системы

6.7.10. Обучение персонала организации методологии внедрения и использования выбранного ИТ - решения

6.7.11. Организация опытной эксплуатации информационной системы и разработка методики испытаний

6.7.12. Управление вводом информационной системы в промышленную эксплуатацию и разработка ее регламентов

6.7.13. Организация мониторинга результатов внедрения информационной системы и внесения необходимых модификаций