Методические указания по выполнению практических работ по профессиональному модулю
жүктеу/скачать 5.65 Mb.
|
| Таблица 1. Оценка стоимости выполнения запроса на сопровождение
Если бы мы имели дело с одним конкретным изменением, проблемы были бы еще не так велики. Обычно организации сталкиваются с непрерывным потоком запросов на сопровождение. Большое количество изменений позволяет снизить стоимость каждого из них, но поток запросов создает повышенные требования к системе обработки. Усилия программистов, тестеров и разработчиков документации нужно координировать. Например, нужно ли обновлять SRS после обнаружения ошибки, после ее устранения, после тщательного тестирования или же, наконец, после объединения данного исправления с другими операциями, выполненными в рамках работ по сопровождению? В любом случае согласованность документации и исходного кода будет время от времени нарушаться. Без внимательного руководства эти кратковременные, казалось бы, несоответствия начнут размножаться, в результате чего документация перестанет соответствовать реальным функциям приложения, и никто не будет знать, что же на самом деле творится с приложением. Суть в том, чтобы сделать изменения понятными и даже элегантными. Элегантность хорошо иллюстрирует следующий пример: можно увеличить полезное пространство в доме, пристроив к нему сарай, а можно сохранить цельность здания, увеличив его объем искусными архитектурными приемами. Пристройка может ухудшить внешний вид и структуру всего здания, а хороший архитектор всегда постарается этого избежать. Тестирование — еще одна важная техническая проблема. Даже сосредоточенное тестирование измененных или добавленных компонентов отнимает достаточно времени, потому что для этого часто приходится разрабатывать специальные планы. Но сосредоточенного тестирования недостаточно, потому что возможность распространения «ряби», вызванной изменениями, требует проведения регрессионного тестирования, которое могло бы исключить ухудшение имевшейся функциональности приложения. Затраты на тестирование составляют значительную долю общих затрат на сопровождение программы. Блок-схема организации процесса сопровождения согласно приведена на рисунке 1. Пункты la-id фактически относятся к этапу разработки. «Разработка с учетом сопровождения» подразумевает попытку предугадать, в каких направлениях будут развиваться требования к продукту, и учесть это в плане. С этой целью часто применяются, например, образцы проектирования. «Удобство поддержки» в пункте б означает возможность эффективного сопровождения. Для этого в код должны включаться подробные комментарии. Персонал, занимающийся сопровождением, имеет обычно не столь специализированные знания, как разработчики, потому что сопровождение требует работы с гораздо большим объемом кода. Тем не менее служба сопровождения должна быть способна после внимательного изучения кода прийти к пониманию смысла каждой инструкции. Только после этого допустимо внесение изменений. Удобство поддержки гарантируется постоянным уровнем качества кода. Пункт 2 состоит в принятии решения о масштабах затрат на сопровождение: главным образом речь идет о том, следует ли относить усовершенствования к работам по сопровождению. Согласно пункту 3, предстоит выбрать, своими или наемными силами выполнять работы по сопровождению. Заключение контракта на сопровождение программы обладает преимуществами конкурентоспособной цены и дает возможность владельцу приложения сосредоточиться на других задачах. Недостаток в том, что сотрудники постепенно теряют контроль над кодом приложения. Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60-80 % работ обычно относится к усовершенствованию приложения, а не к исправлению его недостатков (рисунок 2). Рисунок 1. Схема организации процесса сопровождения Рисунок 2. Виды работ по сопровождению Приспособление, или адаптация (adaptive maintenance), относится к исправлению недостатков, потому что функциональность приложения в результате не изменяется и никакого усовершенствования не происходит. Запрос на сопровождение 78 При изменении игроком значения одной из характеристик сумма всех значений должна сохраняться, но этого не происходит. Например, если характеристики имеют следующие значения: сила = 10, терпение = 0,8, выносливость = 0,8 (сумма = 11,6), и игрок устанавливает силу равной 11, в результате его характеристики получают значения: сила = 11, терпение = 0 и выносливость = 0. Теперь займемся запросом на сопровождение с улучшением (perfective maintenance). Предположим, что отдел маркетинга решил сделать игру более привлекательной, основываясь на том, что пользователи должны получать максимально ощутимую награду за свой уровень. Предлагается, чтобы при переходе игрока на следующий уровень облик игры в целом становился более качественным. Отдел оформления предоставит необходимые рисунки, а отдел сопровождения должен внести изменения, отражающие новые требования. Запрос 162 будет обсуждаться далее в тексте лекции. Запрос на сопровождение 162 Измените игру Встреча так, чтобы она начиналась с отображения зон и их соединений в согласованном стиле. Когда игрок достигает второго уровня, все зоны и их соединения отображаются в усовершенствованном согласованном стиле, который доступен только для уровня 2, и т. п. Отдел оформления обеспечит необходимые изображения. Рисунок 3. Влияние дефекта на сопровождение Последовательность обработки запросов на сопровождение состоит из анализа, проектирования и реализации, точно так же, как и обычная разработка. Существенным отличием является необходимость анализа влияния изменений на артефакты. Согласно исследованию Вейсса, 19 % дефектов в приложениях образуются на этапе определения требований, 52 % — на этапе проектирования и 7 % — в процессе программирования. Влияние устранения дефекта на артефакты иллюстрирует рисунке 3. В случае минимального влияния изменения вносятся в один-единственный артефакт. Это происходит, например, при нарушении программистом стандарта именования локальных переменных или при удалении неиспользованной переменной из программы. Напротив, в худшем случае изменения распространяются на все этапы процесса. Даже для дефекта, возникшего на уровне кода (то есть дефекта, связанного лишь с неправильным кодированием), степень влияния может быть как малой, так и весьма значительной. Кажущееся простым изменение, например увеличение размера статического массива в C++, может вызвать сильную «рябь» по всему приложению. Запрос 162, приведенный ранее, влияет на все аспекты процесса, показанного на рисунке 4. Если приложение разрабатывается так, чтобы его можно было прослеживать, то документировать действия по сопровождению может быть относительно несложно. В противном случае последствия могут быть крайне дорогостоящими. Рисунок 4. Влияние дефекта на сопровождение История сопровождаемого программного продукта может быть очень непростой. Многие существующие приложения часто оказываются, снабжены скудной или противоречивой документацией. Первым шагом в организации рациональных работ по сопровождению таких приложений должно быть создание подробной согласованной документации. Для этого часто требуется восстановление архитектуры по исходному коду — обратное проектирование (reverse engineering). Существует несколько программных средств, помогающих выполнить эту задачу. Например, пакеты Rational Rose (Rational Corporation) и Together (Object International) позволяют создавать модели объектов из исходного кода на C++ и Java. Получающиеся в результате диаграммы можно использовать для анализа хода мыслей разработчика. Из-за неоднозначности трактовки диаграмм на UML и механичности процесса обращения обратное проектирование не позволяет полностью понять намерения разработчика. Когда разработчик рисует прямоугольники и связи UML, их геометрическое размещение (например, группировка) несет смысловую нагрузку, воспринимаемую только людьми. Обратное проектирование является более общим средством, чем преобразование кода в проект, поскольку представляет собой процесс восстановления содержания какого-то этапа по артефактам последующего этапа. Получение намерений из структуры возможно не всегда. Отсылаем читателя к недокументированному коду в разделе 1.5.1. Из-за отсутствия комментариев сделать выводы о назначении кода просто невозможно. Действия по сопровождению включают в себя гораздо больше, нежели просто технические изменения и дополнения. Для отражения каждого такого действия требуется обновление всей цепочки документации. Например, исправление, вызванное дефектом в требованиях, приводит к изменению документации, содержащей требования к продукту, а также, вероятно, проектной документации и обязательно — документации на реализацию и тестирование. Кроме того, необходимо изменение состояния системы управления конфигурациями для отражения новой версии продукта. Для больших программ, в работе над которыми случалось принимать участие автору, устранение дефектов часто занимало меньше времени, чем обновление документации. Но если игнорировать необходимость обновления, то документация потеряет согласованность, из-за чего стоимость сопровождения начнет возрастать и в конце концов окажется просто неприемлемой. Стандарт IEEE 1219-1992 определяет процесс сопровождения программного обеспечения. Семь стадий процесса, описанные в этом стандарте, приблизительно соответствуют стадиям процесса разработки. Каждая стадия характеризуется шестью атрибутами (рис. 5). Значения этих атрибутов для каждой из семи стадий процесса сопровождения приведены в табл. 2 и табл. 3. Содержание стандарта IEEE 1219-1992 приводится ниже. жүктеу/скачать 5.65 Mb. Достарыңызбен бөлісу:
|