Tài liệu phần Bảo trì phần mềm trong môn Kỹ nghệ phần mềm cho lớp 56PM, Khoa Công nghệ thông tin, Trường Đại học Xây Dựng.

1. III. Bảo trì phần mềm
Bảo trì phần mềm đã được đặc trưng là “núi băng trôi”. Thực tế, ta biết rằng rất nhiều vấn
đề tiềm năng và chi phí nằm ở dưới bề mặt. Việc bảo trì phần mềm hiện có, có thể chiếm đến
70% phần mềm toàn bộ nỗ lực chi tiêu của tổ chức phần mềm. Trong phạm vi này, chúng ta có
thể dự kiến một tổ chức phần mềm hướng bảo trì, nó phải dành tất cả tài nguyên có sẵn cho
việc bảo trì phần mềm cũ.
Bản chất thay đổi thường xuyên nằm trong mọi công việc phần mềm. Thay đổi là điều
không tránh khỏi khi hệ thống dựa trên máy tính được xây dựng. Do đó, chúng ta phải xây
dựng cơ chế để đánh giá, kiểm soát và thực hiện những thay đổi.
III.1 Định nghĩa về bảo trì phần mềm
Chúng ta định nghĩa bảo trì bằng cách mô tả 4 hoạt động cần thực hiện sau
(1) Trong khi dùng bất kỳ chương trình lớn nào, lỗi sẽ xuất hiện và được báo về cho người
phát triển, tiến trình bao gồm việc chuẩn đoán và sửa một hay nhiều lỗi được gọi là bảo trì sửa
chữa
(2) Hoạt động thứ 2, đóng góp thêm vào việc bảo trì, xuất hiện bởi sự thay đổi nhanh
chóng thường gặp trong mọi khía cạnh của tính toán. Các thế hệ phần cứng mới dường như
được công bố theo chu kỳ 24 tháng, các hệ điều hành mới xuất hiện đều đặn, thiết bị ngoại vi
và các phần tử hệ thống khác thường xuyên được thay đổi và nâng cấp. Đời sống có ích của
phẩn mềm ứng dụng lại có thể kéo dài hơn 10 năm, sống lâu hơn môi trường hệ thống ban đầu
nó được phát triển. Do đó bảo trì thích nghi - một hoạt động làm thay đổi phần mềm để khớp
với môi trường thay đổi - vừa cần thiết lại vừa phổ biến
(3) Hoạt động thứ 3 có thể được áp dụng cho định nghĩa về bảo trì xuất hiện khi bộ trình
phần mềm đã thành công. Khi phần mềm được dùng người ta nhận được từ người dùng
những khuyến cáo về khả năng mới, những sửa đổi về chức năng hiện tại và những nâng cấp
chung. Để thoả mãn những yêu cầu này, việc bảo trì hoàn thiện được tiến hành.
(4) Hoạt động bảo trì thứ 4 xuất hiện khi phần mềm được thay đổi để cải thiện tính bảo trì
và hay tin cậy sau này, hay đưa ra một cơ sở tốt hơn cho khả năng nâng cấp trong tương lai,
thường được gọi là bảo trì phòng ngừa.

2. III.2 Các đặc trưng bảo trì
Việc bảo trì phần mềm cho mãi đến rất gần đây vẫn là giai đoạn bị bỏ quên trong tiến trình
kỹ nghệ phần mềm còn tương đối ít nghiên cứu hay sản phẩm được thu thập về chủ đề này và
cũng chỉ có vài cách tiếp cận hay phương pháp đã được đưa ra.
Để hiểu các đặc trưng của bảo trì phầm mềm, ta xét chủ đề này theo 3 quan điểm khác
nhau:
1. Các hoạt động đòi hỏi hoàn thành trong giai đoạn bảo trì và tác động của cách tiếp cận
kỹ nghệ phần mềm lên tính hiệu quả của các hoạt động này.
2. Chi phí đối với giai đoạn bảo trì
3. Các vấn đề thường gặp phải khi việc bảo trì được tiến hành
III.2.1 Bảo trì có cấu trúc so với phi cấu trúc
Luồng các sự kiện có thể xuất hiện như kết quả của nhu cầu bảo trì được minh hoạ trong
hình vẽ dưới.
Nếu phần tử sẵn có của cấu hình phần mềm là chương trình gốc thì hoạt động bảo trì bắt
đầu với một đánh giá cẩn thẩn về mã. Những đặc trưng tinh vi như cấu trúc chương trình, cấu
trúc dữ liệu toàn cục, giao diện hệ thống, các ràng buộc hiệu năng thì khó chắc chắn được và
thường bị hiểu sai. Các phép kiểm thử hồi quy ( lặp lại phép thử quá khứ để đảm bảo rằng
những sửa đổi không đưa lỗi vào phần mềm) không thể nào tiến hành được vì không có tải liệu
ghi lại việc kiểm thử. Chúng ta đang tiến hành việc bảo trì phi cấu trúc và phải trả giá ( lãng phí
công sức, chán nản …)
Nếu tồn tại một cấu hình phần mềm đầy đủ, thì bảo trì bắt đầu với việc đánh giá về tài liệu
thiết kế. Cấu trúc quan trọng, hiệu năng, các đặc trưng giao diện của phần mềm được xác định.
Tác động của các sửa đổi hay sửa chữa sẽ được thẩm định. Bản thiết kế sẽ được sửa đổi và
xét duyệt lại.

3. H4.7 Bảo trì có cấu trúc so với bảo trì phi cấu trúc
Dãy các sự kiện trong hình vẽ này lập nên bảo trì có cấu trúc và xuất hiện như kết quả của
việc áp dụng phương pháp luận kỹ nghệ phần mềm.
III.2.2 Chi phí bảo trì
Chi phí cho việc bảo trì phần mềm đã tăng dần trong 20 năm qua, trong những năm 70,
việc bảo trì chiếm khoàng 35 % đến 40 % ngân sách phần mềm, con số này nhẩy lên xấp xỉ 60
% trong những năm 1980.
Chi phí về tiền là mối quan tâm hiển nhiên của chúng ta . Tuy nhiên, những chi phí ít thấy
khác cuối cùng lại có thể là nguyên nhân cho mối quan tâm lớn hơn. Các chi phí vô hình khác
bao gồm : Sự không thoả mãn của khách hàng khi các yêu cầu sửa chữa hay thay đổi có vẻ
hợp lý lại không được đề cập tới một cách hợp thời. Sự suy giảm chất lượng phần mềm tổng
Yêu cầu
bảo trì
Cấu
hình
?
Đánh giá thiết kế
Lập KH tiếp cận
Thay đổi thiết kế
Mã hoá lại
Duyệt
Đánh giá mã
?
Mã hoá lại
Duyệt
Kiểm thử &
phát hành

4. thể xem như kết quả của những thay đổi tạo thêm lỗi trong những phần mềm đã được bảo trì.
Biến động đột ngột xảy ra trong nỗ lực phát triển khi nhân viên bị kéo sang làm công việc bảo
trì.
Chi phí cuối cùng cho việc bảo trì phần mềm giảm rất nhiều theo hiệu suất, điều thường
gặp phải khi việc bảo trì chương trình cũ được khởi đầu, đã có báo cáo về việc giảm hiệu suất
40:1 tức là nỗ lực phát triển tốn 25$/ 1 dòng mã cho việc xây dựng thì có thể tốn tới 1000$ cho
mỗi dòng cần bảo trì. Chi phí có thể tăng lên theo hàm mũ nếu cách tiếp cận phát triển phần
mềm nghèo nàn ( tức là thiếu kỹ nghệ phần mềm) được sử dụng và người hay nhóm dùng
cách tiếp cận này còn chưa sẵn có để thực hiện việc bảo trì. Việc thiếu kiểm soát và kỷ luật
trong các hoạt động phát triển kỹ nghệ phần mềm gần như bao giờ cũng biến thành vấn đề
trong bảo trì phần mềm.
III.3 Tổ chức bảo trì
Mặc dầu tổ chức bảo trì chính thức không nhất thiết phải thành lập, nhưng một sự uỷ
quyền không chính thức thì tuyệt đối cần cho mọi nhà phát triển phần mềm nhỏ. Một sơ đồ như
vậy được minh hoạ trong hình dưới. Các yêu cầu bảo trì được chuyển qua kênh người kiểm
soát bảo trì, người chuyển tiếp từng yêu cầu đánh giá cho người giám sát hệ thống. Người
giám sát hệ thống là thành viên của của bộ phận kỹ thuật, những người đã được trao trách
nhiệm phải trở nên am hiểu từng tập con nhỏ nhất trong các chương trình sản phẩm. Một khi
việc đánh giá đã được tiến hành thì người có thẩm quyền điều khiển thay đổi phải xác định
hành động cần tiến hành.
Tổ chức được gợi ý trên nhằm giảm bớt những lẫn lộn và cải tiến luồng hoạt động bảo trì.
Vì yêu cầu bảo trì đều trút về một cá nhân (hoặc nhóm) nên những thay đổi không được thừa
nhận dễ gây ra lỗi sẽ khó xảy ra. Vì ít nhất một cá nhân bao giờ cũng có một sự am hiểu nào đó
với chương trình, nên yêu cầu thay đổi có thể được thẩm định nhanh chóng hơn.
Mỗi tiêu đề công việc trên đều thiết lập nên một lĩnh vực trách nhiệm cho bảo trì. Người
kiểm soát và quyền điều khiến sự thay đổi có thể là một người hay với các hệ thống lớn có thể
là một nhóm các nhà quản lý và nhân viên kỹ thuật cấp cao. Khi các trách nhiệm được trao hết
để bắt đầu hoạt động bảo trì thì sự lẫn lộn được giảm đi rất nhiều. Nhưng quan trọng hơn cả là
việc xác định trách nhiệm sớm có thể kiềm chế bất kể cảm giác khó chịu nào vẫn thường xảy ra
khi một người bị kéo ra khỏi nỗ lực phát triển để tiến hành công việc bảo trì.

5. H4.8 Tổ chức
Quyền điều
khiển thay đổi
Người quản
lý cấu hình
Người kiểm
soát
Người giám
sát hệ thống
Đội ngũ nhân
viên bảo trì
Yêu cầu
bảo trì

6. III.4 Luồng sự kiện
Dãy các sự kiện cuất hiện như một yêu cầu bảo trì được vẽ ở hình dưới. Yêu cầu đầu tiên
là xác định kiểu bảo trì cần được tiến hành. Trong nhiều trường hợp, người dùng có thể xét yêu
cầu như một chỉ dẫn về lỗi phần mềm (bảo trì sửa chữa) trong khi người phát triển có thể coi
yêu cầu đó là thích nghi hoặc nâng cấp. Nếu tồn tại các ý kiến khác nhau thì cần thương lượng
về giải pháp.
Yêu cầu bảo trì
Kiểu?
Kiểu?
Nghiê
m
trọng?
Ước lượng phân
loại đặt vào hàng
đợi
Ước lượng
phân loại
Hoạt động
chữa cháy
Hành
động
Thông tin
cần thông
báo
Ưu tiên đưa
vào hàng
đợi
Chọn nhiệm vụ
tiếp theo trong
hàng đợi
Lập kế hoạch, tổ
chức ứng dụng
Còn
lại?
Áp dụng tài
nguyên cho phát
triển phần mềm
Ước lượng phân
loại đặt vào hàng
đợi
Không
Có
Bỏ Làm
Thích nghi Nâng cao
Khác
Lỗi
Rất Không

7. H4.9 Luồng bảo trì các sự kiện
Một yêu cầu cho bảo trì sửa lỗi bắt đầu với một với một ước lượng về mức nghiêm trọng
của lỗi. Nếu lỗi nghiêm trọng xuất hiện thì nhân sự sẽ được phân bổ theo chỉ thị của người
giám sát hệ thống và việc phân tích vấn đề được bắt đầu ngay lập tức. Với những lỗi ít nghiêm
trọng hơn yêu cầu về bảo trì sửa chữa được ước lượng, phân loại và lập lịch cùng với các
nhiệm vụ khác. Trong một số trường hợp một lỗi có thể nghiêm trọng đến mức việc kiểm soát
thông thường về bảo trì tạm thời bị ngưng lại. Chương trình phải được sửa đổi lập tức, cách
chữa cháy này cho bảo trì sửa chữa chỉ được dành riêng cho các khủng hoảng và nên biểu thị
cho một số phần trăm rất nhỏ trong hoạt động bảo trì. Sau khi giải quyết xong khủng hoảng thì
những hoạt động này phải được tiến hành để bảo đảm rằng những lỗi hiện tại sẽ không lan
truyền các vấn đề nghiêm trọng hơn.
Các yêu cầu về bảo trì thích nghi và hoàn thiện thì đi theo một con đường khác. Việc thích
nghi được ước lượng và phân loại trước khi được đặt vào hàng đợi các hoạt động bảo trì. Việc
nâng cấp cũng trải qua cùng ước lượng này, tuy nhiên không phải tất cả các yêu cầu nâng cao
đều được tiến hành. Những sự nâng cấp cần được tiến hành cũng đặt vào hàng đợi. Độ ưu
tiên cho mỗi yêu cầu đều được thiết lập và công việc cần thiết sẽ được lên lịch dường như nó
là một nỗ lực phát triển khác, nếu một số ưu tiên thật cao được nêu ra thì công việc có thể bắt
đầu ngay lập tức.
Trong thực tế việc bảo trì phần mềm là kỹ nghệ phần mềm được áp dụng đệ quy. Sự nhấn
mạnh sẽ dịch chuyển theo từng kiểu bảo trì nhưng cách tiếp cận toàn bộ cũng không thay đổi.
Sự kiện cuối cùng trong luồng bảo trì phần mềm và việc xét duyệt làm hợp lệ lại tất cả các phần
tử của cấu hình phần mềm.
III.5 Bảo trì chương trình xa lạ
Gần như mọi tổ chức phần mềm chín muồi đều phải duy trì các chương trình đã phát triển
từ 15 năm trước hay hơn nữa. Những chương trình như vậy đôi khi được gọi là chương trình
xa lạ vì không còn nhân viên kỹ thuật nào tiếp tục làm việc phát triển chương trình đó nữa hoặc
không áp dụng được phương pháp luận phát triển nào do đó gây ra kiến trúc và dữ liệu nghèo
nàn, tài liệu thì không đầy đủ và việc ghi lại những thay đổi trong quá khứ thì rất sơ sài.
Ngay từ đầu phần này chúng ta đã thảo luận về sự cần thiết với người giám sát hệ thống -
người đã quen thuộc đối với một tập con các chương trình cần phải bảo trì. Việc làm quen với
các chương trình này đã được tiến hành bằng cách dùng cách tiếp cận kỹ nghệ phần mềm có

8. điều kiện thuận tiện là có cấu hình phần mềm đầy đủ và thiết kế tốt. Vậy phải làm gì với các
chương trình xa lạ?
1. Nghiên cứu chương trình trước khi bạn đi vào, cố gắng có đươc nhiều thông tin nền
tảng nhất có thể được
2. Cố gắng quên thuộc với luồng điều khiển của toàn bộ chương trình, bỏ qua chi tiết mã
hoá ban đầu. Sẽ rất ích lợi nếu bạn tự vẽ ra được biểu đồ cấu trúc và sơ đồ khối mức cao nếu
chưa có.
3. Ước lượng tính hợp lý của tài liệu hiện có, đưa thêm vào lời giải thích của bạn trong bản
in chương trình gốc nếu bạn nghĩ chúng có ích.
4. Dùng các bản in tham khảo chéo tốt, các bảng ký hiệu và các trợ giúp khác mà nói
chung cho trình biên dịch hay hợp dịch cung cấp.
5. Thay đổi chương trình với sự thận trọng lớn nhất. Hãy tôn trọng các và định dạng của
chương trình nếu có thể được. Hãy chỉ ra trên bản in những lệnh nào bạn đã thay đổi.
6. Đừng huỷ bỏ mã lệnh trừ phi bạn chắc chắn là nó không được dùng tới
7. Đừng cố dùng chung biến tạm thời và bộ nhớ làm việc đã có trong chương trình, hãy
thêm vào các biến của riêng mình để tránh rắc rối.
8. Hãy giữ các bản ghi chi tiết về hoạt động và kết quả bảo trì
9. Tránh sự thôi thúc mạnh mẽ vứt chương trình đi và viết lại nó. (Tuy nhiên đôi khi thôi
thúc này cũng hợp lý và thực tế).
10. Đừng xen lẫn việc kiểm tra lỗi
Những hướng dẫn trên sẽ giúp cho việc bảo trì các chương trình cũ.