Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Как эффективно учить аудитории - просто не знаю и не имею ни малейших догадок. Поэтому "безумству храбрых поем мы песню". Снимаю шляпу.Не мы не безумцы. Мы же не аналитиков явно готовим, а более абстрактно специалист по информ систем.
Эд, отписал.Денис, каюсь нет. Если у тебя он имеется, можешь поделиться?
Ты давал авторам стандартный чеклист ошибок по Коберну?
Ну а что касается обучения системному мышлению, так лично у меня в Вузе был курс системного анализа. Так что да, учили. Как сейчас - не знаю. Тоже учат, скорее всего. И наверное, даже лучше, чем меня (я-то был редким раздолбаем). Вот только проку мне от их познаний в области системного мышления, когда на практике нужны навыки?Такого предмета у наших студентов нет. Правда, в рамках читаемого мною предмета есть раздел, посвященный системному анализу и основам теории систем.
Возможно, действительно не совсем понял. Но с другой стороны - а-ля ГОСТ есть, и есть потребность вставить куда-нибудь туда последнюю све... то есть, ВИ.Ну так ровно тоже можно сказать о DFD, BPMN, IDEF0 и IDEF3.
А ведь это совсем не проблема оформления. Это коллизия систематизации информации. Как если бы один конструктор состоял из кубиков, а другой - из пирамидок. Пока играем только одним или другим - все замечательно. Но когда несколько кубиков в конструкторе меняют на пирамидки - начинаются проблемы. То углы пирамидок за пределы кубиков торчат, то кубики на вершинах пирамидок не стоят. Даже примеры из приложенной инструкции не собираются.А из каких по Вашему кубиков должна состоять тогда пояснительная записка?
Почему? Можете раскрыть мысль?Производство - это создание чего-либо по заранее подготовленной технологии, тут главное контролировать параметры процесса и характеристики исходного сырья. Ну это на мой взгляд. Программы не производятся, они разрабатываются. Производятся копии(на болванках). Ну такое вот мое представление:)
Песня действительно не новая.Ага, первая фраза на работе- забудьте то, чему вас учили в вузе. У нас все по другому. Потому не стоит видимо и пытаться.
Я бы в ВИ написал неАга понял.
"1. Менеджер меню делает запрос на создание меню на определенную дату."
а
"1. Менеджер меню делает запрос на создание меню на определенную дату в пределах допустимых дат."
и все, потоки 10.1 и 10.2 уже не нужны:)
ВИ писал один человек, а реализовывал другой?Точно так.
И еще вопрос по пункту 5. Там речь идет о типе меню всего меню, или о типе меню в котором находится блюдо выбранной категории?В реальной постановке было, есть меню кафетерию в который входя разные блюда, в том числе и из ресторанов. Т.е. кафетерий договаривается и часть блюд не готовит и заказывает у ресторанов. Клиенту дается понять, что он может заказывать блюда из соседних ресторанов. Но это довольно опционально.
Если не уточнить этот вопрос, может показаться, что есть два вида "типов меню", один тип меню у каждого блюда, и один тип меню у всего меню, в которые входят блюда, каждое со своим типом меню:)
Зачем вообще все так переусложнять с типами меню? Это было озвучено в задаче или так решил создатель ВИ?
Если основной поток занимает больше 7-10 строк, я предпочитаю выносить даже мелкие ветвления в альтернативные потоки. Здесь можно было бы так сделать.Ну нравится не нравится, тут как говорится дело вкусов. Почему такой стиль вызывает у вас негативные эмоции?
И ещё мне нравится стиль описания ветвлений, когда в точке ветвления (2) пишется что-то типа:
"1. Менеджер меню делает запрос на создание меню на определенную дату.
2. Система проверяет существование меню на указанную дату.
3. Система выводит новое меню с входящим в него списком стандартных блюд."
, а остальная часть ветвления выносится в альтернативный поток.
Разве если менеджер изменит цену на экране, то это изменение может на нём не отобразиться? Или имеется ввиду что-то другое и нужно уточнить пункт?Думаю, студент не совсем понял идею диалога. Возможно ему показалось. что когда клиент что-то ввел в поле система это отобразила - т.е. некое действие. Конечно. тут ошибка. Действия системы нет. Если бы изменилась общая сумма, подсветилась строка, куда вводится цена. Другой разговор.
Если верить этому пункту, то мы можем добавить в меню блюда категорий, не разрешённых новым типом меню (на который меняем). Так не должно быть?А что есть новый тип? По-моему в описании сказано, что выбирается тип меню, а потом категория блюда. Но я согласен, описанные действия далеко не ясные.
Как я понял прямой связи с блюдом не должно быть. Будет связь между типами меню и категориями многие-ко-многим и между категориями и блюдами (один-ко-многим или многие-ко-многим). Я не прав?Ну из описания ВИ Вы никаких таких вывод сделать не можете, верно? На самом деле в реализации Категория блюда и Тип меню - атрибут блюда. Не уверен есть ли перечисление или таблица с категориями и типами, но это 1-ко-многим в лучшем случае. Между Типами и категориями связь опосредованная, но получается что одно блюдо может быть отнесено только к одной категории и только к одному типу меню. Без вариантов.
Кем задан этот порядок и в каком порядке должны располагаться категории между первыми и напитками? Сначала салаты, а потом вторые или наоборот?Порядок задан Заказчиком
1. Почему бы сразу не обязать менеджера при создании меню выбирать тип? Это избавит его от ошибок, а нас от альтернативного потока 10.4 - да и выглядит коряво с точки зрения юзабилити:)Согласен.
2. Судя по ВИ, менеджер не может сохранить стандартный набор блюд как новое меню. Согласно 3.2 он обязан добавить новые блюда. Это так задумано или студент недосмотрел?Да в ВИ не указано явно, но стандартный набор блюд должен всегда присутствовать в меню. Потому при создании меню, блюда помеченные как стандартные автоматом переносятся в создаваемое меню.
3. Альтернативный поток 10.3 - не вижу его применения. Судя по ВИ, категория выбирается только при добавлении нового блюда. А если он хочет добавить новое блюдо, то выбор категории обязателен и осуществляется до выбора блюда. Таким образом я не вижу как ВИ может перейти в этот поток.Согласен. Мне этот момент тоже показался весьма странным. На реализации это выглядит так.
1. Описания ВИ применяются в "Программе и методике испытаний" (код "ПМ") в качестве методов проверки системы на соответствие требованиям ТЗ.Леонид, спасибо за Ваше мнение. Но получается ВИ - это уже результат реализации системы. Это противоречит всему моему представлению об этой технологии сбора требований и описания системы.
2. Диаграмму ВИ можно применять в том же документе для пояснения, каким образом решены задачи разработки системы (из раздела 2 ТЗ), но будет избыточный "бантик".
Соответственно, где-то между стадиями "Рабочая документация" и "Ввод в действие". В зависимости от того, на какую стадию конкретного проекта запланирована разработка ПМ.
Переход от системного мышления к "клиповому". Наблюдаю то же самое в среде "молодых специалистов".Т.е. Вы полагаете, что до введения ВИ у студентов было системное мышление и их этому учили? Можно подробнее о наблюдениях?
Жаль студентов. Методические указания по скрещиванию теплого с мягким загоняют их в ситуацию, в которой сделать что-то приличное в принципе невозможно. А потом они приходят на "производство" и пытаются работать так же (ну, те, кто вообще пытается).1. Вы не совсем поняли. Есть методуказания по оформлению и требования к содержанию. Они есть аля ГОСТ 34. Хорошо это или плохо - думаю не очень и важно. Главное есть определенная структура, которой можно следовать. Мне она лично не нравится, я не воспринимаю студенческую работу как проект, все-таки это совокупность работ, которыми студент должно продемонстрировать свою уровень: умение системно или логично мыслить, понимать причины, понимать причинно-следственную связь, демонстрировал свои знания и умения. Сама методичка это особо не мешает явно, но создает неявные проблемы. Но они не столь серьезны, сложнее объяснять студенту почему ему здесь нужно написать это и это, а не то что как ему кажется написано в методичке.
4. Ну и проверку на даты я бы не стал включать как альтернативные потоки. Просто контроль при создании меню и все.Что значит просто контроль? АП вроде как раз и включает описания исключений, которые могут возникнуть при неверных данных.
… и теперь пожалуйста доступ на комментирование.Денис, ты больше меня пользуешься GDocs, посоветуй как корректно настроить доступ. Я дал доступ всем, но вот про комментарии не понял как.
Эд, а опубликуй в GDocs, тогда будет проще комментировать попунктно.Хорошо.
Эдуард, я как раз тут (http://it-analysis.blogspot.ru/2013/10/use-cases-34.html) излагал свои мысли по этому поводу.Спасибо, Павел. Не могу сказать, что стало понятнее, особенно после прочтения комментариев
