Мы в вузе используем ГОСТ 34.601-90. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. при выполнении курсовых и дипломных работ.

Как вы считает, на какой стадии следует использовать варианты использования (диаграмму и описания ВИ). Почему-то раньше особо не задумывался, поскольку мало студентов решались браться за ВИ, но сейчас тенденция и изменилась, и студенты с удовольствием их используют.

Типично размещают их в техническом проекте, как часть функциональной схемы. Однако мое мнение, что эти ВИ лучше размещать в 1. Формирование требований к АС, в пункте 1.2. Формирование требований пользователя к АС.

А у вас какие мнения?

Для начала нужно понять что в ГОСТ подразумевается под требованиями пользователя к АС.... это скорее то что называется stakeholder requests в RUP.

Для начала нужно понять что в ГОСТ подразумевается под требованиями пользователя к АС.... это скорее то что называется stakeholder requests в RUP.

Юра, а зачем понимать. Мы достаточно опытные люди и можем определить этом место сами.

В ГОСТе - чуть ниже есть комментарий, если тебе поможет:
"а) подготовку исходных данных для формирования требований АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы);
б) формулировку и оформление требований пользователя к АС."

Как я это понимаю. Коберн и иные говорят: найди заинтересованных лиц, пойми их задачи, договорись о том, как они решаются будущей системой. Если посмотреть Вигерса, то у него сначала идет образ решения (по ГОСТ это вторая стадия), потом идет описание ВИ и далее спецификация требований.

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

Business use cases — в требованиях пользователей (stakeholder requirements)

System use cases — в ЭП/ТП

Business use cases — в требованиях пользователей (stakeholder requirements)
System use cases — в ЭП/ТП

Спасибо. Денис. А как на твой взгляд будут отличаться BUCs от SUCs, Есть подозрение, что сделать это студенту будет не просто, а преподавателю -руководителя тоже. Понятно, что критерием будет контекст.

Тем не менее, следую твоим советам, варианты использования следует помещать в область технического проекта. А в каком разделе? Схема функциональной структуруы?

Вроде бы Юра в своей презентации-мапинге разных методологий находил место СВИ.
С БВИ советую не связываться и говорить студентом, что мы описываем только СВИ.

Я искренне не понимаю, зачем в ГОСТе искать место тому, что там не предусмотрено. Но, imho, на этапе 1, до разработки концепции, использование ВИ бессмысленно. Что имели в виду авторы пункта под "требованиями пользователя", сейчас трудно сказать, но это явно не user requirements. На этом этапе никто ещё даже не представляет, чью деятельность эта АС будет автоматизировать.

Словом "пользователь" здесь, судя по всему, обозначают Заказчика (именно так, с большой буквы, в лице заказывающего ведомства или министерства).

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

Эд, а посмотри: http://blog.shumoos.com/archives/288
Это гипотеза, но довольно вероятная.

<Если это верно>, Тогда ВИ действительно лучше отнести на следующие стадии.

PS. Я согласен с коллегами. Знания о правилах работы с ГОСТ-ами похоже остались в глубоком прошлом. Сейчас попытка с ними работать и спецам то сносит голову, так что говорить о студентах?

Я искренне не понимаю, зачем в ГОСТе искать место тому, что там не предусмотрено.

Я пытался сказать в первом посте, что студенты делают выпускные работы, придерживаясь методических указаний, которые представляются собой компиляцию из ГОСТ. А в проектировании используют UML и в том числе варианты использования.

Потому и хочется соединить, как ты выражаешься несоединимое.

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

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

Эд, а посмотри: http://blog.shumoos.com/archives/288
Это гипотеза, но довольно вероятная.

Может быть трудно сказать. Ясно, что размещать их в ТЗ не следует. Но оговорюсь, у того же Вигерса ТЗ идет следом за ВИ, а не наоборот. При ВИ у него вытекает из Образа решения.

Спасибо. Денис. А как на твой взгляд будут отличаться BUCs от SUCs,

Так, как например отличается группа сценариев «Купить товар» от «Заказать товар» — первая предполагает описание всех видов деятельности, необходимых для приобретения товара — как автоматизируемых, так и не автоматизируемых, а вторая — только автоматизируемые.

Есть подозрение, что сделать это студенту будет не просто, а преподавателю -руководителя тоже. Понятно, что критерием будет контекст.

Приходи в скайп если что, помогу.

Тем не менее, следую твоим советам, варианты использования следует помещать в область технического проекта. А в каком разделе? Схема функциональной структуруы?

Схема — это схема, т.е. в случае UC — диаграмма UC и их пакетов. Тексты сценариев можно размещать в документе
Описание автоматизируемых функций, раздел Характеристика функциональной структуры.
 

Я искренне не понимаю, зачем в ГОСТе искать место тому, что там не предусмотрено. Но, imho, на этапе 1, до разработки концепции, использование ВИ бессмысленно. Что имели в виду авторы пункта под "требованиями пользователя", сейчас трудно сказать, но это явно не user requirements. На этом этапе никто ещё даже не представляет, чью деятельность эта АС будет автоматизировать.

Словом "пользователь" здесь, судя по всему, обозначают Заказчика (именно так, с большой буквы, в лице заказывающего ведомства или министерства).

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

Я своим студентам рассказываю, что в СССР «пользователем» называли организацию, т.к. считалось, что только у организаций есть полномочия заказывать систему

Мы используем в онлайн-курсе трёхмодульную схему БТ-Концепция-ТЗ с опорой на российские и международные стандарты, получается сложно, зато универсально.

И я всё-таки рекомендую ознакомиться с типовой структурой Stakeholder Requirements по IEEE 29148-2011, там есть раздел про сценарии.

Так, как например отличается группа сценариев «Купить товар» от «Заказать товар» — первая предполагает описание всех видов деятельности, необходимых для приобретения товара — как автоматизируемых, так и не автоматизируемых, а вторая — только автоматизируемые.

+1.

Если брать подход Коберна, то «Купить товар» это ВИ уровня змея, в контексте которого выполняются ВИ уровня моря такие как «Заказать товар» и другие.

Эдуард, я как раз тут (http://it-analysis.blogspot.ru/2013/10/use-cases-34.html) излагал свои мысли по этому поводу.

Эдуард, я как раз тут (http://it-analysis.blogspot.ru/2013/10/use-cases-34.html) излагал свои мысли по этому поводу.

Спасибо, Павел. Не могу сказать, что стало понятнее, особенно после прочтения комментариев

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

Бизнес ВИ естественно размещаются на разделе формирования требований, как советует Денис Бесков. Кстати, я тоже советовал так ранее студентам, но потом это как-то потерялось. Вообще наверное, на стадии формирования требований должна быть сформирована модель AS IS, как бы она не создавалась. Нет?