Как правильно составить асу

Как за семь шагов спроектировать масштабную автоматизированную систему для крупного предприятия

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

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

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

Шаг 1: исследование предметной области

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

Шаг 2: выявление главных бизнес-целей у генерального директора предприятия

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

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

Шаг 3: выявление задач будущих пользователей системы

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

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

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

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

Сложности

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

Шаг 4: формирование информационной структуры

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

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

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

Шаг 5: разработка пользовательских сценариев

Создали базовые и вспомогательные сценарии для всех типов пользователей, шаблоны поведения.

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

Таких сценариев для MVP-версии наши специалисты описали несколько десятков. И даже при этом абсолютно все учесть на этом этапе не получилось. Остальное запланировали на следующие этапы развития проекта.

Шаг 6: создание структуры личного кабинета пользователя

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

Шаг 7: создание прототипа и технического задания

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

От начала до конца работы над проектом прошло три месяца.

Проектирование АСУ ТП

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

Основные темы раздела будут такими:

• Проектирование. Способы проектирования систем автоматизации.
• Документация. ГОСТы. Руководства. Законодательство.
• Средства разработки. SCADA. CAD-системы. Средства разработки ПО ПЛК и т.п.
• Программирование. Особенности программирования приборов АСУ.
• Примеры проектов. Здесь будем рассматривать примеры учебных и действующих проектов.

Но по мере своих скромных сил я буду расширять этот список. А теперь немного подробнее об основных принципах разработки АСУ.

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

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

Проектирование — это процесс определения архитектуры, компонентов, интерфейсов и
других характеристик системы или её части. Результатом проектирования является проект — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы (ISO 24765).

Разработка — это процесс проектирования и создания изделия (системы). Результатом разработки является изделие (система).

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

А разрабатывая АСУ, мы выдаём заказчику готовую систему “под ключ”.

Таким образом проектирование — это лишь часть (этап) разработки. Поэтому, если будете когда-нибудь работать с юридически подкованным заказчиком, то ни в коем случае не пишите в договоре “я обязуюсь разработать АСУ”, если вы не собираетесь выполнять её монтаж и пуско-наладку.

Этапы проектирования АСУ

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

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

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

• Ввод в эксплуатацию (в действие, в работу). Пуско-наладка, обучение персонала, испытания, пробная эксплуатация…
• Сопровождение. Выполнение работ по гарантийным обязательствам.

Это, так сказать, список шагов по разработке АСУ, приближённый к ГОСТовскому. Но у меня по итогам моей практической деятельности сложился свой список шагов. Он похож на этот, но всё-же немного отличается. И я об этом обязательно расскажу, но в другой раз. Так что подписывайтесь на новости, чтобы ничего не пропустить (кнопка вверху страницы справа).

Программирование АСУ

В отличие от НЕ автоматизированных инженерных систем, разработка современных АСУ ТП практически всегда включает в себя программирование.

Виды программирования я бы разделил так:

• Программирование приборов. Это даже не столько программирование, сколько конфигурирование (настройка). Обычно вы просто устанавливаете какие-то параметры, например, для таймеров, терморегуляторов, частотных преобразователей и т.п.
• Программирование панелей оператора, программируемых реле. В большинстве случаев это тоже не программирование, а конфигурирование. Хотя некоторые панели оператора позволяют писать макросы на каком-либо языке программирования. Если панель позволяет создавать полноценные программы, то это уже не панель, а панельный ПЛК (программируемый логический контроллер).
• Программирование ПЛК. Вот это уже настоящее программирование, хотя и специфическое. ПЛК — это основа современной АСУ. Соответственно, большая часть времени программиста будет потрачена на разработку ПО ПЛК.
• Программирование SCADA-систем. Это тоже программирование. Точнее, SCADA-системы позволяют писать программы на
  каком-либо языке программирования (обычно на простом, таком как Паскаль или VBScript). Однако в простых случаях это может и не понадобиться, потому что можно будет обойтись конфигурированием. SCADA-системы — это отдельная большая тема, которой я буду посвящать отдельные статьи.

Сколько времени занимает проектирование

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

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

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

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

Если же вы сам заказчик, то вы можете поступать таким же образом — разбить задачу на маленькие подзадачи,
и каждую подзадачу отдать на выполнение, например, фрилансерам. Правда, это не всегда возможно.

Ниже приведу некоторые цифры, основанные на моём опыте. Быть может, кому-то это поможет оценить трудозатраты.

• Обследование объекта. Обычно занимает 1-2 рабочих дня (с учётом поездок в пределах города и близлежащих населённых пунктов).
• Разработка ТЗ — примерно 1…2 страницы в час. ТЗ для системы средней сложности обычно содержит 20…30 страниц.
• Эскизный проект. Обычно 1…2 рабочих дня, если не углубляться в подробности (в эскизном проекте этого и не надо).
• Технический и рабочий проект:
• Чертёж формата А4 — примерно 1 час
• А3 — 1,5…2 часа
• А2 — 3..4 часа
• А1 — 7…8 часов
• А0 — 12…16 часов
• Расчётно-пояснительная записка (РПЗ) — 1…3 страницы в час. РПЗ для проекта средней сложности обычно 30…50 страниц. Ну и не все это делают, надо сказать.
• Разработка ПО. Здесь определить трудозатраты практически невозможно. Потому что это очень индивидуально и зависит от требований заказчика и от вашего опыта (или опыта вашего программиста). Поэтому здесь надо всегда брать время с запасом. Например, если вы предполагаете, что разработка ПО ПЛК займёт 40 часов, то в себестоимость надо включать не менее 60 часов, а лучше 80. То есть вашу предварительную оценку надо умножить на 1,5…2, тогда получите что-то более-менее близкое к действительности.

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

Средства разработки АСУ ТП

Здесь я буду краток, потому что средствам разработки будут посвящены отдельные статьи и даже подразделы. Итак, проектировщики и разработчики АСУ используют примерно такой набор инструментов:

• CAD-системы,
  такие как КОМПАС или
  AutoCAD. Эти системы применяются для разработки схем, чертежей, 3D-моделей и т.п.
• Средства разработки ПО ПЛК. Например, CoDeSys. С помощью этих средств разрабатываются и отлаживаются программы для ПЛК. Загрузка программ в ПЛК выполняется этими же средствами.
• SCADA-системы. С помощью этих систем создаются программы для компьютеров. Эти программы необходимы для взаимодействия с оператором, для хранения данных АСУ, для формирования отчётов и т.п.
• Конфигураторы. Используются для настроек разных приборов, таких как терморегуляторы, панели оператора, преобразователи интерфейсов, программируемые реле и т.п.
• Программы для расчётов и составления смет. Здесь есть куча всяких маленьких и больших программ,
  которые помогают делать инженерные расчёты, составлять сметы и т.п. Примеры: Гранд-СМЕТА, разные калькуляторы.
• Математические программы и симуляторы. Это используется реже, в основном для каких-то достаточно узких направлений. Но всё же иногда может быть полезно. Примеры: MathCAD, Maple, Multisim.
• Средства разработки ПО для микроконтроллеров и Ардуино. Вообще на микроконтроллерах АСУ не делают. Но есть любители, которые этим занимаются. Во всяком случае на просторах Интернета вы можете найти их проекты. Иногда довольно сложные.

Как видите, практически все средства разработки — это программы. В цифровой век живём, товарищи…

Особенности проектирования АСУ ТП

Ну в общем-то в каждом инженерном направлении есть свои особенности. Есть они и в проектировании систем автоматизации. Я бы назвал следующие:

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

Документация для разработчиков АСУ

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

1. Документы, которыми руководствуются при проектировании. Это ГОСТы, Правила, законы, технические условия, руководства и т.п.
2. Документы, которые создаются при проектировании. Ну а это уже непосредственно проектная и рабочая документация, которая появляется в ходе выполнения проектных работ. Если кратко, то всё, что было рассмотрено ранее, надо описать и задокументировать.

Но если говорить именно о документации ДЛЯ разработчиков, то это, конечно, документы из первой части.

Например, если вы разрабатываете электрические схемы для систем автоматизации, то вы должны “как отче наш” знать
ПУЭ (Правила Устройства Электроустановок).

Если вы создаёте АСУ для взрывоопасного объекта, то вы обязаны знать соответствующие ГОСТы и законодательство, определяющее правила проектирования для таких объектов.

Ну и так далее. Как видите, жизнь простого инженера-автоматизатора не легка…

Стоимость проектирования систем автоматизации

Лично для меня это самый больной вопрос (как и в случае с трудозатратами — это связанные вопросы). Потому что, в отличие от других вопросов, он почти неразрешим.

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

Но кроме трудозатрат есть ещё и стоимость инструмента, оборудования и материалов. И здесь тоже немало подводных камней. Особенно в нашей стране, где в течение года стройматериалы могут подорожать в три раза, а электрические кабели и провода — в 2…2,5.

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

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

Конечно, в крупных проектных компаниях этим занимаются экономисты. Но, как правило, и они ничего толком не могут рассчитать с нужной точностью.

Я, например, когда-то работал программистом на машиностроительном предприятии, и плотно общался с экономистами. Одной из задач был как раз расчёт себестоимости продукции. И, чтобы сделать это в программе, мне нужно было знать алгоритмы этого расчёта.

Я упорно пытал экономистов, но конкретного ответа так и не получил. Точнее, получил такой ответ: все расчеты очень приблизительны. То есть по сути цифры берутся “с потолка”.

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

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

Ну а те, кто не понимает, переплачивают. Потому что в таком случае я не могу заранее с нужной точностью сказать, сколько времени потребует разработка. Поэтому, например, если предварительно я оцениваю трудозатраты 50 часов, то я закладываю 100. На всякий случай. И, как правило, реальность получается где-то посередине. То есть 70…80 часов (с учётом мелких доработок и исправления ошибок).

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

Советы начинающим проектировщикам

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

1. Не бойтесь делать. Это главное. “Глаза боятся, а руки делают” — народная мудрость. Или “не боги горшки обжигают”. Да, это сложно. Но разобраться можно во всём. Невыполнимых задач не существует.
2. Не бойтесь ошибаться. Вроде бы это входит в первый пункт, но на самом деле нет. Это всё-таки другое. Многие боятся совершить ошибку, “облажаться”. Напрасно. Открою вам тайну — ошибаются все. Даже самые матёрые профессионалы. Иначе бы самолёты не падали. И так уж человек устроен, что лучше всего он учится именно НА СВОИХ ошибках.
3. Не бойтесь показаться глупым. Не бойтесь спрашивать. Отбросьте все комплексы — все мы когда-то пИсали в штаны. И если вас кто-то гнобит за ваши незнания, не обращайте внимания. Так поступают только люди с комплексами неполноценности — им надо самоутверждаться за счёт других. Настоящий же мастер всегда поможет разобраться со сложным вопросом, потому что он помнит, что когда-то и он был таким.
4. Изучайте законы, ПУЭ, ГОСТы и другие официальные документы, касающиеся вашей отрасли.
5. Изучайте средства разработки — это поможет вам повысить эффективность использования рабочего времени (снизить трудозатраты). Особенно это вам пригодится, если вы будете фрилансером. Потому что вы сможете делать больше за то же время, что позволит вам больше зарабатывать и получать больше клиентов.
6. Как можно больше практики на этапе входа в профессию. Делайте любые проекты. Даже если вам за это не платят или платят мало. Платить хорошо будут, когда вы наберётесь опыта. Но этого опыта вы никогда не наберётесь, если будете отказываться от работы.

Что вас ждёт дальше на пути проектировщика АСУ ТП

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

Не талант. Не связи. Не образование. А именно настойчивость.

Почему простой деревенский мужик Ломоносов стал всемирно известным учёным? Ведь у него не было ничего: ни связей, ни денег, ни образования. Талант, возможно, был. Но он так и остался бы в глухой деревне, если бы Ломоносов не был НАСТОЙЧИВЫМ и не пошёл бы пешком в столицу.

Путь автоматизатора также сложен и долог. Поэтому настойчивость — это то, что поможет вам достичь успеха на этом пути.

И можете считать это ещё одним — главным советом начинающему проектировщику — будьте настойчивы, не сдавайтесь.

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

Что почитать о проектировании АСУ ТП

Справочник инженера по АСУТП: Проектирование и разработка. Том 1

Справочник инженера по АСУТП: Проектирование и разработка. Том 2

Порядок создания, модернизации и сопровождения АСУТП

Библия электрика: ПУЭ, ПОТЭЭ, ПТЭЭП

Я не прощаюсь…

Статья получилась достаточно большой. Но я не сказал даже сотой части того, чего мог бы сказать. Поэтому данный раздел будет постоянно обновляться. И по всем подразделам мы будем продвигаться углублённо. Так что “не переключайтесь”. Подписывайтесь на новости и ждите новых статей…

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

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

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

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

На начальной стадии проектирования
выделяют следующие этапы работ:

• обследование объекта и обоснование
  необходимости создания АСУ;

• формирование требований пользователей
  к АСУ;

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

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

• изучение объекта автоматизации;

• проведение необходимых научно-исследовательских
  работ;

• разработка вариантов концепции АСУ,
  удовлетворяющих требованиям пользователей;

• оформление отчета и утверждение
  концепции.

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

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

Стадия 4. Эскизный проект:

• разработка предварительных проектных
  решений по системе и её частям;

• разработка эскизной документации на
  АСУ и её части.

Стадия 5. Технический проект:

• разработка проектных решений по системе
  и её частям;

• разработка документации на АСУ и её
  части;

• разработка и оформление документации
  на поставку комплектующих изделий;

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

Стадия 6. Рабочая документация:

• разработка рабочей документации на
  АСУ и её части;

• разработка и адаптация программ.

Стадия 7. Ввод в действие:

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация АСУ поставляемыми изделиями
  (программными и техническими средствами,
  программно-техническими комплексами,
  информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

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

• проведение приемочных испытаний.

Стадия 8. Сопровождение АСУ:

• выполнение работ в соответствии с
  гарантийными обязательствами;

• послегарантийное обслуживание.

1.6. Формирование требований к асу

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

Рекомендуется даже при проектировании
АСУ для достаточно узкой сферы деятельности
проводить комплексное обследование
объекта. При этом желательно:

• обновить или подтвердить данные о
  структуре предприятия;

• выяснить политику высшего руководства
  по тактике и стратегии развития
  предприятия;

• составить карту или паспорт технических
  и программных средств предприятия, в
  том числе эксплуатирующихся АСУ;

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

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

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

На этапе формирования требований
пользователейк АСУ рекомендуется
определить группы и отдельных сотрудников,
для которых создаваемая автоматизированная
система представляется как набор
пересекающихся или непересекающихся
функциональностей. В качестве инструмента
для этого этапа можно применить диаграммы
вариантов использования (usecasediagram)
унифицированного языка моделированияUML(UnifiedModelingLanguage).
Язык UML является простым и мощным
средством моделирования, который может
быть эффективно использован для
построения концептуальных, логических
и графических моделей сложных систем
самого различного целевого назначения.

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

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

• сформулировать общие требования к
  функциональному поведению проектируемой
  системы;

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

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

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

• характеристика объекта и результатов
  его функционирования;

• описание существующей информационной
  системы и её недостатков;

• обоснование необходимости совершенствования
  информационной системы объекта;

• цели, критерии и ограничения создания
  АСУ;

• функции и задачи создаваемой АСУ;

• выводы и предложения.

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

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

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

В разделе «Обоснование необходимости
совершенствования информационной
системы объекта» при анализе
соответствия показателей функционирования
объекта предъявляемым требованиям
оценивают степень соответствия
прогнозируемых показателей требуемым
и выявляют необходимость совершенствования
информационной системы путем создания
АСУ.

Раздел «Цели, критерии и ограничения
создания АСУ» содержит:

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

• характеристику ограничений по созданию
  АСУ.

В раздел «Функции и задачи создаваемой
АСУ» включают:

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

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

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

Раздел «Ожидаемые технико-экономические
результаты создания АСУ» содержит:

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

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

• ожидаемые обобщающие показатели
  экономической эффективности АСУ.

Раздел «Выводы и предложения» рекомендуется
разделять на подразделы:

• выводы о производственно-хозяйственной
  необходимости и технико-экономической
  целесообразности создания АСУ;

• предложения по совершенствованию
  организации и технологии процесса
  деятельности;

• рекомендации по созданию АСУ.

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

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

Третий подраздел «Рекомендации по
созданию АСУ» должен содержать:

• рекомендации по виду создаваемой АСУ,
  её совместимости с другими АСУ и
  неавтоматизируемой частью соответствующей
  системы;

• по организационной и функциональной
  структуре создаваемой АСУ;

• по составу и характеристикам подсистем
  и видов обеспечения АСУ;

• по организации использования имеющихся
  и приобретению дополнительных технических
  средств;

• по рациональной организации разработки
  и внедрения АСУ;

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

• по обеспечению производственных условий
  создания АСУ;

• любые другие рекомендации.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных»

1. Общие сведения

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

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

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

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

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

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

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

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

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

1.3.1. Заказчик

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

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

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

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

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

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

Если не целесообразно указывать эти сведения, то дается ссылка на Договор.

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

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

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

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

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

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

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

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

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

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

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

4. Требования к системе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:
Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.
Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система «Человек-машина». Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.
Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).
Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

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

4.1.7.1. Требования к информационной безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1.11. Дополнительные требования

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

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

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

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

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

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

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

При внедрении, эксплуатации и обслуживании технических средств системы должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей».
Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.
Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:
— 50 дБ — при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
— 60 дБ — при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

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

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

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

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

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

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

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

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

4.3.2. Требования к информационному обеспечению

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

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

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

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

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

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

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

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

Система должна быть реализована с использованием специально выделенных серверов Заказчика.
Сервер базы данных должен быть развернут на HP9000 SuperDome №1, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; Network Card: 2 (2 Gbit); Fiber Channel: 4.
Сервер сбора, обработки и загрузки данных должен быть развернут на HP9000 SuperDome №2, минимальная конфигурация которого должна быть:
CPU: 8 (16 core); RAM: 32 Gb; HDD: 100 Gb; Network Card: 2 (1 Gbit); Fiber Channel: 2.
Сервер приложений должен быть развернут на платформе HP Integrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; Network Card: 3 (1 Gbit).
Приведенные сервера должны быть подключены к дисковому массиву HP XP с организацией сети хранения данных. Минимальный объем свободного пространства для хранения данных на дисковом массиве должен составлять 100 Тб.

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Порядок контроля и приёмки системы

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

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

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

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

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

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

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

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

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