Phân loại: có 4 loại —Bảo trì hiệu chỉnhcorrective mainternance: Thay đổi hệ thống để sửa lại những khiếm khuyết nhằm Bảo trì phần mềm - Phân loại —Bảo trì tích hợpadaptive maintermance:
Trang 1Chương 6 Bảo trì
Bảo trì phần mềm
Tổng quan
—Là hoạt động chỉnh sửa chương trình sau khi nó đã được đưa vào sử dụ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
—Đ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
—Vẫn còn bị coi nhẹ và còn ít số liệu nghiên cứu cũng như phương pháp kỹ thuật (so với giai đoạn hoạch định và phát triển)
Lý do, phân loại
Lý do
—Việc kiểm thử không thể loại bỏ hết lỗi
—Các thay đổi thường xuyên của môi trường
—Lúc sử dụng, các yêu cầu về khả năng mới, các thay đổi
hay mở rộng chức năng đã có
—Cải thiện các tính năng hay độ tin cậy
Phân loại: có 4 loại
—Bảo trì hiệu chỉnh(corrective mainternance):
Thay đổi hệ thống để sửa lại những khiếm khuyết nhằm
Bảo trì phần mềm - Phân loại
—Bảo trì tích hợp(adaptive maintermance):
Tích hợp hệ thống vào một môi trường vận hành khác
—Bảo trì hoàn thiện(perfective mainternance):
Để bổ sung hoặc chỉnh sửa các yêu cầu chức năng của
hệ thống: chỉnh sửa hệ thống sao cho thoả mãn các yêu cầu mới
—Bảo trì phòng ngừa(preventive mainternance):
Để cải thiện các tính năng bảo trì để tăng độ tin cậy trong tương lai hay để cung cấp một nền tảng tót hơn
Trang 2Bảo trì phần mềm – Tỷ lệ
Tỷ lệ các loại bảo trì
Bảo trì phần mềm - Các đặc điểm
Bảo trì có cấu trúc – không cấu trúc
Yêu cầu bảo trì
Có cấu trúc?
Đánh giá thiết kế Lập kế hoạch Sửa thiết kế
Mã hóa lại Xem xét
Đánh giá mã Xem xét
Mã hóa lại Xem xét Kiểm tra &
bàn giao
Bảo trì phần mềm - Chi phí
Chi phí
—Ngày càng tăng
—Thường lớn hơn chi phí
xây dựng từ 2-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ả tác nhân kỹ
thuật và phi kỹ thuật
—Cơ cấu (xem hình)
Bảo trì phần mềm – chi phí
Chi phí ngày càng tăng
Trang 3Bảo trì phần mềm - Chi phí
Các nhân tố ảnh hưởng đến chi phí
—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ì => không bắt buộc họ phải thiết kế lại cho
các thay đổi trong tương lai
Bảo trì phần mềm - Chi phí
—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
Bảo trì phần mềm - Chi phí
Giá thành công sứ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ư phân tích, ước lượng, thay đổi
thiết kế, sửa code nguồn)
K: hằng số kinh nghiệm
c: đánh giá mức độ phức tạp được tính do 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
Khả năng bảo trì
Khả năng bảo trì
—Là khả năng hiệu chỉnh, tích hợp hay phát triển của phần mềm
—Các yếu tố kiểm soát:
—Ngoài sự cẩn thận trong thiết kế, viết chương trình nguồn, kiểm thử… còn có các yếu tố sau:
— 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
Trang 4Bảo trì phần mềm - Khả năng
—Dùng các hệ điều hành chuẩn
—Dùng các cấu trúc huẩn tài liệu
—Dùng được các test-case
—Có phương tiện gỡ rối đi kèm
—Dùng các máy tính tốt để thực hiện việc bào trì
—Các đánh giá định lượng:
—Khả năng bảo trì, như chất lượng hay độ tin cây
khó xác định Tuy nhiên có thể đánh giá khả năng
bảo trì bằng các thuộc tính có thể định lượng được
như sau:
Bảo trì phần mềm - Khả năng
—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 thay đổi
—Thời gian hiệu chỉnh thật 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ì
Các công việc bảo trì
Người ủy quyền QL
thay đổi (change
control board)
Quản lý cấu hình
Yêu cầu bảo trì
Người kiểm soát công việc bảo trì (mainternance controller)
Giám sát hệ thống (system super isor)
Đội ngũ bảo trì
Cơ cấu tổ chức
Bảo trì phần mềm - Các công việc
Báo cáo bảo trì
—Người phát triển cung cấp đơn yêu cầu bảo trì (mainternance request form MRF)
—MRF được thiết lập từ bên ngoài và là cơ sở đề ra kế hoạch bảo trì
—Nội bộ cũng đề ra báo cáo thay đổi phần mềm (software change report SCR) gồm:
—Các công sức đòi hỏi để thỏa mãn một MRF
—Trạng thái ban đầu của yêu cầu sửa đổi
—Mức ưu tiên của các yêu cầu
—Các dữ liệu cần cho việc sửa đổi
Trang 5Các công việc bảo trì - Quy trình
Yêu cầu bảo trì
Kiểu?
Bảo trì lỗi Bảo trì khác
lỗi khác
Quy trình bảo trì phần mềm
Các công việc bảo trì – Quy trình
Mức độ nghiêm trọng
Đánh giá, phân loại, sắp xếp theo hàng đợi Đáp ứng khẩn cấp
2
Các công việc bảo trì – Quy trình
Kiểu?
Đánh giá, phân loại, Đánh giá, phân loại,
sắp xếp theo hàng đợi
Hoạt động
Yêu cầu thông tin bổ sung
Đặt thứ tự ưu tiên trong hàng đợi
1
Các công việc bảo trì - Quy trình
Hệ thống vận hành
Bảo trì
Áp dụng nguồn lực vào
Còn nhiệm vụ?
Không
Có
Trang 6Các công việc bảo trì - Quy trình
— Cài đặt thay đổi
— Cài đặt hay đổi khẩn cấp
Các công việc – Lưu giữ các hồ sơ
Lưu giữ các hồ sơ
—Các loại thông tin lưu giữ (theo Swanson)
—Dấu hiệu nhận biết chương trình
—Số lượng các câu lệnh trong mã nguồn
—Số lượng các lệnh mã máy
—Ngôn ngữ lập trình sử dụng
—Ngày cài đặt chương trình
—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 lệnh được thêm vào khi thay đổi
Các công việc – Lưu giữ các hồ sơ
—Số các lệnh xóa khỏi nguồn khi thay đổi
—Số giờ mỗi người 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 MRF
—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ì
—Lợi ích thực sự gắn liền với các công việc bảo trì
Các công việc – Giá bảo trì
Xác định giá bảo trì
—Swanson đưa ra một số cách đánh giá sau:
—Sô lượng trung bình các lỗi xử lý cho 1 lần chạy ch/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, hteo kiểu bảo trì
—Số giờ trung bình cho mỗi người cho 1 dòng lệnh thêm vào hay 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 MRF
—Tỷ lệ phần trăm của mỗi kiểu bảo trì
Trang 7Hiệu ứng lề
Thay đổi mã nguồn
—Các thay đổi hay gây lỗi:
—Một chương trình con có thể bị xóa hay thay đổi
—Một dòng nhãn có thể bị xóa hay thay đổi
—Một biến có thể bị xóa hay thay đổi
—Các thay đổi để tăng khả năng thực hiện
—Việc đóng mở file có thể bị thay đổi
—Các phép toán logic có thể bị thay đổi
—Thay đổi thiết kế => 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ề
Thay đổi dữ liệu
—Các thay đổi thường gây lỗi:
—Định nghĩa lại các hằng cục bộ
—Định nghĩa lại các cấu trúc hay file
—Tăng hay gảim kích thướng một mảng
—Thay đổi dữ liệu toàn cục
—Định nghĩa lại các flag hay pointer
—Xếp lại các tham số input/output hay tham số của chương trình con
Hiệu ứng lề
Thay đổi 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
—Với tài liệu thiết kế: Hiệu ứng kề xẩy ra trong
những lần bảo trì sau đó khi tham khảo đến các tài
liệu kỹ thuật dẫn đến đánh giá sai về đặc tính của
phần mềm
—Đối với người sử dụng, phần mềm chỉ tốt khi có tài
Các hình thức bảo trì tiên tiến
Bảo trì “Mã chương trình xa lạ”
—Yourdon đưa ra các đề nghị:
—Nghiên cứu chương trình trước khi bị đặt vào “chế
độ khẩn cấp” Cố gắng thu nhận được càng nhiều thông tin cơ sở càng tốt
—Cố gắng làm quen với toàn bộ các luồng điều khiển của chương trình; trước hết bỏ qua các chi tiết của code Sẽ rất có ích nếu vẽ sơ đồ cấu trúc và sơ đồ luồng hoạt động cấp cao nếu chưa có bản nào tồn
Trang 8Các hình thức bảo trì tiên tiến
—Đánh giá tính hợp lý của tài liệu hiện có, bổ sung
các chú thích của bản thân vào mã nguồn thấy cần
—Sử dụng tốt các danh sách chỉ dẫn tham khảo, các
bảng ký hiệu, các trợ giúp khác thường được các
chương trình dịch cung cấp
—Thực hiện sửa đổi chương trình với sự chú ý lớn
nhất Lưu ý đến các kiểu và dạng của chương trình
tại tất cả các chổ có thể Đánh dấu trên chương trình
các lệnh đã sửa
Các hình thức bảo trì tiên tiến
—Đừng loại bỏ chương trính trừ phí chắc chắn nó không sử dụng được nữa
—Đừng sử dụng chung các biến tạm thời và vùng nhớ làm việc đã có sẵn trong chương trình Thêm các biến riêng của bạn để tránh các rắc rối
—Giữ các bản ghi chép chi tiết (về hoạt động bảo trì
và kết quả)
—Tránh sự nóng vội ném bỏ chương trình cũ đi và viết lại
—Thực hiện các kiểm tra lỗi
Các hình thức bảo trì tiên tiến
Reverse Engineering và Re-engineering
—Công nghệ phản hồi (Reverse Engineering) bắt
nguồn từ phần cứng: công nhân tháo rời sản phẩm
để tìm thiết kế và bí quyết của đối thủ
—Tổ chức lại (Re-engineering) là quá trình khám phá
thiết kế Các công cụ RE lấy ra dữ liệu, kiến trúc,
các thông tin thủ tục từ chương trình đã tồn tại
—RE không đơn thuần phát hiện các thông tin thiết kế
mà còn dùng các thông tin để biến đổi hay tổ chức
lại với mục đích cải thiện chất lượng
Các hình thức bảo trì tiên tiến
Quy trình Re-engineering
—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ình
—Mô-đun hoá chương trình: tổ chức lại cấu trúc chương trình
—Tái kỹ nghệ dữ liệu: thu dọn và cấu trúc lại dữ liệu
hệ thống
Trang 9Các hình thức bảo trì tiên tiến Các hình thức bảo trì tiên tiến
Bảo trì phòng ngừa
—Thay vì đợi đến khi nhận được yêu cầu bảo trì, các tổ chức phát triển hay bảo trì chọn một chương trình mà:
— Sẽ được sử dụng trong một số năm định trước
— Hiện đang sử dụng tốt
— Dễ bị thay đổi hay nâng câp trong tương lai gần
Chiến lược “Phần mềm thành phần”
—Một đặc tính của phần cứng là thay bộ phận hư hỏng bằng phụ tùng mới Với phần mềm, khái niệm nguyên mẫu được Spiegel trình bày như sau:
Các hình thức bảo trì tiên tiến
“Nguyên mẫu phần mềm là một quá trình mô hình
hóa yêu cầu của người dùng trong một hay nhiều
mức chi tiết, bao gồm cả các mô hình làm việc Các
tài nguyên của dự án được xếp đặt làm sao để sản
xuất các phiên bản phần mềm được mô tả theo yêu
cầu phải nhỏ đi Phiên bản nguyên mẫu làm cho
người dùng, người thiết kế và quản tri… có thể xem
lại được phần mềm Quá trình đó sẽ tiếp tục khi
được đề nghị, với phiên bản đang chạy chuẩn bị
phát hành sau vài lần làm lại.”
Các hình thức bảo trì tiên tiến
—Nếu các mức khác nhau của nguyên mẫu được phát triển Có thể có một bộ các phụ tùng phần mềm đươc sử dụng khi có yêu cầu bảo trì, hiệu chỉnh
—Ví dụ: Một mô-đun phân tích có thể được thiết kế và thực hiện theo 2 cách khác nhau nhưng có cùng giao diện bên ngoài Một phiên bản được sử dụng trong phần mềm làm việc Nếu mô-đun đó hỏng, sẽ có phụ tùng thay thế ngay
—Mặt dù chiến lược phụ tùng thay thế có vẻ khác thường, nhưng không có bằng chứng là nó tốn kém hơn khi tính
