Главная \ Статьи \ АНАЛИЗ ОСНОВНЫХ ПРОЦЕССОВ ОБЕСПЕЧЕНИЯ НАДЁЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ АСУ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ

Статьи

« Назад

АНАЛИЗ ОСНОВНЫХ ПРОЦЕССОВ ОБЕСПЕЧЕНИЯ НАДЁЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ АСУ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ  06.06.2015 11:03

Анализируются базовые процессы и процедуры обеспечения надёжности программных средств (ПС), являющиеся предметом обсуждения при подготовке и формировании современных стандартов в области качества ПС. Основные процессы, направленные на обеспечение надёжности ПС, рассматриваются с учетом их вклада в повышение общей надёжности создаваемых ПС как важного компонента специализированных АСУ.  Отмечается, что особенно большие затраты и сложности устранения связаны с ошибками, обнаруживаемыми в процессе эксплуатации ПС. Отсюда вытекает важная задача проверки корректности ПС непосредственно в процессе его создания. Такая проверка должна проводиться на всех этапах создания ПС. Приводится и обсуждается общая схема и содержательная структура рассматриваемых процессов  оценки и обеспечения качества (надёжности) ПС. Значительное внимание уделяется вопросам организации и проведения динамического тестирования ПС, включая тестирование на базе спецификаций (стратегия «черного ящика») и тестирование на базе структуры ПС (стратегия «белого ящика»). Кратко анализируются различные способы организации тестирования для каждой из рассматриваемых стратегий. Отмечаются их основные достоинства и недостатки. Приводятся рекомендации по их применению в интересах повышения надёжности ПС АСУ специального назначения. При рассмотрении процессов демонстрации ПС выделяется ряд подпроцессов, заключающихся в исследовании прототипа ПС, версии ПС для пользователя и пробной версии ПС. Приводится вербальная характеристика каждого из этих подпроцессов. Различия между этими подпроцессами  заключаются в степени реализации задаваемых требований к ПС. Приводятся рекомендации по использованию рассмотренных процедур для повышения надёжности ПС. В выводах работы отмечается, что при практической организации работ по созданию высоконадёжных ПС особое внимание следует обращать на внедрение методов и способов обеспечения надёжности ПС на ранних этапах создания ПС, поскольку стоимость последующего исправления допущенных на этих этапах ошибок в ПС существенно возрастает.     ANALYSIS OF BASIC SOFTWARE RELIABILITY CONTROLE PROCESSES FOR SPECIAL PURPOSE COMPUTER SYSTEMS Basic processes  and procedures to ensure software reliability being the subject matter of software quality are analysed. The basic processes to ensure software reliability are treated taking into account their contribution into total reliability of software being produced. It is pointed out that the most expensive software defects are those found in the course of  software exploitation. Now an imported problem of software correctness control  in  the course of its development follows. Such actions may be initiated during all the stages of software development. A basic diagram and the major structure of the processes involved are discussed. Much consideration is received to software dynamic testing including “black box” and “white box” testing. A variety of techniques for testing organizations for each the strategies covered are analyzed in short. The main strengths and weaknesses are noted out.  Some recommendations for these methods applications are given.  In software demonstration processes some subprocesses are stood out such as software prototype, user version and mock-up. Verbal characteristics of each the processes are given. The distinctions between the processes lay with the level of basic requirements for software.   Some recommendations for using these procedures to increase  the software reliability are given. It is stressed in draw that during the reliable software development processing much considerations should be paid to promoting the techniques for each reliable software development stage, In view of the fact that the cost of removing these defects later is high.   Ключевые слова: программные средства; надёжность; тестирование; верификация; валидация.   Keywords: software; reliability; software testing; verification; validation.   Среди характеристик качества программных средств (ПС) АСУ специального назначения (СН) надёжность ПС занимает особое место[1,9-13]. Известно, что ПС АСУ, являясь продуктом интеллектуального труда, неизбежно содержит некоторое число дефектов – ошибок, допущенных человеком-разработчиком ПС. Известны  примеры серьезных ошибок в ПС, приведших к потере человеческих жизней, космических аппаратов или к масштабным нарушениям работы инфраструктурных сетей [1,2,23,24]. По мере развития АСУ СН возрастает сложность ПС АСУ, что  приводит к увеличению количества ошибок в нем и, соответственно, - росту ущерба от этих ошибок [9-11]. Поэтому исследование проблемы обеспечения надёжности ПС АСУ СН приобретает важное значение. В работе авторов [1] рассмотрен ряд общих вопросов, связанных с оценкой и обеспечением надежности ПС АСУ СН и определены некоторые первоочередные мероприятия, направленные на решение рассматриваемой проблемы. Настоящая работа отведена анализу основных процессов, направленных на обеспечение надёжности ПС, с учетом их вклада в повышение общей надёжности создаваемых ПС.   Опытным путем установлено, что чем позже обнаружена ошибка в ПС, тем выше затраты на её устранение. Особенно большие затраты и сложности устранения связаны с ошибками, обнаруживаемыми в процессе эксплуатации ПС[5,6,19-21]. На рисунке 1 представлена диаграмма, характеризующая относительные затраты на исправление допущенных ошибок в ПС на различных этапах тестирования и при эксплуатации ПС. Диаграмма составлена по материалам [5,6].                                                                                      Рис.  1. Относительная величина затрат на устранение ошибки в ПС на различных этапах тестирования ПС и при их эксплуатации Соответствующие процедуры осуществления такой проверки получили наименование тестирования, верификации и валидации ПС. В известной литературе существуют некоторые расхождения в трактовке указанных терминов. Поэтому целесообразно внести определенные уточнения, опираясь на  имеющиеся исследования, проведенные в последнее время [1-4]. Тестирование ПС – это процесс исполнения ПС, направленный на обнаружение дефектов (ошибок) в ПС. Здесь важно подчеркнуть два момента – это целевая установка процесса (поиск и обнаружение ошибок) и исполнение ПС (тестирование будем относить лишь к исполняемым элементам ПС). Заданная целевая установка побуждает именно к обнаружению и исправлению допущенных ошибок в ПС, а не к демонстрации работоспособности ПС, что имеет большой практический смысл. И второй момент – понятие «тестирование» следует относить лишь к исполняемым элементам ПС, хотя имеется и более широкая трактовка этого понятия [7]. Однако в отечественной литературе утвердилась приведенная выше трактовка, которой и будем далее придерживаться [2-4,14,20-22]. Более общим, чем тестирование, является понятие верификации ПС. Целью процесса верификации ПС является подтверждение того, что верифицируемый объект (описание, проект, программный код и т.д.) соответствует предъявленным ПС требованиям. Процесс верификации включает в себя различного рода проверки (инспекции), тестирование кода, анализ промежуточных документов и т.д. Валидация ПС – это процесс, целью которого является подтверждение того, что  созданные  ПС  удовлетворяют ожиданиям заказчика (пользователя) [8].Иными словами, если в процессе верификации  ПС проверяют их соответствие заданным требованиям, то  при валидации – идут далее, т.е. проверяют соответствие ПС реальным потребностям их применения.  В качестве иллюстрации на рисунке 2 приведено схематическое представление взаимосвязи рассмотренных  понятий.

Реальные потребности применения 
Валидация
Сформулирован-ные требования
Верификация
Код
Тестирование

                  Рис. 2. Взаимосвязь тестирования, верификации и валидации   Вопросы проведения валидации ПС часто связываются с заключительными этапами создания ПС, когда в процессе демонстрации ПС Заказчик начинает осознавать, что заданные им требования к ПС не вполне адекватно отражают его реальные потребности в ПС. Компромисс обычно достигается за счёт корректировки требований и соответствующей доработки ПС. Такой процесс достаточно трудно формализуем, и требует рассмотрения с учетом полной конкретики решаемых задач. Достаточно полное представление о рассматриваемых процессах оценки и обеспечения качества (надёжности) ПС, по-видимому, содержится в стандарте [7]. Общая схема процессов, затрагиваемых в этом стандарте, включает четыре базовых процесса: -статические проверки; -динамическое тестирование; -демонстрация возможностей; -анализ в рамках верификации и валидации ПС. Каждый из этих процессов, в свою очередь включает ряд подпроцессов. Так процесс статических проверок включает подпроцессы инспекций, обзоров, модельной верификации и статического анализа документов, связанных с разработкой ПС. Каждый из этих подпроцессов имеет свои особенности, вытекающие из практики создания больших систем ПС. Общим является то, что все действия по статической проверке ПС осуществляются без исполнения программного кода и основываются на рассмотрении и анализе сформулированных требований (спецификации требований, техническое задание), описаний проектных решений (эскизный и технический проекты), исходных кодов (тексты программ), руководств и инструкций, планов проверок и  испытаний ПС и т.д. Опыт разработки больших систем ПС показывает, что такие проверки позволяют выявить существенные, глубинные просчёты при создании ПС и, в конечном счёте, выражаются в экономии материальных затрат и времени на создание ПС. Динамическое тестирование ПС обычно подразделяют на две большие  группы: (1) Тестирование на базе спецификаций (стратегия «чёрного ящика»); (2) Тестирование на базе структуры ПС (стратегия «белого ящика»). Рассмотрим эти подходы подробнее. Стратегию «чёрного ящика» называют  также  тестированием с управлением по данным, или тестированием с управлением по входу-выходу.  При этом тестируемое ПС рассматривается как некий «черный ящик», внутренняя структура которого не анализируется.  Задача тестирования заключается в том, чтобы проверить  работоспособность ПС на совокупности сочетаний возможных исходных данных. Ясно, что такая задача может быть решена строго (с уверенностью 100%), если в качестве тестовых последовательностей будут использованы все возможные наборы входных данных. Однако достичь этого при тестировании реальных ПС, как правило, не удаётся ввиду чрезвычайно большого  количества таких наборов данных. Поэтому на практике обычно применяют компромиссный подход, основанный на анализе совокупности входных данных тестируемого ПС и построении  множества таких их наборов, которое бы обеспечивало наиболее вероятное «покрытие входа» решаемой задачи. Стратегию «белого ящика» называют также тестированием, управляемым логикой программы. Существо его сводится к тому, чтобы на базе исследования внутренней логики ПС построить тестовые последовательности, обеспечивающие прохождение различных разветвлений информационно-вычислительного процесса. На первый взгляд представляется, что достаточно построить такой набор тестовых последовательностей подобного рода, в котором бы каждый оператор выполнялся хотя бы один раз, и задача тестирования будет решена. На самом деле проверка ПС связана не только с выходом на каждый оператор, но и с исходными данными, подаваемыми на каждый оператор. Анализ показывает, что в итоге опять приходим к «проклятию размерности», то есть к необходимости построения чрезвычайно большого набора входных данных для исчерпывающего тестирования маршрутов в ПС. В свою очередь в каждой из этих групп используется некоторое число специфических методов тестирования. Представленный, например, в стандарте [7] набор существующих методов тестирования ПС включает около двадцати наименований, что  говорит о важности и сложности решения рассматриваемой проблемы. Количество методов в каждой из групп (1) и (2) – более десятка. Выбор среди этих методов представляет далеко не простую задачу для исследователя. В целом решение такой  задачи должно основываться на практическом опыте тестирования ПС. В качестве основных  в плане оценки  надёжности ПС стандарт [7] рекомендует использовать следующие четыре метода из группы методов на базе спецификации ПС: -случайное тестирование; -тестирование на базе переходов между состояниями; -тестирование возможных ошибок; -тестирование на базе анализа граничных значений. Охарактеризуем кратко эти методы. Модель случайного тестирования основывается на определении набора  возможных значений входных  данных объекта тестирования. Функция распределения входных данных при этом может быть выбрана на основе ожидаемого распределения реального входного потока. При отсутствии информации о распределении входного потока обычно принимают равномерное распределение. Модель тестирования на базе переходов между состояниями основана на определении совокупности состояний, которые может занимать объект тестирования, а также переходов между этими состояниями и результатов таких переходов. Состояния модели должны быть различимы, определены, а их число – конечно.  Тестирование возможных ошибок основывается на модели выявления возможных ошибок, набор которых определяется на основе имеющихся знаний и опыта работы с подобными объектами тестирования. Модель тестирования на базе анализа граничных значений связывается с разделением входных и выходных данных объекта тестирования на некоторое число наборов с определяемыми границами. Значения на границах, внутри и вне их  определяются в зависимости от требуемого уровня покрытия объекта тестирования. Тестирование в рамках стратегии белого ящика выражается в достижении рациональной степени покрытия тестами логики программы. При этом различают следующие основные методы [5,7]: -покрытие операторов; -покрытие решений; -покрытие условий; -покрытие решений-условий; -комбинаторное покрытие условий. Рассмотрим кратко указанные подходы. Метод покрытия операторов предполагает, что набор тестов должен быть построен таким образом, чтобы обеспечить использование каждого оператора по крайней мере один раз. К сожалению, такой критерий покрытия является достаточно слабым, поскольку не позволяет обнаруживать целый ряд ошибок, обусловленных, например, неверной записью переходов в программе. Более сильным является метод покрытия решений, согласно которому формируется набор тестов, обеспечивающих принятие на каждом решении значений «истина» и «лож», по крайней мере, один раз. Иначе говоря, каждое направление перехода в программе должно быть реализовано хотя бы один раз. Покрытие решений обычно удовлетворяет условию  покрытия операторов.  Поскольку каждый оператор лежит на некотором пути, то при выполнении каждого перехода каждый оператор должен быть выполнен. Вместе с тем возможны и специальные варианты, не укладывающиеся в эту схему. Например, в случае наличия нескольких входов в программу. Более сильным, по сравнению с предыдущими,  является метод покрытия условий. Этот метод требует такого набора тестов, который был бы достаточен для того, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз. Однако поскольку покрытие условий также не всегда приводит к выполнению каждого оператора, то этот метод требует дополнительных усилий по обработке, например, ситуаций с несколькими входами. Метод покрытия решений/условий требует такого набора тестов, при  котором бы все возможные результаты каждого из условий в решении выполнялись, по крайней мере, один раз,  все результаты каждого решения выполнялись бы, по крайней мере, один раз и каждой точке входа передавалось управление не менее, чем один раз. Метод является достаточно мощным, однако он недостаточно чувствителен к ошибкам в логических выражениях. Метод комбинаторного покрытия условий лишен указанных недостатков. Этот метод требует создания такого числа тестов, при котором все возможные комбинации результатов условия в каждом решении и все точки входа выполнялись бы, по крайней мере, один раз. Как видно из проведенного анализа, методы тестирования, применяемые в рамках  стратеги «белого ящика» достаточно трудоёмки и требуют детального ознакомления со структурой и особенностями конкретной реализации исследуемых ПС. Обеспечить выполнение таких требований на практике не всегда удаётся в достаточной мере. Поэтому прикладное использование методов тестирования в рамках стратегии «белого ящика», по-видимому, следует рекомендовать при проведении тестирования ПС на этапах его создания, когда тестирование выполняется силами Разработчика ПС, которому хорошо известны все особенности программной реализации ПС. Как отмечается в [5], тестирование отдельных модулей ПС может быть ориентировано на использование  стратегии «белого ящика». При переходе к комплексному тестированию ПС уже более рациональным является использование стратегии «черного ящика».    На тех этапах, на которых ответственность за принятие решений возложена на Заказчика ПС,  также целесообразно использовать методы стратегии «чёрного ящика». Заметим, что в дополнение к рассмотренным группам стратегий тестирования ПС иногда добавляют третью – тестирование на базе имеющегося опыта. Однако этот подход не является систематизированным и не получил большого распространения. Обратимся теперь к процессам демонстрации ПС. Здесь принято различать следующие подпроцессы, заключающиеся в исследовании: - прототипа ПС; -версии ПС для пользователя (заказчика); -пробной версии ПС (mock-up). Различие между этими подпроцессами  заключается в степени реализации задаваемых требований к ПС. В прототипе ПС обычно реализованы все основные требования и задача заключается в демонстрации пользователю возможностей ПС. Версия ПС для пользователя это – рабочий вариант ПС, который передается Заказчику для использования в работе с тем, чтобы в последующем учесть и реализовать возможные замечания. Пробная версия ПС  (mock-up) имеет основной целью отработку человеко-машинных интерфейсов до наиболее приемлемого Заказчиком варианта. Далее следуют процессы анализа всего накопленного, в результате реализации предыдущих процессов, материала в интересах верификации и валидации ПС. Для этих целей используется широкий ассортимент методов и подходов, включая моделирование и расчёты с помощью формальных математических методов, доказательства на базе алгебры логики и т.д.[7,15-18]  В итоге проведенного анализа можно сделать следующие основные выводы. (1) Вопросы обеспечения надёжности ПС приобретают всё более важное значение по мере развития возможностей систем и комплексов управления специального назначения. (2) На международном уровне отработана и рекомендована для практического использования определённая последовательность процедур поддержки процессов разработки ПС, ориентированная на создание высоконадёжных ПС. Соответствующие процедуры определены на уровне международных стандартов. (3) При практической организации работ по созданию высоконадёжных ПС особое внимание следует обращать на внедрение методов и способов обеспечения надёжности ПС на ранних этапах создания ПС, поскольку стоимость последующего исправления допущенных на этих этапах ошибок в ПС существенно возрастает.       Библиографический список 1 Балыбердин В.А., Белевцев А.М., Степанов О.А. Вопросы оценки и обеспечения надёжности программных средств АСУ специального назначения. . Таганрог, Известия ЮФУ, Технические науки, №5, 2014г., с.115-120. 2  Кулямин В.В. Методы верификации программного обеспечения.- М.: ИСП РАН, 2008.- 117с. 3 Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. – М.: МИФИ (ГУ), 2006. – 157с. 4 Степанченко И.В. Методы тестирования программного обеспечения. – Волгоград: РПК «Политехник», 2006. – 77с. 5 Майерс Г. Искусство тестирования программ / Пер. с англ. под ред. Б. А. Позина. –М.: Финансы и статистика, 1982. – 176 с. 6 Майерс Г Надёжность программного обеспечения. ./Пер. с англ. Под ред.В.Ш.Кауфмана. – М.:Мир, 1980.-360с. 7 ISO/IEC 29119-1. Systems and Software Engineering – Part 1: Concepts and Definitions.- 2012. 8 ISO/IEC 25010. Systems and Software Engineering. - Systems and Software Quality Requirements and Evaluation.- 2010. 9 Липаев В.В. Надёжность программных средств. - М.: Синтег, 1998. - 222с. 10 Полонников Р.И., Никандров А.В. Методы оценки показателей надёжности программного обеспечения. - СПб.: Политехника, 1992. - 78с. 11 Штрик А.А., Осовецкий Л.В., Мессих И.Г. Структурное проектирование надёжных программ встроенных ЭВМ. - Л.: Машиностроение, 1989. - 296с. 12 Холстед М.Х. Начала науки о программах./Пер. с англ.В.М.Юфы.- М.: Финансы и статистика, 1981. -128с. 13 Липаев В.В. Процессы и стандарты жизненного цикла сложных программных средств. Справочник. – М., Синтег, 2006.- 260с. 14 Василенко Н.В., Макаров В.А. Модели оценки надёжности программного обеспечения. – Вестник Новгородского государственного университета, №28.- Новгород, 2004, с.126-132. 15 Степанов О.А., Шумило Д.А.Метод оценки программных средств АСУВ по результатам тестирования. – Материалы всероссийской конференции «Современные тенденции развития теории и практики управления в системах специального назначения». – М.: Системпром, 2014. – с.11-14. 16 Балыбердин В.А., Белевцев А.А., Степанов О.А. Об  оценке компонентов информационного и лингвистического обеспечения АСУ. - Таганрог, Известия ЮФУ, Технические науки, № 5, 2013г.- с. 34-40. 17 Балыбердин В.А., Степанов О.А. Шумило Д.А. К оценке надёжности программных средств АСУВ. Актуальные проблемы защиты и безопасности. Труды 14-й Всероссийской научно-практической конференции. Вооружение и военная техника. Том 1. С.-Петербург, 2011, с.603-608. 18 Балыбердин В.А., Пенкин О.М., Полунин А.И. Проблемные вопросы создания и внедрения новых информационных технологий в автоматизированных системах военного назначения. – М.: СВТП РИА, 2001, 144 с. 19 Балыбердин В.А., Зубарев И.В., Панов В.В., Степанов О.А. Прикладные аспекты автоматизации управления войсками и оружием в современных условиях. – М.: 3 ЦНИИ МО РФ, 2013. - 240 с. 20 Липаев В.В. Надёжность и функциональная безопасность комплексов программ реального времени. – М.: ИСП РАН, 2013.- 176с. 21 Липаев В.В. Функциональная безопасность программных средств.- М.: СИНТЕГ, 2004. - 348 с. 22 Жоголев Е.А. Технология программирования. – М.:Научный мир, 2004. – 216с. 23 Kauffels F.-J. Practical LANs analised.- N.Y.-Toronto: Ellis Horwood Limited, 1989.-334p. 24 Gorner birgit. Novell Netware.-Munchen: Markt&Technic AG,1990.-260p.