[CISA 이론 정리 - 3장] 08 외부 구입 및 공정 개선 실무

1. 소프트웨어 획득 절차

(1) 타당성 검토

① 기존 시스템을 수정할지, 새로 개발할지, 상용 패키지를 구입할지 결정한다.

② 요구 사항을 가장 잘 충족하는 방법, 각 대안의 소요 비용과 시간 등을 고려하게 된다.

(2) 분석 (요구 분석)

① 패키지를 구입하기로 결정했을 때에도 사용자 요구 사항을 분석하는 과정은 수행한다.

② 다만 이런 분석 과정은 소프트웨어 구입 관점에서 이루어진다.

(3) 선정

① 벤더들에 제품의 요구사항, 벤더의 실적 및 재정 능력, 소스 코드 제공 여부, 유지 보수 서비스 범위 등의 정보를 요청하는 제안 요청서(RFP: Request for Proposal)를 전달한다.

② 벤더들이 제출한 제안서(proposal)를 수령한 다음 일차 평가 및 필요하다면 추가 평가를 수행하고 소수의 적격한 업체들을 선정하고 협상을 거쳐 계약을 체결한다.

(4) 형상 조정(Configuration)

① 패키지 제품은 매개 변수를 조정하여 기능과 특성을 선택할 수 있는 유연성이 장점이다.

② 패키지만으로 필요가 충족되지 않으면 일부 모듈을 수정 또는 추가 개발해야 한다.

③ 패키지 시스템과의 연계를 위해서 기존에 사용 중인 시스템을 수정해야 할 수도 있다.

(5) 테스트

① 연계 테스트, 통합 테스트, 시스템 테스트 등을 상황에 맞게 수행할 수 있다.

(6) 구현

① 맞춤 개발하는 경우와 마찬가지로 최종 인수 테스트를 수행하고 시스템 이관을 한다.

② 데이터 변환, 사용자 교육 및 훈련, 헬프 데스크 운영 등을 진행한다.

③ 프로젝트 후 검토, 구현 후 검토 등도 수행한다.

2. IT 인프라 개발 및 획득

(1) 물리적 아키텍처 분석

① 기존의 서버, 저장 장치, 보안 통제 대책 등 물리적 아키텍처를 전체적으로 검토한다.

② 전산실의 지리적 위치와 물리적 한계 등을 고려하여 운영 상의 제약 요소도 파악한다.

③ 그런 다음 향후 IT 기반구조가 갖추어야 할 기능 및 보안 요구사항을 철저히 파악한다.

④ 이 과정에서 개념 검증(POC: Proof of Concepts), 즉 채택된 IT 기반구조가 기능 및 보안 요구사항을 충족하는지 검증하는 것이다.

(2) 입찰 요청서(ITT: Invitation to Tender)의 전달

① 먼저 업체 선정 기준과 입찰 제안서를 잠재적 공급자에 전달한다.

② ITT에는 정보 처리, 보안, 하드웨어, 시스템 소프트웨어 등에 관한 요구사항을 포함한다.

③ 또한 기술 및 사용자 지원 관련 요구사항, 구현 및 전환 관련 요구사항 등도 포함한다.

(3) 견적서 평가 및 업체 선정

① 견적서를 평가하여 소수의 적절한 업체들을 선정하고 협상하여 최종업체를 결정한다.

② 최종 결정된 업체와 합의하고 계약서와 SLA(Service Level Agreement)로 문서화한다.

(4) 구현 계획 및 구현

① 계약서와 SLA 체결되면 납품 일정을 결정하고 구현 및 테스트 계획 등을 수립한다.

② 구현 실패로 인한 업무 중단에 대비하는 돌발 상황 계획(contingency plan)을 수립한다.

③ IT 기반구조 요소들에 적용되는 표준 형상을 파악하여 이를 반영한다.

④ 계획에 따른 물리적 아키텍처 구현, 공급자가 설정한 패스워드 변경, 테스트 등을 한다.

(5) 변경 통제

① IT 인프라에 새로운 요소가 도입되거나 변경되면 기존 환경에 다양한 영향을 미친다.

② 철저한 비용/편익 분석 및 영향/위험 평가를 거친 후 적절한 변경 승인을 한다.

③ 변경 과정을 중단하거나 변경 사항 취소 후 원상 회복하기 위한 대책도 수립해야 한다.

④ 필수적으로 최신의 보안 패치를 설치해야 할 때는 형상 관리 기록도 갱신해야 한다.

⑤ 변경 사항은 영향을 받는 당사자들에 적절히 통보해야 한다.

3. 업무 공정 재설계(BPR: Business Process Re-engineering) 

① 업무 공정을 급격하고 대대적으로 재설계하여 생산성을 극적으로 향상하는 경영 기법

② 업무 공정을 분할한 후 각 단위 공정의 가치를 계산하여 가치가 없거나 낮은 공정은 삭제하거나 통합한다.

③ 이러한 과정에서 직무 분리 등의 예방 통제가 완화되는 위험이 있다.

④ BRP은 일반적으로 IT 솔루션의 도입을 수반한다.

4. ISO 9126

① 사용자 관점에서 소프트웨어 제품에서 기대되는 일반적인 품질 특성들을 제시한다.

② 또한, 각 특성을 달성하기 위해 개발자들이 충족해야 할 특성들을 제시한다.

③ 이때 사용자 관점에서 소프트웨어에 요구되는 품질 특성을 외부 특성이라 한다.

④ 각각의 외부 특성을 달성하기 위해 개발자가 달성해야 할 특성을 내부 특성이라고 한다.

기능성(Functionality)

• 요구되는 기능 및 기능 집합을 실제로 보유하고 있는 정도

• (관련 내부 특성) 적합성, 정확성, 유연성, 보안성

신뢰성(Reliability)

• 특정 조건과 기간 동안 일정 수준의 성능을 유지할 수 있는 능력

• (관련 내부 특성) 성숙성, 회복성, 오류 허용성

사용성(Usability)

• 사용법을 손쉽게 익히고 편리하게 사용할 수 있는 특성

• (관련 내부 특성) 이해성, 운용성, 습득성

효율성(Efficiency)

• 제품의 성능 수준 유지에 필요한 자원/시간을 적게 요구하는 특성

• (관련 내부 특성) 실행 효율성, 자원 효율성

유지보수성(Maintainability)

• 기능과 구조를 변경하기가 수월한 특성

• (관련 내부 특성) 해석성, 안정성, 변경성, 시험성

이식성(Portability)

• 새로운 환경에 쉽게 설치되고 충돌 없이 실행되는 특성

• (관련 내부 특성) 환경적응성, 일치성, 치환성, 이식작업성

※ ISO 9126를 구현하는 방법에 관한 표준은 ISO 14598이다.

5. 능력 성숙 모델(CMM: Capability Maturity Model)

(1) 의의

① 1992년 미국의 Carnegie Mellon 대학의 SEI(Software Engineering Institute)에서 미 국방부의 지원을 받아 개발한 모델이다.

② 소프트웨어 개발업체의 개발 능력 성숙도(maturity)를 체계적으로 평가하는 모델이다.

③ CMM 모델은 다양한 후속 모델들의 출현에 기여했으며 향후 CMMI로 확장된다.

(2) 단계 구성

① CMM에서는 소프트웨어 개발업체의 능력을 다음과 같이 5 단계로 평가한다.

1단계: 초기(Initial)

• 표준화된 프로세스가 없으며 문서화도 되어 있지 않다.

• 개발 일정과 비용을 예측할 수 없으며 통제가 미약하다.

• 프로세스는 사후 대응적이며 품질은 직원의 개인기에 의존한다.

2단계: 반복(Repeatable)

• 특정 유형의 프로젝트에 한하여 일련의 프로세스를 적용한다.

• 해당 프로세스를 적용하는 프로젝트는 성과를 예측할 수 있다.

• 형상 관리, 품질 보증, 요구 사항 관리, 외주 관리 등을 수행한다.

3단계: 정의(Defined)

• 개발 프로세스가 잘 정의/문서화되고 표준 방법론이 존재한다.

• 개발 일정과 비용은 예측할 수 있으나 품질 수준은 변동적이다.

• 검증과 확인, 위험 관리, 통합 프로젝트 관리 등을 수행한다.

4단계: 관리(Managed)

• 통계적/계량적 기법을 통해 프로세스와 품질을 측정/통제한다.

• 개발 일정과 비용은 물론 품질 수준이 예측 가능하다.

• 조직 프로세스 성과, 계량적 프로젝트 관리를 수행한다.

5단계: 최적(Optimizing)

• 점진적/혁신적 프로세스 개선을 통해 성과를 지속적으로 향상한다.

• 프로세스 자동화 및 개선을 위해 지속적으로 자금을 투자한다.

• 기술 변화 관리 및 프로세스 변화 관리를 수행한다.

(3) ISO/IEC 15504(일명 SPICE)

① CMM 모델을 국제 표준화한 것으로서 1998년에 제안되어 2003년에 정식 승인되었다.

② SPICE는 Software Process Improvement and Capability dEtermination의 약자이다.