Функциональный разрыв 1с что это
Перейти к содержимому

Функциональный разрыв 1с что это

  • автор:

Использование директив компиляции и инструкций препроцессора

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

1. Директивы компиляции:

&НаКлиенте (&AtClient)
&НаСервере (&AtServer)
&НаСервереБезКонтекста (&AtServerNoContext)

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

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

2. Не следует использовать инструкции препроцессора в клиент-серверных общих модулях для проверки клиентского и серверного контекстов (#Если Сервер, #Если Клиент) ввиду невозможности надежного определения контекста исполнения. Процедуры и функции, которые работают по-разному при вызове с клиента и с сервера, следует размещать в общих модулях с постфиксами Клиент и Сервер , а не КлиентСервер .

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

Функция КодОсновногоЯзыка() Экспорт
#Если НЕ ТонкийКлиент И НЕ ВебКлиент Тогда
Возврат Метаданные.ОсновнойЯзык.КодЯзыка;
#Иначе
Возврат СтандартныеПодсистемыКлиент.ПараметрКлиента(«КодОсновногоЯзыка»);
#КонецЕсли
КонецФункции

Функция КодОсновногоЯзыка() Экспорт
#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
Возврат Метаданные.ОсновнойЯзык.КодЯзыка;
#Иначе
Возврат СтандартныеПодсистемыКлиент.ПараметрКлиента(«КодОсновногоЯзыка»);
#КонецЕсли
КонецФункции

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

В то же время, как и в обычных клиентских модулях, допустимо ветвление кода для учета специфики различных режимов работы клиентского приложения: веб-клиент, тонкий или толстый клиент (например, #Если ВебКлиент).

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

Процедура Пример1()
а = 1
#Область ИмяОбласти
+ 2;
#КонецОбласти // разрыв выражения
КонецПроцедуры

#Область ИмяОбласти
Процедура Пример2()
// .
#КонецОбласти // разрыв процедуры
КонецПроцедуры

Если <. >Тогда
// .
#Если ВебКлиент Тогда // разрыв блока Если
Иначе
// .
#КонецЕсли
КонецЕсли;

Результат = Пример4(Параметр1,
#Если Клиент Тогда
Параметр2, // некорректный вызов функции
#КонецЕсли
Параметр3);

Данные ошибки диагностируются автоматически с помощью среды разработки 1C:Enterprise Development Tools (EDT).

Правильно использовать инструкции препроцессора без разрыва конструкций.

Функциональная опция

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

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

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

Функциональная опция

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

Функциональная опция

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

Функциональная опция

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

Функциональная опция

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

Назначение функционального моделирования

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

Жуковский О парении птиц стр. 26

Выдержка из публикации профессора Н.Е. Жуковского «О парении птиц». 1891 г.

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

На выходе функциональное моделирование (ФМ) даёт приблизительный результат (точный даст — опытная эксплуатация):

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

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

Предлагаю оглавление по документу ФМ:

  • Описание бизнес-процессов предприятия (As is/To be).
  • Выбор решений программного и аппаратного обеспечений.
  • Насколько соответствует типовое решение техническим требованиям и бизнесу?
  • Какая допустимая нагрузка на систему / подсистемы?
  • Какие условия информационной безопасности?
  • Обзор текущей инфраструктуры.
  • Какие функциональные разрывы между системой и бизнес-процессами и способы их устранения?

As is/To be

Модель «To be» описывается всегда.

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

Типовое решение и функциональные разрывы

Вернёмся к математике, к формуле нормального распределения, график которого имеет следующий вид:

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

В ФМ требуется определить попадание бизнес-процессов в функциональность системы. Если количество редких бизнес-процессов велико, то требуется выбирать иное программное обеспечение (комплекс программ) или значительно дорабатывать существующее. Требуется компетенция аналитика, то есть знание продукта и отсутствие неловкости в вопросах «почему? и «зачем?».

Ниже представлен слайд отчёта фирмы 1С по программному продукту 1С ERP, который резюмирует, что «89% функционала внедряется без доработок или с небольшими доработками».

Статистика доработок ERP

Возражения пользователей на тему «1С не делает самый необходимый важный функционал» остаются лишь эмоциями.

Нагрузочное тестирование

Фирма 1С разрабатывает и предоставляет внедренцам комплекс программ «1С:Корпоративный инструментальный пакет 8» для повышения успеха проектов, в том числе на этапе функционального моделирования.

1С Кип 8

Основные задачи «1С:Корпоративного инструментального пакета 8»:

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

Это больше чем необходимо на ФМ, но крайне важно на средних и крупных проектах (внедрения по технологиям ТБР и ТКВ). Для внедрения ТСВ (Технология стандартного внедрения) допускается не делать нагрузочное тестирование.

Документирование

Результатом функционального моделирования должен стать:

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

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

Список документов ФМ

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

  • Предполагаемое типовое/отраслевое решение;
  • MS Word для описания результатов;
  • MS Visio, Coral Draw для описания бизнес-процессов, блок-схем, граф-схем и т.п.;
  • MS Paint, Joxi, Screenshoter Mail для снимков экрана;
  • MS Project для планирования работ, затрат, трудозатрат;
  • MS Excel для описания структуры отчётов, печатных форм.

Пример документа «Функциональное моделирование» упрощённой версии можно получить по email «doc@ingraf.su» с темой «Лайт».

Разрыв в бизнес-процессе

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

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

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

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

Смотри также:

  • Бизнес-процесс
  • Вход процесса
  • Выход процесса
  • Узкие места процесса
  • Пользовательское соглашение
  • Политика конфиденциальности
  • Карта сайта
  • Файлы Cookie

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *