Что такое sloc

SLOC — оценка (Source Lines Of Code)

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

· количество «физических» SLOC (используемые аббревиатуры: LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на число пустых строк, как правило, вводится ограничение – учитывается их количество, которое не превышает 25% общего числа строк в измеряемом блоке кода);

· количество «логических» SLOC (используемые аббревиатуры: LSI, DSI, KDSI, где SI – Source Instructions) – определяется как число команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещения на одной строке нескольких команд, количество «логических» SLOC будет соответствовать числу «физических» за исключением пустых строк и строк комментариев. Если же язык программирования поддерживает размещение нескольких команд на одной строке, то одна «физическая» строка должна быть учтена как несколько «логических», если она содержит более одной команды языка.

Литера «D» (Delivered) означает «поставленный» код, т. е. только вошедший в законченный программный продукт. Очень часто возникает необходимость учитывать не только поставленный код, но и вспомогательный или промежуточный, который не входит в законченный продукт, но нужен для реализации проекта и требует определенных затрат труда.

Что касается вычисления показателя SLOC, то здесь следует отметить, что не существует единственного общепризнанного подхода, приемлемого для различных языков программирования и ориентированного на универсальное применение. Чаще всего SLOC определяется как общее число строк кода за исключением пустых строк и комментариев. В большинстве случаев подсчитывается именно число «физических» SLOC, и наличие нескольких операторов на одной строке не учитывается. Также отметим, что если в контексте SLOC конкретный язык программирования не называется, это обычно означает, что речь идет о величине, выраженной в базовых единицах, – количестве строк кода языка Basic Assembler. Для сопоставления значений показателя для различных языков программирования применяются специальные таблицы преобразования.

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

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

· оценка показателя SLOC «снизу-вверх» экспертным методом. Этой методикой предусмотрено разбиение проекта на иерархическую структуру задач (Work Breakdown Structure, WBS), на основании которых производится экспертная оценка показателя, в итоге суммируемая для всего проекта. Как правило, экспертами предоставляются три оценки (наиболее вероятная, максимальная и минимальная), а далее они усредняются с помощью бета — распределения (рассчитывается сумма минимальной, максимальной и четырехкратной наиболее вероятной оценок, которая затем делится на шесть).

Для метрики SLOC имеется много производных, призванных получить отдельные показатели проекта. Основными среди них являются:

· число пустых строк (Blank Lines Of Code, BLOC);

· число строк, содержащих комментарии (Comment Lines Of Code, CLOC);

· число строк, содержащих исходный код и комментарии (Lines with Both Code and Comments, C&SLOC);

· число строк, содержащих декларативный исходный код;

· число строк, содержащих императивный исходный код;

· процент комментариев (число строк комментариев, умноженное на 100 и деленное на число строк кода);

· среднее число строк для функций (методов);

· среднее число строк, содержащих исходный код для функций (методов);

· среднее число строк для модулей;

· среднее число строк для классов.

Также наряду со SLOC применяются другие показатели, отражающие количественную оценку отдельных составляющих проекта: число модулей, функций / методов, классов, страниц документации и пр. Однако помимо метрик, подсчитывающих число элементов проекта, к метрикам размера следует отнести также функциональные точки (Function Points, FP), их производные и разновидности, вычисляемые на базе не исходного кода, а пользовательских требований, спецификаций, описаний прецедентов (например, точки прецедентов, Use Case Points, UCP) и пр. В большинстве случаев главное предназначение этой группы метрик, независимо от способа их вычисления, состоит в том, чтобы оценить объем работ по проекту, и, соответственно, быть основой для таких показателей, как стоимость и длительность его реализации.

Потенциальные недостатки SLOC, на которые нацелена критика:

· некрасиво и неправильно сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности. Менеджер может назначить наиболее талантливых программистов на сложнейший участок работы; это означает, что разработка этого участка займёт наибольшее время и породит наибольшее количество ошибок, из-за сложности задачи. Не зная об этих трудностях, другой менеджер по полученным показателям может решить, что программист сделал свою работу плохо.

· Метрика не учитывает опыт сотрудников и их другие качества

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

· Неточность: нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.

И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы.

Перевод «SLOC» на русский

Автоматический перевод » SLOC » в русский

Glosbe Translate
Google Translate

«SLOC» в словаре английский — русский

В настоящее время у нас нет переводов для SLOC в словаре, может быть, вы можете добавить его? Обязательно проверьте автоматический перевод, память переводов или косвенные переводы.

Компьютерные переводы

Эти переводы были «предположены» при помощи алгоритма и не подтверждены человеком. Будьте осторожны.

средства противоминной защиты (@1 : fr: LCM )

Переводы «SLOC» на русский в контексте, память переводов

Склонение Основа
President, Sea Lanes of Communication (SLOC) Study Group, Korea
Председатель, Исследовательская группа по морским коммуникациям, Корея

The plan was approved by county officials October 14, 1996, with Provo paying $2 million, Utah County $2 million, SLOC $3 million, and Seven Peaks donating land for the arena and parking spaces.

14 октября чиновники Юты одобрили этот план, по нему выходило, что власти города и округа выделяют по 2 миллиона долларов, организационный комитет — 3 миллиона, а аквапарк — землю для будущей арены и парковочных мест.

WikiMatrix
Before the queue could be used, the variables rloc and sloc had to be set to zero.

Прежде чем класс queue можно будет использовать, переменным rloc и sloc нужно присвоить нулевые значения.

Literature

SLOC loaned $7 million to the city for construction costs, and would rent the arena from the city during the Olympic Games.

SLOC выделил 7 млн долларов на строительные расходы и планировал арендовать сооружение на время Олимпийских игр.

WikiMatrix

Therefore, vital sea lines of communications (SLOCS) around the southern Eurasian rimland must be protected.

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

Literature

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program’s source code.

Количество строк кода (англ. Source Lines of Code — SLOC) — это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода.

WikiMatrix

In July 1995, only a month after winning the 2002 Winter Olympic bid, the Salt Lake Organizing Committee (SLOC) accepted a proposal from West Valley City to build a new ice hockey facility in their city.

В июле 1995 года, всего через месяц после того, как Солт-Лейк-Сити выиграл заявку на проведение зимних Олимпийских игр 2002 года, Salt Lake Organizing Committee одобрил предложение Вест-Вэлли-Сити о строительстве нового хоккейного стадиона в городе.

WikiMatrix
This means that Q1 and Q2 will each have their own, separate copies of q, sloc, and rloc.

Это означает, что каждый из объектов Q1 и Q2 будет иметь собственные отдельные копии переменных q, sloc и rloc.

SLOC

SLOC, его ещё где-то используют? Я вот на днях за 8 часов написал аж целых 100 строчек кода, которые работали ещё 2 часа и сделали работу, которую 3 человека пытались сделать с января, написав при этом 10k строк быдлокода. Интересно послушать адептов этой методики, если они ещё не вымерли. А до этого целый день думал, как написать этот код.

peregrine ★★★★★
04.06.19 14:59:17 MSK

А до этого целый день думал, как написать этот код.

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

imul ★★★★★
( 04.06.19 15:08:14 MSK )

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

theNamelessOne ★★★★★
( 04.06.19 15:09:48 MSK )

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

Harald ★★★★★
( 04.06.19 15:13:44 MSK )
Ответ на: комментарий от Harald 04.06.19 15:13:44 MSK

Прикол в том что алгоритм надо было придумать.

peregrine ★★★★★
( 04.06.19 15:14:38 MSK ) автор топика
Ответ на: комментарий от Harald 04.06.19 15:13:44 MSK

И этот минимум будет актуальным только в вакууме. Всё зависит от перспективы и скилов конкретного разраба. Где средний разраб будет фигачить тысячу строк кода, его, уже сталкивавшийся с подобной задачей, коллега возьмёт какой-то малоизвестный готовый инструмент, либо остроумное решение, и уложится в 100 строк.

~~WitcherGeralt~~ ★★
( 04.06.19 15:20:59 MSK )
Ответ на: комментарий от peregrine 04.06.19 15:14:38 MSK

Их уже уволили, тебя повысили?

~~WitcherGeralt~~ ★★
( 04.06.19 15:22:19 MSK )
Ответ на: комментарий от WitcherGeralt 04.06.19 15:22:19 MSK

Двоих уволили, при том раньше даже, джуна перевели на другой проект.

peregrine ★★★★★
( 04.06.19 15:33:00 MSK ) автор топика
Последнее исправление: peregrine 04.06.19 15:33:20 MSK (всего исправлений: 1)

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

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

ixrws ★★★
( 04.06.19 15:35:15 MSK )
Ответ на: комментарий от Harald 04.06.19 15:13:44 MSK

Однострочники это олдскул, разработчики могущие это теперь большая редкость. Куда чаще в проектах встречаются сотни файлов с 2-100 строк. В некотором смысле это ещё хуже однострочников, потому что парсить что хотел автор ещё дольше по времени.

ixrws ★★★
( 04.06.19 15:37:02 MSK )
Ответ на: комментарий от ixrws 04.06.19 15:37:02 MSK

Куда чаще в проектах встречаются сотни файлов с 2-100 строк

Если структура проекта адекватная, то это скорее норма.

~~WitcherGeralt~~ ★★
( 04.06.19 15:44:18 MSK )
Ответ на: комментарий от ixrws 04.06.19 15:37:02 MSK

Впрочем, от языка зависит.

~~WitcherGeralt~~ ★★
( 04.06.19 15:44:45 MSK )

SLOC, его ещё где-то используют? Интересно послушать адептов этой методики, если они ещё не вымерли.

Вот тут (в совокупности ответов) достаточно подробно разжевано, что такое SLOC, и как и для чего его можно использовать: https://stackoverflow.com/questions/3769716/how-bad-is-sloc-source-lines-of-c.

Переводить/копипастить сюда не вижу смысла. Прошу прощения у Ъ.

Manhunt ★★★★★
( 04.06.19 15:48:52 MSK )
Последнее исправление: Manhunt 04.06.19 15:53:00 MSK (всего исправлений: 2)

Ответ на: комментарий от WitcherGeralt 04.06.19 15:44:18 MSK

Ну если, то да. Однако если бы адекватная, то и проблемы нет.

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

ixrws ★★★
( 04.06.19 16:11:06 MSK )
Ответ на: комментарий от theNamelessOne 04.06.19 15:09:48 MSK

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

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

andreyu ★★★★★
( 04.06.19 17:48:24 MSK )

8 часов написал аж целых 100 А до этого целый день думал, как написать этот код

= 100/2 = 50 строк в человекодень.

3 человека пытались сделать с января, написав при этом 10k

= 10000/3человеков/14*5 дней = 37 строк в человекодень.

Чрезвычайно точно(там степенной показатель от 1.0 до 1.2).

DonkeyHot ★★★★★
( 05.06.19 07:01:29 MSK )
Ответ на: комментарий от andreyu 04.06.19 17:48:24 MSK

ощущение, что им платят именно за количество строк

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

DonkeyHot ★★★★★
( 05.06.19 08:16:45 MSK )
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

ДРУГИЕ МЕТРИКИ

В этом разделе описывается более общий взгляд на выполнение проекта CCPDS-R: эволюция размера ПО, совершенствование процессов создания подсистем, диаграмма выполнения SCO, а также продуктивность различных CSCI и факторы качества.

D.8.1 Эволюция размера ПО.

Размеры Подсистемы общего назначения и отдельных CSCI отслеживались ежемесячно и извлекались непосредственно из файлов с метриками. Объем кода существенно вырос: по сравнению с цифрой, указанной в контракте (150 ООО SLOC), объем готового продукта составил 355 ООО SLOC без сколь-нибудь существенного увеличения бюджета разработки ПО. Существуют два обоснования такого роста объема кода:.

Способ подсчета количества исходных строк был изменен на восьмом месяце для того, чтобы улучшить баланс при оценке трудозатрат на разработку и не противоречить методу подсчета, принятому в модели Ada СОСОМО.

Были разработаны автоматические инструменты для генерации кода, которые выдавали «многословный» исходный код при меньшем количестве входных строк, написанных людьми. Эти инструменты использовались для прямой генерации форматов вывода, обработки подтверждения сообщений и для функций учета взаимодействий. Сами инструменты состояли из 14 ООО SLOC, и для них потребовалось 20 ООО строк в файлах с входными данными. Выход от этих инструментов составил приблизительно 200 ООО SLOC рабочего ПО. Таким образом, инструменты для генерации кода дали пятикратную отдачу от вложенного в них труда.

Общий рост объема кода приведен в таблице D.10.
Таблица D.10.
Размеры CSCI Подсистемы общего назначения
Указано в контракте
Поставлено
Создано автоматически

Главной причиной увеличения числа SLOC явилось изменение правил подсчета. При заключении контракта использовался простой подсчет символов «точка с запятой». Этот подход был перенесен в процедуру подсчета; она была реализована в виде простого инструмента, который использовался всем персоналом проекта:.

■ В рамках той части, которая определялась языком Ada, каждый символ «возврат каретки» считался за одну SLOC. Четыре стандарта кодирования обеспечивали непротиворечивость подсчета строк:.

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

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

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

Инициализация сложных объектов (таких, как записи и массивы) располагается по одному компоненту на каждой строке. Каждое из этих присвоений представляется специально созданным выражением; служебное слово «others» (прочие) обычно используется для стандартных присвоений.

■ Внутри подпрограмм, написанных на языке Ada, каждая точка с запятой принимается за одну SLOC. Общие описания считаются по одной строке на каждый общий параметр.

Такое определение более чувствительно к декларативной части проекта (спецификациям), чем к выполняемой части (телу). Оно вызвало множество жарких споров, тем не менее хорошо работает как внутри проекта, так и вне его. Не так важно иметь правильное определение; гораздо важнее, чтобы оно было непротиворечивым и адекватным.

Два компонента послужили причиной изменения определения SLOC. Во-первых, САПО-пакеты в СС содержали сетевые определения, в которые входили все определения процессов, задач, межпрограммных интерфейсов и соединений. В эти пакеты было включено множество определений записей, специально созданных перечислимых типов, а также инициализации полей записей и массивов в спецификациях. Исходный код для этих элементов содержал более 50 ООО символов «возврат каретки», но всего лишь несколько сотен точек с запятой. Поскольку работа над этими пакетами больше была похожа на работу, связанную с написанием 50 ООО SLOC, возникла необходимость в изменениях. Вторым компонентом с аналогичным обоснованием был компонент, содержащий типы глобальных сообщений системы. В этих пакетах содержалось около 300 различных типов записей, представляющих большую часть данных, которыми обменивались между собой САПО-объекты.

Из-за большого разнообразия категорий SLOC, разрабатывавшихся в рамках проекта CCPDS-R, был придуман метод нормализации различных категорий с тем, чтобы можно было правильно распределить бюджет и сравнить продуктивность. В результате появилось расширение метода, предлагаемого моделью СОСОМО для повторного использования; оно называлось эквивалентными строками исходного кода (ESLOC). По существу ESLOC преобразует стандартную для модели СОСОМО единицу измерения SLOC в нормализованную единицу измерения, которая подлежит сравнению на основании работы, затраченной на написание одной строки кода. Необходимость в новой единице возникла при попытке распределения бюджета и анализа продуктивности для случаев, представляющих собой смесь из вновь разработанного, повторно используемого и автоматически сгенерированного кода. Например, компонент размером 10 ООО SLOC, отвечающий за оформление вывода, который автоматически сгенерирован с помощью некоторого инструмента пЬсредством задания 1000-строчного сценария оформления вывода, не должен иметь такого же бюджета, как и вновь разработанный компонент объемом в 10 ООО строк. В таблице D.11 определяется перевод SLOC в ESLOC в проекте CCPDS-R.

Таблица D.11.
Факторы преобразования SL0C в ESL0C
Формат SL0C
Проектирование Новое = 40%
Реализация Новая = 20%
Тестирование Новое = 40%
Коммерческий
Повторно используемый
Автоматизированный
Входные данные для инструментов
При таких преобразованиях следует учитывать множество факторов:.

■ Готовые коммерческие компоненты не вносят никакого вклада при подсчете ESLOC. Включение таких компонентов учитывается с помощью количества вновь разрабатываемого ПО для реализации интерфейса с ними.

■ Новое ПО разрабатывается с нуля. Для его создания требуется полный объем работ по проектированию, реализации и тестированию, поэтому ESLOC имеет множитель 100%

■ Код повторно используемых компонентов, которые были разработаны ранее, может применяться в другом компоненте при внесении некоторых изменений. Существует множество способов оценки относительных затрат на повторное использование, и для каждого конкретного случая лучше всего подходит свой собственный. Тем не менее такое преобразование определяется по умолчанию простым эмпирическим правилом. Вообще говоря, повторно используемый компонент требует 50% работ по проектированию, 25% по реализации и 75% по тестированию. Приведение в соответствие с распределением 40/20/40 для нового ПО дает итоговое значение 55%.

■ Для автоматически генерируемых компонентов обычно требуется отдельная система учета исходных записей (формат входных данных для инструмента всегда меньше) как входных данных для инструмента, из которых в дальнейшем автоматически производятся конечные SLOC. Поскольку автоматически сгенерированный исходный код становится частью конечного продукта, он должен быть подвергнут исчерпывающему тестированию. А вот работа по проектированию и реализации равна нулю. Если инструмент, позволяющий автоматизировать создание исходного кода, должен быть разработан заново, его собственное число SLOC следует отнести к категории «новый». В результате получается значение фактора преобразования из SLOC в ESLOC, равное 40%.

■ Входные данные для различных инструментов могут принимать самые разнообразные формы. В рамках проекта CCPDS-R использовались входные файлы для определения архитектуры (длинные, но простые таблицы имен, атрибутов и связей), определения вывода (типы выводимых объектов, местоположение и атрибуты) и подтверждения сообщений. Форматы с более высоким уровнем абстракции преобразовывались с затратами 75% работ на проектирование (простые нотации высокого уровня), 50% работ на реализацию (многократно повторяющиеся синтаксис и семантика высокого уровня) и 25% работ на тестирование (которые сосредоточивались на тестировании сгенерированного, а не исходного кода). В результате значение фактора преобразования из SLOC в ESLOC равен 50%.

Важно, что разработка нескольких инструментов для создания кода уменьшила значение ESLOC для Подсистемы общего назначения на 78 000 строк (см. таблицу D.12). Показатель ESLOC анализировался с единственной целью — убедиться в том, что общее распределение рабочей силы и бюджета, по которому велись переговоры с каждым руководителем CSCI, было относительно справедливым. Оценки в ESLOC использовались в качестве входных данных для анализа моделирования затрат, учитывающего относительную сложность каждого CSCI и другие уточняющие факторы модели СОСОМО.

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

CCPDS-R, хороший пример того, почему использование SLOC оказывается проблематичным при измерении размера ПО. С другой стороны, этот процесс является примером сложной системы, в которой единицы измерения SLOC работают весьма эффективно.

Таблица D.12.
Размеры CSCI Подсистемы общего назначения, выраженные в ESLOC
Поставляемые.
Сгенерированные с помощью инструментов
Использованные в качестве входных данных для инструментов
Разработанные.
инструменты
80 000 355 000
40 000 202 000
12 000 38 000
3000 24 000
65 000 277 400

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

D.8.2 Совершенствование процессов создания подсистем.

Одним из лейтмотивов данной книги является утверждение о том, что реальное улучшение процесса должно стать очевидным при последующем осуществлении проекта. Поскольку проект CCPDS-R состоит из трех отдельных проектов, он прекрасно иллюстрирует эту тенденцию. В целом создание Подсистемы общего назначения позволило выполнить основную черновую работу для подсистем PDS и STRATCOM, а именно: определение процесса, инструментария и архитектурных примитивов. При создании каждой очередной подсистемы продуктивность и качество значительно повышались. Это позволяло приближаться к зрелому процессу создания ПО, такому, каким является процесс, разработанный и усовершенствованный при осуществлении проекта CCPDS-R. Сравнивать производительность различных проектов всегда сложно, однако в случае.

подсистем CCPDS-R имелись непротиворечивые способы измерения SLOC, созданных разработчиками, а также единые процессы, команды и методы. Согласованный подход к определению метрик обеспечивал получение сравнимых наборов данных, В качестве нормализованной единицы измерения были выбраны затраты, приходящиеся на одну SLOC. Абсолютные значения затрат несущественны; имеют значение лишь относительные затраты на каждую подсистему. Стоимость одной строки подсистемы PDS составляла 40% от стоимости SLOC Подсистемы общего назначения, а подсистемы STRATCOM — 33%, Это один из реальных показателей процесса уровня 3 или уровня 4 СММ.

В таблице D.13 представлено движение всех SCO по всем CSCI на 58-ом месяце выполнения проекта. К этому моменту для Подсистемы общего назначения закончился процесс ОКТ и было обработано некоторое количество SCO в режиме сопровождения с целью реализации некоторых новых предложений. Подсистемы PDS и STRATCOM уже находились в стадии тестирования. Для полноты картины в таблицу включены разделы, касающиеся вспомогательного ПО, тестирования и поставщика операционной системы. (Отслеживание запросов на внесение изменений в коммерческие продукты производилось аналогично отслеживанию SCO.) В вспомогательное ПО вошли инструменты для генерации кода, управления конфигурацией, работы с метриками и драйверы для независимого тестирования; к тестированию относились драйверы, использовавшиеся для проверок на соответствие требованиям.

Из таблицы D.13 видно, что значения коэффициента дефектности (среднее количество дефектов, приходящееся на одно изменение) и адаптируемости (среднее количество доработок на одно изменение) оказываются намного лучше для последующих подсистем (PDS и STRATCOM), нежели для Подсистемы общего назначения. Единственное исключение составляет ССВ CSCI — специальная система взаимодействия, необходимая только для подсистемы STRATCOM и не имеющая аналогов в других подсистемах, поэтому ее сложность является уникальной.

Проект CCPDS-R продемонстрировал наличие реального показателя зрелости процесса в соответствии с описанным в разделе Е.2. Для каждой последующей системы процесс ее создания — если измерять качество, продуктивность или затраченное время — оказывался лучше. За время жизни проекта CCPDS-R возможности по созданию ПО подвергались многочисленным оценкам, проводимым SEI, и зрелость процесса всегда соответствовала уровню 3 или выше. Однако эти улучшения возникли не только благодаря зрелости процесса. Работа в единой команде всех заинтересованных сторон и усилия, направленные на формирование основ архитектуры и автоматизацию процесса, оказались, вероятно, не менее важными для общего успеха проекта.