79) мероприятия обеспечивающие приемлемый уровень качества пс

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

К административным можно отнести следующие мероприятия:

1. Проведение обучения персонала, переподготовки.

2. Тщательное документирование всех изменений в структуре программного средства. Для этого используются средства под­держки версионности.

3. Назначение ответственных лиц за каждую доработку программного средства.

4. Уделение внимания текущему контролю качества и заклю­чительному контролю качества.

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

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

7. Организация отдела тестирования как самостоятельного подразделения.

8. Проведение совместных аттестаций с пользователем.

9. Обращение внимания на уровень и простоту обслуживаемости программного обеспечения. Здесь речь идет как о решении проблем, возникших у пользователя, так и о простоте и надежности внесения изменений в программное обеспечение. Даже если очень надежный кусок программного обеспечения был разработан, он может вскоре стать ненадежным, если сложно сделать изменения в программе. Часто изменения должны быть выполнены вследствие новых потребностей внешней среды, например вследствие изменений в законодательстве или требований заказчика.

К технологическим относятся следующие мероприятия.

1. Выбор стандарта качества и четкое следование ему на всех этапах. Создание модели проекта с регулярными проверками, которые будут выполняться независимыми командами экспертизы. Такая модель может быть построена, например, на основе стандартов качества (например, ISO 9000).

2. Единая среда разработки. Лучшие результаты дают программные продукты разработки, которые поддерживают несколько или все этапы жизненного цикла программного обеспечения. На данный момент такими комплексными решениями являются, например, продукты Oracle Designer, продукты фирмы Rational.

3. Использовать формальный язык спецификаций (например, UML, DESIGN IDEF).

4. Выбор надежной СУБД (если программное средство ра­ботает с массивами информации и использование СУБД оп­равдано).

5. Тщательное тестирование программного обеспечения.

6. Широкое внедрение автоматизации тестирования.

7. Использование полностью проверенной программной сре­ды окружения (ОС) и языка программирования, которые минимизируют опасность внесения ошибки.

8. Использование статистических методов для сбора информации о качестве ПС.

9. Изучение результатов испытаний (тестов) и ошибок для использования в постоянном усовершенствовании программы. Источник в случае возникновения отказа должен быть найден и устранен. Недостаточно найти ошибку в программном обеспече­нии и исправить ее. Изменения должны быть сделаны в процессе разработки ПО.

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

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

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

80)

Рассмотрим классификацию моделей надежности ПС.

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

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

         Для использования динамических моделей необходимо иметь данные о появлении отказов во времени. Если фиксируются ин­тервалы каждого отказа, то получается непрерывная картина появления отказов во времени (группа динамических моделей с непрерывным временем). Может фиксироваться только число отказов за произвольный интервал времени. В этом случае пове­дение ПС может быть представлено только в дискретных точках (группа динамических моделей с дискретным временем). Рассмот­рим основные предпосылки, ограничения и математический ап­парат моделей, представляющих каждую группу, выделенную по схеме.

 

         В современных условиях, условиях жесткой конкуренции, очень важно гаранти­ровать высокое качество процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обес­печения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/IЕС 15504 и модель зрелости процесса конструирования ПО  - СММ.  Института программной инженерии при американском универ­ситете Карнеги-Меллон.

         Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из лю­бых областей человеческой деятельности. Стандарт ISO/IEC 15504 специали­зируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей  ISO/IEC 15504 взята из модели СММ.

81)

Факторы, влияющие на качество программного обеспечения, классифицируются по трем аспектам программного продукта:

• рабочие характеристики;

• приспособленность к внесению изменений;

• приспособленность к изменению окружающей обстановки.

К первой группе можно отнести следующие характеристики:

• правильность (корректность), характеризующая степень функционального соответствия программного обеспечения требованиям пользователя;

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

• эффективность характеризует оперативность выполнения функциональных задач, а также объемы компьютерных ресурсов и объем кода программы, необходимые для выполнения последней своих функций;

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

 

• физические и интеллектуальные усилия, необходимые для обучения работе с рассматриваемым программным продуктом;

• время, необходимое для того, чтобы использование системы стало эффективным;

• повышение производительности труда при эксплуатации программного обеспечения пользователем средней квалификации;

• субъективную оценку отношения пользователя к системе;

• целостность определяет степень, с которой может быть проконтролирован несанкционированный доступ к данным и программам.

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

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

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

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

Третья группа характеристик - возможности использования программного обеспечения в новых окружающих условиях, включает:

• переносимость (мобильность) характеризует усилия, необходимые для переноса программы с одного технического изделия на другое или перенос ее в другую операционную обстановку;

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

• совместимость определяет возможность взаимодействия с другими программными продуктами.

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

82)

Определение тестирования

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

Слишком часто тестированию в литературе по программной инженерии придается огромное значение, что, собственно, и отражено в определении, данном в Wikipedia: «Тестирование программного обеспечения — это процесс оценки качества компьютерных программ. Тестирование — это практическое техническое изучение, проводимое для того, чтобы предоставить заинтересованным сторонам информацию о качестве продукта или сервиса с учетом контекста, в котором, как предполагается, он будет работать». На самом деле, тестирование программы мало что говорит о ее качестве, поскольку 10 или даже 10 млн тестов — это лишь капля в океане всех возможных случаев.

Безусловно, связь между тестами и качеством программ существует, но она довольно слаба?— успешный тест позволяет оценить качество только в том случае, если прежде он не был пройден. Тогда это свидетельствует об отсутствии неудачи и, как правило, — отсутствии самой ошибки*.

Если систематически отслеживать неудачи и ошибки, то их регистрация может дать представление о том, сколько еще ошибок осталось. Если последние три недели при работе тестов было обнаружено 550, 540 и 530 ошибок, то тенденция обнадеживает, но маловероятно, что при следующем тестировании не будет выявлено ни одной ошибки или всего 100 таковых. (Математические модели надежности позволяют оценить это более точно и достоверно, если реализован эффективный процесс долгосрочной сборки данных.)

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

«Тестирование программ, — отмечал Эдсгер Дейкстра, — можно использовать для того, чтобы показать наличие ошибок и никогда — для того чтобы показать их отсутствие!» Очень немногие (Дейкстра, вероятно, на это и не рассчитывал) понимают, что для тестировщиков это означает наилучшую возможность для саморекламы. Безусловно, любая методика, позволяющая находить ошибки, крайне важна для «заинтересованных лиц», от менеджеров до разработчиков и пользователей. Мы должны воспринимать эту максиму не как некое обвинение, а как определение тестирования. Конечно, это не столь амбициозно звучит, как «предоставление информации о качестве», но зато более реалистично и практично.

Принцип 1. Определение. Для того чтобы протестировать программу, нужно попытаться заставить ее работать неверно.

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