Форум Сообщества Аналитиков
Общий раздел => Методологии => RUP EUP AUP OpenUP => Тема начата: Galogen от 06 Февраля 2007, 10:12:53
-
Уважаемые аналитики. Бизнес-аналитики, системные аналитики. Опытные аналитики и только начинающие. Срочно, просто срочно требуется внятная консультация.
Многие меня на форуме знают. Я не новичок в целом. Но все равно пока не могу "сшить" одно с другим. Прежде чем задать вопрос некоторые мыли по поводу понимания самого процесса RUP и использования ООАП.
Не будем говорить о том, когда и зачем нужно бизнес-моделирование. Возьмем это за постулат. Оно нужно всегда. Пусть оно простое, в целом очевидное. Все равно оно требуется для задания контекста, для создания красочных иллюстраций, для обучения наконец.
Бизнес-моделирования какрезультат должно привести к построению как минимум двух моделей: модели бизнес-вариантов использования и модели бизнес-объектов. Модель бизнес-объектов - задает, определяет статическую структуру бизнес-систему, модель вариантов использования - поведение системы. Бизнес варианты-использования обычно сводят до уровня пользователя такой бизнес-системы: внешние действующие лица, ради которых собственно и работает бизнес, производит некоторую ценность. Внешние действующие лица часто являются участниками, инициаторами, источниками и потребителями бизнес-процессов системы. Очевидно у бизнес-системы могут быть один или несколько основных бизнес-процессов, куча вспомогательных. Каждый такой бизнес-процесс, выделенный и очерченный в ходе анализа, является отличным кандидатом на подсистему в будущей системе, которую мы захотим построить. естественно IT-специалиста в первую очередь интересует информационная составляющая таких процессов.
Бизнес-вариант использования может быть детализирован диаграммой деятельности или диаграммой последовательности. Отдельная деятельность может стать хорошим кандидатом на системный вариант использования.
Т.е. в RUP на мой взгляд прослеживается такой переход от БМ к модели системной:
1.Внешнее действующее лицо трансформируется либо в основное действующее лицо(пользователя системы) либо становится третьестепенным(закулисным)либо становится классом-сущностью системы
2.Бизнес-вариант использования становится подсистемой системы или остается вариантом использования системы
3.Деятельность может стать отдельным вариантом использования системы
4. Бизнес-имсполнитель превращается в основное действующее лицо системы(пользователя системы) или превращается в управляющую автоматическую структуру.
Это, конечно , рекомендации, а не руководства к действию. Но в целом мне кажется вполне логичным
Однако-таки есть червячок сомнение, этакая вольная интерпетация того, чего может я не понимаю на самом деле.
Хотелось бы предложить некоторую практическую задачу, для анализа и устранения ошибок.
Задача чисто вымышленная.
Предположим мы с вами организовали небольшой бизнес: скажем маленькое студентческое кафе (такое я видел в Португалии в их техническом универститете): 10 столиков, а то и того меньше, по 4 человека за столик. Относительно разнообразное меню: закуски, вторые блюда, первые блюда, выпечка, десерты, напитки. Пусть для простоты и опрделенности сделаем как это было в Португалии: каждый день кафе анонсирует пять блюд: обычно это рыба в сочетании с разным гарниром и 1-2 блюда с мясом: - это основные блюда. Есть еще супы, но они не анонсируются.
Естественно у нас есть повар с помощниками, кассир, директор, бухгалтер, закупщик продуктов. Это роли. Штат значение не имеет.
Основным бизнес-процессом будет обслуживание клиента, нужно также организовать закупку свежих продуктов, приготовить блюда, решать разные оргвопросы.
Какие проблемы возникают и зачем нам строить информационную систему? Ну скажем нужно знать какова средняя интенсивность обслуживания, какое количество продуктов требуется на день, какова выручка, что следует сдлеать чтобы увеличивать прибыль и поддерживать качество обедов и обслуживания. Очевидно для ответа на эти и другие вопросы нам нужна информация. Чобы получить ее нужна ежедневная регистрация данных: сколько каких продуктов купили, сколько народу посетило кафе, какие блюда пользуются спросом, какие цены выставлять, и т.п.
Начинаем строить контекст, используя инструментраий UML.
Внешние действующие лица:
клиенты (студенты, преподаватели, возможно случайные посетители вуза) - те кто приходят покушать
поставщики (магазины, рынки, торговые базы) - все те, у кого мы закупаем продукты
администрация вуза - кому мы оплачиваем аренду, кто обеспечивает законность нашего бизнеса - есть возможность, что мы не образуем отдельного юридического лица - 1 вариант, а можем быть и самостоятельным юридическим лицом - тогда появляется еще связь с налоговыми органами
санитарные службы - у которых мы должны получить лицензию
Очевидно, не все из перечисленного значимо для нашего случая, однако очевидно, что важными для нас будут клиенты, поставщики, администрация.
Основным вариантом использования уровня облака или воздушного змея наверное будет "Обслужить клиента", а цель получение прибыли от своей деятельности, очевидно. Если детализировать это процесс, то вероятно можно выделить:
БП1: Накормить клиента - (ДЛ клиент)
БП2: Приготовить блюда - (включается в БП1) ???
БП3: Закупить продукты - (Дл постащики)
БП4: Оплатить аренду - (ДЛ администрация вуза(бухгалтерия вуза))
БП1: Накормить клиента
1. Клиент изучает меню.
2. Клиент выбирает блюда.
3. Продавец-официант выдает заказанные блюда
4. Кассир расчитывает сумму и выбивает чек
5. Клиент расплачивается разрешенным способом(наличными или кредитной картой)
6. Клиент есть свой обед
7. Клиент относит посуду.
БП3: Закупить продукты (доставит продукты??)
1. повар планирует меню следующего дня
2. Повар составляет реестр необходимых продуктов
3. Закупщик закупает продукты у поставщика(в магазине, оптовой базе)
4. Поставщик выдает накладную (счет-фактуру)
5. Закупщик доставляет продукты в кафе
6. Бухгалтер оформляет поступление продуктов
Останавлюсь пока на этом, поскольку чувствую что-то не совсем так....
Однако скажем посел построения БМ - я перейду к системе:
Очевидно - пользователями будут кассир, бухгалтер, повар, закупщик??
а варианты использования будем рассматриватьс точки зрения уже их:
Кассир: рассчитать клиента
Повар: составить реестр продуктов, составить меню
Закупщик: составить заказ
Бухгалтер: Оприходывать продукты, Рассчитать арендную плату, что-то еще?
Директор: провести инвентаризацию....
Вот такая каша в голове? Может кто-то поможет сделать это ясным, логичным и точным?
Но нужно как можно скорее, через неделю начинаются занятия, не хотелось бы учить ошибкам...
-
Развитие идеи. Сегодня сидел со воей коллегой 4 часа. Интенсивно обсуждали вопрос моделирования и вот к чему пришли. Прошу судить, делать замечания, ругать и хвалить...
Итак, рассматривается бизнес: Студенческое кафе.
Попытаюсь описать возможные функции. Поскольку бизнес придуманный, то естественно вводятся определенные ограничения
1. Обслужить посетителя. Участники: посетитель, официант, кассир, уборщик
Посетитель садится на свободное место, изучает меню. Официант принимает заказ, идет на кухню, получает заказ, приносит заказ и квитанцию заказа. Посетитель ест, по завершению трапезы идет к кассиру и дает ему квитанцию заказа(список заказаных блюд). Кассир подсчитывает сумму, принимает деньги посетителя, выдает сдачу и чек. Уборщик убирает посуду, протерает стол.
2. Составить меню. Участники: Повар
Повар составляет меню блюд. Блюда деляться на первые, вторые, салаты, десерт, напитки, выпечка.
3. Составить калькуляцию блюд. Участники: менеджер.
На основании меню, менеджер составляет калькуляцию каждого блюда.
4. Анализировать потребности в продуктах. Участники: менеджер.
Используя калькуляцию блюд, зная средние потребности в продуктах менеждер составляет заказ на закупку продуктов.
5. Закупать продукты. Участники: Закупщик, оптовая база, столовая.
Закупщик на основании заказа на продукты закупает продукты и полуфабрикаты в оптовой базе. Получает деньги у бухгалтера на закупку продуктов. Оптовая база выдает продукты, составляет счет-фактуру (или другой документ). Закупщик доставляет продукты в кафе. Сгружает продукты, отдает бухгалтеру накладную на закупленные продукты.
Выпечка закупается в столовой, с которой есть договор.
Доставку осуществляет закупщик транспортом кафе.
6. Готовить блюда (кухня). Участник: Повар, Помощники повара.
Повар с помощниками согласно меню, калькуляции блюд и средней потребности готовит блюда (первые, вторые, салаты, десерты, горячие напитки(чай, кофе))
7. Предоставлять отчеты и выплаты. Менеджер,Бухгалтер
Менеджер составляет отчеты руководству вуза (где располагается кафе), в налоговые органы.
Бухгалтер рассчитывает выручку, начисляет налоги, фиксирует затраты, начисляет и выплачивает зарплату, выдает деньги на закупку.
Я решил выделить три бизнес ВИ или три бизнес-процесса. Например Готовить блюда - это контекст системы, нам невидимый, также составления меню, калькуляция и анализ.
Т.е. я оставляю на диаграмме только те процессы, в которых участвуют внешние действующие лица (Посетитель, Налоговые органы, Оптовая база, Столовая, Администрация вуза)
Вот что получается:
-
Обслужить посетителя - думаю тут довольно ясно прописан основной ход действия.
Я ограничиваюсь тем, что кафе ориентировано на несложные, но качественные блюда. Количество посадочных мест скажем 5 столиков по 4 человека. Средняя продолжительность пребывания полчаса.
В обслуживание можно добавить отдельным ВИ - скажем обеспечивать торжественные заказы: свадьбы, вечеринки
но думаю для нашего студенческого кафе можно и не рассматривать, если полагать, что кафе располагетсяв учебном корпусе (тут лекции идут а в кафе гулянка:)) Тем более, что горячительные напитки мы исключаем
Закупать продукты - возможно имеет смысл разбить на
Закупать продукты в оптовой базе (закупается все, кроме выпечки) Закупка производится скажем для простоты в одной оптовой базе.
Закупать выпечку - закупается в столовой
Предоставлять отчеты и выплаты - в первую очередь имеется в виду важные отчеты, без которых бизнес могут прикрыть (тут фантазия работает слабо:-), но для игровой ситуации думаю потянет) а также важные отчисления: за аренду, налоги.
Не стал рассматривать деятельность по рекламе, улучшению имиджа кафе, дизайн и прочее.
Решением может быть например - автоматизация регистрации, выполнения и оплаты заказа (скажем проблема более быстрого рассчета посетителей, проблема ухода посетителей без оплаты)
Можно напридумывать что-то типа:
Официант принимает заказа. Вводит заказ на терминале. Получает фишку с кодом. Приносит заказ и фишку посетителю. Посетитель отобедав, идет к кассиру, подает фишку. Кассир кидает фишку в некое устройство. устройство считывает код, отображает заказа клиента с подчетом итоговой суммы. Клиент расплачивается, получает чек и сдачу. Кассир закрывате заказ - делает его проведенным
-
Дома хорошенько подумаю. А пока ремарка, чистое IMHO.
1) Важно понимать, что бизнес-процессы связаны между собой.
Например, прямая связь закупка продуктов - обслуживание посетителя: предоставляет продукты, обратная связь - предоставляет материалы для корректировки и планирования.
Обслуживание потребителя и закупка продуктов предоставляют материалы для расчёта налоговых выплат и средства для их произведения.
2) Владельцы процессов всегда пересекаются, иначе нет основания объединять варианты использования в одни рамки системы (в данном случае - не IT-системы, а системы гораздо важнее - производственной!). Посетителя обслуживает столовая. У оптовой базы материалы также обслуживает столовая. Столовая платит налоги, администрация ВУЗа выступает гарантом. (Кстати, что раньше по логике вещей? :) Порядок важен.)
3) Отчёты и выплаты по налоговому учёту и закупка продуктов - обеспечивающие БП.
Не думай сразу про автоматизацию: вся IT является мелочью по сравнению с получением прибавочной стоимости, её получали до IT и будут производить после :) .
Попробуй сделать что-нибудь невымышленное. Умозрительный эксперимент - это хорошо, но его результаты нельзя проверить. Чем часами ломать копья - расспроси лучше знакомого официанта или повара о том, как всё устроено.
-
Попробуй сделать что-нибудь невымышленное. Умозрительный эксперимент - это хорошо, но его результаты нельзя проверить. Чем часами ломать копья - расспроси лучше знакомого официанта или повара о том, как всё устроено.
Спасибо Саша. Очень хорошо обсказал по взаимосвязи. Я ее конечно вижу и чувствую. UML такую свзяь явно не дает. Долой UML - все верно. Бери то, что лучше отражает семантику.
Однако стоп, вся идея состоит вот в чем.
Я хочу дать некие темы для организации бизнеса и только. Пусть народ сам подумает, придумает. Хотите узнать лучше - иди к знакомому официанту (кстати ну нет у меня знакомых официантов), однако многие из нас не раз бывали в столовых, кафе, закусочных, ресторанах. Не важно. пусть придумают то, что придумали. и действуют в рамках придуманного.
Если я дам им свою придуманную задачу - будет кавардак, дать реальную задачу - невозможно в рамках курса. Можно только индивидуально на курсовой, дипломе, когда человек действительно будет что-то делать не для вымышленной истории. А тут игра.
Цель не придумать супер-пупер корректный бизнес, который в реальности принесет прибыль, будет доходным и прочее. Просто пусть придумают хоть что-то. Думаю команда из 5-7 человек, основываясь на совем опыте, опыте друзей, знакомых и прочая, могут что-то придумать, что-то понятное им. Моя задача держаться в рамках этого придуманного, не вылезти в дикую фантазию.
В целом мы в какой-то степени делаем что-то наоборот, ну и что, пусть появится опыт.
Когда я постил первый пост - был в ужасе о каши в голове. Сейчас немного прояснилось после 4-часовой дискусии, мозгового штурма. Мы никакю идею не откидывали, все клали в кучу.
Например: наше кафе будет само готовить или брать готовые блюда в столовой, ресторане, магазине, а потом просто их расскладывать, подогревать и т.п. Пожалуйста рассмотрим и выберим тот вариант, что нам по душе.
Как обслуживание идет? Просто выбираемна выдаче блюда, ставим на поднос, расплачиваемся, кушаем. Или как описал я? А может совершенно по другому? Не важно - ты придумал, ты и обоснуй, даже вернее не обоснуй, а держишь в этих рамках. Раз уж придумал, что оплачиваешь после, так и в товей модели не должно быть противного.
Какая цель - попытаться! именно попытаться! показать как от одного переходим к другому, почему это появляется тут, откуда оно появилось, почему оно появилось. Есть и контроль! Если нет в описании оплаты по кредитной карточке, то откуда вдруг у тебя появилось Кассир проверяет платежеспособность кредитной карты? Хочешь сделать это - обоснуй, сделай это усовершенствованием.
У меня нет цели рассказыать все о РУП процессе или пройти с ними весь UML в тонкостях. Нет у меня ресурсов времени на это, потому довольствуюсь малым. Мы пока не проектируем, мы пока уясняем, а что нам нужно: концепция + часть логики.
У них уже есть некоторый опыт моделирвания втехнологии SADT, пусть сравнят.
Идеально было бы начинать с требований. Я формулирую требования (то есть играю роль бизнес-аналитика), а студенты изучают их, анализируют идут на логический уровень. Но это уже проходилось - лажа полная получается. Хотя просмотрев несколько книг: Ларман, Мацяшек, Румбо и т.п. везде примеры задачи рассматриваются фактически от требований бизнеса, т.е. уже предлагается некая оценка.
Остановится только на бизнесе - рано им еще, надо пощупать инструменты, технологии, попробывать свои проекты на ООП, базах данных, и вот тут наложить на их хоть малюсенький опыт что-то более обобщенное...
Хотя в лекциях хочу рассказать сути БП их видах и прочее. если у тебя есть материальчик в доступной и четкой (без лишней воды) форме, дай буду просто признателен..
А потом я хочу провести эксперимент - посмотрю, что будет. Получится или нет, большой беды не будет надеюсь. Тем более у меня еще летом с ними практика 60 часов, вот можно будет продолжить, показать что-то поправить.
Главное что - не хочется нести полную лажу, или выдавать свои собственные заблуждения за истину. Студенты народ внушаемый - сказал препод, так оно и есть. Хотя я своих студентов всегда учу - я не семи пядей, я не всезнайка, я человек, а человеку свойственно заблуждаться. Единственная разница(конечно важная) я вынужден их оценивать, а они меня нет:-). Но я всегда даю скиду, фору...
Я таки-надеюсь выбить для вуза лицензию на EA, там ведь есть бизнес-процессы. Думаю то, что ты написал лучше описывать с помощью eEPC (так вроде пишется). Но мне надо изучить это самому - а потом лезть в омут:-))
Может мне удасться гармонично связать в будущем Теорию информационных процессов и систем с курсом ОО моделирование и лекции, и практику.
В любом случае, ответственность за мной. Ни с кем из вас я ее разделить не смогу, стыдно будет мне одному. Но и это не важно, главное дать знания, пусть 5 %. Уже хорошо. А главное конечно понять самому...
-
Не думай сразу про автоматизацию: вся IT является мелочью по сравнению с получением прибавочной стоимости, её получали до IT и будут производить после
Конечно, ты прав. Сегодня IT, завтра телепатия или магия. Все преходяще.
Но повторю, я не ЭКОНОМИСТ, я не учу ЧТО ТАКОЕ БИЗНЕС, конечно приходится это учитывать, но лишь в контексте как раз вот этой самой IT.
-
Если по сути то все вроде нормально.
Есть несколько ремарок:
1. ВИ "Обслужить посетителя", должен называться подругому, т.к. название ВИ должно нести хоть какую-то цель его актеру. Н-р, можно назвать - "Покушать" или как-то еще.
2. Все процессы, которые ты указал, можно показать на ДВИ реализации, т.е., н-р, ВИ "Покушать" реализиуется с помощью ВИР "Приготовить пищу", "Сделать меню" и т.д.
3. Связи м/у ВИ, т.е. м/у БП, можно указать в Бизнес Правилах.
З.Ы. Народ опять же будет спрашивать: а цель какая у тя при моделировании БП? Я думаю тут можно ограничиться двумя: очертить границы системы и понять контекст работы производста. Возможно, есть и более лучшие способы описать БП, чем это делать с помощью ЮМЛ, но Эдуард, хочет выстроить полную цепочку моделирования именно с помощью ЮМЛ.
-
В своих поисках решения я полагаюсь на десяток книг. Что я вижу в книгах.
И уважаемый ларман, Коберн, Рамбо, Фаулер и некоторые другие, все они скрывают бизнес-анализ и получают сразу бизнес-требования. Как они получены, почему, какая логика - к сожалению отсутствует.
Далее, их примеры - уже есть куча программных компонентов система ПОС, система авторизации платежей и т.п.
Из конектса вообще не ясно, а чем их ПОС не устраивает. Однако на всем этом строится весь процесс доказательств и обоснований. А по сути идет некий реинжиниринг. Такая идея у меня была, но придумать нормальный процесс для студентов - повесится можно, а делать 1 на всех, не понятно как оценивать.
Потому я и использую поместь реинжиниринга с придумыванием бизнеса
Далее есть-таки одна книга, которая довольно хорошо дает свЯзь всех моментов моделирования и проектирования. Потому я в некоторой степени руковдствуюсь ею. Однако к сожаления и в этой книги очень важные детали на мой взгляд скрыты. Например в книге говорится что на основании анализа нами выделено около 30-40 прецедентов, после их изучения мы некоторые отбросили, другие заменили, третьи не соотвествуют нашей задаче, в результате оставили только во эти, что показаны на диаграмме.
Приведена там диаграмма уровня неба. И называется Обслужить пациента с кучей ВДЛ. В том числе и пациента. И я согласен. Это уровень неба, потому и цель всего бизнеса как такого, а не части его участников.
Далее идет более детальное представление. И опять в терминах скорее цели не пациента.
Почему? Я думаю потому как пациент - третьестепенное лицо, возможный триггер, имеющий интерес.
Хотя именно по этому я и задал в посте вопросы, связанные с этим моделированием.
-
Это исключительно ответ на первый пост. Остальное надо обдумать... так что, наверное, продолжение следует...
У меня постоянно складывается впечатление, что за проблему бкрутся не с той стороны.
Сережа! Именно, потому и спрашиваю. Знал бы прикуп,жил бы в Сочи(с). :-)
Теперь от том, что ты написал! Великолепно - просто замечательная постановка вопросов. Буду брать на вооружение. Пошла конкретная помощь практикующего аналитика.
Теперь оправдания: Взять готовый бизнес - дело неперспективное. Потому я и предлагаю студентам в течение 2 недель в группе из нескольких человек придумать этот бизнес самим.
Следующее занятие - презентация бизнеса и формирование проблемы, вся аудитория студентов (надеюсь направляемая мною с коллегой) должна задать вопросы по бизнесу и этим возможным проблемам. Т.е. в нашем случае - это исключительно 1 вариант. Второй вариант - не наш. Я не могу учить, как создавать бизнес. Мы будем руководствоваться логикой и здравым смыслом + личным опытом.
Как получится эта презентация и интервью, сказать не могу. Попробуем - доложу. Очевидным будет все-таки поиск проблемы, которую можно решить через построение ИС, сбор и учет информации и ее анализ.
Естественно у директора кафе может быть проблема - где взять кредит на ремонт кафе, и явно мы ему в этом не поможем.
А вот в других вопросах - здесь есть перспектива. Пусть даже проблема надуманная. А посмотри все примеры в книгах, разве там есть хоть одна не надуманная проблема? Что не было ИТ - не было возможности контролировать все это? проблема не в этом, а в эффективности, скорости, своевременности, достоверности.
Обрати внимание, в следующем посте я показываю проблему - некоторые посетители уходили не заплатив или пытались оспорить предъявленную оплату. Главное, что проблема затрагивает возможность (а не необходимость) изменения сбора информации и учета.
После этого мы выясняем детали всех имеющихся в модели сценариев и там выясняется, что нужна ежедневная регистрация данных и т.д. и т.п
Только после этого в моей модели появятся ВИ "Обслужить клиента", а может и вовсе не появится.
Они там появятся исключительно по ниточкам, пришедшим от основных проблем "Унать ЧТОТОТАМ"
Сережа, но есть же очевидные вещи. Кафе - это СМО, сегодня густо, завтра пусто.
-
И еще.Но кто сказал, что при решении моей проблемы мне интересно обслуживание клиента в целом?
Почему не что-то другое или только часть обслуживания клиента? Мне не нужно кафе в целом, нужно решить конкретную проблему, не перегружаясь лишней информацией.
Сергей, я понимаю лишь то, что мы друг друга не понимаем и вероятно никогда не поймем. Мотивации нет, нет совместных проектов.
Я обращаюсь с конкретной просьбой, вопросом, советом. А мне в ответ ушат слов - понять, которые не всегда возможно. Ты порой пишешь, вероятно держа в голове, кучу всяких понятных тебе понятий, но я их не знаю.
Исходи из того, что перед тобой ученик, студент.
Задача есть - не будем ее менять. Выдели ту проблему, которая кажется тебе интересной, покажи ход мысли в качестве примера.
Если что-то непонятно, можно ведь уточнить.
Про трассировке не очень понимаю, нужен пример.
-
2 Boatman,
Ну предположим, что проблемы все мы выснили и поняли, что надо провести БМ части БП, которые описал Эдуард. Просто если еще студента начать грузить проблемами, да еще их выяснять, он никогда задание не сделает.
Кстати, есть хорошая книга, которая как раз рассказывает как докапаться до корневой проблемы, перейти от проблем к БМ, от БМ к СМ, от СМ к требованиям и т.д. и т.п., но она на англ. языке:
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=64
-
При придумывании бизнеса, допустим, маркетинговую и балансовую часть бизнес-плана мы опускаем. Остается часть с описанием бизнеса - пакет регламентов или что-то подобное, можно в виде модели. НО ПРИЧЕМ ТУТ АВТОМАТИЗАЦИЯ?
Если вы проектируете автоматизированный бизнес, то система автоматизации уже закладывается в него, как любой другой инструмент и особое внимание ей не требуется.
Основанием для разработки системы автоматизации является концепция с готовым описанием объекта автоматизации (бизнес-процессов)
Согласен с тобой, Сергей. Возможно я передергиваю, и чего-то не понимаю. Вот и будем понимать это вместе со студентами.
Да автоматизация подразумевается. Иначе зачем приглашать для решения проблемы ИТ-специалиста.
Я также хочу проэкспериментировать с возникновением этих проблем, пусть студенты сами их попробуют придумать. Главное правильно показать как их выявлять, согласен?
Давайте используя описанный бизнес сформулируем проблемы. Пусть они будут надуманы, несовсем очевидные, но определенные.
Берем тоже кафе: ты уже выписал ряд определенных проблем.
1. Проблема - трудно, сложно создавать план закупок продуктов на день. Информация по расходам продуктов есть, но она колеблится день ото дня, сложно быстро подготовить или быстро сорректировать план. Людей в кафе немного, каждый совмещает множество обязаностей. Взять на работу лишнего человека не по карману. Есть проблема иногда перерасхода продуктов (особенно опасно скоропортящиеся, выпечка), а иногда недобор продуктов, приходится докупать, отвлекать персонал, создаются проблемы в быстром и качественном обслуживании посетителей
Кого касается: менеджер, посетитель, директор, столовая, оптовая база (поправьте если я ошибаюсь, а ошибка кажется есть)
Результат: повышаются издержки на закупку лишних продуктов или их порчи при недоиспользовании, посетитель вынужден уйти недождавшись заказа (из-за отсутвия нужных продуктов для приготовления блюд или из-за необходимости ждать когда блюдо будет приготовлено)
Выгода от решения: снимит издержки при закупках, позволит быстро подготавливать заказ на закупку, поможет четко контролировать требуемые запасы
Пока остановимся на этом. Сначала "обсосем"(Boatman) - это. что правильно, что не правильно.
-
Сергей, искренное спасибо за помощь. Восхищаюсь мужеством, терпением и тактом, а также содержательностью ответа и самопожертвованием твоим при его создании.
Многое становится яснее. По поводу целей и проблем и так ненависного тебе и "т.п.". Не сомневайся это и "т.п." я ввожу только в посте. Не будет "и т.п." у студентов, не будет множества проблем и целей. Каждый (или каждая пара) возьмет и будет рассматривать свою проблему, моя задача как преподавателя помочь им ее выделить и сформулировать.
Общую концепцию подхода я понял. Но одного не понял все-таки.
Все авторитеты использования UML (в частности в RUP) говорят, на диаграмме BUC должны присутствовать только внешние к бизнесу актеры, инетересы и цели которых наш бизнес удовлетворяет. На твоих диаграммах мы видим главным образом именно бизнес-исполнителей, а не бизнес-актеров. И в этом трудность понимания. Опять же следуя авторитетам бизнес-исполнители появляются на диаграмме деятельности, диаграмме бизнес объектов (реализация BUC) и диаграмме последовательностей. Переход к системным ВИ происходит из модели бизнес-объектов.
На твоих рисунках строится диаграмма с точки зрения исполнителей, чем тогда будет отличатся бизнес-модель от системной модели вариантов использования?
Еще раз огромное спасибо за интерес к проблеме. Мне кажется эти публикации вызывут интерес и у наших посетителей. Предлагаю довести (по мере возможности) этот или другой пример до уровня рекомендаций, статьи...
-
Кажется начинает что-то проясняться.
И вот что я подумал. Если мы рассматриваем бизнес как прозрачный ящик, описываем возможные BUC, то может изображать не саму диаграмму BUC, а диаграмму деятельности.
Или по другому, имеет смысл изображать и то, и другое?
Например, у Шмуллера при описании ресторанного бизнеса я увидел такой подход:
1. Интервью с администратором
2. Рисование диаграммы деятельности на его основе (там основной процеес именно обслуживание клиента)
3. Формирование диаграммы классов
4. Выделение ролей и определение для них вариантов использования
Я привел это лишь для примера
-
Вообще для ответа, что рисовать, надо бы разобрать несколько примеров на чртение диаграмм.
Вот каr бы ты, Эдуард, прочитал последнюю диаграмму в этом посте?
Клиент обращается в ЗАО "Рога и копыта", чтобы Получить обслуживание. В ходе обслуживания Продавец с помощью Кассового аппарата Пробивает чек.
Директор забирает дневную выручку у Продавца (вероятно в конце рабочего дня). Директор Узнает дневную выручку ???(Может узнает количество дневных посещений). Директор для чего-то Узнает среднюю интенсивность обслуживания в месяц. Директор Вычисляет интенсивность обслуживания в месяц, вероятно в конце месяца, чтобы потом ее когда-то узнать или что-то предпринять на базе этой информации :-)
-
Сергей, нет ли у тебя полного шаблона описания варианта использования.
У меня есть множество различных вариантов, а на каком остановится не знаю. Хотелось бы иметь самый полный или, например, который ты чаще всего используешь и считаешь оптимальным.
-
По поводу обучения предполагается примерно такая программа:
1 занятие. Семинар - фантазийное формулирование бизнеса на тему, предложенную преподавателем. Командная работа. Метод мозгового штурма. Цель: нафантазировать бизнес в меру своих возможностей. Преподаватель как направляющая сила. Домашнее задание - закончить фантазии и сделать презентацию своих концепций и идей. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.
2 занятие. Семинар - обсуждение презентаций. Презентация 10 минут, 20 минут обсуждение. Обнаружить, высказать проблему(ы). Группа выступает аудитория задает вопросы (4 выступление за семинар, не хватит времени перенос на лекцию). Домашнее занятие: уяснение проблемы, причин возникновения проблемы, участников проблемы, негативных последствий проблемы, что изменит в лучшую сторону создание новой системы.
Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.
3 занятие. Обучение написанию вариантов использования в контексте выявленной проблемы. Примеры, написание варианта использования по каждой теме групповых заданий. Домашнее задание: написание сценариев для выявленных ВИ. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.
4 занятие. Работа в UML. построение диаграммы ВИ и диаграммы деятельности.
Домашнее задание: построить диаграммы и подготовить презентацию
Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.
5 занятие. Семинар-презентаци. Выявление ошибок. Домашнее задание: устранение ошибок, доработка ВИ, диаграмм. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.
6-11 занятия. еще не придумал полностью. Модель бизнес-объектов. Переход к системным вариантам использования. Диаграммы последовательности для системных событий (Пользователь - (событие)- Система (По Ларману 2 е издание))
-
Лично я против чтения диаграмм в таком стиле. Во первых нет уверенности, что ты вытащил всю информацию. А во вторых вообще нет понимания, на какие вопросы в принципе может отвечать диаграмма.
Да ради Бога. Баб Яга всегда против:-) 1. в твоем вопросе описать, что ты видишь на диаграмме, я увидел подколку. Потому абстрагировался от "глубоких" познания UML, а использовал только познания скажем те, которые мне объяснил мой консультант, когда показывал енту самую диаграмму.
Что он мне сказал:
Прямоугольник очерчивает границы вашей зао "рога и копыта". Все что внутри - это ваше устройства бизнеса. Вот эти человечки - действующие лица, которые чего-то хотят (чего написано внутри овальчиков).
Вот исходя скажим их таких примитивных постулатов я и начинаю исходить.
Ты же мне не написал - проделай полный анализ диаграммы на предмет того-то. Мы наверное с тобой антагонисты :-) Когда ты задавал мне это вопрос, уже ожидал получить ответ такого вот вида, а я например узрел в этом, что сама по себе диаграмма ВИ неочень информативна, и искренне полагал, что именно это ты мне пытаешся объяснить. Не угадал :-) Опять получил щелбан.
Заметь, за что ты всегда меня стромишь, сам же и делаешь. Все видят банан по своему...
Как бы я предложил читать ту диаграмму: надо понимать, что это вполне конечный и определенный набор фактов.
Кажестя повторяться не имеет смысла, а?
3. Существуют описанные цели и сценарии их реализации
И где ты увидал сценарии реализации? Я пока вижу цели и связи
В частности, непонятно, кто основное действующее лицо - диаграмма не отвечает на этот вопрос, если надо уточнение, придется смотреть текст ВИ.
А с какой позиции смотреть. Кстати про ОДЛ я вообще ничего не говорил явно, однако. Если закрыть листочком все ЗАО мы увидим - а что мы увидим, Клиента - Черный ящик(с целью получить обслуживание)
По-моему не надо быть Коперником, чтобы понять, что клиент тут чего-то хочет. А хочет он явно получить обслуживание. По-моему ничего противоречащего здравому смыслу и здравой логике тут нет.
Давай найдем отличия твоего прочтения от реально имеющегося в диаграмме...
Давай попробуем.
[b]Клиент обращается в ЗАО "Рога и копыта", чтобы Получить обслуживание.[/b] (Где написано слово "обращается", откуда известно, что основное действующее лицо - клиент?)
См выше. Если тебе так написать Клиент хочет получить обслуживание в ЗАО. Модель тем и характерна, что она скрывает или убирает второстепеннные элементы, а выпячивает значимые. Т.е. я полагаю, если ты мне нарисовал RLC- цепь, то вероятно в ней индуктивность означает именно индуктивность.
В ходе обслуживания Продавец с помощью Кассового аппарата Пробивает чек. (Связи между "Получить обслуживание" и "Пробить чек" нет на диаграмме, Продавец - единственный участник, значит основное действующее лицо - засчитано)
В данной ситуации продавец исполнитель процесса обслуживать и ОДЛ процесса Пробить чек. Причем из семантики ясно, что клиент хочет получить чек. Опыт жизни. Сергей!
домыслы не засчитаны, таких фактов нет на диаграмме)
Мои домыслы, как раз и есть те возможные вопросы, которые я бы хотел задать автору диаграммы. Поскольку они мне как раз и неизвестны, потому я и попытался сдлуать некую догадку, чтобы усылшать одобрение или возражение
Теперь смотри сам, чего не хватает на диаграмме для ответа на какие вопросы. И как она должна быть нарисована для того, чтобвы в точности соответствовать твоему тексту.
Это назвается многократный перевод. Такому стилю учать иностранному переводу.
Очевидно можно добавить некие комменты.
Естественно - это все мое частное мнение. Прошу критиковать и обсуждать.
Это не мнение - это декларация своих идей:-))
Мое мнение, думаю, в данной ситуации абсолютно не значимо. Былобы интересно узнать мнения других практикующих людей. Именно практикующих, поскольку мои знания чисто теоретизированы и не подкреплены практикой.
-
Предлагаю не нагнетать эмоции. если задел - приношу извинения.
Сережа, это ты прости меня, если я дал повод, чтобы ты подумал, что задел меня. Вовсе нет.
ОДЛ - это носитель цели и почти всегда инициатор. Если ОДЛ н еинициатор, то это очень четко оговаривается. Так как я не разделял участников на бизнес-актеров и актеров, то они все нарисованы одинаково.
Еще раз повторюсь, я действовал в роли простого обывателя, который видит картинку, особо не зная всех тонкостей, но имеющий все-таки солидный жизненный опыт. Как раз этот опыт мог мне подсказать, что Клиент и есть некое внешнее лицо, желанное для ЗАО "Рога и копыта" и имеющий некий интерес в этом учреждении. Далее я вижу некую роль Продавца. Ассоциация очевидна. Я не знаю что там такое это продавец продает, но судя по названию ЗАО, рога и копыта... Конечно это домыслы, но что еще можно узнать из такой диаграммы?
Ты ответил, что к ней надо было бы подходить с точки зрения семантики UML, т.е. читать схему. Возможно ты и прав...
Конечно, здравый смысл подсказывает правильное прочтение. Но мой здравый смысл подсказывает, что у всех разный здравый смысл, так что лучше переспросить :)
То, что клиент хочет получить чек ясно опять только из здравого смысла (который у всех разный :) ), но не из диаграммы.
Да здравый смысл у всех разный, но нужно все-таки полагать, не намного. Иначе бы люди не могли общаться меж собой...
Выпадом про мнение ты ставишь меня в тупик... Чем принципиально различно мое мнение и мои идеи?
Я имел в виду, что мое мнение в данной ситуации не совсем объективное. Поскольку я сам же задачу придумал. К тому же я скорее неофит, чем серьезный конкурент. Но для того чтобы просто принять например твои доводы, я их должен глубоко осознать, а не просто принять на веру. Частично, я уже проникся твоими идеями. Они помогли мне взглянуть на прочитанное по другому, произошел некий качественный скачек. Но еще не до конца:-)
Твое мнение в данной ситуации очень интересно. Просто, я все пытаюсь донести мысль, что свой здравый смысл следует выносить на бумагу для всеобщего обозрения воизбежание неоднозначного толкования.
Это я уже понял, вернее понимал и раньше и интуитивно использую, просто нет еще навыка делать это скурпулезно.
Я тут обдумывал твой большой и мужественный пост (Кстати еще раз огромное за него спасибо), и знаешь к чему пришел?
Вот ты выдвигаешь скажем некие проблемы и последовательно разворачиваешь анализ, добавляя одну проблему за другой.
Но, если посмотреть на это несколько иначе. Некая выдвинутая проблема вызвана некими причинами, не имеет ли смысл сначала установить а в чем глубинная причина этой проблемы, а может и других проблем. Не окажется ли, что все эти проблемы имеют одни корни, а потому могут быть решены одним решением?
Другая мысль, рожденная в ходе обдумывания. А почему все должно плясать именно от проблемы. Нет то, что анализ и начинается с обнаружения проблемы - это ясно мне теперь (да и раньше было ясно, просто как-то скрывалось за пластом ненужных деталей).
Вся это технология с проблемой важна для определения потребностей в системе и т.п.
Однако, скажем такая ситуация. Молодой бизнесмен, ведя свой бизнес по бумажной технологии, скажем вполне доволен и не видит особых поводов для беспокойства.
Но все его друзья активно используют компьютерные программы для ведения своего бизнеса. На молодец их кажется боится, но ведь все используют, значит это выгодно, или можно, или престижно. И решает он тоже внедрить нечто подобное. Есть у него скажем приятель - компьютерщик. Он обратился к нему за советом, ну а тот не против заработать немного денег. И скажем начинает сбор первичной информации и спрашивает у бизнесмена - а в чем у тебя проблема? Он ему да ни в чем, вернее стыдно перед знакомыми, все имеют компьютеры, а я все по бумажкам расписываю.
Т.е. конечно проблема или побудитель к началу действий есть. Но ведь - все таки это не проблема для начала исследования и построения системы? Или же можно считать и это проблемой? Всегда ли построение чего-либо инициируется проблемой?
-
Насчет схемы, конечно, аналогию я провел неудачно. Все-таки модель вариантов использования - это неформальные требования, это даже еще не эскиз того, что требуется.
Поэтому конечно схема должна читаться однозначно, хотя есть разные схему - монтажная и принципиальная, что конечно не одно и тоже, хотя очень близкое.
ТЗ - это безусловно документ регламентирующий, поскольку за ним стоит финансовая ответственность и, трактовка должна быть сугобо однозначная.
Насчет понятия проблемы, тоже разъянилось. Я тут побеседовал с Юрием Булуем и согласен, что проблема должна исходить от заинтересованной стороны, а не навязываться ей.
Вообщем можно сказать, что конценсус найден :-))
Нужно теперь его закрепить...
-
[Некробурения приступ]
"Ресторан" является популярным тренажёром -- учебной моделью, на которой якобы можно продемонстрировать подход, возможности нотации и т. п.. При этом считается, что [всю всамделишную] работу ресторана можно хорошо себе представить и считать-узнать в учебной модели. Полагаю это очень сильмым допучением и считаю, что "ресторан-тренажёр" моделирует только наши представления, которые могут соотноситься или не соотноситься с реальностью.
"Ресторан" (https://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html) by Kirill Fakhroutdinov.
"Ресторан" (http://files.defcon.no/RUP/process/modguide/md_bucm.htm) как часть руководства по RUPу от IBM и как исходник рисунков Fakhroutdinov-а.
"Ресторан (https://www.uml-diagrams.org/use-case-diagrams/use-case-business-error.png) с красными человечками" by Kirill Fakhroutdinov -- иллюстрация популярных "граблей" при построении BUC-модели.
-
[Некробурения приступ]
"Ресторан" является популярным тренажёром -- учебной моделью, на которой якобы можно продемонстрировать подход, возможности нотации и т. п.. При этом считается, что [всю всамделишную] работу ресторана можно хорошо себе представить и считать-узнать в учебной модели. Полагаю это очень сильмым допучением и считаю, что "ресторан-тренажёр" моделирует только наши представления, которые могут соотноситься или не соотноситься с реальностью.
"Ресторан" (https://www.uml-diagrams.org/restaurant-uml-use-case-diagram-example.html) by Kirill Fakhroutdinov.
"Ресторан" (http://files.defcon.no/RUP/process/modguide/md_bucm.htm) как часть руководства по RUPу от IBM и как исходник рисунков Fakhroutdinov-а.
"Ресторан (https://www.uml-diagrams.org/use-case-diagrams/use-case-business-error.png) с красными человечками" by Kirill Fakhroutdinov -- иллюстрация популярных "граблей" при построении BUC-модели.
Я бы добавил в копилку Джозефа Шмуллера (https://yadi.sk/d/Ktbjp1bYKDTm5g)
-
Долистало до примера с рестораном. По дороге хотело всё свалить на переводчика-ксенолингвиста, но просмотр оригинала на английском показывает, что книга за прошедшее время сильно разошлась со стандартом UML, которому учит. Ну и изначальные дефекты есть.
Я бы не рекомендовало.
-
Что касается диаграммы (https://www.uml2.ru/forum/index.php?action=dlattach;topic=124.0;attach=152), то на ней стоило показать все бизнес-процессы. Полагаю, что те, которые не изображены, связаны с бизнес-актором (бизнес-акторами), которых не выделили. Такими как Время. Мне, кстати, не встречались диаграммы BUC с таким бизнес-актором, хотя многие бизнес-процессы завязаны на время и стартуют по нему.
-
"Приключения в ресторане" продолжаются.
Некто поместил в википедию свою версию диаграммы ВИ (https://en.wikipedia.org/wiki/File:Restaurant_Model.png) ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия (https://www.dragon1.com/help/create-dynamic-use-case-diagram) со сплошными экстендами. Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание (https://babok-school.ru/testy/uml-basics-test/) UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.
-
RUP (по неясно откуда взявшейся традиции, называя его UMLем) не только увязывают бегом на месте, но и заявляют, что он тянет аналитиков в прошлое. Так прямо и заявлено в одном выступлении на аналитич-фесте, а затем понабросано на нескольких площадках -- на хабре и далее везде. То есть технология, придуманная NASA-вскими разрабами надёжных программ для шаттлов (а именно они и создали Rational, а значит и RUP), не пускает аналитика в светлое будущее, где проги, с которыми ты вынужен обращаться в обиходе постоянно сбоят, и вместо этого отправляет в тёплое ламповое прошлое, когда надёжность обеспечивалась и за счёт процесса разработки, а не только лишь за счёт личных качеств исполнителей.