Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Gordon от 22 Марта 2009, 23:01:17
-
Первым постом хочу выразить искреннюю благодарность всему Сообществу Аналитиков за предоставленные мне, да и не мне одному, Знания по Анализу и Проектированию.
Не сочтите за рекламу: Наша компания, http://spo.tyumen.ru, занимается Свободным Программным Обеспечением, СПО.
Увиденное мною разделение, на этом форуме, на бесплатные семинары, включая подробный разбор полетов в этой теме, и платные услуги по Анализу и Проектированию полностью соответствует философии СПО.
Цели, с которой я создал эту тему:
1. Овладение практическими навыками по анализу и моделированию бизнес-процессов с помощью UML.
2. Принять за объект анализа и моделирования ИС Катрин-такси, разрабатываемую нашей компанией под лицензией GPLv.2.
3. Создать, с помощью местных гуру, достойный пример ИС.. :)
За основу своего примера я взял курсовую работу, пользователя Наташа, "Автоматизация книжного магазина", из соседней темы: http://www.uml2.ru/forum/index.php?topic=286.0. За что ей и всем учавствовавшим в обсуждении большой привет!
Самую последнюю версию модели вы всегда сможете увидеть по адресу http://katrin.distance.ru/wiki/Taxi
-
Начальные затраты
На данный момент вхождение на рынок пассажирских перевозок требует относительно-больших затрат:
* Рекламная компания: объявления в радио, газеты.
* Помещение для диспетчеров: покупка или аренда офиса.
* Оборудование для связи с водителями: покупка и монтаж радиостанции или сервера.
* Информационная Система: разработка или покупка и последующее внедрение ИС.
* Сотрудники: диспетчеры, водители с личными автомобилями и, в зависимости от типа используемой связи, рациями или современными мобильными телефонами.
-
Описание процесса
Клиент звонит в компанию, диспетчер принимает заявку и определяет первого, стоящего в очереди, водителя, в районе посадки.
Следующие алгоритмы работы компании зависят от используемого типа связи между диспетчерами и водителями.
Для того, чтобы встать в очередь на ближайшем районе, водитель произносит в эфир приветствие, свой позывной номер и район местонахождения либо отмечает в мобильном клиенте свой статус в "свободен" и район местонахождения.
Учет очередности водителей может вестись как Информационной Системой, с помощью мобильных клиентов, где водители отмечают свое местонахождение; либо в ручную, диспетчерами, с помощью металлического табло и намагниченными фишками, с нанесенными на них позывными номерами водителей, если компания для связи сотрудников использует радиостанции.
После определения первого в очереди водителя, в случае использования для связи радиостанции, диспетчер вызывает его по рации, с помощью позывного номера, и диктует адрес посадки пассажира, после чего водитель должен повторить адрес и подтвердить принятие заказа.
Если водителей поблизости от адреса посадки нет, то статус заказа считается "непринятый", и он оглашается через определенные промежутки времени в эфир. Любой водитель, желающий взять "непринятый" заказ, может это сделать назвав в эфир свой позывной и адрес посадки заказа.
В случае использования ИС диспетчер вводит следующие данные о заказе: адреса посадки и доставки, время подачи машины и цена поездки, если в ИС присутствует функционал расчета поездки. После ввода, ИС скидывает на мобильный телефон, первого в очереди водителя, информацию о заказе. Водитель должен либо принять заказ, тогда он должен указать время через какое он доедет до клиента, либо отказаться, тогда ИС скидывает заказ следующему в очереди водителю.
Если водителей поблизости от адреса посадки нет, то статус заказа считается "непринятый", и он помещается в специальное меню, в которое можно попасть с помощью мобильного клиента. Любой водитель, желающий взять "непринятый" заказ, может это сделать зайдя в меню "непринятых" заказов в мобильном клиенте, выделить его и нажать на кнопку ввода. После чего ему надо будет указать время, через какое он приедет к адресу посадки.
После подачи машины по адресу посадки, водитель сообщает диспетчеру по рации, либо отмечает в мобильном клиенте, с помощью смены состояния на "подъехал", о своем прибытии. Диспетчер перезванивает клиенту и сообщает о подаче машины, либо ИС скидывает с помощью СМС информацию о подаче машины если телефон клиента мобильный или проигрывает запись с сообщением о подаче машины, если телефон клиента стационарный/городской.
После посадки клиента, водитель сообщает в эфир свой позывной номер и то, что он посадил пассажира(ов) либо меняет в мобильном клиенте свое состояние на "в пути".
После приезда на адрес доставки клиент оплачивает поездку в сумме:
* Стоимость проезда по маршруту, по действующим тарифам, +
* Стоимость подачи машины на время, по действующим тарифам, +
* Стоимость ожидания клиента возле адреса посадки, первые 10 минут бесплатно, остальные по действующим тарифам, +
* Стоимость ожидания, если в пути клиент выразил необходимость остановиться по своим нуждам, по действующим тарифам.
* Другие условия по действующим тарифам.
После высадки клиента(ов) водитель снова встает в очередь на районе местонахождения произнося в эфир свой позывной номер и район либо меняет в мобильном клиенте свой район местонахождения.
Каждый водитель заканчивая работу произносит в эфир свой позывной, благодарит за работу диспетчеров и прощается с ними либо выключает мобильный клиент на телефоне.
-
Продолжение следует..
-
Не будете возражать, если ваш пример мы будем использовать на разборах на наших практикумах (http://it-konsulting.spb.ru/index.php?option=com_sectionex&view=category&id=8&Itemid=22)?
-
Gordon,
Отлично. Рад что Вам здесь понравилось и то, что Вы хотите внести неоценимую лепту для Начинающих.
Теперь по теме ... Поподробнее посмотрю попозже. Сейчас же замечания по структуре:
Не понятно что Вы хотите описать в разделе "1 Описание предметной области"? ИМХО там все должно быть про Бизнес: ЗЛ, Описание деятельности ЗЛ (БВИ), Проблемы, Цели, ДБО.
-
Кстати по такси. Немного говорили в этих темах:
задача о службе такси в городе (http://www.uml2.ru/forum/index.php?topic=663.0)
Задачи на построение диаграммы вариантов использования (http://www.uml2.ru/forum/index.php?topic=565.0)
-
Gordon,
Отлично. Рад что Вам здесь понравилось и то, что Вы хотите внести неоценимую лепту для Начинающих.
Я сам начинающий, и очень расчитываю на вашу помощь. :)
Теперь по теме ... Поподробнее посмотрю попозже. Сейчас же замечания по структуре:
Не понятно что Вы хотите описать в разделе "1 Описание предметной области"? ИМХО там все должно быть про Бизнес: ЗЛ, Описание деятельности ЗЛ (БВИ), Проблемы, Цели, ДБО.
Да, это понятно.
Сюда я хочу выкладывать то, что можно назвать "чистовиком". "Черновик" лежит здесь: http://katrin.distance.ru/wiki/Taxi Собственно эта ссылка есть в моем первом посту, видимо я не ясно пояснил..
Не будете возражать, если ваш пример мы будем использовать на разборах на наших практикумах (http://it-konsulting.spb.ru/index.php?option=com_sectionex&view=category&id=8&Itemid=22)?
Совсем нет..
-
БВИ
(http://katrin.distance.ru/wiki/images/4/49/%D0%91%D0%92%D0%98.png)
Проблема №1: Большая нагрузка на диспетчеров во время пика заказов
В основном приводит к повышенному времени ожидания клиентом принятия заказа диспетчером, также при повышенных нагрузках возможны ошибки человеческого характера.
Решение проблемы №1
Проблема будет решена за счет замены диспетчера-человека программно-аппаратным комплексом, состоящим из:
* Sphinks - программа по распознаванию речи.
* Asterisk - call-центр.
* Katrin-taxi - ERP-система.
* A-S-K - скрипт, объединяющий Sphinx, Asterisk и Katrin-taxi.
* Сервер подключенный к сети Интернет
Проблема №2: Рассогласованность адресов посадки и мест скопления водителей у разных компаний
Как правило, часты случаи когда у компании№1, в районе№1, скопилось большое кол-во водителей, а в районе№2, большое кол-во "непринятых" заказов. В свою очередь у компании №2, в районе№2, есть очередь водителей, а в районе№1 некоторое кол-во "непринятых" заказов. Это приводит к увеличению времени подачи машины к клиенту.
Решение проблемы №2
Внедрение ИС-Катрин позволит рассматривать коллективы водителей разных компаний как единый коллектив, т.е. выбор водителя будет зависеть не от очередности на районе и принадлежности водителя к какой либо компании, а от: расстояния между водителем и адресом посадки, и рейтингом водителя. Что позволит максимально сократить время подачи машины к клиенту.
-
Я пытаюсь придать описанию структуру аналогичную той, которую вы (я имею в виду весь коллектив) одобрили для курсовой работы Наташи. Но изменения вносимые мной в бизнес-процессы диспетчеризации столь кардинальны, что мне кажется будет более целесообразным описать новый бизнес-процесс заново, так, как я описал старый бизнес-процесс. Прошу мнений..
-
В ДВИ показывается то, что должна делать проектируемая система, которая уж перевезти клиента никак не сможет :)
Соответсвено, ВИ - это фукции, которые выполняет система, по запросу актёра (кого-то внешнего, по отношению к системе).
-
Gordon,
ИМХО нужно сначала определиться с Problem Domain. Т.е. описать всех ЗЛ, Проблемы кот. будем решать, и потом уже БВИ, кот. представляют по сути БП компании.
Опять же нужно определиться какой уровень абстракции БВИ принять - как белый или черный ящик? Т.е. показываем или нет сотрудников Организации?
-
StUtk,
Не спеши. Есть СВИ и БВИ. Различия смотреть в ФАКе - Чем отличается диаграммы Бизнес ВИ и Системных ВИ? (http://www.uml2.ru/index.php?option=com_content&task=view&id=75&Itemid=47)
-
В ДВИ показывается то, что должна делать проектируемая система, которая уж перевезти клиента никак не сможет :)
Соответсвено, ВИ - это фукции, которые выполняет система, по запросу актёра (кого-то внешнего, по отношению к системе).
Собственно в этом посту: http://www.uml2.ru/forum/index.php?topic=993.msg10616#msg10616 Galogen пишет, цитирую: -"Цель декомпозируема - это факт. Но ВИ не функция, ВИ отражает цель пользователя, а не является ее сам по себе."
Это противоречие, мягко говоря, вводит в ступор..
-
Gordon,
ИМХО нужно сначала определиться с Problem Domain. Т.е. описать всех ЗЛ, Проблемы кот. будем решать, и потом уже БВИ, кот. представляют по сути БП компании.
Опять же нужно определиться какой уровень абстракции БВИ принять - как белый или черный ящик? Т.е. показываем или нет сотрудников Организации?
дада.. понятно! :)
ЗЛ:
* Клиенты - единственной целью использовать ИС является переезд из одной точки в другую, что включает в себя: звонок в компанию, заказ поездки и, собсно, сама поездка.
* Руководители компаний - управление компанией, куда входит прием и увольнение водителей и редактирование тарифов на: поездки, з/п водителей и др. условия..
* Водители - цель: перевозка пассажиров за вознаграждение.. собственно это включает в себя: смена состояния, прием заказа и поездка.
* Диспетчеры (нужно ли их сюда включать, если в создаваемой системе они отсутствуют, а их функции берет на себя ИС?)
Проблемы:
* Клиенты - долгое время ожидания приезда машины.
* Руководители - необходимость автоматизации компании влечет за собой затраты на разработку или внедрение и поддержку ИС, существуют большие риски связанные с некачественной разработкой или внедрением ИС.
* Водители - неоптимизированность поездок, всегда приходится проезжать довольно большое расстояние до места посадки.
Уровень абстракции БВИ предполагаю использовать как белый ящик. Интересно, кем придуманы эти термины (черный и белый ящики?)
Вроде все.. прошу дальнейших комментариев..
-
зачем водителю менять чей-то статус?... этим должны заниматься те, кто обслуживает ИС - операторы, администраторы, диспетчеры, или как они там в конкретном случае называются. Или вы хотите предоставить водителю доступ к ИС?
Да, именно это я и хочу сделать.. У водителя, на телефоне установлена небольшая программа, меню и возможности которой я привожу ниже:
(http://katrin.distance.ru/wiki/images/a/a6/%D0%9C%D0%B5%D0%BD%D1%8E_%D0%B4%D0%B6%D0%B0%D0%B1%D0%B1%D0%B5%D1%80-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0.png)
Клиенты не используют ИС.
Они пользуются услугами службы перевозок (звонят, ездят, платят деньги). Доступа к ИС у них с точки зрения здравого смысла быть не должно. Как и у водителей.
Хм.. смотря с какого боку это рассматривать..
Клиент звонит по телефону и с помощью модулей, входящих в ИС, а именно: "Сфинкс-распознование голоса" и "Астериск-проигрывание заранее записанных звуковых файлов", создает заявку. Как можно изобразить такой подход на БВИ...? Либо клиент САМ создает заявку (значит и доступ к ИС у него есть), либо заявку создают модули, которые уже ВХОДЯТ в ИС?
Руководители компаний тоже вряд ли будут ручками редактировать тарифы и др. условия. Скорее всего, этим будет заниматься отдельный человек (совмещающий с др. обязанностями или нет, в зависимости от объемов работы).
Руководители могут захотеть получать какие-то отчеты о проделанной работе, статистику и пр. Они устанавливают тарифы и пр. Но не они вводят их в систему, это не стратегическая задача, ее можно передать исполнителю.
Частично согласен.. Возможно тут надо добавить еще актЁров.. (уж простите.. но я физически не могу говорить актОр:) Декомпозировав роль Руководителя.. как это сделать пока не соображу.. в голове вертится: для ИС не важно кто будет иметь доступ к БД компании, сам руководитель или доверенное лицо..
Т.о., здесь по сути две задачи:
1. Диаграмма ВИ собственно для ИС (т.е. ПО)
2. Диаграмма ВИ для самой службы, т.е. бизнеса
У них будут общие ВИ и будут различающиеся, как и роли.
Вот это просто и понятно! :)
-
Gordon,
В первых Ваших сообщениях вычитал вот что:
"В случае использования ИС диспетчер вводит следующие данные о заказе: адреса посадки и доставки, время подачи машины и цена поездки, если в ИС присутствует функционал расчета поездки."
А дальше Вы задаётесь вопросом в варианте ЗЛ: "Диспетчеры (нужно ли их сюда включать, если в создаваемой системе они отсутствуют, а их функции берет на себя ИС?)"
Я просто не понял, в создаваемой системе диспетчеры будут или нет?
Что касается целей ЗЛ "Водители": "Водители - цель: перевозка пассажиров за вознаграждение.. собственно это включает в себя: смена состояния и прием заказа"
Так они же и до создания ИС перевозили пассажиров за вознаграждение =)
И по руководителям компании я тоже не согласен... они и без ИС тоже управляли компанией. То есть цели достигнуты уже до создания ИС...)) Я бы сказал, что цели руководителей - оптимизация бизнеса.
-
Gordon,
В первых Ваших сообщениях вычитал вот что:
"В случае использования ИС диспетчер вводит следующие данные о заказе: адреса посадки и доставки, время подачи машины и цена поездки, если в ИС присутствует функционал расчета поездки."
А дальше Вы задаётесь вопросом в варианте ЗЛ: "Диспетчеры (нужно ли их сюда включать, если в создаваемой системе они отсутствуют, а их функции берет на себя ИС?)"
Я просто не понял, в создаваемой системе диспетчеры будут или нет?
В создаваемой системе функции диспетчера останутся, но выполнять их будет комплекс программ, который мы называем Информационная Система.
Что касается целей ЗЛ "Водители": "Водители - цель: перевозка пассажиров за вознаграждение.. собственно это включает в себя: смена состояния и прием заказа"
Так они же и до создания ИС перевозили пассажиров за вознаграждение =)
Ну да.. А разве мне это не надо указывать в БВИ?
И по руководителям компании я тоже не согласен... они и без ИС тоже управляли компанией. То есть цели достигнуты уже до создания ИС...)) Я бы сказал, что цели руководителей - оптимизация бизнеса.
Интересное замечание! :)
Наверно я возьмусь за письменное описание планируемого бизнес-процесса.. Дабы не вводить в заблуждение почтенную публику! :)
-
Описание планируемого процесса
Компания-диспетчер (КД) заключает договор с компанией-разработчиком (КР) ИС о внедрении ИС в бизнес-процессы КД. В одном городе существует одна КР и множество КД.
Внедрение включает в себя:
1. Переадресация входящих звонков с телефона КД на ИС Катрин-такси, включающую в себя программный АТС Asterisk.
2. Предоставление руководителю КД веб-интерфейса редактирования водителей и тарифов, можно сказать, что это константы, на основании которых рассчитывается стоимость поездки, стоимость времени ожидания, процент от стоимости поездки остающийся у руководителя компании..
3. Планируемый функционал также включает в себя сдачу налоговой отчетности как для руководителя КД так и для водителей..
Собсно сам процесс:
1. Клиент звонит по телефону КД.
2. Katrin-taxi - модуль биллинговой системы Katrin, создает в БД записи о номере телефона клиента, на телефон какой компании он позвонил, времени звонка, все остальные хар-ки можно увидеть на диаграмме классов: http://katrin.distance.ru/wiki/images/a/ab/TaxiGraph.png
3. Программный АТС Asterisk по заданному алгоритму просит произнести адреса посадки и доставки, (интересует тип диаграммы для описания этого алгоритма).
4. Программа по распознаванию речи Sphinks распознает адреса и записывает в БД.
5. ГИС-система определяет кратчайший маршрут между адресами, высчитывает расстояние и по константам, которые задает руководитель КД высчитывает стоимость поездки. Тем самым заказ будет полностью оформлен.
6. Для начала работы водителя, ему нужно просто включить jabber-клиент на своем телефоне, выставить свой статус в "свободен" и указать район местонахождения.
7. ГИС-система определяет ближайшего водителя к адресу доставки, либо Katrin-taxi, по старинке, определяет первого водителя на районе, и скидывает ему на мобильный jabber-клиент, установленный на сотовом телефоне, предложение принять заказ. В случае отказа, система предлагает принять заказ следующему водителю. После принятия заказа водитель должен указать время, через которое он подъедет к месту посадки. При принятии заказа статус водителя автоматически устанавливается в состояние "принял заказ".
8. После подъезда к месту посадки водитель меняет свое состояние на "подъехал"
9. После смены состояния водителя на "подъехал" смс-модуль Катрин-такси скидывает клиенту информацию о подаче машины: ее марку, номер, стоимость поездки.
-
Прошу указать следующие шаги по построению модели ИС.
-
Собственно в этом посту: http://www.uml2.ru/forum/index.php?topic=993.msg10616#msg10616 Galogen пишет, цитирую: -"Цель декомпозируема - это факт. Но ВИ не функция, ВИ отражает цель пользователя, а не является ее сам по себе."
Это противоречие, мягко говоря, вводит в ступор..
ВИ отражает цель, но ею не является. У актера есть цель (потребность). Система предоставляет ему функциональность (или как говорит Коберн система имеет ответственность). Ответственность покрывается функциями системы. И функция и цель декомпозируемы по определению. Но ВИ - это набор разных функций, которые могут относится к той или иной части декомпозиции, но ВИ - не есть декомпозиция цели.
-
StUtk,
Не спеши. Есть СВИ и БВИ. Различия смотреть в ФАКе - Чем отличается диаграммы Бизнес ВИ и Системных ВИ? (http://www.uml2.ru/index.php?option=com_content&task=view&id=75&Itemid=47)
Саша ты не прав.Показывая ту ситуаци, которая изображена на диаграмме мы показываем, что
1. Либо водитель использует ИС Катрин для перевести клиента,
2. или ИС Катрин использует водителя для перевозки клиента.
в 1 случае непонятна цель использования ИС Катрин, но очевидно Основное действующее лицо
во 2 случае водитель второстепенное лицо, тогда нет Основного действующего лица
Противоречие на лицо
-
ВИ отражает цель, но ею не является. У актера есть цель (потребность). Система предоставляет ему функциональность (или как говорит Коберн система имеет ответственность). Ответственность покрывается функциями системы. И функция и цель декомпозируемы по определению. Но ВИ - это набор разных функций, которые могут относится к той или иной части декомпозиции, но ВИ - не есть декомпозиция цели.
Все это очень сложно уложить в голове, особенно новичку.. Galogen, прошу вас, скажите правильное наименование ВИ в БДВИ для клиента в моем примере.
-
Саша ты не прав.Показывая ту ситуаци, которая изображена на диаграмме мы показываем, что
1. Либо водитель использует ИС Катрин для перевести клиента,
2. или ИС Катрин использует водителя для перевозки клиента.
в 1 случае непонятна цель использования ИС Катрин, но очевидно Основное действующее лицо
во 2 случае водитель второстепенное лицо, тогда нет Основного действующего лица
Противоречие на лицо
Для меня это совсем не очевидно! Но спасибо за такой комментарий! Тут есть над чем подумать..
Ок, первые две строчки мне ясны..
Но про Основное действующее лицо я впервые слышу.. за что сорри, пошел учить мат.часть.. :)
-
Каким будет алгоритм по которому будет идти общение ИС с клиентом я представляю.. но в какой диаграмме это выразить - мне не ясно..
Суть примерно следующая:
1) Клиент звонит в КД и попадает на нашу телефонию.
2) Asterisk проигрывает запись приветствия, и просит произнести улицу и номер дома посадки.
2а) Asterisk проигрывает запись о сожалении об ошибке, и просит произнести улицу и номер дома посадки снова.
3) Клиент произносит улицу и номер дома посадки.
4) Sphinks, в реальном времени распознает адрес и записывает в БД. В случае неудачи распознавания алгоритм возвращается на п.2а
5) Asterisk просит произнести улицу и номер дома доставки. 5а) Asterisk проигрывает запись о сожалении об ошибке, и просит произнести улицу и номер дома доставки снова.
6) Клиент произносит улицу и номер дома доставки.
7) Sphinks, в реальном времени распознает адрес и записывает в БД. В случае неудачи распознавания алгоритм возвращается на п.5а
8) Asterisk просит подождать пока ИС назначит водителя.. проигрывается музыка..
*** в это время Катрин скидывает на джаббер-клиенты водителей предложения о заказе, пока не назначит водителя либо не кончится их очередь. регламентная продолжительность фазы 30-60сек ***
9) Если водитель принимает заказ, Asterisk проигрывает запись, что ваш заказ принят, машина такая-то, номер такой-то, приедет через столько-то..
9а) Если заказ не принят, Asterisk проигрывает запись, что мол машины пока заняты, и при ближайшей возможности мы уведомим вас о принятии заказа через смс.
-
Gordon,
у Вас, судя по тем описаниям, которые Вы представили, система со сложным внутренним алгоритмом. Для описания такой системы варианты использования мало подходят. Не заморачивайтесь на этом формате, отталкивайтесь от того описания бизнес-процесса, которое у вас есть, на его основе формируйте требования к ПО и переходите к программированию.
-
Народ,
Мы что-то - кто в лес, кто по дрова .... Давайте определимся что делаем - структуру проекта, а потом уже будем делать
-
Собсно программирование уже идет.. :)
Кроме этого проекта в голове есть еще много всякого.. :) Но это "всякое" мало структурировано.. лежит на дне и "всплывает" с большим трудом.. По этой причине хочется освоить подходящие инструменты, чтоб мысли приходили "в голову" не только умирать, а имели шансы принести пользу.. :)
К сожалению до сих пор остается неясным вопрос о сфере практического использования UML, но этот вопрос в данной теме оффтоп.. может кто направит по нужной ссылке на путь истинный?
Также открываю вопрос о потенциале обсуждения этой темы.. прошу мнения.
-
Народ,
Мы что-то - кто в лес, кто по дрова .... Давайте определимся что делаем - структуру проекта, а потом уже будем делать
Половина сообщения где то по пути, в лесу, застряло.. :)
Чую, что в этой половине есть ответы на мои вопросы! :)
-
Зашибись....
Да, именно так мы обычно и работаем.
Лучше поздно чем никогда :)
-
Оффтопите, дамы и господа, оффтопите! :)
Я все ждал когда меня начнут тянуть за уши.. и тут, по ссылке от Galogen'a нашел серию постов от Boatman по своей теме! Начиная отсюда: http://www.uml2.ru/forum/index.php?topic=565.msg6723#msg6723
Попытаюсь все это осмыслить, усвоить и повторить! Прошу напутствий перед дорогой! :)
-
К сожалению до сих пор остается неясным вопрос о сфере практического использования UML, но этот вопрос в данной теме оффтоп..
Лично мне не кажется, что это оффтоп, вопрос как раз уместный. По-моему, в данной теме налицо не вполне удачные попытки применить инструмент, который для выбранной цели не очень подходит. Неудобно запихивать шары в квадратные отверстия, вот мы и мучаемся.
Всякому овощу свое время. С легкой руки г-на Коберна варианты использования как техника описания требований стали настолько популярны, что некоторые аналитики стали считать их асболютно универсальным средством, которое можно и нужно применять в любой задаче, и именно с их помощью формулировать конечный набор требований к ПО.
Лично мне более близок подход Вигерса (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=101), который указывает на то, что варианты использования имеют ограниченное применение. Они подходят как форма промежуточного описания предметной области, когда аналитик только пытается ее как-то декомпозировать - выделяет акторов, их действия по отношению к системе и т.п. Дальше, по Вигерсу, аналитик с этими зарисовками идет к этим акторам, проговаривает с ними сценарии использования (вот тут от них и есть польза), а дальше - ВИ умирают и на смену им приходят требования к ПО, которые аналитик выявил и сформулировал как результат обсуждения с пользователем. Этот подход к формулированию требований является распространенным, но неправильно было бы утверждать, что он является единственно возможным, т.е. что путь к требованиям ПО лежит только через варианты использования. Более того, Вигерс указывает, что для некоторых классов систем (например, со сложными внутренними вычислениями) ВИ мало подходят для использования.
В Вашем кейсе я вижу следующее:
1) бизнес-процессы и алгоритмы работы системы на верхнем уровне Вами описаны;
2) взаимодействие конечных акторов (водители, клиенты) с системой Вы тоже описали, пусть и не в форме классических ВИ;
3) дальнейшее интервьюирование акторов для уточнения требований вряд ли имеет большой практический смысл - если только у Вас есть какие-то продвинутые водители и/или клиенты, с которыми Вы готовы обсудить эту идею - я бы выбрал обсуждать с ними прототип, а не ВИ;
4) основная "тяжесть" системы состоит во взаимодействии ее компонентов - Sphinks, Katrin, Asterisk, ГИС - при желании это взаимодействие можно расписать в виде ВИ, но, опять же, это не лучший, не единственный и не обязательный способ. Еще такой нюанс - если Вы используете эти системы как готовые/полуготовые, то с практической точки зрения Вы скорее пойдете от существующих интерфейсов к сценариям, нежели наоборот.
Таким образом, Вы можете продолжать попытки применить техники ВИ для описания данной системы; в учебных целях это, наверное, неплохо. Но с практической точки зрения я бы не стал на этом проект останавливать; есть все необходимое, чтобы двигаться дальше.
-
Прошу подсказать в каком типе диаграмм описывается алгоритм подобный этому: http://www.uml2.ru/forum/index.php?topic=1210.msg13205#msg13205
-
Прошу подсказать в каком типе диаграмм описывается алгоритм подобный этому: http://www.uml2.ru/forum/index.php?topic=1210.msg13205#msg13205
диаграмма деятельности
-
Я бы к сценарию работы над проектом Михаила добавил следующее...
Необходимо выполнить:
1. Бизнес Анализ
1.1. Описать ЗЛ
1.2. Описать деятельность работы Организации (ДБВИ и их сценарии, Д Бизнес-процессов или просто текстом)
1.3. Выявит Проблемы в работе Организации
1.4. Наметить цели автоматизации
1.5. Составить список основных функций ИС
1.6. Составить словарь предметной области (ДБО или просто в виде Глоссария)
2. Системный Анализ
2.1. Описать Пользовательские Требования (ДСВИ и их сценариев или просто текстом), как уже сказано можно этот шаг и пропустить, но я бы не стал
2.2. Функциональные Требования к ИС (текст)
2.3. Не функциональные Требования к ИС (текст)
3. Проектирование ИС
....
-
Хм.. bas, так то это мой проект.. :) Но я понял, что вы хотели сказать.. :)
1.
1.1. Описание ЗЛ уже есть, т.е. есть описание кто участвует в процессе и какие цели он преследует.
1.2. Считаю, что текстом тоже есть.. а вот диаграммы БП я видел только в Virtual-Paradigm, и совсем не понятно как я смогу описать Бизнес-Процесс диаграммой Бизнес-Процессов, который уже описан текстом.. может кто на готовый пример ссылку даст?
1.3. Здесь не совсем понятно: необходимо выявить Проблемы в новом БП или в старом БП?
/*Мне кажется здесь надо подойти немного с другой стороны: я не автоматизирую старый БП, с устранением старых недостатков, а я проектирую новый БП, который преследует те же цели, но изначально лишен недостатков старого БП.. */
1.4. /*Хотя следующий подход тоже имеет право на жизнь:*/ автоматизации подлежат функции диспетчера, а именно - прием заказов на поездку, назначение заказу водителя, контроль за исполнением заказа, связь с водителями, учет очереди водителей по районам..
1.5. Для "быстрого ответа" этот пункт слишком большой и он пока не составлен, но на http://katrin.distance.ru/wiki/Taxi он обязательно появится..
1.6. см. в п.1.5
2.
2.1. Да, я тоже не стану пропускать, ибо это важно.. особенно в алгоритме создания заявки клиентом и ИС.. см. п.1.5
2.2.-2.3. Для меня не совсем ясны термины "Функциональные Требования к ИС" и "Не функциональные Требования к ИС"
3.
Вот это самое интересное! :)
Продолжение следует..
-
1.1. Где это описание? Не нашел.
1.3. Необходимо выявить все проблемы и будущие и текущие, и их решение. Например, в будущих проблемах я вижу следующее - Система не сможет распознать голос Клиент и сделать заказ... Новый БП на основе чего Вы проектируете?
1.4. Это не Цели, это задачи. Читаем про Цель на страничке boatman'а (http://boatmanshome.ru/cgi-bin/page.pl?1goal_000.page).
1.5. Без этого п. Двигаться дальше не имеет смысла.
1.6. см. в п.1.5
2.2.-2.3. Читаем Вигерса (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=77).
-
Gordon,
Мне совсем не нравится ваша ДБВИ.
1. БВИ - это цели ЗЛ с т.з. Бизнеса, т.е. те реальные нужды, которые испытывает человек без привязки к ИС. Ну нет потребности у Владельца Редактировать тарифы или Добавить Водителя. У него может мыть потребность - нанять водителя, назначит тарифы на перевозки и т.д.
2. Переехать с одной точки на другую и Перевезти Клиента - это один БВИ, в кот. участвует Клиент и Водитель, м.б. еще и Диспетчер.
3. Как-то реальные потребности ЗЛ не отображены на Д. Например, у Клиента есть две очевидные потребности - Заказать такси и Приехать в пункт назначения, в первом участвует Клиент и Диспетчер, во втором Клиент, Водитель и м.б. Диспетчер. И т.д.
-
Может у когонить будут комментарии..?
(http://katrin.distance.ru/wiki/images/0/01/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8.png)
-
Пару моментов мне только сейчас видны:
1) в варианте - "не хочу чтоб меня соединили с дежурным" нет проверки на правильность распознования..
2) тема сюрпрайса не раскрыта.. :)
-
Может у когонить будут комментарии..?
Просим подождать пока ..., просим произнести ... - это ожидания событий (другая нотация)
Все что кончается знаком вопроса - в комментарий и присоединить к соответствующему ромбу.
Все Да или Нет на переходах - в квадратные скобки.
Звонок в компанию - это либо условия на переходе, либо ожидание события
перерисуй и покажи, что получилось. потом еще посмотрим.
-
Может у когонить будут комментарии..?
Знаете такой анекдот:
Самолет падает, которым управляет В.И. и Петька ..
В.И. - Петька, приборы?!
Петька - 200
В.И. - Что 200?
Петька - А что приборы?
Так же и у нас получается, проверить, а для чего и откуда взялась эта Д не понятно.
-
Gordon,
Мне совсем не нравится ваша ДБВИ.
Ссылка на анекдот про приготовление кошек на форуме очень популярна.. :)
А мне, в таких случаях вспоминается другой анекдот, на эту же тему..:
Два африканских аборигена едят только что пожаренное на костре мясо, один другому говорит:
- Знаешь, мне в последнее время твоя тещя не нравится..
Второй отвечает:
- Не нравится - не ешь!
Сейчас читаю К.Лармана. Считаю, что у новичков/студентов эта книга должна быть первой в очереди для прочтения.
Многие моменты уже стали более ясные. Наверно продолжим обсуждение темы только после прочтения мной этой книги.. Хотя если кто-то выложит свои комментарии, буду очень рад! :)
-
Просим подождать пока ..., просим произнести ... - это ожидания событий (другая нотация)
Все что кончается знаком вопроса - в комментарий и присоединить к соответствующему ромбу.
Все Да или Нет на переходах - в квадратные скобки.
Звонок в компанию - это либо условия на переходе, либо ожидание события
перерисуй и покажи, что получилось. потом еще посмотрим.
Перерисовал.. Все кроме квадратных скобок.. Диаграмма на предыдущей странице, на пару постов выше.. Последний вариант заменил собой предыдущий.. Использую движек Википедии.. зпт.. очень удобно! тчк :)
Надеюсь, что я правильно вас понял..?
-
перерисуй и покажи, что получилось. потом еще посмотрим.
А будет ли правильным следующее оформление:
Смысл сообщения системы выносим в комментарии и соединяем с action пунктирной стрелкой, а в action пишем порядковый номер сообщения..?