Software cost estimation Mục Tiêu Mục tiêu của chương này là để giới thiệu các kĩ thuật để ước tính chi phí và công sức cần thiết cho sản suất phần mềm .khi bạn đã đọc chương này ,bạn sẽ: ■ Hiểu các nguyên tắc cơ bản của chi phí phần mềm và lý do tại sao giá của phần mềm có thể không liên quan trực tiếp đến chi phí phát triển của nó ■ Đã được giới thiệu với ba số liệu được sử dụng để đánh giá sản xuất phần mềm; ■ Hiểu được tại sao một loạt các kỹ thuật nên được sử dụng khi ước lượng chi phí phần mềm, tiến độ; ■ Hiểu các nguyên tắc của mô hình COCOMO II cho dự toán chi phí thuật toán. Nội dung 26.1 Sản xuất phần mềm 26.2 Kỹ thuật ước lượng 26.3 Mô hình chi phí thuật toán 26.4 Thời hạn dự án và nhân sự •• SE8_C26.qxd 4406 9:20 Page 613 Chapter 26 ■ Software cost estimation 613 Trong chương 5, tôi đã giới thiệu quá trình lập kế hoạch dự án mà các công việc trong một dự án được chia thành một số hoạt động riêng biệt. Điều này thảo luận trước đó của dự án quy hoạch tập trung vào những cách để đại diện cho các hoạt động, sự phụ thuộc của họ và phân bổ nhân dân thực hiện các nhiệm vụ này. Trong chương này, tôi chuyển sang các vấn đề gắn kết các ước tính về sức và thời gian với các hoạt động của dự án. Dự toán bao gồm trả lời các câu hỏi sau: 1. Làm thế nào nhiều công sứcđược yêu cầu để hoàn thành từng hoạt động? 2. Bao nhiêu thời gian lịch là cần thiết để hoàn thành từng hoạt động? 3. Tổng chi phí của từng hoạt động là gì? Dự toán chi phí dự án và lập kế hoạch dự án thường được thực hiện cùng nhau. Các chi phí phát triển chủ yếu là chi phí của các công sứctham gia, vì vậy việc tính toán công sứcđược sử dụng trong cả các chi phí và ước lượng lịch biểu. Tuy nhiên, bạn có thể phải làm một số dự toán chi phí trước khi lị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á cho các phần mềm cho khách hàng. 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: • Phần cứng và phần mềm chi phí bao gồm bảo dưỡng • Phí du lịch và đào tạo • Chi phí công sức(chi phí trả các kỹ sư phần mềm). Đối với hầu hết các dự án, chi phí chiếm ưu thế là chi phí công sức. Máy tính là đủ mạnh mẽ để phát triển phần mềm là tương đối rẻ. Mặc dù chi phí đi lại rộng lớn có thể cần thiết khi một dự án được phát triển tại các địa điểm khác nhau, chi phí đi lại thường là một phần nhỏ của chi phí công sức. Hơn nữa, bằng cách sử dụng hệ thống thông tin liên lạc điện tử như email, các trang web chia sẻ và hội nghị truyền hình có thể làm giảm đáng kể các chuyến du lịch cần thiết. Hội nghị điện tử cũng có nghĩa là thời gian đi du lịch được giảm xuống và thời gian có thể được sử dụng hiệu quả hơn trong việc phát triển phần mềm. Trong một dự án mà tôi từng làm việc, làm cho mỗi cuộc họp khác một cầu truyền hình chứ không phải là một mặt đối mặt đáp ứng giảm chi phí đi lại và thời gian bằng gần 50% Chi phí công sức không chỉ là mức lương của các kỹ sư phần mềm có liên quan đến dự án. Các tổ chức tính toán chi phí công sứcvề chi phí trên không, nơi họ có tổng chi phí điều hành tổ chức và phân chia này bằng số lượng nhân viên sản xuất. Do đó, các chi phí sau đây đều là một phần của tổng chi phí hiệu quả như: 1. Chi phí của việc cung cấp, sưởi ấm và chiếu sáng không gian văn phòng 2. Chi phí nhân viên hỗ trợ như kế toán, quản trị, quản lý hệ thống, chất tẩy rửa và kỹ thuật 3. Chi phí của mạng và truyền thong. SE8_C26.qxd 4406 9:20 Page 614 614 Chapter 26 ■ Software cost estimation 4. Chi phí của các cơ sở trung ương như một thư viện hoặc các cơ sở giải trí. 5. Chi phí an sinh xã hội và lợi ích người lao động như lương hưu và bảo hiểm y tế Yếu tố chi phí này thường là ít nhất gấp hai lần mức lương kỹ sư phần mềm, tùy thuộc vào kích thước của các tổ chức và các chi phí liên quan của nó. Vì vậy, nếu một công ty trả tiền cho một kỹ sư phần mềm 90,000 mỗi năm, tổng chi phí của nó là ít nhất 180,000 mỗi năm hoặc 15.000 mỗi tháng. Khi một dự án đang được tiến hành, quản lý dự án phải thường xuyên cập nhật các dự toán chi phí và lịch trình của họ. Điều này giúp với 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 so với ước tính đáng kể, sau đó người quản lý dự án phải có hành động. Điều này có thể liên quan đến việc áp dụng thêm nguồn lực cho các dự án hoặc thay đổi công việc phải được thực hiện. Phần mềm chi phí nên được canied ra một cách khách quan với mục tiêu chính xác được chuẩn dicting chi phí phát triển phần mềm. Nếu chi phí của dự án đã được tính toán như là một phần của một dự án thầu cho một khách hàng, một quyết định sau đó đã được thực hiện về giá báo cho khách hàng. Cổ điển, giá cả chỉ đơn giản là chi phí cộng với lợi nhuận. Tuy nhiên, mối quan hệ giữa chi phí dự án và giá cho khách hàng thường không phải là đơn giản như vậy. Giá phần mềm phải đưa vào trương mục của tổ chức, kinh tế, chính trị và kinh doanh xem xét rộng hơn, chẳng hạn như những người trong hình 26.1. Do đó, có thể không có một mối quan hệ đơn giản giữa giá cả cho khách hàng đối với các phần mềm và các chi phí phát triển. Bởi vì trong những cân nhắc tổ chức có liên quan, giá dự án nên liên quan đến quản lý cấp cao (tức là, những người có thể đưa ra quyết định chiến lược), cũng như các nhà quản lý dự án phần mềm. Ví dụ, nói một dịch vụ dầu khí công ty phần mềm nhỏ sử dụng 10 kỹ sư vào đầu của một năm, nhưng chỉ có hợp đồng xảy ra đòi hỏi 5 thành viên của đội ngũ phát triển. Tuy nhiên, nó đang đấu thầu một hợp đồng rất lớn với một công ty dầu mỏ lớn đòi hỏi phải có 30 năm người công sứctrong 2 năm. Dự án sẽ không bắt đầu lên trong ít nhất 12 tháng, nhưng nếu được phép, nó sẽ chuyển đổi các tài chính của các công ty nhỏ. Các công ty dịch vụ dầu khí được một cơ hội để chào giá trên một dự án đòi hỏi 6 người và phải được hoàn thành trong 10 tháng. Các chi phí (chi phí chung bao gồm cả những dự án này) được ước tính khoảng 1.2 triệu. Tuy nhiên, để nâng cao vị thế cạnh tranh, các công ty dịch vụ dầu khí chào giá một mức giá để khách hàng của 0.800.000 . Điều này có nghĩa rằng, mặc dù nó mất tiền trên hợp đồng này, nó có thể giữ được nhân viên chuyên cho các dự án có lợi nhuận nhiều hơn trong tương lai.
Trang 1Software cost estimation
Mục Tiêu
Mục tiêu của chương này là để giới thiệu các kĩ thuật để ước tính chi phí và công sức cần thiết cho sản suất phần mềm khi bạn đã đọc chương này ,bạn sẽ:
■ Hiểu các nguyên tắc cơ bản của chi phí phần mềm và lý do tại sao giá của phần mềm có thể không liên quan trực tiếp đến chi phí phát triển của
•
Trang 2SE8_C26.qxd 4/4/06 9:20 Page 613
Chapter 26 ■ Software cost estimation 613
Trong chương 5, tôi đã giới thiệu quá trình lập kế hoạch dự án mà các công việc trong một dự án được chia thành một số hoạt động riêng biệt Điều này thảo luận trước đó của dự án quy hoạch tập trung vào những cách để đại diện cho các hoạt động, sự phụ thuộc của họ và phân bổ nhân dân thực hiện các nhiệm vụ này Trong chương này, tôi chuyển sang các vấn đề gắn kết các ước tính về sức và thời gian với các hoạt động của dự án Dự toán bao gồm trả lời các câu hỏi sau:
1 Làm thế nào nhiều công sứcđược yêu cầu để hoàn thành từng hoạt động?
2 Bao nhiêu thời gian lịch là cần thiết để hoàn thành từng hoạt động?
3 Tổng chi phí của từng hoạt động là gì?
Dự toán chi phí dự án và lập kế hoạch dự án thường được thực hiện cùng nhau Các chi phí phát triển chủ yếu là chi phí của các công sứctham gia, vì vậy việc tính toán công sứcđược sử dụng trong cả các chi phí và ước lượng lịch biểu Tuy nhiên, bạn có thể phải làm một số dự toán chi phí trước khi lị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á cho các phần mềm cho khách hàng
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:
• Phần cứng và phần mềm chi phí bao gồm bảo dưỡng
• Phí du lịch và đào tạo
• Chi phí công sức(chi phí trả các kỹ sư phần mềm)
Đối với hầu hết các dự án, chi phí chiếm ưu thế là chi phí công sức Máy tính là
đủ mạnh mẽ để phát triển phần mềm là tương đối rẻ Mặc dù chi phí đi lại rộng lớn
có thể cần thiết khi một dự án được phát triển tại các địa điểm khác nhau, chi phí đi lại thường là một phần nhỏ của chi phí công sức Hơn nữa, bằng cách sử dụng hệ thống thông tin liên lạc điện tử như email, các trang web chia sẻ và hội nghị truyền hình có thể làm giảm đáng kể các chuyến du lịch cần thiết Hội nghị điện tử cũng
có nghĩa là thời gian đi du lịch được giảm xuống và thời gian có thể được sử dụng hiệu quả hơn trong việc phát triển phần mềm Trong một dự án mà tôi từng làm việc, làm cho mỗi cuộc họp khác một cầu truyền hình chứ không phải là một mặt đối mặt đáp ứng giảm chi phí đi lại và thời gian bằng gần 50%
Chi phí công sức không chỉ là mức lương của các kỹ sư phần mềm có liên quan đến dự án Các tổ chức tính toán chi phí công sứcvề chi phí trên không, nơi họ có tổng chi phí điều hành tổ chức và phân chia này bằng số lượng nhân viên sản xuất
Do đó, các chi phí sau đây đều là một phần của tổng chi phí hiệu quả như:
1 Chi phí của việc cung cấp, sưởi ấm và chiếu sáng không gian văn phòng
2 Chi phí nhân viên hỗ trợ như kế toán, quản trị, quản lý hệ thống, chất tẩy rửa
và kỹ thuật
3 Chi phí của mạng và truyền thong
Trang 3614 Chapter 26 ■ Software cost estimation
4 Chi phí của các cơ sở trung ương như một thư viện hoặc các cơ sở giải trí
5 Chi phí an sinh xã hội và lợi ích người lao động như lương hưu và bảo hiểm y
tế
Yếu tố chi phí này thường là ít nhất gấp hai lần mức lương kỹ sư phần mềm, tùy thuộc vào kích thước của các tổ chức và các chi phí liên quan của nó Vì vậy, nếu một công ty trả tiền cho một kỹ sư phần mềm $ 90,000 mỗi năm, tổng chi phí của
nó là ít nhất $ 180,000 mỗi năm hoặc $ 15.000 mỗi tháng
Khi một dự án đang được tiến hành, quản lý dự án phải thường xuyên cập nhật các dự toán chi phí và lịch trình của họ Điều này giúp với 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 so với ước tính đáng kể, sau đó người quản lý dự án phải có hành động Điều này có thể liên quan đến việc áp dụng thêm nguồn lực cho các dự án hoặc thay đổi công việc phải được thực hiện
Phần mềm chi phí nên được canied ra một cách khách quan với mục tiêu chính xác được chuẩn dicting chi phí phát triển phần mềm Nếu chi phí của dự án đã được tính toán như là một phần của một dự án thầu cho một khách hàng, một quyết định sau đó đã được thực hiện về giá báo cho khách hàng Cổ điển, giá cả chỉ đơn giản
là chi phí cộng với lợi nhuận Tuy nhiên, mối quan hệ giữa chi phí dự án và giá cho khách hàng thường không phải là đơn giản như vậy
Giá phần mềm phải đưa vào trương mục của tổ chức, kinh tế, chính trị và kinh doanh xem xét rộng hơn, chẳng hạn như những người trong hình 26.1 Do đó, có thể không có một mối quan hệ đơn giản giữa giá cả cho khách hàng đối với các phần mềm và các chi phí phát triển Bởi vì trong những cân nhắc tổ chức có liên quan, giá dự án nên liên quan đến quản lý cấp cao (tức là, những người có thể đưa
ra quyết định chiến lược), cũng như các nhà quản lý dự án phần mềm
Ví dụ, nói một dịch vụ dầu khí công ty phần mềm nhỏ sử dụng 10 kỹ sư vào đầu của một năm, nhưng chỉ có hợp đồng xảy ra đòi hỏi 5 thành viên của đội ngũ phát triển Tuy nhiên, nó đang đấu thầu một hợp đồng rất lớn với một công ty dầu mỏ lớn đòi hỏi phải có 30 năm người công sứctrong 2 năm Dự án sẽ không bắt đầu lên trong ít nhất 12 tháng, nhưng nếu được phép, nó sẽ chuyển đổi các tài chính của các công ty nhỏ Các công ty dịch vụ dầu khí được một cơ hội để chào giá trên một dự
án đòi hỏi 6 người và phải được hoàn thành trong 10 tháng Các chi phí (chi phí chung bao gồm cả những dự án này) được ước tính khoảng $ 1.2 triệu Tuy nhiên,
để nâng cao vị thế cạnh tranh, các công ty dịch vụ dầu khí chào giá một mức giá để khách hàng của 0.800.000 $ Điều này có nghĩa rằng, mặc dù nó mất tiền trên hợp đồng này, nó có thể giữ được nhân viên chuyên cho các dự án có lợi nhuận nhiều hơn trong tương lai
26.1 Sản suất phần mềm
• •
Trang 4SE8_C26.qxd 4/4/06 9:20 Page 615
26.1 ■ Software productivity 615
Ảnh hưởng đến giá
Phần mềm Cơ hội thị trường Tổ chức phát triển có thể trích dẫn một mức giá thấp bởi vì nó
muốn di chuyển vào một phân khúc 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ể cung cấp cho tổ chức các cơ hội để tạo ra lợi nhuận lớn hơn sau này Những kinh nghiệm thu cũng có thể giúp nó phát triển sản phẩm mới
Chi phí ước tính không chắc chắn Nếu một tổ chức là 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 nó bởi một số dự hơn và trên lợi
nhuận bình thường của nó
Điều kiện hợp đồng Một khách hàng có thể sẵn sàng để cho phép các nhà phát triển
để giữ lại quyền sở hữu của mã nguồn và tái sử dụng nó trong các dự án khác Giá tính sau đó có thể ít hơn nếu mã nguồn phần mềm được bàn giao cho khách hàng
Yêu cầu biến động Nếu các yêu cầu có khả năng thay đổi, một tổ chức có thể giảm
giá để giành chiến thắng một hợp đồng Sau khi hợp đồng được trao giải thưởng, giá cao có thể bị tính phí cho những thay đổi trong yêu cầu
Sức khỏe tài chính Các nhà phát triển đang gặp khó khăn về tài chính có thể làm giảm giá của họ để đạt được một hợp đồng Nó là tốt hơn để
tạo ra lợi nhuận nhỏ hơn bình thường hoặc thậm chí phá vỡ hơn để đi ra khỏi kinh doanh
Bạn có thể đo lường hiệu quả trong một hệ thống sản xuất bằng cách đếm số lượng các đơn vị được sản xuất và phân chia này bằng số giờ người cần để sản xuất chúng Tuy nhiên, đối với bất kỳ vấn đề phần mềm, có nhiều giải pháp khác nhau, mỗi trong số đó có các thuộc tính khác nhau Một giải pháp có thể thực hiện quả hơn ciently trong khi người khác có thể dễ đọc hơn và dễ dàng hơn để duy trì Khi các giải pháp với các thuộc tính khác nhau được sản xuất, so sánh tỷ lệ sản xuất của
họ không thực sự có ý nghĩa
Tuy nhiên, như một người quản lý dự án, bạn có thể phải đối mặt với các vấn đề của ước tính hợp tác năng suất của các kỹ sư phần mềm Bạn có thể cần những những tính toán năng suất để giúp xác định các chi phí hoặc tiến độ dự án, để thông báo quyết định đầu tư hoặc để đánh giá xem liệu quá trình hoặc công nghệ cải tiến
có hiệu quả
Ước tính năng suất thường dựa vào đo lường các thuộc tính của phần mềm và cách chia này bằng tổng số công sứccần thiết để phát triển Có hai loại chỉ số này
đã được sử dụng:
1 Size-related metrics Kích thước liên quan đến các số liệu này có liên quan đến
kích thước của một số đầu ra từ một hoạt động Thường được sử dụng hầu hết các kích thước liên quan đến metric là dòng mã nguồn giao Các số liệu khác
mà có thể được sử dụng là số lượng các hướng dẫn mã đối tượng được chuyển giao hoặc số trang của tài liệu hệ thống
2 Function-related metrics Số liệu chức năng liên quan đến những liên quan đến
các chức năng tổng thể của phần mềm được gửi Năng suất được biểu diễn dưới dạng số chức năng hữu ích được sản xuất trong một thời gian nhất định Điểm chức năng và các điểm đối tượng là những số liệu nổi tiếng nhất của loại hình này
Trang 5616 Chapter 26 ■ Software cost estimation.
Dòng mã nguồn lập trình mỗi tháng (LOC/pm) là một suất đồ mềm sử dụng rộng rãi metric Bạn có thể tính LOC/pm bằng cách đếm tổng số dòng mã nguồn được chuyển giao, sau đó chia cho số bằng tổng thời gian trong tháng lập trình cần thiết
để hoàn thành dự án Lần này vì vậy bao gồm thời gian cần thiết cho tất cả các hoạt động khác (yêu cầu, thiết kế, mã hóa, kiểm tra và tài liệu) tham gia phát triển phần mềm
Cách tiếp cận này lần đầu tiên được phát triển khi lập trình nhất là trong FORTRAN, ngôn ngữ lắp ráp hoặc COBOL Sau đó, chương trình đã được đánh máy trên thẻ, với một tuyên bố trên mỗi thẻ Số lượng các dòng mã đã được dễ dàng để đếm: Nó tương ứng với số lượng thẻ trong boong chương trình Tuy nhiên, các chương trình trong ngôn ngữ như Java hay C ++ bao gồm tờ khai, báo cáo thực thi và bình luận Họ có thể bao gồm các hướng dẫn vĩ mô mà mở rộng đến một vài dòng mã Có thể có nhiều hơn một tuyên bố trên mỗi dòng Không có, do đó, một mối quan hệ đơn giản giữa các báo cáo chương trình và đường vào một danh sách
So sánh năng suất giữa các ngôn ngữ lập trình cũng có thể cung cấp cho ấn tượng sai lệch về năng suất lập trình Các biểu cảm hơn những ngôn ngữ lập trình, thấp hơn năng suất rõ ràng Sự bất thường này phát sinh bởi vì tất cả các hoạt động phát triển phần mềm được xem xét cùng nhau khi tính toán thời gian phát triển, nhưng các số liệu LOC chỉ áp dụng cho các quá trình lập trình Vì vậy, nếu một trong những ngôn ngữ đòi hỏi dòng hơn nữa để thực hiện các chức năng tương tự, ước tính năng suất sẽ là bất thường
Ví dụ: hãy xem xét một hệ thống thời gian thực nhúng có thể được mã hóa trong
5.000 dòng mã lắp ráp hoặc 1.500 dòng C Thời gian phát triển cho các giai đoạn khác nhau được thể hiện trong hình 26.2 Các lập trình lắp ráp có một suất 714 lineslmonth và mức độ cao lập trình ngôn ngữ ít hơn một nửa trong số 300 lineslmonth này Tuy nhiên, các chi phí phát triển cho các hệ thống phát triển trong
C thấp hơn và nó được gửi trước đó
Một thay thế cho sử dụng mã kích thước như các thuộc tính sản phẩm ước tính
là sử dụng một số biện pháp của các chức năng của mã Điều này tránh sự bất thường trên, như chức năng độc lập với ngôn ngữ thực hiện MacDonell (MacDonell 1994) mô tả ngắn gọn và so sánh một số biện pháp dựa trên chức năng Tốt nhất được biết đến của các biện pháp này là số lượng điểm chức năng
Điều này đã được đề xuất bởi Albrecht (Albrecht 1979) và tinh chế bởi Albrecht
và Gaffney (Albrecht và Gaffney, 1983) Garmus và Herron (Garmus và Herron, 2000) mô tả việc sử dụng thực tế của các điểm chức năng trong các dự án phần mềm
Năng suất được thể hiện như số lượng các điểm chức năng được thực hiện mỗi tháng người Một điểm chức năng không phải là một đặc tính riêng biệt nhưng được tính toán bằng cách kết hợp các phép đo khác nhau hoặc dự toán Bạn tính tổng số điểm chức năng trong một chương trình bằng cách đo hoặc ước lượng các tính năng chương trình sau đây:
• •
Trang 6Ngiên cứu Thiết kế Mã hóa Kiểm thử Làm tài liệu
Ngôn ngữ bậc cao 3 Tuần 5 Tuần 4 Tuần 6 Tuần 2 Tuần
Kích thước Hoàn thành Năng suất
Ngôn ngữ bậc cao 1500 dòng 20 Tuần 300 dòng /tháng
• Đầu vào và ra bên ngoài;
• Tương tác với người dùng;
• Giao diện bên ngoài;
• Những file được sử dụng bởi hệ thống
Rõ ràng, một số yếu tố đầu vào và đầu ra, tương tác, phức tạp hơn hẳn chức năng khác và mất nhiều thời gian để thực hiện Các điểm chức năng metric cần đưa vào sự đánh giá bằng cách nhân ước tính số điểm chức năng ban đầu với một trọng số phức tạp Bạn nên đánh giá mỗi tính năng bởi sự phức tạp và sau đó gán trọng số cho các nhân bắt đầu từ 3 (cho đầu vào bên ngoài đơn giản) đến 15 cho tập tin bên trong phức tạp Hoặc là giá trị trọng số Albrecht hoặc giá trị dựa trên kinh nghiệm nội bộ có thể được sử dụng
Sau đó bạn có thể tính toán cái gọi là điểm chức năng chưa điều chỉnh (UFC) bằng cách nhân mỗi số đếm ban đầu với trọng số ước tính và tính tổng tất
cả các giá trị
UFC = ∑(số yếu tố của loại nhất định) x (trọng số) Sau đó bạn sửa đổi số điểm chức năng chưa điều chỉnh của các tác nhân phức tạp hơn có liên quan đến sự phức tạp của toàn thể hệ thống Điều này sẽ đưa vào trương mục các mức độ xử lý phân tán, tái sử dụng, hiệu suất, và v.v… Các điểm chức năngchưa hiệu chỉnh được nhân với các yếu tố phức tạp của dự án để tạo
ra một số điểm chức năng cuối cùng cho toàn bộ hệ thống
Symons (Symons, 1988) lưu ý rằng tính chất chủ quan của sự ước lượng phức tạp có nghĩa là số lượng chức năng trong chương trình phụ thuộc vào sự ước lượng Những người khác nhau có quan niệm khác nhau về độ phức tạp Do đó có sự khác biệt lớn trong số điểm chức năng tùy thuộc vào sự phán đoán ước lượng và kiểu hệ thống được phát triển Hơn nữa, điểm chức năng thiên về hệ thống xử lý dữ liệu bị chi phối bởi các hoạt động đầu vào và đầu ra Nó rất khó để ước tính số lượng điểm chức năng cho các hệ thống hướng sự kiện Vì lý do này, một số người nghĩ rằng điểm chức năng không phải là một cách hay để đo lường năng suất phần mềm (Furey và Itchenham, 1997; Amour, 2002) Tuy nhiên, người sử dụng các điểm chức năng cho rằng, mặc dù có khiếm khuyết, nó vẫn có hiệu quả trong các tình huống thực tế (Banker, et al, 1993; Garmus và Herron, 2000)
Trang 7618 Chapter 26 ■ Software cost estimation
Điểm đối tượng (Banker, et al., 1994) là một thay thế cho điểm chức năng
Chúng có thể được sử dụng với các ngôn ngữ như: ngôn ngữ lập trình cơ sở dữ liệu
vs ngôn ngữ kịch bản Điểm đối tượng không phải là đối tượng các lớp mà có thể được tạo ra khi một phương thức hướng đối tượng được thực hiện để phát triển phần mềm Thay vào đó, số lượng các điểm đối tượng trong một chương trình là một ước tính trọng số của:
1 The number of separate screens that are displayed (Số lượng màn hình riêng
biệt được hiển thị )màn hình đơn giản được tính là 1 điểm đối tượng, màn hình phức tạp hơn được tính là 2, và màn hình rất phức tạp được tính là 3 điểm đối tượng
2 The number of reports that are produced (Số báo cáo được tạo ra) Đối với báo
cáo đơn giản, tính 2 điểm đối tượng, cho các báo cáo phức tạp vừa phải, 5 điểm, và cho các báo cáo rằng có thể sẽ là khó tạo ra, đếm 8 điểm đối tượng
3 The number of modules in imperative programming languages such as Java or
C++ that must be developed to supplement the database programming code
(Số lượng các mô-đun trong ngôn ngữ lập trình mệnh lệnh như Java hay C ++
mà phải được phát triển để bổ sung các mã lập trình cơ sở dữ liệu) Mỗi module được tính là 10 điểm đối tượng
Điểm đối tượng được sử dụng trong tính toán mô hình COCOMO II (nơi chúng được gọi là các điểm ứng dụng) mà tôi bao gồm trong chương này Lợi thế của điểm đối tượng trên các điểm chức năng là nó dễ dàng ướ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, các báo cáo
và các module trong ngôn ngữ lập trình thông thường Nó không quan tâm đến chi tiết thực hiện, và ước tính yếu tố phức tạp là đơn giản hơn nhiều
Nếu điểm chức năng hoặc điểm đối tượng được sử dụng, chúng có thể được ước lượng ở giai đoạn đầu trong quá trình phát triển trước khi quyết định có ảnh hưởng đến kích thước chương trình được thực hiện Ước tính của các thông số này có thể được thực hiện ngay sau khi sự tương tác bên ngoài của hệ thống đã được thiết kế
Ở giai đoạn này, nó là rất khó để tạo ra một sự ước lượng chính xác về kích thước của một chương trình trong các dòng mã nguồn
Điểm chức năng và số lượng đối tượng điểm có thể được sử dụng kết hợp với dây chuyền của các mô hình mã ước lượng Kích thước mã cuối cùng được tính từ
số lượng các điểm chức năng Sử dụng lịch sử phân tích dữ liệu, con số trung bình của các dòng lệnh, AVC, trong một ngôn ngữ đặc biệt cần thiết để thực hiện một điểm chức năng có thể được ước tính Giá trị của AVC khác nhau từ 200-300 LOCIFP trong ngôn ngữ lắp ráp để 2-40 LOCFP cho một ngôn ngữ lập trình cơ sở
dữ liệu như SQL Các ước tính kích thước các mã lệnh cho một ứng dụng mới sau
đó được tính như sau:
Kích thước mã = AVC x số điểm chức năng 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ố Một số trong những yếu tố quan trọng nhất được tóm tắt trong hình 26.3 Tuy nhiên, những khác biệt trong khả năng thường lớn hơn so với bất kỳ yếu
tố nào
Trang 8SE8_C26.qxd 4/4/06 9:20 Page 619
26.1 ■ Software productivity 619
Hình 26.3 Các yếu tố
ảnh hưởng đến năng suất kỹ thuật phần mềm
Kinh Nghiệm miền ứng dụng Kiến thức của miền ứng dụng là điều cần thiết cho sự phát triển phần mềm hiệu quả Kỹ sư người đã hiểu một miền có thể sẽ là
hiệu quả nhất.
chất lượng quy trình Quá trình phát triển sử dụng có thể có một tác động đáng kể đến
năng suất Điều này được đề cập trong Chương 28.
Kích cỡ dự án Lớn hơn một dự án, thời gian hơn cần thiết cho thông tin liên lạc
đồng đội Ít thời gian có sẵn để phát triển nên năng suất cá thể
bị giảm.
Công nghệ hỗ trợ 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ôi trường làm việc Như tôi đã thảo luận ở chương 25, một môi trường làm việc yên
tĩnh với các khu vực làm việc riêng góp phần cải thiện năng suất.
Trong một đánh giá ban đầu về năng suất, Sackrnan et al (Sackman, et al., 1968) phát hiện ra rằng một số lập trình viên có năng suất cao hơn 10 lần những người khác Theo kinh nghiệm của tôi điều này vẫn đúng Các đội lớn có thể có một sự kết hợp của khả năng và kinh nghiệm do đó sẽ có năng suất 'trung bình' Trong các đội nhỏ, tuy nhiên năng suất tổng thể chủ yếu phụ thuộc vào năng khiếu và khả năng của cá nhân
Năng suất phát triển phần mềm thay đổi đáng kể trên các lĩnh vực ứng dụng và các tổ chức Đối với lớn, phức tạp, hệ thống nhúng, năng suất đã được ước tính là thấp như 30 LOC/pm Để đơn giản, hệ thống ứng dụng được tìm hiểu, viết bằng một ngôn ngữ như Java, nó có thể cao như 900 LOC/pm Khi đo về số điểm đối tượng, Boehm et al (Boehm, et a]., 1995) cho thấy rằng năng suất dao động từ 4 điểm đối tượng mỗi tháng đến 50 điểm mỗi tháng, tùy thuộc vào loại ứng dụng, công cụ hỗ trợ và khả năng phát triển
Vấn đề với các biện pháp dựa vào số lượng sản xuất trong một khoảng thời gian nhất định là họ sẽ không có trương mục của các đặc tính chất lượng như độ tin cậy
và khả năng bảo trì Nó chứng tỏ rằng nhiều hơn luôn luôn có nghĩa là tốt hơn Beck (Beck, 2000), trong cuộc thảo luận của ông về lập trình cực đoan, tạo ra một điểm nhấn tuyệt vời về ước lượng Nếu phương pháp của bạn được dựa trên mã đơn giản hóa và cải tiến liên tục, do đó đếm dòng mã không có nhiều ý nghĩa.Những biện pháp này cũng không tính đến khả năng tái sử dụng các phần mềm
đã được tạo ra, sử dụng mã máy và các công cụ khác giúp tạo ra các phần mềm Các chi phí phát sinh một hệ thống đặc biệt với chức năng nhất định, chất lượng, hiệu suất, bảo trì, và v.v… những gì chúng ta thực sự muốn ước lượng Đây là chỉ liên quan gián tiếp đến các biện pháp hữu hình như kích thước của hệ thống
Là nhà quản lý, bạn không nên sử dụng các phép đo năng suất để có những phán đoán thiếu cân nhắc về khả năng của các kỹ sư trong nhóm của bạn Nếu bạn làm thế, các kỹ sư có thể làm ảnh hưởng về chất lượng để trở thành nhiều người ‘năng suất cao’
Trang 9620 Chapter 26 ■ Software cost estimation
Nó có thể là trường hợp mà các người lập trình ‘năng suất kém’ viết mã đáng tin cậy hơn - mã số đó là dễ hiểu hơn và rẻ hơn để duy trì Bạn nên luôn luôn, do đó, nghĩ rằng việc đo lường năng suất như cung cấp một phần thông tin về năng suất người lập trình Bạn cũng cần phải xem xét các thông tin khác về chất lượng của các chương trình được sản xuất
26.2 Kỹ thuật ước lượng
Không có cách nào đơn giản ước lượng chính xác của các công sức cần thiết để phát triển một hệ thống phần mềm Bạn có thể phải có những ước tính ban đầu trên
cơ sở yêu cầu level cao mà người sử dụng định nghĩa Phần mềm này có thể chạy trên các máy khác nhau hoặc sử dụng công nghệ phát triển mới Những người tham gia dự án và kỹ năng của họ có thể sẽ không được biết đến Tất cả những điều đó
có nghĩa là nó không thể ước tính chi phí phát triển hệ thống chính xác ở giai đoạn đầu trong một dự án
Hơn nữa, có một khó khăn cơ bản trong việc đánh giá độ chính xác của các phương pháp tiếp cận khác nhau đến các kỹ thuật ước lượng chi phí Ước lượng dự
án được thực hiện thường xuyên Các ước tính sử dụng để xác định ngân sách dự
án, và các sản phẩm được điều chỉnh sao cho các con số ngân sách được nhận ra
Tôi không biết về bất kỳ thử nghiệm kiểm soát chi phí dự án, nơi chi phí ước lượng không ảnh hưởng đến thử nghiệm Một thử nghiệm kiểm soát sẽ không tiết
lộ các chi phí ước lượng quản lý dự án Các chi phí thực tế sau đó sẽ được so sánh với chi phí ước lượng của dự án Tuy nhiên, một thử nghiệm như vậy có lẽ là không thể vì chi phí cao có liên quan đến số lượng các biến mà không thể kiểm soát được
Tuy nhiên, các tổ chức cần phải có sự công sứcphần mềm và dự toán chi phí Để làm như vậy, một hoặc nhiều hơn các kỹ thuật được có thể sử dụng được mô tả trong hình 26.4 (Boehm 1981) Tất cả những kỹ thuật dựa trên phán đoán, dựa trên kinh nghiệm của các nhà quản lý dự án, sử dụng kiến thức của họ về các dự án trước đó để đi đến một ước tính của các nguồn lực cần thiết cho dự án Tuy nhiên,
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 Hệ thống phân phối đối tượng chứ không phải là hệ thống máy tính lớn
2 Sử dụng dich vụ web
3 Sử dụng ERP hoặc các hệ thống cơ sở dữ liệu trung tâm
4 Sử dụng phần mềm off-the-shelf hơn là phát triển hệ thống ban đầu
5 Phát triển cho nó và với tái sử dụng chứ không phải là sự phát triển mới của tất
cả các bộ phận của một hệ thống
Trang 10SE8_C26.qxd 4/4/06 9:20 Page 621
26.2 ■ Estimation techniques 621
Figure 26.4 Kỹ thuật Kỹ thuật Mô tảƯớc lượng
Chi phí Mô hình thuật toán
chi phí Một mô hình được phát triển bằng cách sử dụng lịch sử các thông tin chi phí có liên quan đến một số phần mềm số liệu (thường là kích
thước của nó) vào chi phí dự án Một số ước tính được làm bằng chỉ
số này và các mô hình dự đoán các công sức cần thiết
Phán đoán chuyên gia Một số chuyên gia về kỹ thuật phát triển phần mềm và đề xuất các
miền ứng dụng được tham khảo ý kiến Họ từng ước tính chi phí của
dự án Những ước tính này được so sánh và thảo luận Việc lặp quá trình lập dự toán cho đến khi ước tính thống nhất là đạt
Ước lượng bằng sự tương tự
Kỹ thuật này được áp dụng khi các dự án khác trong cùng miền ứng dụng đã được hoàn thành Chi phí của một dự án mới được ước tính bằng cách tương tự với các dự án đã hoàn thành Myers (Myers, 1989) đưa ra một mô tả rất rõ ràng của phương pháp này
Luật Parkinson Parkinson's Law nói rằng việc mở rộng để lấp đầy thời gian có sẵn
Các chi phí được xác định bởi nguồn lực sẵn có chứ không phải bằng cách đánh giá khách quan Nếu phần mềm đã được giao trong
12 tháng và có sẵn 5 người, các công sứccần thiết được ước tính là
60 người-tháng
Pricing to win
Chi phí phần mềm được ước tính là bất cứ điều gì khách hàng đã có sẵn để chi cho dự án Các công sức ước tính 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
6 Phát triển bằng cách sử dụng ngôn ngữ lập trình như TCL hoặc Perl (Ousterhout, 1998)
7 Việc sử dụng các công cụ CASE và phát triển chương trình chứ không phải là phát triển phần mềm không được hỗ trợ
Nếu các nhà quản lý dự án đã không làm việc với những kỹ thuật, kinh nghiệm trước đây của họ có thể không giúp đỡ họ ước tính chi phí dự án phần mềm Điều này làm nó khó khăn hơn cho họ để tính ra chi phí chính xác và ước tính thời hạn Bạn có thể giải quyết các phương pháp tiếp cận chi phí dự toán thể hiện trong hình 26.4 bằng cách sử dụng một phương pháp từ trên xuống hoặc một phương pháp tiếp cận từ dưới lên Một cách tiếp cận từ trên xuống bắt đầu ở cấp độ hệ thống Bạn bắt đầu bằng cách kiểm tra các chức năng tổng thể của sản phẩm và làm thế nào các chức năng được cung cấp bằng cách tương tác chức năng phụ Các chi phí của các hoạt động hệ thống cung cấp như tích hợp, quản lý cấu hình và tài liệu được thực hiện và đưa vài trương mục
Các phương pháp tiếp cận từ dưới lên, ngược lại, nó bắt đầu ở cấp thành phần
Hệ thống này được phân rã thành các thành phần, và bạn ước lượng công sức cần thiết để phát triển mỗi thành phần này Sau đó bạn thêm các thành phần chi phí để tính toán các công sức cần thiết cho sự phát triển toàn bộ hệ thống
Trang 11622 Chapter 26 ■ Software cost estimation
Các nhược điểm của phương pháp tiếp cận từ trên xuống là những lợi thế của phương pháp tiếp cận từ dưới lên và ngược lại Dự toán từ trên xuống có thể đánh giá thấp những chi phí của việc giải quyết các vấn đề kỹ thuật khó khăn kết hợp với các thành phần cụ thể như giao diện cho phần cứng không theo tiêu chuẩn Không
có lý giải chi tiết cho dự toán được tao ra Ngược lại, ước tính từ dưới lên tạo ra một sự biện minh và xem xét từng thành phần Tuy nhiên, phương pháp này có nhiều khả năng để đánh giá thấp những chi phí của các hoạt động hệ thống như tích hợp Dự toán từ dưới lên cũng tốn kém hơn Phải có hệ thống thiết kế ban đầu để xác định các thành phần để được dự trù kinh phí
Mỗi kỹ thuật ước lượng có điểm mạnh và điểm yếu riêng Mỗi cách sử dụng thông tin khác nhau về dự án và đội ngũ phát triển, vì vậy nếu bạn sử dụng một
mô hình duy nhất và thông tin này là không chính xác, ước tính cuối cùng của bạn
sẽ là sai lầm Đối với các dự án lớn, do đó, bạn nên sử dụng một số kỹ thuật dự toán chi phí và so sánh kết quả của họ Nếu những dự đoán chi phí hoàn toàn khác nhau, có thể bạn không có đủ thông tin về các sản phẩm hoặc quá trình phát triển.Bạn nên tìm kiếm thêm thông tin về sản phẩm, quá trình hoặc nhóm và lặp lại quá trình cho đến khi chi phí dự toán hội tụ
Những kỹ thuật ước lượng được áp dụng khi một tài liệu yêu cầu đối với hệ thống đã được sản xuất Điều này cần xác định tất cả người sử dụng và yêu cầu hệ thống Do đó, bạn có thể làm cho một ước tính hợp lý của các chức năng hệ thống là phải được phát triển Nói chung, các hệ thống lớn các dự án kỹ thuật sẽ
có một tài liệu yêu cầu
Tuy nhiên, trong nhiều trường hợp, các chi phí của nhiều dự án phải được ước tính bằng cách sử dụng chỉ yêu cầu người sử dụng không đầy đủ cho hệ thống
Điều này có nghĩa rằng các ước lượng có rất ít thông tin nào đó để làm việc Phân tích yêu cầu và đặc điểm kỹ thuật là tốn kém, và các nhà quản lý trong một công ty có thể cần một ước tính chi phí ban đầu cho hệ thống trước khi họ có thể
có một ngân sách đã được phê duyệt để phát triển các yêu cầu chi tiết hơn hoặc một nguyên mẫu hệ thống
Trong hoàn cảnh này, "giá cả để giành chiến thắng" là một chiến lược thường được sử dụng Các khái niệm về giá cả để giành chiến thắng có vẻ phi đạo đức và không được thiết thực Tuy nhiên, nó có một số lợi thế Một chi phí dự án được thỏa thuận trên cơ sở đề nghị một phác thảo Các cuộc đàm phán sau đó diễn ra giữa khách hàng và khách hàng để thiết lập các đặc điểm kỹ thuật dự án chi tiết
Đặc điểm kỹ thuật này bị hạn chế bởi các chi phí đã thỏa thuận Người mua và người bán phải đồng ý về chức năng hệ thống chấp nhận được là gì Các yếu tố cố định trong nhiều dự án không phải là dự án yêu cầu nhưng chi phí Việc các yêu cầu có thể được thay đổi để các chi phí không được vượt quá
Ví dụ, nói rằng một công ty đang đấu thầu một hợp đồng phát triển một hệ thống nhiên liệu mới cho một công ty dầu rằng lịch trình giao hàng nhiên liệu đến các trạm dịch vụ của nó Không có tài liệu yêu cầu chi tiết cho hệ thống này nên các nhà phát triển ước tính rằng giá 900,000$ là có khả năng để cạnh tranh và trong ngân sách của công ty dầu Sau khi được cấp hợp đồng, họ thương lượng các yêu cầu chi tiết của hệ thống, do đó chức năng cơ bản được giao sau đó họ ước tính các chi phí bổ sung cho các yêu cầu khác Các công ty dầu không nhất thiết phải mất ở đây vì nó đã nhận được hợp đồng với một công ty mà nó có thể tin tưởng
Trang 12622 Chapter 26 ■ Software cost estimation
Các yêu cầu bổ sung thì các quốc có thể được tài trợ từ ngân sách trong tương lai, do đó
ngân sách của công ty dầu không bị gián đoạn bởi một phần mềm chi phí ban đầu rất cao
kích thước của các thành phần hệ thống và sử dụng một phần tài liệu tham khảo được biết
đến để ước tính kích thước thành phần, hoặc nó có thể chỉ đơn giản là một câu hỏi của đánh
giá kỹ thuật
Chính xác ước lượng kích thước mã là khó khăn ở giai đoạn đầu trong một dự án bởi vì
kích thước đang bị ảnh hưởng bởi quyết định thiết kế mà vẫn chưa được thực hiện Ví dụ,
một ứng dụng có yêu cầu quản lý dữ liệu phức tạp, hoặc có thể sử dụng một cơ sở dữ liệu
thương mại hoặc thực hiện hệ thống quản lý dữ liệu riêng của mình Nếu một cơ sở dữ liệu
thương mại được sử dụng, kích thước mã sẽ nhỏ hơn nhưng công sứcbổ sung có thể cần
thiết để khắc phục những hạn chế hiệu suất của các sản phẩm thương mại
Các ngôn ngữ lập trình được sử dụng để phát triển hệ thống cũng ảnh hưởng đến số
lượng các dòng mã sẽ được phát triển Một ngôn ngữ như Java có thể có nghĩa rằng nhiều
dòng mã là cần thiết hơn nếu C (nói) đã được sử dụng.Tuy nhiên, mã này thêm cho phép
nhiều thời gian biên dịch kiểm tra để xác nhận chi phí có thể sẽ được giảm Làm thế này
nên được đưa vào trương mục? Hơn nữa, nó có thể là có thể sử dụng lại một số lượng đáng
kể của mã từ các dự án trước đó và dự toán kích thước đã được điều chỉnh để đưa vào
trương mục
Nếu bạn sử dụng một mô hình dự toán chi phí thuật toán, bạn nên phát triển một loạt các dự
(tồi tệ nhất, mong đợi và tốt nhất) chứ không phải là một ước tính duy nhất và áp dụng các
công thức chi phí cho tất cả chúng Ước tính có nhiều khả năng được chính xác khi bạn hiểu
các loại phần mềm đang được phát triển, khi bạn đã điều chỉnh các mô hình chi phí bằng
cách sử dụng dữ liệu địa phương, và khi ngôn ngữ lập trình và lựa chọn phần cứng đang
được xác định trước mô hình chi phí thuật toán dùng công thức toán để dự đoán chi phí dự
án dựa trên ước tính của kích cỡ dự án, số của kỹ sư phần mềm, và các quy trình và yếu tố
sản phẩm Một mô hình chi phí thuật toán có thể được xây dựng bằng cách phân tích các chi
phí và các thuộc tính của dự án hoàn thành và tìm kiếm công thức phù hợp nhất với kinh
nghiệm thực tế
Mô hình chi phí thuật toán được sử dụng chủ yếu để lập dự toán của phần mềm chi phí phát
triển, nhưng Boehm (Boehm, et al., 2000) thảo luận về một loạt các sử dụng khác cho các
ước tính chi phí thuật toán, bao gồm cả dự toán cho các nhà đầu tư trong các công ty phần
mềm, các ước tính về chiến lược thay thế để giúp đánh giá rủi ro và dự toán để thông báo
những quyết định về tái sử dụng, tái phát triển hoặc gia công phần mềm
• •
Trang 1326.3 ■ Algorithmic cost modelling 623
26.3 Algorithmic cost modelling
Trong hình dạng chung nhất, một dự toán thuật toán cho chi phí phần mềm có thể được thể hiện như
Effort = A × SizeB × M
A là một yếu tố không đổi mà phụ thuộc vào thực tiễn tổ chức địa phương và các loại phần mềm được phát triển Kích thước có thể là một đánh giá của các mã kích thước của phần mềm hoặc một ước tính chức năng thể hiện trong chức năng hoặc đối tượng điểm Giá trị của số mũ B thường nằm giữa 1 và 1,5 M là một số nhân xuất theo quy trình Bining, sản phẩm và phát triển các thuộc tính toán, chẳng hạn như các yêu cầu về độ tin cậy cho các phần mềm và kinh nghiệm của đội ngũ phát triển
Hầu hết các mô hình ước lượng thuật toán có một thành phần mũ (B trong phương trình trên) được liên kết với các ước tính kích thước Điều này phản ánh một thực tế là chi phí thường không tăng tuyến tính với quy mô dự án Khi kích thước của các phần mềm tăng, chi phí phụ phát sinh do các nguyên tắc cần giao tiếp của các đội lớn hơn, quản lý cấu hình phức tạp hơn, tích hợp hệ thống khó khăn hơn và vì vậy Cho nên, hệ thống lớn hơn, giá trị lớn hơn của số mũ này.Thật không may, tất cả các mô hình thuật toán bị từ những khó khăn cơ bản giống nhau:
1 Nó thường là khó để ước tính kích thước ở giai đoạn đầu trong một dự án khi
chỉ có một đặc điểm kỹ thuật có sẵn Ước tính chức năng điểm và đối tượng
điểm là dễ sản xuất hơn so với ước tính của mã kích thước nhưng thường vẫn không chính xác
2 Dự toán của các yếu tố góp phần B và M là chủ quan Ước tính, thay đổi từ người này sang người khác, tùy thuộc vào nền tảng của họ và thí nghiệm khoa với các loại hệ thống đang được phát triển
Số lượng các dòng mã nguồn trong hệ thống phân phối là các số liệu cơ bản được sử dụng trong nhiều mô hình chi phí thuật toán Ước lượng kích cỡ có thể liên quan đến việc ước lượng bằng cách tương tự với các dự án khác, dự toán bằng cách chuyển đổi chức năng hoặc đối tượng điểm mã kích thước, ước lượng bằng cách xếp hạng các kích thước của các thành phần hệ thống và sử dụng một phần tài liệu tham khảo được biết đến để ước tính kích thước thành phần, hoặc nó
có thể chỉ đơn giản là một câu hỏi của đánh giá kỹ thuật
• •
Trang 14hệ thống quản lý dữ liệu riêng của mình Nếu một cơ sở dữ liệu thương mại được sử dụng, kích thước mã sẽ nhỏ hơn nhưng công sứcbổ sung có thể cần thiết để khắc phục những hạn chế hiệu suất của các sản phẩm thương mại
Các ngôn ngữ lập trình được sử dụng để phát triển hệ thống cũng ảnh hưởng đến số lượng các dòng mã sẽ được phát triển Một ngôn ngữ như Java có thể có nghĩa rằng nhiều dòng mã là cần thiết hơn nếu C (nói) đã được sử dụng Tuy nhiên, mã này thêm cho phép nhiều thời gian biên dị ch kiểm tra để xác nhận chi phí có thể sẽ được giảm Làm thế này nên được đưa vào trương mục? Hơn nữa, nó có thể là có thể sử dụng lại một số lượng đáng kể của mã từ các dự án trước đó và dự toán kích thước đã được điều chỉ nh để đưa vào trương mục
Nếu bạn sử dụng một mô hình dự toán chi phí thuật toán, bạn nên phát triển một loạt các dự (tồi tệ nhất, mong đợi và tốt nhất) chứ không phải là một ước tính duy nhất và áp dụng các công thức chi phí cho tất cả chúng Ước tính có nhiều khả năng được chính xác khi bạn hiểu các loại phần mềm đang được phát triển, khi bạn đã điều chỉnh các mô hình chi phí bằng cách sử dụng dữ liệu địa phương,
và khi ngôn ngữ lập trình và lựa chọn phần cứng đang được xác định trước
Tính chính xác của các ước lượng được sản xuất bởi một mô hình thuật toán phụ thuộc vào các thông tin hệ thống sẵn có Là số tiền thu được quá trình phần mềm, có thêm thông tin để ước tính ngày càng trở nên chính xác hơn Nếu ước tính ban đầu của công sứccần thiết là x tháng nỗ lực, phạm vi này có thể là từ 0.25
~ 4x khi hệ thống được đề xuất đầu tiên Điều này thu hẹp trong quá trình phát triển, như thể hiện trong hình 26.5 Con số này được chuyển thể từ giấy Boehm của (Boehm, et al., 1995), phản ánh kinh nghiệm của một số lượng lớn các dự án phát triển phần mềm Tất nhiên, ngay trước khi hệ thống được giao, một ước tính rất chính xác có thể được thực hiện
26.3.1 Mô hình COCOMO
Một số mô hình thuật toán đã được đề xuất như là cơ sở cho việc ước lượng nỗ lực, thời gian và chi phí của một dự án phần mềm Đây là những khái niệm tương tự nhưng sử dụng các giá trị tham số khác nhau Các mô hình mà tôi thảo luận ở đây là
mô hình COCOMO Mô hình COCOMO là một mô hình thực nghiệm, được bắt nguồ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 được phân tích để khám phá công thức mà là phù hợp nhất để quan sát
Những công thức liên kết các kích thước của các hệ thống và sản phẩm, dự án và các yếu tố nhóm để các công sứcđể phát triển hệ thống
Tôi đã chọn để sử dụng các mô hình COCOMO vì nhiều lý do:
Trang 1526.3 ■ Algorithmic cost modelling 625
2 Nó đã được sử dụng rộng rãi và đánh giá trong một loạt các tổ chức
3 Nó có một phả hệ dài từ instantiation đầu tiên của mình vào năm 1981 (Boehm, 1981), thông qua một sàng lọc phù hợp để phát triển phần mềm Ada (Boehm và Royce, 1989), đến phiên bản của nó gần đây nhất, COCOMO 11, xuất bản năm 2000 (Boehm, et al.,
2000)
Các mô hình COCOMO là toàn diện, với một số lượng lớn các thông số mỗi người mà có thể mất một khoảng giá trị Họ rất phức tạp mà tôi không thể đưa ra một mô tả triệt để ở đây Thay vào đó, tôi chỉ cần thảo luận về đặc điểm thiết yếu của họ để cung cấp cho bạn một sự hiểu biết cơ bản của mô hình chi phí thuật toán
Phiên bản đầu tiên của mô hình COCOMO (COCOMO 81) là một mô hình ba mức các mức tương ứng với các chi tiết của việc phân tích dự toán chi phí Cấp độ đầu tiên (cơ bản) cung cấp một ước tính sơ ban đầu; cấp độ thứ hai này được sửa đổi bằng cách sử dụng một số dự án và quá trình nhân; và dự toán duced trình độ chi tiết nhất cho các giai đoạn khác nhau của dự án Hình 26.6 cho thấy công thức COCOMO cơ bản với nhiều loại khác nhau của các dự án Các nhân M phản ánh UCT, dự án và nhóm đặc điểm phẩm
COCOMO 8 1 giả định rằng phần mềm sẽ được phát triển theo một quy trình thác nước (xem Chương 4) sử dụng ngôn ngữ lập trình bắt buộc tiêu chuẩn như C hay FORTRAN Tuy nhiên, đã có những thay đổi căn bản để phát triển phần mềm
kể từ phiên bản đầu tiên này đã được đề xuất Nguyên mẫu và phát triển gia tăng thường được sử dụng mô hình quy trình Phần mềm hiện nay thường được phát triển bởi
