Chương 13: Vận hành và bảo trì hệ thống doc

Trang 109
Giáo trình: Phân tích thiết kế hệ thống Giảng viên: Lê Đắc Nhường

G
Chương 13
Vận hành và bảo trì hệ thống

13.1. Tổng quan về vận hành và hỗ trợ hệ thống
Hỗ trợ hệ thống (Systems support) là việc hỗ trợ về mặt kỹ thuật cho người sử dụng cũng
như việc bảo trì để sửa lỗi hoặc đáp ứng những yêu cầu mới xuất hiện.Vận hành hệ thống
(Systems operation) là việc thực thi hàng ngày của một hệ thống thông tin.
Các hoạt động hỗ trợ hệ thống:
 Bảo trì hệ thống (Program maintenance) sửa các lỗi xuất hiện trong quá trình phát
triển hệ thống
 Phục hồi hệ thống (System recovery) là việc phục hồi lại hệ thống và dữ liệu sau
khi xảy ra sự cố
 Hỗ trợ kỹ thuật (Technical support) là bất kỳ sự trợ giúp nào được cung cấp cho
người sử dụng trong trường hợp cần thiết
 Nâng cấp hệ thống (System enhancement) là việc cải thiện hệ thống để xử lý các
vấn đề nghiệp vụ hoặc vấn đề kỹ thuật hay yêu cầu kỹ thuật mới
13.2. Bảo trì hệ thống
Các nguyên nhân gây lỗi:
 Các yêu cầu không được xem xét kỹ
 Các yêu cầu không được truyền đạt chính xác
 Các yêu cầu bị hiểu sai
 Các yêu cầu hoặc bản thiết kế bị cài đặt không chính xác
 Sử dụng sai mục đích chương trình
Các mục tiêu của việc bảo trì hệ thống:

 Tạo các thay đổi được dự đóan trước đối với hệ thống hiện có để hiệu chỉnh lỗi
 Duy trì các bộ phận vẫn hoạt động tốt của chương trình và tránh trường hợp những
thay đổi có thể gây ảnh hưởng bất lợi tới các bộ phận đó
 Tránh nhiều nhất có thể việc làm giảm hiệu suất của hệ thống
 Hoàn thành nhiệm vụ nhanh nhất có thể để tránh việc hy sinh chất lượng và tính tin
cậy của hệ thống
13.2.1. Bước 1 – Xác định vấn đề
Các dự án bảo trì hệ thống nhỏ thường được kích hoạt bởi việc phát hiện ra lỗi. Hầu hết
các lỗi đều được phát hiện bởi người sử dụng khi họ nhận thấy một số bộ phận của hệ thống
hoạt động không chính xác. Nhiệm vụ đầu tiên của người phân tích hệ thống hoặc lập trình



Trang 110
Giáo trình: Phân tích thiết kế hệ thống Giảng viên: Lê Đắc Nhường

G
viên là xác định vấn đề. Nếu đúng là có lỗi thì việc bảo trì phải được thực hiện trên bản sao
của chương trình. Còn chương trình gốc vẫn được sử dụng tới khi sửa xong lỗi.
13.2.2. Bước 2 – Đánh dấu chương trình
Không phải phần nào của chương trình cũng hỏng. Do đó, trước khi thực hiện bất cứ thay
đổi nào đối với chương trình thì cần kiểm thử chương trình để phân định ranh giới giữa phần
chương trình có lỗi cần sửa với phần chương trình có thể xem xét muộn hơn.
13.2.3. Bước 3 – Nghiên cứu và bắt lỗi chương trình
Tri thức về chương trình thì có được từ mã nguồn. Để có thể hiểu được chương trình thì
cần không ít thời gian. Hoạt động này có thể bị chậm trễ do một số hạn chế có thể có sau:
 Cấu trúc chương trình tồi
 Lôgíc không có cấu trúc
 Những hoạt động bảo trì không tốt trước đó (chẳng hạn như việc sửa đổi nhanh
chóng và phần mở rộng được thiết kế tồi)

 Mã chết (là những câu lệnh không thể thực hiện được – thường bị bỏ qua trong các
lần kiểm thử và bắt lỗi trước đây)
 Tài liệu không tốt hoặc không đầy đủ
13.2.4. Kiểm thử chương trình
Một phiên bản đề cử của chương trình phải được kiểm thử trước khi được đưa vào vận
hành. Dưới đây là những bước kiểm thử cần thiết hoặc tùy chọn:
 Kiểm thử bộ phận (Unit testing) cần thiết để đảm bảo rằng một chương trình độc
lập đã được sửa lỗi mà không gây ảnh hưởng ngoài dự đoán tới chương trình.
 Kiểm thử hệ thống (System testing) cần thiết để đảm bảo rằng toàn bộ ứng dụng
(trong đó chương trình đã được sửa chữa và kiểm thử là một phần) vẫn hoạt động
tốt trên phạm vi toàn hệ thống.
 Kiểm thử hồi quy (Regression testing) ngoại suy ảnh hưởng của các thay đổi tới
hiệu suất hệ thống (thông lượng và thời gian đáp ứng) bằng cách phân tích hiệu
suất trước và sau khi thực hiện thay đổi.
Kiểm soát phiên bản hay kiểm soát cấu hình (Version control/ Configuration Control) là
quá trình trong đó ta theo dõi những thay đổi đã có đối với chương trình để làm thuận tiện
việc tìm hiểu chương trình về sau.
13.3. Phục hồi hệ thống
Sự cố hệ thống là điều không thể tránh khỏi. Người phân tích hệ thống thường sửa lỗi hệ
thống hoặc haọt động như một cầu nối giữa người sử dụng và người có trách nhiệm sửa lỗi.
Các hoạt động phục hồi hệ thống có thể tóm tắt như sau:
Trong nhiều trường hợp, người phân tích hệ thống có thể ngồi tại máy tính của người
dùng để phục hồi hệ thống. Họ có thể cần phải cung cấp các chỉ dẫn để hiệu chỉnh cho người
dùng để tránh lặp lại sự cố.
Trong một số trường hợp, người phân tích phải liên hệ với nhân lực vận hành hệ thống để
sửa lỗi. Điều này thường cần thiết khi hệ thống có sử dụng máy chủ. Thường thì người quản



Trang 111

Giáo trình: Phân tích thiết kế hệ thống Giảng viên: Lê Đắc Nhường

G
trị mạng hoặc quản trị viên cơ sở dữ liệu hay người quản trị web sẽ xem xét các vấn đề của
máy chủ.
Trong một số trường hợp, người phân tích có thể cần phải nhờ người quản trị dữ liệu
phục hồi các tệp dữ liệu hoặc cơ sở dữ liệu đã mất hoặc bị hỏng. Khi phục hồi dữ liệu nghiệp
vụ thì không chỉ cần khôi phục cơ sở dữ liệu.
 Bất cứ giao dịch nào xuất hiện trong khoảng thời gian kể từ lần sao lưu cuối cùng
tới lúc phục hồi dữ liệu đều phải được xử lý lại.
 Nếu sự cố xảy ra trong khi diễn ra một giao dịch và giao dịch đó đã được hoàn
thành một phần thì bất cứ việc cập nhật giao dịch nào diễn ra trước sự cố đều phải
được hủy bỏ trước khi xử lý lại toàn bộ giao dịch.
Trong một số trường hợp, người phân tích có thể phải nhờ người quản trị mạng sửa một
lỗi trên mạng cục bộ hay mạng diện rộng.
Trong một số trường hợp, người phân tích có thể phải nhờ chuyên viên kỹ thuật giải quyết
các vấn đề nảy sinh về phần cứng.
Trong một số trường hợp, người phân tích sẽ phát hiện được lỗi phần mềm có thể gây ra
sự cố. Họ sẽ cố gắng cô lập lỗi nhanh chóng để nó không thể gây ra sự cố khác. Tiếp theo là
việc xử lý lỗi.
13.4. Hỗ trợ kỹ thuật
Một hoạt động thường xuyên khác trong giai đoạn hỗ trợ hệ thống đó là hỗ trợ kỹ thuật.
Cho dù người dùng có được đào tạo tốt như thế nào hay các tài liệu được viết kỹ thế nào thì
người dùng vẫn cần có sự trợ giúp. Người phân tích hệ thống thường sẵn sàng đợi yêu cầu
của người dùng. Những công việc thường phải làm là:
 Đều đặn theo dõi việc sử dụng hệ thống
 Theo dõi kết quả thăm dò mức độ hài lòng của người dùng và gặp gỡ họ
 Thay đổi thủ tục nghiệp vụ cho phù hợp với hoạt động của hệ thống phần mềm
 Cung cấp thêm các hoạt động đào tạo người dùng
 Lưu lại các yêu cầu và ý tưởng về việc nâng cấp hệ thống

13.5. Nâng cấp hệ thống
13.5.1. Động lực của việc nâng cấp hệ thống
Hầu hết các hoạt động nâng cấp hệ thống đều xuất phát từ việc đáp ứng các sự kiện sau:
 Các vấn đề về nghiệp vụ mới phát sinh: một vấn đề nghiệp vụ mới nảy sinh khiến
cho một phần của hệ thống hiện tại trở nên không đáp ứng được hoặc sử dụng hệ
thống không hiệu quả.
 Các yêu cầu nghiệp vụ mới xuất hiện: một yêu cầu nghiệp vụ mới (ví dụ loại báo
cáo hay giao dịch hoặc chính sách mới) cần có để duy trì giá trị sử dụng của hệ
thống hiện tại.
 Các yêu cầu công nghệ mới xuất hiện: một quyết định về việc sử dụng một công
nghệ mới (bao gồm cả việc nâng cấp phần cứng và phần mềm) trong hệ thống
hiện có cần được thực hiện.



Trang 112
Giáo trình: Phân tích thiết kế hệ thống Giảng viên: Lê Đắc Nhường

G
 Các yêu cầu thiết kế mới: một phần tử của hệ thống hiện có cần được thiết kế lại
(ví dụ thêm bảng hoặc trường vào cơ sở dữ liệu, thay đổi giao diện người dùng…)
13.5.2. Bước 1 – Phân tích yêu cầu nâng cấp
Bước này nhằm xác định các hoạt động cần thực hiện để đáp ứng yêu cầu nâng cấp của
hệ thống. Nhiệm vụ đầu tiên là phân tích một yêu cầu trong mối tương quan với các yêu cầu
thay đổi nổi bật khác để xác đinh thứ tự ưu tiên.
Nếu cần phải thay đổi ngay lập tức thì yêu cầu được chọn cần phải được định hướng giải
pháp tùy theo loại thay đổi cần thực hiện:
 Các vấn đề nghiệp vụ mới cần được hướng tới phiên bản thu nhỏ của giai đoạn
phân tích vấn đề. Từ đó, việc nâng cấp sẽ được định hướng thông qua các phiên
bản thu nhỏ tương ứng của các giai đoạn phân tích yêu cầu, phân tích quyết định,

thiết kế,xây dựng và triển khai.
 Các yêu cầu nghiệp vụ mới cần được hướng tới các phiên bản thu nhỏ của các giai
đoạn phân tích yêu cầu, phân tích quyết định, thiết kế, xây dựng và triển khai.
 Các yêu cầu kỹ thuật mới cần được hướng tới giai đoạn phân tích quyết định trước
khi diễn ra giai đoạn thiết kế, xây dựng và triển khai. Việc phân tích quyết định sẽ
xác định xem liệu công nghệ được đề xuất có khả thi trong hệ thống mới hay
không. Điều này đặc biệt quan trọng bởi việc thay đổi công nghệ có thể tốn kém và
phức tạp.
 Các yêu cầu thiết kế mới phải được định hướng tới ngay trong giai đoạn thiết kế,
xây dựng và triển khai.
13.5.3. Bước 2 – Thực hiện sửa chữa nhanh
Một số kiểu nâng cấp hệ thống có thể được thực hiện nhanh chóng bằng cách viết những
chương trình đơn giản mới hoặc thựuc hiện các thay đổi đơn giản đối với các chương trình
đang có. Các chương trình và thay đổi đơn giản có thể được thực hiện mà không cần phải tái
cấu trúc dữ liệu (tức là thay đổi cấu trúc cơ sở dữ liệu), không phải cập nhật dữ liệu hay nhập
dữ liệu mới. Nói một cách khác, các chương trình đó sinh ra các báo các và đầu ra mới.
13.5.4. Bước 3 – Phục hồi hệ thống vật lý hiện có
Đôi khi xảy ra việc hệ thống được nâng cấp nhưng tài liệu về nó lại không được cập nhật.
Và có trường hợp các hệ thống được phát triển không theo quy trình nghiêm ngặt nào. Khi
đó, người phân tích có thể được yêu cầu phục hồi cấu trúc vật lý hiện có của một hệ thống để
làm cơ sở cho việc nâng cấp hệ thống về sau.