CMMI 물리적 구성 감사를 수행하는 최선의 접근 방식은 무엇입니까?

Question

제가 현재 일하고 있는 조직은 모든 ​​것을 문서화하는 전체 CMMI 세계로 나아가고 있는 조직입니다.나는 (다른 한 사람과 함께) 구성 관리자라는 직함을 받았습니다.축하드립니다.

업무의 일부는 물리적 구성 감사를 정기적으로 수행하는 것입니다(아직도 정기적으로 정의하고 있으며 분기별 또는 월별로 수행).이는 기본적으로 프로덕션에 배포된 소스 코드 버전을 프로덕션의 소스 코드 버전으로 확인하는 것입니다.

우리 프로젝트는 Java로 작성된 비교적 작은 웹 애플리케이션입니다.우리가 작업하는 파일 형식은 java, jsp, xml, 속성 파일 및 SQL 패키지입니다.

제가 겪고 있는 문제(표현했지만 무시되는 것 같음)는 어떻게 프로덕션 서버에 물리적으로 로그온하여 파일 버전을 확인해야 하는지, 그리고 가능하더라도 엄청나게 많은 시간이 걸릴 것이라는 점입니다.

파일 버전이 현재 파일에도 없습니다(예:댓글 등으로).사용자에게도 표시되는 각 화면에 눈에 보이는 버전 번호를 배치하는 것이 제안되었습니다.화면 자체는 우리가 유지 관리하는 코드의 작은 부분만을 나타내기 때문에 나는 이것이 터무니없다고 생각했습니다.

현재 우리가 사용하는 도구는 IDE용 Netbeans와 버전 관리 도구인 Serena Dimensions입니다.

저는 특히 정확하고 시간 소모가 없는 더욱 자동화된 방식으로 이 감사를 수행하는 방법에 대한 아이디어를 찾고 있습니다.

내 생각은 현재 해당 파일의 버전 번호를 포함하는 각 파일의 상단에 주석을 추가하고, 프로덕션 빌드를 생성하여 XML 파일을 생성할 때 실행되는 스크립트 또는 각 파일의 파일 이름과 버전 파일을 포함하는 유사한 것을 추가하는 것입니다. 빌드에 파일을 넣으세요.그런 다음 감사를 수행해야 할 때 프로덕션 서버로 이동하여 정보가 포함된 xml 파일을 가져오고 이를 프로덕션에 있다고 생각되는 것과 프로그래밍 방식으로 비교한 후 보고서를 출력합니다.

더 나은 아이디어.나는 이 작업이 이미 수행되어야 한다는 것을 알고 있으며 다른 리소스를 찾지 못했다는 사실이 나에게는 미친 것처럼 보입니다.

Answer 1

프로덕션 서버에서 소스 파일의 SHA1 해시를 계산하고 해시 값을 소스 컨트롤에 저장된 버전과 비교할 수 있습니다. 소스 컨트롤에서 동일한 해시를 찾을 수 있다면 프로덕션에 어떤 버전이 있는지 알 수 있습니다. 만약 너라면 캔트 소스 컨트롤에서 동일한 해시를 찾으면 생산에 추적되지 않은 수정이 있으며 새 작업 제목이 정당화됩니다. :)

Answer 2

CMMI에 빠지는 전형적인 함정 조직은 모든 ​​것을 과도하게 하려고 합니다.제가 제안할 수 있는 것이 있다면 작게 시작하여 필요한 것만 수행하는 것입니다.따라서 이전에 CM 영역에서 겪었을 수 있는 문제를 고려하십시오.

CMMI는 조직이 수행해야 하는 작업을 설명하지만 작업 방법은 사용자에게 달려 있습니다.그만큼 CMMI 사양, 2장은 읽을 가치가 있습니다. 사양의 필수, 예상 및 정보 구성 요소를 설명합니다. 기본적으로 목표가 필요하고, 예상되는 사례가 있으며, 그 밖의 모든 내용은 유익합니다.이는 CMMI 평가자가 직접 요구할 수 있는 사양의 작은 부분, 즉 목표만 있음을 의미합니다.실무 수준에서는 설명된 관행 중 하나를 수행하는 것이 허용됩니다. 또는 허용 가능한 대안 그들에게.

구성 감사의 경우 목표 SG3은 "기준의 무결성이 확립되고 유지됩니다"입니다.SP3.2는 "구성 기준의 무결성을 유지하기 위해 구성 감사를 수행"합니다. 여기에 얼마나 자주 이루어 지거나 얼마나 오래 걸릴 수 있는지에 대해 언급 한 것은 없습니다.

이전 조직에서 FCA/PCA는 일반적으로 제품 출시 프로세스의 일부로만 수행되었으며, ClearCase를 버전 관리 도구로 사용했으며 기준선을 정의하기 위해 코드베이스 전체에 레이블을 적용했습니다.모든 소스 파일에 버전 번호가 없었으며 모든 제품 화면에 버전 번호도 없었습니다. CM 활동은 올바른 일을 하고 있었고 감사를 통해 뒷받침되었으며 이는 CMMI 평가에서 결코 문제가 되지 않았습니다. .레이블 간의 델타를 사용하여 어떤 파일이 변경되었는지 확인하고, diff를 수행하여 실제 코드 변경 사항을 확인할 수 있습니다.프로세스의 중요한 부분은 해당 변경 사항을 요구 사항/버그 보고서/변경을 시작한 이유에 다시 연결할 수 있다는 것입니다.

감사에서는 프로세스를 자동화하기 위해 스크립트를 사용했지만 이는 내부에서 개발된 스크립트로 ClearCase에만 적용되었습니다. 기본적으로 모든 파일, CM 시스템의 해당 버전 및 해당 파일이 속한 기준선/구성 항목을 나열합니다.

Answer 3

소스 컨트롤을 사용할 수 없습니까? 해당 배포로 버전을 배포하고 SourceControl을 태그하는 경우 소스 제어 시스템에 대해 확인할 수 있습니다.