Giáo trình Quản lý dự án phần mềm

Nội dung text: Giáo trình Quản lý dự án phần mềm

1. Quảnlýdự án phầnmềm
2. Nội dung z Giớithiệuvề quảnlýdự án phầnmềm z Đovàướclượng z Lậplịch và theo dõi z Đảmbảochấtlượng phầnmềm z Nghiên cứukhả thi z Quảnlýnhânsự z Quản lý thay đổi z Công cụ hỗ trợ quảnlýdự án 2
3. Tài liệu z Pressman, Software Engineering, McGraw Hill (chapter 2 & 3) z Sommerville, Software Engineering, Addison-Wesley (chapter 29) z Ngô Trung Việt, Phương pháp luậnquản lý dự án CNTT, NXB KHKT z Giáo trình kỹ nghệ phầnmềm(chương 6) z Các tài liệu điệntử khác 3
4. Tạisaophảiquảnlýdự án z 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ấtlượng không đảmbảo 4
5. Thống kê của Standish Group (2006) z Có tới 50% trong số các dự án phầnmềmthấtbại z Chỉ có 16.2% dự án là hoàn thành đúng hạnvànằm trong giớihạn ngân sách, đáp ứng tấtcả tính năng và đặctínhnhư cam kếtban đầu z 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ạnvàbộichi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như thiếtkế ban đầu z Và có 31.1% dự án thấtbạitrướckhiđược hoàn thành z -> hơn 83.8% dự án thấtbạihoặc không đáp ứng những yêu cầu ban đầu 5
6. Mụctiêu z Quảnlýcácyếutố: − Thờigian: đúng thờihạn − Chi phí: không vượtdự toán − Sảnphẩm: đầy đủ các chứcnăng đã định − Thỏamãnyêucầu khách hàng ƒ thỏamãnvề nhu cầu ƒ thỏamãnvề tiếntrình 6
7. Nhiệmvụ, quyềnhạncủangườiquảnlýdự án z Thờigian − lậplịch, điềuchỉnh lịch − kiểmtra/đốichiếucáctiến trình con vớilịch biểu − tạo độ mềmdẻo trong lịch biểu z Tài nguyên − thêm tiền, thêm người, thêm thiếtbị z Sảnphẩm − thêm, bớt, sửachứcnăng z Rủiro − phân tích rủiro − đề xuấtgiải pháp − thựchiệngiải pháp và giám sát 7
8. Các pha công việc z Thiếtlập: viết đề án z Ướclượng (chi phí, người, thiếtbị, ) z Phân tích rủiro z Lậpkế hoạch z Chọnngười z Theo dõi và kiểm soát tiếntrình z Viết báo cáo và trình diễn 8
9. Các hoạt động thường xuyên z Đảmbảochấtlượng phầnmềm − đảmbảosựđúng đắn − đảmbảosự tuân thủ theo chuẩn z Quản lý thay đổi/quảnlýcấuhìnhphầnmềm − Quản lý thay đổivề yêu cầu, thiếtkế, mã nguồn − Quảnlýcấuhình(được phát triển phân tán) 9
10. 1. Đovàướclượng z Cách thứctiếpcậpquảnlý: đovàướclượng z Đophầnmềm − kích thước, chi phí, hiệunăng, chấtlượng z Ướclượng − kích thước − chi phí − thờigian z Chỉ quảnlýđượccácyếutố có thểđo được 10
11. Độ đovàướclượng z Ướclượng phầnmềmlàcôngviệc quan trọng hàng đầu trong quảnlýdự án − kích cỡ, chi phí − thời gian, nhân lực z Để ướclượng đượccầncóđộ đo − kích cỡ, chấtlượng, hiệunăng z Nguyên lý: cầnphảixáclập độ đocho mọicôngviệc − độ đophải định lượng 11
12. Đo kích cỡ phầnmềm z Đo theo dòng lệnh (LOC – Lines Of Code) − trực quan − phụ thuộcngônngữ z Đo điểmchứcnăng (FP – Functional Points) − độclậpvới ngôn ngữ − phụ thuộc các mô hình lựachọn (tham số) -hiệunăng: KLOC/người-tháng -chấtlượng: số lỗi/KLOC - chi phí: giá thành/KLOC 12
13. Điểmchứcnăng z Tổng hợpcácđặctrưng của module − Input − Output − Interface − Files z Đặttrọng số cho các đặctrưng z Trọng số phụ thuộcvàongữ cảnh (dự án) cụ thể − độ phứctạpcủa bài toán − Các yêu cầuvề chấtlượng, hiệunăng − Kích thướccủadữ liệusử dụng 13
14. Điểmchứcnăng FP z FP = a1I + a2O + a3E + a4L + a5F − I : số Input − O: số Output − E: số yêu cầu − L: số tệptruycập − F: số giao diện ngoại lai (devices, systems) 14
15. Điểmchứcnăng: Ví dụ z FP = 4I + 5O + 4E + 10L + 7F z Hàm: Tính ướcsố chung lớnnhấtcủa hai số nguyên − Input I = 2 − Output O = 1 − Yêu cầuE = 1 -> Điểmchứcnăng FP = 17 15
16. Độ đovề chấtlượng dựa trên thống kê z Độ tin cậy: MTBF – Mean Time Between Failures − thờigianchạy liên tục không có lỗi z Thờigiankhôiphụchệ thống − MTTR – Mean Time To Recover MTBF z Tính sẵncó: MTBF + MTTR 16
17. Độ đohiệuquả phát hiệnlỗi z Hiệuquả khử lỗi: E/(E+D) − E(rror): lỗipháthiệntrước khi bàn giao − D(efect): lỗi phát hiện sau khi bàn giao z E/(E+d/0.9) − d: số lỗi phát hiện trong 1 tháng sau khi bàn giao 17
18. Ướclượng phầnmềm z Các yếutố cần ướclượng − kích cỡ phầnmềm − chi phí (công sức) phát triển − thờigian − số người tham gia z Nguyên tắc ướclượng − phân rã chứcnăng − ướclượng vớitừng chứcnăng − dựa trên kinh nghiệm, dữ kiệnquákhứ 18
19. Ướclượng z Kích cỡ − LOC: ướclượng trựctiếpvớitừng mô đun − FP: ướclượng gián tiếp thông qua ướclượng input/output, yêu cầu z Công sức: − dựatrênkíchcỡ, độ phứctạp − dựavàodữ liệu quá khứ − đơnvị: person-day, person-week, person-month 19
20. Ví dụ z Trang web xem kếtquả họctậpcủa sinh viên bao gồmcácmôđun/giao diện chính: − nhập thông tin tìm kiếm: 100 LOC − tìm kiếm trên CSDL sinh viên: 300 LOC − sinh kếtquả: 100 LOC công sức: 01 person-week Vậyphầnmềm đào tạo 2000 LOC thì sao? 20
21. Mô hình ướclượng COCOMO - Costructive Cost Model z Ướclượng nỗ lực, thời gian, số người phát triểntừ kích cỡ phầnmềm. z Sử dụng vớicácphầnmềmlớn z Mô hình cơ sở − Nỗ lực E = a * Lb − Thời gian T = c * Ed − Số ngườiN = E/T L: số dòng lệnh (KLOC) a, b, c, d: tham số 21
22. COCOMO: các bướctiếnhành z Thiếtlậpkiểudự án − organic: đơngiản, không truy cậpcácthiếtbị ngoạilai − semi-detached − embeded: phứctạp, truy cậpthiếtbị z Xác lập (phân rã) mô đun và ướclượng số dòng lệnh z Tính lạisố dòng lệnh trên cơ sở tái sử dụng z Tính nỗ lực phát triểnE chotừng mô đun z Tính lạiE dựatrênđộ phứctạpcủadự án − độ tin cậy, độ lớncủaCSDL − yêu cầuvề tốc độ, bộ nhớ z Tính thờigianvàsố người tham gia 22
23. COCOMO: tham số cơ sở a b c d organic 3.2 1.05 2.5 0.38 semi-detached 3.0 1.12 2.5 0.35 embeded 2.8 1.2 2.5 0.32 23
24. COCOMO: Ví dụ z Phầnmềmkíchcỡ 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 24
25. Khó khăn trong ướclượng z Các thông số không trựcquan z Khó đánh giá tính đúng đắncủa các tham số z Không có mô hình tổng quát z Các kỹ thuật ướclượng đang thay đổi •Ápdụng các mô hình khác nhau •Tiếnhànhướclượng nhiềulần • Ướclượng lại khi dự án tiếntriển 25
26. 2. Lậplịch và theo dõi z Ướclượng cho chúng ta con số khái quát để làm cơ sở thựchiệndự á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 đổitheotừng pha của dự án z Cầnphải phân tích chi tiếthơnvàlậplịch để kiểm soát công việc 26
27. Lậplịch và theo dõi z Lậplịch để kiểm soát công việc (nhiệmvụ) − xác định nhiệmvụ − thời điểmbắt đầu, thời điểmkếtthúc − ngườithựchiện − ràng buộc(mối liên hệ giữa các nhiệmvụ) cầncóđộ mềmdẻovề thờigian 27
28. Xác định tài nguyên cho dự án z Con người − là nhân tố quan trọng nhất − cầnphảitậphợp các thành viên có năng lực − mỗigiaiđoạncầnsố người, năng lực khác nhau z Phầnmề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ókinhnghiệm(dễ dàng sửa chữa để phụcvụ cho dự án) − Các thành phần dùng lại ít có kinh nghiệm (chi phí cho sửachữalớn) z Phầncứng/công cụ phầnmềm − Phảichiasẻ phầncứng, công cụ 28
29. Xác định nhiệmvụ z Nhiệmvụ phải đượcxácđịnh là: − Là công việccókếtquả bàn giao − Qui trách nhiệmchomột cá nhân − Có hạn định về thờigian − Có thểđo được(tiến độ, chấtlượng) 29
30. Xác định ràng buộc nhiệmvụ z Các ràng buộcvề tài nguyên (con người, thiếtbị) z Ràng buộcvề tiếntrình − các nhiệmvụ phải đượckết thúc trước − các nhiệmvụ có thểđượcthựcthikế tiếp z Giảmtối đacácnhiệmvụ phụ thuộc z Thựchiệncácnhiệmvụ song song khi có thể 30
31. Lậplịch nên z Giảmtối đathờigianthừa z Tậndụng tối đacácnguồnlựccóthể z Điềuphối tài nguyên (chỗ thừa/thiếu) z Xem xét các hạnchế − phụ thuộctiếntrình − phụ thuộc tài nguyên z Là một qui trình lặplại − theo dõi thờigianbiểu − sửachữa, lậplạithờigianbiểu z Sử dụng các công cụ tựđộng 31
32. 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 I.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined I.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete I.1.4 Isolate software elements Milestone: Software elements defined I.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified I.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed I.1.7 Make quick estimate of size I.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete 32
33. Tham khảo z Thời gian thựctế thường kéo dài hơn ướclượng từ 25% đến 40%. z Lý do: − Mộtsố công việc không ướclượng được − Mộtsố công việcphảilàmlại − Người phát triển tham gia đồng thời nhiều công việc 33
34. 3. Đảmbảochấtlượng phầnmềm z Software Quality Assurance – SQA − Là công việc xuyên suốt quá trình phát triển phầnmềm z Thế nào là chấtlượng? − Chấtlượng củaphầncứng = sựổn định, sự đồng đều − Chấtlượng phầnmềm ƒ Tin cậy, dễ sử dụng, hiệuquả, bảotrì ƒ Khó đo đạctrực quan 34
35. Đảmbảochấtlượng z Đảmbảochấtlượng khi bắt đầudự án − Con người − Qui trình − Công cụ z Đảmbảochấtlượng trong quá trình thựchiệndự án − tuân thủ qui trình (các chuẩn, các tài liệu) − họp xét duyệt − kiểmthử sảnphẩm 35
36. Giá trả cho tìm và sửalỗi 100 60.00-100.00 log scale 10 10.00 3.00 1.50 1.00 1 0.75 Design test field Req. system code test use 36
37. Xét duyệt z Tạimỗi pha công việc, cầnhọp xét duyệt để đảmbảochấtlượng − không để lỗitruyền sang pha sau z Thựchiện theo nhóm z Xét duyệtcáctàiliệu − Phân tích − Thiếtkế − Mã nguồn − Tài liệungười dùng − 37
38. 4. Nghiên cứukhả thi z Xác định, phân tích các yếutố − Phạmvi phầnmềm − Khả thi về kinh tế − Khả thi về kỹ thuật − Khả thi về pháp lý − Các rủirovàbiện pháp khắcphục 38
39. Khả thi về kinh tế z Phân tích lợi ích - chi phí − chi phí xây dựng − phí tổnvận hành − hiệuquả kinh tế − vị trí củasảnphẩm − khả năng tài chính của khách hàng z 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ểncần thuyếtphục khách hàng về tính kinh tế 39
40. Khả thi về kỹ thuật z Khó đánh giá ở giai đoạn phân tích − có công nghệđểthựchiện không? − có năng lựcthựchiện không? − có tài nguyên (phầncứng) để thựchiện không? − khách hàng có vận hành được không 40
41. Khả thi về pháp lý z Khả thi về pháp lý là yếutố ít quen thuộc đốivớingười phát triển − Vi phạmbản quyền ƒ sử dụng mã nguồncủangười khác ƒ cung cấpâmnhạctrựctuyến − Vi phạmtự do cá nhân ƒ kiểmduyệtemail, phámậtkhẩu − Gây hại đốivới bên thứ ba ƒ virus, spam email, DoS − Các vi phạm pháp luật khác ƒ cung cấpcácdịch vụ cấm, 41
42. Rủirovàbiệnpháp z Các nhân tố có thể làm thấtbạidự án − rủirokỹ thuật: quá khó − rủirokinhtế: quá đắt − rủirothời gian: thời gian quá ngắn phân hoạch yêu cầu •cầnthiết • mong muốn •phụ (optional) 42
43. Báo cáo khả thi z cần đưa ra quyết định − làm − không làm − xem xét lại 43
44. Quảnlýrủiro z Rủirolàcácsự kiệnkhiếndự án thấtbại − chi phí quá cao − thời gian quá dài − tính năng quá kém z Là các yếutố có thể quảnlýđược z Nhiệmvụ củangườiquảnlýdự án − xác định (dựđoán) rủiro − phân tích rủiro(khả năng và thiệthại) − quảnlýrủiro(đưaragiải pháp) − giám sát (theo dõi sự xuấthiện, tác động củarủiro) và thựchiệnbiện pháp quảnlý 44
45. Quảnlýrủiro z Dựa trên phân hoạch yêu cầu − chứcnăng cầnthiết − chứcnăng mong muốn − chứcnăng phụ thêm z Nguyên lý Pareto (80-20) z Phân tích, đưaraquyết định có áp dụng biện pháp quảnlýcầnthiết hay không − dựatrênthống kê (kinh nghiệm) − dùng cây quyết định 45
46. 5. Quảnlýnhânsự z Con ngườilàyếutố quan trọng nhất trong phát triểnphầnmềm z Các thành viên rấtkhácnhauvề năng lực z Mộtsố các công việc đặc thù không phảiai cũng làm được − lậptrìnhhệ thống − giao diện đồ họacaocấp − điềukhiểnthiếtbị − cơ sở dữ liệu 46
47. Nhóm và đặctrưng z Phầnmềm phát triển theo nhóm z Kích thướctối ưucủa nhóm: 3~8 người z 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ầnmềm(quảnlýcấuhình) − kiểmthử viên z Cầncó − team leader − technical leader 47
48. Nhóm và đặctrưng z Không nên tổ chức nhóm quá lớn − thời gian cho giao tiếpsẽ tăng cao − khó tăng tốc độ bằng cách thêm người z Mộtsố công việcchỉ nên để cho một ngườithựchiện z Cần phân rã dự án lớn thành các dự án nhỏ 48
49. Phân bổ thời gian làm việc 20% không trựctiếp làm việc 50% giao tiếp vớicác 30% làm việc thành viên khác 49
50. Mộtsố cách tổ chứcnhóm z Nhóm ngang quyền (democratic team) − Công việc đượcthảoluận và các thành viên thống nhấtgiải pháp chung − Các thành viên đều có kinh nghiệmvànăng lực z Nhóm XP − Mộtdạng của ngang quyền, lậptrìnhđôi và chịu trách nhiệm chung z Nhóm quyềnlựctập trung (chief programmer team) − Nhóm trưởng có năng lựcvượttrộivàlàngười thiếtkế chính − Các thành viên khác thựchiện công việc chi tiết 50
51. Nhóm làm việchiệuquả z Các mục đích đượcthống nhất z Thànhviêntin tưởng vào vai trò và mục tiêu z Chấpnhậnmụctiêuvàtiêuchíchấtlượng z Có phương thứctraođổi thông tin hiệuquả z họp, trao đổiý tưởng, kiểm soát thay đổi z Xác lập đượcmối quan hệ hợp tác giữacác thành viên 51
52. 6. Quảnlýthayđổi z Mộttrongcáclýdo khiếnchodự án thất bại z Luôn có sự thay đổi − yêu cầu, thiếtkế, mã hóa, sửalỗi − phầnmềm luôn tiến hóa z Không nhậnrasự thay đổicủavấn đề z khôngcóphương pháp hiệuquảđể quảnlýsự thay đổi 52
53. Quảnlýthayđổi z Định nghĩa thay đổivớibấtcứ hoạt động nào: − phạmvi − kếtquả bàn giao − kiếntrúccơ bản − chi phí − lịch trình z Lậptàiliệu đầy đủ về các thay đổi, đảm bảo các thành viên hiểurõvề các thay đổi − sử dụng công cụ hỗ trợ 53
54. Quảnlýcấu hình phầnmềm Configuration management z Nhiệmvụ củaquảnlýcấu hình: − quản lý phiên bảnphầnmềm − lưutrữ tài liệu, mã nguồn, dữ liệu − tạo điểmtruycập duy nhất(đảmbảo tính thống nhấtcủa mã nguồn) z Trên diệnhẹp, còn gọilàquảnlýmãnguồn 54
55. Lợiích •Cungcấpchongười phát triển phiên bản mớinhấtcủaphầnmềm •Quản lý các mã nguồn đượclưutrữ phân tán •Quản lý các phiên bản khác nhau • Ghi chú lý do củasửa đổi mã nguồn •Dễ dàng truy cập các phiên bảncũ •Tíchkiệm không gian đĩa 55
56. Quảnlýphiênbản z Thế nào là phiên bảnphầnmềm − version − variant − release z Phải đặt ra các tiêu chí để xác định phiên bản, tiêu chí để định danh phiên bản 56
57. Phương thứchoạt động • Lưutrữ tập trung - mã nguồn, tài liệu, công cụ • Lưutrữ duy nhất (logic) • Quảnlýsửa đổi - không cho phép sửa đổi đồng thời - lưutrữ phiên bảncũ - thông tin sửa đổi: lý do, ngườithựchiện, thời điểm 57
58. Nội dung lưutrữ • Tài liệu - phân tích, thiếtkế, tài liệungười dùng • Mã nguồn • Công cụ phát triển - cần công cụ cũđểbiên dịch lạicác mã nguồncũ cho việcbảotrì • Các bộ dữ liệutest Vớiphầnmềmlớn, phảiquản lý hàng nghìn tài liệu 58
59. Chia sẻ mã nguồn Nhiềungười đồng thời phát triểnmộttệpmãnguồn • Sử dụng cơ chế lock/unlock chỉ cho phép mộtngười đượcquyềnsửa đổitạimộtthời điểm - lock (check out): mở tệp để sửa đổi - unlock (check in): kết thúc sửa đổi Đồng thờisửa đổi/ hệ thống giáp nốicác sửa đổimộtcáchtựđộng 59
60. Các công cụ z RCS − chạytrênhệđiều hành Solaris − quảnlítệp − check out/check in z CVS − dựatrênRCS − dùng cơ chế ghép nốisửa đổi z Visual SourceSafe − trong bộ công cụ Visual Studio củaMicrosoft − quảnlíproject − check out/check in 60
61. 7. Công cụ hỗ trợ quảnlýdự án z Microsoft Project 2000 − Hỗ trợ quảnlýdự án phầnmềm z Microsoft SourceSafe − Quảnlýcấu hình, mã nguồn z Visio 2000 − Tạobảng biểu, mô hình z 61
62. Gantt Chart tạobằng Visio 2000 Feb 22 2004 Feb 29 2004 Mar 7 2004 ID Task Name Start End Duration 23 24 25 26 27 28 29 1 2 3 4 5 6 7 8 9 10 11 GÆp gì kh¸ch 1 2/23/2004 2/24/2004 2d hµng 2 Ph©n tÝch yªu cÇu 2/25/2004 2/26/2004 2d 3 §Æc t¶ yªu cÇu 2/27/2004 2/27/2004 1d 4 Ph©n tÝch hÖ thèng 3/1/2004 3/3/2004 3d 5 ThiÕt kÕ tæng thÓ 3/4/2004 3/10/2004 5d 6 64
63. Timeline tạobằng Visio 2000 65
64. Tổng kết: Quảnlýdự án z Ngườiquảnlýcần có kinh nghiệm, phảicứng rắn − Đượctrangbị kiếnthứcvề quảnlýdự án PM − Có thâm niên trong việc phát triểnphầnmềm ƒ Đãtừng tham gia các công đoạncủa quá trình phát triển phầnmềm ƒ Kinh nghiệm đóng vai trò then chốt ƒ Có trình độ quảnlýtốt ƒ Làm việccókế hoạch ƒ z Cầncócácđộ đo z Phải đượclậptàiliệu z Luôn cầnxemxét, điềuchỉnh 67