Bài giảng Quản lý dự án phần mềm công nghệ thông tin (Phần 2) - Trường Cao đẳng công nghệ và nông lâm Nam Bộ

Nội dung text: Bài giảng Quản lý dự án phần mềm công nghệ thông tin (Phần 2) - Trường Cao đẳng công nghệ và nông lâm Nam Bộ

1. Chương 6. ƯỚC LƯỢNG Thời gian: 06g (LT: 03g; TH: 03g) Mục đích: Sau khi học xong phần này người học có khả năng: - Trình bày được các kỹ thuật ước lượng trong dự án CNTT, các cách tiếp cận ước lượng trong dự án; - Thực hiện được các công việc ước lượng, hệ số năng suất toàn cục và tỉ lệ hiệu chỉnh năng suất trong dự án; - Rèn luyện ý thức lao động, tác phong công nghiệp, có trách nhiệm và sáng tạo. Nội dung: 6.1. KHÁI NIỆM VỀ ƯỚC LƯỢNG. Nhà quốc hội Scotland được thiết kế bởi Enric Miralles, kiến trúc sư người Tây Ban Nha và hai nhóm thiết kế EMBT, RMJM. khởi công chưa được bao lâu cả kiến trúc sư và đại diện chủ đầu tư đều qua đời bởi bạo bệnh. Trong và sau thời gian thi công, công trình là đề tài quan tâm hàng đầu của báo chí Anh. Năm 2003, tòa nhà quốc hội trở thành vấn đề So với thiết kế ban đầu, tòa nhà được xây dựng trên khu đất rộng hơn 30.000m , tăng hơn 14.000m , kinh phí tăng từ 75 triệu USD lên 830 triệu USD. Công trình hoàn thành vào tháng 10-2004, chậm tiến độ mất 4 năm [13]. Rất nhiều các dự án khác trên thế giới cũng gặp tình trạng tương tự. Hình như sự ước lượng chi phí và thời gian không bao giờ đủ để thực hiện dự án! Ước lượng không đúng là nguyên nhân thất bại của việc quản trị dự án trong nhiều lĩnh vực khoa học, và ngành khoa học phần mềm cũng thế. Tại sao việc ước lượng dự án lại khó như vậy? –Do: - Ước lượng không phải là một ngành khoa học chính xác. - Bản chất của dự án là duy nhất và liên quan đến sự không chắc chắn. Đã vậy, việc ước lượng sức gia công thường diễn ra trong giai đoạn đầu của dự án; ở giai đoạn này, dự án chưa thể được ước lượng chi tiết chính xác. Chỉ đến khi yêu cầu đã được hiểu rõ, thông tin có nhiều hơn; lúc đó trưởng dự án mới hoàn chỉnh chi tiết việc ước lượng. 63
2. Hơn nữa, ước lượng không phải là việc làm 1 lần rồi xong mà là một công việc sẽ tái diễn nhiều lần trong qui trình sống dự án. Trong ước lượng, người ta không dùng từ „chính xác‟ mà thay bằng từ „hợp lý‟, „đáng tin cậy‟. Thật vậy, trong những dự án phần mềm, không ai có thể trả lời chính xác câu hỏi “Liệu ước lượng này có chính xác không? Vì cách duy nhất để biết một ước lượng có chính xác không là so sánh nó với những nỗ lực thực tế đã bỏ ra, nghĩa là khi công việc được ước lượng đó đã được thực hiện xong!. Không có giải pháp nhanh và có sẵn cho vấn đề ước lượng. Tuy nhiên, trưởng dự án cũng có thể nâng cao kỹ năng ước lượng của họ bằng cách sử dụng những nguyên tắc, hướng dẫn (đã được kiểm tra) dựa trên các dữ kiện và kinh nghiệm. 6.2. CÁC KỸ THUẬT ƯỚC LƯỢNG SỨC GIA CÔNG. Định nghĩa: Sức gia công (effort): đại lượng đo lường công sức phải bỏ ra cho dự án. Đơn vị tính là người/tháng. 6.2.1. Kỹ thuật tương tự (Top-Down). Còn được gọi là kỹ thuật ước lượng Từ Trên Xuống, vì nó dựa trên thông tin của công việc gốc trong WBS-lúc này chưa biết rõ chi tiết của công việc. Được dùng lúc làm proposal đấu thầu dự án hoặc ở giai đoạn đầu của pha lên kế hoạch. Kỹ thuật này ước lượng chi phí bằng cách so sánh dự án mới với những dự án (công việc) tương tự mà đã hoàn thành trước đây. Ví dụ để ước lượng chức năng Tra Cứu Sách cho một thư viện, có thể tham khảo ước lượng của chức năng như vậy mà đã cài đặt rồi cho thư viện khác. Kỹ thuật này ít tốn kém, độ tin cậy càng cao nếu WBS của các dự án trước càng tương đồng với dự án đang được ước lượng. Lợi điểm của kỹ thuật này là các ước lượng đều dựa trên những kinh nghiệm thực tế. Nhưng trong thực tế thường là không có dữ liệu lịch sử của những dự án tương tự. 6.2.2. Ước lượng từ dưới lên (Bottom-Up). Được dùng để ước lượng chi tiết của từng gói công việc (công việc lá) trong WBS. Sau đó tính tổng tất cả thì sẽ được chi phí của toàn dự án. Kỹ thuật này cho ra kết quả khá chính 64
3. xác, nhưng tốn kém, và có hạn chế là phải có đầy đủ thông tin rồi mới thực hiện ước lượng vì không phải lúc nào dữ liệu chi tiết cũng có sẳn. Đặc biệt đây là kỹ thuật tốt nhất để định danh các yếu tố rủi ro. Cả 2 cách tiếp cận bottom-up và top-down cần những thông tin của dự án như kích thước (top-down), và danh sách các công việc (bottom-up), trong nhiều trường hợp, hai cách tiếp cận này bổ sung cho nhau. Cả hai loại sẽ cho ra ước luợng chính xác hơn nếu thông tin về dự án có nhiều hơn. Ví dụ, việc ước lượng kích thước sẽ khó hơn nhiều khi dự án chỉ mới nhận được các yêu cầu ở mức thô nhưng sẽ dễ hơn khi phần thiết kế đã hoàn tất, và ngay cả dễ hơn và chính xác hơn khi phần cài đặt mã nguồn được tiến hành. Vì thế, độ chính xác của ước lượng phụ thuộc vào thời điểm ước luợng, và độ chính xác sẽ tăng lên khi càng có nhiều thông tin về dự án 6.2.3. Mô hình tham số. Kỹ thuật này sử dụng các tham số, các thuật tóan toán học dựa trên các quan hệ về thống kê và dữ liệu lịch sử để ước lượng tổng quát cho dự án, nó còn có tên Ước lượng dựa Định lượng. Kỹ thuật này có thể được dùng chung với các kỹ thuật và phương pháp khác. Một điểm cần lưu ý là mô hình có thể không chính xác nếu không được tinh chỉnh và thẩm định đúng đắn, dữ liệu lịch sử dùng để tinh chỉnh mô hình có thể không thích hợp hoàn toàn cho dự án mới. Nếu mô hình được tinh chỉnh và được thẩm định một cách đúng đắn thì kết quả của mô hình thường chính xác hơn kết quả của các kỹ thuật khác hoặc tệ lắm cũng có độ tin cậy tương đương Do ưu điểm này nên kỹ thuật này thường được sử dụng rộng rãi không những trong các công ty phần mềm mà còn trong những ngành công nghiệp khác. Hiện nay có nhiều mô hình ước lượng phần mềm tham số hóa phức tạp để tính toán chi phí và thời gian thực hiện dự án phần mềm. trong đó có một số mô hình thông dụng nhất là COCOMO (Constructive Cost Model), Function Point, PRICE S® Price Software Model) và SEER-SEM ® (Galorah Software Evaluatiion and Estimation of Resource Software Estimating Model) 65
4. Một ví dụ đơn giản của kỹ thuật này là để ước lượng chi phí cho việc xây một căn nhà, người ta thường dùng tham số là số tiền trên một mét vuông. 6.2.4. Ước lượng theo sự phân phối sức gia công. Kỹ thuật này dùng phần trăm của các pha (kinh nghiệm) trong dự án để ước lượng. Ví dụ: - Pha lên kế hoạch 10% - Pha thu thập yêu cầu 20% - Pha phân tích, thiết kế 20% - Pha mã hóa 20% - Pha thử nghiệm 30% 6.3. CÁC CÁCH TIẾP CẬN ƯỚC LƯỢNG. Ứng với mỗi kỹ thuật ước lượng, có một hoặc nhiều phương pháp tiếp cận bổ xung cho nhau: 6.3.1. Historical data. Với các dự án thành công; trưởng dự án nên ghi nhận các ước lượng thật tế và dự kiến, các đặc trưng, trình độ và kỹ năng người thực hiện các công việc của dự án. Khi nhận một dự án mới, nếu trong dự án mới này có những công việc tương tự như các công việc trong các dự án cũ, thì trưởng dự án nên tham khảo các ước lượng cũ này trước khi quyết định các ước lượng cho dự án mới. Kết quả ước lượng sẽ rất đáng tin cậy nếu có một số lượng dự án tương tự cùng loại và gần giống nhau. 6.3.2. Tương tự như công việc khác trong cùng một dự án. Khi dự án có một số kết quả ban đầu, nghĩa là có một vài công việc đã hoàn thành xong, trưởng dự án nên duyệt xem trong dự án có công việc nào (chưa làm) tương tự như các công việc đã làm xong này không. Nếu có, nên tái ước lượng lại dựa trên các kết quả này. 6.3.3. Tư vấn từ chuyên gia. Khi dự án có liên quan đến công nghệ mới mà nhóm thực hiện không rành, thường nên tham khảo ý kiến của các chuyên gia về công nghệ mới này. Kỹ thuật này đặc biệt hữu ích 66
5. trong việc đánh giá những điểm khác nhau giữa các dự án trong quá khứ và dự án mới, những dự án duy nhất khi không có dữ liệu lịch sử nào. Nhưng kỹ thuật này có hạn chế là các chuyên gia khác nhau có thể đưa ra các ước lượng hết sức khác nhau cho cùng một dự án, một hạn chế khác nữa là các chuyên gia thường hay thiên lệch về một phía. Nên cẩn thận, đôi khi kiến thức của chính chuyên gia cũng có vấn đề. 6.3.4. Brainstorm. Lấy ý kiến từ nhóm. Phương pháp này hay được dùng trong ngành công nghệ thông tin. Trưởng dự án họp nhóm lại, đưa ra vấn đề và yêu cầu mỗi người ghi lại các ước lượng chủ quan của mình rồi nộp lại. trưởng dự án sẽ thống kê và chọn ra ước lượng hợp lý nhất. 6.3.5. Phương pháp 3 điểm. Còn có tên khác phương pháp PERT. Ứng với mỗi ước lượng sẽ có 3 giá trị ước lượng: - Ước lượng lạc quan nhất: O - Ước lượng trung bình: M - Ước lượng bi quan nhất: P - Ước lượng kết quả tính bằng công thức: (O + 4M + P)/6 6.3.6. Hệ số năng suất toàn cục (Global Efficiency Factor -GEF). Phương pháp này kết hợp thêm thời gian phi sản suất vào ước lượng. Ban đầu giả sử mỗi người được gán 100% năng suất. Sau đó, trưởng dự án tính toán thêmcác hệ số phi sản xuất, mỗi mục được gán một tỉ lệ phần trăm liên quan đến từng cái khác. Kế đó khấu trừ tỉ lệ phần trăm từ 100% để rút ra sự ước lượng thực tế nhất, theo bảng sau: Ví dụ: Công việc thiết kế sitemap cho khách hàng. Tổng thiếu hụt 25 Ước lượng hoàn thành công việc: 100 giờ Điều chỉnh ước lượng: 125 giờ ( =100 giờ + (100 giờ × 25%)) 67
6. Phương pháp GEF không phổ biến nhưng có nhiều người ủng hộ nó. Họ tin rằng nó điểm mặt được các thời gian phi sản xuất và do đó trừ khử được khuynh hướng lạc quan thái quá. Tuy nhiên, phương pháp GEF cũng có những hạn chế của nó. Phần trăm khấu trừ thường là chủ quan, do đó nó lệch theo ý kiến chủ quan của người ước lượng. Phần trăm cho mỗi sự khấu trừ thường rất khác nhau với những người ước lượng khác nhau. 6.3.7. Phần trăm điều chỉnh năng suất (Productivity Adjustment Percent -PAP). Phương pháp PAP thực hiện trên thang đo tổng quát hơn GEF. Áp dụng hệ số năng suất tổng quát để ước lượng cho tất cả các công việc. Ví dụ: với công việc Thiết kế sitemap cho khách hàng: Giả sử mỗi người được gán 80% năng suất. Vì trong thực tế không thể có ai có năng suất làm việc 100%. Một số thời điểm chắc chắn phải trải qua thời gian phi sản xuất, vì vậy, mỗi giờ ước lượng được điều chỉnh để tính thêm cho khoảng thời gian phi sản xuất (gọi điện thoại, họp, thời gian nghỉ ) Ta có: 100% - 80% = 20%. Vậy cộng thêm hệ số 20% này vào ước lượng cơ sở ban đầu 100%, ta được 120% hay 1.2. Vậy, hệ số tổng quát là 1.2 Ước lượng thực hiện công việc 100 giờ Điều chỉnh ước lượng 120 giờ (= 100 giờ x 1.2) Phương pháp PAP cũng có người ủng hộ vì hai lý do. Trước hết nó dựa trên các con số lấy từ kinh nghiệm. Việc nghiên cứu các độ đo trên công việc được sử dụng thường xuyên để tính ra phần trăm tổng quát. Thứ hai, dễ dàng để áp dụng tính toán này. Không có phần trăm khấu hao dựa trên công việc. Cũng không có bất kỳ tính toán phức tạp nào. Dù có hai lợi ích trên; nó vẫn có một vài điểm bất lợi. Việc ghi nhận lại kinh nghiệmkhông phải luôn luôn có sẵn để xác định hệ số năng suất cho công ty. Cũng vậy, do hệ số quá tổng quát nên khó phù hợp cho một công việc đặc biệt. Cuối cùng, nó không tính các độ phức tạp của vấn đề liên quan đến công việc. 68
7. Để sự ước lượng có một kết quả đáng tin cậy, người ta thường phối hợp càng nhiều phương pháp càng tốt, sau đó sẽ tổng hợp các kết quả để chọn ra một kết quả thích hợp nhất. 6.3.8. Quỹ thời gian dự trữ. Ngoài ra nên tạo quỹ thời gian dự trữ bằng cách tạo một công việc giả (công việc này không làm gì) – xếp công việc này là công việc cuối cùng trong SĐMCV của ĐA - có TGTH= từ 5% đến -10% tổng TGTH của dự án. 6.4. KHÁI NIỆM VỀ LỊCH BIỂU. Định nghĩa: - Lịch biểu (schedule): thời gian thực hiện (của công việc/dự án) tương ứng với sức gia công được cấp. - Một khi mà sức gia công đã được xác định (ước lượng) xong, thì sẽ có nhiều lịch biểu khác nhau (hay thời gian thực hiện của dự án) phụ thuộc vào số lượng tài nguyên (con người) được cấp cho dự án đó. Ví dụ, một dự án có ước lượng sức gia công là 56 người-tháng, thì: - Lịch biểu 8 tháng với nhân lực là 7 người là hoàn toàn hợp lý - Hoặc một lịch biểu sử dụng 8 người trong 7 tháng cũng có thể xảy ra, - Thậm chí một lịch biểu trong 9 tháng với 6 người cũng có thể chấp nhận được. Điều đó hoàn toàn đúng trên lý thuyết. Tuy nhiên, trên thực tế, nhân lực và thời gian thực hiện đề án thì không phải có thể thay đổi tuỳ ý được. Ví dụ như một lịch biểu sử nhân lực là 56 người trong một tháng thì không thể chấp nhận được, mặc dù nó vẫn “khớp” với yêu cầu đặt ra. Tương tự, không ai thực hiện dự án trong 28 tháng với 2 người. Nói cách khác, khi mà sức gia công đã chốt lại, bạn có thể linh hoạt xây dựng lịch biểu bằng cách bố trí nhân lực cho dự án đó một cách phù hợp. Nhưng sự linh hoạt này cũng có giới hạn, các dữ liệu trên thực tế đã cho thấy là không tồn tại một phương trình tuyến tính giữa sức gia công và lịch biểu thực hiện dự án. "Kéo dài" một lịch biểu thì rất dễ dàng; đơn giản chỉ cần dùng ít người hơn (mặc dù dự án có thể sẽ mất đi giá trị nếu thời gian hoàn tất quá lâu). Tuy nhiên việc rút ngắn thời gian của một dự án lại không hề dễ dàng. Một ví dụ điển hình đã được nêu ở trên: không thể rút ngắn lịch biểu của một dự án 56 người lại chỉ còn trong một tháng mà không cần quan tâm 69
8. đến tài nguyên hiện có. Nói chung, việc rút ngắn một lịch biểu hơn mức cho phép sẽ làm tăng chi phí; bởi vì sẽ sử dụng nhiều tài nguyên hơn, điều này có thể sẽ gây lãng phí, nhiều công việc bị trùng lắp, và còn nhiều thứ khác nữa. Có một vài cách tiếp cận thảo luận về ảnh hưởng của việc rút ngắn lịch biểu trên tổng sức gia công. Tuy nhiên, để đánh giá được ảnh hưởng đó trước tiên phải xác định được lịch biểu chuẩn của dự án. Một phương pháp để xác định lịch biểu chuẩn là sử dụng một hàm thích hợp để xác định nó từ sức gia công cho trước. Hàm thích hợp này được suy ra bằng cách học những mẫu dữ liệu từ những dự án đã hoàn tất. Ví dụ, giả sử đã có được đồ thị phân bố của sức gia công và lịch biểu của những dự án đã hoàn tất, bạn có thể vẽ được 1 một đường cong hồi quy thông qua đồ thị này. Đường cong này thường là phi tuyến bởi vì lịch biểu không phát triển tuyến tính với sức gia công. Sau đó bạn có thể rút ra được phương trình của đường cong. Từ đó bạn có thể tính được lịch biểu cho một dự án với sức gia công đã được ước lượng sẳn. Nhiều mô hình đã đi theo cách tiếp cận này, tham khảo thêm [8] Phân phối lịch biểu khác với việc phân phối sức gia công. Với ba giai đoạn chính này, tỉ lệ phần trăm của lịch biểu được dùng trong giai đoạn xây dựng nhỏ hơn tỉ lệ phần trăm của sức gia công, vì giai đoạn này cần nhiều người hơn. Tương tự, tỉ lệ phần trăm của lịch biểu trong giai đoạn thiết kế và kiểm thử vượt hơn tỉ lệ sức gia công cho giai đoạn đó. Lịch biểu chính xác phụ thuộc vào đỉnh cao nhân lực. Cho trước 1 sức gia công đã ước lượng cho 1 pha nào đó, người ta có thể xác định được thời gian thực hiệc của pha đó nếu biết được đỉnh nhân lực 6.5. ƯỚC LƯỢNG THỜI GIAN THỰC HIỆN. Việc ước lượng thời gian thực hiện cũng không đi ra ngoài các kỹ thuật ước lượng liệt kê ở trên. Để việc ước lượng thời gian thực hiện đáng tin cậy, nên lưu ý các yếu tố sau: Các yếu tố ảnh hưởng thời gian thực hiện - WBS: sơ đồ phân rã công việc phải khá chi tiết (nếu dùng kỹ thuật từ dưới lên), có khả năng tự giải thích được cách đi đến kết quả cuối cùng. 70
9. - Khả năng nhân sự: ở giai đoạn đầu của ước lượng, trưởng dự án có thể không biết cụ thể nhân sự nào; do đó khi ước lượng, chỉ có thể phỏng đoán dựa trên nhân sự có năng lực trung bình. Nhưng khi dự án được thực thi thì có thể gặp nhân sự có năng lực thấp hoặc cao hơn trung bình. Điều này làm ảnh hưởng thời gian thực hiện - Hiệu năng làm việc: Khi đang làm việc, đương sự bị gián đoạn do điện thoại gọi, có người tìm v v Khi giải quyết xong các công việc đột suất đó, đương sự phải mất một ít thời gian mới lấy lại được trạng thái làm việc như lúc trước khi bị gián đoạn. Sự gián đoạn này làm mất thời gian cũng như năng xuất làm việc. Trưởng dự án không biết tần suất gián đoạn là bao nhiêu lần trong ngày. Nhưng có thể khống chế sự gián đoạn này bằng cách đưa ra những qui định, qui chế về tiếp khách riêng, gọi điện thoại, check mail,.v v trong giờ làm việc. - Độ phức tạp của công việc. - Cá tính, kiến thức về ứng dụng, ngôn ngữ, máy móc của nhân sự: một nhân sự có kiến thức rộng và sâu kèm theo cá tính tốt thì đương nhiên sẽ thực hiện công việc có chất lượng và nhanh hơn. - Các biến cố bất ngờ: cúp điện, kẹt xe, cung cấp vật tư trễ, - Hiểu lầm và sai sót - Một đề nghị chia phần trăm thời gian theo tỷ lệ sau: + Lên kế hoạch, thu thập yêu cầu, phân tích, thiết kế: 50% + Lập trình: 20%, + Kiểm thử: 30% 9.5.1. Các loại thời gian Trong suốt qui trình thực hiện dự án, trưởng dự án một mặt phải ước lượng nguồn lực cho công việc; một mặt phải tính toán chi phí công việc, chi phí công lao động, ; một mặt phải lên lịch (định thời gian) giao việc cho thành viên trong nhóm, hoặc lên lịch giao sản phẩm cho khách hàng. Ứng với mỗi mặt như vậy, trưởng dự án sẽ phải dùng các đơn vị thời gian khác nhau. Phần dưới đây giới thiệu các loại thời gian và cách sử dụng chúng. 9.5.1.1. Định nghĩa: 71
10. Thời gian thực hiện (Duration): tính bằng ngày (mặc nhiên 8 tiếng) làm việc, không tính ngày lễ, weekend. Thời gian lao động (Work effort): thời gian cần để hòan tất một công việc. Tính bằng giờ liên tục hoặc không liên tục Thời gian lịch: tính bằng ngày dd/mm/yy liên tục, kể cả lễ, weekend. 9.5.1.2. Cách sử dụng: Thời gian thực hiện: để tính thời gian hòan tất công việc hay dự án. Thời gian lao động: tính chi phí, lương. Thời gian lịch: để giao tiếp. Ví dụ: Quang thiết kế module giao diện nhập hàng trong 6 ngày, mỗi ngày Quang làm 4 giờ. Bắt đầu từ ngày 4/01/2018 (xem lịch). Hỏi: - Thời gian lao động? - Thời gian thực hiện? - Thời gian lịch? .Thời gian thực hiện bị ảnh hưởng bởi tài nguyên nhưng không phải ảnh hưởng theo quan hệ tuyến tính. Mỗi công việc có điểm tới hạn về tài nguyên, vượt qua điểm này sự ước lượng sẽ không còn hợp lý 72
11. Chương 7. TÍNH TOÁN CHI PHÍ Thời gian: 04g (LT: 02g; TH: 02g) Mục đích: Sau khi học xong phần này người học có khả năng: - Trình bày được tầm quan trọng của chi phí trong dự án CNTT, các qui trình quản lý chi phí; - Tính toán được chi phí của dự án CNTT; - Rèn luyện ý thức lao động, tác phong công nghiệp, có trách nhiệm và sáng tạo. Nội dung: Trưởng dự án phải chịu trách nhiệm về ngân sách của dự án và có nhiệm vụ báo cáo các mức độ chi tiêu chênh lệch của dự kiến so với thực tế, lên quản lý cấp trên. Dự án có rất nhiểu đề mục cần phải chi tiêu, trưởng dự án phải nắm rõ các đề mục này và lên kế hoạch chi tiêu hợp lý, khi dự án được thực thi, phải theo dõi và giám sát các thu, chi để chắc chắn rằng số tiền chi tiêu phải nằm trong kế hoạch chi tiêu đó. 7.1. CÁC ĐỀ MỤC CẦN CHI PHÍ. Sau đây là một số các đề mục điển hình cần phải được tính chi phí trong kế hoạch chi tiêu của dự án, nếu bỏ qua hoặc tính sót thì dự án có khả năng bị lỗ hay vượt chi. 7.1.1. Chi phí từng công việc: Ứng với mỗi gói công việc ở WBS, đã ước lượng được thời gian thực hiện và tài nguyên gồm nhân sự và các vật tư để thực hiện công việc đó. Chi phí này được tính như sau: Chi phí (CV) = chi phí(nhân sự) + chi phí (vật tư). 7.1.2. chi phí phi lao động (Non-labour cost): - Ở Tiệc: Để nhóm làm việc có điều kiện hiểu nhau và đoàn kết, thường nên tổ chức một số buổi tiệc nhẹ/nặng ở các cột mốc chính của dự án như kickoff meeting, pha thực thi dự án, kết thúc dự án, v v - Ở Du lịch: Nếu dự án có kế hoạch cấp một số suất đi du lịch, tham quan để học tập. - Ở Phòng: Nếu dự án có thuê mặt bằng để hoạt động. 73
12. - Ở v v 7.1.3. Chi phí điều hành: Chi phí khấu hao của các máy móc, các tiện ích, thiết bị, vật dụng hỗ trợ hành chánh như máy tính, máy in, máy photo, viết, giấy, v v 7.1.4. Chi phí lạm phát: Nếu dự án thực hiện trong nhiều năm, cần phải cộng thêm tỉ lệ lạm phát 7.1.5. Chi phí rủi ro bất ngờ: Đề phòng những rủi ro không lường trước được. Chi phí này được tính, tùy theo độ phức tạp, từ 5% đến -8% tổng chi phí của dự án. 7.1.6. Chi phí hoạt động: Gồm: - Phí huấn luyện: nếu dự án có nhu cầu mời chuyên gia huấn luyện một kỹ năng nào đó cho nhóm. - Phí thăm bịnh: trường hợp nhân sự trong nhóm hoặc khách hàng bị bịnh, tai nạn thì trưởng dự án hoặc đại diện phải thăm bệnh với quà để động viện và tỏ sự quan tâm. - Thưởng Lễ, tết: nếu thời gian thực hiện dự án có bao hàm các ngày lễ quốc tế như lễ Lao Động 1/5; các ngày lễ quốc gia như tết nguyên đán, 30/4, 2/9, v.v Linh tinh, Nên nhớ tất cả các hoạt động trên chẳng những khiến dự án phải tốn thêm chi phí mà nhân sự lại ở tình trạng không làm việc. Nghĩa là ngoài việc phải tính thêm chi phí, trưởng dự án phải tính thêm thời gian tiêu thụ của các hoạt động này vào dự án. Quỹ phòng hờ (Buffer budged): với sự đồng ý của khách hàng, quỹ này được tính thêm bằng 10%-20% trị gía dự án. Quỹ được sử dụng để tính các chi phí khi phía khách hàng thay đổi yêu cầu, thêm chức năng, v v , nhằm tránh cho khách hàng khỏi phài tốn thời gian thuyết phục, xin phép, làm giấy tờ thu chi với công ty của họ khi có sự thay đổi hoặc thêm chức năng. Khi kết thúc dự án, số tiền còn dư trong quỹ sẽ được trả lại khách hàng. 74
13. 7.2. CÔNG THỨC TÍNH CHI PHÍ. Như đã nói, có nhiều thành phần trong dự án phải tiêu xài tiền. Các thành phần tiêu biểu là: - Trang thiết bị (mua, xin, mướn, mượn) - Cơ sở vật chất (facilities) (không gian phòng ốc, kho dữ liệu) - Lao động (nhân công, hợp đồng) - Các vật dụng (giấy, viết, mực , và vài thứ lặt vặt khác) - Huấn luyện (các buổi seminar, hội nghị, hội thảo khoa học) - Vận tải (đường bộ, đường thủy , đường hàng không) Công thức tính các chi phí này: - Trang thiết bị = giá mua hoặc = Giá thuê × khoảng thời gian thuê hoặc = Giá mướn × khoảng thời gian mướn - Cơ sở vật chất = Giá thuê × khoảng thời gian thuê hoặc = Giá mướn × khoảng thời gian mướn - Chi phí lao động = (thời gian lao động × đơn giá mỗi giờ) + (số giờ làm việc thêm trong tuần × 1.5 đơn giá mỗi giờ) + (các giờ làm việc thêm vào lễ, weekend × 2 đơn giá mỗi giờ) Trong đó đơn giá lao động mỗi giờ: dựa vào khả năng nhân sự + độ phức tạp của công việc + xu hướng thị trường - Các vật dụng = số lượng × đơn giá của từng đơn phẩm - Chí phi huấn luyện = (chi phí giảng dạy × đơn giá mỗi giờ × số lượng người có mặt) + (tổng chi phí lao động cho người có mặt) - Chi phí vận tải = (đơn giá theo giờ, hàng ngày, hàng tháng, hàng năm) × (thời gian sử dụng) 7.3. PHÂN LOẠI CHI PHÍ. 7.3.1. Chi phí trực tiếp và chi phí giám tiếp. - Chi phí trực tiếp liên quan đến việc tạo ra sản phẩm. 75
14. Ví dụ, chi phí mua nguyên vật liệu và trả công người lao động. - Chi phí gián tiếp là những chi phí khác không cần thiết liên quan tới tạo ra sản phẩm. Ví dụ, tiền thuê mướn và thuế. 7.3.2. Chi phí tuần hoàn và chi phi phí không tuần hoàn. - Chi phí tái diễn: Xuất hiện thường xuyên Ví dụ, sự chi trả lâu dài cho các cơ sở vật chất hoạt động. - Chi phí không tái diễn: Chỉ xuất hiện một lần Ví dụ, tiền mua thiết bị 7.3.3. Chi phí cố định và chi phí biến động. Chi phí cố định: chi phí không thay đổi theo khối lượng công việc- ví dụ, chi phí sử dụng các cơ sở vật chất. Chi phí biến động: chi phí phụ thuộc vào tiêu dùng và khối lượng công việc được làm - ví dụ, chi phí cho nguyên vật liệu. 7.3.4. Các chi phí lao động bắt buộc và không bắt buộc. Chi phí lao động bắt buộc: bao gồm tiền trả cho các phúc lợi– ví dụ, bảo hiểm xã hội, y tế và không gian phòng ốc và chi phí hoạt động. Chi phí lao động không bắt buộc: chi phí lao động – phí lao động bắt buộc 7.3.5. Lao động trong giờ và lao động ngoài giờ. - Số giờ lao động trong giờ thì nhỏ hơn hoặc bằng 40 giờ (=8h x 5 ngày) mỗi tuần. - Số giờ lao động ngoài giờ thì lớn hơn 40 giờ mỗi tuần, bao gồm thời gian làm việc ngoài giờ trong tuần và ngoài giờ trong ngày lễ, weekend. 7.4. CÁC YẾU TỐ ẢNH HƯỞNG VIỆC TÍNH TOÁN CHI PHÍ. Việc đạt được sự ước lượng chi phí đáng tin cậy phụ thuộc vào các ước lượng thời gian. Vì hầu hết các ước lượng chi phí dựa vào số lượng giờ lao động để hoàn thành công việc. Do đó, nếu sự ước lượng công việc là đáng tin cậy, thì các ước lượng chi phí cũng có độ tin cậy tương đương, bởi vì chi phí là kết quả của đơn giá làm việc theo giờ nhân với tổng thời gian làm việc. 76
15. Hơn nữa, các ước lượng thường dựa trên các giả thiết. Trừ phi các giả thiết được làm rõ, nếu không chúng có thể đưa đến việc hiểu sai và cho ra các tính toán không chính xác. Vì thế các giả thiết phải được giải thích rõ trong bản phát biểu công việc. 7.5. CÁCH TIẾP CẬN QUẢN LÝ CHI PHÍ. Nếu không quản lý chi tiêu một cách chặt chẻ thì nguy cơ dự án bị vượt chi là rất cao. Trưởng dự án phải có nhiệm vụ rà soát để loại bỏ hoặc cắt giảm các chi tiêu phí phạm, không hợp lý trong quá trình thực hiện dự án. Quản lý chi tiêu nên được tiếp cận theo qui trình để tính toán và đưa ra cái nhìn thực tế về toàn bộ chi phí của dự án. Trong đó chi phí cho hoạt động (overhead) và vật liệu có ảnh hưởng rất lớn trong tổng chi phí của dự án. Do đó trưởng dự án không những phải tập trung vào các quy trình và cải tiến quy trình để giảm bớt chi phí hoạt động, chi phí vật liệu, mà còn phải tập trung vào khách hàng vì chi phí thật sự của sản phẩm cuối cùng được tính cho khách hàng. Để làm được như vậy, trưởng dự án phải đóng vai trò quan trọng trong việc xác định rõ: - Khách hàng muốn những gì (SOW). - Danh sách các công việc đáp ứng các mong muốn này của khách hàng (WBS). - Tổng số tiền (ước lượng chi phí) để tạo ra sản phẩm hoặc dịch vụ. - Các chi phí trực tiếp hoặc gián tiếp trong thực tế - Các quy trình nào cần cải tiến hoặc bỏ đi để gia tăng sự thỏa mãn cho khách hàng và giảm bớt các chi phí. 77
16. Chương 8. PHÂN PHỐI TÀI NGUYÊN Thời gian: 04g (LT: 01g; TH: 02g; KT:1g) Mục đích: Sau khi học xong phần này người học có khả năng: - Trình bày được vai trò của tài nguyên trong công tác tổ chức thực hiện dự án CNTT và từ đó thấy được tầm quan trọng của việc quản lý tài nguyên trong dự án, được qui trình cân đối tài nguyên trong dự án CNTT; - Cân đối được kinh phí của dự án CNTT; - Rèn luyện ý thức lao động, tác phong công nghiệp, có trách nhiệm và sáng tạo. Nội dung: 8.1. GIỚI THIỆU Như đã biết, trưởng dự án phải quản lý một lượng lớn tài nguyên đa dạng gồm con người, vật tư, thiết bị, phòng ốc, các công cụ, những tiện ích .v v Anh ta có nhiệm vụ phân phối tài nguyên sao cho bảo đảm việc sử dụng chúng với một hiệu quả cao nhất có thể được. Trong các tài nguyên thì con người là nguồn tài nguyên quí và rất khó quản lý. Do đó ở đây chỉ tập trung minh họa những nguyên tắc phân phối tài nguyên con người. Các loại tài nguyên khác được ứng dụng tương tự. Phân phối tài nguyên gồm các bước sau: 1. Xác định những công việc liên quan Trưởng dự án dựa trên sơ đồ mạng công việc (network diagram) để xác định những công việc của dự án. Những công việc này tương ứng với những gói công việc (cấp lá) trong sơ đồ phân rã công việc (WBS). 2. Phân phối tài nguyên cho những công việc Khi phân phối nguồn tài nguyên con người, trưởng dự án nên xét đến các yếu tố sau: - Khả năng sẵn sàng của tài nguyên. - Khả năng sẵn sàng của ngân sách. - Giáo dục / huấn luyện. - Công cụ hổ trợ. 78
17. - Sự thành thạo. - Sự mong đợi hoặc lợi ích của cá nhân. - Kiến thức. - Cá tính. - Khả năng làm việc đội, nhóm. Trưởng dự án cũng nên xét những yếu tố thuộc về cách cư xử như nhân cách. Ví dụ một vài người không thích hợp để làm những nhiệm vụ tưởng như đơn giản (một kĩ sư có thể giỏi nhưng không thích hợp để làm công việc của người bán hàng), hoặc phân 2 người có mâu thuẫn cá nhân làm chung 1 việc. Ngoài ra, cũng nên sử dụng các động cơ thúc đẩy để kích hoạt nhân viên vươn lên những tầm cao, rộng hơn. Ví dụ: Phân công việc có khả năng mở rộng cho người mà ta muốn thử thách năng lực để xem người đó có khả năng đảm trách hay không. Chỉ định những công việc phong phú để thúc đẩy những thành viên khác trong nhóm. Phân công những công việc một cách luân phiên với nhau. Dĩ nhiên, sẽ có một vài rủi ro, mà phần lớn chính là sự bất lực của con người khi tham gia vào những vai trò không quen thuộc hoặc phải mang nhiều trách nhiệm hơn. Tuy nhiên, trưởng dự án nên áp dụng điều này khi có cơ hội, vì lợi ích trong việc phát hiện những khả năng tiềm ẩn của nhân sự sẽ vượt thắng những rủi ro. Khi phân phối tài nguyên, trưởng dự án nên áp dụng những heuristic sau: 1. Gán độ ưu tiên cao nhất cho những công việc nằm trên đường căng. 2. Với những công việc không nằm trên đường căng (Critical Path) thì gán độ ưu tiên của công việc tùy theo độ thả nổi, nghĩa là công việc có độ thả nổi thấp thì sẽ có độ ưu tiên cao hơn. 3. Nếu 2 công việc có cùng độ thả nổi thì ưu tiên cho công việc phức tạp hơn. 8.2. CÂN ĐỐI TÀI NGUYÊN. 79
18. Sau khi phân công tài nguyên, trưởng dự án phải mô tả việc sử dụng từng tài nguyên trên một đồ hình để xem coi có tài nguyên nào bị phân công quá tải hay quá ít không. Các phần mềm quản trị dự án (như MS Project) hầu hết đều có hổ trợ chức năng này. Hình H 8.1 - Trục X biểu diễn thời gian. - Trục Y biểu diễn giờ tích lũy của một tài nguyên (nhân sự) để thi hành một hoặc nhiều nhiệm vụ trong một khoảng thời gian xác định. - Vạch ngang: biểu diễn 100% năng suất của tài nguyên, ví dụ 8 giờ/ngày. Đồ hình ban đầu thường là một hình không đều. Những điểm cao là đỉnh (peak), phản ánh cách dùng tài nguyên nhiều hơn, tại một khoảng thời gian cụ thể nào đó. Những điểm thấp là thung lũng (valley), phản ánh cách dùng tài nguyên thấp hơn, tại một khoảng thời gian cụ thể nào đó. Hình 5.1 là một ví dụ của một biểu đồ với một vài đỉnh và thung lũng. Nếu các đỉnh và thung lũng hội tụ về đường vạch ngang có nghĩa đã phân công tài nguyên có hiệu quả vì sử dụng được gần hết năng suất của tài nguyên. Một đồ hình không đều phản ánh những tài nguyên được dùng là không hiệu quả. Những đỉnh (càng) vượt quá vạch ngang cho thấy nhân sự bị phân công (rất) quá tải, có thể phải làm thêm ngoài giờ mới hoàn thành công việc. Những thung lũng càng xa vạch ngang cho thấy chưa tận dụng hết năng suất của nhân sự. Do đó trưởng dự án phải giảm số lượng đỉnh và thung lũng bằng cách làm đồ hình càng phẳng càng tốt nghĩa là làm cho chúng hội tụ về vạch ngang. Quá trình san bằng này gọi là cân đối tài nguyên (resource leveling). Tất nhiên, một đồ hình bằng phẳng là rất hiếm. 80
19. Hình H 8.2. 8.3. CÁC PHƯƠNG PHÁP CÂN ĐỐI TÀI NGUYÊN. Khi một tài nguyên -con người, vật tư thực hiện /được sử dụng trong nhiều công việc song song cùng lúc thì thường hay xẩy ra sự qúa tải. lúc này trưởng dự án phải cân đối để giảm tải cho các tài nguyên đó. Có thể dùng các phương pháp sau: 1. Trên SĐMCV, đổi các cặp công việc có quan hệ song song (SS- Start-Start) thành quan hệ tuần tự (FS - Finish-Start), nếu không làm ảnh hưởng đến thời gian hoàn tất của dự án. 2. Dùng thời gian trễ: thêm độ trễ (lag) giữa hai công việc gối đầu để giảm sự thực hiện đồng thời của chúng. 3. Kéo dài thời gian thực hiện của một công việc không thuộc đường căng sao cho không vượt quá độ thả nổi cho phép. Ví dụ một người được phân công 30% thời gian cho công việc 2 tuần (3 ngày), kéo dài thời gian thực hiện công việc này lên 3 tuần (giả sử không ảnh hưởng đến đường căng) thì phần trăm phân công sẽ giảm xuống là 20%. Cũng cùng một sức gia công, 3 ngày, đều thỏa cho cả 2 trường hợp, nhưng nhân sự có thêm thời gian cho các công việc gối đầu. 4. Thay đổi phần trăm thời gian phân công: nếu một người/tài nguyên thực hiện nhiều công việc song song cùng lúc, nên cắt giảm phần trăm thời gian cần cho mỗi công việc đó. Ví dụ một lập trình viên được phân công thực hiện 4 công việc, mỗi công việc cam kết 40 phần trăm, giảm 40 phần trăm này thành 25 phần trăm. 5. Phân công nhân sự lại: Nếu một người rảnh trong khi người khác lại qúa tải và nếu 2 người này kỹ năng tương đương nhau thì nên phân công lại cho họ. 6. Phân hoạch công việc: một số công việc có thể được phân hoạch thành các công việc nhỏ hơn và phân công cho 2 hoặc nhiều người thực hiện đồng thời. 81
20. 8.4. HỔ TRỢ PHÂN CÔNG NHÂN SỰ. Để hổ trợ việc phân công nhân sự được khá chính xác và nhanh chóng, trưởng dự án cần tổ chức các thông tin sau: 8.4.1. Cơ sở dữ liệu nhân sự: Trưởng dự án hoặc công ty nên có 1 cơ sở dữ liệu lưu trữ các thông tin cá nhân của các nhân sự. Ngoài các thông tin về lý lịch của từng cá nhân, cần thêm các thông tin sau: - Các kỹ năng và trình độ tương ứng, trình độ có thể cụ thể hóa bởi cho điểm. - Tính tình, sở thích, v v Hình H 8.3. 8.4.2. Cơ sở dữ liệu dự án: Lưu trữ các công việc của dự án. Ứng với mỗi công việc, cho biết: - Cần bao nhiêu người với kỹ năng, trình độ tương ứng. - Độ khó - V v Hình minh họa: giả sử dự án có các công việc A, B, C, Giả sử công việc A cần 1 người trình độ .Net 8 điểm, 82
21. Hình H 8.4. Phân công: Bây giờ phân công chỉ là vấn đề so khớp của 2 bảng trên để lọc ra các ứng viên thỏa yêu cầu. Sau đó trưởng dự án sẽ tự quyết định phân công cho nhân sự được chọn trong các ứng viên đó. Sau đây là một ví dụ bảng phân công ứng với bảng nhân sự và công việc trên: Có thể viết phần mềm hổ trợ cho chức năng phân công này. Hơn nữa, có thể khai thác cơ sở dữ liệu nhân sự và cơ sở dữ liệu dự án cho nhiều mục đích khác nữa. Ví dụ có thể khai thác các kinh nghiệm lên kế hoạch của các dự án đã thực hiện trong cơ sở dữ liệu dự án để lên kế hoạch cho một dự án mới. 83
22. Chương 9. QUẢN LÝ, KIỂM SOÁT DỰ ÁN Thời gian: 12g (LT: 02g; TH: 08g; KT:2g) Mục đích: Sau khi học xong phần này người học có khả năng: - Trình bày được các đặc điểm của dự án, được qui trình kiểm soát dự án CNTT; - Thực hiện được các công việc kiểm soát dự án; - Rèn luyện ý thức lao động, tác phong công nghiệp, có trách nhiệm và sáng tạo. Nội dung: 9.1. CÁC ĐẶC ĐIỂM CỦA DỰ ÁN CNTT. - Xu thế 84
23. Trước đây Ngày nay Dữ liệu thuần nhất Thông tin không thuần nhất (multimedia) Mainframes Mạng (cục bộ, diện rộng) Lập trình phân tán, lập trình hướng đối tượng, lập trình Lập trình tuần tự song hành Xây dựng các hệ thống thụ Xây dựng các hệ thống chủ động động Đặc điểm của việc xây dựng những phần mềm lớn - Có từ 10.000 đến 100.000 dòng lệnh (SLOC - Source Line Of Code, hoặc KSLOC = 1000 SLOC ) - Nhiều thành viên tham gia - Những chươg trình không được phép sai (ví dụ: điều khiển máy bay, quản lý các giao dịch ngân hàng, tính hoá đơn bán hàng ) Phân loại dự án Phân loại Lập trình viên Thời gian Số dòng lệnh (SLOC) Rất nhỏ 1 1 tháng 500 Nhỏ 1 1-6 tháng 1-2 K Vừa 2-5 1-2 năm 5-50 K Lớn dưới 100 2-3 năm 50-100 K Rất lớn dưới 500 4-5 năm 1000 K Cực lớn trên 500 5-10 năm trên 1000 K Dự án càng lớn => khả năng thành công càng ít. Sự khủng hoảng của những dự án phần mềm vào đầu những năm 70 Phần mềm nhiều lỗi Chạy không ổn định Trễ hạn Vượt quá kinh phí dự kiến Khó bảo trì 85
24. Phần cứng ngày càng rẻ Nhu cầu làm phần mềm ngày càng tăng Sự khủng hoảng đó vẫn còn dư âm đến tận ngày nay Theo Kiểm tra kế toán Mỹ (1979) 50 % dự án phần mềm vượt quá ngân sách 60 % dự án phần mềm bị trễ hạn 45 % phần mềm giao nộp nhưng không dùng được ngay 22 % phần mềm phi thiết kế lại 29 % phần mềm không bao giờ giao nộp Theo một số nguồn khác Tom De Marco (1982) : 25% Hệ mềm lớn thất bại Copers Jones (1991) : trung bình các hệ thông tin qun lý bị trễ 1 năm và vượt ngân sách 100% - Đặc thù riêng của việc làm phần mềm Không nhìn thấy được (invisibility) Không xác định rõ thế nào là "xong" (conformity) Độ phức tạp lớn (complexity) Dễ (bị) thay đổi (flexibility) - Độ đo của dự án CNTT Là những gì có thể định lượng hoá, nhằm đánh giá tiến độ, độ ổn định và chất lượng của việc phát triển phần mềm. Số liệu khách quan: số lượng giờ làm việc của các thành viên trong nhóm, SLOC, số lỗi mắc phải Số liệu chủ quan: phụ thuộc vào đánh giá chủ quan, ví dụ: mức độ khó khăn của bài toán, độ rõ ràng của các yêu cầu, Các thông tin về khách quan và chủ quan là bổ sung cho nhau. Các số liệu chủ quan là cơ sở để giải thích cho các số liệu khách quan Các số liệu khách quan là chỗ dựa để người phụ trách xem lại xem sự đánh giá của mình, sự hiểu của mình về bài toán đã chính xác chưa 86
25. Những thông tin khách quan phản ánh tiến độ hoặc tình trạng dự án. Ví dụ: số các module đã lập trình xong, số lượng các kiểm thử đã thực hiện. Những con số này sẽ cho thấy tiến độ đến đâu. 9.2. QUẢN LÝ DỰ ÁN. 9.2.1. Khái niệm về quản lý Quản lý (nói chung) là sự tác động của chủ thể quản lý lên đối tượng quản lý nhằm đạt được những mục tiêu nhất định trong điều kiện biến động của môi trường. - Có chủ thể quản lý (người quản lý). - Có đối tượng quản lý (người bị quản lý). - Có mục tiêu cần đạt được. - Có môi trường quản lý. Vì sao cần quản lý: Đạt mục đích theo cách tốt nhất trong hoàn cảnh môi trường luôn biến động và nguồn lực hạn chế. Quản lý tạo ra giá trị gia tăng của 1 tổ chức. Có thể cần phân tích thêm yếu tố quản lí trong điều kiện biến động của môi trường để thấy sự tương phản giữa quản lí cổ điển và quản lí hiện đại. Chính yếu tố biến động này đã dẫn tới việc quản lí theo dự án trở thành trọng tâm cho thời nay, đối lập với quản lí hành chính quan liêu cổ điển. 87
26. Bức tranh tổng thể về Quản lý dự án 9.2.2. Đặc điểm chung nhất của các hệ thống quản lý - Có chủ thể quản lý và đối tượng quản lý + Chủ thể quản lý: tạo ra các tác động quản lý. + Đối tượng quản lý: tiếp nhận các tác động của chủ thể quản lý. - Các mục đích là thống nhất giữa chủ thể và đối tượng quản lý. 88
27. - Có sự trao đổi thông tin nhiều chiều. Chủ thể quản lý phải thu nhận thông tin từ nhiều nguồn khác nhau. - Tính linh hoạt, thích nghi, điều chỉnh, đổi mới của chủ thể quản lý. Môi trường quản lý luôn biến động. Kết luận: Quản lý là một nghệ thuật, một khoa học, một nghề - Quản lý là một nghệ thuật. Vì sao là nghệ thuật: + Sự đa dạng, phong phú, muôn màu muôn vẻ của sự vật, hiện tượng. + Quản lý cơ quan hành chính ≠ quản lý doanh nghiệp ≠ quản lý trường học ≠ quản lý dự án. + Quản lý dự án A ≠ Quản lý dự án B. + Không phải mọi hiện tượng đều mang tính quy luật. + Không phải mọi quy luật đều đã được tổng kết thành lý luận. + Quản lý là sự tác động đến con người, mà con người thì rất phức tạp. Đòi hỏi người quản lý phải khéo léo, linh hoạt. + Hiệu quả quản lý phụ thuộc vào kinh nghiệm của người quản lý, cá tính của người quản lý, cơ may, vận rủi. - Quản lý là một khoa học. Vì sao là khoa học + Tổng hợp và vận dụng các quy luật: kinh tế, công nghệ, xã hội. + Vận dụng những thành tựu của khoa học, công nghệ trong quản lý: các phương pháp dự báo, tâm lý học, tin học. - Quản lý là một nghề Vì sao là một nghề: + Phải học mới làm được + Muốn thực hành được, phải có được nhiều yếu tố ban đầu: cách học, chương trình học, năng khiếu nghề nghiệp, ) 9.2.3. Các phương tiện phục vụ quản lý dự án 89
28. 9.2.3.1. Sử dụng phần mềm để trợ giúp quản lý dự án MỘT SỐ ĐẶC ĐIỂM KHI SỬ DỤNG PHẦN MỀM. - Phải chọn ra một phần mềm thích hợp để mua và sử dụng. - Phải học sử dụng phần mềm sao cho thành thạo (mất một thời gian ban đầu để học) - Nên sử dụng 1 phần mềm cho: + Tất cả các máy tính trong dự án; + Tất cả các công việc mà phần mềm có thể đáp ứng (tránh dùng các phần mềm khác nhau) - Nên để ý đến các phiên bản nâng cấp của phần mềm; - Phần mềm chỉ trợ giúp, không thể thay thế cho Người quản lý dự án. Nhiều người quản lý dự án cùng dụng 1 phần mềm, nhưng kết quả thành công khác nhau. Có rất nhiều công việc phải làm bằng tay và phải suy nghĩ rất cẩn thận (xác định bảng công việc, ước tính một số tham biến, ) - Dữ liệu cho phần mềm phải thường xuyên được cập nhật mới có ý nghĩa; - Người cập nhật phần mềm: Càng ít càng tốt. - Người xem phần mềm: càng nhiều càng tốt; - Biết sử dụng thành thạo 1 phần mềm còn hơn là biết sử dụng không thành thạo nhiều phần mềm; - Mọi dữ liệu nhập vào phần mềm chỉ là những dữ liệu thô thiển, trong khi thực tế còn rất nhiếu yếu tố khác không mô tả được, không định lượng được. - Nên kết hợp thêm với các phần mềm Word, EXCEL, Email 9.2.4. Sơ đồ luồng công việc Tóm tắt: - Cần phải xây dựng một số thủ tục làm việc trong dự án. - Mỗi thủ tục là một quy định/nội quy bắt buộc các thành viên dự án phải tuân theo. - Mỗi thủ tục là một bản viết rõ ràng, phát cho anh em, không nói bằng lời 9.2.5. Các thủ tục dự án 90
29. - Vì sao phải áp đặt các thủ tục + Tạo ra một chuẩn mực để trao đổi, làm việc trong nhóm một cách hiệu quả + Tập trung suy nghĩ, hành động của các thành viên trong tổ theo 1 hướng. + Tăng năng suất công việc (mọi việc quy định rõ ràng, không mất thời gian hỏi nhau) - Mỗi thủ tục đều phải trả lời các câu hỏi: Liên quan tới ai, cái gì, khi nào, ở đâu, thế nào và tại sao. - Việc xây dựng các thủ tục - Lưu ý: Chỉ nên đặt ra các thủ tục cho những nội dung chính, quan trọng (tuỳ người quản lý dự án quyết định). Nên xây dựng các thủ tục cho: + Kiểm soát thay đổi; + Sử dụng thiết bị; + Dùng các biểu mẫu; + Quy chế báo cáo; + Trách nhiệm của một số người trong dự án; + Họp hành; + Mua sắm vật tư, thiết bị. - Mô tả luồng công việc + Minh hoạ bằng hình vẽ cho các thủ tục 91
30. - Khối vuông: Xử lý. Mô tả lời, thường là một động từ và một bổ ngữ. - Điều kiện rẽ nhánh: Câu hỏi, trả lời "Có" hoặc "Không" 9.2.6. Hồ sơ quản lý dự án - Hồ sơ quản lý dự án: bao gồm tất cả các giấy tờ, tài liệu liên quan đến quá trình hoạt động của dự án. - Lưu trữ những gì: + Thư từ trao đổi với bên ngoài (thư đến, thư đi). + Các ước lượng thời gian. + Các biểu mẫu. + Các bản ghi nhớ. + Các biên bản các cuộc họp. + Các thủ tục. 92
31. + Các báo cáo. + Các quy định về trách nhiệm, quyền hạn trong dự án. + Các cập nhật lịch biểu. + Bảng công việc + Các tài liệu khác có liên quan. - Ai thực hiện việc lưu trữ Trợ lý Người quản lý dự án có trách nhiệm: + Phân loại tài liệu. + Tạo lập, thu thập, bổ sung hồ sơ. + Cung cấp tài liệu khi được yêu cầu. - Lưu trữ như thế nào. + Trên giấy: (không khuyến khích): Tổ chức thành các cặp tài liệu. + Trên máy tính (khuyến khích): Tổ chức thành các folder chia sẻ trên mạng (Nếu Dự án trải rộng trên nhiều tỉnh => Truy nhập qua Web). + Luôn có một "File list" (trên giấy, trên máy) được cập nhật thường xuyên và thông báo cho mọi người. - Tại sao phải tổ chức lưu trữ hồ sơ dự án. + Mất thời gian 1 lần, tiết kiệm thời gian nhiều lần. + Tạo điều kiện theo dõi dự án. + Tạo điều kiện thuận lợi cho cấp trên (hoặc nhà tài trợ) kiểm tra dự án. + Là cơ sở để lập các báo cáo. + Là chỗ dựa để Người quản lý dự án tự bảo vệ mình. + Chia sẻ thông tin trong tập thể thực hiện dự án. 9.2.6.1. Các biểu mẫu. Người quản lý dự án cần quy định một số biểu mẫu cho một số báo cáo, đề nghị, tờ trình, - Lưu ý: + Nên soạn biểu mẫu trên máy tính (chia xẻ và thông báo rộng rãi). 93
32. + Có hướng dẫn cách khai (ngắn gọn, rõ ràng). + Thiết kế thoáng, nhiều chỗ trống. + Chỉ yêu cầu viết đủ các thông tin cần thiết, tránh viết dài, thừa. + Biểu mẫu nên thiết kế sao cho dễ khai, mất ít thời gian để khai 9.2.6.2. Báo cáo Báo cáo: là một loại Biểu mẫu (Form), được thiết kế để cấp dưới báo cáo lên cấp trên. Form cho báo cáo được thiết kế đa dạng, phong phú (lời văn, hình vẽ, bảng biểu, ). Cố gắng sao cho báo cáo có thể tạo ra trên máy tính. 9.2.6.3. Các biên bản: - Là một loại tài liệu không thể thiếu. - Là một dạng ghi lại những thống nhất, cam kết. - Theo dõi và quản lý các cuộc họp và các sự kiện của dự án. - Lưu ý: + Biên bản cần cụ thể, rõ ràng, tránh sơ sài. + Nói trực tiếp vấn đề, ngắn gọn (1- 2 trang) + Cấu trúc logic, hợp lý. + Nên tập trung vào những điểm đã thỏa thuận, thống nhất. 9.2.7. Văn phòng dự án. - Trung tâm chỉ huy và kiểm soát của dự án. Phần lớn các hoạt động và quyết định quản lí dự án chính đều xuất hiện tại văn phòng dự án. - Nơi cung cấp các tài nguyên dự án. - Nơi tổ chức các cuộc họp quan trọng. - Nơi làm việc chính thức của Ban quản lý dự án. - Lưu ý: + Dự án càng lớn => Văn phòng dự án càng lớn. + Nên lập Văn phòng dự án càng sớm càng tốt. + Văn phòng dự án cần có. + Phần mềm quản lí dự án tự động. 94
33. + Văn kiện dự án. + Hồ sơ quản lý dự án. + Thư viện dự án. + Trên tường của Văn phòng dự án phải treo các bảng phóng to. + Các sơ đồ thanh (Gantt). + Sơ đồ tổ chức. + Các bản đồ. + Bảng tiến độ công việc. + Các nội dung quan trọng khác. 9.2.8. Quản lí hợp đồng Tiến trình làm hợp đồng là như sau: - Dự án xác định rõ chỗ nào đòi hỏi việc xây dựng do bên ngoài thực hiện. - Nhận diện người kí hợp đồng có khả năng làm khoán ngoài. Kí kết các phát biểu được giữ bí mật và gửi bản chào thầu Request for Quote (RFQ) cho từng nhà cung cấp có thể. - Phân tích kết quả RFQ, và chọn ra người cung cấp tuân thủ theo chính sách, trách nhiệm công việc thường được thực hiện và xác nhận vào lúc này. - Xây dựng bản hợp đồng với nhà cung cấp được chọn, và xây dựng Phát biểu công việc ban đầu có cả các cột mốc và tiêu chí chấp nhận. - Xác định các trông đợi giao hàng của nhà cung cấp (đặc tả chức năng, kết quả kiểm thử đơn vị, etc ). - Điều phối tiến độ và việc phát triển bởi người quản lí dự án và người quản lí phát triển. - Kiểm thử các sản phẩm công việc đã chuyển giao rồi chấp nhận hay đệ trình lại để sửa chữa hay gỡ lỗi. - Sản phẩm công việc phần mềm được chấp thuận dựa trên điều khoản của hợp đồng và bản phát biểu về công việc SOW. - Dự án đi vào phần bảo trì như đặc tả của bản thoả thuận. 9.2.9. Quản lí nhà cung cấp 95
34. - Người quản lí nhà cung cấp (VM) sẽ được chỉ định trong bản kế hoạch dự án cho từng nhà cung cấp đã có hợp đồng làm việc với dự án. Thông thường đó chính người quản lí dự án hay người quản lí phát triển của dự án đặc biệt. - Người quản lí nhà cung cấp phải có các thủ tục tại chỗ để đánh giá mức độ hiệu năng và chất lượng của nhà cung cấp trong cả thời hạn dự án Hiệu năng của nhà cung cấp nên được lập kế hoạch và theo dõi trong tất cả các pha của vòng đời phát triển dự án. - Lập kế hoạch nhà cung cấp và báo cáo trạng thái + Họp và kiểm điểm nhà cung cấp + Kiểm điểm sản phẩm công việc của nhà cung cấp + Kiểm soát thay đổi nhà cung cấp + Quản lí cấu hình phần mềm nhà cung cấp + Đảm bảo chất lượng phần mềm nhà cung cấp - Kế hoạch của nhà cung cấp và báo cáo trạng thái + Người quản lí nhà cung cấp phải đảm bảo rằng thủ tục lập kế hoạch dự án của nhà cung cấp tuân thủ phương pháp phát triển ứng dụng phần mềm của tổ chức ( SDM ). + Bản kế hoạch của nhà cung cấp phải bao gồm: * Chỉ báo hiệu năng (kích cỡ, chi phí, nguồn lực máy tính) * Lịch biểu (đường găng và các thành tựu cột mốc) * Các hoạt động kĩ thuật * Thẩm định rủi ro liên kết với chi phíe, nguồn lực, lịch biểu * Tuân thủ an ninh + Người quản lí nhà cung cấp phải đảm bảo rằng nhà cung cấp gửi báo cáo trạng thái thường kì (theo tuần, tháng). + Họp và kiểm điểm nhà cung cấp + Họp về trạng thái + Cuộc họp khởi động cho tất cả các thành viên tổ để xem xét về bản kế hoạch dự án, vai trò và trách nhiệm, thủ tục, kế hoạch của nhà cung cấp. 96
35. + Kiểm điểm các yêu cầu phần mềm với tổ dự án, cộng đồng doanh nghiệp/người dùng, và nhà cung cấp. + Các cuộc họp về trạng thái diễn ra tiếp sau đó được tổ chức để thảo luận các vấn đề, mối quan tâm, trạng thái các hoạt động, việc cần làm. + Xem như một hướng dẫn, cuộc họp kiểm điểm nhà cung cấp phải được tổ chức sau khi hoàn thành: * Pha lập kế hoạch * Pha xây dựng (phát triển) * Pha ổn định hoá (kiểm thử) * Pha trình diễn / Đánh giá (kiểm thử chấp nhận của người dùng) + Họp kiểm điểm tính sẵn sàng bàn giao của nhà cung cấp nên được tổ chức trước mọi việc bàn giao sang kiểm thử tích hợp hay sản phẩm. + Thủ tục và tiêu chuẩn chấp nhận được xác định cho phần mềm và sản phẩm công việc không là phần mềm: * Bản ghi nhớ bàn giao của nhà cung cấp * Kết quả kiểm thử của nhà cung cấp * Mã nguồn theo Quản lí cấu hình (CM) * Tài liệu người dùng + Người quản lí nhà cung cấp đưa ra chữ kí chấp nhận để chỉ ra việc hoàn thành thoả đáng. * Hiệu năng của nhà cung cấp được đánh giá theo tiêu chí đánh giá được xác định trong thoả thuận hợp đồng. 9.3. KIỂM SOÁT DỰ ÁN. 9.3.1. Các yếu tố làm ảnh hưởng đến năng suất và chất lượng phần mềm - Năng lực cá nhân: Năng khiếu, lòng yêu nghề, tính sáng tạo, tính cần cù - Kỹ năng trao đổi trong tổ, nhóm - Nói một cách thuyết phục: Mình nói người khác hiểu, người khác nói mình hiểu. 97
36. - Độ phức tạp của phần mềm: Nhiều dòng lệnh, thuật toán phức tạp, nhiều module, phụ thuộc vào nghiệp vụ phức tạp hay đơn giản. - Cách tiếp cận hệ thống. - Thời gian được phép. + Nếu thời gian căng thẳng quá => phần mềm bị làm gấp sẽ nhiều lỗi. + Khả năng hiểu thấu vấn đề, hiểu nghiệp vụ, hiểu công cụ lập trình. + Độ ổn định của các yêu cầu. - Kỹ năng đáp ứng những công nghệ mới: Công nghệ client/server, công nghệ Web + Môi trường làm việc, công cụ. + Sự đào tạo, huấn luyện của tổ chức. - Kỹ năng quản lý các rủi ro xảy ra. - Những hạn chế của một lập trình viên mới. + Khả năng diễn đạt vấn đề. + Hiểu nghiệp vụ của những lĩnh vực ứng dụng. + Chưa có ý thức về việc bảo hành, bảo trì phần mềm. + Làm việc trong một khuôn khổ, bài bản của quản lý dự án. + Làm việc trong nhóm. 9.3.2. Thu thập, đánh giá hiện trạng Thu thập hiện trạng là: Dùng mọi phương sách để xác định xem các công việc (nói riêng) và toàn bộ dự án (nói chung) hiện nay đang tiến triển thế nào. Các bước: - Bước 1: Thu thập các dữ liệu về hiện trạng theo định kỳ (1 hoặc hai tuần). Công bố cho anh em biết. - Bước 2: Thu thập dữ liệu hiện trạng từ mọi thành viên của tổ dự án. Tránh đưa ra đánh giá (vội vã) khi thu thập dữ liệu. (Cần phân tích kỹ lưỡng) - Bước 3: Làm tài liệu tổng hợp (tốt nhất là tổng hợp từ các tài liệu, báo cáo điện tử) - Bước 4: Mục đích cuối cùng của đánh giá: + Làm rõ sự khác biệt giữa dự kiến và thực tế khác biệt có thể là xấu hoặc tốt. 98
37. + Sai biệt lịch biểu = Ngày bắt đầu và kết thúc theo kế hoạch. + Sai biệt ngân sách Sai biệt chi phí = Chi phí ngân sách - Chi phí thực tế - Bước 5: Nhiệm vụ của người quản lý dự án là phải trả lời các câu hỏi: + Tại sao có sự khác biệt? + Sự khác biệt là tốt hay xấu? + Có cần những hành động uốn nắn, điều chỉnh dự án hay không? + Nếu có, thì là gì? 9.3.3. Lập kế hoạch phòng ngừa rủi ro - Dựa trên phân tích rủi ro, lập biểu sau: Mô tả Giả thiết Xác suất Ảnh hưởng Phản ứng (1) (2) (3) (4) (5) 1- Mô tả: Xác định vấn đề (rủi ro) 2- Giả thiết: Hoàn cảnh có thể làm xuất hiện rủi ro 3- Xác suất: Ước lượng khả năng xuất hiện (%) 4- Đánh giá ảnh hưởng đối với dự án 5- Cách giải quyết (đối sách) - Cần liệt kê tất cả các giả thiết ảnh hưởng tới quyết định cách giải quyết. Nếu sau này hoàn cảnh không còn hợp với các giả thiết nữa, có thể thay đổi đối sách. - Cần được sự ủng hộ của những người chịu tác động của rủi ro. - Với những "sự cố" đã xẩy ra mà không dự kiến được, cần ghi lại nhật ký Mô tả Độ quan trọng Người chịu trách nhiệm Ngày giải quyết [1] [2] [3] [4] 1- Mô tả, thuật lại sự cố 2- Tầm quan trọng của sự cố. 3- Tên người giải quyết sự cố. 99
38. 4- Thời gian vấn đề đã được hay sẽ được giải quyết. 9.3.4. Kiểm soát tài liệu dự án - Ý nghĩa của kiểm soát tài liệu + Tài liệu là sản phẩm. Phần mềm chỉ được hiểu qua tài liệu. + Tài liệu cũng là công cụ làm việc. + Mỗi tài liệu thuộc một loại nào đó, nhằm mục đích sử dụng nào đó: đặc tả yêu cầu, đặc tả thiết kế, báo cáo công việc, báo cáo sự cố/rủi ro, báo cáo tài chính, + Viết tài liệu cũng khó như viết văn. + Trong thực tế: Tài liệu là khâu thường bị bôi bác + Không chuyển sang công việc tiếp sau, nếu tài liệu không sát thực, đầy đủ, dễ hiểu, nhất quán Kết luận: làm tài liệu tốt trong quá trình thực hiện dự án là vấn đề khó - Các tiêu chuẩn xem xét, đánh giá tài liệu + Tính chính xác * Tài liệu viết có chính xác không? * Có lỗi nào hiển nhiên không? * Các mô tả về tài nguyên, môi trường của hệ thống có hợp lý không? v.v + Tính rõ ràng * Tài liệu có được trình bày sáng sủa, dễ hiểu không? * Những chỗ cần dùng bảng hoặc biểu đồ thay lời nói thì có dùng hay không? + Tính đầy đủ * Những thông tin trong tài liệu có phù hợp với mục đích tài liệu không? * Có những điểm nào quan trọng bị bỏ sót không? * Trong trường hợp một tài liệu là phát triển tiếp tục của một tài liệu khác, những điểm cần thiết của tài liệu trước có được nhắc lại hay không? + Tính nhất quán * Cách đánh số các chương, mục, điều khoản trong tài liệu có nhất quán không? * Các ký hiệu có thống nhất không? Hoặc có theo chuẩn không? 100
39. + Mức độ chi tiết * Đủ chi tiết như mục đích và yêu cầu của tài liệu không? * Liệu có phần nào cần hoàn thiện chi tiết hơn nữa không? - Một số tài liệu chính cần có khi thực hiện vòng đời của dự án + Xác định, phân tích yêu cầu Bao gồm a/ Mô tả khái lược về hệ thống (sâu hơn tài liệu mô tả dự án) b/ Tài liệu về yêu cầu và đặc tả c/ Tài liệu về kế hoạch phát triển phần mềm Chú ý: Phải đảm bảo những nội dung sau: - Nhu cầu của khách hàng được diễn đạt theo một cách thức rõ ràng, chi tiết, mô tả hệ thống phải làm gì. - Phải làm việc với các chuyên gia trong lĩnh vực chuyên môn để hiểu được các khái niệm nghề nghiệp, hoạt động nghiệp vụ - Nên tận dụng những phần mềm mà khách hàng trước đây đã sử dụng (nếu có). Xem xét và thảo luận trên những phần mềm đó (về ưu/khuyết của các modules, về quan điểm thiết kế, ) - Mô tả những loại dữ liệu vào, ra - Các tài liệu trên khi được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp. 9.3.5. Các hoạt động điều chỉnh Khi việc thực hiện dự án không diễn ra theo kế hoạch, hoặc chất lượng sản phẩm/công việc chưa đạt yêu cầu - Điều chỉnh lại lịch biểu thời gian cho chính xác hơn. - Tìm thêm nhân viên mới. Chú ý: Thời gian làm quen với dự án, quan hệ với các thành viên cũ, kinh phí phát sinh) - Mua hay thuê thiết bị tốt hơn, phần mềm tốt hơn. Chú ý: tăng kinh phí, mất thời gian để anh em học sử dụng. - Hợp lý hoá, cải tiến phong cách làm việc. 101
40. - Hạ thấp yêu cầu chất lượng công việc (không nên !!!) -Tập trung cho các công việc trên đường găng. - Làm thêm giờ (không nên kéo dài quá lâu) - Hạn chế nghỉ phép (coi chừng phản ứng của tổ viên!!!) - Khen thưởng/phê bình. - Đào tạo, huấn luyện, nâng cấp nhân viên (chú ý thời gian và chi phí huấn luyện). - Xem lại cách thức hợp tác, trao đổi thông tin trong nhóm. 9.3.6. Khi chi phí cho dự án có nguy cơ tăng lên - Hạ thấp yêu cầu sản phẩm (Chú ý: khách hàng có thể phản đối). - Giảm nhân viên: những người không làm các công việc trên đường găng (chú ý: nguy cơ mất người giỏi). - Thuê lao động rẻ (nguy cơ "tiền nào của nấy!!!). - Dùng thiết bị, vật tư rẻ tiền. - Rút bớt thời gian huấn luyện (chú ý phản ứng tâm lý của tổ viên). - Xem lại: Có cần làm thêm giờ? - Hợp lí hoá hơn nữa: Giảm số cuộc họp, giảm các phê chuẩn, 9.3.7. Khi chất lượng công việc/sản phẩm có nguy cơ giảm - Tăng cường kiểm tra chất lượng sản phẩm - Thuê thêm tư vấn - Tập trung vào những khâu trọng yếu ảnh hưởng đến chất lượng sản phẩm - Kiểm tra chéo - Huấn luyện, đào tạo, nâng cấp nhân viên (có thể huấn luyện tại chỗ - trainingon-job) - Thưỏng/phạt 9.3.7. Kiểm soát thay đổi Thực tế cho thấy: Kế hoạch và thực tế không bao giờ giống nhau. - Ai gây ra/đề nghị những thay đổi + Khách hàng + Các cơ quan/đơn vị liên quan 102
41. + Tổ dự án + Người tài trợ + Chính người quản lý dự án + v.v - Phân loại thay đổi: 3 loại + Thay đổi quan trọng: Lịch biểu, đặc tính sản phẩm, ngân sách, và những gì được xem là quan trọng cho dự án. Làm thay đổi cơ bản kết quả của dự án. Ví dụ: Nhà tài trợ tuyên bố cắt giảm ngân sách (gây ra bởi người tài trợ) Yêu cầu bổ sung thêm một số tính năng của phần mềm (gây ra bởi khách hàng) + Thay đổi nhỏ: Không làm thay đổi kết quả chung cuộc của dự án, nhưng có thể ảnh hưởng đến sự thành công của dự án. Ví dụ: Dự án xây nhà: Những phát sinh lặt vặt (từ phía chủ nhà - khách hàng) Dự án làm phần mềm: Yêu cầu làm thêm một vài module lập báo cáo (khách hàng đề nghị) + Thay đổi mang tính sửa chữa/sửa lỗi: Đã coi nhẹ hoặc bỏ qua 1 điểm nào đó, bây giờ phải bổ sung hoặc khắc phục Ví dụ: Dự án xây nhà: Quên chưa đi dây điện thoại ngầm trong tường, cần phải lắp thêm hệ thống dây điện nổi (do người quản lý dự án hoặc tổ dự án đề nghị) Dự án xây dựng phần mềm: Quên chưa lên kế hoạch huấn luyện cho người sử dụng trước khi bàn giao (do khách hàng phát hiện ra) 9.3.8. Xem xét tác động của thay đổi - Ảnh hưởng tới công việc, thời gian. - Ảnh hưởng tới kinh phí. - Ảnh hưởng tới con người: Phải làm thêm việc => phản ứng tiêu cực - Ảnh hưởng tới chất lượng sản phẩm của dự án. 9.3.9. Xét xem thay đổi nào cần ưu tiên thực hiện trước - Lập danh sách những thay đổi - Xác định mức độ ưu tiên: cao, thấp, rất thấp, không cần phải thay đổi 103
42. - Từ đó có kế hoạch đáp ứng: người, thời gian, tiền, 9.4. KẾT THÚC DỰ ÁN. Một dự án phải kết thúc, sớm hay muộn tùy thuộc các lí do kết thúc dự án như sau: - Đã hoàn thành các yêu cầu - Chưa hoàn thành các yêu cầu, nhưng có các yếu tố sau: + Kinh phí đã hết, không thể cấp thêm. + Thời hạn đã hết, không cho phép gia hạn thêm. + Ban Quản lý và nhà tài trợ quyết định chấm dứt. + Những lý do đặc biệt khác Trước kết thúc dự án, cần làm 1 số công việc dưới đây: 9.4.1. Thống kê lại dữ liệu Thống kê lại các số liệu "lịch sử" về chi phí, thời gian thực hiện, chất lượng công việc, chất lượng sản phẩm. - So sánh giữa kế hoạch và thực tế - Tìm nguyên nhân (kể cả trong trường hợp mọi sự là hoàn hảo) 9.4.2. Rút bài học kinh nghiệm - Gợi ý về một dàn bài - Gợi ý 1 dàn bài I. Giới thiệu chung về dự án A. Mục đích B. Phạm vi II. Tình hình/hiện trạng trước khi thực hiện dự án III. Tóm tắt nội dung công việc của dự án IV. Những điểm đã đạt được/thành công A. Các thành công B. Thảo luận về từng thành công V. Các vấn đề gặp phải trong khi thực hiện dự án A. Thảo luận về từng vấn đề B. Cách khắc phục vấn đề 104
43. VI. Cơ hội cho công việc tương lai - Các nguồn tài liệu tham khảo để viết tài liệu + Yêu cầu kiểm soát thay đổi + Bản ghi chi phí + Phỏng vấn với các thành viên tổ, Ban lãnh đạo và khách hàng + Biên bản các cuộc họp + Lịch biểu thời gian + Phác thảo dự án và những sửa đổi + Tài liệu thống kê - Thời gian tốt nhất để viết tài liệu: liệu này: cuối dự án hoặc hay ngay sau khi dự án kết thúc. Càng để muộn càng không hay. - Tài liệu này là không có lợi khi nào? + Người quản lý dự án không đủ trình độ, không đủ thông tin => viết ra một tài liệu không chính xác. + Mục đích chính trị của tài liệu: Tài liệu không phản ảnh sự thật, hoặc để công kích người khác + Không phổ biến cho ai, hoặc không cho ai đọc 9.4.3. Kiểm điểm sau khi bàn giao - Mục đích: Khảo sát năng suất phục vụ của sản phẩm và các hoạt động duy trì, bảo trì, hỗ trợ khách hàng. + Xác định xem mục đích và mục tiêu của dự án có đạt được không? + Khẳng định sản phẩm có đáp ứng nhu cầu của khách hàng không? + Đánh giá ích lợi thực sự của sản phẩm? + Khách hàng có thực sự thoả mãn? + Thảo luận sự hỗ trợ tiếp tục - Các lưu ý khi họp kiểm điểm + Mời tư vấn độc lập + Khoanh vùng những nội dung cần họp bàn, tránh đi lan man, cãi vã + Cần khoảng 3-6 tháng chuẩn bị cho cuộc họp (tuỳ độ lớn của dự án) 105
44. + Tổng kết những điểm mới (sáng kiến, kinh nghiệm, ) trong dự án 9.4.4. Đóng dự án Trong giai đoạn cuối của dự án, trước khi kết thúc, nên làm một số việc: - Giảm bớt người, phân công lại công việc - Xác nhận và công bố những cá nhân/đơn vị đã làm tốt (động viên tinh thần, hoặc kèm theo vật chất - dù nhiều/ít) Lấy xác nhận từ phía khách hàng (một cách để người quản lý dự án tự bảo vệ mình) 106
45. TÀI LIỆU THAM KHẢO [1] Nguyễn Văn Ba, Bài giảng môn Phân tích và thiết kế hệ thông tin, Khoa CNTT, ĐHBK Hà nội. [2] Ngô Trung Việt, Phân tích và Thiết kế tin học hệ thống Quản lý - Kinh doanh - Nghiệp vụ; 1995, Nhà xuất bản giao thông vận tải. [3] Benjamin S.Blanchard Wolter J.Fabrycky, System Engineering and Analysis, 1990, Pren-Hall, Australia. [4] Judson R.Ostle, Infornation systems Analysis and Design 1985, Burgess Communications, USA. [5] Roger S. Pressman, Ph.D, Soffware Engineering Kỹ nghệ phần mềm tập một. Bản dịch của Ngô Trung Việt,1997, Nhà xuất bản giáo dục. [6] Phân tích, thiết kế cài đặt hệ thông tin quản lý, Biên soạn: Chris Smart, Robin Sims, Đoàn Văn Ban, Ngô Trung Việt, Đặng Văn Hưng, Trần Thị Phiếm, Phạm Ngọc Khôi, thuộc viện Tin học,1990. [7] Sandra Donaldson Dewitz, System Analysis and Design and the Transition to objects, 1996, Mc Graw - Hill International Editions. [8] I.T Hawryszkiewycz Introduction to system Analysis and Design, second Edition, 1991, Printice Hall of Australia Pty.Ptd. [9] Donal J.Flynn Olivia Fragoso diaz, Infornation Modelling and International perspective,1996, Prentice Hall. [10] Trần Thành Trai, Phân tích và thiết kế hệ thống thông tin quản lý. Nhà xuất bản trẻ. [11] Lê Tiến Vương, Nhập môn cơ sở dữ liệu, 1994, Nhà xuất bản khoa học và kỹ thuật. [12] Mailir Page-Jones, The Practical Giude to Structured Systems Design, 1988, Prentice Hall Building, Engiewood Clliffs, New Jersey 07632. [13] Richard Barker, Case*Method Entity Relationship Modelling, 1990,, Addition-Wesley Publishing Company, ORACLE Corporation UK Limited. [14] Richard Barker Cliff Longman, Case*Method Function and Process Modelling, 1992, Addition-Wesley Publishing Company, ORACLE Corporation UK Limited. 1
46. [15] A.Collongues J. Hugues B.Laroche, MERISE, Phưong pháp thiết kế hệ thống thông tin tin học hóa phục vụ quản lý doanh nghiệp, Dịch giả : Trương Văn Tú, Nhà xuất bản khoa học kỹ thuật, 1994 2
47. THUẬT NGỮ SỬ DỤNG English Vietnamese A Abstract Trừu tượng, tóm lược Accommodate Điều tiết, làm cho phù hợp Accuracy Đúng đắn, chính xác Acti-gram Sơ đồ hoạt động Activate Kích hoạt Activate mechanism Cơ chế kích hoạt Activity chart Lược đồ hoạt động Ad - hoc Không thể thức, đặc biệt Adaptability Tính thích nghi, thích ứng Adaptation Thích nghi, thích ứng Adaptive maintenance Bảo trì thích nghi Add-on Phụ thêm Adjusted productivity value Giá trị hiệu năng được điều chỉnh Algorithm Giải thuật Alias Biệt hiệu, bí danh, tên phụ Allocation Cấp phát, phân phối Alternative Phương án khác, lựa chọn, phụ Analysis Phân tích Application context Ngữ cảnh áp dụng Architecture context diagram Biểu đồ ngữ cảnh kiến trúc Architecture design Thiết kế kiến trúc Architecture dictionary Từ điển kiến trúc Architecture flow diagram Biểu đồ kết nối kiến trúc Architecture interconnection diagram Biểu đồ liên nối kiến trúc Architecture template Tiêu bản/khuôn mẫu kiến trúc Archive Lưu trữ Argument đối Arithmetic-logic unit Bộ số học-logic 3
48. Artifact Tạo tác, mẫu Assembler Hợp ngữ Assembly line diagram Biểu đồ đường lắp ráp Assembly structure Cấu trúc lắp ghép Assign Gán Associative data object Đối tượng dữ liệu kết hợp Attribute Thuộc tính Audit Kiểm toán Available Có sẵn, sẵn dùng B Background Hậu cảnh, nền, ngầm Background processing Xử lý hậu cảnh, ngầm Backup Sao lưu Balance Cân bằng Bar chart Sơ đồ thanh Bar code Mã vạch Baseline Vạch ranh giới, đường cơ sở Batch processing Xử lý theo lô Behavior Hành vi Behavious modeling Mô hình hoá hành vi Benchmark Tiêu chuẩn Black box testing Kiểm thử hộp đen Boundary Biên Boundary time Thời gian biên Breakpoint Điểm đứt, gián đoạn Bubble chart Lược đồ hình tròn Budget Ngân sách Buffer Bộ đệm C Concurrence Tương tranh, đồng thời 4
49. Configuration Cấu hình Conic Hình nón Composite data item Khoản mục dữ liệu hợp thành (phức hợp) Composition object Đối tượng hợp thành Computer system engineering Công nghệ hệ thống máy tính CASE (Computer Aided Software Engineering) Công nghệ phần mềm với máy tính hỗ trợ Case Study Ví dụ lớn minh hoạ Characteristic Đặc trưng, đặc tính Chart Lược đồ Checklist Danh sách kiểm tra Class diagram Biểu đồ lớp Classification Phân lớp Clean room Phòng sạch Closely couple Gắn chặt Closely Couple Kết nối chặt Closely couple Kết nối chặt Code generator Bộ sinh mã (chương trình,) Coding Mã hoá Coercion Bó buộc Cohesion Cố kết Coincidentally Trùng khớp ngẫu nhiên Combination Tổ hợp Combined entity diagram Biểu đồ thực thể được tổ hợp Communication Truyền thông Compatibility Tính tương hợp, tương thích Compilation, Compile, Compiler Biên dịch, Chuơng trình dịch Complexity adjustment value Giá trị điều chỉnh độ phức tạp Component Thành phần, cấu phần Connectivity Tính nối được, tính liên thông 5
50. Con-routine Trình tương tranh Consistence Nhất quán Constitute Cấu thành, hợp thành, thiết lập Constraint Ràng buộc, điều kiện Construct Kết cấu, xây dựng Context Ngữ cảnh Context model Mô hình Ngữ cảnh Context switching Chuyển Ngữ cảnh Contractor Nhà thầu Control điều khiển, kiểm soát Control flow diagram Biểu đồ luồng điều khiển Control hierarchy Phân cấp điều khiển Control process Tiến trình điều khiển Control specification Đặc tả điều khiển Control unit Bộ điều khiển Conveyer Băng truyền Coordinate Phối hợp Core Lõi Co-routine Trình tương hỗ Corrective maintenance Bảo trì hiệu chỉnh Correctness Tính đúng đắn Cost Chi phí, giá Cost-benefit analysis Phân tích chi phí-lợi ích Couple Dính nối, gắn kết Coupling Kết nối Crisis Khủng hoảng Critical path method Phương pháp đường găng Cross stimulate Kích thích chéo Cyclomatic Xoay vòng D Data condition Điều kiện dữ liệu 6
51. Data flow diagram Biểu đồ dòng dữ liệu Data flow graph đồ thị dòng dữ liệu Data modeling Mô hình hoá dữ liệu Data object Đối tượng dữ liệu Data store Kho dữ liệu Data structure Cấu trúc dữ liệu Data transfer rate Tỉ lệ truyền dữ liệu Data typing Định kiểu dữ liệu Database Cơ sở dữ liệu Database engineering Kỹ nghệ cơ sở dữ liệu Datagram Bức dữ liệu Data-object-type hierarchy Phân Cấp dữ liệu - Đối tượng kiểu Datum Dữ liệu Debate Tranh luận Debug Gỡ rối Declaration Khai báo Decomposition Phân rã Defect Khiếm khuyết Dependable Tính tin cậy Deployment Triển khai Depth Độ sâu Design Thiết kế Design model Mô hình thiết kế Design specification Đặc tả thiết kế Design walkthrough Xét duyệt thiết kế Detail design Thiết kế chi tiết Development plan Kế hoạch phát triển Development system Hệ thống phát triển Diagnostic analyzer Bộ phân tích chẩn đoán Diagram Biểu đồ Diagrammatic Văn phạm biểu đồ 7
52. Dimension Chiều, kích cỡ Direct Trực tiếp Dispatch branch Nhánh gửi Dispatch module Mo đun gửi Display Hiển thị Distributed system Hệ phân tán Document Tư liệu Driven Đi ra từ, rút ra Driver Điều khiển Dynamic multi-variable model Mô hình đa biến động Dynamic single-variable model Mô hình đơn biến động E Economic feasibility Khả thi kinh tế Economic justification Luận chứng kinh tế Effort Công sức Effort Trách nhiệm Effort adjustment factor Nhân tố điều chỉnh công sức Elaboration Kỹ lưỡng, Chi tiết Embedded software Phần mềm nhúng Empirical estimation Ước lượng thực nghiệm Encapsulation Bao bọc Endeavors Nỗ lực mới Engineering Công nghệ Kỹ nghệ Enhancement Nâng cao Entity Thực thể Entity diagram Biểu đồ thực thể Entity-relationship diagram Biểu đồ thực thể- liên kết (ER) Enumeration type Kiểu kiệt kê Environment Môi trường Estimate Estimation ước lượng Estimation model Mô hình ước lượng 8
53. Estimation variable Biến ước lượng Event Sự kiện Event flow Luồng sự kiện Exception handling Khiển giải biệt lệ Expected value Giá trị kỳ vọng Expert system Hệ chuyên gia Explode Khai triển Exploration Khái thác Extensibility Tính mở rộng được External entity Tác nhân ngoài (Thực thể) F Facilitator Người điều khiển Factoring Lấy thừa số chung Failure S ai lỗi Fan- in Số modul vào, tản ra Fan-out Số modul ra, co cụm Fault tree analysis Phân tích cây thiếu sót Feasibility study Nghiên cứu khả thi Feature Tính năng Feature point Điểm chức năng Finalize Hoàn tất Flag Cờ Flexibility Tính mềm dẻo Flow Luồng Flowchart Lưu đồ Foreground Tiền cảnh Form Hình thái, hình dạng Formal specification đặc tả hình thức Facilitated application specification techniques(FAST) Kỹ thuật đặc tả ứng dụng thuận tiện 9
54. Formal technical review Họp xét duyệt kỹ thuật hình thức Fourth General Technology (4GT) Kỹ thuật thế hệ 4 Frame Khuôn khổ, khung Framework Cơ cấu Khuôn khổ công việc Framework Khung mẫu Fulfillment Hoàn chỉnh, Thực hiện Function Hàm, chức năng Functional decomposition Phân rã chức năng Functional point Điểm chức năng Functionality Tính chức năng Fundamental system model Mô hình hệ thống nền tảng G Generality Tính tổng quát Grammar Văn phạm H Handle Giải quyết Handler Điều giải Hardware Phần cứng Hardware requirement analysis Phân tích yêu cầu phần cứng Heuristic Trực cảm, mẹo Hierarchy Cấp bậc Home-machine interaction Tương tác người-máy Homologous đồng đẳng Host machine Máy chủ Human engineering Kỹ nghệ con người I Identification Căn cước Identifier Tên gọi, định danh , căn cước Identify Xác định, định danh Implementation Cài đặt 10
55. Implementation description Mô tả cài đặt Implode Hợp triển Incoming flow Luồng đi vào Inconsistency Bất nhất Incremental Tăng lên, gia tăng Index Chỉ số Indicator Chỉ báo Indirect Gián tiếp Information flow Luồng thông tin Information society Xã hội thông tin Information structure Cấu trúc thông tin Inherent Cố hữu Inheritance Kế thừa Immature Chưa trưởng thành Input Cái vào, đầu vào Instance Thể nghiệm, thể hiện Instance connection Mối nối thể nghiệm Instantiation Việc lấy thể nghiệm Instruction Lệnh Integrate Tích hợp Integrate test Kiểm thử tích hợp Integrate testing Kiểm thử tích hợp Integrity Toàn vẹn Interactive Tương tác Interconnection description Mô tả liên nối Interface Giao diện Interoperability Tính liên tác Interpretation Thông dịch Interrelated Tương quan nhau Interrupt Ngắt Interrupt latency Trễ ngắt 11
56. Item Khoản mục K Knowledge Tri thức Knowledge database Cơ sở tri thức L Layer Tầng, lớp Legal feasibility khả thi pháp lý Level of abstraction Mức độ trừu tượng Life cycle Vòng đời Line of balance chart Biểu đồ cân bằng Linearity Tính tuyến tính Linguistic modular unit Đơn vị mô đun ngôn ngữ Link Móc nối, nối, mối nối Link weight Trọng số nối Linked list Danh sách móc nối List Danh sách LOC (Line Of Code) Số dòng mã lệnh Locality Tính cục bộ Logic manipulator Bộ thao tác logic Loosely couple Gắn lỏng M Machine cycle Chu trình máy Machine language Ngôn ngữ máy Macroscopic level Mức vĩ mô Mailbox Hộp thư Maintainability T ính bảo trì được Maintenance Bảo trì Maturity Trưởng thành, thuần thục Measure Việc đo Member Thành viên 12
57. Memory locking Khoá bộ nhớ Message Thông báo, Thông điệp Message path Đường thông báo Meta-model Siêu mô hình Meta-rule Siêu luật Method(s) Phương pháp, phương thức Metric Độ đo Micro-electronic Vi điện tử Milestone Cột mốc Mock-up Mô hình, market Mode Mốt. Chế độ Model checking tools Công cụ kiểm tra mô hình Modification Sửa đổi Modularbility , Module Tính mô đun, Mô đun Module diagram Biểu đồ mô đun Monitor Bộ điều phối, giám sát Multiple inheritance Kế thừa bội Multi-programming đa lập trình Multi-tasking đa nhiệm Multi-user Nhiều người dùng Mutual exclusion Loại trừ lẫn nhau N Narrative Lời thuật Network Mạng Neuron network Mạng nơ ron Node Đỉnh, nút Non-procedural Phi thủ tục Normalization rule Quy tắc chuẩn hoá O Object Đối tượng, sự vật 13
58. Object code Chương trình đích Object diagram Biểu đồ Đối tượng Objective Mục tiêu Object-oriented Hướng Đối tượng Obsolesce Lỗi thời Occurrence Sự xuất hiện Off - the - shelf Không lỗi thời Off-line Gián tuyến On-line T rực tuyến Operability Tính vận hành Operation Thao tác , tác vụ Organizational unit Đơn vị tổ chức Outgoing flow Luồng đi ra Output Cái ra, đầu ra Outsourcing Gia công/ khoán ngoài Out-souring Thoái hoá P Package Đóng gói Package body Thân bộ trình Paradigm Khuôn cảnh Parallel Song song Parallel computing Tính toán song song Parameter Tham biến Partition Phân hoạch Password Mật khẩu, mật hiệu Path Đường dẫn Perceptive maintenance Bảo trì hoàn thiện Performance Hiệu năng Performance criteria Tiêu chuẩn hiệu năng Performance test Kiểm thử hiệu năng Phase Pha 14
59. Planning Lập kế hoạch Polygon Đa giác Polymorphism Đa hình thái Portability Tính khả chuyển Pragmatic Thực dụng, thực hiện Precision Chính xác Preliminary design Thiết kế sơ bộ Preventive maintenance Bảo trì phòng ngừa Primary storage Bộ nhớ chính Problem space Không gian vấn đề Procedural abstraction Trừu tượng thủ tục Procedural language Ngôn ngữ thủ tục Process Quá trình, tiến trình Process activate table Bảng kích hoạt tiến trình Process activation table Bảng kích hoạt tiến trình Process diagram Biểu đồ xử lý Process identifier Bộ định danh tiến trình Processing Xử lý Processing narrative Lời thuật xử lý Processor Bộ xử lý Profile Sơ thảo Program design language Ngôn ngữ thiết kế chương trình Program structure Cấu trúc chương trình Programming language Ngôn ngữ lập trình Programming, coding Lập trình progress Tiến độ Project Dự án Proof checking tools Công cụ kiểm tra chứng minh Protocol Giao thức Protocol description Mô tả giao thức Prototype environment Môi trường làm bản mẫu 15
60. Prototyping Làm bản mẫu Pseudo-code Giả lệnh Pull-down menu Đơn kéo xuống Round-trip Khứ hồi Quality Chất lượng Quantity Số lượng Quasi formal Giả hình thức Query Truy vấn R Rayleigh-Norden curve Đường cong Rayleigh-Norden Real-time Thời gian thực Reclamation Tái chế Recover Dò lại Recursion, recursive Đệ quy Re-engineering Tái kỹ nghệ Reference Tham khảo Refinement Làm mịn Relation model Mô hình quan hệ Reliability Tính tin cậy được, độ tin cậy Repeat Lặp Repertoire, Repository Kho , Kho chứa Request for proposal (RFP) Yêu cầu về các đề nghị Requirement Yêu cầu Requirement analysis Phân tích yêu cầu Requirement dictionary Từ điển yêu cầu Requirement statement language Ngôn ngữ phát biểu yêu cầu Resolution Giải trình, độ phân giải, Resource model Mô hình tài nguyên Reusability Khả năng tái sử dụng Reusable Dùng lại, tái dụng Reverse engineering Kỹ nghệ ngược 16
61. Reverse reengineering tool Công cụ tái công nghệ ngược Risk analysis Phân tích rủi ro Rough merge Gộp thô S Scalar Vô hướng Scalar item Khoản mục vô hướng Scenario Kịch bản Schedule Lập lịch Schema Sơ đồ Schematic block diagram Biểu đồ khối sơ đồ Scope Phạm vi Scrap Manh mún Secondary storage Bộ nhớ phụ Security An toàn Selection Tuyển chọn Semantic Ngữ nghĩa Semaphore Cờ báo hiệu Send Truyền, gửi Sensitive test Kiểm thử nhạy cảm Sequential Tuần tự Sequential vector Vec tơ tuần tự Server Phục vụ Service Dịch vụ Serviceability Tính phục vụ được Simple Simplicity Đơn giản Simulation Mô phỏng Size Kích cỡ Software architecture Kiến trúc phần mềm Software configuration Cấu hình phần mềm Software engineer Kỹ sư phần mềm Software engineering (SE) Công nghệ phần mềm 17
62. Software project plan Kế hoạch dự án phần mềm Software requirement specification Đặc tả yêu cầu phần mềm Software safety An toàn phần mềm Software store Kho phần mềm Solution Giải pháp Solution space Không gian giải pháp Source code Chương trình gốc , nguồn Specification Đặc tả Specification environment Môi trường đặc tả Spine Chốt trục Spiral Xoắn ốc Spoilage Hỏng hóc Stage Giai đoạn stakeholder Người tham gia State Trạng thái State transition diagram Biểu đồ chuyển trạng thái Static multi-variable model Mô hình đa biến tĩnh Static single-variable model Mô hình đơn biến tĩnh Stepwise elaboration Làm kỹ lưỡng từng bước Stepwise refinement Làm mịn dần từng bước Store Ghi nhớ, lưu giữ, Kho Stress test Kiểm thử gay cấn Strong type Kiểu mạnh Structure chart Lược đồ cấu trúc Structure clash Va chạm cấu trúc Stub Cuống Sub-flow Luồng con Subordinate Thuộc cấp Substantiate Chứng minh Suite Loạt Super-ordinate Thượng cấp 18
63. Supplementary Phụ trợ, bù Supportability Tính hỗ trợ được Swap Tráo đổi Synergy Hoà hợp Syntax Cú pháp Synthetic Toàn thái System analysis Phân tích hệ thống System concept document Tài liệu quan niệm về hệ thống System image Hình ảnh hệ thống System module narrative Lời thuật mô đun hệ thống System perception Cảm nhận hệ thống System respond time Thời gian hệ thống đáp ứng System software Phần mềm hệ thống System specification đặc tả hệ thống System specification review Xét duyệt đặc tả hệ thống System state Trạng thái hệ thống System test Kiểm thử hệ thống T Tactics Chiến thuật Tangible Hữu hình, rõ ràng Target machine Máy đích Task analysis Phân tích nhiệm vụ Task network Mạng nhiệm vụ Technical feasibility khả thi kỹ thuật Technology Công nghệ, Kỹ nghệ Template Tiêu bản Test Kiểm thử Trace-ability Tính theo dõi được Trade-off Trả giá Time-out Thời gian chết Tool Công cụ 19
64. Test plan and procedure Bản kế hoạch và thủ tục kiểm thử Testability Tính kiểm thử được Threat Đe doạ Time scale Khoảng thời gian Time stamp Đóng dấu thời gian Transaction Giao tác Transform Biến đổi Transform center Trung tâm biến đổi Transform flow Luồng biến đổi Transition Chuyển dịch, Chuyển đổi, biến đổi Treatment Xử lý Trigger Kích hoạt , cá Type checking Kiểm tra kiểu Typeless Phi kiểu U Unit test Kiểm thử khối Update Cập nhật Usability Tính sử dụng được User Manuel Sổ tay người dùng User model Mô hình người dùng Use case Trường hợp sử dụng V Valid Hợp lệ Validation test Kiểm thử hợp lệ Variability Độ biến thiên Variant Biến thể Visibility Thấy được , trực quan Visual Trực quan Vocabulary Vốn từ W 20
65. walkthrough Xét duyệt Warehouse Nhà kho Warning Cảnh báo Waterfall model Mô hình thác nước Wayside Bó hẹp Weak type Kiểu yếu White box testing Kiểm thử hộp trắng Width Chiều rộng Work breakdown structure Cấu trúc phân chia công việc Workflow Dòng công việc Workforce Nhân lực Workplace Hiện trường 21