서비스운영조직에서의 CMMI 적용방안tqms.co.kr/wordpress/wp-content/uploads/2015/07/서비스... · 2015. 7. 14. · CMMI 모델은한가지사업영역에국한되지않음

1 Version 1.0

서비스 운영 조직에서의 CMMI 적용 방안(How to apply CMMI to System Maintenance Organization)서비스 운영 조직에서의 CMMI 적용 방안(How to apply CMMI to System Maintenance Organization)

2005. 6. 24.

㈜ 티큐엠에스

2 Version 1.0

발표 목적 및 차례

목적- 서비스 운영 조직의 프로세스 개선 활동 수행 시, 고려해야 할 사항에 대한 이해- 이를 통한, 효과적인 프로세스 개선 활동 방법 이해

차례- 서비스 운영(유지보수) 활동 개요- CMMI의 이해- 서비스 운영 조직에 적용하는 방안

일러두기

© 본 발표 자료의 저작권은 ㈜티큐엠에스의 소유이므로, 본 발표 이외의 용도로는 내용의 일부 또는전부를 무단으로 사용하거나 복제할 수 없습니다.

☞본 발표 중, 사용되는 일부 내용은 발표자의 경험과 지식을 근간으로 작성됨에 따라 특정 기업에는적절하지 않을 수 있습니다.

☞ CMM Integration and CMMI are Service Marks of Carnegie Mellon University.

3 Version 1.0

발표 순서

서비스 운영(유지보수) 활동 개요

CMMI의 이해

서비스 운영 조직에 적용하는 방안

4 Version 1.0

서비스 운영(유지보수) 업무

서비스 운영 그룹 시스템 고객

• 서비스 추가• 서비스 보완• 서비스 변경

• 서비스 삭제• 결함 제거• 장애 해결

• 모니터링

• 서비스 제공

서비스 요청

5 Version 1.0

현재의 IT 의미

“IT is the business” and “The business is IT”

6 Version 1.0

서비스 운영 그룹

BusinessGoal달성

BusinessGoal달성

원활한비즈니스

수행

원활한비즈니스

수행

높은 가용성, 신뢰성유지보수성 제공

높은 가용성, 신뢰성유지보수성 제공

고객 만족높은 신뢰

고객 불만낮은 신뢰

영속적인비즈니스

영속적인비즈니스

낮은 가용성, 신뢰성유지보수성 제공

낮은 가용성, 신뢰성유지보수성 제공

비즈니스에대한

악영향

비즈니스에대한

악영향

잦은IT Stop!

잦은IT Stop!

BusinessStrop!

BusinessStrop!

서비스 운영과 비즈니스와의 관계

7 Version 1.0

서비스 1 서비스 2

서비스3

신규 서비스

서비스 운영팀

서비스 운영 담당자

서비스 운영 조직에서는 단순 개발로부터 프로젝트 성격의 개발까지 다양한 크기의 업무가

지속적으로 발생함

서비스 운영에서의 개발 활동

결함 및 장애결함 및 장애

서비스 운영 담당자

변경변경

8 Version 1.0

고객

서비스 운영조직

• 과중한 업무 요청• 촉박한 일정 및 인력 부족• 복잡해져만 가는 시스템• 잦은 변경• 빈번히 발생되는 장애 및 장애

해결의 어려움

• 과중한 업무 요청• 촉박한 일정 및 인력 부족• 복잡해져만 가는 시스템• 잦은 변경• 빈번히 발생되는 장애 및 장애

해결의 어려움

• 불안정한 서비스• 서비스 운영 활동의 투명성 부족• 원가 절감 대두• 시스템 오픈 지연으로 인한

비즈니스 지연

• 잦은 장애 및 복구 지연으로 인한비즈니스 중단

• 불안정한 서비스• 서비스 운영 활동의 투명성 부족• 원가 절감 대두• 시스템 오픈 지연으로 인한

비즈니스 지연

• 잦은 장애 및 복구 지연으로 인한비즈니스 중단

• 의사소통의 어려움• 과장된 정보 소통• 수동적 업무처리• 성과에 대한 불신• 품질활동의 불인정

• 의사소통의 어려움• 과장된 정보 소통• 수동적 업무처리• 성과에 대한 불신• 품질활동의 불인정

상호불신증대

서비스 운영에서의 현상

9 Version 1.0


CMMI의 이해


발표 순서

10 Version 1.0

•Organizational Process Focus•Organizational Process Definition

•Organizational Training

프로젝트 관리 영역 엔지니어링 영역 지원 영역 프로세스 관리 영역

Level2Managed

Level3Defined

Level4Quantitatively

Managed

Level5Optimizing

•Measurement and Analysis•Process and Product Quality Assurance

•Configuration Management

•Project Planning•Project Monitoring and Control•Supplier Agreement Management

•Integrated Project Management for IPPD

•Risk Management•Integrated Teaming•Integrated Supplier Management

•Organizational Process Performance

•Quantitative Project Management

•Requirements Management

•Requirements Development•Technical Solution•Product Integration•Verification•Validation

•Decision Analysis and Resolution

•Organizational Environment forIntegration

•Organizational Innovation and Deployment

•Causal Analysis and Resolution

CMMICMMI

CMMI 요건

개발 운영 지원 영역개발 및 운영 영역개발 관리 영역

11 Version 1.0

CMMI 모델은 SI 사업에서만 적합한 모델이 아닌가?CMMI 모델은 SI 사업에서만 적합한 모델이 아닌가?

CMMI 모델은 한가지 사업 영역에 국한되지 않음Software 개발의 본질은 같음기존 SI에서의 사례를 따르는 것만이 CMMI 모델을 만족시키는 것은 아님HOW 적 측면에서 다를 수 있음조직에 따른 HOW를 찾고 그에 따른 Tailoring이 관건임

일반적 오

해

서비스 운영 조직에 CMMI 적용 시의 일반적 오해 (1/2)

12 Version 1.0

서비스 운영 조직에 CMMI 적용 시의 일반적 오해 (2/2)

각 Level 별, PA 별로 프로세스를 개선해야만 하는 것인가?각 Level 별, PA 별로 프로세스를 개선해야만 하는 것인가?

CMMI는 개선 모델이라기 보다 평가를 위한 모델에 가까움프로세스 개선 활동은 복합적인 접근이 이루어져야 함

개발 활동은 유기적으로 연결되어 있으므로 CMMI 각 프로세스 영역간의연관관계를 이해하고 있어야 실질적인 개선 활동이 이루어짐

해당 Level에서의 프로세스 영역간 유기적인 연관을 가진 활동과 다음Level을 대비한 개선 활동이 동시에 이루어져야 함CMMI 모델에서 제시하는 프로세스 영역에 집착하는 개선보다 현재의문제점을 파악하고 개선하는 것이 더욱 중요함

일반적 오

해

13 Version 1.0

성공적인 CMMI 적용을 위한 초기 고려 사항

고객 및 서비스 운영 조직 내부의 Commitment 확보고객과 서비스 운영 조직 모두의 변화 필요

서비스 운영 조직의 적극적 참여뿐만이 아니라 고객의 적극적 참여 필요

고객은 서비스 운영 조직의 품질 활동을 인정

상호 협력을 통해서만 실질적인 개선 가능

고객서비스 운영조직

상호 변화

상호 협력

능동적 참여

Commitment 확보

상호 변화

상호 협력

능동적 참여

Commitment 확보

Successful Process Improvement!!!Successful Process Improvement!!!

14 Version 1.0

서비스 운영 조직에서 CMMI 적용 시의 어려운 점들

• 형상 관리는 어떻게 적용하는가?• 품질 보증은 어떻게 적용하는가?• 측정 및 분석 활동은 무엇을,

어떻게 해야 하는가?• 개발 지원 영역의 실질적 개선을

위하여 그 외 필요한 것은?

• 기존 시스템에 대한 분석/설계는 존재하지않는데…

• 시스템 운영 상에서의 요구사항 관리는?• Verification과 Validation은 어떻게 적용을

할 것인가?• 기타 서비스 운영 조직에서 개발 운영에

대한 실질적인 개선을 위하여 필요한것은 무엇인가?

CMMICMMI

개발관리 영역

개발관리 영역

개발 및운영 영역개발 및

운영 영역

개발운영지원 영역개발운영지원 영역

• 어떤 단위로 관리를 해야 하는가?• 계획은 어떻게 시작을 할 것인가?• 어떻게 견적을 하는가?• 추적 활동은 어떻게 적용할 것인가?

15 Version 1.0


CMMI의 이해


개발 관리 관점

개발 및 운영 관점

개발 및 운영 지원 관점

발표 순서

16 Version 1.0

적용방안적용방안

계획 및 견적

계획의 단위

계획의 적용 방안

견적의 적용 방안

고객 서비스 요청 단위의 계획 및 견적 수행

고객 서비스 요청에 대한 업무 등급제 도입

상위 경영층의 확고한 Commitment가 요구됨 계획 활동의 제도화 (초기에는무조건적 수행, 강약의 문제임)주요 수행 활동의 파악

고객과 개발자 관점에서의 견적 기준 수립

초기의 기준은 업무 완료 후 실제 값과 비교하여 보정

업무 규모의 경우 업무 완료 후 FP, LOC, 본 등의 기법을 활용한 규모 실측치 측정개발 표준 정의

투입 공수의 단위로 M/H 사용견적에 대한 데이터 공유

업무 계획은 개개인의 계획으로부터 시작

적용문제적용문제

17 Version 1.0

업무 등급제 도입

고객의 업무 요청 별 업무량에 대한 등급을 지정하는 것으로 업무량 판단의 기준이 됨

고객 및 서비스 운영 조직간 업무량에 대한 공통된 이해 기준이 마련됨

제공 서비스 구분에 따라 M/H 또는 M/D를 기준으로 등급을 나누도록 함고객과 업무에 대한 합리적 일정 타협이 이루어지게 됨

향후 어느 정도의 업무를 얼마만큼 수행했는지에 대한 데이터 확보가 가능함

프로세스에 대한 테일러링 기준으로 사용

상위 등급(대규모)의 경우 별도의 견적 활동이 이루어져야 함실제 데이터와의 비교를 통한 등급 기준 데이터의 보정이 무엇보다 중요함

등급 기준

1등급 1m/m 이상(20m/d 이상)

2등급 10m/d 이상 20m/d 미만

3등급 5m/d 이상 10m/d 미만

4등급 1m/d 초과 5m/d 미만

5등급 8m/h 이하

프로젝트 성 개발프로세스

단순 개발및 운영 프로세스

경험 orSize측정

기준

업무 요청업무 요청

Illustr

ative

18 Version 1.0


추적 및 모니터링 적용 방안

고객 서비스 요청 단위로 추적 및 모니터링 수행

전체 고객 서비스 요청 처리 현황에 대한 뷰와 서비스 요청건별 처리 현황에 대한 뷰의

마련 필요

개개인의 일일 업무 실적기록을 기반으로 이루어짐

TIME TRACKING 시스템의 도입 필요상위 경영층의 확고한 Commitment 필요 실적 기록의 제도화데이터에 의한 의사소통 체계 구축 데이터 수집 및 분석 체계 강화, 데이터에 의한보고체계

고객 서비스 요청에 의한 업무와 일상적인 업무의 비중 파악


추적 및 모니터링

19 Version 1.0

Time Tracking System 구축

수기로 기록하고 취합, 분석하는 데에 많은 시간과 노력이 소요되므로 자동화된 시스템 적용이필수

현재 빈번히 일어나는 활동을 파악하여 수행 활동의 종류를 정의하는 것으로부터 시작

간단한 분류로 시작하여 점차 분석을 통하여 분류 체계를 확장

수행 활동에 대한 일일 기록을 제도화

업무 계획 및 실적 기록을 동시에 할 수 있도록 함

자동화된 시스템 적용을 통해 정확하고 빠른 분석 결과를 얻을 수 있음

Time Tracking System서비스 운영 조직원

활동 계획계획 시간수행활동수행 시간

활동 계획계획 시간수행활동수행 시간

활동 분석투입 시간분석계획력 분석

활동 분석투입 시간분석계획력 분석

Illustr

ative

20 Version 1.0

서비스 운영 조직 상태보고서 예

Illustr

ative

21 Version 1.0

CSR : Customer Service Request(고객 서비스 요청) 자동화 적용

업무 요청 처리 프로세스

정확한 업무량 파악을 위해서 고객 서비스 요청 접수 창구를 단일화

서비스 운영조직고객

서비스요청발생

서비스요청발생

업무등급 결정

업무등급 결정

CSR작성

CSR작성

CSR접수

CSR접수

업무등급 확인

업무등급 확인

업무처리계획 협의업무처리계획 협의

업무 처리계획 수립

업무 처리계획 수립

업무 처리업무 처리

보고보고

업무 완료업무 완료

Illustr

ative

22 Version 1.0

업무 처리 현황 분석

업무 처리 현황에 대한 분석을 통해 서비스 운영 조직의 인원 적절성(인원수, 역량), 업무 처리방식의 적절성, 현재 운영상의 문제점 등을 파악할 수 있음데이터에 대한 검증도 동시에 이루어져야 함

업무 처리 현황 분석 활동을 통하여 조직의 계획 능력을 향상 시킬 수 있음

서비스 운영 조직의 업무 처리에 대한 실제 현상 및 문제점을 객관적으로 판단할 수 있음

분석 결과를 고객과 공유함으로써 투명한 서비스 운영 업무가 가능해짐

분석 항목

업무 구분별 등급별 처리 건수 및 비율 분석

업무 구분별 등급별 처리 투입 공수 분석

고객 요청 업무 대비 일상 업무 비율 분석

업무별 적시 제공율 분석

업무별 납기 지연율 분석

계획 대비 실적 오차율 분석

업무 등급과 실제 업무 규모(FP, Loc, 본, 기타단위)와의 비교 분석

업무 처리 현황 분석업무 처리 현황 분석

Illustr

ative

23 Version 1.0


CMMI의 이해





발표 순서

24 Version 1.0


요구사항 관리에 대한 방안

분석 설계 적용에 대한 방안

Verification과 Validation 적용 방안실질적 개선을 위하여 그 외로 적용되어야 할 사항


개발 및 운영

요구사항 관리

고객 서비스 요청 자체를 요구사항으로 간주하고 관리

시스템에 대한 기능별 관리가 이루어져야 함

분석 및 설계

개선 활동 시작 이후의 개발 서비스 : 분석/설계 활동의 규정화개선 활동 시작 이전의 서비스 : 서비스 즉 기능에 대한 상호 연관성과 기능에 대한 구성요소(화면, 코드, 데이터) 연관성을 파악함. 일부 기능에 대한 선택적 분석/설계 역 작업개발자 인식의 변화 유도

Inspection과 Test의 체계화 및 제도화이관 관리활동 강화

장애 및 문제 관리 활동 강화

재사용성 증대

25 Version 1.0

CSR 접수관리 시스템

요구사항 관리

서비스 운영 조직에서는 두 가지의 관리가 이루어져야 함

고객 서비스 요청 관리

기능 관리

고객 서비스 요청 관리는 고객 측면의 요구사항을 관리하는 것임

기능 관리는 개발 측면의 요구사항 즉 기능에 대한 구성요소와의 맵핑을 관리하는 것임

자동화된 시스템의 지원을 통해 보다 원활히 수행할 수 있음

더 나아가 기능에 대한 결함 및 장애 건수와 맵핑하여 관리할 수 있음

고객

CSR 변경관리

CSR1

CSR2

CSRn

.

.

기능분류

기능A

기능B

기능Z

.

.

분석/설계문서

화면

A.CB.C

코드 데이터

장애

테스트케이스결함 정보

Illustr

ative

CSR 관리 기능 관리

26 Version 1.0

기존의 시스템에 대한 분석/설계 문서를 역으로 작업하는 일은 상당한 노력과 시간이 소요되는활동이므로 모든 기존 시스템에 대한 분석/설계 문서를 만드는 것은 현실적으로 어려움기존 주요 서비스나 시스템에 대하여 선택적으로 수행함

신규 개발일 경우 무조건적으로 수행하도록 함 (수행의 문제가 아닌 강약의 문제임)기존 시스템의 경우 기능에 대한 상호 연관표와 기능에 대한 구성요소간의 연관표로 분석/설계문서를 대체함

분석 및 설계

서비스 1 서비스 2

서비스3

신규 서비스

기존 시스템

신규 개발

기능 연관성 파악

A.CB.C

기능, 화면, 코드, 데이터 연관성 파악

분석 설계 규정화 분석 설계 수행

중요 모듈

27 Version 1.0

TestTest

Verification과 Validation

Verification과 Validation의 적절한 연계 운영이 중요함개발 초기부터 운영까지 모두 고려되어야 함

Inspection과 테스트의 전략적 대상 선정이 필요함개발의 규모 및 중요도에 따라 다양한 Inspection 및 테스트 절차가 마련되어야 함회귀 테스트(Regression Test) 강화 : 변경으로 인한 장애 발생을 최소화Inspection 및 테스트에 대한 결과 데이터의 관리 및 활용 강화Checklist와 Test Case는 형상관리 하에서 관리하며, 지속적인 현행화가 이루어져야 함결함 데이터의 분석은 제품 및 프로세스 개선의 필수적인 요소임

InspectionInspection

TestTest

장애 및 결함정보

대상 및

방법선정

결과 정보

결과 정보

공유 활용

정보 분석

• Inspection 및 Test에 대한 전문 교육 수행• 인식의 전환 필요• 코드 뿐 아니라 요구사항, 분석, 설계문서에 대해서도 수행함

• Checklist와 Test case는 형상관리하에서관리함

• 운영 환경에서 회귀테스트는 필수• 개발 초기부터 고려되어야 함

28 Version 1.0

이관 관리 활동 강화

이관이란 개발된 시스템을 개발 환경에서 실제 운영 환경으로 옮기는 활동을 의미함

이관활동은 형상관리 활동의 일부분 이기도 함

이관의 통제는 무분별한 변경의 통제와 검증 활동의 강화를 의미함

긴급 이관과 정상 이관 두 가지의 프로세스가 마련되어야 함

이관에 대한 정보(이관일, 이관자, 이관 대상, 이관사유)도 기록 관리되어야 함

개발 환경 운영 환경

이관이관

단일화된 창구

• 무분별한 변경 통제• 검증 활동 강화

29 Version 1.0

장애(Incident) 및 문제(Problem) 관리 활동 강화

해결되지못한 사항

Incident 관리Incident 관리 Problem 관리Problem 관리

Incident관리 개요Incident관리 개요

주요목적주요목적

서비스를 중단 또는 품질저하를 발생시킬 수 있는장애에 대한 신속한 복구를통한 서비스 연속성 확보

서비스 연속성 확보를 위한빠른 서비스 복구 및 이를통한 고객 업무지원 및생산성 증대

문제 관리개요

문제 관리개요

주요목적주요목적

문제의 근본 원인을 제거함으로써 동일/유사 문제의재발을 방지하여 서비스의안정성을 추구함

근본 원인 분석해결안 마련유사 장애 발생의 예방

서비스 운영 조직에서는 발생한 장애에 대한 빠른 해결과 동시에 그에 대한 근본 원인 파악/ 제거활동도 중요함

전자를 장애 또는 사건(Incident) 관리라 하며, 후자를 문제(Problem)관리라 함ITIL( Information Technology Infrastructure Library)의 개념이나 서비스 운영 조직에 적용 시유용함

30 Version 1.0

재 사용성 증대

조직 내 재사용성 향상은 곧 생산성 증가로 연결

재사용의 대상은 코드 뿐 아니라 문서도 포함

아키텍처 체계 및 개발 표준의 정의로부터 출발

재사용이 명확한 대상은 개발 표준에 포함 시킴

재사용 모듈에 대해서는 조직 차원의 관리 필요

재사용 모듈의 식별 및 활용을 위한 별도의 정책 및 절차 필요

재사용 모듈식별

재사용 모듈식별

저장소조직 개발

표준조직 개발

표준

적용

적용

적용

적용

31 Version 1.0


CMMI의 이해





발표 순서

32 Version 1.0


형상관리 적용 대한 방안

품질보증 적용에 대한 방안

측정 및 분석 적용 방안

실질적 개선을 위하여 그 외로 적용되어야 할 사항


서비스 운영 조직 전체 또는 서비스 별로 프로젝트로 간주하여 적용

대형 신규 개발과 운영상의 개발(단순 개발 포함)은 다른 프로세스를 사용품질 감사를 위한 내부 전문인원의 순환 활용

품질 감사를 통한 형상 감사 수행

조직에 영향을 줄 수 있는 최소한의 항목으로 측정/분석을 시작프로세스의 자동화 적용

개발 지원

33 Version 1.0

상세 적용 방안상세 적용 방안

서비스 별 또는 서비스 운영

조직 전체를 하나의 프로젝트로

간주하여 적용

고객 서비스 요청에 따른 개발

별로 형상 관리 계획 및 감사를

실시하는 것이 아니라 정기적인

이벤트로써 수행하도록 함

(대규모 개발 제외)ex) 형상 관리 계획 – 1년 주기

형상 감사 – 1달 주기형상 감사는 주기적인 품질

감사활동으로 대처하여 수행 할

수 있음

고려 사항고려 사항

대규모 개발이 발생할 시에는

별도의 프로젝트로 간주하고

별도로 진행

관리하는 서비스가 많을 경우

서비스 단위 별로 관리

서비스 운영 조직에서는 개발 중의

형상관리 뿐 아니라 오픈 후의

형상관리도 중요

서비스 운영 조직에서는 특히

변경에 대한 영향 평가가 무엇보다

중요

형상관리 도구의 도움 필요

개발자의 인식변화와 습관화가

무엇보다 중요

형상 관리 활동

34 Version 1.0

상세 적용 방안상세 적용 방안 고려 사항고려 사항

서비스 별 또는 서비스 운영 조직

전체를 하나의 프로젝트로

간주하여 적용

품질 감사 조직이 별도로 구성되는

것이 바람직하나, 조직 구조 상어려울 경우 주기적으로 품질 감사

인원을 선발하여 품질 감사 활동을

수행하도록 하는 것도 가능

고객 서비스 요청에 따른 개발 별로

품질 보증 활동 계획 및 감사를

수행하는 것이 아니라 정기적인

이벤트로써 수행(대규모 개발 제외)ex) 품질 보증 계획 – 1년 주기

품질 감사 – 1달 주기

대규모 개발이 발생할 시에는

별도의 프로젝트로 간주하고

별도로 진행

품질 감사 활동에 선정된

인원에게는 별도의 보상 마련

매 감사 시 모든 부분을 감사하는

방법과 시점 별로 정해진 항목에

대해서 감사하는 방법이 있음

프로세스(Process) 이행 뿐아니라 프로덕트(Product : 산출물 포함) 자체에 대한 검토도필요

품질 보증 활동

35 Version 1.0

측정 및 분석

적용 원칙적용 원칙

“If you don’t measure it, you can’t manage it”“If you don’t measure it, you can’t improve it”“If you don’t measure it, you probably don’t care”“If you can’t influence it, then don’t measure it”

적용 방안적용 방안

측정에 대한 목표가 명확한 사항에 대해 측정

너무 많은 것을 측정하려 하지 말 것

데이터 축적 및 활용의 습관화

데이터에 의한 의사소통

데이터 분석 전문가 양성 및 배치

36 Version 1.0

계획계획

분석분석

설계설계

빌드빌드

테스트

테스트

모니터링모니터링

종료종료

서비스 개발 및 운영서비스 개발 및 운영

이행이행

통계 DB

CSR관리

시스템

결함관리

시스템

품질 경영시스템

(지식관리)

고객만족도조사

시스템

비기능테스트 툴

기능테스트 툴

품질보증로봇

디버거 /코드

분석 툴

형상 관리시스템

기능관리

시스템

재무시스템

영업 관리시스템

공급업체관리

시스템

•선정 기준

•범위•위험•제약사항

•매출•예산•수익

•비용•경비

•변경예산•경비

•통계치

•견적치•근거•가정사항

•형상정보

•변경정보

•표준프로세스

•투입공수 •재작업

•공급업체 정보

•평가정보•계약 •계획

•등급•진척•리스크•이슈

•투입공수 •결함정보•장애 및 문제정보•재작업

•부적합 사항•시정조치

•결함

•결함

•고객만족도•내부고객만족도

•소스코드

•테스트시나리오•테스트케이스•데이터



•이행 경험•우수 사례

견적 툴

TC관리시스템

•부하•성능•볼륨

•변경사항•이력 정보

시간 관리시스템

•변경사항

•기능정보

프로세스 자동화

Illustr

ative

교육관리시스템

37 Version 1.0

10010

끝마치기 전에…

10010

아직 90이나..

벌써 10이나..

WINNER

38 Version 1.0

질의/응답

서비스운영조직에서의 CMMI 적용방안tqms.co.kr/wordpress/wp-content/uploads/2015/07/서비스... · 2015. 7. 14. · CMMI 모델은한가지사업영역에국한되지않음

Documents