Bài giảng Quản lý dự án phần mềm - Quản lý phạm vi

Nội dung text: Bài giảng Quản lý dự án phần mềm - Quản lý phạm vi

1. QUẢN LÝ PHẠM VI Nguyễn Anh Hào Khoa CNTT – HV CNBCVT II 2005 - 2006 1
2. 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
3. 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
4. 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
5. 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
6. * 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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