Nhập môn Công nghệ phần mềm - Trần Đình Quế

huyển giao là một khía cạnh thử thách nhất của phần mềm và bạc 
bẽo nhất 
 Những người quản lý phải chỉ định công việc bảo trì cho những người lập trình giỏi nhất 
và 
 Trả lương cho họ phù hợp 
11.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 
 Nguyên nhân, 
 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) 
P
T
I
T
Chương 11: Pha bảo trì 
180 
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ử 
 SQA thực hiện kiểm thử trên phiên bản cơ sở của tất cả các mô đun mã 
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 
P
T
I
T
Chương 11: Pha bảo trì 
181 
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”) 
11.1.4 Bảo trì sau khi chuyển giao với kỹ năng phát triển 
 Những kỹ năng cần thiết cho bảo trì gồm 
o Khả năng xác định nguyên nhân gây ra lỗi của một phần mềm lớn 
 Cũng cần thiết trong suốt quá trình tích hợp và kiểm thử sản phẩm 
o Khả năng thực hiện chức năng có hiệu quả mà không cần có tài liệu chính xác 
 Tài liệu hiếm khi được hoàn thiện đến tận khi chuyển giao 
o Kỹ năng phân tích, thiết kế, cài đặt và kiểm thử 
 Tất cả bốn hoạt động được thực thi trong suốt quá trình phát triển 
 Những kỹ năng cần thiết cho bảo trì sau khi chuyển giao giống với những kỹ năng của tất 
cả các luồng công việc khác 
 Điểm chính 
o Người lập trình bảo trì không phải chỉ có kỹ năng rộng ở mọi lĩnh vực mà những 
kỹ năng đó phải ở trình độ cao 
o Sự chuyên môn hóa không thể có ở những người lập trình bảo trì 
11.1.5 Kỹ nghệ ngược 
 Khi nào tài liệu duy nhất đối với bảo trì sau khi chuyển giao là mã nguồn thì 
o Bắt đầu với mã 
o Tái tạo lại thiết kế 
o Tái tạo lại các đặc tả (cực kỳ khó) 
o Công cụ CASE có thể trở giúp ((flowcharters, các mục đích trực quan khác) 
P
T
I
T
Chương 11: Pha bảo trì 
182 
 Kỹ nghệ lại 
o Kỹ nghệ ngược, được sinh ra bởi kỹ nghệ tiên tiến (Reverse engineering, followed 
by forward engineering) 
o Mức độ thấp hơn tới cao hơn tới thấp hơn của trừu tượng (Lower to higher to 
lower levels of abstraction) 
 Xây dựng lại 
o Việc cải thiện sản phẩm phần mềm mà không có thay đổi chức năng phần mềm 
o Ví dụ: 
 Cải thiện việc bảo trì 
 Xây dựng lại(XP, agile processes) 
 Điều gì sẽ xảy ra nếu chúng ta chỉ có mã thực thi? 
o Xem xét phần mềm như hộp đen 
o Suy luận những đặc tả từ hành vi của phần mềm hiện thời 
11.1.6 Công cụ CASE cho bảo trì sau khi chuyển giao 
 Công cụ điểu khiển cấu hình là cần thiết 
o Công cụ thương mại 
 CCC 
o Công cụ mã nguồn mở 
 cvs 
 Các công cụ kỹ nghệ lại 
o Các công cụ thương mại 
 IBM Rational Rose, Together 
o Các công cụ mã nguồn mở 
 Doxygen 
 Các công cụ theo dõi – phát hiện 
o Công cụ thương mại 
 IBM Rational ClearQuest 
o Công cụ mã nguồn mở 
 Bugzilla 
10.1.7 Thước đo của bảo trì sau khi chuyển giao 
 Về bản chất, các hoạt động của bảo trì sau khi chuyển giao là những hoạt động của quá 
trình phát triển 
o Các thước đo đối với luồng công việc phát triển 
 Các thước đo bản ghi khuyết điểm (Defect report metrics) 
o Sự phân loại khuyết điểm 
o Trạng thái khuyết điểm (Defect status) 
10.1.8 Những thách thức của bảo trì sau khi chuyển giao 
 Chương này miêu tả rất nhiều thách thức 
 Thách thức khó nhất cần giải quyết 
o Bảo trì khó hơn phát triển, nhưng 
o Những người phát triển có xu hướng nhìn xuống (tend to look down) những người 
bảo trì và 
o Thường xuyên được trả tiền lương nhiều hơn 
P
T
I
T
Chương 11: Pha bảo trì 
183 
11.2 BẢO TRÌ HỆ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 
 Bề ngoài, mô hình hướng đối tượng khuyến kích việc bảo trì theo bốn cách 
o Phần mềm bao gồm các đơn vị độc lập 
o Đóng gói (độc lập về mặt khái niệm) 
o Ẩn giấu thông tin (độc lập về mặt vật lý) 
o Truyền tham số là các giao tiếp duy nhất (Message-passing is the sole 
communication) 
 Thực thế hơi khác (The reality is somewhat different) 
 Ba cản trở 
Một là: Cây phân cấp kế thừa có thể lớn 
 Để hình dung ra những gì displayNode làm trong BalancedBinaryTreeClass, chúng 
ta phải kiểm tra tỉ mỉ cây hoàn thiện 
o Cây hoàn thiện có thể trải rộng toàn bộ phần mềm 
o Khác xa “những đơn vị độc lập ” (A far cry from “independent units” ) 
o Giải pháp 
o Công cụ CASE có thể dàn mỏng cây kế thừa (A CASE tool can flatten the 
inheritance tree) 
Hai là:Hậu quả của liên kết động và đa hình 
P
T
I
T
Chương 11: Pha bảo trì 
184 
 Hệ thống không hoạt động khi gọi myFile.open () 
 Phiên bản nào của open có chứa lỗi? 
o Công cụ CASE không thể trợ giúp (công cụ tĩnh) 
o Chúng ta phải theo dõi (kiểm tra) 
 Liên kết động và đa hình có thể có 
o Ảnh hưởng tích cực tới đội phát triển nhưng 
o Ảnh hưởng tiêu cực đối với bảo trì 
Ba là: Hậu quả của kế thừa 
 Tạo một lớp mới qua kế thừa 
 Lớp con mới 
o Không ảnh hưởng tới lớp cha, và 
o Không ảnh hưởng tới bất cứ lớp con 
o Chỉnh sửa lớp con mới này 
o Một lần nữa, không ảnh hưởng 
o Chỉnh sửa lớp cha 
o Tất cả các lớp con kế thừa đều bị ảnh hưởng 
o “Fragile base class problem” 
 Kế thừa có 
o Ảnh hưởng tích đối với người phát triển, nhưng 
o Ảnh hưởng tiêu cực đối với bảo trì 
11.3 KIỂM THỬ PHA BẢO TRÌ 
 Người bảo trì xem xét phần mềm như một tập các thành phần có liên quan lỏng lẻo 
o Chúng không liên quan đến sự phát triển phần mềm 
 Kiểm thử hồi quy là cần thiết 
o Lưu giữ các trường hợp kiểm thử và đầu ra của chúng, chỉnh sửa nếu cần thiết 
P
T
I
T