| СТАТЬЯ |
26.06.03
|
© Сергей Трофимов
© Статья была опубликована в журнале РСWeek/RE №12 (378), 2003
Я не открою Америку, если скажу, что сопровождение программ — это трудоемкий и длительный процесс. Для программистов он означает копание в чужом, плохо структурированном коде, латание “дыр” и постепенное отставание от современных технологий. Для руководителей — это постоянная головная боль от звонков пользователей, напоминание об ошибках, требовавших исправления еще в прошлой версии, трудности с оценкой текущего состояния дел и прогнозом на будущее.
Сопровождение отнимает значительные ресурсы компаний, которые можно было бы использовать более эффективно. Лучшие разработчики, знающие программную систему как свои пять пальцев, тратят массу времени на консультирование пользователей и разбор замечаний, причем часто одних и тех же.
Настройка соединения с базой данных
Термин сопровождение ПО определяется IEEE как “процесс модификации программной системы или ее компонентов, проводимый после поставки системы заказчику с целью устранения отказов, повышения производительности или улучшения других характеристик системы или адаптации к изменившемуся программному окружению”*.
Выделяют следующие направления сопровождения**:
Корректирующее сопровождение— это исправление ошибок, выявленных при тестировании или эксплуатации. Пользователи ожидают от разработчиков оперативного исправления найденных в процессе работы “жучков” и бывают очень недовольны, если их замечания теряются. Поэтому именно корректирующему сопровождению уделяется особое внимание.
Улучшающее сопровождение — это добавление в продукт новых функций. Запросы на их включение обычно также исходят от пользователей, но и аналитики не остаются в стороне, выдавая заявки на доработку системы.
Адаптивное сопровождение— это внесение изменений для поддержки новых программных и аппаратных средств. Изменения в интерфейсе отдельных компонентов системы или структуры данных влекут за собой переделку части системы для возвращения ей работоспособного состояния. Но при этом функциональность не нуждается в расширении. Программа лишь должна выполнять старые функции в новых условиях или в новом окружении.
Внесение изменений — это чаще всего правка исходного кода, которая влечет за собой весь комплекс работ по модернизации ПО — от анализа до тестирования и передачи пользователям. Для облегчения этого процесса создаются методики, позволяющие вносить изменения в программный код с меньшими трудозатратами, например получивший широкое распространение объектно-ориентированный подход.
Настройка ввода данных
Однако есть еще другая сторона сопровождения, также поглощающая немало человеко-дней. Здесь мы вспоминаем о сопровождении как о процессе. Независимо от того, к какому типу сопровождения принадлежит заявка (дефект программного обеспечения, требование на доработку и т. п.), она должна пройти по определенному маршруту между сотрудниками, меняя свой внутренний статус в зависимости от проведенных работ. Как этот процесс поставлен, сколько у него бюрократических инстанций и каковы трудоемкость и стоимость прохождения каждого шага и поддержки процесса в целом — все это определяет общую стоимость сопровождения в конкретной компании.
Процесс управления запросами на изменение (CRM — Change Request Management) представляет собой целый цикл работ по регистрации, отслеживанию, анализу запроса, принятию по нему решения, реализации, проверке и закрытию. Реализация CRM требует принятия ряда решений руководителями различных подразделений и обмена информацией между заинтересованными лицами о поставленных задачах и произведенных работах.
Одним из вариантов поддержки этого процесса будет его реализация при помощи внутренних регламентов организации, но при этом нельзя забывать, что для отслеживания их выполнения необходимо затрачивать дополнительные ресурсы. И все равно никто не гарантирует точного их соблюдения, ведь так велико искушение немного отступить от правил.
Рассмотрим обычный сценарий работы с запросом на изменение программного продукта. Например, пользователь сталкивается с проблемой, разрешить которую самостоятельно не в состоянии. Он звонит (пишет письма, посылает факс) разработчикам и сообщает о ней. Проблема регистрируется и передается экспертам для анализа, и если есть возможность ее как-то обойти или решить “мирными” способами, т. е. без внесения изменений в исходный код, то такое решение и принимается. Если в обозримое время поиски обходных путей не дают результатов, то скорее всего придется дорабатывать программный продукт для устранения выявленной проблемы. Руководитель определяет трудоемкость работ, назначает ответственного и срок исполнения. После внесения изменений они тестируются, и новая версия отправляется пользователям. Проблема закрывается.
Организация такой или еще более сложной цепочки работ уже сама по себе непростая задача, требующая четкой регламентации последовательности действий. Правда, некоторые компании, успешно внедряющие документооборот у своих клиентов, пытаются отрицать необходимость управления этим процессом и работают по старинке. У них прием заявки может выглядеть следующим образом.
Секретарь (хорошо, если он есть) принимает звонок и переадресует его одному из разработчиков, ответственных за ту или иную функцию системы. Разработчик долго беседует с пользователем, пытаясь разобраться в его проблеме и совершенно не догадываясь, что в соседней комнате или даже за соседним столом эту проблему уже успешно решили.
Обычная картина для неформализованного процесса сопровождения — специалист по системе затрачивает значительную часть своего рабочего времени на общение с пользователями по телефону, разъяснение вопросов, касающихся эксплуатации ПО. При этом поступающая информация в лучшем случае фиксируется в Excel-файле и по мере внесения исправлений удаляется, а в худшем — вообще записывается на клочках бумаги, периодически куда-то пропадающих.
Налицо непродуктивная трата времени квалифицированного специалиста, вдобавок к этому возникают трудности с планированием работ по устранению замечаний. У руководителя нет полной информации по выявленным дефектам, нет сводной статистики по замечаниям, которые уже исправлены или еще нуждаются в рассмотрении.
Настройка запроса к данным
Кто в подобных случаях расставляет приоритеты? Сам разработчик — он принимает замечания и решает, что делать в первую очередь, а что отодвинуть на потом. Это должен быть чрезвычайно ответственный человек, который болеет за свое дело и аккуратно складывает распечатки дефектов в папочку, а таких среди программистов, приверженцев разумного хаоса, еще нужно поискать. В течение года такой разработчик забивает бумагами ящики своего рабочего стола, и гарантии, что хотя бы одно замечание пользователя при этом не потеряется, — никакой.
Пока нет вала замечаний и у фирмы всего один-два клиента, работающих с небольшой системой, с этим еще можно как-то мириться, но когда объемы возрастают, требуется кардинальное решение проблемы. Необходим инструмент, который позволит сделать сопровождение прозрачным, будет поддерживать необходимую организацию работ, запрещая отступать от правил и не требуя больших усилий на ведение процесса, и конечно же в нем должны храниться все полученные данные в одном месте для быстрого и беспрепятственного доступа команды сопровождения — от руководителя до программиста.
Для поддержки процесса разработки компания Rational Software (www.rational.com) предлагает средство Rational ClearQuest (RCQ). Эта программная система, построенная на технологии клиент—сервер, предназначена для управления дефектами и запросами на изменение программного обеспечения. Она работает как под Windows, так и на платформе UNIX.
В систему входят следующие основные модули:
Rational ClearQuest Maintenance Tool предназначен для управления соединением с базой данных и настройки хранилища данных CQ для следующих СУБД: Oracle, SQL Anywhere, DB2, Microsoft Access, MS SQL Server. Есть возможность переноса базы между СУБД, что позволяет в не очень крупных проектах использовать поначалу Microsoft Access, а в дальнейшем по мере необходимости перейти на СУБД с большей производительностью.
Клиентская утилита CQ предоставляет чрезвычайно гибкий доступ к базе данных требований и дефектов как Windows/UNIX-клиентам, так и работающим через Web-интерфейс.
Ввод новых данных осуществляется довольно просто, при помощи нескольких щелчков мыши, однако основным достоинством системы является возможность, которая понятна уже из ее названия***, это — построение запросов к базе данных дефектов и обращений на изменение.
***ClearQuest можно перевести как “прозрачный запрос”.Интуитивно понятный интерфейс визуального редактора позволяет легко изменять готовые запросы и полученные данные или создавать новые запросы, сохраняя все в базе.
Результаты запросов могут быть выведены как в табличной форме, так и в форме графиков. Возможно подключение внешнего отображения данных, например через Crystal Report, и создание любых, даже самых изощренных отчетов.
Система позволяет создавать профили практически для любого программного проекта. Для этого в комплект поставки включен Rational ClearQuest Designer, предлагающий инструменты для изменения предустановленной структуры и встроенных алгоритмов обработки. Designer позволяет не только менять окна ввода, например для русификации, но и добавлять новые поля и обработчики событий на языках Basic или Perl. Нужно отметить, что при изменении в обработчиках событий они отражаются во встроенной системе контроля версий, в этом случае не требуется использования дополнительных программ, таких, как MS Visual Source Safe или Rational Clear Case.
ClearQuest предоставляет готовые типы записей (record types) для дефектов и запросов на доработку, однако если процессы вашей компании отличаются от стандартных, можно полностью преобразовать предустановленные типы для более точного следования процессу.
Каждая запись данных, будь то дефект или требование, в течение своего жизненного цикла проходит через несколько состояний — от обнаружения до закрытия, что отражается в системе при помощи состояний (state) и матрицы переходов между ними (state transition). Эту структуру можно добавлять и изменять, что позволяет необходимым образом организовать и в любой момент точно отследить текущее состояние работ, поскольку для любых изменений данных в системе ведется внутренний протокол.
Создание диаграммы
Настройка перехватчиков событий (hook), например для оповещения заинтересованных лиц по электронной почте, позволяет автоматизировать процесс прохождения документов в цепочке работ.
Вместе с ClearQuest поставляются шесть уже настроенных схем работы:
Таким образом, ClearQuest может работать как отдельно, так и вместе с другими продуктами компании Rational, полностью поддерживая процесс разработки и сопровождения.
Интересные возможности для руководителя предоставляет тандем ClearQuest и Microsoft Project 2000—2002 с точки зрения планирования работ. Для связи этих продуктов в комплект поставки включен модуль plug-in для MS Project — ClearCase Project Tracker, который позволяет производить обмен между базой данных дефектов и запросов на изменение и проектом в Microsoft Project.
После установки этого модуля в MS Project появляются дополнительные пункты меню, при выборе которых и происходит обмен данными. Таким образом, ClearQuest дает возможность руководителю планировать работы по сопровождению программной системы без дополнительных затрат времени на его изучение. При этом есть возможность вообще не устанавливать модуль клиента на компьютер руководителя, если доступ к базе производится посредством Web-интерфейса.
В заключение можно отметить, что ClearQuest — комплексная система, построенная с использованием многолетнего опыта Rational Software и охватывающая все необходимые этапы работ по сопровождению программных продуктов. Эта система позволяет оптимизировать работу команды сопровождения, повысить ее качество и снизить непродуктивные потери времени. Ее внедрение позволит руководителям в любой момент получать исчерпывающую информацию как по текущему состоянию дел, так по тенденциям и прогнозам.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
