Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Включение элементов в программную конфигурацию (Acquiring software configuration items) Различные элементы программной конфигурации передаются под управление SCM-процесса в различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла. Инициирующим событием является завершение определенных форм формального утверждения задач, таких как формальная оценка (review). Рисунок 4 характеризует развитие базовой линии в процессе жизненного цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях иллюстрации; нижние индексы используются для обозначения версий эволюционирующих элементов. Запросы на изменения (software change requests, SCR), присутствующие на рисунке, описываются в теме 3.1 “Requesting, Evaluating, and Approving Software Changes”. Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4] После включения элемента в конфигурацию в качестве SCI, изменения элементов должны утверждаться формально, как связанные с соответствующими элементами (SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP). После утверждения <запроса на изменение и проведения работ по изменению>, <измененный> элемент включается в конфигурацию, в соответствии с заданной процедурой утверждения. Программная библиотека (Software Library) Программная библиотека – контролируемая коллекция программных приложений и связанной с ними документации, предназначенная для использования в процессе разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE 610.12-90). В качестве <элемента> программной библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике могут использоваться различные типы библиотек, каждая из которых соответствует определенному уровню зрелости элементов программного обеспечения. Например, “рабочая библиотека” (working library) может поддерживать работы по кодированию, “библиотека поддержки проекта” (project support library) может поддерживать тестирование, “мастер-библиотека” (master library) может использоваться для завершенных продуктов (например, как вся совокупность средств, используемых для разработки и/или выпуска продукта). С каждой библиотекой ассоциирован соответствующий уровень контроля конфигурационного управления, также ассоциированный с базовой линией и уровнем полномочий по внесению изменений. Безопасность (в терминах контроля доступа и средств резервного копирования) является одним из ключевых аспектов управления библиотеками. SWEBOK отмечает, что существуют различные модели программных библиотек, а также приводит соответствующие первоисточники по этой теме. Используемые для каждой библиотеки инструменты должны поддерживать контроль SCM, необходимый для данной библиотеки, как в терминах управления элементами конфигурации (SCI), так и с точки зрения контроля доступа к библиотеке. На уровне рабочей библиотеки – это средства управления кодом, обслуживающие разработчиков, специалистов по сопровождению и SCM-процесс/инструментарий (например, среда разработки должна обеспечивать интеграцию с SCM-системой). В данном контексте, рабочая библиотека фокусируется на управлении версиями программных элементов (к которым, безусловно, относится не только код, но и запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в многопользовательской среде. На более высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система) является основным пользователем <библиотеки> (например, для осуществления автоматической сборки продукта по расписанию). Все эти библиотеки также являются важным источником информации для количественной оценки работ, их результата и прогресса <в развитии программных элементов>. Контроль программных конфигураций (Software Configuration Control) Контроль программных конфигураций касается вопросов управления изменениями в течение жизненного цикла программного обеспечения. Он включает процесс определения того, какие именно изменения должны быть сделаны, какие полномочия необходимы для утверждения определенных <типов> изменений, в чем состоит поддержка реализации этих изменений, а также концепцию формального утверждения отклонений от проектных требований, также как и отказа от внесения изменений. Получаемая в результате этого информация полезна для количественной оценки потока изменений, нарушения целостности <системы> и аспектов “переработки” в проекте (в большинстве случаев, по времени, стоимости и усилиям - трудозатратам). Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes) Первый шаг по управлению изменениями контролируемых элементов состоит в определении того, какие именно изменения надо производить. Процесс обработки запросов на изменения (software change request process), представленный на рисунке 5, включает формальные процедуры по предложению (submitting) и записи (recording) запросов на изменения, оценки потенциальной стоимости и влияния предлагаемых изменений, а также принятию, модификации или отказу от внесенных предложений по изменениям. Запросы на изменения элементов программных конфигураций могут вноситься любым лицом в любой точке жизненного цикла и может включать предлагаемые решения и соответствующий уровень приоритетности. Один из источников запросов на изменения состоит в инициировании корректирующих действий в ответ на сообщения о проблемах (problem reports). Вне зависимости от источника запроса, в самом запросе на изменение (software change request, SCR) обычно записывается информация о его типе (например, “дефект” или “заявка на расширение функциональных возможностей”/”пожелание” – enchancement/suggestion). Рисунок 5. Поток процесса контроля изменений. [SWEBOK, 2004, с.7-7, рис. 5] Такой подход обеспечивает возможность отслеживания дефектов и сбора метрических показателей о деятельности по обработке и внесению изменений, с группировкой по типу изменений. Как только получен запрос на изменение (SCR), производится техническая оценка (включающая, а иногда и называемая анализом влияний – impact analysis) запрашиваемых изменений для определения масштабов модификаций, необходимых для удовлетворения параметров запрашиваемых изменений (достаточно часто, в результате такого анализа формулируются соответствующие требования, определяющие содержание необходимых работ). Четкое понимание связей между программными (и, возможно, аппаратными) элементами системы является важной составной частью данной задачи. Наконец, органы, обладающие полномочиями, соответствующими затрагиваемой базовой линии, элементам программной конфигурации и природе изменений, должны оценить технические и управленческие (организационные) аспекты внесения запрашиваемых изменений, а также принять, модифицировать, отклонить или отложить предлагаемые изменения. Совет по конфигурационному контролю (Software Configuration Control Board) Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются на <организационную> сущность, называемую совет по конфигурационному контролю - Configuration Control Board (чаще звучит как совет по координации изменений - Change Control Board, CCB). В небольших проектах такие полномочия могут, в действительности, принадлежать лидеру или одному назначенному лицу из числа членов проектной команды. В общем случае может существовать несколько уровней полномочий в части принятия решений в отношении изменений, в зависимости от различных критериев, таких как критичность предлагаемых изменений, их приоритет, природа изменений (например, параметры бюджета или расписания) или текущая точка жизненного цикла. Решения о том, кто именно будет включен в CCB для данной системы (проекта) могут варьироваться, в зависимости от данных критериев. Однако, в CCB всегда должно присутствовать лицо, вовлеченное в организацию конфигурационного управления. В CCB входят все заинтересованные лица, чья роль соответствует уровню CCB. Когда содержание полномочий CCB охватывает только аспекты программного обеспечения, такой совет называется Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно является объектом аудита качества или оценки. Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений. Процесс обработки запросов на изменения (Software change request process) Эффективный процесс <обработки> запросов на изменения (SCR process) требует использования соответствующих средств поддержки и процедур <для данного вида деятельности>, от “бумажных” форм и документированных процедур (как последовательности действий или сценариев) до программных инструментов, позволяющих отсылать запросы на изменения, выполнять процесс обработки таких запросов (изменять их статус, комментировать, детализировать и т.п.), фиксировать решения, принятые CCB, а также генерировать отчетную информацию по процессу обработки запросов на изменения. Связь между этими средствами и инструментами обработки отчетов об ошибках может существенно облегчить определение решений для обнаруженных проблем. Обработка различных типов запросов на изменения в отношении разрабатываемых или модифицируемых программных систем, будь то сообщения о проблемах (defect report) или запросы на расширение функциональности (enchancement request), даже при разных процессах принятия решений в отношении их, должны быть объединены в единую систему (в единой базой данных), являющуюся составной и неотъемлемой частью единой среды конфигурационного управления. Только в этом случае можно обеспечить однозначную и актуальную связь между запросами различных типов и другими активами проекта (кодом, документацией, проектными моделями, задачами, ресурсами и т.п.), что позволяет не только получать актуальную информацию в любой момент времени, но и оперативно принимать те или иные (в том числе, управленческие) решения в отношении проекта, основываясь на максимально полном и корректном объеме информации. SWEBOK отмечает, что описания процессов и соответствующих форм (например, формы сообщения о проблеме) можно найти в большом количестве внешних источников, в частности, указанных непосредственно в библиографии SWEBOK. Реализация изменений (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) – утверждение дальнейшего использования элемента, которое отличается в той или иной степени от предварительно заданных условий. В обоих случаях используются формальные процессы (точнее, процедуры) для получения одобрения на отклонение или отказ от предопределенных ранее условий. В большинстве случаев, говорят об отклонении от требований (изменении реализации требований с одновременной их корректировкой) и отказе от выполнения запросов на изменения (или отклонении запросов). Как вы уже обратили внимание, использование слова “отклонение” сильно зависит от контекста, подразумевая, в первом случае, определенную корректировку условий и работ и, во втором случае, полный отказ от внесения изменений с утверждением и обоснованием такого отказа. Учет статусов конфигураций (Software Configuration Status Accounting) Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения. Информация о статусе конфигураций (Software Configuration Status Information) Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется для получения (и генерации отчетов) информации, необходимой для осуществления процессов жизненного цикла системы. Как и в любой информационной системе, информация о статусе конфигураций должна идентифицироваться, собираться и поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций. Различная информация и количественные показатели необходимы для поддержки процесса конфигурационного управления, а также для генерации отчетности (о статусе конфигураций), необходимой для управления, выполнения процессов программной инженерии и других связанных видов деятельности. Типы доступной информации обычно включают идентификацию утвержденных конфигураций, наравне с идентификацией и текущим статусом реализации изменений, отклонений и отказов от изменений. SWEBOK дает ссылки на источники, содержащие возможные (частные) списки важных информационных элементов. Современные инструментальные средства SCM должны включать определенные формы поддержки сбора и данных и подготовки SCSA-отчетности. Это может быть реализовано на уровне обращения к соответствующим базам данных, может быть представлено и в виде самостоятельных приложений, а также являться функциональной составляющей более крупных интегрированных инструментальных средств. Логично, что только такие интегрированные многофункциональные средства возможно считать полноценными SCM-инструментами, образующими категорию систем конфигурационного управления. В противном случае, мы говорим лишь об отдельно взятых (пусть и взаимодействующих, в той или иной степени) инструментах - “системе управления заявками на изменения” (change request submission), “системе сообщения и отслеживания дефектов” (defect-tracking), “системе контроля версий” (version control), “системе генерации отчетности” (configuration reporting) и т.п. Отчетность по статусу конфигураций (Software Configuration Status Reporting) Отчетная информация может быть использована различными организационными единицами или проектными группами, включая команду разработки, команду сопровождения, управляющих проектами и персоналом, обеспечивающим проверку качества. Отчетность может предоставляться в специальной форме, следуя специфическим запросам, но может генерироваться на постоянной основе (с определенной периодичностью) в соответствии с заданными шаблонами. Определенные элементы информации, получаемой в процессе деятельности по учету статуса конфигураций, может становиться составной частью данных, необходимых и используемых в работах по обеспечению качества (как продуктов, так и процессов). В дополнение к отчетности по текущему статусу конфигураций, информация, получаемая в процессе SCSA-деятельности, может использоваться как основа для проведения различных количественных оценок в интересах менеджмента, разработки или конфигурационного управления. Например, к такого рода данным относятся: количество запросов на изменения на один конфигурационный элемент; среднее время, необходимое для реализации запрошенных изменений <заданного типа>. Аудит конфигураций (Software Configuration Auditing) Аудит программного обеспечения – деятельность, выполняемая для независимой оценки программных продуктов и процессов на <формальное> соответствие (conformance) применимым в данном случае инструкциям, стандартам, руководящим документам, планам и процедурам (см. IEEE 1028-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 для программного и аппаратного обеспечения, перед их выполнением необходимо четко оценивать реальные потребности в таких видах аудита (так как они требуют существенных, иногда, просто “неподъемных” затратах ресурсов, если оценивать их в рамках заданных ограничений проекта). |