Т.е. это система контроля задолженностей?
А не предоставления услуг.

В вашем описании о задолженностях нет ни слова.

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

Я к чему это говорю - учитесь правильно ставить задачу, и вам ее правильно реализуют. Как поставите - так и реализуют. Не пинайте потом разработчиков. 

Это сообщение отредактировал(а) ida - 27.5.2008, 09:20

Система сама услуги не предоставляет. Я об этом не говорил. Просто есть услуги, есть абоненты. Тут не только контроль задолженности. Нужно расчитать эту задолженность.


Дык, бизнес цели действительно пропустил 

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

Ну и далее, вторичные задачи, вытекающие из первых двух:
3. печать документов
4. учет оплат

Это сообщение отредактировал(а) sandello - 27.5.2008, 09:53

Владелец ещё вводит данные об издержках, т.к. знает о них только он.


Не понял. Что значит "импорт данных наружу"?
Данные от реализаторов идут на главный компьютер (с основной программой) владельца/главбуха. Промежуточных импортов нет. Данные дальше куда-то наружу не идут.


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

sandello, уже лучше.

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

Наверно, «проанализировали» — это громко сказано. Я представляю в целом, как все устроено, но не могу разложить по полочкам. Мы работаем в области геодезии и землеустройства, можно ли считать объектами регулирующие законы, нормы и правила, порядки оформления, земельные участки, заказчиков, госучреждения, выдающие справки, сами справки?


Незарегистрированный пользователь
1. Просмотр статей.
2. Скачивание файлов.
3. Контакт с фирмой
4. Контакт с представителем фирмы
5. Идентификация
6. Комментирование статей с проверкой email.
7. Расчет стоимости услуг
8. Регистрация

Зарегистрированный пользователь (клиент)
1. Авторизация
2. Авторизация через почту
3. Редактирование профиля.
4. Сохранение заказа.
5. Просмотр истории и статистики заказов.
6. Редактирование заказа.
7. Оформление заказа в офисе или по телефону.
8. Добавление вопроса специалисту.
9. Комментирование статей без проверки email.

Менеджер
1. Ответ на вопрос.
2. Редактирование заказа.
3. Оформление заказа.

Администратор
1. Управление контентом.
2. Управление пользователями.
3. Редактирование настроек сайта.
---

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

Проблема в том, что я не очень понимаю, как нужно строить варианты использования и как их дальше использовать. Например:
1) большая часть сайта — справочная информация, о компании и прочее — никак не отражается в моих вариантах, т.к. это суть просмотр страниц;
2) менеджер и клиент участвуют в одном процессе (оформление заказа), тут нужно по варианту для каждой стороны?
3) как раскрыть операции вроде управления контентом? «1. Администратор управляет контентом»? Тут столько вариантов добавлений, правок, удалений, перемещений, да еще есть админы с разным доступом;
4) нужно ли (и как?) показывать циклические действия, например, оценка суммы и редактирование заказа могут повторяться сколько угодно. Для циклов похоже будет другой тип диаграмм?
5) как отразить ветвления алгоритма? Читал про способ с указанием альтернатив, но это неудобно и ненаглядно;
6) как определить полноту описания и двинуть дальше?

Это сообщение отредактировал(а) altspam - 28.5.2008, 05:26

Присоединённый файл ( Кол-во скачиваний: 9 )
 use_cases.txt 4,69 Kb

где-то я уже это видел...   

ida, что еще не так?

altspam, вот уже появились какие-то кленты.
Они клиенты или все-таки зарегистрированные пользователи?...
Все клиенты являются зарегистрированными пользователями? Все зарегистрированные пользователи являются клиентами? Почему их называют клиентами?


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

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

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

1. Каких статей? Для чего они пользователю нужны?
2. Каких файлов? Для чего?
3. Для чего и с какой фирмой? В чем этот контакт заключается?
4. То же самое, что в предыдущем + в чем разница с предыдущим?
5. С какой целью?
6. Первое действие, похожее на настоящий вариант использования. 
7. Каких услуг? Кто их предоставляет?

1, 2 можно не разделять
3 нормально
4 непонятно - что значит "сохранение заказа" и почему оно отдельно?... Насколько я понимаю, чтобы что-то заказать, нужно проделать несколько шагов, сохранение - один из них. Где остальные?...
5, 6 нормально
7 какой участие принимает сайт в оформлении заказа в офисе или по телефону? Каким еще способом можно оформить заказ? И что же это наконец за заказ, про который мы уже полчаса говорим, а я так и не поняла, откуда и зачем он взялся?
8, 9 нормально.


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

2. Чтобы понять, "чей" вариант использования, полезно спросить: "кому нужно это действие? кто его инициирует?"
Поставив себя на место клиента, можно понять, что клиент инициирует оформление заказа, чтоб удовлетворить какую-то свою потребность (смотря что он там заказывает). Поэтому на диаграмме вариантов использования мы соединим этот вариант использования с действующим лицом Клиент (или как мы его там назовем).
У Менеджера цели будут явно другие - например, Посмотреть состояние заказов или Получить отчет.

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

4, 5. чтобы описать алгоритмы, нужно использовать диаграммы деятельности. Ими детализируют в том числе и сложные варианты использования, если требуется.

6. Еще рано 

Это сообщение отредактировал(а) ida - 28.5.2008, 12:10

sandello, а над вашей задачкой я еще подумаю.
Потому что из классов предметной области вижу ясно пока только один: Абонент.
Под вопросом: Услуга.

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

Свои версии?...

ida, 
Хых. Для описанной задачи мы сделали 3.
«Абонент» - его информация требуется для различной отчетности. Самостоятельная сущность
«Услуга» -  в данной поставновке требуется для задания способов расчета потребления. Они разные. Самостоятельная сущность.
«Подписка» на услугу или Услуга Абонента - сущность на стыке Абонентов и Услуг. Описывает подключение конкретного абонента к конкретной услуге.

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

Теперь вроде бы замкнутое описание 

А вы не посмотрели прикрепленный файл? Там я раскрыл варианты использования.


Зарегистрированный пользователь может стать клиентом, если закажет что-то.


Нет, есть и оффлайн-клиенты, которые нас не интересуют.


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


Заказывающих удобнее называть клиентами. Думаете, нужен отдельный класс? Ведь функции у них одинаковы, «клиент» — это скорее условный статус зарегистрированного пользователя.


Поправьте, пожалуйста, ибо никак не могу взять в толк :)
Мы говорим об анализе предметной области.
Предметная область — часть реального мира, рассматриваемая в пределах данного контекста.
Соответственно, «Где процессы? Где жизненные циклы объектов? Где функциональные требования? Ограничения?» относится к реальному миру, с которым взаимодействует разрабатываемая система.
Возьмем объекты (классы?), которые я привел, какое отношение они имеют к сайту?

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

Я мыслю в правильном направлении?


Цели:

• привлечение клиентов;
• стимулирование потенциальных клиентов к контакту с фирмой;
• упрощение заказа услуг;
• увеличение авторитета фирмы на рынке.

А что нам это дает? В ТЗ всегда пишут «задачи сайта», «цели сайта», но на практике для 90% сайтов цели одни — увеличение продаж.



Справочная часть:

• Официальные документы — законы, ГОСТы, СНиПы, акты, рекомендации и т.п.
• Пояснения и комментарии к официальным документам.
• Рекомендации по самостоятельному оформлению — порядок действий, списки необходимых документов и т.д.
• Информация об организациях, имеющих отношение к землеустройству.
• Словарь терминов.

А также:

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

• Тексты официальных документов.
• Примеры и бланки документов, необходимых для самостоятельного оформления.
• Любые другие файлы, прикрепленные к статьям.

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


Это то же самое, но когда посетитель уже знаком с фирмой и ищет конкретного человека либо конкретного специалиста.


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


Не понимаю. Другие варианты — изучение предложений фирмы, цен и грубо говоря поиск телефона, — это недостаточная цель использования сайта? Изначально сайты вообще были продвинутыми «визитными карточками», остаются ими и по сей день. 


Землеустроительных услуг, которые предоставляет фирма-владелец сайта.



Шаги такие:

• Расчет стоимости.
• Сохранение заказа.
• Оформление заказа с менеджером (по номеру).

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

altspam, хорошо, ответьте мне на вопрос: для чего пользователь приходит на сайт?

Кто за чем.

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

altspam, вот это и будут ваши варианты использования.
Их и надо расписывать.

Кто-то хочет заказать съемку или оформление участка.


Кто-то хочет получить консультацию.


Многие ищут информацию, руководства, разбираются в теме.


Кто-то продает участок.
Кто-то хочет купить.

Кто-то просто интересуется геодезией.


Мм?

Добавлено через 5 минут и 48 секунд
ida, большое спасибо вам за помощь.
Вижу, что слишком загрузил, дальше буду разбираться сам. Направление примерно понятно.

Если нужно что сверстать — обращайтесь :)

Спасибо за еще одну классическую ошибочку :)

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

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

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

Это сообщение отредактировал(а) ida - 1.6.2008, 19:06