3장. 전통적 시스템 개발 방법론의 단계 구성
(1) IS 프로젝트 착수: 타당성 검토 후 프로젝트 헌장 작성
1) IS 감사인 평가 효용 극대화 시점 : 착수 전 미비점을 확인할 수 있음
2) 기능점수분석 활용 : 프로젝트의 규모 및 개발 노력/원가를 점수로 확인
3) 비용/편익 분석 활용 : 비즈니스 목적을 충족하는 가장 경쟁력 있는 방법 확인
4) 프로젝트 헌장 : 타당성 검토 결과를 기초 투입물로 사용하여 작성
(2) 분석 (또는 기본 설계, 기능적 설계 단계)
1) 요구사항 정의 및 분석
- 사용자 : 사용자 요구사항과 인수 기준(Acceptance criteria)을 포함한 명세서를 작성하여 제시함
- 시스템 설계에 사용자 참여를 증가시키기 위한 방안: 사업부에 IS 기능에 대한 책임 부여
- 시스템 분석가(System analyst) : 사용자 명세서를 분석하여 요구사항 정의서를 작성함
- IS 감사인: 명세서 및 요구사항 정의서에 통제 사양이 식별되었는지 검토를 수행
2) 비즈니스 프로세스 및 데이터 분석
- 시스템 분석가 : 사용자들이 IT의 지원을 받고자 하는 업무의 범위를 정의하고 업무를 배부
- DBA : 데이터베이스(DB)의 논리적 구조를 설계
3) 프로토타입 제작 : 필요 기능 또는 핵심 기능만 갖춘 시제품 성격을 프로그램
(3) 설계 (또는 상세 설계): IS 감사인의 참여가 가장 중요한 시기
1) 프로그램 모듈 구성 결정
2) 사용자 인터페이스 및 데이터베이스 설계
- 시스템 분석가 : UI(레이아웃, 인쇄할 보고서의 서식)를 설계
- DBA : 데이터베이스(DB)의 물리적 구조를 설계
3) 프로그램 사양서 작성
- 시스템 분석가 : IS 설계 문서, 즉 프로그램 사양서(Specification) 작성
- IS 감사인 : 프로그램 사양서에 통제 시스템이 반영되었는지 확인
- 프로그래머 : 프로그램 사양서에 근거하여 자신에게 할당된 프로그램 모듈을 프로그래밍 및 테스트 계획 수립
** 상세 설계 단계에서 테스트 계획이 수립됨을 주의
4) 상세 설계 완료 후 기준선(정지/동결 시점) 설정 : 이후 요구변경은 철저한 변경관리(비용/편익분석) 필요
(4) 프로그래밍 (또는 개발) : 표준개발 방법론의 지원을 받아 수행
1) 코딩(원시코드 작성) 및 디버깅(버그 수정) : 디버깅 (프로그래밍 단계에서 IS 감사인의 주요 관심사) 도구
- 논리 경로 모니터(Logic path monitor) : 순서
- 메모리 덤프(Memory dump): 특정 시점 데이터 제공 -> 비일관성 확인
- 산출물 분석기(Output analyzer): 결과와 예상치 비교
** 컴파일러(Compiler)는 디버깅 도구가 아님 (But 디버깅에 도움)
2) 사용자 인터페이스 설계 : 객체 이름 지정(Naming) 방법 및 프로그램 로직 기술 방법은 표준을 따라야 함
** 추후 QA는 프로그램 개발 단계에서 표준준수 여부를 확인하여야 함 (과정 품질) cf. QC: 결과품질
3) 안전한 보관 및 백업
- 모든 프로그래밍 작업은 실제 업무 처리 환경과 분리된 개발 환경 수행
- 개발 환경에 대한 적절한 접근 통제 및 버전 관리 수행
- 작성 중인 또는 완성된 모듈은 하나의 컴퓨터에 보관하며 적절한 백업 수행
4) 단위 테스트(Unit test)=모듈테스트 : 모듈별로 내부 로직과 외적인 기능 수행 결과를 검증
5) 표준개발 방법론 : 문서화 방법/데이터 선언 방법/명령문 구성 방법/입출력 기법 등
(5) 테스트
1) 연계 테스트(Interface test) : 시스템을 구성하는 하드웨어와 소프트웨어 요소들 간 연결 상태를 평가
2) 통합 테스트(Integration test) : 구성요소가 단일시스템으로 통합되어 유기적으로 작동하는지 확인 (아키텍쳐 설계 Test)
3) 시스템 테스트(System test) : 매우 극단적이고 유동적인 환경에서 시스템 신뢰성, 성능, 보안, 복구 능력을 테스트 ** 연계 테스트와 통합 테스트는 안정적이고 통제된 기술 환경에서 수행
4) 테스트 관련 용어
- 상향식 테스트(Bottom-up Test) : 단위 테스트, 연계 테스트, 통합 테스트 순으로 테스트
- 하향식 테스트(Top-down Test) : 시스템 전체에서 개별 모듈로 관점을 좁혀 가면서 테스트
- 파일럿 테스트(Pilot Test): 시스템의 일부 또는 일부분만 예비적으로 테스트
** 초기 개념 증명(Proof of concept)도 일종의 파일럿 테스트
- 기능/확인 테스트(Function/Validation Test) : 시스템에 요구 사항에 맞게 올바로 개발되었는지 확인
- 회귀 테스트(Regression Test) : 오류수정 or 시스템변경 후, 새로운 오류가 발생하는지 확인하기 위해 테스트 재수행
- 병행 테스트(Parallel Test) : 신규(또는 변경된) 시스템의 안정성을 기존 시스템과 비교(병행 시뮬레이션과 구별 주의)
- 사회성 테스트(Sociability Test) : 신규(또는 변경된) 시스템이 설치되면서 기존 시스템에 부정적 영향을 주지 않는지 확인
(6) 구현(Implementation)
1) 정의: 시스템을 사용자 환경으로 이관(Migration)하는 것
2) 인수 테스트(Acceptance Test) : 사용자들이 인수기준에 따라 구현되었는지 직접 실제 생산(Production) 환경에서 확인
** 사업적 수요를 확인, 모든 테스트 중 가장 중요한 테스트 절차임 (IS 자산 구입 시에도 인수 테스트는 중요)
- 알파 테스트: 사용자들의 대표 그룹에 의한 사용자 테스트
- 베타 테스트: 알파 테스트 후 불특정 다수의 사용자들에 의한 사용자 테스트 - 결과
① 인정=공인(Certification)
② 인가=인수(Accreditation)
③ 정지
3) 사용자 및 운영자 교육 : 사용자 매뉴얼과 운영자 매뉴얼을 완성, 교육/훈련을 제공 -> 헬프 데스크 조직 및 활동
** 프로그램 복구 및 재개 절차: 운영자 매뉴얼 (사용자 매뉴얼 X)
4) 데이터 변환(Data Conversion) : 새로 개발된 시스템에서 정의한 형식으로 데이터를 변경
5) 전환(Transition) : 응용을 사용자 환경에 배포/설치하고 새로운 시스템을 사용하기 시작(기존 업무의 중단 최소화)
- 전환 범위에 따른 분류
① 직접적 (Direct): 전환은 신속하지만 시행 착오와 중단 위험이 높음
② 순차적(Phased, Pilot): 시행 착오와 업무 중단 위험은 낮지만 전환 기간이 김
- 병행 여부에 따른 분류
① 단절적(Abrupt) : 새로운 환경 적응 스트레스 및 업무 중단 위험이 높음
② 병행적(Parallel) : 새로운 환경 적응 스트레스 및 업무 중단 위험이 낮지만, 시스템 요구용량이 매우 큼
(7) 프로젝트 이후의 활동
1) 프로젝트 이후 검토(Post project review) : 프로젝트를 마친 후에는 프로젝트 수행에서 얻을 수 있는 교훈점을 분석
2) 구현 후 검토(Post implementation)
** IS 감사인 입장에서 구현 후 검토가 인수 테스트 보다 더 확실한 감사증거임
- 구현이 끝난 지 6~18 개월 후 수행
- 시스템이 사용자 요구 사항과 비즈니스 니즈를 충족확인
- 목표한 투자 대비 편익이 달성되었는지 확인
- 프로젝트 수행 과정은 적절했는지 확인
4장. SDLC 모델 및 시스템 유지 보수 ** SDLC 모델은 위험관리기법을 포함함
(1) 소프트웨어 개발 수명 주기 모델
1) 폭포수(Waterfall) 모델 : 순차적/체계적 수행, But 가변적/역동적 환경에 부적합 -> V 모델로 확장
2) V 모델 : 생명주기 단계별로 상응하는 테스트 존재, 테스트를 중요시 여기는 모델
- 확인(Validation) : 외적 일관성 보증
- 검증(Verification) : 내적 일관성 보증
3) 증분적(Incremental) 모델 : 순차적으로 완성된 각 부분을 통합하여 전체 시스템을 완성
4) 반복적(Iterative) 모델 : 객체지향개발에서 주로 이용 -> 완성코드를 계속 생성(미완성 코드가 제출되면 안됨)
- 전체 개발 범위에 대해 분석, 설계, 개발, 테스트 과정을 반복 수행
- 시스템 전체를 기본 구성만 갖춘 형태로 신속하게 개발하여 최초 버전을 완성
- 최초 버전에 사용자들의 검토 의견을 반영하여 최종 버전 완성
** 이 과정에서 변경 통제와 문서화가 잘 이루어지지 않을 위험 존재
5) 프로토타이핑(Prototyping) : 프로토타입이란 사용자들과 효과적으로 의사 소통하기 위해 만든 시제품
** 프로토타핑은 증분적 모델, 반복적 모델, 나선형 등과 결합하여 사용될 수 있음
6) 나선형(Spiral) 모델 : 다른 모델들을 아우르는 일종의 통합 모델
(2) 정보 시스템 유지 보수 실무
1) 변경 관리 프로세스의 개요
- 변경의 필요를 인지한 주체는 변경 요청서(CRF: Change Request Form)를 제출
- CRF는 변경 통제 위원회(CCB: Change Control Board)나 승인권자에게 제출
- CCB는 변경의 비용/편익/위험/영향 등을 평가한 후 변경 요청을 승인/보류/기각
- 변경 요청이 승인되면 유지 보수 팀이 구축되고 프로그램 변경을 진행
- 변경 후에도 반드시 사용자 인수 절차를 거쳐야 하며 관련 문서들도 갱신해야 함
2) 비상 변경 : 개발자에게 비상 변경을 허락한 후 추후 로그 검토하여 이를 문서화 및 최종 인수 서명 수행
3) 형상 관리(형상통제위원회의 관리를 받음)
- 형상(Configuration): 제품의 외관/구조/형태/위치/기능/특성과 더불어 이에 관한 기록을 동시에 가리키는 표현
- 형상관리: 특정 제품의 버전 별 제품 정보를 기록하는 관리 실무
- 형상관리 소프트웨어: 형상을 효과적이고 효율적으로 관리하는 데 도움 - 형상관리 단계
① 형상 식별: 제품의 구조와 특성 및 기타 정보를 파악
② 형상 통제: 제품의 버전 또는 기준선을 확정하고 형상의 변경을 방지
③ 형상 회계: 특정 버전을 기준으로 제품의 구조와 특성을 문서화
④ 형상 감사: 작성된 형상 기록 문서를 실제 제품의 형상과 비교하여 검증
(4) 라이브러리 통제 소프트웨어
1) 라이브러리(Library) 정의 : 각종 파일(프로그램 파일 및 데이터 파일)들을 보관하는 물리적 또는 논리적 장소
- 개발 라이브러리 :
① 개발 라이브러리 : 소스 코드 개발/변경을 위해 구축
② 테스트(or 스테이징, staging) 라이브러리 : 테스트 환경의 안정성을 위해 구축
- 운영(or 생산) 라이브러리
① 소스 코드 라이브러리 : 운영 환경에서 사용되는 프로그램의 소스 코드를 보관
② 목적 코드 라이브러리 : 목적 코드의 보관/실행에 사용
** 목적 코드 라이브러리는 생산(Production), 실행(Execution), 운영 라이브러리라고도 함
2) 라이브러리 통제 : 라이브러리 부당 접근과 불법 변경 통제 -> 파일 사용 주체 간 직무 분리, 접근 통제, 시스템 무결성 유지
- 개발 라이브러리와 테스트 라이브러리: 오직 개발자들만 접근 가능
- 소스 코드 라이브러리: 라이브러리안이나 변경 통제 담당자만 접근 가능
- 목적 코드 라이브러리: 오직 운영 직원들 및 사용자들만 접근 가능
(5) 소스 코드 임치 계약(Escrow contract) : 납품본에 소스 코드가 포함되어 있지 않는 경우 중요
1) 정의 : 개발업체가 소스 코드를 위탁 보관업체에 함께 맡겨 두었다가 임치항목들을 고객사에 제공하기로 하는 계약
- 위탁 보관업체(Escrow agent=Escrowee) or 중개인(Trust agent)
- 고객사=지적재산권 이용자=피재산권자(Licensee) or 수혜자(Beneficiary)
- 개발업체=벤더=설정자(Settor)
- 임치항목(deposit) : 소스 코드, 목적 코드, 개발 및 운영 문서, 유지 보수 자료, 개발자 정보, Embedded OS 등을 보관
** 개발자 정보에 개발자 연락처까지는 포함될 필요는 없음
** 데이터는 보관하면 안됨 (데이터 보관은 오프사이트 저장소 개념임)
2) 소스 코드 임치 계약이 발동하는 경우
- 개발업체의 폐업
- 개발업체의 유지보수 의무 불이행
- 소스 코드 임치 계약조항을 심각하게 위반하였을 때
-끝-
참고할 점!
- 요즘은 IS라고 안하고 IT라고 하는게 일반적임. CISA가 업데이트가 늦음. IS를 IT라고 생각하면 더 익숙하게 느껴져요!
- 블로그 내용 참고도 좋지만 직접 한번 더 정리하고, 문제 풀이하면서 요약집에 없는 내용을 적절한 domain, 챕터에 지속적으로 업데이트해서 꼼꼼히 읽기를 추천드립니다..! (그저 추천입니다...)
참고한 내용!
- 동료 PTW 회계사님이 친히 작성해주신 정리글 일부를 참고하였습니다~ (회계사님 CISA없어도 CISA이시고.. 이번에 CISA 취득하실거에요! 감사해요!)
- 동료 LYJ 선생님이 작성해주신 정리글도 일부 참고하였습니다~ 시간되시는 분 블로그 놀러가세요! (감사감사!)
Link : https://unvertige123.wordpress.com
Codes and Things
프로그래밍 학습 블로그
unvertige123.wordpress.com
- 아래 블로그도 참고하였습니다.
Link :https://33cram.tistory.com/category/CISA/1.%20IS%20%EA%B0%90%EC%82%AC%20%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4
'CISA/1. IS 감사 프로세스' 카테고리의 글 목록
CISA, PMP, CISSP, CIA 자료를 공유합니다.
33cram.tistory.com
댓글