[CISA 이론 정리 - 3장] 04 SDLC 모델 및 시스템 유지 보수

1. 소프트웨어 개발 수명 주기 모델

(1) 폭포수(Waterfall) 모델

① 전통적 개발 방법론이 주로 따르던 접근법이다.

② 정형화된 일련의 단계들을 순차적으로 수행하며 한번 수행한 단계는 회귀하지 않는다.

③ 대단히 체계적인 방법이지만, 가변적/역동적 환경에는 적합하지 않을 수 있다.

(2) 증분적(Incremental) 모델

① 전체 개발 범위를 일정 단위로 분할한 후 개발 우선 순위를 결정한다.

② 사전 결정한 순서에 따라 각 부분을 분석, 설계, 개발, 테스트하여 완성한다.

③ 순차적으로 완성된 각 부분을 통합하여 전체 시스템을 완성한다.

(3) 반복적(Iterative) 모델

① 전체 개발 범위에 대해 분석, 설계, 개발, 테스트 과정을 반복 수행한다.

② 시스템 전체를 기본 구성만 갖춘 형태로 신속하게 개발하여 최초 버전을 완성한다.

③ 최초 버전에 사용자들의 검토 의견을 반영하여 최종 버전으로 완성해 간다.

(4) 프로토타이핑(Prototyping)

① 프로토타입이란 사용자들과 효과적으로 의사 소통하기 위해 만든 시제품이다.

② 프로토타입은 의사 소통에만 사용하고 폐기할 수도 있고 처음부터 실제 기능을 포함시킨 다음 계속 정련하여 최종 제품으로 완성해 가는 데 사용할 수도 있다.

③ 프로토타핑은 증분적 모델, 반복적 모델, 나선형 등과 결합하여 사용될 수 있다.

(5) 나선형(Spiral) 모델

① 증분적 개발 접근법이나 반복적 개발 접근법에 위험 분석 활동을 추가한 형태이다.

② 하지만 나선형 모델은 다른 모델들을 아우르는 일종의 통합 모델이다.

③ 반복적 과정을 한 번만 수행하는 폭포수 개발 접근법이 된다.

④ 여러 번 수행하면 증분적 개발 접근법이이나 반복적 개발 접근법과 유사해진다.

3. 정보 시스템 유지 보수 실무

(1) 변경 관리 프로세스의 개요

① 이미 업무에 사용되고 있는 응용 프로그램 변경은 함부로 변경되어서는 안 된다.

② 변경의 필요를 인지한 주체는 변경 요청서(CRF: Change Request Form)를 제출한다.

③ CRF는 변경 통제 위원회(CCB: Change Control Board)나 승인권자에게 제출한다.

④ CCB는 변경의 비용/편익/위험/영향 등을 평가한 후 변경 요청을 승인/보류/기각한다.

⑤ 변경 요청이 승인되면 유지 보수 팀이 구축되고 프로그램 변경을 진행한다.

⑥ 변경 후에도 반드시 사용자 인수 절차를 거쳐야 하며 관련 문서들도 갱신해야 한다.

(2) 비상 변경

① 정상적인 절차를 따를 수 없는 긴급 상황에서 소프트웨어를 변경해야 할 경우 개발자에게 비상 변경용 사용자 ID를 부여하여 긴급 변경을 허가하게 된다.

② 관리자는 추후에 활동 로그를 분석하여 부정 행위가 있지 않았는지 확인하고, 예외 사항이 없으면 정상적인 변경 절차에 따라 관련 문서를 작성하고 최종 인수 서명을 한다.

(3) 형상 관리

① 형상(Configuration)이란 제품의 외관/구조/형태/위치/기능/특성과 더불어 이에 관한 기록을 동시에 가리키는 표현이다.

② 따라서 형상 관리는 특정 제품의 버전별 제품 정보를 기록하는 관리 실무이다.

③ 형상 관리 소프트웨어를 사용하면 보다 효과적이고 효율적인 관리가 가능하다.

④ 형상 관리는 크게 네 가지 단계를 거처서 수행한다.

• 형상 식별 - 제품의 구조와 특성 및 기타 정보를 파악한다.

• 형상 통제 - 제품의 버전 또는 기준선을 확정하고 형상의 변경을 방지한다.

• 형상 회계 - 특정 버전을 기준으로 제품의 구조와 특성을 문서화한다.

• 형상 감사 - 작성된 형상 기록 문서를 실제 제품의 형상과 비교하여 검증한다.

4. 라이브러리 통제 소프트웨어

(1) 의의

① 라이브러리(Library)란 각종 파일(프로그램 파일 및 데이터 파일)들을 보관하는 물리적 또는 논리적 장소를 가리킨다.

② 프로그램 라이브러리는 개발(development)과 운영(operation) 라이브러리로 구분된다.

③ 개발 라이브러리는 다시 개발(소스 코드 개발/변경을 위해 구축)과 테스트(또는 스테이징, staging) 라이브러리(테스트 환경의 안정성을 위헤 구축)로 나뉜다.

④ 운영 라이브러리는 다시 소스 코드(운영 환경에서 사용되는 프로그램의 소스 코드를 보관)와 목적 코드 라이브러리(목적 코드의 보관/실행에 사용)로 나뉜다.

⑤ 한편 종종 목적 코드 라이브러리는 생산(production), 실행(execution), 운영 라이브러리라고도 부른다.

(2) 라이브러리 통제

① 라이브러리 통제 소프트웨어는 부당한 라이브러리 접근과 불법 변경을 통제한다.

② 이로써 파일 사용 주체 간 직무 분리, 접근 통제, 시스템 무결성 유지에도 도움을 준다.

③ 개발 라이브러리와 테스트 라이브러리에는 오직 개발자들만 접근할 수 있다.

④ 소스 코드 라이브러리는 라이브러리안이나 변경 통제 담당자만 접근할 수 있다.

⑤ 목적 코드 라이브러리에는 오직 운영 직원들 및 사용자들만 접근할 수 있다.

5. 소스 코드 임치 계약

① 소스 코드 임치 계약(escrow contract)이란 소스 코드 및 개발 관련 자료를 위탁 보관업체(escrow agent)에 함께 맡겨 두었다가 개발업체가 폐업하거나 유지보수 의무를 이행하지 않으면 임치(deposit) 항목들을 고객사에 제공하기로 하는 계약이다.

② 소스 코드, 목적 코드, 개발 및 운영 문서, 유지 보수 자료, 개발자 정보 등을 보관한다.

③ 이러한 임치 항목들은 주요한 변경이 있을 때마다 갱신 보관되어야 한다.