Реальные примеры - безналичная оплата топлива на АЗС(Прочитано 18877 раз)
Значится так:

Поступил новый проект мне на разработку требований к системе.
После 10 минут разговоров удалось выяснить следующее:

Задача:
Есть проект, для которого необходимо разработать SRS (system, then software).

Цель проекта:
Обеспечить возможность безналичной оплаты топлива на АЗС для корпоративных клиентов.

Реализация:
Обеспечение безналичной оплаты планируется реализовать при помощи карт-идетификаторов при  поднесении которой заправка будет связываться с сервером и проверять\снимать деньги со «счета» клиента.
Каждый счет может иметь неограниченное количество карт привязанных к счету.
Система работает только при наличии непрерывной связи с сервером.

Ограничения системы:
Система должна только снимать деньги на основании заправленного бензина.
Система не должна управлять подачей топлива.
При поднесении карты система должна связаться с сервером и показать доступную сумму.
После заправки система должна снять деньги со «счета» клиента и вывести сообщение об оплате.
При недостатке денег на «счете» клиента система должна сообщить о недостаточности средств на счету. Снять деньги со счета и вывести сообщение о недостающей сумме. Доплата суммы контролируется вне системы, средствами персонала АЗС.

Бизнес – прецеденты при безналичной оплате.

Покупатель:
Заправка топливом (устная просьба)
Оплата топлива (поднесение карты)

Информация о состоянии счета
Информация о снятии денег со счета
Получение чека

Кассир:
Заправка топлива
Проверка оплаты


Администратор:
Указание цены на топливо.
Создание\редактирование\удаление клиента
Создание\редактирование\удаление счетов для клиента
Создание\редактирование\удаление карточек для счета клиента
Внесение денег на счет клиента.
Выдача денег со счета клиента
Просмотр статистики (TBD)

Владелец счета:
Устная просьба к администратору
Просмотр статистики? (устная просьба к админу на распечатку отчета?)



Основная проблема в том, что система разрабатываться будет на основании наименьшего сопротивления с точки зрения оборудования. Отсюда и ее …… странность

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


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




Для начала хотелось бы определиться в чем (UML, DFD, IDEF) можно сделать наброски диаграмм (и диаграмм чего), что бы можно было общаться с заказчиком. Представить свое виденье, и соответственно после вопросво-ответов внести изменения в диаграммы.



Для начала хотелось бы определиться в чем (UML, DFD, IDEF) можно сделать наброски диаграмм (и диаграмм чего), что бы можно было общаться с заказчиком. Представить свое виденье, и соответственно после вопросво-ответов внести изменения в диаграммы.

Читая книгу Рамбо и Блаха, UML 2.0 ОО моделирование и разработка, можно подчерпнуть следующие моменты.

1. Концептуализация системы.
1.1. Изобретение концепции (у тебя она в целом есть)
1.2. Проработка концепции
1.2.1. Для кого предназначено приложение? (спонсоры и конечные пользователи)
спонсоры оплачивают разработку и важно получить добро
конечные пользователи будут работать с системой
1.2.2. Какую задачу приложение будет решать
ограничить масштаб усилий и установить область их применения. функции, которыми будет обладать система, а какими не будет
1.2.3. Где будет использоваться система
1.2.4. Когда будет нужна система
1.2.5. Почему нужна система
1.2.6. Как она будет работать (предложить некий прототип, возможно структуру, например автоматы АЗС - связаны с ЦК, то связан с ПК банка и т.п. или это кассовые терминалы)
2. Постановка задачи - нестрогое, понятное клиенту описание сути видения приложения. Рисовать можно в любой нотации, заменять графически примитивы картинками и т.п.)
3. Анализ предметной области - фактическое построение концептуальной диаграммы классов
3.1. выделение классов - избегать классов реализации, только классы предметной области
3.2. выделение  ассоциаций
3.3. выделение атрибутов
3.4. проверка маршрутов с помощью OCL
3.5. построение диаграммы состояний для объектов изменяющих свое состояние (например для счета в твоем случае - вряд ли больше)
3.6. модель взаимодействий - обычно не используется
4. Анализ приложения
4.1. Модель взаимодействия приложения
4.1.1. Границы системы
4.1.2. Действующие лица
4.1.3. Варианты использования
4.1.4. начальные и конечные события по каждому ВИ
4.1.5. Типовые сценарии - вполне понятные даже людям далеким от ИТ
4.1.6. Сценарии-вариации и исключительных событий
4.1.7. Внешние события
4.1.8. Диаграммы деятельностей - только для сложных ВИ
4.1.9. Структуризация ВИ и ДЛ
4.1.10 проверка по модели классов
4.2. Модель классов приложения
4.2.1. Интерфейсы пользователей
4.2.2. Пограничные классы
4.2.3 Управляющие объекты
4.2.4. Валидация по модели взаиможействия
....

Таким образом - нужно стремится использовать UML, но никто вовсе не запрещает использовать и все остальное



Бизнес – прецеденты при безналичной оплате.

Покупатель:
Заправка топливом (устная просьба)
Оплата топлива (поднесение карты)

Информация о состоянии счета
Информация о снятии денег со счета
Получение чека

Кассир:
Заправка топлива
Проверка оплаты


Администратор:
Указание цены на топливо.
Создание\редактирование\удаление клиента
Создание\редактирование\удаление счетов для клиента
Создание\редактирование\удаление карточек для счета клиента
Внесение денег на счет клиента.
Выдача денег со счета клиента
Просмотр статистики (TBD)

Владелец счета:
Устная просьба к администратору
Просмотр статистики? (устная просьба к админу на распечатку отчета?)


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

1. Реально бизнесс-юзкейсов у вас не предствалено. То что предствалено -- это функциональная дексмпозиция работы оператора и кассира и покупателя. С т.з. бизнес-юзкейсов, у вас должен быть только эктор Покупатель, у которого одна единтсвенная цель -- получить бензин. Для достижения этой цели он взаимодействует с Оператором и Кассиром (которые есть business workers, по большому счету).
2. Описав сценарий бизнес-юзкейса, можно опускаться на уровень системных юзкейсов. Тут экторами будут выступать уже Оператор и кассир. И тут нужно более детально посмотреть на их цели по отношению к системе.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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

Вобщем нашел немного времени и сделал диаграммы бизнес процесса (только обслуживание), бизнес и системных ВИ.
Много вопросов возникло по поводу как правильно их рисовать, думал несколько вариантов представить, как мне думалось нарисовать. Но нету времени.

Буду очень рад критике как по самим диаграммам с точки зрения ЮМЛ, с точки зрения правильности и содержательности, так и дальнейшим шагам, и.п.

П.С. Сорри что тему создал, а времени особо нету заниматься - времени нету на проект и на форум соответственно:(

Всем еще раз огромное спасибо!

П.П.С. Бизнес процесс на АЗС довольно таки сжатый, заправщик он же и кассир, выполняет все действия.


Вот картинки:




Александр.

Думаю. здесь на форуме уже было достаточно дискуссий по поводу того, как следует представлять свои задачи для обсуждения.
Я понимаю, что многое из заявленного достаточно прозрачно и тем не менее. Если и ставить задачу, то ставить ее достаточно точно. Пусть не полно, это нормально для постановки задачи. Четкое понимание того, что нужно дает и четкое понимание тех диаграмм, что были изображены.

Очевидно, что имеет смысл начать с проблемы. Что за проблема, с чем она связана, почему возникла, кого она затрагивает, что получается не так, как хотелось. А как хотелось.
Вероятно, помимо безналичной оплаты будет оплата и за наличные деньги. Если нас интересует безналичная оплата, то почему такая ситуация возникла. Что требуется для ее организации, чем будет отличаться безналичная оплата от оплаты за наличные. Что занчит оплата по картам. Какое участие в этом принимает клиент? Что означает поднести карты, куда ее следует подносить? что будет при этом?

Нужен для анализ бизнес-процесса? Если это новый бизнес-процесс, какие есть аналоги. Внедряется совершенно новое исполнение или за основу берутся существующие опробированные решения?

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

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

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



Как будет выглядеть сценарий для UC "Узнать стоимость"? Может это полсьл часть UC "Купит топливо", который может просто привести к завершению юзкейса, если цена не устроит?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Как будет выглядеть сценарий для UC "Узнать стоимость"? Может это полсьл часть UC "Купит топливо", который может просто привести к завершению юзкейса, если цена не устроит?
Постараюсь перевести вопрос с русского на русский.
Как будет выглядеть сценарий для UC "Узнать стоимость"? Может это только часть UC "Купить топливо", который может просто привести к завершению юзкейса, если цена не устроит покупателя топлива?

Думаю имеет смысл задать вопрос: для чего необходимо узнать стоимость топлива? Для того, чтобы принять решение? какое? Покупать или не покупать? Тогда как это согласуется с принципом безналичного расчета? Покупатель топлива может на свою магнитную карту покупать топливо в любой заправке? или только в той, фирма которой выпускает конкретную магнитную карту? В последнем случае знание стоимости топлива ничего принципиально не меняет, тем более факт стоимости обычно вывешивается на обочине как рекламный щит.
« Последнее редактирование: 25 Февраля 2007, 16:14:52 от Galogen »



Эд, спасибо за корректировку ... просто беда какая-то, как тороплюсь -- делаю бешенное кол-во ошибок, а исправлять после публикации ... ну вобщем как всегда :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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



Спасибо Эдуард, спасибо Юрий.


Думаю. здесь на форуме уже было достаточно дискуссий по поводу того, как следует представлять свои задачи для обсуждения.
Я понимаю, что многое из заявленного достаточно прозрачно и тем не менее. Если и ставить задачу, то ставить ее достаточно точно. Пусть не полно, это нормально для постановки задачи. Четкое понимание того, что нужно дает и четкое понимание тех диаграмм, что были изображены.
Какую задачу вы имеете в виду?
Задачу которую я хочу достигнуть я написал в первом посте.
Имеется в виду цель данных диаграмм?
Или задача которую я ставлю форумчанам вывешивая свои посты\диаграммы?
Не совсем понял что мне нужно более точно ставить, какую задачу?

Цитировать
Очевидно, что имеет смысл начать с проблемы. Что за проблема, с чем она связана, почему возникла, кого она затрагивает, что получается не так, как хотелось. А как хотелось.
Вероятно, помимо безналичной оплаты будет оплата и за наличные деньги. Если нас интересует безналичная оплата, то почему такая ситуация возникла. Что требуется для ее организации, чем будет отличаться безналичная оплата от оплаты за наличные.
Проблема мне не известна, я ее не узнаю.
Решение о внедрении системы уже принято, на каких основаниях - неизвестно.
Известно что есть и что должно быть. Оплата отличается только тем что никто из пользователей заправки не будет видеть денюжку.

Цитировать
Что занчит оплата по картам. Какое участие в этом принимает клиент? Что означает поднести карты, куда ее следует подносить? что будет при этом?
Клиент подносит карту-идентификатор. Так сказать ID, к считывателю, который узнает ID карты. Сверяет с БД, что это за аккаунт, есть ли на нем деньги, показывает сколько денег, при заправке автоматически снимает указанную сумму с счета этого аккаунта.

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


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

Цитировать
далее диаграмма бизнес-юзкейсов. - где граница системы? кто тут основное действующее лицо? кто внешнее, кто исполнитель.
Очевидно покупатель топлива - внешнее лицо, инициатор процесса покупки топлива. Заправщик - лицо, исполняющее - это часть системы.
Если диаграмма должна отражать бизнес- как прозрачный ящик, то как все-таки это происходит. Не лучше ли сначала написать текстовый сценарий?
Более чем справедливо, не знаю я как правильно это все отображать. Хотелось бы увидеть примеры, что-бы разобраться как необходимо это изображать.

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

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

Цитировать
Диаграмма системных ВИ: почему отображена связь между Покупателем и заправщиком?
Разве у покупателя есть такая цель - Узнать объем топлива? И он обращается к системе для этого?
Заправить топливо - разве сделать запись о продаже не включается в процесс Заправить топливо.
Вопросов больше чем ответов на мой взгляд.
Я связь отобразил т.к. Покупатель - сообщает заправщику что ему нужно, какой бензин, в каком количестве,
Покупатель может посмотреть на информацию та дисплее колонки - сколько литров залито, какая стоимость залитого топлива.
(почему это ВИ? - ИМХО можно скрывать это от пользователя. Мелкий ВИ- согласен, может и не нужно его показывать, но ИМХО можно.)



Как будет выглядеть сценарий для UC "Узнать стоимость"? Может это полсьл часть UC "Купит топливо", который может просто привести к завершению юзкейса, если цена не устроит?

Простите - имел в виду узнать объем заправленного топлива и сумму за это заправленное топливо. Имелось в виду что это отображается на индикаторе заправочной колонки.


Вот переписанные БМВИ и ВИ системы.
Надеюсь понятна цель данных диаграмм. Хотелось бы услышать критику по диаграммам.
Если не понятно, и что-то пропущено, то я напишу текстовые сценарии работы на этих АЗС.

Как разберусь с "is" тогда и перешагну к "to be". to-be в принципе определен не мной, и вариантов улучшений у меня не много, основная задача при создании SRS к системе и ПО, что-бы небыло ляпов в системе и ПО, плюс в рамках придуманного БП сделать как можно более удобную систему.

Надеюсь я читабелен, и надеюсь более или менее понятен и последователен.
К сожалению нету времени заниматься этим проектом и тем более уточнять детали. К уточнению деталей приступлю как создам грубые модели "is" и "to be". Сейчас моя цель - создать их правильными ч точки зрения семантики.
Я чувствую что плаваю тут.

+Сказывается что занимаюсь этим после рабочего дня:)



Вот удалось сутра немного подумать, решил написать текстовый вариант.

Бизнес Прецеденты:
1. Заправить топливо

Сценарии:
Заправить топливо:
1. Сообщить заправщику тип и объем заправляемого топлива
2. Дождаться выполнения работы заправщиком
3. Посмотреть показатели счетчика: увидеть залитый объем и сумму к оплате.
4. Произвести оплату заправленного топлива
5. Получить чек

Актеры:
Покупатель

Business worker:
Заправщик




Системные Прецеденты:

1. Заправить топливо
1.1. Выбрать тип топлива
1.2. Проконтролировать заправляемый объем
1.3. Получить чек
2. Видеть показатели счетчика (стоит или не стоит выводить это а прецедент, буду рад прояснениям.)
Есть ли такой тип описания ВИ???

Или нужно описывать:
1. Заправить топливо
2. Видеть показатели счетчика
Сценарии:
….

Сценарии:
- Подскажите, не знаю до какого уровня спускаться.
Пример 1:
1. Выбрать тип топлива (просто берется тот или иной пистолет\шланг)
2. Заправить топливо
2.1. Вставить пистолет
2.2. Отпустить фиксатор (начать подачу топлива?)
2.3. Дождаться необходимых показателей счетчика топлива\суммы или отстрела пистолета.
2.4. Вытащить пистолет
2.5. Установить пистолет в исходную позицию
3. Посмотреть показатели счетчика
4. Сообщить сумму покупателю
5. Взять оплату
6. Выдать чек.

Пример 2:
1. Заправить топливо
1.1. Взять пистолет
1.2. Вставить пистолет
1.3. Отпустить фиксатор
1.4. Дождаться необходимых показателей счетчика или отстрела
1.5. Вытащить пистолет
1.6. Установить пистолет в исходную позицию.
Сценарии:

Актеры:
Заправщик
Покупатель


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

Буду рад услышать критику и детальные объяснения, что не так, чтобы создать текстовое описание, а потом построить модели.

Потом к “to be” можно будет перешагнуть.



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

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

Если ты планируешь описать процесс AS IS - а в твоем случае это покупка топлива за наличные - так и описывай этот процесс.

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


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

Для успешного решения задачи советую:
1. Понять, что нужно делать
2. Выделить область действия задачи
3. Построить модель Действующие лица и цели (Можно в виде таблицы, а можно в виде диаграммы вариантов использования, но без связей включения и расширения)
4. Построить модель Участники и интересы (т.е. расширить модель ДЛ и цели, посредством перечислением всех участников и их интересов, это можно сделать и при описании сценария)
5. Только после уяснения этого этапа - можно идти к этапу описания системы или придумывания системы.

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

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

Ну или как то подругому, тут и есть идея придумывания.


Теперь от твоих диаграммах.

Я не вижу тут бизнес-процесса. Правила рисования насколько я знаю запрещают взаимодействие ДЛ кроме как через ВИ или связи обобщения.

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



ну начнем разбор полетов
Цитировать
Бизнес Прецеденты:
1. Заправить топливо

Сценарии:
Заправить топливо:
1. Сообщить заправщику тип и объем заправляемого топлива
2. Дождаться выполнения работы заправщиком
3. Посмотреть показатели счетчика: увидеть залитый объем и сумму к оплате.
4. Произвести оплату заправленного топлива
5. Получить чек

Актеры:
Покупатель

Business worker:
Заправщик
Сценарий нужно писать от лица действующих лиц. Пинг-понг, передача мяча, как пишет Кобрен.
Сценарии:
Основной поток(успешный)
Заправить топливо:
1. Покупатель сообщает заправщику тип и объем заправляемого топлива
2.  Заправщик заправлет машину покупателя топливом.
3. Заправщик вычисляет и сообщает стоимость заправки.
4. Покупатель производит оплату заправленного топлива
5. Заправщик выбивает чек.
6. Покупатель получает чек.

По системным прецедентам.
Заправщик работает с системой, чем бы она не была. Описание идет в стиле "черный ящик"

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

Если система работает с магнитной картой - это факт отражается где-то, это как раз и будет усовершенствание процесса



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

Спасибо Эдуарду за помощь, многое прояснилось.




 

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