Что такое назначение системы

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

2. Назначение и цели создания системы 2.1. Назначение системы Указать вид автоматизируемой деятельности (указать для управления какими процессами предназначена система). Указать перечень объектов автоматизации, на которых предполагается использовать систему, перечень автоматизируемых органов (пунктов) управления объекта автоматизации и управляемых ими объектов (здесь указать в каких подразделениях предусматривается устанавливать систему и привести в разрезе подразделений перечень автоматизируемых бизнес-процессов верхнего уровня). КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика. Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика. В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах: 1. анализ финансово-хозяйственной деятельности; 2. информационная поддержка процессов бюджетирования; 3. .

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

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

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

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

3. Характеристика объектов автоматизации Приводятся краткие сведения об области деятельности Заказчика (или подразделения организационной структуры Заказчика, для нужд которого разрабатывается система) и сферы автоматизации с указанием ссылок на ранее разработанные документы, содержащие более подробные сведения об организации заказчика. <Приводится описание организационной структуры>Как правило, объектом автоматизации являются бизнес-процессы, выполняемые в структурных подразделениях Заказчика. Следовательно, применительно к данному ТЗ, объектами автоматизации будут являться бизнеспроцессы, выполняемые в . Выделены следующие процессы в деятельности , в рамках которых производится анализ информации и вынесены соответствующие выводы о возможности их автоматизации:

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

4. Требования к системе 4.1. Требования к системе в целом 4.1.1. Требования к структуре и функционированию системы Определяется перечень функциональных подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы. Система КХД должна быть централизованной, т.е. все данные должны располагаться в центральном хранилище. Система КХД должна иметь трехуровневую архитектуру (можно привести общую схему, на которой определить уровни. Например, первый — источник, второй — хранилище, третий — отчетность). В Системе предлагается выделить следующие функциональные подсистемы: — подсистема сбора, обработки и загрузки данных , которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных; — подсистема хранения данных , которая предназначена для хранения данных в структурах, нацеленных на принятие решений; — подсистема формирования и визуализации отчетности , которая предназначена для формирования бизнес-ориентированных витрин данных и отчетности.

Назначение и цели создания (развития) системы

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

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

Техническая документация

разработка техдокументации по ГОСТ без бумаги и расстояний

(2) Назначение и цели создания (развития) системы

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

Создан 01.03.2014 10:40:02

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

Начнем, как всегда, с нормативных документов и терминологии. Итак, что имеется по составу раздела в соответствующем стандарте на продукцию — ГОСТ 34.602-89? услуги КВЭД

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

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов [из 2.4.1 ГОСТ 34.602-89]

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

2.1.1 Вид автоматизируемой деятельности

Пусть видом автоматизированной деятельности будет управление или услуги КВЭД>. Управление — это Совокупность целенаправленных действий, включающая оценку ситуации и состояния объекта управления, выбор управляющих воздействий и их реализацию [из 10 прил. 1 ГОСТ 34.003-90].

Из толкового словаря

НАЗНАЧЕНИЕ, назначения, ср. (книжн.).

1. Действие по гл. назначить-назначать. Назначение лекарства. Назначение на должность.
2. Постановление о зачислении на службу, направление на определенную доджность. Получить назначение на окраину. «Я приближался к месту моего назначения.» Пушкин.
3. Целесообразное применение, предполагаемая роль или действие кого-чего-нибудь. Назначение маятника — регулировать ход часов. Не отвечать своему назначению. Отряд особого назначения. Факультет особого назначения. Использовать что-нибудь по прямому назначению. Не по назначению.
4. Цель, задача, миссия (книжн. ритор.). «Не забывай высокого, святого назначения.» Пушкин.

Д.Н. Ушаков. 1935-1940.

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

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

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

Примечание от 20.05.2015 г. — Часто подобрать подходящий вид автоматизированной деятельности можно из ОКВЭД. Если, к примеру, речь идет об автоматизации розничной сети аптек, то формулировка может быть такова: «Основной вид деятельности, для автоматизации которого предназначена Издели?, — согласно коду ОКВЭД 52.31 Розничная торговля фармацевтическими товарами».

2.1.2 Перечень объектов автоматизации

К сожалению, ГОСТ 34.003-90 не раскрывает понятия объекта автоматизации, но для подготовки содержимого данного раздела достаточно будет и приведенных ниже схожих по смыслу определений. Итак:

• объект деятельности — Объект (процесс), состояние которого определяется поступающими на него воздействиямичеловека (коллектива) и, возможно, внешней среды [из 7 прил. 1 ГОСТ 34.003-90];
• объект информатизации — Совокупность информационных ресурсов, средств и систем обработки информации, используемых в соответствии с заданной информационной технологией, средств обеспеченияобъекта информатизации, помещений или объектов (зданий, сооружений, технических средств), в которых они установлены, или помещения и объекты, предназначенные для ведения конфиденциальных переговоров [из 2.1(4) ГОСТ Р 51275-99];
• технологический объект управления — Объектуправления, включающий технологическое оборудование и реализуемый в нем технологический процесс [из 7.1 ГОСТ 34.003-90];
• технический объект — Любое изделие (элемент, устройство, подсистема, функциональная единица или система), которое можно рассматривать в отдельности. Примечание — Объект может состоять из технических средств, программных средств или их сочетания и может в частных случаях включать людей, его эксплуатирующих, обслуживающих и (или) ремонтирующих. Определениетермина «технический объект (объект)» изложено с учетом определения этого термина, приведенного в МЭК 50(191) [из 3.12 ГОСТ 27.310-95];
• информационный объект — Идентифицированная (именованная) совокупность данных в информационной системе, обладающая набором атрибутов (характеристик) и предполагающая определенный методобработки [из 3.1.4 ГОСТ 2.053-2013];
• объект измерения — Тело (физическая система, процесс, явление и т.д.), которое характеризуется одной или несколькими измеряемыми физическими величинами. Пример — Коленчатый вал, у которого измеряют диаметр, технологический процесс, во время которого измеряют температуру, спутник Земли, координаты которого измеряются. Это все объекты измерения [из 5.19 РМГ 29-99];
• и множество иных объектов, определения которых можно найти здесь. Автоматизировать можно все.

Пример перечня объектов автоматизации изображен на рисунке.

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

В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы [из 2.4.2 ГОСТ 34.602-89]

Цели создания системы — вопрос тонкий. Среди стандартизованных определений найдена лишь цель деятельности — Желаемый результат процесса деятельности [из 5 прил. 1 ГОСТ 34.003-90]. Это еще как-то похоже на цель создания, поскольку результат может быть представлен положительной динамикой: повышением (эффективности), снижением (затрат) и т.д.

Примечание от 24.09.2014 г. — Еще одна цель — Планируемый результат (выход системы) [ИСО 9241-11:1998, 3.8] [из 3.5 ГОСТ Р ИСО 9241-110-2009], но это очередная ИСО’шная глупость, поскольку целью создания системы не может являться собственно создание системы.

И еще из ГОСТ 24.202-80: Раздел «Цели, критерии и ограничения создания АСУ» должен содержать:

• формулировку производственно-хозяйственных (3.1), научно-технических (3.2) и экономических целей и критериев создания АСУ (3.3);
• характеристикуограничений по созданию АСУ (3.4).

Примечание — Цели и критерии создания АСУ должны быть заданы в виде изменения значений соответствующих показателей [из 2.4 ГОСТ 24.202-80]. Подчеркиваем: ЦЕЛЬ — это именно ИЗМЕНЕНИЯ, т.е. ДИНАМИКА (причем только положительная. Ухудшения никому не нужны, только улучшения).

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

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

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

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

Термин «гармонизация» применяется все больше к стандартам, см. гармонизированные стандарты. Смысл гармонизации в целом состоит во взаимопонимании, соответствии, эквивалентности. И в достижении консенсуса при плюрализме мнений. В данном конкретном случае под гармонизацией понимаем соответствие решаемых задач поставленным целям. Для простоты приведем известный всем пример из программы КПСС (не дословно, конечно): цель — повышение благосостояния всего советского народа. Одна из решаемых задач для достижения указанной цели — к 2000 году обеспечить каждую советскую семью отдельной квартирой. Стоит обратить внимание, что назначение (перечень задач) и цель гармонизируются, «бьются» на все сто процентов, как бухгалтерский баланс — до копеечки.

Напоследок о критериях оценки достижения целей создания системы.

2.2.2 Критерии оценки достижения целей создания системы

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

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

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

Проектирование и внедрение ИТ систем

В ИТ с конца 90-х прошлого века. Сейчас занимаюсь внедрением систем в одном очень-очень большом федеральном заказчике -) Этот блог создан для записи моих идей, случаев из моей практики проектирования и внедрения ИТ систем, в первую очередь по ITSM. Систем мониторинга и управления ИТ, инфраструктурных проектов и, конечно же, об управлении командой, проектом, заказчиком.

Ярлыки

понедельник, 13 июня 2011 г.

Пишем ТЗ: Что такое Назначение Системы, Цели и Задачи

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

Очень часто когда обычных ИТ-шников просят написать VISION на систему на них сходит ступор. С чего начать? Особенно если вас просят начать с ТЗ по ГОСТ34 -). А оно начинается с Назначение, Цели и Задачи. А есть еще Показатели назначения, о которых рекомендуется не писать вообще. По первой я то же не сразу приобрел легкость бытия, но регулярно встречаю различные перлы на эту тему. Приступим:

Назначение системы — для чего она предназначена (самое простое).
Здесь выдумывать ничего не надо и просто можно указать:

1. какой процесс она автоматизирует (это для систем пользовательских, в которых есть пользователи, например SAP, Почта,1С и тп) «Назначением системы А является автоматизация процесса В (учета использованных карандашей)»
2. что в системе создается(это для инфраструктурных систем, которые работают без пользователей, например MPLS сеть, ферма VMWare и тп.) «Назначением системы является создание MPLS сети уровня предприятия А».

1. Назначений системы не стоит делать несколько;
2. Не стоит писать, что назначением является обеспечение чего либо — чаще всего это цели создания;
3. Систем которые создаются ради «создания» крайне мало, используйте это назначение аккуратно. Классический для меня пример: 1. Создание системы резервного копирования — автоматизация процессов рез копирования; 2. Создание хранилища данных — автоматизация процессов хранения и обработки данных

Цели создания — зачем собственно мы это делаем.

Часто именно здесь можно как совершить непростительные ошибки, так произвести вери гуд впечатление на ЛПР (лицо принимающее решение).

В первую очередь — что не является целями создания. Целью создания не является собственно само СОЗДАНИЕ. Писать, что целью создания системы является ее создание/развитие\модернизация, оставим Портосу, который сказал — «Я дерусь, потому что я дерусь».
Включить в голове правильное направление мыслей, может помочь ответ на вопрос — «Вот мы создали Систему, а толку?»

Вот несколько самых типовых целей:

• соответствие требованиям регуляторов (например — Закону о персональных данных)
• обеспечение возросших потребностей компании А в пропускной способности сети связи (например для замены 10BaseT на 1000BaseT)
• обеспечение возможности развертывания в компании В централизованной ERP системы (модернизация сетей передачи данных)
• обеспечение подразделений А-В-С современными средствами соответствующим общемировым практикам ITIL\ITSM (например при внедрении Сервисдеска)
• организация централизованного учета материальных средств и работ по их обслуживанию и сопровождению
• техническое обеспечение бизнес услуги «По-секундная тарификация»
• снижение трудоемкости подготовки какой-то там отчетности
• повышение доступности ИТ за счет снижения времени обнаружения неисправностей (для систем мониторинга)
• ну и в таком стиле.

• в первую очередь — не пишите в целях то, достижение чего система не в состоянии обеспечить. В первую очередь это ПОВЫШЕНИЕ или ПОНИЖЕНИЕ чего-либо: стоимости владения, доходности, снижение затрат на обслуживание. и тому подобное. Писать достижение экономического эффекта в качестве целей системы — не надо.
• далее — выкиньте весь маркетинг шит, если только вы не пишете бизнес проспект
• если вы пишете в целях улучшение какой-то многофакторной переменной, то используйте фразу «за счет снижения\улучшения такого-то фактора»
• не надо писать много целей, чаще всего достаточно 1-3
• и запомните — цели должны быть достижимыми и измеряемыми. Если вы хотите что-то улучшить запаситесь началом отсчета. Например, замерьте сколько в среднем занимала операция по подготовке квартального отчета, и сколько она стала занимать после внедрения datawarehouse на 1 млн уе. А ведь она может не изменится -) Так что лучше не пишите в ТЗ в целях всякий маркетинг шит

Фактически здесь мы указываем артефакты проекта. То что получит заказчик.
Например типовые задачи автоматизации бизнес процесса типовой компании

1. Развертывание системы автоматизации кастомизированной под требования бизнес процесса в составе следующих компонентов:

• центральный портал
• модуль Кадры,
• модуль Зарплата,
• модуль .

1. Разработка регламента бизнес-процессов Кадры, Зарплата . (это если вы еще и бизнес процесс внедряете)
2. Разработка пакета отчетности в соответствии с требованиями
3. Обучение персонала
4. Развертывание системы безопасности на фаирволах и системах обнаружения вторжений
5. далее я думаю понятно.

На этом пока все — в следующем посте серии я планирую описать что такое Показатели назначения (это из ТЗ) и что такое Описание объекта автоматизации (это фактически SCOPE системы).