Лекции

Тема 9: Анализ и моделирование функциональной области внедрения ИС. Часть 1
Ключевая проблема (сквозной вопрос на занятие):
«Можно ли успешно внедрить 1С, не разобравшись в том, как устроен и работает бизнес заказчика?
Почему попытки "настроить систему под отдел" часто проваливаются, а успешные проекты всегда
начинаются с вопросов о миссии, целях и организационной структуре компании?»
Цель занятия: Сформировать понимание организационного бизнес-моделирования как
фундаментального этапа проектирования ИС. Научить студентов выделять и анализировать
ключевые элементы бизнес-архитектуры: миссию, цели, стратегии и статическую структуру
компании.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «Компания "Быстрый заказ" (доставка
готовой еды) обратилась к интеграторам. Задача: "Ускорить работу курьеров и улучшить
отчетность". Одна команда сразу начала обсуждать технические требования к мобильному
приложению курьера и новые отчеты в 1С. Другая команда сначала задала вопросы: "В чем
ваша главная ценность для клиента? Вы боретесь за скорость или за качество/ассортимент?
Как устроена логистика: темные кухни или рестораны-партнеры? Кто принимает ключевые
решения по зонам доставки?" Вопрос: Какая команда с большей вероятностью создаст
успешное ИТ-решение и почему? Что дает второй команде их линия вопросов?»

Деятельность студентов: Работают парами. Приходят к выводу, что вторая команда ищет
коренные причины и контекст, а первая — просто технически оформляет симптом.

Выход на тему: Преподаватель резюмирует: «Чтобы автоматизировать бизнес, нужно сначала
понять его. Это понимание начинается не с процессов, а с основ: зачем компания существует
(миссия), куда и как движется (цели и стратегии) и как устроена (статическая структура). Это
и есть организационное бизнес-моделирование — первый и важнейший шаг проектировщика
ИС».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (определения, примеры,
шаблоны, фрагменты учебников по стратегическому менеджменту).
o
Группа 1: «Зачем мы здесь? Миссия и видение как отправная точка»

Задача: Изучить понятия миссии и видения компании и их роль в
проектировании ИС.

Материалы: Определения миссии и видения, примеры миссий известных
компаний (IKEA, Tesla, Сбер), связь миссии с корпоративной культурой и
ценностями.

Вопросы для анализа:
1. Дайте определение миссии компании. Чем она отличается от видения?
Приведите примеры.
2. Как понимание миссии заказчика может повлиять на приоритеты и
архитектурные решения при проектировании ИС? (Например, миссия,
ориентированная на инновации vs миссия, ориентированная на
надежность).
3. Сформулируйте гипотетическую миссию для сети кофеен "Бодрость".
Какие ключевые слова в ней зададут вектор для автоматизации?
o
Группа 2: «Куда мы идем? Дерево целей и стратегии»

Задача: Изучить метод дерева целей и понятие стратегии как способа
декомпозиции миссии.

Материалы: Концепция дерева целей (goal tree), методология SMART, примеры
стратегий (лидерство по издержкам, дифференциация). Связь с BSC
(Сбалансированной системой показателей).

Вопросы для анализа:
1. Что такое "дерево целей"? Почему цели должны быть иерархичны и
соответствовать критерию SMART?
2. Как стратегия компании (например, "удержание клиентов за счет
сервиса" vs "захват рынка за счет низкой цены") влияет на
выбор приоритетных модулей для автоматизации (CRM vs система
контроля затрат)?
3. Постройте фрагмент дерева целей для цели "Повысить лояльность
клиентов" в розничном магазине. Как минимум на два уровня вглубь.
o
Группа 3: «Как мы устроены? Статическое описание компании»

Задача: Изучить элементы статического описания бизнеса.

Материалы: Описание организационной структуры (типы: линейная,
функциональная, дивизиональная), модели окружения (заинтересованные
стороны, стейкхолдеры), модель ресурсов (материальные, нематериальные).

Вопросы для анализа:
1. Что входит в статическое описание компании? Перечислите 3-4
ключевых элемента.
2. Почему проектировщику ИС критически важно
понимать организационную структуру и степень централизации
управления в компании? Как это влияет на настройку прав доступа в 1С и
маршруты согласования?
3. Кто такие ключевые стейкхолдеры (stakeholders) проекта внедрения ИС?
Почему их нужно выявлять на самом раннем этапе?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется схема: Миссия → Стратегия и Дерево
целей → Статическая структура (Оргструктура, Ресурсы, Стейкхолдеры).

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Организационное бизнес-моделирование — это процесс создания формализованного
описания компании как системы на макроуровне. Это контекст, в который будет
встраиваема ИС. Без него проектирование ИС слепо.
2. Миссия — это философская и социальная причина существования компании, ее
предназначение для общества и клиентов. Видение — это образ желаемого будущего.
Миссия задает "правила игры" и ценности, которые ИС должна поддерживать
(надежность, открытость, скорость).
3. Дерево целей — это иерархическая структура, декомпозирующая стратегические цели
на тактические и операционные. Стратегия — это генеральный путь достижения целей.
Анализ целей и стратегий позволяет проектировщику выделить критические факторы
успеха (КФУ) и понять, автоматизация каких бизнес-областей даст максимальный
стратегический эффект.
4. Статическое описание компании включает:

Организационную структуру: Схема подчинения, отделы, центры
ответственности. Определяет ролевую модель и потоки документов в будущей
ИС.

Модель окружения: Внешние и внутренние стейкхолдеры (клиенты,
поставщики, регуляторы, акционеры, сотрудники). Их интересы формируют
требования к системе.

Ресурсы: Материальные (оборудование, деньги) и нематериальные (бренд,
знания, патенты). ИС часто создается для управления ключевыми ресурсами.
5. Вывод по проблеме: Команда, задающая вопросы о миссии и стратегии,
строит архитектуру автоматизации, выровненную по бизнесу (Business-IT Alignment).
Она автоматизирует не "отчетность курьеров", а ключевой фактор успеха "скорость и
предсказуемость доставки", что напрямую вытекает из миссии и стратегии. Это
приводит к созданию ценности, а не просто к появлению нового программного
модуля.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу с "Быстрым заказом". Студентам предлагается сформулировать, как
ответы на вопросы второй команды повлияют на проект.

Примерный итог: «Узнав, что миссия — "дарить время и удовольствие", а стратегия —
"лидерство по скорости в пределах 15-минутных зон", команда спроектирует ИС, где главный
экран диспетчера — это карта с ETA курьеров в реальном времени, а алгоритмы оптимизации
маршрутов будут ядром системы. Автоматизация отчетности станет следствием, а не целью.
Понимание оргструктуры (например, есть ли региональные менеджеры) определит модель
прав доступа к данным».

Анонс следующей темы: «Мы описали компанию "в статике". Теперь посмотрим, как она
работает "в динамике" — изучим бизнес-процессы и их моделирование».
Конспект лекции 9. Анализ и моделирование функциональной области внедрения ИС. Часть 1
Введение (Проблематизация)
Представьте, что вас попросили спроектировать систему управления для незнакомого механизма. Вы
начнете ковырять винтики? Нет, вы сначала изучите его чертеж, поймете назначение и принцип
работы. Бизнес — это сложнейший механизм. Организационное бизнес-моделирование — это
создание "чертежа" бизнеса, без которого проектирование ИС превращается в хаотичное
кодирование "винтиков" без понимания целого.
1. Организационное бизнес-моделирование
Это первый и фундаментальный этап анализа при внедрении ИС, целью которого является создание
целостного, формализованного представления о компании-заказчике как о системе. Модель
отвечает на вопросы: КТО? (структура), ЗАЧЕМ? (миссия), КУДА? (цели и стратегии), ЧТО ИМЕЕМ?
(ресурсы).
Зачем это нужно проектировщику ИС?

Чтобы понять язык и проблемы бизнеса, говорить с заказчиком на одном языке.

Чтобы выявить истинные, а не симптоматичные потребности в автоматизации.

Чтобы обеспечить выравнивание ИТ с бизнес-стратегией (Business-IT Alignment), гарантируя,
что ИС создает реальную бизнес-ценность.

Чтобы идентифицировать всех ключевых стейкхолдеров и учесть их интересы.
2. Миссия компании, дерево целей и стратегии их достижения


Миссия компании — это краткое, ясное утверждение, выражающее основную цель
организации, причину ее существования. Она описывает, что компания делает, для кого и в
чем ее уникальность/ценность.
o
Пример: Миссия IKEA: «Создать лучшую повседневную жизнь для многих людей».
o
Влияние на ИС: Миссия, сфокусированная на инновациях, потребует ИС с высокой
гибкостью и быстрым циклом внедрения изменений. Миссия, сфокусированная на
качестве и безопасности (например, в фармацевтике), потребует ИС со строгим
аудитом и соответствием стандартам.
Видение — это образ компании в будущем, то, кем она хочет стать. Это ориентир для
стратегического планирования.


Дерево целей — это структурированный, иерархический набор целей, в котором цели
верхнего уровня (стратегические) последовательно детализируются в цели нижних уровней
(тактические и операционные).
o
Принцип SMART: Цели должны быть Конкретными, Измеримыми, Достижимыми,
Релевантными, Ограниченными по времени.
o
Пример: Стратегическая цель: «Увеличить долю рынка до 15% за 3 года». Тактическая:
«Запустить программу лояльности к концу года». Операционная: «Разработать
механизм начисления бонусов в 1С к Q3».
o
Влияние на ИС: Дерево целей — источник требований к функциональности и
отчетности. Система должна предоставлять метрики для измерения достижения
целей.
Стратегия — это общий, комплексный план достижения миссии и целей. Это выбор способа
конкуренции (например, по издержкам, по дифференциации).
o
Влияние на ИС: Стратегия определяет приоритеты автоматизации. Если стратегия —
«клиентоориентированность», то в первую очередь автоматизируется CRM и сервис.
Если «оптимизация издержек» — то управление закупками и логистика.
3. Статическое описание компании
Это "фотография" организации в определенный момент времени, описывающая ее устойчивые
элементы.
1. Организационная структура:
o
Графическое или текстовое описание состава, соподчиненности и взаимосвязи
подразделений и должностей.
o
Типы: Линейная, функциональная, дивизиональная, матричная, сетевая.
o
Важность для ИС: Прямо определяет ролевую модель, матрицу прав доступа,
иерархию справочников (например, "Подразделения"), маршруты согласования
документов в системах workflow.
2. Модель окружения (стейкхолдеры):
o
Стейкхолдеры (заинтересованные стороны) — это лица или группы, которые влияют
на деятельность компании или находятся под ее влиянием.
o
Внутренние: Собственники, топ-менеджмент, сотрудники.
o
Внешние: Клиенты, поставщики, конкуренты, государство (налоговая,
Роспотребнадзор).
o
Важность для ИС: Требования к системе — это, по сути, формализованные интересы
стейкхолдеров. Клиент хочет удобный личный кабинет, налоговая —
регламентированные отчеты. Их раннее выявление и анализ — залог успеха проекта.
3. Ресурсная модель:
o
Описание ключевых активов компании: финансовые, материальные (оборудование,
товары), человеческие, информационные, нематериальные (бренд, патенты).
o
Важность для ИС: ИС часто является инструментом учета, контроля и управления
ключевыми ресурсами. Понимание, что является главным ресурсом (например,
интеллектуальная собственность или уникальное оборудование), определяет фокус
проектирования.
Заключение
Организационное бизнес-моделирование — это инвестиция в понимание. Пропуск этого этапа ради
"скорейшего начала программирования" — главная причина создания ИС, которые не решают
бизнес-задач, не окупаются и вызывают разочарование. Для проектировщика ИС навыки бизнесанализа и моделирования на макроуровне становятся не менее важными, чем знание технологий.
Они превращают его из технического исполнителя в стратегического партнера бизнеса.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 9
1. Проблемный вопрос: Внедренческая компания приступает к проекту автоматизации
производства на заводе. Заказчик представляет собой холдинг с централизованным
финансами и децентрализованными, самостоятельными производствами в регионах. Почему,
прежде чем обсуждать модули 1С:ERP, проектировщики должны уделить особое внимание
анализу организационной структуры и дерева стратегических целей холдинга? К каким
конкретным проектных решениям в ИС может привести этот анализ?
2. Сформулируйте миссию для онлайн-школы программирования. Исходя из этой миссии,
предложите одну стратегическую цель и одну тактическую задачу, которую должна
поддерживать информационная система школы.
3. Кто такие внутренние и внешние стейкхолдеры проекта внедрения новой системы
электронного документооборота (СЭД) в крупной компании? Для каждой группы приведите
по два примера и укажите, какой их ключевой интерес (требование) должен учесть
проектировщик СЭД.
4. Объясните, как тип организационной
структуры (например, функциональная vs дивизиональная) может повлиять на подход к
проектированию системы бюджетирования и управленческой отчетности в 1С.
5. Что такое «выравнивание ИТ с бизнес-стратегией» (Business-IT Alignment)? Приведите
пример невыравненного решения (когда ИС не соответствует стратегии)
и выравненного решения на примере розничного магазина со стратегией "удержание
клиентов через персональный сервис".
Домашнее задание для студентов:
1. Изучить конспект лекции 9.
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно) Выберите любую известную вам компанию (местную сеть, крупный бренд).
Проведите для нее мини-анализ:
o
Предположите и сформулируйте ее миссию (можно найти реальную или
сформулировать логически).
o
На основе миссии предложите 2-3 стратегические цели.
o
Сделайте предположение о ее организационной структуре (схематично) и
перечислите 3-4 ключевых стейкхолдера.
o
Сделайте вывод: на автоматизацию каких бизнес-аспектов должна быть направлена
ИС в первую очередь, исходя из этого анализа.
Тема 9 (Часть 2): Анализ и моделирование функциональной области внедрения ИС. Часть 2
Ключевая проблема (сквозной вопрос на занятие):
«Мы поняли, зачем компания существует и как устроена. Но как понять, ЧТО ИМЕННО нужно
автоматизировать? Как перейти от общих целей и оргструктуры к конкретным требованиям к
функциям и данным будущей ИС?»
Цель занятия: Сформировать понимание процессного и информационного моделирования как
ключевых инструментов анализа деятельности компании для выявления требований к ИС. Научить
студентов различать типы бизнес-моделей и их назначение.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «В компании "Быстрый заказ" (доставка еды)
из первой части выявили стратегическую цель: "Снизить время доставки с 40 до 25 минут в
95% заказов". IT-директор требует от аналитиков ответить: "Какие именно изменения в
системе 1С и мобильном приложении курьера нужно сделать для этого?" Вопрос: Как
аналитикам перейти от глобальной цели к списку конкретных IT-требований? Какие вопросы
нужно задать и что нужно описать?»

Деятельность студентов: Работают парами. Предлагают идеи: разобрать процесс доставки по
шагам, понять, где возникают задержки, какие данные нужны для планирования.

Выход на тему: Преподаватель резюмирует: «Чтобы ответить на этот вопрос, нужно перейти
от статического описания компании к динамическому — описать ее бизнеспроцессы и потоки данных. Только так мы поймем, что и как автоматизировать. Это и есть
содержание второй части моделирования».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (описания нотаций, примеры
моделей, схемы).
o
Группа 1: «Как всё течет? Динамическое описание и процессные модели»

Задача: Изучить понятие динамического описания компании и основы
процессного моделирования.

Материалы: Определение бизнес-процесса, нотация BPMN (основные
элементы: пул, дорожки, события, действия, шлюзы), пример простой
процессной диаграммы (например, "Оформление заказа").

Вопросы для анализа:
1. Что такое динамическое описание компании и чем оно дополняет
статическое?
2. Что такое бизнес-процесс? Назовите 3-4 ключевых характеристики
(например, имеет начало и конец, создает ценность для клиента).
3. Зачем проектировщику ИС нужны процессные модели? Какую
информацию он из них извлекает для проектирования?
o
Группа 2: «Данные в движении: Потоковые модели и модели структур данных»

Задача: Изучить моделирование потоков данных и структур хранения
информации.

Материалы: Концепция потоков данных (DFD — Data Flow Diagram), нотация ERдиаграмм (Сущность-Связь) для модели "сущность-связь", примеры.

Вопросы для анализа:
1. Чем модель потоков данных (DFD) отличается от процессной модели
(BPMN)? На что делает акцент каждая? (Подсказка: DFD — на данные,
BPMN — на порядок действий).
2. Что такое ER-диаграмма (модель "сущность-связь")? Что обозначают
прямоугольники, ромбы и линии?
3. Как связаны между собой процессная модель (BPMN) и модель данных
(ER)? Приведите пример: как действие "Оформить заказ" в BPMN
отражается в ER-модели?
o
Группа 3: «Полная картина: Построение целостной бизнес-модели»

Задача: Понять, как все виды моделей интегрируются в единую бизнес-модель
компании.

Материалы: Концепция полной бизнес-модели (например, на основе подхода
ARIS или Zachman Framework), принцип взаимосвязи моделей (цели -> процессы
-> данные -> функции).

Вопросы для анализа:
1. Что такое полная (комплексная) бизнес-модель компании? Какие
группы моделей (аспекты) она должна включать? (Организационная,
процессная, информационная, функциональная).
2. Как, по вашему мнению, связаны дерево целей из Части 1 и процессные
модели из Части 2?
3. Почему построение такой комплексной модели — это итеративный, а не
линейный процесс? (Сначала нарисовали процессы, потом поняли, что
нужны новые данные, потом уточнили оргструктуру и т.д.)
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется схема взаимосвязей: Цели -> Процессы
(BPMN) -> Потоки данных (DFD) -> Структуры данных (ER) -> Функции системы.

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Динамическое описание компании — это описание ее деятельности во
времени: бизнес-процессы, потоки информации, последовательности событий. Если
статика — это скелет, то динамика — это физиология.
2. Процессные потоковые модели (нотация BPMN):

Цель: Наглядно показать логическую последовательность действий,
участников, события и решения в рамках бизнес-процесса.

Для проектировщика ИС: Это источник требований к функциональности
(действия, которые надо автоматизировать), интерфейсам (переходы между
шагами), бизнес-правилам (шлюзы-условия), ролям (дорожки).

Пример: Процесс "Обработка заказа" от поступления на сайт до выдачи
курьеру.
3. Модели структур данных (ER-диаграммы):

Цель: Описать статические структуры для хранения информации (сущности, их
атрибуты и связи) без привязки к тому, как они используются.

Для проектировщика ИС: Это основа для проектирования базы данных,
справочников, документов, регистров в 1С. Это ответ на вопрос: "Какие данные
нужно хранить?"

Пример: Сущности "Клиент", "Заказ", "ПозицияЗаказа", "Товар" и связи между
ними.
4. Полная бизнес-модель компании — это согласованный набор всех перечисленных
моделей (миссия/цели, оргструктура, процессы, данные), дающий целостное
представление о компании. Подходы: ARIS (Architecture of Integrated Information
Systems), Zachman Framework.
5. Логика работы аналитика/проектировщика:

От целей выявляются критические процессы, которые на них влияют.

Процессы детализируются, выявляются действия, участники, события.

Для каждого действия определяется, какие данные на входе, обработке и
выходе (DFD помогает).

Все выявленные данные структурируются в ER-модель.

На основе процессной модели и ER-модели формулируются требования к
функциям ИС (что система должна делать) и информационные требования (с
какими данными работать).
6. Вывод по проблеме: Чтобы снизить время доставки, аналитики должны
смоделировать процесс "Исполнение заказа" (BPMN), выявить узкие места (ожидание
сборки, неоптимальный маршрут). Они анализируют потоки данных (когда и какая
информация о заказе, курьере, трафике поступает). На основе этого проектируют
изменения: в ER-модель добавляют сущность "Геозоны" и "Статус дорожной
ситуации", а в функции системы — "Автоматический подбор курьера с учетом геозоны
и пробок" и "Push-уведомление кухне о готовящемся заказе".
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу. Студентам предлагается кратко описать путь от цели до IT-требований.

Примерный итог: «Цель: снизить время доставки. Шаг 1: Моделируем процесс "Доставка" в
BPMN. Шаг 2: Находим шаги "Поиск курьера" и "Построение маршрута" как ключевые для
ускорения. Шаг 3: Анализируем DFD: какие данные нужны для этих шагов (локация курьеров,
заказов, карта пробок). Шаг 4: Дорабатываем ER-модель (добавляем данные о геолокации и
трафике). Итог — требования к ИС: 1) Интеграция с картографическим сервисом, 2) Алгоритм
оптимального назначения курьера, 3) Отслеживание позиций в реальном времени».

Анонс следующей темы: «Мы выявили требования. Теперь нужно их грамотно
задокументировать и перейти к проектированию архитектуры системы».
Конспект лекции 9 (Часть 2). Анализ и моделирование функциональной области внедрения ИС.
Часть 2
Введение (Проблематизация)
Мы знаем, куда плывет корабль (миссия и цели) и как он устроен (оргструктура). Но чтобы добраться
до цели, нужна карта течений и ветров — понимание того, как работа выполняется день за
днем. Процессное и информационное моделирование — это и есть создание такой "карты"
бизнеса, без которой автоматизация будет хаотичной и неэффективной.
4. Динамическое описание компании
Если статическое описание — это "фотография" компании, то динамическое — это "видео" ее
работы. Оно фокусируется на изменениях, последовательностях, преобразованиях. Ключевые
объекты динамического описания:

События (что происходит?).

Действия/Функции (что делается?).

Процессы (как действия связаны во времени?).

Потоки (что передается между действиями? — данные, документы, материалы).
Цель динамического описания — понять логику деятельности компании для выявления точек
улучшения и автоматизации.
5. Процессные потоковые модели
Это инструменты для графического описания бизнес-процессов.

Бизнес-процесс — это устойчивая, целенаправленная совокупность взаимосвязанных видов
деятельности, которая по определенной технологии преобразует входы в выходы,
представляющие ценность для потребителя.

Нотация BPMN 2.0 (Business Process Model and Notation) — современный стандарт для
моделирования процессов.
o
o
Основные элементы:

Событие (Event): Круг. Что-то происходит (старт, завершение, сообщение).

Действие/Задача (Activity): Скругленный прямоугольник. Конкретная работа.

Шлюз (Gateway): Ромб. Точка принятия решения (ветвление, слияние потоков).

Поток управления (Sequence Flow): Сплошная линия со стрелкой. Порядок
выполнения.

Пул и дорожки (Pool, Lane): Пул — границы процесса, дорожки — роли/отделы.
Зачем проектировщику ИС?
1. Выявление автоматизируемых действий (задач).
2. Определение ролей пользователей (дорожки) для системы безопасности.
3. Формализация бизнес-правил (шлюзы) для алгоритмов.
4. Понимание интерфейсов системы с внешним миром (события-сообщения).
6. Модели структур данных
Показывают, какая информация требуется для выполнения процессов и как она организована.

Диаграммы потоков данных (DFD — Data Flow Diagram): Показывают, какие
процессы преобразуют данные, какие данные хранятся, и куда они перемещаются. Акцент
на функциях обработки и потоках. Уровни: контекстная диаграмма, диаграммы уровней 0, 1,
2.

ER-диаграммы (Entity-Relationship — "Сущность-Связь"): Показывают статические структуры
хранения данных.
o
Сущность (Entity): Прямоугольник. Реальный или абстрактный объект (Клиент, Заказ,
Товар).
o
Атрибут (Attribute): Овал/список внутри сущности. Свойство сущности (ФИО клиента,
Дата заказа).
o
Связь (Relationship): Ромб или линия. Отношение между сущностями (Клиент
"оформляет" Заказ).
o

Мощность связи (Cardinality): Обозначает количество (1:1, 1:N, M:N).
Зачем проектировщику ИС? ER-модель является прямым прототипом для
проектирования базы данных, справочников, документов и регистров в 1С. DFD помогает
понять, какие данные и когда создаются, изменяются и используются.
7. Полная бизнес-модель компании
Это интегрированный набор всех перечисленных моделей, обеспечивающий согласованное
представление о компании с разных точек зрения. Примеры методологий:

ARIS (Architecture of Integrated Information Systems): Предлагает множество видов моделей
(V-модель), объединенных в единый репозиторий: организационные диаграммы, eEPCпроцессы (расширенные цепочки процессов), ER-диаграммы, диаграммы функций.

Принцип взаимосвязи: Изменение в одной модели (например, добавление нового продукта в
продуктовую линейку — статическая модель) должно повлечь пересмотр процессов его
продажи и производства, а также структуры данных для его учета.
Зачем это нужно для проектирования ИС?
Полная бизнес-модель является единственным достоверным источником требований к
информационной системе. Она позволяет:
1. Проследить каждое требование от стратегической цели до конкретного поля в форме ввода.
2. Обеспечить полноту — ничего не упустить.
3. Обеспечить непротиворечивость — чтобы данные, созданные в одном процессе, корректно
использовались в другом.
4. Обосновать проектные решения перед заказчиком.
Заключение
Моделирование функциональной области — это не "бумажная работа", которую можно пропустить.
Это интеллектуальная инвестиция, которая снижает риски проекта на порядки. Проектировщик,
умеющий строить и анализировать процессные и информационные модели, перестает быть просто
"настройщиком 1С" и становится бизнес-архитектором, способным говорить с бизнесом на его
языке и создавать ИТ-решения, которые реально меняют компанию к лучшему. Внедрение ИС
становится не самоцелью, а средством для оптимизации смоделированных и понятых бизнеспроцессов.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 9 (ЧАСТЬ 2)
1. Проблемный вопрос: В проекте внедрения CRM-системы аналитики сразу начали спрашивать
у отдела продаж: "Какие поля должны быть в карточке клиента?" и рисовать
интерфейсы. Почему такой подход является ошибочным? Какой должна быть корректная
последовательность моделирования, и почему она начинается не с данных, а с целей и
процессов?
2. В нотации BPMN смоделируйте фрагмент процесса "Согласование отпуска" (3-4 шага).
Обязательно используйте элементы: стартовое событие, как минимум две задачи
(действия), шлюз (условие), дорожки (минимум две роли), конечное событие. Дайте
пояснения к элементам.
3. Для сущностей "Студент", "Дисциплина" и "Оценка" нарисуйте простую ER-диаграмму, указав
связи и их мощность (например, один студент может иметь много оценок). Каким образом эта
ER-модель может быть преобразована в объекты метаданных 1С?
4. Объясните, чем диаграмма потоков данных (DFD) будет полезна при анализе процесса "Учет
товара на складе" для выявления требований к ИС? Какую информацию, недоступную в
BPMN, она может дать?
5. Что означает принцип "согласованности моделей" в рамках полной бизнес-модели компании
(например, ARIS)? Приведите пример несогласованности между процессной моделью и
моделью данных, которая приведет к ошибке в проектировании ИС.
Домашнее задание для студентов:
1. Изучить конспект лекции 9 (Часть 2).
2. Подготовить письменные ответы на 5 контрольных вопросов. К вопросу №2 приложить
рисунок схемы BPMN (можно от руки, сфотографировано, или сделанный в простом
графическом редакторе).
3. (Дополнительно) Выберите простой бытовой или учебный процесс (например, "Подготовка к
утренним занятиям", "Выбор и покупка товара в интернет-магазине", "Сдача сессии").
Выполните для него мини-моделирование:
o
Сформулируйте цель процесса.
o
Нарисуйте процессную диаграмму в нотации BPMN (5-7 элементов).
o
Выделите ключевые сущности данных (объекты), с которыми работает процесс, и
нарисуйте для них простую ER-диаграмму (2-3 сущности).
o
Сделайте вывод: какую часть этого процесса было бы эффективно
автоматизировать и какие данные для этого нужны?
Тема 10: Спецификация функциональных требований к ИС. Часть 1 (Процессный подход)
Ключевая проблема (сквозной вопрос на занятие):
«Требования к новой ИС поступают от разных отделов: бухгалтерия хочет одни отчеты, отдел продаж
— другие, логисты — третьи. Как превратить этот разрозненный поток пожеланий в целостную,
непротиворечивую и структурированную спецификацию, которая опишет систему как единый
организм, а не как набор разрозненных функций?»
Цель занятия: Сформировать у студентов понимание процессного подхода как фундаментального
метода анализа деятельности организации и выявления функциональных требований к ИС. Научить
их выделять и классифицировать бизнес-процессы для построения логичной и полной
функциональной модели системы.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «На заводе "Машиностроитель" собирают
требования к новой ERP-системе. Отдел главного технолога требует систему для управления
техпроцессами. Отдел снабжения — для управления закупками. Отдел продаж — для
управления заказами. Финансовый директор хочет видеть единую отчетность по всем
направлениям. Каждый отдел подготовил свой список пожеланий (30-40 пунктов). Вопрос: Как
руководителю проекта избежать хаоса и создать единое видение системы? Можно ли просто
сложить все списки в один большой? Какая методология поможет структурировать эти
требования?»

Деятельность студентов: Работают парами. Приходят к выводу, что простым сложением не
обойтись, нужен какой-то объединяющий принцип, который покажет связи между
требованиями разных отделов.

Выход на тему: Преподаватель резюмирует: «Таким объединяющим принципом
является процессный подход. Он позволяет увидеть не разрозненные функции отделов, а
сквозные цепочки создания ценности, которые проходят через несколько отделов. Именно
эти цепочки (процессы) и должны быть автоматизированы. Давайте разберемся, как это
работает».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (определения, схемы, примеры
классификаций процессов).
o
Группа 1: «Философия целостности: Процессный подход vs функциональный»

Задача: Сравнить процессный и традиционный функциональный
(департаментный) подход к управлению.

Материалы: Описание функционального подхода (иерархия отделов,
вертикальное управление), описание процессного подхода (сквозные потоки,
ориентированные на результат и клиента), их плюсы и минусы.

Вопросы для анализа:
1. В чем ключевое различие между функциональным
(департаментным) и процессным взглядом на организацию?
2. Какой из подходов лучше выявляет проблемы на стыках
отделов (например, когда отдел продаж обещает то, что производство не
может сделать)? Почему?
3. Почему для проектирования интегрированных ИС (ERP) процессный
подход является более естественным и эффективным?
o
Группа 2: «Атомы деятельности: Основные элементы процессного подхода»

Задача: Изучить ключевые элементы, из которых строятся процессы.

Материалы: Определения: вход/выход процесса, владелец процесса, ресурсы,
показатели эффективности (KPI), границы процесса. Примеры для процесса
"Выполнение заказа клиента".

Вопросы для анализа:
1. Дайте определения: вход процесса, выход процесса, владелец
процесса. Почему определение владельца критически важно?
2. Что такое показатели эффективности процесса (KPI)? Приведите 2-3
примера KPI для процесса "Обработка претензии клиента".
3. Как эти элементы (вход, выход, владелец, KPI) помогают в
формулировании четких и измеримых требований к ИС?
o
Группа 3: «Карта процессов: Классификация и выделение»

Задача: Изучить основные классы процессов в организации.

Материалы: Классификация процессов: основные (производящие ценность),
управления (менеджмент), обеспечивающие (поддерживающие). Примеры для
каждого класса. Принцип выделения процессов.

Вопросы для анализа:
1. Дайте характеристику основных (базовых) процессов. Как они связаны с
миссией компании и созданием продукта/услуги для внешнего клиента?
Приведите пример.
2. Чем процессы управления (например, стратегическое планирование,
бюджетирование) отличаются от основных? Чем процессы
обеспечения (например, подбор персонала, ИТ-поддержка)?
3. Почему при проектировании ИС важно автоматизировать в первую
очередь основные процессы? Может ли система работать без
автоматизации процессов обеспечения?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется схема: Процессный подход →
Элементы процесса → Классификация процессов → Карта процессов верхнего уровня.

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Процессный подход — это методология управления, рассматривающая деятельность
организации как совокупность взаимосвязанных бизнес-процессов, направленных на
создание ценности для клиента. В отличие от функционального подхода (где
оптимизируют работу отделов), процессный подход оптимизирует сквозные потоки
работ, проходящие через несколько отделов, что минимизирует потери на стыках.
2. Основные элементы процессного подхода:

Вход — что преобразуется (материалы, информация).

Выход (продукт) — результат, имеющий ценность для потребителя (клиента
процесса).

Владелец процесса — лицо, несущее ответственность за результат и
эффективность процесса.

Ресурсы — то, что потребляется в процессе (оборудование, ПО, люди).

Показатели (KPI) — измеримые метрики эффективности (время, стоимость,
качество).

Границы — точки начала и окончания процесса.
3. Классификация процессов (по ISO 9000, APQC):

Основные (базовые, ключевые) процессы: Создают основную
продукцию/услуги, приносящие доход. Непосредственно создают ценность
для внешнего клиента. Примеры: "Разработка продукта", "Производство",
"Продажи и маркетинг", "Обслуживание клиентов".

Процессы управления (менеджмента): Обеспечивают планирование, контроль
и координацию деятельности. Примеры: "Стратегическое управление",
"Финансовое управление", "Управление рисками", "Управление проектами".

Процессы обеспечения (поддерживающие): Обеспечивают ресурсами и
инфраструктурой основные и управленческие процессы. Примеры: "Управление
персоналом", "ИТ-обеспечение", "Административно-хозяйственное
обеспечение", "Юридическая поддержка".
4. Выделение процессов — это декомпозиция деятельности компании на процессы этих
трех типов. Результат — карта (модель) процессов верхнего уровня, которая
показывает, как основные, управленческие и обеспечивающие процессы связаны
между собой.
5. Связь с функциональными требованиями к ИС: Карта процессов верхнего уровня
становится оглавлением для спецификации функциональных требований. Каждому
процессу (особенно основному) ставится в соответствие функциональный блок или
модуль будущей ИС. Требования к системе формулируются как способность
поддерживать, автоматизировать и улучшать показатели (KPI) этих процессов. Это
гарантирует целостность и бизнес-ориентированность системы.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу с заводом. Студентам предлагается предложить план действий
руководителя проекта.

Примерный итог: «Руководитель проекта должен отказаться от работы с разрозненными
списками отделов. Вместо этого нужно совместно с руководством завода построить карту
процессов верхнего уровня: выделить основные процессы ("Управление заказами",
"Производство", "Снабжение"), управленческие ("Бюджетирование", "Контроль качества") и
обеспечивающие ("Ремонт оборудования", "ИТ-поддержка"). Затем для каждого процесса
определить владельца и KPI. Требования к ERP-системе будут сгруппированы и
сформулированы как поддержка этих процессов. Это обеспечит целостность системы и
удовлетворит все отделы, так как их функции будут видны как части сквозных процессов».

Анонс следующей темы: «Мы создали карту процессов. Теперь нужно детально описать
каждый процесс, чтобы выявить конкретные функции, которые должна выполнять ИС. Этим
займемся в следующей части».
Конспект лекции 10. Спецификация функциональных требований к ИС. Часть 1 (Процессный
подход)
Введение (Проблематизация)
Спросите десять сотрудников компании, что должна делать новая информационная система. Вы
получите десять разных списков, полных противоречий, дублирований и пробелов. Как собрать из
этого мозаику целостную картину? Ответ — сменить точку зрения. Вместо того чтобы спрашивать
«Чего хочет твой отдел?», нужно спросить: «Какой бизнес-процесс ты выполняешь, какой в него
вклад вносишь и как система может этот процесс улучшить?». Это и есть процессный подход — язык,
на котором бизнес говорит о своей деятельности, а проектировщик понимает, что на самом деле
нужно автоматизировать.
1. Процессные потоковые модели; процессный подход к организации деятельности

Процессный подход — это философия и методология управления, согласно которой
организация рассматривается как система взаимосвязанных бизнес-процессов, а не как
совокупность разрозненных функций (отделов). Его цель — оптимизация сквозных потоков
создания ценности для конечного клиента.

Процессные потоковые модели (нотации BPMN, EPC) — это инструменты визуализации и
описания процессов в рамках этого подхода.

Сравнение с функциональным подходом:
o
Функциональный подход: Фокус на вертикалях — отделах, функциях, зонах
ответственности. Приводит к «стенкам» между подразделениями, потере информации,
локальной оптимизации в ущерб общему результату.
o
Процессный подход: Фокус на горизонталях — сквозных цепочках работ,
пронизывающих несколько отделов. Ориентирован на результат процесса (ценность
для клиента), что способствует интеграции и глобальной оптимизации.
2. Основные элементы процессного подхода
Для однозначного описания и анализа процесса необходимо определить:
1. Границы процесса: Четкие точки начала (триггерное событие) и окончания (результат).
2. Входы (Inputs): Что потребляет и преобразует процесс (сырье, информация, документы).
3. Выходы (Outputs): Конечный продукт процесса, имеющий ценность для потребителя
процесса (который может быть как внешним, так и внутренним клиентом).
4. Владелец процесса: Должностное лицо, наделенное полномочиями и несущее
ответственность за весь процесс, его результат и эффективность.
5. Ресурсы: То, что используется процессом (оборудование, ПО, деньги, персонал).
6. Показатели эффективности (KPI): Количественно измеримые метрики, позволяющие оценить,
насколько хорошо процесс работает (например, время цикла, стоимость, процент брака,
удовлетворенность клиента).
Пример для процесса "Оформление и отгрузка заказа":

Вход: Заявка клиента.

Выход: Отгруженный товар и закрытый счет.

Владелец: Начальник отдела продаж.

KPI: Время от заявки до отгрузки (часы), процент выполненных в срок заказов (%).
3. Выделение и классификация процессов
Выделение процессов — это итеративная работа по декомпозиции деятельности компании от
общего к частному.
Классификация процессов (по назначению и роли в создании ценности):
1. Основные (базовые, ключевые) процессы:
o
Назначение: Непосредственное создание основной продукции или услуги, за которую
клиент платит деньги. Это суть бизнеса компании.
o
Клиент: Внешний.
o
Примеры: "Разработка нового продукта", "Закупка сырья", "Производство",
"Маркетинг и продажи", "Послепродажное обслуживание".
o
Связь с ИС: Автоматизация этих процессов — основа ERP, CRM, SCM-систем.
2. Процессы управления (менеджмента):
o
Назначение: Обеспечение постановки целей, планирования, контроля, анализа и
корректировки деятельности. Они управляют основными и обеспечивающими
процессами.
o
Клиент: Внутренний (руководство, собственники).
o
Примеры: "Стратегическое планирование", "Бюджетирование и финансовый
контроль", "Управление рисками", "Корпоративное управление", "Управление
качеством".
o
Связь с ИС: Автоматизация этих процессов — основа BI (Business Intelligence), систем
бюджетирования, CPM (Corporate Performance Management).
3. Процессы обеспечения (поддерживающие):
o
Назначение: Обеспечение основных и управленческих процессов необходимыми
ресурсами, инфраструктурой и сервисами.
o
Клиент: Внутренний (другие процессы компании).
o
Примеры: "Управление персоналом (HR)", "Информационно-технологическое
обеспечение (IT)", "Административно-хозяйственное обеспечение (АХО)",
"Бухгалтерский и налоговый учет", "Юридическая поддержка".
o
Связь с ИС: Автоматизация этих процессов — основа HRM, ITSM, систем
документооборота, 1С:Бухгалтерии.
Результат классификации и выделения — карта (модель) процессов верхнего уровня —
графическое представление всех ключевых процессов компании и их взаимосвязей.
Это стратегическая карта автоматизации, определяющая, какие модули ИС и в каком порядке
нужны.
Заключение
Процессный подход — это мост между бизнес-стратегией и ИТ-реализацией. Он превращает
хаотичные пожелания пользователей в структурированную, приоритизированную и выровненную по
бизнесу функциональную модель будущей системы. Спецификация требований, построенная на
основе процессной модели, гарантирует, что ИС будет поддерживать не просто функции отделов,
а целостные бизнес-процессы, создающие реальную ценность. Это первый и самый важный шаг к
созданию успешной информационной системы.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 10
1. Проблемный вопрос: При обследовании компании выяснилось, что отдел продаж работает в
CRM, склад — в своей учетной системе, а бухгалтерия — в 1С. Данные передаются вручную
через Excel, что приводит к ошибкам и задержкам. Объясните, как применение процессного
подхода при проектировании новой интегрированной ИС поможет решить эту проблему. В
ответе используйте понятия: "сквозной процесс", "стыки между подразделениями", "владелец
процесса".
2. Для процесса "Прием на работу нового сотрудника" определите:
o
Входы (не менее двух)
o
Выходы (не менее двух)
o
К какому классу (основной, управленческий, обеспечивающий) он относится и почему.
3. Почему для успеха проекта внедрения ИС критически важно
определить владельцев ключевых бизнес-процессов еще на этапе сбора требований? Что
может пойти не так, если этого не сделать?
4. Приведите пример показателя эффективности (KPI) для процесса "Обработка обращений в
службу поддержки". Как этот KPI может трансформироваться в требование к
функциональности ИС (например, к модулю Service Desk)?
5. Составьте фрагмент карты процессов верхнего уровня для интернет-магазина одежды.
Укажите не менее двух процессов из каждого класса (основные, управления, обеспечения).
Домашнее задание для студентов:
1. Изучить конспект лекции 10.
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно) Выберите любую знакомую организацию (вуз, кафе, магазин). Проведите
для нее мини-проект по процессному подходу:
o
Выделите и назовите один ключевой (основной) процесс.
o
Для этого процесса определите: границы, входы, выходы, владельца (должность), 2
KPI.
o
Сделайте вывод: какие основные функции должна предоставлять ИС для поддержки
этого процесса.
Тема 10 (Часть 2): Спецификация функциональных требований к ИС. Часть 2 (Методы
предпроектного обследования)
Ключевая проблема (сквозной вопрос на занятие):
«У нас есть понимание, что такое процессный подход. Но как на практике собрать достоверную
информацию о процессах, проблемах и потребностях сотрудников? Как отличить реальные "болевые
точки" бизнеса от субъективных мнений и личных предпочтений отдельных сотрудников?»
Цель занятия: Сформировать у студентов практические навыки планирования и проведения
предпроектного обследования организации. Научить их применять и критически оценивать
различные методы сбора информации (анкетирование, интервью, наблюдение) для формирования
объективной картины требований к ИС.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «Аналитик Анна пришла в компанию для
обследования перед внедрением 1С. Она провела 3 интервью: с директором (говорил о
стратегии), с главным бухгалтером (жаловалась на старую программу) и с самым активным
менеджером по продажам (рассказал, "как все должно быть идеально"). На основе этого
Анна составила список требований. Через месяц, когда началась настройка системы,
выяснилось: 1) ключевые данные для отчетности хранятся в таблице Excel у начальника
отдела снабжения, о котором все забыли; 2) процесс согласования закупок на самом деле
занимает не 1 день, как сказал директор, а 5; 3) 70% сотрудников не готовы менять
привычные Excel-файлы. Вопрос: В чем системные ошибки Анны при проведении
обследования? Каких методов ей не хватило, чтобы получить полную и объективную
картину?»

Деятельность студентов: Работают парами. Выявляют ошибки: неполный охват
стейкхолдеров, отсутствие проверки информации на практике, игнорирование сопротивления
изменениям.

Выход на тему: Преподаватель резюмирует: «Чтобы не повторить ошибки Анны, нужно
владеть арсеналом методов сбора информации и понимать, когда и какой метод применять.
Давайте систематизируем эти методы и поймем, как их комбинировать для получения
достоверных результатов предпроектного обследования».
Этап 2. Самостоятельная исследовательскую работу в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (описания методов, шаблоны
анкет, чек-листы для интервью).
o
Группа 1: «Стратегия и план: Организация предпроектного обследования»

Задача: Изучить цели, этапы и принципы планирования обследования.

Материалы: Определение предпроектного обследования, его место в ЖЦ ИС
(стадия формирования требований), основные этапы (планирование, сбор,
анализ, документирование), принципы (системность, объективность,
конфиденциальность).

Вопросы для анализа:
1. Сформулируйте основные цели предпроектного обследования. Что
должно стать его результатом?
2. Почему обследование нужно тщательно планировать? Что должно быть
в плане (например, список опрашиваемых, график, методы)?
3. Как определить круг лиц (стейкхолдеров), которых необходимо
включить в обследование, чтобы избежать ситуации, как в кейсе с
Анной?
o
Группа 2: «Методы сбора "мягкой" информации: Анкетирование и
интервьюирование»

Задача: Изучить методы опроса, их разновидности, достоинства и недостатки.

Материалы: Типы интервью (структурированное, полуструктурированное,
неструктурированное), правила проведения. Виды анкет (открытые, закрытые,
смешанные), принципы построения.

Вопросы для анализа:
1. В чем разница между анкетированием и интервью? Когда
предпочтительнее использовать каждый метод?
2. Что такое полуструктурированное интервью и почему оно часто
наиболее эффективно при обследовании? Составьте 3-4 ключевых
вопроса для интервью с владельцем процесса "Закупки".
3. Какие типичные ошибки допускают аналитики при проведении
интервью и составлении анкет? (Наводящие вопросы,
профессиональный жаргон, излишняя детализация).
o
Группа 3: «Методы сбора "жестких" данных: Наблюдение и анализ документов»

Задача: Изучить методы прямого наблюдения за деятельностью и анализ
артефактов.

Материалы: Метод "Фотографии рабочего дня" (хронометраж), shadowing
(наблюдение "след в след"), анализ существующих документов и отчетов.

Вопросы для анализа:
1. Что такое "фотография рабочего дня" и какую информацию она дает,
которую невозможно получить на интервью?
2. Почему анализ существующих документов (договоры, отчеты, экранные
формы старых программ, Excel-файлы) является обязательной частью
обследования? Приведите примеры полезных находок.
3. Каковы этические и практические ограничения методов наблюдения?
Как получить согласие сотрудников и не нарушить рабочий процесс?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется сравнительная таблица методов сбора
информации.

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Предпроектное обследование — это комплекс мероприятий по сбору, анализу и
документированию информации об объекте автоматизации, его внешней среде,
существующих проблемах и требованиях к новой ИС. Цель: получить полное и
объективное понимание предметной области для формирования качественного
Технического задания (ТЗ).
2. Принципы успешного обследования: Системность (охват всех аспектов),
Объективность (проверка данных), Комплексность (использование нескольких
методов), Конфиденциальность, Уважение к сотрудникам.
3. Ключевые методы сбора информации и их применение:

Интервью (беседа): Лучше всего подходит для выявления мотивации, проблем,
неформальных правил, стратегических целей. Эффективно с топменеджментом и ключевыми специалистами. Типы: Структурированное (по
жесткому сценарию), Неструктурированное (свободная
беседа), Полуструктурированное (имеет план ключевых тем, но допускает
гибкость) — "золотая середина".

Анкетирование (опрос): Позволяет быстро собрать мнения большой группы
людей (например, всех пользователей). Хорошо для выявления общей
удовлетворенности, частоты использования функций. Риск: низкий процент
возврата, поверхностные ответы.

Фотография рабочего дня (хронометраж): Метод наблюдения и
фиксации точных временных затрат на операции. Раскрывает реальную, а не
декларируемую загрузку сотрудников, выявляет скрытые, рутинные операции.

Анализ документов и артефактов: Изучение существующих документов,
отчетов, файлов, журналов, записей в БД. Дает объективные данные о
реальных потоках информации, структурах данных, объемах работ. Позволяет
обнаружить "теневые" системы учета (те самые Excel-таблицы).

Наблюдение (shadowing): Прямое наблюдение за работой сотрудника.
Позволяет увидеть неосознаваемые действия, "хаки", реальные проблемы в
интерфейсах.
4. Результаты предпроектного обследования оформляются в виде Отчета об
обследовании или непосредственно используются для составления Технического
задания (ТЗ). В отчет входят: описание текущей ситуации (организационная структура,
бизнес-процессы "как есть"), выявленные проблемы и "узкие места", требования и
пожелания заказчика, ограничения, предварительные рекомендации по
автоматизации.
5. Главный вывод: Ни один метод не дает полной картины. Треугольник
методов — Интервью (понимаем "почему" и "зачем"), Наблюдение/Фотография
рабочего дня (понимаем "как на самом деле"), Анализ документов (получаем
"жесткие" данные) — позволяет добиться перекрестной проверки информации
(триангуляции) и минимизировать риски получения неполных или искаженных
требований.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу с Анной. Студентам предлагается составить для нее краткий план
исправления ошибок.

Примерный итог: «Анне следовало: 1) Спланировать обследование: составить полный список
стейкхолдеров (включив начальника снабжения и рядовых кладовщиков). 2) Комбинировать
методы: провести интервью не с тремя, а с 10-15 ключевыми лицами; раздать анкету всем
сотрудникам отдела продаж и закупок; запросить и проанализировать основные Excel-файлы
и журналы; провести выборочное наблюдение за процессом согласования. 3) Сопоставлять
данные: сравнивать то, что говорят на интервью, с тем, что видно в документах и при
наблюдении. Только тогда требования были бы полными и объективными».

Анонс следующей темы: «Мы собрали и проанализировали информацию. Теперь нужно
грамотно ее задокументировать в виде формальных требований. Рассмотрим структуру и
содержание Технического задания».
Конспект лекции 10 (Часть 2). Спецификация функциональных требований к ИС. Часть 2 (Методы
предпроектного обследования)
Введение (Проблематизация)
Знать теорию процессного подхода — необходимо, но недостаточно. Проектировщик ИС — это еще
и исследователь, детектив и психолог. Его задача — проникнуть вглубь работы организации,
выявить истинные, а не декларируемые процессы, понять реальные проблемы людей и собрать
факты, на которых будет строиться новая система. Какими инструментами он для этого пользуется?
4. Проведение предпроектного обследования организации
Это первая практическая фаза проекта, следующая за инициацией. Ее задача — получить
всестороннее понимание предметной области.

Цели:
1. Изучить организационную структуру и окружение.
2. Выявить и описать бизнес-процессы «как есть» (AS-IS).
3. Зафиксировать проблемы, узкие места, неэффективные операции.
4. Сформулировать потребности и ожидания ключевых стейкхолдеров.
5. Определить границы и ограничения будущего проекта.

Основные этапы обследования: Планирование → Сбор информации → Анализ информации
→ Документирование результатов.

Ключевой принцип: Триангуляция — использование нескольких независимых методов для
сбора данных об одном объекте с целью повышения достоверности.
5. Анкетирование, интервьюирование, фотография рабочего времени персонала
А. Интервьюирование (Interview)

Суть: Целенаправленная беседа аналитика с представителем заказчика (стейкхолдером) по
заранее подготовленному сценарию.

Виды:

o
Структурированное: Жесткий список вопросов. Легко обрабатывать, но нет гибкости.
o
Неструктурированное: Свободная беседа на общую тему. Позволяет раскрыть
неочевидное, но сложно управлять и систематизировать.
o
Полуструктурированное (наиболее эффективное): Есть основной список
вопросов/тем, но порядок и формулировки могут меняться. Позволяет и
придерживаться плана, и углубляться в интересные ответы.
Правила проведения: Готовьтесь (изучите собеседника), создавайте доверительную
атмосферу, задавайте открытые вопросы ("Как...?", "Почему...?", "Что произойдет, если...?"),
больше слушайте, чем говорите, ведите записи, резюмируйте ключевые моменты.
Б. Анкетирование (Questionnaire)

Суть: Массовый опрос с помощью стандартизированных бланков (анкет).

Типы вопросов: Открытые (свободный ответ), закрытые (выбор из вариантов), шкальные
(оценка по шкале).

Преимущества: Охват большой аудитории, анонимность, количественная обработка.

Недостатки: Низкая глубина, риск неверного толкования вопросов, низкий процент возврата.

Применение в ИТ-проектах: Оценка удовлетворенности текущими системами, сбор массовых
пожеланий, выявление частоты использования функций.
В. Фотография рабочего дня (Work Time Photography)

Суть: Непрерывное наблюдение и точная фиксация всех действий работника, затрат времени
и перерывов в течение всего рабочего дня (или репрезентативного периода).

Что фиксируется: Наименование операции, время начала/окончания, длительность,
результат, используемые инструменты (ПО, документы).

Результат: Таблица или диаграмма, наглядно показывающая распределение времени.
Позволяет выявить: непроизводительные затраты времени, рутинные операции-кандидаты на
автоматизацию, реальную загрузку сотрудников.

Важно: Проводится с согласия сотрудника, результаты часто используются в обезличенном и
агрегированном виде.
Г. Другие методы:

Анализ документов: Изучение регламентов, отчетов, форм, журналов, файлов данных. Дает
объективную картину информационных потоков и структур.

Наблюдение (Shadowing): Аналитик "следует по пятам" за сотрудником, наблюдая за его
работой без вмешательства. Позволяет увидеть неформальные практики.

Рабочие сессии (Workshops): Групповые обсуждения с участием представителей разных
отделов для совместного моделирования процессов "как есть" и "как должно быть".
6. Результаты предпроектного обследования
Итогом этапа является Отчет о предпроектном обследовании. Его примерная структура:
1. Введение: Цели, задачи, методы и сроки обследования.
2. Общая характеристика организации: Краткое описание, миссия, организационная структура.
3. Описание существующей системы управления (ИС "как есть"):
o
Функциональное окружение (какие задачи решаются).
o
Информационное окружение (какие данные используются, где хранятся).
o
Техническое окружение (ПО, оборудование).
o
Описание ключевых бизнес-процессов (желательно в графическом виде).
4. Анализ выявленных проблем и ограничений: "Узкие места", дублирование функций, ручные
операции, недостаток информации.
5. Требования и ожидания заказчика: Сводка пожеланий от различных стейкхолдеров,
сгруппированная по процессам или направлениям.
6. Предварительные выводы и рекомендации:
o
Область автоматизации и границы проекта.
o
Критические факторы успеха.
o
Ограничения и риски.
o
Рекомендации по дальнейшим действиям (например, разработка ТЗ).
Этот отчет является основой для составления Технического задания (ТЗ) и проведения стоимостной
оценки проекта.
Заключение
Умение грамотно провести предпроектное обследование — это ключевая компетенция аналитика и
проектировщика ИС. От качества собранной информации на 80% зависит успех всего проекта.
Использование комплексного подбора методов (интервью + наблюдение + анализ документов)
позволяет не только собрать требования, но и завоевать доверие будущих пользователей, вовлекая
их в процесс создания системы с самого начала. Помните: нельзя автоматизировать хаос, не
превратив его в систему. Предпроектное обследование и есть первый шаг к наведению порядка.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 10 (ЧАСТЬ 2)
1. Проблемный вопрос: В ходе интервью начальник отдела уверенно заявляет: "Мой отдел
обрабатывает входящие заявки максимум за 2 часа". Однако пользователи жалуются на
задержки в 1-2 дня. Какие методы обследования, кроме интервью, вы примените для
проверки этой информации и выявления истинных причин расхождений? Обоснуйте выбор
методов.
2. Составьте план-сценарий полуструктурированного интервью (5-7 ключевых вопросов/тем) с
менеджером по продажам для выявления требований к функционалу нового модуля CRM в
системе 1С. Вопросы должны быть открытыми и нацелены на выявление процессов, а не
конкретных кнопок.
3. Для каких целей в рамках предпроектного обследования целесообразно использовать
анкетирование, а для каких — фотографию рабочего дня? Приведите по одному
конкретному примеру для каждого метода.
4. Что такое «триангуляция» применительно к методам сбора требований? Приведите пример,
как можно триангулировать информацию о процессе "Утверждение отпуска".
5. Какие разделы отчета о предпроектном обследовании будут напрямую использованы при
составлении Технического задания (ТЗ) на систему? Назовите не менее трех и объясните
связь.
Домашнее задание для студентов:
1. Изучить конспект лекции 10 (Часть 2).
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно — практикум) Выберите простой процесс из учебной или повседневной
жизни (например, "Выдача книги в библиотеке", "Заказ еды в столовой", "Запись на
консультацию к преподавателю"). Спланируйте и мысленно проведите для него миниобследование:
o
Определите 3-4 ключевых стейкхолдера для опроса.
o
Для одного из них составьте список из 5-7 вопросов для полуструктурированного
интервью.
o
Предложите 2-3 конкретных документа или артефакта, которые вы бы
проанализировали.
o
Сформулируйте одну гипотезу о проблеме в этом процессе и предложите, как вы ее
проверите с помощью наблюдения.
Тема 11: Методологии моделирования предметной области. Часть 1 (Структурные модели)
Ключевая проблема (сквозной вопрос на занятие):
«При обследовании компании мы собрали гору разрозненной информации: списки сотрудников,
документы, отчеты, описание функций отделов. Как превратить этот хаос в четкую,
структурированную модель, на основе которой можно проектировать систему? Существуют ли
стандартные "линзы", через которые можно посмотреть на организацию, чтобы увидеть её стройную
архитектуру?»
Цель занятия: Сформировать у студентов понимание трех ключевых структурных моделей
предметной области (объектной, функциональной, управления) как фундамента для системного
анализа и проектирования ИС. Научить выделять и описывать эти структуры в контексте реального
бизнеса.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «Стартап “Hava” продает надувную мебель
через Instagram. Всё управляется в чатах: заказы принимает основатель, логистику
координирует его друг, а деньги считают в Google-таблицах. Компания растет, хаос нарастает.
Для создания нормальной ИС наняли студента-программиста. Он сразу спросил: “Где база
данных товаров? Какие у вас бизнес-процессы?” Основатель развел руками. Вопрос: Что
должен сделать аналитик (или сам студент), прежде чем проектировать базу данных и писать
код? Какие три главных “чертежа” (структуры) компании ему нужно создать, чтобы понять, что
автоматизировать?»

Деятельность студентов: Работают парами. Предлагают идеи: нарисовать схему, кто за что
отвечает (структура управления), что продается (структура объектов), какие шаги делает заказ
(функции).

Выход на тему: Преподаватель резюмирует: «Чтобы автоматизировать хаос, его сначала
нужно структурировать. Классический структурный анализ предлагает три обязательных
“проекции” или “вида” компании: что в ней есть (объектная структура), что она делает
(функциональная структура) и кто и как этим управляет (структура управления). Это и есть
первые три модели предметной области».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (определения, примеры, схемы,
фрагменты методик SADT/IDEF0).
o
Группа 1: «Мир сущностей: Объектная структура предметной области»

Задача: Изучить понятие объектной структуры и методы её выделения.

Материалы: Определение объекта предметной области (сущности), примеры
(ресурсы, документы, люди, события). Принципы выделения объектов
(устойчивость, идентифицируемость). Связь с ER-диаграммами.

Вопросы для анализа:
1. Что такое объект (сущность) предметной области? Приведите 5-6
примеров объектов для компании “Hava”.
2. Чем объектная структура отличается от организационной структуры?
(Подсказка: отдел — это не объект данных, а Клиент — объект).
3. Как правильно выделить объекты? Почему “Обработка заказа” — это не
объект, а “Заказ” — объект? Сформулируйте правило.
o
Группа 2: «Мир действий: Функциональная структура»

Задача: Изучить функциональную структуру и принцип декомпозиции функций.

Материалы: Определение функции (операции, действия). Методология
функционального моделирования IDEF0 (блоки, дуги). Принцип иерархической
декомпозиции (контекстная диаграмма, диаграммы уровней).

Вопросы для анализа:
1. Что такое функция в контексте моделирования предметной области? Как
она связана с бизнес-процессом? (Функция — это действие, процесс —
это последовательность функций).
2. Опишите логику методологии IDEF0. Что обозначают прямоугольник
(блок) и стрелки (вход, управление, выход, механизм)?
3. Постройте фрагмент функциональной структуры для “Hava”:
декомпозируйте функцию “Продажа товара” на 2-3 подфункции
следующего уровня.
o
Группа 3: «Мир власти: Структура управления»

Задача: Изучить структуру управления и её связь с информационными
потоками.

Материалы: Понятие структуры управления (иерархия, полномочия,
ответственность). Типы организационных структур (линейная, функциональная,
матричная). Схемы потоков информации для принятия решений.

Вопросы для анализа:
1. Что входит в понятие “структура управления” помимо организационной
схемы? (Принятие решений, утверждение, контроль).
2. Как тип организационной структуры (например, плоская в стартапе vs
иерархическая в заводе) влияет на проектирование системы
документооборота и маршрутов согласования в ИС?
3. Почему при анализе структуры управления важно выявлять не только
формальные, но и неформальные центры принятия решений? К чему
может привести их игнорирование?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется схема с тремя пересекающимися
кругами: Объектная структура, Функциональная структура, Структура управления, с
примерами связей между ними.

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Структурная модель предметной области — это формализованное описание
организации с точки зрения её состава, деятельности и управления. Это три
взаимосвязанных, но различных взгляда на одну систему.
2. Объектная структура: Описывает статические, информационные сущности, с
которыми работает компания. Это «существительные» бизнеса: Ресурсы (Товар,
Деньги, Оборудование), Документы (Заказ, Накладная, Счет), Контрагенты (Клиент,
Поставщик), Сотрудники. Результат моделирования — ER-диаграмма (СущностьСвязь). Это основа для проектирования базы данных (справочников и документов в
1С).
3. Функциональная структура: Описывает преобразования, которые компания
производит над объектами. Это «глаголы» бизнеса: Производить, Продавать,
Учитывать, Планировать. Моделируется через диаграммы декомпозиции функций
(IDEF0), где каждая функция имеет Входы (что преобразуется), Выходы (результат),
Управление (правила) и Механизмы (кто/что выполняет). Это основа для
выделения модулей и подсистем будущей ИС.
4. Структура управления: Описывает распределение ответственности, полномочий и
потоков управленческой информации. Включает формальную организационную
структуру и неформальные связи. Определяет, кто принимает
решения, какие документы и отчеты для этого нужны, как информация движется по
иерархии. Это основа для проектирования системы прав доступа, workflow
(маршрутов согласования) и управленческой отчетности в ИС.
5. Взаимосвязь структур: Функции (Ф) оперируют Объектами (О) под контролем
Структуры управления (У). Пример: Функция “Утвердить заказ” (Ф) выполняется
Директором (У) над объектом “Заказ клиента” (О). Без понимания всех трех структур
проектирование ИС будет ущербным.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу стартапа “Hava”. Студентам предлагается кратко описать три структуры
для него.

Примерный итог: «Аналитик должен сначала построить для “Hava”: 1) Объектную структуру:
выделить сущности “Товар (надувной диван)”, “Клиент Instagram”, “Заказ”, “Платеж”.
2) Функциональную структуру: декомпозировать процесс на функции “Принять заказ в чате”,
“Согласовать срок доставки”, “Подготовить товар к отправке”. 3) Структуру управления:
зафиксировать, что основатель принимает все ключевые решения, а друг исполняет. Только
после этого станет ясно, что нужно автоматизировать: каталог товаров (объекты), личный
кабинет для приема заказов (функции) и простую систему уведомлений для согласования
(управление)».

Анонс следующей темы: «Мы рассмотрели статические структуры. Теперь изучим, как
описывать динамику — потоки данных и состояний в системе».
Конспект лекции 11. Методологии моделирования предметной области. Часть 1 (Структурные
модели)
Введение (Проблематизация)
Представьте, что вам нужно объяснить инопланетянину, что такое «велосипед». Вы не станете сразу
показывать ему анимацию езды. Вы сначала опишете детали (рама, колеса, цепь — объектная
структура), затем принцип работы (крутить педали, рулить, тормозить — функциональная
структура), и лишь потом — кто и как им управляет (велосипедист, правила дорожного движения
— структура управления). Так и с бизнесом. Чтобы его автоматизировать, нужно сначала создать эти
три «чертежа» — структурные модели предметной области.
1. Структурная модель предметной области; объектная структура

Структурная модель — это абстракция, выделяющая в предметной области устойчивые,
относительно неизменные компоненты и связи между ними. Она отвечает на вопрос «ИЗ
ЧЕГО состоит система?».

Объектная структура (информационная модель) — это модель, описывающая
множество сущностей (объектов) предметной области, их свойств (атрибутов) и статических
связей между ними.
o
Объект (сущность) — это элемент предметной области, информация о котором
должна храниться в системе и который может быть однозначно идентифицирован.
Объекты — это пассивные элементы, над которыми производятся действия.
o
Примеры объектов: Справочники в 1С («Номенклатура», «Контрагенты»,
«Сотрудники»), Документы («Приходная накладная», «Заказ покупателя»), Регистры
сведений («Цены номенклатуры»).
o
Метод описания: ER-диаграммы (Entity-Relationship). Прямоугольник — сущность,
овал — атрибут, ромб — связь. Мощность связи (1:1, 1:N, M:N) критически важна для
проектирования БД.
o
Зачем это нужно проектировщику ИС? Объектная структура — это
прямое техническое задание для проектировщика базы данных или конфигуратора
1С. Она определяет, какие справочники, документы и регистры нужно создать.
2. Функциональная структура

Функциональная структура — это модель, описывающая совокупность действий (функций),
выполняемых в предметной области, их иерархию и взаимосвязи. Она отвечает на
вопрос «ЧТО ДЕЛАЕТ система?».

Функция — это целенаправленное действие или группа действий, преобразующее входные
данные (объекты) в выходные по определенным правилам.

Метод описания: Методология IDEF0 (Icam DEFinition).
o
Блок (прямоугольник): Обозначает функцию. Имеет уникальный номер и название
(глагол).
o
Вход (слева): Материалы или информация, которые преобразуются функцией.
o
Выход (справа): Результат преобразования.
o
Управление (сверху): Правила, стандарты, законы, по которым работает функция
(например, «Закон о защите прав потребителей» для функции «Возврат товара»).
o
Механизм (снизу): Ресурсы, выполняющие функцию (люди, оборудование, ПО).

Принцип декомпозиции: Любая функция может быть детализирована (разложена) на
диаграмме нижнего уровня, состоящей из нескольких взаимосвязанных подфункций. На
верхнем уровне — контекстная диаграмма с одной функцией «Управлять компанией».

Зачем это нужно проектировщику ИС? Функциональная структура (IDEF0) позволяет:
1. Четко определить границы автоматизации (какие функции будут поддерживаться ИС).
2. Выявить информационные потребности каждой функции (что на входе, что на
выходе).
3. Спроектировать архитектуру системы — разбить её на подсистемы и модули,
соответствующие группам функций.
3. Структура управления

Структура управления — это модель, описывающая распределение целей, задач,
ответственности и полномочий между элементами организации, а также потоки
управленческой информации, необходимой для принятия решений и контроля. Она отвечает
на вопросы «КТО управляет?», «КАК принимаются решения?».

Включает в себя:
1. Формальную организационную структуру (схему подчинения).
2. Распределение функций по должностям (матрица ответственности RACI).
3. Модель принятия решений: какие решения, кем, на основе какой информации и в
какие сроки принимаются.
4. Систему планирования и контроля.

Зачем это нужно проектировщику ИС? Структура управления напрямую диктует ключевые
нефункциональные требования к системе:
1. Система разграничения прав доступа (RBAC): Кто и к каким данным имеет доступ.
2. Система workflow (маршруты согласования): Как документы движутся по инстанциям.
3. Интерфейсы управленческой отчетности (Dashboards): Какие агрегированные данные
и в каком виде нужны руководителям разных уровней для контроля.
Заключение
Три структурные модели (объектная, функциональная, управления) — это триединый каркас, на
который «нанизывается» будущая информационная система. Попытка проектировать ИС, пропустив
этап их построения, подобна попытке строить дом без архитектурного плана, имея лишь список
желаемых комнат. Только владея языком этих моделей, аналитик может грамотно перевести
расплывчатые бизнес-потребности в четкие, формальные и взаимосвязанные требования к
программному обеспечению.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 11
1. Проблемный вопрос: При обследовании отдела продаж вы получили список: «Нужен
быстрый поиск клиента, автоматический расчет скидки, отчет по менеджерам, напоминание о
звонках». Как, используя методологию структурного моделирования, преобразовать этот
список в системное видение модуля CRM? Опишите, какие элементы объектной,
функциональной и управленческой структур вам нужно будет выявить.
2. Для предметной области «Библиотека» выделите не менее пяти ключевых объектов
(сущностей). Для одного из них укажите 3-4 атрибута. Нарисуйте фрагмент ER-диаграммы,
связав два объекта осмысленной связью и указав её мощность.
3. Представьте функцию «Рассчитать заработную плату» в нотации IDEF0. Укажите, что может
являться: Входом (I), Выходом (O), Управлением (C) и Механизмом (M) для этого блока.
4. Объясните, как тип организационной структуры (например, проектная (матричная))
повлияет на проектирование системы учета времени и задач в ИС по сравнению с линейнофункциональной структурой.
5. Почему при построении объектной структуры важно отличать объектыдокументы (например, «Договор») от объектов-справочников (например, «Контрагент»)? Как
это различие отражается в метаданных платформы 1С?
Домашнее задание для студентов:
1. Изучить конспект лекции 11.
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно) Выберите небольшой, но реальный объект вокруг вас (студенческое кафе,
секция в спортзале, кружок по интересам). Проведите для него структурный анализ:
o
Составьте список из 5-7 ключевых объектов (что есть?).
o
Определите 3-4 основные функции (что делается?).
o
Опишите неформальную структуру управления (кто за что отвечает, кто принимает
решения?).
o
Сделайте вывод: какие из этих элементов просится автоматизировать в первую
очередь и почему?
Тема 11 (Часть 2): Методологии моделирования предметной области. Часть 2
Ключевая проблема (сквозной вопрос на занятие):
«Мы смоделировали, "что есть" и "что делается" в компании. Но кто конкретно будет работать в
новой системе и на каком "железе" она встанет? И главное: стоит ли описывать бизнес через
функции (действия) или через объекты (сущности)? От этого выбора зависит вся архитектура будущей
ИС. Как не ошибиться?»
Цель занятия: Сформировать у студентов целостное представление о полном комплексе структурных
моделей предметной области, включая организационную и техническую. Научить различать,
сравнивать и выбирать между функционально-ориентированным и объектно-ориентированным
подходами к моделированию.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «Команда аналитиков "Альфа" описала
логистический склад, используя функциональные диаграммы (IDEF0): детально расписала все
операции — "принять груз", "взвесить", "разместить на стеллаж". Команда "Бета" описала тот
же склад, выделив ключевые объекты и их поведение: "Грузовая единица (паллета)" может
иметь статусы "принята", "взвешена", "размещена"; "Стеллаж" имеет свойство "свободное
место". Вопрос: Чем будут отличаться ИС, спроектированные на основе этих двух моделей?
Какая модель может оказаться более гибкой при появлении новых типов грузов или
изменении складских правил?»

Деятельность студентов: Работают парами. Обсуждают, что функциональная модель жестко
задает последовательность, а объектная описывает состояния и правила, которые легче
менять.

Выход на тему: Преподаватель резюмирует: «Это столкновение двух фундаментальных
парадигм в моделировании и проектировании. Чтобы сделать осознанный выбор, нужно
также четко понимать, в какой организационной среде и на какой технической базе будет
жить будущая система. Дополним нашу картину недостающими структурами».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (схемы, описания парадигм,
примеры).
o
Группа 1: «Люди и роли: Организационная структура как система взаимодействия»

Задача: Углубить понимание организационной структуры как динамической
системы.

Материалы: Модели организационных структур (линейная, функциональная,
проектная, матричная, сетевая). Понятие роли (Role) в ИС. Матрица
ответственности RACI (Responsible, Accountable, Consulted, Informed).

Вопросы для анализа:
1. Чем организационная структура как модель отличается от простой
схемы подразделений? Что еще, кроме подчинения, она должна
отражать?
2. Что такое "роль" в контексте проектирования ИС? Почему настраивать
права доступа лучше на роли (например, "Менеджер по продажам"), а
не на конкретных людей?
3. Как матрица RACI помогает выявить пробелы и конфликты в
ответственности при автоматизации процесса? Приведите пример для
процесса "Согласование рекламного бюджета".
o
Группа 2: «Фундамент системы: Техническая структура (инфраструктура)»

Задача: Изучить техническую структуру как среду выполнения ИС.

Материалы: Компоненты технической структуры: аппаратное обеспечение
(серверы, сети, рабочие станции), системное ПО (ОС, СУБД, middleware),
телекоммуникации. Требования к производительности, надежности,
безопасности.

Вопросы для анализа:
1. Почему анализ технической структуры (инфраструктуры) заказчика
является обязательной частью предпроектного обследования? К каким
рискам может привести его игнорирование?
2. Какие нетехнические факторы (например, географическая
распределенность филиалов, требования регуляторов к хранению
данных) влияют на проектирование технической архитектуры ИС?
3. Как выбор платформы (например, "1С:Предприятие") ограничивает или
определяет варианты технической структуры?
o
Группа 3: «Две философии: Функционально-ориентированный vs Объектноориентированный подход»

Задача: Сравнить две основные методологии описания предметной области.

Материалы: Принципы функционально-ориентированного подхода (акцент на
процессах и данных, нисходящее проектирование, DFD/IDEF0). Принципы
объектно-ориентированного подхода (акцент на объектах, их свойствах и
поведении, инкапсуляция, наследование, полиморфизм, UML).

Вопросы для анализа:
1. В чем основное методологическое различие между подходами? Что
является первичным элементом модели: функция или объект?
2. Какие сильные и слабые стороны каждого подхода? Для каких типов
систем (например, расчетных, управляющих) больше подходит каждый?
3. Как эти подходы соотносятся с платформой 1С? Можно ли сказать, что
конфигурация 1С строится на объектно-ориентированных принципах
(объекты метаданных)? А бизнес-логика часто описывается в
функциональном стиле?
Этап 3. Соведение структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется общая схема из 5 взаимосвязанных
структур (объектная, функциональная, управления, организационная, техническая) и
сравнительная таблица двух парадигм.

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Организационная структура (как расширенная модель): Это не просто "дерево"
отделов. Это модель распределения функций, ответственности и полномочий между
людьми и подразделениями. Ключевые инструменты для проектировщика
ИС: ролевая модель (для системы прав) и матрица RACI (для выявления всех
участников процессов). Эта модель отвечает на вопрос "КТО?" в развернутом виде.
2. Техническая структура (инфраструктура): Описывает аппаратно-программную среду,
в которой будет функционировать ИС. Включает: серверы (применений, БД,
файловые), клиентские рабочие места, сетевую инфраструктуру, системы
безопасности, резервного копирования. Анализ этой структуры
определяет нефункциональные требования к системе (производительность,
доступность, безопасность) и напрямую влияет на стоимость проекта.
3. Функционально-ориентированные методологии (Structural Analysis):

Суть: Предметная область описывается как набор функций (процессов),
преобразующих потоки данных. Данные и функции разделены.

Инструменты: DFD (Data Flow Diagrams), IDEF0.

Плюсы: Хорошо подходит для описания четких, регламентированных,
последовательных процессов (например, расчет зарплаты, формирование
регламентированного отчета). Простота и наглядность для бизнеспользователей.

Минусы: При изменении бизнес-правил часто требуется перепроектировать
многие функции. Сложно моделировать сложное поведение и взаимосвязи
объектов.
4. Объектно-ориентированные методологии (OOA/OOD):

Суть: Предметная область описывается как набор взаимодействующих
объектов, обладающих данными (атрибутами) и поведением (методами).
Акцент на инкапсуляции (объект скрывает свою реализацию).

Инструменты: UML (Unified Modeling Language) — диаграммы классов,
состояний, последовательности.

Плюсы: Лучше отражает реальный мир, более гибок к изменениям (можно
добавить новый тип объекта, не меняя всю систему). Прямое отображение в
объектно-ориентированные языки программирования. Подходит для сложных
систем со многими взаимосвязями.

Минусы: Более сложны для понимания неподготовленными бизнеспользователями.
5. Современный синтез: В реальных проектах, особенно при работе с такими
платформами, как 1С, используется гибридный подход. Структура данных (объектная
модель) проектируется в объектно-ориентированном ключе (справочники, документы
— это классы). Бизнес-процессы и сценарии использования часто описываются
функционально (в виде алгоритмов или диаграмм деятельности UML). Важно уметь
применять оба подхода адекватно задаче.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу про склад. Студентам предлагается дать итоговую оценку.

Примерный итог: «Для стандартного склада с жесткими правилами подойдут обе модели. Но
модель команды "Бета" (объектно-ориентированная) потенциально более устойчива к
изменениям. Если появится новый тип паллеты с датчиком температуры, в объектной модели
достаточно будет создать подкласс "Термопаллета" с дополнительным свойством, и логика
системы, работающая с базовым классом "Паллета", может остаться неизменной. В
функциональной модели пришлось бы пересматривать многие диаграммы. Вывод: для
сложных, развивающихся систем предпочтительнее объектный подход, но для простых и
стабильных эффективнее функциональный».

Анонс следующей темы: «Мы освоили методы моделирования предметной области. Теперь
научимся оформлять результаты этого моделирования в главный документ проекта —
Техническое задание».
Конспект лекции 11 (Часть 2). Методологии моделирования предметной области. Часть 2
Введение (Проблематизация)
Мы собрали пазл из структур компании. Но пазл не живет в вакууме. Его будут собирать люди
(организационная структура) на определенном столе (техническая структура). И сам способ, которым
мы режем пазл на кусочки — на функциональные блоки или на объекты-персонажи —
предопределит, насколько легко его потом будет собирать и перестраивать. Завершим построение
полной картины методологий.
4. Организационная структура
Это модель, описывающая состав, взаимосвязи и распределение ответственности среди
человеческих ресурсов компании. В контексте проектирования ИС её важно рассматривать не как
статическую схему, а как систему ролей и взаимодействий.

Ключевые аспекты для ИС:
1. Ролевая модель: Абстракция, группирующая пользователей по выполняемым
функциям (например, "Кассир", "Бухгалтер", "Руководитель отдела"). В ИС права
доступа назначаются ролям, а не конкретным людям, что упрощает
администрирование.
2. Матрица ответственности RACI: Инструмент для четкого определения участия в
процессах.

R (Responsible) – Исполнитель, кто делает работу.

A (Accountable) – Ответственный, кто несет конечную ответственность
(утверждает).

C (Consulted) – С кем консультируются (двусторонняя связь).

I (Informed) – Кого информируют (односторонняя связь).
3. Модель принятия решений: Описание того, какие решения, кем, на каком уровне и на
основе какой информации принимаются. Это основа для проектирования
систем business intelligence (BI) и workflow.
5. Техническая структура
Это модель, описывающая аппаратно-программную платформу, необходимую для
функционирования ИС. Её анализ проводится для обеспечения реализуемости и определения
граничных условий проекта.

Компоненты:
o
Аппаратное обеспечение: Серверы (приложений, баз данных, файловые), сетевое
оборудование, рабочие станции, периферия.
o
Системное программное обеспечение: Операционные системы, системы управления
базами данных (СУБД), промежуточное ПО (middleware), системы виртуализации.
o
Коммуникации: Локальные и глобальные сети, протоколы, каналы связи.
o
Инфраструктура информационной безопасности: Межсетевые экраны, системы
обнаружения вторжений, средства криптозащиты.

Зачем это нужно проектировщику ИС?
o
Для формулировки требований к техническому обеспечению в ТЗ.
o
Для оценки производительности и масштабируемости будущей системы.
o
Для выявления ограничений и рисков (устаревшее "железо", низкая скорость сети).
o
Для планирования этапов внедрения и миграции данных.
6. Функционально-ориентированные и объектно-ориентированные методологии описания
предметной области
Это два основных конкурирующих подхода (парадигмы) к анализу и проектированию систем.
А. Функционально-ориентированный подход (FOA - Function-Oriented Analysis):

Философия: Система – это черный ящик, преобразующий входные данные в выходные через
последовательность функций. Акцент на процессах и потоках данных.

Базовые концепции: Функция, поток данных, хранилище данных, внешняя сущность.

Основные инструменты:
o
DFD (Data Flow Diagram): Диаграммы потоков данных разных уровней.
o
IDEF0: Функциональные диаграммы с входами/выходами/управлением.

Преимущества: Простота, наглядность для заказчика, хорошее отражение последовательных
процессов, историческая проверенность.

Недостатки: "Разрыв" между данными и функциями, сложность отражения сложного
поведения и наследования, низкая устойчивость к изменениям бизнес-правил.
Б. Объектно-ориентированный подход (OOA/OOD - Object-Oriented Analysis/Design):

Философия: Система – это совокупность взаимодействующих объектов, каждый из которых
является экземпляром определенного класса. Акцент на сущностях, их состоянии и
поведении.

Базовые концепции (ООП):

o
Инкапсуляция: Объединение данных и методов в одном объекте, скрытие реализации.
o
Наследование: Возможность создания новых классов на основе существующих.
o
Полиморфизм: Возможность объектов с одинаковым интерфейсом иметь разную
реализацию.
Основной инструмент: UML (Unified Modeling Language).
o
Диаграмма классов (Class Diagram): Статическая структура системы (классы, атрибуты,
методы, связи).
o
Диаграмма последовательностей (Sequence Diagram): Взаимодействие объектов во
времени.
o
Диаграмма состояний (State Machine Diagram): Изменение состояний объекта в ответ
на события.

Преимущества: Более естественное моделирование реального мира, высокая гибкость и
повторная используемость кода, лучшая поддержка сложных и изменчивых систем.

Недостатки: Более высокая сложность освоения, может быть избыточным для простых
систем.
Применительно к 1С: Платформа 1С по своей природе объектно-ориентирована (все метаданные —
это классы: Справочник, Документ, РегистрСведений). Поэтому объектно-ориентированный подход
к анализу данных здесь наиболее естественен. Однако описание бизнес-логики (алгоритмов
проведения документов, расчетов) часто носит процедурный (функциональный) характер внутри
этих объектов.
Заключение
Современный проектировщик ИС должен владеть арсеналом методологий. Выбор между
функциональным и объектным подходом — не вопрос веры, а прагматичное решение, зависящее от
сложности, стабильности требований и выбранной платформы реализации. Часто оптимальным
является комбинированный подход: объектная модель для данных и статической структуры,
функциональные или сценарные модели (UML Use Case, BPMN) для описания процессов. Умение
строить полный комплекс моделей (от организационной до технической структуры) в выбранной
парадигме — признак высокой квалификации специалиста по проектированию информационных
систем.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 11 (ЧАСТЬ 2)
1. Проблемный вопрос: Проектируется ИС для научно-исследовательского института. Процессы
часто меняются, появляются новые типы экспериментов и отчетов. Какой подход к
моделированию предметной области (функциональный или объектно-ориентированный)
будет предпочтительнее и почему? Аргументируйте, ссылаясь на ключевые характеристики
подходов и специфику предметной области.
2. Для проекта внедрения системы электронного документооборота (СЭД) в департаменте с 5
отделами постройте фрагмент матрицы RACI для процесса "Согласование положения об
охране труда". Определите для 2-3 гипотетических ролей (например, "Начальник отдела",
"Специалист по ОТ", "Юрист") их тип участия (R, A, C, I).
3. Почему при анализе технической структуры заказчика важно учитывать не только текущее
состояние, но и стратегию развития его ИТ-инфраструктуры? К каким проблемам может
привести проектирование ИС только под текущие мощности?
4. Сопоставьте основные инструменты моделирования функционально-ориентированного и
объектно-ориентированного подходов. Что в UML является аналогом хранилища данных из
DFD? Что в IDEF0 является аналогом метода класса из UML?
5. Объясните, как принцип инкапсуляции из объектно-ориентированного подхода может быть
реализован при проектировании конфигурации 1С на примере объекта "СчетФактура". Что
будет "скрыто" внутри, а что будет "интерфейсом"?
Домашнее задание для студентов:
1. Изучить конспект лекции 11 (Часть 2).
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно — синтез) Используя знания из обеих частей темы 11, выполните
комплексное задание для вымышленного сервиса "КнигаВдороге" (аудиокниги по подписке):
o
Выделите 3-4 ключевых класса объектов (сущностей) и нарисуйте простую диаграмму
классов UML с атрибутами и связями.
o
Для одного из бизнес-сценариев ("Пользователь слушает книгу") постройте
простую DFD-диаграмму уровня 0 (покажите основные функции и потоки данных).
o
Определите 2-3 ключевые роли в организационной структуре сервиса.
o
Сделайте вывод: какой подход (функциональный или объектный) был для вас
первичным при анализе и почему?
Тема 12: Методологии моделирования предметной области. Часть 1 (Инструменты и практика: от
бизнес-модели к интерфейсам)
Ключевая проблема (сквозной вопрос на занятие):
«Мы создали красивую и сложную функциональную модель бизнес-процесса в нотации IDEF0. Но как
превратить эту абстрактную схему из прямоугольников и стрелок в конкретные, удобные экранные
формы, которые будет заполнять рядовой сотрудник? Существует ли прямой путь от модели
деятельности к проектированию интерфейса информационной системы?»
Цель занятия: Сформировать практическое понимание связи между функциональными моделями
предметной области и проектированием пользовательского интерфейса ИС. Научить студентов
использовать принципы методологии IDEF0 и структуру модели для обоснованного проектирования
экранных форм электронных документов.
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «Аналитик Виктор построил детальную
модель IDEF0 процесса "Оформление заказа клиента" в инструменте BpWin. На диаграмме
нижнего уровня появились функции: "Проверить наличие товара", "Рассчитать стоимость",
"Зарезервировать товар", "Сформировать счет". Руководитель проекта похвалил модель, но
спросил: "Отлично, а как теперь будет выглядеть одна экранная форма "Заказ клиента" в 1С?
Все эти функции должны быть на ней? Или это будут разные кнопки? Откуда брать список
полей для этой формы?" Виктор задумался. Вопрос: Может ли модель IDEF0 дать прямые
ответы на эти вопросы? Если да, то как? Если нет, то чего не хватает в этой модели для
проектирования интерфейса?»

Деятельность студентов: Работают парами. Обсуждают, что на модели показаны действия и
данные, но не видно, как человек их выполняет. Нужно понять, какие данные вводятся для
каждой функции.

Выход на тему: Преподаватель резюмирует: «Модель IDEF0 — это не про интерфейс, а про
логику. Но она содержит всю необходимую информацию о данных на входе, управлении и
выходе каждой функции. Задача проектировщика — "спроецировать" эти данные на
экранные формы, которые станут инструментом (механизмом) для выполнения этих
функций. Давайте научимся это делать, начав с освоения инструмента и правил построения
самой модели».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (скриншоты BpWin/аналогов,
руководство по IDEF0, примеры форм из 1С).
o
Группа 1: «Инструмент мысли: Среда BpWin и её аналоги»

Задача: Ознакомиться с назначением и основными возможностями CASEсредств для функционального моделирования.

Материалы: Описание инструментальной среды BpWin (AllFusion Process
Modeler), её основные функции (создание диаграмм IDEF0, IDEF3, DFD, хранение
в репозитории). Краткий обзор современных аналогов (Business Studio, Visual
Paradigm, Draw.io).

Вопросы для анализа:
1. Каково основное предназначение CASE-средств типа BpWin? Почему для
построения сложных моделей недостаточно обычного графического
редактора?
2. Какие три ключевые методологии/нотации чаще всего поддерживаются
такими средами и для чего каждая используется? (IDEF0, DFD, IDEF3).
3. Что такое репозиторий модели и почему он важен для командной
работы и поддержания целостности модели?
o
Группа 2: «Язык бизнес-архитектуры: Принципы IDEF0»

Задача: Глубоко изучить синтаксис и семантику нотации IDEF0.

Материалы: Стандарт IDEF0: правила построения контекстной диаграммы (A-0),
понятия "Субъект моделирования", "Цель", "Точка зрения". Структура блока
(Function Box) и интерфейсных дуг (Input, Control, Output, Mechanism). Правила
декомпозиции и нумерации.

Вопросы для анализа:
1. Что такое контекстная диаграмма (A-0) и как определяются её границы
через "Цель" и "Точку зрения" моделирования? Почему это критически
важно?
2. В чем принципиальная разница между стрелкой "Управление"
(Control) и стрелкой "Вход" (Input)? Приведите содержательный пример.
3. Как правило нумерации блоков и диаграмм (например, A1, A12, A123)
отражает иерархию модели? Что означает номер "A0"?
o
Группа 3: «Мост от функции к форме: Как модель подсказывает интерфейс»

Задача: Установить связи между элементами IDEF0-модели и элементами
проектирования интерфейса.

Материалы: Скриншот формы документа "Заказ клиента" в 1С. Фрагмент
модели IDEF0 для процесса оформления заказа. Принципы UX: группировка
данных, последовательность заполнения.

Вопросы для анализа:
1. Данные с дуг "Вход" и "Управление" для функции "Рассчитать
стоимость". Как они могут быть отражены на экранной форме? (Поля
ввода, справочники, параметры).
2. Функция (блок) "Проверить наличие". Каким элементом интерфейса она
может быть реализована? (Кнопка "Проверить", автоматическая
проверка при вводе, отдельная информационная панель).
3. Последовательность функций на диаграмме. Должна ли она жестко
определять последовательность вкладок или шагов мастера в форме?
Почему нет? Что важнее для интерфейса — логика данных или логика
пользовательского сценария?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске строится цепочка: Цель моделирования →
Контекстная диаграмма A-0 → Декомпозиция (A1, A2...) → Данные на интерфейсных дугах
→ Проектирование формы (поля, кнопки, логика).

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Инструментальная среда BpWin (и аналоги) — это профессиональный инструмент для
создания, хранения и анализа согласованных комплексов моделей. Они
обеспечивают проверку синтаксиса, поддержку репозитория и генерацию отчетов, что
критично для серьезных проектов.
2. Принципы построения модели IDEF0:

Контекстная диаграмма (A-0): Один блок, представляющий субъект
моделирования (систему в целом). Её границы и содержание
определяются целью (зачем мы моделируем) и точкой зрения (позицией
наблюдателя — директор, технолог, бухгалтер).

Декомпозиция: Блок A-0 детализируется на диаграмме A0 (обычно 3-6 блоков).
Каждый блок A0 может быть детализирован далее (A1, A2, A3...).

Стрелки (интерфейсные дуги): Несут данные или объекты. Вход (I) —
преобразуется в работу. Управление (C) — регламентирует, как делать (правила,
законы, стандарты). Выход (O) — результат. Механизм (M) — ресурс, который
выполняет функцию (отдел, программа, станок).

Строгие правила: Название блока — глагол или отглагольное существительное.
Стрелки должны быть поименованы. Входы/выходы родительского блока
должны соответствовать входам/выходам на дочерней диаграмме (правило
сохранения границ).
3. Проектирование экранных форм электронных документов на основе модели:

Источник данных для полей формы: Поля ввода и вывода на форме
соответствуют данным на стрелках "Вход" (I) и "Управление" (C) для функций,
которые пользователь выполняет с помощью этой формы. Например, для
функции "Сформировать счет" входом может быть "Данные о клиенте и
товарах", а управлением — "Прейскурант", "Правила расчета НДС". Все эти
данные должны быть доступны на форме.

Источник функций для кнопок и команд: Блоки (функции) нижнего уровня,
которые должен инициировать пользователь, могут быть реализованы
как кнопки ("Проверить", "Рассчитать", "Провести") или автоматические
процедуры.

Логическая группировка элементов: Функции, сгруппированные на одной
диаграмме IDEF0, часто логически связаны. Это может подсказать разбивку
формы на вкладки, панели или этапы мастера (например, вкладка "Товары",
вкладка "Доставка и оплата").

Важное ограничение: IDEF0 моделирует логику преобразования данных, а
не пользовательский сценарий (UI-flow). Поэтому последовательность блоков
на диаграмме не обязательно должна превращаться в жесткую
последовательность шагов в интерфейсе. Интерфейс должен быть удобен для
пользователя, а модель гарантирует, что все необходимые данные и функции
учтены.
4. Практический вывод: Модель IDEF0 служит непротиворечивым и полным
источником требований к данным и функциям для проектировщика интерфейсов.
Она отвечает на вопрос "ЧТО должно быть на форме?" (все данные с I и C стрелок) и
"ЧТО можно сделать с формой?" (функции-блоки). Вопрос "КАК это лучше
расположить?" решается на основе принципов юзабилити и конкретной технологии
(1С).
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу с Виктором. Студентам предлагается дать ему рекомендации.

Примерный итог: «Виктор, твоя модель — отличная основа. Чтобы спроектировать форму
"Заказа клиента", сделай следующее: 1) Выбери диаграмму нижнего уровня, где собраны
функции, выполняемые менеджером при оформлении. 2) Выпиши ВСЕ данные со стрелок
"Вход" и "Управление" для этих функций — это кандидаты в поля формы (клиент, товары,
цены, условия доставки). 3) Каждую функцию (блок), которую менеджер запускает сам,
рассмотри как кандидата на кнопку ("Рассчитать", "Зарезервировать"). 4) Сгруппируй эти
данные и кнопки на форме интуитивно, возможно, по шагам сценария работы менеджера, а
не строго по твоей диаграмме. Модель гарантирует, что ты ничего не упустил».

Анонс следующей темы: «Мы увидели, как функциональная модель питает проектирование
интерфейса. Теперь посмотрим на другой, не менее важный вид моделирования —
информационное (данные). Изучим IDEF1X и проектирование структуры базы данных».
Конспект лекции 12. Методологии моделирования предметной области. Часть 1 (Инструменты и
практика)
Введение (Проблематизация)
Моделирование — это не самоцель. Это средство для создания качественного программного
обеспечения. Сегодня мы рассмотрим, как конкретный инструмент (BpWin) и конкретная нотация
(IDEF0) помогают решить очень практическую задачу: спроектировать экранную форму документа в
системе, чтобы она была полной, логичной и соответствовала бизнес-процессу.
1. Инструментальная среда BpWin

BpWin (AllFusion Process Modeler) — это классическое CASE-средство (Computer-Aided
Software/System Engineering) для функционального моделирования, анализа и
реинжиниринга бизнес-процессов.

Основные возможности:

o
Поддержка нотаций IDEF0, IDEF3, DFD.
o
Построение иерархических моделей с соблюдением синтаксических правил.
o
Хранение модели в едином репозитории (проектном файле), что обеспечивает
целостность, непротиворечивость и возможность командной работы.
o
Генерация отчетов и документации.
Современный контекст: BpWin — проприетарный и несколько устаревший продукт. Сегодня
используются аналоги: Business Studio (популярен в РФ, интегрирован с 1С), Visual
Paradigm, Sparx Systems Enterprise Architect, Miro и Draw.io (для более простых задач).
Принципы моделирования при этом не меняются.
2. Принципы построения модели IDEF0
IDEF0 — это федеральный стандарт США, методология функционального моделирования.

Базовые элементы:
o
Функциональный блок (Activity Box): Прямоугольник. Обозначает функцию (действие,
процесс, операцию). Имя блока — глагол или отглагольное существительное.
o
Интерфейсные дуги (Arrows): Представляют данные или материальные объекты,
связывающие блоки. Имя дуги — существительное.


Стороны блока и тип дуг (ICOM):
o
Вход (Input, слева): То, что преобразуется функцией в Выход (материалы,
информация).
o
Управление (Control, сверху): То, что регламентирует выполнение функции, но не
преобразуется (правила, стандарты, законы, планы).
o
Выход (Output, справа): Результат выполнения функции.
o
Механизм (Mechanism, снизу): Ресурсы, обеспечивающие выполнение функции
(люди, оборудование, ПО). Часто на нижних уровнях моделирования не показывается.
Структура и правила моделирования:
1. Контекстная диаграмма (A-0): Самая верхняя диаграмма. Всего один блок, который
представляет собой субъект моделирования (систему в целом). Его границы и
содержание определяются формулировками цели моделирования и точки зрения.

Цель: Зачем мы создаем модель? (Пример: "Описать процесс продаж для
последующей автоматизации в CRM").

Точка зрения: С позиции кого? (Пример: "Менеджера по продажам").
2. Декомпозиция: Блок A-0 детализируется на диаграмме A0. Обычно содержит от 3 до 6
блоков. Каждый блок на A0 может быть детализирован на следующем уровне (A1, A2,
A3...).
3. Сохранение границ: Все входы, управления и выходы родительского блока должны
быть отражены на дочерней диаграмме в качестве граничных стрелок. Это главное
правило обеспечения согласованности модели.
4. Нумерация: Блоки нумеруются по диаграмме (A1, A2, A3). Диаграммы нумеруются по
иерархии (A0, A1, A2, A21, A22...).
3. Проектирование экранных форм электронных документов на основе IDEF0
Электронный документ в ИС (например, документ "Заказ покупателя" в 1С) — это, по
сути, инструмент (механизм) для выполнения одной или нескольких бизнес-функций,
моделируемых в IDEF0.
Алгоритм перехода от модели к форме:
1. Идентификация контекста: Определить, какую функцию (блок) или группу функций нижнего
уровня будет поддерживать создаваемая экранная форма. Например, форма документа
"Реализация товаров" поддерживает функцию "Оформить отгрузку со склада" (блок A32 на
диаграмме A3).
2. Извлечение требований к данным:
o
Данные для ввода пользователем — это, как правило, данные со стрелок "Вход"
(I) и "Управление" (C) выбранной функции.
o
Пример: Для функции "Рассчитать стоимость заказа" (C) — это "Прайс-лист", "Правила
скидок"; (I) — это "Список выбранных товаров". Все эти данные должны быть доступны
на форме (поля выбора товара, отображение цены, поле ввода скидки).
3. Извлечение требований к функциям (кнопкам, командам):
o
Сама функция (блок) часто реализуется как комплексная команда (например,
кнопка "Провести"), которая запускает все внутренние преобразования.
o
Если функция декомпозирована, её подфункции могут стать отдельными
кнопками ("Рассчитать", "Зарезервировать", "Напечатать счет") или автоматическими
действиями.
4. Определение логической структуры формы:
o
Группировка связанных функций на одной диаграмме может подсказать разбивку
на вкладки (например, "Основное", "Товары", "Дополнительно").
o
Последовательность стрелок (поток данных) может подсказать естественный порядок
заполнения полей (от ввода клиента к выбору товаров, к указанию оплаты).
5. Важное замечание: IDEF0 не моделирует пользовательский интерфейс. Она
моделирует логику бизнеса. Поэтому окончательный дизайн формы, расположение
элементов, интерактивность определяются принципами UX/UI и возможностями платформы
разработки (1С). Модель служит гарантией полноты и непротиворечивости функциональных
требований, заложенных в форму.
Заключение
Инструментальные среды вроде BpWin и методологии вроде IDEF0 — это не "академические
изыски", а рабочие инструменты инженера по проектированию ИС. Они позволяют системно
подойти к анализу деятельности и получить на выходе четкий, верифицируемый набор требований,
который напрямую ложится в основу проектирования ключевых элементов системы — экранных
форм электронных документов. Умение "читать" бизнес-модель и видеть за ней будущий интерфейс
— важный навык на стыке бизнес-анализа и проектирования ИС.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 12
1. Проблемный вопрос: В модели IDEF0 процесса "Рассмотрение резюме" функция "Принять
решение" имеет управление "Критерии отбора" и вход "Резюме кандидата". Выход —
"Решение (принять/отклонить)". Спроектируйте фрагмент экранной формы в системе
подбора персонала, которая будет служить инструментом для выполнения этой
функции. Укажите, какие элементы формы (поля, кнопки, списки) будут соответствовать
каждому элементу модели (I, C, O, сама функция).
2. Почему при построении контекстной диаграммы (A-0) так критически важно четко
определить "Точку зрения"? Как изменится модель процесса "Обработка заявки на кредит",
если точкой зрения будет "Сотрудник колл-центра", а не "Начальник кредитного отдела"?
3. В чем заключается правило "сохранения границ" при декомпозиции блока в IDEF0? К каким
ошибкам в проектировании ИС может привести нарушение этого правила (например,
"потеря" управляющей информации на нижнем уровне)?
4. Для функции "Согласовать договор" выявлены следующие данные: "Проект договора" (вход),
"Устав компании и доверенности" (управление), "Согласованный договор" (выход), "Юрист и
руководитель" (механизм). Какие из этих данных должны быть обязательно отражены на
экранной форме электронного документа "Договор" для этапа согласования? Ответ
обоснуйте.
5. Объясните, почему современные онлайн-инструменты для совместной работы (например,
Miro) часто используются для функционального моделирования вместо "тяжелых" CASEсредств вроде BpWin? Какие преимущества и недостатки у такого подхода?
Домашнее задание для студентов:
1. Изучить конспект лекции 12.
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно — практикум) В любом доступном графическом редакторе (Draw.io, Power
Point, Paint) выполните:
o
Часть А: Постройте контекстную диаграмму (A-0) для процесса "Подготовка к лекции
преподавателем". Определите и подпишите Цель и Точку зрения моделирования.
Обозначьте 3-4 ключевые входные, управляющие и выходные стрелки.
o
Часть Б: Выполните декомпозицию на диаграмму A0 (разбейте на 3-4 блока: например,
"Собрать материал", "Создать презентацию", "Подготовить практическое задание").
Покажите стрелки между блоками.
o
Часть В: Для одного из блоков на A0 предложите вид экранной формы в
гипотетической "Системе подготовки преподавателя". Схематично нарисуйте эту
форму, указав, какие элементы на ней соответствуют входам/управлениям выбранного
блока.
Тема 12 (Часть 2): Методологии моделирования предметной области. Часть 2 (Информационное
моделирование и данные)
Ключевая проблема (сквозной вопрос на занятие):
«Мы спроектировали удобные формы для ввода данных, но где и как эти данные будут храниться?
Как избежать ситуации, когда один и тот же клиент в системе числится под разными названиями, а
данные о товаре дублируются в десятке таблиц? Существует ли методология, которая позволяет
спроектировать непротиворечивую, гибкую и эффективную структуру хранения информации —
основу любой ИС?»
Цель занятия: Сформировать у студентов понимание информационного моделирования как
критического этапа проектирования ИС. Научить их основам методологии IDEF1 для построения
концептуальных моделей данных, которые затем могут быть преобразованы в физическую структуру
базы данных (в том числе в объекты метаданных 1С).
План теоретического занятия (2 академических часа)
Этап 1. Погружение в проблему через кейс (15 минут)

Деятельность преподавателя: Предлагает кейс: «При внедрении CRM-системы в компании
"Строймаш" выяснилось, что отдел продаж ведет свой список контактов в Excel, отдел
снабжения — свой в старой программе, а бухгалтерия — в 1С. Один и тот же поставщик "ООО
"Вектор" в одной таблице записан как "Вектор", в другой — "Вектор ООО", в третьей — с ИНН
с ошибкой. При попытке построить отчет по закупкам у одного поставщика система не видит
связи. Вопрос: В чем коренная проблема, приведшая к "информационному хаосу"? Какой этап
проектирования был пропущен, чтобы этого избежать? Что нужно было сделать до начала
программирования или настройки CRM?»

Деятельность студентов: Работают парами. Приходят к выводу, что не была продумана
единая, централизованная структура хранения данных, не определены основные сущности и
правила их ведения.

Выход на тему: Преподаватель резюмирует: «Чтобы данные работали на бизнес, а не
создавали проблемы, их структуру нужно проектировать. Этим занимается информационное
моделирование, а одной из ключевых методологий для этого является IDEF1. Давайте узнаем,
как с её помощью создать "единый источник правды" для всех данных компании».
Этап 2. Самостоятельная исследовательская работа в группах (35 минут)

Деятельность преподавателя: Делит группу на 3 команды и выдает
каждой исследовательское задание с пакетом материалов (описания IDEF1, примеры ERдиаграмм, схемы организации ИБ).
o
Группа 1: «Хранилище знаний: Информационная база и принципы её организации»

Задача: Изучить понятие информационной базы (ИБ) и основные
архитектурные подходы к её организации.

Материалы: Определение ИБ, сравнение подходов: файл-серверная, клиентсерверная (2-х и 3-х уровневая), распределенная архитектура. Принципы
централизации и нормализации данных.

Вопросы для анализа:
1. Что такое информационная база (ИБ) в контексте ИС? Чем она
отличается от базы данных (БД) в техническом смысле?
2. Как архитектура ИБ (файл-серверная vs клиент-серверная) влияет
на производительность, безопасность и масштабируемость системы?
Почему для 1С в средних и крупных компаниях рекомендуют клиентсерверный вариант?
3. Почему принцип "единого ввода и многократного
использования" данных является краеугольным камнем проектирования
ИС? Как он связан с проблемой из кейса?
o
Группа 2: «Сущности и связи: Основы моделирования данных и метод IDEF1»

Задача: Изучить базовые концепции моделирования данных и специфику
методологии IDEF1.

Материалы: Основные понятия: сущность (Entity), атрибут (Attribute), связь
(Relationship), ключ (Key). Особенности IDEF1 как метода, ориентированного на
отображение структуры данных в рамках предметной области, а не на
физическую реализацию.

Вопросы для анализа:
1. Дайте определения: сущность, атрибут, первичный ключ. Приведите
примеры для предметной области "Учебный процесс" (сущность
"Студент", её атрибуты и ключ).
2. В чем основное назначение методологии IDEF1? Чем она отличается от
более известных ER-диаграмм (Chen notation)? (Подсказка: IDEF1 —
стандарт, ориентированный на анализ существующих данных в
организации).
3. Что такое связь (Relationship) в IDEF1? Какие виды мощности связей
(Cardinality) существуют (1:1, 1:N, M:N)? Приведите пример связи M:N.
o
Группа 3: «От концепции к реализации: Отображение модели данных в ИС»

Задача: Изучить, как концептуальная модель данных преобразуется в объекты
конкретной платформы (1С).

Материалы: Примеры отображения сущностей и связей IDEF1 на объекты
метаданных 1С: Сущность -> Справочник или Документ; Атрибут -> Реквизит;
Связь 1:N -> Подчиненный справочник или Табличная часть документа; Связь
M:N -> Регистр сведений.

Вопросы для анализа:
1. Как сущность "Сотрудник" с атрибутами (ФИО, табельный номер,
должность) может быть реализована в 1С? А сущность "Приказ о приеме
на работу"?
2. Как в 1С реализуется связь "Один ко многим" (1:N) между сущностями
"Заказ" и "ПозицияЗаказа"? Что будет сущностью, а что — атрибутами?
3. Почему связь "Многие ко многим" (M:N) (например, "Студент" —
"Дисциплина") требует создания промежуточной сущности (например,
"Оценка")? Как эта промежуточная сущность отображается в 1С?
Этап 3. Совместное структурирование знаний (40 минут)

Деятельность преподавателя: Модерация. Последовательно заслушивает отчеты групп,
задавая уточняющие вопросы. На доске формируется цепочка: Предметная область →
Концептуальная модель данных (IDEF1) → Логическая модель (нормализованные таблицы)
→ Физическая модель (объекты 1С: справочники, документы, регистры).

Деятельность студентов: Представляют результаты. Дискутируют, дополняют.

Ключевые моменты, которые должны быть зафиксированы (итог дискуссии):
1. Информационная база (ИБ) — это единая, централизованная совокупность данных,
организованная по определенным правилам и используемая для решения задач
управления в ИС. Способы организации: Выбор архитектуры (файл-сервер, клиентсервер) определяет, как физически хранятся и обрабатываются данные, что критически
влияет на работу системы в целом.
2. Моделирование данных — это процесс создания формализованного описания
информации, используемой в предметной области, в виде модели данных. Цель —
обеспечить непротиворечивость, отсутствие дублирования, целостность и
эффективный доступ. Без этой модели ИС обречена на проблемы с качеством данных.
3. Метод IDEF1 (ICAM DEFinition for Information Modeling) — это методология,
предназначенная для анализа и проектирования структур данных в рамках их
семантики (смысла) в предметной области. Она фокусируется на том, какие данные
нужны, а не на том, как они будут физически храниться.

Основные объекты: Сущности (прямоугольники), Связи (линии с указанием
мощности), Атрибуты (списки внутри сущностей). Ключевое правило: Каждая
сущность должна иметь уникальный идентификатор (первичный ключ).

Мощность связей (Cardinality): Определяет, сколько экземпляров одной
сущности связано с экземпляром другой (0,1, 1, 1..N, 0..N и т.д.).
4. Отображение модели данных в ИС (на примере 1С):

Независимая сущность (например, "Контрагент", "Номенклатура")
→ Справочник.

Событие/Документ (например, "Приходная накладная", "Заказ") → Документ.

Атрибут сущности → Реквизит справочника или документа.

Связь 1:N (например, "Заказ" имеет несколько "Позиций") → Табличная
часть документа (для связи с документом) или подчиненный справочник (если
связь между справочниками).

Связь M:N (например, "Студент — Дисциплина") → Создается промежуточная
сущность (например, "Зачетная книжка" или "Оценка"), которая в 1С
реализуется как Регистр сведений с двумя измерениями (Студент, Дисциплина)
и ресурсом (Оценка).
5. Связь с функциональными моделями (IDEF0): Выходы (Output) одних функций
становятся Входами (Input) или Управлениями (Control) для других. Эти потоки данных
(стрелки в IDEF0) как раз и являются данными, структура которых описывается в
IDEF1. Таким образом, IDEF0 и IDEF1 — это взаимодополняющие методологии, дающие
полную картину: процессы и данные.
Этап 4. Рефлексия и выводы (5 минут)

Возвращаемся к кейсу с "Строймашем". Студентам предлагается предложить план
исправления ситуации.

Примерный итог: «Проблема возникла из-за отсутствия единой модели данных (IDEF1).
Чтобы её исправить, нужно: 1) Выделить ключевые сущности (Контрагент, Товар, Договор,
Заказ). 2) Определить их атрибуты и правила идентификации (например, идентификация
контрагента по ИНН). 3) Спроектировать связи между ними. 4) На основе этой модели в CRM
(или 1С) создать единый справочник "Контрагенты", к которому будут обращаться все
отделы. Новые данные будут вводиться один раз, а использоваться — многократно. Это и есть
результат грамотного информационного моделирования».

Анонс следующей темы: «Мы освоили два ключевых вида моделирования — функциональное
и информационное. Теперь посмотрим, как на их основе создается главный документ,
связывающий бизнес и ИТ — Техническое задание на разработку ИС».
Конспект лекции 12 (Часть 2). Методологии моделирования предметной области. Часть 2
(Информационное моделирование и данные)
Введение (Проблематизация)
Данные — это кровь информационной системы. Если функциональные модели (IDEF0) описывают
«мышцы» и «процессы» бизнеса, то информационные модели описывают «кровь» — её состав,
структуру и правила циркуляции. Плохо спроектированная структура данных приводит к «тромбам»
(дублированию), «кровоизлияниям» (потере целостности) и в итоге — к «смерти» системы от
неэффективности. Как спроектировать идеальную «кровеносную систему» для ИС? Ответ —
информационное моделирование.
4. Информационная база и способы её организации

Информационная база (ИБ) — это систематизированная совокупность данных, относящихся к
определённой предметной области, организованная по установленным правилам и
предназначенная для хранения, накопления и обработки в целях информационного
обеспечения деятельности.

Способы организации ИБ (архитектурные подходы):
1. Файл-серверная: Данные хранятся в файле на общем сетевом ресурсе. Все клиентские
станции работают с этим файлом напрямую. Недостатки: низкая производительность и
надёжность при множественном доступе, высокий риск повреждения данных.
2. Клиент-серверная (2-уровневая): Данные хранятся на сервере баз данных (СУБД,
например, MS SQL, PostgreSQL). Клиентское приложение (1С) отправляет запросы
серверу, который обрабатывает их и возвращает результат. Преимущества: высокая
производительность, безопасность, целостность данных.
3. 3-уровневая архитектура: Добавляется отдельный сервер приложений, на котором
выполняется бизнес-логика. Клиенты общаются с сервером приложений, а тот — с
сервером БД. Преимущества: масштабируемость, централизация логики.
4. Распределённая: Данные размещены на нескольких физически разнесённых серверах.
Используется в крупных географически распределённых компаниях.
Выбор архитектуры — ключевое проектное решение, влияющее на стоимость,
производительность и сопровождение ИС.
5. Моделирование данных
Это процесс создания формального описания данных, их структуры, ограничений и взаимосвязей.
Цель — создать непротиворечивую, не избыточную, целостную модель, которая точно отражает
информационные потребности бизнеса и может быть эффективно реализована в СУБД.
Уровни моделирования:

Концептуальная модель (IDEF1): Описывает данные с точки зрения предметной области, без
привязки к способу хранения. Язык общения с бизнес-пользователями.

Логическая модель: Детализированная модель, часто в форме нормализованных
таблиц (3NF). Определяет таблицы, столбцы, типы данных, первичные и внешние ключи. Ещё
не привязана к конкретной СУБД.

Физическая модель: Модель, оптимизированная для конкретной СУБД. Включает индексы,
секции, стратегии хранения.
6. Метод IDEF1
Методология, предназначенная для построения концептуальной модели данных.

Основные элементы:
o
Сущность (Entity): Представляет собой множество реальных или абстрактных объектов
(людей, событий, состояний), обладающих общими атрибутами или характеристиками.
Изображается прямоугольником. Примеры: СОТРУДНИК, ЗАКАЗ, ТОВАР.
o
Связь (Relationship): Представляет собой логическое отношение между сущностями.
Изображается линией, соединяющей сущности. Мощность связи
(Cardinality) указывает, сколько экземпляров одной сущности связано с экземпляром
другой. Обозначения: «1» (ровно один), «M» («Many» — много), «N» (неопределённое
количество), «P» (один или более), «Z» (ноль или один).

1:1 (Один к одному)

1:N (Один ко многим) — наиболее распространённая.

M:N (Многие ко многим) — требует преобразования через промежуточную
сущность.
o
Атрибут (Attribute): Именованная характеристика сущности. Задаёт, какие данные
должны храниться об экземпляре сущности. В IDEF1 атрибуты часто перечисляются
внутри прямоугольника сущности.
o
Ключ (Key): Атрибут или набор атрибутов, однозначно идентифицирующий экземпляр
сущности. Первичный ключ (Primary Key) обозначается подчеркиванием в списке
атрибутов.
7. Отображение модели данных в ИС (на примере 1С:Предприятие)
Концептуальная модель IDEF1 является основой для проектирования метаданных в 1С.

Сущность типа «Объект» (справочная информация) → Справочник. Пример: Сущность
КОНТРАГЕНТ → Справочник «Контрагенты».

Сущность типа «Событие» или «Документ» → Документ. Пример: Сущность ПРИХОДНАЯ
НАКЛАДНАЯ → Документ «ПриходнаяНакладная».

Атрибут сущности → Реквизит справочника или документа.

Связь 1:N между сущностями-документами → может быть реализована через связь по
реквизиту или через табличную часть. Пример: Связь «ЗАКАЗ (1) — содержит —
ПОЗИЦИЯ_ЗАКАЗА (N)» реализуется как документ «ЗаказПокупателя» с табличной частью
«Товары».

Связь M:N между сущностями-справочниками → создаётся промежуточная сущность,
которая в 1С реализуется как Регистр сведений. Пример: Связь «СТУДЕНТ (M) — изучает —
ДИСЦИПЛИНА (N)» требует промежуточной сущности «ОЦЕНКА» с атрибутами «Студент»,
«Дисциплина», «Оценка». В 1С это будет регистр сведений «Оценки» с измерениями
«Студент» и «Дисциплина» и ресурсом «Оценка».

Агрегированные данные, итоги → Регистры накопления (остатки и обороты).
Заключение
Информационное моделирование с использованием методологии IDEF1 — это не абстрактное
упражнение, а практическая необходимость для создания устойчивых, масштабируемых и
сопровождаемых информационных систем. Оно позволяет говорить с бизнесом на языке сущностей
и связей, а с разработчиками — на языке таблиц, ключей и регистров. Модель данных, созданная на
ранних этапах проекта, становится страховкой от самых дорогих и болезненных ошибок, связанных с
качеством информации, и фундаментом, на котором строится вся функциональность ИС.
КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ТЕМЕ 12 (ЧАСТЬ 2)
1. Проблемный вопрос: В компании существует процесс «Управление проектами». Аналитик
построил функциональную модель (IDEF0), где одной из функций является «Назначить
исполнителя на задачу». Выходом этой функции является информация «Назначение: ПроектЗадача-Исполнитель-Срок». Как, используя метод IDEF1, спроектировать структуру данных
для хранения этой информации? Выделите сущности, связи между ними и их атрибуты.
2. Для предметной области «Библиотека» выделите сущности «КНИГА», «ЧИТАТЕЛЬ», «ВЫДАЧА».
Определите связи между ними и укажите мощность этих связей. Как связь «Многие ко
многим» между «КНИГА» и «ЧИТАТЕЛЬ» должна быть разрешена в модели?
3. Объясните, почему связь M:N (многие-ко-многим) между сущностями не может быть
напрямую реализована в реляционной базе данных (и, как следствие, в метаданных 1С)?
Какой механизм в 1С (какой тип объекта метаданных) предназначен для реализации таких
связей?
4. В чём заключается принципиальное различие между файл-серверной и клиентсерверной архитектурой информационной базы с точки зрения обработки запросов к
данным? Почему для работы группы из 20 и более пользователей не рекомендуется
использовать файл-серверный вариант?
5. Сопоставьте элементы концептуальной модели данных (IDEF1) и объекты метаданных
платформы 1С. Заполните таблицу: для элемента IDEF1 «Сущность "Договор" с атрибутами:
Номер, Дата, Сумма» укажите, в какой объект метаданных 1С она преобразуется, и как будут
называться её атрибуты в этом объекте.
Домашнее задание для студентов:
1. Изучить конспект лекции 12 (Часть 2).
2. Подготовить письменные ответы на 5 контрольных вопросов.
3. (Дополнительно — практикум) Выполните информационное моделирование для фрагмента
предметной области «Заказ билетов в кино»:
o
Выделите не менее четырёх сущностей (например, Фильм, Сеанс, Зал, Бронирование).
o
Для каждой сущности укажите 3-4 ключевых атрибута, выделите первичный ключ.
o
Определите связи между сущностями и укажите их мощность.
o
Нарисуйте схему IDEF1 (от руки или в любом графическом редакторе).
o
Сделайте предположение: какие объекты метаданных 1С (справочники, документы,
регистры) понадобились бы для реализации этой модели?