Bài giảng Công nghệ phần mềm - Huỳnh Xuân Hiệp - Bài 15: Giai đoạn bảo trì
Nội dung:
? Khái quát chung
? Sự cần thiết của bảo trì
? Những đòi hỏi đối với các nhà lập trình bảo trì
? Quản lý bảo trì
? Bảo trì phần mềm h-ớng đối t-ợng
? So sánh kỹ năng bảo trì và kỹ năng phát triển
? Kiểm thử
? Đánh giá
Tóm tắt nội dung Bài giảng Công nghệ phần mềm - Huỳnh Xuân Hiệp - Bài 15: Giai đoạn bảo trì, để xem tài liệu hoàn chỉnh bạn click vào nút "TẢI VỀ" ở trên
Huỳnh Xuân Hiệp - CNPM 178 15 GIAI ĐOạN BảO TRì(MAINTENANCE PHASE) Nội dung: Khái quát chung Sự cần thiết của bảo trì Những đòi hỏi đối với các nhà lập trình bảo trì Quản lý bảo trì Bảo trì phần mềm h−ớng đối t−ợng So sánh kỹ năng bảo trì và kỹ năng phát triển Kiểm thử Đánh giá Huỳnh Xuân Hiệp - CNPM 179 15.1 Khái quát chung (overview) Giai đoạn bảo trì bắt đầu sau khi khách hàng đã chấp thuận sản phẩm và cần có các thay đổi trên sản phẩm Các thể hiện của bảo trì: mã nguồn, tài liệu, h−ớng dẫn sử dụng,... Còn gọi là sự tiến triển (evolution) để chỉ rõ sự phát triển của sản phẩm thay vì gọi đó là bảo trì Huỳnh Xuân Hiệp - CNPM 180 15.2 Sự cần thiết của bảo trì (why maintenance is necessary) Hiệu chỉnh (corrective maintenance): khoảng 17.5%; các lỗi đặc tả , thiết kế, tài liệu, mã nguồn hay các dạng khác VD: Nghiên cứu trên 69 công ty của [Lientz, Swanson và Tompkins] Hoàn thiện (perfective maintenance): khoảng 60.5%; các thay đổi về mã lệnh nhằm hoàn thiện hiệu năng của sản phẩm VD: Khách hàng yêu cầu thêm một số chức năng hay sửa đổi sản phẩm để tăng tốc độ xử lý Thích ứng (adaptive maintenance): khoảng 18%; các thay đổi nhằm tác động lại những thay đổi trong môi tr−ờng mà sảnphẩm đang vận hành. Khách hàng phải chịu chi phí (external imposed) VD: thay đổi trình biên dịch, hệ điều hành hay phần cứng Huỳnh Xuân Hiệp - CNPM 181 Các dạng khác (other types of maintenance): khoảng 4%; thuộc các dạng khác ngoài ba dạng kể trên Hình 15.1 Các khoảng thời gian cho mỗi dạng bảo trì Huỳnh Xuân Hiệp - CNPM 182 15.3 Những đòi hỏi đối với các nhà lập trình bảo trì (what is required of maintenance programmers) Hình thành thuật ngữ nhà lập trình bảo trì (maintenance programmer - MP) Đây là khía cạnh khó khăn nhất, nhiều thách thức, của một sản phẩm phần mềm vì đụng chạm đến tất cả các giai đoạn trong tiến trình xây dựng phần mềm Nghịch lý hiện nay tại các công ty: xem nhẹ công tác bảo trì giao các công đoạn bảo trì cho các lập trình viên mới VD: Xem xét các khả năng xảy ra khi một báo cáo về lỗi sản phẩm không làm việc giống nh− trong h−ớng dẫn sử dụng đ−ợc chuyển đến cho một MP; các thông tin đ−ợc điền vào theo quan điểm của ng−ời sử dụng. Các lý giải có thể có: o không có lỗi, do ng−ời sử dụng hiểu không chính xác h−ớng dẫn sử dụng hoặc sử dụng sản phẩm không đúng cách o h−ớng dẫn sử dụng đ−ợc viết không chính xác o lỗi tại mã nguồn Huỳnh Xuân Hiệp - CNPM 183 MP phải có kỹ năng lần vết (debugging skills) tốt để xác định chính xác vị trí lỗi Lỗi hồi qui (regression fault): sửa chữa lỗi có quan tâm đến các lỗi khác trong sản phẩm Chuẩn bị tài liệu chi tiết cho toàn bộ sản phẩm cũng nh− cho từng mô-đun riêng biệt sau khi sửa chữa xong Đ−ợc xem nh− là dịch vụ hậu mãi (after-sales service), giữ khách hàng bằng cách cung cấp những dịch vụ bảo trì tốt nhất Là chuẩn mực cho sự thành công của công ty phần mềm Huỳnh Xuân Hiệp - CNPM 184 15.4 Quản lý bảo trì (management of maintenance) Xây dựng cơ chế cho phép có những thay đổi trên sản phẩm khi bảo trì Lãnh đạo nhóm SQA và lãnh đạo nhóm phát triển phần mềm phải độc lập với nhau Các báo cáo lỗi (fault reports) ng−ời sử dụng điền các thông tin về lỗi trên các chức năng đủ thông tin để MP có thể tái tạo lại lỗi ủy quyền thay đổi trên sản phẩm (authorizing changes to the product) xác định lỗi, thay đổi mã nguồn, cố định mã nguồn kiểm thử qui hồi (regression testing) trên toàn bộ sản phẩm cập nhật các tài liệu để phản ánh các thay đổi có thể cập nhật tài liệu về đặc tả cũng nh− thiết kế tạo phiên bản mới chuyển đến nhóm SQA để xác nhận lại (nh−ng không đ−ợc can thiệp vào công việc của các lập trình viên) Huỳnh Xuân Hiệp - CNPM 185 Bảo đảm công tác bảo trì (ensuring maintainability) việc bảo trì phải đ−ợc thực hiện nhiều lần tạo nhiều phiên bản có kế hoạch bảo trì trong suốt tiến trình phần mềm ghi nhận cẩn thận các thông tin kỹ thuật tài liệu phải đ−ợc hoàn tất và hiệu chỉnh chu đáo, phản ánh chính xác mọi thành phần của phiên bản hiện hành Vấn đề về sự lặp lại công tác bảo trì (problem of repeated maintenance) khách hàng th−ờng xuyên thay đổi các yêu cầu nên đ−a ra mô hình làm việc, khi có thay đổi thì khách hàng sẽ phải trả thêm chi phí phát triển Huỳnh Xuân Hiệp - CNPM 186 15.5 Bảo trì phần mềm h−ớng đối t−ợng (maintenance of object-oriented software) Dễ dàng bảo trì các đối t−ợng do các khái niệm độc lập nên dễ dàng xác định vị trí nhằm hiệu chỉnh hay nâng cao các thay đổi chỉ tác dụng bên trong đối t−ợng nên giảm thiểu các lỗi hồi qui Khó khăn: MP phải nghiên cứu toàn bộ các cây thừa kế khi cài đặt trên ngôn ngữ lập trình h−ớng đối t−ợng: vấn đề đa hình và động khi lần vết các thừa kế liên tục nhau khi có một lớp nào đó có một số thay đổi Huỳnh Xuân Hiệp - CNPM 187 15.6 So sánh kỹ năng bảo trì và kỹ năng phát triển (maintenance skills versus development skills) Khả năng Kỹ năng bảo trì Kỹ năng phát triển Xác định nguyên nhân gây ra lỗi Hiệu chỉnh Kiểm thử tích hợp và kiểm thử phát triển Thực hiện hiệu quả các chức năng mà không có tài liệu thích hợp Hoàn thiện, thích ứng Đặc tả, thiết kế, cài đặt và tích hợp, kiểm thử Nắm vững các vấn đề liên quan trên các giai đoạn Đòi hỏi nh− nhau Huỳnh Xuân Hiệp - CNPM 188 15.7 Kiểm thử giai đoạn bảo trì (testing during the maintenance phase) Khó khăn khi phải nắm vững toàn bộ sản phẩm Cách tiến hành: sử dụng các tình huống kiểm thử (test cases) để đảm bảo sản phẩm vẫn còn vận hành tốt sau khi đã có cập nhật thay đổi một số tình huống kiểm thử l−u trữ toàn bộ các tình huống kiểm thử với kết quả cần đạt t−ơng ứng Sử dụng kiểm thử hồi qui Huỳnh Xuân Hiệp - CNPM 189 15.8 Đánh giá giai đoạn bảo trì (metrics for the maintenance phase) Sử dụng cách đánh giá cho các giai đoạn liên quan nh− trong quá trình phát triển Ngoài ra còn có: số l−ợng báo cáo lỗi phân loại lỗi theo độ khó và kiểu lỗi thông tin về trạng thái hiện hành của báo cáo lỗi VD: 13 báo cáo lỗi nghiêm trọng đã đ−ợc xử lý, 03 báo cáo lỗi nghiêm trọng ch−a đ−ợc xử lý.
File đính kèm:
Bài giảng Công nghệ phần mềm - Huỳnh Xuân Hiệp - Bài 15 Giai đoạn bảo trì.pdf
