5671

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 06 Февраля 2007, 18:23:39 »

Обслужить посетителя - думаю тут довольно ясно прописан основной ход действия.
Я ограничиваюсь тем, что кафе ориентировано на несложные, но качественные блюда. Количество посадочных мест скажем 5 столиков по 4 человека. Средняя продолжительность пребывания полчаса.
В обслуживание можно добавить отдельным ВИ - скажем обеспечивать торжественные заказы: свадьбы, вечеринки
но думаю для нашего студенческого кафе можно и не рассматривать, если полагать, что кафе располагетсяв учебном корпусе (тут лекции идут а в кафе гулянка:)) Тем более, что горячительные напитки мы исключаем

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

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

Не стал рассматривать деятельность по рекламе, улучшению имиджа кафе, дизайн и прочее.

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

5672

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 06 Февраля 2007, 18:06:52 »

Развитие идеи. Сегодня сидел со воей коллегой 4 часа. Интенсивно обсуждали вопрос моделирования и вот к чему пришли. Прошу судить, делать замечания, ругать и хвалить...

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


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

2. Составить меню. Участники: Повар
Повар составляет меню блюд. Блюда деляться на первые, вторые, салаты, десерт, напитки, выпечка.

3. Составить калькуляцию блюд. Участники: менеджер.
На основании меню, менеджер составляет калькуляцию каждого блюда.

4. Анализировать потребности в продуктах. Участники: менеджер.
Используя калькуляцию блюд, зная средние потребности в продуктах менеждер составляет заказ на закупку продуктов.

5. Закупать продукты. Участники: Закупщик, оптовая база, столовая.
Закупщик на основании заказа на продукты закупает продукты и полуфабрикаты в оптовой базе. Получает деньги у бухгалтера на закупку продуктов. Оптовая база выдает продукты, составляет счет-фактуру (или другой документ). Закупщик доставляет продукты в кафе. Сгружает продукты, отдает бухгалтеру накладную на закупленные продукты.
Выпечка закупается в столовой, с которой есть договор.
Доставку осуществляет закупщик транспортом кафе.

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

7. Предоставлять отчеты и выплаты. Менеджер,Бухгалтер
Менеджер составляет отчеты руководству вуза (где располагается кафе), в налоговые органы.
Бухгалтер рассчитывает выручку, начисляет налоги, фиксирует затраты, начисляет и выплачивает зарплату, выдает деньги на закупку.

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

Вот что получается:

5673

RUP EUP AUP OpenUP / Практика использования RUP. Или бег на месте...

« : 06 Февраля 2007, 10:12:53 »

Уважаемые аналитики. Бизнес-аналитики, системные аналитики. Опытные аналитики и только начинающие. Срочно, просто срочно требуется внятная консультация.

Многие меня на форуме знают. Я не новичок в целом. Но все равно пока не могу "сшить" одно с другим. Прежде чем задать вопрос некоторые мыли по поводу понимания самого процесса RUP и использования ООАП.

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

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

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

Хотелось бы предложить некоторую практическую задачу, для анализа и устранения ошибок.

Задача чисто вымышленная.
Предположим мы с вами организовали небольшой бизнес: скажем маленькое студентческое кафе (такое я видел в Португалии в их техническом универститете): 10 столиков, а то и того меньше, по 4 человека за столик. Относительно разнообразное меню: закуски, вторые блюда, первые блюда, выпечка, десерты, напитки. Пусть для простоты и опрделенности сделаем как это было в Португалии: каждый день кафе анонсирует пять блюд: обычно это рыба в сочетании с разным гарниром и 1-2 блюда с мясом: - это основные блюда. Есть еще супы, но они не анонсируются.
Естественно у нас есть повар с помощниками, кассир, директор, бухгалтер, закупщик продуктов. Это роли. Штат значение не имеет.
Основным бизнес-процессом будет обслуживание клиента, нужно также организовать закупку свежих продуктов, приготовить блюда, решать разные оргвопросы.

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

Начинаем строить контекст, используя инструментраий UML.

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

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

Основным вариантом использования уровня облака или воздушного змея наверное будет "Обслужить клиента", а цель получение прибыли от своей деятельности, очевидно. Если детализировать это процесс, то вероятно можно выделить:
БП1: Накормить клиента - (ДЛ клиент)
БП2: Приготовить блюда - (включается в БП1)
БП3: Закупить продукты - (Дл постащики)
БП4: Оплатить аренду - (ДЛ администрация вуза(бухгалтерия вуза))

БП1: Накормить клиента
1. Клиент изучает меню.
2. Клиент выбирает блюда.
3. Продавец-официант выдает заказанные блюда
4. Кассир расчитывает сумму и выбивает чек
5. Клиент расплачивается разрешенным способом(наличными или кредитной картой)
6. Клиент есть свой обед
7. Клиент относит посуду.

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

Останавлюсь пока на этом, поскольку чувствую что-то не совсем так....

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

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

5674

RUP EUP AUP OpenUP / Re: Глоссарий артефактов и ролей по RUP

« : 06 Февраля 2007, 09:08:59 »

Крэг Ларман. Применение UML и шаблонов проектирования. Издание 2-е и 3-е. Второе издание есть в электронном виде - ищите в файловом архиве.
Кроме того, есть множество и других переводных книг по RUP процессу.
Так же на нашем сайте в файловом архиве посмотрите документ "Бизнес-моделирование". Там есть неплохой перевод артефактов из РУП по бизнес-моделированию

5675

Проектирование / Re: Информационно-справочная система(domain model)

« : 05 Февраля 2007, 18:41:04 »

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

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

Мне интересно решение с помощью диаграммы классов. Будет оно лучше? Проще? Объективнее?
Хотелось бы конечно сразу "пощупать решение". Возможно с использованием той же МДА технологии.

5676

Сообщество Аналитиков / Ваше базовое образование

« : 05 Февраля 2007, 12:15:48 »

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

5677

Проектирование / Re: Информационно-справочная система(domain model)

« : 05 Февраля 2007, 12:05:04 »

! Теперь о тебе! Вспомним известное: не судите да не судимы будите! Профессор не спешите мне ставить двойки! Ну поехали! 

Да не сужу я, не сужу. И двойки не ставил, а тройку:) И то с умыслом:-) Умысел удался..

“Здание” пришлось бы квалифицировать.  Номера и наименование корпусов, в общем случае, уникальны только в пределах одного ВУЗа, а не на всем множестве. Я не прав?

Да прав,конечно. Только чем тебя например не устраивала ассоциация без квалификатора?

Квалификаторы ставятся  у того конца ассоциации, который соединен с понятием, в пределах которого осуществляется квалификация.  Номер и наименование здания уникальны в пределах ВУЗа. Вот так следует читать данную квалифицированную ассоциацию. Хочу заметить что, это придумал не я,  это Буч, Рамбо, Якобсон. Троечники что скажешь 

да нечего сказать, только признать свою не правоту...

Оба понятие “Должность” и “Подразделение” специализируют понятие “Абонент”.  Пользователь требует все телефоны деканата, кто в этом случае абонент? Пользователь требует телефон декана, кто абонент? “Должность” это класс-ассоцициации. Сотруднику не соответствует номер телефона, он соответствует должности. Неважно где сидит Иванов. Важно где сидит декан.

Могет быть, могет быть

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

Т.е. когда мы делали сие приложение мы исходили из этого факта. А остальное просто навешивали к помещению. При этом, так же держали в голове и реализацию. Возможно не совсем корректный подход

5678

Проектирование / Re: Информационно-справочная система(domain model)

« : 04 Февраля 2007, 11:19:01 »

Вот и диаграмма

Slav, привет! Не понял логику использования квалификаторов.

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

Аналогично связь здание - помещение.

Стрелка около абонента не понятна. Должность или подразделение расширяет понятие абонента?

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

И потом телефон все-таки закреплен за помещением, а недолжностью или человеком. конечно, скажем ректор переехал в другой кабинет и забрал телефон. Ясно что телефон служит человеку. Но телефон и помещение - понятия родственные - из физического мира.
А должность, подразделение и т.п. - понятия абстрактные.

В общем SLAV - только тройка:-). В n-арных задачах  ты был великолепен, а тут что-то не так

5679

Проектирование / Re: Информационно-справочная система(domain model)

« : 03 Февраля 2007, 16:46:17 »

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

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

Вообще, когда задавался вопрос про то, как в принципе система позволит узнать ФИО сотрудника, я хотел увидеть аналитический сценарий (use-case description), а не набор хаотических идей по организации интерфейса системы

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

Узнать ФИО - это цель типа А, так?

Ну можно так сказать...

Про "набор непротиворечивой информации" не понял - к чему это?

Есть некия массив данных, который описывает некоторого человека - он непротиворечив

"фио у него то ли Басков, то ли Белкин" - это пахнет нечётким поиском, SOUNDEX, а не поиском по подстроке.

Естественно, предполагается, что выдается некоторая учебная информация о возможности организации поиска. есть понятие маски поиска, шаблона поиска, есть примеры использования такого поиска. Реально ФИО разделено на три поля Ф И О, для гибкости запросов

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

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

Должна ли система помогать в цели А, если единственное, что ты помнишь о человеке - это пол и то, что ты его встречал в северном крыле?

Такая задача никогда не ставилась, как явно не достижимая

На тему поиска и построения общих поисковых систем (не обязательно веб-поисковых), рекомендую книгу Ambient Findability и связанные статьи.

Спасибо за ссылки, но думаю пока особой проблемы нет.

Возможно, это моя ошибка. Я не довел цель задачи. Хотя я думаю многие ее поняли именно так, как я ее задумывал. Есть некоторое решение с использованием структурных методов. Модель прилагалась.
Задача заключалась в том, как подобная модель могла бы выглядеть, если ее строить как диаграмму классов.

Вероятно стоит указать проблему, которая возникала. А возникла проблема при выполнении запросов, которая приводила к дублированию записей, вернее к потери семантики информации.

Т.е. к примеру у нас есть
Завкаф Сидоров Профессор к.10 корпус Г
и для него же
Декан Сидоров Профессор к. 15 корпус А

Результат был для исходной модели
Завкаф Сидоров Профессор к.10 корпус Г
Завкаф Сидоров Профессор к.15 корпус А
Декан Сидоров Профессор к. 15 корпус А
Декан Сидоров Профессор к. 10 корпус Г

Решение проблемы были реализовано через образование связи между Помещением и Должностью и разрывом связи между Должностью и Сотрудником, ну и другие дополнения. Т.е. пришлось нарушить строгую орагнизацию (как мы ее понимали), а контроль целостности возложить на рнр скрипт, тем более в mysql именно так часто и делают, теряя бизнес-логику на стороне сервера и приобретая большее быстродействие.
Но говорю решений ведь может быть много, наше не идеальное, как говорится сумели, так и сделали. Надеюсь не совсем по дилетански:-))

5680

Проектирование / Re: Информационно-справочная система(domain model)

« : 02 Февраля 2007, 22:52:09 »

Хорошо, я хочу узнать ФИО сотрудника. Как в принципе система позволит это мне сделать?

Элементарно Ватсон!
Система содержит набор непротиворечивой информации, отображающая данные о некой личности на предприятии.

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

5681

Проектирование / Re: Информационно-справочная система(domain model)

« : 02 Февраля 2007, 19:17:53 »

Ну хорошо.
Тогда давай начнем сначала: каковы цели пользователя достигаемые с использованием информационно-справочной системы?

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

5682

Проектирование / Re: Информационно-справочная система(domain model)

« : 02 Февраля 2007, 17:57:31 »

Отличные диаграммы!

Для цели поиска человека понятие должность, вообще не нужно (ИМХО).

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

5683

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 02 Февраля 2007, 17:41:58 »

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

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

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

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

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

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

5684

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 02 Февраля 2007, 17:39:26 »

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

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

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

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

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

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

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

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

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

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

5685

ПО Аналитика / Re: Оценка CASE интсрументов

« : 02 Февраля 2007, 17:28:14 »

Это викторина называется - "оцени свое CASE тулз". Т.е. берешь эти критерии, свой инструмент и оцениваешь по 5 бальной шкале, умножаешь на вес и суммируешь оценки, получешь цифру, потом если сделают так несколько человек, то можнобудет сравнить КАСЕ тулзы.

Саш, а может ты сделаешь по своим критериям опросник - как это сделал Boatman. С указанием баллов верно не получится, но это уже каждый вычислит для себя сам. Правда сейчас только подумал а как этот опросник увязать? Только если сделать несколько опросников для каждой системы