Mở đầu:

Ngoài yêu tố về kỹ thuật - công nghệ như đã phân tích ở bài viết trước, một yếu tố tác động đến hiệu suất xây dựng, phát triển, nâng cấp, chỉnh sửa phần mềm đó là yếu tổ tác động môi trường và nhóm làm việc. Đây là các yêu cầu đối với nhóm lập trình phần mềm, đóng góp chính cho sự thành công của một dự án là khả năng, trình độ của nhóm đó. Khi xây dựng, phát triển, nâng cấp, chỉnh sửa phần mềm sử dụng chuyên gia và nhóm lập trình có trình độ càng cao, thì hiệu suất lao động càng lớn, khi sử dụng chuyên gia và nhóm lập trình có trình độ càng thấp thì hiệu suất lao động càng thấp.

Trong phương pháp xác định chi phí phần mềm nội bộ theo hướng dẫn của Bộ Thông tin và Truyền thông tại Quyết định số 671/QĐ-BTTTT ngày 26/4/2024 có 8 yếu tố kỹ thuật - công nghệ.

Hình [1]: Minh họa Hệ số tác động môi trường và nhóm làm việc

Dưới đây là 08 hệ số tác động môi trường và nhóm làm việc (EFW) được xác định giá trị xếp hạng trong nội dung mô hồ sơ phục vụ xác định chi phí phần mềm nội bộ (Yêu cầu về môi trường cho phát triển, nâng cấp, mở rộng phần mềm). Giá trị xếp hạng được xác định trong khoảng từ 0 đến 5 (chấp nhận giá trị lẻ 01 chữ số thập phân sau dấu phẩy).

Mỗi hệ số tác động môi trường và nhóm làm việc được liệt kê dưới dạng Tên - Mô tả cụ thể như sau:

EFW1 - Có áp dụng quy trình phát triển phần mềm

Hệ số “Có áp dụng quy trình phát triển phần mềm” đánh giá trải nghiệm của nhóm lập trình với quy trình phát triển mà đề xuất. Hệ số này đã được điều chỉnh để phản ánh thực tế rằng các quy trình và ngôn ngữ mô hình hóa khác có thể được sử dụng thay thế.

0. Nhóm không có kinh nghiệm với quy trình phát triển hoặc không sử dụng bất kỳ quy trình nào.

1. Nhóm có kiến thức lý thuyết về quá trình phát triển, nhưng không có kinh nghiệm.

2. Một vài thành viên của nhóm đã sử dụng quy trình trong một dự án.

3. Một vài thành viên của nhóm đã sử dụng quy trình trong nhiều dự án.

4. Có tới một nửa nhóm đã sử dụng quy trình trong nhiều dự án.

5. Hơn một nửa nhóm đã sử dụng quy trình trong nhiều dự án.

Các quy trình phát triển phần mềm bao gồm:

- Quy trình phát triển phần mềm theo mẫu RUP (Rational Unified Process - Tiến trình hợp nhất được phát triển bởi hãng IBM);

- Quy trình phát triển phần mềm theo Mô hình thác nước (Waterfall model);

- Quy trình phát triển phần mềm Mô hình xoắn ốc (Spiral model);

- Quy trình phát triển phần mềm Mô hình agile;

- Quy trình phát triển phần mềm Mô hình tiếp cận lặp (Iterative model);

- Mô hình tăng trưởng (Incremental model);

- Quy trình phát triển phần mềm Mô hình chữ V (V model);

- Quy trình phát triển phần mềm Mô hình Scrum;

- Mô hình RAD (Rapid Application Development);

- Quy trình quản lý chất lượng (ISO) áp dụng trong lĩnh vực phát triển phần mềm.

Giá trị xếp hạng EFW1 càng cao tương ứng với yêu cầu kinh nghiệm càng cao.

EFW2 - Kinh nghiệm phát triển ứng dụng tương tự              

Hệ số “Kinh nghiệm phát triển ứng dụng tương tự” đánh giá sự quen thuộc của nhóm với khu vực ứng dụng hoặc miền. Ví dụ: nếu ứng dụng là về thương mại điện tử, nhóm đã làm việc với các hệ thống trong cùng khu vực chưa?

0. Không có thành viên trong nhóm có bất kỳ kinh nghiệm trong các dự án trong cùng khu vực.

1. Một số thành viên trong nhóm có 6 đến 12 tháng kinh nghiệm trong các dự án trong cùng khu vực.

2. Một số thành viên trong nhóm có 12 đến 18 tháng kinh nghiệm trong các dự án trong cùng khu vực.

3. Hầu hết các thành viên trong nhóm có từ 18 đến 24 tháng kinh nghiệm trong các dự án trong cùng khu vực.

4. Hầu hết các thành viên trong nhóm có hơn hai năm kinh nghiệm trong cùng một khu vực.

5. Tất cả các thành viên trong nhóm có hơn hai năm kinh nghiệm trong cùng một khu vực.

Giá trị xếp hạng EFW2 càng cao tương ứng với yêu cầu kinh nghiệm càng cao. Điều này sẽ chỉ có liên quan khi thực hiện thay đổi đối với một ứng dụng hiện có. Giá trị xếp hạng cao hơn thể hiện nhiều kinh nghiệm hơn. Đối với một ứng dụng mới, trải nghiệm của mọi người sẽ là 0.

EFW3 - Kinh nghiệm về hướng đối tượng                    

Không được nhầm lẫn yếu tố này với sự quen thuộc với quy trình phát triển (EFW1) hoặc kinh nghiệm trong ứng dụng (EFW2): Hệ sốn “Kinh nghiệm về hướng đối tượng” là về kinh nghiệm của nhóm trong việc thực hiện phân tích, mô hình hóa, thiết kế và lập trình hướng đối tượng, độc lập với khu vực ứng dụng và quá trình phát triển được sử dụng.

0. Nhóm không có kinh nghiệm về kỹ thuật hướng đối tượng.

1. Tất cả các thành viên trong nhóm có một số kinh nghiệm về các kỹ thuật hướng đối tượng (tối đa một năm).

2. Hầu hết các thành viên trong nhóm có 12 đến 18 tháng kinh nghiệm trong các kỹ thuật hướng đối tượng.

3. Tất cả các thành viên trong nhóm có 12 đến 18 tháng kinh nghiệm hoặc hầu hết các thành viên trong nhóm có từ 18 đến 24 tháng kinh nghiệm về các kỹ thuật hướng đối tượng.

4. Hầu hết các thành viên trong nhóm có hơn hai năm kinh nghiệm trong các kỹ thuật hướng đối tượng.

5. Tất cả các thành viên trong nhóm có hơn hai năm kinh nghiệm trong các kỹ thuật hướng đối tượng.

Giá trị xếp hạng EFW3 càng cao tương ứng với yêu cầu kinh nghiệm về hướng đối tượng càng cao. Một dự án do người dùng định hướng hoặc sử dụng theo từng trường hợp sẽ có cấu trúc hướng đối tượng có trong quá trình triển khai.

EFW4 - Kinh nghiệm của trưởng nhóm lập trình                  

Hệ số “Kinh nghiệm của trưởng nhóm lập trình” đo lường kinh nghiệm của trưởng nhóm lập trình đối với phân tích yêu cầu và mô hình hướng đối tượng (UML).

0. Trưởng nhóm lập trình không có kinh nghiệm.

1. Trưởng nhóm lập trình có kinh nghiệm trước đây trong một dự án tương tự.

2. Trưởng nhóm lập trình có khoảng một năm kinh nghiệm trong nhiều dự án tương tự.

3. Trưởng nhóm lập trình có khoảng hai năm kinh nghiệm trong các dự án tương tự.

4. Trưởng nhóm lập trình có hơn hai năm kinh nghiệm trong các dự án tương tự.

5. Trưởng nhóm lập trình có hơn ba năm kinh nghiệm trong một loạt các dự án.

Giá trị xếp hạng EFW4 càng cao tương ứng với yêu cầu kinh nghiệm của trưởng nhóm lập trình càng cao. Hệ số này thể hiện yêu cầu kiến thức và có khả năng là người chịu trách nhiệm về các yêu cầu của dự án,

EFW5 - Tính chủ động

Làm thế nào để nhóm dự án có tính chủ động?       

0. Nhóm lập trình không chủ động gì cả. Nếu không có sự giám sát liên tục, nhóm sẽ trở nên không hiệu quả. Nhóm chỉ làm những gì được yêu cầu nghiêm ngặt.

1. Nhóm lập trình rất ít chủ động . Giám sát liên tục là cần thiết để giữ năng suất ở mức chấp nhận được.

2. Nhóm lập trình ít chủ động. Thỉnh thoảng cần có sự can thiệp của quản lý để duy trì năng suất.

3. Nhóm lập trình một số chủ động. Thông thường nhóm có sáng kiến, nhưng sự can thiệp của quản lý vẫn cần thiết một cách rời rạc để giữ năng suất.

4. Nhóm lập trình có chủ động tốt. Nhóm thường tự quản lý, nhưng sự tồn tại của giám sát vẫn là cần thiết vì năng suất có thể bị mất nếu không có nó.

5. Nhóm lập trình có chủ động cao. Ngay cả khi không có sự giám sát, mọi người đều biết phải làm gì và tốc độ được duy trì vô thời hạn..

Giá trị xếp hạng EFW5 càng cao tương ứng với yêu cầu về tính chủ động trong công việc càng cao.

EFW6 - Độ ổn định của các yêu cầu                    

Hệ số “Độ ổn định của các yêu cầu” đánh giá nếu nhóm có thể giữ các yêu cầu ổn định trong các dự án trước đây, giảm thiểu thay đổi của họ trong dự án. Hệ số này có thể thay đổi từ dự án này sang dự án khác, bởi vì có những lĩnh vực mà các yêu cầu thay đổi thường độc lập với năng lực của các chuyên gia phân tích. Hệ số này phải đánh giá chỉ những thay đổi phần mềm do nhóm không có khả năng phát hiện ra các yêu cầu phù hợp.

0. Không có dữ liệu lịch sử về sự ổn định yêu cầu hoặc, trong quá khứ, phân tích kém gây ra những thay đổi lớn trong yêu cầu sau khi dự án bắt đầu.

1. Yêu cầu chủ yếu là không ổn định trong quá khứ. Khách hàng yêu cầu nhiều thay đổi gây ra chủ yếu do yêu cầu không đầy đủ hoặc không chính xác.

2. Yêu cầu không ổn định trong quá khứ. Khách hàng yêu cầu một số thay đổi gây ra bởi các yêu cầu không đầy đủ hoặc không chính xác.

3. Yêu cầu tương đối ổn định trong quá khứ. Khách hàng yêu cầu thay đổi chức năng thứ cấp với một số thường xuyên. Thay đổi chức năng chính đã được yêu cầu hiếm khi.

4. Yêu cầu chủ yếu là ổn định trong quá khứ. Người dùng yêu cầu thay đổi nhỏ, đặc biệt là mỹ phẩm. Những thay đổi trong chức năng chính hoặc phụ là bất thường.

5. Yêu cầu hoàn toàn ổn định trong quá khứ. Những thay đổi nhỏ, nếu có, không có tác động đến các dự án.

Thay đổi về yêu cầu có thể làm tăng công việc. Cách để tránh điều này là bằng cách lập kế hoạch thay đổi và thiết lập một hệ thống thời gian để quản lý những thay đổi đó. Khi các nhóm không làm điều này, sẽ có nguy cơ làm lại dự án hoặc mất nhiều thời gian, nguồn lực để sửa chữa.

Giá trị xếp hạng EFW6 càng cao tương ứng với yêu cầu về độ ổn định của các yêu cầu hệ thống càng cao. Các con số cao hơn thể hiện nhiều thay đổi hơn (hoặc một hệ thống kém hiệu quả để quản lý thay đổi).

EFW7 - Sử dụng các nhân viên làm bán thời gian                 

Hệ số “Sử dụng các nhân viên làm bán thời gian” là một yếu tố tiêu cực, nghĩa là trái với sáu yếu tố môi trường đầu tiên, các giá trị cao hơn ở đây đại diện cho thời gian phát triển nhiều hơn chứ không phải ít hơn. Một nhóm có nhiều thành viên tham gia vào các dự án hoặc hoạt động khác kém năng suất hơn một nhóm chuyên dụng.

0. Không có thành viên trong nhóm là bán thời gian cho dự án.

1. Có tới 10% nhóm là bán thời gian.

2. Tối đa 20% nhóm là bán thời gian.

3. Có tới 40% nhóm là bán thời gian.

4. Có tới 60% nhóm là bán thời gian.

5. Hơn 60% nhóm là bán thời gian.

Giá trị xếp hạng EFW7 càng cao tương ứng với việc cho phép càng nhiều nhân viên làm việc bán thời gian hoặc kiêm nhiệm. Giá trị xếp hạng cao hơn phản ánh các thành viên trong nhóm là bán thời gian, tư vấn bên ngoài và đơn vị phát triển đang chia thời gian của họ cho các dự án. Chuyển đổi bối cảnh và các yếu tố vô hình khác khiến các thành viên trong nhóm kém hiệu quả hơn.

EFW8 - Kinh nghiệm sử dụng ngôn ngữ lập trình                 

Hệ số “Kinh nghiệm sử dụng ngôn ngữ lập trình” cũng là một yếu tố tiêu cực khác, có nghĩa là giá trị cao ở đây có hại cho thời gian phát triển.

0. Tất cả các thành viên trong nhóm là những lập trình viên rất có kinh nghiệm.

1. Hầu hết các thành viên trong nhóm có ít nhất hai năm kinh nghiệm lập trình.

2. Tất cả các thành viên trong nhóm có ít nhất 18 tháng kinh nghiệm lập trình.

3. Hầu hết các thành viên trong nhóm có ít nhất 18 tháng kinh nghiệm lập trình.

4. Một vài thành viên trong nhóm có một số kinh nghiệm về lập trình (không quá một năm).

5. Tất cả các thành viên trong nhóm là những lập trình viên thiếu kinh nghiệm.

Giá trị xếp hạng EFW8 càng cao tương ứng với yêu cầu về kinh nghiệm trong việc sử dụng ngôn ngữ lập trình càng cao.

Kết luận:

Qua phân tích nêu trên, có thể thấy môi trường và nhóm làm việc trong một dự án xây dựng, phát triển, nâng cấp, chỉnh sửa phần mềm nội bộ có ảnh hưởng trực tiếp đối với kết quả của dự án. Do đó, cần có yêu cầu cụ thể để bảo đảm dự án được triển khai thành công./.

Đỗ Thị Thảo Hiền

Tài liệu tham khảo:

- Quyết định số 671/QĐ-BTTTT ngày 26/4/2024 của Bộ trưởng Bộ Thông tin và Truyền thông hướng dẫn xác định chi phí phần mềm nội bộ

- Object-Oriented Analysis and Design for Information Systems, Raul Sidnei Wazlawick, http://dahlan.unimal.ac.id/files/ebooks2/2014%20Object-Oriented%20Analysis%20and%20Design%20for%20Information%20Systems.pdf, https://booksite.elsevier.com/9780124186736/content/Chapter_e4.pdf

- http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/