Диез
Давайте рассмотрим конкретный пример: фирма - разработчик ПО получила заказ от некоей организации на разработку ПО для распознавания, скажем, снимков сетчатки глаза, и последующего сравнения с образцами из БД.

Для полноценного ТЭО, увы, не зватает исходных данных.
Я предполагаю, что это АC предназначена для использования не в криминалистике, а в медицине - конкретно, в иридодиагностике, т. е. постановке диагноза болезни по сетчатке глаза.
1 вариант.
Иридодиагностика уже практикуется вручную в ряде крупных медцентров.
Пользоваться услугами таких центров для больных накладно, да и самих центров мало.
Расширять количество центров и готовить специалистов - дорого (легко считается).
Можно изображение сетчатки передать по сети в спец.центр, который поставит диагноз (дешево, можно из любой поликлиники).
2 Использование иридодиагностики вместо стандртных клинических исследований (анализы крови, УЗИ, томография и т.п.), что очень дорого и длительно и не везде доступно (экономия на каждом анализе(обследовании), также легко считается)
Это прямая прибыль.
Есть и косвенная - ранняя диагостика, исключение смертей и инвалидности (экономия на пенсиях) и многое другое.

Еcли кратно, то я бы заплатил вам за примерно следующую формулировку цели создания АС (и именно подтверждение её с вас бы требовал):

Сокращение срока постановки диагноза до 1 часа с достоверностью 96% и снижением стоимости диагноза в 3 раза по сравнению с клиническим исследованием.


Диез

И, кстати, напомню предыдущий вопрос, на который вы почему-то не захотели отвечать:

Если вы подписались в ТЗ, что расход материала уменьшится на 8%, а он уменьшился только на 5% (потому что изменилась форма деталей), вы готовы отказаться от оплаты за вашу работу?

Вы же сами и ответили на свой вопрос - "изменилась форма деталей" (т. е. по логике следует, что форма деталей была оговорена).
Т. е. вы разработали АС для раскроя штанов и гарантируете 8%, а вашу АС используют для штамповки из стального листа неких фигур.
Изменились условия, соответственно, конечные результаты
В таких случаях (когда разрабатывается АС на все случаи жизни) пишут по другому;
- экономия должна быть не менее X% при любых формах деталей;
- время реакции системы (реального времени) не более 3 сек;
- наработка на отказ не менее 1000 час и т. п.

Диез
Кажется, это ключевые слова :)

Так эта мысль проходит через все мои письма;
никто ни за что не отвечает и ничего не гарантирует.

Все требуют почасовую оплату.
Помните интермедию А. Райкина?
Один зубы сверлит, другой точит, третий коронку ставит, а за дикцию никто не отвечает
- Ты думал, у меня дефект речи?
Дурачок. Я мошт во рту штрою.

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

Это нонсенс, вы уж не обессудьте...


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


P.S. Я прекращаю дискуссию - все равно каждый останется при своем мнении.
Вы не убедите меня, а я - вас.

Также iscrafm...Помимо всех прочих целей, преследуемых заказчиком есть сокращение срока прохождения документа по маршруту до n-х рабочих дней. Это цели заказчика.
Задача разработчика обеспечить бесперебойную передачу документа по маршруту и предоставление возможности пользователям в соответствии с полномочиями выполнять те или иные действия с каждым документом. Задача моей компании обеспечить именно это. А будет или нет проходить документ маршрут за указанный срок? Я не могу это гарантировать,

Я не понимаю суть претензий.
Врач говорит больному: Вот вам лекарство, принимайте 3 раза в день перед едой, через неделю будете здоровы. Гарантирую.
Больной не выполняет назначение врача. Кто виноват?

Вот вам система документоборота. Я гарантирую, что при соблюдении заложенной в ней технологии документ не потеряется, про него не забудут и он будет обработан за 3 дня.
Если заказчик не собладает технологию, причем тут исполнитнль?
Также и в других системах - я гарантирую вам прибыль N%, если будете соблюдать реализованныую в проекте технологию.
Кто с этим спорит?
Почитайте выше свои письма - вы то говорите, что заказчику НИЧЕГО НЕЛЬЗЯ ОБЕЩАТЬ КОНКРЕТНО (ни 7 дней прохождения документа, ни предполагаемой прибыли и т. п.).

iscrafm Это у него в инструкции прописано.
Да, потому что так СПРОЕКТИРОВАНО!
И паспортные данные надо ввести вручную из паспорта, а не взять в БД паспортов жителей города
и многое другое...

Цель-то была - удлинить очередь, а не сократить её.

гость Владимир Как вы собираетесь это проверять?

Программа и методика испытаний должна продемонстрировать, что расход материала при ручном раскрое в среднем выше на 8%, чем при машинном.
Как проверять - это должно быть прописано в методике испытаний. Будете ли вы реально резать материал и обсчитывать обрезки или использовать компьютерную модель - сначала человек раскроил на экране, а потом это проделал компьютер, и сравнивать результат - утверждает заказчик.

гость Владимир
А что если за время разработки АС квалификация работников увеличится, и они без вашей АС производить с расходом материала на 5% меньше. Ваша цель не достигнута. Заказчику не нужна ваша АС.
Есть милион факторов, которые меняются быстро и независимо ни вас, нет возможности их зафиксировать чтобы в последствии сравнить, нет возможности провести эксперимент по расчету прибыли до и после внедрения АС.
В ТЗ должны быть цели, ...

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

гость Владимир
Как вы со стороны исполнителя будете выполнять работу над таким ТЗ?


Господа!
Я тоже устал от пустопорожнего обсуждения.
Ваше со товарищи кредо - разрабатывали, разрабатываем и, несмотря ни на что, будем разрабатывать АС без оцениваемых количественных (качественых) характеристик.
Тогда зачем задаете вопросы типа "как измерять"?
Для вас такой проблемы не существует!
У меня другой подход, я его изложил, но не навязываю его вам как единственно верный.
Вот в соседнем топике - яркая иллюстрация вашего подхода.
Человек интересуется алгоритмами скронинговой системы.
Алгоритмы (и используемое ПО) будут разные, в зависимости от того, какие количественные показатели должна обеспечить система.
Но для автора вопроса - это несущественные мелочи.
У него, как полагаю, нет количественных параметров, которые он должен обеспечить.
Тогда и АС получится "как карта ляжет".


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