Документация по сопровождению программных средств.
Документация
по сопровождению ПС описывает
ПС с точки зрения ее разработки. Эта
документация необходима, если ПС
предполагает изучение того, как оно
устроена, и модернизацию его программ.
Сопровождение — это продолжающаяся
разработка. Поэтому в случае необходимости
модернизации ПС к этой работе привлекается
специальная команда разработчиков-сопроводителей.
Этой команде придется иметь дело с такой
же документацией, которая определяла
деятельность команды первоначальных
(основных) разработчиков ПС, — с той лишь
разницей, что эта документация для
команды разработчиков-сопроводителей
будет, как правило, чужой (она создавалась
другой командой). Команда
разработчиков-сопроводителей должна
будет изучать эту документацию, чтобы
понять строение и процесс разработки
модернизируемого ПС, и внести в эту
документацию необходимые изменения,
повторяя в значительной степени
технологические процессы, с помощью
которых создавалось первоначальное
ПС.
Документация
по сопровождению ПС можно разбить на
две группы:
(1)
документация, определяющая строение
программ и структур данных ПС и технологию
их разработки;
(2)
документацию, помогающую вносить
изменения в ПС.
Документация
первой группы содержит итоговые документы
каждого технологического этапа разработки
ПС. Она включает следующие документы:
-
Внешнее
описание ПС. -
Описание
архитектуры ПС, включая внешнюю
спецификацию каждой ее программы. -
Для
каждой программы ПС — описание ее
модульной структуры, включая внешнюю
спецификацию каждого включенного в
нее модуля. -
Для
каждого модуля — его спецификация и
описание его строения. -
Тексты
модулей на выбранном языке программирования. -
Документы
установления достоверности ПС,
описывающие, как устанавливалась
достоверность каждой программы ПС и
как информация об установлении
достоверности связывалась с требованиями
к ПС.
Документация
второй группы содержит
-
Руководство
по сопровождению ПС, которое описывает
известные проблемы вместе с ПС, описывает,
какие части системы являются аппаратно-
и программно-зависимыми, и как развитие
ПС принято в расчет в его строении
(конструкции).
Общая
проблема сопровождения ПС — обеспечить,
чтобы все его представления шли в ногу,
когда ПС изменяется. Чтобы этому помочь,
связи и зависимости между документами
и их частями должны быть зафиксированы
в базе данных управления конфигурацией.
Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.
Обсудим
обеспечение примитивов качества ПС,
выражающих критерии функциональности
и надежности ПС.
Обеспечение завершенности программного средства.
Завершенность
ПС является общим примитивом качества
ПС для выражения и функциональности и
надежности ПС.
Функциональность
ПС определяется его функциональной
спецификацией. Завершенность ПС как
примитив его качества является мерой
того, насколько эта спецификация
реализована в данном ПС. Обеспечение
этого примитива в полном объеме означает
реализацию каждой из функций, определенной
в функциональной спецификации, со всеми
указанными там деталями и особенностями.
Однако
в спецификации качества ПС могут быть
определены несколько уровней реализации
функциональности ПС: может быть определена
некоторая упрощенная (начальная или
стартовая) версия, которая должна быть
реализована в первую очередь, могут
быть также определены и несколько
промежуточных версий. В этом случае
возникает дополнительная технологическая
задача: организация наращивания
функциональности ПС. Упрощенная версия
требуемого ПС должна быть рассчитана
на практически полезное применение
любыми пользователями, для которых оно
предназначено. Поэтому главный принцип
обеспечении функциональности такого
ПС заключается в том, чтобы с самого
начала разрабатывать ПС таким образом,
как будто требуется ПС в полном объеме,
до тех пор, пока разработчики не будут
иметь дело с теми частями или деталями
ПС, реализацию которых можно отложить
в соответствии со спецификацией его
качества. Тем самым, и внешнее описание
и описание архитектуры ПС должно быть
разработано в полном объеме. Можно
отложить лишь реализацию тех программных
подсистем, определенных в архитектуре
разрабатываемого ПС, функционирования
которых не требуется в начальной версии
этого ПС.
Выполнение проекта внедрения программной системы сродни цветочно-конфетному периоду ухаживания, а сдача в промышленную эксплуатацию как урегулирование взаимных обязательств почти «свадьба» исполнителя и заказчика. Однако как женихи и невесты зачастую не задумываются, что будет после этого волнующего момента, так и партнеры считают, что дальше будут жить долго и счастливо. Однако очевидно, что без совместных усилий, подкрепленных взаимным уважением и профессионализмом, счастливой жизни не получится.
Определение процесса сопровождения
Под сопровождением программного обеспечения понимают процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию. К счастью, этот процесс достаточно хорошо стандартизован, и открывать Америку для того, чтобы его разработать и внедрить не придется. Упомянем только некоторые основные стандарты:
- ISO/IEC 14764 (2006, русский перевод стандарта 1999 г. — 2002 г.);
- ISO/IEC 12207 (2008, русский перевод стандарта 2010г.);
- ISO 20000;
- SWEBOK (2004 г.);
- ITIL v3 (2007 г, обновление — 2011 г.);
- COBIT v5 (2012 г.).
Процесс сопровождения является одной из фаз жизненного цикла программного обеспечения, следующей за передачей ПО в эксплуатацию, и завершается выводом его из эксплуатации. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, для добавления новой функциональности, повышения удобства использования (юзабилити) и роста уровня использования ПО. По стандарту ISO/IEC 12207, этот процесс входит в 5 основных процессов жизненного цикла (ЖЦ) ПО: приобретение, поставка, разработка, эксплуатация, сопровождение.
В общем случае процесс сопровождения состоит из следующих задач:
- устранение сбоев;
- улучшение дизайна;
- расширение функциональных возможностей;
- создание интерфейсов взаимодействия с другими (внешними) системами;
- адаптация (например, портирование) для возможности работы на другой (или обновленной) аппаратной платформе, применение новых системных возможностей, функционирование в среде обновленной телекоммуникационной инфраструктуры и т.п.;
- миграция унаследованного (legacy) программного обеспечения; вывод программного обеспечения из эксплуатации.
Сопровождение и удовлетворенность пользователей
Именно процесс сопровождения позволяет улучшить удовлетворенность пользователей внедренным ПО. Действительно, общеизвестно, что удовлетворенность пользователей зависит от того, насколько полученный результат соответствует их ожиданиям (т.е. от площади области пересечения ожиданий и результата — см. рисунок 1).
Рис. 1. Область удовлетворенности пользователей.
По неоднократным опросам пользователей, они ждут от нового ПО, разработанного и внедренного, в частности, на платформе «1С:Предприятие» следующего:
- эффективного решения стоящих перед ними задач;
- удобного и интуитивно понятного интерфейса;
- помощи по всем возникающим вопросам использования ПО;
- выполнения их заявок в требуемые сроки.
Все эти задачи можно и нужно выполнять на этапе сопровождения. Кроме того, присущий человечеству консерватизм определяет негативное отношение большинства пользователей к новому ПО. Именно и только стадия сопровождения позволяет примирить с ним пользователей и приучить их с удовольствием и с пользой применять его в своей деятельности. По статистике, удовлетворенность пользователей через год использования ПО в несколько раз выше, чем сразу после внедрения.
Но, чтобы достичь таких результатов, сопровождение должно осуществляться на должном уровне. Ведь в противном случае эту удовлетворенность можно даже уменьшить.
Типы заявок предложений о модификации
Процесс сопровождения состоит из обработки заявок пользователей. Эти заявки целесообразно классифицировать по типам (см. рис. 2).
Рис. 2. Иерархия типов предложения по модификации ПО (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)
Так, тип сопровождения — корректирующее — это реактивное изменение программного продукта для коррекции обнаруженных проблем (после обнаружения). Проблемы могут относиться к функциональности системы, ее интерфейсам, надежности и производительности работы.
Адаптивное сопровождение — изменение программного продукта после поставки для обеспечения его использования в условиях изменения его (программного продукта) или окружающей среды.
Полное (совершенствующее) сопровождение — изменение программного продукта после поставки для улучшения производительности или удобства эксплуатации.
Профилактическое сопровождение — это изменение программного продукта после поставки для выявления и исправления скрытых дефектов в ПО до того, как они станут явными ошибками.
Следует также отметить, что профилактическое и полное (совершенствующее) сопровождение относятся к проактивному подходу к сопровождению, при котором инициатива исходит от обслуживающего персонала, а корректирующее и адаптивное — к реактивному подходу, инициатива которого находится у пользователей.
Проактивному сопровождению необходимо уделять достаточно внимания, поскольку именно оно в наибольшей степени способствует повышению удовлетворенности пользователей и эффективному развитию программной системы.
Этапы процесса сопровождения
Этапы процесса сопровождения основаны на цикле Деминга PDCA (Plan — Do — Check — Analyze) или «планируй — делай — проверяй — анализируй» (см. рис. 3).
Рис. 3. Общая структура процесса сопровождения (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)
Формирование процесса сопровождения начинается с разработки концепции сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 (Standard for Software Engineering — Software Maintenance), должен содержать следующие разделы:
1. Область сопровождения программного средства.
1.1. Типы выполняемого сопровождения.
1.2. Сопровождаемый уровень документов.
1.3. Реакция (чувствительность) на сопровождение
(определение ожиданий к сопровождению заказчика).
1.4. Обеспечиваемый уровень обучения персонала.
1.5. Обеспечение поставки продукта.
1.6. Организация справочной службы («горячей линии»).
2. Практическое применение (адаптация) данного процесса.
3. Определение организаций (лиц), ответственных за сопровождение.
4. Оценка стоимости сопровождения:
4.1. Проезд до места расположения пользователя.
4.2. Обучение как сопроводителей, так и пользователей.
4.3. СПИ (среда программной инженерии) и СТПС (среда тестирования программного средства) и их ежегодное сопровождение.
4.4. Персонал (зарплата и премии).
Должен быть сформирован соответствующий план сопровождения. Этот план должен подготавливаться одновременно с разработкой программной системы. План должен определять, как пользователи будут размещать свои запросы на модификацию (изменения) или сообщать об ошибках, сбоях и проблемах.
Стандарт ГОСТ Р ИСО/МЭК 14764-2002 предлагает следующий состав такого плана:
a). Введение:
- описание сопровождаемой системы;
- определение исходных состояний программного средства;
- описание уровня требуемой поддержки;
- определение организаций, осуществляющих сопровождение;
- описание любых условий (протоколов), согласованных между заказчиком и поставщиками;
b). Концепция сопровождения (уже кратко описанная выше):
- описание концепции;
- описание уровня поддержки системы;
- установление периода поддержки;
- адаптация (практическое применение) процесса сопровождения;
c). Организационные работы и работы по сопровождению:
1. роли и обязанности сопроводителя до поставки программного продукта:
- реализация процесса;
- определение инфраструктуры процесса;
- установление процесса обучения;
- установление процесса сопровождения;
2. роли и обязанности сопроводителя после поставки программного продукта:
- реализация процесса;
- анализы проблем и модификаций (изменений);
- реализация (внесение) модификаций (изменений);
- рассмотрение и принятие модификаций (изменений);
- перенос программного средства в новую среду;
- снятие программного средства с эксплуатации;
- решение проблем (включая справочную службу);
- при необходимости — обучение персонала (сопроводителя и пользователя);
- усовершенствование процесса;
3. роль пользователя:
- приемочные испытания;
- взаимосвязи (интерфейсы) с другими организациями;
d). Ресурсы:
1. персонал:
- состав персонала для конкретного проекта; Структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающуюся бюджетирования, финансового менеджмента и управления человеческими ресурсами в области сопровождения.
2. программные средства:
- определение программных средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);
3. технические средства:
- определение технических средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);
4. оборудование (аппаратура):
- определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);
5. документы:
- план обеспечения качества;
- план управления проектом;
- план управления конфигурацией;
- документы разработки;
- руководства по сопровождению;
- план проведения верификации;
- план проведения аттестации (валидации);
- план тестирования, процедуры тестирования и отчеты о тестировании;
- план обучения;
- руководство (а) пользователя;
6. данные;
7. другие требования к ресурсам (при необходимости);
e). Процесс (как должна быть выполнена конкретная деятельность):
1. процесс, выполняемый сопроводителем (приводят общее описание процесса без детализации в плане сопровождения всего процесса);
2. процесс адаптации (практического применения сопровождения к условиям проекта);
f). Обучение:
1. определение уровня обучения, необходимого для сопроводителя и пользователей;
g). Протоколы и отчеты по сопровождению:
1. перечень запросов пользователя на оказание услуг по сопровождению, предложение о модификациях или отчеты о проблемах;
2. состояния запросов (предложений, отчетов) по категориям;
3. приоритеты запросов (предложений, отчетов);
4. контрольные данные, собранные при работах по сопровождению.
Связь сопровождения с эволюцией ПО
Отдельно хочется коснуться связи сопровождения с эволюцией программных систем. В 1969 году Мэнни М. Леман впервые связал деятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты более чем 20-ти летних исследований группы, которой он руководил, привели к формулированию ряда важных положений.
Ключевой результат: деятельность по сопровождению, по сути, представляет собой эволюционную разработку программных систем. Принятию тех или иных решений в процессе сопровождения, помогает понимание того, что происходит с программной системой в процессе ее эксплуатации.
Существующее (особенно корпоративное) программное обеспечение никогда не бывает полностью завершенным и продолжает эволюционировать в течение всего срока эксплуатации. В процессе эволюционирования программная система становится все более сложной до тех пор, пока не прикладываются специальные усилия (в том числе, в рамках специального проекта по модификации) по уменьшению ее сложности.
Леман вместе с Белади (Lehman and Belady) выделили 3 типа программ.
- Программы S-типа, требования к которым могут быть формализованы.
- Программы P-типа, которые развиваются итеративно.
- Программы E-типа, которые влияют на окружающую среду. Поэтому их нельзя рассматривать изолированно от нее.
На основании этой классификации для программных систем Е-типа постепенно Леманом были сформулированы законы эволюции:
- (1974) Непрерывное изменение — системы E-типа должны непрерывно адаптироваться или они будут все менее удовлетворять потребностям компании.
- (1974) Увеличение сложности — по мере развития систем E-типа их сложность будет возрастать, если не поддерживать их и не уменьшать сложность.
- (1974) Саморегулирование — процесс эволюции систем E-типа саморегулируем, распространение продукта близко к нормальному закону.
- (1978) Сохранение организационной стабильности — средняя скорость развития систем E-типа инвариантна относительного жизненного типа программного продукта.
- (1978) Сохранение осведомленности — поскольку системы E-типа вовлечены во все с ними связанное: разработчиков, продавцов, пользователей, то для достижения полезного развития необходимо поддерживать знание их содержания и поведения различными группами пользователей. Избыточное развитие ухудшает владение системой.
- (1991) Непрерывное развитие — функциональное содержание систем E-типа должно непрерывно расширяться, чтобы обеспечить удовлетворенность пользователей на период жизненного цикла системы.
- (1996) Ухудшение качества — качество систем E-типа будет ухудшаться, если они не будут тщательно сопровождаться и адаптироваться под изменения операционной среды.
- (1996) Система обратной связи (впервые — 1974, формализовано — 1996) — процессы эволюции систем E-типа представляют собой системы многоуровневой, многоконтурной и охватывающей многих сотрудников обратной связи и должны быть такими, чтобы достигнуть существенных улучшений разумными средствами.
Сопровождение выгодно всем
В заключение необходимо отметить, что процесс сопровождения ПО важен для всех заинтересованных сторон. Он предоставляет:
Заказчику
- возможность получить возврат инвестиций на затраты на проект;
- средство ведения бизнеса — необходимый компонент деятельности;
- возможность развиваться.
Внедренцу — возможность:
- продолжения взаимодействия с заказчиком;
- укрепить контакты;
- развиваться;
- сделать работу над ошибками;
- исправить ошибки.
Вендору
- возможность эффективно развивать продукт и оперативно исправлять ошибки;
- возможность повысить удовлетворенность партнеров и клиентов.
Тем, кто этого еще не сделал, необходимо обратить свое внимание на процесс сопровождения программного обеспечения.
Сопровождение программных продуктов и баз данных – процесс, который не определен законом, но он все равно встречается в официальной документации. За счет этого в мире сложилось общее понимание предстоящей операции. Сюда можно отнести обучение клиентов основам работы с программным обеспечением, а также консультирование, настройку и адаптацию контента в пользовательской среде, поддержку работоспособности, исправление неполадок и возникающих ошибок. При необходимости – обновление и модификацию.
Сопровождение контента не имеет четко обозначенных границ, поэтому соответствующее понятие является весьма широким. Определяется непосредственными сторонами-участниками. Далее техническая поддержка программных продуктов будет рассмотрена более подробно.
Определение понятия
Рассматриваемое понятие – процедура улучшения, устранения дефектов и оптимизации программных продуктов. Осуществляется после того, как софт передан на реализацию. Является одной из фаз жизненного цикла ПО. Она идет после передачи контента в эксплуатацию.
Наблюдение за работоспособностью программного средства в России имеет собственный стандарт. Есть международные принципы использования соответствующей операции. Эта документация помогает лучше понять, как реализовывать процесс.
О границах использования
Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:
- Сопровождение автоматизированных информационных систем ничем не отличается от аналогичной операции относительно другого софта.
- Сопровождение ПО не предусматривает техническую поддержку АИС. Связано это с небольшой разницей при реализации.
ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.
Некоторые полагают, что сопровождение и поддержка – одинаковые понятия. Такая точка зрения весьма распространена. Но есть и те, кто уверяют в обратном. Под поддержкой понимают обслуживание непосредственными сотрудниками той компании, которая использует контент в работе. Такие специалисты имеют меньшую квалификацию, нежели сопроводители.
Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.
Структура
Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:
- для устранения обнаруженных ошибок;
- при модификации в соответствии с потребительскими нуждами.
В структуре технической поддержки программного обеспечения выделяют несколько линий. Они помогают понять, чем будет заниматься соответствующий специалист.
Чтобы лучше разобраться в теме, необходимо рассмотреть наглядную структуру процесса. За основу взят внешний контент:
- Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
- Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
- Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
- Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.
Работа инженера иногда сравнивается с информационными центрами. Функционал у соответствующих «специалистов» сильно отличается. Колл-центр собирает обращения, а сопроводитель – это ключевое звено технического обслуживания и доработки. Он будет решать проблемы, связанные с эксплуатацией программных продуктов и сервисов.
Виды
Техподдержка бывает разной. Она включает в себя базовый и расширенный типы. В первую категорию включены следующие операции:
- обучение азам работы с программами и приложениями;
- помощь в освоении имеющихся продуктов;
- обслуживание путем диспетчерской связи;
- настройка, адаптация, отладка экземпляров программ с учетом особенностей пользовательского окружения;
- поддержка работоспособности;
- профилактика сбоев, неполадок;
- устранение ошибок (включая критические);
- мониторинг за процессом работы софта.
Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.
Расширенный тип предусматривает:
- модификации эталонных сервисов и баз данных для развития и встраивания обновлений;
- совершенствование для отладки работоспособности итогового контента.
Остальные задачи обсуждаются индивидуально.
Этапы
Рассматриваемая операция обычно включает в себя несколько этапов:
- Подготовка к необходимым исследованиям и действиям.
- Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
- Внесение изменений.
- Проверка и приемка контента.
В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.
Как быстро освоить направление
Поддержка программного обеспечения – процесс, который сможет освоить любой IT-специалист. Особенно, если он занимается системным администрированием и разработкой.
Чтобы быстрее освоить направление, в Москве и других регионах России рекомендуется закончить специализированные компьютерные курсы. В срок до 12 месяцев пользователя научит инновационным профессиям с нуля. В конце будет выдан сертификат, подтверждающий знания и умения в соответствующей области.
Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!
Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.
Документация на программное обеспечение — это документы, сопровождающие некоторое программное обеспечение (ПО) — программу или программный продукт. Эти документы описывают то, как работает программа и/или то, как её использовать.
Документирование — это важная часть в разработке программного обеспечения, но часто ей уделяется недостаточно внимания.
Типы документации
Существует четыре основных типа документации на ПО:
- архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО
- техническая — документация на код, алгоритмы, интерфейсы, API
- пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала
- маркетинговая
Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так?» Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи, как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.
Техническая документация
Это именно то, что подразумевают под термином документация большинство программистов. При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст, описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технических характер и в основном используется для определения и описания API, структур данных и алгоритмов.
Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.
Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том, как он работает, пользовательская документация описывает лишь то, как использовать программу.
В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.
Существует три подхода к организации пользовательской документации. Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем подходе, команды или задачи организованы в виде алфавитного справочника — часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей.
Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи (англ. online help), содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.
Маркетинговая документация
Для многих приложений необходимо располагать рядом рекламных материалов, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:
- подогреть интерес к продукту у потенциальных пользователей
- информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем что они получат
- объяснить положение продукта по сравнению с конкурирующими решениями
Одна из хороших маркетинговых практик — предоставление слогана — простой запоминающейся фразы, иллюстрирующей то что мы хотим донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают более ясную картину о возможностях и способах использования программы, чем всё остальное.
Документирование программного обеспечения
Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы: что должно быть сделано, кроме собственно программы? что и как должно быть оформлено в виде документации? что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом? Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование? Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.
Качество программного обеспечения, наряду с другими факторами, определяется полнотой и качеством пакета документов, сопровождающих ПО. К программным документам относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения программ и эксплуатации.
Техническое задание
Техническое задание. Требование к содержанию и оформлению. Напомним, что техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы.
Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта программного средства.
- Техническое задание на разработку ПО должно включать следующие разделы: введение; основания для разработки;
- назначение разработки;
- требования к программе;
- требования к программной документации;
- технико-экономические показатели;
- стадии и этапы разработки;
- порядок контроля и приемки;
- приложения.
В зависимости от особенностей разрабатываемого ПО стандарт допускает уточнение содержания разделов, введение новых разделов или их объединение.
Руководство пользователя
Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации программного пакета. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке программного пакета. Ее целью является предоставление потенциальным покупателям первичных сведений о программном пакете.
Пользовательская документация программного средства объясняет пользователям, как они должны действовать, чтобы применить данную программу. Она необходима, если программа предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми руководствуется пользователь при установке программы с соответствующей настройкой на среду применения, при применении программы для решения своих задач и при управлении программой (например, когда данное программное средство взаимодействует с другими системами). Эти документы частично затрагивают вопросы сопровождения программного средства, но не касаются вопросов, связанных с модификацией программ.
В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программы (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые оно ориентировано, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей, у которого есть необходимость в определенной пользовательской документации. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения программного средства (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
Можно считать типичным следующий состав пользовательской документации для достаточно больших программных средств:
- Общее функциональное описание программного средства. Дает краткую характеристику функциональных возможностей программного средства.
- Предназначено для пользователей, которые должны решить, насколько необходимо им данное программного средства.
Руководство по инсталляции программного средства
Предназначено для системных администраторов. Он должен детально предписывать, как устанавливать системы в конкретной среде. Он должен содержать описание машинно-считываемого носителя, на котором поставляется программное средство, файлы, представляющие программное средство, и требования к минимальной конфигурации аппаратуры.
Инструкция по применению программного средства
Предназначена для ординарных пользователей. Содержит необходимую информацию по применению программного средства, организованную в форме удобной для ее изучения.
Справочник по применению программного средства
Предназначен для ординарных пользователей. Содержит необходимую информацию по применению программного средства, организованную в форме удобной для избирательного поиска отдельных деталей.
Руководство по управлению программным средством
Предназначено для системных администраторов. Оно должно описывать сообщения, генерируемые, когда программные средства взаимодействует с другими системами, и как реагировать на эти сообщения. Кроме того, если программное средство использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.
Разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех программы. Она должна быть достаточно проста и удобна для пользователя (в противном случае это программное средство, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками программного средства, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользовательской документации разработан ряд стандартов, в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание.
Руководство программиста
Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.
Эта документация необходима, если программное средство предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение — это продолжающаяся разработка. Поэтому в случае необходимости модернизации программного средства к этой работе привлекается специальная команда разработчиков- сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков программного средства, — с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Команда разработчиков- сопроводителей должна будет изучать эту документацию, чтобы понять строение и процесс разработки модернизируемого программного средства, и внести в эту документацию необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное программное средство.
Документация по сопровождению программного средства можно разбить на две группы:
1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в программное средство.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки программного средства. Она включает следующие документы:
- Внешнее описание программного средства (Requirements document).
- Описание архитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.
- Для каждой программы программного средства — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
- Для каждого модуля — его спецификация и описание его строения (design description).
- Тексты модулей на выбранном языке программирования (program source code listings).
- Документы установления достоверности программного средства (validation documents), описывающие, как устанавливалась достоверность каждой программы программного средства и как информация об установлении достоверности связывалась с требованиями к программному средству.
Документы установления достоверности включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки программного средства, например, доказательства свойств программ.
Документация второй группы содержит
- Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программно- зависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).
- Общая проблема сопровождения программного средства — обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда программное средство изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы в базе данных управления конфигурацией.
Процесс управления конфигурацией
Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния (базовой линии) программных объектов в системе, управления их изменениями и выпуском.
Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.
- Подготовка процесса управления конфигурацией — разработка плана управления конфигурацией. Тип выходного результата задачи — план.
- Определение конфигурации — Определение схемы обозначения программных объектов и их версий (объектов программной конфигурации) и документации, в которой фиксируется состояние их конфигурации. Тип выходного результата задачи — описание.
- Контроль конфигурации — Регистрация заявок на внесение изменений; анализ и оценка изменений; принятие или непринятие заявки; реализация, верификация и выпуск измененного программного объекта; обеспечение аудиторских проверок изменений.
- Учет состояний конфигурации — Подготовка протоколов управления конфигурацией и отчетов о состоянии контролируемых программных объектов. Тип выходного результата задачи — протокол, отчет.
- Оценка конфигурации — Определение и обеспечение функциональной законченности и физической завершенности программных объектов. Тип выходного результата задачи — протокол, отчет.
- Управление выпуском и поставка — Контроль выпуска и поставки программных продуктов и документации.
Источник:
Положение темы настоящей главы в контексте разработки программного обеспечения иллюстрирует рис. 10.1.
♦ Разделы 10.1-10.7.
♦ Упражнения.
Вопросы, которые рассматриваются в этой главе.
♦ Понимание определения сопровождения программ.
♦ Правильная оценка затрат на сопровождение.
♦ Понимание вопросов сопровождения программ.
♦ Организация сопровождения.
♦ Использование стандарта сопровождения 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 % хуже, чем до внесения изменений.