Вопросы, которые рассматриваются в этой главе.
♦ Понимание определения сопровождения программ.
♦ Правильная оценка затрат на сопровождение.
♦ Понимание вопросов сопровождения программ.
♦ Организация сопровождения.
♦ Использование стандарта сопровождения IEEE.
♦ Применение метрик сопровождения.
10.1. Введение.
Рассмотрим типичную последовательность действий по обработке запроса на сопровождение (MR — maintenance request).
1.
Будьте готовы вести учет необходимых метрик, включая:.
♦ количество добавленных строк;.
♦ количество измененных строк;.
♦ время, ушедшее на подготовку, разработку, кодирование, тестирование.
2.
Убедитесь в том, что запрос был подтвержден.
3.
Тщательно изучите проблему:.
♦ воспроизведите ее или.
♦ уточните ситуацию иными средствами.
4.
Классифицируйте запрос на сопровождение как исправление или усовершенствование.
5.
Решите, требует ли реализация переработки на более высоком уровне:.
♦ в случае положительного решения рассмотрите возможность объединения данного запроса с другими.
6.
Произведите запрошенную модификацию (то есть внесите необходимые изменения).
7.
Планируйте переход с учетом текущего состояния.
8.
Контролируйте влияние небольших изменений в масштабе всего приложения:.
♦ небольшие изменения могут быть очень существенны!.
9.
Реализуйте изменения.
10.
Выполните модульное тестирование измененных компонентов.
11.
Выполните регрессионное тестирование,.
♦ убедитесь, что изменения не ухудшили достигнутые характеристики.
12.
Выполните системное тестирование с новыми функциями.
13.
Обновите документацию, описывающую конфигурацию, требования, проектирование и тестирование.
Далее эти действия будут рассмотрены более подробно с соответствующими теоретическими обоснованиями.
10.1.1. Сопровождение программ.
Сопровождение программного продукта включает в себя все действия, выполняемые с приложением после поставки продукта заказчику. В словаре IEEE [57].
сопровождение программы определяется как процесс изменения программной системы или компонента после поставки с целью исправления ошибок, повышения производительности или иных параметров, а также для адаптации к изменившимся условиям.
По различным оценкам сопровождение программы составляет от 40 до 90 % стоимости всего жизненного цикла приложения (например, [31], [89]). Можно возразить, что в указанное выше определение сопровождения включены усовершенствования, которые лучше было бы считать дополнительными разработками. В любом случае объем работ по сопровождению программ обычно достаточно велик. Наиболее значительные усилия в области сопровождения были затрачены на решение проблемы 2000 года (Y2K). Изменение приложений для работы с датами, относящимися к новому тысячелетию, потребовало огромного труда. Эти работы относятся именно к сопровождению программ, потому что их целью было сохранение функциональности существующих приложений.
Лехман [Lei, Le2] предложил «закон», заключающийся в том, что любая программа, адаптацией которой к изменяющимся условиям никто не занимается, с течением времени неизбежно теряет свою ценность. Другими словами, если приложение остается неизменным, польза от него постепенно убывает.
10.1.2. Вопросы сопровождения программ.
Чтобы представить, какие проблемы возникают при сопровождении программ, вообразите приложение настолько большое, что ни один человек не может знать всех его функций и особенностей. Автор работал с защитными системами больших кораблей, которые могут быть отнесены именно к этому классу программ. Большую проблему в сопровождении таких программ создает «эффект ряби», возникающей при внесении изменений. Когда множество относительно безвредных изменений производятся одновременно в «удаленных уголках» больших приложений, эти изменения могут приводить к повреждению приложения как целого.
Беннетт [8] упорядочил проблемы, связанные с сопровождением программ, разделив их на три категории.
♦ Проблемы управления:.
♦ трудность выявления прибыли на инвестированный капитал.
♦ Проблемы обработки:.
♦ для обслуживания потока запросов на сопровождение требуется жесткая координация.
♦ Проблемы технического характера:.
♦ трудность учета всех результатов изменений;.
♦ высокая стоимость тестирования по сравнению с пользой от отдельных изменений: идеальным было бы сосредоточенное тестирование, но оно стоит дорого. Невозможно полностью исключить регрессионное тестирование.
Руководство обычно гораздо сильнее интересуется процессом поставки приложений. Кроме того, затраты на сопровождение программы трудно классифицировать как прибыль на инвестированный капитал.
Раскроем этот момент подробнее. Предположим, что Военно-морской флот уведомляет нас (фирму-подрядчик) о том, что алгоритм согласования трех независимых источников навигационных данных работает неправильно. Необходимо оценить стоимость внесения исправлений. Пример расчета приведен в табл. 10.1. Затраты на изменение программы при стоимости одного человеко-часа $50-100 (с учетом пособий и т. п.) будут составлять, таким образом $5600-28 000. Разброс значений очень велик.
Таблица 10.1. Оценка стоимости выполнения запроса на сопровождение | ||||||||||||||||||||||||||||
|
Если бы мы имели дело с одним конкретным изменением, проблемы были бы еще не так велики. Обычно организации сталкиваются с непрерывным потоком запросов на сопровождение. Большое количество изменений позволяет снизить стоимость каждого из них, но поток запросов создает повышенные требования к системе обработки. Усилия программистов, тестеров и разработчиков документации нужно координировать. Например, нужно ли обновлять SRS после обнаружения ошибки, после ее устранения, после тщательного тестирования или же, наконец, после объединения данного исправления с другими операциями, выполненными в рамках работ по сопровождению? В любом случае согласованность документации и исходного кода будет время от времени нарушаться. Без внимательного руководства эти кратковременные, казалось бы, несоответствия начнут размножаться, в результате чего документация перестанет соответствовать реальным функциям приложения, и никто не будет знать, что же на самом деле творится с приложением.
Суть в том, чтобы сделать изменения понятными и даже элегантными. Элегантность хорошо иллюстрирует следующий пример: можно увеличить полезное пространство в доме, пристроив к нему сарай, а можно сохранить цельность здания, увеличив его объем искусными архитектурными приемами. Пристройка может ухудшить внешний вид и структуру всего здания, а хороший архитектор всегда постарается этого избежать.
Тестирование — еще одна важная техническая проблема. Даже сосредоточенное тестирование измененных или добавленных компонентов отнимает достаточно времени, потому что для этого часто приходится разрабатывать специальные планы. Но сосредоточенного тестирования недостаточно, потому что возможность распространения «ряби», вызванной изменениями, требует проведения регрессионного тестирования, которое могло бы исключить ухудшение имевшейся функциональности приложения. Затраты на тестирование составляют значительную долю общих затрат на сопровождение программы.
10.1.3. Организация процесса сопровождения.
Блок-схема организации процесса сопровождения согласно [89] приведена на рис. 10.2. Пункты 1а-1д фактически относятся к этапу разработки. «Разработка с учетом сопровождения» подразумевает попытку предугадать, в каких направлениях будут развиваться требования к продукту, и учесть это в плане. С этой целью часто применяются, например, образцы проектирования. «Удобство поддержки» в пункте 1 б означает возможность эффективного сопровождения. Для этого в код должны включаться подробные комментарии. Персонал, занимающийся сопровождением, имеет обычно не столь специализированные знания, как разработчики, потому что сопровождение требует работы с гораздо большим объемом кода. Тем не менее служба сопровождения должна быть способна после внимательного изучения кода прийти к пониманию смысла каждой инструкции. Только после этого допустимо внесение изменений. Удобство поддержки гарантируется постоянным уровнем качества кода.
Пункт 2 состоит в принятии решения о масштабах затрат на сопровождение: главным образом речь идет о том, следует ли относить усовершенствования к работам по сопровождению. Возможные варианты рассматриваются в разделе 10.2.
Согласно пункту 3, вам предстоит выбрать, своими или наемными силами выполнять работы по сопровождению. Заключение контракта на сопровождение программы обладает преимуществами конкурентоспособной цены и дает возможность владельцу приложения сосредоточиться на других задачах. Недостаток в том, что ваши сотрудники постепенно теряют контроль над кодом приложения.
Планирование процесса сопровождения обсуждается в разделе 10.5.
10.2. Виды работ по сопровождению.
Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60-80 % работ обычно относится к усовершенствованию приложения, а не к исправлению его недостатков (например, [89] и [38]).
Лиенц, Свенсон и др. [79] дополняют иерархию работ, разбивая каждую из определенных выше категорий на две (рис. 10.3).
 |
Рис. 10.2. Схема организации процесса сопровождения |
 |
Рис. 10.3. Виды работ по сопровождению |
Приспособление, или адаптация (adaptive maintenance), относится к исправлению недостатков, потому что функциональность приложения в результате не изменяется и никакого усовершенствования не происходит.
Необходимость упреждающего сопровождения (preventive maintenance) следует из наблюдений Лемаша [Lei, Le2]): без специальных поправок структура сопровождаемой программы постепенно усложняется и со временем становится настолько сложной, что стоимость ее изменения становится неприемлемой.
Рассмотрим пример одного из видов сопровождения применительно к игре Встреча. Пример исправления недостатков показан в запросе на сопровождение 78. Персоналу, который занимается сопровождением, нужно решить: кроется ли ошибка в методе adjustQual ity О или неправильно сформулированы требования к персонажам игры. На самом деле проблема именно в требованиях, которые гласят:.
♦ пользователь может установить для любой характеристики своего персонажа любое значение, не превышающее текущей суммы значений всех характеристик;.
♦ пропорции всех остальных значений при этом сохраняются;.
♦ значение характеристики не может лежать в интервале от 0 до 0,5;.
♦ сумма значений характеристик остается постоянной.
Как следует из запроса 78, эти требования противоречивы и не могут быть удовлетворены одновременно. Поскольку проблема обнаружена в требованиях к программе, заказчик должен санкционировать внесение изменений. Можно, например, ослабить последнее требование (требование инвариантности суммы), записав его в форме.
О
< (сумма характеристик)
< ab§(сумма характеристик - N), где N — количество характеристик, abs — абсолютное значение (модуль числа), ах — значениех после изменения одной из характеристик игроком. После такого изменения правил игроку все равно будет невыгодно менять значения характеристик слишком часто и слишком сильно, потому что при этом могут теряться очки.
Запрос на сопровождение 78.
При изменении игроком значения одной из характеристик сумма всех значений должна сохраняться, но этого не происходит. Например, если характеристики имеют следующие значения: сила = 10, терпение = 0,8, выносливость = 0,8 (сумма = 11,6), и игрок устанавливает силу равной 11, в результате его характеристики получают з}1ачения: сила = 11, терпение = 0 и выносливость = 0.
Теперь займемся запросом на сопровождение с улучшением (perfective maintenance). Предположим, что отдел маркетинга решил сделать игру более привлекательной, основываясь на том, что пользователи должны получать максимально ощутимую награду за свой уровень. Предлагается, чтобы при переходе игрока на следующий уровень облик игры в целом становился более качественным. Отдел оформления предоставит необходимые рисунки, а отдел сопровождения должен внести изменения, отражающие новые требования. Запрос 162 будет обсуждаться далее в тексте главы.
Запрос на сопровождение 162.
Измените игру Встреча так, чтобы она начиналась с отображения зон и их соединений в согласованном стиле.
Когда игрок достигает второго уровня, все зоны и их соединения отображаются в усовершенствованном согласованном стиле, который доступен только для уровня 2, и т. п. Отдел оформления обеспечит необходимые изображения.
10.3. Методы сопровождения 10.3.1. Анализ влияния факторов.
Последовательность обработки запросов на сопровождение состоит из анализа, проектирования и реализации, точно так же, как и обычная разработка. Существенным отличием является необходимость анализа влияния изменений на артефакты. Согласно исследованию Вейсса [НО], 19 % дефектов в приложениях образуются на этапе определения требований, 52 % — на этапе проектирования и 7 % — в процессе программирования. Многие другие авторы утверждают, что доля дефектов, вызванных неправильной формулировкой требований, должна быть значительно выше. Влияние устранения дефекта на артефакты иллюстрирует рис. 10.4.
 |
Рис. 10.4. Влияние дефекта на сопровождение |
В случае минимального влияния изменения вносятся в один-единственный артефакт. Это происходит, например, при нарушении программистом стандарта именования локальных переменных или при удалении неиспользованной переменной из программы. Напротив, в худшем случае изменения распространяются на все этапы процесса. Даже для дефекта, возникшего на уровне кода (то есть дефекта, связанного лишь с неправильным кодированием), степень влияния может быть как малой, так и весьма значительной. Кажущееся простым изменение, например увеличение размера статического массива в С++, может вызвать сильную «рябь» по всему приложению.
Запрос 162, приведенный ранее, влияет на все аспекты процесса, показанного на рис. 10.5. Если приложение разрабатывается так, чтобы его можно было прослеживать, то документировать действия по сопровождению может быть относительно несложно. В противном случае последствия могут быть крайне дорогостоящими. Подробнее об анализе влияния действий по сопровождению на уровне кода рассказывается в книге [111].
 |
Рис. 10.5. Влияние запроса 162 |
10.3.2. Обратное проектирование.
История сопровождаемого программного продукта может быть очень непростой. Многие существующие приложения часто оказываются снабжены скудной или противоречивой документацией. Первым шагом в организации рациональных работ по сопровождению таких приложений должно быть создание подробной согласованной документации. Для этого часто требуется восстановление архитектуры по исходному коду — обратное проектирование (reverse engineering). Существует несколько программных средств, помогающих выполнить эту задачу. Например, пакеты Rational Rose (Rational Corporation) и Together (Object International) позволяют создавать модели объектов из исходного кода на С++ и Java. Получающиеся в результате диаграммы можно использовать для анализа хода мыслей разработчика. Из-за неоднозначности трактовки диаграмм на UML и механичности процесса обращения обратное проектирование не позволяет полностью понять намерения разработчика. Когда разработчик рисует прямоугольники и связи UML, их геометрическое размещение (например, группировка) несет смысловую нагрузку, воспринимаемую только людьми.
Обратное проектирование является более общим средством, чем преобразование кода в проект, поскольку представляет собой процесс восстановления содержания какого-то этапа по артефактам последующего этапа. Получение намерений из структуры возможно не всегда. Отсылаем читателя к недокументированному коду в разделе 1.5.1. Из-за отсутствия комментариев сделать выводы о назначении кода просто невозможно.
10.3.3. Реинжиниринг.
В 1980 году в книге Хаммера и Чампи [40] о реинжиниринге бизнес-процесса (BPR — Business Process Reengineering) компаниям предлагалось заново взглянуть на процесс производства ценностей для потребителей, после чего спроектировать его заново. Хаммер и Чампи основное внимание уделяли процессу как целому, а не отдельным его частям. Процесс начинается с входных данных, например заказов, заканчивается окончательной отгрузкой товаров или предоставлением услуг и включает все способствующие достижению цели элементы, такие как поддержка программ и вклад сотрудников. Реинжиниринг заставляет взглянуть на требования к программным приложениям как на часть требований к предприятию (компании, организации и т. п.) в целом. Получающиеся приложения иногда называются корпоративными приложениями (enterprise application), хотя обсуждаемая концепция используется и вне контекста реинжиниринга бизнеспроцесса. Реинжиниринг обычно заставляет ответить на вопрос о том, как должны работать существующие приложения, а не о том, как они работают. Фактически, при реинжиниринге к бизнес-процессу применяются концепции системной разработки, обсуждавшиеся в главе 3.
Реинжиниринг относят к сопровождению, потому что он требует перепланирования приложений. Сравнение экспансивного развития с реинжинирингом на примере моста приводится на рис. 10.6. В первом случае мост укрепляется, а во втором — перестраивается для того, чтобы отвечать возросшим требованиям.
В качестве примера рассмотрим компанию, приступающую к реинжинирингу процесса обучения менеджеров. Реинжиниринг подразумевает изучение процесса от начала до конца. Обычно оказывается непрактичным переписывать программы с нуля, поэтому берутся имеющиеся программы, которые затем перепроектируются так, чтобы удовлетворять изменившимся требованиям. Высокоуровневая схема интеграции видеоигры Встреча в систему обучения менеджеров показана на рис. 10.7. Результатом реинжиниринга станет адаптация игры Встреча для получения приложения, моделирующего менеджмент и оценивающего результаты.
 |
Рис. 10.7. Реинжиниринг игры Встреча для обучения менеджменту |
10.3.3.1. Рефакторинг.
Часто усовершенствование программы требует не просто изменения отдельных строк кода, а приложения гораздо больших усилий, не достигающих, однако, масштабов полного реинжиниринга. Иногда этот процесс называют рефакторингом (refactoring). Фаулер [32] рассматривает пример проекта для магазина видеофильмов — этот проект не слишком хорош, но вполне пригоден для конкретной простой задачи. Затем он показывает, как можно переделать проект под новые требования, например добавить возможность формирования новых типов отчетов. Этот процесс включает экстракцию метода (то есть создание метода, заменяющего имеющийся фрагмент кода). Другие примеры рефакторинга включают воплощение идей главы 7, посвященной реализации, в код, например замену литерной константы.
final int MAX_NUM_VIDEOS = 18; методом.
static final int getMaxNumVideos() . . .
10.3.4. Унаследованные приложения.
Унаследованные системы (legacy systems) — это приложения, решающие существующие задачи. Иногда термин legacy трактуется как устаревшие и применяется к программам, которые не стоят того, чтобы их модифицировать.
Беннетт [8] перечисляет возможные действия с унаследованными системами.
♦ Продолжать сопровождение;.
♦ Прекратить сопровождение и:.
♦ заменить на покупной продукт;.
♦ заменить на собственный продукт, полученный обратным проектированием или разработкой с нуля. Возможна поэтапная замена;.
♦ присоединить к новому приложению. Сопровождение заморозить;.
♦ инкапсулировать и использовать как сервер. Возможно использование образца проектирования Adapter.
Присоединение и инкапсуляцию иллюстрирует рис. 10.8. Под меткой i на этом рисунке показано, каким образом новое приложение получается из исходного путем расширения или модифицирования последнего. В примере с игрой Встреча это могло бы потребоваться, если бы нам нужно было получить игру в реальном времени от первого лица. В такой ситуации к существующей игре Встреча можно было бы добавить графический процессор (расширение), который постоянно отображал бы все, что видит игрок, а исходный код изменить так, чтобы поле игры отображалось глазами игрока, а не в перспективе с видом сверху.
При инкапсуляции исходное приложение практически не изменяется. Новое приложение создается полностью независимо, а в процессе его выполнения вызывается функциональность унаследованного приложения. Это может осуществляться как напрямую (метка ed), так и через обертку (метка ew). Часть рисунка под меткой ed отвечает образцу проектирования Adapter (см. главу 6), если унаследованное приложение является объектно-ориентированным. Обертка — это программное обеспечение, предоставляющее интерфейс для обращения клиентов к унаследованному приложению. В частности, обертка может сделать любое приложение внешне объектно-ориентированным. После этого можно применять образец проектирования Adapter.
 |
Рис. 10.8. Использование унаследованных приложений |
10.3.5. Обновление документации.
Действия по сопровождению включают в себя гораздо больше, нежели просто технические изменения и дополнения. Для отражения каждого такого действия требуется обновление всей цепочки документации. Например, исправление, вызванное дефектом в требованиях, приводит к изменению документации, содержащей требования к продукту, а также, вероятно, проектной документации и обязательно — документации на реализацию и тестирование. Кроме того, необходимо изменение состояния системы управления конфигурациями для отражения новой версии продукта. Для больших программ, в работе над которыми случалось принимать участие автору, устранение дефектов часто занимало меньше времени, чем обновление документации. Но если игнорировать необходимость обновления, то документация потеряет согласованность, из-за чего стоимость сопровождения начнет возрастать и в конце концов окажется просто неприемлемой.
10.4. Стандарт IEEE 1219-1992.
Стандарт IEEE 1219-1992 определяет процесс сопровождения программного обеспечения. Семь стадий процесса, описанные в этом стандарте, приблизительно соответствуют стадиям процесса разработки. Каждая стадия характеризуется шестью атрибутами (рис. 10.9). Значения этих атрибутов для каждой из семи стадий процесса сопровождения приведены в табл. 10.2 и табл. 10.3. Содержание стандарта IEEE 1219-1992 приводится ниже.
1.
Определение задачи.
1.1.
Входные данные.
1.2.
Процесс.
1.3.
Контроль.
1.4.
Выходные данные.
1.5.
Факторы качества.
1.6.
Метрики.
2.
Анализ.
2.1.
Входные данные.
2.2.
Процесс.
2.2.1.
Анализ осуществимости.
2.2.2.
Подробный анализ.
2.3-2.6. Контроль, Выходные данные, Факторы качества, Метрики.
3.
Проектирование.
3.1-3.6. Входные данные, Процесс, Контроль, Выходные данные, Факторы качества, Метрики.
4.
Реализация.
4.1.
Входные данные.
4.2.
Процесс.
4.2.1. Кодирование и тестирование.
4.2.3.
Анализ и обзор рисков.
4.2.4.
Проверка готовности к тестированию.
4.3-4.6. Контроль, Выходные данные, Факторы качества, Метрики.
5.
Системное тестирование.
5.1.-5.6. Входные данные, Процесс, Контроль, Выходные данные, Факторы качества, Метрики.
6.
Приемосдаточное тестирование.
6.1.-6.1. Входные данные, Процесс, Контроль, Выходные данные, Факторы качества, Метрики.
7.
Поставка.
7.1.-7.6. Входные данные, Процесс, Контроль, Выходные данные, Факторы качества, Метрики
 |
Рис. 10.9. Атрибуты стадий сопровождения |
10.4.1. Определение задачи сопровождения.
Стадия процесса обработки запросов на сопровождение, на которой происходит определение задачи, описана в табл. 10.2. В примере в конце этой главы определение задачи выполняется отделом маркетинга, который запросил и изучил жалобы пользователей на сложность алгоритма обмена характеристиками персонажей игры Встреча.
Таблица 10.2. Определение задачи запроса на сопровождение | ||||||||||||||
| ||||||||||||||
10.4.2. Анализ задачи.
Стадия анализа задачи в процессе обработки запросов на сопровождение описана в табл. 10.3.
Таблица 10.3. Анализ запроса на сопровождение | ||||||||||||||
| ||||||||||||||
10.4.2.1. Пример анализа задачи сопровождения.
Задачи сопровождения бывают как очень простыми, так и требующими предельного напряжения. Предположим, например, что мы хотим дополнить игру Встреча новыми параметрами изображения для главного игрока. Задача кажется довольно прямой и ясной, однако объем работ по запросам, подобным этому, часто недооценивается. Процедура анализа задачи должна выявлять реальные трудозатраты на внесение изменений и дополнений. Например, может выясниться, что увеличение параметров изображений может потребовать полного изменения методов выбора и отображения.
Проанализируем приведенный выше запрос на сопровождение 162 и оценим ресурсы на проектирование и реализацию необходимых изменений. Будем использовать образец проектирования Abstract Factory, описанный в главе 6. Для согласования и добавления новых классов требуется изменение объектной модели.
После этого нужно будет заменить все ссылки на Area и AreaConnection в клиентском коде (использующем новую конфигурацию), такие как.
new Area О new Connection О.
вызовами типа.
LevelNBui1der.getArea () LevelNBuilder.getConnecti on().
Охарактеризуем эти изменения в метриках IEEE.
♦ Количество изменений в требованиях для запроса 162: между 140 и 450. Поскольку мы упорядочили требования по классам, эта величина включает в себя:.
♦ количество новых классов, подлежащих описанию: 60-90 (пусть в игре будет 20-30 уровней; для каждого из них образец проектирования Abstract Factory требует создания класса Factory и подклассов Area и AreaConnection);.
♦ количество новых методов: (2-5 на класс) х (60-90 классов) = 120-450.
♦ Оценочная величина трудозатрат по запросу 162: от 2,4 до 9 человекомесяцев. Вычисляется через количество человеко-часов на каждое требование исходя из имеющихся данных по конкретному проекту. Например, если в исходном проекте было 300 требований и он был завершен за 6 человеко-месяцев, мы можем считать, что каждое требование требует 0,02 человеко-месяца. Отсюда для запроса 162 получается результат (120-450) х 0,02 = 2,4-9 человеко-месяцев. Природа классов позволяет уменьшить эту оценку, вероятнее всего до 3 человеко-месяцев.
♦ Оценка фактической продолжительности по запросу 162. Вычисляется по имеющимся фактическим данным точно так же, как и трудозатраты.
Для оценки правильнее использовать метод линейной регрессии, заключающийся в построении аппроксимирующей прямой по имеющимся фактическим данным.
10.4.3. Проектирование запроса на сопровождение.
Стадия проектирования запроса на сопровождение описана в табл. 10.4. Например, разработка запроса 162 выполняется с применением образца проектирования Abstract Factory и состоит в модификации исходного пакета EncounnterEnvi ronment (СредаВстречи). Документация для этого пакета до его модификации показана на рис. 10.10.
Таблица 10.4. Проектирование запроса на сопровождение | ||||||||
|
IEEE 1219-1992. Стадия сопровождения 3: проектирование | |
б. Процесс | Создать тестовые варианты Просмотреть: требования и план реализации |
в. Контроль | Верифицировать проект. Проинспектировать: проект и тестовые варианты |
г. Выходные данные | Измененные: список модификаций, детальный анализ и план реализации. Обновленные: каркас проекта и планы тестирования |
д. Выбранные факторы качества | Гибкость (проектирования) Прослеживаемость. Возможность повторного использования Понятность |
е. Выбранные метрики | Трудозатраты в человеко-часах Фактическая продолжительность Количество изменяемых приложений |
 |
Рис. 10.10. Пакет СредаВстречи до модификации |
В измененном приложении объекты Area и EncounterAreaConnection будут создаваться не непосредственно, а через методы getAreaO и getAreaConnectionO. Это методы нового класса EnvironmentFactory. Клиентская часть кода пакета EncounnterEnvironment может ничего не знать о типе создаваемых объектов Area и AreaConnection, поскольку все запросы на создание направляются через конкретный объект EnvironmentFactory, агрегируемый пакетом EncounterEnvironment. Во время выполнения программы клиентский код выбирает объект соответствующего подкласса EnvironmentFactory. На рис. 10.11 мы приводим классы Area и AreaConnection только для трех уровней игры, а не для всех уровней, запланированное число которых достаточно велико.
 |
Рис. 10.11. Применение образца проектирования Abstract Factory к игре Встреча |
Для перехода от старого проекта к новому нужен отдельный план. Этот план приведен на рис. 10.12. Он начинается с существующего проекта и состоит в добавлении и тестировании компонентов, не нарушающих имеющуюся реализацию. Перед последним шагом все готово к реализации образца проектирования Abstract Factory, причем все компоненты уже протестированы. На последнем шаге происходит окончательная реализация и тестирование.
10.4.4. Реализация запроса на сопровождение
Стадия реализации запросов на сопровождение описывается в табл. 10.5. Таблица 10.5. Реализация запроса на сопровождение | ||||||
| ||||||
IEEE 1219-1992. Стадия сопровождения 4: реализация | |
в. Контроль | Проверка кода. Верификация: контроль конфигурации и прослеживаемость нового кода |
г. Выходные данные | Обновленные: программное обеспечение, отчеты о модульном тестировании, пользовательские документы |
д. Выбранные факторы качества | Гибкость. Прослеживаемость Понятность. Удобство сопровождения Надежность |
е. Выбранные метрики | Количество строк кода Процент ошибок |
 |
Рис. 10.12. План перехода на многоуровневую версию Встречи |
Обработка запросов на сопровождение может потребовать разработки большого объема кода, в результате чего могут возникнуть новые дефекты. Процент ошибок — это количество дефектов, созданных в рамках трудозатрат по данной теме, в расчете на единицу измерения трудозатрат (например, человеко-месяц). Необходимо точно определить методику измерения количества новых дефектов. Можно, например, подсчитать «количество дефектов, найденных в течение трех месяцев с даты поставки». Предположим, что на обработку запроса 162 ушло 20 человеко-дней, за которые было создано 10 новых дефектов. Процент ошибок в этом случае будет составлять 10/20 = 0,5 дефекта/человеко-день.
Оставшиеся стадии процесса сопровождения — системное тестирование, приемка и обновление проектной документации — практически полностью аналогичны соответствующим фазам обычной разработки.
10.5. Управление сопровождением.
План сопровождения (maintenance plan) регламентирует поток запросов на сопровождение внутри организации. Типичный план сопровождения приведен на рис. 10.13. Жирной линией на нем отмечена номинальная последовательность обработки запросов. В этом плане отдел сопровождения принимает от пользователей (заказчиков) жалобы и предложения. Они оформляются как запросы на сопровождение. Специальное подразделение, которое может быть как одним человеком, так и целым комитетом, принимает решение о реализации запросов и присваивает им приоритеты. Такой комитет иногда называется Советом по контролю изменений (ССВ). После этого запросы обслуживаются техническим персоналом службы сопровождения. Тонкими линиями показаны другие последовательности появления и исчезновения запросов. Оптимальная организация работ по сопровождению зависит от масштабов приложения: процесс реализации запросов может быть достаточно растянутым.
С реализацией запросов связаны две проблемы. Первая — доставка подготовленного кода пользователям. Вторая — борьба с дефектами в целом. Дефект может повлиять на длительность тестирования, подготовка которого может недопустимо затянуться. Исключительным примером является военное приложение, в работах над которым довелось принять участие автору. Между определением задачи и полной реализацией запроса в этом проекте проходило до 9 месяцев! В таких ситуациях прибегают к выпуску исправлений или заплат (patch). Исправления — это изменения кода, которые либо устраняют дефект, либо позволяют обойти его. Исправления считаются временными. Часто они выпускаются в виде набора файлов, заменяющих уже написанный объектный код. Возможный вариант работы с исправлениями в организации, занимающейся разработкой, иллюстрирует рис. 10.14. Преимущества и недостатки исправлений рассматриваются в табл. 10.6.
 |
Рис. 10.13. Типичная последовательность работ по сопровождению |
Таблица 10.6. Преимущества и недостатки исправлений | ||||||||||
|
Под скрытием дефектов подразумевается то, что наличие неустраненного дефекта затрудняет обнаружение других дефектов, которые проявились бы, если бы первый дефект был устранен.
 |
Рис. 10.14. Сопровождение и исправление |
Опросы организаций, занимающихся сопровождением программ, показали, что эти организации ранжируют причины своих затруднений в следующем порядке [22].
1.
Изменение приоритетов.
2.
Методы тестирования.
3.
Измерение производительности.
4.
Неполная системная документация или ее отсутствие.
5.
Адаптация к изменяющимся требованиям бизнеса.
6.
Количество незавершенных задач.
7.
Измерение вклада.
8.
Низкий уровень самосознания из-за отсутствия признания или уважения.
9.
Недостаток персонала, в особенности квалифицированного.
10. Недостаточный уровень методологии, стандартов, средств и процедур сопровождения.
Видно, что наибольшие трудности вызываются частым изменением приоритетов задач, стоящих перед службой сопровождения. В качестве примера рассмотрим нашу игру Встреча. Приведенная ниже последовательность изменения основных приоритетов типична для любой огранизации-разработчика:.
♦ в момент выпуска — в игре должно быть меньше ошибок, чем у конкурентов:.
♦ решение: устранить максимальное количество дефектов;.
♦ через два месяца после выпуска — у игры должно быть больше достоинств, чем у ее основного конкурента;.
♦ решение: быстрое выполнение усовершенствований;.
♦ через шесть месяцев после выпуска — нужно снизить постоянно возрастающую стоимость сопровождения;.
+ решение: устранение только самых серьезных дефектов.
Второй и третий по масштабу источники проблем связаны с методами тестирования и измерения производительности. Как мы уже видели, список возможных тестов достаточно широк, а время их выполнения весьма продолжительно. Измерять эффективность предприятия, занимающегося сопровождением, тоже можно множеством способов. Сопровождение часто оказывается одной из важных статей расходов, но при этом недооценивается. Еще один источник проблем — задержка выполнения запросов, которые накапливаются с опасной быстротой. Наконец, сопровождение и тестирование часто считаются менее престижными и эффектными профессиями, чем проектирование.
10.6. Качество сопровождения.
Сопровождение нередко кажется тяжким грузом, но его можно рассматривать и как возможность продемонстрировать высокое качество обслуживания потребителей. Беннетт [9] пишет, что такое отношение к сопровождению широко распространено в Японии. Качественное сопровождение можно считать необходимым условием для достижения постоянной удовлетворенности покупателя и для получения его будущих заказов. Некоторые предприятия выделяют сопровождение в самостоятельный вид деятельности, потому что оно может стать надежным долгосрочным источником дохода.
10.6.1. Метрики сопровождения.
Поскольку на сопровождение уходит значительная часть общей суммы трудозатрат за время жизни приложения (иногда для предприятий это оказывается неожиданностью), особенно важным становится наличие адекватной методики оценки затрат на сопровождение и доходов от него. Перечислим основные метрики сопровождения:.
♦ количество строк сопровождаемого кода;.
♦ трудозатраты на решение задач по сопровождению;.
♦ количество дефектов.
Прежде всего следует определить цели сопровождения конкретного приложения, после чего выбрать дополнительные метрики, с помощью которых можно будет оценивать успех в достижении поставленных целей. Зависимость выбора метрик от поставленных целей демонстрирует табл. 10.7, построенная на основе аналогичной таблицы из [101].
Таблица 10.7. Выбор метрик в соответствии с целью сопровождения | |||||||||||||||||
| |||||||||||||||||
* Для метрик, взятых из стандарта IEEE, в таблице приведены соответствующие номера |
Рассмотрим эти метрики более подробно.
(1) Частота отказов. Отказы — это дефекты, обнаруженные во время тестирования или в процессе эксплуатации приложения. Вычисляется как отношение количества найденных дефектов к величине NCSLOC. Последняя аббревиатура расшифровывается как «тысяч строк исходного кода не считая комментариев».
(30) Среднее время до отказа. Среднее время получения отказа после запуска приложения. Эта метрика требует введения определения отказа для тестируемого приложения. Определение зависит от того, что будет восприниматься потребителем как отказ. Отказом может считаться как аварийное завершение приложения, так и возникновение определенных конкретных проблем. Для финансового приложения как отказ может быть определена ошибка в вычислениях на величину не менее 1 доллара.
10.6.2. Применение метрик сопровождения.
В этом разделе обсуждаются вопросы применения метрик для управления действиями по сопровождению. Доля комментариев в общем числе строк исходного кода позволяет предсказать масштаб трудозатрат на сопровождение (рис. 10.15). По сравнению с тремя другими модулями модуль «Запись неудачных дней» создаст больше всего трудностей при сопровождении из-за большой доли некомментированных строк и своего большого объема. Сопровождать модуль «Отчет о прибылях» будет проще всего, потому что он имеет наименьшие размеры и высокую долю комментариев. Долю комментариев можно вычислить при помощи специальной программы или путем изучения взятых наугад участков кода.
 |
Рис. 10.15. Оценка трудозатрат на сопровождение |
Для управления затратами на сопровождение полезны графики, аналогичные приведенному на рис. 10.16. В соответствии с этим графиком большое количество запросов на исправления и усовершенствования прибывает в первые два года, в результате чего на второй год эксплуатации возникает пик задержек выполнения запросов. Постепенно задолженность устраняется. Общий вид кривых на этом графике достаточно типичен, изменяется только масштаб по оси времени (годы, месяцы, недели).
 |
Рис. 10.16. Профиль количества запросов на устранение недостатков |
Ранее в этой главе мы подчеркивали разницу между исправлением недостатков и усовершенствованием приложения. Обычно руководитель отдела сопровождения старается учитывать затраты на эти два вида деятельности отдельно друг от друга, чтобы усовершенствования оплачивались заказчиком. Для достижения эффективного распределения объема работ полезны графики, подобные рис. 10.17. На графике показано среднее количество недель ожидания решения по запросу на сопровождение. Время отсчитывается с момента поступления первого отчета. Для исправлений средний срок составляет около одной недели, а для усовершенствований — около четырех недель.
 |
Рис. 10.17. Пример профиля задержки до принятия решения о выполнении запроса |
10.6.3. Удобство сопровождения.
Оман [85] выделил основные параметры исходного кода, влияющие на удобство сопровождения приложения. Проведенное им разбиение исходного кода по типам показано на рис. 10.18. Автор изменил предложенное Оманом представление, чтобы сделать рисунок доступнее. Более полный вариант той же схемы приведен на рис. 10.19.
Например, чем лучше система разбита на модули, тем проще ее сопровождать (рис. 10.19, Исходный код ► Управляющая структура ► Система). Чем лучше данные инициализируются, тем проще их сопровождать (рис. 10.19, Исходный код ► Информационная структура ► Компонент). Читатель, несомненно, обратит внимание на то, что большинство перечисленных качеств уже рассматривались в этой книге с точки зрения качества проектирования и реализации.
Вспомните, что основным мотивом использования образцов проектирования является обеспечение удобства сопровождения приложений. Например, образец проектирования State позволяет с легкостью добавлять новые состояния, не изменяя функциональность имеющихся. К сожалению, усовершенствованные методы разработки систем обычно приводят к увеличению, а не к уменьшению затрат на сопровождение [23]. Судя по всему, это связано с тем, что хорошо разработанные приложения проще изменять, поэтому мы чаще прибегаем к их адаптации к новым условиям.
 |
Рис. 10.18. Влияние параметров исходного кода на удобство сопровождения (1) |
 |
Рис. 10.19. Влияние параметров исходного кода на удобство сопровождения (2) |
10.7. Подведение итогов.
Сопровождение обычно поглощает значительную долю бюджета, выделяемого на разработку программ. В свою очередь, большую долю работ по сопровождению составляет усовершенствование приложения, а не устранение неполадок. Основные идеи главы приведены ниже.
♦ Сопровождение программы — это то, что следует за поставкой.
♦ Самое важное — это анализ влияния вносимых в приложение изменений.
♦ Стандарт IEEE описывает этот процесс:.
♦ определение, входные данные, процесс, контроль, выходные данные, качество, метрика;.
♦ порядок стадий тот же, что и при разработке.
♦ Сложности, возникающие при управлении:.
♦ управление потоком запросов;.
♦ создание мотивации у персонала;.
♦ обеспечение актуальности всей документации.
♦ Метрика: построение графиков для исправлений и усовершенствований.
Многими идеями и ссылками автор обязан Беннетту [8] и Пигоски [89]. Рекомендуем читателю также обратиться к полезному труду Омана [84].
Упражнения.
Ответы и подсказки для упражнений, помеченных символами «о» или «п», приводятся в конце этой главы.
Вопросы для проверки.
П10.1". Дайте определение понятия «сопровождение программ» одним предложением.
П10.2°. Сопровождение бывает четырех видов, которые могут быть отнесены к двум категориям. Назовите их.
П10.3°. Приведите типичную последовательность обработки запросов на сопровождение. Решение вы найдете в разделе 10.2.
П10.4
. Предлагается изменить длину массива, используемого в некотором приложении, чтобы оно стало отвечать новым требованиям. Какие действия необходимо выполнить перед внесением изменений в код?.
П10.5°. Определите обратное проектирование одним абзацем. Решение находится в разделе 10.3.2.
П10.6
. Приведите два или три способа использования унаследованных приложений в новых программах.
П10.7
. Что подразумевается под реинжинирингом приложения ? Почему в этом может возникнуть необходимость?.
П10.8
. Перечислите пять-десять возможных проблем, связанных с сопровождением (см. раздел 10.5).
Общие упражнения.
ОЮ.1. Предлагается реализовать приведенное ниже требование к игре Встреча, которое ранее считалась необязательным.
Требование к персонажу игрока: [желательно[(«Внешний вид персонажа игрока») Игрок получает возможность выбирать изображение своего персонажа из четырех или более файлов формата GIF.
♦ К какому типу может быть отнесен этот запрос на сопровождение?.
♦ Выполните оценку влияния выполнения этого запроса.
010.2. Приведите примеры возможных корректирующих, адаптивных и упреждающих изменений для игры Встреча.
ОЮ.З. В каких случаях из перечисленных далее может потребоваться реинжиниринг? Объясните.
♦ Преобразование модели банковских операций в автоматизированную систему безопасности банка.
♦ Расширение модели банковских операций с учетом перемещений персонала службы безопасности.
♦ Изменение электронной сетевой системы обучения таким образом, чтобы она могла в любое время обрабатывать тесты с вариантами выбора, использование которых позволяло бы студентам оценить понимание изучаемого материала.
Упражнения в команде.
К10.1 (Сопровождение.).
1.
Получить спецификации от двух других команд того же класса. Предложить по крайней мере одно изменение каждого типа: исправление, адаптация, усовершенствование и упреждение.
2.
Другая команда должна выдвинуть аналогичные предложения к вашему проекту. Выполните оценку, влияния предложенных изменений на ваш проект.
3.
Обсудите предложенные изменения с выдвинувшей их командой на предмет доступных ресурсов. Реализуйте изменения.
4.
Реализуйте, протестируйте и оцените свои изменения.
Критерии оценки.
1.
Соответствие предложенных изменений указанному типу («Отлично» — точное соответствие).
2.
Полнота оценки влияния («Отлично» — раскрыты все возможные аспекты влияния).
3.
Качество тестирования изменений («Отлично» — все изменения тщательно протестированы).
Ответы.
П10.1. Сопровождение программы — это ее обслуживание после поставки заказчику.
П10.2. Исправление (коррекция и адаптация) и усовершенствование (улучшение и упреждение).
П10.4. Оценка влияния — выявление артефактов, которые будут затронуты предлагаемым изменением.
П10.6. Одна из возможностей — изменение унаследованного приложения и добавление нового кода. Вторая возможность — вызов унаследованного приложения напрямую из нового. Третья возможность — создание обертки для унаследованного приложения (снабжение его адекватным интерфейсом) и использование его функциональности в новом приложении через этот интерфейс.
П10.7. Реинжиниринг существующего приложения — это его перепроектирование, масштаб которого превосходит мелкие изменения, но не достигает уровня проектирования и реализации с нуля. Реинжиниринг рекомендуется применять в том случае, когда ожидаемое непрерывное изменение приложения приведет к ухудшению его как целого и к увеличению затрат на сопровождение.
Пример. Сопровождение игры Встреча.
В этом примере рассматривается обработка запросов на сопровождение для игры Встреча.
Запрос на сопровождение 4593.
(Содержимое настоящего документа описано в таблицах раздела 10.4.).
1. Определение задачи.
1.1.
Входные данные.
Руководитель отдела маркетинга Мэри Краус определила, что механизм изменения значений характеристик двух встречающихся персонажей слишком сложен для среднего любителя компьютерных игр.
1.2.
Процесс.
Работа по этому запросу будет включена в выпуск 4. Запрос был принят к исполнению руководителем проекта 12 января 2000 года. Инженер Алан Оуэне оценивает стоимость исправления в 12 человеко-часов (включая все необходимые тесты) при условии, что регрессионное тестирование для данного запроса будет объединено с регулярным регрессионным тестированием, которое проводится каждые две недели. Запросу установлен приоритет 4 (из 5, где 5 — низший возможный приоритет).
1.3.
Контроль.
Запрос был внесен в хранилище запросов инженером А. Джонсом 13 января 2000 года.
1.4.
Выходные данные.
13 января 2000 года инженер А. Джонс присвоил запросу номер 4593. Формулировка запроса такова.
Упростить формулу вычисления значений характеристик персонажей при их контакте друг с другом указанным ниже способом. Значения специфичных для зоны характеристик для более слабого персонажа уменьшаются вдвое. (Под специфичными для зоны характеристиками понимаются характеристики, относящиеся к зоне, в которой происходит контакт.) Значения характеристик более сильного персонажа не изменяются.
1.5.
Факторы качества.
Факторы качества — полнота и ясность запроса на сопровождение.
1.6. Метрики.
Запрос 4593 был оценен в процессе проверки службы сопровождения 22 января 2000 года и получил следующие баллы:.
♦ количество недочетов в запросе: 1;.
ясность запроса: 8 (0 — непонятен, 10 — невозможно сказать яснее);.
♦ перекрытие запроса: 0 (0 — не перекрывается с другими запросами, 10 — включен в один или несколько незавершенных запросов);.
♦ оценка задержки запроса: 12 дней.
[Примечание для студентов. Приведенные ниже сводные данные не следует повторять для каждого запроса.].
По всем незавершенным запросам получены следующие средние показатели:.
♦ среднее количество недочетов в запросе: 0,9 (групповой стандарт — 0,5);.
♦ средняя ясность запроса: 7,2 (групповой стандарт — 7);.
♦ среднее перекрытие запроса: 1,6 (групповой стандарт — 2,0);.
♦ средняя оценка задержки запроса: 18 дней (цель — 14).
2. Анализ задачи.
2.1.
Входные данные.
1.
Запрос на сопровождение 4593.
2.
SRS версии 4.6.5 со следующими сведениями:.
3.2.К0.3.1. Вступление в контакт с внешним персонажем [важно]. При встрече двух персонажей более сильным считается тот, у которого больше сумма значений характеристик, специфичных для зоны контакта. Система передает половину значения каждой характеристики, специфичной для зоны контакта, от более слабого персонажа к более сильному.
Предположим, что игрок встречается с внешним персонажем в зоне, где важны выносливость и сосредоточенность. Пусть р
— значение выносливости игрока, и т. д. Предположим, что р
+ р
> f
+ f
. Тогда р
= р
+ f
/2, р
= р
+ f
/2. f
= fa/2, f
= f
/2, где x — значение x после передачи характеристик.
Рассмотрим пример с конкретными числами. Если значение выносливости игрока равно 7, а сосредоточенности — 19, тогда как для Фредди (внешнего персонажа) выносливость равна 11, а сосредоточенность — 0,1, то игрок будет сильнее. В результате контакта характеристики персонажей получат следующие значения: Игрок: выносливость 7 + 11/2 = 12,5; сосредоточенность 19 + 0,1/2 = 19,05 (отображается как 19,1).
Фредди: выносливость 11/2 = 5,5; сосредоточенность 0, потому что 0,1/2 меньше 0,1.
2.2.
Процесс.
Возможность осуществления: данный запрос считается осуществимым, поскольку его влияние ограничено результатами контакта и жизнью игровых персонажей.
Подробный анализ: единственный класс, который может быть изменен при выполнении запроса, — это Контакт. Объект Контакт вычисляет конечные значения характеристик персонажей, встретившихся друг с другом. Значения атрибутов объектов персонажей во время выполнения будут другими, но их код не требует изменения.
В описании запроса приводится преобразование /
= /
/2, которое должно быть заменено на/
= /
/2, потому что значение делится пополам, а не заменяется половиной другого значения.
Уточнение документации: необходимо изменить одно требование в SRS. Другие требования остаются нетронутыми. Необходимо изменить руководство пользователя.
2.3.
Контроль.
Запрос обсуждался на собрании отдела сопровождения 3 апреля 1999 года и был классифицирован как запрос уровня 1 (технически простой).
Для регрессионного тестирования были выбраны сегменты, задокументированные под номерами 7829 и 8924. Они не требуют изменений, за исключением таблиц ожидаемых результатов.
[Примечание для студентов. Документация по тестированию в настоящем примере отсутствует.].
2.4.
Выходные данные.
Одно требование в SRS было изменено так, как показано ниже (удаленные слова перечеркиваются, добавленные — подчеркиваются).
3.2.К0.3.1. Вступление в контакт с внешним персонажем [важно]. При встрече двух персонажей более сильным считается тот, у которого больше сумма значений характеристик, специфичных для зоны контакта. Система передаст поло шшу значения каждой характеристики, специфичной длязоиы контакта, от более слабого персонажа к более сильному. Значения всех специфичных для зоны контакта характеристик более слабого персонажа уменьшаются вдвое.
Предположим, что игрок встречается с внешним персонажем в зоне, где важны выносливость и сосредоточенность. Пусть р
— значение выносливости игрока, и т. д. Предположим, что р
+р
> f
+f
. Тогда f £>=£„/3 ft
=l f
/2 I и f,.=[ i,J2 I. где x — значение x после передачи характеристик. Выражение I z I (операция округления вниз) означает наибольшее целое число. не превышающее z.
Рассмотрим пример с конкретными числами. Если значение выносливости игрока равно 7, а сосредоточенности — 19, тогда как для Фредди (внешнего персонажа) выносливость равна 11, а сосредоточенность — 0,1, то игрок в рассматриваемой зоне будет сильнее. В результате контакта характеристики персонажей получат следующие значения:.
Игрок: выносливость 7 + 11 /2 — 12,5; сосредоточенность 19 + 0,1/2 = 19,05 (отображается как Ю.Н.без изменений.
Фредди: выносливость Lll/2j = 5; сосредоточенность L1/2J = 0.
"В руководство пользователя необходимо внести следующие изменения... Vne приводятся).
План реализации: данный запрос будет реализован инженером Т. Файном. Поскольку запрос приведет к значительным изменениям в стиле игры, он будет реализован и протестирован отдельно от всех прочих запросов.
Существует некоторая неопределенность относительно того, как это изменение будет принято игроками, поэтому планируется проведение расширенного тестирования удобства и простоты использования.
2.5.
Факторы качества.
Принципиальным фактором качества является цельность анализа влияния.
2.6.
Метрики.
Количество часов на анализ влияния одного измененного или добавленного метода: 0,5.
Степень изолированности от других запросов: 6,5 (абсолютно не изолирован — 0, полностью изолирован — 10). Примечание: этот запрос устранил дефект «f
= /а/2» в первом требовании к контакту, в результате чего образовалось перекрытие с другим действием по сопровождению.
Ожидаемое время подтверждения задачи: 12 дней фактического времени.
Процент ошибок в документации: (еще не оценен).
Трудозатраты: 2 человеко-часа.
Фактическое время: 2 дня.
Процент ошибок: (еще не оценен).
В результате для полного набора незавершенных запросов получены следующие средние результаты.
♦ Среднее количество часов на анализ влияния одного измененного или добавленного метода: 0,9 (среднее по группе — 0,6).
♦ Средняя степень изолированности запросов друг от друга: 5,1 (групповой стандарт — 4,0).
3. Проектирование.
3.1.
Входные данные.
Запрос на сопровождение 4593.
3.2.
Процесс.
Требуется изменение SDD. Псевдокод функции executeO класса Контакт был изменен так, как показано ниже.
3.3.
Контроль.
Требуется инспектирование нового псевдокода. Дата инспектирования — 8 апреля 1999 года.
3.4.
Выходные данные.
Номер первой редакции SDD с этим запросом — 5.4.3.
Приведенный ниже псевдокод должен быть включен в измененный метод execute О класса Контакт.
Пусть asq[] - специфичные для зоны контакта характеристики. ПРИСВОИТЬ р сумму значений asq[] для игрока. ПРИСВОИТЬ f сумму значений asq[] для внешнего персонажа. ЕСЛИ р == f, контакт ничем не заканчивается. ЕСЛИ р > f.
Уменьшить значения asq[] внешнего персонажа вдвое и применить к ним операцию округления вниз. ИНАЧЕ ЕСЛИ f > р.
Уменьшить значения asq[] игрока вдвое и применить к ним операцию округления вниз.
План тестирования должен быть изменен следующим образом: ... В связи с важностью данного запроса отдел маркетинга назначил тест удобства и простоты использования за номером 8902. Этот тест призван определить реакцию пользователей на вычисления по новым формулам.
3.5.
Качество.
Важнее всего то, как изменение будет принято игроками. Кроме того, важно проведение регрессионного тестирования, гарантирующего отсутствие ошибок в расчетах, а также отсутствие отрицательного влияния нововведения на другие функции игры.
3.6.
Метрики.
Количество замен в псевдокоде: 1.
Процент ошибок в документации: подлежит оценке. Трудозатраты: 1 человеко-час. Фактическое время: 1 день. Процент ошибок: подлежит оценке.
4. Реализация.
4.1.
Входные данные.
SDD версии 5.4.2.
Исходный код версии 11.3.7.
4.2.
Процесс.
Кодирование изменений по данному запросу было выполнено Б. Марксом. Несистемное тестирование произвел А. Антонини.
4.3.
Контроль.
Планы реализации и модульного тестирования были проверены 30 января 2000 года командой 5.
4.4.
Выходные данные.
Первая версия исходного кода с внесенными изменениями — 11.3.8.
Отчет об инспектировании находится в архивах инспектирований и датирован 30 января 2000.
Отчеты о тестировании находятся в пакетах документации тестирования 7820, 7621 и 8902.
4.5.
Факторы качества.
Применялись факторы качества SQAP проекта Встреча.
4.6.
Метрики.
5. Системное тестирование.
5.1.
Входные данные.
SDD версии 5.4.2. SRS версии 4.6.5. Исходный код версии 11.3.8.
5.2.
Процесс.
Регрессионные тесты 7893.4, 23689.14, 21376.0 и 1237.46 пройдены. Новые регрессионные тесты, построенные для проверки новых расчетов, имеют номера 7893.5, 23689.15, 21376.1 и 1237.47 соответственно.
Перечисленные далее тесты будут проведены для версии 11.3.2:... Удобство и простота использования конечного продукта будет оценено при помощи приведенной ниже процедуры, которая будет выполнена три раза. Полная документация тестирования сохранена за номером 89041.0.
Из всего множества игроков будут случайным образом выбраны 100 человек, которые должны будут оценить текущую версию игры по десятибалльной шкале по следующим показателям: интерес, сложность, реалистичность и общее удовольствие.
После этого им будет предоставлена измененная версия вместе с новым руководством пользователя. Они будут играть в измененную игру 10-15 часов в течение недели, после чего должны будут выполнить ту же оценку, что и ранее.
Приведенная выше процедура должна быть повторена с другой выборкой, но в обратном порядке (сначала новая версия, потом старая).
Отчет о результатах тестирования на удобство и простоту использования должен быть предоставлен в форме процентных различий между значениями перечисленных показателей для старой и новой версий.
5.3.
Контроль.
См. SCMP.
5.4.
Выходные данные.
Результаты тестирования будут сохранены в STD за номером 890451.
5.5.
Факторы качества См. STD.
5.6. Метрики.
См. STD.
6. Приемосдаточное тестирование.
Выполнение запроса на сопровождение будет признано успешным, если для 400 потребителей будут получены следующие результаты.
1.
Пройдены все регрессионные тесты (см. выше).
2.
По всем категориям достигнуто увеличение показателей.
По меньшей мере в двух категориях теста на удобство и простоту использования получено увеличение на 25 %. Ни по какой категории результат не может быть более чем на 3 % хуже, чем до внесения изменений.