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

Все-таки скажу как и что мы делаем.
Цель - построить модель функционирования системы, сформулировать функциональные требования, построить инфологическую модель. Пощупать ее в акцессе.
С чего мы начинаем:
1. формирование текстуального описания объекта обследования, т.е. заполняется некий шаблон документа, с выделенными позициями для заполнения: цель документа, цель систему, глоссарий, источники информации, внешние факторы, внутренние факторы, общее состояние проблемы, имеющиеся предпосылки, рекомендации куда двигаться дальше. Верю - сложновато у меня получилось, вернее слишком кусок большой, откусить можно - прожеват не каждый может. Задание уменьшить - свести к довольно элементарному процессу, например прием товара на склад и баста - и пускай всю цепочку рассмотрят.
2. используя описание или делая это параллельно - формируем IDEF0 - до нужной стадии декомпозиции - в первую очередб выделить функции- которые передендуют на звание подсистемы
3. Вот одну из этих подсистем  и разбиарем более подробно с точки зрения автоматизации использую DFD и показывая потоки данных, хранилища и логику обработки
4. далее делаем скачок к ИЛМ, либо автоматом из BPWIN либо просто из анализа документов, последнее лучше, первое логичнее.

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

Знания должны проявится в будущем - например в проектировании ИС. К тому же у меня в след. семестре будет предмет, в котором я буду давать уже UML, вот тут можно и заставить немного покумекать.
Вообще идея была - дать в одном семестре структурный методв, а в другом объектный -и чтобы студенты сделали вывод, что лучше и когда

Цель - построить модель функционирования системы, сформулировать функциональные требования, построить инфологическую модель. Пощупать ее в акцессе.

Вот я чего у вас не вижу - так это чёткого перехода от моделирования AS-IS к TO-BE - как этот процесс происходит? Как меряется корректность и точность модели AS-IS, как оценивается её полезность? Как провести имитационное моделирование, что оно может показать? Если мы хотим изменить систему (реинжиринг) и/или заменить механизмы выполнения некоторых её функций, то с какой целью? Каких показателей мы хотим добиться? Сколько вариантов автоматизации/реорганизации данной системы существует? Как выбрать из них подходящий? Только потом уже можно говорить о функциональных требованиях к вновьсоздаваемой системе. Не понимаю, что вам даёт инфологическая модель в эксессе. Какие выводы на её основе можно сделать?

Вообще идея была - дать в одном семестре структурный методв, а в другом объектный -и чтобы студенты сделали вывод, что лучше и когда

А что, есть варианты, кроме того, что структурно-функц. методы лучше подходят для описания бизнеса, а объектные - технических систем, причём скорее ПО, чем аппаратных?

Чтобы использовать анализ, надо иметь, что анализировать. То есть нужна СИСТЕМА. При этом она должна быть такой, которую будут в состоянии исследовать студенты почти самостоятельно. Естественно, решение уравнения не нужно, с другой стороны экономические и бизнес-системы недоступны в рамках семестрового курса. Остаются технические и научные системы, которые описаны достаточно точно и четко.

Да, нужен объект исследования. И на мой вгляд, работа с новыми нечёткими системами - это соль работы аналитика - прийти туда, где мало кто может изложить целостное видение и "разложить по полочкам". Если дать студенту уже формализованную систему, то он с неопределённостью работать не научится, исхо.

Я бы делал так - команде из 4- человек давал Пр.Обл. типа работы местного отделеания Почты или Магазина, Библитотеки. Дать им теорию с целями, разобрать достаточное количество примеров, рассмотреть достоинства/недостатки, показать имитационные модели, рассказать про методы сбора и формализации знаний и запустить "в поле". ДЛя этого конечно нужно иметь контакты с "экспертами" Магазина. И постоянно мониторить ход работ, помогая со всеми тупиками и затыками.

Ох, Денис, вашими устами да мед пить.

Я бы делал так - команде из 4- человек давал Пр.Обл. типа работы местного отделеания Почты или Магазина, Библитотеки. Дать им теорию с целями, разобрать достаточное количество примеров, рассмотреть достоинства/недостатки, показать имитационные модели, рассказать про методы сбора и формализации знаний и запустить "в поле". ДЛя этого конечно нужно иметь контакты с "экспертами" Магазина. И постоянно мониторить ход работ, помогая со всеми тупиками и затыками.

Это как Вы себе все это видете? У меня 30 студентов, 2 преподавателя. Хорошо разобъем на 4. Получим 7 четверок. Дальше, по поводу теории, кучи примеров, имитационных моделей и прочее - это сколько времени надо?
Далее мне нужно еще иметь контакт с магазинами и т.п. Интересно мне что делать больше нечего, как ходить по магазинам и устанавливать контакты? С кем? С товароведом. Нет это не реально. И Постоянно мониторить? Как? Механизм плиз. У меня по ГОС 36 чаосв лекции 36 часов лаб, т.е. 18 занятий, ни курсовой ни т.п. К тому же у студентов тоже не один мой предмет. Дальше?
Вы думаете я не делал нечто подобное? Знаете какой результат? Сегодня вот какое? 25 - правильно. А зачет есть? Неа, а проекты сдаются? Нет, а те что сдаются - скомканые, я студенты говорю у тебя тут то не верно, это не верно - а он на меня смотрит, ну ладноЭГ, ну ставь 3 хотябы да отпусти ты меня в поле чистое.
Хочу все-таки подчеркнуть - веротяно мы выпускаем не системных аналитиков, предметы не те, не то количество часов и акценты.
А потому надо смотреть в стороны общего знакомства, общих положений и навыков. А вот все что Вы сказали выше, отрабатывать персонально на курсовом и дипломном проектировании. Но тут есть одно но, занимаюсь анализом только я да мой напарник, а остальные преподы? Да не фига они не занимаются...

По поводу предыдущего поста

Вот я чего у вас не вижу - так это чёткого перехода от моделирования AS-IS к TO-BE - как этот процесс происходит?

А зачем, зачем усложнять задачу. Пока вопрос стоит так, есть некий процесс, процесс не автоматизирован, цель предложить решение по его автоматизации..

Я согласен с постановкой проблемы, но в моем случае она воплощения не находит. Почему?
1. К моменту изучения курса Теория информационных процессов и систем (обратите внимание на название) по идее студент должен иметь уже знания по Теории принятия решений, Теории имитационного моделирования, Теории оценивания систем, Теории систем. Однако в реальности - ничего подобного нет: фактически мне приходится галопом по Европам говорить о теории систем, теории принятия решений, теории имитационного моделирования, принятия решений. Так и было, но у меня урезали курс в два раза почти!!!!

2. Переход от AS_IS к TO-BE а так ли это важно? Он формально есть от общей схемы функционирования к схеме функционирования ИС. Да не совсем так, не очень полно. Но не возможно за 1 семестр научить все му тому, что Вы тут сказали. Не бывает так, это совокупный продукт, в не за один курс.

3. Прекрасные рекомендации
[qoute]
Каких показателей мы хотим добиться? Сколько вариантов автоматизации/реорганизации данной системы существует? Как выбрать из них подходящий?[/quote]
Сразу видно - Вы закончили инженерную специальность, и Вам многое дали из инженерных дисциплин. У нас есть похожая специальность -автоматизация химпроизводста. Но это  другое, другой базис.
Ваши аргументы не работают мне кажется полностью.

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

Сергей, ты совершенно все понимаешь. А для того, чтобы понять еще больше, давай совершим экскурс в программу обучения.
1 курс: Информатика, Структурное программирование, Дискретная математика,
2 курс: Матлогика, Информационные технологии, Теория вероятности и статистика, Статистические методы прогнозирования
3. Курс Теория информационных процессов и систем, Функционально-математическое моделирвание, Моделирование систем, Базы данных, ООП, ЭВМ и сети, Надежность или защита (не помню точно)
4. Проектирование ИС, ООП, Информационные сети, Администрирование ИС, Представление знаний, Интеллектуальные ИС
5 курс: COM технологии, web-технологии, КИС, МИровые информационные ресурсы

Ну примерно так. Что за спецы? Сам до сих пор не пойму, но есть догадка, скорее всего - это либо конструктор баз данных, либо информационный технолог (в широком понимании слова), либо программер, либо (в редких случаях системный аналитик). Т.е. конечно мы не готовим системных аналитиков (я подозреваю, что это в ГОС и не закладывалась, судя по наличию дисциплин). Однако умение провести препроектное обследование, собрать информацию, определить различные требования к системе, суметь построить модель данных, отвечающая за ПО, сравнить варианты, если нужно, и выбрать. Т.е. использование структурных методов не самоцель - а историческая ситуация, один из возможных способов формализации описания системы, формирования функциональных требований самого общего назначения.
На самом деле между SADT и RUP на стадии сбора информации и определения требований много общего. Даже скажем не с SADT, а DFD и IDEF3. ТОже есть внешние сущности, ТОже есть процессы и подсистемы, ТОже могут быть описаны в виде сценариев как словесно, так и графически. Но есть разница в идеологии использования, парадигме. Кроме того, важным аспектом все равно является ситуация сбора первичной информации, выделения из описания, документов, аналогов существенных ее аспектов. Думаю нужно и здесь быть внимательным при обучении, а также умение найденную информацию превратить в формализованное описание.
Все это ролевое обучение. Кто-то из студентов станет аналитиком, кто-то не станет, а будет скажем тестером или внедренцем или техписателем. Как ты сам говорил, нужно научить языку схем, правилам их построения, чтения и использования, а также используя ее построить систему.

Интересный поворот событий. Но мне кажется решение несколько усложнено.
Сделаем экскурс в теорию использование IDEF0. IDEF0 отображает некую статическую структуру процесса - наиболее значимые существенные связи между функциональнмы блоками. Связи эти могут быть случайными, последовательными, логическими, функциональными и другими. Однако, IDEF0 не предполагет описание четкой алгоритмической последовательности выполнения действий или функций.

Читал такой пример IDEF0 - это разметка улиц, зданий, их взаимное расположение и т.п.
А чтобы показать переход из точки А, в точку Б, скажем сипользуют IDEF3. Очевидно вариантов тут много.

Также и в нашем случае. Мы говорим, чтобы чтобы вычислить корни уравнения (т.е. решить его), мы находим дискриминант, выясняем его характеристики, находим корни, либо говорим что решение не определно. Однако оно не определено в обычной математике, скалярно, но вполне имеет решения в комплексной алгебре. Так что утверждение о решении сделанные тобой, опираются на ограничения скалярной алгебры

Кроме того решение может быть выполнено методами численной математики. Где дискриминант не находяд, а находят корни например методом Ньютона,а в этом случае выясняется природа корней, их существование, кратность и тому подобное.

Даже если принять твой постулат, я ыб все-таки реализовал несколько по другому.
Существуют два этапа вычисления:
1. Вычисление дискриминанта и его анализ на предмет вычисления корня
2. Вычисление корня - сам факт вычисления корня сводится к канонической формуле, просто при D=0, оба корня равны, т.е. имеется один корень,

Т.е. имеем два блока -
1. Вычисление дискриминанта (вход: A, B, C - выход D - управление Формула вычисления - Механизм (ручка, тетрадь, калькулятор, ЭВМ))
2. Вычисление корня (Вход - A, B, C, D, выход корни или решения нет) - управление формула вычисления корня и Результат анализа, тут есть некая путаница - Это D - все-таки вход или управление. Т.е. D ведь не претерпевает собственно изменений, так же в прочем как и A, B, C

Можно конечно, поместить между этапами этап анализа, который и будет инициирующим действием для запуска процесса решения, Хотя ведь уже на стадии вычисления дискримината мы можем сказать все о корнях, кроме их значения

А вот, что сформулировано тобой в последнем посте, мне немного не понятно. Видно не по тем книжкам учился:-))
Может разовешь мысль дальше?

Хочу еще добавить. Вычисление дискримината и посик решения(нахождение корня) функционально связанные задачи.
Т.е. d=f1(a,b,c), x = f2(a,b,c,d) = f2(a,b,c,f1(a,b,c))

Сергей, или лучше обращаться как Boatman?

Давай все-таки сформулируем для начала этапы, через которые следует пройти. Хотя бы черновой вариант. Затем возьмемся за разработку каждого этапа.
Т.е. применим системный анализ к методике его преподавания.
Чем ограничемся? Ограничимся этапами концептуального моделирования, т.е. стадией обследования и предпроектное решение. В качестве инструментария возьмем линейку allfusion modeling suite.
А дальше можно провести параллель с UML.
На выходе следует получить набор артефактов, описывающих некую поставленную проблему. Ты считаешь - задания мои сложноваты, тогда давай свое представление об уровне задания, подберем темы. Но меня конечно интересует построение решения для автоматизации.
Пусть не все рабочее место кладовщика, а скажем рабочее место приемщика ТМЦ: учет и размещение.

Давай все-таки сформулируем для начала этапы, через которые следует пройти. Хотя бы черновой вариант. Затем возьмемся за разработку каждого этапа.

Прежде чем планировать работу, имхо стоит сформулировать цель, ресурсы и ограничения.

Безусловно, все это входит в планирование работы. Планировать нужно на базе цели, ограничений и ресурсов
Правда цель очевидна - привить навыки системного анализа при формировании описания системы как функционального так и информационного
Ограничения надо подумать - хотя кратко я уже их описал, веротяно будет так: полужесткие ограничения самого задания
Ресурсы - вот этого я не очень понимаю, вернее я знаю что есть ресурсы, но что имеется в моем конкретном случае? входная информация?

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

Да согласен, пример хорош для преподавания. Возьму на вооружение.

2. предложенный процесс решения может быть автоматизирован и это достаточно дешево. Зачем доводить дело до кода: я считаю, что можно показать как проводятся трассировки от анализа к архитектурным элементам.

Нет нет, до коа доводить нет нужды, да и проблематично. Во-первых, задача не моего курса, во-вторых, студенты еще к этому моменту не изучают средства разработки приложений типа Дельфи, или даже Аксесс. Не могу же я в рамках курса успеть еще научить разрабатывать формы, запросы, отчеты в Аксесс, когда еще нет нужных знаний по SQL. Хотя в первый год пробывал - получилось кстати не плохо:-)) Но понял, что это уж слишком тяжело студентам...

3. Разработка и продвижение по теме всегда ходит кругами:

Не устаю об этом говорить, более того, когда мы обсуждаем проекты какждой пары я обращаю внимание студентов именно на этом. Вот строим модель данных, формируем связи, видим чего-то не хватает, возвращаемся к DFD или IDEF0 уточняем, корректируем и так по циклу. Вчера принимал зачеты - знаешь студенты в конце семестра просто умнеют на глазах. Три пары, фактически за неделю изменили и адаптировали сови модели, почти до желаемого результата. И сами говорят, что им было очень интересно в течение этой недели:-))

4. Из сказанного я понял, что в семестровом задании кадый должен будет выполнить задачу постановщика, сформулировав ТЗ на разработку. Правильно?

Примерно так. Может не реальное ТЗ, но хотя бы подходы к нему. Т.е. мы не рассматриваем кучу других требований, а сосредотачиваемся на функциональных требованиях и бизнес-правилах

По этому предлагаю такой вариант: каждая группа или человек в семестре и пишет ТЗ и кодирует софт по чужой постановке.

Боюсь не сумею так все организовать. Слишком велик риск, когда добросовестные студенты подготовят ТЗ, а недобросовестные нет. Может разве внутри одной пары. Нет думаю на это пока не замахиваться...
Просто не очень представляю как все это организовать...
А вот заставить сделать в конце семестра презентацию проектов и оценку проекта другими студентами вероятно можно, но боюсь врядли получится. Попробую сделать эксперимент на прае самых умных. Отработаю механизм и методику....

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

Либо просто ограничить и упростить БП. Не могу понять чем тебе не нравится задача с кладовщиком. Ну если не слишком углубляться в детали, процессы же довольно очевидны...
Есть еще предложение, чтобы задание было однотипным по сути, но разным по содержательной части. Типа в одном случае прием товаров, а в другом регистрация входящей корреспонденции.

В качестве примера цели, ресурсов и ограничений:

Цель: Создать методику преподавания системного анализа для студентов специальности "Информационные системы".

(Т.е. продукт, система - Методика)

Критерии достижения цели

• Применение данной методики позволяет систематически обучать студентов с получением среднего бала по группе не ниже 4,0 по разработанной системе тестов по перечню навыков или
• Не менее 40% cтудентов, обучаемых согласно данной методике, могут успешно работать (по признанию работодателя) в качестве помощника аналитика по окончанию обучения.

Ресурсы
Для реализации методики могут использоваться аудиторный фонд института (в пределах 50 часов), интернет-ресурсы (в пределах 30 часов). Для преподавания могут быть привлечены 2 преподавателя.

Ограничения
Методика обучения не должна тематически серьёзно отличаться от ГОСа.
Методика обучения должна позволять обучение студентам, закончившим 2 курса технического вуза.
Методика обучения должна позволять достижение целей обучения за 1 семестр и 74 часа занятий.
Методика должна позволять обучение не менее 30 человек/семестр.
Использование методики не должно предполагать закупку нового оборудования или ПО сверх имеющегося фонда.

... и т.д.

• Попробую переформулировать.
  
  Цель: Выработать методику преподавания системного анализа для студентов специальности 230201 "Информационные системы и технологии" в рамках дисциплины "Теория информационных процессов и систем".
  
  Критерии достижения цели
  Каждый студент должен правильно использовать методологии IDEF0,(IDEF3), DFD, IDEF1x -хотя бы с технической точки зрения.
      Уметь анализировать документы и выделять из них требуемые сведения.
      Уметь собирать и формулировать требования
  Применение данной методики позволяет систематически обучать студентов с получением среднего балла по группе не ниже 3,5 (будем скромнее) по итогам сессии - работы в семестре и экзамене
  Не менее 40% cтудентов, обучаемых согласно данной методике, должны успешно применять свои знания при реализации новых проектов.
  
  Ресурсы
  Для реализации методики могут использоваться аудиторный фонд института (в пределах 72 часов: 36 лекционные и 36 практические). Для преподавания могут быть привлечены 2 преподавателя.
  
  Ограничения
  
  • Методика обучения не должна тематически серьёзно отличаться от ГОСа.

  Теория информационных процессов и систем
  Основные задачи теории систем; краткая историческая справка; терминология теории систем; понятие информационной системы; системный анализ; качественные и количественные методы описания информационных систем; кибернетический подход; динамическое описание информационных систем; каноническое представление информационной системы; агрегатное описание информационных систем. Операторы входов и выходов; принципы минимальности информационных связей агрегатов; агрегат как случайный процесс; информация и управление. Модели информационных систем; синтез и декомпозиция информационных систем; информационные модели принятия решений; возможность использования общей теории систем в практике проектирования информационных систем.
  

  • Методика обучения должна позволять обучение студентам, закончившим 2 курса технического вуза.
  • Методика обучения должна позволять достижение целей обучения за 1 семестр и 72 часа занятий.
  • Методика должна позволять обучение не более 30 человек/семестр.
  • Использование методики не должно предполагать закупку нового оборудования или ПО сверх имеющегося фонда.
  • Методика базируется на структурно-функциональном анализе (IDEF0,DFD,IDEF1x)
  
  Хочу напомнить еще, что многие недостижимы, поскольку всегда есть фактор нежелания учится самостоятельно. А между тем самостоятельная составляющая 60% от общего т.е где-то 94 часа.
  Кроме того, методика должна базироваться на последовательности лабораторных работ, т.к. курсовой не предусмотрено.
  Еще все-таки обратите внимание на теоретический характер дисциплины
  Кроме того давайте решать задачу поэтапно. Сначала сделаем нечто, что подойдет для меня, а дальше развернем как самостоятельный ресурс.
  
  Поскольку системный анализ - это все-таки набор процедур, методов и методик, то надо определится с набором их касаемо специалистов в области ИС. На мой взгляд - первое на что нужно обращать внимание в моем случае - сбор требований и формирование модели данных, либо просто привить навыки сбора требований:
  
  • сбор первичной информации
    работа с документами
    описание функциональных требований
    описание информационных потоков