CHƯƠNG 3. ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
3.4 Biến đổi quy trình ƣớc lƣợng dự án phần mềm
3.4.2 Quy trình ước lượng dự án phần mềm thực tế
Trong các phần trước chúng ta có thể thấy rõ ràng để ước lượng dự án phần mềm chúng ta phải làm những gì (what) nhưng không nói rõ ràng ra rằng để làm được cái gì đấy thì chúng ta phải thực hiện như thế nào (how ?). Điều đó cũng giống như CMMI thì đưa ra các yêu cầu các công ty phải làm những gì và kiểm tra những gì để đạt được tiêu chuẩn CMMI chứ không đưa ra cách thức cụ thể làm như thế nào để đạt được những tiêu chuẩn như thế giống như Rational Unified Process (RUP). Sau đây là quy trình ước lượng dự án phần mềm ở công ty chúng tôi dựa trên quy trình phát triển phần mềm của công ty như sau :
Tìm hiểu yêu cầu
Chia các luồng công việc thành
các công việc
Chia dự án ra thành các luồng
công việc
Ước lượng từng công việc
Ước lượng các luồng công việc
Đưa ra effort Đưa ra schedule Đưa ra Cost
Quy trình trên gồm những bước như sau :
Tìm hiểu yêu cầu dự án
Đối với một công ty chuyên làm về gia công phần mềm (outsourcing) như công ty của chúng tôi, các yêu cầu dự án thường đến từ phía khách hàng. Nó có
Hình 3.4.1: Quy trình ước lượng phần mềm sau khi biến đổi
thể bao gồm các yêu cầu đơn giản ở mức thô hoặc có thể bao gồm cả các bản phân tích và thiết kế. Trong một số trường hợp khi chúng tôi chỉ được gia công một phần nhỏ trong một hệ thống lớn thì yêu cầu của dự án bao gồm cả việc phát triển dựa trên một kiến trúc và mã lệnh đã có sẵn sao cho chúng khi được ghép lại có thể chạy tốt cùng với các dự án khác.
Khi đã nắm được yêu cầu dự án chúng ta chuẩn bị bước sang bước tiếp theo, chia các công việc ra thành các luồng công việc.
Sau đây là ví dụ :
Chia dự án ra theo các luồng công việc
Lý do quy trình ước lượng dự án ở công ty tôi có áp dụng các luồng công việc vì quy trình phát triển phần mềm trong thực tế của chúng tôi cũng sử dụng các luồng công việc. Quy trình phát triển phần mềm được biến đổi từ Rational
Hình 3.4.2: Ví dụ về ước lượng tìm hiểu yêu cầu dự án
Unified Process. Ở đây luồng công việc được định nghĩa theo Rational Unified Process như sau :
1. Mô hình kinh doanh-Business Modeling.
2. Quản lý Yêu cầu (Requirements Management).
3. Phân tích và Thiết Kế (Analysis and Design).
4. Cài đặt (Implementation).
5. Kiểm thử (Test).
6. Triển khai (Deployment).
7. Quản lý cấu hình (Configuration and Change Management).
8. Quản lý dự án (Project Management) 9. Môi trường phát triển (Environment)
Trong số chín luồng công việc thì các luồng công việc từ bẩy đến chín được coi là những luồng công việc hỗ trợ cho sáu luồng công việc đầu tiên.
Trong trường hợp dự án đã có sẵn thiết kế và kiến trúc và công việc của chúng tôi chỉ đơn giản là thiết kế, cài đặt, nên tùy từng tình huống cụ thể mà số lượng và thành phần các luồng công việc sẽ khác nhau. Sau đây là ví dụ về việc chia các công việc ra thành các luồng công việc :
Hình 3.43: Phân chia dự án thành các luồng công việc
Ở ví dụ trên chúng ta thấy rõ ràng là chúng ta chỉ sử dụng bốn luồng công việc là Quản lý yêu cầu, Thiết kế, Cài đặt, và Kiểm thử. Các luồng công việc khác quá ít và gần như là không có trong dự án này.
Chia các luồng công việc ra thành các nhiệm vụ cụ thể.
Sau khi chia dự án ra thành các luồng công việc. Việc tiếp theo của chúng ta là tiếp tục chia nhỏ những luồng công việc này thành các công việc nhỏ hơn và nhiệm vụ nhỏ hơn. Ở đây chúng ta cố gắng áp dụng việc phân tách các chức năng lớn thành các chức năng nhỏ hơn và gộp lại các chức năng quá nhỏ thành một chức năng vừa đủ lớn để dễ dàng kiểm soát và không quá sa đà vào việc ước lượng quá sâu và chi tiết.
Sau đây là ví dụ của việc phân chia công việc thành các các công việc nhỏ hơn và nhiệm vụ nhỏ hơn :
7.
Hình 3.4.4: Phân chia các luồng công việc thành các nhiệm vụ
Ước lượng từng nhiệm vụ và các luồng công việc
Chúng ta phải tính toán chi tiết những công việc diễn ra trong dự án tốn bao nhiêu man-hour (hoặc person-house) hay là bao nhiêu man-month (hoặc person-month) ? Tính như thế nào ? Trong thực tế khách hàng thường gửi yêu cầu đến dưới dạng điểm chức năng (Function Point) và vì thế việc ước lượng dựa trên FP là rất tiện lợi. Để việc ước lượng được chính xác chúng ta cần phân loại các chức năng thuộc loại nào ? Độ phức tạp của chúng là cao hay thấp, hay trung bình ? Với từng loại dự án khác nhau thì công sức bỏ ra để hoàn thành chức năng thuộc loại thấp, cao, hay trung bình. Bảng sau đây cho biết trong trường hợp thực hiện viết mã lệnh cho một ứng dụng web với công nghệ đơn giản là Java với các chức năng có độ phức tạp khác nhau :
STT Độ phức tạp Số giờ phải thực hiện
1 Cao (High) ≥7 ngày và ≤2.5 tuần
2 Trung bình (Medium) ≥4 ngày và ≤6 ngày
3 Thấp (low) ≥3.3 ngày và ≤4 ngày
Một vấn đề được đặt ra là một trang web thế nào thì được cho là có độ phức tạp là thấp hoặc cao hoặc trung bình. Điều này phụ thuộc rất nhiều vào tiêu chí đánh giá do tổ chức xây dựng hoặc do người trưởng dự án đưa ra. Có thể đưa ra tiêu chí đánh giá như sau đối với dự án trên :
STT Độ phức tạp Mô tả
1 Cao (High) Có từ 10 màn hình phải viết mã trở lên, các luồng dữ liệu và luồng logic phức tạp, sử dụng nhiều các thành phần khác nhau trong dự án. Có yêu cầu phức tạp về mặt logic hoặc nghiệp vụ. Đòi hỏi những người phát triển có kỹ năng đặc biệt. Hoặc là những vấn đề mà đội dự án chưa có kinh nghiệm xử lý.
2 Trung bình
(Medium)
Có từ 4 màn hình phải viết mã lệnh đến ít hơn 10 màn hình phải viết mã. Độ phức tạp về yêu cầu ở mức độ trung bình. Các thuật toán xử
lý và nghiệp vụ đòi hỏi ở mức độ trung bình không có quá nhiều đòi hỏi đặc biệt
3 Thấp (low) Có ít hơn 4 màn hình phải viết mã lệnh.
Chỉ bao gồm các chức năng đơn giản không yêu cầu phức tạp về mặt thực hiện hoặc là giao diện phức tạp nhưng sử dụng lại được từ các chức năng trước đó, hoặc từ dự án khác.
Giả sử trong trường hợp chúng ta chỉ có đúng hai ngày để đưa ra ước lượng dự án và báo giá cho dự án thì cách thức thực hiện như trên rất hữu ích vì chúng ta có thể nhanh chóng đưa ra kết luận về số lượng man-month cũng như man-hour. Sau đây là ví dụ về một bản ước lượng khối lượng công việc:
Hình 3.4.5: Ước lượng Effort dự án
Trong bảng báo giá trên các phần A, B, C, D tương ứng với bốn chức năng chính phải viết mã trong dự án. Tổng số effort dự tính là khoảng 6 person-month.
Bây giờ chúng ta sẽ xem xét vấn đề dữ liệu quá khứ. Dưới đây là một ví dụ về vấn đề dữ liệu quá khứ dùng để tham khảo trong quá trình ước lượng phần mềm :
Những dữ liệu này để cho tiện dụng sẽ lưu trữ trong một tệp EXCEL riêng biệt đi kèm với các tệp ước lượng chi tiết khác theo dạng tham chiếu.
Dưới đây là một ví dụ ước lượng sử dụng dữ liệu quá khứ ở tệp EXCEL trên :
Hình 3.4.6: Dữ liệu quá khứ
Sau đây là ví dụ cụ thể một chức năng :
Hình 3.3.7: Ví dụ ước lượng Effort dự án
Đưa ra khối lượng công việc, kế hoạch công việc, và dự toán.
Hình 3.3.8: Ví dụ ước lượng Effort một chức năng
Trong một số trường hợp từ các thông số ước lượng được từ khối lượng công việc, chúng ta có thể chuyển nó qua kế hoạch công việc (schedule). Ở đây chúng ta phải lưu ý tới vấn đề : có một số chức năng quan trọng mà bắt buộc phải có nó thì các chức năng khác mới chạy, hay còn được gọi là chức năng chính hoặc lõi của dự án, nó cần được ưu tiên xếp lịch hoàn thành trước các chức năng khác, để cho những người phát triển các chức năng liên quan có thể dễ dàng ghép vào chức năng của họ. Việc sẵp xếp thời hạn phụ thuộc nhiều việc dự án dự kiến sẽ bắt đầu và kết thúc như thế nào ? Trong trường hợp dự án bắt buộc phải kết thúc theo thời gian của khách hàng thì cần tăng thêm người và thời hạn đối với số lượng các thành viên tham gia dự án khác nhau thì sẽ phải khác nhau. Vì thế, chúng ta cũng cần chuẩn bị sẵn những nguồn nhân lực tham gia vào dự án.
Trong phần này có một lưu ý là có một số chức năng thuộc loại rủi ro, mà khi thực hiện nó chúng ta không chắc chắn được là sẽ kết thúc nó vào thời điểm nào trong dự án, hoặc là chúng ta chưa có đủ kiến thức để làm chủ công nghệ. Do đó việc chúng ta có đáp ứng được không vì thế thời hạn đưa ra nhất thiết phải được cộng thêm một số ngày nào đó.
Sau đây là ví dụ :
Hình 3.3.9: Ví dụ ước lượng khối lượng công việc của dự án.
Những công việc thuộc loại Others bao gồm việc đào tạo nhân viên dự án, chuẩn bị môi trường làm việc, nghiên cứu công nghệ, tools, họp hành. Ngoài ra để đảm bảo dự án không bị chậm tiến độ trong phần ước lượng khối lượng công việc chỳng ta thờm một cụng việc gọi là ô Additional ằ, nú được tớnh theo phần trăm của tổng ước lượng cơ bản, trong ví dụ này nó là 20%.
Về vấn đề ước lượng dự toán, đây là mục quan trọng nhất vì nó sẽ quyết định dự án có đem lại hiệu quả kinh doanh hay không? Việc thực hiện dự án có cần thêm chi phí dịch thuật hay chi phí nào khác như nghiên cứu, đào tạo,. Việc đưa ra dự toán còn tùy thuộc vào vấn đề chúng ta cần lãi suất cao, cần đánh bóng thương hiêu, cần làm để tạo quan hệ hay cần thực hiện dự án để tạo tiền đề cho những dự án sau. Đây là vấn đề rất khó khăn vì thông thường với các dự án mà trong đó đội dự án chỉ làm công việc viết mã thì dự toán thường thấp hơn nhiều so với các dự án làm thêm việc thiết kế hoặc tham gia làm yêu cầu và phân tích.
Sau đây là ví dụ tính dự toán thông thường dựa trên khối lượng công việc :
Ở đây chúng ta tính dự toán mỗi một giờ làm việc của người phát triển tốn 8 USD. Và trong ví dụ của chúng ta dự toán không được thêm chi phí nghiên cứu phát triển, chi phí đào tạo và các chi phí khác đã được thêm vào trong effort nên không cần thiết thêm vào nữa. Trong trường hợp dự án cần mua thêm một số sản phẩm phần cứng, phần mềm thì ta sẽ có kết quả ước lượng như sau :
Ở ví dụ trên chúng ta đã giả sử rằng giá mua phần cứng và phần mềm hết khoảng 5000USD và những chi phí khác liên quan đến dự án để đảm bảo dự án hoạt động tốt hết khoảng 10% so với tổng chi phí về khối lượng công việc, chi phí này có thể đến do quá trình triển khai dự án kéo dài, việc phát triển gặp khó khăn cần kéo dài, chi phí cho việc đi công tác triển khai sản phẩm. Ở đây chúng ta sử dụng ô Unit 1 ằ để tớnh giỏ.
Cuối cùng là lên kế hoạch làm việc, đây là phần khá quan trọng nó sẽ cho biết khi nào thì chúng ta kết thúc một mốc công việc, khi nào bàn giao sản phẩm cho khách hàng, ai sẽ thực hiện công việc gì, cụ thể công việc đó thực hiện từ ngày nào tới ngày nào, các thành viên tham gia vào dự án như thế nào. Chính vì
Hình 3.3.11: Tính dự toán dự án dựa trên khối lượng công việc.
kế hoạch làm việc là khá quan trọng nên nó rất cần chi tiết, nhưng khi thực hiện ở phần ước lượng công việc chúng ta không nhất thiết phải đưa ra chi tiết một kế hoạch công việc mà chỉ đưa ra các công việc chính cùng với nó là các mốc bàn giao sản phẩm, khi nào thực hiện kiểm thử tích hợp, khi nào kiểm thử nghiệm thu.
Và vì thực hiện ở giai đoạn ước lượng nên thông tin về nó có thể không đầy đủ, trong quá trình phát triển dự án, người quản lý dự án sẽ cập nhật thêm thông tin vào bản kế hoạch làm việc. Sau đây là ví dụ về kế hoạch làm việc giống như sơ đồ Gantt :
Hình 3.3.12: Kế hoạch thực hiện công việc.