Для оценки трудоемкости может быть и не нужны. Но вот для обоснования стоимостных показателей проекта перед заказчиком (так чтоб ему самому чем прикрыться можно было) совсем не помешают.

При этом никто не мешает определять стоимость другими методами, а на нужные показатели выходить  играя параметрами расчета.

Это пять!!! Берем произвольную стоимость, манипулируя параметрами подгоняем под результат и потом выдаем это за обоснование. И втюхиваем доверчивому заказчику.

Честные люди называют это по другому. Кто как, но термин "очковтирательство" тоже пойдет.



Райкин - оптический обман зрения: https://www.youtube.com/watch?v=rqR7bcDzQ1k

Ну и немного неприятного. Трудоемкость (и стоимость) проекта - вероятностная величина. Не существует никакой "точной" оценки, потому что трудоемкость можно посчитать только после завершения проекта. От этого рвет крышу, но истина такова. Если взять три примерно одинаковых команды (A, B, C) и два примерно одинаковых проекта (K, L) и каждую команду попросить сделать каждый проект, то вполне может получиться такой разброс в трудоемкости:

Проект K
A - 200 человекочасов
B - 600
C - 2500

Проект L
A - 1000
B - 100
C - 800

Я примерно такой эксперимент ставил и результат удивил даже меня.         
         
         
         
         
         
         

Если взять три примерно одинаковых команды (A, B, C) и два примерно одинаковых проекта (K, L) и каждую команду попросить сделать каждый проект, то вполне может получиться такой разброс в трудоемкости:

Я бы даже взялся утверждать, что одна и та же команда выполнит один и тот же проект в разное время (читай, в разных условиях) очень по-разному. Жаль, экспериментом не проверишь.

Берем произвольную стоимость, манипулируя параметрами подгоняем под результат и потом выдаем это за обоснование. И втюхиваем доверчивому заказчику.

Тссс! Не пали основной метод ценообразования.

Ну и немного неприятного. Трудоемкость (и стоимость) проекта - вероятностная величина. Не существует никакой "точной" оценки, потому что трудоемкость можно посчитать только после завершения проекта. От этого рвет крышу, но истина такова. Если взять три примерно одинаковых команды (A, B, C) и два примерно одинаковых проекта (K, L) и каждую команду попросить сделать каждый проект, то вполне может получиться такой разброс в трудоемкости:

Проект K
A - 200 человекочасов
B - 600
C - 2500

Проект L
A - 1000
B - 100
C - 800

Я примерно такой эксперимент ставил и результат удивил даже меня.

Честно говоря думал что уважаемые форумчане в курсе таких очевидных истин...
Никакого очковтирательства нет, нормальный заказчик прекрасно понимает суть данного ценообразования. И то что результат такой прикидки довольно приблизительный прекрасно понимает.

Вопрос в том, какой заключается контракт - если это FP, то заказчика вообще не волнует себестоимость проекта - это проблема самой команды. А самой команде нужны метрики , которые работают на всех стадиях проекта. С этой точки зрения  UC в качесте метрики подходят идеально - их можно получить на любой стадии проекта. На начальных стадиях они более грубые и менее детальные. Но если при этом отслеживать преемственность от стадии к стадии . Соответственно всегда можно проводить анализ, что в бюджете, а что нет. UC просто выступает в качестве расходной статьи бюджета. И при измении UC паралельно меняется структура бюджета.

Если Т&М , то заказчик контролирует фактические затраты и превышение бюджета. При Т&M бюджет примерный и его превышение допустимо , но бюджет контролируется, опять же его превышение (уменьшение надо обсновывать (почему бы не обосновать через изменение UC?) .

Суть использования UC не в точности прогнозирования стоимости, а в задании структуры стоимости, которой впоследствии можно управлять

Честные люди называют это по другому. Кто как, но термин "очковтирательство" тоже пойдет.

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

Но видимо каждый думает о том, что у него наболело

Эх... Трассировку от стоимости в ТЭО к фактической стоимости проекта можно сделать только по завершении последнего. Все остальные "методики" - лишь теории, которые стоят одна другой.

Ну да. А текущая себестоимость проекта и ожидаемая стоимость совершенно неинтересные показатели...

Вот! Вот это по-нашему! Только зачем при этом нужен какой-то расчет? Можно же играть сразу в бюджет: трудозатрат поменьше, профит побольше, результат быстрее и не нужно слушать капризы программиста (а то и целой команды) системы расчета.

Как раз и хочется воспользоваться EA не в качестве UML рисовалки, а в качестве полноценного средства управления разработкой. В том числе и ее бюджетом. Потому как без такой автоматизации на подобные расчеты много времени уходит.

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

Ценообразование с такой сутью легко выполняется на половине бумажного листка ручкой или в несколько кликов в проджекте. Достоверность примерно равная. Зачем городить огород, создавая иллюзию "солидности" (мол, мы не от балды выкатили, у нас все ходы записаны). Иллюзии такого рода создаются как правило с одной целью - втюхать подороже. Реже - когда тот, кому втюхивают, в доле и ему нужно оправдаться, что уплочено не зазря. И то, и другое пахнет не очень.

Наверное, есть исключения, когда этим занимаются из спортивного интереса. Или возлагают по наивности некоторые надежды. Только не дороговато ли получится? Ведение таких моделей требует кропотливой работы и постоянного внимания. Не лучше ли пустить их на создание результата?

А самой команде нужны метрики , которые работают на всех стадиях проекта. С этой точки зрения  UC в качесте метрики подходят идеально - их можно получить на любой стадии проекта. На начальных стадиях они более грубые и менее детальные. Но если при этом отслеживать преемственность от стадии к стадии .

Если у нас UC - это "сценарии использования", то в качестве метрик по которым можно считать затраты, они никакие. Т.е. по ним можно прикинуть часть затрат, но очень-очень приблизительно и при любом изменении базиса (вроде архитектуры решения или нормативки) все эти прикидки можно выкинуть.

Соответственно всегда можно проводить анализ, что в бюджете, а что нет.

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

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

Почему при изменении статьи бюджета должна меняться его структура?

бюджет контролируется, опять же его превышение (уменьшение надо обсновывать (почему бы не обосновать через изменение UC?).

В таком качестве - да, запросто. Будет выглядеть солиднее, чем вспышки на Солнце или Луна в созвездии Козерога.

Суть использования UC не в точности прогнозирования стоимости, а в задании структуры стоимости, которой впоследствии можно управлять

Хреновая структура стоимости получится. И управляться будет хреново (вернее, структура управляться будет хорошо, хреново будет с "управлением" стоимостью).

Ну да. А текущая себестоимость проекта и ожидаемая стоимость совершенно неинтересные показатели...

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

Как раз и хочется воспользоваться EA не в качестве UML рисовалки, а в качестве полноценного средства управления разработкой. В том числе и ее бюджетом. Потому как без такой автоматизации на подобные расчеты много времени уходит.

Признаюсь, EA кроме как рисовалкой не пользовался. Он вообще рассчитан на управление разработкой?
Обычно в этих целях используют что-то вроде проджекта или джиры.

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

Признаюсь, EA кроме как рисовалкой не пользовался. Он вообще рассчитан на управление разработкой?
Обычно в этих целях используют что-то вроде проджекта или джиры.

Вопрос не в самой оценке, а в том, что варианты использования вполне могут стать сквозной аналитикой, метрикой проекта.

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

Не изучал еще детально встроенные средства EA (там вроде присутствует календарное планирование),  но как минимум UC можно завести в качестве работ в проджекте.

Кстати регистрировать запросы на изменения в EA  можно (тоже не изучал).

Понятно, что планирование в EA не будет таким удобным, как в проджекте, а трекинг не таким удобным как в джире, но зато в EA можно держать ВСЕ виды моделей, в нем можно настраивать документирование, кодогенерацию и держать в самом проекте "вручную" написанные исходные коды (опять же не пробовал, но такие возможности есть)

И кстати в качестве метрики проектов можно использовать не только UC, а любые обьекты. Любые модели, которые характеризуют проект  и по которым можно осуществлять трассировку на всех его стадиях могут выступить в качестве его метрики (прежде всего BPMN и диаграммы последовательности)

Но это так, фантазии Для начала хотелось бы немножко облегчить себе жизнь на первых стадиях проекта.

Вопрос не в самой оценке, а в том, что варианты использования вполне могут стать сквозной аналитикой, метрикой проекта.

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

Да. Это то, о чем писали я и SALar чуть выше. Оценка по аккуратно заполняемым таймшитам - оценка пост-фактум. Точная, как у патологоанатома. Вот так действительно можно посчитать затраты проекта.
Ну, это если предположить, что в шытах шыта не будет. Чего я за свой некоторый опыт еще не видел: как только людей заставляют писать, чем они занимались (и не дай Бог, еще и решения какие-то принимают на основе ими написанного), практически на всех разом нисходит вдохновение и "трудятся" они на бумаге по 9 часов из 8. Причем над самыми животрепещущими задачами.

Понятно, что планирование в EA не будет таким удобным, как в проджекте, а трекинг не таким удобным как в джире, но зато в EA можно держать ВСЕ виды моделей, в нем можно настраивать документирование, кодогенерацию и держать в самом проекте "вручную" написанные исходные коды (опять же не пробовал, но такие возможности есть)

Не слышал о применении ЕА в качестве репозитория кода. От слова "совсем". На Вас за такие инициативы программисты могут... обидеться. Примерно как ПМы за затаскивание их в EA вместо родного проджекта.

И кстати в качестве метрики проектов можно использовать не только UC, а любые обьекты. Любые модели, которые характеризуют проект  и по которым можно осуществлять трассировку на всех его стадиях могут выступить в качестве его метрики (прежде всего BPMN и диаграммы последовательности)

Тут как с грибами: есть можно все, но не все стоит.

Но это так, фантазии Для начала хотелось бы немножко облегчить себе жизнь на первых стадиях проекта.

Я боюсь, что именно так оно и есть (про фантазии).
И нихрена себе у Вас представление про "облегчить"...

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

Да. Это то, о чем писали я и SALar чуть выше. Оценка по аккуратно заполняемым таймшитам - оценка пост-фактум. Точная, как у патологоанатома.
книга Стива Макконнелла "Сколько стоит программный проект".

Нет, не так. Если Брать пост SALar

Для оценки трудоемкости не нужен SQL. Не нужна EA.
А нужна книга Стива Макконнелла "Сколько стоит программный проект".

то речь идет об оценке, а не о калькулировании факта

 Вот так действительно можно посчитать затраты проекта.
Ну, это если предположить, что в шытах шыта не будет. Чего я за свой некоторый опыт еще не видел: как только людей заставляют писать, чем они занимались (и не дай Бог, еще и решения какие-то принимают на основе ими написанного), практически на всех разом нисходит вдохновение и "трудятся" они на бумаге по 9 часов из 8. Причем над самыми животрепещущими задачами.

Как все плохо то.... Ни спрогнозировать, ни факт посчитать. Правильно ли я понимаю, что единственно возможным вариантом является ввод коммунизма - программистам и аналитикам платить по потребностям, а сроки устанавливать полагаясь на их сознательность 

Не слышал о применении ЕА в качестве репозитория кода.

Тем не менее такие возможности есть. И настройка редактора кода на различные языки, и подключение разных компиляторов и разработка скриптов для автоматической сборки проекта. Собственно без этих сервисов  кодогенерация бессмысленна - проще вообще все вручную делать. Насколько все удобно надо пробовать - я ж сразу обозначил, что делаю эту задачку в контексте изучения возможностей EA.

Ну с програмистами и PM отдельный разговор. Может в EA полноценно загнать не получится, так можно подумать об интеграции. Структура базы у EA прозрачная, скрипты есть - что еще нужно...

И нихрена себе у Вас представление про "облегчить"...

Непонятно, что вас смущает? При первичной проработке думать все равно приходится. Проще думать над моделями (пусть даже неточными и грубыми) - мне по крайней мере. Рисовать модели более менее все равно в чем. Оценка трудоемкости, выпускаемая по кнопочке - бонус

Нет, не так. Если Брать пост SALar

Не тот пост берете. См. №16.

Как все плохо то.... Ни спрогнозировать, ни факт посчитать.

Се ля ви. Ну, с небольшой оговоркой - факт можно "посчитать" по зарплатным ведомостям и расходникам. В подробностях - это уже искусство.

Правильно ли я понимаю, что единственно возможным вариантом является ввод коммунизма - программистам и аналитикам платить по потребностям, а сроки устанавливать полагаясь на их сознательность 

Хех... Наилучший результат, который я видел в разработке больших и отвественных систем, был именно у такой команды. Сидели они в своей конторе, прорабатывали себе нормативку, математику, сами писали по ним софт. Более 20 лет так работали. Ни тебе энсотмиллионных контрактов, ни корпоративов в куршавелях. Только зарплата инженеров с соразмерными премиями. Периодически отмечали юбилеи друг дружки тортиками под чай. Кому 60, кому 70.

А система их, что характерно, работала. Пока "молодые и амбициозные" (каждый год новые) приходили их автоматизировать.

Но будем считать, что это случайное совпадение. Безусловно, молодой и амбициозной команде, имеющей на оснащении 10 программных систем энтерпрайз-уровня и бегло изъясняющейся на 10 нотациях, любая задача по плечу. Особенно если энсот лямов ее хозяевам отсыпать.

Тем не менее такие возможности есть.

Да там много чего есть, я даже не сомневаюсь. И при наличии должного энтузиазма многое можно сделать (например, как сделали X-COM  в экселе). Вот только есть более признанные и более распространенные подходы.

Насколько все удобно надо пробовать - я ж сразу обозначил, что делаю эту задачку в контексте изучения возможностей EA.

Что вызывает уважение (и чуть-чуть зависти). Пробовать что-то новое, лезть в какую-то неведомую дыру - занятие полезное.

Проще думать над моделями (пусть даже неточными и грубыми) - мне по крайней мере. Рисовать модели более менее все равно в чем. Оценка трудоемкости, выпускаемая по кнопочке - бонус

Вот это и смущает. Вы стремитесь думать своими категориями над тем, для чего давно придуманы другие (и придуманы не просто так).

Да не обращайте внимания, в конце концов. Оно ж меня смущает, а не Вас.

Вобщем сделал, что хотел.

Во вложении пример расчета, константы и xml с переведенными на русский язык наименованиями показателей сложности и квалификации, а так же расчет со всеми custom SQL фрагментами

Не нашел, где EA держит константы трудоемкости на UUCP (в файле T_constant такая константа есть, но по факту ее EA не использует, а берет откуда то из другого места), стоимости часа разработки (тоже в новых константах)  и параметр отчета об учете ACTOR (учитываются всегда)
 
Соответственно константы CostPerHour и HoursPerUCP можно поменять через ACCESS

По процессу:

В принципе EA понравился - все просто, понятно, безглючно. Основной негатив вызывал не EA, а убогость акцессовского SQL (избаловался на Oracle). Но изучать имеет смысл сразу со скриптов. Ограничение один фрагмент-один запрос в custom SQL делает его применение довольно бессмысленным (за такие запросы и многократные перечитывания данных другого бы програмиста расстрелял ), так что кто заинтересуется и начнет изучать документирование EA, то разбирайтесь сразу со скриптами. На них же потом можно всякие визарды потом писать и кодогенерацию, а не только отчеты

Вложения - поправлены (до этого почему то загружались 0 размера)