Bài giảng Chương 4 bảo trì phần mềm

Chương 4 BẢO TRÌ PHẦN MỀM MỤC TIÊU:  Hiểu được vai trò của việc bảo trì phần mềm  Nắm được các vấn đề liên quan đến bảo trì: phân loại, phương pháp, chi phí bảo trì …  Hiểu được một số quy trình và các chiến lược cải tiến phần mềm  Tìm hiểu về tái kỹ nghệ NỘI DUNG CHÍNH 3.1 Giới thiệu 3.2 Tiến trình bảo trì 3.3 Một số hiệu ứng lề 3.4 Những vấn đề về bảo trì hiện nay 3.5 Các kỹ thuật cho bảo trì 3.6 Ma trận các chủ đề bảo trì p/m và tài liệu tham khảo 3.1 Giới thiệu 3.1.1 Định nghĩa 3.1.2 Tại sao phải bảo trì 3.1.2 Phân loại bảo trì 3.1.3 Chi phí bảo trì 3.1.1 Định nghĩa • Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển (chương trình, dữ liệu, các loại tư liệu đặc tả, . . ) theo những lý do nào đó • Bảo trì thường không bao gồm những thay đổi chính liên quan tới kiến trúc của hệ thống. • Những thay đổi trong hệ thống thường được cài đặt bằng cách: – điều chỉnh những thành phần đang tồn tại và – bổ sung những thành phần mới cho hệ thống. 3.1.2 Tại sao phải bảo trì • Bảo trì là không thể tránh khỏi vì: – Các yêu cầu hệ thống thay đổi khi hệ thống đang được xây dựng => hệ thống được chuyển giao có thể không thoả mãn các yêu cầu của nó. – Hệ thống gắn kết chặt chẽ với môi trường của nó => thay đổi môi trường sẽ thay đổi các yêu cầu của hệ thống. – Các hệ thống phải được bảo trì nếu chúng muốn là những phần hữu ích trong môi trường nghiệp vụ. • Bảo trì là cần thiết – để đảm bảo rằng hệ thống tiếp tục t/mãn các y/cầu người dùng • Bảo trì phải được thực hiện để – Sửa các lỗi – Sửa các yêu cầu và các chỗ hổng thiết kế – Cải tiến thiết kế – Tạo các nâng cấp – Giao tiếp với các hệ thống khác – Chuyển đổi chương trình sang nền tảng p/cứng, p/mềm, … phù hợp 3.1.2 Tại sao phải bảo trì • Các khía cạnh chính mà bảo trì tập trung là: – Bảo trì điều khiển toàn bộ các chức năng của hệ thống hàng ngày – Bảo trì điều khiển toàn bộ các sửa đổi hệ thống – Hoàn thiện các chức năng có thể chấp nhận đang tồn tại – Ngăn chặn sự thực hiện của hệ thống từ mức thấp đến các mức có thể được chấp nhận => P/mềm phải được cải tiến và bảo trì 3.1.2 Tại sao phải bảo trì 3.1.3 Phân loại bảo trì Chia làm 4 loại: – Bảo trì để tu chỉnh – Bảo trì để thích nghi – Bảo trì để hoàn thiện – Bảo trì để phòng ngừa Bảo trì tu chỉnh và phòng ngừa được xếp vào loại bảo trì sửa chữa Bảo trì thích nghi và hoàn thiện thuộc loại nâng cấp a) Bảo trì để tu chỉnh • Là bảo trì khắc phục những khiếm khuyết có trong phần mềm • Một số nguyên nhân điển hình – Kỹ sư phần mềm và khách hiểu nhầm nhau – Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết – Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . thiết kế sai, biên soạn sai . . . – Thiếu chuẩn hóa trong phát triển phần mềm • Các bước thực hiện: dò lại thiết kế để tu sửa b) Bảo trì để thích nghi • Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì, thích nghi và quản lý phần mềm theo vòng đời của nó • Những nguyên nhân chính: – Thay đổi về phần cứng (ngoại vi, máy chủ,. . ) – Thay đổi về phần mềm (môi trường): đổi OS – Thay đổi cấu trúc tệp hoặc mở rộng CSDL c) Bảo trì để hoàn thiện • Là việc tu chỉnh phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn • Những nguyên nhân chính: – Mở rộng thêm chức năng mới cho hệ thống – Cải tiến quản lý kéo theo cải tiến tài liệu vận hành và trình tự công việc – Thay đổi người dùng hoặc thay đổi thao tác • Còn gọi là tái kỹ nghệ (re-engineering), với mục đích đưa ra một thiết kế của cùng một chức năng nhưng có chất lượng cao hơn d) Bảo trì để phòng ngừa • Mục đích: – sửa đổi p/m để thích hợp với yêu cầu thay đổi sẽ có của người dùng • Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào • Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt 3.1.3 Chi phí bảo trì • Chi phí bảo trì thường lớn hơn chi phí xây dựng gấp từ 2 đến 100 lần phụ thuộc vào từng ứng dụng: – Chi phí bảo trì bị ảnh hưởng bởi cả các yếu tố kỹ thuật và phi kỹ thuật. – Nếu bảo trì càng nhiều, sẽ càng làm thay đổi cấu trúc phần mềm và do đó sẽ làm cho việc bảo trì càng trở lên khó khăn hơn. – Phần mềm có tuổi thọ càng cao thì cần chi phí bảo trì càng cao Phân bổ chi phí bảo trì Các yếu tố ảnh hưởng đến chi phí bảo trì • Sự ổn định của đội dự án: chi phí bảo trì sẽ giảm nếu nhân viên trong đội dự án không thay đổi. • Những trách nhiệm đã cam kết: người xây dựng hệ thống có thể không cam kết trách nhiệm bảo trì cho nên không có gì để bắt buộc họ phải thiết kế lại cho các thay đổi trong tương lai. • Kỹ năng của nhân viên: nhân viên bảo trì thường không có kinh nghiệm và hiểu biết về miền ứng dụng của họ bị hạn chế. • Tuổi thọ và cấu trúc chương trình: khi tuổi thọ và cấu trúc chương trình bị xuống cấp thì chúng càng trở lên khó hiểu và thay đổi nhiều. Dự đoán bảo trì • Dự đoán bảo trì: – liên quan tới việc đánh giá những phần nào của hệ thống có thể gây ra lỗi và cần bao nhiêu chi phí để bảo trì. • Khả năng chịu được sự thay đổi – phụ thuộc vào khả năng bảo trì của các thành phần bị ảnh hưởng bởi sự thay đổi đó. • Thực hiện các thay đổi – có thể làm hỏng hệ thống và giảm khả năng bảo trì của nó. • Chi phí bảo trì – phụ thuộc vào số lượng các thay đổi và – chi phí thay đổi phụ thuộc vào khả năng bảo trì. • Có thể dự đoán bảo trì thông qua việc đánh giá độ phức tạp của các thành phần hệ thống. • Độ phức tạp của thành phần phụ thuộc vào: – Độ phức tạp của cấu trúc điều khiển – Độ phức tạp của cấu trúc dữ liệu – Kích thước của đối tượng, phương thức và mô-đun. • Ngoài ra, ta có thể sử dụng các phép đo quy trình để đánh giá khả năng bảo trì của hệ thống. – Số lượng các yêu cầu cần bảo trì sửa lỗi. – Thời gian trung bình cần thiết để phân tích ảnh hưởng – Thời gian trung bình để cài đặt một yêu cầu thay đổi. – Số lượng các yêu cầu cần giải quyết. Dự đoán bảo trì Dự đoán thay đổi – Dự đoán số lượng các thay đổi có thể xảy ra và tìm hiểu mối quan hệ giữa hệ thống và môi trường của nó. Làm thế nào để giảm độ phức tạp bảo trì • Sử dụng các kỹ thuật kiểm thử tốt hơn trong suốt quá trình phát triển • Tạo ra các tài liệu tốt hơn, tuân theo các chuẩn và các quy ước • Dự đoán các thay đổi trong tương lai trong suốt giai đoạn xác định yêu cầu – Thiết kế hướng đến sự mở rộng: chi phí bảo trì dòng mã lớn hơn gấp 20 đến 40 so với giai đoạn xd dòng mã đó • Thiết kế cấu trúc hệ thống để không ràng buộc với các thay đổi trong tương lai • Tách ra các thành phần mà có thể thay đổi trong tương lai • Giành sự cố gắng hơn trong quá trình thiết kế ban đầu để có được các yêu cầu đúng của người sử dụng • Khi quyết định lựa chọn hoạt động bảo trì hay thay thế phần mềm, ta cần trả lời các câu hỏi sau: – Chí phí bảo trì không quá cao? – Tính tin cậy của hệ thống có được chấp nhận không? – Hệ thống có không mất đi khả năng thích nghi với các thay đổi trong tương lai với một giản đồ và chi phí hợp lý – Hệ thống có thực hiện dựa trên các ràng buộc đã mô tả trước không? – Các chức năng không làm hạn chế tính hữu ích của hệ thống? – Không thể có các hệ thống khác mà làm công việc tương tự nhanh hơn, tốt hơn và rẻ hơn? – Chi phí bảo trì phần cứng không trở nên đắt đến nỗi mà phần cứng có thể bị thay thế => Nếu tất cả các trả lời đều là Yes thi ta mới nên tiến hành bảo trì Làm thế nào để giảm độ phức tạp bảo trì 3.2.1 Cải thiện phần mềm 3.2.2 Mô hình tiến trình bảo trì 3.2.3 Các hoạt động bảo trì 3.2 Tiến trình bảo trì 3.2.4 Tiến trình bảo trì khẩn cấp • Để cải thiện hệ thống hiện có, người ta đã đề xuất 4 chiến lược cơ bản: – Tách hệ thống và chỉnh sửa các quy trình nghiệp vụ – Tiếp tục bảo trì hệ thống – Biến đổi hệ thống bằng cách tái kỹ nghệ để nâng cấp khả năng bảo trì của nó. – Thay thế hệ thống bằng một hệ thống mới 3.2.1 Cải thiện phần mềm • Việc lựa chọn chiến lược cải tiến hệ thống phụ thuộc vào chất lượng hệ thống và giá trị nghiệp vụ của nó như sau: – Chất lượng thấp và giá trị nghiệp vụ thấp: những hệ thống này nên được tách ra. – Chất lượng thấp và giá trị nghiệp vụ cao: những hệ thống này có giá trị nghiệp vụ cao nhưng chi phí bảo trì khá lớn. Ta nên tái kỹ nghệ hoặc thay thế bởi một hệ thống thích hợp – Chất lượng cao và giá trị nghiệp vụ thấp: thay thế bằng các thành phần code – Chất lượng cao và giá trị nghiệp vụ cao: tiếp tục sử dụng và bảo trì hệ thống theo cách thông thường. 3.2.1 Cải thiện phần mềm • Việc đánh giá giá trị nghiệp vụ được thực hiện từ nhiều khung nhìn khác nhau. Phỏng vấn các stakeholder khác nhau và đối sánh kết quả thu được. Các stakeholder thường là: – Người sử dụng cuối – Khách hàng của doanh nghiệp – Người quản lý dây chuyền sản xuất – Người quản lý công nghệ thông tin – Người quản lý cao cấp 3.2.1 Cải thiện phần mềm • Đánh giá chất lượng hệ thống thông qua: – Quy trình nghiệp vụ: quy trình nghiệp vụ đã hỗ trợ cho các mục tiêu nghiệp vụ như thế nào? – Môi trường hệ thống: môi trường hệ thống có hiệu quả như thế nào và chi phí để bảo trì nó. – Khả năng ứng dụng: chất lượng của ứng dụng? 3.2.1 Cải thiện phần mềm 3.2 .2 Mô hình tiến trình bảo trì • Mô hình tiến trình bảo trì theo IEEE Phân loại và nhận dạng Phân tích ảnh hưởng Cài đặt Thiết kế Kiểm thử Hệ thống Kiểm thử Chấp thuận Phát hành Yêu cầu sửa đổi • Các hoạt động của tiến trình bảo trì theo ISO/IEC – tương tự như IEEE, – Chúng được kết hợp theo trình tự như sau: 3.2.2 Mô hình tiến trình bảo trì Cài đặt tiến trình Bảo trì chấp thuậnPhân tích vấn đề sửa đổi Cài đặt sửa đổi Nghỉ hưu Chuyển dịch • Thực hiện phân tích ban đầu – Xác minh vấn đề cần sửa đổi • Phát triển các giải pháp cho việc cài đặt sửa đổi • Tư liệu hóa các giải pháp • Lựa chọn giải pháp sửa đổi được khách hàng chấp thuận Phân tích vấn đề sửa đổi • Phát triển các kế hoạch bảo trì • Thiết lập các thủ tục cho việc sửa đổi các y/cầu • Cài đặt các thủ tục và tiến trình quản lý cấu hình Cài đặt sửa đổi Bảo trì chấp thuận • Kiểm tra lại với dữ liệu người dùng • Đảm bảo hệ thống người dùng chấp thuận • Đảm bảo rằng sự chuyển dịch là phù hợp với chuẩn • Phát triển một kế hoạch chuyển dịch • Thông báo cho người dùng về các kế hoạch chuyển dịch • Đảm bảo dữ liệu cũ có thể truy cập Chuyển dịch • Phát triển một kế hoạch nghỉ hưu, • Thông báo cho người dùng về các kế hoạch nghỉ hưu • Đảm bảo rằng dữ liệu cũ có thể truy cập Nghỉ hưu 3.2.3 Các hoạt động bảo trì • Tương tự như các hoạt động phát triển p/mềm – Phân tích, thiết kế, mã hóa, kiểm thử và tư liệu hóa (theo mô hình tiến trình trên) • Các hoạt động khác: – Hiểu mã nguồn – Quản lý cấu hình – Đảm bảo chất lượng hệ thống – Lập kế hoạch bảo trì Hiểu mã nguồn Tác dụng của việc hiểu mã nguồn: – Phân tích ảnh hưởng: xác định mọi hệ thống, thành phần hệ thống bị ảnh hưởng bởi một y/cầu thay đổi – Ước lượng các tài nguyên cần thiết để hoàn thành việc thay đổi – Xác định các rủi ro được tạo bởi sự thay đổi – Hiệu ứng lề của việc thay đổi – Tiến trình bảo trì là không đủ nếu chỉ • lưu vết các sửa đổi yêu cầu và các báo cáo vấn đề – Sản phẩm p/m và bất kỳ thay đổi nào của nó đều phải được quản lý bởi tiến trình quản lý cấu hình p/m (SCM) • nhằm xác định các cấu hình của hệ thống tại các điểm riêng lẻ • điều khiển các thay đổi cho cấu hình Quản lý cấu hình • Cần lập kế hoạch bảo trì • Lựa chọn kỹ thuật hỗ trợ các hoạt động – đảm bảo chất lượng p/m (SQA) và – V&V hệ thống sau tiến trình bảo trì Đảm bảo chất lượng hệ thống • Là hoạt động quan trọng của tiến trình bảo trì • Ước lượng chính xác các tài nguyên : – Thời gian bảo trì – Chi phí – Phạm vi bảo trì – Các biến đổi của tiến trình sau phát hành – Những hỗ trợ cho bảo trì Lập kế hoạch bảo trì [IEEE 1219], [ISO/IEC 14764] 3.2.4 Tiến trình bảo trì khẩn cấp Hiểu phần mềm đã có • Theo tài liệu nắm chắc các chức năng • Theo tài liệu chi tiết nắm vững đặc tả chi tiết, điều kiện kiểm thử, . . . • Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống => 3 việc trên đều là công việc thực thi trên bàn Tu sửa phần mềm đã có • Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại • Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả • Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ thống Phát triển phần mềm mới • Khi có y.c thêm chức năng mới – phải phát triển chương trình cho phù hợp với yêu cầu • Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit (như trong mô hình bảo trì p.m) • Phản ảnh vào giao diện của phần mềm ( thông báo, phiên bản, . . .) Kiểm chứng tính nhất quán bằng kiểm thử tích hợp • Đưa đơn vị (unit) đã được kiểm thử vào hoạt động trong hệ thống • Điều chỉnh sự tương thích giữa các môđun • Dùng các dữ liệu trước đây khi kiểm thử để kiểm thử lại tính nhất quán • Chú ý hiệu ứng lề trong chỉnh sửa Kiểm thử sau bảo trì • Kiểm tra nội dung thay đổi có trong tư liệu đặc tả ko • Cách ghi tư liệu có phù hợp với mô tả môi trường phần mềm mới hay không ? Lập biểu quản lý bảo trì • Cần quản lý tình trạng bảo trì • Lập biểu quản lý tình trạng bảo trì • Ngày tháng, giờ • Nguyên nhân • Tóm tắt cách khắc phục • Chi tiết khắc phục, hiệu ứng lề • Người làm bảo trì • Số công Ví dụ về tiến trình bảo trì : • Người sử dụng tìm ra một vấn đề và báo cáo với nhân viên hỗ trợ • Nhân viên hỗ trợ mô tả chi tiết vấn đề và gửi đến nhóm đánh giá • Nhóm đánh giá phân tích và xác định vấn đề – Liệu vấn đề đã được biết chưa – Liệu người sử dụng có đang sử dụng phần mềm một cách đúng đắn – Vấn đề nghiêm trọng như thế nào, ..... • Người quản lý giao cho lập trình viên giải quyết vấn đề dựa trên việc đánh giá mức độ ưu tiên • Lập trình viên bảo trì giải quyết vấn đề: – Khôi phục lại các tài liệu, mã nguồn và các thiết bị liên quan khác từ bản phát hành trước – Vạch ra các khiếm khuyết và cố định nó – Kiểm tra các thay đổi – Cập nhật tất cả các tài liệu có liên quan, mô hình hệ thống, mã nguồn, cấu trúc dữ liệu, .... – Tích hợp các thay đổi vào bản phát hành tiếp theo • Người sử dụng nhận phiên bản phần mềm đã được cập nhật hoặc các gói dịch vụ, .... Ví dụ về tiến trình bảo trì: 3.3 Một số hiệu ứng lề của bảo trì • Sửa đổi phần mềm là công việc nguy hiểm, ta thường gặp 3 loại hiệu ứng lề chính như sau: – Hiệu ứng lề của việc thay đổi mã nguồn – Hiệu ứ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 Hiệu ứng lề của việc thay đổi mã nguồn • Một thay đổi đơn giản tới một câu lệnh đơn cũng có thể đem lại một hậu quả thảm khốc. • Mặc dù không phải các ảnh hưởng đều là tiêu cực, nhưng việc sửa lỗi luôn dẫn đến các vấn đề phức tạp. • Mặc dù tất cả các thay đổi mã lệnh chương trình đều có thể tạo ra lỗi, nhưng tập hợp các thay đổi sau có thể gây ra nhiều lỗi hơn: • Tập hợp các thay đổi gây ra nhiều lỗi: – 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. Hiệu ứng lề của việc thay đổi dữ liệu • Trong quy trình bảo trì, – việc sửa đổi thường được tiến hành đối với các phần tử riêng rẽ của cấu trúc dữ liệu. – Khi dữ liệu thay đổi, việc thiết kế phần mềm sẽ không còn phù hợp với dữ liệu và lỗi có khả năng xảy ra. • Hiệu ứng lề của dữ liệu xảy ra như là kết quả của việc thay đổi cấu trúc dữ liệu. – Định nghĩa lại các hằng số cục bộ. – Định nghĩa lại cấu trúc bản ghi/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. Các thay đổi dữ liệu sau đây thường gây ra lỗi: Hiệu ứng lề của việc thay đổi tài liệu • Việc bảo trì không chỉ tập trung riêng vào việc sửa đổi mã. • Sự ảnh hưởng của tài liệu xảy ra khi – 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. => Bất cứ lúc nào có thay đổi về: • Luồng dữ liệu, • cấu trúc phần mềm, • các thủ tục hay bất cứ cái gì có liên quan,  tài liệu kỹ thuật phải được cập nhật. • Tài liệu thiết kế phản ánh không đúng trạng thái hiện tại của phần mềm có lẽ còn tồi tệ hơn không có tài liệu. • Hiệu ứng lề xảy ra trong các lần bảo trì sau đó • Đố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 một cách chính xác. • Thực tế một vài yêu cầu bảo hành có thể đòi hỏi: • không được thay đổi thiết kế của phần mềm hoặc • Không thay đổi 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. => Trong những trường hợp như vậy nỗ lực bảo trì tập trung vào tài liệu. Hiệu ứng lề của việc thay đổi tài liệu 3.4 Những vấn đề về bảo trì hiện nay • Sáng kiến trong quy trình phát triển p/mềm • Sáng kiến trong quy trình bảo trì phần mềm • Phát triển những kỹ thuật mới cho bảo trì Sáng kiến trong quy trình phát triển phần mềm (1) Chuẩn hóa mọi khâu trong phát triển phần mềm (2) Người bảo trì chủ chốt tham gia vào giai đoạn phân tích và thiết kế (3) Thiết kế để dễ bảo trì Sáng kiến trong quy trình bảo trì phần mềm (1) Sử dụng các công cụ hỗ trợ phát triển phần mềm (2) Chuẩn hóa thao tác bảo trì và các công cụ của môi trường bảo trì (3) Lưu lại những thông tin lịch sử bảo trì (4) Dự án nên cử một người chủ chốt làm công việc bảo trì sau khi dự án kết thúc giai đoạn phát triển Phát triển những kỹ thuật mới cho bảo trì • Công cụ phần mềm hỗ trợ bảo trì • Cơ sở dữ liệu cho bảo trì • Quản lý tài liệu, quản lý dữ liệu, quản lý chương trình nguồn, quản lý dữ liệu thử, quản lý tiền sử bảo trì 3.5 Các kỹ thuật cho bảo trì 3.5.1 Hiểu chương trình 3.5.2 Tái kỹ nghệ 3.5.3 Kỹ nghệ ngược 3.5.4 Phân tích ảnh hưởng 3.5.1 Hiểu chương trình • Để cải đặt thay đổi – Các nhà nc chỉ ra rằng: 40%->60%cố gắng bảo trì là để hiểu p/m sẽ được sửa đổi • Khó hiểu qua tài liệu văn bản • Khó lần theo vết các cải tiến của p/m qua các phiên bản • Các thay đổi không được tư liệu hóa • Người phát triển không giải thích về mã • Tài liệu rõ ràng súc tích – Hỗ trợ cho việc hiểu chương trình • Website: Cung cấp một số bài báo về việc hiểu chương trình & các công cụ trợ giúp tiến trình hiểu mã nguồn • Code Browsers: là công cụ chìa khóa cho việc hiểu chương trình, thái mỏng c/trình 3.5.2 Tái kỹ nghệ hệ thống (System re-engineering ) • Tái kỹ nghệ hệ thống là kỹ thuật cấu trúc lại hoặc viết lại một phần hoặc toàn bộ hệ thống được thừa kế mà không thay đổi các chức năng của nó. • Tái kỹ nghệ giúp – giảm rủi ro • vì trong quá trình xây dựng phần mềm mới rủi ro có thể xảy ra là khá cao – giảm chi phí. – Tái kỹ nghệ ngày nay được sử dụng như là kỹ nghệ ngược để cải thiện cấu trúc của các chương trình hướng đối tượng • Mô hình sau đây giúp phân biệt forward và reverse-engineering: 3.5.3 Kỹ nghệ ngược (reverse engineering ) • Là tiến trình phân tích một hệ thống (mã nguồn) – để xác định các thành phần của hệ thống – và các mối quan hệ bên trong chúng – để tạo lại các biểu diễn của hệ thống theo • dạng khác hoặc • ở mức độ trừu tương cao hơn • Kỹ nghệ ngược là chủ động – Không thay đổi hệ thống – Ví dụ đơn giản về hoạt động kỹ nghệ ngược: tạo đồ thị luồng điều khiển từ mã nguồn 3.5.3 Kỹ nghệ ngược (reverse engineering ) • Quy trình kỹ nghệ ngược bao gồm các hoạt động sau: – Dịch mã nguồn: chuyển mã lệnh thành ngôn ngữ mới. – Kỹ nghệ ngược: phân tích chương trình để tìm hiểu nó. – Cải thiện cấu trúc chương tr