[Перевод] Планируйте компромиссы: Вы не можете оптимизировать все атрибуты качества программного обеспечения
Важнейший аспект анализа требований заключается в понимании того, какие качественные характеристики наиболее важны — чтобы разработчики могли соответствующим образом учитывать эти характеристики.
Следующее приложение, которым я воспользуюсь, должно быть без ошибок: никаких 404 «страница не найдена» или экранов со справкой, которые не помещаются на странице, с которой я работаю. Приложение не должно занимать много памяти или замедлять работу моего компьютера, а по завершении работы оно должно высвободить всю использованную память. Приложение должно быть полностью безопасным, чтобы никто не мог украсть мои данные или выдать себя за меня. Оно должно мгновенно реагировать на любую команду и быть абсолютно надежным. Я не хочу видеть никаких сообщений типа «внутренняя ошибка сервера» или «приложение не отвечает». Пользовательский интерфейс должен быть спроектирован так, чтобы не позволять мне совершать ошибки. Должна быть возможность использовать это приложение на любом устройстве с мгновенной загрузкой и без задержек. В приложении должен быть предусмотрен импорт и экспорт любых данных из внешних источников. Ах да, чуть не забыл — это приложение должно быть еще и бесплатным.
Это было бы потрясающее приложение, правда? Конечно, так и есть! Вправе ли я такого ожидать? Конечно, нет!
Невозможно реализовать все характеристики и аспекты программной системы наилучшим образом, везде подобрав идеальные варианты. Приходится идти на неизбежные компромиссы между различными аспектами качества — развитие одного из них часто приводит к неизбежной деградации другого. Следовательно, при анализе требований особенно важно понимать, какие характеристики качества являются наиболее важными, чтобы проектировщики могли соответствующим образом их учитывать.
Параметры качества
Команды разработчиков ПО должны учитывать при изучении требований широкий набор атрибутов качества. Понятия «проектирование в расчёте на наилучшие характеристики» (design for excellence) оно же DfX, также относятся к атрибутам качества, где X — это интересующее вас свойство, которое проектировщики стремятся оптимизировать. Когда говорят о нефункциональных требованиях, обычно имеют в виду атрибуты, касающиеся качества.
Нефункциональные требования не реализуются непосредственно на уровне харда или софта. Напротив, они служат основой для производной функциональности, архитектурных решений или подходов к проектированию и реализации. Некоторые нефункциональные требования накладывают ограничения, сужающие выбор, доступный проектировщику или разработчику. Например, требования к совместимости могут ограничивать структуру продукта использованием определенных стандартных интерфейсов.
Я видел списки более чем из 50 атрибутов качества программного обеспечения, иерархически сгруппированных самым разным образом. Немного найдётся проектов, в которых пришлось бы учитывать такое множество атрибутов. В первом списке приведены некоторые атрибуты качества, которые следует учитывать каждой команде, когда становится известно, какой уровень качества необходимо поддерживать в данном продукте. Для изделий, оснащаемых встроенным программным обеспечением, действуют некоторые дополнительные атрибуты качества, например, те, что показаны во втором списке (Koopman 2010, Sas and Avgeriou 2020).
Некоторые важные атрибуты качества для программных систем
• Доступность — Могу ли я использовать систему, когда и где мне нужно?
• Соответствие стандартам — Соответствует ли система всем применимым стандартам по функциональности, безопасности, коммуникации, сертификации и интерфейсам?
• Эффективность — Экономно ли система использует вычислительные ресурсы?
• Возможность установки — Могу ли я легко установить, удалить и переустановить систему и обновления?
• Целостность — защищена ли система от неточности, искажения и потери данных?
• Интероперабельность — хорошо ли система взаимодействует с другими системами для обмена данными?
• Ремонтопригодность — Могут ли разработчики без труда изменять, исправлять и улучшать систему?
• Производительность — достаточно ли быстро система реагирует на действия пользователя и внешние события?
• Переносимость — Легко ли портировать систему на различные платформы?
• Надежность — Работает ли система без сбоев, когда должна?
• Возможность повторного использования — Могут ли разработчики повторно использовать элементы системы в других продуктах?
• Надежность — реагирует ли система на ошибочные входные данные и неожиданные условия эксплуатации?
• Масштабируемость — Может ли система легко расширяться, чтобы в неё можно было вместить больше пользователей, данных или транзакций?
• Безопасность — защищает ли система от атак вредоносных программ, злоумышленников, неавторизованных пользователей и кражи данных?
• Удобство использования — Легко ли пользователю научиться использовать систему для выполнения своих задач?
• Верифицируемость — Могут ли тестировщики определить, правильно ли было написано и внедрено программное обеспечение?
Некоторые дополнительные атрибуты качества для аппаратных компонентов, содержащих встроенное программное обеспечение
• Долговечность — будет ли продукт хорошо работать в обычных условиях эксплуатации?
• Расширяемость — Легко ли добавить к изделию новые функциональные модули, датчики или другое оборудование, не нарушая его функционирования?
• Обработка сбоев — обнаруживает ли изделие возникающие сбои, восстанавливается ли после них и регистрирует ли их?
• Изготовимость — Легко ли и экономично ли производить изделие?
• Использование ресурсов — сохраняет ли компонент достаточную пропускную способность при потребляемых ресурсах памяти, ширине полосы передачи данных, мощности, производительности процессора и т. д.?
• Удобство обслуживания — Удобно ли эффективно выполнять профилактическое и корректирующее обслуживание изделия?
• Бережливость — удаётся ли свести к продукт минимальное негативное воздействие на окружающую среду в течение своего жизненного цикла, начиная с добычи сырья и заканчивая производством, использованием и утилизацией?
• Возможность модернизации — Легко ли усовершенствовать изделие путем добавления или замены компонентов?
Одно свойство, которое не фигурирует ни в одной из этих таблиц, — стоимость. Как и в случае с функциональностью, проектировщики должны соизмерять ценность достижения некоторой желаемой цели качества с затратами на ее достижение. Например, все хотели бы, чтобы программное обеспечение, которое они используют, было доступно для использования все время, но достижение этой цели может обойтись дорого.
У одного из моих клиентов-консультантов была компьютерная система управления производством с требованием доступности 24 часа в сутки, 365 дней в году (366 в високосные годы), с нулевым временем простоя. Они выполнили это требование благодаря наличию резервных компьютерных систем. Они могли установить обновления программного обеспечения на автономную систему, протестировать ее, перевести систему в режим онлайн, а затем обновить вторую систему. Наличие двух независимых компьютерных систем было дорого, но это было дешевле, чем отказ от производства продукции, когда система управления не работала.
Определение атрибутов качества
Разработчикам программного и аппаратного обеспечения, а также пользователям необходимо знать, какие атрибуты качества наиболее важны, какие аспекты этих зачастую многомерных атрибутов имеют первостепенное значение и какие цели они преследуют. Недостаточно просто сказать: «Система должна быть надежной» или «Система должна быть удобной для пользователя». Бизнес-аналитик (БА), инженер по требованиям, владелец продукта или менеджер по продукту должны задавать вопросы во время разработки требований, чтобы понять, что заинтересованные стороны подразумевают под «надежностью» или «удобством для пользователя». Как мы сможем определить, является ли система надежной или достаточно удобной для пользователя? Каковы примеры того, что система не является надежной или удобной для пользователя?
Чем точнее БА может сформулировать ожидания заинтересованных сторон в отношении качества, тем проще разработчикам сделать правильный выбор и оценить, достигли ли они поставленной цели. Роксана Миллер (2009) приводит множество примеров четко сформулированных требований к атрибутам качества в различных категориях. Когда это возможно, излагайте цели в области качества измеримыми и проверяемыми способами, чтобы направлять проектные решения. Рассмотрите возможность использования Planguage, языка ключевых слов, изобретенного пионером программного обеспечения Томом Гилбом, который позволяет точно, количественно и измеримо специфицировать такие расплывчатые атрибуты, как «доступность» и «производительность» (Simmons 2001, Gilb 2005). Такая тщательная спецификация требований требует некоторого времени, но это время хорошо потрачено по сравнению с перестройкой продукта после того, как он не оправдал ожиданий заказчика.
Проектирование для качества
Разработчики могут оптимизировать свой подход к решению практически по любому параметру качества, в зависимости от того, что им сказали или что они считают наиболее важным. Без руководства один разработчик может оптимизировать решение по производительности, другой — по удобству использования, а третий — по переносимости между платформами доставки. В ходе изучения требований проекта необходимо определить, какие атрибуты важнее других, чтобы направить разработчиков в наиболее важное для успеха бизнеса русло. То есть вам нужно расставить приоритеты для нефункциональных требований так же, как и для функциональных.
Расстановка приоритетов необходима из-за компромиссов между определенными парами атрибутов качества. Повышение одного атрибута качества часто требует от разработчика компромисса в некоторых других областях (Wiegers and Beatty 2013). Вот несколько примеров конфликтов между атрибутами качества, которые требуют принятия решений о компромиссе:
• Многофакторная аутентификация (MFA) более безопасна, чем простой вход по паролю, но снижает удобство использования из-за дополнительных шагов (и, возможно, устройств).
• Продукт или компонент, предназначенный для многократного использования, может быть менее эффективным, чем если бы код данной возможности был оптимизирован для одного приложения. Однако при условии, что снижение производительности будет приемлемым, создание многократно используемого компонента может оказаться разумным.
• Оптимизация системы по производительности может ухудшить ее портируемость, если разработчики будут использовать специфические свойства операционной системы или языка, чтобы выжать из нее все возможное.
• Оптимизация одних аспектов сложных качественных характеристик может ухудшить другие. Например, в широкой области юзабилити разработка системы, которая должна быть простой для новых или случайных пользователей, может сделать ее менее эффективной для экспертов.
С другой стороны, некоторые пары атрибутов качества синергически связаны друг с другом. Проектирование системы, обеспечивающей высокую надежность, улучшит ряд других атрибутов:
• Доступность: Если система не дает сбоев, люди могут ею пользоваться.
• Целостность: Снижается риск потери или повреждения данных в результате сбоя системы.
• Надежность: Продукт с меньшей вероятностью выйдет из строя из-за неожиданных действий пользователя или условий окружающей среды.
• Безопасность: Если механизмы безопасности продукта работают надежно, никто не пострадает.
Взаимодействие атрибутов качества показывает, почему команда проекта должна на раннем этапе понять, что качество значит для ключевых заинтересованных сторон, и направить работу всех на достижение этих целей. Заинтересованные стороны, которые не работают с БА над формированием этого понимания, оказываются во власти проектировщиков, которые будут делать свои лучшие предположения. Если вы не изучите нефункциональные требования во время анализа и не укажете их точно, вы не сможете гарантировать, что дизайнеры встроят те свойства, которые ценят клиенты.
Архитектура и атрибуты качества
Команды разработчиков должны понимать, какие атрибуты требуют пристального внимания на ранних этапах, чтобы они могли сделать правильный выбор архитектурного проекта. Архитектура системы влияет на множество атрибутов, включая доступность, эффективность, функциональную совместимость, производительность, переносимость, надежность, безопасность, масштабируемость и защищенность. Поскольку часто приходится идти на компромиссы, если архитекторы не знают, каким атрибутам отдать предпочтение, они могут сделать выбор, который не приведет к желаемым результатам.
Откатываться на поздних этапах разработки или после выпуска и перестраивать архитектуру системы, чтобы устранить недостатки качества, очень дорого. Поэтапное создание систем без заблаговременного определения наиболее важных целей в области качества может привести к проблемам, которые будет трудно устранить, особенно если речь идет как об аппаратном, так и о программном обеспечении. Как это часто бывает в проектах по разработке программного обеспечения, если потратить немного больше времени, чтобы лучше понять цели в области качества, это может привести к менее дорогостоящим и более долговечным решениям.
При изучении требований основное внимание, естественно, уделяется функциональности. Именно это видят пользователи, когда используют приложение, и именно на это ориентируются дизайнеры, когда придумывают решения. Однако изучение многочисленных, часто противоречивых качественных характеристик продукта с самого начала закладывает прочный фундамент для удовлетворения потребностей клиентов и надежной разработки.
Карл Вигерс — автор книги «Жемчужины разработки. Чему мы научились за 50 лет создания ПО», из которой взята эта статья. Карл является главным консультантом компании Process Impact и автором многочисленных книг по разработке ПО, управлению проектами, проектированию и другим темам.
