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

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

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

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

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

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

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

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

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

As is/To be

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

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

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

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

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

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

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

 

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

?\_(?)_/?

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

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

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

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

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

 

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

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

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

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

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

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

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

Удачных проектов!

Сергей Куканов

ingraf.su