Cách tính KLOC

Mục đích.

• Hiểu được tầm quan trọng của việc quản lý chi phí dựán

• Hiểu được một sốkhái niệm và thuật ngữvềquản lý chi phí.

• Hiểu được các Qui trình Quản lý chi phí

• Mô tảcách dùng phần mềm trong quản lý chi phí dựán

4.1. Tầm quan trọng của việc quản lý Chi phí.

• Những dựán vềCNTT có hồsơtheo dõi kém hiệu quảcho việc đạt được

mục đích vềgiá cả.

• Chi phí trung bình vượt quá dựtoán ban đầu theo nghiên cứu từnăm 1995

của CHAOS là 189%; đã được cải thiện 145% trong nghiên cứu năm 2001

• ỞMỹcác dựán CNTT bịhuỷlàm tốn trên 81 tỉ đô la năm 1995

Nội dung tài liệu Quản trị dự án - Chương 4: Quản lý chi phí dự án, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên

GIAN COCOMO TRUNG GIAN là mở rộng của Mô hình COCOMO cơ bản, và được dùng để ước tính thời gian lập trình trong triển khai sản phẩm phần mềm. Sự mở rộng này, xem xét trên một tập hợp “Chi phí của các đặc trưng các Bộ phận điều khiển [driver]” được chia thành 4 nhóm [15 tính chất]: ƒ Đặc trưng của sản phẩm: o Yêu cầu về tính độ tin cậy của phần mềm o Khối lượng CSDL [database] của ứng dụng o Tính phức tạp của sản phẩm. o Đặc trưng của phần cứng o Ràng buộc về tính năng Run-time o Ràng buộc về Bộ nhớ o Tính không ổn định của môi trường máy ảo. o Yêu cầu về thời gian chuyển hướng [turnabout time] ƒ Đặc trưng về Chuyên gia. o Khả năng phân tích o Khả năng về kỹ sư PM [Software engineer] o Kinh nghiệm ứng dụng o Kinh nghiệm về máy ảo o Kinh nghiệm về ngôn ngữ lập trình • Đặc trưng về Dự án o Sử dụng các công cụ Phần mềm o Ứng dụng các Phương pháp của CNPM [software engineering] o Yêu cầu về triển khai lịch biểu [development schedule] Mỗi tính chất được đánh giá [cho điểm] theo thang điểm có 6 mức từ rất chậm [very low] đến quá cao [extra high] . Dựa trên thang điểm, Hệ số cố gắng [effort multiplier] sẽ được xác định theo bảng sau: Tích các Hệ số cố gắng =EAF [Effort Adjustment Factor, thường có giá trị từ 0.9 - 1.4.] Chương 4. QL Chi phí Trương Mỹ Dung www.fit.hcmuns.edu.vn/~tmdung Mail= 44 XẾP HẠNG [Ratings] Rất chậm [Very Low] Chậm [Low] Không đáng kể [Nominal] Cao [High] Rất cao [Very High] Quá cao [Extra High] Đặc trưng của sản phẩm Yêu cầu về độ tin cậy của Phần mềm 0.75 0.88 1.00 1.15 1.40 Khối lượng CSDL của Ứng dụng 0.94 1.00 1.08 1.16 Tính phức tạp của sản phẩm 0.70 0.85 1.00 1.15 1.30 1.65 Đặc trưng của Phần cứng Ràng buộc về tính năng Run-time 1.00 1.11 1.30 1.66 Ràng buộc về bộ nhớ 1.00 1.06 1.21 1.56 Tính không ổn định của môi trường máy ảo. 0.87 1.00 1.15 1.30 Yêu cầu về thời gian chuyển hướng [turnabout time] 0.87 1.00 1.07 1.15 Đặc trưng về Chuyên gia Khả năng Phân tích 1.46 1.19 1.00 0.86 0.71 Khả năng về Kỹ sư Phần mềm 1.29 1.13 1.00 0.91 0.82 Kinh nghiệm Ứng dụng 1.42 1.17 1.00 0.86 0.70 Kinh nghiệm về máy ảo 1.21 1.10 1.00 0.90 Kinh nghiệm về Ngôn ngữ lập trình 1.14 1.07 1.00 0.95 Đặc trưng về Dự án Sử dụng các công cụ Phần mềm 1.24 1.10 1.00 0.91 0.82 Ứng dụng các Phương pháp của CNPM [software engineering methods] 1.24 1.10 1.00 0.91 0.83 Yêu cầu về triển khai lịch biểu [development schedule] 1.23 1.08 1.00 1.04 1.10 Phương trình Cocomo trung gian có dạng: E=ai[KLOC][bi].EAF Trong đó: • E = Ước tính của NGƯỜI/THÁNG, • KLOC = Số dòng lệnh [đơn vị=1000] ước tính của sản phẩm dự án phần mềm. • EAF được cho bởi bảng trên. Chương 4. QL Chi phí Trương Mỹ Dung www.fit.hcmuns.edu.vn/~tmdung Mail= 45 • Hệ số ai và bi được cho bởi bảng sau đây. Dự án PM [Software project] ai bi Tổ chức [Organic] 3.2 1.05 Nửa gắn kết [Semi- detached] 3.0 1.12 Nhúng [Embedded] 2.8 1.20 Thời gian triển khai D được tính từ E tương tự như COCOMO Cơ bản. Phần mềm COCOMO II. COCOMO II là mô hình cho phép ước tính chi phí, sự cố gắng và lích biểu khi lập kế họach cho một dự án phần mềm mới. Gồm có 3 module: Applications Composition, Early Design, and Mô hình Post-architecture. Mô hình COCOMO gốc do Dr. Barry Boehm khởi xướng năm 1981, và COCOMO II được hình thành sau nhiều năm cố gắng của nhóm nghiên cứu [1990] USC- CSE, IRUS at UC Irvine, and the COCOMO II Project Affiliate Organizations, lần đầu tiên cài đặt giữa năm 1997. USC COCOMO II.1998.0 beta ra đời 10/1998. Phiên bản 98 sữ dụng 161 điểm DL [data] và sử dụng cách tiếp cận Công thức Bayes [Bayesian statistical approach [119kb]] có thêm ý kiến chuyên gia trong mô hình. USC COCOMO II.1999.0 ra đời giữa năm 1999 và USC COCOMO II.2000.0 ra đời cùng với Quyển sách COCOMO xuất bản vào tháng 7/ 2000. Phiên bản mới này cải tiến giao diện thân thiện với người dùng hơn, mô hình tính tóan tương tự như các phiên bản trước. Phiên bản USC COCOMO II.2001.0 cho phương pháp tính tóan mới. Các phiên bản phần mềm USC-COCOMO II được phát triển do nhóm Sinh viên lập trình, dưới sự chì đạo của Dr. Ellis Horowitz. Công cụ có thể cài đặt trên môi trường Unix, Microsoft Windows, và Java. [liên hệ cocomo-tool- ]. COCOMO và điểm Chức năng [Function Points]. COCOMO II Không hỗ trợ điểm chức năng. Phần mềm COCOMO II [Mô hình Post-architecture]: [ Chương trình Thử nghiệm] • Chạy [Run] Java USC COCOMO II.1997.2 • Chạy [Run] Expert COCOMO II with Risk Assessment* Chương 4. QL Chi phí Trương Mỹ Dung www.fit.hcmuns.edu.vn/~tmdung Mail= 46 Phần mềm USC COCOMO II.1999.0 [Mô hình Post-architecture & Early Design]: • SunOS 4.x and 5.x [2.13mb] • Windows 95/98/Windows NT platforms [3.26mb] Tư liệu - 1999 COCOMO II Model Manual Updated 10/02/1998 • Postscript [1.60mb] • PDF [252kb] USC COCOMO II User's Manual Updated 2/05/1999 • Postscript [4.17mb] • PDF [844kb] Phần mềm USC COCOMO II.1998.0 [Mô hình Post-architecture]: Phiên bản beta • SunOS 4.x and 5.x [1.95mb] • Windows 95/Windows NT [3.84mb] Tư liệu 1998 : COCOMO II Model Manual Updated 10/02/1998 • Postscript format [1.60mb] • PDF format [515kb] USC COCOMO II User's Manual Updated 10/02/1998 • Postscript format [6.27mb] • PDF format [5.70mb] Phần mềm thương mại COCOMO II, do COSTAR, Softstar Systems Amherst, NH, Cost Xpert, Cost Xpert Group, San Diego, CA, và ESTIMATE Professional, Software Productivity centre V.ancouver, BC, Canada.COCOMO 81 được triển khai bởi Dr. Ray Madachy và Dr. Brad Clark. Phần mềm USC COCOMO 81[Mô hình Intermediate]: • SunOS 4.x with Motif [1.47mb] • Windows 3.1/95/NT [392kb] Tư liệu: Chương 4. QL Chi phí Trương Mỹ Dung www.fit.hcmuns.edu.vn/~tmdung Mail= 47 USC COCOMO 81 Reference Manual • Postscript format [717kb] • PDF format [400kb] Phần mềm Alternate COCOMO 81 [Mô hình Intermediate]: • Expert COCOMO 81 with Risk Assessment • Macintosh [Apple Computer, Inc.] platform [265kb] Phần mềm COCOMO 81 Web-based [Mô hình Intermediate]: • Chạy [Run] COCOMO 81 Calculator PHẦN MỀM The COCOMO Suite tập hợp 6 mô hình COCOMO liên quan đến các mô hình trong các giai đọan triểnkhai, theo hình sau. • COCOTS [COnstructive COTS] [Chris Abts, Ye Yang] MỤC TIÊU: Triển khai một mô hình ước tính chi phí dùng để ước tính hiện mộ số chi phí quan trọng trong Triển khai và bảo trì Phần mềm COTS-cơ bản. • COQUALMO. Dùng để nhận dạng mối quan hệ giữa Chi phí, Chất lượng và lịch biểu. • CORADMO= tính /dự báo lịch biểu [tháng, M], người [P], và điều chỉnh sự nổ lực [người-tháng, PM] dự trên phân bố sự cố gắng và lịch biểu trong nhiều giai đọan khác nhau, và ảnh hưởng của sự lựa chọn lịch biều tỷ suất bộ phận điều khiển trên M, P, và PM trong mỗi giai đọan. • COPROMO [Constructive Productivity Improvement Model ] Tập trung trên dự báo về chi phí định vị hữu hiệu các nguồn tài nguyên đầu tư trong công nghệ mới và cai tiến sản xuất. • COSYSMO.Mục tiêu của mô hình COSYSMO [Constructive Systems Engineering Cost Model] ước tính Hệ thống các công việc công nghệ [SE] trong dự án phần mềm chuyên sâu. • Đọc thêm: o Barry Boehm. Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. ISBN 0-13-822122-7 o Barry Boehm, et al. Software cost estimation with Cocomo II [with CD-ROM]. Englewood Cliffs, NJ:Prentice-Hall, 2000. ISBN 0-13-026692-2 o Stan Malevanny. Case Study: Software Project Cost Estimates Using COCOMO II Model, 2005.

Các file đính kèm theo tài liệu này:

• ch4_qlchi_phi_tmdung_9261.pdf

Loading Preview

Sorry, preview is currently unavailable. You can download the paper by clicking the button above.

Hôm nay chúng ta sẽ cùng đàm đạo về một chủ đề khó nhằn đòi hỏi kinh nghiệm nhiều năm trong nghề đó là Estimate – 見積もり. Nó thực sự khó và phần việc này “không dành cho tay mơ” vì liên quan vấn đề tiền bạc. Tại sao BrSE phải biết cái này. Sẽ có nhiều bạn thắc mắc : việc Estimate là của người khác chứ sao BrSE lại làm ? vậy “người khác” đây là ai. Sẽ có 1 ngày bạn sẽ là cái “người khác” đó nên từ bây giờ hãy chuẩn bị những kiến thức cần biết, sau này sẽ dùng. Và một điều mình muốn tiết lộ : không phải Sale, không phải PM, Sếp càng không … mà chính là các bạn – những BrSE cứng là người hiểu hệ thống sâu nhất và chính là người estimate với sai số thấp nhất.

Về định nghĩa mình sẽ không nói ở đây, vì nếu bạn chưa biết estimate là gì thì không nên đọc bài này chi cho đau đầu. Những nội dung mình muốn truyền tải gồm 3 phần :

• Tầm quan trọng
• Những con số
• Phân loại dự án và cách ước tính

Tầm quan trọng của Estimate

Kể chuyện xưa… Cách đây 8 năm mình có join vào 1 dự án phải nói là đình đám nhất lúc đó, vì thời điểm 2010 mà lấy được Project hơn 1 triệu đô là quá kinh khủng [bây giờ thì bình thường]. Sau biết bao tháng ngày vật vã chiến đấu, có những tuần liền ăn ở tại công ty và chỉ chợp mắt vài tiếng mỗi ngày. Kết quả cuối cùng là … dự án fail. Quá đắng. Khi tĩnh tâm lại để mọi người cùng phân tích thì có nhiều nguyên do : chất lượng resource chưa cao với tuổi đời khá trẻ và non kinh nghiệm [BrSE 26, PTL 27 tuổi, TL toàn 25, PM 30 còn coder toàn 23-24], Plan không khớp với lượng công việc, chọn sai phương pháp triển khai phải rework nhiều … và 1 đống hầm bà lằng khác. Nhưng nguyên nhân sâu xa nhất và quyết định đến thành bại chính là bản Estimate quá hời hợt ngay từ đầu. Dự tính, ước lượng tất nhiên là có sai số nhưng sai tới 400% là có vần đề nghiêm trọng.

Nói dong dài vậy để các bạn có thể thấy được việc “sai một li đi một dặm” của Estimate. Không những công ty bị thiệt hại nặng, khách cũng đánh giá thấp khả năng ước lượng khối lượng công việc bên mình mà còn vấn đề to tát hơn là đập bể nồi cơm của anh em ở nhà. Vậy nên trước khi trưng ra phải coi cho thật kỹ tất cả khía cạnh, đánh giá mọi rủi ro có thể. Có đôi lúc mặc dù khó cũng phải gửi lời từ chối nếu bị khách ép quá đáng.

Những con số trong Estimate

• 20 – số ngày trong 1 tháng [đã trừ thứ 7 chủ nhật và lễ]
• 5 – số tiếng trong 1 ngày [= 8 tiếng * 62%]
• 10% – task management [Task quản lý của PM – TL]
• 10% – buffer risk [Sai số nếu xảy ra risk]

Nếu 1 anh dev code [+UT] được 20 line Java trong 1 tiếng liên tục thì 1 tháng sẽ code được : 20 * 5 * 20 = 2000 => KLOC = 2000. 1 ngày có 8 tiếng, trong đó sẽ bao gồm nhiều task khác như mail, họp, nghỉ ngơi … khi estimate chỉ nên tính 5, cao lắm thì 6, còn nếu tính 8 chắc chắn phải OT mới keep được deadline.

Còn gì nữa thì sẽ bổ sung sau, mới nhớ ra chừng này.

Phân loại dự án và cách ước tính

Có nhiều phương pháp estimate mà các bạn đã từng nghe như Delphi, COCOMO… nhưng trong các dự án phần mềm thì mình thấy dùng WBS [Work Breakdown Structure] vẫn là chuẩn nhất. Nó có điểm lợi là phân chia rạch ròi công việc ra từ đầu cho tới cuối dự án dựa theo scope mà khách yêu cầu, có thể base để lên Plan-Schedule cho team luôn. Ngoài ra còn 1 yếu tố nữa, nếu các bạn làm với Nhật thì sẽ biết được mức độ kỹ lưỡng của họ. Nếu mình break được công việc ra thành nhiều khối nhỏ họ sẽ dễ đánh giá và approve cho bản estimate mà mình đưa.

Maintenance

Đối với dòng dự án này chúng ta cần tỉnh táo phân tích rõ phạm vi maintain và mức độ ảnh hưởng của các module tới phần còn lại của hệ thống. Đối với những Framework và source được tổ chức tốt cộng với tính độc lập cao của function – method ta sẽ đỡ mất công hơn. Vậy nên trước khi estimate ta cần phải đọc và hiểu cấu trúc source, đặc biệt là phần common thì mới đưa ra được phương án tốt nhất. Về productivity maintain project có hệ số 1.2 đến 1.5 so với code mới. Ví dụ code java có productivity là 2.5 KLOC [2500 line code/1tháng] thì maintain thường rơi vào khoảng 3k đến 3.5k. Cách tính LOC thì không phải chỉ những dòng thêm mới mà cả những dòng chỉnh sửa – xoá cũng phải được liệt kê vào.

Các đầu mục cần list ra :

• Chuẩn bị môi trường – tài liệu
• Phân tích source
• Phần update : cần phân tích độ khó của yêu cầu để đưa ra productivity hợp lý và ước lượng số LOC cần update.
• Phần delete : cần xem xét mức độ ảnh hưởng tới các module khác để thêm bớt thời gian test lại hệ thống.
• Phần add new : nếu có phần tương tự đã có sẵn thì set produtivity cao hơn còn nếu không phải theo qui chuẩn [của công ty bạn qui định đối với năng suất dev trên các ngôn ngữ – FW]
• Test UAT : nếu khách yêu cần thêm cả CT hay IT cũng cần phải đưa vào Estimate.
• Tổng tất cả lại tính ra số MM bước đầu, sau đó cộng với buffer risk [10%] và task quản lý [10%] sẽ ra được con số cuối cùng.

Migration

Có rất nhiều loại : Migration Platform, Migration Language, Migration Version, Migarion database. Đối với dòng dự án này thông thường có tool hỗ trợ, nếu không phải tự tay code ra để dùng. Thời gian code tool cũng sẽ được tính vào trong estimate nhưng đổi lại phải nâng Productivity cho phần update code sau khi converted. Hoặc cũng có nhiều trường hợp estimate dựa trên hình thức làm thủ công nhưng khi triển khai thực tế mình tự code tool để nâng cao năng suất. Cái này không cần cho khách biết vì chuyện nội bộ, mình code tool mà tool không chạy được mình chịu nên nếu làm được tool ngon thì là của mình – không phải của khách.

• Về Platform cái này mình sẽ tiếp tục thu thập kinh nghiệm rồi bổ sung sau, hiện tại vẫn chưa đủ để viết nên các bạn thông cảm dùm.
• Language : ta thường gặp nhất là Lotus Node => Sharepoint, Cobol => Java, Orther => Java, Other => C#, VB => VB.Net …
  Cách làm tối ưu nhất vẫn là lấy mẫu thử [sampling] theo 3 cấp độ : Khó + trung bình + dễ, sau đó cho dev thử [hoặc tự xử nếu code tốt] rồi đưa ra con số. Bước tiếp theo là phân tích module đánh trọng số, sau đó kết hợp với con số productivity ở bước đầu ta sẽ có được con số cuối cùng.
• Verion : Hay gặp nhất là Java old => Java new version, .Net old => .Net new, C => GCC … cách làm cũng là lấy mẫu thử rồi tính toán.
• Database : DB2 => SQL, Oracle => SQL, Other => Oracle, Other => SQL, etx => etc … Cần xác định rõ môi trường 2 DB có kết nối được với nhau không, nếu có thì tool migration data có hỗ trợ tốt không. Ví dụ Oracle => SQL thì có tool SSMA [SQL Server Migration Assistant] của Microsoft hỗ trợ rất tốt nhưng điều kiện 2 server phải thông nhau. Trường hợp không thông thì cần phải get DB cũ lưu ra file từng table riêng => convert DDL => convert Data => Create Data/table/index/sequence… => Import => Test. Các thông số mình cần khách cung cấp : Số lượng table – view – procedure, record, độ phức tạp của dữ liệu …

Development

Đầu tiên là xác định scope : Design => UAT, thì khách cần mình làm công đoạn nào. Sau đó cũng WBS nó ra từng phần nhỏ, ứng mỗi phần lấy mẫu thử rồi tổng hợp lại. Thông số quan trọng nhất mà các bạn cần phải nắm đó là Productivity của ngôn ngữ. Từng công ty sẽ có các thông số khác nhau, ví dụ Java thông thường là 2k5 KLOC nhưng cũng có nơi 2k có nơi 2k7. Riêng dev Nhật thì tầm 3k5 [và lương họ cũng gấp đôi gấp ba lương dev Việt 😀 ].

Tỉ lệ % giữ các công đoạn – tương ứng độ khó : Design – code – test

Giải thích : giả sử tất cả các module đều có độ khó trung bình, sau khi phân tích module và chức năng hệ thống ta tính được con số 15MM dành cho design thì tương ứng sẽ là 10MM code và 5MM test. Trong đó basic design 35% ~ 5MM, detail design 45% ~ 7MM, program design [detail of detail design] 20% ~ 3MM.

Ở mỗi công ty đều có 1 bộ tài liệu với cách tính riêng có chênh lệch đôi chút dựa theo project history [lấy kết quả các dự án quá khứ để đưa ra con số trung bình]. Vậy nên các bạn chỉ cần nắm được lõi vấn đề, kết hợp với các thông tin trong các tài liệu tổng hợp đó thì chắc chắn sẽ làm được, không có gì quá khó cả. Dần dần kỹ năng, kinh nghiệm tăng lên và sai số sẽ giảm dần.

Với những gì mình viết trong bài này chưa đủ để các bạn cho ra một bản 見積 hoàn chỉnh nhưng hy vọng nó sẽ giúp ích phần nào. Ngoài ra khi làm cũng cần phải tham khảo các project tương tự trước đây, task list hay những con số rất có giá trị, đặc biệt là Productivity. Và cuối cùng, hãy cùng thảo luận cởi mở với khách nếu bạn là người trực tiếp thương thảo, còn nếu không hãy đưa ra các bằng chứng chứng minh cho các con số – các item để người chịu trách nhiệm hiểu cặn kẽ, tránh bị khách bắt bẻ. Còn đối với khách nào mà miệng lưỡi o ép kiểu “cái này dễ mà” – “có nhiêu đây làm gì mất nhiều thời gian vậy” – “tôi thấy mấy chỗ khác làm rẻ lắm” … thì để họ tự làm luôn đi. Giỡn chứ lựa lời mà nói cho họ hiểu. Hẹn gặp các bạn ở phần tiếp, mình sẽ nói sơ sơ về Proposal [提案書].

• Các mức level BrSE và mức lương tương ứng
• May 18, 2017
• In "Chuyện nghề"

• BrSE xưa và nay
• July 6, 2016
• In "Chuyện nghề"