«Надежность программного обеспечения – беспризорное дитя вычислительной техники»
Р. Гласс
Проблема надежности ПО относится, похоже, к категории «вечных». В посвященной ей монографии Г. Майерса, выпущенной в 1980 г., отмечается, что этот вопрос рассматривался ещё на заре применения вычислительных машин.
«Те, кто регулярно программирует для быстродействующих электронных машин, знают на собственном опыте, что солидная доля подготовительного этапа работы на ЭВМ уходит на устранение ошибок, сделанных при составлении программы. С помощью здравого смысла и отладочных подпрограмм большинство ошибок удается найти и исправить достаточно быстро. Однако некоторые из них настолько неуловимы, что не поддаются обнаружению удивительно долгое время» – данное наблюдение было опубликовано в 1952 г. Сегодня, на пороге ХХI века, вопрос надежности ПО не потерял своей актуальности.
Отметим, что проблема надежности ПО имеет, по крайней мере, два аспекта:
1) обеспечение надежности;
2) оценка (измерение) надежности.
Какой из этих двух аспектов важнее?
Исследователи данной проблемы расходятся во мнениях. Одна точка зрения: более важно обеспечить надежность программной системы; вторая точка зрения: прежде, чем улучшать какую-либо характеристику (в нашем случае надежность), следует научиться её измерять, и уж, по крайней мере, необходимо иметь единицу её измерения.
Определим, что такое ошибка в ПО и что такое надежность ПО.
Рассмотрим пример: США – система раннего обнаружения баллистических снарядов, наблюдающая за объектами, движущимися по направлению к США – одна из первых версий системы приняла поднимающуюся луну за снаряд, летящий над северным полушарием.
Ошибка ли это? С точки зрения министерства обороны США (пользователя) – да. С точки зрения разработчика системы – возможно, и нет.
Что такое ошибка?
Несколько определений:
1) ПО содержит ошибку, если его поведение не соответствует спецификациям.
2) ПО содержит ошибку, если его поведение не соответствует спецификациям при использовании в установленных при разработке пределах.
3) Ошибка в ПО – это неспособность системы действовать в соответствии с перечнем требований пользователя.
4) В ПО имеется ошибка, если оно не выполняет того, что пользователю разумно от него ожидать.
5) Понятие ошибки в программе субъективно. Одна и та же программа может устроить одного и не устроить другого потребителя, т.е. вместо понятий правильно/неправильно надо применять категории приемлемо/неприемлемо, имея в виду конкретного потребителя.
! Какое из приведенных определений, по вашему мнению, является наиболее верным? наиболее удачным?
Первое определение страдает следующим недостатком: неявно предполагается, что спецификации корректны. Если поведение программного продукта не соответствует его спецификациям, ошибка, вероятно, имеется. Однако, если система ведет себя в соответствии со спецификациями, то нельзя утверждать, что она не содержит ошибок.
Второе определение еще хуже первого. Если система случайно используется в непредусмотренной ситуации, её поведение должно оставаться разумным, а если это не так, то система содержит ошибку.
Недостаток третьего определения: требования пользователя невозможно детализировать настолько, чтобы описать поведение ПО при всех мыслимых обстоятельствах.
Четвертое определение исходит из принципа, что «клиент всегда прав». Если разработчик ПО хочет спроектировать удачную систему, то он должен понимать, что именно ее пользователям «разумно от нее ожидать».
Пятое определение представляет другой взгляд на понятие ошибки.
Парадоксы программной ошибки (это интересно):
Ошибка – не всегда результат недостатков.
Ошибка не всегда может быть выявлена.
Выявленная ошибка не всегда может быть описана.
Описанная ошибка не всегда может быть понята.
Понятая ошибка не всегда может быть исправлена.
Исправленная ошибка не всегда может улучшить качество программы.
Рассмотрим этапы жизненного цикла ошибок в программном обеспечении.
BTS (bug – tracking systems) – программные продукты, предназначенные для проведения контроля за всеми этапами жизненного цикла ошибок в ПО – от инициализации до момента устранения. Конечная цель BTS – совершенствование менеджмента разработки программных продуктов.
Система BTS представляет собой базу данных с удаленным доступом, располагающуюся, как правило, на сервере локальной сети, и клиентских приложений, установленных на машинах сотрудников компании. Важным элементом в BTS является определение жизненного цикла ошибки (bug – life cycle) и соответствующий сценарий использования системы. Одно из многих возможных решений иллюстрирует диаграмма, представленная на рис. 5.1.
Рис. 5.1. Жизненный цикл ошибки
New. Сообщение об ошибке внесено в базу данных. Возможность сразу же закрыть сообщение (перевести его в состояние Closed) предусмотрена на случай, когда сообщение само по себе ошибочно.
Assigned. Сообщение попадает к ответственному за проект специалисту, который определяет важность ошибки и решает, как поступить с проблемой дальше:
· переслать программистам для исправления (Resolved);
· передать специалистам отдела качества (QA checked) для перепроверки и/или уточнения сценария и условия воспроизведения ошибки;
· отложить в «долгий ящик» (Postponed).
QA checked. Перепроверив сообщение об ошибке, сотрудник отдела QA вправе «закрыть» проблему (Closed) либо, удостоверившись в том, что проблема действительно существует, возвратить ее ответственному лицу.
Postponed. Исправление ошибки откладывается «до лучших времен». В обязанности группы QA, помимо прочего, входит регулярная проверка списка отчетов этого вида. В результате ошибка передается программистам для исправления. Ошибка может и исчезнуть вследствие изменений исходного кода и тогда сообщение переводится в состояние Closed.
Resolved. Исправив ошибку, программист передает результат на проверку (Verified). Если программист по тем или иным причинам не согласен с директивой руководства, он может возвратить проблему ответственному лицу (Assigned).
Verified. Ошибка в руках у сотрудников отдела качества. Перепроверив программу и вновь обнаружив изъян, они возвращают отчет об ошибке ответственному лицу. Если проблема решена, – с ней расстаются (Closed).
Closed. Архив побед программистов. Случается, что ошибка, которую считали устраненной, дает о себе знать. В этом случае отчет о ней извлекается QA – командой для перепроверки (QA checked).
Один из важных принципов BTS: никто не может удалить отчет из базы данных, ошибку можно перевести в разряд закрытых (Closed), но не удалить совсем.
Что такое надежность ПО?
Несколько определений:
1) Надежность есть вероятность того, что при функционировании системы в течение некоторого периода времени не будет обнаружено ни одной ошибки.
2) Надежность ПО есть вероятность его работы без отказов в течение определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа.
3) Надежность – это способность системы функционировать в соответствии со спецификациями («корректность») и при этом успешно справляться с возникающими ненормальными ситуациями («устойчивость»).
! Какое из приведенных определений, по вашему мнению, наиболее верное? наиболее удачное?
Основной недостаток первого определения – это то, что в нем не учтено различие между ошибками разных типов (по своим последствиям разные ошибки далеко не одинаковы).
Во втором определении надежность определяется как функция воздействия ошибок на пользователей системы. Слово «вероятность» в определении означает вероятность того, что пользователь не введет в систему некоторый конкретный набор данных, выводящий систему из строя.
Третье определение представляет совершенно другой взгляд на надежность ПО.