Очень кратко суть: однажды на форуме ixbt заметили очень странную штуку, что оказывается есть файл, который, если записать его на CD-R(W) на большом количестве приводов потом нормально не считывается и это не связано с качеством болванки и записи, а только с уникальной сигнатурой внутри.
Причем ошибка чтения такого диска происходит в любых ОС и с любыми драйверами.
Я удивлен, но в 2003-м году еще не перевились настоящие спецы и багу раскопали. Проблема оказалась в том, что в очень уникальном случае эта сигнатура при записи на CD-R совпадает с сигнатурой для сектора синхронизации и происходит сбой. Видимо, те кто писал прошивки к приводам дисков, полагали, что раз вероятность совпадения настолько низкая, что за все время существования cd-rom технологии она может не встретиться, то и принимать меры на столь потенциально редкий случай не стоит. Обезьяны не напечатают случайно барабаня по клавишам "Войну и Мир".
Тонкая ошибка в рассуждениях здесь заключалась в том, что действительно вероятность случайно встретить специфическую последовательность байт невелика, но она может возникнуть и неслучайно! Конкретно в той статье она возникла из-за поломки привода, который выдал синхропоследовательность вместо данных на диске. И вероятность такой поломки оказалась не так и мала.
Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Здравствуйте, Michael7, Вы писали:
M>По результатам этой статьи: http://www.ixbt.com/optical/magia-chisel.shtml
M>Очень кратко суть: однажды на форуме ixbt заметили очень странную штуку, что оказывается есть файл, который, если записать его на CD-R(W) на большом количестве приводов потом нормально не считывается и это не связано с качеством болванки и записи, а только с уникальной сигнатурой внутри.
Спасибо за статью.
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
Здравствуйте, Michael7, Вы писали:
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
это баян еще времен первого нетскейпа
G>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
It depends.
Не дай бог разработчики ПО для АЭС примут такую рекомендацию .
Для банков, впрочем, тоже.
Здравствуйте, Michael7, Вы писали:
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
Если я правильно понял, проблема в самой идее использовать какую бы то ни было последовательность в качестве основы синхронизации. Такой подход изначально некорректен.
Впрочем, я не очень разбираюсь в физике CD-привода, поэтому допускаю, что иного выбора просто нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
PD>It depends.
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>Для банков, впрочем, тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>Для банков, впрочем, тоже.
G>>Ни те, ни другие этот форум не читают.
PD>Я знаю по крайней мере одного человека с RSDN, который принимал (правда, небольшое) участие в написании ПО для банка. Хорошо его знаю
Я тоже принимал участие в разработке по для банка, но это был не проессинг и для него верно то, что я написал.
M>Мораль сей басни такова: даже если некое событие имеет чрезвычайно низкие шансы встретиться, но не вовсе невозможно, в хорошей программе, стоит предусмотреть реакцию на него. Хотя бы потому что с оценкой шансов можно и ошибиться, причем так, что в голову не придет.
как бы то ни было на нижних (железных и околожелезных) уровнях это неизбежно.
Другой хороший пример -- это git -- он считает, что хэш двух разных коммитов не может совпадать, хотя чрезвычайно маленькая вероятность этого есть.
В твоем примере планируемая вероятность сбоя была видимо чрезвычайно низка и допустима.
Но из-за неправильной реализации она оказалась недопустимо высокой.
Скажем, если бы при записи привод шифровал информацию с новым сгенерированным паролем, то этого бы не произошло.
Но зато у такого решения были бы другие проблемы.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
PD>It depends.
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию .
Такую рекомендацию используют, скажем, разработчики железяк для самолетов, и, наверное, ПО тоже. У них правда пороги не 80%, а повыше, но тем не менее, у них есть понятие "очень редко встречающийся дефект".
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Еще веселее получается, когда разработчик, считая какую-либо величину случайной, строит поверх нее защищенность своего приложения. Из последнего: http://habrahabr.ru/company/pt/blog/149746/
Использование в генераторе сессионных токенов md5 не является фактором, определяющим успешность той конкретной атаки. Ошибка разработчиков PHP заключалась не в использовании этого алгоритма. А вот цитате из статьи в википедии же следовало бы звучать так: MD5 should be considered cryptographically broken and unsuitable for further cryptographic use.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>>Для банков, впрочем, тоже.
DM>В банках порой качество внутреннего софта ниже плинтуса.
Софт бывает разный. Один бумажки учитывает, другой процессит платежи или управляет активами. В последних случаях одно неловкое движение и огребете по полной.
Здравствуйте, gandjustas, Вы писали:
G>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
С точки зрения маркетинга — да, с точки зрения программиста — нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не дай бог разработчики ПО для АЭС примут такую рекомендацию . PD>Для банков, впрочем, тоже.
О, Павел, вы, право же, переоцениваете банковский софт. Его глюкавость значительно выше среднего — по банальным причинам:
1. Во главу угла ставится вовсе не надёжность, а скорость обновления в ответ на быстроменяющиеся требования
2. Огромный объём функционала. Грубо говоря, для MS Word мы имеем примерно 500.000.000 пользователей. Даже если поделить их на ~1500 операций, доступных в ворде, и даже если учесть то, что самые редкие из них используются примерно на четыре порядка реже самых частых, мы всё ещё видим как минимум ежедневное использование каждой операции. Для банковского софта типична ситуация, когда количество возможных операций на порядок превышает количество пользователей. Тем более, что примерно 80% функций в нём делаются под запросы конкретного клиента.
3. Отсутствие возможности полного тестового покрытия. У типичного банка — терабайты данных; возможности "накатить апгрейд" на реальную базу и прогнать все регрессионные тесты нет даже в теории.
4. Низкая квалификация персонала. Из-за большого объёма работы, возможности держать маленькую сплочённую команду профессионалов нет; набирается народ с минимальными техническими познаниями, и после краткого натаскивания на используемые тулзы и библиотеки бросается в бой. Текучка кадров — значительная, т.к. задачи неинтересные, оплата невысокая, мораль — низкая.
В итоге, результат вполне предсказуем: низкокачественное ПО с огромным количеством ошибок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В итоге, результат вполне предсказуем: низкокачественное ПО с огромным количеством ошибок.
Хм...
Пример с Word мне не кажется особенно удачным. Word — гораздо более сильносвязанная система (особенно если там есть VBA-макросы). Небольшое изменение может првести к переформатированию всего текста.
Я, конечно, никак не могу считать себя специалистом в области банковского софта, но как пользователь его (физический), могу отметить следующее. Там, по сути, есть операции 1:0 (взять/положить наличные на счет) и 1:1 (перевести с одного счета на другой, заплатить, например). Насчет операции 1:2 — не помню, чтобы такие были, они будут просто выполняться как две операции 1:1. Для юрлиц, наверное, сложнее, но и там вряд ли есть вариант N:M, скорее всего, он разбивается на N или M операций.
Так что реально различных операций не так уж много, не миллиарды, а скорее тысячи, если не сотни. Ну а то, что они выполняются одновременно и параллельно и массово — это общее свойство современного софта. Выполняется их одновременно 10 или 10 тысяч — в принципе, от этого мало что зависит, если сами операции написаны корректно...
Здравствуйте, gandjustas, Вы писали:
G>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
Бывают такие редкие ошибки, но из-за которых приходится полностью менять не только прогу, но и железо..
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так что реально различных операций не так уж много, не миллиарды, а скорее тысячи, если не сотни.
Сотни тысяч. Это не экземпляров операций, а типов операций. Там же миллионы строк кода!
Софт по управлению АЭС — это, извините, детский лепет. Там, грубо говоря, один конечный автомат с четырьмя состояниями. Поэтому сложности разработки сильно преувеличены.
А у какого-нибудь банка запросто может быть полторы-две тысячи видов документов. И для каждого из них — workflow с десятком шагов. И пересечений между банками по этим видам и шагам — от силы 20%. Остальное — результат творчества данного конкретного совета директоров, умноженный на судороги регулирующих органов, ежеквартально выпускающих новые инструкции типа "при совершении операции на сумму более 4.5 МРОТ между счетами юридического лица и физического лица, соблюдать форму отчётности №34532-бис с поправками от 4 июня 2006, но без поправок от 17 мая 2009".
Вот, скажем, году этак в 2010 один банк федерального уровня попросил компанию ЦФТ добавить шаг с кнопкой "подтвердить" в один из процессов. На осторожные вопросы "зачем вам эта кнопка", "по какому критерию её будет нажимать сотрудник — может быть ему нужно показать какие-то дополнительные расчёты", "может быть кнопку можно заменить автоматическим вычислением этих критериев" было отвечено, что кнопка нужна для того, чтобы её нажимала секретарша некоего конкретного человека. Сам человек уже в пенсионном возрасте, с компьютерами незнаком. Критериев никаких нет — кнопка будет нажиматься всегда. Если эту кнопку не сделать, то дедушку придётся уволить, а политические соображения требуют держать его в банке. При этом давать ему реальные обязанности, где надо думать головой, никто не рискует — маразм-с.
Так что не нужно сакрализовывать banking.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так что реально различных операций не так уж много, не миллиарды, а скорее тысячи, если не сотни. S>Сотни тысяч. Это не экземпляров операций, а типов операций. Там же миллионы строк кода!
Можешь аргументировать ? Откуда сотни тысяч ?
Контраргумент — а как же в докомпьютерную эру с этим вручную справлялись ? Три-четыре девушки в отделении банка вполне могли провести эту операцию. Любую. И на порядок проще это не было, ведь все, что делается сейчас, делалось и тогда, ничего принципиально нового в этом плане не появилось. Ну не могли бы эти девушки что-то делать вообще, если бы им пришлось иметь дело с печатными руководствами на сотни тысяч различных операций.
Только не говори мне, что мол, в СССР все было проще. В остальном мире проще не было.
Или ты имеешь в виду операции, одинаковые по сути, но отличающиеся параметрами ? Заплатить по сотовому телефону, за ТВ, налог и т.д. ? Таких, конечно, очень много, но по сути это одна операция с вариацией параметров.
S>Софт по управлению АЭС — это, извините, детский лепет. Там, грубо говоря, один конечный автомат с четырьмя состояниями. Поэтому сложности разработки сильно преувеличены.
Я не о сложности говорил, а о надежности.
S>А у какого-нибудь банка запросто может быть полторы-две тысячи видов документов. И для каждого из них — workflow с десятком шагов. И пересечений между банками по этим видам и шагам — от силы 20%. Остальное — результат творчества данного конкретного совета директоров, умноженный на судороги регулирующих органов, ежеквартально выпускающих новые инструкции типа "при совершении операции на сумму более 4.5 МРОТ между счетами юридического лица и физического лица, соблюдать форму отчётности №34532-бис с поправками от 4 июня 2006, но без поправок от 17 мая 2009".
Бог с ним, с директорами и workflow. Когда дело до операций с банком дойдет, там не так уж много вариантов будет.
У тебя есть доступ к Интернет-банку ? Зайди и подсчитай, сколько там разных вариантов есть. Я так думаю, не больше 20-30, включая всякие выписки. Больше просто и нельзя для обычного человека, иначе он во всем этом запутается. Ну а для юрлиц может и больше, на порядок, ну пусть на два...
S>Вот, скажем, году этак в 2010 один банк федерального уровня попросил компанию ЦФТ добавить шаг с кнопкой "подтвердить" в один из процессов. На осторожные вопросы "зачем вам эта кнопка", "по какому критерию её будет нажимать сотрудник — может быть ему нужно показать какие-то дополнительные расчёты", "может быть кнопку можно заменить автоматическим вычислением этих критериев" было отвечено, что кнопка нужна для того, чтобы её нажимала секретарша некоего конкретного человека. Сам человек уже в пенсионном возрасте, с компьютерами незнаком. Критериев никаких нет — кнопка будет нажиматься всегда. Если эту кнопку не сделать, то дедушку придётся уволить, а политические соображения требуют держать его в банке. При этом давать ему реальные обязанности, где надо думать головой, никто не рискует — маразм-с.
Что-то я не совсем понял. Ладно, пусть секретарша должна нажимать кнопку (кстати, после каких действий, кем выполняемых и на чьем компьютере ?). А что этот самый человек пенсионного возраста тут делает ? Если он даже кнопку нажать не может, значит, и все остальное он тоже не может. А тогда при чем он тут ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можешь аргументировать ? Откуда сотни тысяч ?
Павел, если вы не в состоянии самостоятельно решить типичную задачу-оценку с собеседования при приёме на работу, то моим вычислениям вы уж точно не поверите.
PD>Контраргумент — а как же в докомпьютерную эру с этим вручную справлялись?
ОМГ. Да так и справлялись — каждая операция была ad-hoc, т.к. люди, в отличие от компьютеров, не настолько буквальны.
PD>Три-четыре девушки в отделении банка вполне могли провести эту операцию. Любую. И на порядок проще это не было, ведь все, что делается сейчас, делалось и тогда, ничего принципиально нового в этом плане не появилось.
Павел, прекратите нести чушь.
Ну не могли бы эти девушки что-то делать вообще, если бы им пришлось иметь дело с печатными руководствами на сотни тысяч различных операций.
А они и без печатного руководства могли выполнить операцию — просто на основании внутренних соображений.
PD>Только не говори мне, что мол, в СССР все было проще. В остальном мире проще не было.
Конечно же было проще. Павел, как вы думаете, кредитные карты когда появились?
PD>Или ты имеешь в виду операции, одинаковые по сути, но отличающиеся параметрами ? Заплатить по сотовому телефону, за ТВ, налог и т.д. ? Таких, конечно, очень много, но по сути это одна операция с вариацией параметров.
Павел, никакой "сути" нету. Есть только код. И этого кода — миллионы строк.
PD>Я не о сложности говорил, а о надежности.
PD>Бог с ним, с директорами и workflow. Когда дело до операций с банком дойдет, там не так уж много вариантов будет.
Это и есть операции с банком. Точнее, операции внутри банка.
PD>У тебя есть доступ к Интернет-банку ? Зайди и подсчитай, сколько там разных вариантов есть. Я так думаю, не больше 20-30, включая всякие выписки.
Какая ловкая подмена предмета дискуссии. Ну давайте ещё обсудим код-прошивку печатаюшего устройства в кассовом аппарате, и сделаем вид, что это и есть банковский софт.
Во-первых, интернет-банк — это убогое подмножество всех операций, выполняемых реальным банком. Из которых большая часть — внутренняя, и вообще никакому клиенту не видны.
Во-вторых, то, что вам кажется "одним вариантом" через UI интернет-банка, внутри может реализовываться парой сотен бизнес-правил.
PD>Больше просто и нельзя для обычного человека, иначе он во всем этом запутается. Ну а для юрлиц может и больше, на порядок, ну пусть на два...
Павел, речь не о софте для обычного человека, а о софте для банков. Там одних департаментов может быть больше, чем у вас кафедр в институте. И у всех — свои заморочки, правила, и потребности.
PD>Что-то я не совсем понял. Ладно, пусть секретарша должна нажимать кнопку (кстати, после каких действий, кем выполняемых и на чьем компьютере ?).
Вижу, вы вообще не понимаете, что такое workflow. А чего тогда лезете рассуждать про банковский софт?
PD>А что этот самый человек пенсионного возраста тут делает ? Если он даже кнопку нажать не может, значит, и все остальное он тоже не может. А тогда при чем он тут ?
Я же вам говорю — он должность занимает. А причём он — про то, откуда берутся бизнес-правила в банковском софте. Которые нужно реализовывать, а потом (в теории) — тестировать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>Можешь аргументировать ? Откуда сотни тысяч ? S>Павел, если вы не в состоянии самостоятельно решить типичную задачу-оценку с собеседования при приёме на работу, то моим вычислениям вы уж точно не поверите.
Уход от ответа.
PD>>Контраргумент — а как же в докомпьютерную эру с этим вручную справлялись? S>ОМГ. Да так и справлялись — каждая операция была ad-hoc, т.к. люди, в отличие от компьютеров, не настолько буквальны.
Тоже не ответ. Пусть люди не буквальны, а инструкции-то были или нет ? В количестве сотен тысяч. Пусть люди в них не глядели, пусть, а быть-то они должны были в каждом офисе банка ? А если нет — значит, просто не было этих сотен тысяч. Кому нужны инструкции, которых никто не видит ?
PD>>Три-четыре девушки в отделении банка вполне могли провести эту операцию. Любую. И на порядок проще это не было, ведь все, что делается сейчас, делалось и тогда, ничего принципиально нового в этом плане не появилось. S>Павел, прекратите нести чушь.
Когда нет других аргументов — надо назвать аргументы оппонента чушью. Тривиальный демагогический прием.
S>Ну не могли бы эти девушки что-то делать вообще, если бы им пришлось иметь дело с печатными руководствами на сотни тысяч различных операций. S>А они и без печатного руководства могли выполнить операцию — просто на основании внутренних соображений.
А документы все же были ? Не было ? Значит, можно было вполне без них и делать.
PD>>Только не говори мне, что мол, в СССР все было проще. В остальном мире проще не было. S>Конечно же было проще. Павел, как вы думаете, кредитные карты когда появились?
Не аргумент. Их аналоги (чековые книжки с бумажными чеками) были еще бог знает когда. И действия по ним были во многом теми же. Расплатиться чеком в США можно было много где.
PD>>Или ты имеешь в виду операции, одинаковые по сути, но отличающиеся параметрами ? Заплатить по сотовому телефону, за ТВ, налог и т.д. ? Таких, конечно, очень много, но по сути это одна операция с вариацией параметров. S>Павел, никакой "сути" нету. Есть только код. И этого кода — миллионы строк.
Да пусть миллионы, я не спорю. Только вот это слабосвязанная система. Грубо говоря, эти миллионы делятся на 10000 раз по 1000, и каждая 1000 от других тысяч мало зависит.
PD>>Бог с ним, с директорами и workflow. Когда дело до операций с банком дойдет, там не так уж много вариантов будет. S>Это и есть операции с банком. Точнее, операции внутри банка.
PD>>У тебя есть доступ к Интернет-банку ? Зайди и подсчитай, сколько там разных вариантов есть. Я так думаю, не больше 20-30, включая всякие выписки. S>Какая ловкая подмена предмета дискуссии. Ну давайте ещё обсудим код-прошивку печатаюшего устройства в кассовом аппарате, и сделаем вид, что это и есть банковский софт. S>Во-первых, интернет-банк — это убогое подмножество всех операций, выполняемых реальным банком. Из которых большая часть — внутренняя, и вообще никакому клиенту не видны. S>Во-вторых, то, что вам кажется "одним вариантом" через UI интернет-банка, внутри может реализовываться парой сотен бизнес-правил.
Никакой подмены. Я не раз писал, что для юрлиц сложнее. Кстати, есть Интернет-банк и для юрлиц, но я с ним по понятным причинам не очень знаком.
А операции физлиц — весьма приличная часть банковской деятельности. Так сколько таких разных операций существует ?
PD>>Больше просто и нельзя для обычного человека, иначе он во всем этом запутается. Ну а для юрлиц может и больше, на порядок, ну пусть на два... S>Павел, речь не о софте для обычного человека, а о софте для банков. Там одних департаментов может быть больше, чем у вас кафедр в институте. И у всех — свои заморочки, правила, и потребности.
Не спорю. Есть там такое. А вот обоснуй, почему этих внутренних операций на порядки больше, чем внешних ?
PD>>Что-то я не совсем понял. Ладно, пусть секретарша должна нажимать кнопку (кстати, после каких действий, кем выполняемых и на чьем компьютере ?). S>Вижу, вы вообще не понимаете, что такое workflow. А чего тогда лезете рассуждать про банковский софт?
Прелесть! Я ему про секретаршу конкретный вопрос, а он мне про workflow из другой части разговора. А на конкретный вопрос все же ответить можно ?
PD>>А что этот самый человек пенсионного возраста тут делает ? Если он даже кнопку нажать не может, значит, и все остальное он тоже не может. А тогда при чем он тут ? S>Я же вам говорю — он должность занимает. А причём он — про то, откуда берутся бизнес-правила в банковском софте. Которые нужно реализовывать, а потом (в теории) — тестировать.
Коль уж о workflow речь зашла, то и опиши workflow с этим начальником и секретаршей. Например, так
Бухгалтер готовит некий запрос в банк. После этого с ноутбуком идет к старому начальнику. Говорит ему — так , мол, и так. Он отвечает "хорошо". После этого бухгалтер идет к секретарше начальника и та нажимает кнопку
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Уход от ответа.
Ок. Около 1000 типов документов в одном банке, типичный workflow — 10 шагов, около 2000 банковских лицензий выдано в РФ.
Предположим, нашим софтом пользуется только половина. Итого имеем до 10000000 бизнес-правил. Около 20% из них — повторяющиеся.
PD>Тоже не ответ. Пусть люди не буквальны, а инструкции-то были или нет ?
Были. PD>В количестве сотен тысяч.
Зачем. В одной инструкции — полсотни-сотня правил,
PD>Пусть люди в них не глядели, пусть, а быть-то они должны были в каждом офисе банка ? А если нет — значит, просто не было этих сотен тысяч. Кому нужны инструкции, которых никто не видит ?
Не в каждом офисе банка. Банков — сотни. У каждого — свои правила.
PD>Когда нет других аргументов — надо назвать аргументы оппонента чушью. Тривиальный демагогический прием.
Мне просто не хочется заниматься ликбезом по истории банковского дела для оппонента, который всё равно ничего из моих реплик не усвоит.
PD>А документы все же были ? Не было ? Значит, можно было вполне без них и делать.
"Документ", Павел, это например "Анкета заёмщика" и "заявление на кредит". Плюс к этому инструкция, плюс тренинги персонала.
Минус все новомодные скоринговые системы, которые появились исключительно как результат компьютеризации.
PD>Не аргумент. Их аналоги (чековые книжки с бумажными чеками) были еще бог знает когда. И действия по ним были во многом теми же. Расплатиться чеком в США можно было много где.
Павел, как вы программы-то пишете? Дьявол ведь в деталях. Кстати, чековая книжка не является аналогом кредитки даже отдалённо — у них разные наборы ограничений и операций.
PD>Да пусть миллионы, я не спорю. Только вот это слабосвязанная система. Грубо говоря, эти миллионы делятся на 10000 раз по 1000, и каждая 1000 от других тысяч мало зависит.
Во-первых, там не так просто изолировать явные зависимости. На первый взгляд, от одного другое не зависит, а в реальности совпал какой-то крайний случай — и оп-па, unexpected behavior.
Во-вторых, как ни изолируй, а тестирование всех этих сотен тысяч строк кода всё равно занимает очень много времени. Поэтому полного регрессионного тестирования там практически никогда не бывает.
PD>Никакой подмены. Я не раз писал, что для юрлиц сложнее. Кстати, есть Интернет-банк и для юрлиц, но я с ним по понятным причинам не очень знаком.
Софт пишется не для юрлиц, а для банков. PD>А операции физлиц — весьма приличная часть банковской деятельности. Так сколько таких разных операций существует ?
В лично моём интернет-банке — около 100 операций. Ну и что?
S>>Павел, речь не о софте для обычного человека, а о софте для банков. Там одних департаментов может быть больше, чем у вас кафедр в институте. И у всех — свои заморочки, правила, и потребности.
PD>Не спорю. Есть там такое. А вот обоснуй, почему этих внутренних операций на порядки больше, чем внешних ?
Потому что так устроена реальность, Павел. Вы когда-нибудь кредит оформляли серъёзный? Ну, скажем, ипотеку?
Вот у меня в моём банке открыто порядка 20 счетов. Несмотря на то, что пользуюсь я только одним. Потому что правила. Например, я не могу снимать деньги "в минус" с карточного счёта. Поэтому за ним стоят два разных счёта: один кредитный, один зарплатный. В зависимости от реального остатка деньги списываются либо с одного, либо с другого, либо частично так и так.
А ещё есть счёт, через который проходит списание процентов за краткосрочный кредит при превышении льготного лимита.
А ещё есть ипотечный счёт, который висит несмотря на закрытие кредита. Точнее — два счёта: один — на который мне начислили деньги для перевода продавцу квартиры, и другой — на котором висит (висела) моя задолженность. Плюс счёт для учёта процентов, начисленных на остаток ссудной задолженности. Плюс счёт для учёта просроченных процентов.
А ещё есть специальный карточный счёт для ипотечного счёта, несмотря на то, что я никакую карточку не получал — для того, чтобы типа вносить платежи через банкомат. А ещё валютный счёт (точнее два) для обеспечения расчётов кредитной картой с организациями, выставляющими счета в валюте.
И всё это, Павел, для обеспечения всего четырёх операций клиентом.
Надеюсь, что сам состав этих счетов, моменты открытия/закрытия, и разрешённые/запрещённые операции — это всё бизнес-правила, вам объяснять не нужно?
Что некоторые действия со счетами требуют всего лишь провести карточкой в считывателе и набрать пин-код, а для других надо писать заявление по установленной форме? И этих форм заявлений — полсотни штук на разные случаи? Или это всё какая-то неочевидная секретная информация?
PD>Коль уж о workflow речь зашла, то и опиши workflow с этим начальником и секретаршей. Например, так
PD>Бухгалтер готовит некий запрос в банк. После этого с ноутбуком идет к старому начальнику. Говорит ему — так , мол, и так. Он отвечает "хорошо". После этого бухгалтер идет к секретарше начальника и та нажимает кнопку
Почти так. Скажем, менеджер в банке готовит некий запрос, на основании заявления клиента банка. Юридического, скажем, лица.
Запрос вбивается в систему автоматизации банковской деятельности.
Затем этот запрос проходит экспертизу в отделе безопасности банка, который проверяет упомянутых в запросе юридических и физических лиц, и ставит либо не ставит свою визу (а иногда добавляет туда специальную информацию, которую клиент никогда не видит и не увидит). Затем запрос проходит экспертизу в экспертном отделе, который проверяет реализуемость проекта.
Затем запрос выносится на комитет, который может вернуть запрос на доработку с комментариями, а может утвердить. Затем запрос попадает в соответствующий отдел, где принимаются второстепенные решения вроде того, в каком из филиалов будут проводиться реальные операции. Запрос разделяется на пару десятков подзапросов, каждый из которых едет своим путём.
И вот где-то в середине этого процесса запрос застревает в статусе "Ждём одобрения от Ивана Ивановича".
Секретарша Ивана Ивановича раз в неделю заходит под его логином в банковскую программу, открывает список "запросы ждущие одобрения от Ивана Ивановича", и на каждом из них нажимает кнопку "одобрить". После этого запросы продолжают своё движение по системе.
А ваша ментальная картинка почему-то не про банк, а про бухгалтера.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>Уход от ответа. S>Ок. Около 1000 типов документов в одном банке,
Принимается
>типичный workflow — 10 шагов
Принимается
>, около 2000 банковских лицензий выдано в РФ.
А это тут с какого бока ? Ты бы еще вспомнил про общее число банков в мире! А что — туда тоже переводы делают. Только вот стандартизировано все это, и от банка не зависит.
Первая передержка detected.
Итого 1000 документов и 10 шагов. 10000, а не сотни тысяч.
S>Предположим, нашим софтом пользуется только половина. Итого имеем до 10000000 бизнес-правил. Около 20% из них — повторяющиеся.
Не рассказывай сказки. Перевод в другой банк делается по стандарту.
PD>>Тоже не ответ. Пусть люди не буквальны, а инструкции-то были или нет ? S>Были. PD>>В количестве сотен тысяч. S>Зачем. В одной инструкции — полсотни-сотня правил,
А всего правил сотни тысяч, так ? То есть при сотне правил тысяча документов ? Они были все в банке ? Они все были нужны ? Девочки в банке
PD>>Пусть люди в них не глядели, пусть, а быть-то они должны были в каждом офисе банка ? А если нет — значит, просто не было этих сотен тысяч. Кому нужны инструкции, которых никто не видит ? S>Не в каждом офисе банка. Банков — сотни. У каждого — свои правила.
А при чем тут сотни банков ? Банков-то сотни, но мы про один банк говорим, и по твоему утверждению, именно для него были (и есть) сотни тысяч документов
Вторая передержка detected
PD>>Когда нет других аргументов — надо назвать аргументы оппонента чушью. Тривиальный демагогический прием. S>Мне просто не хочется заниматься ликбезом по истории банковского дела для оппонента, который всё равно ничего из моих реплик не усвоит.
Продолжение демагогии detected.
PD>>А документы все же были ? Не было ? Значит, можно было вполне без них и делать. S>"Документ", Павел, это например "Анкета заёмщика" и "заявление на кредит". Плюс к этому инструкция, плюс тренинги персонала.
А в докомпьютерную эпоху не было заемщиков и анкет и не было кредита и заявлений ? Пусть не у нас, но в США были или нет ?
S>Минус все новомодные скоринговые системы, которые появились исключительно как результат компьютеризации.
А, ну это ладно, так и быть.
PD>>Не аргумент. Их аналоги (чековые книжки с бумажными чеками) были еще бог знает когда. И действия по ним были во многом теми же. Расплатиться чеком в США можно было много где. S>Павел, как вы программы-то пишете? Дьявол ведь в деталях. Кстати, чековая книжка не является аналогом кредитки даже отдалённо — у них разные наборы ограничений и операций.
Дъявол точно в деталях. А чековая книжка вполне является предком дебетки хотя бы (насчет кредита по ней просто не знаю). И с той можно платить, и с той.А то, что разный набор — так никто не говорит, что 100% совпадает.
PD>>Да пусть миллионы, я не спорю. Только вот это слабосвязанная система. Грубо говоря, эти миллионы делятся на 10000 раз по 1000, и каждая 1000 от других тысяч мало зависит. S>Во-первых, там не так просто изолировать явные зависимости. На первый взгляд, от одного другое не зависит, а в реальности совпал какой-то крайний случай — и оп-па, unexpected behavior. S>Во-вторых, как ни изолируй, а тестирование всех этих сотен тысяч строк кода всё равно занимает очень много времени. Поэтому полного регрессионного тестирования там практически никогда не бывает.
Вот с этим отчасти соглашусь. Полное тестирование вообще абстракция, не бывает его. А достаточное тестирование возможно. Что касается того, что в слабосвязанной системе иногда ве же проявляется влияние этого связывания — кто же спорит ? Только в автономных системах оно не проявляется. И да, тестирование требует времени. Но что с того ? Чем больше (не сложнее, а больше) система, тем больше времени требуется.
PD>>Никакой подмены. Я не раз писал, что для юрлиц сложнее. Кстати, есть Интернет-банк и для юрлиц, но я с ним по понятным причинам не очень знаком. S>Софт пишется не для юрлиц, а для банков. PD>>А операции физлиц — весьма приличная часть банковской деятельности. Так сколько таких разных операций существует ? S>В лично моём интернет-банке — около 100 операций. Ну и что?
Вот именно. Около сотни разных операций. А вот если умножить на чмсло разных значений операндов (что ты и делаешь), тогда миллионы легко возникнут.
S>>>Павел, речь не о софте для обычного человека, а о софте для банков. Там одних департаментов может быть больше, чем у вас кафедр в институте. И у всех — свои заморочки, правила, и потребности.
PD>>Не спорю. Есть там такое. А вот обоснуй, почему этих внутренних операций на порядки больше, чем внешних ? S>Потому что так устроена реальность, Павел. Вы когда-нибудь кредит оформляли серъёзный? Ну, скажем, ипотеку?
Нет. Вклады оформлял. Допускаю, что кредит раз в 10 сложнее. Ну и что ?
S>Вот у меня в моём банке открыто порядка 20 счетов. Несмотря на то, что пользуюсь я только одним. Потому что правила. Например, я не могу снимать деньги "в минус" с карточного счёта. Поэтому за ним стоят два разных счёта: один кредитный, один зарплатный. В зависимости от реального остатка деньги списываются либо с одного, либо с другого, либо частично так и так. S>А ещё есть счёт, через который проходит списание процентов за краткосрочный кредит при превышении льготного лимита. S>А ещё есть ипотечный счёт, который висит несмотря на закрытие кредита. Точнее — два счёта: один — на который мне начислили деньги для перевода продавцу квартиры, и другой — на котором висит (висела) моя задолженность. Плюс счёт для учёта процентов, начисленных на остаток ссудной задолженности. Плюс счёт для учёта просроченных процентов. S>А ещё есть специальный карточный счёт для ипотечного счёта, несмотря на то, что я никакую карточку не получал — для того, чтобы типа вносить платежи через банкомат. А ещё валютный счёт (точнее два) для обеспечения расчётов кредитной картой с организациями, выставляющими счета в валюте.
Да бога ради. Только вот когда ты с одним счетом что-то делаешь, ты либо с другими ничего не делаешь, либо делаешь с одним (перевод с одного счета на другой). А вот операций, включающих сразу 5 счетов, нет в природе.
А так бога ради. Раздроби свой вклад на суммы в $100, открой на каждую сотню долларов по вкладу, и будет у тебя N счетов. Только что с того ? Что это изменит в ПО банка ?
S>И всё это, Павел, для обеспечения всего четырёх операций клиентом.
S>Надеюсь, что сам состав этих счетов, моменты открытия/закрытия, и разрешённые/запрещённые операции — это всё бизнес-правила, вам объяснять не нужно? S>Что некоторые действия со счетами требуют всего лишь провести карточкой в считывателе и набрать пин-код, а для других надо писать заявление по установленной форме? И этих форм заявлений — полсотни штук на разные случаи? Или это всё какая-то неочевидная секретная информация?
Да, вполне допускаю, что есть с десяток вариантов счета, ина каждый с десяток правил, и они разные. Итого примерно 10 юзкейсов, ну а если перекрестно взять (с каждого счета на каждый) — 100, причем в этих 100 слаьая связанность, так как реально зачисление на один счет не зависит от снятия с другого.
PD>>Коль уж о workflow речь зашла, то и опиши workflow с этим начальником и секретаршей. Например, так
PD>>Бухгалтер готовит некий запрос в банк. После этого с ноутбуком идет к старому начальнику. Говорит ему — так , мол, и так. Он отвечает "хорошо". После этого бухгалтер идет к секретарше начальника и та нажимает кнопку S>Почти так. Скажем, менеджер в банке готовит некий запрос, на основании заявления клиента банка. Юридического, скажем, лица. S>Запрос вбивается в систему автоматизации банковской деятельности. S>Затем этот запрос проходит экспертизу в отделе безопасности банка, который проверяет упомянутых в запросе юридических и физических лиц, и ставит либо не ставит свою визу (а иногда добавляет туда специальную информацию, которую клиент никогда не видит и не увидит). Затем запрос проходит экспертизу в экспертном отделе, который проверяет реализуемость проекта. S>Затем запрос выносится на комитет, который может вернуть запрос на доработку с комментариями, а может утвердить. Затем запрос попадает в соответствующий отдел, где принимаются второстепенные решения вроде того, в каком из филиалов будут проводиться реальные операции. Запрос разделяется на пару десятков подзапросов, каждый из которых едет своим путём.
S>И вот где-то в середине этого процесса запрос застревает в статусе "Ждём одобрения от Ивана Ивановича". S>Секретарша Ивана Ивановича раз в неделю заходит под его логином в банковскую программу, открывает список "запросы ждущие одобрения от Ивана Ивановича", и на каждом из них нажимает кнопку "одобрить". После этого запросы продолжают своё движение по системе.
Так бы сразу и объяснил. Совершенно нормальный workflow. Так было всегда и будет всегда. Документы готовят разные люди и отделы, а потом начальник их визирует, порой даже и не читая. Что тут особенного ?
Единственное "но" — начальник сам это делать не умеет (в твоем примере), поэтому это делает его секретарша, которой он, очевидно, доверил визировать эти операции. Ну и что тут интересного, кроме того, что он сам это делать не умеет ? А если бы мог — что изменилось бы ? Если бы он сам на кнопку нажимал, тебя бы это удовлетворило ?
Другй вопрос — нужно ли такое визирование вообще ? Но ответ на этот вопрос никакого отношения к ИТ не имеет.
PD>А это тут с какого бока ? Ты бы еще вспомнил про общее число банков в мире! А что — туда тоже переводы делают. Только вот стандартизировано все это, и от банка не зависит.
Павел, реальный банковский софт пишется не для одного банка. Решения ЦФТ стоят примерно в 80% банков в РФ.
PD>Не рассказывай сказки. Перевод в другой банк делается по стандарту.
Павел, перевод в другой банк — это о-малое от всех операций, подлежащих автоматизации.
PD>А всего правил сотни тысяч, так ? То есть при сотне правил тысяча документов ? Они были все в банке ? Они все были нужны ?
Не обязательно. И банков было меньше, и девочек было меньше, и видов операций было меньше.
PD>А при чем тут сотни банков ? Банков-то сотни, но мы про один банк говорим, и по твоему утверждению, именно для него были (и есть) сотни тысяч документов
Я не знаю, о каком одном банке говорим. Я говорю о софте для банков, которых много. Например, Сбербанк РФ — это примерно полсотни разных банков.
PD>А в докомпьютерную эпоху не было заемщиков и анкет и не было кредита и заявлений ? Пусть не у нас, но в США были или нет ?
Были, Павел, были. И вместо многих инструкций было внутреннее чутьё сотрудника банка.
PD>Дъявол точно в деталях. А чековая книжка вполне является предком дебетки хотя бы (насчет кредита по ней просто не знаю). И с той можно платить, и с той.А то, что разный набор — так никто не говорит, что 100% совпадает.
Вы говорите. По-вашему, одним и тем же кодом можно обработать хоть то, хоть это.
PD>Вот с этим отчасти соглашусь. Полное тестирование вообще абстракция, не бывает его. А достаточное тестирование возможно. Что касается того, что в слабосвязанной системе иногда ве же проявляется влияние этого связывания — кто же спорит ? Только в автономных системах оно не проявляется. И да, тестирование требует времени. Но что с того ? Чем больше (не сложнее, а больше) система, тем больше времени требуется.
Вот, теперь, Павел, вы начинаете понимать. Допустим, что полное тестирование требует, скажем, 24 месяца. А апдейты надо выпускать каждый квартал. Теперь понятно, откуда берётся хреновое качество?
PD>Вот именно. Около сотни разных операций. А вот если умножить на чмсло разных значений операндов (что ты и делаешь), тогда миллионы легко возникнут.
Я этого не делаю. Павел, сотня — это оценка снизу. Я не понимаю способа, которым вы переводите её в оценку сверху.
PD>Нет. Вклады оформлял. Допускаю, что кредит раз в 10 сложнее. Ну и что ?
См. расчёт вначале поста.
PD>Да бога ради. Только вот когда ты с одним счетом что-то делаешь, ты либо с другими ничего не делаешь, либо делаешь с одним (перевод с одного счета на другой). А вот операций, включающих сразу 5 счетов, нет в природе.
Павел, лично я вообще ничего не делаю. "Операция", с моей клиентской точки зрения — это, скажем "выдача кредита". И вот она включает в себя двадцать отдельных операций со счетами. И ещё неизвестное количество шагов некоего документооборота, устройство которого составляет коммерческую тайну.
PD>А так бога ради. Раздроби свой вклад на суммы в $100, открой на каждую сотню долларов по вкладу, и будет у тебя N счетов. Только что с того ? Что это изменит в ПО банка ?
Павел, вы опять путаете количество типов с количеством экземпляров. Зачем?
PD>Да, вполне допускаю, что есть с десяток вариантов счета, ина каждый с десяток правил, и они разные. Итого примерно 10 юзкейсов, ну а если перекрестно взять (с каждого счета на каждый) — 100, причем в этих 100 слаьая связанность, так как реально зачисление на один счет не зависит от снятия с другого.
О как. Ну вот оттуда мы и видим, когда с одного счёта снялось, а на другой не поступило. Потому что пишут софт такие же "спецы" как вы — с независимыми зачислениями. А потом клиенты удивляются, когда им в 4 утра СМС приходит "с вашего счёта списано 8000000 рублей" а потом "на ваш счёт зачислено 8000000 рублей".
PD>>>Коль уж о workflow речь зашла, то и опиши workflow с этим начальником и секретаршей. Например, так
PD>>>Бухгалтер готовит некий запрос в банк. После этого с ноутбуком идет к старому начальнику. Говорит ему — так , мол, и так. Он отвечает "хорошо". После этого бухгалтер идет к секретарше начальника и та нажимает кнопку S>>Почти так. Скажем, менеджер в банке готовит некий запрос, на основании заявления клиента банка. Юридического, скажем, лица. S>>Запрос вбивается в систему автоматизации банковской деятельности. S>>Затем этот запрос проходит экспертизу в отделе безопасности банка, который проверяет упомянутых в запросе юридических и физических лиц, и ставит либо не ставит свою визу (а иногда добавляет туда специальную информацию, которую клиент никогда не видит и не увидит). Затем запрос проходит экспертизу в экспертном отделе, который проверяет реализуемость проекта. S>>Затем запрос выносится на комитет, который может вернуть запрос на доработку с комментариями, а может утвердить. Затем запрос попадает в соответствующий отдел, где принимаются второстепенные решения вроде того, в каком из филиалов будут проводиться реальные операции. Запрос разделяется на пару десятков подзапросов, каждый из которых едет своим путём.
S>>И вот где-то в середине этого процесса запрос застревает в статусе "Ждём одобрения от Ивана Ивановича". S>>Секретарша Ивана Ивановича раз в неделю заходит под его логином в банковскую программу, открывает список "запросы ждущие одобрения от Ивана Ивановича", и на каждом из них нажимает кнопку "одобрить". После этого запросы продолжают своё движение по системе.
PD>Так бы сразу и объяснил. Совершенно нормальный workflow. Так было всегда и будет всегда. Документы готовят разные люди и отделы, а потом начальник их визирует, порой даже и не читая. Что тут особенного ? PD>Единственное "но" — начальник сам это делать не умеет (в твоем примере), поэтому это делает его секретарша, которой он, очевидно, доверил визировать эти операции. Ну и что тут интересного, кроме того, что он сам это делать не умеет ? А если бы мог — что изменилось бы ? Если бы он сам на кнопку нажимал, тебя бы это удовлетворило ? PD>Другй вопрос — нужно ли такое визирование вообще ? Но ответ на этот вопрос никакого отношения к ИТ не имеет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ладно, давай заканчивать. Все равно результат как всегда. За тобой право последнего ответа.
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А это тут с какого бока ? Ты бы еще вспомнил про общее число банков в мире! А что — туда тоже переводы делают. Только вот стандартизировано все это, и от банка не зависит. S>Павел, реальный банковский софт пишется не для одного банка. Решения ЦФТ стоят примерно в 80% банков в РФ.
Про иностранные банки ты аккуратно убрал. Не годится для твоих рассуждений, поэтому и убрал. Правильно сделал. Ну а насчет внутренних дел — да, конечно, в каждом банке должны во многом делать одно и то же, только вот с чего это сложность увеличивается в 2000 раз (число банков) — ты так и не объяснил. Правильно сделал, потому что это рушит всю твою концепцию.
PD>>Не рассказывай сказки. Перевод в другой банк делается по стандарту. S>Павел, перевод в другой банк — это о-малое от всех операций, подлежащих автоматизации.
Несомненно. Только вот ты-то говорил, что нужно умножить на 2000, где 2000 — число банков. А если речь идет об операциях, в которых другой банк не задействован — тогда при чем тут 2000 ?
PD>>А всего правил сотни тысяч, так ? То есть при сотне правил тысяча документов ? Они были все в банке ? Они все были нужны ? S>Не обязательно. И банков было меньше, и девочек было меньше, и видов операций было меньше.
Банков в США вряд ли было меньше. Ну а если девочек было меньше, и при этом они справлялись — тогда все твои построения рушатся совсем. Впрочем, их не было меньше. А вот видов операций если и стало больше, то не на порядки. Виды операций вообще-то бизнесом определяются, а не ИТ. Что бизнесу надо — то и есть.
PD>>А при чем тут сотни банков ? Банков-то сотни, но мы про один банк говорим, и по твоему утверждению, именно для него были (и есть) сотни тысяч документов S>Я не знаю, о каком одном банке говорим. Я говорю о софте для банков, которых много. Например, Сбербанк РФ — это примерно полсотни разных банков.
Банк все же один, филиалы у него разные, по регионам . А софт скорее всего один, общий, зачем им своя версия софта в каждом филиале. Впрочем, не знаю. Но уж у остальных банков точно вряд ли. У них и в крупных городах по 4-5 всего отделений, так что ПО скорее всего одно и то же.
PD>>А в докомпьютерную эпоху не было заемщиков и анкет и не было кредита и заявлений ? Пусть не у нас, но в США были или нет ? S>Были, Павел, были. И вместо многих инструкций было внутреннее чутьё сотрудника банка.
Потрясающий аргумент. То есть инструкции они не видели, но у них было чутье, какими они должны быть, и это чутье их не обманывало. Прелесть, да и только. Бвнковская телепатия.
PD>>Дъявол точно в деталях. А чековая книжка вполне является предком дебетки хотя бы (насчет кредита по ней просто не знаю). И с той можно платить, и с той.А то, что разный набор — так никто не говорит, что 100% совпадает. S>Вы говорите. По-вашему, одним и тем же кодом можно обработать хоть то, хоть это.
Я что-то говорил о коде для обработки чеков в докомпьютерную эру ?
Очередное передергивание detected.
PD>>Вот с этим отчасти соглашусь. Полное тестирование вообще абстракция, не бывает его. А достаточное тестирование возможно. Что касается того, что в слабосвязанной системе иногда ве же проявляется влияние этого связывания — кто же спорит ? Только в автономных системах оно не проявляется. И да, тестирование требует времени. Но что с того ? Чем больше (не сложнее, а больше) система, тем больше времени требуется. S>Вот, теперь, Павел, вы начинаете понимать. Допустим, что полное тестирование требует, скажем, 24 месяца. А апдейты надо выпускать каждый квартал. Теперь понятно, откуда берётся хреновое качество?
Ну спасибо, объяснил.
PD>>Вот именно. Около сотни разных операций. А вот если умножить на чмсло разных значений операндов (что ты и делаешь), тогда миллионы легко возникнут. S>Я этого не делаю. Павел, сотня — это оценка снизу. Я не понимаю способа, которым вы переводите её в оценку сверху.
Делаешь, делаешь. На число банков в России кто умножал ? А это и есть число операндов в операции "перевод в другой банк".
PD>>Нет. Вклады оформлял. Допускаю, что кредит раз в 10 сложнее. Ну и что ? S>См. расчёт вначале поста.
PD>>Да бога ради. Только вот когда ты с одним счетом что-то делаешь, ты либо с другими ничего не делаешь, либо делаешь с одним (перевод с одного счета на другой). А вот операций, включающих сразу 5 счетов, нет в природе. S>Павел, лично я вообще ничего не делаю. "Операция", с моей клиентской точки зрения — это, скажем "выдача кредита". И вот она включает в себя двадцать отдельных операций со счетами.
И ещё неизвестное количество шагов некоего документооборота, устройство которого составляет коммерческую тайну.
20 отдельных операций ? Это твоя гипотеза или есть доказательства ? Если есть — пруф в студию. Не брал я кредит, но вот выдача вклада — это одна или 2 операции, вот и все. А с кредитом так, может, надо действительно несколько документов предъявить, но вот насчет 20 операций по счетам — изволь доказать.
Курьеры, курьеры, сорок тысяч одних курьеров...
PD>>А так бога ради. Раздроби свой вклад на суммы в $100, открой на каждую сотню долларов по вкладу, и будет у тебя N счетов. Только что с того ? Что это изменит в ПО банка ? S>Павел, вы опять путаете количество типов с количеством экземпляров. Зачем?
А может быть, именно ты путаешь ? Когда умножаешь на число банков в России ? Ну а я просто довел до абсурда твою концепцию, чтобы показать тебе твою же ошибку. Если уж можно умножать на число банков, почему бы не умножить на число счетов ?
PD>>Да, вполне допускаю, что есть с десяток вариантов счета, ина каждый с десяток правил, и они разные. Итого примерно 10 юзкейсов, ну а если перекрестно взять (с каждого счета на каждый) — 100, причем в этих 100 слаьая связанность, так как реально зачисление на один счет не зависит от снятия с другого. S>О как. Ну вот оттуда мы и видим, когда с одного счёта снялось, а на другой не поступило. Потому что пишут софт такие же "спецы" как вы — с независимыми зачислениями. А потом клиенты удивляются, когда им в 4 утра СМС приходит "с вашего счёта списано 8000000 рублей" а потом "на ваш счёт зачислено 8000000 рублей".
Спокойно, спокойно, не нервничай. Во-первых, я банковский софт не пишу, а то, что писал и пишу, как ты знаешь, не обсуждаю здесь. А во-вторых, позволю себе напомнить одну формулировку "программа без ошибок есть абстрактное теоретическое понятие". Так что ошибки есть, и в банковском софте, и в моем, и в твоем, успокойся.
S>>>Секретарша Ивана Ивановича раз в неделю заходит под его логином в банковскую программу, открывает список "запросы ждущие одобрения от Ивана Ивановича", и на каждом из них нажимает кнопку "одобрить". После этого запросы продолжают своё движение по системе.
PD>>Так бы сразу и объяснил. Совершенно нормальный workflow. Так было всегда и будет всегда. Документы готовят разные люди и отделы, а потом начальник их визирует, порой даже и не читая. Что тут особенного ? PD>>Единственное "но" — начальник сам это делать не умеет (в твоем примере), поэтому это делает его секретарша, которой он, очевидно, доверил визировать эти операции. Ну и что тут интересного, кроме того, что он сам это делать не умеет ? А если бы мог — что изменилось бы ? Если бы он сам на кнопку нажимал, тебя бы это удовлетворило ? PD>>Другй вопрос — нужно ли такое визирование вообще ? Но ответ на этот вопрос никакого отношения к ИТ не имеет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Про иностранные банки ты аккуратно убрал. Не годится для твоих рассуждений, поэтому и убрал.
Да не поэтому убрал, а потому, что в иностранных банках — другой софт стоит. Не бывает банковского софта, который можно поставить и в РФ, и в США.
PD>Правильно сделал. Ну а насчет внутренних дел — да, конечно, в каждом банке должны во многом делать одно и то же, только вот с чего это сложность увеличивается в 2000 раз (число банков) — ты так и не объяснил.
Я, Павел, объяснил, да только ты не понял. Предсказуемо. Сложность увеличивается ровно потому, что процессы в банках — разные. И твой софт, который ты ставишь в 1000 банков, будет содержать кучу кода, уникального для каждого банка. Если для одного банка ты написал 1000 строк кода, то для другого банка придётся дописать ещё 800 строк — потому что из предыдущих можно повторно использовать всего 200. И так далее. Когда твой софт будет стоять в 50 банках, у тебя будет уже 40000 строк.
PD>Несомненно. Только вот ты-то говорил, что нужно умножить на 2000, где 2000 — число банков. А если речь идет об операциях, в которых другой банк не задействован — тогда при чем тут 2000 ?
Выше объяснено.
PD>Банков в США вряд ли было меньше. Ну а если девочек было меньше, и при этом они справлялись — тогда все твои построения рушатся совсем.
Павел, идиотизм этих рассуждений виден невооружённым мозгом. Вот, к примеру, с прямохождением по пересечённой местности справляется любой дебил, несмотря на то, что у него нет вообще никаких "инструкций". Ты возьмёшся за написание программного решения той же задачи?
Так и в бизнесе: "ручной" документооборот легко справляется с парой сотен вариантов отклонения сценария от стандарта. Автоматический документооборот нужно нудно программировать для тех же сценариев.
PD>Впрочем, их не было меньше. А вот видов операций если и стало больше, то не на порядки. Виды операций вообще-то бизнесом определяются, а не ИТ. Что бизнесу надо — то и есть.
Павел, прежде, чем рассуждать про то, что надо бизнесу, вы бы хоть что-то почитали на эту тему, что ли. Бизнес-ландшафт за последние 100 лет минимум четыре раза претерпевал революционные изменения. И это я говорю не про СССР, а про развитый мир.
PD>Банк все же один, филиалы у него разные, по регионам . А софт скорее всего один, общий, зачем им своя версия софта в каждом филиале.
Вот именно. Софт — общий. А бизнес-правила — отличаются. Позвоните на горячую линию сбера, задайте какой-нибудь простой вопрос — вроде "какой процент вы предлагаете по потребительским кредитам". У вас первым делом спросят, в каком банке и в каком регионе вы обслуживатесь.
PD>Делаешь, делаешь. На число банков в России кто умножал ? А это и есть число операндов в операции "перевод в другой банк".
Нет, Павел, я в оценке сложности операцию межбанковского перевода вообще не учитывал. Я оцнивал количество сценариев, которые нужно автоматизировать.
PD>20 отдельных операций ? Это твоя гипотеза или есть доказательства ?
Павел, я поражаюсь вашей неспособности воспринимать простейшие идеи. Доказательства я вам, конечно же, предоставить не смогу — внутренние правила банков составляют коммерческую тайну, разглашение которой суть уголовное преступление.
Поэтому вам придётся поверить мне на слово.
PD>Если есть — пруф в студию. Не брал я кредит, но вот выдача вклада — это одна или 2 операции, вот и все.
Павел, выдача вклада — о-малое от реальных операций, проводимых внутри типичного банка.
А с кредитом так, может, надо действительно несколько документов предъявить, но вот насчет 20 операций по счетам — изволь доказать.
PD>Ну я вам же привёл список счетов, которые есть лично у меня. Что ещё непонятно-то?
Я уж не говорю о том, что банк — это далеко не только движения по счетам. Это в первую очередь документооборот — и там всё гораздо запутаннее. Каждый раз, когда вы "предъявляете документ", внутри банковского софта происходит отдельная операция (а то и не одна).
PD>>>Так бы сразу и объяснил. Совершенно нормальный workflow. Так было всегда и будет всегда. Документы готовят разные люди и отделы, а потом начальник их визирует, порой даже и не читая. Что тут особенного ? PD>На это, как я понимаю, возражений нет ?
Да какие могут быть возражения человеку, который три поста подряд читает текст, а понять его так и не может? Вот я привёл пример требования, которое нужно программировать в банковском софте. Чтобы пояснить, откуда берутся сотни тысяч видов операций. Вы, Павел, почему-то упорно думаете, что в банковском софте есть только одна операция "перевод денег со счёта на счёт", и она во всех банках делаетя одинаково. Ну вот вам пример типа операции, которая сделана для конкретного сотрудника. Не для конкретного филиала, не для конкретного банка, и уж тем более не для всех банков в РФ. Персонально для Ивана Ивановича.
А в другом банке будет Петр Петрович, и для него надо сделать затычку где-то в другом месте.
И никто в жизни никогда не протестирует поведение системы, для всех потенциальных сочетаний включенности этих затычек.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, gandjustas, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах.
BFE>С точки зрения маркетинга — да, с точки зрения программиста — нет.
Ты марктингом называешь создание продукта который хотят\который нужнен пользователям? Ты прав.
Точка зрения программиста в данном случае вообще ниочем, кроме самолюбия программиста ни на что не влияет.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах. B>Бывают такие редкие ошибки, но из-за которых приходится полностью менять не только прогу, но и железо..
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, gandjustas, Вы писали:
G>>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах. B>>Бывают такие редкие ошибки, но из-за которых приходится полностью менять не только прогу, но и железо..
G>Пример чтоли приведи.
Та запросто.. Как то в 80-е при разработке ПО предложил считать время по внутреннему таймеру без прерываний.. С расчетом, что по той же вероятности смогу корректировать. Точность была не очень принципиальна.. Разработали прибор, и нифига не получилось у меня корректировать. Пришлось ставить еще одно устройство, которое считало время. Сломалось все.. и прерывания пришлось открыть..
G>>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах. B>>Бывают такие редкие ошибки, но из-за которых приходится полностью менять не только прогу, но и железо..
G>Пример чтоли приведи.Та запросто..
Как то в 80-е при разработке ПО предложил считать время по внутреннему таймеру без прерываний.. С расчетом, что по той же вероятности смогу корректировать. Точность была не очень принципиальна.. Когда запустили, и нифига не получилось у меня корректировать. Пришлось ставить еще одно устройство, которое считало время. Сломалось все.. и прерывания пришлось открыть..
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, batu, Вы писали:
B>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах. B>>>Бывают такие редкие ошибки, но из-за которых приходится полностью менять не только прогу, но и железо..
G>>Пример чтоли приведи. B>Та запросто.. Как то в 80-е при разработке ПО предложил считать время по внутреннему таймеру без прерываний.. С расчетом, что по той же вероятности смогу корректировать. Точность была не очень принципиальна.. Разработали прибор, и нифига не получилось у меня корректировать. Пришлось ставить еще одно устройство, которое считало время. Сломалось все.. и прерывания пришлось открыть..
Давным-давно в далекой-далекой галактике...
Кстати, с чего ты взял что софт, зашитый в прибор ты сможешь корректировать? Это же не прикладной софт.
Здравствуйте, gandjustas, Вы писали:
B>>Та запросто.. Как то в 80-е при разработке ПО предложил считать время по внутреннему таймеру без прерываний.. С расчетом, что по той же вероятности смогу корректировать. Точность была не очень принципиальна.. Разработали прибор, и нифига не получилось у меня корректировать. Пришлось ставить еще одно устройство, которое считало время. Сломалось все.. и прерывания пришлось открыть..
G>Давным-давно в далекой-далекой галактике...
G>Кстати, с чего ты взял что софт, зашитый в прибор ты сможешь корректировать? Это же не прикладной софт.
Тебе пример был нужен или поговорить?
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>Та запросто.. Как то в 80-е при разработке ПО предложил считать время по внутреннему таймеру без прерываний.. С расчетом, что по той же вероятности смогу корректировать. Точность была не очень принципиальна.. Разработали прибор, и нифига не получилось у меня корректировать. Пришлось ставить еще одно устройство, которое считало время. Сломалось все.. и прерывания пришлось открыть..
G>>Давным-давно в далекой-далекой галактике...
G>>Кстати, с чего ты взял что софт, зашитый в прибор ты сможешь корректировать? Это же не прикладной софт. B>Тебе пример был нужен или поговорить?
Пример древний как говно мамонта, актуальность потерял почти до нуля.
В примере твоя ошибка, а не реальное положение дел.
Здравствуйте, gandjustas, Вы писали:
G>>>Вывод неверный. В первую очередь нужно сосредоточиться на основных сценариях в приложении, которые возникают в 80%+ случаев. Те сценарии, которые возникают в 0.00001% случаев можно просто игнорировать. При появлении проблем просто поправить, ведь большая часть софта умеет обновляться проще, чем алгоритм записи дисков в CD-приводах. BFE>>С точки зрения маркетинга — да, с точки зрения программиста — нет. G>Ты марктингом называешь создание продукта который хотят\который нужнен пользователям? Ты прав.
Я маркетингом называю деятельность направленную на увеличение продаж. К созданию это имеет опосредованное отношение.
G>Точка зрения программиста в данном случае вообще ниочем, кроме самолюбия программиста ни на что не влияет.
Человек, который себя не любит — это какой-то неправильный человек.
Здравствуйте, B0FEE664, Вы писали:
G>>Ты марктингом называешь создание продукта который хотят\который нужнен пользователям? Ты прав. BFE>Я маркетингом называю деятельность направленную на увеличение продаж. К созданию это имеет опосредованное отношение.
Одна из ключевых задач маркетинга в RnD делах -- верно составить фичерлист и всякое ТЗ, что бы разработчики разработали востребованный и легкопродаваемый продукт, а не УГ, которое потом фиг кому впаришь, сколько не занимайся "маркетингом" в твоём понимании
G>>Точка зрения программиста в данном случае вообще ниочем, кроме самолюбия программиста ни на что не влияет. BFE>Человек, который себя не любит — это какой-то неправильный человек.
Некоторые работают таки ради денег. Если ты хорошо понимаешь, что то, что ты делаешь на продажу, надо делать так, что бы продалось, а не так, что бы покруче сделать, то у теюя есть боьше шансов заработать. А для души есть хоби и опенсорц...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
G>>>Ты марктингом называешь создание продукта который хотят\который нужнен пользователям? Ты прав. BFE>>Я маркетингом называю деятельность направленную на увеличение продаж. К созданию это имеет опосредованное отношение. E>Одна из ключевых задач маркетинга в RnD делах -- верно составить фичерлист и всякое ТЗ, что бы разработчики разработали востребованный и легкопродаваемый продукт, а не УГ, которое потом фиг кому впаришь, сколько не занимайся "маркетингом" в твоём понимании
Ну откуда вам знать, что в моем понимании хороший маркетинг?
Вот вам пример абсолютно гениального маркетингового хода здесь.
G>>>Точка зрения программиста в данном случае вообще ниочем, кроме самолюбия программиста ни на что не влияет. BFE>>Человек, который себя не любит — это какой-то неправильный человек. E>Некоторые работают таки ради денег. Если ты хорошо понимаешь, что то, что ты делаешь на продажу, надо делать так, что бы продалось, а не так, что бы покруче сделать, то у теюя есть боьше шансов заработать. А для души есть хоби и опенсорц... Я семь лет работал в конторе, которая продавала самую крутую библиотеку в своей нише. Доходило до того, что конкуренты говорили: "нет, мы так не умеем. Купите вот у них."
У нас 4 последних года, что я там работал, не было ни одного багрепорта связанного с падением по нашей вине. Библиотеку покупали за надёжность и богатство предоставляемых возможностей. Так что не надо мне рассказывать про 80% основных случаев.
Здравствуйте, B0FEE664, Вы писали:
BFE> Я семь лет работал в конторе, которая продавала самую крутую библиотеку в своей нише. Доходило до того, что конкуренты говорили: "нет, мы так не умеем. Купите вот у них." BFE>У нас 4 последних года, что я там работал, не было ни одного багрепорта связанного с падением по нашей вине. Библиотеку покупали за надёжность и богатство предоставляемых возможностей. Так что не надо мне рассказывать про 80% основных случаев.
Ну в жанном случае надёжность была востребованной фичей. Это не всегда так.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
.
Я семь лет работал в конторе, которая продавала самую крутую библиотеку в своей нише. Доходило до того, что конкуренты говорили: "нет, мы так не умеем. Купите вот у них."