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

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

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

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

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

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

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

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

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

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

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

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

Требования к используемости ресурсов памяти и производительности вычислительных средств могут устанавливаться исходя, с одной стороны, из экономической целесообразности применения наиболее дешевой, с минимальными ресурсами ЭВМ, загрузка которой будет в среднем не ниже 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 человеко-часов).

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

Дата добавления: 2014-01-13