Hỏi: Tôi xin hỏi vấn đề sau, tôi muốn định nghĩa 1 số đo cho các dự án. Nhưng như tôi thấy, các số đo như UCP, LOC, FP chỉ đo kích cỡ giai đoạn phát triển, hay nói cách khác là kích cỡ sản phẩm hơn là kích cỡ một dự án. Trong khi, ở cương vị 1 Quản trị dự án, tôi thấy có nhiều giai đoạn như giai đoạn lấy yêu cầu hay giai đoạn triển khai rất khó tính kích cỡ được, mà lúc Monitor dự án tôi rất muốn tính được khối lượng (kích cỡ) hoàn thành (dựa trên khối lượng dự án chứ khối lượng sản phẩm thì không đầy đủ). Liệu có cách đo nào tính được kích cỡ toàn dự án, nhằm đưa ra số đo khối lượng hoàn thành cho từng tuần không?

Đáp: Rất khó tính toán “kích cỡ toàn bộ” của dự án phần mềm vì có nhiều yếu tố tham gia vào như ngôn ngữ lập trình (như, C hay Java), yếu tố độ phức tạp (đơn giản hay phức tạp với chu trình và tính toán phức tạp), yếu tố miền (dựa trên Web, nhúng, hay ứng dụng doanh nghiệp v.v.), yếu tố qui trình hay vòng đời (thác đổ, xoáy ốc, làm bản mẫu, gia tăng v.v), các phương pháp (cấu trúc hay hướng đối tượng) và khách hàng (nội bộ và ngoại bộ) và mức độ truyền thông được yêu cầu. Về căn bản, ước lượng kích cỡ dự án tuỳ thuộc vào môi trường trong đó dự án được thực hiện.

Kĩ thuật kích cỡ mà bạn nhắc tới CHỈ dùng để ước lượng sản phẩm phần mềm, KHÔNG phải là kích cỡ toàn bộ dự án. Dòng mã (LOC) đo số các mã có thể được đếm trong phần mềm. Nó có ích chỉ cho nền công nghệ trên đó phần mềm được xây dựng nhưng LOC biến thiên cho các ngôn ngữ lập trình khác nhau. Điểm chức năng (FP) đo chức năng công việc. Kích cỡ được đo qua phương pháp FP là độc lập với ngôn ngữ lập trình hay công nghệ và có tác dụng tốt với ứng dụng nghiệp vụ nhưng không cho các ứng dụng khác như phần mềm nhúng hay phần mềm dựa trên web (nhiều hiển thị màn hình và dẫn hướng). Điểm đối tượng (OP) đo kích cỡ phần mềm bằng việc đếm số màn hình, báo cáo và giao diện nhưng có thể không có tác dụng tốt cho nghiệp vụ (nhiều tính chức năng) hay ứng dụng khoa học (nhiều xử lí)

Có những chức năng hỗ trợ trong mọi dự án phần mềm mà thường KHÔNG được tính tới trong các phương pháp này như các hoạt động quản lí dự án, hoạt động kĩ nghệ yêu cầu, hoạt động trao đổi, hoạt động đào tạo, hoạt động tổ, hoạt động gặp gỡ khách hàng, hoạt động báo cáo, hoạt động làm tài liệu, hoạt động đóng dự án, hoạt động kiểm điểm, hoạt động đảm bảo chất lượng, hoạt động cấu hình, hoạt động hỗ trợ hệ thống, và nhiều thứ nữa. Đó là lí do tại sao rất khó tính “kích cỡ toàn thể” của dự án phần mềm.

Có cách đơn giản mà nhiều người quản lí dự án thường làm. Họ tính toán kích cỡ của việc phát triển dự án (LOC, FP, OP v.v) rồi thêm 25% (cho các dự án nhỏ và đơn giản) tới 45% (cho dự án lớn và phức tạp) để đi tới “kích cỡ dự án toàn bộ”. Đây là “tổng phí” cho các chức năng hỗ trợ mà phải được đưa vào.

Để tính đúng kích cỡ dự án toàn bộ, bạn có thể thêm mọi yếu tố vào trong bản kế hoạch dự án, cũng như phần đệm cho trường hợp dự phòng nào đó. Sau đây là một cách đơn giản mà tôi thường dùng để lập ngân sách cho dự án. (Lưu ý: Đây không phải là phương pháp khoa học được dạy trong trường nhưng dựa trên kinh nghiệm. Một số người có thể đồng ý hay có thể không đồng ý. Tất nhiên, chúng ta không thảo luận cách tốt nhất hay cách đúng ở đây.)

Tôi thường bắt đầu phát triển “ngân sách dự án toàn bộ” bằng việc nhìn vào toàn thể dự án như một tổng thể. Không chỉ hoạt động phát triển phần mềm (các pha vòng đời phần mềm). Tôi ước lượng nỗ lực của điều phải được làm, cách nó được làm, và thời gian làm nó. Có hai chi phí chính: lao động và vật tư (phần cứng, phần mềm, trang thiết bị v.v.) nhưng với hầu hết dự án phần mềm, lao động là yếu tố chi phí then chốt.

Tôi chia toàn thể dự án thành nhiều hoạt động chi tiết để ước lượng nỗ lực và chi phí toàn bộ. Chẳng hạn: lập kế hoạch tiền dự án, hợp nhất yêu cầu, phân tích yêu cầu, kiểm điểm yêu cầu, làm tài liệu yêu cầu, lập kế hoạch dự án, hình thành tổ, đào tạo tổ, đào tạo dự án, kiểm điểm yêu cầu, phân công công việc tổ, kiến trúc hệ thống, kiểm điểm kiến trúc, thiết kế chi tiết, kiểm điểm thiết kế, thực hiện dự án (viết mã), giám định mã, kiểm điểm mã, chiến lược kiểm thử, lập kế hoạch kiểm thử, kiểm điểm kiểm thử, kiểm thử dự án, kiểm thử tích hợp, kiểm thử chấp nhận của khách hàng và hoạt động hỗ trợ dự án (đảm bảo chất lượng, quản lí cấu hình, hỗ trợ mạng, hỗ trợ phần cứng, hỗ trợ tài liệu v.v.).

Với từng hoạt động, tôi xác định bao nhiêu người sẽ được tham gia và nó sẽ mất bao nhiêu thời gian. Tất nhiên, nó chỉ là ước lượng đại thể vì khó tính được con số chính xác nỗ lực. Sau khi đi tới một ước lượng, tôi thêm quãng 20% tới 30% phần đệm cho từng hoạt động dành cho dự phòng (để giảm rủi ro).

Chẳng hạn: Lập kế hoạch tiền dự án yêu cầu hai cuộc họp để hiểu mong đợi của quản lí và nhu cầu của khách hàng. Nó thường bao gồm ba người: người quản lí dự án, người kiến trúc sư hệ thống và người quản trị hành chính dự án để làm tài liệu các chi tiết. Điều này yêu cầu hai cuộc họp; một cuộc với người quản lí cấp cao và một cuộc với khách hàng, mỗi cuộc có thể mất một giờ. Với ba người và hai giờ, tôi có thể tính ra chi phí bằng việc nhân tiền trả theo giờ với ba (để đơn giản giả sử cả ba đều có cùng giá $10 đô la một giờ. Chi phí tổng cho hoạt động này là: $10X3X2 = $60. Tôi thêm vùng đệm 30% cho nó cho nên chi phí toàn bộ cho hoạt động này là $60 + $18 = $78.

Cùng điều đó có thể được áp dụng cho các hoạt động khác cho nên bằng tính toán ra được tổng chi phí lao động cho từng hoạt động; tôi đi tới tổng chí phí lao động cho toàn thể dự án. Một số dự án có thể yêu cầu chi phí vật tư như phần cứng, phần mềm, trang thiết bị hay công cụ. Chằng hạn, từng người phát triển cần dùng công cụ phần mềm. Tôi phân công từng người một giấy phép cho công cụ và nhân chi phí giấy phép lên theo số người phát triển. Nếu một giấy phép là $10 trên người dùng, tôi có 100 người phát triển, nhân $10X 100 được chi phí $1000. Bằng việc bổ sung thêm phần đệm 30% tổng là $1300. Cùng điều này có thể dược dùng cho chi phí trang thiết bị. Bằng việc biết bao nhiêu trang thiết bị được cần và chi phí cho từng thứ, tôi có thể tính tổng chi phí.

Bằng việc tổ chức các nỗ lực này trong một lịch theo tuần, tôi có thể giám sát điều tôi đã lập kế hoạch và điều thực sự xảy ra (được lập theo kế hoạch so với thực tại) cũng như dõi vết tiền tôi đã tiêu (được lập theo kế hoạch so với thực tại). Tôi bao giờ cũng lưu chúng chúng trên trang tính như Excel rồi đến cuối dự án, tôi có “dữ liệu lịch sử” về ước lượng của tôi tốt thế nào. Tôi càng có nhiều “dữ liệu lịch sử”, tôi càng có thể điều chỉnh các ước lượng của tôi cho các dự án tương lai. Đây là cách tôi học về ước lượng, đo và giám sát dự án phần mềm. Không cái gì tốt hơn là thực hành thức tế để thu được kinh nghiệm.

Tôi chắc chắn những người khác có cách riêng của họ để tính “kích cỡ toàn bộ” của dự án phần mềm dựa trên kinh nghiệm riêng của họ.

—-English version—-

Asking on Measurement

Question: Tôi xin hỏi vấn đề sau, tôi muốn định nghĩa 1 số đo cho các dự án. Nhưng như tôi thấy, các số đo như UCP, LOC, FP chỉ đo kích cỡ giai đoạn phát triển, hay nói cách khác là kích cỡ sản phẩm hơn là kích cỡ một dự án. Trong khi, ở cương vị 1 Quản trị dự án, tôi thấy có nhiều giai đoạn như giai đoạn lấy yêu cầu hay giai đoạn triển khai rất khó tính kích cỡ được, mà lúc Monitor dự án tôi rất muốn tính được khối lượng (kích cỡ) hoàn thành (dựa trên khối lượng dự án chứ khối lượng sản phẩm thì không đầy đủ). Liệu có cách đo nào tính được kích cỡ toàn dự án, nhằm đưa ra số đo khối lượng hoàn thành cho từng tuần không?

Answer: It is very difficult to calculate the “total size” of a software project because there are many factors involved such as programming language (i.e., C or Java), complexity factor (Simple or complex with loops and sophisticated calculation), domain factor (Web-based, embedded, or business application etc.), process factor or life cycle (Waterfall, Spiral, Prototyping, Incremental etc.), methods (Structure or object oriented) and customer (Internal or external) and the degree of communication required. Basically, project size estimation is depending on the environment within which the project is being performed.

The size techniques that you mentioned are ONLY use to estimate the software product, NOT the total project size. Lines of code (LOC) measures number of code that can be counted in the software. It is useful only to the technology platform on which the software is built but LOC varies for different programming language. Function points (FP) measures the business functionality. The size measured through FP method is independent of the programming language or technology and work well with business application but not on other applications such as embedded software or web-based software (More screen displays and navigations). Object Points (OP) measures the software size by counting the number of screens, reports, and interfaces but may not work well for business (More functionality) or scientific applications (more processing)

There are supporting functions in every software project that often NOT being calculated in these methods such as project management activities, requirements engineering activities, communication activities, training activities, teamwork activities, customers meeting activities, reporting activities, documentation activities, project closure activities, review activities, quality assurance activities, configuration activities, system supporting activities, and many more. That is why it is very difficult to calculate the “Total size” of a software project.

There is a simple way that many project managers often do. They calculate the size of project development (LOC, FP, OP etc) then add 25% (For small and simple project) to 45% (For large and complex project) to come up with a “Total project size”. These are the “Overhead” for supporting functions that must be included.

To calculate a total project size correctly, you can add all factors into the project plan, as well as buffers for certain contingencies. Following is a simple way that I used to plan my project budget. (Note: This is not a scientific method taught in school but based on experience. Some people may agree or may not. Of course, we are not discussing the best way or the correct way here.)

I often start to develop a “total project budget” by looking at the entire project as a whole. Not just software development activities (Software life cycle phases). I estimate the efforts of what must be done, how it is done, and the time to do it. There are two major costs: labor and materials (hardware, software, equipments etc.) but for most software projects, labor is the key cost factor.

I break down the entire project into many detailed activities to estimate the total efforts and costs. For example: Pre-project planning, Requirements solicitation, Requirements analysis, Requirements reviews, Requirements documentation. Project planning, Team formation, Teamwork training, Project training, Requirements reviews, Teamwork assignments, System architecture, Architecture review, Detail design, Design review, Project implementation (Coding), Code inspections, Code reviews, Testing strategy, Test planning, Test review, Project testing, Integration testing, Customer acceptance testing and Project support activities (Quality assurance, Configuration management, network supports, hardware supports, documentation supports etc.).

For each activity, I determine how many people will be involved and how long will it takes. Of course, it is only a rough estimate since it is difficult to calculate the exact number of efforts. After come up with an estimate, I add about 20% to 30% buffers for each activity just for contingencies. (To reduce risks)

For example: Pre-project planning requires two meetings to understand the expectations of management and the need of customers. It often involves three people: The project manager, the System architect, and the Project administration to document details. It requires two meetings; one with senior manager and one with customer, each may take one hour. With three people and two hours, I can calculate the cost by multiply the hour rate by three (For simplicity assumes all three have the same rate of $10 dollars per hour. The total cost for this activity is: $10X3X2 = $60. I add 30% buffer to it so the total cost for this activity is $60 + $18 = $78.

The same thing can be applied to other activities so by calculate the total labor cost for each; I can come up with the total labor cost for the entire project. Some projects may require material costs such as hardware, software, equipments or tools. For example, each developer needs to use software tools. I assign each person a license for the tool and multiply the licensing cost by the number of developers. If a license is $10 per user, and I have 100 developers, multiply $10X 100 to get the $1000 cost. By adding 30% buffers the total is $1300. The same thing can be use for equipment costs. By knowing how many equipment needed and the cost of each, I can calculate the total costs.

By organize these efforts into a weekly schedule, I can monitor what I have planned and what really happen (Planned vs. actual) as well as tracking the money that I spent (Planned vs. Actual). I always save them on a spreadsheet such as Excel than by the end of the project, I have a “historical data” about how well is my estimates. The more “historical data” that I have, the more I can adjust my estimates for future projects. This is how I learned about estimate, measure and monitor software projects. Nothing is better than actual practice to gain experience.

I am sure other people have their own way of calculate “Total size” of software project based on their own experience.