Здравствуйте, byur, Вы писали:
G>>Я, во-первых, совершенно не озабочен таким отождествлением, в силу практической бесполезности оного. Пусть этим теоретики занимаются. Мне достаточно заметить сходство, и все. Во-вторых, формально говоря у видеоконтроллера "actor" один (ЦП), это не бизнес-система, где надо явно выделять роли, так что расписывать в нашем случае это просто "штоб было" и для соблюдения ритуала смысла я не вижу — пользы не много. Хотя, если уж вдуматься как следует, то экторов на более высоком уровне будет ажно три штуки.
B>Вобщем не столько интересна озабоченность (i.e. отождествлением) и прочия рефлексия на тему ритуалов, сколько а) используемая методология б)ее адаптация.
"Адаптация методологии" предполагает, что вы выбрали методологию, и начинаете ее адаптировать. Мы не занимаемся адаптацией методологий, так что ни чем не могу помочь — подход другой, мы решаем свои проблемы по ситуациям, и выбранные методы случайно или намеренно совпадают или похожи на методы из известных "Методологий". Меня это сходства и различия совершенно не заботят — главное это эффективность для моих задач.
В наших процессах разработки есть много общего с практиками RUP и PSP/TSP. Вообще — в любой методологии есть что-то рациональное и хорошее, что можно использовать в работе (обычно если это оставить, то от толстого описания Методологии останется тоненькая брошурка). Однако — сами "методологии" не стоят того, чтобы их "внедрять". Я считаю так, кто-то может считать иначе, я не против, и никого не собираюсь переубеждать. Своим подходом готов поделиться, если кому интересно, и с удовольствием ознакомлюсь с чужим опытом. ОПЫТОМ, а не цитатами из методологий.
G>>Мне кажется, я вообще всегда говорю только очевидные и простые вещи B>Хорошо, что допускаете что это может казаться .
Зачем вы это написали? "Мне кажется" — это просто фигура речи, для вежливости, ничего больше. Если вы настаиваете, в беседе с вами могу обойтись и без них.
G>>Вполне вероятно, хотя мне кажется, что несложно сделать из этого system-level use cases, которые удовлетворят формальный RUP. А по вашему — как еще должны выглядеть use-cases с точки зрения формального RUP для видеоконтроллера?
B>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
Это так же, как в боевых исскуствах. Удар ногой кикбоксера — это совсем не то же самое, что "маваши гири" каратиста — это же совсем не одно и тоже. Однако в реальной жизни применяется в тех же обстоятельствах и приводит к тому же результату . Вы спрашиваете меня — какую Методологию (школу) я применяю, однако я просто бью ногой, дружище, когда это нужно, мне думать над этим некогда . Не по высокой науке, да, но в реальном бою это мало кого интересует .
Почему так? Потому, что я не консультант-одиночка, а руководитель толпы человек в 20, которые еще и меняются переодически в зависимости от проекта. Учить их абстрактному светлому и высокому ДАО у меня нет времени, возможности, и желания. Поэтому, нужны простые и эффективные техники, свободные от зауми, а не Методологии.
G>>Я вижу прямую выгоду от присутствия сценариев в ТЗ, и не вижу ровным счетом ничего существенного, что мне мешает их в ТЗ включить. Раз уж на то пошло, то я могу кому угодно доказать, что юзкейс является требованием к функциям, если это потребуется для того, чтобы включить их в ТЗ . Вопрос в любом случае мутный и казуистический, так что мне все равно, что на него отвечать, лишь бы было как мне удобно. Зачем мне в ТЗ нужны сценарии — я объяснил.
B>В вопросе все достаточно ясно ... и в ответе тоже. У вас не юзкейсы, а сценарии.
Как вам будет угодно, сэр .
Я предпочитаю находить сходство в подходах, и извлекать из него пользу, кто-то может концентрироваться на находении различий. С моей точки зрения, сценарии несущественно отличаются от use-cases, те же, так сказать, яйца, только вид сбоку, просто менее формализовано, а процесс ГОСТ В 29110-91 до чрезвычайнсти похож на RUP-овский controlled iteration. И эти сходства я использую практически, себе на пользу.
Здравствуйте, newbie_analyst, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
_>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
1. Основания для выполнения НИР
2. Цели и задачи НИР.
3. Требования к выполнению НИР
Краткая характеристика проблемы, обоснование необходимости работ.
Краткое содержание проводимых работ/исследований.
Внимание, цитирую, должны быть указаны основные технические требования к НИР, обеспечивающие выполнение поставленных задач. А именно — сюда мы пишем "должна быть обеспечена поддержка следующих сценариев использования...".
Указывается, чем должна заканчиваться работа.
4. Технические требования
А вот тут указываются
а) требования к интерфейсам
б) функуиональные требования
в) прочие требования
и так далее. Далее там про условия сохранения гостайны и прочее. ТЗ давно утверждено и подписано, так что все в порядке.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, newbie_analyst, Вы писали:
_>>Здравствуйте, Gaperton, Вы писали:
_>>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
G>Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, newbie_analyst, Вы писали:
_>>>Здравствуйте, Gaperton, Вы писали:
_>>>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
G>>Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
К>Это по какому-то ГОСТу или ваш формат ТЗ?
Руководитель проекта пишет, что использованы справочные материалы по оформлению НИР в соответствии с последней версией ГОСТ "Система разработки и постановки продукции на производство. Порядок выполнения научно-исследовательских работ". ГОСТ не 34-й, а 15-й, сам понимаешь. Уверен, что это не принципиально, можно и в 34-м найти ходы чтобы сделать как хочется.
Здравствуйте, Gaperton, Вы писали:
B>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ... Да и я не понимаю, что вам объяснять -- Коберна чтоли? Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
2. То как лично вы интерпретируете UC -- это ваша поблема/удача ... я свою т.з. высказал -- юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
G>Как вам будет угодно, сэр .
Вы сама любезность, мсье.
Re[9]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
B>>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
B>1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ... Да и я не понимаю, что вам объяснять -- Коберна чтоли? Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
B>>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
B>1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ...
Я нигде не говорил, что юзкейсы это только RUP. Да и какая разница?
B> Да и я не понимаю, что вам объяснять -- Коберна чтоли?
Я не просил вас ничего мне объяснять. Однако если хотити что-то объяснить — вперед, никто не держит. Знанием имен тока на понт брать не надо — это для пионеров оставьте.
B> Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
Неудивительно, ведь каждый слышит только то, что хочет слышать.
B>2. То как лично вы интерпретируете UC -- это ваша поблема/удача ...
Зачем вы это написали? Если для вас иметь свой собственный взгляд на вещи обязательно является либо проблемой либо редкостной удачей, Юрий, то это ваша проблема, не моя . Я к этому отношусь проще.
B>я свою т.з. высказал -- юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
Нивабиду, но ваша "точка зрения" не обладает для окружающих никакой ценностью, если вы не гуру вроде якобсона. мне интересны ваши рассуждения, а не точки зрения. Рассуждений у вас пока нет.
Re[10]: Бизнес-требования, use cases, фун. требования и ТЗ Г
B>> Да и я не понимаю, что вам объяснять -- Коберна чтоли?
G>Я не просил вас ничего мне объяснять. Однако если хотити что-то объяснить — вперед, никто не держит. Знанием имен тока на понт брать не надо — это для пионеров оставьте.
Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
Вы консультант, и претендуете на особое знание? Самое время его наглядно продемонстрировать. Вы же относитесь к форумам как к площадкам для рекламы, тусовкам, в которых надо участвовать? Пожалуйста — объясните мне
1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете.
Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит.
Re[11]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Gaperton, Вы писали:
G>Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
Мсье, ваш тон не располагает к дискуссии. Оставьте ваше "плавали-знаем" вашим проектам и "каким-то там пионэрам".
G>Вы консультант, и претендуете на особое знание? Самое время его наглядно продемонстрировать. Вы же относитесь к форумам как к площадкам для рекламы, тусовкам, в которых надо участвовать? Пожалуйста — объясните мне
Елене привет от меня!!!
G>1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
Хто вам сказал что хуже? Это ваш домысел ...
G>2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
Отличие в определении. И бардаке, который возникает если вещи не называть своими именами. Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс. У юзкейса обязательно есть эктор, в отличие от сценария. В моей практике я это разделяю и называю своими именами и призываю это делать других. Не нужно иметь суперинтеллект, чтобы придумать как это использовать на практике. Если вы между собой и заказчиком договоритесь называть "горшок" "креслом", и будете понимать друг друга -- значит все ОК. Я как консультант просто перейду на ваш птичий язык и буду оперировать им .
G>Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете.
Благодарю вас мсье, но боюсь в ближайшее время я не смогу принять ваше приглашение как "консультант-одиночка" .
G>Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит.
"Не нукай, не запряг" (с) русская поговорка. А на вопрос я ответил выше.
P.S. "А ты азартен, Парамоша" (с) ... момент истины, понимаешь ... Я плакалъ.
Re[9]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
B> юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
Почему? Какая разница, в кнечном итоге, что проектируется — софт или "железо"? Механизм использования этого (того, что проектируется) всё равно можно описывать посредством юзкейсов.
Здравствуйте, byur, Вы писали:
B>Отличие в определении. И бардаке, который возникает если вещи не называть своими именами.
Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
B>Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс.
Коберн в своей книге написал именно так. Но, полагаю, сторонникам точки зрения Коберна будет любопытно узнать определение сценария в прогнозировании:
"СЦЕНАРИЙ [scenario] в прогнозировании — преимущественно качественное описание возможных вариантов развития исследуемого объекта при различных сочетаниях определенных (заранее выделенных) условий. Метод С. не предназначен для “предсказания” будущего, он должен в развернутой форме лишь показать возможные варианты развития событий (для их дальнейшего анализа) и выбора наиболее реальных, благоприятных и т. п."
Если опираться на это устоявшееся определение сценария, то юзкейс корректнее переводить, как сценарий использования, потому что именно сценарий, согласно определению, содержит варианты, но не наоборот.
КЛ>Если опираться на это устоявшееся определение сценария, то юзкейс корректнее переводить, как сценарий использования, потому что именно сценарий, согласно определению, содержит варианты, но не наоборот.
Странно. Сценарий Вы определили практически буквально как в RUP, а вывод сделали противоположный. При том что "сase" зря переводят как "вариант". Имхо скорее "прецедент".
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[13]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
80% споров из-за разницы в терминологии. Меня еще в аспирантуре научили бережно относится к терминам.
КЛ>Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
О какой науке вы говорите ... программная инженерия -- это инженерная дисциплина.
Re[14]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
B>80% споров из-за разницы в терминологии. Меня еще в аспирантуре научили бережно относится к терминам.
КЛ>>Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
B>О какой науке вы говорите ... программная инженерия -- это инженерная дисциплина.
Прикладных наук никогда не было, нет и не будет, потому что есть наука и есть ее приложения. ( Пастер, отсюда)
А споры о терминах, на мой взгляд, совершенно неконструктивны.
Re[12]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
G>>Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
B>Мсье, ваш тон не располагает к дискуссии. Оставьте ваше "плавали-знаем" вашим проектам и "каким-то там пионэрам".
"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться?
G>>1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
B>Хто вам сказал что хуже? Это ваш домысел ...
Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
G>>2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
B>Отличие в определении. И бардаке, который возникает если вещи не называть своими именами. Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс. У юзкейса обязательно есть эктор, в отличие от сценария.
Начну с конца. Сразу, to cut off the bullshit.
Use cases do not need to be specified in a special language. They can be written in any style that suits the needs of the project.
Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
Это все, что вы хотели мне сказать? Стоило ли из-за этого разводить такой флейм? Короче, мне все ясно, и больше к вам вопросов нет.
B>В моей практике я это разделяю и называю своими именами и призываю это делать других. Не нужно иметь суперинтеллект, чтобы придумать как это использовать на практике. Если вы между собой и заказчиком договоритесь называть "горшок" "креслом", и будете понимать друг друга -- значит все ОК. Я как консультант просто перейду на ваш птичий язык и буду оперировать им . G>>Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете. B>Благодарю вас мсье, но боюсь в ближайшее время я не смогу принять ваше приглашение как "консультант-одиночка" .
Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
G>>Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит. B>"Не нукай, не запряг" (с) русская поговорка. А на вопрос я ответил выше. B>P.S. "А ты азартен, Парамоша" (с) ... момент истины, понимаешь ... Я плакалъ.
Ну, плакать, право же, не надо. Ничего страшного. Хотя...
Re[13]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Gaperton, Вы писали:
G>"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться? G>Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
Вау .. если это не хамство ... то что тогда хамство?
Скажите, каково максимальное кол-вол юзкейсов было в ваших системах, по вашему опыту? Задайте этот вопрос широкой аудитории и сравните ответы (количество) с собственным. Вот вам и разница в подходах. Требуются дополнительные пояснения???
G>Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
Еще и прецедентами их переводят ... и что? Может вы и сокращаете в разговоре до "сценариев", а другие не сокращают ... и что другие не правы, что вкладывают в сценарий несколько иное понятие?
Следуя вашей логике Use case = сценарий (в сокращенной форме). Сценарий это stories (напрашивается сокращенная форма от user stories), получаем что Use case = user stories ... великолепно .
G>У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
Не пишите и его наличие -- разные вещи.
G>Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
Эта разница будет если мы примем что сценарий есть часть юзкейса. Если это не подразумевается, но есть явная последовательность действий, то это что не сценарий??? И у него не может отсутствовать эктор?
G>Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
Да, я жалею потраченного на этот флейм с вами времени. Честь имею кланяться, мсье.
P.S. Елене привет передали?
Re[14]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
B>Вау .. если это не хамство ...
Йоу. Вот это — не хамство. Не согласны — выделите "хамство" жирным. G>>"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться?
B>то что тогда хамство?
А вот это G>>Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
написано в ответ на вашу хамоватую фразу: B>Хто вам сказал что хуже? Это ваш домысел...
Что хотели — то и получили, грех жаловаться. Неужто причинно-следственной связи между вашими постами и моими ответами не видите? Следите сначала за своими словами, а потом изумляйтесь "хамству".
B>Скажите, каково максимальное кол-вол юзкейсов было в ваших системах, по вашему опыту? Задайте этот вопрос широкой аудитории и сравните ответы (количество) с собственным. Вот вам и разница в подходах. Требуются дополнительные пояснения???
Да, требуются дополнительные пояснения.
Зачем я должен задавать этот вопрос широкой аудитории, и что мне делать с ответом? Цель — какая?
Каким именно образом я получу из ответов всю разницу в подходах? Какую такую "всю", в каких таких "подходах"?
Ответ на этот вопрос вообще не слишком показателен, потому что кейсы бывают разного уровня общности, и их можно детализировать до разного уровня — по желанию. А если явно выделять system-level use cases, то их станет еще больше. Поэтому, результаты этого никому не нужного опроса будут еще и невалидными.
Кейсы по "своим системам". Скажу, отчего не сказать. Мне скрывать нечего.
1. В бизнес-системах, которыми я знимался после универсистета, количество ролей не превышало 10, а количество прикладных кейсов — вероятно, сотни, не больше.
2. В системе CQG-клиент, которая умеет делать почти все, что нужно трейдерам, количество пользовательских кейсов исчисляется тысячами, а системных — десятками тысяч. Общий объем кода 50 мегабайт.
3. В системе CQG-сервер, системные кейсы порядка тысяч штук, до десятка, наверно.
Напоминаю вам, многоуважаемый сэр, свою просьбу — приведите пожалуйста конкретные примеры из своей практики, иллюстрирующие вашу точку зрения. Ведь она не сводится, вероятно, к тому, как правильно называть use case? Или это все, что вы хотите сказать? Все — так и скажите, "да, это все", и вопрос будет снят.
G>>Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
B>Еще и прецедентами их переводят ... и что? Может вы и сокращаете в разговоре до "сценариев", а другие не сокращают ... и что другие не правы, что вкладывают в сценарий несколько иное понятие? B>Следуя вашей логике Use case = сценарий (в сокращенной форме). Сценарий это stories (напрашивается сокращенная форма от user stories), получаем что Use case = user stories ... великолепно .
Это вы следуете своей логике, не моей. По моей логике — "хоть горшком назови, только в печь не ставь".
G>>У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
B>Не пишите и его наличие -- разные вещи.
Юрий. Хотите нормально общаться — выводы из ваших общих фраз делайте пожалуйста сами, явно, и озвучивайте их сами, не надо обрывать рассуждение в начале и заставлять собеседника догадываться, что вы хотите сказать. Есть что сказать по существу — договаривайте до конца, этот ореол таинственности и загадочности вокруг элементарных вещей, который вы создаете, задолбал уже, если честно.
G>>Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
B>Эта разница будет если мы примем что сценарий есть часть юзкейса. Если это не подразумевается, но есть явная последовательность действий, то это что не сценарий??? И у него не может отсутствовать эктор?
1. Вы выполните мою просьбу, сэр, и приведете пример сценария из вашей практики, у которого отсутствует "эктор" — для иллюстрации вашей мысли? Что может быть проще?
2. actor is something or someone who supplies a stimulus to the system. An actor cannot be controlled by the system and is defined as being outside the system. Любой сценарий начинается с внешнего по отношению к рассматриваемой подсистеме стимула, который исходит от эктора, находящегося в рамках внешней подсистемы. Ваш "сценарий без эктора" обязательно будет относится к system-level use case, у которого обязательно будут "экторы", хотите вы этого, или нет. Тот факт, что вы можете пропустить этот кейс при анализе — сути дела не меняет, это простая неаккуратность.
3. Правильнее было бы сказать, "если мы примем, что сценарий относится к юзкейсу". "Является частью" — только одно из отношений между сущностями (довольно специфическое), и по отношению к сценариям и кейсам это отношение некорректно на мой взгляд.
G>>Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
B>Да, я жалею потраченного на этот флейм с вами времени. Честь имею кланяться, мсье.
Прошу простить меня, сэр, за такое замечание, ничего личного — но вы сами это затеяли, и по моим данным прекрасно знали, на что идете. Хороший был повод для вас продемонстрировать свои познания в технике юзкейсов и свой опыт — но вы почему-то не захотели, предпочли пофлеймить и откланяться. Зачем? Непонятно.
B>P.S. Елене привет передали?
Многотысячная аудитория с замиранием серца следит за нашей дискуссией — так что вы вполне можете сами пользуясь случаем передавать приветы друзьям, родным, близким, и знакомым.
Я вот, например, пользуясь случаем передаю сердечный привет своему давнему другу dbg, известному также как Изя Рнет , и приглашаю его к себе в гости!
P.S.: Юрий, вы близко к серцу это все не принимайте пожалуйста . И правда ведь знали, на что идете .
Коллега, есть к Вам вопрос практического характера, как специалисту.
Необходимо разработать сервис, который бы периодически (например, 10 раз в сек.) получал результаты измерений некоторых параметров (5 шт.) от продвинутой железяки по специализированному протоколу поверх TCP/IP.
Сервис должен осуществлять усреднение этих параметров на периоде 1 сек. и хранение их в оперативной памяти.
Этим сервисом будут пользоваться другие компоненты. Используя API, предоставляемый сервисом, они будут запрашивать набор осреднённых значений за какой-то интервал (10-15 сек).
Плюс, сервис должен реализовать некоторый дополнительный функционал — такой, как сброс архивов работы на жёсткий диск, сигнализация о том, что одна или несколько железяк ничего не присылают и т.д.
Встаёт задача разработки ТЗ.Вернее встаёт вопрос эффективности использования вариантов использования (простите за каламбур) для описания функциональности этого сервиса.
После беглого анализа получается, что акторами для этого сервиса будут:
— железяка, которая посылает результаты измерений
— другой сервис, который, используя API, будет запрашивать усреднённые значения.
Исходя из этого, можно сформулировать два варианта использования:
1)Железяка подключается к сервису. Железяка посылает сервису значения параметров, сервис их принимает и подтверждает получение.
2)Сторонний сервис подключается к сервису, указывает интервал (опционально, если не указывается, используется значение по умолчанию — 15 сек), за который хочет получить информацию и состав параметров (опционально, если не указывается, считается, что сторонний сервис запросил значения всех параметров). Сервис возвращает запрошенные результаты.
Куда девать описание функциональности усреднения данных на интервале? Задачу усреднения сервис выполняет самостоятельно, по своей инициативе.
Актора тут никакого нет и в вариант использования это на запихнёшь. Также сервис сам занимается задачами архивирования данных, оповещения администратора о сбоях и т.д.
Получается, здесь варианты использования не применимы?
P.S. Описание системы специально очень сильно упрощено, чтобы ухватить суть.
Здравствуйте, newbie_analyst, Вы писали:
_>Необходимо разработать сервис, который бы периодически (например, 10 раз в сек.) получал результаты измерений некоторых параметров (5 шт.) от продвинутой железяки по специализированному протоколу поверх TCP/IP. _>Сервис должен осуществлять усреднение этих параметров на периоде 1 сек. и хранение их в оперативной памяти.
Понятно. Формулируете вы "объектно", поэтому сразу рефлекторно пишем CRC-Card, который фиксирует функциональность — для того, чтобы понятно стало. Формат:
+ выполняемая функция (с кем общается для ее выполнения)
Name: Service
+ Умеет получать параметры на периодической основе (Железяка)
+ Знает усредненные параметры на периоде 1 сек.
_>Этим сервисом будут пользоваться другие компоненты. Используя API, предоставляемый сервисом, они будут запрашивать набор осреднённых значений за какой-то интервал (10-15 сек).
+ Знает N последних усредненных значений.
Занятно, напоминает сервер обработки котировок.
_>Плюс, сервис должен реализовать некоторый дополнительный функционал — такой, как сброс архивов работы на жёсткий диск, сигнализация о том, что одна или несколько железяк ничего не присылают и т.д.
+ Умеет сохранять историю [усредненных] значений на диск (DiskStorage)
+ Умеет уведомлять о событиях (Listener)
_>Встаёт задача разработки ТЗ.Вернее встаёт вопрос эффективности использования вариантов использования (простите за каламбур) для описания функциональности этого сервиса.
_>После беглого анализа получается, что акторами для этого сервиса будут: _> — железяка, которая посылает результаты измерений _> — другой сервис, который, используя API, будет запрашивать усреднённые значения.
Допустим.
_>Исходя из этого, можно сформулировать два варианта использования:
_>1)Железяка подключается к сервису. Железяка посылает сервису значения параметров, сервис их принимает и подтверждает получение.
Вот как? Здесь вы сообщили мне существенно больше информации, чем раньше. Тогда правим CRC-карту — пока вы не сообщили кейс, я предполагал, что это сервис опрашивает железяку. Вместо
+ Умеет получать параметры на периодической основе (Железяка)
Пишем
+ Умеет получать новые значения параметров.
Вариант использования с эктором "Источник данных" назовем, скажем, "Получение параметров". Все, CRC-Card выбрасываем — он был нужен мне чтобы структурировать ваши слова и для иллюстрации, что кейсы дают в чем-то больше информации чем описание функциональности . Однако (хозяйке на заметку) — CRC-Card чрезвычайно мощный метод описания функциональности на мелком уровне — совершенно уникальное промежуточное представление между требованиями и дизайном.
_>2)Сторонний сервис подключается к сервису, указывает интервал (опционально, если не указывается, используется значение по умолчанию — 15 сек), за который хочет получить информацию и состав параметров (опционально, если не указывается, считается, что сторонний сервис запросил значения всех параметров). Сервис возвращает запрошенные результаты.
Замечание:
— возвращается однократно, без подписки на обновление? Или можно и так и так? Если да, то тут не один, а два кейса.
— что насчет подписки на события?
Эктор "Клиент"
1. Получить усредненные значения параметров (агрегаты — термин вводим, определим в другом месте) за заданный период.
_>Куда девать описание функциональности усреднения данных на интервале? Задачу усреднения сервис выполняет самостоятельно, по своей инициативе.
Сначала скажу, как бы сделал я, и как советую сделать вам. В функциональных требованиях раскрыть отдельным пунктом — как считаются "агрегаты", вернее — дать им там точно определение, включающее их способ расчета. use cases характеризует сценарии взаимодействия с внешним миром/способы использования вашей штуковины, отвечая на вопросы "зачем ваша штука нужна", "как и для чего она будет использоваться". Ваш сервис знает усредненные значения, и все, этого достаточно для описания кейса.
Кейсы, с одной стороны дают больше информации по сравнению с функциональными требованиями — и одновременно меньше. Парадокса никакого нет — объясняю.
Все виды структурирования информации о вашей системе — будь то кейсы, функциональные требования, тестовые сценарии (конструктивное выражение требований), разные виды спецификаций — это модели, ни одна из которых по отдельности не дает полной информации о системе. Но все они в совокупности дают достаточно полное покрытие.
Пример из дизайна/архитектуры: есть статические модели (например, диаграммы классов), поведенческие модели (например, диаграммы переходов состояний), и функциональные модели (например, диаграмма потоков данных). Они — ортогональны, то есть каждый из них описывает систему со своего угла зрения, под которым видны ее разные аспекты. "Главной" точки зрения нет — они дополняют, а не заменяют друг друга. Диаграмма классов дает информацию о структуре системы, интерфейсах составны частей, и связях между компонентами системы. Но она не дает никакой информации о поведении системы, и протоколах взаимодействия ее составных частей. В ней нет времени, она статическая. Диаграмма переходов состояний класса — задает протокол его работы, но не дает информации о его связях с соседями и роли в системе — время в ней есть, но нет структуры и связей. Диаграмма потока данных показывает, каким образом информация трансформируется и проходит через систему, и в каком порядке происходит обработка, какие данные от каких зависят и т.д. Однако, в ней нет ни времени, ни структуры. Только три типа моделей в совокупности адекватно опишут систему.
То же самое имеет место быть с разными вариантами представления требований. Вы не должны использовать какой-то один вариант — вам надо смело комбинировать все доступные варианты с целью добится максимально простого, понятного, и непротиворечивого описания вашей системы. Главное — именно это, от вас требуется хорошее ТЗ, а не точное соответствие правилам оформления use cases и правильность выполнения других техник.
В этом вся суть — не надо сдвигать акцент с разработки продукта на разработку документации и соответствие каким либо формальным правилам. Пусть теоретики и прочая публика кто на этом зарабатывает этим занимается. Не полагайтесь на формальные техники — понимание сути ваших проблем и умение объясняться простып и понятным человеческим языком гораздо важнее. Техники, которые лично вам помогают добиться главной цели — простого и понятного ТЗ применяйте. Которые не помогают — нахер, пишите как умеете концетрируясь на сути ваших проблем.
Не позволяет вам use case записать алгоритм усреднения? Любая другая проблема? К черту техники, пишите как вам кажется правильным. Тоже мне, проблема. Что, работать хуже будет, если некошерно, не по учебникам документацию написать, чтоли? Да все ровно наоборот .
_>Актора тут никакого нет и в вариант использования это на запихнёшь. Также сервис сам занимается задачами архивирования данных, оповещения администратора о сбоях и т.д.
В функциональных требованиях описать. Кстати, административный интерфейс неплохо также описать кейсами каким-нить. "Администратор" — это очень похоже на эктора.
_>Получается, здесь варианты использования не применимы?
Да вот еще. С какой стати? Просто не надо чудес от этой "техники" ждать. Потому что нет там никакой особой техники на самом деле — не техника приводит вас к успеху, а ваши мозги и понимание проблем. "Варианты использования" — это всего лишь один из способов представления требований, иногда полезный — не более того.
Для пищи к размышлению — даю свою форму документа требований, который после разработки креативно копипастится в ГОСТ-овское ТЗ.
1. Требования к окружению — в каком окружении ваша штука будет работать. Структурная схема типового окружения, описание вольным текстом — в составе какой системы/комплекса то должно функционировать.
2. Требования к внешним интерфейсам (если они есть). Тут не надо ничего выдумывать — либо специальные требования есть, либо их нет. У вас, скажем, требования — TCP/IP.
3. Сценарии/способы использования.
Отвечает на вопрос — как ваша штука будет использоваться.
Сюда узкейсы вольным текстом — простым и человеческим, в терминах окружения.
4. Фукциональные требования
"Определение" вашей штуки. Что она умеет делать.
5. Прочие требования.
Все, что не влезло в предыдущие секции, но существенно.
Этот простенький пример я привёл для того, чтобы проиллюстрировать, что достаточно большая часть функционала (в этом случае одна треть или больше) системы не покрывается вариантами использования.
Но, наверное, это действительно не страшно, и дыры можно закрывать функциональными требованиями.
И всё-таки один вопрос меня мучает.
Как мне организовать раздел ТЗ № 4.2 "Требования к функциям системы"? Сваливать туда вперемешку варианты использования, функциональные требования, вытекающие из вариантов использования, и функциональные требования, возникшие сами по себе?
Либо только варианты использования и самостоятельные функциональные требования, чтобы не дублировать описание одной и той же функциональности и не путать заказчика?
, и приглашаю его к себе в гости! 
