구성 관리 (구성 관리) 상세 정보 daquan

< /p>

CM (구성 관리) 은 기술 또는 관리 수단을 통해 소프트웨어 제품 및 개발 프로세스 및 수명주기를 제어하고 규제하는 일련의 조치입니다. 구성 관리의 목표는 소프트웨어 제품의 진화 과정을 문서화하여 소프트웨어 개발자가 소프트웨어 수명 주기의 모든 단계에서 정확한 제품 구성을 얻을 수 있도록 하는 것입니다. 기본 소개 중국어 이름: 구성 관리 외국어 이름: 구성 관리 설명: 기술을 통한 소프트웨어 제품 제어: 소프트웨어 개발 소개, 기능, 병렬 개발 지원, 개정 관리, 버전 관리, 관리 프로세스, 구축 관리, 프로세스 제어, 코드 * * 버전 관리, 변경 관리, 구성 감사, 구현, 경험, 비용 절감, 지식 기반 구축 촉진, 사양 관리, 정수, 버전 관리, 변경 제어, 구성 제어, 상태 보고, 구성 감사, 구성 관리 비즈니스 모델, CICO 모델, 조직 모델, 길이 일관성, 추적 가능성, 제품을 사용자의 요구에 크게 맞출 수 있습니다. 소프트웨어 수정 사항 및 각 수정으로 생성된 소프트웨어 구성 요소를 제어, 기록, 추적하여 소프트웨어 제품 관리 기능을 제공합니다. 1970 년대 초반 캘리포니아 대학의 Leon Presser 교수는 변경 및 구성 제어 개념을 제시한 논문을 저술한 뒤 1975 년 SoftTool 이라는 회사를 설립하여 자체 구성 관리 도구인 CCC 를 개발했습니다. 이는 최초의 구성 관리 도구 중 하나입니다. 이후 소프트웨어 개발 규모가 커지면서 소프트웨어 구성 관리의 중요성을 인식하는 기업과 팀이 늘고 있으며, 해당 소프트웨어 구성 관리 도구도 우후죽순처럼 생겨나고 있습니다. Marc Rochkind 의 SCCS(Source Code Control System) 와 Walter Tichy 의 RCS(Revision Control System) 가 대표적이다. 이 두 도구는 향후 구성 관리 도구의 발전에 큰 역할을 했다 소프트웨어 개발 프로세스 및 프로젝트 관리 프로세스에서 구성 관리의 역할 소프트웨어 시스템의 복잡성과 사용자 요구 사항, 소프트웨어 업데이트의 빈도가 증가함에 따라 구성 관리는 소프트웨어 수명 주기 동안 중요한 제어 프로세스가 되어 소프트웨어 개발 과정에서 점점 더 중요한 역할을 하고 있습니다. 좋은 구성 관리 프로세스는 소프트웨어 개발 및 유지 관리의 모든 측면을 포괄할 수 있으며, 소프트웨어 개발 프로세스의 거대한 관리, 즉 프로젝트 관리도 중요한 지원 역할을 합니다. 우수한 구성 관리를 통해 소프트웨어 개발 프로세스를 보다 예측 가능하게 하고, 소프트웨어 시스템을 반복 가능하게 하며, 사용자와 주관 부서에서 소프트웨어 품질 및 개발 팀을 사용할 수 있다는 확신을 가질 수 있습니다. 소프트웨어 구성 관리의 최종 목표는 소프트웨어 제품을 관리하는 것입니다. 소프트웨어 제품은 사용자의 변화하는 요구에 따라 끊임없이 변화하기 때문에, 제품의 효과적인 통제와 추적을 보장하기 위해 구성 관리 프로세스는 정적이고 성형된 제품만 관리할 수 없습니다. 역동적이고 성장하는 제품을 관리해야 합니다. 구성 관리는 소프트웨어 개발 프로세스와 밀접하게 연관되어 있음을 알 수 있습니다. 구성 관리는 사용자가 제시한 요구 사항 관리, 구현 모니터링, 최종 사용자 요구 사항이 제품의 각 버전에 구현되도록 보장하고 제품 출시 및 사용자 지원 등에 도움을 주어 사용자의 새로운 요구 사항을 반영하고 새로운 개발 주기를 추진해야 합니다. 구성 관리 프로세스의 제어를 통해 소프트웨어 제품에 대한 사용자의 수요는 일반 제품에 대한 주문처럼 엄격한 프로세스를 따르고, 제어된 생산 라인을 거쳐 최종적으로 제품을 형성하여 세트 사용자에게 판매된다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어)

또 다른 관점에서 볼 때, 제품 개발의 여러 단계에서 일반적으로 서로 다른 임무가 있으며, 서로 다른 역할에 의해 담당되고, 각 역할의 책임은 명확하고, 분명하지만, 동시에 앞뒤가 맞물려 서로 조화를 이룹니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 좋은 구성 관리 프로세스는 각 역할의 동작을 규제하는 데 도움이 되며 역할 간 임무 전달을 위한 원활한 결합을 제공하여 전체 개발 팀이 하나의 교향악단처럼 조화롭고 복잡하게 행진할 수 있도록 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 구성 관리 프로세스는 제품 개발 프로세스, 개발자 및 최종 제품에 직접 연결되므로 프로젝트 임원의 관심사이므로 구성 관리 시스템도 소프트웨어 프로젝트 관리에서 중요한 역할을 합니다. 구성 관리 프로세스의 진화된 제어, 보고 기능을 통해 프로젝트 관리자는 프로젝트 진행 상황, 개발자의 부하, 생산성 및 제품 품질 상태, 제공 날짜 등을 더 잘 이해할 수 있습니다. 관리 프로세스에 의해 규정된 작업 흐름과 명확한 분업을 함께 구성하면 관리자가 개발자 흐름의 딜레마에 대처할 수 있어 새로운 구성원이 신속하게 작업 인계를 수행하고 인력 이동으로 인한 손실을 최소화할 수 있습니다. 기능 동시 개발 지원은 개발 및 유지 관리를 위해 개발자가 동일한 소프트웨어 모듈에서 동시에 작업하면서 동일한 코드 부분을 다르게 수정할 수 있도록 요구합니다. 지리적으로 분산된 개발 팀도 통제력을 잃지 않고 함께 작업할 수 있습니다. 개정 관리는 각 변경의 제작자, 시간 및 원인을 추적하여 문제 및 결함 파악 속도를 높입니다. 버전 관리는 소프트웨어 시스템의 모든 과거 버전을 간단하고 명확하게 재현할 수 있습니다. 제품 배포 관리: 소프트웨어 배포 계획, 사전 맞춤형 수명 주기 또는 관련 품질 프로세스와 일치하는 관리, 계획 소프트웨어 변경 프로젝트 관리자는 언제든지 프로젝트의 상태를 명확하게 파악할 수 있습니다. 구성 관리 프로세스 구축 관리 소프트웨어 저장소 기반 버전 관리 기능을 구축하여 빌드 프로세스를 자동화합니다. 프로세스 제어는 액세스 권한 제어, 개발 규칙 구현 등을 포함한 개발 사양을 구현합니다. 변경 요청 관리: 개발 과정에서 발생하는 결함 (Defect), 기능 향상 요청 (RFE) 또는 임무 (Task) 를 추적, 관리, 커뮤니케이션 및 공동 작업 강화, 변경 상태 파악 등의 기능을 제공합니다. 코드 * * * * 개발자들이 자체 개발 리소스를 즐길 수 있는 좋은 저장 및 액세스 메커니즘을 제공합니다. 프로세스 개발 구성 관리 계획 구성 관리자는 구성 관리 하드웨어 및 소프트웨어 리소스, 구성 항목 계획, 기준 계획, 제공 계획, 백업 계획 등을 포함한 구성 관리 계획을 개발합니다. CCB 가 계획을 승인합니다. 라이브러리 구성 관리 구성 관리자는 프로젝트에 대한 구성 라이브러리를 작성하고 각 프로젝트 멤버에게 권한을 지정합니다. 각 프로젝트 멤버는 자신의 허가 작업에 따라 라이브러리를 구성합니다. 구성 관리자는 불필요한 정보 파일 정리, 구성 라이브러리 백업 등과 같은 구성 라이브러리를 정기적으로 유지 관리합니다. 버전 관리 프로젝트 개발 과정에서 대부분의 구성 항목을 여러 번 수정해야 최종 확정할 수 있습니다. 구성 항목을 수정하면 새 버전이 생성됩니다. 새 버전이 반드시 이전 버전보다' 좋다' 는 보장은 없기 때문에, 이전 버전을 버릴 수 없다. 버전 관리의 목적은 특정 규칙에 따라 구성 항목의 모든 버전을 저장하고, 버전 손실이나 혼동 등을 방지하고, 구성 항목의 모든 버전을 빠르고 정확하게 찾는 것입니다. 구성 항목의 상태는 초안, 공식 게시 및 수정됨의 세 가지가 있으며, 이 분야는 구성 항목의 상태 변경 및 버전 번호에 대한 규칙을 설정합니다. 변경 제어 프로젝트 개발 과정에서 구성 항목을 변경하는 것은 거의 불가피합니다. 변경 제어의 목적은 구성 항목이 임의로 수정되는 것을 방지하기 위한 것입니다. 초안 상태의 구성 항목을 수정하는 것은 "변경" 으로 간주되지 않으며 CCB 의 승인이 필요하지 않습니다. 수정자는 버전 제어 규칙에 따라 실행됩니다. 구성 항목의 상태가 "공식 발표" 가 되거나 "동결" 된 후에는 누구도 임의로 수정할 수 없으며, "신청 → 승인 → 변경 수행 → 재검토 → 종료" 규칙에 따라 실행해야 합니다. 구성 감사 프로젝트 구성원, 구성 관리자, CCB 를 포함한 모든 사람이 구성 관리 사양을 준수하도록 품질 보증 담당자는 정기적으로 구성 관리 작업을 감사해야 합니다.

구성 감사는 "프로세스 품질 검사" 활동으로 품질 보증 담당자의 업무 책임 중 하나입니다. 구성 관리 시스템을 구현하기 위한 일반적인 단계와 고려 사항은 다음과 같습니다 .1. 네트워크 개발 환경을 계획하고 조정하는 것이 구성 관리 시스템을 구현하기 위한 전제 조건입니다. 이 단계에서 구성 관리 시스템을 계획하려면 주로 네트워크 대역폭, 토폴로지 서버 선택, 명명 사양 저장소의 위치 지정 개발자 및 그룹 명명 규정 등 2. 설계 구성 관리 라이브러리는 프로젝트 개발 요구 사항에 따라 개발 자원의 스토리지 모델을 설계하고, 좋은 스토리지 모델은 관리 부담을 줄이고, 구성 관리 라이브러리의 액세스 성능을 향상시키고, 액세스 권한을 쉽게 제어할 수 있도록 합니다 3. 구성 관리 시스템의 역할 정의 이 단계에서 구성 관리와 관련된 모든 역할 (모든 역할에 해당하는 활동 포함) 을 결정해야 합니다. 개발 과정에서 개발자는 여러 역할을 동시에 수행할 수 있지만 한 번에 하나의 역할로만 작업을 수행할 수 있습니다. 일반 구성 관리에서 사용되는 역할은 다음과 같습니다. 프로젝트 관리자: 구성 관리에서 프로젝트 관리자의 역할은 구성 관리자, 시스템 관리자 및 시스템 아키텍처 설계자의 도움을 받아 프로젝트의 조직 구조 및 구성 관리 정책을 개발하는 것입니다. 이러한 작업으로는 개발 하위 시스템 사용자 정의, 액세스 제어 사용자 정의, 공통 전략 개발, 통합 이정표 개발, 시스템 통합 등이 있습니다. 구성 관리자: 구성 관리자의 역할은 프로젝트 관리자가 설정한 개발 조직 구조 및 정책에 따라 구성 관리 환경을 구현 및 유지 관리하는 것입니다. 주요 임무는 구성 관리 라이브러리 생성, 저장소에 대한 일상적인 백업 및 복구, 구성 관리 환경 유지 관리, 구성 관리 관련 사용자 관리 등입니다. 소프트웨어 개발자: 소프트웨어 개발자는 프로젝트의 개발 및 구성 관리 전략에 따라 개발 작업을 작성, 수정 및 테스트합니다. 통합자: 소프트웨어를 통합하여 적절한 기준 또는 릴리스 버전을 형성합니다. QA 직원: 현재 프로젝트의 상태를 추적하고, 테스트하고, 오류를 보고하고, 수리 결과를 검증하는 소프트웨어 구성 관리에 대해 더 잘 알고 있어야 합니다. 4. 구성 관리 프로세스 개발 이것은 구성 관리 구현의 중요한 단계이며, 주요 목적은 프로젝트 개발의 필요에 따라 개발을 더 잘 지원할 수 있도록 적절한 구성 관리 프로세스를 개발하는 것입니다. 주요 활동은 다음과 같습니다. 맞춤형 병렬 개발 전략: 합리적인 병렬 개발 전략에는 프로젝트의 복잡성과 요구 사항 조정, 분기 유형 및 메타데이터 통합 생성, 개발 중 변경 통합을 위한 효과적인 사양 개발 등이 있어야 합니다 릴리스 버전 관리: 소프트웨어 개발 프로세스의 주요 활동 중 하나는 가공소재의 관련 버전을 추출하여 소프트웨어 시스템의 단계 버전 또는 릴리스 버전을 형성하는 것입니다. 이를 일반적으로 안정적인 베이스라인이라고 합니다. 안정적인 베이스라인은 새로운 개발 활동의 시작을 나타내며, 일련의 맞춤형 활동을 통해 새로운 안정적인 베이스라인이 생성됩니다. 이 기능을 효과적으로 활용하면 프로젝트 개발 프로세스 중 처음부터 끝까지 가공소재 버전 간의 연관을 관리하고 추적할 수 있습니다. 일반적으로 구성 관리 시스템을 구현하기 위해 관계자들은 다음과 같은 교육을 받아야 합니다. 구성 관리 관리자 교육: 구성 관리자를 위한 주요 학습 구성 관리 도구 관리 관련 내용. 개발자 교육: 개발자를 위해 구성 관리 도구 개발과 관련된 일반적인 작업을 주로 학습합니다. 관리 프로세스 교육: 전체 인력을 대상으로 구성 관리 전략 및 프로세스, 개발 관리, 프로젝트 관리와 통합하는 방법을 이해하는 것입니다. 경험 구성 관리를 중심으로 전 세계 소프트웨어 엔지니어링 연구에 주력하는 일부 기업들은 ISO 9000 에 대한 심층적인 이해를 바탕으로 ISO 9000 구성 관리 표준을 준수하는 다양한 도구 소프트웨어 (예: INTERSOLV 의 PVCS, Rational 의 Clear Case 등) 를 출시했습니다. 이러한 구성 관리 도구는 소프트웨어 표준화, 엔지니어링, 자동화의 필요성을 지향하며, 개발팀이 과학 관리 수준을 높여 엔지니어링 효율성을 높이고 엔지니어링 비용을 절감할 수 있도록 지원합니다.

이제 PVCS 를 예로 들어 실제 경험과 함께 구성 관리 구현의 이점에 대해 논의합니다. 비용 절감 1. 개발 주기 단축 PVCS 의 Version Manager 를 사용하여 프로그램 리소스를 버전 관리 및 추적하고, 회사의 코드 지식 기반을 구축하고, 개발 프로세스의 각 프로세스 버전을 저장하여 코드 재사용률을 크게 높이고, 여러 버전을 동시에 유지 관리하고, 새 버전을 개발할 수 있습니다. 동시에 프로젝트 관리자는 Version Manager 를 통해 프로젝트 개발 로그를 볼 수 있고, 테스터는 개발 로그와 버전에 따라 소프트웨어를 테스트할 수 있으며, 엔지니어는 Version Manager 에서 서로 다른 실행 버전을 얻을 수 있으며, Version Manager 는 웹 서버에 설치하여 개발자가 현장에 직접 방문하지 않고도 최신 버전에 액세스할 수 있습니다. Tracker 를 사용하여 개발 그룹 간의 문제 추적 및 메시지 통신을 구축함으로써 Notify 모듈과 e-메일을 결합하여 개발 그룹 간의 커뮤니케이션을 크게 강화했습니다. Reporter 모듈은 발견된 문제를 정리하여 보고서 형식으로 분류하여 개발 지침으로 사용할 수 있습니다. PVCS 의 두 가지 주요 모듈로, 과학적 적용은 개발 효율성을 크게 향상시키고, 코드 적용, 의사 소통 부족, 개발 무질서의 혼란을 방지하며, 회사의 기존 지식 기반을 활용할 경우 생산성을 높이고 개발 주기를 단축할 수 있습니다. 2. 시공비용 절감 PVCS 를 이용한 소프트웨어 구성 관리 후 개발 관리 사양을 세우고 버전 관리 파일을 회사 내부의 웹 서버에 연결하고 내부적으로 Netscape 를 통해 Version Manager 에 직접 액세스하며 엔지니어는 원격으로 인트라넷에 들어가 필요한 최신 버전을 얻습니다. 개발자는 현장을 떠날 필요가 없습니다. 현장 엔지니어는 상대 시스템 관리자를 통해 피드백을 수집하고 사내 개발팀 프로젝트 관리자에게 서면으로 제출하고, 개발팀 내부에서 수정 여부를 논의하고, 서면 답변을 합니다. 이렇게 하면 여러 프로젝트 포인트를 동시에 반향시켜 개발자가 각 프로젝트 지점, 분산력, 인력 부족 문제를 분배하지 못하게 하는 동시에 대량의 여행 경비를 절약할 수 있습니다. 지식 기반 구축에 유리하다 1. 코드 개체 라이브러리 소프트웨어 코드는 소프트웨어 개발자의 정신노동의 결정체이자 소프트웨어 회사의 귀중한 재산이다. 장기 개발 과정에서 형성된 각종 코드 개체는 부품 가공물처럼 빠른 생성 시스템의 일부이다. 장기적으로 볼 때, 한 개발자가 직장을 그만두면, 원래 만든 코드는 기본적으로 쓰레기가 되어 아무도 묻지 않는다는 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 예술명언) 그 이유는 각 사람의 유용한 대상을 전문적으로 관리하지 않고, 그 사용 범위를 회사 1 급으로 확대하고, 규범화하고, 설명하고 보급하기 때문이다. Version Manager 는 객체 관리를 위한 플랫폼 및 웨어하우스를 제공하여 회사 수준의 코드 객체 라이브러리를 쉽게 설정할 수 있도록 합니다. 2. 비즈니스 및 경험 라이브러리는 PVCS Version Manager 의 주석 및 Tracker 를 통해 전체 개발 로그 및 문제 집합을 구성할 수 있으며, 개발의 전체 프로세스를 텍스트로 동반하고, 누군가의 이전에 따라 사라지며, 회사에서 업무 경험을 쌓는 데 도움이 되며, 버전 수정이나 버전 업그레이드에 중요한 지도 역할을 합니다. 규범 관리 1. 양적 업무량 평가 전통적인 개발 관리에서 업무량은 항상 가늠할 수 없는 지표로, 개발자에 의해 스스로 파악되고, 임의성이 상당히 크며, 임원에 의해 파악되고, 주관성이 너무 강하다. PVCS 관리를 통해 개발자는 매일 퇴근하기 전에 수정된 파일 Check In 을 수정하며, 당일 수정된 세부 사항에 대해 설명합니다. 이 설명은 작업량의 척도로 사용될 수 있습니다. 2. 사양 테스트가 PVCS 를 채택한 후, 테스트는 실제 작업을 수행했으며, 테스터는 매일 수정된 세부 묘사에 따라 매일 작업에 대한 구체적인 테스트를 수행하고 테스터에게도 평가성이 있어 고리가 맞물려 작업의 임의성을 크게 줄였다.

3. 조정 및 커뮤니케이션 강화 PVCS 채택 후 Version Manager 문서 * * * 향유 및 특정 잠금 메커니즘, 트래커와 e-메일의 통합을 통해 프로젝트 구성원 간의 커뮤니케이션을 크게 강화하여 문제가 있을 경우 적시에 찾아내고, 적시에 수정하고, 적시에 통보할 수 있습니다. 특히 구성 관리에는 제품의 구조 식별, 제품의 구성 요소 및 유형 식별, 고유한 식별자 지정, 어떤 형태로든 액세스 제공 등의 내용이 포함됩니다. 제어: 특정 메커니즘을 통해 구성 항목의 수정을 제어합니다. 상태 보고서: 구성 항목과 메타데이터의 상태를 기록하고 보고합니다. 구성 감사: 제품의 무결성을 확인하고 구성 항목 간의 일관성을 유지합니다. 위 설명에서 알 수 있듯이 구성 관리의 기본 단위는 구성 항목입니다. 철학적 의미에서, 그것은 구성 항목의 세 가지 측면을 기록한다: 어디에서 왔는가? 이 항목은 귀결될 수 있는 질문입니다. (Who) 누가 만들었습니까? (When) 언제 만들었습니까? (Why) 이 구성 항목을 만든 이유는 무엇입니까? 현재 어디에 있습니까? 이 항목은 구성 항목의 현재 저장 위치와 상태를 기록합니다. 어디로 갈까요? 구성 제어를 통해 구성 항목을 올바른 버전으로 "조립" 합니다. 구성 항목은 큰 세분성 또는 작은 세분성일 수 있습니다. 개별 수요를 추적하는 경우 전체 수요 사양 문서를 하나의 구성 항목으로 정의할 필요가 없습니다. 각 수요를 구성 항목으로 정의할 수 있습니다. 소프트웨어 개발 도구도 구성 관리 시스템에 넣으면 구성 항목을 파일 레벨로 정의하는 것은 적절하지 않습니다. 개발 도구의 버전을 추적하기만 하면 전체 구성 도구를 하나의 구성 항목으로 정의할 수 있습니다. 간단히 말해 구성 항목은 파일 레벨 세분성 또는 파일 버전 레벨 세분성일 수 있습니다. 물론 입도가 낮을수록 관리 비용은 높아지지만 구성의 정확도도 높아진다. 전체 SCM 시스템에는 버전 관리, 변경 제어, 구성 제어 및 두 가지 지원 기능인 상태 통계 및 구성 감사의 세 가지 핵심 기능이 있어야 합니다. 버전 관리 버전 (구성 id 라고도 함) 은 특정 객체의 특정 인스턴스에 대한 잠재적 존재를 나타냅니다. 여기서 특정 대상은 버전 유지 관리 도구에서 관리하는 소프트웨어 구성 요소 (일반적으로 소스 파일) 를 나타냅니다. 구체적인 예는 소프트웨어 개발자가 소프트웨어 라이브러리에서 복구한 소프트웨어 구성 단위의 내용과 속성이 있는 실제 복사본을 말합니다. 예를 들어, 원본 파일을 수정할 때마다 새 버전이 생성됩니다. 버전 관리는 소프트웨어 개발 과정에서 작성된 구성 객체의 여러 버전을 관리하여 언제든지 올바른 버전과 버전의 조합을 얻을 수 있도록 하는 것입니다. 현재 이 분야의 일반적인 도구는 VSS 및 CVS 와 같습니다. 변경 제어 변경 제어는 변경 요청 (CR) 분류, 추적 및 관리 프로세스를 통해 이루어집니다. 변경의 기원은 기능 변경과 결함 수정 (Bug-Fix) 의 두 가지입니다. 기능 변경은 특정 기능을 추가하거나 제거하기 위한 것입니다. 결함 패치는 기존 결함을 패치하는 것입니다. 구성 관리 변경 사항을 제어하는 기관을 변경 제어 위원회 (CCB) 라고 합니다. 변경 관리 위원회는 정기적으로 회의를 열어 최근 발생한 변경 요청을 분석, 정리 및 결정해야 합니다. 그리고 일정한 변경 메커니즘을 따라야 한다. 다음은 일반적인 변경 메커니즘입니다. 변경 프로세스가 진행됨에 따라 구성 항목의 상태를 올릴 수 있습니다. 이 방면의 도구는 Bugzilla 이다. 구성 제어 구성 제어를 통해 사용자는 적절한 버전 선택을 통해 특정 속성 (구성) 의 소프트웨어 시스템을 구성할 수 있습니다. 이러한 유연한' 조립' 전략을 통해 구성 관리 시스템은 기존 빌딩 블록 (버전) 을 빌딩 블록처럼 사용하여 다양한 기능을 갖춘 모델로 조립할 수 있습니다. 소프트웨어 제품의 각 버전은 구성 항목 세트 (소스 코드, 문서, 데이터) 의 모음입니다. 구성 제어는 각 구성의 무결성과 정확성을 보장하는 것입니다.

예를 들어, 소프트웨어 버전 32.6 을 게시하려면 소스 코드, 문서, 데이터에 이 버전에 포함되어야 하는 모든 올바른 구성 항목을 체크 아웃해야 합니다. 개발 과정에서, 여러 단계에서 다양한 기준선을 세워야 한다. 베이스라인 작성은 배치 제어 기능의 일반적인 적용입니다. 따라서 베이스라인은 이정표의 의미를 지닌 구성입니다. 일반적인 상용 소프트웨어 구성 관리 도구에는 구성 제어 기능이 있지만 유연성과 정확성은 다릅니다. 상태 보고서 상태 보고서는 소위 4W 라는 질문에 답해야 한다: What: 무슨 일이야? Who: 누가 이 일을 했습니까? When: 이 일은 언제 일어났습니까? Why: 왜 이 일을 합니까? 또한 상태 보고서는 모든 구성 항목과 변경 요청의 상태를 보고할 수 있습니다. 구성 감사 구성 감사는 다음을 검토해야 합니다. 전체 구성 관리 프로세스가 규정 준수 구성 항목이 요구 사항과 일치하는지 여부, 올바른 구성의 구성이 일관성이 있는지 여부 기록 기타 현재 소프트웨어 업계가 품질에 점점 더 많은 관심을 기울이고 있기 때문에 많은 프로젝트가 구성 감사를 위해 품질 보증 부서를 설립하고 있습니다. 따라서 구성 감사는 SQA (소프트웨어 품질 보증) 활동이라고 할 수 있습니다. 구성 관리의 비즈니스 모델 구성 관리 구현은 도구와 사양이라는 두 부분으로 구성됩니다. 소프트웨어 개발 프로세스가 자동화되는 오늘날, 도구 지원 없이 완전한 구성 관리를 구현하는 것은 상상도 할 수 없는 일입니다. 따라서 회사나 프로젝트에 맞는 도구를 선택하는 것이 중요합니다. 구성 관리 시스템에서는 다음 네 가지 모델을 요약할 수 있습니다. 현재 비즈니스 도구는 일반적으로 이러한 모델 중 하나 이상을 사용합니다. CICO 모델 조직 모델 긴 트랜잭션 모델 변경 세트 모델은 비즈니스 모델에 대한 이해를 통해 도구가 회사 또는 프로젝트에 적합한지 여부를 이해하는 데 도움이 됩니다. CICO 모델 CICO 모델은 주로 개별 파일의 버전 관리에 초점을 맞추고 있습니다. 이 그림은 CICO 모델을 지원하는 CM 시스템의 작동 과정을 보여 줍니다. 사용자는 라이브러리 및 파일 시스템을 사용하여 작업합니다. 파일이 버전 지정되고 라이브러리에 저장되고 새 버전의 생성은 라이브러리 도구에 의해 제어됩니다. 그러나 라이브러리는 라이브러리에서 직접 액세스할 수 없으므로 사용자는 파일의 버전을 작업공간으로 체크 아웃 (체크 아웃) 하여 내용을 읽어야 합니다. 변경된 파일을 체크 인 (체크 인) 하여 파일의 새 버전을 생성할 수 있습니다. 이 모델의 대표 도구는 SCCS 와 CVS 입니다. 구성 모델 구성 모델은 CICO 모델에서 자연스럽게 파생되며 구성 요소 버전 다이어그램을 기반으로 하며 저장소 및 작업공간의 개념에 따라 구성 요소 잠금을 동시에 제어할 수 있습니다. 조직 모델은 CM 시스템의 지원을 받아 구성 작성, 관련 내역 정보 관리 및 작업 환경으로 사용 지원을 강화하는 데 중점을 두고 있습니다. 조직 모델의 구성은 시스템 모델과 버전 선택 규칙으로 구성됩니다. 시스템 모델은 시스템을 구성하는 모든 구성요소를 나열합니다. 버전 선택 규칙은 구성을 구성하는 각 구성요소 선택 버전을 나타냅니다. 선택 규칙은 시스템 모델에 사용됩니다. 즉, 구성요소를 버전에 바인딩하는 구성요소 버전을 선택합니다. 이 모델은 개발자가 모델의 구성요소를 기준으로 전체 시스템을 정의하고 각 단계에서 각 구성요소에 적합한 버전을 선택하는 방식으로 작동합니다. 버전 작업은 그림과 같이 작동합니다. CM 지원은 주로 시스템과 해당 구성 요소의 버전 기록을 유지하고 일관성 구성에 맞는 구성 요소 버전을 선택하는 데 관심이 있습니다. 선택한 구성 요소의 버전이 선택한 다른 구성 요소 버전과 일치하는 경우에만 구성 버전으로 간주됩니다. 이 모델의 대표 도구는 CCC 입니다. 긴 트랜잭션 모델 긴 트랜잭션 모델은 주로 일련의 원자 변경을 포함한 시스템 전반의 진화와 팀 개발자가 시스템 변경에 대한 조정을 지원합니다. 개발자는 개별 구성요소가 아닌 구성을 주로 조작합니다. 트랜잭션 제출의 결과는 새 구성 버전이고, 일련의 연속적인 변경 결과는 개발 경로라는 일련의 구성 버전을 생성합니다. 긴 트랜잭션 모델에서 개발자의 주요 작업 대상은 구성이며, 개발자는 먼저 시스템 구성 버전을 선택한 다음 시스템 구조에 중점을 둡니다. 위젯의 버전은 구성에 의해 암시적으로 결정됩니다.

긴 트랜잭션은 작업공간과 동시 제어 시나리오의 두 가지 개념으로 구성됩니다. 작업공간은 저장소 또는 닫힌 작업공간의 고정 구성에서 파생됩니다. 작업공간은 작업 프로파일과 저장된 일련의 프로파일로 구성됩니다. 작업 구성은 구성요소 및 시스템 구조가 동적으로 변경될 수 있는 구성을 나타냅니다. 작업공간을 통한 투명한 라이브러리 액세스를 제공하고, 효율적인 라이브러리 저장 기술을 작업공간에 적용하고, 파생 구성요소의 버전을 관리합니다. 이 모델의 대표 시스템은 NSE 입니다. 변경 세트 모델은 주로 시스템 구성의 논리적 변경 지원에 중점을 둡니다. 이 모델에 도입된 변경 세트는 논리적 변경을 구성하는 다양한 구성 요소 수정 집합을 나타내며, 변경 작성 활동이 완료된 후 논리적 변경 사항에 대한 기록입니다. 이 모델을 지원하는 CM 시스템 사용자는 변경 세트를 직접 조작할 수 있습니다. 변경 세트 모델에서 할당은 베이스라인과 변경 세트 세트로 구성된 것으로 설명할 수 있습니다. 개별 변경 세트를 포함하여 다른 구성에 변경 사항을 전파할 수 있습니다. 개발자는 서로 다른 통합 정책을 사용하여 논리적 변경 세트를 새 시스템 릴리스에 포함시킵니다. 이러한 이점은 분명합니다. 예를 들어, 10 개의 서로 다른 제품 버전을 유지 관리하는 경우 이제 모든 버전에 대해 버그 (Bug) 를 수정해야 합니다. 동일한 도구가 단순히 10 번 반복된다면 분명히 받아 들일 수 없습니다. 변경 세트를 통해 이 논리적 변경 사항을 한 버전에서 다른 버전으로 자유롭게 전달할 수 있습니다. 개발자는 논리적 변경 사항을 추적하고 이러한 변경 사항이 특정 구성에 속하는지 여부를 확인할 수 있습니다. 이 구성 관리 방법은 논리적 변경에 초점을 맞추고 있기 때문에 변경 지향 구성 관리라고 합니다. 다른 세 가지 CM 모델이 사용하는 버전 지향 접근 방식이 구성 요소 및 구성 버전에 초점을 맞추기 때문에 현재 다른 세 가지 CM 모델과는 다릅니다. 단일 위젯의 경우 변경 세트는 두 파일 버전 간의 차이 모음이며 일반적으로 증분 내용을 나타냅니다. 배치의 경우 변경 세트는 두 배치 버전 간의 차이 집합입니다. 이 세트의 차이점은 두 구성 버전 간의 수정된 구성요소 증분 집합, 즉 구성요소 세트의 증분 변경입니다. 변경 지향 관점은 버전 지향 관점과 다릅니다. 두 가지 차이점이 있습니다. 즉, 논리적 변경의 명시적 표현을 통해 개별 구성요소 및 구성과 관련된 변경 세트를 추적할 수 있습니다. 둘째, 단일 변경 세트를 참조하여 구성 관리에 선택적으로 포함시킬 수 있는 이 기능은 유지 관리되는 시스템 구성에 논리적 변경 사항을 전달하는 시스템 진화 관리를 지원합니다. 이 모델의 대표 도구는 UCM 과 SABLIME 입니다. 구성 관리를 위한 클라우드 보안 조치의 가장 중요한 요소는 구성 관리입니다. SaaS 환경에서 구성 관리는 전적으로 클라우드 공급업체가 처리합니다. 가능한 경우 고객은 SSAE (인증 업무 지침 공고) 제 16 호, 서비스 조직 통제 (SOC) 보고 또는 ISO 인증, 클라우드 보안 연합의 보안, 신뢰 및 보증 등록 증명서를 통해 공급자에게 패치 관리 및 구성 관리 관행에 대한 요구 사항을 제시할 수 있습니다. PaaS 환경에서 플랫폼 개발 및 유지 관리는 공급업체가 담당합니다. 응용 프로그램 구성 및 개발 라이브러리 및 도구는 기업 사용자가 관리할 수 있으므로 보안 구성 표준은 여전히 내부 정의 범주에 속합니다. 그런 다음 PaaS 환경에서 이러한 표준을 적용하고 모니터링해야 합니다. 끝말 구성 관리 자체는 이론과 실천에서 끊임없이 풍부하고 발전하고 있다. 예를 들어, "기술 자료" 에 적용되는 구성 관리 제품군의 관리로 인해 "컨텐츠 관리" 라는 새로운 영역이 생겨났습니다. 구성 관리에서 제공하는 상태 보고 및 데이터 통계도 소프트웨어 메트릭에 대한 의사 결정 기반을 제공합니다. 구성 관리는 프로젝트 관리를 위한 다양한 프로젝트 진행 상황을 모니터링하는 관점을 제공하며 프로젝트 관리자가 프로젝트 프로세스를 정확하게 파악할 수 있도록 합니다. 구성 관리는 또한 개발자가 보다 효율적으로 의사 소통하고 공동 작업을 수행할 수 있는 공동 작업 플랫폼을 제공합니다. 구성 관리는 소프트웨어 개발의 초석이라고 할 수 있습니다! 구성 관리는 최근 몇 년 동안 중국에서 큰 인정을 받았는데, 구성 관리가 없으면 소프트웨어 개발에 대해 이야기할 수 없고, 소프트웨어 품질에 대해 이야기할 수 없고, 소프트웨어 업계의 발전에 대해 이야기할 수 없다는 것은 과장할 수 없다. (마하트마 간디, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) 소프트웨어 산업의 규모가 커짐에 따라 구성 관리의 구현은 원하지 않는 문제가 아니라 언제, 어떻게 실시할 것인가에 관한 문제이다. < /p >