Форум Сообщества Аналитиков
Дисциплины => Обучение => Тема начата: Galogen от 27 Ноября 2006, 14:54:48
-
На протяжении 6 лет я преподаю в одном университете предмет, связанный с изучением теориетических основ информационых процессов и систем. Задача предмета состоит в том, чтобы научить студентов производить формальное описание систем, проводить декомпозицию систем с целью снятия сложности, формализовать предметную область.
Результатом практических занятий является построение функциональных, структурных и инфологических моделей системы.
На первом этапе используются структурные методы IDEF0, IDEF3, DFD, Idef1x.
Студенты должны научится создавать формализованное описание системы, выделять ее из окружения, научится декомпозировать ее, описывать законы функционирования и как результат формировать функциональные требования к системе.
Для общего понимания в конце проекта предлагается сгенерировать БД в MS Access.
В качестве исходного задания предлагаются различные системы с подробным но неформализованным описанием процессов в ней.
В качестве примера: работа отдела кадров вуза, работа приемной комиссии, интернет-магазин,
склад, производство, кадровое агентство, риэлтерская контора, и т.п.
Задания составлены так, чтобы студент смог понять общую картину, либо стимулировать его на задание дополнительных вопросов с целью выяснение деталей и подробностей.
Однако я столкнулся с проблемой того, что в итоге даже очень продвинутые студенты практически не справляются с заданием полностью.
Основные проблемы - слабая логика, непонимание для чего это нужно, несерьезное отношение к синтаксису и семантики используемых методологий.
Пробывал разные подходы к объяснению материала:
1.Ничего кроме лекций не объяснял, давал полную творческую свободу. Главное, чтобы было логично и понятно.
2. Сначала показывал пример использования, подробно разбирал этапы, предложил шаблон моделирования и создания описания. В результате - либо бездумное копирование
описания с небольшими изменениями в семантике системы, либо такое напридумывают, что хоть стой хоть падай.
3. Создал жесткое описание, с четко выделенными ограничениями, описанием основных процессов и списка функций. Большинство не может выдержать ограничений, все равно пытаются чего-то нафантазировать
4. Сделал симбиоз строго описание и возможности пофантазировать.
Сравнение не очень показательное, так как каждый год разные студенты. Одни умнее, другие слабее. Однако в целом одно замечано - никто не читает дополнительную литературу, а ее у меня хоть отбавляй...
Совершенно не развита логика мышление, пониятие о диалектике вооще отсутствует, критического подхода практически ни у кого нет.
Я тут подумал, может как-то преподаю не правильно, может слишком сложно даю предмет, и многое от них хочу? Может надо как-то по другому пойти?
Да понимаю предмет сложен, слишком многое зависит от контекста, нет четких критериев как в математике той же.
Поделитесь опытом, как преподаете Вы, или как преподавали Вам и вы считаете, что владеете предметом....
-
Мдааааа, труден предмет сей.....
Я сам изучал несколько лет и только после лет двух начал что-то хоть понимать. Тут как говорится только влезь, а открывались все новые и новые горизонты.
За один семестр научить невозможно этому. Надо как минимум два, первая теория с небольшими примерами/ДЗ, а второй только курсач. Да и то не факт. Да и студент нынче ленив. Многим это и не нужно. Когда преподают на курсах, то внемлишь каждому слову, а тут сделал и ладно. А м.б. не принимать заведомо скопированное или не правильно сделанное ДЗ, несколько лет помучаешься, а потом пойдет слух про твой предмет и все начнут более аккуратно к нему относится. И примеров побольше на семинарах, и чтобы кто-то что-то делал, а Вы потом разбирали всей группой ошибки и т.д.
Кстати, а почему сразу не ЮМЛ???? Потом трудно от структурного к объектному перейти. Лучше что-то одно, и конечно ЮМЛ.
З.Ы. А так, учить кого-то - это не мой профиль....
-
А я до сих пор студент, поэтому может помогу прочувствовать всю проблему.
Вы не пытались заменить БД в MS Access на что-то подобное но более актуальное, например Delphi? Ну не хочется работать с MS Access.
Кстати, а почему сразу не ЮМЛ?Непонимающий Потом трудно от структурного к объектному перейти. Лучше что-то одно, и конечно ЮМЛ.
Тогда надо и сразу на JAVA :)
Шаблоны проектирования(Design patterns)? Может от этой точки станет деиствительно интерессно?
-
Отвечу так. Есть такое понятие как ГОС - государственный обучающий стандарт.
А он определяет направление и темы. К тому же изучение UML само по себе никого не научит системному мышлению. К сожалению получается, что так. Хотя мне думается то лукавство.
UML хорош, но он слишком объемен. Только просто прочитать внятно семантику и синтаксис этого языка - одного курса не достаточно, да + еще хоть какой-то инструмент освоить. ГРАМОТНО.
А в общем так получилось исторически, может со временем я и уйду от SADT, или буду рассматривать их кратко. Но пока считаю как инструмент обучения IDEF0 DFD IDEF3 IDEF1x - очень хороши . Тем более диаграмма активности - а чем вам не IDEF3 или DFD. А диаграмма состояния чем не DFD, да и use case считай упрощенная DFD, без явного связывания. Миниспецификация - тот же сценарий варианта использования. Думаю UML дает слишком много свободы, потому его начинать изучать раньше других методологий не верно. К тому же говорить, что UML есть язык ООП, не совсем корректно, да разные есть причины, хотя бы потому, что студенты еще не проходили ООП:-)) А структурное программирование все-таки понятнее. Тем не менее никто все равно не понимает, что SADT и есть система ориентированная на структурный подход программирования.
NIN. Акцесс тут вовсе не причем. Просто Акцесс под рукой, и переход туда не требует знаний каких-то. А в Дельфи? Я что на занятиях еще буду объяснять как работать в дельфи, учить всяким подходам - BDE ID FIB и другие? А своим то главным делом когда займусь?
А так - всего занятие и нужно из ERwin перекинуть в акцесс, там ничего не делая!!!!!! просто посмотреть, получившуюся схему данных, и попробывать ввнести в таблицы данные используя всякие фичи акцессовские - подтаблицы и прочее. Очень удобно для быстрого прототипирования... А потом кто сказал что акцесс отстой? вовсе нет, для определенных задач очень даже не плохо. У меня куча проектов аксессовских - прекрасно работают в течение 6 лет и никаких сбоев....
А потом раз Вы студент сами понимаете, что хорошо знающий JAVA скажем врядли будет работать в вузе, потому большинство преподов порой мало понимают в новых технологиях... Это факт к сожалению
-
Буду краток, лучше сразу учить ООП, чем потом переучивать. Было несколько человек с кем работал, кто знал структурное, и трудно было потом им обяснить зачем абстрактный класс нужен.
-
Буду краток, лучше сразу учить ООП, чем потом переучивать. Было несколько человек с кем работал, кто знал структурное, и трудно было потом им обяснить зачем абстрактный класс нужен.
Блин писал писал тут ответ, а в результате ваша сессия закончилась, Саш, настрой форум, а то никто к нам не пойдет!!!
Написал две страницы, уж точно не буду восстанавливать.
Буду краток ты прав, но не в моем контектсе. Я учу не программированию, я учу умению решать проблемы, формализовывать систему, причем без относительно к технологии и языку реализации
-
Блин писал писал тут ответ, а в результате ваша сессия закончилась, Саш, настрой форум, а то никто к нам не пойдет!!!
Написал две страницы, уж точно не буду восстанавливать.
Знал бы как, настроил :) Ты наверное поставил авторизовывать себя на 60 мин., поэтому и вылетел или одновременно лазил и в админку и в форум. Можно сделать бэк и скопировать сообщение, а потом заново запостить. У меня вообще просто высветилась что ваше сессия закончилась, но пост не стерся, а остался на той же странице ответа.
Буду краток ты прав, но не в моем контектсе. Я учу не программированию, я учу умению решать проблемы, формализовывать систему, причем без относительно к технологии и языку реализации
Я имел ввиду лучше мышление сразу перестраивать на ОО, а то потом сложно будет обяснить, что ВИ - это не ф-ция.
-
Сейчас учусь на одном из старших курсов по специальности Системное проектирование. К огромному сожалению, у нас нет преподователей которые смогли бы прочитать курс, связанный с современными методологиями анализа. Но, в любом случае, нам читают предметы которые лежат в основе проектирования, описания и тд, применительно к авиации. В этом семестре, например, начался Системный анализ. Мои однокурсники, мягко сказать не очень понимают что это за предмет и для чего все это нужно (по крайне мере 90% из них). А мне делать там нечего, простите за скромность. И на это есть 2 основные причины: Во-первых, мне очень интересно, что дает мотивацию посмотреть разнообразную литературу по теме. Во-вторых, по роду работы немного (к сожалению) занимался анализом Бизнес процессов и архитектурой программных средств, поэтому легко представляю как это все использовать на практике (хотя всего лишь неглубоко знаю UML и совсем немного ARIS). Вот мне и кажется, что в практике и есть основная проблема, нам ее просто критически не хватает! Рядовому студенту даже представить сложно как выглядит Бизнес процесс. Даже если он выучил методологию ARIS наизусть, то когда ему скажут, к примеру: "Спроектируй БП, описав работу материального отдела бухгалтерии!". Не удастся, потому что как работает бухгалтерия для него остается загадкой. Может в этом и кроется проблема...
-
Вот мне и кажется, что в практике и есть основная проблема, нам ее просто критически не хватает! Рядовому студенту даже представить сложно как выглядит Бизнес процесс. Даже если он выучил методологию ARIS наизусть, то когда ему скажут, к примеру: "Спроектируй БП, описав работу материального отдела бухгалтерии!". Не удастся, потому что как работает бухгалтерия для него остается загадкой. Может в этом и кроется проблема...
Практики не хвататет не только студенту, но и всем кто начинает изучать ЮМЛ и все что с ним связано, поэтому и был создан предыдущий и этот сайт ....
На самом деле, по сути, не так важно для учебных целей досканально знать БП "работу материального отдела бухгалтерии", важна методология, даже если он опираясь на базовые данные без деталей, опишет как надо, то это уже отлично. Практика тут кроется немного в другом, т.к. прочитав тонны макулатуры не сделает с 10ок примеров, то он не бует знать в сущности ничего.
-
Keen_G...
Полностью согласен, практика - основа всего. Можно прочитать кучу материала, но если не дать пощупать, все это бесполезно.
Потому я и кричу, помогите, посоветуйте, как донести до человека важность.
Думаю, мои студенты будут полностью солидарны с Вашими 90%. А накой это надо. За 6 лет, я выслушивал разные мнения от студентов, причем в первую очередь умных и неглупых, которые имею вполне неплохую практику разработки проектов. Большинство считают, а зачем делать всякие модели- пустая трата. Вы нас мол учите технологии COM, Java Beans, Ecllipce и т.п. Я обычно отвечаю, а также языкам Питон, ТСЛ, АДА85, Кобол, и т.п.
Времени-то откуда взять, научитись сначала понимать один язык...
Однако я же участвую в защите дипломов, и когда студент защищается видно, что получается. 100% не могут составить грамотные требования к системе. Да некоторым удается сделать неплохой проект, чаще всего не с нуля, а как продолжение, на базе 1с или еще чего, но... практически не возможно продолжать их дело. Ставил эскперимент - в течение 2 лет подряд делал с ребятами 1 проект. Первый должен был сделать моделть и некий прототип, а второй продолжить усовершенствания. И что в итоге? Либо мне самому все пришлось бы писать от начала до конца(но это не мой принцип), либо просто каждый день заниматься со студентом все свободное время. Последнее не против, но так получилось, что они просто не хотят брать знания, просто упираются изо всех сил.
Вот Вы говорите нужна практика, согласен, нужна даже не практика, а стимул. Например, мы заплатим Вам 30 тыс рублей за этот проект - и откуда чего берется:-)
Но мои занятия как раз ведь и построены по приниципу приобретения опыта: есть примеры, постоянно объясняю. Например - идет лаба, сижу с парой студентов и обсуждаем их проект. Я смотрю на него как сторонний наблюдатель и задаю вопросы по ходу, а почему так, а это что, а как это понять, а объяните что тут. а как вы думаете, если это- постановка задачи и ее дать программисту - он сможет сделать, то что вы написали? Практически с каждой парой говорю половину занятия (около часа). И заметьте никто не записывает, не задает вопросы, не уточняет, не отстаивает свое убеждение.
Пример. Задание: существует компания, которая занимается выполнением заказов по почте, телефону и т.п.
Скажем книги. Она размещает рекламу о себе, подготавливает тематические каталоги, которые рассылает по почтам и другим общественным местам, принимает заказы от людей, и выполняет их. Отправляет заказы курьером или почтой наложенным платежем либо с полной оплатой ранее.
Книги заказывает у издательств, складирует их где-то у себя в офисе. Грантирует выполнение заказа в течение месяца в зависимости от дальности клиента.
Предлагается проанлизировать работу компании и предложить решение по переводу системы на веб-технологию, то есть разработать Интернет-магазин (1), систему управления складом (2)
Т.е. работают 2 студента -1 делает магазин, второй складскую систему.
Есть некоторое неформализованной описание работы.
Результат примерно через 2 месяца моделирования.
Сделана только контекстная диаграмма IDEF0 с нулевой декомпозицеей, на которой получается, что наша компания занимается следующим - ищет клиентов и перенаправляет их в издательства. Все.
Т.е. я например зашел на сайт, заказал книгую. мой заказ ушел в издательство, а издательство уже тпа выполняет заказ.
Я говорю - а причем тут ваша компания? какую выгоду она тут получает? кто ей платит? клиент за права просмотра тематического каталога? а не проще ему самому обратится в издательство и купить у него книгу без вашего посредничества, а потом где гарантия для клиента, что издательство захочет выполнить заказ. Т.е. клиент заплатил вашей компании деньги - пусть небольшие - а заказ исчез, кто отвественен? Ваша компания скажет - мы заказ отправили, издательство его получило, разбираетесь с ним?? такое ощущение, что ребята насмотрелись криминальных хроник...
Посел критик было улучшение, но и тогда компания неожиданно сама же и доставляет клиенту книги. Я вроде говорю, а почему вы так решили, а если клиент живет в адис-абебе, вам прийдется что фрахтовать самолет и туда лететь? Сколько же стоит заказ книги у вас? Вы торгуете раритетами?
А ведь в описание четко определе общий сценарий действий.
И так практичкески со всеми, на протяжении примерно 6 лет. Вывод мой таков - никто даже не пытается узнать больше, чем лекция, но на лекции невозможно рассказать все.
Что делать? Как мотивировать? Тут посоветовали ставь мол не больше 3 вообще за весь курс, и не сходи с пути. Через пару - тройку лет все будут бояться и учиться.
Вот к примеру в мое время (я учился не на ИТ, я химик) сложным предметом были сопромат и коллидная химия - все вешались, но многие хорошо учились и знания получали, что надо. А потому как спуску нам не давали. У друзей энергетов притчей во языцах - ТОЕ, теоретически основы электротехники - сдал ТОЕ - считай выучился.
Конечно, все эти предметы насчитывают десятки и сотни лет, потому и методически выстроены грамотно.
Думаю сам предмет системный анализ и все с ним связанное, очень еще молод, очень мало умных людей пишут хорошие учебные пособия, но есть и еще причины, но какие? Ничего практически студенты не читают, шаг влево, шаг вправо от намеченного курса сделать лень. А не читая книг, не изучая чужой опыт, не делая собственных ошибок как можно научиться?
-
Вот к примеру в мое время (я учился не на ИТ, я химик) сложным предметом были сопромат и коллидная химия - все вешались, но многие хорошо учились и знания получали, что надо. А потому как спуску нам не давали. У друзей энергетов притчей во языцах - ТОЕ, теоретически основы электротехники - сдал ТОЕ - считай выучился.
Конечно, все эти предметы насчитывают десятки и сотни лет, потому и методически выстроены грамотно.
Думаю сам предмет системный анализ и все с ним связанное, очень еще молод, очень мало умных людей пишут хорошие учебные пособия, но есть и еще причины, но какие? Ничего практически студенты не читают, шаг влево, шаг вправо от намеченного курса сделать лень. А не читая книг, не изучая чужой опыт, не делая собственных ошибок как можно научиться?
А вот тут ты сам ответил себе на вопрос. У нас тоже был сопрмат не из легких предметов. Но все его понимали и знали, хотя никто ничего дополнительно не читал. Только лекции с семинарами и учебники с методами и все. Так что в лево вправо это уже не то. Если те интересно, то ты будешь копать дальше, если нет, то ты должен знать все что в рамках курса и можешь даже сдать на 5.
В сегоднешенем обучении новым предметам есть несколько причин:
1. Нет достаточных учебных пособий именно для ВУЗов, т. о. курс читают как получится
2. Студентам некогда вникать, кушать хочется. Как сказал наш замдек - "Раньше студенты учились и подрбатывали, а сейчас они работают и подучиваются" Студент толкь опотом поймет, что он упустил за время обучения.
3. Не достаток времени у преподов и квалификации (тя не берем)
-
А вот тут ты сам ответил себе на вопрос. У нас тоже был сопрмат не из легких предметов. Но все его понимали и знали, хотя никто ничего дополнительно не читал. Только лекции с семинарами и учебники с методами и все. Так что в лево вправо это уже не то. Если те интересно, то ты будешь копать дальше, если нет, то ты должен знать все что в рамках курса и можешь даже сдать на 5.
Да ответил, но тот же сопромат: нужно рассчитать нагрузку на некую балку, которая хитро закреплена. Все же ясно, сложно, но решаемо: есть формулы, подходы, точные решения, математические заметь, строго формализованные.
А у нас? все расплывчато, сделал так, а почему так? Чем руководствоваться? Математической логикой - а что это есть? Предикативные высказывания? Или просто здравый смысл? А какой он здравый? Для одного это вполне здраво, для другого другое?
Где критерии? Критерии в неком формальном подходе, но верен ли он?
Да удается сделать проект, он вполне работоспособен, значит мы верно шли?
Пропагандируем его всемерно и вдруг ничего успешного у других не получается. Кажестя человек бъется бъется - но никак. Нет потому критерия, правильно это или нет, так или не так.
Вот берем задачу - рассмотреть функционирование деканата. С чего начать?
Начать сразу с рассмотрения действий работников деканата?
Или сначала их скрыть и рассмотреть, что окружающие ожидают от деканата?
А будут ли последнее правильно?
Цель деканата понятно - управление работой факультета в целом и в деталях. Функции известны в общем.
С чего начинать? С модели окружения читай БВИ, где рассматриваем только внешних лиц, и забываем про внутренних(а много ли их? методист да декан, да зам деканата) фактически функции деканата, это функции декана, а все остальные лишь его помощники.
Очень хотелось начать с внутреннего уровня, но тогда куда деть студента, учебный отдел, ученый совет, кафедры, преподавателей, заведующих, общежитие, ректорат и т.п.
Вроде они в деятельности деканата как таковые не участвуют, но для них собственно и работает деканат, аглавная задача - организация учебного процесса в целом...
-
Пару слов вствалю, если не возражаете ...
1. Студенты стали относиться халтурнее к учебе нынче, это факт. И этот факт объясняется в частности тем, что можно заплатить денег, и 3 балла получить ... не напрягаясь, совсем.
2. Студенты хотят получать не знания а НАВЫКИ, причем по конкретным технологиям ... чтобы можно было быстрее научиться "софт лабать".
3. Почему? в частности потому, что никто на производстве не требует ЗНАНИЙ, нужны НАВЫКИ :-) ... за знания работодатели тоже далеко не всегда готовы платить -- ибо экономика ОТКАТОВ. Не важно какое у тебя решение и сервисы, все равно тендер выиграет тот, кто "кум/сват/брат или бОльший откат".
4. Качество преподавания предмета Технологии разработки ПО в целом невысокое, я имел возможность ознакомиться с лекциями по нему, например в МИРЭА -- у меня у знакомых дети там учатся, попросили их проконсультировать. "Аццкая" смесь ГОСТ и IDEF. Учебников и методичек для курсовика -- НЕТ. Преподаватель сам в ГОСТах путается ... и причем сначала говорит что у вас не по ГОСТ выполнено (требования к ПО в курсовике), когда сделали все по ГОСТ -- сказала, что не обязательно строго придеживаемся ГОСТ :-). Если наложить на это нежелание студентов самих разбираться -- все .. смерть.
5. Как вариант, попробуйте сделать обязательным раздел в курсовике "Предположения и зависимости", где студенты должны излагать то что они дофантазируют на основании данных им кейсов ... может меньше будет случаев "отправок кнг в Эфиопию".
-
Спасибо Юрий за интерес к теме.
Полностью согласен по всем пунктам. Единственное но. Курс мой не проектирование. Проектирование они будут учить на 4 курсе во втором семестре. Тогда какая моя цель - очень неоднозначная. Во-первых, я не должен брать на себя функции чтения материалов по проектированию - вроде для этого цельный семестр и 200 часов аудиторных занятий. Мой курс существенно скромнее всего-то 100. Правда я взял на себя смелость и следующий за ним курс переделал в похожий. В результате получил нечто такое: первый семестр - основы системного анализа, структурные методы анализа, практика использования IDEF на базе BPWin, практика моделирования предметной области на базе IDEF1x с использованием ERWin. 2 семестр - объектно-ориентированный анализ на базе UML и RR. Стараюсь давать такие навыки как:
1. сбор первичной информации - на самом деле крайне тяжело, поскольку фактически я не могу заставить или обеспечить студентам возможность реального сбора информации, а только стимулирую их играть роль разработчиков сам играя роль заказчика. Реально - туго, практически никто не задает никаких дополнительных вопросов, хотя я даже написал целый шаблон таких вопросников - глухо как в танке.
2. Анализ первичной информации с выделением и уяснением главной и всех других целей системы - тут используется BPWin, причем я подчеркиваю - BPWin - это как карты Таро или натальные карты в гороскопе или магический квадрат Пифагора - просто средство оганизовать мысль и донести ее до других в некоторой определенной стандартом форме.
3. Уменеие на основании анализа предложить синтезированное решение в области ИС.
Мне приходится конечно затрагивать вопросы жизненого цикла и проектирования, даже требовать некоторого условного прототипирования. Например в 1 семестре - хотя бы БД на аксессе, во втором семестре - реализация приложения на дельфи, используя технологию BOLD MDA. На мой взгляд я даю НАВЫКИ в технологии, даже делаю на этом акцент. Пусть ты не понял теорию, но обязан понять технологические приемы - и они куда как конкретные: построил модель данных - конвертируй ее в БД аксесс и посмотри как работает твоя БД, аналогично тому, что ты хотел? Аналогично с диаграммой классов - сделал диаграмму - конвертируй ее в BOLD приложение и посмотри что получилось - удобно? просто сделать то, что ты хотел? НЕТ - переделывай модель!!!
НЕ ДОХОДИТ - ответы есть, они Вами перечислены и другими, но что делать, как сделать преподавание таким, чтобы в среднем все-таки результат был - пусть троечный, но был??
Кстати буду менять преподавание на следующий год, боле простые и очевидные задания, сделаю акцент на технологические решения, а не на творчество, а творчество оставлю на факультатив, может поможет??
Тут как-то пригласили в одну софтверную компанию проконсультировать постановщиков в IDEF, тихий ужас - практически никто не владеет даже технологическими приемами, а порой не владею простой логикой. Очень обидно, тем более народ у нас в целом не глупый, предлагаю выработать некие методические приемы...
-
А у нас? все расплывчато, сделал так, а почему так? Чем руководствоваться? Математической логикой - а что это есть? Предикативные высказывания? Или просто здравый смысл? А какой он здравый? Для одного это вполне здраво, для другого другое?
Где критерии? Критерии в неком формальном подходе, но верен ли он?
Да удается сделать проект, он вполне работоспособен, значит мы верно шли?
Пропагандируем его всемерно и вдруг ничего успешного у других не получается. Кажестя человек бъется бъется - но никак. Нет потому критерия, правильно это или нет, так или не так.
Ну хорошо, зайдем с другой стороны. Сложно подобрать критерии к рекомендательным подходам. Вот примеры:
1. Когда зашел у нас спор с другом на счет бух. учета в Банках.
Он в этом спец. и говорит: "У нас в нашем бухучете все на перекосяк шаг влево, шаг вправо - растрел, так работать невозможно. Весь мир уже работает по другому, международный стандарт бухучета (забыл я как он называется). Вот он носит рекомендательный характер, и есть регулирующие органы, ревизоры. Если ты сможешь им доказать, что ты сделал правильно, то тя не оштрафуют если нет, то пипец те."
А я ему говорю: "Что за фуфло ваш международный бухучет, если нельзя все расписать до винтика и строгизх мат. формул. Это как же получается как хочу так и ворочу?"
Он: "А вот так, поверь мне что так лучше."
(Рассказал в краце и без деталей, надеюсь смысл понятен)
И спорили мы до 5 утра под пивко :) Причем нас было два техноря, а он один :)
Для меня тогда это тоже было шоком, как так бухучет и без строгих правил. А сейчас ты требуешь строгих правил к творчесому процессу.
2. Был у нас в инсте С++ и был курсовик, надо было что-то реализовать, используя Классы. Я и реализовал, переделав из структурной программы алгоритм по игре в шахматы или шашки (я уж не помню). Программа работала верно и все было ок, пока препод (очень грамотный мужик) не посмотрел в код и сказал, что иерархия классов реализована не правильно и сказал как надо было бы реализовать.
В програмирование тоже нет строгих критериев релизации, есть только патерны, которые нам видимо тоже надо реалтзованвать и для ЮМЛ. Посади 10 человек реализовать программу и все они напишут поразному, у всех будет работать в итоге, но код будет у кого-то правильнее а у кого-то вообще кривой.
3. Из форумов по "проектированию БД".
Есть БД, построенная со всеми правилами нормализации до 3ей формы, но она будет работать медленее в некоторых случаях, чем правильно денормализованная.
Итог: Сложно придумать четкие критерии к выше перечисленным процессам, иначе все бы загнали джавно в комп и нажимал бы кнопочку и генерилась правильная модель.
Вот берем задачу - рассмотреть функционирование деканата. С чего начать?
Начать сразу с рассмотрения действий работников деканата?
Или сначала их скрыть и рассмотреть, что окружающие ожидают от деканата?
А будут ли последнее правильно?
Цель деканата понятно - управление работой факультета в целом и в деталях. Функции известны в общем.
С чего начинать? С модели окружения читай БВИ, где рассматриваем только внешних лиц, и забываем про внутренних(а много ли их? методист да декан, да зам деканата) фактически функции деканата, это функции декана, а все остальные лишь его помощники.
Очень хотелось начать с внутреннего уровня, но тогда куда деть студента, учебный отдел, ученый совет, кафедры, преподавателей, заведующих, общежитие, ректорат и т.п.
Вроде они в деятельности деканата как таковые не участвуют, но для них собственно и работает деканат, аглавная задача - организация учебного процесса в целом...
У меня критерий один: Нужно мне или моей организации черкать БМ или нет, если нет, то не делам, если что-то не понятно или требует закзчик, то делаем.
Для учебных целей думаю БМ не нужна, черкайте сразу СМ.
З.Ы. Если не возражаешь, то запостю данный тред на www.sql.ru. Или ты это сделай в разделе "Разработка ИС".
-
З.Ы. Если не возражаешь, то запостю данный тред на www.sql.ru. Или ты это сделай в разделе "Разработка ИС".
не возражаю. Пости.
Однако, я понимаю, что все это творческий процесс, но как раз и цель, сделать творческий процесс технологичным. Когда-то счтиали, что сделать машину - искусство, а сейчас это технология. А технология базируется на критериях и четких алгоритмах, которые нужно понять.
Вот и цель как донести эту мысль до студентов.
А уж если у него есть творческие способности - да ради бога. Понимаешь проектирование вообще нужно при коллективной разработке, а если я один что-то делаю, да на кой мне все эти модели, верно ведь...
-
Запостил: http://www.sql.ru/forum/actualthread.aspx?tid=370422&pg=-1
-
IMHO методология построения IT систем - пока слабо формализуемая область.
Поэтому тут, пока, так-же как в вопросе воспитания ребёнка:
- здесь холодно
- здесь горячо
- это ложка для ....
для студентов :).
-
IMHO методология построения IT систем - пока слабо формализуемая область.
Поэтому тут, пока, так-же как в вопросе воспитания ребёнка:
- здесь холодно
- здесь горячо
- это ложка для ....
для студентов :).
Согласен Q. Потому и есть такое желание, обощив опыт, выдать на гора хотя бы некоторые приемы с помощью, которых удасться что-то втолковать.
Хотя вероятно все это маниловские мечты, к сожалению
-
Вот что запостили на www.sql.ru:
http://www.maxkir.com/sd/useCasesTenYearsLater_RUS.html
Читаем и делаем выводы.
-
Вот что запостили на www.sql.ru:
http://www.maxkir.com/sd/useCasesTenYearsLater_RUS.html
Читаем и делаем выводы.
Почитал, что-то в этом есть согласен.
Суть такая, все равно это все в области искусства. Потому и научить можно только человека потенциально творческого, т.е нужно ставить ситуации где бы проявлялись именно творческие способности.
Однако !!! за ту зарплату:)) что нам платят, и при том количесвте студнетов - до 30 на группу - сделать творчество - слишком сложно.
Либо давать задание в начале семестра и не чего явно не указывать, только сказать что результат будет оцениваться строго.
Сумел построить систему - молодца, нет - сорри... Так что ли?
Эдак мне прийдется 2/3 на экзамен не пускать, так меня сразу уволят:-))
Правда тут со студенткой приключился такой разговор.
Девочка делает систему продажи металлопроката через интернет - типа бизнес-площадки.
Сделал - работает что-то ей вроде нравится. Теперь пришла пора описать все эти в записке. Что выбрать? выбрала UML, хотя весь код читсый структурный подход, не одного объекта только функции.
Начал делать - ошибок море но!!!! Сама говорит, я вот когда стала описывать все, вдруг понял как все криво я сделала, и то не так и эдак не эдак.
По моему это успех! Настоящий успех - если человек понял, как важно вот это обследование начальное, анализ моделирование...
Мне таки кажется UML IDEF0 и прочая беллетристика, все это карты ТАРО, астрология, гадание на кофейной гуще и прочее, т.е. нечто что позволяет организовать мысли и воплотить их в некий формализованый вариант описания ( а почему - да потому как язык этот не естественный, а тезаурусный, просто для его понимания, надо чтобы и противоположная сторона его понимала...)
-
Ну в общем ЧТД. Если человек хочет (студентка), то он помучается и получит результат и сделает вывод,все таки ЮМЛ - это не какая нить аэродинамика. Просто материал объемный и мало структурированный.
Кстати, м.б. про БМ вообще те не говорить, а идти от Agile и чем проще тем лучше, а на последней лекции сказать, что есть РУП и немного про него расказать и сказать, для более полной инфы читай там. Т.е. упростить до безобразия.
-
Кстати, м.б. про БМ вообще те не говорить, а идти от Agile и чем проще тем лучше, а на последней лекции сказать, что есть РУП и немного про него расказать и сказать, для более полной инфы читай там. Т.е. упростить до безобразия.
Понимаешь, я вообще не веду курсы проектирования. А выеду курсы теоретические, т.е. вводные для всех последующих. Мне и проще и сложнее. Проще то, что нет нужды опираться на какую-либо методологию, а сложнее - без опоры сложно донести смысл теоретических построений.
А вообще, может ты и прав, начинать надо с простейших приемов, а навык дело наживное, как и опыт...
-
Должен сказать, что я в целом понимаю Эдуарда, т.к. преподавал пару семестров Базы Данных, и хотел уже было начать преподавать СисАнАрхизм (Системный анализ и архитектуру систем), когда мне пришлось отказаться от идеи преподавания в вузе вообще. Т.е. мне самому очень нравится эта тематика, но на практике сталкиваешься с рядом принципиальных проблем.
В одном из последних курсов, где я вёл и практические занятия и лекции, я в начале семестра специально выделил фазу Анализа и проектирования, написал под них методические пособия (http://community.livejournal.com/ru_mysql/101612.html), но по итогам результат получился неудовлетворительным.
Какие наблюдения и выводы я сделал:
Да, действительно, ещё сильнее, чем в годы нашей с bas'ом учёбы, проявилась необходимость студентов прежде всего работать, а потом уже учиться. Причём если изначально если они и верят, что эта учёба им поможет в работе, то чем дальше по курсам, тем более они в этом разубеждаются. Конечно, это сильно зависит от преподавательского состава и качества учебного процесса, но даже в нашем доблестном вузе (Бауман) сами преподаватели признавались мне, что большая часть препод-состава не рубит в современных методиках консалтинга и разработки ПО в силу объективных и субъективных причин.
Специфика современной мозаичной культуры такова, что студент живёт в мире хаотично сменяющихся образов, мелодий, настроений, идей и возможностей (кибер-пост-модерн). Т.е. среда сама по себе не способствует целостности, монотонности восприятия и мышления, последовательной логике, вдумчивости, усидчивости и т.д. Позвонил-заскочил-списал-скачал-щёлкнул-стукнул-получил. Это нельзя не учитывать в обучении.
Вот Эдуард говорил, что ведёт сугубо теоретический курс. Для большинства студентов - это почти сразу означает ненужную абстракцию, умопостроения без практической пользы, споры по поводу того, сколько битов уместится на конце флэшки и т.д. Это путь в никуда. Да, есть люди, которые прекрасно работают с абстракциями, но большая часть их учится на физиков и математиков, а не инженеров.
Что действительно происходит в учебном процессе? Начался новый раздел, на лекции преподаватель дал определения, рассказал историю понятий, их назначение, взаимосвязь, далее были рассмотрены методы, продемонстрирован пример, дано задание. А один, два, три, пять студентов занятия пропустили по разным обстоятельствам, в результате потеряли возможность задать вопрос, чтобы понять тему (с чужими конспектами, даже если они и есть, не поговоришь), пришли на следующее занятие, и уже ничего не понимают - выпали из процесса. Многие боятся задавать вопросы по ходу занятий, хотя на одном слушании по крайней мере в анализе далеко не уедешь. Другая часть студентов просто динамит ДЗ, срывает сроки - а у преподавателя нет цели быть цербером-контролёром, он знаниями хочет поделиться, а не гоняться за каждым. В результате в конце семестра снежный ком троечников-двоечников.
Почему это происходит?
- Во-первых, сам предмет непрост для изучения - как говорят сами работодатели, системный аналитик - это штучный товар.
- Во-вторых, преподаватель физически не может персонально вести каждого из группы в 20 человек, если к тому же эта работа у него не основная, а курс не один.
- В-третьих, слаба мотивация учащихся - они в основном хотят откосить от армии, получить корочку для трудоустройства и замужества, в лучшем случае практические навыки, чтобы быстрее получить работу.
- В-четвёртых, слабая мотивация преподавателей - от участия преподавателя зависит многое, и если он выпускает какие-то аспекты учебного процесса из рук, то работают законы Мёрфи.
Что делать?
- Работать только с теми студентами, которые мотивированы на получение знаний и навыков, обладают устойчивым интересом к теме.
- Работать с ограниченным количеством студентов (3-5), используя персональный подход, в роли личного тьютора.
- Практическую работу орагнизовывать по возможности в командном режиме - это больше соответствует реалиям it-бизнеса + нефигово стимулирует участников.
- Как можно раньше привлекать студентов к решению практически значимых задач - организовывать команды "фрилансеров", чтобы они получали и настоящую практику и настоящие деньги, могли измерять свою эффективность.
- Стимулировать преподавателя - за счёт совместной работы нескольких преподавателей над учебным курсом, за счёт поощрения подрядной договорной деятельности, сотрудничества с бизнесом (малому бизнесу категорически не хватает IT!)
- Обучать не какому-то одному срезу - Инженерии ПО, работе с требованиями, базами данных, ООП, веб-технологиями, архитектурой, Анализом и Проектированием - а всему потоку работ и задач во взаимосвязи - как минимум за счёт сильнейшей взаимосвязи разных курсов, чего обычно в вузе не наблюдается - кто в лес, кто по дрова.
Какие выводы? В текущей структуре высшего образования всё это практически не возможно.
-
Денис, спасибо за сообщение.
И ситуацию в целом обрисовали верную. Если уж в Бауманке та же ситуация, что уж говорить о периферии.
Ясно, быть системным аналитиком - удел единиц. Тут нужен еще и кругозор, целостное восприятие мира.
Однако я хотел не только понять причины, вероятно, они известны каждому, кто в этой сфере работал, а как все-таки преподнести материал, чтобы ну большая часть ухватила знаний на троечку.
Проблема в том, что формируя разные подходы, анализируя результаты, я так и не смог сделать для себя выводы, а какой метод преподавание избрать.
Делал по-разному:
и давал полную свободу, главное получить результат (ну обычно какое-нибудь небольшое приложение реализующее часть системы). Результат - справились единицы
давал минимум свободы - действия по шаблону - шаг влево шаг вправо расстрел. Результат - справились единицы, и даже этим единицам было не комильфо
упростил задания, разбил задание на части, части распеределил среди нескольких группок(пар студентов) - результат - все ждут, когда сделает авторитет группы.
буду пробывать в следующем году этапность - т.е. объяснять некоторый этап на примерах, а потом заставлять стдентов делать по образцу и подобию с доп фантазированием, если хотят. Ставить оценку. Затем к дургому этапы и т.д. Т.е. жесткий контроль за исполняемость, дробление общего проекта на мелкие шажки. Боюсь получится не намного лучше, но заствалю работать в классе, а не делать это во всем семестре. Единственная выгода, все-таки будут заниматься делом, а не лясы точить.
Индивидуальный подход - это идеал, можно было бы выделять группы и заниматься целенаправлено, но это не возможно.
Вывод из всего - а надо ли? Может гори оно синим пламенам? Читать как читал, спрашивать как спрашивал, кто научится молодец, нет его проблемы. Можно осла подвести к реке, но даже аллах не заставит его напиться
-
Вывод из всего - а надо ли? Может гори оно синим пламенам? Читать как читал, спрашивать как спрашивал, кто научится молодец, нет его проблемы. Можно осла подвести к реке, но даже аллах не заставит его напиться
На том свете зачтется ... А если серьезно, то решать тебе, но думаю - не бросишь ты все на самотек....
-
На том свете зачтется ... А если серьезно, то решать тебе, но думаю - не бросишь ты все на самотек....
А если тот свет-то?
Ой не брошу, ты прав
-
Возможно лучше тратить первые 4-8 часов лекций на объяснение зачем это нужно студентам,
практические примеры зачем это нужно, где это помогает, что это дает?
Вобщем как в анекдоте про глобус:)
-
Возможно лучше тратить первые 4-8 часов лекций на объяснение зачем это нужно студентам,
практические примеры зачем это нужно, где это помогает, что это дает?
Вобщем как в анекдоте про глобус:)
Ой да я не только на первых лекциях, я на каждой лекции на каждом занятии об этом говорю, даже устраиваю экскурсии на защиты, чтобы 3 курс посмотрел что получается
Даже веду факультатив по МДА технологии где ясно видно, что получается при моделировании диаграммы классов.
Понимаешь, когда речь идет про моделирование данных, тут еще куда не шло, а когда про определение целей системы, функций и т.п. - тихий ужас:-))
-
Ну незнаю мне нравится очень.
Может это не интересно народу?
Но блин никто же не заставляет этим заниматься всю жизнь.
Это позволит делать выводы в любой ситуации. В частности в соц. среде.
И может помочь принять правильное решение, зная систему...
Очень странно, мне бы очень хотелось иметь такой предмет в университете, точнее хотелось бы что бы он был там когда я учился:)
П.С. Пока человек не захочет научиться он не научится, не захочет пока не станет интересно или необходимо. Первый вариант намного эффективнее влияет на обучение.
Отсюда делайте вывод.
-
Да, правильно, нельзя все сваливать на Студентов, сами виноваты, если не можем выстроить доступный процесс обучения...
Отлично, давайте попытаемся создать план обучения и контрольные вопросы.
За основу возьмем 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 лет, я многое изменил в интерфейсе, но практически мало в структуре данных. Более того это решение я растиражировал еще на два проекта. Все работают замечательно, мое вмешательство минимально. Уже позже изучив теорию систем, теорию РБД и прочие мудые науки, я с удивлением заметил, что довольно правильно использовал все. Вопрос, почему я не имею крупицы знаний смог, а студент, имеющий довольно много базовых знаний теряется? ИМХО, потому, что воспринимает это как учебная рутина раз, мотива нет два. Как всеэто изменить? Ответа нет...
Потому весь этот проект - думаю есть возможность систематизировать знания, выработать некую стратегию и тактику преподавания в целом. Систематизация, технологичность всегда приносила повышение производительности. Вспомним Форда.
Так что думаю какое бы задание не было, все что можем мы в данной ситуации - это все-таки наложить на него жесткие ограничения, обучать мелким приемам. Системность мышления прийдет позже, когда человек столкнется. потму в первую очередь научить хотябы механическим приемам. Нельзя думаю научить творчеству, но технологии можно
-
Да согласен. Но... интерес ведть составляет не просто любые системы, а системы, которые можно преобразовать в ИС. Согласить, что система решения уравнения к этому не подходит. Не подходит и физический процесс. Хотя именно с него я обычно начинаю знакомство студентов с инструментарием. Я обычно все-таки показываю не сам физический процесс, а его информационную модель. Скажем - Собрать стул, очевидно что на входе идут комплектующие, я их указываю - так нагляднее и проще, но параллельно указываю документы - наряд на сборку, чертеж, заказ на комлектацию, собранный стул с сопроводительной документацией. Да интересен процесс сборки, но в нашем конкретном случае интересна учетная функция. Т.е. мы рассматриваем скажем цех сборки, рабочее место мастера по сборке. Предположим, что наш мастер включает компьютер, смотрит опцию входные задания, где расположен список заказ-нарядов на сборку того или иного изделия. Если необходимо, мастер может запросить спецификацию сборки, чертежи и т.п. После изготовления стула, мастер фиксирует факт его изготовления в накладной на выпуск. Данная накладная поступает скажем в отдел ОТК, где тоже меняется это документ - утверждается или отвергается, ну и так далее.
Ты скажешь, это сложно для студента - он не знает предметной области.. Может быть, но я откуда это знаю? Откуда я знаю как осуществляется сборка и т.п.? думаю и студент догадается.
Какую систему мы можем взять - которая известна? Ну например работа приемной комиссии? Но она им известна только с одной стороны. Можно взять рейтинговую систему - тут кажется им все известно, есть документ положение и т.п. В прошлом году я дал такую задачу, и студент был кажется заинтересованный, но он делал все так сложно так заковыристо, что в результатет пришлось снять. Процесс сдачи экзамена, запись и посещения библиотеки, подготовка к обучению и т.п. Такие задачи я давал - результат еще хуже. на самом деле эта ПО им неизвестна еще более. Думаю задачи на работу магазинов, складов, псевдо производств и т.п. вполне дееспособны.
Главное задать рамки в которых студент должен действовать и оценивать две стороны - техническую и творческую.
Пусть творчеству мы не научим, но зато техническая сторона будет зафиксирована.
Все-таки скажу как и что мы делаем.
Цель - построить модель функционирования системы, сформулировать функциональные требования, построить инфологическую модель. Пощупать ее в акцессе.
С чего мы начинаем:
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 по разработанной системе тестов по перечню навыков (http://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA) или
- Не менее 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 часа.
Кроме того, методика должна базироваться на последовательности лабораторных работ, т.к. курсовой не предусмотрено.
Еще все-таки обратите внимание на теоретический характер дисциплины
Кроме того давайте решать задачу поэтапно. Сначала сделаем нечто, что подойдет для меня, а дальше развернем как самостоятельный ресурс.
Поскольку системный анализ - это все-таки набор процедур, методов и методик, то надо определится с набором их касаемо специалистов в области ИС. На мой взгляд - первое на что нужно обращать внимание в моем случае - сбор требований и формирование модели данных, либо просто привить навыки сбора требований:
- сбор первичной информации
работа с документами
описание функциональных требований
описание информационных потоков
-
По порядку.
1. Этюд с квадратным уравнением закончить можно.
2. Этюд с учетом ТМЦ можно продолжить, наложив некие ограничения модельного характера. Ясно, что рассмотреть реальный бизнес процесс весьма сложно, но попробывать стоит. Если тебе не нравится этот этюд - предложи свои и ПрОб образования. Однако даже эта область мало знакома студенту, вообще я заметил, студент многое мало знакомо: причина - мало мотивации, попроси разработать систему по учету ТМЦ скажем тысяч за 10 и месяцев за 2 - удивительная метаморфоза - студент просто забомбит тебя вопросами и консультациями. Вывод - проблема мотивировки. Что делать учить всему, но этапно. Дать возможность пошевелить мозгами. В этом и методика: примеры, строгие шаблоны, набор шаблонных вопросов, контроль со стороны преподавателя, его направляющая деятельность...
3. Научить задавать вопросы - это главное. Это я всегда предполагал. Ограниченное описание и должно было стимулировать фантазию, стимулировать сутдента задавать вопросы. Но в семестре -это идет плохо, зато перед сессией - меня просто торпедировали вопросами. Вывод: каждый этап должен быть разбит на 2-3 занятия с завершающим контролем, типа напишити список вопросов, которые бы вы задали, если бы получили такое задание: нарпимер организовать прием экзаменов по математике в 10 классе школы №18. Думаю с этим справится можно....
4. Чему учить - исследовать, моделировать. Полный цикл не нужен.Все-таки пока я нацелен не на аналитиков как самостоятелных специалистов, а на разработчиков БД. Ну понимаешь каждый инженер учится читать чертежи, их чертить при необходимости, но не всем же дается это столь подробно, как скажем конструктору. Т.е. можно обойтись и без начертательой геометрии. Надо научить читать схемы, их строить. И подчеркиваю для выделение понятий и связей для модели данных, ограничений бизнес правил
5. Следует учить овладеванию приемов анализа, а не конкретно бизнес-анализу и т.п. Следует показать приницпы использования инструмента, а далее отрабатывать приемы его использования. И семестра будет мало:-)) Но зато будет еще семестр - моделирование систем, где я могу тонко продолжить, предмет Базы данных - где есть курсовая, и где требуется формирование требований, построение ИЛМ. В конце концов будет КИС на 5 курсе, где можно сделать упор на бизнес-процессах и поучиться их описывать, все-таки к тому времени знания студентов расширяться, в том числе и экономическими понятиями, теорией принятия решения, представлениями знаний, интеллектуальными ИС, проектированием ИС..
6. Предельно простые находящиеся под носом. Я все жду когда ты мне ее предложишь - кроме решения уравнения :-)) Понимаешь мы готовим специалиста по ИС, специалист по ИС должен уметь создавать модели данных - ведь это ядро системы, построение модели данных требует изучения требований, сбор информации о них. Мне неинтересно моделировать физический процесс, мне важно моделировать сопровождающий его информационный процесс. В том же учете ТМЦ: можно учесть все что ты написал и даже больше - ты просто эксперт по ТМЦ:-)) НО в нашем случае пусть будет простофиксация факта получения, факта отгрузки, факта перемещения. В конце концов мы можем задать ограничение: Склад имеет N - стеллажей, в каждом стеллаже M - секций, в каждой секции K - полок. На полке умещается Z-ящиков, в каждом ящике хранятся изделия одного типа, от одного поставщика, одной партии и прочее. Не надо слишком заморачиваться, не стоит прыгать выше головы. Ненадо залезать в паралич анализа...
Задача пусть будет простая или сложная, но решается просто. Можно просто оценивать стремление человека все описать и все учесть, оптять же итерационность цикличность. Ну зачем заказчику столь сложный анализ БП? Это он должен его предоставить, он же спец в этом, быстрый гибкий анализ, быстрое получение результат, циклическое его уточнение с заказчиком. Напрмер трудно проанализировать диаграмму функций, но гораздо проще модель данных на ее корректность, а еще проще попробывать ввести некие данные, чтобы понять свои ошибки, имхо....
А учим всему по немногу:
и научить выделять цели - это веротяно первое, чем вообще надо учить
второе формальному или полуформальному выводу одного из другого, тем более дискретныю математику они прошли, матанализ тоже, мат логику тоже. Учить диалектике мышления, расширять кругозор, включать фантазию - думаю
это главное.
Просто приведу пример из своей практики.
Я делал диплом по моделированию кинетики плазмохимических систем. Я знал ПрОб достаточно хорошо, я умел писать уравнения, решать их десятками способов, знал терминалогию, понятия, предикаты - но не умел это применять в анализе, в творческом анализе!!! И только через 3 года, когда я начал активно писать диссертацию на меня снизошло озарение, все знания встали на свои места, сложиись в цельную непротиворечивую картину.
Т.е. я к чему - все равно боьшинство студентов не будут уметь применять СА правильно, нет опыта, нет плодов ошибок, бессоных ночек, головных болей, мотивации и т.п. Но так или иначе, все-таки надо приучить определенным шаблонам поведения, алгоритмам поведения, алгоритмам рассуждения. Тот кому это явно понадобится- быстро сумеют востановить знания и систематизировать их
Однако это не исключает, что мы должны обучать правильно, методично, спрашивать строго и с пристрастием
-
Некоторые мысли вслух.
Строго говоря методике использования СА в вузе учат на всем протяжении обучения. Т.е. в первую очередь в вузе учат решать задачи и решать их наиболее приемлемым способом.
СА применяется для решения нескольких типов задач:
строго формализованных - эти задачи наиболее распространены в обучении, они строго определены, методы известны - задачи математики, физики, химии и т.п. различные математические схемы сводимые к теории автоматов, дифурам, сетям, СМО, и т.п.
частично формализованные - используются комбинированные как качественные так и количественные методы
наконец неформализованные или слабо формализованные - наиболее общие задачи и наиболее сложные - основные методы снятия неопределенности качественные.
В нашем случае я все-таки склонен полагать что задачи частично формализованы, поэтому существенный вклад в анализ вносят качественные методы: мозговой штурм, дельфи, экспертные оценки, эвристики и т.п.
Итак как я полагаю студент 3 курса уже имеет определенный навык проведения СА, хотя он может и не знать об этом. Однако мы можем эксплуатировать это фундамент и аппелировать к нему. Главное показать приемственность..
Теперь о нашем курсе и методике.
ГОС я уже приводил, не буду повторяться. Каково окружение.
Дискретная математика, Математическая логика. Реляционная алгебра, Теория веротяности и статистика, Информационные технологии, Струткурное программирование, Математический анализ, Функциональное математическое моделирование
Что требуется дать - основы и приниципы (закономерности) ОТС и СА, общие понятие ИС, ее структуру, формы обеспечения, понятие жизненного цикла, методолгии структурного анализа IDEF, DFD, IDEF1x.
Что требуется закрепить:
1. Разделению задачи на подзадачи
2. Целеполаганию
3. Умению анализировать информацию и задавать вопросы
4 Выделять существенные стороны, выделять понятия и связи этих понятий
5. Уметь выделять требования, формулировать их, определять бизнес-правила в рамках недостатка информации
6. Уметь проводить анализ документов
7. Уметь строить Idef0 модели? DFD, обращаться с IDEF1x. На самом деле - это нетак сложно, сложнее получить что-то действительно ценное.
Как действовать
Лабораторный практикум - 18 пар = 36 часов. Все задачи должны быть разделены на этапы с промежуточным контролем. Контрольные задания должны выполнятся за одно занятия, включая предварительную домашнюю работу.
Задание возможно должно представлять достаточно понятный и неочень сложный бизнес-процесс в упрощенном представлении. Главное тут методика и техника анализа, а не конечный продукт. Хотя конечный продукт стимулирует вооброжение. потому вводим обязательный этап реализация базы данных в Аксесс.
Почему - доступен, есть литература на каждого студента, есть примеры в конце концов. Есть функция подтаблиц, которая позволяет проследить логику использования и заполнения БД. Кроме того планируется результаты работы 1 семестра использовать по желанию в 2 семестре при реализации курсовой работы по проектированию БД и простого приложения...
Методика
1. Занятие начинается с примера, который преподаватель демонстрирует с помощью видео техники.
2. Судентам предлагается повторить приемы работы самостоятельно на своем задании - веротяно задание на пару студентов - ограничение на посадочные места - 16 компьютеров около 30 студентов, кроме того имитация коллективной работы.
Какие этапы занятия.
1. Уяснение задачи. Струтуризация задачи по возможному шаблону (нужен шаблон - ясный понятный неочень формализованный и сложный). Целеполагание. Выстраивание иерархии целей. Выделение участников и их интересов. думаю этот прием применим в любой методологии
2. Описание процесса по заданию. Формирование вопросов, которые следует задать (опять примерный перечень вопросов, некий тест-проверки) Цель возбудить фантазию, стимулировать воображение.
3. Построение модели по описанию, пусть модель ради модели. Строим модель IDEF0, есkи нужно IDEf3 (шаблон, рекомендации по формированию контекста) Основание результаты работы 1 и 2 урока. Думаю иерархия целей - трансформируется в иерархию функций. Остается определится со структурными связями. Повести ранжирование функций, выделить наиболее значимые первоочередные, без которых дальнейшее моделирование не возможно.
Уточнение входной управляющей выходной информации (документы, отчеты бланки и т.п.)
4. Трансформация IDEF0 в DFD, предложение по струткуре будущей ИС. Предложение маршрутов обработки информации, определение хранилищ, верификация потоков, связывание потоков с данными (сущностями и атрибутами)
5. Ведение словаря данных
6. Формирование миниспецификаций - фактически ВИ нижнего уровня
7. Трансформация DFD в IDEF1x - либо автопереносом определнных сущностей, либо проведением анализа документов форм отчетов и бланков. Во втором случае следует сформировать гипотетические документы (а возможно мне самому их предоставить, сложно но думаю вы мне поможите, и с нами Бог). Думаю модель аднных должна быть неочень сложной и содержать неболее 5-6 таблиц - сущностей, даже после нормализации
Пусть задача не будет выполнена комплексно, пусть будут частичные процессы, но коли студенты работают в паре, можно помочь выбрать им два значимых и доплняющих процесса, где каждый рассматривает свой вариант, а потом сравнивает на предмет пересечения.
Например процесс размещение заказа в интернет магазине книг и процесс выполнения заказа. В обоих случаях нужен тематический каталог книг. Как он заполянется и формируется можно опустить, но его струткура нужна как при размещении заказа, так и при его выполнении
Жду конструктивных предложений...
-
Усвоение студентами совокупности теоретичес¬ких знаний должно привести к формированию в их сознании такой структуры знаний, которая соответствова¬ла бы структуре изучаемой теории. Знания студентов, отвечающие этому требованию, т.е. образующие струк¬туру, адекватную структуре научной теории, будут назы¬вать системными. Системные знания — это знания, структурирующиеся в сознании студента по схеме: основные научные понятия — основные положения — следствия — приложения.
Как же сформировать системные знания?
Для этого у студента должны быть сформированы:
— знания о теории, ее составе и структуре;
— представления о природе получения этих знаний;
— представления о том, какие знания входят в теории непосредственно, а какие — опосредованно;
— представления о роли научных фактов для теории.
Таким образом, для формирования системности в зна¬ниях студентов им необходимы знания о знаниях, назы¬ваемых методологическими (Зорина Л.Я. Дидактические основы формирования системности знаний старшекласс¬ников. М.: Педагогика, 1978).
-
Красиво ты все расписал, но некоторые моменты надо более выделить, а другие скрыть.
Насчет - маловато времени - согласен. Но давай все-таки учтем такой факт. Я обучаю тебя численным методам, моя задача пройтись по всем типам задач за семестр. Я готовлю тебе задания, объясняю методику их решения. Научишься ли ты решать эти задачи на 100% после семестра? Очень сомневаюсь, и еще больше сомневаюсь, если в дальнейшем тебя никто не застваит использовать эти методы.
Посмотрим на наш случай: Только закончится семестр - здравствуйте пожалуйста UML, где те же приемы можно рассматривать, но под другим углом. Парлельно нужно делать курсовую по БД: а это набор докментов или атрибутов + набор функций, которые нужно студенту выделить в осмысленный проект и сделать работающее приложение.
Идем дальше следующий год образования - проектирование ИС с курсовой, где преподы требуют со студентов DFD моделирования и моделирования данных (хотя скажу по секрету сами не в зуб ногой в этом не разбираются:-) )
5 курс - еще две работы курсовой проект и дипломный проект, так что есть где знания закрепить, расширить и обновить. По крайней мере, мои студенты поработают над этим в поте лица (дипломники I mean)
Графический инструментарий IDEF и DFD - не слишком сложен, гораздо понятен и быстро запоминается по сравнению с тем же UML. Фактически по каждой методике достаточно пол лекции, разве только для IDEF1x побольше. Другое дело применение, однако тут только опыт,опыт и опыт - и ничего больше. К сожалению, сказав 1001 раз, что функциональный блок следует называть глагольной или отглагольной фразой, я тем не менее всегда встречаюсь с названиями именительных существительных и т.п. Так или иначе, все-таки главным будет даже не графическое изображение моделей, а их текстовое, смысловое, логическое сопровождение.
3. Кроме тем и вышеописанных навыков во введении надо дать задачи на развитие фантазии и понимание системного подхода.
Подскажи пример? Мне -то кажется, что все что мы делаем в сфере обучения и есть системный подход, по крайней мере в моем контексте....
Если не делать полный цикл, нужно искать адекватные средства оценить результат решения задачи.
А метод обратной связи тея как не водушевляет? Говорят - это основной метод уяснения того, как студенты понимают предмет.
Думаю фантазию можно возбуждать некими микроконтрольными занятиями, на 10-15 минут. Например:
Дама сдавала в багаж:
Диван,
Чемодан,
Саквояж,
Картину,
Корзину,
Картонку
И маленькую собачонку.
Выдали даме на станции
Четыре зеленых квитанции
О том, что получен багаж:
Диван,
Чемодан,
Саквояж,
Картина,
Корзина,
Картонка
И маленькая собачонка.
Вещи везут на перрон.
Кидают в открытый вагон.
Готово. Уложен багаж:
Диван,
Чемодан,
Саквояж,
Картина,
Корзина,
Картонка
И маленькая собачонка.
Ну и некий вопрос - запишите последовательность действия, бизнес-процесс:-)) предложите модель данных для данных строк
Я каждую лекцию практически провожу летучку на 10 минут, задаю теоретические вопросы и микропрактические, на которые можно ответить за 1 минуту...
Кроме того можно каждое задание на практических разбить на ряд вопросов, на которые студент должен ответить и получить минимальные гарантии, что у него что-то получилось. Т.е. мысль такая - разбить каждое занятие - на маленькие обозримые вопросы-ответы, которые постепенно будут складываться в единую концепцию.
Т.е. как раз здесь и можно применить правило-метод дерева целей, каждый раз задавая себе вопрос: достаточно полно данное описание раскрывает цель.
Скажем выбираем 1 задание - выработка цели, границы, участников
1. Определить цель процесса
а.ответить на вопрос что делает процесс, для чего служит
б.кому это нужно, почему
в.требуется декомпозиция цели
г. какие функции попомгаю достичь цель
д. бла бла бла
2. Какова область дейстивя, границы
а. процесс как-есть
б. учет без бухгалтерских проводок
в. что-то не так??? :-)
3. Кто участвует в процессе
а. что они делают, для чего
б. с кем взаимодействуют
с. опишите роль каждого и т.д.
Ну это я так сумбурно конечно, надеюсь услышать что-то более профессиональное
[qoute]Во первых можно копать в математике. Например: нарисуй процесс сложения в столбик (IDEF вообще способен моделировать простейшие процессы решения математических задач?)
Во вторых можно копать в физике и геометрии - процесс решения есть везде.[/quote]
Сережа, ну не нравится мне эти задачи. Как пример на лекция согласен, но мне требуется чтобы это выделялось в семантическую модель данных, то что требует хранения, а не только обработки. Кончено можно исхитрится и составить таблицу парметры уравнения, результат уравнения - но это не то. Конечно учится моделированию можно на всем, но задачи надо все-таки выбирать из области близкой для использования именно студентами нашей специальности. Все-таки странно обучать студента-химика моделированию электротехнических процессов - как бы не схожи были эти процессы. Кроме того системный анализ все-таки в своей исходной посылке применяется для решения смешанных нечеткоструктурированных задач, а задачи физики, математики для них все-таки больше приемлемы методы исследования операций, методы математического и имитационного моделирования, такие задачи чаще решаются типовыми методами.
Конечно показать на лекции методическую основу, многовариантность, уменияе задаваться вопросами лучше на задачах такого плана как ты указал, т.к. всегда можно быстро проверить правильность (другими методами). Да с этой позиции такие примеры хороши и в практике лабораторных. Однако я боюсь мы слишком далеко уйдем от наших реалиях.
Все-таки нам нужна пусть простая, но многообразная предметная область. А как ее реализовать в том же примере решения системы линейных уравнений матричным способом - тут все детерминировано - метод, постановка задачи, способ решения.
Т.е. если мы берем такую задачу - как сдача студентом экзамена. Только процесс сдачи - тут все довольно ясно и вместе с тем есть информация, которую следует хранить, условия которые следует обрабатывать, и понятность - каждый студент к этому времени уже сдавал экзамены минимум 4 сессии.
В любом случае надо уходить от стадии высказывания мыслей, к стадий наполнения. Чем больше ошибок сделаем тем лучше...
Знаешь как вводил систему тестирования знания. А я три года проводил колокувиумы-тесты. Диктовал вопрос, студенты писали ответ. Каждый год через такую процедуру проходил примерно 16 групп, за три года 48 вариантов ответов у меня накопилось, я ввел их в комп, обработал, отбросил совсем глупые, откорректировал грамматические ошибки. И получил тест, одновременно довольно простой - но отлично стимулирующий внимание. Поскольку варианты ответов были очень близки. Сначал почти все получали двойки, даже при 3 попытках, но потом народ привык и стал внимательно читать ответы. Уровень образования - хотя бы с теоретической точки зрения сильно повысился.
паралич анализа чаще всего вызван отсутствием информации, а значит, отсутствием следующего вопроса, уточняющего модель.
Ты прав, но только отчасти. Как это не парадоксально, паралич часто возникает, когда стараешь ответить на слишком много вопросов. Понимаешь чем больше ты знаешь, тем больше возникает попутных неизвестных факторов. Все-таки я сторонник быстрой атаки, быстрого прохода по всем аспектам. Метод последовательных приближений - вот аналог моего подхода, главное дожен быть критерий для сравнения - здесь могут подойти например аналоги
-
Сергей, вчера полночи не спал. Думал думал и наконец чего-то такое надумал.
Итак, тезисы размышлений.
1. Системный анализ не панацея.
2. Системный подход - один из подходов, хотя и передовых
3. Системный анализ <> системный подход
4. Системный анализ для ИС <> системный анализ для бизнеса
5. Системный анализ для бизнеса = системный анализ для КИС
6. КИС будем изучать на 5 курсе, а потому уже можно взять бизнес-анализ за рога
7. Задачи математического или физико-химического плана можно использовать как отправные точки, синхронно рассказывая о IDEF-DFD. Взять на грудь это не сложно, нет там ничего особо нового, кроме некоторых ограничений.
6. Семинары вообще можно развести - не делать единую комплексную задачу, а сделать маленькие задачки из разных областей, что мне кажется довольно существенно. Чтобы задачи были и из изветной им области - например математики, и не совсем известной. Ведь СА именно тогда эффективен, когда изучается терра инкогнита.
Насчет сложности - можно поспорить, но не буду, скажу лишь "СА - это методика здравого смысла" (с). Найду точную цитату - приведу...
7. Моделирование данных, конечно, было бы неплохо иметь вообще отдельный семестр - от начала до конца, но нет его. Вообще в ГОС нигде нет даже строчки о том, что нужно учить IDEF DFD UML и прочее, думаю - это большой непорядок с одной стороны, а с другой стороны определнная дальновидность, правда эта дальновидность больше отрицательного вносит чем положительного. Потому - моделирование данных можно провести на основе анализа документов. Вообщем нужно думать размышлять
8. Подготовлю свое видение той же функции учета поступлений - выложу на суд обсудим.
А тебя попрошу докончить математический пример, правда лучше возьми скажем метод Ньютона для решения нелинейного уравнения(нахождения корня), всетаки там есть цикл, обратная связь
9. Про обратную связь в педагогике - это личное общение со студентом - каждым, чтобы почувствовать его интерес- неинтересн, понять что и как он понимает и не понимает. Именно этим я и занимаюсь фактически на практике, даже показывая пример - я всегда задаю вопросы аудитории и жду ответы, показываю им как нужно их анализировать и предпочитать одно другому, однако личное общение сверхважно - без него обучение пустой номер... Талмуд конечно никто не кладет да и не нужен, критерии очень простые: критерий здравого смысла- раз, критерий техники использования два, критерий умения формулировать мысли - три.
10. Про набор тем и подтем.
предлагаю занятие 1. Знакомство с инструментарием IDEF, это вообще в целом не сложно. В качестве примера берем хоть твой математический пример, обычно беру пример изготовления стола. Почему начинаем с этого - метод погружения, выплескивается некоторая мало понятная информация, очерчивается круг проблем и вопросов, к тому же надо еще лекции начитать:-))
Занятие 2. - Подробно разбираем этапы: целепологание, границы, цель моделирования - контрольное задание
Занятие 3. - Модель черный ящик(входы выходы, механизмыы, управление) - контрольное задание
занятие 4. - модель состава и структуры - инвариантность, критерии оценки вариантов (да вот а как оценивать?) - контрольное задание
Занятие 5 - пример более приближенный к жизни, сбор стула стола или еще чего, сопровождаемый документацией наряд, заказ, чертеж, спецификация, накладная и т.п. - опять же контрольное задание
Я думаю тут главное раскрутить машину и задать определенные стрессовую ситуацию для студентов - тяжело в учении - лекго в бою...
-
Давай брать быка за рога.
Предлагается задача
Автоматизировать обработку информации при приеме товара от поставщиков (ввод данных приходной накладной);
В качестве товара рассматриваются книги.
Книги подразделяются на жанровые группы (худлжественная литература, учебная, научно-техническая, компьютерная, бытового назначения). Внутри группы книги отличаются авторами, наименованием, издательством, поставщиком и т.д.
Книги постаставляются только упаковками по 20 книг в каждой. Формат в расчет не принимаем. Книги складируются на стеллажах, каждый стеллаж имеет N стоек, на каждой стойке M полок, На каждой полке можно расположить 3 контейнера. В 1 контейнере можно разместить 6 упаковок книг, т.е. имеем 6 секций
Бизнеспроцесс - принять книги
Описание: Приезжает машина с очередной поставкой книг. Книги поставляются на основании некоторого договора, проверяется путевой лист, книги разгружаются в отделе сортировки склада. По инвентарной описи кладовщик сверяет поставку, если есть недостачи или поврежденные упаковки составляется акт недостатч/брака, бракованные книги возвращаются поставщику. Принятые книги в соотвествии со свободными местами и правилами размещения, размещаются на складе. На каждую упаковку оформляется инвентарный ярлык с номером и кратким описанием, в журнале размещения фиксируется место, размещения, номер товара и его количество. Используя счет фактуру в системе учета фиксируется данная поставка товаров и оформляется приходная накладная - копия передается в бухгалтерию, выдается поставщику(?)
Что получилось?
-
Конечно он остается открытым, да и как иначе. Если бы ты к примеру мог попреподавать у нас или где-то еще такой же или близкий курс, плюс вообще в сфере образования и именно на подобной специальности поработал, вероятно было бы точнее и понятнее.
Я не против математических или физических процессов, пожалуйста, давай развивать параллельно.
Я говорю сразу - четко организованной методики нет, ее к сожалению нет ни в книгах, нет ее и в живой практике. Не очень понятны цели, которые нужно достичь. Потому я и иду ощупью, использую здравый смысл.
Выдав вот такую картинку, я просто стараюсь обострить ситуацию с одной стороны, а с другой стороны вызвать тебя или еще кого на дискуссию. Поскольку картинки обсуждать - интереснее:-))
Кстати если у тебя есть BPWIN - я буду выкладывать модели в этом формате. У меня стоит версия 4.1.4 - она конечно триальная, но вполне работоспособная.
Конечная цель ясна. Подцели я сформулировал, они на картинках. Хотя в реальности мне неинтересен вообще процесс, мне важна его информационная составляющая. Тем не менее, я специально иду на бизнес-анализ.
Заинтересованные стороны. Если следовать SADT методологии, то в ней заинтересованные стороны обычно как-то замаскированы, не выделены. Однако я понимаю, что мы можем ситуацию синтезировать.
Итак заинтересованные стороны:
1. Книготорговое предприятие - заинтересовано во всех формах учета поступающей литературы для продажи, в данном случае оно хочет знать какие униги, от кого были получены, в какой момент времени, какого качества поставка, где располагается продукция на складе, каковая ее цена закупки, сколько книг на складе, требуется ли дополнительные заказы на книги и прочее прочее. Однако в первую очередь - скдаировать товар, учесть его и сохранить столько, сколько нужно.
2. Поставщик (экспедитор поставщика) - заинтересован в качественной поставке книг, в их сохранности, несет отвественно за доставку, готов принять брак, должен получить соотвествующий акт приемки книг, акт браков, недостач.
Теперь некоторый комментарий:
Вот передо мной две системы: 1С предприятие стандартная конфигурация и КИС "Восточный экспресс". Конечно помимо чисто прихода, учитываются соотвествующие бухгалтерские проводки, появляется информация в соотвествующих справочниках и т.п. См. рисунок
Но все вопросы по нумеровке, разгрузке, идентификации и прочее скрыты. Хорошо это или плохо, мне кажется не очень хорошо, но с другой стороны, если происходит простой учет - достаточно по понятной схеме - сформулировать задачу автоматизации (фактически форму хранения данных, бизнес-правила, способ предоставления данных).
Тем неменее я понимаю, нужно понять сначал весь бизнес-процесс, чтобы найти более приемлемые решения.
Скажем в моем случае можно предположить, что кладовщик перемещается по складу с ноутбуком или наладонным компом и вводит информаци. о товаре, о месте ее расположения, сразу, извлекая предварительно специальный штрихкод и прикрепляя его к упаковке, автоматически занося в некий преварительный накопитель информацию о поставке. Затем просто скачав эту информацию на головном компьютере - быстро формирует приходную накладную. Реализаций может быть много....
-
Что-то я не очень понял, почему беседа потекла в такое русло.
Имхо, методика преподавания - это прежде всего КАК учить, исходя из того, ЧЕМУ учить.
Если хотите создавать конкретный учебный курс, то имхо стоит посмотреть существующие (http://www.intuit.ru/department/se/devis/) и понять, чем они вас не устраивают.
Говоря о типичных осязаемых бизнес-процессах, хочу привести пример работы кассира - в читаемой мной сейчас книге Лармана "Applying UML and Patterns" в качестве сквозного примера выбрана POS-система. Как раз с точки зрения бизнеса в книге всё очень плохо описано. Мне кажется, это гораздо более наглядный и доступный процесс, нежели доставка и хранение книг, которую редко кто наблюдает и сталкивается.
-
Тут на днях брал в книжном магазине полистать учебник по "Теории информационных процессов и систем" - так вот там сплошные формулы, векторы и матрицы. Вы уверены, что SADT - это то, чем надо кормить наших студентов?
Ну т.е. даже если брать банально в лоб информ. процессы - хранение, представление, передача, обработка (преобразование), удаление, сбор, поиск - то SADT тут вообще непричём, впору половину семестра читать Теории передачи информации и т.д.
Если смотреть ГОС 654700, то там после курса ТИПиС ещё отдельно будут "Моделирование Система" и "Проектирование ИС", вот там SADT, ARIS и UML уместны.
А в ТИПиС мне кажется надо смотреть ближе к этому (http://www.intuit.ru/department/expert/intsys/).
-
Денису!
Ну хорошо с целями определились.
Сразу вопросы:
- 4 балла из скольки?
- Ты представляешь себе объем работы по составлению тестов с учетом приведенного перечня навыков?
- Ты представляешь, как перечень навыков впихнуть в 1 семестр?
- Как организовать надежный механизм признания работодателем навыков студентов?
Критерии в целом ясны, но все так же непонятно, как связать состояние, в котором мы находимся с желаемым состоянием читывая, что оно все еще недостаточно определено.
Эти цели и критерии я приводил в качестве примера ) Приведённый перечень навыков скорее представляет мои интересы в компетенции потенциальных коллег-аналитиков, чем действительно необходимые навыки студентов именно этой специальности.
-
Денису.
1.Денис, я пытась читать предмет ТИПиС уже 6 лет. За это время я переделывал свой предмет 6 раз, иной раз на 50%.
У вас есть ГОС и учебный план. Вы должны были обратить внимание на множество дисциплин предшедствующих ТИПиС.
Есть там и теория информации, где им читают вопросы передачи данных и т.п. Учебников по ТИПИС фактически нет, все старые учебники - действительно ориентированы на одни сплошные формулы и связаны главным образом с теорией вычислительных процессов, а это замечу не одно и тоже. Лично я вообще возражаю против такой постановки вопроса, а зачем программисту, базисту, аналитику надо знать какова физика передачи данных? Да для общего понимания картины нужно, для понимания построения БД или ИС, до некоторой степени. Например, если канал имеет одну пропускную способность, а вы пытаетесь получить отличное быстродействие при большом количестве пользователей.
Далее - первые два года я читал ТИПиС без использования SADT и другого - проблемы дальше, проблемы невсегда мои. Потому произошло переосмысление дисциплины. В чем теория? теория систем, теория анализа, теория моделирования в обобщеном смысле, но направленная на способы построения систем и не просто систем, а ИС. любая ИС это информационное обеспечение, техническое обеспечение, персонал, программное обеспечение.
Техническое обеспечение - не моя задача (есть курсы ЭВМ, опреционные системы, платформы и т.п.)
Программное обеспечение - опять же не моя конкреная задача (есть ООП, Управление данными, проектирование и т.п.)
Моя задача - информационное обеспечение - что это такое, как его организовать, как оно влияет на все остальное. Это теория я ее даю на лекциях, что следует закрепить на практике - конечно применение анализа, способы решения задач, закономерности решения задач, при этом мне следует учитывать некоторую преемственность, какую, а такую что например на при проектировании ИС, студент должен владеть инструментарием и семантикой нотаций
Вообщем, давайте не будем мне советовать, что и каким образом читать. А лучше побеседуем о том как преподавать, то что уже обсуждается...
Я думаю уже все понятно
2. Приведенные вами ссылки учебных курсов затрагиваю теорию, а не практику - две совсем разные вещи
-
Про список тем: была поставлена цель. Если мой список подходит, хорошо, если надо внести исправления, предлагай и будем его фиксировать.
А нельзя огласить весь список(с). Ты дал рекомендации, а списка нет. Список может быть разным.
Могу предложить - задачи из численной математики:
1. Численное решение нелинейных уравнений (метод помследовательных приближений, Ньютона, хорд и т.п.)
2. Решение СЛАУ - матричный способ, способы прямые, способы итерационные
3. Интерполяция и аппроксимация
4. Дифуры и их системы
5. Оптимизация
BPWIN сейчас нет (раньше был, теперь что-то с лицензией не то), попробую достать и поставить.
BPwin 4.1.4. скачаешь с http://www.interface.ru (нужно зарегится, хотя можно и обмануть, там закачка идет с фтп, регистрация нужна только для контроля). Keygen могу выслать.
Если "Конечная цель ясна" - это ты про задачу с приходованием книг, то, возможно, она ясна тебе. Наша задача изложить цель в виде текста так, чтобы онга была ясна всем максимально одинаково.
Но она же ясна. Знать что привезли, кто, когда, сколько. Знать что есть, Знать кому отдали когда и сколько. Зачем усложнять задачу сверх меры??
Далее по поводу документов. Не моя цель учить пользоваться теми или иными доукментами. Сегодня одни документы, завтра другие. Но использовать что-то в качестве шаблона можно. Что прогрессивнее и проще то и лучше. Документ видение мне не очень понятен, но думаю с твоей помощью разберемся в нем.
какие книги от кого были получены (правильно ли я понял: от какого поставщика)
Думаю зависит от постановки. Мы можем сделать поставщика и издательство одним лицом, а можем использовать промежуточное лицо. Думаю это не суть важно, просто понятие поставщик в данной ситуации логично. В конце концов книготорговое предприятие может осуществлять поставки и самостоятельно...
сколько каких книг на складе (без учета расхода это не получить!)
Да конечно, потому можно дать вторую часть другому студенту-напарнику
- требуются ли дополнительные заказы на книги (определить стратегию заказа: МЗ, с использованием MRP еще что-то...)
Важный процесс но в нашем контексте можно о нем забыть, мы же не собираемся моделировать все предприятие, а некоторый его кусочек
По остальное. Интересно, но думаю для моего курса это не подъемно, это еще сложнее чем, то, что я использую сейчас. И опять же - мы обсуждаем процесс проектирования в его полной форме, но нет еще у студентов знания, архитектурного решения, опыта работы с БД, знаний ООП и много другого, без чего успешным наше видение не сделаешь.
У меня ощущение, что мы вероятно друг друга слабо понимаем. А главное я ни как не понимаю как объяснить, что же мне нужно. Вроде говорю, говорю, а все равно нет понимания.
Возможно у меня шоры, возможно ты воспринимаешь всю концепцию не так.
Ты пытаешься предусмотреть все моменты, выгоды, прибыль и т.п. Думаю ты прав, так и следует делать, но студенту это вообще-то сложно.
Вот предметы пройденные студентами к моменты начала моего курса:
Алгебра и геометрия
Дискретная математика
Математическая логика и теория алгоритмов
Вычислительная математика
Математический анализ
Вероятность и статистика Функциональный анализ Электротехника и электроника
Метрология, стандартизация и сертификация
Физика
Химия
Информатика Информационные технологии
Архитектура ЭВМ и систем, в т.ч.курсовой проект (*)
Компьютерная геометрия и графика
Статистические метода прогнозирования
Схемотехника
Параллельно со мной идут
функциональное математическое моделирование
Операционые системы
Защита и надежность информации
Теория принятия решений
Экономика - будет только за мной, Технико-экономический анализ в 9 семестер
Понимаешь к чему веду?
-
Вот все-таки опубликую некоторые положения ГОС по ключевым предметам:
Инфоматика
Понятие информации, общая характеристика процессов сбора, передачи, обработки и накопления информации; технические и программные средства реализации информационных процессов; модели решения функциональных и вычислительных задач; алгоритмизация и программирование; языки программирования высокого уровня; базы данных; программное обеспечение и технологии программирования; локальные и глобальные сети ЭВМ; основы защиты информации и сведений, составляющих государственную тайну; методы защиты информации; компьютерный практикум.
Обратите внимание на выделенное красным
Информационные технологии
Содержание новой информационной технологии как составной части информатики; общая классификация видов информационных технологий и их реализация в технических областях; модели процессов передачи, обработки, накопления данных в информационных системах; системный подход к решению функциональных задач и к организации информационных процессов в системах; глобальная, базовая и конкретные информационные технологии; особенности информационных технологий; модели, методы и средства реализации перспективных информационных технологий.
Основы теории управление
Управление и информатика; общие принципы системной организации; устойчивость, управляемость и наблюдаемость; инвариантность и чувствительность систем управления; математические модели объектов и систем управления; формы представления моделей; методы анализа и синтеза систем управления. Цифровые системы управления; использование микропроцессоров и микро-ЭВМ в системах управления; особенности математического описания цифровых систем управления, анализа и синтеза систем управления с ЭВМ в качестве управляющего устройства; программная реализация алгоритмов управления в цифровых системах.
Читают преподаватели других кафедр, в частности кафедры кибернетики и автоматизации химических процессов
Теория информационных процессов и систем
Основные задачи теории систем; краткая историческая справка; терминология теории систем; понятие информационной системы; системный анализ; качественные и количественные методы описания информационных систем; кибернетический подход; динамическое описание информационных систем; каноническое представление информационной системы; агрегатное описание информационных систем. Операторы входов и выходов; принципы минимальности информационных связей агрегатов; агрегат как случайный процесс; информация и управление. Модели информационных систем; синтез и декомпозиция информационных систем; информационные модели принятия решений; возможность использования общей теории систем в практике проектирования информационных систем.
Мой предмет, модели есть - инструментов нет. Интересно что такое каноническое представление ИС - 6 лет искал, нашел когда-то что это представление ИС в виде иерархической модели или просто как строгая иерархия, кого чего? Для себя решил, что это просто представление ИС через виды обеспечения...
Управление данными
Основные понятия банков данных и знаний; информация и данные; предметная область банка данных; роль и место банков данных в информационных системах; пользователи банков данных; преимущества централизованного управления данными; база данных как информационная модель предметной области; система управления базой данных (СУБД); администратор базы данных; архитектура банка данных; инфологическое проектирование базы данных; выбор модели данных; иерархическая, сетевая и реляционная модели данных, их типы структур, основные операции и ограничения; представление структур данных в памяти ЭВМ; современные тенденции построения файловых систем; обзор промышленных СУБД; тенденции развития банков данных.
Интерсно правда? Делаем БД, а моделировать предметную область еще как бы и не научились. Т.е. если я не должен давать в своем предмете это, то где давать моделирование данных, IDEF1x, ERD или что-то подобное?
Моделирование систем
Основные понятия теории моделирования; классификация видов моделирования; имитационные модели информационных процессов; математические методы моделирования информационных процессов и систем; планирование имитационных экспериментов с моделями; формализация и алгоритмизация информационных процессов; концептуальные модели информационных систем; логическая структура моделей; построение моделирующих алгоритмов; статистическое моделирование на ЭВМ; оценка точности и достоверности результатов моделирования; инструментальные средства; языки моделирования; анализ и интерпретация результатов моделирования на ЭВМ; имитационное моделирование информационных систем и сетей.
Если посмотреть программы на основе этогй выдержки ГОС, то мы увидим, каждый вуз трактует это по своему. Я ориентируюсь на учебник Советова Моделирование систем. Правда в настоящий момент данный курс передан функциональному математическому моделирования, а я планирую читать UML. Тут кстати есть резервы для изменения курсов: ТИПиС - читаем основы, приниципы анализа, понятия UML подробно, SADT поменьше. А на следующем курсе попробывать уже именно проектирование-моделирование
Проектирование ИС
Общая характеристика процесса проектирования ИС; структура информационно-логической модели ИС; разработка функциональной модели; исходные данные для проектирования; разработка модели и защита данных; разработка пользовательского интерфейса; разработка проекта распределенной обработки. Структура программных модулей; разработка алгоритмов; логический анализ структур ИС; анализ и оценка производительности ИС; управление проектом ИС; проектная документация; инструментальные средства проектирования ИС; типизация проектных решений; графические средства представления проектных решений; эксплуатация ИС.
Курс 200 часов с курсовой, ведут лекции 2 преподавателя. Один читает скажем формальную часть, дкументирование и т.п. Другой что читает не знаю. Но от меня требуют, чтобы я уже подготовил студентов к сиспользованию SADT, DFD и даже UML. При этом они так в этом уверены, что если я выброшу такую часть из своих курсов, то это будет означать, что народу прийдется в спешном порядке изучать DFD как-то самостоятельно. Боюсь представить что из этого получится...
Содержание моего курса (примерно)
Лекция 1. Понятие информационной системы. Основные процессы преобразования информации. История и направление развития ИС. Классификация ИС (2 часа).
Лекция 2. Типы информационных моделей. Функциональные, структурные, поведенческие, архитектурные модели и модели данных (2 часа).
Лекция 3. Основные задачи системного анализа. Понятие системы как семантической модели (2 часа).
Лекция 4. Классификация систем. Основные определения системного анализа: элемент, среда, подсистема, характеристика, параметр, свойство, закон функционирования, цель, показатель, алгоритм функционирования, качество, процесс, эффективность процесса, критерий эффективности, состояние системы, структура, ситуация, проблема (2 часа).
Лекция 5. Принципы и структура системного анализа. Девять стадий представления систем (2 часа).
Лекция 6. Сущность структурного подхода. Этапы анализа и моделирования информационных систем: сбор и анализ первичной информации, формирование требований, функциональное моделирование (2 часа).
Лекция 7. Методология функционального моделирования IDEF0. Синтаксис и семантика моделей IDEF0. (2 часа).
Лекция 8. Методология функционального моделирования IDEF0. Правила построения моделей IDEF0. Виды диаграмм IDEF0 (2 часа).
Лекция 9. Методология описания процессов IDEF3. Синтаксис и семантика моделей IDEF3. Правила построения моделей IDEF3. (2 часа).
Лекция 10. Моделирование потоков данных (процессов) DFD. Синтаксис и семантика моделей DFD. Правила построения моделей DFD. (2 часа).
Лекция 11. Моделирование потоков данных (процессов) DFD. Словарь данных. Методы задания спецификаций процессов (2 часа).
Лекция 12. Моделирование данных. Рассширенная модель "Сущность - связь" (2 часа).
Лекция 13. Моделирование данных. Методология IDEF1x (2 часа).
Лекция 14. Принципы создания моделй данных. Описание процесса. Построение моделей данных на основе анализа документов (2 часа).
Лекции 15-16. Реляционная модель данных. Основные понятия и определения. Операции над отношениями. Нормализация отношений. Нормальные формы. Синтез отношений (4 часа).
Лекция 17. Нормализация отношений. Нормальные формы (2 часа).
Лекция 18. Назначение информационно-поисковых систем. Состав и структура ИПС. Информационно-поисковые языки. Основные элементы ИПЯ. Требования к ИП. Типы отношений между словами. Типология ИПЯ. (2 часа).
Лекция 19. Дескрипторные языки. Системы индексирования. Поисковый аппарат ИПС. Модели поиска информации (2 часа).
Конечно количесвто часов тут условно, в реальной практике читаю немного иначе, что-то отставлю на сам работу, что-то даю гораздо больше, а что-то меньше
Практически задания примерно следующие, но тоже реальное занчение времени и наполнение несколько иное
Разработка документа «Оценка деятельности рассматриваемой организации» в соответствие с выданным заданием. (6 часов). Неделя №1-3.
Фактически включает общий анализ проблемы, задачи, системы
Функциональное моделирование в AllFusion Process Modeler (BPwin). Построение контекстной диаграммы, диаграммы декомпозиции, дерева узлов (6 часов). Недели №4-6.
Есть не что иное как дополнение к первой, на самом деле все делается в общем вместе циклично
Формирование системной спецификации. Разработка документа «Функциональные требования к разрабатываемой системе» (4 часа). Недели № 7-8.
Построение модели функционирования информационной системы DFD (6 часов). Неделя № 9-11.
Условное название - общая идея показать собственно общий вычислительный процесс, определить потоки, дать им название, структуризировать их
Разработка документа «Бизнес-правила рассматриваемой предметной области» (4 часа) Неделя №12-13.
Разработка инфологической модели рассматриваемой предметной области (6 часа) Недели № 14-16.
Реализация физической модели данных на СУБД MS Access 2000. (2 часа) Неделя № 17.
Разработка прототипа приложения на СУБД MS Access 2000. (4 часа) Неделя № 18-19.
-
мысль моя развивается спонтанно и очень дискретно :-). Поскольку все мысли приходится обдумывать буквально на ходу, между путешествием домой или на работу, либо в паузы между атаками студентов.
Однако хотелось высказать следующее:
Итак, моя выпускающая кафедра принадлежит факультету с названием "Институт финансов, управления и информационных систем". В пору младенчества специальности, из которого мы надо сказать только выбираемся в раннее детство, специальность имела поэтическое название "Информационные системы в управлении". Правда такое название просуществовало всего 2 года. Однако очень показательно как развивалась на мой взгляд идея создания такой кафедры и специальности, пришедшая в свое время молодому доктору наук, актифному профессору мистеру Х :-) Очевидна аналогия с названием факультета и его структурой - кафедра Экономики и Финансов, Высшая математика, мы - скромные имярек - кафедра информатики и вычислительно техники, наконец кафедра мат методов в экономике иил что-то в этом роде. Очевидная подоплека - ИС в экономике, но с уклоном в управление. Вероятно по этой причине возникла одна из дисциплин Основы теории управления (к сожалению не организационно-техническими системами, а системами техническими). Вероятно было бы просто здорово развивать специальность в сторону САПР и т.п., ориентированных на химическую промышленность. Может быть где-то когда-то такая идея и была, но после забыта. А результат остался - ГОС тот, который мы имеем. Оглядываясь на ушедшые годы преподавания на этой кафедре (как сказал, а :) ), у меня складывается общее впечатление, что готовим мы специалистов беспредметников. Плохо ли это или хорошо, не мне пока судить. Однако, хотя и преподается ряд экономических специальностей, я все-таки рискну заявить их ужасно мало, да и читаются они все больше на 4 или 5 курсе. Но много математики всякой разной, много физики и электротехники.
Базам данных посвящен 1 семестр, с этого года слава богу ООП будет уже два семестра, но вводится бакалаврская ступень, а это значит многие дисциплины, читаемые на 4 курсе перемещаются на 5. Вообще 5 курс оказывается пересыщен, а если учесть, что студенты вынуждены выполнять курсовой проект, а потом дипломный, то надо сказать - посещаемость занятий 5 курсом очень слабая.
Если сравнивать специальность с некоторой системой, которая используя ресурсы, под чутким руководством вузовского начальства, должна переварить бравого абитуриента в не менее бравого специалиста ИТ, то безусловно можно задать вопрос, а чем должен обладать данный студент - какими такими знаниями? Уметь хорошо программировать (по ГОС этого не скажешь), быть великолепным аналитиком? (вы меня уже убедили, что скорее всего нет), быть отличным специалистом БД (это мне нравится, в это я веря, все для этого делаю, но на практике к сожалению и тут кажется получается прокол, если учитывать дипломные проекты). Что же получается? А не знаю!!! Всего по немногу. При этом одни говорят нам - нам нужны программисты, учите их программировать на СИ, JAVA, NET, ВАсику, Delphi. Другие говорят - нам нужны специалисты по БД! Третьи - зачем нам ваши программисты, базисты, моделисты, математики и физики - давай нам экономиста с глубоким знанием информационных технологий!!! Кто же нужен?? Друг-приятель как то сказал - студент -выпускник должен решать любую поставленную задачу теме средствами, которые ее решают наиболее качественно и быстро. НО это анимбосибль! Но к этому стоит стремится, что же я полагаю - весь цикл образования специальности направлен на то, чтобы студент-выпускник умел проектировать, разрабатывать и сопровождать ИС. А что есть ИС, мы знаем. Основой всегда будет конечный продукт, то что на выходе, а не то каким образом мы его получали. Эффективность проверяется в конкуренции, конкуренция формирует школу, школа делает имя и специалиста.
Тем не менее, что сегодня? Учитывая, что сделали мы 3 выпуска (а ведь это немного) Могу сказать, что в общем часть работает программистами и главным образом 1эсят. Часть работает вообще не там и не здесь, часть стали большими специалистами ИТ у себя в ... маленьком городке. Некоторые перебрались в Москву, во всю админят, настраивают и прочее локальные сетки.
К чему бы надо стремится? Надо давать некоторую основу, базу. Чисто технологическое обучение может быть опасно. Какую базу давать? Вероятно базу создания ИС, разных не только КИС, но и неориентированных на бизнес и управление.
Если взять за основу жизненный цикл, то видно:
1. Возникновение проблемы - но генерировать проблемы, этому вроед не учат:-)) Проблемы возникают сами.. Но можно учить предвиденью проблем? А как? Сам бы поучился.
2. Анализ проблемы, поиск путей ее решения. Чаще всего это изучение и исследование бизнес-процессов, требований и предметной области в целом. - поиск концепции решения, построение моделей решения и т.п. На чем он базируется, чаще всего нам говорят - это системный анализ, но и исследование операций, математическое моделирование и другие методы и методики. Я вижу обучение этого этапа - как обучение элементарным действиям: сбор информации, интервьюирование, работа с документами, анализ аналогов, морфологический анализ и прочее, прочее. Возможные предметы: все виды матемаики, физика, химия, информатика, основы программирования, ТИПиС, моделирование систем, функциональное мат.моделирование, теория управления, теория принятия решения, представление знаний и т.п.
3.Далее веротяно можно идти к проектированию - Управление данными, отчасти ООП, проектирование, интеллектуальные ИС, всякие теои надежности и защиты, информационные сети
4. Кодированию - Управление данными, ООП, проектирование ИС, СОМ, и другие
5. Развертыванию - Эвм и сети, ос и всякое по
6. Эксплуатации - администрирование ИС, проектирование ИС, защита информации,сети, что то еще....
Я вижу мой предмет входит в область, главным образом анализа проблемы, и то, на ряду с другими. Если быть честным, я бы вообще упразднил это название ТИПИс. Пусть бы это был системный анализ - четко и не двусмысленно, вообще требуется предмет - разработка требований к системам, где действительно целый семестр разжовывать все до усвоения, моделирование данных, всякие UML с РУП. Но к сожалению такой возможности нет, потому приходится размазывать все по предметам, здесь дать широко но не глубоко, там дать узко, но поглубже.
На мой взгляд оптимальным было бы выделение двух специализаций: с углублением аналитической состваляющей в одном случае, а в другом более технологический уклон. НО я не лицо, принимающее решение, я даже не лицо, помогающее принять решение:-))
Так что вывод: давайте действовать не в моем видение задачи, а том, как все-таки надо.
Единственный тезис - научить студента, обущающегося анализировать проблему, понимать суть ее, находить приемлемое решение в ограниченные сроки, с органиченными ресурсами...
-
...
2. Приведенные вами ссылки учебных курсов затрагиваю теорию, а не практику - две совсем разные вещи
Э-э, а я как-то на название предмета ориентировался. Не надо было?
-
Денис, надо надо.
Спасибо за ссылки, это все я, как говорил, видел раньше, просто не доходило все это почитать. А имел я в виду то обстоятельство, что теоретические концепции много раз публиковались и много раз читались и не только на интутите. А вот нормальных практических примеров, разобранных от и до, без купюр практически нет. Чаще всего бывает великолепное начало, а потом раз и все быстренько сворачивается, а потом как чертик из табакерки вылезает решение. Опытный читатель, конечно, догадается, но накой опытному это все читать?
Хотя сегодны пробежался по этим курсам по диагонали - неплохо в целом, дуамаю даже часть курса включу в дисциплину Корпоративные ИС, самое по-моему оно, особенно по бизнес-моделированию.
-
В качестве бредовой идеи: может тогда давать задание не на исследование, а на построение бизнеса
В какой-то степени именно такие примерно задачи и ставились. Фактически придумать бизнес при некоторых условных ограничениях и упрощениях. Разработать документы, посмотреть аналоги, создать свое работающее решение. А модель данных как некоторый инструмент проверки - в том направлении двигаемся или нет?
В результате ролевой игры по списку интересов заинтересованных лиц, ограничениям и правилам из 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 (http://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 процесс работы интернет-магазина??
-
Здрасте. А у меня вопрос на засыпку: как выглядит в IDEF процесс работы интернет-магазина??
Я уже заснул, спасибо.
-
Здрасте. А у меня вопрос на засыпку: как выглядит в IDEF процесс работы интернет-магазина??
А какой IDEF имеется в виду?
-
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=5.msg2441#msg2441
IDEF0, IDEF3.
Дело в том, что это моя курсовая работа, а я почти полны зеро. Подскажите хоть что-нибудь.
-
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=5.msg2441#msg2441
IDEF0, IDEF3.
Дело в том, что это моя курсовая работа, а я почти полны зеро. Подскажите хоть что-нибудь.
Мил человек, я же не знаю КАКОЙ интернет-магазин вы проектируете. Если Вам до фонаря, ну зайти хотя бы на любой сайт интернет-магазина и посмотрите как там это делается.
Можно посмотреть пример в книге Мацяшека: ее можно найти например на сайте www.all-eBooks.com.
Если влом искать, тогда придумывайте сами. Возьмите для начала работу магазина простого, или скажем Книги-почтой. Перенесите ее на свой интернет-магазин.
Основной процесс:
A-0 Продажа чего-то on-line
A1 Управление каталогом товаров
А11 Маркетинговые исследования
А22 Составление каталога
А2 Управление заказами клиентов
А21 Изучение предложения
А22 Выбор товара в корзину
А23 Оформление заказа
А24 Подтвреждение заказа
А25 Выполнение заказа
А3 Управление запасами
А31 Планирование закупок
А32 Заказы на поставку
А33 Отгрузка заказа
Ну что-то в этом роде. Декомпозиция может идти сколь угодно долго, но следует остановится, когда процесс прост или элементарен. Его уже можно описать с помощью IDEF3 сценария
Сначала нужно следовать правилу:
1. построить контекст - А-0 и А0 диаграммы - но для начало неплохо провести анализ постановки задачи и выделить набор возможных функций-действий и данных. Проанализировать список. убрать лишнее, сгруппировать по смыслу
2. Далее идет уже декомпозиция и связывание функциональных блоков.
Начните с построения дерева функций или целей.
Продажа он-лайн - это понятно, посредством каких функций или действий она осуществялется. Таких-то
Управление заказами клиентов - это как? Раскрываем списком. Каждый пункт такого списка раскрываем дальше, если суть действия не совсем понятна или очевидна (например имеет не один выход а несколько) Стремимся к такой декомпозиции, чтобы каждая функция имела один и только один выход. И этот выход должен быть четко понимаем. Например оформление заказа - ясно, что результат - заказ и ничего более, поэтому его можно просто декомпозировать в сценарий IDEF3, т.е. показать последовательность заполнения заказа...