[CISA 이론 정리 - 3장] 03 전통적 시스템 개발 방법론의 단계 구성 (1/2)

1. 타당성 검토

① 전략적 목적을 달성하기 위한 다양한 IT 솔루션을 식별하고 그 타당성을 분석한다.

② 기존 시스템을 수정할지, 새로 개발할지, 외부에서 패키지를 구입할지를 결정한다.

③ 비용과 편익을 분석하고 비즈니스 목적을 충족하는 가장 경쟁력 있는 방법을 찾는다.

④ 기술적, 법적, 경제적 타당성을 검토하여 최종 의사 결정을 한다.

⑤ 타당성 검토 결과는 프로젝트 헌장의 기초 투입물로 사용되기도 한다.

2. 분석 (또는 기본 설계)

(1) 요구사항 정의

① 지원 대상 업무를 이해하고 사용자들의 필요와 문제를 분석 및 문서화한다.

② 요구사항 정의는 시스템 분석가(system analyst)가 한다.

③ 시스템 분석가는 비즈니스와 IT 양쪽을 이해하며 의사소통 능력이 뛰어나야 한다.

④ 이 단계에서는 IT 솔루션의 외관이나 기술 또는 구조에 집중하지 않는다.

⑤ 사용자 요구 사항 분석은 경영진의 적극적 지원과 사용자의 심도 깊게 참여해야 한다.

⑥ 사용자들은 이 단계에서 인수 기준(acceptance criteria)을 제시한다.

(2) 비즈니스 프로세스 및 데이터 분석

① 시스템 분석가는 사용자들이 IT의 지원을 받고자 하는 업무의 범위를 정의하고 분할한다.

② 분할된 단위 업무는 균일하고 연관성이 높은 하위 활동들로 구성되어야 한다.

③ 분석 단계에서는 데이터베이스(DB)의 논리적 구조를 설계한다.

④ DBA 또는 DB 전문가가 IS의 DB 구조가 어떤 데이터를 어떻게 관리할 것인지 분석한다.

(3) 프로토타입 제작

① 분석 및 설계 단계에서 프로토타입을 제작하면 사용자와의 의사소통이 향상된다.

② 일반적으로 프로토타입은 실제 기능은 없는 외관만 갖춘 프로그램을 의미한다.

③ 또는 필요 기능 또는 핵심 기능만 갖춘 시제품 성격을 프로그램을 가리킨다.

④ 프로토타입은 최종 사용자가 시스템의 구조와 기능을 쉽게 이해하도록 돕는다.

3. 설계 (또는 상세 설계)

(1) 프로그램 모듈 구성 결정

① 시스템 분석가는 각 업무 단위를 향후 어떤 프로그램 모듈과 대응시킬지를 결정한다.

② 업무 활동의 논리적 구성과 프로그램의 물리적 구성은 반드시 일치하지 않을 수 있다.

④ 이는 프로그램의 개발 효율, 처리 성능, 다른 시스템과의 관계 등을 고려하여 결정한다.

⑤ 하지만 모든 단위 업무는 특정 프로그램 모듈에 대응해야 한다.

(2) 사용자 인터페이스 및 데이터베이스 설계

① 사용자와 IS가 상호 작용하는 매개체를 사용자 인터페이스(UI)라고 한다.

② 사용자는 UI를 통해 IS에 데이터를 입력하고 처리할 연산을 지시한다.

③ 그러면 IS는 UI를 통해 사용자에게 해당 연산의 처리 결과를 출력한다.

④ UI에는 컴퓨터 모니터에 보여 줄 화면의 레이아웃, 인쇄할 보고서의 서식 등이 포함된다.

⑤ 시스템 분석가가 UI를 설계하려면 입출력 데이터를 빠짐 없이 파악해야 한다.

⑥ 설계 단계에서는 데이터베이스(DB)의 물리적 구조를 설계한다.

⑦ DBA(DB 관리자) 또는 DB 전문가가 개발 중인 IS의 DB 구조를 설계한다.

(3) 프로그램 사양서 작성

① 시스템 분석가는 IS 설계 문서, 즉 프로그램 사양서(specification)를 만든다.

② 여기에는 프로그램의 외관, 수행 연산, 무결성 규칙, DB 구조 등이 상세히 기술된다.

③ 프로그램 사양서는 모듈별로 작성되며 다양한 그림과 설명을 포함한다.

④ 추후 프로그래머들은 프로그램 사양서에 근거하여 자신에게 할당된 프로그램 모듈을 프로그래밍한다.

(4) 기타 설계 활동

① 응용 통제, 자동화된 감사 증적 생성 모듈 등 다양한 통제 대책을 설계에 포함한다.

② 개발된 IT 대한 테스트, 사용자 교육, 프로그램 이관(migration) 등을 계획한다.

③ 기존 데이터를 새로운 시스템의 포맷에 맞게 변환(conversion)하는 방법도 결정한다.

④ 개발 대상 시스템의 백업 및 재해 복구 계획도 수립한다.

⑤ 설계 결과에 대한 사용자 경영진의 승인 획득 및 변경 통제를 위한 기준선을 설정한다.

⑥ 사용자 지침서(User guide)와 운영 매뉴얼(operation manual)의 초안을 작성한다.

4. 프로그래밍 (또는 개발)

(1) 코딩 및 디버깅

① 프로그래머는 자신에게 할당된 모듈의 사양서에 따라 (1) 프로그램 원시 코드를 작성하고 (2) 프로그램 오류, 즉 버그(bug)를 찾아 수정한다.

② 이를 각각 코딩(coding)과 디버깅(debugging)이라고 하며 프로그래밍이라고 총칭한다.

③ 대표적인 디버깅 도구에는 (1) 논리 경로 모니터(logic path monitor) (2) 메모리 덤프(memory dump) (3) 산출물 분석기(output analyzer)가 있다.

※ 컴파일러(Compiler)는 디버깅 도구가 아니다.

(2) 사용자 인터페이스 설계

① 프로그래머는 개발하도록 할당된 모듈의 UI를 제작하고 필요한 연산 로직을 작성한다.

② 이때 각각의 모듈, 버튼, 아이콘, 데이터 입력 필드 등에는 적절한 이름이 지정한다.

③ 객체들의 이름을 지정(naming) 및 프로그램 로직 기술 방법은 표준을 따라야 한다.

④ 추후 QA 담당자는 프로그램 개발 단계에서 표준 준수와 적절한 문서화 여부를 감사한다.

(3) 안전한 보관 및 백업

① 모든 프로그래밍 작업은 실제 업무 처리 환경과 분리된 개발 환경에서 이루어져야 한다.

② 개발 환경에 대한 적절한 접근 통제 및 버전 관리가 이루어져야 한다.

③ 작성 중인 또는 완성된 모듈은 하나의 컴퓨터에 보관하며 적절히 백업해 두어야 한다.

(4) 단위 테스트(Unit test)

① 코딩과 디버깅을 마친 후 모듈별로 내부 로직과 외적인 기능 수행 결과를 검증한다.

② 이를 단위 테스트 또는 모듈 테스트라고 한다.

③ 단위 테스트는 프로그램 내부 로직을 상세히 점검하기 때문에 화이트 박스 테스트(white box test)의 일종이다.

④ 하지만 모든 화이트 박스 테스트가 곧 단위 테스트는 아니다.