Испытание программных средств

Содержание Введение . Определение испытания и их цель Методики проведения испытаний . Подготовка испытаний и схема их проведения
Стадии испытаний Типы испытаний . Приемосдаточные испытания опытного образца Особенности испытаний на надежность программ . Достоверность определения качества программ при испытаниях . Исходные и отчетные документы при испытаниях программ Задачи сопровождения программ Этапы подготовки и внесения изменений в комплекс программ Тиражирование и использование версий программ Сертификационные испытания . Аттестационные испытания программных средств Заключение . Список источников и литературы . Приложение . Введение. В настоящее время в самых различных сферах народного хозяйства, военного дела и других отраслях человеческой деятельности получили широкое применение персональные ЭВМ (ПЭВМ). Сложность их программного обеспечения (ПО) достигла значительных величин. В дальнейшем будет наблюдаться её всё более прогрессирующий рост. В работе [8] отмечается: “в мире постоянно происходят катастрофы, большие и малые аварии и всё чаще их причиной становится ненадёжное функционирование компьютерных систем, и в частности, их программного обеспечения. Оборона, авиация и космос, медицина, технологические процессы на современных ядерных, химических и других производствах – вот неполный перечень тех предметных областей, где низкое качество ПО и даже единичные дефекты в нём находят воплощение в терминах человеческих жизней и разрушенных материальных ценностей”. Над подобными “ответственными” системами работает целая отрасль с огромными денежными затратами, располагающая значительным количеством высококвалифицированных программистов и проектировщиков, хорошо поставлен менеджмент, отлажены процессы разработки, испытаний и контроля. И, тем не менее, ПО даёт порой такой сбой, резонанс от которого бывает весьма громким [8]. Основными причинами проявления ошибок ПО являются недостаточно высокий уровень технологии производства программных средств и их чрезмерная сложность. И несмотря на то, что в области качества и надёжности программных средств за последнее время достигнуты определённые положительные результаты и ошибки в процессе функционирования ПО сравнительно редки, проблема обеспечения высокой надёжности сложного ПО остаётся достаточно злободневной. Для решения данной проблемы нужен комплексный, системный подход. Конечно, охватить все стороны данной проблемы в отдельной статье невозможно. Причина обращения к данному принципу в теории надёжности техники и ПО одна и та же. Современная теория оперирует с численными оценками. Хорошо известно парадоксальное противоречие: чем более надёжный продукт мы создаём, тем труднее оценить и подтвердить его надёжность. Однако на практике эту задачу как-то необходимо решать, чтобы при реализации системой цели можно было принять правильное решение. Сжатие информации об ошибках системы во времени в данном случае есть единственный выход из ситуации, когда в процессе её испытаний в реальном времени может не хватить ни времени испытаний, ни ресурсных затрат, или, в крайнем случае, сама система может морально устареть [16]. Многие организации, занимающиеся созданием программного обеспечения, до 30% средств, выделенных на разработку программ, тратят на испытания, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовло­жения, знаний о сути испытаний явно не хватает и большинство программных продуктов ненадежно. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования. Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет оснований утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами. Надежность невозможно внести в программу в результате тестирования, она определяется пра­вильностью этапов проектирования. Наилучшее решение проблемы надежности — с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Испытания таких программ, как системы реального времени, операционные системы и программы управления данными, которые сохраняют «память» о предыдущих входных данных, особенно трудны. Нам потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Поэтому исчерпывающее тестирование для всех входных данных любой разумной программы неосущест­вимо. Испытание является завершающим этапом разработки. Ему предшествует этап статической и динамической отладки программ. Основным методом динамической отладки является тестирование. В узком смысле цель тестирования состоит в обнаружении ошибок, цель же отладки—не только в обнаружении, но и в устранении ошибок. Однако ограничиться только отладкой программы, если есть уверенность в том, что все ошибки в ней устранены, нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа может не обладать определенными потребительскими свойствами и тем самым быть непригодной к использованию по своему назначению. Не может служить альтернативой испытанию и проверка работоспособности программы на контрольном примере, так как программа, работоспособная в условиях контрольного примера, может оказаться неработоспособной в других условиях применения. Попытки охватить контрольным примером все предполагаемые условия функционирования сводятся, в конечном счете, к тем же испытаниям. Определение испытания и их цель Для программ, создаваемых на уровне продукции производственно-технического назначения и отчуждаемых от разработчика, испытания являются одним из важнейших этапов жизненного цикла, на котором проверяются и фиксируются достигнутые показатели качества программного средства (ПС). В соответствии с ГОСТ 16504—81 под испытанием промышленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функционировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.
Целью испытания является экспериментальное определение фактических (достигнутых) характеристик свойств испытываемого ПС и определение степени соответствия созданного комплекса программ техниче­скому заданию, полученному от заказчика. Эти характеристики могут быть как количественными, так и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПС к использованию по своему назначению. Если вывод отрицательный, то образец ПС возвращается на доработку. Таким образом, перекрывается доступ недоброкачественной продукции к пользователю, Непосредственно в ходе испытаний качество ПС может и не измениться, так как локализация ошибок не является целью испытания. Вместе с тем некоторые дефекты в программах и документации могут устраняться по ходу испытания [11].
В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие “испытание” часто отождествляют с понятием “тестирование”. Например, в Std IEEE 829—1983 “Документация тестов программного обеспечения” (США) дано следующее определение тестирования: “ .процесс активного анализа ПО на предмет обнаружения расхождения между реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с целью оценки характеристик элементов ПО”. Данное определение объединяет два приведенных определения термина “испытание” с той лишь разницей, что при принятой концепции поиск и локализация ошибок не являются явно выраженными целями испытания. С учетом высказанных соображений термин “тестирование”, используемый в зарубежной литературе, будем интерпретировать как испытание методом тестирования. Важная осо­бенность испытаний программы состоит в наличии достаточно полных эталонов, которым должен соответствовать комплекс программ, — тре­бований технического задания. За относительно короткий период приемосдаточных испыта­ний трудно провести достаточно полное тестирование, демон­стрирующее достигнутое качество сложного комплекса программ. Поэтому для обеспечения их высокого качества в техническом задании целесообразно задавать технологию его проектирования и усло­вия поэтапной проверки основных компонент в процессе разра­ботки. Для этого до начала разработки в процессе формирования технического задания формируются основы методики тестирова­ния и проверяемые характеристики программ при испытаниях. В этом случае испытатель получает возможность поэтапно и глубо­ко знакомиться с создаваемым изделием и подготовиться к испыта­ниям программных средств. Одновременно уточняются и конкретизируются техни­ческое задание и методика тестирования программ на завершаю­щих приемосдаточных испытаниях. Длительность испытания зависит от типа, конфигурации (сложности) ПС, а также от целей и степени автоматизации рассматриваемого технологического процесса. При испытании операционных систем она колеблется от одного до шести месяцев. Сложные программные комплексы после интеграции могут испытываться и более длительное время. Составлению плана проведения испытаний должен предшествовать анализ Т3 на разработку ПС, структурных и функциональных схем, режимов функционирования, зависимостей между модулями программы, планов-графиков разработки и отладки компонентов ПС, результатов контроля их качества на ранних стадиях разработки. В результате этого анализа необходимо разработать и обосновать общую стратегию испытания, а на ее основе — комплекс документов по организации испытаний, который должен содержать ответы на следующие вопросы: 1. задачи испытаний на каждой фазе, последовательность развития фаз; 2. используемые специальные испытательные средства; 3. количество необходимого машинного времени на каждой фазе испытаний; 4. конфигурация общего технического и программного обеспечения; 5. оцениваемые свойства, критерии оценки, способы их получения; 6. процедуры контроля хода испытания; 7. процедуры регистрации, сбора, обработки и обобщения результатов испытания; 8. условия (критерии) начала и завершения каждой фазы испытаний. По каждому из этих вопросов необходимо определить ответственных исполнителей, сроки выполнения работ, вид конечного результата [12]. Проанализировав содержание выделенных разделов плана испытания/тестирования, можно сделать вывод о целесообразности включения сведений, содержащихся в этих разделах, в программы и методики испытания ПС. Такое включение будет способствовать повышению информативности этих документов и упорядочению самого процесса испытаний. Методики проведения испытаний Существует несколько различных методик проведения испытания, но заранее хочу отметить, что, как правило, используют несколько вариантов сразу. 1. Анализируют весь диапазон входных данных. На основе анализа заранее готовят такое множество комбинаций данных (тестовых наборов данных), которое охватывает наиболее характерные подмножества входных данных. Программу рассматривают как черный ящик. Испытания сводятся к последовательному вводу тестовых наборов данных и анализу получаемых результатов. 2. Анализируют множество ситуаций, которые могут возникнуть при функционировании ПС. Выбирают наиболее характерные ситуации. Каждую из них выражают через тестовый набор входных данных. Далее сущность испытания и анализа результатов сводится к подходу 1; 3. С помощью графовой модели анализируют микроструктуру ПС. Выбирают множество путей, которое полностью покрывает граф-схему ПС, и такую последовательность тестовых наборов исходных данных, выполнение которой будет проходить по выделенным путям. Организация испытаний аналогична подходам 1 и 2; 4. ПС испытывают в реальной среде функционирования; 5. ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде. Ни один из этих подходов не является универсальным. Каждый из них имеет свои преимущества и недостатки, которые в разной степени проявляются в зависимости от специфики испытываемого ПС. Например, подход 1 может оказаться предпочтительным, если диапазон входных данных обозрим, сравнительно легко анализируется и систематизируется, и неприемлемым — в противном случае. Наиболее достоверные результаты получаются при испытаниях в реальной среде функционирования (подход 4). Но такие испытания редко удается осуществить. Поэтому на практике используют комбинации всех видов. Типичным примером такой комбинации может служить смешанный метод, когда среда функционирования ПС моделируется, а достоверность результатов проверяется путем сравнения с результатами, полученными при функционировании ПС в реальной среде. Анализ показывает, что абсолютная проверка ПС ни при одном из рассмотренных подходов не осуществима. Поэтому при планировании испытаний необходимо предварительно анализировать структуры испытываемых программ и входных данных. В частности, следует устанавливать те пути граф-схемы программы, использование которых при преобразовании данных наиболее вероятно. Эта задача аналогична подходам 1 и 2. Для сложных программных комплексов она не имеет строго математического решения. Вместе с тем на практике нередко удается заранее установить наиболее вероятные ситуации, которые могут возникнуть в автоматизируемой системе, а, следовательно, и наборы входных данных, описывающие эти ситуации.
Методика решения задачи планирования испытания включает в себя следующие этапы: — нахождение всех путей реализации; — выделение минимального подмножества путей, обеспечивающих проверку всех участков программы; — разработка тестов для проверки выделенных путей. Необходимо отметить, что в результате решения получают не одно подмножество путей, а некоторую совокупность таких подмножеств. Анализируя эти совокупности по критериям минимального времени реализации их на ЭВМ, выбора наиболее вероятных путей, отсутствия в этих совокупностях несовместимых путей (рассмотренным методам присущ этот недостаток), выбирают наиболее приемлемую совокупность. Для формирования входных данных тестирования для каждого выделенного пути реализации составляют специальные таблицы. В таблицах представляют только условные операторы, принадлежащие данному пути, и операторы, в которых вычисляются переменные управления. В результате анализа предписаний, удовлетворяющих условным операторам, вырабатывают входные данные тестирования.
Несмотря на то что проверка всех путей граф-схемы большой программы неосуществима, при планировании испытаний необходимо при заданных ресурсах обеспечить максимальную полноту проверки, особенно проверки модулей решения наиболее ответственных задач. Стремление избежать при этом неэффективного простого перебора приводит к задаче выбора минимального количества путей, покрывающих граф ПС. Под покрытием понимают включение всех дуг графа. Минимальное покрытие, с одной стороны, обеспечивает минимум тестов и контрольных просчетов, а, с другой стороны, гарантирует прохождение каждой дуги графа хотя бы по одному разу. Рассмотренный метод планирования на этапе автономных статистических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориентация на тот или иной подход к испытаниям зависит от типа испытываемого ПС [2]. Подготовка испытаний и схема их проведения. Любому виду испытаний должна предшествовать тщательная подготовка. В подготовку испытаний ПС входят следующие мероприятия: — составление и согласование плана-графика проведения испытания; — разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях; — анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний; — анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС; — проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях; — разработка, согласование и утверждение программ и методик испытаний; — аттестация специалистов на допуск к проведению испытаний; — приемка испытываемого опытного образца ПС на носителе данных и документации; — проведение мероприятий, направленных на обеспечение достоверности испытаний. Особо следует подчеркнуть необходимость заблаговременной разработки и испытания всех программно-технических средств, которые будут использоваться при проведении испытаний. При этом следует иметь в виду, что уровень точности и надежности измерительной аппаратуры, используемой при испытаниях любого объекта, должен быть значительно выше соответствующих показателен испытываемого объекта. Поэтому реальные характеристики программно-технических испытательных средств необходимо установить заранее, а их приемлемость согласовывать между разработчиками, испытателями и заказчиками ПС. Пренебрежение этим правилом вызывает недоверие к результатам испытания и, как следствие, удлинение сроков испытания. Сложность программно-технических испытательных средств, требования к их совершенству, а следовательно, и затраты ресурсов на их разработку прямо пропорционально зависят от соответствующих показателей испытываемых ПС. Объем испытательных программных средств, выраженный в машинных командах, может достигать объема испытываемых с их помощью программ. Поэтому разработка программно-технических средств, предназначенных для испытания особо сложной ПП, должна начинаться одновременно с разработкой опытных образцов продукции. Для повышения эффективности испытания, его ускорения и удешевления необходимо разработать научно обоснованные методы, средства и методики, позволяющие преодолеть недостатки подхода к испытанию, недооценку его роли в обеспечении требуемого уровня качества ПП, подмену испытаний процедурами типа проверки работоспособности на контрольном примере и т. п. Эта цель может быть достигнута лишь путем разработки технологической схемы испытаний, предусматривающей: — знание назначения испытываемого ПС, условий его функционирования и требований к нему со стороны пользователей; — автоматизацию всех наиболее трудоемких процессов и прежде всего моделирование среды функционирования, включая искажающие воздействия; — ясное представление цели и последовательности испытания; — целенаправленность и неизбыточность испытания, исключающие или минимизирующие повторение однородных процедур при одних и тех же условиях функционирования испытываемого ПС; — систематический контроль за ходом, регулярное ведение протокола и журнала испытания; — четкое, последовательное определение и исполнение плана испытания; — четкое сопоставление имеющихся ресурсов с предполагаемым объемом испытания; — возможность обеспечения, а также объективной количественной оценки полноты и достоверности результатов испытания на всех этапах. На основании изложенного можно определить следующие пять этапов испытания. 1. Обследование проектируемого ПС, анализ проектной документации. 2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию. 3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания. 4. Разработка (освоение) испытательных программно-технических средств, библиотек тестов и баз данных (если они требуются). 5. Непосредственное проведение испытаний, анализ результатов, принятие решения [3]. Стадии испытаний Следует выделить три стадии испытания: подготовительную; непосредственные испытания; заключительную (подготовка отчетных материалов). Подготовительная стадия наиболее длительная и наиболее трудоемкая. Основными ее задачами являются: — планирование испытаний; — разработка технологической схемы испытаний и испытательных средств; разработка программ и методик испытания; — накопление предварительных статистических данных, характеризующих ПС. Целенаправленность и четкость организации работ по накоплению статистических данных может существенно повысить достоверность оценки качества ПС, исключить дублированные (повторные) проверки и уменьшить сроки испытаний и затрачиваемые материальные ресурсы. Однако в некоторых случаях из-за плохой организации работы результаты тестирования на этапах отладки программ и предварительных испытаниях не регистрируются, поэтому не могут использоваться для окончательной оценки качества программы.
Между выделенными стадиями испытания ПС имеются прямые и обратные связи, аналогичные связям между этапами жизненного цикла ПС. Это означает, что при выполнении работ заключительной стадии может быть выявлена необходимость возвращения к стадии непосредственных испытаний (или даже к подготовительной стадии) для уточнения отдельных характеристик.
План проведения испытаний должен быть ориентирован на обеспечение всесторонней проверки ПС и максимальной (заданной) достоверности полученных результатов при использовании ограниченных ресурсов, выделенных на испытаниях. В общем случае при планировании и организации испытаний следует искать компромиссное решение, учитывающее два противоречивых требования: обеспечение максимальной достоверности обобщенной оценки качества ПИ и выполнение испытания в ограниченное время с использованием ограниченных ресурсов. На проведение испытаний ПП приходится затрачивать значительные трудовые и материальные ресурсы. Сроки проведения испытаний всегда ограничены. Поэтому перед испытателями всегда стоит задача поиска путей минимизации затрат материальных, трудовых и временных ресурсов для достижения цели испытания. Для реализации этой задачи необходимо установить критерии завершенности Испытаний, которые могут служить основой для принятия решения о завершении испытаний. При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них: 1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, характеристики которых неизвестны; 2) отсутствие общепринятых показателей, а также методов расчета требуемых и фактических значений приводит к тому, что в ТЗ на разработку ПС требования к характеристикам ПС либо фактически отсутствуют (в количественном выражении), либо не претендуют на полноту. Рассмотрим пути решения проблемы оценки завершенности испытаний ПС. Но прежде всего обратим внимание на необходимость тщательного документирования процесса испытания. Такое документирование следует начать с момента приобретения ПС свойства работоспособности и вести его непрерывно до момента передачи ПС в промышленную эксплуатацию. Опыт создания отечественных систем реального времени подтверждает необходимость ведения одного или двух журналов. В одном из них следует регистрировать все эксперименты с ПС, а в другом—обнаруженные ошибки (проблемы) и ход их устранения. Периодически составляют отчеты об испытаниях за определенный период времени. Для ведения журналов необходимо тщательно разработать инструкции, в которых установить общие правила заполнения журналов, в том числе единые правила присвоения регистрационных номеров ошибкам, индексации типов ошибок, классификации ошибок и т. п. В журналах следует предусмотреть отдельные разделы, в которых при необходимости будут даваться подробные комментарии к ошибкам и способы их устранения [4]. Не всякую ошибку можно быстро идентифицировать, поэтому в стандарте IEEE 829—1983 рекомендовано документировать в виде отчетов тест-инцидент все нестандартные события, происходящие во время испытания и требующие дополнительного анализа. Рекомендуется следующая структура этого отчета: идентификатор отчета тест-инцидент, аннотация, описание инцидента, влияние инцидента на последующий ход испытания. Последние два раздела являются основными. Описание инцидента должно включать следующие элементы: входные данные, ожидаемые и фактические результаты, отклонение от нормы, дата и время испытания, шаг процедуры испытания, среда функционирования, результаты попыток повторения условий эксперимента, испытатели, наблюдатели-регистраторы. Регистрация экспериментов и ошибок (инцидентов), периодическая обработка данных и анализ результатов позволяют контролировать испытания и управлять этим процессом. Сама процедура регистрации может быть разной, важно лишь предотвратить потерю ценной информации при минимальных трудозатратах на сбор и обработку данных. Данное условие можно обеспечить только путем максимальной автоматизации всех процессов. Типы испытаний В зависимости от места проведения различают стендовые и полигонные испытания. Под испытательным стендом понимают совокупность технических устройств и математических моделей, обеспечивающих в автоматическом режиме имитацию среды функционирования; поступление входных данных, искажающие воздействия; регистрацию информации о функционировании ПС, а также управление процессом испытания и объектом испытания. Если в основу стендовых испытаний положен принцип моделирования, то соответствующие испытательные стенды называют моделирующими. Испытательным полигоном называют место, предназначенное для испытаний в условиях, близких к условиям эксплуатации, и обеспеченное необходимыми средствами испытания. Полигонным испытаниям подвергают системы, работающие в реальном масштабе времени. В полигонных условиях обычно сочетают натурные испытания с использованием реальных объектов автоматизируемых систем и моделирование некоторых объектов и процессов их функционирования. В последнее. Время в некоторых разрабатывающих организациях создают испытательные полигоны, представляющие собой совокупность специализированных по профилю данной организации испытательных стендов. Такие полигоны имеют общую техническую и информационную базы, а также программные средства организации испытаний. В качестве примера рассмотрим испытания проводимые на комплексном иммитационно-моделирующем испытательном стенде (см. Приложение. Рис 1). В основу создания комплексных имитационно-моделирующих испытательных стендов, используемых для отладки и испытания сложных систем управления в реальном масштабе времени, положена идея имитационного моделирования. Комплексный имитационно-моделирующий испытательный стенд (КИМИС) представляет собой совокупность средств испытываемой системы и их моделей, модели внешней среды и программ обработки результатов моделирования, функционально объединенных на основе испытываемого программного комплекса. Комплексные имитационно-моделирующие испытательные стенды используются при полигонных испытаниях сложных систем. Общая идея создания КИМИС основана на том, что для испытания (исследования) ПС, реализованного непосредственно на управляющей ЭВМ, необходимо моделировать управляемый процесс и имитировать поступление в ЭВМ информации об этом процессе. Испытываемое ПС безразлично к непосредственным источникам информации. Важно лишь, чтобы вся информация была распределена по реальным физическим каналам ЭВМ и временным тактовым интервалам, а также соответствовала заданному (ожидаемому) диапазону условий внешней среды. Сопряжение моделей с реальными средствами системы необходимо для оценки результатов моделирования путем их сравнения с реальными данными. Использование в составе КИМИС непосредственно самого ПС, а не его модели, позволяет получить более достоверные результаты при моделировании и избежать больших дополнительных трудозатрат на разработку модели ПС.
Для создания КИМИС, помимо основной ЭВМ, на которой реализуется испытываемое ПС, используют ЭВМ примерно такой же производительности для реализации комплекса моделей соответствующего назначения. Первую ЭВМ (ВС) обычно называют технологической, вторую—инструментальной. Инструментальная ЭВМ и программное обеспечение образуют КИМИС. Такие КИМИС являются кроссовой системой (КРОСС-КИМИС). Моделируемые (имитируемые) на инструментальной ЭВМ данные передаются в технологическую ЭВМ, где и обрабатываются как реальные данные. Программное обеспечение КИМИС может быть реализовано и на технологической ЭВМ (Резидент-КИМИС). Но такой вариант используется сравнительно редко из-за дефицита памяти и производительности в технологических (управляющих) ЭВМ.
Автоматизированный технологический комплекс (АТК) состоит из элементов следующих типов: управляемый технологический агрегат (УТА), автоматизированная система управления технологическим процессом (АСУ ТП), датчики информации (ДИ) о состоянии управляемого процесса. На вход АТК поступает объект обработки (00), на выход—результат обработки (РО). Если прекратить доступ информации в ЭВМ от реальных физических объектов АТК, а вместо нее вводить адекватную информацию, имитируемую по КИМИС на инструментальной ЭВМ, то процесс функционирования ПО АСУ ТП будет адекватен реальному. Оператор УТА в принципе может участвовать в обоих режимах. Программное обеспечение КИМИС в общем случае состоит из следующих подсистем: моделирования, анализа результатов испытания, регистрации событий (документирования), планирования и управления и базы данных. В состав подсистемы моделирования входят: модель заявок на обработку (МЗ), модель объекта обработки (МОО); модели датчиков информации (МДИ); имитатор помех (ИП); модель управляемого технологического агрегата (МТА). Модель заявок имитирует поток заявок на обработку, исходя из плановых и производственных соображений В соответствии с заданным приоритетом или случайным образом выбирается 00, принимаемый на обслуживание, из совокупности 00, имитируемой МЗ, и его характеристики. Модели датчиков информации являются информационными моделями конкретных типов датчиков информации, используемых в системе управления АТК. Они имитируют выдачу текущих координат характеризующих состояние технологического процесса. Модель управляемого технологического агрегата имитирует управляемый технологический процесс с выдачей соответствующей информации об этом процессе. Имитатор помех в соответствии с заданными вероятностными характеристиками имитирует воздействие случайных факторов на элементы моделируемой системы и управляемый процесс. При этом используется датчик случайных чисел, позволяющий реализовать процедуру “розыгрыш”. Таким образом, подсистема моделирования, имитируя технологический процесс в управляемом агрегате, обеспечивает воспроизведение потока входной информации в управляющую ЭВМ, адекватного этому потоку в реальных условиях эксплуатации АТК. Имитируемый поток входной информации подается на вход испытываемого ПО АСУ и инициирует его функционирование, результатом которого является поток выходной (управляющей) информации, выдаваемый на УТА или его модель. Образуется замкнутый контур управления, адекватный контуру управления в реальном ДТК. Основными компонентами подсистемы анализа результатов испытаний являются: программа выборки результатов преобразования входных данных, программы формирования эталонных значений для анализа правильности результатов, программа сравнения фактических результатов с эталонными и оценки их приемлемости (правильности). Подсистема регистрации событий обеспечивает документирование хода испытаний и регистрацию всех тех характеристик, которые могут быть полезны как для определения значений показателей качества испытываемого ПС, так и для оценки эффективности и состояния самого процесса испытаний. Подсистема планирования и управления на основе анализа состояния испытаний, полученных результатов, проверенных путей граф-схемы испытываемого ПС и поступающих заданий от программистов-испытателей осуществляет планирование экспериментов и подготовку соответствующих исходных данных для подсистемы моделирования. На эту же подсистему возлагается координация действий (инициализация) всех элементов КИМИС. Использование КИМИС позволяет осуществлять комплексную стыковку объектов испытываемой системы и проверку принципов управления задолго до создания всех элементов системы (элемент системы, разработка которого не завершена, заменяется моделью). Применение моделирования позволяет разнообразить условия испытания и сэкономить материальные ресурсы. Комплексные испытательные моделирующие стенды можно использовать не только для испытания программ, но и для отработки взаимодействия всех элементов системы. Сопряжение реальных средств испытываемой системы с их моделями позволяет разнообразить условия испытания и провести полунатурные эксперименты. Можно, например, проверить работу автоматизируемого технологического агрегата, моделируя поведение объекта обработки или, наоборот, промоделировать работу технологического агрегата при работе с реальным объектом обработки. Такие вариации позволяют, с одной стороны, проверять адекватность моделей своим оригиналам и тем самым убеждаться в достоверности результатов статистических испытаний, а, с другой стороны, использовать КИМИС на самых ранних этапах разработки опытного образца ПС для выбора и апробации наилучших проектных решений. Приемосдаточные испытания опытного образца Испытания сложных ПС являются наиболее формализован­ным и регламентированным видом тестирования. Для всесторон­ней проверки опытный образец ПС подвергается испытаниям, главного конструктора (предварительные испытания) и заказчи­ка-пользователя с участием разработчиков (совместные испыта­ния). При испытаниях главного конструктора, которые, зачастую совмещаются с завершением комплексной отладки, производится, по существу, такое же тестирование, что и на совместных испы­таниях, только и меньшем объеме. Эти проверки оформляются документально и являются основанием для предъявления ПС за­казчику на совместные испытания. Любые испытания ограничены допустимым объемом проверок и длительностью работы комиссии, поэтому не могут гарантировать всестороннюю проверку изделия. Для повышения достоверности определения и улучшения харак­теристик ПС после испытаний главного конструктора программы целесообразно на некоторое время передавать на опытную эксплу­атацию в типовых условиях. Это позволяет более глубоко оце­нить эксплуатационные характеристики созданного комплек­са и устранить некоторые ошибки. Опытная эксплуатация ПС проводится разработчиками с участием испытателей и некоторых пользователей, назначаемых заказчиком. Результаты опытной эксплуатации после испытаний главного конструктора могут учи­тываться при совместных испытаниях для их сокращения. В жизненном цикле ПС можно выделить следующие виды испытаний (каждый из которых имеет особенности тестирова­ния):
1. Опытного образца ПС на полное соответствие требованиям технического задания; 2. рабочей версии ПС, адаптированной к условиям конкретного применения; 3. версии модернизированного ПС при сопровождении. Для обеспечения полноты приемосдаточных испытаний опыт­ного образца ПС как программного средства при их планирова­нии целесообразно выделять категории тестирования, во многом аналогичные этапу комплексной отладки.
Функциональное тестирование — наиболее об­ширное и труднее всего систематизируемое. Набор испытатель­ных тестов полностью определяется функциональными задачами и сложностью ПС. Эти тесты должны обеспечивать проверку и демонстрацию заказчику или пользователю качества решения функциональных задач, сформулированных в техническом зада­нии и конкретизированных в документации. Поскольку исчерпы­вающее тестирование для сложных ПС невозможно, большое значение имеют уточнение областей варьирования тестовых дан­ных и выделение областей их изменения, наиболее важных для последующего использования программ [2]. Стрессовое тестирование (в критических ситуа­циях) базируется на классификации областей определения ис­ходных данных и использует граничные или экстремальные значения параметров и условий. Комбинация критических зна­чений и условий испытаний в большинстве случаев очень раз­нообразна, и необходим тщательный анализ для выделения до­статочно представительной выборки. Кроме того, при стрессо­вых испытаниях должно быть показано, что при изменении ис­ходных данных за допустимыми пределами эти ситуации обна­руживаются, селектируются и выдается диагностика о наруше­нии ограничений на условии эксплуатации программ. Тестирование использования ресурсов ЭВМ комплексом программ в значительной степени является стрессовым тестированием. При этом внимание сосредо­точивается на исследовании зависимости объема памяти и дли­тельности решения задач от характеристик исходной информа­ции. Определяются допустимые размерность задач и интенсив­ности потоков исходных данных, при которых возможно нор­мальное функционирование ПС на данной ЭВМ. Тестирование параллельного решения за­дач в многомашинных или многопроцессорных вычислитель­ных комплексах состоит в испытаниях взаимодействия программ и данных при одновременном исполнении компонент ПС. Эти испытания можно разделить на две части: при детерминирован­ных запланированных ситуациях и при случайном нормальном функционировании программ. В первом случае основная проб­лема состоит в создании представительного многообразия ситу­аций параллельного функционирования программ. Вторая часть тестирования может совмещаться с остальными видами испытаний и заключается в основном в выделении случайных тестов и условии, при которых проверяется недетерминированное па­раллельное исполнение программ [6]. Особенности испытаний на надежность программ В теории надежности разработан ряд методов, позволяющих определять характеристики надежности сложных систем: прямые экспериментальные методы определения показателей надежности систем в условиях нормального функционирования и форсиро­ванные методы испытаний реальных систем на надежность. Прямые экспериментальные методы опре­деления показателей надежности программ в нормальных условиях функционирования в ряде случаев весьма трудно использовать при испытаниях из-за большого времени наработки на отказ (десятки и сотни часов). Сложность выяв­ления и регистрации редких отказов, а также высокая стоимость экспериментов при длительном функционировании сложных ПС приводят к тому, что на испытаниях получаются малые выборки зарегистрированных отказов. Кроме того, при таких эксперимен­тах трудно гарантировать представительность выборки исход­ных данных, так как режимы эксплуатации определяются кон­кретными условиями использования данного ПС на испыта­ниях. При испытаниях ПС на надежность функционирования необ­ходимо разделять причины отказов и отказовых ситуаций на обусловленные ненадежностью аппаратуры и ошибками в прог­раммах. Устойчивые отказы аппаратуры селектируются доста­точно просто. Однако кратковременные сбои в аппаратуре и последствия ошибок в программе требуют тщательного анализа для выделения и диагностики их источника. Значительную по­мощь может оказать программа анализа сбоев. Эта программа автоматически регистрирует наличие отказа и отказовой ситуации, а также условия их возникновения, осуществля­ет первичный анализ и классификацию возможных источников аномалий функционирования. Для диагностики и локализации причин отказа обычно требуется дополнительное стохастическое и детерминированное тестирование, которое позволяет либо вы­делить первичную ошибку в программе, либо отнести источник отказа к сбою в аппаратуре. При дополнительном тестирова­нии одна из задач заключается в подготовке стохастических тестов, способных значительно повысить частоту проявления отказов вследствие ошибок. Это позволяет в конце концов за­фиксировать значения тестовых данных, при которых происходит отказ, и детерминированным тестированием локализовать ошибку [1]. На этапе испытаний целесообразно устранять в программах локализованные ошибки. Вследствие этого характеристики на­дежности ПС в среднем улучшаются, однако возможны измене­ния программы, которые их ухудшают. Изменения показателей надежности необходимо связывать во времени с моментами корректировки программ. Анализируя связь между значениями надежности и процессом изменения программ, можно выявить корректировки, которые содержат ошибки и ухудшают надеж­ность. Получающиеся при этом показатели надежности позволяют прогнозировать число ошибок, подлежащих исправлению для до­стижения заданной надежности. Для этого используются мате­матические модели изменения ошибок и основных показателей надежности в зависимости от длительности тестирования. При высокой надежности ПС организуются много­часовые прогоны реального функционирования программ в усло­виях широкого варьирования исходных данных. Такие прогоны позволяют измерить и зафиксировать достигнутые показатели на­дежности и степень их соответствия требованиям технического задания, а также закрепить их в технических условиях на ПС. Форсированные методы испытаний реаль­ных систем на надежность осуществляются путем тестирования ПС при повышенной интенсивности искажений ис­ходных данных с широким варьированием их значений, а также специальным увеличением загрузки ПС выше нормальной. Пла­нирование форсированных испытаний должно предусматривать последующий пересчет полученных показателей надежности на условия нормального функционирования. Для этого необходимо изучать надежность испытываемых программ в зависимости от интенсивности искажений данных или от характеристик пере­грузки ЭВМ и способы пересчета получаемых показателей на нормальные условия эксплуатации. Особым видом форсированных испытаний является тестиро­вание эффективности средств контроля и восстановления прог­рамм, данных и вычислительного процесса. Для этого имитиру­ются запланированные экстремальные условия функционирова­ния программ, при которых в наибольшей степени вызываются средства программного рестарта. При таких испытаниях основ­ная задача состоит в проверке качества функционирования средств повышения надежности, а оценка интегральных показа­телей надежности отходит на второй план [13].
Достоверность определения качества программ при испыта­ниях. Задача испытателей и заказчика при планировании испы­таний состоит в выделении условий и областей изменения пере­менных, которые наиболее важны для последующего использо­вания программы. При этом разработчик контролирует, чтобы планируемое тестирование не выходило из областей, заданных техническим заданием. Испытания за пределами технического задания могут квалифицироваться как его расширение или могут исключаться по требованию разработчика. Важную роль играют оценка и обеспечение близких значений методической и стати­стической достоверностей испытаний. Если высокая методическая достоверность испытаний не может быть использована вслед­ствие ограничений статистики результатов тестирования, то ресурсы на обеспечение методической достоверности оказываются затраченными нерентабельно. Возможны случаи, когда некото­рые неучтенные факторы значительно снижают методическую достоверность, в результате чего может оказаться бесполезным набор большой статистики при испытаниях.
Методическая достоверность испытаний ПС оп­ределяется следующими факторами: — полнотой программы испытаний, корректностью методик те­стирования, степенью охвата возможных условий функциони­рования и областей изменения исходных данных программ; — достоверностью и точностью эталонных значений, с которыми сравниваются результаты тестирования испытываемой програм­мы или которые служат опорными при расчете параметров, зафиксированных в техническом задании; — адекватностью и точностью моделей, используемых для ими­тации внешней среды и их реакции на управляющие воздей­ствия; — точностью и корректностью регистрации и обработки резуль­татов тестирования, а также сравнения полученных данных с требованиями технического задания. До начала испытаний подлежат проверке и паспортизации средства, обеспечивающие получение эталонных данных, сред­ства имитации внешней среды и средства фиксирования и об­работки результатов тестирования. Например, при испытаниях программ, решающих задачи управления воздушным движением, эталонами служат координаты и параметры движения воздуш­ных объектов, получаемые специальными высокоточными радио­локационными станциями по небольшому количеству объектов. Остальная воздушная обстановка может дополняться имитато­рами тестов на базе цифровых вычислительных машин. Резуль­таты функционирования регистрируются в ходе экспериментов и накапливаются либо в управляющей ЭВМ, либо на специаль­ных носителях информации. Сопоставление результатов тестиро­вания с эталонными данными, полученными специальными изме­рителями и сформированными при моделировании, может произ­водиться после завершения экспериментов. На вычислительной машине могут производиться обработка результатов тестирова­ния и расчет параметров, подлежащих проверке на соответ­ствие техническому заданию [7]. Статистическая достоверность испытаний в значительной степени ограничена допустимым объемом и продол­жительностью испытаний. Методы теории планирования экспери­ментов позволяют упорядочение варьировать исходные данные и наиболее эффективно использовать ограниченные ресурсы тести­рования. При планировании испытаний большое значение имеют характеристики средств автоматизации, используемых для ими­тации внешней среды и обработки результатов. Противоречия между необходимой степенью достоверности тестирования и объ­емом анализируемых данных при различных видах испытаний привели к созданию системы автоматизации испытаний различ­ной сложности и глубины проверок. Исходные и отчетные документы при испытаниях программ. Совместные испытания проводятся комиссией заказчика, в кото­рой участвуют главный конструктор разработки и некоторые ведущие разработчики. Комиссия при испытаниях руководствует­ся следующими документами: 1. утвержденным заказчиком и согласованным с разработчиком техническим заданием на комплекс программ; 2. действующими государственными и отраслевыми стандартами на проектирование и испытания программ и на техническую документацию; 3. программой испытаний по всем требованиям технического за­дания; 4. методиками испытаний по каждому разделу требований тех­нического задания. Программа испытаний, методики их проведения и оценки результатов разрабатываются совместно заказчиком и разработ­чиком, должны быть согласованы и утверждены. Они содержат уточнения требований технического задания для данного ПС и должны гарантировать их корректную проверку. Документация на ПС должна полностью соответствовать испытываемым про­граммам, обеспечивать познаваемость системы обслуживающим персоналом, а также обеспечивать возможность развития и мо­дернизации программ для увеличения их жизненного цикла. Программа испытаний — это план проведения серии экспери­ментов. Он разрабатывается с позиции минимизации объема тестирования при заданной и согласованной с заказчиком до­стоверности получаемых результатов. Для этого методами фактор­ного анализа и теории планирования экспериментов определяются последовательность и объем каждого тестирования в процессе проведения испытаний для проверки выполнения требований тех­нического задания при минимальных затратах. Особенно сложно выбрать набор стрессовых ситуаций функционирования сис­темы, при которых следует провести испытания. Программа испытаний должна содержать следующие четко сформулирован­ные разделы: — объект испытаний, его назначение и перечень основных до­кументов, определивших его разработку; — цель испытаний с указанием основных требований техни­ческого задания, подлежащих проверке, и ограничений на прове­дение испытаний; — собственно программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствии с техни­ческим заданием и план тестирования для проверки функциони­рования программ по всем разделам технического задания и до­полнительным требованиям, формализованным отдельными ре­шениями; — методики испытаний, однозначно определяющие все понятия проверяемых характеристик, условия тестирования, средства, ис­пользуемые для испытаний, методики обработки и оценки ре­зультатов тестирования по каждому разделу программы испыта­ний. Большой объем разнородных данных, получаемых при испы­таниях ПС, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами для обработки результатов тестирования становятся методики обработки и оценки результатов. В соответствии с методиками испытаний средства автоматизации должны обес­печивать полноту проверок характеристик по каждому разделу методик и разработку протоколов проверки по пунктам програм­мы испытаний. Сложность ПС и сильная взаимосвязь между их характеристиками приводят к необходимости тщательной форму­лировки всех условий тестирования и значений параметров, при которых должна производиться проверка. Результаты испытаний фиксируются в протоколах, которые обычно содержат следующие разделы: — назначение тестирования и раздел требований технического задания, по которому проводится испытание;
— указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов; — условия проведения тестирования и характеристика исходных данных; — обобщенные результаты испытаний с оценкой их на соответ­ствие требованиям технического задания и другим руководящим документам;
— выводы о результатах испытаний и степени соответствия созданного ПС определенному разделу требований технического задания. Протоколы по всей программе испытаний обобщаются в акте, в результате чего делается заключение о соответствии сис­темы требованиям заказчика и о завершении работы с положи­тельным или отрицательным итогом. При полном выполнении всех требований технического задания заказчик обязан принять систему и работа считается завершенной [10]. Однако, как уже отмечалось, для сложных ПС трудно на начальных этапах проектирования предусмотреть и корректно сформулировать все требования технического задания. Поэтому при отладке и испытаниях часто выявляется, что некоторые тре­бования технического задания оказываются невыполненными и иногда даже принципиально не могут быть выполнены при самом добросовестном отношении к этому со стороны разработчика. В этом случае необходима совместная работа заказчика и раз­работчика в поисках компромиссного решения при завершении испытаний и составлении заключения. Некоторые недостатки ПС в процессе испытаний только регистрируются и фиксируются в плане устранения замечаний комиссии, проводившей испытания. Этот план является приложением к акту о результатах испытаний и позволяет отделять последующие доработки от непосред­ственных испытаний. Задачи сопровождения программ Программы явля­ются одним из наиболее гибких видов промышленных изделий и эпизодически подвергаются изменениям в течение всего вре­мени их использования. Иногда достаточно при корректировке внести одну ошибку для того, чтобы резко снизилась надеж­ность программы или ее корректность при некоторых исходных данных. Для сохранения и повышения качества ПС необходимо регламентировать процесс модификации и поддерживать его со­ответствующим тестированием и контролем качества. В резуль­тате ПС со временем обычно улучшается как по функциональ­ным возможностям, так и по качеству решения отдельных задач. Работы, обеспечивающие контроль и повышение качества, а также развитие функциональных возможностей программ, сос­тавляют процесс сопровождения. В процессе сопровождения в программы вносятся изменения, значительно различающиеся причинами и характеристиками; — исправления ошибок — корректировка программ, выдающих неправильные результаты в условиях, ограниченных техничес­ким заданием и документацией; в процессе сопровождения тре­буют около 20 % общих затрат; — регламентированная документами адаптация к условиям кон­кретного использования, обусловленным характеристиками внеш­ней среды или конфигурацией аппаратуры, на которой предстоит функционировать программам, — около 20 % общих затрат; — модернизация — расширение функциональных возможностей или улучшение характеристик решения отдельных задач в соот­ветствии с новым или дополненным техническим заданием на ПС — до 60 % общих затрат [2]. Первый вид изменений является непредсказуемым и его труд­но регламентировать. Остальные виды корректировок носят упо­рядоченный характер и проводятся в соответствии с заранее подготавливаемыми планами и документами. Эти корректировки в наибольшей степени изменяют программы и требуют наиболь­ших затрат. Поэтому изменения, обусловленные ошибками, в большинстве случаев целесообразно по возможности накап­ливать и реализовывать, приурочивая к изменениям, регламен­тированным модернизациями. Однако некоторые ошибки могут приводить к необходимости срочного исправления программ. В этих случаях допустимо некоторое отставание корректировки документации при более срочном и регистрируемом исправле­нии самих программ. Со временем, иногда через десятки лет, сопровождение ПС прекращается. Это может быть обусловлено разработкой более совершенных ПС, прекращением использования сопровожда­емого или нерентабельным возрастанием затрат на сопровожде­ние. Для того чтобы со временем прийти к обоснованному ре­шению о прекращении сопровождения, необходимо периодически оценивать эффективность эксплуатации и возможный ущерб от отмены сопровождения. В некоторых случаях решение о прекра­щении сопровождения принимается при противодействии со сто­роны отдельных пользователей. Этапы подготовки и внесения изменений в комплекс про­грамм. Некоторые некорректные изменения эксплуатируемых программ могут вызывать значительный ущерб, поэтому необхо­димо их селектировать и тщательно проверять. На завершающих стадиях комплексной отладки в процессе эксплуатации и со­провождения сложных ПС применяются методы конфигу­рационного управления. Конфигурационное управление необходимо и особенно эффективно при сопровожде­нии широко тиражируемых очень сложных ПС, используемых одновременно в нескольких версиях. Предположим, что сопро­вождается сложный ПС (объемом в 105 .107 команд), прошедший испытание опытного образца и уже имеющий n-ю версию. Этот ПС используется в течение 10 .20 лет многими пользователями, у каждого из которых адаптируется к конкретным условиям применения. Схема конфигурационного управления при сопровождении ПС между n-й и (n+1)-й версиями с учетом тиражирования и возможности прекращения сопровождения представлена на рис. 2 (см. Приложение). Ошибки и предложения изменений первоначально селектируются специалистами но компонентам ПС и анализиру­ются советом конфигурационного управления по их влиянию на качество функционирования программ и затратам на осуществле­ние изменений. Каждое предлагаемое изменение программ оцени­вается по следующим критериям: — насколько данное изменение может улучшить эксплуатацион­ные характеристики ПС в целом; — каковы затраты на выполнение корректировок в новой вер­сии и их распространение пользователям; — возможно ли и насколько сильно влияние изменения на функ­циональные характеристики остальных компонент данного ПС; — какова срочность извещения пользователей о разработанной корректировке и целесообразно ли ее распространять до под­готовки очередной версии; — для какого числа пользователей может быть полезным данное изменение; — как данное изменение отразится на эксплуатации пользо­вателями предыдущих версий; — насколько подготовка данного изменения может отразиться на сроках создания очередной версии. В результате анализа часть предлагаемых изменений отвер­гается, а для тех, которые отобраны для реализации, разраба­тываются корректировки. Особое значение приобретает тестиро­вание подготовленных изменений и испытания выпускаемых версий. Основное тестирование сосредоточивается на проверке корректности каждой выполненной корректировки программ и на качестве функционирования испытываемой эталонной ПС. Проверка функционирования копий может быть ограничена некоторым набором типовых контрольных задач.
В процессе эксплуатации n-й версии ПС у каждого m-го пользователя выявляются некоторые претензии к функционированию, которые пользователем обычно квалифицируются как ошибки эталонной или собственной версии. Однако ряд аномалий обусловлен недостаточной квалификацией пользователя. Для установления достоверности сообщений о всех выявленных ошибках производятся регистрация условий, при которых проявляются аномалии, и предварительное тестирование версии программ для селекции неподтверждающихся ошибок. Часть претензий оказывается несвязанной с коррекцией программ и возникает либо вследствие недостаточной квалификации самого пользователя, либо из-за недостатков документации на ПС, либо вследствие сбоев в аппаратуре ЭВМ.
Установление достоверности ошибок начинается с тестирования эталонной версии ПС при исходных данных m-го пользователя, обнаружившего ошибку. Если проявляется ошибка, то она регистрируется как подтвержденная при зафиксированных тестовых данных. При отсутствии проявления ошибки на эталонной версии при тех же исходных данных целесообразно проводить последующее тестирование копии версии, адаптированной к условиям применения m-го пользователя. Если и при этом ошибка не проявляется, то регистрируется ее неподтверждение, о чем сообщается пользователю и ошибка снимается с учета. Если ошибка подтверждена на версии пользователя, то возможно, что эта версия была неправильно адаптирована к условиям применения. Подготовка и тестирование новой адаптированной версии могут подтверждать проявление ошибки, о которой информировал пользователь, и тогда ошибка регистрируется для последующего анализа. Если ошибка не подтверждается, то регистрируется неправильная адаптация версии пользователем и уточняется причина некорректной адаптации. От пользователя могут поступать также предложения по внесению изменений в (n+1)-ю версию для улучшения эксплуатационных характеристик и расширения функциональных возможностей ПС. Аналогичные предложения могут поступать от разработчиков комплекса. Изменения могут быть направлены на коренное улучшение функциональных возможностей программ или некоторые косметические улучшения реализуемых функций. Ва­рианты небольших корректировок программ целесообразно на­капливать отдельно от предложений по существенному совершен­ствованию системы. Таким образом создается документ — исход­ные данные для планирования доработок и тестирования ПС в процессе сопровождения [9]. Для общения с пользователями и накопления информа­ции о выявляемых недостатках в широко тиражируемых слож­ных ПС целесообразно выделение группы специалистов высокой квалификации, овладевших всеми функциональными возможностями данного ПС. Эта группа сопровождения должна иметь в своем зарегистрированном и аннотированном журнале практи­чески весь комплекс тестов, применявшихся при испытаниях опытного образца и предыдущих версий ПС для антирегресси­онного тестирования. Эти тесты накапливаются, упорядочива­ются и каталогизируются в базе данных тестирования. Они ис­пользуются для контроля сохранности версий и установления достоверности ошибок, сообщенных пользователями. В группе конфигурационного управления сосредоточивается информация для планирования основных операций по доработке и выпуску очередных версий ПС. Специалисты оценивают степень срочности исправления ошибок и проведения модернизаций, а также нахо­дят условия, позволяющие достаточно полноценно эксплуати­ровать программы до выполнения всех запланированных изме­нений при выпуске очередной версии. Для повышения качества очередных версий руководитель сопровождения и совет конфигурационного управления анализи­руют все предлагаемые изменения и выделяют изменения, раз­решенные для данной версии. При выделении изменений при­ходится решать оптимизационную задачу по оценке ущерба от того, что изменение не проведено и не повышается соответ­ственно качество функционирования ПС, и по оценке затрат на проведение изменения и возможного ущерба, если оно содер­жит ошибки. В процессе анализа предполагаемые изменения се­лектируются на группы: 1. срочные изменения, которые должны не только быть внесены в очередную (n+1)-ю версию ПС, но и сообщены пользова­телям для оперативной корректировки программ до внедрения официальной версии; 2. изменения, которые целесообразно внести в (n+1)-ю версию с учетом затрат на их реализацию и улучшения эффективности ПС; 3. изменения, которые требуют дополнительного анализа целесо­образности и эффективности их реализации в последующих вер­сиях и могут не внедряться в ближайшую (n+1)-ю версию ПС; 4. изменения, которые не оправдывают затрат на разработку и выполнение корректировок или практически не влияют на эф­фективность ПС, вследствие чего не подлежат реализации. Для принятых к внедрению изменений разрабатывается план доработок программ и определяется ответственный за каждую корректировку программ. Изменения программ могут потребо­вать либо полной замены модуля или группы программ, либо небольшого изменения текста программного модуля, описания данных или констант. Если изменения в программе или данных невелики, то тестирование стремятся ограничить компонентами, непосредственно связанными с выполненной корректировкой. Од­нако следует учитывать, что корректировки программ в 10 .30 % случаев сами содержат ошибки и требуют тестирования не только техчастей программы. Где внесен изменения. Наличие в программах глубоких межмодульных связей по управлению и по информации вызывают необходимость тестирования и тех компонент, где по первому впечатлению корректировки не оказывают влияния. Такие связи зачастую приводят к появлению вторичных ошибок вследствие проведенных изменений и нарушения функциональной целостности взаимодействующих программ и данных. Тиражирование и использование версий программ. Все корректировки предварительно выполняются и проверяются на версиях программ разработчиков, которые формируются на основе фрагментов подлинника n-й версии ПС. Откорректированные версии компонент подвергаются автономному тестированию, после чего объединяются в группы программ и тестируются в нескольких скомплексированных группах. Проверенные таким образом изменения регистрируются в журнале проведен­ных корректировок для (n+1)-й версии ПС. Объединение групп откорректированных программ позволяет создать эталон (n + 1)-й версии ПС, подлежащий тестированию по программе испытаний. Сложность испытаний зависит от объ­ема выполненных изменений и при большом их количестве может приближаться к испытаниям опытного образца. Объем тестиро­вания при испытаниях (n+1)-й версии согласуется разработ­чиком с заказчиком или основными пользователями. Все про­веренные и подтвержденные при испытаниях изменения программ регистрируются и утверждаются окончательно руководителями конфигурационного управления и главным конструктором. После этого оформляются документация и магнитные носители подлин­ника (n+1)-й версии, которая передается на тиражирование и внедрение у пользователей. В некоторых случаях может быть полезным выпуск извещения для пользователей, объявляющего создание (n+1)-й версии ПС и ее основные отличия от пре­дыдущей версии.
При создании опытного образца ПС реального времени могут предусматриваться в ЭВМ некоторые резервы ресурсов для по­следующего развития программ, однако эти резервы быстро ис­сякают при первых же версиях. При создании очередной (n + 1)-й версии ПС в таких условиях необходимо не только подготовить новые компоненты и корректировки ошибок, но и выделить ре­сурсы ЭВМ для их реализации. Эти ресурсы образуются за счет исключения некоторых компонент программ, что обеспечи­вает освобождение необходимого объема памяти команд и дан­ных, а также сокращение длительности счета при решении задан­ного комплекса задач.
В процессе разработки (n+1)-й версии ПС используются версии i-x подсистем, переписываемых из предыдущей n-й версии. После внесения изменений из i-х подсистем образу­ются j-е версии комплексирования групп программ, которые пос­ле автономного тестирования объединяются в (n+1)-ю версию ПС для испытаний и документального оформления. Все версии разработчиков сопровождаются дубликатами, которые эпизоди­чески тестируются на соответствие основной версии разработ­чика на данном этапе разработки. Корректировку компонент и сборку очередной версии производят специалисты, ответственные за сопровождение с привлечением разработчиков предыдущих версий подсистем [9]. Версия, прошедшая испытания, после оформления акта испы­таний и окончательной корректировки документации превраща­ется в подлинник (n+l)-и версии. Этот подлинник снабжается техническими условиями и тестами для проверки его полной со­хранности и функциональной работоспособности. Для сохранения подлинника должны обеспечиваться особые условия его хранения и периодическое (с интервалами полгода – год) тестирование для проверки отсутствия разрушении. С подлинника копируется дубликат, который используется для подготовки пользовательских копий и, так же как подлинник, подлежит особенно тщательному хранению и периодическому тестированию. Каждая версия m-го пользователя должна снабжаться адаптированными тестами для проверки сохранности и работоспособности программ. При выпуске каждой новой версии стремятся обеспечить преемственность ее функций с предыдущими, а также рассматри­вается возможность прекращения сопровождения некоторой ран­ней версии ПС. В результате среди всего множества версий каждого ПС образуется зона сопровождаемых версий. Число таких сопровождаемых эталонных версий или глубина сопровождения практически всегда не менее двух версий и редко превышает четыре версии. Для сложных ПС это соответствует рациональному времени жизни и тиражирования каждой версии, которое составляет приблизительно 3 .5 лет. При этом полное время жизни и развития ПС может составлять 20 .30 лет, а суммарное число эталонных версий — достигать 20. В ряде областей применения ПС требуются высокие гарантии качества функционирования допускаемых к использованию версий программ. Такие гарантии качества ПС необходимы, например, при автоматизированном управлении объектами или процессами, от которого зависит здоровье или даже жизнь людей (авиация, атомная энергетика, химия). В этих случаях недопустимы ано­малии функционирования программ при любых искажениях исход­ных данных, сбоях аппаратуры и других нештатных ситуациях. Качество ПС должно быть не только проверено разработчиками и пользователями, но и удостоверено особо квалифицированными специалистами, имеющими право на государственную или ведом­ственную сертификацию ПС. Методы сертификации ПС в значи­тельной степени подобны изложенным выше методам тестирования при отладке и испытаниях комплексов программ. Основное отли­чие состоит в более широком варьировании всех исходных данных и условий функционирования программ. Для этого необходимы адекватные модели внешней среды, обеспечивающие весь спектр исходных данных для сертификации. Кроме того специалисты, проводящие сертификацию должны быть независимыми от разра­ботчиков, заказчиков и будущих пользователей ПС. Эти специа­листы имеют право на расширение условий испытаний и на созда­ние нештатных ситуаций для функционирования программ, при которых ПС должны обеспечивать необходимое качество решения задач. При успешных результатах проверок определенной версии ПС на нее оформляется специальный документ — сертификат. Сертификационные испытания В последнее время в различных организациях обращается особое внимание на то, сертифицированы или нет программные средства. Причина в том, что все чаще встречаются программные продукты, потребительские свойства которых не соответствуют предъявляемым требованиям. По экспертным оценкам доля лицензионных ПС, используемых разными государственными организациями, не превышает 10%. В то же время в условиях свободного рынка организации-разработчики ПС вынуждены не только заботиться о качестве своих программных продуктов, но и подтверждать их соответствие установленным требованиям. Использование сертифицированных ПС стало весьма актуальным. Работа во многих сферах уже невозможна без применения компьютерной техники и использования специализированных прикладных программ. Ведомственные интересы требуют усиления контроля за качеством ПС, обеспечением их высоких потребительских свойств, эффективностью затрат на их разработку, эксплуатацию, сопровождение. Именно в связи с этим, а также в целях защиты пользователей программных средств от недобросовестных и непрофессиональных разработчиков создаются испытательные лаборатории программных средств, получающие аккредитацию в Системе сертификации ГОСТ Р (аттестат аккредитации РОСС RU.0001.22СП29). Область аккредитации лабораторий - программные средства (код ОПС 50 1000 - 50 9000). Сертификация ПС проводится в рамках Системы сертификации электрооборудования, созданной еще в 1992 г. и предусматривающей для конкретных видов продукции добровольную или обязательную сертификацию. Правила проведения сертификации электрооборудования зарегистрированы в Минюсте России 2 сентября 1999 г. (регистрационный № 1885) и в Государственном реестре 21 сентября 1999 г. (регистрационный № РОСС RU.0001.01MЛ00). Для ПС проводится добровольная сертификация с использованием схемы сертификации № 3 [14]. Испытательные лаборатории проводят испытания ПС с целью определения качества их функционирования, оценивает соответствие требованиям государственных стандартов и нормативных документов, качество и наглядность выходных форм. В ходе испытаний лабораториями оцениваются соответствие функциональных характеристик ПС требованиям технического задания или описанию постановки задач и функционирование ПС во всех заявленных режимах, анализируются полнота и качество программной и эксплуатационной документации ПС, а также проверяются формирование выходных файлов. Проводится проверка соответствия ПС требованиям таких государственных стандартов, как ГОСТ Р ИСО/МЭК 9126-93 "Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению", ГОСТ Р ИСО/МЭК ТО 9294-93 "Информационная технология. Руководство по управлению документированием программного обеспечения", ГОСТ Р ИСО 9127-94 "Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов", ГОСТ 28195-89 "Оценка качества программных средств. Общие положения", ГОСТ 28806-90 "Качество программных средств. Термины и определения" [11].
Сертификационные испытания проводятся лабораторией только на лицензионном системном программном обеспечении с применением инструментальных средств тестирования. Инспекционный контроль сертифицированных ПС проводится органом по сертификации "Сертинформ ВНИИНМАШ" не реже одного раза в год. Наряду с этим отмечаются случаи представления на испытания ПС с недооформленной программной и эксплуатационной документацией, без контрольных примеров. Не полностью сформированные комплекты файлов ПС, направленных на сертификацию, не позволяют иногда даже инсталлировать эти программы.
При подаче заявок на сертификацию ПС организации-разработчики не всегда просят оценить ПС на соответствие полному перечню требований государственных стандартов и нормативных документов. Изменение такого подхода разработчиков могло бы существенно поднять качество ПС и обеспечить более высокий спрос на рынке прикладных программ, тем более что для анализа прикладных программ экономической направленности ГОСТ 28195-89 рекомендует оценивать такие показатели качества, как работоспособность, доступность программных и эксплуатационных документов, полноту реализации, согласованность, логическую корректность и проверенность. Результаты сертификационных испытаний подтвердили необходимость дальнейшего совершенствования процесса подготовки и проведения сертификации ПС. При подготовке к сертификации многое зависит от организации-разработчика ПС. Подавая заявку на добровольную сертификацию ПС, изготовитель самостоятельно определяет, на соответствие каким именно государственным стандартам будет проводиться сертификация его продукции, какому нормативному документу должны соответствовать выходные формы разработанного ПС. Что же касается разработчика ПС, уже имеющего сертификат соответствия, то ему важно помнить, что выданный сертификат соответствия распространяется на ПС только той версии, которая подвергалась испытаниям, и не может подтверждать ее соответствие установленным требованиям документов при внесении последующих изменений. Аттестационные испытания программных средств Аттестация ПС - это авторитетное подтверждение качества ПС. Обычно для аттестации ПС создается представительная (аттестационная) комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит испытания ПС с целью получения необходимой информации для оценки его качества. Под испытанием ПС мы будем понимать процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. Этот комплекс включает проверку полноты и точности программной документации, изучение и обсуждение других ее свойств, а также необходимое тестирование программ, входящих в состав ПС, и, в частности, соответствия этих программ имеющейся документации. На основе информации, полученной во время испытаний ПС, прежде всего должно быть установлено, что ПС выполняет декларированные функции, а также должно быть установлено, в какой степени ПС обладает декларированными примитивами и критериями качества. Таким образом, оценка качества ПС является основным содержанием процесса аттестации. Произведенная оценка качества ПС фиксируется в соответствующем решении аттестационной комиссии. Известны следующие виды испытаний ПС, проводимых с целью аттестации ПС: испытания компонент ПС; — системные испытания; — приемо-сдаточные испытания; — полевые испытания; — промышленные испытания. Испытания компонент ПС - это проверка (тестирование) работоспособности отдельных подсистем ПС. Проводятся только в исключительных случаях по специальному решению аттестационной комиссии. Системные испытания ПС - это проверка (тестирование) работоспособности ПС в целом. Может включать те же виды тестирования, что и при комплексной отладке ПС. Проводится по решению аттестационной комиссии, если возникают сомнения в качестве проведения отладки разработчиками ПС. Приемо-сдаточные испытания являются основным видом испытаний при аттестации ПС. Именно с этих испытаний начинает работу аттестационная комиссия. Эти испытания начинаются с изучения представленной документации, в том числе, и документации по тестированию и отладке ПС. Если в документации отсутствуют достаточно полные результаты тестирования ПС, аттестационная комиссия может принять решение о проведении системных испытаний ПС или о прекращении процесса аттестации с рекомендацией разработчику провести дополнительное (более полное) тестирование ПС. Кроме того, во время этих испытаний могут выборочно пропускаться тесты разработчиков, а также контрольные задачи пользователей (см. лекцию 10) и дополнительные тесты, подготовленные комиссией для оценки качества аттестуемого ПС. Полевые испытания ПС - это демонстрация ПС вместе с технической системой, которой управляет эта ПС, узкому кругу заказчиков в реальных условиях и осуществляется тщательное наблюдение за поведением ПС. Заказчикам должна быть предоставлена возможность задания собственных контрольных примеров, в частности, с выходов в критические режимы работы технической системы, а также с вызовом в ней аварийных ситуаций. Это дополнительные испытания, проводимые по решению аттестационной комиссии только для некоторых ПС, управляющих определенными техническими системами. Промышленные испытания ПС - это процесс передачи ПС в постоянную эксплуатацию пользователям. Представляет собой период опытной эксплуатации ПС пользователями со сбором информации об особенностях поведения ПС и ее эксплуатационных характеристиках. Это завершающие испытания ПС, которые проводятся по решению аттестационной комиссии, если на предшествующих испытаниях получена недостаточно полная или надежная информация для оценки качества аттестуемого ПС [3]. Оценка качества ПС по каждому из критериев сводится к оценке каждого из примитивов, связанных с этим критерием качества ПС, в соответствии с их конкретизацией, произведенной в спецификации качества этого ПС. Методы оценки примитивов качества ПС можно разделить на четыре группы: непосредственное измерение показателей примитива качества; обработка программ и документации ПС специальными программными инструментами (процессорами); тестирование программ ПС; экспертная оценка на основании изучения программ и документации ПС. Непосредственное измерение показателей примитива качества производится путем подсчета числа вхождений в тот или иной программный документ характерных единиц, объектов, конструкций и т.п., а также путем измерения времени работы различных устройств и объема занятой памяти ЭВМ при выполнении контрольных примеров. Например, некоторым показателем эффективности по памяти может быть число строк программы на языке программирования, а некоторым показателем эффективности по времени может быть время ответа на запрос. Использование каких-либо показателей для примитивов качества может определяться в спецификации качества ПС. Метод непосредственного измерения показателей примитива качества может сочетаться с использованием тестирования программ.
Для установления наличия у ПС некоторых примитивов качества могут использоваться определенные программные инструментальные средства. Такие программные инструменты обрабатывают тексты программ или программной документации с целью контроля каких-либо примитивов качества или получения некоторых показателей этих примитивов качества. Для оценки структурированности программ ПС, если они программировались на подходящем структурном диалекте базового языка программирования, достаточно было бы их пропустить через конвертер структурированных программ, осуществляющий синтаксический и некоторый семантический контроль этого диалекта и переводящий тексты этих программ на входной язык базового транслятора. Однако таким путем в настоящее время удается контролировать лишь небольшое число примитивов качества, да и то в редких случаях. В ряде случаев вместо программных инструментов, контролирующих качество ПС, полезнее применять инструменты, осуществляющие преобразование представления программ или программной документации. Таким, например, является форматер программ, приводящий тексты программ к удобочитаемому виду, - обработка текстов программ ПС таким инструментом может автоматически обеспечить наличие соответствующего примитива качества у ПС.
Для оценки некоторых примитивов качества ПС используется тестирование. К таким примитивам относится прежде всего завершенность ПС, а также его точность, устойчивость, защищенность и другие примитивы качества. В ряде случаев для оценки отдельных примитивов качества ПС тестирование применяется в сочетании с другими методами. Так для оценки качества документации по применению ПС (П-документированности) тестирование применяется в сочетании с экспертной оценкой этой документации. Если при комплексной отладке ПС было проведено достаточно полное тестирование, то эти же тесты могут быть использованы и при аттестации ПС. В этом случае аттестационная комиссия может воспользоваться протоколами тестирования, проведенного при комплексной отладки. Однако и в этом случае необходимо выполнить какие-либо новые тесты или хотя бы повторно некоторые старые. Если же тестирование при комплексной отладке будет признано недостаточно полным, то необходимо провести более полное тестирование. В этом случае может быть принято решение о проведении испытаний компонент или системных испытаний ПС, а также о возврате ПС разработчикам на доработку. Весьма важно, чтобы для оценки ПС по критерию легкости применения было проведено (во время отладки и аттестации ПС) полное тестирование по тестам, подготовленным на основании документации по применению, а по критерию сопровождаемости - по тестам, подготовленным по каждому из документов, предлагаемых для сопровождения ПС [2]. Для оценки большинства примитивов качества ПС в настоящее время можно применять только метод экспертных оценок. Этот метод заключается в следующем: назначается группа экспертов, каждый из этих экспертов в результате изучения представленной документации составляет свое мнение об обладании ПС требуемым примитивом качества, а затем голосованием членов этой группы устанавливается оценка требуемого примитива качества ПС. Эта оценка может производиться как по двухбалльной системе ("обладает" - "не обладает"), так и учитывать степень обладания ПС этим примитивом качества (например, производиться по пятибальной системе). При этом группа экспертов должна руководствоваться конкретизацией этого примитива и указанием о способе его оценки, сформулированными в спецификации качества аттестуемого ПС. Заключение. В данной работе были рассмотрены вопросы, связанные с испытанием программных средств. Важно отметить, что испытания – долгий и трудоемкий этап создания программной продукции, но необходимый для того, чтобы испытуемое программное средство заняло достойное место на рынке подобной продукции. Я рассмотрела различные методики проведения испытаний, и сделала вывод о том, что не одна из методик не является универсальной, и для каждого программного средства предпочтительно использование нескольких из них. Так, одна и та же методика не подойдет для испытаний различной программной продукции. Были рассмотрены этапы и стадии проведения испытания, а также технологическая схема проведения испытаний. Для каждого из названных процессов определяющую роль играет подготовка испытания, а именно, необходимость выбора и согласования методики испытания, подготовка плана проведения испытания, заблаговременная разработка и испытание всех программно-технических средств, которые будут использоваться при проведении испытаний, составление и анализ соответствующей документации. Были изучены типы испытаний в зависимости от места их проведения, и рассмотрена работа испытателей на комплексном иммитационно-моделирующем испытательном стенде, который позволяет проследить комплексную стыковку объектов испытываемой системы. КИМИС используется на самых ранних этапах создания опытного образца программного средства для выбора наилучших проектных решений. Испытания опытного образца являются базовыми и, как правило, самыми трудоемкими, так в испытаниях опытного образца можно выделить 4 стадии проверки: функциональное тестирование, стрессовое тестирование, тестирование использования ресурсов ЭВМ комплексом программ и тестирование параллельного решения задач в многомашинных и многопроцессорных вычислительных комплексах. Каждое из названных тестирований создает различные условия для проверки работы программы. Для четкой и отлаженной работы испытателей им необходимо иметь соответствующую документацию, где фиксируются план выполнения работ, процесс проведения испытаний и анализ полученных данных. Комиссия руководствуется утвержденным заказчиком и согласованным с разработчиком техническим заданием на комплекс программ; действующими государственными и отраслевыми стандартами на проектирование и испытания программ и на техническую документацию; программой испытаний по всем требованиям технического за­дания; методиками испытаний по каждому разделу требований тех­нического задания. Как правило, однажды созданное программное средство имеет нескольких пользователей, а часто нескольких заказчиков, поэтому необходимо проводить адаптирование данной программы к среде ее будущего использования. Так появляются различные версии программного средства, каждая из которых также требует проведения испытаний и отладки программы в соответствующих условиях – именно это и составляет основные задачи сопровождения программ. Нередко при проведении совместных испытаний, заказчик предлагает внести корректировки в работу программных средств, не оговоренные ранее в техническом задании, в таком случае изменение программы возможно только при анализе специальной комиссией соотношения таких факторов, как срочность изменений, затраты на их проведение, влияние работы улучшенных характеристик на функционирование всей программы в целом. Существуют специальные аттестационные и сертификационные испытания. Они проводятся специальными комиссиями (аттестационной и сертификационной соответственно) в специально предназначенных для этого лабораториях, где проводятся стандартные тестовые испытания на подтверждение качества продукции и соответствие ее назначению. При удачно завершенных испытаниях выдаются соответсвующие документы на программное средство, подтверждающие данный ему статус.
Список источников и литературы Литература 1. Г. Майерс. Надежность программного обеспечния. - М.: Мир, 1980. – 232с. 2. В.В.Липаев. Тестирование программ. - М.: Радио и связь, 1986. – 312с. 3. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. – 416с.
4. Б.Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. – 154с. 5. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, 1997. - 368с. 6. Липаев В.В. Отладка сложных программ. М.: Энергоатомиздат, 1993. – 213с. Смагин В.А., Солдатенко В.С., Кузнецов В.В. Моделирование и обеспечение надёжности программных средств АСУ. – СПб.: ВИКУ им. А.Ф. Можайского, 1999. – 49 с. Аджиев В. Мифы о безопасности ПО: уроки знаменитых катастроф. – Изд. “Открытые системы”, 1999. - № 3. – С.1-17. Липаев В.В. Надёжность программных средств. – М.: СИНТЕГ, 1998. – 232 с. Источники 10. IEEE Std 1003.0-1995 IEEE Guide to the POSIX® Open System Environment (OSE). Государственные стандарты. Утверждены и введены в действие Постановлением Государственного комитета РФ по стандартам от 30 июня 1998 г. www.mgtu.ru www.softforum.ru www.ixbt.ru www.scientific.ru www.spiiras.nw.ru Приложение Рис 1. Схема работы КИМИС. Рис 2. Тиражирование и использование версий программ