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

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

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

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

Выстраиваем бизнес-процессы

1. Оптимизация трудозатрат.
2. Минимизация влияния человеческого фактора.
3. Сокращение механических ошибок.
4. Понимание сотрудниками зоны своей компетенции и ответственности.
5. Упрощение процесса оценки эффективности работы.

Весь процесс формализации деятельности можно разбить на четыре простых шага (рис. 1).

Рисунок 1 – Этапы разработки бизнес-процесса

Пример работы по бизнес-процессу

БП формализуют деятельность как компании в целом, так и отдельно ее отделов.

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

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

Типовой БП «Продажа» для компаний в В2В сегменте может иметь вид, представленный на рисунке 2.

Рисунок 2 – БП «Продажа»

Для формализации работы отдела продаж также можно настроить БП «Формирование лояльности», «Работа с постоянными клиентами (повторные продажи)», «Продажа дилера» и другие. Также за счет БП можно выстроить работу отделов маркетинга («Проведение рекламной кампании», «Маркетинговое исследование», «Разработка долгосрочной стратегии»), работы с кадрами («Обучение сотрудников», «Карьерный рост») и другие.

Немаловажной является возможность настройки взаимодействия между отделами компании за счет внедрения таких БП, как «Разработка коммерческого предложения», «Разработка договора», «Разработка продукта».

Инструмент реализации бизнес-процесса

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

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

Бизнес-процесс «в блокноте».

Зачастую владельцы бизнеса, пытаясь якобы систематизировать работу компании, ограничиваются своими записными книжками, программными продуктами пакета MS Office и «распечатками» над рабочим местом ответственного сотрудника.

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

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

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

БП в CRM-системе

Четко определена последовательность действий процесса

Источник: efsol.ru

Этапы проектирования ИС с применением UML

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм.

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

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

На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов.

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

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

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

• Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде.
• Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.
• Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).
• Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.
• Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.
• Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.
• Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.
• Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.

На рис. 3.10 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение «является источником входных данных для. » (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности).

Рис. 3.10. Взаимосвязи между диаграммами UML

Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.

3.4. Анализ требований и предварительное проектирование системы

Основные задачи этапа:

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

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

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

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

Рис. 3.11. Диаграмма классов «Защита доступа»

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

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

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

Процесс сбора и анализа требований включает следующие шаги:

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

3.5. Анализ и формирование требований к ИС

Функциональные требования

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

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

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

Функциональные требования, как минимум должны включать:

• общесистемные требования, согласованные всеми заинтересованными представителями бизнес-процессов:

— основные цели создания ИС и ее назначение;

— планируемое развитие ИС;

— требования к ИС в целом;

— требования к структуре данных ИС;

— требования к функциональности ИС;

— требования к интерфейсу пользователя;

— требования к отчетам;

— требования к средствам администрирования;

— требования к средствам разработки;

— требования к взаимодействию с другими программными продуктами;

— требования к документированию;

— требования к программному и аппаратному обеспечению по объему требуемых ресурсов, быстродействию, надежности.

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

— документирование форматов входных и выходных данных;

— методы реализации контроля подготовки, ввода данных и обработки ошибок ввода данных, позволяющих реализовать корректировку ошибок;

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

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

— средства, поддерживающие неотказуемость транзакций;

• формализованные требования, согласованные всеми заинтересованными представителями бизнес-процессов:

— описание детальных спецификаций ПО в части функциональности системы;

— требования к разработке и документированию интерфейсов с внутренними подсистемами;

— требования к разработке и документированию алгоритмов обработки данных;

— требования обеспечения безопасности, целостности и доступности (в том числе при чрезвычайных ситуациях).

Требования к внешним интерфейсам

Требования к внешним интерфейсам ИС, в зависимости от конкретных условий эксплуатации, включают:

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

Нефункциональные требования

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

Нефункциональные требования включают:

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

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

Основные требования пользователей к информационным системам

ИС должны обеспечивать:

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

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

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

Общими требованиями к ИС являются:

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

Требования по обеспечению информационной безопасности

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

Программно – аппаратные средства защиты информации должны быть лицензионными, сертифицированными и обеспечивать:

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

Источник: cyberpedia.su

Практика формирования требований в ИТ проектах от А до Я. Часть 4. Бизнес процессы, автоматизируемые системой

VII Детализируем процессы, включенные в рамки проекта

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

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

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

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

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

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

Рисунок 7.1 — модель процесса определения сценариев использования системы

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

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

1. Используем диаграммы бизнес-процессов

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

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

На рисунке 7.2 приведен пример контейнера диаграмм, группирующий диаграммы процессов, разбитые по бизнес транзакциям.

Рисунок 7.2 – Деление процессов на бизнес транзакции

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

Рисунок 7.3 – Фрагмент диаграммы с 2_умя точками входа в процесс

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

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

Рис. 7.4 – Диаграмма Бизнес процесса Сбор потребностей заказчика

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

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

2. Пример использования диаграммы бизнес-процессов для определения ролей и хранилищ данных

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

Рис. 7.5 – Диаграмма Бизнес процесса Обработка обращений заинтересованных лиц

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

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

Например, на рис. 7.6 Хранилище «Элементы архитектуры», может использоваться в нескольких бизнес транзакциях и в нескольких процессах.

Рис. 7.6 – Использование диаграммы для формализации хранилищ

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

Рис. 7.7 – Таблица зависимостей ресурса

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

3. Используем диаграммы бизнес-процессов для реинжениринга

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

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

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

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

Формирование таких показателей и определение их значений, должно производиться при непосредственном участии представителей заказчика. Количество показателей не должно превышать 20.

4. Просчитываем предварительную ркусрсоемкость проекта

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

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

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

• для Сущностей: 0,3 — простой; 0,7 — средний; 1 – сложный;
• для Выборки: 1 — простой; 1,5 — средний; 2 – сложный;
• для Форм: 0,7 — простой; 1,5 — средний; 2 – сложный;
• для Процедур: 1 — простой; 3 — средний; 6 – сложный;
• для Отчетов: 0,5 — простой; 1 — средний; 3 – сложный;

5. Пересматриваем границы проекта (при необходимости)

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

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

Рис. 7.8 – Изменения в функциональной модели системы Управления требованиями

6. Подведем итоги использования процессных моделей

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

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

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

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

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

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

Список литературы

1. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
2. Дэвид А. Марк и Клемент МакГоуэн – «Методология структурного анализа и проектирования SADT»
3. Коберн — «Современные методы описания функциональных требований» (2002)
4. Леффингуэлл Дин, Уидрих Дон — «Принципы работы с требованиями к ПО» (2002)
5. Карл И. Вигерс – «Разработка требований к программному обеспечению» (2002)
6. Элизабет Халл, Кен Джексон, Джереми Дик — «Разработка и управление требованиями практическое руководство пользователей» (2005)
7. Скотт Амблер – «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (2005)
8. Гринфилд Джек, Кейн Шорт — «Фабрики разработки программ» (2007)
9. Алистэр Коуберн — «Каждому проекту своя методология»
10. Вольфсон Борис- «Гибкие методологии разработки»
11. Лешек А. — «Анализ требований и проектирование систем»
12. Фримен Эрик, Фримен Элизабет — «Паттерны проектирования» (2011)
13. Эванс Эрик — «Предметно-ориентированное Проектирование» (2011)
14. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»

• формирование требований
• проектирование
• требования
• управление проектами
• менеджмент продукта

• Программирование
• Анализ и проектирование систем
• Проектирование и рефакторинг
• Визуализация данных
• Промышленное программирование

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