Подготовка программы к эксплуатации

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

Техники тестирования базируются на некоторых теоретических и практических положениях, например, на природе подхода к проектированию (компонентного, объектно-ориентированного, сервисного и т.п.), а также на следующих данных:

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

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

Инструкция-обзор по режимам песочной фильтрационной установки Intex

Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Процесс тестирования документируется и согласно стандарту IEEE 829-98 включает описание тестовых документов, их связи между собой и с задачами тестирования. Без документации по процессу тестирования невозможно провести сертификацию продукта по модели СММ [1.20]. После завершения тестирования рассматриваются вопросы стоимости и оценки рисков, вызванных сбоями или недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или его продолжении.

Управление тестированием:

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

Заметим, что стандарт ISO/IEC 12207 и гармонизированный ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование как неотъемлемую часть всего ЖЦ.

Первый запуск посудомойки. Пошаговая инструкция.

1.1.5. Сопровождение ПО (Software maintenance)

Сопровождение ПО — совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или улучшению других характеристик ПО. В связи с решением проблемы 2000 года сопровождение стало рассматриваться как более важный процесс, который должны осуществлять разработчики. Новая версия системы должна решать те же самые задачи, иметь план переноса информации в другие обновленные БД и учета стоимости сопровождения. Сопровождение (в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.

Область знаний «Сопровождение ПО ( Software maintenance )» состоит из следующих разделов:

• основные концепции (Basic Concepts),
• процесс сопровождения (Process Maintenance),
• ключевые вопросы сопровождения ПО (key Issue in Software Maintenance ) ,
• техники сопровождения (Techniques for Maintenance)

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

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

К основным концепциям можно отнести ЖЦ ПО (стандарт ISO/IEC 12207) и составление документации. Главное назначение этой области знаний состоит в выполнении готовой программной системы, фиксации возникающих ошибок при выполнении, исследовании причин ошибок, анализа необходимости модификации системы в целях устранения ошибок, оценки стоимости работ по проведению изменений функций и системы в целом. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и методы ее преодоления.

Процесс сопровождения включает: модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений. Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:

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

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

Эволюция ПО.Известный специалист в области ПО Дж. Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становится более сложной и плохо управляемой, возникает проблема уменьшения ее сложности. К технологиям эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.

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

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

Чаще всего реверсная инженерия применяется после того, как в код ПО было внесено много изменений и оно стало неуправляемым.

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

1.1.6. Управление конфигурацией ПО

Управление конфигурацией (Software Configuration Management — SCM ) состоит в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта; составляются отчеты об изменениях, внесенных в конфигурацию, и степени их реализации, а также проводится проверка соответствия внесенных изменений заданным требованиям.

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

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

Область знаний «Управление конфигурацией ПО» состоит из следующих разделов:

• управление процессом конфигурации (Management of SCM Process),
• идентификация конфигурации ПО (Software Configuration Identification ),
• контроль конфигурации ПО (Software Configuration Control ),
• учет статуса (положение конфигурации в ПО или состояние) конфигурации ПО (Software Configuration Status Accounting ),
• аудит конфигурации ПО (Software Configuration Auditing ),
• управление версиями ПО и доставкой (Software Release Management and Delivery).

Управление процессом конфигурации.Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетной информацией, касающейся конфигурации. Включает:

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

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

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

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

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

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

Базис (baseline) — формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.

Библиотека ПО — контролируемая коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО.

Сборка ПО — объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.

Источник: intuit.ru

Порядок проведения опытной эксплуатации

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

Программа опытной эксплуатации должна предусматривать [36]:

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

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

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

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

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

Оценка качества программного обеспечения

Качество – это совокупность свойств и характеристик объекта, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Под качеством программного обеспечения понимается совокупность показателей, характеризующих устойчивость работы, свойство интерфейса, а также способность программы удовлетворить потребности пользователя в обработке информации. Показателем качества программного продукта является наличие сертификата. Сертификация – это действие третьей стороны, доказывающее, что обеспечивается необходимая уверенность в том, что продукция или предоставляемая услуга соответствует стандарту. В стандарте ИСО 9000-3-91[24] предусмотрены показатели качества программного продукта, такие как надежность работы, удобство сопровождения и применения, эффективность программного продукта.

Надежность программного обеспечения является очень важным и ответственным параметром программного обеспечения. История помнит множество случаев, когда ненадежность программного обеспечения приводила к крупным последствиям. Неудачный исход первого полета на Венеру американской автоматической станции, из-за ошибки в списке операторов цикла на Фортране, остановка на несколько дней конвейера ВАЗа в 80-ых годах (была проведена информационная диверсия работником ВЦ), неудачная посадка американского космического корабля на Марс из-за ошибки в программе управления кораблем являются яркими примерами этого.

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

Проблема надежности программного обеспечения всегда была объектом пристального внимания программистов. Программисты на опыте убедились, что исправление ошибок занимает много времени при программировании. Надежность программного обеспечения зависит первую очередь от отсутствия программных ошибок. Характерными случаями возникновения программных ошибок являются [49]:

1. Программная ошибка происходит тогда, когда программа работает не в соответствии со своими спецификациями. Не всегда верны и спецификации. Опыт показывает, что спецификации являются одним из главных источников ошибок.
2. Программа работает с ошибками, если эксплуатируется за приделами определенных границ. Проблема определения границ таблиц являются не простым. Как определить границы таблицы, как постараться избежать ее переполнения? Например, АСУ-ВУЗ работает без ошибок, если количество студентов не более 10000 (потому что разработчики ПО — ВУЗа предположили, что никогда в ВУЗе не будет больше 100000 студентов и при использовании данного программного продукта в ВУЗе с количеством студентов более 10000 у системы появляются проблемы).
3. Ошибка имеет место тогда, когда работа программы не соответствует сопутствующей ей документации. (Как быть, если и в документации и в программе есть ошибки?).

4. Несоответствие работы программы первоначальным требованиям пользователя-заказчика. (Как правило, первоначальные требования заказчика бывают очень расплывчатые, не подробные, не всегда описывают желаемое поведение программы при всех возможных условиях).

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

Имеется множество факторов, определяющих надежность ПО. В.В.Шураков [49] выделяет следующие основные факторы надежности (рис.16).

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

Под признаком «где» мы подразумеваем классификацию среды фиксации ошибки: персонал (структуры, процедуры и т.д.), оборудование (ПЭВМ, связь), программное обеспечение.

Источник: studfile.net

Большая Энциклопедия Нефти и Газа

Для эксплуатации программы NWA требуется лишь минимальная конфигурация ПЭВМ с объемом рабочей памяти 256 Кбайт. Перед считыванием программы дискета устанавливается в дисководе. После ввода команды NWA программа считывается и запускается. [3]

Опыт эксплуатации программ показал, что дальнейшее развитие методов проектирования с применением ЭВМ связано с совершенствованием изыскательских работ с целью более достоверного определения характеристик среды, прогнозированием изменения свойств грунтов в процессе эксплуатации, учетом фактических эксплуатационных нагрузок и более точным моделированием взаимодействия трубопровода с грунтом. [4]

Опыт эксплуатации программ анализа и оптимизации фазовращателей показал, что успех их проектирования во многом зависит от правильного выбора исходных параметров. Наибольшую критичность фазовращатели обнаруживают к величинам регулирующих емкостей Cpi. Уменьшение Cpi ведет к увеличению возможного диапазона регулирования фазы; с другой стороны, возрастает рассогласование управляемых секций из-за неизбежных разбросов Cpi от секции к секции и от заданного номинального значения. Увеличить Cpi возможно только при изменении размеров поперечного сечения связанных линий, что порождает необходимость оптимизации конструкции по наиболее трудно изменяемым параметрам. Тем не менее построение программ с менее жесткими алгоритмами оптимизации, предусматривающими изменение возможно большего числа исходных параметров, перспективно в отношении рассматриваемых управляемых устройств СВЧ на основе СПЛ. [5]

Инструкция по эксплуатации программ содержит следующие разделы. [6]

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

В процессе эксплуатации программы , кроме результатов счета, могут выводиться на печать сообщения об ошибках. Возможные типы ошибок ( 6 типов) описаны в § 6 гл. [8]

Для возможности эксплуатации программы кем-либо кроме автора она должна быть оформлена. В описание включается инструкция по использованию программы, излагается примененный метод решения, приводятся алгоритмы ( иногда и текст программы), а также контрольные примеры с эталонными результатами. Наличие описания программы позволяет не только успешно эксплуатировать ее длительное время, но и проводить ее модернизацию и использовать в дальнейших разработках. [9]

Потери эффективности при эксплуатации программ вследствие их отказов С3э характеризуют устойчивость ПС к различного рода внешним возмущениям. Возмущения приводят к отказовым ситуациям, которые при длительности восстановления 4 больше допустимой 4 регистрируются как отказ, снижающий надежность. Интенсивность отка-зовых ситуаций зависит от уровня отлаженности программ или от вероятности р0 невыявленной программной ошибки. [10]

Для подготовки к эксплуатации программы должны быть записаны на магнитную ленту. [12]

Для подготовки к эксплуатации программы должны быть записаны на магнитную ленту. [14]

Для подготовки к эксплуатации программы должны быть запи-аны на магнитную ленту. [15]

Источник: www.ngpedia.ru