Chương 3 – Ước lượng chi phí phần mềm

NHẬP MễN CễNG NGHỆ PHẦN MỀM 1 CHƯƠNG 3 – ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM Nội dung
Giới thiệu
Ước l−ợng kích th−ớc phần mềm
Ước l−ợng chi phí phần mềm 2 Giới thiệu
Các yếu tố cần −ớc l−ợng
Kích th−ớc phần mềm
Công sức phát triển
Thời gian thực hiện 3
Số ng−ời tham gia
Nguyên tắc −ớc l−ợng
Phân rã chức năng
Ước l−ợng từng chức năng
Dựa trên kinh nghiệm, dữ kiện quá khứ Ước lượng kớch thước phần mềm
Ước l−ợng kích th−ớc phần mềm
Qua dòng lệnh (LOCKDSI): Ước l−ợng trực tiếp với từng module 4
Qua điểm chức năng (FP): Ước l−ợng gián tiếp thông qua −ớc l−ợng input/output, yêu cầu,… Ước lượng kớch thước phần mềm
Qua dòng lệnh
Theo đơn vị một dòng lệnh LOC (Lines Of Code)
Theo đơn vị một ngàn dòng lệnh KDSI (Thousand Delivered Source of Code) 5
Phụ thuộc ngôn ngữ lập trình Ước lượng kớch thước phần mềm
Các vấn đề gặp phải với các ph−ơng pháp LOC và KDSI
Tính toán kích th−ớc cho các giai đoạn khác: phân tích yêu cầu, … 6
Cài đặt trên các ngôn ngữ lập trình khác nhau: C, Java, Lisp,…
Cách tính số dòng mã lệnh: mã lệnh thực thi, định nghĩa dữ liệu,…
Sinh mã tự động, thiết kế giao diện trực tiếp (GUI)
Giá thành của sản phẩm phụ thuộc vào −ớc l−ợng LOC Ước lượng kớch thước phần mềm
Qua điểm chức năng (FP - Functional Points)
Độc lập với ngôn ngữ lập trình
Các điểm chức năng:
Input Item (Inp): Số input 7
Output Item (Oup): Số output
Inquiry (Inq): Số yêu cầu
Master File (Maf) : Số tập tin truy cập
Interface (Inf): Số giao diện Ước lượng kớch thước phần mềm
Bảng giá trị các điểm chức năng theo độ phức tạp từ thấp, trung bình đến cao 8
Công thức tính số điểm chức năng thô UFP = a1 x Inp + a2 xOup + a3 x Inq + a4 xMaf + a5 x Inf với a1, a2, a3, a4, a5 là giá trị các điểm chức năng theo độ phức tạp cho trong bảng trên. Ước lượng kớch thước phần mềm
Ví dụ: Tính điểm chức năng thô UFP theo độ phức tạp trung bình khi thực hiện hàm tìm −ớc chung lớn nhất của hai số nguyên? 9 Inp = 2 Inq = 1 Inf = 0 Oup = 1 Maf = 0 UFP = 4Inp + 5Oup + 4Inq + 10Maf + 7Inf = 17 Ước lượng kớch thước phần mềm
Công thức tính điểm chức năng FP FP = Điểm chức năng thô x (0.65 + 0.01 x Tổng các mức độ ảnh h−ởng của các hệ số kỹ thuật )
Các hệ số kỹ thuật (có mức độ ảnh h−ởng nằm trong phạm vi từ 0 (không quan trọng hay không thích hợp hay không ảnh 10 h−ởng) tới 5 (cực kỳ quan trọng hay cần thiết tuyệt đối hay ảnh h−ởng nhất) 1. Trao đỗi dữ liệu (Data communication) 2. Chức năng phõn bố (Distributed function) 3. Hiệu suất (Performance) 4. Đặt nặng về cấu hỡnh tiện ớch (Heavily used configuration) 5. Tỷ lệ giao tỏc (Transaction rate) Ước lượng kớch thước phần mềm
Các nhân tố kỹ thuật 6. Trao đổi dữ liệu trực tuyến (Online data entry) 7. Màn hỡnh nhập liệu hiệu quả (End-user efficiency) 8. Cập nhật trực tuyến (Online update) 11 9. Xử lý phức tạp Complex processing 10. Sử dụng lại (Reusability) 11. Dễ cài đặt (Installation ease) 12. Dễ thao tỏc (Operation ease) 13. Được cài đặt ở nhiều tổ chức (Multiple site) 14. Thuận lợi cho thay đổ (Facilitate change) Ước lượng kớch thước phần mềm
Điểm chức năng FP có thể đ−ợc dùng để dự đoán số dòng lệnh LOC LOC = AVC * số điểm chức năng FP với AVC : yếu tố phụ thuộc vào ngôn ngữ lập trình đ−ợc sử dụng 12 Bảng cung cấp các dự đoán thô về LOC trung bình đ−ợc yêu cầu để xây dựng một điểm chức năng ở các ngôn ngữ lập trình cấp cao Ước lượng chi phớ phần mềm
Ước l−ợng chi phí
Dựa trên kích th−ớc, độ phức tạp
Dựa vào dữ liệu quá khứ Chi phớ tỉ lệ với cụng sức (effort) phỏt triển phần mềm 13

Chi phớ tớnh dựa theo cụng sức cho cỏc giai đoạn phỏt triểm phần mềm: khởi đầu, phõn tớch, thiết kế, cài đặt, kiểm thử nhưng chưa tớnh đến giai đoạn bảo trỡ.
Đơn vị tớnh của cụng sức: người-thỏng (hoặc người- ngày) Ước lượng chi phớ phần mềm
Các ph−ơng pháp −ớc l−ợng chi phí phần mềm
Theo ý kiến của chuyên gia
Theo giải thuật Bằng sự t−ơng tự 14

Bằng luật Parkinson
Pricing to win
Thực hiện các ph−ơng pháp −ớc l−ợng trên theo cách từ trên xuống hoặc từ d−ới lên Tự đọc Ước lượng chi phớ phần mềm
Ước l−ợng theo từ trên xuống ( top-down estimation)
Từ trên xuống (top – down): Khởi đầu tại mức hệ thống và đánh giá toàn thể chức năng hệ thống và cách thức chức năng này đ−ợc phân phối thông qua các hệ 15 thống con.
Có thể sử dụng mà không có kiến thức về kiến trúc hệ thống và các thành phần của hệ thống
Cần phải tính tới các chi phí nh− tích hợp, quản lý cấu hình và tài liệu
Có thể đánh giá không đúng mức chi phí giải quyết các vấn đề kỹ thuật mức thấp Ước lượng chi phớ phần mềm
Ước l−ợng theo từ d−ới lên ( bottom - up estimation)
Từ d−ới lên (bottom - up): Khởi đầu tại mức thành phần (bộ phận của hệ thống) và −ớc l−ợng chi phí cho từng thành phần. Cộng tất cả các chi phí thành phần này để 16 có đ−ợc −ớc l−ợng cuối cùng.
Có thể sử dụng khi kiến trúc hệ thống đ−ợc biết và các thành phần của hệ thống đã xác định
Ph−ơng pháp này chính xác nếu hệ thống đ−ợc thiết kế một cách chi tiết
Có thể đánh giá không đúng mức chi phí cho các hoạt động mức hệ thống nh− tích hợp và tài liệu Ước lượng chi phớ phần mềm
í kiến của chuyên gia (expert judgment)
Một hay nhiều chuyên gia trong cả lĩnh vực ứng dụng và phát triển phần mềm sử dụng kinh nghiệm của họ để dự tính chi phí phần mềm. Qui trình này đ−ợc lặp đi lặp lại cho đến khi đạt đ−ợc sự nhất trí. 17
Thuận lợi: Ph−ơng pháp dự đoán chi phí thấp một cách t−ơng đối. Có thể chính xác nếu các chuyên gia có kinh nghiệm trực tiếp trong các hệ thống t−ơng tự.
Khó khăn: Rất thiếu chính xác nếu không có các chuyên gia thực sự! Ước lượng chi phớ phần mềm
Ước l−ợng chi phí theo giải thuật
Các mô hình −ớc l−ợng chi phí theo giải thuật
Mô hình Walston và Felix Mô hình Bailey và Basili 18

Mô hình COCOMO Mụ hỡnh Walston và Felix
Một trong các mô hình giải thuật sớm nhất (1977)
Mô hình đ−ợc đề nghị sau khi nghiên cứu 60 dự án của IBM
Có 29 yếu tố ảnh h−ởng tới hiệu suất 19
Công thức −ớc l−ợng công sức E E = 5.25 x S 0.91 (ng−ời - tháng) Với S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo đơn vị ngàn dòng lệnh)
Công thức −ớc l−ợng thời gian thực hiện T= 2.5 x E0.35 (tháng) Mụ hỡnh Walston và Felix
Mỗi yếu tố sẽ nhận 1 trong 3 giá trị tùy thuộc vào sự tác động của nó tới hiệu suất
1 (cao): làm tăng hiệu suất 0 (trung bình): không ảnh h−ởng tới hiệu suất 20

-1 (thấp): làm giảm hiệu suất Mụ hỡnh Walston và Felix 1. Customer interface complexity 16. Use of design and code inspections 2. User participation in requirements definition 17. Use of top-down development 3. Customer-originated program design changes 18. Use of a chief programmer team 4. Customer experience with the application area 19. Overall complexity of code 5. Overall personnel experience 20. Complexity of application processing 6. Percentage of development programmers who participated in the design of functional specifications 21. Complexity of program flow 7. Previous experience with the operational computer 22. Overall constraints on program’s design 8. Previous experience with the programming language 23. Design constraints on the program’s main storage 21 9. Previous experience with applications of similar size and complexity 24. Design constraints on the program’s timing 10. Ratio of average staff size to project duration (people per month) 25. Code for real-time or interactive operation or for execution under severe time constraints 11. Hardware under concurrent development 26. Percentage of code for delivery 12. Access to development computer open under special request 27. Code classified as nonmathematical application and input/output formatting programs 13. Access to development computer closed 28. Number of classes of items in the database per 1000 lines of code 14. Classified security environment for computer and at least 25% of programs and data 29. Number of pages of delivered documentation per 1000 lines of code 15. Use of structured programming Mụ hỡnh Bailey và Felix
Mô hình đ−ợc đề nghị năm 1981 bởi Bailey và Felix
Mô hình này sử dụng cơ sở dữ liệu của 18 dự án viết bằng ngôn ngữ Fortran tại trung tâm Goddard Space Flight của NASA 22
Các nhóm yếu tố ảnh h−ởng tới công sức: ph−ơng pháp, độ phức tạp và kinh nghiệm
Công thức −ớc l−ợng công sức ban đầu E E = 5.5 + 0.73xS 1.16 (ng−ời - tháng) Với S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống Mụ hỡnh Bailey và Felix
Mỗi yếu tố ảnh h−ởng tới công sức nhận một trong các giá trị từ 0 đến 5 Total methodology (METH) Cumulative complexity (CPLX) Cumulative experience (EXP) Tree charts Customer interface Programmer 23 complexity qualifications Top-down design Application complexity Programmer machine experience Formal documentation Program flow complexity Programmer language experience Chief programmer teams Internal communication complexity Programmer application experience Formal training Database complexity Team experience Formal test plans External communication complexity Design formalisms Customer-initiated program design changes Code reading Unit development folders Mụ hỡnh COCOMO 81
Mô hình COCOMO 81 đ−ợc đề nghị bởi Boehm
Dạng cơ bản: ỏp dụng cho nhúm nhỏ, mụi trường quen thuộc
Dạng trung bỡnh: ỏp dụng cho dự ỏn khỏ lớn, cú một ớt 24 kinh nghiệm
Dạng lớn: ỏp dụng cho dự ỏn lớn, mụi trường mới
Bảng mức độ khú khi phỏt triển sản phẩm Mụ hỡnh COCOMO 81
Công sức E = ab x S^bb x EAF
ab và bb: đ−ợc xác định dựa vào bảng mức độ khó khi phát triển phần mềm
EAF (effort adjustment factor): hệ số hiệu 25 chỉnh công sức. Nó đ−ợc tính bằng tích của các hệ số phát triển
S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo đơn vị ngàn dòng lệnh)
Thời gian T = cb x E^db Mụ hỡnh COCOMO 81
Các hệ số phát triển 26 Mụ hỡnh COCOMO 2
Mô hình COCOMO 81 đ−ợc phát triển trên giả thiết rằng tiến trình phát triển phần mềm thác n−ớc đ−ợc sử dụng và tất cả các phần mềm đ−ợc phát triển từ đầu. 27
Mô hình COCOMO 2 đ−ợc thiết kế để thích ứng với những cách tiếp cận khác nhau đối với sự phát triển phần mềm Mụ hỡnh COCOMO 2
COCOMO 2 kết hợp chặt chẽ các mô hình con nhằm đ−a ra các dự đoán phần mềm chi tiết
Các mô hình con trong COCOMO 2 là:
Mô hình Application composition: đ−ợc sử dụng khi phần mềm đ−ợc tạo thành từ các thành phần hiện có 28
Mô hình Early design: đ−ợc sử dụng khi các yêu cầu là sẵn có nh−ng thiết kế vẫn ch−a đ−ợc bắt đầu
Mô hình Reuse: đ−ợc sử dụng để tính công sức tích hợp các thành phần có thể dùng lại đ−ợc
Mô hình Post-architecture: đ−ợc sử dụng ngay khi kiến trúc hệ thống đã đ−ợc thiết kế và các thông tin chi tiết hơn về hệ thống là sẵn có Mụ hỡnh COCOMO 2 29 Mụ hỡnh Application composition
Hỗ trợ các dự án bản mẫu và các dự án có sự tái sử dụng nhiều
Đ−ợc dựa trên số l−ợng điểm ứng dụng (đối t−ợng)
Công thức −ớc l−ợng 30
Công sức E = ( NAP x (1 - %reuse/100 ) ) / PROD (ng−ời – tháng)
NAP: số l−ợng điểm ứng dụng
PROD: hiệu suất. Nó phụ thuộc vào kinh nghiệm và khả năng của nhà phát triển cũng nh− tính tr−ởng thành và khả năng của công cụ Mụ hỡnh Application composition
Bảng xác định hiệu suất 31 Mụ hỡnh Application composition
Số l−ợng điểm ứng dụng phụ thuộc vào:
Các màn hình riêng biệt đ−ợc hiển thị
Các báo cáo đ−ợc sinh ra bởi hệ thống 32
Các module ch−ơng trình (đ−ợc viết bằng các ngôn ngữ lập trình nh− Java, C++, v.v) phải đ−ợc phát triển để bổ sung cho mã lệnh lập trình cơ sở dữ liệu Mụ hỡnh Application composition
Tính số l−ợng điểm ứng dụng
Đếm số l−ợng màn hình, báo cáo và module
Xác định độ phức tạp cho từng thành phần (1 màn hình hay 1 báo cáo hay 1 module) theo bảng sau 33 8 + medium difficult difficult 4 + medium difficult difficult For Screens For Reports Number and source of data tables Number and source of data tables Number of views contained Total < 4 (<2 server, <3 client) Total < 8 (2-3 server, 3-5 client) Total 8+ (>3 server, >5 client) Number of sections contained Total < 4 (<2 server, <3 client) Total < 8 (2-3 server, 3- 5 client) Total 8+ (>3 server, >5 client) <3 simple simple medium 0 or 1 simple simple medium 3 - 7 simple medium difficult 2 or 3 simple medium difficult Mụ hỡnh Application composition
Tính số điểm ứng dụng cho từng thành phần khi đã biết độ phức tạp theo bảng d−ới đây Object type Simple Medium Difficult Screen 1 2 3 Report 2 5 8 34
Tính tổng số điểm ứng dụng cho tất cả các thành phần 3GL component - - 10 Mụ hỡnh Early design
Các −ớc l−ợng có thể đ−ợc tạo ra sau khi các yêu cầu đ−ợc chấp nhận
Công thức −ớc l−ợng
Công sức E = a x Sb x M với 35
M: tích của 7 hệ số nhân
a = 2.94
S kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo đơn vị ngàn dòng lệnh)
b thay đổi trong khoảng 1.1 tới 1.24 tùy thuộc vào tính mới của hệ thống, tính linh động trong phát triển, các ph−ơng pháp quản lý rủi ro và tính tr−ởng thành của tiến trình Mụ hỡnh Early design
Các hệ số nhân phản ánh khả năng của nhà phát triển, các yêu cầu phi chức năng, sự hiểu biết rõ về nền tảng phát triển, v.v.
RCPX - product reliability and complexity
RUSE - the reuse required 36
PDIF - platform difficulty
PREX - personnel experience
PERS - personnel capability
SCED - required schedule
FCIL - the team support facilities
Giá trị của các hệ số này nằm trong khoảng từ 1 (rất thấp) đến 6 (rất cao) Mụ hỡnh reuse
Đ−a vào mã lệnh hộp đen đ−ợc tái sử dụng mà không cần thay đổi và mã cần phải đ−ợc sửa lại để tích hợp nó vào mã lệnh mới
Hai loại tái sử dụng: 37
Tái sử dụng hộp đen: mã lệnh không đ−ợc sửa đổi. Công sức phát triển cho mã hộp đen đ−ợc tính là 0
Tái sử dụng hộp trắng: mã lệnh đ−ợc chỉnh sửa để nó có thể hoạt động trong hệ thống mới một cách chính xác. Một số công sức phát triển đ−ợc cần đến. Mụ hỡnh reuse
Nhiều hệ thống còn bao gồm các mã lệnh đ−ợc sinh ra một cách tự động từ các bộ dịch ch−ơng trình (một dạng tái sử dụng)
Dự đoán công sức để tích hợp mã lệnh đ−ợc sinh ra tự động: E= (ASLOC * AT/100)/ATPROD 38
ASLOC: số dòng mã lệnh trong các thành phần mà chúng đ−ợc sửa lại cho phù hợp
AT: tỷ lệ phần trăm của mã lệnh đ−ợc sinh tự động
ATPROD: hiệu suất của các kỹ s− trong việc tích hợp mã lệnh này Mụ hỡnh Reuse
Dự đoán công sức để tích hợp các mã lệnh mới và các thành phần tái sử dụng hộp trắng:
Không dự đoán công sức trực tiếp mà qua số dòng mã nguồn mới ESLOC = ASLOC * (1-AT/100) * AAM 39
ESLOC: số dòng mã nguồn mới t−ơng đ−ơng
ASLOC và AT nh− tr−ớc
AAM: hệ số nhân hiệu chỉnh sự thích ứng từ các chi phí của việc thay đổi mã lệnh tái sử dụng, các chi phí để hiểu cách tích hợp mã lệnh và các chi phí để ra quyết định tái sử dụng Mụ hỡnh Post-architecture
Sử dụng cùng một công thức nh− mô hình early design nh−ng có tới 17 hệ số nhân
Công sức E = a x Sb x M với
M: tích của 17 hệ số nhân 40
a = 2.94
S kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo đơn vị ngàn dòng lệnh)
b = 1.01 + 0.01 x ∑Wi với Wi là hệ số có giá trị biến đổi từ 5 (rất thấp) tới 0 (cực kỳ cao) Mụ hỡnh Post- architecture
17 hệ số nhân M 41 Mụ hỡnh Post-architecture
Kích th−ớc mã lệnh S trong mô hình này đ−ợc tính bằng cách cộng ba −ớc l−ợng d−ới đây:
Sự −ớc l−ợng về số dòng mã nguồn mới đ−ợc phát triển
Sự −ớc l−ợng về số dòng mã nguồn t−ơng đ−ơng đ−ợc 42 tính bằng cách sử dụng mô hình reuse
Sự −ớc l−ợng về số dòng mã lệnh phải đ−ợc sửa đổi theo các thay đổi về yêu cầu Mụ hỡnh Post-architecture
Các hệ số W 43 Mụ hỡnh Post-architecture
Các hệ số W 44