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

Доступность

Концептуальная целостность

Возможность взаимодействия

Удобство и простота обслуживания

Управляемость

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

Надежность

Возможность повторного использования

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

Безопасность

Обеспеченность технической поддержкой

Тестируемость

Взаимодействие с пользователем / удобство и простота использования

Доступность

Доступность определяет ту долю времени, когда система функциональна и работает. Она может быть измерена в процентном соотношении как доля общего времени простоя системы за заданный период. На доступность оказывают влияние ошибки системы, проблемы инфраструктуры, злонамеренные атаки и нагрузка системы. Основные проблемы доступности:

Физический уровень, такой как сервер базы данных или сервер приложений, может дать сбой или не отвечать, приводя к общему сбою системы. Продумайте реализацию поддержки обработки отказов для уровней системы. Например, с помощью механизмов балансировки сетевой нагрузки (Network Load Balancing) для Веб-серверов распределите нагрузку и не допустите направление запросов на нефункционирующий сервер. Также используйте технологию RAID для смягчения негативного влияния на систему при сбое диска. Рассмотрите возможность размещения резервного узла в другой точке планеты на случай стихийных бедствий, таких как землетрясения или торнадо.

Атаки типа отказ в обслуживании (Denial of Service, DoS), которые препятствуют доступу к системе авторизованных пользователей, могут быть причиной прерывания операций, если система не в состоянии своевременно справиться с большими нагрузками, что часто происходит из-за недостаточности времени на обработку либо из-за конфигурации сети и перегрузки системы запросами. Чтобы максимально

сократить негативное влияние атак типа DoS, сократите поверхность атаки, выявляйте злонамеренное поведение, используйте инструментарий приложения для предоставления непредусмотренного поведения и реализуйте исчерпывающую проверку данных. Устойчивость системы помогут повысить шаблоны Circuit Breaker (Прерыватель) и Bulkhead (Перемычка).

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

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

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

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

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

Концептуальная целостность

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

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

Несогласованные или плохо управляемые процессы разработки. Проведите оценку эффективности применения методик Управления жизненным циклом приложения

(Application Lifecycle Management, ALM) и используйте испытанные и протестированные инструменты и методики разработки.

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

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

Недостаточное использование стандартов проектирования и написания кода. Используйте опубликованные рекомендации по стандартам проектирования и написания кода и выполняйте анализ кода в процессе разработки, что обеспечит следование рекомендациям.

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

Возможность взаимодействия

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

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

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

Недостаточное следование стандартам. Ознакомьтесь с формальными и реально используемыми стандартами предметной области, в которой работаете, и используйте один из них, а не создавайте что-то новое и особое.

Удобство и простота обслуживания

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

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

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

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

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

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