Управление выпуском программного обеспечения (Software Release Management)

Управление выпуском (release management) программного обеспечения охватывает идентификацию, упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации, аннотацию релиза (release note) и конфигурационные данные. Понимая, что изменения в продукте происходят постоянно, одной из задач управления выпуском продукта является определение момента времени, когда именно выпускать продукт (в этом контексте, управление выпуском может быть тесно связано как с деятельностью по обеспечению качества, так и с маркетинговыми соображениями в отношении выпускаемого продукта). На это решение также влияет серьезность проблем, решению которых адресуется релиз, и количественная оценка плотности сбоев (fault densities) в предыдущих релизах. Задача упаковки (packaging) состоит в идентификации того, какие элементы продукта должны быть выпущены (например, на основании функциональных требований и их трассировки на элементы конфигурации), и в последующем выборе корректных вариантов этих элементов, задаваемом аспектами применения продукта. Документирование информации о физическом содержании релиза, обычно, включают в документ описания версии (version description document). В свою очередь, аннотация релиза (release note) содержит информацию о новых возможностях, известных проблемах, а также требованиях к платформе(ам), которые необходимо соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к выпуску пакет (package) также включает инструкции по установке и обновлению <предыдущей версии>. Создание такой инструкции может быть осложнено тем, что некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по управлению выпуском может требовать отслеживание распространения (поставки) продукта различным заказчикам или в рамках заданных целевых систем. Например, возможны ситуации, когда поставщику требуется уведомить заказчика об обнаруженных проблемах.

Для поддержки таких функций управления выпуском могут требоваться соответствующие возможности инструментария поддержки (средств поддержки или “вспомогательных средств”, если, например, попытаться максимально приблизиться к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с инструментальными возможностями поддержки процесса обработки запросов на изменения для отображения содержимого релиза на полученные запросы на изменения (SCR - software change request, включая сообщения об обнаруженных ранее и исправленных в данном релизе ошибках, прим. автора). Эти инструментальные средства <поддержки управления выпуском продуктов> также могут поддерживать информацию о различных целевых платформах и <операционном> окружении, используемом у заказчиков.

 

7. Управление программной инженерией
(Software Engineering Management по SWEBOK)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK.
Содержит перевод описания области знаний SWEBOK “Software Engineering Management”, с замечаниями и комментариями.

Управление программной инженерией (Software Engineering Management)
1. Инициирование и определение содержания (Initiation and Scope Definition)
1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements)
1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)
1.3 Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)
2. Планирование программного проекта (Software Project Planning)
2.1 Планирование процесса (Process Planning)
2.2 Определение результатов (Determine Deliverables)
2.3 Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation)
2.4 Распределение ресурсов (Resource Allocation)
2.5 Управление рисками (Risk Management)
2.6 Управление качеством (Quality Management)
2.7 Управление планом проекта (Plan Management)
3. Выполнение программного проекта (Software Project Enactment)
3.1 Реализация планов* (Implementation of Plans)
3.2 Управление контрактами с поставщиками (Supplier Contract Management)
3.3 Реализация процесса по ведению измерений (Implementation of Measurement Process)
3.4 Процесс мониторинга (Monitor Process)
3.5 Процесс контроля (Control Process)
3.6 Ведение отчетности (Reporting)
4. Обзор и оценка (Review and Evaluation)
4.1 Определение удовлетворения требованиям (Determining Satisfaction of Requirements)
4.2 Оценка продуктивности/результативности (Reviewing and Evaluation Performance)
5. Закрытие (Closure)
5.1 Определение <критериев> закрытия проекта (Determining Closure)
5.2 Работы по закрытию проекта (Closure Activities)
6. Измерения в программной инженерии (Software Engineering Measurement)
6.1 Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment)
6.2 Планирование процесса измерений (Plan the Measurement Process)
6.3 Выполнение процесса измерений (Perform the Measurement Process)
6.4 Оценка измерений (Evaluate Measurement)

Управление программной инженерией может быть определено как приложение вопросов управления (management activities) – планирования, координации, количественной оценки, мониторинга, контроля и отчетности – к инженерной деятельности для систематического, упорядоченного и количественно измеряемого обеспечения разработки и сопровождения программных систем (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology).

Таким образом, область знаний “Управление программной инженерией” определяет аспекты управления и количественной оценки в программной инженерии. Измерения являются важным аспектом для всех областей знаний SWEBOK и соответствующая тема также включена и в описании данной области знаний.

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

  • Восприятие клиентов (потребителей, заказчиков) таково, что часто отсутствует с их стороны понимание сложности, порожденной самой природой программной инженерии, в частности связанной с влиянием изменяющихся требований.
  • Практически неизбежно изменение или появление новых клиентских требований, как следствие функционирования процессов программной инженерии.
  • В результате, программные системы часто строятся с применением итеративных процессов, вместо последовательного выполнения и закрытия работ (задач).
  • Уровень новизны и сложности программных систем часто крайне высок (и не позволяет в полной мере применять уже существующие наработки и опыт).
  • Применяемые технологии обладают высокой скоростью изменения, обновления и устаревания

Что касается программной инженерии, управленческая деятельность в этой области происходит на трех уровнях:

  • Организационное управление и управление инфраструктурой
  • Управление проектами
  • Планирование и контроль программ количественной оценки

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

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

Другим важным аспектом управления является управление персоналом через политики и процедуры найма и приема на работу, обучения, и мотивации специалистов, помощи в развитии навыков для дальнейшего карьерного роста (mentoring in career developement). Все это требует внимания не только в контексте проекта, но в рамках всей организации. Для инженеров-программистов особо важными, в частности, являются вопросы обучения и индивидуального внимания менеджмента. В большой степени это связано с постоянно развивающимеся технологиями и потребностью в обновлении и расширении знаний для эффективного решения поставленных задач. Часто не придают необходимого внимания вопросам коммуникаций между сотрудниками. На самом деле управление коммуникациями, создание естественных условий (в agile-практиках им придается особое внимание) для их развития – один из ключевых элементов повышения не только продуктивности команд разработки и сопровождения, но и, например, точности получаемых от пользователей требований и запросов на изменения, то есть любой информации, которая передается между людьми и значима для успешного решения поставленных задач. Наконец, управление портфелями (проектов разработки и работ по сопровождению) позволяет сформировать и развивать общее видение в отношении всех существующих, обновляемых и создаваемых программных активов на уровне ИТ-подразделения и в организации, в целом. Все это, в конечном счете, обеспечивает и более эффективное управление ресурсами, а, значит, и возможность интенсивного, а не экстенсивного развития организации, в которой инновации начинают играть одну из ключевых ролей.

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

Организационная культура, нормы поведения, аспекты корпоративного управления в вопросах приобретения и поставки, управления цепочками поставок (supply chain management), маркетинг, продажи, партнерства и т.п. – все это влияет, хотя и неявно, на организационные процессы программной инженерии.

В отношении данной области знаний особо уместно подчеркнуть значимость вопросов управления проектами (project management), так как “конструирование имеющих ценность программных артефактов” (к которым относятся требования, модели, документация, тесты и т.п.) обычно ведется в форме проектов или программ проектов. Принимая это во внимание, создатели SWEBOK особо отмечают связь данной области знаний c обсуждавшимся уже в этой книге Руководством к Своду Знаний по Управлению Проектами PMBOK (A Guide to the Project Management Body of Knowledge. PMBOK® Guide). В контексте управления программной инженерией следует понимать важность соответствующих областей знаний PMBOK:

  • Управление интеграцией проекта (project integration management)
  • Управление содержанием проекта (project scope management)
  • Управление сроками проекта (project time management)
  • Управление стоимостью проекта (project cost management)
  • Управление качеством проекта (project quality management)
  • Управление человеческими ресурсами проекта (project human resource management)
  • Управление коммуникациями проекта (project communication management)

Наравне с ними, с точки зрения автора, необходимо уделять не меньшее внимание и другим областям знаний управления проектами:

  • Управление рисками проекта (project risk management)
  • Управление поставками проекта (project procurement management)

SWEBOK отмечает, что, несомненно, области знаний управления проектами имеют непосредственное влияние на решение вопросов управления инженерной деятельностью в области программного обеспечения. Не имеет смысла, да и просто невозможно дублировать в SWEBOK содержание PMBOK. Вместо этого, PMBOK рассматривается как ключевой источник информации и знаний по управлению проектами, настоятельно рекомендуемый всем лицам, в той или иной степени вовлеченных в управленческую деятельность в программных проектах. Таким образом, естественно, что управление проектами можно найти в области знаний SWEBOK “Связанные дисциплины” (Related Disciplines).

Данная область знаний состоит из пяти секций, посвященных процессам управления программной инженерией и еще одной секции, касающейся вопросов измерений и количественных оценок в управлении. Хотя эти два аспекта (управление и измерения) часто рассматриваются отдельно и, в самом деле, обладают многими уникальными аспектами, их тесная взаимосвязь играет важную роль в этой области знаний. К сожалению, сложилось, во многих случаях, обоснованное [Chaos, 2004] восприятие индустрии программного обеспечения как недостаточно зрелой, в силу частых срывов сроков, превышения бюджетных ограничений, недостаточного качества продуктов, неопределенной функциональности и других причин. Управление, ориентированное на измерения, как один из основных принципов любой инженерной деятельности, может серьезно помочь в изменении сложившейся неблагоприятной ситуации и формировании положительного восприятия программной индустрии потребителями (пользователями и заказчиками). По-сути, управление без измерений, количественных или качественных, приводит к отсутствию прогресса в достижении целей, а измерения без управления – к потере контекста и целей. Однако, в то же время, управление и измерения без необходимого и достаточного уровня знаний становится неэффективным и, часто, превращается в самоцель (что приводит, по мнению автора к излишней бюрократизации и неадекватной загруженности ресурсов). Таким образом, управленческая деятельность, в общем плане (включая количественные и качественные оценки), должна проводиться сбалансировано с другими аспектами программной инженерии, не превращая Software Engineering Management (SEM) в дорогостоящую, но бесполезную работу. Эффективный менеджмент требует комбинации соответствующих систематических и упорядоченных подходов в управлении и соответствующего опыта*.

* например, на практике практически невозможно добиться статуса PMP – Project Management Professional по версии Project Management Institute (PMI), если претендент не обладает серьезным практическим опыт управления проектами и пытается сдать соответствующий экзамен только на основе штудирования PMBOK и теоретических “изысканий”.

Прежде, чем детализировать данную область знаний, необходимо дать рабочие определения для понятий “процесс управления” и “измерения”:

  • Процесс управления (Management process) описывает действия (работы - activities), предпринимаемые для обеспечения того, что процессы программной иженерии выполняются в согласовании с политиками, целями и стандартами, принятыми в организации
  • Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также разработкой на их основе моделей* с использованием статистических методов (и данных), экспертных знаний и других техник.

* В данном контексте, SWEBOK видимо подразумевает, что полученные модели используются для идентификации и анализа рисков, планирования и совершенствования процессов программной инженерии (процессов жизненного цикла, включая процессы сопровождения), а также процесса управления.

Секции (подобласти) данной области знаний, связанные с управлением программной инженерией, тесно связаны с секций измерений (количественной оценки).

Вполне естественно, что данная область знаний тесно связана с другими областями знаний SWEBOK и ее необходимо рассматривать в контексте других областей знаний. Стоит особо отметить следующие аспекты применения других областей знаний в управлении программной инженерией и, особо, в управлении программными проектами:

  • Требования к программному обеспечению (Software Requirements) – соответствующие действия по работе с требованиями (в первую очередь, их определение) указанной области знаний должны выполняться в фазе инициирования (Initiation) и определения содержания (Scope Definition) программных проектов.
  • Конфигурационное управление (Software Configuration Management) – связано с идентификацией, контролем, учетом статуса (активов проекта, включая запросы на изменения, прим. автора) и аудитом конфигураций (в терминах конфигурационного управления) в сочетании с управлением релизами (release management) и развертыванием программных систем.
  • Процесс программной инженерии (Software Engineering Process) – процессы и продукты тесно связаны; указанная область знаний включает аспекты измерений продуктов и процессов.
  • Качество (Software Quality) – качество является одной из постоянных целей управления и большого комплекса соответствующих работ, которыми необходимо управлять.

Данная область знаний рассматривает управление программной инженерий в терминах организационного процесса, включающего управление процессами и проектами. Структурная декомпозиция этой области знаний основывается и на определении соответствующих тем и на рассмотрении жизненного цикла. При этом, основной отправной точкой дальнейшей детализации является процесс управления программными проектами (в оригинале SWEBOK в данной области знаний активно используется термин software engineering project). Таким образом, структура декомпозиции управления программной инженерией включает шесть основных секций (подобластей), из которых первые пять, в основном, следуют стандарту IEEE (ISO/IEC, ГОСТ) 12207 в части “Процесса управления” (Management Process). Вот эти шесть секций данной области знаний:

  • Инициирование и определение содержания (Initiation and scope definition) – касается принятия решения о начале программного проекта
  • Планирование программного проекта (Software project planning) – относится к работам, предпринимаемым для подготовки к успешному ведению программно-инженерной деятельности с точки зрения управления
  • Выполнение программного проекта (Software project enactment) – касается общепринятых (general accepted) действий по управлению программной инженерией в процессе проведения соответствующих инженерных работ
  • Обзор и оценка (Review and evaluation) – относится к работам по проверке того, что получаемый программный продукт отвечает заданным целям, требованиям, ограничениям и т.п.
  • Закрытие <проекта> (Closure) – относится к фиксированию результатов программного проекта после передачи полученного программного продукта в эксплуатацию.
  • Измерения в программной инженерии (Software engineering measurement) – касается разработки и реализации программ по измерению (ведению количественной оценки) в организациях (в общем смысле, т.е. группах, подразделениях, компаниях и т.п.), занимающихся инженерной деятельностью в области программного обеспечения.

Рисунок 1. Область знаний “Управление программной инженерией” [SWEBOK, 2004, с.8-2, рис. 1]

Здесь нельзя не сделать замечание, связанное со структурированием этой области знаний. Обсуждаемая область знаний, действительно, тесно связана с дисциплиной управления проектами. Более того, речь идет о приложении управления проектами к программной инженерии. В этом контексте кажется уместным сопоставить предлагаемый в SWEBOK цикл “Initiation & scope definition – Planning – Enactment – Review & evaluation – Closure” с процессными группами PMBOK “Initiation – Planning – Execution – Monitoring & Controlling – Closing”. Как мы видим, в PMBOK роль работ SWEBOK “Обзор и оценка” (Review and evaluation) играют действия по мониторингу и контролю процессов - “Monitoring & Controlling Processes”. Таким образом, с учетом реального содержания секции “Software project enactment”, ее название и переведено автором как “Выполнение программного проекта”, хотя “enactment” в большей степени подразумевает формальный “запуск” работ. Конечно, перевод мог звучать и как “исполнение” (например, следуя PMBOK), однако, такой перевод, по мнению автора, все же несет слишком формальный оттенок, что, субъективно, не соответствует ряду методологических подходов (в первую очередь agile) и культурных “ограничений”.