Попробую ответить на вопрос автора: вам необходимо применить "итеративный" метод разработки со своей стороны (судя по условиям исполнителя, они итеративные методы не используют).

Примеры буду приводить для интернет магазина.

1. По ТЗ составляете список use-cases:
UC1. Просмотр доступного товара пользователем
UC2. Покупка товара
UC3. Возврат товара
.........

2. Согласовываете с исполнителем объем работ (например, все UC из списка будут выполнены за 1 год за сумму N USD)

3. Выбираете из общего списка UC несколько основных:UC1 и UC2.
4. Прописываете выбранные UC в деталях:

UC1. Просмотр доступного товара пользователем
1а. На основной странице отображается список категорий....
2а. Пользователь кликает на категории и появлется новая страница с товарами из категории.
2а.1. В категории менее 10 товаров. Все товары отображаются на одной странице
2а.2. В категории более 10 товаров. 10 отображаются на одной странице и появляется линейка со страницами и т.п.

UC2. Покупка товара
1а. ПОльзователь нажимает кнопку Checkout.
2b. Экран для ввода name/password
2c.1. Пользователь ввел правильный пароль
2c.1.1. Экран для ввода адреса
2c.1.2. Экран для ввода кредитной карты
2c.1.3. Экран для подтверждения заказа
................
2c.2. Пользователь ввел правильный пароль
2c.2.1. Экран с сообщением и предложением выстлать пароль по почте
....................

5. Т.е. каждый UC распадается на множество возможных путей (аналогично алгритму программы). Выбираете из детально прописанных UC несколько "положительных" путей. Например, для
UC1: 1а. -> 2а.-> 2а.1.
UC2: 1a -> 2b -> 2c1-> 2c2 -> 2c3

6. Если у вас есть комптентные люди в разработке (а они я понял есть) оцениваете сколько процентов от общего объема занимают выбранные случаи.

7. Получаете от заказчика оценку сколько процентов от общего объема занимают выбранные случаи.

8. Если ваши оценки сильно расходятся - повод задуматься или получить от заказчика причину расхождения. Если срок слишком большой (но вы удовлетворены объяснениями) - еще ограничиваете выбранные пути. Основная идея - добиться РАБОТАЮЩЕГО варианта за максимально короткий срок (например, 10-20% от общего времени разработки)

9. Согласуете с заказчиком детали выбранных путей и сроки. Ожидаете результата. По результатам приемки первого этапа оплачиваете разработчику (или платите авансом) работу в процентом отношении (по вашей согласованной оценке) и договариваетесь/не договариваетесь на дальнейшие этапы.

Плюсы такого подхода:
1. Вы получаете РАБОТАЮЩИЙ продукт (не прототип, который выкидывается в помойку!) на ранней стадии и можете корректировать, если вам что-то не нравится ( может и за доп. деньги, но это лучше, чем когда уже все сделано и нужно половину переписывать).
2. На каждом этапе вы контролируете разработку, видете реальность сроков и после каждой следующей стадии можете с увеличивающейся вероятностью предсказать сроки окончания и результат проекта.
3. Вы платите за реально работающий продукт и в случае разрыва отношений теряете только аванс (если был) за последний этап.
4. Четко расписанные UC дают больше гарантий, что вам сделают то, что нужно, а не то, что исполнитель "подумал".

Дополнительно к этому:
1. Требуйте наличия АВТОМАТИЗИРОВАННЫХ тестов/unit-тестов при сдаче каждого этапа. В этом случае у вас есть некоторая уверенность, что количество ошибок не будет расти снежным комом и работающий на первом этапе каталог останется работающим при сдаче третьего этапа. Если вас заверяют, что в штате есть тестировщик, который "все протестировал по документу, который постоянно обновляется" - не верьте. Обговорите условия предоставления автоматизированных тестов, если исполнитель не владеет технологией сейчас - оговорите возможность (доп. бюджет, они/вы наймете доп. человека, который будет этим заниматься, покупка средств тестирования).
2. Наймите/определите в своем штате человека, который будет курировать этапы/оценки/создание UC и т.п.
3. Наймите/определите в своем штате человека, который будет оценивать техническое качество продукта (посмотрит код, тесты и т.п.)
4. Все требования по быстродействию и т.п. должны быть четко прописаны и продемонстрированы. Не "должно работать при большой загрузке на мощном обрудовании", а " на сервере Dell Intel Core 2 Duo 4 Gb ... при одновременной работе 10 пользователей время отклика не должно превышать 1 секунду". Кстати, демонстрация выполнения требований будет невозможна без использования хороших средств тестирования.

Уффф... Надеюсь, чем-то помог.

guest_20040621> 1. По ТЗ составляете список use-cases:

Дружище, Вы вообще представляете, как и почему связаны техническое задание и прецеденты? Понимаете, что существует не только UP, а еще целая куча методик проектирования?


Представляю. Просто то, что предлагается текущим исполнителем - это обычный waterfall - будем 2 года программировать, потом протестируем, а потом покажем заказчику (а потом будем еще 2 года переделывать). Я никого не призываю следовать конкретным методам разработки и т.п. - основная идея в том, что большой проект нужно постараться разбить на небольшие куски с максимально четкими требованиями и небольшими сроками.
Если вы готовы предложить метод разработки/проектирования, который позволит контролировать разработку и результат со стороны закзчика в бОльшей степени - пожалуйста, в студию.

guest_20040621
> " на сервере Dell Intel Core 2 Duo 4 Gb ... при одновременной работе 10
> пользователей время отклика не должно превышать 1 секунду".

Поделитесь, пожалуйста, источником этой ахинеи. Не верю, что Вы это придумали самостоятельно.


В чем здесь ахинея? Требования к производительности (если это вообще важно для проекта) должны быть формальными. Если у нас апликация для сбора и хранения данных - то в требованиях нужно записать спецификацию hardware и временные показатели работы системы. Если у вас требования записаны в виде - "все должно работать быстро на современном PC" - лучше было ничего не писать вообще.

Petro123
в целом IMHO конкретно, но вот откуда возьмётся в фирме человек понимающий то что вы написали.
Т.е. опять найм независимого эксперта-представителя..... (бригадира по возведению дома)

Как я понял из его постов, у автора в компании такие люди есть. Компетентность такого человека может быть пропорциональной стоимости проекта. Если проект на 500К, то можно потратить 50К на консультанта, чтобы увеличить вероятность успеха. Если же бюджет проекта 10К - то скорее всего и бить там на части нечего (хотя и в том случае, если заказчику важны сроки, когда он получит свой продукт, то и в этом случае лучше нанять консультанта на несколько недель).

Petro123
1. Вы получаете РАБОТАЮЩИЙ продукт (не прототип, который выкидывается в помойку!) на ранней стадии и можете корректировать, если вам что-то не нравится ( может и за доп. деньги, но это лучше, чем когда уже все сделано и нужно половину переписывать).
============ это и есть прототип, а не работающий продукт как вы написали.


Прототипом я называю (в случае интернет-магазина) - например, набор статических страниц, позволяющий оценить как будет выглядеть сайт и как с ним будет работать пользователь. Если же вы получаете выполненный UC, который крутиться на выбранной для реализации СУБД и движке - это уже работающий продукт, удовлетворяющий N% ваших требований (конечно, исполнитель может все переписать к следующей стадии - но это уже его проблемы).

Petro123
1. Требуйте наличия АВТОМАТИЗИРОВАННЫХ тестов/unit-тестов при сдаче каждого этапа.
========== более конкретно распишите


По unit-тестам: в хорошо протестированном приложении кол-во кода unit-тестов приблизительно равно коду самой программы. Есть средства (для разных языков разные), позволяющие оценить покрытие кода unit-тестами ( например, для .Net - NUnit/NCover). В unit-тестах также можно выполнить и часть performance тестов - заполнять базу тестовыми данными и проверять, что запросы выполняются в рамках заданного времени (если кто-то завтра уберет индекс, то мы узнаем об этом сразу, а не через 2 года, когда пользователь будет материться в службу поддержки).
Про функциональные/нагрузочные тесты - различных стредств очень много и они настолько разные, что нужно смотреть по средствам разработки и бюджету.