Quản lý dự án phần mềm trong thực tiễn (Software Project Management in Practice)

Quản lý dự án phần mềm thực tiễn (Software Project Management in Practice) Các quy trình dùng Infosys, công ty đạt CMM mức 5, để quản lý dự án phần mềm Tác giả: Pankaj Jalote Nhà xuất bản: Addison-Wesley Năm xuất bản: 2002 Biên dịch sang tiếng Việt: Nguyễn Công Danh Sửa dịch: Trần Cao Đệ Bộ môn: Công nghệ phần mềm Khoa CNTT&TT, ĐH Cần Thơ Năm biên dịch: 2013 (Dùng nội làm tài liệu tham khảo bổ sung cho sinh viên) Mục lục Chương 1: Quản lý dự án phần mềm Phần 1: Lập kế hoạch cho dự án Chương 2: Cơ sở hạ tầng để lập kế hoạch cho dự án 25 Chương 3: Lập kế hoạch cho quy trình 44 Chương 4: Ước lượng nỗ lực thời gian biểu 62 Chương 5: Lập kế hoạch cho chất lượng 98 Chương 6: Quản lý rủi ro 119 Chương 7: Đo lường kế hoạch theo dõi 143 Chương 8: Kế hoạch quản lý dự án 164 Chương 9: Quản lý cấu hình 200 Phần 2: Thực kết thúc dự án Chương 10: Xem xét lại 227 Chương 11 Giám sát kiểm soát dự án 257 Chương 12 Kết thúc dự án 305 Chương Quản lý dự án phần mềm Trên giới, khoảng nửa triệu người quản lý dự án thực khoảng triệu dự án phần mềm năm, sản xuất phần mềm trị giá 600 tỷ USD Nhiều dự án số có chất lượng không kỳ vọng khách hàng không cung cấp phần mềm phạm vi ngân sách thời gian hoàn thành Một phân tích cho thấy khoảng phần ba dự án có chi phí thời gian hoàn thành (cost and schedule) vượt 125% [1] Tại nhiều dự án phần mềm thất bại? Mặc dù có nhiều lý do, lý quan trọng quản lý dự án không phù hợp Ví dụ, lý làm cho dự án chệch khỏi tầm kiểm soát mục tiêu không rõ ràng, lập kế hoạch tồi, công nghệ mới, thiếu phương pháp quản lý dự án, không đủ nhân [2] Ít ba năm lý rõ ràng liên quan đến quản lý dự án Hai lý lại - không đủ nhân công nghệ - coi rủi ro mà để quản lý chúng phần quản lý dự án Rõ ràng, cách sử dụng kỹ thuật quản lý dự án có hiệu quả, người quản lý dự án cải thiện hội để thành công Tuy nhiên, hiệu kỹ thuật gì? Hãy xem xét tương tự Giả sử bạn muốn phát triển thể, với bắp săn Để đạt mục tiêu, bạn bắt đầu nhìn vào chương trình tập thể dục mô tả tạp chí Một viết mô tả làm để phát triển sức mạnh cánh tay, đưa danh sách gồm 10 tập – không nhiều so sánh với chuẩn Nhưng sau đó, viết khác hướng dẫn để phát triển sức mạnh đùi, cung cấp 10 tập, người huấn luyện cho bụng phẳng cảm thấy làm 10 tập không nhiều Nếu bạn muốn phát triển thể tổng thể bạn cách làm theo chương trình tập thể dục riêng lẻ, bạn thấy bạn có 50 đến 100 tập để làm - rõ ràng hầu hết người, để một người quản lý dự án bận rộn Để đạt mục tiêu bạn, bạn cần chương trình đào tạo toàn diện, thiết thực hiệu Tương tự vậy, bạn tìm thấy phong phú đề xuất để thực khía cạnh khác quản lý dự án, bao gồm ước lượng/dự toán nỗ lực (effort estimation), quản lý rủi ro, giám sát dự án, quản lý cấu hình, v.v Mặc dù kỹ thuật đề xuất để giải vấn đề riêng biệt, có chưa rõ ràng việc làm để kết hợp kỹ thuật lại với thành quy trình khả thi thực tế Để quản lý dự án hiệu quả, cần phải trải qua thời gian thực tế quản lý, thực “chương trình tập luyện” quản lý để tạo kết Nói cách khác, cần thiết quy trình cân bao gồm việc quản lý toàn dự án từ bắt đầu đến hoàn thành Thật không may, có số lượng phương pháp công bố dẫn làm để tích hợp kỹ thuật lại với theo cách Cuốn sách lấp đầy khoảng trống cách mô tả quy trình sử dụng công ty tầm cỡ giới để quản lý hiệu dự án phần mềm Công ty Infosys, công ty phát triển phần mềm có thành tích tuyệt vời việc thực dự án; tính riêng năm 2000, người quản lý dự án Infosys sử dụng quy trình mô tả để thực thành công khoảng 500 dự án cho khách hàng Cuốn sách thảo luận tất khía cạnh khác quản lý dự án Infosys - lập kế hoạch, thực hiện, kết thúc Bạn học làm người quản lý dự án Infosys ước lượng/dự toán, lập kế hoạch quản lý rủi ro, thu thập số đo (metrics), thiết lập mục tiêu chất lượng, sử dụng phép đo để giám sát dự án, v.v Một khía cạnh thú vị quy trình này, hấp dẫn cho người quản lý dự án bận rộn, chúng không phức tạp, không cồng kềnh, sử dụng số đo đơn giản Infosys đánh giá mức (mức cao nhất) Mô Hình Trưởng Thành Năng Lực (CMM - Capability Maturity Model) Bằng cách trích quy trình quản lý dự án từ tập hợp quy trình Infosys, sách minh họa làm dự án quản lý công ty trưởng thành mức cao Thông qua minh hoạ này, hy vọng giới thiệu lợi ích CMM cho người quản lý dự án - người không nghiên cứu thiếu thời gian, họ nhận thấy khó khăn dùng CMM vào thực hành quản lý dự án Chương giới thiệu hai chủ đề tạo nên bối cảnh cho sách: CMM Infosys Bởi trọng tâm sách quản lý dự án CMM, thảo luận sách tập trung vào khía cạnh quản lý dự án CMM Chương cung cấp nhìn tổng quan quy trình quản lý dự án trường hợp nghiên cứu (case study) chính; chi tiết vấn đề thảo luận phần lại sách Trước tiên, thảo luận ngắn gọn vai trò quy trình quản lý dự án 1.1 QUY TRÌNH VÀ QUẢN LÝ DỰ ÁN Một dự án phần mềm có hai nhóm hoạt động chính: phát triển quản lý dự án Nhóm dự án quan tâm đến vấn đề thiết kế, kiểm thử, cài đặt mã, v.v Nhóm quản lý dự án quan tâm đến hoạch định quản lý hoạt động để đạt mục tiêu dự án: chi phí, thời gian hoàn thành, chất lượng Đối với dự án nhỏ: nhóm hai người làm dùng kỹ thuật không hình thức Kế hoạch dự án e-mail xác định ngày giao hàng có lẽ vài cột mốc (milestones) bên khoảng thời gian Yêu cầu (requirements) truyền đạt thư ngắn chí lời nói, sản phẩm trung gian, chẳng hạn tài liệu thiết kế, mảnh giấy ghi vội vàng lưu tập giấy cá nhân Tuy nhiên, kỹ thuật không hình thức không dùng cho dự án lớn: nhiều người làm việc nhiều tháng, hầu hết dự án phần mềm thương mại Trong dự án thế, việc phát triển phải làm cẩn thận theo phương pháp thử nghiệm, kết công việc phải lập tài liệu rõ ràng để người khác xem xét lại (review) chúng Các công việc dự án phải hoạch định phân công cho thành viên sau theo dõi dự án bắt đầu Nói cách khác, để dự án lớn thành công phải gia tăng tính hình thức cứng nhắc quản lý thực Những kỹ thuật theo hình thức cần quy trình định nghĩa rõ ràng để thực công việc khác kết trở nên phụ thuộc nhiều vào khả quy trình Những kỹ thuật hình thức tiếp tục mở rộng phương pháp định lượng sử dụng quy trình thông qua việc sử dụng số đo phù hợp Quy trình gì? Về mặt kỹ thuật, quy trình cho công việc bao gồm chuỗi bước cần theo để thực công việc Tuy nhiên, công ty, quy trình khuyến cáo để sử dụng kỹ sư người quản lý dự án nhiều chuỗi bước; chúng đóng gói kỹ sư người quản lý dự án học từ dự án thực thành công Thông qua quy trình, lợi ích kinh nghiệm trao cho tất người, kể người gia nhập công ty Những quy trình giúp người quản lý kỹ sư đạt thành công tránh vấn đề dẫn đến thất bại Đối với dự án, quy trình xác định làm để thực hoạt động phát triển đặc tả yêu cầu, thiết kế, thử nghiệm, v.v Các quy trình quản lý dự án, mặt khác, xác định làm để thiết lập cột mốc (milestones), tổ chức nhân sự, quản lý rủi ro, giám sát tiến độ, v.v Cuốn sách tập trung vào quy trình quản lý dự án Tuy nhiên, bạn xem xét quy trình quản lý dự án, bạn phải đặt câu hỏi: liệu người quản lý dự án có muốn sử dụng chúng không? Tôi thường nghe người thiết kế quy trình than phiền người quản lý dự án không thực theo quy trình họ không thích thay đổi Kinh nghiệm với người quản lý dự án Infosys công ty khác họ thực muốn sử dụng quy trình chúng hợp lý giúp người quản lý dự án thực dự án họ tốt Tuy nhiên, nhiều người quản lý dự án cảm thấy phẫn nộ nghĩ quy trình dường không cần thiết đóng góp giá trị cho công việc họ Trong trường hợp này, cần phải có quy trình trọng lượng nhẹ (lightweight processes) – giúp người quản lý dự án lập kế hoạch kiểm soát dự án họ tốt cung cấp cho họ linh hoạt để xử lý tình khác Để trả lời cho câu hỏi “Tại người quản lý dự án cần theo quy trình?”, S.D Shibulal – người thành lập giám đốc Infosys cho rằng: - Quy trình mô tả kiến thức chung Sử dụng chúng làm tăng hội thành công bạn - Một quy trình có bước dư thừa, bạn luôn biết trước không cần thiết, bạn có nhiều rủi ro chọn cách nhanh chóng - Nếu quy trình, bạn dự đoán kết dự án bạn - Bạn công ty học cách hiệu mà quy trình được định nghĩa Học tập cải tiến có tính bắt buộc giới dựa tri thức ngày - Quy trình làm giảm mức độ lo lắng bạn Các liệt kê mục cần kiểm tra (checklist) chắn bao gồm 80% cần phải thực Do đó, nhiệm vụ bạn làm giảm rủi ro 20% lại 1.2 QUẢN LÝ DỰ ÁN VÀ CMM Khi chấp nhận sử dụng quy trình hiệu giúp thực dự án thành công, câu hỏi là: Những đặc trưng được mong muốn quy trình gì? CMM cho phần mềm khung làm việc (framework) để cố gắng trả lời câu hỏi CMM cho phần mềm khung làm việc phát triển Viện Công Nghệ Phần Mềm (SEI) Đại học Carnegie Mellon cách quan sát thực hành tốt phần mềm công ty khác Do đó, CMM phản ánh kinh nghiệm quy trình chung mong đợi nhiều công ty Nó xác định các đặc điểm mong muốn quy trình mà không mô tả quy trình cụ thể Vì thế, quy tình khác thực đầy đủ yêu cầu CMM Nó sử dụng để đánh giá quy trình phần mềm công ty xác định thiếu sót CMM khung làm việc phổ biến để cải tiến quy trình phần mềm (các khung làm việc khác thường sử dụng ISO 9001 [3][4][5]) Các sở CMM quy định Managing the Software Process [6] Watts Humphrey, khung làm việc mô tả đầy đủ The Capability Maturity Model: Guidelines for Improving the Software Process Viện Công Nghệ Phần Mềm [7] Một "phiên mới" CMM, gọi CMM-I, phát hành Nhưng trọng tâm sách mô hình kinh nghiệm CMM-I, thảo luận CMM cho phần mềm khía cạnh quản lý dự án, CMM bao gồm vấn đề công ty quản lý quy trình Tôi không thảo luận thủ tục đánh giá, mô tả ngắn gọn vấn đề đưa sách CMM in Practice [8], mô tả chi tiết đưa CMM Based Appraisal for Internal Process Improvement S Masters [9] 1.2.1 Tổng quan CMM Một mục tiêu CMM để phân biệt quy trình trưởng thành với quy trình chưa trưởng thành, không theo thể thức (ad hoc) Quy trình phần mềm chưa trưởng thành ngụ ý dự án thực mà nhiều hướng dẫn, kết dự án phụ thuộc phần lớn vào khả nhóm dự án lãnh đạo dự án Ngược lại, với quy trình trưởng thành, dự án thực cách theo quy trình định nghĩa Trong trường hợp này, kết dự án phụ thuộc vào người phụ thuộc nhiều vào quy trình Khi đó, quy trình trưởng thành, kết dự án dự đoán kiểm soát tốt Phạm vi kết dự đoán dự án thực cách sử dụng quy trình khả quy trình (process capability) Kết thực tế đạt dự án thực cách sử dụng quy trình hiệu suất quy trình (process performance) Rõ ràng, hiệu suất quy trình phụ thuộc vào khả quy trình Để cải thiện hiệu suất quy trình dự án, bạn phải tăng cường khả quy trình, quy trình tự phải trưởng thành Con đường dẫn đến mức trưởng thành cao bao gồm số trạng thái ổn định xác định rõ ràng gọi mức trưởng thành (maturity levels) CMM Mỗi mức trưởng thành quy định cụ thể số đặc điểm cho quy trình, mức trưởng thành cao có đặc điểm cao cấp tìm thấy quy trình phần mềm trưởng thành Do đó, khung làm việc CMM mô tả yếu tố quy trình phần mềm mức khác trưởng thành Bởi vậy, xác định đường mà quy trình phần mềm theo để chuyển đổi từ quy trình chưa trưởng thành đến quy trình trưởng thành cao Con đường bao gồm năm mức trưởng thành, thể Hình 1.1 [7] Ở mức 1, mức khởi tạo (initial level), dự án thực theo cách thức nhóm dự án người quản lý dự án thấy phù hợp Mức lặp lại (repeatable level) (mức 2) áp dụng thực hành quản lý dự án sử dụng, quy trình chưa áp dụng cho toàn công ty Ở mức định nghĩa (defined level) (mức 3), quy trình cho toàn công ty định nghĩa thường xuyên thực theo Ở mức quản lý (managed level) (mức 4), định lượng hiểu biết khả quy trình làm cho dự đoán theo định lượng kiểm soát hiệu suất quy trình thực dự án Ở mức tối ưu hóa (optimizing level) (mức 5), khả quy trình cải tiến cách có kiểm soát cải tiến dựa định lượng Hình 1.1.7 Các mức trưởng thành CMM Mỗi mức trưởng thành (trừ mức 1) đặc trưng lĩnh vực quy trình trọng điểm (KPAs – key process areas), xác định lĩnh vực mà công ty nên tập trung để nâng cao quy trình họ đến mức trưởng thành Hình 1.1 cho thấy KPAs cho mức khác Đối với công ty để đạt mức trưởng thành, phải đáp ứng tất KPAs mức trưởng thành KPAs tất mức trưởng thành thấp Duy trì quy trình mức cao trưởng thành nhiệm vụ đầy thách thức đòi hỏi phải cam kết từ công ty văn hóa làm việc thích hợp Trong 900 đánh giá tiến hành từ năm 1996 đến tháng năm 2000, kết đánh giá cung cấp cho SEI, 3% công ty mức 5, 5% mức [10] Phần lại mức thấp hơn, với 38% mức 18% mức 1.2.2 KPAs cho quản lý dự án Mỗi KPA quy định cụ thể mục tiêu mà quy trình công ty phải đáp ứng để thỏa mãn KPA Ngoài ra, KPA xác định nhóm hoạt động, gọi thực hành chủ chốt (key practices), để đáp ứng mục tiêu KPA Các mục tiêu cho KPA nắm bắt chất Chúng xác định mục tiêu mà CMM đặt cho quy trình liên quan đến KPA Để minh họa KPAs kết hợp với quản lý dự án nào, thảo luận ngắn gọn mục tiêu KPAs Những mục tiêu lấy từ CMM [7], với số thay đổi nhỏ cách diễn đạt số mục tiêu Bảng 1.1 liệt kê tất mục tiêu cho KPAs mức 2, cho thấy rõ ràng trọng tâm mức gần dành riêng cho quản lý dự án Theo mục tiêu này, bạn tạo tài liệu kế hoạch dự án, đánh giá hiệu dự án diễn so với kế hoạch hành động hiệu suất thực tế sai lệch đáng kể so với kế hoạch Các yêu cầu (requirements) lập tài liệu cách đắn, thay đổi yêu cầu quản lý Tất sản phẩm làm kiểm soát, thay đổi thành phần quản lý thông qua kế hoạch quản lý cấu hình Các xem xét lại (reviews) kiểm tra (audits) thực để đảm bảo quy trình, kế hoạch tiêu chuẩn tuân thủ Nếu số phần dự án hợp đồng phụ với nhà cung cấp khác việc gia công hợp đồng phụ theo dõi cách Bảng 1.2 trình bày chi tiết mục tiêu ba bảy KPAs mức Các KPAs khác tập trung vào vấn đề tổ chức quản lý quy trình Một dự án công ty mức sử dụng phiên điều chỉnh phù hợp quy trình chuẩn tái sử dụng thành phần (asset), liệu, kinh nghiệm từ dự án khứ cho việc lập kế hoạch Các nhóm khác đóng góp vào dự án hợp tác cách suôn sẻ thông qua giao diện chế xác định rõ ràng Xem xét lại (review) thực để xác định lỗi sản phẩm tạo ra, hỗ trợ đầy đủ để thực việc xem xét lại (review) theo dõi hoạt động cung cấp Báo cáo kết thúc dự án ACIC (Closure Report of the ACIC Project) THÔNG TIN CHUNG (GENERAL INFORMATION) Mã dự án (Project Code) Xxxxx Chu kỳ sống (Life Cycle) Phát triển, toàn chu kỳ sống (Development, Full life cycle) Lĩnh vực nghiệp vụ Tài Ứng dụng Web để quản lý tài khoản (Business Domain) (Finance Web-based application for managing accounts.) Người lãnh đạo dự án/lãnh đạo mô-đun Xxxxxx (Project leader/Module Leader) Người quản lý nghiệp vụ (Business Manager) Cố vấn chất lượng Xxxxx (Software Quality Adviser ) TÓM TẮT HIỆU SUẤT (PERFORMANCE SUMMARY) Tham số hiệu suất (Performance Thực tế Ước lượng Chênh lệch Lý chênh lệch (nếu lớn) Parameter) (Actual) (Estimated) (Deviation) (Reasons for Deviation (If Large)) Nỗ lực tổng cộng 597 501 19% Hai yêu cầu thay đổi lớn đến (Total Effort (person- (Two major change requests that days)) came.) Kích thước nhóm lúc 9 N/A 03 Apr 2000 03 Apr 2000 N/A 03 Nov 2000 30 Nov 2000 27 ngày Hai yêu cầu thay đổi lớn tiêu tốn (Days) 5% nỗ lực (Two major change cao điểm (Peak Team Size) Ngày bắt đầu (Start Date) Ngày kết thúc (End Date) requests consumed more than 5% of the effort.) 314 Chất lượng (số lỗi 0.002 Chất lượng cải tiến 0.0125 giao/FP) phòng ngừa lỗi sử dụng quy trình (Quality (number of tăng dần defects delivered per (Quality improved because of defect FP)) prevention and use of incremental process.) Năng suất 58 57 2% N/A 31.4% 33% 5% N/A 0.022 0.03 –26% Đã cải tiến phòng ngừa (Productivity) Chi phí chất lượng (Cost of quality) Tỷ lệ tiêm lỗi (Defect injection lỗi (Improved because of defect rate) prevention.) Hiệu loại bỏ lỗi 97.4 97 (Small) N/A (Defect removal efficiency) CHI TIẾT QUY TRÌNH (PROCESS DETAILS) Điều chỉnh quy trình  Quy trình RUP sử dụng (Rational Unified Process was employed.) (Process Tailoring) Phát triển phân tích làm cách lặp lại – vòng lặp phát triển  vòng lặp thiết kế phân tích (Development and analysis were done iteratively—3 iterations for development and for design and analysis.)  Việc theo dõi dấu vết nguồn gốc yêu cầu làm cách dùng công cụ Requisite Pro (Requirement traceability was done through Requisite Pro tool.) CÔNG CỤ ĐƯỢC SỬ DỤNG (TOOLS USED) Ghi công cụ sử  dụng (Notes on Tools Used) Công cụ bên ngoài: VSS, VJA, Requisite Pro, MSP (External Tools: VSS, VJA, Requisite Pro, MSP)  Công cụ bên trong: BugsBunny, WAR (Internal Tools: BugsBunny, WAR) 315 QUẢN LÝ RỦI RO (RISK MANAGEMENT) Các rủi ro xác định lúc bắt đầu dự án (Risks identified at the start of the project) Risk Thiếu hỗ trợ từ kiến trúc sư sở liệu người quản trị sở liệu khách hàng (Lack of support from database architect and database administrator of the customer) Risk Dùng sai RUP sử dụng lần (Improper use of RUP, as it is being used for the first time) Risk Mất nhân (Personnel attrition) Risk Các vấn đề việc làm việc với sở liệu khách hàng thông qua liên kết (Problems with working on customer's database over the link) Các rủi ro gặp phải suốt trình thực dự án (Risks encountered during the project) Risk Tác động việc chuyển đổi sang VAJ 3.0 (Impact of conversion to VAJ 3.0) Risk Thiếu hỗ trợ từ kiến trúc sư sở liệu người quản trị sở liệu khách hàng (Lack of support from database architect and database administrator of the customer) Risk Dùng sai RUP sử dụng lần (Improper use of RUP, as it is being used for the first time) Risk Mất nhân (Personnel attrition) Các ghi giảm thiểu rủi ro (Notes on Risk Mitigation) Risk1: Nói rõ ràng rủi ro giúp khách hàng đồng ý trì hoãn việc chuyển đổi với chi phí phù hợp cho tác động Risk2: Các chiến lược giảm thiểu lập kế hoạch chi tiết cẩn thận sử dụng người điều phối chỗ (on-site coordinator) cách có hiệu Risk3: Đào tạo đội ngũ RUP có hiệu Vì vậy, giữ liên lạc với khách hàng 316 Risk 4: Vẫn rủi ro, không xảy Tác động giảm thiểu nhiều người thông báo cho biết (informed) hoạt động quan trọng (critical activity) KÍCH THƯỚC (SIZE) Ước lượng (Estimated) Thực tế (Actual) 5 9 12 12 Số trường hợp sử dụng đơn giản (Number of simple use cases) Số trường hợp sử dụng trung bình (Number of medium use cases) Số trường hợp sử dụng phức tạp (Number of complex use cases) Ghi ước lượng (Notes on Estimation) Tiêu chí phân loại (Classification Criteria): Định nghĩa tiêu chuẩn đơn giản, trung bình, phức tạp sử dụng để phân loại trường hợp sử dụng Điều thực tốt Kích thước hệ thống tính theo FP Kích thước mã nguồn sau đo theo LOC Nó chuẩn hóa sang FP cách sử dụng bảng chuyển đổi công bố Đối với Java, bảng công bố cho thấy 21 LOC FP COBOL, 107 LOC FP Ngôn ngữ kết Kích thước tính theo LOC Kích thước tính theo FP (Output Language) (Size in LOC) (Size in FP) 33,865 1612 1241 12 Java COBOL 317 THỜI GIAN BIỂU (SCHEDULE) Thời gian thực tế dùng (ngày) Thời gian ước (Actual Elapsed lượng (ngày) % trượt Giai đoạn (Phase) Time) (Estimated Time) (Slippage) Yêu cầu 28.67 31 –6.5 0 0.0 38.8 42 –6.7 132 135 –1.6 10 –9.3 141 144 –2.1 40 40 15 0.0 30 10 200.0 Lý Do trượt (Reasons for Slippage) (Requirements) Thiết kế mức cao (High-level design) Thiết kế chi tiết (Detailed design) Cài đặt mã (Coding) Kiểm thử đơn vị (Unit testing) Toàn - Xây dựng (Total – Build) Kiểm thử tích hợp (Integration test) Kiểm thử hệ thống (System testing) Kiểm thử chấp nhận AT đầy đủ (AT - Acceptance mở rộng testing) yêu cầu khách hàng (AT completion was extended on customer's request.) 318 NỖ LỰC (EFFORT) Phân phối qua giai đoạn chu kỳ sống (Distribution over Life-Cycle Stages) Giai đoạn (Stage) Yêu cầu (Requirements) Công việc Xem xét lại Làm lại Tổng (Task) (Rework) (Total) (Review) 210.0 10.0 60.0 280.0 0.0 0.0 0.0 0.0 652.0 14.0 29.5 695.5 1188.0 39.5 76.5 1304.0 Kiểm thử đơn vị (Unit testing) 129.5 0.0 17.0 146.5 Kiểm thử tích hợp (Integration 567.5 6.0 160.5 734.0 90.0 0.0 0.0 90.0 336.5 0.0 0.0 336.5 3173.5 69.5 343.5 3586.5 Quản lý dự án (Project management) 733.1 0.0 0.0 733.1 Đào tạo (Training) 104.5 0.0 0.0 104.5 Quản lý cấu hình (CM) 317.0 0.0 0.0 317.0 Misc 488.5 0.0 0.0 488.5 1643.0 0.0 0.0 1643.0 4816.50 69.50 343.50 5229.50 25.76 0.37 1.84 27.97 Thiết kế mức cao (High-level design) Thiết kế chi tiết (Detailed design) Cài đặt mã (Coding) testing) Kiểm thử hệ thống (System testing) Kiểm thử chấp nhận (Acceptance testing) Tổng số - Các giai đoạn chu kỳ sống (Total - LC stages) Total – mgmt, training, and misc Tổng nỗ lực (người-giờ) (Total Effort (Person-hours))) Tổng nỗ lực (người-tháng) (Total Effort (Person-months))) 319 Chi phí chất lượng (Cost of Quality) Phân phối nỗ lực thực tế so với ước lượng (Effort Distribution and Actual Versus Estimated) Thực tế (Actual) Ước lượng (Estimated) Giai đoạn Nỗ lực Nỗ lực (người- (người- giờ) giờ) % Chênh (person- (person- lệch (Stage) hours) % hours) % Yêu cầu 280 5.35 475.0 10 Lý chênh lệch (Deviation) (Reasons for Deviation) –30 (Requirements) Ước tính cao nỗ lực (dữ liệu từ dự án trước không giúp ích cho ước tính giai đoạn này.) (Overestimated this effort (data from earlier project did not help because it did not have this phase.)) Thiết kế (mức 695.5 13.30 569.0 12 22 Thiết kế cần nhiều thời gian nhóm cao chi tiết) kinh nghiệm (Design (HLD and Rational Rose OOAD detailed)) (Design took more time because team was inexperienced with Rational Rose and OOAD.) 320 Cài đặt mã 1304.0 24.94 1235.3 26 146.5 2.80 142.5 3 734.0 14.04 331.0 120 (Coding) Kiểm thử đơn vị (Unit testing) Kiểm thử tích hợp Nhiều nỗ lực xài để (Integration sửa chữa lỗi xuất testing) suốt trình hòa giải với Synergy mã Window Resized (Much effort spent on fixing bugs introduced during reconciliation with Synergy and Window Resized code.) Kiểm thử hệ 90.0 1.72 95.0 –5 336.5 6.43 285.0 18 thống (System testing) Kiểm thử chấp Các kiểm thử chấp nhận nhận không hoàn thành vào (Acceptance tháng 11 testing) gia hạn đến 23 tháng 11 trì hoãn từ khách hàng (Acceptance testing was not completed on Nov and was extended until Nov 23 due to delays from the customer.) Tổng – giai 3586.5 68.58 3132.8 66 14.5 733.1 14.02 713.0 15 đoạn chu kỳ sống (Total—LC stages) Quản lý dự án 321 (Project management) Đào tạo 104.5 2.00 455.0 10 –77 317.0 6.06 142.0 123 (Training) Quản lý cấu hình (CM) Chênh lệch vấn đề hòa giải (Deviation due to reconciliation issues.) Misc 488.5 9.34 285.0 71 Nhiều đào tạo (More because of training.) Tổng cộng – 1643.0 31.42 1595.0 34 3.01 5229.5 100 4727.8 100 10.6 quản lý, đào tạo, misc.) (Total—mgmt, training, and misc.) Tổng (Total) LỖI (DEFECTS) Phân phối lỗi (Defect Distribution) % tổng số lỗi Số lỗi % tổng số Số lỗi thực phát (% ước lượng lỗi ước tế (Actual of Total (Estimated lượng (% of % chênh (Stage Number of Defects Number of Total Estimated lệch Defects) Found) Defects) Defects) (Deviation) 11 10 29 20 –62 58 50 29 20 100 Giai đoạn phát Detected) Xem xét lại yêu cầu thiết kế (Req and design review) Xem xét lại mã (Code review) 322 Kiểm thử đơn vị 15 13 57 40 –73 29 25 25 17 16 –40 116 100 145 100 –20 (Unit testing) Tích hợp kiểm thử (Integration and system testing) Kiểm thử chấp nhận (Acceptance testing) Tổng (Total) Lý cho chênh lệch (Reasons for Deviation) Phòng ngừa lỗi làm giảm tỷ lệ tiêm lỗi giai đoạn sau đó, kết làm giảm tỷ lệ tiêm lỗi tổng thể Trong dự án trước – dự án mà liệu dùng để làm ước lượng (dự toán) cho dự án – việc xem xét lại mã (code reviews) thực có phụ thuộc lớn vào kiểm thử đơn vị (UT- unit testing) Ngược lại, dự án này, việc xem xét lại mã thực cách nghiêm ngặt rộng hơn, nhiều lỗi tìm thấy trình xem xét lại, dẫn đến sụt giảm đáng kể số lỗi tìm thấy kiểm thử đơn vị Hiệu loại bỏ lỗi (Defect Removal Efficiencies) Giai đoạn phát lỗi Giai đoạn tiêm lỗi Hiệu loại bỏ lỗi (Defects Detection Stage) (Defects Injection Stage) (Defect Removal Efficiency) Xem xét lại yêu cầu Yêu cầu Xây dựng Thiết kế (Req.) (Build) (Design) 100% (Req review) Xem xét lại thiết kế 100% (Design review) 323 Xem xét lại mã 0 58 55% ( 58 / 58 + 15 + 29 + ) 0 15 32% (15 / 15 + 29 + 3) Kiểm thử tích hợp hệ 0 29 91% ( 29 / 29 + 3) 100% (Code review) Kiểm thử đơn vị (Unit testing) thống (Integration/system testing) Kiểm thử chấp nhận (Acceptance testing) Hiệu loại bỏ lỗi tổng thể (Overall Defect Removal Efficiency) = 113 / 116 = 97.4 % Trong hiệu loại bỏ lỗi giai đoạn/hoạt động SQA tính theo công thức sau: Defects Removed during a Phase DRE % = X 100 Defects Removed till date Và hiệu loại bỏ lỗi dự án là: Total No Of Defects before Release/Delivery DRE % = - X 100 Total No Of Defects for the Project Sự phân phối theo mức độ nghiêm trọng (Distribution by Severity) Mức độ nghiêm trọng % tổng số lỗi STT (Severity) Số lỗi (Number of Defects) (% of Total Defects) Nhẹ bên (Cosmetic) 26 22.4 Nhỏ (Minor) 51 44 Lớn (Major) 36 31 Nghiêm trọng (Critical) 2.6 Khác (Others) — — Tổng (Total) 116 324 Sự phân phối theo loại lỗi (Distribution by Defect Type) Số lượng lỗi % tổng lỗi STT Loại lỗi (Defect Type) (Number of Defects) (% of Total Defects) Lôgic (Logic) 33 28.4 Chuẩn (Standards) 29 25 Hiệu suất (Performance) 24 20.7 Mã dư thừa 14 12 7.7 (Redundant code) Giao diện người dùng (User interface) Kiến trúc (Architecture) 3.5 Sự quán 1.7 0.9 (Consistency) Khả tái sử dụng (Reusability) Tổng (Total) 365 10 PHÂN TÍCH NHÂN QUẢ VÀ BÀI HỌC KINH NGHIỆM (CAUSAL ANALYSIS AND LESSONS LEARNED) Có chênh lệch lớn hiệu suất quy trình; hiệu suất thực tế gần với dự kiến Những lý chênh lệch, chênh lệch lớn, đưa kèm theo Một số học quan trọng học là: Phát triển tăng dần (incremental development) phát triển theo giai đoạn (phased development) vô hữu ích để đạt chất lượng suất cao liệu từ giai đoạn sử dụng để cải thiện giai đoạn lại thông qua việc phòng ngừa lỗi (defect prevention) Phòng ngừa lỗi làm giảm đáng kể tỷ lệ tiêm lỗi Về mặt nỗ lực (effort), phòng ngừa lỗi giúp tiết kiệm nhiều nỗ lực; cách xài nỗ lực (giờ), đạt đến từ đến 10 lần tiết kiệm nỗ lực thông qua hình thức giảm nỗ lực làm lại (rework effort) 325 Nếu yêu cầu thay đổi có ảnh hưởng lớn, việc thảo luận với khách hàng cách sử dụng phân tích chi tiết tác động hữu ích việc thiết lập kỳ vọng làm phân tích lợi ích mặt chi phí (cost-benefit) cách cách thức (có thể dẫn đến việc phải hoãn trì hoãn thay đổi, xảy dự án ) Lỗi hiệu loại bỏ (defect removal efficiencies) việc xem xét lại mã (code reviews) kiểm thử đơn vị (unit testing) thấp Quy trình cho hai, việc cài đặt (thực hiện) quy trình này, cần phải xem xét lại để cải thiện số Trong dự án này, kiểm thử tích hợp hệ thống bù đắp cho hiệu hoạt động xem xét lại kiểm thử đơn vị Tuy nhiên, dự án lớn, điều hiệu hoạt động xem xét lại kiểm thử đơn vị có ảnh hưởng xấu đến chất lượng 11 CÁC THÀNH PHẦN CỦA QUY TRÌNH TRÌNH ĐƯỢC NỘP (PROCESS ASSETS SUBMITTED) Kế hoạch quản lý dự án (project management plan), tiến độ (biểu thời gian) dự án (project schedule), kế hoạch quản lý cấu hình (configuration management plan), tiêu chuẩn cài đặt mã Java (Java coding standards), danh sách kiểm tra để xem xét lại mã (code review checklist), danh sách kiểm tra để xem xét lại kế hoạch tích hợp (integration plan review checklist), danh sách kiểm tra để phân tích tác động (impact analysis checklist), báo cáo phân tích nhân để phòng ngừa lỗi (causal analysis reports for defect prevention) 12 TÀI LIỆU THAM KHẢO Bỏ qua 12.3 TÓM TẮT Một dự án không kết thúc sau giao cài đặt phần mềm; trước đóng lại, phải sử dụng cho việc học tập Phân tích kết thúc dự án phương pháp để đạt mục tiêu 326 Sau số học quan trọng rút từ cách tiếp cận Infosys để kết thúc dự án:  Phân tích kết thúc dự án dựa vào số đo (metrics) Phân tích liệu để hiểu hiệu suất dự án nguyên nhân gây chênh lệch lớn Những nguyên nhân dùng nguồn để tạo sáng kiến cải tiến  Việc phân tích số đo nên báo cáo chất lượng cuối giao cho khách hàng (productivity achieved), phân phối nỗ lực (distribution of effort) phân phối lỗi (distribution of defects), hiệu việc việc loại bỏ lỗi (defect removal efficiency) hoạt động chất lượng khác nhau, chi phí chất lượng (cost of quality)  Thu thập thành phần quy trình kế hoạch (plans), danh sách kiểm tra (checklists), tiêu chuẩn (standards), hướng dẫn (guidelines), làm cho chúng dùng lại (available) người khác Đối với CMM, kết thúc dự án (project closure) yêu cầu trực tiếp KPAs quản lý dự án Tuy nhiên, báo cáo kết thúc (closure report) dung để cung cấp liệu cho sở liệu quy trình (process database) để tạo baseline khả quy trình (process capability baseline) – cần đến để để đáp ứng nhiều yêu cầu KPA Lập Kế Hoạch Cho Dự Án (Project Planning KPA) KPA Quản Lý Phần Mềm Tổng Hợp (Integrated Software Management KPA) Chúng hỗ trợ cho việc học tập (learning) lưu trữ hồ sơ (record keeping), yêu cầu CMM mức 12.4 CÁC THAM KHẢO S Brady and T DeMarco Management-aided software engineering IEEE Software, Nov 1994 E.J Chikofsky Changing your endgame strategy IEEE Software, Nov 1990 B Collier, T DeMarco, and P Fearey A defined process for project postmortem review IEEE Software, July 1996 R Grady Successful Software Process Improvement Prentice Hall PTR, 1997 K Caputo CMM Implementation Guide: Improvement Addison-Wesley, 1998 327 Choreographing Software Process V.R Basili and H.D Rombach The experience factory In The Encyclopedia of Software Engineering, John J Marciniak, editor John Wiley and Sons, 1994 K Kumar Post implementation evaluation of computer-based information systems: Current practices Communications of the ACM, Feb 1990 HẾT 328