Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 2: Nền tảng của sự thay đổi phần mềm - Nguyễn Thị Thanh Trúc

Nội dung text: Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 2: Nền tảng của sự thay đổi phần mềm - Nguyễn Thị Thanh Trúc

1. TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM PHÁT TRIỂN VẬN HÀNH BẢO TRÌ PHẦN MỀM ThS. NGUYỄN THỊ THANH TRÚC Khoa Công Nghệ Phần Mềm UIT-VNUHCM 2009 1
2. Nội dung (Chương 2) Nền tảng của sự thay đổi phần mềm Mối liên quan kinh tế của việc cập nhật phần mềm Giải pháp tiềm năng đối với vấn đề bảo trì Thảo luận và làm bài tập Q&A UIT-VNUHCM 2009 Company Logo 2
3. Chương 2: NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM 2.1 Nền tảng của sự thay đổi phần mềm 2.2 Mối liên quan kinh tế của việc cập nhật phần mềm 2.3 Giải pháp tiềm năng đối với vấn đề bảo trì UIT-VNUHCM 2009 3
4. Chương 2: NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM 1. NỀN TẢNG SỰ THAY ĐỔI PHẨN MỀM o Sự thay đổi phần mềm o Phân loại sự thay đổi ü Corrective Change (Thay đổi hiệu chỉnh) ü Adaptive Change (Thay đổi thích nghi) 2. MỐI LIÊN HỆ KINH TẾ CỦA ViỆC CẬP NHẬT PHẦN MỀM o Giới hạn đối với sự thay đổi o Hạn chế tài nguyên o Chất lượng của hệ thống tồn tại o Chiến lược tổ chức o Tính trì trệ (không thay đổi) 3. GiẢI PHÁP TiỀM NĂNG ĐỐI VỚI VẤN ĐỀ BẢO TRÌ o cấp phát Ngân sách và Nỗ lực (Effort) o Hoàn chỉnh thay thế hệ thống o Bảo trì hệ thống tồn tại UIT-VNUHCM 2009 4
5. 2.1 NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM qSự thay đổi phần mềm o Tiến hoá phần mềm üLoại phần mềm üLuật tiến hoá qPhân loại những thay đổi o Thay đổi hiệu chỉnh (Corrective Change) o Thay đổi thích nghi (Adaptive Change) o Thay đổi hoàn chỉnh (Perfective Change) o Thay đổi ngăn ngừa (Preventive Change) UIT-VNUHCM 2009 5
6. Luật đầu tiên của Công nghệ phần mềm “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle” Bersoff et al. (1980) UIT-VNUHCM 2009 6
7. Nguồn của sự thay đổi qNhững điều kiện kinh doanh và thị trường mới gây ra thay đổi những yêu cầu sản phẩm và qui tắc nghiệp vụ (business rules) qKhách hàng mới cần thay đổi nhu cầu dữ liệu, chức năng hay dịch vụ phân phối bởi hệ thống qTái tổ chức hay cắt giảm kinh doanh mà thay đổi ưu tiên và cấu trúc nhóm (team) qRàng buộc ngân sách và lịch trình gây ra tái định nghĩa hệ thống qHẦU HẾT SỰ THAY ĐỔI LÀ CÓ LÝ DO CHÍNH ĐÁNG UIT-VNUHCM 2009 7
8. Bảo trì và SDLC qQui trình phát triển phần mềm Waterfall, chúng ta có hộp ở mỗi cuối qui trình và được bỏ qua trong mô tả qui trình qChu trình cải tiến hơn như Spiral Model,bảo trì phù hợp nhiều vị trí nổi bật qBảo trì vẫn liên quan đến khía cạnh của SDLC qVí dụ: Pressman không có chương cụ thể về Bảo Trì, Somerville có 15 trang trong 742 trang UIT-VNUHCM 2009 8
9. Loại chương trình q Chương trình S-type (“Specifiable”) Source: Adapted from Lehman 1980, pp1061-1063 o Vấn đề được khẳng định hình thức và hoàn chỉnh o Chấp nhận: Chương trình có chính xác như đặc tả của nó? o Phần mềm này không tiến triển. ü Thay đổi đặc tả định nghĩa vấn đề mới, như vậy một chương trình mới q Chương trình P-type (“Problem-solving”) o Khẳng định không chính xác vấn đề thế giới thực o Chấp nhận: Chương trình là giải pháp có thể chấp nhận đối với vấn đề? o Phần mềm này xem như tiến triển liên tục ü Bởi giải pháp không bao giờ hoàn hảo, và có thể cải tiến ü Bởi thế giới thực thay đổi và vấn đề thay đổi q Chương trình E-type (“Embedded”) o Một hệ thống trở thành một phần thế giới nó được mô hình hoá o Chấp nhận: phụ thuộc toàn bộ vào ý kiến và phán xét o Phần mềm này vốn đã tiến hoá ü Thay đổi trong phần mềm và thế giới tác động lẫn nhau UIT-VNUHCM 2009 9
10. Source: Adapted from Lehman 1980, pp1061-1063 formal may statement controls the relate of problem production P-type to of change real world real PROGRAM world abstract view of world provides maybe of solution interest to S-type compare change requirements specification E-type real world change solution PROGRAM PROGRAM abstract requirements view of world specification model UIT-VNUHCM 2009 10
11. Loại Bảo trì qLàm thế nào và tại sao chúng ta tốn khá nhiều thời gian và nỗ lực cho việc bảo trì? qBảo trì thì nhiều vấn đề hơn việc fix bug qPhân chi thành ba loại chính o Corrective Maintenance (bảo trì hiệu chỉnh) o Adaptive Maintenance (Bảo trì thích nghi) o Perfective Maintenance (Bảo trì hoàn chỉnh) qRanh giới giữa các loại bảo trì khá mờ không rõ qChúng ta có thể định nghĩa các loại bảo trì khác – bảo trì ngăn ngừa UIT-VNUHCM 2009 11
12. Các loại bảo trì Corrective Maintenance Source: Adapted from van Vliet, 1999, p449. fixing latent errors includes temporary patches and workarounds other efficiency Adaptive Maintenance perfective responding to external changes corrective changes in hardware platform changes in support software user Perfective Maintenance enhancements adaptive improving the as-delivered software user enhancements efficiency improvements Preventative Maintenance Improves (future) maintainability preventative Documenting, commenting, etc. UIT-VNUHCM 2009 12
13. Bảo trì hiệu chỉnh (Corrective Maintenance) qTập trung vào fix lỗi qLà qui trình có phản ứng lại o Lỗi và lỗi kết hợp nói chung cần được chính xác ngay lập tức hay trong tương lai gần qLỗi biến đổi theo chi phí để hiệu chỉnh: o Coding – thường tương đối rẻ o Design – Khá tốn kém khi chúng có thể đòi thay đổi vài thành phần chương trình o Requirements – Tốn kém nhất – có lẽ đòi tái thiết kế hệ thống mở rộng qThiết kế và Yêu cầu là nguồn chiếm khoảng 80% lỗi UIT-VNUHCM 2009 13
14. Bảo trì hiệu chỉnh (2) qHiệu chỉnh lỗi có 20 đến 50% cơ hội đưa ra lỗi khác qNguyên nhân lỗi mới gồm : o Dấu vết tác động nơi mà sự thay đổi ở một nơi gây ra sự thay đổi vùng dường như không liên quan o Người sửa lỗi nói chung không phải là người viết code hay thiết kế hệ thống qHai loại bảo trì hiệu chỉnh o Sửa chữa khẩn cấp – thời gian ngắn- thường chương trình đơn, lỗi cần được sửa sớm như có thể o Sữa chữa theo lịch trình - lỗi không cần chú ý ngay, kiểm tra lại tất cả sữa chữa khẩn cấp UIT-VNUHCM 2009 14
15. Bảo trì thích nghi (Adaptive Maintenance) qTiến hoá hệ thống nhằm đạt nhu cầu người dùng và doanh nghiệp qGây ra bởi o Nhu cầu nội bộ o Canh trạnh bên ngoài o Những yêu cầu ngoài ví dụ thay đổi Luật qCần thiết đưa ra những yêu cầu mới cho hệ thống qNhư vậy chúng ta nên xử lý giống như phát triển mới theo hướng tiếp cận và phương pháp UIT-VNUHCM 2009 15
16. Bảo trì hoàn chỉnh (Perfective Maintenance) qThành ngữ xưa “Nếu không hỏng, thì không sửa nó” qBảo trì hoàn chỉnh bỏ qua câu thành ngữ xưa qCải thiện chất lượng chương trình sẳn sàng hoạt động qMục tiêu đạt được o Giảm chi phí trong sử dụng hệ thống o Tăng khả năng bảo trì hệ thống o Gần hơn nhu cầu người dùng UIT-VNUHCM 2009 16
17. Bảo trì hoàn chỉnh (2) qGồm tất cả nỗ lực để trau chuốt hay cải tiến chất lượng phần mềm và sưu liệu qImportant that the potential benefits of the perfective maintenance outweigh o Chi phí của bảo trì o Và chi phí cơ hội của cải tiến nơi khác hay dùng tài nguyên trong phát triển mới qNhư vậy, trước khi thực hiện bảo trì hoàn chỉnh,đầu tiên nên qua tiến trình phân tích qTuy nhiên, bảo trì hoàn chỉnh bé có thể những ảnh hưởng UIT-VNUHCM 2009 17
18. Bảo trì ngăn ngừa (Preventative Maintenance) qCó thể thấy như bảo trì hoàn chỉnh mức cơ bản hay một sự lựa chọn để bảo trì qĐược biết như Software Re-engineering qNắm giữ hệ thống và chuyển đổi cấu trúc hay chuyển đổi thành ngôn ngữ mới qHệ thống cữ bắt đầu như đặc tả cho hệ thống mới qPhương pháp chung được biết như vỏ bọc mà toàn hệ thống được thay bởi vỏ bọc OO và được xử lý như đối tượng lớn UIT-VNUHCM 2009 18
19. Sự lựa chọn để bảo trì qĐôi khi, bảo trì không thoả mãn chính nó qTái cấu trúc không hoàn chỉnh tích hợp với bảo trì thích nghi o Dùng để cải tiến có thứ tự với mỗi phiên bản hệ thống qHoàn chỉnh sắp xếp lại hoặc xem xét toàn bộ code toàn tại o Dùng hệ thống thiên về bảo trì mức độ cao UIT-VNUHCM 2009 19
20. Chọn lựa để bảo trì (2) qHoàn chỉnh tái thiết kế và viết lại o Dùng khi nhiều hơn 20% chương trình phải thay đổi o Dùng khi chương sẽ được nâng cấp cho công nghệ mới o Không dùng khi thiết kế và và chức năng của hệ thống không được biết qTừ bỏ hệ thống và hoàn chỉnh tái phát triển o Dùng khi chuyển qua công nghệ mới o Dùng khi chi phí bảo trì phần mềm và phần cứng đạt đến chi phí của tái phát triển UIT-VNUHCM 2009 20
21. Mối liên hệ giữa các loại thay đổi phần mềm UIT-VNUHCM 2009 21
22. Qui trình Bảo trì Đây là qui trình lý tưởng, thường không đạt đến Change requests System Change Impact Change System release management analysis implementation release planning Perfective Adaptive Corrective maintenance maintenance maintenance UIT-VNUHCM 2009 22
23. Qui trình bảo trì (2) qQuản lý sự thay đổi o Nhận diện duy nhất, mô tả, lưu vết những trạng thái của tất cả yêu cầu qPhân tích tác động o Nhận diện tất cả hệ thống và sản phẩm tác động yêu cầu thay đổi o Thực hiện ước tính tài nguyên cần thiết tác động thay đổi o Phân tích lợi ích thay đổi qLập kế hoạch phiên bản (Release Planning) o Thiết lập lịch biểu và nội dụng của một phiên bản hệ thống o Không muốn mỗi yêu cầu thay đổi được thực hiện khi chúng được xử lý UIT-VNUHCM 2009 23
24. Qui trình Bảo trì phần mềm (3) qThực hiện sự thay đổi o Thay đổi thiết kế o Coding o Kiểm thử Testing – phải thực hiện regression testing qPhiên bản hệ thống bao gồm o Sưu liệu o Phần mềm o Huấn luyện o Thay đổi phần cứng o Chuyển đổi dữ liệu UIT-VNUHCM 2009 24
25. Sơ đồ tổ chức bảo trì phần mềm UIT-VNUHCM 2009 25
26. Vai trò và tổ chức bảo trì phần mềm UIT-VNUHCM 2009 26
27. OnGoing Support qTruyền thông hiệu quả o Thiết lập mối liên hệ tốt với khách hàng o Hiểu rõ nhu cầu khác hàng o Tránh ra quyết định trái ngược yêu cầu khách hàng qHuấn luyện end-user o Hỗ trợ người dùng dễ dàng hiểu, ex: phone online queries qCung cấp thông tin kinh doanh o Thông tin chính xác để thể hỗ trợ ra quyết đinh chiến lược UIT-VNUHCM 2009 27
28. Các luật của Tính tiến hoá chương trình Source: Adapted from Lehman 1980, pp1061-1063. See also, van Vliet, qContinuing Change 1999, Pp59-62 o Any software that reflects some external reality undergoes continual change or becomes progressively less useful üThe change process continues until it is judged more cost effective to replace the system entirely qIncreasing Complexity o As software evolves, its complexity increases ü unless steps are taken to control it. qFundamental Law of Program Evolution o Tiến hoá của phần mềm là qui định tự nó với hướng có thể xác định và không thay đổi theo thống kê qConservation of Organizational Stability o Trong suốt hoạt động thực sự của hệ thống phần mềm, đầu ra công việc của một dự án phát triển là gần không đổi (xem như tài nguyên) qConservation of Familiarity o Trong suốt hoạt động thực sự của một chương trình số lượng thay đổi trong những phiên bản kế tiếp gần không đổi UIT-VNUHCM 2009 28
29. 2.2 MỐI LIÊN HỆ KINH TẾ CỦA ViỆC CẬP NHẬT PHẦN MỀM qGiới hạn đối với sự thay đổi qHạn chế tài nguyên qChất lượng của hệ thống tồn tại qChiến lược tổ chức qTính trì trệ (không thay đổi) UIT-VNUHCM 2009 29
30. Chi phí bảo trì qMột nghiên cứu đưa ra o Định nghĩa yêu cầu 3% o Thiết kế sơ bộ 3% o Thiết kế mức chi tiết 5% o Thực thi 7% o Kiểm thử 15% o Bảo trì 67% qNghiên cứu khác đưa ra ít nhất 50% nỗ lực chi cho bảo trì qNghiên cứu khá tìm thấy khoảng giữa 65% và 75% cho bảo trì qNhững hệ thống nhúng thời gian thực, chi phí bảo chỉ chiếm gấp 4 lần chi phí phát triển UIT-VNUHCM 2009 30
31. Tại sao bảo trì tốn kém ? qHầu hết phần mềm có từ 10 and 15 năm qNhiều phần mềm chỉ tuổi nó được tạo bởi kích thước chương trình và không gian lưu trữ là những yêu tố quan trọng hơn qĐiều này dẫn đến không thay đổi thiết kế, code, và sưu liệu qBảo trì được thực hiện bởi đội ngũ không có kinh nghiệm và không quen với ứng dụng qNgười phát triển không thích bảo trì qThay đổi thường gây ra lỗi mới trong hệ thống qThay đổi hướng làm manh mún cấu trúc chương trình qThay đổi thường không được ghi sưu liệu UIT-VNUHCM 2009 31
32. Yếu tố tác động đến chi phí bảo trì qTính độc lập module o Khả năng thay đổi một phần hệ thống o Thuận lợi tiềm năng của OO qNgôn ngữ lập trình o Mức độ ngôn ngữ lập trình càng cao, càng bảo trì rẻ hơn o C – ngôn ngữ chữ viết :-) qKiểu chương trình o Cách thức một chương trình được viết qĐánh giá và kiểm thử chương trình o Càng nhiều thời gian và nỗ lực chi cho đánh giá thiết kế và chương trình, lỗi càng ít và nhu cầu bảo trì hiệu chỉnh càng ít hơn UIT-VNUHCM 2009 32
33. Yếu tố tác động đến chi phí bảo trì (2) qChất lượng sưu liệu chương trình o Sưu liệu càng tốt, việc bảo trì càng dễ dàng qKỹ thuật quản lý cấu hình o Lưu vết tất cả tài liệu hệ thống và đảm bảo chúng phù hợp thì chi phí chính của bảo trì, như vậy công cụ quản lý cấu hình (CM tools) và thực tế giảm chi phí này qPhạm vi ứng dụng o Càng ít hiểu phạm vi được hiểu kỹ, the less well- understood the domain, nhu cầu có thể xảy ra càng lớn cho bảo trì thích nghi như người dùng và người phát triển bắt đầu hiểu phạm vi qỔn định đội ngũ o Chi phí bảo trì giảm nếu người phát triển phải bảo trì chính hệ thống của họ, thường qua chu kỳ sống của hệ thống UIT-VNUHCM 2009 33
34. Yếu tố tác động đến chi phí bảo trì (3) qTuổi hệ thống o Hệ thống càng cũ, càng nhiều mức độ manh mún và khó bảo trì o Lôi cuốn đội ngũ người biết hệ thống cũ ngôn ngữ, DB, vận hành trở nên khó hơn và nhiều kinh nghiệm qPhù thuộc hệ thống và môi trường ngoài o Sự phụ thuộc càng cao,càng nhiều bảo trì thích nghi được cần qĐộ ổn định phần cứng o Nếu platform phần cứng sẽ không thay đôi qua thời gian hệ thống, bảo trì cho nguyên nhân này sẽ không cần UIT-VNUHCM 2009 34
35. Khác nhau giữa Bảo trì và Phát triển mới qRàng buộc của hệ thống tồn tại o Thay đổi phải phù hợp hay tương thích với kiến trúc tồn tại, thiết kế, ràng buộc mã nguồn qKhung thời gian ngắn hơn o Phát triển khoảng 6 tháng trở lên o Bảo trì tính giờ hay ngày cho đến 6 tháng qTính sẵn sàng dữ liệu kiểm thử o Phát triển tạo tất cả dữ liệu từ hỗn tạp o Bảo trì dùng dữ liệu kiểm tra tồn tại với regression testing, tạo dữ liệu mới từ sự thay đổi UIT-VNUHCM 2009 35
36. Bài tập & Thảo luận (1) qBài tập 3.1 Mô tả những thay đổi khác nhau mà sản phẩm phần mềm trải qua và chỉ ra lý do cơ bản cho mỗi loại qBài tập 3.2 : Giải thích tại sao cho là quan trọng để phân biệt giữa những loại khác nhau của sự thay đổi phần mềm UIT-VNUHCM 2009 36
37. Bài tập & Thảo luận (2) qBài tập 3.3 Ongoing support không được cho là cần thiết dẫn đến sự thay đổi của chương trình như vậy nó nên xem là một phần của bảo trì không?. Ý kiến của bạn là gì. qBài tập 4.1: Chọn gói phần mềm (software package) đã biết liên quan nhiều version. Liệt kê những thay đổi đã được thực hiện trong những version khác nhau. Có những Rào cản gì trong thực hiện những chức năng cụ thể này trong những version. UIT-VNUHCM 2009 37
38. 2.3 GiẢI PHÁP TiỀM NĂNG ĐỐI VỚI VẤN ĐỀ BẢO TRÌ qTái cấp phát Ngân sách và Nỗ lực (Effort) o Ít tài nguyên để phát triển cho hệ thống khó bảo tri và khó, ngược lại đầu tư nhiều cho phát triển, đặc tả và thiết kế với hệ thống có thể bảo trì o Sử dụng nhiều đặc tả yêu cầu thiết kế trước đã phê duyệt, kỹ thuật thiết kế, công cụ, chất lượng đảm bảo tiêu chuẩn ISO làm hệ thống có thể bảo trì hơn qHoàn chỉnh thay thế hệ thống o Ràng buộc kinh tế o Lỗi thường trú trong hệ thống mới o Cơ sở dữ liệu của thông tin qBảo trì hệ thống tồn tại UIT-VNUHCM 2009 38
39. Những vấn đề đối mặt của người bảo trì q5 vấn đề hàng đầu: Source: Adapted Pfleeger 1998, p423-424. See also, van Vliet, 1999, pp464-467 o (Kém) Chất lượng sưu liệu o Nhu cầu người dùng cho việc cải tiến và mở rộng o Nhu cầu đối đầu thời gian người bảo trì o Khó khăn trong trong buổi họp cam kết lịch trình o Doanh thu trong tổ chức người dùng qSự hiểu biết hạn chế o 47% nỗ lực bảo trì phần mềm dành cho hiểu phần mềm üThí dụ: nếu một hệ thống có m thành phần và chúng ta cần thay đổi k trong chúng ü Có k*(m-k) + k*(k-1)/2 giao diện kiểm tra tác động o Cùng , >50% nỗ lực đóng góp cho sự thiếu hiểu biết của người dùng üI.e. báo cáo không hoàn chỉnh và sai lầm của lỗi và cải tiến qTinh thần Thấp o Bảo trì phần mềm được xem xét như ít thích thú hơn việc phát triển UIT-VNUHCM 2009 39
40. Cách tiếp cận bảo trì qTriết lý bảo trì Source: van Vliet,1999, pp473-475 o “throw-it-over-the-wall” – người nào khác chịu trách nhiệm cho bảo trì üĐầu tư kiến thức và kinh nghiệm là uổng phí üBảo trì trở thành thách thức reverse engineering o “mission orientation” – nhóm phát triển thực hiện cam kết giới hạn để bảo trì phần mềm qMô hình qui trình bảo trì của Basili: o Quick-fix model üThay đổi làm ở mức lập trình (code) dễ dàng có thể üPhân rã (manh mún) nhanh cấu trúc của phần mềm o Iterative enhancement model üThay đổi thực hiện dựa trên phân tích hệ thống tồn tại üCố gắng kiểm soát độ phức tạp và duy trì thiết kết tốt o Full-reuse model üBắt đầu bằng những yêu cầu hệ thống mới, tái sử dụng nhiều như có thể üCần tăng trưởng văn hoá dùng lại để thành công UIT-VNUHCM 2009 40
41. Làm trẻ lại phần mềm (Software Rejuvenation) qRedocumentation Source: van Vliet, 1999, Pp455-457 o Tạo hay xem lại những thể hiện sự thay đổi phần mềm üTại cùng mức độ của trừu tượng hoá o Phát sinh : üBảng giao diện dữ liệu, đồ hình gọi hàm, thành phần/biến qua bảng tham chiếu etc. qRestructuring o Chuyển dịch phần code của hệ thống mà không thay đổi hành vi qReverse Engineering o Phân tích hệ thống để chính xác thông tin về hành vi hay cấu trúc üCũng khôi phục thiết kế - Tạo lại trừu tượng thiết kế từ code, tài liệu, và kiến thức phạm vi o Phát sinh: üSơ đồ cấu trúc, lược đồ quan hệ thực thể, DFD, mô hình yêu cầu qReengineering o Kiểm tra và thông báo hệ thống khôi phục nó trong hình thức khác o Cũng cần biết như nâng cấp, phân loại lại UIT-VNUHCM 2009 41
42. Reuse qDùng lại phần mềm để cắt giảm chi phí Source: van Vliet, 1999, Chapter 17 o Phát triển phần mềm tốn kém, vì vậy dùng lại cho những hệ thống liên quan üHướng tiếpcận thành công tập trung sử dụng lại tri thức và kinh nghiệm hơn sản phẩm phần mềm üTính kinh tế việc dùng lại là phức tạp khi nó tốn nhiều hơn để phát triển reusable software qThư viện của thành phần có thể sử dụng lại o Thư viện phạm vi cụ thể (e.g. Math libraries) o Thư viện phát triển chương trình (e.g. Java AWT, C libraries) qDomain Engineering o Phân chia phát triển phần mềm thành 2 phần : üPhân tích phạm vi – nhận diện thành phần dùng lại có chung đặc điểm cho một phạm vi vấn đề üPhát triển ứng dụng – dùng thành phần phạm vi cho ứng dụng cụ thể. qHọ phần mềm o Nhiều công ty đề nghị dãy các hệ thống phần mềm liên quan üChọn kiến trúc ổn định cho họ phần mềm üNhận diện sự đa dạng cho những thành viên khác nhau trong họ o Thể hiện quyết định chiến lược kinh doanh về phần mềm gì để phát triển UIT-VNUHCM 2009 42
43. Thúc đẩy đội ngũ bảo trì qThường xem xét đến dead-end trong tổ chức cũng như sự chán nản qQuyết định đến sự thành công của tổ chức qChiến lược có thể o Cặp mục tiêu phần mềm và mục đích của tổ chức o Cặp Phần thưởng bảo trì phần mềm với thực hiện tổ chức o Tích hợp nhân sự bảo trì phần mềm với nhóm vận hành o Tạo biện pháp, hoàn chỉnh/ngăn ngừa, ngân sách bảo trì cho phép nhóm bảo trì quyết định khi re-engineer hệ thống o Lối kéo độ ngũ bảo trì sớm trong qui trình phần mềm trong suốt chuẩn bị qui chuẩn, review, và chuẩn bị kiểm thử UIT-VNUHCM 2009 43
44. Tài liệu tham khảo qvan Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)” Wiley, 1999. oChapter 14 is a very good introduction to the problems and approaches to software maintenance. Chapter 17 covers software reuse in far more detail than we’ll go into on this course. qLehman, M.M. “Programs, Life Cycles, and Laws of Software Evolution”. Proceedings of the IEEE, vol 68, no 9, 1980. oLehman was one of the first to recognise that software evolution is a fact of life. His experience with a number of large systems led him to formulate his laws of evolution. This paper is included in the course readings. It is widely cited. qPfleeger, S. L. “Software Engineering: Theory and Practice” Prentice Hall, 1998. oPfleeger’s chapter 10 provides some additional data on the costs of maintenance. UIT-VNUHCM 2009
45. Yêu cầu thực hiện tuần tiếp theo qNộp báo cáo các bài tập làm trên lớp (* ) qTìm hiểu và minh hoạ các công cụ (tools) quản lý sự thay đổi (*) qChuẩn bị các bài đăng ký dịch theo ebook Thi Giữa kỳ qChuẩn bị các thuyết minh và chương trình để họp với nhóm khách hàng -> ghi nhận yêu cầu, thay đổi (xem template Report1.pdf và Report2.pdf qNHóm khách hàng (customer group): bắt cặp ngược theo thứ tự nhóm đã được cho ?, và ngược lại qHai nhóm sẽ có đại diện để trao đổi ghi nhận thông tin, trao đổi thông tin với nhau thông qua group link của nhau. qLưu ý :(*) Nộp tuần tiếp theo trước khi ngày học lý thuyết, bắt buộc, không nộp trừ điểm UIT-VNUHCM 2009 45