Тема 1.2 МСиСвИТ. Основные положения метрологии программных продуктов
 Скачать 2.32 Mb.
|
Основные положения метрологии программных продуктовМетрология Программного Обеспечения (МПО)– изучает методы и средства оценивания качества Программных Продуктов (ПП) с целью их объективного сравнения путем сравнения метрик, характеризующих свойства ПП. Свойства программы – это особенности присущие программе, которые проявляются в ее жизненном цикле (корректность, устойчивость. восстанавливаемость). Характеристика программы – набор свойств, посредством которых описывается и оценивается его качество. Иначе говоря, характеристика – это проявляемый и измеримый атрибут свойства (обучаемость, переносимость, удобство). Показатель качества ПП – характеристика качества, имеющая количественное значение. Измерение (оценка) одной или нескольких характеристик программы дает представление о том, насколько программе присуще то или иное свойство. Каждому свойству соответствует одна или несколько характеристик ПО. Для решения задачи количественной оценки характеристик ПО необходимо наличие системы измерений и методов оценки. Основные термины и определения Система измерений характеристик программного обеспечения – это совокупность измеряемых характеристик, единиц измерения, измерительных шкал и связей, установленных между ними. Измерительная шкала устанавливает границы (диапазон) и точность измерений характеристик свойств в установленных единицах. Результаты измерений в избранной измерительной шкале позволяют обнаружить сходство и различие в свойствах программного обеспечения с целью последующей оценки и классификации. Применительно к ПО используют главным образом следующие виды измерительных шкал: 1. Категорийные – характеризуются номинальной шкалой. Характеризуют только наличие или отсутствие свойства у ПП без численной градации 2. Ранжирующие – характеризуются порядковой шкалой. Позволяют упорядочивать свойства программ путем сравнения с опорными значениями 3. Числовые – характеризуются интервальной шкалой. Представляются реально измеряемыми физическими величинами Выполнение процесса оценки программных продуктов, отвечающего требованиям ISO/IEC 12207, регламентируется стандартом ISO/IEC 14598. Стандарт описывает процесс оценивания в виде пошаговой процедуры, ориентированной на использование обобщенной модели качества, представленной в стандарте ISO/IEC 9126. К проектированию оценивания От спецификации оценивания Основные положения метрологии программных продуктов Измерения, выполняемые в процессе разработки ПП, помогают лучше оценить сам процесс разработки, принятый в организации, ход выполнения проекта и качество ПП. Измерения процесса производятся в целях его дальнейшего совершенствования, измерения проекта - для улучшения организации работ, а измерения ПП - для улучшения его качества. В результате измерения определяется количественная характеристика какого-либо свойства объекта измерения - метрика. Все метрики можно разделить на три основные группы: метрики процесса, метрики проекта и метрики продукта
Измерения помогают оценить как продукт, так и сам процесс его разработки. В результате измерений определяется мера - количественная характеристика какого-либо свойства объекта. Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить». Метрики качества позволяют судить о том, насколько близко соответствие программного изделия требованиям пользователя, т. е., судить о пригодности изделия к использованию. Ме́трика програ́ммного обеспе́чения — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. Метрики, использующие номинальную и упорядоченную шкалы, применяются для оценки качественных показателей, которые нельзя измерить количественно. Метрики, использующие числовые шкалы, применяются для оценки количественных показателей. Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались и пытаются перенести данный подход и в разработку программного обеспечения. Стандарт ISO/IEC 9126-2 определяет следующие типы мер:
Качество ПС описывается совокупностью показателей критериев, для каждого из которых должны быть определены метрики и методы их измерения. В соответствии с принципиальными особенностями ПС выбираются номенклатура и значения показателей качества, которые отражаются в техническом задании и в спецификации требований на конечный продукт. Кроме SLOC к количественным характеристикам относят также: - количество пустых строк, - количество комментариев, - процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах) - среднее число строк для функций (классов, файлов), - среднее число строк, содержащих исходный код для функций (классов, файлов), - среднее число строк для модулей Самой элементарной метрикой является количество строк кода (SLOC). количество «физических» SLOC (используемые аббревиатуры: LOC, SLOC, KLOC, KSLOC, DSLOC) – общее число строк исходного кода, включая комментарии и пустые строки (25%) количество «логических» SLOC (используемые аббревиатуры: LSI, DSI, KDSI, где SI – Source Instructions) – определяется как число команд и зависит от используемого языка программирования Измерение в области программного обеспечения– это получение числовых значений определенных показателей программного продукта или процесса его разработки. Значения этих показателей сравнивают между собой и со стандартами, применяемыми в данной организации. На основе этих сравнений можно сделать выводы о качестве продукта или процесса разработки. Измеряемые атрибуты могут быть внутренними и внешними. Внутренние атрибуты могут измеряться в терминах самого объекта, отдельно от его поведения. Внешние атрибуты оцениваются с учетом связи объекта с внешней средой. Примеры внутренних атрибутов: показатель числа строк кода в программном продукте; продолжительность выполнения действия; величина трудозатрат; число неудачных тестовых испытаний; объем денежных затрат; уровень сложности и степень модульности. Примеры внешних атрибутов: время выполнения (требуются программа и компьютер), полезность и удобство представления (требуются приложение и пользователь), надежность, эффективность, тестируемость, повторная применимость, переносимость и взаимодействие между операциями. Измерения при разработке ПОИзмерения в разработке ПО
Виды измерений
Результаты измерений процесса разработки и сопровождения ПС Классификация метрик
Классификация метрик по их ориентации:
Размерно-ориентированные метрики
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Они основываются на LOC-оценках (Lines of code). LOC-оценка – это количество строк в программном продукте. Исходные данные для расчета этих метрик сводятся в таблицу. На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества: Пример применения размерно-ориентированной метрикиИсходные данные для расчета LOC- метрик Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 12100 строк программы были разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три человека. Производительность = Длина / Затраты (тыс.LOC/чел.-мес.); Качество = Ошибки / Длина (Единиц/тыс. LOC); Удельная стоимость = Стоимость /Длина (тыс.$/LOC); Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC) На основе таблицы вычисляются размерно-ориентированные метрики: Достоинства размерно-ориентированных метрик:1) широко распространены2) просты и легко вычисляютсяНедостатки размерно-ориентированных метрик:1) зависимы от языка программирования2) требуют исходных данных, которые трудно получить на начальной стадии проекта3) не приспособлены к непроцедурным языкам программированияФункционально-ориентированные метрики 1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно. 2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных отчета отдельно не подсчитываются. 3. Количество внешних запросов. Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы - каждый учитывается отдельно. 4. Количество внутренних логических файлов. Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом). 5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо LOC - оценки рассматривается функциональность или полезность продукта. Используется и оценивается 5 информационных характеристик. Внешний ввод — элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл. Внешний вывод — элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле. Внешний запрос — элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат — данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная часть не несет данных, вычисляемых приложением (в этом и состоит отличие запроса от вывода). Внутренний логический файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы. Внешний интерфейсный файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении. Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется на элемент данных (однократный учет). После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики - А. Альбрехт (1979). Данные для определения ранга и оценки сложности транзакций и файлов (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4. Табл.6 « « Каждой из выявленных характеристик ставится в соответствие сложность. Характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл. Тип элемента- записи - это подгруппа элементов данных, распознаваемая пользователем в пределах файла. Тип элемента данных – уникальное или рекурсивное поле, распознаваемое пользователем. Количество функциональных указателей вычисляется по формуле: FP= Общее количество*(0,65+0,01*Fi), (1) Где Fi – коэффициент регулировки сложности (I=1..14). Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).
Число внешних вводов – 35;
Функционально-ориентированные метрики Функционально-ориентированные метрикиДостоинства функционально-ориентированных метрик:
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.Метрология качества Оценка качества программного продукта Стандарты ГОСТ 28806–90, ГОСТ 28195–99, СТБ ИСО/МЭК 9126–2003 регламентируют выполнение оценки качества ПС и систем на основе иерархической модели качества. В соответствии с данной моделью совокупность свойств, отражающих качество программного средства, представляется в виде многоуровневой структуры. Характеристики на первом (верхнем) уровне соответствуют основным свойствам ПС. Характеристики каждого уровня оцениваются посредством характеристик последующих. Стандарты ГОСТ 28806–90, СТБ ИСО/МЭК 9126–2003 определяют первые два уровня иерархической модели качества. Номенклатура характеристик первого уровня обязательная, а номенклатура характеристик второго уровня (подхарактеристик) – рекомендуемой. Стандарт ГОСТ 28195–99 определяет четырехуровневую модель оценки качества. Номенклатура характеристик и подхарактеристик первых двух уровней является обязательной, а номенклатура подхарактеристик третьего и четвертого уровней – рекомендуемой. Вышеназванные стандарты определяют шесть основных характеристик качества ПС, находящихся на верхнем уровне модели качества. Функциональность (Functionality); - Надежность (Reliability); – Удобство использования (практичность, Usability); - Эффективность (Efficiency); –Сопровождаемость (Maintainability); –Мобильность (Portability). Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой: - номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения; - порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;
- абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10). Оценка качества программного продукта . . СТБ ИСО/МЭК 9126–2003 и другая Процесс оценивания состоит из трех стадий: установление (определение) требований к качеству, подготовка к оцениванию и процедура оценивания. Данный процесс может применяться в любой подходящей фазе жизненного цикла для каждого компонента программной продукции. Целью начальной стадии является установление требований в терминах характеристик качества. Требования выражают потребности внешнего окружения для рассматриваемой программной продукции и должны быть определены до начала разработки. Целью второй стадии является подготовка основы для оценивания. Результатом третьей является заключение о качестве программной продукции. Затем обобщенное качество сравнивается с другими факторами, такими, как время и стоимость. Окончательное решение руководства принимается на основе критерия управляемости. Результатом является решение руководства по приемке или отбраковке, или по выпуску или не выпуску программной продукции. Оценка качества программного продукта Iso/iec 9126-1:2001 Модель внешнего и внутреннего качества программных средств (характеристики и подхарактеристики). Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными подхарактеристиками: Функциональность: 1. пригодность; 2. корректность; 3. способность к взаимодействию; 4. защищенность; 5. соответствие функциональности. Надежность: 1. завершенности (отсутствие ошибок); 2. устойчивость к ошибке; 3. восстанавливаемость; 4. соответствие надёжности. 21 стандарт ISO/IEC 9126–1:2001 классифицирует метрики качества ПС на внутренние, внешние и метрики качества в использовании. В модели внешнего и внутреннего качества метрики находятся на третьем уровне иерархии и определяют значения подхарактеристик качества. В модели качества в использовании метрики находятся на втором уровне иерархии и непосредственно определяют значения характеристик качества. Применение конкретного вида метрик определяется стадией жизненного цикла программного средства. В стандарте ISO/IEC TR 9126–2–4 определены следующие желательные свойства метрик: 1)надежность; надежность связана со случайной ошибкой; метрика свободна от случайной ошибки, если случайные изменения не влияют на результаты метрики; 2(повторяемость; повторное использование метрики для того же продукта теми же специалистами, используя ту же спецификацию оценки (ту же окружающую среду), тот же тип пользователей и окружения, должно привести к тем же результатам с теми же допусками; 3) однотипность; применение метрики для того же продукта различными специалистами по оценке, используя ту же спецификацию оценки (включая ту же окружающую среду), тот же тип пользователей и окружения, должно привести к тем же результатам с теми же допусками; 4) применимость; метрика должна четко указывать условия (например, наличие определенных атрибутов), которые ограничивают её употребление; 5) показательность; это способность метрики идентифицировать части или элементы программы, которые должны быть улучшены, на основании сравнения измеренных и ожидаемых результатов; 6) корректность; метрика должна обладать следующими свойствами:
7) значимость; измерение должно давать значащие результаты, касающиеся поведения программы или характеристик качества. Метрика должна также быть эффективной по отношению к стоимости. Это значит, что более дорогие метрики должны обеспечивать лучшие результаты оценки. 1) корреляция; изменение в значениях характеристик качества (оперативно определенных по результатам измерения основных метрик), обусловленное изменением в значениях метрики, должно определяться линейной зависимостью; 2) трассировка; если метрика М непосредственно связана с величиной характеристики качества Q (оперативно определенной по результатам измерения основных метрик), то изменение величины Q (T1), имеющейся в момент времени T1, к величине Q (T2), полученной в момент времени Т2, должно сопровождаться изменением значения метрики от М (T1) до М (T2) в том же направлении (например, если увеличивается Q, то М тоже увеличивается); 3) непротиворечивость; если значения характеристик качества (оперативно полученные по результатам измерения основных метрик) Q1, Q2,…, Qn, связанные с продуктами или процессами 1, 2..., n, определяются соотношением Q1> Q2> ... > Qn, то соответствующие значения метрики должны удовлетворять соотношению M1> M2> ... > Мn. 4) предсказуемость; если метрика используется в момент времени T1 для прогноза значения (оперативно полученного по результатам измерения основных метрик) характеристики качества Q в момент времени T2, то ошибка прогнозирования, определяемая выражением должна попадать в допустимый диапазон ошибок прогнозирования; 5) селективность; метрика должна быть способной различать высокое и низкое качество программного средства. Разработчик метрики должен доказать ее обоснованность. Метрика должна удовлетворять хотя бы одному из следующих критериев обоснованности метрики: Концентрация на одной внешней характеристике качества ПО может влиять на другую характеристику положительно, отрицательно, а может и не влиять Внутренние метрики функциональности предназначены для предсказания того, удовлетворяет ли разрабатываемый программный продукт требованиям к функциональности и предполагаемым потребностям пользователя Внутренние метрики надежности используются во время разработки программного продукта для предсказания того, удовлетворяет ли ПП заявленным потребностям в надежности. Внутренние метрики практичности используются во время разработки программного продукта для предсказания степени, в которой ПП может быть понят, изучен, управляем, привлекателен и соответствует договоренностям и руководствам по практичности. Внутренние метрики эффективности используются во время разработки программного продукта для предсказания эффективности поведения ПП во время тестирования или эксплуатации. Внутренние метрики сопровождаемости используются для предсказания уровня усилий, необходимых для модификации программного продукта. Унификация применения метрик, при количественной оценке качества программных продуктов в стандартах ISO/IEC TR 9126–2–4 Из двух формул для конкретной метрики выбирается та, которая соответствует критериям трассировки и непротиворечивости: с увеличением относительного значения метрики значение подхарактеристики и характеристики качества должно увеличиваться. Для обеспечения возможности совместного использования различных метрик (независимо от их физического смысла, единиц измерения и диапазонов значений) при количественной оценке качества программных продуктов метрики в стандартах ISO/IEC TR 9126–2–4 по возможности представляются в относительных единицах: Х=А/В (1) или Х=1-А/В (2) где Х – значение метрики; А – абсолютное (измеренное) значение некоторого свойства (атрибута) оцениваемого продукта или документации; В – базовое значение соответствующего свойства. Вычисление метрик по формуле (1) или (2) позволяет привести их относительные значения в диапазон 0≤ Х ≤1 (3) что упрощает их совместное использование при интегральной оценке качества программных средств. Внутренние метрики качества программных средств Внутренние метрики качества программных средств Внутренние метрики качества программных средств Внутренние метрики качества программных средств Внутренние метрики качества программных средств Внутренние метрики качества программных средств Метрики в управлении проектами По своему назначению выделяется три типа метрик:
Первые нужны, чтобы попытаться предсказать те проблемы, с которыми может столкнуться проект. Вторые служат для мониторинга текущего состояния проекта. Третьи в идеале помогают избежать в будущем тех неприятностей, с которыми команда сталкивалась в текущих или уже завершенных проектах Метрики в управлении проектами Прогнозирующие метрики могут описывать множество различных параметров: предполагаемый объем работ, запланированный бюджет, фактор сложности проекта, сложность плана проекта, количество людских ресурсов, суммарный запас времени и т.д. При этом желательно иметь значения этих показателей для других проектов этого же профиля, чтобы иметь возможность для сравнения. Значительные различия в показателях схожих проектов часто указывают на проблемы. Наверное, если запланированные бюджеты двух очень похожих проектов отличаются на несколько порядков, то это повод задуматься! Прогнозирующие метрики Параметров, которые описываются диагностическими метриками, также может быть великое множество. Это и соотношение планового бюджета выполненных работ к фактическому, и соотношение плановых трудозатрат к фактическим, и производительность труда работников, занятых на проекте, и показатели качества, и еще много-много чего еще. Какой бы параметр не измерялся, важно чтобы его измерения происходили регулярно. Форма представления метрик особой роли не играет: кто-то предпочитает табличный вид, а кому-то больше нравятся графики. Диагностические метрики По сути, ретроспективные метрики описывают все те же параметры, что и диагностические. Это и соотношение планового бюджета выполненных работ к фактическому, и соотношение плановых трудозатрат к фактическим, и производительность труда работников, занятых на проекте, и показатели качества, и еще много-много чего еще. Единственная разница между ними лишь в цели использования: если диагностические метрики нужны для оценки текущей ситуации на проекте и реагирования на актуальные проблемы, то ретроспективные помогают оценить уже прошедшие события. Такой ретроспективный анализ позволяет избежать типовых ошибок в будущем. Ретроспективные метрики Таким образом, использование метрик позволяет эффективно управлять проектом: своевременно обнаруживать недостатки, устранять их и при этом видеть, насколько хорошо работают найденные методы решения проблем. Однако использование метрик сопряжено с определенными сложностями. Во-первых, ни одна из известных на сегодняшний день метрик не может похвастаться достаточной значимостью и точностью. Метрики не дают объективной картины происходящего, они всего лишь предоставляют некоторые показатели, вычисленные по заданному алгоритму. Особенно это касается тех случаев, когда для оценки какого-либо параметра вводится только одна метрика. Более-менее полную картину может дать только использование целого комплекса метрик, Во-вторых, часто, если сотрудники знают об измеряемых показателях, то они стараются не выполнить свою работу надлежащим образом, а занимаются подгонкой своих показателей под заданные параметры. К примеру, если важным показателем является KSLOC (количество строк кода), то программисты будут писать «индусский» код, всячески избегая способов его упрощения, сокращающих количество строчек. Другой пример: если показателем эффективности работы программистов и тестировщиков будет количество допущенных и выявленных багов, то очень скоро они договорятся между собой, как «оптимизировать» этот показатель, чтобы это было выгодно обеим сторонам. Ну и еще один пример: если на проекте открыто используется метрика focus factor и если менеджер проекта не является «технарем», то, скорее всего, программисты будут специально завышать оценки по времени, чтобы создать себе своеобразную «подушку тайм-безопасности». В-третьих, использование метрик порождает целый ряд этических проблем. В частности, если на проекте одновременно вводятся метрики для оценки сотрудников и метрики для оценки деятельности команды в целом, то это может привести к внутренним конфликтам. В попытках «оптимизировать» собственные показатели сотрудники могут «тянуть одеяло на себя» и обвинять в своих неудачах других участников команды. В итоге между личными целями сотрудников и общими целями команды возникают противоречия, команда не срабатывается, и, как следствие, проект оказывается «заваленным». В-четвертых, сам процесс сбора метрик сопряжен с определенными техническими сложностями. Как правило, для сбора метрик и их интерпретации выделяются особые сотрудники. Если подходить к этим процессам без должной организации (особенно это касается вопросов автоматизации сбора метрик), то существует риск того, что сотрудники просто «утонут» в собранных сведениях. Тогда придется привлекать дополнительных людей, а это прямой путь к излишней бюрократизации и нерациональному расходованию ресурсов. Кроме того, существует риск того, что из-за сбора числовых показателей сотрудники будут отвлекаться от своих непосредственных обязанностей. Конечно, существуют специальные автоматизированные системы для сбора метрик, упрощающие этот процесс, но, так или иначе, к работе с метриками все равно придется привлекать специалиста-человека, которому придется потратить на это определенное время. Более того, на сбор метрик тратится еще и время членов команды, занятой на проекте. И далеко не каждый заказчик согласен это время оплачивать. Тем не менее, при правильном внедрении и грамотной интерпретации метрики могут стать весьма полезным инструментом для project-менеджеров. Благодаря использованию метрик можно отследить моменты снижения качества разработки, определить его причины и выявить самые сложные участки в системе. Кроме того, числовые показатели способны помочь в планировании затрат ресурсов на дальнейшее развитие разрабатываемого продукта. Классификация измерений Классификация измеренийВсе измерения делятся по следующим признакам: - прямые, - косвенные, - совокупные, - совместные. по способу получения измерений по числу измерений - однократные, - многократные. по точности измерений - равноточные, - неравноточные. по практическому назначению измерений - технические, - метрологические. по характеру зависимости измеряемой величины от времени - статические, - динамические. по способу выражения результатов измерений - абсолютные, - относительные.
По планируемой точности измерения делят на технические и метрологические. К техническим следует относить измерения, которые выполняют с заранее установленной точностью, т.е. с соблюдением такого условия, что погрешность измерения не должна превышать заданного значения []: [], где [] – допустимая погрешность измерения. Метрологические измерения выполняют с максимально достижимой точностью, добиваясь минимальной (при имеющихся ограничениях) погрешности измерения , что можно записать как 0. Такие измерения имеют место при эталонировании единиц, при выполнении уникальных исследований. Если цель измерений состоит в приблизительной оценке ФВ, а точность результата измерений не имеет принципиального значения прибегают к ориентировочным измерениям. Их погрешности могут колебаться в широких пределах, поскольку любая реализуемая в процессе измерений погрешность , принимается за допустимую [] [] = . По числу измерений:
Измерения можно классифицировать:
Измерения можно классифицировать:
Измерения можно классифицировать: Виды измеренийПо способу получения числового значения измеряемой величины: Прямое измерение Совместные измерения Совокупные измерения Косвенное измерение Прямые измерения
- значение измеряемой величины находится путем прямого измерения нескольких физических величин, связанных с измеряемой определенным соотношением.Косвенные измерения
Совокупные измерения - это производимые одновременно измерения одноименных величин, при которых искомые значения величин находят решением системы уравнений, получаемых при прямых измерениях различных сочетаний этих величин. При совокупных измерениях значения набора одноименных величин Х1, Х2,..., Хk как правило, определяют путем измерений сумм или разностей этих величин в различных сочетаниях: где коэффициенты cij принимают значения ±1 или 0.
а затем решая систему трех уравнений, определим R31, R12, R23Звезда- из эксперимента: ; ; и решая систему уравнений, определим R1, R2, R3
Предположим, что у нас имеется вольтметр с диапазоном измерений 12 - 15 В и совокупность гальванических элементов, у каждого из которых ЭДС может находиться в пределах Е = 4.0 .. 4.5 В. С помощью прямых измерений указанным вольтметром определить ЭДС каждого элемента невозможно. Но, измерив суммарные ЭДС различных сочетаний этих элементов, можно получить систему уравнений, решение которой дает значение ЭДС каждого элемента. Решая систему уравнений определим значение ЭДС каждого элемента. Искомые ЭДС: E1 = 4.0 В; Е2 = 4.1 В; Е3 = 4.З В; Е4 = 4.5 В. Пусть из эксперимента получено:
Эта система уравнений в матричной форме и ее решение имеют вид АХ = В; Х = А-1 В, где А - исходная матрица системы уравнений; X - вектор-столбец неизвестных; А-1 - матрица, обратная матрице А; B - вектор-столбец свободных членов. Искомые неизвестные ЭДС: E1 = 4.0 В; Е2 = 4.1 В; Е3 = 4.З В; Е4 = 4.5 В.
Совместные измерения - это проводимые одновременно измерения двух или нескольких разнородных величин для нахождения зависимости между ними. Примером совместных измерений является определение температурных коэффициентов и начального сопротивления для терморезисторного преобразователя. Зависимость сопротивления платиновой проволоки от температуры выражается формулой RT = R0 (1 + a٠∆T + b٠∆T 2), где RT - сопротивление терморезисторного преобразователя при повышении начальной температуры на ∆T; R0 - сопротивление преобразователя при начальной температуре; ∆T - превышение температуры преобразователя над начальной температурой; a - температурный коэффициент; b - температурный коэффициент. Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл. Тип элемента- записи - это подгруппа элементов данных, распознаваемая пользователем в пределах файла. Тип элемента данных – это уникальное или рекурсивное поле, распознаваемое пользователем. Количество функциональных указателей вычисляется по формуле: FP= Общее количество*(0,65+0,01*Fi), (1) Где Fi – коэффициент регулировки сложности (I=1..14). Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12). |