Công nghệ phần mềm quy trình bảo trì phần mềm – Tài liệu text

admin đăng lúc 02/01/2023

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 )

Bạn đang đọc: Công nghệ phần mềm quy trình bảo trì phần mềm – Tài liệu text

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.

Xem thêm: In Tem Bảo Hành Giá Rẻ – Tem Vỡ – Uy Tín Chất Lượng | IN5G

• 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

Xem thêm: Chính sách bảo hành

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
phần mềm hoàn thành xong ship hàng nhu yếu của người dùng cần trải qua một quy trìnhphát triển phần mềm gồm nhiều quy trình tiến độ khác nhau. Quy trình tăng trưởng phần mềmlà một cấu trúc gồm có tập hợp những thao tác và những hiệu quả đối sánh tương quan sử dụngtrong việc tăng trưởng để sản xuất ra một mẫu sản phẩm phần mềm. Để có một quy chuẩncho tiến trình tăng trưởng phần mềm, tổ chức triển khai ISO / IEC đã đưa ra chuẩn ISO / IEC12207. Mục đích là trở thành một tiêu chuẩn định nghĩa tổng thể những việc làm cầnthực hiện để thiết kế xây dựng và bảo trì loại sản phẩm phần mềm. Theo chuẩn này, có 4 thao táccơ bản là nền tảng cho quá trình tăng trưởng phần mềm. • Đặc tả phần mềm : Các tính năng của phần mềm và điều kiện kèm theo hoạt động giải trí củanó phải được định nghĩa. • Sự tăng trưởng của phần mềm : Để phần mềm đạt được đặc tả thì cần có quytrình này. • Đánh giá phần mềm : Phần mềm phải được nhìn nhận để chắc như đinh rằng nólàm những gì mà người mua muốn. • Sự tiến hóa của phần mềm : Phần mềm phải được tiến hóa để thỏa mãn nhu cầu sựthay đổi những nhu yếu của người mua. Một tiến trình tăng trưởng phần mềm ( chu kỳ luân hồi sống của phần mềm ) gồm những giaiđoạn cơ bản sau : • Requirements ( nghiên cứu và phân tích nhu yếu ) : Thu thập nhu yếu của người mua về phầnmềm, nghiên cứu và phân tích và đặc tả chi tiết cụ thể về những nhu yếu đó. • Design ( phong cách thiết kế ) : chuyển tài liệu đặc tả nhu yếu ở bước trên thành tài liệu môtả phong cách thiết kế. • Coding ( lập trình ) : thực thi mã hóa tài liệu phong cách thiết kế thành mã chương trình. • Testing ( kiểm thử ) : chạy thử chương trình, phát hiện lỗi hay khả chuyển phầnmềm để tương thích với những phần mềm khác. • Deployment ( tiến hành ) : triển khai thiết lập chương trình, đổi khác nhu yếu củakhách hàng, tăng cấp chương trình. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 3T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMHình 1 : Chu kỳ sống của phần mềmTheo quy trình tiến độ trên thì việc triển khai bảo trì phần mềm sẽ được triển khai ở giaiđoạn tiến hành phần mềm và là phần sau cuối trong một chu kỳ luân hồi sống của phầnmềm. Bảo trì phần mềm ( software maintenance ) gồm có kiểm soát và điều chỉnh những lỗi màchưa được phát hiện trong những tiến trình trước của chu kỳ luân hồi sống của một phần mềm, tăng cấp tính năng sử dụng và bảo đảm an toàn quản lý và vận hành của phần mềm. Việc bảo trì phầnmềm hoàn toàn có thể chiếm đến 65 % – 75 % công sức của con người trong chu kỳ luân hồi sống của một phần mềm. Nhiệm vụ của quá trình bảo trì phần mềm nhằm mục đích giữ cho phần mềm được cập nhậtkhi thiên nhiên và môi trường quản lý và vận hành đổi khác và nhu yếu của người mua đổi khác. Theo chuẩnIEEE ( 1993 ), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần mềmsau khi đã chuyển giao để chỉnh lại những lỗi phát sinh, cải tổ hiệu năng của phần mềmhoặc những thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trườngđã bị biến hóa. 1.2 Khó khănViệc bảo trì phần mềm sẽ chịu ảnh hưởng tác động trực tiếp từ nhiều yếu tố như : kíchthước của mạng lưới hệ thống, tuổi của mạng lưới hệ thống, đầu ra và cấu trúc của tài liệu, ngôn từ lậptrình, hay độ dài của mã 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 hạn, gây khó khăn vất vả trong việc đọc hiểu và bảo trì, do khôngcó sự liên kết ngặt nghèo giữa những thành phần phần mềm và TT tài liệu của hệthống. Chìa khóa của việc bảo trì một mạng lưới hệ thống phức tạp là phải hiểu chúng, phảiNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 4T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMhiểu sâu về những thành phần công dụng, phi công dụng, và những tương tác giữa chúng. Đặc biệt, khó khăn vất vả nhất nằm trong phần mã nguồn, nhiều nghiên cứu và điều tra đã chỉ ra rằngchi phí dành cho việc đọc hiểu mã nguồn chiếm một phần rất lớn trong hàng loạt chiphí bảo trì phần mềm. Theo quy mô của mạng lưới hệ thống, lượng mã nguồn và những mối quanhệ giữa những 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 vất vả 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 chuyên sâu bảo trì. Các link truy vết giúp cho những kĩ sư phần mềm hiểu được mối quan hệ và sựphụ thuộc giữa những thành phần phần mềm từ đó giúp sức cho quy trình đọc hiểu mãnguồn. Tuy nhiên, ngay trong những tổ chức triển khai và dự án Bất Động Sản với quá trình tăng trưởng phầnmềm thuần thục, những thành phần phần mềm được tạo ra trong những bước của quy trìnhnày ở đầu cuối cũng bị mất link với những thành phần khác. Các tác nhân chủ yếudẫn đến việc mất link giữa những thành phần phần mềm gồm có : • Các thành phần phần mềm khác nhau được viết bằng những ngôn từ khácnhau ( ngôn từ tự nhiên và ngôn từ lập trình ). • Các thành phần phần mềm miêu tả mạng lưới hệ thống phần mềm ở những Lever trừu tượngkhác nhau ( Lever phong cách thiết kế và thiết lập ). • Các quá trình làm đổi khác một thành phần giả tưởng ( artifact ) không dẫn đếncác sửa đổi link đang sống sót giữa nó với những 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 nhắc nhở choviệc sửa tài liệu sử dụng của mã đó ) • Thiếu những công cụ tương hỗ việc tạo và duy trì những link truy vết này. Các điều tra và nghiên cứu tạo link 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 liên kết tài liệu và mã nguồn dựa trên những link một-một. Hạn chế lớn nhất của chiêu thức này là đã bỏ lỡ những thông tin ngữ nghĩa, có cấu trúc hoàn toàn có thể tìm thấy trong những tài liệu và mã nguồn, dẫn đến sự thiếu chínhxác và năng lực ứng dụng trong trong thực tiễn không được cao. Một thử thách khác đó là việc xác lập những rủi ro tiềm ẩn bảo mật thông tin. Đối với những ứngdụng được đặt vào những môi trường tự nhiên đổi khác sẽ có độ rủi ro đáng tiếc bảo mật thông tin cao, việc xácđịnh những lỗ hổng bảo mật thông tin này trong những mạng lưới hệ thống phần mềm sống sót trở thành mộttrong những việc làm quan trọng trong tiến trình bảo trì phần mềm. Trong khi mãnguồn ngày càng tăng nhanh thì yếu tố này lại càng trở lên ngày càng khó khăn vất vả bởiđể phát hiện được những rủi ro tiềm ẩn bảo mật thông tin thì người bảo trì phải thực sự hiểu được hệthống của mình. Một thử thách khác gặp phải trong quy trình bảo trì mạng lưới hệ thống là một kỹ sư phầnmềm, theo thời hạn cũng không còn nắm rõ được những thông tin về kiến trúc, về mãnguồn, hay rộng hơn là những giả tưởng ( artifact ) do chính họ tạo ra nữa. Khó khănNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 5T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMthậ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 tăng trưởng phần mềm. Tương tự như vậy, nếu không được tương hỗ, người kỹ sưsẽ gặp khó khăn vất vả không nhỏ khi muốn tái sử dụng những artifact của chính mình, chưanói đến tái sử dụng artifact sẵn có của người khác. Việc tìm kiếm, nghiên cứu và phân tích và tìm hiểu và khám phá mã nguồn đóng vai trò rất quan trọng. Tuynhiên, ngay trong những IDE ( Integrated Development Environment-môi trườngphát triển tích hợp ) tăng trưởng phần mềm mạnh nhất như Eclipse, việc tương hỗ tìmkiếm cũng không can đảm và mạnh mẽ khi chỉ đơn thuần tìm kiếm văn bản riêng không liên quan gì đến nhau, thôngthường theo tên những method, class, … mà không tương hỗ tìm kiếm phối hợp giữa cácthành phần này. Người lập trình rất hay gặp phải những trường hợp tìm kiếm như : tìm kiếm những phương pháp nhận một kiểu nào đó làm đối số nguồn vào hay tìm kiếmcác phương pháp trả về một kiểu tài liệu nào đó. Hiện nay chưa có một IDE nào thỏamãn những nhu yếu tìm kiếm này đơn thuần là do tại chúng không khai thác tính ngữnghĩa giữa những thành phần của mã nguồn để triển khai tìm kiếm. Ngoài ra việc bảotrì phần mềm sẽ gặp không ít khó khăn vất vả khi môi trường tự nhiên quản lý và vận hành không tương thích, cósự tích hợp chồng chéo, không thích hợp của những phần mềm. Thiếu kinh nghiệmkiểm chuẩn, xác lập giải pháp, kế hoạch cho bảo trì. Yêu cầu của khách hàngquá nhiều và luôn đổi khác. Để khắc phục những khó khăn vất vả trên, tăng hiệu suất cao cho quy trình bảo trì phầnmềm tất cả chúng ta nên sử dụng 1 số ít giải pháp sau : • Lưu lại rất đầy đủ, đúng mực thông tin về phần mềm. • Chuẩn hóa những thao tác kiểm chuẩn, bảo trì. • Sử dụng những công cụ tương hỗ tăng trưởng và bảo trì phần mềm. • Lựa chọn thiên nhiên và môi trường quản lý và vận hành thích hợp với từng phần mềm. 2. Phân loạiTheo chuẩn IEEE thì bảo trì phần mềm được phân thành 4 loại : • Bảo trì tu sửa ( Corrective Maintenance ) • Bảo trì thích nghi ( Adaptive Maintenance ) • Bảo trì nâng cấp cải tiến ( Perfective Maintenance ) • Bảo trì phòng ngừa ( Preventive Maintenance ) NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 6T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMHình 2 : Phân loại bảo trì2. 1 Bảo trì tu sửaBảo trì tu sửa ( Corrective Maintenance ) là bảo trì được thực thi nhằm mục đích sửa cáclỗi hay khuyết điểm phát sinh được tìm thấy. Lỗi hay khuyết điểm thường phát sinhdo : • Lỗi phong cách thiết kế : Open khi những sự đổi khác, update làm cho phần mềmhoạt động không còn đúng chuẩn, rất đầy đủ, thậm chí còn là truyền đạt sai hay nhữngyêu cầu biến hóa bị hiểu sai. • Lỗi logic : Open do việc triển khai tiến trình kiểm tra, đưa ra Kết luận sai, triển khai không đúng theo phong cách thiết kế chi tiết cụ thể kỹ thuật hoặc tài liệu không đượckiểm tra khá đầy đủ. • Lỗi coding : do người lập trình thực thi không đúng những quy tắc chi tiết cụ thể thiếtkế hoặc không tuân thủ theo những quy tắc logic mã nguồn. • Ngoài ra còn Open do việc giải quyết và xử lý tài liệu hay quản lý và vận hành mạng lưới hệ thống gặp lỗi. Bảo trì tu sửa thường sử dụng kỹ thuật dịch ngược ( Reverse Enginnering ) dòtheo phong cách thiết kế để tìm lỗi. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 7T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM2. 2 Bảo trì thích nghiBảo trì thích nghi ( Adaptive Maintenance ) là bảo trì được triển khai nhằm mục đích chỉnhsửa phần mềm, làm cho phần mềm hoạt động giải trí được thông thường khi có sự thay đổicủa thiên nhiên và môi trường. Môi trường ở đây được hiểu là tổng thể những ảnh hưởng tác động, hành vi bênngoài tác động ảnh hưởng làm cho phần mềm không còn hoạt động giải trí đúng mực nữa. Đó hoàn toàn có thể làsự biến hóa về chủ trương kinh doanh thương mại, quy tắc hoạt động giải trí của công ty, quy mô làmviệc hay sự đổi khác của những thiết bị phần cứng, hệ quản lý, hoặc những thiết bị đikèm … 2.3 Bảo trì cải tiếnKhi phần mềm được triển khai xong và đưa vào sử dụng thành công xuất sắc, người dùng sẽcàng chăm sóc đến nó. Việc này sẽ dẫn đến việc người dùng muốn thử những chứcnăng vượt ra ngoài khoanh vùng phạm vi của phần mềm, do đó sẽ dẫn tới việc người dùng sẽ đặtra những nhu yếu mới. Việc bảo trì nâng cấp cải tiến ( Perfective Maintenance ) là bảo trì đượcthực hiện nhằm mục đích biến hóa phần mềm theo những nhu yếu ngày càng triển khai xong hơn, vừa đủ hơn, hài hòa và hợp lý hơn. Đây là hình thái bảo trì phổ cập nhất trong thực tiễn. Việctiến hành bảo trì được đặt ra khi người mua muốn nâng cao hiệu suất, cải tiếnphương thức truy nhập, lan rộng ra thêm tính năng cho mạng lưới hệ thống, nâng cấp cải tiến quản trị làmcải tiến tư liệu quản lý và vận hành và trình tự việc làm, hay hoàn toàn có thể do đổi khác người dùngdẫn đến đổi khác những thao tác triển khai. 2.4 Bảo trì phòng ngừaBảo trì phòng ngừa ( Preventive Maintenance ) sẽ chăm sóc tới những hoạt độngnhằm tăng cường năng lực hoàn toàn có thể bảo trì của mạng lưới hệ thống, như update tài liệu, ghichú, cải tổ cấu trúc của mạng lưới hệ thống. Việc bảo trì này là sự tu sửa phần mềm có tínhđến tương lai của phần mềm đó sẽ được lan rộng ra hay biến hóa như thế nào nhằmgiảm bớt độ phức tạp của mạng lưới hệ thống và làm cho những lần bảo trì sau trở thuận tiện hơn. 3. Ý nghĩaBảo trì là quy trình tiến độ ở đầu cuối trong một chu kỳ luân hồi sống của phần mềm, nhằm mục đích nângcấp tính năng của phần mềm và làm cho phần mềm hoạt động giải trí không thay đổi, hiệu quảhơn. Bảo trì phần mềm để chắc như đinh rằng phần mềm tạo ra thỏa mãn nhu cầu được rất đầy đủ, đúng chuẩn những nhu yếu của người mua. Bảo trì cần phải thực thi để : • Chỉnh sửa những lỗi • Nâng cao phong cách thiết kế • Có thể setup nâng cao • Giao tiếp được với những mạng lưới hệ thống khácNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 8T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM • Thích ứng được chương trình với những phần cứng, phần mềm, những phương tiệntruyền thống khác. • Giúp mạng lưới hệ thống dễ sử dụng lại trong những lần tiếp theo. Bảo trì sẽ được triển khai theo định kỳ, triển khai khi có sự cố xảy ra hay khi yêucầu của người mua đổi khác. Với một mạng lưới hệ thống mạng Server việc bảo trì là rất quantrọng, cần phải được thực thi theo định kỳ để bảo vệ mạng lưới hệ thống hoạt động giải trí đượcliên tục, không thay đổi. Bởi một mạng lưới hệ thống Server thì nhu yếu hoạt động giải trí liên tục là thực sựquan trọng, để phân phối được những nhu yếu của những client. Với mạng lưới hệ thống mạng nội bộ ( ví dụ như trong một phòng ban của công ty ) thì việc bảo trì hoàn toàn có thể chỉ cần khi phầnmềm đó gặp sự cố. Bởi mức độ nhu yếu phần mềm cần hoạt động giải trí liên tục khôngcao, tầm ảnh hưởng tác động của bảo trì là không lớn. Trong mạng lưới hệ thống ngân hàng nhà nước ( ghi ngân sách, giao dịch thanh toán tiền ) thì việc bảo trì cũng cần được thực thi định kỳ, bởi nhu yếu vềchức năng của phần mềm trong nghành này rất cao, luôn yên cầu không được xảy rasai sót. Việc bảo trì cần bảo vệ cho mạng lưới hệ thống được quản lý và vận hành không thay đổi, đúng mực. Trong một mạng lưới hệ thống mạng nhiều ứng dụng như những phần mềm trên mobile thì yêucầu của bảo trì là tiếp tục, nhưng không cao. Bởi trong những mạng lưới hệ thống này thìmôi trường hoạt động giải trí luôn biến hóa, nhu yếu của người mua cũng biến hóa theo sựphát triển của khoa học công nghệ tiên tiến. Việc bảo trì trong mạng lưới hệ thống này hầu hết do sựphát triển và nhu yếu ngày một cao của người mua. 4. Mô hình bảo trì phần mềm4. 1. Mô hình Quick-FixHình 3 : Quick-fixNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 9T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMMô hình Quick-fix đại diện thay mặt cho một sự trừu tượng của cách tiếp cận nổi bật đểbảo trì phần mềm. Trong quy mô Quick-fix, bạn sẽ sử dụng những thứ hệ thốnghiện có, thường chỉ là mã nguồn và triển khai những biến hóa thiết yếu đến mãnguồn và những tài liệu kèm theo, sau đó biên dịch lại những mạng lưới hệ thống như thể một phiênbản mới. Điều này hoàn toàn có thể đơn thuần như một sự biến hóa 1 số ít thành phần bên trongnhư sửa một lỗi tương quan đến một thành phần hoặc sự biến hóa cấu trúc hoặc thậmchí 1 số ít công dụng cao hơn. Hình 3 cho thấy sự đổi khác 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úcnào cũng đúng – tài liệu kèm theo hướng dẫn cũng được update. Bạn hoàn toàn có thể hiểumô hình này theo hướng tái sử dụng, vì việc tạo ra một mạng lưới hệ thống mới bằng cách táisử dụng mạng lưới hệ thống cũ hay chỉ đơn thuần là sửa đổi mạng lưới hệ thống cũ. Ưu điểm : • Nhanh. • Có thể hữu dụng cho dự án Bất Động Sả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 quy trình bảo trìcó thể sẽ phá vỡ phong cách thiết kế bắt đầu của phần mềm. 4.2. Mô hình Iterative EnhancementHình 4 : Iterative Enhancement modelNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 10T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMDựa trên nhận định và đánh giá rằng một mạng lưới hệ thống khi kiến thiết xây dựng rất khó hoàn toàn có thể đã đáp ứngđược hết nhu yếu của người sử dụng, chiêu thức interative – enhance tiếnhành kiến thiết xây dựng mạng lưới hệ thống hoàn hảo dựa trên cơ sở nghiên cứu và phân tích trong bước đầu về yêucầu của mạng lưới hệ thống, thực thi nghiên cứu và phân tích sâu hơn nhu yếu đặt ra so với phần mềmdựa trên phản hồi của người sử dụng để thiết kế xây dựng mạng lưới hệ thống mới. Ưu điểm : • Tương đối đơn thuần • So với quick-fix là những tài liệu của mạng lưới hệ thống được update liên tục vớimọi sự biến hóa của mạng lưới hệ thống. Nhược điểm : • Những quyết định hành động, nhu yếu không rõ ràng. 4.3. Mô hình Full-reuseHình 5 : Full-reuseMục đích của tái sử dụng lại là nhằm mục đích tăng hiệu suất, chất lượng và tạo điều kiệnthuận lợi cho việc quy đổi mã, giảm bớt thời hạn ngân sách để bảo trì. Có thể hiểuNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 11T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ 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 những kinhnghiệm đã có từ chính mạng lưới hệ thống đó hay những mạng lưới hệ thống tựa như nhằm mục đích giảm bớt nỗ lựcđể tăng trưởng hay bảo trì mạng lưới hệ thống. Ứng dụng tư tưởng tái sử dụng, giải pháp full-reuse thiết kế xây dựng mạng lưới hệ thống mớitrên cơ sở tái sử dụng những yếu tố tương thích trong từng quá trình khi kiến thiết xây dựng hệthống cũ. Do đó, chiêu thức này thích hợp cho việc kiến thiết xây dựng những mạng lưới hệ thống cóvòng đời ngắn. Tăng năng lực tái sử dụng của những thành phần mạng lưới hệ thống. Đặc biệt, khi tích hợp full-reuse và interative enhancement hoàn toàn có thể tăng đáng kể hiệu suất cao kinhtế của quy trình bảo trì phần mềm. Ưu điểm : • Có thể dùng những thành phần từ những dự án Bất Động Sản khác. • Mã nguồn được chia thành những modun nhỏ. Nhược điểm : • Ngân sách chi tiêu trong phong cách thiết kế để tái sử dụng cao. 5. Công việc bảo trì phần mềm5. 1 Khả năng bảo trìKhả năng bảo trì của phần mềm hoàn toàn có thể coi như những năng lực hiểu, hiệu chỉnhhoặc hoàn toàn có thể thêm vào năng lực tăng trưởng phần mềm. Khả năng bảo trì là chìa khóađể dẫn đến những chiêu thức phong cách thiết kế kiến thiết xây dựng phần mềm. 5.1.1 Yếu tố kiểm soátKhả năng bảo trì gồm nhiều yếu tố như : sự thiếu thận trọng trong việc phong cách thiết kế, viết chương trình nguồn, kiểm tra, thông số kỹ thuật yếu kém có tác động ảnh hưởng xấu đi đến việcbảo trì. Thêm vào đó những yếu tố khác tương quan đến giải pháp phát triến phầnmềm như : • Chất lượng hiệu suất cao của đội ngũ phần mềm • Cấu trúc của mạng lưới hệ thống dễ hiểu • Dễ dàng trấn áp mạng lưới hệ thống • Dùng những ngôn từ lập trình chuẩn • Dùng những hệ quản lý chuẩn • Dùng những cấu trúc chuẩn tài liệu • Dùng được những tài liệu kiểm tra • Phương tiện tháo gỡ đi kèm • Dùng được những máy tính tốt để thực thi việc bảo trìCác yếu tố ở trên đã phản ánh những đặc thù về phần cứng cũng như chươngtrình nguồn được dùng trong việc tăng trưởng phần mềm và còn chỉ ra được sự cầnNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 12T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMthiết để có được chương trình nguồn chuẩn. Nếu coi phần mềm như một hệ thốngcác thành phần sẽ phải chịu những biến hóa không hề tránh được thì thời cơ tạo ranhững phần mềm có năng lực bảo trì sẽ thực sự tăng lên. 5.1.2 Đánh giá định lượngKhả năng bảo trì cũng như chất lượng hay độ an toàn và đáng tin cậy là rất là khó xác lập. Tuy nhiên tất cả chúng ta hoàn toàn có thể nhìn nhận năng lực bảo trì gián tiếp bằng việc xem xét cácthuộc tính của những việc làm bảo trì hoàn toàn có thể nhìn nhận được như : • Thời gian nhận ra yếu tố. • Thời gian trễ do những việc làm hành chính. • Thời gian lựa chọn công cụ bảo trì. • Thời gian nghiên cứu và phân tích yếu tố. • Thời gian xác lập sự đổi khác. • 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ể và toàn diện. • Thời gian tổng kết bảo trì. • Tổng thời hạn của việc làm bảo trì. Mỗi nhìn nhận trên thực tiễn là những tài liệu hoàn toàn có thể cung ứng cho người quản trị vềhiệu quả của việc làm. 5.2 Các việc làm bảo trì5. 2.1 Cơ cấu bảo trìTức là những nhu yếu bảo trì được chuyển cho người trấn áp việc làm bảo trìvà từ đây chuyển tiếp nhu yếu tới người quản trị mạng lưới hệ thống để nhìn nhận, người quản lýhệ thống là thành viên của nhóm nhân viên cấp dưới kỹ thuật. Những nhân viên cấp dưới này có tráchnhiệm về một phần nhỏ của chương trình mẫu sản phẩm. Khi một nhu yếu được nhìn nhận, người được ủy quyền quản trị việc đổi khác phải quyết định hành động hành vi nào đượcthực hiện tiếp. Cơ cấu được miêu tả ở trên ship hàng cho việc thiết lập khoanh vùng phạm vi tráchnhiệm so với việc làm bảo trì. Người trấn áp và người ủy quyền quản trị việcthay đổi hoàn toàn có thể là một người hay một nhóm quản trị và chuyên viên kỹ thuật hạng sang. Yêu cầu bảo trìNgười quản trị quy trình bảo trì ( maintenance manager ) NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 13T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMNgười quản trị hệ thống5. 2.2 Báo cáoTất cả những nhu yếu về việc bảo trì phần mềm cần được trình diễn theo mộttiêu chuẩn. Người tăng trưởng phần mềm thường cung ứng một đơn nhu yếu bảo trìcòn được gọi là báo cáo giải trình những lỗi phần mềm. Báo cáo này được người sử dụng điềnvào khi nhu yếu việc làm bảo trì. Nếu Open một lỗi, bản miêu tả rất đầy đủ tìnhhuống dẫn đến lỗi gồm có tài liệu, đoạn chương trình và những nhu yếu khác phảiđược điền không thiếu vào bản báo cáo giải trình. Đơn nhu yếu bảo trì được coi như cơ sở để đề ra kế hoạch của việc làm bảotrì. Ngoài ra trong nội bộ công ty phần mềm một bản báo cáo giải trình biến hóa phần mềmcũng được tạo ra. Nó bộc lộ sức lực lao động cần có để thỏa mãn nhu cầu một đơn nhu yếu bảo trì, trạng thái bắt đầu của nhu yếu sửa đổi, những tài liệu cần cho việc sửa đổi … 5.2.3 Lưu giữ những 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 phân biệt chương trình. • Số lượng những câu lệnh trong chương trình nguồn. • Số lượng những 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ố những chương trình chạy từ khi thiết lập. • Số những lỗi giải quyết và xử lý xảy ra. • Mức và tín hiệu đổi khác chương trình. • Số những câu lệnh được thêm vào chương trình nguồn khi chương trình thayđổi. • Số những câu lệnh được xóa khỏi chương trình nguồn khi chương trình biến hóa. • Số giờ mỗi người sử dụng cho mỗi lần sửa đổi. • Ngày đổi khác chương trình. • Dấu hiệu của kỹ sư phần mềm. • Dấu hiệu của đơn nhu yếu bảo trì. • Kiểu bảo trì. • Ngày mở màn 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, những hồ sơ tàng trữ về việc bảo trì thường không có do cơ quan đó phásản hay những cơ quan bảo trì là độc lập nhau. 5.3 Định giá bảo trìChi phí bảo trì là rất lớn so với những ngân sách khác trong quy trình tiến độ tăng trưởng phầnmềm. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 14T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMBảng 1 : Tỉ lệ ngân sách bảo trìămỉ lệchiphíbảotrì ( % ) àiliệthkhảo00090hi phídànhchopháttriểnvà bảotrì / tổngchi phíphầnmềmrlikh ( 2000 ) 9935 % ảo trìphầnmềm / ngânsáchhệthốngthôngtin ( trong tàisảncủa1000côngty ) astwood ( 199399090 hi phídànhoad ( NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 15T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMchopháttriểnvà bảotrì / tổngchi phíphầnmềm19909900-70ảo trìphầnmềm / ngânsáchđiềuhànhhệthốngthôngtinquảnlý ( MIS ) uff ( 19909880 – 70 ảo trìphầnmềm / ngânsáchđiềuhànhhệthốngthôngtinquảnlý ( MIS ) ort ( 19889845 – 75 ôngsứctiêueeNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 16T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMtốnchobảotrì / tổng côngsứccôngnghệphầnmềmcó sẵn ( 1984 ) 98150 hờigiannhânviêntiêutốnchobảotrì / tổng thờigian ( trên 487 tổchức ) ientanson ( 19819797 % hi phíbảotrì / tổng chiphíphầnmềmelkowitzetal. ( 1979 ) Biểu thức phân phối một quy mô cho việc bảo trì : M = p + K * exp ( c-d ) Với M là hàng loạt những việc làm cho việc bảo trìNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 17T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMp là việc làm làmK là hằng số kinh nghiệmc là nhìn nhận độ phức tạp được tính cho việc thiếu phong cách thiết kế về cấu trúc dữ liệud là nhìn nhận mức độ hiểu biết về phần mềmViệc xác lập ngân sách bảo trì thường phức tạp. theo những chuyên viên việc đánh giávề việc thực thi bảo trì dựa vào : • Số lượng trung bình những lỗi giải quyết và 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 những biến hóa theo chương trình, theo ngôn từ 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 từ lập trình. • Thời gian trung bình cho việc bảo trì một đơn nhu yếu bảo trì. • Tỷ lệ Tỷ Lệ của mỗi kiểu bảo trì. Hình dưới là ngân sách của từng tiến trình trong quy trình tiến độ tăng trưởng phần mềm. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 18T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMHình 6 : giá thành tăng trưởng phần mềmNHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 19T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀMII. QUY TRÌNH BẢO TRÌ PHẦN MỀM1. Quy trình bảo trì tổng quátTùy vào tiến trình bảo trì cho loại phần mềm mà quy mô những hoạt động giải trí có khácnhau, tuy nhiên cơ bản tuân thủ theo quy mô sau : Hình 7 : Mô hình bảo trì phần mềmKhi có nhu yếu cần biến hóa ( những nhu yếu phát sinh từ người dùng, khách hànghay nhu yếu quản trị mà có tác động ảnh hưởng đến mạng lưới hệ thống ) sẽ thực thi nghiên cứu và phân tích mức độảnh hưởng của sự đổi khác đến những thành phần hiện có của mạng lưới hệ thống. Dựa vào đó đểquyết định khoanh vùng phạm vi bảo trì ở mức độ nào : làm tất những những nhu yếu, chỉ thao tác sửalại lỗi hay là không làm gì cả … Nếu những biến hóa được phê duyệt cho triển khai mở màn lên kế hoạch releasecho 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 mạng lưới hệ thống. Quy trình bảo trì phần mềm cung ứng những hoạt động giải trí và chi tiết cụ thể đầu vào đầu racho những hoạt động giải trí đó, và nó được miêu tả trong chuẩn bảo trì phần mềm IEEE 12911998. Mô hình tiến trình này mở màn với việc nỗ lực bảo trì phần mềm trong giaiđoạn sau khi giao hàng và những yếu tố đàm đạo như kế hoạch bảo trì. Bảo trì gồm những việc làm sau : • Sửa lỗi. • Chỉnh sửa để thao tác với nền tảng mới. • Tăng cường cho mạng lưới hệ thống ( thêm tính năng, tăng độ bảo đảm an toàn … ). • Quy trình bảo trì phần mềm phân phối những hoạt động giải trí và cụ thể đầu vào đầu racho những hoạt động giải trí đó, và nó được miêu tả trong chuẩn bảo trì phần mềmIEEE 1291 và ISO / IEC 14764. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 20T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM1. 1. Chuẩn bảo trì phần mềm IEEE 1291H ình 8 : Các hoạt động giải trí trong tiến trình bảo trì phần mềmCác tiến trình trong quy trình bảo trì phần mềm gồm : • Classification và Identification : phân loại nhu yếu đổi khác là repairhay làenhancement và xác lập rõ những đổi khác cần thực thi. • Analysis : nghiên cứu và phân tích những biến hóa, cũng như những tác động ảnh hưởng của sự thayđổi lên mạng lưới hệ thống cũ. • Design : phong cách thiết kế cho tương thích những biến hóa. • Implementation : thực thi những đổi khác trong source code. • System Test : thực thi việc test lại những tính năng biến hóa, test hồi quy toànbộ mạng lưới hệ thống. • Acceptance Test : triển khai test để phân phối cho người mua. • Delivery : phân phối. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 21T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM1. 1.1 Xác định yếu tố, phân loại và ưu tiênTrong tiến trình này, sự đổi khác phần mềm được xác lập, phân loại và gán chomột thứ hạng ưu tiên bắt đầu. Mỗi một nhu yếu sửa đổi sẽ được nhìn nhận phân loạivà ưu tiên giải quyết và 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 quá trình này là những nhu yếu đổi khác. 1.1.1. 2. Quá trình thực hiệnKhi có một nhu yếu đổi khác phần mềm, những hành vi sau đây sẽ xảy ra trongquá trình bảo trì phần mềm : • Gán một mã số nhận dạng. • Phân loại những mô hình bảo trì. • Phân tích những sửa đổi để xác lập nên đồng ý, phủ nhận, hoặc đánh giáthêm. • Ước tính sơ bộ sự đổi khác độ lớn, kích cỡ. • Định mức ưu tiên những nhu yếu sửa đổi. • Gửi nhu yếu tới khối lập lịch để triển khai đổi khác. 1.1.1. 3. Đầu raĐầu ra của quy trình này gồm có : • Báo cáo về một yếu tố hay một tiến trình mới ; • Bản nhìn nhận nhu yếu hoặc yếu tố ; • Phân loại những mô hình bảo trì ; • Thứ tự ưu tiên khởi đầu ; • Ước tính nguồn lực bắt đầu thiết yếu để sửa đổi mạng lưới hệ thống. 1.1.2. Phân tíchGiai đoạn nghiên cứu và phân tích sẽ sử dụng thông tin của tiến trình trước đó, cùng với những tàiliệu của mạng lưới hệ thống và dự án Bất Động Sản để nghiên cứu và điều tra tính khả thi, năng lực kiểm soát và điều chỉnh và lậpmột kế hoạch sơ bộ cho việc phong cách thiết kế, triển khai, kiểm tra và chuyển giao. Các số liệu, giải pháp và những yếu tố tương quan được xác lập trong quá trình này phải được thuthập và xem xét trước. 1.1.2. 1. Đầu vàoĐầu vào cho quy trình nghiên cứu và phân tích gồm có : • Các nhu yếu giải quyết và xử lý đã được xác nhận. • Ước tính tài nguyên khởi đầu và thông tin những kho chứa khác. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 22T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM • Các tài liệu về dự án Bất Động Sản và mạng lưới hệ thống nếu có. 1.1.2. 2. Quá trình thực hiệnPhân tích là một quy trình được lặp đi lặp lại nhiều lần và có tối thiểu hai thànhphần : nghiên cứu và phân tích tính khả thi và nghiên cứu và phân tích cụ thể. Phân tích tính khả thiPhân tích tính khả thi gồm có những điều sau đây : • Tác động của việc sửa đổi. • Các giải pháp sửa chữa thay thế. • Phân tích những nhu yếu quy đổi. • Tính bảo đảm an toàn và bảo mật thông tin. • Các yếu tố con người. • Ngân sách chi tiêu thời gian ngắn và ngân sách dài hạn. • Các quyền lợi khi sửa đổi. Phân tích chi tiếtViệc nghiên cứu và phân tích cụ thể gồm có : • Xác định những nhu yếu sửa đổi từ phía người mua. • Xác định những yếu tố cần biến hóa. • Xác định những nhu yếu bảo mật an ninh và bảo đảm an toàn. • Xây dựng một kế hoạch thử nghiệm. • Xây dựng một kế hoạch triển khai. 1.1.2. 3. Đầu raĐầu ra của quy trình này gồm có : • Báo cáo về tính khả thi của việc đổi khác. • Báo cáo nghiên cứu và phân tích chi tiết cụ thể. • Các nhu yếu cần update. • Thay đổi list cơ bản. • Kiểm tra kế hoạch. • Kế hoạch thực thi. 1.1.3. Thiết kếTrong tiến trình phong cách thiết kế, toàn bộ những thành phần gồm có tài liệu về dự án Bất Động Sản, hệthống, phần mềm hiện có và cơ sở tài liệu, và đầu ra của tiến trình nghiên cứu và phân tích sẽ đượcsử dụng cho việc phong cách thiết kế sửa đổi mạng lưới hệ thống. 1.1.3. 1. Đầu vàoĐầu vào cho quy trình tiến độ phong cách thiết kế gồm có : NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 23T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM • Đầu ra của quy trình tiến độ nghiên cứu và phân tích ( báo cáo giải trình nghiên cứu và phân tích chi tiết cụ thể, báo cáo giải trình những yêucầu update, dạnh sách sửa đổi cơ bản, kế hoạch kiểm tra và kế hoạch thựchiện ). • Các tài liệu về dự án Bất Động Sản và mạng lưới hệ thống. • Mã nguồn, cơ sở dữ liệu … 1.1.3. 2. Quá trình thực hiệnCác bước trong quá trình phong cách thiết kế gồm có : • Xác định những module phần mềm bị tác động ảnh hưởng. • Chỉnh sửa tài liệu về những module ( biểu đồ tinh chỉnh và điều khiển luồng và tài liệu, sơ đồ, … ). • Tạo test-case cho phong cách thiết kế mới, gồm có cả những yếu tố bảo mật an ninh và bảo đảm an toàn. • Tạo những bài kiểm tra hổi quy ( regression tests ). • Xác định tài liệu những nhu yếu update. • Cập nhật list sửa đổi. 1.1.3. 3. Đầu raĐầu ra của quy trình tiến độ phong cách thiết kế gồm có : • Danh sác những sửa đổi. • Cập nhật những phong cách thiết kế cơ sở. • Cập nhật kế hoạch kiểm thử. • Phân tích cụ thể những sửa đổi. • Thực hiện những kế hoạch sửa đổi. • Danh sách những khó khăn vất vả và rủi ro đáng tiếc. 1.1.4. Cài đặtTrong quy trình tiến độ này, tác dụng của quy trình tiến độ phong cách thiết kế, mã nguồn, những tài liệu dự ánvà mạng lưới hệ thống được sử dụng để thực thi việc setup. 1.1.4. 1. Đầu vàoĐầu vào của quy trình setup gồm có : • Kết quả của quy trình phong cách thiết kế. • Mã nguồn. • Các tài liệu dự án Bất Động Sản và mạng lưới hệ thống. 1.1.4. 2. Quá trình thực hiệnGiai đoạn này gồm có bốn quy trình tiến độ con sau đây, mỗi quá trình con hoàn toàn có thể đượcthực hiện lặp đi lặp lại : • Coding và kiểm tra những module. • Tích hợp. • Phân tích tính rủi ro đáng tiếc. • Kiểm tra tính sẵn sàng chuẩn bị. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 24T ÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM1. 1.4.3. Đầu raĐầu ra của quy trình này gồm có : • Phần mềm đã được update • Cập nhật những tài liệu phong cách 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 đáng tiếc và khuyến nghị cho người dùng. • Báo cáo kiểm tra tính sẵn sàng chuẩn bị. 1.1.5. Kiểm thử hệ thốngGiai đoạn này phải được thực thi trên mạng lưới hệ thống đã được sửa đổi từ giai đoạntrước. Kiểm tra hồi quy phải được thực hiên để chắc rằng mạng lưới hệ thống không còn mắcphải những lỗi sống sót trước khi bảo trì. 1.1.5. 1. Đầu vàoĐầu vào tiến trình kiểm thử mạng lưới hệ thống gồm có : • Báo cáo nhìn nhận kiểm tra tính chuẩn bị sẵn sàng ; • Các tài liệu về kế hoạch kiểm thử mạng lưới hệ thống, tài liệu về test-cases, test-procedures, hướng dẫn sử dụng … • Hệ thống đã được update. 1.1.5. 2. Quá trình thực hiệnKiểm tra mạng lưới hệ thống sẽ được thực thi trên một mạng lưới hệ thống được tích hợp khá đầy đủ, gồm có những bước : • Kiểm thử tính năng của mạng lưới 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 mạng lưới hệ thống. 1.1.5. 3. Đầu raĐầu ra của quy trình này gồm có : • Kiểm tra tính tích hợp của mạng lưới hệ thống. • Báo cáo việc làm kiểm thử. • Báo cáo nhìn nhận kiểm tra tính chuẩn bị sẵn sàng. 1.1.6. Kiểm nhận ( Acceptance test ) Kiểm nhận phải được triển khai trên mạng lưới hệ thống khi mà quy trình kiểm thử hệthống đã hoàn thành xong. Kiểm nhận phải được triển khai bởi người mua, người sử dụnghoặc là một bên thứ ba dưới sự chuyển nhượng ủy quyền của người mua. 1.1.6. 1. Đầu vàoĐầu vào của quy trình kiểm nhận gồm có : • Báo cáo nhìn nhận tính sẵn sàng chuẩn bị. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 25

Source: https://vvc.vn
Category : Bảo Hành