TỔNG QUAN VỀ
Đối tượng ước lượng và các phương pháp xác định
Mỗi phần mềm đều có rất nhiều thuộc tính đặc trưng mà có thể là đối tượng để đo, để ước lượng như: kích cỡ, độ phức tạp, độ tin cậy, chất lượng, tính khả dụng Do đó để xây dựng một chương trình đo, ước lượng phần mềm tốt cần xác định rõ các mục tiêu của dự án cũng như của tổ chức phát triển phần mềm Các câu hỏi cần được trả lời như:
Đối tượng của các phép đo là gì?
Mục tiêu kỳ vọng về sản phẩm, quy trình, các nguồn phát triển sau các phép đo?
Những độ đo nào thể hiện các mục tiêu đó có đạt được hay không.
Sau đây ta sẽ nghiên cứu một số phương pháp xác định mục tiêu:
1 Phương pháp 1: Hướng tiếp cận các độ đo câu hỏi mục tiêu
(Goal Question Metrics Approach GQM)
GQM là một hướng tiếp cận đc Basilieta đưa ra và được chấp nhận rộng rãi như một cấu trúc có giá trị để giải đáp cho câu hỏi "đo lường cái gì".Nói tóm lược, GQM đưa ra định nghĩa về các thông số đo lường chương trình theo một cấu trúc top down như sau: a Xác định mục tiêu của sản phẩm, tiến trình, và của nguồn _ đây là các mục tiêu mà khách hàng của các độ đo hướng tới. b Làm rõ những câu hỏi về đặc trưng cách đánh giá phương thức gặt hái những thành tựu. c Định nghĩa các độ đo để cung cấp các câu trả lời mang tính số lượng cho từng câu hỏi.Các độ đo có thể là khách quan (nếu chỉ dựa thuần túy vào đối tượng được đo) hoặc là chủ quan (nếu dựa vào cả quan điểm đo lường và đối tượng đo).
Xét ví dụ: Ta hãy để ý sự chuyển giao một sản phẩm phần mềm: Người quản lý sản phẩm/dự án, có thể có những mục tiêu sau cho sản phẩm:
* Mục tiêu là chuyển giao một sản phẩm phần mềm đạt các mong đợi về chức năng của khách hàng => câu hỏi cần đặt ra là phần mềm chuyển giao cho khách hàng kia đã thay đổi bao nhiêu so với yêu cầu của khách hàng Một độ đo cần sử dụng để trả lời cho câu hỏi đó là: Số những khiếm khuyết phần mềm được đếm Thông thường, luôn có những thỏa thuận về việc hình thành các khiếm khuyết, các nhược điểm, thường là dựa trên sự vận hành của phần mềm đã thay đổi trong sự thỏa thuận chặt chẽ của yêu cầu Các yêu cầu càng rõ ràng, thì các độ đo càng khách quan Ở đây ta cũng có thể sử dụng một độ đo khác: Là mức độ thỏa mãn của khách hàng dựa theo một số biểu mẫu khảo sát _ Đây là một độ đo chủ quan, hoàn toàn dựa vào quan điểm của khách hàng.
2 Phương pháp 2: Mô hình tạo quyết định
Một phương thức thứ nữa để tập hợp các độ đo là tập trung vào việc đưa ra các quyết định của dự án Các bộ tạo quyết định chính là khách hàng của các độ đo, mà các độ đo được tạo ra để làm tiện dụng cho các thông tin tới các bộ quyết định Trong phương thức này ta cần xác định yêu cầu của bộ tạo quyết định là gì, nhận diện được tác dụng của chúng Phương thức này hoàn toàn gắn kết chặt chẽ với GQM với sự chú trọng tới những quyết định được tạo ra như hình 2.1
Hiểu được các quyết định được tạo ra sẽ giúp cho đặt đúng chỗ việc đo lường dự án hỗ trợ cho việc đưa ra các quyết định Ví dụ: Một quản lý dự án cần đưa ra quyết định phân bố nguồn dựa trên tình trạng hiện thời với mối tương quan của tiến trình dự kiến. Anh ta cần tính toán về thời gian và cả nỗ lực/nhân lực trong cả vòng đời phát triển. Một người quản lý kiểm thử cần xác đĩnh xem chất lượng của sản phẩm phần mềm có đạt được mức có thể chấp nhận được để chuyển giao cho khác hàng không, do đó anh ta cần đo lường chất lượng hiện tại của sản phẩm và một cái nhìn tổng quan sau thời gian chỉnh sửa.
Trong phương thức này, cần xem nhu cầu của việc đưa ra các quyết định để xác định các độ đo cần dùng.
3 Phương pháp 3: Các độ đo các hệ số chuẩn
Có những tập hợp các độ đo tiêu chuẩn chung cho công nghệ phần mềm cũng như cho các ứng dụng chuyên biệt Và một số tổ chức đã sử dụng chúng như chuẩn mực cho các bộ đo chương trình của họ Một ví dụ là mô hình phần mềm chính xác của Viện công nghệ phần mềm SEI (Software Engineering Institute) yêu cầu sự đo lường về kích cỡ hệ thống, thời gian dự án, mức công sức, và những lỗ hổng của phần mềm Họ tích hợp những đơn vị đo này với những yêu cầu tiến trình để hỗ trợ cho việc Quản lý dự án và Cải thiện liên tục Cùng với năng suất, chúng ta coi tập hợp độ đo của SEI như tập hợp gọn nhất cho tổ chức đó là : Kích cỡ hệ thống, thời gian dự án, nhân lực, lỗ hổng, năng suất.
Mỗi kỹ nghệ khác nhau cần có nhưng tiêu chuẩn riêng về độ đo, độ tin cậy và an toàn.
Ví dụ: Trong công nghệ truyền thông, có tiêu chuẩn TL9000 có định nghĩa dài về độ đo mà các nhà cung cấp phần mềm phải có và cung cấp cho khách hàng Còn trong công nghệ hạt nhân EIC60880:1986-09 định nghĩa các tiêu chuẩn và độ đo cho "Phần mềm cho máy tính trong hệ thống an toàn của trung tâm năng lượng hạt nhân".
Tóm lại trong phương thức này, ta cần quan tâm tới cả các tiêu chuẩn chung và các tiêu chuẩn đặc trưng cho từng kỹ nghệ để lựa chọn các độ đo cho phù hợp.
4 Phương pháp 4: Mở rộng GQM: Độ đo kỹ xảo
(Extension to GQM: Metric Mechanism)
Một điều quan trọng cần bổ sung vào các hướng tiếp cận trên cần quan tâm Kỹ xảo để thu thập các dữ liệu về độ đo cần hiểu thấu đáo và thống nhất trước khi đưa vào ứng dụng trong chương trình Trong sự chấp thuận với những tiền đề của Basili, ta thêm kỹ xảo vào GQM để có đc GQM2 như sau:
* Kỹ xảo (Mechanism): Bao gồm việc xác định ai sẽ chịu trách nhiệm bảo đảm việc thu thập và báo cáo các dữ liệu xác thực, tần xuất thu thập dữ liệu, tần xuất báo cáo dữ liệu, và cơ sở hạ tầng (như các công cụ, nguồn nhân viên ) cần để thu thập và báo cáo dữ liệu.
Thất bại trong việc hiểu và thống nhất trong "Kỹ xảo" có thể dẫn tới rất nhiều thất bại trong những độ đo chương trình: Dữ liệu không hoàn thiện hoặc không chuẩn xác là do không có ai đảm bảo cho nó phải có kịp lúc và đúng kiểu Dữ liệu cũ, và không còn hữu dụng cho những quyết định hiện thời Dữ liệu không có sẵn sàng khi cần tới Ngân sách dự án bị thiếu hụt do chi phí cho cơ sở hạ tầng của độ đo chương trình Kế hoạch dự án bị phá vớ do không có kế hoạch thời gian dự trù và xác thực.
Kỹ xảo cho độ đo khiếm khuyết: Chủ sở hữu=Quản lý dịch vụ khách hàng, tần xuất thu thập= lỗ hổng xuất hiện, tần xuất báo cáo= hàng tháng, cơ sở vật chất= hệ thống công cụ khách hàng hiện có và 0,25 nhân viên văn phòng
Kỹ xảo cho độ đo thỏa dụng khách hàng: Chủ sở hữu = quản lý sản phẩm, tần xuất thu thập= sau khi chuyển giao từng phần chính của phần mềm, tần xuất báo cáo = quý, cơ sở hạ tầng = khảo sát khách hàng đã có trong từng lần chuyển giao và 0.1 quản lý sản phẩm
5 Đối tượng đo lường là một chức năng của thời gian
Một đặc điểm của bất cứ độ đo chương trình nào là chúng đều có chức năng của thời gian trong ba hình thức:
Đối tượng đo lường biến đổi dựa trên vị trí hiện thời trong sự phát triển phần mềm và vòng đời sản phẩm phần mềm Ví dụ, các độ đo kiểm tra mã nguồn được thu thập và kiểm soát trong suốt thời gian phát triển mã lệnh của vòng đời Trong pha kiểm thử, thời gian phát triển để chuyển giao những vá lỗi có thể đồng nhất với nhu cầu bộ đưa quyết định cần biết Độ tin cậy của sản phẩm phần mềm cần được đo trong các bước sớm trước khi chuyển giao và ứng dụng sản phẩm, trong khi chi phí bảo trì nằm trong khoảng lợi nhuận khi mà sản phẩm đã nằm ở cuối vòng đời.
Các kỹ thuật ước lượng chi phí phần mềm
Những nghiên cứu đáng kể đưa ra các kỹ thuật ước lượng chi phí phần mềm bắt đầu từ những năm 1965, với việc nghiên cứu dựa trên tập hợp các dữ liệu mẫu từ 169 dự án phần mềm, với 104 thuộc tính của phần mềm được khảo sát Dựa trên những nghiên cứu này, một vài mô hình ước lượng, dù chưa được hòan chỉnh nhưng khá có giá trị đã được công bố vào cuối những năm 1960 đầu những năm 1970.
Cho tới cuối những năm 1970, đã có hàng loạt những mô hình mạnh hơn, có độ chính xác cao hơn được giới thiệu như: SLIM (Putnam và Myers), Checkpoint (Jones), PRICE-S (Park), SEER (Jensen) và COCOMO (Boehm) Tuy nhiên tất cả các mô hình này đều gặp vấn đề với các dự án có kích cỡ và tầm quan trọng lớn Với những phần mềm quy mô lớn này, thì có độ phức tạp cao, làm cho việc ước lượng chính xác chi phí vô cùng khó Đây cũng chính là động lực thúc đẩy các nhà nghiên cứu phát triển thêm các mô hình cho phù hợp hơn với thực tế.
Với bản chất thay đổi nhanh chóng của phần mềm làm cho việc xây dựng các mô hình tham số (vốn mang lại độ chính xác cao cho nhiều lĩnh vực trong phát triển phần mềm) trở nên rất khó khăn Với mục tiêu xây dựng các mô hình hữu dụng, dựa theo vòng đời phát triển phần mềm để dự đoán chính xác chi phí phần mềm, trong khoảng hơn hai thập kỷ gần đây, nhiều mô hình ước lượng chi phí phần mềm đã xuất hiện Các kỹ thuật thường được sử dụng nhất trong các mô hình này là các phương pháp tiếp cận đa hồi quy cổ điển Ta có thể xếp các kỹ thuật thông dụng nhất hiện nay theo sáu hướng tiếp cận sau:
Hình 1: các kỹ thuật ước lượng phần mềm
Sau đây ta sẽ nghiên cứu thêm về từng loại kỹ thuật đó.
1 Các kỹ thuật dựa trên mô hình:
Theo nghiên cứu trong thời gian qua không có nhiều các mô hình ước lượng phần mềm được xây dựng, và hầu hết đều là các mô hình thuộc sở hữu độc quyền do đó khó có thể so sánh hay đối chiếu về mặt cấu trúc của các mô hình Tính năng của các mô hình được xác định thuần túy trên lý thuyết hay qua các thử nghiệm Sau đây ta sẽ nghiên cứu về một số mô hình phổ biến.
1.1.Mô hình SLIM của Putnam Đây là mô hình được Larry Putnam thuộc công ty Quantitative Software Development, phát triển từ cuối những năm 1970 SLIM là kết quả phân tích của Putnam về vòng đời phát triển phần mềm, sử dụng đường cong phân bố Rayleigh để ước lượng cống sức, thời gian và tỷ lệ khiếm khuyến của dự án Ông sử dụng một chỉ số xây dựng nhân lực (MBI _ Manpower Buildup Index) và một hệ số năng suất (PF _ Productivity Factor) để hiệu chỉnh phân bố SLIM sử dụng các dữ liệu từ các dự án đã hoàn thành để ước lượng cho dự án mới Nếu không có các dữ liệu tiền định, thì ta có thể xác định các giá trị MBI và PF qua việc trả lời một tập các câu hỏi SLIM sử dụng khái niệm năng suất
P là tỷ lệ giữa kích cỡ phần mềm S và công sức phát triển E.
SLIM có thể thực hiện được với các độ đo kích cỡ phổ biến như số dòng mã lệnh SLOC, số điểm chức năng Function Points hay kỹ thuật ballpark. Đường cong Rayleigh được sử dụng để xác định phân bố công sức qua biểu thức vi phân:
Dy/dt=2Kate -at 2 Đây là một ví dụ về phân bố Rayleigh cho mức sử dụng nhân lực trong thời gian phát triển td với K=1, a=0.02, td=0.18 Với mỗi giá trị K, a và td khác nhau ta có được đồ thị phân bố khác nhau Tuy nhiên phân bố Rayleigh không phải luôn luôn đúng trong thực tế, ví dụ khi phát triển gia tăng thì phân bố Rayleigh trở thành nằm ngang, hay khi tăng thời gian thực hiện dự án ta chỉ có thể tiết kiệm nhân lực được một lươngj nhỏ hơn t 4 Putnam đã đề xuất một số hiệu chỉnh cho các trường hợp đặc biệt đó
Công ty Quantitative Software Development đã xây dựng một bộ gồm ba công cụ dựa trên mô hình SLIM là SLIM Estimate hỗ trợ lập kế hoạch dự án, SLIM Control để theo dõi giám sát dự án và SLIM Metrics để lưu trữ và đánh giá các độ đo phần mềm Ta có thể tham khảo thêm thông tin về mô hình SLIM và các công cụ này tại http://www.qsm.com
1.2 Mô hình Checkpoint - điểm kiểm tra Đây là công cụ ước lượng dự án phần mềm được Software Productivity Research (SPR) phát triển trên những nghiên cứu của Capers Jones Checkpoint sử dụng các điểm chức năng FPs là đầu vào chính về kích cỡ để tiến hành ước lượng với nguồn cơ sở dữ liệu là hơn 8000 nghìn dự án đã hoàn thiện Dưới đây là mô hình của Checpoint với các khái niệm QA_ Quality Assurance đảm bảo chất lượng, JAD _ Joint Applications Development là tham gia phát triển ứng dụng, SDM _ Software Development Metrics là các độ đo phát triển phần mềm
Mô hình này hỗ trợ việc phát triển và củng cố mô hình vòng đời phát triển phần mềm theo 3 chức năng chính:
Ước lượng: Dự đoán công sức cần cho dự án théo cả bốn cơ sở: Dự án, các pha phát triển, các hoạt động và các nhiệm vụ Ước lượng gồm 5 thành phần: Tài nguyên, những phần được chuyển giao, các khiếm khuyết, chi phí và thời gian.
Đo lường: Cho phép người dùng chọn các độ đo để đo lường cho dự án, từ đó phân tích hiệu năng, xác định kỹ thuật ứng dụng tốt nhất và xây dựng nền tảng tri thức ước lượng nội bộ (là các mẫu _ templates)
Đánh giá: Dựa trên các tiêu chuẩn công nghiệp để hỗ trợ việc so sánh đánh giá các tính năng của dự án với nhu cầu thực tế Đánh giá ưư nhược điểm của môi trường pháp triển phần mềm và mô hình hóa các khuyến nghị trong cải thiện quy trình đánh giá.
Ngoài ra SPR còn đưa ra thị trường một số công cụ khác như: Knowledge Plan giúp đưa ra một ước lượng ban đầu về dự án phần mềm với công sức giới hạn, và hướng dẫn một quy trình tinh chỉnh qua các thử nghiệm và đánh giá; FP Workbench là công cụ để phân tích các điểm chức năng có lưu trữ cập nhật và phân tích từng phép đếm
Ngoài SPR còn một số tổ chức khác cũng xây dựng mô hình ước lượng dựa trên số đếm các điểm chức năng Tiêu biểu như COSMIC -Common Software Mesurement International Consortium Là một dự án với kỳ vọng thừa kế tất cả các ưu điểm của các mô hình ước lượng qua điểm chức năng khác như IFPUG MkII, NESMA Do các điểm chức năng không phù hợp với các hệ thống nhúng và hệ thống thời gian thực, nên COSMIC FFP v2.2 đã bổ sung để đo kích cỡ theo đơn vị chức năng là các yêu cầu về chứuc năng của người dùng (FUR-Functional User Requirement) Hiện nay COSMIC FFP đã được tiêu chuẩn quốc tế hóa.
Là mô hình được phát triển đầu tiên ở RCA và được sử dụng nội bộ để ước lượng cho các dự án phần mềm thuộc bộ quốc phòng mỹ, NASA và các dự án chính phủ Mỹ khác Các biểu thức không được công bố mà chỉ một số giải thuật chính được công bố vào năm 1988 Sau này đã được phổ biến rộng rãi và thương mại hóa bởi công ty PRICE System Bao gồm 3 mô hình con: i Mô hình thu thập: Dự đoán chi phí và thời gian thực hiện của phần mềm, xây dựng ứng dụng trên tất cả mọi lĩnh vực: Hệ thống kinh doanh, hệ thống giao tiếp, hệ thống chỉ huy và điều khiển, hệ thống điện tử hàng không vũ trụ PRICE-S tập trung vào các vấn đề: Tái kỹ nghệ, sinh mã nguồn, phát triển xoắn ốc, phát triển nhanh, tạo mẫu thử nhanh, phát triển hướng đối tượng và đo lường năng suất phần mềm. ii Mô hình định cỡ: Hỗ trợ việc ước lượng kích cỡ của phần mềm qua các độ đo như SLOC, FP hay POP (các điểm đối tượng dự đoán Predictive Object Points) - là độ đo hướng đối tượng mới của Chidamber. iii Mô hình chi phí vòng đời: Ước lượng nhanh chi phí các pha bảo trì và hỗ trợ ở giai đoạn sớm Thường được sử dụng kết hợp với mô hình thu thập
Tham khảo thêm về PRICE-S tại http://www.pricesystems.com
MÔ HÌNH COCOMO II
Tổng quan
COCOMO II sử dụng hai mô hình Post-Architecture (PA) và Early – Design (ED) để ước lượng cho việc phát triển dự án phần mềm mô hình PA là mô hình chi tiết được sử dụng khi một dự án đã sẵn sàng để phát triển và có thể duy trì Hệ thống đó đã có một kiến trúc vòng đời để cung cấp các thông tin chi tiết về các tham số đầu vào của hệ thống, từ đó đảm bảo cho sự chính xác khi ước lượng Còn mô hình ED là một mô hình được sử dụng để khảo sát các khả năng thay thế về kiến trúc hoặc các chiến lược phát triển gia tăng Mức độ chi tiết của mô hình này phù hợp với tổng quát của các thông tin có được và độ chính xác cần thiết ở giai đoạn sớm của dự án.
Cả PA và ED đều sử dụng cùng một cách tiếp cận để ước lượng kích cỡ sản phẩm (bao gồm cả phần tái sử dụng lẫn các hệ số tỷ lệ)
Các biểu thức ước lượng trong mô hình COCOMO II
Cả 2 mô hình PA và ED đều sử dụng cùng một dạng hàm số để ước lượng các tiêu chí, chỉ khác nhau về các tham số cụ thể trong các hàm này Các công thức có tính danh nghĩa về thời gian NS (Norminal Schedule) không bao gồm tham số về độ co giãn thời gian, bởi về danh nghĩa luôn giả định rằng các dự án được hoàn thành đúng thời gian. Các công thức sẽ được giới thiệu chi tiết ở phần sau.
Lượng công sức danh nghĩa để hòan thành dự án được tình theo nhân công tháng PMNS
(Person month) được tình theo công thức:
Trong đó giá trị n (số các hệ số nhân công sức) của mô hình PA là 16 còn của mô hình
Lượng thời gian danh nghĩa để phát triển sản phẩm TDEVNS được ước lượng theo công thức:
Các giá trị chuẩn A,B,EM,SF được xác định dựa theo dữ liệu từ 161 dữ liệu dự án phần mềm của COCOMO II Trong đó 6 hệ số nhân công sức trong mô hình ED là tổng hợp
16 hệ số nhân công sức tương ứng trong mô hình PA các giá trị trong cocomo II
Các giá trị hằng số A,B,C,D này có thể được điều chỉnh cho phù hợp với môi trường phát triển của tổ chức mỗi tổ chức đều nên hiệu chỉnh tối thiểu 2 giá trị A,C cho phù hợp với môi trường của mình để đạt được sự chính xác cần thiết cho ước lượng chứ không nên chỉ áp dụng giá trị chuẩn mà COCOMO II đã đưa ra.
Định kích cỡ phần mềm
Trong mỗi mô hình ước lượng thì việc ước lượng kích cỡ của một dự án phần mềm là điều rất quan trọng và cũng rất khó Một dự án phần mềm thường bao gồm khộng chỉ mã lệnh được viết mới mà còn bao gồm các các mã lệnh tái sử dụng từ các nguồn khác (có thể có hoặc không có sự thay đổi cần thiết), và các mã lệnh được dịch tự động. Trong mô hình COCOMO II việc đánh giá kích cớ của một dự án thông qua hai loại mã lệnh cơ bản là mã được viết mới và mã lệnh sao chép có sửa đổi, bởi chỉ hai loại này mới ảnh hưởng đến công sức phát triển phần mềm Và hai loại mã này đều được gộp chung lại sau khi đã quy đổi kích cỡ module tái sử dụng thành kích cỡ tương đương.
3.1 Đếm số dòng mã lệnh
Có nhiều phương pháp và kỹ thuật để thực hiện việc ước lượng số dòng mã lệnh Kích cỡ của số dòng mã lệnh được tình theo đơn vị nghìn dòng lệnh KSLOC Để xác định chính xác được thế nào là một dòng lệnh nói chung là khó, vì nó phụ thuộc nhiều vào đặc thù riêng của từng ngôn ngữ lập trình Học viện kỹ thuật phần mềm SEI đưa ra một bản liệt kê các câu lệnh nguồn logic được dùng làm đơn vị đo lường cho dòng mã lệnh.
Hình sau minh họa bảng liệt kê của SEI với mỗi dấu tích trong phần “include” là ứng với thành phần tương ứng được tính là mã nguồn logic, còn tích trong “exclude” là thành phần không được tính
Bảng 1: Danh sách liệt kê các loại dòng lệnh được tính Để ước lượng số dòng mã lệnh với độ chính xác chấp nhận được đòi hỏi phải có kinh nghiệm trong thiết kế, kinh nghiệm với các dự án tiền nhiệm của tổ chức Thông thường, người ta áp dụng nhiều phương pháp như áp dụng tương tự, lấy ý kiến chuyên gia hay ước lượng theo chiều dài của bản đặc tả yêu cầu và thiết kế… Ước lượng số dòng mã lệnh dựa theo chiều dài của bản đặc tả yêu cầu và thiết kế được áp dụng khi một tổ chức phát triển phần mềm có môi trường chặt chẽ, quy định thống nhất trong tất cả các dự án, và có tài liệu rõ ràng Trong môi trường như thế, người ta thấy có thể tìm được tỷ lệ tương đối giữa chiều dài đặc tả yêu cầu và thiết kế với số dòng mã lệnh.
3.2 Đếm các điểm chức năng chưa điều chỉnh UFP
Phép tiếp cận ước lượng chi phí theo điểm chức năng dựa trên số lượng chức năng có trong một dự án phần mềm và một tập các nhân tố đơn lẻ của dự án Điểm chức năng rất hữu ích cho việc ước lượng bởi chúng dựa trên thông tin có được từ giai đoạn sớm của dự án.
Việc đếm điểm chức năng của một dự án được thực hiện bằng cách tính số lượng các điểm chức năng xử lý theo 5 kiểu chính sau
Bảng 2: Các loại chức năng Điểm chức năng Mô tả
Nhập dữ liệu EI Các chức năng nhập dữ liệu có ảnh hưởng tới ILF Xuất dữ liệu EO Cung cấp dữ liệu cho người dùng
Các tệp logic trong ILF Các tệp logic được quản lý bởi ứng dụng, Các tệp giao tiếp ngoài EIF Gồm các tệp của các ứng dụng khác được gọi
Truy vấn ngoài EQ Tra cứu, trợ giúp
Mỗi thể hiện của các kiểu chức năng trên được sắp xếp và phân chia theo các mức độ phức tạp Kết hợp độ phức tạp với tất cả các điểm chức năng đếm được sẽ cho ta một số điểm chức năng chưa điều chỉnh Đây là một đơn vị kích cỡ được COCOMO II sử dụng và chuyển đổi qua số KSLOC làm dữ liệu đầu vào về kích cỡ phần mềm.
Quy trình xác định UFP gồm 4 bước:
Đếm số các chức năng theo kiểu: dựa vào các đặc tả yêu cầu phần mềm, với kinh nghiệm của những chuyên viên hàng đầu để tính ra số lượng chức năng từng kiểu.
Xác định độ phức tạp: phân chia, sắp xếp các chức năng theo độ phức tạp tương ứng Thấp, trung bình, cao tùy theo số lượng các kiểu phần tử dữ liệu chứa trong chức năng đó và số lượng các kiểu tệp mà chức năng đó tham chiếu đến
Xác định trọng số cho các chức năng: định trọng số cho từng kiểu chức năng theo các cấp độ phức tạp khác nhau.
Tính toán UFP: là tổng của tất cả trọng số các điểm chức năng đã được đếm
Bảng 3: Xác định trọng số theo độ phức tạp của chức năng
Kiểu chức năng Độ phức tạp _ trọng số
Mối liên hệ UFP với SLOC
Trong quá trình nghiên cứu, người ta thấy có sự tương quan giữa UFP và SLOC phụ thuộc vào ngôn ngữ lập trình sử dụng Nói một cách khác, để thực hiện cùng một chức năng như nhau thì ở mức độ trung bình về khả năng lập trình của lập trình viên, sẽ cần số dòng mã lệnh trong một ngôn ngữ xác định là khá ổn định Người ta đã tổng kết ra bảng chuyển đổi UFP sang SLOC như sau
Bảng 4: Bảng tỷ lệ chuyển đổi SLOC/UFP theo ngôn ngữ
3.3 Tổng hợp các mã mới, mã thích ứng và mã tái sử dụng
Trên đây ta mới chỉ đề cập tới những mã lệnh được tạo mới Trong thực tế phát triển phần mềm đôi khi còn sử dụng lại các mã lệnh từ các nguồn khác Trong trường hợp mã có sẵn đóng kín và được tích hợp vào sản phẩm gọi là mã tái sử dụng (reused code). Trong trường hợp mã có sẵn mở cho phép chỉnh sửa cho thích ứng với sản phẩn thì gọi là mã thích ứng (adatped code) Kích cỡ của các mã thích ứng được quy về một giá trị tương đương với đơn vị tạo mã mới lượng mã này được gọi là ESLOC Việc điều chỉnh này thể hiện công sức để điều chỉnh mã cho thích ừng với sản phẩm cần xây dựng.
3.3.1 Các hiệu ứng không tuyến tính của việc tái sử dụng
Các phân tích cho thấy chi phí của việc tái sử dụng là không tuyến tính và phụ thuộc vào hai yếu tố quan trọng là: nỗ lực để tái sử dụng mã không bắt đầu từ 0 mà thường phải chi phí 5% để đánh giá, lựa chọn và sử dụng lại thành phần
Theo dữ liệu nghiên cứu của Parikh Zveginzov cho thấy 47% công sức trong bảo trì phần mềm là để hiểu được phần mềm chỉnh sửa vì thế khi chuyển từ mã tái sử không chỉnh sửa sang mã tái sử dụng có chỉnh sửa, ta gặp một vấn đề là phải hiểu được phần mềm Nghiên cứu của Gerlich Denskat cho thấy rằng muốn chỉnh sửa k module trong tổng số m module phần mềm, thì số giao diện module cần kiểm tra N được xác định theo công thức
Khối lượng của việc hiểu phần mềm và kiểm tra các giao tiếp module có thể giảm nếu phần mềm có cấu trúc tốt Và tổ chức thành các module, cấu trúc phân cấp có thể làm giảm số lượng giao tiếp cần kiểm tra Việc phần mềm dễ hiểu hơn nếu được cấu trúc hợp lý, có giải thích và xác định mục đích rõ ràng COCOMO II phản ánh điều này qua việc xét đến nỗ lực ước lượng để hiệu chỉnh phần mềm có thể tái sử dụng
3.3.2 Mô hình tái sử dụng
COCOMO II sử dụng ba hệ số phản ánh mức độ chỉnh sửa: phần trăm thiết kế được chỉnh sửa DM, phần trăm mã lệnh cần chỉnh sửa CM và một hệ số phần trăm phản công sức cần để tích hợp thành phần tái sử dụng/ thích ứng này vào hệ thống IM
Hiệu số điều chỉnh thích ứng được tính theo công thức:
Số dòng mã lệnh tương đương
Ước lượng công sức
Trong mô hình COCOMO II công sức được tính theo đơn vị nhân công tháng PM (Person month) _ tức là lượng công sức một người làm trong một tháng Với số giờ công bình quân tính cho một nhân công tháng là 152 PH/PM
Công thức ước lượng công sức áp dụng cho cả hai mô hình PA và ED được tính như sau:
Với hệ số A=2,94 và số mũ
Công thức này để ước lượng công sức giữa hai điểm kết thúc LCO, IOC của mô hình MBASE/RUP và SRR, SAR trogn mô hình thác nước Tùy theo mô hình PA hay EM mà số các hệ số và giá trị của chúng được xác định khác nhau
Kích cỡ Size được tình theo đơn vị KSLOC, là tổng kích thước được ước lượng của các module thành phần Kích cỡ cũng có thể được tính theo các điểm chức năng rồi chuyển qua SLOC Chi tiết về cách tính kích cỡ đã trình bày ở phần trên.
Tác động vào kích cỡ là số mũ E, đây là tác động tổng hợp của 5 hệ số tỷ lệ SF đặc trưng cho các thuộc tính của dự án, và do đó nó được áp dụng cho tất cả các thành phần của dự án.
Các hệ số chi phí thể hiện các đặc tính trong phát triển phần mềm và ảnh hưởng tới công sức dự án Mỗi hệ số chi phí là một tác nhân của mô hình mà chi phối tới ước lượng chi phí của mô hình(ở đây đang xét là nhân công tháng) Các hệ số chi phí này được phân chia mức độ ảnh hưởng tới công sức phát triển từ rất thấp cho tới rất cao Và ứng với mỗi mức độ có một giá trị trọng số gọi là các hệ số nhân công sức EM (Effort Multiplier) Trong đó: mức độ trung bình các hệ số này có giá trị là 1.00, với mức ảnh hưởng làm tăng công sức chúng sẽ có giá trị lớn hơn 1.00, và nếu ảnh hưởng làm giảm công sức chúng sẽ có giá trị nhỏ hơn 1.00 Mỗi tỷ lệ này sẽ xác định rõ yếu tố nào thay đổi và mức độ thay đổi của nó trong công sức dự án và năng suất
Mô hình PA có 16 hệ số nhân công sức EM, mô hình ED có 6 hệ số nhân công sức. Ngoài ra cả hai mô hình này đều sử dụng chung hệ số thời gian phát triển cẩn thiết SCED.
4.1 Các hệ số tỷ lệ SFj
Trong biểu thức tính công sức thì số mũ E là tổng hợp của 5 hệ số tỷ lệ đặc trưng cho hệ thống, E thể hiện khả năng giảm bớt hay gia tăng thêm chi phí sản xuất:
Nếu E1.00 thể hiện đây là dự án mang tỷ lệ phi kinh tế cao thường do hai nguyên nhân: tăng sự giao tiếp giữa các nhân viên, và tăng sự tích hợp hệ thống lớn Các dự án lớn cần nhiều nhân sự và do đó sẽ bị tăng trội giao tiếp giữa các nhân viên Tích hợp các phần vào một dự án lớn không chỉ đòi hỏi công sức để phát triển các thành phần đơn thuần mà còn cần thêm nhiều công sức để thiết kế, bảo trì, tích hợp và kiểm thử giao diện của chúng với các phần còn lại
Hình sau mô tả sự tác động của E lên công sức (Coi như cùng trong một môi trường nên E thay đổi theo B)
Số mũ E được tính theo biểu thức:
Trong đó B=0.91 là một hằng số có thể điều chỉnh cho phù hợp với môi trường phát triển Các hệ số tỷ lệ SF được phân mức độ từ Cực thấp đến Cực cao và được đánh trọng số theo từng mức độ Bảng 10 tổng kết các mức độ và giá trị của các hệ số tỷ lệ:
Các hệ số tỷ lệ
Rất thấp Thấp Trung bình
Cao Rất cao Cực cao
PREC Hoàn toàn không có tiền lệ
Hầu như không có tiền lệ
Có chút ít tiền lệ
Thân thuộc ở mức chung chung
FLEX Nghiêm ngặt, khắt khe
Tuân theo một cách chung chung Đôi chỗ phải tuân theo
RESL Hầu như không Đôi chút Nhiều khi Thường xuyên
TEAM Giao tiếp rất khó khăn
Giao tiếp có đôi chút khó khăn
Về cơ bản có khó khăn
Cộng tác ở mức độ lớn
Giao tiếp mà không có trở ngại
PMAT Mức độ thuần thục quy trình tương đương (EPML) được ước lượng
Nửa trên SW- CMM mức 1
Bảng 10: Tổng hợp các hệ số tỷ lệ
Trong đó hệ số tiền lệ PREC và độ linh hoạt FLEX có sự thay đổi lớn giữa các mô hình trong COCOMO nguyên thủy : Có tính hệ thống, Bán hệ thống, và Nhúng
Sau đây ta sẽ nghiên cứu chi tiết hơn về các hệ số tỷ lệ này
4.1.1 Hệ số về tính tiền lệ PREC (Precedentedness) Đây là hệ số thể hiện độ giống nhau với các dự án khác mà tổ chức đã phát triển Cấp độ đánh giá được phân loại theo bảng sau:
Tính chất Rất thấp Trung bình/Cao Cực cao
Hiểu về các mục tiêu của sản phẩm ở cấp độ toàn tổ chức
Chung chung Đáng kể Xuyên suốt
Có kinh nghiệm làm việc với các hệ thống phần mềm liên quan
Vừa phải Đáng kể Sâu sắc
Phát triển đồng thời các phần cứng và các thủ tục vận hành kết hợp
Sâu sắc Vừa phải Đôi chút
Cần các kiến trúc xử lý dữ liệu, giải thuật đổi mới Đáng kể Đôi chút Tối thiểu
Bảng 11: Mức đánh giá tính tiền lệ 4.1.2 Độ linh hoạt phát triển FLEX (Development Flexibility)
Hệ số thể hiện mức độ yêu cầu cần thích ứng với các yếu tố phát triển của phần mềm
Tính chất Rất thấp Trung bình/cao Cực cao
Phần mềm cần phù hợp với những yêu cầu đã thiết lập trước
Toàn bộ Đáng kể Về cơ bản
Phần mềm cần phù hợp với những đặc tả giao tiếp
Toàn bộ Đáng kể Về cơ bản
Kết hợp những ràng buộc trên với khoản thưởng cho hoàn thành sớm
Bảng 12: Mức đánh giá độ linh hoạt
PREC và FLEX là hai hệ số liên quan chặt chẽ đến các yếu tố bên trong của dự án và không thể điều khiển được.
Ba hệ số tỷ lệ còn lại xác định các yếu tố quản lý có thể điều khiển được mà nhờ đó các dự án có thể giảm tỷ lệ phi kinh tế cho các dự án.
4.1.3 Tỷ lệ kiến trúc/giải pháp xử lý rủi ro RESL (Architecture/Risk Resolution) Đây là hệ số tỷ lệ kết hợp hai hệ số tỷ lệ trong mô hình ADA COCOMO là hệ số độ trọn vẹn thiết kế qua duyệt lại thiết kế sản phẩm (Design thoroughness by Product Design Review PDR) và sự loại bỏ rủi ro bằng duyệt lại thiết kế sản phẩm (Risk elimination by Product Design Review) Bảng sau tổng kết mức độ phân loại hệ số kết hợp với các mốc quan trọng trong kiến trúc vòng đời (Life Cycle Architecture LCA) trong mô hình MBASE/RUP cũng như của PDR trong mô hình thác nước Hệ số RESL là trung bình các trọng số được đánh giá chủ quan của các đặc tính. Đặc điểm Rất thấp
Kế hoạch quản lý rủi ro chỉ ra tất cả các trường hợp, và đưa ra các mốc để giải quyết qua PDR hoặc
Không Rất ít Đôi chút
Thời gian, ngân sách và các cột mốc được đưa ra qua PDR và LCA phù hợp với kế hoạch quản lý rủi ro
Không Rất ít Đôi chút
Phần trăm thời gian phát triển cho việc thiết lập kiến trúc, đưa ra các mục tiêu chung của sản phẩm
Phần trăm về kiến trúc phần mềm cao cấp theo yêu cầu có sẵn
Các công cụ hỗ trợ cho việc giải quyết các rủi ro, xây dựng và xác thực các đặc tả kiến trúc có sẵn
Không Rất ít Đôi chút
Mức độ không chắc chắn của các yếu tố chi phối chính đến kiến trúc: nhiệm vụ, giao diện người dùng,
COTS, phần cứng, công nghệ và tính năng
Nhiều Một vài Ít Rất ít
Số lượng và mức nghiêm trọng của các rủi ro
Bảng 13: Các cấp độ đánh giá hệ số RESL
Các hệ số nhân công sức
5.1 Các hệ số trong mô hình PA
PA là một mô hình chi tiết, được áp dụng khi đã hoàn tất thiết kế vòng đời phát triển phần mềm Mô hình này sử dụng 17 hệ số nhân công sức EM (Effort Multipliers) để điều hỉnh công sức danh nghĩa Mỗi hệ số được phân loại chi tiết và đánh trọng số theo từng loại đó
5.1.1 Các yếu tố của sản phẩm Đây là các hệ số thể hiện tác động của các đặc trưng về sản phẩm lên công sức phát triển Ta xét 5 hệ số có tác động lớn nhất sau:
Hệ số độ tin cậy được yêu cầu RELY (Required Software Reliability): Đây là thước đo độ tin cậy mà phần mềm phải đạt được trong một khoảng thời gian. Bảng 18 đưa ra xếp loại và trọng số cho hệ số RELY
Bất tiện, không đáng kể
Mất mát ít, dễ khôi phục
Mất mát vừa phải, dễ khôi phục
Mất mát lớn về tài chính
Nguyên hiểm đến tính mạng con người
Các cấp độ phân loại
Rất thấp Thấp Trung bình
Cao Rất cao Cực cao
Các hệ số nhân công sức tương ứng
Bảng 17: Phân loại và trọng số hệ số RELY
Hệ số này còn có thể bị ảnh hưởng bởi yêu cầu nhằm phát triển phần mềm cho việc tái sử dụng.
Hệ số kích cỡ dữ liệu DATA (Database Size) : thể hiện tác động của kích cỡ dữ liệu kiểm thử tác động lên phát triển sản phẩm Việc phân loại để xác định trọng số dựa vào tỷ lệ D/P: là tỷ lệ về kích cỡ (theo bytes) giữa CSDL kiểm thử trên số dòng mã lệnh SLOC của chương trình DATA cho biết công sức cần thiết để tạo ra và duy trì dữ liệu được yêu cầu để hoàn thiện kiểm thử tại điểm IOC.
Các cấp độ phân loại
Thấp Trung bình Cao Rất cao Cực cao
Các hệ số nhân công sức n/.a 0.90 1.00 1.14 1.28 n/a
Bảng 18: phân loại và trọng số DATA
Hệ số độ phức tạp của sản phẩm CPLX (Product Complexity) : độ phức tạp được phân chia theo 5 lĩnh vực: quá trình điều khiển, quá trình tính toán, quá trình phục thuộc thiết bị, quá trình quản lý giao diện người dùng Bảng 19 giúp phân cấp theo từng loại, bảng 20 cho ta các trọng số tương ứng.
Quá trình không phụ thuộc thiết bị
Quá trình quản lý dữ l iệu
Quá trình quản lý giao diện người dùng
Mã đều nhau với một số câu lẹnh có cấu trúc, không lồng nhau: DO,
Tính toán một số biểu thức đơng giản
Các câu lệnh đọc ghi đơn giản với các định dạng đơn giản
Các mảng đơn giản trong bộ nhớ chính Các truy vấn, cập nhật COTS –
Các mẫu nhập liệu,tạo báo cáo đơn giản ra một số module đơn giản thông qua các lời gọi thủ tục hoặc kịch bản đơn gian
Thấp Các câu lệnh lập trình có cấu trúc, lồng nhau, tuần tự hấu hết là các thuộc tính đơn giản
Tính tóan các biểu thức ở mức độ vừa phải, như sử dụng lũy thừa, căn
Không cần thiết phải có hiểu biết về các đặc điểm của từng bộ vi xử lý hay thiết bị Nhâp/xuất.
Việc nhập/ xuất được thực hiện ở cấp độ GET/
Bố trí các file riêng lẻ mà không làm thay đổi cấu trúc dữ liệu, không hiệu chỉnh, không tạo các file trung gian.
Các truy vấn và cập nhật COTS – DB ở mức độ vừa phải
Sử dụng các trình tạo giao diện người dùng GUI đơn giản
Hầu hết là cấu trúc lồng nhau đơn giản có đôi chút điều khiển giữa các module.
Các bảng quyết đinh,các lời gọi ngược hoặc truyền thông điệp đơn giản, bao gồm xử lý phân tán có hỗ trợ của phần mềm trung gian
Sử dụng các thủ tục toán học và thống kê chuẩn. các phép tính ma trận/ vector cơ bản
Các xử lý nhập/xuất bao gồm lựa chọn thiết bị, kiểm tra trạng thái và xử lỹ lỗi
Nhập dữ liệu từ nhiều file, xuất dữ liệu ra 1 file.
Nhưng thay đổi đon giản về cấu trúc, hiệu chỉnh đơn giản các truy vấn, cập nhật COTS-
Sử dụng tập các công cụ cải tiến ở mức đơn giản
Cao Các câu lệnh lập trình có cấu trúc lồng nhau nhiều lớp với rất
Phân tích cơ bản về số học: các biểu thức vi phân thông
Các thao tác nhập/xuất ở mức vật lý (các phép phân giải địa
Các trigger đơn giản được kích hoạt bởi các nội dụng
Phát triển và mở rông tập các công cụ cải tiến.Nhập/xuất nhiều thuộc tính đa hợp. điều khiển hàng đợi và ngăn xếp xử lý phân tán đồng nhát. Điều khiển mềm một bộ xử lý theo thời gian thực. thường, trực giao đa biến.
Các phép chặt cụt, làm tròn cơ bản. chỉ bộ nhớ vật lý, tìm, kiếm, đọc ) nhập/ xuất chồng chéo được tối ưu hóa luồng dữ liệu. cấu trúc lại dữ liệu phức tạp âm thanh, đa phương tiện đơn giản
Lập trình đệ quy và đa thực thi đồng thời. xử lý các ngắt có mức ưu tiên cố định Đồng bộ các nhiệm vụ, các lời gọi ngược phức tạp, xủ lý phân tán đồn nhất Điều khiển cứng bộ vi xử lý đơn theo thời gian thực.
Phân tích số học phức tạp, nhưng có cấu trúc: các biểu thức gần ma trận đơn, các biểu thức vi phân từng phần.
Các chương trình chẩn đoán ngắt, phục vụ, mặt nạ Xử lý đường trao đổi thông tin Các hệ thống nhúng đòi hỏi tính năng cao.
CSDL phân tán Các trigger phưc tạp Tối ưu hóa tìm kiếm. Ảnh đồ họa động, 2D/3D có độ phức tạp vừa phải, đa phương tiện
Quản lý theo thời gian nhiều tài nguyên với các thứ tự ưu tiên thay đổi linh hoạt Điều khiển ở mức vi mã Điều khiển cứng, phân tán theo thời
Phân tích số học khó và không có cấu trúc: phân tích dữ liệu nhiễu với độ chính xác cao.
Lập trình thiết bị phục thuộc khoảng thời gian, các toán tử được vi lập trình Các hệ thống nhúng đòi hỏi tính năng cao
Các cấu trúc đối tượng và quan hệ động, phụ thuộc chặt chẽ vào nhau.
Quản lý dữ liệu ngôn ngữ tự nhiên.
Giao diện đa phương tiên phức tạp,hiện thực ảo,ngôn ngữ tự nhiên gian thực
Bảng 19: Phân cấp độ phức tạp thành phần
Các cấp độ phân loại Rất thấp Thấp Trung bình Cao Rất cao Cực cao
Hệ số nhân công sức 0.73 0.87 1.00 1.17 1.34 1.74
Bảng 20: Hệ số CPLX theo từng cấp độ
Hệ số phát triển để tái sử dụng RUSE (Developed for Reusability): hệ số này tính công sức phải bỏ thêm để xây dựng các thành phần nhằm mục đích tái sử dụng trong tương lai Đây là phần công sức để tạo thêm các thiết kế chung của phẩn mềm, các tài liệu đánh giá cũng như các kiểm thử mở rộng, để chắc chắn rằng các thành phần này đã sẵn sàng để tái sử dụng.
RUSE còn đặt các ràng buộc lên RELY và DOCU: mức RELY tối đa là thấp hơn RUSE 1 bậc, DOCU tối thiểu là trung bình khi RUSE là trung bình hoặc cao và tối thiểu là cao khi RUSE là rất cao hoặc cực cao.
Dấu hiệu phân loại RUSE
Trong một dòng sản phẩm
Trong nhiều dòng sản phẩm
Các cấp độ phân loại
Cao Rất cao Cực cao
Hệ số nhân công sức n/a 0.95 1.00 1.07 1.15 1.24
Bảng 21: Hệ số chi phí RUSE
Hệ số tài liệu phù hợp với nhu cầu của vòng đời DOCU (Documentation Match to Life – Cycle needs): hệ số này được đánh giá theo mức độ phù hợp của tài liệu dự án theo nhu cầu vòng đời của nó Nếu tiết kiệm chi phí với mức DOCU rất thấp hoặc thấp sẽ phải gia tăng chi phí phần bảo trì lên nhiều lần tài liệu nghèo nàn và thiếu sẽ làm tăng SU Mặt khác DOCU còn chịu ràng buộc bởi RUSE như phân tích trên.
Dấu hiệu phân loại DOCU
Nhiều nhu cầu của vòng đời chưa được phát hiện
Một vài nhu cầu của vòng đời chưa được phát hiện Đáp ứng được yêu cầu về kích cỡ của vòng đời
Nhiều so với nhu cầu của vòng đời
Quá nhiều so với nhu cầu của vòng đời
Các cấp độ phân loại
Rất thấp Thấp Trung bình
Cao Rất cao Cự c cao
Các hệ số nhân công sức
Bảng 22: Hệ số chi phí DOCU
5.1.2 Các yếu tố nền tảng (Platform Factors) Đây là các yếu tố liên quan đến độ phức tạp của phần cứng và cấu trúc hạ tầng của phần mềm bao gồm 3 yếu tố chính sau:
Hệ số ràng buộc về thời gian thực hiện TIME (Execution Time Constraint): Đánh giá ràng buộc về thời gian thực thi trong hệ thống phần mềm
Sử dụng 70% thời gian thực thi
Sư dụng 80% thời gian thực thi
Sử dụng 95% thời gian thực thi
Các cấp độ phân loại Rất thấ p
Cao Rất cao Cực cao
Hệ số nhân công sức n/a n/a 1.00 1.11 1.29 1.63
Bảng 23: Hệ số chi phí TIME
Hệ số ràng buộc về dung lượng lưu trữ chính STOR (Main Storage Constraint): Đánh giá mức độ ràng buộc về dung lượng lưu trữ chính của toàn hệ thống hay từng thành phần.