Category Archives: Проектирование

Декомпозиция подсистемы организации на структурные элементы

Структурный анализ организации. Методология и этапы структурного анализа

Структура системы

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

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

  • выявление реальных целей системы;
  • выяснение альтернативных путей достижения этих целей;
  • достижение взаимосвязей между элементами;
  • получение возможности моделирования системы.

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

Рисунок «Разбиение организации на структурные подсистемы»
Разбиение организации на структурные подсистемы

Введем несколько определений:

  • Организационная структура — это структура, элементами которой являются подразделения организации разного уровня иерархии, а отношениями — отношения входимости и руководства-подчинения.
  • Производственная структура — часть организации, выполняющая задачи оперативного управления производством и обеспечивающая выпуск продукции и/или предоставление услуг.
  • Функциональная структура — структура, элементами которой являются функции, реализуемые подразделениями предприятия, а отношениями — связи, обеспечивающие передачу между элементами предметов труда.
  • Информационная структура — совокупность центров производства, сбора, анализа и распространения информационных потоков.
  • Структура выходов организации — совокупность материальной и нематериальной продукции, являющейся результатом деятельности организации и поставляемой ею во внешнюю (по отношению к ней) среду.
  • Структура входов организации — совокупность материальной и нематериальной продукции, используемой для осуществления деятельности организации.
  • Юридическая структура — совокупность бизнес-единиц с множеством организационных, административно-правовых отношений между ними, а также отношений собственности и контроля.
  • Финансово-экономическая (финансовая) структура — совокупность центров учета с финансовыми потоками между ними.
  • Штатная структура — состав подразделений и перечень должностей, размеры должностных окладов и фонд заработной платы.
  • Социальная структура — разбиение персонала организации на группы по социальным показателям.
  • Территориальная структура — совокупность мест расположения элементов организационной структуры.

Структурный анализ

Структурный анализ является методологической разновидностью системного анализа. Он был разработан в 60-70-х годах XX века Дугласом Т. Россом в виде методологии SADT (Structured Analysis and Design Technique)— технология структурного анализа и проектирования.
В основе структурного анализа лежит выявление структуры как относительно устойчивой совокупности отношений, признание методологического примата отношений над элементами в системе, частичное отвлечение от развития объектов.

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

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

Для такого подхода характерны:

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

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

Декомпозиция (см. рисунок) является условным приемом, позволяющим представить систему в виде, удобном для восприятия, и оценить ее сложность. В результате декомпозиции подсистемы по определенным признакам выделяются отдельные структурные элементы и связи между ними. Декомпозиция служит средством, позволяющим избежать затруднений в понимании системы. Глубина декомпозиции определяется сложностью и размерностью системы, а также целями моделирования.

Рисунок «Декомпозиция подсистемы организации на структурные элементы»
Декомпозиция подсистемы организации на структурные элементы

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

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

Рисунок «Характеристики структурных элементов и связей»
Характеристики структурных элементов и связей

Методология структурного анализа

Структурный анализ как совокупность методов моделирования сложных систем вследствие большой размерности решаемых задач должен опираться на мощные средства компьютерной поддержки, обеспечивающей автоматизацию труда системных аналитиков. Такими средствами являются CASE-системы (Computer Aided Software Engineering).
Архитектура большинства CASE-систем основана на парадигме «методология — модель — нотация — средства» (см. рисунок).
Методология структурного анализа представляет методы и средства для исследования структуры и деятельности организации. Она определяет основные принципы и приемы использования моделей.
Модель — это совокупность символов (математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
Нотации — система условных обозначений, принятая в конкретной модели.
Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.

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

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

Рисунок «Архитектура CASE-систем»
Архитектура CASE-систем

Среди многообразия средств, предусмотренных для проведения структурного анализа, наиболее часто и эффективно применяются:

  • DFD(Data Flow Diagrams)—диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;
  • STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени;
  • ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера;
  • Структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;
  • FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;
  • SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;
  • Семейство IDEF (Integration Definition for Function Modeling).

Семейство IDEF:

  • IDEFO — методология функционального моделирования, являющаяся составной частью SADT и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций;
  • IDEF1 — методология анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия;
  • IDEF1X — методология информационного моделирования, основанная на концепции «сущность-связь», предложенной Ченом. Применяется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы и обеспечивающий универсальное представление структуры данных в рамках предприятия, независимое от конечной реализации базы данных и аппаратной платформы;
  • IDEF3 — методология документирования технологических процессов, предприятия, позволяющая моделировать их сценарии посредством описания последовательности изменений свойств объекта в рамках рассматриваемого процесса;
  • IDEF4 — методология объектно-ориентированного проектирования для поддержки проектов, связанных с объектно-ориентированными реализациями;
  • IDEF5 — методология, обеспечивающая наглядное представление данных, полученных в результате обработки онтологических запросов, в простой, графической форме.

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

Понятия модели и моделирования

Создаваемая модель должна давать ответ на следующие вопросы:

  • Кто из сотрудников организации должен выполнять конкретные функции?
  • При каких условиях нужно выполнять функцию?
  • Что должен сделать сотрудник в рамках данной функции?
  • Каким образом следует ее выполнять?
  • Какие ресурсы при этом необходимы?
  • Каковы результаты выполнения функции?
  • Какие информационные средства нужны?
  • Каким образом все это согласовать?
  • Как все это можно осуществить наиболее эффективно?
  • Как можно изменить или построить бизнес-процесс?
  • Как снизить риск и повысить эффективность изменений?

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

Для модели в общем случае характерны четыре свойства:

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

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

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

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

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

К важнейшим признакам, по которым проводится классификация моделей, относятся:

  1. закон функционирования и характерные особенности выражения свойств и отношений оригинала;
  2. основания для преобразования свойств и отношений модели в свойства и отношения оригинала.

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

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

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

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

Знаковые (символические) модели выражают свойства моделируемой системы с помощью условных знаков или символов. Образно-знаковые модели совмещают в себе признаки образных и знаковых моделей. Подавляющее большинство моделей ARIS являются образно-знаковыми.

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

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

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

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

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

К нотации модели предъявляются следующие основные требования:

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

Рисунок «Обозначение объектов в диаграмме структуры знаний ARIS»
Обозначение объектов в диаграмме структуры знаний ARIS

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

Нотация графической модели предполагает наличие:

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

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

Этапы структурного анализа

Проведение структурного анализа организации предполагает нескольких этапов:

  • построение иерархии целей оптимизации деятельности организации;
  • выбор методологии;
  • выбор моделей;
  • анализ деятельности организации;
  • разработка моделей в соответствии с иерархией целей;
  • оптимизация моделей;
  • реорганизация деятельности.

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

Основными принципами проведения изучения деятельности организации являются:

  • целенаправленность;
  • комплексность;
  • планомерность;
  • организационно-методическая целостность.

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

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

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

Характерной проблемой является наличие неофициальных отношений подчинения.

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

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

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

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

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

Формирование данной структуры — один из наиболее приоритетных этапов моделирования.
Задачи, связанные с созданием и внедрением информационных технологий, требуют детального анализа существующих информационных систем — их структуры и участия в бизнес-процессах организации. В связи с этим, необходимо заранее, до детального моделирования процессов, сформировать структурированный перечень всех интересующих информационных систем, а также оценить их внутреннюю структуру (прежде всего — набор основных модулей и экранных форм).
Таким образом, для того, чтобы построить адекватную и востребованную модель организации необходимо уже на первоначальных этапах моделирования задуматься о выделении и фиксации всех основополагающих структур. Грамотное их формирование обеспечивает качественный «задел» на будущее. Это позволит продуманно и прогнозируемо разработать все новые детальные модели, имеющие определенное место в общей модели структуры организации и соответствующие целям анализа отдельных элементов и организации в целом.
От качества и количества информации, полученной при изучении организации, зависит, насколько адекватной будет построенная модель.

Разработка моделей деятельности организации включает несколько этапов:

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

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

Функционально-ориентированная (иерархическая) организация

Системный анализ деятельности организации. Виды организаций в ARIS

Системный анализ деятельности организации. Виды организаций в ARIS

Понятие организации

Международный стандарт ИСО 9000:2000 определяет организацию как группу работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений.
Организация может быть корпоративной, государственной или частной. Можно дать и другое определение: организация — это систематизированное, сознательное объединение действий людей, преследующих достижение конкретных целей.
Понятие «организация» раскрывает приведенная на рисунке модель технических терминов ARIS (Architecture of Integrated Information Systems — архитектура интегрированных информационных систем).

Рисунок «Виды организаций, представленные с помощью модели технических терминов ARIS»
Виды организаций, представленные с помощью модели технических терминов ARIS

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

С точки зрения управления главными заинтересованными сторонами являются:

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

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

Любая организация — многофункциональна. К ее основным функциям относятся:

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

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

Функционально-ориентированная (иерархическая) организация

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

Рисунок «Функционально-ориентированная (иерархическая) организация»
Функционально-ориентированная (иерархическая) организация

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

Функционально-ориентированные организации обладают рядом недостатков, основными из которых являются:

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

Альтернативой строго функциональной структуре является процессно-ориентированная структура.

Процессно-ориентированная организация

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

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

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

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

Рисунок «Понятие «процесс», представленное с помощью модели технических терминов ARIS»
Понятие «процесс», представленное с помощью модели технических терминов ARIS

Понятие системы

Любая организация является сложной социально-технической системой. Термин «система», употребляемый в современной практике, имеет множество значений и смысловых нюансов. Это приводит к необходимости выделить те значения, которые имеют непосредственное отношение к системному анализу деятельности организации. Далее приведены три определения, которые представляются наиболее удачными.
Первое из них дано в Международном стандарте ИСО 9000:2000 «Системы менеджмента качества. Основные положения и словарь».

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

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

Для системы характерны следующие основные свойства:

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

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

Понятие «границы» в целом ряде случаев весьма условно, и при моделировании необходимо четко определить, где кончается система, а где начинается среда.

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

Рисунок «Связи системы-организации с внешней средой»
Связи системы-организации с внешней средой

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

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

  • стратегические и тактические цели;
  • долгосрочные (выполнение через несколько лет) и краткосрочные (выполнение через год и ранее) цели;
  • производственные, финансовые, социальные цели, цели повышения качества продукции и т.п.

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

Рисунок «Цели организации, представленные в виде диаграммы целей ARIS»
Цели организации, представленные в виде диаграммы целей ARIS

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

Системный подход

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

Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:

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

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

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

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

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

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

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

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

Системный подход применяется для решения различного рода сложных задач, в число которых входят:

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

Качество данных

80 % времени я трачу на очистку данных. Качественные данные всегда выигрывают у качественных моделей.
Томсон Нгуен

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

Специалистам‑аналитикам нужны правильные данные, собранные правильным образом и в правильной форме, в правильном месте, в правильное время. (Они просят совсем не много.) Если какое‑то из этих требований не выполнено или выполнено недостаточно хорошо, у аналитиков сужается круг вопросов, на которые они способны дать ответ, а также снижается качество выводов, которые они могут сделать на основании данных.
Continue reading→

IndustryPrint Process Modeler

Моделирование BPMN. IndustryPrint Process Modeler. BluePrint

С IndustryPrint Process Modeler вы можете разработать модели бизнес-процессов BPMN. Формат хранения XML.
IndustryPrints имеют иерархическую структуру. На верхнем уровне, IndustryPrint состоит из групп процессов, которые представляют собой наборы функционально связанных процессов.

Каждая группа процессов состоит из одного или нескольких процессов. Процесс состоит из графической модели процесса, а задачи являются основными строительными блоками. Три уровня IndustryPrints (группового процесса, процесса и задачи), показаны ниже.
IndustryPrint Process Modeler
Модели процессов могут быть использованы для различных целей, таких как улучшение процесса и модернизации, activity-based costing, анализа проблем и оценки эффективности. IndustryPrint Process Modeler использует метод моделирования, основанный на стандарт, называемый Business Process Modeling Notation (BPMN) с небольшим набором основных понятий: задачи, подпроцесса, событие, шлюз, Swimlane, соединяющего объекта, объекта данных, группы и аннотации.

СКАЧАТЬ Моделирование BPMN. IndustryPrint Process Modeler. BluePrint

Scrum Framework

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Руководство по скраму (Scrum) — К.Швабер и Дж.Сазерленд

Цель Руководства по Скраму

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

Общее Описание Скрама

Скрам (Scrum – потасовка, драка за мяч в регби) – это подход, в рамках которого возможно решить сложные адаптивные проблемы, и в то же время продуктивно и с применением творческого подхода разработать продукт наивысшего качества. Скрам является:

  • Легким
  • Простым в понимании
  • Чрезвычайно сложным в овладении

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

Скрам Подход (Scrum Framework)

Скрам состоит из Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles), а также мероприятий (events), артефактов (artifacts) и правил (rules). Каждый компонент Скрама имеет свое предназначение и является ключевым для успеха и использования Скрама.
Различные стратегии использования Скрама изменяются, и их описание выходит за пределы данного руководства.
Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Скрама прописаны в данном документе.

Scrum FrameworkТеория Скрама

Скрам основывается на теории управления эмпирическими процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит с опытом и принятием решений на основании того, что является известным. Скрам использует итеративный, инкрементальный подход для оптимизации прогнозируемости и управления рисками.
В основе управления эмпирическими процессами лежат три главных принципа: прозрачность (transparency), проверка (inspection) и адаптация (adaptation).

Прозрачность

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

  • Все участники процесса должны пользоваться общей терминологией, относящейся к процессу;
  • Исполняющие работу и оценивающие ее результат в виде продукта должны иметь единое определение “Готовности”1.

Проверка

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

Адаптация

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

Согласно подразделу данного документа Мероприятия Скрама, Скрам предписывает четыре формальные возможности для проверки и адаптации.

  • Планирование Спринта (Sprint Planning Meeting)
  • Ежедневный Скрам (Daily Scrum)
  • Обзор Спринта (Sprint Review Meeting)
  • Ретроспектива Спринта (Sprint Retrospective)

Скрам

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

Скрам Команда

Скрам Команда состоит из

  • Владельца Продукта (Product Owner),
  • Команды Разработчиков (Development Team) и
  • Скрам Мастера (Scrum Master).

Команда Scrum

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

Владелец Продукта

Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.
Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту (Product Backlog). Управление Журналом Продукта включает в себя:

  • Четкое определение элементов Журнала Продукта;
  • Упорядочение элементов Журнала Продукта для оптимизации достижения целей и поставленных задач;
  • Ответственность за ценность работы, исполняемой Командой Разработчиков;
  • Обеспечение доступности, прозрачности и понятности Журнала Продукта, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время.
  • Ответственность за понимание Командой Разработчиков требований Журнала Продукта на надлежащем уровне.

Владелец Продукта может либо сам выполнять вышеперечисленные функции, либо предоставить их выполнение членам Команды Разработчиков. Однако подотчетным считается именно Владелец Продукта.

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

Команда Разработчиков

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

Командам Разработчиков присущи следующие характеристики:

  • Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности;
  • Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта;
  • Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений;
  • Отдельные члены Команды Разработчиков могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым.
  • У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа.

Размер Команды Разработчиков

Оптимальный размер Команды Разработчиков должен быть довольно небольшим, чтобы Команда оставалась простой в управлении и в то же время довольно большим, чтобы выполнить значимый объем работы. Если в Команде Разработчиков менее трех человек, взаимодействие уменьшается, что приводит к снижению продуктивности. Кроме того, на определенном этапе Спринта у небольшой Команды может почувствоваться недостаток необходимых знаний, вследствие чего она будет не в состоянии завершить работу над потенциально готовым к выпуску Инкрементом продукта. Если же в Команде более девяти человек, нужно прилагать больше усилий для координации их работы. Большие Команды Разработчиков создают слишком много сложностей для управления эмпирическим процессом. Роли Владельца Продукта и Скрам Мастера не учитываются при подсчете размера Команды Разработчиков за исключением случаев, когда они выполняют работу из Журнала Спринта.

Скрам Мастер

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

Обязанности Скрам Мастера по отношению к Владельцу Продукта

Скрам Мастер во многом помогает Владельцу Продукта, в частности:

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

Обязанности Скрам Мастера по отношению к Команде Разработчиков

Скрам Мастер во многом помогает Команде Разработчиков, в частности:

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

Обязанности Скрам Мастера по отношению к Организации

Скрам Мастер во многом помогает организации, в частности:

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

Мероприятия Скрама

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

Мероприятия scrum (скрама)

Спринт

Сердцем Скрама является Спринт, с временными рамками (time-boxes) в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта. Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Спринт состоит из Планирования Спринта, Ежедневных Скрамов, работы по разработке, встрече по Обзору Спринта, а также Ретроспективы Спринта.

Во время Спринта:

  • Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal);
  • Состав Команды Разработчиков и цели по качеству продукта остаются неизменными;
  • Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

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

Отмена Спринта

Спринт можно остановить перед окончанием его временных рамок. Только у Владельца Продукта есть право на то, чтобы остановить Спринт, хотя он может сделать это и под влиянием заинтересованных лиц, Команды Разработчиков или же Скрам Мастера.
Спринт отменяют в том случае, если его цели перестают быть актуальными. Это может произойти вследствие изменения направления работы компании, изменения технологий или рыночных условий. В общем, Спринт нужно отменить, если в силу некоторых обстоятельств в нем уже нет необходимости. Однако, принимая во внимание его короткую продолжительность, отмена редко имеет смысл.
При отмене Спринта все выполненные и “готовые” элементы из Журнала Продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску Инкремент функциональности. Все остальные требования переоцениваются и возвращаются в Журнал Продукта. Работа, проделанная над ними, обесценивается быстро, и поэтому требует пересмотра.
Отмена Спринта требует дополнительных ресурсов, так как все члены Команды должны перегруппироваться при Планировании Спринта и приступить к новому Спринту. Отмена Спринта является для Команды неприятным процессом, однако на деле это происходит довольно редко.

Планирование Спринта

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

  • Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
  • Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

Цель Спринта придает работе Команды Разработчиков некоторую гибкость в отношении разработки функциональности во время Спринта.
Пока Команда работает, эта цель служит для нее ориентиром. Для ее достижения Команда Разработчиков реализовывает функциональность и технологию. Если же работа оказывается сложнее, чем ожидалось, тогда Команда Разработчиков договаривается с Владельцем Продукта об изменении объема Журнала Спринта в текущем Спринте.
Цель Спринта может быть важным этапом на пути к более высокой цели в разработке конечного продукта.

Ежедневные Скрамы

Ежедневные Скрамы – это 15-минутные совещания для Команды Разработчиков с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Это делается для того, чтобы проверить, что нового было сделано со времени проведения прошлого Ежедневного Скрама и спланировать работу, которую можно успеть сделать за следующие 24 часа.
Эти совещания происходят в обусловленном месте в одно и то же время во избежание путаницы. Во время таких совещаний каждый участник Команды Разработчиков рассказывает коллегам о следующем:

  • Что было сделано со времени прошлой встречи?
  • Что планируется сделать до следующей встречи?
  • Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.
Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

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

Обзор Спринта

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

Обзор Спринта включает в себя следующие элементы:

  • Владелец Продукта определяет, что является “готовым”, а что нет;
  • Команда Разработчиков вспоминает, что прошло гладко во время Спринта и с чем возникли трудности, а также то, как она с ними справилась;
  • Команда Разработчиков проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;
  • Владелец Продукта обсуждает состояние Журнала Продукта. Он делает предположения касательно возможной даты окончания проекта, принимая во внимание скорость продвижения работы над ним;
  • Вся Команда принимается за обсуждение того, что делать в дальнейшем, для того чтобы данный Обзор Спринта предоставлял важную входную информацию для последующей встречи по планирования Спринта.

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

Ретроспектива Спринта

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

Целью Ретроспективы Спринта является:

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

Скрам Мастер поощряет Скрам Команду пересмотреть свои процессы разработки в рамках процессов и практик Скрама, чтобы сделать её более эффективной в следующем Спринте. Во время каждой Ретроспективы Спринта Скрам Команда ищет пути улучшения качества разрабатываемого продукта, при необходимости уточняя определение “Готовности”.
До окончания Ретроспективы Скрам Команда должна определить практичные и действенные факторы улучшения процесса работы, которые она реализует в следующем Спринте. Внедрение этих изменений в следующем Спринте как раз и является адаптацией к проверке самой Скрам Команды. Хотя изменения могут быть внесены в любое время, Ретроспектива Спринта является специализированным совещанием, посвященным исключительно проверке и адаптации.

Артефакты Скрама

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

Журнал Продукта

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

Элементы Журнала Продукта с высоким уровнем приоритетности должны быть более понятными и содержать больше деталей, чем менее приоритетные. Более точно можно рассчитать время работы над теми требованиями, которые являются более понятными и содержат больше дополнительной информации. Чем ниже приоритетность, тем меньше деталей. Те требования Журнала Продукта, над которыми Команда Разработчиков будет работать во время текущего Спринта, являются детализированными и разбитыми на части таким образом, что любое из этих требований может быть выполнено и “готово” в рамках одного Спринта. Требования Журнала Продукта, которые можно выполнить и “завершить” в течение одного Спринта считаются “готовыми” и “выполняемыми” для того, чтобы их внесли в план во время следующего Планирования Спринта.
Как только продукт начинает использоваться, его значение возрастает и вызывает ответную реакцию рынка, его Журнал становится более полным и всеобъемлющим. Требования к продукту постоянно изменяются, и поэтому Журнал Продукта – это живой артефакт. Изменения в сфере требований, рыночных условий, технологий и ресурсов приводят также и к изменению Журнала Продукта.

Довольно часто случается так, что над одним продуктом работают несколько Команд. Но всё равно используется только один Журнал Продукта, чтобы определить работу на ближайший период. При этом к элементам Журнала Продукта вводится дополнительный атрибут, позволяющий сгруппировать запросы по Скрам Командам.
Поддержание Журнала Продукта – это деятельность по добавлению деталей, оценок предполагаемых затрат времени, и упорядочивания элементов. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработчиков детализируют требования Журнала Продукта. Во время обработки требования проверяются и пересматриваются. Однако Владелец Продукта в любое время может изменить статус этих требований.

Поддержание Журнала Продукта – это часть деятельности во время Спринта, исполняемой Владельцем Продукта и Командой Разработчиков. Часто Команды Разработчиков владеют знаниями в нужной области и сами могут осуществить обработку требований. Как и когда сделать обработку требований решает только Скрам Команда. Обработка требований обычно занимает не более 10% времени Скрам Команды.
Команда Разработчиков несет всю ответственность за оценку объемов работы. Владелец Продукта может помочь Команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от Команды.

Отслеживание прогресса на пути к Цели

В любое время можно подытожить количество работы, которую осталось проделать для достижения Цели. Владелец Продукта отслеживает оставшееся количество работы, как минимум, для каждого Обзора Спринта. Владелец Продукта сравнивает текущее количество работы с тем, которое оставалось во время предыдущего Обзора Спринта, чтобы оценить прогресс в работе и то, успевает ли Команда достичь Цели в рамках запланированного времени. Эта информация является доступной и открытой для всех заинтересованных лиц.
Скрам не принимает во внимание время, потраченное на работу над требованиями Журнала Продукта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

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

Журнал Спринта

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

Журнал Спринта определяет объем работы, которую Команда Разработчиков должна выполнить, чтобы превратить Журнал Продукта в “готовый” Инкремент. Журнал Спринта визуализирует ту работу, которую Команда Разработчиков считает необходимой для достижения Цели Спринта.
Журнал Спринта это достаточно детализированный план, чтобы прогресс в его воплощении можно было увидеть на каждом Ежедневном Скраме. Команда Разработчиков вносит изменения в Журнал Спринта на протяжении всего Спринта, и, соответственно, Журнал Спринта постоянно изменяется. Такие изменения происходят потому, что в процессе работы Команда Разработчиков узнает все новые и новые детали о работе, которую нужно выполнить для достижения Цели Спринта.

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

Отслеживание прогресса Спринта

В любое время во время Спринта можно подытожить количество работы, оставшейся в Журнале Спринта. Команда Разработчиков отслеживает оставшееся количество работы, как минимум, во время каждого Ежедневного Скрама. Команда Разработчиков ежедневно отслеживает количество оставшейся работы и вероятность достижения Цели Спринта. Благодаря отслеживанию количества оставшейся работы во время Спринта Команда Разработчиков может управлять прогрессом.
Скрам не принимает во внимание время, потраченное на работу над элементами Журнала Спринта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Инкремент

Инкремент – это сумма всех выполненных требований Журнала Продукта реализованных во время текущего Спринта и всех предыдущих Спринтов. По окончанию Спринта новый Инкремент должен быть «Готовым», то есть он должен быть пригодным к эксплуатации и отвечать определению Скрам Команды понятия “Готовности”. Несмотря на решение Владельца Продукта выпускать ли эту версию Инкремента, он должен быть готовым к использованию.

Scrum доска/Agile Board

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

скрам доска (scrum board)

Пример доски из жизни:

agile доска

Определение «Готовности»

Когда элемент Журнала Продукта или же Инкремент назван “готовым”, все должны понимать, что означает “Готово”. Хотя это определение разные Скрам Команды интерпретируют по-разному, чтобы гарантировать прозрачность, члены Команды должны иметь общее совместное понимание, что означает, когда работа сделана. Именно такое единое определение понятия “Готовности” используется Скрам Командой для оценки окончания работ над Инкрементом Продукта.
Одно и то же определение помогает Команде Разработчиков в понимании того, сколько требований выбрать из Журнала Продукта во время Планирования Спринта. Целью каждого Спринта является разработка Инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению “Готовности” Скрам Команды.
По окончанию каждого Спринта Команда Разработчиков представляет Инкремент функциональности продукта. Такой Инкремент является пригодным к эксплуатации, и поэтому Владелец продукта может решить сразу же его выпустить. Каждый последующий Инкремент должен дополнять все предыдущие Инкременты, а также быть тщательно протестирован для обеспечения стабильной работы всех Инкрементов продукта.
По мере увеличения профессионализма Скрам Команды, определение понятия “Готовности” может расширяться более строгими критериями для достижения лучшего качества продукта.

Заключение

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

бизнес-процесс

Бизнес-процесс. Управление и моделирование в BPM (Business Process Management)

Введение в управление бизнес-процессами (Business Process Management, BPM)

Распространенные роли в управлении бизнес-процессами:

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

Управление бизнес процессами (Business Process Management, BPM) – это концепция управления, увязывающая стратегию и цели организации с ожиданиями и потребностями клиентов путем соответствующей организации сквозных процессов. BPM сводит воедино стратегию, цели, культуру и организационную структуру, роли, политики, нормативы, методологии и программные средства для: а) анализа, проектирования, внедрения, управления и непрерывного улучшения сквозных процессов и б) регулирования отношений в области процессного управления.

Видео по бизнес-процессам:

Рисунок «Три взгляда на BPM»

Три взгляда на BPM

Усовершенствование бизнес процессов (BPI) – это разовая инициатива или проект, направленный на более полное соответствие стратегии организации и ожиданий клиентов. BPI включает в себя выбор, анализ, проектирование и внедрение усовершенствованного процесса.

Управление процессами предприятия (EPM) – это применение принципов, методов и процессов BPM в конкретной организации. EPM: а) обеспечивает соответствие портфеля и архитектуры сквозных процессов стратегии и ресурсам организации и б) предоставляет модель регулирования для оценки и управления BPM инициативами.

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

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

Что такое управление бизнес процессами (BPM)?

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

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

  1. Бизнес процессы, поддерживающие управление бизнес процессами. Например, у организации должны быть процессы, которые обеспечивают:
    • описание и проектирование бизнес процессов;
    • разработку и внедрение бизнес процессов;
    • мониторинг и контроль исполнения бизнес процессов;
    • непрерывное и постоянное улучшение бизнес процессов, несмотря на и в ответ на внутренние и внешние изменения.
  2. Определенные роли (люди), вовлеченные в управление бизнес процессами . Таковые включают (не ограничиваясь ими) следующие:
    • архитектор процессов, который отвечает за описание и проектирование бизнес процессов;
    • процессный аналитик, который отвечает за построение, внедрение, мониторинг и оптимизацию бизнес процессов;
    • владелец процесса, который отвечает за исполнение бизнес процесса от начала до конца, в соответствии с определенными целевыми показателями эффективности и в конечном итоге за создание ценности для потребителя.
  3. Внедрение специализированных информационных технологий управления бизнес процессами , обеспечивающих следующую функциональность:
    • описание бизнес процессов в контексте корпоративной архитектуры;
    • проектирование бизнес процессов с целью внедрения;
    • исполнение бизнес процессов в контексте операционной деятельности;
    • мониторинг целевых показателей эффективности бизнес процессов;
    • анализ бизнес процессов с целью выявления и оценки возможностей для улучшения;
    • управление изменениями бизнес процесса.

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

Рисунок «Бизнес-процесс»

бизнес-процессКонцепция потребителя во взаимодействии функций внутри организации

Концепция потребителя в бизнес-процессе BPMЦенность в виде проектных спецификаций

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

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

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

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

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

Секрет полезности метрик на стадии «Проверка» – правильная архитектура описания процесса на стадии «Планирование». Целевые показатели эффективности процесса определяются ожиданиями потребителя. Эти показатели эффективности самого верхнего уровня, в свою очередь, декомпозируются на нижележащие целевые показатели эффективности, которые могут устанавливаться на функциональном и операционном уровнях. В теории:

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

schema_rascheta_kpi_bizness_processa

Категории бизнес-процессов

Бизнес-процессы можно разделить на три категории:

  • Основные процессы – сквозные и, как правило, кросс функциональные процессы, непосредственно создающие ценность для потребителя. Основные процессы также называют ключевыми, так как они представляют собой действия, необходимые с точки зрения выполнения организацией своей миссии. Эти процессы составляют цепочку создания ценности, в которой каждый шаг добавляет ценность к предыдущему, измеряемую вкладом в создание или поставку продукции или сервиса и в конечном счете в создание ценности для потребителя.
  • Вспомогательные процессы предназначены для поддержки основных, обычно через управление ресурсами и/или инфраструктурой, необходимых основным процессам. Разница между основными и вспомогательными процессами в том, что вспомогательные процессы непосредственно не создают ценность для потребителя. Примеры вспомогательных процессов обычно относятся к ИТ, финансам, управлению персоналом. Хотя вспомогательные процессы зачастую тесно связаны с функциональными областями (например, процесс выдачи и отзыва разрешения на сетевой доступ), они могут пересекать функциональные границы и зачастую действительно их пересекают.
  • Процессы управления предназначены для измерения, мониторинга и контроля бизнес деятельности. Они призваны гарантировать, что основные и вспомогательные процессы спроектированы и исполняются в соответствии с поставленными операционными, финансовыми целями, регуляторными и юридическими ограничениями. Как и вспомогательные, процессы управления непосредственно не добавляют ценности для потребителя, но они необходимы для обеспечения соответствия операций целевым уровням производительности и результативности.

Модель зрелости BPM

Модель зрелости бизнес-процессов BPM:

Модель зрелости бизнес-процессов BPM

Моделирование бизнес-процессов

Цели моделирования процессов

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

Процессные модели – это средства:

  • управления процессами организации;
  • анализа эффективности процесса;
  • описания изменений.

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

Побудительные причины моделирования процессов:

Причины моделирования бизнес-процессов

Процессные нотации

Распространенные процессные нотации:

Процессные нотации

BPMN:
BPMN диаграмма

Диаграмма с дорожками Брюса Силвера:
Диаграмма с дорожками

Блок-схема:
Блок схема

Процессная цепочка, управляемая событиями (EPC):
Процессная цепочка, управляемая событиями (EPC)

UML:
uml

IDEF:
IDEF

Карта потока создания ценности:
Карты потока создания ценностиСпециализированные подходы к моделированию процессов

Специализированные подходы к моделированию процессов:
Специализированные подходы к моделированию процессов

Процессная иерархия

Процессная иерархия:
Процессная иерархия

Основные принципы моделирования бизнес-процессов

Что означает моделирование бизнес-процессов на практике? Моделирование бизнес-процессов в компании может быть направлено на решение большого числа различных задач:

  • Точно определить результат бизнес-процесса и оценить его значение для бизнеса.
  • Определить набор действий, составляющих бизнес-процесс. Ясное определение набора задач и действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.
  • Определить порядок выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
  • Произвести разделение зон ответственности: определить, а затем отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
  • Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
  • Понять суть взаимодействий между участвующими в процессе сотрудниками и подразделениями компании и оценить, а затем повысить эффективность коммуникации между ними.
  • Увидеть движение документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
  • Определить потенциальные узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
  • Более эффективно внедрить стандарты качества, например ИСО 9000, и успешно пройти сертификацию.
  • Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.
  • Эффективно произвести автоматизацию бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами.
  • Разобравшись в совокупности бизнес-процессов компании, понять и описать деятельность предприятия в целом.

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

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

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

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

Шаги построения модели бизнес-процесса

Важной частью построения модели бизнес-процесса является исследование аспектов его эффективности. Сюда входят использование ресурсов, время выполнения работ сотрудниками, возможные задержки и простои. Необходимо разработать систему показателей, или метрик, для оценки эффективности процесса. Частично в качестве метрик могут быть взяты используемые в компании KPI (Key Performance Indicator), однако могут потребоваться и дополнительные характеризующие рассматриваемый процесс показатели.

При моделировании определяются бизнес-цели, в достижение которых вносит свой вклад моделируемый процесс. Следует различать понятия бизнес-цели и результата процесса. Каждый бизнес-процесс должен иметь как минимум один результат и быть направлен на достижение хотя бы одной бизнес-цели. Например, результат процесса «Исполнение заказа на подключение абонента» можно определить как «Получение подтверждения подключения от клиента», тогда как бизнес-цели, которые преследуются при выполнении данного процесса, могут включать «Обеспечение минимального времени исполнения заказа» и «Обеспечение минимального процента рекламаций». Для определения целей следует обратиться к бизнес-стратегии компании.

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

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

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

  • Процессная карта, показывающая связь между различными бизнес-процессами и их взаимодействия. На процессной карте, как правило, каждый бизнес-процесс компании изображен в виде прямоугольника, стрелками показаны связи между ними (например, зависимость одного процесса от другого, или замена одного процесса другим при выполнении некоторого условия), а также представлены различные документы, которые передаются из процесса в процесс или регламентируют их ход (стандарты, инструкции и т.п.).
  • Диаграмма ролей, показывающая роли при выполнении процесса и связи между ними. Диаграмма ролей не является иерархической. Она представляет такие связи, как участие в группе, руководство, коммуникацию, замещение одной роли другой и т. д.
  • Модель «как есть» каждого рассмотренного бизнес-процесса, детально описывающая процесс и отражающая ход процесса, действия, роли, движение документов, а также точки возможной оптимизации. Такая модель включает в себя:
    • диаграмму окружения процесса, представляющую бизнес-процесс в виде одного действия (то есть не раскрывающую ход процесса), для которого могут быть показаны запускающее процесс событие, необходимые входные данные, результат, роли, показатели эффективности, прерывающие события и компенсирующие процессы, регламентирующие документы, связанные бизнес-цели;
    • высокоуровневую диаграмму процесса, показывающую его крупные шаги (обычно не более десяти) и связанные с ними роли;
    • подробные диаграммы для каждого шага высокоуровневой модели (в зависимости от сложности процесса здесь может использоваться несколько иерархически организованных диаграмм), в деталях показывающие ход процесса, прерывающие события, бизнес-правила, роли и документы;
    • диаграмму обработки исключений, показывающую, какие действия выполняются в случае данной исключительной ситуации и кем, а также куда передается управление после окончания обработки исключения.

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

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

Методология проектирования программных средств

Методология проектирования программных средств

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

Технология проектирования АСОИУ – совокупность методологии, а также методов и средств организации процесса проектирования (управление процессом разработки и модернизации проекта).
Методология проектирования представляет собой концепцию / принципы проектирования, реализуемые набором методов проектирования, поддерживаемых средствами проектирования.
Метод (подход) проектирования – алгоритм / последовательность шагов по реализации той или иной стадии создания АСОИУ.
Главный принцип построения различных систем – принцип иерархической декомпозиции включает две группы методологий:

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

Структурно-функциональная методология

В структурном анализе и проектировании используются различные модели, описывающие:

  1. Функциональную структуру системы;
  2. Последовательность выполняемых действий;
  3. Передачу информации между функциональными процессами;
  4. Отношения между данными.

Наиболее распространенными реализациями этих моделей являются:

  1. Функциональная модель SADT (Structured Analysis and Design Technique);
  2. Модель IDEF3;
  3. DFD (Data Flow Diagrams) — диаграммы потоков данных.
  4. Диаграмма «сущность — связь» (ERD — Entity-Relationship Diagram).

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. и успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого семейства — IDEF0 последняя редакция которого была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 г. постановлением Госстандарта России был введен в действие руководящий документ РД IDEF0 – 2000, содержащий основные сведения о методологии функционального моделирования IDEF0, о ее графическом языке и методике построения и практического применения функциональных моделей организационно-экономических и производственно-технических систем. Кроме того, РД IDEF0 – 2000 устанавливает правила оформления комплекта иерархических диаграмм.

В основе методологии IDEF0 лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарии.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

  • верхняя сторона имеет значение «Управление» (Control);
  • левая сторона имеет значение «Вход» (Input);
  • правая сторона имеет значение «Выход» (Output);
  • нижняя сторона имеет значение «Механизм» (Mechanism).

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними.
Единицы работы — Unit of Work (UOW) (работы), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор).
Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными и имеют следующие типы:

  • временное предшествование,
  • объектный поток,
  • нечеткое отношение.

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

Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.

При создании диаграммы потоков данных используются четыре основных понятия:

  • потоки данных,
  • процессы (работы) преобразования входных потоков данных в выходные,
  • внешние сущности,
  • накопители данных (хранилища).

SADT создавалось как средство моделирования систем в целом, а DFD как средство проектирования ИС, поэтому DFD более перспективно для использования, тем более DFD согласовано с ERD, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), которая впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются: (сущности), их свойства (атрибуты) и отношения друг с другом (связи). Кроме того, ERD связываются с такими понятиями как: мощность и тип связи, первичный и внешние ключи, индексы, нормализация диаграммы и т.д.

Объектно-ориентированная методология

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

Объектно-ориентированный подход обладает следующими преимуществам:

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

К недостаткам объектно-ориентированного подхода относятся:

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

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

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

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

Введение в унифицированный язык моделирования (UML)

Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.

Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, ОМТ-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.
Все шло к созданию единого языка, который объединял бы сильные стороны известных методов и обеспечивал наилучшую поддержку моделирования. Таким языком оказался UML.

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов ОМТ и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения.

Пользователям языка предоставлены возможности:

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

Синтаксис и семантика основных объектов UML

UML – это набор диаграмм, которые позволяют создавать модели сложных программных систем.
Диаграммы UML разделяются на две группы.
1. Структурные диаграммы:

  • Implementation Diagram (диаграммы реализации):
    • Deployment diagram (диаграммы топологии);
    • Component diagram (диаграммы компонент).
  • Class diagram (диаграммы классов);

2. Диаграммы поведения:

  • Use case diagram (диаграммы вариантов использования);
  • Statechart diagram (диаграммы состояний);
    • Activity diagram (диаграммы активности);
  • Interaction diagram (диаграммы взаимодействия);
    • Sequence diagram (диаграммы последовательности);
    • Collaboration diagram (диаграмма сотрудничества / кооперативная диаграмма);

Диаграмма прецедентов использования (Use Case Diagram)

Вариант использования определяется, прежде всего, своим именем и типом пользователя приложения, называемого действующим лицом.
Вариант использования состоит из типичного взаимодействия между действующим лицом и приложением. Например, команда «открыть файл» будет типичным вариантом использования текстового редактора с пользователем в качестве действующего лица. Один и тот же человек или внешняя система может использовать систему несколькими разными способами, принимая роли разных действующих лиц (актеров – actors). Актеры представляют именно роли, исполняемые людьми или внешними сущностями, а не конкретных людей или сущностей.
Прецедент описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или более актеров.
Для детализации прецедента составляют спецификацию.

Таблица «Примерный вид спецификации прецедента»

Имя прецедента – отглагольное существительное в стиле UpperCamelCase
Идентификатор (1.1 – прецедент.№альтернативного потока)
Краткое описание – цель прецедента
Актеры: главные актеры инициируют прецедент; второстепенные актеры – взаимодействуют с прецедентом после его инициации
Предусловия определяют условия, которые должны быть истинными для того, чтобы прецедент мог быть инициирован
Основной поток – этапы осуществления прецедента.
Этапы принято записывать в виде:
<номер> <кто-либо><действие>
1. Покупатель заполняет в форме свои имя и адресДля представления ответвления используется ключевое слово «Если»
2. Если покупатель выбирает «удалить позицию»
2.1. Система удаляет позицию из корзиныПовторения моделируют с помощью ключевых слов «Для» или «Пока»
3. Если система находит необходимые продукты, тогда
1.1 Для каждого найденного продукта
1.1.1 Система выводит на экран представление продукта
1.1.2 Система выводит на экран цену продукта
Постусловия определяю, какие условия будут истинными после выполнения прецедента
Альтернативные потоки – альтернативные пути в прецеденте, которые перехватывают ошибки, ответвления и прерывания основного потока (наиболее значимые с т.з. функционирования альтернативные потоки документируются отдельно).

Диаграммы вариантов использования позволяют показать специфические взаимоотношения между прецедентами:

  • обобщение,
  • включение и
  • расширение.

Обобщение прецедентов выносит поведение, общее для одного или более прецедентов, в родительский прецедент.

Рисунок «Обобщение прецедентов»
UML Обобщение прецедентов

При построении диаграмм вариантов использования необходимо:

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

Однако, на диаграммах встречается последовательное соединение прецедентов, но при этом используются специальные типы связей:
Отношение «include» устанавливаемое между прецедентами, позволяет включить поведение одного прецедента в поток другого прецедента. Это означает, что при выполнении прецедента «Просмотреть Индексную Карточку УММ» обязательно должен быть выполнен прецедент «Поиск УММ». Для обозначения отношения включения в UML используется пунктирная стрелка, направленная от исходного варианта использования (включающего) к целевому (включаемому).

Рисунок «Использование отношений «include» и «extend»»
UML Использование отношений include и extend

Таблица «Структура спецификации прецедента, включающей отношение «include»»

Прецедент: РедактироватьИндекснуюКарточку
ID: 4
Краткое описание: Менеджер меняет даные служащего. Администратор изменяет поля УММ, отраженные в индексной карточке
Главные актеры: Администратор
Второстепенные актеры: нет
Предусловия:
1. Администратор входит в систему
Основной поток:
1. include (ПоискУММ)
2. include (ПросмотретьИндекснуюКарточку)
3. Система выводит данные УММ
4. Администратор меняет данные УММ
Постусловия:
1. Данные УММ изменены
Альтернативные потоки: нет

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

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

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

Диаграммы прецедентов определяют зачем (или с какой целью) актеры взаимодействуют с системой. Прецеденты и их описание являются важнейшим артефактом этапа анализа требований.
Для того, что бы ответить не только на вопрос «Зачем происходит взаимодействие с системой? Но и как происходит взаимодействие?» необходимо будет обратиться к диаграммам взаимодействия (sequence и collaboration) и деятельности (activity).

Диаграммы взаимодействия (Interaction Diagram)

Взаимодействие актеров с системой в целом или взаимодействие отдельных модулей (классов) системы между собой происходит посредством обмена сообщениями (или запросами). Для моделирования такого взаимодействия UML включает в свой состав диаграммы взаимодействия: диаграмма последовательности действий (Sequence Diagram) и диаграмма сотрудничества (Collaboration Diagram), которые позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Как правило, диаграммы взаимодействия охватывает поведение объектов в рамках одного конкретного варианта использования.

Sequence Diagram (диаграммы последовательности)

Для построения диаграммы последовательности необходимо:

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

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

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента используется специальный символ в форме латинской буквы «X».
Объекты на диаграмме последовательности могут находиться в двух состояниях, активном — непосредственно выполняя какие-либо действия, и пассивном, ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, применяется фокус управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

Рисунок – Диаграмма последовательностей для варианта использования «Добавление файла УММ для обработки»
Диаграмма последовательностей для варианта использования «Добавление файла УММ для обработки»

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

  • Simple (1) — простая посылка сообщения;
  • Synchronous (2) — операция происходит только в том случае, когда клиент посылает сообщение, а сервер может принять сообщение клиента;
  • Самоделегирование (3) — распространенное явление в ООП, например, когда объект вызывает свой собственный (как правило, защищенный) метод;
  • Balking (4) — операция происходит только в том случае, когда сервер готов немедленно принять сообщение, если сервер не готов к приему, клиент не выдает сообщение;
  • Timeout (5) — клиент отказывается от выдачи сообщения, если сервер в течение определенного времени не может его принять;
  • Procedure Call (6) — клиент вызывает процедуру сервера и полностью передает ему управление;
  • Asynchronous (7) — клиент выдает сообщение, и, не ожидая ответа сервера, продолжает выполнение своего программного кода;
  • Return (8) — определяет, что происходит возврат из процедуры;

Частота посылки сообщений может иметь два варианта:

  • Periodic – сообщения поступают от клиента с заданной периодичностью;
  • Aperiodic – сообщения поступают от клиента нерегулярно.

Рисунок – Виды сообщений на диаграмме последовательностей
Виды сообщений на диаграмме последовательностей

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

Как и все прочие диаграммы UML, диаграммы последовательностей проходят две стадии детализации:

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

Рисунок – Диаграмма последовательностей для варианта использования «Добавить файл УММ для обработки»
Диаграмма последовательностей для варианта использования «Добавить файл УММ для обработки»

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

Рисунок – Диаграмма сотрудничества
Диаграмма сотрудничества

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

  • Связь Link To Self (связь с самим собой) показывает, что объект имеет обратную связь с самим собой.
  • Link Message / Reverse Link Message (передача сообщения / обратная передача) позволяет отразить связь, которая подразумевает обязательную передачу сообщения в прямом (обратном) направлении.
  • Data Flow / Reverse Data Flow (поток данных) позволяет отразить связь показывающую, что происходит передача данных от одного объекта другому в прямом / обратном направлении.

Отличительной особенностью диаграммы сотрудничества по сравнению с диаграммой взаимодействия является возможность использовать более богатый набор синтаксических конструкций. На рис. смоделирована ситуация, которая предусматривает наличие у экземпляра класса «ConcreteStateA» метода «create». Метод «create» в цикле позволяет создать мультиобъект (коллекцию) «ConcreteStateB». Причем, поскольку метод «create» вызывается с аргументом, то это означает, что при создании используется конструктор с параметрами.

Рисунок – Циклы на диаграмме сотрудничества
Циклы на диаграмме сотрудничества

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

Диаграмма деятельности (Activity Diagram)

Диаграммы деятельности (Activity Diagram) позволяет изобразить поток операций в системном, производственном или технологическом процессе. Диаграммы деятельности используется для моделирования прецедента в виде последовательности действий (activity), описывающих взаимодействие актера с системой. Эта диаграмма концентрирует внимание на том, какие действия выполняются и кто несет ответственность за их выполнение. Деятельность изображается на диаграмме в виде

Деятельность может быть двух типов:

  • action – действие.
  • send event – посылка события.

В свою очередь действие (action) может имеет имя (name) и выполняться по входу (on Entry), по выходу (on Exit), во время (Do) и при возникновении события (on Event). Семантика деятельности «Подготовка диска» в состав которого входит действие «Форматирование», которое выполняется по входу имеет след. вид:

Рисунок – Изображение действия на диаграмме деятельности
Изображение действия на диаграмме деятельности

При инициализации действия по событию (on Event) можно указать имя события, передаваемые аргументы (arguments) и условие, которое должно выполниться для инициализации действия по данному событию. Семантика деятельности «Технологический процесс», включающее действие «Звонок», которое выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» имеет след. вид:

Рисунок – Изображение действия с событием
Изображение действия с событием

Если деятельность имеет тип «send event» — послать событие, то, кроме указания момента инициализации данной деятельности (on Entry, on Exit, Do, on Event) можно указать посылаемые аргументы (Send arguments) и целевую деятельность (Send target). Действие «Звонок» деятельности «Технологический процесс» выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» и заключается в посылке сообщения деятельности «Завершение процесса» с аргументами (статус и полное время). В этом случае семантика деятельности «Технологический процесс» имеет следующий вид:
Рисунок – Изображение действия с событием и условием осуществления
Изображение действия с событием и условием осуществления

Диаграмма деятельности кроме собственно деятельностей (activity) может включать в свой состав:

  • состояния (State),
  • синхронизации (Synchronizations),
  • узел решения (слияния) – decision и
  • разделы (swimlanes-плавательные дорожки).

Состояние (State) – это ситуация в жизни объекта на протяжении которой он удовлетворяет некоторому условию при этом объект осуществляет определенные действия или ожидает некоторого события. Так же как и Деятельность состояние может быть двух типов: action – состояние в котором выполняется заданное действие и send event – состояние, которое посылает событие с аналогичными настройками момента перехода в состояние или посылки сообщения.

Перемещение объекта от одной деятельности (состояния) к другой отражается с помощью стрелки (transition).
Спецификация перехода включает в себя:

  • событие (event) – это то, что вызывает переход от одной деятельности к другой. Имя события помещается над связью между состояниями. У события могут быть аргументы.
  • защитные условия (guard conditions) – условия, наложенные на осуществление перехода. Защитные условия указываются вдоль линии перехода после имени события и заключаются в квадратные скобки.
  • действие (action), которое должно быть выполнено в процессе перехода (указывается вдоль линии перехода после «/»).
  • событие, которое может быть послано (send event) целевой деятельности (send target) с аргументами (send arguments)

Рисунок – Семантика условного перехода
Семантика условного перехода

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

Узел синхронизации (Synchronizations) предназначен для разделения потока на несколько параллельных потоков или, напротив, объединяет несколько входящих потоков на один исходящий.
Узел решения – decision должен сопровождаться указанием условия перехода в виде комментария. При этом каждая ветвь потока должна снабжаться сторожевым условием (guard condition). Он становится узлом слияния, если объединяет несколько потоков.
Разделы (swimlanes-плавательные дорожки) предназначены для разделения деятельностей с помощью их группировки по прецедентам, классам, компонентам, ролям и т.д.
Историческое состояние (обозначается «Н») – это псевдосостояние, которое восстанавливает предыдущее активное состояние в композитном состоянии. Оно позволяет композитному состоянию OpenState запоминать, какое из вложенных состояний (StopState или StartState) было текущим в момент выхода из OpenState, для того, чтобы любой из переходов в OpenState возвращался именно в это вложенное состояние, а не в начальное.

Рисунок – Изображение «Исторического состояния»
Изображение «Исторического состояния»

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

Рисунок – Пример построения диаграммы деятельности
Пример построения диаграммы деятельности

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

Диаграмма классов (Class Diagram)

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

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

Например, на рис. представлена диаграмма классов основного сценария варианта использования П.1 «Добавление файла УММ для обработки», где Спецификация загрузок УММ моделирует таблицу БД, в которую будут сохраняться данные (логин пользователя, дата, имя файла) о загружаемых на сервер файлах УММ. В Спецификации УММ для каждой УММ сохраняется атрибутивная информация (название УММ, год издания, кол-во страниц и т.д.), состав которой перечислен в ТЗ.

Рисунок — Диаграмма классов варианта использования «Добавить файл УММ для обработки»
Диаграмма классов варианта использования «Добавить файл УММ для обработки»

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

Рисунок – Изображение класса на диаграмме классов
Изображение класса на диаграмме классов

Объекты обмениваются сообщениями через соединения — связи. Но, для того, что бы между объектами была связь, между классами этих объектов должна существовать ассоциация, так как связь между объектами – это экземпляр ассоциации между классами.
Ассоциация – это связь между классами, отражающая некоторое значимое отношение между ними.
В процессе анализа ассоциаций необходимо придерживаться принципами минимализма, поскольку, если МПО будет состоять из N классов, то теоретически между ними можно будет установить N(N-1). В этой связи, в модель включают только те ассоциации, знания о которых необходимо сохранять в течение некоторого периода.
Не только ассоциация в целом может иметь имя, но и классам на обоих концах ассоциации могут быть присвоены имена ролей, исполняемые объектами классов, когда они связаны экземпляром данной ассоциации. Стрелка показывает направление передачи информации (например, посылки сообщения) от одного объекта к другому.
Например, предположим, что компания нанимает n служащих. Ограничения кратности (множественность — multiplicity) «1» и «n» означают, что объекты Person в данный момент времени могут быть наняты только одним объектом Company и Person не могут быть безработными. Объект Company может посылать сообщения объектам Person, но не наоборот.

Рисунок – Использование символов множественности на диаграмме классов
Использование символов множественности на диаграмме классов

Недооцененная кратность ограничивает гибкость приложения, например, некоторые персональные менеджеры не позволяют охранять несколько телефонов для одного человека.
Частным случаем ассоциации является ассоциация-класс (Association Class), которая обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс – это место, где хранятся относящиеся к ассоциации атрибуты и операции.
Имена полюсов ассоциаций являются обязательными, когда класс имеет ассоциацию с самим собой (рефлексивная ассоциация), которая означает, что объекты данного класса имеют связи с другими объектами этого же класса.
Каждый объект Directory может иметь связь с объектами Directory, выступающими в роли subdirectory, число которых может меняться от 0 до n. C другой стороны у подкаталога родитель может быть только 1 или не иметься вообще. Кроме того, Directory может иметь связь с произвольным числом объектов File.

Рисунок – Пример использования рефлексивной ассоциации на диаграмме классов
Пример использования рефлексивной ассоциации на диаграмме классов

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

Рисунок – Класс-ассоциация
Класс-ассоциация

Конкретизированные формы ассоциации (association):

  • зависимость (dependency) – однонаправленная связь, показывающая, что один класс зависит от определений, сделанных в другом. Такая связь имеет место, например, если один класс использует другой в качестве параметра операции. При генерации кода к исходному классу атрибуты целевого класса добавлены не будет, но в код будет добавлен оператор типа «#include».
  • агрегация (aggregation) – частный случай ассоциации, который выражает отношение целое-часть (например, автомобиль-двигатель). Агрегация является транзитивной: если А является частью В, а В – частью С, то А — часть С. Агрегация изображается с помощью ромба, который ставится около полюса, являющегося агрегатом. Жизненный цикл объекта–части совпадает с ЖЦ объекта-целого. Более сильная разновидность агрегации – это связь типа «композиция» (объединение – composition), которая накладывает на ассоциацию два дополнительных ограничения:
    • (i) составляющая часть может принадлежать не более чем одному агрегату;
    • (ii) составляющая часть получает срок жизни агрегата. Композиция обозначается закрашенным ромбом. Таким образом, агрегация – это способ встраивания нескольких объектов в один объект-контейнер и использование встраиваемых объектов для реализации методов контейнера.

Код:
агрегация (aggregation) – частный случай ассоциации, который выражает отношение целое-часть

Обобщение (generalization) – показывает связи наследования между двумя классами (суперкласс-подкласс). При этом, подклассы наследуют все возможности своих надклассов (атрибуты, операции, отношения, ограничения) – inheritance. Обобщение часто используется совместно с абстрактными классами, которые могут иметь абстрактные атрибуты и операции. Абстрактные классы не создают экземпляров. Подкласс абстрактного класса реализует абстрактные операции, добавляя новые возможности, или переопределяя их.

Рисунок – Наследование на диаграмме классов
Наследование на диаграмме классов

Поскольку обобщение транзитивно, экземпляр подкласса одновременно является экземпляром всех его предков, т.е. обладает значениями всех атрибутов всех классов-предков и может вызывать любую операцию, указанную у любого из его предков. Не следует создавать слишком глубокую иерархию классов, поскольку это затруднит восприятие модели – иерархия с количеством уровней не превышающих 3, как правило, всегда приемлема; 5-6 уровней иерархии может быть как приемлемо, так и нет в зависимости от особенностей проектируемой системы.
Кроме того, обобщение следует использовать только там, где по крайней мере один из подклассов обладает атрибутами, операциями или ассоциациями, неприменимыми к суперклассу. Например, не следует использовать обобщение, когда существуют подклассы одинаковые по своей сигнатуре и поведению с суперклассом (масть карты Таким образом, ассоциации типа «обобщение» позволяют обеспечить полиморфизм:
добавляя новый подкласс автоматически наследуется поведение суперкласса и, более того, новый подкласс не нарушает работу существующего класса.
Следует отметить, что некоторыми языками программирования поддерживается множественное наследование, которое позволяет классу наследовать составляющие от нескольких классов одновременно.

На рисунке показано дерево классов, в котором SubClass является подклассом (дочерним классом) по отношению к двум суперклассам (базовым классам) – SuperClass1 и SuperClass22. Object1 и Object2 – экземпляры класса SubClass, наследующие атрибуты класса SubClass (x и y). В свою очередь SubClass наследует атрибуты z и w классов SuperClass1 и SuperClass2, переопределяет3 атрибут x и добавляет атрибут y.
Таким образом, при вызове, например Object1.x или Object2.x будет использоваться атрибут SubClass.x, находящийся на один уровень выше в иерархии наследования; при вызове Object1.z или Object2.z будет использоваться атрибут SuperClass1.z, поскольку класс SuperClass1 находится левее в дереве по сравнению с SuperClass2, то SubClass будет наследовать атрибуты SuperClass1 в первую очередь. Таким образом, при использовании множественного наследования следует иметь в виду, что порядок классов, перечисленных в строке заголовка инструкции class наследующего класса, определяет порядок наследования атрибутов.

Рисунок – Множественное наследование
Множественное наследование

Рисунок – Листинг кода, демонстрирующий множественное наследование
Листинг кода, демонстрирующий множественное наследование

Множественное наследование стараются избегать или путем реструктурирования модели на этапе проектирования или с помощью механизма реализации «делегирование».

Видимость атрибута указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости:

  • public (общий) – любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;
  • protected (защищенный) – только класс или потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;
  • private (закрытый) – только данный класс может пользоваться закрытыми атрибутами. Обозначаются символом «-»;
  • package or implementation (пакетный) – атрибут является общим в пределах пакета в котором расположен класс. Обозначаются символом «~».

При определении видимости для той или иной составляющей необходимо руководствоваться следующими соображениями:

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

Еще одной важной характеристикой атрибутов и операций классов является область действия (scope), которая определяет к чему относится данная составляющая: к объекту или к классу. У объектов есть собственные копии атрибутов, принимающих разные значения и операций. Область действия этих атрибутов и операций instance (экземпляр) – у каждого экземпляра класса есть собственное значение данного свойства. Однако иногда нужно определить атрибуты, которые имеют единственное, общее для всех объектов класса значение. Аналогично нужны операции, не относящиеся ни к одному конкретному экземпляру класса (например, операция создания объекта — конструктор). Такие атрибуты и операции имеют область действия classifier (классификатор) – все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).
В этом случае оно называется статическим.
Для группировки классов, обладающих общностью, применяют пакеты, которые являются средством организации модели в процессе разработки, повышения ее управляемости и читаемости. Диаграмма пакетов – диаграмма, содержащая пакеты классов и зависимости между ними. Кроме того, пакеты используются для представления подсистем (модулей) системы в процессе проектирования. Подсистема, включающая совокупность классов, реализует набор операций, которые определены в ее интерфейсе.

Рисунок – Диаграмма пакетов
Диаграмма пакетов

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

Рисунок – Сопоставление пакетов проектным слоям
Сопоставление пакетов проектным слоям

Каждый пакет представляет пространство имен (namespace), следовательно каждый класс внутри собственного пакета должен иметь уникальное имя. Чтобы отличить один класс от другого, можно использовать полностью определенное имя (fully qualified name), то есть имя, которое указывает на структуру, владеющую пакетом. В языке UML в именах пакетов используются двойные двоеточия, поэтому классы дат могут иметь имена System::Date.
Можно показывать только имя пакета или имя вместе с его содержимым.
Согласно концепции UML классы в пакетах могут быть открытыми (public) или закрытыми (private). Открытые классы представляют часть интерфейса пакета и могут быть использованы классами из других пакетов; закрытые классы недоступны извне. Можно сделать это, присвоив всем классам модификатор видимости private (закрытый), так чтобы они были доступны только классам данного пакета, а также создав дополнительные открытые классы для внешнего использования. Эти дополнительные классы, называемые Facades (Фасады), делегируют открытые операции другим классам пакета.

Диаграмма компонент (Component Diagram)

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

  • Package (пакет) — объединяет группу компонентов в модели;
  • Main program (главная программа);
  • Subprogram body (тело подпрограммы);
  • Package specification/body (определение/тело пакета).

Рисунок — Диаграмма компонент
Диаграмма компонент

Диаграмма размещения (Deployment Diagram)

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

Рисунок – Диаграмма размещения
Диаграмма размещения

Введение в проектирование баз данных

Основные сведения

Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation—отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом — таскать бревна, кирпичи…

Процесс проектирования базы данных состоит из следующих этапов:

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

Первые 5 этапов образуют фазу логического проектирования, а остальные два — фазу физического моделирования.

Логическая фаза

Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.

Сбор требований

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

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

Определение атрибутов

Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты.
baza_dannih_doma_sushnosti_i_atributi
Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе — нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

Внешним ключом называется совокупность атрибутов, ссылающихся на первичный или альтернативный ключ другой сущности. Если внешний ключ не связан с первичной сущностью, то он может содержать только неопределенные значения. Если при этом ключ является составным, то все атрибуты внешнего ключа должны быть неопределенными.
На диаграммах атрибуты, объединяемые во внешние ключи, обозначаются специальными символами. На рисунке изображены две связанные сущности (Дома и их Хозяева) и образованные ими внешние ключи (ведь один человек может владеть больше, чем одним домом).
sushnosti_s_vneshnim_kluchom

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

Определение связей между сущностями

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

Один-к-одному

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

Один-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

Многие-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако и каждой записи второй сущности может соответствовать несколько записей из первой сущности. Например, есть две сущности: Автор и Книга. Один автор может написать много книг. Но у книги может быть несколько авторов.
По критерию обязательности отношения делятся на обязательные и необязательные.

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

Нормализация

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

Первая нормальная форма

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

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

Вторая нормальная форма

Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность — этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме).
vtoraya_normalnaya_forma

Третья нормальная форма

В третьей нормальной форме исключаются атрибуты, не зависящие от всего ключа. Любая сущность, находящаяся в третьей нормальной форме, находится также и во второй. Это самая распространенная форма базы данных.
В третьей нормальной форме каждый атрибут зависит от ключа, от всего ключа и ни от чего, кроме ключа.
Например, у сущности Владелец дома на рисунке есть атрибут Знак зодиака, который зависит от даты рождения владельца дома, а не от его имени (которое является ключом).
Для приведения сущности Владелец дома необходимо создать сущность Знаки зодиака и перенести туда атрибут Знак зодиака (Сущность Владелец дома, приведенная к третьей нормальной форме):
tretiya_normalnaya_forma

Ограничения

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

Хранимые процедуры

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

ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.

Целостность данных

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

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

Триггеры

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

Деловые правила

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

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

Все эти возможности можно применять для реализации деловых правил в базе данных.

Физическая модель

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

Денормализация

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