Bài giảng Quản lý dự án phần mềm: Quản lý phạm vi - Nguyễn Anh Hào

Bài giảng Quản lý dự án phần mềm: Quản lý phạm vi cung cấp cho người học các kiến thức: Phạm vi (scope), quản lý phạm vi, công việc định nghĩa phạm vi (yêu cầu), tiến hành cam kết, phân tích khả thi,... Mời các bạn cùng tham khảo nôi dung chi tiết.

QUẢN LÝ PHẠM VI Nguyễn Anh Hào Khoa CNTT – HV CNBCVT II 2005 - 2006 Phạm vi (scope) • Phạm vi: ranh giới giới hạn cho công việc sản phẩm mà dự án dự định tiến hành – Phạm vi sản phẩm – Phạm vi cơng việc • Phạm vi = phạm vi trách nhiệm = toàn yêu cầu dự án cam kết thực hiện: – Yêu cầu đ/v sản phẩm (chuyển giao) – Yêu cầu đ/v công việc dự án • Để có sản phẩm dự án cần sử dụng nguồn lực hữu hạn để thực cơng việc tạo sản phẩm => phải có giới hạn phạm vi để phù hợp với nguồn lực cấp phát Quản lý phạm vi • Quản lý phạm vi: khẳng định công việc cần làm sản phẩm cần tạo ra, làm công việc cần làm để hồn thành dự án khng thời gian chi phí cam kết – ie : giới hạn trách nhiệm dự án, khẳng định thuộc dự án khơng thuộc dự án, thực cam kết để khơng bị trễ hạn, lạm chi, chất lượng thiếu thời gian, kinh phí – Việc làm hồi… đến dự án ngừng (RM) • Gồm công việc: – 1.Định nghĩa phạm vi (Requirements Management) – 2.Kiễm soát thay đổi phạm vi (Change Management) – 3.Giám sát việc thực (Tracking&Oversight) 1.Định Nghĩa Phạm Vi • Thiết lập phát biểu mơ tả chi tiết phạm vi dự án để làm sở kết thúc dự án tương lai, dựa cân đối nguồn lực dự án yêu cầu cam kết Mô tả sản phẩm công việc Các tiêu chuẩn dùng để nghiệm thu Các điều khoản dùng để thay đổi phạm vi dự án • Phạm vi dự án phần mềm = đặc tả yêu cầu đ/v phần mềm (sau phân tích) + yêu cầu thêm cách tiến hành dự án – SW Requirements Engineering !! Công việc định nghĩa phạm vi (yêu cầu) Xác định yêu cầu từ môi trường sản phẩm – Nghiệp vụ tổ chức thụ hưởng (quy tắc quản lý) – Mong muốn từ người sử dụng (Actors, stackholders) – Môi trường hổ trợ (thiết bị, cơng nghệ, ) Xem xét lợi ích thực (quy thành tiền được, MOV *) yêu cầu mà dự án đáp ứng Tiến hành cam kết ** bên phạm vi dự án – ghi thành phát biểu phạm vi dự án * MOV chuyễn giao • • • Chuyển giao = sản phẩm + dịch vụ mà dự án cung cấp Chuyyễn giao đáp ứng hết phần yêu cầu từ môi trường, lực bị giới hạn dự án MOV (Mesureable Organisational Value) = giá trị sử dụng chuyển giao Sử dụng môi trường Chuyển giao MOV Mong muốn từ MOV → Yêu cầu đ/v chuyển giao Những yêu cầu đưa đến chuyển giao có giá trị sử dụng cao nên đưa vào phạm vi dự án ** Tiến hành cam kết ~ Thiết lập cam kết thực yêu cầu đ/v dự án – Xem xét chọn lọc yêu cầu thành yêu cầu khả thi để đưa vào kế hoạch thực (Baseline Project Plan) Phân tích khả thi Nơi phát sinh yêu cầu Trợ giúp Khả Yêu cầu Yêu cầu Khả thi  Mục tiêu Nguồn lực Phương án / Rủi ro BaseLine Project Plan  Nhóm dự án: trách nhiệm  Làm thỏa mãn cam kết Phân tích khả thi (1) Khả thi kinh tế (Economic Feasibility) • Xác định lợi lợi ích hữu hình lợi ích vơ hình từ giải pháp giải yêu cầu (vd: giảm chi phí vận hành, khắc phục lỗi, gia tăng tính linh hoạt, tăng tốc độ xử lý, ) • Xác định chi phí hữu hình chi phí vơ hình từ giải pháp giải yêu cầu (chi phí ban đầu chi phí phát sinh thường kỳ lúc sử dụng) • Cân nhắc lợi ích chi phí Phân tích khả thi (2) Khả thi kỹ thuật (Technical Feasibility): xem xét cách giải yêu cầu, để dự kiến khó khăn gây rủi ro (thất bại, lỗi), từ đưa đến định chấp nhận u cầu hay từ chối u cầu • Ví dụ: – Có cách làm đáng tin cậy để giải vấn đề chưa ? – Những khó khăn cách làm nhận thức đầy đủ chưa ? – Năng lực dự án hổ trợ từ bên ngồi có đủ để thực cách làm khơng ? Phân tích khả thi (3) Khả thi vận hành (Operational Feasibility): đánh giá khả sử dụng sản phẩm phần mềm môi trường mà vận hành, khai thác – Các phân tích phải bộc lộ giá trị sử dụng (cao hay thấp) sản phẩm phần mềm cho tổ chức thụ hưởng – Sản phẩm phần mềm thành phần (hoặc hệ thống con) môi trường vận hành tổ chức thụ hưởng (công nghệ, thiết bị, quy trình, quy tắc quản lý, người sử dụng,… ) ; phải tương thích với mơi trường 10 Phân tích khả thi (4) Khả thi kế hoạch thực (Schedule Feasibbility) Phân tích thời gian cần thiết để làm thỏa mãn yêu cầu, thời gian phải phù hợp với thời hạn hoàn thành dự án Khả thi pháp lý (Legal and Contractual Feasibility) Phân tích khả thực yêu cầu phạm vi cho phép nhà nước (luật lao động, luật quyền sở hữu trí tuệ, ) điều khoản hợp đồng (quyền sử dụng phần mềm, tài liệu tổ chức, ) Khả thi trị xã hội (Political Feasibility): Ước lượng mức độ hài lòng stakeholders giải pháp giải yêu cầu 11 Phát biểu phạm vi dự án Ví dụ: phạm vi dự án: Cung cấp chiến lược TMĐT cho tổ chức thụ hưởng, xác định xử lý, sản phẩm, dịch vụ cung cấp internet → phạm vi dịch vụ dự án (tư vấn) Tạo hệ thống phần mềm hổ trợ xử lý, sản phẩm, dịch vụ chiến lược → phạm vi sản phẩm dự án Tích hợp hệ thống phần mềm vào mơi trường vận hành công ty → phạm vi dịch vụ dự án phạm vi dự án: Đánh giá trình độ cơng nghệ cơng ty Phần mềm có chức khai khống liệu 12 Work Breakdown Structure (1) • Là cấu trúc phân rã mục tiêu, yêu cầu (sản phẩm chuyển giao) dự án thành thành phần đủ nhỏ để hiểu làm (công việc) Danh từ 0.0 Product breakdown 1.0 1.1 1.2 2.0 2.1 3.0 2.2 3.2 Task breakdown Động từ 13 Work Breakdown Structure (2) Sản phẩm phân rã đến mức đủ nhỏ để hiểu (“what”) Mọi sản phẩm mức thấp gắn với công việc Công việc phân rã đến mức đủ nhỏ để thực (how) Mọi công việc mức thấp khả thi điều kiện nguồn lực giới hạn dự án WBS phải bảo đảm sản phẩm công việc thể theo thứ tự hợp lý, không mâu thuẩn 14 Ví dụ WBS Sinh nhật 0.0 Thiệp 1.0 Đến CH1 Mua thiệp Phát thiệp 1.1 1.2 1.3 Bánh 2.0 Đến CH2 Mua bánh 2.1 2.2 Nến 3.0 Đến CH3 3.1 Mua nến 3.2 15 Ví dụ WBS Sản phẩm PM Phiên SR1 DD1 Phiên P1 Đn yêu cầu R1 SR2 DD2 P2 Cập nhật R1 Thiết kế D1 Tạo mẫu P1 Cập nhật D1 Cập nhật P1 WBS cho dự án làm theo mô hình xoắn ốc 16 Kiểm sốt thay đổi phạm vi • Xem xét yếu tố gây thay đổi phạm vi dự án kiểm soát thay đổi phạm vi dự án, để tích hợp cơng việc điều chỉnh cần thiết vào kế hoạch thực dự án – Là phần việc quản lý cấu hình • Kết quả: – Các phiên cập nhật BPP, WBS, Phạm vi – Các hành động điều chỉnh cần thiết cho phạm vi 17 Project Requirements Management Các yêu cầu phải “review” bên tham gia trước đưa vào dự án, để – Loại trừ yêu cầu không rõ nghĩa, không giới hạn trách nhiệm – Yêu cầu kiểm chứng khách quan (đo được) – Yêu cầu cho dự án cam kết Các thay đổi nội dung yêu cầu phải “review” bên tham gia trước đưa vào dự án, để – Ước lượng mức độ ảnh hưởng thay đổi đàm phán – Định nghĩa, tính tốn rủi ro, lập tài liệu kiễm sốt – Thơng báo nơi có liên quan 18 Các loại thay đổi • Khơng chắn phạm vi yêu cầu (Scope grope) – Do dự án không hiểu rõ hết yêu cầu • Tăng thêm yêu cầu (Scope creep) – Bổ sung thêm tiện ích • Sửa u cầu (Scope leap) – Do nhận thức không đúng, nhu cầu sử dụng thay đổi => Xem xét yêu cầu cách có hệ thống (từ mơi trường → sản phẩm) để hiểu rõ, giải vấn đề từ đến chi tiết (mơ hình xoắn ốc, mơ hình hợp nhất) 19 Quản lý cấu hình ~ ~ Cấu hình dự án tập họp yếu tố cấu hình dùng để tạo sản phẩm, như: baseline, hồ sơ phân tích, thiết kế, source code, kế hoạch thực hiện, Quản lý cấu hình kiễm sốt thay đổi yếu tố cấu hình, để phản ánh đặc điểm sản phẩm: Định nghĩa yếu tố cấu hình (configuration items) Nhận biết khác phiên sản phẩm yếu tố cấu hình (version control) Sử dụng cấu hình: xác định yếu tố cấu hình sử dụng cho phiên sản phẩm, mối quan hệ dẫn xuất từ yếu tố cấu hình lên phiên sản phẩm (build control) Kiễm soát thay đổi lên cấu hình : cân nhắc cho thay đổi yếu tố cấu hình phiển sản phẩm (change control) 20 Giám sát việc thực yêu cầu Phát để loại trừ công việc khơng góp phần làm thỏa mãn u cầu chuyển giao – Những cơng việc làm thêm, nằm ngồi yêu cầu Phát để loại trừ nguyên nhân phát sinh thêm công việc lại không gia tăng thêm giá trị cho dự án – Dữ liệu trùng lặp nhiều nơi, làm tăng số lượng testcase Đo lường mức độ thỏa mãn yêu cầu khả hoàn thành dự án (tracking & oversight) Tránh lãng phí, hiệu thân hành động giám sát điều khiển 21 Tracking & Oversight • Tracking: Thu thập liệu (đo) tiêu chí quan trọng (như mức độ thỏa mãn yêu cầu sản phẩm, mức độ tiêu tốn kinh phí,…) để tìm ngun nhân độ đo bất thường (có rủi ro, có lỗi), tìm biện pháp ứng xử Phạm vi đo toàn chuyển giao lược đồ WBS công việc tạo chuyển giao – Ví dụ: Kiễm thử thực thi, kiễm thử phi thực thi • Over-sight: Tiên đốn khẳng định điều xãy cho dự án (ví dụ: trễ hạn, hụt kinh phí, bị hủy,…) – Ví dụ: hệ số CPI, SPI từ phương pháp phân tích giá trị thu (Earned Value Analysis) phần quản lý chi phí 22 Control chart • Phân tích thay đổi chất lượng theo thời gian; kiện vượt biên độ cho phép (tín hiệu bất thường) tần suất kiện 23 Cause and Effect Diagram • Diễn tả nguyên nhân (có thể đo lường được) gây ảnh hưởng đến chất lượng hệ thống People training responsibility availability reliabilty Technology Methods Management documentation support appropriateness leadership standards methods Measurement culture Requirement not properly defined Environment 24 Phân tích tiến trình ~ Nhận biết công việc dư thừa vơ ích để loại bỏ, tiết kiệm nguồn lực thời gian Nội dung xem xét dựa trên: Ranh giới trách nhiệm cơng việc, bao gồm mục đích, đầu vào đầu ra, người thực tác nhân (nằm phạm vi cam kết dự án) Nội dung công việc, gồm cấu trúc xử lý (các việc chi tiết hơn) giao tiếp với cơng việc khác Diễn biến trạng thái công việc Diễn biến trạng thái thực công việc (đạt/không đạt yêu cầu), tiên đề cho cải tiến 25 .. .Phạm vi (scope) • Phạm vi: ranh giới giới hạn cho công vi? ??c sản phẩm mà dự án dự định tiến hành – Phạm vi sản phẩm – Phạm vi cơng vi? ??c • Phạm vi = phạm vi trách nhiệm = toàn yêu cầu dự án. .. công vi? ??c dự án • Để có sản phẩm dự án cần sử dụng nguồn lực hữu hạn để thực công vi? ??c tạo sản phẩm => phải có giới hạn phạm vi để phù hợp với nguồn lực cấp phát Quản lý phạm vi • Quản lý phạm vi: ... thay đổi phạm vi dự án • Phạm vi dự án phần mềm = đặc tả yêu cầu đ/v phần mềm (sau phân tích) + yêu cầu thêm cách tiến hành dự án – SW Requirements Engineering !! Công vi? ??c định nghĩa phạm vi (yêu