Главная страница

Лабораторная работа 1. Предпроектные исследования предметной области


Скачать 1.4 Mb.
НазваниеЛабораторная работа 1. Предпроектные исследования предметной области
Дата03.04.2021
Размер1.4 Mb.
Формат файлаpdf
Имя файлаlab_9.pdf
ТипЛабораторная работа
#190841
страница5 из 10
1   2   3   4   5   6   7   8   9   10
46 соответствующего типа
Ведение журналов результатов сбора, обработки и загрузки данных
Текстовые файлы
В момент выполнения сбора, обработки и загрузки данных
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы
Текстовый файл, оконное сообщение, email
Не позднее 15 минут после возникновения нештатной ситуации
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) к информационной совместимости со смежными системами;
4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
5) по применению систем управления базами данных;

47
6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
7) к защите данных от разрушений при авариях и сбоях в электропитании системы;
8) к контролю, хранению, обновлению и восстановлению данных;
9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с
ГОСТ 6.10.4
).
4.3.2.1. Требования к составу, структуре и способам организации данных в системе
Структура хранения данных в КХД должна состоять из следующих основных областей:

область временного хранения данных;

область постоянного хранения данных;

область витрин данных.
Области постоянного хранения и витрин данных должны строиться на основе многомерной модели данных
, подразумевающей выделение отдельных измерений и фактов с их анализом по выбранным измерениям.
Многомерная модель данных физически должна быть реализована в реляционной СУБД по схеме «звезда» и/или «снежинка».
4.3.2.2. Требования к информационному обмену между компонентами системы
Информационный обмен между компонентами системы КХД должен быть реализован следующим образом:
Подсистема сбора, обработки и загрузки данных
Подсистема хранения данных
Подсистема формирования и визуализации отчетности
Подсистема сбора, обработки и загрузки данных
X
Подсистема хранения данных
X
X
Подсистема формирования и визуализации отчетности
X
4.3.2.3. Требования к информационной совместимости со смежными системами
Состав данных для осуществления информационного обмена по каждой смежной системе должен быть определен Разработчиком на стадии
«Проектирование.
Разработка эскизного проекта
Разработка технического проекта
» совместно с полномочными представителями
Заказчика.

48
Система не должна быть закрытой для смежных систем и должна поддерживать возможность экспорта данных в смежные системы через интерфейсные таблицы или файлы данных.
Система должна обеспечить возможность загрузки данных, получаемых от смежной системы.
4.3.2.4.
Требования по использованию классификаторов, унифицированных документов и классификаторов
Система, по возможности, должна использовать классификаторы и справочники, которые ведутся в системах-источниках данных.
Основные классификаторы и справочники в системе (клиенты, абоненты, бухгалтерские статьи и т.д.) должны быть едиными.
Значения классификаторов и справочников, отсутствующие в системах-источниках, но необходимые для анализа данных, необходимо поддерживать в специально разработанных файлах или репозитории базы данных.
4.3.2.5. Требования по применению систем управления базами данных
Для реализации подсистемы хранения данных должна использоваться промышленная СУБД <указывается название и версия СУБД>.
4.3.2.6. Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных
Процесс сбора, обработки и передачи данных в системе определяется регламентом процессов сбора, преобразования и загрузки данных, разрабатываемом на этапе
«Проектирование.
Разработка эскизного проекта
Разработка технического проекта
».
4.3.2.7. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы
Информация в базе данных системы должна сохраняться при возникновении аварийных ситуаций, связанных со сбоями электропитания.
Система должна иметь бесперебойное электропитание, обеспечивающее еѐ нормальное функционирование в течение 15 минут в случае отсутствия внешнего энергоснабжения, и 5 минут дополнительно для корректного завершения всех процессов.
Резервное копирование данных должно осуществляться на регулярной основе, в объѐмах, достаточных для восстановления информации в подсистеме хранения данных.
4.3.2.8. Требования к контролю, хранению, обновлению и восстановлению данных
К контролю данных предъявляются следующие требования:

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

49

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

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

к независимости программных средств от используемых СВТ и операционной среды;

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

по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.
Перечень покупных программных средств:
- указывается название СУБД;
- указывается название ETL-средства;
- указывается название BI-приложения.
СУБД должна иметь возможность установки на ОС HP Unix.
ETL-средство должно иметь возможность установки на ОС HP Unix.
BI-приложение должно иметь возможность установки на ОС Linux
Suse.
К обеспечению качества ПС предъявляются следующие требования:

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

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

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

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

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

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

51
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) требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию.

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

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

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

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

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

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

53
Патентная чистота
– это юридическое свойство объекта, заключающиеся в том, что он может быть свободно использован в данной стране без опасности нарушения действующих на ее территории патентов исключительного права, принадлежащего третьим лицам
(права промышленной собственности).
5. Состав и содержание работ по созданию системы
Данный раздел должен содержать перечень стадий и этапов работ по созданию системы в соответствии с
ГОСТ 24.601
, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.
Работы по созданию системы выполняются в три этапа:
Проектирование.
Разработка эскизного проекта.
Разработка технического проекта (продолжительность — X месяца).
Разработка рабочей документации.
Адаптация программ
(продолжительность — Y месяцев).
Ввод в действие (продолжительность — Z месяца).
Конкретные сроки выполнения стадий и этапов разработки и создания
Системы определяются
Планом выполнения работ, являющимся неотъемлемой частью Договора на выполнение работ по настоящему
Частному техническому заданию.
Перечень организаций
- исполнителей работ, определение ответственных за проведение этих работ организаций определяются
Договором.
Возможно приведение таблицы, в которой будут укрупненно описываться работы по каждому этапу, выходные результаты, участие
Разработчика и ответственность Заказчика.
6. Порядок контроля и приѐмки системы
В разделе указывают:
1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
З) статус приемочной комиссии (государственная, межведомственная, ведомственная).
6.1. Виды и объем испытаний системы
Система подвергается испытаниям следующих видов:
1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.

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

1   2   3   4   5   6   7   8   9   10


написать администратору сайта