Tài liệu Xây dựng công cụ ước lượng chi phí phát triển phần mềm dựa trên CBR và thử nghiệm ở Công ty Honda Việt Nam

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LƢƠNG MINH HẢI XÂY DỰNG CÔNG CỤ ƢỚC LƢỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM LUẬN VĂN THẠC SĨ HÀ NỘI - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LƢƠNG MINH HẢI XÂY DỰNG CÔNG CỤ ƢỚC LƢỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM Ngành: CÔNG NGHỆ THÔNG TIN Chuyên ngành: CÔNG NGHỆ PHẦN MỀM Mã số: 60 48 10 LUẬN VĂN THẠC SĨ Người hướng dẫn khoa học TS. Trƣơng Anh Hoàng HÀ NỘI - 2010 MỤC LỤC CHƢƠNG 1 – GIỚI THIỆU ..................................................................................................... 1 CHƢƠNG 2 – QUY TRÌNH ƢỚC LƢỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM ............ 4 2.1. Tổng quan và mục đích ước lượng.......................................................................... 4 2.2. Chi tiết quy trình ước lượng ................................................................................... 4 2.2.1. Xác định phạm vi và mục tiêu của dự án .............................................................. 6 2.2.2. Xác định phạm vi kĩ thuật và các giả định ............................................................ 6 2.2.3. Thu thập dữ liệu...................................................................................................... 6 2.2.4. Xác định kích cỡ phần mềm .................................................................................. 7 2.2.5. Chuẩn bị đường mức ước lượng ............................................................................ 7 2.2.6. Thẩm định và phân tích các rủi ro ......................................................................... 9 2.2.7. Kiểm định kết quả ước lượng ................................................................................ 9 2.2.8. Xây dựng kế hoạch thực thi dự án ....................................................................... 10 2.2.9. Xây dựng tài liệu cho quá trình ước lượng ......................................................... 10 2.2.10. Đánh giá dự án thông qua quá trình phát triển ................................................. 11 2.3. Một số phương pháp ước lượng chi phí phát triển phần mềm .............................. 11 2.3.1. Mô hình COCOMO ...................................................................................... 11 2.3.2. Mô hình điểm chức năng (Function Point) .................................................... 15 2.3.3. Phương pháp chuyên gia ............................................................................... 16 CHƢƠNG 3 – PHƢƠNG PHÁP LẬP LUẬN DỰA TRÊN KINH NGHIỆM ...................... 19 3.1. Giới thiệu chung ................................................................................................... 19 3.2. Chi tiết phương pháp lập luận dựa trên kinh nghiệm ............................................. 19 3.2.1. Tìm kiếm dữ liệu tương tự ............................................................................ 22 3.2.2. Sử dụng lại kết quả tìm kiếm ......................................................................... 24 3.2.3. Bảo trì cơ sở dữ liệu các ca lập luận .............................................................. 27 3.3. Ưu và nhược điểm của phương pháp CBR. ........................................................... 30 3.3.1. Ưu điểm ........................................................................................................ 30 3.3.2. Nhược điểm .................................................................................................. 30 CHƢƠNG 4: PHÂN TÍCH THIẾT KẾ HỆ THỐNG PC-PACK-CES ................................ 32 4.1. Thiết kế hệ thống .................................................................................................. 32 4.2. Mô hình triển khai ................................................................................................ 32 4.3. Phân tích kiến trúc hệ thống ................................................................................. 33 4.3.1. Phân tích yêu cầu .......................................................................................... 33 4.3.2. Xác định các gói phân tích ............................................................................ 34 4.3.3. Xác định tác nhân ......................................................................................... 35 4.3.4. Biểu ca ca sử dụng ........................................................................................ 35 4.3.5. Luồng sự kiện ............................................................................................... 36 4.4. Phân tích ca sử dụng ............................................................................................. 40 4.4.1. Đăng nhập vào hệ thống ................................................................................ 40 4.4.2. Ca sử dụng quản lý danh mục dự án .............................................................. 42 4.4.3. Khai báo yếu tố chi phí ................................................................................. 45 4.4.4. Ca sử dụng ước lượng chi phí ....................................................................... 48 4.5. Thiết kế cơ sở dữ liệu PC-PACK-CES ................................................................. 50 4.5.1. Sơ đồ logic quan hệ các bảng dữ liệu ............................................................ 50 4.5.2. Mô tả chi tiết các bảng dữ liệu ...................................................................... 51 CHƢƠNG 5: ĐÁNH GIÁ KHẢ NĂNG ÁP DỤNG PC-PACK-CES TẠI CÔNG TY HONDA ................................................................................................................................... 56 5.1. Giới thiệu các hệ thống phần mềm tại công ty Honda ........................................... 56 5.2. Quy trình thử nghiệm phần mềm PC-PACK-CES tại công ty Honda .................... 58 5.2.1. Thu thập, phân tích và xử lý dữ liệu .................................................................... 58 5.2.2. Kết quả thử nghiệm chương trình ........................................................................ 61 5.3. Đánh giá khả năng áp dụng phần mềm PC-PACK-CES tại công ty Honda ........... 64 KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN CỦA ĐỀ TÀI ............................................................ 65 TÀI LIỆU THAM KHẢO................................................................................................................ 66 BẢNG KÝ HIỆU CÁC TỪ VIẾT TẮT Viết tắt Thuật ngữ CBR Case based reasoning KNN K nearest Neighbor PC-PACK-CES Giải thích Phương pháp lập luận dựa trên kinh nghiệm Thuật toán tìm k người hàng xóm gần nhất Phần mềm ước lượng chi phí phát triển phần mềm tại công ty Honda 4.3. DANH MỤC HÌNH VẼ Hình 2 - 1. Quy trình ước lượng chi phí phát triển dự án phần mềm[5] ............................... 5 Hình 3 - 1. Mô hình lập luận dựa trên kinh nghiệm [5]. .................................................. 20 Hình 3 - 2. Sơ đồ phân rã công việc hệ thống CBR[7]..................................................... 21 Hình 3 - 3. Sơ đồ mô tả quy trình tìm kiếm CBR[7] ........................................................ 23 Hình 3 - 4. Sơ đồ mô tả quá trình hiệu chỉnh giải pháp.................................................... 26 Hình 3 - 5. Mô tả phạm vi và khả năng tìm ra lời giải của ca lập luận. .............................. 29 Hình 4 - 1. Thiết kế tổng quan hệ thống .......................................................................... 32 Hình 4 - 2. Mô hình triển khai PC-PACK-CES ............................................................... 33 Hình 4 - 3. Sơ đồ các gói chức năng của hệ thống ........................................................... 34 Hình 4 - 4. Mô hình ca sử dụng mức gộp của hệ thống. .................................................. 36 Hình 4 - 5. Biểu đồ phân tích lớp đăng nhập hệ thống. .................................................... 40 Hình 4 - 6. Biểu đồ tuần tự phân tích thực thi ca sử dụng đăng nhập hệ thống ................ 40 Hình 4 - 7. Biểu đồ hoạt động chức năng đăng nhập hệ thống. ........................................ 41 Hình 4 - 8. Màn hình đăng nhập hệ thống PC-PACK-CES.............................................. 41 Hình 4 - 9. Màn hình chính hệ thống PC-PACK-CES ..................................................... 42 Hình 4 - 10. Biểu đồ lớp phân tích thực thi ca sử dụng khai báo dự án cơ sở lập luận ..... 42 Hình 4 - 11. Biểu đồ tuần tự phân tích thực thi ca sử dụng quản lý danh mục dự án ........ 43 Hình 4 - 12. Biểu đồ hoạt động ca sử dụng quản lý dự án cơ sở lập luận ......................... 43 Hình 4 - 13. Màn hình quản lý thông tin dự án cơ sở lập luận. ........................................ 44 Hình 4 - 14. Màn hình khai báo thông tin của dự án mới. ................................................ 44 Hình 4 - 15. Màn hình sửa thông tin dự án ...................................................................... 45 Hình 4 - 16. Biểu đồ lớp phân tích thực thi ca sử dụng khai báo yếu tố chi phí ............... 45 Hình 4 - 17. Biểu đồ tuần tự phân tích thực thi ca sử dụng khai báo yếu tố chi phí .......... 46 Hình 4 - 18. Biểu đồ hoạt động ca sử dụng quản lý yếu tố chi phí ................................... 46 Hình 4 - 19. Màn hình quản lý danh mục yếu tố chi phí .................................................. 47 Hình 4 - 20. Màn hình khai báo yếu tố chi phí mới. ........................................................ 47 Hình 4 - 21. Màn hình sửa dữ liệu yếu tố chi phí. ........................................................... 48 Hình 4 - 22. Biểu đồ phân tích lớp thực thi ca sử dụng ước lượng chi phí ....................... 48 Hình 4 - 23. Biểu đồ tuần tự phân tích thực thi ca sử dụng ước lượng chi phí ................. 49 Hình 4 - 24. Biểu đồ hoạt động ca sử dụng ước lượng chi phí ......................................... 49 Hình 4 - 25. Màn hình ước lượng chi phí phát triển dự án ............................................... 50 Hình 4 - 26. Quan hệ các bảng dữ liệu .................................................................................. 50 Hình 5 - 1. Cơ cấu tổ chức công ty Honda ...................................................................... 56 Hình 5 - 2. Kết quả ước lượng bằng phương pháp khoảng cách Euclidean. ..................... 63 Hình 5 - 3. Kết quả ước lượng bằng phương pháp tính độ tương tự thuộc tính ................ 63 4.3. DANH MỤC BẢNG Bảng 2 - 1. Bảng hằng số dùng trong tính toán bằng phương pháp COCOMO cơ bản 12 Bảng 2 - 2. Thang điểm đánh giá các đặc trưng của dự án .......................................... 14 Bảng 2 - 3. Bảng hệ số tính bằng phương pháp COCOMO trung gian ....................... 15 Bảng 2 - 4. Bảng quy đổi số dòng lệnh trong một chức năng của các ngôn ngữ lập trình .................................................................................................................................. 15 Bảng 5 - 1. Danh sách các hệ thống phần mềm sử dụng tại Honda ............................ 57 Bảng 5 - 2. Đặc trưng thuộc tính của các dự án đã thực hiện thành công ................... 59 Bảng 5 - 3. Danh sách các dự án lưu trong CSDL dùng để lập luận .......................... 61 Bảng 5 - 4. Dữ liệu đầu vào của dự án cần ước lượng ............................................... 62 Bảng 5 - 5. Chi phí dự toán của dự án mới ................................................................ 62 Bảng 5 - 6. Bảng kết quả thử nghiệm ước lượng bằng PC-PACK-CES ..................... 64 1 CHƢƠNG 1 – GIỚI THIỆU 1.1. Đặt vấn đề Sự thành công hay thất bại của một dự án nói chung và dự án phát triển phần mềm nói riêng phụ thuộc rất nhiều vào những kết quả của quá trình ước lượng, lập dự toán chi phí trước thời điểm triển khai dự án vào thực tế. Chủ đề này đã thu hút sự chú của rất nhiều nhà khoa học trên thế giới và đến nay đã có những công trình nghiên cứu có chất lượng. Từ xu hướng đó tác giả đã nghiên cứu một số phương pháp luận thường được sử dụng để ước lượng chi phí phát triển phần mềm, đặc biệt là những phương pháp mô phỏng quá trình lập luận của con người. Trong số đó, phương pháp lập luận dựa trên kinh nghiệm CBR (Case based reasoning) là một trong những phương pháp có nhiều ưu điểm, có khả năng áp dụng thành công vào công việc ước lượng chi phí. Đã có nhiều sản phẩm phần mềm thực hiện ước lượng bằng phương pháp này, tuy nhiên chưa có tiêu chuẩn cụ thể để đánh giá độ tin cậy kết quả mà những sản phẩm này đưa ra. Vì vậy qua luận văn này tác giả mong muốn: - Tìm hiểu phương pháp ước lượng dựa trên kinh nghiệm CBR (Case based reasoning). - Xây dựng một công cụ ước lượng chi phí phát triển phần mềm sử dụng kiến thức đã tìm hiểu được. - Thực nghiệm và đánh giá phương pháp ước lượng chi phí phát triển phần mềm tại phòng Hệ thống - Công ty Honda Vietnam. 1.2. Tính cấp thiết của đề tài Trong quá trình phát triển dự án phần mềm thì quản lý chi phí là một công việc có tầm quan trọng vô cùng lớn, bao gồm những quy trình đảm bảo cho dự án được hoàn tất trong sự cho phép của ngân sách: lập kế hoạch cho nguồn tài nguyên, ước lượng chi phí, dự toán chi phí, kiểm soát và điều chính chi phí. Nếu công việc này không được làm tốt sẽ dẫn tới sự thất bại của dự án và theo số liệu thống kê tại các doanh nghiệp Mỹ do CHAOS thực hiện thì chi phí trung bình vượt quá dự toán ban đầu theo nghiên cứu từ năm 1995 là 189% và giảm xuống còn 145% trong năm 2001. Hậu quả của việc huỷ các dự án Công nghệ thông tin ở Mĩ đã làm tốn trên 81 tỉ đô la (số liệu thống kê năm 1995 do CHAOS thực hiện)[5]. Vì vậy, việc ước lượng chính xác chi phí cần thiết để xây dựng các phần mềm là một vấn đề đang được quan tâm hiện nay. Xuất phát từ nhu cầu trên, tính từ năm 1960 cho đến nay đã có nhiều nhà khoa học đã tiến hành những công trình nghiên cứu nhằm tìm ra phương pháp luận chính xác nhất để ước lượng chi phí phát triển phần mềm như: mô hình ước lượng bằng tham số của Frank Freiman (1970)[7], phương pháp ước tính dựa trên các thông số COCOMO (1977) và COCOMO II (1990) của Barry W. Boehm[7], phương pháp ước 2 tính bằng điểm chức năng của Capres Jones (1980)[7]. Tuy nhiên, những phương pháp này còn tồn tại nhiều hạn chế như yêu cầu phải có đủ số thông tin đầu vào để tính toán chính xác, dựa trên một mô hình tính toán được xác định rõ nên khó áp dụng được ở những giai đoạn đầu của quá trình phát triển dự án. Để khắc phục những khó khăn đó, Roger Schank và các đồng nghiệp tại đại học Yale đề xuất ước lượng chi phí bằng phương pháp lập luận dựa trên kinh nghiệm CBR (Case base reasoning) năm 1977[4]. Ưu điểm nổi trội của phương pháp này là mô phỏng quá trình lập luận của con người nên dễ hiểu và có thể làm công cụ giải trình hiệu quả cho các thành viên tham gia phát triển dự án phần mềm. Ngoài ra, phương pháp cho phép thực hiện ước lượng với tập nhỏ dữ liệu ban đầu, dữ liệu trong tập kinh nghiệm sẽ được cập nhật ở những lần thực hiện ước lượng tiếp theo nên độ chính xác của kết quả ước lượng sẽ tỉ lệ thuận với số lượng dự án được lưu trữ trong cơ sở dữ liệu. 1.3. Mục tiêu của đề tài Mục tiêu của luận văn này nhằm tập trung nghiên cứu về phương pháp ước lượng dựa trên kinh nghiệm qua đó xây dựng một công cụ áp dụng kiến thức đã tìm hiểu được và đánh giá khả năng áp dụng sản phẩm tại phòng Hệ thống – Công ty Honda Vietnam. 1.4. Đối tƣợng và phạm vi nghiên cứu - Đối tượng: các dự án phần mềm được phát triển tại công ty Honda Vietnam từ năm 2006 đến nay. Phạm vi: bài toán ước lượng chi phí phát triển phần mềm tại phòng Hệ thống, công ty Honda Vietnam. 1.5. Kết cấu của luận văn Bố cục của luận văn chia thành 05 chương: - Chƣơng 1: Giới thiệu. Nội dung chương: Nêu tính cấp thiết của đề tài, mục tiêu và phạm vi nghiên cứu của luận văn. - Chƣơng 2: Quy trình ước lượng chi phí phát triển phần mềm Nội dung chương: Mô tả chi tiết các bước của quy trình ước lượng chi phí phát triển phần mềm và một số phương pháp ước lượng thường sử dụng. - Chƣơng 3: Phương pháp lập luận dựa trên kinh nghiệm. Nội dung chương: Trình bày các bước thực hiện và đánh giá ưu nhược điểm của phương pháp lập luận dựa trên kinh nghiệm. - Chƣơng 4: Phân tích thiết kế hệ thống PC-PACK-CES. Nội dung chương: Trình bày chi tiết phân tích, thiết kế của hệ thống PCPACK-CES (ca sử dụng, biểu đồ tuần tự, thiết kế bảng dữ liệu). - Chƣơng 5: Đánh giá khả năng áp dụng PC-PACK-CES tại công ty Honda Vietnam. Nội dung chương: Trình bày kết quả thử nghiệm và đánh giá khả năng áp dụng hệ thống PC-PACK-CES tại công ty Honda. 3 - Kết luận và hƣớng phát triển của đề tài. Nội dung chương: Trình bày những kết luận của tác giả sau khi nghiên cứu và triển khai phần mềm áp dụng phương pháp lập luận dựa trên kinh nghiệm tại công ty Honda. Ngoài ra, tác giả cũng đề xuất hướng nghiên cứu và cải tiến chương trình của tác giả trong thời gian tới.  4 CHƢƠNG 2 – QUY TRÌNH ƢỚC LƢỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM 2.1. Tổng quan và mục đích ƣớc lƣợng Phần mềm là một sản phẩm đặc thù có quan hệ mật thiết với nguồn ngân sách đầu tư xây dựng hệ thống thông tin của bất kì tổ chức nào. Với tính đa dạng của các đặc trưng phần mềm và sự xuất hiện ngày càng nhiều của các công nghệ mới đã dẫn đến sẽ ngày càng khó khăn hơn để ước lượng chính xác chi phí cần thiết để phát triển dự án phần mềm. Quá trình ước lượng bao gồm việc xác định và thẩm định những yếu tố có liên quan đến quá trình xây dựng một sản phẩm phần mềm. Đó có thể là những tiến trình phát triển dự án, nguồn nhân lực và tài nguyên cần để xây dựng và hoàn thiện dự án. Đến thời điểm hiện tại, việc ước tính chính xác chi phí cần thiết để hoàn thành một dự án vẫn là một vấn đề được nhiều nhà nghiên cứu trên thế giới quan tâm. Mục đích của việc ước lượng chi phí phát triển phần nhằm đáp ứng các yêu cầu sau: - Là cơ sở để xem xét và đánh giá tính khả thi của dự án: bất kì tổ chức nào trước khi quyết định có thực hiện dự án hay không sẽ cần tới kết quả ước lượng chi phí và nguồn tài nguyên cần để hoàn thành dự án. Dựa trên kết quả ước lượng này các tổ chức sẽ xem xét và đánh giá khả năng của mình có thể thực hiện dự án hay không để từ đó đưa ra quyết định cần thiết. - Là công cụ hỗ trợ quản lý dự án: người quản lý dự án sẽ chịu trách nhiệm lập kế hoạch và điều hành việc thực thi dự án. Nhờ có sự trợ giúp của các kết quả ước lượng dự án, công việc này sẽ đơn giản và hiệu quả hơn vì công việc quản lý có thể dựa trên lịch biểu và nguồn nhân lực đã được ước tính trước đó. - Các thành viên của đội thực hiện dự án sẽ kết hợp với nhau hiệu quả hơn nếu hiểu rõ vai trò của mình và toàn bộ các hoạt động trong dự án. Điều này có thể đạt được nếu kết quả ước lượng được áp dụng để xây dựng bảng phân chia nhiệm vụ cho các thành viên trong nhóm phát triển phần mềm. Quá trình ước lượng chi phí có thể được thực hiện nhiều lần trong suốt vòng đời phát triển dự án. Lý do là vì trong quá trình xây dựng hệ thống sẽ xuất hiện ngày càng nhiều thông tin hữu ích chưa có tại thời điểm thực hiện ước lượng trước đó và những thông tin này sẽ làm tăng độ chính xác, chi tiết của quá trình ước lượng. 2.2. Chi tiết quy trình ƣớc lƣợng Nếu quá trình ước lượng chi phí được tích hợp với quá trình phát triển phần mềm thì có thể lập nên các kế hoạch dự án khả thi và đáng tin cậy, giúp thoả mãn các yêu cầu của hệ thống và các cam kết đã đề ra. Ngoài ra, quá trình này còn hỗ trợ đắc lực cho hoạt động quản lý dưới hình thức cung cấp những thông tin kế hoạch chính xác và kịp thời. 5 Cấu trúc của dự án được hình thành từ nhiều yếu tố khác nhau bao gồm đặc tả yêu cầu và kiến trúc của hệ thống, yêu cầu chất lượng, kế hoạch sử dụng nguồn nhân lực. Tuy nhiên, yếu tố có vai trò quan trọng nhất và có vai trò quyết định tới sự thành công hoặc thất bại của dự án là việc ước lượng phạm vi, yếu tố thời gian và chi phí cần thiết để hoàn thành dự án. Quá trình ước lượng có thể tác động tới nhiều khía cạnh của dự án, ràng buộc các hoạt động có thể được thực hiện trong quá trình phát triển hoặc nâng cấp sản phẩm phần mềm và là cơ sở để lựa chọn những phương án đã lập kế hoạch. Từ những phân tích trên, chúng ta có thể định nghĩa ước lượng là quá trình đưa ra nhận định về giá trị xấp xỉ, gần đúng của một số thông tin mà ta quan tâm. Ước lượng có thể dựa trên miền tri thức hoặc giả định không đầy đủ hay hoàn chỉnh. Đã có nhiều công trình nghiên cứu để chuẩn hoá quy trình ước lượng chi phí phát triển phần mềm, tuy nhiên cho đến nay vẫn chưa có một mô hình tiêu chuẩn được thừa nhận và sử dụng rộng rãi. Mỗi một tổ chức sẽ có một mô hình ước tính chi phí của riêng mình, nhưng nhìn chung những mô hình đó bao gồm những bước chính sau: Hình 2 - 1. Quy trình ước lượng chi phí phát triển dự án phần mềm[5] 6 2.2.1. Xác định phạm vi và mục tiêu của dự án Những yêu cầu ở thời điểm bắt đầu thực hiện dự án cần định nghĩa và lập tài liệu với nội dung thể hiện những mong muốn vào kết quả ước lượng. Nếu tất cả các thành viên tham gia dự án có thể hiểu rõ phạm vi và mục tiêu của quá trình ước lượng thì sẽ hình thành đường mức cơ sở và có thể dựa vào đó để đánh giá tác động của những thay đổi của dự án trong tương lai. Ngoài ra, công việc này còn giúp các thành viên của dự án có thể thấy được những hiểu lầm và làm sáng tỏ các giả định trái ngược nhau về những gì được mong đợi của các nhóm tham gia dự án. Bằng việc lập tài liệu đặc tả ứng dụng bao gồm các chi tiết mang tính kĩ thuật, các mối phụ thuộc bên ngoài dự án và các yêu cầu nghiệp vụ sẽ cung cấp thông tin đầu vào có giá trị để ước lượng nguồn tài nguyên cần thiết để hoàn thành dự án. Trong đó, những đặc tính mang tính chất kĩ thuật nếu càng được mô tả chi tiết sẽ càng có giá trị. Sau khi các yêu cầu đã được làm rõ thì lúc đó mới có thể xác định chi phí khả thi của dự án. Quá trình ước lượng cần được cập nhật thường xuyên trong suốt vòng đời phát triển dự án. Để đảm bảo tính toàn vẹn của dự án, khi có bất kì sự thay đổi nào của dữ liệu hoặc sự xuất hiện của những thông tin hữu ích thì cần phải lưu trữ lại và sẽ là một yếu tố tham gia quá trình ước lượng. 2.2.2. Xác định phạm vi kĩ thuật và các giả định Chúng ta cần xác định rõ các chức năng có trong quá trình ước lượng để thiếp lập đường mức kĩ thuật hợp lý. Trong trường hợp không xác định được các yếu tố chức năng của ước lượng thì các quy luật nền tảng và các giả định cần nêu rõ những gì có và không có trong quá trình ước lượng. Những vấn đề liên quan đến sử dụng lại và những giả định khác cũng cần lập tài liệu để theo dõi. Mặc dù các quy luật nền tảng và các giả định là cơ sở của quá trình ước lượng nhưng chúng ta phải nhận thức rằng các quy luật và giả định này chưa hoàn thiện và còn chứa đựng nhiều yếu tố không chắc chắn ở giai đoạn đầu của ước lượng. Do đó, cùng với việc thường xuyên thực hiện ước lượng lại cũng cần phải tiến hành xem xét và định nghĩa lại các giả định trong dự án. 2.2.3. Thu thập dữ liệu Theo định nghĩa thì bất kì quá trình ước lượng nào cũng bao gồm những yếu tố không chắc chắn nên chúng ta thường biểu diễn những yếu tố đầu vào dưới dạng khoảng giá trị thay vì những dữ liệu cụ thể. Điều này sẽ giúp chúng ta có thể thực hiện quá trình ước lượng ngay cả khi chưa xác định đầy đủ phạm vi của hệ thống đang lập dự toán. Tuy nhiên, để đạt được kết quả ước lượng nhất quán đòi hỏi chúng ta phải xác định được những thông tin cốt lõi. Dữ liệu có liên quan đến dự án không chỉ đến từ một nguồn duy nhất và cũng không xuất hiện tại cùng một thời điểm nên nếu chúng ta sử dụng một mẫu biểu tập hợp dữ liệu hoàn chỉnh sẽ có tác dụng tích cực cho công 7 việc thu thập dữ liệu vì khi tìm ra thông tin mới, có giá trị thì đã có sẵn một hình thức tổ chức và quản lý dữ liệu của toàn bộ dự án. 2.2.4. Xác định kích cỡ phần mềm Trong điều kiện tối ưu các tổ chức nên thực hiện toàn bộ những bước thuộc quy trình ước lượng chi phí phát triển phần mềm đã mô tả ở hình 2-2 để có thể đạt được kết quả ước lượng chính xác và đáng tin cậy. Tuy nhiên, nếu yếu tố thời gian không cho phép thì nên tập trung vào bước xác định kích cỡ phần mềm. Bằng việc sử dụng những công cụ tự động ước tính chi phí và lịch biểu thời gian có thể cung cấp dữ liệu cho những người chịu trách nhiệm phân tích dự án. Kích cỡ phần mềm là yếu tố có ảnh hưởng rất lớn tới việc xác định chi phí và lịch biểu thời gian phát triển dự án. Phạm vi của dự án phần mềm được định nghĩa bởi việc xác định không chỉ những thông tin liên quan đến dự án được phát triển mới mà còn bao gồm dữ liệu của những hệ thống đã có sẽ được tích hợp vào hệ thống mới. Ngoài ra, để ước lượng kích cỡ phần mềm chúng ta cần xác định những yếu tố như số dòng lệnh (SLOC – Source lines of code), số điểm chức năng hoặc bất kì cách tính đơn vị chương trình nào đang được sử dụng để thống kê. Thông thường, để có thể đưa ra thông tin tổng thể kích cỡ phần mềm, kết quả ước lượng kích cỡ được biểu diễn dưới dạng phạm vi chặn trên và chặn dưới. Danh sách bên dưới là một số hình thức ước lượng kích cỡ phần mềm thường được các tổ chức sử dụng:  Ý kiến đánh giá của các chuyên gia: là hình thức ước tính dựa trên thông tin tập hợp lại của các dự án đã thực hiện trước đó và những giả định có thể diễn ra với hệ thống mới kết hợp với kinh nghiệm của các chuyên gia thuộc lĩnh vực.  Hình thức suy luận: là phương pháp so sánh độ tương đồng giữa hai thực thể dựa trên một số đặc trưng nhất định. Kết quả so sánh ở dạng giá trị xấp xỉ nên có thể hiệu chỉnh các đặc trưng so sánh với thực thể tương đồng tìm được để tăng độ chính xác của phương pháp.  Phương pháp hình thức hoá: là phương pháp thống kê có sử dụng các công cụ tự động hoặc các thuật toán được xác định trước như hình thức đếm số lượng các hệ thống con hoặc các lớp con và chuyển đổi thành các điểm chức năng.  Phương pháp thống kê định cỡ: là phương pháp cung cấp phạm vi kĩch cỡ dưới dạng khoảng giới hạn cận trên và cận dưới. 2.2.5. Chuẩn bị đƣờng mức ƣớc lƣợng Kết quả của quá trình ước lượng có vai trò quyết định tới độ chính xác của ngân sách và lịch biểu thời gian phát triển dự án. Do đó, để đảm bảo tính chính xác và hiệu quả của kết quả ước lượng chúng ta cần xem xét một số yếu tố sau: - Chỉ các chuyên gia được đào tạo, có kinh nghiệm và tay nghề được giao nhiệm vụ xác định kích cỡ phần mềm và tham gia vào quá trình ước lượng. - Những chuyên gia này cần được trang bị công cụ và công nghệ phù hợp. 8 Người quản lý dự án cần xây dựng và chịu trách nhiệm hiệu chỉnh quy trình ước lượng thống nhất trong toàn bộ vòng đời phát triển dự án. Hiện nay, có nhiều phương pháp khác nhau để chuẩn bị đường mức ước lượng có thể là phương pháp tiếp cận từ dưới lên (Bottom-Up), phương pháp đánh giá của chuyên gia và mô hình chi phí…  Phương pháp ước lượng từ dưới lên trên (Bottom-Up): phương pháp này bao gồm việc phân rã hệ thống tới mức thấp nhất dạng chức năng hay nhiệm vụ ở nút lá. Chi phí để thực hiện các thực thể ở trên khác nút lá sẽ bằng tổng chi phí thực hiện của các phần tử nút lá thuộc thực thể này. Quá trình này sẽ được lặp lại đến khi gặp thực thể ở mức cao nhất và giá trị tổng chi phí tính được sẽ là chi phí để thực hiện dự án. Phương pháp này khá hiệu quả để ước tính chi phí cho các hệ thống cỡ nhỏ vì những hệ thống này sẽ thuận lợi cho việc phân rã nhỏ thành các module chức năng.  Mô hình chi phí phần mềm: mỗi một mô hình chi phí phần mềm sẽ có tập yêu cầu thông tin đầu vào khác nhau. Tuy nhiên, đa số các mô hình đều yêu cầu người sử dụng cung cấp những đặc trưng của dự án dưới dạng các tham số đầu vào để thực hiện tính toán. Những thông tin này có thể là thông tin mô tả, các đặc trưng của dự án, kinh nghiệm và trình độ đào tạo của đội ngũ phát triển dự án, phương thức và công cụ được sử dụng để hoàn thiện dự án. Các mô hình chi phí dạng thông số cung cấp các phương tiện để áp dụng một phương thức thống nhất cho mục đích chuyển đổi các tình huống không rõ ràng thành các phân tích thống kê toán học chính xác. Do đó, nhiều nhà nghiên cứu đã thừa nhận những mô hình chi phí phần mềm có tính bao quát hơn so với các kĩ thuật ước lượng khác và giúp giảm thiểu sai số khi thực hiện ước lượng chi phí phần mềm. Ngoài ra, mô hình còn được sử dụng như một phương tiện để quản lý thông tin có tính chất mô tả dự án, hỗ trợ quá trình phân tích và xác định những rủi ro có thể xảy ra.  Mô hình ước lượng dựa vào các hạng mục công việc: một hình thức khác được sử dụng để ước lượng các thành phần khác nhau của dự án phần mềm được bắt đầu từ các đặc tả yêu cầu và quy mô của dự án. Những thông tin này sẽ được dùng để xác định những hạng mục công việc cần thực hiện để từ đó tính toán ra toàn bộ nỗ lực cần thiết để hoàn thành dự án. Kết quả của quá trình sẽ cung cấp cho chúng ta bảng phân rã công việc thể hiện cách thức tổ chức và thực hiện công việc cần thiết. Tài liệu này sẽ được sử dụng để lập kế hoạch cho dự án và cung cấp thông tin nhiệm vụ cụ thể cần được triển khai. Tuy nhiên, chúng ta cần lưu ý là tài liệu này không thể hiện dạng danh mục những việc cần phải làm mà nội dung của nó thể hiện kiến trúc các nhiệm vụ cần thực hiện. Khi toàn bộ những nhiệm vụ này được thực hiện thì kết quả tương ứng với việc thoả mãn tất cả những thoả thuận ban đầu được đưa ra. - 9 2.2.6. Thẩm định và phân tích các rủi ro Chúng ta phải thừa nhận rằng luôn luôn tiềm ẩn những rủi ro không thể lường trước được trong quá trình thực hiện bất kì dự án nào. Tuy nhiên, vấn đề chúng ta cần quan tâm là việc phân định rõ thế nào là rủi ro và rủi ro là gì. Với những vấn đề dễ dàng được nhận diện và xử lý thì không cần đánh giá đó là mối đe doạ cho dự án. Rủi ro là những vấn đề khiến chúng ta phải dành thời gian, chi phí để xử lý hoặc trầm trọng hơn là mất sự kiểm soát những gì đang diễn ra. Thông thường, sự kiện rủi ro có xẩy ra hay không được biểu diễn dưới dạng xác suất sự kiện. Giá trị này được thể hiện bằng hai giá trị logic sau: 0 – không thể xảy ra và 1 – chắc chắn sẽ xảy ra. Khi xác suất của rủi ro có giá trị bằng 1 thì rủi ro trở thành vấn đề cần giải quyết vì nó chắc chắn sẽ xảy ra và sẽ ảnh hưởng tới quá trình phát triển dự án. Với mỗi rủi ro chúng ta cần xác định những việc cần làm để giảm thiểu hoặc tránh được ảnh hưởng của chúng. Quản lý rủi ro sẽ bao gồm những hành động cần thực hiện để hạn chế hoặc loại bỏ rủi ro có thể xảy ra. Quá trình quản lý rủi ro giúp chúng ta có thể xác định rõ những mối đe doạ có thể xuất phát từ bên trong hoặc bắt nguồn từ các yếu tố ngoại cảnh tới quá trình thực hiện dự án. Với những vấn đề có liên quan đến việc xác định kích cỡ và ước lượng phần mềm sẽ có những ảnh hưởng tiêu cực. Nhiệm vụ của người quản lý dự án là đánh giá triệt để các mối đe doạ tiềm ẩn để từ đó có thể xây dựng đối sách cần thiết nhằm giảm thiểu hoặc hạn chế tác động khi vấn đề nảy sinh. 2.2.7. Kiểm định kết quả ƣớc lƣợng Nếu xét đến vị trí trong quy trình mô tả ở hình 2-1 thì đến bước này kết quả ước lượng được đảm bảo là chính xác và đáng tin cậy. Tuy nhiên, chúng ta vẫn cần thẩm định lại phương pháp đã sử dụng và kết quả ước lượng nhằm đảm bảo tính thống nhất của quá trình ước lượng. Việc làm này sẽ giúp chúng ta tin tưởng hơn vào độ chính xác của dữ liệu ước lượng, khẳng định tính hiệu quả của phương pháp và quan trọng hơn là chúng ta đã đi đúng lộ trình. Có nhiều phương pháp khác nhau thực hiện thẩm định quá trình ước lượng. Đối tượng cần đánh giá sẽ là quy trình xây dựng kế hoạch ước lượng và bản thân quá trình ước lượng. Thông thường, để đảm bảo tính khách quan khi thẩm định công việc này sẽ do một thành viên không tham gia quá trình ước lượng chi phí dự án thực hiện. Nhằm tăng tính chính xác cho công việc thẩm định, cần sử dụng nhiều phương pháp và công cụ khác nhau để thực hiện các bước so sánh kết quả phân tích. Chúng ta cần dựa vào những giả định được sử dụng trong quá trình ước lượng để thẩm định phương pháp ước tính. Ngoài ra, chúng ta cũng cần đảm bảo là các quy tắc nghiệp vụ được sử dụng thống nhất trong toàn bộ quá trình ước lượng. Nếu chúng ta ước tính chi phí thấp và không lường hết các rủi ro có liên quan đến những yêu cầu đặc biệt sẽ dẫn tới việc đánh giá thấp hoặc coi nhẹ những yếu tố này. Những giả định sai lầm, dữ liệu không đáng tin cậy và độ lệch ước lượng sẽ được phát hiện thông qua quy trình thẩm định hợp lý. Điều này sẽ giúp chúng ta hiểu 10 rõ hơn những rủi ro gắn liền với bản kế hoạch thực hiện ước lượng chi phí phần mềm. Thông qua việc tách những vấn đề từ nguồn gốc phát sinh ra chúng, chúng ta có thể xây dựng kế hoạch để ngăn chặn những rủi ro có liên quan đến những vấn đề đó, đồng thời chúng ta có thể xác định rõ những nhiệm vụ cần thực hiện để hoàn thành dự án với nguồn lực cho trước. 2.2.8. Xây dựng kế hoạch thực thi dự án Quá trình xây dựng kế hoạch thực thi dự án bao gồm việc sử dụng kết quả ước tính và việc phân bổ chi phí, lịch biểu thời gian thành các chức năng và cấu trúc phân chia công việc thành từng nhiệm vụ. Sự thành bại của một dự án chịu ảnh hưởng rất lớn bởi vai trò của người quản lý dự án. Người quản lý dự án cần phải dám đối mặt và kịp thời thiết lập đối sách cho những thách thức của hiện tại để có thể loại bỏ những rủi ro có thể xảy ra ở tương lai. Một người quản lý dự án được đánh giá là thực hiện tốt nhiệm vụ của mình nếu sở hữu kinh nghiệm phong phú về lĩnh vực và kĩ thuật phát triển phần mềm, là người có khả năng lãnh đạo các thành viên trong nhóm, có khả năng phân tích những vấn đề tiềm ẩn và có thể xây dựng kế hoạch hoạt động của dự án nhằm đạt tới mục tiêu hoàn thành dự án đúng tiến độ, với nguồn chi phí cho trước. 2.2.9. Xây dựng tài liệu cho quá trình ƣớc lƣợng Ở thời điểm kết thúc quá trình phát triển dự án phần mềm, chúng ta nên lập tài liệu nhằm lưu lại những thông tin quan trọng tạo nên quá trình ước lượng cũng như những bài học rút ra được từ việc thực hiện ước lượng chi phí phần mềm. Việc làm này sẽ là căn cứ chứng minh rằng những hạng mục công việc chúng ta thực hiện là hợp lệ, kết quả của quá trình ước lượng là đáng tin cậy. Nội dung của tài liệu này là những quyết định quan trọng được đưa ra trong quá trình xây dựng quy trình ước lượng, kết quả và những tác động của những hoạt động đã được thực hiện. Tài liệu này cũng nên đề cập tới những thông tin còn thiếu, những rủi ro, những vấn đề phức tạp đã nảy sinh trong quá trình ước lượng. Cuối cùng, trong tài liệu này cũng không thể thiếu thông tin mô tả quá trình kết hợp của các thành viên trong đội ước lượng, quá trình trao đổi với khách hàng, sự đánh đổi mà chúng ta đã thực hiện để làm rõ các vấn đề phát sinh trong quá trình ước tính chi phí dự án. Thời điểm thích hợp nhất để đánh giá, tổng kết để rút ra những bài học kinh nghiệm từ dự án là ngay khi quá trình phát triển dự án kết thúc vì khi đó các thành viên tham gia vẫn còn có thể nhớ chi tiết các vấn đề đã diễn ra. Quá trình họp đánh giá có thể chỉ là tiến hành ở mức nhỏ chỉ có ít nhất hai thành viên phát triển dự án tham gia cho đến mức cao hơn là những buổi họp có sự tham gia của các thành viên tham gia trả lời phiếu điều tra, khảo sát nhằm tiến tới thống nhất những vấn đề chính yếu có ảnh hưởng tới quy trình ước lượng chi phí phát triển dự án phần mềm. Dự án phát triển phần mềm được xem như là cơ hội tốt để tổ chức cải tiến quy trình ước lượng chi phí và là cơ sở để chuẩn bị tốt hơn nữa cho những dự án tiếp theo. 11 2.2.10. Đánh giá dự án thông qua quá trình phát triển Những thông tin liên quan đến quá trình phát triển dự án cần được tập hợp lại làm cơ sở để so sánh với kế hoạch ban đầu. Chúng ta cần xem xét lại toàn bộ quy trình ước lượng trong trường hợp chi phí thực tế cần để hoàn thành dự án khác xa so với kế hoạch đã đề ra. Thông thường, chúng ta cần thu thập lại dữ liệu của những đặc trưng sau của dự án: - Yếu tố chi phí ở khía cạnh nỗ lực của nhân viên, nỗ lực ở từng giai đoạn và nỗ lực tổng thể của dự án. - Những thiếu sót được tìm ra và đối sách và chi phí để khắc phục chúng. - Đặc trưng của quy trình phát triển dự án như ngôn ngữ lập trình, mô hình phát triển và công nghệ. - Những thay đổi về đặc tả yêu cầu, lịch biểu phát triển. - Kiến trúc phần mềm ở khía cạnh quy mô và độ phức tạp. Công việc ước tính chi phí phần mềm, lập kế hoạch thực hiện và xác định rủi ro là những công việc khó khăn nhưng có ảnh hưởng rất lớn tới sự thành công của dự án. Kết quả công việc sẽ hiệu quả nếu chúng ta xây dựng tiêu chuẩn hoá cho quy trình ước lượng và được kiểm nghiệm ở nhiều dự án khác nhau. Quy trình ước lượng mô tả ở hình 2-2 sẽ thay đổi theo nhu cầu thực tế của từng tổ chức, tuỳ theo quan điểm đánh giá những hạng mục công việc được cho là quan trọng, cần tập trung thời gian và nhân lực để thực hiện. 2.3. Một số phƣơng pháp ƣớc lƣợng chi phí phát triển phần mềm Hiện nay, trên thế giới có nhiều phương pháp ước lượng chi phí khác nhau được sử dụng nhưng nhìn chung các phương pháp này thuộc một trong ba nhóm phương pháp sau:  Phương pháp dùng mô hình toán học: là nhóm sử dụng các công thức toán học và các tham số đầu vào để tính toán nỗ lực và thời gian cần thiết để hoàn thành dự án. Những mô hình toán học phổ biến gồm có mô hình COCOMO (Constructive COst MOdel) (Boehm 1981) và kĩ thuật phân tích điểm chức năng (Albrecht & Gaffney 1983) [3].  Phương pháp đánh giá của chuyên gia: là nhóm phương pháp dự đoán chi phí dựa trên kinh nghiệm và kĩ năng của một hoặc nhiều chuyên gia phần mềm.  Phương pháp ước lượng dựa trên lập luận: là nhóm phương pháp so sánh dự án cần ước tính với những dự án đã thực hiện và hoàn thành trước đó để tìm ra các dự án tương tự làm cơ sở để ước lượng chi phí cần thiết hoàn thành dự án mới. 2.3.1. Mô hình COCOMO COCOMO là mô hình do Barry Boehm thiết kế nhằm ước tính công sức, thời gian và số người-tháng (man-month) cần thiết để phát triển dự án dựa trên kích cỡ 12 phần mềm. Mô hình này rất phù hợp để ước tính cho các phần mềm kích cỡ lớn. Mô hình này dựa trên kết quả khảo sát 60 dự án tại các công ty TRW, Northrop Grumman từ năm 2002[7]. Kết quả nghiên cứu đã được xây dựng thành chương trình viết bằng ngôn ngữ PL/I và bao gồm hơn 100,000 dòng lệnh. Mô hình COCOMO gồm có 3 dạng sau:  COCOMO cơ bản: mô hình cho giá trị đơn, chi phí được tính dựa trên số lượng dòng lệnh tạo nên phần mềm.  COCOMO trung gian: chi phí được tính theo độ lớn phần mềm theo số dòng lệnh và cộng thêm đánh giá sản phẩm, phần cứng, nguồn nhân lực và các thuộc tính của dự án.  COCOMO chi tiết: tích hợp mọi đặc trưng của mô hình COCOMO trung gian nhưng có bổ sung thêm đánh giá của chi phí ảnh hưởng trong mỗi giai đoạn của quy trình công nghệ phần mềm. 2.3.1.1. COCOMO cơ bản Mô hình có thể áp dụng cho ba lớp dự án phần mềm  Dự án với quy mô nhỏ: dự án phần mềm đơn giản và có cấu trúc rõ ràng, đội ngũ tham gia phát triển nhỏ, có kinh nghiệm phát triển ứng dụng cùng loại và làm việc trên môi trường với những yêu cầu không quá khắt khe.  Dự án phần mềm nửa gắn kết: đội ngũ tham gia phát triển có kinh nghiệm về nhiều lĩnh vực khác nhau và làm viêc trên môi trường với những yêu cầu không quá khắt khe.  Dự án nhúng: được triển khai trong điều kiện chặt chẽ về phần cứng, phần mềm và có cả những ràng buộc về điều kiện vận hành. Công thức tính toán của mô hình COCOMO cơ bản có dạng: E  ab ( KLOC) bb ; D  cb ( E ) db ; P  E / D Trong đó: E - ước tính người/tháng. D - thời gian triển khai, tính theo tháng. KLOC – ước tính số dòng lệnh (đơn vị = 1000 dòng lệnh) của sản phẩm dự án phần mềm. P – số lượng người cần cho dự án. Hệ số ab, bb, cb, db được cho bởi bảng sau đây: Dự án phần mềm ab bb cb db Quy mô nhỏ 2.4 1.05 2.5 0.38 Nửa gắn kết 3.0 1.12 2.5 0.35 Nhúng 3.6 1.20 2.5 0.32 Bảng 2 - 1. Bảng hằng số dùng trong tính toán bằng phương pháp COCOMO cơ bản 13 Mô hình COCOMO cơ bản rất phù hợp cho ước tính thô vì dễ dàng và thực hiện nhanh. Tuy nhiên, kết quả tính toán có độ chính xác không cao vì thiếu một số nhân tố, chưa kể đến sự khác nhau trong ràng buộc về phần cứng, kinh nghiệm và khả năng chuyên nghiệp của con người. Ngoài ra, việc sử dụng các công cụ hiện đại và các đặc trưng khác cũng sẽ ảnh hưởng tới độ chính xác của kết quả ước lượng. 2.3.1.2. COCOMO trung gian Mô hình COCOMO trung gian là sự cải tiến của mô hình COCOMO cơ bản và được dùng để ước tính thời gian lập trình trong triển khai sản phẩm phần mềm. Sự cải tiến này nếu xem xét trên một tập hợp “Chi phí của các đặc trưng các bộ phận điều phối” thì được chia thành 4 nhóm sau:  Đặc trưng của phần mềm - Yêu cầu về độ tin cậy của phần mềm. - Độ lớn CSDL của ứng dụng. - Độ phức tạp của phần mềm.  Đặc trưng của phần cứng. - Ràng buộc về tính năng vận hành. - Ràng buộc về bộ nhớ. - Tính không ổn định của môi trường máy ảo. - Yêu cầu về thời gian chuyển hướng (turnabout time).  Đặc trưng về chuyên gia - Khả năng phân tích vấn đề. - Khả năng về kĩ nghệ phần mềm. - Kinh nghiệm phát triển ứng dụng. - Kinh nghiệm về máy ảo. - Kinh nghiệm sử dụng ngôn ngữ lập trình.  Đặc trưng về dự án - Sử dụng các công cụ phần mềm. - Khả năng ứng dụng các phương pháp của kĩ nghệ phần mềm. - Yêu cầu về lịch biểu triển khai dự án. Mỗi đặc trưng trên sẽ được đánh giá và cho điểm theo thang điểm có 6 mức từ rất chậm đến quá cao. Dựa trên thang điểm, hệ số nỗ lực sẽ được tính theo bảng xếp hạng sau: Rất Chậm Bình chậm thƣờng Cao Rất cao 1.15 1.40 Đặc trưng của phần mềm Yêu cầu về độ tin cậy của phần mềm 0.75 0.88 1.00 Quá cao