Ну вот предлагаю для обсуждения и критики следующие варианты

1. Усредненная рыночная стоимость услуг (котировки)
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Заказчик определяет список фирм, специализирующихся на разработке ПО, как в регионе присутствия Заказчика, так и в других регионах. Пусть количество таких фирм будет N.
- Заказчик подготавливает и направляет N запросов в адреса фирм из указанного перечня, с предложением указать стоимость их услуг по разработке ПО с требуемой функциональностью в требуемый срок.
- Полученные ответы (котировки) обобщаются Заказчиком, стоимость услуг усредняется по какой-либо методике, например, путем взятия средней цены, или путем отброса самой большой и самой малой цены и взятием среднего.
- Полученная усредненная цена УЦ услуг корректируется (умножается) на следующие поправочные коэффициенты:
а) коэффициент-дефлятор на год исполнения работ – КД;
б) коэффициент репрезентативности котировок – КРК;
в) коэффициент непредвиденных расходов – КНР.
- Полученная цена Ц=УЦ*КД*КРК*КНР закладывается в бюджет.

Данная модель имеют следующие плюсы:
- при увеличении числа участников, направляющих котировки, цена Ц будет приближаться к объективно-рыночной;
- высока вероятность найти исполнителя, который будет готов выполнить работы за сумму равную или меньшую рассчитанной Ц.

2. Оценка по базовой стоимости с коэффициентамиДанная методика основывается на применении повышающих или понижающих коэффициентов к абстрактной базовой стоимости услуг (аналог расчета вмененного налога или страхование ОСАГО).
- Заказчик определяет абстрактную базовую стоимость услуг (БЦ) исходя из следующих множителей:
1) средняя стоимость труда программиста в месяц, например $2000/мес.
2) количество программистов в усредненной группе способной решить абстрактный проект средней сложности, например - 5 чел.
3) средняя продолжительность разработки абстрактного проекта средней сложности, например - 1 год.
4) сопутствующие и непредвиденные расходы, закладываемые подрядчиком от стоимости проекта, например - 20%.
5) средняя прибыль, закладываемая подрядчиком от стоимости проекта, например - 30%.
Например, БЦ = 2,000*12*5*(20%+30%) = $180,000/год.
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Базовая цена абстрактного проекта умножается на повышающие/понижающие коэффициенты, отражающие сложность реальной задачи по отношению к усредненной абстрактной (см. ниже) на основании имеющихся функциональных требований. Шкала значений коэффициентов может быть выбрана любая, при этом коэффициент 1 соответствует базовому абстрактному проекту.
1) срок исполнения работ отличается от базового (1 год) в меньшую или большую сторону – Кс.
2) методическая изученность бизнес-процесса – ИБП;
3) необходимость миграции данных– НМ;
4) необходимость интеграции с имеющимся ПО – НИ;
5) несколько видов интерфейсов пользователя – ИП;
6) специфичность ОС - СпОС;
7) специфичность СУБД – СпСУБД.
- Полученная цена Ц=БЦ*КС*ИБП*НМ*НИ*ИП*СпОС*СпСУБД закладывается в бюджет.

3. Оценка «в попугаях»
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Заказчик определяет уже исполненный эталонный проект, который удовлетворяет заказчика по функциональным характеристикам и на разработку которого в некоторый срок С затрачена сумма денег П, при этом, Заказчик субъективно считает, что показатель стоимость ПО/эффективность ПО является оптимальным (идеальным). Назовем такой проект-эталон, оцениваемый в сумму П, «попугаем».
- Заказчик рассматривает сложность и трудоемкость новых проектов, а соответственно и стоимость, «в попугаях», т.е. стоимость нового проекта определяется как Ц=П*К*Кс, где К - коэффициент сложности/простоты (т.е. «количество попугаев»), Кс - срок исполнения работ отличается от срока С для «попугая» в меньшую или большую сторону.

ну, собственно я примерно ту же идею описал в п.1 своего поста

по Вашем замечаниям непонятно следующее:
KGP3. рассылаете ТТЗ по компаниям и предлагаете определить им их
3.1 предварительные суммы
3.2 предварительные отчетные документы (считай смета)

разве не достаточно разослать только требования и желаемые сроки которые должен и может готовить заказчик? ТЗ если к нему тщательно подходить штука достаточно трудоемкая и как правило возлагается уже на исполнителя на первоначальном этапе работ. По крайней мере практика сечас у нас такова.

далее, что такое "3.2 отчетные документы"? это смета расходов подрядчика? Что-то я сомневаюсь, что на уровне предварительных котировок фирмы потратят на это время, более того, это и не в их интересах на данном этапе.


KGP5. закладываете среднюю сумму по компаниям, которым вы доверяете
критерий субъективный, для методики годится большо натяжкой. Почему Вам не понравился коэффициент репрезентативности котировок (КРК), в который заложено, то что если компаний приславших котировки достаточно мало, то верить такой усредненной цене можно меньше чем если бы их было много, например более 10 или 20.

мне понравилась Ваша мысль добавить еще одну итерацию по оценке проекта на этапе предваряющим тендер но до окончания верстки бюджета :)

стесняюсь спросить разницу между ТЗ иТТЗ

[quot kvasov]какие могут быть проблемы если деньги есть? - надо не лениться их тратить
мне так кажется
[/kvasov]

я говорю про гос.организацию, планирующую свой бюджет на 3 года вперед. Денег еще нет, но они могут появиться если их заложить в бюджет, а заложить можно только обосновав на бумаге, в первую очередь для ФАС и прокуратуры, а не поковыряв пальцем в носу.

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

[quot KGP1. есть понятие прототип ... но это достаточно дорогое удовольствие
2. хм ... может мы ведем речь о проектах разного уровня? имхо:
2.1 большенство успешных компаний за 1000$ просто послют за птицами
[/quot]
именно
KGP
2.2 Заказчик ТЗ не в состоянии подготовить в том виде, что можно было даже архитектуру набросать, тем более прототип

тоже верно

KGP Rus000стесняюсь спросить разницу между ТЗ иТТЗ

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

хотя я придерживаюсь для себя скорее терминов vision, srs; и считаю, что в подготовке vision заказчик выполняет большую роль, чем в подготовке srs, use case specification ... особенно это важно при больших/неопределенных проектах

смотрим гост 34.601-90


в нашем случае 1.1-1.2 как раз подойдет