Здрасте всем!
Уже пол-года пытаемся перейти на "правильное" проектирование с помощью RR 2003. И все возникают вопросы и непонятки в основном по первым процессам: анализ БП и выявление требований, функционала системы.

Вроде бы БП удобнее проанализировать в BPWin. Но хочется все-в-одном, чтобы сгенерить потом документацию из одного места. Остается RR.
А в RR начинаешь рисовать use-cases и понимаешь, что что-то ты не так делаешь... Вроде бы рисуешь вариант использования (ВИ), но так и тянет нарисовать последовательность вариантов по горизонтали (типа по-времени). Но я вроде понял что это неправильно. А как правильно? Рисовать актеров а вокруг них основные ВИ? А потом расширять их черерз extend, include на более подробные? А до какой степени подробности??? Или просто брать основной ВИ и рисовать ему блок-схему (Activity)?
А еще эти диаграммы последовательности (ДП)... Они вроде удобны, но они для работы с объектами. А что брать как объекты, когда надо описать алгоритм действий оператора+системы для реализации какого-либо ВИ??? Сущности, визуалку - ведь можно и так и так.

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

А БД вообще удобнее сделать в ERWin. - И опять 25 - Сущности в ERWin, сущности в RR, а как синхронизировать, да потом чтобы сгенерить на Оракл???

А программисты все-равно до конца все по этим картинкам с описаниями не понимают - все равно приходиться объяснять. А потом не будешь же все до мелочей делать - кажды алгоритм расписывать - только сложные? А то будешь проектировать пол-года и программировать пол-года. А когда до этого делали "на коленке" (бумажке, абы как - все алгоритмы смотри в коде... и т.п.) все быстрее получалось. Правда ошибок было много и пототм не разберешь, кто как что сделал. Но сказать что сейчас у нас прям резко все улучшилось по срокам и по ошибкам нельзя.

Потом вроде взяли сделали табличку в Excel "функции-роли" - тоже вроде не удобно - не охватываешь взглядом.

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

Так что оказался я в творческом ступоре... Короче нужен мне курс обучения :)

Собственно сам вопрос вот в чем: Как другие разработчики выполняют эти первые этапы проектирования (Анализ БП, выявление треб и функционала с правами на него, описание алгоритмов, разработка классов и БД)??? Поделитесь пожлст опытом с "зелеными"...

Мы пытаемся использовать RUP. А про ДВИ - я и спрашиваю - КАК?

Классы мы не генерим, потому что у нас используется Delphi и своя структура приложения. У нас нет общеприянитых классов. У нас есть один универсальный класс, в который можно на ходу добавлять какие угодно поля. Но эти поля мы и описываем в олбщих инклюдах - они и есть наш "класс". Таким образом мы уходим от проблем некорректной сборки версий - хотя может это и неправильно. Поэтому генерить стандартный класс нам никчему.

С БД в ERWinе все прозрачно, а в RR все непонятно - как делать эту БД???

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

Подскажите!!!

Может подскажите хорошую книгу по методике проектирования? А еще бы увидеть хоть бы одну полноценную модель в RR...

Вот этот пример - это правильно?
Если да, то до какой степени его прорабатывать? Ведь "Ввод заказа" можно довести до очень маленьких квантов типа "Выбор клиента".

А смысл БП таков:
Есть прием заказов. При принятии заказов мы должны сразу обязательно создать счет на оплату введенных заказов.

Если клиент новый, то надо его сначала добавить в БД.

При выдаче заказов обязательно формируется счет-фактура и иногда акт выдачи.

Ну и т.п.

А вот это правильно???

В чем разница между include и extend?
Как я понял связь Include - это обязательный ВИ, без которого тот ВИ кто на него указывает, не может состояться.

Как я понял связь Extend - это необязательный ВИ, который может случиться а может и нет. Основной ВИ указывает на дополнительный.

Или ВИ "Редактирование клиента" надо описать диаграммой псоледовательности или диаграммой действий?

byurP.S. представленная модель юзкейсов не корректна. Юзкейсы выделены неверно, и проименованы неверно.

А как правильно то???? И как их именовать???

Научите!!!! Пожалуйста!!!!

Вот например взять кусок:
Организация принимает заказы. Приходит клиент заполняет бланк заказа или присылает бланк по мылу. Заказ оператором вводиться в БД. Клиенту на группу одновременно принятых заказов оператор создает счет. Менеджер выставляет счет клиенту.

Как это правильно описать в Use-casах???

И как от use-cases перейти к функциональным требованиям и в каком виде???

А так правильно?

Хорошо. А как далее расписываются use-cases? С помощью диаграмм деятельности? я имею ввиду сценарии use-casе-а.

Всем большое спасибо.
Буду читать ссылки. :)