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

Может кто-нибудь уже сталкивался с подобный вопросом? Существуют ли какие-либо методики, стандарты?

Добрый день, Саша!
Для данных целей существует методика оценки трудоемкости CETIN, которая в том числе дает оценку трудоемкости и стоимости доработки программного обеспечения. Принципы методики приведены http://www.factor.kz/publ/detail.php?ID=1

>> существует методика оценки трудоемкости CETIN
существует - это громко сказано, насколько я понимаю это методика разработана для Гос заказов в Казахстане. Мирового признания пока не получила.

В рамках госзаказа да, т.к. методика ориентирована на раннюю оценку и применяется в госзаказе.
Но никто не мешает воспользоваться ее принципами, нежели использовать расчет по строкам кода

http://www.nitec.kz/?mod=chapter&lng=rus&opt=viewdoc&id=343
Методика, которая используется в Казахстане.

Саша, позволь добавить свои "5 коп.":
Если я правильно понял, существует следующая проблема:
Есть общая задача на доработку (разработку) функционала. Эта работа заказывается некоторому внешнему исполнителю. Исполнитель выкатывает какие-то оценки (с тайной мыслью: попробуй проверь!). Вам данные оценки кажутся неадекватными. Как самим получить оценки, которым вы а) доверяете и б) с которыми вы можете сравнить оценки исполнителя.
Я в такой ситуации поступил бы следующим образом:

• во-первых: оценил бы масшатаб работ. Это то, что входит в такую область деятельности, как "Change Management". Об этом очень подробно написал Денис. Добавить можно только некоторые незначительные моменты. Для чего это делатся? Мы оцениваем общий скоуп работ- определяем границы будущей работы;
  
• нам необходимо оценить стоимость элементов входящих в этот скоуп. Здесь возможны два варианта:
  
  • Исполнитель провел декомпозицию работ (WBS). Разбил общую задачу на атомарные шаги (работы). Потом оценил. Об этом писал Shur. Вы в свою очередь, тоже, запросив его декомпозицию, экспертным путем оценили трудозатраты на каждую атомарную задачу. Потом сравнили. Если оценки исполнителя на выполнение конкретной задачи сильно отличаются от вашей в большую сторону, необходимо выяснить "почему?". Как это сделать? Есть много техник так называемого Root Cause Analysis. Нет смысла затевать какое-то глобальное исследование. Можно использовать самый простой его вариант: "5 Why?". Считается, что достаточно 5 раз последовательно задать вопрос "почему?"  и вы докопаетесь до истинной причины. Пример из личной практики. Мы очень успешно использовали данный прием в общении с нашим удаленным разработчиком. Выясняя, почему он на выполнение плевой работы запрашивает несколько дней, в конце концов высняли, что собственно работа будет выполненна за 2 часа, остальное время - это почитать о новой технологии (т.е. читай - самообучится за счет проекта), потратить полдня на техосмотр машины и т.п.
    
  • второй вариант - это когда исполнитель описывает и затем разрабатывает (кодит) требования в форме Вариантов Использования (Use Cases). Для оценки затрат на реализацию требования в форме ВИ разработана и успешно используется методика Use Case Points. Вот здесь лежит очень внятный документик: http://www.bfpug.com.br/Artigos/UCP/Banerjee-UCP_An_Estimation_Approach.pdf  Понятно, что это оценка очень средняя, но во всяком случае позволит выявить ситуацию, когда вам пытаются впарить за $6000 работу, стоимостью в $700. Это будет хорошей базой для обсуждения цен исполнителя (вспоминаем "5 Why?"  )
    

второй вариант - это когда исполнитель описывает и затем разрабатывает (кодит) требования в форме Вариантов Использования (Use Cases). Для оценки затрат на реализацию требования в форме ВИ разработана и успешно используется методика Use Case Points

alex6565, согласен с вами в том плане, что при разработке новой системы оценка use case работает отлично, но в процессе доработки сам вариант использования может не измениться, меняется внешняя среда, интеграция между компонентами, т.е. получается необходима детализация UC.

• при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org
   
• при малой степени детализации CETIN - factor.kz/~CETIN

• при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org
   
• при мало степени детализации CETIN - factor.kz/~CETIN

Пасиб! Очень интересно - обязательно почитаю!