Методологические основы

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

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

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

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