19.Mô tả các hoạt động của bảo trì phần mềm

Khi bảo trì phần mềm các hiệu ứng lề nào có thể xảy ra

Bảo trì phần mềm là phức tạp và chúng ta có thể chia hoạt động bảo trì ra làm bốn hoạt động như sau:

1. Bảo trì hiệu chỉnh

Công việc bảo trì đầu tiên cần phải thực hiện là do việc kiểm tra chương trình không thể tránh được mội lỗi ẩn chứa bên trong một hệ phần mềm lớn. Trong khi sử dụng bất kỹ một chương trình lớn nào, các lỗi sẽ được báo về lại cho người phát triển.

Bảo trì hiệu chỉnh chính là quá trình phân tích và hiệu chỉnh một hay nhiều lỗi của chương trình.

2. Bảo trì tiếp hợp

Hoạt động thứ hai diễn ra bởi sự thay đổi thường xuyên môi trường. Những thế hệ phần cứng mới dường như được công bố theo chu trình 24 tháng một lần. Những hệ điều hành mới hay phiên bản mới của các hệ cũ đều đặn xuất hiện; thiết bị ngoại vi và các thành phần hệ thống khác liên tục được nâng cấp và thay đổi. Thời gian hữu dụng của một phần mềm ứng dụng mặt khác lại dễ dàng vượt qua thời hạn mười năm, lâu hơn môi trường hệ thống đã phát triển nó đầu tiên.

Bảo trì tiếp hợp là hoạt động sửa đổi phần mềm để thích ứng được với những thay đổi của môi trường.

3. Bảo trì hoàn thiện

Hoạt động thứ ba diễn ra khi một phần mềm đã được hoàn tất thành công. Hoạt động này chiếm hầu hết các công sức tiêu tốn cho việc bảo trì phần mềm. Lúc sử dụng, các yêu cầu về những khả năng mới, các thay đổi những chức năng đã có, và các mở rộng tổng quát được người dùng gửi đến.

Để thỏa mãn những yêu cầu phát triển của người sử dụng, ta tiến hành bảo trì hoàn thiện.

4. Bảo trì phòng ngừa

Bảo trì phòng ngừa là hoạt động bảo trì diễn ra khi phần mềm được thay đổi để cải thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung cấp một nền tảng tốt hơn cho những mở rộng sau này.

Bảo trì phòng ngừa, hoạt động này vẫn còn nhiều xa lạ trong thế giới phần mềm hiện nay.

Một số hiệu ứng lề của công việc bảo trì

Sửa đổi phần mềm là công việc nguy hiểm,  ta thường gặp ba loại chính của hiệu ứng lề như sau:

7.3.3.1. 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.

• 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.

7.3.3.2. Hiệu ứng lề của việc thay đổi dữ liệu

Trong quá 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.

Các thay đổi dữ liệu sau đây thường gây ra lỗi:

• Đị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.

Hiệu ứng lề dữ liệu có thể được 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.

7.3.3.3. Hiệu ứng lề của việc thay đổi tài liệu

Việc bảo trì thường tập trung vào cấu hình phần mềm và không 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 về 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 đó, 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.

Các hiệu ứng lề trong tài liệu có thể được giảm về căn bản nếu toàn bộ cấu hình được xem xét trước khi phát hành phiên bản phần mềm tiếp sau. 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 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.