РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ НА СОЗДАНИЕ ФУНКЦИОНАЛЬНОГО МОДУЛЯ АРХИВАЦИИ ДАННЫХ ДЛЯ ОРДЖОНИКИДЗЕВСКОГО РОСП

Горбунов Д.П. 1

1МГТУ им. Носова

Работа в формате PDF

769.6 KB

Сертификат участника

Комментарии

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

Введение

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

В соответствии с Указом Президента Российской Федерации от 09.03.2004 № 314 "О системе и структуре федеральных органов исполнительной власти" завершена работа по реорганизации Министерства юстиции Российской Федерации и созданию подведомственных ему федеральных служб. Во исполнение данного указа проведена реорганизация службы судебных приставов Министерства юстиции Российской Федерации в ^{Федеральную службу судебных приставов.}

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

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

В качестве объекта автоматизации рассматривается отдел организации исполнительного производства.

Цель проектной работы: разработать ТЗ функционального модуля по архивации данных.

Для достижения цели необходимо решить следующие задачи:

Проанализировать предметную область, описать основные бизнес-процессы на предприятии, построить модель “as-is”(как есть).
Выявить «узкие места» на предприятии и сформировать предложения по их совершенствованию. Сформировать требования пользователей к информационной системе.
Рассчитать экономическую эффективность проекта.
Разработать концепцию проектирования функционального модуля; построить модель “to-be” (как должно быть) бизнес-процессов деятельности объекта автоматизации.
Создать ТЗ функционального модуля.

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

В качестве методологии проектирования используются методологии структурного (SADT) и объектного(RUP) анализа и проектирования. В рамках данных методологий основными инструментальными средствами являются Case-средства AllFusion Data Modeler (ERwin) (IDEF1X); MS Visio (Cause and Effect Diagram – «Диаграмма Исикавы», Organization Chart Diagram – организационная диаграмма). А также Case-средство Rational Rose (Use Case Diagramm – диаграмма вариантов использования).

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

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

Organization Chart Diagram – организационная диаграмма (MS Visio), для получения общего представления об организационной структуре Орджоникидзевского РОСП
Effect Diagram – “Диаграмма Исикавы” (MS Visio), которая позволит выявить факторы, влияющие на создание исполнительных производств.
EPS Diagram – диаграмма , которая показывает весь процесс работы отдела организации исполнительного производства.
Use Case Diagram – диаграмма вариантов использования (Rational Rose) для представления связи между отделами в оконной фабрике ООО «Квалитет групп».

На защиту выносится ТЗ функционального модуля по архивации данных

Глава 1. Технико-экономическая характеристика отдела по организации исполнительного производства Орджоникидзевского РОСП Деятельность службы судебных приставов

В соответствии с законодательством РФ Управление ФССП действует в следующих областях:

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

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

Организационная структура Орджоникидзевского РОСП представлена на рисунке 1.

Рис.1. – Организационная структура Орджоникидзевского РОСП

Территориальным органом Федеральной службы судебных приставов является главное управление Федеральной службы судебных приставов, действующее на территории субъекта РФ. В территориальный орган ФССП России входят: аппарат управления и структурные отделы территориального органа ФССП России.

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

Используя методику «будет/не будет» определим, какие объекты и процессы будут принадлежать нашей предметной области.

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

проект будет предназначен для повышения качества работы ФССП: судебных приставов-исполнителей и архивариусов;
проект будет внешним, поскольку в данной задаче происходит взаимодействие с клиентами или другими представителями «внешней среды»;
проект будет рассматривать снижение затрат времени на подготовку и передачу исполнительных производств на ответственное хранение в архив подразделения;
Проект будет рассматривать уведомление через интернет.

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

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

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

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

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

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

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

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

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

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

В ходе анализа системы были выделены следующие «узкие места»:

Затраты времени на создание не электронного (бумажного) архива исполнительных производств составляют около 8 мин. на каждое исполнительное производство, что приводит к замедлению исполнению должностных обязанностей судебных приставов-исполнителей и архивариуса, а как следствие к снижению производительности труда.
Хранение документов в бумажном виде приводит к неэффективному использованию площадей и проблемам при восстановлении испорченных или утерянных документов. В случае утери исполнительных документов, по каждому такому факту проводится служебная проверка, законом предусмотрена административная и уголовная ответственность виновных лиц, т.е. потеря документов недопустима.
Распределённое хранение документов усложняет контроль за её использованием, разграничение доступа и защиту информации. Исполнительные документы в архиве хранятся от 1 года до 100 лет.

1.2 Формирование требований пользователя к ИС

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

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

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

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

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

На основе полученных данных была построена диаграмма вариантов использования информационной системы для пристава-исполнителя – Use Case Diagram (Рисунок 5). Требования пользователя направлены на устранение “узких мест”.

Рисунок 5 - Диаграмма вариантов использования

Действующее лицо

Вариант использования (прецедент)

Пристав-исполнитель

Сканирование поступивших документов

Возбуждение личного дела

Занесение отсканированных данных в исполнительное производство

Формирование ежемесячного отчета

1.3.Расчет экономической эффективности проекта

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

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

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

Э = ΔЭ_год – С – Е×К = ΔЭ_год – П(1)

Где ∆Э_год - годовая экономия (прибыль), вызванная ИС, без учета эксплуатационных затрат на ИС;

С - эксплуатационные затраты на ИС;

К - единовременные затраты (капиталовложения), связанные с созданием ИС;

Е - норма прибыли на капитал (нормативная прибыльность);

П - годовые приведенные затраты на ИС: П=С + ЕК

Единицы измерения в формуле (размерность величин) следующие:

Э - руб./г.; ∆Э_год - руб./г.; С - руб./г., К - руб.; Е - 1/г.; П - руб./г.

(∆Э — С) — это хозяйственная или бухгалтерская прибыль. Она представляет собой разность между выручкой и явными затратами. По рыночной терминологии, явные затраты (ExplicitCost) — это все денежные издержки предприятия, включая амортизацию.

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

Так, если Центральный банк РФ установил с 14 сентября 2012 года ставку рефинансирования 8,25%; норму прибыли на капитал необходимо установить равной 8,25%.

Рассмотрим составляющие затрат формулы (1) и произведем их расчет.

Капитальные затраты (К)

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

Применительно к ИС группировать капитальные затраты можно следующим образом (2):

К ꞊ Кпр + Ктс + Кпс + Киб + Куч + Кво + Кнеучт (2)

где Кпр - затраты на проектирование модуля;

Ктс - затраты на технические средства управления;

Кпс - затраты на программные средства;

Киб - затраты на формирование информационной базы;

Куч - затраты на обучение персонала;

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

Кнеучт - неучтенные затраты, обычно составляют 7-8% от общих затрат.

Затраты на формирование информационной базы Киб относятся к формированию условно-постоянной информации.

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

Произведем расчет капитальных затрат:

Кпр - затраты на проектирование модуля

Кпр=з/пл программистов*кол-во специалистов*срок проектирования = 15000руб*2*1 мес.= 30000руб.

Киб - затраты на формирование информационной базы

Киб=кол-во экспертов*з/пл*срок формирования инф.базы =3*10000*0,5 мес =15000руб.

Куч - затраты на обучение персонала

Куч=з/пл пристава-исполнителя*срок обучения=20000*1 мес=20000руб.

Итого получаем:

К=(30000+15000+20000)+7% неучтенных затрат=69550руб.

Эксплуатационные затраты (С)

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

В состав эксплуатационных затрат на информационную систему входят следующие затраты:

(3),

где Сао — амортизационные отчисления;

Сто— затраты на техническое обслуживание, включая заработную плату персонала ИС;

Син — затраты, связанные с использованием глобальных вычислительных сетей (Интернета и др.);

Сэл — затраты на электроэнергию;

Спр — прочие затраты составляют примерно 7%.

Введение новой ИС не повлияет на такие затраты, как:

а) амортизационные отчисления (Сао);

б)затраты, связанные с использованием глобальных вычислительных сетей (Син).

Произведем расчет эксплуатационных затрат:

Сто— затраты на техническое обслуживание, включая заработную плату персонала ИС;

Сто =(з/пл пристава – исполнителя*12 мес)*25%=20000*12*0,25=60000 руб/год

Сэл — затраты на электроэнергию

Сэл=400 руб.мес.*кол-во раб.мест*12мес=14400руб/год

Итого получаем:

С=60000+14400+7%=74400+7%=79608руб./год

Проведем расчет годовых приведенных затрат на ИС

Итого получаем:

П=С+Е*К=79608 +69550*8,25 % =85346руб.

Перейдем к рассмотрению показателей расчета годовой экономии (прибыли), вызванной ИС, без учета эксплуатационных затрат на ИС (ΔЭ_год).

Методика определения экономической эффективности на основе статических показателей сводится к расчету годовой экономии (прибыли), вызванной ИС, как суммы прямого и косвенного эффектов:

ΔЭ_год = Э_прям + Э_косв

Прямой экономический эффект

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

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

Произведем расчет прямого экономического эффекта:

где - сокращение заработной платы управленческого персонала при внедрении ИС;

- суммарные эксплуатационные затраты на ИС за исключением заработной платы управленческого персонала.

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

Сзп — заработная плата управленческого персонала в предлагаемом варианте.

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

П=С+Е*К=79608 +69550*8,25 % =85346руб.

Э прям = – С – Е×К=- П

Э прям= -79608 руб =0-79608 =-79608 руб.

Величина прямого экономического эффекта является недостаточной (даже отрицательной) для оправдания затрат на внедрение ИС. Это объясняется отсутствием экономии на заработной плате управленческого персонала.

В этом случае внедрение ИС целесообразно, только если есть уверенность в достаточно большом косвенном экономическом эффекте.

Косвенный экономический эффект

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

Произведем расчет косвенного экономического эффекта.

Э = ∆Э_год – С – Е×К = ∆Э_год – П = Э_прям+ Э_{косв = -}П + Э_косв

Э_косв = А + С_себ +Ш,

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

∆А - годовой прирост выручки от реализации продукции =0

∆Ссеб - годовая экономия на себестоимости продукции объекта управления;

∆Ш - сокращение штрафов и других непланируемых потерь за год ; Общая сумма штрафов за год, вызванная потерей документов по вине отдела, равна примерно 300 000 руб. Функциональный модуль отдела позволит снизить эти потери на 20% в год.

Итого ΔШ=300 000 руб.-(300000руб-20%)=60 000 руб.

Состав статей, по которым рассчитывается экономия на себестоимости продукции за счет ИС, обычно следующий :

где ∆Ск - экономия на канцелярии;

∆Сэ - экономия на эл. энергии на технологические цели;

∆Сзп - экономия на заработной плате сотрудников;

∆Ссэо - экономия на содержании и эксплуатации оборудования;

∆Сдок - сокращение потерь документов.

Если внедрение ИС не влияет на какую-либо статью затрат в составе себестоимости, то эта статья, не фигурирует в расчете косвенного экономического эффекта.

В структуре себестоимости основную долю занимают материальные затраты – 38% ; затраты на оплату труда с отчислениями – 36%; прочие затраты – 26% (∆Сэ+∆Ссэо+∆Сдок ).

Запланируем 3% сокращения затрат на оплату труда за счет отмены некоторых функций и 20% сокращения затрат на канцелярию. Для простоты расчета объединим экономию по энергии, содержанию оборудования и потерям документов и запланируем 1% экономии.

Себестоимость работ - 90000.

Получаем:

∆Ск - экономия на канцелярии

ΔСк=90000*38%-(38%*90000-20%)=6840 руб./мес.;

∆Сзп - экономия на заработной плате сотрудников

ΔСзп=90000*36%-(36%*90000-3%)=972 руб./мес.;

ΔСпроч=ΔСэ+ΔСсэо+ΔСдок

ΔСпроч=26%*90000-(26%*90000-1%)=234 руб/мес.

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

ΔСсеб=12*(ΔСк+ΔСзп+ΔСпроч)=12*(6840 руб./мес.+ 972 руб./мес.+ 234 руб/мес) =12*8046руб/мес. =96552руб/год

Таким образом,

Экосв=ΔА+ΔСсеб+ΔШ =0+96552+60000=156552руб.

Эгод=Экосв+Эпрям=156552 - 79608 =76944руб.

Годовой экономический эффект - абсолютный показатель эффективности.

Т.к. Э>0, то система эффективна.

Вспомогательные показатели экономической эффективности:

-Расчетная прибыльность (рентабельность):

Ер=Эгод/К=76944 /69550=1,106

-Срок окупаемости:

Ток=1/Ер=К/Эгод=0,9 - проект окупится через 1 месяц.

Разработка новой автоматизированной информационной системы будет производится в течение 1 месяца, в одну смену продолжительностью 8 часов. Заработная плата разработчика за 1 месяц, с учетом районного коэффициента и единого социального налога, составит 12 000 рублей. (Количество разработчиков - 2). В итоге затраты на разработку ИС, включая формирования начальной информационной базы и обучение диспетчера, составят 69550 руб.

Затраты на техническое обслуживание ИС в течение года и затраты на заработную плату сотрудника работающего с ИС составит 79608 руб в год.

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

Вывод по главе 1: В первой главе данной проектной работы было проведено предпроектное обследование предметной области.

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

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

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

Глава 2. Формирование технического задания функционального модуля по архивации данных для отдела по организации исполнительного производства.

УТВЕРЖДАЮ:

Директор РОСП

Личная подпись:

Расшифровка подписи: Герасимов А.М.

Печать

Дата: 02.10.13

УТВЕРЖДАЮ:

Горбунов Д.П.

Личная подпись:

Расшифровка подписи: Горбунов Д.П.

Печать

Дата: 02.10.13

Функциональный модуль по архивации данных

ФССП РФ

наименование вида АС

Отдел по организации исполнительного производстванаименование объекта автоматизации

«ФМО»

сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На 40 листах

Действует с 2.10.2013

СОГЛАСОВАНО

Руководитель: начальник отдела по организации исполнительного производства

Личная подпись

Расшифровка подписи: Герасимов А.М.

Печать

Дата 2.10.2013

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

2.1.1 Наименование системы

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

Полное наименование – функциональный модуль по архивации данных

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

Краткое наименование – ФМО.

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

Работа выполняется на основании договора №1 от 2.10.2013 между РОСП Орджоникидзевского р-на и Горбуновым Д.П.

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

2.1.3.1 Заказчик

Заказчик: РОСП Орджоникидзевского р-на

Адрес фактический: 455000, г. Магнитогорск, ул. Советской армии, д.6.

Телефон: (3519)26-07-65

Факс:

2.1.3.2 Разработчик

Разработчик: Адрес фактический:455021,г.Магнитогорск,ул.Сиреневый д.23

Телефон: +79642457154

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

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

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

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

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

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

2.2. Назначение и цели создания АС.

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

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

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

Основными задачами ФССП России являются:

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

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

Рисунок 6 - Организационная структура отдела

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

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

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

Далее разработаем событийную цепочку процессов диспетчерского отдела, представленную на рисунке 8.

Рисунок 8- Диаграмма EPC

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

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

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

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

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

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

1. работу пользователей в режиме – 24 часов в день, 7 дней в неделю (24х7);
2. выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.

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

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

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

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

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

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

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

Системный администратор;
Администратор баз данных;
Администратор информационной безопасности;
Пользователь.

Основными обязанностями системного администратора являются:

Модернизация, настройка и мониторинг работоспособности комплекса технических средств (серверов, рабочих станций);

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

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

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

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

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

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

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

При изменении количества потребителей информации;
При изменении количества услуг и приложений;
При изменении требований к системе безопасности;
При изменении количества поставщиков информации.

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

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

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

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

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

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

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

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

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

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

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

Таблица 4 – Требования к сохранению работоспособности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

интерфейс системы должен быть типизирован;
должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;
должен использоваться шрифт Times New Roman;
размер шрифта должен быть 12;
цветовая палитра должна быть в сине-белых тонах;
в шапке форм, документов и отчетов должен использоваться логотип Заказчика.

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

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

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

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

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

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

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40°С, относительная влажность от 40 до 80 % при Т=25°С, атмосферное давление от 630 до 800 мм ртутного столба).

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

Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220В частотой 50 Гц через сетевые розетки с заземляющим контактом.

Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).

Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».

Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.

Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».

Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:

- 50 дБ - при работе технологического оборудования и средств вычислительной техники без печатающего устройства;

- 60 дБ - при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

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

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

2.4.2. Разработка прототипа системы

Построим модели “to-be” (как должно быть) с учетом внедрения информационной системы.

Разработаем контекстную диаграмму диаграмму представления EPC (рис.12)

Рисунок 12- Диаграмма EPC «to-be»

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

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

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

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

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

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

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

Таблица 12 – Требования к информационному обмену

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

2.4.3.2.2. Требования к информационной совместимости со смежными системами

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

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

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

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

Для реализации подсистемы хранения данных должна использоваться промышленная СУБД.

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

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

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

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

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

2.4.3.2.7. Требования к контролю, хранению, обновлению и восстановлению данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данные получаемые в ходе работы с системой, хранятся и обрабатываются при помощи Microsoft SQL Server. Основной используемый язык запросов — Transact-SQL.

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

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

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

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

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

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

Специальные требования к техническому обеспечению отсутствуют 2.4.3.6. Требования к метрологическому обеспечению Не предъявляются.

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

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

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

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

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

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

Не указывается.

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

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

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

Данный раздел должен содержать перечень стадий и этапов работ по созданию системы в соответствии с в соответствии с ГОСТ 24.601.

Разработаем в среде MS Project следующие документы: план проекта (рис.23), график проекта (рис.24), лист ресурсов (рис.25), использование ресурсов (рис.26), использование задач (рис.27)

Рисунок 23 - План проекта

Рисунок 24 - График проекта

Рисунок 25 - Лист ресурсов

Рисунок 26 - Использование ресурсов

Рисунок 27 Использование задач

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7.1Технические мероприятия

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

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

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

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

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

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

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

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

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

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

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

2.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 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению.

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

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

Договор №1 от 20.10.2013 между Орджоникидзевским РОСП и Горбуновым Д.П.
ГОСТ 24.701-86 “Надежность автоматизированных систем управления”.
ГОСТ 15150-69 “Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды”.
ГОСТ 21958-76 “Система “Человек-машина”. Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования”.

СОСТАВИЛИ

Наименование организации	Должность исполнителя	Фамилия имя, отчество	Подпись	Дата

СОГЛАСОВАНО

Наименование организации	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата

Выводы по главе 2

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

В ТЗ были отражены следующие моменты:

Общие сведения об информационной системе.
Назначение и цели создания системы.
Характеристика объектов автоматизации.
Требования к системе.
Состав и содержание работ по созданию системы
Порядок контроля и приемки системы.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
Требования к документированию.
Источники разработки.

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

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

Список литературы

ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения.
ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.
ГОСТ 34.320-96 Информационная технология. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы.
ГОСТ 34.321- 96 Информационная технология. Система стандартов по базам данных. Эталонная модель.
ГОСТ 34.601-90 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
ГОСТ 34.603-92 Информационные технологии. Виды испытаний автоматизированных систем.
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.
ГОСТ Р ИСО/МЭК 15271-98 «Информационные технология. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
ГОСТ Р 50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования
Ипатова Э.Р., Ипатов Ю.В. Проектирование информационных систем: Учебное пособие.— Магнитогорск: МаГУ, 2003. — 187 c.
Ипатова Э.Р., Ипатов Ю.В. Практикум по проектированию информационных систем: Учеб. пособие. – Магнитогорск: МаГУ, 2004. – 116 с.
Липаев В.В. Надежность программных средств. - М.:Синтег, 1999.
Управление Федеральной службы судебных приставов http://www.r74.fssprus.ru/
Типовая инструкция по делопроизводству в федеральных органах исполнительной власти. М., 2005
Савельев А.М. Практические вопросы автоматизации документооборота в органах власти и других государственных структурах Российской Федерации // Делопроизводство. 2007. № 2. С. 55-58.
Рысков О.И. О некоторых проблемах использования электронных документов в делопроизводстве федеральных органов исполнительной власти // Делопроизводство. 2004. №1. С. 11-17.
Баласанян В.Э. Применение автоматизированных систем документационного обеспечения управления (АС ДОУ) для повышения эффективности управления //Делопроизводство. 2002. № 2. С.27 – 29.
Баласанян В.Э. Какой должна быть современная автоматизированная система документационного обеспечения управления//

Делопроизводство. 2004. № 1. С. 18

Бачило И.Л. О проблемах информационного права в области документирования и документооборота //Делопроизводство. 2002. № 2. С. 5-8.

Заключение

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

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

Для реализации обозначенных ранее задач был использован метод анкетирования, анкету заполнял начальник отдела Гречкосий Николай Александрович.; так же использовались следующие методологии структурного анализа и проектирования: SADT, RUP и ARIS.

Были построены модели:

Organization Chart Diagram – организационная диаграмма (MS Visio);
Effect Diagram – «Диаграмма Исикавы» (MS Visio);
eEPC Diagram – диаграмма потока работ (MS Visio);
Use Case Diagram – диаграмма вариантов использования (Rational Rose);

Приложение

Анкета

Название подразделения: отдел судебных приставов
Фамилия, имя, отчество начальника: Герасимов Алексей Михайлович.
Фамилия, имя, отчество заместителя начальника отдела: Савельева Елена Юрьевна.
Основная цель отдела: Своевременное и качественное решение вопросов по неоплаченным задолжностям.
Основные функции отдела: взаимодействие с должниками, розыск задолжников, конфискация имущества.
Документы, поступающие в отдел из других подразделений: Исполнительный лист, Судебное постановление.
Документы, формирующиеся в отделе судебных приставов: Исполнительное производство.
Физическое представление время, частота и вид обработки и требования к безопасности каждого из этих документов: Электронный документ - составляются по мере обращения клиентов. Отчет - формируются ежемесячно, поквартально, ежегодно в виде бумажного документа.
Продолжительность хранения каждого из документов и условия перевода в архив: Заносятся в электронную базу. Отчеты хранятся в течение трех лет и по истечении срока сдаются в архив.
Физическое представление время и частота отправки, вид обработки и требования к безопасности каждого из этих документов: Отчеты – бумажный документ, хранение в специальной папке, передаются руководителю предприятия.
Информация, передающаяся из отдела судебных приставов во внешние органы: различные постановления, запросы, ответы, требования.
Описание информационной инфраструктуры (техническое оснащение и программные продукты) отдела судебных приставов: в настоящее отдел судебных приставов оснащен компьютерной техникой.
Основные недостатки бизнес-процессов и существующей системы обработки документов в отделе судебных приставов: дублирование информации, сложности при работе с бумажными документами, сложность формирования отчетности и поиска информации.
Предложения по реорганизации бизнес-процессов и существующей системы обработки документов в отделе судебных приставов: разработки и внедрения АИС в организацию не требует ,т.к. на предприятии уже установлена программа : АИС ФССП v 1.18
Дата заполнения анкеты: __________________.
Подпись: ________________________________.

Просмотров работы: 3281

Код для цитирования:

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

РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ НА СОЗДАНИЕ ФУНКЦИОНАЛЬНОГО МОДУЛЯ АРХИВАЦИИ ДАННЫХ ДЛЯ ОРДЖОНИКИДЗЕВСКОГО РОСП

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