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

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