Атрибуты качества

Текстовая расшифровка пятого урока курса Введение в профессию аналитика.

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

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

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

Раньше был стандарт ИСО 9126, в котором хорошо описана модель разных точек зрения на качество программных продуктов. Но сейчас формально этот стандарт считается устаревшим, ему на смену пришел стандарт ИСО 25010, в котором эта модель немного расширена.

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

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

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

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

Удобство использования или, по-английски, usability. Здесь за удобством использования лежит целая отрасль, которая сейчас вовлекает в себя всё больше людей, потому что удобство использования, применительно к интернет-проектам, становится очень важным конкурентным преимуществом. Это, в первую очередь, удобство работы для пользователя. Удобство обучения использованию продукта. Внешняя привлекательность — атрибут качества, которого не было в эпоху автоматизированных систем. Тогда была так называемая «эргономика и техническая эстетика», но это на самом деле совсем не юзабилити.

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

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

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

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

В стандарте 25010 приведены немного другие картинки. Там выделена модель качества при использовании. То есть эффективность, производительность, удовлетворенность, свобода от риска и покрытие контекста.

И общая модель качества продукта, которая включает в себя те области, которые были в стандарте 9126: функциональная пригодность, производительность, совместимость, удобство использования, надёжность, сопровождаемость, переносимость. Здесь добавилась еще группа защищённости. Ее вынесли наконец-то в отдельный набор атрибутов. Раньше шли споры о том, к чему относится защита информации — к функциональной стороне продукта или к нефункциональной. Сейчас мы понимаем, что это свой набор атрибутов качества. Я бы отнёс его к нефункциональной стороне, поскольку он описывает не что делает продукт, и каких целей достигают пользователи, а, скорее, накладывает на них некоторые ограничения в процессе достижения этих целей.

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

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

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

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

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

Предыдущий урок: Функциональная и нефункциональная стороны программного продукта

Следующий урок: Какие виды требований важнее остальных?