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. . 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. 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. 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