[소프트웨어공학] 25장 Configuration Management

-> 소프트웨어의 버전을 관리하는 부분, change 요청을 관리하는 부분에서 언급됨.

 

주요의제

• Version management(버전관리)
• System building(시스템 통합)
• Change management(개선점 변경관리)
• Release management(배포관리)

 

Configuration Management

->소프트웨어 제품에 들어가는 다양한 소스코드, 자원에 대해서 유지관리 함

->소스코드를 관리하며 변경이 된 내용을 관리하고 변경된 이력 역시 관리함

->수정이 발생한다면 어떠한 파일이 언제 어떠한 이유로 바뀌었는지를 기록하고 관리함

->각각의 릴리즈에 들어가는 소프트웨어는 무엇인지 컨트롤할 수 있어야함

 

CM activities

>Version management – 버전을 관리해 주는 것, 소프트웨어에 들어가는 소스 파일이 바뀌거나 컴포넌트 또는 시스템수준이 바뀌는 것을 관리해 주는 것, 유니크한 식별자를 부여함

- multiple versions of system components(소스코드, 파일 등 여러 가지의 변화를 관리)

- do not interfere with each other(수정에 있어 각각의 것들이 서로 직접적인 영향을 주지 않도록 하는 것, 소프트웨어가 진화하는 것을 방해하지 않는다.)

>System building (소스파일, 헤더파일과 같은 프로그램 컴포넌트들이 하나로 통합되는 과정, c언어와 같은 것에서 이루어지는 컴파일작업)

>Change management(A에서 B로 바뀌는 이력을 기록함 -> 어떠한 이유로 누가 언제 무엇을 바꾸었는지, 소스코드의 변화 추적, 수정을 받아드릴지 말지를 결정함)

>Release management(고객님에게 빌드하고 제공하는 것, 고객님에게 출시한 소프트웨어는 일정기간 책임을 져야함)

 

Configuration management activities

>소프트웨어를 만들면 그에 따른 소스코드, 자원파일들과 같은 컴포넌트들이 만들어짐 이러한 것들이 개선되면서 수정된 것들이 버전으로 관리되어 쭉 올라감 -> 그러한 컴포넌트들을 하나의 시스템으로 통합 -> 여기서 만들어진 시스템을 유지 관리하는데 변화가 발생하면 그러한 변화들을 할지말지 결정한 후 버전들을 만들어 관리함, 수많은 소스코드, 자원들 중 어떠한 것들이 이번 시스템에 투입되었는지 기록해야함 -> 이후 시스템을 릴리즈하면서 그 안에 포함된 문서, 소스코드 파일들의 버전은 무엇인지 등이 관리됨.

 

 

Agile development and CM

-> plan-based 기법에서의 형상관리는 개발이 되었는지 되었다면 통합하고 완성되었다면 내보내고 끝이다. 이렇게 한번 쭉 흘러가는 것이라면 에이자일은 스크럼 미팅, 스프린트 미팅이 계속해서 나옴 -> plan-based에 비해 형상관리가 더욱 중요함(하루에도 몇 번씩 수정이 일어나고 변화를 받아들이기 때문에, 굉장히 자주 일어나고 더불어 자동화 될 필요가 있음)

-> 각각의 개발자들은 각자의 저장 공간(private workspace)에 본인이 다루는 소스코드, 파일들을 가져다 놓는다. -> 이러한 것들은 쉐어드 공간에 서로 공유된 자원들 속에서 필요로 하는 자원들을 카피하여 가져다 놓음-> 이렇게 진행한 일들이 아무 문제를 일으키지 않는다면 다시 쉐어드 공간에 올림.

 

Development phases

>development phase – 새로운 변화를 집어넣는 것이 정해져있는 것들을 지키는 것

>system testing phase – 새로운 요구사항을 반영하기 보다는 기존에 존재하는 것들에 문제가 없는지 확인함(bug fixing)

>release phase – 완전히 번호를 달고 그러한 버전들에 대해 책임을 져야함(고객에게 전달)

 

 

Multi-version systems

-> 만든 소프트웨어가 고객에게 전달되었다고 끝나는 것이 아님

-> 자잘한 버그나 고객님의 요청 중 빠져있는 것들에 대해 추가적인 작업이 필요함

-> 시간이 지남에 따라 버전들이 늘어나고 여러 고객님들께 동시 다발적으로 제공됨

-> 소프트웨어란 단하나의 버전만 존재하는 것이 아님 -> 다양한 버전 존재(유니크한 번호를 부여하여 관리를 함)

 

Multi-version system development

-> 버전 진화의 모습 -> 고객님들께 전달이 될 때는 Releases버전으로 바뀌어 전달이 됨.

-> 마이너버전들을 계속해서 만들어지고 그에 따른 변화들은 트랙킹됨.

-> 마이너버전은 사소한 기능 첨삭이나 버그에 대한 개선이 이루어짐

-> 메이저버전은 혁신적으로 구조가 바뀌는 것을 의미함

>>같은 소프트웨어라도 버전이 매우 많음 -> 이것을 체계적으로 관리해야함

 

CM terminology -> 형상관리 주요 단어

Codeline – 소프트웨어 컴포넌트 버전의 집합 의미, 특정 코드의 집합을 말함

Baseline – 시스템을 구성하는 컴포넌트 버전의 컬렉션을 의미함, 명확한 버전은 꼭 지켜줘야 함.

Branching - 기존 코드라인의 버전에서 새 코드라인으로 이동

Mainline – 일련의 기준선

Configuration (version) control - 변경 사항이 관리되고 모든 버전의 구성 요소가 식별되고 저장됨.

Configuration item or software configuration item (SCI) - design, code, test data,

document와 같이 형상관리의 주요 대상이 되는 것

Merging - 서로 다른 코드 라인에서 개별 버전을 병합하여 소프트웨어 구성 요소의 새 버전

Release – 고객에게 소프트웨어를 제공하는 것

Repository – 데이터베이스가 공유되는 공간

System building - 실행 가능한 시스템 버전 생성

Version - 구성 항목의 인스턴스

Workspace – 개발자 스스로가 작업을 진행하는 공간

 

Version management

-> 코드라인, 베이스라인과 같은 수많은 파일들이 개선되고 합쳐지고 릴리즈 되는 것을 관리

-> 다른 버전 추적

-> 서로 간섭하지 않는다. -> 구글닥스에 활용되는 기술

 

Codelines and baselines

-> 코드라인은 소스 코드의 일련의 버전을 의미함 -> 각 구성 요소의 다른 버전

-> 베이스라인은 특정 시스템의 정의

 

Baselines

-> 형상 언어(정해진 형태의 문법을 통해 정해진 동작을 하는 것)를 사용하여 베이스라인을 지정할 수 있다. -> 사용을 어떻게 해야 하는지 문서화된 부분이 존재한다.

-> 전체 시스템의 특정 버전을 다시 생성해야 하는 경우가 많기 때문에 베이스라인이 중요

-> 회사 내부적으로 recreation해야 할 필요가 있음

 

Version control systems

VC(Version Control) 시스템은 다양한 버전의 구성 요소에 대한 액세스를 식별, 저장 및 제어됨. -> 수작업으로 하기 에는 어려움이 있음

소프트웨어로 구현되는 것

Centralized systems(단일 마스터 리포지토리, 한 곳에 중앙 집중의 형태로 관리가 되는 것, ex. Subversion)

Distributed systems(여러 버전의 구성 요소 리포지토리가 동시에 있는 것, ex. GitHub)

 

Key features of version control systems(버전 제어 시스템의 주요 기능)

>Version and release identification - 버전 및 릴리스 식별

>Change history recording – 변경 기록 수정, 누가 언제 무엇을 바꾸었는지 기록

>Support for independent development – 독립적인 개발이 필요

>Project support – 프로젝트를 도움

>Storage management (disk space optimization, 디스크를 효과적으로 사용하기 위하여 변경된 이력만 저장해서 관리함) - 필요한 파일들이 저장되어 관리되어야함

Public repository and private workspaces(별도로 다운받는 것)

->간섭 없이 독립적인 개발을 지원

->변경을 완료하면 변경된 구성 요소가 프로젝트 저장소로 반환

->프로젝트 저장소(마스터본)에서는 모든 구성 요소의 '마스터' 버전을 관리

check-in – 작업공간의 데이터를 마스터로 올리는 것

check-out – 마스터로부터 별도의 작업공간에 저장하는 것

 

Centralized version control

-> check out을 통해 개인 작업공간에 업로드를 통해 작업을 수행함

-> 수행한 작업을 check-in을 통해 마스터에 올림

-> 동시에 구성 요소 작업

-> 겹치거나 충돌이 나는 부분에 대한 경고를 해줌

 

Distributed version control

-> '마스터' 리포지토리가 서버에 작성되어있음.

-> 프로젝트 저장소를 clone을 통해 카피를 해서 작업을 함

 

commit - 변경사항 및 개인 서버 리포지토리 업데이트

push - 프로젝트 저장소에 대한 변경 사항을 넣는 것

pull – 변경된 사항을 가져오는 것, 가지고 있는 것과 통합됨.(pull request)

 

Benefits of distributed version control -> 분산된 버전을 현재 많이 사용하고 있음

-> 백업 장치 제공

-> 오프라인 작업이 가능

-> 개발자는 로컬 컴퓨터에서 전체 시스템을 컴파일하고 테스트할 수 있음

 

Open-source development -> 오픈소스가 많이 사용되면서 Distributed version control이 많이 사용됨

-> 전 세계의 많은 사람들이 개발을 진행할 수 있음.

-> 개발자가 통합관리자에게 요청을 하면 판단을 통해 소프트웨어를 가져가는 pull request가 있음.

ex. 리눅스

 

Branching and merging

-> 독립적인 순서를 가짐

-> 다른 개발자들은 다른 버전에서 독립적으로 일함

-> 코드라인 브랜치를 병합하여 새 버전을 만든다. -> 코드에 적용되는 델타(이전 것에서의 변화) 결합을 통해 자동으로 병합됨

 

 

Storage management

-> 초기에는 한정적인 디스크 용량으로 효율적으로 스토리지 관리가 필요했음.

-> 한 버전과 다른 버전 간의 차이(델타) 목록을 저장

-> 바뀐 버전을 마스터 버전(일반적으로 최신 버전)에 적용하면 대상 버전을 다시 만들 수 있음

 

Storage management in Git

-> Git는 deltas를 사용하지 않지만 저장된 파일 및 관련 메타 정보에 표준 압축 알고리즘을 적용

-> 그러나 똑같은 파일이 중복되어 저장되는 것은 방지함.

 

 

System building

-> 앞서 만든 소프트웨어 베이스라인에 있는 소스코드들을 모두 합쳐 실행 가능한 형태를 만드는 것

-> 시스템 빌드(System Building)는 시스템 구성 요소, 외부 라이브러리, 구성 파일 등을 컴파일하고 연결하여 완벽한 실행 가능한 시스템을 만드는 프로세스이다.

-> 시스템 빌드 도구와 버전 관리 도구는 빌드 프로세스에서 버전 관리 시스템에 의해 관리되는 리포지토리에서 구성 요소 버전을 체크아웃하는 것과 관련하여 통신해야 합니다.

-> 기준선을 식별하는 데 사용되는 구성 설명은 시스템 빌드 도구에서도 사용됩니다.

 

Build platforms

development system - 컴파일러, 소스 코드 편집기 등과 같은 개발 도구를 포함, IDE(비주얼 코드 같은 것) 개발자에게 좋은 개발환경을 제공하는 것

-> 이렇게 만들어진 시스템이 버전 관리에 있으면 build server가 소스코드들을 가져와서 최종 실행 소프트웨어를 만듦

build server - 시스템의 최종 실행 가능한 버전을 빌드하는 데 사용

target environment - 시스템이 실행되는 플랫폼, 소프트웨어가 실행되는 환경

 

System building

-> 소스코드, 데이터, 라이브러리 그리고 어떻게 어떤 식으로 하라는 Configuration files이 있어서 이를 보고 빌드 시스템이 자동화된 형태로 자원들을 하나하나 연결해 가는 과정을 거침 (소스코드가 컴파일 언어로 되어있다면 컴파일러와 같은 도구를 거침) -> 결과적으로 실행 가능한 타겟 시스템이 나왔고 이러한 타겟 시스템이 테스트과정들을 추가로 거침

 

 

 

Build system functionality

- Build script generation(수많은 파일들을 어떤 순서로 어떤 인터프리터 툴을 사용해서 사용하지를 써놓은 것)

- Version management system integration(버전 시스템과 빌드시스템은 항상 통합이 되어 있음)

- Minimal re-compilation(윈도우나 XP같은 큰 빌드파일을 실행 시키게 되면 너무 과정이 많아지므로 앞서 빌드할 때 컴파일 된 것들을 다시 사용함)

- Executable system creation(실행 가능한 시스템 역시 통합됨)

- Test automation(테스트와 같은 것들도 자동화로 진행함, 컴파일되고 있는 것들에 문제가 있는지 없는지를 확인할 수 있음)

- Reporting(빌드가 끝나고 나면 제대로 이루어졌는지 또는 문제가 있었던 것들에 대한 리포트들이 자동으로 만들어진다.)

- Documentation generation(사람들이 보기 좋게 문서화해주는 작업)

>>위와 같은 작업들을 빌드시스템이 제공해 주는 기능이다.

 

System platforms

위에 것에서 추가 실시간으로 돌아가거나 임베디드 시스템의 경우에는 개발하는 시스템과 타겟시스템이 완전히 다른 경우가 대부분이다. -> 안드로이드 운영체제가 올라가있는 어플리케이션을 짠다면 안드로이드 경우에는 안드로이드 스튜디오가 깔려있는 컴퓨터에서 작업함.

-> 개발시스템과 타겟시스템이 다를 수 있음.(두 시스템 환경의 차이가 극도로 심할 수가 있음)

 

Development, build, and target platforms - 개발과 빌드, 타겟 플랫폼의 관계

-> 개발 시스템에 개발 도구가 존재(주피터노트북, 비주얼코드 등) -> 작업공간을 열고 작업을 진행함 -> 버전 관리 시스템이 있다고 하면 카피해온(check-out) 데이터 소스코드를 통해

개발을 진행한 후 check-in을 함 -> 이렇게 만들어진 소스코드들을 빌드 서버가 가져와 타겟 플랫폼에서 실행 가능한 시스템의 형태로 만들어줌

 

Agile building -> Continuous integration(계속해서 통합함)

-> 주선 시스템 점검 -> 시스템 구축 및 자동화 테스트 실행 -> 변경사항작성 -> 개인 작업 공간에서 시스템 구축 -> 빌드 시스템에 체크인합니다. -> 빌드 서버에 시스템 구축-> 변경 사항 커밋

 

-> 버전 관리 시스템에서 소스코드를 가져옴(check-out) -> 빌드하고 테스트하는 시스템이 동작을 함 or 개인적인 공간에서 소스코드를 수정하는 작업은 private workspace에서 진행함 -> 변경을 진행하고 내 컴퓨터 안에서 테스트를 진행함 -> 테스트가 성공을 하면 빌드서버에 집어넣음 or 실패한다면 다시 수정하고 테스트하는 과정을 거침 -> check-in은 자신이 변경한 사항만 추가된 상황이고 다른 사람들의 소스코드까지 합쳐서 테스트를 진행함 -> 빌드서버에서 결국 테스트를 했는데 성공을 했다 -> 내가 만들 코드가 내가 만든 환경과 다른 사람들의 것과 합친 경우에도 문제가 없으니 결국 수정작업에 문제가 없다고 판단함 -> 통합매니저에게 문제가 없음을 알리고 요청함 -> 통합 메니저에서 빌드 서버로 보내 실행 가능한 시스템으로가 모두를 합쳐서 최종버전으로 릴리즈를 함

>>에이자일이건 top-down방식이건 별반 차이는 없음 -> 에이자일은 스크럼을 뛰게 되어 지속적으로 테스트하고 개발하고 통합하는 과정을 진행함 -> 매일매일 소프트웨어 릴리즈가 나옴 -> 이렇게 계속해서 반복되는 작업들은 자동화시키는 것이 유리함 -> 따라서 Devops에 관심을 갖고 3장 이후를 본다면 CI(Continuous integration), CO(Continuous Operation)이라는 단어가 많이 나옴을 알 수 있다 -> 핵심적으로 자동화를 많이 언급함.

-> 빌드작업을 수시로 하기 위해서 대부분의 공정, 작업들에 소프트웨어 툴을 사용하여 자동화를 함

 

Pros and cons of continuous integration

장점

다른 사람과 독립적으로 작업할 수 있음

항상 최신버전의 동작할 수 있는 소프트웨어가 존재함 -> 매일 작업한 내용들을 매일 통합해 나가기 때문에 항상 최신 버전의 실행할 수 있는 파일을 만들 수 있다.

단점

프로그램을 빌드하는데 오랜 시간이 걸린다면 매일매일 통합하기가 어려움 -> 통합되는 작업이 크지 않은 경우(서버리스 등)에만 연결될 수밖에 없음

개발 플랫폼이 목표 플랫폼과 다를 경우, 불가능 할 수 있음.(안드로이드 서비스 개발을 한다면 컴퓨터에서 개발을 하지만 동작은 안드로이드 기반의 기기를 활용해야함 -> 이것에 시간이 상당히 소요됨.)

 

-> plan-based 기법 기반의 경우 -> 특정 날짜에 맞춰서 빌드하는 것이 일반적임

Daily building(매일 빌드를 하는 경우)

ex)

매일 2시에 빌드를 하기로 되어 있다면 매일 2시가 되기 이전에 모든 개발자들은 2시 이전에 본인이 하던 소프트웨어 개발을 마치고 빌드 서버 안에 집어넣어야함(본인 소프트웨어 테스트, 통합테스트도 일정부분 마친 상태여야 함)-> 시스템에서 자동으로 빌드를 진행하고 테스팅팀으로 넘김 -> 자동화된 도구들을 가지고 테스트를 진행함 -> 그에 따른 결과 문서들이 나오고 문제가 있는 부분은 재수정하는 과정을 거침

 

에이자일의 경우(continuous integration)에는 매일해진 시간에 빌드를 진행을 하는데 정해진 시간이전에 개발하던 것들을 빌드시스템에 올림 -> 빌드시스템은 자동으로 예약되어 있는 시간에 맞춰서 Configuration files에 따라 본인이 빌드해야할 시스템을 자동으로 빌드함 -> 테스팅 소프트웨어들을 하나씩 꺼내어 빌드시스템이 자동으로 우리가 빌드한 소프트웨어들을 테스트해 나감(TDD기법에 의해 짜놓은 테스트 TDD코드들을 사용할 수도 있음, 각 단계별로 정해놓은 테스트들을 진행 할 수도 있음 -> 사람이 개입하지 않음) -> 소프트웨어가 자동으로 생성된 개발된 리포트가 만들어짐 -> 프로그램의 에러와 warning들이 자동으로 확인이 되면 빌드시스템에서 테스트한 코드에 해당하는 담당자에게 이메일과 같은 것들로 전송됨. -> 그 메일 받은 사람들은 수리에 들어감

Minimizing recompilation -> 리컴파일을 줄임

-> 컴파일 된 버전의 구성 요소를 사용할 수 있는지 확인하여 이를 수행 -> 해당 구성 요소를 다시 컴파일할 필요가 없음

-> 유니크한 식별자를 부여함 식별자를 통해 동일한 부분을 확인함 -> 바뀌거나 바뀌지 않은 부분을 확인하기 위함

 

식별자의 경우에는 Modification timestamps를 둠 -> 그 파일이 언제 수정이 되었는지 나와있음 -> 시간 날짜를 확인함으로써 해당 소스코드나 파일이 변경되었는지를 확인함 -> 많이 사용x 구현에 어려움이 있음

Source code checksums (이것을 많이 사용함) -> 공식을 하나 만들어서 공식에 텍스트 파일의 내용을 공식에 집어넣음 -> 수식에 따라 변경되었는지를 확인 할 수 있음 -> 여러 가지 요소들을 합쳐서 나오는 코드 값(checksum)값을 이용하여 판단함

>>예시(48page)

 

 

Change management -> 우리의 시스템을 요구한 사람들의 변화에 따른 요구사항을 어떻게 반영할 것인지

-> 테스트하는 사람, 고객으로부터 변화에 대한 요구가 들어온다면 그것을 반영해서 수정하는 과정 -> 기능개선, 빠진 것들을 다시 넣는 것 -> change

-> 수정관리 -> 요청이 오는 대로 모두 받는 것이 아닌 조직적 수행을 위해 판단을 하는 과정을 거침 -> 비용을 분석, 장점 판단, 우리의 여건 같은 것들을 따져서 받아들일지 말지를 정함(approve 과정) -> 수용된 변화들은 적용을 위해 들어감

 

>>규모가 있는 회사들이라면 Change requests를 관리하는 부서가 따로 존재함 -> 변화들을 approve하고 필요한 것들을 적용하도록 넘김 -> Check CR팀에서 판들을 해서 유효한지 아닌지를 판단을 해서 가능한 것들은 알려주고 필요한 것들은 변경을 적용하는 부서로 넘김 -> 정말 필요한 기능들을 선별을 해서 개발하고 테스트하고 반영하는 Close CR과정을 거침 -> 굳이 필요가 없다면 개발 없이 해결함 ->요청이 직접 개발부서로 전달되는 경우도 있음 -> 분석을 진행하고 필요가 있다면 팀을 꾸려 진행함

 

>>Change requests가 시스템에 등록되는 과정

-> 어떤 프로젝트인지 등 여러 정보들이 입력되어 있음

-> 어떤 내용이 요청이 되었는지, 분석된 내용 역시 기입되어 있음

-> 변화를 통해 영향을 받는 부분도 나타나있고 변경 시 소요되는 요소들에 대해서도 나타나 있음

-> 결정이 받아졌는지에 대한 부분도 나타나 있음

 

 

Factors in change analysis -> 변화를 위한 분석

변화가 꼭 필요한 것인지 -> 굳이 필요 없다면 진행할 필요x

변화의 이점이 무엇인지

변화를 요구한 사람이 몇 명인지

투입되어야할 돈이 어느 정도인지

지금 당장 해야하는 것인지(다음 버전에 가능하다면 다음 버전으로)

 

-> 변경되거나 정보들이 주석으로 되어있다 -> 소프트웨어 파일 안에(좋은 요소임)

 

Change management and agile methods -> 에이자일인 경우

-> 스크럼을 뛰면서 개발자들 끼리 스스로 변화가 필요한 부분에 대해서 이야기를 하고 고객님과의 대화를 통해 변화가 필요한 부분에 대해서 알아간다.

-> 변화가 필요한 것에 대해 논의하는 과정이 선행되어야함(신규로 필요한 부분보다 우선순위에 있음)

-> Refactoring에 대한부분은 항상 오픈마인드로 본인이 먼저 실행해보는 과정을 가져야함

 

 

Release management

-> 우리가 만든 시스템을 고객에게 전달하고 관리하는 것

-> Release management의 2가지 측면

- mass market software(윈도우10, 오피스 같은 것들 – 다양한 고객에게 제공되는 것) -> major releases(완전히 새로운 구조), minor releases(일부 변경, 일부 신기능 추가) 번호가 제공됨.

- custom software(특정사람들에게 개별적으로 개발되는 것) -> 동시 시점으로 다양한 소프트웨어들이 돌아갈 수 있음

>>오픈소스 소프트웨어는 두 가지 모든 측면이 있을 수 있음

 

Release components -> 무엇이 관리되어야 하는지

-> configuration files, data files, installation program, documentation, packaging와 같은 것들이 관리되어야 함

 

Factors influencing system release planning -> 다음 릴리즈 시 고려되는 요소들

->Competition, Marketing requirements, Platform changes, Technical quality of

the system 이러한 것들이 반영이 되어야함.

 

 

Release creation

-> 릴리즈에 따라 만들어져야 할 것

-프로그램 실행 가능 코드 및 모든 관련 데이터 파일은 버전 제어 시스템에서 식별되어야 한다.

-하드웨어 및 운영체제별로 구성설명을 작성하여야 할 수 있다.

-자체 시스템을 구성해야 하는 고객을 위해 업데이트 지침을 작성해야 할 수 있습니다.

-설치프로그램의 스크립트를 작성하여야 할 수 있다.

-시스템 설명서 링크와 함께 릴리즈를 설명하는 웹 페이지를 작성해야 합니다.

-모든 정보가 확보되면 소프트웨어의 실행 가능한 마스터 이미지를 작성하여 고객 또는 판매점에 배포해야 한다.

 

 

Release tracking

-> reproduce exactly, re-created exactly -> 언제 어디서든 동일하게 이루어져야 한다.

-> 가장 중요

 

Release reproduction -> 다시 복원될 수 있어야한다.

-> 운영체제, 개발된 정보, 빌드 된 정보 등 여러 가지 정보들이 복원될 수 있어야한다.

 

Release planning -> 시간상의 계획들이 필요하다.

 

Software as a service -> 최근의 소프트웨어들은 웹베이스 서버스들이 많아짐

-> software as a service (SaaS) -> 별도의 변경인증이 필요x

-> 네트워킹이 일반화되면서 이렇게 변함

 

Key points

-구성 관리는 진화하는 소프트웨어 시스템의 관리입니다. 시스템 유지 관리 시 CM 팀이 투입됩니다.

변경사항이 시스템에 통제된 방식으로 통합되고 기록이 구현된 변경사항의 세부사항과 함께 유지되도록 하기 위한 장소입니다.

- 주요 구성 관리 프로세스는 버전 관리, 시스템 구축, 변경 관리 및 릴리스 관리와 관련이 있습니다.

-버전 관리는 소프트웨어 구성요소가 변경됨에 따라 소프트웨어 구성요소의 다양한 버전을 추적하는 것을 포함한다.

-시스템 구축(System Building)은 시스템 구성 요소를 실행 가능한 프로그램으로 조립하여 대상 컴퓨터 시스템에서 실행하는 프로세스입니다.

- 소프트웨어는 새 버전이 구축되는 즉시 수시로 재구축 및 테스트해야 합니다. 이를 통해 마지막 빌드 이후 도입된 버그와 문제를 더 쉽게 감지할 수 있습니다.

-변경관리에는 시스템 고객 및 기타 이해관계자의 변경사항 제안사항을 평가하고 이를 새로운 시스템 버전으로 이행하는 것이 비용 효율적인지 결정하는 작업이 포함됩니다.

-시스템 릴리스에는 실행 가능한 코드, 데이터 파일, 구성 파일 및 설명서가 포함되어 있습니다. 릴리스 관리에는 시스템 릴리스 날짜에 대한 결정, 배포에 대한 모든 정보 준비 및 각 시스템 릴리스 문서화 작업이 포함됩니다.