Архитектура программного обеспечения
Атрибуты качества программного обеспечения, нефункциональные требования и лучшая архитектура программного обеспечения
Прочтите обновленную версию этой статьи.
При проектировании архитектуры программного обеспечения для нового продукта часто бывает сложно оценить доступные варианты дизайна и выбрать оптимальный. Это часто происходит из-за того, что разработчикам непонятно, какие критерии им следует использовать при принятии проектных решений и почему.
Некоторые разработчики полагаются на свой предыдущий инженерный опыт и личные предпочтения в методах, технологиях, инструментах и шаблонах. Проблема в том, что у каждого члена команды разработчиков разные предпочтения, мнения и предположения. В результате может быть трудно достичь консенсуса в команде и согласовать некоторые решения. Споры по поводу субъективных мнений и предпочтений могут не только повредить отношениям между коллегами, но также не обязательно приведут к созданию архитектуры программного обеспечения, оптимизированной для достижения бизнес-целей.
Что могут сделать разработчики, чтобы решения по архитектурному проектированию были более объективными? Один из вариантов:
- начать с исследования нефункциональных требований к продукту,
- понять, для каких атрибутов качества программного обеспечения его следует оптимизировать,
- затем используйте эти знания, чтобы выбрать варианты архитектуры, которые позволят их продукту удовлетворить все бизнес-требования.
Прежде чем мы продолжим, позвольте мне сначала прояснить, что такое нефункциональные требования и атрибуты качества.
Нефункциональные требования - это критерии оценки того, как программная система должна работать, а не того, что она должна делать. Примером может служить требование, чтобы время ответа конечной точки веб-API было менее 200 мс.
Когда мы говорим, что программный продукт должен быть «безопасным», «высокодоступным», «переносимым», «масштабируемым» и т. Д., Мы говорим о его атрибутах качества.
Другими словами, программный продукт должен иметь определенные атрибуты качества, чтобы соответствовать определенным нефункциональным требованиям.
Пара примеров.
Пример 1: продукт должен обеспечивать потоковую передачу видеоконтента 0,5–1 млн одновременных пользователей 24/7 по всему миру. Эти нефункциональные требования побуждают разработчиков рассматривать варианты дизайна, которые приводят к высокомасштабируемой, высокодоступной и отказоустойчивой архитектуре. Кроме того, требование быть доступным по всему миру означает, что продукт должен поддерживать интернационализацию, чтобы быть локализованным для различных стран.
Пример 2: продукт должен быть доступен в рабочее время нескольким сотням пользователей в одной стране. Эти требования предполагают, что продукт не обязательно должен быть особенно масштабируемым. Вероятно, он даже не обязательно должен быть постоянно доступен в нерабочее время.
Нефункциональные требования должны быть измеримыми, измеримыми и включать такие цели, как «0,5–1 млн», «24 часа в сутки, 7 дней в неделю», «несколько сотен», «часы работы» в примерах. Должен быть способ проверить, выполнено ли требование. Разработчики могут использовать эти цели в качестве ориентиров, чтобы определить, соответствует ли их продукт требованиям.
Для разработчиков крайне важно знать все нефункциональные требования, включая все предположения и неявные ожидания заинтересованных сторон, если они хотят создать успешный продукт. Если такие предположения обнаружатся позже, изменение архитектуры может оказаться дорогостоящим.
Как только у разработчиков появятся нефункциональные требования, они смогут понять, для каких качественных характеристик им следует оптимизировать архитектуру. Например, в примере 1 логично оптимизировать архитектуру продукта для масштабируемости (чтобы он мог достичь желаемой емкости) и доступности (чтобы он мог быть доступен 24/7).
Разработчики также могут захотеть узнать, для каких атрибутов качества не нужно оптимизировать архитектуру продукта. Затем, если потребуется, они будут знать, какими качествами пожертвовать, чтобы соответствовать требованиям, важным для бизнеса. Хорошие кандидаты на такие атрибуты либо не имеют связанных нефункциональных требований, либо легко выполняются.
Разработчикам было бы удобно иметь исчерпывающий список качественных атрибутов, чтобы проверить, имеет ли каждый атрибут связанные нефункциональные требования.
Я часто использую список из 31 атрибута качества (сгруппированных по 8 характеристикам), определенных в международном стандарте «ISO / IEC 25010» в разделе, который представляет модель качества программного продукта:
- функциональная пригодность: функциональная полнота, функциональная правильность, функциональная пригодность;
- эффективность производительности: поведение во времени, использование ресурсов, емкость;
- надежность: зрелость, доступность, отказоустойчивость, восстанавливаемость;
- удобство использования: уместность, узнаваемость, обучаемость, работоспособность, защита от ошибок пользователя, эстетика пользовательского интерфейса, доступность;
- безопасность: конфиденциальность, целостность, неотрекаемость, подотчетность, подлинность;
- совместимость: сосуществование, взаимодействие;
- ремонтопригодность: модульность, возможность повторного использования, анализируемость, модифицируемость, тестируемость;
- портативность: адаптируемость, возможность установки, заменяемость.
Я не включаю здесь определения. Их можно найти либо в бесплатном фрагменте официального стандарта, либо на этой странице.
Я знаю, что большинство из этих характеристик кажутся очень абстрактными и бесполезными для разработчика, пытающегося просто создать часть программного обеспечения. Но давайте рассмотрим пример, чтобы лучше понять, как использовать этот список и какие знания о нашем продукте мы можем извлечь из него.
Пример 3. Представьте себе команду разработчиков Ruby on Rails и React, создающую глобальный онлайн-рынок для фрилансеров для продажи таких услуг, как веб-разработка, цифровой маркетинг, SEO, копирайтинг и т. д. Давайте рассмотрим некоторые характеристики (качество атрибуты) из модели, чтобы определить нефункциональные требования и выбрать те, для которых архитектура продукта должна быть оптимизирована.
Для краткости рассмотрим только подхарактеристики «ремонтопригодности».
1. «Модульность», будучи отличным качеством, похоже, не имеет связанных нефункциональных требований для онлайн-рынка.
2. «Возможность повторного использования» - еще одно отличное качество, которое, похоже, не имеет связанных нефункциональных требований в данном случае.
3. «Анализируемость» важна. Разработчики хотели бы диагностировать продукт в случае сбоев, собирать и анализировать системные метрики (например, время отклика, время загрузки страницы, использование ЦП и памяти и т. Д.), Искать и анализировать журналы и т. Д. Люди, работающие с продуктом, будут заинтересованы в наличии возможностей для сбора таких показателей, как средняя продолжительность посещения, коэффициент конверсии, процент пользователей, использующих определенные функции. Примеры нефункциональных требований:
- все исключения должны регистрироваться в сторонней системе, храниться в течение 12 месяцев и быть доступными для поиска,
- журналы должны собираться в сторонней системе, храниться в течение пяти лет и быть доступными для поиска;
- время загрузки домашней страницы должно быть менее 500 мс;
- каждый щелчок пользователя в веб-приложении должен отслеживаться сторонним инструментом; и т.п.
Очевидно, что архитектура онлайн-рынка должна быть оптимизирована для «анализируемости».
4. «Возможность модификации» тоже важна. Особенно в долгосрочной перспективе, когда от этого зависит, по сути, стоимость разработки и поддержки продукта. Связанные нефункциональные требования могут выглядеть так:
- обновить все сторонние библиотеки и фреймворки до последней мажорной версии не позднее, чем через 30 дней с момента их выпуска;
- иметь всю инфраструктуру в коде, чтобы упростить внесение изменений в процессы подготовки и развертывания.
5. Нефункциональные требования, связанные с «тестируемостью», могут выглядеть следующим образом:
- иметь 98% покрытие юнит-тестами для внутреннего и внешнего кода;
- пройти приемочные испытания для всех сценариев, связанных с воронкой конверсии;
- иметь проверки безопасности и сканирование уязвимостей, которые предотвращают отправку кода с известными недостатками безопасности в производство.
Если бы мне пришлось разрабатывать архитектуру программного обеспечения для этого онлайн-рынка, то среди его пяти характеристик ремонтопригодности я бы оптимизировал (в этом порядке):
1. тестируемость: чтобы разработчики могли действовать быстро и своевременно обнаруживать дефекты;
2. анализируемость: чтобы разработчики знали, как работают программные компоненты продукта.
3. Возможность модификации: чтобы мы не загоняли себя в угол, а могли поддерживать и развивать то, что мы создали.
Я надеюсь, что этот пример продемонстрировал, как после просмотра списка разработчики могут определить, для каких качественных характеристик им следует оптимизировать архитектуру. В результате им будет проще сравнить варианты дизайна и быстрее выбрать оптимальный. Кроме того, разработчики будут принимать решения на основе тщательного анализа требований, а не на основе своих личных предпочтений и мнений.
Обратите внимание, нет необходимости ограничивать список только 31 атрибутом из модели качества. Могут быть полезны и другие атрибуты качества, например, из этой статьи в Википедии.
