|
Тестирование программного обеспечения| |ь | | | | | | | |0 |Неэффективность | | | | | | | |Всего |+6 |-1 |+4 |-3 |+4 |+7 | Рис. 10.8. Взвешенная оценка подходов к сборке. III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ). 1. ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ. Испытания являются важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504—81 под испытанием промышленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функционировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования. Целью испытания является экспериментальное определение фактических (достигнутых) характеристик свойств испытываемого ПИ. Эти характеристики могут быть как количественными, так и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПИ к использованию по своему назначению. Если вывод отрицательный, то образец ПИ возвращается на доработку. Таким образом перекрывается доступ недоброкачественной продукции к пользователю, Непосредственно в ходе испытаний качество ПИ может и не измениться, так как локализация ошибок не является целью испытания. Вместе с тем некоторые дефекты в программах и документации могут устраняться по ходу испытания. Испытание является завершающим этапом разработки. Ему предшествует этап статической и динамической отладки программ. Основным методом динамической отладки является тестирование. В узком смысле цель тестирования состоит в обнаружении ошибок, цель же отладки—не только в обнаружении, но ив устранении ошибок. Однако ограничиться только отладкой программы, если есть уверенность в том, что все ошибки в ней устранены, нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа может не обладать определенными потребительскими свойствами и тем самым быть непригодной к использованию по своему назначению. Не может служить альтернативой испытанию и проверка работоспособности программы на контрольном примере, так как программа, работоспособная в условиях контрольного примера, может оказаться неработоспособной в других условиях применения. Попытки охватить контрольным примером все предполагаемые условия функционирования сводятся в конечном счете к тем же испытаниям. В соответствии с ГОСТ 19,004—80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к использованию по своему назначению. Но такое требование редко соблюдается на практике. В некоторых случаях, особенно в автоматизированных системах, ТЗ на ПС либо вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются на ПС, без указания требований к другим потребительским свойствам. При отсутствии ТЗ на разработку ПС или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной. Что значит установить соответствие программы заданным требованиям, если эти требования формально не заданы? Какая польза от установления такого соответствия, если эти требования заведомо «усечены» и не отражают основных потребительских свойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ. При наличии в ТЗ требуемых характеристик основных потребительских свойств ПИ приведенные определения термина «испытание» по цели испытания практически совпадают. Однако и в этом случае первое определение является более конструктивным, так как оно формулирует не только цель, но и основной метод проведения испытании — проверка ПИ, функционирующего в реальной или моделируемой, но близкой к реальной среде, В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие «испытание» часто отождествляют с понятием «тестирование». Например, в Std IEEE 829—1983 «Документация тестов программного обеспечения» (США) дано следующее определение тестирования: «...процесс активного анализа ПО на предмет обнаружения расхождения между реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с целью оценки характеристик элементов ПО». Данное определение объединяет два приведенных определения термина «испытание» с той лишь разницей, что при принятой (см. определения) концепции поиск и локализация ошибок на являются явно выраженными целями испытания. С учетом высказанных соображений термин «тестирование», используемый в зарубежной литературе, будем интерпретировать как испытание методом тестирования, Длительность испытания зависит от типа, конфигурации (сложности) ПС, а также от целей и степени автоматизации рассматриваемого технологического процесса. При испытании операционных систем она колеблется от одного до шести месяцев [20]. Сложные программные комплексы после интеграции могут испытываться и более длительное время. Основными видами испытания ПП являются предварительные, приемочные и эксплуатационные испытания, включая опытную эксплуатацию. Особенности их организации и проведения подробно рассмотрены в книге [18]. В зависимости от места проведения различают стендовые и полигонные испытания. Под испытательным стендом понимают совокупность технических устройств и математических моделей, обеспечивающих в автоматическом режиме имитацию среды функционирования; поступление входных данных, искажающие воздействия; регистрацию информации о функционировании ПС, а также управление процессом испытания и объектом испытания. Если в основу стендовых испытаний положен принцип моделирования, то соответствующие испытательные стенды называют моделирующими. Испытательным полигоном называют место, предназначенное для испытаний в условиях, близких к условиям эксплуатации, и обеспеченное необходимыми средствами испытания. Полигонным испытаниям подвергают системы, работающие в реальном масштабе времени. В полигонных условиях обычно сочетают натурные испытания с использованием реальных объектов автоматизируемых систем и моделирование некоторых объектов и процессов их функционирования. В последнее. Время в некоторых разрабатывающих организациях создают испытательные полигоны, представляющие собой совокупность специализированных по профилю данной организации испытательных стендов. Такие полигоны имеют общую техническую и информационную базы, а также программные средства организации испытаний. По степени зависимости испытателей от разработчиков различают зависимые и независимые испытания. При зависимых испытаниях основные операции с испытываемыми ПС (подготовка к работе, подготовка и ввод исходных данных, регистрация и анализ результатов) выполняют разработчики программ. Оценку результатов испытания производит комиссия при активном участии разработчиков. Независимые испытания проводят специальные подразделения, не несущие ответственности за разработку программ и непосредственно не подчиняющиеся руководителям разработки. 2. ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ. Для повышения эффективности испытания, его ускорения и удешевления необходимо разработать научно обоснованные методы, средства и методики, позволяющие преодолеть недостатки подхода к испытанию как к своего рода эвристике, недооценку его роли в обеспечении требуемого уровня качества ПП, подмену испытаний процедурами типа проверки работоспособности на контрольном примере и т. п. Эта цель может быть достигнута лишь путем разработки технологической схемы испытаний, предусматривающей; знание назначения испытываемого ПС, условий его функционирования и требований к нему со стороны пользователей; автоматизацию всех наиболее трудоемких процессов и прежде всего моделирование среды функционирования, включая искажающие воздействия; ясное представление цели и последовательности испытания; целенаправленность и неизбыточность испытания, исключающие или минимизирующие повторение однородных процедур при одних и тех же условиях функционирования испытываемого ПС; систематический контроль за ходом, регулярное ведение протокола и журнала испытания; четкое, последовательное определение и исполнение плана испытания; четкое сопоставление имеющихся ресурсов с предполагаемым объемом испытания; возможность обеспечения, а также объективной количественной оценки полноты и достоверности результатов испытания навсех этапах. Любому виду испытаний должна предшествовать тщательная подготовка. В подготовку испытаний ПС входят следующие мероприятия: составление и согласование плана-графика проведения испытания; разработка, комплектование, испытание и паспортизация программно- технических средств, используемых при испытаниях; анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний; анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС; проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях; разработка, согласование и утверждение программ и методикиспытаний; аттестация специалистов на допуск к проведению испытаний; приемка испытываемого опытного образца ПС на носителе данных и документации; проведение мероприятий, направленных на обеспечение достоверности испытаний. Особо следует подчеркнуть необходимость заблаговременной разработки и испытания всех программно-технических средств, которые будут использоваться при проведении испытаний. При этом следует иметь в виду, что уровень точности и надежности измерительной аппаратуры, используемой при испытаниях любого объекта, должен быть значительно выше соответствующих показателен испытываемого объекта. Поэтому реальные характеристики программно- технических испытательных средств необходимо установить заранее, а их приемлемость согласовывать между разработчиками, испытателями и заказчиками ПС. Пренебрежение этим правилом вызывает недоверие к результатам испытания и, как следствие, удлинение сроков испытания. Сложность программно-технических испытательных средств, требования к их совершенству, а следовательно, и затраты ресурсов на их разработку прямо пропорционально зависят от соответствующих показателей испытываемых ПС. Объем испытательных программных средств, выраженный в машинных командах, может достигать объема испытываемых с их помощью программ. Поэтому разработка программно-технических средств, предназначенных для испытания особо сложной ПП, должна начинаться одновременно с разработкой опытных образцов продукции. На основании изложенного можно определить следующие пять этапов испытания. 1. Обследование проектируемого ПС, анализ проектной документации. 2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию. 3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания. 4. Разработка (освоение) испытательных программно-технических средств, библиотек тестов и баз данных (если они требуются). 5. Непосредственное проведение испытаний, анализ результатов, принятие решения. На рис. 16 изображена технологическая схема в виде этапов подготовки и проведения испытания и их связи с этапами разработки ПС. [pic] Рис. 16. Технологическая схема испытания ПС. В зависимости от специфики, условий применения, требований к качеству испытываемых ПС испытания могут проводиться либо путем тестирования, либо путем статистического моделирования среды функционирования, либо на основе натурных и смешанных экспериментов. Часто полезно использование всех этих методов. Значения некоторых показателей качества можно получить экспертным путем. 3. ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ. План проведения испытаний должен быть ориентирован на обеспечение всесторонней проверки ПС и максимальной (заданной) достоверности полученных результатов при использовании ограниченных ресурсов, выделенных на испытаниях. Принципиально возможны следующие подходы к решению этой задачи: 1) анализируют весь диапазон входных данных. На основе анализа заранее готовят такое множество комбинаций данных (тестовых наборов данных), которое охватывает наиболее характерные подмножества входных данных. Программу рассматривают как черный ящик. Испытания сводятся к последовательному вводу тестовых наборов данных и анализу получаемых результатов; 2) анализируют множество ситуаций, которые могут возникнуть при функционировании ПС. Выбирают наиболее характерные ситуации. Каждую из них выражают через тестовый набор входных данных. Далее сущность испытания и анализа результатов сводится к подходу 1); 3) с помощью графовой модели анализируют микроструктуру ПС. Выбирают множество путей, которое полностью покрывает граф-схему ПС, и такую последовательность тестовых наборов исходных данных, выполнение которой будет проходить по выделенным путям. Организация испытаний аналогична подходам 1) и2); 4) ПС испытывают в реальной среде функционирования; 5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде. Ни один из этих подходов не является универсальным. Каждый из них имеет свои преимущества и недостатки, которые в разной степени проявляются в зависимости от специфики испытываемого ПС. Например, подход 1) может оказаться предпочтительным, если диапазон входных данных обозрим, сравнительно легко анализируется и систематизируется, и неприемлемым — в противном случае. Наиболее достоверные результаты получаются при испытаниях в реальной среде функционирования. Но такие испытания редко удается осуществить. Поэтому на практике используют комбинации всех видов. Типичным примером такой комбинации может служить смешанный метод, когда среда функционирования ПС моделируется, а достоверность результатов проверяется путем сравнения с результатами, полученными при функционировании ПС в реальной среде. Анализ показывает, что абсолютная проверка ПС ни при одном из рассмотренных подходов не осуществима. Поэтому при планировании испытаний необходимо предварительно анализировать структуры испытываемых программ и входных данных. В частности, следует устанавливать те пути граф-схемы программы, использование которых при преобразовании данных наиболее вероятно. Эта задача аналогична подходам 1) и 2). Для сложных программных комплексов она не имеет строго математического решения. Вместе с тем на практике нередко удается заранее установить наиболее вероятные ситуации, которые могут возникнуть в автоматизируемой системе, а следовательно, и наборы входных данных, описывающие эти ситуации. Методика решения задачи планирования испытания включает в себя следующие этапы: нахождение всех путей реализации; выделение минимального подмножества путей, обеспечивающих проверку всех участков программы; разработка тестов для проверки выделенных путей. Необходимо отметить, что в результате решения получают не одно подмножество путей, а некоторую совокупность таких подмножеств. Анализируя эти совокупности по критериям минимального времени реализации их на ЭВМ, выбора наиболее вероятных путей, отсутствия в этих совокупностях несовместимых путей (рассмотренным методам присущ этот недостаток), выбирают наиболее приемлемую совокупность. Для формирования входных данных тестирования для каждого выделенного пути реализации составляют специальные таблицы. В таблицах представляют только условные операторы, принадлежащие данному пути, и операторы, в которых вычисляются переменные управления. В результате анализа предписаний, удовлетворяющих условным операторам, вырабатывают входные данные тестирования. Для установления потребности в машинном времени на проведение испытаний необходимо знать среднее значение абсолютной реактивности ПС. Эта характеристика должна быть задана в ТЗ. Если же она не задана, то можно принять [pic] где [pic]— минимальное значение абсолютной реактивности; [pic]— максимальное значение абсолютной реактивности. Несмотря на то что проверка всех путей граф-схемы большой программы неосуществима, при планировании испытаний необходимо при заданных ресурсах обеспечить максимальную полноту проверки, особенно проверки модулей решения наиболее ответственных задач. Стремление избежать при этом неэффективного простого перебора приводит к задаче выбора минимального количества путей, покрывающих граф ПС. Под покрытием понимают включение всех дуг графа. Минимальное покрытие, с одной стороны, обеспечивает минимум тестов и контрольных просчетов, а, с другой стороны, гарантирует прохождение каждой дуги графа хотя бы по одному разу. Рассмотренный метод планирования на этапе автономных статистических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориентация на тот или иной подход к испытаниям зависит от типа испытываемого ПС. В общем случае при планировании и организации испытаний следует искать компромиссное решение, учитывающее два противоречивых требования: обеспечение максимальной достоверности обобщенной оценки качества ПИ и выполнение испытания в ограниченное время с использованием ограниченных ресурсов. Следует выделить три стадии испытания: подготовительную; непосредственные испытания; заключительную (подготовка отчетных материалов). Задачи этих стадий очевидны. Подробнее остановимся на задачах подготовительной стадии. Эта стадия наиболее длительная и наиболее трудоемкая. Основными ее задачами являются: планирование испытаний; разработка технологической схемы испытаний и испытательных средств; разработка программ и методик испытания; накопление предварительных статистических данных, характеризующих ПС. Целенаправленность и четкость организации работ по накоплению статистических данных может существенно повысить достоверность оценки качества ПС, исключить дублированные (повторные) проверки и уменьшить сроки испытаний и затрачиваемые материальные ресурсы. Однако в некоторых случаях из-за плохой организации работы результаты тестирования на этапах отладки программ и предварительных испытаниях не регистрируются, поэтому не могут использоваться для окончательной. оценки качества программы. Между выделенными стадиями испытания ПС имеются прямые и обратные связи, аналогичные связям между этапами жизненного цикла ПС. Это означает, что при выполнении работ заключительной стадии может быть выявлена необходимость возвращения к стадии непосредственных испытаний (или даже к подготовительной стадии) для уточнения отдельных характеристик. Составлению плана проведения испытаний должен предшествовать анализ Т3 на разработку ПС, структурных и функциональных схем, режимов функционирования, зависимостей между модулями программы, планов-графиков разработки и отладки компонентов ПС, результатов контроля их качества на ранних стадиях разработки. В результате этого анализа необходимо разработать и обосновать общую стратегию испытания, а на ее основе—комплекс документов по организации испытаний, который должен содержать ответы на следующие вопросы: 1) задачи испытаний на каждой фазе, последовательность развития фаз; 2) используемые специальные испытательные средства; 3) количество необходимого машинного времени на каждой фазе испытаний; 4) конфигурация общего технического и программного обеспечения; 5) оцениваемые свойства, критерии оценки, способы их получения; 6) процедуры контроля хода испытания; 7) процедуры регистрации, сбора, обработки и обобщения результатов испытания; 8) условия (критерии) начала и завершения каждой фазы испытаний. По каждому из этих вопросов необходимо определить ответственных исполнителей, сроки выполнения работ, вид конечного результата. В стандарте IEEE 829—1983 (США) большое внимание уделено документированию процесса испытания ПП. Перечень документов, которые разрабатываются и ведутся в соответствии с планом испытания, приведен в разделе «Документирование», Проанализировав содержание выделенных разделов плана испытания/тестирования, можно сделать вывод о целесообразности включения сведений, содержащихся в этих разделах, в программы и методики испытания ПС. Такое включение будет способствовать повышению информативности этих документов и упорядочению самого процесса испытаний. На проведение испытаний ПП приходится затрачивать значительные трудовые и материальные ресурсы. Сроки проведения испытаний всегда ограничены. Поэтому перед испытателями всегда стоит задача поиска путей минимизации затрат материальных, трудовых и временных ресурсов для достижения цели испытания. Для реализации этой задачи необходимо установить критерии завершенности Испытаний, которые могут служить основой для принятия решения о завершении испытаний. При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них: 1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, характеристики которых неизвестны; 2) отсутствие общепринятых показателей, а также методов расчета требуемых и фактических значений приводит к тому, что в ТЗ на разработку ПС требования к характеристикам ПС либо фактически отсутствуют (в количественном выражении), либо не претендуют на полноту. Рассмотрим пути решения проблемы оценки завершенности испытаний ПС. Но прежде всего обратим внимание на необходимость тщательного документирования процесса испытания. Такое документирование следует начать с момента приобретения ПС свойства работоспособности и вести его непрерывно до момента передачи ПС в промышленную эксплуатацию. Опыт создания отечественных систем реального времени подтверждает необходимость ведения одного или двух журналов. В одном из них следует регистрировать все эксперименты с ПС, а в другом—обнаруженные ошибки (проблемы) и ход их устранения. Периодически составляют отчеты об испытаниях за определенный период времени. Для ведения журналов необходимо тщательно разработать инструкции, в которых установить общие правила заполнения журналов, в том числе единые правила присвоения регистрационных номеров ошибкам, индексации типов ошибок, классификации ошибок и т. п. В журналах следует предусмотреть отдельные разделы, в которых при необходимости будут даваться подробные комментарии к ошибкам и способы их устранения. Не всякую ошибку можно быстро идентифицировать, поэтому в стандарте IEEE 829—1983 рекомендовано документировать в виде отчетов тест-инцидент все нестандартные события, происходящие во время испытания и требующие дополнительного анализа. Рекомендуется следующая структура этого отчета: идентификатор отчета тест-инцидент, аннотация, описание инцидента, влияние инцидента на последующий ход испытания. Последние два раздела являются основными. Описание инцидента должно включать следующие элементы: входные данные, ожидаемые и фактические результаты, отклонение от нормы, дата и время испытания, шаг процедуры испытания, среда функционирования, результаты попыток повторения условий эксперимента, испытатели, наблюдатели- регистраторы. Регистрация экспериментов и ошибок (инцидентов), периодическая обработка данных и анализ результатов позволяют контролировать испытания и управлять этим процессом. Сама процедура регистрации может быть разной, важно лишь предотвратить потерю ценной информации при минимальных трудозатратах на сбор и обработку данных. Данное условие можно обеспечить только путем максимальной автоматизации всех процессов. Критерий интенсивности обнаружения ошибок. Если считать, что во время одного эксперимента обнаруживается не более одной ошибки и каждая ошибка до начала следующего эксперимента устраняется, то можно предположить, что при благоприятном ходе отладки и испытания кривая зависимости: N = 1 — п/К, где п — количество обнаруженных и устраненных ошибок; К. — . количество экспериментов, будет асимптотически стремиться к единице (кривая 1 на рис. 17). Кривая 2 свидетельствует о неблагополучном ходе процесса. Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несущественных ошибок. Идея выбора такого критерия основана на том, что частота обнаружения ошибок, выраженная отношением п/К, по мере увеличения количества экспериментов должна уменьшаться и к моменту завершения испытаний принять значение, близкое к нулю. Следует иметь в виду, что оценка уровня завершенности испытаний по этому показателю будет достоверной лишь в том случае, если каждый эксперимент проводится в новых условиях и испытатели стремятся обнаружить ошибки, а не доказать их отсутствие. Если же программу проверяют при одних и тех же или близких условиях, то довольно быстро получают кривую вида 1, которая не свидетельствует ни о полноте, ни о глубине проверки программ, ни об отсутствии в ней ошибок. Критерий заданного значения средней наработки на отказ (критерий Дж. Д. Муса). Сделано два предположения. 1. Суммарное количество обнаруженных и устраненных дефектов в про грамме (под дефектом понимается любая причина неудовлетворенности свойствами программы) описывается показательной функцией времени функционирования [pic] [pic] [pic] - исходное количество дефектов в программе; [pic]- общее количество дефектов, которое может проявиться за время эксплуатации ПС; [pic] — средняя наработка на отказ в начале испытаний; С—коэффициент сжатия тестов. Коэффициент С[pic]1 тогда, когда абсолютная реактивность программы при прогоне тестов или статистических испытаниях отличается от абсолютной реактивности при работе программы в реальных условиях. Если, например, за один час испытаний моделируется управляемый процесс, происходящий в реальных условиях в течение десяти часов, то коэффициент сжатия С принимается равным 10. Скорость обнаружения и устранения дефектов, измеряемая относительно времени функционирования программы, пропорциональна интенсивности отказов. Коэффициент пропорциональности B=n/m называется коэффициентом уменьшения дефектов. Количество зарегистрированных отказов т зависит от суммарного времени функционирования программы следующим образом: [pic] Значение средней наработки на отказ также зависит от суммарного времени функционирования: [pic] Если в ходе испытания обнаруженные ошибки устраняются, то текущее значение средней наработки на отказ будет увеличиваться. Таким образом, в качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Tо. Тогда, определяя периодически текущее значение средней наработки на отказ по этой формуле , можно при планировании дальнейшего хода испытания рассчитать требуемое время для дальнейшего прогона программы по формуле [pic] При планировании отладки и испытания ПО следует учитывать влияние следующих факторов: 1) скорости выявления дефектов; 2) скорости устранения дефектов; 3) удовлетворенности машинным временем. Первый фактор зависит от укомплектованности и квалификации испытателей, второй—от укомплектованности и квалификации группы программистов отладчиков, третий — от фондовооруженности (технической оснащенности) разрабатывающей (испытывающей) организации. На начальной стадии отладки программы интенсивность выявления дефектов высока. Программисты-отладчики перегружены работой, приходится даже прерывать тестовые прогоны, делать перерывы в испытаниях. На заключительной стадии интенсивность обнаружения дефектов низкая, но остро ощущается необходимость в машинном времени. Испытатели перегружены в подготовке все новых и новых тестовых исходных данных, в то время как у программистов- отладчиков работы может быть мало. 4. СТЕНДЫ ОТЛАДКИ И ИСПЫТАНИЯ ПРОГРАММ. Идея имитационного моделирования положена в основу создания комплексных имитационно-моделирующих испытательных стендов, используемых для отладки и испытания сложных систем управления в реальном масштабе времени. Комплексный имитационно-моделирующий испытательный стенд (КИМИС) представляет собой совокупность средств испытываемой системы и их моделей, модели внешней среды и программ обработки результатов моделирования, функционально объединенных на основе испытываемого программного комплекса. Комплексные имитационно-моделирующие испытательные стенды используются при полигонных испытаниях сложных систем. Общая идея создания КИМИС основана на том, что для испытания (исследования) ПС, реализованного непосредственно на управляющей ЭВМ, необходимо моделировать управляемый процесс и имитировать поступление в ЭВМ информации об этом процессе. Испытываемое ПС безразлично к непосредственным источникам информации. Важно лишь, чтобы вся информация была распределена по реальным физическим каналам ЭВМ и временным тактовым интервалам, а также соответствовала заданному (ожидаемому) диапазону условий внешней среды. Сопряжение моделей с реальными средствами системы необходимо для оценки результатов моделирования путем их сравнения с реальными данными. Использование в составе КИМИС непосредственно самого ПС, а не его модели, позволяет получить более достоверные результаты при моделировании и избежать больших дополнительных трудозатрат на разработку модели ПС. Для создания КИМИС, помимо основной ЭВМ, на которой реализуется испытываемое ПС, используют ЭВМ примерно такой же производительности для реализации комплекса моделей соответствующего назначения. Первую ЭВМ (ВС) обычно называют технологической, вторую—инструментальной. Инструментальная ЭВМ и программное обеспечение образуют КИМИС. Такие КИМИС являются кроссовой системой (КРОСС-КИМИС). Моделируемые (имитируемые) на инструментальной ЭВМ данные передаются в технологическую ЭВМ, где и обрабатываются как реальные данные. Программное обеспечение КИМИС может быть реализовано и на технологической ЭВМ (Резидент-КИМИС). Но такой вариант используется сравнительно редко из-за дефицита памяти и производительности в технологических (управляющих) ЭВМ. Автоматизированный технологический комплекс (АТК) состоит из элементов следующих типов: управляемый технологический агрегат (УТА), автоматизированная система управления технологическим процессом (АСУ ТП), датчики информации (ДИ) о состоянии управляемого процесса. На вход АТК поступает объект обработки (00), на выход—результат обработки (РО). Если прекратить доступ информации в ЭВМ от реальных физических объектов АТК, а вместо нее вводить адекватную ин формацию, имитируемую по КИМИС на инструментальной ЭВМ , то процесс функционирования ПО АСУ ТП будет адекватен реальному. Оператор УТА в принципе может участвовать в обеих режимах. Программное обеспечение КИМИС в общем случае состоит из следующих подсистем: моделирования, анализа результатов испытания, регистрации событий (документирования), планирования и управления и базы данных (рис. 20). В состав подсистемы моделирования входят: модель заявок на обработку (МЗ), модель объекта обработки (МОО); модели датчиков информации (МДИ); имитатор помех (ИП); модель управляемого технологического агрегата (МТА). Модель заявок имитирует поток заявок на обработку (например, поток слябов) исходя из плановых и производственных соображений [pic] В соответствии с заданным приоритетом или случайным образом выбирается 00, принимаемый на обслуживание, из совокупности 00, имитируемой МЗ, и его характеристики. Модели датчиков информации являются информационными моделями конкретных типов датчиков информации, используемых в системе управления АТК. Они имитируют выдачу текущих координат характеризующих состояние технологического процесса. Модель управляемого технологического агрегата (например, прокатного стана) имитирует управляемый технологический процесс (например, прокатки стали) с выдачей соответствующей информации об этом процессе. Имитатор помех в соответствии с заданными вероятностными характеристиками имитирует воздействие случайных факторов на элементы моделируемой системы и управляемый процесс. При этом используется датчик случайных чисел, позволяющий реализовать процедуру «розыгрыш». Таким образом, подсистема моделирования, имитируя технологический процесс в управляемом агрегате, обеспечивает воспроизведение потока входной информации в управляющую ЭВМ, адекватного этому потоку в реальных условиях эксплуатации АТК. Имитируемый поток входной информации подается' на вход испытываемого ПО АСУ и инициирует его функционирование, результатом которого является поток выходной (управляющей) информации, выдаваемый на УТА или его модель. Образуется замкнутый контур управления, адекватный контуру управления в реальном ДТК. Основными компонентами подсистемы анализа результатов испытаний являются: программа выборки результатов преобразования входных данных, программы формирования эталонных значений для анализа правильности результатов, программа сравнения фактических результатов с эталонными и оценки их приемлемости (правильности). Подсистема регистрации событий обеспечивает документирование хода испытаний и регистрацию всех тех характеристик, которые могут быть полезны как для определения значений показателей качества испытываемого ПС, так и для оценки эффективности и состояния самого процесса испытаний. Подсистема планирования и управления на основе анализа состояния испытаний, полученных результатов, проверенных путей граф-схемы испытываемого ПС и поступающих заданий от программистов-испытателей осуществляет планирование экспериментов и подготовку соответствующих исходных данных для подсистемы моделирования. На эту же подсистему возлагается координация действий (инициализация) всех элементов КИМИС. Достоинства КИМИС очевидны. Его использование позволяет осуществлять комплексную стыковку объектов испытываемой системы и проверку принципов управления задолго до создания всех элементов системы (элемент системы, разработка которого не завершена, заменяется моделью). Применение моделирования позволяет разнообразить условия испытания и сэкономить материальные ресурсы. Комплексные испытательные моделирующие стенды можно использовать не только для испытания программ, но и для отработки взаимодействия всех элементов системы. Сопряжение реальных средств испытываемой системы с их моделями позволяет разнообразить условия испытания и провести полунатурные эксперименты. Можно, например, проверить работу автоматизируемого технологического агрегата, моделируя поведение объекта обработки или, наоборот, промоделировать работу технологического агрегата при работе с реальным объектом обработки. Такие вариации позволяют, с одной стороны, проверять адекватность моделей своим оригиналам и тем самым убеждаться в достоверности результатов статистических испытаний, а, с другой стороны, использовать КИМИС на самых ранних этапах разработки опытного образца ПС для выбора и апробации наилучших проектных решений. IV. СЕРТИФИКАЦИЯ ПРОГРАММНЫХ ПРОДУКТОВ. 1. СТАНДАРТИЗАЦИЯ СИСТЕМ КАЧЕСТВА. В начале 70-х годов многие специалисты пришли к выводу о необходимости широкого распространения индустриальных (инженерных) методов в области построения программ (см, § 1.1). Индустриальные методы базируются на строгой регламентации и автоматизации технологических процессов. Таким образом, стандартизация и в области построения программ стала жизненной необходимостью. В рамках Единой Системы Программной Документации (ЕСПД) разработано и введено в действие около тридцати стандартов, упорядочивающих разработку программной документации. Многие виды стандартов для программной продукции еще не разработаны (общие технические требования, общие технические условия, технические условия на виды ПП, номенклатура показателей качества, методы выполнения отдельных видов работ в технологических процессах, порядок проведения этих работ и др.). При разработке ПМК системы УК ПП приняты следующие исходные положения: 1) разработка ПП осуществляется в соответствии с действующими стандартами, техническими условиями, ТЗ или иными заменяющими его документами, содержащими требования к качеству ПП, установленные на основании анализа требований конкретного и (или) потенциального пользователя к потребительским свойств данного вида ПП; 2) качество ПП обеспечивается преимущественно в процессе его разработки; по завершению каждого этапа разработки проекта должен проводиться документированный, систематический и критический анализы результатов разработки; 3) за качество разрабатываемой ПП ответственность несет разработчик, поставляемой — поставщик; 4) руководство организации — разработчика несет ответственность за определение политики в области качества и за решения, касающиеся разработки, внедрения и ведения системы качества; 5) управление качеством ПП основывается прежде всего на стимулировании заинтересованности разработчиков и поставщиков в обеспечении высокого качества ПП, повышении профессионализма: 6) для обеспечения требуемого качества ПП управление качеством осуществляется на всех стадиях и этапах жизненного цикла ПП, начиная с самых ранних; 7) в разрабатывающей организации должны быть определены система качества (управляющие органы и лица, несущие ответственность за качество), а также политика в области качества ПП; ответственность и полномочия за каждый вид деятельности, влияющей на качество ПП; определение обязанностей и полномочий должно обеспечивать достижение поставленных целей на заданном уровне эффективности; 8) управление качеством ПП базируется на контроле качества в процессе разработки; 9) все формализуемые функции, процедуры и операции по управлению качеством в конечном счете должны быть переданы ЭВМ и реализованы на ней в виде инструментальных программ; 10) в идейном (концептуальном) плане инструментальные программы и методики, входящие в состав ПМК, должны представлять единое целое, согласующееся с принятой технологией программирования и являющееся составной частью этой технологии; 11) в составе ПМК подсистемы У К ПП можно выделить базовую (условно постоянную) и переменную части. Базовая часть-ПМК разрабатывается как типовое проектное решение с использованием принципов модульной структуры и может быть использована в различных организациях, независимо от ведомственной принадлежности и собственной специфики. Переменная часть-ПМК учитывает специфику разрабатывающей организации, структуры и задач подсистемы УК ПП. Она создается в конкретной организации путем настройки базовой части ПМК и разработки новых, недостающих частей подсистемы УК ПП; 12) все компоненты базовой части ПМК должны обладать свойствами автономности (независимости) разработки, настройки и применения. Однако наибольший эффект должен достигаться от комплексного использования всех компонентов ПМК. Основными методами стандартизации УК ПП в разрабатывающей организации являются: систематизация и классификация: типизация и унификация; регламентирование. Систематизация и классификация направлены на упорядочение элементов управления (ГКК, СКК и др.), установление их прав и обязанностей, а также взаимодействия между ними. Типизация и унификация направлены на выявление и формирование сходных компонентов программ и программных комплексов по профилю организации, па создание библиотек унифицированных компонентов, средств генерации программ из этих компонентов, интерфейсных соглашении. Регламентирование направлено на упорядочение организационных и технологических процедур по обеспечению требуемого уровня качества на всех стадиях жизненного цикла ПП. В США, например, в середине 80-х годов введены в действие следующие стандарты: ANSI/IEEE «Спецификация требований к ПО» (Guide to Software Requirements Specifications); «Планирование управления конфигурацией ПО» (Software Configuration Management Plans); «Документирование тестов ПО» (Software Test Documentation); «Планирование уровня качества ПО» (Software Quality Assurance Plan?). В качестве проектов апробируются и другие стандарты, в том числе «Справочник гарантии качества», «Классификация отказов, сбоев и ошибок ПО». При организации управления качеством ПП многие полезные рекомендации можно заимствовать из соответствующих стандартов по управлению качеством промышленной продукции. В 1987 г. утверждено пять международных стандартов ISO, устанавливающих требования к системам обеспечения качества продукции на предприятиях: «Стандарты по управлению качеством и обеспечению качества. Руководство для выбора и применения» (ISO 9000); «Система качества. Модели обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании» (ISO 900S); «Система качества. Модели обеспечения качества при производстве и монтаже» (ISO 9002); «Система качества. Модели обеспечения качества в процессе контроля и испытания готовой продукции» (ISO 9003); «Управление качеством и элементы системы качества. Основные направления» (ISO 9004). 2. КЛАССИФИКАЦИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Под показателем качества программной продукции в соответствии с ГОСТ 15467—79 следует понимать количественную характеристику одного или нескольких свойств продукции, составляющих ее качество, рассматриваемую применительно к определенным условиям ее создания и эксплуатации. Свойство продукции — это объективная особенность, которая может проявиться при создании или эксплуатации продукции. В определении понятия «Показатель качества» слова «Количественная характеристика» не следует понимать в буквальном смысле. При определении значений показателей качества успешно могут применяться и нечисловые характеристики, хотя в общем случае наличие строго количественных, числовых характеристик предпочтительней. Показатели качества программной продукции в зависимости от характера решаемых задач по оценке качества продукции можно классифицировать по следующим признакам: характеризуемые свойства; способ выражения; количество характеризуемых свойств; место применения в процедуре оценки; стадии определения значений показателей. По способу выражения различают показатели, выраженные в натуральных единицах, и показатели, выраженные в стоимостных единицах. В качестве натуральных единиц обычно используют единицы физических величин (килограммы, метры, секунды и т. п.), а также баллы и безразмерные единицы. ПС являются информационными объектами. Какими-либо собственными физическими свойствами они не обладают, поэтому единицы физических величин в традиционном виде при определении значений показателей качества ПС почти не применяются, за исключением единиц времени. Но как составной элемент системы обработки данных ПС вносит определенную долю погрешности в точность выходных результатов. Эта погрешность может измеряться в единицах преобразуемых физических величин. Вместе с тем в программировании широко используют такие натуральные единицы, как бит, байт, условная машинная команда, строка текста и т. п. Стоимостные единицы применяют при определении значений экономических показателей качества программной продукции. По количеству характеризуемых свойств различают единичные и комплексные показатели. Единичные показатели качества характеризуют одно из свойств ПС, комплексный—несколько. Комплексные показатели могут быть групповыми, обобщенными или интегральными. В зависимости от места применения в процедуре оценки уровня качества ПС различают базовые и относительные показатели. Базовым значением показателя качества продукции называют значение показателя, принятое за основу при сравнительной оценке качества продукции. Относительное значение показателя качества продукции представляет собой отношение фактического значения показателя качества оцениваемой продукции к базовому значению этого показателя. По стадии определения значений показателей качества различают прогнозируемые, проектные, производственные и эксплуатационные показатели. Прогнозируемыми показателями оперируют на стадиях выполнения научно- исследовательских работ и составления ТЗ на разработку ПС, т. е. на тех стадиях, когда нет еще ни детального проекта ПС, ни, тем более, самого ПС. Значения прогнозируемых показателей в основном определяют на основе интуиции и опыта аналогичных разработок, поэтому эти показатели носят субъективный характер. Значения проектных показателей определяют на основе анализа проектов ПС (эскизного, технического, рабочего), а также путем испытания опытного образца ПС. Эти показатели носят более объективный характер. Степень их достоверности зависит от эффективности используемых инструментальных средств анализа и испытания. Производственные показатели мало отличаются от проектных, особенно если изготовление ПС сводится к простому копированию. Если же копированию предшествуют операции сборки или генерации ПС, то производственные показатели качества таких ПС могут существенно отличаться от проектных. Значения эксплуатационных показателей определяют по результатам промышленной эксплуатации ПС. При соблюдении определенных правил сбора и обработки данных о качестве ПС в процессе эксплуатации эксплуатационные показатели дают наиболее объективную и достоверную оценку. Только по этим показателям можно произвести действительную оценку научно-технического уровня и качества ПС. 3. ВЫБОР НОМЕНКЛАТУРЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Выбор номенклатуры показателей качества программной продукции заключается в установлении перечня наименований характеристик свойств продукции, определяющих качество данного вида продукции и обеспечивающих возможность полной и достоверной оценки ее уровня качества. Порядок выбора номенклатуры показателей качества программной продукции должен устанавливаться с учетом специфики этой продукции. Выбор номенклатуры показателей качества конкретного ПС зависит от вида (группы) ПС, цели применения и стадии определения показателей. Для каждого вида (группы), а иногда и конкретного ПС устанавливают свою номенклатуру показателей качества, учитывающую специфику назначения п условий применения. Номенклатура показателей качества для каждого подкласса, группы и вида ПС оформляется в виде таблиц применяемости показателей качества. Помимо перечня рекомендуемых и обязательных показателей качества для данного подкласса (вида, группы) ПС, в таблицах применяемости следует указывать и коэффициенты (параметры) весомости (значимости) каждого из показателей. Определение коэффициентов весомости показателей качества — наиболее существенная и трудная задача выбора номенклатуры показателей качества. В принципе при решении этой задачи можно использовать либо метод стоимостно-регрессионных зависимостей, либо метод предельных номинальных значений. Но их использование затруднено из-за отсутствия необходимых исходных данных. Поэтому на практике наиболее распространен экспертный метод определения коэффициентов весомости. Таблицы применяемости являются руководящим или справочным материалом для выбора рабочей номенклатуры показателей качества конкретного ПС. Рабочая номенклатура ПС устанавливается с учетом назначения и условий использования ПС; результатов анализа требований пользователя (заказчика), поставленных задач управления качеством; состава, структуры и специфики характеризуемых свойств. Цели применения номенклатуры показателен качества устанавливают в соответствии с задачами управления качеством программной продукции. Такими целями, в частности, могут быть следующие: составление технического задания па разработку ПС; составление технических условии на ПС; заполнение карты технического уровня; установление контролируемых показателей при проектировании ПС; установление контролируемых показателей при опытной эксплуатации ПС; аттестация ПС по категориям качества. Стадии определения значении показателей качества соответствуют стадиям жизненного цикла ПС. При выделении свойств и соответствующих показателей качества ПС необходимо руководствоваться следующими основными принципами : выделение групп свойств должно производиться по четко определенным признакам; свойства, входящие в одну группу, должны, как правило, взаимно исключать друг друга и быть независимыми. Если свойства зависят друг от друга, то в методиках определения значении показателей качества должны быть даны четкие указания по исключению многократного (неоднократного) влияния одного и того же свойства на обобщенную оценку качества ПС; всякая исходная номенклатура показателей должна быть открытой, т. е. должна допускать возможность внесения мне исключения из нее отдельных элементов. Это требование обусловлено, с одной стороны, недостаточным опытом оценки качества программной продукции, а с другой,—большим разнообразием ПС и условий их применения; для каждого из выделенных свойств должна существовать возможность выражения их в шкалах «лучше — хуже», «больше — меньше»; в группу следует включать свойства, необходимые и достаточные для определения соответствующего сложного свойства; формулировка свойств должна быть однозначной; совокупность свойств, характеризующих качество оцениваемого ПС, должна быть упорядочена по определенному правилу в виде многоуровневой иерархической структуры — дерева свойств; дерево свойств должно отражать все основные особенности использования н функционирования ПС; выбранные показатели качества должны быть скоррелнрованы с соответствующими свойствами ПС. Это значит, что между каждым из выделенных свойств и характеризующими его показателями должно быть установлено однозначное соответствие. Установление такого соответствия позволяет вместо дерева свойств использовать дерево показателей качества программной продукции; показатели качества, характеризующие свойства ПС, должны способствовать обеспечению соответствия качества ПС требованиям со стороны их пользователей и учитывать современные достижения науки и техники. Для выполнения этого принципа часто необходимо проводить специальные исследования, так как в общем случае между показателями качества могут возникать серьезные противоречия, а улучшение одного показателя может привести к ухудшению другого. Для проверки работоспособности выбранной системы показателей качества необходимо устанавливать степень корреляции каждого рассматриваемого показателя с качеством ПС, полезность показателя, возможность количественного представление и автоматической оценки показателя. В частности, оценку полезности каждого из выбранных показателей для конкретных ПС рекомендуется производить по следующей шкале: 5—крайне важно, чтобы данный показатель имел высокое значение; 4—важно, чтобы данный показатель имел высокое значение; 3—хорошо бы иметь высокое значение данного показателя; 2— в некоторой степени полезно иметь высокое значение данного показателя; 1—при низких значениях данного показателя ощутимых потерь нет, Около 50 % частных показателей можно определить автоматически с помощью ЭВМ, 25 % —с помощью компаратора. Таким образом, оценка около 75 % показателей может быть формализована. Оценка 20 % показателей может быть произведена только квалифицированным специалистом. Большинство показателей устанавливают путем статического анализа программ и лишь около 5 % — в процессе динамических испытаний (Данные соответствуют положению в этой области в 80-е годы). Следует иметь в виду, что оценка качества, а следовательно, к выбор показателей качества сложных многофункциональных программных комплексов типа операционных систем, систем управления базами данных, пакетов прикладных программ и так далее имеет свои особенности. Каждая функция таких ПС реализуется программным путем, задающим определенный технологический процесс преобразования входных данных в выходные. Известны цель этого процесса и потребность в нем, Для того чтобы удовлетворить эту потребность, ПС должна обладать определенными свойствами. Причем свойства ПС, удовлетворяющие потребности в одной функции, могут существенно отличаться от свойств ПС, необходимых для реализации другой функции. Поэтому степень удовлетворения потребности в выполнении каждой из функций ПС в общем случае характеризуется своими показателями или, по крайней мере, параметрами весомости показателей. Возникает необходимость выбора показателей и определения их весомости для оценки качества (эффективности) реализации каждой из основных функций ПС. Попытка выбора единой номенклатуры показателей качества оказывается, как правило, безрезультатной. В этом можно легко убедиться на примере оценки качества операционных систем (ОС) ЭВМ. На ОС ЭВМ возлагаются следующие функции: управление данными, заданиями, вводом-выводом; обслуживание библиотек пользователей; трансляция и редактирование программ; протоколирование состояний и событий; перезапись и сортировка информации и др. Очевидно, что требования, например, к трансляторам существенно отличаются от требований к ПС протоколирования событий как по своему перечню, так и по весомости каждого из показателей. В свою очередь различие требований обусловливает необходимость использования различных показателей качества, характеризующих потребительские свойства программ, реализующих эти функции. 4. ГРУППЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Любому классу продукции присущи определенные свойства, характерные для данного класса. В свою очередь каждый подкласс, группа, вид этой продукции имеет частные свойства, отличающие изделия одной классификационной группировки от другой. Рассмотрим формирование номенклатуры показателей качества, характеризующей общие свойства класса программной продукции. Эта номенклатура может быть использована в качестве исходной при выборе рабочей номенклатуры показателей качества любого конкретного ПС. Номенклатуры показателей качества всегда имеют иерархическую структуру. Их формирование начинается с выделения групп верхнего уровня иерархии, а затем номенклатуры детализируются вплоть до получения единичных показателей. Выделение групп показателей качества является важной и сложной задачей формирования номенклатуры показателей качества. Неудачное комплектование групп может привести к усложнению взаимосвязей между группами и отдельными показателями, а также сделать номенклатуру показателей качества малоконструктивной. Известно, что для оценки качества промышленной продукции используют следующие группы показателей: назначения; экономичного использования сырья, материалов, топлива, энергии; надежности; эргономичности; эстетичности; технологичности; патентно-правовые; унификации и стандартизации; экологичности; безопасности. Все эти показатели можно использовать и при оценке качества ПП. По в силу особенностей ПП некоторые группы показателей при оценке ее качества применять нецелесообразно (неконструктивно). К таким показателям относят показатели экологичности, безопасности. Экологические показатели и показатели безопасности нехарактерны для ПП, так как программные изделия непосредственно не могут оказывать вредных воздействий ни на окружающую среду, ни на здоровье человека. В принципе, такие воздействия возможны в тех случаях, когда ПИ используют в качестве элементов управляющих объектов, например в АСУ. В этом случае вырабатываемые ЭВМ по определенному алгоритму управляющие воздействия могут вызвать и неблагоприятные экологические последствия, и быть опасными для человека. Но это уже косвенное воздействие через управляющие органы и исполнительные механизмы автоматизированных технологических комплексов (АТК). Они учитываются как соответствующие показатели AT К. Патентно-правовые показатели программной продукции не могут быть использованы до тех пор, пока вопросы патентно-правовой защиты этой продукции не будут решены в законодательном (юридическом) плане. Относительно надежности программной продукции существует много противоречивых мнений. Вместе с тем большинство специалистов единодушны в мнении о том, что природа надежности программных и технических средств различна. Для программной продукции малопродуктивными являются такие показатели надежности, как долговечность, сохраняемость, ремонтопригодность. Источниками низкой надежности ПС в основном являются ошибки в программах, внесенные на стадии проектирования и невыявленные при отладке и испытаниях. Заслуживает внимания мнение американского специалиста Фокса Д., который считает, что использование термина «надежность программного обеспечения» наносит вред, так как способствует неправильному пониманию природы программного обеспечения . Вместе с тем следует учитывать тот факт, что при анализе некоторых свойств ПП, проявляющихся при ее функционировании, приходится пользоваться категориями надежности (работоспособность, отказ, сбой, восстановление и др.). Поэтому в номенклатуре показателей качества ПП признано целесообразным выделять в отдельную группу показатели, характеризующие свойства ПП, близкие по своим внешним проявлениям показателям надежности аппаратуры. Эта группа названа показателями надежности функционирования. Таким образом, в базовой номенклатуре показателей качества ПП на верхнем уровне выделяем следующие показатели: назначения, надежности функционирования, эргономичности, технологичности, унификации и стандартизации. Качество ПП в основном формируется в процессе создания продукции и в значительной мере зависит от эффективности структурных (конструктивных) решений. Поэтому на этом же уровне в отдельную группу выделим структурные показатели. Показатели назначения, надежности функционирования, эргономичности и технологичности характеризуют свойства ПП, проявляющиеся в процессе ее использования (эксплуатации). По этому признаку их можно считать эксплуатационными. Структурные показатели и показатели унификации и стандартизации характеризуют свойства структуры (конструкции) ПС, их можно объединить в одну группу конструктивных показателей. По отношению к группе эксплуатационных показателей эта группа носит вспомогательный характер. Достижение определенного уровня значений этих показателей не может служить самоцелью, это лишь средство (путь) обеспечения требуемых значений одного или нескольких показателей, относящихся к основной группе — группе эксплуатационных показателей. СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ: 1. Майерс. Искусство тестирования программного обеспечения. 2. Майерс. Надежность программного обеспечения. 3. Кулаков. Управление качеством программного обеспечения. Страницы: 1, 2 |
|
