Chng 26 Software cost estimation Nhm 13 Hunh

Chương 26 ( Software cost estimation ) Nhóm 13: Huỳnh Ngọc n Ngô Thị Mỹ Hạnh Lê Thị Mỹ Hằng MSSV : 070003 T MSSV : 070096 T MSSV : 070078 T

Mục Tiêu (Objectives ) Ø Mục tiêu của chương này là để giới thiệu các kỹ thuật lập dự toán chi phí và nỗ lực cần thiết cho sản xuất phần mềm: a. Hiểu được nguyên tắc cơ bản của phần mềm chi phí và lý do tại sao giá của phần mềm có thể không được trực tiếp liên quan đến chi phí phát triển của nó. Mô tả các số liệu để đánh giá năng suất phần mềm Giải thích tại sao các kỹ thuật khác nhau nên được sử dụng để ước lượng phần mềm Hiểu các nguyên tắc của mô hình COCOMO II , thuật toán dự toán chi phí. b. c. d.

Nội Dung (Contents) q 26. 1 Năng suất (Productivity) q 26. 2 Các kỷ thuật ước lượng ( Estimation techniques) q 26. 3 Mô hình chi phí thuật toán ( Algorithmic cost modelling ) q 26. 4 Nhân lực và thời gian dự án (Project duration and staffing)

Nội Dung (Contents) q q Dự toán liên quan đến việc trả lời các câu hỏi sau đây: 1. Làm thế nào nhiều nỗ lực là cần thiết để hoàn thành từng hoạt động? 2. Thời gian là cần thiết để hoàn thành một hoạt động? 3. Tổng chi phí của từng hoạt động? Dự án dự toán và lập kế hoạch dự án thường được tiến hành xen kẽ với nhau. Tuy nhiên, bạn có thể phải làm một số dự toán chi phí trước khi kế hoạch chi tiết được vẽ lên. Những ước tính ban đầu có thể được sử dụng để thiết lập một ngân sách cho dự án hoặc để thiết lập một mức giá của phần mềm cho khách hàng.

Các Thành Phần Chi Phí Của Phần Mềm Có ba thông số liên quan đến việc tính toán tổng chi phí của một dự án phát triển phần mềm: • Chi phí phần cứng và phần mềm • Du lịch và chi phí đào tạo • Chi phí nỗ lực (Mức lương của các kỹ sư tham gia dự án) q Chi phí chiếm ưu thế là chi phí công sức. q Chi phí du lịch phong phú, có thể cần thiết khi dự án được phát triển tại các địa điểm khác nhau, các chi phí đi lại thường là một phần nhỏ trong chi phí công sức. q Máy tính đủ mạnh để phát triển phần mềm là tương đối rẻ. q

Các Thành Phần Chi Phí Của Phần Mềm q Các chi phí sau đây là một phần của tổng chi phí nổ lực: 1. Chi phí của việc cung cấp hệ thống sưởi ấm và chiếu sáng không gian văn phòng 2. Chi phí của các nhân viên hỗ trợ như kế toán, quản trị, quản lý hệ thống và kỹ thuật 3. Chi phí kết nối mạng và truyền thông 4. Chi phí của cơ sở trung ương như là một thư viện hoặc cơ sở giải trí 5. Chi phí an sinh xã hội lợi ích như lương hưu, bảo hiểm y tế.

Chi Phí Và Giá Cả Một khi dự án được triển khai, quản lý dự án phải thường xuyên cập nhật chi phí và dự toán kế hoạch. Điều này giúp quá trình lập kế hoạch và sử dụng hiệu quả các nguồn lực. q Nếu chi phí thực tế lớn hơn nhiều so với dự toán, người quản lý dự án phải áp dụng các nguồn lực bổ sung cho dự án, sửa chữa các công việc phải làm. q Phần mềm định giá phải được tiến hành khách quan với mục đích dự đoán chính xác chi phí phát triển phần mềm. Tuy nhiên, mối quan hệ giữa chi phí dự án và giá tính phí cho khách hàng thường không đơn giản. q Các tổ chức kinh tế, chính trị và kinh doanh được xem xét ảnh hưởng tới giá tính phí. q

26. 1 Năng suất (Productivity) Năng suất là số đơn vị đầu ra trên số giờ làm việc q Hình 26. 1 yếu tố ảnh hưởng phần mềm giá cả q Yếu Tố (Factor) Cơ hội thị trường (Market Opportunity) - Mô tả (Description) - Một tổ chức phát triển có thể báo giá thấp bởi vì nó muốn tiến xa hơn trong giai đoạn mới của thị trường phần mềm

- Chi phí ước tính không chắc chắn (Cost estimate uncertainty) Chấp nhận lợi nhuận thấp trên một dự án có thể cho các tổ chức cơ hội để kiếm lợi nhuận lớn hơn sau đó. Những kinh nghiệm thu được cũng có thể cho phép sản phẩm mới được pháp triển -Nếu một tổ chức không chắc chắn về ước tính chi phí của nó, nó có thể làm tăng giá của mình bằng một số dự phòng trên và cao hơn lợi nhuận bình thường. - Một khách hàng có thể sẵn sàng để cho phép các Điều kiện hợp nhà phát triển giữ lại quyền sở hữu của mã nguồn đồng (Cost estimate và tái sử dụng nó trong các dự án khác. uncertainty) - -Nếu các yêu cầu có khả năng thay đổi, một tổ - Yêu cầu, biến chức có thể hạ giá thấp hơn để giành được một hợp động (Requirement; đồng Sau khi nhận được hợp đồng, giá cao có thể volatility) được tính phí cho các thay đổi đối với yêu cầu.

- Tài chính y tế Phát triển trong tài chính khó khăn có thể thấp hơn giá để đạt được một hợp đồng - Năng suất ước tính thường được đo lường dựa trên các thuộc tính của phần mềm chia cho tổng số nỗ lực cần thiết để phát triển. Các loại số liệu đã được sử dụng: q 1. Số đo kích thước ( ví dụ: số dòng lệnh) 2. Số đo chức năng ( ví dụ: số chức năng được tạo ra trên một khoảng thời gian)

26. 1 Năng suất Phần mềm. Tính tổng số điểm chức năng trong một chương trình bằng cách đo hay đánh giá các tính năng chương trình sau đây: Ø Hình 26. 2 Thời gian phát triển hệ thống q

26. 1 Năng suất Phần mềm. q Bạn có thể tính toán số điêm chức năng (UFC) bằng cách nhân mỗi ước tính ban đầu của trọng lượng với tổng hợp tất cả các giá trị. q Số lượng điểm đối tượng trong một chương trình là một ước tính trọng lượng của: 1. Số lượng màn hình riêng biệt đó là màn hình hiển thị đơn giản được tính là 1 đối tượng điểm, màn hình phức tạp vừa phải tính là 2, và màn hình rất phức tạp tính là 3 điểm đối tượng.

26. 1 Năng suất Phần mềm. 2. Số lượng các báo cáo được sản xuất đối với báo cáo đơn giản là 2 điểm đối tượng, đối với báo cáo vừa phức tạp là 5, và cho các báo cáo rằng có thể sẽ là khó khăn để sản xuất là 8 điểm đối tượng. 3. Số lượng module bằng các ngôn ngữ lập trình bắt buộc như Java, C++ mà phải được phát triển để bổ sung mã lập trình cơ sở dữ liệu, mỗi một module được tính là 10 điểm đối tượng. q Ưu điểm của điểm đối tượng trên điểm chức năng là được dễ dàng hơn để ước tính từ một đặc điểm kỹ thuật phần mềm cấp cao, điểm đối tượng chỉ quan tâm đến màn hình, báo cáo và các module bằng các ngôn ngữ lập trình thông thường. Không quan tâm đến chi tiết thực hiện, và các yếu tố phức tạp tính toán đơn giản hơn nhiều.

26. 1 Năng suất Phần mềm. q Ước tính kích thước mã cho một ứng dụng được tính như sau: Code size = AVC x Number of function points (Mã kích thước = AVC x Số điểm chức năng) AVC: số dòng mã trung bình Giá trị của AVC khác nhau 200 -300 LOC / FP trong ngôn ngữ lắp ráp, 2 -40 LOC / FP cho một ngôn ngữ lập trình cơ sở dữ liệu như SQL. q Năng suất lập trình của các cá nhân làm việc trong một tổ chức bị ảnh hưởng bởi một số yếu tố. Quan trọng nhất trong số này được tóm tắt trong hình 26. 3. q q

q. Hình 26. 3 yếu tố ảnh hưởng đến năng suất công nghệ phần mềm - Kinh nghiệm miền ứng dụng (Application domain experience) - Chất lượng quy trình dự án (Process quality ) Kiến thức về các miền ứng dụng là rất cần thiết cho các kỹ sư phát triển phần mềm. -Quá trình phát triển có thể ảnh hưởng đáng kể đến năng suất. (chương 28) - - Kích thướt dự án (Project size) - Các dự án lớn hơn, thời gian cần thiết nhiều hơn. Ít thời gian có sẵn để phát - Công nghệ hỗ trợ (Technology triển nên năng suất cá thể là giảm. support ) -Công nghệ hỗ trợ tốt như các công cụ CASE và hệ thống quản lý cấu hình có - Môi trường làm việc (Working thể cải thiện năng suất. environment ) -Một môi trường yên tĩnh làm việc với khu vực làm việc tư nhân góp phần cải thiện năng suất.

26. 2 Các kỹ thuật ước lượng (Estimation techniques) q Không có cách nào đơn giản để thực hiện một ước tính chính xác các nỗ lực cần thiết để phát triển một hệ thống phần mềm • Ước tính ban đầu được dựa trên các thông tin không đầy đủ trong yêu cầu người sử dụng. • Các phần mềm có thể chạy trên các máy tính không quen thuộc hoặc sử dụng công nghệ mới. • Những người tham gia trong dự án này có thể chưa biết. q Tất cả những kỹ thuật dựa vào những đánh giá trên kinh nghiệm của người quản lý dự án, sử dụng kiến thức của họ về các dự án trước đây để đi đến ước tính của các nguồn lực cần thiết cho dự án.

26. 2 Các kỹ thuật ước lượng (Estimation techniques) q Tuy nhiên, có thể có sự khác biệt quan trọng giữa các dự án trong quá khứ và tương lai. Nhiều phương pháp phát triển mới và kỹ thuật đã được giới thiệu trong 10 năm qua. Một số ví dụ về những thay đổi có thể ảnh hưởng ước tính dựa trên kinh nghiệm bao gồm: 1. Đối tượng được phân phối hệ thống hơn 2. Sử dụng dịch vụ web 3. Sử dụng hệ thống ERP hay cơ sở dữ liệu trung tâm 4. Sử dụng phần mềm off-the-shelf 5. Phát triển và tái sử dụng

q Hình 26, 4 Dự toán chi phí kỹ thuật Kỹ thuật - Thuật toán xây dựng mô hình chi phí (Algorithmic cost: modelling) Mô tả Một mô hình được phát triển bằng cách sử dụng chi phí thông tin lịch sử có liên quan một số phần mềm số liệu (thường là kích thước) với ước tính chi phí dự án được làm từ đó số liệu và mô hình dự báo các nỗ lực cần thiết. - - - Ý kiến chuyên gia (Expert judgement) - Một số chuyên gia về phát triển kỹ thuật phần mềm được đề xuất và được giới thiệu để áp dụng các tên miền. Ước tính Chi phí dự án được so sánh và thảo luận. Quá trình lặp lại cho đến khi đạt được thỏa thuận về dự toán ước tính

- Đánh giá tương tự (Estimation by analogy) - Luật Parkinson (Parkinson's Law ) Kỹ thuật này được áp dụng khi các dự án cùng lĩnh vực. Chi phí của một dự án mới là ước tính của tương tự với các dự án này hoàn thành. - -Chi phí phụ thuộc vào thời gian và số nhân công. Chi phí xác định bởi nguồn tài nguyên có sẵn hơn là đánh giá khách quan. Nếu phần mềm đã được giao trong 12 tháng và 5 người có sẵn, các nỗ lực cần thiết được ước tính là 60 người-tháng. - - - Giá cả để thắng thầu (Pricing to win) - Phụ thuộc vào năng lực khách hàng. Những nỗ lực phụ thuộc vào ngân sách của khách hàng và không phải trên các chức năng phần mềm.

26. 2 Các kỹ thuật ước lượng (Estimation techniques) Bạn có thể giải quyết cách tiếp cận với ước tính chi phí thể hiện trong hình 26, 4 bằng cách sử dụng một cách tiếp cận từ trên xuống hay từ dưới lên. q Top-down • Bắt đầu ở cấp độ hệ thống • Đánh giá tổng thể chức năng hệ thống và cách này được phân phối thông qua hệ thống phụ. • 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ó thể là một phần của hệ thống. • Đưa vào chi phí tài khoản như quản lý cấu hình tích hợp và tài liệu. • Có thể đánh giá thấp chi phí giải quyết khó khăn vấn đề kỹ thuật ở mức độ thấp. q

26. 2 Các kỹ thuật ước lượng (Estimation techniques) q Bottom-up • Bắt đầu ở cấp thành phần và dự toán các nỗ lực cần thiết cho mỗi thành phần. • Thêm những nỗ lực để đạt được một ước tính cuối cùng. • Có thể sử dụng khi các kiến trúc của hệ thống được biết đến và các thành phần được xác định. • Có thể là một phương pháp chính xác, nếu hệ thống được thiết kế chi tiết. • Có thể đánh giá thấp các chi phí của hoạt động ở cấp hệ thống như tích hợp và tài liệu.

26. 3 Mô hình chi phí thuật toán (Algorithmic cost modelling ) Thuật toán xây dựng mô hình chi phí sử dụng một công thức toán học để dự đoán chi phí dự án dựa trên các ước tính của các môt dự án, số lượng kỹ sư phần mềm, . . q Một thuật toán dự toán chi phí cho phần mềm có thể được thể hiện như: Effort =A x Size. B x M (Nỗ lực) q A: là một yếu tố hằng số phụ thuộc vào thực tiễn địa phương tổ chức và phần mềm được phát triển. (độ phức tạp) Size: Kích thướt mã phần mềm(số đo năng suất)

26. 3 Mô hình chi phí thuật toán (Algorithmic cost modelling ) B: Giá trị B thường giữa từ 1 đến 1, 5 phản ánh các nổ lực không cân xứng cho yêu cầu các dụ án lớn. M: phụ thuộc vào quá trình và năng suất q Hầu hết các mô hình đều tương tự nhưng sử dụng các giá trị A, B, M khác nhau q Chú ý: • Rất khó dự đoán Size trong giai đoạn đầu. • B và M là khách quan và có thể thay đổi từ người này sang người khác.

26. 3. 1 Mô hình COCOMO là một mô hình thực nghiệm được thực hiện bằng cách thu thập dữ liệu từ một số lượng lớn các dự án phần mềm. q Những dữ liệu này được phân tích để tìm ra công thức phù hợp nhất. q Liên kết các công thức kích thước của hệ thống, sản phẩm dự án, và các yếu tố nỗ lực để phát triển hệ thống. q q Phiên bản đầu tiên của mô hình COCOMO (COCOMO 81) là một mô hình ba cấp. Cấp độ đầu tiên (cơ bản) cung cấp một ước tính ban đầu khó khăn. Mức thứ hai sửa đổi lần này bằng cách sử dụng một số dự án và quá trình hệ số và mức độ chi tiết nhất được sản xuất ước tính cho giai đoạn khác nhau của dự án.

q Phần mềm hiện nay thường được phát triển bởi Độ phức tạp dự án Công thức - Đơn giản PM = 2. 4 (KDSI) 1, 05 x M - Vừa phải PM = 3. 0 (KDSI) 1, 12 x M - Chuyên sâu (Lồng nhau) PM = 3. 6 (KDSI) 1, 20 x M (KDSI: số lệnh nguồn theo đơn vị nghìn) Mô tả -Các ứng dụng được phát triển bởi các nhóm nhỏ - Dự án phức tạp hơn, nơi các thành viên nhóm có thể giới hạn về kinh nghiệm -Kết hợp chặt với nhau về phần cứng, phần mềm, quy định và thủ tục hoạt động

26. 3. 1 Mô hình COCOMO Các mô hình con là một phần của mô hình COCOMO II là: • Một ứng dụng mô hình thành phần : được tạo ra từ các thành phần tái sử dụng (hiện có). • Thiết kế mô hình lúc đầu: sử dụng khi yêu cầu được cung cấp nhưng chưa bắt đầu thiết kế. • Tái sử dụng mô hình : được sử dụng để tính toán nỗ lực cần thiết để tích hợp các thành phần tái sử dụng. • Một mô hình kiến trúc, một khi các kiến trúc hệ thống đã được thiết kế, dự toán chính xác hơn về kích thước phần mềm có thể được thực hiện q Hình 26, 7 Các mô hình COCOMO II q

Số điểm ứng dụng Dựa trên Số điểm chức năng Dựa trên Số lượng các dòng Mã tái sử dụng hoặc tạo ra Số lượng các dòng mã nguồn Dựa trên Ứng dụng mô hình thành phần Thiết kế mô hình Đầu Tái sử dụng mô hình Được dùng Cho. Dựa trên Mô hình kiến trúc Thử nghiệm các hệ thống phát triển sử dụng kịch bản, DB lập trình, vv Ước lượng nỗ lực ban đầu. dựa vào những yêu cầu hệ thống và những tùy chọn thiết kế. Nỗ lực để sử dụng lại các thành phần hoặc tự động tạo ra mã Được dùng Nỗ Cho. lực phát triển dựa trên thiết kế hệ thống đặc điểm kỹ thuật

26. 3. 1 Mô hình COCOMO Ứng dụng mô hình thành phần q Ứng dụng mô hình thành phần được đưa vào COCOMO II hỗ trợ lập dự toán nỗ lực cần thiết để tạo mẫu dự án và cho các dự án phần mềm được phát triển bởi các thành phần tái sử dụng rông rãi. q Nó được dựa trên ước tính trọng điểm ứng dụng (điểm đối tượng) chia cho một ước tính tiêu chuẩn của ứng dụng năng suất điểm. v Dựa trên các ước tính tiêu chuẩn của các nhà phát triển năng suất trong các ứng dụng(đối tượng) điểm / tháng. Có sử dung cụ Case. q Hình 26, 8 Cho thấy mức độ năng suất của đối tượng điểm được đề xuất bởi các nhà phát triển mô hình (Boehm, et al, 1995. ). q

26. 3. 1 Mô hình COCOMO q Công thức tính nổ lực: PM= (NAP x (1 - % reuse/100))/PROD PM: nổ lực người/tháng NAP: số điểm ứng dụng. PROD: năng suất % ước tính số lượng mã được tái sử dụng q Hình 26, 8 Đối tượng điểm năng suất Kinh nghiệm, năng lực của nhà phát triển Very low Low Nominal High Veryhigh CASE phát triển và năng lực Very low Low Nominal High Veryhigh PROD (NOP / tháng ) 4 7 13 25 50

26. 3. 1 Mô hình COCOMO Thiết kế mô hình Đầu q Ước tính có thể thực hiện khi các yêu cầu được đồng ý. v Ước tính sản xuất trong giai đoạn này được dựa trên công thức tiêu chuẩn cho các mô hình thuật toán, cụ thể là: B= A x Size. B x M A=2, 14 trong hiệu chỉnh ban đầu trong KSLOG M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED B: dao động từ 1, 1 đến 1, 24 phụ thuộc vào tinh hình dự án, tính linh hoạt trong phát triển và phương pháp tính rủi ro. q

26. 3. 1 Mô hình COCOMO Kích thước của hệ thống được thể hiện trong KSLOC, đó là hàng ngàn số dòng mã nguồn. Tính KSLOC bằng cách ước tính số lượng các điểm chức năng trong phần mềm. q Hệ số phản ánh năng lực của nhà phát triển, các chức năng yêu cầu. . q Có thể tăng hoặc giảm các nỗ lực cần thiết. Những đặc điểm này được sử dụng trong thiết kế mô hình ban đầu. • RCPX là sản phẩm đáng tin cậy và phức tạp. • RUSE Tái sử dụng yêu cầu. • PDIF: nền tảng khó khăn. • PERS: năng lực nhân viên. • PREX kinh nghiệm nhân viên. • SCED yêu cầu tiến độ • FCIL: phương tiện hỗ trợ. q

26. 3. 1 Mô hình COCOMO Tái sử dụng mô hình q COCOMO II xem xét sử dụng lại mã có hai loại: • Black-box: đưa mã vào hộp đen để tái sử dụng mà không thay đổi, mã được điều chỉnh để tích hợp với mã mới. • White-box: sử dụng lại mã được sửa đổi, một ước tính kích thước tương đương với số dòng mã nguồn mới được tính. q Một số nỗ lực phát triển là cần thiết để tái sử dụng này bởi vì nó phải được hiểu và sửa đổi trước khi nó có thể hoạt động được trong hệ thống. q Đối với các mã được tự động tạo ra, công thức tính toán nỗ lực là: v PMAuto = (ASLOC x AT/100) / ATPROD Ø ASLOC: số lượng các dòng mã được tạo ra. Ø AT: tỉ lệ % của mã tự động tạo ra. Ø ATPROD: năng suất các kỹ sư tích hợp các mã này.

26. 3. 1 Mô hình COCOMO Ø Ví dụ : ATPROD được khoảng 2. 400 báo cáo source / tháng. Do đó, nếu có một tổng số là 20. 000 dòng của hộp màu trắng sử dụng lại mã số trong một hệ thốngvà 30% số này được tự động tạo ra, sau đó các nỗ lực cần thiết để tích hợp mã này được tạo ra là: (20. 000 x 30 / 100) / 2400 = 2, 5 tháng / người q Các công thức sau đây được sử dụng để tính toán số lượng tương đương các dòng của mã nguồn: ESLOC = ASLOC x (1 - AT/100) x AAM Ø Ø Ø ESLOC: số lượng tương đương các dòng mã nguồn mới. ASLOC và AT: như trên AAM: là sự điều chỉnh phù hợp với hệ số tính toán từ các chi phí của việc thay đổi mã để sử dụng lại, chi phí của việc tích hợp các mã và chi phí của quyết định tái sử dụng.

26. 3. 2 Mức độ kiến trúc sau cùng Sử dụng cùng một công thức như thiết kế mô hình ban đầu. q Ước tính sản xuất ở cấp độ kiến trúc này dựa trên cùng một công thức cơ bản: PM=A x SIZEB x M. q Kích thước mã được ước tính là: Ø Số lượng các dòng mã mới sẽ được phát triển. Ø Ước tính số lượng tương đương các dòng mã mới tính toán bằng cách sử dụng các mô hình tái sử dụng. Ø Ước tính về số lượng các dòng mã phải được sữa đổi theo yêu cầu thay đổi. q

Hình 26. 9 Miêu tả các yếu tố được sử dụng trong việc tính toán số mũ COCOMO II q Đánh giá các giá trị được sử dụng trong tính toán số mũ là: Ø Tiền tệ là một dự án mới cho các tổ chức xếp hạng thấp(4). Ø Phát triển tính linh hoạt không có sự tham gia của khách hàng được đánh giá rất cao (1). Ø Kiến trúc / nguy cơ giải quyết - Không có phân tích rủi ro -. V. thấp (5). Ø Nhóm nghiên cứu gắn kết - đội mới - danh nghĩa (3) Ø Quá trình trưởng thành - một số kiểm soát - danh nghĩa (3)

Hình 26. 9 Miêu tả các yếu tố được sử dụng trong việc tính toán số mũ COCOMO II Yếu tố quy mô Giải thích Tiền tệ Phản ánh những kinh nghiệm trước đây của tổ chức. Rất thấp có nghĩa là không có kinh nghiệm trước đó. Thêm có nghĩa là cao mà tổ chức này hoàn toàn quen thuộc với ứng dụng tên miền. Phát triển tính linh hoạt Phản ánh mức độ linh hoạt trong quá trình phát triển. Rất thấp có nghĩa là một quá trình theo quy định được sử dụng; Extra có nghĩa là cao mà khách hàng chỉ đặt mục tiêu chung.

Hình 26. 9 Miêu tả các yếu tố được sử dụng trong việc tính toán số mũ COCOMO II Kiến trúc / nguy cơ giải quyết Phản ánh mức độ phân tích nguy cơ thực hiện. Rất thấp có nghĩa là ít phân tích. Extra cao có nghĩa là một hoàn thành và triệt để phân tích rủi ro. Nhóm nghiên cứu gắn kết Phản ánh như thế nào nhóm phát triển biết nhau và làm việc cùng nhau. Rất thấp có nghĩa là tương tác rất khó khăn. Extra cao có nghĩa là một nhóm hợp và hiệu quả không có vấn đề truyền thông. Quá trình trưởng thành Phản ánh quá trình trưởng thành của tổ chức. Các tính toán giá trị này phụ thuộc vào trưởng thành CMM Bảng câu hỏi, nhưng ước tính có thể đạt được bằng cách trừ đi quá trình CMM mức độ trưởng thành từ 5.

Hình 26. 10 Chi phí dự án điều khiển Các thuộc tính (hình 26. 10) được sử dụng để điều chỉnh dự toán ban đầu. Mô hình kiến trúc sau thành bốn nhóm: q Ø Ø 1. Sản phẩm phần mềm được phát triển có thuộc tính liên quan đến các thuộc tính cần thiết. 2. Các phần mềm bị hạn chế bởi các phần cứng của máy tính. 3. Các thuộc tính là kinh nghiệm, khả năng của những người làm việc dựa trên các dự án. 4. Thuộc tính dự án có liên quan với các đặc điểm cụ thể của dự án phát triển phần mềm.

Hình 26. 10 Chi phí dự án điều khiển Thuộc tính Loại Mô tả RELY Sản phẩm Hệ thống yêu cầu độ tin cậy CPLX Sản phẩm Sự Phức tạp của những module hệ thống. DOC Sản phẩm Phạm vi tài liệu được yêu cầu DATA Sản phẩm Kích thước cơ sở dữ liệu được sử dụng RUSE Sản phẩm Yêu cầu tỷ lệ phần trăm của các thành phần tái sử dụng

Hình 26. 10 chi phí dự án điều khiển TIME Máy tính Thời gian thực hiện chế PVOL Máy tính Biến động của nền tảng phát triển STOR Máy tính Bộ nhớ hạn chế Nhân viên Năng lực của các nhà phân tích dự án ACAP PCON Tính liên tục Nhân viên PCAP Khả năng lập trình Nhân viên

Hình 26. 10 Chi phí dự án điều khiển PEXP Nhân viên Kinh nghiệm lập trình trong dự án miền Nhân viên Nhà phân tích kinh nghiệm trong dự án miền Nhân viên Ngôn ngữ và kinh nghiệm công cụ AEXP LTEX TOOL Sử dụng công cụ phần mềm Dự án Sự nén chương trình Phát triển. SCED Dự án SITE Dự án Mức độ làm việc cho nhiều trang và chất lượng của các trang web thông tin liên lạc

Hình 26. 11 Ảnh hưởng của điều khiển chi phí dự toán Giá trị số mũ Kích thước hệ thống (bao gồm cả các yếu tố để tái sử dụng và yêu cầu biến động) COCOMO ước tính ban đầu mà không có trình điều khiển chi phí 1. 17 128, 000 DSI 730 người/tháng Độ tin cậy Phức tạp Bộ nhớ hạn chế Công cụ sử dụng Lịch Điều chỉnh dự toán COCOMO Rất cao, hệ số = 1, 39 Rất cao, hệ số = 1, 3 Cao, hệ số = 1, 21 Thấp, hệ số = 1, 12 Tăng tốc, hệ số =1, 29 2306 người/tháng Độ tin cậy Phức tạp Bộ nhớ hạn chế Công cụ sử dụng Lịch Điều chỉnh dự toán COCOMO Rất thấp, hệ số =0, 75 Không, hệ số = 1 Rất cao, hệ số = 0, 72 Bình thường, hệ số =1 295 người/tháng

Hình 26. 11 Ảnh hưởng của điều khiển chi phí dự toán n Các mô hình thuật toán chi phí cung cấp một cơ sở cho dự án quy hoạch vì chúng cho phép thay thế chiến lược được so sánh. Hệ thống nhúng tàu vũ trụ : Ø Phải là đáng tin cậy. Ø Phải giảm thiểu trọng lượng (số lượng chip). Ø Hệ số về chế độ tin cậy và máy tính>1. Chi phí các thành phần: Ø Mục tiêu phần cứng. Ø Phát triển nền tảng. Ø Nỗ lực phát triển.

26. 3. 2 Thuật toán chi phí trong dự án quy hoạch n Các chi phí phần mềm (SC) được tính như sau: Sc=Effort estimate x RELY x TIME x STOR x TOOL x EXP x $15000. n Chú thích: Ø Ø Ø Rely: độ tin cậy. Stor: không gian lưu trữ. Time: thời gian cần thiết. Tool: công cụ. Exp: kinh nghiệm.

Hình 26. 12 Quản lý các tùy chọn

Hình 26. 12 Quản lý các tùy chọn A. Sử dụng các phần cứng, phát triển hệ thống và phát triển đội ngũ B. Xử lý và nâng cấp bộ nhớ C Chỉ nâng cấp bộ nhớ Chi phí phần cứng tăng Kinh nghiệm giảm Chi phí phần cứng tăng D. Các nhân viên có kinh Nghiệm. E. Hệ thống mới phát triển Chi phí phần cứng tăng Kinh nghiệm giảm F. Nhân viên có kinh nghiệm Phần cứng

Hình 26. 13 Quản lý chi phí tùy chọn n Lựa chọn D xuất hiện để cung cấp chi phí thấp nhất cho tất cả các ước tính cơ bản. Lựa chọn C (nâng cấp bộ nhớ) có tiết kiệm chi phí thấp hơn, nhưng nguy cơ rất thấp. Nhìn chung, mô hình này cho thấy tầm quan trọng của đội ngũ nhân viên kinh nghiệm phát triển phần mềm.

26. 4 Nhân lực và thời gian dự án q q q q Cũng như nỗ lực lập dự toán, quản lý phải ước tính thời gian lịch yêu cầu để hoàn thành một dự án. Lịch thời gian có thể được ước tính bằng cách công thức COCOMO 2 : TDEV = 3 x (PM)(0. 33+0. 2*(B-1. 01)) Trong đó: PM là tính toán nỗ lực. B là số mũ. Tính toán này dự báo lịch trình danh nghĩa của dự án. Nhân viên không cần thiết có thể được tính bằng cách lặn thời gian phát triển bởi các yêu cầu tiến độ. Số lượng người làm việc trong một dự án thay đổi tùy theo giai đoạn của dự án. Thời gian cần thiết là độc lập với số lượng người làm việc trên dự án.

Điểm chính q q q q Hiện không phải là một mối quan hệ đơn giản giữa giá tính phí cho một hệ thống và chi phí của nó phát triển. Các yếu tố ảnh hưởng đến năng suất bao gồm năng khiếu cá nhân, kinh nghiệm miền, các dự án phát triển, quy mô dự án, hỗ trợ công cụ và môi trường làm việc. Phần mềm có thể có giá để đạt được một hợp đồng và các chức năng điều chỉnh giá. Các kỹ thuật khác nhau của dự toán chi phí nên được sử dụng khi lập dự toán chi phí. Mô hình COCOMO có dự án, sản phẩm, nhân viên và các thuộc tính phần cứng vào tài khoản khi dự đoán nỗ lực cần thiết. Các mô hình thuật toán chi phí hỗ trợ phân tích định lượng tùy chọn vì chúng cho phép các chi phí của các tùy chọn khác nhau để so sánh. Thời gian để hoàn thành một dự án không tỷ lệ thuận với số người làm việc trên dự án.