5431

Обучение / Система складского учета

« : 17 Апреля 2007, 19:15:43 »

Система складского учета - программная система, затрагиваю¬щая все аспекты, связанные с движением товара на склад и со скла¬да. По результатам анализа можно выделить семь основных функций системы.
Функция системы                                    Описание
Учет заказов            Прием заказов от клиентов и ответы на запросы клиентов о состоянии заказов
Ведение счетов         Направление счетов клиентам и отслеживание плате¬жей. Прием счетов от
                                     поставщиков и отслеживание платежей, направляемых поставщикам
Отгрузка со склада  Составление спецификаций на комплектацию отправляемых со склада клиентам
Складской учет         Постановка прибывающих товаров на учет и снятие товаров с учета при       
отправке  заказов
Закупки                    Заказ товаров поставщикам и отслеживание поставок
Получение               Принятие на склад товаров от поставщиков
Планирование          Выпуск отчетов, в том числе отражающих тенденции
                                      спроса на отдельные виды товаров и активность постав¬щиков
В качестве части стратегии компании, занимающейся торговлей по каталогам, по проникновению на новые участки рынка было ре¬шено создать ряд относительно автономных региональных складов продукции. Каждый такой склад несет ответственность за учет това¬ров и выполнение заказов. В целях повышения эффективности сво¬ей работы склад обязан сам поддерживать ту номенклатуру товаров, которая в наилучшей степени соответствует потребностям местного рынка. Номенклатура может быть разной для каждого региона и должна оперативно меняться в соответствии с потребностями кли¬ентов. Головная компания хотела бы иметь на всех складах одинако¬вую систему учета.
Основными функциями системы являются:
•   учет товаров, приходящих от разных поставщиков, при приеме их на склад;
•   учет заказов по мере поступления их из центральной удаленной организации; заказы также могут приниматься по почте. Их обра¬ботка ведется на местах;
•   генерация указаний персоналу, в частности, об упаковке товаров;
•   генерация счетов и отслеживание оплат;
•   генерация запросов о поставке и отслеживание платежей поставщикам.
Кроме автоматизации стандартных складских операций си< также должна предоставлять богатые возможности по генерации различных форм отчетности, в том числе отражающих тенденции развития рынка, списков наиболее надежных и ненадежных поставщиков и клиентов, материалов для рекламных кампании.

5432

Обучение / Служба занятости в рамках вуза

« : 17 Апреля 2007, 19:15:11 »

Система предназначена для того, чтобы помочь студенту устро¬иться на работу уже в процессе обучения его в вузе. Подав заявление в систему, студент становится ее клиентом и начинает обслуживать¬ся на протяжении всего обучения в вузе. Заявление представляет со¬бой анкету. Система предлагает профессиональные (основанные на изучаемых предметах) психологические тестирования, проводимые регулярно (раз в семестр (полгода)). Особое внимание уделяется обучению студента, по итогам успеваемости составляются эксперт¬ные оценки. На основе собранной информации составляется резю¬ме, представляющее собой полную характеристику человека, и рас¬сылается всем организациям, имеющим необходимые вакансии.
Основным назначением системы являются автоматизация ввода и хранения отчетных данных о студентах, составление характеристик и резюме, поиск вакансий в фирмах. Система позволяет изменять, дополнять, вести поиск и просмотр информации о студентах, накладывать ограничения доступа к системе, хранить списки студентов, окончивших обучение, в виде архива, контролировать выдачу студенту заданий на курсовые работы и проекты, связывать институт с фирмами, заинтересованными в поиске сотрудников.
Данная система также может быть использована для составления отдельных списков групп, печати зачетных ведомостей и полной ба¬зы данных, для статистики.
Система состоит из четырех подсистем:
•   контроля за успеваемостью студентов;
•   профессиональных и психологических тестов;
•   обработки запросов, определения категорий полномочий поль¬зователей;
•   экспертных оценок.
Подсистема "Контроль успеваемости студентов" отвечает за ста¬тистическую отчетность по успеваемости отдельного студента, груп¬пы или целого факультета, а также за хранение и правильность ее ввода.
Входными данными подсистемы являются: оценки, даты сдачи экзаменов, имена студентов, номера групп, факультет. На выходе подсистема выдает обработанные данные: средний балл по студенту, группе или факультету, процентное соотношение оценок у студента в группе или на факультете, имена и количество стипендиатов в группе или на факультете. Подсистема "Контроль успеваемости сту¬дентов" может функционировать отдельно от всей системы, что дает возможность установить и использовать ее независимо, если это не¬обходимо.
Подсистема "Контроль успеваемости студентов" включает следу¬ющие функции:
•   ввод, вывод и редактирование информации по информацион¬ным объектам подсистемы;
•   сохранение информации, поступившей от подсистемы "Кон¬троль успеваемости студентов";
•   расчет процентного соотношения оценок у студента в грунт или на факультете и вывод его в виде таблиц, графиков и диаграмм;
•   расчет среднего балла по студенту, группу или факультету;
•   формирование данных по студенту, группе или факультету;
•   выявление сильнейших и слабейших студентов в группе или на факультете;
•   расчет количества стипендиатов в группе или на факультете;
•   проверку правильности ввода данных.
Подсистема обработки запросов, определения категорий поль¬зователей предназначена для определения категории, полномочий и Обработки запросов пользователей службы занятости. В частности, она выполняет следующие функции:
•   регистрацию новых фирм;
•   регистрацию новых студентов;
•   определение прав доступа зарегистрированного пользователя;
•   обработку запросов;
•   прием регистрационных данных от фирм, студентов и обслу¬живающего персонала;
•   составление резюме;
•   запись данных в БД студентов, фирм и зарегистрированных пользователей.
В соответствии с выполняемыми функциями система работает со следующими сведениями:
•   регистрационными данными студентов и фирм;
•   личными данными студентов;
•   информацией о студентах (получаемой фирмами);
•   информацией о фирмах (получаемой студентами);
•   идентификационными данными пользователей;
•   информацией о системе;
•   запросом;
•   служебной информацией (для обслуживающего персонала);
•   результатами психологического и профессионального тестов;
•   экспертными оценками.

5433

Обучение / Магазин проката видеопродукции

« : 17 Апреля 2007, 19:14:41 »

Магазин проката видеопродукции нуждается в компьютеризо¬ванной системе учета, так как его ассортимент составляют около 1000 видеокассет и 500 видеодисков. Запас уже заказан у поставщи¬ка, однако директор намерен прибегать к услугам большего числа поставщиков. Все видеокассеты и диски снабжены штрих-кодом, так что сканер, интегрированный в систему, может поддерживать операции выдачи напрокат и возврата видеофильмов. Членские кар¬точки клиентов также снабжены штрих-кодом.
Клиенты имеют возможность резервировать видео таким обра¬зом, чтобы комплект видеофильмов был собран к определенной да¬те. Система должна обладать поисковым механизмом для ответов на запросы клиентов, включая вопросы, касающиеся фильмов, кото¬рых нет в ассортименте магазина (но которые он может заказать по просьбе клиента).
Для каждого фильма установлен конкретный период проката (исчисляемый в днях) с соответствующей платой за прокат за этот период.
Видеомагазин должен быть в состоянии немедленно дать ответ на любой запрос по наличию фильмов в запасе, а также количеству кассет или дисков (текущие условия по каждой ленте и диску долж¬ны быть известны и зафиксированы).
Плата за прокат отличается в зависимости от ви кассета или диск.
Хотя магазин держит в запасе видеодиски только одно1. та DVD, пользователи желали бы расширить в будущем систему про ката и на диски других форматов.
Работники видеомагазина стремятся запомнить коды наиболее популярных лент. Зачастую при идентификации фильма они используют именно код фильма, а не его название (поскольку фильм с одним названием мог выпускаться разными режиссерами).
Дополнительные требования:
•   за кассеты и диски, возвращенные позже указанного срока, взимается дополнительная плата за период, превышающий срок проката. Каждый видеоноситель обладает уникальным идентифика¬ционным номером.
Фильмы заказываются у поставщика, который может поставить кассеты и диски в течение недели. Обычно делается один заказ на несколько фильмов.
Забронировать можно те фильмы, которые заказаны у постав¬щика и/или все копии которых находятся в прокате, а также филь¬мы, которых нет в запасе и которые не заказаны у поставщика; при этом с клиента требуется задаток за один период проката.
Клиент может также сделать несколько предварительных зака¬зов, однако для каждого забронированного фильма нужно подгото¬вить отдельный запрос на бронирование. Бронирование может быть отменено из-за того, что клиент не проявил никакой реакции в тече¬ние недели, прошедшей с момента, когда ему сообщили о возможно¬сти взять фильм напрокат. Если за фильм был уплачен задаток, он записывается на счет клиента.
База данных хранит традиционную информацию о поставщиках и клиентах, т.е. адреса, телефонные номера и т.д. В каждом заказе по¬ставщику указываются заказываемые фильмы, их количество, фор¬мат кассеты/диска, а также дата ожидаемой доставки, отпускная це¬на, возможные скидки и т.д.
Когда кассета возвращается клиентом или поступает от постав шика, работники магазина в первую очередь обслуживают клиентов, сделавших предварительный заказ. Для правильной обработки бро¬нирования фильмов информация, связанная с бронированием, об¬новляется дважды: после установления контакта с клиентом, когда ему сообщается, что "забронированный фильм пришел", и после сдачи фильма клиенту напрокат. Эти шаги гарантируют правильное проведение операции бронирования.
Клиент может взять несколько кассет или дисков, однако каждо¬му взятому видеоносителю ставится в соответствие отдельная за¬пись. Для каждого выдаваемого напрокат фильма фиксируются дата и время выдачи, установленный и фактический срок возврата. Поз¬же запись о прокате обновляется, чтобы отразить факт возврата ви¬деофильма и факт окончательного платежа (или возврата денег). Кроме того, запись хранит информацию о продавце, отвечающем за прокат фильма. Детальная информация о клиенте и по прокату хра¬нится в течение года, чтобы можно было легко определить уровень доверия к клиенту. Старая информация по прокату сохраняется в те¬чение года в целях проведения аудита.
Все операции выполняются с использованием наличности, эле¬ктронного перевода денег или кредитных карточек. От клиентов тре¬буется внести плату за прокат при выдаче кассет/дисков.
Если кассета/диск возвращены позже установленного срока (или не могут быть возвращены по каким-либо причинам), плата снимается либо со счета клиента, либо принимается непосредствен¬но от клиента.
Если кассета/диск задержаны более чем на два дня, клиенту от¬правляется уведомление о задержке. После отправки двух уведомле¬ний о задержке одной и той же кассеты/диска клиент получает пре¬дупреждение о том, что он является "нарушителем" и при следую¬щем обращении его в магазин руководство будет рассматривает вопрос о снятии с него статуса "нарушителя".

5434

Обучение / Интернет-магазин

« : 17 Апреля 2007, 19:14:18 »

Производитель компьютеров предлагает приобретать свою про¬дукцию через интернет. Клиент может выбрать компьютер на Web-странице производителя. Компьютеры подразделяются на серверы, настольные и портативные. Заказчик может выбрать стандартную конфигурацию или построить требуемую в диалоговом режиме. Компоненты конфигурации (такие, как оперативная память) пред¬ставляются в виде списка для выбора из доступных альтернатив. Для каждой новой конфигурации система может подсчитать цену.
Для того чтобы оформить заказ, клиент должен заполнить ин¬формацию по доставке и оплате. В качестве платежных средств до¬пускается использование кредитных карточек или чеков. После вво¬да заказа система отправляет клиенту по электронной почте сообще¬ние, содержащее подтверждение получения заказа вместе с относящимися к нему деталями. Пока клиент ожидает доставку ком¬пьютера, он может проверить состояние заказа в любое время в диа¬логовом режиме. Серверная часть обработки заказа состоит из зада¬ний, необходимых для проверки кредитоспособности и способа рас¬чета клиента за покупку, истребования заказанной конфигурации со склада, печати счета и подачи заявки о доставке компьютера клиен¬ту на склад.
Дополнительные требования:
•   для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент исполь¬зует web-страницу интернет-магазина. При этом также приводится цена конфигурации;
•   клиент выбирает детали конфигурации, с которыми он хочет ознакомиться и, возможно, купить готовую или составить более под¬ходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требованию пользователя;
•   клиент может выбрать вариант заказа компьютера по интернету либо попросить, чтобы продавец связался с ним для объяснения де¬талей заказа, договорился о цене и тому подобном, прежде чем заказ будет фактически размешен;
•   для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек);
•   после ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее подробное описание заказанной конфигурации;
•   детали сделки, включая номера заказа и счета клиента, отправ¬ляются по электронной почте клиенту, так что заказчик может про¬верить состояние заказа по интернету;
•   склад получает счет-фактуру от продавца и отгружает компью¬тер клиенту.

5435

Обучение / Система начисления заработной платы

« : 17 Апреля 2007, 19:13:55 »

Перед информационной службой компании поставлена задача создания новой системы начисления заработной платы взамен мо¬рально устаревшей существующей системы. Новая система должна предоставлять служащим возможность записывать электронным способом информацию из карточки учета рабочего времени и авто¬матически формировать чеки на оплату, учитывающие количество отработанных часов и общий объем продаж (для служащих, получа¬ющих комиссионное вознаграждение).
Новая система должна предоставлять служащим возможность вводить информацию из карточки учета рабочего времени и заказы на поставку, изменять свои параметры (такие, как способ оплаты за работу) и формировать различные отчеты. Система должна работать на персональных компьютерах служащих всей компании. В целях обеспечения безопасности и аудита служащие должны иметь воз¬можность доступа и редактирования только своих собственных кар¬точек учета рабочего времени и заказов на поставку.
В системе должна храниться информация обо всех служащих компании, в том числе работающих в различных странах. Система должна обеспечивать правильную и своевременную оплату труда каждого служащего в соответствии с указанным им способом. Ком¬пания из соображений экономии расходов желает сохранить без из¬менений одну из существующих баз данных (БД управления проек¬тами), которая содержит всю информацию относительно проектов и тарифов. База данных управления проектами функционирует в сре¬де DB2 на мейнфрейме IBM. Новая система может читать данные из БД управления проектами, но не может обновлять их.
Некоторые служащие получают почасовую заработную плату, которая начисляется на основе карточек учета рабочего времени, каждая из которых содержит дату и количество часов, отработанных в соответствии с конкретным тарифом. Если какой-либо служащий отработал вдень больше 8 ч, сверхурочное время оплачивается с ко¬эффициентом 1,5. Служащие-почасовики получают заработную плату каждую пятницу.
Некоторые служащие получают фиксированный оклад, однако они тоже представляют свои карточки учета рабочего времени. Бла¬годаря этому система может вести учет количества часов, отработан¬ных в соответствии с конкретными тарифами. Такие служащие полу¬чают заработную плату в последний рабочий день месяца.
Некоторые из служащих, получающих фиксированный оклад, также получают комиссионное вознаграждение, учитывающее объ¬ем продаж. Они представляют заказы на поставку, отражающие дату и объем продаж. Процент комиссионного вознаграждения опреде¬ляется индивидуально для каждого служащего и может составлять 10%, 15, 25 или 35%.
Одной из наиболее часто используемых возможностей новой си¬стемы является формирование различных отчетов: запросить коли¬чество отработанных часов, суммарную заработную плату, оставше¬еся время отпуска и т.д.
Служащие могут выбирать способ оплаты за работу и получать свои чеки на оплату по почте, на счет в банке или на руки в офисе.
Администратор системы ведет информацию о служащих. В его обязанности входят ввод данных о новых служащих, удаление дан¬ных и изменение любой информации о служащем, такой, как имя, адрес и способ оплаты, а также формирование различных отчетов для руководства.
Приложение начисления заработной платы запускается автоматически каждую пятницу и в последний рабочий день месяца расчета в эти дни заработной платы соответствующих служащих. Начисление заработной платы должно проводиться автоматически, ручного вмешательства.

5436

Обучение / Структура курсового проекта

« : 17 Апреля 2007, 19:13:10 »

Курсовой проект должен состоять из четырех глав и заключения.
Первая глава "Постановка задачи" должна содержать формули¬ровку задания.
Вторая глава "Анализ требований" должна содержать глоссарий, диаграмму вариантов использования, описания действующих лиц и вариантов использования.
Третья глава "Анализ системы" должна содержать диаграммы взаимодействия между объектами (последовательности и кооперативные), соответствующие потокам событий вариантов испо и.юва-ния. При необходимости можно включить диаграммы деятельности и сопроводить их пояснениями, указывающими, какому потоку со¬бытий они соответствуют (если это не ясно из их названия), и ком¬ментариями.
Четвертая глава "Проектирование" должна содержать иерархию классов системы и описание пакетов. Для каждого класса системы дается описание, которое включает: ответственность класса, описа¬ние атрибутов в виде таблицы из трех столбцов: имя, описание, тип; таблицу с описанием операций (имя, описание, сигнатура). Должны быть приведены диаграммы классов системы, отображающие связи между классами, и диаграммы состояний, описывающие поведение экземпляров отдельных классов. Также приводится диаграмма раз¬мещения с комментариями. Если вариант предполагает создание схемы базы данных, то такая схема также должна быть включена в отчет.
В заключение должен быть подведен итог и оценены результаты работы.

5437

Обучение / МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО КУРСОВОМУ ПРОЕКТИРОВАНИЮ

« : 17 Апреля 2007, 19:12:42 »

ТЕМАТИКА КУРСОВОГО ПРОЕКТА И ЗАДАНИЯ ПО ЕГО ВЫПОЛНЕНИЮ
Тематика курсового проекта ориентирована на разработку систе¬мы для решения конкретных прикладных задач в заданной предмет¬ной области.
Основное задание курсового проекта - это построение моделей ПО с помощью инструментального средства Rational Rose. Процесс создания модели состоит из нескольких этапов.
Этап   1. Составление глоссария проекта.
Этап  2. Создание модели вариантов использования.
Этап  3. Анализ вариантов использования.
Этап  4. Проектирование системы.
Процесс создания модели должен проходить так, как это описа¬но в настоящем практикуме. Структура модели в браузере Rose должна соответствовать структуре, предусмотренной технологией Rational Unified Process.
После выполнения третьего этапа модель должна удовлетворять следующим требованиям:
•   глоссарий проекта должен иметь вид таблицы и храниться в отдельном файле;
•   на диаграммах вариантов использования каждое действующее лицо и вариант использования должны сопровождаться описанием.

Описание действующего лица должно коротко (в одну-две строки) характеризовать роль данного лица. Описание варианта использова¬ния должно включать пояснение, предусловие, потоки событий (ос¬новной и альтернативные, если таковые имеются) и постусловие. Описания представляют собой либо присоединенные текстовые файлы, либо текст, введенный в поле Documentation спецификации соответствующего элемента диаграммы;
•  диаграммы взаимодействия, соответствующие потокам собы¬тий вариантов использования, должны содержать необходимые по¬яснения.
При проектировании системы требуется:
•   создать иерархию классов системы;
•   разместить классы по пакетам (в зависимости от постановки задачи);
•   связать объекты с классами, сообщения на диаграммах взаимо¬действия - с операциями;
•   сопроводить кратким описанием каждый класс (обязанности класса), описанием атрибутов в виде таблицы (имя, описание, тип) и таблицей с описанием операций (имя, описание, сигнатура);
•   указать стереотипы для классов;
•   построить диаграммы классов системы, отображающие связи между классами;
•   построить диаграммы состояний для описания поведения объ¬ектов отдельных классов;
•   разработать (если требуется) схему базы данных и отобразить ее на диаграмме "сущность-связь".
Следует также разработать диаграмму размещения. В зависимос¬ти от варианта задания диаграмма размещения должна показывать расположение компонентов в распределенном приложении.

5438

Обучение / Анализ задач для моделирования и проектирования

« : 17 Апреля 2007, 19:12:06 »

Хочу предложить набор задач от Вендрова для анализа и возможной их адаптации (а может быть оставить без изменения) для курса ООМАП

5439

Системный Анализ и Требования / Re: Потерянные требования

« : 17 Апреля 2007, 17:44:45 »

Тогда повторюсь

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

Читая вашу беду, сразу подумал о Вигерсе и о его примерах в книге, тут вот сделал перевод его примеров, ну а саму книгу найдете думаю.

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

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

Набор бизнес правил тоже очень полезен - поскольку определяет условия, ограничение, правила проверки и т.п.

Кроме того используя Visio, или Enterprise Architect, или Visual Paradigm CE, Access наконец можно разработать сразу концепции форм и трассировать их к тем элементам данных в словаре, модели данных, правилам и ограничениям.

5440

Сообщество Аналитиков / Re: Ваши проблемы и задачи

« : 17 Апреля 2007, 17:43:01 »

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

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

Читая вашу беду, сразу подумал о Вигерсе и о его примерах в книге, тут вот сделал перевод его примеров, ну а саму книгу найдете думаю.

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

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

Набор бизнес правил тоже очень полезен - поскольку определяет условия, ограничение, правила проверки и т.п.

Кроме того используя Visio, или Enterprise Architect, или Visual Paradigm CE, Access наконец можно разработать сразу концепции форм и трассировать их к тем элементам данных в словаре, модели данных, правилам и ограничениям.

5441

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 17 Апреля 2007, 17:24:49 »

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

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

5442

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 17 Апреля 2007, 17:18:03 »

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

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

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

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

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

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

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

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

5443

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 17 Апреля 2007, 12:10:24 »

Можно и мне немного поучаствовать?

You are welcome

А какой курс, если не секрет? вроде бы 3 или 4 ? Народ будет экзамен сдавать или зачет?
насколько серьезно, вы планируете их "мучать" на зачете (экзамене)?

3 курс. Был уже предмет, где я их "мучил" Idef. Были экзамены.
На данном предмете экзамен. Все очень просто - никаких мучения. Экзамен письменный. Задачки на моделирование. Задачки мелкие и абсолютно конкрентные. Написать сценарий ВИ, сделать диаграмму, выделить классы, и т.п.

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

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

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

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

а как, кстати, с литературой у студентов? есть что почитать? или только желания нет?

Масса литературы - правда в электронном виде. Но практически не читают, не читают даже разжеванные примеры....

5444

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 16 Апреля 2007, 20:55:39 »

как видите, я ленив (мне лень даже разрывать и копировать Ваши сообщения на куски, т.к. это проблема программиста написавшего движок сайта)

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

5445

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 16 Апреля 2007, 20:18:22 »

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

Пусть в ходе выявления бизнес-требований был предложен такой ВИ:

Принять товарно-материальную ценность (ТМЦ)
1. Поставщик привозит ТМЦ и сопроводительные документы (счет-фактуру)
2. Кладовщик на основании счет-фактуры поставщика оприходует ТМЦ.
3. Кладовщик подписывает счет-фактуру и создает документ "Приход ТМЦ".
4. Поставщик идет в бухгалтерию.
5. Бухгалтер на основании подписанной кладовщиком счет-фактуры и, руководствуясь договором, выписывает счет на получение денег.
6. Поставщик со счетом идет в кассу.
7. Кассир выдает требуемую сумму и создает "расходный ордер".

Согласно моему пониманию я описал ВИ уровня бизнеса в стиле прозрачный ящик. Уровень обобщенный (могу ошибаться - просьба поправить)

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

Очевидно, что Приход ТМЦ и Расходный Ордер  наследники абстрактного класса Документ с конкретной реализацией методов проводки, изменения состояния, записей в регистры, журналы операций и т.п.

Элементы документа могут быть справочниками, каждый из которых в свою очередь наследник некого класса Справочник

Вот и интересно как наиболее оптимально тут действовать? Имеет ли смысл создавать независмую модель? Не увеличивает ли это трудоемкость? И вообще применима ли технология UML или вернее имеющихся процессов разработки, ориентированных на UML, в реализации проектов на 1С? Или требуется идти совсем другим путем?