Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 08 Ноября 2013, 20:32:27
-
Мы в вузе используем ГОСТ 34.601-90. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. (http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53) при выполнении курсовых и дипломных работ.
Как вы считает, на какой стадии следует использовать варианты использования (диаграмму и описания ВИ). Почему-то раньше особо не задумывался, поскольку мало студентов решались браться за ВИ, но сейчас тенденция и изменилась, и студенты с удовольствием их используют.
Типично размещают их в техническом проекте, как часть функциональной схемы. Однако мое мнение, что эти ВИ лучше размещать в 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, как бы она не создавалась. Нет?
-
Мы в вузе используем ГОСТ 34.601-90. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. (http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53) при выполнении курсовых и дипломных работ.
Как вы считает, на какой стадии следует использовать варианты использования (диаграмму и описания ВИ).
1. Описания ВИ применяются в "Программе и методике испытаний" (код "ПМ") в качестве методов проверки системы на соответствие требованиям ТЗ.
2. Диаграмму ВИ можно применять в том же документе для пояснения, каким образом решены задачи разработки системы (из раздела 2 ТЗ), но будет избыточный "бантик".
Соответственно, где-то между стадиями "Рабочая документация" и "Ввод в действие". В зависимости от того, на какую стадию конкретного проекта запланирована разработка ПМ.
Почему-то раньше особо не задумывался, поскольку мало студентов решались браться за ВИ, но сейчас тенденция и изменилась, и студенты с удовольствием их используют.
Переход от системного мышления к "клиповому". Наблюдаю то же самое в среде "молодых специалистов".
Типично размещают их в техническом проекте, как часть функциональной схемы.
Однако мое мнение, что эти ВИ лучше размещать в 1. Формирование требований к АС, в пункте 1.2. Формирование требований пользователя к АС.
А у вас какие мнения?
Мое мнение, что ВИ - суть сырье для разработки требований, один из источников. И если очень хочется включить исходные материалы в дополнение к требованиям - почему бы и нет? ГОСТ не запрещает. Можно и в упомянутые документы, и в ТЗ, и в технорабочий проект (как минимум, в качестве приложений). Другое дело, что это не сильно нужно, может вызвать соответствующие вопросы и увеличивает объем документации, не увеличивая ее содержательное наполнение.
Я пытался сказать в первом посте, что студенты делают выпускные работы, придерживаясь методических указаний, которые представляются собой компиляцию из ГОСТ. А в проектировании используют UML и в том числе варианты использования.
Жаль студентов. Методические указания по скрещиванию теплого с мягким загоняют их в ситуацию, в которой сделать что-то приличное в принципе невозможно. А потом они приходят на "производство" и пытаются работать так же (ну, те, кто вообще пытается).
-
Эдуард, я как раз тут (http://it-analysis.blogspot.ru/2013/10/use-cases-34.html) излагал свои мысли по этому поводу.
Не могу согласиться. Задача технического проекта - дать Заказчику детальное представление о разрабатываемой системе. То есть о том, как Исполнитель собирается решать задачи и удовлетворять требования, обозначенные в ТЗ. Описывать то, что у Заказчика и так есть, в ТП совершенно не нужно. Этим материалам место в "Отчете об обследовании" или, если очень надо, в разделе ТЗ "Характеристика объектов автоматизации".
ВИ в "Описании процесса выполнения функций" можно применять, если дела совсем плохи и полноценное описание дать невозможно (некогда, некем). И то стоит несколько раз подумать - может, вообще без описания будет лучше.
-
В моем понимание ТП - это архитектура решения. СВИ - это требования уровня пользователя. Поэтому я придерживаюсь позиции:
В ТЗ пишем кратко состав функций, а в приложении ДВИ и спецификация.
-
В моем понимание ТП - это архитектура решения. СВИ - это требования уровня пользователя. Поэтому я придерживаюсь позиции:
В ТЗ пишем кратко состав функций, а в приложении ДВИ и спецификация.
(на правах примечания, а не вторжения в частное мнение)
В понимании ГОСТ, ТП - это всеобъемлющее описание проектируемого решения. Включающее в т.ч. и архитектуру, которая в норме составляет довольно небольшую часть ТП.
"Масштабы" ТП можно оценить по совокупности ГОСТ 34.201-89 и РД 50-34.698-90.
-
1. Описания ВИ применяются в "Программе и методике испытаний" (код "ПМ") в качестве методов проверки системы на соответствие требованиям ТЗ.
2. Диаграмму ВИ можно применять в том же документе для пояснения, каким образом решены задачи разработки системы (из раздела 2 ТЗ), но будет избыточный "бантик".
Соответственно, где-то между стадиями "Рабочая документация" и "Ввод в действие". В зависимости от того, на какую стадию конкретного проекта запланирована разработка ПМ.
Леонид, спасибо за Ваше мнение. Но получается ВИ - это уже результат реализации системы. Это противоречит всему моему представлению об этой технологии сбора требований и описания системы.
Переход от системного мышления к "клиповому". Наблюдаю то же самое в среде "молодых специалистов".
Т.е. Вы полагаете, что до введения ВИ у студентов было системное мышление и их этому учили? Можно подробнее о наблюдениях?
Жаль студентов. Методические указания по скрещиванию теплого с мягким загоняют их в ситуацию, в которой сделать что-то приличное в принципе невозможно. А потом они приходят на "производство" и пытаются работать так же (ну, те, кто вообще пытается).
1. Вы не совсем поняли. Есть методуказания по оформлению и требования к содержанию. Они есть аля ГОСТ 34. Хорошо это или плохо - думаю не очень и важно. Главное есть определенная структура, которой можно следовать. Мне она лично не нравится, я не воспринимаю студенческую работу как проект, все-таки это совокупность работ, которыми студент должно продемонстрировать свою уровень: умение системно или логично мыслить, понимать причины, понимать причинно-следственную связь, демонстрировал свои знания и умения. Сама методичка это особо не мешает явно, но создает неявные проблемы. Но они не столь серьезны, сложнее объяснять студенту почему ему здесь нужно написать это и это, а не то что как ему кажется написано в методичке.
2. UML в методичке не прописан, методологии по которым им следует разрабатывать свои проекты тоже. Так что нет никаких скрещиваний.
3. Проблемы возникают при оформлении работы. Это да. Вот я и поднял дискуссию, чтобы пройтись по этой теме.
4. То, что студенты приходят на "производство" (это слово уж точно не для ИТ-индустрии) и делают не так как ожидает "производитель" - ну эту песню я слышу всю свою жизнь. Не подумайте, что СССР, потом Россия, так уж уникальны в этом, при всей феншуйности западного образования.
5. Ну впрочем эта очень философичная тема и я ее поднимать здесь не хочу. Без обид, Леонид?
-
Но получается ВИ - это уже результат реализации системы. Это противоречит всему моему представлению об этой технологии сбора требований и описания системы.
Ну, я про сбор ничего и не говорил. ВИ могут быть разными. Те, о которые применяются в ГОСТовой документации, можно было бы назвать "Варианты использования системы в целях подтверждения ее соответствия заявленным требованиям". Или "методы испытаний", если короче.
Т.е. Вы полагаете, что до введения ВИ у студентов было системное мышление и их этому учили? Можно подробнее о наблюдениях?
Не совсем так. Скорее я склонен рассматривать ВИ и набирающие популярность agile-процессы как следствие изменений в мышлении. Оно становится ориентированным на все более короткие "итерации". Вместо "фильмов" люди думают "клипами". Можно поинтересоваться у учителей литературы старших классов (я поинтересовался) - дети из года в год все больше утрачивают способность воспринимать тексты целостно, с трудом осиливают разве что яркие эмоциональные фрагменты. С таким мышлением оперировать ВИ (или "юзер-сторями") значительно проще, чем, например, алгоритмами.
Ну а что касается обучения системному мышлению, так лично у меня в Вузе был курс системного анализа. Так что да, учили. Как сейчас - не знаю. Тоже учат, скорее всего. И наверное, даже лучше, чем меня (я-то был редким раздолбаем). Вот только проку мне от их познаний в области системного мышления, когда на практике нужны навыки?
1. Вы не совсем поняли. Есть методуказания по оформлению и требования к содержанию. Они есть аля ГОСТ 34...
2. UML в методичке не прописан, методологии по которым им следует разрабатывать свои проекты тоже. Так что нет никаких скрещиваний.
3. Проблемы возникают при оформлении работы. Это да. Вот я и поднял дискуссию, чтобы пройтись по этой теме.
Возможно, действительно не совсем понял. Но с другой стороны - а-ля ГОСТ есть, и есть потребность вставить куда-нибудь туда последнюю све... то есть, ВИ.
А ведь это совсем не проблема оформления. Это коллизия систематизации информации. Как если бы один конструктор состоял из кубиков, а другой - из пирамидок. Пока играем только одним или другим - все замечательно. Но когда несколько кубиков в конструкторе меняют на пирамидки - начинаются проблемы. То углы пирамидок за пределы кубиков торчат, то кубики на вершинах пирамидок не стоят. Даже примеры из приложенной инструкции не собираются.
4. То, что студенты приходят на "производство" (это слово уж точно не для ИТ-индустрии)
Почему? Можете раскрыть мысль?
и делают не так как ожидает "производитель" - ну эту песню я слышу всю свою жизнь. Не подумайте, что СССР, потом Россия, так уж уникальны в этом, при всей феншуйности западного образования.
5. Ну впрочем эта очень философичная тема и я ее поднимать здесь не хочу. Без обид, Леонид?
Песня действительно не новая. :)
Какие могут быть обиды? Наоборот, весьма интересно послушать практикующих людей, которые видят происходящее с позиций, отличный от твоих.
-
Ну а что касается обучения системному мышлению, так лично у меня в Вузе был курс системного анализа. Так что да, учили. Как сейчас - не знаю. Тоже учат, скорее всего. И наверное, даже лучше, чем меня (я-то был редким раздолбаем). Вот только проку мне от их познаний в области системного мышления, когда на практике нужны навыки?
Такого предмета у наших студентов нет. Правда, в рамках читаемого мною предмета есть раздел, посвященный системному анализу и основам теории систем.
Я согласен, что привить культуру системного мышления крайне сложно, и Ваши наблюдения подтверждаются фактами. Правда, я не делал подобный измерений, но есть такое ощущение, что с каждым годом уровень студентов понижается.
Но говорить что у них у всех клиповое мышление, ну я бы не подписался под этим. Разные бывают.
Мне например никто не преподавал системный анализ, ну ничего как-то клиповости нет.
Возможно, действительно не совсем понял. Но с другой стороны - а-ля ГОСТ есть, и есть потребность вставить куда-нибудь туда последнюю све... то есть, ВИ.
Ну так ровно тоже можно сказать о DFD, BPMN, IDEF0 и IDEF3.
А ведь это совсем не проблема оформления. Это коллизия систематизации информации. Как если бы один конструктор состоял из кубиков, а другой - из пирамидок. Пока играем только одним или другим - все замечательно. Но когда несколько кубиков в конструкторе меняют на пирамидки - начинаются проблемы. То углы пирамидок за пределы кубиков торчат, то кубики на вершинах пирамидок не стоят. Даже примеры из приложенной инструкции не собираются.
А из каких по Вашему кубиков должна состоять тогда пояснительная записка?
Почему? Можете раскрыть мысль?
Производство - это создание чего-либо по заранее подготовленной технологии, тут главное контролировать параметры процесса и характеристики исходного сырья. Ну это на мой взгляд. Программы не производятся, они разрабатываются. Производятся копии(на болванках). Ну такое вот мое представление:)
Песня действительно не новая. :)
Ага, первая фраза на работе- забудьте то, чему вас учили в вузе. У нас все по другому. Потому не стоит видимо и пытаться.
-
Но говорить что у них у всех клиповое мышление, ну я бы не подписался под этим. Разные бывают.
Так и я не подписывался. Я говорил про такую распространенность явления, которая успешно продвигает новые методологические решения. Переход, так сказать, количества в качество.
Наличие "разных" никаким сомнениям не подвергаю.
Ну так ровно тоже можно сказать о DFD, BPMN, IDEF0 и IDEF3.
Все перечисленное ближе к идеологии, применяемой в госстандартах. Так или иначе, это ёмкое описание процессов, в отличие от ВИ, которые по определению лишь один из "маршрутов" его прохождения.
Лично мне неоднократно доводилось включать IDEF0 в гостовые документы. Приживаются, как родные.
А из каких по Вашему кубиков должна состоять тогда пояснительная записка?
Из одинаковых. А каких именно - это уж как договоритесь.
Производство - это создание чего-либо по заранее подготовленной технологии, тут главное контролировать параметры процесса и характеристики исходного сырья. Ну это на мой взгляд. Программы не производятся, они разрабатываются. Производятся копии(на болванках). Ну такое вот мое представление:)
Гм... Завод по производству яхт (которые на заказ) - он производство? Там ведь каждая яхта по-своему уникальна в разработке. Но пилят, клеят, шлифуют, красят и лакируют их примерно одинаковыми способами. Одним и тем же оборудованием.
Как по мне, так разработка софта - ровно то же самое производство. Со своими технологиями, оборудованием, ресурсами, параметрами техпроцессов и организацией управления. Плюс массивное творческое начало которое, если его не направлять в полезное русло, стремится превратить все в хаос. Всё "как у людей".
Ага, первая фраза на работе- забудьте то, чему вас учили в вузе. У нас все по другому. Потому не стоит видимо и пытаться.
Честно говоря, даже не представляю, как учить аналитиков академически. Те курсы, которые я наблюдал или имел возможность "прикоснуться" через коллег, полезны в первую очередь не слушателям, а организаторам как совокупность систематизирующего, продуктопродвигающего и финансового начал.
Я могу "поднять" человека с нуля до младшего аналитика за пару месяцев. До просто аналитика - за полгода. Но это достигается методом "делай с ним". Таким образом могу вести максимум двоих, и это реально тяжело. Как эффективно учить аудитории - просто не знаю и не имею ни малейших догадок. Поэтому "безумству храбрых поем мы песню". Снимаю шляпу.
-
Как эффективно учить аудитории - просто не знаю и не имею ни малейших догадок. Поэтому "безумству храбрых поем мы песню". Снимаю шляпу.
Не мы не безумцы. Мы же не аналитиков явно готовим, а более абстрактно специалист по информ систем.