ЛЕКЦИЯ 4 1. Надежность и качество программных средств

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

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

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

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

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

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

Модель надежности ПО - математическая модель, построенная для оценки зависимости надежности ПО от некоторых определенных параметров. Модели надежности ПО

Модели надежности программных средств (МНПС) подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели).

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

Аналитические модели представлены двумя группами: динамические модели и статические. В динамических МНПС поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем, а учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных (по области данных).

Аналитическое моделирование надежности ПС включает четыре шага: 1)определение предположений, связанных с процедурой тестирования ПС; 2)разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования; 3)выбор параметров моделей с использованием полученных данных; 4)применение модели расчет количественных показателей надежности по модели.

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

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

В момент, когда проводится оценка надежности, после тестирования, на которое потрачено определенное время t, зафиксировано m отказов и выявлено n ошибок. Тогда из соотношения n = B · m(1) можно определить коэффициент уменьшения числа ошибок В как число, характеризующее количество устраненных ошибок, приходящихся на один отказ.

В модели Муса различают два вида времени: 1) суммарное время функционирования τ, которое учитывает чистое время тестирования до контрольного момента, когда проводится оценка надежности; 2) оперативное время t время выполнения программы, планируемое от контрольного момента и далее при условии, что дальнейшего устранения ошибок не будет (время безотказной работы в процессе эксплуатации).

Для суммарного времени функционирования τ предполагается: интенсивность отказов пропорциональна числу неустраненных ошибок; скорость изменения числа устраненных ошибок, измеряемая относительно суммарного времени функционирования, пропорциональна интенсивности отказов.

Один из основных показателей надежности, который рассчитывается по модели Муса, средняя наработка на отказ. Этот показатель определяется как математическое ожидание временного интервала между последовательными отказами и связан с надежностью:, где t время работы до отказа. Если интенсивность отказов постоянна (т.е. когда длительность интервалов между последовательными отказами имеет экспоненциальное распределение), то средняя наработка на отказ обратно пропорциональна интенсивности отказов.

Статические модели надежности Статические модели принципиально отличаются от динамических прежде всего тем, что в них не учитывается время появления ошибок в процессе тестирования и не используется никаких предположений о поведении функции риска λ(t). Эти модели строятся на твердом статистическом фундаменте.

Модель Нельсона Данная модель при расчете надежности ПС учитывает вероятность выбора определенного тестового набора для очередного выполнения программы. Предполагается, что область данных, необходимых для выполнения тестирования программного средства, разделяется на k взаимоисключающих подобластей Z i, i = 1,2,..., k. Пусть Р i вероятность того, что набор данных Z i будет выбран для очередного выполнения программы.

Предполагая, что к моменту оценки надежности было выполнено N i прогонов программы на Z i наборе данных и из них n i количество прогонов закончилось отказом, надежность ПС в этом случае равна: (1)

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

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

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

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

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

Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE Стандарт содержит рекомендации по оценке и выбору инструментальных средств, поддерживающих процессы жизненного цикла программных средств, включая процессы управления проектами, процессы разработки и процессы, следующие за разработкой, а также интегральные процессы жизненного цикла ПС. Для оценки и выбора инструментальной среды и CASE- средств стандартом рекомендуется использовать определенные стандартом наборы правил и критериев. Группы критериев в стандарте выделены и сформированы с учетом общих требований стандарта ISO 9126:1991 по оценке качества программных продуктов.

Качество программного обеспечения Определение в соответствии со стандартом ISO 8402:1994: Качество совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности.

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

Современная техника управления качеством (например, концепция Total Quality Management (TQM)) базируется именно на управлении качеством. На современном этапе уже недостаточно иметь только методы оценки качества произведенного и используемого программного средства (выходной контроль), необходимо иметь возможность планировать качество, измерять его на всех этапах жизненного цикла программного средства и корректировать процесс производства программного обеспечения для улучшения качества.

Международные стандарты серии ISO 9000 регламентируют создание системы управления качеством. Однако они являются общими, лишь рекомендательными. Каждая компания, производящая программное обеспечение и желающая внедрить у себя действенную систему управления качеством на основе стандартов ISO 9000-й серии, должна учесть специфику своей отрасли и разработать систему показателей качества, которая бы отражала реальное влияние факторов качества на программный продукт.

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

Для измерения некоторых показателей качества могут служить: тестирование, тестирование пользователем (так называемое β-тестирование), информация от пользователя о найденных проблемах, получаемая от службы технической поддержки.

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

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

К административным можно отнести следующие мероприятия: 1. Проведение обучения персонала, переподготовки. 2. Тщательное документирование всех изменений в структуре ПС. Для этого используются средства поддержки версионности. 3. Назначение ответственных лиц за каждую доработку программного средства. 4. Уделение внимания текущему контролю качества и заключительному контролю качества.

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

5. Организация отдела тестирования как самостоятельного подразделения. 6. Проведение совместных аттестаций с пользователем. 7. Обращение внимания на уровень и простоту обслуживаемости ПО.

К технологическим относятся следующие мероприятия. 1. Выбор стандарта качества и четкое следование ему на всех этапах. Создание модели проекта с регулярными проверками. которые будут выполняться независимыми командами экспертизы. Такая модель может быть построена, например, на основе стандартов качества (например, ISO 9000). 2. Единая среда разработки. Лучшие результаты дают программные продукты разработки, которые поддерживают несколько или все этапы жизненного цикла программного обеспечения. На данный момент такими комплексными решениями являются, например, продукты Oracle Designer, продукты фирмы Rational. 3. Использовать формальный язык спецификаций (например. UML, DESIGN IDEF). 4. Выбор надежной СУБД (если программное средство работает с массивами информации и использование СУБД оправдано). 5. Тщательное тестирование программного обеспечения.

6. Широкое внедрение автоматизации тестирования. 7. Использование полностью проверенной программной среды окружения (ОС) и языка программирования, которые минимизируют опасность внесения ошибки. 8. Использование статистических методов для сбора информации о качестве ПС. 9. Изучение результатов испытаний (тестов) и ошибок для использования в постоянном усовершенствовании программы. Источник в случае возникновения отказа должен быть найден и устранен. Недостаточно найти ошибку в программном обеспечении и исправить ее. Изменения должны быть сделаны в процессе разработки ПО. 10. Использование испытательной среды, которая предостережет от передачи пользователю ненадежного программного обеспечения. Создание автоматических средств приемки.