Công nghệ phần mềm quy trình bảo trì phần mềm

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (477.34 KB, 30 trang )

TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
HỌC VIỆN KỸ THUẬT MẬT MÃ
BÀI TẬP MÔN CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI 12: TÌM HIỂU VỀ BẢO TRÌ PHẦN
MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Giảng viên: Nguyễn Văn Thắng
Sinh viên thực hiện: PhaLiNha
Nguyễn Công Đức
Nguyễn Tuấn Anh
Nguyễn Thị Hồng Ngoan
Nguyễn Thu Thùy
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
MỤC LỤC
Danh mục hình vẽ
Hình 1: Chu kỳ sống của phần mềm
Hình 2: Phân loại bảo trì
Hình 3: Quick-fix
Hình 4: Iterative Enhancement model
Hình 5: Full-reuse
Hình 6: Chi phí phát triển phần mềm
Hình 7: Mô hình bảo trì phần mềm
Hình 8: Các hoạt động trong quy trình bảo trì phần mềm
Hình 9: ISO/IEC 14764
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 2
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
I. BẢO TRÌ PHẦN MỀM
1. Tổng quan
1.1 Khái niệm
Phần mềm là tập các câu lệnh hoặc chỉ thị được viết bằng một hoặc nhiều ngôn
ngữ lập trình theo một trật tự nhất định. Dữ liệu hay các tài liệu liên quan được xây
dựng nhằm thực hiện một số nhiệm vụ hay chức năng. Để có thể xây dựng nên một

phần mềm hoàn thiện phục vụ yêu cầu của người dùng cần trải qua một quy trình
phát triển phần mềm gồm nhiều giai đoạn khác nhau. Quy trình phát triển phần mềm
là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng
trong việc phát triển để sản xuất ra một sản phẩm phần mềm. Để có một quy chuẩn
cho quy trình phát triển phần mềm, tổ chức ISO/IEC đã đưa ra chuẩn ISO/IEC
12207. Mục đích là trở thành một tiêu chuẩn định nghĩa tất cả các công việc cần
thực hiện để xây dựng và bảo trì sản phẩm phần mềm. Theo chuẩn này, có 4 thao tác
cơ bản là nền tảng cho quy trình phát triển phần mềm.
• Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện hoạt động của
nó phải được định nghĩa.
• Sự phát triển của phần mềm: Để phần mềm đạt được đặc tả thì cần có quy
trình này.
• Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó
làm những gì mà khách hàng muốn.
• Sự tiến hóa của phần mềm: Phần mềm phải được tiến hóa để thỏa mãn sự
thay đổi các yêu cầu của khách hàng.
Một quy trình phát triển phần mềm (chu kỳ sống của phần mềm) gồm các giai
đoạn cơ bản sau:
• Requirements (phân tích yêu cầu): Thu thập yêu cầu của khách hàng về phần
mềm, phân tích và đặc tả chi tiết về những yêu cầu đó.
• Design (thiết kế): chuyển tài liệu đặc tả yêu cầu ở bước trên thành tài liệu mô
tả thiết kế.
• Coding (lập trình): thực hiện mã hóa tài liệu thiết kế thành mã chương trình.
• Testing (kiểm thử): chạy thử chương trình, phát hiện lỗi hay khả chuyển phần
mềm để phù hợp với các phần mềm khác.
• Deployment (triển khai): thực hiện cài đặt chương trình, thay đổi yêu cầu của
khách hàng, nâng cấp chương trình.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 3
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Hình 1: Chu kỳ sống của phần mềm

Theo quy trình trên thì việc thực hiện bảo trì phần mềm sẽ được thực hiện ở giai
đoạn triển khai phần mềm và là phần cuối cùng trong một chu kỳ sống của phần
mềm. Bảo trì phần mềm (software maintenance) bao gồm điều chỉnh các lỗi mà
chưa được phát hiện trong các giai đoạn trước của chu kỳ sống của một phần mềm,
nâng cấp tính năng sử dụng và an toàn vận hành của phần mềm. Việc bảo trì phần
mềm có thể chiếm đến 65%-75% công sức trong chu kỳ sống của một phần mềm.
Nhiệm vụ của giai đoạn bảo trì phần mềm nhằm giữ cho phần mềm được cập nhật
khi môi trường vận hành thay đổi và yêu cầu của khách hàng thay đổi. Theo chuẩn
IEEE(1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần mềm
sau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềm
hoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trường
đã bị thay đổi.
1.2 Khó khăn
Việc bảo trì phần mềm sẽ chịu ảnh hưởng trực tiếp từ nhiều yếu tố như: kích
thước của hệ thống, tuổi của hệ thống, đầu ra và cấu trúc của dữ liệu, ngôn ngữ lập
trình, hay độ dài của mã nguồn. Hệ thống phần mềm và thông tin đi kèm luôn có
biến động lớn theo thời gian, gây khó khăn trong việc đọc hiểu và bảo trì, do không
có sự kết nối chặt chẽ giữa các thành phần phần mềm và trung tâm dữ liệu của hệ
thống. Chìa khóa của việc bảo trì một hệ thống phức tạp là phải hiểu chúng, phải
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 4
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
hiểu sâu về các thành phần chức năng, phi chức năng, và các tương tác giữa chúng.
Đặc biệt, khó khăn nhất nằm trong phần mã nguồn, nhiều nghiên cứu đã chỉ ra rằng
chi phí dành cho việc đọc hiểu mã nguồn chiếm một phần rất lớn trong toàn bộ chi
phí bảo trì phần mềm. Theo quy mô của hệ thống, lượng mã nguồn và các mối quan
hệ giữa các thành phần mã nguồn cũng ngày một tăng nhanh, cả về số lượng và độ
phức tạp, gây ra rất nhiều khó khăn cho người bảo trì trong việc đọc hiểu và xác
định đoạn mã cần được tập trung bảo trì.
Các liên kết truy vết giúp cho các kĩ sư phần mềm hiểu được mối quan hệ và sự
phụ thuộc giữa các thành phần phần mềm từ đó giúp đỡ cho quá trình đọc hiểu mã

nguồn. Tuy nhiên, ngay trong các tổ chức và dự án với quy trình phát triển phần
mềm thuần thục, các thành phần phần mềm được tạo ra trong các bước của quy trình
này cuối cùng cũng bị mất liên kết với các thành phần khác. Các nhân tố chủ yếu
dẫn đến việc mất liên kết giữa các thành phần phần mềm bao gồm:
• Các thành phần phần mềm khác nhau được viết bằng các ngôn ngữ khác
nhau (ngôn ngữ tự nhiên và ngôn ngữ lập trình).
• Các thành phần phần mềm mô tả hệ thống phần mềm ở các cấp độ trừu tượng
khác nhau (cấp độ thiết kế và cài đặt).
• Các quy trình làm thay đổi một thành phần giả tưởng(artifact) không dẫn đến
các sửa đổi liên kết đang tồn tại giữa nó với các thành phần giả
tưởng(artifact) khác (Ví dụ: khi sửa mã thì không có đưa ra cảnh báo cho
việc sửa tài liệu sử dụng của mã đó)
• Thiếu các công cụ hỗ trợ việc tạo và duy trì các liên kết truy vết này.
Các nghiên cứu tạo liên kết truy vết giữa mã nguồn và tài liệu cho đến nay chủ
yếu tập chung vào việc kết nối tài liệu và mã nguồn dựa trên những liên kết một-
một. Hạn chế lớn nhất của phương pháp này là đã bỏ qua các thông tin ngữ nghĩa,
có cấu trúc có thể tìm thấy trong các tài liệu và mã nguồn, dẫn đến sự thiếu chính
xác và khả năng ứng dụng trong thực tế không được cao.
Một thách thức khác đó là việc xác định các nguy cơ bảo mật. Đối với các ứng
dụng được đặt vào các môi trường thay đổi sẽ có độ rủi ro bảo mật cao, việc xác
định những lỗ hổng bảo mật này trong các hệ thống phần mềm tồn tại trở thành một
trong những công việc quan trọng trong giai đoạn bảo trì phần mềm. Trong khi mã
nguồn ngày càng tăng nhanh thì vấn đề này lại càng trở lên ngày càng khó khăn bởi
để phát hiện được các nguy cơ bảo mật thì người bảo trì phải thực sự hiểu được hệ
thống của mình.
Một thách thức khác gặp phải trong quá trình bảo trì hệ thống là một kỹ sư phần
mềm,theo thời gian cũng không còn nắm rõ được các thông tin về kiến trúc, về mã
nguồn, hay rộng hơn là các giả tưởng(artifact) do chính họ tạo ra nữa. Khó khăn
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 5
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM

thậm chí còn tăng nên gấp bội nếu kỹ sư bảo trì không trực tiếp tham gia trong quá
trình phát triển phần mềm. Tương tự như vậy, nếu không được hỗ trợ, người kỹ sư
sẽ gặp khó khăn không nhỏ khi muốn tái sử dụng các artifact của chính mình, chưa
nói đến tái sử dụng artifact sẵn có của người khác.
Việc tìm kiếm, phân tích và tìm hiểu mã nguồn đóng vai trò rất quan trọng. Tuy
nhiên, ngay trong những IDE (Integrated Development Environment-môi trường
phát triển tích hợp) phát triển phần mềm mạnh nhất như Eclipse, việc hỗ trợ tìm
kiếm cũng không mạnh mẽ khi chỉ đơn thuần tìm kiếm văn bản riêng lẻ, thông
thường theo tên các method, class, …mà không hỗ trợ tìm kiếm kết hợp giữa các
thành phần này. Người lập trình rất hay gặp phải những tình huống tìm kiếm như:
tìm kiếm các phương thức nhận một kiểu nào đó làm đối số đầu vào hay tìm kiếm
các phương thức trả về một kiểu dữ liệu nào đó. Hiện nay chưa có một IDE nào thỏa
mãn các yêu cầu tìm kiếm này đơn giản là bởi vì chúng không khai thác tính ngữ
nghĩa giữa các thành phần của mã nguồn để thực hiện tìm kiếm. Ngoài ra việc bảo
trì phần mềm sẽ gặp không ít khó khăn khi môi trường vận hành không phù hợp, có
sự tích hợp chồng chéo, không tương thích của các phần mềm. Thiếu kinh nghiệm
kiểm chuẩn, xác định phương pháp, chiến lược cho bảo trì. Yêu cầu của khách hàng
quá nhiều và luôn thay đổi.
Để khắc phục những khó khăn trên, tăng hiệu quả cho quá trình bảo trì phần
mềm chúng ta nên sử dụng một số biện pháp sau:
• Lưu lại đầy đủ, chính xác thông tin về phần mềm.
• Chuẩn hóa các thao tác kiểm chuẩn, bảo trì.
• Sử dụng các công cụ hỗ trợ phát triển và bảo trì phần mềm.
• Lựa chọn môi trường vận hành thích hợp với từng phần mềm.
2. Phân loại
Theo chuẩn IEEE thì bảo trì phần mềm được phân thành 4 loại:
• Bảo trì tu sửa (Corrective Maintenance)
• Bảo trì thích nghi (Adaptive Maintenance)
• Bảo trì cải tiến (Perfective Maintenance)
• Bảo trì phòng ngừa (Preventive Maintenance)

NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 6
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Hình 2: Phân loại bảo trì
2.1 Bảo trì tu sửa
Bảo trì tu sửa (Corrective Maintenance) là bảo trì được thực hiện nhằm sửa các
lỗi hay khuyết điểm phát sinh được tìm thấy. Lỗi hay khuyết điểm thường phát sinh
do:
• Lỗi thiết kế: xuất hiện khi những sự thay đổi, cập nhật làm cho phần mềm
hoạt động không còn chính xác, đầy đủ, thậm chí là truyền đạt sai hay những
yêu cầu thay đổi bị hiểu sai.
• Lỗi logic: xuất hiện do việc thực hiện giai đoạn kiểm tra, đưa ra kết luận sai,
thực hiện không đúng theo thiết kế chi tiết kỹ thuật hoặc dữ liệu không được
kiểm tra đầy đủ.
• Lỗi coding: do người lập trình thực hiện không đúng các quy tắc chi tiết thiết
kế hoặc không tuân thủ theo các quy tắc logic mã nguồn.
• Ngoài ra còn xuất hiện do việc xử lý dữ liệu hay vận hành hệ thống gặp lỗi.
Bảo trì tu sửa thường sử dụng kỹ thuật dịch ngược (Reverse Enginnering) dò
theo thiết kế để tìm lỗi.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 7
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
2.2 Bảo trì thích nghi
Bảo trì thích nghi (Adaptive Maintenance) là bảo trì được thực hiện nhằm chỉnh
sửa phần mềm, làm cho phần mềm hoạt động được bình thường khi có sự thay đổi
của môi trường. Môi trường ở đây được hiểu là tất cả các ảnh hưởng, hành động bên
ngoài tác động làm cho phần mềm không còn hoạt động chính xác nữa. Đó có thể là
sự thay đổi về chính sách kinh doanh, quy tắc hoạt động của công ty, mô hình làm
việc hay sự thay đổi của các thiết bị phần cứng, hệ điều hành, hoặc các thiết bị đi
kèm…
2.3 Bảo trì cải tiến
Khi phần mềm được hoàn thiện và đưa vào sử dụng thành công, người dùng sẽ

càng quan tâm đến nó. Việc này sẽ dẫn đến việc người dùng muốn thử các chức
năng vượt ra ngoài phạm vi của phần mềm, do đó sẽ dẫn tới việc người dùng sẽ đặt
ra các yêu cầu mới. Việc bảo trì cải tiến (Perfective Maintenance) là bảo trì được
thực hiện nhằm thay đổi phần mềm theo những yêu cầu ngày càng hoàn thiện hơn,
đầy đủ hơn, hợp lý hơn. Đây là hình thái bảo trì phổ biến nhất trong thực tế. Việc
tiến hành bảo trì được đặt ra khi khách hàng muốn nâng cao hiệu suất, cải tiến
phương thức truy nhập, mở rộng thêm chức năng cho hệ thống, cải tiến quản lý làm
cải tiến tư liệu vận hành và trình tự công việc, hay có thể do thay đổi người dùng
dẫn đến thay đổi các thao tác thực hiện.
2.4 Bảo trì phòng ngừa
Bảo trì phòng ngừa (Preventive Maintenance) sẽ quan tâm tới các hoạt động
nhằm tăng cường khả năng có thể bảo trì của hệ thống, như cập nhật dữ liệu, ghi
chú, cải thiện cấu trúc của hệ thống. Việc bảo trì này là sự tu sửa phần mềm có tính
đến tương lai của phần mềm đó sẽ được mở rộng hay thay đổi như thế nào nhằm
giảm bớt độ phức tạp của hệ thống và làm cho các lần bảo trì sau trở dễ dàng hơn.
3. Ý nghĩa
Bảo trì là giai đoạn cuối cùng trong một chu kỳ sống của phần mềm, nhằm nâng
cấp tính năng của phần mềm và làm cho phần mềm hoạt động ổn định, hiệu quả
hơn. Bảo trì phần mềm để chắc chắn rằng phần mềm tạo ra thỏa mãn được đầy đủ,
chính xác các yêu cầu của khách hàng. Bảo trì cần phải thực hiện để:
• Chỉnh sửa các lỗi
• Nâng cao thiết kế
• Có thể cài đặt nâng cao
• Giao tiếp được với các hệ thống khác
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 8
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
• Thích ứng được chương trình với các phần cứng, phần mềm, các phương tiện
truyền thống khác.
• Giúp hệ thống dễ sử dụng lại trong các lần tiếp theo.
Bảo trì sẽ được thực hiện theo định kỳ, thực hiện khi có sự cố xảy ra hay khi yêu

cầu của khách hàng thay đổi. Với một hệ thống mạng Server việc bảo trì là rất quan
trọng, cần phải được thực hiện theo định kỳ để đảm bảo hệ thống hoạt động được
liên tục, ổn định. Bởi một hệ thống Server thì yêu cầu hoạt động liên tục là thực sự
quan trọng, để đáp ứng được các yêu cầu của các client.Với hệ thống mạng nội bộ
(ví dụ như trong một phòng ban của công ty) thì việc bảo trì có thể chỉ cần khi phần
mềm đó gặp sự cố. Bởi mức độ yêu cầu phần mềm cần hoạt động liên tục không
cao, tầm ảnh hưởng của bảo trì là không lớn. Trong hệ thống ngân hàng (ghi chi phí,
thanh toán tiền) thì việc bảo trì cũng cần được thực hiện định kỳ, bởi yêu cầu về
chức năng của phần mềm trong lĩnh vực này rất cao, luôn đòi hỏi không được xảy ra
sai sót. Việc bảo trì cần đảm bảo cho hệ thống được vận hành ổn định, chính xác.
Trong một hệ thống mạng nhiều ứng dụng như các phần mềm trên mobile thì yêu
cầu của bảo trì là thường xuyên, nhưng không cao. Bởi trong những hệ thống này thì
môi trường hoạt động luôn thay đổi, yêu cầu của khách hàng cũng thay đổi theo sự
phát triển của khoa học công nghệ. Việc bảo trì trong hệ thống này chủ yếu do sự
phát triển và yêu cầu ngày một cao của khách hàng.
4. Mô hình bảo trì phần mềm
4.1. Mô hình Quick-Fix
Hình 3: Quick-fix
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 9
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Mô hình Quick-fix đại diện cho một sự trừu tượng của cách tiếp cận điển hình để
bảo trì phần mềm. Trong mô hình Quick-fix, bạn sẽ sử dụng những thứ hệ thống
hiện có, thường chỉ là mã nguồn và thực hiện những thay đổi cần thiết đến mã
nguồn và các tài liệu kèm theo, sau đó biên dịch lại các hệ thống như là một phiên
bản mới. Điều này có thể đơn giản như một sự thay đổi một số thành phần bên trong
như sửa một lỗi liên quan đến một thành phần hoặc sự thay đổi cấu trúc hoặc thậm
chí một số chức năng cao hơn. Hình 3 cho thấy sự thay đổi của mã nguồn của hệ
thống cũ sang mã nguồn của phiên bản mới. Nó được giả định rằng – không phải lúc
nào cũng đúng – tài liệu kèm theo hướng dẫn cũng được cập nhật. Bạn có thể hiểu
mô hình này theo hướng tái sử dụng, vì việc tạo ra một hệ thống mới bằng cách tái

sử dụng hệ thống cũ hay chỉ đơn giản là sửa đổi hệ thống cũ.
Ưu điểm:
• Nhanh.
• Có thể hữu ích cho dự án nhỏ
Nhược điểm:
• Nhỏ hay không có tài liệu. Vai trò của tài liệu bị giảm sút.
• Do can thiệp trực tiếp vào code của chương trình nguồn nên quá trình bảo trì
có thể sẽ phá vỡ thiết kế ban đầu của phần mềm.
4.2. Mô hình Iterative Enhancement
Hình 4: Iterative Enhancement model
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 10
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Dựa trên nhận định rằng một hệ thống khi xây dựng rất khó có thể đã đáp ứng
được hết yêu cầu của người sử dụng, phương pháp interative- enhance tiến
hành xây dựng hệ thống hoàn chỉnh dựa trên cơ sở phân tích bước đầu về yêu
cầu của hệ thống, tiến hành phân tích sâu hơn yêu cầu đặt ra đối với phần mềm
dựa trên phản hồi của người sử dụng để xây dựng hệ thống mới.
Ưu điểm:
• Tương đối đơn giản
• So với quick-fix là các tài liệu của hệ thống được cập nhật thường xuyên với
mọi sự thay đổi của hệ thống.
Nhược điểm:
• Những quyết định, yêu cầu không rõ ràng.
4.3. Mô hình Full-reuse
Hình 5: Full-reuse
Mục đích của tái sử dụng lại là nhằm tăng năng suất, chất lượng và tạo điều kiện
thuận lợi cho việc chuyển đổi mã, giảm bớt thời gian chi phí để bảo trì. Có thể hiểu
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 11
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
định nghĩa của việc tái sử dụng phần mềm như sau: đó là việc sử dụng lại các kinh

nghiệm đã có từ chính hệ thống đó hay các hệ thống tương tự nhằm giảm bớt nỗ lực
để phát triển hay bảo trì hệ thống.
Ứng dụng tư tưởng tái sử dụng, phương pháp full-reuse xây dựng hệ thống mới
trên cơ sở tái sử dụng những yếu tố phù hợp trong từng giai đoạn khi xây dựng hệ
thống cũ. Do đó, phương pháp này thích hợp cho việc xây dựng những hệ thống có
vòng đời ngắn. Tăng khả năng tái sử dụng của các thành phần hệ thống. Đặc biệt,
khi kết hợp full-reuse và interative enhancement có thể tăng đáng kể hiệu quả kinh
tế của quá trình bảo trì phần mềm.
Ưu điểm:
• Có thể dùng các thành phần từ các dự án khác.
• Mã nguồn được chia thành các modun nhỏ.
Nhược điểm:
• Chi phí trong thiết kế để tái sử dụng cao.
5. Công việc bảo trì phần mềm
5.1 Khả năng bảo trì
Khả năng bảo trì của phần mềm có thể coi như các khả năng hiểu, hiệu chỉnh
hoặc có thể thêm vào khả năng phát triển phần mềm. Khả năng bảo trì là chìa khóa
để dẫn đến các phương pháp thiết kế xây dựng phần mềm.
5.1.1 Yếu tố kiểm soát
Khả năng bảo trì gồm nhiều yếu tố như: sự thiếu cẩn trọng trong việc thiết kế,
viết chương trình nguồn, kiểm tra, cấu hình yếu kém có ảnh hưởng tiêu cực đến việc
bảo trì. Thêm vào đó các yếu tố khác liên quan đến phương pháp phát triến phần
mềm như:
• Chất lượng hiệu quả của đội ngũ phần mềm
• Cấu trúc của hệ thống dễ hiểu
• Dễ dàng kiểm soát hệ thống
• Dùng các ngôn ngữ lập trình chuẩn
• Dùng các hệ điều hành chuẩn
• Dùng các cấu trúc chuẩn tài liệu
• Dùng được các tài liệu kiểm tra

• Phương tiện gỡ rối đi kèm
• Dùng được các máy tính tốt để thực hiện việc bảo trì
Các yếu tố ở trên đã phản ánh những đặc điểm về phần cứng cũng như chương
trình nguồn được dùng trong việc phát triển phần mềm và còn chỉ ra được sự cần
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 12
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
thiết để có được chương trình nguồn chuẩn. Nếu coi phần mềm như một hệ thống
các thành phần sẽ phải chịu những thay đổi không thể tránh được thì cơ hội tạo ra
những phần mềm có khả năng bảo trì sẽ thực sự tăng lên.
5.1.2 Đánh giá định lượng
Khả năng bảo trì cũng như chất lượng hay độ tin cậy là hết sức khó xác định.
Tuy nhiên chúng ta có thể đánh giá khả năng bảo trì gián tiếp bằng việc xem xét các
thuộc tính của các công việc bảo trì có thể đánh giá được như:
• Thời gian nhận biết vấn đề.
• Thời gian trễ do các công việc hành chính.
• Thời gian lựa chọn công cụ bảo trì.
• Thời gian phân tích vấn đề.
• Thời gian xác định sự thay đổi.
• Thời gian hiệu chỉnh (hay sửa đổi) thực sự.
• Thời gian chạy thử cục bộ.
• Thời gian chạy thử tổng thể.
• Thời gian tổng kết bảo trì.
• Tổng thời gian của công việc bảo trì.
Mỗi đánh giá trên thực tế là các dữ liệu có thể cung cấp cho người quản lý về
hiệu quả của công việc.
5.2 Các công việc bảo trì
5.2.1 Cơ cấu bảo trì
Tức là những yêu cầu bảo trì được chuyển cho người kiểm soát công việc bảo trì
và từ đây chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá, người quản lý
hệ thống là thành viên của nhóm nhân viên kỹ thuật. Những nhân viên này có trách

nhiệm về một phần nhỏ của chương trình sản phẩm. Khi một yêu cầu được đánh giá,
người được ủy quyền quản lý việc thay đổi phải quyết định hành động nào được
thực hiện tiếp. Cơ cấu được miêu tả ở trên phục vụ cho việc thiết lập phạm vi trách
nhiệm đối với công việc bảo trì. Người kiểm soát và người ủy quyền quản lý việc
thay đổi có thể là một người hay một nhóm quản lý và chuyên gia kỹ thuật cao cấp.
Yêu cầu bảo trì
Người quản lý quá trình bảo trì (maintenance manager)
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 13
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Người quản lý hệ thống
5.2.2 Báo cáo
Tất cả các yêu cầu về việc bảo trì phần mềm cần được trình bày theo một
tiêu chuẩn. Người phát triển phần mềm thường cung cấp một đơn yêu cầu bảo trì
còn được gọi là báo cáo các lỗi phần mềm. Báo cáo này được người sử dụng điền
vào khi yêu cầu công việc bảo trì. Nếu xuất hiện một lỗi, bản mô tả đầy đủ tình
huống dẫn đến lỗi bao gồm dữ liệu, đoạn chương trình và các yêu cầu khác phải
được điền đầy đủ vào bản báo cáo.
Đơn yêu cầu bảo trì được coi như cơ sở để đề ra kế hoạch của công việc bảo
trì. Ngoài ra trong nội bộ công ty phần mềm một bản báo cáo thay đổi phần mềm
cũng được tạo ra. Nó thể hiện công sức cần có để thỏa mãn một đơn yêu cầu bảo trì,
trạng thái ban đầu của yêu cầu sửa đổi, các dữ liệu cần cho việc sửa đổi…
5.2.3 Lưu giữ các hồ sơ
Các thông tin cần phải lưu giữ trong hồ sơ bảo trì thường:
• Dấu hiệu nhận biết chương trình.
• Số lượng các câu lệnh trong chương trình nguồn.
• Số lượng các lệnh mã máy.
• Ngôn ngữ lập trình được sử dụng.
• Ngàycài đặt chương trình.
• Số các chương trình chạy từ khi cài đặt.
• Số các lỗi xử lý xảy ra.

• Mức và dấu hiệu thay đổi chương trình.
• Số các câu lệnh được thêm vào chương trình nguồn khi chương trình thay
đổi.
• Số các câu lệnh được xóa khỏi chương trình nguồn khi chương trình thay đổi.
• Số giờ mỗi người sử dụng cho mỗi lần sửa đổi.
• Ngày thay đổi chương trình.
• Dấu hiệu của kỹ sư phần mềm.
• Dấu hiệu của đơn yêu cầu bảo trì.
• Kiểu bảo trì.
• Ngày bắt đầu và kết thúc bảo trì.
• Tổng số giờ của mỗi người dùng cho việc bảo trì.
Tuy nhiên, các hồ sơ lưu trữ về việc bảo trì thường không có do cơ quan đó phá
sản hay các cơ quan bảo trì là độc lập nhau.
5.3 Định giá bảo trì
Chi phí bảo trì là rất lớn so với các chi phí khác trong quy trình phát triển phần
mềm.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 14
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Bảng 1: Tỉ lệ chi phí bảo trì
ăm
T
ỉ lệ
chi
phí
bảo
trì(
%)
T
ài
liệ

u
th
a
m
kh
ảo
000
>
90
%
C
hi phí
dành
cho
phát
triển
và bảo
trì/
tổng
chi phí
phần
mềm
E
rli
kh
(2
00
0)
993
7

5%
B
ảo trì
phần
mềm/n
gân
sách
hệ
thống
thông
tin(tro
ng tài
sản
của
1000
công
ty)
E
as
tw
oo
d(
19
93
)
990
>
90
%
C

hi phí
dành
M
oa
d(
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 15
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
cho
phát
triển
và bảo
trì/
tổng
chi phí
phần
mềm
19
90
)
990
6
0-
70
%
B
ảo trì
phần
mềm/n
gân
sách

điều
hành
hệ
thống
thông
tin
quản
lý(MI
S)
H
uf
f(
19
90
)
988
6
0-
70
%
B
ảo trì
phần
mềm/n
gân
sách
điều
hành
hệ
thống

thông
tin
quản
lý(MI
S)
P
or
t(
19
88
)
984
6
5-
75
%
C
ông
sức
tiêu
M
c
K
ee
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 16
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
tốn
cho
bảo
trì/tổn

g công
sức
công
nghệ
phần
mềm
có sẵn
(1
98
4)
981
>
50
%
T
hời
gian
nhân
viên
tiêu
tốn
cho
bảo
trì/tổn
g thời
gian(tr
ên 487
tổ
chức)
L

ie
nt
z
&
S
w
an
so
n(
19
81
)
979
6
7%
C
hi phí
bảo
trì/tổn
g chi
phí
phần
mềm
Z
el
ko
wi
tz
et
al.

(1
97
9)
Biểu thức cung cấp một mô hình cho việc bảo trì:
M= p + K*exp(c-d)
Với M là toàn bộ các công việc cho việc bảo trì
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 17
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
p là công việc làm
K là hằng số kinh nghiệm
c là đánh giá độ phức tạp được tính cho việc thiếu thiết kế về cấu trúc dữ liệu
d là đánh giá mức độ hiểu biết về phần mềm
Việc xác định chi phí bảo trì thường phức tạp.theo các chuyên gia việc đánh giá
về việc thực hiện bảo trì dựa vào:
• Số lượng trung bình các lỗi xử lý cho một lần chạy chương trình.
• Tổng số giờ của mỗi người dùng cho mỗi loại bảo trì.
• Số lượng trung bình các thay đổi theo chương trình, theo ngôn ngữ lập trình,
theo kiểu bảo trì.
• Số giờ trung bình của mỗi người cho một dòng lệnh được thêm vào và xóa đi.
• Số giờ trung bình của mỗi người cho một ngôn ngữ lập trình.
• Thời gian trung bình cho việc bảo trì một đơn yêu cầu bảo trì.
• Tỷ lệ phần trăm của mỗi kiểu bảo trì.
Hình dưới là chi phí của từng giai đoạn trong quy trình phát triển phần mềm.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 18
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Hình 6: Chi phí phát triển phần mềm
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 19
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
II. QUY TRÌNH BẢO TRÌ PHẦN MỀM
1. Quy trình bảo trì tổng quát

Tùy vào quy trình bảo trì cho loại phần mềm mà mô hình các hoạt động có khác
nhau, song cơ bản tuân thủ theo mô hình sau:
Hình 7: Mô hình bảo trì phần mềm
Khi có yêu cầu cần thay đổi (những yêu cầu phát sinh từ người dùng, khách hàng
hay nhu cầu quản lý mà có tác động đến hệ thống) sẽ tiến hành phân tích mức độ
ảnh hưởng của sự thay đổi đến các thành phần hiện có của hệ thống. Dựa vào đó để
quyết định phạm vi bảo trì ở mức độ nào: làm tất các các yêu cầu, chỉ làm việc sửa
lại lỗi hay là không làm gì cả …
Nếu những thay đổi được phê duyệt cho thực hiện bắt đầu lên kế hoạch release
cho phiên bản sửa đổi (về nhân sự, hướng tiếp cận bảo trì…), thực thi những thay
đổi và release hệ thống.
Quy trình bảo trì phần mềm cung cấp các hoạt động và chi tiết đầu vào đầu ra
cho các hoạt động đó, và nó được miêu tả trong chuẩn bảo trì phần mềm IEEE 1291
1998.Mô hình quy trình này bắt đầu với việc cố gắng bảo trì phần mềm trong giai
đoạn sau khi giao hàng và các vấn đề thảo luận như kế hoạch bảo trì.
Bảo trì gồm các công việc sau:
• Sửa lỗi.
• Chỉnh sửa để làm việc với nền tảng mới.
• Tăng cường cho hệ thống (thêm tính năng, tăng độ an toàn…).
• Quy trình bảo trì phần mềm cung cấp các hoạt động và chi tiết đầu vào đầu ra
cho các hoạt động đó, và nó được miêu tả trong chuẩn bảo trì phần mềm
IEEE 1291 và ISO/IEC 14764.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 20
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
1.1. Chuẩn bảo trì phần mềm IEEE 1291
Hình 8: Các hoạt động trong quy trình bảo trì phần mềm
Các giai đoạn trong quá trình bảo trì phần mềm gồm:
• Classification & Identification: phân loại yêu cầu thay đổi là repairhay là
enhancement và xác định rõ những thay đổi cần thực hiện.
• Analysis: phân tích những thay đổi, cũng như những ảnh hưởng của sự thay

đổi lên hệ thống cũ.
• Design: thiết kế cho phù hợp những thay đổi.
• Implementation: thực hiện các thay đổi trong source code.
• System Test: thực hiện việc test lại các chức năng thay đổi, test hồi quy toàn
bộ hệ thống.
• Acceptance Test: thực hiện test để phân phối cho khách hàng.
• Delivery: phân phối.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 21
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
1.1.1 Xác định vấn đề, phân loại và ưu tiên
Trong giai đoạn này, sự thay đổi phần mềm được xác định, phân loại và gán cho
một thứ hạng ưu tiên ban đầu. Mỗi một yêu cầu sửa đổi sẽ được đánh giá phân loại
và ưu tiên xử lý. Theo IEEE thì sẽ được phân thành 4 loại:
• Corrective.
• Adaptive.
• Perfective.
• Emergency.
1.1.1.1. Đầu vào
Đầu vào của giai đoạn này là các yêu cầu thay đổi.
1.1.1.2. Quá trình thực hiện
Khi có một yêu cầu thay đổi phần mềm, các hành động sau đây sẽ xảy ra trong
quá trình bảo trì phần mềm:
• Gán một mã số nhận dạng.
• Phân loại các loại hình bảo dưỡng.
• Phân tích các sửa đổi để xác định nên chấp nhận, từ chối, hoặc đánh giá
thêm.
• Ước tính sơ bộ sự thay đổi độ lớn, kích thước.
• Định mức ưu tiên các yêu cầu sửa đổi.
• Gửi yêu cầu tới khối lập lịch để thực hiện thay đổi.
1.1.1.3. Đầu ra

Đầu ra của quá trình này bao gồm:
• Báo cáo về một vấn đề hay một quy trình mới;
• Bản đánh giá yêu cầu hoặc vấn đề;
• Phân loại các loại hình bảo dưỡng;
• Thứ tự ưu tiên ban đầu;
• Ước tính nguồn lực ban đầu cần thiết để sửa đổi hệ thống.
1.1.2. Phân tích
Giai đoạn phân tích sẽ sử dụng thông tin của giai đoạn trước đó, cùng với các tài
liệu của hệ thống và dự án để nghiên cứu tính khả thi, khả năng điều chỉnh và lập
một kế hoạch sơ bộ cho việc thiết kế, thực hiện, kiểm tra và bàn giao. Các số liệu,
biện pháp và các yếu tố liên quan được xác định trong giai đoạn này phải được thu
thập và xem xét trước.
1.1.2.1. Đầu vào
Đầu vào cho quá trình phân tích bao gồm:
• Các yêu cầu xử lý đã được xác nhận.
• Ước tính tài nguyên ban đầu và thông tin các kho chứa khác.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 22
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
• Các tài liệu về dự án và hệ thống nếu có.
1.1.2.2. Quá trình thực hiện
Phân tích là một quá trình được lặp đi lặp lại nhiều lần và có ít nhất hai thành
phần: phân tích tính khả thi và phân tích chi tiết.
Phân tích tính khả thi
Phân tích tính khả thi bao gồm những điều sau đây:
• Tác động của việc sửa đổi.
• Các giải pháp thay thế.
• Phân tích các yêu cầu chuyển đổi.
• Tính an toàn và bảo mật.
• Các yếu tố con người.
• Chi phí ngắn hạn và chi phí dài hạn.

• Các lợi ích khi sửa đổi.
Phân tích chi tiết
Việc phân tích chi tiết bao gồm:
• Xác định các yêu cầu sửa đổi từ phía khách hàng.
• Xác định các yếu tố cần thay đổi.
• Xác định các yêu cầu an ninh và an toàn.
• Xây dựng một chiến lược thử nghiệm.
• Xây dựng một kế hoạch thực hiện.
1.1.2.3. Đầu ra
Đầu ra của quá trình này bao gồm:
• Báo cáo về tính khả thi của việc thay đổi.
• Báo cáo phân tích chi tiết.
• Các yêu cầu cần cập nhật.
• Thay đổi danh sách cơ bản.
• Kiểm tra chiến lược.
• Kế hoạch thực hiện.
1.1.3. Thiết kế
Trong giai đoạn thiết kế, tất cả các thành phần bao gồm tài liệu về dự án, hệ
thống, phần mềm hiện có và cơ sở dữ liệu, và đầu ra của giai đoạn phân tích sẽ được
sử dụng cho việc thiết kế sửa đổi hệ thống.
1.1.3.1. Đầu vào
Đầu vào cho giai đoạn thiết kế bao gồm:
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 23
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
• Đầu ra của giai đoạn phân tích (báo cáo phân tích chi tiết, báo cáo các yêu
cầu cập nhật, dạnh sách sửa đổi cơ bản, chiến lược kiểm tra và kế hoạch thực
hiện).
• Các tài liệu về dự án và hệ thống.
• Mã nguồn, cơ sở dữ liệu…
1.1.3.2. Quá trình thực hiện

Các bước trong quy trình thiết kế bao gồm:
• Xác định các module phần mềm bị ảnh hưởng.
• Chỉnh sửa tài liệu về các module (biểu đồ điều khiển luồng và dữ liệu, sơ đồ,
…).
• Tạo test-case cho thiết kế mới, bao gồm cả các vấn đề an ninh và an toàn.
• Tạo các bài kiểm tra hổi quy (regression tests).
• Xác định tài liệu các yêu cầu cập nhật.
• Cập nhật danh sách sửa đổi.
1.1.3.3. Đầu ra
Đầu ra của giai đoạn thiết kế bao gồm:
• Danh sác các sửa đổi.
• Cập nhật những thiết kế cơ sở.
• Cập nhật kế hoạch kiểm thử.
• Phân tích chi tiết các sửa đổi.
• Thực hiện các kế hoạch sửa đổi.
• Danh sách những khó khăn và rủi ro.
1.1.4. Cài đặt
Trong giai đoạn này, kết quả của giai đoạn thiết kế, mã nguồn, các tài liệu dự án
và hệ thống được sử dụng để thực hiện việc cài đặt.
1.1.4.1. Đầu vào
Đầu vào của quá trình cài đặt bao gồm:
• Kết quả của quá trình thiết kế.
• Mã nguồn.
• Các tài liệu dự án và hệ thống.
1.1.4.2. Quá trình thực hiện
Giai đoạn này bao gồm bốn quy trình con sau đây, mỗi quy trình con có thể được
thực hiện lặp đi lặp lại:
• Coding và kiểm tra các module.
• Tích hợp.
• Phân tích tính rủi ro.

• Kiểm tra tính sẵn sàng.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 24
TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
1.1.4.3. Đầu ra
Đầu ra của quá trình này bao gồm:
• Phần mềm đã được cập nhật
• Cập nhật các tài liệu thiết kế.
• Cập nhật tài liệu hướng dẫn kiểm tra.
• Cập nhật tài liệu hướng dẫn người sử dụng.
• Cảnh báo rủi ro và khuyến cáo cho người dùng.
• Báo cáo kiểm tra tính sẵn sàng.
1.1.5. Kiểm thử hệ thống
Giai đoạn này phải được thực hiện trên hệ thống đã được sửa đổi từ giai đoạn
trước.Kiểm tra hồi quy phải được thực hiên để chắc rằng hệ thống không còn mắc
phải những lỗi tồn tại trước khi bảo trì.
1.1.5.1. Đầu vào
Đầu vào giai đoạn kiểm thử hệ thống bao gồm:
• Báo cáo đánh giá kiểm tra tính sẵn sàng;
• Các tài liệu về kế hoạch kiểm thử hệ thống, tài liệu về test-cases, test-
procedures, hướng dẫn sử dụng…
• Hệ thống đã được cập nhật.
1.1.5.2. Quá trình thực hiện
Kiểm tra hệ thống sẽ được thực hiện trên một hệ thống được tích hợp đầy đủ,
bao gồm các bước:
• Kiểm thử chức năng của hệ thống.
• Kiểm thử giao diện.
• Kiểm thử hồi quy.
• Kiểm thử tính sẵn sang của hệ thống.
1.1.5.3. Đầu ra
Đầu ra của quá trình này bao gồm:

• Kiểm tra tính tích hợp của hệ thống.
• Báo cáo công việc kiểm thử.
• Báo cáo đánh giá kiểm tra tính sẵn sàng.
1.1.6. Kiểm nhận (Acceptance test)
Kiểm nhận phải được thực hiện trên hệ thống khi mà quá trình kiểm thử hệ
thống đã hoàn thành.Kiểm nhận phải được thực hiện bởi khách hàng, người sử dụng
hoặc là một bên thứ ba dưới sự ủy quyền của khách hàng.
1.1.6.1. Đầu vào
Đầu vào của quá trình kiểm nhận bao gồm:
• Báo cáo đánh giá tính sẵn sàng.
NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 25

Công nghệ phần mềm quy trình bảo trì phần mềm

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về