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

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

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 в гостовые документы. Приживаются, как родные.

А из каких по Вашему кубиков должна состоять тогда пояснительная записка?

Из одинаковых. А каких именно - это уж как договоритесь.

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

Гм... Завод по производству яхт (которые на заказ) - он производство? Там ведь каждая яхта по-своему уникальна в разработке. Но пилят, клеят, шлифуют, красят и лакируют их примерно одинаковыми способами. Одним и тем же оборудованием.
Как по мне, так разработка софта - ровно то же самое производство. Со своими технологиями, оборудованием, ресурсами, параметрами техпроцессов и организацией управления. Плюс массивное творческое начало которое, если его не направлять в полезное русло, стремится превратить все в хаос. Всё "как у людей".

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

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

Как эффективно учить аудитории - просто не знаю и не имею ни малейших догадок. Поэтому "безумству храбрых поем мы песню". Снимаю шляпу.

Не мы не безумцы. Мы же не аналитиков явно готовим, а более абстрактно специалист по информ систем.