VII Международная студенческая научная конференция Студенческий научный форум - 2015

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

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

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

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

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

Краткое наименование - ФМУЗМО

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

Работа выполняется на основании договора №100 от ___.___.____ между ООО «Доминик» и ФГБУЗ МСЧ №142 ФМБА России

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

1.3.1. Заказчик

Заказчик: ФГБУЗ МСЧ №142 ФМБА РоссииАдрес фактический: Российская Федерация, 453571, Башкортостан Респ, Межгорье г, Олимпийская, 16Телефон: +7 (34781) 21606Факс: +7 (34781) 22003

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

Разработчик: ООО «Доминик»Адрес фактический: г. Москва, Фрунзе 34Телефон: +7 (495) 3333343Факс: +7 (495) 3347333

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

Плановые сроки начала и окончания работ по созданию системы: план-график.

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

Источники и порядок финансирования указаны в договоре №100. Финансирование работ осуществляет Заказчик. Объем и порядок финансирования определяется Календарным планом работ, Рабочей программой и Протоколом договорной цены, являющихся неотъемлемой частью Контракта (Дополнительных Соглашений) на выполнение работ в соответствии с настоящим Частным техническим заданием.

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

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

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

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

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

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

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

ФМУЗМО разрабатывается для сотрудников отдела закупок с целью:

• оперативности в обработке документов;

• повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;

• упрощению поступления документов из других отделов;

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

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

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

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

Основными задачами деятельности Федерального государственного бюджетного учреждение здравоохранения Медико-санитарная часть № 142 Федерального медико-биологического агентства России (ФГБУЗ МСЧ №142 ФМБА России) являются:

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

• - обследование эксплуатационного и обслуживающего персонала в целях его аттестации на допуск к работе

• - обеспечение условий пребывания в больничных учреждениях (проживания, питания и т.п.) Основной задачей деятельности ФГБУЗ МСЧ №142 ФМБА России является повышение качества оказываемой медицинской помощи населению России.

Организационная диаграмма представлена на рис.1

Рисунок 1 – Организационная диаграмма

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

Начальник МСЧ №142 утверждает список должностных лиц, ответственных за учет закупок медицинского оборудования (менеджеры по закупкам и др.), правильное и своевременное оформление этих операций.

Для учета закупок медицинского оборудования ФГБУЗ МСЧ №142 ФМБА России применяется первичная учетная документация, отвечающая требованиям основных положений по учету материалов и приспособленная для автоматической обработки информации. Количество экземпляров выписываемых документов и их документооборот устанавливается в зависимости от характера технического снабжения и от системы организации учета. Количество экземпляров должно быть минимальным; при использовании ЭВМ – один экземпляр, а при ручной обработке – не более двух.

На ФГБУЗ МСЧ №142 ФМБА России учет закупок медицинского оборудования в организации контролирует в первую очередь отдел закупок, который следит за выполнением поставщиком договорных обязательств, предъявляет им претензии по качеству и недостачам материалов, разыскивает грузы, если они своевременно не прибыли в организацию.

Рассмотрим факторы, которые смогут повлиять на результат работы исследуемого нами отдела. В качестве основной методологии проектирования на данном этапе будем использовать методологию ARIS, диаграмму причин и факторов Исикавы (рис. 2).

Рисунок 2 – Диаграмма Исикавы

Проведем анализ построенной диаграммы.

В начале анализа выделим «показатель качества» – «Эффективность деятельности отдела закупок», который является основным.

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

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

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

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

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

Доставка – оцениваются внешние факторы (Погодные условия: гололед, дожди и т.д., стоимость доставки), состояние дорог, которые могут привести к задержке доставки сырья и материалов.

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

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

Методика будет/не будет

Проект будет:

• Проект будет внутренним, т.к. в процессе участвуют только сотрудники отдела закупок;

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

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

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

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

Проект не будет:

• Проект не будет производить выбор поставщика медицинского оборудования;

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

• Проект не будет рассматривать работу по разгрузке и распределению медицинского оборудования на складе;

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

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

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

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

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

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

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

• «Количественный учет медицинского оборудования».

• «Анализ заявок на медицинское оборудование».

• «Принятие решения о необходимости закупки».

• «Выбор поставщика».

• «Сформировать отказ поставщику».

• «Составить план закупок».

Завершает работу системы процесс-клиент «Осуществление закупок». Таким образом, отслеживается весь путь от получение заявки на материалы до осуществления закупки.

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

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

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

Взаимодействие отдела закупок с внешними субъектами (см. рис.12)

Рисунок 12 - Взаимодействие отдела закупок с другими отделами

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

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

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

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

5 – принятие заявки на закупку медицинского оборудования от поликлиники, стационара и амбулатории.

Оперативная передача информации между отделами позволит улучшить их работу.

Система должна поддерживать следующие режимы функционирования:

• Основной режим, в котором ФМУЗМО выполняют все свои основные функции.

• Профилактический режим, в котором ФМУЗМО не выполняют своих функций.

В основном режиме функционирования, Система ФМУЗМО должна обеспечивать:

• работу пользователей в режиме – 24 часов в день, 7 дней в неделю (24х7);

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

В профилактическом режиме Система ФМУЗМО должна обеспечивать возможность проведения следующих работ:

- техническое обслуживание;

- модернизацию аппаратно-программного комплекса;

- устранение аварийных ситуаций.

Общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (Y часов в месяц).

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

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

- СУБД – Microsoft SQL Server;

- ETL-средство - Informatica PowerCenter

- средство визуализации - Gephi

Обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР.

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

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

Для поддержки функционирования ФМУЗМО Заказчиком должна быть создана Служба эксплуатации, персонал которой должен обладать знаниями в области информационных технологий. В состав персонала, необходимого для обеспечения эксплуатации комплекса средств автоматизации (КСА) Подсистемы, должны входить:

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

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

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

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

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

- - Администратор ФМУЗМО - 2 человека.

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

Данные лица должны выполнять следующие функциональные обязанности:

- Руководитель эксплуатирующего подразделения - на всем протяжении функционирования ФМУЗМО обеспечивать общее руководство группой внедрения, эксплуатации и сопровождения…

- Администратор - на всем протяжении функционирования ФМУЗМО обеспечивать информационную поддержку системы и её контроль, распределение дискового пространства, модификацию структур БД, оптимизацию производительности, формирование и визуализации отчетности, подготовку и загрузка данных из внешних источников в хранилище данных, обеспечивать поддержку пользователей и т.д.

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

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

- Администратор ФМУЗМО- знания методологии проектирования хранилищ данных, знание СУБД, знание языка запросов SQL, опыт администрирования СУБД, знания и навыки операций архивирования и восстановления данных и т.д.

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

Персонал, работающий с Системой ФМУЗМО и выполняющий функции её сопровождения и обслуживания должен работать в следующих режимах:

- Конечный пользователь - в соответствии с основным рабочим графиком подразделений Заказчика.

- Администратор ФМУЗМО– двухсменный график, поочередно.

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

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

- Количество измерений – X.

- Количество показателей – Y.

- Количество аналитических отчетов – Z.

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

Обеспечение приспособляемости системы должно выполняться за счет:

- своевременности администрирования;

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

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

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

• При изменении количества потребителей информации;

• При изменении количества услуг и приложений;

• При изменении требований к системе безопасности;

• При изменении количества поставщиков информации.

Влияние изменения количества потребителей информации

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

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

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

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

Влияние изменения количества услуг и приложений

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

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

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

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

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

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

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

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

• Процесс адаптации не должен прерывать процесс подготовки и публикации документов.

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

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

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

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

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

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

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

Надежность должна обеспечиваться за счет:

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

- своевременного выполнения процессов администрирования Системы;

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

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

Время устранения отказа должно быть следующим:

- при перерыве и выходе за установленные пределы параметров электропитания - не более X минут.

- при перерыве и выходе за установленные пределы параметров программного обеспечением

- не более Y часов.

Система должна соответствовать следующим параметрам:

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

- коэффициент готовности W - определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;- время наработки на отказ E часов - определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки. Средняя наработка на отказ системы не должна быть меньше G часов.

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

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

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

1. Сбой общего или специального программного обеспечения ФМУЗМО

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

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

ФМУЗМО должна обеспечивать возможность «горячей» замены сбойного или вышедшего из строя активного накопителя на жестком магнитном диске без остановки функционирования системы и потерь информации. В ФМУЗМО должна быть обеспечена возможность восстановления данных с внешнего накопителя после восстановления активного накопителя.

1. Ошибки в работе персонала.

Система должна локализовывать ошибки персонала.

1. Импульсные помехи, сбои или прекращение электропитания.

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

1. Прекращение электропитания на время до 15 минут не должно приводить к прекращению функционирования ФМУЗМО. Должны быть предусмотрены средства оповещения пользователей о прекращении электропитания.

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

Надежность ФМУЗМО в части технического обеспечения должна обеспечиваться:

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

• наличием на объектах автоматизации запасных изделий и приборов (ЗИП);

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

• дублированием носителей информационных массивов.

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

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

• применение технических средств соответствующих классу решаемых задач;

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

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

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

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

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

• должно быть обеспечено бесперебойное питание активного сетевого оборудования.

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

• предварительного обучения пользователей и обслуживающего персонала;

• своевременного выполнения процессов администрирования;

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

• своевременное выполнение процедур резервного копирования данных.

Надежность программного обеспечения системы должна обеспечиваться за счет:

• надежности общесистемного ПО и ПО разрабатываемого Разработчиком;

• проведением комплекса мероприятий отладки, поиска и исключения ошибок.

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

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

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

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

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

1. в части внешнего оформления:

• интерфейс системы должен быть типизирован;

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

• должен использоваться шрифт Times New Roman;

• размер шрифта должен быть 12;

• цветовая палитра должна быть в серо-белых тонах;

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

1. в части диалога с пользователем:

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

• при возникновении ошибок в работе системы – на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке.

1. в части процедур ввода-вывода данных:

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

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.8. Требования по сохранности информации при авариях

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

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

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

1. требования к радиоэлектронной защите:

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

1. требования по стойкости, устойчивости и прочности к внешним воздействиям:

• система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % - 30 %);

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

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

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

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

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

В качестве методологии проектирования используются методологии структурного анализа и проектирования SADT и ARIS. В рамках данных методологий основными инструментальными средствами являются AllFusion Process Modeler (Bpwin), AllFusion Data Modeler (ERwin) (IDEF1X),ARIS Toolset, а также Case-средство MS Visio (EPS Diagram, Cause and Effect Diagram – «Диаграмма Исикавы», Organization Chart Diagram – организационная диаграмма и Fault Tree Analysis Diagram – диаграмма «Дерево отказов»).

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 7.х и BPWin 7.х.

Для работы с БД должны использоваться язык запросов SQL в рамках стандарта ANSI SQL. В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

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

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

1.  

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

Бизнес - требования:

Исходные данные, возможности бизнеса:

Предметная область связана с учетом закупок медицинского оборудования, который должен учитывать закупленное медицинское оборудование, составлять план закупок и формировать отчетность. В отдел закупок передаются копии договоров купли продажи медицинского оборудования и ведомости учета остатков медицинского оборудования. Менеджер по закупкам ведет количественный учет закупок медицинского оборудования. При необходимости проведения закупок другие подразделения передают в отдел закупок заявки на медицинское оборудования. Менеджер по закупкам на основании данных заявок, прайс-листов поставщиков и выделенного бухгалтерией бюджета на проведения закупок формирует план закупок, который после утверждения начальником отдела закупок передается руководству. Рабочее дневное время менеджера по закупкам составляет 8 часов (480 минут). При ручном оформлении документов менеджер может принять и обработать 12 заявок. Из этого следует, что время, затрачиваемое на принятие 40 минут (480/12).

Бизнес-цели и критерии успеха:

Бизнес - цель 1. Уменьшить среднее рабочее время менеджера до 20 минут в течение 3 месяцев после первого выпуска ФМУЗМО.

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

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

Факторы бизнес-риска

Фактор бизнес - риска 1. Введение новых форм обслуживания клиентов зависит от уровня информатизации организаций. Не все поставщики готовы к новой форме обслуживания.

Фактор бизнес - риска 2. Не все сотрудники отдела закупок готовы к работе с ФМУЗМО потребуются финансовые и временные ресурсы на обучение персонала.

Фактор риска - риска 3. Возможно изменение функций сотрудников отдела закупок.

Образ решения

Положение об образе объекта

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

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

Лингвистическое обеспечение должно включать:

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

• терминологические словари.

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

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

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

• поиск информации в документах системы;

• достижение максимальных характеристик по полноте и точности при поиске информации в системе;

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

• развитую систему диалога на языке, близком к естественному;

• формирование и выдачу информации, а также ее отображение с учетом принципов «дружественного интерфейса».

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

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

В состав системы должны входить следующие подсистемы:

• подсистема хранения данных;

• подсистема расчета;

• подсистема формирования отчетности.

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

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

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

В качестве методологии проектирования используются методологии структурного анализа и проектирования SADT и ARIS. В рамках данных методологий основными инструментальными средствами являются AllFusion Process Modeler (Bpwin), AllFusion Data Modeler (ERwin) (IDEF1X),ARIS Toolset а также Case-средство MS Visio (EPS Diagram, Cause and Effect Diagram – «Диаграмма Исикавы», Organization Chart Diagram – организационная диаграмма и Fault Tree Analysis Diagram – диаграмма «Дерево отказов»).

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 7.х и BPWin 7.х.

Данные получаемые в ходе работы с системой, хранятся и обрабатываются при помощи Microsoft SQL Server. Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями.

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

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

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

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

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

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

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

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

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

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

Общие требования к приемке работ

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

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

Испытания Подсистемы должны проводиться в соответствии с ГОСТ 34.603-92.

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

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

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

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

Порядок и сроки проведения приемочных испытаний определяются Заказчиком на этапе «Опытная эксплуатация».

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

6.1 Виды и объем испытаний системы

Система подвергается испытаниям следующих видов:

1. Предварительные испытания.

2. Опытная эксплуатация.

3. Приемочные испытания.

Состав испытаний

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

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

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

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

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

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

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

Приемочные испытания должны включать проверку:

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

• выполнении каждого требования, относящегося к интерфейсу Подсистемы;

• работы персонала в диалоговом режиме;

• средств и методов восстановления работоспособности Подсистемы после отказов;

• комплектности и качества эксплуатационной документации.

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

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

• сложность процедур диалога, возможность работы персонала без специальной подготовки;

• реакция Подсистемы и ее частей на ошибки оператора, средства сервиса.

Проверка средств восстановления работоспособности Подсистемы после отказов ЭВМ должна включать:

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

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

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

При испытаниях Подсистемы проверяется:

• качество выполнения комплексом программных и технических средств автоматических функций во всех режимах функционирования Подсистемы согласно ЧТЗ

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

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

Состав и содержание работ по созданию системы регламентирован стандартом ГОСТ-34.602, РД 50-34.698-90.

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

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

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

• осуществление закупки и установки необходимого АТК;

• организацию необходимого сетевого взаимодействия.

7.2. Организационные мероприятия

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

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

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

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

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

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

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

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

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

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

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

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

7.3. Изменения в информационном обеспечении

Для организации информационного обеспечения системы должны быть разработаны и утверждены следующие регламенты:

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

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

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

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

• требования по документированию комплектующих элементов;

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

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

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

1. ГОСТ 34.602 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

2. РД 50-34.698-90 Автоматизированные системы требования к содержанию документов.

3. ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла ПС.

4. ISO 15504:1-9:1998 Оценка (аттестация) процессов жизненного цикла программных средств

5. ISO 15271:1998. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207.

6. ISO 16326:1999. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.

7. ISO 9000-3:1997. Стандарты в области административного управления качеством и обеспечения качества. Часть 3. Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.

8. ГОСТ 19-201-78 Единая система программной документации. Техническое здание. Требование к содержанию и оформлению.

9. ГОСТ 19.402-78 Единая система программной документации. Описание программы.

10. ГОСТ 19.404-79 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению.

11. ГОСТ 19.301-79 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению.

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

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

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

• Договор № … от … между …

• ГОСТ 24.701-86 «Надежность автоматизированных систем управления».

• ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды».

• ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».

• ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».

• ГОСТ Р 50571.22-2000 «Электроустановки зданий».

• и т.д.

Код для цитирования: Скопировать