Tổng quan về các phương pháp estimation dự án phần mềm

-A A +A

Project 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.

Xác định scope

Như các bạn đã biết một hệ thống thông tin bao gồm các yếu tố chính như phần cứng, phần mềm, middleware, con người ... Trong đó một hệ thống lớn, phức tạp sẽ có rất nhiều vendor khác nhau. Công ty bạn được khách hàng yêu cầu estimate cho phần công việc nào thì hãy estimate chính xác cho phần đó để tránh việc chồng lấn hoặc thiếu sót có thể xảy ra. Thậm chí trong một project với nhiều công đoạn, khách hành chỉ yêu cầu estimate riêng cho phần design, riêng cho codding hay test thì bạn cũng phải hết sức chú ý. Khi nhận estimate hãy confirm lại với đội Sale hay Manager của bạn nếu có điểm chưa rõ ràng về Scope. Và hãy chắc chắn scope estimate được ghi lại đầy đủ trong tài liệu estimation.

Xác định các nội dung ngoài scope

Các bạn có thể thấy hơi lạ hoặc không cần thiết nhưng những chi tiết, chức năng ngoài scope phát triển cũng nên được mô tả rõ trong tài liệu. Ý tưởng của khách hàng thường khá chung chung, hình dung ban đầu của bạn cũng có thể mơ hồ nên những phần còn chưa rõ ràng hãy cho vào assumption và nhờ khách hàng xác nhận lại. Nếu tự hiểu ngầm theo ý của bạn mà không confirm sớm thì rất có thể sẽ phát sinh nhiều vấn đề ảnh hưởng đến bản estimation của bạn. Nếu hệ thống phức tạp và trình bày câu chữ có thể mất thời gian và khó hiểu hãy trình bày bằng diagram hay bảng biểu nào đó để hình dễ dàng hơn.

4. Development process

Những Software development process hiện tại cũng khá nhiều và đa dạng, từ Waterfall, Iterative tới Agile/Scrum. Việc áp dụng mô hình nào trong quản trị dự án cũng có thể quyết định sớm từ khi bắt đầu estimate.

Project duration

Khi đưa ra yêu cầu estimate thông thường khách hàng cũng sẽ cho biết thời gian mong muốn nhận được sản phẩm. Tùy vào mục đích kinh doạnh của khách hàng mà duration của dự án có thể dài, ngắn khác nhau. Dựa vào thông tin đó bạn có thể estimate thời gian bắt đầu, thời gian kết thúc, phân bổ hợp lý và có plan để sắp xếp resource. Ngoài ra một số mốc thời gian như deliver sản phẩm cho khách hàng nếu được thì cũng có thể mô tả trong tài liệu estimation.

Lưu ý quan trọng: Duration càng ngắn thì chi phí dự án càng lớn. Lý do: Bạn phải huy động nhiều nhân sự hơn, các công việc được kéo về gần thời điểm xuất phát và tiến hành song song thay vì triển khai trên đường cơ sở (critical path).

Requirement & Constraint

Trong giai đoạn estimate thì yêu cầu thường chưa rõ ràng do đó cần liệt kê chi tiết các chức năng tới mức có thể để làm tiền đề cho việc estimate. Ngoài ra, trường hợp có nhiều bên cùng tham gia phát triển một dự án là việc khá phổ biến. Nếu phần việc của công ty bạn bị phụ thuộc bởi công ty khác như về thiết bị, features, API, tài liệu thiết kế .. thì cũng hãy define rõ ràng những constraint về mặt thời gian với các bên liên quan (nên đưa vào phần Assumption trong tài liệu estimation). Bạn cũng lên có plan để đối ứng cho các constraint này trong trường hợp rủi ro có thể xảy ra.

Các phương pháp estimation

  • 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 của chuyên gia.
    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.
      Thí dụ các phần mềm kế toán, CRM... gần như giống nhau về nghiệp vụ, ít có sự sáng tạo mới. Tương tự như các căn hộ của chung cư được xây dựng cùng một khuôn mẫu giống nhau để bán. Đặc điểm của các dự án này là giá thành thấp và sản phẩm dễ bán.
    • 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 (các tính năng đặc thù). Yêu cầu cũng ít cứng nhắc hơn.

      Semi-detached tương tự như các khu nhà biệt thự song lập, có thiết kế giống nhau và những điểm chung. Tuy nhiên mỗi căn nhà đều có những đặc trưng riêng (thí dụ nội thất).
    • 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.

      Các dự án phần mềm thuộc dạng này cũng tương tự như biệt thự đơn lập có thiết kế riêng, đặc trưng. Đặc điểm của các dự án dạng này là giá thành rất cao.
       

  • Tiếp sau 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.


Bảng công thức tính điểm độ phức tạp kỹ thuật. Mỗi công ty phần mềm sẽ có bảng chuẩn của riêng mình.

  • 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)
* Embedded 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à không 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 effort.
  • 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 một user 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ẽ hỏi ý kiến 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 sang tiếng Việt 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 đó chuyển cho ít nhất 3 developer có kinh nghiệm khác nhau để estimate, một developer có trình độ chuyên gia (expert), một developer có tư duy làm dự án nổi trội hơn tư duy kỹ thuật, một developer có nhiều kinh nghiệm "xương máu" với "fix bugs", bảo trì và hỗ trợ kỹ thuật. 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à tương đối, cũng giống như khi bạn được lãnh đạo giao nhiệm vụ định giá một khu đất, bạn loay hoay cách định giá theo giá Nhà nước hay giá thị trường.
  • Ngoài các điểm chú ý đã liệt kê ở trên thực tế còn rất nhiều điểm cần lưu ý khi thực hiện estimate. Cũng có thể một số mục ở trên bạn thấy chưa cần thiết khi làm estimate. Bạn có thể tùy nghi thay đổi thêm bớt cho phù hợp với thực tế của công ty bạn.

Hi vọng bài viết có ích cho bạn! Chúc các bạn thành công.

Tổng hợp từ viblo

Category
Tư vấn CNTT