Cần hướng dẫn cụ thể xác định chi phí phần mềm nội bộ

Ngoài ra, chi phí phần mềm nội bộ còn có thể được xác định bằng các phương pháp khác như: phương pháp so sánh; phương pháp chuyên gia; phương pháp kết hợp sử dụng số liệu theo công bố của các cơ quan khác có chức năng… Mặc dù đã có văn bản hướng dẫn cách xác định chi phí phần mềm nội bộ nhưng trong thực tế triển khai còn nhiều vướng mắc, có nhiều nội dung không còn phù hợp với tình hình phát triển nhanh của viễn thông và công nghệ thông tin như hiện nay.

Khó khăn trong xác định chi phí phần mềm nội bộ

Theo Bộ Tài chính, việc xác định chi phí phần mềm nội bộ đối với phần mềm lõi, trí tuệ nhân tạo, giải pháp tự động, mobile app... đang gặp một số khó khăn cần Bộ Thông tin và Truyền thông (Bộ TTTT) hướng dẫn cách xác định chi phí như: Hiện nay, một số dự án xây dựng phần mềm nội bộ dựa trên phần mềm lõi được mua của các hãng nước ngoài nhưng chưa xác định mua từ hãng nào. Bên cạnh đó, các ứng dụng trí tuệ nhân tạo đang dần được áp dụng, các dịch vụ (service) phục vụ kết nối, chia sẻ dữ liệu chạy ngầm (nhưng không tính được chi phí xây dựng phần mềm nội bộ).

Việc xây dựng form nhập động (thay cho việc xây dựng từng form nhập cụ thể), báo cáo động (thay cho việc xây dựng từng báo cáo cụ thể), dịch vụ kết nối, chia sẻ dữ liệu tự động (thay cho từng dịch vụ cụ thể) xây dựng rất phức tạp; do đó có hướng dẫn bảo đảm công bằng về chi phí giữa giải pháp tự động với giải pháp cụ thể như trước đây.

Hiện nay, các ứng dụng mobile app thông thường được phát triển đồng thời cùng với việc phát triển các ứng dụng nội bộ của các cơ quan nhà nước. Bên cạnh đó, việc xây dựng các ứng dụng mobile app đòi hỏi nhân sự có trình độ kỹ thuật công nghệ thông tin thông thường cao hơn so với mặt bằng chung yêu cầu nhân sự công nghệ thông tin trong các chuyên ngành hẹp khác… cần có hướng dẫn xác định chi phí phát triển phần mềm trên mobile app.

Để đáp ứng yêu cầu kiến trúc Chính phủ điện tử và yêu cầu cải cách quy trình nghiệp vụ, một số bài toán sẽ tính toán để ghép lại thành các bài toán tổng thể. Bộ TTTT cần có hướng dẫn cụ thể trong việc mô tả trường hợp sử dụng ghép các chức năng của các bài toán khác nhau về cùng một nền tảng công nghệ và cùng chức năng quản lý.

Ý kiến góp ýđối với dự thảo

Mới đây, Bộ TTTT đã dự thảo quyết định hướng dẫn xác định chi phí phần mềm nội bộ gồm 2 phần và 7 phụ lục, cụ thể: 

Phần I. Quy định chung gồm 3 mục quy định các nội dung: Phạm vi điều chỉnh, đối tượng áp dụng, giải thích từ ngữ. 

Phần II. Quy định cụ thể gồm 4 mục quy định các nội dung: Yêu cầu đối với việc xác định chi phí phần mềm nội bộ, nội dung hồ sơ phục vụ xác định chi phí phần mềm nội bộ, trình tự xác định chi phí phần mềm nội bộ, phương pháp xác định chi phí phần mềm nội bộ. Phụ lục I: Bảng danh sách các tác nhân tham gia vào hệ thống (actor). Phụ lục II: Bảng chuyển đổi yêu cầu chức năng sang trường hợp sử dụng (use case). Phụ lục III: Bảng tính toán điểm các tác nhân (actors) tương tác, trao đổi thông tin với phần mềm. Phụ lục IV: Bảng tính toán điểm các trường hợp sử dụng (use case). Phụ lục V: Bảng tính toán hệ số phức tạp kỹ thuật – công nghệ. Phụ lục VI: Bảng tính toán hệ số tác động môi trường và nhóm làm việc, hệ số phức tạp về môi trường, xác định độ ổn định kinh nghiệm và nội suy thời gian lao động. Phụ lục VII: Bảng tính toán chi phí trực tiếp xây dựng, phát triển, mở rộng phần mềm nội bộ.

Góp ý với dự thảo quyết định của Bộ TTTT, Bộ Tài chính cho rằng: Đối với khái niệm trường hợp sử dụng (use case): Theo định nghĩa "Trường hợp sử dụng (Use case) là một tập hợp các giao dịch giữa phần mềm với các tác nhân bên ngoài hệ thống nhằm đạt được một mục tiêu sử dụng nào đó của tác nhân. Một trường hợp sử dụng mô tả một hoặc nhiều giao dịch xảy ra khi tác nhân tương tác với hệ thống phần mềm", nhưng một use case mô tả một tình huống và một use case mô tả nhiều tình huống có chi phí khác nhau. Do đó, Bộ TTTT cần hướng dẫn cụ thể trường hợp nào dùng "một use case mô tả một tình huống" và "một use case mô tả nhiều tình huống".

Đối với phần giải thích từ ngữ về use case, transaction, không có ví dụ minh họa cụ thể, nên mỗi dự án sẽ viết use case, transaction khác nhau, không theo một mẫu giống nhau. Ví dụ áp dụng khái niệm giao dịch trong phép tính "1+2 =3" sẽ có nhiều cách hiểu:

Cách hiểu 1: phép tính có 4 transaction gồm: tác nhân nhập số 1, hệ thống ứng dụng kiểm tra là số học và hiện lên số 1; tác nhân nhập dấu cộng, hệ thống ứng dụng kiểm tra ghi nhận phép toán và hiện lên dấu cộng; tác nhân nhập số 2, hệ thống ứng dụng kiểm tra là số học và hiện lên số 2; tác nhân chọn dấu =, hệ thống tính toán và hiện lên kết quả.

Cách hiểu 2: phép tính có 2 transaction: tác nhân nhập tham số của phép tính, hệ thống ứng dụng ghi nhận và hiện lên màn hình các tham số; tác nhân chọn summit (dấu =) hệ thống ứng dụng tính toán và hiện kết quả.

Cách hiểu 3: phép tính có 1 transaction là tác nhân nhập phép tính và ấn summit, hệ thống tính toán và trả ra kết quả.

Do đó, trong dự thảo, Bộ TTTT nên có ví dụ minh họa cụ thể cho use case và transaction, hướng dẫn rõ "chuỗi hành động" ở giao dịch được hiểu mức độ như thế nào. Đồng thời, bổ sung hướng dẫn xác định Actor trong trường hợp có nhiều hệ thống bên ngoài trao đổi thông tin với phần mềm thông qua nền tảng chia sẻ dữ liệu.

Ngoài ra, Bộ TTTT nên hướng dẫn rõ cách xác định mức lương lao động bình quân H 7 tại mục II – Hướng dẫn cụ thể. Tại mục 3 về trình tự xác định chi phí phần mềm nội bộ: Thống nhất tên các bảng với tên tại các phụ lục phần mềm "…Bảng này phải phù hợp với yêu cầu về môi trường cho xây dựng, phát triển, mở rộng phần mềm trong hồ sơ phục vụ xác định chi phí phần mềm nội bộ" và bổ sung cụm từ cho xây dựng, phát triển, mở rộng phần mềm vào điểm h để thống nhất với điểm g.

Tại phụ lục II định nghĩa "Trường hợp sử dụng (Use case) là một tập hợp các giao dịch giữa phần mềm với các tác nhân bên ngoài hệ thống...", đối với mục này Bộ Tài chính đề nghị Bộ TTTT cân nhắc hướng dẫn phân loại BMT như sau: Trường hợp sử dụng loại B: Mô tả trường hợp sử dụng có transaction đáp ứng yêu cầu nghiệp vụ của phần mềm, không bao gồm các chức năng được phân loại M và T. Trường hợp sử dụng loại M: mô tả trường hợp sử dụng có transaction kết nối, liên thông, chia sẻ dữ liệu với các hệthống hạ tầng kỹ thuật, phần mềm, cơ sở dữ liệu liên quan. Trường hợp sử dụng loại T: Mô tả trường hợp sử dụng có transaction phần mềm ứng dụng công nghệ trí tuệ nhân tạo (AI), chuỗi khối (blockchain), thực tế ảo/thực tế tăng cường (VR/AR) để hỗ trợ ra quyết định và chức năng phần mềm trên các thiết bị di động thông minh, mà phải lập trình riêng cho từ 02 hệ điều hành thiết bị di động trở lên" (ví dụ đáp ứng cho cả iOS và Android).

Trong Phụ lục II cũng như toàn bộ dự thảo văn bản hướng dẫn không hướng dẫn cách chuyển đổi từ yêu cầu chức năng sang trường hợp sử dụng; Bộ TTTT cần bổ sung hướng dẫn nội dung này. Đối với các bảng xác định giá trị xếp hạng cho 13 hệ số phức tạp kỹ thuật – công nghệ, đề nghị có bổ sung ví dụ cụ thể cho từng giá trị xếp hạng. Đối với hệ số "Xử lý phân tán" nên có hướng dẫn cho những hệ thống tập trung lớn phức tạp.

Đối với hệ số "Mức độ quan trọng của hiệu năng": Tuy có hướng dẫn ý nghĩa dựa trên thời gian phản hồi của hệ thống và khả năng xử lý đồng thời, nhưng hướng dẫn xác định giá trị chưa cụ thể chỉ ra thời gian phản hồi bao lâu? Khả năng xử lý đồng thời bao nhiêu? Dự thảo chỉ dừng ở việc hướng dẫn có yêu cầu về hiệu năng hay không, có yêu cầu sử dụng công cụ phân tích hiệu năng hay không. Do đó, Bộ Tài chính có ý kiến như sau:

Đối với hệ số "Yêu cầu về hiệu quả sử dụng cho người dùng" (TFW3): Bộ Tài chính đề nghị bổ sung thêm vào tiêu chí "Hỗ trợ và tài liệu trực tuyến": Tiêu chí có hướng dẫn ngắn gọn dạng tooltip trên giao diện nhập liệu, có ban hành quy chế vận hành sử dụng phần mềm trong đó quy định cụ thể cho từng đối tượng.

Đồng thời xem xét giảm bớt số lượng tiêu chí được tính cho tiêu chí hỗ trợ song ngữ thành 2 tiêu chí (dự thảo đang tính là 4 tiêu chí) và đa ngôn ngữ giảm còn 4 tiêu chí (dự thảo đang tính là 6 tiêu chí) vì hiệu quả sử dụng phụ thuộc nhiều vào đặc thù nghiệp vụ/đối tượng sử dụng hệ thống. Xem xét sửa "hỗ trợ đa ngôn ngữ" thành "Hỗ trợ từ 03 ngôn ngữ trở lên".

Đối với Hệ số "Yêu cầu về độ phức tạp của xử lý bên trong" (TFW4): Tại gạch đầu dòng thứ 2 – mục 1, Bộ Tài chính đề nghị sửa "Yêu cầu về xử lý bảo mật riêng" thành "yêu cầu về

xử lý bảo mật an toàn đặc biệt" để phù hợp với tiêu đề. Tại mục 2, đề nghị sửa ví dụ cho "Yêu cầu xử lý logic mở rộng", đây là những ví dụ cho hệ số "Yêu cầu về hiệu quả sử dụng cho người dùng".

Tại ý nghĩa hệ số "Yêu cầu khả năng tái sử dụng mã nguồn" (TFW5): Bộ Tài chính đề nghị định nghĩa rõ quy chuẩn thiết kế và viết mã là quy chuẩn nào.

Đối với hệ số "Yêu cầu về tính dễ cài đặt" (TFW6): Tại bảng hướng dẫn xác định giá trị xếp hạng của hệ số, đề nghị có ghi chú rõ hệ thống bắt buộc đáp ứng đủ các tiêu chí tại từng giá trị xếp hạng. Đề nghị phần ý nghĩa hệ số bổ sung hướng dẫn "dễ cài đặt" đối với từng loại ứng dụng phân tán hay tập trung, và đối với việc phát triển hoặc việc mở rộng ứng dụng.

Đối với ứng dụng tập trung việc cài đặt ứng dụng trên máy chủ thường phức tạp, đòi hỏi người có chuyên môn CNTT thực hiện trên tài liệu hướng dẫn cài đặt; phần máy trạm người sử dụng thông thường không phải cài đặt.

Đối với ứng dụng phân tán, việc cài đặt đối với người sử dụng thông thường khó hơn, cài đặt trên máy chủ có thể có hoặc không.

Đối với hệ số "Dễ vận hành" (TFW7): Đề nghị cân nhắc bổ sung định nghĩa và hướng dẫn cụ thể từng giá trị việc vận hành ứng dụng của người sử dụng thông thường (ví dụ: quy trình người sử dụng nhập chứng từ -> kiểm soát chứng từ -> ký số, ký nhân danh (nếu có) -> kết nối và đẩy chứng từ sang hệ thống khác) và vận hành của người quản trị.

Đối với hệ số "Thiết kế nhằm dễ dàng bảo trì" (TFW9): Yêu cầu thiết kế nhằm dễ dàng bảo trì thể hiện thông qua việc khách hàng có yêu cầu thiết kế ứng dụng phải dễ dàng chỉnh sửa và thay đổi trong tương lai (sửa các lỗi phát sinh, cải thiện hiệu năng của phần mềm, chỉnh sửa đáp ứng các yêu cầu nghiệp vụ mới hoặc thay đổi của người sử dụng hoặc làm cho phần mềm thích ứng trong một môi trường đã bị thay đổi).

Như vậy, việc "dễ dàng chỉnh sửa và thay đổi trong tương lai (sửa các lỗi phát sinh, cải thiện hiệu năng của phần mềm, chỉnh sửa đáp ứng các yêu cầu nghiệp vụ mới hoặc thay đổi của người sử dụng hoặc làm cho phần mềm thích ứng trong một môi trường đã bị thay đổi)" được thực hiện bởi ai, người sử dụng, người quản trị hay nhà thầu tương lai; yêu cầu mức độ chỉnh sửa hệ thống trong tương lai là thế nào (tất cả các chức năng, hay một số chức năng hay chỉnh sửa tham số hệ thống quan trọng?)…

Tại bảng hướng dẫn xác định giá trị xếp hạng của Hệ số "Yêu cầu về xử lý đồng thời/song song", đề nghị thống nhất chung sử dụng cụm từ "đồng thời/song song" hay chỉ "đồng thời" với giá trị xếp hạng 1, 2, 3.

Đối với hệ số "Mức độ hỗ trợ bảo mật" (TFW11): Dự thảo hướng dẫn xác định dựa trên cơ chế mật khẩu như mức độ phức tạp của mật khẩu, yêu cầu thời gian thay đổi mật khẩu định kỳ..., tuy nhiên hiện nay đa số các ứng dụng được phát triển có tính năng tích hợp SSO, tức là mức độ bảo mật của ứng dụng được xác định bởi ứng dụng quản lý mật khẩu đã có sẵn (ví dụ AD). Dự thảo cũng quy định xác định mức độ bảo mật dựa trên cơ chế xác thực đa nhân tố, việc này cơ bản dựa trên chi phí khi triển khai các giải pháp này nhiều hơn ví dụ chi phí cho mua sắm thiết bị sinh trắc học, chi phí dịch vụ tin nhắn viễn thông (SMS)... Bộ TTTT nên xem xét tập trung nhiều hơn vào các tiêu chí liên quan bản thân việc phát triển phần mềm. 

Tại bảng hướng dẫn xác định giá trị xếp hạng của hệ số "Mức độ hỗ trợ đào tạo người sử dụng": Đối với giá trị 2, Bộ TTTT nên giải thích cụ thể và có ví dụ cho ý "Ứng dụng có một số tiện ích để hỗ trợ đào tạo".

Đối với bảng tính toán hệ số tác động môi trường và nhóm làm việc, hệ số phức tạp về môi trường tại phụ lục VI cần có hướng dẫn xác định yêu cầu nhân sự đối với trường hợp xây dựng, phát triển, mở rộng nhiều phần mềm nội bộ trong một đề cương dự toán chi tiết và một gói thầu.

Đối với hệ số "Có áp dụng quy trình phát triển phần mềm" (EFW1): Bộ TTTT nên hướng dẫn rõ cách xác định "thành viên tham gia phát triển có kinh nghiệm tham gia dự án có áp dụng quy trình phát triển phần mềm", ví dụ: các thành viên phải cung cấp hợp đồng đã tham gia dự án có áp dụng quy trình phát triển phần mềm.

Đối với Hệ số "Tính chủ động" (EFW5), Bộ TTTT nên sắp xếp lại bảng giá trị xếp hạng để đảm bảo "yêu cầu về công tác giám sát, quản lý công việc càng cao thì giá trị xếp hạng của hệ số EFW5 càng cao" giống cách đánh giá các hệ số khác.

Đối với hệ số "Độ ổn định của các yêu cầu" (EFW6), sửa câu "Độ ổn định yêu cầu càng cao thì giá trị xếp hạng càng thấp" thành "Độ ổn định yêu cầu càng cao thì giá trị xếp hạng càng cao" vì bảng giá trị xếp hạng đang để mức 5 là mức yêu cầu được nêu ra hoàn toàn ổn định.

Tại bảng hướng dẫn xác định giá trị xếp hạng của hệ số "Kinh nghiệm sử dụng ngôn ngữ lập trình" (EFW8), Bộ Tài chính đề nghị sửa như bảng trên.

Xác định chi phí phần mềm nội bộ là việc xác định khối lượng công việc cụ thể, phương thức tính toán, kiểm tra trên cơ sở nỗ lực giờ công để thực hiện các trường hợp sử dụng (use case) quy định với các chỉ dẫn có liên quan trên nguyên tắc tuân thủ các tiêu chuẩn, quy định về ứng dụng công nghệ thông tin của Việt Nam. Chi phí phát triển, nâng cấp phần mềm nội bộ được xác định là cơ sở cho việc lập và quản lý chi phí ứng dụng công nghệ thông tin trong hoạt động của cơ quan nhà nước. Do đó, việc kịp thời sửa đổi, bổ sung các phương thức và nguyên tắc xác định chi phí phần mềm nội bộ đảm bảo tính khả thi trong thực tế là cần thiết để đảm bảo công tác triển khai hoạt động chuyển đổi số của Việt Nam kịp tiến độ.

Tài liệu tham khảo:

(Nguồn: Công văn số 7422/BTC-THTK ngày 19/6/2020 của Bộ Tài chính về việc tham gia ý kiến Dự thảo Quyết định hướng dẫn xác định chi phí phần mềm nội bộ)

(Bài đăng trên ấn phẩm in Tạp chí TT&TT Số 5+6 tháng 6/2020)

Kim Liên