Практика использования RUP. Или бег на месте...(Прочитано 32226 раз)
Сергей, нет ли у тебя полного шаблона описания варианта использования.
У меня есть множество различных вариантов, а на каком остановится не знаю. Хотелось бы иметь самый полный или, например, который ты чаще всего используешь и считаешь оптимальным.



По поводу обучения предполагается примерно такая программа:

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, т.е. читать схему. Возможно ты и прав...

Цитировать
Конечно, здравый смысл подсказывает правильное прочтение. Но мой здравый смысл подсказывает, что у всех разный здравый смысл, так что лучше переспросить :)
То, что клиент хочет получить чек ясно опять только из здравого смысла (который у всех разный :) ), но не из диаграммы.
Да здравый смысл у всех разный, но нужно все-таки полагать, не намного. Иначе бы люди не могли общаться меж собой...

Цитировать
Выпадом про мнение ты ставишь меня в тупик... Чем принципиально различно мое мнение и мои идеи?
Я имел в виду, что мое мнение в данной ситуации не совсем объективное. Поскольку я сам же задачу придумал. К тому же я скорее неофит, чем серьезный конкурент. Но для того чтобы просто принять например твои доводы, я их должен глубоко осознать, а не просто принять на веру. Частично, я уже проникся твоими идеями. Они помогли мне взглянуть на прочитанное по другому, произошел некий качественный скачек. Но еще не до конца:-)

Цитировать
Твое мнение в данной ситуации очень интересно. Просто, я все пытаюсь донести мысль, что свой здравый смысл следует выносить на бумагу для всеобщего обозрения воизбежание неоднозначного толкования.
Это я уже понял, вернее понимал и раньше и интуитивно использую, просто нет еще навыка делать это скурпулезно.


Я тут обдумывал твой большой и мужественный пост (Кстати еще раз огромное за него спасибо), и знаешь к чему пришел?
Вот ты выдвигаешь скажем некие проблемы и последовательно разворачиваешь анализ, добавляя одну проблему за другой.
Но, если посмотреть на это несколько иначе. Некая выдвинутая проблема вызвана некими причинами, не имеет ли смысл сначала установить а в чем глубинная причина этой проблемы, а может и других проблем. Не окажется ли, что все эти проблемы имеют одни корни, а потому могут быть решены одним решением?


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



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

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

Насчет понятия проблемы, тоже разъянилось. Я тут побеседовал с Юрием Булуем и согласен, что проблема должна исходить от заинтересованной стороны, а не навязываться ей.

Вообщем можно сказать, что конценсус найден :-))

Нужно теперь его закрепить...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19