Техническое задание автоматизация бизнес процессов

Большинство компаний всё чаще произносят слово “бизнес-процесс” в нужное время и в нужном месте. Это значит, что рассматривая ИТ-систему в какой-либо предметной области, готовя требования к проекту, разговаривая с поставщиками, Команда выбора и ЛПР говорят о процессах.

Какие аспекты работы бизнес-процесса стоит учесть при написании ТЗ для его автоматизации?

На уровне отдельной операции процесса Пол Хармон в книге Business Process Change выделяет 5 аспектов, которые необходимо учесть при стандартизации операции бизнес-процесса, которые влияют на производительность операции:

1. Activity Specification. Стандартизирована ли операция? Знает и понимает ли исполнитель ожидаемый результат? Разделяет ли исполнитель мнение о том, что стандарт операции достижим?
2. Activity Support. Может ли исполнитель с легкостью понять момент, когда нужно начать выполнение операции? Может ли операция быть выполнена без влияния на другие активности исполнителя? Имеются ли необходимые ресурсы для исполнения операции?
3. Consequences. Соответсвуют ли выходы операции желаемой производительности? Результаты операции значимы для исполнителя? Выходы операции контролируются по времени?
4. Feedback. Получает ли исполнитель информацию о своей производительности? Получает ли исполнитель обратную связь по соответствию выходов операции ожиданиям?
5. Skill, knowledge and capability. Имеет ли исполнитель необходимые компетенции и знания? Понимает ли исполнитель общую значимость своей производительности? Имеет ли исполнитель эмоциональную возможность достичь необходимую производительность?

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

Автоматизация бизнес процессов на базе 1С ERP

Схема подготовки требований

Как разработчик BPM-системы мы сталкиваемся с тем, что графическая схема процесса (построенная, например, в Business Studio) не является техническим заданием для его автоматизации. Информация, изложенная на схеме процесса, дает лишь первичное представление о процессе, она является необходимой, но недостаточной для подготовки задания на автоматизацию.

Схема инициации процесса. Необходимо предусмотреть правила, мотивы и удобство старта бизнес-процесса. Это гарантирует, что им будут пользоваться сотрудники или клиенты. Различные способы запуска процесса позволяют “органично встроить” процесс в работу компании.

Схема создания ценности. Коротко о ценности процесса. Для чего он нужен компании? Что от процесса ожидает его заказчик? Можно проанализировать приоритеты заказчика процесса, исходя из них выбрать логику процесса и средства автоматизации.

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

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

Этап проектирования и техническое задание (ТЗ) в проектах по автоматизации

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

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

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

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

1. Создается единое понимание/видение процесса, которое разделяется бизнесом компании, ИТ-специалистами компании и будущим исполнителем;
2. Прорабатывая требования в комплексе, компания лучшим образом понимает приоритетные и вторичные требования к системе. Компания прорабатывает сценарии использования будущей системы;
3. У компании появляется фундамент для оценки применимости различных инструментов автоматизации.

Источник: medium.com

Техническое задание на автоматизацию: каким оно должно быть, состав и технологии создания

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

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

Почему так важно правильно начинать? Только одно начало ведет только к одному концу.

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

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

Согласно диалектике результат, например, внедренная IT-система (важно, не просто реализованная, но внедренная!), это – развернутое начало.

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

Все начинается с идеи

В начале было слово.

В начале создания любого программного обеспечения нужно слово. Это бриф. Иначе говоря – идея. Когда мы хотим создать любое программное обеспечение, сначала нужно сформировать идею.

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

Для примера, идеей может быть: «Разработать IT-систему для контроля взаиморасчетов» или «Разработать IT-систему для автоматизации продаж». Также это может быть описание процесса, например, в таком виде:

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

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

Как формулировать идею

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

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

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

А что если мы хотели совсем не то, что в итоге получилось?

Этот вопрос-возражение нередко задают заказчики. Обычно он звучит так:

“Мы хотели CRM-систему, а написали, что нужна ERP” или “Нам нужна была CMS для сайта, а мы написали CRM”.

Ошибки в терминологии – распространенная проблема. А в сфере IT терминология сложна и очень важна. Потому лично я посвящаю правильной терминологии множество публикаций.

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

Ну, а если в процессе согласований не возникло каких-то сложностей, и вы получили результат, который помогает решать поставленные задачи, скорей всего, вы просто ошибочно использовали термины. И когда говорили “CRM” на самом деле имели в виду ERP или наоборот.

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

Графическое описание процесса

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

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

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

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

• Сравнение нотаций IDEF3, IDEF0, BPMN и DFD
• Как описать бизнес-процесс в формате нотации BPMN и других.

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

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

Еще один пример – Запись клиента на услуги. Здесь также нужно описать последовательность действий, начиная с момента обращения клиента до момента непосредственно записи на услугу.

Текстовое описание

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

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

Например, в графической модели мы указали «Создать заявку». В самой диаграмме этого достаточно. Но в текстовом описании мы указываем, что необходимо для создания заявки. Это может быть перечень полей (Клиент, Сумма заявки, Комментарий и пр.).

Аналогично при создании Сделки на основе заявки, в тексте описываются поля «Сумма сделки», «Перечень товаров», «Клиент», «Этап» и т.д.

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

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

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

План

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

Например, у нас в процессе должен создаваться звонок и подключаться автоматически запись разговора. Значит, нам нужно:

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

Еще один распространенный пример – на данный момент сайт заполняется вручную. Необходимо настроить автоматическую выгрузку на сайт. В плане мы так и ставим задачу: «Автоматическая выгрузка данных на сайт. Разработка скриптов переноса данных из учетной системы на сайт информации».

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

Я лично так понимаю:

• Программист – это тот человек, который будет писать программный код.
• Консультант – человек, который будет контролировать работу программиста.
• Старший консультант – это человек, который будет осуществлять общее руководство проектом.

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

Требования к плану:

1. В плане должны быть отражены все задачи, которые нужно выполнить, чтобы получить из того, что есть, то, что должно быть.
2. В плане должны указываться четкие сроки выполнения задач, и кто исполнитель.

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

Счет и/или калькуляция

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

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

Источник: temofeev.ru

Пример 2. Пример ТЗ для создания АИС. Техническое задание на создание автоматизированной системы (пример)

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 63.41 Kb.

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

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

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

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

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

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

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

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

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

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

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

Заказчик: ОАО Заказчик

Адрес фактический: г. Москва .

Телефон / Факс: +7 (495) 2222222

Разработчик: ЗАО Разработчик

Адрес фактический: г. Москва .

Телефон / Факс: +7 (495) 3333333

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

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

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

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

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

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

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

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

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

Указать вид автоматизируемой деятельности (указать для управления какими процессами предназначена система).

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

КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика.

Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика.

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

1. анализ финансово-хозяйственной деятельности;

2. информационная поддержка процессов бюджетирования;

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

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

КХД создается с целью:

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

— создания единой системы отчетности по показателям деятельности;

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

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

— время сбора и первичной обработки исходной информации;

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

— время, затрачиваемое на информационно-аналитическую деятельность;

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

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

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

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

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

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

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

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

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

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

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

— подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений;

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

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

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

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

Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

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

Смежными системами для КХД являются:

— информационные системы оперативной обработки данных Заказчика;

— информационные системы планирования;

Источниками данных для Системы должны быть:

— Информационная система управления предприятием (СУБД MS SQL).

— Информационно-справочная система (СУБД MS SQL).

— Информационная система обеспечения бюджетного процесса (СУБД Oracle).

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

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

— Информационно-справочная система — обмен файлами ОС определенного формата.

— Информационная система обеспечения бюджетного процесса — интеграция «точка – точка».

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

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

— Основной режим, в котором подсистемы КХД выполняют все свои основные функции.

— Профилактический режим, в котором одна или все подсистемы КХД не выполняют своих функций.

В основном режиме функционирования Система КХД должна обеспечивать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Администратор подсистемы хранения данных — 2 человека.

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

— Руководитель эксплуатирующего подразделения — на всем протяжении функционирования КХД обеспечивает общее руководство группой сопровождения, .

— Администратор подсистемы сбора, обработки и загрузки данных — на всем протяжении функционирования КХД обеспечивает контроль процессов ETL, подготовку и загрузка данных из внешних источников в хранилище данных, .

— Администратор подсистемы хранения данных — на всем протяжении функционирования КХД обеспечивает распределение дискового пространства, модификацию структур БД, оптимизацию производительности, .

— Администратор подсистемы формирования и визуализации отчетности — на всем протяжении функционирования КХД обеспечивает поддержку пользователей, формирование отчетности, .

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

К квалификации персонала, эксплуатирующего Систему КХД, предъявляются следующие требования.

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

— Администратор подсистемы хранения данных — глубокие знания СУБД; знание архитектуры «Звезда» и «Снежинка»; опыт администрирования СУБД; знание и навыки операций архивирования и восстановления данных; знание и навыки оптимизации работы СУБД.

— Администратор подсистемы формирования и визуализации отчетности — понимание принципов многомерного анализа; знание методологии проектирования хранилищ данных; знание и навыки администрирования приложения; знание языка запросов SQL; знание инструментов разработки.

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

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

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

— Администратор подсистемы сбора, обработки и загрузки данных – двухсменный график, поочередно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— своевременного выполнения процессов администрирования Системы КХД;

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

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

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

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

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

— при выходе из строя АПК ХД — не более Z часов.

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

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

— коэффициент готовности W — определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;

— время наработки на отказ E часов — определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки.

Средняя наработка на отказ АПК не должна быть меньше G часов.

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

Источник: topuch.com