136

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 06 Февраля 2007, 18:54:44 »

Дома хорошенько подумаю. А пока ремарка, чистое IMHO.
1) Важно понимать, что бизнес-процессы связаны между собой.
Например, прямая связь закупка продуктов - обслуживание посетителя: предоставляет продукты, обратная связь - предоставляет материалы для корректировки и планирования.
Обслуживание потребителя и закупка продуктов предоставляют материалы для расчёта налоговых выплат и средства для их произведения.
2) Владельцы процессов всегда пересекаются, иначе нет основания объединять варианты использования в одни рамки системы (в данном случае - не IT-системы, а системы гораздо важнее - производственной!). Посетителя обслуживает столовая. У оптовой базы материалы также обслуживает столовая. Столовая платит налоги, администрация ВУЗа выступает гарантом. (Кстати, что раньше по логике вещей? Порядок важен.)
3) Отчёты и выплаты по налоговому учёту и закупка продуктов - обеспечивающие БП.

Не думай сразу про автоматизацию: вся IT является мелочью по сравнению с получением прибавочной стоимости, её получали до IT и будут производить после .

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

137

Теория моделирования и нотации / Re: Задача на n-арные связи

« : 01 Февраля 2007, 20:03:28 »

Углубляемся в детали реализации .

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

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

То что договор включает некоторые предметы соглашения понятны, однаок если эти предметы соглашения могут перепродаваться?

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

Кроме того как учитывается тот факт, что один и тот же предмет договра может продаваться по разным ценам в будущем?

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

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

138

Теория моделирования и нотации / Re: Задача на n-арные связи

« : 01 Февраля 2007, 19:28:31 »

Но ведь ты меня понял и нарисовал - значит, цель достигнута . Не обижайся. Я сегодня целый день с диаграммами вожусь, они мне вот уже вот где <показываю поперёк горла>.

Хочешь более простой модели - отсеки лишнее, получишь более частный случай и вероятность потерять лес за деревьями .

Зачем я выделил более общий случай: я уже 2 раза участвовал в таких системках, и в течении года после внедрения приходили именно к такой модели. Причина в том, что компания пытается использовать систему в более широких рамках, чем начальные. Выясняется, что:
- компания начинает работать и с физиками, и с юриками, и со своими собственными филиалами, и с ПБОЮЛами;
- договоры бывают трёхсторонними, многосторонними и внутренними, а лица могут выступать в роли гарантов, управляющих предприятий и т.д.;
- предметом договора становится пёс знает что.
Теперь я предпочитаю несколько усложнить модель, но выйти на более высокий уровень абстракции.

Причём эта модель подходит для очень многих документов-соглашений (договоры, счета, счета-фактуры, товарные накладные), всё зависит только от стиля визуализации. А если допустить связь с документом одной роль - то схема подойдёт и для документов-решений.

Насчёт абстрактного класса: ассоциация абстрактного класса означает ассоциации всех его подклассов, которые являются конкретными классами.

Или... это была теоретическая задача, отвязанная от конкретной системы?

139

Теория моделирования и нотации / Re: Задача на n-арные связи

« : 01 Февраля 2007, 18:42:32 »

Как бы я сделал.
Есть класс "лицо". У него подклассы - "юр. лицо" и "физ. лицо".
Есть класс "договор".
Есть класс "роль лица в договоре". У него - ассоциации с "лицом" и "договором", и подклассы "продавец" и "покупатель".
Есть класс "предмет договора". У него - ассоциация с "договором" и подкласс "ценная бумага".

140

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 31 Января 2007, 11:43:49 »

Не брешешь? Тогда стукнись в аську, я сменю тебе права на сайте - будешь статейки тискать и кое что в этом направлении публиковать. Предлагай как раздел назовем? Теория и практика бизнес-анализа? Или Бизнес для IT-специалистов? Ну что тебе на ум прийдет. Я создам раздел и вперед:-))

Я думал, что "возмись"="пеши исчо" . На самом деле - наверное, брешу. Опыт бизнес-анализа у меня есть, но он стремительно устаревает. Я сейчас скорее ситемный аналитик, а бизнес-аналитик и архитектор - не от хорошей жизни, а от остутствия результатов от "выделеннных" бизнес-аналитиков и архитекторов. Лучше бы этим разделом "выделенному" бизнес-аналитику заниматься. Тем более что со временим у меня - то достаточно густо (вот сейчас, например, понапридумывал и согласовал, и пока прототип не сделают, полегче), то совсем пусто (когда надо тестировать на достижение цели (!=тестировать на качество), придумывать и особенно согласовывать).

141

Бизнес-анализ и Целеполагание / Re: Что такое бизнес-процесс?

« : 29 Января 2007, 16:15:28 »

2bas
IMHO да, процесс бух. учёта является служебным БП, направленным на:
1) выявление отклонений от штатного хода БП (усушек, утрясок, утрат, недостач и прочего разгильдяйства и воровства)
2) сбор информации об эффективности (прибыльности) основных БП и общем состоянии организации
3) прогнозирование (износ, устаревание, вложения)
4) достижение соответствия деятельности закону.
(1)-(3) для России неприменимо: бух. учёт и фактический учёт у нас по известным причинам расходятся.

142

Бизнес-анализ и Целеполагание / Re: Что такое бизнес-процесс?

« : 29 Января 2007, 14:24:20 »

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

143

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 29 Января 2007, 14:01:50 »

Я бы сказал, что декомпозиция есть как раз усложнение, а не упрощение.

То, что у банка что есть функция "выдать кредит" - это просто.

То, что "выдать кредит" - это:
1) Идентифицировать заёмщика
2) Проверить платёжеспособность и кредитную историю
3) Желания заёмщика
4) Принять решение о возможности выдачи кредита и условиях кредитования
5.а) Оформить и зверить кредит, выдать деньги
5.б) Запросить дополнительные подтверждения платёжеспособности
5.в) Отказать в кредите
- уже сложнее.

То, что "проверить платёжеспособность и кредитную историю" - это:
4.1) Запросить бюро кредитных историй
4.2) Рассмотреть динамику возвращния кредитов и составить прогноз
4.3) Запросить МВД, проверить признаки схемы "отмывания" денег
4.4) Учитывая желаемые условия кредитования, расчитать риск
4.5) Расчитать взвешенную прибыльность кредита для банка, принять решение
- довольно сложно.

А конкретные вычислительные модели и технологиии прогнозирования в "составить прогноз" - это совсем сложно .

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

144

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 29 Января 2007, 11:47:02 »

ОК, возьмусь . А суждения приходят в голову любому после прочтения Максовского "Капитала". Маркс IMHO был гений: он сделал бизнес-модель для общего случая, так сказать, class diagram, а не object diagram .
Ну и ещё Макконнелл-Брю с Фишером есть.

145

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 26 Января 2007, 15:31:14 »

<...>Что такое ускорение информационных потоков. А главное зачем их ускорять?<...>

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

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

Увеличивать "амплитуду" могут системы анализа бизнес-процессов и САПР.

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

IMHO всевозможный учёт и анализ - не главные функции АСУ. Они нужны, чтобы выявить сбои в ходе бизнес-процесса и оценить его эффективность.

146

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 25 Января 2007, 19:20:25 »

Какова цель бизнес-моделирования, в частности в примере? Реинжениринг и оптимизация процессов, тем более без создания ПО? Эту задачу успешно решают именно инженеты от ИТ или все-таки это не совсем их домен?

Цель бизнес-моделирования в примере - выявление предметной области АСУ склада и написание корректных ВИ для этой АСУ. Эту задачу решают инженеры ИТ. В результате происходит оптимизация бизнес-процесса благодаря ускорению информационных потоков посредством АСУ.
IMHO реинжиниринг бизнес-процесса - это один частный случай оптимизации, а построение АСУ - другой частный случай (оптимизируется использование временнОго ресурса).

А вот насчет отсутствия событийности ... так есть же понятие Business Event, которое есть в RUP, если мне не изменяет склероз. Да, стереотип, и что это плохо?

Такое понятие действительно есть. В UML 1.0-1.1 (RR 2003), в Activity нельзя передавать (неизвестно что) объектам. В UML 2.0 (EA 6.5) действительно можно, причём определять, что передаёшь - контроль или информационный поток. Activity в UML 2.0 действительно можно превратить в ARIS eEPC. Жаль только, что это автоматически не даёт тулзе поддерживающей UML 2.0, возможностей модулей ARIS ABC, BSC и Simulation .

147

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 24 Января 2007, 19:09:51 »

Вообще почему у оператоов в данном контексте цель - спланировать доставку или отгрузку. Может уж тогда инициировать доставку/отгрузку.

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

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

А не важны ещё на этом уровне ни компьютерные системы и подсистемы. Построение АСУ - всего лишь один из способов оптимизации бизнес-процесса. Зачастую - далеко не самый эффективный.
Если в реальном бизнес-процессе есть ветвление, а показать его в ВИ нельзя, то нужно использовать что-то отличное от ВИ. Хотя, кстати, ветвление ВИ реализуется альтернативными последовательностями. 3-4 сложных ветвления (связанных не с обработкой ошибок, а с вариантами логики обработки) превращают ВИ в нечитаемого монстра.

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

В Activity нет важнейших понятий - владелец функции, исполнитель функции, ресурс. Нет разделения перехода на переход
-- контроля
-- физического объекта
-- информации.
Действительно, можно "расширить" Activity посредством введения новых стереотипов. Но не проще ли использовать готовый eEPC?
В Sequence нет ничего, кроме исполнителей функции и переходов непонятно чего.
Ни там, ни здесь нет событийной основы.

Согласен, что гораздо проще показать процесс словами или нотациями типа SADT, ARIS, но ведь и диаграмма деятельности - практический аналог IDEF3

А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?

148

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 22 Января 2007, 18:49:32 »

Очень грубый пример БП:
1) Событие: пришёл заказ от клиента
2) Оператор бэк-офиса: проверить платёжеспособность и отправляет заказ поставщику; вход - невалидированный заказ, выход - валидированный заказ
3) Поставщик: выполнить заказ и доставить на склад; вход - валидированный заказ, выход - заказанный продукт, ресурс - склад
4) Оператор склада: учесть доставку заказанного продукта, передать складскую накладную оператору бэк-офиса; вход - заказанный продкут, выход - складская накладная
5) Оператор бэк-офиса: выписать счёт и счёт-фактуру, заказать доставку доставщику; вход - складская накладная, выход - счёт, счёт-фактура, заказ доставки
6) Доставщик доставляет заказ, клиент подтверждает доставку. Вход - заказанный продукт, заказ доставки, счёт, счёт-фактура. Выход - подписанный счёт-фактура. Ресурс - склад.
7) Клиент оплачивает счёт. Вход - счёт, выход - оплаченный счёт, платёж.

ERP-систему не внедряем, делаем АСУ склада. К большей части шагов бизнес-процесса наша система не будет иметь никакого отношения, что-то неявное и не слишком важное с точки зрения бизнес-процессов - уточним. И вообще, "контроль" нам неважен, а важен "информационный поток".
Поэтому из соответствующих шагов произойдут следующие варианты использования:
(2)=> Оператор бэк-офиса планирует доставку на склад
(3)=> Оператор склада учитывает доставку заказанного продукта; Оператор склада создаёт складскую накладную
(5)=> Оператор бэк-офиса планирует вывоз заказанного продукта со склада
(6)=> Оператор склада учитывает вывоз заказанного продукта со склада

149

Теория моделирования и нотации / Re: А чем моделировение отличается от програмирования

« : 19 Января 2007, 17:12:20 »

<...>А чем моделировение отличается от програмирования<...>

IMHO отличаются уровнями абстракции от двух вещей:
--предметной области
--маш. кода и аппаратной архитектуры

Модель предметной области - ближе к предметной области. Аналитическая модель - ровно посередине. Модель архитектуры - ближе к маш.коду. Код - ещё ближе к маш. коду.

Крамольная мысль:
"Только тем, что модель компиллирует человек, а не компиллятор, причём не всегда есть формальные правила преобразования модели в код.
Хотя, учитывая
--синхронизацию моделей с кодом в современных CASE-средствах
--концепции Domain-Driven Design и Model-Driven Design
--абстракции и поддержку паттернов современными языками программирования
различия между графической моделью (например, UML-диаграммой) и "текстовой" моделью (? кодом) становятся всё более размытыми."

150

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 19 Января 2007, 15:07:23 »

Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?

IMHO для описания бизнес-процессов лучше не использовать никаких UML-диаграмм. Если всё же очень хочется - activity и sequence/collaboration. Любимой class diagram там делать нечего: сложна не столько структура, сколько процесс. Диаграмма вариантов использования не показывает условий ветвления, синхронизаций, передаваемых объектов, используемых ресурсов, временных факторов, событийной основы...

Есть ARIS вообще и eEPC в частности. IMHO лучше применять его (можно применять методологию и нотацию, а в качестве инструмента - хоть Visio).

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