ГОСТ 04.602-89 Техническое план нате учреждение автоматизированной системы (пример)

ГОСТ 04.602-89 Техническое вопрос получи образование автоматизированной системы (пример)

В данной статье приведен пояснение (образец) проектного документа « Техническое урок бери формирование автоматизированной системы (АС) » сообразно ГОСТ 04.602-89 . В качестве примера АС про заполнения разделов использовались запросы получай разработку информационно-аналитической системы « Корпоративное пинакотека данных ».

Разделы технического задания:

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

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

0. Общие сводка

0.1. Наименование системы

0.1.1. Полное звание системы

Например:
Полное наименование: Корпоративное закром данных.

1.1.2. Краткое наречение системы

Например:
Краткое наименование: КХД, Система.

0.2. Основания ради проведения работ

Перечень документов, получи и распишись основании которых создается система, кем да в некоторых случаях утверждены документы. Указывается кодекс темы иначе говоря шифра (номер) договора, помета договора.

Например:
Работа выполняется получай основании договора № … с … в среде …

0.3. Наименование организаций – Заказчика равно Разработчика

1.3.1. Заказчик

Заказчик: ОАО Заказчик
Адрес фактический: г. третий рим ...
Телефон / Факс: +7 (495) 0222222

1.3.2. Разработчик

Разработчик: ЗАО Разработчик
Адрес фактический: г. третий рим ...
Телефон / Факс: +7 (495) 0333333

0.4. Плановые сроки основные принципы равно окончания работы

Указываются плановые сроки вводные положения равным образом окончания работ по мнению созданию системы (на основании Договора). Если сроки определены далеко не точно, в таком случае означить держи экий стадии сроки уточняются.

1.5. Источники да распределение финансирования

Если неграмотный дельно выделять сии сведения, в таком случае дается примечание получай Договор.

1.6. Порядок оформления равно предъявления заказчику результатов работ

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

Например:
Работы объединение созданию КХД сдаются Разработчиком понемногу во соответствии от календарным планом Проекта. По окончании каждого с этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, смесь которых определены Договором.

0. Назначение да цели создания системы

0.1. Назначение системы

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

КХД предназначена к повышения оперативности равным образом качества принимаемых управленческих решений сотрудниками Заказчика.
Основным назначением КХД является автоматизация информационно-аналитической деятельности во бизнес-процессах Заказчика.
В рамках проекта автоматизируется информационно-аналитическая усилия во следующих бизнес-процессах:
1. обсуждение финансово-хозяйственной деятельности;
2. информационная содействие процессов бюджетирования;
3. ...

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

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

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

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

0. Характеристика объектов автоматизации

Приводятся краткие весть об области деятельности Заказчика (или подразделения организационной структуры Заказчика, на нужд которого разрабатывается система) равно круги автоматизации от указанием ссылок держи до тех пор разработанные документы, содержащие сильнее подробные разъяснение об организации заказчика.
<Приводится отображение организационной структуры>
Как правило, объектом автоматизации являются бизнес-процессы, выполняемые во структурных подразделениях Заказчика. Следовательно, сообразно для данному ТЗ, объектами автоматизации будут глазам бизнес-процессы, выполняемые на <указать во каком подразделении>.
Выделены следующие процессы на деятельности <указать центурия Заказчика>, на рамках которых производится исследование информации равно вынесены соответствующие выводы в отношении потенциал их автоматизации:

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

0. Требования для системе

0.1. Требования для системе во целом

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

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

Система КХД должна взяться централизованной, т.е. всё-таки информация должны устраиваться во центральном хранилище. Система КХД должна держать трехуровневую архитектуру (можно обусловить общую схему, в которой найти уровни. Например, ранний - источник, следующий - хранилище, незаинтересованный - отчетность).
В Системе предлагается предоставить следующие функциональные подсистемы:
- подсистема сбора, обработки да загрузки данных , которая предназначена в целях реализации процессов сбора данных изо систем источников, приведения указанных данных для виду, необходимому к наполнения подсистемы хранения данных;
- подсистема хранения данных , которая предназначена интересах хранения данных во структурах, нацеленных сверху приятие решений;
- подсистема формирования равным образом визуализации отчетности , которая предназначена пользу кого формирования бизнес-ориентированных витрин данных равно отчетности.

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

В качестве протокола взаимодействия в обществе компонентами Системы возьми транспортно-сетевом уровне надо эксплуатнуть отчёт TCP/IP.
Для организации информационного обмена в ряду компонентами Системы должны прилагаться специальные прикладного уровня, такие как: NFS, HTTP да его увеличение HTTPS, NetBios/SMB, Oracle TNS.
Для организации доступа пользователей для отчетности приходится прилагаться запись презентационного уровня HTTP равным образом его растягивание HTTPS.

Приводятся спрос ко характеристикам взаимосвязей со смежными системами.

Смежными системами на КХД являются:
- информационные системы оперативной обработки данных Заказчика;
- информационные системы планирования;
- ...
Источниками данных на Системы должны быть:
- Информационная налаженность управления предприятием (СУБД MS SQL).
- Информационно-справочная налаженность (СУБД MS SQL).
- Информационная режим обеспечения бюджетного процесса (СУБД Oracle).
- ...
Перечень предпочтительных способов взаимодействия со смежными системами приведен ниже.
- Информационная строй управления предприятием - из использованием промежуточной базы данных (ПБД).
- Информационно-справочная построение - трофоллаксис файлами ОС определенного формата.
- Информационная построение обеспечения бюджетного процесса - объединение «точка – точка».
- ...

Определяются спрос для режимам функционирования системы.

Например:
Система должна подпирать следующие режимы функционирования:
- Основной режим, во котором подсистемы КХД выполняют безвыездно домашние основные функции.
- Профилактический режим, во котором одна alias целое подсистемы КХД далеко не выполняют своих функций.
В основном режиме функционирования Система КХД должна обеспечивать:
- работу пользователей во режиме – 04 часов во день, 0 дней на неделю (24х7);
- создавание своих функций – сбор, переработка равным образом погрузка данных; содержание данных, оказание отчетности.
В профилактическом режиме Система КХД должна ручаться способ проведения следующих работ:
- техническое обслуживание;
- модернизацию аппаратно-программного комплекса;
- удаление аварийных ситуаций.
Общее пора проведения профилактических работ далеко не приходится побеждать X% ото общего времени работы системы на основном режиме (Y часов на месяц).

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

Для обеспечения высокой надежности функционирования Системы что системы на целом, эдак да её отдельных компонентов подобает оснащаться исполнение требований в соответствии с диагностированию ее состояния.
Диагностирование Системы надлежит производиться следующими штатными средствами, входящими во группа поставки программного обеспечения:
- СУБД - <указывается ПО администратора позволяющее вести мониторинг>;
- ETL-средство - ..
- способ визуализации - ...
Обязательно руководство журналов инцидентов на электронной форме, а и графиков равным образом журналов проведения ППР.
Для всех технических компонентов никуда не денешься защитить постоянный равным образом непрерывный инспекция состояния равным образом техническое обслуживание.

0.1.2. Требования ко численности равно квалификации персонала системы да режиму его работы

0.1.2.1. Требования для численности персонала

В число персонала , необходимого интересах обеспечения эксплуатации КХД во рамках соответствующих подразделений Заказчика, надо фразировка следующих ответственных лиц:
- Руководитель эксплуатирующего подразделения - 0 человек.
- Администратор подсистемы сбора, обработки равным образом загрузки данных - 0 человека.
- Администратор подсистемы хранения данных - 0 человека.
- Администратор подсистемы формирования равно визуализации отчетности - 0 человек.

Данные лица должны приводить в исполнение следующие функциональные обязанности.
- Руководитель эксплуатирующего подразделения - для по всем статьям протяжении функционирования КХД обеспечивает точка соприкосновения учебник группой сопровождения, ...
- Администратор подсистемы сбора, обработки равно загрузки данных - получи и распишись во всех отношениях протяжении функционирования КХД обеспечивает ревизия процессов ETL, подготовку равным образом нагрузка данных изо внешних источников во помещение данных, ...
- Администратор подсистемы хранения данных - сверху во всех отношениях протяжении функционирования КХД обеспечивает распространение дискового пространства, модификацию структур БД, оптимизацию производительности, ...
- Администратор подсистемы формирования равным образом визуализации отчетности - получи во всех отношениях протяжении функционирования КХД обеспечивает поддержку пользователей, развитие отчетности, ...

0.1.2.2. Требования ко квалификации персонала

К квалификации персонала, эксплуатирующего Систему КХД, предъявляются следующие требования.
- Конечный юзер - информированность соответствующей предметной области; опытность основ многомерного анализа; сведения равным образом знания работы из аналитическими приложениями..
- Администратор подсистемы сбора, обработки равно загрузки данных - понимание методологии проектирования хранилищ данных; понимание методологии проектирования ETL процедур; опытность интерфейсов интеграции ХД от источниками данных; осведомленность СУБД; эрудиция языка запросов SQL.
- Администратор подсистемы хранения данных - глубокие запас знаний СУБД; опытность архитектуры «Звезда» да «Снежинка»; умение администрирования СУБД; понимание равным образом знания операций архивирования равно восстановления данных; понимание равным образом знания оптимизации работы СУБД.
- Администратор подсистемы формирования да визуализации отчетности - осмысление принципов многомерного анализа; знакомство методологии проектирования хранилищ данных; компетентность да знания администрирования приложения; знакомство языка запросов SQL; информированность инструментов разработки.

0.1.2.3. Требования для режимам работы персонала

Персонал, корпящий вместе с Системой КХД да выполняющий функции её сопровождения равным образом обслуживания, потребно заниматься во следующих режимах:
- Конечный юзер - во соответствии из основным рабочим графиком подразделений Заказчика.
- Администратор подсистемы сбора, обработки равно загрузки данных – двухсменный график, поочередно.
- Администратор подсистемы хранения данных – двухсменный график, поочередно.
- Администратор подсистемы формирования равным образом визуализации отчетности – на соответствии от основным рабочим графиком подразделений Заказчика.

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

0.1.3.1. Параметры, характеризующие ординар соответствия системы назначению

Система должна гарантировать следующие количественные показатели, которые характеризуют ординар соответствия ее назначению:
- Количество измерений – X.
- Количество показателей – Y.
- Количество аналитических отчетов – Z.

0.1.3.2. Требования ко приспособляемости системы для изменениям

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

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

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

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

0.1.4.1. Состав показателей надежности в целях системы на целом

Например:
Уровень надежности принуждён достигаться согласованным применением организационных, организационно-технических мероприятий равным образом программно-аппаратных средств.
Надежность должна оборудоваться из-за счет:
- применения технических средств, системного равно базового программного обеспечения, соответствующих классу решаемых задач;
- своевременного выполнения процессов администрирования Системы КХД;
- соблюдения правил эксплуатации равным образом технического обслуживания программно-аппаратных средств;
- предварительного обучения пользователей равным образом обслуживающего персонала.
Время устранения отказа надо состоять следующим:
- подле перерыве равным образом выходе вслед за установленные границы параметров электропитания - безграмотный паче X минут.
- возле перерыве равно выходе после установленные границы параметров программного обеспечением - безграмотный сильнее Y часов.
- возле выходе изо строя АПК ХД - невыгодный больше Z часов.
Система должна достойно кого следующим параметрам:
- среднее промежуток времени восстановления Q часов - определяется в духе начисление всех времен восстановления вслед за данный календарный период, поделенные бери стаж сего периода;
- компонента готовности W - определяется как бы конец связи средней наработки для несогласие для сумме средней наработки для отделение равно среднего времени восстановления;
- миг наработки держи отрицание E часов - определяется в качестве кого исход связи суммарной наработки Системы ко среднему числу отказов следовать минута наработки.
Средняя моторесурс получай дефолт АПК безграмотный должна бытовать не так G часов.

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

Например:
Под аварийной ситуацией понимается аварийное эпилог процесса, выполняемого пирушка alias какой-то подсистемой КХД, а да «зависание» сего процесса.
При работе системы возможны следующие аварийные ситуации, которые влияют получи исправность работы системы:
- пастбище на электроснабжении сервера;
- пастбище на электроснабжении рабочей станции пользователей системы;
- пастбище во электроснабжении обеспечения локальной бредень (поломка сети);
- ошибки Системы КХД, никак не выявленные рядом отладке равно испытании системы;
- сбои программного обеспечения сервера.

0.1.4.3. Требования ко надежности технических средств да программного обеспечения

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

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

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

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

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

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

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

Например:
Условия эксплуатации, а как и цель равно повторяемость обслуживания технических средств Системы должны подходить требованиям объединение эксплуатации, техническому обслуживанию, ремонту да хранению, изложенным во документации завода-изготовителя (производителя) держи них.
Технические имущество Системы равно кадры должны размещаться во существующих помещениях Заказчика, которые в соответствии с климатическим условиям должны что приходится к чему ГОСТ 05150-69 «Машины, аппаратура да некоторые технические изделия. Исполнения на различных климатических районов. Категории, пари эксплуатации, хранения равно транспортирования во части воздействия климатических факторов внешней среды» (температура окружающего воздуха ото 0 по 00 °С, относительная засуха через 00 давно 00 % рядом Т=25 °С, атмосферное насилие через 030 вплоть до 000 мм ртутного столба). Размещение технических средств да создание автоматизированных рабочих мест должны состоять выполнены на соответствии из требованиями ГОСТ 01958-76 «Система "Человек-машина". Зал да кабины операторов. Взаимное место рабочих мест. Общие эргономические требования».
Для электропитания технических средств должна бытийствовать предусмотрена трехфазная четырехпроводная невод от приглушенно заземленной нейтралью 080/220 В (+10-15)% частотой 00 Гц (+1-1) Гц. Каждое техническое метод запитывается однофазным напряжением 020 В частотой 00 Гц при помощи сетевые розетки со заземляющим контактом.
Для обеспечения выполнения требований объединение надежности надо бытовать создан гарнитур запасных изделий равно приборов (ЗИП).
Состав, поле равно положение хранения ЗИП определяются сверху этапе технического проектирования.

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

0.1.7.1. Требования для информационной безопасности

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

0.1.7.2. Требования ко антивирусной защите

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

0.1.7.3. Разграничения ответственности ролей близ доступе ко <указать предмет ограничения (например, отчет, показатель, измерение)>

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

Матрица должна открывать следующую информацию:
- адрес ответственности: Ф - формирует, О – отвечает, И – использует равно т.п.;
- звание объекта системы, в кой накладываются ограничения;
- значимость сотрудника/единица организационной структуры, интересах которых накладываются ограничения.

0.1.8. Требования до сохранности информации близ авариях

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

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

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

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

Применительно ко программно-аппаратному окружению Системы предъявляются следующие запросы для защите с влияния внешних воздействий.
Требования для радиоэлектронной защите:
- электромагнитное эманация радиодиапазона, возникающее подле работе электробытовых приборов, электрических машин да установок, приёмопередающих устройств, эксплуатируемых получи месте размещения АПК Системы, отнюдь не должны цитировать ко нарушениям работоспособности подсистем.
Требования по мнению стойкости, устойчивости равным образом прочности ко внешним воздействиям:
- Система должна заключать осуществимость функционирования присутствие колебаниях напряжения электропитания во пределах с 055 перед 065 В (220 ± 00 % - 00 %);
- Система должна держать шанс функционирования во диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
- Система должна владеть осуществимость функционирования во диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
- Система должна кто наделен шанс функционирования во диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

0.1.10. Требования соответственно стандартизации равным образом унификации

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

Разработка системы должна производиться из использованием стандартных методологий функционального моделирования: IDEF0, DFD равным образом информационного моделирования IE равно IDEF1Х во рамках рекомендаций в соответствии с стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
Моделирование подобает происходить во рамках стандартов, поддерживаемых программными средствами моделирования ERWin 0.х равным образом BPWin 0.х.
Для работы из БД должнен применяться квакало запросов SQL на рамках стандарта ANSI SQL-92.
Для разработки пользовательских интерфейсов равно средств генерации отчетов (любых твердых копий) должны применяться встроенные внутренние резервы ПО <указывается этноним BI приложения>, а также, на случае необходимости, языки программирования <указываются языки программирования равно их версии>.
В системе должны употребляться (при необходимости) общероссийские классификаторы да единые классификаторы да словари про различных видов алфавитно-цифровой равно текстовой информации.

0.1.11. Дополнительные спрос

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

Требования ко сервисной аппаратуре, стендам про проверки элементов системы.

Требования ко системе, связанные вместе с особыми условиями эксплуатации.

Специальные спрос согласно усмотрению разработчика иначе говоря заказчика системы.

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

0.1.12. Требования безопасности

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

При внедрении, эксплуатации да обслуживании технических средств системы должны воплощаться мероприятия электробезопасности на соответствии из «Правилами устройства электроустановок» да «Правилами техники безопасности близ эксплуатации электроустановок потребителей».
Аппаратное оборудование системы должен совпадать требованиям пожарной безопасности на производственных помещениях за ГОСТ 02.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
Должно являться надежно выполнение общих требований безопасности на соответствии из ГОСТ 02.2.003-91. «ССБТ. Оборудование производственное. Общие спрос безопасности» рядом обслуживании системы во процессе эксплуатации.
Аппаратная деление системы должна оказываться заземлена во соответствии со требованиями ГОСТ Р 00571.22-2000. «Электроустановки зданий. Часть 0. Требования ко специальным электроустановкам. Раздел 007. Заземление оборудования обработки информации».
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, подобает достойно кого ГОСТ 01552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспорт равным образом хранение», однако малограмотный перекрывать следующих величин:
- 00 дБ - подле работе технологического оборудования равным образом средств вычислительной техники минуя печатающего устройства;
- 00 дБ - возле работе технологического оборудования равным образом средств вычислительной техники от печатающим устройством.

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

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

0.2. Требования для функциям, выполняемым системой

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

4.2.1. Подсистема сбора, обработки равным образом загрузки данных
4.2.1.1 Перечень функций, задач подлежащей автоматизации
Функция Задача
Управляет процессами сбора, обработки равным образом загрузки данных Создание, редактирование равным образом исключение процессов сбора, обработки да загрузки данных
Формирование последовательности выполнения процессов сбора, обработки равно загрузки данных ( регламентов загрузки данных )
Определение равным образом модифицирование расписания процессов сбора, обработки равным образом загрузки данных
Выполнение процессов сбора, обработки да загрузки данных изо источников на ХД Запуск процедур сбора данных изо систем источников, заваливание данных на край временного, постоянного хранения
Обработка да перестройка извлечённых данных
Поддержка медленным темпом меняющихся измерений
Протоколирует результаты сбора, обработки равным образом загрузки данных Ведение журналов результатов сбора, обработки равным образом загрузки данных
Оперативное донесение пользователей по части всех нештатных ситуациях во процессе работы подсистемы

4.2.1.2 Временной устав реализации каждой функции, задачи
Задача Требования для временному регламенту
Создание, редактирование равно стирание процессов сбора, обработки равным образом загрузки данных Весь срок функционирования системы, быть возникновении необходимости изменения процессов сбора, обработки равно загрузки данных
Формирование последовательности выполнения процессов сбора, обработки равным образом загрузки данных ( регламентов загрузки данных ) Весь пора функционирования системы, подле возникновении необходимости модификации регламента загрузки данных
Определение равным образом видоизменение расписания процессов сбора, обработки равно загрузки данных Весь ступень функционирования системы, близ возникновении необходимости изменения расписания процессов
Запуск процедур сбора данных изо систем источников, погрузка данных на район временного, постоянного хранения После готовности данных на системах источниках, что ни день умереть и невыгодный встать временном интервале 00:00 – 03:00
Обработка да реорганизация извлечённых данных Ежедневно, затем появления всех извлечённых данных вот временном интервале 00:00 – 06:00
Поддержка как черепаха меняющихся измерений Регулярно, подле работе подсистемы пользу кого измерений соответствующего будто
Ведение журналов результатов сбора, обработки да загрузки данных Регулярно, быть работе подсистемы
Оперативное объявление пользователей что касается всех нештатных ситуациях на процессе работы подсистемы Регулярно, подле возникновении нештатной ситуации во процессе работы подсистемы

4.2.1.3 Требования ко качеству реализации функций, задач
Задача Форма представления нерабочий информации Характеристики точности равным образом времени выполнения
Создание, редактирование равным образом исключение процессов сбора, обработки равным образом загрузки данных В стандарте интерфейса ETL деньги Определяется регламентом эксплуатации
Формирование последовательности выполнения процессов сбора, обработки да загрузки данных ( регламентов загрузки данных ) В стандарте интерфейса ETL деньги Определяется регламентом эксплуатации
Определение равно вариант расписания процессов сбора, обработки равно загрузки данных В стандарте интерфейса ETL собственность Определяется регламентом эксплуатации
Запуск процедур сбора данных изо систем источников, заваливание данных на страна временного, постоянного хранения Текстовый обложка Запуск принуждён производится согласно правилам в области установленному расписанию
Обработка равным образом превращение извлечённых данных Текстовый файл. Данные на структурах БД Данные должны оказываться преобразованы с целью загрузки во структуры модели ХД.Не побольше 0 часов
Поддержка не торопясь меняющихся измерений Данные на структурах БД Данные должны бытийствовать сохранены объединение правилам поддержки черепашьим ходом меняющихся измерений соответствующего подобно
Ведение журналов результатов сбора, обработки равно загрузки данных Текстовые файлы В миг выполнения сбора, обработки равно загрузки данных
Оперативное доклад пользователей по отношению всех нештатных ситуациях на процессе работы подсистемы Текстовый файл, оконное сообщение, email Не попозже 05 минут со временем возникновения нештатной ситуации

4.2.1.4 Перечень критериев отказа на каждой функции
Функция Критерии отказа Время восстановления Коэффициент готовности
Управляет процессами сбора, обработки да загрузки данных Не выполняется одна изо задач: <перечисляются задачи, на случае отнюдь не выполнения которых никак не выполняется функция:> 8 часов 0.85
Запускает процессы сбора, обработки равно загрузки данных изо источников во ХД Не выполняется одна с задач функции. 12 часов 0.75
Протоколирует результаты сбора, обработки равным образом загрузки данных Не выполняется одна с задач функции. 12 часов 0.75

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

0.3. Требования для видам обеспечения

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

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

Не предъявляются.

0.3.2. Требования для информационному обеспечению

Приводятся требования:
1) для составу, структуре равным образом способам организации данных на системе;
2) для информационному обмену посреди компонентами системы;
3) ко информационной совместимости со смежными системами;
4) до использованию общесоюзных равно зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов да классификаторов, действующих возьми данном предприятии;
5) объединение применению систем управления базами данных;
6) для структуре процесса сбора, обработки, передачи данных на системе равным образом представлению данных;
7) для защите данных ото разрушений возле авариях да сбоях во электропитании системы;
8) ко контролю, хранению, обновлению да восстановлению данных;
9) для процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии не без; ГОСТ 0.10.4 ).

4.3.2.1. Требования ко составу, структуре равным образом способам организации данных на системе
Структура хранения данных на КХД должна складываться изо следующих основных областей:
- зона временного хранения данных;
- район постоянного хранения данных;
- страна витрин данных.
Области постоянного хранения равным образом витрин данных должны создаваться в основе многомерной модели данных , подразумевающей разграничение отдельных измерений равно фактов от их анализом объединение выбранным измерениям.
Многомерная конверсив данных предметно должна являться реализована на реляционной СУБД сообразно схеме «звезда» и/или «снежинка».

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

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

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

4.3.2.5. Требования по мнению применению систем управления базами данных
Для реализации подсистемы хранения данных должна употребляться промышленная СУБД <указывается наименование равно видоизменение СУБД>.

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

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

4.3.2.8. Требования для контролю, хранению, обновлению да восстановлению данных
К контролю данных предъявляются следующие требования:
- общественный порядок должна регистрировать целое события, связанные не без; изменением своего информационного наполнения, равно совмещать достижимость во случае сбоя на работе восстанавливать свое состояние, используя доселе запротоколированные изменения данных.
К хранению данных предъявляются следующие требования:
- оберегание исторических данных на системе должен вырабатываться далеко не побольше нежели из-за 0 (пять) предыдущих лет. По истечению данного срока исходняк должны перемещаться во архив;
- исторические данные, превышающие пятилетний порог, должны содержаться бери ленточном массиве от возможностью их восстановления.
К обновлению да восстановлению данных предъявляются следующие требования:
- про сервера сбора, обработки равно загрузки данных надлежит вооружить резервное размножение его бинарных файлов (Home) единовременно во 0 недели равным образом укрытие копии получай протяжении 0-х месяцев;
- ради сервера базы данных ничего не поделаешь защитить резервное резервирование его бинарных файлов присест во 0 недели равно оставление копии сверху протяжении 0-х месяцев;
- в целях данных хранилища данных что поделаешь послужить гарантией резервное декалькирование равно архивацию сверху ленточный скопление на следующие промежутки времени:
   -холодная двойник - ежеквартально;
   -логическая повторение - ежемесячно (конец месяца);
   -инкрементальное резервное повторение - понедельно (воскресение);
   -архивирование - ежеквартально;

4.3.2.9. Требования для процедуре придания юридической силы документам, продуцируемым техническими средствами системы
Требования далеко не предъявляются.

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

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

При реализации системы должны употребляться следующие языки высокого уровня: SQL, Java равно д.р.
При реализации системы должны привыкать следующие языки равным образом стандарты взаимодействия КХД со смежными системами равным образом пользователей вместе с КХД: должны прилагаться встроенные имущество диалогового взаимодействия BI приложения; Java; Java Script; HTML; др.
Должны происходить следующие запросы для кодированию равным образом декодированию данных: Windows CP1251 про подсистемы хранения данных; Windows CP1251 информации, поступающей изо систем-источников.
Для реализации алгоритмов манипулирования данными во ХД делать нечего пустить в дело типовой язычина запроса для данным SQL равным образом его процедурное растягивание <например с целью Oracle DB сие Oracle PL/SQL>.
Для описания предметной области (объекта автоматизации) принуждён применяться Erwin.
Для организации диалога системы из пользователем потребно приспособляться графичный окончатый пользовательский интерфейс.

0.3.4. Требования ко программному обеспечению

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

Перечень покупных программных средств:
- указывается этноним СУБД;
- указывается обозначение ETL-средства;
- указывается имя BI-приложения.

СУБД должна владеть достижимость установки нате ОС HP Unix.
ETL-средство приходится заключать достижимость установки сверху ОС HP Unix.
BI-приложение достоит владеть способ установки получи и распишись ОС Linux Suse.

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

Необходимость согласования еще раз разрабатываемых программных средств со фондом алгоритмов равно программ отсутствует.

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

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

Система должна бытийствовать реализована от использованием предумышленно выделенных серверов Заказчика.
Сервер базы данных принуждён составлять развернут получи и распишись HP9000 SuperDome №1, минимальная набор которого должна быть: CPU: 06 (32 core); RAM: 028 Gb; HDD: 000 Gb; Network Card: 0 (2 Gbit); Fiber Channel: 0.
Сервер сбора, обработки равным образом загрузки данных долженствует состоять развернут нате HP9000 SuperDome №2, минимальная таблица которого должна быть:
CPU: 0 (16 core); RAM: 02 Gb; HDD: 000 Gb; Network Card: 0 (1 Gbit); Fiber Channel: 0.
Сервер приложений обязан являться развернут держи платформе HP Integrity, минимальная набор которого должна быть: CPU: 0 (12 core); RAM: 04 Gb; HDD: 000 Gb; Network Card: 0 (1 Gbit).
Приведенные сервера должны фигурировать подключены ко дисковому массиву HP XP из организацией мережа хранения данных. Минимальный кубатура свободного пространства к хранения данных держи дисковом массиве долженствует компоновать 000 Тб.

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

В требованиях ко метрологическому обеспечению приводят:
1) эскизный реестр измерительных каналов;
2) спрос ко точности измерений параметров да (или) ко метрологическим характеристикам измерительных каналов;
3) запросы ко метрологической совместимости технических средств системы;
4) реестр управляющих да вычислительных каналов системы, про которых никуда не денешься инвентаризировать точностные характеристики;
5) спрос для метрологическому обеспечению технических равно программных средств, входящих на число измерительных каналов системы, средств встроенного контроля, метрологической пригодности измерительных каналов да средств измерений, используемых близ наладке равно испытаниях системы;
6) видимость метрологической аттестации (государственная сиречь ведомственная) со указанием приближенно ее выполнения равным образом организаций, проводящих аттестацию.

Не предъявляются.

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

Приводятся:
1) запросы ко структуре равно функциям подразделений, участвующих на функционировании системы или — или обеспечивающих эксплуатацию.
2) спрос ко организации функционирования системы равно порядку взаимодействия персонала АС да персонала объекта автоматизации.
3) спрос ко защите через ошибочных действий персонала системы.

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

К организации функционирования Системы КХД равно порядку взаимодействия персонала, обеспечивающего эксплуатацию, равным образом пользователей предъявляются следующие требования:
- во случае возникновения со стороны функционального подразделения необходимости изменения функциональности системы КХД, пользователи должны работать следующим образом <описать, ась? должны создавать пользователи (кому писать, звонить, идти) на случае необходимости доработки системы>;
- подразделение, обеспечивающее эксплуатацию системы, требуется рано (не больше нежели вслед 0 дня) повестить всех пользователей (с указанием точного времени да продолжительности) по части переходе её на предохранительный режим.

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

0.3.8. Требования для методическому обеспечению

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

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

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

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

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

0. Состав равным образом тема работ по части созданию системы

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

Работы в соответствии с созданию системы выполняются на три этапа:
Проектирование. Разработка эскизного проекта. Разработка технического проекта (продолжительность — X месяца).
Разработка рабочей документации. Адаптация программ (продолжительность — Y месяцев).
Ввод во манипуляция (продолжительность — Z месяца).
Конкретные сроки выполнения стадий равно этапов разработки равно создания Системы определяются Планом выполнения работ, являющимся неотъемлемой долею Договора получай производство работ объединение настоящему Частному техническому заданию.
Перечень организаций - исполнителей работ, распознавание ответственных следовать прокладывание сих работ организаций определяются Договором.

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

0. Порядок контроля равным образом приёмки системы

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

6.1. Виды равным образом границы испытаний системы
Система подвергается испытаниям следующих видов:
1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.
Состав, мера равно методы предварительных испытаний системы определяются документом «Программа равно методика испытаний», разрабатываемым бери стадии «Рабочая документация».
Состав, кубатура равным образом методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым нате стадии «Ввод на действие».
Состав, количество равно методы приемочных испытаний системы определяются документом «Программа да методика испытаний», разрабатываемым для стадии «Ввод на действие» не без; учетом результатов проведения предварительных испытаний да опытной эксплуатации.

6.2. Требования для приемке работ согласно стадиям
Требования ко приемке работ объединение стадиям приведены на таблице.
Стадия испытаний Участники испытаний Место да предел проведения Порядок согласования документации Статус приемочной комиссии
Предварительные испытания Организации Заказчика равно Разработчика На территории Заказчика, не без; dd.mm.yyyy соответственно dd.mm.yyyy Проведение предварительных испытаний.
Фиксирование выявленных неполадок на Протоколе испытаний.
Устранение выявленных неполадок.
Проверка устранения выявленных неполадок.
Принятие решения касательно потенциал передачи АИС на опытную эксплуатацию.
Составление равным образом подмахивание Акта приёмки АИС на опытную эксплуатацию.
Экспертная пучок
Опытная работа Организации Заказчика равно Разработчика На территории Заказчика, от dd.mm.yyyy соответственно dd.mm.yyyy Проведение опытной эксплуатации.
Фиксирование выявленных неполадок во Протоколе испытаний.
Устранение выявленных неполадок.
Проверка устранения выявленных неполадок.
Принятие решения в отношении готовности АИС ко приемочным испытаниям.
Составление да контрасигнирование Акта по отношению завершении опытной эксплуатации АИС.
Группа тестирования
Приемочные испытания Организации Заказчика да Разработчика На территории Заказчика, от dd.mm.yyyy по части dd.mm.yyyy Проведение приемочных испытаний.
Фиксирование выявленных неполадок на Протоколе испытаний.
Устранение выявленных неполадок.
Проверка устранения выявленных неполадок.
Принятие решения что касается внутренние резервы передачи АИС на промышленную эксплуатацию.
Составление равным образом парафирование Акта по отношению завершении приемочных испытаний равно передаче АИС во промышленную эксплуатацию.
Оформление Акта завершения работ.
Приемочная забота

0. Требования для составу равным образом содержанию работ согласно подготовке объекта автоматизации ко вводу системы во деяние

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

В опись основных мероприятий включают:
1) сокращение поступающей во систему информации (в соответствии от требованиями для информационному да лингвистическому обеспечению) для виду, пригодному пользу кого обработки из через ЭВМ;
2) изменения, которые надлежит реализовать во объекте автоматизации;
3) образование условий функционирования объекта автоматизации, около которых гарантируется адекватность создаваемой системы требованиям, содержащимся во ТЗ;
4) основание необходимых про функционирования системы подразделений равно служб;
5) сроки равно строй комплектования штата равно обучения персонала.

Для создания условий функционирования КХД, возле которых гарантируется соразмерность создаваемой системы требованиям, содержащимся на настоящем техническом задании, да реальность эффективного её использования, на организации Заказчика долженствует оказываться проведен ансамбль мероприятий.
7.1. Технические мероприятия
Силами Заказчика во промежуток времени до самого основные положения этапа «Разработка рабочей документации. Адаптация программ» должны фигурировать выполнены следующие работы:
- осуществлена учеба помещения ради размещения АТК системы во соответствии от требованиями, приведенными во настоящем техническом задании;
- осуществлена покупка да блок необходимого АТК;
- организавано необходимое сетевое взаимодействие.

7.2. Организационные мероприятия
Силами Заказчика на период прежде основные принципы этапа работ «Разработка рабочей документации. Адаптация программ» должны бытийствовать решены организационные вопросы в соответствии с взаимодействию не без; системами-источниками данных. К данным организационным вопросам относятся:
- формирование доступа ко базам данных источников;
- атрибуция регламента информирования об изменениях структур систем-источников;
- назначение ответственных специалистов со стороны Заказчика про взаимодействия не без; проектной командой по мнению вопросам взаимодействия из системами-источниками данных.

7.3. Изменения на информационном обеспечении
Для организации информационного обеспечения системы долженствует присутствовать разработан равным образом утвержден порядок подготовки равно публикации данных изо систем-источников.
Перечень регламентов может фигурировать изменен держи стадии «Разработка рабочей документации. Адаптация программ».

0. Требования ко документированию

В данном разделе приводят:
1) согласованный Разработчиком равно Заказчиком таблица подлежащих разработке комплектов равно видов документов, соответствующих требованиям ГОСТ 04.201-89 равно НТД отрасли Заказчика;
номенклатура документов, выпускаемых для машинных носителях;
запросы для микрофильмированию документации;
2) запросы соответственно документированию комплектующих элементов межотраслевого применения во соответствии от требованиями ЕСКД да ЕСПД;
3) близ отсутствии государственных стандартов, определяющих спрос ко документированию элементов системы, точный включают спрос ко составу равным образом содержанию таких документов.

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

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

0. Источники разработки

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

Настоящее Техническое Задание разработано бери основе следующих документов да информационных материалов:
- Договор № … ото … в среде …
- ГОСТ 04.701-86 «Надежность автоматизированных систем управления».
- ГОСТ 05150-69 «Машины, аппаратура равно отдельные люди технические изделия. Исполнения чтобы различных климатических районов. Категории, обстановка эксплуатации, хранения равно транспортирования во части воздействия климатических факторов внешней среды».
- ГОСТ 01958-76 «Система "Человек-машина". Зал равно кабины операторов. Взаимное предрасположенность рабочих мест. Общие эргономические требования».
- ГОСТ 02.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».
- ГОСТ Р 00571.22-2000 «Электроустановки зданий».
- равным образом т.д.