Ƣớc lƣợng dự toán

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Sử dụng tri thức trong việc phát triển các dự án công nghệ thông tin Luận văn ThS Công nghệ thông tin 1.01.10 (Trang 94 - 101)

CHƢƠNG 3 ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM

4.4 Ƣớc lƣợng dự toán

Khi ước lượng dự toán thông thường người ta áp dụng một số công thức đơn giản như lấy tổng số khối lượng công việc (effort) theo giờ nhân với 8 hoặc 9 USD tùy theo mức giá thỏa thuận với khách hàng- hiện tại ở Việt nam mức giá khoảng 8 USD là mức giá trung bình với phần lớn khách hàng. Sau đây là ví dụ :

Hình 4.3.4: Kế hoạch làm việc áp dụng nhân tố chắc chắn.

96

Đây là cách tính thông dụng và đơn giản nhất hiện nay. Trong trường hợp chúng ta phải trả thêm một số chi phí cho dự án hoặc dự án nhiều khả năng phát sinh mà chúng ta không lường hết được ví dụ như thời gian bảo trì, bảo hành sản phẩm kéo dài, thời gian phát triển kéo dài, chúng ta phải trả thêm nhiều chi phí về đào tạo và quản lý, dịch thuật.. thì chúng ta có một số phát biểu sau :

Nếu dự án diễn ra bình thường dự toán sẽ là 9672 USD CF (luật 1)=0.8+0.6 (1-0.8)=0.92= CF (cost draft)

Hình 4.4.1: Tính dự toán áp dụng lý thuyết chắc chắn.

97

Nếu như chi phí phần cứng và phần mềm là khoảng 5000 USD với CF (luật2)=0.8 ; hầu như chắc chắn.

Thì như đã nói ở trên chúng ta cần thêm vào những chi phí không lường trước được để dự phòng trường hợp dự án kéo dài nên chúng ta phải cộng thêm vào nó khoảng 10% so với tổng giá trị ban đầu để đảm bảo dự án chắc chắn có đủ vốn để thực hiện.

Quay lại với luật 1 và luật 2 giả sử có luật 3

 Nếu luật 1 và luật 2 đúng thì luật 3 đúng CF (luật 3)=0.6

 Nếu luật 3 đúng và luật 1 và luật 2 đúng thì luật 4 CF=0.8 Như vậy CFKết hợp=max{CF1,CF2,CF3}*CF4=0.73

Việc áp dụng dự toán phụ thuộc vào rất nhiều yếu tố vì có dự án có công ty chấp nhận chịu lỗ vì nhiều mục đích khác nhau, vì muốn có thêm tên khách hàng mới trong danh sách khách hàng, vì muôn làm dự án A để làm bước đệm làm dự án B, vì muốn đánh bóng thương hiệu, vì nhiều mục đích khác. Vì thế trong thực tế giữa giá ước lượng và giá đưa ra cho khách hàng nhiều khi khác xa so với thực tế vì thế dự toán đưa cho khách hàng sẽ nằm trong khoảng nào đó. Dựa vào ví dụ trên ta thấy dự toán nằm trong khoảng [cost draft-additional,cost draft+additional]

Bỏ qua những trường hợp đặc biệt, chúng ta phải đưa ra dự toán chuẩn để từ đó ra quyết định. Giả sử dự toán chuẩn là 15640 USD như ở phần trên, chúng ta sẽ phải cân đối dự toán với những yêu cầu của dự án. Có những trường hợp dự án bắt buộc phải thành công cho dù doanh thu thu về không đủ để bù đắp chi phí hoặc chúng ta chấp nhận đưa ra giá cả thấp hơn so với bình thường để đạt được mục đích. Trong một số trường hợp thực tế, có rất nhiều cách mà có vẻ như là chi phí thực tế cao hơn dự toán nhưng vấn có lãi. Chẳng hạn khi công ty A nhận được dự án P với ước lượng là 4 người làm trong 1 tháng (4 person-month) với dự toán bằng C1, nhưng thực tế họ lại cho cả 10 người vào dự án làm, nếu tính toán dựa trên số lượng đơn thuần thì rõ ràng công ty A lỗ gấp 2.5 lần so với bình thường. Nhưng thực tế họ lại lãi rất nhiều, lý do là trong 10 người chỉ có 4 người có kinh nghiệm còn 6 người chưa có kinh nghiệm với công nghệ trên. Thông thường công ty A thường tốn một khoản chi phí C2 dùng để đào tạo nhân viên trước khi tham gia dự án, nay nếu tham gia vào dự án thì họ sẽ tiết kiệm được 6*C2 chi phí đào tạo và như vậy trên thực tế có thể giảm giá thành C=C1- 6*C2 để tăng cạnh tranh. Tất nhiên trong thực tế còn tùy thuộc vào xu hướng và

98

lợi ích mới có thể áp dụng được cách trên. Bởi vì công ty A đã nghiên cứu và thấy rằng xu hướng của thị trường gia công phần mềm đối với các dự án nhúng đang tăng lên rất nhanh và xu hướng dành cho các dự án ứng dụng thông thường và web đang giảm xuống nên họ mới ra quyết định như vậy.

Chuyển những số liệu này thành biểu đồ hoặc bảng để thống kê là việc vô cùng dễ dàng. Nó sẽ giúp cho việc lưu trữ các dữ liệu lịch sư được thuận tiện và dễ dàng hơn. Việc áp dụng các luật sẽ giúp chúng ta dễ dàng hơn trong việc đưa ra kết luận và đó cũng là mục đích quan trọng nhất của hệ chuyên gia.

4.5 Kết luận

Chương này đã đề cập đến phần quan trọng nhất trong đề tài đó là việc sử dụng tri thức trong việc ước lượng DAPM sau đây là những nội dung mà chương này đề cập đến:

 Ước lượng cỡ dự án

 Ước lượng khối lượng công việc

 Ước lượng lịch biểu

 Ước lượng dự toán

99

KẾT LUẬN

Quản lý dự án phần mềm là một trong những lĩnh vực quan trọng trong việc phát triển phần mềm. Việc ước lượng DAPM ảnh hưởng tới nhiều kết quả sản xuất kinh doanh của công ty. Hiện nay trong xu thế hội nhập ngày càng có nhiều các công việc gia công phần mềm đến từ các công ty nước ngoài. Việc ước lượng giá trị phần mềm một cách khoa học và chính xác sẽ giúp chúng ta dự đoán trước được tình hình sản xuất, kinh doanh cũng như giúp chúng ta không bị trễ hạn dự án khi ước lượng quá ngắn và không bị cho là hoang tưởng khi ước lượng quá dài.

Luận văn đã trình bày một số khía cạnh liên quan đến vấn đề quản lý và vận hành dự án, tổ chức dự án, quản lý, ước lượng dự án phần mềm. Đặc biệt là luận văn cũng trình bày đầy đủ các phương pháp ước lượng dự án phần mềm, từ những phương pháp như COCOMO đến các phương pháp dễ đoán hơn là điểm chức năng, đến các phương pháp mới hơn như là điểm trường hợp sử dụng. Ngoài ra là các phần lý thuyết liên quan đến Lý thuyết chắc chắn trong hệ chuyên gia, các luật chắc chắn, các định nghĩa về nhân tố chắc chắn.

Việc áp dụng tri thức (lý thuyết chắc chắn) đã mang lại sự tin tưởng nhiều hơn về khả năng thành công cho dự án, giúp cho người quản trị dự án có thể ước lượng trước về khả năng thành công ở mức độ như thế nào của dự án, cũng như dự đoán trước những khả năng không thành công. Và quan trọng nhất là đưa ra một cách gần chính xác, những con số để có thể cân, đo, đong, đếm được- những con số đó có thể dùng làm dữ liệu lịch sử để ước lượng cho dự án mới. Có lý thuyết chắc chắn khi làm ước lượng chúng ta có thể xác định khả năng thành công cụ thể là bao nhiêu một cách chính xác hơn sẽ là 0.90 hay là 0.6 hay là 0.96,.. Việc nâng cao khả năng chắc chắn cho dự án bằng cách thêm vào những khoảng đệm để nâng cao khả năng thành công cho dự án là một điểm đặc biệt cho phép người quản trị dự án hình dung được mức độ thành công của dự án khi thêm 5% thời gian sẽ là bao nhiêu, khi thêm 10% và 15% sẽ là bao nhiêu.

Việc áp dụng kỹ thuật ước lượng thể hiện bằng công cụ EXCEL là một bước tiến lớn so với việc áp dụng mẫu chuẩn của RUP viết bằng phần mềm soạn thảo WORD. Việc thể hiện ước lượng trên EXCEL giúp cho người tham gia ước lượng chỉnh sửa và không quá mất công đi tìm kiếm những dữ liệu quá khứ hoặc quá quan tâm đến tổng thể dự án. Từ những dữ liệu này có thể sử dụng để quản

100

lý và theo dõi tiến độ của dự án dựa trên những công việc. Từ đó dễ dàng xây dựng những biểu đồ hoặc so sánh giữa thực tế và kế hoạch theo thời hạn.

101

TÀI LIỆU THAM KHẢO

 Tiếng Việt

[1]. Ban Điều Hành Đề Án 112 Chính phủ(2003), Quản lý và tổ chức thực hiện các dự án công nghệ thông tin.

[2]. Đỗ Trung Tuấn (1999), Hệ Chuyên Gia, NXB Giáo Dục

[3]. Jody Zall Kusek và Ray C. Rist (2005), Mười bước tiến tới Hệ Thống Giám Sát và Đánh giá dựa trên Kết quả, NXB Văn Hóa-Thông Tin

 Tiếng Anh

[4] A function point FAQ:

http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm [5] Alan Green (2006), How to estimate a software project,

http://www.bright-green.com/docs/howto_estimate.html [6] COCOMOII web site:

http://sunset.usc.edu/COCOMOII/cocomo.html

[7] DeMarco (1982), Tom, Controlling Software Projects, Prentice-Hall [8] Goether, Wolfhart B., Elizabeth K. Bailey, Mary B. Busby, CMU/SEI-92- TR-021 (2006), Software Effort and Schedule Measurement: A framework for counting Staff-hours and reporting Schedule Information,

http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.021.html

[9]. IBM Rational (2004), Rational Unified Process.

[10] International Function Point Users Group (IFPUG) web site:

http://www.ifpug.org

[11] Jones, Capers (2006), What are Function Points,

http://www.spr.com/library/0funcmet.htm

[12]. Kathleen Peters (1999), Software Project Estimation. [13]. Peter J Merrick (2006), Use Case Points Method,

http://www.uea.ac.uk/~a168955/effort_estimation/use_case_points.html

102

[14]. R. Park, CMU/SEI-92-TR-20 (2006), Software Size Measurement: A framework for counting source statements.

http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html

[15]. Schneider, G. and J. Winters (1998), Applying Use Cases - A Practical

Guide, Addison Wesley Longman, Inc.

[16] Vigder, M.R. & A.W. Kark (2006), Software Cost Estimation and Control,

http://wwwsel.iit.nrc.ca/abstracts/NRC37116.abs (full text available).

[17] William R. Ducan (2004), A guide to the Project management body of

knowledge (PMBOK Guide) Thrid Edition, Project Management Institute Standard

Committee.

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Sử dụng tri thức trong việc phát triển các dự án công nghệ thông tin Luận văn ThS Công nghệ thông tin 1.01.10 (Trang 94 - 101)

Tải bản đầy đủ (PDF)

(101 trang)