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 cung cấp cho người học các kiến thức: 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ì. Mời các bạn cùng tham khảo.
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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Nội dung (Chương 2) Nền tảng thay đổi phần mềm Mối liên quan kinh tế việc cập nhật phần mềm Giải pháp tiềm vấn đề bảo trì Thảo luận làm tập Q&A UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Company Logo Chương 2: NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM 2.1 Nền tảng thay đổi phần mềm 2.2 Mối liên quan kinh tế việc cập nhật phần mềm 2.3 Giải pháp tiềm vấn đề bảo trì UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Chương 2: NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM NỀN TẢNG SỰ THAY ĐỔI PHẨN MỀM o Sự thay đổi phần mềm o Phân loại thay đổi Corrective Change (Thay đổi hiệu chỉnh) Adaptive Change (Thay đổi thích nghi) MỐI LIÊN HỆ KINH TẾ CỦA ViỆC CẬP NHẬT PHẦN MỀM o o o o o Giới hạn thay đổi Hạn chế tài nguyên Chất lượng hệ thống tồn Chiến lược tổ chức Tính trì trệ (khơng thay đổi) 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 Nỗ lực (Effort) o Hoàn chỉnh thay hệ thống o Bảo trì hệ thống tồn UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt 2.1 NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM Sự 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á Phân loại thay đổi o o o o Thay đổi hiệu chỉnh (Corrective Change) Thay đổi thích nghi (Adaptive Change) Thay đổi hoàn chỉnh (Perfective Change) Thay đổi ngăn ngừa (Preventive Change) Tầm quan trọng việc phân loại Cho ví dụ cho loại? UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Định nghĩa E-type system o the criteria for acceptability is based on its performance in a real world situation S-type system o the criteria for acceptability is that it is correct relative to an absolute specification On-going support o a service offered to customers to assist their continuing use of a product Ripple effect o consequences of an action in one place, occurring elsewhere UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Luật 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Nguồn thay đổi Những điều kiện kinh doanh thị trường gây thay đổi yêu cầu sản phẩm qui tắc nghiệp vụ (business rules) Khách hàng cần thay đổi nhu cầu liệu, chức hay dịch vụ phân phối hệ thống Tái tổ chức hay cắt giảm kinh doanh mà thay đổi ưu tiên cấu trúc nhóm (team) Ràng buộc ngân sách lịch trình gây tái định nghĩa hệ thống HẦU HẾT SỰ THAY ĐỔI LÀ CĨ LÝ DO CHÍNH ĐÁNG UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Thay đổi hiệu chỉnh (Corrective Change) Thay đổi hiệu chỉnh ám đến cập nhật khởi nguồn từ dò lỗi phần mềm Dò lỗi kết từ lỗi thiết kế, lỗi logic hay lỗi chương trình o Lỗi thiết kế (Design) Thay đổi khơng xác, hồn chỉnh, truyền thơng sai lệch hay yêu cầu thay đổi hiểu nhầm o Lỗi logic Kết từ kiểm thử không hợp lệ, liệu thử, thực thi không thiết kế, lỗi luồng logic o Lỗi cài đặt (coding) Gây thực thi khơng xác thiết kế chi tiết mức logic sử dùng khơng xác logic chương trình nguồn UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt Thay đổi thích nghi (Adaptive change) Để thích nghi phần mềm với thay đổi môi trường Kết khởi nguồn từ loại bỏ software, hardware khác biệt, phần mềm nền, trình biên dịch, hệ điều hành Kết từ thay đổi máy ảo (virtual machine), thêm tiện ích cho hệ điều hành, lưu không gian đĩa, khôi phục cố lỗi Thay đổi hệ thống phần mềm liên quan khu vực (areas), ví dụ: giao dịch ngân hàng, kinh doanh UIT-VNUHCM 2009 10 CuuDuongThanCong.com https://fb.com/tailieudientucntt Tại bảo trì tốn ? Hầu hết phần mềm có từ 10 and 15 năm Nhiều phần mềm tuổi tạo kích thước chương trình khơng gian lưu trữ yêu tố quan trọng Điều dẫn đến không thay đổi thiết kế, code, sưu liệu Bảo trì thực đội ngũ khơng có kinh nghiệm không quen với ứng dụng Người phát triển không thích bảo trì Thay đổi thường gây lỗi hệ thống Thay đổi hướng làm manh mún cấu trúc chương trình Thay đổi thường khơng ghi sưu liệu UIT-VNUHCM 2009 51 CuuDuongThanCong.com https://fb.com/tailieudientucntt Yếu tố tác động đến chi phí bảo trì Tính độc lập module o Khả thay đổi phần hệ thống o Thuận lợi tiềm OO Ngơn ngữ lập trình o Mức độ ngơn ngữ lập trình cao, bảo trì rẻ o C – ngơn ngữ chữ viết :-) Kiểu chương trình o Cách thức chương trình viết Đánh giá kiểm thử chương trình o Càng nhiều thời gian nỗ lực chi cho đánh giá thiết kế chương trình, lỗi nhu cầu bảo trì hiệu chỉnh UIT-VNUHCM 2009 52 CuuDuongThanCong.com https://fb.com/tailieudientucntt Yếu tố tác động đến chi phí bảo trì (2) Chất lượng sưu liệu chương trình o Sưu liệu tốt, việc bảo trì dễ dàng Kỹ thuật quản lý cấu hình o Lưu vết tất tài liệu hệ thống đảm bảo chúng phù hợp chi phí bảo trì, cơng cụ quản lý cấu hình (CM tools) thực tế giảm chi phí Phạm vi ứng dụng o Càng hiểu phạm vi hiểu kỹ, the less wellunderstood the domain, nhu cầu xảy lớn cho bảo trì thích nghi người dùng người phát triển bắt đầu hiểu phạm vi Ổn định đội ngũ o Chi phí bảo trì giảm người phát triển phải bảo trì hệ thống họ, thường qua chu kỳ sống hệ thống UIT-VNUHCM 2009 53 CuuDuongThanCong.com https://fb.com/tailieudientucntt Yếu tố tác động đến chi phí bảo trì (3) Tuổi hệ thống o Hệ thống cũ, nhiều mức độ manh mún khó bảo trì o Lơi đội ngũ người biết hệ thống cũ ngơn ngữ, DB, vận hành trở nên khó nhiều kinh nghiệm Phù thuộc hệ thống mơi trường ngồi o Sự phụ thuộc cao,càng nhiều bảo trì thích nghi cần Độ ổn định phần cứng o Nếu platform phần cứng không thay đôi qua thời gian hệ thống, bảo trì cho nguyên nhân không cần UIT-VNUHCM 2009 54 CuuDuongThanCong.com https://fb.com/tailieudientucntt Khác Bảo trì Phát triển Ràng buộc hệ thống tồn 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 Khung thời gian ngắn o Phát triển khoảng tháng trở lên o Bảo trì tính hay ngày tháng Tính sẵn sàng liệu kiểm thử o Phát triển tạo tất liệu từ hỗn tạp o Bảo trì dùng liệu kiểm tra tồn với regression testing, tạo liệu từ thay đổi UIT-VNUHCM 2009 55 CuuDuongThanCong.com https://fb.com/tailieudientucntt Bài tập & Thảo luận (1) Bài tập 3.1 Mô tả thay đổi khác mà sản phẩm phần mềm trải qua lý cho loại Bài tập 3.2 : Giải thích cho quan trọng để phân biệt loại khác thay đổi phần mềm UIT-VNUHCM 2009 56 CuuDuongThanCong.com https://fb.com/tailieudientucntt Bài tập & Thảo luận (2) Bài tập 3.3 Ongoing support không cho cần thiết dẫn đến thay đổi chương trình nên xem phần bảo trì khơng? Ý kiến bạn Bà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ê thay đổi thực version khác Có Rào cản thực chức cụ thể version UIT-VNUHCM 2009 57 CuuDuongThanCong.com https://fb.com/tailieudientucntt 2.3 GiẢI PHÁP TiỀM NĂNG ĐỐI VỚI VẤN ĐỀ BẢO TRÌ Tái cấp phát Ngân sách Nỗ lực (Effort) o Ít tài nguyên để phát triển cho hệ thống khó bảo tri khó, ngược lại đầu tư nhiều cho phát triển, đặc tả thiết kế với hệ thống 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 bảo trì Hồn chỉnh thay hệ thống o Ràng buộc kinh tế o Lỗi thường trú hệ thống o Cơ sở liệu thông tin Bảo trì hệ thống tồn UIT-VNUHCM 2009 58 CuuDuongThanCong.com https://fb.com/tailieudientucntt Những vấn đề đối mặt người bảo trì 5 vấn đề hàng đầu: o (Kém) Chất lượng sưu liệu o o o o Source: Adapted Pfleeger 1998, p423-424 See also, van Vliet, 1999, pp464-467 Nhu cầu người dùng cho việc cải tiến mở rộng Nhu cầu đối đầu thời gian người bảo trì Khó khăn trong buổi họp cam kết lịch trình Doanh thu tổ chức người dùng Sự 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ụ: hệ thống có m thành phần cần thay đổi k 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 thiếu hiểu biết người dùng I.e báo cáo khơng hồn chỉnh sai lầm lỗi cải tiến Tinh thần Thấp o Bảo trì phần mềm xem xét thích thú việc phát triển UIT-VNUHCM 2009 59 CuuDuongThanCong.com https://fb.com/tailieudientucntt Cách tiếp cận bảo trì Triết lý bảo trì Source: van Vliet,1999, pp473-475 o “throw-it-over-the-wall” – người khác chịu trách nhiệm cho bảo trì Đầu tư kiến thức kinh nghiệm 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 cam kết giới hạn để bảo trì phần mềm Mơ hình qui trình bảo trì Basili: o Quick-fix model Thay đổi làm mức lập trình (code) dễ dàng Phân rã (manh mún) nhanh cấu trúc phần mềm o Iterative enhancement model Thay đổi thực dựa phân tích hệ thống tồn Cố gắng kiểm sốt độ phức tạp trì thiết kết tốt o Full-reuse model Bắt đầu yêu cầu hệ thống mới, tái sử dụng nhiều Cần tăng trưởng văn hố dùng lại để thành cơng UIT-VNUHCM 2009 60 CuuDuongThanCong.com https://fb.com/tailieudientucntt Làm trẻ lại phần mềm (Software Rejuvenation) Redocumentation Source: van Vliet, 1999, Pp455-457 o Tạo hay xem lại thể thay đổi phần mềm Tại mức độ trừu tượng hoá o Phát sinh : Bảng giao diện liệu, đồ hình gọi hàm, thành phần/biến qua bảng tham chiếu etc Restructuring o Chuyển dịch phần code hệ thống mà khơng thay đổi hành vi Reverse Engineering o Phân tích hệ thống để xác thơng tin 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, 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 u cầu Reengineering o Kiểm tra thơng báo hệ thống khơi phục hình thức khác o Cũng cần biết nâng cấp, phân loại lại UIT-VNUHCM 2009 61 CuuDuongThanCong.com https://fb.com/tailieudientucntt Reuse Dù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, dùng lại cho 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 kinh nghiệm sản phẩm phần mềm Tính kinh tế việc dùng lại phức tạp tốn nhiều để phát triển reusable software Thư viện thành phần 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) Domain Engineering o Phân chia phát triển phần mềm thành 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 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ể Họ phần mềm o Nhiều công ty đề nghị dãy 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 đa dạng cho thành viên khác họ o Thể định chiến lược kinh doanh phần mềm để phát triển UIT-VNUHCM 2009 CuuDuongThanCong.com https://fb.com/tailieudientucntt 62 Thúc đẩy đội ngũ bảo trì Thường xem xét đến dead-end tổ chức chán nản Quyết định đến thành công tổ chức Chiến lược Cặp mục tiêu phần mềm mục đích tổ chức Cặp Phần thưởng bảo trì phần mềm với thực tổ chức Tích hợp nhân bảo trì phần mềm với nhóm vận hành Tạo biện pháp, hồn chỉnh/ngăn ngừa, ngân sách bảo trì cho phép nhóm bảo trì định re-engineer hệ thống o Lối kéo độ ngũ bảo trì sớm qui trình phần mềm suốt chuẩn bị qui chuẩn, review, chuẩn bị kiểm thử o o o o UIT-VNUHCM 2009 63 CuuDuongThanCong.com https://fb.com/tailieudientucntt Tài liệu tham khảo van 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 Lehman, 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 Pfleeger, 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Yêu cầu thực tuần Nộp báo cáo tập làm lớp (* ) Tìm hiểu minh hoạ cơng cụ (tools) quản lý thay đổi (*) Chuẩn bị thuyết minh 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 Report2.pdf, SMP_documents.rar NHóm khách hàng (customer group): bắt cặp ngược theo thứ tự nhóm cho ?, ngược lại Hai nhóm có đại diện để trao đổi ghi nhận thông tin, trao đổi thông tin với thông qua group link UIT-VNUHCM 2009 65 CuuDuongThanCong.com https://fb.com/tailieudientucntt ... Company Logo Chương 2: NỀN TẢNG CỦA SỰ THAY ĐỔI PHẦN MỀM 2. 1 Nền tảng thay đổi phần mềm 2. 2 Mối liên quan kinh tế việc cập nhật phần mềm 2. 3 Giải pháp tiềm vấn đề bảo trì UIT-VNUHCM 20 09 CuuDuongThanCong.com... https://fb.com/tailieudientucntt Bảo trì SDLC Qui trình phát triển phần mềm Waterfall, có họp cuối qui trình bỏ qua mơ tả qui trình Chu trình cải tiến Spiral Model ,bảo trì phù hợp nhiều vị trí bật ? ?Bảo trì liên quan... (bảo trì hiệu chỉnh) o Adaptive Maintenance (Bảo trì thích nghi) o Perfective Maintenance (Bảo trì hồn chỉnh) Ranh giới loại bảo trì mờ khơng rõ Chúng ta định nghĩa loại bảo trì khác – bảo trì