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

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

Нотация BPMN (Business Process Model And Notation) находит широкое применение для построения как аналитических, так и исполняемых моделей бизнес-процессов. Она стала стандартом для лидеров ИТ-рынка и широко используется в программных системах.
Нотация BPMN 2.0 является одновременно средством графического визуального моделирования бизнес-процессов и языком создания исполняемой модели бизнес-процесса. BPMN ориентирована на широкий круг специалистов, вовлеченных в описание и автоматизацию бизнес-процессов: начиная с аналитиков и разработчиков и заканчивая экспертами предметной области.
Нотация BPMN относится к классу индустриальных стандартов. Она разработана организацией Object Management Group и утверждена общим решением лидеров ИТ-рынка. Высокий статус организации разработчика, его независимость от конкретного производителя и поддержка лидеров компьютерной индустрии обеспечивают BPMN широкое распространение. В настоящее время версия 2.0 стандарта реализована в большинстве продуктов для моделирования и управления бизнес-процессами, присутствующими на рынке.
При использовании Системы Управления Бизнес-Процессами исполняемая модель помогает не только раскрыть и верифицировать модель бизнес-процесса, но и испытать ее в условиях реальной эксплуатации.

Нотация BPMN предназначена для описания:

• Порядка исполнения работ, образующих бизнес-процесс;

• Потоков данных между операциями процесса;

• Потоков сообщений между процессами;

• Ассоциации обрабатываемых объектов данных с операциями процесса.

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

Системная инженерия (Systems Engineering) (системотехника) — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем.

Ключевые инструменты системной инженерии:

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

• Разработка систем на основе моделей. Моделирование требований, функциональности системы, вариантов реализации, исследование затрат, исполнение моделей, валидация

• Управление изменениями и конфигурациями. Управление взаимодействием, изменениями, общим репозиторием и конфигурацией

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

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

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

На переделку дефектов, связанных с недокументированными либо плохо сформулированными требованиями, расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки.
Основной закон: требования должны быть документированы. Не следует ожидать, что для успеха проекта хватит телепатической передачи ненаписанных требований. Требования для каждого проекта должны быть представлены в формах, которые позволят ознакомить с ними всех заинтересованных лиц и управлять ими на протяжении разработки проекта.
Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.

Цель рабочего потока анализа (с точки зрения объектно-ориентированного анализа) – создание аналитической модели. Данная модель фокусируется на том, что должна делать система. Детали того, как система будет это делать, предоставляются потоку проектирования.
Аналитик — это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации.
Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей.
В результате формулировки требований формируется коллективный взгляд на систему.
Поскольку именно требования определяют предполагаемый исход (результат) проекта, планы, сметы и графики следует разрабатывать на основе требований.
На разработку требований в успешных проектах тратится от 10 до 30 % ресурсов.
Изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований: 11% — на сбор информации по требованиям, 10% — на моделирование, а 7% на проверку и утверждение; на разработку требований для среднего проекта необходимо 15.7% всех ресурсов и 38.6% времени.
Анализ требований закладывает фундамент всего процесса проектирования и реализации системы.

Системный арализ – совокупность методов и средств, используемых при исследовании и конструировании сложных и сверхсложных объектов, прежде всего методов выработки, принятия и обоснования решений при проектировании, создании и управлении социальными, экономическими, человеко-машинными и техническими системами.
Этап анализа (analysis) состоит в исследовании системных требований и проблемы, а не в поисках путей ее решения.
Выделяют анализ требований (requirements analysis) (т.е. исследование требований к системе) и объектно-ориентированный анализ (object-oriented analysis) (исследование объектов предметной области).
В процессе проектирования (design) основное внимание уделяется концептуальному решению, обеспечивающему выполнение основных требований, но не вопросам его реализации. Этот термин тоже стоит уточнить и говорить об объектно-ориентированном проектировании (object-oriented design) или проектировании базы данных (database design).
Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Разработка модели информационной системы (ИС) для бизнеса в такой же мере необходима, как и наличие проекта при строительстве здания.
Большинство современных методов ООАП основаны на использовании языка UML.
Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы.
UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии построения информационных систем.

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

Требования (requirements) — это возможности или условия, которым должна соответствовать система или проект.
Анализ требований может включать описание процессов или сценариев использования приложения, которое может быть представлено в форме прецедентов (вариантов использования) (use cases).
Прецеденты — это повествовательные истории об использовании системы. Построить диаграмму прецедентов может быть просто, а их описание может занять несколько недель, или даже больше.
Сценарий (scenario) — это специальная последовательность действий или взаимодействий между исполнителями и системой. Это один конкретный сценарий использования системы либо один проход прецедента.
Прецедент - это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого для конкретного исполнителя результата.
Требования — это весь набор прецедентов, т.е. модель функционирования системы и ее окружения.
Описания прецедентов — это текстовые документы, а не диаграммы. Диаграммы прецедентов UML позволяют оценить рамки системы и ее окружение.
Описание прецедента в формате “черный ящик” (black-box use cases) — это самый типичный и рекомендуемый тип описания прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн. Наоборот, системе вменяются некоторые обязанности (responsibilities).
Прецеденты не являются исчерпывающим описанием системы. Могут использоваться также: дополнительная спецификация (supplementary specification), словарь терминов (glossary), документ “Видение” (vision). Помимо прецедентов, функции системы можно выразить через ее свойства (system features), представляющие собой высокоуровневые, краткие утверждения, описывающие возможности системы.

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

Опыт показывает, что любые теоретические рекомендации по построению инфологической модели воспринимаются всерьез лишь после нескольких безрезультатных попыток оживления неудачно спроектированных систем.
Т.к. многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).
Плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.
Проект базы данных надо начинать с анализа предметной области и выявления требований к ней пользователей.
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" (Entity-Relationship, ER).
Реляционная модель данных при проектировании приложений баз данных является наиболее популярной, поддерживаемой всеми крупнейшими участниками рынка информационных технологий во всем мире, и доминирующей в области разработки информационных систем с использованием баз данных.
Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры. Среди них наиболее распространен SQL (Structured Query Language – структуризованный язык запросов).

Проектирование базы данных – самый трудный и ответственный этап во всем процессе разработки БД. Проект базы данных – это фундамент будущего программного комплекса.
Структурный анализ предметной области – это начало проектирования БД.
Группировка атрибутов в отношениях должна быть рациональной, такой чтобы в таблицах были сведены к минимуму или отсутствовали: избыточность данных, аномалии обновления, аномалии удаления, аномалии ввода.
Достигается это нормализацией отношений. Использование ненормализованных таблиц может привести к нарушению целостности данных (противоречивости информации) в базе данных.
Начинающий проектировщик зачастую использует ненормализованную базу данных в качестве завершенной БД. Однако, при этом возникают проблемы, неминуемо приводящие к многочисленным сложностям при разработке архитектуры системы, написании кода и, как следствие, ошибкам в работе системы и проблемам пользователей при взаимодействии с ней, устранять которые путем изменения и усложнения кода все сложнее с каждой выявленной проблемой и, в конечном итоге, становится в принципе невозможным.
Проблемы, проистекающие из плохо спроектированной схемы данных, можно исправить только путем правильного проектирования БД.
Нормализация отношений гарантирует целостность данных. Обычно применяется нормализация базы данных до НФБК, в случаях достаточно сложных зависимостей между сущностями может быть проведена нормализация до 4НФ (или 5НФ).
Чаще всего модель представляется в виде диаграммы «сущность – связь» (entity – relationship) или ER-диаграммы. Процесс построения ER-диаграммы называется ER-моделированием.