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

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

Сегодня мы увидим другой, не менее важный аспект: архитектурные особенности, или атрибуты качества, или системные возможности, или нефункциональные требования и сделайте краткий обзор наиболее важных из них. Эти качественные требования иногда называют -способностями после суффикса 𝕞𝕠𝕤𝕥 слов share (доступность, ремонтопригодность, масштабируемость и т. Д.).

Атрибуты функциональности и качества ортогональны

𝕎𝕙𝕪 𝕤𝕙𝕠𝕦𝕝𝕕 𝕨𝕖 𝕔𝕒𝕣𝕖…

Мой наименее предпочтительный термин - «нефункциональные требования» (NFR) - это совершенно неправильный термин: кто будет строить систему на основе требований, которые не являются функциональными? Эти требования относятся к качествам, которыми должна обладать система, и ограничениям, при которых она должна работать! Поэтому я предпочитаю термин "Атрибут качества" ( QA).

ЭТО. проекты обычно недофинансируются, и на этапе разработки главное место занимает их функциональность! Атрибуты качества - легкая цель для отмены приоритетов, но последствия их игнорирования напрямую приводят к проблемам с качеством и увеличению технического долга.

Однако этот выбор недальновиден: тестировщики могут оказать большее влияние на дизайн, а если мы ошибаемся, они окажут эффект посторонней помощи на доставка, так как они требуют дорогостоящих переделок. По моему опыту, системы перепроектированы не потому, что они функционально несовершенные (обычно вычисления и функциональные возможности часто идентичны), а потому, что они не масштабируются, их трудно поддерживать, они слишком медленные… и этот список можно продолжать (и продолжать)!

𝕌𝕟𝕒𝕞𝕓𝕚𝕘𝕦𝕠𝕦𝕤 𝕤𝕡𝕖𝕔𝕚𝕗𝕚𝕔𝕒𝕥𝕚𝕠𝕟

До сих пор мы определили термин «атрибут качества» в общих чертах. Вот более конкретное определение:

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

Я подчеркиваю важность того, чтобы QA было измеримым и тестируемым: Чтобы определить ощутимое и недвусмысленное QA, мы должны охватить эти шесть важных части:

→ Стимул: условие, которое необходимо учитывать при поступлении в систему.
→ Источник: объект, генерирующий стимул.
→ Среда : Обстоятельства, при которых возникает стимул, например нормальная работа, стрессовые условия, неисправность и т. д.
→ Артефакт: часть системы, которая стимулируется.
→ Ответ: деятельность системы, предпринимаемая как результат поступления стимула.
→ Измерение: насколько ответ должен удовлетворять требованию.

Например: «При нормальной работе получено непредвиденное внешнее сообщение. Сообщение регистрируется, и система продолжает работать без простоев. »

✏️ Если вы хотите узнать больше, в этом канадском университете есть сокращенная глава о том, как документировать QA.

𝕀𝕥’𝕤 𝕒 𝕓𝕒𝕝𝕒𝕟𝕔𝕚𝕟𝕘 𝕒𝕔𝕥…

В Википедии записано множество QA, и академические круги определили несколько таксономий на протяжении многих лет:

Точно так же есть по крайней мере пара стандартов ISO (о которых я знаю), которые пытаются классифицировать QA по разным категориям: ① ISO 25010 и ② ISO 9126 .

Все QA имеют решающее значение, но, как гласит старая пословица: мы не можем есть торт и есть его!

С одной стороны, затраты будут чрезмерными, а время выхода на рынок резко упадет, а с другой (что наиболее важно) некоторые QA имеют тенденцию оказывать негативное влияние на других. Например, чтобы максимизировать ремонтопригодность, нам, возможно, придется пожертвовать эффективностью; или повышенная надежность может отрицательно сказаться на производительности; или удобство использования обычно зависит от того, работает ли программное обеспечение на нескольких платформах (переносимость).

Здесь в игру вступает архитектура!

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

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

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

Производительность - это способность системы соответствовать требованиям по времени в рамках заданных ограничений, таких как скорость, точность, использование памяти и т. Д.
Она оценивается по следующим параметрам:

  • Пропускная способность: количество событий, выполненных в течение заданного периода времени.
  • Задержка: время, необходимое для ответа на определенные события.
  • Емкость: количество обработанных событий при сохранении требований к пропускной способности и задержке.

Для повышения производительности системы можно использовать несколько стратегий, например:

◽ Кэширование
◽ Увеличение аппаратных ресурсов: память, процессоры, сети
◽ Балансировка нагрузки
◽ Введение параллелизма
◽ Разделение / репликация данных

Производительность является определяющим фактором в архитектуре системы и часто ставит под угрозу достижения других QA. Это часто связано с масштабируемостью, то есть с увеличением работоспособности системы при хорошей производительности. Давайте посмотрим, что это значит:

𝟚 𐩑 Масштабируемость

Масштабируемость позволяет системе изящно реагировать на предъявляемые к ней требования и обрабатывать возросшую рабочую нагрузку, не влияя на производительность или ее способность расширять архитектуру для размещения большего количества пользователей, процессов, данных и т. Д.
Задача состоит в том, чтобы оценить характер запроса, который будет предъявлен к системе, а также компоненты, которые будут подчеркнуты. При предварительном проектировании мы часто делаем упор на неправильные области и пытаемся оптимизировать, не проверяя ожидаемое поведение системы.

Есть два вида масштабируемости:

  • Вертикальная масштабируемость (масштабирование) означает покупку оборудования большего, например добавление дополнительной памяти / ЦП / жесткого диска к существующему серверу.
  • Горизонтальная масштабируемость (горизонтальное масштабирование) означает добавление нескольких наборов аппаратных ресурсов для разделения нагрузки и ответа на одни и те же запросы - например, добавление еще одного сервера в кластер серверов. Это, как правило, более рентабельно, поскольку позволяет нам начать с малого, а затем со временем реагировать на запросы системы.

При планировании масштабирования необходимо учитывать следующие факторы:

◽ Количество пользователей
◽ Объем данных
◽ ЦП, память, операции с интенсивным вводом-выводом
◽ Параллелизм
◽ Асинхронный, а не синхронный
◽ Без сохранения состояния
◽ Длительные операции (пакетное планирование в непиковое время)

При проектировании масштабируемости чаще всего упускается из виду необходимость:

  • Механизм мониторинга: важно следить за состоянием системы! Предупреждения должны быть доступны группам эксплуатации и разработки, когда использование ресурса превышает 80%, поэтому принимаются меры по исправлению положения.
  • Стресс-тестирование: крайне важно довести систему до предела, чтобы выяснить, какие операции являются интенсивными, где находятся точки останова, и определить, как система выйдет из строя под нагрузкой (мы ищем 'изящный отказ').

𝟛 𐩑 Наличие

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

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

  • когда услуга недоступна, каков процесс восстановления: автоматический или ручной; как долго длится простой; можно ли выполнить SLA (соглашение об уровне обслуживания)?
  • каков план смягчения последствий, чтобы избежать сбоя в будущем после выполнения RCA (анализа первопричин)?
  • какие уведомления требуются при возникновении сбоя?
  • какова устойчивость системы, т.е. как часто она дает сбой?

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

Давайте посмотрим на некоторые методы, которые повышают доступность системы:

Обнаружение:

◽ временная метка для упорядочивания событий
◽ пульс для периодического мониторинга системы
◽ контрольные суммы для проверки данных
◽ ведение журнала исключений
◽ тайм-ауты, когда время ожидания превышает заранее установленный предел
◽ самостоятельно -тесты на корректность
◽ Обнаружение машинного обучения

Восстановление:

◽ обработка исключений в среде программирования
◽ откат, т.е. возврат к предыдущему хорошему состоянию
◽ повторная попытка в случае временной ошибки (например, сбой сети)
◽ повторная попытка с альтернативным действием (например, если рыночная цена для T недоступен, попробуйте получить T-1)
◽ перезапуск службы

Профилактика:

◽ предотвращение исключений
◽ транзакции
◽ корректное завершение работы и повторное создание экземпляров
◽ расширенное покрытие тестирования

𝟜 𐩑 Расширяемость

Расширяемость - это понятие того, насколько легко система может приспособиться к будущим изменениям за счет гибкой архитектуры, дизайна или реализации. Расширения могут осуществляться за счет добавления новых функций или модификации существующих функций. Быстрый выход на рынок всегда является ключевым для любой организации, поскольку он влияет на ее способность увеличивать доходы, связанные с рассматриваемой системой.

Следует помнить о некоторых критических факторах:

  • высокая когезия и низкое сцепление
  • применять принципы SOLID (особенно Open-Closed и Dependency Inversion) и шаблоны проектирования, которые позволяют изменять поведение системы, не затрагивая архитектуру
    [Эта статья объясняет, как принципы SOLID также применяются к архитектуре, а не только программированию]
  • разделение проблем, например логическое разделение приложения на разные уровни (клиент, уровень представления, уровни бизнес-логики)
  • использовать абстракции для проектирования тех системных границ, которые могут быть подвержены изменениям
  • модульность пользовательского интерфейса, чтобы различные модули стали доступны с минимальным воздействием
  • подключаемая архитектура
  • использовать механизмы рабочего процесса с динамическими правилами
  • предоставлять функциональные возможности слоев, подсистем и модулей через API
  • развертывание в один клик для быстрого вывода на рынок
  • высокий тестовый охват, подтверждающий отсутствие побочных эффектов

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

✏️ Пожалуйста, не путайте расширяемость с модифицируемостью: модифицируемость означает, что можно изменить программное обеспечение, тогда как расширяемость означает, что изменение было запланировано и будет (почти) легким!

𝟝 𐩑 Поддержка

Возможность поддержки - это способность системы предоставлять полезную информацию для выявления и решения проблем. Основные требования здесь определены с точки зрения:

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

Не стоит недооценивать ценность этого QA: большая часть ИТ-бюджета организации тратится на обслуживание критически важного программного обеспечения, поэтому чем более удобны в обслуживании приложения, тем ниже их совокупная стоимость владения (общая стоимость владения). .

𝟞 𐩑 Юзабилити

Удобство использования учитывает факторы, определяющие способность программного обеспечения обеспечивать улучшенное взаимодействие с пользователем. Пользовательские интерфейсы должны разрабатываться с учетом предполагаемого конечного пользователя, чтобы они были интуитивно понятными, последовательными и простыми в освоении и эксплуатации.

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

  • асинхронные API для длительных процессов или фоновых задач, чтобы элементы управления пользовательского интерфейса не зависали
  • использование соответствующих компонентов / виджетов с использованием соответствующих шаблонов проектирования пользовательского интерфейса
  • обратимые действия (отменить / отменить)
  • автозаполнение
  • персонализация и сохранение пользовательских предпочтений
  • признание, а не отзыв
  • механизм оповещения и обратной связи (особенно о неисправностях)
  • устранение лишних щелчков
  • эстетика и внешний вид пользовательского интерфейса
  • поддержка различных средств доставки: мобильный, компьютер, планшет
  • помощь и документация

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

Это большая ошибка! Архитектурного разделения презентации и приложения недостаточно для решения всех проблем удобства использования, которые могут проникнуть глубоко в приложение за пределы уровня представления.

𝔼𝕡𝕚𝕝𝕠𝕘𝕦𝕖

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

Качество - это не действие; это привычка - Аристотель

Часто решение в пользу одного атрибута качества влияет на другой, поэтому найти оптимальное решение из набора конкурирующих и меняющихся требований непросто.

Но именно это делает программную архитектуру настоящей инженерной наукой!

Вот несколько полезных ресурсов, если вы хотите узнать больше по некоторым из затронутых нами тем:

Использованная литература:

Спасибо за прочтение!

Я регулярно пишу о технологиях и данных на Medium - если вы хотите читать мои будущие сообщения, то, пожалуйста, Подписывайтесь на меня!