Да, правильно, нельзя все сваливать на Студентов, сами виноваты, если не можем выстроить доступный процесс обучения...

Отлично, давайте попытаемся создать план обучения и контрольные вопросы.
За основу возьмем IDEF0?! Хотя я его плоховато знаю, но если что поправите ....

Как сказал Boatman, логично выделить следующие фазы обучения:
1. Определение и постановка целей. Критерии и ограничения.
2. Рассмотрение и выделение слоев абстракции. Декомпозиция.
3. Определение состава Системы.
4. Определение структуры Системы. Связи.

Чего-то явно не хватает.

Продолжение следует ....

Спасибо, Boatman, за интерес к теме.
Вы довольно много высказали критики и в мой адрес. Совершенно согласен. Но..., безусловно все начинается с цели. Это основа. Просто я, описывая проблему, изначально полагал это. Конечно все зависит от точки зрения и цели. Один и тотже автомобиль будет описан разными людьми по-разному, исходя из их цели. Принцип конечной цели - это центральный принцип системного анализа. Кстати в иностранной литературе часто ставится знак равенство между системным анализом и системным подходом.

Отлично понимаю, что наиболее управляемое действие - это развитие предмета, подгонка его под нужды, разработка методики. Проблема даже не в студентах или предмете, проблема в методике преподавания. Подчеркиваю я пытался использовать разные подходы, анализировал их, но пока вижу, что серьезных успехов нет. Что я вижу в успехе? Это когда средний студент, сможет провести довольно грамотный анализ, а главное еще будет понимать, что он сделал. Идеальная ситуация, преподавать группе из 5-6 человек не более. Однако это не выполнимо.
Потому нужна стратегия и тактика, а также методика. Потому и обратился. Вижу результат есть - и это очень хорошо.

Для начала нужно определить цель дисциплины как таковой:
Теория информационных процессов и систем, содержания ГОС 230201:

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

Его содержание мне не нравится, не наше оно. Это калька с ГОС ориентированного впервую очередь на ИСУ - и основан на ГОС Бауманки И ЛЭИ

Однако содеражание теоретического курса в нашем случае не так важно. Я его меняю процентов на 30 ежегодно: узнаю новое, появляется новая литература, новое понимание и т.д.

Что есть в содержании практикума:
1. Постановка задачи (выдается небольшое задание на моделирование и предлагается составить общее описание системы или проблемы, приветствуется дополнительный сбор информации: опрос пользователей, изучение аналогов, составление вопросников и опрос заказчика - т.е. преподавателя в нашей ситуации - уже здесь видна проблема - проблема времени, если реально общаться с каждой парой студентов (8-9 пар на преподавателя) то очевидны проблемы времени и качества ответа)
На этой стадии выясняется цель изучаемой системы, ее назначение, круг пользователей, заинтересованных лиц, обязанности пользователей, их потребности в самом общем виде, выделяются функции системы, определяется состав документов, форм, отчетов. Система изучается как есть либо как должно быть. Определяется цель моделирования, выделяются точки зрения, структуризируются точки зрения, выделяется наиболее значимая. Определяются границы моделирования и самые общие ограничения. Основной инструмент на данном этапе - здравый смысл, знания математической логики, теории множеств, отношений и т.п.
Представляются примеры проведения опросов, анализа информации по репрезентативной выборке документов и т.п.
2. Начальный этап моделирования - использую IDEF0, но может и вообще отойду от него, используется IDEF3.
Строится контекст и диаграмма нулевого уровня, выявляются взаимосвязи, точно определяется что на выходе, что на входе, что управление а что механизм. Итерационно связана с 1 задачей. Основная цель - выделение подсистем, определение закона функционирования
3. Детальный этап моделирование - разделение по подсистемам и переход к DFD, рассмотрение и структуризация потоков данных, алгоритмов обработки данных, ведения словаря данных, составление миниспецификаций процессов в самом общем виде - результат функциональные требования, понимание структуры данных, бизнес-правила
4. Моделирование данных - основанное на документах либо перенос из DFD модели (здесь пока не ограничиваю)
5. Трансформация модели данных в Access с целью посмотреть получается нормально или нет - то есть быстрое прототипирование

Естественно никакой водопадности не накладывается, приветсвуется итерационность, разделение обязанностей внутри пары, а иногда и четверки и шестерки...

Примеры заданий:
Пример 1

   Процесс заказов состоит в следующем:
•   потенциальный покупатель обращается к системе электронных заказов;
•   используя тематический каталог, он осуществляет поиск и выбор в корзину заказов интересующих его изданий,
•   затем покупатель определяет способ доставки и оплаты заказа, вводит необходимую информацию о себе;
•   система присваивает заказу уникальный номер и высылает покупателю извещение с информацией о заказе: ФИО,  адрес, детали заказа, общая стоимость заказа;
•   покупатель должен в установленный срок подтвердить сделанный заказ, в противном случае заказ аннулируется;
•   после подтверждения заказа покупателем система высылает сообщение о начале выполнения заказа.
Менеджер заказов осуществляет
•   ведение тематического каталога,
•   составляет ежедневные отчеты о сделанных и выполненных заказах,
•   анализирует информацию о наиболее популярных книгах и книгах, пользующихся малым спросом,
•   следит за новыми изданиями, 
•   оформляет заказы на поставку книг.

Пример2

Домоуправление (Д/У) осуществляет контроль состояния и обслуживание принадлежащего ему жилого фонда. Д/У выполняет заявки жильцов на текущий и экстренный ремонт квартир. Д/У регистрирует проживающих и вновь прибывших в домовых книгах, где указывается адрес дома, номер и площадь квартиры,  проживающие на данной площади (ФИО и дата рождения), дата регистрации. Д/У ежемесячно начисляет квартирную плату.  Д/У ведет паспорт на каждую единицу жилого фонда, где указан адрес дома, дата ввода в эксплуатацию, тип строения, этажность, тип перекрытий, тип кровли, тип системы отопления, тип квартир, число квартир каждого типа. Д/У также проводит плановый и капитальный ремонт жилого фонда.
 Должностные обязанности штатных сотрудников:
•   Начальник Д/У осуществляет общее руководство деятельностью Д/У;
•   Главный инженер отвечает за техническое состояние жилого фонда – руководит текущими и капитальными ремонтами, входит в состав комиссии по приему новых домов на баланс Д/У;
•   Заместитель начальника Д/У по жилью ведет паспорт на каждый дом, регистрирует новые единицы жилого фонда и составляет план капитального ремонта домов, срок эксплуатации которых превысил нормативный;
•   Паспортист осуществляет регистрацию жильцов и ведет домовые книги;
•   Бухгалтерия начисляет квартирную плату в зависимости от площади и числа проживающих в квартире;
•   Диспетчер принимает заявки от жильцов, выполняет ежедневное распределение бригад на работы в соответствии с поступившими  заявками;
•   Бригады рабочих различных специальностей – слесарей, сантехников, строителей, электриков, которыми руководят бригадиры.

Пробывал и такие варианты - на 3 человека или даже 3 пары в зависимости от величины группы

Вариант 1. Учет наличия и движения товаров в торговой организации.
В процессе учета участвуют специалисты следующих подразделений: склада, бухгалтерии, группы маркетинга, торгового зала. Товары подразделяются на товарные группы (бытовая техника, обувь, одежда, электроника и т.д.). Внутри группы товары отличаются наименованием, маркой, производителем, поставщиком и т.д.
1.1      Модуль «Учет движения товаров на складе».
Программное обеспечение АРМ кладовщика должно позволять -
1) хранить необходимую информацию о каждом виде товара, имеющегося на складе; хранить справочник нормативов запаса товаров по каждой группе товара;
2) выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  данных о заданном товаре по его номенклатурному номеру;
-   выборка всех данных о товарах с сортировкой  по товарным группам;
-   выборка номенклатурного номера и наименования товаров, количество которых на складе меньше заданной нормы запаса;
-   расчет суммарной стоимости товаров, принятых и отпущенных за текущий день;
-   расчет стоимости товаров, отпущенных по заданной расходной накладной;
-   диаграмма - стоимость товаров с группировкой по товарным группам;
3) автоматизировать обработку информации при следующих бизнес-операциях:
1)   прием товара от поставщиков (ввод данных приходной накладной);
2)   выдача товара в торговый зал (ввод данных о расходе и оформление расходной накладной),
3)   списание товара  (ввод данных о списании и оформление  акта о списании);
4)   переоценка товара (ввод данных о новой цене заданного товара, групповое изменение цены с заданным коэффициентом),
5)   передача устаревших документов в архив (накладные и акты за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);
4) вывод выходных документов на печать (расходная накладная, карточка складского учета, акт о списании);
5) вывод сведений об авторе и назначении программы.

1.2      Модуль «Работа с товарами и покупателями в торговом зале»
Служащие торгового зала выписывают счет на покупку, товарный чек (накладную), ведут книгу продаж. Отпуск товаров покупателям ведется только через торговый зал.
ПО АРМ продавца должно позволять -
1)   хранить необходимую информацию о каждом виде товара, имеющегося в каждом  отделе торгового зала;  информацию о распределении продавцов по отделам;
2)   выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  сведений о продаже заданного товара по номеру товарного чека;
-   выборка названия, цены и рекламных сведений о товарах, с сортировкой по   фирмам - производителям;
-   выборка данных о покупках заданного клиента по фамилии (названию фирмы) покупателя;
-   вывод списка покупателей в алфавитном порядке;
-   расчет суммарной стоимости товаров, отпущенных данному клиенту за год;
-   диаграмма - сумма продаж за заданный период времени с группировкой по товарным группам;
3) автоматизировать обработку информации при следующих бизнес-операциях:
   прием товара со склада (ввод данных накладной);
   продажа товара покупателю (ввод данных о расходе, оформление товарного чека; оформление требования на склад, если данный товар в зале закончился),
   оформление витрин торгового зала с помощью ценников и рекламных листовок;
   передача устаревших документов в архив (записи в книге продаж за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);
4) вывод выходных документов на печать (товарный чек, ценник, рекламный листок, требование);
5) вывод сведений об авторе и назначении программы.

1.3      Модуль «Работа с поставщиками и анализ продаж в группе маркетинга»
Маркетологи еженедельно анализируют сбыт товаров,  формируют прайс-листы, поддерживают контакты с поставщиками, информируют торговый зал и кладовщика об изменении цен на товары.
ПО АРМ маркетолога должно позволять -
1)   хранить необходимую информацию о каждом виде продаваемого товара; информацию о фирмах – оптовых поставщиках товаров;
2)   выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  сведений о заданном поставщике по его названию или ИНН;
-   выборка названия и цены товаров, отсортированные по городам и поставщикам;
-   выборка данных о поставках заданного поставщика по его ИНН;
-   расчет суммарной стоимости продаж с группировкой по неделям (месяцам) и поставщикам (перекрестный);
-   расчет количества продаж каждого вида товаров за заданный период (от …до…);
-   определение 10 самых ходовых товаров (количество их продаж максимально);
3) автоматизировать обработку информации при следующих бизнес-операциях:
   переоценка товаров (изменение цены заданного товара, изменение цены на группу товаров,  формирование нового прайс-листа);
   анализ сбыта товаров (формирование еженедельной ведомости продаж с группировкой по товарам и их группам, построение диаграммы продаж или диаграммы цена\спрос),
   установление деловых контактов с новым поставщиком (ввод данных о поставщике и его товарах);
   разрыв контактов с заданным поставщиком (удаление сведений о заданном поставщике);
4) выводить выходные документы на печать (прайс-листы по группам товаров, ведомость продаж;  диаграмма продаж, перекрестный);
5) выводить сведения об авторе и назначении программы.

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

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

Понимаешь, тема в приниципе не важна. Обычно все варианты лежат на поверхности: торговля, простое сборочное производство из комплектующих, что-то связанное с вузами: отдел кадров, ведение зарплаты, и т.п.
В целом я бы не сказал, что студенты не понимают своих заданий. Они порой увлеченно дискутируют, однако результат я оцениваю уже на дипломе, т.е. спустя 2 года на защитах курсовых и дипломов. И вот тут видно - бааааальшие проблемы.
В чем тут проблема, только ли в студентах или преподавании. На 4 курсе уних есть предмет проектирование ИС, веду не я:-) Их там заставляют делать DFD по Вендрову. Вендрова знаю лично. Человек интересный, но практикум у него так себе.
Ну да ладно я отвлекся.

Думаю надо сделать так:
1 занятие. Уяснение задания. Выработка цели, построение иерархии целей и задач.
Например:

3) автоматизировать обработку информации при следующих бизнес-операциях:
1)   прием товара от поставщиков (ввод данных приходной накладной);
2)   выдача товара в торговый зал (ввод данных о расходе и оформление расходной накладной),
3)   списание товара  (ввод данных о списании и оформление  акта о списании);
4)   переоценка товара (ввод данных о новой цене заданного товара, групповое изменение цены с заданным коэффициентом),
5)   передача устаревших документов в архив (накладные и акты за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);

Цель - учет движения товаров на складе
задачи: прием товаров
            выдача товаров в торговлю
            списание товаров
            переоценка товаров
            архивирование устаревших документов
Кажется все ясно?
Цель моделирования: установить общую логику работы кладовщика, разработать требования к системе, определить бизнес-правила и модель данных.

помимо этого стоит подумать над структурой документов: накладных, форм отчетов и т.п. Студенту предлагается сделать их самостоятельно по аналогии и в упрощенной форме

На базе этого этапа, можно потребовать разработать скажем контекст для ПРиема товаров, или даже провести требуемую декомпозицию с использованием IDEF0 и IDEF3

продолжение следует

Можно построить модель БО

1) Кто является заказчиком исследования?
думаю в данной ситуации заказчик - это преподаватель. Иначе - это может быть некая организация желающая построить простую систему учета запасов.

2) Каковы его цели?
Если преподаватель  - дать навык описания анализа системы и требований к системе, научить строить модель данных по документам и/или на базе функционального анализа DFD

3) Каковы собственные цели исследователя?
Сформулировать функциональные требования к системе, определить бизнес-правила и ограничения, построить модель данных

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

5) Кто будет потребителем решения, каковы его цели и ограничения?
В данном случае конечно преподаватель, но реально кладовщик все ограничения цели сформулированы в задании, смотри выше пост

Предложите свои ответы?

Отличное дополнение, мне нравится. Однажды я пытался ввести нечто подобное, однако студенты так долго придумывали кто же они, и для кого делают, что решил упростить - убрать.

Тут надо оговорится. Поскольку пока мы ориентированы на структурные методы, то ничего подобного для них я в свое время не обнаружил. Однако начав изучать RUP, вычленил из него ряд интересных документов несколько адаптировав их для решения.

В частности - первые несколько занятий  студентам предлагалось заполнить документ типа Target Assessment.

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

Есть еще предложение перенести ведение проекта в Hydra компонент. Поскольку пока заинтересованный человек один, кроме меня, то мы могли бы поработать в более комфортной системе.
Я могу создать группу Teaching и включить туда тебя и меня для начала. Для группы создам проект - Формирование методики преподавания основ системного анализа и будем по-тихоньку его делать. Правила использования постараюсь описать на фронтэнде.
Но вкратце. Пользователь может иметь 4 возможные роли - заказчик, участник, лидер и администратор. Роль пользователя единая. Т.е. пользователь может входит во многие проекты и группы, но всегда с одной и той же ролью.
Я думаю роль лидера тебя вполне устроит, я по умолчанию администратор - ну поскольку внедрил компонент и управляю системой в целом. Можно пригласить в проект других пользователей на правах участников или заказчиков. Но думаю пока обойдемся.
Кроме того можно установить бот, который позволяет сделать в контенте проекта ссылку на форум, в статьях это получается, то не пробывал в HYdra. В общем хочешь не хочешь, проект я запущу, заодно потренируемся.
В проекте можно создавать задачи, события, документы и загружать файлы. Файлы будут загружаться в папку projects - то есть url http://www.uml2.ru/projects. Т.е. можно закачивать туда рисунки или модельки и цеплять в текстах документов обычным способом...

согласен
сделал папку teachers туда тебя поместил как лидера - проект говорит сам за себя

Как насчёт того, чтобы переименовать тему во что-то более содержательное, например "Методика преподавания структурного-функционального анализа"?

Думаю не переименовать, а создать новую,
Думаю ее можно будет приатачить к проекту Методика СА - пока там два пользователя я  boatman

Итак. Нужно зарегистрироваться на сайте. Должно появится меню пользователя. В нем выбираем пункт Мои проекты. Должно загрузится окно Hydra manager, там должны быть видны доступные проекты и задачи - в первую очередь задачи.
Наша 1 задача Формулировка задания...

Приветствую тебя, Зоркий глаз. Очень рад.

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

Золотые слова, дай я тебя расцалую :-) Именно через подобные вопросы и барьеры, я и пролазил все эти 5, а нет 6 лет преподавания. Как с одной стороны дать не очень сложное задание в целом (а выставленное задание, надо сказать, в этом виде я не использовал), а с дургой стороны заставить студентов задавать вопросы!
Ничего не получилось, вопросы обычно задаю я,и часто не получаю ответов. Да я пробывал остановится только на образовательной сфере, но скучно и тоже предметная область не известна. Я давал задания по вузу : работа приемной комиссии, отдела кадров, деканата, ПФО и некоторые другие, говорил студентам ходить и узнавать дополнительные моменты, но воз и ныне там. Ну не хотят они напрягаться.

- брать те процессы, которые они знают хорошо или могут узнать хорошо самостоятельно.

Я уже замучался поиском этих процессов. Вообще я выставляю много вариантов - около 20 -30, выбор есть. Либо может взять одни процесс и поменять в нем только вводные - но это будет профонация 100%. Умные сделают, лентяи у них просто сдуют с удовольствием получив свои три балла.

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

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

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

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

И еще есть вопрос: что должно быть в результате задания: программные модули, артефакты, документация еще что-то?

Формально должны получится артефакты: описание объекта обследования в целом, функциональные требования в  виде описания и набора диаграмм, бизнес-правила и модель данных, рекомендации по реализации: архитерктурное решение, на чем мол делать будем и т.п. (очень кратко и сжато) Главное - это фактически требования на разработку проектного решения, формирование концепции..

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

пусть некий закон функционирования объекта управления или просто управляющая функция описывается этим уравнением. Меняются парамерты a, b и с. Требуется рассчитать воздействие для заданного х, или наоборо подобрать такое х, которое отвечает заданным параметрам.
Тогда вероятна понятна цель, а уравнение - есть средство ее достижения.
Конечно можно расписать модель решения, но зачем же из пушкой по воробьям.
Достаточно будет и блок-схемы или графа.
Думаю все-таки надо брать более реальные примеры: например обработать результаты эксперимента, или решить задачу оптимизации

Окей попробую.
Пусть функционирование системы описывается уравнением a*x^2+b*x+c=0
уравнение детерминирвано при определенных a b c. Если a b c известны - решение известно заранее, если a b c изменяемые параметры системы, то ответ заренее не известен, но он определен при фиксировании a b c. Данная задача конечно не имеет практического применения.
Интереснее задача y=a*x^2+b*x+c, где х - есть входная эндогенная переменная, а у - наблдение или экзогенная переменная. Тогда суть решения есть подбор параметров a b c если между x и y есть корреляция, описываемая квадратным уравнением или полиномом 2 степени.

Пусть будет такой этюдик - но чему он может научить? Не очень понятно...

Думаю проблему методики надо решать с использованием системного анализа.
Основной принцип, которого - принцип конечно цели. В чем цель предмета? Научить системному анализу? Научить методам описания систем? Научить решать задачи?
Я подумаю и попытаюсь с формулировать все довольно четко.
Однако уже сейчас я вижу:
1. дать основы системного анализа и приемы его использования для описания информационных процессов и систем
2. дать навык использования инструментальных средств
3. научить приемам формализации поставленной задачи и формирования требований

Что значит дать основы? Здесь и теоретический материал, он вполне очевидный, хотя критичныим является содержание того, что дается. К основам можно отнести:
1.определения и терминология, в первую очередь понятия системы
2.назначение СА и его структура. Структура довольно интересная, но к сожалению элементы этой структуры разобраны в литературе не достаточно ясно...
3. принципы системного анализа и закономерности систем

Это теоретический базис, дальше идет скорее всего эмпирические знания, поскольку все эти IDEF, DFD, UML - есть не что иное как эмпирика. Инженерная адаптация общей теории систем и специальных разделов математики к практике. Сегодня UML, а завтра нечто иное...Но основы теоретические должны остаться.

Кого мы готовим, я все 6 лет мучаюсь над этим вопросом. И вот к чему пришел. Мы готовим технолога. А что есть технология - наука о методах тго, как воплотить идею в практику.

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

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

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

Что же я могу понять? Да то, что любая ИС отвечает определенным требованиям: ввод, хранение и предоставление информации,отсюда и надо идти...

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

Я всегда студентов ставлю на свое место.

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

Ничего я не знал ни о реляционных БД, не об ООП, ни о 1С. СА - что это такое?
Все что у меня было - желание и здравый рассудок. За неделю я изучил (так мне казалось тогда) приницпы создания БД, используя в качестве примеров - образцы БД в MS Access 1995, ком 486 процессор 16 метров оперативки. Еще неделя ушла на определения инфологической модели данных. Мне почему-то тогда казалось это краеугольным во всем проекте, самое интересное, что так и оказалось. Далее пошли формочки и алгоритмы обработки. Первый вариант был готов после первого месяца о заказа и система сразу была внедрена. После эксплуатации ее в течение 3 лет, я многое изменил в интерфейсе, но практически мало в структуре данных. Более того это решение я растиражировал еще на два проекта. Все работают замечательно, мое вмешательство минимально. Уже позже изучив теорию систем, теорию РБД и прочие мудые науки, я с удивлением заметил, что довольно правильно использовал все. Вопрос, почему я не имею крупицы знаний смог, а студент, имеющий довольно много базовых знаний теряется? ИМХО, потому, что воспринимает это как учебная рутина раз, мотива нет два. Как всеэто изменить? Ответа нет...

Потому весь этот проект - думаю есть возможность систематизировать знания, выработать некую стратегию и тактику преподавания в целом. Систематизация, технологичность всегда приносила повышение производительности. Вспомним Форда.

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