Прогнозирование сопровождения

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

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

• Количество и сложность системных интерфейсов.

• Количество изменяемых системных требований.

• Бизнес-процессы, в которых используется данная система.

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

• Количество запросов на корректировку системы.

• Среднее время, потраченное па анализ причин системных сбоев и отказов.

• Среднее время, необходимое на реализацию изменений.

• Количество незавершенных запросов на изменения.

Управление изменениями

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

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

Процесс управления изменениями

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

Сразу после представления заполненной формы запроса проводится проверка необхо­димости и допустимости изменения. Это объясняется тем, что некоторые изменения вызва­ны не ошибками в программе, а неправильным пониманием требований, другие могут дуб­лировать исправление ранее обнаруженных ошибок. Если в процессе проверки выявляется, что изменение недопустимо, повторяется или уже было рассмотрено, то изменение откло­няется. Лицу, представившему запрос на изменение, объясняется причина отказа.

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

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

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

Изменение каждого компонента системы должно регистрироваться. Таким образом создается история компонента.