Công việc bảo trì phần mềm và một số hiệu ứng lề

Yếu tố kiểm soát

Khả năng bảo trì cơ bản bao gồm nhiều yếu tố. Sự thiếu cẩn trọng trong việc thiết kế, viết chương trình nguồn, kiểm tra có ảnh hưởng tiêu cực đến việc bảo trì có kết quả một phần mềm. Cấu hình yếu kém cũng có các tác động tương tự, thậm chí cả khi từng bước của kỹ thuật xây dựng phần mềm được xem xét một cách cẩn thận. Thêm vào đó nhiều yếu tố khác liên quan tới phương pháp phát triển phần mềm, như:

 Chất lượng hiệu quả của đội ngũ phần mềm.

 Cấu trúc của hệ thống dễ hiểu.

 Dễ dàng kiểm soát hệ thống.

 Dùng các ngôn ngữ lập trình chuẩn.

 Dùng các hệ điều hành chuẩn.

 Dùng các cấu trúc chuẩn tài liệu.

 Dùng được các tài liệu kiểm tra.

 Phương tiện gỡ rối đi kèm.

 Dùng được các máy tính tốt để thực hiện việc bảo trì.

Các yếu tố được đưa ra ở trên đã phản ánh những đặc điểm về phần cứng cũng như chương trình nguồn được dùng trong việc phát triển phần mềm. Những yếu tố khác chỉ ra sự cần thiết để có được phương pháp chuẩn, chương trình nguồn chuẩn. Có thể, yếu tố quan trọng nhất tác động tới khả năng bảo trì là kế hoạch cho khả năng bảo trì. Nếu coi phần mềm như là một hệ thống các thành phần sẽ phải chịu những thay đổi không tránh được, thì cơ hội tạo những phần mềm có khả năng bảo trì sẽ tăng thực sự.

Đánh giá định lượng

Khả năng bảo trì, như chất lượng hay độ tin cậy là hết sức khó xác định.

Tuy nhiên chúng ta có thể đánh giá khả năng bảo trì gián tiếp bằng việc xem xét các thuộc tính của các công việc bảo trì có thể đánh giá được:

 Thời gian nhận biết vấn đề.

 Thời gian trễ do các công việc hành chính.

 Thời gian lựa chọn công cụ bảo trì.

 Thời gian phân tích vấn đề.

 Thời gian xác định sự thay đổi.

 Thời gian hiệu chỉnh (hay sửa đổi) thực sự.

 Thời gian chạy thử cục bộ.

 Thời gian chạy thử tổng thể.

 Thời gian tổng kết bảo trì.

 Tổng thời gian của công việc bảo trì.

Mỗi đánh giá trên thực tế là các dữ liệu đó có thể cung cấp cho người quản lý cùng với chỉ số về hiệu quả của công việc.

Cơ cấu bảo trì

Mặc dù những tổ chức bảo trì chuẩn không cần được thiết lập, nhưng sự ủy thác trách nhiệm rất là cần thiết kể cả cho các tổ chức phát triển phần mềm nhỏ. Những yêu cầu bảo trì được chuyển qua cho người kiểm soát công việc bảo trì và từ đây chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá. người quản lý hệ thống là thành viên của nhóm nhân viên kỹ thuật. Những nhân viên này có trách nhiệm về một phần nhỏ của chương trình sản phẩm. Khi môth yêu cầu được đánh giá, người được ủy quyền quản lý việc thay đổi phải quyết định hhành động nào được thực hiện tiếp.

Cơ cấu được miêu tả ở trên phục vụ cho việc thiết lập phạm vi trách nhiệm đối với công việc bảo trì. Người kiểm soát và người ủy quyền quản lý việc thay đổi có thể là một người hay là một nhóm quản lý và chuyên gia kỹ thuật cao cấp.

Báo cáo

Tất cả các yêu cầu về việc bảo trì phần mềm cần được trình bày theo một tiêu chuẩn. Người phát triển phần mềm thường cung cấp một đơn yêu cầu bảo trì còn được gọi là báo cáo các lỗi phần mềm. Báo cáo này được người sử dụng điền vào khi yêu cầu công việc bảo trì. Nếu xuất hịên một lỗi, bản mô tả đầy đủ tình huống dẫn đến lỗi bao gồm dữ liệu, đoạn chương trình và các yêu cầu khác phải được điền đầy đủ vào bản báo cáo. Nếu yêu cầu bảo trì là bảo trì tiếp hợp hay bảo trì hoàn thiện thì một yêu

cầu chi tiết sẽ được thảo ra. Đơn yêu cầu bảo trì sẽ được người kiểm soát bảo trì và người quản lý hệ thống xem xét như phần trước đã nêu.

Đơn yêu cầu bảo trì được thiết lập từ bên ngoài và được coi như một cơ sở để đề ra kế hoạch của công việc bảo trì. Ngoài ra trong nội bộ của cơ quan phần mềm một báo cáo thay đổi phần mềm cũng được tạo ra. Nó chỉ ra:các công sức đòi hỏi để thỏa mãn một đơn yêu cầu bảo trì, trạng thái ban đầu của yêu cầu sửa đổi, mức ưu tiên của yêu cầu, các dữ liệu cần cho việc sửa đổi,...

Lưu giữ các hồ sơ

Thường chúng ta không có đầy đủ các hồ sơ cho tất cả các giai đoạn trong chu kỳ sống của một phần mềm. Thêm nữa không có các hồ sơ về việc bảo trì phần mềm. Do đó chúng ta thường khó có thể tiến hành các công việc bảo trì có hiệu quả, không có khả năng xác định tính chất của các chương trình và khó xác định được giá bảo trì phần mềm.

Các thông tin cần phải lưu giữ trong hồ sơ bảo trì thường:

 Dấu hiệu nhận biết chương trình.

 Số lượng các câu lệnh trong chương trình nguồn.

 Số lượng các lệnh mã máy.

 Ngôn ngữ lập trình được sử dụng.

 Ngày cài đặt chương trình.

 Số các chương trình chạy từ khi cài đặt.

 Số các lỗi xử lý xảy ra.

 Mức và dấu hiệu thay đổi chương trình.

 Số các câu lệnh được thêm vào chương trình nguồn khi chương trình thay đổi.

 Số các câu lệnh được xóa khỏi chương trình nguồn khi chương trình thay đổi.

 Số giờ mỗi người sử dụng cho mỗi lần sửa đổi.

 Ngày thay đổi chương trình.

 Dấu hiệu của kỹ sư phần mềm.

 Dấu hiệu của đơn yêu cầu bảo trì.

 Kiểu bảo trì.

 Ngày bắt đầu và kết thúc bảo trì.

 Tổng số giờ của mỗi người dùng cho việc bảo trì.

Xác định giá bảo trì

Việc xác định giá trị bảo trì thường phức tạp do thiếu thông tin. Nếu tiến hành việc lưu giữ các hồ sơ có thể tiến hành một số cách đánh giá về việc thực hiện bảo trì. Theo các chuyên gia thì đánh giá về việc thực hiện bảo trì dựa vào:

 Số lượng trung bình các lỗi xử lý cho một lần chạy chương trình.

 Tổng số giờ của mỗi người dùng cho mỗi loại bảo trì.

 Số lượng trung bình các thay đổi theo chương trình, theo ngôn ngữ lập trình, theo kiểu bảo trì.

 Số giờ trung bình của mỗi người cho một dòng lệnh được thêm vào và xóa đi.

 Số giờ trung bình của mỗi người cho một ngôn ngữ lập trình.

 Thời gian trung bình cho việc bảo trì một đơn yêu cầu bảo trì.

 Tỷ lệ phần trăm của mỗi kiểu bảo trì.

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.

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.

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.