Надёжность программного обеспечения

 

Лабораторная работа № 3

 

Оценка качества программного продукта с помощью внешних метрик (2 часа)

1. Краткие сведения из теории

 

1.1. Назначение и состав метрик

 

1.1.1. Назначение внешних метрик Согласно ISO/IEC 9126-1 (стандарт ISO 9126-1: 2001. Информационная технология, Качество программных средств, далее – стандарт) метрика – это масштаб измерения качества и метод, используемый для измерения качества программного обеспечения (ПО) или программного продукта. Метрика включает методы для распределения по категориям данных, выраженных в качественной форме. Метрика может быть внутренней или внешней. Метрики качества ПО делятся на внутренние и внешние. Внутренние метрики используются во время разработки ПО для предсказания того, удовлетворяет ли ПО заявленным требованиям к качеству. Они характеризуют так называемое внутреннее качество ПО (качество на стадии разработки). Внешние метрики должны измерять свойства, связанные с поведением ПО во время тестирования, чтобы показать степень надёжности (качества) ПО в процессе эксплуатации. Они характеризуют внешнее качество ПО (качество после тестирования, т.е. на стадии эксплуатации). Внутреннее качество определяют как среднеарифметическое внутренних метрик, а внешнее – как среднеарифметическое внешних метрик. Метрики, которые не могут быть рассчитаны по каким-либо причинам, из оценок внутреннего и внешнего качества исключаются.

1.1.2. Численный расчёт (оценка) метрик. Метрики распределяются по категориям характеристик и подхарактеристик из ISO/IEC 9126-1. Каждая подхарактеристика оценивает свой i – единичный показатель качества ПО Х_i. Оценка внутренних и внешних метрик качества ПО строится на базе одних и тех же взаимосвязанных между собой формул для разных метрик. Эти формулы имеют вид:

Х = А/В (1)

Х = 1 – А/В (2)

При этом в (1), (2) полагается, что оценка Х=1 соответствует максимальному качеству (надёжности), а Х=0 – минимальному, а А и В численные значения некоторых количественно оцениваемых единичных подхарактеристик ПО.

Общий интегральный показатель качества ПО согласно ГОСТ 15467-79 «Управление качеством продукции. Термины и определения» записывается как средневзвешенное значение единичных показателей , т.е.

, (3)

где – весовой коэффициент при i -ом единичном показателе качества, определяемый методом экспертных оценок, опытом работы или социологическим опросом потребителей, N – количество метрик (единичных показателей). Если совокупность единичных показателей представить в виде N – мерного вектора , а совокупность весовых коэффициентов – в виде N – мерного вектора , то формулу (3) несложно переписать в виде скалярного произведения векторов и , т.е.

, (4)

где «*» в (3.21) – знак скалярного произведения 2-х векторов. Согласно ISO/IEC 9126-1 все координаты вектора равнозначны, т.е.

. (5),

причём (6)

1.1.3. Расчёт (оценка) метрик в баллах. Во многих случаях для введения равномерности шкалы оценки единичных показателей, а также при их количественном, а не качественном значении, вместо оценки метрик по формулам (1), (2) дополнительно применяют их оценку в баллах. Для этого каждой метрике назначают шкалу от 0 до 10 баллов (0 баллов соответствует минимальному качеству (надёжности), а 10 баллов – максимальному). Градацию шкал (т. е. установление, что значение метрики от 0 до 0,2 соответствует единичному показателю в 2 балла) проводят при этом методом экспертных оценок, опытом работы или социологическим опросом потребителей и разработчиков ПО.

1.1.4. Состав внешних метрик (их полный перечень приведен в прил. 1-4, отдельные файлы, при этом в таблицах из прил. 1-4 приняты следующие обозначения:

столбец 6, тип ШМ (шкалы метрик) – А (абсолютная), ШО (шкала отношений),

столбец 7, тип измерений – ЧТ (численный тип), ВТ – временной тип

столбец 10, ЦА (целевая аудитория) – Р (разработчик), СС (специалист по сопровождению), П – пользователь, Пк – поставщик

1.1.4.1. Метрики функциональных возможностей (functionality metrics, группа 1, всего 14 метрик, 5 подгрупп). Внешняя метрика этой группы должна измерять такой атрибут (свойство), как функциональное поведение системы, содержащей программное обеспечение. За поведением системы можно наблюдать в следующих ракурсах: а) Различия между фактически выполненными результатами и спецификацией требований к качеству; б) Несоответствие функциональным требованиям, обнаруживаемое во время работы обычного пользователя, которое не указано, но подразумевается как требование в спецификации.

Метрики пригодности (suitability metrics, группа 1, подгруппа 1.1, всего 4 метрики). Метрика пригодности должна измерять появление не соответствующей требованиям функции или появление не соответствующей требованиям операции во время тестирования и работы пользователя в системе. Не соответствующими требованиям функциями или операциями могут быть: а) Функции и операции, которые выполняются не так, как указано в руководствах пользователя или спецификации требований, б) Функции и операции, которые не обеспечивают корректного и приемлемого результата для достижения намеченной конкретной цели пользовательской задачи.

1.1.4.1.2. Метрики правильности (accuracy metrics,группа 1, подгруппа 1.2, всего 3 метрики). Метрика правильности должна измерять частоту встречи пользователей с возникшими неточностями, включающими: а) Ошибку или неопределенность в результатах, вызванную неадекватными данными; например, данные с недостаточным для точных вычислений числом значащих разрядов; б) Несоответствие между фактическими и описанными в руководстве по эксплуатации (operation manual) процедурами работы (operation procedures); в) Различия между фактическими и ожидаемыми приемлемыми результатами задач, выполняемых во время работы.

1.1.4.1.3. Метрики способности к взаимодействию (interoperability metrics,группа 1, подгруппа 1.3, всего 3 метрики). Метрика способности к взаимодействию должна измерять количество функций или возникновений меньшей коммуникативности, влияющих на данные и команды, которые легко переносятся с одной программной продукции на другие связанные с ней системы, другую программную продукцию или оборудование.

1.1.4.1.4. Метрики защищенности (security metrics, группа 1, подгруппа 1.4, всего 2 метрики). Метрика защищенности должна измерять количество функций с проблемами защищенности или функций, в которых могут возникнуть такие проблемы. Этими проблемами могут быть: а) Отказ при попытке предотвращения утечки защищенной выходной информации или данных; б) Отказ при попытке предотвращения утери важных данных; в) Отказ при попытке защиты от несанкционированного доступа или несанкционированной операции.

1.1.4.1.5. Метрики согласованности в функциональных возможностях (functionality compliance metrics, группа 1, подгруппа 1.5, всего 2 метрики). Метрика согласованности в функциональных возможностях должна измерять количество функций с проблемами в согласованности или функций, в которых могут возникнуть такие проблемы, приводящие к тому, что программная продукция не соответствует стандартам, соглашениям, договорам или прочим законным требованиям.

Метрики надежности (reliability metrics, группа 2, всего 14 метрик, 5 подгрупп). Метрика надежности должна измерять атрибуты, связанные с поведением системы, содержащей программное обеспечение, в процессе выполнения испытаний, для того, чтобы показать степень надежности программного обеспечения в данной системе в процессе эксплуатации. В большинстве случаев понятия «системы» и «программное обеспечение» используются как одно понятие.

1.1.4.2.1. Метрики завершенности (maturity metrics, группа 2, подгруппа 2.1, всего 8 метрик). Метрика завершенности должна измерять независимость программного обеспечения от отказов (freedom of failures), вызванных существующими в самой системе ошибками.

1.1.4.2.2. Метрики устойчивости к ошибкам (fault tolerance metrics, группа 2, подгруппа 2.2, всего 3 метрики). Метрику устойчивости к ошибкам следует связать со способностью программного обеспечения поддерживать определенный уровень производительности в случаях возникновения ошибок эксплуатации или нарушения конкретного интерфейса программного обеспечения.

1.1.4.2.3. Метрики восстанавливаемости (recoverability metrics, группа 2, подгруппа 2.3, всего 6 метрик). Метрика восстанавливаемости должна измерять такие атрибуты, как способность программного обеспечения вместе с системой восстанавливать отвечающий требованиям уровень производительности, а также данные, подвергаемые прямому воздействию в случае отказа.

1.1.4.2.4. Метрики согласованности в надежности (reliability compliance metrics, группа 2, подгруппа 2.4, всего 1 метрика). Метрика согласованности в надежности должна измерять количество функций с проблемами соответствия или функций, в которых могут возникнуть такие проблемы, которые приводят к тому, что программная продукция не соответствует стандартам, соглашениям или положениям о надежности.

Метрики практичности (usability metrics, группа 3, всего 14 метрик, 5 подгрупп). Метрики практичности показывают, насколько программное обеспечение понятно, легко для обучения пользователей и работы с ним, а также показывают привлекательность программного обеспечения и его степень соответствия положениям и руководящим принципам практичности.

Метрики понятности (understandability metrics, группа 3, подгруппа 3.1, всего 7 метрик) Пользователи должны быть способны выбрать программную продукцию, которая бы подходила им по назначению. Внешняя метрика понятности должна определять, понимают ли пользователи-новички то, а) является ли программное обеспечение подходящим, б) как его можно применять для решения конкретных задач.

Метрики обучаемости (learnability metrics, группа 3, подгруппа 3.2, всего 6 метрик). Внешняя метрика обучаемости должна определять то, как долго пользователи обучаются применению конкретных функций, и насколько эффективны системы справочной информации и документация. Обучаемость сильно зависит от понятности, а измерения степени понятности могут показать потенциал обучаемости программного обеспечения.

1.1.4.3.3. Метрики простоты использования (operability metrics, группа 3, подгруппа 3.3, всего 1 метрика). Внешняя метрика простоты использования должна определять, могут ли пользователи работать и управлять программным обеспечением. Метрики простоты использования из данной подгруппы 3.3 можно разделить на категории согласно диалоговым принципам (dialogue principles) из стандарта ISO 9241-10:

категория 3.3.1 – соответствие ожиданиям работающего пользователя (соответствие программного обеспечения решаемой задаче, группа 3, подгруппа 3.3, категория 3.3.1, всего 1 метрика),

категория 3.3.2 – характеризующие контролируемость (информативность программного обеспечения, группа 3, подгруппа 3.3, категория 3.3.2, всего 1 метрика),

категория 3.3.3 – управляемость программного обеспечения

категория 3.3.4 – соответствие программного обеспечения ожиданиям пользователя

категория 3.3.5 – устойчивость программного обеспечения к ошибкам

категория 3.3.6 – пригодность программного обеспечения

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

1.1.4.3.4. Метрики привлекательности (attractiveness metrics, группа 3, подгруппа 3.3, всего 1 метрика). Внешняя метрика привлекательности должна определять внешний вид программного обеспечения и зависит от таких факторов, как структура экранного изображения и цвет. Это особенно важно для потребительской продукции.

Метрики согласованности в практичности (usability compliance metrics, группа 3, подгруппа 3.3, всего 1 метрика) Внешняя метрика согласованности в практичности должна определять степень соответствия стандартам, соглашениям, руководствам по стилю или положениям, относящимся к практичности.

 

Вышеперечисленные метрики подробно описаны в стандарте.

1.1.5. Как читать и применять таблицы метрик, приведенные в таблицах из прил. 1-5. В таблицах предоставляется следующая информация для каждой метрики:

(1) Название метрики: Соответствующие метрики в таблице внутренних метрик и таблице внешних метрик имеют сходные имена.

(2) Цель метрики: Она выражается в форме вопроса, ответ на который определяется применением метрики.

(3) Метод (методология) применения: Предоставляет общую схему применения.

(4) Измерение, формула и расчет элементов данных: Предоставляет формулу для измерения и объясняет значения использованных элементов данных.

ПРИМЕЧАНИЕ: В некоторых случаях для метрики предлагается более одной формулы.

(5) Интерпретация измеренного значения: Предоставляет диапазон предпочтительных величин.

(6) Тип шкалы метрик: Тип шкалы, который использует метрика. Используемые типы шкал: номинальная шкала (Nominal scale), порядковая шкала (Ordinal scale), интервальная шкала (Interval scale), шкала отношений (Ratio scale) и абсолютная шкала (Absolute scale).

ПРИМЕЧАНИЕ: Более подробное объяснение предоставлено в приложении C.

(7) Тип измерений: Используемые типы: размерный тип (Size type, например, размер функции, объем кода), временной тип (Time type, например, время работы, время пользователя), численный тип (Count type, например, число изменений, число отказов).

ПРИМЕЧАНИЕ: Более подробное объяснение предоставлено в приложении C.

(8) Входные данные для измерения: Источник данных, используемых в измерении.

(9) Ссылка на ISO/IEC 12207 SLCP: Определяет процесс(ы) жизненного цикла программного обеспечения, в котором (которых) применима данная метрика.

(10) Целевая аудитория: Определяет пользователя (пользователей) результатов измерений.

Как это выглядит на практике, видно из вышеназванных таблиц. При этом к таблицам справедливы следующие примечания: а) Входными данными для процесса измерений является обновленная редакция спецификации требований. Любые изменения, обнаруженные, в процессе жизненного цикла, должны быть внесены в спецификацию требований перед проведением процесса измерений, б) Некоторые метрики могут быть предложены для экспериментального применения, поэтому при выполнении лабораторной работы должны быть получены инструкции от преподавателя – учитывать эти метрики или нет, в) Всякую недостающую функцию нельзя рассматривать при проверке, поскольку она (функция) не реализована. Для обнаружения недостающих функций предлагается, чтобы каждая функция, объявленная в спецификации требований, тестировалась одна за другой в процесса функциональной проверки. Такие результаты становятся входными данными для метрики «Полнота реализации функций». Для обнаружения реализованных, но неадекватных функций предлагается, чтобы каждая функция тестировалась на составных задачах. Такие результаты становятся входными данными для метрики «Соответствие функций». Поэтому пользователям метрик предлагается применять обе эти метрики в процессе функциональной проверки

 

1.2. Пример оценки качества программного продукта

 

1.2.1. Пусть требуется оценить качество программного продукта (ПП) «Клиент-серверное приложение», предназначенного для обмена данными между пользователями и включающего 3 компонента: «Проверка регистрации пользователя», «Проверка авторизации пользователя» и «Рассылка сообщений», написанного на языке. Оценка должна быть проведена по метрикам группы 8.2 «Метрики надёжности» подгруппы 8.2.2 «Внешние метрики устойчивости к ошибке» (см. прилагаемый к лабораторной работе английский прототип стандарта СТБ ИСО/МЭК 9126-2003 (файл «ISO 9126-2R FinalRelease»), сс. 33–34). Текст ПП приведен ниже:

Текст компонента «Проверка регистрации пользователя»:

Клиент:

private void registryBtn_Click(object sender, EventArgs e)

{

_communicator.SendRequest(new RegisterRequest

{

Login = rLoginTb.Text,

Password = rPasswordTb.Text

});

}

Сервер:

private static BaseResponse Register(RegisterRequest register, ServerListener<BaseRequest, BaseResponse> communicator, Client client)

{

if (_users.ContainsKey(register.Login))

{

return new RegisterResponse { Error = "UserExists" };

}

 

_users.Add(register.Login, new User

{

Name = register.Login,

Password = register.Password,

});

 

Login(new LoginRequest { Login = register.Login, Password = register.Password }, communicator, client);

 

return new BaseResponse();

}

Текст компонента «Проверка авторизации пользователя»:

Клиент:

private void loginBtn_Click(object sender, EventArgs e)

{

_communicator.SendRequest(new LoginRequest

{

Login = loginTb.Text,

Password = passwordTb.Text

});

}

 

Сервер:

private static BaseResponse Login(LoginRequest login, ServerListener<BaseRequest, BaseResponse> communicator, Client client)

{

if (_users.ContainsKey(login.Login) && string.Equals(_users[login.Login].Password, login.Password))

{

var user = _users[login.Login];

user.Connection = client;

 

communicator.Write(client.TcpClient, new LoginResponse {Login = login.Login});

 

foreach (var u in _users.Where(x => x.Value.Connection.TcpClient.Connected &&!string.Equals(x.Key, login.Login)))

{

communicator.Write(u.Value.Connection.TcpClient, GetUsers());

}

 

return new BaseResponse();

}

 

return new LoginResponse { Error = "User not found" };

}

 

Текст компонента «Рассылка сообщений»:

Клиент:

private void sendBtn_Click(object sender, EventArgs e)

{

if (usersList.SelectedIndex < 0)

return;

 

_clientListener.SendRequest(new SendMessageRequest { Message = new Message { Sender = _user, Text = messageTb.Text, Receiver = usersList.SelectedItem.ToString() } });

}

 

Сервер:

private static SendMessageResponse SendMessage(SendMessageRequest request, ServerListener<BaseRequest, BaseResponse> communicator)

{

if (_users.ContainsKey(request.Message.Receiver))

{

var user = _users[request.Message.Receiver];

 

if (user.Connection.TcpClient.Connected)

{

request.Message.Time = DateTime.Now;

communicator.Write(user.Connection.TcpClient, new ReceiveMessageResponse { Msg = request.Message });

_users[request.Message.Sender].Messages.Add(request.Message);

 

return new SendMessageResponse { Time = DateTime.Now };

}

}

 

return new SendMessageResponse { Error = "User not found" };

}

 

На рис. 1 показана главная форма ПП.

 

 

Рисунок 1 – Вид главной формы ПП «Клиент-серверное приложение»

 

Исходные данные для оценки студент выбирает самостоятельно. Метод оценки – равнозначные коэффициенты при отдельных метриках как единичных показателях качества. Таких метрик 3 – №№ 23, 24, 25, следовательно, вектор весового коэффициента будет иметь вид:

= [0.333, 0.333. 0.333]. (7)

1.2.1.1. Оценим величину метрики № 23 «Коэффициент аварийных отказов [Breakdown avoidance]» как единичного показателя качества. Логика рассуждений при выборе исходных данных для оценки:

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

б) анализируем «Отчет о тестировании» ПП, если продукт ещё разрабатывается, и «Отчет об эксплуатации» ПП, если продукт уже эксплуатируется (считаем, что эти отчёты у нас имеются);

в) по выбранному отчёту находим: B1 = количество отказов ПП при эксплуатации (багов при тестировании) = 23; A1 = количество аварийных отказов при эксплуатации (аварийных багов при тестировании) = 10 (аварийный отказ означает незавершение выполнения всех задач пользователя до перезагрузки системы или потерю контроля над системой вплоть до принудительного выхода из нее, это пояснение берём из примечания к метрике в стандарте).

Измерение, формула и расчет элементов данных: по формуле (2) (с точностью до 3-х знаков после запятой):

Х1 = 1 – А1/В1 = 1 – 10/23 = 1 –0,435 =0,565

Итак, цель метрики: оценить, как часто программная продукция вызывает аварийный отказ всей программной среды? Метод (методология) оценки (применения) метрики: «Подсчитайте количество случаев аварийного отказа (breakdown occurrence) по отношению к количеству отказов (failure). Если это происходит во время эксплуатации, проанализируйте протокол, содержащий предысторию работы пользователя» (см. стандарт). Интерпретация измеренного значения: Полученная оценка Х1 = 0,565 предоставляет собой точку в диапазоне предпочтительных величин (0 <= X1, чем ближе к 1, тем лучше).

 

1.2.1.2. Оценим величину метрики № 24 «Коэффициент отказов [Failureavoidance]» как единичного показателя качества. Логика рассуждений при выборе исходных данных для оценки:

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

б) анализируем «Отчет о тестировании» ПП, если продукт ещё разрабатывается, и «Отчет об эксплуатации» ПП, если продукт уже эксплуатируется (считаем, что эти отчёты у нас имеются);

в) по выбранному отчёту находим: B2 = количество выполненных тестовых наборов, направленных на проверку типовых ошибок, которые могут привести к отказам при эксплуатации или тестировании = 58 (В1 ˂ В2, потому что число выполненных тестовых наборов больше числа ошибок или багов; некоторые наборы приводят к отсутствию ошибок или багов) A2 = количество случаев критических и серьезных отказов, которых удалось избежать, в сравнении с тестовыми наборами, направленными на проверку типовых ошибок = 52 (А2 ≠ А1).

Измерение, формула и расчет элементов данных: по формуле (1) (с точностью до 3-х знаков после запятой):

Х2 = А2/В2 = 52/58 = 0,897.

Итак, цель метрики: оценить, сколько типовых отказов было взято под контроль для того, чтобы избежать критических или серьезных отказов? Метод (методология) оценки (применения) метрики: «Подсчитайте количество типовых отказов, которых удалось избежать, и сравните с количеством типовых отказов, подлежащих рассмотрению» (см. стандарт). Интерпретация измеренного значения: Полученная оценка Х2 = 0,897 предоставляет собой точку в диапазоне предпочтительных величин (0 <= X2, чем ближе к 1, тем лучше).

1.2.1.3. Оценим величину метрики № 25 «Способность к предотвращению некорректных действий [Incorrect operation avoidance]» как единичного показателя качества. Логика рассуждений при выборе исходных данных для оценки:

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

б) анализируем «Отчет о тестировании» ПП, если продукт ещё разрабатывается, и «Отчет об эксплуатации» ПП, если продукт уже эксплуатируется (считаем, что эти отчёты у нас имеются);

в) по выбранному отчёту находим: B3 = количество выполненных тестовых наборов, направленных на проверку типичных некорректных действий, которые могут привести к отказам = 15 (В3 ˂ В2, В3 ˂ В1 последнее может быть наоборот)) A3 = количество случаев критических и серьезных отказов вследствие типичных некорректных действий, которых удалось избежать = 14 (А3 ≠ А1).

Измерение, формула и расчет элементов данных: по формуле (1) (с точностью до 3-х знаков после запятой):

Х3 = А3/В3 = 14/15 = 0,933.

Итак, цель метрики: оценить, сколько функций реализовано с возможностью предотвращения некорректных действий? Метод (методология) оценки (применения) метрики: «Подсчитайте количество тестовых наборов некорректных действий, которые могли вызвать критические или серьезные отказы, но их удалось избежать, и сравните с количеством выполненных тестовых наборов типичных некорректных действий» (см. стандарт). Интерпретация измеренного значения: Полученная оценка Х3 = 0,933 предоставляет собой точку в диапазоне предпочтительных величин (0 <= X3, чем ближе к 1, тем лучше).

1.2.1.4 На основе полученных оценок метрик интегральный показатель качества в соответствии с (4) несложно переписать в виде скалярного произведения векторов и , где вектор

= [0.565, 0.897, 0.933]. (8)

Тогда интегральный показатель качества

= [0.333, 0.333. 0.333]*[0.565, 0.897, 0.933] = подсчитать (9)

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

= [0.2, 0.35, 0.45]. (10)

Тогда интегральный показатель качества

= [0.2, 0.35, 0.45]*[0.565, 0.897, 0.933] = подсчитать (11)

 

2 Практическая часть (порядок выполнения лабораторной работы)

 

2.1 Изучите описание лабораторной работы, стандарт ISO/IEC 9126-2 и пример п. 1.2.

2.2 Вспомните о любой написанной Вами когда-либо программе или её фрагменте (далее – Ваша программа). Запишите программу с комментариями (если программа непонятна без них), скриншотами и кратким описанием (что она делает). Для заданного варианта Вашей программы оцените качество её по тем метрикам, которые указаны в Вашем варианте (задавая равнозначные коэффициенты при отдельных метриках как единичных показателях качества).

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

2.4 Сделайте вывод о том, как необходимо изменить параметры А и В каждой метрики для достижения заданного уровня интегрального показателя качества.

 

3 Содержание отчёта.

 

3.1 Название курса, название и номер лабораторной работы, ф. и. о. и номер группы студента, дату выполнения работы, текст своего варианта (варианты содержатся в файле «Варианты».

3.2 Запись своих индивидуальных заданий по пп. 2.2 – 2.4 по образцу примера п. 1.2. В записи обязательно должно присутствовать описание логики Ваших рассуждений при выборе исходных данных для оценки каждой метрики.

3.3 Выводы по п. 2.4.

 

4 Задания для самоподготовки и самопроверки

 

4.1 Чем отличается внутренняя метрика от внешней?

4.2 Что такое метрика?

4.3 Чем отличается качество ПО от его надёжности?

4.4 Что такое весовой коэффициент при расчёте качества ПО и чем отличаются равнозначные весовые коэффициенты от неравнозначных?

4.5 Что такое скалярное произведение 2-х векторов и чем оно отличается от векторного? Запишите формулы и вычислите придуманные Вами примеры скалярного и векторного произведения 2-х векторов.

4.6 Какие метрики функциональных возможностей (functionality metrics) Вы знаете? В какую группу они входят? Что оценивают?

4.7 Какие метрики завершенности (maturity metrics) Вы знаете? В какую группу они входят? Что оценивают?

4.8 Какие метрики практичности (usability metrics) Вы знаете? В какую группу они входят? Что оценивают?.

4.9 Какие метрики эффективности (efficiency metrics) Вы знаете? В какую группу они входят? Что оценивают?.

4.10 Какие метрики сопровождаемости (maintainability metrics) Вы знаете? В какую группу они входят? Что оценивают?.

4.11 Какие метрики мобильности (portability metrics) Вы знаете? В какую группу они входят? Что оценивают?

4.12 Расскажите об эволюции стандарта ISO/IEC 9126-2 за рубежом.

4.13 Расскажите об эволюции стандартов по оценке качества и надёжности ПО в СССР и Беларуси.

4.14 Приведите примеры процесса, работы и задачи согласно СТБ 12207-2003.

4.15 Какими желательными свойствами должна обладать метрика?

4.16 Какими критериями обоснованности должна обладать метрика?

4.17 Опишите структуру таблиц ISO/IEC 9126, в которых даны примеры метрик качества.

4.18 Что такое метод применения метрики? Приведите примеры.

4.19 Что такое способ измерения, формула, исходные и вычисляемые данные метрики? Приведите примеры.

4.20 Что такое интерпретация измеренного значения метрики? Приведите примеры.

4.21 Что такое тип шкалы, используемой при измерении метрики? Приведите примеры.

4.22 Что такое тип измеренного значения метрики? Приведите примеры.

4.23 Что такое источники входных данных для измерения метрики? Приведите примеры.

4.24 Что такое ссылка на СТБ 12207-2003 в таблицах ISO/IEC 9126? Приведите примеры.

4.25 Что такое целевая аудитория метрики? Приведите примеры.