6-software_engineering_configuration_manag ement (1133546), страница 6
Текст из файла (страница 6)
Только с учетом этих критериев и других ограничений можно сформировать оптимальное иэффективное решение по программному обеспечению SCM-процесса в том объеме, которыйобоснован в каждом конкретном случае.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru15Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.3.3 Отклонения и отказ от изменений (Deviations and Waivers)Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных работ<программной инженерии>, как и спецификации, созданные в процессе разработки, могут содержатьусловия, которые не могут быть удовлетворены в заданной точке жизненного цикла.
Отклонение(deviation) - утверждение изменений, внесенных относительно предварительно сформулированныхусловий к разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) –утверждение дальнейшего использования элемента, которое отличается в той или иной степени отпредварительно заданных условий. В обоих случаях используются формальные процессы (точнее,процедуры) для получения одобрения на отклонение или отказ от предопределенных ранее условий.В большинстве случаев, говорят об отклонении от требований (изменении реализации требованийс одновременной их корректировкой) и отказе от выполнения запросов на изменения (илиотклонении запросов).
Как вы уже обратили внимание, использование слова “отклонение” сильнозависит от контекста, подразумевая, в первом случае, определенную корректировку условий и работи, во втором случае, полный отказ от внесения изменений с утверждением и обоснованием такогоотказа.4. Учет статусов конфигураций (Software Configuration Status Accounting)Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA)подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации,необходимой для эффективного управления конфигурациями программного обеспечения.4.1 Информация о статусе конфигураций (Software Configuration Status Information)Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется для получения(и генерации отчетов) информации, необходимой для осуществления процессов жизненного цикласистемы.
Как и в любой информационной системе, информация о статусе конфигураций должнаидентифицироваться, собираться и поддерживаться <в актуальном состоянии> по мере эволюцииэтих конфигураций. Различная информация и количественные показатели необходимы дляподдержки процесса конфигурационного управления, а также для генерации отчетности (о статусеконфигураций), необходимой для управления, выполнения процессов программной инженерии идругих связанных видов деятельности.
Типы доступной информации обычно включаютидентификацию утвержденных конфигураций, наравне с идентификацией и текущим статусомреализации изменений, отклонений и отказов от изменений. SWEBOK дает ссылки на источники,содержащие возможные (частные) списки важных информационных элементов.Современные инструментальные средства SCM должны включать определенные формы поддержкисбора и данных и подготовки SCSA-отчетности.
Это может быть реализовано на уровне обращения ксоответствующим базам данных, может быть представлено и в виде самостоятельных приложений,а также являться функциональной составляющей более крупных интегрированныхинструментальных средств.Логично, что только такие интегрированные многофункциональные средства возможно считатьполноценными SCM-инструментами, образующими категорию систем конфигурационногоуправления. В противном случае, мы говорим лишь об отдельно взятых (пусть ивзаимодействующих, в той или иной степени) инструментах - “системе управления заявками наизменения” (change request submission), “системе сообщения и отслеживания дефектов” (defecttracking), “системе контроля версий” (version control), “системе генерации отчетности” (configurationreporting) и т.п.4.2 Отчетность по статусу конфигураций (Software Configuration Status Reporting)Отчетная информация может быть использована различными организационными единицами илипроектными группами, включая команду разработки, команду сопровождения, управляющихпроектами и персоналом, обеспечивающим проверку качества.
Отчетность может предоставляться вспециальной форме, следуя специфическим запросам, но может генерироваться на постояннойоснове (с определенной периодичностью) в соответствии с заданными шаблонами. Определенныеэлементы информации, получаемой в процессе деятельности по учету статуса конфигураций, можетCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru16Основы программной инженерии (по SWEBOK)Программная инженерия. Конфигурационное управление.становиться составной частью данных, необходимых и используемых в работах по обеспечениюкачества (как продуктов, так и процессов).В дополнение к отчетности по текущему статусу конфигураций, информация, получаемая в процессеSCSA-деятельности, может использоваться как основа для проведения различных количественныхоценок в интересах менеджмента, разработки или конфигурационного управления. Например, ктакого рода данным относятся: количество запросов на изменения на один конфигурационныйэлемент; среднее время, необходимое для реализации запрошенных изменений <заданного типа>.5.
Аудит конфигураций (Software Configuration Auditing)Аудит программного обеспечения – деятельность, выполняемая для независимой оценкипрограммных продуктов и процессов на <формальное> соответствие (conformance) применимым вданном случае инструкциям, стандартам, руководящим документам, планам и процедурам (см. IEEE1028-97 “Standard for Software Reviews”). Аудиты проводятся в <строгом> соответствии с четкоопределенными процессами, содержащими и определяющими различные роли аудиторов и изобязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и может требоватьпривлечения многих специалистов для выполнения различных задач (определяемых процедуройаудита) за достаточно короткий промежуток времени.
Автоматизированные средства,обеспечивающие поддержку планирования и проведения аудита, могут существенно облегчить иускорить этот процесс. SWEBOK отмечает, что рекомендации по проведению аудита можно найти вомногих источниках, в том числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”.Деятельность по аудиту программных конфигураций определяет степень, в которой элемент<конфигурации> (SCI) удовлетворяет заданным (например, на уровне требований и/или запросов наизменения) функциональным и физическим характеристикам. Неформальный аудит такого типаможет быть связан с ключевыми точками жизненного цикла (вехами проекта, в терминах управленияпроектами - milestones).
Существует два достаточно распространенных типа формального аудита(требуемого определенными категориями контрактов, например, на создание критически-важногопрограммного обеспечения): функциональный аудит конфигураций (Functional Configuration Audit,FCA) и физический аудит конфигураций (Physical Configuration Audit, PCA). Успешное (в терминахсоответствия результатов заданным условиям) завершение этих аудитов может быть обязательнымтребованиям для фиксирования базовой линии продукта.
В то же время, если сравнивать контекстFCA и PCA для программного и аппаратного обеспечения, перед их выполнением необходимо четкооценивать реальные потребности в таких видах аудита (так как они требуют существенных, иногда,просто “неподъемных” затратах ресурсов, если оценивать их в рамках заданных ограниченийпроекта).5.1 Функциональный аудит программных конфигураций (Software Functional Configuration Audit)Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент полностьюсоответствует заданным спецификациям. “Выход”, то есть результат проверки и аттестации (V&V,verification and validation) программного обеспечения является ключевым “входом” (исходнымиданными) для проведения этого аудита.5.2 Физический аудит программных конфигураций (Software Physical Configuration Audit)Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно согласуются с самимпрограммным продуктом.5.3 Внутренние аудиты базовых линий (In-process Audits of Software Baseline)Как уже упоминалось выше, аудиты могут выполняться на протяжении всего процесса разработкидля получения текущего статуса заданных элементов конфигураций.
В данном случае, аудит можетпроводиться в отношении к выборочным элементам базовых линий с тем, чтобы убедиться, чтособлюдаются заданные спецификациями характеристики процесса, скорости и качества развитияпродукта, а также того, что документация соответствует и поддерживается в согласованномсостоянии с документируемыми элементами продукта в процессе их эволюционирования/напротяжении жизненного цикла.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru17Основы программной инженерии (по SWEBOK)Программная инженерия.
Конфигурационное управление.6. Управление выпуском и поставкой (Software Release Management and Delivery)Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая распространение<и использование> элементов конфигураций за рамками работ по разработке программногообеспечения. Это может включать как внутренние релизы, так и выпуск и передачу программногообеспечения заказчикам. В ситуациях, когда доступны для поставки различные версии программныхэлементов (в частности, различные версии для разных платформ или редакции с различнымнабором функциональных возможностей), часто бывает необходимо создавать специализированныеверсии и пакеты (сборки) соответствующих материалов (элементов, активов) для выпуска в качестве<самостоятельной> версии. Программная библиотека (предоставляющая соответствующийинструментарий для такой сборки) играет ключевую роль в выполнении таких работ.6.1 Сборка программного обеспечения (Software Building)Сборка (building) программного обеспечения – деятельность по комбинированию корректных версийэлементов программных конфигураций, проводимая с использованием соответствующихконфигурационных данных, с целью получения исполняемой программы (программной системы) дляпередачи заказчику и/или другим получателям (например, выполняющим работы по тестированию).Исполняемая программа для аппаратных и программно-аппаратных систем получается в результатедеятельности по системной сборке (system building).
Инструкции по сборке предоставляют описаниенеобходимых для сборки шагов, представленных в заданной (корректной) последовательности.Работы по сборке программного обеспечения выполняются не только для получения нового релиза,но и для повторного создания предыдущих релизов в целях их восстановления, тестирования,сопровождения или каких-либо других необходимых действий.Программное обеспечение собирается с использованием заданных версий таких средств поддержки(supporting tools), как компиляторы. В ряде случаев может требоваться повторная сборка точнойкопии ранее собранного элемента конфигурации.
В этом случае, средства поддержки иассоциированные инструкции по сборке должны находиться под контролем SCM (подразумевая, взависимости от контекста, в определенных ситуациях, SCM-систему или только процесс) дляобеспечения доступности корректной версии инструментария.Часто бывают полезны возможности инструментов, позволяющие выбирать корректные длязаданного окружения версии программных элементов, а также обеспечивать автоматизациюпроцесса сборки (например, по расписанию) программного обеспечения на основы выбранныхверсий и соответствующих конфигурационных данных. Такие возможности инструментов особеннонеобходимы для крупных проектов с параллельной разработкой и/или распределенной средойразработки (географически распределенной команды разработки).
Большинство программныхсредств, обеспечивающих инфраструктуру разработки поддерживают такую возможность (или, какминимум, декларируют ее, прим. автора). Эти инструменты сильно отличаются (по степеникомплексности предоставляемого функционала и) по своей сложности, требуя в ряде случаевизучения специализированного (специфичного для конкретного инструмента) языка сценариев, илипредоставляя графические возможности, скрывающие сложность настройки “интеллектуальных”средств сборки программного обеспечения.Процесс и результаты сборки могут быть необходимы для последующего использования <в другихпроцессах, работах и проектах> и часто являются объектом верификации (проверки) в рамкахдеятельности по обеспечению качества (SQA).6.2 Управление выпуском программного обеспечения (Software Release Management)Управление выпуском (release management) программного обеспечения охватывает идентификацию,упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации,аннотацию релиза (release note) и конфигурационные данные.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
