Кто-нибудь задавался таким вопросом: какова норма AVC для 1С? AVC (aberage number of lines of code) - количество строк кода, необходимых для реализации одной функциональной точки. Для различных языков программирования AVC варьируется от 200 до 300 строк программы на одну функциональную точку. Данный показатель используется для расчета экономической эффективности разработки программы.

Приведу примеры:

Ассемблер 320
Макроассемблер 213
C 150
Algol 106
Cobol 106
Fortran 106
Pascal 91
Modula-2 71
Ada 71
Prolog 64
Lisp 64
Forth 64
Basic 64
C++ 53
Java 2 46
Objective C 26
Visual Basic 6 24
Smalltalk 21
Delphi 5 18
Языки запросов 16–13

(0) Думаю примерно как у бейсика, либо чуть ниже. Хотя вопрос конечно, как оно считается...

Вот пример статьи, где рассматривается само понятие функциональные точки: http://itc.ua/node/21814

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

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

Кстати, метод разработки вслепую тоже метод. Только он не позволяет оценить реальные трудозатрат и стоимость проекта. Отсюда и большая вероятность неудачи.

(0)Объсни смысл сабжа и приведенной статистики.

(5) При проектировании информационных систем рассматривают следующие методы оценивания стоимости разработки

1. алгоритмическое моделирование
2. экспертная оценка
3. оценка по аналогии
4. оценка по выделенному времени и рабочей силы
5. конъюнтурное назначение цены с целью выиграть тендер
и другие

Тот медод к которому я пытаюсь подвести - алгоритмический метод. Суть которого сводится к следующему:

Затраты = A * размер^B *M

где A - коэффициент, зависящий от класса разрабатываемого программного средства и организации разработки,
B - показатель, зависящий от размера программы, который варьируют в пределах от 1 до 1.5
M - коэффициент корректировки затрат, связанный с тем или иным этапом разработки, а также реализацией специальных требований к характеристикам разрабатываемого программного средства.

Размер программы = AVC*количество функциональных точек.

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

Вот еще одна статья по различным методам подсчета себестоимости проекта: http://itc.ua/node/25631

(7) А голову ломают обычно для того чтобы наиболее точно подсчитать себестоимость. Если количество денег - ограниченная величина, то этот вопрос является наиболее актуальным при проектировании проекта. Обычно те люди, которые обладают деньгами не хотят ими так просто делиться. Вот и приходится различным людям придумывать как обосновать необходимость этих денег для проекта. И весьма небезуспешно надо сказать.

(8) тут в основном практики собрались, а не теоретики.
работают восновном по (5).2-(5).3.
Поскольку эффективность разработки на 1С повыше и фраймверк сей поузкоглазее, в наборе решений заморачиваться с остальными методами смысла не имеет.

(8) Имхо бред
1) Как определить кол-во функц. точек в проекте?
2) Т.е. ассемблер и java примерно одинаковы при разработке
3) Кол-во строк кода проекта далеко не основной показатель

Basic 64
Visual Basic 624
--
без комментариев

(10) 1) Не хотел этим грузить. Количество функциональных точек = Сумма(Ф*Л) для каждого n. (математическая формула выглядит немного по другому). где n - количество факторов (критериев) подсчета функциональных точек (например количество диалогов ввода-вывода, операций с файловой системой и т.д.), Ф - количество характеристик (оценочных элементов) для каждого критерия подсчета функциональных точек.
Л - вес характеристик каждого критерия подсчета функциональных точек.

2) Они могут быть примерно одинаковы именно потому, что направлены на решение различных задач.

3) описанная технология как раз и предлагает уйти от количества строк кода, как основного показателя и обратиться к тем функциям которые с помощью него разрабатываются.

(11) имеется в виду 6ой Visual Basic

А как вы будете "чистые" языки сравнивать с предметно-оринтированным RAD?

Допустим с точки зрения 1С достаточно ЭтотОбъект.Записать(), а с точки зрения чистой явы столько налопатить кода надо...

Опять же интерфейсные вещи... Толковый грид под C# надо или искать халявный или покупать (скорее всего) - писать самому ИМХО затрахаетесь. В 1С все интерфейсные объекты уже есть.

(14) В том то и дело, что AVC по крайней мере для каждого языка рассчитывается индивидуально.

Кроме того, вместо функциональных можно использовать объектные точки. Объектные точки используют преимущественно для языков программирования четвертого поколения. Количество объектных точек в программе определяют путем предварительного подсчета следующих элементов:

1. Количество изображений на дисплее (простое изображение - одна точка, изображение умеренной сложности - две точки, очень сложные - три объектные точки).

2. Количество представленных отчетов (выходных документов). Для простых отчетов назначают две объектные точки, для умеренно сложных - пять. Сложные отчеты оценивают восемью объектными точками.

3. Количество модулей, которые написаны на языках третьего поколения и разработаны в дополнение к коду, написанному на языке четвертого поколения. Каждому модулю на языке третьего поколения назначают 10 объектных точек.

Методика расчета выглядит идиотской. Почему у стекового Форта, декларативного Пролога, функционального Лиспа и императивного Бейсика одинаковый AVC, а у какой-то дельфи, к примеру, в несколько раз меньше.Есть подозрение, что составители об экзотических языках знают только их название (ну в самом деле, по каким исходникам считалась эффективность модулы или смалтока?)
Кстати, если все же почитать Брукса, на которого они так рьяно ссылаются, получатся совсем другие выводы.
У 1С, к слову, показатель эффективности кода очень высокий. Для императивных языков, думаю, будет близок к максимальному. Что вполне логично и согласуется с ее природой: узкоспециализированная RAD-среда.