Chương 26

( Software cost estimation )

Nhóm 13:
Huỳnh Ngọc Ân MSSV : 070003T
Ngô Thị Mỹ Hạnh MSSV : 070096T
Lê Thị Mỹ Hằng MSSV : 070078T
 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ó.
b. Mô tả các số liệu để đánh giá năng suất phần mềm
c. 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
d. Hiểu các nguyên tắc của mô hình COCOMO II ,thuật toán dự toán
chi phí.
 Nội Dung (Contents)
 26.1 Năng suất (Productivity)

 26.2 Các kỷ thuật ước lượng ( Estimation techniques)

 26.3 Mô hình chi phí thuật toán ( Algorithmic cost

modelling )

 26.4 Nhân lực và thời gian dự án (Project duration and

staffing)
 Nội Dung (Contents)
 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)
 Chi phí chiếm ưu thế là chi phí công sức.
 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.
 Máy tính đủ mạnh để phát triển phần mềm là tương đối rẻ.
Các Thành Phần Chi Phí Của Phần Mềm
 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.
 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.
 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 cá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.
 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í.

 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
 Hình 26.1 yếu tố ảnh hưởng phần mềm giá cả

Yếu Tố (Factor) Mô tả (Description)

-
Cơ hội thị trường - Một tổ chức phát triển có thể báo giá thấp
(Market bởi vì nó muốn tiến xa hơn trong giai đoạn
Opportunity) mới của thị trường phần mềm
 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
- Chi phí ước tính
không chắc chắn phí của nó, nó có thể làm tăng giá của mình bằng
(Cost estimate một số dự phòng trên và cao hơn lợi nhuận bình
uncertainty) 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:

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
 26.1 Năng suất Phần mềm.
 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ị.

 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.

 Ư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.
 Ướ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.
 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.
 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 )
- Kích thướt dự án (Project
size)
- Công nghệ hỗ trợ
(Technology support )
- Môi trường làm việc
(Working environment )
-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)
- 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
triển nên năng suất cá thể là giảm.
-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ó
thể cải thiện năng suất.
-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)
 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.

 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)
 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

 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)
- Ý kiến chuyên gia (Expert
judgement)
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.
-
- 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ự -Kỹ thuật này được áp dụng khi các dự án cùng
(Estimation by analogy) 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.
- Luật Parkinson
--Chi phí phụ thuộc vào thời gian và số nhân
(Parkinson's Law )
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
- Phụ thuộc vào năng lực khách hàng.Những
(Pricing to win)
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ác 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.
 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.
 26.2 Các kỹ thuật ước lượng
(Estimation techniques)
 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,..
 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 SizeB x M
(Nỗ lực)

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
 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

 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
 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.
 Những dữ liệu này được phân tích để tìm ra công thức phù hợp nhất.
 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.

 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.
  Phần mềm hiện nay thường được phát triển bởi

Độ phức tạp dự Công thức Mô tả

án

- Đơn giản PM = 2.4 (KDSI) 1,05 x M -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,
- Vừa phải PM = 3.0 (KDSI) 1,12 x M nơi các thành viên
nhóm có thể giới hạn
về kinh nghiệm

- Chuyên sâu PM = 3.6 (KDSI) 1,20 x M -Kết hợp chặt với nhau
(Lồng nhau) về phần cứng, phần
(KDSI: số lệnh nguồn theo mềm, quy định và thủ
đơn vị nghìn) 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
 Hình 26,7 Các mô hình COCOMO II
 Dựa trên Ứng
Ứng Được dùng Thử nghiệm các hệ thống
Số
Sốđiểm
điểm dụng
dụngmô
môhình
hình phát triển sử dụng kịch
ứng
ứngdụng
dụng Cho.
thành
thànhphần
phần bản, DB lập trình, vv

Dựa trên Được dùng Ước lượng nỗ lực ban

Số điểm Thiết kế mô đầu. dựa vào những yêu
chức năng hình Đầu Cho. cầu hệ thống và những
tùy chọn thiết kế.

Số lượng các Tái sử dụng Được dùng

Dựa trên Nỗ lực để sử dụng lại các
dòng Mã tái mô hình
thành phần hoặc tự động
sử dụng Cho.
tạo ra mã
hoặc tạo ra

Số lượng các Dựa trên Mô hình kiến Được dùng Nỗ lực phát triển dựa trên
dòng mã trúc thiết kế hệ thống
Cho. đặc điểm kỹ thuật
nguồn
 26.3.1 Mô hình COCOMO
 Ứng dụng mô hình thành phần
 Ứ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.
 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.

 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 cng cụ Case.
 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.).
 26.3.1 Mô hình COCOMO
 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
 Hình 26,8 Đối tượng điểm năng suất

Kinh nghiệm, năng lực của nhà Very low Low Nominal High Veryhigh
phát triển

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
 Ước tính có thể thực hiện khi các yêu cầu được đồng ý.

 Ướ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 SizeB 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.
 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.
 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..
 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ợ.
 26.3.1 Mô hình COCOMO
 Tái sử dụng mô hình
 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.
 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.
 Đối với các mã được tự động tạo ra, công thức tính toán nỗ lực là:

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
 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.
 Ướ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.
 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.
 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
 Đá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 Phản ánh mức độ linh hoạt trong quá trình phát
hoạ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ơ Phản ánh mức độ phân tích nguy cơ thực hiện. Rất
giải quyế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 Phản ánh như thế nào nhóm phát triển biết nhau và làm
kết 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:
 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ế

ACAP Năng lực của các nhà

Nhân viên phân tích dự án
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

AEXP
Nhân viên Ngôn ngữ và kinh nghiệm công cụ
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 Mức độ làm việc cho nhiều trang và chất

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

D.Các nhân viên có kinh
Chi phí phần cứng Nghiệm.
Chi phí phần cứng tăng
Kinh nghiệm giảm tăng

E.Hệ thống mới phát triển

F.Nhân viên có kinh nghiệm
Chi phí phần cứng tăng
Phần cứng
Kinh nghiệm giảm
 Hình 26.13 Quản lý chi phí tùy chọ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
 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
 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.