Надежность АСОИУ (1088455), страница 50
Текст из файла (страница 50)
д.Проектно-ориентированный подход к оценке качества программногообеспеченияРассмотренные метрики, универсальные по своему характеру, не даютполного численного описания уровня качества конкретного программногоизделия или комплекса, область применения которых может быть весьмаразнообразна. Эти метрики не учитывают семантическую составляющуюпрограммного продукта. Они сконструированы без учета особенностейтребуемой предметной области, операционного окружения, методологииразработки, не учитывают качество обрабатываемых данных и взаимодействиеданных с потоком вычислений и т.
д.Поэтому для обеспечения полноты измерения качества ПИ используютпроектно-ориентированные или структурные метрики качества, которые можноприменять на ранних стадиях проектирования для анализа целей проекта,области применения, ограничений и других характеристик проектируемогопрограммного изделия.Термин «проектно-ориентированный» в данном контексте означает, чтометрики разрабатываются в виде некоего стандарта качества проекта на егоранних стадиях и представляют собой правила или нормы, которым долженудовлетворять промежуточный или конечный программный продукт.
Терминструктурный означает, что метрики разрабатываются структурным методомсверху вниз для обеспечения целостности и полноты оценки качества ПО.Измерение качества в соответствии с данными метриками состоит ввычислении отклонения фактических характеристик ПО от установленныхнорм и правил. Методология создания метрик качества указанным способомрегламентирована стандартом IEEE 1061.Как упоминалось выше, не существует единственной метрики, которая быдала адекватную оценку качества многообразного программного обеспечения.Измерения качества позволяют получить спектр проектно-зависимых метрик,которые могут служить руководящей основой для принятия решений впроцессе формирования заказа, разработки, внедрения и последующегосопровождения программного обеспечения.
Следует отметить, что некоторыеметрики качества являются изначально неочевидной категорией.Методология создания метрик качества состоит из нескольких этапов.На первом этапе (верхний уровень иерархии) определяется нетехническийуровень(предназначенныйдляменеджеров,пользователей,заказчика):формирование требований качества; выбор свойств (атрибутов); установкаприоритетов и связей с требованиями; присвоение атрибутов факторамкачества, которые отражают представление заказчика о качестве; установкаизмерений для факторов качества; определение допустимых разбросовзначений показателей качества.На втором этапе (средний уровень иерархии) определяется техническийуровень (предназначенный для аналитиков, конструкторов, разработчиков):осуществляется декомпозиция факторов качества в измеряемые характеристикипрограммного обеспечения (субфакторы).Натретьемэтапе(нижнийуровеньиерархии)осуществляетсядекомпозиция субфакторов в метрики, которые могут быть примененынепосредственно к программному продукту или процессу разработки.
Этиметрики применяются как непрямые меры (индикаторы) прямых измеренийфакторов качества на верхних уровнях иерархии процесса разработки. Инымисловами, это уровень разработанных правил и норм, которым долженудовлетворять программный продукт или вычислительный процесс с тем,чтобы были выполнены факторы качества.Иллюстрация этапов представлена на рис. 3.2.Рис. 3.2. Этапы проектно-ориентированного подходаДля первого этапа выбраны следующие факторы качества программнойсистемы:• переносимость — обеспечивается включением в программу модулей,используемых для переноса программных изделий с одной аппаратнойплатформы на другую;• надежность — ожидаемая степень корректного выполнения программной системой требуемых функций;• тестируемость — методы, средства и инструменты, используемые длятестирования функций программы.Для оценки (или измерения) факторов качества могут использоватьсяколичественные показатели.
Например, переносимость можно оценить кактрудоемкость, т. е. количество человеко-часов, требуемое для организациипереноса программы с платформы Хна платформу У (допустимый порог — 1чел./ч на 1 К строк исходного кода). Надежность — среднее время наработки наотказ (допустимый порог— 120 операционных дней). Тестируемость такжеоценивается как трудоемкость — количество человеко-часов, требуемое дляполного тестирования 90% всех модулей (допустимый порог — 10 чел./ ч на 1К строк исходного кода).В результате декомпозиции приведенных выше факторов (второй этап)можно получить следующие субфакторы:• точность — правильность вычислений и контроля;• сложность — трудность разработки и модификации;• совместимость—использование унифицированной технологии проектирования и разработки на протяжении всего цикла разработки;• устойчивость к ошибкам— степень ущерба от возникающихошибок;• универсальность — функциональная широта потенциального использования;• аппаратная независимость — степень применимости программы надругом аппаратном обеспечении;• оснащенность средствами контроля — степень контроля программысобственными средствами контроля и идентификации возникающихошибок;• модульность—степень функциональной независимости программных компонентов;• удобочитаемость—уровень смыслового наполнения комментирования, соответствие стандартам кодирования и именования;• простота — легкость понимания программы;• системная независимость — степень независимости от нестандартных характеристик системного окружения и ограничений.Для приведенных субфакторов необходимо определить правила (нормы).При этом целесообразно использовать стандартные метрики для проведенияизмерений.Важнымсвойствомприведенныхиерархическихметрикявляетсявозможность предсказания уровня качества, которое может быть выведено наоснове измерения непрямых метрик.
Измерение на верхнем уровне иерархииобычно производится расчетом взвешенной суммы метрик нижнего уровня.Преимущества методологии качества IEEE основаны на возможностиуправления качеством на всех этапах разработки программного обеспечения.При этом эффективность управления будет зависеть от уровня квалификацииразработчика, осуществляющего проектирование иерархической структурыметрик качества с учетом целей и особенностей конкретного проектаразработки программного обеспечения.IEEE- подход позволяет управлять качеством на всех этапах жизненногоцикла разработки программного обеспечения, поскольку правила и нормы длявсех факторов качества являются не только метриками, но и инструкциями,выполнение которых может планироваться до исполнения и контролироватьсяв процессе работы.Какчастныйслучайпроектно-ориентированногоподходаможнорассматривать подход к измерению качества на основе сопровожденияпродукта.Однимизглавныхпутейповышениякачестваявляетсяанализпрактического опыта использования данного продукта или процесса ипоследующего применения полученных данных для его совершенствования.Речь идет о так называемой парадигме совершенствования качества (QualityImprovement Paradigm — QIP)Парадигма совершенствования качества предполагает систематическийподход к организации сбора практического материала, систематизациинакопленной информации и подготовке результирующих выводов дляулучшения качества.Наиболееприменимымспособомреализациипарадигмыявляетсяиерархический подход к формированию информации: от целей к вытекающимиз них вопросам, от вопросов — к метрикам.Другой составляющей рассматриваемого метода является стандартныйнаучный подход к выработке решений: формулирование проблемы, сборданных и планирование, формирование гипотез, подготовка к проверке,выполнение проверки, анализ результатов, формулировка решения.Итогом процесса является накопление знаний о качестве в соответствующей базе знаний.
База знаний о качестве находящегося насопровождении программного продукта служит источником для формированиятребований к новой версии продукта и принятия решений, основанных наколичественном анализе, о развитии существующих подсистем, созданииновых версий, снятии с эксплуатации и т. п.Обычно для конкретного проекта программного обеспечения разрабатывается свое множество метрик, которое отражает назначение иособенности условий функционирования программного продукта.
Рассмотримнекоторые примеры подобных метрик, используемых в настоящее время.Цена качества. Понятие цены качества рассматривается как стоимость всоставе продукта, которая может быть сэкономлена, если все исполнителиработают безупречно.Фактическионаотражает стоимостьдоработки и увеличенную стоимость сопровождения.Цена качества может быть разделена на два типа.процессовСогласованная цена — это сумма, затраченная на достижение заданногокачества программного продукта. Она подразделяется на цену предупрежденияи цену контроля. Затраты предупреждения связаны с предупреждениемдефектовдоихпредупрежденияпоявления.являютсяПриразработкезатратынаПОобучениепримеромколлективазатратбазовымметодологиям, переход на современные технологии разработки, использованиеавтоматизированных средств проектирования и разработки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
