Внешняя или прецедентная модель описывает бизнес так, как он виден извне, т.е. как он воспринимается клиентами и другим окружением. Данная модель отражает представление о том, что делает бизнес, а не как делает.
Построение прецедентной модели начинается с выделения прецедентов и элементов окружения. «Продажа заказного продукта», является основным прецедентом, который отражает весь бизнес-процесс в исследуемой организации. В данный прецедент входят еще три различных по своей сути бизнес-процесса: «Оформление заказа», «Проектирование», «Изготовление».
Окружение моделируется при помощи действующих лиц, субъектов, которое взаимодействует с бизнесом. Субъект представляет собой абстракцию кого-либо или чего-либо, использующего бизнес. Он обозначает роль, которую что-то или кто-то может играть по отношению к бизнесу.
Субъектами исследуемого бизнес-процесса являются «Заказчик» и «Поставщики». «Заказчик» физическое или юридическое лицо, обращающееся в салон-мастерскую с целью сделать заказ на изготовление мебели. «Поставщики» — субъекты, с которыми взаимодействует бизнес, и которые осуществляют поставку материалов и фурнитуры. На рисунке 4.1 представлена диаграмма вариантов использования, которая отображает взаимодействие бизнес-процесса с окружением (прецедентов с акторами).
11.1 Бизнес процессы: демонстрация работы
Рисунок 4.1 Диаграмма вариантов использования Следующий шаг в построении прецедентной модели — описание прецедента последовательностью шагов. Данное описание называется потоком событий. Так как реинжиниринг будет направлен на процесс продажи заказной мебели, особое внимание обратим именно этот прецедент.
Данный бизнес-процесс является общим и исследуемым, он включает в себя поток событий и три обособленных прецедента, каждый из которых будет рассмотрен более подробно. Поток событий прецедента «Продажа заказного продукта» (Рисунок 4.2): 1. Клиент обращается в отдел по работе с клиентами с целью заказать мебель, начинается выполнение прецедента «Оформление заказа».
2. Если клиент отказывается от условий, то бизнес-процесс прерывается, если клиент соглашается, то он заказывает необходимую ему мебель. 3. Проектный отдел приступает к проектированию заказанной мебели, данный бизнес процесс отражает прецедент «Проектирование».
4. Сборочный цех приступает к изготовлению заказанной мебели, данный бизнес-процесс отражает прецедент «Изготовление». 5. Следующим шагом является контроль качества изделия, который осуществляет проектный отдел. 6. Если изделие не удовлетворяет предъявляемым нормам, то в сборочном цеху приступают к исправлению дефектов и несоответствий нормам.
7. Если изделие качественное, то отдел доставки осуществляет погрузку и доставку изделия клиенту. 
Рисунок 4.2 Поток событий прецедента «Продажа заказного продукта» Далее будет рассмотрен поток событий бизнес-процесса, обособленный в отдельный прецедент «Оформление заказа», при котором происходит взаимодействия клиента с менеджером по работе с клиентами.
Бизнес-процессы: что это, зачем нужны, как использовать на практике.
Поток событий прецедента «Оформление заказа» (Рисунок 4.3): 1. Клиент приходит в отдел по работе с клиентами и обращается к одному из менеджеров по работе с клиентами, с целью оформить заказ на изготовление мебели. 2. Менеджер предоставляет клиенту каталог возможных эскизов и дизайнов мебели. Клиент выбирает изделие.
3. В процессе общения выясняются дополнительные пожелания клиента, которые менеджер учитывает и примечает. 4. Менеджер объясняет клиенту условия оплаты мебели.
5. Далее возможны два варианта: Клиент отказывается и на этом текущий бизнес-процесс прерывается; Клиент сразу полностью оплачивает заказ, и ему выдается чек об оплате; 6. Если бизнес-процесс не был прерван, то менеджер формирует бланк заказа, в котором указывает личную информацию клиента, выбранный тип изделия, дополнительные пожелания клиента. 7. Далее менеджер относит бланк заказа в проектный отдел, на этом поток событий данного прецедента заканчивается.
Рисунок 4.3 Поток событий прецедента «Оформление заказа» Вторым в последовательности событий бизнес-процесса «Продажа мебели на заказ» является прецедент «Проектирование», в котором описан процесс проектирования заказанной мебели. В данном бизнес процессе взаимодействуют два отдела: проектный отдел и отдел материально-технического снабжения.
Поток событий прецедента «Проектирование» (Рисунок 4.4): 1. Один из проектировщиков принимает бланк заказа от менеджера по работе с клиентами. 2. Проектировщик начинает разрабатывать проект изделия, и в процессе учитывает пожелания клиента. 3. Далее проектировщик оценивает материальные затраты на изготовление мебели.
4. Проектировщик формирует заявку на необходимые материалы и относит её в отдел по материально-техническому снабжению. 5. Оператор автоматизированного учета сверяет по базе данных наличие необходимых материалов.
6. Если необходимые материалы отсутствуют, то материально-ответственный кладовщик заказывает необходимые материалы у поставщиков, по факту доставки он их принимает и подписывает счет-фактуру. 7. После доставки, или если материалы были в наличии, материально-ответственный кладовщик сообщает о наличии необходимых материалов в сборочный цех.
8. Проектировщик относит готовый проект мебельным мастерам в сборочный цех. На этом поток событий данного прецедента заканчивается.
Рисунок 4.4 Поток событий прецедента «Проектирование» Третьим в последовательности событий бизнес-процесса «Продажа мебели на заказ» является прецедент «Изготовление», в котором описан процесс изготовления мебели. Поток событий прецедента «Изготовление» (Рисунок 4.5): 1. Мебельный мастер принимает проект изделия.
2. В соответствии с проектом мебельный мастер изготавливает необходимую мебель. 3. Далее приглашается ответственный за заказ проектировщик, для контроля качества изделия. На этом шаге последовательность прецедента «Изготовление» заканчивается. 
Рисунок 4.5 Поток событий прецедента «Изготовление» Таким образом, прецедентная модель бизнес-процесса «Продажа заказного продукта» построена.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Описание процессов/прецеденты.
Прецедент – это описание происходящих в предметной области. Он позволяет формировать требования к ИС.
Прецедент – это документ, описывающий последовательность действий исполнителя, который приводит к конечному результату (покупка товара).
— верхнего уровня или бизнес – прецеденты.
Прецеденты высокого уровня описывают наиболее важные глобальные процессы объекта (2-3 предложения).
Развернутые – подробное описание, включает типичный ход событий.
Прецедент является описанием как правило завершаемого процесса, в который входит несколько шагов и транзакций. Для описания прецедента необходимо определить субъекты и инициирующие действия.
На практике прецеденты представляются с различной степенью детализации.
Для формирования прецедентов необходимо иметь описание:
3. тип прецедента
4. описание прецедента
Выбор границы системы определяется целями исследования. Если рассматриваются проблемы изменения стратегии ОУ, т.е повышение конкурентоспособности, то рассматривается вариант 2. После определения границ системы осуществляется ранжирование прецедентов.
Выделяют 3 типа прецедентов:
1. Основные, описывающие общие процессы (покупка товара).
2. Вторичные, описывают уточняющие редкие процессы (запрос на ассортимент товара).
3. Дополнительные, описывающие процессы не реализуемые в системе.
Прецедент может быть представлен описанием нескольких шагов. Пошаговое описание процессов дает возможность :
— четко моделировать предметную область.
— осуществлять взаимосвязи между субъектами на едином языке.
Этапы та стадии SSADM.
SSADM регламентирует и поддерживает все этапы ЖЦ ИС.
Входом в технологию являются документы, инициирующие проект, а выходом являются проектные решения.
Структура ЖЦ ИС в SSADM реализуется каскадной моделью.
В SSADM выделяют 5 этапов проектирования и 7 стадий.
ТЭО – технико-экономическое обоснование
КП – каталог пользователей
КТ – каталог требований
КЗ – каталог задач
1 – предпроектное обследование
2 – выбор вариантов автоматизации
4 – выбор вариантов технической реализации
5 – логический проект
6 – физический проект
При реализации типового технического процесса проектирования стадия 1 может быть опущена.
Основной задачей анализа реализуемости является разработка ТЭО.
Анализ требований реализует 2 стадии: предпроектное обследование и выбор вариантов автоматизации.
Предпроектное обследование предусматривает описание существующей системы управления. Должны быть выполнены работы:
— определение границ исследования;
— изучение существующих информационных потоков и системы обработки данных;
— разработка логического описания существующей системы в терминах логики данных, функциональных задач, информационных объектов;
— определение КП, КТ при формировании недостатков существующей системы управления;
Итерационный процесс RUP.
Rational Unified Process — это:
· новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру;
· четко определенный процесс (технологическая процедура), описывающий структуру жизненного цикла проекта, роли и ответственности отдельных исполнителей, выполняемые ими задачи и используемые в процессе разработки модели, отчеты и т.д.;
· готовый продукт, предоставляемый в виде веб-сайта, содержащего все необходимые модели и документы с описанием процесса.
Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.
IBM Rational Unified Process — процесс, управляемый на основе прецедентов. Это означает, что в качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ используются сценарии использования. Сценарии использования позволяют легко выявлять реальные потребности будущих пользователей системы и отслеживать полноту описания этих требований. Они гарантируют выполнения требований заказчика к ПС. Кроме того, использование завершенных сценариев в качестве единицы измерения прогресса помогает избежать неадекватной оценки степени выполнения проекта исполнителем.
IBM Rational Unified Process предполагает разработку, реализацию и тестирование архитектуры на самых ранних стадиях выполнения проекта. Такой подход позволяет устранять самые опасные риски, связанные с архитектурой, на ранних стадиях разработки. Благодаря ему удается избежать существенных переработок в последний момент, если вдруг выяснится, что выбранное решение не обеспечивает, к примеру, выполнение требований к производительности системы.
Моделирование классов UML
В отличие от концептуальной модели ДК описывает программные сущности.
ДК иллюстрирует спецификацию программных классов и интерфейсов в приложении.
На ДК выносится:
1.Классы, ассоциации и атрибуты
2.Интерфейсы с операциями и константами
4.Информацияя о типах атрибутов
Для построения диаграммы необходимо выполнить работы по след. этапам:
1.Проанализировать диагр. взаимодействий и определить все классы, задействованные в конкретном проектном решении
2.Перенесение на д-му классов атрибуты, соответствующие понятиям из концептуальной модели (КМ)
3.Добавить имена методов на основе д-мы взаимодействия
4.Добавить информацию о типах атрибутов и методах.
Некоторые понятия из КМ (кассир, менеджер, товар) на ДК отсутствуют, т.к. на данной итерации нет необходимости разрабатывать их программное описание.
На последующих итерациях при появлении новых требований и новых прецедентов они вносятся в ДК.Определениее методов для каждого класса осуществляется на основании диаграммы кооперации. Например: если сообщение make line iteаm передается классу sale (говорят о методах), то в этом классе должен быть метод make line iteаm.
Отображение информации о типах атрибутов, методах зависит от ее использования разработчиком (программистом).
Если генерация кода осуществляется автоматически case-средством, то должна быть полная информация.
5. На д-ме классов ассоциации указываются стрелками (навигациями). Информация о навигации связана с видимостью объектов.
Модели SSADM.
Основное назначение методологии SSADM заключается в предоставлении участникам проекта технологии и инструментария для выбора стратегии разработки, формирования требований к ИС, проектирования и специфицирования ИС и ее компонентов. Основным преимуществом SSADM явл. обязательное участие КП (конечных пользователей) в процессе разработки. Для этого описываются их функции (разработчики, КП, менеджеры(управление коллективом разработчиков, планирование, контроль, регулирование видов работ)).
Распределение обязанностей между участниками проекта дает возможность повысить качество проектных решений (подписи участников). Регламентация работ осуществляется в рамках модульной структуры ЖЦ. Модульная стр-ра определяет стр-ные аспекты моделирования, действия и связи между ними, кот-е представляются инфо-ми потоками, регламентирующие результаты этих действий. В каждом модуле подробно расписываются его цели, действия, результаты.
Под моделью в SSADM понимается процесс описания проектирования ИС от инициирующего документа до получения проектных решений.
Выделяют 5 модулей ЖЦ ИС:
АР (анализ реализуемости),
СЛС(спецификация логической стр-ры),
Диаграмма состояний.
Модель взаимодействий (interaction model) является источником детализированной спецификации прецедента. Модель состояний (statechart model) служит детализированным описанием класса, т.е. описание динамического изменения состояний классов.
Состояние (state) объекта обозначается текущими значениями его атрибутов. Модель состояний (statechart model) фиксирует «жизненный путь» класса.
Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Прецеденты должны соответствовать бизнес-правилам.
Диаграмма состояний определяет способ реагирования объектов класса на события. Диаграмма определяет для каждого состояния объекта определенное действие (action), которое должно быть выполнено после получения сообщения или сигнала.
Изменение состояний объекта осуществляется по схеме событие / условие / действие.
Событие может быть защищено ограждающим условием.
Действие (action) — короткое вычисление, выполняемое при срабатывании перехода. Действие — это отклик объекта на обнаруженное событие.
Состояние может состоять из вложенных (nested state). Составное состояние (composite state) является абстрактным. Переход может сработать от любого из вложенных состояний. Это делает диаграмму более ясной и лаконичной.
Дата добавления: 2018-02-15 ; просмотров: 1112 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Прецедент бизнес процесса это
Определение прецедентов (вариантов использования)
Необходимый первый шаг для достижения заветной цели — понять, чего же вы хотите.
Бен Штайн (Ben Stein)
Анализ требований может включать описание процессов или сценариев использования приложения, которое может быть представлено в форме прецедентов.
Прецеденты — это повествовательные истории об использовании системы, которые широко используются для осмысления и формулировки требований. Они оказывают влияние на множество аспектов проекта, включая ООА/П. Построить диаграмму прецедентов может быть просто, а их описание может занять несколько недель, или даже больше.
Описание прецедентов (вариантов использования)
Исполнителем (actor) называется сущность, обладающая поведением, например, человек (идентифицируемый по роли, к примеру, кассира), компьютерная система или организация. Сценарий (scenario) — это специальная последовательность действий или взаимодействий между исполнителями и системой. Его иногда также называют экземпляром прецедента (use case instance). Это один конкретный сценарий использования системы либо один проход прецедента, например, сценарий успешной покупки товаров за наличный расчет либо сценарий неудачного завершения покупки из-за прерванной транзакции по обработке данных кредитной карточки.
Прецедент — это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого для конкретного исполнителя результата.
В контексте UP модель прецедентов (Use Case Model) относится к дисциплине “Требования”. Действительно, требования — это весь набор прецедентов, т.е. модель функционирования системы и ее окружения.
Описания прецедентов — это текстовые документы, а не диаграммы. Моделирование прецедентов — это процесс написания текста, а не рисования.
Модель прецедентов может включать диаграммы прецедентов на UML, отражающие имена прецедентов и исполнителей, а также их взаимоотношения. Диаграммы прецедентов позволяют оценить рамки системы и ее окружение, а также обеспечивают простой способ перечисления имен прецедентов.
Зачем нужны описания прецедентов
У потребителей и конечных пользователей есть свои задачи, решение которых должна обеспечить компьютерная система. Эти задачи могут варьироваться от регистрации торговых операций до оценивания объемов добычи нефти из перспективных месторождений. Существует несколько способов выделения этих задач или системных требований.
Наилучшие из них достаточно просты и доступны, поскольку это облегчает участие конечных пользователей в определении требований к системе. А участие в этом процессе потребителей снижает риск провала проекта. Эти рассуждения могут показаться очевидными, но они очень важны. Одной из главных причин провала проектов по разработке программных систем является недостаточное привлечение пользователей к процессу разработки. Поэтому важность участия пользователей в процессе анализа системы трудно переоценить.
Прецеденты — это механизм упрощения этапа формулировки требований для всех заинтересованных лиц.
Ориентация на цели и задачи пользователя
Важной особенностью описания прецедентов является их ориентация на цели и задачи пользователя. В процессе описания необходимо задавать вопросы: “Кто является пользователем системы? Каковы типичные сценарии использования системы? Каковы цели и задачи пользователей?”.
Такой взгляд на систему гораздо больше ориентирован на пользователя, чем обычный список системных требований. Зачастую прецеденты нужно продумывать гораздо детальнее. Но основная идея состоит в исследовании и формулировке функциональных требований путем написания историй “из жизни системы”. Эти истории помогают сформулировать различные задачи и представляют собой сценарии использования системы. На первый взгляд, описать прецеденты не сложно, хотя зачастую достаточно трудно определить, что требуется от системы и описать это на нужном уровне детализации.
Исследование целей, а не обязанностей и процедур, позволяет сосредоточить внимание на основных требованиях. Например, на одном из семинаров кассир может сказать, что одной из его целей является регистрация в системе. При этом он может иметь в виду элементы интерфейса пользователя, соответствующие диалоговые окна, ввод идентификатора и пароля. Однако все это — механизмы достижения цели, а не сама цель. Изучая иерархию целей (отвечая на вопрос “какова цель этой задачи?”), системный аналитик приходит к формулировке, независимой от механизма реализации: “идентифицировать себя и выполнить аутентификацию” или на более высоком уровне — “предотвратить утечку информации”.
Описание прецедента в формате “черный ящик” (black-box use cases) — это самый типичный и рекомендуемый тип описания прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн. Наоборот, системе вменяются некоторые обязанности (responsibilities).
Этот метафорический термин широко применяется в объектно-ориентированном проектировании: программные элементы имеют обязанности и взаимодействуют с другими элементами со своими обязанностями. Определяя обязанности системы через прецеденты типа “черный ящик”, можно указать, что должна делать система (функциональные требования), не расписывая, как это делать (не выполняя проектирование).
Вообще, термины “анализ” и “проектирование” зачастую сводятся к вопросам “что” и “как”. Это важные вопросы в хорошей программной разработке. В процессе анализа требований нужно избегать принятия решений “как”, а описывать лишь внешнее поведение системы как черного ящика. Позднее, на этапе проектирования, создается решение, удовлетворяющее разработанной спецификации.
На первый взгляд, требование обеспечения ощутимого результата может показаться очевидным. Однако в сфере программного обеспечения известно множество неудачных проектов, которые провалились из-за невыполнения реальных задач пользователей. К такому отрицательному результату может привести подход к описанию системных требований в виде списка свойств и функций системы, поскольку он не заставляет заинтересованных лиц рассматривать требования в более широком контексте для достижения некоторого ощутимого результата или некоторой цели. В отличие от этого подхода, в контексте прецедентов свойства и функции системы ориентированы на достижение цели.
Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому при описании прецедентов необходимо идентифицировать исполнителей и их задачи, которые должны быть решены в результате создания системы. При таком подходе несколько смещаются акценты аналитиков.
Вместо вопроса “Каковы задачи системы?” возникает вопрос “Кто является исполнителем и каковы их задачи?”. Чтобы отобразить эту взаимосвязь, имя прецедента должно соответствовать названию задачи. Например, задаче электронного оформления продажи должен соответствовать прецедент «Оформление продажи». Таким образом, ключевая идея состоит в том, чтобы для выделения прецедентов исследовать задачи исполнителей.
Источник: system-inform.wixsite.com