Tải bản đầy đủ (.pdf) (74 trang)

Bài giảng Phát triển vận hành và bảo trì phần mềm - Chương 4

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 (650.45 KB, 74 trang )

Chương 4
BẢO TRÌ PHẦN MỀM
MỤC TIÊU:

Hiểu được vai trị của việc bảo trì phần mềm

Nắm được các vấn đề liên quan đến bảo trì: phân
loại, phương pháp, chi phí bảo trì …

Hiểu được một số quy trình và các chiến lược cải
tiến phần mềm

Tìm hiểu về tái kỹ nghệ


NỘI DUNG CHÍNH
3.1 Giới thiệu
3.2 Tiến trình bảo trì
3.3 Một số hiệu ứng lề
3.4 Những vấn đề về bảo trì hiện nay
3.5 Các kỹ thuật cho bảo trì
3.6 Ma trận các chủ đề bảo trì p/m và tài
liệu tham khảo


3.1 Giới thiệu
3.1.1
3.1.2
3.1.2
3.1.3


Định nghĩa
Tại sao phải bảo trì
Phân loại bảo trì
Chi phí bảo trì


3.1.1 Định nghĩa
• Bảo trì là cơng việc tu sửa, thay đổi phần
mềm đã được phát triển (chương trình, dữ liệu,
các loại tư liệu đặc tả, . . ) theo những lý do nào
đó
• Bảo trì thường khơng bao gồm những thay
đổi chính liên quan tới kiến trúc của hệ
thống.
• Những thay đổi trong hệ thống thường được
cài đặt bằng cách:
– điều chỉnh những thành phần đang tồn tại và
– bổ sung những thành phần mới cho hệ thống.


3.1.2

Tại sao phải bảo trì

• Bảo trì là khơng thể tránh khỏi vì:
– Các yêu cầu hệ thống thay đổi khi hệ thống đang
được xây dựng
=> hệ thống được chuyển giao có thể khơng thoả mãn các
u cầu của nó.


– Hệ thống gắn kết chặt chẽ với môi trường của nó
=> thay đổi mơi trường sẽ thay đổi các u cầu của hệ
thống.

– Các hệ thống phải được bảo trì nếu chúng muốn
là những phần hữu ích trong mơi trường nghiệp
vụ.


3.1.2

Tại sao phải bảo trì

• Bảo trì là cần thiết
– để đảm bảo rằng hệ thống tiếp tục t/mãn các
y/cầu người dùng

• Bảo trì phải được thực hiện để







Sửa các lỗi
Sửa các yêu cầu và các chỗ hổng thiết kế
Cải tiến thiết kế
Tạo các nâng cấp
Giao tiếp với các hệ thống khác

Chuyển đổi chương trình sang nền tảng p/cứng,
p/mềm, … phù hợp


3.1.2

Tại sao phải bảo trì

• Các khía cạnh chính mà bảo trì tập trung là:
– Bảo trì điều khiển tồn bộ các chức năng của hệ
thống hàng ngày
– Bảo trì điều khiển toàn bộ các sửa đổi hệ thống
– Hoàn thiện các chức năng có thể chấp nhận đang
tồn tại
– Ngăn chặn sự thực hiện của hệ thống từ mức
thấp đến các mức có thể được chấp nhận
=> P/mềm phải được cải tiến và bảo trì


3.1.3 Phân loại bảo trì
Chia làm 4 loại:
– Bảo
– Bảo
– Bảo
– Bảo

trì
trì
trì
trì


để tu chỉnh
để thích nghi
để hồn thiện
để phịng ngừa

Bảo trì tu chỉnh và phịng ngừa được xếp vào loại
bảo trì sửa chữa

Bảo trì thích nghi và hồn thiện thuộc loại
nâng cấp


a) Bảo trì để tu chỉnh
• Là bảo trì khắc phục những khiếm khuyết có
trong phần mềm
• Một số ngun nhân điển hình
– Kỹ sư phần mềm và khách hiểu nhầm nhau
– Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình
hoặc khi kiểm thử chưa bao quát hết
– Vấn đề tính năng của phần mềm: khơng đáp ứng
được yêu cầu về bộ nhớ, tệp, . . . thiết kế sai, biên
soạn sai . . .
– Thiếu chuẩn hóa trong phát triển phần mềm

• Các bước thực hiện: dò lại thiết kế để tu sửa


b) Bảo trì để thích nghi
• Là tu chỉnh phần mềm theo thay đổi của mơi

trường bên ngồi nhằm duy trì, thích nghi
và quản lý phần mềm theo vịng đời của nó
• Những ngun nhân chính:
– Thay đổi về phần cứng (ngoại vi, máy chủ,. . )
– Thay đổi về phần mềm (môi trường): đổi OS
– Thay đổi cấu trúc tệp hoặc mở rộng CSDL


c) Bảo trì để hồn thiện
• Là việc tu chỉnh phần mềm theo các yêu cầu
ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý
hơn
• Những ngun nhân chính:
– Mở rộng thêm chức năng mới cho hệ thống
– Cải tiến quản lý kéo theo cải tiến tài liệu vận hành
và trình tự cơng việc
– Thay đổi người dùng hoặc thay đổi thao tác

• Cịn gọi là tái kỹ nghệ (re-engineering), với
mục đích đưa ra một thiết kế của cùng một
chức năng nhưng có chất lượng cao hơn


d) Bảo trì để phịng ngừa
• Mục đích:
– sửa đổi p/m để thích hợp với u cầu thay đổi sẽ
có của người dùng

• Là cơng việc tu chỉnh chương trình có tính đến
tương lai của phần mềm đó sẽ mở rộng và thay đổi

như thế nào

• Thực ra trong khi thiết kế phần mềm đã phải tính
đến tính mở rộng của nó, nên thực tế ít khi ta
gặp bảo trì phòng ngừa nếu như phần mềm
được thiết kế tốt


3.1.3 Chi phí bảo trì
• Chi phí bảo trì thường lớn hơn chi phí xây
dựng gấp từ 2 đến 100 lần phụ thuộc vào
từng ứng dụng:
– Chi phí bảo trì bị ảnh hưởng bởi cả các yếu tố kỹ
thuật và phi kỹ thuật.
– Nếu bảo trì càng nhiều, sẽ càng làm thay đổi cấu
trúc phần mềm và do đó sẽ làm cho việc bảo trì
càng trở lên khó khăn hơn.
– Phần mềm có tuổi thọ càng cao thì cần chi phí
bảo trì càng cao


Phân bổ chi phí bảo trì


Các yếu tố ảnh hưởng đến chi
phí bảo trì
• Sự ổn định của đội dự án: chi phí bảo trì sẽ
giảm nếu nhân viên trong đội dự án không thay đổi.
• Những trách nhiệm đã cam kết: người xây
dựng hệ thống có thể khơng cam kết trách nhiệm

bảo trì cho nên khơng có gì để bắt buộc họ phải thiết
kế lại cho các thay đổi trong tương lai.
• Kỹ năng của nhân viên: nhân viên bảo trì thường
khơng có kinh nghiệm và hiểu biết về miền ứng
dụng của họ bị hạn chế.
• Tuổi thọ và cấu trúc chương trình: khi tuổi thọ
và cấu trúc chương trình bị xuống cấp thì chúng
càng trở lên khó hiểu và thay đổi nhiều.


Dự đốn bảo trì
• Dự đốn bảo trì:
– liên quan tới việc đánh giá những phần nào của
hệ thống có thể gây ra lỗi và cần bao nhiêu chi
phí để bảo trì.

• Khả năng chịu được sự thay đổi
– phụ thuộc vào khả năng bảo trì của các thành
phần bị ảnh hưởng bởi sự thay đổi đó.

• Thực hiện các thay đổi
– có thể làm hỏng hệ thống và giảm khả năng bảo
trì của nó.

• Chi phí bảo trì
– phụ thuộc vào số lượng các thay đổi và
– chi phí thay đổi phụ thuộc vào khả năng bảo trì.


Dự đốn bảo trì

• Có thể dự đốn bảo trì thông qua việc đánh giá độ
phức tạp của các thành phần hệ thống.
• Độ phức tạp của thành phần phụ thuộc vào:
– Độ phức tạp của cấu trúc điều khiển
– Độ phức tạp của cấu trúc dữ liệu
– Kích thước của đối tượng, phương thức và mơ-đun.

• Ngồi ra, ta có thể sử dụng các phép đo quy trình để
đánh giá khả năng bảo trì của hệ thống.





Số lượng các yêu cầu cần bảo trì sửa lỗi.
Thời gian trung bình cần thiết để phân tích ảnh hưởng
Thời gian trung bình để cài đặt một yêu cầu thay đổi.
Số lượng các yêu cầu cần giải quyết.


Dự đoán thay đổi
– Dự đoán số lượng các thay đổi có thể xảy ra và
tìm hiểu mối quan hệ giữa hệ thống và mơi
trường của nó.


Làm thế nào để giảm độ phức tạp bảo trì
• Sử dụng các kỹ thuật kiểm thử tốt hơn trong suốt
q trình phát triển
• Tạo ra các tài liệu tốt hơn, tn theo các chuẩn và

các quy ước
• Dự đốn các thay đổi trong tương lai trong suốt giai
đoạn xác định yêu cầu
– Thiết kế hướng đến sự mở rộng: chi phí bảo trì dịng mã lớn
hơn gấp 20 đến 40 so với giai đoạn xd dịng mã đó

• Thiết kế cấu trúc hệ thống để không ràng buộc với
các thay đổi trong tương lai
• Tách ra các thành phần mà có thể thay đổi trong
tương lai
• Giành sự cố gắng hơn trong q trình thiết kế ban
đầu để có được các yêu cầu đúng của người sử
dụng


Làm thế nào để giảm độ phức tạp bảo trì
• Khi quyết định lựa chọn hoạt động bảo trì hay thay
thế phần mềm, ta cần trả lời các câu hỏi sau:
– Chí phí bảo trì khơng q cao?
– Tính tin cậy của hệ thống có được chấp nhận khơng?
– Hệ thống có khơng mất đi khả năng thích nghi với các thay
đổi trong tương lai với một giản đồ và chi phí hợp lý
– Hệ thống có thực hiện dựa trên các ràng buộc đã mô tả
trước không?
– Các chức năng khơng làm hạn chế tính hữu ích của hệ
thống?
– Khơng thể có các hệ thống khác mà làm cơng việc tương tự
nhanh hơn, tốt hơn và rẻ hơn?
– Chi phí bảo trì phần cứng khơng trở nên đắt đến nỗi mà
phần cứng có thể bị thay thế

=> Nếu tất cả các trả lời đều là Yes thi ta mới nên tiến hành bảo
trì


3.2 Tiến trình bảo trì
3.2.1 Cải thiện phần mềm
3.2.2 Mơ hình tiến trình bảo trì
3.2.3 Các hoạt động bảo trì
3.2.4 Tiến trình bảo trì khẩn cấp


3.2.1 Cải thiện phần mềm
• Để cải thiện hệ thống hiện có, người ta
đã đề xuất 4 chiến lược cơ bản:
– Tách hệ thống và chỉnh sửa các quy trình
nghiệp vụ
– Tiếp tục bảo trì hệ thống
– Biến đổi hệ thống bằng cách tái kỹ nghệ
để nâng cấp khả năng bảo trì của nó.
– Thay thế hệ thống bằng một hệ thống mới


3.2.1 Cải thiện phần mềm
• Việc lựa chọn chiến lược cải tiến hệ thống
phụ thuộc vào chất lượng hệ thống và giá trị
nghiệp vụ của nó như sau:
– Chất lượng thấp và giá trị nghiệp vụ thấp: những
hệ thống này nên được tách ra.
– Chất lượng thấp và giá trị nghiệp vụ cao: những hệ
thống này có giá trị nghiệp vụ cao nhưng chi phí

bảo trì khá lớn. Ta nên tái kỹ nghệ hoặc thay thế
bởi một hệ thống thích hợp
– Chất lượng cao và giá trị nghiệp vụ thấp: thay thế
bằng các thành phần code
– Chất lượng cao và giá trị nghiệp vụ cao: tiếp tục sử
dụng và bảo trì hệ thống theo cách thơng thường.


3.2.1 Cải thiện phần mềm
• Việc đánh giá giá trị nghiệp vụ được thực hiện
từ nhiều khung nhìn khác nhau. Phỏng vấn các
stakeholder khác nhau và đối sánh kết quả thu
được. Các stakeholder thường là:






Người sử dụng cuối
Khách hàng của doanh nghiệp
Người quản lý dây chuyền sản xuất
Người quản lý công nghệ thông tin
Người quản lý cao cấp


3.2.1 Cải thiện phần mềm
• Đánh giá chất lượng hệ thống thơng qua:
– Quy trình nghiệp vụ: quy trình nghiệp vụ
đã hỗ trợ cho các mục tiêu nghiệp vụ như

thế nào?
– Mơi trường hệ thống: mơi trường hệ thống
có hiệu quả như thế nào và chi phí để bảo
trì nó.
– Khả năng ứng dụng: chất lượng của ứng
dụng?


×