Денис, надо надо.
Спасибо за ссылки, это все я, как говорил, видел раньше, просто не доходило все это почитать. А имел я  в виду то обстоятельство, что теоретические концепции много раз публиковались и много раз читались и не только на интутите. А вот нормальных практических примеров, разобранных от и до, без купюр практически нет. Чаще всего бывает великолепное начало, а потом раз и все быстренько сворачивается, а потом как чертик из табакерки вылезает решение. Опытный читатель, конечно, догадается, но накой опытному это все читать?

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

В качестве бредовой идеи: может тогда давать задание не на исследование, а на  построение бизнеса

В какой-то степени именно такие примерно задачи и ставились. Фактически придумать бизнес при некоторых условных ограничениях и упрощениях. Разработать документы, посмотреть аналоги, создать свое работающее решение. А модель данных как некоторый инструмент проверки - в том направлении двигаемся или нет?

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

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

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

1. Системный анализ = моделирование до некоторой степени. А может и полное тождество в нашем случае. Моделирование - это процесс построения модели М для реального объекта исследование S с точностью А. Думаю точность определяется целями моделирования, т.е. что мы хотим от этого процесса. В нашем конкретном случае мы хотим фактически автоматизировать ввод, хранение и предоставление информации от поступлении на склад  и изъятии книг со склада. Важной составляющей является информационные потоки или потоки документов, которые должны быть созданы в процессе или которые будут использоваться в процессе. Мы определяем в начале, что же мы хотим знать:
1/ общее количество книг на текущий момент
2/ количесвто книг поступивших в период времени
3/ количесвто книг по категориям
4/ количество книг по названи
5/ цену покупки книги
6/ место где она хранится
7/ остатки
8/ кто поставщик или издательство
Для решения этой задачи безусловно нужно рассматривать как поступление, так и изъятие. В реальной практике - это может быть сложный и многоаспектный процесс, однако в нашем случае - мы можем абстрагироваться от деталей и упростить ситуацию до простейшего поступления книги или партии книг и их изъятия куда-то, куда не важно - мы просто фиксируем два основных факта: приход книги - уход книги.
наша задача отобразить эти факты в нашей системе, системе учета прихода-расхода.
При описании процесса мы можем дать волю фантазии, а можем особо не задумываться о том, как каким образом узнается, определяется скажем место положение конкретной книги, ее идентификатор и т.п. С другой стороны, это кажется важным как происходит присваивание новым поступлениям номенклатурного номера и определяется место хранение. Формируется ли это после ввода в документ системы, где система автоматически назначает соотвествующий номер и определяет место хранения (ящик, полка, стойка, стеллаж) - однако нас пока не интересует факт реализации, мы можем просто констатировать, что
при вводе нового товара ему присваивается некий новый номер
при вводе товара следует указать место его хранения
номер определяет всю поставку (20 книг в упакове - одного и тогоже автора и названия) или можем потребовать чтобы каждая книга имела свой номенклатурный номер.
Т.е. мы должны определить бизнес-правила того как формируется документ.

2. Если рассматривать бизнес-процесс как есть, с целью его модификации и улучшения - согласен это другая задача, никакого отношения к последующему проектированию явно не имеющего, но служащая основанием, конечно, определяющая контекст

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

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

Конечно, проблема в том. что мы изучаем гипотетические задачи, пусть во многом аналогичные имеющимся...

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

Что-то у нас частенько меняется цель и направление движения. Сейчас у нас их несколько:- Разработать методику...- Разобрать практический пример...- Автоматизировать...и т.д.

Да нет, мы просто уже потеряли канву исходного посыла. Пост назывался "Крик души" - я изложил проблемы и попытался получить помощь в из преодолении. В ходе дискуссии возникла идея разработать методику преподавания. Денис предложил назвать нашу тему так как она сейчас и называется, видимо под впечателением инструментов,которые я использую.
Могу сказать, что я готов отказаться от всех этих инструментов одномоментно, однако к этому не готовы наши преподаватели на высших курсах. Здесь тонкость является в том, что я не могу отвечать за других, но вынужден учитывать их наработки. Т.е. если я к примеру полностью перейду на UML, а мои коллеги будут настаивать на использовании DFD, то получается довольна забавная ситуация. Надеюсь все-таки мы прийдем к некотрому знаменателю. Однако на мой взгляд, все используемые инструменты - просто инструменты, удобные или нет, кроме того, как кажется нужно дать общий багаж знаний. Ведь то, что классическая механика  не отражает реалии мира полностью, не означает, что мы ее должны отбросить и начать изучать только квантовую механику.

В посте, где я насчитал 7 тем я решил, что это он и есть (там выше ).

Не сочти за труд - опубликуй и выдели красным цветом:-))

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

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

Давай определимся среди вариантов:1. Речь идет об отношениях юридических лиц: поставщика и покупателя 2. Речь идет о двух юридических лицах: фирма и транспортная компания3. Речь идет о трех подразделениях одной организации: оптовый склад, транспортное подразделение, другой склад (склад магазина?)Так как я сейчас играю роль задающего вопросы, то отвечаешь на них ты. Выбирай вариант или предлагай иное...

Любое предположение может быть нормальным. Просто надо выбрать. Вот скажем если студент задаст мне все эти три вопроса, то я буду удовлетворен, но он не задаст
Я думаю для простоты можно зафиксировать торговое предприятие - поставщик, причем с учетом, что торговое предприятие и само может поставлять товар (т.е. самовывоз)

Это суть работы аналитика. Если не привить эти навыки, моделирование и прочие радости даже не игрушки, а веселые картинки.

Но ведь аналитик- аналитику рознь. Один анализирует бизнес-процессы, другой анализирует уже описание этих процессов, при чем проектировщик БД - одно выискивает, интерфейсник другое, тестер третье, архитектор четвертое.
Я все-таки склонен сделать упор на проектировщика БД, но надо дать и ретроспективу.

Я чувствую, что в самом названии уже корень непонимания. Мы говорим о разных вещах. И я извиняюсь за то, что невнимательно читаю.

Давай отвяжемся от этого. Идем от СА применительно к построению систем. Обычно строят
функциональные модели - в качестве инструмента может выступать IDEF0 IDEF3, причем эти методологии более ориентированы на материальные системы
структурные модели - Idef1x ERD и некоторые другие, кто-то относит сюда и DFD
Поведенческие модели - модели поведения STD, конечные автоматы, но ведь и DFD
Архитектурные модели - тут можно использвать DFD вероятно что-то еще...
Я не замахиваюсь на весь цикл.
СФА - помоему показывает приоритет функции над структурой, какие функции реализуем такая и структура, а не наоборот, подгонка функций под структуру.

если следовать понятию Бизнес-модели: то диаграмма прецедентов - внешнее представление системы, модель бизнес-объектов - суть концептуальная ИЛМ, хотя и с поведением, но необязательно

Написано еще много чего. Но сейчас мой вопрос такой: действительно ли требуетсяметодика преподавания техник функционального моделирования и моделирования данных (IDEF, DFD) на примере построения OLTP приложения с клиент-серверной архитектурой для автоматизации бизнес-деятельности путем1. Моделирования бизнес-процессов и ER моделирования 2. Получения функциональных требований к системе (судя по всему требуется алгоритм вывода требований из ОБП и ERD я такого не знаю)3. Построения БД и создания клиентского приложения RAD средством MS Access (для верификации результата)

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

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

Сергей, кажется я понял предмет нашего разногласия и непонимания.

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

Я все-таки склонен сделать упор на проектировщика БД, но надо дать и ретроспективу.
...
Я ориентировался всегда на процесс создания БД.

Вот кстати очень интересно, почему? Ведь если почитать современных объективистов, то у них БД (а также, между прочим, шаблоны интерфейса, CSS, конфигурационные файлы и проч.) вообще в архитектуру ИС, а следовательно, как я понимаю, и в саму систему не входит! ) Т.е. Система общается с БД как со внешним техническим  сервисом через соотвествующий слой и всё тут )

Ваши слова кстати напоминают ещё особенность в понимании термина БД у представителей малого и иногда среднего и даже большого бизнеса - они, бывает, говорят "нам нужна БД того-то", а на самом деле им нужна ИС различного масштаба, т.е. не бывает не-IT-шных клиентов, которым была бы нужна система только хранения структурированной информации, без механизмов её обработки и интерфейса взаимодействия (Access всех развратил, кстати). Скорее всего это историческое наследие доминирования парадигмы баз данных как основной ценности при создании системы учёта чего бы то ни было. Нонешный же ОО-люд смотрит на них только как на чулан, который в принципе может быть реализован хоть на XML, хоть на плоских файлах, в зависимости от задачи.

Ваши слова кстати напоминают ещё особенность в понимании термина БД у представителей малого и иногда среднего и даже большого бизнеса - они, бывает, говорят "нам нужна БД того-то"

Да слов из песни не выкинешь. Но и буквально их понимать не стоит. Все-таки мы не говорим только о БД, мы больше говорим об инфологической модели, а это не только структура, но и бизнес-логика, не забывай. То что я написал, отражает мой ход мысли, но не совсем. Правда, это есть следствие моего жизненного опыта и изучения литературы к моменту собственно чтения курсов (ведь чтобы съездить на курсы повышения квалификации нужно либо мозолить глаза руководству, либо делать это за собственные деньги - а программа повышения квалификации нарушена сейчас). А тут стратегия такая, коли не знаешь, что давать, давай что-то полезное. А Базы данных еще долго будут полезными.

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

Кстати я опубликовал две темы, одна из них Теория информационных процессов и систем - прошу высказываться о наполнении предмета там.

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

Дружище Galogen! Не стоит воспринимать вопросы, как критику. Никто тебя не критикует: у тебя свои цели и критерии, мы пытаемся понять, чего же ты хочешь получить на выходе.

Спасибо дружище Boatman. Да я не принимаю понимаю, что это не критика:-) Это я так, просто с досады, что не могу донести до вас картину того, что у меня есть, в какой ситуации я нахожусь, и прочее. Я даже скажу более, будем считать - что я вообще круглый дилетант, так оно в общем и есть, поскольку варюсь-то я в своем соку.
Единственно, что все во мне против, так это такого вот скрупулезного анализа. Вернее я за него, но не через меру:-))

Цели уточняются - это хорошо. правильно ли я понимаю, что ты хочешь привить навыки применения SADT путем моделирования бизнес-системы в IDEF0,IDEF3 с переходом к DFD с переходом к IDEF1 и финальным получением физической схемы базы данных для верификации результата (в данном случае в MS Access)? Давай все таки напряжемся и сформулируем задачу парой фраз, к которым был бы трудно придраться и там было бы ровно то, что ты хочешь сделать.

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

Единственный упор я исторически делаю на модель данных, поскольку пришел к выводы, если я их этому не научу, больше никто никогда не научит. Такой факт.

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

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

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

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

Вот почитал методическое пособие, которое Денис опубликовал в файловом архиве (раздел Бизнес-моделирование). Можно сказать, что там описывается примерно то, что я хотел бы получить. Может только немного в более стилизованном виде, менее прагматичное и чуть абстрактнее.

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

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

Книготорговое предприятие "Пегас Лимитед" имеет небольшую сеть книжных магазинов, централизованное книжное хранилище и центральный офис. Отдел маркетинга фирмы, изучая спрос, отчеты продаж и общее состояние книжного рынка, осуществляет заказ книг, напрямую контактируя с издательствами или сотрудничая с поставщиками-дилерами. Доставка книг осуществялется только в книжное хранилище либо транспортом поставщика либо самовывозом, т.е. используется транспорт книготоргового предприятия. Распределение книг по магазинам осуществляется на основании заявки, поданной менеджером магазина.
Склад предприятие представляет собой хорошооборудованое погодозащищенное здание. Книги хранятся на стеллажах. Каждый стеллаж состоит из равного количества стоек, стойка имеет равное количество полок, на полке размещается 3 ящика, в каждом из которых размещается не более 100 книг или 5 упаковок.
Книги поставляются только упаковками по 20 штук в каждой.
Выдача книг в магазины учитывается поштучно.
Руководство предприятия обратилось в фирму разработки ПО с заказом на решение проблемы, связанной с несвоевременном получении информации о состоянии склада (остатков), сложности и долговременности получения отчетов о количестве книг поступивших за определенный период, их ассортиментном составе, какие книгу куда распределены (в какие магазины) и т.п.
Целью задания является разработка практического решения(моделей) для снятия проблемы связанной с книгооборотом на центральном складе предприятия....

Описание типичного процесса (работа склада).
Экспедитор Печкин поставщика "Простоквашино" в 9:30 приехал на грузовике на склад фирмы "Пегас лимитед". Он привез новые книги согласно договору между поставщиком и фирмой "Пегас лимитед". Печкин был большой приятель кладовщицы Аси и никогда не забывал привести какой-нибудь сюрприз. Вот и сейчас, увидав симпатичную кладовщицу Асю, но преподнес ей букет пышных хризантем. "С моего участка" - похвастался Печкин. Ася зарделась от смущения, но ей было очень приятно. Она чмокнула Печкина в щеку. Но дело, есть дело.
Печкин протянул Асе сопроводительные документы. Шустрый малый Вася-долговяз подскачил на каре и в два приема, быстро и сноровисто, разгрузил машину. Ася стала проверять соотвествие паковочных листов на упаковках записям в накладной поставщика. При этом они мило переговаривались с Печкиным. После утверждения очередной упаковки. Печкин ставил упаковку на конвеер и он скрывалась в утробе склада. Вскоре все книги были перемещены внутрь склада. Проблем не было. Хотя они и случались. Как-то раз сам Печкин, известный аккуратист и служака, попал в аварию и несколько упаковок с книгами пострадали. Пришлось составить акт возврата, а книги Печкин увез обратно. Дело есть дело....
Но в этот раз все было просто прекрасно. Ася подписала документы. Печкин еще немного поговорил и вскоре отбыл.
Ася же и ее помощницы ну и так далее.....

Вот два стиля, в каком направлении двигаться. Учтите, что мы сейчас ограничиваемся только учетом прихода книг на склад и уходом со склада....

Читал-читал и расстроился. Американцы (Дэвид А. Марка и Клемент МакГоуэн) много думали над методикой преподавания SADT (AKA IDEF0) и придумали. См. книжку: Дэвид А. Марка и Клемент МакГоуэн. МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ SADT. — М.: Интерфейс, 2000. Перевод выполнен Марией Каменновой, перевод очень качественный. Книжка, конечно, сосредоточена не столько на синтаксисе IDEF0, а именно на методологии. В частности, описаны особенности проведения интервбю аналитика с экспертом (сотрудником заказчика).

В этой книжке есть указания для преподавателя и методика, рассчитанная на 25 часовых занятий, выполняющихся за 5 дней. Группа обучаемых – до 20 чел. Я использую эту методику 5 лет, обучил 8 групп (в основном, специальности прикладная информатика). На курс уходит, конечно, не 25 часов, а, как минимум, 32 аудиторных часа + примерно 20 часов студенты работают самостоятельно по заданиям. Конечно, в группе, которая больше 15 человек, всегда найдутся лодыри, но 2/3 группы активно работают.

Если интересно – пишите, адрес есть на моём сайте (www.vak.nw.ru, там, правда, мало что толкового есть ).

Спасибо, Виктор, за интерес к теме.
Есть у меня эта книга даже выложена на сайт. Действительно все там написано замечательно и частично я ее использую в курсе преподавания. Однако все равно проблемы есть.
1. Проблема ретроспективы методов IDEF0 IDEF3 DFD IDEF1x
2. Проблема постановки задачи для студентов, т.е. порой нет проблемы в рисовании графических образов, назывании стрелок и блоков, ведения описаний и т.п. С этим большинство справляется, Единицы - которые тупят по страшному. Однако все утыкается именно в эту проблему - проблема задач.

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

За помощь спасибо

Сергей, по поводу методики преподавания.
Виктор Андреевич действительно указал нам на очевидный факт, книгу Марка и МакГоуэна.
И в частной беседе рассказал мне о возможном подходе - реализации деловой игры: Эксперт -Аналитик-Наблюдатель.
Для начала посмотри пожалуйста вот в этом направлении: http://www.isuct.ru/~ivt/books/CASE/case8/sadt/p5.htm
Дополнительно мне было все-таки хотелось сделать акцент на методологи DFD, насчет IDEF1x вопрос открытый. Однако мотивы ты знаешь...

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

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

2. Исходное задание должно содержать четко определенную проблему.

3. исходное задание следует описать как некоторый case или историю. Совсем не обязательно делать ее очень короткую, контекст будет определять заданная проблема. Т.е. в идеале можно сформулировать 1 задачу, и поставить 16 проблем к ним.

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

5. Я готовлю специалистов в области ИС и ИТ. Бизнес-понятия все-таки даются контекстуально и наиболее обще

6. Следует дать навыки текстового разбора задания (на пример как нам показал Boatman) или как показано в книге Марка и МакГоуэна

7. Следует научить задавать вопросы и видеть недостающую информацию(факт ее отсутсвия для грамотного принятия  решения о  структуре и алгоритме)

8. Привить навык интервьюирования, наблюдения (деловая игра)

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

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

Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры. 

В состав компании входят: отдел продаж и маркетинга, производственный отдел и склад. 

Отдел продаж и маркетинга занимается приемом заказов от клиентов, устройством презентаций и выставок, рекламой.

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

Кладовщик отгружает клиентам заказы.

 Здрасте. А у меня вопрос на засыпку: как выглядит в IDEF  процесс работы интернет-магазина??