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

Может кто-нибудь уже сталкивался с подобный вопросом? Существуют ли какие-либо методики, стандарты?
Добрый день, Саша!
Для данных целей существует методика оценки трудоемкости 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?"  :) )
« Последнее редактирование: 25 Апреля 2012, 15:29:51 от alex6565 »
Кто знает, тот делает, кто не знает — тот учит других
(Б.Шоу)



Цитировать
второй вариант - это когда исполнитель описывает и затем разрабатывает (кодит) требования в форме Вариантов Использования (Use Cases). Для оценки затрат на реализацию требования в форме ВИ разработана и успешно используется методика Use Case Points
alex6565, согласен с вами в том плане, что при разработке новой системы оценка use case работает отлично, но в процессе доработки сам вариант использования может не измениться, меняется внешняя среда, интеграция между компонентами, т.е. получается необходима детализация UC.
  • при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org
     
  • при малой степени детализации CETIN - factor.kz/~CETIN
« Последнее редактирование: 25 Апреля 2012, 16:37:51 от sanaomir »



  • при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org
     
  • при мало степени детализации CETIN - factor.kz/~CETIN
Пасиб! Очень интересно - обязательно почитаю!
« Последнее редактирование: 25 Апреля 2012, 16:40:11 от alex6565 »
Кто знает, тот делает, кто не знает — тот учит других
(Б.Шоу)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19