ИСПЫТАНИЯ И СЕРТИФИКАЦИЯ ПРОГРАММНЫХ ПРОДУКТОВ

Организация и процессы испытаний компонентов и комплексов программ. Программа и методики испытаний компонентов и комплексов программ. Завершение испытаний программных продуктов. Организация сертификации сложных заказных программных продуктов. Завершение испытаний и внедрение версий программных продуктов. Приложение

Определение задач испытаний предусматривает анализ документов, в которых сформулированы требования к программному продукту, и выделение необходимых работ, чтобы затем их проверять. В качестве руководящих принципов для присвоения приоритетов функциям должны использоваться документы, содержащие формулировки требований. Новым функциям и характеристикам имеет смысл посвящать повышенное внимание, нежели слегка модифицированным компонентам. Кроме того, необходимо уделять время на проверку проектных решений и структуры комплекса, а также на тестирование новых компонентов. В дополнение к обычному анализу требований необходимо учесть задачи, которые не имеют прямого отношения к документам с требованиями, но влияют на процессы тестирования.

  • • составление плана и Программы проведения испытаний;
  • • разработка тестовых сценариев и динамических моделей внешней среды для генерации тестов;
  • • отладка тестовых сценариев и генераторов тестов;
  • • верификация, проверка, выявление и исправление дефектов генераторов тестов;
  • • определение качества тестов и степени реализации функций и характеристик программного продукта, процесса их сборки и использования;
  • • пересмотр и корректировка пользовательской документации.

После подготовки такого перечня работ следует его ревизовать вместе с группой тестирования и провести через полный жизненный цикл, определяя дополнительные компоненты и задачи, которые должны выполняться для корректных испытаний. Такой перечень является динамичным документом, претерпевающим изменения на протяжении всего жизненного цикла тестирования и испытаний по мере роста понимания того, что должно быть сделано для получения программного продукта высокого качества, соответствующего требованиям и эталонам заказчика.

Функции, характеристики и свойства компонентов и комплекса программ, которые должны тестироваться - это функциональные возможности, отличительные характеристики и риски программного продукта, а также производительность, надежность, безопасность, переносимость, определенные требованиями заказчика. Все, что декларировано заказчиком, должно быть отражено в требованиях, в Программе и плане проведения испытаний с тем, чтобы это протестировать до поставки продукта заказчику. Основным источником, позволяющим фиксировать, что было согласовано с заказчиком, служат документы определения требований и эталонов (см. Главу 13). Перечень требований должен сопровождаться технико-экономическим обоснованием и контрольной таблицей для вычисления трудозатрат, необходимых для проведения тестирования и испытаний программного комплекса. Каждая позиция этого перечня должна соответствовать конкретным пунктам документов описания требований, в то же время каждой такой позиции должен соответствовать один или большее число тестов, определенных в Программе и спецификациях методик испытаний.

Разработчики должны участвовать в производстве и регистрации процесса подготовки к тестированию, тестовых вариантов, сценариев и тестовых процедур, которые нужно использовать для полного испытания системы, и в прослеживании соответствия между тестовыми вариантами и требованиями к функциям и характеристикам системы. Каждое проверяемое требование должно соответствовать конкретным, обоснованным характеристикам системы, иметь уникальный для проекта идентификатор, чтобы можно было провести испытание и проследить его выполнение с помощью объективного теста. Для каждого требования должны выбираться квалификационные методы для функциональных подсистем и компонентов программного комплекса, которые необходимо прослеживать в требованиях к системе. Степень детализации требований следует выбирать, учитывая в первую очередь те функции и характеристики качества, которые внесены в условия приемки системы заказчиком, и отдавать приоритет тем из них, которые заказчик требует обеспечить обязательно. Испытания должны быть выполнены в соответствии с утвержденными заказчиком планом, Программой, тестовыми вариантами, сценариями и процедурами.

База данных должна содержать полный набор данных о дефектах и ошибках, обнаруженных во время тестирования программного комплекса. Сводку дефектов, обнаруженных во время испытаний, целесообразно включать в отчетный доклад. В таком случае всем сторонам, заинтересованным в успехе разработки, не потребуется обращаться в базу данных дефектов за сведениями о ходе работ по испытаниям и о качестве программного продукта. Окончательная версия отчета по результатам анализа дефектов, в котором показаны все обнаруженные дефекты и их окончательные корректировки, а также редакция отчета о не устраненных дефектах и ошибках являются необходимыми дополнениями отчетного доклада о результатах испытаний.

Приемосдаточные испытания подразумевают участие заказчика и возможно пользователей. Обнаруженные в ходе приемосдаточных испытаний дефекты документируются в отчетах о проблемах, и определяются их приоритеты. Проблемы, устранение которых невозможно осуществить в отведенные на приемосдаточные испытания сроки, следует передавать техническому Совету для дальнейшего рассмотрения и оценки. По итогам проведения приемосдаточных испытаний должен готовиться отчет, который содержит краткое описание произведенных работ и оценку полученных результатов тестирования.

Наиболее полным и разносторонним испытаниям должна подвергаться первая версия программного продукта. При испытаниях очередных версий программного продукта возможны значительные сокращения объемов тестирования апробированных повторно используемых компонентов. Однако комплексные и завершающие испытания каждой новой версии программного продукта, как правило, должны проводиться в достаточном объеме, гарантирующем проверку выполнения всех требований модифицированного технического задания. Для выявления дефектов в процессе эксплуатации серийных образцов в каждом из них должен быть предусмотрен некоторый минимум средств для оперативной проверки функционирования и обнаружения искажений результатов. Эти средства должны позволять фиксировать условия неправильной работы программ и характер проявления дефектов при применении программного продукта.

Программа и методики испытаний компонентов и комплексов программ

Оценивание качества и соответствия требованиям программного продукта при квалификационных и/или приемосдаточных испытаниях проводится комиссией заказчика, в которой участвует руководитель (главный менеджер) разработки и некоторые ведущие разработчики, или аттестованной сертификационной лабораторией (см. ISO 10006). Комиссия при испытаниях должна руководствоваться следующими документами'.

  • • утвержденными заказчиком и согласованными с разработчиком контрактом, техническим заданием и спецификациями требований на программный продукт и систему;
  • • действующими государственными и ведомственными стандартами на жизненный цикл и испытания крупных комплексов программ, на технологическую и эксплуатационную документацию, а также стандартами де-факто, согласованными с заказчиком для использования - профилем стандартов и нормативных документов;
  • • Программой испытаний по всем требованиям контракта, технического задания и спецификаций;
  • • методиками испытаний и матрицей тестов, охватывающими каждый раздел требований технического задания, спецификаций и Программы испытаний;
  • • комплектом адекватной эксплуатационной и технологической документации на программный комплекс.

План испытаний комплекса программ должен описывать порядок квалификационного тестирования функциональных компонентов и подсистем, тестовую внешнюю среду, которая будет использоваться при тестировании, идентифицировать выполняемые тесты и указывать план-график тестовых действий (см. Главу 2.4). Для каждой предполагаемой тестовой реализации или динамического тестового варианта должны быть указаны: используемые версии аппаратных средств; интерфейсное оборудование; дополнительные внешние устройства; генераторы тестовых сценариев или динамических тестовых потоков данных.

Программа испытаний является серией экспериментов и должна разрабатываться с позиции необходимого объема тестирования в процессе проведения испытаний для проверки выполнения всех требований технического задания и соответствия предъявленной документации. Программа испытаний, методики их проведения и оценки результатов, разработанные совместно заказчиком и менеджерами разработки, должны быть согласованы и утверждены. Они должны содержать уточнения и детализацию требований технического задания и спецификаций для данного программного продукта, а также гарантировать корректную проверку всех заданных функций и характеристик качества. Программа испытаний должна содержать следующие четко сформулированные разделы:

  • • объект испытаний, его назначение и перечень основных документов, определивших его разработку;
  • • цель испытаний, с указанием всех требований технического задания, характеристик качества, подлежащих проверке, и ограничений на проведение испытаний программного продукта;
  • • собственно Программу испытаний, содержащую проверку комплектности спроектированного программного комплекса в соответствие с техническим заданием, план и график проведения тестирования для проверки по всем разделам требований технического задания и дополнительных требований, формализованных отдельными решениями разработчиков и заказчика;
  • • перечень и содержание методик испытаний, однозначно определяющих все требования, понятия проверяемых функций и характеристик качества, условия и сценарии тестирования, инструментальные средства, используемые для испытаний;
  • • перечень методик обработки и оценки результатов тестирования программного продукта по каждому разделу Программы испытаний.

Методика испытаний должна содержать: описание организации процесса тестирования, тестовые варианты, сценарии и процедуры, которые используются при испытаниях отдельного функционального компонента или комплекса программ в целом. Каждый тест должен иметь уникальный для данного проекта идентификатор; должны быть представлены инструкции для проведения процедур тестирования; описание аппаратуры и инструментальные средства для реализации тестирования, а также инструкции для динамического и регрессионного тестирования. Кроме того, должны быть приведены ссылки на соответствующие проверяемые требования, указаны условия выполнения (конфигурация аппаратуры и компонентов комплекса программ), входные данные, эталонные и ожидаемые результаты, критерии оценки качества результатов, процедура проведения тестирования для каждого тестового сценария, допущения и ограничения.

Большой объем разнородных данных, получаемых при испытаниях сложных комплексов программ, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами становятся методики обработки и оценки результатов, а также протоколы проверки по пунктам Программы испытаний. В соответствии с методиками испытаний средства автоматизации должны обеспечивать всю полноту проверок характеристик по каждому разделу методик. Результаты испытаний фиксируются в протоколах (см. ISO 12119), выводы о результатах испытаний и о соответствии созданного программного комплекса или его функционального компонента определенному разделу требований технического задания и исходных спецификаций.

Протоколы по всей программе испытаний обобщаются в акте, в результате чего делается заключение о соответствии системы требованиям заказчика и о завершении работы с положительным или отрицательным итогом. При выполнении всех требований технического задания заказчик обязан принять программный продукт, и проект считается завершенным.

Завершение испытаний программных продуктов

Завершение испытаний программного комплекса в составе системы должно удостоверить и зафиксировать следующие процессы и результаты'.

  • • завершена разработка всех функций комплекса программ и исправление всех выявленных ошибок;
  • • все функциональные компоненты размещены под формальный автоматизированный контроль системы управления конфигурацией компонентов проекта;
  • • завершено компонентное тестирование всех функций и исправление всех выявленных дефектов версии программного продукта;
  • • подготовлена полная версия программного комплекса с контролируемыми изменениями после испытаний;
  • • версия программного комплекса, переданная на испытания, сопровождается технологической и эксплуатационной документацией, перечнем изменений, содержит список отчетов о дефектах, которые исправлены в версии;
  • • предоставлена контролируемая полная версия программного комплекса, которая установлена в тестовой среде, стабильно функционирует и позволяет получать поддающиеся интерпретации результаты испытаний;
  • • проведены совещания менеджеров и специалистов, посвященные управлению незавершенными работами по устранению дефектов и оценки времени для исправления дефектов;
  • • в предшествующие несколько недель не произошло ни одного сбоя, остановки, неожиданного прекращения процесса или другой аномалии функционирования комплекса программ на объектном компьютере в системе;
  • • анализ динамического функционирования показал, что комплекс программ достиг приемлемого уровня качества, стабильности, надежности и безопасности;
  • • менеджеры и группа управления системой установили, что программный продукт, как это определено в ходе заключительного цикла испытаний, удовлетворяет требованиям заказчика и пользователей;
  • • проведено совещание менеджеров производства с заказчиком и установлено, что критерии завершения испытаний программного продукта выполнены.

Завершаются испытания предъявлением заказчику на утверждение комплекта документов, содержащих результаты ком

плексных испытаний версии программного продукта. Принимая решение прекратить работы по испытаниям, следует учитывать факты, которые играют важную роль при оценке неготовности заказного программного продукта к поставкам. Это количество дефектов, обнаруженных в процессе тестирования, которые остаются неисправленными; количество тестов, реализация которых не может быть выполнена, поскольку они заблокированы дефектами. С целью выработки оценки готовности версии отлаженного программного продукта следует проводить специальные совещания менеджеров - разработчиков и заказчика. В некоторых предприятиях оценку готовности определяет группа тестирования; в других организациях совещание проводит руководитель проекта системы либо руководитель разработки и заказчик программного продукта. В любом случае в задачу группы тестирования и испытаний входит представление результатов и выработка рекомендаций относительно готовности продукта к поставкам. Хотя оценка готовности может проводиться формально, в любом случае следует фиксировать имена участников и принятое ими решение, касающееся поставок заказного программного продукта. Чтобы оценка готовности содержала результаты и рекомендации предприятия, проводившего испытания, эта оценка должна содержать ссылку на отчетный доклад по результатам испытаний.

Критерии успешного или неудачного прохождения испытаний и отдельных тестов для программных компонентов должны быть включены в тестовые сценарии, в связи с чем их следует помещать в план проведения испытаний. С самого начала проекта необходимо определить, что следует считать успешным прохождением стадии испытаний и соответствия исходным требованиям и эталонам заказчика, когда можно прекратить испытания продукта и начать его поставку.

После завершения испытаний новой версии программного продукта обычно осуществляется процесс ее внедрения для применения. Это производится, как правило, в два этапа; силами разработчиков версии в целях обкатки, проверки и выявления ошибок в изменениях на этапе опытной эксплуатации и посредством использования специализированных коллективов сопровождения для тиражирования и распространения версий программного продукта.

Основные обязанности специалистов сводятся к передаче физических носителей с текстами программ и комплектом эксплуатационной документации, а также к проведению консультаций для выделенной группы специалистов заказчика и пользователей. Разработчики и испытатели в этом случае получают возможность непосредственно контролировать работу пользователей с системой и документацией, что обеспечивает высокую оперативность отработки замечаний и рекламаций, формирование квалифицированных предложений для изменений, оценку эффективности применения версии программного продукта. Кроме того, должны разрабатываться учебно-методический план, подготавливаться учебные пособия, необходимые для обучения пользователей, а также проводиться обучение выделенной группы специалистов, ответственных за последующее обучение коллективов пользователей.

Организация сертификации сложных заказных программных продуктов

При сертификации заказных программных продуктов и разработке тестов сертификаторы должны иметь четкое представление о потребностях заказчика. Необходимо изучить системные требования, сценарии использования системы и/или описание назначения системы для того, чтобы лучше понять цель разработки программного продукта, выбор методов и средств его тестирования. Требования к тестам и документы должны содержать подробный перечень того, что и как должно быть испытано [17, 28, 31]. Стратегия сертификационных испытаний - это документ, отражающий совокупность выбранных методов, требований и решений, вытекающих из целей и задач проекта и его тестирования, общие правила и принципы, способствующие достижению целей разработки программного продукта высокого качества. При сертификационных испытаниях программного продукта целесообразно выборочно или полностью использовать результаты предварительных испытаний с учетом их полноты и достоверности. Завершаются предварительные испытания разработчиков предъявлением заказчику на утверждение комплекта документов, содержащих результаты, необходимые для сертифи кационных испытаний программного продукта. Результатом сертификационных испытаний должен быть комплект отчетных документов и подтверждение результатов, зафиксированных при предварительных испытаниях.

Утверждение этого комплекта документов для конкретного программного продукта дает право на присвоение ему сертификата и знака качества. Отчетный доклад о результатах испытаний должен содержать перечень всех не устраненных дефектов, с соглашением и планом того, будут ли они исправлены в более поздних версиях или же их исправление откладывается на неопределенное время.

Современные заказные программные продукты для управления и обработки информации активно применяются в сложных критических и ответственных системах динамического управления объектами различного назначения. Ущерб от дефектов программных продуктов таких систем может определяться высокой их стоимостью и даже иногда жизней пользователей. На реализацию требуемого качества требуются ресурсы, которые могут быть соизмеримыми с первичными затратами на весь процесс проектирования и производства системы и программного продукта, а также на подготовку и воспитание профессиональных квалифицированных коллективов специалистов в области индустрии сложных программных продуктов высокого качества.

Любые испытания ограничены допустимым количеством и объемом тестирования, а также длительностью работы комиссии испытателей, поэтому не могут гарантировать абсолютную проверку программного продукта, на соответствие требованиям к функциям и характеристикам. Для повышения достоверности определения и улучшения оценивания характеристик, после внутренних или квалификационных испытаний, некоторые экземпляры комплексов программ целесообразно передавать пользователям на опытную эксплуатацию в типовых условиях. Это позволяет более глубоко оценить эксплуатационные характеристики созданного комплекса и оперативно устранять некоторые дефекты и ошибки. Опытную эксплуатацию целесообразно проводить разработчиками с участием испытателей-заказчиков и некоторых пользователей, назначаемых заказчиком. Результаты и характеристики качества опытной эксплуатации после внутренних испытаний могут учитываться при проведении заказчиком квалификационных испытаний для их сокращения.

Для заказчика и пользователей доминирующее значение могут иметь номенклатура и особенности реализации некоторых функций комплекса программ, которые, как правило, требуют наибольших затрат на тестирование и определяют основной эффект от применения программного продукта, а также потенциальный уровень спроса на рынке. Если затраты на разработку комплекса программ можно оценивать и прогнозировать с некоторой достоверностью, то эффективность применения и особенно будущий спрос на конкретную версию программного продукта со стороны пользователей априори оценить трудно. Такие оценки могут проводиться на основе специальных маркетинговых исследований и опыта эксплуатации аналогичных комплексов программ или достаточно близких их прототипов.

Потребителей - заказчиков программных продуктов управляющих систем интересует, прежде всего, качество готового продукта и обычно не очень беспокоит, как оно достигнуто. Однако это качество должно быть ответственно удостоверено и гарантировано компетентными, независимыми организациями. Гарантирование качества продукции возможно посредством сертификационных испытаний процессов производства комплексов программ и/или испытаний их результатов - готовых программных продуктов [17, 22]. Рассматриваемые далее заказные программные продукты для систем управления и обработки информации в реальном времени активно применяются в сложных критических и ответственных системах динамического управления объектами. Проектирование и производство таких программных продуктов обычно требуется заказчиками базировать на международных стандартах, охватывающих весь их жизненный цикл.

Сертификационные испытания должны технически и юридически удостоверять в письменной форме, что состояние продукции, процессов его производства и системы менеджмента качества способны обеспечить требуемое качество и стабильность характеристик изготовляемой продукции любыми двумя методами (рис. 2.10).

Схема сертификации сложных программных продуктов-испытания технологий и конечного программного продукта

Рис. 2.10

Первый метод должен обеспечивать высокое качество выполнения всего технологического процесса проектирования и производства, и тем самым минимум экономических потерь от брака, что особенно важно при создании сложных дорогих систем. Результаты испытаний качества процессов проектирования и производства трудно измерять количественными критериями и обычно характеризуются рядом требований к качественному выполнению наборов стандартизированных производственных процессов.

Они оцениваются свойствами различных процессов, непосредственно отражающимися на характеристиках качества программного продукта, однако при этом нет гарантии адекватного и однозначного требуемого качества конечного продукта.

Второй метод сертификации акцентирован на анализе, контроле и удостоверении качества готового программного продукта, которое удостоверяется при его испытаниях. Отсутствие или недостатки системы обеспечения качества в технологическом процессе разработки могут приводить к длительному итерационному процессу доработок и повторных испытаний. При сертификационных испытаниях готового программного продукта могут использоваться его стандартизированные количественные и качественные критерии качества и характеристики.

Требования к составу документов для организации сертифицируемого производства включают: комплект должностных инструкций, определяющих ответственность и порядок взаимодействия специалистов, для производства программного продукта;

  • • положение о подразделениях и должностные инструкции, обязанности и полномочия специалистов, реализующих производство программных продуктов;
  • • набор характеристик комплекса программ для сертификационных испытаний;

состав документации процессов и результатов сертификации -задание клиента на проведение сертификационных испытаний производства программного продукта;

  • • план сертификации производства программного продукта; документы сертификационной лаборатории:
  • • требования к документации результатов внутренних испытаний производства программного продукта;
  • • состав технологических средств автоматизации и Программа сертификационных испытаний производства;
  • • методики испытаний по каждому разделу требований процессов производства программного продукта;
  • • отчеты выполнения и результаты испытаний производства;
  • • отчет клиенту - заявителю о проверках организации сертификационных испытаний - программного продукта.

Рис. 2.11

Соответственно можно выделить два вида сертификационных испытаний, технологий обеспечения жизненного цикла программных комплексов, поддержанных регламентированными системами качества; и испытаний готового программного продукта с полным комплектом эксплуатационной документации (см. рис. 2.10). Взаимосвязь качества разработанных комплексов программ с качеством технологии их создания и с затратами на производство становится особенно существенной при необходимости получения критического заказного программного продукта реального времени с особенно высокими значениями характеристик качества при ограниченных ресурсах. Этот вид комплексной сертификации должен обеспечивать контроль реализации требований алгоритмической и функциональной корректности программного продукта, что особенно важно в программных комплексах для обеспечения функциональной безопасности применения сложных управляющих систем [32].

Результаты сертификационных испытаний сложного программного продукта включают:

исходные документы заявителя для выполнения сертификации заказного программного продукта:

  • • техническое задание - требования к функциям, характеристикам, качеству программного продукта, системы и внешней среды;
  • • полные тексты программ, содержание базы данных и технологической документации программного продукта;
  • • комплект эксплуатационных документов, поставляемых заказчику и пользователям для применения программного продукта;
  • • план, Программу и методики испытаний, применения и оценки качества программного продукта;
  • • руководство по генерации и инсталляции пользовательских версий и загрузке базы данных в соответствии с условиями и характеристиками внешней среды;

договор заявителя с сертифицирующей организацией на проведение испытаний версии программного продукта:

  • • отчет сертификаторов о реализации Программы и методик проведения сертификационных испытаний программного продукта в соответствии с Договором на сертификацию с заявителем;
  • • результаты выполнения планов и методик сертификационных испытаний, протоколы испытаний предъявляемым требованиям, утвержденным сертификаторами и согласованным с заявителями;

Акт результатов сертификационных испытаний программного продукта, реальные характеристики программного продукта, выводы о их соответствии требованиям к характеристикам заказчика продукта:

  • сертификат заказного программного продукта, лицензия на применение знаков соответствия;
  • удостоверение для поставки и применения пользователями сертифицированного программного продукта.

Рис. 2.12

Требования к тестам и документы должны содержать подробный перечень того, что и как должно быть испытано. При сертификационных испытаниях программного продукта целесообразно выборочно или полностью использовать результаты предварительных испытаний с учетом их полноты и достоверности. Утверждение комплекта документов для конкретного программного продукта дает право на присвоение ему сертификата и знака качества. Отчетный доклад о результатах испытаний должен содержать перечень всех не устраненных дефектов, с соглашением и планом того, будут ли они исправлены в более поздних версиях или же их исправление откладывается.

Завершение испытаний и внедрение версий программных продуктов

При снятии программного продукта с сопровождения следует определить необходимые для этого действия, а затем разработать и документально оформить этапы работ, обеспечивающие их выполнение. Должны быть предусмотрены возможности доступа к полным архивным документам снятого с сопровождения программного продукта. Современные заказные программные продукты для управления и обработки информации активно применяются в сложных критических и ответственных системах динамического управления объектами различного назначения. Ущерб от дефектов программных продуктов таких систем может определяться огромной их стоимостью и жизней пользователей. На реализацию требуемого качества требуются ресурсы, которые могут быть соизмеримыми с первичными затратами на весь процесс проектирования и производства системы и программного продукта, а также на подготовку и воспитание профессиональных квалифицированных коллективов специалистов в области индустрии сложных программных продуктов высокого качества.

На завершающих этапах испытаний, когда, как правило, на группу тестирования оказывают давление руководители для ускорения с окончанием работ, разработчикам полезно иметь в своем распоряжении документ, в котором оговариваются все требования и дополнения заказчика, которые планировалось испытать. Спе циалисты склонны забывать, какие соглашения и требования были достигнуты, а также планы проведения испытаний. Если проблема возникнет в области, которая не подвергалась испытаниям в соответствии с планом и Программой, она должна быть устранена и проверена после выпуска очередной версии программного продукта. Поскольку стоимость исправления дефектов после сдачи программного продукта в эксплуатацию велика, важно получать по возможности точную оценку рисков, прежде чем принимать решение проводить дополнительные испытания того или иного свойства или конфигурации версии программного продукта.

Отчетный доклад о результатах испытаний должен содержать перечень всех не устраненных дефектов, с соглашением и планом того, будут ли они исправлены в более поздних версиях или же их исправление откладывается на неопределенное время. Дальнейшие версии программного продукта могут содержать не устраненные дефекты до тех пор, пока они не будут исправлены. Необходимо вести наблюдение за такими дефектами, чтобы не тратить дополнительные усилия на их выявление в будущих версиях продукта. В плане проведения испытаний будущих версий должны присутствовать ссылки на список не устраненных дефектов. Это позволит тестировщикам учитывать, что их ожидает во время испытаний новой версии программного продукта.

С целью выработки оценки готовности версии отлаженного программного продукта следует проводить специальные совещания менеджеров - разработчиков и заказчика. В некоторых предприятиях оценку готовности определяет группа тестирования; в других организациях совещание проводит руководитель проекта системы либо руководитель разработки и заказчик программного продукта. В любом случае в задачу группы тестирования и испытаний входит представление результатов и выработка рекомендаций относительно готовности продукта к поставкам. Хотя оценка готовности может проводиться формально, в любом случае следует фиксировать имена участников и принятое ими решение, касающееся поставок программного продукта. Чтобы оценка готовности содержала результаты и рекомендации предприятия, проводившего испытания, эта оценка должна содержать ссылку на отчетный доклад по результатам испытаний.

Критерии успешного или неудачного прохождения испытаний и отдельных тестов для программных компонентов должны быть включены в тестовые сценарии, в связи с чем их следует помещать в план проведения испытаний. С самого начала проекта необходимо определить, что следует считать успешным прохождением стадии испытаний и соответствие исходным требованиям и эталонам заказчика, когда можно прекратить испытания продукта и начать его поставку. В некоторых случаях критерий выхода из испытаний определяется в Программе испытаний или в документе, который содержит формулировки требований, предъявляемых к программному продукту. Вне зависимости от того, кто служит источником этих критериев, следует давать их четкую формулировку в плане и Программе проведения испытаний.

После завершения испытаний новой версии программного продукта обычно осуществляется процесс ее внедрения для применения. Это производится, как правило, в два этапа: силами разработчиков версии в целях обкатки, проверки и выявления ошибок в изменениях на этапе опытной эксплуатации и посредством использования специализированных коллективов сопровождения для тиражирования и распространения версий программного продукта. Основные обязанности специалистов сводятся к передаче физических носителей с текстами программ и комплектом эксплуатационной документации, а также к проведению консультаций для выделенной группы специалистов заказчика и пользователей. Разработчики и испытатели в этом случае получают возможность непосредственно контролировать работу пользователей с системой и документацией, что обеспечивает высокую оперативность отработки замечаний и рекламаций, формирование квалифицированных предложений для изменений, оценку эффективности применения версии программного продукта. Кроме того, должны разрабатываться учебно-методический план, подготавливаться учебные пособия, необходимые для обучения пользователей, а также проводиться обучение выделенной группы специалистов, ответственных за последующее обучение коллективов пользователей.

В процессе жизненного цикла большое значение имеет история эксплуатации программного продукта, развития его версий и соответствующая документация. Еще на стадии проектирования первой версии могут возникать идеи совершенствования комплекса программ, которые в то время невозможно реализовать из-за высокой стоимости, ограниченных сроков проектирования или по иным причинам. Идеи изменения могут быть направлены на коренное улучшение функциональных возможностей программ или некоторые «косметические» улучшения реализуемых функций. Идеи небольших корректировок программ целесообразно накапливать отдельно от предложений по существенному совершенствованию программного продукта. Таким образом, должен создаваться документ - исходные данные для изменения требований и планирования доработок в процессе сопровождения, содержащий разделы: выявленные дефекты и ошибки в программном продукте; предложения по совершенствованию функций и улучшению качества эксплуатируемых версий программного продукта; идеи и предполагаемая экономическая эффективность коренной модернизации, расширения функций и/или улучшения характеристик версии программного продукта.

После внесения изменений в требования специалисты разрабатывают и тестируют конкретные корректировки пилотного варианта программного продукта. Исходными данными для проведения работы при внесении изменений должны быть: версия программного продукта; согласованные с заказчиком предложения о модификации; согласованные документы на реализацию корректировок; отчет о влиянии корректировок и выходные результаты работы по анализу изменений. Сопроводитель должен провести проверки каждого внесенного изменения совместно с заказчиком, утвердившим изменение в целях подтверждения целостности и работоспособности измененного программного продукта. Он должен получить согласование и подтверждение того, что внесенные изменения удовлетворяют требованиям заказчика, установленным в дополнительном договоре, посредством вспомогательного процесса контроля качества, проведения аудита функциональной и физической конфигурации. Результатами данной работы являются: новая версия программного продукта, включающая в себя принятые изменения требований; отклоненные изменения; отчет о приемке версии; отчеты о проверках и аудитах; отчет о квалификационном тестировании откорректированного программного продукта.

Снятие программного продукта с эксплуатации и развития версий должно быть подготовлено анализом, обосновывающим это решение. В анализе следует определить и экономически обосновать: возможность сохранения устаревшей версии комплекса программ, а также необходимость создания и применения новой версии программного продукта. При снятии программного продукта с сопровождения следует определить необходимые для этого действия, а затем разработать и документально оформить этапы работ, обеспечивающие их эффективное выполнение. Должны быть предусмотрены возможности доступа к полным архивным документам снятого с сопровождения программного продукта.

Специалисты, выполняющие снятие версий программного продукта с сопровождения и эксплуатации, должны разработать план, предупредить пользователей об этом, провести соответствующее обучение персонала, уведомить всех заинтересованных субъектов о завершении сопровождения и архивировать соответствующие данные. Должен быть разработан, документально оформлен и реализован план снятия с эксплуатации и прекращения активной поддержки программного продукта сопровождающим предприятием. К запланированным работам целесообразно привлечь пользователей.

Перед прекращением сопровождения следует определить влияние снятия программного продукта с сопровождения на пользователей, установить программный продукт, заменяющий снимаемый (при его наличии) и определить обязанности по любым вопросам последующей поддержки применения версий программного продукта. Пользователи должны получить уведомление о планах и работах по снятию с сопровождения и эксплуатации. В содержание уведомления необходимо включить: описание заменяющей или модернизированной версии программного продукта с указанием даты ее доступности для пользователей; объяснение того, почему прежний программный продукт нельзя больше поддерживать и применять.

Для плавного перехода пользователей к новой версии программного продукта в некоторых случаях должна быть обеспечена параллельная эксплуатация прежнего и нового программных продуктов. Следует провести необходимое обучение пользо-

вателей новой версии в соответствии с условиями договора. После выполнения запланированного снятия с эксплуатации должно быть послано соответствующее уведомление всем заинтересованным сторонам. Все, связанное с прежней версией: документы требований, разработки, тестирования и испытаний, журналы регистрации и программы должно быть помещено в архивы под конфигурационное управление (см. Главу 2.6). Данные, использованные или связанные со снятым с эксплуатации программным продуктом, следует сохранять доступными для аудиторской проверки. Целесообразно также сохранять старые версии комплекса программ и некоторые данные, полученные при решении предыдущих задач в качестве тестов.

При сопоставлении результатов оценивания функций и характеристик качества с требованиями технического задания и спецификаций разработчик или поставщик обязан удовлетворять требования заказчика только в пределах согласованных параметров модели внешней среды и системы. Оценивание функционирования комплекса программ за этими пределами должно дополнительно согласовываться испытателями с разработчиком. При этом невыполнение требований может квалифицироваться как их расширение за пределы, ограниченные контрактом, и не учитываться при оценивании заказчиком характеристик качества программного продукта, или как дополнительные работы, подлежащие соответствующему финансированию со стороны заказчика, для доработки комплекса программ с целью удовлетворения этих требований.

Приложение

МЕЖДУНАРОДНЫЕ И ГОСУДАРСТВЕННЫЕ СТАНДАРТЫ, РЕГЛАМЕНТИРУЮЩИЕ ПРОЕКТИРОВАНИЕ И ПРОИЗВОДСТВО СЛОЖНЫХ ЗАКАЗНЫХ ПРОГРАММНЫХ ПРОДУКТОВ

  • 1. ГОСТ Р ИСО/МЭК 12207.2008 - Системная и программная инженерия, процессы жизненного цикла систем и программных комплексов.
  • 2. CMMI - Capability Maturity Model Integration for Product and Process Development - Интегрированная модель оценивания зрелости продуктов и процессов разработки программных средств.
  • 3. ISO 19759:2005. SWEBOK. Свод знаний о программной инженерии.
  • 4. ISO 15288:2002. Системная инженерия. Процессы жизненного цикла систем.
  • 5. ISO 19760:2003. - Системная инженерия. Руководство по применению стандарта ISO 15288.
  • 6. ISO 12207:1995. (ГОСТ Р - 1999). ИТ. Процессы жизненного цикла программных средств.
  • 7. ISO 15271:1998. (ГОСТ Р - 2002). ИТ. Руководство по применению ISO 12207.
  • 8. ISO 16326:1999. (ГОСТ Р - 2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.
  • 9. ГОСТ Р 51904 - 2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию.
  • 10. ISO 9000:2000. (ГОСТ Р - 2001). Система менеджмента (административного управления) качества. Основы и словарь.
  • 11. ISO 9001:2000. (ГОСТ Р - 2001). Система менеджмента (административного управления) качества. Требования.
  • 12. ISO 9004:2000. (ГОСТ Р - 2001). Система менеджмента (административного управления) качества. Руководство по улучшению деятельности.
  • 13. ISO 90003:2004 - Руководство по организации применения стандарта ISO 9001:2000 для программных средств.
  • 14. ISO 12182:1998. (ГОСТ Р- 2002). ИТ. Классификация программных средств.
  • 15. ISO 14598-1-6:1998-2000. Оценивание программного продукта.

Ч. 1. Общий обзор. Ч. 2. Планирование и управление. Ч. 3. Про цессы для разработчиков. Ч. 4. Процессы для покупателей. Ч. 5. Процессы для оценщиков. Ч. 6. Документирование и оценивание модулей.

  • 16. ISO 9126-1-4: 2002. ИТ. ТО. Качество программных средств: Ч. 1. Модель качества. Ч. 2. Внешние метрики. Ч. 3. Внутренние метрики. Ч. 4. Метрики качества в использовании.
  • 17. ISO 25000:2005 ТО. - Руководство для применения новой серии стандартов по качеству программных средств на базе обобщения стандартов ISO 9126:1-4: 2002 и ISO 14598:1-6:1998-2000.
  • 18. ISO 15939: 2002 - Процесс измерения программных средств.
  • 19. ISO 14756: 1999. ИТ. Измерение и оценивание производительности программных средств компьютерных вычислительных систем.
  • 20. ISO 12119:1994. (ГОСТ Р - 2000 г). ИТ. Требования к качеству и тестирование.
  • 21. ISO 14764: 1999. (ГОСТ Р - 2002). ИТ. Сопровождение программных средств.
  • 22. ISO 15846:1998. ТО. Процессы жизненного цикла программных средств. Конфигурационное управление программными средствами.
  • 23. ISO 15910:1999. (ГОСТ Р - 2002) ИТ. Пользовательская документация программных средств.
  • 24. ISO 18019:2004 ИТ. Руководство по разработке пользовательской документации на прикладные программные средства для офисов, бизнеса и профессиональных применений.
  • 25. ISO 6592:2000. ОИ. Руководство по документации для вычислительных систем.
  • 26. ISO 9294:1990. (ГОСТ-1993 г). ТО. ИТ. Руководство по управлению документированием программного обеспечения.
  • 27. ГОСТ Р 51901-2002. Управление надежностью. Анализ рисков технологических систем.
  • 28. ISO 14143: 1-5: 1998 - 2004. ИТ. Измерение программных средств. Измерение функционального размера. 4.1. 1998. Определение концепции. Ч. 2. 2002. Оценивание соответствия методов измерения размера программных средств стандарту ISO 14143:1:1998. Ч.З. 2003. Верификация методов измерения функционального размера. Ч. 4.2002. Эталонная модель. Ч. 5. 2004. Определение функциональных доменов для использования при измерении функционального размера.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >