[Estimation Part_2] Software development estimation methodologies (Các phương pháp estimation dự án phần mềm)

Trong phần trước tôi đã giới thiệu các điểm cần chú ý để có một bản Softare Estimation chính xác. Các bạn có thể tham khảo lại bài viết tại link dưới sau [Estimation Part_1] Key factor for success Estimation in Software Development. Bài viết này tôi sẽ tiếp tục giới thiệu tới các bạn về các phương pháp dùng để estimate một dự án phần mềm.

• Đầu tiên xin nhắc lại qua một chút về khái niệm Estimation là gì? Theo Wiki "Estimation là một quá trình để tìm ra số lượng ước đoán hay con số xấp xỉ, cái mà giá trị của nó hữu ích với một số mục đích nào đó ngay cả trong trường hợp dữ liệu đầu vào không đầy đủ, không đáng tin cậy và không ổn định". Vậy thì Software Development Estimation là quá trình dự báo, xác định số effort cần thiết cho việc phát triển hoặc maintain một sản phẩm phần mềm dựa vào những requirement không đầy đủ và không ổn định.Effort ở đây có thể là thời gian hay chi phí.
• Effort estimates có thể được sử dụng làm input đầu vào cho Project Plan, dự toán ngân sách, phân tích đầu tư, hay trong đấu thầu. Vì vậy sự chính xác của bản estimate thực sự là rất quan trọng.
• Có rất nhiều cách phân loại các phương pháp tiếp cận estimation. Các loại phổ biến nhất như sau:
  1. Expert estimation: Các bước định lượng dựa trên quá trình phán đoán
  2. Formal estimation model: Các bước định lượng dựa trên quá trình tính toán cơ học. Sử dụng công thức có nguồn gốc từ dữ liệu quá khứ.
  3. Combination-based estimation: Các bước định lượng dựa trên sự kết hợp giữa phán đoán và cơ học của các estimate từ các nguồn khác nhau.
• Trong giới hạn của bài viết tôi sẽ giới thiệu mỗi loại một phương pháp estimate ứng với các cách tiếp cận ở trên.

I. COCOMO model (Formal estimation model)

• COCOMO là từ viết tắt của COstructive COst MOdel, đây là phương pháp được sử dụng rộng rãi nhất trong software estimation trên thế giới.

• Mô hình COCOMO dự báo số effort và duration của một Project dựa vào đầu vào liên quan đến kích thước của kết quả hệ thống và một số "cost drives" ảnh hưởng đến Productivity.

• COCOMO được xác định theo ba mô hình khác nhau gồm:

  • Basic model
  • Intermediate model
  • Detailed model

  Ba model trên sắp xếp theo thứ tự độ phức tạp tăng dần. Model càng phức tạp thì càng đưa ra được estimate chính xác do tính toán nhiều yếu tố ảnh hưởng đến Software Project.

• Yếu tố quan trọng nhất góp phần vào thời gian và chi phí của dự án là Development Mode. Development Mode thì bao gồm 3 Mode như bên dưới, tương ứng với 3 chủng loại Project.

  • Organic mode: Dự án được phát triển trong môi trường ổn định, quen thuộc. Sản phẩm tương tự với các sản phẩm được phát triển trước đó. Sản phẩm tương đối nhỏ và đòi hỏi ít sự sáng tạo.
  • Semidetached mode: Đặc điểm của dự án là trung gian giữa Organic mode và Embedded mode, team size trung bình, công việc pha trộn giữa kinh nghiệm và đổi mới. Yêu cầu cũng ít cứng nhắc hơn.
  • Embedded mode: Dự án đặc trưng bởi những rằng buộc cứng nhắc, chặt chẽ và yêu cầu về giao diện. Một dự án thuộc Embedded mode thường đòi hỏi nhiều sáng tạo và đổi mới.

• Tiếp sau tôi sẽ giới thiệu chi tiết cách tính theo Basic model thông qua một ví dụ để các bạn có thể dễ hình dung hơn.

Basic COCOMO

Phương trình của Basic COCOMO thì được tính như bên dưới

• Effort Applied (E) = a(KLOC)^b [ man-months ]
• Development Time (D) = c(Effort Applied)^d [months]
• People required (P) = Effort Applied / Development Time [count]

Hệ số a, b, c, d được đưa ra như table bên dưới

Các hệ số trên là kết quả đúc kết dựa trên số liệu của rất nhiều các dự án develop trong quá khứ. Theo như công thức trên thì ta thấy các con số đều khá đơn giản và rõ ràng. Chỉ có một ẩn số duy nhất cần phải tính toán đó là số KLOC (1K line of code = 1000[LOC]). Vậy chúng ta sẽ cùng tìm hiểu tiếp làm sao để tìm ra số KLOC này.

• Công thức tính số KLOC thì như sau:
  • KLOC = FunctionPoint (FP) * LOC_per_FP / 1000
  • LOC = Language Factor * FP
  • FP = Unadjusted Function Points (UFP) * Technical Complexity Factor (TCF)
  • TCF = 0.65 + 0.01 * DI (Degree of Influence)
  • UFP = Unadjusted Function Point count (UFC) * Weight Factor

Không biết nhìn xong list công thức trên các bạn có cảm giác như thế nào, nhưng tôi đã bắt đầu thấy rối loạn một chút rồi đây. Chúng ta sẽ cùng tìm hiểu tiếp quá trình đưa ra được số KLOC theo thứ tự từ dưới lên trên. Ví dụ chúng ta có một bài toán như sau.

Phần mềm kiểm tra chính tả này sẽ nhận input là document file và personal dictionary. Trình kiểm tra này sẽ list tất cả các từ không có trong từ điển và trong personal dictionary. Người dùng có thể biết được số từ được xử lý và số lỗi ở bất kỳ thời điểm nào của xử lý. Chúng ta sẽ tính số KLOC theo các step dưới đây.

• Step 1: Để tính Function Point đầu tiên ta phải tính số UFC. Số UFC thì được count theo các categories như sau:

  • External input: những item được cung cấp bởi user (giống như file name hay menu selection)
  • External output: những item cung cấp cho user (ví dụ như report hay message)
  • External inquiry: những input đòi hỏi response từ hệ thống
  • External files: machine-readable interfaces sử dụng để truyền thông tin tới hệ thống khác.
  • Internal files: file logic chính trong hệ thống.

  Phân tích ví dụ trên ta sẽ có list như sau:

  • 2 user input: document file, personal dictionary
  • 3 usser output: fault report, word count, misspelled
  • 2 user request: xử lý word, tìm lỗi
  • 1 internal file: dictionary
  • 2 external file: document file, personal dictionary

• Step 2: Nhân UFC đã xác định bên trên với Weight Factor (được đánh trọng số theo độ phức tạp) như bảng bên dưới

Ví dụ: UFP = (4*2) + (5*3) + (4*2) + (10*1) + (7*2) = 55

• Step 3: Tính total TCF (Technical Complexity Factor) bằng cách đánh giá trị từ 0 đến 5 theo tầm quan trọng cho các điểm dưới đây.

• Step 4: Cộng tất cả các trọng số ở step 3 để ra được số DI (Degree of Influece)

  DI = 30

• Step 5: Tính số TCF đựa trên DI đã có ở step 4

  TCF = 0.65 + 0.01 * 30 = 0.95

• Step 6: Tính số FP = UFP*TCF

  FP = 55*0.95 = 52.25

• Step 7: Tính số KLOC = FunctionPoint (FP) * LOC_per_FP / 1000. Trong đó LOC được tính theo bảng dưới đây, dựa vào mỗi ngôn ngữ khác nhau thì số LOC trên mỗi FP cũng khác nhau.

Giả sử phần mềm sẽ sử dụng ngôn ngữ Java, và LOC trên FP của Java là 53.
* KLOC = 52.25 * 53 /1000 = 2.76 (KLOC)

Vậy ứng với mỗi chủng loại dự án ta sẽ có số effort như sau
* Organic mode: E = 2.4 * (2.76^1.05)
* Semidetached mode: E = 3.0 * (2.76^1.12)
* Embeded mode: E = 3.6 * (2.76^1.2)

Sau khi có số Effort thì việc tính toán Duration và Resource cần cho dự án chỉ là vấn đề công thức. Phương pháp Basic COCOMO về cơ bản là khá tốt cho việc ước lượng nhanh chi phí phát triển phần mềm. Nhưng nó không tính toán sự khác biệt về phần cứng, kinh nghiệm và chất lượng của resource .v.v. Nên nếu muốn chính xác hơn nữa, các bạn có thể áp dụng phương pháp Intermediate COCOMO hay Detailed DOCOMO.

II. Delphi method (Expert estimation)

• Phương pháp Delphi là phương pháp estimation dựa trên sự đồng thuận cho số effort dự kiến. Về cơ bản nó dựa trên khảo sát và sử dụng thông tin của những người tham gia, chủ yếu là những chuyên gia trong lĩnh vực đó. Bằng việc sử dụng phương pháp này bạn sẽ có được cả kết quả định tính và định lượng. Các khảo sát, nghiên cứu của các chuyên gia được thực hiện qua nhiều vòng cho đến khi đạt được sự đồng thuận. Trong mỗi vòng thì các nghiên cứu được thu thập lại và các feedback được đưa ra, và do được làm bởi nhiều người nên phương pháp này hội tụ được nhiều suy nghĩ, đánh giá mà ko bị phụ thuộc ảnh hưởng lẫn nhau.
• Trong quản trị dự án phương pháp Delphi được sử dụng khá rộng rãi, đặc biệt là trong các hoạt động đòi hỏi nhiều ý kiến từ các chuyên gia như quản lý rủi ro, quản lý thời gian và estimate effot.
• Giả sử bạn cần estimate cho một dự án phát triển phần mềm theo mô hình Agile.
  • Trong mô hình Agile thì mỗi hoạt động của Project dựa trên cái gọi là Story được đưa ra bởi khách hàng. Việc estimate chính xác cho các Story rất quan trọng trong việc xác định project critical path (qua critical path bạn có thể thấy thời gian cần thiết để hoàn thành dự án).
  • Việc của người quản trị dự án là break story ra thành các task và giao cho các cá nhân kinh nghiệm trong dự án, hoặc thuê các chuyên gia tư vấn bên ngoài (tuỳ điều kiện thực tế) để estimate cho phần công việc đó.
  • Nếu bản estimate của các bên khá tương đồng thì coi như bản estimate được hoàn thành. Nếu có sự khác nhau thì người quản trị dự án sẽ share ý kiến cho các bên và lấy feedback để các bên điều chỉnh estimate lần hai. Quá trình này sẽ tiếp diễn đến khi có được đự đồng thuận.
  • Và cuối cùng Project manager sẽ review lại bản estimate đó với toàn bộ team estimation.

III. Work Breakdown Structure (Combination-based estimation)

• Work Breakdown Structure (WBS) dịch nôm na là Cấu trúc phân chia công việc, về ý tưởng thì cũng khá đơn giản đó là list ra các công việc cần làm (task) để hoàn thành dự án. List các công việc thì càng chi tiết càng tốt (Module > sub-module > function > sub-function > …), sau đó là dự trù thời gian, chi phí và nhân lực để hoàn thành. Lý thuyết thì đơn giản như vậy, nhưng cái khó nằm ở hai chữ “Đúng” và “Đủ”. Vậy làm sao để list đầy đủ các công việc và estimate đúng effort cần thiết để hoàn thành công việc. Cái này dựa nhiều vào kinh nghiệm và khả năng phân tích hệ thống của người estimate.
• Phương pháp WBS thì có một số lợi ích sau
  • Quá trình tạo ra các function, task chi tiết bởi Project manager và Team sẽ giúp cả team có cái nhìn cụ thể, chi tiết hơn về scope của dự án, có thể phát hiện chỉ ra được một số issue có thể phát sinh. Ngoài ra còn có thể clear được những điểm mập mờ trong requirement. Đồng thời đưa ra những assumption để confirm với khách hàng.
  • Cũng dựa trên việc các task, function được liệt kê chi tiết nên số effort và chi phí dự trù cũng sẽ chính xác hơn do đó quá trình lập kế hoạch dự án về thời gian và kinh phí cũng đáng tin cậy hơn.
  • Việc phân bổ resource cho các task cũng sẽ dễ dàng hơn. Nhìn từ các task nhỏ Project manager có thể chỉ định các cá nhân trong team phù hợp nhất với task đó. Việc quản lý tiến độ cũng trở nên dễ dàng và trực quan hơn.

Kết luận

• Để có thể estimate được chính xác thực sự là một công việc khó. Bạn có thể kết hợp một lúc nhiều phương pháp để có thể estimate được chính xác nhất. Ví dụ tôi thường dùng phương pháp WBS, break công việc thành các task nhỏ. Sau đó ném cho một 3 chú Developer, 1 chú pro code ngon, 1 chú code khá, 1 chú thì là new Dev (phương pháp three point) để estimate. Sau khi có kết quả estimate của từng người sẽ nhân chia hệ số để có thể ra được con số cho task đó. Thông thường hệ số tính như sau (A + 4*B + C)/6, A, B, C thì tương ứng với số estimate theo trình độ của người estimate nêu trên.
• Dù bạn áp dụng phương pháp nào thì cũng chúc bạn may mắn vì estimate cũng chỉ là estimate mà thôi. Hi vọng bài viết có ích cho bạn! Trong phần tới tôi sẽ giới thiệu với các bạn template dùng trong estimate.