2686

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 16:13:37 »

Galogen, скажите, а что по поводу процентов за услугу? Ведь действительно, он должен где-то участвовать в нашем ВИ...

Имхо это инкапсулируется в Вычислить сумму платежа  (саму формулу можно приложить в доп требованиях к ВИ)

2687

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 13:10:03 »

Павел, смотрите сами.

Мы при описании ВИ фиксируем требования.

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

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

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

Диаграмма активностей - ну вижу, она ничего особо нового не дополняет как мы видим в данном случае и скорее формальная, чем необходимая

2688

Проектирование / Re: Вопрос по реализации

« : 01 Февраля 2010, 10:15:29 »

использование флеш - это не каприз, можно было бы и C# использовать, если бы речь не шла о вебе и о процессе обработки документа

в общих чертах я правильно мыслю ?

Мне кажется , постановка вопроса в корне не верна.

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

Все остальное вторично. Сначала нужно сформулировать требования, и если Вы пытаетесь задать вопрос, то нужно дать нам контекст, выделить проблему, которая Вас беспокоит

2689

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 10:09:05 »

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

Каким образом правильно это сделать?

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

Можно было бы указать так:
1. Оператор инициирует ВИ "оформить платеж"
2. Система предлагает выбрать тип платежа
3. Оператор указывает один из типов
4. Система предлагает ввести детали платежа
5. Оператор вводит необходимые данные согласно извещению
6. Система вычисляет сумму платежа, добавляя ее к общей сумме, предъявляемой к оплате
7. Система предлагает добавить следующий платеж
8. Если есть еще платежи
    8.1 Оператор повторяет пункты 3-6
9. Иначе
    9.1 Оператор Завершает оформление платежей
    9.2 Система выводит общую сумму платежа и предлагает ввести сумму денег о клиента
    9.3 Оператор подтверждает совершение оплаты
    9.4 Система сохраняет данные платежей, вычисляет сдачу, печатает квитанции

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

2690

Примеры / Re: Проектная работа - Коммунальные платежи

« : 31 Января 2010, 14:39:25 »

Что-то мне ваши расширения не нравятся.

Я так понимаю, вы хотите передать то, что можно оформить сразу несколько платежей (в данном случае одного типа). Система подсчитает общую сумму за все сделанные платежи. Когда будет сделана оплата, система рассчитает требуемую сдачу и напечатает нужно количество квитанций?

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

2691

Примеры / Re: Проектная работа - Коммунальные платежи

« : 31 Января 2010, 11:45:47 »

Второстепенные действующие лица: Клиент

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

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

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

Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система определяет сумму оплаты, на основании установленного тарифа
3. Система определяет сдачу, как разницу между введенной и рассчитанной суммой

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

4. Оператор принимает от клиента наличные и совершает оплату

Опять же реакция системы не видна. Оператор принял оператор совершил, а система что делает? Выдает квитанцию?

5. Система выдает квитанцию об оплате
6. Система регистрирует транзакцию

Объединить в один шаг

Постусловия:
Нет

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

Альтернативные потоки:
Нет.

ну с этим еще предстоит разобраться

А так?

Уже много лучше

2692

Примеры / Re: Проектная работа - Коммунальные платежи

« : 31 Января 2010, 00:10:06 »

Почитайте рекомендации по написанию ВИ

Кейс 1:

Что за кейс? как именуется, какова его цель?, кто действующее лицо, если другие участники кейса, интересы которых следует соблюсти

Предусловия:
1) Выполнен Кейс "Настройка АРМ пользователя"
2) Оператор ввел логин и пароль.

Действительно так? Может все-таки написать проще? Заданы тарифы, дата - хотя мне как-то все это представляется странноватым
Оператор ввел логин и пароль - больше смахивает на реализацию, может просто авторизирован в системе?

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

Архив понятие реализации. Вообще сохранение данных начато рано, а если у клиента не окажется денег? (забыл кошелек)

2. Оператор инициирует расчет суммы, на основании установленного тарифа
3. Система расчитывает и выводит сумму оплаты, на основании установленного тарифа

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

4. Оператор инициирует оплату
5. Система сохраняет транзакцию в архиве

Как то выглядит странно и похоже на описание того, что сделано, а не на то что должно быть сделано

6. Оператор инициирует печать квитанции с указанием номер АРМ, даты платежа, номера платежа и оплаченной суммы, с учетом услуги по оформлению платежа.

К чему такие подробности - покажите их на форме квитанции. А где кстати реакция системы?

Незачтено Попробуйте еще разок

2693

Проектирование / Re: Вопрос по реализации

« : 29 Января 2010, 18:57:32 »

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

1. какое касательство имеет UML к тем flash-объектам, о которых идет речь?
2. нужно изучить: как следует работать с этими flash-объектами и рассказать (научить) Вас?
3. в UML нет диаграм прохождения документа в документообороте, однако прохождение документа в документообороте можно описать с использованием имеющихся UML диаграмм

2694

Примеры / Re: Проектная работа - Коммунальные платежи

« : 29 Января 2010, 12:27:18 »

Вот, переосмыслил диаграмму.

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

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

2695

Системный Анализ и Требования / Re: Сравнение различных подходов к формированию функ. требований к ИС

« : 29 Января 2010, 12:21:03 »

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

Я с тобой полностью согласен!

2696

Системный Анализ и Требования / Re: Сравнение различных подходов к формированию функ. требований к ИС

« : 29 Января 2010, 10:05:31 »

А что, бакалаврский диплом в одиночку пишут теперь, без научного руководителя?

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

2697

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 19:31:43 »

И вообще, я бы предпочёл по этому поводу говорить с Эдом, если он прочитал в моих словах тот же смысл, что и ты и его это волнует.

А какой смысл был в твоих словах

Семинар был по мотивам вот этой презентации Функциональные требования к ПО в форме модели сценариев использования (Use Case Model) на TrainingLabs 2008.

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

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

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

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

Лично я не увидел принципов работы с документами заказчиков

2698

Примеры / Re: Проектная работа - Коммунальные платежи

« : 27 Января 2010, 18:59:09 »

Ну я там назвал это "1. Ввести данные... на основании квитанции". Просто тарифы меня сбивают все время.

В нашем деле ясность и однозначность формулировко имеет первостепенное значение.

То есть "2. Рассчитать сумму оплаты по тарифам" - это не то, для чего "пользователь обращается к системе"?
Ведь оператор хочет узнать - "А какая сумма то к оплате"?

Оператору думаю это без надобности. Оператор желает внести сумму платежа и оформить этот платеж надлежайшим образом. А система в этом ему помогает. Это основная задача оператора - зафиксировать прием платежей.

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

Теперь бац - появляется система

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

Оператору произвести оплату не нужно, ему нужно принять оплату и должным образом ее зарегистрировать

Потом оператору нужно узнать сдачу, которую ему нужно сдать клиенту.

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

PS. Сохранение в базе, это не задача оператора, то есть выходит, что это не кейс, а уже функция системы.

Да это функция системы. В нашем случае это постусловие, т.е. состояние в которое перейдет система после исполнения варианта использования.

Очень часто значимость ВИ определяется тем, изменит ли свое состояние система или нет.

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

2699

Примеры / Re: Проектная работа - Коммунальные платежи

« : 27 Января 2010, 13:32:21 »

Попробую порассуждать:

1. Оператор:

Что он хочет от Системы?
1. Ввести данные по тарифам платежей, на основании квитанции, предоставленной клиентом.
2. Рассчитать сумму оплаты по тарифам (на основании установленной оплаты за единицу)
3. Ввести сумму оплаты, предоставленную клиентом
4. Рассчитать сдачу


Верно?

Думаю не совсем.

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

2700

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 13:26:06 »

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

Понимаешь, Денис, ты вырвал фразу из контекста. Речь шла о том, что новичку будет сложно понять о том, что говорилось. Речь перемежалась англоязычным сленгом. Текст был англоязычный. Так, что о доступной форме, можно говорить с натяжкой. Да я признаю, что материал собран и, вероятно, взвешен коллегами из rational или IBM. Но он ориентирован на англоязычную аудиторию.

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