Giáo trình Công nghệ phần mềm - Chương 3: Quản lý dự án phần mềm

Nội dung text: Giáo trình Công nghệ phần mềm - Chương 3: Quản lý dự án phần mềm

1. Chương 3 QUẢN LÝ DỰ ÁN PHẦN MỀM
2. 3.1. Giới thiệu về quản lý dự án phần mềm Quản lý dự án phần mềm Là các hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án thời gian thực hiện, các rủi ro và quy trình thực hiện dự án nhằm đảm bảo thành công cho dự án. 2
3. Tại sao phải quản lý dự án? Các dự án thường: - Không hoàn thành đúng hạn - Chi phí xây dựng vượt quá dự toán - Chất lượng không đảm bảo 3
4. Theo thống kế của Standish Group (2006)  Có tới 50% trong số các dự án phần mềm thất bại  Chỉ có 16.2% dự án là hoàn thành đúng hạn và nằm trong giới hạn ngân sách, đáp ứng tất cả tính năng và đặc tính như cam kết ban đầu  Có 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn thành đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như thiết kế ban đầu  Và có 31.1% dự án thất bại trước khi được hoàn thành  -> hơn 83.8% dự án thất bại hoặc không đáp ứng những yêu cầu ban đầu 4
5. Mục tiêu  Quản lý các yếu tố: — Thời gian: đúng thời hạn — Chi phí: không vượt dự toán — Sản phẩm: đầy đủ các chức năng đã định — Thỏa mãn yêu cầu khách hàng . thỏa mãn về nhu cầu . thỏa mãn về tiến trình 5
6. Nhiệm vụ, quyền hạn của người quản lý dự án  Thời gian — lập lịch, điều chỉnh lịch — kiểm tra/đối chiếu các tiến trình con với lịch biểu — tạo độ mềm dẻo trong lịch biểu  Tài nguyên — thêm tiền, thêm người, thêm thiết bị  Sản phẩm — thêm, bớt, sửa chức năng  Rủi ro — phân tích rủi ro — đề xuất giải pháp — thực hiện giải pháp và giám sát 6
7. Các pha công việc - Thiết lập: Viết đề án - Ược lượng: Chi phí, người, thiết bị - Phân tích rủi ro - Lập kế hoạch - Chọn người - Theo dõi và kiểm soát dự án - Viết báo cáo và trình diễn sản phẩm 7
8. Xác định yêu cầu chung . Trước tiên cần xác định các yêu cầu chức năng (công việc phần mềm thực hiện) cũng như phi chức năng (công nghệ dùng để phát triển phần mềm)của phần mềm . Sau đó cần xác định rõ tài nguyên cần thiết để xây dựng phần mềm: . Nhân tố con người . Các thành phần . Phần mềm có thể sử dụng lại . Phần cứng hoặc công cụ có sẵn cần dùng đến . Xác định thời gian cần thiết để thực hiện dự án. . Trong quá trình này cần phải nắm bắt được bài toán thực tế cần giải quyết cũng như các hoạt động mang tính nghiệp vụ của khách hàng để có thể xác định rõ ràng yêu cầu chung của 8 đề án, xem xét dự án có khả thi hay không
9. Viết đề án . Bối cảnh thực hiện dự án: Căn cứ pháp lý để thực hiện, hiện trạng cntt của khách hàng trước khi có dự án, nhu cầu ứng dụng phần mềm của khách hàng, đặc điểm và phạm vi của phần mềm sẽ xây dựng. . Mục đích và mục tiêu của dự án: Xác định mục tiêu của phần mềm: lượng dữ liệu xử lý, lợi ích phần mềm đem lại. . Phạm vi dự án: Những người liên quan tới dự án, các hoạt động nghiệp vụ cần tin học hóa. . Nguồn nhân lực tham gia dự án: Cán bộ nghiệp vụ, người tham gia (phân tích, thiết kế, lập trình,kiểm thử, cài đặt, người hướng dẫn khách hàng sử dụng, bảo trì) . Ràng buộc thời gian thực hiện dự án: Ngày nghiệm thu dự án, ngày bàn giao dự án. . Ràng buộc kinh phí: Kinh phí trong từng giai đoạn thực hiện dự án. . Ràng buộc công nghệ phát triển: Sử dụng Công nghệ nào 9 . Chữ kí các bên liên quan tới dự án
10. Lập kế hoạch dự án - Hiểu rõ tầm quan trọng của việc lập kế hoạch dự án - Ứng với mỗi hoạt động trong quá trình phát triển phần mềm, chúng ta sẽ phải có một bản kế hoạch riêng. - Nắm được cấu trúc của một bản kế hoạch dự án phát triển hệ thống phần mềm. - Nó liệt kê các hành động từ pha khởi tạo cho đến khi đưa ra được hệ thống. Kế hoạch phải được theo dõi thường xuyên, nhất là khi có những thông tin hoặc những yêu cầu mới xuất hiện. 10
11. Lập kế hoạch dự án 11
12. Các loại kế hoạch thực hiện dự án C 12
13. 3.2. Đo và ước lượng • Cách thức tiếp cận quản lý: Đo và ước lượng • Đo phần mềm Kích thước, chi phí, hiệu năng, chất lượng • Ước lượng - Kích thước - Chi phí - Thời gian • Chỉ quản lý các yếu tố có thể đo được 13
14. 3.2. Đo và ước lượng • Ước lượng phần mềm là công việc quan trọng hàng đầu trong quản lý dự án - Kích cỡ, chi phí - Thời gian, nhân lực • Để ước lượng cần có độ đo - kích cỡ, chất lượng, hiệu năng • Nguyên lý: Cần phải xác lập độ đo cho mọi công việc độ đo phải định lượng 14
15. Đo kích cỡ phần mềm • Đo số dòng lệnh (LOC – Lines Of Code) : Trực quan, phụ thuộc vào ngôn ngữ lập trình cụ thể. Từ kích cỡ phần mềm có thể tính một số giá trị như - Hiệu năng = KLOC/người –tháng - Chất lượng: Số lỗi / KLOC - Chi phí: Giá thành/KLOC 15
16. Đo kích cỡ phần mềm . Điểm chức năng FP Tính dựa trên đặc tả yêu cầu và độc lập với ngôn ngữ phát triển. Mô hình cơ sở của tính điểm chức năng là . FP = a1I+ a2O + a3E + a4L + a5F, . Trong đó: - I : số Input - O: số output - E: số yêu cầu - L: Số tệp truy cập - F: số giao diện ngoại lai (devices, systems) 16
17. Đo kích cỡ phần mềm • Ví dụ: FP=4I + 5O + 4E + 10L + 7F Hàm: tính ước số chung lớn nhất của hai số nguyên Input =2 Output = 1 Yêu cầu =1 -> FP = 17 17
18. Độ đo về chất lượng dựa trên thống kê 18
19. Độ đo hiệu quả phát hiện lỗi 19
20. Ước lượng phần mềm 20
21. Ước lượng phần mềm 21
22. Ước lượng phần mềm 22
23. Ước lượng phần mềm 23
24. Mô hình ước lượng COCOMO- Constructive Cost Model 24
25. COCOMO: Các bước tiến hành 25
26. COCOMO: Tham số cơ sở 26
27. COCOMO: Tham số cơ sở 27
28. COCOMO: Ví dụ  Phần mềm kích cỡ 33.3 KLOC. − a = 3.0 b = 1.12 c = 2.5 d = 0.35 − E = 3.0 * 33.31.12 = 152 person-month − T = 2.5 * E0.35 = 14.5 tháng — N = E/D = ~ 11 người 28
29. Khó khăn trong ước lượng  Các thông số không trực quan  Khó đánh giá tính đúng đắn của các tham số  Không có mô hình tổng quát  Các kỹ thuật ước lượng đang thay đổi • Áp dụng các mô hình khác nhau • Tiến hành ước lượng nhiều lần • Ѭớc lѭợng lại khi dự án tiến triển 29
30. 3.3. Lập lịch và theo dõi  Ước lượng cho chúng ta con số khái quát để làm cơ sở thực hiện dự án — Lịch trình cụ thể phụ thuộc vào mô hình lựa chọn — Số ngѭời tham gia thay đổi theo từng pha của dự án  Cần phải phân tích chi tiết hơn và lập lịch để kiểm soát công việc 30
31. 3.3. Lập lịch và theo dõi  Lập lịch để kiểm soát công việc (nhiệm vụ) — xác định nhiệm vụ — thời điểm bắt đầu, thời điểm kết thúc — người thực hiện — ràng buộc (mối liên hệ giữa các nhiệm vụ) cần có độ mềm dẻo về thời gian 31
32. Xác định tài nguyên cho dự án  Con người — là nhân tố quan trọng nhất — cần phải tập hợp các thành viên có nĕng lực — mỗi giai đoạn cần số ngѭời, nĕng lực khác nhau  Phần mềm dùng lại được — Các thành phần đã đѭợc đóng gói (dễ dàng dùng lại) — Các thành phần đã có kinh nghiệm (dễ dàng sửa chữa để phục vụ cho dự án) — Các thành phần dùng lại ít có kinh nghiệm (chi phí cho sửa chữa lớn)  Phần cứng/công cụ phần mềm — Phải chia sẻ phần cứng, công cụ 32
33. Xác định nhiệm vụ  Nhiệm vụ phải được xác định là: — Là công việc có kết quả bàn giao — Qui trách nhiệm cho một cá nhân — Có hạn định về thời gian — Có thể đo được (tiến độ, chất lượng) 33
34. Xác định ràng buộc nhiệm vụ  Các ràng buộc về tài nguyên (con ngѭời, thiết bị)  Ràng buộc về tiến trình — các nhiệm vụ phải đѭợc kết thúc trѭớc — các nhiệm vụ có thể đѭợc thực thi kế tiếp  Giảm tối đa các nhiệm vụ phụ thuộc  Thực hiện các nhiệm vụ song song khi có thể 30
35. Lập lịch nên  Giảm tối đa thời gian thừa  Tận dụng tối đa các nguồn lực có thể  Điều phối tài nguyên (chỗ thừa/thiếu)  Xem xét các hạn chế — phụ thuộc tiến trình — phụ thuộc tài nguyên  Là một qui trình lặp lại — theo dõi thời gian biểu — sửa chữa, lập lại thời gian biểu  Sử dụng các công cụ tự động 35
36. Work tasks week 1 week 2 week 3 week 4 week 5 I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined Define desired output/control/input (OCI) I.1.2 Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WPfunctions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe I.1.3 spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete Isolate software elements Milestone: Software elements defined Research availability of existing software Reseach text editiong components Research I.1.4 voice input components Research file management components I.1.5 Research Spell/Grammar check components Milestone: Reusable components identified Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed I.1.6 Make quick estimate of size Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope I.1.7 document complete I.1.8 36
37. Tham khảo  Thời gian thực tế thường kéo dài hơn ѭớc lượng từ 25% đến 40%.  Lý do: — Một số công việc không ước lượng được — Một số công việc phải làm lại — Người phát triển tham gia đồng thời nhiều công việc 37
38. 3.4.Đảm bảo chất lượng phần mềm  Software Quality Assurance – SQA —Là công việc xuyên suốt quá trình phát triển phần mềm  Thế nào là chất lượng? — Chất lượng của phần cứng = sự ổn định, sự đồng đều — Chất lѭợng phần mềm . Tin cậy, dễ sử dụng, hiệu quả, bảo trì . Khó đo đạc trực quan 38
39. 3.4Đảm bảo chất lượng phần mềm  Đảm bảo chất lượng khi bắt đầu dự án — Con người — Qui trình — Công cụ  Đảm bảo chất lượng trong quá trình thực hiện dự án — tuân thủ qui trình (các chuẩn, các tài liệu) — họp xét duyệt — kiểm thử sản phẩm 39
40. Giá trả cho tìm và sửa lỗi 100 60.00- log 100.00 scale 10 10.00 3.00 1.50 1 0.751.00 Design testsystem field Req. code test use 40
41. Xét duyệt  Tại mỗi pha công việc, cần họp xét duyệt để đảm bảo chất lượng — không để lỗi truyền sang pha sau  Thực hiện theo nhóm  Xét duyệt các tài liệu — Phân tích — Thiết kế — Mã nguồn — Tài liệu người dùng − 41
42. 3.5. Nghiên cứu khả thi Xác định phân tích yêu cầu — Phạm vi phần mềm — Khả thi về kinh tế — Khả thi về kỹ thuật — Khả thi về pháp lý — Các rủi ro và biện pháp khắc phục 42
43. Khả thi về kinh tế  Phân tích lợi ích - chi phí — chi phí xây dựng — phí tổn vận hành — hiệu quả kinh tế — vị trí của sản phẩm — khả nĕng tài chính của khách hàng  Khách hàng và nhà phát triển có cách nhìn khác nhau vǻ tính kinh tǹ, nhà phát triển cần thuyết phục khách hàng và tính kinh tế 43
44. Khả thi về kỹ thuật  Khó đánh giá ở giai đoạn phân tích — có công nghệ để thực hiện không? — có nĕng lực thực hiện không? — có tài nguyên (phần cứng) để thực hiện không? — khách hàng có vận hành đѭợc không 40
45. Khả thi về pháp lý  Khả thi về pháp lý là yếu tố ít quen thuộc đối với người phát triển — Vi phạm bản quyền . sử dụng mã nguồn của người khác . cung cấp âm nhạc trực tuyến — Vi phạm tự do cá nhân . kiểm duyệt email, phá mật khẩu — Gây hại đối với bên thứ ba . virus, spam email, DoS — Các vi phạm pháp luật khác . cung cấp các dịch vụ cấm, 45
46. Báo cáo khả thi  Cần đưa ra quyết định — làm — không làm — xem xét lại 46
47. 3.6. Rủi ro và biện pháp  Các nhân tố có thể làm thất bại dự án — rủi ro kỹ thuật: quá khó — rủi ro kinh tế: quá đắt — rủi ro thời gian: thời gian quá ngắn phân hoạch yêu cầu • cần thiết • mong muốn • phụ (optional) 47
48. Quản lý rủi ro dự án phần mềm 48
49. Ví dụ về rủi ro 49
50. Các rủi ro 50
51. Hoạt động của quản lý rủi ro 51
52. Tiến trình quản lý rủi ro 52
53. Bước 1: Xác định các rủi ro có thể 53
54. Thời gian ước lượng thực tế 54
55. Phương pháp xác định rủi ro 55
56. Một số kỹ thuật xác định rủi ro 56
57. Một số kỹ thuật xác định rủi ro 57
58. Một số kỹ thuật xác định rủi ro 58
59. Một số kỹ thuật xác định rủi ro 59
60. Một số câu hỏi giúp xác định rủi ro 60
61. Một số câu hỏi giúp xác định rủi ro 61
62. Bước 2: Phân tích rủi ro 62
63. Một số rủi ro và giải pháp 63
64. Một số rủi ro và giải pháp 64
65. Bước 3: Lập kế hoạch đáp ứng 65
66. Chiến lược đáp ứng rủi ro 66
67. Chiến lược đáp ứng rủi ro 67
68. Chiến lược đáp ứng rủi ro 68
69. Chiến lược đáp ứng rủi ro 69
70. Bước 4: Kiểm soát rủi ro 70
71. Quản lý rủi ro  Rủi ro là các sự kiện khiến dự án thất bại — chi phí quá cao — thời gian quá dài — tính nĕng quá kém  Là các yếu tố có thể quản lý được  Nhiệm vụ của ngѭời quản lý dự án — xác định (dự đoán) rủi ro — phân tích rủi ro (khả nĕng và thiệt hại) — quản lý rủi ro (đưa ra giải pháp) — giám sát (theo dõi sự xuất hiện, tác động của rủi ro) và thực hiện biện pháp quản lý 71
72. Quản lý rủi ro  Dựa trên phân hoạch yêu cầu — chức nĕng cần thiết — chức nĕng mong muốn — chức nĕng phụ thêm  Nguyên lý Pareto (80-20)  Phân tích, đưa ra quyết định có áp dụng biện pháp quản lý cần thiết hay không — dựa trên thống kê (kinh nghiệm) — dùng cây quyết định 72
73. 3.7. Quản lý nhân sự  Con người là yếu tố quan trọng nhất trong phát triển phần mềm  Các thành viên rất khác nhau về năng lực  Một số các công việc đặc thù không phải ai cǜng làm được — lập trình hệ thống — giao diện đồ họa cao cấp — điều khiển thiết bị — cơ sở dữ liệu 73
74. Nhóm và đặc trưng  Phần mềm phát triển theo nhóm  Kích thước tối ưu của nhóm: 3~8 người  Tổ chức nhóm — lập trình viên — chuyên gia giao diện — chuyên gia miền ứng dụng — thủ thư phần mềm (quản lý cấu hình) — kiểm thử viên  Cần có — team leader — technical leader 74
75. Nhóm và đặc trưng  Không nên tổ chức nhóm quá lớn — thời gian cho giao tiếp sẽ tĕng cao — khó tĕng tốc độ bằng cách thêm người  Một số công việc chỉ nên để cho một người thực hiện  Cần phân rã dự án lớn thành các dự án nhỏ 75
76. Phân bổ thời gian làm việc 20% không trực tiếp làm việc 50% giao tiếp với các 30% thành làm việc viên khác 76
77. Một số cách tổ chức nhóm  Nhóm ngang quyền (democratic team) — Công việc được thảo luận và các thành viên thống nhất giải pháp chung — Các thành viên đều có kinh nghiệm và năng lực  Nhóm XP — Một dạng của ngang quyền, lập trình đôi và chịu trách nhiệm chung  Nhóm quyền lực tập trung (chief programmer team) — Nhóm trѭởng có nĕng lực vượt trội và là người thiết kế chính — Các thành viên khác thực hiện công việc chi tiết 50
78. 3.7. Quản lý cấu hình phần mềm 78
79. 3.7. Quản lý cấu hình phần mềm 79
80. Công cụ hỗ trợ quản lý dự án 80