c. Các test case cho chức năng thống kê phòng theo doanh thu
10.1.3 Quản lý bảo trì sau khi chuyển giao
• Các vấn đề khác nhau về mặt quản lý bảo trì sau khi chuyển giao cần được xem xét • Trước tiên, người lập trình bảo trì nên xem xét tệp bản ghi khuyết điểm
• Nó bao gồm
o Tất cả các lỗi đã được ghi lại mà chưa sửa và
o Những đề nghị về các công việc sẽ thực thiện về những khuyết điểm đó • Trong một thế giới lý tưởng
o Sửa tất cả mọi lỗi ngay lập tức
o Sau đó chúng ta công bố phiên bản phần mềm mới ở mọi vị trí • Trong thế giới thực
o Phân bố các bản ghi lỗi ở tất cả các vị trí
o Không có nhân viên để bảo trì ngay lập tức
o Thực hiện nhiều thay đổi ở cùng một lúc sẽ rẻ hơn, đặc biệt nếu có nhiều vị trí cài đặt
a- Các bản ghi khuyết điểm
• Cần một cơ chế đối với việc thay đội sản phẩm phần mềm
• Nếu sản phẩm phần mềm xuất hiện một chức năng không đúng, thì người dùng đưa ra một bản ghi khuyết điểm
o Bản ghi đó phải đủ thông tin để cho phép người lập trình bảo trì tái tạo lại vấn đề • Theo lý tưởng, mỗi khuyết điểm nên được cố định ngay lập tức
o Trong thực tế, tốt nhất chúng ta có thể làm là nghiên cứu sơ bộ ngay lập tức • Nếu khuyết điểm đã được ghi lại trước đó: Đưa thông tin trong tệp bản ghi khuyết điểm
tới người dùng
• Nếu nó là một khuyết điểm mới:
o Người lập trình bảo trì nên cố gắng tìm
Cách để sửa khuyết điểm đó, và
Cách làm việc xung quanh vấn đề đó
o Khuyết điểm mới được ghi lại vào tệp tường trình phát hiện lỗi, cùng với tài liệu
Dánh sách (Listings)
Thiết kế (Designs)
Sổ tay (Manuals)
o Tệp bản ghi khuyết điểm cũng nên chứa những yêu cầu cảu khách hàng để bảo trì thích hợp và hoàn thiện chức năng
Nội dung của tệp phải được định độ ưu tiên bởi khách hàng
Những chỉnh sửa tiếp theo là một trong những nội dung có độ ưu tiên cao nhất trong tệp
o Các bản sao của bản ghi khuyết điểm phải lưu hành tới tất cả
Bao gồm: ước lượng khi nào khuyết điểm được sửa
o Nếu cùng thất bại xảy ra ở một vị trí khác, người dùng có thể xác định
Khả năng làm việc xung quanh khuyết điểm
Thời gian mà khuyết điểm được sửa b- Cho phép thay đổi phần mềm
• Bảo trì sửa lỗi
o Chỉ định một người lập trình bảo trì xác định lỗi và nguyên nhân của lỗi, sau đó sửa lỗi đó
o Kiểm thử sửa chữa, kiểm thử toàn bộ phẩn mềm (kiểm thử hồi quy)
o Cập nhật tài liệu để phản ánh những thay đổi đã thực hiện
o Cập nhật những lời giải thích ban đầu để phản ánh
Những gì đã thay đổi,
Tại sao nó được thay đổi,
Ai thực hiện thay đổi, và
Khi nào
• Bảo trì thích hợp và hoàn thiện
o Giống với bảo trì sửa lỗi, ngoại trừ không có bản ghi khuyết điểm
o Thay vì có thay đổi trong yêu cầu
• Điều gì sẽ xảy ra nếu người lập trình không kiểm thử những lỗi đã được sửa một cách thích đáng?
o Trước khi phần mềm được phân phối, thì phần mềm phải được kiểm thử bởi nhóm SQA
• Bảo trì sau khi chuyển giao là cực kỳ khó • Kiểm thử là khó và tiêu tốn thời gian
o Được thực hiện bởi nhóm SQA
• Kỹ thuật phiên bản cơ sở và các bản sao riêng phải được sử dụng
• Người lập trình thực hiện các thay đổi đối với các bản sao chép riêng của các mô đun mã và kiểm thử chúng
• Người lập trình đóng băng phiên bản trước đó, và đưa ra phiên bản chỉnh sửa cho nhóm SQA để kiểm thử
c- Bảo đảm việc bảo trì
• Bảo trì không là sự cố gắng một lần (Maintenance is not a one-time effort) • Phải lập kế hoạch cho bảo trì xuyên suốt toàn bộ vòng đời phần mềm
o Luồng công việc thiết kế - sử dụng kỹ thuật ẩn dấu thông tin
o Luồng cài đặt – lựa chọn đặt tên có ý nghĩa để thuận tiện cho những người lập trình trong tương lai
o Tài liệu phẩi được hoàn thiện và chính xác và phản ánh đúng phiên bản hiện thời của mỗi mô đun mã
• Trong suốt quá trình bảo trì sau khi chuyển giao, bảo trì không phải giàn
o Luôn luôn biết rõ việc bảo trì trong tương lai là không thể tránh được d- Vấn đề của bảo trì lặp
• Việc thay đổi những yêu cầu phần mềm gây nhiều khó khăn cho đội phát triển • Việc thay đổi thường xuyên thường gây bất lợi cho việc bảo trì phần mềm
Thay đổi bài toán đích
• The problem is exacerbated during postdelivery maintenance • Càng nhiều thay đổi
o Thì sản phẩm phần mềm càng khác xa so với thiết kế ban đầu
o Việc thay đổi trong tương lai càng trở nên khó hơn
o Tài liệu trở nên kém tin cậy hơn bình thường
o Các file kiểm thử hồi quy không được cập nhật
o Viết lại toàn bộ có thể cần thiết đối với bảo trì trong tương lai • Giải pháp hiển nhiên
o Đóng băng các đặc tả khi chúng được ký đến tận khi chuyển giao sản phẩm phần mềm
o Sau mỗi yêu cầu của bảo trì hoàn thiện, đóng băng các đặc tả trong 3 tháng hoặc 1 năm
• Trong thực tế
o Khách hàng có thể đưa ra những thay đổi ngay ngày hôm sau
o Nếu bằng lòng với giá cả, thì khách hàng có thể đưa ra những thay đổi hàng ngày • “Ai trả tiền thì người ấy có tiền”(“He who pays the piper calls the tune”)