Các kĩ thuật bảo trì phần mềm trong môn học Công nghệ phần mềm của trường Bưu Chính Viễn Thông

1. HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
---------------------------------------
Bảo trì phần mềm
Môn học: Nhập môn CNPM
Giảng viên: Thạc Bình Cường
Nhóm SV: Nguyễn Duy – B14DCCN514
Phạm Trung Đức – B13DCAT056
Lâm Viết Thái – B14DCCN465
Nguyễn Hữu Thắng – B12
Nhóm: G12
Hà nội, ngày 12 tháng 5 năm 2017

2. Mục lục
Danh mục các thuật ngữ viết tắt ......................................................................................1
Danh sách các bảng ...........................................................................................................2
Danh sách hình ảnh...........................................................................................................3
Danh sách phần việc thực hiện.........................................................................................4
Lời dẫn................................................................................................................................5
Chương 1: Giới thiệu về bảo trì phần mềm ....................................................................6
1.1. Định nghĩa về bảo trì phần mềm ........................................................................6
1.2. Phân loại các dạng bảo trì phần mềm................................................................7
1.2.1. Bảo trì để tu sửa ............................................................................................7
1.2.2. Bảo trì để thích hợp.......................................................................................8
1.2.3. Bảo trì để hoàn thiện.....................................................................................9
1.2.4. Bảo trì để phòng ngừa...................................................................................9
1.3. Phương pháp cải tiến thao tác bảo trì:.............................................................10
Chương 2: Qui trình và các mô hình bảo trì phần mềm .............................................12
2.1. Qui trình bảo trì.................................................................................................12
2.1.1. Bước phân tích.............................................................................................15
2.1.2. Bước thiết kế................................................................................................16
2.1.3. Bước triển khai............................................................................................17
2.1.4. Bước kiểm tra hệ thống ..............................................................................18
2.1.5. Bước thử nghiệm nghiệm thu.....................................................................19
2.1.6. Bước giao nhận............................................................................................20
2.2. Các mô hình bảo trì phần mềm ........................................................................21
2.2.1. Mô hình bảo trì nhanh chóng Quick-fix ...................................................21
2.2.2. Mô hình Boehm ...........................................................................................22
2.2.3. Mô hình Osborne.........................................................................................24
2.2.4. Mô hình cải tiến lặp lại ...............................................................................26
2.2.5. Mô hình tái sử dụng định hướng ...............................................................27
2.2.6. Mô hình bảo trì Taute.................................................................................28
Chương 3: Các vấn đề trong bảo trì phần mềm...........................................................30

3. 3.1. Kĩ nghệ đảo ngược (Reverse Engineering):.....................................................30
3.1.1. Giới thiệu......................................................................................................30
3.1.2. Định nghĩa....................................................................................................30
3.1.3. Mục đích và các mục tiêu của kỹ thuật đảo ngược..................................31
3.1.4. Các mức độ của kĩ thuật đảo ngược..........................................................32
3.1.5. Kỹ thuật hỗ trợ............................................................................................33
3.1.6. Lợi ích...........................................................................................................34
3.2. Kiểm thử hồi quy................................................................................................35
3.3. Chi phí bảo trì ....................................................................................................37
Chương 4: Việc xử lí tài liệu trong bảo trì phần mềm.................................................40
4.1. Lời dẫn ................................................................................................................40
4.2. Qui trình sinh tài liệu sản phẩm.......................................................................41
4.3. Tài liệu qui trình ................................................................................................41
4.4. Tài liệu sản phẩm...............................................................................................42
4.4.1. Tài liệu người dùng .....................................................................................42
4.4.2. Tài liệu hệ thống..........................................................................................44
Tổng kết............................................................................................................................46
Tài liệu tham khảo...........................................................................................................47

4. 1
Danh mục các thuật ngữ viết tắt
Từ Ý nghĩa
ANSI American National Standards Institute
CM Check Modification
CR Correction Request
HR Human Resources
IEEE The Institute of Electrical and Electronics Engineers
MR Modification Request
PM Project Manager

5. 2
Danh sách các bảng
Trang
Bảng 2.1: Năm đặc thù quan trọng cho mỗi bước 13
Bảng 2.2: Các yêu cầu xác định bảo trì 13
Bảng 2.3: Các bước xác định yêu cầu thay đổi 14
Bảng 3.1: Định nghĩa các thành phần của kĩ nghệ dịch ngược 30
Bảng 3.2: Lợi ích của kĩ thuật Reverse Engineering 35

6. 3
Danh sách hình ảnh
Trang
Hình 1.1: Các loại hình bảo trì 7
Hình 2.1: Bảy bước thực hiện bảo trì theo chuẩn IEEE/EIA 219 12
Hình 2.2: Các bước thực hiện với lượng yêu cầu thay đổi 15
Hình 2.3: Các bước thực hiện pha phân tích 16
Hình 2.4: Chi tiết thực hiện bước thiết kế 17
Hình 2.5: Chi tiết thực hiện bước thiết kế 18
Hình 2.6: Chi tiết bước kiểm tra hệ thống 19
Hình 2.7: Các bước thử nghiệm nghiệm thu. 20
Hình 2.8: Các bước trong quá trình giao nhận 20
Hình 2.9: Mô hình Quick-fix 21
Hình 2.10: Vòng đời mô hình Boehm 25
Hình 2.11: Mô hình bảo trì Osborne 25
Hình 2.12: Ba bước của mô hình cải tiến lặp lại 26
Hình 2.13: Mô hình tái sử dụng 27
Hình 2.14: Minh họa mô hình Taute 29
Hình 3.1: Minh họa về quá trình cải thiện phần mềm. 32
Hình 3.2: Các mức độ kĩ thuật đảo ngược 32
Hình 4.1: Năm loại tài liệu phục vụ đối tượng khác nhau 43

7. 4
Danh sách phần việc thực hiện
Thành viên Phần việc thực hiện Trang
Nguyễn Duy Chương 1: Giới thiệu về bảo trì phần mềm 6 - 11
Phạm Trung Đức Chương 2: Qui trình và các mô hình bảo trì phần mềm 12 - 29
Lâm Viết Thái Chương 3: Các vấn đề trong bảo trì phần mềm 30 - 39
Thắng Chương 4: Việc xử lí tài liệu trong bảo trì phần mềm 40 - 46

8. 5
Lời dẫn
Trong ngành công nghiệp phần mềm, không thể tạo ra được một hệ thống hoàn hảo mà lại
không có thay đổi. Trong suốt thời gian tồn tại của một hệ thống, các yêu cầu ban đầu sẽ
thay đổi do nhu cầu của khách hàng và người sử dụng. Đây chính là nhiệm vụ của việc
bảo trì phần mềm trong ngành này. Khác với vạn vật sống, phần mềm không tự chết đi
(trừ khi không có điện), phần mềm có thể sẽ tự sống và chỉ “chết” đi nếu không còn người
tác động sử dụng, hoặc không còn được công ty mẹ hỗ trợ. Chính vì thế, việc bảo trì phần
mềm là một nhánh cực kì cần thiết trong ngành tin học nói chung. Bài tìm hiểu của nhóm
12 về phần này sẽ đi qua sơ lược và khái quát các kiến thức cơ bản của việc bảo trì phần
mềm, giúp người đọc có một cái nhìn tổng quát về nó.

9. 6
Chương 1: Giới thiệu về bảo trì phần mềm
1.1. Định nghĩa về bảo trì phần mềm
Bảo trì phần mềm là một quá trình mà một chương trình máy tính bị thay đổi
hoặc cập nhật sau khi nó được phát hành. Mặc dù thuật ngữ "bảo trì" có thể hàm ý
sửa chữa và sửa chữa sai sót, chỉ một phần của quá trình này được dự định cho
mục đích này, được gọi là "khắc phục". Phần lớn bảo trì phần mềm được sử dụng
cho công việc "thích nghi" để đảm bảo chương trình tiếp tục có hiệu quả và có thể
sử dụng được trong môi trường thay đổi cũng như các thủ tục "hoàn hảo" cải tiến
chức năng. Việc bảo trì "dự phòng" được sử dụng để làm cho quy trình trở nên dễ
dàng hơn trong tương lai bằng cách cung cấp các tài liệu bổ sung và các công cụ
để làm cho những cập nhật sau này trở nên đơn giản hơn.
Phần lớn bảo trì phần mềm được thực hiện thông qua các miếng vá được tạo ra bởi
một nhà phát triển và sau đó phát hành ra công chúng. Các tệp này được cài đặt
bởi một người dùng máy tính và họ sửa đổi các chức năng và thiết kế của chương
trình cơ sở trên một hệ thống. Điều này được thực hiện sau khi phát hành một
chương trình, mặc dù phát triển phần mềm sớm nên bảo trì xem xét.
Bảo trì phần mềm sửa chữa là quá trình phát triển các thay đổi cho một chương
trình sửa chữa lỗi hoặc khắc phục sự cố. Điều này không thêm bất kỳ tính năng
mới, trừ khi chúng đã tồn tại nhưng không thể được sử dụng do lỗi trong lập
trình. Chỉ khoảng một phần tư tất cả các phần mềm bảo trì phần mềm được sử
dụng cho các vấn đề khắc phục, tuy nhiên nó thường được coi là yếu tố quan trọng
nhất của người sử dụng chương trình.
Phần lớn bảo trì phần mềm được gọi là "adaptive", được sử dụng để điều chỉnh
một chương trình để hoạt động trong một môi trường mới. Các chương trình
thường được thiết kế và phát triển để hoạt động trên một hệ điều hành nhất định
(OS). Trong khi một số phần mềm có thể hoạt động trên các phiên bản mới hơn,
có rất nhiều chương trình không thể làm như vậy. Một miếng vá thích ứng cho
một chương trình có thể làm thay đổi mã để cho phép nó hoạt động đúng trên một
hệ thống mới, giữ cho nó hiện tại và có thể sử dụng được.
Bảo trì phần mềm hoàn hảo được sử dụng để thêm các tính năng mới vào sản
phẩm và thực hiện những thay đổi có thể trực tiếp ảnh hưởng đến người dùng. Một
công ty có thể phát hành một chương trình xử lý văn bản, ví dụ như bao gồm một
vài tính năng kiểm tra chính tả. Nếu họ phát hành một bản vá cập nhật từ điển
trong chương trình, và tạo thêm các tùy chọn sửa lỗi, thì nó sẽ được coi là sự bảo
trì hoàn hảo. Những nâng cấp này thường khá nhỏ, vì những cuộc cải tổ lớn
thường đòi hỏi phải phát hành phiên bản mới hoặc phần mềm "khách hàng".

10. 7
Các nhà phát triển cũng có thể làm việc về bảo trì phần mềm dự phòng, được
sử dụng để thay đổi trong tương lai thậm chí còn đơn giản hơn. Sau khi phát triển,
một công ty có thể nhận ra rằng có khả năng cho một lỗi mà vẫn chưa phát
triển. Họ có thể phát hành một bản vá sửa vấn đề này trước khi nó thực sự trở
thành vấn đề. Tài liệu bổ sung và dọn dẹp mã cũng có thể được thực hiện để giúp
bảo trì trong tương lai dễ dàng hơn hoặc không cần thiết.
Hình 1.1: Các loại hình bảo trì
1.2. Phân loại các dạng bảo trì phần mềm
1.2.1. Bảo trì để tu sửa
Bảo dưỡng sửa chữa là một hình thức bảo trì được thực hiện sau khi lỗi hoặc sự
cố xuất hiện trong hệ thống, với mục đích khôi phục tính hoạt động. Trong một số
trường hợp, không thể dự đoán hoặc ngăn ngừa sự thất bại, làm cho loại bảo trì này
là lựa chọn duy nhất.
Bảo dưỡng sửa chữa đề cập đến hành động chỉ thực hiện khi xảy ra sự cố hệ thống
hoặc thành phần. Đó là một chiến lược hồi tố. Nhiệm vụ của nhóm bảo trì trong
kịch bản này thường là để sửa chữa càng sớm càng tốt. Chi phí liên quan đến bảo
dưỡng sửa chữa bao gồm:
 Chi phí sửa chữa
 Mất sản xuất
 Mất doanh thu

11. 8
Quá trình bảo dưỡng sửa chữa bắt đầu với một chẩn đoán về sự thất bại trong việc
xác định lý do tại sao nó xảy ra. Tiến trình chẩn đoán có thể bao gồm:
 Kiểm tra vật lý của một hệ thống
 Sử dụng máy tính chẩn đoán để đánh giá hệ thống
 Phỏng vấn người dùng
 Nhiều bước khác
Điều quan trọng là phải xác định nguyên nhân của sự cố để có hành động phù hợp
và phải nhận thức được nhiều thành phần hoặc lỗi hệ thống có thể xảy ra đồng
thời.
Kiểu bảo trì để tu sửa xuất hiện do các nguyên nhân:
 Kỹ sư phần mềm và khách hàng không hiểu ý nhau.
 Lỗi tiềm ẩn phần mềm do sơ ý lập trình hoặc kiểm tra chưa bao quát
kĩ
 Vấn đề tính năng của phần mềm bị lỗi.
 Thiếu chuẩn hóa trong phát triển phần mềm
Khi áp dụng hoạt động bảo trì này, ta cần lưu ý đến:
 Kỹ thuật dịch ngược: dò lại thiết kế để tu sửa
 Mức độ trừu tượng và tương tác của phần mềm.
 Tính đầy đủ của phần mềm
1.2.2. Bảo trì để thích hợp
Sự phát triển của hệ thống để đáp ứng nhu cầu của người sử dụng và doanh
nghiệp. Kiểu bảo trì này gây ra bởi:
 Nhu cầu nội bộ, cạnh tranh với các đối thủ.
 Do các hệ điều hành mới, các thiết bị ngoại vi mới thường
xuyên được xuất hiện và nâng cấp, cần bảo trì phần mềm
theo cách này để phần mềm có thể tiếp tục hoạt động trên
các nền tảng mới.
Bảo dưỡng thích ứng cũng hàm ý sự cần thiết phải sửa đổi một số chức năng, mặc
dù hệ thống hoạt động như mong đợi. Nó thường xảy ra khi có sự thay đổi trong
các quy phạm pháp luật hoặc sự thay đối trong những người sử dụng chính trị.

12. 9
Những thay đổi như vậy thường gây ra sự khác biệt trong hệ thống ban đầu và các
thông số của nó, và do đó cần phải hài hòa và thực hiện các chức năng mới dựa
trên yêu cầu cảu người dùng. Bảo trì thích ứng được chia thành hai nhóm:
A. Những thay đổi được điều chỉnh bởi sự thay đổi của luật pháp
hoặc các quy định khác trong nước.
B. Các thay đổi không bị điều chinh bởi sự thay đổi các quy định
pháp luật hoặc quy định khác ở nước của người đang sử dụng
1.2.3. Bảo trì để hoàn thiện
Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy
đủ hơn, hợp lý hơn. Bảo trì hoàn thiện nhằm đưa ra một thiết kế cùng chức năng
nhưng có chất lượng cao hơn. Những nguyên nhân chính để xảy ra được kiểu bảo trì
này là:
 Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức
truy cập.
 Mở rộng thêm chức năng mới cho hệ thống.
 Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công
việc.
 Thay đổi người dùng hoặc thay đổi thao tác.
Các bước thực hiện:
 Xây dựng lưu đồ phần mềm.
 Suy dẫn ra biểu thức Bun cho từng dãy xử lý.
 Biên dịch bảng chân lí (Đúng / Sai)
 Tái cấu trúc phần mềm.
1.2.4. Bảo trì để phòng ngừa.
Bảo trì dự phòng đề cập đến việc bảo trì định kỳ, thường xuyên để giúp giữ
thiết bị hoạt động, ngăn ngừa bất kỳ thời gian chết không kế hoạch và chi phí đắt
tiền từ thất bại thiết bị không lường trước. Nó đòi hỏi phải lập kế hoạch cẩn thận và
lập kế hoạch bảo trì thiết bị trước khi có một vấn đề thực tế cũng như giữ hồ sơ
chính xác của các kiểm tra trong quá khứ và phục vụ các báo cáo. Quản lý dự phòng
có thể rất phức tạp, đặc biệt đối với các công ty có rất nhiều thiết bị. Vì lý do này,
nhiều công ty dựa vào phần mềm bảo dưỡng dự phòng để giúp tổ chức và thực hiện
tất cả các nhu cầu bảo trì dự phòng của họ.

13. 10
Yêu cầu bảo dưỡng dự phòng chính xác sẽ thay đổi tùy thuộc vào hoạt động và loại
thiết bị. Các tiêu chuẩn được đề nghị của Viện Tiêu chuẩn Quốc gia Hoa Kỳ
( ANSI ) được sử dụng để giúp xác định loại kiểm tra và bảo trì cần thiết và tần suất
chúng nên được thực hiện. ANSI giúp đảm bảo sức khoẻ và sự an toàn của người
tiêu dùng bằng cách tạo ra và giám sát việc sử dụng hàng ngàn hướng dẫn và tiêu
chuẩn cho hầu hết các ngành công nghiệp và các tiêu chuẩn ANSI có thể được sử
dụng như một danh sách kiểm tra bảo dưỡng dự phòng để xác định các yêu cầu và
hướng dẫn để duy trì thiết bị.
Bảo trì dự phòng bao gồm nhiều hơn là chỉ đơn giản thực hiện bảo trì thường xuyên
trên thiết bị. Nó cũng bao gồm việc duy trì các hồ sơ chính xác của mọi kiểm tra và
phục vụ, cũng như biết được tuổi thọ của từng bộ phận để hiểu được tần suất thay
thế. Những hồ sơ này có thể giúp các kỹ thuật viên bảo trì dự đoán thời gian thích
hợp để thay đổi các bộ phận và cũng có thể giúp chẩn đoán các vấn đề khi chúng
xảy ra. Phần mềm bảo trì dự phòng giúp thu thập và tổ chức thông tin này để nó có
sẵn cho các kỹ thuật viên bảo trì.
Bảo trì dự phòng cung cấp cho công ty một số lợi ích quan trọng bao gồm:
 Tuổi thọ của phần mềm
 Thời gian ngừng hoạt động không theo kế hoạch do sự cố phần
mềm
 Ít không cần thiết bảo trì và kiểm tra
 Ít lỗi hơn trong hoạt động hàng ngày
 Cải thiện độ tin cậy của phần mềm
 Ít sửa chữa đắt tiền gây ra bởi sự thất bại phần mềmbất ngờ mà
phải được cố định nhanh chóng. Lý tưởng nhất là lịch trình bảo trì
ngăn ngừa tất cả các phần mềm hỏng trước khi nó xảy ra. Nó sẽ
tiết kiệm được thời gian, giảm chi phí và duy trì hoạt động hiệu
quả và hiệu quả.
1.3. Phương pháp cải tiến thao tác bảo trì:
Sáng kiến trong quy trình phát triển phần mềm:
 Chuẩn hóa mọi khâu trong phát triển phần mềm.
 Người bảo trì chủ chốt tham gia vào giai đoạn phân tích và thiết
kế.
 Thiết kế để dễ bảo trì.

14. 11
Sáng kiến trong quy trình bảo trì phần mềm:
 Sử dụng các công cụ hỗ trợ phát triển phần mềm.
 Chuẩn hóa thao tác bảo trì và thiết bị môi trường bảo trì.
 Lưu lại những thông tin lịch sử bảo trì.
 Dự án nên cử một người chủ chốt của mình làm công việc bảo trì
sau khi dự án kết thúc giai đoạn phát triển.
Phát triển những kỹ thuật mới cho bảo trì:
 Công cụ phần mềm hỗ trợ bảo trì.
 Cơ sở dữ liệu cho bảo trì.
 Quản lý tài liệu, quản lý dữ liệu, quản lý chương trình nguồn, quản
lý dữ liệu thử, quản lý sử bảo trì.

15. 12
Chương 2: Qui trình và các mô hình bảo trì
phần mềm
2.1. Qui trình bảo trì
Qui trình bảo trì phần mềm theo tiêu chuẩn IEEE /EIA 1219 giải thích rất rõ
ràng về việc thực thi và quản lí các hoạt động trong việc bảo trì phần mềm. Tiêu
chuẩn này về cơ bản giải thích rằng việc bảo trì phần mềm cũng giống như một
vòng đời cơ bản, và mô tả việc bảo trì là quá trình sản xuất một sản phẩm phần mềm
bằng cách hiệu chỉnh lại mã nguồn và cải tiến tài liệu cho việc nâng cấp. Mục tiêu
chính của nó là cải thiện chất lượng phần mềm nhưng vẫn giữ được tính toàn vẹn
của nó. Tiêu chuẩn này tập trung vào mô hình 7 bước bảo trì như trong hình dưới.
Hình 2.1: Bảy bước thực hiện bảo trì theo chuẩn IEEE/EIA 219

16. 13
Bảy bước bao gồm:
1. Xác định vấn đề
2. Phân tích
3. Thiết kế
4. Áp dụng
5. Thử nghiệm hệ thống
6. Thử nghiệm nghiệm thu
7. Bàn giao sản phẩm
Trong mỗi bước trên lại có năm đặc thù quan trọng khác:
Bảng 2.1: Năm đặc thù quan trọng cho mỗi bước
Đặc thù Ý nghĩa
Định nghĩa
hoạt động
Chỉ đến việc áp dụng qui trình của
bước thực hiện
Đầu vào
Chỉ đến thành phần yêu cầu đầu
vào của bước thực hiện
Đầu ra
Chỉ đến thành phần đầu ra của
bước thực hiện
Điều khiển
Chỉ đến thành phần cung cấp khả
năng điều khiển bước thực hiện
Đo lường
Chỉ đến thành phần đo lường trong
khi thực thi bước thực hiện
Bước xác định vấn đề: các yêu cầu đến việc thay đổi trong phần mềm thường
được tạo ra bởi những người sử dụng phần mềm, hoặc là khách hàng. Các yêu cầu
từ việc thay đổi này dẫn đến việc bảo trì phần mềm. Yêu cầu thay đổi được nộp
bằng bảng yêu cầu chỉnh sửa lỗi hoặc bản yêu cầu phát triển. Hai định nghĩa này
(Modification Request và Correction Request) thường được sử dụng trong ngôn ngữ
chung của việc bảo trì phần mềm. Việc bảo trì được sắp xếp lại như sau:

17. 14
Bảng 2.2: Các yêu cầu xác định bảo trì
Bước Chi tiết
1 Xác định loại yêu cầu
2
Xác định loại hình bảo trì phù hợp với yêu
cầu:
 Bảo trì hoàn thiện
 Bảo trì thay đổi
 Bảo trì thích hợp
3 Xác định mức độ ưu tiên
4 Gán số nhân dạng để thay đổi
Các bước nhỏ trong quá trình này bao gồm:
Bảng 2.3: Các bước xác định yêu cầu thay đổi
Bước Chi tiết
1
Từ chối hoặc chấp nhận yêu cầu chỉnh sửa
(MR – Modification Request)
2
Xác định và ước lượng nguồn lực cần có để
thay đổi chương trình
3
Đưa MR trong một loạt thay đổi theo lịch
trình để thực hiện. Quá trình thu thập và
đánh giá các MR, chẳng hạn như số MR gửi
và số MR bị từ chối, bắt đầu trong giai
đoạn này. Đối với giai đoạn xác định vấn
đề, đầu vào, đầu ra, kiểm soát và số liệu
đã được tóm tắt trong hình dưới

18. 15
Hình 2.2: Các bước thực hiện với lượng yêu cầu thay đổi
2.1.1. Bước phân tích
Các đầu vào cho giai đoạn này là một MR được xác nhận, một dự toán tài
nguyên ban đầu, thông tin kho, và tài liệu dự án. Kho lưu trữ là vị trí trong đó tất cả
các hiện vật liên quan đến phần mềm được lưu trữ. Quá trình được xem là có hai
thành phần chính: phân tích tính khả thi và phân tích chi tiết. Đầu tiên, phân tích
tính khả thi được thực hiện để:
 Xác định tác động của sự thay đổi.
 Khảo sát các giải pháp khả thi khác bao gồm cả việc tạo mẫu.
 Đánh giá cả chi phí ngắn hạn và dài hạn và sự thay đổi.
Sau khi lựa chọn phương pháp tiếp cận cụ thể, giai đoạn 2 của phân tích chi tiết
được thực hiện. Giai đoạn thứ hai xác định:
 Yêu cầu về sửa đổi chính.
 Các thành phần phần mềm tham gia.
 Chiến lược kiểm tra tổng thể
 Kế hoạch thực hiện.

19. 16
Tiêu chuẩn nhấn mạnh vào ít nhất ba mức độ kiểm tra: đơn vị, tích hợp và chấp
nhận. Ngoài ra, các bài kiểm tra hồi quy được kết hợp với ba mức độ kiểm tra. Hình
minh họa tóm tắt đầu vào, kiểm soát, số liệu, và đầu ra cho giai đoạn phân tích.
Sau khi hoàn thành giai đoạn phân tích, một số bước được thực hiện: phân tích
rủi ro được thực hiện; dự toán tài nguyên sơ bộ được cập nhật; và bằng cách liên
quan đến khách hàng, quyết định có tiến hành giai đoạn tiếp theo hay không. Nếu
quyết định chuyển sang giai đoạn tiếp theo, thì các sản phẩm giai đoạn, bao gồm
một báo cáo phân tích chi tiết, được xác định cụ thể.
Tiêu chuẩn cho thấy một số chỉ số được thu thập, chẳng hạn như số lượng yêu
cầu thay đổi, thời gian trôi qua, và tỷ lệ lỗi được tạo ra.
Hình 2.3: Các bước thực hiện pha phân tích
2.1.2. Bước thiết kế
Việc sửa đổi hệ thống bắt đầu trong giai đoạn này dựa trên thông tin thu thập
được cho đến thời điểm này. Thông tin bao gồm tài liệu hệ thống và dự án, đầu ra
của giai đoạn phân tích, phần mềm hiện có và thông tin kho. Các hoạt động của giai
đoạn này như sau:
 Xác định các thành phần phần mềm bị ảnh hưởng
 Chỉnh sửa các thành phần phần mềm
 Ghi lại những thay đổi

20. 17
 Tạo bộ kiểm tra cho thiết kế mới
 Chọn các trường hợp thử nghiệm để kiểm tra hồi quy.
Giai đoạn này cung cấp một đường cơ sở thiết kế được sửa đổi, các kế hoạch
thử nghiệm đã được chỉnh sửa, báo cáo phân tích chi tiết, phân tích rủi ro được sửa
đổi và các yêu cầu đã được kiểm chứng. Hình dưới tóm tắt các đầu vào, đầu ra, số
liệu, và kiểm soát cho giai đoạn thiết kế.
Hình 2.4: Chi tiết thực hiện bước thiết kế
2.1.3. Bước triển khai
Giai đoạn thiết kế tạo ra các đầu vào chính cho giai đoạn này. Các hoạt động
thực hiện trong giai đoạn này là: viết mã mới và thực hiện kiểm tra đơn vị, tích hợp
mã thay đổi, thực hiện kiểm tra tích hợp và hồi quy, thực hiện phân tích rủi ro, và rà
soát hệ thống sẵn sàng kiểm tra. Để đánh giá có hay không hệ thống đã sẵn sàng để
kiểm tra cấp hệ thống, một đánh giá được thực hiện trong giai đoạn này. Trong giai
đoạn này, phân tích và đánh giá rủi ro được thực hiện định kỳ chứ không phải vào
cuối giai đoạn. Nhiều bài đánh giá cần được thực hiện do thực tế là phần lớn các
thiết kế, các vấn đề về hiệu suất, rủi ro và chi phí bị tiết lộ trong khi thay đổi hệ
thống. Tất cả tài liệu, bao gồm phần mềm, thiết kế, kiểm tra, người dùng và thông
tin đào tạo được cập nhật. Đối với giai đoạn triển khai, đầu vào, đầu ra, số liệu và
kiểm soát được tóm tắt trong hình dưới.

21. 18
Hình 2.5: Chi tiết thực hiện bước thiết kế
2.1.4. Bước kiểm tra hệ thống
Trong giai đoạn này, các phép thử được thực hiện trên toàn bộ hệ thống để đảm
bảo rằng hệ thống đã được điều chỉnh phù hợp với các yêu cầu ban đầu cũng như
các sửa đổi mới. Kiểm tra mức hệ thống bao gồm một loạt các hoạt động thử
nghiệm: kiểm tra chức năng, kiểm tra tính ổn định, kiểm tra tính ổn định, kiểm tra
tải, kiểm tra hiệu suất, kiểm tra an ninh và kiểm tra hồi quy. Thử nghiệm hồi quy
được tiến hành để xác nhận rằng không có lỗi mới đã được giới thiệu. Khá thường
xuyên, trong quá trình bảo trì, các kỹ sư kiểm tra bền vững thực hiện các trường hợp
kiểm tra hệ thống.
Cuối cùng, nhân viên bảo trì xác minh liệu hệ thống đã sẵn sàng để thực hiện
kiểm tra chấp nhận hay không. Giai đoạn này chấp nhận việc đưa ra kế hoạch kiểm
thử hệ thống bao gồm các trường hợp kiểm tra chi tiết, báo cáo đánh giá độ sẵn sàng
kiểm tra, và một hệ thống cập nhật. Giai đoạn này cung cấp một báo cáo thử
nghiệm, một hệ thống kiểm tra được tích hợp đầy đủ và báo cáo đánh giá độ sẵn
sàng kiểm tra. Đối với giai đoạn thử nghiệm hệ thống, đầu vào, đầu ra, số liệu và
kiểm soát được tóm tắt trong hình dưới.

22. 19
Hình 2.6: Chi tiết bước kiểm tra hệ thống
2.1.5. Bước thử nghiệm nghiệm thu
Thử nghiệm chấp nhận được thực hiện trên một hệ thống tích hợp hoàn toàn, nó
bao gồm khách hàng, người dùng hoặc đại diện của họ. Mục tiêu chính của việc thử
nghiệm chấp nhận là đánh giá chất lượng chung của hệ thống hơn là xác định các
khuyết tật. Trái lại, mặt khác, mục tiêu thử nghiệm hệ thống là tìm kiếm các lỗi, các
ngoại lệ.
Một khái niệm quan trọng trong việc kiểm tra chấp nhận là đáp ứng yêu cầu của
khách hàng từ hệ thống. Các đầu vào chính cho giai đoạn này báo cáo đánh giá độ
sẵn sàng kiểm tra, một hệ thống tích hợp hoàn chỉnh và một kế hoạch kiểm tra với
các trường hợp thử nghiệm chi tiết để kiểm tra chấp nhận. Khi kết thúc thử nghiệm
chấp nhận, một báo cáo thử nghiệm được tạo ra. Báo cáo giải thích tình trạng của
tiêu chí đã được thống nhất để hoàn thành thành công thử nghiệm nghiệm thu. Báo
cáo hiện trạng được thông báo cho ủy ban có trách nhiệm xem xét lại. Khách hàng
làm chủ tịch ủy ban đánh giá để đánh giá tiêu chí xuất cảnh và báo cáo thử nghiệm
để đảm bảo rằng hệ thống đã sẵn sàng cho việc phát hành. Đối với giai đoạn thử
nghiệm chấp nhận, đầu vào, đầu ra, số liệu và kiểm soát được tóm tắt trong hình
dưới đây.

23. 20
Hình 2.7: Các bước thử nghiệm nghiệm thu.
2.1.6. Bước giao nhận
Trong giai đoạn này, hệ thống thay đổi được phát hành cho khách hàng để cài
đặt và vận hành. Bao gồm trong giai đoạn này là các hoạt động sau: thông báo cho
cộng đồng người sử dụng, thực hiện cài đặt và đào tạo, và phát triển một phiên bản
lưu trữ của hệ thống để sao lưu. Đối với giai đoạn phân phối, đầu vào, đầu ra, số liệu
và kiểm soát được tóm tắt trong hình dưới.
Hình 2.8: Các bước trong quá trình giao nhận

24. 21
Các hướng dẫn về thực hành bảo trì cũng được đề xuất bởi tiêu chuẩn trong phụ
lục của phần mềm. Ví dụ, hướng dẫn thực hành bảo trì bao gồm một hướng dẫn để
lập kế hoạch bảo trì; bảng dưới đây cho thấy các phần chính của một kế hoạch bảo
trì.
2.2. Các mô hình bảo trì phần mềm
Việc bảo trì phần mềm đã được chú ý tới nhưng các mô hình bảo trì không được
phát triển tốt, hiểu rõ như các mô hình phát triển phần mềm. Khi phần mềm phát
triển, hoặc gặp nhiều sự cố khác nhau, nắm rõ được các nguyên tắc cũng như
phương pháp bảo trì là điều cần thiết. Sau đây chúng ta cùng điểm qua các phương
pháp bảo trì phổ biến trong ngành công nghiệp phần mềm.
2.2.1. Mô hình bảo trì nhanh chóng Quick-fix
Về cơ bản đây là cách tiếp cận đặc biệt để duy trì phần mềm mang tính “chữa
cháy”, chờ sự cố xảy ra và sau đó cố gắng khắc phục nó càng nhanh càng tốt.
Trong mô hình này, các bản sửa lỗi sẽ được thực hiện mà không cần phân tích
chi tiết về ảnh hưởng dài hạn, ví dụ như ảnh hưởng đối với cấu trúc mã. Bảo trì theo
kiểu Quick-fix sẽ không, hoặc chỉ có rất ít tài liệu. Đến thời điểm ngày nay, mô hình
quick-fix đôi khi vẫn được áp dụng.
Hình 2.9: Mô hình Quick-fix
Môi trường quick-fix có thể hiệu quả trong môi trường phần mềm phát triển bảo
trì chỉ cần một người. Khi đó, lập trình viên dễ dàng bảo trì mà không cần đến, hoặc
cần rất ít đến tài liệu mà công việc vẫn hoàn thành. Quick-fix nhanh gọn và có chi
phí rẻ.

25. 22
Tuy nhiên, môi trường như vậy không phải là tiêu chuẩn trong ngành công
nghiệp, trong khi thực tế cần xem xét việc sử dụng mô hình này trong bối cảnh
thông thường hơn của một hoạt động thương mại có một lượng khách hàng lớn. Vậy
tại sao đến giờ các công ty tổ chức lớn đôi khi vẫn cho phép sử dụng mô hình không
đáng tin cậy như sửa lỗi nhanh Quick-fix? Áp lực lớn nhất là thời gian và nguồn lực.
Nếu khách hàng yêu cầu sửa lỗi, ví dụ như khách hàng có thể không sẵn sàng chờ
đợi công ty dành thời gian để thực hiện các giai đoạn chi tiết và của phân tích rủi ro.
Khi đó nếu thực hiện đầy đủ chuẩn hóa phần mềm, công ty rất có thể mất khách
hàng.
Nhưng về vấn đề dài hạn, nếu một tổ chức chỉ dựa vào quickfix, nó sẽ đối mặt
các vấn đề khó khăn và rất tốn kém, do đó sẽ mất đi bất kỳ lợi thế nào từ việc sử
dụng mô hình sửa lỗi nhanh Quick-fix ngay từ đầu.
Chiến lược tốt nhất được thông qua là để kết hợp các kỹ thuật Quick-fix vào
một mô hình phức tạp hơn. Bằng cách này bất kỳ thay đổi nào vội vã qua vì áp lực
bên ngoài sẽ tạo ra một nhu cầu được công nhận để bảo trì dự phòng sẽ sửa chữa bất
kỳ thiệt hại được thực hiện.
Hạn chế của mô hình Quick-fix rất rõ ràng. Cần phải phân biệt giữa việc nâng
cấp ngắn hạn và dài hạn. Ví dụ, nếu người dùng tìm thấy lỗi trong một phần mềm
thương mại, việc nhận được bản vá lỗi ngay khi đó là không thực tế. Giải pháp sẽ
được thực hiện, cùng với các sửa đổi và cải tiến khác thành một bản nâng cấp lớn
sau này.
2.2.2. Mô hình Boehm
Năm 1983 nhà khoa học máy tính nổi tiếng Barry W.Boehm đề xuất một mô
hình cho quá trình bảo trì dựa trên mô hình kinh tế và nguyên tắc. Các mô hình kinh
tế không có gì mới. Quyết định kinh tế là động lực chính đằng sau nhiều quá trình
và luận cứ của Boehm là các mô hình kinh tế và các nguyên tắc có thể không chỉ
nâng cao năng suất trong bảo trì mà còn giúp hiểu được tiến trình.
Boehm định nghĩa cho quá trình bảo trì như là một chu kỳ vòng khép kín. Ông
giả thuyết rằng đó là giai đoạn mà các quyết định quản lý được thực hiện để thúc
đẩy quá trình. Trong giai đoạn này, một bộ thay đổi được chấp thuận được xác định
bằng cách áp dụng chiến lược cụ thể và đánh giá “chi phí-lợi ích” cho một bộ thay
đổi được đề xuất. Các thay đổi được chấp thuận được kèm theo ngân sách của riêng
họ mà chủ yếu sẽ xác định mức độ và loại tài nguyên chi tiêu.

26. 23
Hình 2.10: Vòng đời mô hình Boehm
Xét về mối quan hệ sản xuất - kinh tế giữa đầu vào với quy trình và lợi ích của
nó - điều này phản ánh biểu đồ ba đoạn tiêu biểu:
Đầu tư: Đây là giai đoạn đầu vào tài nguyên thấp và lợi ích thấp. Điều này
tương quan với một sản phẩm phần mềm mới được phát hành có yêu cầu cao đối với
các bản sửa lỗi khẩn cấp và các cải tiến bắt buộc.
Lợi nhuận cao: Một tổ chức thấy lợi ích ngày càng tăng từ sản phẩm phần mềm
và những vấn đề ban đầu được giải quyết. Đây là một giai đoạn trong đó tài nguyên
được đưa vào cải tiến người dùng và cải tiến tài liệu và hiệu quả. Lợi ích tích lũy
cho tổ chức tăng nhanh trong giai đoạn này.
Giảm dần lợi nhuận: Khi vượt quá một điểm nhất định, tỷ lệ tăng lợi ích tích lũy
sẽ giảm. Sản phẩm đã đạt đến đỉnh cao về tính hữu dụng. Sản phẩm đã đạt đến giai
đoạn mà sự thay đổi cơ bản trở nên ít tốn kém hơn và ít tốn kém hơn.
Boehm nhận thấy nhiệm vụ của người quản lý bảo trì là một trong việc cân
bằng việc theo đuổi các mục tiêu bảo trì so với các ràng buộc do môi trường mà

27. 24
công việc bảo trì được tiến hành. Do đó, quá trình bảo trì được điều khiển bởi các
quyết định của người quản lý bảo dưỡng dựa trên việc cân bằng giữa các mục tiêu
với những ràng buộc.
2.2.3. Mô hình Osborne
Sự khác biệt giữa mô hình Osborne và các mô hình khác được mô tả ở đây là nó
liên quan trực tiếp với thực tế của môi trường bảo trì. Các mô hình khác có xu
hướng giả thiết một số khía cạnh của một tình huống lý tưởng - ví dụ như có các tài
liệu đầy đủ. Mô hình của Osborne tạo ra sự hỗ trợ cho mọi thứ thay vì làm thế nào
chúng ta muốn.
Mô hình bảo trì được coi là sự lặp lại liên tục của vòng đời phần mềm với mỗi
giai đoạn cung cấp cho việc bảo trì được xây dựng. Nếu các tính năng bảo trì tốt đã
tồn tại, ví dụ đầy đủ và chính thức của các đặc điểm kỹ thuật hoặc tài liệu đầy đủ, tất
cả tốt và tốt , nhưng nếu không, việc trợ cấp được thực hiện để chúng được xây
dựng.
Các giai đoạn trong chu kỳ bảo trì được thể hiện trong hình dưới bao gồm việc
nhận biết các bước mà lặp đi lặp lại thường xảy ra.

28. 25
Hình 2.11: Mô hình bảo trì Osborne
Osborne đưa ra giả thuyết rằng nhiều vấn đề kỹ thuật phát sinh trong quá trình
bảo trì là do truyền thông và kiểm soát quản lý không đầy đủ và đề xuất một chiến
lược bao gồm:
 Việc bao gồm các yêu cầu bảo trì trong đặc tả thay đổi.
 Chương trình đảm bảo chất lượng phần mềm xác lập yêu cầu đảm
bảo chất lượng.

29. 26
 Một phương tiện xác minh rằng các mục tiêu bảo trì đã được đáp
ứng.
 Đánh giá hiệu suất để cung cấp phản hồi cho các nhà quản lý.
2.2.4. Mô hình cải tiến lặp lại
Mô hình này đã được đề xuất dựa trên nguyên lý rằng việc thực hiện các thay
đổi cho một hệ thống phần mềm trong suốt thời gian của nó là một quá trình lặp đi
lặp lại và liên quan đến việc tăng cường một hệ thống như vậy một cách lặp đi lặp
lại. Nó tương tự như mô hình phát triển tiến hóa trong quá trình trước cài đặt.
Đề xuất ban đầu là một mô hình phát triển nhưng phù hợp với việc duy trì, động
lực cho điều này là môi trường mà các yêu cầu không được hiểu đầy đủ và không
thể xây dựng một hệ thống đầy đủ.
Hình 2.12: Ba bước của mô hình cải tiến lặp lại
Được điều chỉnh để duy trì, mô hình này giả định tài liệu đầy đủ vì nó dựa vào
sự sửa đổi của điều này làm điểm xuất phát cho mỗi lần lặp. Mô hình này có hiệu
quả là chu trình ba giai đoạn:
 Phân tích.
 Đặc điểm của các sửa đổi đề xuất.
 Thiết kế lại và thực hiện

30. 27
Tài liệu hiện có cho mỗi giai đoạn (yêu cầu, thiết kế, mã hóa, thử nghiệm và
phân tích) được sửa đổi bắt đầu với tài liệu cấp cao nhất bị ảnh hưởng bởi những
thay đổi được đề xuất. Những sửa đổi này được tuyên truyền thông qua các bộ tài
liệu và hệ thống được thiết kế lại.
Áp lực của môi trường bảo trì thường cho thấy một giải pháp nhanh chóng được
tìm ra, nhưng như chúng ta đã thấy, việc sử dụng giải pháp "nhanh nhất" có thể dẫn
tới nhiều vấn đề hơn là giải quyết. Giống như mô hình trước đó, việc cải tiến lặp đi
lặp lại cho phép thuần hóa các mô hình khác trong đó và do đó có thể kết hợp một
cách nhanh chóng trong môi trường có cấu trúc riêng của nó. Việc khắc phục nhanh
có thể được thực hiện, xác định khu vực khó khăn, và lần lặp kế tiếp sẽ giải quyết cụ
thể chúng.
Các vấn đề với mô hình tăng cường lặp lại bắt nguồn trong trường hợp đầy đủ
nguồn tài liệu và khả năng của đội ngũ bảo trì để phân tích các sản phẩm hiện có
đầy đủ. Trong khi việc sử dụng rộng rãi các mô hình bảo trì có cấu trúc sẽ dẫn đến
một nền văn hoá nơi tài liệu có xu hướng được cập nhật và hoàn thiện, điều này
thường không xảy ra.
2.2.5. Mô hình tái sử dụng định hướng
Mô hình này dựa trên nguyên tắc rằng bảo trì có thể được xem như là một hoạt
động liên quan đến tái sử dụng các thành phần chương trình hiện có. Mô hình tái sử
dụng mô tả bởi Victor Basili có bốn bước chính:
 Xác định các bộ phận của hệ thống cũ là những ứng cử viên để tái sử
dụng.
 Hiểu những bộ phận của hệ thống.
 Sửa đổi các bộ phận hệ thống cũ phù hợp với yêu cầu mới.
 Tích hợp các bộ phận đã được sửa đổi vào hệ thống mới.
Cần có một khung chi tiết để phân loại các thành phần và các sửa đổi có thể.
Với mô hình tái sử dụng đầy đủ, điểm xuất phát có thể là bất kỳ giai đoạn nào của
vòng đời - các yêu cầu, thiết kế, mã hoặc dữ liệu thử nghiệm - không giống như các
mô hình khác. Ví dụ, trong mô hình sửa lỗi nhanh, điểm xuất phát luôn là mã.

31. 28
Hình 2.13: Mô hình tái sử dụng
2.2.6. Mô hình bảo trì Taute
Mô hình được phát triển bởi B. J. Được dạy vào năm 1983 và rất dễ hiểu và
thực hiện. Nó là một mô hình bảo trì điển hình và có tám giai đoạn trong chu kỳ:
Hình 2.14: Minh họa mô hình Taute

32. 29
1. Thay đổi yêu cầu giai đoạn: Nhóm bảo trì nhận được yêu cầu theo định
dạng theo quy định từ khách hàng để thực hiện thay đổi. Thay đổi này có
thể thuộc bất kỳ loại hoạt động bảo trì nào.
2. Giai đoạn ước tính: Giai đoạn này được dành để ước tính thời gian và nỗ
lực cần thiết để thực hiện thay đổi. Rất khó để ước tính chính xác. Nhưng
mục tiêu là phải có ít nhất là ước tính hợp lý về thời gian và nỗ lực. Cần
phải có sự phân tích tác động lên hệ thống hiện có để giảm thiểu ảnh
hưởng gợn sóng.
3. Giai đoạn lập lịch: Xác định yêu cầu thay đổi cho lần phát hành theo kế
hoạch tiếp theo và cũng có thể chuẩn bị các tài liệu được yêu cầu để lập
kế hoạch.
4. Giai đoạn lập trình: Trong giai đoạn này, mã nguồn được sửa đổi để thực
hiện thay đổi được yêu cầu. Tất cả các tài liệu liên quan như tài liệu thiết
kế, sách hướng dẫn được cập nhật cho phù hợp. Đầu ra cuối cùng là
phiên bản thử nghiệm của mã nguồn.
5. Giai đoạn thử nghiệm: Chúng ta muốn đảm bảo rằng sửa đổi được thực
hiện đúng. Do đó, đội kiểm tra mã. Có thể sử dụng các trường hợp thử
nghiệm sẵn có và cũng có thể thiết kế các trường hợp thử nghiệm mới.
Thuật ngữ được sử dụng cho các thử nghiệm như vậy được gọi là kiểm
tra hồi quy.
6. Giai đoạn tài liệu: Sau khi kiểm tra hồi quy, hệ thống và tài liệu người
dùng được chuẩn bị và cập nhật trước khi phát hành hệ thống. Điều này
giúp chúng ta duy trì mối quan hệ giữa mã và tài liệu.
7. Giai đoạn phát hành: Sản phẩm phần mềm mới cùng với các tài liệu cập
nhật được gửi tới khách hàng. Chấp nhận thử nghiệm được thực hiện bởi
người sử dụng của hệ thống.
8. Giai đoạn vận hành: Sau khi nghiệm thu, phần mềm được đặt dưới hoạt
động bình thường. Trong quá trình sử dụng, khi một vấn đề khác được
xác định hoặc yêu cầu chức năng mới được cảm nhận hoặc thậm chí tăng
cường năng lực hiện có là mong muốn, một lần nữa một yêu cầu 'yêu cầu
thay đổi' được bắt đầu. Nếu làm như vậy, chúng ta có thể quay trở lại để
thay đổi giai đoạn yêu cầu và lặp lại tất cả các giai đoạn để thực hiện
thay đổi.

33. 30
Chương 3: Các vấn đề trong bảo trì phần
mềm
3.1. Kĩ nghệ đảo ngược (Reverse Engineering):
3.1.1. Giới thiệu
Cần phải hiểu về hệ thống phần mềm trược khi thực hiện bất kì thay đổi nào đối
với hệ thống Quá trình nhận thức cần phải phân bổ thời gian một cách hợp lý cho
việc thực hiện các thay đổi
Các lý do cho điều này bao gồm không chính xác, vượt quá thời gian dự định
không có tài liệu, sự phức tạp của hệ thống, thiếu hiểu biết về lĩnh vực, một cách có
thể làm giảm đi các khó khăn kể trên là trừu tượng hóa thông tin thích hợp, xác đáng
từ mã nguồn về hệ thống vd như đặc tả, thiết kế.
Phương pháp Reverse Engineering là kĩ thuật có thể sử dụng làm điều này.các
thay đổi được thực hiện nhờ sử dụng các phương pháp như forward engineering,
restructuring, and reengineering.
3.1.2. Định nghĩa
Bảng 3.1: Định nghĩa các thành phần của kĩ nghệ dịch ngược
Thành phần Định nghĩa
Trừu tượng
hóa
Là mô hình chứa đựng chi tiết về 1 đối tượng
Kỹ thuật
chuyển tiếp
Kĩ thuật phần mềm truyền thống thăm dò bắt
đầu với phân tích yêu cầu phần mềm, phát
triển đối với thực thi hệ thống
Reengineering
Quá trình kiểm tra và thay đổi bằng cách
chỉnh sửa hệ thống bằng kĩ thuật đảo ngược
đầu, và sau đó là kỹ thuật chuyển tiếp.
Tái cấu trúc
Việc chuyển đổi hệ thống từ kiểu này sang
kiểu khác.

34. 31
Kỹ thuật đảo
ngược
Quá trình phân tích hệ thống :
 Xác định các thành phần hệ thống và
các mối quan hệ.
 Tạo các kiểu của hệ thống trong các
mẫu khác nhau hoặc ở mức độ trừu
tượng cao hơn.
Trừu tượng
Trừu tượng là việc chọn các tính năng quan
trọng của hệ thống mà bỏ qua các tính năng
không quan trọng. Có 3 kiểu của trừu tượng
có thể biểu diễn trong hệ thống: trừu tượng
chức năng, trừu tượng dữ liệu, trừu tượng
quá trình.
3.1.3. Mục đích và các mục tiêu của kỹ thuật đảo ngược
Mục đích của kĩ thuật này là tạo thuận lợi thay đổi bằng cách cho phép hiểu
được hệ thống phần mềm làm gì, làm thế nào cấu trúc của nó ra sao.
Các mục tiêu của mục đích này là phục hồi dữ liệu đã mất thuận tiên luân
chuyển giữa các nền tảng khác nhau, phát triển và cung cấp tài liệu mới lấy ra các
thành phần tái sử dụng, giảm các nỗ lực bảo trì phần mềm, xử lý các vấn đề phức
tạp, phát hiện ra các ảnh hưởng.
Hình 3.1: Minh họa về quá trình cải thiện phần mềm.

35. 32
3.1.4. Các mức độ của kĩ thuật đảo ngược
Hình 3.2: Các mức độ kĩ thuật đảo ngược
Redocumentation:
Là tái tạo lại 1 biểu diễn tương đương trong một mức độ trừu tượng có liên
quan.
Tạo các cách nhìn khác nhau về hệ thống để mà nâng cao khả năng hiểu biết.
Phát triển tài liệu hiện có. Tài liệu nên được tạo ra trong quá trình phát triển hệ
thống và chỉnh sửa chúng mỗi khi hệ thống có thay đổi. Tạo tài liệu cho chương
trình được điều chỉnh mới.
Design recovery:
Đòi việc xác nhận trích rút các trừu tượng mức độ cao hơn, có ý nghĩa mà
không thể trực tiếp lấy được từ việc kiểm tra mã nguồn. Điều này có thể đạt được từ
việc kết hợp mã nguồn, các tài liệu thiết kế tồn tại, kinh nghiệm cá nhân, sự hiểu
biết về vấn đề, lĩnh vực ứng dụng. thiết kế được phục hồi có thể không cần thiết với
bản thiết kế ban đầu có thể sau đó sử dụng cho phát triển hệ thống, hay nói cách
khác là nền tảng cho việc chỉnh sửa hệ thống trong tương lai. Việc thiết kế này có
thể được sử dụng để phát triển tương tự nhưng không đồng nhất các ứng dụng.
VD: Sau khi phục hồi thiết kế ứng dụng kiểm tra phát âm, nó có thể được sử
dụng thiết kế các module kiểm tra phát âm gói xử lý các từ mới.
Specification recovery

36. 33
VD: Khi thay đổi biểu mẫu ta có rất ít hoặc gần như không có thông tin về biểu
mẫu ban đầu.
VD: Chuyển từ lập trình cấu trúc sang lập trình hướng đối tượng
Trong trường hợp này cách tiếp cận thích hợp là lấy các thông tin đặc tả ban
đầu về hệ thống thông qua specification recovery. Điều này liên quan đến việc xác
định, trừu tượng hóa, biểu diễn các mức trừu tượng cao hơn, có ý nghĩa, khó có thể
thu được từ bằng cách kiểm tra thiết kế hoặc mã nguồn của hệ thống phần mềm.
Trong suốt quá trình này việc đặc tả này có thể lấy trực tiếp mã nguồn hoặc từ bản
thiết kế đang tồn tại. Các thông tin lấy được như: tài liệu về thiết kế, hệ thống, kinh
nghiệm trước các vấn đề, các lĩnh vực ứng dụng tạo điều kiện thuận lợi cho quá
trình phục hồi.
Các đặc tả về hệ thống có thể được sử dụng để hỗ trợ bảo trì phần mềm mà
không nhất thiết truy nhập vào mã nguồn
Các đặc tả này hỗ trợ cho hiểu biết về kiến thức để tác động đến việc thay đổi
hệ thống.
Nếu các đặc tả này mà phù hợp có thể sử dụng để phát triển, bảo trì các hệ
thống tương tự.việc sử dụng các đặc tả đôi lúc có lợi hơn là việc sử dụng mã nguồn
tương tự.
3.1.5. Kỹ thuật hỗ trợ
Hiểu biết được rút ra thông qua phương pháp đảo ngược có thể hỗ trợ việc thay
đổi thông qua các kĩ thuật như forward engineering, restructuring, and reengineering
Forward engineering
Đối lập với kĩ thuật reserve engineering, nó ám chỉ cách tiếp cận phát triển
truyền thống thực hiện từ yêu cầu đến thực thi chi tiết thông qua thiết kế hệ thống.
Restructuring
Kĩ thuật này dùng để chuyển đổi từ dạng này sang dạng khác ở mức độ trừu
tượng có liên quan mà bỏ qua bất kì sự thay đổi chức năng trong nó, điều này tạo ra
định dạng mà ta mong muốn
Ngày nay các chương trình ngày càng khó hiểu hơn và phức tạp hơn để có thể
kiểm soát được điều này mã nguồn cần phải cấu trúc lại. Restructuring là 1 loại của

37. 34
bảo trì phòng ngừa làm tăng trạng thái vật lý của hệ thống đích với cấu tạo phù hợp
với tiêu chuẩn
Reengineering
Là quá trình kiểm tra, thay đổi hệ thống đích để thực thi các thay đổi mong
muốn.
Phương pháp này có 2 bước:
 Áp dụng đối với hệ thống đích để hiểu và biểu diễn hệ thống ở
dạng mới
 Kĩ thuật Forward engineering được áp dụng thực thi, tích hợp
bất kì yêu cầu mới nào do đó có thể đưa ra, nâng cấp hệ thống
mới.
3.1.6. Lợi ích
Lợi ích từ mục đích trên được ứng dụng trong bảo trì phần mềm và đảm bảo
chất lượng phần mềm
Kết quả khi ứng dụng kĩ thuật đảo ngược này hữu dụng đối với ứng dụng và tái
sử dụng phần mềm từ những bản thiết kế và mã nguồn đã có trước đó.
Việc sử dụng các công cụ kĩ thuật đảo ngược cung cấp tài liệu cho việc hiểu hệ
thống. Thời gian dành cho hiểu được tổng thể phần mềm là rất lớn, công cụ kĩ thuật
đảo ngược sẽ giới hạn phạn vi và từ đó ta có thể giảm được giá thành cho việc bảo
trì phần mềm.
VD: nghiên cứu phương pháp reengineering trong bảo trì phần mềm chỉ ra rằng
phương pháp này có thể giảm độ phức tạp nhưng lại tăng tính bảo trì.
Kĩ thuật Reverse Engineering mang lại lợi ích cho các hoạt động bảo trì phần
mềm theo các cách sau:

38. 35
Bảng 3.2: Lợi ích của kĩ thuật Reverse Engineering
Chỉnh sửa chính
xác
Dễ dàng phát hiện dễ dàng các thiếu sót
trong các thành phần và các lỗi trong phần
mềm.
Chỉnh sửa cho
phù hợp
Việc sử dụng kĩ thuật trên giảm thời gian
để dành cho tìm hiều về hệ thống, các
thành phần chính trong hệ thống mối quan
hệ giữa chúng, do đó có thể thấy được nơi
các yêu cầu mới được đặt cho thích hợp và
chúng quan hệ với các thành phần đã có
như thế nào.việc đúc rút đặc tả và thông
tin thiết kết có thể được sử dụng trong suốt
quá trình phát triển hệ thống hoặc phát
triển hệ thống cho sản phẩm khác
3.2. Kiểm thử hồi quy
Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi
mã chính. Cụ thể, nó tìm cách phát hiện ra các hồi quy của phần mềm hoặc các lỗi
cũ quay trở lại. Những hồi quy như vậy xảy ra bất cứ khi nào chức năng phần mềm
trước đây đang hoạt động giờ tạm ngưng như đã định. Thông thường, những hồi quy
xảy ra như một hệ quả không lường trước được những thay đổi chương trình, khi
một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó.
Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước
đó và kiểm thử xem lỗi cố định trước đây tại sao lại xuất hiện. Độ sâu của kiểm thử
phụ thuộc vào các nguy cơ và giai đoạn trong quá trình phát hành các tính năng bổ
sung. Chúng có thể được hoàn tất khi thay đổi thêm vào đầu hoặc cuối bản phát
hành, cũng có thể được có mức độ nguy hiểm thấp khi thực hiện kiểm thử tích cực
trên mỗi tính năng.
Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng
A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì
chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C,
trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không
còn làm việc đúng nữa.
Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một
trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua

39. 36
Regression Test là "không được phép" vì có thể dẫn đến tình trạng phát sinh hoặc tái
xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không
có hoặc đã được kiểm tra và sửa chữa rồi.
Cái gì ảnh hưởng đến phạm vi kiểm thử hồi quy?
 Bản chất của thay đổi được thêm vào.
 Mối quan hệ/ảnh hưởng của thay đổi đối với hệ thống/chức năng
của hệ thống.
 Thời gian và nhân lực hiện có.
Làm thế nào để Tester xác định được phạm vi kiểm thử hồi quy?
 Dựa vào kinh nghiệm và hiểu biết về ứng dụng.
 Trao đổi với developer.
 Nơi mà thay đổi được thực hiện: ví dụ, nếu thay đổi ở Home
Page thì cần phải bỏ nhiều công sức để kiểm thử hơn so với
những thay đổi ở các page ít được truy cập.
Tuỳ thuộc vào các yếu tố và thời điểm, team kiểm thử có thể đi theo các hướng
sau:
 Kiểm thử hồi quy đơn vị: nghĩa là chỉ cần Kiểm thử lại với
module/vùng bị thay đổi của ứng dụng.
 Kiểm thử hồi quy 1 phần: nghĩa là chỉ thực hiện kiểm thử lại với
module có thay đổi, cùng với các module khác có tương tác với
nó.
 Kiểm thử hồi quy toàn bộ: nghĩa là thực hiện kiểm thử lại với
toàn bộ ứng dụng, không quan tâm đến module nào bị thay đổi.
Tuỳ vào từng tình huống (thời gian và nguồn lực có sẵn), mức độ nghiêm trọng
của thay đổi (và ảnh hưởng của nó), thông tin mà developer cung cấp sẽ hiệu quả
hơn khi bạn có thể lựa chọn một phạm vi đúng cho việc kiểm thử hồi quy. Phân tích
hồi quy là chìa khoá cho sự thành công. Nó cần xử lý thông minh hơn là chăm chỉ.
Các hiểu nhầm về kiểm thử hồi quy:
 Kiểm thử hồi quy luôn được tự động hoá: Không hoàn toàn,
kiểm thử hồi quy hoàn toàn có thể được làm manual. Nên nhớ
rằng, kiểm thử hồi quy là ứng cử viên để tự động hoá. Việc kiểm
thử lặp đi lặp lại sẽ rất tốn thời gian và thậm chí còn gây nhàm

40. 37
chán. Ngoài ra, những kiểm tra quan trọng cũng có thể bị bỏ
qua. Tự động hoá sẽ là giải pháp đáng tin cậy, nhanh và hiệu
quả hơn.
 Kiểm thử hồi quy không bao giờ kết thúc: Đúng nhưng không
hoàn toàn. Ý của tôi là, kiểm thử hồi quy vét cạn có thể là bất
khả thi. Nhưng kiểm thử hồi quy vét cạn cũng có thể là không
cần thiết.
Giả sử bạn thay đổi một lỗi chỉnh tả trên trang chủ. Đó là một
thay đổi rất nhỏ, và cũng không liên quan đến các phần khác của
ứng dụng. Vì thế, chỉ cần kiểm thử lại 1 cách đơn giản. Không
cần thiết phải thực hiện Kiểm thử hồi quy toàn bộ các tính năng
của trang chủ.
 Nếu bạn không có thời gian thì kiểm thử hồi quy là không cần
thiết: Không đúng. Không kiểm thử đủ sẽ dẫn đến sự thiếu lòng
tin vào sản phẩm. Bạn sẽ không bao giờ biết cái gì có thể xảy ra
với các kịch bản người dùng khác nhau.
 Cần phải chạy từng test case của các phiên bản trước: Một lần
nữa, sử dụng mọi test case không phải là 1 cách đúng. Chiến
lược lựa chọn là chìa khoá. Hãy hiểu thay đổi và lựa chọn những
test case phù hợp.
3.3. 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. Chi phí vè tài
chính luôn là mối quan tâm của chúng ta. Tuy nhiên, co những chi phí ít thấy lại là
mối quan tâm cần được ưu tiên. Một chi phí vô hình của việc bảo trì phần mềm là cơ
hội phát triển bị trì hoãn hay bị mất tài nguyên sẵn có phải chuyển cho các nhiệm vụ
bảo trì. Các chi phí khác bao gồm:
 Sự không thỏa mãn của khách hang khi các yêu cầu sửa chữa
hay thay đổi hợp lí lại không được đề cập đến một cách kịp thời.
 Sự suy giảm chất lượng phần mềm tổng thể do những thay đổi
phát sinh thêm lỗi trong phần mềm sau khi đã 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 việc bảo trì.
Chi phí cuối cùng cho việc bảo trì phần mềm làm giảm hiệu suất bảo trì (được
đo theo số dòng lệnh (LOC) trên người – tháng hay điểm chức năng (FP) trên người
– tháng), điều thường gặp phải khi bắt đầu bảo trì chương trình cũ.

41. 38
Nỗ lực dành cho việc bảo trì có thể bị phân chia vào các hoạt động sản xuất (
như phân tích và đánh giá, sửa đổi thiết kế, mã hóa) và các hoạt động như hiểu mã
chương trình làm gì, thử diễn giải cấu trúc dữ liệu, các đắc trưng giao diện, các biên
hiệu năng. Biểu thức sau đây đưa ra mô hình về nỗ lực bảo trì:
𝑀 = 𝑝 + 𝐾ₑ( 𝑐−𝑑)
p – Nỗ lực hiệu suất
M – Tổng nỗ lực dành cho bảo trì
Kₑ - Hằng số kinh nghiệm
c – Đo độ phức tạp
d – Việc đo mức độ quen thuộc với phần mềm.
Mô hình được mô tả trên cho thấy nỗ lực (và chi phí) có thể tăng lên theo hàm
mũ nếu sử dụng 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) và người hay nhóm người dung cách tiếp cận này còn chưa sẵn có để
thực hiện việc bảo trì.
Lưu ý:
Chi phí cho việc thêm vào một chức năng mới của hệ thống khi sau nó được
triển khai thường lớn hơn chi phí xây dựng các chức năng tương tự khi phần mềm
được phát triển ban đầu bởi vì:
 Các nhân viên bảo trì thường không có kinh nghiệm và không
quen thuộc với miền ứng dụng. Bảo trì là một công việc nhàm
chán đối với các kĩ sư phân mềm. Đây thường được xem là một
công việc đòi hỏi ít kĩ năng hơn phát triển hệ thống nên nó
thường được giao cho các nhân viêc cấp thấp.
 Chương trình được bảo trì đã được phát triển nhiều năm trước
đây nên không có các kĩ thuật nghệ phần mềm hiện đại. Chúng
cần được xây dựng và tối ưu hóa để nâng cao tính hiệu quả.
 Thay đổi chương trình có thể làm phát sinh ra các lỗi mới. Các
lỗi này lại yêu cầu các thay đổi.
 Khi hệ thống thay đổi, cấu trúc của nó có thể bị suy biến. Điều
đó làm cho hệ thống khó hiểu hơn và các thay đổi sẽ khó khăn
hơn khi tính cố kết của hệ thống bị suy giảm.

42. 39
 Mối liên quan giữa chương trình và các tài liệu liên quan giảm
đi. Do đó, các tài liệu này không còn đủ tin cậy để trợ giúp việc
hiểu chương trình.

43. 40
Chương 4: Việc xử lí tài liệu trong bảo trì
phần mềm
4.1. Lời dẫn
Khi các phần mềm thương mại hoặc phần mềm doanh nghiệp điều hành, phần
mềm quản lí tài chính chứng khoán trở nên phát triển cồng kềnh, khó sử dụng thì tài
liệu phần mềm là yếu tố cần thiết để áp dụng việc bảo trì phần mềm một cách hiệu
quả. Chính vì vậy phần quản lí tài liệu cũng là một phần của việc bảo trì phần mềm
Tất cả các dự án phát triển phần mềm lớn, bất kể ứng dụng, tạo ra một số lượng
lớn các tài liệu liên quan. Đối với các hệ thống có kích thước vừa phải, tài liệu có
thể sẽ điền vào một số tủ hồ sơ; đối với các hệ thống lớn, nó có thể lấp đầy một số
phòng. Phần lớn chi phí xử lý phần mềm phát sinh trong quá trình sản xuất tài liệu
này. Hơn nữa, lỗi và thiếu sót của tài liệu có thể dẫn đến lỗi của người dùng cuối và
hậu quả của sự cố hệ thống với chi phí liên quan và sự gián đoạn. Do đó, các nhà
quản lý và các kỹ sư phần mềm nên quan tâm nhiều đến tài liệu và chi phí liên quan
đến sự phát triển của phần mềm.
Các tài liệu liên quan đến một dự án phần mềm và hệ thống đang được phát
triển có một số yêu cầu liên quan:
1. Chúng phải hoạt động như một phương tiện truyền thông giữa
các thành viên của nhóm phát triển.
2. Tài liệu phải là một kho thông tin hệ thống được sử dụng bởi
các kỹ sư bảo trì.
3. Tài liệu nên cung cấp thông tin cho ban quản lý để giúp họ lên
kế hoạch, ngân sách và lên lịch tiến trình phát triển phần mềm.
4. Một số tài liệu nên cho người dùng biết cách sử dụng và quản lý
hệ thống.
Đáp ứng các yêu cầu này yêu cầu các loại tài liệu khác nhau từ các tài liệu làm
việc không chính thức thông qua các hướng dẫn sử dụng sản xuất chuyên nghiệp.
Các kỹ sư phần mềm thường chịu trách nhiệm sản xuất hầu hết các tài liệu này mặc
dù các nhà văn chuyên nghiệp có thể hỗ trợ việc đánh bóng cuối cùng các thông tin
được công bố bên ngoài.

44. 41
4.2. Qui trình sinh tài liệu sản phẩm
Đối với các dự án phần mềm lớn, thường là trường hợp tài liệu bắt đầu được tạo
ra tốt trước khi quá trình phát triển bắt đầu. Một đề xuất để phát triển hệ thống có
thể được sản xuất để đáp ứng yêu cầu về hồ sơ dự thầu của một khách hàng bên
ngoài hoặc để đáp ứng các văn bản chiến lược kinh doanh khác. Đối với một số loại
hệ thống, một tài liệu yêu cầu toàn diện có thể được tạo ra để xác định các tính năng
cần thiết và hành vi mong muốn của hệ thống. Trong quá trình phát triển chính nó,
tất cả các loại tài liệu khác nhau có thể được sản xuất - kế hoạch dự án, thiết kế chi
tiết kỹ thuật, kế hoạch kiểm tra.
Không thể xác định một bộ tài liệu cụ thể được yêu cầu - điều này phụ thuộc
vào hợp đồng với khách hàng đối với hệ thống, loại hệ thống được phát triển và tuổi
thọ dự kiến, văn hoá và quy mô của công ty phát triển hệ thống và sự phát triển Lịch
trình mà nó mong đợi. Tuy nhiên, nói chung chúng ta có thể nói rằng các tài liệu
được sản xuất được chia thành hai lớp:
1. Quy trình tài liệu: Các tài liệu ghi lại quá trình phát triển và bảo
trì. Kế hoạch, tiến độ, tài liệu chất lượng quá trình và tiêu chuẩn
tổ chức và dự án là tài liệu quá trình.
2. Tài liệu sản phẩm: Tài liệu này mô tả sản phẩm đang được phát
triển. Tài liệu hệ thống mô tả sản phẩm từ quan điểm của các kỹ
sư phát triển và duy trì hệ thống; Tài liệu hướng dẫn sử dụng
cung cấp mô tả sản phẩm hướng tới người dùng hệ thống.
Hồ sơ quy trình được sản xuất để phát triển hệ thống có thể được quản lý. Tài
liệu sản phẩm được sử dụng sau khi hệ thống hoạt động nhưng cũng rất cần thiết
cho việc quản lý việc phát triển hệ thống. Việc tạo ra một tài liệu, chẳng hạn như
một đặc tả hệ thống, có thể là một cột mốc quan trọng trong quá trình phát triển
phần mềm.
4.3. Tài liệu qui trình
Quản lý hiệu quả yêu cầu quá trình được quản lý để được nhìn thấy được. Bởi
vì phần mềm là vô hình và quá trình phần mềm có liên quan đến các nhiệm vụ nhận
thức tương tự rõ ràng hơn là các nhiệm vụ thể chất rõ ràng khác nhau, cách duy nhất
để đạt được mục tiêu này là thông qua việc sử dụng tài liệu hướng dẫn.
Tài liệu quy trình rơi vào một số loại:

45. 42
1. Kế hoạch, ước tính và lịch trình: Đây là các tài liệu do các nhà
quản lý sản xuất được sử dụng để dự đoán và kiểm soát quy
trình phần mềm.
2. Báo cáo: Đây là những tài liệu báo cáo về các nguồn lực đã
được sử dụng trong quá trình phát triển như thế nào.
3. Tiêu chuẩn: Đây là những tài liệu nêu ra quá trình thực hiện.
Các tiêu chuẩn này có thể được phát triển từ các tiêu chuẩn tổ
chức, quốc gia hoặc quốc tế
4. Các giấy tờ làm việc: Đây thường là các tài liệu truyền thông kỹ
thuật chính trong một dự án. Họ ghi lại các ý tưởng và suy nghĩ
của các kỹ sư làm việc trong dự án, là các phiên bản tạm thời
của tài liệu sản phẩm, mô tả các chiến lược thực hiện và đưa ra
các vấn đề đã được xác định. Họ thường, ngầm, ghi lại lý do cho
các quyết định thiết kế.
5. Bản ghi nhớ và thư điện tử: Đây là những bản ghi chi tiết về
giao tiếp hàng ngày giữa các nhà quản lý và các kỹ sư phát triển.
Các đặc tính chính của tài liệu quá trình là hầu hết nó trở nên lỗi thời. Kế hoạch có thể
được lập trên cơ sở hàng tuần, hàng tuần hoặc hàng tháng. Tiến bộ thường được báo
cáo hàng tuần. Bản ghi nhớ ghi lại suy nghĩ, ý tưởng và ý định thay đổi.
4.4. Tài liệu sản phẩm
Tài liệu sản phẩm liên quan đến mô tả sản phẩm phần mềm được phân phối.
Không giống như hầu hết các tài liệu quá trình, nó có một cuộc sống tương đối dài.
Nó phải tiến triển theo bước với sản phẩm mà nó mô tả. Tài liệu sản phẩm bao gồm
tài liệu hướng dẫn cho người dùng cách sử dụng sản phẩm phần mềm và tài liệu hệ
thống chủ yếu dành cho các kỹ sư bảo trì.
4.4.1. Tài liệu người dùng
Người dùng của một hệ thống không giống nhau. Nhà sản xuất tài liệu phải cấu
trúc nó để phục vụ cho các nhiệm vụ khác nhau của người sử dụng và mức độ khác
nhau của chuyên môn và kinh nghiệm. Điều đặc biệt quan trọng là phải phân biệt
giữa người dùng cuối và người quản trị hệ thống:
1. Người dùng cuối sử dụng phần mềm để hỗ trợ một số công việc
như là quản lí vé máy bay, quản lý chính sách bảo hiểm, viết
sách ... Họ muốn biết phần mềm có thể giúp họ như thế nào. Họ
không quan tâm đến chi tiết về máy tính hoặc quản trị.

46. 43
2. Quản trị viên hệ thống chịu trách nhiệm quản lý phần mềm được
sử dụng bởi người dùng cuối. Điều này có thể liên quan đến
hoạt động như một nhà điều hành nếu hệ thống là một hệ thống
máy tính lớn, vì người quản lý mạng là hệ thống bao gồm một
mạng lưới các máy trạm làm việc hoặc là một chuyên gia kỹ
thuật, người sửa các vấn đề phần mềm của người dùng cuối và
người giữ liên lạc giữa người dùng và nhà cung cấp phần mềm.
Để phục vụ cho các đối tượng và mức độ chuyên môn khác nhau của người
dùng, có ít nhất 5 tài liệu (hoặc có thể là các chương trong một tài liệu) nên được
cung cấp cùng với hệ thống phần mềm.
Hình 4.1: Năm loại tài liệu phục vụ đối tượng khác nhau
Mô tả chức năng của hệ thống vạch ra yêu cầu hệ thống và mô tả ngắn gọn các
dịch vụ được cung cấp. Tài liệu này nên cung cấp tổng quan về hệ thống. Người
dùng có thể đọc tài liệu này với một hướng dẫn giới thiệu và quyết định xem hệ
thống có phải là những gì họ cần hay không.
Tài liệu cài đặt hệ thống dành cho quản trị viên hệ thống. Nó sẽ cung cấp chi
tiết về cách cài đặt hệ thống trong một môi trường cụ thể. Nó phải chứa một mô tả
của các tập tin tạo nên hệ thống và yêu cầu cấu hình phần cứng tối thiểu. Các tập tin
cố định phải được thiết lập, cách khởi động hệ thống và các tệp phụ thuộc cấu hình
phải được thay đổi để điều chỉnh hệ thống cho một hệ thống máy chủ cụ thể cũng
cần được mô tả. Việc sử dụng trình cài đặt tự động cho phần mềm máy tính có nghĩa
là một số nhà cung cấp coi tài liệu này là không cần thiết. Trên thực tế, vẫn cần phải
giúp các nhà quản lý hệ thống khám phá và khắc phục sự cố khi cài đặt.

47. 44
Cẩm nang giới thiệu nên trình bày một cách giới thiệu không chính thức về hệ
thống, mô tả cách sử dụng 'bình thường'. Nó nên mô tả làm thế nào để bắt đầu và
làm thế nào người dùng cuối có thể sử dụng các cơ sở hệ thống thông thường. Nó
nên được minh hoạ tự do với các ví dụ. Tất nhiên người mới bắt đầu, bất kể nền
tảng và kinh nghiệm của họ, sẽ mắc phải sai lầm. Dễ dàng phát hiện ra thông tin về
cách khôi phục lại từ những sai lầm này và khởi động lại công việc hữu ích nên là
một phần không thể tách rời của tài liệu này.
Hướng dẫn tham khảo hệ thống nên mô tả các cơ sở của hệ thống và cách sử
dụng chúng, cung cấp một danh sách đầy đủ các thông báo lỗi và nên mô tả cách
phục hồi từ các lỗi đã phát hiện. Nó phải được hoàn thành. Các kỹ thuật mô tả chính
thức có thể được sử dụng. Phong cách của tài liệu tham khảo không nên là không
cần thiết khi nói dối và thô tục, nhưng sự hoàn chỉnh quan trọng hơn khả năng đọc.
Cần cung cấp một hướng dẫn chung cho quản trị viên hệ thống đối với một số
loại hệ thống như hệ thống lệnh và kiểm soát. Điều này nên mô tả các thông báo
được tạo ra khi hệ thống tương tác với các hệ thống khác và làm thế nào để phản
ứng với những thông điệp này. Nếu phần cứng hệ thống có liên quan, nó cũng có thể
giải thích nhiệm vụ của người vận hành trong việc duy trì phần cứng đó. Ví dụ, nó
có thể mô tả làm thế nào để xóa lỗi trong hệ thống điều khiển, làm thế nào để kết nối
thiết bị ngoại vi mới.
Cũng như hướng dẫn sử dụng, các tài liệu dễ sử dụng khác có thể được cung
cấp. Một thẻ tham khảo nhanh chóng liệt kê các cơ sở hệ thống có sẵn và cách sử
dụng chúng đặc biệt thuận lợi cho người dùng hệ thống có kinh nghiệm. Hệ thống
trợ giúp trực tuyến, có chứa thông tin ngắn gọn về hệ thống, có thể tiết kiệm thời
gian dành cho người sử dụng để tham khảo hướng dẫn sử dụng mặc dù không nên
xem như một sự thay thế cho các tài liệu toàn diện hơn.
4.4.2. Tài liệu hệ thống
Tài liệu hệ thống bao gồm tất cả các tài liệu mô tả hệ thống chính nó từ yêu cầu
đặc điểm kỹ thuật đến kế hoạch kiểm tra cuối cùng.
Các tài liệu mô tả thiết kế, thực hiện và thử nghiệm một hệ thống là cần thiết
nếu chương trình phải được hiểu và duy trì. Giống như tài liệu hướng dẫn người sử
dụng, điều quan trọng là tài liệu hệ thống được cấu trúc, với các bài tổng quan dẫn
người đọc vào các mô tả chính thức và chi tiết hơn về từng khía cạnh của hệ thống.
Đối với các hệ thống lớn được phát triển theo đặc tả của khách hàng, tài liệu hệ
thống cần bao gồm:
1. Văn bản yêu cầu và lý do hợp nhất.

48. 45
2. Một tài liệu mô tả kiến trúc hệ thống.
3. Đối với mỗi chương trình trong hệ thống, mô tả về kiến trúc của
chương trình đó.
4. Đối với mỗi thành phần trong hệ thống, mô tả về chức năng và
giao diện của nó.
5. Danh sách mã nguồn của chương trình. Những nhận xét này cần
được bình luận ở đâu các nhận xét nên giải thích các phần phức
tạp của mã và cung cấp một lý do cho phương pháp mã hóa
được sử dụng. Nếu sử dụng các tên có ý nghĩa và một phong
cách lập trình tốt có cấu trúc được sử dụng, hầu hết mã sẽ tự ghi
lại mà không cần thêm ý kiến. Thông tin này hiện nay được duy
trì bằng điện tử chứ không phải trên giấy với các thông tin được
chọn in theo nhu cầu của độc giả.
6. Các tài liệu xác nhận mô tả cách thức mỗi chương trình được
xác nhận và cách thông tin xác nhận liên quan đến các yêu cầu.
7. Hướng dẫn duy trì hệ thống mô tả những vấn đề đã biết của hệ
thống, mô tả phần nào của hệ thống là phụ thuộc phần cứng và
phần mềm và mô tả cách thức sự phát triển của hệ thống đã
được tính đến trong thiết kế của nó.
Một vấn đề bảo trì hệ thống chung là đảm bảo rằng tất cả các đại diện được giữ
trong bước khi hệ thống được thay đổi. Để giúp đỡ việc này, các mối quan hệ và sự
phụ thuộc giữa các tài liệu và các phần của tài liệu phải được ghi lại trong một hệ
thống quản lý tài liệu như đã thảo luận trong phần cuối của bài báo này.
Đối với các hệ thống và hệ thống nhỏ hơn được phát triển như các sản phẩm
phần mềm, tài liệu hệ thống thường ít toàn diện hơn. Điều này không nhất thiết là
một điều tốt nhưng áp lực về thời gian cho các nhà phát triển có nghĩa là các tài liệu
chỉ đơn giản là không bao giờ được viết hoặc, nếu được viết, không được cập nhật.
Những áp lực này đôi khi không thể tránh khỏi, nhưng theo quan điểm của tôi, ít
nhất bạn cũng nên cố gắng duy trì một đặc tả của hệ thống, một tài liệu thiết kế kiến
trúc và mã nguồn của chương trình.
Thật không may, bảo trì tài liệu thường bị bỏ quên. Tài liệu có thể trở nên
không phù hợp với phần mềm có liên quan của nó, gây ra sự cố cho cả người dùng
và người bảo trì hệ thống. Xu hướng tự nhiên là để đáp ứng một thời hạn bằng cách
sửa đổi mã với ý định sửa đổi các tài liệu khác sau đó.

49. 46
Tổng kết
Qua bài tìm hiểu về vấn đề bảo trì phần mềm, chúng ta đã đi một cách tổng quát
và ngắn gọn về các vấn đề trong bảo trì phần mềm như là phân loại bảo trì, các
phương pháp cải tiến việc bảo trì. Sau đó chúng ta đi sâu vào qui trình bảo trì và các
mô hình bảo trì được áp dụng thực tế. Qui trình bảo trì theo chuẩn IEEE / IEA 219
và các mô hình bảo trì phần mềm phổ biến như Quick-fix, Boehm, Osborne, Taute.
Sang chương số ba về các vấn đề trong bảo trì phần mềm, chúng ta tìm hiểu sơ lược
tổng quát về các vấn đề phổ biến trong bảo trì như là kĩ nghệ ngược, kiểm thử hồi
quy, chi phí bảo trì. Ở chương cuối cùng, vấn đề xử lí tài liệu trong phần mềm được
nhắc tới, qua đó giúp người đọc thấy được tầm quan trọng của việc xử lí tài liệu
phần mềm để ứng dụng cho vấn đề bảo trì phần mềm sau này.

50. 47
Tài liệu tham khảo
[1]. SOFTWARE EVOLUTION AND MAINTENANCE (2015) A
Practitioner’s Approach by PRIYADARSHI TRIPATHY
KSHIRASAGAR NAIK by John Wiley
[2]. Giáo trình Nhập môn Công nghệ Phần mềm NXB Giáo dục Việt Nam
2011, tác giả: Thạc Bình Cường
[3]. Software Maintenance: Concepts and Practice (2003) by Penny Grubb,
Armstrong A. Takang
[4]. http://swebokwiki.org/Chapter_5:_Software_Maintenance#Evolution_of_
Software
[5]. http://www.worldscientific.com/worldscibooks/10.1142/5318
[6]. https://ifs.host.cs.st-
andrews.ac.uk/Books/SE9/Web/ExtraChaps/Documentation.pdf