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

ứng lề của việc thay đổi dữ liệu 
 Hiệu ứng lề của việc thay đổi tài liệu 
 Bài tập: Thảo luận cho ví dụ minh họa ngữ 
 cảnh các hiệu ứng lề như trên khi sửa lỗi phần 
 mềm 
 42 
UIT-VNUHCM 2009 
 Hiệu ứng lề của việc thay đổi mã nguồn 
 Việc sửa lỗi luôn dẫn đến các vấn đề phức tạp .Tập 
 hợp các thay đổi sau có thể gây ra nhiều lỗi hơn 
  Một chương trình con bị xóa hay thay đổi. 
  Một dòng nhãn bị xóa hay thay đổi. 
  Một biến bị xóa hay thay đổi. 
  Các thay đổi để tăng khả năng thực hiện. 
  Việc mở và đóng file bị thay đổi. 
  Các phép toán logic bị thay đổi. 
  Việc thay đổi thiết kế chuyển thành các thay đổi lớn về 
 chương trình. 
  Các thay đổi ảnh hưởng đến việc chạy thử các trường 
 hợp biên. 
 43 
UIT-VNUHCM 2009 
 Hiệu ứng lề của việc thay đổi dữ liệu 
  Định nghĩa lại các hằng số cục bộ và hằng số địa 
 phương. 
  Định nghĩa lại cấu trúc bản ghi hay cấu trúc file. 
  Tăng hoặc giảm kích thước một mảng. 
  Thay đổi dữ liệu tổng thể. 
  Định nghĩa lại các cờ điều khiẻn và các con trỏ. 
  Xếp lại các tham số vào ra hay tham số của 
 chương trình con. 
 Hạn chế: bằng tài liệu thiết kế mô tả cấu trúc dữ liệu và 
 cung cấp một lời chỉ dẫn tham khảo đến từng phần từ dữ 
 liệu, các bản ghi, các file và các cấu trúc khác của các 
 module phần mềm 
UIT-VNUHCM 2009 44 
 Hiệu ứng lề của việc thay đổi tài liệu 
 thay đổi chương trình nguồn mà không thay đổi tài 
 liệu thiết kế và tài liệu hướng dẫn sử dụng 
 Hiệu ứng lề xảy ra trong các lần bảo trì sau đó, khi 
 việc nghiên cứu không kỹ các tài liệu kỹ thuật, dẫn 
 tới sự đánh giá sai về các đặc tính của phần mềm. 
 Đối với người sử dụng, phần mềm tốt chỉ khi có tài 
 liệu hướng dẫn sử dụng chúng. 
 không được thay đổi thiết kế của phần mềm hoặc 
 mã chương trình, mà chỉ cần chỉ ra sự thiếu rõ 
 ràng trong tài liệu của người sử dụng 
 45 
UIT-VNUHCM 2009 
 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, 
 Continuing 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 
 Increasing Complexity 
 o As software evolves, its complexity increases 
 unless steps are taken to control it. 
 Fundamental 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ê 
 Conservation 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) 
 Conservation 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 
 46 
UIT-VNUHCM 2009 
 Lehman’s laws 
 Law Description
 Continuing change A program that is used in a real-world environment necessarily
 must change or become progressively less useful in that
 environment.
 Increasing complexity As an evolving program changes, its structure tends to become
 more complex. Extra resources must be devoted to preserving
 and simplifying the structure.
 Large program evolution Program evolution is a self-regulating process. System
 attributes such as size, time between releases and the number of
 reported errors is approximately invariant for each system
 release.
 Organisational stability Over a programÕs lifetime, its rate of development is
 approximately constant and independent of the resources
 devoted to system development.
 Conservation of Over the lifetime of a system, the incremental change in each
 familiarity release is approximately constant.
 Continuing growth The functionality off ered by systems has to continually increase
 to maintain user satisfaction.
 Declining quality The quality of systems will appear to be declining unless they
 are adapted to changes in their operational environment.
 Feedback system Evolution processes incorporate multi-agent, multi-loop
 feedback systems and you have to treat them as feedback
 systems to achieve significant product improvement.
 47 
UIT-VNUHCM 2009 
 Khả năng áp dụng của các luật Lehman 
 Luật Lehman dường như được áp dụng với hệ 
 thống lớn được phát triển bởi tổ chức lớn. 
 không rõ ràng các luật này được thay đổi như thế 
 nào đối với 
 o Những tổ chức nhỏ 
 o Hệ thống độ lớn trung bình 
 o . 
 48 
UIT-VNUHCM 2009 
 2.2 MỐI LIÊN HỆ KINH TẾ CỦA ViỆC CẬP NHẬT PHẦN 
 MỀM 
 Giới hạn đối với sự thay đổi 
 Hạn chế tài nguyên 
 Chất lượng của hệ thống tồn tại 
 Chiến lược tổ chức 
 Tính trì trệ (không thay đổi) 
 49 
UIT-VNUHCM 2009 
 Chi phí bảo trì 
Mộ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% 
Nghiên cứu khác đưa ra ít nhất 50% nỗ lực chi cho 
 bảo trì 
Nghiên cứu khá tìm thấy khoảng giữa 65% và 75% 
 cho bảo trì 
Nhữ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 
 50 
UIT-VNUHCM 2009 
 Tại sao bảo trì tốn kém ? 
Hầu hết phần mềm có từ 10 and 15 năm 
Nhiề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 
Điều này dẫn đến không thay đổi thiết kế, code, và sưu 
 liệu 
Bả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 
Người phát triển không thích bảo trì 
Thay đổi thường gây ra lỗi mới trong 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 được ghi sưu liệu 
 51 
UIT-VNUHCM 2009 
 Yếu tố tác động đến chi phí bảo trì 
Tí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 
Ngô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 :-) 
Kiểu chương trình 
 o Cách thức một chương trình được viết 
Đá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 
 52 
UIT-VNUHCM 2009 
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 càng tốt, việc bảo trì càng dễ dàng 
Kỹ 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 
Phạ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 
Ổ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 
 53 
UIT-VNUHCM 2009 
 Yếu tố tác động đến chi phí bảo trì (3) 
Tuổ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 
Phù 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 
Độ ổ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 
 54 
UIT-VNUHCM 2009 
 Khác nhau giữa Bảo trì và Phát triển mới 
 Rà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 
 Khung 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 
 Tí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 
 55 
UIT-VNUHCM 2009 
 Bài tập & Thảo luận (1) 
 Bà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 
 Bà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 
 56 
UIT-VNUHCM 2009 
 Bài tập & Thảo luận (2) 
 Bà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ì. 
 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ê 
 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. 
 57 
UIT-VNUHCM 2009 
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 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 
 Hoà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 
 Bảo trì hệ thống tồn tại 
 58 
 UIT-VNUHCM 2009 
 Những vấn đề đối mặt của người bảo trì 
5 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 
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ụ: 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 
Tinh 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 
 59 
UIT-VNUHCM 2009 
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 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 
Mô 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 
 60 
UIT-VNUHCM 2009 
 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 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. 
 Restructuring 
 o Chuyển dịch phần code của hệ thống mà không thay đổi hành vi 
 Reverse 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 
 Reengineering 
 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 
 61 
UIT-VNUHCM 2009 
 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, 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 
Thư 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) 
Domain 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ể. 
Họ 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 
 62 
UIT-VNUHCM 2009 
 Thúc đẩy đội ngũ bảo trì 
 Thường xem xét đến dead-end trong tổ chức cũng 
 như sự chán nản 
 Quyết định đến sự thành công của tổ chức 
 Chiế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ử 
 63 
UIT-VNUHCM 2009 
 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 
 Yêu cầu thực hiện tuần tiếp theo 
  Nộp báo cáo các bài tập làm trên lớp (* ) 
  Tìm hiểu và minh hoạ các công cụ (tools) quản lý sự thay đổi (*) 
  Chuẩ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, SMP_documents.rar 
  NHó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 
  Hai 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. 
 65 
UIT-VNUHCM 2009