Luận văn Thạc sĩ Kỹ thuật phần mềm, Đề tài: Giải pháp số hóa quy trình quản lý phát triển phần mềm tại trung tâm Công nghệ thông tin - Ngân hàng TMCP đầu tư và phát triển Việt Nam

Luận văn Thạc sĩ Kỹ thuật phần mềm, Đề tài: Giải pháp số hóa quy trình quản lý phát triển phần mềm tại trung tâm Công nghệ thông tin - Ngân hàng TMCP đầu tư và phát triển Việt Nam

MỤC LỤC

LỜI CAM ĐOAN

LỜI CÁM ƠN

MỤC LỤC

DANH MỤC CÁC CHỮ VIẾT TẮT i

DANH MỤC BẢNG iii

DANH MỤC HÌNH v

LỜI MỞ ĐẦU 1

CHƯƠNG 1: CƠ SỞ LÝ LUẬN VỀ SỐ HÓA QUY TRÌNH QUẢN LÝ PHÁT TRIỂN PHẦN MỀM 3

1.1 Tổng quan về số hóa 3

1.1.1 Khái niệm về số hóa 3

1.1.2 Quy trình số hóa 3

1.1.3 Vai trò của số hóa 4

1.2 Quy trình phát triển phần mềm 5

1.2.1 Khái niệm 5

1.2.2 Các Bước thực hiện 5

1.2.3 Một số mô hình cho việc xây dựng quy trình phát triển phần mềm 6

1.3 Kết luận chương 1 12

CHƯƠNG 2: THỰC TRẠNG QUY TRÌNH QUẢN LÝ PHÁT TRIỂN PHẦN MỀM THEO QUY ĐỊNH CỦA BIDV TẠI TRUNG TÂM CNTT 13

2.1 Giới thiệu về BIDV 13

2.2 Các hình thức phát triển phần mềm 16

2.2.1 Quy trình phát triển phần mềm theo hình thức cổ điển 16

2.2.2 Quy trình PTPM theo mô hình Agile 27

2.2.3 Quy trình phát triển phần mềm theo hình thức khẩn gấp 28

2.3 Lập kế hoạch phát triển phần mềm 29

2.3.1 Các mức ưu tiên trong kế hoạch phát triển phần mềm 29

2.3.2 Bổ sung và điều chỉnh kế hoạch PTPM 30

2.4 Quản lý phát triển phần mềm 31

2.4.1 Các thành phần tham gia quản lý và phát triển phần mềm 31

2.4.2 Luồng quy trình phát triển phần mềm hiện tại 32

2.5 Những ưu điểm, khó khăn tồn tại 35

2.5.1 Ưu điểm 35

2.5.2 Những khó khăn tồn tại 35

2.6 Kết luận chương 2 36

CHƯƠNG 3: GIẢI PHÁP SỐ HÓA QUY TRÌNH QUẢN LÝ PHÁT TRIỂN PHẦN MỀM THEO QUY ĐỊNH CỦA BIDV TẠI TRUNG TÂM CNTT 37

3.1 Cơ sở xây dựng các giải pháp 37

3.2 Mô tả bài toán 39

3.3 Phân tích các quy trình 40

3.3.1 Quy trình đăng nhập hệ thống 40

3.3.2 Qui trình phê duyệt nhóm hồ sơ 41

3.3.3 Số hóa quy trình phát triển phần mềm 63

3.4 Thiết kế cơ sở dữ liệu 77

3.5 Một số giao diện chính 78

KẾT LUẬN VÀ KIẾN NGHỊ 83

1 KẾT LUẬN 83

2 KIẾN NGHỊ 84

TÀI LIỆU THAM KHẢO 85

PHỤ LỤC: CÁC BẢNG TRONG THIẾT KẾ LOGIC VÀ THIẾT KẾ VẬT LÝ -CÁC BIỂU MẪU 86

DANH MỤC CÁC CHỮ VIẾT TẮT

1 Ngân hàng TMCP

ĐT&PT VN Ngân hàng TMCP Đầu tư và Phát triển Việt Nam

2 Trung tâm CNTT Trung tâm Công nghệ Thông tin Ngân hàng TMCP

Đầu tư và Phát triển Việt Nam

3 TTNHS Trung tâm Ngân hàng số

9 Các Phòng QTUD

Gồm các phòng thực hiện nhiệm vụ Quản trị ứngdụng, bao gồm: Phòng QTUD, Phòng VHHT, PhòngKhu vực miền nam, Phòng Khu vực miền trung

10 Các Phòng VHHT

Gồm các phòng thực hiện nhiệm vụ Vận hành hỗ trợ,bao gồm: Phòng Vận hành hỗ trợ, Phòng Khu vựcmiền nam, Phòng Khu vực miền trung

11 Cán bộ PTPM

Gồm các cán bộ thực hiện công tác phát triển phầnmềm tại các phòng PTPM của TTCNTT và cán bộPTPM tại TTNHS

12 Cán bộ QTUD Gồm các cán bộ thực hiện công tác quản trị ứng dụng

16 PTTK Tài liệu Phân tích thiết kế

17 HDSD Tài liệu Hướng dẫn sử dụng

18 HDCĐ Tài liệu Hướng dẫn cài đặt

19 URD Tài liệu yêu cầu người sử dụng

20 RSD Tài liệu đặc tả yêu cầu người sử dụng

STT Chữ sử dụng Giải thích

21 Quản lý luân chuyển

hồ sơ phần mềm QLLCHSPM

DANH MỤC BẢNG ST

Nội dung

Trang

1 Bảng 1.1 Các bước trong quy trình số hóa 3

2 Bảng 1.2 Các bước trong quy trình phát triển phần mềm 5

3 Bảng 3.1 Các bước trong quy trình đăng nhập hệ thống 40

4 Bảng 3.2 Các bước trong quy trình phê duyệt tài liệu RSD,

7 Bảng 3.5 Các bước phê duyệt hồ sơ Thẩm định UR, RSD,

Báo cáo đánh giá quá trình PTPM 47

8 Bảng 3.6

Các bước phê duyệt hồ sơ URD, Biên bản nghiệmthu nghiệp vụ, Kịch bản kiểm thử chi tiết củanghiệp vụ, Tài liệu hướng dẫn sử dụng, Trình triểnkhai của nghiệp vụ

49

9 Bảng 3.7 Các bước phê duyệt hồ sơ PTTK 51

10 Bảng 3.8 Các bước phê duyệt hồ sơ PTTK sơ bộ, Dự thảo

HDSD, HDCĐ, Kết quả test nội bộ 53

11 Bảng 3.9

Các bước phê duyệt hồ sơ Kịch bản test kỹ thuật,Báo cáo nghiệm thu kỹ thuật, Kịch bản kiểm thửchi tiết của kỹ thuật, Nội dung đào tạo, Tài liệu vậnhành chính thức

60

15 Bảng 3.13 Các bước phê duyệt phê duyệt hồ sơ Tài liệu hướng 61

dẫn cài đặt

16 Bảng 3.14 Các bước thực hiện phê duyệt tài liệu trên chương

trình Quản lý luân chuyển hồ sơ phần mềm 65

DANH MỤC HÌNH ST

6 Hình 2.2 Sơ đồ các đơn vị thực hiện trong quá trình PTPM 31

7 Hình 2.3 Quy trình phát triển phần mềm hiện tại tại BIDV

8 Hình 3.1 Quy trình nghiệp vụ đăng nhập vào hệ thống 40

9 Hình 3.2 Quy trình phê duyệt tài liệu RSD, biên bản nghi nhớ 41

10 Hình 3.3 Quy trình phê duyệt hồ sơ Khái toán, dự kiến kế

11 Hình 3.4 Quy trình phê duyệt hồ sơ Đề nghị thẩm định

12 Hình 3.5 Quy trình phê duyệt hồ sơ Thẩm định UR, RSD, Báo

14 Hình 3.7 Quy trình phê duyệt hồ sơ PTTK 50

15 Hình 3.8 Quy trình phê duyệt hồ sơ PTTK sơ bộ, Dự thảo

HDSD, HDCĐ, Kết quả test nội bộ 52

16 Hình 3.9

Quy trình phê duyệt hồ sơ Kịch bản test kỹ thuật,Báo cáo nghiệm thu kỹ thuật, Kịch bản kiểm thử chitiết của kỹ thuật, Nội dung đào tạo, Tài liệu vận hànhchính thức

Tài liệu vận hành chính thức của ứng dụng quantrọng của phòng QTUD

20 Hình 3.13 Quy trình phê duyệt hồ sơ Tài liệu hướng dẫn cài đặt 61

21 Hình 3.14 Luồng quy trình số hóa quy trình phát triển phần

23 Hình 3.16 Màn hình phê duyệt tài liệu 78

26 Hình 3.19 Màn hình quản lý kế hoạch PTPM 79

27 Hình 3.20 Màn hình quản lý danh mục phần mềm 80

28 Hình 3.21 Màn hình quản lý danh mục hồ sơ 80

29 Hình 3.22 Giao diện quản lý email Template 81

30 Hình 3.23 Màn hình phân quyền xem tài liệu PTTK 81

31 Hình 3.24 Màn hình Báo cáo theo dõi tình trạng hồ sơ phần

32 Hình 3.25 Màn hình báo cáo rà soát hồ sơ phần mềm 82

LỜI MỞ ĐẦU

1 Tính cấp thiết của đề tài

Công nghệ phần mềm nói chung hiện nay được xem là một trong những trụcột chính của tăng trưởng kinh tế ở nhiều nước Các công ty phần mềm thườngxuyên phải đối mặt với nhiều thách thức khó khăn để cung cấp phần mềm đạt chấtlượng và đúng tiến độ Theo một khảo sát bởi Standish Group, năm 2019 có đến70% các dự án phần mềm bị chậm, không kịp tiến độ Tình trạng này không chỉdiễn ra trên thế giới, mà ở Việt Nam tình trạng này còn trầm trọng hơn

Cùng với sự phát triển của khoa học trên thế giới, ngành công nghệ thông tinngày càng một phát triển, việc áp dụng những công nghệ mới để tin học hóa nhữngquy trình làm việc, giảm bớt khối lượng công việc cho người quản lý và lập dự án,tiết kiệm thời gian, kinh tế, nhân sự cho doanh nghiệp là một điều tất yếu, việc sốhóa quy trình để trong công tác quản lý phát triển phần mềm là vô cùng quan trọng

Trong suốt chặng đường hoạt động của ngân hàng TMCP Đầu tư và pháttriển Việt Nam (BIDV), đặc biệt trong 25 năm hoạt động theo mô hình ngân hàngthương mại (1995-2020), BIDV được biết đến như một định chế hàng đầu của ViệtNam tiên phong trong hội nhập với các ngân hàng khu vực và thế giới với sự vượtbậc về quy mô, tài sản, hệ thống mạng lưới dịch vụ cũng như công tác quản trị điềuhành Để đạt được kết quả này, hoạt động công nghệ thông tin luôn đồng hành và đãgóp phần xứng đáng vào những thành tựu trong hoạt động kinh doanh của BIDV

Là một trong 4 ngân hàng lớn nhất Việt Nam, ngân hàng Thương mại cổphần Đầu tư và phát triển Việt Nam “BIDV’ đã luôn đi đầu trong ứng dụng côngnghệ thông tin với chiến lược, định hướng rõ ràng Đến nay BIDV đã xây dựngđược hệ thống cơ sở hạ tầng CNTT hiện đại, đủ sức phục vụ vận hành hoạt độngcủa cả hệ thống BIDV Mô hình quản trị công nghệ thông tin tiên tiến phù hợp vớithông lệ quốc tế và quy mô phát triển của BIDV, là nơi sản sinh các sản phẩm tiêntiến, hiện đại hướng tới khách hàng và thử thử nghiệm các mô hình kinh doanh mớitrên nền tảng công nghệ 4.0 Tuy nhiên, bên cạnh những thành tựu và kết quả tíchcực đã đạt được, việc áp dụng quy trình quản lý phát triển phần mềm vào những dự

án vẫn còn nhiều mặt hạn chế gây ảnh hưởng tới tiến độ phát triển phần mềm và do

đó làm ảnh hưởng tới hiệu quả kinh tế của BIDV cũng như uy tín trong ngành Vớimong muốn nâng cao hiệu quản quản lý tiến độ phần mềm nhằm giúp các dự ánphần mềm nắm bắt được tiến độ theo thời gian thực, từ đó điều chỉnh hoạt động để

có được sản phẩm đúng như dự kiến Chính vì vậy tôi đã chọn đề tài “ Giải pháp sốhóa quy trình quản lý phát triển phần mềm tại Trung tâm CNTT - Ngân hàng TMCPĐầu tư và phát triển Việt Nam”

2 Mục tiêu nghiên cứu

Mục tiêu nghiên cứu tổng quát của đề tài: Số hóa quy trình trong quản lý pháttriển phần mềm tại Trung tâm CNTT - Ngân hàng TMCP Đầu tư và phát triển ViệtNam

Để thực hiện được mục tiêu tổng quát, luận văn thực hiện các mục tiêu cụ thểsau:

Nghiên cứu quy trình và số hóa

Nghiên cứu qui trình phát triển phần mềm

Nghiên cứu thực trạng quản lý phần mềm tại BIDV

Đề xuất số hóa quy trình quản lý phần mềm tại BIDV

3 Đối tượng và phạm vi nghiên cứu

Đối tượng nghiên cứu là: Số hóa quy trình quản lý phần mềm tại BIDV

Phạm vi nghiên cứu là: Các quy trình quản lý phần mềm thực hiện từ 2015đến nay tại trung tâm CNTT ngân hàng BIDV

4 Kết cấu của luận văn

Ngoài phần mở đầu, kết luận, danh mục chữ viết tắt, danh mục bảng biểu,danh mục tài liệu tham khảo, luận văn gồm 3 chương:

Chương 1 Cơ sở lý luận về số hóa quy trình quản lý phát triển phần mềmChương 2 Thực trạng quy trình quản lý phần mềm tại Trung tâm CNTT -Ngân hàng TMCP Đầu tư và phát triển Việt Nam

Chương 3 Giải pháp số hóa quy trình quản lý phát triển phần mềm tại Trungtâm CNTT - Ngân hàng TMCP Đầu tư và phát triển Việt Nam

CHƯƠNG 1

CƠ SỞ LÝ LUẬN VỀ SỐ HÓA QUY TRÌNH QUẢN LÝ

PHÁT TRIỂN PHẦN MỀM 1.1 Tổng quan về số hóa

1.1.1 Khái niệm về số hóa

Số hóa là hình thức hiện đại hóa, chuyển đổi các hệ thống thường sang hệthống kỹ thuật số

Số hóa dữ liệu lưu trữ là hình thức chuyển đổi dữ liệu từ dạng văn bản hệthống bên ngoài thành những dữ liệu dạng tín hiệu được máy tính hiểu và lưu trữ

Số hóa dữ liệu lưu trữ là biện pháp tối ưu, với số hóa dữ liệu giúp giải quyết việclưu trữ, truy xuất, chia sẻ, hay tìm kiếm thông tin hết sức dễ dàng Cắt giảm chi phí tối đacho việc quản lý và không gian lưu trữ Ngoài ra số hóa dữ liệu giúp chỉnh sửa và tái sửdụng tài liệu, linh hoạt trong việc chuyển đổi sang các dạng tài liệu số khác nhau

1.1.2 Quy trình số hóa

Hiện nay trong các tổ chức, hồ sơ dữ liệu chưa được số hóa rất nhiều nênviệc số hóa tài liệu cần được lựa chọn, tiêu chuẩn số hóa phụ thuộc vào mục tiêucủa chủ sở hữu

Quy trình số hóa gồm 5 bước sau:

Bảng 1.1 Các bước trong quy trình số hóa

Bước 1

Nhận tài liệu lưu trữ

đã được lựa chọn đểthực hiện số hóa

Tiêu chuẩn của việc lựa chọn tài liệu để sốhóa, phụ thuộc vào tiêu chuẩn của mỗi tổchức, đơn vị đánh giá

Bước 2 Chuẩn bị tài liệu - Phân loại tài liệu, tách các mức độ quan

trọng của từng tài liệu để số hóa cho phù hợpBước 3 Thiết lập hệ thống - Scan và thiết lập hệ thống ảnh: đặt tên file,

đặt định dạng, đóng, ghim lại theo tổ chức tàiliệu ban đầu, tạo siêu siêu dữ liệu

- Đây là bước quyết định nhất để chuyển đổitài liệu truyền thống sang tài liệu số hóa

Các Bước Nội dung Ý nghĩa (sản phẩm)

Danh mục tài liệu số hóa được lập vànhúng, tài liệu thông qua một phần mềmứng dụng và tạo ra metadata, đồng thời tàiliệu được đặt định dạng theo sự lựa chọnđược định trước

Bước 4 Kiểm tra tài liệu Kiểm tra tài liệu đã được số hóa và làm lại

những ảnh không đạt yêu cầu

Bước 5 Nghiệm thu bàn

giao tài liệu lưu trữ

Công việc bao gồm bàn giao tài liệu số hóa

và tài liệu gốc Nếu tài liệu số hóa là tài liệucủa một lưu trữ lịch sử, thì với những vănbản không đóng quyển trong một hồ sơ, việcbàn giao phải được kiểm tra chặt chẽ từngtrang tài liệu để đảm bảo đầy đủ như tài liệuban đầu đã nhận ở Bước 1

1.1.3 Vai trò của số hóa

- Giảm không gian lưu trữ

- Lưu trữ, quản lý sản phẩm vĩnh viễn

- Hạn chế hư hỏng, mất mát do các yếu tố bên ngoài như thời tiết, côn trùng,hỏa hoạn, ẩm mốc…

- Quản lý khoa học, tiết kiệm thời gian tìm kiếm

- Chia sẻ thông tin nhanh chóng

- Tăng cường khả năng bảo mật thông tin

- Chi phí vận hành và quản lý thấp nhưng vẫn mang lại hiệu quả cao

1.2 Quy trình phát triển phần mềm

1.2.1 Khái niệm

Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác

và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sảnphẩm phần mềm

ra của giai đoạn này là Tài liệu đặc tả yêu cầu

Kết quả: Source code

4 Bước 4 Kiểm thử

Nhiệm vụ: Tester tạo kịch bản kiểm thử (testcase) theo tài liệu đặc tả yêu cầu, thực hiệnkiểm thử và cập nhật kết quả vào kịch bảnkiểm thử, log lỗi trên các tool quản lý lỗi

Kết quả: Test case, lỗi trên hệ thống quản lý lỗi

5 Bước 5 Triển khai Nhiệm vụ: Triển khai sản phẩm cho khách hàng.

Kết quả: Biên bản triển khai với khách hàng

1.2.3 Một số mô hình cho việc xây dựng quy trình phát triển phần mềm.

Có rất nhiều mô hình phát triển phần mềm nhưng 3 mô hình phát triển phầnmềm phổ biến nhất đó là: Mô hình thác nước, Mô hình chữ V, Mô hình Agile(Phương pháp Scrum).

1.2.3.1 Mô hình thác nước

Hình 1.1 Mô hình thác nước

Mô hình này gồm các giai đoạn xử lý nối tiếp nhau như sau:

Thu thập yêu cầu (Requirement gathering): Đây là giai đoạn xác định cácyêu cầu chức năng và phi chức năng mà hệ thống phần mềm cần có Kết quả củagiai đoạn này là bản tài liệu đặc tả yêu cầu Tài liệu này sẽ là nền tảng cho nhữnggiai đoạn tiếp theo cho đến cuối dự án

Phân tích hệ thống (System Analysis): Là giai đoạn định ra làm thế nào để hệthống phần mềm đáp ứng đúng yêu cầu của khách hàng Giai đoạn này thực hiệnphân tích, thiết kế hệ thống phần mềm

Coding: Là giai đoạn thực hiện sản phẩm dựa trên đặc tả yêu cầu và tài liệuthiết kế module

Testing: Tester sẽ nhận sản phẩm từ developer và thực hiện kiểm thử chonhóm các thành phần và kiểm thử hệ thống Khâu kiểm thử cuối cùng sẽ là Kiểmthử chấp nhận, giai đoạn này còn có sự tham gia của khách hàng

Implementation: Triển khai hệ thống ra môi trường của khách hàng

Operations & Maintenance: Đây là giai đoạn cài đặt, cấu hình và đào tạo chokhách hàng Giai đoạn này sửa chữa những lỗi của sản phẩm (nếu có) và phát triểnnhững thay đổi mới được khách hàng yêu cầu.

Đặc điểm:

Thường áp dụng cho các phần mềm có quy mô vừa và nhỏ

Các dự án có yêu cầu rõ ràng, ít thay đổi

Nguồn lực được đào tạo và sẵn sàng

Ưu điểm: Vì có yêu cầu rõ ràng nên dễ hiểu, dễ áp dụng Dễ phân công công

việc, bố trí, giám sát

Nhược điểm: Thực tế cho thấy rằng đến những giai đoạn cuối cùng của dự án

mới có khả năng nhận ra sai sót trong những giai đoạn trước để có thể quay lại sửa chữa

1.2.3.2 Mô hình chữ V

Hình 1.2 Mô hình chữ V

Hoạt động tốt với các dự án có quy mô vừa và nhỏ

Dễ dàng quản lý vì mỗi giai đoạn có các mục tiêu và mục tiêu được xác định

rõ ràng

Toàn bộ quy trình được chia thành 2 nhóm giai đoạn tương ứng nhau là pháttriển và kiểm thử Mỗi giai đoạn phát triển sẽ tiến hành song song với một giai đoạnkiểm thử tương ứng Do đó, các lỗi được phát hiện sớm ngay từ đầu.

Ưu điểm

Ngay từ lúc nhận được tài liệu đặc tả yêu cầu, tester sẽ tham gia vào reviewtài liệu đặc tả yêu cầu sau đó lên kế hoạch và thực hiện viết test case Lỗi được pháthiện từ giai đoạn này sẽ ít tốn thời gian và chi phí hơn các giai đoạn sau

Nhược điểm

Trong mô hình chữ V, các yêu cầu vẫn được đưa vào thực hiện cùng 1 lúc

mà rủi ro về thay đổi yêu cầu từ phía khách hàng là rất lớn Do đó, mô hình này vẫn

có thể gặp rắc rối khi khách hàng thường xuyên thay đổi yêu cầu

1.2.3.3 Mô hình Agile: quy trình Scrum

Hình 1.3 Mô hình Agile

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sảnphẩm đến tay người dùng càng nhanh càng tốt

Đặc trưng của Agile:

Tính lặp (Interactive): Dự án sẽ được thực hiện trong các phân đoạn lặp đilặp lại Các phân đoạn (được gọi là Interation hoặc Sprint) này thường có khungthời gian ngắn (từ 1 đến 4 tuần) Trong mỗi phân đoạn này, nhóm phát triển phải

thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết

kế, triển khai, kiểm thử để cho ra các phần nhỏ của sản phẩm Các phân đoạn Sprintlặp đi lặp lại trong Agile: các phương pháp Agile thường phân rã mục tiêu thành cácphần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, không thựchiện lập kế hoạch dài hạn

Tính tiệm tiến và tiến hóa: Cuối các phân đoạn Sprint, nhóm phát triểnthường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường đầy

đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng được ngay.Theo thời gian, các phân đoạn này nối tiếp các phân đoạn kia, các phần chạy đượctích lũy và lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn

Tính thích ứng: Do các sprint chỉ kéo dài trong khoảng 1 thời gian ngắn và

việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trìnhphát triển đều có thể áp dụng theo cách thích hợp Theo đó, các quy trình Agilethường thích ứng rất tốt với các thay đổi

Quy trình Scrum

Scrum là một quy trình phát triển phần mềm theo mô hình linh hoạt Vì thế,

nó tuân thủ các nguyên tắc của Agile Scrum rất linh hoạt như các phương phápAgile khác Nhờ đó nó mang lại tính thích nghi rất cao Dựa trên các thông tin minhbạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thayđổi một cách tích cực, nhờ đó mang lại thành công cho dự án

Các công cụ (artifacts) Scrum:

Product backlog: Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu

ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án.Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (ProductBacklog Item) trong Product Backlog dựa trên các giá trị do Product Owner định

nghĩa Sprint backlog: Đây là bản kế hoạch cho một Sprint, là kết quả của buổi họp

lập kế hoạch (Sprint Planning) Với sự kết hợp của Product Owner, nhóm sẽ phântích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mụctrong Product Backlog dưới dạng danh sách công việc (TODO list)

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với cáchạng mục được sắp theo thứ tự ưu tiên Đội sản xuất sẽ thực hiện việc hiện thực hóadần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn từ 1 đến 4 tuần làmviệc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các góiphần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable ProductIncrement)

Đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint.Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứacác công việc cần làm trong suốt một Sprint

Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong ProductBacklog đều được hoàn tất

Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog vàthực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũngnhư các vướng mắc trong quá trình làm việc cùng nhau Nhóm được trao quyền để

tự quản lý và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint

Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh,sẵn sàng chuyển giao (shippable) cho khác hàng Buổi họp Sơ kết Sprint (SprintReview) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giaonhững gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến

Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họpCải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint tiếp theobắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint

Hình 1.4 Mô hình nguyên lý hoạt động của Scrum

Bao gồm 4 cuộc họp như sau:

Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển họp với Product

Owner để lên kế hoạch làm việc cho một Sprint Công việc lập kế hoạch bao gồmviệc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việcphải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ Scrum sửdụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập

kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặplại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm

Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sảnxuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ côngviệc Trong cuộc họp này, từng người trong nhóm phát triển lần lượt trình bày để trảlời 3 câu hỏi sau:

Hôm qua đã làm gì?

Hôm nay sẽ làm gì?

Có khó khăn trở ngại gì không?

Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng vớiProduct Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừaqua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm

Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp của ScrumMaster, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cảitiến quy trình làm việc cũng như bản thân sản phẩm.

Bao gồm 3 vai trò:

Product Owner: Là người chịu trách nhiệm về sự thành công dự án, ngườiđịnh nghĩa các yêu cầu cho sản phẩm và đánh giá đầu ra cuối cùng của các nhà pháttriển phần mềm

Scrum Master: Là người đảm bảo các sprint được hoàn thành theo đúng quytrình Scrum, giúp đỡ loại bỏ các trở ngại cho đội dự án

Development Team: Là tập hợp của từ 5 đến 9 thành viên chịu trách nhiệm trựctiếp tham gia sản xuất Tùy theo quy mô của dự án để bố trí số thành viên cho phùhợp

Ưu điểm:

Phù hợp với các yêu cầu / nghiệp vụ hay thay đổi, hoặc hệ thống nghiên cứu

do làm theo từng giai đoạn ngắn ngày, có thể nhìn thấy những rủi ro hay nhữngđiểm chưa phù hợp để thay đổi

Nhược điểm:

Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết

Quy mô nhân lực thường giới hạn, sẽ có trở ngại lớn nếu nguồn nhân lực yêucầu vượt quá con số này ví dụ trong các cuộc họp trao đổi

Yêu cầu nguồn nhân lực phải có kiến thức và am hiểu về Agile

1.3 Kết luận chương 1

Trong chương 1, luận văn đã giới thiệu cơ sở lý thuyết liên quan đến nghiêncứu của đề tài như: khái niệm, các vấn đề liên quan đến số hóa và các qui trình pháttriển phần mềm nói chung Để đề xuất được giải pháp số hóa quy trình quản lý pháttriển tại Trung tâm CNTT - Ngân hàng BIDV cần tìm hiểu thực trạng của qui trìnhquản lý phát triển phần mềm tại trung tâm hiện nay Nội dung này sẽ được trình bàytrong nội dung của chương tiếp theo

CHƯƠNG 2 THỰC TRẠNG QUY TRÌNH QUẢN LÝ PHÁT TRIỂN

PHẦN MỀM THEO QUY ĐỊNH CỦA BIDV

TẠI TRUNG TÂM CNTT 2.1 Giới thiệu về BIDV

Tên đầy đủ: Ngân hàng TMCP Đầu tư và Phát triển Việt Nam

Tên giao dịch quốc tế: Joint Stock Commercial Bank for Investment andDevelopment of Vietnam Tên gọi tắt: BIDV

Địa chỉ: Tháp BIDV, 35 Hàng Vôi, quận Hoàn Kiếm, Hà Nội

Điện thoại:19009247; Fax:0422200399; Email: Info@bidv com vn

Ngân hàng Đầu tư và Phát triển Việt nam (BIDV) được thành lập ngày 26tháng 4 năm 1957 theo Quyết định số 177-TTg ngày 26/4/1957 của Thủ tướngChính phủ với tên gọi ban đầu là “Ngân hàng Kiến Thiết Việt Nam” Khi mới thànhlập, BIDV hoạt động với chức năng là một cơ quan quản lý nguồn vốn xây dựng cơbản được cấp từ ngân sách Nhà Nước để tài trợ cho các dự án đầu tư xây dựng cơbản Từ năm 1995, BIDV đã chính thức chuyển đổi thành một NHTM đa năng,cung cấp đầy đủ các dịch vụ và sản phẩm ngân hàng từ tiền tệ, tín dụng, dịch vụngân hàng, cho tới cho vay đối với những dự án hạ tầng cơ sở

KHỐI LIÊN DOANH

Ngân Hàng Liên Doanh VID-PublicTrụ Sở Chính tại Hà NộiNgân Hàng Liên Doanh Lào-Việt Trụ Sở Chính tại , Lào

Công Ty Cho Thuê Tài Chính II

Công Ty Chứng Khoán BIDV Công Ty Cho Thuê Tài Chính

Trung Tâm Công Nghệ Thông Tin

Viện Đào Tạo và nghiên cứu

KHỐI ĐƠN VỊ SỰ NGHIỆP

Ngân Hàng Liên Doanh Việt Nga Trụ Sở Chính tại Hà Nội

190 Chi Nhánh

Công Ty TNHH BIDV Quốc Tế

Hiện nay BIDV là một trong bốn Ngân hàng Nhà nước và TMCP NN(NHTMCP NN) lớn của Việt Nam giữ vai trò chủ đạo trong phục vụ đầu tư pháttriển có chức năng huy động vốn dài hạn, trung hạn và ngắn hạn trong nước vàngoài nước để đầu tư phát triển, kinh doanh đa năng tổng hợp về tài chính tiền tệ,tín dụng ngân hàng; làm Ngân hàng đại lý, ngân hàng phục vụ cho đầu tư phát triển

từ các nguồn vốn của Chính phủ, các tổ chức tài chính, tiền tệ, các tổ chức kinh tế,

xã hội, trong và ngoài nước theo quy định của pháp luật về Ngân hàng

BIDV có hệ thống tổ chức với mạng lưới chi nhánh, văn phòng đại diện vàcác đơn vị trực thuộc rộng khắp ngân hàng có 190 chi nhánh tại 63 tỉnh/TP trên toànquốc được hỗ trợ bởi 871 phòng giao dịch, 104 quỹ tiết kiệm, 1800 máy rút tiền tựđộng (ATM) và gần 25.000 điểm chấp nhận thẻ (POS) Mặc dù BIDV đã và đangtập trung mở rộng hoạt động kinh doanh ngân hàng bán lẻ, ngân hàng vẫn tiếp tụctài trợ cho những dự án đầu tư xây dựng cơ bản và phát triển BIDV có mối quan hệthường xuyên với hơn 1,050 ngân hàng và các tổ chức tài chính trên toàn thế giới

Ngoài ra, BIDV còn có một số công ty con và liên doanh như: Công ty chothuê tài chính, công ty chứng khoán, liên doanh VID Public Bank, ngân hàng liêndoanh Lào- Việt, Ngân hàng liên doanh Việt Nga, Công ty Bảo hiểm BIDV

Năm 2019 cũng là năm BIDV tiếp tục bứt phá, hoàn thành xuất sắc, toàndiện tất cả các chỉ tiêu kế hoạch đặt ra Việc chào bán thành công hơn 603 triệu cổphiếu với giá trị giao dịch 20.295 tỷ đồng cho Nhà đầu tư chiến lược KEB HanaBank (Hàn Quốc) đã đánh dấu nấc thang mới trong quá trình phát triển và hội nhậpquốc tế của BIDV Đây là giao dịch bán cổ phần cho Nhà đầu tư chiến lược nướcngoài lớn nhất trong hệ thống ngân hàng từ trước đến nay Giao dịch này có ý nghĩarất lớn đối với BIDV, mang lại cho BIDV nguồn lực tài chính mạnh mẽ, tăng quy

mô vốn điều lệ lên 40.220 tỷ đồng, cao nhất trong hệ thống các tổ chức tín dụng(TCTD) Việt Nam hiện nay; Đồng thời, nâng cao năng lực tài chính, đảm bảo hệ số

an toàn vốn, thúc đẩy tăng trưởng và phát triển bền vững cho BIDV

Giữ vững vị thế là ngân hàng ứng dụng công nghệ thông tin (CNTT) hàngđầu trong hệ thống, năm 2019 BIDV đã hoàn thành việc xây dựng chiến lược số

hóa, chính thức thành lập và đưa vào hoạt động của Trung tâm Ngân hàng số(TTNHS), Trung tâm sáng tạo của BIDV, là nơi sản sinh các sản phẩm tiên tiến, hiệnđại hướng tới khách hàng và thử nghiệm các mô hình kinh doanh mới trên nền tảngcông nghệ số

2.2 Các hình thức phát triển phần mềm

Tại BIDV việc phát triển phần mềm phần mềm được thực hiện theo 3 quytrình, cụ thể:

2.2.1 Quy trình phát triển phần mềm theo hình thức cổ điển

Bước 1: Xây dựng URD

- Đơn vị nghiệp vụ đầu mối tiến hành xây dựng URD và gửi xin ý kiến góp ýcủa các đơn vị liên quan Thời hạn góp ý URD không quá 05 ngày làm việc kể từkhi nhận được văn bản xin góp ý

- Đơn vị nghiệp vụ đầu mối hoàn thiện URD theo góp ý của các đơn vị liênquan trình cấp có thẩm quyền phê duyệt URD

- Trung tâm CNTT hỗ trợ Đơn vị nghiệp vụ đầu mối trong quá trình xâydựng URD đối với các phần mềm đòi hỏi hiểu biết về kỹ thuật

- Đơn vị nghiệp vụ đầu mối gửi URD đã được phê duyệt tới Ban Công nghệ

và Trung tâm CNTT để phân khai kế hoạch chi tiết và tổ chức thực hiện PTPM

Bước 2: Phân khai kế hoạch chi tiết thực hiện PTPM

Sau khi nhận được URD đã được phê duyệt, Ban Công nghệ phối hợp vớiTrung tâm CNTT thực hiện:

 Trung tâm CNTT thực hiện lập khái toán ngày công PTPM

 Đề xuất kế hoạch thực hiện chi tiết, gửi tới Ban Công nghệ để giám sátthực hiện chậm nhất là 45 ngày kể từ khi nhận được đầy đủ tài liệu URD

từ đơn vị nghiệp vụ

Bước 3 Xây dựng, thẩm định tài liệu RSD

- Trung tâm CNTT xây dựng tài liệu RSD trong quá trình thực hiện xây dựngphần mềm Tài liệu RSD phải đảm bảo đầy đủ, chi tiết các nội dung cần thiết để xây

dựng, kiểm tra nghiệm thu phần mềm đảm bảo chất lượng, tối thiểu cần nêu rõ cácnội dung sau:

- Tên gọi (theo URD), mã kế hoạch của phần mềm;

- Nội dung RSD phải nêu được các chức năng cần có, mỗi chức năng cần xácđịnh tối thiểu các thông tin cụ thể sau:

 Dữ liệu đầu vào: Gồm những thông tin gì, nguồn dữ liệu với mỗi thông tinđầu vào (nhập tay, chọn từ danh sách), các yêu cầu kiểm tra tính hợp lệcủa các thông tin đầu vào;

 Các nút chức năng và yêu cầu xử lý ở mỗi nút chức năng;

 Dữ liệu đầu ra: Gồm những thông tin gì, cần phải kiểm tra tính hợp lệ củatừng thông tin như thế nào;

 Mô tả cụ thể luồng xử lý của nghiệp vụ trong tác nghiệp thực tế (nếu cần);

- Những chức năng trong URD bị loại bỏ, không xây dựng (nếu có);

- Bảng dự toán chi tiết ngày công;

- Đề nghị điều chỉnh kế hoạch chi tiết và lý do điều chỉnh (nếu cần);

- RSD được làm thành 02 bản được ký xác nhận bởi: Lãnh đạo Trung tâmCNTT, Lãnh đạo Đơn vị nghiệp vụ và mỗi đơn vị (Đơn vị nghiệp vụ đầu mối,Trung tâm CNTT) giữ một bản;

- Trung tâm CNTT gửi RSD đã được phê duyệt và văn bản đề nghị thẩmđịnh RSD về Ban Công nghệ để thẩm định chậm nhất là giữa thời hạn hoàn thànhxây dựng phần mềm tính từ thời điểm bắt đầu thực hiện phân tích thiết kế phầnmềm (gửi bản RSD đã được phê duyệt và bản mềm kèm theo)

- Sau khi nhận được đầy đủ hồ sơ thẩm định RSD, trong vòng tối đa 10 ngàylàm việc, Ban Công nghệ hoàn thành thẩm định RSD, ghi nhận manday thực hiện,điều chỉnh kế hoạch chi tiết (nếu cần) và thông báo tới các đơn vị liên quan để phốihợp thực hiện Báo cáo thẩm định RSD được lập theo Mẫu số BM01B-QLPM

Bước 4: Phân tích, thiết kế phần mềm

- Trung tâm CNTT thực hiện phân tích URD nhằm làm rõ nội dung nghiệp

vụ một cách tổng thể và có hệ thống

- Trung tâm CNTT thực hiện thiết kế phần mềm, những nội dung chính củathiết kế chương trình phần mềm phải đảm bảo:

 Thiết kế phải đảm bảo tuân thủ chuẩn kiến trúc phần mềm của BIDV, đảmbảo tải trọng hệ thống, đảm bảo an toàn bảo mật;

 Thiết kế cơ sở dữ liệu, thuật toán xử lý và giao diện với các hệ thống phầnmềm khác

 Thiết kế các mô đun (Module), thư viện sử dụng chung cho các phần mềm

có liên quan, tổ chức đào tạo, phổ biến cho tất cả cán bộ PTPM về các môđun, thư viện dùng chung để khai thác, sử dụng một cách thống nhất, đồng

bộ nhằm tiết kiệm thời gian và nâng cao hiệu quả PTPM;

 Thiết kế các mô đun, các hàm và các thủ tục;

 Phải thể hiện được mô hình logic, mô hình vật lý của hệ thống, mô tả đầy

đủ mục đích, chức năng chi tiết của từng thành phần/cấu phần/mô đun của

hệ thống, thể hiện đầy đủ, cụ thể các luồng xử lý/hoạt động của hệ thống,chi tiết về kỹ thuật làm cơ sở trực tiếp cho lập trình

 Thiết kế phần mềm phải có: chức năng hướng dẫn sử dụng chương trìnhtrực tuyến (help online) có thể cập nhật hướng dẫn sử dụng một cách dễdàng, thuận tiện và có chức năng cho phép gửi thông báo (ở màn hìnhchính) tới người sử dụng các thông tin gấp, cần thiết

- Đối với phần mềm xây dựng mới/nâng cấp có thay đổi kiến trúc/thiết kếtổng thể của hệ thống:

 Trung tâm CNTT mời Ban Công nghệ tham gia các buổi thảo luậnhoặc tham gia góp ý về tài liệu phân tích thiết kế (PTTK) cùng với quátrình làm việc của Hội đồng PTTK của Trung tâm CNTT Các ý kiến phảnbiện của Ban Công nghệ với phương án thiết kế của Trung tâm CNTT(nếu có) phải ghi vào biên bản làm việc của Hội đồng PTTK có ký xácnhận của thành viên Ban Công nghệ hoặc được phản hồi bằng vănbản/email cho Trung tâm CNTT

 Tài liệu phân tích thiết kế/tài liệu kỹ thuật nâng cấp phải trình bày/cậpnhật lại mô hình thiết kế tổng thể của hệ thống (vẽ lại toàn bộ mô hình đầy

đủ các module được bổ sung/nâng cấp) và mô tả luồng xử lý, chức năngcủa từng module được bổ sung/nâng cấp

- Tài liệu phân tích, thiết kế/Tài liệu kỹ thuật của phần mềm phải được Trungtâm CNTT phê duyệt (Ban Giám đốc Trung tâm CNTT phê duyệt hoặc phân loại vàphân cấp ủy quyền cho Lãnh đạo cấp phòng của Trung tâm CNTT phê duyệt)

- Trung tâm CNTT ban hành Tài liệu hướng dẫn chi tiết về thực hiện PTTK

và xây dựng tài liệu PTTK phần mềm

Bước 5 Xây dựng phần mềm

- Trung tâm CNTT tổ chức lập trình tuân thủ tài liệu phân tích thiết kế vàtuân thủ các tiêu chuẩn, quy cách xây dựng mã nguồn phần mềm và sử dụng các môđun, thư viện dùng chung một cách đồng bộ, thống nhất

- Trung tâm CNTT ban hành sổ tay về tiêu chuẩn, quy cách xây dựng mãnguồn phần mềm phải đảm bảo cho việc cán bộ mới (không tham gia nhóm xâydựng phần mềm đó) dễ dàng tìm hiểu, làm chủ được việc nâng cấp, bảo trì phầnmềm Tiêu chuẩn viết mã chương trình cần đảm bảo tối thiểu các yêu cầu sau:

 Áp dụng thống nhất các khung phần mềm (frame work) và có tài liệuthuyết minh cụ thể về các đặc điểm kỹ thuật của khung phần mềm đó;

 Trình bày cấu trúc mã chương trình mạch lạc và có thứ bậ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ệtgiữa các đối tượng với nhau;

 Phải có các ghi chú, giải thích đối với các đoạn mã để giải thích các xử lýcủa chương trình Nội dung ghi chú phải bao gồm các nội dung: mô tảchung đoạn mã chương trình, ngày sửa, người sửa, người kiểm tra và nộidung sửa;

 Tên và số hiệu phiên bản phần mềm phải thể hiện rõ trên màn hình chínhcủa phần mềm

- Việc sử dụng các công cụ lập trình miễn phí hoặc mã nguồn mở (nếu có)phải là những công cụ lập trình hoặc mã nguồn mở được sử dụng phổ biến và đượccộng đồng người sử dụng đánh giá là an toàn;

- Trong quá trình lập trình, thư mục mã nguồn và cơ sở dữ liệu cần được saolưu định kỳ (tối thiểu 3 ngày làm việc/lần) để tránh mất mát trong trường hợp máytính xảy ra sự cố và chỉ những thành viên trong nhóm phát triển mới được phép truycập

- Trung tâm CNTT chủ động phối hợp với Đơn vị nghiệp vụ đầu mối kiểmthử ngay trong quá trình xây dựng phần mềm Đồng thời, Trung tâm CNTT thựchiện kiểm thử phần mềm trong nội bộ Trung tâm ngay ở giai đoạn cuối của khâu lậptrình nhằm đảm bảo đã hoàn thành xây dựng phần mềm trước ngày đề nghị Đơn vịnghiệp vụ bắt đầu thực hiện kiểm thử nghiệm thu

- Trung tâm CNTT gửi văn bản cho Ban Công nghệ và Đơn vị nghiệp vụ đầumối thông báo hoàn thành xây dựng phần mềm và đề nghị Đơn vị nghiệp vụ đầumối tổ chức kiểm thử nghiệm thu trước ngày dự kiến bắt đầu tiến hành kiểm thửnghiệm thu ít nhất 5 ngày làm việc

- Hoàn thành xây dựng phần mềm được xác định là: đã hoàn thành việc phântích, thiết kế, lập trình phần mềm, hoàn thành xây dựng tài liệu hướng dẫn cài đặt,tài liệu hướng dẫn sử dụng sơ bộ, hoàn thành việc kiểm thử nội bộ trong Trung tâmCNTT (đảm bảo phần mềm không còn lỗi kỹ thuật, đã có đầy đủ các chức năng,tính năng theo RSD và các Biên bản ghi nhớ (nếu có) và hoàn thành chuẩn bị môitrường kiểm thử nghiệm thu sẵn sàng cho Tổ kiểm thử nghiệm thu nghiệp vụ làmviệc)

- Thời điểm hoàn thành xây dựng phần mềm được căn cứ vào văn bản thôngbáo hoàn thành xây dựng phần mềm của Trung tâm CNTT (trường hợp phần mềmhoặc môi trường chưa sẵn sàng cho Tổ KTNT nghiệp vụ làm việc theo kế hoạchđược Trung tâm CNTT thông báo, Đơn vị nghiệp vụ đầu mối gửi văn bản cho BanCông nghệ để giám sát tiến độ thực tế)

Bước 6 Kiểm thử, nghiệm thu phần mềm

- Trung tâm CNTT/Đơn vị nghiệp vụ đầu mối chủ động thực hiện việc thành

lập Tổ kiểm thử nghiệm thu (KTNT) kỹ thuật/nghiệp vụ, xây dựng kịch bản KTNT

kỹ thuật/nghiệp vụ ngay sau khi có thông báo kế hoạch PTPM chi tiết Tổ KTNTnếu chỉ bao gồm các cán bộ của Đơn vị sẽ do lãnh đạo Đơn vị ký duyệt văn bảnthành lập Tổ KTNT, nếu bao gồm các cán bộ của nhiều Đơn vị hoặc cán bộ của Chinhánh thì Đơn vị đầu mối cần trình Phó Tổng Giám đốc phụ trách phê duyệt Tờtrình thành lập Tổ KTNT

- Cán bộ tham gia tổ KTNT kỹ thuật không phải là cán bộ tham gia xây dựngphần mềm và phải am hiểu các vấn đề kỹ thuật cần thực hiện kiểm thử nghiệm thutheo kịch bản kiểm thử Các cán bộ tham gia trong Tổ KTNT nghiệp vụ phải là cáccán bộ am hiểu nghiệp vụ của phần mềm cần kiểm thử và các nghiệp vụ liên quan,thành thạo trong việc nhập các dữ liệu, giao dịch vào hệ thống kiểm thử Đối vớicác phần mềm có phạm vi triển khai tại Chi nhánh, phải có cán bộ Chi nhánh thamgia vào Tổ KTNT để đảm bảo phần mềm phù hợp với nhu cầu tác nghiệp tại Chinhánh

- Môi trường kiểm thử, nghiệm thu phải độc lập với môi trường phát triển,tách biệt với môi trường thật và phải đảm bảo giả lập được đầy đủ các yếu tố, thànhphần như môi trường thật, không để lộ thông tin khách hàng và thông tin tài khoản,giao dịch của khách hàng

- Kiểm thử nghiệm thử kỹ thuật:

 Tổ KTNT kỹ thuật thực hiện xây dựng kịch bản kiểm thử, nghiệm thu kỹthuật trình Lãnh đạo Trung tâm CNTT (hoặc cấp được ủy quyền) phêduyệt để thực hiện Kịch bản kiểm thử nghiệm thu kỹ thuật thuật được lậptheo Mẫu số BM02-QLPM và phải đảm bảo:

 Kiểm thử, nghiệm thu về cài đặt, cấu hình các tham số hệ thống, các chứcnăng quản trị, vận hành, giám sát của phần mềm

 Kiểm thử nghiệm thu về các yêu cầu kỹ thuật, khả năng chịu tải, an toànbảo mật của phần mềm

 Các nội dung kiểm thử, nghiệm thu khác (tùy thuộc vào tính năng, đặcđiểm của từng phần mềm) đảm bảo bao gồm đầy đủ các nội dung cầnkiểm thử về kỹ thuật, an toàn bảo mật.

 Nhóm kiểm thử, nghiệm thu kỹ thuật thực hiện kiểm thử, nghiệm thu kỹthuật và lập Báo cáo kết quả kiểm thử, nghiệm thu kỹ thuật theo Mẫu sốBM03-QLPM với kết luận, đề xuất cụ thể về mức độ đáp ứng điều kiện kỹthuật, an toàn bảo mật để triển khai kèm theo kết quả kiểm thử, nghiệmthu chi tiết theo kịch bản kiểm thử, nghiệm thu đã được phê duyệt

- Kiểm thử nghiệm thu nghiệp vụ:

 Tổ kiểm thử nghiệm thu nghiệp vụ xây dựng Kịch bản kiểm thử theo Mẫu

số BM04-QLPM trình Lãnh đạo đơn vị nghiệp vụ đầu mối phê duyệt.Kịch bản kiểm thử, nghiệm thu phải đảm bảo có đầy đủ các chức năng,báo cáo theo đúng URD/RSD và các biên bản ghi nhớ (nếu có), với mỗichức năng/báo cáo phải lập kịch bản kiểm thử chi tiết với các tình huống

nghiệp vụ có thể xảy ra (kể cả tình huống đúng và các tình huống sai quy trình kỹ thuật, nghiệp vụ)

 Trường hợp, việc chỉnh sửa, nâng cấp đối với phần mềm có các cấu phần

do các đơn vị đầu mối khác nhau phụ trách (như hệ thống Kondor gồmcấu phần K+ thuộc trách nhiệm của Ban KDV&TT, K+TP thuộcTTDVKH, MLS thuộc Ban QLRRTT&TN, KGR thuộc Ban QLRRTD),

Tổ kiểm thử nghiệm thu nghiệp vụ gửi Kịch bản kiểm thử xin ý kiến đốivới các đơn vị liên quan trước khi trình Lãnh đạo đơn vị nghiệp vụ đầumối phê duyệt

 Tổ KTNT nghiệp vụ chuẩn bị bộ dữ liệu cần nhập vào hệ thống với tất cả

các tình huống kiểm thử Trong trường hợp bắt buộc phải sử dụng dữ liệu

thật để phục vụ quá trình kiểm thử thì Tổ KTNT phải có văn bản nêu rõ lý

do và trình Phó Tổng Giám đốc phụ trách đơn vị nghiệp vụ đầu mối phêduyệt cho phép sử dụng dữ liệu thật (dữ liệu giao dịch thật trong quá khứ)

để phục KTNT phần mềm

 Chậm nhất trước 02 ngày làm việc kể từ ngày dự kiến bắt đầu kiểm thử,Đơn vị nghiệp vụ đầu mối phải gửi kế hoạch kiểm thử chi tiết (có thờigian, cán bộ kiểm thử từng chức năng/báo cáo), kịch bản kiểm thử chi tiết,chủ trương sử dụng dữ liệu thật (nếu có) đã được phê duyệt tới Trung tâmCNTT để chuẩn bị cơ sở vật chất, dữ liệu kiểm thử Trong trường hợpkhông thống nhất với Trung tâm CNTT về kế hoạch kiểm thử thì Đơn vịnghiệp vụ đầu mối phải có văn bản thông báo cho Trung tâm CNTT vàBan Công nghệ, trong đó nêu rõ các lý do chưa thống nhất và đề nghịphương án giải quyết cụ thể.

 Trung tâm CNTT hỗ trợ Tổ KTNT trong quá trình làm việc Tổ KTNT ghinhật ký kiểm thử có đẩy đủ thông tin theo Mẫu số BM05-QLPM

 Trong quá trình thực hiện KTNT, nếu phát sinh các tình huống làm chậm

tiến độ kế hoạch KTNT (phần mềm có nhiều lỗi/môi trường KTNT không

ổn định/Tổ TKNT không tiến hành KTNT đúng kế hoạch), thì Tổ

KTNT/Trung tâm CNTT (Bộ phận hỗ trợ KTNT) cần ghi biên bản/chứng

cứ ghi nhận lý do, nguyên nhân, thời gian gián đoạn làm căn cứ xem xéttrách nhiệm của từng Đơn vị trong việc để chậm tiến độ KTNT, đồng thờithông báo (qua văn bản/email) cho Ban Công nghệ và Trung tâmCNTT/Đơn vị nghiệp vụ để phối hợp xử lý Nếu không có các biênbản/bằng chứng để xác định rõ trách nhiệm của mỗi Đơn vị thì sẽ trừTrung tâm CNTT và Đơn vị nghiệp vụ đầu mối mỗi bên 50% số điểmchậm tiến độ KTNT

 Nếu quá thời hạn bắt đầu kiểm thử (theo thông báo của Trung tâm CNTT)

05 ngày làm việc trở lên mà chưa thực hiện kiểm thử hoặc không thựchiện kiểm thử từ 05 ngày làm việc liên tục trở nên mà không có lý do:

 Trung tâm CNTT sẽ tự động xóa bỏ, thu hồi môi trường kiểm thử vàthông báo bằng văn bản tới Đơn vị nghiệp vụ đầu mối, Ban Công nghệ(đồng thời gửi báo cáo các Phó Tổng Giám đốc phụ trách các đơn vị liênquan)

 Đơn vị nghiệp vụ đầu mối phải báo cáo giải trình và đề xuất phương án xử

lý trình Phó Tổng Giám đốc phụ trách đơn vị phê duyệt gửi Ban Côngnghệ, Trung tâm CNTT làm căn cứ xử lý tiếp

 Tổ kiểm thử, nghiệm thu nghiệp vụ hoàn thiện tài liệu hướng dẫn sử dụngphần mềm đảm bảo hướng dẫn sử dụng phần mềm được rõ ràng, cụ thể,lồng ghép các hướng dẫn về quy trình xử lý nghiệp vụ, các quy tắc nhập vàkiểm soát dữ liệu theo yêu cầu của nghiệp vụ trình lãnh đạo Đơn vịnghiệp vụ đầu mối ký ban hành

 Tổ kiểm thử, nghiệm thu nghiệp vụ lập Báo cáo kết quả kiểm thử, nghiệmthu nghiệp vụ trong đó:

 Đánh giá phần mềm đã đáp ứng đầy đủ URD/RSD, đủ điều kiện đểnghiệm thu về mặt nghiệp vụ hoặc nêu cụ thể các lỗi còn tồn tại, các điểmchưa đáp ứng URD/RSD và đề xuất xử lý cụ thể;

 Kết luận, đề xuất về khả năng, phương án triển khai phần mềm (triển khaithí điểm/triển khai chính thức) hoặc phương án xử lý nếu phần mềm chưađáp ứng yêu cầu nghiệp vụ;

 Kèm theo kết quả kiểm thử, nghiệm thu chi tiết theo kịch bản kiểm thử,nghiệm thu nghiệp vụ đã được phê duyệt

- Sau khi hoàn thành KTNT, các Đơn vị gửi hồ sơ phần mềm cho Ban Côngnghệ và Trung tâm CNTT (tài liệu không yêu cầu gửi bản cứng được gửi qua hệthống Văn phòng điện tử hoặc gửi qua email) để thực hiện báo cáo đánh giá quátrình PTPM:

- Trung tâm CNTT gửi các tài liệu sau:

Tài liệu phân tích, thiết kế/Tài liệu kỹ thuật (file scan bản đã được phê duyệt)

Văn bản thành lập Nhóm kiểm thử, nghiệm thu kỹ thuật và kịch bản KTNT kỹ thuật(file scan bản gốc)

 Tài liệu hướng dẫn cài đặt, vận hành (file scan bản đã được phê duyệt)

 Báo cáo kết quả kiểm thử, nghiệm thu kỹ thuật (bản gốc)

 Đơn vị nghiệp vụ đầu mối gửi Ban Công nghệ và Trung tâm CNTT:

 Văn bản thành lập Nhóm kiểm thử, nghiệm thu nghiệp vụ và kịch bảnkiểm thử, nghiệm thu nghiệp vụ (file scan bản gốc).

 Báo cáo kết quả kiểm thử, nghiệm thu nghiệp vụ (bản gốc có chữ kýNhóm kiểm thử và Lãnh đạo đơn vị nghiệp vụ đầu mối)

 Tài liệu hướng dẫn sử dụng đã được Lãnh đạo đơn vị nghiệp vụ đầu mốiphê duyệt (file scan bản đã được phê duyệt)

- Thời điểm hoàn thành KTNT được xác định là thời điểm Ban Công nghệnhận được đầy đủ hồ sơ phần mềm nêu trên

Bước 7: Lập báo cáo đánh giá quá trình PTPM

- Ban Công nghệ thực hiện lập báo cáo đánh giá quá trình PTPM, đảm bảophần mềm đã được thực hiện tuân thủ đúng/đủ các bước PTPM và đáp ứng đủ tiêuchuẩn nghiệm thu được quy định tại Quy định này trước khi triển khai

- Tiêu chuẩn nghiệm thu phần mềm

- Phần mềm được chấp nhận nghiệm thu chỉ khi đáp ứng đầy đủ các điềukiện sau đây:

 Hồ sơ phần mềm đã đầy đủ các tài liệu theo danh mục hồ sơ phần mềmđược nêu tại biểu mẫu số BM09-QLPM

 Báo cáo kết quả kiểm thử, nghiệm thu kỹ thuật với kết luận phần mềm đãđáp ứng các yêu cầu kỹ thuật, đủ điều kiện về mặt kỹ thuật, an toàn bảomật để triển khai phần mềm (nếu còn nội dung chưa được kiểm thử hoặcchưa đạt yêu cầu nhưng được đánh giá là không ảnh hưởng đến chất lượngphần mềm nếu được triển khai)

 Báo cáo kết quả kiểm thử, nghiệm thu nghiệp vụ có kết luận phần mềm đãđáp ứng đầy đủ các nội dung URD/RSD, đủ điều kiện về mặt nghiệp vụ để

có thể triển khai (nếu còn nội dung chưa được kiểm thử hoặc chưa đạt yêucầu nhưng được đánh giá là không ảnh hưởng đến chất lượng phần mềmnếu được triển khai)

- Căn cứ hồ sơ phần mềm đã được bàn giao đầy đủ theo quy định, trong vòngkhông quá 07 ngày làm việc, Ban Công nghệ lập báo cáo đánh giá quá trình PTPM

Bước 8 Triển khai phần mềm

- Sau khi nhận được báo cáo đánh giá quá trình PTPM từ Ban Công nghệ(phần mềm đã đủ tiêu chuẩn nghiệm thu), Đơn vị nghiệp vụ đầu mối phối hợp vớiTrung tâm CNTT lập phương án, kế hoạch triển khai phần mềm (phù hợp với tìnhhình chuẩn bị các điều kiện kỹ thuật cần thiết để triển khai phần mềm của Trungtâm CNTT) trình Phó Tổng Giám đốc phụ trách đơn vị nghiệp vụ phê duyệt gửiTrung tâm CNTT để thực hiện triển khai, gửi Ban Công nghệ để giám sát

- Căn cứ phương án, kế hoạch triển khai đã được Phó Tổng Giám đốc phụtrách đơn vị nghiệp vụ phê duyệt, Trung tâm CNTT phối hợp Đơn vị nghiệp vụ đầumối thực hiện triển khai phần mềm, hỗ trợ các đơn vị sử dụng phần mềm

- Trường hợp phần mềm là ứng dụng các ứng dụng dành cho thiết bị di độngđược cung cấp trên kho dữ liệu trực tuyến:

- Trung tâm CNTT phải kiểm soát chặt chẽ việc đưa đưa phần mềm lên khoứng dụng trực tuyến (Apple Store, CH Play, Windows,…) Cụ thể:

 Phân giao nhiệm vụ và cấp quyền cho cho cán bộ đưa ứng dụng lên cáckho ứng dụng trực tuyến;

 Giao nhiệm vụ cho cán bộ giám sát việc đưa ứng dụng lên các kho ứngdụng trực tuyến;

 Đảm bảo đưa đúng phiên bản và đúng ứng dụng lên các kho ứng dụng trựctuyến;

 Định kỳ hàng tháng thực hiện rà soát các ứng dụng giả mạo trên các khoứng dụng trực tuyến và thực hiện các thủ tục để gỡ bỏ các ứng dụng giảmạo trên các kho ứng dụng trực tuyến (nếu có)

- Đơn vị đầu mối nghiệp vụ đối với các ứng dụng dành cho thiết bị di động được

cung cấp trên kho dữ liệu trực tuyến, thường xuyên rà soát các ý kiến của khách hàng để:

 Có xử lý phù hợp, theo đúng quy định của BIDV đối với các bình luậntiêu cực tác động đến khách hàng sử dụng;

 Tập hợp các ý kiến tham gia góp ý về tính năng, tiện ích của ứng dụng đểkịp thời bổ sung, chỉnh sửa đáp ứng tốt hơn nhu cầu khách hàng

- Chậm nhất sau 02 tháng kể từ thời hạn triển khai phần mềm, nếu phần mềmchưa được triển khai hoặc không thể triển khai thì Đơn vị nghiệp vụ đầu mối phải

có văn bản giải trình (nêu rõ đề xuất kế hoạch triển khai hoặc phương án xử lý) gửiBan Công nghệ để tổng hợp, báo cáo Phó Tổng Giám đốc phụ trách Ban Công nghệ

Bước 2: Xây dựng Yêu cầu người sử dụng (URD)

Không xác định được các yêu cầu chi tiết ngay từ đầu Tuy nhiên, phải cókhung tổng thể và danh mục các chức năng được Lãnh đạo/PTGĐ phụ trách về nghiệp

vụ phê duyệt Trước khi xây dựng nhóm chức năng nào thì tài liệu mô tả nhóm chứcnăng đó (Product Backlog) phải được Lãnh đạo/PTGĐ phụ trách về nghiệp vụ phêduyệt

Bước 3: Phân khai kế hoạch chi tiết

Squad Team chủ động phân chia các phân đoạn và chủ động điều chỉnh linhhoạt các phân đoạn cho phù hợp với tình hình triển khai thực tế nhằm đáp ứng yêucầu tiến độ triển khai và đạt hiệu quả, chất lượng cao nhất

Bước 4: Xây dựng, phê duyệt tài liệu PTTK của PM

Tài liệu PTTK và kiến trúc tổng thể của PM phải được Lãnh đạo phụ trách

về kỹ thuật phê duyệt trước khi tiến hành xây dựng các chức năng chi tiết của PM

Hạn chế tối đa việc thay đổi yêu cầu trong quá trình PTPM

Các nội dung thay đổi yêu cầu được linh hoạt chấp nhận trong quá trình pháttriển, tuy nhiên nếu thay đổi có ảnh hưởng lớn tới mục tiêu/đặc tính sản phẩm đãđược phê duyệt hoặc làm chậm tiến độ hoàn thành theo kế hoạch chi tiết đã phânkhai từng giai đoạn thì cần báo cáo Ban lãnh đạo phê duyệt

Bước 5: Xây dựng, thẩm định RSD và dự toán ngày công PTPM

Không có tài liệu RSD, việc lập và thẩm định dự toán ngày công PTPM đượcthực hiện cùng với báo cáo đánh giá quá trình PTPM (nghiệm thu PM)

Bước 6: Kiểm thử nghiệm thu: được thực hiện sau khi hoàn thành lập trìnhtoàn bộ PM

Squad Team phối hợp chặt chẽ trong quá trình lập trình, thực hiện kiểm thửnghiệm thu “cuốn chiếu” ngay từng chức năng/nhóm chức năng

Kiểm thử nghiệm thu, triển khai ở mỗi phân đoạn: Trên cơ sở Biên bảnKTNT (do Squad Team thực hiện), Squad Team phối hợp TTCNTT tổ chức triểnkhai PM (có phê duyệt của lãnh đạo phụ trách Squad Team và Lãnh đạo Trung tâmCNTT) và gửi thông báo triển khai cho Ban CN để thực hiện cấp mã PM và cậpnhật Danh mục phần mềm của BIDV

Khi Squad Team hoàn thành KTNT và được TTCNTT đánh giá đạt yêu cầukiểm thử chấp nhận triển khai tổng thể, toàn bộ PM (hoàn thành phân đoạn cuốicùng): Squad Team gửi đầy đủ HSPM (bao gồm cả Biên bản kiểm thử chấp nhậntriển khai của TTCNTT) cho Ban CN thực hiện Báo cáo đánh giá quá trình PTPM

đủ tiêu chuẩn được nghiệm thu, triển khai chính thức

Bước 7: Báo cáo đánh giá quá trình PTPM

Được thực hiện sau khi hoàn thành KTNT toàn bộ phần mềm Tiêu chuẩnnghiệm thu PM phải có đầy đủ các tài liệu được cấp có thẩm quyền phê duyệt, cụthể:

Lãnh đạo phụ trách nghiệp vụ ký duyệt tài liệu mô tả sản phẩm ProductBacklog, tài liệu hướng dẫn sử dụng, biên bản kiểm thử nghiệm thu nghiệp vụ

Lãnh đạo phụ trách kỹ thuật ký duyệt tài liệu PTTK, tài liệu hướng dẫn càiđặt, biên bản KTNT kỹ thuật

2.2.3 Quy trình phát triển phần mềm theo hình thức khẩn gấp

Được thực hiện theo nguyên tắc thực hiện song song một số bước, đồng thời

rút gọn một số bước PTPM, với trình tự thực hiện như sau:

Bước 1: Đơn vị nghiệp vụ đầu mối gửi Tờ trình được Phó Tổng giám đốc phụtrách phê duyệt hoặc văn bản chỉ đạo của Ban Lãnh đạo về chủ trương PTPM (kèm theotài liệu mô tả yêu cầu nghiệp vụ tới Ban Công nghệ đầu mối phối hợp Trung tâm CNTT

và các đơn vị liên quan đánh giá, sắp xếp kế hoạch thực hiện

Bước 2: Sau khi nhận được thông báo của Ban Công nghệ và các văn bản, tờtrình, tài liệu yêu cầu nghiệp vụ do Đơn vị nghiệp vụ đầu mối cung cấp, Trung tâmCNTT tiến hành ngay việc khảo sát, phân tích, thiết kế và lập trình Tài liệu RSDđược xây dựng song song trong quá trình xây dựng phần mềm và là căn cứ để thựchiện kiểm tra, nghiệm thu phần mềm Đơn vị nghiệp vụ đầu mối tham gia kiểm thửngay trong quá trình xây dựng phần mềm

Bước 3: Trung tâm CNTT phối hợp với Đơn vị nghiệp vụ tổ chức kiểm tranghiệm thu phần mềm đáp ứng các yêu cầu theo RSD Căn cứ biên bản kiểm tra,nghiệm thu, Đơn vị nghiệp vụ gửi văn bản thông báo kế hoạch triển khai tới BanCông nghệ, Trung tâm CNTT (đồng thời gửi báo cáo Ban lãnh đạo) và phối hợp vớiTrung tâm CNTT tổ chức triển khai phần mềm

Bước 4: Sau khi hoàn thành việc triển khai phần mềm, Trung tâm CNTT đầumối gửi toàn bộ hồ sơ PTPM (RSD, tài liệu PTPK/tài liệu kỹ thuật, biên bản KTNT

kỹ thuật/nghiệp vụ, công văn/tờ trình triển khai phần mềm nếu có) tới Ban Côngnghệ để thẩm định, ghi nhận ngày công thực hiện và cập nhật thông tin quản lý,giám sát tại Ban Công nghệ

2.3 Lập kế hoạch phát triển phần mềm

Quy trình phát triển phần mềm tại BIDV được thực hiện dưới hình thức tựphát triển và thuê ngoài, được áp dụng cho toàn hệ thống BIDV bao gồm Trụ sởchính và các Đơn vị trực thuộc

2.3.1 Các mức ưu tiên trong kế hoạch phát triển phần mềm

Việc xây dựng kế hoạch PTPM định kỳ (vào quý IV hàng năm) phải gắn liền

và ưu tiên với chiến lược phát triển CNTT theo từng giai đoạn và chiến lược kinhdoanh của BIDV

Việc lập kế hoạch xây dựng một phần mềm được đánh giá sắp xếp theo thứ

tự các mức ưu tiên như sau (từ 1 đến 4, mức 1 là ưu tiên cao nhất, mức 4 là ưu tiênthấp nhất), cụ thể:

 Mức 1: Là các yêu cầu xây dựng phần mềm để đáp ứng yêu cầu của các

cơ quan quản lý của nhà nước có hiệu lực thực hiện không thể lùi hoãnhoặc phần mềm phục vụ khách hàng lớn, quan trọng/kinh doanh trực tiếpnhằm dành cơ hội cạnh tranh cấp bách cho BIDV trên thị trường (mà nếuthiếu phần mềm sẽ không thể triển khai được sản phẩm dịch vụ)

 Mức 2: Là các yêu cầu xây dựng phần mềm phục vụ công tác quản trị điềuhành của Ban lãnh đạo theo chỉ đạo trực tiếp của Ban lãnh đạo

 Mức 3: Phần mềm phục vụ hoạt động kinh doanh trực tiếp có kế hoạch dàihạn/chưa cấp bách hoặc phần mềm phục vụ công quản lý, quản trị điềuhành của toàn hệ thống BIDV

 Mức 4: Các yêu cầu xây dựng phần mềm phục vụ công tác quản lý nội bộcủa các Ban

2.3.2 Bổ sung và điều chỉnh kế hoạch PTPM

- Kế hoạch phát triển phần mềm được đăng ký mới, cập nhật điều chỉnh tốithiểu 2 lần/năm Tổng Giám đốc hoặc Phó Tổng Giám đốc phụ trách Ban Côngnghệ phê duyệt điều chỉnh kế hoạch PTPM

- Nếu cần điều chỉnh kế hoạch, Đơn vị đề xuất gửi văn bản điều chỉnh kếhoạch về Ban Công nghệ để tổng hợp trình Phó Tổng Giám đốc phụ trách BanCông nghệ phê duyệt, cụ thể:

 Nếu điều chỉnh kế hoạch do các lý do khách quan xuất phát từ yêu cầu các

cơ quan quản lý, do thay đổi yêu cầu từ khách hàng lớn, quan trọng: Gửicông văn kèm theo các văn bản liên quan của cơ quan quản lý, kháchhàng…

 Nếu điều chỉnh kế hoạch thực hiện do các lý do khác: có Tờ trình báo cáogiải trình xin ý kiến phê duyệt của Phó Tổng Giám đốc phụ trách đơn vị

- Đối với phần mềm phát sinh đột xuất, ngoài kế hoạch:

- Đơn vị nghiệp vụ đầu mối gửi Tờ trình được Phó Tổng giám đốc phụ tráchphê duyệt hoặc văn bản chỉ đạo của Ban Lãnh đạo về chủ trương PTPM tới BanCông nghệ (kèm theo tài liệu mô tả yêu cầu nghiệp vụ) Ban Công nghệ phối hợp

Tổ tư vấn nghiệp vụ đánh giá tính khẩn cấp, cần triển khai gấp của yêu cầu PTPM

và thực hiện theo nguyên tắc sau:

 Nếu là phần mềm khẩn cấp, cần triển khai gấp: Ban Công nghệ phối hợpvới Trung tâm CNTT, các Đơn vị liên quan trao đổi, thống nhất vềphương án, kế hoạch thực hiện (đảm bảo tính khả thi và chất lượng phầnmềm, thực hiện thủ tục giãn/hoãn các phần mềm khác_nếu cần) và thôngbáo cho Trung tâm CNTT, Đơn vị nghiệp vụ đầu mối để tổ chức thựchiện Trong vòng 5 ngày làm việc kể từ khi nhận được phê duyệt chủtrương PTPM, Ban Công nghệ có phản hồi về phương án sắp xếp kếhoạch tới Đơn vị nghiệp vụ đầu mối biết để phối hợp thực hiện

 Nếu phần mềm không khẩn cấp, không cần thiết phải triển khai ngay: BanCông nghệ thông báo tới Đơn vị nghiệp vụ đầu mối thực hiện đăng ký bổsung kế hoạch và chỉ xem xét bổ sung vào kế hoạch nếu nguồn lực PTPMtrong năm còn khả năng đáp ứng

 Nguyên tắc xem xét các phần mềm cần giãn hoãn để dành nguồn lực chocác phần mềm phát sinh khẩn gấp:

 Xem xét giãn đối với các phần mềm có mức ưu tiên 4, sau đó xem xétgiãn đối với các phần mềm có mức ưu tiên 3

 Xem xét giãn phần mềm của chính đơn vị có phần mềm cần ưu tiên thựchiện trước, sau đó xem xét đến các phần mềm của đơn vị khác

2.4 Quản lý phát triển phần mềm

2.4.1 Các thành phần tham gia quản lý và phát triển phần mềm

Hình 2.2 Sơ đồ các đơn vị thực hiện trong quá trình PTPM

Ban Công nghệ: Đơn vị đầu mối trình ban hành kế hoạch PTPM hàng năm,theo dõi, giám sát tiến độ PTPM, thực hiện đánh giá quá trình phát triển phần mềm

Ban nghiệp vụ HSC: Đơn vị đầu mối xây dựng tài liệu yêu cầu người sửdụng, kiểm tra nghiệm thu

Ban giám đốc TTCNTT: Chỉ đạo thực hiện, phê duyệt văn bản liên quan đếncông tác PTPM tại TTCNTT

Phòng PTHT: đầu mối thực hiện việc theo dõi kế hoạch PTPM và cập nhậtthông tin kế hoạch phần mềm lên hệ thống HPSM

Các phòng PTPM: đầu mối thực hiện công tác phát triển phần mềm, banhành các tài liệu trong giai đoạn xây dựng phần mềm

Phòng QTUD: đầu mối thực hiện công tác hỗ trợ kiểm tra nghiệm thu, triểnkhai, ban hành các tài liệu trong giai đoạn kiểm tra nghiệm thu phần mềm, tài liệu quảntrị

Phòng VHHT: đầu mối thực hiện công tác vận hành, hỗ trợ người sử dụng trongquá trình tồn tại của phần mềm, ban hành các tài liệu liên quan đến công tác hỗ trợ

2.4.2 Luồng quy trình phát triển phần mềm hiện tại