Метрика тестирования программного обеспечения — это критерий для отслеживания эффективности усилий по обеспечению качества. Сначала вы устанавливаете показатели успеха на этапе планирования. Затем сравниваете их с полученной метрикой после завершения процесса.
Однако многие специалисты по контролю качества программного обеспечения и тестированию склонны фокусироваться на том, как будут выполняться тесты, а не на фактической информации, получаемой в результате тестирования. Под этим я подразумеваю, что тестировщики часто сосредотачиваются на простом удовлетворении от завершения всех тестов. Но всегда ли это хорошо? У вас может быть 100% процент прохождения тестов со всеми зелеными индикаторами на приборной панели, и все равно возможно, что ваши тесты недостаточно сильны.
В статье Алекса Хусара (Alex Husar) будут обсуждаться пять метрик тестирования программного обеспечения, которые могут помочь специалистам по контролю качества в оценке их успеха.
Характеристики «хорошей» метрики тестирования
Давайте поговорим о функциях, которые метрика должна иметь в идеале.
№108: Производительность кода — это важнейший критерий качества?
Соответствие бизнес-целям
Критические KPI должны отражать основную миссию и цель бизнеса; например, ежемесячный рост выручки или количество новых пользователей. Каждая компания выбирает свои показатели на основе того, чего они намерены достичь с помощью своего продукта. Хотя может показаться привлекательным преуспеть во всех тестах, сосредоточение внимания на неправильных целях может быть обманчивым. Это может повлиять на работу приложения и всю сложную систему, такую как headless commerce architecture.
Позволяет расти
Каждая метрика должна допускать возможность улучшения. Что, если вы достигли 100-процентного уровня успеха? Целью может быть сохранение этого показателя на этом уровне или его дальнейшее улучшение.
Поощряет разработку стратегии
Когда показатель дает команде цель, он также мотивирует их задавать вопросы для разработки плана. Предположим, вам нужно увеличить доход. Подумайте, требуются ли продукту новые функции, чтобы стимулировать больше покупок. Необходимо ли создавать новый канал приобретения? Запустил ли конкурент какие-либо новые продукты или функции, которые привлекают новых покупателей?
Отслеживаемая и понятная
Хорошие метрики просты для понимания и отслеживания. В противном случае, как люди, собирающие их, будут принимать обоснованные решения? Сотрудники должны понимать, что они могут сделать для улучшения результата.
Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных»!
Три совета по выбору и измерению метрик тестирования программного обеспечения
1. Начните с вопросов
Ваши вопросы должны охватывать три темы:
Критерии качества релиза
- Что вы измеряете
- Стратегии и инструменты для его измерения
- Причины для отслеживания
Чтобы избежать анализа бесполезных метрик, обратите внимание на процесс определения метрик. Иногда небольшое количество ошибок в бэклоге означает, что ваша команда QA (quality assurance) выполняет свою работу. Однако, когда вы разделите эти ошибки на проблемы с высоким/средним/низким приоритетом, вы сможете лучше увидеть общее качество программы и внести необходимые коррективы.
2. Не пренебрегайте автоматизацией при расчете метрик QA
Автоматизация экономит время на ручной сбор данных и помогает обеспечить постоянную актуальность ваших показателей. Предположим, вы используете Jira. Настройте запрос Jira Query Language (JQL) на вашей странице Confluence, если вам нужны данные о критических ошибках каждый спринт. Они будут часто обновляться. Или вы можете использовать другие инструменты, основываясь на предпочитаемой системе управления тестированием/отслеживания задач.
3. Собирайте комментарии и постепенно улучшайте метрики
После того, как вы настроили и собрали все метрики, начинаются процессы обратной связи и улучшения. Обратите внимание на обратную связь, чтобы повысить эффективность и ясность ваших метрик и отчетов.
Пять показателей тестирования программного обеспечения, которые необходимо отслеживать
Теперь давайте рассмотрим несколько конкретных примеров. Обратите внимание, что различные аспекты качества имеют разное значение в зависимости от обстоятельств.
1. Удовлетворенность пользователей
Здесь вы захотите увидеть реакцию клиента на продукт. Вы используете опросы об удовлетворенности пользователей и тикеты поддержки, которые выявляют ошибки. Если вы будете отслеживать эти показатели качества и работать над их улучшением, бизнес будет расти, поскольку вы увидите больше довольных и возвращающихся клиентов. Если что-то не так, вам придется провести причинно-следственный анализ проблемы и устранить препятствия.
2. Метрики процесса
Это внутренние измерения, которые оказывают значительное влияние на качество вашего продукта. Например, вы можете отслеживать время выполнения, время, которое проходит между постановкой задачи и развертыванием кода и продуктивом.
Еще одна метрика, которую вы можете использовать, — это время цикла. Оно означает время на создание функции после получения разрешения на начало работы над ней. Наконец, вы можете отслеживать время, необходимое для решения трудностей. Это может означать скорость решения тикетов или ошибок после того, как о них было сообщено.
Поскольку эти показатели бывает трудно измерить, еще одним методом повышения эффективности процесса является обнаружение того, где незавершенная работа начинает скапливаться в очереди. Это может выявить узкое место, устранение которого может помочь вашим командам стать более продуктивными.
3. Метрики покрытия
Еще одним показателем качества тестирования является покрытие тестов. Оно информирует нас о количестве протестированного кода. Это способ убедиться в том, что ваши тесты проверяют код и насколько они работают. В этом случае лучше использовать стратегию «сверху вниз». Первым шагом является анализ покрытия модулей.
Затем вы рассматриваете функциональность и, наконец, покрытие данных в каждой функциональности. Это означает, сколько различных комбинаций потенциальных входов данных вы покрываете тестами.
В эту группу входят такие метрики, как:
- Процент покрытия требований
- Покрытие модульных тестов
- Покрытие ручных или исследовательских тестов
- Тестовые случаи по категориям требований
- Покрытие тестов пользовательского интерфейса
- Покрытие интеграционных и API тестов
4. Метрики качества кода
Оценка качества кода означает разделение ценности кода на две категории: Хороший и плохой. Единого понятия качества не существует, потому что практически каждый разработчик сам определяет, что такое хороший код. Как вы можете оценить качество кода? Такие инструменты, как SonarQube, позволяют определить, сколько технического долга имеется в системе. Вам необходимо классифицировать проблемы и уязвимости, упорядочить их по приоритетности и выбрать, на чем вы собираетесь сосредоточиться.
5. Метрики ошибок или инцидентов
Каждая проблема отличается по степени серьезности, поэтому не стоит придавать всем проблемам одинаковое значение. Некоторые проблемы — это просто предложения по улучшению. Определите, какие компоненты качества важнее других для вашей компании. При анализе показателей, которые вы будете использовать, не ограничивайтесь только количеством дефектов.
Что можно извлечь из отчетов о происшествиях? Эти результаты могут включать в себя:
- Общее количество ошибок
- Открытые дефекты
- Закрытые дефекты
- Время закрытия каждого отчета об инциденте
- Изменения с момента последнего релиза
Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных»!
Правила измерения метрик тестирования программного обеспечения
Оценка метрик в тестировании программного обеспечения и оценка их успешности может быть разочаровывающей и неясной. Вот несколько советов и предложений, которые вы можете использовать:
- Соотносите свои метрики с целями проекта, процесса и продукта. Помните, что одного показателя недостаточно для полного представления о качестве программного обеспечения.
- Отслеживайте прогресс (или регресс) в течение времени. Оптимизируйте процесс сбора данных с помощью автоматизации, храните данные в ресурсах для совместной работы, таких как Wiki/Confluence, и регулярно анализируйте результаты.
- Сообщайте статистику заказчику и команде, чтобы продемонстрировать свой прогресс. Отчеты должны быть простыми для понимания, поэтому делайте их полезными и удобными для пользователя.
- Проверяйте достоверность метрик. Об отслеживании неактуальных метрик и отображении неточных данных не может быть и речи.
Измерение является важным видом деятельности в тестировании программного обеспечения, например определение количества успешных тестов в сравнении с количеством неудачных. Вся полученная информация поступает к заинтересованным сторонам. В результате они могут принимать обоснованные решения, например, когда выпускать приложение.
Как вы можете контролировать свою деятельность по тестированию? Вам необходимо определить соответствующие метрики тестирования программного обеспечения. Выбрать правильные метрики тестирования может быть непросто. Часто команды выбирают метрики, которые не синхронизированы с общим бизнесом.
К чему может привести отсутствие адекватных показателей? Заинтересованные стороны не могут измерить прогресс, определить возможности для развития или проконтролировать, какие тактики тестирования оказывают наиболее положительное влияние. При всем этом команды QA должны отслеживать индивидуальный прогресс, уровень квалификации и успехи, а также качество кода, ошибки и покрытие.
Также по теме:
- 3 совета по улучшению управления лицензиями программного обеспечения
- Цепочки поставки программного обеспечения
- Простые уловки, как ускорить процесс разработки программного обеспечения
- Автоматизация тестирования: что можно, а что не нужно
- Медленное движение «влево» в автоматизации тестирования
Источник: cleverics.ru
10 ключевых показателей качества программного обеспечения и почему они важны
Процесс разработки ПО проходит наиболее успешно, когда вы создаете удобный интерфейс и выпускаете качественный продукт. Существует несколько типов показателей качества программного обеспечения, которые касаются различных аспектов приложения, включая его функции, функции и процесс разработки программы. Если вы заинтересованы в работе в области разработки программного обеспечения, изучение различных показателей программного обеспечения — отличный способ создавать усовершенствованные продукты, отвечающие ожиданиям клиентов. В этой статье мы объясним основы использования метрик качества программного обеспечения и поделимся несколькими вариантами метрик для использования в вашей работе.
Что такое показатели качества программного обеспечения?
Показатели качества программного обеспечения — это аспекты программного обеспечения, которые описывают его удобство использования, функциональность и эффективность. Показатели качества программного обеспечения также могут относиться к качеству проекта разработки программного обеспечения, например к процедурам, связанным с проектированием и тестированием программной платформы.
Команды разработчиков программного обеспечения обычно имеют набор показателей, которые они используют на этапе обеспечения качества разработки, чтобы убедиться, что их программы соответствуют всем требованиям пользователей, прежде чем выпускать продукт на рынок. Они также используют показатели качества для сбора отзывов клиентов об ошибках, ошибках и проблемах с интерфейсом, которые они могут применить к обновлениям программного обеспечения и новым выпускам.
Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)
Почему важны показатели качества программного обеспечения?
Метрики качества программного обеспечения являются ключевым аспектом процесса разработки и обслуживания программного обеспечения. У них есть несколько ключевых преимуществ:
- Обеспечение функциональности: внедрение метрик программного обеспечения в качестве стандартов обеспечения качества обеспечивает правильную работу программ.
- Удовлетворение потребностей клиентов. Показатели качества программного обеспечения помогают гарантировать, что все функции соответствуют ожиданиям и потребностям клиентов.
- Ограничение ошибок. Измеряя работу программы с помощью ряда показателей, вы можете ограничить количество ошибок, возникающих после выпуска приложения.
- Улучшение процессов. Сбор данных о качестве программных продуктов и процессов дает вам возможность разрабатывать передовые методы разработки.
- Привлечение новых пользователей. Когда вы используете аналитику для изучения качества вашего программного обеспечения, вы можете улучшить его аспекты, такие как интерфейс, функции и дизайн, чтобы привлечь клиентов.
10 типов метрик качества программного обеспечения
Вот 10 примеров типов показателей, которые вы можете использовать для повышения качества своих программных продуктов:
1. Надежность
Пользователи полагаются на надежность и согласованность программного обеспечения, поэтому они могут использовать его функции для получения тех же результатов. Это предполагает наличие программы, которая ведет себя предсказуемым образом в зависимости от действий пользователя. Это также требует наличия надежных методов обслуживания для быстрого решения проблем. Вот несколько конкретных показателей, которые поддерживают надежное качество программного обеспечения:
- Частота отказов
- Доступность системы
- Частота сбоев
2. Функциональность
Чтобы программное обеспечение соответствовало ожиданиям пользователей, все функции должны работать с минимальными ошибками и ошибками. Основным аспектом процесса тестирования при разработке и обслуживании программного обеспечения является выявление и устранение ошибок для улучшения функциональности. Это включает в себя использование метрик, связанных с функциональностью, для отслеживания распространенных типов ошибок и того, какие функции или аспекты кода вызывают у пользователей больше всего проблем. Примеры показателей качества программных функций включают в себя:
- Вероятность отказов
- Количество ошибок
- Серьезность ошибок
3. Характеристики кода
- Количество строк кода
- Ясность кода
- Соблюдение правил кодирования
4. Доступность интерфейса
Программные интерфейсы должны быть доступны и удобны в использовании, чтобы произвести впечатление на клиентов. Это включает в себя привлекательный дизайн и интуитивно понятную панель навигации, которую легко понять людям. Многие программы также имеют обучающий режим, который обучает пользователей работе с основными функциями программы, поэтому очень важно, чтобы приложение было как можно более доступным.
5. Производительность системы
Другим аспектом качества программного обеспечения, который необходимо измерить, является общая производительность системы и объем ввода или действий пользователя, которые она может обработать. Это наиболее важно для программных приложений, содержащих сложный код и предъявляющих сложные системные требования, таких как компьютерные игры или программные службы баз данных. Когда пользователи вводят сложные команды, важно, чтобы программное обеспечение соответствовало этим требованиям.
6. Управление дефектами
Хотя целью любого разработчика программного обеспечения является полное устранение ошибок, ошибки и дефекты являются нормальной частью любого приложения. Это означает, что текущее обслуживание и устранение дефектов важны для поддержания качества программного обеспечения. Чтобы надлежащим образом устранять дефекты, вы можете отслеживать частоту ошибок, время, необходимое для их устранения, и успех ваших решений с помощью следующих показателей качества:
- Среднее время обнаружения сбоев и ошибок
- Среднее время наработки на отказ системы
- Среднее время устранения ошибок
- Резерв билетов
- Коэффициент успешного разрешения
7. Документация
Поскольку проектирование программного обеспечения требует регулярных обновлений и совместной работы нескольких специалистов по разработке программного обеспечения, вы также можете контролировать качество своей документации. В разработке программного обеспечения документация включает в себя объяснение изменений в коде, описание обновлений и внутренние заметки для общения с другими разработчиками. Каждая команда разработчиков программного обеспечения имеет свои собственные методы документирования, поэтому отслеживание документации обычно предполагает соблюдение этих правил.
8. Адаптивность для разных платформ
Многие разработчики программного обеспечения разрабатывают приложения, которые работают на нескольких платформах или интегрируются с другими программами. Чтобы убедиться, что эта функция работает, вы можете сравнить производительность программного обеспечения на каждом канале, чтобы определить, насколько хорошо работает интеграция. Например, вы можете сравнить уровень дефектов, количество ошибок и другие ключевые показатели для нескольких типов операционных систем, чтобы измерить адаптивность программного обеспечения.
9. Охрана и безопасность
Построение отношений с пользователями программного обеспечения, чтобы они доверяли вам свои данные, имеет важное значение для разработчиков программного обеспечения. Вы можете повысить уверенность в безопасности своего приложения, записывая сведения о том, как вы защищаете пользовательские данные, и отслеживая показатели, касающиеся целостности ваших существующих мер безопасности. Эти индикаторы безопасности для программного обеспечения могут показать ваше управление качеством для безопасности пользовательских данных:
- Время исправить уязвимости
- Уровни нечеловеческого трафика
- Частота проверки на вирусы
10. Общее удовлетворение
Наконец, получение качественных отзывов от клиентов об их общем опыте использования вашего программного обеспечения может дать вам целостное представление о качестве вашего приложения. Если вы попросите потребителей оценить качество своего опыта или дать оценку конкретным функциям программного обеспечения, это может сообщить вам о сильных и слабых сторонах вашего продукта. Вы можете собирать эту информацию, проводя опросы по электронной почте, на своем веб-сайте или даже интегрируя систему опросов в свое программное обеспечение.
Источник: buom.ru
Реферат: Основные характеристики качества программного обеспечения.
Программные системы (ПС) – это сложные системы, поэтому к ним следует применять общие методы исследования и проектирования сложных систем. Поэтому, ПС характеризуется, прежде всего конкретными функциональными показателями качества или показателями назначения, номенклатура и значение которых определяются целями и областью применения программ. Наиболее общее качество программ – эффективность использования – отражает, прежде всего, назначение и выполняемые функции. Функциональные показатели характеризуют эффект от использования программ, с учетом затрат на их создание.
ПС характеризуются также конструктивными показателями качества, номенклатура которых почти не зависит от назначения и области использования программ. Эти показатели характеризуют любые программы и позволяют сопоставлять по показателям качества программы разного назначения.
Оцениваемые характеристики ПС группируются по трем этапам жизненного цикла программ: проектирование, эксплуатация, сопровождение. Всего различают четыре этапа жизненного цикла программ (рис.12): системный анализ, в ходе которого определяется назначение и основные функциональные характеристики, оцениваются затраты и возможная эффективность применения; проектирование программ включает разработку структуры ПС, программирование отладку модулей, испытание и внедрение для постоянной эксплуатации программ; эксплуатация программ; сопровождение программ состоит в развитии функциональных возможностей, повышение эксплуатационных характеристик системы, тиражирование программного комплекса. Показатели качества ПС и методы их определения, группируются по последним трем этапам (рис.13). Это не единственная модель показателей качества ПС, в работах [8,1] предложены другие системы показателей, но приводимая на рис.13 модель обладает упорядоченностью и позволяет ранжировать показатели.
Показатели качества представляют собой измеряемые характеристики в виде некоторой функции. Описать единый показатель невозможно, так как в зависимости от этапа, в жизненном цикле ПС, от
Рис.12. Схема жизненного цикла программных систем
Рис.13. Схема показателей качества программных систем
задач использования и целей анализа, от характера внешних условий и т.д. доминирующим становится один или несколько показателей.
Для измерения и численной оценки показателей качества применяют метрики. В зависимости от особенностей показателя качества, применяются различные виды метрик.
Первый вид метрик характеризуют числовые параметры, которые измеряются относительными величинами или реально измеряемыми физическими показателями, например, их временем наработки на отказ, число маршрутов в программе и т.д. Второй вид метрик (порядковая шкала) позволяет ранжировать некоторые характеристики путем сравнения с опорными значениями. Математические преобразования с такими показателями более ограничены, чем при первом виде метрик. Третий вид метрик (номинальная или категорийная шкала) характеризует только наличие рассматриваемого свойства, например, наличие гибкости.
Все конструктивные показатели качества ПС делятся на основные и вспомогательные (влияющие на значение основных) показатели. Основные показатели показаны на рис.13, а вспомогательные в табл.2.
Такое деление предназначено для выделения минимального числа показателей, которые чаще всего целесообразно анализировать, как наиболее важные характеристики качества. Это деление условно и поэтому показатели можно переводить из основных во вспомогательные и наоборот.
4.3. Показатели качества этапа проектирования программных систем
Сложность проектирования конкретизуется и становится измеримым при установлении связи этого понятия с конкретными ресурсами, необходимыми для решения задачи. В табл.3, приведены различные показатели сложности программ, из которых этап проектирования характеризуют п.1-3. Эти показатели выбраны по тому, что они являются имитирующими ресурсами для проектирования любого изделия, в том числе и ПС.
Сложность проектирования ПС часто называют статистической сложностью. Её целесообразно анализировать на базе трех специфических компонент: сложность программных модулей, сложность структуры комплекса, сложность структуры данных (рис.14).
Сложность программных модулей оценивается сложностью внутренней структуры и функций программных модулей и интегрально по внешним статистическим характеристикам модулей. Эти показания с различных позиций связывают значения сложности с трудоемкостью разработки модуля.
Таблица 2.Вспомогательные показатели качества.
| Этапы жизненного цикла | ||
| Проектирование | Эксплуатация | Сопровождение |
| 1. Структурная упорядоченность программ и данных | 1. Корректность постановки задач | 1. Структурная упорядоченность ПС и данных |
| 2. Степень стандартизации структуры модулей и переменных | 2. Полнота и точность спецификаций | 2. Степень стандартизации структуры модулей и переменных |
| 3. Документированность ПС | 3. Уровень языков программирования | 3. Документированность для модификаций |
| 4. Методическая обеспеченность технологии проектирования | 4. Полнота тестирования программ | 4. Уровень языков программирования |
| 5. Степень комплексной автоматизации технологии проектирования | 5. Степень помехозащищенности программ | 5. Степень комплексной автоматизации технологии проектирования |
| 6. Уровень языков спецификаций, программирования и отладки | 6. Документированность для эксплуатации | 6. Обеспеченность контроля изменений версий и распространения копий |
| 7. Квалификация специалистов и методы организации работ |
Структурная сложность модулей определятся числом взаимодействующих компонент, числом связей между компонентами и сложностью их взаимодействия. Разнообразие поведения модуля и связей входных и результирующих данных в значительной степени определяются набором маршрутов, по которым исполняется модуль, т.е. сложность программного модуля связана не с размером программы по числу команд, а с числом отдельных маршрутов его исполнения.
Маршруты возможной обработки данных должны быть достаточно полно проверены при создании программы и тем самым определяют сложность её разработки. Проверка в логических системах должна осуществляться по всем маршрутам по конечным и промежуточным решениям. Для этого строится граф программы, по которому формируется полное множество маршрутов. Пример определения полного множества маршрутов показан на рис.15.
Замечание: вследствие быстрого роста структурной сложности при увеличении числа условных вершин целесообразно ограничивать размер программных модулей.
Статическая сложность модулей основывается на определении внешних измеряемых характеристик программных модулей. Первая характеристика – это интеллектуальная сложность создаваемого программного модуля.
где V – объем текста программы в битах; V* — потенциальный объем описания программ – это объем наиболее компактного текста программы для фиксированного алгоритма, написанного на языке самого высокого уровня.
Выражение (1) может быть представлено в виде
где l — показатель уровня языка используемой системы программирования (см. табл.4).
Вторая характеристика статистической сложности модулей – это трудоемкость разработки программы.
где S – интенсивность анализа и принятия решений программистом, измеряемая числом символов, которые различает программист в секунду (S≈18).
Сложность структуры ПС и связей между модулями по передаче управления и по обмену информацией определяется степенью взаимодействия модулей и регулярностью структуры межмодульных связей. Следует отметить, что программный модуль – это замкнутая компонента ПС. Автономность модулей достигается путем максимального ослабления взаимосвязей между модулями при одновременном усилии
Таблица 3. Значения показателей сложности программных систем
| Показатель сложности | Уровень сложности | ||||
| простой | средней сложности | сложный | сверх-сложный | ||
| 1. | Трудоемкость создания, чел. — годы | 0,1 | 1-10 | 103-104 | |
| 2. | Длительность разработки, годы | 0,1-0,5 | 1-2 | 2-5 | 3-10 |
| 3. | Количество разрабатывающих специалистов, чел | 1-2 | 3-10 | 10-100 | 100-1000 |
| 4. | Длинна программы, операторов | 103 | 104 | 105 | 106-107 |
| 5. | Количество модулей, шт. | 1-3 | 10-102 | 103 | 104-105 |
| 6. | Количество обрабатываемых переменных, типов | 102-103 | 104-105 | 106-108 | |
| 7. | Длительность решения варианта задачи, ч. | 10-2-10-1 | 102-103 | ||
| Допустимое время отклика, с. | 106-104 | 103-102 | 10-0,1 | 10-2-10-4 |
Таблица 4. Значения показателя уровня языка l
| Язык программирования | Уровень языка l |
| PL-1 | 1,53 |
| Алгол | 1,21 |
| Фортран | 1,14 |
| Ассемблер | 0,88 |
Рис.14. Виды сложности проектирования.
Рис.15. Пример графа программы (а) и полного множества маршрутов в этом графе (б)
связей компонент программы внутри модуля. Благодаря этому существенно снижается сложность структуры ПС и взаимодействия модулей за счет некоторого повышения сложности внутренней структуры модулей. В результате возникает оптимизационная задача минимизация совокупной сложности ПС с учетом внутренней сложности модулей и сложности модульных связей.
Наименьшая структурная сложность ПС достигается при минимальных межмодульных связей как по управлению, так и по информации. Степень связей по управлению определяется числом вариантов возможных вызовов данного модуля от других модулей. Сцепление модулей по информации производится путем обращения к массивам данных, которые используются двумя большим числом модулей, и обращение к каждой единицы информации следует рассматривать как внешнюю информационную связь. При расчете сложности ПС следует учитывать все связи по управлению и информации. Сложность управляющих связей компонент ПС определяется по формуле:
где М – множество индексов модулей ПС; — переменная, учитывающая связь i-го модуля с j-ым; — переменная, учитывающая связь j-го модуля с i-ым; и могут принимать либо значения 1, если связь есть, либо 0, если связи нет.
Следует отметить, что при таком определении сложности каждая управляющая связь учитывается дважды: в вызывающем и в вызываемом модуле.
Полное количество информационных связей в ПС равно:
где G – множество индексов информационных единиц (переменные, которые передаются в модуль как формальные параметры, также являются информационными единицами); — переменная, учитывающая использование k-ой информационной единице в i-ом модуле; — переменная, учитывающая формирование k-ой инфор-мационной единице в i-ом модуле:
Управляющие и информационные связи, описываются матрицами связей.
Статистические характеристики сложности ПС позволяют не учитывать детали структуры комплексов программ и особенности межмодульных связей. За основную единицу, характеризующую сложность ПС, принято число модулей.
Сложность структуры данных определяется количеством и структурой переменных и информационных единиц, регулярностью их размещения в массивах и сложностью доступа к этим переменным.
Корректность программ и степень адекватности их функциональных возможностей, поставленным целям и техническим заданиям является, важнейшим критерием в процессе разработки и испытаний ПС. Понятие корректности или правильности, подразумевает соответствие проверяемой ПС эталону, которому должна она соответствовать. Эти показатели, определяются техническим заданием на ПС и спецификациям на ее компоненты. Различают следующие виды корректности ПС:
• корректность текстов программ, синтаксическая и семантическая. Корректность текстов определяется степенью соответствия исходных программ формализованным правилам этих языков. Многие некорректности этих типов выявляются автоматически в процессе трансляции исходных текстов программ;
• корректность программных модулей структурная и функциональная, которая в свою очередь делится на детерминированную и стохастическую. Структурная корректность модулей заключается в соответствии их структуры общим правилам структурного программирования и корректным правилам оформления и внутреннего построения программных модулей. Функциональная корректность модулей определяется корректностью обработки исходных данных и получения результатов. В зависимости от функциональных задач корректность модуля может оцениваться детерминировано по полностью определенным наборам эталонных значений или стохастически при задании эталонов распределениями случайных величин;
• корректность данных структурная и функциональная (иначе, корректность значений). Структурная корректность данных определяется правилами их структурирования и упорядочивания. Эти правила могут быть достаточно полно формализованы без учета конкретных особенностей функционирования программ. Функциональная корректность данных связана в основном с конкретизацией их содержания в процессе исполнения программ, а так же при подготовке данных;
• корректность ПС структурная и функциональная. Структурная корректность определяется правилами структурного, модульного построения ПС и общими правилами организации межмодульных связей. Проверка структурной корректности может быть в значительной мере проверена автоматически.
Функциональная корректность ПС трудно формализуется вследствие большого количества возможных эталонных значений и распределений. Для программ реального времени различают детерминированную, стохастическую и динамическую корректность. Детерминированная корректность характеризует соответствие исходных и результирующих данных исполняемых программ эталонным значениям. Стохастическая корректность характеризуется соответствием распределений результирующих случайных величин заданным эталонным распределениям при соответствующих распределениях исходных данных. Динамическая корректность характеризует соответствие изменяющихся во времени результатов исполнения программ эталонными данными.
Метрики корректности программных модулей весьма разнообразны и довольно полно представлены в [8].
Трудоемкость разработки ПС зависит от квалификации специалистов, технологии проектирования, степени автоматизации разработки и испытаний. При измерении трудоемкости могут применятся обычные экономические показатели.
Источник: ronl.org