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

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

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

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

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

Программного средства

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

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

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

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

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

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

VII. Задания для самостоятельной работы:

Напомнить обучаемым вопросы, изученные на занятии, подчеркнуть важность отработанной тематики.

Дать задание на самостоятельную подготовку, ответить на возможные вопросы обучаемых.

Задание 1.

Выполнить оценку качества программного средства своего варианта (варианты заданий получить у ведущего преподавателя по дисциплине):

1. Произвести анализ кода разрабатываемого программного продукта с применением программного средства IBM Rational Code Analyzer.

2. Продемонстрировать умения использовать возможности системы анализа кода и поиска дефектов Microsoft PREFix/PreFast.

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

Профессор кафедры №31 Ф.О. Федин