14/9/2009 1 Chươ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 thoả mãn yêu cầu hệ thống. 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 cho những mở rộng sau nầy. 14/9/2009 2 Bả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ếtkế 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 Phần mềm Mã 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 14/9/2009 3 Bả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 — Dùng các ngôn ngữ lập trình chuẩn 14/9/2009 4 Bả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 14/9/2009 5 Các công việc bảo trì - Quy trình Yêucầu bảo trì Kiểu? Bảotrì lỗi Bảotrì khác lỗi khác Quy trình bảo trì phần mềm 1 2 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 Cao Thấ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 Thích nghi Nâng cấp Hoạt động Yêu cầu thông tin bổ sung Đặt thứ tự ưu tiên trong hàng đợi Không làm Làm 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 phát triển phần mềm mới Còn nhiệm vụ? Không Có 14/9/2009 6 Cá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ì 14/9/2009 7 Hiệ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 liệu hướng dẫn sử dụng. 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 tại. 14/9/2009 8 Cá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 14/9/2009 9 Cá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 đến tất cả chi phí cho tất cả chu kỳ sống của phần mềm . cầu — Các dữ liệu cần cho việc sửa đổi 14/9/2009 5 Các công việc bảo trì - Quy trình Yêucầu bảo trì Kiểu? Bảotrì lỗi Bảotrì khác lỗi khác Quy trình bảo trì phần. 14/9/2009 2 Bả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