ĐẶC ĐIỂM CỦA BẢO TRÌ PHẦN MỀM

Bảo trì phần mềm cho tới gần đây vẫn còn là một giai đoạn bị coi nhẹ của chu trình phần mềm. Kiến thức về bảo trì có được rất ít khi so sánh với các giai đoạn hoạch định và phát triển. Có rất ít các số liệu nghiên cứu và chế tạo tập trung vào đề tài này, vầ rất ít các phương pháp kỹ thuật được đưa ra. Để hiểu được điểm bản chất của bảo trì, chúng ta sẽ xem xét các vấn đề từ ba góc độ khác nhau:

·        Các hoạt động cần thiết để hoàn thành giai đoạn bảo trì và tính toàn vẹn của một cách tiếp cận theo công nghệ phần mềm đối với hiệu quả của những hoạt động đó, hay sự thiếu hụt nó.

·        Chi phí kèm theo giai đoạn bảo trì.

·        Các vấn đề thường gặp phải khi tiến hành bảo trì phần mềm.

7.2.1. Bảo trì có cấu trúc đối với bảo trì không cấu trúc.

Nếu thành phần có được duy nhất của một cấu hình phần mềm là mã nguồn, hoạt động bảo trì bắt đầu với việc đánh giá chi tiết mã nguồn thường là khá phức tạp với những tài liệu nghèo nàn bên trong. Những đặc điểm tế nhị như cấu trúc phần mềm, các cấu trúc dữ liệu toàn cục, giao diên hệ thống,hoạt động và các ràng buộc thiết kế thường rất khó sáng tỏ và hay bị hiểu lầm. Các thay đổi lặt vặt thường xuyên làm cho các mã rất khó đánh giá. Các kiểm tra hồi quy (lặp lại các kiểm tra trước kia để đảm bảo rằng những thay đổi không tạo ra lỗi trong phần mềm đã hoạt động) là không thể thực hiện được bởi không hề có các bản lưu về các kiểm tra đó. Chúng ta đang tiến hành phép bảo trì không cấu trúc và đang phải trả giá (khi lãng phí công sức và gây tâm trạng thất vọng). Sự trả giá này luôn đi kèm với các phần mềm đã không được phát triển theo những phương pháp đúng đắn.

Nếu có một cấu hình phần mềm hoàn thiện, nhiệm vụ bảo trì bắt đầu bằng việc đánh giá các tài liệu thiết kế. Sau đó là xác định các đặc điểm thuộc cấu trúc quan trọng, các đặc điểm hoạt động và giao diện. Tính toàn vẹn của những sửa đổi và hiệu chỉnh cần thiết sẽ được đánh giá và một kế hoạch sửa đổi sẽ được thiết lập. Thiết kế được thay đổi (sử dụng những kỹ thuật phù hợp với những điều đã bàn luận ở ácc chương trước) rồi nhận xét đánh giá. Mã nguồn được phát triển, sau đó tiến hành các kiểm tra hồi quy sử dụng thông tin chứa trong phần "đặc tả kiểm tra" và rồi phần mềm lại được phát hành.

Các mô tả trên đây là phép bảo trì cấu trúc và được tiến hành như là kết quả của những ứng dụng trước đây trong khoa học về công nghệ phần mềm. Mặc dù sự có mặt của một cấu hình phần mềm không đảm bảo được các vấn đề bảo trì nảy sinh, nhưng khối lượng công việc đã được giảm bớt và chất lượng chung của những thay đổi và hiệu chỉnh đã được cải thiện.

7.2.2. Giá thành bảo trì

Theo thống kê, giá thành cho việc bảo trì các phần mềm tăng lên một cách đều đặn trong suốt 20 năm qua. Trong những năm 1970, bảo trì chiếm đến 35 đến 40 phần trăm kinh phí phần mềm dành cho tổ chức hệ thống thông tin.Tỷ lệ này đã nhảy tới con số 60 vào giữa những năm 1980. Và nhiều công ty đã chi 80% kinh phí cho việc bảo trì vào giữa những năm 1990.

Chi phí cho việc bảo trì là rõ ràng nhất. Tuy nhiên những chi phí khác khó thấy hơn có thể gây ra mối quan tâm lớn hơn:

·        Một chi phí khó xác định của việc bảo trì phần mềm là các cơ hội phát triển bị bỏ qua vì các tài nguyên có sẵn đều dành cho nhiệm vụ bảo trì.

·        Sự không hài lòng của người dùng khi các yêu cầu có vẻ hợp lý cho việc sửa chữa hay sửa đổi không được chú ý một cách hợp lý.

·        Việc suy giảm chất lượng nói chung do lỗi tạo ra bởi sự thay đổi trong các phần mềm được bảo trì.

·        Một yêu cầu bất chợt làm ngắt quãng quá trình phát triển của một nhân viên buộc anh ta tiến hành công việc bảo trì.

            Chi phí cuối cùng cho việc bảo trì là sự giảm sút kinh khủng về năng suất lao động (được đo theo số dòng lệnh -LOC- của một người trong một tháng hay số tiền chi phí cho dòng lệnh). Sự giảm sút này xuất hiện khi tiến hành bảo trì đối với các phần mềm cũ. Người ta đã ghi nhận sự giảm sút năng suất lao động theo tỷ lệ 40:1, có nghĩa là chi phí cho việc phát triển trị giá $25.00 trên một dòng lệnh sẽ có thể trị giá tới $1000.00 cho việc bảo trì mỗi dòng lệnh.

Công sức cho việc bảo trì có thể được phân chia thành các thao tác làm việc: phân tích, ước lượng, thay đổi thiết kế, và sửa chữa chương trình nguồn và các thao tác lặp lại: việc cố gắng hiểu chương trình nguồn làm gì, cố gắng sáng tỏ cấu trúc dữ liệu, các thuộc tính giao diện, giới hạn của việc thực hiện,... Biểu thức dưới đây cung cấp một mô hình cho công việc bảo trì:

M = p + K* exp(c-d),

với      M = toàn bộ các công việc cho việc bảo trì;

            p = công việc làm (như miêu tả ở trên);

            K = hằng số kinh nghiệm;

            c = đánh giá mức độ phức tạp được tính cho việc thiếu thiết kế về cấu trúc và dữ liệu;

            d = đánh giá mức độ hiểu biết về phần mềm.

Mô hình trên đây cho thấy công việc và giá thành có thể tăng lên theo cấp số mũ nếu một phương pháp phát triển phần mềm kém cỏi được sử dụng -tức là thiếu sót của công nghệ phần mềm, và nếu một người hay một nhóm dùng các phương pháp không có giá trị để bảo trì phần mềm. Chi phí cho bảo trì khi phần mềm được phát triển không đúng phương pháp được minh hoạ ở hình sau:

7.2.3. Một số vấn đề khác

Hầu hết các vấn đề liên quan tới việc bảo trì phần mềm đều liên quan tới các sai lệch trong cách xây dựng và phát triển phần mềm. Sự thiếu sót trong việc điều khiển và tổ chức trong hai giai đoạn đầu tiên của một chu trình phần mềm gần như luôn luôn tạo ra các vấn đề giai đoạn cuối.

Nhiều vấn đề kinh điển có thể liên quan tới việc bảo trì phần mềm được trình bày dưới đây:

·        Rất khó hoặc không thể theo dõi sự tiến hóa của phần mềm qua các phiên bản. Các thay đổi không được tư liệu hóa.

·        Khó theo dõi được các quá trình xử lý được tạo bởi các phần mềm.

·        Thường xuyên gặp rất nhiều khó khăn trong việc tìm hiểu chương trình của người khác viết. Những khó khăn này tăng lên khi số thành phần các cấu hình của phần mềm giảm đi. Nếu chỉ có các chương trình nguồn không có tài liệu hướng dẫn thì không nên tìm hiểu phần mềm đó.

·        Những người viết phần mềm thường không có mặt để giải thích. Chúng ta không thể trông cậy vào những giải thích cá nhân của các nhà phát triển phần mềm khi việc bảo trì được yêu cầu.

·        Các tài liệu chính xác không có hay thiếu trầm trọng. Phải thừa nhận rằng phải có tài liệu về phần mềm là bước đầu tiên, nhưng tài liệu phải hiểu được và phù hợp với chương trình lại là chuyện khác.

·        Phần lớn các phần mềm không thiết kế để thay đổi, trừ phi sử dụng phương pháp thiết kế dùng các khái niệm về phân tách chương trình thành các module độc lập. Việc thay đổi phần mềm sẽ rất khó khăn và dẫn đến xu hướng sai.

·        Việc bảo trì phần mềm không được coi là một công việc dễ dàng mà công việc bảo trì phần mềm luôn liên quan tới các sai lệch ở mức độ cao.