Kỹ năng trao đổi trong tổ, nhóm
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
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
Nếu thời gian căng thẳng quá => phần mềm bị làm gấp sẽ nhiều lỗi
Những hạn chế của một lập trình viên mới
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:
- 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 25;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:
- 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ý
- Ý 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à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à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?
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?
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?
Đủ 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
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:
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
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.
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:
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
Kinh nghiệm thực tế cho thấy rằng:
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)
- Luật BROOKS
Thực tế cho thấy: kế hoạch và thực tế không bao giờ giống nhau.
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í 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)
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ị)
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.
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"
- Đố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
- Khi nào phải làm lại kế hoạch
- 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,....
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
