Форум Сообщества Аналитиков

×


Система автоматизации диспетчерских и таксопарков(Прочитано 35533 раз)
Оффтопите, дамы и господа, оффтопите! :)
Я все ждал когда меня начнут тянуть за уши.. и тут, по ссылке от Galogen'a нашел серию постов от Boatman по своей теме! Начиная отсюда: http://www.uml2.ru/forum/index.php?topic=565.msg6723#msg6723
Попытаюсь все это осмыслить, усвоить и повторить! Прошу напутствий перед дорогой! :)



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

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

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

В Вашем кейсе я вижу следующее:
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'а.
1.5. Без этого п. Двигаться дальше не имеет смысла.
1.6. см. в п.1.5

2.2.-2.3. Читаем Вигерса.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Gordon,

Мне совсем не нравится ваша ДБВИ.
1. БВИ - это цели ЗЛ с т.з. Бизнеса, т.е. те реальные нужды, которые испытывает человек без привязки к ИС. Ну нет потребности у Владельца Редактировать тарифы или Добавить Водителя. У него может мыть потребность - нанять водителя, назначит тарифы на перевозки и т.д.
2. Переехать с одной точки на другую и Перевезти Клиента - это один БВИ, в кот. участвует Клиент и Водитель, м.б. еще и Диспетчер.
3. Как-то реальные потребности ЗЛ не отображены на Д. Например, у Клиента есть две очевидные потребности - Заказать такси и Приехать в пункт назначения, в первом участвует Клиент и Диспетчер, во втором Клиент, Водитель и м.б. Диспетчер. И т.д.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Может у когонить будут комментарии..?



Пару моментов мне только сейчас видны:
1) в варианте - "не хочу чтоб меня соединили с дежурным" нет проверки на правильность распознования..
2) тема сюрпрайса не раскрыта.. :)



Может у когонить будут комментарии..?

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

перерисуй и покажи, что получилось. потом еще посмотрим.



Может у когонить будут комментарии..?
Знаете такой анекдот:
Самолет падает, которым управляет В.И. и Петька ..
В.И. - Петька, приборы?!
Петька - 200
В.И. - Что 200?
Петька - А что приборы?

Так же и у нас получается, проверить, а для чего и откуда взялась эта Д не понятно.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Gordon,
Мне совсем не нравится ваша ДБВИ.
Ссылка на анекдот про приготовление кошек на форуме очень популярна.. :)
А мне, в таких случаях вспоминается другой анекдот, на эту же тему..:
Два африканских аборигена едят только что пожаренное на костре мясо, один другому говорит:
- Знаешь, мне в последнее время твоя тещя не нравится..
Второй отвечает:
- Не нравится - не ешь! 

Сейчас читаю К.Лармана. Считаю, что у новичков/студентов эта книга должна быть первой в очереди для прочтения.
Многие моменты уже стали более ясные. Наверно продолжим обсуждение темы только после прочтения мной этой книги.. Хотя если кто-то выложит свои комментарии, буду очень рад!  :)



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



перерисуй и покажи, что получилось. потом еще посмотрим.
А будет ли правильным следующее оформление:
Смысл сообщения системы выносим в комментарии и соединяем с action пунктирной стрелкой, а в action пишем порядковый номер сообщения..?




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19