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.

Nguyễn Anh Hào

Khoa CNTT – HV CNBCVT II

QUẢN LÝ PHẠM VI

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

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)

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 !!

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

* 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

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.

** 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)

Yêu cầu

Khả năng

BaseLine Project Plan

Mục tiêu Nguồn lực Phương án / Rủi ro Yêu cầu

Phân tích khả thi

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ắcphụ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 sinhthường kỳ trong lúc sử dụng)

• Cân nhắc giữa lợi ích và chi phí

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 ?

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

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

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

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)

Work Breakdown Structure (2)

1 Sản phẩm được phân rã đến mức đủ nhỏ để hiểu nó là gì

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

Ví dụ WBS

Sinh nhật 0.0

Thiệp 1.0

Bánh 2.0

Nến 3.0

Mua thiệp 1.2

Phát thiệp 1.3 Đến CH1

1.1 Đến CH22.1 Mua bánh2.2 Đến CH33.1 Mua nến3.2

Ví dụ WBS

Sản phẩm PM Phiên bản 1 Phiên bản 2

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

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

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)

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).

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

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í

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.

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

Technology Measurement Environment

Requirement not properly defined

training responsibility

documentation appropriateness

support leadership

culture

standards methods availability

reliabilty

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:

đầ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)

chi tiết hơn) và các giao tiếp của nó với công việc khác

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