Реализация изменений (Implementing Software Changes)
Принятые (утвержденные) запросы на изменения (SCR) реализуются используя определенные процедуры, в соответствии с подходящими требованиями в отношении расписания. Если набор утвержденных запросов на изменения может выполняться одновременно, необходимо обеспечить отслеживание того, какие именно SCR реализованы в конкретной версии программного продукта и базовой линии <конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с closure - “закрытием”, то есть завершением проекта), является аудит(ы) конфигурации(й) и верификация качества программного обеспечения. Это обеспечивает гарантию того, что были внесены только утвержденные изменения. Описанный выше процесс обработки запросов на изменения обычно включает документирование всей информации, связанной с принятым изменением.
Фактическая реализация изменений поддерживается инструментальными средствами соответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”), обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как минимум, эти инструменты должны поддерживать операции chek-in/check-out (помещение в репозиторий/ получение из репозитория) и ассоциированные возможности по контролю версий (например, отметка версии – labeling, сравнение – compare/diff, слияние – merge и т.п.). Более мощные инструменты могут поддерживать параллельную разработку (parallel development) и среду географически распределенной разработки (geographically distributed environment). Эти инструменты могут объявляться (в рамках организации) как отдельные специализированные приложения, целиком находящиеся под контролем независимой SCM-группы (как самостоятельной/выделенной организационной сущности). Наконец, они могут быть столь элементарными, что включают только упрощенный контроль версий, например, на уровне файловой системы операционной среды.
|
|
|
Безусловно, существует широкий спектр, обоснованных функциональных возможностей инструментальных средств, используемых для решения различных задач конфигурационного управления. При этом, при выборе соответствующего инструмента или комплекса инструментов, необходимо точно понимать их функциональную нагрузку, уровень интегрируемости, возможности по адаптации с учетом конкретных процессов жизненного цикла в проектной команде или организации, в целом. Только с учетом этих критериев и других ограничений можно сформировать оптимальное и эффективное решение по программному обеспечению SCM-процесса в том объеме, который обоснован в каждом конкретном случае.
Отклонения и отказ от изменений (Deviations and Waivers)
Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных работ <программной инженерии>, как и спецификации, созданные в процессе разработки, могут содержать условия, которые не могут быть удовлетворены в заданной точке жизненного цикла. Отклонение (deviation) - утверждение изменений, внесенных относительно предварительно сформулированных условий к разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) – утверждение дальнейшего использования элемента, которое отличается в той или иной степени от предварительно заданных условий. В обоих случаях используются формальные процессы (точнее, процедуры) для получения одобрения на отклонение или отказ от предопределенных ранее условий.
|
|
|
В большинстве случаев, говорят об отклонении от требований (изменении реализации требований с одновременной их корректировкой) и отказе от выполнения запросов на изменения (или отклонении запросов). Как вы уже обратили внимание, использование слова “отклонение” сильно зависит от контекста, подразумевая, в первом случае, определенную корректировку условий и работ и, во втором случае, полный отказ от внесения изменений с утверждением и обоснованием такого отказа.
Дата добавления: 2018-05-12; просмотров: 297; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!