Забавный топик.

ЮВСокращение срока постановки диагноза до 1 часа с достоверностью 96% и снижением стоимости диагноза в 3 раза по сравнению с клиническим исследованием.
ЮВ, а откуда вы взяли вот эти цифры? Ну т.е. откуда вам известно что возможно сокращение срока постановки диагноза именно на 1 час (не на 30 мин и не на 2 часа), и снижение стоимости именно в 3 (а не в 2 и не 5) раз? Кто должен определить нормы экономической эффективности - заказчик или разработчик?
И, кстати - за какой срок должны быть достигнуты эти результаты - в первый же день после внедрения, или через неделю, или когда?
Ну и еще пример. Намеренно не из ИТ области.
Допустим, некто считает что используя рекламные щиты необычной конструкции (треугольные? тороидальные?), он сможет поднять продажи своих товаров на невиданную высоту. И хочет заказать эти щиты местной мастерской. Должен ли он в описании задания (а заказ щитов - тоже в некотором роде ТЗ), указывать эту самую "невиданную высоту" прибыли? Что некто будет проверять - соответствие формы изделия или рекламную отдачу? Мастерская - должна ли отказываться от заказа, если ее виденье рекламы не совпадает с заказчиком (т.е. они считают что никаких прибылей щиты не принесут)?
Проясните, пжлста, очень интересно.

ЮВВот вам система документоборота. Я гарантирую, что при соблюдении заложенной в ней технологии документ не потеряется, про него не забудут и он будет обработан за 3 дня.
Т.е., исполнитель (ИТ-подразделение) должен будет после продажи системы контролировать, что заложенная в ней технология соблюдается?

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


Nobody faults but mine... (LZ)

ЮВ
Разработчик. Рассчитать, обосновать и затем реально обеспечить.
Допустим, вы желаете разработать АС.
Объявляете тендер и выбирае того, кто предлагает (обоснованно!) наибольшую прибыль.
Обоснованно - это того кто лучше на бумаге разрисует? Разработчик, гарантирующий мне норму прибыли от своей АС - либо идиот, либо жулик. Почему я должен ему верить?
ЮВ
Вы путаете божий дар с яичницей.
Заказ щитов - это не ТЗ на ОКР, а договор на изготовление продукции по готовым чертежам заказчика.
Точно также авиазавод, который изготовил самолет по чертежам конструктроского бюро не отвечает за летные характеристики самолета, так и изготовитель щитов отвечает только за соответствие их чертежам.
Где у меня было написано про "готовые чертежи"? Нет, это именно ТЗ - нарисуйте нам, в вашем конструктороском бюро, чертежи "примерно такой формы" и сделайте по ним щиты.
Кстати, авиазавод за ЛТХ отвечает наравне с КБ - при различии заявленного и полученного, создаются комиссии которые выясняют причины.
ЮВ
Может ли конструкция рекламных щитов поднять уровень продаж?
Это вопрос НИР или ТЗ на разработку (поиск) рекламных щитов, поднимающих процент продаж.
Так вот, именно эти НИР или ТЗ и должны предоставить КОНКРЕТНЫЕ геометрические формы щитов и КОНКРЕТНО назвать цифры, на сколько повысится уровеь продаж.
А собственно изготовитель этих щитов тут ни при чем.
Замечательно. Т.е. изготовитель НИР проводить не должен, не так ли? Но тогда откуда он может взять уровень продаж?

shelsoft
2) Очень редко видел ТЗ, которые составлены действительно на систему . Т.е. учитывают не только ПО, но и предполагают штатные (не путать с организацией службы поддержки) изменения организации и изменения в нормативном обеспечении.

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


Может быть, потому что это другие документы, и называются они не ТЗ?

гость Владимир
ТЗ на НИР не содержит требований по увеличению прибыли на конкретное число, оно только лишь содержит требований определить условия, при которых прибыль будет увеличена на N процентов, или обосновать, что это невозможно.
Я предположу больше - ни в ТЗ, ни в НИР вообще нет ни слова про прибыль.

shelsoft
1) Читаем внимательно 4 слово в моем третьем пункте. Щас только не хватало приводить названия этих документов от ГОСТов(рус,ISO,IEEE) до бестпрАктик. [Пробрюзжал]
4-е слово "документы" :)
И я намекаю именно на то, что вопросы "изменения структуры организации и нормативных документов" не описываются каким-либо документом по ГОСТу (рус,ISO,IEEE). Эти вопросы либо относятся к консалтингу, т.е. это скорее область услуг, либо это вопросы самого заказчика.

shelsoft
2) Меняем первое слово на аналитик.
Давайте определимся. В контексте этой беседы лично я под словом "разработчик" понимаю ИТ-подразделение - как обособленное (ИТ-фирма, продающая некие ИС), так внутреннее, но имеющее одну "точку входа". Внутри которого есть и аналитики, и технологи, и пр.
Однако нигде ИТ-подразделение не определяет бизнес-концепцию предприятия.

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

ЮВ
Далее, скажем, предприниматель, доверившись НИР, решил подзаработать..
Он составляет ТЗ на ОКР, в котором предлагает на основе НИР разработать макеты (чертежи) рекламных щитов в пределах заданной стоимости, для заданного размещения и с заданной экономической эффективностью (реклама должна приносить прибыль!).
Исполнитель ТЗ на основе материалов НИР, конструирует подходящие под заданные требования щиты.
Результатом выполнения ТЗ на ОКР будут РАБОЧИЕ ЧЕРТЕЖИ И ТЕХНОЛОГИЧЕСКИЕ ДОКУМЕНТЫ для изготовления щитов. Именно на этом этапе исполнитель ТЗ ОКР несет ответственность за обоснованность своих решений.
Далее щиты изготовливает любое предприятие, которое несет ответственность только за их качество.

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