Kiểm soát dự án
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 Nói một cách thuyết phục ...
- 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
Nói một cách thuyết phục
- Độ 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 đòi hỏi của 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
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:
- 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
- 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)
- 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ử)
- 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.
Khác biệt không nhất thiết là tốt hay xấu (tuỳ từng trường hợp cụ thể)
Sai biệt lịch biểu = Ngày bắt đầu và kết thúc theo kế hoạch -
Ngày bắt đầu và kết thúc thực tại
Sai biệt ngân sách
Sai biệt chi phí = Chi phí ngân sách - Chi phí thực tế
- Nhiệm vụ của người quản lý dự án: trả lời 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ì?
- 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] |
- Mô tả: Xác định vấn đề (rủi ro)
- Giả thiết: Hoàn cảnh có thể làm xuất hiện rủi ro
- Xác suất: Ước lượng khả năng xuất hiện (%)
- Đánh giá ảnh hưởng đối với dự án
- 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] |
- Mô tả, thuật lại sự cố
- Tầm quan trọng của sự cố.
- Tên người giải quyết sự cố.
- Thời gian vấn đề đã được hay sẽ được giải quyết.
- Ý 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?
- 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 phi được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp
- Thiết kế
Tên tài liệu: Tài liệu thiết kế chi tiết, làm c sở cho lập trình
Chú ý: Phải đảm bảo những nội dung sau:
- Xác định kiến trúc của phần mềm sao cho phù hợp với đặc tả hệ thống
- Phân rã các yêu cầu thành các hệ thống con
- Chi tiết hoá kiến trúc phần mềm (làm mịn dần dần), cố gắng chi tiết tới mức gần như có thể lập trình được
- Thiết kế các sơ đồ theo chức năng hoặc định hướng theo đối tượng
- Mô tả mọi dữ liệu được nhập bởi người dùng, các kết quả cần cho (ví dụ: trên màn hình, trên máy in, ...)
- Thủ tục, quy trình vận hành phần mềm
- Mô tả từng đơn vị chưng trình: chức năng, thuật toán thực hiện, giao diện, dữ liệu vào, dữ liệu ra
- Tài liệu trên phải được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp
- Lập trình
a/ Tài liệu ngoài chương trình
Đặc biệt quan trọng khi
Phát triển những phần mềm lớn, thuộc những dự án lớn.
Phải xây dựng những phần mềm với sự tham gia của nhiều người. Sẽ xẩy ra trường hợp một người lập trình phải gỡ lỗi và đọc những đoạn chương trình của người khác viết. Thậm chí người này đã chuyển sang cơ quan khác.
- Việc viết tài liệu cho chương trình phi đủ rõ ràng để bảo trì chương trình
- Tài liệu cho chương trình không liên quan đến mã lệnh của chương trình.
- Nội dung chính: Mô tả chung chưng trình, mục đích chung của chưng trình, ai viết, viết khi nào, các thuật toán riêng có sử dụng, chương trình được thiết kế và phát triển cho những hệ thống nào, nguồn dữ liệu vào, những yêu cầu cần có đối với dữ liệu vào, format của dữ liệu vào, hình thức của kết quả đưa ra, v.v...
- Tài liệu cho chương trình còn bao gồm sơ đồ cấu trúc của chưng trình
b/ Tài liệu trong chương trình
Là một bài viết ngắn đặt ở đầu chương trình, dưới dạng comment. Bài viết này thường chứa những thông tin sau:
- Tên tác giả, tên nhiệm vụ, ngày giao nhiệm vụ, ngày phải hoàn thành
- Mô tả vấn đề cần giải quyết
- Cách tiếp cận để giải quyết vấn đề. Mô tả vắn tắt thuật toán, hoặc tên thuật toán nếu thuật toán đã quen thuộc đối với mọi người. Có thể chỉ ra tên tài liệu tham khảo liên quan đến thuật toán.
- Các yêu cầu khác đối với chương trình: ngôn ngữ sử dụng, chương trình dịch, nguồn của dữ liệu vào (vào bằng tay, đọc từ file,...)
- Các yêu cầu đối với chương trình còn chưa đáp ứng được, hoặc có thể cải tiến cho tốt hơn
- Các lỗi còn xuất hiện, chưa gỡ được
- v.v...
c/ Nội dung của chương trình
Những khía cạnh cần xem xét trong nội dung chương trình
- Cách đặt tên biến, tên hàm, tên lớp
- Định lề cho mỗi dòng lệnh
- Sự sáng sủa của chưng trình
- Giải thích cho chương trình (comment)
- Tổ chức chương trình
- Tính khả chuyển
Kinh nghiệm thực tế cho thấy rằng:
- Để phát triển và hoàn thiện một chương trình (đặc biệt là các chương trình lớn), lập trình viên mất 70% thời gian vào việc xem lại và cải tiến các đoạn chưng trình cũ, chỉ 30% thời gian dành cho việc viết mã lệnh mới.
- Ngoài ra, rất nhiều tình huống trong thực tế đòi hỏi người này phải đọc chương trình của người kia (để gỡ lỗi, hoặc để mở rộng thêm một số chức năng)
- Nhiều khi phải xem lại mã chương trình sau hàng tháng, hoặc hàng năm.
- Thông thường, lập trình viên làm việc dưới một sức ép về thời gian, do đó không quan tâm đến hậu quả của những đoạn mã lệnh sản sinh ra, miễn là chương trình chạy được.
- Kiểm thử và Chấp nhận phần mềm
Tên tài liệu: Tài liệu kiểm thử phần mềm
Kế hoạch và kịch bản kiểm thử (được viết dựa trên tài liệu về yêu cầu và đặc tả hệ thống)
- 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
- 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
- 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ẻ mạt (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, ...
- 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ỗ - training-on-job)
- Thưỏng/phạt
- Luật BROOKS
- Khi một dự án phần mềm đã bị trễ hạn, việc bổ sung thêm người (lập trình viên) chỉ làm cho dự án trễ thêm mà thôi.
- Nếu 1 ông thợ cày có thể cày 1 mẫu ruộng trong 3 ngày, 3 ông thợ cày có thể cày 1 mẫu ruộng trong .....
- Nếu 1 phụ nữ có thể sinh một đứa bé trong 9 tháng, 9 người phụ nữ có thể sinh một đứa bé trong ....
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
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)
- Sự khác nhau giữa rủi ro và thay đổi
Rủi ro: Tai hoạ, sự cố, biến cố đã được dự phòng, lường trước
Thay đổi: Chênh lệch so với kế hoạch đã được ghi trong tài liệu, đã được thống nhất, cam kết
- Làm thế nào để khỏi rơi vào phong cách quản lý bị động? => Cần phải biết cách kiểm soát các thay đổi.
Kiểm soát thay đổi là: phát hiện, phân tích, đánh giá và thực hiện những thay đổi liên quan đến mô tả sản phẩm, lịch biểu, ngân sách và yêu cầu chất lượng.
- 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
- 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
- Từ đó có kế hoạch đáp ứng: người, thời gian, tiền,...
- Thủ tục kiểm soát thay đổi
Do người quản lý dự án tự xây dựng cho dự án của mình. Ví dụ:
- Biểu mẫu kiểm soát, theo dõi thay đổi
Hoặc gọi là "Nhật ký kiểm soát thay đổi"
| Ngày tháng | Mô tả thay đổi | Phân tích tác động | Mức ưu tiên | Người khởi đầu | Người chịu trách nhiệm | Đồng ý? | Ngày hiệu lực |
| [1] | [2] | [3] | [4] | [5] | [6] | [7] | [8] |
- Đối với những dự án làm phần mềm, cần tập trung quản lý thay đổi các phiên bản phần mềm
- Có bao nhiêu phiên bản của sản phẩm
- Các phiên bản đó khác nhau thế nào
- Phiên bản nào của sản phẩm được cài đặt và ứng dụng ở chỗ nào
- Tài liệu nào đi với mỗi phiên bản
- Phần cứng nào cần cho mỗi phiên bản
- Phiên bản nhằm khắc phục lỗi gì
- Khi nào phải làm lại kế hoạch
- Phát hiện ra những lỗi lầm trong kế hoạch đang thực hiện
- Gặp những thay đổi quá lớn, nếu không làm lại kế hoạch thì không thể đi tiếp được
- Khi lập kế hoạch lại có thể phải cấu trúc lại một phần hay toàn bộ dự án => yêu cầu thời gian, kinh phí,...
- Làm lại kế hoạch, tức là có thể thay đổi lại tất cả những nội dung đã xây dựng: mục đích mục tiêu, mô tả sản phẩm, ước lượng thời gian, kinh phí, lịch biểu,....
- Cần tận dụng những kết quả, kinh nghiệm đã có trong lần lập kế hoạch trước => có 1 kế hoạch tốt hơn
- Xác định rõ những lý do, nguyên nhân phải lập lại kế hoạch
- Xác định rõ những thay đổi cần có trong kế hoạch mới (khác với kế hoạch cũ)
- Phải được sự đồng thuận của Ban Quản lý dự án, nhà tài trợ (có thể cả của khách hàng)
- Thời gian chi phí cho việc lập lại kế hoạch:
Nếu nhiều quá: ảnh hưởng đến tiến độ dự án
Nếu ít quá: => kế hoạch có thể sơ sài, tiềm ẩn những sai lầm
- Tránh phải lập lại kế hoạch nhiều lần
