61

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 21 Июля 2011, 12:57:02 »

Для "хотелок", не связанных с основными бизнес-процессами использование такого подхода (нанять специалиста по конкретной системе) вполне оправдано.
Главное чтобы специалист не начал изобретать велосипед, и писать уникальную систему с 0.
Есть готовое решение 1С:Ресторан+Бар+Кафе на 7.7.

Вот мой еще один вариант минимизирующий оборудование и затраты на ПО.
1. Система (С) находится в режиме ожидания выбора пользователя:
Заказ
Отмена.
2. Обедающий (О) выбирает вариант Заказ.
2.1. С запрашивает сканирование карты, ожидает сканирования.
2.2. О сканирует карту
2.3. С переходит в режим формирования заказа, высвечивает текущее меню.
2.4. О выбирает блюда, завершает оформление заказа. Если отказывается от заказа возврат на шаг 1.
2.5. С печатает чек с составом заказа и шк заказа.
2.6. О передает чек работнику столовой (РС)
2.7. РС выдает блюда. Если выданы все блюда то сканирует ш/к, переход на ш. 2.8.
Исключение если блюда нет просит О отказаться от заказа и оформить новый. Обслуживание завершено. Возврат на ш. 1.
2.8. С по шк чека находит заказ, проставляет статус выдан. Обслуживание завершено. Возврат на ш. 1.
3. О выбирает вариант Отмена заказа
3.1. С ожидает сканирования шк на чеке
3.2. О сканирует шк чека
3.3. С отменяет действие заказа (если он не еще не отменен или не выдан). Обслуживание завершено. Возврат на ш. 1.

Оборудование: Касса на базе ПК, с сенсорным экраном, с доп оборудованием ридер магнитных карт, принтер чеков, сканер ШК (порядка 30 т.р.).
Поскольку реальных денег не пробивается то фискальный регистратор не нужен, кассовый ящик тоже, то можно взять обычнй моноблок и подключить к нему ридер и сканер ШК.
ПО: готовое решение 1С:Ресторан+Бар+Кафе на 7.7.
Доработка ПО под бизнес-процесс, без серьезного изменения основной функциональности конфигурации, 2-3 рабочих дня (порядка 20-30 т.р.).
В зависимости от перспектив "касса" подключается к локальной сети, для удаленного администрирования и управления. Для большей надежности базу можно разместить на сервере. Функциональность конфигурации используется только в той части какой нужно (либо тупо: "ведение меню, заказ, подтверждение, статистика" либо дополнительно: учет блюд, раскладка, учет продуктов, выгрузка в БД бухгалтерии и т.п).

62

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:52:39 »

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

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

63

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:28:00 »

Кстати, уважаемый, Galogen, пора бы уточнить первоначальную постановку указав там те ограничения что выявились в процессе обсуждения вариантов:
"Отказ от кассира"
"Ограничение по бюджету"
"Отсутствие необходимости оплаты"
и т.п.

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

64

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:04:10 »

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


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

65

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 09:12:25 »

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

66

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 18 Июля 2011, 17:48:06 »

из разделов :   работа,  дети, дом (ведение  хозяйств),  подработка ,  образование, и  уделение  внимания   друзьям  и родственникам.  Ах  да, еще  же  и  отдохнуть  надо   и   за  здоровьем  проследить.  Если  на него  забьешь, то это  автоматически  тебе   сделает  неспособным  выполнить почти все задачи из приведенного списка.
А  я  этого не понимаю,  поэтому не могу  рассчитать ни  время  ни  силы  толком .
Ошибаюсь .
Что еще  может  быть :  ступор .  Я торможу  в проблеме  выбора. .  Я не могу  понять , что важнее , поэтому никак не  могу  начать что-то делать.  И это  очень нервирует.  Стресс.
2) (Теоретическое )  Если  я буду    держать   эту  иерархию  в голове,   то я буду  понимать  общую  картину.  Т.е.  я буду  понимать  глобально что я делаю и зачем.
И  если  эта  картина  действительно  правильная, значит  я смогу прогнозировать результат  или по-крайней мере  отслеживать  я приближаюсь  к цели  или нет?
А также  общая картина позволит  находить другие  решения проблем , способы  достижения  целей.
Что  даст:
на мой взгляд  даст  более спокойную,  более  понятную, прогнозируемую   жизнь .

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

67

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 18 Июля 2011, 16:12:54 »

Как насчет - "через 5 лет зарабатывать 10 тыс долларов в месяц"?

Это не цель, это задача.
Цель "удовлетворение материальных потребностей", мета цель "удовлетворение личных потребностей" (будь то выживание, здоровье, комфорт, возможность реализации в группе, самореализации, и т.п. согласно классификации Маслоу).

68

Идеи и мозговой штурм / Re: Что влияет на качество документов Аналитика?

« : 15 Июля 2011, 11:30:36 »

Я думаю, это "трудности", а не "факторы, влияющие на качество".
Уважающий себя и свою команду аналитик не может сделать некачественную работу.

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

69

Проектирование / Re: Как стать Архитектором ПО ?

« : 13 Июля 2011, 14:16:54 »

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

70

Проектирование / Re: Как стать Архитектором ПО ?

« : 13 Июля 2011, 13:18:06 »

Меня же никто не возьмет с нуля на такую серьезную должность.
Сейчас же я сижу в конторе прогаю на С\С++\С# и SQL.
Мне не нравится проект в котором я занят, он представляет из себя большую вонючую кучу мусора, в которую гадили лет двадцать и вот теперь это досталось мне в наследство от старшего поколения. Там нет никакой архитектуры, ничего, работать т.к. уже никто просто не знает что там внутри творится. Работает как надо, да и ладно.
Зарплату конечно платят, но я не вижу для себя никакого проф. роста, ввиду того что все здесь говорит о том как НЕ надо работать =) А мне хочется попасть в контору, где я бы мог расти профессианально, где бы видел пример того как надо работать.
Это я для чего написал? Просто я высказал желание - где я хочу быть и где я нахожусь сейчас. Собсно что мне делать ? Какой следующий должен мой быть шаг? Искать другую работу?

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

71

Конференции Семинары и Тренинги / Re: Отзывы о ЛАФ 2011

« : 06 Июля 2011, 09:40:56 »

Опубликовал в блоге свою статью (сюда она не влезла, http://bit.ly/msIL7r), на основании которой готовил выступление на ЛАФ'11. Комментарии докладов привел в нормальный вид.

Спасибо, Алексей. Очень полезная статья.
К моему сожалению на ЛАФ'2011 попасть не смог.

72

Примеры / Re: Вопрос к гуру по диаграмме классов

« : 05 Июля 2011, 12:18:20 »

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

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

73

Примеры / Re: Вопрос к гуру по диаграмме классов

« : 05 Июля 2011, 12:08:50 »

это отдельная сущность?

Обычно добавляют атрибут дата начала действия и в алгоритмах ищут последний действующий объект.
может тогда данную связь можно организовать обобщением?

может тогда данную связь можно организовать обобщением?

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

74

Примеры / Re: Вопрос к гуру по диаграмме классов

« : 05 Июля 2011, 11:05:48 »

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

При этом адреса разных видов могут с течением времени меняться как сами адреса так и их типы (например после регистрации по месту проживания), в этом случае дополнительно вводят "периодичность"

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

Это обычно реализуется вводом сущности Физические лица.
с ассоциацией один к одному с сущностями Пациент, Сотрудник.
В вашем примере на объект ФИЗЛИЦО Петров будут ссылки как в из объекте Сотрудник так и из Пациент.

75

Поздравления / Re: Поздравляем Эда - Galogen'а с днем рождения!

« : 14 Июня 2011, 17:28:08 »

С Днем рождения!