Как обосновать трудоемкость разработки? Опции

[ZinyakinRS]

Здравствуйте все!В настоящее время наша контора в составе комплека КД на агрегат выпускает схемы электрические принципиальные (Э3). Последнее время в разработках стали все больше и больше использовать ПЛК. Труд по созданию ПО для ПЛК отдельно не нормировался - нормировалась вся схема целиком - пускай в форматах, пускай с коэффициентами за сложность и новизну. Сейчас сформировали отдельную группу и посадили писать ПО.
ВОПРОС существуют ли какие-нибудь нормы по трудоемкости на создание ПО? Буду признателен за нормативы разработанные сторонней организации для оценки собсвенных работ- чтобы я вник в них и хоть от чего-то начал отталкиваться. Для меня очевидно , что считать строки кода- это всеравно что Э3 в форматах нормировать - не эффективно и не в полной мере отражает трудоемкость разработки. Можно конечно, из уже наработанного опыта посчитать какая вышла практическая трудоемкость ПО для выполенных проектов.

Также предстоит отдельно нормровать - разработку пользователького интерфейса - выход экранные формы и менюшки, алгоритмы - выход блок-схема. Заглядываю в будущее -предстоит использовать не ПЛК, а МК - то есть среда разработки не интуитивно понятная для домохозяек, а уже на уровень выше. Заранее благодарен за ответы.

[bookd]

Для меня про строки кода совсем неочевидно. Если программист не разрабатывает новый алгоритм, а кодирует, то вполне можно посчитать число строк кода в день по предыдущим проектам и заложить их в стоимость.
Придумывание новых алгоритмов работа действительно трудно нормируемая, так как в нее входит изучение неопределенного количества документации. Невозможно предсказать, сколько документов придется перелопатить данному человеку если он пытается придумать новый алгоритм в новой для данного инженера области знаний.
Полагаю таких новшеств в ПЛК нет, есть стандартные алгоритмы управления, и как я понимаю речь идет о СКАДА системе, судя по наличию ПЛК и экранных форм. То есть Вы имеете дело с сильно формализованной средой, и задача программистов сделать дружественный интерфейс и запрограммировать ПЛК так, чтобы дружественный интерфейс был еще и действующим
Вполне можно считать строки кода.
С экранными формами тоже самое. Можно считать сколько точек ввода и вывода есть в форме, и опираясь на опыт прошлых проектов посчитать сколько занимает в конечном итоге одна точка ввода/вывода (ну там кнопочка или цифровой индикатор или числовой параметр).
С МК все тоже самое. Единственное чего не рекомендуется делать с МК это слушать грамотеев, которые будут убеждать Вас работать на языке ассемблера. Как только позволите, все туши свет, станете рабом этого грамотея. Потому что только он разберется в том коде, который этот грамотей наворотил.
А если в МК умеренной сложности алгоритм на семафорах, почему нет. Все точно также нормируется. Надо только один раз этот стояк создать, по которому крутится основной цикл и дальше останется только добавлять, убавлять ветви с конкретными задачами.
Экранные формы. На первый взгляд создать удобную форму задача для дизайнера. На самом деле нет. Надо только найти человека, который может быстро размещать параметры по окну так, чтобы ими было удобно пользоваться. Одним это дано, другим нет.
Иной гуру такое на экране наворотит, убить мало, но нельзя, гуру же, с глубочайшими познаниями. Вот и отправить его туда...к знаниям.
А на формы посадить человека который может. Искать такого надо среди тех, кто по жизни все упрощает и старается простым языком объяснять сложные вещи. Такие кадры и форму сделают такую, что неграмотные тетки враз начнуть доменными печами рулить.
Но вроде все. Не усложняйте. Труд программиста неоценимый ... это миф. Надо только иметь в наличии отчеты по прошлым проектам.
Если таких отчетов нет, возьмите текущий проект в системе контроля версий, и проанализируйте чего делал данный индивид с проектом каждый день. Работа муторная, но после того как Вы загоните результаты простых подсчетов в Excel за хотя бы месяц, удивитесь насколько люди работают монотонно, в том смысле, что объем кода ежедневно в среднем один и тот же. Независимо ни от чего.

[SyncLair]

ВОПРОС существуют ли какие-нибудь нормы по трудоемкости на создание ПО?

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