Управление программными проектами. Учебное пособие

7Катастрофический – решение о прекращении выполнения программы исходит от пользователя; система разрушается.

8Инфекционный – разрушает другие системы, даже если работоспособность исходной системы не нарушена.

Завершив составление матрицы источников ошибок и их классификацию,

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

Таблица 7.2 – Виды и источники сбоев

Следующий этап – определение потребностей заказчика в надежности. Эти потребности заранее определены и задокументированы в документе SRS.

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

121

1Минимальный показатель надежности функционирования системы запуска ракет составляет 0.999 от 95-процентного доверия, основанного на подтверждении запуска по отношению к отделению от носителя полезной нагрузки.

2Надежность системы управления спутниками оценивается как 0.999 от 95-

процентного доверия на период, равный 15 годам с момента разделения полезной

нагрузки.

3Для авиационной системы характерно в среднем 500 летных часов между критическими ошибками.

4Встроенная система самоконтроля определит неисправную ракету с вероятностью 60 процентов.

5Встроенная система самоконтроля примет реальную ракету за неисправную с вероятностью менее 1 процента.

6Среднее время исправления функционирующего ПО составляет 30 минут или меньше.

7Среднемаксимальное корректировочное время составляет 60 минут с 90-

ым процентным распределением.

8 Максимальное время завершения работы встроенной системы

самоконтроля составляет 20 секунд.

9Среднее время загрузки ПО в полном объеме и выполнения полного внутреннего самоконтроля составляет 10 минут.

10Среднее время обновления одной интерактивной страницы документации составляет 30 минут.

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

сформулированных в требованиях. При отсутствии исторических данных,

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

122

этапе менеджеру проекта необходимо разработать экстенсивные системные модели,

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

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

Этап 5 заключается в определении целей надежности, основанных на результатах альтернативных учебных курсов. Окончательный набор целей обеспечения надежности передается обратно, процессу определении требований,

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

Предотвращение сбоем включает итеративное уточнение системных требований и выработки технических характеристик ПО наравне с моделированием,

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

заключается в исследовании системы и требований, как описывалось выше.

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

Вторым основным методом предотвращения ошибок является разработка и внедрение проекта. Если команда разработчиков проекта сначала начинает разработку и внедрение, функции по обеспечению надежности распределяются

123

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

На ранних стадиях жизненного цикла разработки ПО цель обеспечения надежности направлена на предотвращение возможных ошибок. В таблице 7.3

представлены подпроцессы основного интерфейса фаз жизненного цикла разработки ПО, которые поддерживают предотвращение сбоев.

Цели обеспечения надежности, предварительно определенные и задокументированные, должны быть установлены для модулей во время разработки.

Разработку так же, как и качество, никогда нельзя проконтролировать или добавить.

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

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

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

124

что и в случае с компонентами программного продукта, созданными с нуля.

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

Таблица 7.3 – Действия жизненного цикли разработки ПО, направленные на предотвращение сбоев

Устранение возникающей в системе ошибки обходится в 10-100 раз дороже,

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

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

125

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

Первая часть этапа устранения ошибок сосредотачивается на фазах проектирования и внедрения. Вторая часть, фаза установки, начинается с работы,

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

пока имеет место частично функционирующая система. Его можно определить в самом начале жизненного цикла разработки продукта с помощью использования прототипов.

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

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

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

ганизации к обучению.

На средних фазах жизненного цикла разработки ПО усилия по обеспечению надежности сосредотачиваются на устранении дефектов. В таблице 7.4 отражены

126

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

Таблица 7.4 – Действия по устранению сбоев в жизненном цикле разработки ПО

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

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

Отказоустойчивость – внутреннее свойство программной системы,

заключающееся в постоянном предоставлении услуг своим пользователям,

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

127

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

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

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

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

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

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

128

выполняющего задачи по сопровождению продукта, осуществляются только со

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

Организация должна иметь доступ к базе данных по ошибкам, обнаруженным после

установки других продуктов. Подобная ин формационная структура, включающая

описания ошибок и действий, предпринятых для их управлении и устранении,

используются для оценки необходимых трудозатрат, понесенных на этапе

сопровождения продукта. Используя хронологические сведения о результатах

оценок ошибок, обнаруженных на фазе разработки, и относительный размер нового

продукта сравнительно с другими, можно выполнить быструю оценку остальных

ошибок и трудозатрат, необходимых для их устранения в новой версии продукта.

Таблица 7.5 – Действия жизненного цикла разработки ПО, обеспечивающие

устойчивость к сбоям

Чтобы обеспечить набор данных для программных продуктов,

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

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

7.3 Инструменты и план обеспечения надежности ПО

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

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

130