Уважаемые форумчане, скажите пожалуйста, пробовал ли кто-то рассчитывать трудоемкость встроенными в EA средствами Use Case Metrics? Если да, то с каким результатом? Может быть кто-то видел где-нибудь описание по использованию, хотябы рекомендации по выставлению коэффициентов. Вообще за любую информацию по оценке трудоемкости с помощью Use Case была бы очень признательна, хотябы просто методики вне инструментария.
У меня есть довольно полная модель Use Case в EA. Оценка уровня сложности (Complexity) по каждому Use Case проводилась по трехбальной шкале - Easy, Medium, Difficult. Хотелось бы попробовать рассчитать трудоемкость по этим параметрам, на сколько это вообще возможно. Пожалуйста, поделитесь опытом, если кто этим занимался.

Я не пробовала, но гугль нашел вот это:
http://forum.sources.ru/index.php?showtopic=8820
http://www.codeproject.com/KB/architecture/usecasep.aspx

Ирина, спасибо!
Первая методика, это действительно то, что реализовано в EA. Причем я ведь про нее когда-то читала .
Судя по "многочисленным" отзывам, никто в своих проектах не  оценивает трудозатраты по UCP. Интересно почему? Слишком неточная оценка получается? Не думаю, что методика Боэма или по функциональным точкам будет точнее.
Я все-таки попробую посчитать UCP и посмотреть как это соотносится с реальными цифрами по уже реализованным UseCas'ам. Результаты, если кому будет интересно, напишу.

Для рассчета трудозатрат по UCP требуется, чтоб UC был единицей измерения проекта. А реально я не видела такого в своей практике. Чаще делят проект на задачи по разным ролям, а потом прикидывают трудозатраты по ним.

Очень интересно будет увидеть результаты, спасибо, Smeagirle!

UCP, как и FP, имеют сильную погрешность, более мене правильно можно мерить (прикидывать) только имя статистику по похожим проектам.
Ваш опыт будет очень интересным, будем благодарны, если по результатам напишите статейку и опубликуете в блоге Сообщества.

To bus: Погрешности да, конечно. А Вы знаете метод в котором их нет? 
Я все-таки посчитала (благо затрат на это практически не потребовалось , вся информация для расчета уже была в модели).  И знаете что? Удивительно похоже на правду получилось. По крайней мере, судя по уже сделанной работе.
Итак,  исходные данные:
Есть проект, который длится некоторый период времени (точнее  10 месяцев).  Руководство требует озвучить какие-то (желательно  более-менее реальные) сроки завершения проекта (выхода бета-версии). Сам разрабатываемый проект - довольно типичное  клиент-серверное приложение.
На начальном этапе были собраны требования + проведен реверс-инжениринг действующей системы (т.к. главное требование – повторить функционал существующей системы, плюс некоторые расширения).  В результате появилась модель UseCase разрабатываемой системы.  Разработка ведется итеративно, в  т.ч. и  анализ. Т.е. на начальном этапе были собраны требования и выявлены UseCases (только перечень, без описания).  Далее для каждой итерации отбираются UseCases для реализации, делается их подробное пошаговое описание. По ходу проекта список UseCase меняется, но незначительно – в основном в сторону увеличения (изначально было выявлено 210 Use case, на данный момент их  236).
Для расчета UCP всем UseCases был проставлен  уровень сложности по 3-хбальной шкале, как рекомендует методика: до 3-х транзакций (реально оценивалось кол-во шагов в UseCases) низкая, от 3 до 7 средняя, больше 7 – высокая.
Коэффициенты уровня сложности проекта и квалификации разработчиков не считала (оставила дефолтные значения). Т.к. оценивается текущий проект, то поправочные коэффициенты не важны, ибо  они не меняются.
Итак,  что получили:
Общее кол-во UseCases – 236,  USP=1704.
За 10 месяцев было реализовано 75 UseCases (504 USP):
52 UC (229 USP) – первый этап (длительностью 6,5 месяцев, этап не был разбит на итерации).
18 UC (109 UCP) – 1 итерация 2 этапа (запланирована была на 2, реально продлилась 2,5 месяца);
5 UC (56 UCP) – 2 итерация 2 этапа (ровно 4 недели (с этого момента перешли на SCRUM: итерации сделали короткими, фиксированными по времени).
Т.е. средняя скорость получается  ~50 UCP/ в месяц. RUP рекомендует считать трудозатраты исходя из расчета  1 UCP – 20 ч/час. В EA дефолтное значение  10, что оказалось ближе к правде: в проекте ~3 разработчика, т.е. 480 часов в месяц.
Т.е. для оставшихся 1200 USP потребуется 12000 чел/час,  или 24 месяца при текущем положении вещей (т.е. 3-х разработчиках, работающих со скоростью 50 USP/месяц).
Что дал нам этот расчет:
1)   Руководство получило хоть и не утешительную, но  более-менее реальную дату окончания проекта.  В результате принято решение выделить дополнительные ресурсы (добавить в проект 1-2х разработчиков).
2)   Нам проще стало планировать итерации, т.к. мы знаем, что на итерацию нужно отбирать количество UserStory,   общим весом не более 50 USP, иначе просто не успеем сделать то, что запланировали. Судя по последней итерации, планирование получается весьма точным.

Спасибо за ценный опыт.

... т.к. мы знаем, что на итерацию нужно отбирать количество UserStory,   общим весом не более 50 USP ...

Не совсем понял как у вас происходит разработка Вы еще UserStory пишете по UC?

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

Будет еще хорошо, если напишите через пару месяцев - прогноз выполняется?!

Да, про UserStory это я не подумав ...   в принципе достаточно было про Use Case написать. В идеале это должно быть одно и то же, но на практике у нас не совсем так.
А разработка у нас ведется немного странным методом, что обусловлено тяжкой и разнообразной историей проекта. Я рассказывала эту грустную историю на ЛАФ: сначала был хаос (т.е. никакого проектирования, один разработчик, который написал 80 % функционала, после чего выяснилось что это немного не то что надо); потом был RUP - тяжелый такой, полновесный RUPище, за почти два года была проведена колоссальная работа по сбору требований, проектированию архитектуры, написана куча документации и... не написано ни строчки кода. Сейчас в проекте внедряется SCRUM. Собственно из скрама UserStory и всплыли.
Т.е. если полный цикл разработки рассматривать, то получается так:
есть ЗЗЛ (запросы заинтересованных лиц - высокоуровневые бизнес-требования), из которых  получились Требования (Requirements)  (функциональные и нефункциональные).  Есть UseCase модель старой системы (которую переписываем, и функциональность которой, как я уже говорила, нужно повторить). Есть модель UseCase разрабатываемой системы (на которую страсированы все требования и usecase старой системы, это чтобы ничего не забыть при разработке). Каждый UseCase описан с помощью sub-диаграмм Activity, Class, stateMachine и т.д. По каждому UseCase пишется один или несколько TestCases. Это все ведется в EA.
Затем, на итерацию отбираются UseCases из которых составляется Sprint Backlog, в виде User Story. Иногда (для простых UseCases) 1 UseCases= 1 UserStory, иногда, если удается разбить UseCases на относительно независимые части это может быть несколько UserStory. Плюс в Backlog включаются еще некие технические задачи, которые не описаны в UseCase. Дальше все по скраму - оцениваем User Story в StoryPoints, разбиваем на задачи, которые тоже оцениваются, но уже в идеальных часах. Backlog итерации (помимо традиционной доски) ведется в TFS. Там же ведутся Bugs,  Risks и другие Work Items проекта.
Т.е. все что требования, анализ и тестирование - в EA, все что разработка в TFS. По хорошему бы, конечно все в одно место перетащить, но TFS для аналитика пока слишком убог, пока там только тест-студию более-менее приличную сделали.

Ясно, спасибо.