Программная инженерия

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

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

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

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

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

350

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

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

Требования к характеристике способность к взаимодействию

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

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

351

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

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

Таблица 12.2

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

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

352

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

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

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

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

353

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

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

354

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

Требования к используемости ресурсов памяти и производительности вычислительных средств могут устанавливаться исходя, с одной стороны, из экономической целесообразности применения наиболее дешевой, с мини­ мальными ресурсами ЭВМ, загрузка которой будет в среднем не ниже 0,5. С другой стороны, высокая загрузка (выше 0,9) может приводить к неже­ лательной задержке или даже потере заданий при случайном, кратковре­ менном повышении их интенсивностей, что может негативно отразиться на функциональной пригодности. Таким образом, в данном примере раци­ ональная величина вероятности использования ресурсов ЭВМ в процессе нормального функционирования ПС должна находится в пределах 0,8.

Пример требований к качественным характеристикам ПС пред­ ставлен в таблице 12.3, которая базируется на мерах и шкалах таблицы 11.3 (лекция 11) с небольшими сокращениями наиболее неопределенных качественных атрибутов, которые выбираются и описываются экспертами в виде наборов свойств программ. Основная часть атрибутов качества в таблице 12.3 сведена к экономическим показателям трудоемкости и дли­ тельности, требуемых для реализации соответствующих характеристик.

Требования к практичности и ее субхарактеристикам — понятнос­ ти и простоты использования — зависят от назначения и функций ПС и могут качественно формализоваться заказчиками набором свойств, необ­ ходимых для удобной и комфортной эксплуатации программ. Количест­ венно простоту использования можно в некоторой степени характеризо­ вать требованиями ограничения средней длительности ввода типовых за­ даний и времени отклика на них, которое должно быть в несколько раз меньше. Требования к продолжительности изучения ПС, достаточной для эффективной эксплуатации сложной административной системы квалифи­ цированным специалистом, в данном примере могут составить около не­ дели или порядка 50 часов. Для коллектива из четырех человек-эксплуата­ ционников это потребует трудоемкости около 200 человеко-часов. Для обеспечения полноценного изучения процессов применения ПС этими спе­ циалистами может быть необходима эксплуатационная документация объе­ мом около 1000 страниц, а также желательны адекватные по содержанию электронные учебники. Малый объем эксплуатационной документации может снизить качество и полноту использования функций сложного ПС, а очень большой объем — также может ухудшить эксплуатацию из-за

355

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

трудности выделения и освоения наиболее существенных свойств и осо­ бенностей применения ПС из множества второстепенных деталей.

Требования к компонентам сопроволсдаемости количественно мож­ но установить для субхарактеристик изменяемости и тестируемости. Тре­ буемые значения зависят от четкости концепции и архитектуры ПС, от унифицированности внутренних, внешних и с пользователями интерфей­ сов, от качества технологической документации, а также от инструмен­ тальной оснащенности ЖЦ данного ПС и еще от некоторых факторов. Обобщенно это отражается на длительности и трудоемкости подготовки и реализации типовых модификаций, обусловленных необходимостью уст­ ранения дефектов и небольшими усовершенствованиями функций ПС. В рассматриваемом примере для подготовки и выполнения каждого измене­ ния (без учета затрат времени на обнаружение и локализацию дефекта) можно принять среднюю продолжительность в 5 часов и суммарную тру­ доемкость двух специалистов около 10 человеко-часов. Требования к про­ должительности тестирования таких изменений могут составить также до 5 часов, но трудоемкость может увеличиться до 20 человеко-часов, так как требуемый коллектив тестировщиков может возрасти до трех-четырех спе­ циалистов.

Выбор и установление требований к мобильности ПС в данном при­ мере сведены к трудоемкости и длительности процессов: адаптации к характеристикам пользователей и внешней среды, инсталляции версий ПС в среде пользователей и замены крупных компонентов версий ПС по тре­ бованиям заказчиков или конкретных пользователей. Наиболее простым и легко формализуемым из перечисленных процессов является инсталляция готовой версии ПС с комплектом документации без дополнительных из­ менений на платформе пользователя, которая может требовать до 5 часов работы двух специалистов (10 человеко-часов). Более сложный процесс включает адаптацию ПС по формализованным инструкциям к специфи­ ческой аппаратной и внешней среде конкретного пользователя, которая может потребовать вдвое большего времени и в несколько раз (в примере 5) большего числа специалистов. Еще более сложный и трудоемкий про­ цесс замены крупных компонентов ПС и перенос их на иную аппаратур­ ную и операционную платформу. Для этого процесса в примере требуется не менее 20 часов и коллектив около 5 человек (100 человеко-часов).

356

Л Е К Ц И Я 13

ВЕРИФИКАЦИЯ, ТЕСТИРОВАНИЕ И ОЦЕНИВАНИЕ КОРРЕКТНОСТИ ПРОГРАММНЫХ КОМПОНЕНТОВ

13.1. принципы верификации и тестирования программ

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

Назначение верификации ПС — последовательно проверить, что в реализованном комплексе программ (рис. 13.1):

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

—требования высокого уровня правильно переработаны в архитек­ туру ПС и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня;

358

13.1. принципы верификации и тестирования программ

Верификация соответствия спецификации требований к программному средству требованиям к информационной системе

f

Верификация соответствия архитектуры комплекса программ требованиям к программному средству

f

Верификация соответствия спецификаций требований

кфункциональным компонентам требованиям

кпрограммному средству

?

Верификация соответствия спецификаций требований

кпрограммным и информационным модулям требованиям

кфункциональным компонентам

^'

Верификация соответствия объектного кода программ спецификациям требований к модулям

Верификация соответствия спецификации требований к технологическому обеспечению жизненного цикла программ

требованиям к программному средству

Верификация соответствия спецификации требований

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

кпрограммному средству

Рис. 13.1

— спецификации требований к функциональным компонентам ПС, расположенным между компонентами высокого и низкого уровня, каж­ дый раз удовлетворяют требованиям более высокого уровня;

359