SCM - есть такая дисциплина

23 июль, 2002 - 23:00Андрей Зубинский
В этой и последующей статьях мы позволим себе вторгнуться в необычно парадоксальную область компьютинга. В отличие от "модной парадоксальности", когда существующие реализации инструментальных программных средств базируются на весьма сомнительной идеологической базе (сомнительной даже в том смысле, что сами ведущие идеологи не могут добиться согласия между собой в основополагающих терминах и определениях), мы столкнемся с разительным отличием реализаций определенных стандартами идей.

Не та SCM

Из-за обилия и важности материала отступлениями эта статья перегружена не будет. Поэтому сразу "возьмем быка за рога" -- аббревиатура SCM, к счастью, не имеет никакого отношения к своей "однофамилице" из бизнеса -- "управлению цепочками поставок". В нашем контексте SCM (Software Configuration Management) невнятно переводится русской калькой "управление конфигурацией программного обеспечения". К счастью, обозначаемая этой невнятностью область деятельности очень точно определена рядом исчерпывающих документов, в том числе стандартом IEEE 729-1983. И чтобы понять важность этой области, достаточно привести из него одну-единственную фразу: "SCM -- дисциплина управления эволюцией программных систем". Уже из этой короткой фразы понятно -- речь идет о масштабных, обладающих запасом живучести, разработках, состоящих из многих десятков и сотен тысяч или даже миллионов строк кода, которыми заняты сотни и тысячи человек. При таких масштабах многогранное понятие "сложности ПО" отражается даже в задаче управления самими исходными текстами, а если учесть очевидный факт, что в ходе развития (эволюции) составляющие программный продукт отдельные модули, классы, процедуры и т. п. изменяются в общем случае асинхронно... появляется потребность в весьма нетривиальных механизмах трансформации множества версий отдельных фрагментов в нечто целое, обладающее заданными показателями качества (по меньшей мере, принципиально работоспособное). Для решения такой непростой задачи стандарт IEEE-Std-610 (уточненный и частично пересмотренный IEEE 729-1983) требует от овеществлений SCM как дисциплины строго определенного функционального перечня.

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

Во-вторых, SCM-системы должны автоматизировать процесс сбора статистики о самом процессе эволюции создаваемых с ее помощью продуктов, для чего, очевидно, они обязаны "помнить" даты и авторство любой из модификаций всех программных компонентов. Эта информация жизненно необходима как для персонала, управляющего проектом, так и для функционирования всей человеко-машинной системы проектирования ПО в целом. Механизмы, отвечающие за реализацию этой функциональности, стандартом SCM названы "учетом состояния" (status accounting).

В-третьих, кроме "бухгалтерии" (игра слов с предыдущим accounting), не лишним будет и "аудит" -- ошибки в проектном процессе не только полезно регистрировать, желательно вообще избегать их появления. И SCM-система как раз должна заботиться о постоянной целостности проекта на уровне исходных текстов -- на протяжении всего жизненного цикла программного продукта его код должен в любой момент времени представлять собой строгую композицию точно определенного множества компонентов. Неудивительно, что стандарт IEEE 729-1983 называет такую функциональность "аудитом проекта".

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


Ценность разных взглядов

Несмотря на наличие стандарта и стандартных определений, в области SCM есть много признанных специалистов мирового уровня, чьи точки зрения на эту дисциплину порой открывают столь важные и интересные аспекты SCM, что не ознакомить с ними читателя было бы непростительным упущением. И, кроме того, SCM попадает под действие не только стандарта IEEE -- в ряде стран и даже в отдельных отраслях существуют свои национальные (отраслевые) стандарты.

В первом разделе статьи мы ознакомились с коротким, в одну фразу, определением SCM, приведенным в устаревшем стандарте (IEEE 729-1983). Автор выбрал его в качестве ознакомительного из-за краткости. Обновленная же версия IEEE (610) о SCM говорит более общо и пространно: "Управление конфигурацией -- это дисциплина, в рамках которой определено применение технических и административных усилий для идентификации и документирования функциональных и физических характеристик конфигурируемой единицы, управления изменением характеристик каждой конфигурируемой единицы; накопления и хранения истории этих изменений, восстановления текущего состояния всего проекта в целом, проверки целостности проекта и его соответствия требованиям". Стоит заметить, что обновление стандарта IEEE привело к глобализации понятий -- если в прежней его редакции речь шла именно об управлении программным проектом, то теперь область применимости определения стала несоизмеримо шире, а аббревиатура меньше на одну букву -- вместо SCM появилась более общая CM (Configuration Management).

Британский стандарт BS-6488, в свою очередь, дает следующее определение CM: "Дисциплина, идентифицирующая все компоненты и их взаимосвязь в развивающейся эволюционным путем системе в целях поддержания целостности и управляемости проекта системы на протяжении всего ее жизненного цикла".

В книге, изданной в 1996 г., Вэйн Бабич (Wayne Babich) куда менее формально, зато конкретно по отношению к проектированию ПО, отразил понятие SCM таким текстом: "В любом командном проекте невозможно полностью избежать несогласованности. Реальная задача -- уменьшить степень этой несогласованности до такого уровня, чтобы работа все-таки могла быть выполнена. Искусство так координировать процесс проектирования программы, чтобы достичь выполнения поставленной задачи, называют управлением конфигурацией. CM -- это искусство выделять, идентифицировать, организовывать и управлять модификациями программы, которые вносятся всей командой разработчиков, и истинное произведение его -- максимальная продуктивность при заданном уровне надежности создаваемой программы".

На перечень всех известных определений можно было бы затратить весь этот номер журнала, автор выбрал же на свое усмотрение наиболее яркие из них, а вот фрагментом "выуженной из пыльных закоулков Internet" статьи о "build and smoke test" этот обзор различных мнений как раз целесообразно закончить, ведь мы имеем дело с точкой зрения практика -- участника одного из самых удачных гигантских коммерческих программных проектов современности. Да, естественно, речь пойдет о Microsoft... Общепринятой практикой в этой компании является ежедневная обязательная проверка программного продукта по методу "а не задымится ли?" (build and smoke). Каждый файл проекта с внесенными за день изменениями транслируется, продукт собирается в исполняемую программу и быстро проверяется относительно простым набором тестов на принципиальную работоспособность. Если продукт "дымится", значит, с изменениями были внесены ошибки. В своей книге "Динамика разработки ПО" Джим МакКарти (Jim McCarthy) пишет так: "Ежедневный тест build and smoke -- это сердцебиение проекта. Если нет сердцебиения -- проект мертв". Ежедневность такой процедуры -- не прихоть и не излишество, по мнению очень многих специалистов, а попытки перевести тесты "build and smoke" на недельный интервал, оказавшиеся провальными, это мнение только подтверждают. Как свидетельствует практика, за неделю отдельные разработчики успевают потерять "пульс проекта" -- слишком велика глубина "отката", выражаемая в чрезмерно большом количестве строк кода...


Словарь SCM

Знание и понимание используемой терминологии -- одна из главных составляющих культуры (например, математической). Сегодня дисциплина SCM настолько важна при коллективной разработке ПО, что знание ее базовых понятий становится полезным не только для программистов, но и для управляющего персонала и обычных пользователей. К сожалению, большинство терминов CM и SCM синтаксически очень близки к общеупотребимым словам, что часто просто заводит в тупик.

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

Ключевой термин CM и SCM -- понятие "конфигурируемой единицы" (Configuration Item, CI). Согласно стандартам IEEE и DoD (Министерства обороны США), CI -- это объединение аппаратных и/или программных средств в одно целое в процессе управления конфигурацией. Так, например, даже готовый "товарный" продукт, управлением конфигурациями которого занялись слишком поздно -- после его создания, может быть "конфигурируемой единицей" (и это подтверждено стандартами). Для сугубо программных разработок есть уточненный термин -- CSCI (Computer Software Configuration Item), "конфигурируемая единица программного обеспечения".

"Управление конфигурацией" (Configuration Control) -- систематическое внесение предложений по изменению "конфигурируемых единиц" (CI), согласование этих предложений, реализация изменений на уровне CI, координация действий разработчиков и управляющего персонала, восстановление всего проекта с учетом внесенных в CI изменений.

"Ось" (Baseline) -- набор спецификаций продукта, формально определенных и одобренных, служащих основой всего хода разработки. "Ось" может изменяться исключительно посредством механизмов "управления конфигурацией". Есть несколько разновидностей "осей". "Предопределенная ось" (Allocated Baseline -- AB) -- это определенный на начальном этапе проектирования и официально одобренный набор спецификаций "конфигурируемых единиц", являющийся частью высокоуровневых спецификаций. Главная роль AB -- фиксация "архитектуры" проекта в виде описания множеством CI. Второстепенная роль -- критериальная, ведь подобный набор спецификаций позволяет оценить степень соответствия проекта требованиям в любой момент времени, т. е. определить готовность проекта как продукта/товара. Как только результат проектирования в своем жизненном цикле достигает точки "товарной готовности", его "координатная система" несколько изменяется, в ней появляется "ось продукта" (Product Baseline -- PB) -- набор спецификаций на продукт как "конфигурируемую единицу".

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

"Ревизия" (Revision) -- это разновидность версии, обычно не вносящая существенных изменений в конфигурацию, направленная, например, на устранение ошибок.

"Вариант" (Variant) -- полноценная "альтернативная" версия, в которой могут быть изменены, например, высокоуровневые спецификации.

"Дельта" (Delta) -- техника хранения "версий" способом записи только информации о различиях. Существуют так называемые "упреждающие дельты" (forward deltas) -- информация о различиях, на основе которой можно получить новую версию из старой, и "реверсивные дельты" (reverse deltas) -- позволяющие "продвигаться" по истории версий как вперед (от старой к новой), так и в обратном направлении.

"Рабочий продукт" (Work Product) -- любой артефакт как результат применения дисциплины SCM к процессу разработки.


Сценарий SCM

Вся жизнь -- театр, а люди в нем актеры...
В. Шекспир

Из приведенных выше определений и "словаря" уже понятно, что SCM -- это серьезный человеко-машинный "спектакль", на сцене которого есть место для инструментальных средств, о чем мы поговорим позже, но главное в нем -- игра и роли актеров.

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

Управляющий проектом (Project Manager -- PM), что очевидно, отвечает за весь проект, но в его роли главное -- превращение ярких личностей всех индивидуумов -- участников проекта -- в нечто единое целое, в команду. В общем, неформальное определение Вэйна Бабича, приведенное ранее, лучше всего характеризует деятельность управляющего проектом. И несмотря на то, что мы вторгаемся в область искусства, здесь есть свои цели и задачи. Цель PM -- создание продукта в заданные сроки и c заданными показателями качества. Для выполнения цели PM, как и любой актер, должен решать и ряд сугубо технических задач: выполнять мониторинг хода развития проекта, выявлять и устранять высокоуровневые проблемы при решении проектных задач. Для этого PM должен располагать механизмами, позволяющими в любой момент времени как определить текущее состояние проекта по заданным самим PM критериям, так и получить обзор, характеризующий ход разработки. Базовый сценарий SCM не предусматривает возможностей прогнозирования и работы в стиле "что будет, если?" -- слишком сложны и непредсказуемы частные вопросы процесса проектирования программного обеспечения, чтобы можно было безопасно играть в подобные игры.

Управляющий процессом конфигурации (Configuartion Manager), в свою очередь, играет одновременно роли "посредника" между высокоуровневыми задачами, которые ставит PM, и конкретными политиками и проектными процедурами, и "гаранта" главного закона проектирования -- изменения не должны приводить к принципиальной потере работоспособности или целостности проекта. Из "театрального зала" управляющий процессом конфигурации кажется брюзжащим бюрократом -- его игра основана на официальных запросах, согласованиях и утверждениях -- всех атрибутах "волокиты", а ее никто не любит. Естественно, перечисленные бюрократические механизмы не обязательно должны быть "волокитой", но это, опять же, область искусства.

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

Если во всем спектакле хоть кто-либо бездарно играет свою роль... результат предрешен так же, как предрешен результат бездарного блок-бастера, создатели которого пытаются "вытянуть" свое детище парой имен модных актеров. По крайней мере, если мы говорим о результате, как о произведении искусства...


Долой рутину с театральных подмостков!

Вооружившись такой короткой "программкой", мы уже можем посмотреть "из зала" на ряд ярких "спектаклей" по-новому. Вот, например, ставший знаменитым и не сходящий 30 лет со сцены спектакль, метко, но длинно названный Ф. Бруксом "...программы, вызвавшие восхищение страстных поклонников, являются продуктом одного или небольшого числа выдающихся проектировщиков...". Естественно, речь идет об ОС Unix. Если судить по сценарию SCM, этот "спектакль" действительно уникален -- в нем исключительно удачно сочетаются гениальность маленького авторского коллектива, неожиданные творческие находки, обеспечившие высокую активность всех участников спектакля, включая пользователей, которые буквально "пожизненно" вовлечены в действо. И даже невзирая на то, что по полноценному SCM-сценарию Unix-спектакли начались поздно -- на этапе жизненного цикла этой системы, когда она уже превратилась в товар, несмотря на то, что далеко не все "спектакли" по сей день проводятся по SCM-сценарию, система продолжает жить.

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

О последнем -- недооценке роли пользователей в жизненном цикле программного продукта, следует сказать особо. Увеличение пользовательской аудитории, неизбежно связанное с ростом популярности продукта, -- несомненно, положительное явление с коммерческой точки зрения. Но у всякой медали есть своя оборотная сторона, и в данном случае производитель неизбежно сталкивается с проблемой пассивности неподготовленных пользователей, за счет которых только и может расти аудитория. Следовательно, необходимо увеличивать затраты на тестирование, совершенствовать его механизмы, ведь ориентированное на массовую аудиторию ПО обычно исключительно сложно в реализации. К сожалению, этот аспект абсолютно игнорируется сообществом разработчиков альтернативных систем, в первую очередь -- из мира Open Source. Стремление привлечь пользователей, окупаемое сложностью ПО, -- это весьма опасная игра, где импровизациям "базарного стиля проектирования" места не остается. Впрочем, ведущие проекты Open Source, непосредственно связанные с пользовательским ПО, во многом приближаются к каноническому сценарию SCM (например, проект KDE).

И наконец, главное. Если вспомнить общность, присущую определению CM, данному обновленной редакцией стандарта IEEE, напрашивается вывод, что для "CM-спектаклей" на самом деле может быть намного больше сцен, чем узкие подмостки "проектирования программ". Фактически в любой области деятельности, где есть коллективная работа над многоверсионным интеллектуальным продуктом, применимы и дисциплина CM, и соответствующие инструментальные средства. Будь то создание и поддержание в актуальном состоянии "контента" Web-портала, осуществляемое группой авторов, коллегиальное администрирование сложных сетевых сервисов, написание книги (сборника) коллективом авторов или ведение технической документации -- все эти весьма нетривиальные в управлении процессы являются благодатной почвой для CM-сценария.