Hướng dẫn dự án Capstone/3
Đây là phần 3 của hướng dẫn cho dự án Capstone:
Trong dự án Capstone, người quản lí dự án (PM) phải giữ dấu vết về cách các thành viên tổ dành thời gian của họ cho dự án. Theo dõi thời gian là hoạt động quan trọng để giám sát trách nhiệm cá nhân với dự án. Việc ghi thời gian cho phép PM so sánh thời gian thực tế so với thời gian được lập kế hoạch của từng thành viên. PM phải tóm tắt thời gian hàng tuần cho từng thành viên và cho tổ để tìm ra tổ thực sự làm việc bao nhiêu thời gian trên dự án. Bằng việc làm điều đó, PM có thể nhận diện đóng góp của từng cá nhân cho công việc dự án trong từng pha. (Lưu ý: PM phải báo cáo tính toán thời gian cho giáo sư.)
Trước từng pha phát triển, PM phải chia sẻ thông tin với các thành viên tổ liên quan tới số giờ thực tế mà họ dành cho nhiệm vụ của họ. Dùng dữ liệu này, thành viên tổ có thể ước lượng số giờ họ sẽ cần để hoàn thành nhiệm vụ tiếp. PM phải phân công cho từng thành viên tổ một số nhiệm vụ để làm cũng như ngày hoàn thành được mong đợi. Điều quan trọng là phân công người dự phòng trong trường hợp một người không có khả năng hoàn thành nhiệm vụ tương ứng. Bắt đầu từng pha cũng là lúc chuyển vai trò và phân công cho nên mọi thành viên đều có cơ hội thực hiện những vai trò nào đó. (Lưu ý: Nhớ rằng vai trò tới cùng trách nhiệm và họ phải hoàn thành chúng.)
Tổ cũng phải định nghĩa tập các độ đo để đo tiến bộ của tổ, năng suất và tính hiệu quả. Với từng độ đo, tổ phải chỉ ra cách họ thu thập dữ liệu, ghi dữ liệu, và cách họ dùng những dữ liệu này để ra quyết định. Tập các độ đo phải bao gồm cách đo chất lượng sản phẩm (lỗi và tỉ lệ lỗi), trạng thái và tiến độ dự án (ước lượng kích cỡ và nỗ lực so với thực tế), chất lượng qui trình (khối lượng việc làm lại, cột mốc được thực hiện và bị lỡ). Tổ phải phát triển một danh sách các rủi ro vì chúng là đe doạ nghiêm trọng cho dự án như thiếu lịch biểu, thay đổi với dự án v.v. Với từng dự án, tổ phải cung cấp một mô tả, và khả năng có thể xuất hiện (thấp, vừa, cao), và chiến lược giảm thiểu rủi ro. Quản lí rủi ro là kĩ năng quan trọng mà tổ phải học. (Lưu ý: Rủi ro thông thường nhất trong dự án Capstone là thay đổi trong yêu cầu. Trong dự án khách hàng thường làm điều đó để xem cách tổ phản ứng. Tổ phải dự đoán những thay đổi này và có kế hoạch giải quyết nó.)
Một khi khách hàng chấp thuận đề nghị của tổ về phạm vi mới, tổ có thể bắt đầu dự án. Điều đầu tiên cần làm là sửa lại bản đặc tả yêu cầu phần mềm (SRS) với phạm vi đã được chấp thuận (Khử bỏ các yêu cầu ưu tiên thấp không cần thiết mà khách hàng đã đồng ý hay thêm yêu cầu mới mà khách hàng đã yêu cầu tổ đưa vào). Dự án Capstone bắt đầu với SRS mới làm cơ sở cho mọi hoạt động dự án. Tổ cũng phải sửa lại và hiệu chỉnh các biểu đồ trường hợp sử dụng use case và lời dẫn mà họ đã làm trước đó và rót đầy những chi tiết còn thiếu và chỉ ra mọi tiền điều kiện, hậu điều kiện và các bộ lẩy cò cho từng use case.
Để nhận diện mọi nhiệm vụ phải được hoàn thành cho từng pha, tổ phải phân rã công việc dự án thành một số các nhiệm vụ và phân công chúng cho từng thành viên. Từ những nhiệm vụ này, thành viên tổ có thể ước lượng nỗ lực của họ (cần bao lâu để hoàn thành chúng) và tổ hợp vào lịch dự án tổng thể. Vì không phải mọi nhiệm vụ đều có thể được làm cùng lúc, một số nhiệm vụ phụ thuộc vào cái ra từ các nhiệm vụ khác, tổ phải nhận diện sự phụ thuộc giữa các nhiệm vụ và xây dựng trình tự có thứ tự các hoạt động thực hiện nhiệm vụ. (Lưu ý: Đây là bài tập lặp, tổ không nên tìm sự hoàn hảo mà chỉ cần biết từng nhiệm vụ trong đủ chi tiết để cho PM có thể theo dõi và báo cáo về tiến độ của họ.)
Việc phân rã công việc (cấu trúc phân việc) thường phụ thuộc vào phương pháp mà tổ dùng nhưng tổ phải thực tế về việc xác định các nhiệm vụ này. Chẳng hạn một nhiệm vụ lớn như “Phân tích vấn đề” hay “Thiết kế chức năng” là không thực tế vì nó không đủ chi tiết cho ước lượng hay theo dõi. Chia thành nhiệm vụ quá nhỏ có thể thành phân mảnh quá cũng không có ích. Cách tốt nhất là cân nhắc một nhiệm vụ như cái gì đó có thể hoàn thành trong vòng 32 giờ (Man-week) là cách tốt nhất để xác định một nhiệm vụ, vì nó dễ cho theo dõi và đo. Khi làm việc về lịch biểu toàn thể, tổ cũng phải xem xét các nhiệm vụ liên quan tới các hoạt động hỗ trợ như SQA, SCM, quản lí thay đổi cũng như bao gồm mọi nhiệm vụ liên quan tới việc học công nghệ mới, quản trị máy phục vụ, công cụ mới v.v.. Những nhiệm vụ hỗ trợ này thường bị quên mất hay không được tính tới trong lịch biểu toàn thể và đó là lí do tại sao nhiều dự án phần mềm bị chậm, lỡ lịch và chúng bị ước lượng thấp.
Khi phân rã được hoàn thành, người quản lí kiểm thử và thành viên tổ phải bắt đầu xây dựng một tập các trường hợp kiểm thử cho phần mềm. Phải có tối thiếu một trường hợp kiểm thử cho từng use case. Nhiều use case có thể yêu cầu nhiều trường hợp kiểm thử. (Lưu ý: Trường hợp kiểm thử nên được thực hiện ở cuối pha phân tích yêu cầu và đầu pha thiết kế để nhận diện bất kì yêu cầu nào bị bỏ sót hay còn mơ hồ. Nếu bạn không thể kiểm thử được cái gì đó điều đó nghĩa là yêu cầu của bạn không rõ ràng hay kiểm thử được. Trong trường hợp đó tổ nên quay lại và đề nghị khách hàng kiểm nghiệm. Mọi trường hợp kiểm thử đều phải dùng một khuôn mẫu tương tự: với từng trường hợp đều phải có mục đích kiểm thử, dữ liệu kiểm thử, kết quả mong đợi, và ngày trường hợp kiểm thử được cho chạy (và cho lại kết quả xác định) và tên của thành viên tổ tiến hành kiểm thử).
Bên cạnh các chức năng được mô tả trong SRS, tổ phải nhận diện các yêu cầu phi chức năng (thuộc tính chất lượng) như an ninh, hiệu năng, tính truy nhập được, tính dễ dùng, tính dễ học, tính bảo trì được, v.v.) vì sản phẩm phải thoả mãn các ràng buộc vận hành thực tế (các cấu phần hệ điều hành, cơ sở dữ liệu, phần cứng và phần mềm). PM phải chỉ ra cách những yêu cầu phi chức năng này có thể được đáp ứng và bất kì hỗ trợ bảo trì nào mà sản phẩm cần sau khi đưa ra cho khách hàng. (Lưu ý: Đây là hoạt động nhiều tổ capstone không đạt tới. Mặc dầu khách hàng không yêu cầu điều đó nhưng tổ dự án phải thực hiện nó vì đó là mấu chốt cho vận hành và nó sẽ vượt quá mong đợi của khách hàng và cho ấn tượng tích cực hơn cho tổ.)
Khi cả các nhiệm vụ chức năng và phi chức năng (thuộc tính chất lượng) được thực hiện, tổ có thể bắt đầu làm việc trên bản mẫu, hay hiển thị màn hình điều sẽ biểu diễn cách “nhìn và cảm” của sản phẩm phần mềm như hiển thị menu chính của mọi chức năng mà người dùng sẽ thấy khi đăng nhập. Tài liệu thiết kế phải chỉ ra ít nhất vài trường hợp sử dụng use case khác biệt (khác hơn đăng nhập/đăng xuất) trong chiều sâu đầy đủ. Tổ phải kiểm điểm và biện minh bất kì vấn đề thiết kế nào hay quyết định thiết kế còn chưa rõ vào lúc này. Nếu cần, PM phải triệu tập cuộc họp với khách hàng để thẩm tra lại các yêu cầu. (Lưu ý: Đây là lần đầu tiên khách hàng thấy việc biểu diễn thực tế của công việc của tổ. Bản mẫu là quan trọng cần để thẩm tra khái niệm vận hành mà tổ có. Sau khi kiểm điểm bản mẫu, khách hàng thường đổi một số yêu cầu cho nên tổ phải được chuẩn bị và không bị thất vọng. Chấp nhận thay đổi ở pha sớm hơn là tốt hơn nhiều so với pha muộn hơn.)
Nếu có thay đổi, tổ phải quay lại cập nhật bản đặc tả yêu cầu phần mềm (SRS) với những thay đổi mới cũng như mọi use case và tài liệu bị ảnh hưởng. (Lưu ý: Nhiều dự án Capstone không làm điều này và thường gặp khó khăn trong pha kiểm thử và bảo trì về sau. Chính các thực hành rất tốt là cập nhật mọi tài liệu ngay khi thay đổi xảy ra. Tổ phải làm việc cùng nhau để vẽ ra các biểu đồ lớp chi tiết hay biểu đồ thực thể-quan hệ. Họ phải chỉ ra mọi lớp, quan hệ, thuộc tính. Có thể dùng kí pháp UML vì nó rất phổ biến trong hầu hết các dự án toàn cầu. Tổ có thể tạo ra từ điển dữ liệu cho mọi thuộc tính trong mô hình của bạn. Các mục từ phải được làm chi tiết, chính xác và không nhập nhằng. Lưu tâm rằng các khái niệm và thuộc tính bạn đang làm việc có các nghĩa hiển nhiên cho bạn nhưng có thể không hiển nhiên cho người dùng.)
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
