Работаю в банке на поддержке АБС. Звонит операционист: «Набираю дату рождения, и программа не даёт ничего сделать: не пропускает дальше, не делает отмену операции, тупо не выходит из поля ввода даты».
Подключилась через Радмин, смотрю: вроде всё правильно. Перебила дату лично, так, на всякий случай: 31.04.1957. Так, стоп, с каких это пор у нас в апреле 31 день?.. Попыталась указать операционистке на её тупость. Однако это не она умом обделённая оказалась. Не то паспортисты рехнулись, выдав документ с такой датой, не то клиентка, счастливо празднующая день рождения 31 апреля, не то все они вместе взятые.
Таких фокусов как 31 апреля у меня не случались, но зато как бы кой-чего не похуже было. Например, занимались оцифровкой архива некоей госорганизации, в этом архиве все бумаги должны были, просто по определению, иметь разный номер, ибо бумаги официальные и в том их в каком-то роде и смысл был, что у каждой свой номер. Разработчики СУБД ничтоже сумняшеся сделали поле с этим номером ключевым. И конечно же, в итоге, некоторые документы таки имели одинаковые номера. И это было не опечаткой. Справедливости ради, скажу, что это было исключительным случаем и таких пар набралось всего около десятка на весь архив и тем не менее, я лишний раз убедился, при разработке автоматизированных систем, имеющих дело с входными документами, следует иметь ввиду, что там может быть ВСЕ. Даже то, чего быть не может.
Здравствуйте, Michael7, Вы писали:
M>Таких фокусов как 31 апреля у меня не случались, но зато как бы кой-чего не похуже было. Например, занимались оцифровкой архива некоей госорганизации, в этом архиве все бумаги должны были, просто по определению, иметь разный номер, ибо бумаги официальные и в том их в каком-то роде и смысл был, что у каждой свой номер. Разработчики СУБД ничтоже сумняшеся сделали поле с этим номером ключевым. И конечно же, в итоге, некоторые документы таки имели одинаковые номера. И это было не опечаткой. Справедливости ради, скажу, что это было исключительным случаем и таких пар набралось всего около десятка на весь архив и тем не менее, я лишний раз убедился, при разработке автоматизированных систем, имеющих дело с входными документами, следует иметь ввиду, что там может быть ВСЕ. Даже то, чего быть не может.
Т.е. отныне все поля в БД должны быть BLOB?
Вообще, для таких случаев пишется документ, называется ТЗ. ТЗ + договор успешно решает эту проблему.
M>Работаю в банке на поддержке АБС. Звонит операционист: «Набираю дату рождения, и программа не даёт ничего сделать: не пропускает дальше, не делает отмену операции, тупо не выходит из поля ввода даты».
M>Подключилась через Радмин, смотрю: вроде всё правильно. Перебила дату лично, так, на всякий случай: 31.04.1957. Так, стоп, с каких это пор у нас в апреле 31 день?.. Попыталась указать операционистке на её тупость. Однако это не она умом обделённая оказалась. Не то паспортисты рехнулись, выдав документ с такой датой, не то клиентка, счастливо празднующая день рождения 31 апреля, не то все они вместе взятые.
Кстати, этот случай сложнее твоего с оцифровкой, т.к. твою проблему можно было решить не выходя из госорганизации. Тут же источник проблемы находится за рамками конторы.
С одной стороны, вроде как можно доработать систему и разрешить ввод неправильных значений, но с другой — неизвестно, где потом это значение дальше будет использоваться.
Думаю, эту проблему надо выносить на руководителя проекта и выше — много вариантов решения. Думаю, наилучший: разработчик учитывает данную особенность доп. соглашением к договору и дорабатывает этот функционал, т.е. "любое ваше желание за ваши деньги".
Здравствуйте, Real 3L0, Вы писали:
R3>Вообще, для таких случаев пишется документ, называется ТЗ. ТЗ + договор успешно решает эту проблему.
Решает возможно проблемы разработчика по общению с заказчиком, но никак не описанную проблему.
Здравствуйте, Рома Мик, Вы писали:
R3>>Вообще, для таких случаев пишется документ, называется ТЗ. ТЗ + договор успешно решает эту проблему. РМ>Решает возможно проблемы разработчика по общению с заказчиком, но никак не описанную проблему.
Ну, если ты готов решать проблемы компании за свой счёт и время, то вперёд. Это всё равно, что протягивать локальную сеть в здании и заодно починить водоснабжение.
Здравствуйте, Real 3L0, Вы писали:
R3>Т.е. отныне все поля в БД должны быть BLOB?
Ну не настолько экстремально, конечно Но вот закладываться, на то что реальные данные всегда будут только какие оговорены, не стоит. Есть разные способы решения проблемы, в той с которой я столкнулся, завели на эти документы совершенно отдельную категорию
R3>Вообще, для таких случаев пишется документ, называется ТЗ. ТЗ + договор успешно решает эту проблему.
Позволяет разработчику "умыть руки", да. Но проблему не решает.
R3>Кстати, этот случай сложнее твоего с оцифровкой, т.к. твою проблему можно было решить не выходя из госорганизации.
Вообще-то в руководстве организации был по этому поводу некоторый скандал, благо люди при которых такая лажа случилась уже давно не работали в ней и тем не менее.
R3> Тут же источник проблемы находится за рамками конторы. R3>С одной стороны, вроде как можно доработать систему и разрешить ввод неправильных значений, но с другой — неизвестно, где потом это значение дальше будет использоваться.
Возможно, можно было рискнуть ввести другое значение, не то, что в паспорте.
R3>Думаю, эту проблему надо выносить на руководителя проекта и выше — много вариантов решения. Думаю, наилучший: разработчик учитывает данную особенность доп. соглашением к договору и дорабатывает этот функционал, т.е. "любое ваше желание за ваши деньги".
Заказчикам, конечно стоит иметь ввиду, на этих примерах, что любая система в ходе реальной эксплуатации может столкнуться с непредвиденными случаями.
Здравствуйте, Michael7, Вы писали:
R3>>Кстати, этот случай сложнее твоего с оцифровкой, т.к. твою проблему можно было решить не выходя из госорганизации. M>Вообще-то в руководстве организации был по этому поводу некоторый скандал, благо люди при которых такая лажа случилась уже давно не работали в ней и тем не менее.
Предполагаю, но вообще, с описанным случаем я несколько раз сталкивался. Решали по разному.
R3>> Тут же источник проблемы находится за рамками конторы. R3>>С одной стороны, вроде как можно доработать систему и разрешить ввод неправильных значений, но с другой — неизвестно, где потом это значение дальше будет использоваться. M>Возможно, можно было рискнуть ввести другое значение, не то, что в паспорте.
Да, думаю, можно было бы использовать следующую дату, как с "29 февраля".
Здравствуйте, Michael7, Вы писали:
M>Работаю в банке на поддержке
в одноэсе подобное решено просто — система после ввода несуществующей даты подставляет следующий день. т.е. в данном случае в поле для ввода просто бы появилось 1 мая.
Здравствуйте, Michael7, Вы писали:
M>счастливо празднующая день рождения 31 апреля, не то все они вместе взятые. M>Таких фокусов как 31 апреля у меня не случались
И напрасна такая пионерская уверенность, т.к. все еще живы люди имеющие в дате рождения только год. И вполне официально, и с ними работают, и их обслуживают )
Здравствуйте, susumanin, Вы писали:
S>Здравствуйте, Michael7, Вы писали:
M>>Работаю в банке на поддержке
S>в одноэсе подобное решено просто — система после ввода несуществующей даты подставляет следующий день. т.е. в данном случае в поле для ввода просто бы появилось 1 мая.
А в результате клиентка не сможет получить свои деньги — в документах банка и в паспорте окажуться разные даты.
Для клиентки это повод обратиться в ЗАГС и паспортный стол для смены документов.
M>Таких фокусов как 31 апреля у меня не случались, но зато как бы кой-чего не похуже было.
Мне как-то на полном серьезе сделали пропуск на склад одной организации до 31 февраля. Девочка, делавшая его, ступила, а утверждающее начальство, как я понимаю, тупо не глянуло, что подписывает.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>Заказчикам, конечно стоит иметь ввиду, на этих примерах, что любая система в ходе реальной эксплуатации может столкнуться с непредвиденными случаями.
Описанный случай — не непредвиденный. Это тупо следствие чей-то ошибки. Причем точно не разработчиков, так как в тз черным по белому написано было, что одинаковых номеров быть не может.
Однако же было решено добавлять костыли, вместо того, чтобы найти и устранить иходную проблему. Почему получилось два дока с одинаковым номером — вот что нужно было выяснять.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
S>в одноэсе подобное решено просто — система после ввода несуществующей даты подставляет следующий день. т.е. в данном случае в поле для ввода просто бы появилось 1 мая.
Джавовский календарь по-умолчанию вообще забавно работает. Из 31 апреля он делает 1 мая. Из 32 второе мая. Из 62 арпеля получится замечательное 1 июня .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Michael7, Вы писали:
M>Таких фокусов как 31 апреля у меня не случались, но зато как бы кой-чего не похуже было. Например, занимались оцифровкой архива некоей госорганизации, в этом архиве все бумаги должны были, просто по определению, иметь разный номер, ибо бумаги официальные и в том их в каком-то роде и смысл был, что у каждой свой номер. Разработчики СУБД ничтоже сумняшеся сделали поле с этим номером ключевым. И конечно же, в итоге, некоторые документы таки имели одинаковые номера. И это было не опечаткой. Справедливости ради, скажу, что это было исключительным случаем и таких пар набралось всего около десятка на весь архив и тем не менее, я лишний раз убедился, при разработке автоматизированных систем, имеющих дело с входными документами, следует иметь ввиду, что там может быть ВСЕ. Даже то, чего быть не может.
Если такая ситуация возникла, то ИМХО из нее есть 2 выхода.
1. Категорически заявить, что , поскольку в соответствии с ТЗ дубликаты невозможны, новый документ с существующим уже номером система принимать НЕ БУДЕТ, и решение этой проблемы за пределами программного продукта. Пусть меняют номера.
2. Если (1) заказчика не устроит, требовать отмены пункта об уникальности номеров в ТЗ.
Здравствуйте, Eugeny__, Вы писали:
E__>Описанный случай — не непредвиденный. Это тупо следствие чей-то ошибки. Причем точно не разработчиков, так как в тз черным по белому написано было, что одинаковых номеров быть не может. E__>Однако же было решено добавлять костыли, вместо того, чтобы найти и устранить иходную проблему. Почему получилось два дока с одинаковым номером — вот что нужно было выяснять.
Документы с одинаковыми номерами сделаны много лет назад, и десять и двадцать и более лет назад. При совсем другой системе их выдачи. Что тут можно поменять или выяснить? Никто эти документы переделывать не станет, да и это и сильно проблематично с юридической точки зрения. Остается только учесть с помощью костылей. Хотя факт подобного кофуза лично меня сильно доставил.
строго говоря, паспорт с датой рождения 31 апреля является недействительным документом со всеми вытекающими. Обладательница данного документа (если, конечно, она его не вчера получила) дура и ССЗБ.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если такая ситуация возникла, то ИМХО из нее есть 2 выхода.
PD>1. Категорически заявить, что , поскольку в соответствии с ТЗ дубликаты невозможны, новый документ с существующим уже номером система принимать НЕ БУДЕТ, и решение этой проблемы за пределами программного продукта. Пусть меняют номера.
Поменять номера невозможно. Парам дублей уже больше десятка лет и есть юридические тонкости, не позволяющие это сделать.
PD>2. Если (1) заказчика не устроит, требовать отмены пункта об уникальности номеров в ТЗ.
PD>Либо — либо.
PD>А не искать обходные решения.
Понимаете, основания чтобы ругаться и чего-то доказывать в свою пользу конечно же есть и строго говоря это действительно не вина разработчиков. Да разработчики все сделали по ТЗ и не колышет, как говорится.
Вот только, как мне кажется, более высокий уровень профессионализма — это в том числе и умение предвидеть возможность наличия таких проблем, в том числе еще на стадии написания ТЗ, которое обычно разработчик и пишет, а заказчик только проверяет. В копилку такого опыта я привел пример проблемы.
Здравствуйте, Michael7, Вы писали:
M>Таких фокусов как 31 апреля у меня не случались,
А если месяц в документе будет — мартобрь, вы б ему какой номер в своих «хаках» присвоили?
Я тут подумал, может это поддельный паспорт, сделаный у слегка укуренных поддельщиков. Интересно с юридической точки зрения, обязаны ли вы принимать любой паспорт, который вам принесут? А если там будет прописка в Антарктиде? Или серия-номер 6666 666666? Ящерица в шляпе на фотограции? Или «Выдан господом богом»? Может ему стоило отдать паспорт вместе с человеком в милицию. Они в крайнем случае сразу бы с паспортным столом у себя там разобрались.
Имхо в случае с паспортом ничего в системе менять не надо. Налицо недействительный паспорт, что означает отсутствие действительного.
Здравствуйте, Michael7, Вы писали:
M>Поменять номера невозможно. Парам дублей уже больше десятка лет и есть юридические тонкости, не позволяющие это сделать.
Эх, смотрю я — съэкономили вы на аналитике при внедрении.
Как я уже говорил — решение есть. И всё в рамках закона.
Будем разбираться или на слово поверишь?
M>Понимаете, основания чтобы ругаться и чего-то доказывать в свою пользу конечно же есть и строго говоря это действительно не вина разработчиков. Да разработчики все сделали по ТЗ и не колышет, как говорится.
Это первое, что надо вбить себе в голову. Когда вы (как компания разработчик) сможете вбить это в голову себе, то затем сможете вбить это и заказчику. И разбираться уже будете совместно. А это уже бОльшая часть решения проблемы. Судя же по описанию проблемы, вы получили от заказчика "сюрприз" и тупо бросились его реализовывать, не разбираясь.
M>Вот только, как мне кажется, более высокий уровень профессионализма — это в том числе и умение предвидеть возможность наличия таких проблем, в том числе еще на стадии написания ТЗ, которое обычно разработчик и пишет, а заказчик только проверяет. В копилку такого опыта я привел пример проблемы.
+1. Только я не понял, как это связано с предыдущим абзацем.
: 4000654 
— в документах банка и в паспорте окажуться разные даты. 
