Лучший подход для проведения аудита физической конфигурации CMMI?

Question

Организация, в которой я сейчас работаю, для организации, которая движется по всему миру CMMI документирования всего. Мне было назначено (вместе с еще одним человеком) название Configuration Manager. Поздравляю меня правильно.

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

Наш проект - это относительно небольшое веб-приложение с написанным на Java. Типы файлов, с которыми мы работаем: java, jsp, xml, файлы свойств и пакеты sql.

Проблема, которую я имею (и выразил, но, похоже, игнорирую), заключается в том, как я должен физически войти на рабочий сервер и проверить версии файлов, и даже если бы я мог, это заняло бы смешное количество времени?

Версии файла даже не находятся в данный момент в файле (то есть в комментарии или что-то в этом роде). Было предложено разместить видимые номера версий на каждом экране, который также виден пользователям. Я тоже подумал, что это смешно, поскольку сами экраны представляют лишь небольшую часть кода, который мы поддерживаем.

В настоящее время мы используем Netbeans для нашей среды IDE и Serena Dimensions в качестве инструмента управления версиями.

Я специально ищу идеи о том, как выполнить этот аудит, надеюсь, более автоматизированным способом, который будет точным и не займет много времени.

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

Есть идеи получше. Я знаю, что это уже было сделано, и мне кажется безумным, что я не нашел никаких других ресурсов.

Answer 1

Вы можете вычислить хеш SHA1 исходных файлов на производственном сервере и сравнить это значение хеша с версиями, хранящимися в системе контроля версий. Если вы можете найти тот же хеш в управлении исходным кодом, то вы знаете, какая версия находится в производстве. Если вы не можете найти тот же хеш в управлении исходным кодом, то в производстве есть неотслеживаемые модификации, и ваше новое название должности оправдано. :)

Answer 2

Типичная организация ловушек, в которую попадает CMMI, пытается переусердствовать во всем. Если бы я мог предложить что-нибудь, это было бы начинать с малого и делать только то, что вам нужно. Поэтому рассмотрим любые проблемы, которые у вас могли возникнуть в области CM, очевидно.

CMMI описывает, что должна делать организация, но оставляет за вами КАК. Спецификацию CMMI , глава 2, стоит прочитать - в ней описаны обязательные, ожидаемые и информативные компоненты спецификации - в основном, требуются цели, ожидаемые практики, а все остальное является информативным. Это означает, что есть только небольшая часть спецификации, которую оценщик CMMI может непосредственно потребовать - цели. На уровне практики допустимо иметь либо описанные практики, либо , либо приемлемые альтернативы .

В случае аудитов конфигурации целью SG3 является "Целостность базовых показателей установлена ​​и поддерживается". В SP3.2 говорится: «Выполнять аудит конфигурации для поддержания целостности базовых показателей конфигурации». Здесь ничего не сказано о том, как часто это делается или сколько времени они могут занять.

В моей предыдущей организации FCA / PCA обычно выполнялись только как часть процесса выпуска продукта, и мы использовали ClearCase в качестве инструмента управления версиями с метками, нанесенными по всей базе кода для определения базовых показателей. У нас не было номеров версий во всех исходных файлах, и при этом у нас не было номеров версий на всех экранах продуктов - деятельность CM выполнялась правильно и была подкреплена аудитами, и это никогда не было проблемой при любой оценке CMMI. , Мы могли бы использовать дельты между метками, чтобы посмотреть, какие файлы изменились, выполнить различия, чтобы увидеть реальные изменения кода. Важной частью процесса является возможность связать эти изменения с требованием / отчетом об ошибке / независимо от причины, которая инициировала изменение.

Наш аудит действительно использовал сценарии для автоматизации процесса, но это были собственные сценарии, разработанные специально для ClearCase - в основном они перечисляли бы все файлы, их версии в системе CM и элемент baseline / config, к которому они относились. принадлежал.

Answer 3

вы не можете использовать свой источник контроля для этого? если вы развертываете версию и помечаете свой sourcecontrol этим развертыванием, вы можете проверить ее по системе контроля версий