2003년도 제1630호 NHNN 결정은 은행업무 소프트웨어 가공 및 구매 기술기준을 규정함에 관한 사항을 발표한다.

2003년도 제1630호 NHNN 결정은 베트남 중앙은행이 은행업무 소프트웨어 가공 및 구매 기술기준을 규정함에 관한 사항을 발표하였다. 이 규정은 중앙은행과 금융기관들에게 적용되며, 정보기술을 은행업무에 안전하고 효과적으로 도입하기 위한 목적으로 사용된다.

Document No.1630/2003/QĐ-NHNN
Document type결정
Issuing authority베트남 국가은행
Signed byVũ Thị Liên — Phó Thống đốc
Updated30/06/2026
Sector은행
Field은행정보기술
Issued date19/12/2003
Effective date14/01/2004
Expiry date
Status발효 중
✦ Smart summary

2003년도 제1630호 NHNN 결정은 베트남 중앙은행이 은행업무 소프트웨어 가공 및 구매 기술기준을 규정함에 관한 사항을 발표하였다. 이 규정은 중앙은행과 금융기관들에게 적용되며, 정보기술을 은행업무에 안전하고 효과적으로 도입하기 위한 목적으로 사용된다.

Scope of application

베트남 중앙은행, 금융기관(예: 상업은행, 인민신용협동금고).

Key points

  • 은행업무 소프트웨어 관련 용어를 설명한다.
  • 은행업무에서 사용되는 소프트웨어는 사용권을 보유해야 하며 불법으로 변경, 복제할 수 없다.
  • 시스템 소프트웨어의 안전성 및 보안 요구사항.
  • 소프트웨어 설계 개방성 및 안정적인 운영 기준.
  • 소프트웨어 구현, 지원운영 및 구성 관리 프로세스.

🌐 Social impact of this document

  • 긍정적 영향: 정보기술을 은행업무에 안전하고 효과적으로 도입하여 서비스 품질을 향상시킨다.
  • 부정적 영향: 소프트웨어 투자 및 관리 비용이 증가할 수 있다.

❓ Frequently asked questions

은행업무 소프트웨어는 사용권을 어떻게 보유해야 하는가?

은행업무에서 사용되는 소프트웨어는 법령에 따라 사용권을 보유해야 한다. 불법으로 변경, 복제, 설계, 알고리즘, 기술 및 소스코드를 공개해서는 안 된다.

시스템 소프트웨어의 안전성 및 보안 요구사항은 무엇인가?

위험 요소를 분석, 설계 단계부터 평가해야 하며, 설치 및 운영 환경에 대한 기술 조건을 명확히 규정해야 한다. 또한 비정상 상황 처리 방안과 불법 접근을 통제하는 방법을 마련해야 한다.

소프트웨어의 설계 개방성 기준은 무엇인가?

프로그램은 하드웨어, 운영체제, 데이터베이스, 통신 등과 상대적으로 독립적으로 설계되어야 하며, 입력 요소를 파라미터화하고 기능별 모듈로 나누어야 한다. 미래에 다른 업무 소프트웨어와 연결성을 확보할 수 있어야 한다.

소프트웨어 구현 프로세스는 어떠한가?

설계, 구축, 구현, 지원, 운영 단계별 계획을 세우고, 업무분석 및 사용자 요구사항 분석, 시스템 소프트웨어 설계, 프로그래밍 및 테스트를 수행한다.

소프트웨어 구성 관리 규정은 무엇인가?

제품 구성 관리 문서를 작성하고, 변경 단계 및 마크를 정의한다. 제품 구성 변경을 관리하고 두 개 이상의 위치에 구성 제품을 저장한다.

Full text

베트남 국립 은행

사회주의 공화국 베트남
독립 - 자유 - 행복

번호: 1630/2003/QĐ-NHNN
하노이, 2003년 12월 19일


결정

은행업무 소프트웨어 가공 및 구매 기술기준에 관한 규정 제정
은행업무

국립 은행 총재

은행법 제01/1997/QH10호 1997년 12월 12일 및 금융기관법 제02/1997/QH10호 1997년 12월 12일을 근거로 함; 1997년 12월 12일 2/1997/QH10 호;
은행법 일부 개정 법률 제10/2003/QH11호 2003년 6월 17일을 근거로 함;
정부가 2002년 11월 5일에 발표한 제86/2002/NĐ-CP 호에 의거하여 각 부처와 정부 직속 기관의 기능, 임무, 권한 및 조직 구성을 규정함
은행 정보기술 cục장을 대표한 요청에 따라,

결정함에 있어서:

조 1. 본 결정에 부속하여 "은행업무 소프트웨어 가공 및 구매 기술기준에 관한 규정"을 제정함.

조 2. 本决定自公布于公报之日起十五日后生效。

조 3. 은행총국 사무처장, 은행총국 정보기술국 국장, 은행총국 소속 각 단위 책임자, 상업은행 총경리(총장), 중앙인민신용금고 총경리는 본 결정의 집행에 대한 책임을 지며 이를 준수해야 함./.

                                                                      통감

                                                                   부통감

                                                                                                    (서명)

                                                                   Vũ Thị Liên

 

규정

은행업무 소프트웨어 가공 및 구매 기술기준
(1630/2003/QĐ-NHHH 2003년 12월 19일 통감 은행총국 결정에 따라 제정)

조 1: 시험 참가 대상

총칙

조 1: 적용범위

1. 본 규정은 은행총국 및 금융기관(이하 단위라 함)의 은행업무 소프트웨어 가공, 구매, 배포 및 지원운영을 위한 기본 기술기준과 절차를 포함하며, 은행업무에 정보기술을 효과적으로 안전하게 적용하기 위해 통일된 관리를 목적으로 함.

2. 연구, 실험 또는 특정 장소에서만 사용되며 단위의 일반적인 은행업무 소프트웨어와 연결되지 않는 은행업무용 소프트웨어는 본 규정의 적용 대상이 아님.

3. 본 규정 외에도 은행업무 소프트웨어의 가공 및 구매는 국가가 정한 물품 및 서비스 구매 관련 규정을 준수해야 함.

조항 2: 용어 해석

본 규정에서 다음 용어들은 다음과 같이 해석됨:

1. 프로그램은 특정 언어로 작성된 명령집합으로, 직접 또는 간접적으로 컴퓨터나 정보 처리 능력을 갖춘 장치에서 실행되어 특정 결과를 얻기 위함임.

2. 소프트웨어는 프로그램, 기술 문서 및 프로그램에 관련된 데이터를 포함함.

3. 은행업무 소프트웨어는 은행 업무 활동의 일부 또는 전체를 자동화하기 위해 은행에서 사용되는 응용 소프트웨어임.

4. 패키지 소프트웨어는 일괄 생산되고 완성된 제품 형태로 판매되는 소프트웨어임.

5. 프로그램 모듈은 독립적으로 작성 및 검증된 프로그램의 일부로서, 다른 모듈들과 결합하여 완성된 프로그램을 구성함.

6. 오픈 소프트웨어는 국내외 산업 표준에 따른 높은 호환성을 가지며 시스템 변경 및 업무 요구사항에 적응할 수 있는 소프트웨어임.

7. 소프트웨어 버전은 소프트웨어 제품 출시에 연결된 숫자 시퀀스임. 버전은 주 버전과 업데이트 버전으로 나뉨; 주 버전은 첫 개발 이후 큰 구조적 및 기능적 변화가 있을 때 사용되며, 업데이트 버전은 오류 수정 및 새로운 요구사항 반영을 위해 사용됨.

8. 소프트웨어 사용권은 해당 소프트웨어를 이용하는 법적 권리를 인정하는 문서임.

9. 시스템은 특정 기준에 따라 조직적으로 통합된 소프트웨어, 장비 및 기타 관련 요소들의 집합으로, 공동 사용 효율성을 높이는 것을 목적으로 함.

10. 시스템 설계는 업무 요구사항 및 사용자의 요구사항을 세부적인 기술 모델로 변환하여 소프트웨어 개발을 지시하는 작업임.

11. 구성은 특정 기술 요구사항에 맞게 조정된 프로그램, 문서 및 데이터의 집합임.

12. 템플릿은 설계, 프로그래밍 또는 업무 처리 과정을 표현하는 모델로서, 실제 작업 수행 전에 아이디어를 시각화하고 평가하며 방향성을 제공함.

13. 프로그램 템플릿 라이브러리는 공유 및 재사용을 목적으로 수집된 표준 프로그램들의 집합임.

14. 소프트웨어 수정은 사용자의 요구사항에 맞게 소프트웨어의 구성 요소를 변경하거나 추가하는 작업임.

15. 소프트웨어 검사는 소프트웨어의 업무 처리, 프로그래밍, 인터페이스 또는 모듈간 상호작용에 대한 오류를 찾아내고 요구사항 충족도를 확인하는 작업임.

16. 검사 상황은 요소, 입력 데이터, 수행 조건 및 예상 결과를 포함한 요인들의 집합이다. 검사 상황은 프로그램의 특정 기능을 검사하거나 시스템의 부하 용량, 사용자의 요구사항 등을 검증하기 위한 특정 목표를 달성하기 위해 설정된다.

17. 검사 절차는 검사 상황을 설정하고, 수행하며, 결과를 평가하는 지침들의 집합이다.

18. 검사 프로그램은 검사 절차를 자동화하기 위한 프로그램으로, 프로그래밍 또는 테스트 도구를 통해 생성될 수 있다.

19. 업무 분석과 사용자 요구사항 분석은 업무 문제와 사용자 요구사항을 이해하고 설명하며, 그들 간의 관계를 분석하고 이러한 요구사항이 특정 환경에서 정보기술을 적용할 때 실현 가능성을 분석하는 과정이다.

20. 소프트웨어 배포는 기술적 해결책 연구, 절차 설정, 교육, 설치, 사용 가이드 제공, 초기화, 데이터 전환 및 소프트웨어 운영 시작 작업을 포함한다.

21. 소프트웨어 보증 및 유지보수는 변경 관리와 운영 지원을 통해 소프트웨어의 정확한, 원활한, 안전한 작동을 보장하는 작업이다.

22. 소프트웨어 구성 관리는 제품 소프트웨어의 설정, 보관, 배포 및 체계적인 변경 관리를 위한 도구이다.

23. 사용자는 프로그램을 운영하여 할당된 권한과 책임에 따라 업무를 수행하도록 지정된 사람이다.

24. 시스템 관리자는 시스템의 원활한, 안전한 작동을 관리하고 보장하도록 지정된 사람이다.

25. 업무 소프트웨어 제작은 업무 분석과 사용자 요구사항 분석, 시스템 설계 분석, 프로그래밍, 사용자 가이드 문서 작성, 테스트 및 소프트웨어 포장 과정을 포함한다.

조항 3: 소프트웨어 사용권

은행 업무용 소프트웨어는 법령에 따른 사용권을 가져야 하며, 이를 무단 변경, 복제, 설계, 알고리즘, 기술 및 소스 코드 공개 등 불법 사용을 엄격히 금지한다.

조 4: 소프트웨어 업그레이드

소프트웨어 업그레이드는 프로그램의 결함을 즉시 수정하고 업무 변화를 반영하며, 낡은 알고리즘 및 기술을 대체한다. 업그레이드 사이의 시간은 소프트웨어의 감가상각 기간을 초과하지 않아야 한다.

장 2:

은행 업무용 소프트웨어의 기초 기술 표준

조 5: 소프트웨어 기술 및 솔루션 선택

1. 업무 요구사항을 잘 충족시키고 실제 적용이 가능하며 장기적으로 사용할 수 있어야 한다.

2. 업무의 보안 및 안전 기준을 준수해야 한다.

3. 오픈 소스 시스템 소프트웨어 설계 표준을 준수해야 한다.

4. 기술 수준, 재정 상태 및 투자 자금의 효율적 사용에 적합해야 한다.

조 6: 보안 및 보호 요구사항

1. 시스템 분석 및 설계 단계부터 잠재적 위험을 평가하고 각 구성 요소와 전체 시스템의 중요도를 분류해야 한다.

2. 시스템 설치 및 운영을 위한 안전한 기술 및 환경 조건을 명확히 규정하고 완전히 구현해야 한다.

3. 업무 특성에 따른 최대 중단 시간 및 데이터 중요도에 맞는 사고 대응 방안을 마련해야 한다.

4. 불법 접근을 통제하고 발생한 결과를 신속하게 제거해야 한다.

5. 사용자의 업무 수행을 그들이 할당받은 역할에 따라 제한하고, 데이터 손실이나 시스템 작동에 영향을 미칠 수 있는 행동을 경고해야 한다.

6. 은행 업무에서 "비밀" 이상의 데이터 교환 시 원본 확인, 데이터의 무결성 보호 및 암호화를 위한 해결책을 제공해야 한다.

7. 데이터 암호화 소프트웨어 및 전자 서명 소프트웨어는 은행 업무에서 "최고 비밀" 제도에 따라 개발, 관리 및 사용되어야 한다.

조 7: 개방형 설계 및 안정적인 운영

1. 프로그램은 하드웨어, 운영 체제, 데이터베이스 및 통신 시스템의 구성 요소와 상대적으로 독립적이어야 하며, 입력 요소, 프로그램 설정 파라미터를 파라미터화하고 기능별로 모듈로 나누어 미래에 다른 업무 소프트웨어와 연결될 수 있어야 한다.

2. 안정적으로 실행되어 업무 요구사항을 충족하고 발생하는 모든 예외 처리를 처리해야 한다.

조항 8: 사용자 인터페이스

1. 프로그램 전체에서 화면 레이아웃, 색상, 메뉴, 폰트 및 아이콘, 기능 키 사용 규칙 등이 일관되게 적용되어야 하며, 프로그램의 입력, 출력 및 실행 방법이 통일되어야 한다.

2. 업무 범위, 작업 그룹 및 업무 순서에 따라 프로그램 기능을 배치하고 온라인 지원을 제공하며 불필요한 작업을 제거해야 한다.

3. 운용 중 발생할 수 있는 오류를 경고하고 제거하며, 사용자가 할당된 권한을 넘어서 업무를 수행하지 못하도록 막아야 한다.

제9조: 다른 업무 소프트웨어와의 인터페이스

1. 관련 업무 소프트웨어와 연속적으로 연결되어야 하며, 테스트 목적을 제외하고 정보 수집, 전송, 처리 및 저장에서 중복을 피해야 한다.

2. 동일한 업무 참조 대상에 대해 발행된 코드 세트를 일관되게 사용해야 한다.

3. 연결 시 안전을 보장하고 각 측의 데이터에 대한 불법 접근이나 간섭을 방지해야 한다.

조 제10조: 기술 문서

1. 프로그램과 함께 기술 문서를 발행해야 한다:

a) 운영 환경 및 예비 환경에서 사용되는 하드웨어, 네트워크, 운영 체제, 데이터베이스 및 기타 장비의 구성;

b) 프로그램 설치 및 운영 가이드;

c) 프로그램 및 데이터베이스의 저장 및 복원 가이드.

2. 처음 발행된 문서와 이후 업데이트 버전은 필요한 경우 쉽게 참조할 수 있도록 완전히 보관되어야 한다.

장 3:

은행 업무용 소프트웨어의 제작, 배포 및 운영 지원

조항 11: 계획, 검사 및 결과 이전

1. 설계, 구축, 배포, 지원, 운영 단계별 계획을 세우고 각 단계의 완료 시 결과를 검토하고 승인해야 한다.

2. 점검 계획 및 보고서는 범위, 목표, 시간, 인력, 비용 및 기타 수행 조건; 마커, 점검 기준 및 획득 결과를 포함한다.

조 제12조: 업무 분석 및 사용자 요구 분석

1. 업무 조사:

a) 사용자가 제공한 업무 규칙, 절차, 지침 등 업무 관련 문서 연구.

b) 조사할 문제와 질문 목록 작성.

c) 실제 업무 활동 조사 및 사용자 인터뷰.

d) 자료 수집 및 조사 보고서 작성.

2. 업무 분석:

a) 업무 요구사항, 조직 특성, 기술 환경, 법적 환경 및 사용자 특성을 분석.

b) 업무 처리 과정 모델링, 데이터 흐름 및 정보 실체 문서 작성.

3. 사용자 요구 분석:

a) 사용자의 관점에서 기능 요구사항, 운영 환경, 운영 요구사항 등을 문서화하고 분류.

b) 요구사항의 타당성, 일관성 및 합리성을 분석; 우선순위, 기준 및 요구사항 충족 조건을 결정.

c) 필요 시 모범 사례 작성.

d) 사용자와 협의하여 불합리하거나 실행 불가능한 요구사항 제거; 상충되는 요구사항 해결 및 새로운 요구사항 추가 연구.

4. 시스템 작업 설명 및 사용자 요구 사항 특징:

a) 현재 및 미래 예상 시스템의 구조, 작업, 작업 절차, 데이터 흐름, 제약 조건, 상황 및 대응 방안 문서화.

b) 사용자의 기능 요구사항, 인터페이스, 데이터 조직, 운영, 장비 요구사항 등을 기술하는 사용자 요구 사항 문서 작성.

c) 사용자에게 결과 확인 요청.

5. 업무 담당자는 조사 요구에 따라 업무 문서 및 답변 의견을 적시에 제공하며, 분석 보고서의 정확성을 확인해야 한다.

제13조: 시스템 소프트웨어 설계 및 분석

1. 설계 요구사항 연구:

a) 요구사항 분류 및 설명: 설계 기준, 절차, 지침 설정; 유사 문제 연구, 재사용 가능한 설계 활용 가능성 평가 및 필요한 도구 결정.

b) 기능 요구사항의 완전성, 합리성 및 실행 가능성을 검토; 법률적 요구사항의 적법성 검토; 불명확하거나 상충되는 요구사항 처리.

2. 전체 설계:

a) 사용자 요구 사항 문서 연구 및 시스템 구조의 기본 요소(기술 모델, 운영, 데이터베이스 조직, 프로그램 조직 등) 결정; 안전성, 보안성, 관리 및 운영 측면 검토 및 필요 시 모델 작성.

b) 설계 방법, 표준, 도구 선택.

c) 프로그램 및 데이터에 대한 전체 설계 문서 작성.

d) 세부 설계 및 프로그래밍 단계의 실행 가능성 검토.

3. 세부 설계:

a) 사용자 인터페이스, 보고서 모델, 처리 알고리즘, 다른 업무와의 인터페이스, 데이터의 보안 및 보호 수준, 기타 설계 내용 작성.

b) 데이터베이스, 프로그래밍 언어, 도구 및 관련 기술 선택.

c) 사용자 및 운영 환경에 대한 세부 기술 요구사항 문서 작성.

d) 설계 문서 검토 및 실행 가능성 평가.

조 14: 프로그램 작성

1. 프로그램 코드 작성 기준:

a) 프로그램 주석: 일반 설명, 수정 날짜, 수정자, 검증자 및 수정 내용; 복잡하거나 오해의 소지가 있는 코드 또는 프로그램 처리를 설명하기 위한 주석.

b) 코드 구조 명확하게 표현하고 계층화.

c) 프로그램 전체에서 일관된 객체 이름 사용. 이름은 의미를 나타내며, 전체 또는 부분 범위를 반영하고 서로 다른 객체 유형을 구분한다. 이름과 파일 형식은 소프트웨어 도구의 내용과 표준에 맞게 설정.

2. 공용 라이브러리 모듈 설계 및 작성.

3. 기능 모듈 프로그래밍 및 통합:

a) 이전 단계에서 작성한 시스템 설계 문서에 따라 프로그램 모듈 작성; 검토, 검증 및 통합.

b) 개별 모듈 및 전체 프로그램을 설계 문서 요구사항에 따라 테스트 환경 설정 및 테스트.

4. 시스템 기능 설명 문서 작성:

a) 구축된 소프트웨어의 전체 기능.

b) 시스템의 주요 기능: 구조도, 흐름도, 시스템 인터페이스 및 데이터 흐름.

c) 시스템 요구사항: 지원 데이터, 장비 구성 및 운영 환경.

d) 소프트웨어 구조: 소스 코드 라이브러리, 실행 프로그램, 지원 프로그램.

5. 설치 도구, 문서 및 운영 가이드 작성

"조항 15. 행정절차 공표 결정 소프트웨어 테스트 및 수정

1. 테스트 계획 작성:

a) 테스트 요구사항 및 제품 평가 기준.

b) 테스트 범위: 작업 한계, 인력, 테스트 일정의 주요 마커, 시간, 주기 및 반복 테스트 단계.

c) 테스트 방법.

d) 테스트 자원 및 환경: 인원 및 기술, 하드웨어, 소프트웨어, 네트워크 인프라 및 테스트 도구.

2. 테스트 시나리오 작성:

a) 테스트 목록 작성.

b) 시스템, 환경 및 프로그램 운영에 대한 일반적인 경우와 비정상적인 경우를 위한 테스트 시나리오 작성.

c) 테스트 절차 작성: 시작 조건, 종료 조건, 수행 단계 및 필요한 테스트 데이터.

d) 테스트 기준: 일반 평가, 수행 성능, 부하 용량 및 비정상 상황.

3. 통합 테스트 수행:

a) 실제 운영 조건을 모방하는 테스트 환경 설정.

b) 시나리오에 따른 테스트 수행, 결과 및 발견된 오류 기록.

c) 발생한 오류 처리 및 처리 후 다시 테스트.

4. 검사 결과 및 평가:

a) 오류의 반복 횟수, 심각도, 수정 시간을 분석하고 처리 방법을 제안한다.

b) 검사 통과 비율을 평가한다.

c) 검사 보고서를 작성하여 소프트웨어 요구사항 충족도와 실제 운영 가능성을 평가한다.

5. 검사 직원은 프로그래밍 직원과 독립적이어야 하며 시스템 설계 문서, 운영 요구사항을 숙지하고 검사 제품의 품질에 대한 책임을 진다.

조 16: 교육 및 훈련

1. 교육 및 훈련 요구사항:

a) 소프트웨어 구현 과정 전 또는 동일하게 진행한다.

b) 적절한 대상에게 제공한다.

c) 실제 운영 환경을 모방한 교육 환경을 제공한다.

d) 운용 자료를 충분히 제공한다.

đ) 고급 운용 기술이 필요한 교육 과정에서는 학습자에게 사용 허가증을 발급한다.

2. 교육 실시:

a) 교육 프로그램을 작성: 내용, 형태, 요구사항 및 조건.

b) 교육 환경, 자료, 데이터 및 지도자를 준비한다.

c) 집중 교육 또는 현장 지도를 실시한다.

d) 교육 조직 결과를 종합하고 평가한다.

조 17: 소프트웨어 구현

1. 구현 계획 수립:

a) 구현 요구사항을 확인: 범위, 기술 환경, 운영 환경, 운영 특징, 사용자 수.

b) 구현 자원, 구현 기간, 구현 방안 및 검수 방법을 확인한다.

c) 다수의 장소에서 구현되는 소프트웨어는 시범 구현 후 경험이 쌓인 후 확대 구현한다.

2. 구현 방안 및 절차 수립:

a) 구현 방안 연구: 일반적인 방안, 문제별 및 요구사항별 방안.

b) 검수 기준 및 검수 기록 표준을 작성한다.

c) 구현 절차를 작성: 단계, 수행 도구, 완료 절차, 검수 방법.

3. 시스템 설치:

a) 설계 문서의 기술 요구사항에 부합하는 운영 환경을 설정한다.

b) 시스템 소프트웨어, 도구 소프트웨어, 응용 소프트웨어를 설치 지침에 따라 설치한다.

c) 초기 데이터: 파라미터, 시스템 데이터, 데이터 변환.

4. 검사 실행:

a) 실제 환경에서 프로그램을 실행하고 검사한다. 예상 결과나 대조 시스템과 비교하고 수정하고 완성한다.

b) 사용자의 요구사항을 충족할 때까지 검사 실행 시간을 결정한다. 프로그램 규모, 완성도, 사용자의 기술 수준에 따라 다르다.

5. 정식 운영:

a) 시간, 방법, 단계를 설정한다.

b) 사용자 지원 및 문제 해결을 준비한다.

c) 프로그램 및 전체 시스템의 활동을 기록한다.

조 18: 소프트웨어 구성 관리

1. 소프트웨어 제품 구성 관리 파일 작성:

a) 소프트웨어 정보 조사: 제품 목록, 일정, 주요 마감일 및 구성 관리 요구사항.

b) 변경 단계와 마감일을 설정한다.

c) 각 단계별 구성 요소 목록 및 코드를 설정한다.

d) 제품 간 연관성을 기록한다.

đ) 각 구성 관리 대상 소프트웨어에 대한 디렉토리 구조와 접근 권한을 설정한다.

e) 예비 저장 규정에 따라 저장한다.

2. 구성 변경 관리:

a) 변경 요청의 내용, 비용, 시간을 분석하고 평가한다.

b) 변경 요청을 검토하고 승인한다.

c) 변경된 구성 요소에 대해 변경을 수행한다.

d) 변경된 구성 요소에 새 버전 번호를 부여한다.

đ) 구성 변경 기록 및 제품 간 연관성을 업데이트한다.

3. 구성 저장:

a) 안전한 저장 환경을 준비한다.

b) 정기적으로 저장 환경을 점검한다.

c) 각 버전의 소프트웨어는 서로 다른 두 장소에 최소 한 개씩 저장하여 상호 보완한다.

4. 버전 번호 부여:

a) 각 배포 제품에 주 버전 또는 업데이트 버전 번호를 부여한다.

b) 버전 번호는 프로그램 화면, 프로그램 주석, 그리고 배포 및 사용 중 혼동을 피하기 위해 철저히 관리된다.

조 19: 구현 후 운영 지원

1. 지원 계획 수립:

a) 사용자의 지원 요구사항을 조사한다.

b) 지원 조건, 자원, 장비, 방안을 확인한다.

c) 지원 목표, 범위, 결과, 시간, 지원 로그를 규정한다.

2. 지원 실시:

a) 지원 조건, 자료, 장소, 환경을 준비한다.

b) 지원 요구사항을 기록하고 분석하며 해결 방안을 시험한다.

c) 사용자 지원, 처리 결과 추적 및 기록을 한다.

d) 지원 요구사항 처리 진행 상황을 기록한다.

3. 지원 결과 종합 및 보고:

a) 보고 기간 동안의 지원 문서 및 요구사항을 종합한다.

b) 제품 관련 발생 문제를 분석한다.

c) 제품 관련 발생 문제 및 제안 사항을 포함한 정기 지원 보고서를 작성한다.

장 4:

은행 업무 소프트웨어 구매

조 20: 은행 업무 소프트웨어 구매

1. 제12조 제4항에 따른 "시스템 활동 설명 및 사용자 요구사항 특성화" 보고서를 입찰 문서로 작성한다.

2. 입찰 문서와 비교하여 제안된 소프트웨어의 요구사항 충족 가능성, 추가 및 조정 필요량을 추정한다.

3. 공급업체와 협력하여 설계 문서의 내용을 명확히 하고, 조정 내용과 구현 전 기술 및 법적 환경 준비 조건을 확인한다.

4. 제품 검수 및 구현을 제2장 및 제3장 제15조부터 제19조까지의 규정에 따른 기준으로 한다.

5. 구매된 소프트웨어는 구매 계약에 따른 사용권을 보유해야 한다.

조 21: 소프트웨어 보증 및 유지보수 요구사항

1. 공급업체의 표준에 따른 소프트웨어 보증

2. 단위가 필요하다면, 유지보수 단계에 대한 조항은 소프트웨어 구매, 위탁 제작 계약서에 공급업체와 협의하여 명시한다.

조 22: 소프트웨어 출시

1. 프로그램 가공대행 또는 구매 시 해당 기관의 정보기술 전담 부서가 제2장에 명시된 기술 표준을 준수하는지 검토하고, 정보를 업데이트하여 공용 프로그램 저장소에 보관해야 한다.

2. 업무 프로그램의 신규 발행 또는 버전 업데이트는 해당 기관의 장이 승인해야 한다.

3. 발행 시 알림과 함께 프로그램 발행 목록 및 상태, 그리고 업데이트된 버전의 변경 사항을 포함해야 한다.

장 5:

시행규정

조 23: 위반 처리

본 규정의 조항을 위반한 행위는 위반 정도에 따라 행정처분, 손해배상, 형사책임을 물어야 하며, 법률에 따른다.

조 24: 집행 책임

은행정보기술국은 본 규정의 이행을 지도하고 감독하며, 점검을 조직한다.

조 25: 본 규정의 개정 및 보완은 중앙은행 총재가 결정한다./.

부통감
(인)
Vũ Thị Liên

Original document (PDF)

Open PDF in a new tab ↗

Relations map

Click a document to open. A red border = a relation that changes validity.