|
NGÂN HÀNG NHÀ NƯỚC |
CỘNG HOÀ XÃ HỘI
CHỦ NGHĨA VIỆT NAM |
|
Số: 1630/2003/QĐ-NHNN |
Hà Nội, ngày 19 tháng 12 năm 2003 |
QUYẾT ĐỊNH
BAN HÀNH QUY ĐỊNH VỀ TIÊU CHUẨN KỸ THUẬT TRONG GIA CÔNG, MUA SẮM PHẦN MỀM NGHIỆP VỤ NGÂN HÀNG
THỐNG ĐỐC NGÂN HÀNG NHÀ NƯỚC
Căn cứ Luật Ngân hàng Nhà nước
Việt Nam số 01/1997/QH10 ngày 12/12/1997 và Luật các Tổ chức tín dụng số
02/1997/QH10 ngày 12/12/1997;
Căn cứ Luật sửa đổi, bổ sung một số điều Luật Ngân hàng Nhà nước Việt Nam số
10/2003/QH11 ngày 17/06/2003;
Căn cứ Nghị định số 86/2002/NĐ-CP ngày 05/11/2002 của Chính phủ quy định chức
năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ, cơ quan ngang Bộ;
Theo đề nghị của Cục trưởng Cục Công nghệ Tin học ngân hàng,
QUYẾT ĐỊNH:
Điều 2: Quyết định này có hiệu lực thi hành sau 15 ngày, kể từ ngày đăng Công báo.
|
|
KT.
THỐNG ĐỐC NGÂN HÀNG NHÀ NƯỚC |
QUY ĐỊNH
VỀ TIÊU CHUẨN KỸ THUẬT TRONG GIA CÔNG, MUA SẮM PHẦN MỀM NGHIỆP
VỤ NGÂN HÀNG
(Ban hành kèm theo Quyết định số 1630/2003/QĐ-NHHH ngày 19/12/2003 của Thống
đốc Ngân hàng Nhà nước)
QUY ĐỊNH CHUNG
1. Quy định này gồm các tiêu chuẩn kỹ thuật cơ bản, trình tự thủ tục trong gia công, mua sắm, triển khai và hỗ trợ vận hành các phần mềm nghiệp vụ ngân hàng của Ngân hàng Nhà nước, các tổ chức tín dụng (sau đây gọi chung là đơn vị) nhằm thống nhất quản lý việc ứng dụng công nghệ thông tin vào các hoạt động ngân hàng đạt hiệu quả cao và an toàn tài sản.
2. Các phần mềm nghiệp vụ dùng cho mục đích nghiên cứu, thử nghiệm hoặc sử dụng cục bộ tại một địa điểm và không kết nối với các phần mềm nghiệp vụ chung của đơn vị không thuộc phạm vi điều chỉnh của Quy định này.
3. Ngoài Quy định này, việc thuê gia công, mua sắm phần mềm nghiệp vụ ngân hàng còn phải tuân thủ các quy định của Nhà nước về việc thuê, mua sắm hàng hóa dịch vụ.
Trong Quy định này các thuật ngữ dưới đây được hiểu như sau:
1. Chương trình là một tập hợp các chỉ dẫn, mệnh lệnh viết bằng một ngôn ngữ đặc trưng và được sử dụng trực tiếp hoặc gián tiếp trên máy tính hoặc thiết bị có khả năng xử lý thông tin để đạt được một kết quả nhất định.
2. Phần mềm bao gồm chương trình, tài liệu kỹ thuật và dữ liệu liên quan sử dụng cho chương trình.
3. Phần mềm nghiệp vụ ngân hàng là phần mềm ứng dụng trong các hoạt động nghiệp vụ của Ngân hàng nhằm tin học hóa một phần hoặc toàn bộ các hoạt động của nghiệp vụ đó.
4. Phần mềm đóng gói là phần mềm được sản xuất hàng loạt và bán dưới dạng sản phẩm đóng gói hoàn chỉnh.
5. Mô đun chương trình là một phần của chương trình được viết và kiểm tra riêng biệt, sau đó được tổ hợp với các mô đun khác để tạo thành chương trình hoàn chỉnh.
6. Phần mềm mở là phần mềm tuân theo các tiêu chuẩn công nghiệp của quốc gia và quốc tế về tính mở, tương thích cao đối với những thay đổi của hệ thống và yêu cầu nghiệp vụ.
7. Phiên bản phần mềm là một dãy số gắn với việc phát hành sản phẩm phần mềm. Phiên bản gồm hai loại phiên bản chính và phiên bản nâng cấp; phiên bản chính là phiên bản sau lần phát triển đầu tiên và những lần thay đổi lớn về cấu trúc tổ chức và chức năng của phần mềm; phiên bản nâng cấp là phiên bản dùng trong quá trình sửa lỗi và cập nhật yêu cầu phát sinh.
8. Bản quyền sử dụng phần mềm là một xác nhận pháp lý về quyền khai thác phần mềm theo những quyền lợi bản quyền đó quy định.
9. Hệ thống là một sự tích hợp có tổ chức của phần mềm, thiết bị và những nhân tố liên quan khác theo một tiêu chuẩn nhất định nhằm nâng cao hiệu quả sử dụng chung.
10. Thiết kế hệ thống là công việc phiên dịch yêu cầu nghiệp vụ và người sử dụng thành mô hình kỹ thuật chi tiết chỉ dẫn cho việc phát triển phần mềm.
11. Cấu hình là một tập hợp những chương trình, tài liệu và dữ liệu được điều chỉnh theo một yêu cầu kỹ thuật nhất định.
12. Bản mẫu là mô hình thể hiện các ý tưởng thiết kế, lập trình hoặc quy trình xử lý nghiệp vụ, giúp cho việc hình dung, đánh giá, định hướng công việc trước khi tiến hành cụ thể.
13. Thư viện chương trình mẫu là những chương trình chuẩn được tập hợp lại với mục đích dùng chung và sử dụng nhiều lần.
14. Điều chỉnh phần mềm là việc thay đổi, bổ sung các cấu phần của phần mềm làm phù hợp hơn với yêu cầu của người sử dụng.
15. Kiểm tra phần mềm là công việc kiểm tra, thử nghiệm phần mềm nhằm phát hiện các lỗi xử lý nghiệp vụ, lập trình, giao diện hoặc tương tác giữa các mô đun của chương trình và xác định mức độ đáp ứng các yêu cầu đề ra của phần mềm cần kiểm tra.
16. Tình huống kiểm tra là một tập hợp các yếu tố, dữ kiện đầu vào, điều kiện thực hiện và kết quả dự kiến. Tình huống kiểm tra được lập ra để đáp ứng một mục tiêu cụ thể nào đó như kiểm tra một chức năng của chương trình, khả năng chịu tải hệ thống, yêu cầu của người sử dụng và các yêu cầu khác nếu có.
17. Thủ tục kiểm tra là một tập hợp các chỉ dẫn để thiết lập; thực hiện và đánh giá kết quả cho một hay nhiều tình huống kiểm tra.
18. Chương trình kiểm tra là một chương trình dùng để tự động hóa việc thực hiện các thủ tục kiểm tra. Chương trình kiểm tra có thể được lập bằng cách lập trình hoặc phát sinh tự động bằng những công cụ kiểm tra.
19. Phân tích nghiệp vụ và yêu cầu người sử dụng là quá trình tìm hiểu và mô tả các bài toán nghiệp vụ, các yêu cầu của người sử dụng, mối liên hệ giữa chúng và phân tích tính khả thi của những yêu cầu đó với việc ứng dụng tin học trong những điều kiện cụ thể.
20. Triển khai phần mềm là công việc nghiên cứu giải pháp kỹ thuật, thiết lập quy trình, tổ chức tập huấn, cài đặt, hướng dẫn sử dụng, khởi tạo, chuyển đổi dữ liệu và đưa phần mềm vào hoạt động.
21. Bảo hành, bảo trì phần mềm là công việc quản lý những thay đổi, hỗ trợ vận hành nhằm bảo đảm hoạt động chính xác, thông suốt và an toàn của phần mềm đã triển khai vận hành.
22. Quản lý cấu hình phần mềm là công cụ thiết lập, lưu giữ, phát hành các sản phẩm phần mềm và kiểm soát một cách có hệ thống các thay đổi của chúng.
23. Người sử dụng là người được giao nhiệm vụ vận hành chương trình để thực hiện công việc theo quyền hạn và trách nhiệm được phân công.
24.Người quản trị hệ thống là người được giao nhiệm vụ quản lý và đảm bảo cho hệ thống hoạt động thông suốt, an toàn.
25. Gia công phần mềm nghiệp vụ là toàn bộ quá trình phân tích nghiệp vụ và yêu cầu người sử dụng, phân tích thiết kế hệ thống, viết chương trình, tài liệu hướng dẫn, kiểm tra thử nghiệm và đóng gói phần mềm.
Điều 3: Bản quyền sử dụng phần mềm
Phần mềm nghiệp vụ dùng trong hoạt động ngân hàng phải có bản quyền sử dụng theo quy định của pháp luật. Nghiêm cấm các hành động sử dụng, can thiệp trái phép như: thay đổi, sao chép, tiết lộ thiết kế, thuật toán, công nghệ và mã nguồn.
Nâng cấp phần mềm, khắc phục kịp thời những khuyết điểm của chương trình, phản ánh thay đổi của nghiệp vụ và thay thế thuật toán, công nghệ đã lạc hậu. Thời gian giữa các lần nâng cấp không vượt quá thời gian khấu hao quy định cho phần mềm.
CÁC TIÊU CHUẨN KỸ THUẬT CƠ BẢN CỦA PHẦN MỀM NGHIỆP VỤ NGÂN HÀNG
Điều 5: Lựa chọn công nghệ, giải pháp phần mềm
1. Giải quyết tốt yêu cầu nghiệp vụ, triển khai ứng dụng được vào thực tế và có khả năng sử dụng lâu dài.
2. Đảm bảo các tiêu chuẩn an toàn và bảo mật của nghiệp vụ.
3. Tuân thủ tiêu chuẩn thiết kế hệ thống phần mềm mở.
4. Phù hợp trình độ công nghệ, tài chính và sử dụng hiệu quả nguồn vốn đầu tư của đơn vị.
Điều 6: Yêu cầu an toàn và bảo mật
1. Đánh giá các rủi ro tiềm ẩn của hệ thống từ giai đoạn phân tích, thiết kế hệ thống, phân loại mức độ quan trọng của từng cấu phần và toàn thể hệ thống.
2. Quy định rõ và triển khai đầy đủ các điều kiện kỹ thuật, môi trường cho cài đặt, vận hành nghiệp vụ an toàn.
3. Có phương án dự phòng xử lý sự cố phù hợp với đặc điểm nghiệp vụ về thời gian gián đoạn tối đa được phép, cấp độ quan trọng của dữ liệu.
4. Kiểm soát, ngăn chặn truy nhập hệ thống bất hợp pháp và có biện pháp hạn chế, khắc phục kịp thời những hậu quả nếu có.
5. Kiểm soát tác nghiệp, chỉ cho phép người sử dụng vận hành theo chức năng, nhiệm vụ được phân công. Cảnh báo đối với những tác nghiệp có thể gây hỏng, mất dữ liệu hoặc ảnh hưởng đến hoạt động hệ thống.
6. Có giải pháp kiểm tra, xác thực nguồn gốc, bảo vệ sự toàn vẹn của dữ liệu và mã hóa dữ liệu thuộc cấp độ “Mật” trở lên trong ngành Ngân hàng khi trao đổi trên mạng.
7. Các phần mềm mã hóa dữ liệu, chữ ký điện tử phải xây dựng, quản lý và sử dụng theo chế độ “Tối mật” trong ngành Ngân hàng.
Điều 7: Thiết kế mở và vận hành ổn định
1. Chương trình thiết kế độc lập tương đối với các thành phần phần cứng, hệ điều hành, cơ sở dữ liệu và truyền thông của hệ thống; tham số hóa các yếu tố đầu vào, tham số cài đặt chương trình và chia thành các mô đun chương trình con theo chức năng; có khả năng mở rộng và kết nối với các phần mềm nghiệp vụ khác trong tương lai.
2. Chạy ổn định, kết quả thực hiện đúng yêu cầu nghiệp vụ và xử lý được các lỗi ngoại lệ phát sinh.
Điều 8: Giao diện với người sử dụng
1. Nhất quán trên toàn bộ chương trình về bố cục màn hình, mầu sắc, thực đơn, phông chữ và quy ước sử dụng biểu tượng, phím chức năng theo các chuẩn thông dụng; thống nhất cách thức vào, ra và thực hiện chương trình.
2. Bố trí các chức năng chương trình theo phạm vi, nhóm công việc và trình tự thực hiện nghiệp vụ; hỗ trợ trực tuyến và cắt bỏ thao tác thừa trong vận hành.
3. Cảnh báo, ngăn chặn các lỗi vô tình trong vận hành; không cho người sử dụng thực hiện công việc quá thẩm quyền được giao.
Điều 9: Giao diện với các phần mềm nghiệp vụ khác
1. Kết nối liên hoàn với các phần mềm nghiệp vụ liên quan; trừ mục đích kiểm tra, không trùng lặp trong thu thập, truyền dẫn, xử lý và lưu trữ thông tin.
2. Sử dụng thống nhất các bộ mã đã ban hành cho cùng một đối tượng nghiệp vụ tham chiếu đến.
3. Đảm bảo an toàn trong kết nối, tránh hiện tượng bị truy nhập hoặc bị can thiệp bất hợp pháp vào dữ liệu của mỗi bên.
1. Tài liệu kỹ thuật phải ban hành kèm chương trình:
a) Cấu hình trang thiết bị phần cứng, mạng, hệ điều hành, cơ sở dữ liệu và các trang thiết bị khác dùng cho môi trường vận hành và môi trường dự phòng của phần mềm;
b) Hướng dẫn cài đặt và vận hành chương trình;
c) Hướng dẫn lưu trữ và khôi phục chương trình, cơ sở dữ liệu.
2. Tài liệu ban hành lần đầu và các phiên bản cập nhật tiếp sau phải được lưu trữ đầy đủ, thuận tiện cho tra cứu khi cần
GIA CÔNG, TRIỂN KHAI VÀ HỖ TRỢ VẬN HÀNH PHẦN MỀM NGHIỆP VỤ NGÂN HÀNG
Điều 11: Lập kế hoạch, kiểm tra và bàn giao kết quả công việc
1. Có kế hoạch cho từng giai đoạn thiết kế, xây dựng, triển khai, hỗ trợ, vận hành phần mềm và xem xét, phê duyệt kết quả khi kết thúc.
2. Kế hoạch và báo cáo kiểm tra gồm các nội dung: phạm vi, mục tiêu, thời gian, nhân lực, chi phí và các điều kiện thực hiện khác; các mốc, các tiêu chuẩn kiểm tra và kết quả thu được.
Điều 12: Phân tích nghiệp vụ và yêu cầu người sử dụng
1. Khảo sát nghiệp vụ:
a) Nghiên cứu các tài liệu nghiệp vụ: quy chế, quy trình, tài liệu hướng dẫn và các tài liệu khác do người sử dụng cung cấp.
b) Lên danh mục các vấn đề, các câu hỏi cần khảo sát.
c) Khảo sát hoạt động nghiệp vụ thực tiễn và phỏng vấn người sử dụng.
d) Tập hợp tài liệu và viết báo cáo khảo sát.
2. Phân tích nghiệp vụ:
a) Phân tích các yêu cầu nghiệp vụ, đặc điểm tổ chức, môi trường kỹ thuật, môi trường pháp lý và đặc điểm người sử dụng.
b) Lập tài liệu mô hình hóa quy trình xử lý nghiệp vụ, luồng dữ liệu và thực thể mang thông tin.
3. Phân tích yêu cầu người sử dụng:
a) Lập tài liệu mô tả và phân loại các yêu cầu về chức năng, môi trường hoạt động, yêu cầu vận hành và các yêu cầu khác từ góc nhìn của người sử dụng.
b) Phân tích tính khả thi, nhất quán và hợp lý của các yêu cầu; xác định mức độ ưu tiên, các tiêu chí và điều kiện thỏa mãn các yêu cầu.
c) Lập bản mẫu trong trường hợp cần thiết.
d) Trao đổi với người sử dụng, loại bỏ các yêu cầu bất hợp lý hoặc không khả thi; giải quyết các yêu cầu mâu thuẫn, nghiên cứu bổ sung các yêu cầu mới nếu có.
4. Mô tả hoạt động hệ thống và đặc tả yêu cầu người sử dụng:
a) Lập tài liệu mô tả kiến trúc, hoạt động của hệ thống hiện tại và dự kiến trong tương lai: quy trình hoạt động, thao tác, các ràng buộc về nghiệp vụ, các tình huống và giải pháp xử lý.
b) Lập tài liệu đặc tả yêu cầu người sử dụng: mô tả các yêu cầu về chức năng, giao diện, tổ chức dữ liệu, vận hành, yêu cầu trang bị và các yêu cầu khác từ góc nhìn của cán bộ kỹ thuật.
c) Xác nhận kết quả đối với người sử dụng.
5. Cán bộ nghiệp vụ có trách nhiệm cung cấp đầy đủ, kịp thời các tài liệu nghiệp vụ, các ý kiến trả lời theo yêu cầu khảo sát và xác nhận tính đúng đắn của báo cáo phân tích nghiệp vụ nếu được yêu cầu.
Điều 13: Phân tích và thiết kế hệ thống phần mềm.
1. Nghiên cứu các yêu cầu thiết kế:
a) Phân loại và mô tả yêu cầu: xác định các tiêu chuẩn, quy định, thủ tục và hướng dẫn thiết kế; nghiên cứu các bài toán tương tự, khả năng sử dụng lại các thiết kế đã có và xác định các công cụ cần thiết.
b) Xem xét đảm bảo tính đầy đủ, hợp lý của các yêu cầu về chức năng và mức độ thực hiện, tính hợp pháp của các yêu cầu về mặt pháp lý; xử lý các yêu cầu chưa rõ ràng và mâu thuẫn giữa các yêu cầu.
2. Thiết kế tổng thể:
a) Nghiên cứu tài liệu đặc tả yêu cầu người sử dụng và xác định các yếu tố cơ bản của kiến trúc hệ thống như: các mô hình kỹ thuật, vận hành, tổ chức cơ sở dữ liệu và tổ chức hệ thống chương trình; các khía cạnh về an toàn, bảo mật, quản lý và vận hành và làm bản mẫu nếu cần.
b) Lựa chọn phương pháp, tiêu chuẩn, công cụ thiết kế.
c) Lập tài liệu thiết kế tổng thể về chương trình và dữ liệu.
d) Xem xét tính khả thi của tài liệu đã lập cho giai đoạn thiết kế chi tiết và lập trình theo thiết kế.
3. Thiết kế chi tiết:
a) Thiết kế màn hình và giao diện với người sử dụng, mẫu báo cáo, thuật toán xử lý và giao diện với các nghiệp vụ khác; mức độ an toàn và bảo mật của dữ liệu và các nội dung thiết kế khác.
b) Lựa chọn cơ sở dữ liệu, ngôn ngữ lập trình, công cụ và các công nghệ liên quan khác đến xây dựng, tổ chức và triển khai phần mềm nghiệp vụ.
c) Lập tài liệu kỹ thuật chi tiết yêu cầu đối với người sử dụng và môi trường vận hành phần mềm nghiệp vụ.
d) Xem xét, đánh giá các tài liệu thiết kế, tính khả thi và độ sẵn sàng cho việc lập trình.
1. Tiêu chuẩn viết mã chương trình:
a) Ghi chú chương trình: mô tả chung, lần sửa, người sửa, người kiểm tra và nội dung sửa tại đầu chương trình; ghi chú, giải thích các đoạn mã phức tạp, dễ gây nhầm lẫn hoặc để giải thích các xử lý của chương trình.
b) Trình bày cấu trúc mã chương trình mạch lạc và có thứ bậc.
c) Đặt tên đối tượng thống nhất trong toàn bộ chương trình. Tên mang ý nghĩa gợi nhớ, thể hiện phạm vi tổng thể hoặc cục bộ và có sự phân biệt giữa các loại đối tượng với nhau. Cách đặt tên và kiểu file phù hợp với nội dung và chuẩn của công cụ phần mềm.
2. Thiết kế, lập trình các mô đun thư viện sử dụng chung.
3. Lập trình và tích hợp các mô đun chức năng:
a) Lập trình các mô đun chương trình theo tài liệu thiết kế hệ thống đã lập ở giai đoạn trước; kiểm tra, xem xét và tích hợp thành chương trình hoàn chỉnh.
b) Thiết lập môi trường, kiểm tra từng mô đun riêng biệt và toàn bộ chương trình theo yêu cầu của tài liệu thiết kế.
4. Viết tài liệu mô tả chức năng hệ thống:
a) Tổng thể chức năng phần mềm được xây dựng.
b) Các chức năng chính của hệ thống: sơ đồ cấu trúc, lưu đồ, các giao diện của hệ thống và dòng dữ liệu.
c) Yêu cầu của hệ thống: dữ liệu hỗ trợ, cấu hình trang thiết bị và môi trường vận hành.
d) Cấu trúc phần mềm: thư viện mã nguồn, chương trình thực hiện, chương tình hỗ trợ của phần mềm.
5. Viết công cụ, tài liệu cài đặt và hướng dẫn vận hành
Điều 15: Kiểm tra thử nghiệm và hiệu chỉnh phần mềm.
1. Lập kế hoạch kiểm tra:
a) Yêu cầu kiểm tra và tiêu chuẩn đánh giá sản phẩm.
b) Phạm vi kiểm tra: giới hạn công việc, nhân công, các mốc chính trong lịch trình kiểm tra, thời gian, chu kỳ thực hiện và các bước kiểm tra lặp lại.
c) Phương pháp kiểm tra.
d) Nguồn lực và môi trường kiểm tra: số người và kỹ năng, môi trường kiểm tra phần cứng, phần mềm, cơ sở hạ tầng mạng và các công cụ kiểm tra.
2. Xây dựng kịch bản kiểm tra:
a) Lập danh mục kiểm tra.
b) Xây dựng tình huống kiểm tra cho trường hợp thông thường và bất thường về hệ thống, môi trường và vận hành chương trình.
c) Xây dựng thủ tục kiểm tra gồm: điều kiện bắt đầu, kết thúc, các bước thực hiện và dữ liệu kiểm tra cần thiết.
d) Tiêu chí kiểm tra: đánh giá chung, hiệu suất thi hành, khả năng chịu tải và tình huống bất thường.
3. Thực hiện kiểm tra tích hợp:
a) Thiết lập môi trường kiểm tra mô phỏng các điều kiện vận hành thực tế của phần mềm nghiệp vụ.
b) Kiểm tra theo kịch bản, ghi nhận kết quả và các lỗi phát hiện được.
c) Xử lý các lỗi phát sinh và kiểm tra lại sau khi đã xử lý.
4. Xem xét và đánh giá kết quả kiểm tra:
a) Phân tích lỗi theo mức độ lặp lại, độ nghiêm trọng, thời gian sửa lỗi và đề xuất xử lý.
b) Đánh giá tỷ lệ đạt được qua kiểm tra.
c) Lập báo cáo tổng hợp kiểm tra, đánh giá mức độ đáp ứng yêu cầu của phần mềm và khả năng triển khai vận hành trong thực tế.
5. Cán bộ kiểm tra phải độc lập với cán bộ viết chương trình, nắm vững các tài liệu thiết kế hệ thống, yêu cầu vận hành và chịu trách nhiệm về chất lượng sản phẩm kiểm tra.
1. Yêu cầu đào tạo huấn luyện:
a) Tiến hành trước hoặc đồng thời trong quá trình triển khai phần mềm.
b) Đúng đối tượng.
c) Môi trường đào tạo mô phỏng thực tế vận hành của nghiệp vụ.
d) Đủ tài liệu vận hành
đ) Kiểm tra, cấp chứng chỉ được phép sử dụng phần mềm cho học viên đối với những khóa học phần mềm có yêu cầu cao về kỹ năng vận hành.
2. Thực hiện đào tạo:
a) Lập chương trình đào tạo: nội dung, hình thức, yêu cầu và điều kiện thực hiện.
b) Chuẩn bị môi trường, tài liệu, dữ liệu và người hướng dẫn.
c) Đào tạo tập trung hoặc hướng dẫn tại chỗ.
d) Tổng hợp, đánh giá kết quả tổ chức đào tạo.
1. Lập kế hoạch triển khai:
a) Xác định yêu cầu triển khai: phạm vi, môi trường kỹ thuật, môi trường vận hành, đặc điểm vận hành, số lượng người sử dụng.
b) Xác định các nguồn lực, thời hạn triển khai, phương án tổ chức thực hiện và cách thức nghiệm thu.
c) Phần mềm triển khai cho nhiều điểm, phải qua triển khai thí điểm, sơ kết rút kinh nghiệm trước khi triển khai mở rộng.
2. Xây dựng giải pháp và quy trình triển khai:
a) Nghiên cứu các giải pháp triển khai; giải pháp chung, giải pháp cho từng vấn đề, từng yêu cầu.
b) Lập các tiêu chuẩn nghiệm thu công việc và mẫu biên bản nghiệm thu.
c) Xây dựng quy trình triển khai: các bước, công cụ thực hiện, thủ tục cần hoàn thành, cách thức kiểm tra.
3. Cài đặt hệ thống:
a) Môi trường vận hành đúng yêu cầu kỹ thuật của tài liệu thiết kế.
b) Phần mềm hệ thống, phần mềm công cụ, phần mềm ứng dụng theo hướng dẫn cài đặt.
c) Dữ liệu ban đầu: các tham số, dữ liệu hệ thống, chuyển đổi dữ liệu cũ.
4. Chạy kiểm tra:
a) Vận hành và kiểm tra chương trình trên môi trường thực tế. Đối chiếu kết quả với hệ thống đối chứng hoặc kết quả dự kiến, sửa lỗi nếu có và hoàn thiện chương trình.
b) Chuyển vận hành chính thức khi đã đáp ứng yêu cầu của người sử dụng. Thời gian chạy kiểm tra được xác định tùy thuộc quy mô, mức độ hoàn chỉnh của chương trình và kỹ năng của người sử dụng.
5. Vận hành chính thức:
a) Xác lập thời gian, cách thức, các bước thực hiện.
b) Sẵn sàng hỗ trợ người sử dụng và xử lý sự cố.
c) Lập nhật ký theo dõi hoạt động của chương trình và toàn bộ hệ thống.
Điều 18: Quản lý cấu hình phần mềm.
1. Lập hồ sơ quản lý cấu hình sản phẩm phần mềm:
a) Nghiên cứu thông tin về phần mềm: danh sách sản phẩm, lịch trình thực hiện, các mốc thời gian chính và các yêu cầu quản lý cấu hình.
b) Xác định các giai đoạn và các mốc thay đổi.
c) Xác định danh sách và mã hiệu các đơn vị cấu hình thuộc vào từng giai đoạn.
d) Lập bảng theo dõi liên kết các sản phẩm.
đ) Tổ chức cây thư mục lưu trữ và phân quyền truy cập cho mỗi phần mềm cần quản lý.
e) Lưu trữ dự phòng theo quy định.
2. Kiểm soát thay đổi cấu hình sản phẩm:
a) Nhận, phân tích đánh giá nội dụng chi phí và thời gian thực hiện yêu cầu thay đổi.
b) Xem xét và phê duyệt yêu cầu thay đổi.
c) Thực hiện thay đổi đối với các cấu phần tham quan.
d) Xác định số hiệu phiên bản mới cho các cấu phần bị thay đổi.
đ) Cập nhật tài liệu ghi nhận thay đổi cấu hình và theo dõi liên kết các sản phẩm.
3. Lưu trữ cấu hình sản phẩm:
a) Chuẩn bị địa điểm, môi trường và các điều kiện lưu giữ an toàn.
b) Kiểm tra định kỳ môi trường và điều kiện lưu giữ.
c) Mỗi phiên bản phần mềm lưu trữ ít nhất tại hai địa điểm khác biệt, dự phòng cho nhau.
4. Đánh số phiên bản phần mềm:
a) Đánh số hiệu phiên bản chính hoặc phiên bản cập nhật tương ứng cho từng sản phẩm phát hành.
b) Số hiệu phiên bản phải thể hiện rõ trên màn hình chương trình, ghi chú trong chương trình và quản lý chặt chẽ để tránh nhầm lẫn trong quá trình triển khai, sử dụng.
Điều 19: Hỗ trợ vận hành sau khi triển khai
1. Lập kế hoạch hỗ trợ:
a) Nghiên cứu nhu cầu hỗ trợ của người sử dụng.
b) Xác định điều kiện, nguồn lực, trang thiết bị hỗ trợ và phương án hỗ trợ.
c) Quy định mục tiêu, phạm vi, kết quả, thời gian và nhật ký hỗ trợ.
2. Thực hiện hỗ trợ:
a) Chuẩn bị các điều kiện trang thiết bị, tài liệu, địa điểm và môi trường hỗ trợ.
b) Ghi nhận yêu cầu, phân tích, lập và thử nghiệm giải pháp xử lý.
c) Hỗ trợ, hướng dẫn người sử dụng, theo dõi và ghi nhận kết quả xử lý.
d) Ghi sổ theo dõi tiến trình xử lý yêu cầu hỗ trợ.
3. Tổng hợp, báo cáo kết quả hỗ trợ:
a) Tổng hợp các hồ sơ, yêu cầu hỗ trợ trong kỳ báo cáo.
b) Phân tích các vấn đề phát sinh liên quan đến sản phẩm.
c) Lập báo cáo hỗ trợ định kỳ: các số liệu thống kê, các vấn đề phát sinh và đề xuất liên quan đến sản phẩm.
MUA SẮM PHẦN MỀM NGHIỆP VỤ NGÂN HÀNG
Điều 20: Mua sắm phần mềm nghiệp vụ ngân hàng
1. Lập báo cáo “mô tả hoạt động hệ thống và đặc tả yêu cầu người sử dụng” theo quy định tại Điều 12 khoản 4 của Quy định này làm tài liệu kỹ thuật mời thầu.
2. So sánh với tài liệu kỹ thuật mời thầu, xem xét khả năng đáp ứng, ước lượng khối lượng cần bổ sung, điều chỉnh của phần mềm được chào bán.
3. Phối hợp với nhà cung cấp làm rõ và tiếp nhận các nội dung của tài liệu thiết kế; xác định nội dung điều chỉnh và những điều kiện chuẩn bị về môi trường kỹ thuật pháp lý trước khi đưa phần mềm vào vận hành theo Điều 13 của Quy định này.
4. Kiểm tra, nghiệm thu sản phẩm và triển khai vận hành theo các tiêu chuẩn quy định tại Chương II và các Điều từ 15 đến 19 Chương III của Quy định này.
5. Phần mềm mua sắm phải có bản quyền sử dụng phù hợp với văn bản thỏa thuận mua bán.
Điều 21: Yêu cầu bảo hành, bảo trì phần mềm
1. Bảo hành phần mềm theo các tiêu chuẩn của nhà cung cấp
2. Trường hợp đơn vị có nhu cầu, các điều khoản về giai đoạn bảo trì phải được thỏa thuận với nhà cung cấp trong văn bản mua, thuê gia công phần mềm.
1. Phần mềm thuê gia công, mua sắm phải được bộ phận chuyên trách công nghệ thông tin của đơn vị xem xét tuân thủ các tiêu chuẩn kỹ thuật tại Chương II của Quy định này; cập nhật thông tin, lưu trữ vào kho phần mềm chung của đơn vị.
2. Phát hành mới hoặc cập nhật phiên bản phần mềm nghiệp vụ phải được Thủ trưởng đơn vị phê duyệt.
3. Phát hành kèm thông báo: danh sách và tình trạng thành phần của phần mềm phát hành và những thay đổi so nếu là phiên bản cập nhật.
ĐIỀU KHOẢN THI HÀNH
Mọi hành vi vi phạm các điều khoản thuộc Quy định này, tùy theo mức độ vi phạm mà bị xử lý hành chính, bồi thường thiệt hại vật chất, truy cứu trách nhiệm hình sự theo quy định của pháp luật
Cục Công nghệ Tin học Ngân hàng có trách nhiệm hướng dẫn, theo dõi và tổ chức kiểm tra việc thực hiện Quy định này.
Điều 25: Việc sửa đổi, bổ sung Quy định này do Thống đốc Ngân hàng Nhà nước quyết định./.
|
THE
STATE BANK OF VIETNAM |
SOCIALIST
REPUBLIC OF VIETNAM |
|
No. 1630/2003/QD-NHNN |
Hanoi, December 19, 2003 |
THE GOVERNOR OF THE STATE BANK
- Pursuant to the Law on the
State Bank of Vietnam No. 01/1997/QH10 dated 12 December, 1997 and the Law on Credit
Institutions No. 02/1997/QH10 dated 12 December, 1997;
- Pursuant to the Law on the amendment, supplement of several Articles of the
Law on the State Bank of Vietnam No. 10/2003/QH11 dated 17 June, 2003;
- Pursuant to the Decree No. 86/2002/ND-CP dated 05 November, 2002 of the
Government providing for the function, assignment, authority and organization
structure of Ministries and ministerial-level agencies;
- Upon the proposal of the Director of the Banking Information Technology
Department,
DECIDES:
Article 1. To issue in conjunction with this Decision "the Regulation on technical standards in the processing, procurement of banking operation software".
Article 2. This Decision shall be effective after 15 days from the publication in the official gazette.
Article 3. The Director of the Administrative Department, the Director of the Banking Information Technology Department, Heads of units of the State Bank, General Managers (Managers) of Commercial Banks, the Central People Credit Fund shall be responsible for the implementation of this Decision.
...
...
...
FOR
THE GOVERNOR OF THE STATE BANK
DEPUTY GOVERNOR
Vu Thi Lien
ON TECHNICAL STANDARDS IN THE PROCESSING, PROCUREMENT OF
BANKING OPERATION SOFTWARE
(Issued in conjunction with the Decision No. 1630/2003/QD-NHNN dated 19
December, 2003 of the Governor of the State Bank)
1. This Regulation shall include basic technical standards, procedural sequences in the processing, procurement, deployment and operating support for banking operation software of the State Bank, Credit Institutions (hereinafter referred to as units) in order to universally manage the application of information technology to banking activities for great efficiency and asset security.
...
...
...
3. The hire for processing, procurement of banking operation software shall also be subject to provisions of the State on the hire and procurement of goods and services besides this Regulation.
In this regulation following terms shall be construed as follows:
1. Program shall be a group of instructions, commands, which are written in a specific language and directly or indirectly used on the computer or other devices with information processing capability to obtain a certain result.
2. Software shall include program, technical documents and related data, which are used in the program.
3. Banking operation software shall be the software applicable to operational activities of the bank in order to informaticalise partial or entire activities of that operation.
4. Packed software shall be software that is produced in mass and sold in form of completely packed products.
5. Program module shall be a part of the program, which is separately written and checked, combined thereafter with other modules to make a complete program.
6. Open software shall be software, which complies with national and international industrial standards in terms of the openness and high compatibility for changes of the system and operation requirements
...
...
...
8. Software license shall be a legal confirmation on the right to exploit the software under interests provided for by that license.
9. System shall be an organizational combination of the software, devices and other related factors under a certain standard in order to enhance the effectiveness of the common usage.
10. System design shall be a translation work that requires operations and users to make a detailed technical model to direct the development of software.
11. Configuration shall be a collection of programs, materials, data that are adjusted under a certain technical requirement.
12. Sample shall be a model reflecting the design, programming ideas or operation settlement process that help the imagination, assessment and orientation of work before performance.
13. Library of sample programs shall consist of standard programs that are collected for the purpose of common use and used for many times.
14. Software adjustment shall be the amendment, supplement of components of the software to make it more appropriate with users' requirements.
15. Software testing shall be the testing, experiment of the software to discover errors in terms of operation settlement, programming, interface or interaction between program's modules and determine the satisfaction level for given requirements of the software that needs testing.
16. Examining situation shall be a collection of input elements, data, operational conditions and expected result. Examining situations are prepared to satisfy a certain objective such as checking a certain function of the program, durability of system, users' requirements and other requirements (if any).
...
...
...
18. Examining program shall be a program used to automate the performance of examining procedures. Examining program may be prepared by programming or automatically arisen by examining instruments.
19. Operation and users' requirement analysis shall be a process of study and description of operation problems, users' requirements, the relationship between them and the feasibility analysis of those requirements in the application of informatics to certain conditions.
20. Software deployment shall be the study of technical solutions, procedure establishment, training organization, installation, operational instruction, initiation, data conversion and putting the software into operation.
21. Software warranty and maintenance shall be the management of changes, provision of support to secure the accurate, smooth and safe operation of the operated and deployed software.
22. Management of software configuration shall be the establishment, preservation, issuance of software products and systematic control of their changes.
23. User shall be the person who is assigned to operate the program to carry out his tasks in accordance with his assigned authorities and responsibility.
24. System administrator shall be the person who is assigned to manage and secure the smooth and safe operation of the system.
25. Processing of operation software shall be the entire process of operation and users' requirement analysis, systematic design analysis, program composition, guiding documents, testing, experiment and package of the software.
...
...
...
Software update shall mean to timely overcome program's shortcomings, reflect changes in operations and replace backward algorithm and technology. The duration between upgrade times should exceed the amortizing time provided for software.
BASIC TECHNICAL STANDARDS OF BANKING OPERATION SOFTWARE
Article 5. Selection of technology and software solutions that
1. can settle operation requirements well, can be deployed and applicable to the fact and have longevity.
2. secure safe and confidential standards of operation.
3. comply with the design standards of open software system.
4. are in line with technology level, financial status and effectively use investment fund sources of the unit.
...
...
...
1. To assess potential risks of the system in the course of the analysis, system design, to classify the importance of each component and the entire system.
2. To specifically stipulate and sufficiently prepare technical conditions, environment for the safe installation and manipulation of operations.
3. To prepare back-up plans for breakdowns settlement in line with operational features in terms of permitted maximum interruption time, importance of data.
4. To control, prevent the illegal access to the system and to take timely measures for limiting and overcoming consequences (if any).
5. To control operation acts, only to permit users to operate in accordance with their assigned function, tasks. To warn of operation acts that may cause the failure, loss of data or affect the operation of the system.
6. To take measures in respect of the source code examination and identification, data protection and encryption from data of the level "Confidential" upward in banking area when the exchange on the network is carried out.
7. Software for the data encryption, electronic signatures must be set up, managed and used in accordance with the "Top secret" regime in the banking area
Article 7. Open design and stable operation
1. The design program shall be relatively independent to components of the hardware, operating system, databases and communication of the system; input elements, program installation shall be parameterized and divided into sub-program modules under their functions, which can be extended and connected to other operation software in the near future.
...
...
...
1. All program must be consistent in terms of screen layout, color, menu, font and the convention on the use of icons, function keys in accordance with common standards; the way of program outgoing and incoming and performance must be consistent.
2. To arrange program functions under scope, task groups and procedures for operation performance; to provide online support and eliminate redundant acts in operating process.
3. To warn and prevent unintentional errors during operating process, not to permit users to carry out assignments beyond their assigned competence
Article 9. Interface with other operation software.
1. Connection to related operation software, except for examination purpose, shall be kept uninterruptedly; the collection, transmission, processing and preservation of information shall not be coincident.
2. Issued codes shall be used consistently for the same operation subject referred to.
3. To secure the safety in the connection, to avoid the access to or illegal intervention with the data of others'.
Article 10. Technical documents
...
...
...
a. Documents on equipment configuration of hardware, network, operating system, database and other equipment that shall be used for s
b. Documents guiding the system installation and operation.
c. Documents guiding the preservation and recovery of programs, database.
2. Documents issued for the first version and update versions should be sufficiently preserved to facilitate the looking up when necessary.
PROCESSING, DEPLOYING AND SUPPORTING THE OPERATION OF BANKING OPERATION SOFTWARE
Article 11. Making plan, examining and handing over assignment results
1. The plan should be made for each design, construction, deployment, support and operation of the software and upon its completion; the result should be considered and approved.
2. The plan and examination report shall consist of following contents: the scope, objectives, time, human resource, cost and other implementing conditions; points of time, examination standards and received results.
...
...
...
1. Operation investigation
a. To study operation documents: procedures, process, guiding documents and other documents provided by users.
b. To list issues, questions that need investigating
c. To investigate practical operation activities and interview users
d. To consolidate documents and make investigation report
2. Operation analysis
a. To analyze operation requirements, organizational features, technical environment, legal environment and users' characteristics.
b. To prepare documents on modeling operation settlement process, data flow and information carriers.
3. Analysis of users' requirements
...
...
...
b. To analyze the feasibility, consistence and appropriateness of requirements and determine the priority, criteria and conditions of requirement satisfaction.
c. To prepare a sample form in the event of necessity.
d. To consult with the user to eliminate unreasonable or infeasible requirements; to deal with conflict requirements, study and supplement new requirements (if any).
4. Description of system operation and users' requirements
a. To prepare documents to describe the design, operation of the system at present and expected in the future: operational process, acts, operational ties, cases and their solutions.
b. To prepare documents that focus on users' requirements: description of requirements concerning function, interface, data organization, operation, equipment requirements and other requirements from the viewpoint of technical officers.
c. To confirm the result with users.
5. Operation officers shall be responsible for sufficient, timely provision of operation documents, responses to investigation requirements and confirmation of the correctness of the report on operation analysis if required.
Article 13. Analysis and design of the software system
...
...
...
a. To classify and describe requirements; to determine standards, provisions, procedures and guidance on design; to study similar problems, the capability of re-utilization of available designs and determine necessary instruments.
b. To consider and ensure the sufficiency, reasonability of requirements on function and implementing levels, the legality of legal requirements; to deal with unclear requirements and conflicts among requirements.
2. Overall design
a. To study documents that focus on users' requirements and determine basic elements of system design such as: technical models, operation, database organization and organization of program system; security issues, secrecy, management and operation and prepare a sample form, if required.
b. To select measure, standards and instruments of design
c. To prepare an overall design document on program and data.
d. To consider the feasibility of documents prepared for the detailed design period and program under the design
3. Detailed design
a. To design screen and user interface, reporting forms, settlement algorithm and interface with other operations; the level of security and secrecy of data and other design contents.
...
...
...
c. To prepare technical document that specifies requirements to users and operating environment of the operation software.
d. To consider, assess design documents, the feasibility and the readiness to program.
1. Standards for writing program codes
a. Program notes: general description, correction time, corrector, examiner and correction content at the beginning of the program; notice taking, explanation of complicated code sections that can easily lead to the mistake or for the explanation of program processing.
b. To display the structure of program sources in a consistent manner and certain order.
c. To name objects of the entire program consistently. The name must create a reminding mean, reflect the entire or partial scope and be distinguishable between other types of objects. The way to name and file forms shall be in line with contents and standards of software instruments.
2. To design, program library modules for common usage.
3. Program and combination of functional modules
...
...
...
b. To set up an environment, examine each separate module and the entire program in accordance with the requirements of the design documents.
4. Writing documents that describe systematic function
a. The overall function of the software to be set up
b. Main functions of the system: structure diagram, interfaces of the system and data lines.
c. Requirements of the system: supporting data, configuration of equipment and operating environment.
d. Software structure: source code library, implementing program, support program of the software.
5. Writing instrument, documents of installation and operation guidance
Article 15. Experimental examination and software correction
1. Making plan for examination
...
...
...
b. Examination scope: limit of work, human resource, main periods in the examining schedule, time, implementation cycle and repeat examining steps.
c. Examining methods
d. Resources and examining: number of persons and skill, examining environment for hardware, software, network infrastructure and examining instruments.
2. Setting up examining scenario
a. To prepare examining list
b. To set up examining situations for regular and irregular cases of the system, environment and operation of the program.
c. To set up examining procedures including: conditions for the begin, end of examination, implementation steps and necessary examination data.
d. Examination criteria: general assessment, implementing productivity, durability and irregular situations.
3. Carrying out the uninterrupted examination
...
...
...
b. To examine under the scenario, take notice of the result and discovered errors.
c. To deal with arising errors and reexamine after settlement
4. To consider and assess results of the examination
a. To analyze errors in accordance with the level of repeat, seriousness, time for error correction and to recommend the settlement.
b. To assess the achievement ratio through examination
c. To make consolidated examination report, to assess the satisfaction level of software's requirements and capability of practical deployment and operation.
5. Examining officers shall operate independently from officers who write program, clearly understand documents concerning the system design, operational requirements and take full responsibility for the quality of examined products.
1. Requirements of the training
...
...
...
b. The training should be carried out for right subjects.
c. Training environment shall imitate the practical operation.
d. The operation documents must be sufficient.
dd. Trainees of software courses that require high operational skills shall be examined and granted a certificate of software use.
2. Training performance
a. To prepare training program: content, forms, requirements and conditions for implementation.
b. To prepare environment, documents, data and guidance.
c. To carry out the class training or on the job guidance.
d. To consolidate, assess results of the training.
...
...
...
1. Preparation of the deployment program
a. To determine requirements for the deployment: scope, technical environment, operating environment, operating features, number of users.
b. To determine resources, deployment time limit, plan for the organization and implementation and the way of inspection test.
c. For software that is deployed for several places, experimental deployment shall be carried out, summed up partially for deriving lessons from experience before the large-scale deployment.
2. Preparation of solutions and process for the deployment
a. To study deployment solutions: general solutions, solution applicable to each matter, each requirement.
b. To prepare standards for taking over the work and the sample minutes on taking over.
c. To set up deployment process: steps, implementing instruments, procedures need to be completed, examining modes.
3. System installation
...
...
...
b. System software, instrumental software, application software shall be installed in accordance with installation guidance.
c. First data: parameters, system data, and conversion of old data
4. Test run
a. The operation and examination of program shall be carried out in practical environments. To reconcile the result with reconciliation system or expected result, to correct errors (if any) and perfect the program.
b. To carry out the official operation when satisfying users' requirements. Time for test run shall be determined based on the scale, the completeness of program and users' skills.
5. Official operation
a. To determine time, method and steps of implementation
b. Ready to support users and deal with breakdowns
c. To make diary following up the operation of program and the entire system.
...
...
...
1. Preparing the file for managing configuration of software products
a. To study information of software: list of products, implementation schedules, main points of time and requirements for the configuration management
b. To determine changed stages and time points
c. To determine the list and codes of configuration units of each stage.
d. To prepare a table following up the combination of products
dd. To organize a directory for preservation and delegate access priority to each software that needs managing.
e. To make backup copy under applicable regulations.
2. Controlling the change of product configuration
a. To receive, analyze, assess the content, cost and time for requirements for change implementation.
...
...
...
c. To make changes to relevant configurations.
d. To determine the number signs of new versions for changed configurations
dd. To update documents recording the changes of configuration and follow up the combination of products.
3. Preserving configuration of products
a. To prepare safe location, environment and conditions for preservation
b. To carry out periodical examination to environment and conditions for preservation.
c. Each version of software shall be preserved at least at 2 different locations for backup
4. Numbering software versions
a. To number main versions or their respective upgraded versions of each issued products.
...
...
...
Article 19. Operation support after deployment
1. Preparing support plan
a. To study the support demand of users
b. To determine support conditions, resources, equipment ort and support project
c. To stipulate support objectives, scope, result, time, location and support diary.
2. Carrying out the support.
a. To prepare equipment conditions, documents, location and environment for support
b. To acknowledge requirements, analyze, prepare and try settlement solutions.
c. To support, guide the users, follow up and acknowledge settlement results.
...
...
...
3. Consolidating, reporting support results
a. To consolidate files, requirements for support in the reporting period.
b. To analyze arising issues relating to products.
c. To make periodical support report: statistic data, arising issues and proposals relating to products.
PROCUMENT OF BANKING OPERATION SOFTWARE
Article 20. Procurement of banking operation software
1. To make report "description of system operation and users' requirements" in accordance with provisions at Article 12 paragraph 4 of this Regulation to use as a technical document for auction invitation.
2. To compare with technical documents for auction invitation, consider the capability of satisfaction, estimate the volume required to supplement, adjust the software being offered.
...
...
...
4. To check and take over products and carry out the operation in accordance with standards provided for in Chapter II and Articles from 15 to 19, Chapter III of this Regulation.
5. Procured software must be supported by the license in line with written agreement on the procurement.
Article 21. Requirements of warranty, maintenance of software
1. Software shall be given a warranty under standards of suppliers
2. In case where units have other demand, Articles on maintenance stages should be agreed upon with supplier in the document on the purchase of, processing hiring of software.
Article 22. Issuance of software
1. Software hired to process, procured must be considered by the information technology specialist body of the unit and comply with technical standards provided for Chapter II of this Regulation; updated with information and preserved in the software stock of the unit.
2. The new issuance or update of operation software versions shall be approved by the Head of unit.
3. To issue in conjunction with the notice: the list and the state of components of issued software and their changes in case of upgraded versions.
...
...
...
Article 23. Dealing with violation
Any act of violation of Articles of this Regulation shall be, depending on the seriousness of violation, subject to administrative punishment, compensation for material damages, prosecuted for criminal liability under provisions of applicable laws
Article 24. Implementing responsibilities
The Banking Information Technology Department shall be responsible for guiding, following up and examining the implementation of this Regulation
Article 25. Any amendment, supplement of this Regulation shall be decided upon by the Governor of the State Bank.
FOR
THE GOVERNOR OF THE STATE BANK
DEPUTY GOVERNOR
Vu Thi Lien
...
...
...
;
Quyết định 1630/2003/QĐ-NHNN quy định về Tiêu chuẩn Kỹ thuật trong gia công, mua sắm phần mềm nghiệp vụ Ngân hàng do Thống đốc Ngân hàng Nhà nước Việt Nam ban hành
| Số hiệu: | 1630/2003/QĐ-NHNN |
|---|---|
| Loại văn bản: | Quyết định |
| Nơi ban hành: | Ngân hàng Nhà nước |
| Người ký: | Vũ Thị Liên |
| Ngày ban hành: | 19/12/2003 |
| Ngày hiệu lực: | Đã biết |
| Tình trạng: | Đã biết |
Văn bản đang xem
Quyết định 1630/2003/QĐ-NHNN quy định về Tiêu chuẩn Kỹ thuật trong gia công, mua sắm phần mềm nghiệp vụ Ngân hàng do Thống đốc Ngân hàng Nhà nước Việt Nam ban hành
Chưa có Video
