Giáo trình Phân tích thiết kế hệ thống thông tin

c 3. Vẽ lược đồ chương trình ở hai mức cao nhất
Mức 1: Một module chính
Mức 2: Gồm 2 module, một module cho đầu vào giao tác và một module cho xử lý giao tác.
Bước 4. Triển khai các module mức 2 xuống mức thấp hơn, mỗi xử lý một module và được module xử lý giao tác gọi qua phép chọn. Khi khai triển cần phát hiện các module dùng chung
Chính
Vào
Xử lý giao tác
E
x3
y2
s1
s2
H
Ra1
y2
x3
q1
q1
q2
q3
Vào
A
B
C
x1
y1
x1
x2
y2
y1
x3
x2
Giao diện
Giao diện
XL1
XL2
XL3
G
K
Ra2
y2
x3
s1
s1
s2
s3
F
Ra3
y2
x3
r1
r2
Giao diện
Giao diện
y2
x3
x3
y2
5.4. THIẾT KẾ CÁC MẪU THỬ
Mẫu thử có thể được phát sinh ngẫu nhiên hoặc không ngẫu nhiên, tự động hoặc không tự động.
Cách thử chương trình bằng mẫu thử:
Thử tính đúng đắn
So kết quả thu được với kết quả chờ đợi
Nếu trong quá trình thử phức tạp, yêu cầu chương trình in các giá trị trung gian
Kiểm tra giá trị trung gian
Kiểm tra vệt chương trình
Thử hiệu năng: các mẫu thử phải đủ lớn và có thể thử nghiệm trong một thời gian dài.
CHƯƠNG 6 – LẬP TRÌNH CHẠY THỬ VÀ BẢO TRÌ
BÀI 1. LẬP TRÌNH, GHÉP NỐI CÁC CHƯƠNG TRÌNH
6.1. TỔ CHỨC LẬP TRÌNH VÀ GHÉP NỐI HỆ THỐNG
6.1.1. Các công việc chuẩn bị trước khi tiến hành lập trình
Trước khi bắt tay vào giai đoạn lập trình, các chuyên gia quản lý dự án phải trả lời các câu hỏi sau:
Kết quả rà xét lại thiết kế có yêu cầu phải làm lại một phần nào đó trong hệ thống không? Nếu có, phải sắp xếp thời gian một cách phù hợp và không nên bắt đầu lập trình khi chưa giải quyết ổn thoả mọi chuyện.
Các nguồn nhân lực, vật lực và thông tin, cũng như là các lập trình viên lúc nào cũng sẵn sàng và dự an sẽ kết thúc đúng theo kỳ hạn. Khi có thay đổi nhân sự vì bất cứ lý do gì, cần phải lượng trình năng suất công việc của người mới đến thay thế để có thể trù liệu trước mọi chuyện đáp ứng được hạn định đã đặt ra. Bởi lẽ trong các công ty với các điều kiện làm việc như nhau, một chuyên gia lập trình giỏi có thể làm việc với năng suất gấp 8 lần người có trình độ trung bình.
Mọi người đã được đào tạo chưa? Chẳng hạn, khi bắt tay vào công việc, các lập trình viên phải biết rõ về hệ điều hành, ngôn ngữ lập trình và các công cụ lập trình sẽ được sử dụng. Họ còn phải làm quen với ứng dụng mà người sử dụng đặt hàng cũng như bài toán cần giải quyết. Một điều quan trọng là phải cung cấp tài liệu đầy đủ đề các lập trình viên biết rõ về tài liệu yêu cầu và đặt tả chức năng.
Mô trường lập trình dành cho các thành viên trong dự án đó được chuẩn bị tốt, đáp ứng các yêu cầu của công việc không? Kinh nghiệm triển khai thực tiễn đã chứng tỏ rằng nên chọn những phần mềm và công cụ lập trình dễ sử dụng. Các máy tính dùng để phát triển công việc của dự án phải đáp ứng được yêu cầu: trả lời nhanh (tốc độ cao), dung lượng bộ nhớ đủ lớn, có độ tin cậy cao và cung cấp đủ khi cần thiết. Một điểm quan trọng khác là phải đảm bảo các thiết bị vẫn đang được nhà sản xuất bảo hành, các tài liệu về phần mềm phát triển vẫn đang được cập nhật thường xuyên. Trong thời gian thực hiện dự án phải luôn đảm bảo hệ thống không bị gián đoạn.
6.1.2. Các bước lập trình, ghép nối và chạy thử
Bước 1. Đặt kế hoạch tích hợp và kiểm thử hệ thống:
Kinh nghiệm xây dựng các hệ tin học cỡ lớn chỉ ra rằng không nên và không thể xây dựng một chương trình giải quyết được tất cả mọi việc. Trong những trường hợp như vậy, cách làm phân chia hệ thống thành các module nhỏ hơn thường tỏ ra hợp lý. Sau đó người ta tiến hành ráp nối các module một cách nhịp nhàng. Các nhà quản lý dự án phải đặt kế hoạch một cách rõ ràng, đưa ra thứ tự ghép nối các module sẽ được lập trình theo thứ tự tích hợp vào hệ thống. Kế hoạch này được gọi là kế hoạch kiểm thử hệ thống.
Các bước sau đây (bước 2 ¸ bước 9) chỉ liên quan tới một module của hệ thống mà thôi.
Bước 2. Thiết kế các module
Ở bước này, các lập trình viên nhận bản đặc tả thiết kế được bàn giao lại từ giai đoạn thiết kế (do kết quả của việc thiết kế mức tổng thể và mức trung gian). Công việc ở đây là tiếp tục chia nhỏ thành các mức thấp hơn cho đến khi đạt tới các công việc “sơ cấp” theo nghĩa có thể lập trình được ngay bằng một ngôn ngữ lập trình nào đó. Quá trình này được gọi là quá trình thiết kế các module hay thiết kế mức dưới.
Câu hỏi đặt ra. Quá trình thiết kế hệ thống sẽ dừng lại ở mức chi tiết như thế nào và khi nào bắt tay vào thiết kế chi tiết từng module?
Câu trả lời. Quá trình thiết kế hệ thống nhằm chia nhỏ các module tới mức người lập trình có thể bắt đầu công việc của mình nghĩa là các đặc tả về dữ liệu và theo tác đủ rõ ràng và tường minh để có thể mã hoá thông qua một ngôn ngữ lập trình nào đó. Hơn nữa, mức độ chi tiết hoá tuỳ thuộc vào từng dự án một hay từng phần trong hệ thống, thậm chí cả quan niệm của người lập trình đảm nhận phần việc được giao.
Cần phải xem xét các yếu tố như:
Nếu chia nhỏ các module là yêu cầu cấp thiết nhằm đáp ứng các đặc tính có độ ưu tiên cao như thời gian trả lời, giao diện hệ thống thân thiện cũng như tính tương hợp trong quá trình xử lý, thì người thiết kế có thể làm tới mức chi tiết sâu hơn.
Mức độ chi tiết trong thiết kế có thể được ghi lại trong hợp đồng. Các dự án tầm cỡ cơ quan chính phủ, các Bộ, Ngành thường quy định rõ số mức thiết kế cần phải tuân thủ.
Nếu lập trình viên không tham gia trong quá trình thiết kế, nên giả định là các thiết kế đó nhằm phục vụ cho các lập trình viên ở trình độ trung bình tức là làm rõ các chi tiết tới mức một lập trình viên hạng trung có thể hiểu và cài đặt được theo ý đồ thiết kế.
Chú ý: Cần phải nhấn mạnh rằng các lập trình viên thường không thích nhận được bản thiết kế quá chi tiêts tới mức lập trình chỉ còn là phát biểu lại hay dịch các mệnh đề tiếng Anh sang một ngôn ngữ lập trình nào đó.
Bước 3: Rà soát thiết kế module
Cũng như đối với các thiết kế ở mức trên và mức giữa, cần phải cân nhắc các điểm lợi/hại khi tiến hành thiết kế ở các mức dưới. Do vậy cần phải rà soát lại thiết kế của từng module trước khi lập trình. Công việc này nên tổ chhức gọn nhẹ. Chỉ cần bản thên lập trình viên, người phụ trách trực tiếp và có thể là một lập trình viên cùng tham dự. Mục đích của việc rà soát lại thiết kế module là đảm bảo rằng đưa ra được một thiết kế tốt nhất có thể có được sao cho mọi chức năng đã được đề cập đến và tất cả mọi trục trặc đã được lường trước.
Bước 4: Đặt kế hoạch kiểm thử module
Lập trình viên phải lập kế hoạch kiểm thử module và dữ liệu trước khi bắt tay vào lập trình. Kế hoạch kiểm thử sau khi lập trình phải được xem xét. Trong kế hoạch này chỉ cần tập trung vào những "kiểm thử" đối với các phần khó nhất trong hệ thống. Người phụ trách dự án có thể tham gia rà soát kế hoạch kiểm thử cùng với rà soát thiết kế module. Theo kinh nghiệm, nên kết hợp 2 khâu này cùng một lúc.
Bước 5: Lập trình các module
Các tiêu chuẩn, các đòi hỏi đối với quá trình lập trình đã được trình bầy rõ trong giai đoạn thiết kế hệ thống (xem phần tài liệu kỹ thuật).
Các cách tiếp cận khác nhau trong triển khai lập trình:
Cách tiếp cận cấu trúc
Cách tiếp cận hướng đối tượng
Các tư tưởng lớn trong lập trình có cấu trúc là:
Phân chia các công việc thành các module nhỏ. Mỗi module đảm nhận 1 chức năng riêng biệt nào đó, khoảng 100dòng mã lệnh thực hiện (không quá 2 trang văn bản chương trình).
Chỉ có một tham số vào, một tham số ra
Càng ít biến tổng thể càng tốt
Các lệnh cầu trúc được dùng là: tuần tự, if... then... else, case..., while... do..., repeat...until..., call....Tránh dùng lệnh go to.
Bước 6: Kiểm thử module:
Lập trình viên tiến hành kiểm thử module sau khi chọn một phạm vi bài toán phù hợp với cùng một số liệu thử - thông tin vào sao cho quá trình thực hiện phải đi qua các nhánh xử lý chính trong module và quan sát kết quả nhận được.
Kinh nghiệm thực tế cho thấy nên tổ chức kiểm thử module theo giai đoạn. Giai đoạn 1 gọi là kiểm thử "hộp trắng" theo nghĩa người lập trình biết rõ cái gì diễn ra bên trong module và đưa ra các dữ liệu kiểm thhử đi qua tất cả các nhành lôgic trong chương trình. Giai đoạn 2 là kiểm thử "hộp đen”. Người lập trình bỏ qua mà không cần biết nội bộ của module, các dữ liệu kiểm thử được đưa ra theo trình tự và tần xuất như trong sử dụng thực tế.
Ở giai đoạn này, cần phải chú ý và tránh được những lỗi đơn giản nhất (chẳng hạn lỗi gõ sai phím, lỗi sử dụng chuột,...).
Bước 7: Kiểm thử các mức tích hợp thấp nhất:
Nếu như một module nào đó gọi tới một vài module khác, thì lập trình viên có thể tích hợp chúng lại ngay sau khi đã hoàn tất công việc với từng module và tiến hành kiểm thử tất cả các module khi chúng phối hợp làm việc với nhau. Ngay cả khi lập trình viên không phải là người viết các module con này, anh ta vẫn phải kiểm thử các lỗi gọi tới chúng và kết quả trả lại. Cách tốt nhất để làm là tạo ra các "cuống chương trình" (program stub) thay cho việc sử dụng thực tế module này. Một cuống chương trình chỉ gồm 4 dòng lệnh, nhằm mô tả đã nhận được tín hiệu điều khiển từ chương trình mẹ, đưa ra các tham số nhận được, và chuyền điều khiển lên mưc trên cùng với một số tham số ra (nếu cần thiết).
Bước 8: Lưu giữ các kết quả kiểm thử. Đệ trình các module đã hoàn tất để tích hợp
Các kết quả kiểm thử module còn được dùng về sau để xây dựng các thống kê về lỗi, nguyên nhân và chi phí để sửa. Người phụ trách dự án phải chịu trách nhiệm tích hợp các module khi các hệ thống thông tin cần xây dựng thuộc loại cỡ nhỏ và trung bình. Để trợ giúp công việc quản lý, có thể sử dụng phần mềm quản lý mã chương trình (Code Management System) nhằm quản lý cấu hình, lưu giữ các thông tin về các phiên bản, những thay đổi lên mã chương trình nguồn (có thể xem phần nói về các công cụ trợ giúp công nghệ phần mềm – Computer Aided Software Engineering (CASE).
Bước 9: Bắt tay vào soạn thảo tài liệu cho người sử dụng
Có thể tổ chức biên soạn các tài liệu cho người sử dụng ngay sau khi hoàn tất kiểm thử module, độc lập với chuyện lập trình viên có tham gia trực tiếp trong nhóm biên soạn hay không.
6.2. CÁC CÔNG CỤ TRỢ GIÚP LẬP TRÌNH VÀ CÀI ĐẶT
Các công cụ trợ giúp lập trình (Programing CASE Tools) nhằm trợ giúp các lập trình viên tự động hoá trong một chừng mực nào đó các công đoạn trong quá trình lập trình.
a. Ngôn ngữ lập trình: 
Các ngôn ngữ lập trình và chương trình dịch đóng một vai trò rất quan trọng. Nếu các thành phần này khá đơn giản, hoàn toàn thích hợp với các ứng dụng, lập trình viên có thể học rất nhanh, sử dụng thành thạo các cấu trúc lệnh và lập trình mà không cần tốn quá nhiều công sức. Hơn nữa, các chương trình dịch làm việc khá nhanh, các thông báo lỗi đầy đủ và rõ ràng.
Ngoài ra các chương trình dịch còn phải đảm bảo các trình tiện ích sau:
b. Bộ soạn thảo 
Đưa ra những dạng mẫu đối với các câu lệnh, người sử dụng chỉ cần điền thêm các biến.
Chẳng hạn, để trợ giúp lập trình bằng PASCAL, hệ soạn thảo đưa ra khuôn dạng sau:
FOR % {biến - điều khiển}% : = % {bthức} % {TO/DOWN TO}% % {bthức} % 
DO % {câu lệnh} %
END;
Người sử dụng chỉ cần điền vào các biến, các biểu thức và câu lệnh dưới sự trợ giúp của bộ soạn thảo. Bộ soạn thảo có thể gọi tới chương trình dịch. Nếu có lỗi khi dịch, bộ soạn thảo sẽ quay trở lại cùng với thông báo lỗi tại dòng mã chương trình nguồn đã gây ra lỗi.
c. Bỗ gỡ lỗi 
Nhằm giúp người lập trình phát hiện và sửa lỗi nhờ các can thiệp sâu vào quá trình thực hiện chương trình: dừng quá trình thực hiện, dõi vết và thực hiện từng bước các dòng lệnh. Các chương trình gỡ lỗi hiệu quả còn cho phép tạo và hiển thị giá trị các biến ở bất kỳ một thời điểm nào.
d. Hệ quản lý mã chương trình nguồn (Code Management System) viết tắt là QLCT
Hệ quản lý mã chương trình nguồn đôi lúc còn được gọi là hệ quản lý cấu hình (Configuration Manager). Hệ quản lý dạng này có ý nghĩa to lớn trong quá trình lập trình, nó lưu giữ tất cả các nguồn thông tin về chương trình: ai cập nhật gì và những đụng độ khi có 2 người muốn cập nhật cùng một module nào đó. Hệ QLCT còn cung cấp các công cụ để lưu giữ các thay đổi lên các module, phục hồi các phiên bản của nó.
Hệ QLCT có thể xử lý các tệp ASCII, do đó nó không chỉ hiệu quả khi dõi viết các chương trình nguồn, mà còn dùng để lưu trữ các tệp tư liệu, các tệp dữ liệu kiểm thử ở dạng văn bản cũng như các tệp tạo dựng hệ thống. Chẳng hạn tại hãng sản xuất phần cứng, phần mềm DEC thường có 20-30 phiên bản hệ điều hành, mỗi hệ khác nhau một chút tuỳ thuộc vào hàng trăm những hoán đổi hay kết hợp các điểm mạnh về phần cứng và phần mềm. Thực tiễn chứng tỏ rằng các hệ QLCT đặc biệt cần thiết khi dõi vết tất cả các phiên bản của hệ thống chương trình.
e. Hệ quản lý các module (Module Management System), viết tắt là QLMĐ
Hệ quản lý các module thường được để tự động hoá quá trình dịch và kết nối, hay xây dựng hệ thống. Nó cho phép xây dựng lại những phần bị thay đổi tính từ lần đầu xây dựng gần nhất. Hệ QLMĐ còn dùng để chạy tự động một tệp các dữ liệu kiểm thử. Có thể thấy rằng hệ QLMĐ còn dùng để chạy tự động một tệp các phiên bản của hệ thống: ráp nối các chương trình nguồn, ảnh và tất cả những tư liệu trong một phiên bản. Hệ QLMĐ có thể làm việc phối hợp với hệ QLCT (toàn bộ các chương trình nguồn, tệp văn bản và tệp câu lệnh cần chạy hệ QLMĐ có thể lưu trữ lại).
f. Hệ quản lý các kiểm thử (Test Manager) viết tắt của QLKT
Hệ loại này được dùng để tự động hoá việc kiểm thử hệ thống. Để sử dụng hiệu quả hệ QLKT, phải xác định tệp các kiểm thử cần chạy cùng với các thông tin ra mong muốn. Hệ QLKT sẽ chạy với các dữ liệu kiểm thử và thông báo cho lập trình viên nếu kết quả khác với kết quả mong muốn.
BÀI 2. LẬP CÁC TÀI LIỆU HƯỚNG DẪN SỬ DỤNG
6.1. TÀI LIỆU HƯỚNG DẪN SỬ DỤNG
Tài liệu này có thể do người lập trình, hay một chuyên viên kỹ thuật, thậm chí là người sử dụng biên soạn. Cần phải nhắc lại là các đặc tả chức năng trong giai đoạn phân tích, thiết kế đã phải có những mô tả chi tiết về các thực đơn, bố trí màn hình, các trình bày và những giao diện khác. Trong tài liệu này không nên trình bày dông dài. Để có một tài liệu hướng dẫn sử dụng tốt, nên chia thành các phần phù hợp với từng đối tượng người sử dụng có chuyên môn khác nhau. Tài liệu phải trình bày theo trình tự người sử dụng sẽ vận hành, khai thác hệ thống, bởi lẽ nó sẽ thuận tiện cho người sử dụng làm việc với hệ. Một thứ tự trình bày hay được sử dụng trong các tài liệu là thứ tự logic các chức năng trong cây thực đơn câu lệnh từ trên xuống dưới, từ trái sang phải.
Ở cuối tài liệu nên có phần tra cứu nhanh các lệnh, các thực đơn, và các thông báo theo thứ tự từ điển.
6.2. TÀI LIỆU HƯỚNG DẪN BẢO TRÌ 
Một trong những yêu cầu cơ bản đối với công việc quản lý trong giai đoạn này là tổ chức để các lập trình viên biên soạn tài liệu chi tiết về chương trình để bảo trì hệ thống về sau. Phần lớn các chuyên gia quản lý dự án cho rằng tổ chức soạn thảo tài liệu hướng dẫn bảo trì không phải là công việc đơn giản. Bởi lẽ các lập trình viên thường không thích biên soạn tài liệu về chương trình, tốt nhất để họ viết sau khi mọi chuyện đã hoàn tất. Vả lại, các lập trình viên thường nghĩ rằng người bảo trì hệ thống lại đòi hỏi giải thích quá chi tiết về logic chương trình, nên xem rằng đây là công việc buồn tẻ và hoàn toàn không cần thiết. Thật là khó trong những tình huống như vậy.
Một giải pháp đơn giản là có thể dùng đặc tả thiết kế ở mức module chi tiết và đầy đủ cùng với bản mã chương trình nguồn có chú giải đầy đủ khi bảo trì hệ thống. Do vậy, tài liệu hướng dẫn bảo trì hệ thống phải gộp cẩ phần đặc tả thiết kế, listing chương trình và giải thích cách ghép nối, xử lý các thay đổi áp lên chương trình cũng như kết quả kiểm thử các module.
6.3. TÀI LIỆU KHAI THÁC VÀ QUẢN LÝ HỆ THỐNG
Tài liệu này giống như tài liệu hướng dẫn sử dụng, nhưng đây dành cho các nhân viên chịu trách nhiệm bật máy, sao lưu và xử lý các sự cố chủ yếu, lập các thống kê. Thường là các tài liệu cho các hãng sản xuất phần cứng và hệ điều hành đã khá đầy đủ, nên chỉ những thủ tục cần thiết để thích nghi phần mềm với từng nhu cầu cụ thể mới phải liệt kê ra.
6.4. TÀI LIỆU ĐÀO TẠO 
Nếu phải tổ chức khoá học về khai thác, sử dụng hệ thống, phải trù tính xem dạng tài liệu đào tạo nào cần phải biên soạn. Tài liệu hướng dẫn sử dụng nếu được biên soạn kỹ càng có thể dùng làm cơ sở cho tài liệu học. Tuy vậy, để việc đào tạo có hiệu quả, cần phải tạo ra những công cụ trợ giúp khác như các bản chiếu, các bài tập soạn sẵn,...
Vấn đề bản quyền: Cần phải chỉ rõ trên sản phẩm và các tài liệu cung cấp cho người sử dụng bản quyền của sản phẩm.
BÀI 3. KHAI THÁC VÀ BẢO TRÌ HỆ THỐNG
Nhiệm vụ chủ yếu của giai đoạn này là bảo hành trong thời kì mà tổ dự án phải giải quyết tất cả các vấn đề này sinh trong hệ thống. Một việc khá quan trọng nữa là tổ chức cuộc họp tổng kết dự án để rút kinh nghiệm, khắc phục những sai sót phạm phải trong dự án.
Các điểm mốc quan trọng ở đây là đưa ra hệ thống tác nghiệp đầy đủ và tiếp tục triển khai dự án ở giai đoạn sau.
Trong nhiều trường hợp, người sử dụng vận hành hệ thống chỉ để phát hiện những điểm lạ trong hệ thống. Họ không thể kiểm thử được moi jviệc nên có thể vẫn còn lỗi.
6.1. DỊCH VỤ BẢO HÀNH
Bảo hành có nghĩa là nhóm dự án phải giải quyết mọi vấn đề nảy sinh do lỗi của các lập trình viên, miễn phí trong một thời khoảng đã quy định. Thông thường thời hạn này là 6 tháng, cho đến 1 năm. Có thể tiến hành bảo hành theo một trong 3 cách sau:
Cử một bộ phận thường trực ở chỗ của người sử dụng để trực tiếp giải quyết mọi vấn đề nảy sinh. Người này nên là cán bộ phụ trách dự án hoặc người có kinh nghiệm lâu năm, có thể hiểu được mọi ngõ ngách của hệ thống, hoặc
Cử một ai có thể trao đổi bằng một cách nào đó về một vấn đề nảy sinh trong hệ thống qua điện thoại. Kinh nghiệm cho thấy nên để cả nhóm dự án, đồng tác giả của sản phẩm biết chuyện này.
Có ai đó có thể giải quyết trực tiếp mọi vấn đề có liên quan ngay sau khi nhận được điện thoại. Trong trường hợp này, dù ai đứng ra giải quyết cũng nên để cả nhóm tác giả của sản phẩm biết chuyện này.
Trong một số trường hợp, tuỳ thuộc vào những điều kiện cụ thể, có thể kết hợp các cách này với nhau. Tuy vậy, nói chung không thể bố trí một ai đó túc trực trong 2-4 tuần tại nơi giao nhận sản phẩm sau khi bàn giao. Về tiết kiệm thời gian và nâng cao hiệu quả, nên kết hợp đào tạo người sử dụng trong giai đoạn này. Hai tháng tiếp sau đó phải luôn đảm bảo lúc nào cũng có người trao đổi vấn đề qua điện thoại các vấn đề chuyên môn có liên quan, ba tháng tiếp theo phải bố trí người để có thể giải quyết vấn đề qua điện thoại theo các vấn đề chuyên môn có liên quan, ba tháng tiếp theo phải bố trí người để có thể giải quyết vấn đề nảy sinh ngay 4 tiếng sau khi nhận được thông báo qua điện thoại.
Cần chú ý rằng trong mọi trường hợp, các hạng mục bảo hành chỉ đảm bảo rằng sẽ có người tiếp nhận vấn đề, chứ không được nói rõ sau bao lâu mọi vấn đề sẽ được giải quyết.
Các hãng sản xuất phần cứng, phần mềm như hãng DEC thường bảo hành theo cách sau: Khi có một vấn đề nào đó nảy sinh và có người gọi điện đến, hãng hứa là sẽ cử một kỹ thuật viên đến ngày đó, chẳng hạn sau vài giờ. Nếu nhân viên này không giải quyết được sau 8 giờ, thì hãng cử một nhân viên khác và cứ như vậy tiếp tục cho đến khi nhóm tác giả sản phẩm được điều đến.
6.2. BẢO TRÌ HỆ THỐNG
Khi vận hành hệ thống, người sử dụng luôn có nhu cầu thay đổi hệ thống để nâng cao chất lượng hoạt động, đưa thêm vào nhiều tính năng mới hay chỉnh sửa những tồn tại sau thời hạn bảo hành đã kết thúc. Phần lớn các trường hợp là do công việc của người sử dụng thay đổi làm cho những yêu cầu của họ cũng thay đổi theo. Trong một số phương pháp, người ta gộp việc bảo trì hệ thống vào trong các quá trình phát triển. Việc bảo trì sẽ tiếp tục trong một thời gian đầu. Theo thống kê của NASA và DEC chi phí bảo trì thường gấp bảy lần các chi phí xây dựng hệ thống ban đầu. Để kết thúc dự án một cách tốt đẹp, việc bảo trì hệ thống nên được xem như phần tách rời, sau khi thời hạn bảo hành kết thúc.
TÀI LIỆU THAM KHẢO
Nguyễn Văn Ba, 2006, Phân tích và thiết kế hệ thống thông tin, Nhà xuất bản Đại học Quốc gia, Hà Nội.
Smart C., Sim R., 1990, Phân tích, thiết kế và Cài đặt Hệ thống thông tin quản lý, Viện Tin học, Hà nội.
MỤC LỤC