Chương 3: Quản lý phạm vi

Chương 3: Quản lý phạm vi Giảng viên: Nguyễn Văn Hòa Khoa CNTT - ĐH An Giang Nội dung     Quản lý phạm vi dự án Thu thập yêu cầu Xác định phạm vi Tạo cấu trúc phân chia công việc WBS      Khái niệm WBS Các đặc trưng WBS Phân loại WBS Các phương pháp tạo WBS Kiểm tra kiểm soát phạm vi Phạm vi dự án  Phạm vi cần thực khơng thực NEEDS FEATRUES REQUIREMENTS Phạm vi dự án tt Người quản lý phải cần áp dụng hệ thống lập kế hoạch kiểm soát tất hoạt động dự án để đáp ứng yêu cầu đề  Nếu dự án đơn giản, người quản lý cần dựa kinh nghiệm đủ  Nếu dự án lớn phức tạp, công việc vượt khả bao quát nhà quản lý Cần kỹ thuật để xác định đầy đủ công việc cần thực hiện, công việc không cần  Quản lý phạm vi dự án    Một khía cạnh quan trọng khó khăn quản lý dự án xác định phạm vi dự án Phạm vi dự án đề cập đến tất việc có liên quan để tạo sản phẩm dự án tiến trình sử dụng để tạo chúng Quản lý phạm vi dự án bao gồm quy trình xác định kiểm sốt cơng việc dự án công việc không thuộc dự án Quản lý phạm vi dự án tt     Quản lý phạm vi dự án có ý nghĩa quan trọng việc thực thành công dự án Xác định phạm vi dự án không rõ ràng nhân tố dẫn đến thất bại DA Nếu dự án bị điều chỉnh phạm vị liên tục nhiều yêu cầu thay đổi không quản lý tốt vòng đời dự án Thay đổi phạm vi  kéo dài thời gian thực Quản lý phạm vi dự án tt  Quy trình bước quản lý phạm vi dự án:     Thu thập yêu cầu: nhằm xác định tính chức sản phẩm Xác định phạm vi: đội dự án xem xét yêu cầu, quy trình phát triển dự án để viết báo cáo phạm vi (Statement Scope) Thiết lập cấu trúc phân chia công việc WBS Xác nhận phạm vi: bên liên quan kiểm tra phạm vi trước thức phát hành phạm vi dự án Thu thập yêu cầu    Thu thập yêu cầu bước bước khó quản lý phạm vi dự án Tổ dự án làm việc với bên liên quan, đặc biệt khách hàng, người dùng để thu thập yêu cầu Nếu tổ dự án thu thập yêu cầu không ghi nhận đầy đủ yêu cầu khác hàng tính hay chức nhóm phát triển phải trả giá đắc để bổ sung tính hay chức Yêu cầu phần mềm  Định nghĩa yêu cầu (theo Tiêu chuẩn Kỹ thuật Công nghệ phần mềm IEEE năm 1990)    Là điều kiện hay khả mà người dùng cần để giải cơng việc Là điều kiện hay khả cần phải có hệ thống, chương trình phần mềm, cần phải có để ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật Hoặc hồ sơ dùng để đại diện cho hay ý Thu thập yêu cầu tt   Theo PMBOK, yêu cầu điều kiện hay khả phải đáp ứng hệ thống, sản phẩm, dịch vụ, kết quả, thành phần để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật Q trình thu thập u cầu phần mềm có bước     Thu thập yêu cầu (Requirements elicitation) Phân tích yêu cầu (Requirements analysis) Đặc tả yêu cầu (Requirements specification) Xét duyệt yêu cầu (Requirements validation) 10 Các bước tạo WBS B4: Gán cho phần tử WBS mã số Sản phẩm mức cao có mã số 0.0, 1.0, … Mã số mối liên quan phần tử nhánh B5: Xem xét lại tính logic tính đầy đủ WBS để đảm bảo rằng: - Mọi sản phẩm có danh từ (có thể có tính từ) - Tất cơng việc có động từ lệnh bổ ngữ - Mọi phần tử có mã số WBS 25 Tính đầy đủ WBS Mỗi hoạt động (activity) phải có đặc điểm sau: Có thể đo lường trạng thái hoàn thành Các kiện bắt đầu kết thúc định nghĩa rõ ràng Mỗi hoạt động phải có đầu (deliverable) Thời gian/chi phí ước lượng dễ dàng Thời gian kết thúc hoạt động nằm khoảng chấp nhận Các công việc gán độc lập 26 Biểu diễn WBS  Có dạng    Được đánh dấu số thập phân     Outline Dạng cây/sơ đồ tổ chức (Organizational Chart) Ví dụ: 3.1.5 mức cao nhẩt Cho thấy mối quan hệ “cha-con” hay “chứa trong” Không hoạt động phụ thuộc thời gian cần cho hoạt động 27 Biểu diễn WBS: Cấu trúc outline 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production 28 Biểu diễn WBS: Cấu trúc 29 Các phương pháp tạo WBS     Top-Down Bottom-Up Analogy BrainStorming 30 Phương pháp top-down    Bắt đầu cấp cao (0) Các cấp sinh suy diễn từ “tổng quát” đến “chi tiết” Thuận lợi nếu:   Hiểu rõ vấn đề đặt Kỹ thuật phương pháp không 31 Phương pháp bottom-up     Bắt đầu cấp thấp (tác vụ cụ thể) Mức cao xây dựng từ tổng hợp từ “chi tiết” đến “tổng quát” Phương pháp lý tưởng cho việc tìm lời giải cho vấn đề độc lập Nhược điểm    Tổng thời gian Cần yêu cầu cụ thể Ưu điểm: Chi tiết (detailed) 32 Phương pháp analogy     Căn WBS dự án tương tự Dùng template Analogy sở để ước lượng Ưu điểm   Dựa kinh nghiệm thực tiễn Nhược điểm  Cần phải so sánh với dự án khác 33 Phương pháp Brainstorming    Liệt kê tất công việc cần thực Nhóm chúng theo chủng loại Có thể kết hợp Top-down Brainstorming WBS 34 Công cụ dùng để tạo WBS     Bảng Sticky note Giấy Phần mềm (Microsoft Organization chart, Microsoft visio,…) 35 Các nguyên lý tạo WBS Một đơn vị công việc xuất nơi WBS Nội dung công việc mục WBS tổng cơng việc Một mục WBS nhiệm vụ người, có nhiều người thực cơng việc WBS phải quán với cách thực cơng việc; trước hết phải phục vụ nhóm dự án mục đích khác thực tế cho phép 36 Các nguyên lý tạo WBS… Các thành viên nhóm dự án phải tham gia phát triển WBS để bảo đảm tính quán Mỗi mục WBS phải có tài liệu kèm để bảo đảm hiểu xác phạm vi cơng việc WBS phải công cụ linh hoạt để đáp ứng thay đổi không tránh được, điều khiển nội dung công việc theo tuyên bố phạm vi 37 Kiểm tra phạm vi    Kiểm tra, xác minh phạm vi dự án phần mềm để giảm thiểu tối đa thay đổi Khơng dự án mà phạm vị phình (scope creep) so với mức độ thực dự án Kiểm tra phạm vi bao hàm hoạt động bên liên quan dự án đến thức chấp nhận phạm vi dự án 38 kiểm soát phạm vi     Thay đổi trình thực dự án khơng thể tránh khỏi Kiểm sốt phạm vi q trình theo dõi tình hình phạm vi dự án quản lý thay đổi Kiểm soát thay đổi phạm vi dự ám đảm bảo tất yêu cầu thay đổi Khi đề xuất thay đổi chấp nhận đưa vào thực cần phải cật nhật phạm vi dự án 39