Билет 23

Билет сделал: Рудов И.А.

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

Формализации показателей качества программных средств по­священа группа нормативных документов. В международном стан­дарте ISO 9126:1991 при отборе минимума стандартизируемых показателей выдвигались и учитывались следующие принципы: ясность и измеряемость значений, отсутствие перекрытия между используемыми показателями, соответствие установившимся по­нятиям и терминологии, возможность последующего уточнения и детализации. Выделены характеристики, которые позволяют оценивать ПС с позиции пользователя, разработчика и управля­ющего проектом. На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. Основой регламентирования показателей качества систем является международный стандарт ISO 9126 «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». В этом стандарте описано многоуровневое распределение характеристик ПО. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.

Согласно этой модели, функциональность программного средства (functionality) – совокупность свойств ПС, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности качества наряду с ее надежностью как технической системы. Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Удобство использования программного средства (usability) – совокупность свойств ПС, характеризующая усилия, необходимые для его использования, и оценку результатов его использования заданным кругом пользователей ПС. Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствии с выделенными ресурсами, временем и другими обозначенными условиями. Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к именующемуся окружению. Портативность (Portability) – совокупность свойств ПС, характеризующая приспособленность для переноса из одной среды функционирования в другие.

Функциональная пригодность детализируется пригодностью для применения, точностью, защищенностью, способностью к взаи­модействию и согласованностью со стандартами и правилами проектирования.

Надежность рекомендуется характеризовать уровнем завер­шенности (отсутствия ошибок), устойчивостью к ошибкам и перезапускаемостью.

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

• Эффективность рекомендуется характеризовать ресурсной и временной экономичностью.

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

• Переносимость предлагается отражать адаптируемостью, структурированностью, замещаемостью и внедряемостью.

Характеристики и субхарактеристики в стандарте определе­ны очень кратко, без комментариев и рекомендаций по их приме­нению к конкретным системам и проектам.

Близким к описанному стандарту по идеологии, структуре и содержанию является ГОСТ 28195-89. На верхнем, первом, уровне выделено 6 показателей — факторов качества: надежность, кор­ректность, удобство применения, эффективность, универсаль­ность и сопровождаемость. Эти факторы детализируются в со­вокупности 19 критериями качества на втором уровне. Дальней­шая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла ПС.

В стандарте ГОСТ 28806-90 формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых тер­минов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в ГОСТ 28195-89.

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

Понятие корректной (правильной) программы может рассмат­риваться статически вне ее исполнения во времени. Корректность программы не определена вне области изменения исходных дан­ных, заданных требованиями спецификации, и не зависит от ди­намики функционирования программы в реальном времени. Сте­пень" некорректности программ определяется вероятностью по­падания реальных исходных данных в область, которая задана требованиями спецификации и технического задания (ТЗ), одна­ко не была проверена при тестировании и испытаниях. Значения этого показателя зависят от функциональной корректности при­меняемых компонентов и могут рассматриваться в зависимости от методов их достижения и оценивания: детерминированно, сто­хастически и в реальном времени. При анализе видов корректно­сти и способов их измерения, естественно, они связываются с видами и методами процесса тестирования и испытания программ.

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

Определение требований к ПО - есть исходным документом разработки ПО, т.е заданием, отражающим в абстрактной форме потребности пользователя.

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

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

Важной задачей при создании определения требований является установление контекста использования ПО, включающего связи между этим ПО, аппаратурой и людьми.

Известны три способа разработки определения требований к по :

• Управляемая пользователем разработка

• Контролируемая пользователем разработка

• Независимая от пользователя разработка.

В первом – требования определяются заказчиком.

Второй – требования контролирует разработчик и участник.

Третий способ – требования определяются самим разработчиком.

С точки зрения обеспечения надежности предпочтительней 2 способ разработки требований.

Модели функциональных точек программного продукта.

...SOON...