Есть заявка на разработку того или иного нового функционала.
Нужно как-то оценить сложность до начала проведения работ.

Кто какими критериями пользуется для формальной оценки сложности.

Пока составил список из следующих критериев

* Ясность задачи
* Ясность процесса подлежащего автоматизации
* Наличие опыта использования механизмов необходимых для реализации доработки
* Количество участвующих в доработке систем
* Предварительная обработка данных
* Обработка данных после внедрения доработки
* Модификация процесса подлежащего автоматизации
* Длительная (более 25% от всего процесса реализации доработки), но понятная и простая работа (описание функционала, написание инструкции, простой кодинг)
* Известны границы доработки
* Наличие проработанной модели доступа к объектам доработки (права, роли)

Оценка веса критериев будет позже. Сначала нужен полный список критериев оценки.

Если есть ГОСТ, тоже был бы благодарен.

Вы хотите оценить степень выразительности взгляда в процентах?

Это все экспертная оценка. Личное мнение и не более того.

(1) Знаю...
но экспер на что-то опирается.

(0) Цель?

(0) Жми на Я - 1 млн ответов на широко поставленый вопрос с замахом на конкретный ответ с конкретным списком вариаций.

Мне понравилось это
http://www.bestpravo.ru/sssr/eh-postanovlenija/y7o.htm
Например, "1.1 Аналитический метод оценки сложностей."

(3) Категорировать доработки и в отчетах руководству показать что иногда 3 месяца, это оправданные затраты. А иногда и недели много.

:)...сферическая экстраполяция сложности задачи в вакууме...

(6) Ну да.
(4) Смотрю. пока не нашел то, что ищу.

(7) И не найдешь. Там методология. Как ты сможешь применить ее идеи к той, которая витает у тебя - вопрос времени.

(5) Иерархия вас спасет. Поясняю идею...
1. От пользователя поступает "обращение".
2. Обращение "разбирается" - х часов по стандарту на выяснение "чего же хотят на самом деле".
3. Обращение преобразуется в задачи. Например: пользователь хочет отчет, для отчета необходимо а) сделать подсистему учета ххх (условно не менее 2 месяцев) б) написать отчет (3 дня по стандарту)

и т.д.
Т.е. обращение пользователя бьете на задачи, задачи уже классифицируются по типам (создать документ/разработать отчет/сделать подсистему/завести пользователя и т.д. и т.п.)

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

http://www.iteam.ru/publications/project/section_36/article_2495
wiki:%CC%E8%F4%E8%F7%E5%F1%EA%E8%E9_%F7%E5%EB%EE%E2%E5%EA%EE-%EC%E5%F1%FF%F6

(9) Это один из рассматриваемых вариантов (по количеству объектов/классов). Довольно сложно оценить на начальном уровне.
Но пока приберегаю его если ничего другого не придумаю.

(10) Книжку читал. До сих пор актуальна. Попробую еще раз просмотреть.

(9) А начальству отчитываетесь, было хх обращений, по итогам которых родилось уу задач (по классам) + остатки с прошлого периода, в отчетный период решили zz...

Мы так делали, имхо самый адекватный способ обоснования разницы топ-ам, далеким от ИТ.

(13) У нас два вида учета. Делим разработку и поддержку.
По поддержке более, менее понятно (и то, сегодня с начальником отдела первой линии поддержки возникли разногласия).
Вопрос именно про разработку.

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

(14) И? С разработкой что непонятно?
тут главное грамотно классификатор составить видов работ и правильно "задачи" бить на классифицируемые подзадачи.

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

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

(2) И опыт, сын ошибок трудных...

Если применительно в разговору с заказчиком, то:
И. Млин, ну это нереально тяжело! 100 часов и 20 штук.
З. Да Вы нереально окуели! 50 часов и 10 штук.
И. Не, нам в 100500 местах править. И вообще кушать хоцца. 75 часов и 15 штук.
З. Да Вы меня по миру пустить хотите, оглоеды... Лады.

РП и программер:
РП. Я тут впарил клиенту обработочку на 75 часов. Нужно быстренько за 10 часов написать и сдать.
П. Не, никак! Тут работы на 100 часов минимум!
РП. Не канифоль мне мозг. Там работы на пять часов!
П. А перекурить, кофе попить, Мисту почитать? Не, меньше 50 никак!
РП. Уволю!
П. Ну ладно. Согласен. (один фиг такую же уже для ООО "Рога и копыта" писал и в архиве лежит)

Вот в все сложности с трудоемкостями.

(0) оценивай сложность и умножай на 2 минимум.

(19) на 3)

(11) по поводу сложности оценки на начальном этапе - введите задачу "выяснение", результатjм которой должен быть рамочный мини-проект/внутреннее тз.
На их основании уже стройте правдоподобную иерархию работ в проджекте (например) и оценивайте.

Вопрос в (0) частный случай подраздела "Проблемы разработки ПО"
wiki:%D0%E0%E7%F0%E0%E1%EE%F2%EA%E0_%EF%F0%EE%E3%F0%E0%EC%EC%ED%EE%E3%EE_%EE%E1%E5%F1%EF%E5%F7%E5%ED%E8%FF

(10) тут возникает другой аспект
1 лошадь - 1 л.с.
2 лошади - 1.8 лс
4 лошади - 3 л.с.

(16) Сложно оценить до начала анализа.
Пока нашел вот это - http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf.
Может кому пригодиться.

(23) Это зависит от  р а з д е л и м о с т и  задачи. Если она разделима, и, если раздать повару готовить еду, а сапожнику - шить сапоги.

1 лошадь - 1 л.с.
2 лошади - 3 л.с
4 лошади - 7 л.с.

В (18) самый правильный ответ - ни добавить ни убавить...

(24) Спасибо! Интересное изложение.