라이지움에 이창희 강사님이 해주신 좋은 답변이 올라왔네요....참고하시기에 아주 좋은 글인것 같습니다. 저도 많이 참고했슴당.
<<배경 설명: 다양한 SDLC 단계 구분법>>
SDLC는 일반적으로 "계획-분석-설계-개발-구현"으로 구분합니다. 하지만, 이는 어디까지나 일반적인 구분법이지, 절대적인 구분법은 아닙니다. 실재로 프로젝트나 방법론마다 조금씩 다른 형태로 정의하고 있습니다. 몇 가지 예를 설명 드리죠.
(1) 분석 단계
분석 단계란, 사용자 요구사항을 정의하는 단계입니다. 한편, ISO 12207에는 표준적인 개발 공정이 정의되어 있습니다. 그런데, ISO 12207은 기본적으로 시스템을 소프트웨어의 집합으로 보고 있습니다. 그리고, 분석 단계는 시스템 수준에서의 분석과 설계로 보며, 설계 단계는 소프트웨어 수준의 분석과 설계로 봅니다. 정리하면 다음과 같죠.
(1-1) 분석 = 시스템 분석 + 시스템 구조 설계
(1-2) 설계 = 소프트웨어 분석 + 소프트웨어 구조 설계 + 소프트웨어 상세 설계
(2) 설계 단계
설계 단계란, 개념적으로 정의된 사용자 요구사항을 시스템적으로 재정의하는 단계입니다. 그래서, 분석 = 시스템 논리 모델 작성, 설계 = 시스템 물리 모델 작성으로 이해하는 경우도 있습니다.
(2-1) 분석 = 논리 모델 작성
(2-2) 설계 = 물리 모델 작성
그런데, 설계 단계를 "기본 설계 + 상세 설계"로 구분하기도 있습니다. 기본 설계는 외부 설계라고도 하는데, 사용자의 관점에서 전체 구조를 설계하는 것입니다. 이에 비해 상세 설계는 내부 설계라고 하며, 개발자의 관점에서 프로그램 명세서(Specification)를 작성하는 것이죠.
(2-3) 기본 설계 = 외부 설계 = 사용자 관점에서의 전체 구조 설계
(2-4) 상세 설계 = 내부 설계 = 개발자 관점에서의 전체 구조 설계
(3) 개발(Development) 단계
개발 단계는 프로그램의 원시 코드를 작성하는 단계입니다. 그래서 개발 단계를 코딩(Coding) 단계 혹은 프로그래밍 단계라고도 부릅니다. 하지만, 코딩은 개발 단계에 포함된 하부 활동이며, 디버깅과 동시에 수행됩니다. 개발 단계는 구축(Construction) 단계라고도 부릅니다.
(3-1) 개발 = 프로그래밍 = 구축
(3-2) 프로그래밍 = 코딩 + 디버깅 + 단위 테스트(=모듈 테스트)
(4) 구현(Implementation) 단계
구현이란, 로직과 기능이 설계서(Spec이라고 흔히 부름)대로 개발되었음이 검증된 모듈 혹은 소프트웨어들을 통합하여 시험하고 실제 설치하는 과정 전체를 말합니다.
(4-1) 구현 = 통합 테스트 + 시스템 테스트 + 인수 테스트 + 이행
(4-2) 시스템 테스트 = 스트레스 테스트 + 볼륨 테스트 + ...
한편, 이행(Transition)은 새로운 시스템 환경으로 이사가는 활동 및 기간 전체를 의미합니다. 새로운 시스템에 대한 교육, 데이터 형식의 재정의, 소프트웨어 배포 및 설치 등의 활동이 여기에 포함됩니다. 그래서 구현 단계를 테스트 및 이행 단계로 표현하기도 합니다.
(4-3) 이행 = 교육 + 데이터 변환 + 소프트웨어 배포 및 설치
(4-4) 구현 = 테스트 + 이행
참고로, 구축/구현/이행/이관/변환이라는 단어가 번역 과정에서 다양하게 사용되는데 그 관계를 간단히 정리해 드리겠습니다.
(5-1) 구축(Condtruction): 구현으로도 변역하지만, 구현은 일반적으로 Inplementation을 가리킴
(5-2) 구현(Implementation): 이행으로도 번역하지만, 이행은 일반적으로 Transition을 가리킴
(5-3) 이행(Transition): 전환이라고도 부름
(5-4) 이관(Migration): 이행(즉, 이관)보다 다소 범위가 좁음
(5-5) 변환(Conversion): 전환이라고도 자주 번역됩니다만, 변환이 일반적임.
(5-6) 구현 > 이행(=전환) > 이관 > 변환(=데이터 변환)
<<질문 1>>
1. IS 감사인이 시스템 개발 프로세스의 단계에서 처음으로 응용통제를
고려해야 하는가?
A .구축 단계(Construction)
B. 시스템 설계 단계
C. 인수 테스트 단계
D. 기능 상세화 단계(Functional Specification)
<<해설 1>>
답은 설계 단계인데, 없어서 당황스러우셨죠. 그나마 상세 설계 단계라도 있으면 쉽게 골랐을 텐데 말입니다. 시스템 설계 단계는 설계라는 말이 있어 B를 선택하고 싶은 유혹이 느껴지지만, 왠지 조금은 수상하고요. 하지만, 답은 D입니다.
시스템 설계 단계는 (1-1)의 시스템 구조 설계를 의미하므로, B는 분석 단계에 해당합니다. 기능 상세화 단계는 (2-4)에서 말씀 드린, 상세 설계 단계에 해당합니다. 상세 설계 단계에서는 프로그램 설계서(Specification)가 작성되는데, D의 상세화(Specification)도 유추의 근거가 될 수 있습니다.
사족으로, Specification은 "명세서/설계서/시방서"를 의미하지만, "명세서작성/설계서작성/상세화"를 의미하기도 합니다. 즉, 문서를 가리키면 "명세서"이고, 행위를 가리키면 "상세화"와 같이 번역하면 됩니다. Documentation이라는 단어도, "문서"로도 번역되고 "문서화"로도 번역되죠. ^ ^
<<질문 2>>
2.시스템 개발 프로젝트의 구축단계(Construction)중에 이뤄질 가능성이 가장 높은 품질 메커니즘?
A. 단위 테스트
B. 스트레스 테스트
C. 회귀 테스트
D. 인수 테스트
<<해설 2>>
모든 테스트는 개발 단계 이후에 이루어지는 활동입니다. 또한, 단위 테스트가 설계 단계에 이루어질 수는 없습니다. (3-1), (3-2)과 (4-1)을 고려하면, 답은 당연히 A가 됩니다.
<<질문 3>>
3. 다음 중 전략적 정보 기술 계획을 수립할때 수행하는 활동이 아닌것은?
A. 향후 5년간 사용할 하드웨어 플랫폼을 검토한다.
B. 기업의 비지니스 요구사한을 검토한다.
C. 정보기술의 기회와 현안을 식별한다.
D. 기존의 시스템을 평가한다.
<<해설 3>>
이 문제는 COBIT을 참조하여 출제한 문제로서 매우 깊이 들어간 문제입니다. COBIT의 PO 도메인은 11개의 프로세스로 구성되어 있는데, 그중 처음 4개가 ISP와 관련 있는 프로세스들입니다. (특히 PO1)
PO1: 전략적 IT 계획 정의 - 전략 계획을 수립하고 이를 단기 및 운영 계획으로 변환
PO2: 정보 아키텍처 정의 - 기업 정보 모델을 수립하고 유지보수
PO3: 기술 발전 방향 결정 - 기술 하부구조 계획을 수립하고 유지보수
PO4: IT 부서와 타 부서의 관계 정의 - 조직의 역할과 책임을 정의하고 통보
결국 이 문제는 PO1에 포함되지 않는 활동에 대해 묻는 것이죠. B-D는 PO1에 속하는 반면 A는 PO3에 포합됩니다. 그래서 답이 A인 것입니다. 한편, 이 문제를 ISP 활동에 포함되지 않는 활동은 무엇인가로 이해하셔도 무방합니다. A는 전략 수준 보다는 다소 정책/전술 수준의 활동이기 때문이죠.
SDLC 방법론과 IT 이론에서 사용되는 여러 용어들은 실무에서 다양하게 사용되던 것들을 정리하고 표준화한 것입니다. 그러다 보니 그 의미와 용법이 상황에 따라 차이가 나는 경우가 많습니다. 이해에 도움이 되셨기를 빕니다. 그럼, 좋은 하루 되시길 바랍니다.