Виды предметных областей бизнес

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

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

Олегу нужно спроектировать систему для хранения и передачи результатов клинических исследований внутри компании N.

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

Первым делом Олег отправляется изучать техническое задание.
И не понимает ни слова.
Более того, Олегу говорят, что через неделю он летит в командировку в лабораторию к клиенту, собирать данные о пользователях. Но Олег не понимает, что собирать, потому что не понимает совсем ничего.

Олега начинают одолевать неприятные мысли о том, что он не очень-то и хорош как дизайнер.

От монолитных моделей предметной области — к модульным

Что все его работы — мусор, и сам он тоже мусор и все тлен.

Пока Олег прокрастинирует и самобичуется, попробуем разобраться, почему так вышло.

Дело в том, что сложно понять дизайн-задачу, если не понимаешь, о чем проект.

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

Но бывают исключения — проекты со сложной предметной областью.

Что такое предметная область

Предметная область — это специфическая группа знаний.

Помните, в школе у нас были разные предметы: химия, физика, биология?

Это — разные предметные области и учителя давали нам базовое понимание каждой из них.

Для UX-дизайнера предметная область — это контекст, в котором существует (или будет существовать) система и пользовательский интерфейс.

Компоненты предметной области

Для удобства можно разделить предметную область на три компонента:

• специфичные термины и язык людей, которые живут/работают в предметной области,
• важные объекты, существенные единицы предметной области,
• то, как эти единицы вязаны и взаимодействуют.

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

Чем глубже вы понимаете контекст проекта, тем эффективнее вы работаете на начальных этапах.

Как разобраться в предметной области

В знании предметной области я условно выделяю 4 этапа (или, если угодно, состояния поектировщика):

Сейчас Олег находится в состоянии “Я ничего не знаю”.
На то, чтобы максимально преисполниться и достичь состояния “Я эксперт” у Олега могут уйти годы. Как и у любого из нас.

Декомпозиция предметной области (на примере магазина)

Поэтому последний этап мы опустим и поговорим о том, как достичь состояний “Я знаю, чего я не знаю” и “Я кое-что знаю”.

И первый шаг на пути к просветлению — домашнее чтение.

Шаг 1: домашнее чтение

Итак, Олег берет себя в руки и решает перебраться из состояния «Я ничего не знаю» в «Я знаю, чего я не знаю». Он начинает читать.

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

Олег остается один на один с тонной новой информации и разрозненных терминов.
Яснее не стало.

Олег предполагал, что путь будет прост.

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

Как же из этой тонны информации выбрать то, что важно знать для проекта?

Вам нужно знать ровно столько, сколько вам нужно знать.

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

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

Какие вопросы о предметной области нужно сформулировать

Как мы уже обсудили, предметная область состоит из 3 компонентов: словарь, сущности и связи между ними.

Для каждого компонента можно сформулировать вопросы и попытаться на них ответить (см. схему ниже).

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

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

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

В случае изучения предметной области помогают 2 артефакта:

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

Именно этими артефактами решает заняться Олег.
Он создает таблицу — словарь, куда вносит непонятные слова и предполагает их смысл.

Он также предполагает, что основные сущности в предметной области — это лаборант, препарат и само клиническое исследование. Возможно, есть что-то еще.
Олег набрасывает схему связей между сущностями.

На основе своих артефактов Олег может составить вопросы.

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

С домашним чтением покончено, у Олега куча вопросов.
Он знает, чего он не знает.

Что же с этими вопросами делать дальше? Самое время обратиться к экспертам.

Шаг 2: Общение с экспертами

Немного разобравшись с базовыми понятиями и сформулировав вопросы, Олег отправляется выяснять тонкие детали к экспертам.

Почему нельзя сразу начать с экспертов, не тратя время на домашнее чтение?
Эксперты — занятые люди. У них полно своих дел и работы.
Лучше заранее разобраться в базовых вещах и сформулировать конкретные вопросы. Это позволит предметно и по существу общаться с экспертами, не тратя их время на объяснение основ.

Кто такие эксперты и где их взять?

Эксперты — люди, которые разбираются в предметной области и/или в ней работают. Они уже прошли минимум 2 этапа познания и находятся в состоянии “Я кое-что знаю” или “Я эксперт”.

Ближайшими в зоне досягаемости экспертами могут выступать коллеги на проекте.
Например, менеджер/руководитель проекта или бизнес-аналитик, которые уже давно варятся в этой кухне.
Если до вас на проекте работали дизайнеры, они могли немного разобраться и оставить полезные документы.
Часть сформулированных вопросов и гипотез можно обсудить с коллегами.

Безусловно, экспертами являются лица, заинтересованные в реализации проекта:

1. Заказчик. Он — точка входа для вас и связующее звено с теми, кто может вам помочь. Бывает, что заказчик и сам является экспертом.
2. Пользователи. Часто в сложных проектах пользователи являются экспертами в предметной области. В случае Олега лаборанты будут стопроцентными экспертами в области клинических исследований.

Для эффективного общения с заказчиком/пользователями можно использовать интервью и наблюдение.

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

Артефакты обновлены.
Словарь содержит верное объяснение терминов, в нем много деталей о разных понятиях, присущих компании N.

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

После общения с экспертами, Олег проверил все свои гипотезы, расширил знания и перешел из состояния “Я знаю, чего я не знаю” в состоянию “Я кое-что знаю”.
Теперь Олег лучше разбирается в клинических исследованиях. Он понимает, о чем его просят и может придумать эффективное решение пользовательских задач.

Безусловно, со временем Олег еще лучше разберется в предметной области своего проекта и его артефакты дополнятся деталями.

Вывод

Попадая на проект со сложной (даже немножко) предметной областью, будьте как Олег.
Исследуйте предметную область в два простых шага:

1. Домашнее чтение. Это позволит сформировать общее представление о терминах, ролях и процессах; сформулировать гипотезы и вопросы к экспертам
2. Общение с экспертами. Это позволит прояснить детали, проверить гипотезы, и дополнить артефакты: словарь терминов и модель связей сущностей.

Немного полезных советов:

• Будьте проактивны
• Помните: вы не эксперт
• Сфокусируйтесь на компонентах предметной области (словарь, сущности, связи)
• Не бойтесь задавать вопросы
• Сначала пообщайтесь с коллегами, затем с экспертами
• Пишите заметки и проверяйте их
• Документируйте

Если статья показалась интересной — дайте знать аплодисментами

Больше о проектировании интерфейсов и мемы по средам можно найти в телеграм-канале Поясни за UX

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

Перечень предметных областей

1. Построение системы мотивации персонала в организации.

2. Повышение эффективности труда персонала.

3. Совершенствование системы найма персонала на предприятии.

4. Формирование и развитие принципов организационного (корпоративного) поведения.

5. Формирование системы безопасности труда и охраны здоровья персонала организации.

6. Планирование и анализ эффективности издержек на персонал.

7. Бюджетирование и бизнес-планирование кадровых служб.

8. Формирование и реализация кадровой политики организации.

9. Организация внутрифирменного обучения персонала на предприятии.

10. Совершенствование системы адаптации персонала на предприятии.

11. Совершенствование системы аттестации и оценки персонала на предприятии.

12. Совершенствование методов управления персоналом.

13. Отбор персонала как современная кадровая технология.

14. Организационно-нормативное обеспечение управления персоналом.

15. Информационное обеспечение деятельности управления персоналом.

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

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

18. Управление персоналом в малом бизнесе.

19. Реализация инноваций в кадровой работе.

20. Управление персоналом на разных стадиях жизненного цикла организации.

21. Организация работы с кадровыми документами (на примере конкретного предприятия).

22. Автоматизация системы управления персоналом ОАО «УМПО»

23. Формирование процедур оценки и аттестации персонала (оценка по компетенциям) ОАО «УМПО» (методы 360, асессмент-центр, тесты способностей, экспертный метод, психодиагностика).

24. Разработка (вынесение на аутсорсинг) тестов оценки профессиональных компетенций ОАО «УМПО».

25. Повышение лояльности и приверженности кадрового резерва ОАО «УМПО».

26. Развитие кадрового резерва в производственной компании ОАО «УМПО» (коучинг, разработка и оптимизация индивидуальных планов развития, обратная связь, мониторинг).

27. Повышение лояльности и приверженности кадрового резерва ОАО «УМПО».

28. PR-деятельность в управлении персоналом ОАО «УМПО».

29. Внедрение форм электронного обучения в процессе приема на работу ОАО «УМПО».

30. Автоматизация систем обучения и развития персонала ОАО «УМПО».

31. Построение работы по обучению персонала в рамках концепции LLL ОАО «УМПО».

32. Построение оптимальных образовательных маршрутов для работников ОАО «УМПО».

Приложение 5

Группа УП-302

Группа УП-303

Приложение 6

Источник: poisk-ru.ru

Понятие предметной области. Понятие предметной области

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

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

Скачать 67.21 Kb.

Понятие предметной области.

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

Предметная область — это совокупность реаль­ных объектов (сущностей), которые представляют интерес для пользователей.

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

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

Например, объект — клиент банка.

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

Анализ предметной области целесообразно разбить на три фазы:

1) анализ концептуальных требований и информационных потребностей;

2) выявление информационных объектов и связей между ними;

3) построение концептуальной модели предметной области и проектирование концептуальной схемы БД.

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

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

Выявление информационных объектов и связей между ними.

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

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

Типы связей.

Все информационные объекты предметной области связаны между собой.

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

а) один к одному (1:1);

б) один ко многим (1:М);

в) многие ко многим (М:М).

Рассмотрим эти типы связей на примере.

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

Рис. 1. Графическое изображение реального отношения 1:1

При связи один ко многим (1 :М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рис. .2.

Рис. 2. Графическое изображение реального отношения 1:М

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На рис..3 графически представлено указанное соответствие.

Рис. 3. Графическое изображение реального отношения М:М

Один студент обучается у многих преподавателей, один преподаватель обучает многих студентов.

Структурная модель предметной области

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

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

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

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

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

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

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

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

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

В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне ( определении требований ), на концептуальном уровне ( спецификации требований ) и внутреннем уровне ( реализации требований ). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств.

На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации.

Объектная структура

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

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

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

Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах.

Функциональная структура

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

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

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

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

Структура управления

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

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

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

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

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

Организационная структура

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

Техническая структура

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

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

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

На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.

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

Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач.

Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

Функция – совокупность операций, сгруппированных по определенному признаку.

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

Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя.

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

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

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