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. Требования к численности персонала

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

• Руководитель эксплуатирующего подразделения - 1 человек.

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

• Администратор подсистемы хранения данных - 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. Требования к сохранению работоспособности системы в различных вероятных условиях

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

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

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.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

регламентом эксплуатации

обработки и загрузки данных

средства

Запуск процедур сбора

данных из систем источников,

Текстовый

Запуск должен

загрузка данных в область

файл

производится точно по

временного, постоянного

установленному расписанию

хранения

Обработка и

Текстовый

Данные должны быть

преобразованы для загрузки в

преобразование извлечѐнных

файл. Данные в

структуры модели ХД.Не

данных

структурах БД

более 2 часов

Поддержка медленно

Данные в

Данные должны быть

меняющихся измерений

структурах БД

сохранены по правилам

поддержки медленно

меняющихся измерений

соответствующего типа

Ведение журналов

Текстовые

В момент выполнения

результатов сбора, обработки и

сбора, обработки и загрузки

файлы

загрузки данных

данных

Оперативное извещение

Текстовый

Не позднее 15 минут

пользователей о всех нештатных

файл, оконное

после возникновения

ситуациях в процессе работы

сообщение, email

нештатной ситуации

подсистемы

4.2.1.4 Перечень критериев отказа для каждой функции

Функция

Критерии отказа

Время

циент

Коэффи

восстановления

готовности

Не выполняется

Управляет

одна из задач:

процессами сбора,

<перечисляются задачи,

8 часов

0.85

обработки и

в случае не выполнения

загрузки данных

которых не выполняется

функция:>

Запускает

процессы сбора,

Не выполняется

обработки и

12 часов

0.75

одна из задач функции.

загрузки данных из

источников в ХД

Протоколиру

ет результаты сбора,

Не выполняется

12 часов

0.75

обработки и

одна из задач функции.

загрузки данных

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

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

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

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

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

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

1. к составу, структуре и способам организации данных в системе;

2. к информационному обмену между компонентами системы;

3. к информационной совместимости со смежными системами;

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

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

3. к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

3. к защите данных от разрушений при авариях и сбоях в электропитании системы;

4. к контролю, хранению, обновлению и восстановлению данных;

3. к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.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. Требования к защите данных от разрушений при авариях и сбоях в

электропитании системы

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

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

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

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

4.3.2.8. Требования к контролю, хранению, обновлению и восстановлению данных К контролю данных предъявляются следующие требования:

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

К хранению данных предъявляются следующие требования:

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

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

К обновлению и восстановлению данных предъявляются следующие требования:

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

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

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

-холодная копия — ежеквартально;

-логическая копия - ежемесячно (конец месяца);

-инкрементальное резервное копирование - еженедельно (воскресение); -архивирование - ежеквартально;

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

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

Для лингвистического обеспечения системы приводятся требования к применению

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

При реализации системы должны применяться следующие языки высокого уровня: SQL, Java и д.р.

При реализации системы должны применяться следующие языки и стандарты взаимодействия КХД со смежными системами и пользователей с КХД: должны использоваться встроенные средства диалогового взаимодействия BI приложения; Java;

Java Script; HTML; др.

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

Для реализации алгоритмов манипулирования данными в ХД необходимо использовать стандартный язык запроса к данным SQL и его процедурное расширение <например для

Oracle DB это Oracle PL/SQL>.

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

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

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

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

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

- указывается название ETL-средства; - указывается название BI-приложения.

СУБД должна иметь возможность установки на ОС HP Unix.

ETL-средство должно иметь возможность установки на ОС HP Unix.

BI-приложение должно иметь возможность установки на ОС Linux Suse.

К обеспечению качества ПС предъявляются следующие требования:

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

• надежность должна обеспечиваться за счет предупреждения ошибок - не допущения ошибок в готовых ПС;

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

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

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

• также на каждом этапе в разработке ПС должна проводится проверка правильности принятых решений по разработке и применению готовых ПС.

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

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. Требования к метрологическому обеспечению

• требованиях к метрологическому обеспечению приводят: