Luận văn Nghiên cứu ước lượng dự án

c gọi là Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs – Unadjusted Use Case Points). Các Yếu tố Kĩ thuật liên quan trong việc phát triển chức năng được đánh giá, tương tự như trong Phân tích Điểm Chức năng, để đưa ra kết quả là Yếu tố Độ phức tạp Kĩ thuật. Bước cuối cùng trong ước lượng là một tính toán khác với phương pháp Điểm Chức năng và đưa ra một yếu tố mới được gọi là Yếu tố Độ phức tạp Môi trường. Kết quả cuối cùng của phép đánh giá là số Điểm Ca Sử dụng (UCPs – Use Case Points), là tích của 3 thừa số được mô tả ở trên. Khái quát, phép đánh giá số Điểm Ca sử dụng có 4 bước: - Tính Điểm Ca Sử dụng Chưa được điều chỉnh - Tính Yếu tố Độ phức tạp Kĩ thuật - Tính Yếu tố Độ phức tạp Môi trường - Tính số Điểm Ca Sử dụng của dự án Sau đây là tính toán cụ thể ở các bước như được đưa ra trong các tài liệu ([5] Karner, 1993), ([8] Schneider, 2001). Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 27 3.2.1.1 Tính số Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs – Unadjusted Use Case Points) Số Điểm Ca Sử dụng Chưa được Điều chỉnh (UUCPs - Unadjusted Use Case Points) được tính dựa trên hai tính toán sau: - Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs – Weighted Use Cases) dựa trên tổng số các hoạt động (hoặc các bước) được tính đến trong tất cả các kịch bản ca sử dụng. - Đếm số Tác nhân sau khi đánh Trọng số (WAs – Weight Actors) dựa trên độ phức tạp kết hợp của tất cả các Tác nhân Ca sử dụng. Tính toán cụ thể: Bước 1: Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs) Các ca sử dụng riêng lẻ được phân loại thành Đơn giản, Trung bình hay Phức tạp, và được đánh trọng số phụ thuộc vào số các giao dịch mà chúng chứa, Bảng 3-1. Chỉ có các ca sử dụng cụ thể được đếm, tức là không tính đến các một ca sử dụng đóng vai trò giao diện. Kiểu Ca sử dụng Mô tả Trọng số Đơn giản Một ca sử dụng là đơn giản nếu kịch bản của nó có tới 3 giao dịch hoặc ít hơn; ta có thể thực thi hành nó với tới ít hơn 5 lớp phân tích. 5 Bình thường Một ca sử dụng là trung bình nếu kịch bản của nó có từ 4 đến 7 giao dịch; sự thi hành của nó đòi hỏi từ 5 đến 10 lớp phân tích. 10 Phức tạp Một ca sử dụng là phức tạp nếu kịch bản của nó có trên 7 giao dịch; sự thi hành của nó đòi hỏi trên 10 lớp phân tích. 15 Bảng 3-1. Phân loại và đánh trọng số ca sử dụng trong UCP Một “giao dịch” của ca sử dụng là một tập các hành động được thực hiện trọn vẹn hoặc hoàn toàn không được thực hiện. Nó không đơn thuần là khái niệm “giao dịch” như trong cơ sở dữ liệu. Một giao dịch use case có thể chứa các thao tác cơ sở dữ liệu, nhưng ngoài ra nó còn chứa thêm các hoạt động khác nữa, ví dụ các kích thích của tác Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 28 nhân, các thao tác khác của hệ thống. Theo mô tả của ([2] Collaris, 2009), một giao dịch là một “vòng tròn” hành động từ người dùng tới hệ thống quay lại người dùng. Một “giao dịch” không phải là một bước của ca sử dụng, một kích thích từ tác nhân (có thể có nhiều kích thích từ tác nhân tới hệ thống nhưng không có chiều ngược lại), một bước hệ thống hay một giao dịch cơ sở dữ liệu. Giữ giao dịch ở cấp độ hợp lý sẽ cho ước lượng chính xác hơn, điều này có được nhờ kinh nghiệm áp dụng trong quá khứ. WUCs được tính bằng cách đếm số lượng ca sử dụng thuộc mỗi loại, nhân số lượng mỗi loại ca sử dụng với trọng số của nó và cộng các tích.    3 1i ii WnWUCs trong đó: WUCs : số lượng Ca Sử dụng đếm được sau khi đánh Trọng số ni : số lượng ca sử dụng loại thứ i (đơn giản, trung bình, phức tạp) Wi : trọng số của loại ca sử dụng thứ i Một ví dụ về việc đếm này được đưa ra như Bảng 3-2. Kiểu Ca sử dụng Mô tả Trọng số Số lượng ca sử dụng Kết quả Đơn giản Một ca sử dụng là đơn giản nếu kịch bản của nó có tới 3 giao dịch hoặc ít hơn; ta có thể thực thi hành nó với tới ít hơn 5 lớp phân tích. 5 8 40 Bình thường Một ca sử dụng là trung bình nếu kịch bản của nó có từ 4 đến 7 giao dịch; sự thi hành của nó đòi hỏi từ 5 đến 10 lớp phân tích. 10 12 120 Phức tạp Một ca sử dụng là phức tạp nếu kịch bản của nó có trên 7 giao dịch; sự thi hành của nó đòi hỏi trên 10 lớp phân tích. 15 4 60 WUCs = 220 Bảng 3-2. Ví dụ đếm số ca sử dụng sau khi đánh trọng số Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 29 Bước 2: Đếm số Tác nhân sau khi đánh Trọng số (WAs) Theo một lối quen thuộc, các Tác nhân được phân loại thành Đơn giản, Bình thường hay Phức tạp dựa trên các tương tác của chúng. Chỉ có các tác nhân cụ thể được tính, không đếm tác nhân đóng vai trò giao diện. Kiểu tác nhân Mô tả Trọng số Đơn giản Một tác nhân là đơn giản nếu nó biểu diễn một hệ thống khác với một API xác định (Application Programming Interface) 1 Bình thường Một tác nhân là trung bình nếu nó là: 1. Một tương tác với một hệ thống khác thông qua một giao thức, ví dụ TCP 2. Một tương tác con người với một giao diện dòng lệnh 2 Phức tạp Một tác nhân là phức tạp nếu nó là một tương tác con người thông qua một giao diện người dùng đồ họa 3 Bảng 3-3. Phân loại và đánh trọng số tác nhân trong UCP WAs được tính bằng cách đếm số lượng tác nhân thuộc mỗi loại, nhân số lượng mỗi loại tác nhân với trọng số của nó và cộng các tích.    3 1i ii WnWAs trong đó: WAs : tổng số lượng Tác nhân sau khi đánh Trọng số ni : số lượng tác nhân loại thứ i (đơn giản, trung bình, phức tạp) Wi : trọng số của loại tác nhân thứ i Tiếp tục ví dụ ở phần trước, đếm số lượng tác nhân sau khi đánh trọng số ở Bảng 3-4. Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 30 Kiểu tác nhân Mô tả Trọng số Số lượng tác nhân Kết quả Đơn giản Một tác nhân là đơn giản nếu nó biểu diễn một hệ thống khác với một API xác định (Application Programming Interface) 1 8 8 Bình thường Một tác nhân là trung bình nếu nó là: 3. Một tương tác với một hệ thống khác thông qua một giao thức, ví dụ TCP 4. Một tương tác con người với một giao diện dòng lệnh 2 12 24 Phức tạp Một tác nhân là phức tạp nếu nó là một tương tác con người thông qua một giao diện người dùng đồ họa 3 4 12 WAs = 44 Bảng 3-4. Ví dụ đếm số tác nhân sau khi đánh trọng số Bước 3: Tính tổng UUCPs Số Điểm Ca Sử dụng Chưa được điều chỉnh được tính bằng cách cộng số lượng Ca Sử dụng sau khi đánh Trọng số và số lượng Tác nhân sau khi đánh Trọng số. WAsWUCsUUCPs  trong đó: UUCPs: số Điểm Ca Sử dụng Chưa được điều chỉnh WUCs : số Ca Sử dụng sau khi đánh Trọng số WAs : số Tác nhân sau khi đánh Trọng số Đối với ví dụ đưa ra trong Bảng 3-2 và Bảng 3-4: UUCPs = 220 + 44 = 264 Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 31 3.2.1.2 Tính Yếu tố Độ phức tạp Kĩ thuật Điểm Ca Sử dụng Chưa được điều chỉnh sẽ được điều chỉnh bởi Yếu tố Độ phức tạp Kĩ thuật (TCF). TCF là gần tương tự như trong Phân tích Điểm Chức năng, khác biệt là tác giả đã thêm một số và bớt một số yếu tố để phù hợp với quy trình Hướng đối tượng. Ngoài ra, các yếu tố được đánh trọng số tổng quát dựa trên kinh nghiệm về tác động tương đối của mỗi yếu tố. Đối với mỗi dự án riêng lẻ, các yếu tố kĩ thuật được đánh giá bởi đội phát triển và được gán cho một tỉ lệ ảnh hưởng từ 0 đến 5 theo độ phức tạp nhận thức được (dựa vào kinh nghiệm). Các ứng dụng đa luồng thì cần nhiều kĩ năng và thời gian hơn so với các ứng dụng đơn luồng, chẳng hạn, như là làm các các ứng dụng có khả năng sử dụng lại. Một tỉ lệ bằng 0 có nghĩa là yếu tố kĩ thuật không liên quan gì tới dự án này; 3 là trung bình; 5 có nghĩa là nó có ảnh hưởng mạnh. Trọng số của mỗi yếu tố được nhân với độ phức tạp nhận thức của nó để đưa ra yếu tố tính toán của nó. Các yếu tố tính toán được cộng lại để đưa ra yếu tố tổng cộng (totalF – Total Factor). Yếu tố totalF không trực tiếp làm thay đổi UUCPs, ta đưa nó vào Yếu tố độ phức tạp kĩ thuật TCF bằng cách nhân totalF với 0.01 và cộng với 0.6. Các công thức để tính TCF:    13 1i ii WTtotalF totalFCCTCF *21  Hoặc có thể dùng công thức tổng hợp sau:    13 1 21 i ii WTCCTCF trong đó: C1= 0.6 C2= 0.01 Wi : trọng số của yếu tố kĩ thuật thứ i Ti : tỉ lệ ảnh hưởng(độ phức tạp nhận thức) của yếu tố thứ i trong dự án totalF : Yếu tố ảnh hưởng tổng cộng mặt kĩ thuật TCF : Yếu tố Độ phức tạp Kĩ thuật Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 32 Yếu tố kĩ thuật Mô tả Trọng số T1 Hệ thống phân tán 2 T2 Các mục tiêu hiệu năng ứng dụng, về mặt đáp ứng hay thông lượng 1 T3 Hiệu quả người dùng cuối (trực tuyến) 1 T4 Xử lý nội bộ phức tạp 1 T5 Tính sử dụng lại, mã phải có khả năng để dùng lại trong các ứng dụng khác 1 T6 Dễ cài đặt 0.5 T7 Dễ sử dụng 0.5 T8 Di động (portablity) 2 T9 Dễ thay đổi (Changeability) 1 T10 Đồng thời 1 T11 Các đặc điểm an ninh đặc biệt 1 T12 Cung cấp truy cập trực tiếp cho các bên thứ 3 1 T13 Các chính sách đào tạo người dùng đặc biệt 1 Bảng 3-5. Trọng số của 13 yếu tố kĩ thuật trong UCP Theo chú ý của tác giả, ([5] Karner, 1993), nếu một yếu tố không phải là quan trọng, mà cũng không phải là không liên quan, thì lấy tỉ lệ ảnh hưởng của nó là 3. Nếu tất cả các yếu tố đều có tỉ lệ ảnh hưởng là 3 thì TCF ≈ 1. Tiếp tục ví dụ đã nêu ở các phần trước, sử dụng các giá trị tỉ lệ dự án mẫu cho các yếu tố, yếu tố tổng cộng được tính như Bảng 3-6. Sau đó tính TCF. Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 33 Yếu tố kĩ thuật Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả T1 Hệ thống phân tán 2 5 10 T2 Các mục tiêu hiệu năng ứng dụng, về mặt đáp ứng hay thông lượng 1 3 3 T3 Hiệu quả người dùng cuối (trực tuyến) 1 5 5 T4 Xử lý nội bộ phức tạp 1 5 5 T5 Tính sử dụng lại, mã phải có khả năng để dùng lại trong các ứng dụng khác 1 3 3 T6 Dễ cài đặt 0.5 3 1.5 T7 Dễ sử dụng 0.5 3 1.5 T8 Di động (portablity) 2 0 0 T9 Tùy biến (Changeability) 1 5 5 T10 Đồng thời 1 0 0 T11 Các đặc điểm an ninh đặc biệt 1 5 5 T12 Cung cấp truy cập trực tiếp cho các bên thứ 3 1 0 0 T13 Các chính sách đào tạo người dùng đặc biệt 1 3 3 Yếu tố tổng cộng totalF = 42 Bảng 3-6. Ví dụ tính Yếu tố Độ phức tạp Kĩ thuật trong UCP Đối với Bảng 3-6, yếu tố tổng cộng là 42, còn Yếu tố Độ phức tạp Kĩ thuật là: TCF = 0.6 + 0.01 * 42 = 1.02 3.2.1.3 Tính Yếu tố Độ phức tạp Môi trường (ECF – Environmental Complexity Factor) Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 34 Mức độ kinh nghiệm của mỗi thành viên dự án có thể có một ảnh hưởng lớn lên quá trình phát triển dự án. Mỗi dự án được phát triển trong một môi trường và chịu ảnh hưởng của môi trường đó. Có 8 Yếu tố Môi trường được tổng quát theo nhận định kinh nghiệm. Mỗi yếu tố môi trường được đánh giá và cho trọng số tổng quát theo kinh nghiệm, Bảng 3-7. Yếu tố môi trường Mô tả Trọng số E1 Quen thuộc với UML 1.5 E2 Kinh nghiệm ứng dụng 0.5 E3 Kinh nghiệm hướng đối tượng 1 E4 Khả năng phân tích 0.5 E5 Động lực 1 E6 Các yêu cầu ổn định 2 E7 Những nhân lực bán thời gian -1 E8 Ngôn ngữ lập trình khó -1 Bảng 3-7. Trọng số của 8 yếu tố môi trường trong UCP Để đánh giá ảnh hưởng của các yếu tố trên mỗi dự án riêng lẻ, mỗi yếu tố được xét và được gán cho một tỉ lệ ảnh hưởng. Đối với các yếu tố từ E1 – E4, tỉ lệ 0 có nghĩa là không có kinh nghiệm trong dự án, 3 nghĩa là trung bình, và 5 nghĩa là thành thạo. Đối với E5, 0 nghĩa là không có động lực trong dự án, 3 nghĩa là trung bình, và 5 nghĩa là động lực lớn. Đối với E6, 0 có nghĩa là các yêu cầu không thay đổi, 3 có nghĩa là tổng số của thay đổi được mong đợi bình thường, và 5 nghĩa là các yêu cầu cực kì không ổn định. Đối với E7, 0 có nghĩa là không có nhân viên kĩ thuật bán thời gian, 3 nghĩa là khoảng một nửa của đội là bán thời gian, và 5 có nghĩa là tất cả đội là bán thời gian. Đối với E8, 0 có nghĩa là một ngôn ngữ lập trình dễ sử dụng được lên kế hoạch, 3 nghĩa là ngôn ngữ khó bình thường, và 5 nghĩa là một ngôn ngữ rất khó được lên kế hoạch cho dự án. Đối với mỗi yếu tố, nhân tỉ lệ tác động của nó với trọng số của nó từ bảng. Cộng các giá trị kết quả cùng nhau để lấy Yếu tố Tổng cộng (totalF). Yếu tố Độ phức tạp Môi trường được tính bằng cách nhân totalF với -0.03 và cộng 1.4. Các công thức để tính ECF:    8 1i ii WEtotalF totalFCCECF *21  Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 35 Hoặc có thể dùng công thức tổng hợp sau:    8 1 21 i ii WECCECF trong đó: C1= 1.4 C2= -0.03 Wi : trọng số của yếu tố môi trườngs thứ i Esi : tỉ lệ ảnh hưởng của yếu tố thứ i trong dự án totalF : Yếu tố ảnh hưởng tộng cộng mặt môi trường ECF : Yếu tố Độ phức tạp Môi trường Lại theo chú ý của tác giả, ([5] Karner, 1993), nếu một yếu tố không phải là quan trọng, mà cũng không phải là không liên quan, thì lấy tỉ lệ ảnh hưởng của nó là 3. Nếu tất cả các yếu tố đều có tỉ lệ ảnh hưởng là 3 thì ECF ≈ 1. Sử dụng các giá trị tỉ lệ dự án mẫu cho các yếu tố, yếu tố tổng cộng được tính như Bảng 3-8. Sau đó tính ECF. Yếu tố kinh nghiệm Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả E1 Quen thuộc với UML 1.5 4 6 E2 Kinh nghiệm ứng dụng 0.5 2 1 E3 Kinh nghiệm hướng đối tượng 1 4 4 E4 Khả năng phân tích 0.5 4 2 E5 Động lực 1 4 0 E6 Các yêu cầu ổn định 2 2 4 E7 Những nhân lực bán thời gian -1 0 0 E8 Ngôn ngữ lập trình khó -1 1 -1 Yếu tố tổng cộng totalF = 16 Bảng 3-8. Ví dụ tính Yếu tố Độ phức tạp Môi trường trong UCP Đối với Bảng 3-8, yếu tố tổng cộng là 16, còn Yếu tố Độ phức tạp Môi trường là: Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 36 ECF = 1.4 +(- 0.03 * 16) = 0.92 3.2.1.4 Tính số Điểm Ca Sử dụng Đây là bước cuối cùng để đưa ra kích cỡ của dự án trong một đơn vị được gọi là số Điểm Ca Sử dụng (UCPs – Use Case Points). UCPs được tính bằng biểu thức sau: ECFTCFUUCPsUCPs ** trong đó: UCPs : số Điểm Ca sử dụng UUCPs: số Điểm Ca sử dụng Chưa được điều chỉnh TCF : Yếu tố Độ phức tạp Kĩ thuật ECF : Yếu tố Độ phức tạp Môi trường Tiếp tục ví dụ đã nêu ở các phần trên. Các thừa số của công thức đã được tính, bây giờ, tổng Điểm Ca Sử dụng của dự án là: UCPs = 264 * 1.02 * 0.92 ≈ 248 3.2.2 Ước lượng nỗ lực từ số Điểm Ca Sử dụng Theo như mô tả của tác giả, ([5] Karner, 1993), từ UCPs có thể ánh xạ sang một đơn vị khác như số lượng các lớp thi hành hay LOC và từ đó ước lượng nỗ lực [người – giờ] cần thiết cho dự án với sự trợ giúp của một mô hình như COCOMO chẳng hạn. Nhưng đề nghị là không nên làm như vậy vì mô hình như COCOMO dùng sự ánh xạ không phải là tuyến tính. Qua các phép thống kê số liệu của chính tác giả, ([5] Karner, 1993), để phân tích xem bao nhiêu tài nguyên cần thiết cho mỗi UCP. Phép phân tích kết quả là xấp xỉ tuyến tính rằng mỗi UCP cần 20 [người – giờ] để hoàn thành. Điều này là một xấp xỉ đủ tốt cho hầu hết các dự án. Liên hệ giữa 2 đơn vị này chỉ có dạng đường cong của một biểu thức lũy thừa với các dự án cực lớn, khi mà năng suất làm việc ở đó thường thấp. Biến đổi Điểm Ca Sử dụng thành [người – giờ] trên mỗi UCP là một vấn đề của việc tính toán một cách sử dụng chuẩn, hay tỉ lệ nỗ lực (ER – Effort Rate), và nhân giá trị đó với số lượng UCP. Một số nghiên cứu thống kê về vấn đề này đã được tiến hành. Theo đề xuất của RoyClem, ([7] RoyClem, 2005), một số giữa 15 và 30 đựa đưa ra bởi những chuyên gia. Một giá trị điển hình là 20. Theo ([1] Carroll, 2005), kinh nghiệm của các đội kĩ nghệ của sự phối hợp Agilis Solution và FPT Software, Hanoi, Vietnam đã thiết lập tỉ lệ nỗ lực [người – giờ] dự án ở 28 [người – giờ] cho mỗi Điểm Ca Sử Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 37 dụng (28[người – giờ]/UCP). Hơn nữa, kinh nghiệm này cũng phù hợp với ([8] Schneider, 2001) ở chỗ không phải tất cả các dự án là giống nhau, từ đó phân biệt các dự án đơn giản với phức tạp bằng cách dùng 20 [người – giờ] cho mỗi Điểm Ca Sử dụng ở các dự án đơn giản. Tính tổng nỗ lực [người – giờ] bằng cách nhân UCP với tỉ lệ nỗ lực: ERUCPsttotalEffor * Cách xác định ER theo ([8] Schneider, 2001) cụ thể như sau: Đếm số lượng (count) các tỉ lệ yếu tố của E1 – E6 mà dưới 3 và số lượng các tỉ lệ yếu tố của E7 – E8 mà trên 3. Nếu tổng số count là bằng hoặc nhỏ hơn 2, thì dùng 20 người – giờ mỗi UCP. Nếu count là 3 hoặc 4, dùng 28 người – giờ cho mỗi UCP. Nếu count là 5 hoặc lớn hơn thì xem xét việc tổ chức lại đội dự án để các số giảm số lượng ít nhất nhỏ hơn 5. Một giá trị bằng hoặc lớn hơn 5 chỉ ra rằng dự án này có nguy cơ đáng kể của sự thất bại với đội dự án dự định. Tiếp tục ví dụ tính UCPs đã nêu trong phần nội dung phương pháp, đếm count = 1, chọn ER= 20, nỗ lực của dự án đã được mô tả là: 248 * 20 = 4960 [người – giờ] Các đơn vị thông dụng hơn là [người – tuần] hay [người – tháng]. Chia [người – giờ] cho 40[giờ làm việc / tuần] được đơn vị [người – tuần]. 4960 /40 = 124 [người – tuần] Chương 4 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 38 Chương 4 XÂY DỰNG CHƯƠNG TRÌNH TÍNH TOÁN HỖ TRỢ ƯỚC LƯỢNG UCP Estimator 4.1 Phát biểu bài toán Các dự án được phân tích và phát triển theo phương pháp hướng đối tượng. Cần xây dựng một chương trình để tính toán ước lượng cho dự án theo phương pháp Điểm Ca Sử dụng (UCP) như được mô tả trong cùng khóa luận. Tên của chương trình là: UCP Estimator. Chương trình được viết bằng ngôn ngữ PHP, thao tác trên hệ cơ sở dữ liệu mySQL. 4.2 Phân tích bài toán 4.2.1 Phân tích tổng thể Một dự án (Project) có thể được chia thành các Mô – đun (Module) ở các mức. Mỗi mô – đun được coi như một dự án độc lập với các mô – đun khác để thực hiện ước lượng trên mô – đun đó, một dự án tổng thể được coi như mô – đun ở mức cao nhất. Tuy vậy, chương trình chỉ thực hiện ước lượng trên một mô – đun ở một mức mà không quan tâm đến các mô – đun khác, dù ở cùng mức hay khác mức (kể các các mô – đun con). Công việc phân chia và quản lý các mô – đun là của quản trị dự án. Mỗi mô - đun có thể được Ước lượng (Estimates) nhiều lần. Các số liệu và kết quả của mỗi lần ước lượng của mỗi mô - đun phải được lưu lại như là dữ liệu lịch sử để phục vụ cho các ước lượng khác trong tương lai. Chương trình cần thực hiện được các chức năng: - Tính ước lượng mới - Tìm kiếm thông tin ước lượng cũ Chương 4 39 4.2.2 Phân tích cụ thể chức năng Quy trình tính toán của chức năng “Tính ước lượng mới” như được mô tả trong Chương 3 cùng khóa luận. Việc tìm kiếm thông tin ước lượng cũ có thể được thực hiện theo 2 cách: - Tìm kiếm trực tiếp đến Ước lượng. Người dùng mong muốn xem lại thông tin của một Ước lượng đã thực hiện. Người dùng nhập thông tin để tìm kiếm Ước lượng, chương trình trả về các Ước lượng hợp lý với từ khóa tìm kiếm. - Tìm kiếm Mô – đun: người dùng mong muốn xem lại thông tin về các ước lượng đã thực hiện của một Mô – đun. Người dùng nhập thông tin Mô – đun để tìm kiếm, chương trình trả về các Mô – đun hợp lý với từ khóa tìm kiếm 4.3 Đặc tả chương trình 4.3.1 Biểu đồ ca sử dụng của chương trình Sau đây là biểu đồ ca sử dụng tổng thể của chương trình: Hình 4-1. Biểu đồ ca sử dụng tổng thể - UCP Estimator Biểu đồ ca sử dụng tổng thể của chương trình chỉ có 2 tác nhân. Các kịch bản ca sử dụng được miêu tả như trong các biểu đồ hoạt động ở phần sau. Chương 4 40 Kịch bản ca sử dụng số 1: Tác nhân Người dùng Hệ thống Luồng sự kiện 1. Chọn thực hiện Ước lượng mới 2. Yêu cầu nhập thông tin định danh Ước lượng mới 3. Nhập thông tin định danh Ước lượng 4. Yêu cầu nhập thông tin để tính UUCPs 5. Nhập thông tin tính UUCPs 6. Yêu cầu nhập thông để tính TCF 7. Nhập thông tin tính TCF 8. Yêu cầu nhập thông để tính ECF 9. Nhập thông tin tính ECF 10. Yêu cầu nhập ER 11. Nhập ER 12. Trả về totalEffort Bảng 4-8. Kịch bản ca sử dụng “Thực hiện ước lượng mới” – UCP Estimator Kịch bản ca sử dụng số 2: Tác nhân Người dùng Hệ thống Luồng sự kiện 1. Chọn Tìm kiếm 2. Yêu cầu nhập thông tin tìm kiếm 3. Nhập thông tin tìm kiếm 4. Trả lại kết quả Bảng 4-9. Kịch bản ca sử dụng “Tìm kiếm ước lượng lịch sử” – UCP Estimator 4.3.2 Các biểu đồ hoạt động 4.3.2.1 Biểu đồ hoạt động của ca sử dụng số 1 (số được viết trong biểu đồ là số thứ tự của giao dịch ca sử dụng) Chương 4 41 Hình 4-2. Biểu đồ hoạt động của ca sử dụng "Thực hiện Ước lượng mới" - UCP Estimator 4.3.2.2 Biểu đồ hoạt động của ca sử dụng số 2 (số được viết trong biểu đồ là số thứ tự của giao dịch ca sử dụng) Hình 4-3. Biểu đồ hoạt động của ca sử dụng "Tìm kiếm Ước lược lịch sử" - UCP Estimator Chương 4 42 4.4 Thiết kế logic hoạt động cho chương trình 4.4.1 Xác định các lớp phân tích Xem xét kịch bản hoạt động trong biểu đồ hoạt động của ca sử dụng “Thực hiện Ước lượng mới”, đề xuất các lớp phân tích như sau:  Người dùng (tác nhân)  Giao diện chương trình (lớp biên)  Điều khiển quy trình ước lượng (lớp điều khiển)  Thông tin ước lượng (lớp thực thể) Xem xét kịch bản hoạt động trong biểu đồ hoạt động của ca sử dụng “Tìm kiếm ước lượng lịch sử”, đề xuất các lớp phân tích như sau:  Người dùng (tác nhân)  Giao diện chương trình (lớp biên)  Điều khiển tìm kiếm (lớp điều khiển)  Thông tin ước lượng (lớp thực thể) 4.4.2 Các biểu đồ cộng tác 4.4.2.1 Biểu đồ cộng tác cho ca sử dụng số 1 Chương 4 43 Hình 4-4. Biểu đồ cộng tác cho ca sử dụng "Thực hiện ước lượng mới" - UCP Estimator 4.4.2.2 Biểu đồ cộng tác cho ca sử dụng số 2 Hình 4-5. Biểu đồ cộng tác cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP Estimator Chương 4 44 4.4.3 Các biểu đồ tuần tự 4.4.3.1 Biểu đồ tuần tự cho ca sử dụng số 1 Hình 4-6. Biểu đồ tuần tự cho ca sử dụng "Thực hiện ước lượng mới" - UCP Estimator Chương 4 45 4.4.3.2 Biểu đồ tuần tự cho ca sử dụng số 2 Hình 4-7. Biểu đồ tuần tự cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP Estimator 4.5 Thiết kế cơ sở dữ liệu 4.5.1 Phân tích bài toán để xây dựng cơ sở dữ liệu Mỗi mô - đun có thể được Ước lượng (Estimates) nhiều lần. Các số liệu và kết quả của mỗi lần ước lượng của mỗi mô - đun phải được lưu lại như là dữ liệu lịch sử để phục vụ cho các ước lượng khác trong tương lai. Mỗi một mô – đun có thể được ước lượng nhiều lần, hay có nhiều ước lượng, nhưng mỗi một ước lượng thì chỉ dựa trên một phân tích (một tập Tác nhân, một tập Ca sử dụng) cụ thể, chỉ xét trên một đội phát triển với các yếu tố ảnh hưởng cụ thể, và chỉ xét trong một môi trường với các yếu tố ảnh hưởng cụ thể. Mỗi Loại Tác nhân (Actor_Types), mỗi Loại Ca Sử dụng (UseCase_Types), mỗi Yếu tố Kĩ thuật (Technical_Factors), mỗi Yếu tố Môi trường (Environment_Factors) được đánh trọng số trước theo phương pháp Điểm Ca Sử dụng để phục vụ cho các ước lượng. Mỗi ước lượng có một số lượng (quantity) cụ thể của mỗi loại tác nhân, có một số lượng cụ thể của một loại ca sử dụng. Mỗi ước lượng chịu ảnh hưởng của mỗi yếu tố kĩ thuật và môi trường theo một tỉ lệ (rate) xác định. Chương 4 46 Mỗi mô – đun được xác định bởi mã mô – đun, tên mô – đun, mô tả mô – đun (mod_code, mod_name, mod_description) Mỗi ước lượng được xác định bởi mã ước lượng, tên ước lượng, mô tả ước lượng (est_code, est_name, est_description) Mỗi loại tác nhân được xác định bởi bởi tên loại tác nhân, mô tả loại tác nhân, trọng số của loại tác nhân (act_type_name, act_type_description, act_type_weight) ví dụ tên loại tác nhân: Simple, Average, Complex, … Mỗi loại ca sử dụng được xác định bởi tên loại ca sử dụng, mô tả loại ca sử dụng, trọng số của loại ca sử dụng (uc_type_name, uc_type_description, uc_type_weight) ví dụ tên loại ca sử dụng: Simple, Average, Complex Mỗi yếu tố kĩ thuật được xác định bởi tên yếu tố kĩ thuật, mô tả yếu tố kĩ thuật, trọng số của yếu tố kĩ thuật (tech_factor_name, tech_factor_description, tech_factor_weight) ví dụ tên yếu tố kĩ thuât: T1, T2, T3, … Mỗi yếu tố môi trường được xác định bởi tên yếu tố môi trường, mô tả yếu tố môi trường, trọng số của yếu tố môi trường (env_factor_name, env_factor_description, env_factor_weight) ví dụ tên yếu tố môi trường: E1, E2, E3 Trong tương lai, phương pháp có thể được bổ sung thêm các loại tác nhân, các loại ca sử dụng, các yếu tố kĩ thuật, các yếu tố môi trường. 4.5.2 Xây dựng biểu dồ thực thể - liên kết (E-R) Xác định các tập thực thể: Mô – đun: Modules(mod_id, mod_code, mod_name, mod_description) Ước lượng: Estimates(est_id, est_code, est_name, est_description) Loại Tác nhân: Actor_Types(act_type_id, act_type_name, act_type_description, act_type_weight) Loại Ca Sử dụng: UseCase_Types(uc_type_id, uc_type_ name, uc_type_description, uc_type_weight) Yếu tố Kĩ thuật: Technical_Factors(tech_factor_id, tech_factor_ name, tech_factor_description, tech_factor_weight) Chương 4 47 Yếu tố Môi trường: Environment_Factors(env_factor_id, env_factor_ name, env_factor_description, env_factor_weight) Xác định các mối quan hệ: (0...n) (1...1) Modules Estimates Có (1...n) (0...n) Estimates Actors_Types Chứa quatity (số lượng tác nhân) (1...n) (0...n) Estimates UseCase_Types Chứa quatity (số lượng ca sử dụng) (1...n) (0...n) Estimates Technical_Factors Chứa rate (tỉ lệ yếu tố kĩ thuật) (1...n) (0...n) Estimates Environment_Factors Chứa rate (tỉ lệ yếu tố môi trường) Chương 4 48 Mô hình E – R: (1...n) (0...n) Environment_Factors env_factor_id Chứa rate (1...n) (0...n) Technical_Factors tech_factor_id Chứa rate (0...n) (1...1) Modules mod_id Có (0...n) (1...n) Actors_Types act_type_id Chứa quantity (0...n) (1...n) UseCase_Types uc_type_id Chứa quantity Estimates est_id 01 02 03 04 05 Hình 4-8. Biểu đồ thực thể-mối quan hệ - UPC Estimator Chương 4 49 4.5.3 Xây dựng lược đồ quan hệ Dựa vào tập thực thể và các mối quan hệ của mô hình thực thể - liên kết, ta xây dựng lược đồ quan hệ như sau: Modules(mod_id, mod_code, mod_name, mod_description) Estimates(est_id, est_code, est_name, est_description, mod_id) : xét quan hệ số 01, chuyển sang lược đồ quan hệ bằng cách thêm khóa ngoài Estimates.mod_id tham chiếu đến khóa chính Modules.mod_id Actor_Types(act_type_id, act_type_ name, act_type_description, act_type_weight) UseCase_Types(uc_type_id, uc_type_ name, uc_type_description, uc_type_weight) Technical_Factors(tech_factor_id, tech_factor_ name, tech_factor_description, tech_factor_weight) Environment_Factors(env_factor_id, env_factor_ name, env_factor_description, env_factor_weight) Actor_Type_Contained(est_id, act_type_id, quantity) : xét quan hệ số 02, chuyển sang lược đồ quan hệ bằng cách thêm vào quan hệ mới Actor_Type_Contained có khóa chính gồm 2 thành phần tham chiếu đến 2 khóa Estimates.est_id và Actor_Types.act_type_id UseCase_Type_Contained(est_id, uc_type_id, quantity) : xét quan hệ số 03, chuyển sang lược đồ quan hệ bằng cách thêm vào quan hệ mới UseCase_Type_Contained có khóa chính gồm 2 thành phần tham chiếu đến 2 khóa Estimates.est_id và UseCase_Types.uc_type_id Technical_Factor_Contained(est_id, tech_factor_id, rate) : xét quan hệ số 04, chuyển sang lược đồ quan hệ bằng cách thêm vào quan hệ mới Tech_Factor_Contained có khóa chính gồm 2 thành phần tham chiếu đến 2 khóa Estimates.est_id và Technical_Factors.tech_factor_id Environment_Factor_Contained(est_id, env_factor_id, rate) : xét quan hệ số 04, chuyển sang lược đồ quan hệ bằng cách thêm vào quan hệ mới Env_Factor_Contained có khóa chính gồm 2 thành phần Chương 4 50 tham chiếu đến 2 khóa Estimates.est_id và Environment_Factors.env_factor_id Chương 5 – Khóa luận tốt nghiệp – Nguyễn Trần Việt 51 Chương 5 ÁP DỤNG VÀ ĐÁNH GIÁ PHƯƠNG PHÁP ƯỚC LƯỢNG ĐIỂM CA SỬ DỤNG Chương này sẽ đánh giá phương pháp ước lượng Điểm Ca sử dụng về mặt lý thuyết và thực tế. Đánh giá về mặt lý thuyết thông qua so sánh với 2 phương pháp truyển thống: Điểm Chức năng và COCOMO. Đánh giá thực tế trước hết thông qua việc áp dụng phương pháp vào bài toán cụ thể. 5.1 Áp dụng thực tế Trong phần này này, em sẽ áp dụng phương pháp Điểm Ca Sử dụng vào 2 bài toán: - Dự án xây dựng máy rút tiền ATM. Việc xét dự án này giúp cho việc hiểu quy trình tính toán. - Dự án xây dựng chương trình tính toán Ước lượng – UCP Estimator – như được nêu trong Chương 4 cùng khóa luận. Việc xét dự án này là một áp dụng sâu sắc vào cách dùng phương pháp, vào các yếu tố điều chỉnh số điểm kết quả của phương pháp. 5.1.1 Bài toán số 1 – Dự án xây dựng mô–đun cho máy rút tiền ATM 5.1.1.1 Miêu tả dự án Xây dựng mô – đun hoạt động trên máy ATM có 2 chức năng Rút tiền và Chuyển tiền. Các module cần thiết khác coi như đã có sẵn. Các biểu đồ Ca sử dụng (và kịch bản), biểu đồ hoạt động của phân tích dự án được mô tả ở Phụ lục A trong cùng khóa luận. 5.1.1.2 Ước lượng kích cỡ tính số Điểm Ca Sử dụng Bước 1: Tính UUCPs Tính WUCs: Chương 5 52 Xem xét biểu đồ hoạt động của các ca sử dụng ở Phụ lục A, để xác định số giao dịch trong mỗi ca sử dụng. Các giao dịch đã được đánh số thứ tự trong biểu đồ hoạt động. - Ca sử dụng “Định danh” có 2 giao dịch - Ca sử dụng “Rút tiền” có 2 giao dịch - Ca sử dụng “Chuyển tiền” có 4 giao dịch Từ đó, căn cứ theo tiêu chuẩn xác định loại ca sử dụng của phương pháp Điểm Ca sử dụng được nêu ở Bảng 3-1, mục 3.2.1.1, ta tính toán UUCPs như sau: Kiểu Ca sử dụng Ca sử dụng Trọng số Số lượng ca sử dụng Kết quả Đơn giản 1. Định danh 2. Rút tiền 5 2 10 Bình thường 1. Chuyển tiền 10 1 10 Phức tạp 15 0 0 WUCs = 20 Bảng 5-10. Đếm WUCs - dự án ATM TínhWAs: Trong biểu đồ ca sử dụng có 1 tác nhân Khách hàng, biểu diễn 1 người tương tác với hệ thống thông qua giao diện người dùng đồ họa, thuộc loại tác nhân Phức tạp theo phân loại đưa ra trong Bảng 3-3, mục 3.2.1.1. Kiểu tác nhân Các tác nhân Trọng số Số lượng tác nhân Kết quả Đơn giản 1 0 0 Bình thường 2 0 0 Phức tạp 1. Khách hàng 3 1 3 WAs = 3 Bảng 5-2. Đếm WAs – dự án ATM Dựa vào Bảng 5-1 và Bảng 5-2, tính: UUCPs = WUCs + WAs = 20 + 3 = 23 Chương 5 53 Bước 2: Tính TCF Giả sử tất cả các yếu tố không phải là quan trọng, mà cũng không phải là không liên quan, lấy tỉ lệ ảnh hưởng của tất cả là 3. Khi đó, như trong phần giới thiệu phương pháp UCP trong cùng khóa luận, thì TCF ≈ 1. Bước 3: Tính ECF Giả sử tất cả các yếu tố không phải là quan trọng, mà cũng không phải là không liên quan, lấy tỉ lệ ảnh hưởng của tất cả là 3. Khi đó, như trong phần giới thiệu phương pháp UCP trong cùng khóa luận, thì ECF ≈ 1. Bước 4: Tính số Điểm Ca sử dụng (UCPs) UCPs = UUCPs * TCF * ECF = 23 * 1 * 1 = 23 [UCP] 5.1.1.3 Ước lượng nỗ lực Dùng tỉ lệ nỗ lực ER = 20[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là: totalEffort = UCPs * ER = 23 * 20 totalEffort = 460 [người – giờ] totalEffort = 11.5 [người – tuần] Dùng tỉ lệ nỗ lực ER = 28[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là: totalEffort = UCPs * ER = 23 * 28 totalEffort = 644 [người – giờ] totalEffort ≈ 16 [người – tuần] Từ nỗ lực này có thể dùng giá lương tổng quát theo kinh nghiệm để ước lượng chi phí nhân công của dự án. 5.1.2 Bài toán số 2 – Dự án xây dựng chương trình UCP Estimator 5.1.2.1 Miêu tả dự án Dự án thứ 2 chính là dự án xây dựng chương trình tính toán ước lượng UCP Estimator được mô tả ở Chương 4. Các phân tích bài toán và biểu đồ đã được mô tả đầy đủ ở Chương 4 Chương 5 54 5.1.2.2 Ước lượng kích cỡ tính số Điểm Ca Sử dụng Bước 1: Tính UUCPs Tính WUCs: Xem xét biểu đồ hoạt động của các ca sử dụng: - Xem xét Hình 4-2, mục 4.3.2.1, nhận thấy ca sử dụng “Thực hiện ước lượng mới” có 5 giao dịch như được đánh số thứ tự, được xếp vào loại Bình thường - Xem xét Hình 4-3, mục 4.3.2.2, nhận thấy ca sử dụng “Tìm kiếm Ước lượng lịch sử” có 2 giao dịch, được xếp vào loại Đơn giản Kiểu Ca sử dụng Các ca sử dụng Trọng số Số lượng ca sử dụng Kết quả Đơn giản 1. Tìm kiếm Ước lượng lịch sử 5 1 5 Bình thường 1. Thực hiện Ước lượng mới 10 1 10 Phức tạp 15 0 0 WUCs = 15 Bảng 5-3. Đếm WUCs - dự án UCP Estimator Tính WAs: Tác nhân “Người dùng” trong biểu đồ ca sử dụng của chương trình có vẻ như biểu diễn một người tương tác qua một giao diện đồ họa, và được xếp vào loại tác nhân Phức tạp theo UCP. Tuy vậy, trong chương trình không xây dựng tác nhân này (không có lớp thực thể biểu diễn tác nhân này), mà chỉ xây dựng các chức năng tính toán, nên sẽ không tính đến tác nhân này khi ước lượng. Chỉ đếm điểm cho tác nhân khi xây dựng một lớp đối tượng riêng để biểu diễn tác nhân với các thuộc tính (định danh, tên, số điện thoại, …) như tác nhân “Khách hàng” trong Bài toán 1 có các thuộc tính(tên, mã số thẻ, mã PIN, …). Không đếm tác nhân >, vì đó chính là hệ thống ta xây dựng. Chương 5 55 Kiểu tác nhân Các tác nhân Trọng số Số lượng tác nhân Kết quả Đơn giản 1 0 0 Bình thường 2 0 0 Phức tạp 3 0 0 WAs = 0 Bảng 5-4. Đếm WAs - dự án UCP Estimator Dựa vào Bảng 5-3 và Bảng 5-4, tính: UUCPs = WUCs + WAs = 15 + 0 = 15 Bước 2: Tính TCF Xem xét độ phức tạp mặt kĩ thuật của dự án để cho điểm ảnh hưởng(tỉ lệ dự án) của các yếu tố được đưa ra trong Bảng 3-5, mục 3.2.1.2: - T1: Hệ thống phân tán = 0 (không yêu cầu yếu tố này trong dự án) - T2: Mục tiêu hiệu năng = 0 (không cần quan tâm với một chương trình tiêu tốn ít tài nguyên đối với hệ thống máy tính hiện đại bây giờ) - T3: Hiệu quả người dùng cuối trực tuyến = 3 (trung bình) - T4: Xử lý nội bộ phức tạp = 1 (chỉ có các phép tính tuyến tính) - T5: Tính sử dụng lại mã = 4 (mô – đun ước lượng có thể được ghép cùng với mô – đun quản trị dự án) - T6: Dễ cài đặt = 3 - T7: Dễ sử dụng = 4 (chương trình phải dễ dùng) - T8: Di động(Portability) = 0 (không cần thiết) - T9: Tùy biến(changeability) = 2 (không thay đổi quy trình tính toán, có thể thay đổi các trọng số hay thêm, bớt các yếu tố - dễ thực hiện bằng cách thiết kế khéo cơ sở dữ liệu) - T10: Khả năng đồng thời = 0 (không cần thiết) Chương 5 56 - T11: Các đặc điểm an ninh đặc biệt = 0 (không cần thiết phải xây dựng trong một chương trình mô phỏng tính toán ở mức độ khóa luận) - T12: Cung cấp truy cập cho các bên thứ 3 = 0 (không xây dựng) - T13: Chính sách đào tạo người dùng đặc biêt = 1 (chương trình thực hiện tính toán theo quy trình UCP cho trước mà không thêm bước thực hiện nào cần phải tập huấn đặc biệt cho người dùng để biết cách sử dụng) Xem xét Bảng 5-5, ta có: totalF = 14 Tính TCF = C1 + C2 * totalF = 0.6 + 0.01 * 14 TCF = 0.74 Chương 5 57 Yếu tố kĩ thuật Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả T1 Hệ thống phân tán 2 0 0 T2 Các mục tiêu hiệu năng ứng dụng, về mặt đáp ứng hay thông lượng 1 0 0 T3 Hiệu quả người dùng cuối (trực tuyến) 1 3 3 T4 Xử lý nội bộ phức tạp 1 1 1 T5 Tính sử dụng lại, mã phải có khả năng để dùng lại trong các ứng dụng khác 1 4 4 T6 Dễ cài đặt 0.5 3 1 T7 Dễ sử dụng 0.5 4 2 T8 Di động (portablity) 2 0 0 T9 Tùy biến (Changeability) 1 2 2 T10 Đồng thời 1 0 0 T11 Các đặc điểm an ninh đặc biệt 1 0 0 T12 Cung cấp truy cập trực tiếp cho các bên thứ 3 1 0 0 T13 Các chính sách đào tạo người dùng đặc biệt 1 1 1 Yếu tố tổng cộng totalF = 14 Bảng 5-5. Cho điểm các Yếu tố kĩ thuật - dự án UCP Estimator Bước 3: Tính ECF Đánh tỉ lệ các yếu tố Môi trường của dự án được đưa ra trong Hình 3-7, mục 3.2.1.3. Việc cho tỉ lệ từ yếu tố E1 đến E5 chính là cho tỉ lệ của chính bản thân em – người viết khóa luận – người trực tiếp xây dựng chương trình. Chương 5 58 - E1: Quen thuộc với UML = 4 - E2: Kinh nghiệm ứng dụng = 3 - E3: Kinh nghiệm hướng đối tượng = 4 - E4: Khả năng phân tích = 4 - E5: Động lực = 5 - E6: Các yêu cầu ổn định = 5 ( không thay đổi yêu cầu trong quá trình phát triển) - E7: Nhân lực bán thời gian = 0 - E8: Ngôn ngữ lập trình khó = 4 (ngôn ngữ PHP với giao diện HTML không hỗ trợ hoàn toàn kĩ nghệ theo Hướng đối tượng) Yếu tố kinh nghiệm Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả E1 Quen thuộc với UML 1.5 4 6 E2 Kinh nghiệm ứng dụng 0.5 3 1.5 E3 Kinh nghiệm hướng đối tượng 1 4 4 E4 Khả năng phân tích 0.5 4 2 E5 Động lực 1 5 5 E6 Các yêu cầu ổn định 2 5 10 E7 Những nhân lực bán thời gian -1 0 0 E8 Ngôn ngữ lập trình khó -1 4 -4 Yếu tố tổng cộng totalF = 24.5 Bảng 5-6. Cho điểm các Yếu tố môi trường - dự án UCP Estimator Dựa vào Bảng 20 ta có: totalF = 24.5 Tính ECF = C1 + C2 * totalF = 1.4 + (-0.03 * 24.5) ECF = 0.665 Chương 5 59 Bước 4: Tính số Điểm Ca sử dụng (UCPs) UCPs = UUCPs * TCF * ECF = 15 * 0.74 * 0.665 UCPs ≈ 6.7 [UCP] 5.1.2.3 Ước lượng nỗ lực Đếm count theo cách được mô tả trong phần 3.3, được count = 0, dùng tỉ lệ nỗ lực ER = 20[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là: totalEffort = UCPs * ER = 6.7 * 20 totalEffort = 134 [người – giờ] totalEffort ≈ 3.5 [người – tuần] Giá trị nỗ lực này là cao so với một chương trình như UCP Estimator. Điều này sẽ được xem xét trong phần Đánh giá phương pháp Điểm Ca Sử dụng sau đây: 5.2 Đánh giá phương pháp 5.2.1 Đánh giá quy trình tính toán Trước hết có thể thấy rằng, UCP là phương pháp ước lượng đầu tiên dựa trên tiến trình nghiệp vụ để đưa ra kết quả. Trong khi đó, FPA chỉ dựa trên số chức năng, COCOMO dựa trên kích cỡ chương trình. Đánh giá mức độ hiệu quả của một phương pháp mới có lẽ nên so sánh với các phương pháp cũ. Phần này sẽ so sánh quy trình tính toán của phương pháp Điểm Ca Sử dụng UCP với 2 phương pháp truyền thống là Phân tích Điểm Chức năng FPA và Mô hình Giá cấu thành COCOMO. Xem xét quy trình tính toán trên các hệ thống được xây dựng theo phương pháp kĩ nghệ Hướng Đối tượng: 5.2.1.1 So sánh UCP với FPA Quy trình tính toán của phương pháp ước lượng UCP dựa trên phương pháp FPA, do đó nó thừa hưởng những ưu điểm của FPA như độc lập về mặt công nghệ và có thể đưa ra được ước lượng sớm trong vòng đời phát triển dự án, ngay sau khi có bản đặc tả ca sử dụng của hệ thống. Hơn thế, UCP khắc phục được nhiều nhược điểm cố hữu của FPA. Chương 5 60 Thứ nhất, việc đánh giá và cho điểm các Yếu tố Kĩ thuật của hệ thống được xây dựng là chi tiết hơn nhiều so với FPA khi mà các yếu tố đã được đánh trọng số ảnh hưởng tổng quát, sau đó đánh giá tỉ lệ phạm vi ảnh hưởng trên dự án, cuối cùng lấy tích để có điểm ảnh hưởng của yếu tố. Trong khi FPA lấy điểm ảnh hưởng chỉ là điểm tỉ lệ phạm vi ảnh hưởng trên dự án, có khoảng giá trị cho tất cả các yếu tố từ 0 đến 5. Thứ hai, các Yếu tố Môi trường ảnh hưởng lên tiến độ dự án đã được đưa vào quy trình tính toán. Việc đưa các Yếu tố Môi trường vào quy trình tính toán tạo ra khả năng ánh xạ tuyến tính từ đơn vị Điểm Ca Sử dụng sang [người – giờ], với các giá trị ER= 20 hay ER= 28 như được nêu ở mục 3.2.2, trong khi FPA không có khả năng này mà phải tiến hành ước lượng nỗ lực dựa trên một mô hình thuật toán như COCOMO. Thứ ba, đối với vấn đề sử dụng lại mô – đun trong Kĩ nghệ Hướng Đối tượng, FPA gặp khó khăn khi đếm số chức năng của các mô – đun thừa kế. Nhưng đối với FPA, vì dựa trên biểu đồ Ca Sử dụng, là một kí pháp của Kĩ nghệ Hướng Đối tượng, nên dễ dàng giải quyết vấn đề này với các kĩ thuật > hay >, >, >. Thứ tư, FPA đếm số lượng file thao tác logic nội bộ là một bất cập với các hệ cơ sở dữ liệu hiện đại, thì UCP đã bỏ qua việc đếm này, mà đánh giá số giao dịch ca sử dụng và có thể cụ thể hơn là đánh giá số lớp phân tích để thi hành ca sử dụng dễ dàng hơn nhiều. Thứ năm, FPA chỉ có thể ước lượng cho các ứng dụng nghiệp vụ bình thường, mà không thể cho các ứng dụng khoa học và công nghệ, khi mà độ phức tạp nằm trong nội hàm tính toán chứ không phải số lượng chức năng, thì UCP lại giải quyết được vấn đề này ở số giao dịch ca sử dụng (liên quan tới số bước tính toán). 5.2.1.2 So sánh UCP với COCOMO UCP và COCOMO có điểm giống nhau là các yếu tố điều chỉnh được xem xét điểm chi tiết và tính đến cả các yếu tố môi trường có ảnh hưởng đến tiến độ hoàn thành dự án. COCOMO là mô hình ước lượng giá cấu thành (nỗ lực và thời gian) dựa trên kích cỡ theo đơn vị LOC (line of code) của chương trình. Việc đánh giá số dòng lệnh sớm và đáng tin cậy là khó và phụ thuộc rất nhiều vào ngôn ngữ lập trình. Hơn nữa đánh giá là không phù hợp khi mã chương trình được sinh ra tự động nhờ các công cụ hiện đại chứ không phải do con người viết. Còn UCP trước hết đánh giá kích cỡ của chương trình Chương 5 61 theo đặc tả yêu cầu, rồi sau đó đánh giá nỗ lực theo một ánh xạ tuyến tính. Chỉ cần có biểu đồ ca sử dụng của đặc tả là có thể đưa ra ước lượng theo UCP. Đánh giá nỗ lực theo COCOMO có vẻ không hợp lý khi đã đồng nhất lượng tri thức ở trong một số lượng dòng lệnh giống nhau của các ngôn ngữ khác nhau, như được nêu trong mục 2.2.3. UCP thì không mắc phải vấn đề này khi đánh giá nỗ lực trực tiếp trên lượng tri thức chứa trong số Điểm Ca Sử dụng. Nỗ lực thay đổi theo ngôn ngữ đã được UCP đưa vào yếu tố môi trường Độ khó ngôn ngữ lập trình. Khi đánh giá nỗ lực theo COCOMO, phải xác định một trong ba phương thức phát triển dự án để lấy các hệ số tính toán. Việc xác định này dựa nhiều vào chủ quan và có thể gây nhầm lẫn. Trong khi đó, các hệ số của UCP là rõ ràng và không cần phải lựa chọn. 5.2.2 Đánh giá trên thực tế Xem xét việc áp dụng ước lượng trong Bài toán 2 ở phần trên có thể thấy rằng kết quả ước lượng nỗ lực cuối cùng 3.5[người – tuần] là khá cao so với một chương trình như UCP Estimator. Trong khi đó Yếu tố Môi trường ECF có giá trị 0.665 đã làm giảm đáng kể số UCPs. Nếu chỉ tính riêng kích cỡ kĩ thuật mà không xét đến các yếu tố môi trường thì UCPs = UUCPs * TCF = 15 * 0.74 ≈ 11 [UCP] Nếu chọn ER (tỉ lệ nỗ lực) = 20 [người – giờ] / UCP thì ước lượng nỗ lưc là: totalEffort = 11 * 20 = 220 [người – giờ] = 5.5 [người – tuần] Nếu chọn ER = 28 [người – giờ] / UCP thì kết quả còn cao hơn. Kết quả cao này là do việc cho điểm các Ca sử dụng và Tác nhân trong dự án này là cao hơn so với thực tế, dẫn đến UUCPs trội hơn. Việc cho điểm Ca sử dụng dựa vào phép đếm số giao dịch nhưng trong trường hợp này điểm của một giao dịch không cao như trọng số theo kinh nghiệm của phương pháp. Như vậy khi cho điểm Ca sử dụng cần thiết phải xét đến độ phức tạp của giao dịch. Thêm một vấn đề nữa, khi số giao dịch của ca sử dụng rất lớn thì nảy sinh vấn đề trong xác định loại ca sử dụng. Thí dụ, một ca sử dụng có 8 giao dịch và một ca sử dụng có 30 giao dịch đều được xếp vào loại Phức tạp với cùng trọng số. Với việc cho điểm tác nhân thì cũng có những vấn đề tương tự, nhưng vì trọng số của mỗi loại tác nhân là nhỏ nên không ảnh hưởng nhiều đến kết quả ước lượng. Chương 5 62 5.2.3 Kết luận Điểm Ca Sử dụng có tiềm năng để đưa ra những kết quả tin cậy bởi vì những ước lượng của nó được đưa ra từ các tiến trình nghiệp vụ trên thực tế, các ca sử dụng – của một hệ thống. Thêm nữa, quy trình tính toán của phương pháp Điểm Ca Sử dụng khắc phục được hầu hết các điểm yếu của những phương pháp truyền thống trong thực tế kĩ nghệ hiện nay. Tuy vậy, nhưng vì phương pháp còn chưa được hiệu chỉnh nhiều trong thực tế nên khi áp dụng cần phải chú ý một số khía cạnh: - Số lượng các bước trong một kịch bản ảnh hưởng đến ước lượng. Một số lượng lớn các bước trong một kịch bản ca sử dụng sẽ làm cho kết quả theo hướng phức tạp và gia tăng Điểm Ca Sử dụng. Một số lượng nhỏ các bước sẽ làm cho nó theo hướng đơn giản. Đôi khi, các nhóm của các bước có thể được giảm đến một số lượng ít hơn mà không ảnh hưởng đến tiến trình nghiệp vụ. Từ đó, giữ các ca sử dụng ở mức độ phức tạp hợp lý. Một giao dịch quá đơn giản có thể không cần đếm, ([2] Collasris, 2009). Khi có nhiều giao dịch trong một ca sử dụng có thể xem xét việc tách ca sử dụng. Theo kinh nghiệm áp dụng được nêu trong ([2] Collasris, 2009), khi một ca sử dụng có nhiều hơn 12 giao dịch, thì thường ca sử dụng đó hoạt động cho nhiều hơn 2 mục đích, có thể xem xét việc tách ca sử dụng để đếm như những ca sử dụng riêng lẻ. Áp dụng điểm mạnh của các kĩ thuật >, >, tổng quát hóa(generalization), thừa kế, giao diện, hiện thực hóa(realization) để điều chỉnh độ đến mức độ thích hợ độ phức tạp của các ca sử dụng. - Số lượng các tác nhân trong một ca sử dụng cũng ảnh hưởng đến ước lượng. Xem xét các tác nhân để áp dụng các kĩ thuật tổng quát hóa, thừa kế, giao diện, hiện thực hóa cho phù hợp. - Các Yếu tố điều chỉnh (Kĩ thuật và Môi trường) cần được điều chỉnh theo thời gian để phù hợp với thực tế - Yếu tố Năng suất cũng cần được điều chỉnh cho hợp lý. 5.3 Đề xuất hướng phát triển 5.3.1 Phát triển lý thuyết chương trình Chương 5 63 Quy trình tính toán của phương pháp là tốt nhưng những hệ số trọng số của các thành phần thì chưa phản ánh được đúng bản chất. Chúng được đưa ra nhờ đánh giá thống kê từ một số dự án mà chưa được kiểm nghiệm trên phạm vi rộng lớn. Khi áp dụng phương pháp cần tiến hành thống kê số liệu để phân tích và hiệu chỉnh các hệ số cho phù hợp. Một chu trình cải tiến tiến trình tính toán được đưa ra bởi ([1] Carroll, 2005) như Hình 5-1. 5.3.2 Phát triển chương trình tính toán UCP Estimator Chương trình UCP Estimator tính toán ước lượng trên mô – đun riêng lẻ. Để hỗ trọ tốt hơn cho việc quản trị dự án, chương trình UCP Estimator có thể kết hợp với một chương trình quản trị dự án. Khi đó, chương trình UCP Estimator sẽ nhận các thông tin phân tích từ chương trình quản trị để tính toán rồi trả về các ước lượng cho chương trình quản trị. Định nghĩa tiến trình Phân tích và cải thiện tiến trình Thực thi tiến trình Thu thập các số liệu Thí điểm / mở rộng Dùng các công cụ Điều khiển tiến trình thống kê Cơ sở dữ liệu tiến trình Hình 5-1. Chu trình cải tiến tiến trình UCP. Nguồn tham khảo: ([5] Carroll E. R. , 2005) Phụ lục A – Khóa luận tốt nghiệp – Nguyễn Trần Việt 64 PHỤ LỤC A. DỰ ÁN XÂY DỰNG MÔ – ĐUN ATM  Phát biểu bài toán Xây dựng mô – đun hoạt động trên máy ATM có 2 chức năng Rút tiền và Chuyển tiền. Các module cần thiết khác coi như đã có sẵn.  Biểu đồ ca sử dụng của dự án Hình 5. Biểu đồ ca sử dụng tổng thể - xây dựng mô-đun ATM Kịch bản ca sử dụng “Định danh”: Tác nhân Khách hàng Hệ thống Luồng sự kiện 1. Đưa thẻ vào máy ATM 2. Yêu cầu nhập mã PIN 3. Nhập PIN 4. Xác nhận Ngoại lệ 1. Nếu xác nhận nhập mã PIN sai tại bước 4, quay lại bước 2. 2. Nếu nhập mã PIN sai 3 lần, máy ATM giữ lại thẻ ATM Bảng 11. Kịch bản ca sử dụng “Định danh” - ATM Kịch bản ca sử dụng rút tiền: Phụ lục A 65 Tác nhân Khách hàng Hệ thống Luồng sự kiện 5. Chọn chức năng rút tiền 6. Yêu cầu nhập số tiền cần rút 7. Nhập số tiền rút 8. Xác nhận 9. Trả tiền Ngoại lệ 1. Nếu xác nhận thấy số tiền rút được nhập không hợp lệ tại bước 4, thì thông báo lỗi và quay lại bước 2 Bảng 2. Kịch bản ca sử dụng “Rút tiền” - ATM Kịch bản ca sử dụng “Chuyển tiền”: Tác nhân Khách hàng Hệ thống Luồng sự kiện 13. Chọn chức năng Chuyển tiền 14. Yêu cầu nhập số tiền cần chuyển 15. Nhập số tiền chuyển 16. Xác nhận số tiền 17. Yêu cầu nhập thông tin tài khoản đến 18. Nhập thông tin tài khoản đến 19. Kiểm tra thông tin 20. Yêu cầu xác nhận thông tin tài khoản đến 21. Chấp nhận thông tin tài khoản đến 22. Xác nhận chấp nhận 23. Thực hiển chuyển tiền Ngoại lệ 1. Nếu xác nhận thấy số tiền chuyển được nhập không hợp lệ tại bước 4, thì thông báo lỗi và quay lại bước 2 2. Nếu kiểm tra ở bước 7 thấy thông tin khách hàng nhập vào không hợp lệ, quay lại bước 5 3. Nếu khách hàng không chấp nhận ở bước 9, thì ở bước 10 quay lại bước 5 Bảng 3. Kịch bản ca sử dụng “Chuyển tiền” - ATM Phụ lục A 66  Các biểu đồ hoạt động Biểu đồ hoạt động của ca sử dụng “Định danh”: Hình 6. Biểu đồ hoạt động ca sử dụng "Định danh" - dự án ATM Biểu đồ hoạt động của ca sử dụng “Rút tiền”: Phụ lục A 67 Hình 7. Biểu đồ hoạt động ca sử dụng "Rút tiền" - dự án ATM Biểu đồ hoạt động của ca sử dụng “Chuyển tiền”: Phụ lục A 68 Hình 8. Biểu đồ hoạt động ca sử dụng "Chuyển tiền" - dự án ATM TÀI LIỆU THAM KHẢO Khối tiếng nước ngoài: [1] Carroll E. R. (2005). Estimating software based on use case points. ACM New York, NY, USA, 2005. [2] Collaris R. A., Dekker E. (2009). Software cost estimation using use case points: Getting use case transactions straight. IBM, 2009. [3] Hewson G., Peters K. (2007). Fundamentals of Software Project Estimation. Software Productivity Center, Inc, 2007. [4] Jacobson I., Booch G., Rumbaugh J. (2005).The Unified Modeling Language User Guide, 2nd edition. Addison Wesley Professional, 2005. [5] Karner G. (1993). Resource Estimation for Objectory Projects. Objective Systems SF AB, 1993. [6] McConnell S. (1996). Rapid Development. Taming Wild Software Schedules, Microsoft Press, 1996, p.163 – 204. [7] RoyClem (2005). Project Estimation with Use Case Points. The Code Project website, 2005. [8] Schneider G., Winters J. P. (2001). Applying Use Cases, A Practical Guide, 2nd edition. Addison – Wesley, 2001. [9] Symons C. R. (1988). Function Point Analysis : Difficulties and improvements. IEEE Transactions on Software Engineering, 1988. [10] What Is Parkinson’s Law in Project Management?. 2010. management.html Khối tiếng Việt Nam: [11] Trương Ninh Thuận (2009). Slide bài giảng môn “Kỹ nghệ phần mềm” cho lớp K51CD. Bộ môn Công nghệ phần mềm, 2009. Chương 3b. [12] Nguyễn Văn Vỵ, Nguyễn Việt Hà (2008). Giáo trình Kĩ nghệ Phần mềm. NXB Đại học Quốc gia Hà Nội, 2008. [13] Nguyễn Văn Vỵ. Phân tích, thiết kế các hệ thống thông tin hiện đại, hướng cấu trúc và hướng đối tượng. NXB Thống kê. 2002.