Главная | Обратная связь | Поможем написать вашу работу!

Врезка 29.1. Форма запроса на изменения

⇐ ПредыдущаяСтр 199 из 202Следующая ⇒

Проект. Proteus/PCL-Tools Номер. 23/94

Лицо, заполняющее запрос. Соммервиль Дата. 1/12/98

Требуемые изменения. После выбора компонента структуры необходимо отображение имени файла, в котором он хранится.

Лицо, осуществляющее анализ запроса. Г. Дин

Дата анализа. 10/12/98

Изменяемые компоненты. Display-lcon.Select, Display-lcon.Display

Связанные компоненты. FileTable

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

Уровень приоритета. Низкий

Выполнение изменения.

Оценка затрат. 0,5 дня

Дата передачи в группу контроля за изменениями. 15/12/98

Дата принятия решения группой контроля за изменениями. 1/2/99

Решение группы контроля за изменениями. Принять изменение. Будет реализовано в версии 2.1.

Кто вносит изменения.

Дата внесения изменений.

Дата передачи запроса в группу управления качеством.

Решение группы управления качеством.

Дата передачи запроса в группу по управлению конфигурацией.

Примечание.

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

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

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

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

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

Изменение каждого компонента системы должно регистрироваться. Таким образом создается история компонента. Самый лучший способ для этого – создавать стандартизированные комментарии в начале кода компонента (листинг 29.2), где содержатся ссылки на запросы изменений данного компонента. Для составления отчетов об изменениях компонента и обработки их историй используются специальные средства.

⇐ Предыдущая 193 194 195 196 197 198199200 201 202 Следующая ⇒