Размер программы в строках

Строки исходного кода (SLOC ), также известные как строки код (LOC ) — это метрика программного обеспечения, используемая для измерения размера компьютерной программы путем подсчета количества строк в тексте исходный код программы . SLOC обычно используется для прогнозирования объема усилий, которые потребуются для разработки программы, а также для оценки продуктивности программирования или ремонтопригодности после создания программного обеспечения.

Методы измерения

Многие полезные сравнения включают только порядок величины строк кода в проекте. Использование строк кода для сравнения проекта из 10 000 строк и проекта из 100 000 строк намного полезнее, чем при сравнении проекта из 20 000 строк и проекта из 21 000 строк. Хотя вопрос о том, как именно измерять строки кода, является спорным, расхождения порядка величины могут быть четкими индикаторами сложности программного обеспечения или человеко-часов.

Существует два основных типа показателей SLOC: физический SLOC (LOC) и логический SLOC (LLOC). Конкретные определения этих двух показателей различаются, но наиболее распространенное определение физического SLOC — это количество строк в тексте исходного кода программы, исключая строки комментариев.

Автоподбор ширины столбца (высоты строки) в Excel

Логический SLOC пытается измерить количество исполняемых «операторов» «, но их конкретные определения привязаны к конкретным компьютерным языкам (одна простая логическая мера SLOC для C -подобных языков программирования — это количество точек с запятой в конце оператора). Намного проще создавать инструменты для измерения физического SLOC, а определения физических SLOC легче объяснить. Однако физические показатели SLOC чувствительны к логически несущественным соглашениям о форматировании и стилях, в то время как логический SLOC менее чувствителен к соглашениям о форматировании и стилях. Однако меры SLOC часто указываются без их определения, и логический SLOC часто может значительно отличаться от физического SLOC.

Рассмотрим этот фрагмент кода C как пример неоднозначности, возникающей при определении SLOC:

for (i = 0; i < 100; i++) printf(«hello»); /* How many lines of code is this? */

В этом примере мы имеем:

• 1 физическая строка кода (LOC),
• 2 логические строки кода (LLOC) (для оператора и printf statement),
• 1 строка комментария.

В зависимости от программиста и стандартов кодирования, указанная выше «строка кода» может быть записана на многих отдельных строках:

/ * Теперь, сколько это строк кода? * / For (i = 0; i

В этом примере мы имеем:

• 4 физических строки кода (LOC): нужно ли расставить фигурные скобки для оценки работы?
• 2 логических строки кода (LLOC): как насчет всей работы, написанной без инструкций строки?
• 1 строка комментария: инструменты должны учитывать весь код и комментарии, независимо от их размещения.

Даже «логические» и «физические» значения SLOC могут иметь большое количество различных определений. Роберт Э. Парк (находясь в Институте программной инженерии ) и другие разработали фреймворк для определения значений SLOC, чтобы люди могли подробно объяснить и определить меру SLOC, используемую в проекте. Например, большинство программных систем повторно используют код, и определение того, какой (если есть) повторно используемый код включить, важно при составлении отчета о показателе.

АВТОПОДБОР ВЫСОТЫ СТРОКИ И ШИРИНЫ СТОЛБЦА В EXCEL

Происхождение

В то время, когда люди начали использовать SLOC в качестве метрики, наиболее часто используемые языки, такие как FORTRAN и язык ассемблера, были строчно-ориентированными языками. Эти языки были разработаны в то время, когда перфокарты были основной формой ввода данных для программирования. Одна перфокарта обычно представляет собой одну строку кода.

Это был один дискретный объект, который легко пересчитать. Это был видимый результат работы программиста, поэтому менеджерам было разумно считать строки кода мерой производительности программиста, даже имея в виду такие, как «изображения карточек ». Сегодня наиболее часто используемые компьютерные языки предоставляют гораздо больше возможностей для форматирования. Текстовые строки больше не ограничены 80 или 96 столбцами, и одна строка текста больше не обязательно соответствует одной строке кода.

Использование мер SLOC

Меры SLOC несколько спорны, особенно в том смысле, что они иногда используются не по назначению. Эксперименты неоднократно подтверждали, что усилия сильно коррелируют с SLOC, то есть программы с более высокими значениями SLOC требуют больше времени для разработки. Таким образом, SLOC может быть эффективным при оценке усилий.

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

Подсчет SLOC вызывает дополнительные проблемы с точностью при сравнении программ, написанных на разных языках, если не применяются поправочные коэффициенты для нормализации языков. Различные компьютерные языки по-разному уравновешивают краткость и ясность; В качестве крайнего примера, большинству языков ассемблера потребовались бы сотни строк кода для выполнения той же задачи, что и несколько символов в APL. В следующем примере показано сравнение программы «hello world», написанной на C, и той же программы, написанной на COBOL — языке, который известен своей особенно многословностью..

# include int main ()

идентификационный отдел. идентификатор программы. Здравствуйте. процедурное деление. отобразить «привет, мир» вернуться. конец программы привет.

Другой все более распространенной проблемой при сравнении показателей SLOC является разница между автоматическими сгенерированный и рукописный код.

Современные программные инструменты часто имеют возможность автоматически генерировать огромные объемы кода с помощью нескольких щелчков мыши. Например, построители графического интерфейса пользователя автоматически генерируют весь исходный код для графических элементов управления, просто перетаскивая значок в рабочее пространство. Работа, связанная с созданием этого кода, не может разумно сравниваться с работой, необходимой, например, для написания драйвера устройства. Точно так же созданный вручную пользовательский класс GUI может быть более требовательным, чем простой драйвер устройства; отсюда и недостаток этой метрики.

Существует несколько моделей оценки затрат, расписания и трудозатрат, которые используют SLOC в качестве входного параметра, включая широко используемую серию моделей Конструктивной модели затрат (COCOMO ) от Барри Боэма. и др., PRICE Systems и SEER-SEM Галората. Несмотря на то, что эти модели продемонстрировали хорошую предсказательную силу, они хороши ровно настолько, насколько хороши оценки (в частности, оценки SLOC), предоставленные им. Многие выступали за использование функциональных точек вместо SLOC в качестве меры функциональности, но, поскольку функциональные точки сильно коррелированы с SLOC (и не могут быть измерены автоматически), это не универсальная точка зрения.

Пример

По словам Винсента Мараиа, значения SLOC для различных операционных систем в линейке продуктов Microsoft Windows NT следующие:

ГодОперационная системаSLOC (млн)

1993	Windows NT 3.1	4–5
1994	Windows NT 3.5	7–8
1996	Windows NT 4.0	11–12
2000	Windows 2000	более 29
2001	Windows XP	45
2003	Windows Server 2003	50

Дэвид А. Уилер изучил Red Hat дистрибутив операционной системы Linux и сообщил, что Red Hat Linux версии 7.1 (выпущенной в апреле 2001 г.) содержит более 30 миллионов физических SLOC. Он также экстраполировал, что, если бы он был разработан обычными собственными средствами, он потребовал бы около 8000 человеко-лет усилий и стоил бы более 1 миллиарда долларов (в долларах США 2000 года).

Позднее аналогичное исследование было проведено для Debian GNU / Linux версии 2.2 (также известного как «Potato»); эта операционная система была первоначально выпущена в августе 2000 года. Это исследование показало, что Debian GNU / Linux 2.2 включает более 55 миллионов SLOC, и, если бы разработка производилась обычным закрытым способом, потребовалось бы 14 005 человеко-лет и 1,9 миллиарда долларов США на разработку. Более поздние прогоны использованных инструментов сообщают, что в следующем выпуске Debian было 104 миллиона SLOC, а по состоянию на 2005 год последний выпуск будет включать более 213 миллионов SLOC.

ГодОперационная системаSLOC (млн)

2000	Debian 2.2	55–59
2002	Debian 3.0	104
2005	Debian 3.1	215
2007	Debian 4.0	283
2009	Debian 5.0	324
2012	Debian 7.0	419
2009	OpenSolaris	9.7
FreeBSD	8.8
2005	Mac OS X 10.4	86
1991	ядро ​​Linux 0,01	0,010239
2001	Linux ядро 2.4.2	2.4
2003	ядро ​​Linux 2.6.0	5.2
2009	ядро ​​Linux 2.6. 29	11.0
2009	ядро ​​Linux 2.6.32	12.6
2010	ядро ​​Linux 2.6.35	13,5
2012	Ядро Linux 3,6	15,9
2015-06-30	Ядро Linux до 4.2	20,2

Утилита

Преимущества

1. Возможности для автоматизации подсчета: поскольку строка кода является физическим объектом, ручные подсчеты можно легко исключить, автоматизируя процесс подсчета. Для подсчета LOC в программе могут быть разработаны небольшие утилиты. Однако утилита подсчета логического кода, разработанная для конкретного языка, не может использоваться для других языков из-за синтаксических и структурных различий между языками. Однако были созданы физические счетчики LOC, которые учитывают десятки языков.
2. Интуитивная метрика: строка кода служит интуитивной метрикой для измерения размера программного обеспечения, потому что ее можно увидеть, и эффект от нее можно визуализировать. Функциональные точки считаются более объективной метрикой, которую нельзя представить как физическую сущность, она существует только в логическом пространстве. Таким образом, LOC пригодится программистам с низким уровнем опыта, чтобы выразить размер программного обеспечения.
3. Повсеместная мера: Меры LOC используются с первых дней появления программного обеспечения. Таким образом, можно утверждать, что доступно больше данных LOC, чем любой другой показатель размера.

Недостатки

1. Отсутствие подотчетности: измерение строк кода страдает некоторыми фундаментальными проблемами. Некоторые думают, что бесполезно измерять продуктивность проекта, используя только результаты этапа кодирования, на который обычно приходится от 30% до 35% общих усилий.
2. Отсутствие согласованности с функциональностью: хотя эксперименты неоднократно подтверждали, что, хотя усилия сильно коррелируют с LOC, функциональность хуже коррелирует с LOC. То есть опытные разработчики могут разработать ту же функциональность с гораздо меньшим количеством кода, поэтому одна программа с меньшим LOC может демонстрировать большую функциональность, чем другая аналогичная программа. В частности, LOC является плохим показателем производительности отдельных людей, потому что разработчик, который разрабатывает только несколько строк, может быть более продуктивным, чем разработчик, создающий больше строк кода — даже больше: некоторый хороший рефакторинг, такой как «метод извлечения», чтобы избавиться от избыточный код и поддержание его в чистоте в основном уменьшит количество строк кода.
3. Неблагоприятное влияние на оценку: из-за факта, представленного в пункте 1, оценки, основанные на строках кода, могут отрицательно сказаться на неверно, по всей вероятности.
4. Опыт разработчика: реализация конкретной логики зависит от уровня опыта разработчика. Следовательно, количество строк кода отличается от человека к человеку. Опытный разработчик может реализовать определенные функции в меньшем количестве строк кода, чем другой разработчик с относительно меньшим опытом, хотя они используют тот же язык.
5. Разница в языках: рассмотрим два приложения, которые предоставляют одинаковые функции (экраны, отчеты, базы данных). Одно из приложений написано на C ++, а другое — на таком языке, как COBOL. Количество функциональных точек будет точно таким же, но аспекты приложения будут другими. Строки кода, необходимые для разработки приложения, определенно не будут такими же. Как следствие, количество усилий, необходимых для разработки приложения, будет другим (часов на функциональную точку). В отличие от строк кода, количество функциональных точек останется постоянным.
6. Появление инструментов GUI : с появлением языков программирования и инструментов на основе GUI, таких как Visual Basic, программисты могут писать относительно небольшой код и достигать высоких уровней функциональности. Например, вместо написания программы для создания окна и рисования кнопки пользователь с графическим интерфейсом пользователя может использовать перетаскивание и другие операции с мышью для размещения компонентов в рабочей области. Код, который автоматически генерируется инструментом GUI, обычно не учитывается при использовании методов измерения LOC. Это приводит к различиям между языками; та же задача, которая может быть выполнена в одной строке кода (или вообще без кода) на одном языке, может потребовать нескольких строк кода на другом.
7. Проблемы с несколькими языками: в сегодняшнем сценарии программного обеспечения программное обеспечение часто разрабатывается более чем на одном языке. Очень часто используется несколько языков в зависимости от сложности и требований. Отслеживание и отчетность о производительности и количестве дефектов представляет собой серьезную проблему в этом случае, поскольку дефекты не могут быть отнесены к конкретному языку после интеграции системы. Функциональная точка оказывается лучшим средством измерения размера в этом случае.
8. Отсутствие стандартов подсчета: нет стандартного определения того, что такое строка кода. Учитываются ли комментарии? Включены ли декларации данных? Что произойдет, если оператор занимает несколько строк? — Это вопросы, которые часто возникают. Хотя такие организации, как SEI и IEEE, опубликовали некоторые руководящие принципы в попытке стандартизировать подсчет, их трудно применить на практике, особенно в связи с тем, что каждый год появляются все новые и новые языки.
9. Психология: программист, чей производительность измеряется в строках кода, будет стимул писать излишне подробный код. Чем больше руководство сосредотачивается на строках кода, тем больше у программиста стимула расширять свой код ненужной сложностью. Это нежелательно, поскольку повышенная сложность может привести к увеличению затрат на обслуживание и увеличению усилий, необходимых для исправления ошибок.

В документальном фильме PBS Triumph of the Nerds руководитель Microsoft Стив Баллмер раскритиковал использование подсчета строк кода:

В IBM есть религия в программном обеспечении, которая гласит, что нужно считать K-LOC, а K-LOC — это тысяча строк кода. Насколько велик проект? О, это своего рода проект 10K-LOC. Это 20K-LOCer. А это 50K-LOC.

И IBM хотела стать религией в отношении того, как нам платят. Сколько денег мы заработали на OS / 2, сколько они сделали. Сколько K-LOC вы сделали? И мы продолжали убеждать их — эй, если у нас есть — у разработчика есть хорошая идея, и он может что-то сделать в 4K-LOC вместо 20K-LOC, должны ли мы зарабатывать меньше денег? Потому что он сделал что-то меньшее и быстрое, без K-LOC. K-LOCs, K-LOCs, это методология.

Ух! В любом случае, от этой мысли у меня всегда морщится спина.

Связанные термины

• KLOC : 1000 строк кода

• KDLOC: 1000 доставленных строк кода
• KSLOC: 1000 строк исходного кода

См. Также

• Оценка усилий по разработке программного обеспечения
• Оценка (управление проектом)
• Оценка затрат на разработку программного обеспечения

Примечания

1. ^Возможно, включая весь пакет iLife, а не только операционную систему и обычно связанные приложения.

Ссылки

Дополнительная литература

• Li, Luo; Хербслеб, Джим; Шоу, Мэри (май 2005 г.). Прогнозирование частоты дефектов на местах с использованием комбинированного подхода, основанного на времени и показателях, на примере OpenBSD (CMU-ISRI-05-125). Университет Карнеги-Меллона.
• Макгроу, Гэри (март – апрель 2003 г.). «С нуля: семинар по безопасности программного обеспечения DIMACS». Безопасность и конфиденциальность IEEE. 1 (2): 59–66. doi : 10.1109 / MSECP.2003.1193213.
• Парк, Роберт Э.; и другие. «Измерение размера программного обеспечения: основа для подсчета исходных утверждений». Технический отчет CMU / SEI-92-TR-20.

Внешние ссылки

• Определения практических строк исходного кода Стандартные метрики ресурсов (RSM) определяют «эффективные строки кода» как метрику реалистичного кода, независимую от стиль программирования.
• Эффективные строки кода метрики eLOC для популярного программного обеспечения с открытым исходным кодом Ядро Linux 2.6.17, Firefox, Apache HTTPD, MySQL, PHP с использованием RSM.
• Уиллер, Дэвид А. «SLOCCount «. Проверено 12 августа 2003 г.
• Уиллер, Дэвид А. (июнь 2001 г.). «Подсчет исходных строк кода (SLOC)». Проверено 12 августа 2003 г.
• Таненбаум, Эндрю С. Современные операционные системы (2-е изд.). Прентис Холл. ISBN 0-13-092641-8.
• Говард Дахда (2007-01-24). «Таненбаум излагает свое видение универсальной ОС». Архивировано с оригинального 27 января 2007 года. Проверено 29 января 2007.
• C. М. Лотт: Инструменты сбора показателей для исходного кода C и C ++
• Folklore.org: Истории Macintosh: -2000 строк кода

Источник: alphapedia.ru

Размер программы в строках

Перенесено в Прочее из С++.

Большой проект определяется не количеством кода, а размером решаемой проблемы

Re: Сколько сток кода в «большом» проекте?

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.09.02 15:07
Оценка:

Здравствуйте MaximE, Вы писали:

ME>Часто приходиться слышать «большой проект». Сколько должно быть в нем строк кода?

Величина проекта определяется не количеством строк кода. Хотя конечно крупный проект в сфере программирования вряд ли будет содержать менее 500К исходников.

Re[2]: Сколько сток кода в «большом» проекте?

От:	MaximE
Дата:	15.09.02 15:07
Оценка:

Здравствуйте Хитрик Денис, Вы писали:

ХД>Перенесено в Прочее из С++.

ХД>Большой проект определяется не количеством кода, а размером решаемой проблемы

А сколько строк должно быть в решении большой проблемы?

Re[3]: Сколько сток кода в «большом» проекте?

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.09.02 15:31
Оценка:

Здравствуйте MaximE, Вы писали:

ME>А сколько строк должно быть в решении большой проблемы?

Вот ты упорный какой. К примеру в Янусе на данный момент 270К исходников, 8 тысяч строк. Это маленький проект.

Далее, возьмем Magic Library. Исходников 940К, 26 тыс. строк. Это средний проект.

В большом будет соответственно больше.

Да, это приведено для C#, на других языках будет несколько иначе. На джаве немножко побольше. На С++ еще побольше. На Дельфи еще немножко побольше. Ну и так далее. Не в объеме исходников счастье.

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

Re[4]: Сколько сток кода в «большом» проекте?

От:	MaximE
Дата:	15.09.02 18:46
Оценка:

Здравствуйте AndrewVK, Вы писали:

AVK>Вот ты упорный какой. К примеру в Янусе на данный момент 270К исходников, 8 тысяч строк. Это маленький проект.

AVK>Далее, возьмем Magic Library. Исходников 940К, 26 тыс. строк. Это средний проект.

AVK>В большом будет соответственно больше.

Просто однажды встретил такую фразу «работа над большим проектом (250 тыс. строк)». И подумал — если грамотно спроектировано, то не так уж и много .

Re[5]: Сколько сток кода в «большом» проекте?

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.09.02 19:13
Оценка:

Здравствуйте MaximE, Вы писали:

ME>Просто однажды встретил такую фразу «работа над большим проектом (250 тыс. строк)». И подумал — если грамотно спроектировано, то не так уж и много .

Ну 250 тыс. строк вполне могут быть большим проектом. А могут и не быть.

И если грамотно спроектировано то это много, очень много.
Пример из другой области — 50-70 млн. транзисторов в микропроцессоре это очень много, а вот для DRAM 1-2 млрд. транзисторов на чипе это не предел. Так и здесь — если грамотно спроектировать то очень много писать ручного кода не придеться. В одном проекте на джаве автоматически генерилось около 120 тыс строк исходников, при этом генератор был что то около 500 строк, а исходные данные (xml) — около 10 тыс строк, которые в свою очередь тоже генерились автоматом на основе данных из дизайнера, в котором ручками было написано тысяч 5-6 строк ручного кода. А ведь можно было бы эти 120 тысяч ручками писать, а можно из них и 200 тысяч сделать если формочки в дизайнере рисовать и репорты делать в традиционных репортерах.

Re[6]: Сколько сток кода в «большом» проекте?

От:	MaximE
Дата:	15.09.02 19:22
Оценка:

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте MaximE, Вы писали:

ME>>Просто однажды встретил такую фразу «работа над большим проектом (250 тыс. строк)». И подумал — если грамотно спроектировано, то не так уж и много .

AVK>Ну 250 тыс. строк вполне могут быть большим проектом. А могут и не быть.

AVK>И если грамотно спроектировано то это много, очень много.
AVK>Пример из другой области — 50-70 млн. транзисторов в микропроцессоре это очень много, а вот для DRAM 1-2 млрд. транзисторов на чипе это не предел.

Да, все правильно. Я имею ввиду, что если грамотно спроектировано (в духе ООП и паттернов), то разобраться одному челу вполне реально.

Re[2]: Сколько сток кода в «большом» проекте?

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	16.09.02 05:57
Оценка:

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте MaximE, Вы писали:

ME>>Часто приходиться слышать «большой проект». Сколько должно быть в нем строк кода?

AVK>Величина проекта определяется не количеством строк кода. Хотя конечно крупный проект в сфере программирования вряд ли будет содержать менее 500К исходников.

А помоему на этой цифре заканчивается маленький проект и начинается средний.

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

Re[3]: Сколько строк кода в «большом» проекте?

От:	Flamer	http://users.livejournal.com/_flamer_/
Дата:	16.09.02 06:12
Оценка:

Здравствуйте Anatolix, Вы писали:

A>Здравствуйте AndrewVK, Вы писали:

AVK>>Здравствуйте MaximE, Вы писали:

ME>>>Часто приходиться слышать «большой проект». Сколько должно быть в нем строк кода?

AVK>>Величина проекта определяется не количеством строк кода. Хотя конечно крупный проект в сфере программирования вряд ли будет содержать менее 500К исходников.

A>А помоему на этой цифре заканчивается маленький проект и начинается средний.

Мда. Ну неверно это — считать величину проекта как в строках кода, так и в объеме исходников на диске!

1. Объем исходников на диске — а какая файловая система используется, а? ИМХО размер будет варьировать.

2. В строках кода? А если я пишу так:

int i; i=0; for(;;) < i++; if(i>=10) < break; > DoSomeJob(); >

Так этот кусок можно переписать в одну строку:

for(int i=0;i<10;i++) DoSomeJob();

Что теперь? Введем поправочный коэффициент качественности кода? Или как?

Соглашусь с Денисом Хитриком, который сказал выше (цитирую):

Большой проект определяется не количеством кода, а размером решаемой проблемы
Re[4]: Сколько строк кода в «большом» проекте?

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	16.09.02 06:35
Оценка:

Здравствуйте Flamer, Вы писали:

F>1. Объем исходников на диске — а какая файловая система используется, а? ИМХО
размер будет варьировать.

Вранье. Мы же не физический размер смотрим а размер файлов.
А 100K это и в африке 100K. Не надо просто file slack дополнительно считать.

F>

F>Большой проект определяется не количеством кода, а размером решаемой проблемы F>

Это слишком субъективная вещь, если мы считаем размер проблемы то в чем считать? Получается что для одних проект большой, а для других в то же время маленький.

Для того чтобы такого не было люди вводят терминологию и договариваются называть такой-то проект большим а такой-то маленьким. Где то я видел даже табличку на эту тему

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

Re[5]: Сколько строк кода в «большом» проекте?

От:	Sinclair	https://github.com/evilguest/
Дата:	16.09.02 07:22
Оценка:

Здравствуйте Anatolix, Вы писали:

A>Это слишком субъективная вещь, если мы считаем размер проблемы то в чем считать? Получается что для одних проект большой, а для других в то же время маленький.

A>Для того чтобы такого не было люди вводят терминологию и договариваются называть такой-то проект большим а такой-то маленьким. Где то я видел даже табличку на эту тему

Наиболее объективный критерий сложности проблемы из известных мне на данный момент — количество use-case. Естественно, это предполагает достаточно качественную декомпозицию на use-case, иначе получится то же, что и со строками кода. Тем не менее, этот показатель не зависит хотя бы от используемого языка программирования.

Альтернативой этому подходу, а точнее его дополнением, может служить количество классов/методов в архитектурной модели.

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

Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Сколько сток кода в «большом» проекте?

От:	Nikita Dolgov	http://nikitadolgov.narod.ru/
Дата:	16.09.02 09:26
Оценка:

Насколько я представляю, размер проекта определяется количеством не кода, а девелоперов (+ сроком разработки для определенности).

Old C programmers never die. They’re just cast into void.
Re[2]: Сколько сток кода в «большом» проекте?

От:	Аноним
Дата:	16.09.02 10:30
Оценка:

Здравствуйте Nikita Dolgov, Вы писали:

ND>Насколько я представляю, размер проекта определяется количеством не кода, а девелоперов (+ сроком разработки для определенности).

Припоминается фильм «Обыкновенное чудо» (кажется он): «- А неделю? — Ну, барин, тут без помощника не обойтись!»

Re[3]: Сколько сток кода в «большом» проекте?

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	16.09.02 16:47
Оценка:

Здравствуйте Anatolix, Вы писали:

AVK>>Величина проекта определяется не количеством строк кода. Хотя конечно крупный проект в сфере программирования вряд ли будет содержать менее 500К исходников.

A>А помоему на этой цифре заканчивается маленький проект и начинается средний.

Еще раз повторюсь — это минимальная цифра. Какой проект может быть большим при таком объеме кода? Ну например веб-сайт. Там основное это не код, его может быть еще меньше, а вот проект при этом может быть очень большим.

Re[4]: Сколько строк кода в «большом» проекте?

От:	MaximE
Дата:	16.09.02 19:32
Оценка:

Здравствуйте Flamer, Вы писали:

F>2. В строках кода? А если я пишу так:

F>Что теперь? Введем поправочный коэффициент качественности кода? Или как?

Управление разработкой ПО

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

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

Например, измерение времени, проводимого служащим на рабочем месте в качестве меры интенсивности его труда и вклада в процветание организации, не вполне адекватно: человек может занять себя на работе и другими вещами. Соответственно, введение административных мер по поощрению «много работающих» и наказанию «мало работающих» только на основании таких измерений может иметь «неожиданные» последствия — показатели «хорошей работы» будут расти, а реальная работа не станет выполняться быстрее или лучше.

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

Одна из первых идей, которая приходит в голову при оценке трудоемкости и времени разработки ПО, — оценить сначала сложность или размер программы, а потом умножить полученную оценку на производительность исполнителей. Похоже, однако, что природа разработки программ такова, что ее трудоемкость слабо связана с размерами результата (например, приводимая ниже модель COCOMO , выражает эту связь в достаточно сложном виде). Часто оказывается, что оценить сразу трудоемкость по аналогии с имеющимся примерами можно точнее, чем оценив сначала размер. Тем не менее, метрики размера и сложности ПО часто используются для оценки трудоемкости разработки.

Самой простой и наиболее широко используемой метрикой является размер программы в строках ее кода (lines of code, LOC). Ее основное достоинство — понятность и простота вычисления. Ее недостатки — не очень хорошая адекватность в качестве метрики трудоемкости разработки программы, зависимость от используемых языков и технологий и трудность предварительной оценки размера ПО. Практика показывает, что качественная программа часто имеет несколько меньший объем, чем программа с теми же функциями, но менее удобная для сопровождения или совершающая больше ошибок. В то же время, на разработку первой программы может уйти в два-три раза больше усилий.

С другой стороны, производительность разных разработчиков очень сильно отличается, но обычно руководители групп и организаций примерно представляют себе среднее значение по группе или организации. В терминах строк кода она обычно лежит в пределах от 5000 до 50000 строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.

Более хитрой метрикой сложности программы являются функциональные точки (functional points, FP) [4,5]. Количество функциональных точек в программной системе вычисляется примерно следующим образом.

увеличить изображение
Рис. 16.4. Схема рассмотрения системы при оценке ее сложности в функциональных точках

• Выделяются обращения к системе с целью ввода данных, с целью получения каких-то уже имеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся в систему, перерабатываются и выдаются какие-то результаты. Дополнительно определяются группы взаимосвязанных данных (называемые файлами) внутри системы и аналогичные группы, лежащие вне ее, но используемые в ее работе.
• Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале «низкая»–»средняя»–»высокая»).
• Итоговая сложность программной системы вычисляется как сумма сложностей выявленных отдельных представителей этих пяти категорий. Сложность ввода, вывода, запроса или группы данных вычисляется умножением оценки сложности составляющих данных на весовой коэффициент, который можно найти в стандартах [4,5] или определить на основе собственного опыта. Обычно весовые коэффициенты групп данных больше, чем коэффициенты для вводов, выводов или запросов.

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

Другие исходные элементы используются при подсчете так называемых объектных точек [6]. В этом случае рассматриваются экраны, формы и отчеты, присутствующие в системе, классы, а также модули, написанные на необъектных языках. Сложность каждого из таких элементов оценивается отдельно, после чего их сложности складываются, тоже с разными весовыми коэффициентами для разных категорий элементов.

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

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II ( Constructive Cost Model II, COCOMO II ) [7,8,9].

В рамках этой модели оценки трудоемкости проекта и времени, требующегося на его выполнение, определяются тремя разными способами на разных этапах проекта:

• На самых ранних этапах, когда примерно известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model). В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле

Effort = A*Size.

• Size представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности.
• Коэффициент A учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов и оцениваемую числом от 4 до 50.

A = (100 – (процент переиспользования))/производительность.
Effort = A*(Size)B*ME + (трудозатраты на автоматически генерируемый код)
Для времени (в месяцах):
Time = T*EffortS (0.28+0.2*(B-1.01))*Sced.

• Коэффициент A считается равным 2,45, а T считается равным 3,67.
• Size — оценка размера ПО в тысячах строк кода.
• B — фактор процесса разработки, который вычисляется по формуле

где факторы Wi принимают значения от 0 до 5:

• W1 — предсказуемость проекта для данной организации, от полностью знакомого (0) до совсем непредсказуемого (5);
• W2 — гибкость процесса разработки, от полностью определяемого командой при выполнении общих целей проекта (0) до полностью фиксированного и строгого (5);
• W3 — степень удаления рисков, от полной (0) до небольшой (5), оставляющей около 80% рисков;
• W4 — сплоченность команды проекта , от безукоризненного взаимодействия (0) до больших трудностей при взаимодействии (5);
• W5 — зрелость процессов в организации, от 0 до 5 в виде взвешенного количества положительных ответов на вопросы о поддержке ключевых областей процесса в модели CMM (лекция 2).

• возможности персонала;
• надежность и сложность продукта;
• требуемый уровень повторного использования;
• сложность платформы;
• опытность персонала;
• использование инструментов;
• плотность графика проекта.

Effort= A*(Kreq*Size)B*MP + (трудозатраты на автоматически генерируемый код)
Для времени — та же формула, что и в предыдущей модели (в месяцах):
Time = T*EffortS(0.28+0.2*(B-1.01))*Sced.

• Size = (размер нового кода в тыс. строк) + RSize , где

RSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 * (AA + 0,4*DM + 0,3*CM + 0,3*IM + SU)/100

• AT — процент автоматически генерируемого кода;
• AA — фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8;
• DM — процент модифицируемых для переиспользования проектных моделей;
• CM — процент модифицируемого для переиспользования кода;
• IM — процент затрат на интеграцию и тестирование повторно используемых компонентов;
• SU — фактор понятности переиспользуемого кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0 , если CM = DM = 0 .

• надежность продукта;
• сложность продукта;
• размер базы данных разрабатываемого приложения;
• требуемый уровень повторного использования;
• требуемый уровень документированности;
• уровень производительности по времени;
• уровень требований к занимаемой оперативной памяти;
• изменчивость платформы;
• возможности аналитика проекта;
• возможности программистов;
• опыт работы команды в данной предметной области;
• опыт работы команды с используемыми платформами;
• опыт работы команды с используемыми языками и инструментами;
• уровень текучести персонала в команде ;
• возможности используемых инструментов;
• возможности общения между членами команды ;
• фактор сжатия графика проекта.

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

Источник: intuit.ru