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

Giáo trình phân tích và thiết kế một hệ thống thông tin
Lời nói đầu
Trong thời kỳ của công nghệ thông tin hiện nay, máy tính đã tham gia hỗ trợ hầu hết các hoạt động của con người như nghiên cứu khoa học, kinh doanh, quản lýĐể ứng dụng công nghệ thông tin cho việc xây dựng các hệ thống thông quản lý đòi hỏi phải có qui trình, phương pháp để áp dụng. Chính vì vậy một trong những yêu cầu quan trọng của những người làm tin học là phải có tri thức về phân tích thiết kế hệ thống mới có thể và phát triển được các ứng dụng tin học có tính khả thi.
Giáo trình này đề cập đến việc phân tích và thiết kế một hệ thống thông tin, trong đó nhấn mạnh tới hệ thống thông tin quản lý. Cuốn sách được giảng dạy ở bậc Cao đẳng, Đại học chuyên ngành Công nghệ thông tin. Sinh viên đã học qua một số ngôn ngữ và phương pháp lập trình trước khi học môn học này.
Hệ thống thông tin nào cũng có một vòng đời, từ lúc khai sinh đến khi lúc bị loại bỏ. Đó là một quá trình gồm một số giai đoạn nhất định. Các giai đoạn chính trong vòng đời của Hệ thống thông tin thường là: khảo sát nhu cầu, phân tích, thiết kế, cài đặt, khai thác và bảo dưỡng. Vì vậy vòng đời của Hệ thống thông tin thường được gọi là chu trình sống hay chu trình phát triển.
Giáo trình này chọn phương pháp phân tích và thiết kế theo hướng cấu trúc, vì các lẽ sau:
Phương pháp có cấu trúc trải qua thời gian đã chứng tỏ được tính kinh điển của nó. Học nó trước hết là học cách tư duy nhất quán và chặt chẽ của nó.
Phương pháp có cấu trúc dung dị, không cầu kỳ, dễ áp dụng, nhưng lại rất hữu hiệu.
Tác giả biên soạn giáo trình này với mục đích tóm lược những khái niệm cơ bản nhất trong lý thuyết, kỹ thuật áp dụng để xây dựng được một hệ thống thông tin quản lý cụ thể nhằm giúp sinh viên có thể nắm bắt được kiến thức của môn học.
Trong cuốn giáo trình này ngoài việc trình bày những kiến thức cơ bản tác giả còn đưa ra ví dụ về phân tích một hệ thống thông tin cụ thể trong cuộc sống để người đọc dễ hiểu và biết cách vận dụng kiến thức vào thực tế.
Nội dung giáo trình được chia thành 6 chương:
Chương 1 – Đại cương về hệ thống thông tin: Giới thiệu các khái niệm cơ bản về hệ thống, hệ thống thông tin, các thành phần của hệ thống thông tin, các giai đoạn phân tích thiết kế hệ thống.
Chương 2 – Khảo sát hiện trạng và xác lập dự án: Giới thiệu các bước và phương pháp thực hiện trong giai đoạn khảo sát hệ thống như: tìm hiểu hiện trạng, xác định mục tiêu, phạm vi, các giải pháp.
Chương 3 – Phân tích hệ thống về chức năng: Giới thiệu các bước phân tích hệ thống về chức năng. Xây dựng mô hình phân rã chức năng.
Chương 4 – Phân tích hệ thống về dữ liệu: Giới thiệu các bước phân tích hệ thống về dữ liệu. Giới thiệu các mô hình thực thể liên kết và cách chuyển đổi giữa các mô hình. Xây dựng mô hình quan hệ của hệ thống.
Chương 5 – Thiết kế hệ thống: Giới thiệu cách thiết kế hệ thống nhằm chuyển các đặc tả logic của hệ thống thành các đặc tả vật lý của hệ thống.
Chương 6 – Lập trình chạy thử và bảo trì: Giới thiệu các lựa chọn ngôn ngữ, hệ quản trị cơ sở dữ liệu để lập trình và viết các tài liệu cho hệ thống.
Cuốn sách như đã giới thiệu ở trên, nhằm mục đích làm giáo trình tham khảo cho sinh viên ngành Công nghệ thông tin. Mọi ý kiến về giáo trình, xin được trao đổi với tác giả qua địa chỉ: Văn phòng khoa CNTT – Trường CĐ KTCN Việt Nam – Hàn Quốc. Rất mong nhận được ý kiến đóng góp của bạn đọc.
Tác giả
Chương 1 – ĐẠI CƯƠNG VỀ HỆ THỐNG THÔNG TIN
Chương mở đầu sẽ trình bày một cách khái quát về khái niệm hệ thống, một số hệ thống (hệ thống kinh doanh/ dịch vụ, hệ thống tin học), rồi tiếp đó đề cập đến cấu trúc, vai trò của hệ thống thông tin, và cuối cùng là các giai đoạn phân tích và thiết kế hệ thống.
BÀI 1. KHÁI NIỆM VỀ HỆ THỐNG THÔNG TIN
1.1. KHÁI NIỆM CHUNG VỀ HỆ THỐNG
1.1.1. Hệ thống
Hê thống Là một tập hợp các phần tử có những mối quan hệ ràng buộc lẫn nhau cùng hoạt động hướng tới một số mục đích chung.
Ta đề cập sâu thêm một số khái cạnh trong định nghĩa này
Các phần tử của hệ thống 
	Các phần tử nói ở đây là các thành phần hợp thành hệ thống:
Các phần tử có thể rất đa dạng: chẳng hạn như trong hệ thống thần kinh thì các phần tử là bộ óc, tủy sống, các dây thần kinh,....; có thể các phần tử lại là những đối tượng trừu tượng, như là một phương pháp, một lập luận.....như trong các hệ thống tư tưởng. Như vậy các phần tử có thể là rất khác biệt về bản chất, không những giữa các hệ thống khác nhau, mà có thể ngay trong cùng một hệ thống.
Các phần tử lại không nhất thiết là đơn giản, sơ đẳng, mà thường khi là những thực thể phức tạp, khiến khi đi sâu vào chúng, ta lại phải xem chúng là các hệ thống. Bởi thế, hệ thống thường có tính phân cấp: hệ thống hợp thành từ nhiều hệ thống con, và trong mỗi hệ thống con đó lại có các hệ thống con nhỏ hơn.
Các quan hệ giữa các phần tử
Các phần tử của một hệ thống không phải tập hợp lại một cách ngẫu nhiên, rời rạc, mà giữa chúng luôn tồn tại những quan hệ (hay các mối ràng buộc lẫn nhau), tạo thành một cấu trúc (hay một tổ chức). Chảng hạn: Trong một hệ thống hành chính, gồm các cán bộ và nhân viên, thì giữa họ tồn tại các mối ràng buộc về phân cấp, phân quyền, các quan hệ về đoàn thế, các quan hệ vê dân sự.
Khi xem xét tính tổ chức của một hệ thống, người ta phải đề cập trước hết đến các quan hệ ổn định, lâu dài.
Tuy nhiên nói đến ổn định, không nhất thiết phải hiểu là hoàn toàn bất biến, tĩnh tại. Trái lại phần lớn các hệ thống đáng quan tâm đều có tính biến động. Biến động song vẫn giữ sự ổn định trong tổ chức, trong các quan hệ giữa các phần tử, nghĩa là vẫn giữ cái bản chất, hay các đặc trưng cốt lõi của hệ thống.
Sự hoạt động và mục đích của hệ thống
Sự biến động của hệ thống thể hiện trên hai mặt:
Sự tiến triển, tức là các thành phần của nó (các phần tử và các quan hệ) có thể có phát sinh, có tăng trưởng, có suy thoái, có mất đi.
Sự hoạt động, tức là các phần tử của hệ thống, trong các mối ràng buộc đã định, cùng cộng tác với nhau để thực hiện một mục đích chung của hệ thống.
Mục đích của hệ thống thường thể hiện ở chỗ hệ thống nhận những cái vào để chế biến thành những cái ra nhất định. Chẳng hạn:
Một hệ thống thu hình, nhận vào năng lượng điện cùng các sóng vô tuyến từ đài phát, để biến thành các hình ảnh trên màn hính.
Một hệ thống sản xuất nhận vào các nguyên vật liệu, tiền, dịch vụ để sản xuất ra các thành phần, hàng hóa.
Môi trường bên ngoài
Một câu hỏi đặt ra: hệ thống nhận cái vào từ đâu? và đưa cái ra ra đâu?. Đó chính là môi trường.
Để phân biệt hệ thống và môi trường xung quanh, cần phải xác định giới hạn của hệ thống (cả về vật lý và khái niệm). Một trong những cách để xác định giới hạn hệ thống là mô tả hệ thống. Với các loại hệ thống khác nhau, cách mô tả hệ thống cũng rất phong phú và đa dạng
Có thể mô tả hệ thống bằng các phương pháp định tính, thông qua mô tả tính chất, chức năng và nhiệm vụ của hệ thống.
Có thể mô tả hệ thống bằng phương pháp định lượng, thông qua việc liệt kê danh sách tất cả các phần tử của hệ thống, mối quan hệ giữa các phần tử, cùng các điểm "nối" với môi trường bên ngoài.
Việc xác định biên một cách chính xác và hợp lý là rất cần thiết, đặc biệt có ý nghĩa đối với giai đoạn khảo sát hệ thống.
Cần lưu ý rằng, giới hạn của hệ thống phụ thuộc chặt chẽ vào mục tiêu của hệ thống đó. Ta có thể đưa ra khái niệm môi trường bên ngoài như sau:
Môi trường bên ngoài là tập hợp các phần tử không phụ thuộc vào hệ thống nhưng có mối liên hệ với hệ thống hoặc chịu sự tác động của hệ thống hoặc là tác động lê hệ thống.
Ví dụ: Khách hàng và Nhà cung cấp hàng là các phần tử thuộc môi trường bên ngoài đối với công ty X – nếu xem công ty này như một hệ thống.
Quan hệ giữa Khách hàng và công ty là mua hàng
Quan hệ Nhà cung cấp hàng với công ty X là cung cấp vật tư.
Hệ thống kinh tế
NHÀ CUNG CẤP
Cung ứng
 vật tư
CÔNG TY X
Mua hàng
KHÁCH HÀNG
Hình 1 – 1: Ví dụ về một hệ thống.
1.1.2. Hệ thống kinh doanh/ dịch vụ
Định nghĩa
Là hệ thống mà mục đích là kinh doanh hay dịch vụ.
Kinh doanh là hoạt động của con người nhằm mang lại lợi nhuận (tức thu giá trị thặng dư).
Dịch vụ là hoạt động của con người nhằm mạng lại lợi ích (tức là cung cấp giá trị sử dụng ). Ví dụ các hoạt động giáo dục, y tế, từ thiện.....
Hệ thống kinh doanh/ dịch vụ nói ở đây có thể ở những quy mô khác nhau. Quy mô nhỏ như một phân xưởng, một cửa hàng. Quy mô vừa như 1 nhà máy, một công ty, một bệnh viện. Quy mô lớn như một tổng công ty, một ngành sản xuất, một tập đoàn kinh doanh đa quốc gia. Để cho gọn, người ta thường gọi hệ thống kinh doanh/dịch vụ là doanh nghiệp hay cơ quan.
Đặc điểm chung của hệ thống kinh doanh/dịch vụ so với hệ thống khác( như hệ thống vật lý, hệ thống kỹ thuật hay hệ thống sinh học) là : chúng là của con người và có con người tham gia.
Đặc điểm chung nói ở trên dẫn tới hai nét nổi bật của các hệ thống kinh doanh/dịch vụ:
Vai trò của cơ chế điều khiển (Trong kinh doanh thường gọi là sự quản lý) là rất quan trọng, nhằm giữ cho hệ thống hướng đúng đích và đạt kết quả với chất lượng cao.
Vai trò của thông tin cũng rất quan trọng, nhằm phục vụ cho nhu cầu giao tiếp, trao đổi giữa con người với nhau.
Các hệ thống con trong hệ thống kinh doanh/ dịch vụ
Bởi sự tồn tại của nhiệm vụ quản lý bên cạnh nhiệm vụ sản xuất như đã nói ở trên, cho nên các hệ thống kinh doanh/dịch vụ luôn bao gồm 2 hệ thống con:
Hệ thống tác nghiệp, gồm con người, phương tiện, phương pháp trực tiếp tham gia vào quá trình biến đổi luồng những cái đi vào thành luồng những cái đi ra (thể hiện mục đích kinh doanh hay dịch vụ) của hệ thống.
Hệ thống quản lý, gồm con người, phương tiện, phương pháp cho phép điều khiển, kiểm soát hoạt động tavs nghiệp hướng đúng vào mục đích kinh doanh hay dịch vụ. Về mặt hình thức hoạt động quản lý luôn luôn là một dãy nối tiếp của hai việc: 
Đề xuất một quyết định kinh doanh.
Thực thi quyết định kinh doanh.
Ta hiểu quyết định là một sự lựa chọn một trong những phương pháp hành động có thể để giải quyết một vấn đề nào đó. Mọi quyết định đều được đề xuất qua hai bước:
Tìm hiểu vấn đề 
Lựa chọn phương pháp
Như vậy, trước khi ra quyết định cần phải thu thập thông tin liên quan. Thông thường thì các thông tin có ích cho quyết định phải được kết xuất từ nhiều nguồn thông tin phức tạp, thông qua các quá trình thu gom, lưu trữ, xử lý. Sau khi ra quyết định, quyết định phải được truyền đạt đến nơi thực hiện, cùng với những thông tin cần thiết cho việc thực thi quyết định đó. Nói thế có nghĩa là, trong quản lý, bên cạnh nhiệm vụ đề xuất các quyết định kinh doanh, luôn có nhiệm vụ xử lý thông tin. Vì vậy hệ thống (con) quản lý trong hệ thống kinh doanh/dịch vụ lại có thể tách thành hai hệ thống con:
Hệ quyết định, gồm con người, phương tiện, phương pháp thực hiện việc đề xuất các quyết định kinh doanh.
Hệ thông tin, gồm con người, phương tiện, phương pháp tham gia vào việc xử lý các thông tin kinh doanh.
Tóm lại, hệ thống kinh doanh/dịch vụ chứa ba hệ thống con: Hệ tác nghiệp, Hệ quyết định, và Hệ thông tin, mà mối liên quan về thông tin giữa chúng được diễn tả như trong hình sau, ở đó thấy rõ vai trò trung gian của hệ thống thông tin trong doanh nghiệp.
Hệ quyết định
Báo cáo sản xuất
Chỉ đạo sản xuất
Hệ 
thông 
tin
Thông tin ra
Thông tin vào
Hệ tác nghiệp
Nguyên vật liệu
Sản phẩm/dịch vụ
MÔI TRƯỜNG
Hình 1 – 2: Các phân hệ của hệ thống kinh doanh/ dịch vụ
Chú ý rằng việc phân chia hệ thống kinh doanh/dịch vụ thành ban hệ thống con như trên chỉ có ý nghĩa phương pháp luận, nhằm cho ta một cách nhìn, một cách nghiên cứu đối với hệ thống, chứ không phải là một sự phân chia về tổ chức.
Tuy nhiên, nhìn một cách khái quát vào một doanh nghiệp, ta luôn thấy:
Những người mà nhiệm vụ chính là đề xuất các quyết định (cán bộ lãnh đạo các cấp)
Những người mà nhiệm vụ chính là xử lý thông tin (Nhân viên các phòng ban)
Những người mà nhiệm vụ chính là trực tiếp sản xuất hay dịch vụ (công nhân, kỹ sư, bác sĩ, giáo viên,....)
Vì thế mà cách tiếp cận hệ thống như trên vẫn là có ích
1.2. VAI TRÒ VÀ NHIỆM VỤ CỦA HỆ THỐNG THÔNG TIN
a. Định nghĩa
Hệ thống thông tin (Information System) là một hệ thống mà mục tiêu tồn tại của nó là cung cấp thông tin phục vụ cho hoạt động của con người trong tổ chức nào đó. Ta còn có thể hiểu Hệ thống thông tin là hệ thống mà mối liên hệ giữa các thành phần của nó cũng như mối liên hệ giữa nó với các hệ thống khác là sự trao đổi thông tin.
Ví dụ: Hệ thống quản lý nhân sự, hệ thống quản lý điểm,...
b. Vai trò của hệ thống thông tin
Hệ thống thông tin đóng vai trò trung gian giữa hệ quyết định và hệ tác nghiệp trong hệ thống quản lý.
Trao đổi thông tin với môi trường ngoài.
Thực hiện việc liên lạc giữa các bộ phận và cung cấp thông tin cho các hệ quyết định và hệ tác nghiệp.
c. Nhiệm vụ của hệ thống thông tin
Hệ thống thông tin có bốn nhiệm vụ chính là nhận thông tin vào, lưu trữ, xử lý, và đưa ra thông tin.
Nhận thông tin vào dưới dạng các dữ liệu gốc về một chủ điểm, một sự kiện hoặc một đối tượng nào đó trong hệ thống, các yêu cầu xử lý hoặc cung cấp thông tin, các lệnh
Xử lý dữ liệu bao gồm sắp xếp, sửa chữa, thay đổi dữ liệu trong bộ nhớ, thực hiện các tính toán tạo ra thông tin mới, thống kê, tìm kiếm các thông tin thỏa mãn một điều kiện nào đó.
Lưu trữ các loại thông tin khác nhau có cấu trúc đa dạng, phục vụ nhu cầu xử lý khác nhau.
Đưa ra thông tin: có thể đưa dữ liệu với các khuôn dạng khác nhau ra các thiết bị như bộ nhớ ngoài, màn hình, máy in, thiết bị mạng hoặc các thiết bị điều khiển.
1.3. CẤU TRÚC HỆ THỐNG THÔNG TIN , CÁC DỮ LIỆU VÀ CÁC XỬ LÝ
Nếu không kể con người và thiết bị, Hệ thống thông tin trong doanh nghiệp có hai thành phần cơ bản:
Các dữ liệu ghi nhận thực trạng của doanh nghiệp.
Các quy trình xử lý cho phép biến đổi các dữ liệu
Các dữ liệu: Đó là các thông tin được lưu và duy trì nhằm phản ánh thực trạng hiện thời hay quá khứ cảu doanh nghiệp. Có thể tách dữ liệu thành hai phần
Các dữ liệu phản ánh cấu trúc nội bộ của cơ quan, như dữ liệu về nhân sự, nhà xưởng, thiết bị.....Cấu trúc cơ quan không phải là cố định, mà có thể biến động khi có một sự kiện tiến hóa xảy ra. Sự kiện tiến hóa thường xảy ra bất ngờ, ngoài ý muốn của con người. Sự điều chỉnh lại các dữ liệu cho thích hợp khi có sự kiện tiến hóa xảy ra gọi là sự cập nhật
Các dữ liệu phản ánh các hoạt động kinh doanh/ dịch vụ của cơ quan, như dữ liệu về sản xuất, mua bán, giao dịch....Hoạt động kinh doanh/dịch vụ nhằm biến đổi luồng vào/ra của doanh nghiệp có thể xem là sự tiếp nối của hàng loạt các sự việc sơ đẳng, gọi là các sự kiện hoạt động. Khi có một sự kiện hoạt động xảy ra thì phải ghi nhận nó, và như vậy làm thay đổi các dữ liệu phản ánh các hoạt động kinh doanh/dịch vụ của doanh nghiệp
Các xử lý: Đó là quá trình biến đổi thông tin, nhằm vào hai mục đích chính
Sản sinh các thông tin theo thể thức quy định, chẳng hạn các chứng từ giao dịch (đơn mua hàng, hóa đơn.,....), các báo cáo, các bản thống kê,....
Trợ giúp cho các quyết định, thông thường là cung cấp những thông tin cần thiết cho việc chọn lựa một quyết định của lãnh đạo, nhưng cũng có thể là thực hiện một sự chọn lựa quyết định (một cách tự động),nếu đó là loại quyết định dựa trên giải thuật (khác với loại quyết định dựa trên trực quan)
Mỗi xử lý thường là một sự áp dụng một quy tắc quản lý định sẵn và diễn ra theo một trật tự định sẵn(gọi là thủ tục). Các quy tắc quản lý và các thủ  ...  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