[개론 - Chap.2] 유사 서비스와의 비교에 대해서 알아보자

😭 2011년도 자료니 참고만 하세요.

세월이 많이 지나서 법도 개정되었을 수 있습니다.

 

타 감리제도와의 비교

교육 로드맵

📌 정보시스템 감리기준 - 제2020-1호(2020.1.6)

[정보] 정보시스템 감리기준 - 제2020-1호(2020.1.6.)

 

CobiT(1/2)

구분	상세
대상	• 정보 및 정보기술(데이터, 응용시스템, 기술, 시설, 인력) • IT Governance - 궁극적으로 IT Process를 중심으로 평가
목적	• 정보와 IT에 대한 경영상의 요구사항을 충족시키고 있는지의 여부를 평가 - 조직의 IT 통제에 대한 인증 및 자문 제공 - 통제 목적들이 적절하게 충족되고 있다는 것을 보증 - 통제에 결함이 있는 프로세스를 식별하고, 이러한 결함으로부터 발생할 수 있는 위험을 실증 - 취해야 할 수정조치를 권고 • IT Governance의 평가 - IT가 경영과 연계되고, 경영에 동인을 제공하고, 효과를 극대화하고 있는지 - IT 자원이 책임성 있게 사용되고 있는지 - IT에 관련된 위험을 적절하게 관리하고 있는지
이해 관계자	평가수행자: IS 감사인 • 평가결과사용자 : 사용자, 경영진
기준	정보에 대한 경영상의 요구사항(7개 항목) • 성숙단계 모델 • KPI, KGI, CSF

 

CobiT(2/2)

구분		상세
체계	지침	• Control Objectives • Audit Guideline • Management Guideline • Control Practice
	절차	1. 경영상의 요구사항에 관련된 위험과 해당 통제 대책의 이해 2. 수립되어 있는 통제의 적절성을 평가 3. 수립되어 있는 통제가 정해진대로 일관성 있고 지속적으로 작동되고 있는지를 테스트하여 통제의 준수 여부를 평가 4. 통제목적을 충족시키지 못함으로써 발생할 수 있는
	자격	기본적으로 IS 감사인이 수행하도록 하고 있음 • IS 감사인에 대한 특별한 자격은 제시하고 있지 않으나, CISA를 염두에 두고
시사점		• CobiT의 기본 가정은 외부 감사가 아니라 조직 내부에 IS 통제를 수립하고, 조직 내부의 감사인이 IS 감사를 수행하는 것임. 국내의 감리 확산을 위해서는 조직 내부에 IS 감리 기능 및 역할의 수립이 필요하다고 판단됨 • CobiT의 또 다른 기반 중의 하나는 통제의 개념임. 통제는 IT 프로세스로 설명되고 있음. 감리에도 통제의 개념을 반영하는 것이 바람직하다고 판단됨 • IT 감리의 개념을 경영과 연계된 IT Governance로 확대할 필요가 있음. 특히 CobiT에서 제시하는 KPI 뿐만 아니라 KGI 지표를 감리에 반영하는 것이 바람직할 것으로 판단됨 • IT Governance Maturity 개념을 반영하여 감리 목적/감리 대상 등에 따라 감리의 수준을 달리하는 방안도 고려할 필요가 있음

 

ISO/IEC 9126/14598 (1/2)

[ISO/IEC 9126-1:2001] Software engineering Part 1: Quality model

구분	상세
대상	• 소프트웨어 제품(software product) - end product 및 intermediate product
목적	• 소프트웨어 제품의 품질(정해진 요구사항들을 충족시킬 수 있는 정도) 평가 - 중간산출물의 품질 평가 목적 ∙ 개발기관이 작성한 중간산출물의 인수 여부를 결정 ∙ 특정 프로세스의 완료 여부와 제품을 다음 프로세스로 이관할 시기를 결정 ∙ 최종 제품의 품질을 예측하거나 추정 - 최종 제품의 품질을 평가하는 목적 ∙ 제품의 인수 여부 결정 ∙ 제품의 릴리스 시기 결정 ∙ 특정 제품을 다른 제품들과 비교 ∙ 여러 제품 중에서 하나의 제품을 선정 ∙ 제품이 사용될 때의 긍정적인 효과와 부정적인 효과를 평가 ∙ 기존의 제품을 개선하거나 대체할 시기를 결정
이해 관계자	• 평가수행자 - 평가결과사용자 - 개발자(developer) - 관리자 - 구매자(acquirer) - 개발자/유지보수자/분석가 - 독립적인 평가자 - 프로세스 개선 담당자
기준	품질 특성(6개의 품질특성 및 27개의 하위 특성)

 

ISO/IEC 9126/14598 (2/2)

ISO/IEC 9126 & 25010 국문 정의 및 모델

구분		상세
체계	지침	∙ 9126-1: 품질 특성 및 부특성  ∙ 9126-2: 외부 메트릭  ∙ 9126-3: 내부 메트릭  ∙ 9126-4: 사용품질 메트릭  ∙ 14598-1: 개요 ∙ 14598-2: 기획 및 관리 ∙ 14598-3: 개발자를 위한 프로세스 ∙ 14598-4: 구매자를 위한 프로세스 ∙ 14598-5: 평가자를 위한 프로세스 ∙ 14598-6: 평가모듈의 문서화
	절차	1. 평가 요구사항 설정 2. 평가 명세 3. 평가 설계 4. 평가 수행
	자격	평가는 개발자, 구매자 조직의 내부 인력이 수행할 수 있음 • 독립적인 평가의 경우에도 특별한 평가원의 자격 제시
시사점		• 감리 대상영역별로 프로세스와 제품에 관련된 점검사항을 구분할 필요가 있을 것으로 판단됨 • ISO/IEC 9126의 제품 품질 특성 및 메트릭을 참조하여 감리 점검항목 또는 체크리스트에 수용할 필요가 있음 • ISO 14598-3에서 제시하는 절차, 기법 등은 개발 감리에서 참조 가능함 • ISO 14598-4에서 제시하는 절차, 기법 등은 최종 감리에서 참조 가능함 • 감리 목적/감리대상/감리수행주체별로 맞춤화된 기준/지침(평가 수준 포함)의 수립이 필요하다고 판단됨

 

CMMi(1/2)

[CMMi] Capability Maturity Model Integration : 능력 성숙도 통합 모델

구분	상세
대상	• 소프트웨어 개발 프로세스(Software Development Process) - Software Capability Determination and Software Process Improvement
목적	• 소프트웨어 개발 프로세스의 능력 평가(프로세스 및 조직단위 평가) - 조직단위 평가 ∙ 조직 단위의 성숙도를 0(Incomplete)에서 5(Optimizing)까지 6단계로 나누어서 평가함. ∙ 각 수준에서 정의된 25개의 프로세스 영역(Process Area) ∙ 기존의 SW-CMM의 능력(Capability) 차원(Dimension)임. ∙ 신뢰성이 높은 SW를 개발할 수 있는 조직의 능력수준을 평가함. ∙ 체계적인 프로세스 개선을 위한 방법을 제시함. - 프로세스 단위 평가 ∙4개의 카테고리(Support, Engineering, Project Management, Process Management), 25개의 프로세스 영역의 정의 ∙ 2차원의 구조의 SPICE 모형과 호환성을 가지는 측면이 추가됨. ∙ 기존의 SW-CMM에 SE, SS, IPPD 영역을 모두 포함할 수 있는 프레임워크 제시. ∙ 평가 대상 조직이 아닌 세부 프로세스 별로 평가가 가능함. ∙ 현재의 프로세스의 강점 및 약점을 파악하고 우선순위에 의한 프로세스의 개선.
이해 관계자	∙ 평가수행자 ∙ 평가결과사용자 - SEI에서 인증한 심사자 - 관리자 - 개발자/유지보수자/분석가 - 프로세스
기준	• 소프트웨어 개발 프로세스 특성(4개의 프로세스 카테고리 및 25개의 주요 프로세스 영역)에 대한 정의 • 주요프로세스영역(KPA)는 달성 및 미달성으로 판정되고 성숙도 수준을 달성하기 위해서는 해당 KPA와 하위수준의 KPA를 모두 달성해야 함. • 소프트웨어 개발능력 별 목적(Generic Goal)과 행동지침(Generic Practice)에 대한 평가

 

CMMi(2/2)

구분		상세
체계	지침	• 2가지 측면에서의 평가(Staged vs Continuous) - Staged 측면 • Level 0 - Level 5: 각 단계별로 제시된 목적과 주요행동지침에 대한 평가 • 조직의 성숙도 정도를 0-5단계로 나타냄. - Continuous 측면 • 4개의 카테고리(Support, Engineering, Project Management, Process Management)와 25개의 프로세스 영역을 정의하고 평가함. • 조직의 사업목적에 따라서 특정 프로세스 평가에
	절차	1. 심사입력: 심사 후원자, 목적, 범위, 제한조건, 책임, 추가적 고려사항 등 2. 심사활동: 계획, 자료수집, 자료검증, 심사모형 적용, 프로세스 평가, 보고 등 3. 심사결과: 심사기록, 프로세스 개선에 관한 시사점
	자격	∙ 평가는 SEI에 인증한 Lead Appraiser 만이 할 수 있음. ∙ SEI는 Lead Appraiser를 양성하는 코스를 개설
시사점		• 감리대상 업체의 주요 프로세스 혹은 조직단위 별 평가결과를 활용하여 평가를 수행하도록 유도함. • 프로세스의 주요 카테고리 중에서 Engineering과 Project Management에 속하는 Generic Practice의 내용을 감리모형에 반영함. • CMMI에서 추구하는 시스템과 소프트웨어의 무난한 통합(Seamless Integration)의 원칙을 적극 활용함.

 

SPICE(1/2)

구분	상세
대상	• 소프트웨어 개발 프로세스(Software Development Process) - Software Process Assessment and Software Process Improvement
목적	• 소프트웨어 개발에 관한 능력 및 프로세스 평가(2차원의 구조): 주로 소프트웨어 조달, 공급, 개발, 운영, 유지보수, 지원활동에 대한 계획, 관리, 감시, 통제, 개선에 관련된 프로세스 평가모형. - 능력 평가: CMM의 성숙도를 기반으로 함. • 프로세스의 성숙도를 0(Incomplete)에서 5(Optimizing)까지 6단계로 나누어서 평가함. • 각 수준에서 정의된 프로세스 속성(Process Attribute)의 달성 여부로 평가. - 프로세스 평가: ISO/IEC 12207 프로세스 모형을 기반으로 함. • 5개의 프로세스 카테고리(Customer-Supplier, Engineering, Support, Management, Organization)로 구분하고 생명주기의 측면에서 Primary Life Cycle Processes, Supporting Life Cycle Processes, 그리고 Organizational Life Cycle Processes의 영역으로 나눔. • 프로세스와 능력의 2차원의 구조
이해 관계자	∙ 평가수행자 ∙ 평가결과사용자 - 심사자 교육을 통한 심사자 양성 - 관리자 - 현재 약 300명의 심사자 배출 - 개발자/유지보수자/분석가 - 프로세스 개선 담당자
기준	• 조직의 프로세스가 평가 대상: 프로세스 별로 6단계의 능력과 프로세스 속성(PA: Process Attribute)으로 평가결과를 나타냄. • PA는 F(Fully Achieved), L(Largely Achieved), P(Partially Achieved), N(Not Achieved)의 순위척도로 판정함. • 프로세스 별 능력수준은 해당 PA는 L 또는 F, 하위 능력수준의 PA는 모두 F이여야 함

 

SPICE(2/2)

구분		상세
체계	지침	• 평가기준이 되는 참조모형(Reference Model)과 심사대상 조직의 규모, 개발분야 등을 고려한 심사모형(Assessment Model)로 구분함. • 참조모형은 비록 SPICE의 근간 표준이나 구체적인 지표(Indicator)는 제시되지 않고 심사목적이나 조직특성을 반영한 구체적인 지표는 심사모형이 제시함으로써 기존의 평가모형을 사용할 수 있는 유연성 부여. • 조직에 대한 단일 성숙도가 아닌 프로세스 별로 능력수준을 제시하고 평가결과는 프로세스 프로파일로 문서화됨.
	절차	1. 심사입력: 심사 후원자, 목적, 범위, 제한조건, 책임, 추가적 고려사항 등 2. 심사활동: 계획, 자료수집, 자료검증, 심사모형 적용, 프로세스 평가, 보고 등 3. 심사결과: 심사기록, 프로세스 개선에 관한 시사점 등
	자격	• 평가는 표준안에서 정의한 교육내용을 이수한 심사자가 할 수 있음. • 2002년 이후 국제적인 연대를 통한 심사자 교육, 벤치마킹에 의한 활성화 방안 제시
시사점		• ISO/IEC 15504 IS(2004년에 발표될 SPICE의 차세대 모형)의 주요 변화는 (1) 소프트웨어 프로세스 평가에서 프로세스평가로 변경이 되고, (2) 참조모형의 강화, (3) 기존의 다른 진영의 평가모형과의 호환성 제고 등으로 언급할 수 있음. • 감리모형의 개발에서도 초점을 소프트웨어 프로세스에서 지원 및 경영 등의 품질에 관련된 프로세스도 포함할 수 있는 방안 강구 • 참조모형의 장점은 기존의 각 조직에서 사용될 수 있는 평가모형을 활용할 수 있다는 점인데, 본 감리모형에서도 유연성을 부여한 참조모형의 개념인 프레임워크를 제시할 필요가 있음

 

ITIL

구분	상세
대상	IT 서비스 및 관리
목적	• 기업 및 고객의 현재와 미래의 요구에 적합한 IT 서비스의 제공 • IT 서비스 제공의 질 향상 • 서비스 제공에 대한 장기 비용
이해 관계자	∙ IT Director ∙ 시스템 개발자 ∙ 현업 관리자 ∙ 시스템 유지보수 인력 ∙ 최종 사용자 ∙ 시스템 테스트 담당 인력
기준	ITIL은 평가를 위한 모델이 아니라 IT 서비스의 best practice를 제시

구분		상세
체계	지침	• Business Perspective • ICT Infrastructure Management • Service Support • Service Delivery • Planning to Implement Service Management • Application Management • Security Management
	절차	• 해당사항 없음(ITIL은 평가 모델이 아님)
	자격	• 평가원은 아니지만, ITIL에 대한 자격 시험이 존재하여 시험을 통해서 다음과 같은 3가지 종류의 자격증을 발부하고 있음 - Foundation Certificate in IT Service Management - Practitioner Certificate in IT Service Management - Manager's Certificate in IT Service Management
시사점		• ITIL은 IT Process 평가 지침이나 절차를 제공하고 있지는 않지만, IT 서비스 제공에 관련된 거의 모든 Process에 대한 best practice를 제공하고 있기 때문에 정보시스템 감리 점검 항목 및 체크리스트 수립시 참조 가능함 - Service Support 및 Service Delivery는 운영 감리에서 참조 가능함 - Application Management는 개발 감리에서 참조 가능함

 

PMO

구분	상세
대상	∙ 기업 내의 모든 수행 중인 프로젝트 ∙ 기업 내의 프로젝트 지원체
목적	∙ 효율적인 프로젝트 관리 ∙ 프로젝트 위험도 제거 및 성공률 제고 ∙ 기업의 성과 유도
이해 관계자	∙ 프로젝트 관리자 ∙ 시스템 개발자 ∙ 현업 관리자 ∙ 시스템 유지보수 인력 ∙ 시스템 테스트 담당 인력
기준	∙ PMO는 평가모형이 아닌 소프트웨어 품질을 향상시키는 프레임워크임

구분		상세
체계	지침	∙ 프로젝트 관리의 표준 및 방법개발 ∙ 과거 프로젝트 기록 관리 ∙ 프로젝트 지원 ∙ 프로젝트 관리에 대한 컨설팅 ∙ 프로젝트 관리에 대한 지식확산(재교육)
	절차	∙ 해당사항 없음
	자격	∙ PMP 자격증
시사점		∙ PMO는 평가 지침이나 절차를 제공하고 있지는 않지만, 소프트웨어 품질에 관련된 best practice를 제공하고 있기 때문에 정보시스템 감리 점검 항목을 결정할 때 참조가 가능함 - 프로젝트 관리의 성숙정도 - 소프트웨어 품질에 관련된 지원시스템

정보시스템감리 개론

요약 : 소프트웨어어 qa, 웹 qa, 앱 qa, 소프트웨어 테스트 자동화, 자동화 소프트웨어, pm 교육, 비즈니스 소프트웨어, 소프트웨어 공학 프로젝트, audit, auditer