Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

214 Глава 5

Таблица 5.2. Классификация рабочих продуктов по ISO/IEC 15504-5: 2006

Категория РП Класс РП Примеры рабочих продуктов

1.1. Политика Цель процесса, кадровая политика

1.2. Процедура Методология разработки, описание процесса, про-

цедура поддержки потребителя, механизм связи

1.3. Стандарт Модель ЖЦ, стандарт кодирования

1. Организа-

ционные

1.4. Стратегия Стратегия повторного использования, стратегия

поставки

2.1. План План-график, план качества, план испытаний, план

повторного использования

2.2. Требования Спецификация требований к продуктам, к услугам,

к документам (внутренних или внешних)

2.3. Проект Технический проект, сценарий испытаний, кон-

трольный пример, проект базы данных

2.4. Реализация Перечень компоновки (особенности реализации)

2.5. Продукт Репозиторий повторного использования, комплект

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

мент конфигурации, документация пользователя

2. Проектные

2.6. Промежу-

точная поставка

Интегрированное ПО (компоненты в соответствии

с перечнем компоновки)

3.1. Отчет Отчет о состоянии, отчет о проблеме

3.2. Протокол Протокол совещания, протокол анализа риска, про-

грамма обеспечения качества, протокол аудита,

результаты испытаний, протокол приемки

3.3. Измерения Оценка размера, критерий качества, измерения

проекта

3. Вспомога-

тельные

3.4. Данные Результаты анализа, эталонные данные, данные об

эффективности процесса

По результатам всестороннего анализа полученной информации готовятся

выходные рабочие продукты процессов контроля качества – планы проверок, отче-

ты о состоянии разработки, данные об эффективности процессов ЖЦ, рекоменда-

ции для руководителей проекта или организации. Некоторые образцы этих рабочих

продуктов уже встречались ранее в этой книге (например, план измерения, план

качества), остальные – будут представлены в последующих главах.

5.2.4. Ключевые метрики для контроля разработки

Ключевыми метриками, применяемыми при решении задач SQA, являются:

• метрики трудоемкости и стоимости разработки;

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

• метрики ошибок.

Трудоемкость и стоимость разработки. Существует немало методов оце-

нивания трудоемкости и стоимости ПС, имеющих как достоинства, так и недостат-

ки. Основные из них (например, SLIM, COCOMO, FPA и др.) подробно рассматри-

ваются в главах 8 и 9.

Глава 5 215

Размер. Основная проблема и препятствие для применения ряда методов оп-

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

нужно сначала предсказать размер конечной системы в единицах SLOC (число

строк исходных инструкций кода). Существуют хорошие руководства по определе-

нию длины кода «готового» программного продукта. Однако, во-первых, они не-

пригодны для прогнозирования, а, во-вторых, длина кода не всегда отражает раз-

мер современных программных продуктов (например, продуктов, предназначенных

для интенсивной работы с базами данных средствами современных СУБД).

Достойную альтернативу измерению SLOC составляет определение размера

ПО в условных единицах функциональности (FP, от Functional Points), выполняемое

на ранних стадиях ЖЦ исходя из анализа функциональных требований к про-

граммному обеспечению. Методологию анализа показателей функционального

размера (FPA, Function Point Analysis) предложил А.Альбрехт в 1979 году [32]. Об-

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

взгляд на разрабатываемый программный продукт, представлен в главе 8.

Сложность. Оценка таких характеристик качества ПС, как надежность или

сопровождаемость, не может быть выполнена до тех пор, пока не получена хотя бы

первая версия кода ПС. Однако еще до завершения разработки системы полезно

знать, какие ее компоненты могут оказаться менее надежными, сложнее тестируе-

мыми или хуже сопровождаемыми, и принимать это во внимание при распределе-

нии ресурсов разработки и тестирования. Многочисленные исследования показали,

что хорошим «предсказателем» для этих целей служат метрики сложности [33].

Наиболее известными метриками сложности являются метрики М.Холстеда (1977

год) [34] и метрика «цикломатическое число» Т.МакКейба (1976 года) [35].

Как показано на рисунке 5.11, М.Холстед определил метрики сложности:

размер программы (длина), размер словаря, предсказанный размер (с учетом разви-

тия) и объем программы, основываясь на синтаксических элементах программы

(операторах и операндах). Он предложил также уравнения для оценки трудоемко-

сти, времени программирования и количества ошибок.

Обозначения, введенные Холстедом:

- количество разных операторов

- количество разных операндов

- общее количество операторов

- общее количество операндов.

Основные метрики:

Размер (длина) программы: N=N

Размер словаря: n=n

Предсказанный размер:

222121

loglog nnnnN ⋅+⋅=

)

Объем программы:

nNV

log⋅=

Дополнительные метрики:

Трудоемкость разработки:

221

log

nNNn

⋅

⋅⋅⋅

Время, требуемое на разработку: T=E/18 секунд.

Количество ошибок:

3000/VB

Рис. 5.11. Метрики Холстеда

216 Глава 5

Используя положения теории графов, Т.МакКейб предложил метрику, на-

званную цикломатическая сложность, в основе которой - анализ графа потока

управления программы (рисунок 5.12).

Рис. 5.12. Пример вычисления цикломатической сложности

Метрика сложности определяется числом линейно независимых путей в гра-

фе потока управления программы, от точки входа до точки выхода (называемых

базовыми путями). Чем меньше число независимых путей, тем меньше тестов тре-

буется для проверки всех возможных последовательностей управления элементом

ПС. Вычисляется по формуле:

C = e - n + 2,

где С – цикломатическая сложность, e – количество ребер на графе, n – количество

узлов. Рекомендуемое значение цикломатической сложности для обеспечения со-

провождаемости и тестируемости кода - 10.

Фирмой McCabe and Associates (www.mccabe.com) создан набор инструмен-

тов структурного анализа и тестового покрытия кода, основанный на этой метрике.

Метрики Холстеда и МакКейба широко использовались в 80-е годы, хотя и

подвергались критике за излишнее упрощение и очевидный «недоучет» сложности

потоков данных или неструктурных программ, что и побудило их критиков к соз-

данию множества новых метрик, учитывающих самые разные аспекты сложности

программ (например, глубина вложенности, число узлов и другие). Однако эти но-

вые метрики определялись на отдельных программах и не были чувствительны к

декомпозиции системы на процедуры и функции. Позже был предложен новый

класс метрик, учитывающих сложность информационных потоков между модулями

[36]. Преимущество этих метрик состояло в том, что они могли применяться до

этапа кодирования ПС, уже во время детального модульного проектирования ПС.

Метрики, используемые при объектно-ориентированном подходе (ООП).

Хотя уже предложено немало метрик, учитывающих особенности объектно-

ориентированного подхода к разработке ПС, они, как правило, не имеют под собой

теоретического базиса и не утверждены формально [37]. Эти метрики предназначе-

ны для оценивания сложности таких конструкций и механизмов, как метод, класс,

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

представлены в таблице 5.3.

Глава 5 217

Таблица 5.3. Метрики сложности, применяемые в ООП

Наименование Определение метрики

Цикломатическая

Сложность

(Cyclomatic

Complexity)

Используется для оценки сложности алгоритма метода. Определя-

ет число тестов, необходимых для тщательного тестирования мето-

да. Чем ниже цикломатическая сложность, тем лучше метод.

Метрика не может непосредственно использоваться для оценки

сложности класса (ввиду действия механизмов наследования), од-

нако цикломатическую сложность отдельных методов можно ком-

бинировать, вычисляя сложность класса.

Взвешенное число

Методов в Классе,

или

Взвешенная на-

сыщенность клас-

са

(Weighted Methods

per Class)

Определяется:

- количеством методов, реализованных в классе, или

- суммой оценок сложности методов (по цикломатической сложно-

сти каждого).

Вторую меру определить сложно, так как не все методы могут быть

доступны в иерархии классов (из-за механизмов наследования).

Метрика используется для определения времени и усилий, необхо-

димых на разработку и сопровождение класса. Чем больше число

методов в классе, тем выше потенциальное влияние на классы-

наследники и тем меньше возможности повторного использования.

Количество вызы-

ваемых удаленных

методов

Number Of Remote

Methods

Удаленный метод - метод, который не определен в классе и его

предках.

При формировании значения метрики просматриваются все конст-

рукторы и методы класса, и подсчитывается количество вызывае-

мых удаленных методов.

Отклик на класс

(Response for a

Class)

Общее количество методов, которые могут вызываться экземпля-

рами класса. Вычисляется как сумма числа локальных методов и

числа удаленных методов. Чем больше число методов, которые мо-

гут быть вызваны из класса с помощью сообщений, тем сложнее

класс, больше коммуникаций с другими классами.

Недостаток связ-

ности методов

(Lack of Cohesion

of Methods)

Вычисляется как число пар методов, не имеющих общих атрибутов,

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

Отрицательный результат отождествляется с нулем.

Низкая связность – признак большой сложности и необходимости

разделения класса. Высокая - свидетельство небольшой сложности

класса и потенциальной возможности повторного использования.

Сцепление между

классами

(Coupling Between

Classes)

Мера относительной независимости класса от других классов.

Вычисляется как количество отдельных иерархий классов (не свя-

занных между собой иерархическим наследованием), для которых

данный класс является сцепляющим (то есть, зависящих от данного

класса). Чем слабее сцепление классов, тем лучше.

Глубина Дерева

Наследования

(Depth of

Inheritance Tree)

Максимальное число шагов по иерархии классов от данного класса

до вершины (корня) иерархии (количество классов-предков в ие-

рархии).

Чем глубже находится класс в иерархии, тем больше методов на-

следуется, тем класс сложнее, однако выше потенциальные воз-

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

Количество на-

следников

(Number of

children)

Число непосредственных подклассов класса в иерархии наследова-

ния. Чем больше, тем больше вероятность неудачной абстракции

класса, тем выше сложность, с другой стороны, тем больше воз-

можность повторного использования.

218 Глава 5

Метрики ошибок. Обнаружение и своевременное устранение ошибок – ос-

новная задача процессов контроля качества ПС. Между тем, ни за рубежом, ни в

Украине, не достигнуто согласия по определению основных понятий в этой облас-

ти – дефект, ошибка, отказ. Эти понятия по-разному определяются не только в на-

учной литературе по качеству и надежности программного обеспечения, но и в

стандартах. Проще всего поступили разработчики стандарта IEEE Std.1044 «Stan-

dard Classification for Software Anomalies» (Стандартная классификация аномалий

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

«аномалия» (anomaly) вместо других – error, fault, failure, incident, flaw, problem,

gripe, glitch, defect или bug

- что для целей этого стандарта оправданно. В Украине

положение усугубляется внесением «погрешностей перевода» специальных терми-

нов в переводную литературу. Поэтому в данном изложении мы даем свое толкова-

ние используемых терминов и указываем их приемлемые английские эквиваленты.

Существуют глубокие причинно-следственные связи между отказами ПС в

эксплуатации, дефектами в поставляемом программном обеспечении, ошибками

разработчика и изъянами в процессах создания ПС (рисунок 5.13).

Отказ (failure) - событие перехода ПС из работоспособного состояния в не-

работоспособное или получения результатов, которые находятся вне области до-

пустимых значений.

Отказы ПС могут быть обусловлены как внешними причинами (ошибками

элементов среды функционирования, в том числе человека-оператора), так и внут-

ренними причинами - дефектами в ПС.

Дефект (defect) в ПС – запись элемента программы (кода) или текста доку-

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

ключающемуся в неправильной интерпретации этого элемента компьютером

(ошибке (fault) в программе - ошибочному состоянию программы) или человеком

(ошибке (error) исполнителя – заблуждению исполнителя).

Дефект всегда является следствием ошибки исполнителя процесса на любом

из этапов разработки. Дефектом могут обладать спецификации требований, про-

ектные документы, тексты кода, эксплуатационная документация и т.д. Выходные

рабочие документы одних процессов, содержащие не устраненные при проверке

дефекты, служат входными документами для других процессов, а дефекты в них –

источником ошибок исполнителей этих процессов. Кроме того, ошибки исполните-

лей могут являться следствием изъянов в определении процессов (неправильная

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

ствующих неправильной интерпретации исходной информации человеком и приня-

тию неверных решений, или просто недостаточной профессиональной зрелостью.

Ошибки исполнителей, в свою очередь, приводят к дефекту в рабочем продукте, и

цикл «ошибка (error) – дефект (defect) – ошибка (error)» повторяется.

Дефекты в коде, не обнаруженные в результате проверок текста кода, служат

источником потенциальных ошибок и отказов ПС. «Сработает» дефект или нет,

зависит от того, по какому сценарию будет работать с программой пользователь, и

«столкнется» ли обработчик кода с неправильным элементом.

Правильно перевести эти слова на русский язык можно лишь в том случае, если

точно знать контекст их применения в тексте.

Глава 5 219

Процесс ЖЦ

Изъян

в определении

Ошибка

исполнителя

процесса

Дефект

устраняется

из рабочего

продукта

Дефект

в рабочем продукте

процесса разработки

Область процесса разработки

Область процесса кодирования

Процесс

кодирования

Ошибка

в определении

Низкая

профессио-

нальная

зрелость и др.

причины

Ошибка

программиста

Область

процесса

контроля

Рабочий продукт

(выходной для

)

Рабочий продукт

(входной для

i+1

)

...

Низкая

профессио-

нальная

зрелость и др.

причины

Дефект

порождает

ошибку

Ошибка

приводит к

дефекту

Процесс

выполнения

программы

Ошибка

при выполнении

дефектного кода

Дефект

в коде

Текст программы

Дефект

порождает

ошибку при

выполнении

Ошибка

распространяется

по программе

Отказ

программы

Дефект

устраняется

при проверке

Ошибка

компенси-

руется

Процесс использования

программы по

определенному

сценарию

Внешняя ошибка

(пользователя

или аппаратуры)

Отказ ПС

в обслу-

живании

Рис. 5.13. Связь ошибок, дефектов и отказов

Если дефект «срабатывает» - возникает цепь ошибок, передаваемых от моду-

ля к модулю. Если ошибка не компенсируется в программе (благодаря встроенным

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

вания» другого дефекта), - она может привести к аномалии в функционировании

ПС. Считать ли аномалию отказом – зависит от определения понятия отказ в спе-

цификации требований к разрабатываемой ПС. Обычно говорят, что в результате

выполнения программы произошел инцидент (incident), который проявился в виде

определенной аномалии. Последующий анализ инцидента и аномалии может пока-

зать наличие проблемы (problem) или ее отсутствие. О проблеме составляется от-

чет, который в виде входного документа направляется процессу «Управление ре-

220 Глава 5

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

цепочкой

дефект в коде (defect) [- ошибка (fault)] - аномалия (anomaly) = отказ (failure).

Основными процессами, обычно исследуемыми в проблематике инженерии

качества, являются процессы внесения ошибок, устранения дефектов и процесс от-

каза, а ключевыми метриками – «количество дефектов», «плотность дефектов» (ко-

личество обнаруженных дефектов, деленное на размер программы) и «интенсив-

ность отказов системы» (число отказов за определенный промежуток времени).

Количество или плотность дефектов, обнаруженных в программе в ходе тес-

тирования, нельзя считать хорошими индикаторами качества ПС, в большей степе-

ни они служат индикаторами серьезности процесса тестирования [38]. Тем не ме-

нее, регистрация дефектов определена как обязательное требование базового стан-

дарта по качеству - ISO 9000-3:1997

. Регистрация дефектов служит основой для

построения банков исторических эталонных данных по программным проектам и

продуктам, которые могут использоваться для сравнения вновь разрабатываемых

ПС с аналогами и улучшения процессов программной инженерии. Некоторые из

них представлены в таблице 5.4 [39].

Таблица 5.4. Эталонные данные по программным проектам

Характеристика Показатели высокого по-

тенциального качества ПС

В среднем

Плотность дефектов в программном продукте, который

реализует совсем новые функции

0,97 дефектов/УЕФ

14 дефектов/KSLOC

Плотность дефектов в программном продукте, который

реализует не новые функции

0,14 дефектов/УЕФ

2 дефекта/KSLOC

Плотность выявленных дефектов в ходе разработки (для

ПС в области организационного управления)

1,2 дефектов/УЕФ

17,4 дефектов/KSLOC

Эффективность

устранения дефектов

> 95% всех дефектов устра-

няются во время разработки

> 56% всех дефектов устра-

няются во время разработки

Стабильность

требований

< 2.5% изменений в базовых

требованиях

Ясность требований > 97.5 % проверенных

требований

Плотность дефектов

после тестирования

0.06 дефектов/УЕФ 0.44 дефектов/УЕФ

6,4 дефектов/KSLOC

Производительность

разработки

39 УЕФ или

4250 SLOC в чел.-мес.

23 УЕФ или

2500 SLOC в чел.-мес.

Наименьшая (по отно-

шению к среднему)

плотность потенции-

альных дефектов в

артефакте проекта (в

расчете на УЕФ)

В требованиях - 0.20

В проектных решениях - 0.25

В коде - 0.25

В документации - 0.20

Не точно устраненных - 0.1

Всего 1.0 дефектов в УЕФ

В требованиях - 1.0

В проекте - 1.25

В коде - 1.25

В документации - 1.0

Не точно устраненных - 0.5

Всего 5.0 дефектов в УЕФ

Серия стандартов ISO 9000 продолжает реформироваться. См. главу 12

Глава 5 221

Характеристика Показатели высокого по-

тенциального качества ПС

В среднем

Наименьшая плотность

фактических дефектов

(в расчете на УЕФ)

В требованиях - 0.02

В проекте - 0.0125

В коде - 0.003

В документации - 0.01

Не точно устраненных - 0.01

Всего 0.056 фактических

дефектов/УЕФ

В требованиях - 0.16

В проекте - 0.10

В коде - 0.024

В документации - 0.08

Не точно устраненных - 0.08

Всего 0.444 фактических

дефектов/УЕФ

Эффективность устра-

нения дефектов (спо-

собность устранять

дефекты без внесения

новых)

CMM уровень 5 - 95%, CMM уровень 4 - 93%

CMM уровень 3 - 91%, CMM уровень 2 - 89%

CMM уровень 1 - 85%

Средний показатель плотности дефектов программных продуктах – 6 дефек-

тов в KSLOC для США и Европы и 2 дефекта в KSLOC для Японии.

В таблице 5.5 представлены данные о процессах выявления и устранения де-

фектов, опубликованные С. Кэном [40].

Таблица 5.5. Структура дефектов по стадиям ЖЦ ПС (дефекты/KSLOC)

Стадия ЖЦ Унас-

ледо-

вано

Вне-

сено

Всего

присут-

ствуют

Эффек-

тивность

устранения

Уст-

ра-

нено

Оста-

ток

Анализ требований Нет 1.2 1.2 Нет Нет 1.2

Спецификация треб. 1.2 8.6 9.8 74% 7.3 2.5

Проектирование 2.5 9.4 11.9 61% 7.3 4.6

Кодирование 4.6 15.4 20.0 55% 11.0 9.0

Автоном. тестирование 9.0 Нет 9.0 36% 3.2 5.8

Интеграц. тестирование 5.8 Нет 5.8 67% 3.9 1.9

Испытания 1.9 Нет 1.9 58% 1.1 0.8

Эксплуатация 0.8 Нет Нет Нет Нет Нет

Количество (или плотность) дефектов в программе перед началом тестирова-

ния – важная метрика для определения, с одной стороны, эффективности процессов

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

эффективности процесса инспекции (чем больше устраняется дефектов, тем эффек-

тивнее процесс). Количество дефектов, содержащихся в программе на момент на-

чала тестирования, полезная метрика для раннего прогнозирования надежности ПС

и параметр ряда моделей роста надежности.

5.2.5. Стандартизация в области инженерии качества

Разработку стандартов осуществляют международные и национальные орга-

ны стандартизации, основные из которых представлены в таблице 5.6 наряду с ука-

занием их адресов в Интернет (по данным, полученным на сайте

www.memst.kz/int_links.html).

222 Глава 5

Таблица 5.6. Международные и национальные органы стандартизации

Обозна-

чение

Наименование (англ.) Наименование (рус.) Адрес в Ин-

тернет

Международные организации по стандартизации

ISO

International Organization

for Standardization

Международная организация

по стандартизации

www.iso.org

IEC/CEI

International Electrotech-

nical Commission

Международная электротех-

ническая комиссия

www.iec.ch

CEN

European Committee for

Standardization

Европейский комитет по стан-

дартизации

www.cenorm.be

CENEL-

European Committee for

Electrotechnical Standardi-

zation

Европейский комитет по стан-

дартизации в области электро-

техники и электроники

www.cenelec.be

ETSI

European Telecommunica-

tions Standards Institute

Европейский институт по

стандартизации в области те-

лекоммуникаций

www.etsi.org

EOQ

European Organization for

Quality

Европейская организация по

качеству

www.eoq.org

IFAN

International Federation of

Standards Users

Международная федерация

пользователей стандартов

www.ifan-

online.org

EASC

EuroAsia Council on Stan-

dartization, Metrology, and

Certification

МГС СНГ – Межгосударств.

совет по станд-ции, метроло-

гии и сертификации СНГ

www.easc.org.by

WSSN

World Standards Services

Network

Всемирная сеть служб стан-

дартов

www.wssn.net

Национальные организации по стандартизации

ANSI

American National Stan-

dards Institute

Американский национальный

институт по стандартизации

www.ansi.org

BSI

British Standards Institution Британская организация по

стандартизации

www.bsi-

global.com

DIN

Deutsches Institut fur Nor-

mund

Институт стандартизации

Германии

www2.din.de

IEEE

Institute of Electrical and

Electronics Engineers, Inc.

IEEE Standards Associa-

tion

Ассоциация по разработке

стандартов. Институт инже-

неров по электротехнике и

электронике (США)

www.ieee.org

standards.ieee.

org

NASA

National Aeronautics Space

Administration

Нац. агентство по исследова-

нию космич. пространства

www.nasa.gov

NIST

National Institute of Stan-

dards and Technology

Нац. институт по стандартза-

ции и технологии (США)

www.nist.gov

SAA

Standards Australia Стандарты Австралии www.standards.

com.au

SCC

Standards Council of Can-

ada

Совет по стандартам Канады www.scc.ca

ГОСТ

State Committee of the Ru-

ssian Federation for Stan-

dardization and Metrology

Государственный комитет

Российской Федерации по

стандартизации и метрологии

www.gost.ru

ДСТУ

State Committee of Ukrai-

ne for Standardization, Me-

trology and Certification

Государственный комитет по

стандартизации, метрологии и

сертификации Украины

www.dssu.gov.

Глава 5 223

Базовыми стандартами по контролю и управлению качеством продукции яв-

ляются международные стандарты серии ISO 9000, касающиеся Системы управле-

ния качеством

, и соответствующие гармонизированные стандарты Украины (при-

ложение 3). Аннотацию на стандарты ISO серии 9000 можно получить по адресу

ISO в Интернет.

Международные стандарты (МС) в области информационной технологии

разрабатываются объединенным техническим комитетом JTC1 (Joint Technical

Committee) «Information technology», образованным ISO и IEC.

JTC1 включает множество подкомитетов (SC, Subcommittee)

. Ответствен-

ным за разработку международных стандартов по программной инженерии являет-

ся подкомитет ISO/IEC SC7 «Software and system engineering»

Для работы по проектам стандартов в подкомитете SC7 созданы рабочие

группы (WG, Working Group), основные из которых перечислены в таблице 5.7.

Таблица 5.7. Рабочие группы подкомитета SC 7 по программной инженерии

Группа Наименование (англ.) Наименование (рус.)

WG 2 System software documentation Документация ПО

WG 4 Tools and Computer Aided Soft-

ware/System Engineering (CASE)

environments

Инструменты и CASE-среды

WG 6 Software product evaluation and

metrics

Оценивание программного продукта и

метрики

WG 7 Life cycle management Управление жизненным циклом

WG 9 System and Software assurance

(safety, security and dependability)

Обеспечение гарантий системы и ПО

(безопасности функционирования, защиты

информации и надежности)

WG 10 Process assessment Оценивание процесса

WG 12 Functional size measurement Измерение объема функциональных воз-

можностей (размера)

WG 19 Modeling languages, metadata,

Open distributed processing (ODP)

framework and components

Языки моделирования, метаданные, схема

и компоненты открытой распределенной

обработки

WG 20 Software Engineering Body of

Knowledge

Ядро знаний в области программной ин-

женерии

WG 21 Software asset management proc-

ess

Процесс управления наработками в облас-

ти программного обеспечения

WG 23 Systems Quality management Управление качеством систем

WG 24 Software Life Cycles for Very

Small Enterprises

Жизненные циклы ПО для очень мелких

предприятий

Поскольку в украинских стандартах термин «quality management» переводится как

«управління якістю», в данном изложении используется термин «управление качеством»

(хотя в соответствующих российских стандартах - «менеджмент качества»)

По последним данным JTC1 насчитывает 17 подкомитетов с номерами 2-37. Нуме-

рация не непрерывная. После роспуска отдельных подкомитетов список не перенумеровы-

вается.

Адрес JTC1/SC7 в Интернет: www.sqi.gu.edu.au/sc7/mirror/ (на дату: 01.06.2006)