Какой параметр характеризует качество и надежность программного продукта
Пользователь
Регистрация: 05.02.2013
Сообщений: 49
Сказал спасибо: 0
Поблагодарили 72 раз(а) в 17 сообщениях
Я тогда уж свои ответы на все модули выложу, вдруг пригодится. Везде оценка “Отлично”.
3 модуль. 25/25. Отл.
Вопрос 1
Какие версии Delphi работают под управлением 16-разрядной Windows 3.1 (3.11)?
только первая версия
Вопрос 2
Как называется самостоятельно существующий объект, параметры которого (размеры, расположение и т.п.) хранятся в специальной структуре данных, а поведение определяется обработчиками сообщений?
окно
Вопрос 3
Какая из перечисленных сред программирования использует в качестве языка разработки язык на основе Object Pascal?
Delphi
Вопрос 4
Укажите обработчик событий для класса TForm, который используется при необходимости задания параметров (цвет или размер) в начальной стадии создания формы
OnCreate
Вопрос 5
Укажите обработчик событий для класса TForm, который используется при перетаскивании объекта мышью над формой (многократно)
OnDragOver
Вопрос 6
Укажите тип объекта, копия которого становится частью составного документа, и никакое изменение оригинала объекта не переносится в составной документ
внедренный объект
Вопрос 7
Как принято называть программы, предназначенные для выполнения под управлением операционной системы типа Windows?
приложениями Windows
Вопрос 8
Укажите новшество второй версии Delphi по сравнению с первой
введена поддержка 16-битных символов и составленных из них строк
Вопрос 9
Основное внимание в процессе разработки приложений в средах программирования «под Windows» сосредотачивается на создании
объекта-формы МБ НЕПРАВИЛЬНО
Вопрос 10
Какова основная идея создания Delphi 6?
обеспечение перехода от дорогих патентованных решений корпорации Microsoft к бесплатным (или почти бесплатным) решениям на базе Linux
Вопрос 11
В основу Windows положен
принцип событийного управления
Вопрос 12
Какая из перечисленных операционных систем первоначально предназначалась для пользователей-профессионалов?
Windows NT
Вопрос 13
Как называются методы, которые могут быть добавлены при разработке конкретного приложения для включения его специфической обработки?
обработчики событий
Вопрос 14
В каком году вышла Delphi 6?
в 2001 г.
Вопрос 15
Укажите характеристику сообщения WMPAINT
посылается окну при необходимости его перерисовки
Вопрос 16
В каком году появилась первая версия Delphi?
в 1995 г.
Вопрос 17
Как называется специальная программа, обеспечивающая взаимодействие технического устройства с Windows?
драйвер
Вопрос 18
Как называется прямоугольная область экрана стандартного вида, через которую пользователь взаимодействует с программой?
окно
Вопрос 19
Какая версия Delphi получила возможность создавать так называемые межплатформенные приложения?
Delphi 6
Вопрос 20
Что из перечисленного не относится к недостаткам программы, непосредственно управляющей устройствами?
усложняет выполнение операций ввода-вывода, даже в простейших случаях
Вопрос 21
Какая из перечисленных сред программирования «под Windows» является наиболее универсальной?
Visual C++
Вопрос 22
В какой операционной системе используется вытесняющая многозадачность, подразумевающая, что управление между процессами передается по истечении некоторого заранее определенного интервала времени (кванта) по сигналу таймера?
Win32
Вопрос 23
С использованием какой технологии выполняется конструирование окна приложения в средах Delphi и C++Builder?
с использованием визуальной технологии
Вопрос 24
Какой тип сообщений в Windows не форматируется под сообщение?
прямые вызовы методов не оконных объектов
Вопрос 25
Какой обработчик событий для класса TForm используется при изменении размеров формы на экране?
OnResize
4 модуль 25/25. Отл.
Вопрос 1
Чем измеряется размер программного модуля?
числом содержащихся в нём операторов или строк
Вопрос 2
Что на диаграмме последовательностей показывают линия жизни?
показывает, когда объект начинает и заканчивает свое существование
Вопрос 3
Какой вид сцепления модулей рекомендуется для использования современной технологией программирования?
параметрическое сцепление
Вопрос 4
Самой слабой степенью прочности обладает
модуль, прочный по совпадению
Вопрос 5
Фаза построения программы начинается
с планирования структуры
Вопрос 6
Кто является действующим субъектом при моделировании вариантов использования программного обеспечения?
человек, который будет реально работать с создаваемой системой
Вопрос 7
Сценарий в моделировании вариантов использования определяет
способ достижения цели операции
Вопрос 8
Как называется любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях разных процессов?
программный модуль
Вопрос 9
Когда можно говорить о начале процесса разработки программного обеспечения?
когда существует договоренность с заказчиком о цене, сроках и общем предназначении программы
Вопрос 10
Что такое сцепление программного модуля?
мера его зависимости по данным от других модулей
Вопрос 11
В чем состоит статистический контроль структуры программы?
в оценке структуры программы, именно насколько хорошо программа разбита на модули с учетом значений основных характеристик модуля
Вопрос 12
Архитектурный подход к разработке программы представляет собой
модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования (кодирования) модуля
Вопрос 13
Сколько итераций каждого этапа разработки проектов может понадобиться?
возможно несколько, в зависимости от нужд пользователя и их представления программистами
Вопрос 14
Атрибуты (методы) для каждого из классов
в основном вырастают из тех существительных, которые сами не стали классам
Вопрос 15
Как называется класс поддержки экрана пользовательского интерфейса?
userInterface
Вопрос 16
Сквозной контроль является видом
динамического контроля
Вопрос 17
В каких случаях следует применять хранение самих объектов?
когда объектов мало и они небольшие
Вопрос 18
Как называется контроль спецификации модулей со стороны разработчиков этих модулей?
смежный контроль снизу
Вопрос 19
Кто обычно инициирует вариант использования?
действующий субъект
Вопрос 20
На какой стадии создания системы с помощью вариантов использования должно быть описано все, что должна делать эта система?
на стадии ее разработки
Вопрос 21
Как называется простой программный фрагмент, который при нисходящем тестировании сигнализирует о самом факте обращения к модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат?
имитатор модуля
Вопрос 22
Что такое рутинность модуля?
его независимость от предыстории обращений к нему
Вопрос 23
Как называется метод, при котором обход дерева программы производится с целью кратчайшим путем реализовать тот или иной вариант (сначала самый простейший) нормально действующей реализации?
целенаправленная конструктивная реализация
Вопрос 24
Как на диаграмме вариантов использования называют прямоугольную рамку, которая окружает все варианты использования, оставляя за своими пределами действующих субъектов?
границей системы
Вопрос 25
Какой метод разработки структуры программы предполагает, что каждый запрограммированный модуль начинают сразу же тестировать до перехода к программированию другого модуля?
метод нисходящей реализации
5 модуль 25/25. Отл.
Вопрос 1
Как называется набор рекомендаций по выполнению разных процессов жизненного цикла программ, оформленный в виде базы знаний?
Rational Unifed Process
Вопрос 2
Что представляет собой система Paradigm Plus, которая используется в качестве поддержки программного обеспечения ECM?
набор рекомендаций по разбиению жизненного цикла программ на отдельные этапы, рекомендации по организации этих этапов, объединенные с CASE-системой построения моделей для всех этапов
Вопрос 3
Чем определяется изучаемость программного средства (ПС)?
составом и качеством документации по сопровождению ПС
Вопрос 4
Как называется некоторое логическое условие, значение которого (истина или ложь) должно сохраняться?
инвариант
Вопрос 5
Какой вид защиты программного средства включает в себя защиту от так называемых «компьютерных вирусов»?
защита от злонамеренного влияния чужих программ
Вопрос 6
На какие типы по целям делятся библиотеки классов?
на библиотеки общего назначения и библиотеки, специализированные по областям применения
Вопрос 7
Укажите наиболее часто применяемый способ приспособления классов и объектов к конкретной задаче
уточнение с помощью наследования, т.е. базовые классы, имеющиеся в библиотеке, реализуют основные алгоритмы обработки, а в программе из них выводятся конкретные классы, изменяющие и приспосабливающие их к текущей задаче
Вопрос 8
Укажите способ приспособления функции к конкретной программе
задание различных аргументов
Вопрос 9
В каком случае возможно реальное ускорение процесса разработки программного обеспечения?
когда конкретная программная система разрабатывается не с нуля, а используя готовые составные части
Вопрос 10
Защита программного средства от отказов чужой программы означает, что
на выполнение функций защищаемой программой не будут влиять отказы (проявления ошибок), возникающие в параллельно выполняемых программах
Вопрос 11
Какое качество программного средства обеспечивают его независимость от устройств, автономность, структурированность и модульность?
мобильность
Вопрос 12
Какие примитивы качества программных средств реализуются программным путем?
коммуникабельность, устойчивость и защищаемость
Вопрос 13
Для чего предназначен Rational Unified Process?
для организации всего жизненного цикла программирования, начиная от анализа деятельности организации (бизнес-моделирования) и кончая тестированием и установкой системы
Вопрос 14
Через какие примитивы качества программного средства выражается его модифицируемость?
расширяемость, легкость изменения, структурированность и модульность
Вопрос 15
К какому виду защиты относится защита от взлома защиты?
защита от несанкционированного доступа
Вопрос 16
Как называется процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации?
инкапсуляция
Вопрос 17
Какова цель создания библиотек функций и библиотек классов?
многократное использование готовых решений
Вопрос 18
Какое CASE-средство, выпускаемое компанией Rational, предназначено для автоматизации тестирования?
TeamTest
Вопрос 19
Как называется упорядочение абстракций, расположение их по уровням?
иерархия
Вопрос 20
Что такое сохраняемость, как элемент объективно-ориентированной модели?
способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства
Вопрос 21
Как называется методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы?
объектно-ориентированное проектирование
Вопрос 22
Какое CASE-средство, выпускаемое компанией Rational, предназначено для построения моделей и их графического изображения с помощью языка UML?
Rational Rose®
Вопрос 23
Какой вид абстракций, согласно Боброву и Стефаку, соответствует программированию, ориентированному на ограничения?
инвариантные соотношения
Вопрос 24
Значение какой погрешности зависит от того, как запрограммированы выражения?
погрешности округления
Вопрос 25
Что такое объектно-ориентированный анализ?
это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области
Источник
Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014)[1].
Другие определения из стандартов:
- весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94)[2][3];
- степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990)[4].
Ранние подходы к определению[править | править код]
Том Демарко в 1999 году предлагал при оценке качества программного обеспечения учитывать, что «качество программного продукта является показателем того, насколько он меняет мир к лучшему»[5].
Джеральд Вайнберг в своей работе 1992 года Quality Software Management: Volume 1, Systems Thinking давал определение качества как «значимого для какого-либо человека»[6][7], подчеркивая тем самым, что понятие качества является по своей природе субъективным — разные люди будут оценивать качество одного и того же программного обеспечения по-разному. Одной из сильных сторон этого определения являются вопросы, на которые должны ответить команды разработчиков программного обеспечения, такие как «Кто те люди, которые будут оценивать наше программное обеспечение?» и «Что будет ценным для них?».
Модели качества[править | править код]
Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня:
- функциональная пригодность;
- уровень производительности;
- совместимость;
- удобство использования (юзабилити);
- надёжность;
- защищённость;
- сопровождаемость;
- переносимость (мобильность).
В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании, которое может сильно отличаться для различных стейкхолдеров[9]. Модель качества в использовании (англ. quality in use model) включает следующие характеристики верхнего уровня[8]:
- результативность;
- производительность;
- удовлетворённость;
- свобода от риска;
- покрытие контекста.
Роберт Гласс в известной книге «Факты и заблуждения профессионального программирования» утверждает, что большинство профессиональных разработчиков согласны с выделением семи показателей качества как основных[10]:
- переносимость;
- надёжность;
- эффективность;
- удобство использования (юзабилити);
- тестируемость[en];
- понятность;
- модифицируемость.
Среди относительно новых моделей качества программного обеспечения можно упомянуть SQUALE и Quamoco[11], которые были применены в промышленных условиях, но пока не получили широкого распространения.
См. также[править | править код]
- Управление качеством
- Тестирование программного обеспечения
- Метрика программного обеспечения
- Технический долг
Примечания[править | править код]
- ↑ Software quality — capability of software product to satisfy stated and implied needs when used under specified conditions: ISO/IEC 25000:2014(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
- ↑ ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению
- ↑ ISO 8402:94. Управление качеством и обеспечение качества. Словарь
- ↑ The degree to which a system, component, or process meets customer or user needs or expectations: IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology
- ↑ DeMarco, T., Management Can Make Quality (Im)possible, Cutter IT Summit, Boston, April 1999
- ↑ Weinberg, Gerald M. (1992), Quality Software Management: Volume 1, Systems Thinking, New York, NY: Dorset House Publishing, с. 7
- ↑ Weinberg, Gerald M. (1993), Quality Software Management: Volume 2, First-Order Measurement, New York, NY: Dorset House Publishing, с. 108
- ↑ 1 2 ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов - ↑ Wijnholds, et al, 2016.
- ↑ Роберт Гласс. Факты и заблуждения профессионального программирования. = Facts and Fallacies of Software Engineering. — 2004. — ISBN 5-93286-092-8; 978-5-93286-092-2.
- ↑ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas. Operationalised product quality models and assessment: The Quamoco approach (англ.) // Information and Software Technology (англ.)русск. : journal. — 2015. — Vol. 62. — P. 101—123. — doi:10.1016/j.infsof.2015.02.009.
Литература[править | править код]
- ГОСТ 28195-89 — Оценка качества программных средств
- Gijs Wijnholds, Zeeger Lubsen, Sylvan Rigal, Joost Visser. Building Software Teams. — O’Reilly Media, Inc., 2016.
Ссылки[править | править код]
- OpenQuality.ru | Качество программного обеспечения
Источник
17.04.1994
С. Г. Романюк
Надежность программного обеспечения гораздо важнее других его характеристик, например, времени исполнения, и хотя абсолютная надежность современного программного обеспечения, по-видимому, недостижима, до сих пор не существует общепринятой меры надежности компьютерных программ. В статье анализируются причины создавшегося положения и предлагается подход к решению проблемы.
Обоснование проблемы
Причины сложившейся ситуации
Вероятностный подход к проблеме
надежности
Компьютерная программа как объект
исследования
Надежность и правильность программы
Модель последовательности испытаний
Бернулли
Некоторые следствия
Заключение
Литература
Надежность программного обеспечения
Надежность программного обеспечения гораздо важнее других его характеристик, например, времени исполнения, и хотя абсолютная надежность современного программного обеспечения, по-видимому, недостижима, до сих пор не существует общепринятой меры надежности компьютерных программ. В статье анализируются причины создавшегося положения и предлагается подход к решению проблемы.
Обоснование проблемы
Проблема надежности программного обеспечения относится, похоже, к категории “вечных”. В посвященной ей монографии Г.Майерса [1], выпущенной в 1980 году (американское издание – в 1976), отмечается, что, хотя этот вопрос рассматривался еще на заре применения вычислительных машин, в 1952 году, он не потерял актуальности до настоящего времени. Отношение к проблеме довольно выразительно сформулировано в книге Р.Гласса ([2]): “Надежность программного обеспечения – беспризорное дитя вычислительной техники”. Следует далее отметить, что сама проблема надежности программного обеспечения имеет, по крайней мере, два аспекта: обеспечение и оценка (измерение) надежности. Практически вся имеющаяся литература на эту тему, включая упомянутые выше монографии, посвящена первому аспекту, а вопрос оценки надежности компьютерных программ оказывается еще более “беспризорным”. Вместе с тем очевидно, что надежность программы гораздо важнее таких традиционных ее характеристик, как время исполнения или требуемый объем оперативной памяти, однако никакой общепринятой количественной меры надежности программ до сих пор не существует.
Для обеспечения надежности программ предложено множество подходов, включая организационные методы разработки, различные технологии и технологические программные средства, что требует, очевидно, привлечения значительных ресурсов. Однако отсутствие общепризнанных критериев надежности не позволяет ответить на вопрос, насколько надежнее становится программное обеспечение при соблюдении предлагаемых процедур и технологий и в какой степени оправданы затраты. Таким образом, приоритет задачи оценки надежности должен быть выше приоритета задачи ее обеспечения, чего на самом деле не наблюдается.
Причины сложившейся ситуации
Судя по имеющимся публикациям, вопрос обеспечения надежности программ считается более важным, чем вопрос ее оценки. Ситуация выглядит парадоксальной: совершенно очевидно, что прежде, чем улучшать какую-то характеритику, следует научиться ее измерять, и уж, по крайней мере, необходимо иметь единицу измерения. Основная причина такого положения коренится в том, что источником ненадежности программ служат содержащиеся в них ошибки, и если ошибки отсутствуют, то программа абсолютно надежна. По существу, все меры по обеспечению надежности программ направлены на то, чтобы свести к минимуму (если не искючить вообще) ошибки при разработке и как можно раньше их выявить и устранить после изготовления программы. Следует заметить, что безошибочные программы, конечно же, существуют, однако современные программые системы слишком велики и почти неизбежно содержат ошибки. Хотя это обстоятельство отмечается многими авторами и известно любому программисту-практику, существует, по-видимому, некий психологический барьер, не позволяющий признать факт наличия ошибок в программном обеспечении неизбежной реальностью: поскольку не существует точного критерия, позволяющего определить максимальный размер свободной от ошибок программы, всегда остается надежда, что в данной конкретной программной системе их не осталось.
Имеется еще одно обстоятельство психологического характера. Как известно, вопрос надежности для аппаратуры хорошо разработан. Источником ненадежности аппаратуры служат объективные факторы, неподвластные человеку (скачки напряжения питания, альфа-частицы и т.д.), поэтому человечество давно смирилось с мыслью о том, что абсолютно надежной аппаратуры не бывает и можно говорить лишь о степени надежности, выражаемой в каких-то единицах (например, среднее время между двумя последовательными отказами). Источник же ненадежности программ ошибки, которые делают люди, их создающие и использующие, поэтому кажется, что проблема лишь в том, чтобы заставить (или научить) их работать “правильно”.
Третья причина состоит в том, что проблему выбора единицы измерения надежности компьютерной программы невозможно решить в рамках промышленного подхода, который в настоящее время занимает в программированиии все более доминирующее положение. Наиболее характерный пример – использование, по аналогий с аппаратурой, в качестве меры надежности программы среднего времени между двумя последовательными ошибочными срабатываниями. Рассуждения в обоснование аналогий такого рода В.Турский ([3]) довольно резко охарактеризовал как наукообразные; сама же характеристика плохо отражает суть дела и не получила широкого признания.
Метод аналогий, конечно, универсален, однако не следует забывать, что любая аналогия имеет границы применимости. В данном случае, поскольку речь идет о фундаментальном понятии (единице измерения), следует не просто переносить характеристики надежности аппаратуры на программы, а воспользоваться более фундаментальными аналогиями.
Вероятностный подход к проблеме надежности
Прежде всего полезно напомнить, откуда берутся характеристики надежности аппаратуры. Надежность, в конечном счете, – понятие статистическое, т.е. предполагается наличие некоторого (достаточно большого) количества одинаковых образцов, испытаний и т.д. Существенно также, что имеется элемент случайности. Изучению случайных явлений посвящен специальный раздел математики: теория вероятностей. Основное понятие этой теории – пространство элементарных событий (выборочное пространство, пространство исходов), на котором задается некоторая (вероятностная) мера. Случайная величина, согласно теории, есть функция, заданная на пространстве элементарных событий. Наконец, в качестве меры надежности используются некоторые характеристики случайной величины (как правило, математическое ожидание).
Таким образом, последовательный вероятностный подход при изучении надежности состоит в анализе исследуемого объекта (самолета, системы охраны, компьютерной программы и т.д.), построении, исходя из “физических” соображений о его природе, пространств элементарных событий, введении на них вероятностной меры и рассмотрении случайных величин.
К сожалению, первый этап исследований – анализ объекта и построение пространств элементарных событий – обычно опускают и сразу переходят к рассмотрению случайных величин, упуская из вида, что случайная величина есть на самом деле функция, заданная на пространстве элементарных событий.
Компьютерная программа как объект исследования
Прежде чем говорить о надежности объекта, следует уточнить, что подразумевается под объектом. Как известно, компьютерная программа имеет несколько разных форм (или представлений): внешние спецификации, исходный текст, исполняемый код и т.д. Общепринятая точка зрения состоит в том, что программа представляет собой объект, инвариантный относительно форм его представления. Согласно этой точке зрения, внешние спецификации, исходные тексты на языках разных уровней, а также исполняемые коды для разных процессоров есть разные формы представления одной и той же программы. Указанная точка зрения полезна при разработке программного обеспечения, поскольку позволяет выявить наиболее существенные для приложения свойства программы, общие для всех ее представлений, однако она малопродуктивна, если речь идет, например, о такой количественной характеристике, как время исполнения: ясно, что указанная характеристика относится лишь к одной из форм представления – исполняемомому коду и, кроме того, зависит не только от программы, но и от типа процессора.
На интуитивном уровне понятие надежности программы отражает тот факт, что она не всегда может давать правильный результат. Это означает, что надежность программы является характеристикой ее исполняемого кода. Исполняемый код соотносится с исходным текстом так же, как, например, электродвигатель и его чертежи: можно говорить о надежности изготовленного изделия, но бессмысленно говорить о надежности описания, чертежа, текста. Две функционально идентичные программы, написанные на разных языках, или подготовленные для разных типов машин, или для одной и той же машины, но с использованием разных компиляторов, с точки зрения надежности следует считать разными.
Надежность и правильность программы
Программа считается правильной, если она не содержит ошибок. Такая программа не дает неверных результатов, т.е. она абсолютно надежна. Этот факт породил ложное представление о том, что число ошибок в программе можно считать наиболее естественной мерой надежности ([1]). Было выполнено довольно много работ, в которых предлагались различные методы оценки числа оставшихся в программе ошибок по результатам ее тестирования, в том числе метод “засорения” известными ошибками, однако, как показывают приводимые ниже соображения, количество ошибок в программе не имеет никакого отношения к ее надежности:
1. Число ошибок в программе – величина “ненаблюдаемая”, наблюдаются не сами ошибки, а результат их проявления.
2. Неверное срабатывание программы может быть следствием не одной, а сразу нескольких ошибок.
3. Ошибки могут компенсировать друг друга, так что после исправления какой-то одной ошибки программа может начать “работать хуже”.
4. Надежность характеризует частоту проявления ошибок, но не их количество; в то же время хорошо известно, что ошибки проявляются с разной частотой: некоторые ошибки остаются невыявленными после многих месяцев и даже лет эксплуатации, но, с другой стороны, нетрудно привести примеры, когда одна единственная ошибка приводит к неверному срабатыванию программы при любых исходных данных, т.е. к нулевой надежности.
Следует также отметить, что если число ошибок рассматривать как меру надежности, то в терминологии теории вероятностей это число есть случайная величина, однако самый главный вопрос – на каком пространстве элементарных событий она задана – нигде не затрагивался.
Наконец, важно подчеркнуть, что, с точки зрения надежности, в результате исправления ошибки или любой другой коррекции получается новая программа с другим, чем до коррекции, показателем надежности.
Таким образом, число ошибок в программе характеризует скорее не программу, а ее изготовителей и используемый инструментарий.
Модель последовательности испытаний Бернулли
Рассмотрим для простоты класс программ, имеющих единственный вход и выход, т.е. не содержащих бесконечных циклов. Фазу выполнения программы от начала до завершения будем называть запуском. Все возможные результаты запуска разобьем на два класса: правильные и неправильные (ошибочные). Будем считать, что любой результат всегда можно отнести к одному из этих классов. (Ясно, что по этому вопросу возможны разногласия между изготовителями программы и пользователями, однако будем предполагать, что имеется какой-то общий критерий, например, “клиент всегда прав”.) Рассмотрим классическую вероятностную модель последовательности испытаний Бернулли. Пространство элементарных событий в этой модели содержит 2n точек, где n – число испытаний (в данном случае под испытанием подразумевается запуск программы). Каждый запуск программы имеет два исхода: правильный и неправильный. Обозначим вероятность неправильного исхода р, а вероятность правильного – (1-p). Вероятность того, что из n запусков К приведут к неправильному результату, выражается хорошо известной формулой биномиального распределения ([4]).
B(р,n,k) = C(n,k) * pk * (1-р)(n-k), (1)
где С(n,k) – число сочетаний. Вероятность р априори неизвестна, но по результатам запусков известны n и k. Величина В как функция р имеет максимум при
р = k/n. (2)
В качестве меры надежности программы можно принять величину
R = 1 – k/n = (n-k)/n, (3)
значения которой (от 0 до 1) согласуются с общепринятым смыслом термина надежность: например, если все запуски окончились с ошибочным результатом (k = n), то надежность – нулевая.
Наиболее существенное предположение в данной модели состоит в том, что запуски программы считаются независимыми. Это означает, что результаты предыдущих запусков не дают никакой информации о результатах следующего. Ясно, что это предположение на практике выполняется не всегда: например, повторный запуск с теми же входными данными даст, очевидно, тот же самый результат.*
Следует отметить, что изготовитель программы и ее пользователь располагают разной информацией о ней. Например, изготовителю заведомо известна логика программы, так что по результатам запуска с некоторыми исходными данными он иногда может точно предсказать результаты запусков с другими исходными данными (на этом, в конечном счете, основана любая методика тестирования), и в этом смысле предположение о независимости испытаний не выполняется. Однако пользователя редко интересует устройство программы, для него важно лишь одно: выполняет ли она требуемые функции, поэтому у пользователя нет оснований считать запуски зависимыми. Если же имеется желание использовать информацию об устройстве программы при оценке ее надежности, то следует придумать какую-то более сложную вероятностную модель, которая бы ее учитывала.
Некоторые следствия
Формула (3) позволяет оценить надежность программы по результатам ее запусков. Следует особо остановиться на двух предельных случаях: k = n (нулевая надежность) и k = 0 (абсолютная надежность). В обоих случаях результаты не следует интерпретировать буквально: нет никаких гарантий того, что очередной запуск приведет к тому же реультату, что и предыдущие. Однако с точки зрения пользователя эти случаи совершенно разные. Если нулевая надежность свидетельствует о том, что программа явно непригодна для эксплуатации, то показатель абсолютной надежности не должен вводить в заблуждение: такой вывод нельзя делать по результатам даже очень большого числа запусков. Следует подчеркнуть, что для оценки надежности в этом случае необходимо рассмотреть другие вероятностные модели.
Из формулы (3) следует, что оценка надежности программы растет с увеличением числа ее запусков по гиперболическому закону. Это подтверждает интуитивно ясное соображение о том, что программа тем надежнее, чем больше опыт ее эксплуатации, который зависит как от интенсивности использования программы, так и от тиража компьютера, на котором она запускается. Таким образом, надежность программ для персональных компьютеров типа IBM РС, общий тираж которых составляет в настоящее время около 100 миллионов, на несколько порядков выше аналогичных программ для специализированных процессоров (если, конечно, такие программы действительно существуют и эксплуатируются).
Стало классическим утверждение, что ошибка в программе обходится тем дороже, чем позже она обнаружена. На самом же деле дорого обходится не ошибка, а опыт эксплуатации программы (т.е. общее количество ее запусков), независимо от того, проявились ошибки или нет. Перед пользователем программы, в которо проявились ошибки, возникает дилемма: продолжать ее эксплуатировать или установить модифицированную версию (разумеется, речь не идет о тех случаях, когда последствия ошибок могут быть катастрофическими). Следует еще раз подчеркнуть, что если программа подвергалась модификациям (в частности, в ней исправлялись ошибки), то при оценке надежности следует учитывать только запуски, выполненные с момента последней модификации: в результате модификации получается новая программа, с другим (возможно, худшим) показателем надежности, и вся прежняя статистика должна быть аннулирована. Этим частично объясняется тот факт, что пользователи порой предпочитают обновленным версиям программ старые, проверенные, эксплуатировавшиеся длительное время, даже если в них обнаружены погрешности: опыт эксплуатации стоит очень дорого, и даже если в программе выявлены ошибки, гораздо дешевле внести исправления и дополнения в инструкции к программе (если это, конечно, возможно), чем пожертвовать накопленным опытом.
Стремление разработчиков создавать бинарно совместимые семейства микропроцессоров находит дополнительное объяснение с позиций надежности программного обеспечения: если бы это удалось в полной мере, то опыт эксплуатации программ не приходилось бы аннулировать при переходе на новый тип процессора, что способствовало бы существенному повышению надежности использующихся программ.
Интересно сравнить характеристики надежности аппаратуры и компьютерной программы. Как известно, надежность физического устройства меняется со временем: в начале эксплуатации она растет (присходит “приработка” изделия), затем некоторое время остается постоянной и, наконец, начинает уменьшаться (эффект износа или “старения”). Говоря о надежности аппаратуры, имеют в виду именно среднюю фазу, на которой надежность постоянна. Всеми отмечается тот факт, что компьютерная программа не изнашивается, так что последней фазы для нее не существует, однако важно подчеркнуть, что первая фаза (“приработки” программы) тоже отсутствует: коррекция программы (независимо от причин, по которым она выполнялась) аналогична внесению изменений в конструкцию физического устройства, в результате чего получается новое устройство, с другим показателем надежности.
***
Несмотря на очевидную актуальность, вопрос оценки надежности программного обеспечения не привлекает д