Методологические основы

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

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

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

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

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

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

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

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

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

Таблица 12.2