Bài giảng Quản lý dự án phần mềm: 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
Nơi
phát
sinh
yêu
cầu

Trợ giúp

Khả năng

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

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

1.1

1.2

2.0

2.1

3.0

2.2

3.2

Task breakdown

Độ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
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 bản 1

SR1

DD1

Phiên bản 2

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


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
~

~
1.
2.
3.

4.

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:
Định nghĩa các yếu tố cấu hình (configuration items)
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)
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)
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
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 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