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

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

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

348

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

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

Таблица 12.1

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

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

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

349

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

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

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

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

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

350

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

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

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

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

351

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

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

Таблица 12.2

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

| Характеристики качества	Мера	Требуемое значение
Надежность
Завершенность:
— наработка на отказ при отсутствии рестарта.	Часы	10
Устойчивость:
— наработка на отказ при наличии автоматического рестарта;	Часы	50
— относительные ресурсы на обеспечение надежности и ре-
старта.	%	10
Восстанавливаемость:
— длительность восстановления.	Минуты	5
Доступность —готовность:
— относительное время работоспособного функционирования.	Вероятность	0,998
Эффективность
Временная эффективность:
— время отклика — получения результатов на типовое зада-
ние;	Секунды	5
— пропускная способность — число типовых заданий, ис-	Число в ми-
полняемых в единицу времени.	нуту	20
Используемость ресурсов:
— относительная величина использования ресурсов ЭВМ
при нормальном функционировании программного средства	Вероятность	0,8

Тактические цели выбора конструктивных характеристик качества стандарта ISO 9126:1-4 последовательно рассмотрены и иллюстрированы таблицами 12.2 и 12.3. Пример требований к основным количественным характеристикам качества ПС сложной административной

352

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

системы представлен в таблице 12.2. Все меры и шкалы для атрибутов характеристик выбраны в соответствии с их содержанием из таблицы 11.2 (лекция 11). Требования к атрибутам характеристики надежность могут быть выбраны с учетом следующих факторов. При отсутствии автоматического рестарта, за счет отладки и при наличии администратора, контролирующего работоспособность ПС, можно считать допустимой наработку на отказ порядка 10 часов. За счет программно-аппаратных механизмов автоматического рестарта эта наработка при проявлении отказов может быть повышена приблизительно в 5 раз, т.е. при 80% отказов возможно их автоматическое обнаружение и оперативное восстановление, вследствие чего наработка на отказ возрастет до 50 часов. По опыту, на обеспечение этого может потребоваться около 10% вычислительных ресурсов системы. Предполагается, что для оперативной работы пользователей административной системы допустимая длительность прерывания работы для полного восстановления нормального функционирования системы может составлять не более 5 минут. В результате при таких значениях атрибутов надежности коэффициент готовности — вероятность застать ПС в работоспособном состоянии — составит достаточно высокую величину 0,998.

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

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

353

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

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

Таблица 12.3 Пример требований к качественным характеристикам