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

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

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

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

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

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

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

Обычный ход разработки системы - независимо от ее природы, основан на принципах системного анализа и предполагает
1. Постановку и определение цели
2. Определение границ моделирования
3. Анализ системы - определение законов ее функционирования и структуры ее предметнойй области
4. Синтез системы - получение алгоритмов законов функционирования для достижения поставленной цели

В разных методологиях это реализовано по разному.

Остановимся на RUP.

RUP предполагает начало работы с построения модели бизнеса. Термин не очень хорошо, но другого нет. Можно назвать это функциональным моделированием - но будет не верно. Я вижу эту модель как сочетание двух видов модели - модель окружения или внешнее представление о системе, и модель объектов - внутреннее представление системы на самом общем уровне понимания

Технология RUP предполагает для бизнес моделирования:
1. построение модели вариантов использования бизнеса (не удачные термины для русского, что можно предложить?)
1а. Определение действующих лиц так или иначе заинтересованных в данной системе (пользователи системы, поставщики системы, кураторы системы, субъекты суперсистемы)
1б. Определение вариантов использования, т.е. потребности или интересы действующих лиц по отношению к системе
Обычно я делаю этот этап следующим образом:
1. Делаю пакет: Внешнее представление
2. В нем делаю два пакета как минимум: Внешние действующие лица и Варианты использования
3. Пакет варианты использования по необходимости сразу разбиваю на подсистемы, если они очевидны, либо пытаюсь это сделать изучая действующих лиц и близость ВИ по смыслу и их владельцам


2. постоение модели бизнес объектов - модели реализации бизнес ВИ.
2а. определение исполнителей
2б. определение сущностей

Следуя за Вендровым, я делаю этот этап следующим образом:
1. делаю пакет Внутренее представление (модель объектов)
2. делаю пакет Исполнители
3. делаю пакет Сущности
4. формирую организационные модули если система сложная
либо создаю кооперации бизнес реализации ВИ
Для каждой такой реализации делаю VOPC
Правильно я делаю или нет, не знаю. Логично - кажется да, но так ли это?

Потому хотелось бы получить ответы на ряд вопросов
1. Когда требуется проводить бизнес моделирование? Хотелось бы услышать рекомендации, чтобы понять необходимсоть этого этапа.

2. Каков типичный сценарий реализации процесса бизнес моделирования? Т.е. какие шаги нужно предпринимать и какие артефакты получать. (читал я rup розовский, там столько всего наворочено, что голова начинает болеть уже через 5 минут)

3. Столкнулся с такой трудностью:
Предположим есть
ВИ: зарегистрироваться на курс
участники: Студент и Регистратор(исполнитель)
Описание:
Студент выбирает из каталога курсы (4 основных и 2 альтернативных)
Регистратор проверяет соблюдение всех условий (студент оплатил обучение, курс не закрыт и прочее)
Регистратор вносит курсы в программу обучения студента

тут можно конечно все расширить...

Все в общем понятно, строим ДК типа VOPC для данного ВИ
Очевидно
исполнитель Регистратор
сущности: График прохождения, Курсы, Студент (его запись в системе)
заинтересованное лицо: бизнес эктор - Студент

Сразу возникает проблема. Создаю сущностный класс с названием Студент, но он уже есть! Использовать для него название типа Профиль студента, не очень красиво. Не так видна семантика.
Не делаю сущность студент - а использую самого Эктора Студент чтобы показать связи.
Для наглядности все окей, но не в наглядности только дело.
Я потратил много времени на создание БМВИ и естественно все что натворил, хочу использовать дальше. Добавлять операции, артибуты и т.п.

Как быть? Я для себя делаю такой ход - сохраняю БМВИ отдельно. копирую ее и дальше уже с некоторыми изменениями использую в дальнейших этапах, т.е. пытаюсь добиться автоматизма при переходе от этапа к этапу..

Но все это мои придумки, а как на самом деле следует поступать???

Технология RUP предполагает для бизнес моделирования:
1. построение модели вариантов использования бизнеса (не удачные термины для русского, что можно предложить?)

Ну почему же не удачный? Слово Бизнес клубоко вошло в нашу жизнь: бизнес процессы, бизнес подразделение и т.д. Я бы назвал это как Бизнес Модель ВИ

1а. Определение действующих лиц так или иначе заинтересованных в данной системе (пользователи системы, поставщики системы, кураторы системы, субъекты суперсистемы)

Я бы еще добавил, что это внешние по отношению к нам участники. Т.е. опираясь на пример, на данной ДВИ должен быть актер Студент, а Регистратора быть не должно быть на данной ДВИ.
И еще все же наверное не к Системе а к нашему бизнесу. Потому что Систему мы определяем позже.

1б. Определение вариантов использования, т.е. потребности или интересы действующих лиц по отношению к системе
Обычно я делаю этот этап следующим образом:
1. Делаю пакет: Внешнее представление
2. В нем делаю два пакета как минимум: Внешние действующие лица и Варианты использования
3. Пакет варианты использования по необходимости сразу разбиваю на подсистемы, если они очевидны, либо пытаюсь это сделать изучая действующих лиц и близость ВИ по смыслу и их владельцам

Можно еще делать один пакет для Актеров и другие пакеты разбивать по функциональным блокам, если ситема большая.

2. постоение модели бизнес объектов - модели реализации бизнес ВИ.
2а. определение исполнителей
2б. определение сущностей

Следуя за Вендровым, я делаю этот этап следующим образом:
1. делаю пакет Внутренее представление (модель объектов)
2. делаю пакет Исполнители
3. делаю пакет Сущности
4. формирую организационные модули если система сложная
либо создаю кооперации бизнес реализации ВИ
Для каждой такой реализации делаю VOPC
Правильно я делаю или нет, не знаю. Логично - кажется да, но так ли это?

Хотелось немного добавить. VOPC - это 'View Of Participating Classes' - "Представление Классов Участников", т.е. тех Классов, которые учавствуют в ДП, ДС, ДА. Т.о. VOPC - это реализация ВИ, которая включает ДК и ДП, ДС, ДА.

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

Ну вот что приходит на ум, когда не надо:
1. Когда Система не сложная
2. Когда бизнеса как такого нет, т.е. нет или мало внешних участников
3. Когда Система уже построена и надо ее задокументировать, т.о. лучше идти от СМ

2. Каков типичный сценарий реализации процесса бизнес моделирования? Т.е. какие шаги нужно предпринимать и какие артефакты получать. (читал я rup розовский, там столько всего наворочено, что голова начинает болеть уже через 5 минут)

Ну дык, ты же описал, вроде так и должно быть. Можно реализацию БВИ представлять не ввиде ДА, ДС и т.д., а ввиде текста, т.е. в виде Сценария БВИ

Сразу возникает проблема. Создаю сущностный класс с названием Студент, но он уже есть! Использовать для него название типа Профиль студента, не очень красиво. Не так видна семантика.
Не делаю сущность студент - а использую самого Эктора Студент чтобы показать связи.
Для наглядности все окей, но не в наглядности только дело.
Я потратил много времени на создание БМВИ и естественно все что натворил, хочу использовать дальше. Добавлять операции, артибуты и т.п.

Ну используй кто не велит? И это будет правильно

Как быть? Я для себя делаю такой ход - сохраняю БМВИ отдельно. копирую ее и дальше уже с некоторыми изменениями использую в дальнейших этапах, т.е. пытаюсь добиться автоматизма при переходе от этапа к этапу..

Проблемма трассировки есть, по крайне мере в Розе. Но не надо подходить так координально.
Мне кажется, что вся модель Система должна быть в одном проекте.

Но все это мои придумки, а как на самом деле следует поступать???

Придумки хорошие. Теперь надо расписать Системную Модель и т.д., а потом вернуться к Vision.

Ну почему же не удачный? Слово Бизнес клубоко вошло в нашу жизнь: бизнес процессы, бизнес подразделение и т.д. Я бы назвал это как Бизнес Модель ВИ

А потому. Вот я сейчас моделирую работу деканата. Это что бизнес? Есть ассоциация, что бизнес - это дело с помощью, которого зарабатывают деньги свободным путем. Это мой бизнес, бизнесмен - читай предприниматель
А деканатом как? какой бизнес ведет декан? декан это - бизнесмен? Ниже ты утвержаешь - нет бизнеса ненадо бизнес-модель. Очень оригинально. Получается для деканата не нужна бизнес-модель, потому как нет бизнеса. Но общее количество внешних актеров довольно велико(студент, кафедра, преподаватель, учебный отдел, НИЧ, ректорат, отдел кадров, зав кафедрой, бухгалтерия и т.п.) Т.е. когда считать, что БВИ не нужна?
Напомню цель БВИ - гарантировать, что система решает потребности актеров в ней...

Можно еще делать один пакет для Актеров и другие пакеты разбивать по функциональным блокам, если ситема большая.

А что внешние действующие лица - это не актеры:-)

Ну вот что приходит на ум, когда не надо:
1. Когда Система не сложная
2. Когда бизнеса как такого нет, т.е. нет или мало внешних участников
3. Когда Система уже построена и надо ее задокументировать, т.о. лучше идти от СМ

Критерии плиз, четкие неоднозначно понимаемые критерии, + см. выше
Проблема системного анализа по ИС - нет четкий критериев, а критерии должны быть четкими и не двусмысленными, как в математике и никак иначе.

Ну используй кто не велит? И это будет правильно
/quote]
Попробуй, а я посмотрю:-))

Что-то ты зациклился, на слове "БИЗНЕС". Бизнес переводится как Дело, а не только как коммерческое дело.
Ну Декан - это работник деканата, А что в ком. структуре бухгалтер или директор (не владелец) - это бизнесмены?
В твоем случае читать так: институт - организация, деканат - отдел/подразделение организации.
Вот как к организации (коммерческой или не ком. - разницы нет) и подходи к Инсту.

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

Возникает противоречие в плане использования UML.
Например ВИ - контролировать успевамость:
работник деканата печатет ведомости и три раза за семестр в установленные контрольные точки передает их на кафедры
преподаватели кафедр заполняют ведомости успеваемости и передают их в деканат
работник деканата заполняет сводную ведомость
работник деканата в конце семестра подводит итоги

Т.е. возможно ли на фактически системном уровне показать ВИ - где с одной стороны ИСПОЛНИТЕЛЬ, а с другой вроде как внешняя сущность, или их всех воспринимать как исполнителей, а что есть система?

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

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

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

Ну если те нужно построить модель ф-ия, то зачем те СМ? Если нужна модель ф-я, то строй БМ. Кстати, сделав множество БМ можно организовать раздел патернов.

Т.е. возможно ли на фактически системном уровне показать ВИ - где с одной стороны ИСПОЛНИТЕЛЬ, а с другой вроде как внешняя сущность, или их всех воспринимать как исполнителей, а что есть система?

На эту тепу достаточно четко высказался  byur:
http://www.sql.ru/forum/actualthread.aspx?tid=363947#3432641