Пример распределения приоритетов требований к характеристикам качества программного средства

Таблица 12.1

Пример выбора и формирования требований к характеристикам качества программного средства

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

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

12.2. Пример выбора и формирования требований к характеристикам качества...

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

Характеристика	Субхарактеристика	Приоритет требований
Функциональность	Функциональная пригодность Корректность — правильность Способность к взаимодействию Защищенность	Высокий Высокий Средний Высокий
I Надежность	Завершенность Устойчивость к дефектам Восстанавливаемость Доступность — готовность	Низкий Средний Высокий Высокий
Эффективность	Временная эффективность Используемость ресурсов	Высокий Средний
Практичность	Понятность Простота использования Изучаемость Привлекательность	Средний Низкий Средний Низкий
Сопровождаемость	Анализируемость Изменяемость Тестируемость	Средний Средний Средний
Мобильность	Адаптируемость Простота установки Замещаемость	Средний Средний Низкий

Стандартизированные в ISO 9126:1-4 характеристики качества ПС различаются по степени влияния на системную эффективность — функциональную пригодность их применения по прямому назначению. Вследствие реальной ограниченности ресурсов, которые доступны в жизненном цикле ПС, их необходимо выделять с учетом влияния на эту эффективность. Для этого целесообразно в процессе системного анализа присваивать и учитывать уровень приоритета требований к каждой субхарактеристике. В таблице 12.1 представлен пример возможного распределения приоритетов требований заказчика к субхарактеристикам ПС для принятого

Лекция 12. Выбор характеристик качества в проектах программных средств

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

Выбор требований к мерам характеристик качества, естественно, должен начинаться с определения необходимых свойств и значений группы показателей, отражающих функциональные возможности ПС, куда по стандарту ISO 9126:1-4 входят субхарактеристики: функциональная пригодность, корректность, способность к взаимодействию и защищенность — безопасность. Пример содержания и возможных диапазонов изменений атрибутов качества этих субхарактеристик был представлен выше в таблице 11.1 (см. лекцию 11). Для конкретного проекта ПС перечень атрибутов качества следует адаптировать и уточнять с учетом его назначения и функций.

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

Требования к субхарактеристике корректность могут представляться в виде описания двух основных свойств, которым должны соответство-

12.2. Пример выбора и формирования требований к характеристикам качества...

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

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

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

Лекция 12. Выбор характеристик качества в проектах программных средств

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