Файл: Основные положения метрологии программных продуктов.pptx

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-менеджеров.

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

Кроме того, числовые показатели способны помочь в планировании затрат ресурсов на дальнейшее развитие разрабатываемого продукта.

Классификация измерений

Классификация измерений

Все измерения делятся по следующим признакам:









- прямые,

- косвенные,

- совокупные,

- совместные.

по способу получения измерений

по числу измерений







- однократные,

- многократные.

по точности измерений







- равноточные,

- неравноточные.

по практическому назначению измерений









- технические,

- метрологические.

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







- статические,

- динамические.

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







- абсолютные,

- относительные.

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

По планируемой точности измерения делят на технические и метрологические.

К техническим следует относить измерения, которые выполняют с заранее установленной точностью, т.е. с соблюдением такого условия, что погрешность измерения  не должна превышать заданного значения []:

  [], где [] – допустимая погрешность измерения.

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

---