Báo cáo bài tập quản trị quá trình triển khai hệ thống thông tin

1
HỌC VIỆN KỸ THUẬT QUÂN SỰ
KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO BÀI TẬP
QUẢN TRỊ QUÁ TRÌNH TRIỂN KHAI HỆ
THỐNG THÔNG TIN

Giảng viên hướng dẫn: TS Tống Minh Đức
Học viên thực hiện:
Lớp: Hệ thống Thông tin – K25
HÀ NỘI – 2014
MỤC LỤC
PHẦN I: KIẾN THỨC CƠ BẢN VỀ QUẢN TRỊ PTTK HỆ THỐNG THÔNG
TIN 5
I. CÁC KHÁI NIỆM VỀ HỆ THỐNG THÔNG TIN 5
1. NHỮNG VẤN ĐỀ CƠ BẢN VỀ HỆ THỐNG THÔNG TIN 5
2. MÔ HÌNH HỆ THỐNG THÔNG TIN 7
II. CÁC MÔ HÌNH XÂY DỰNG HỆ THỐNG THÔNG TIN 10
1. MÔ HÌNH THÁC NƯỚC (WATERFALL) 14
2. MÔ HÌNH TIẾN HÓA (EVOLUTIONARY) 16
3. MÔ HÌNH TĂNG TRƯỞNG (INCREMENTAL) 18
III. PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN 20
1. PHÂN TÍCH THIẾT KẾ HƯỚNG (CẤU TRÚC) CHỨC NĂNG 20
2. PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 21
3. NGÔN NGỮ UML 26
IV. CÁC TÁC NHÂN THAM GIA QUÁ TRÌNH PTTK 33
V. CÁCH THỨC TỔ CHỨC, QUẢN TRỊ QUÁ TRÌNH PTTK 36
1. CÔNG TÁC CHUẨN BỊ 36
2. QUẢN TRỊ MODULES 36
3. QUẢN TRỊ NHÂN SỰ 37

4. QUẢN TRỊ CHẤT LƯỢNG 38
5. QUẢN TRỊ RỦI RO 39
PHẦN II: QUẢN TRỊ QUÁ TRÌNH TRIỂN KHAI HỆ THỐNG QUẢN LÝ
THUẾ TẠI HÀ NỘI 40
2
GIỚI THIỆU 40
Mục đích 40
Khái niệm, thuật ngữ 40
Mô tả tài liệu 41
GIẢI PHÁP TRIỂN KHAI 41
Kiến trúc tổng thể hệ thống 41
Giải pháp triển khai tổng thể 43
Giải pháp triển khai ứng dụng Quản lý thuế cấp Tổng cục 43
Giải pháp triển khai các ứng dụng Quản lý thuế cấp Cục và Chi cục Mô hình
cục 45
1.1.1 Giải pháp triển khai ứng dụng Quản lý thuế cấp Chi cục Mô hình VAT
48
1.2 Chuẩn bị triển khai 50
1.2.1 Chuẩn bị về máy chủ 50
1.2.2 Chuẩn bị về máy trạm 54
1.2.3 Chuẩn bị về mạng và đường truyền 54
1.2.4 Backup dữ liệu Cục thuế trước triển khai 55
1.3 Các giải pháp triển khai chi tiết 55
1.3.1 Giải pháp cài đặt Database 55
1.3.2 Giải pháp cài đặt máy trạm 56
1.3.3 Giải pháp kiểm tra và xác nhận công việc triển khai 57
1.3.4 Giải pháp xử lý lỗi chương trình trong quá trình triển khai 58
1.4 Danh sách các đĩa cài đặt 58
3
2QUY TRÌNH TRIỂN KHAI 58

2.1 Quy trình triển khai ứng dụng Quản lý thuế cấp Tổng cục thuế 58
2.1.1 Chuẩn bị triển khai 58
2.1.2 Triển khai ứng dụng QTC 59
2.1.3 Kiểm tra và hỗ trợ sau triển khai 60
2.2 Quy trình triển khai các ứng dụng Quản lý thuế cấp Cục thuế và Chi cục mô
hình cục 61
2.2.1 Chuẩn bị triển khai 61
2.2.2 Triển khai ứng dụng QTN 62
2.2.3 Triển khai ứng dụng QLT, BMT, QHS 65
2.2.4 Kiểm tra và hỗ trợ sau triển khai 67
2.3 Quy trình triển khai tại Chi cục thuế Mô hình VAT 69
3PHỤ LỤC 72
3.1 Danh sách các điểm triển khai 72
4
PHẦN I: KIẾN THỨC CƠ BẢN VỀ QUẢN TRỊ PTTK HỆ
THỐNG THÔNG TIN
I. CÁC KHÁI NIỆM VỀ HỆ THỐNG THÔNG TIN
1. NHỮNG VẤN ĐỀ CƠ BẢN VỀ HỆ THỐNG THÔNG TIN
Khi nghiên cứu những vấn đề cơ bản của hệ thống nói chung ta cần làm rõ
khái niệm và đặc trưng về hệ thống. Trong các hoạt động của con người, các thuật
ngữ như hệ thống triết học, hệ thống pháp luật, hệ thống kinh tế, hệ thống thông
tin đã trở nên quen thuộc. Một cách đơn giản và vấn tắt, ta có thể hiểu: Hệ thống là
một tập hợp vật chất và phi vật chất như người, máy móc, thông tin, dữ liệu, các
phương pháp xử lý, các qui tắc, quy trình xử lý, gọi là các phần tử của hệ thống.
Trong hệ thống, các phần tử tương tác với nhau và cùng hoạt động để hướng tới
mục đích chung.
Khái niệm chung về hệ thống: Hệ thống là tập hợp các phần tử tương tác được
tổ chức nhằm thực hiện một mục đích xác định.
Như vậy có thể hiểu hệ thống là một tập hợp gồm nhiều phần tử, có mối quan hệ
ràng buộc lẫn nhau và cùng hoạt động hướng tới mục đích chung. Ví như hệ thống

thông tin quản lý là hệ thống thông tin tin học hóa, cung cấp thông tin cho công tác
quản lý của tổ chức, nó bao gồm con người, thiết bị và quy trình thu thập, phân
tích, đánh giá và phân phối những thông tin cần thiết, kịp thời, chính xác cho
những người soạn thảo các quyết định trong tổ chức. Đây cũng là tên gọi của một
chuyên ngành khoa học. Ngành khoa học này thường được xem là một phân ngành
của khoa học quản lý và quản trị kinh doanh. Ngoài ra, do ngày nay việc xử lý dữ
liệu thành thông tin và quản lý thông tin liên quan đến công nghệ thông tin, nó
cũng được coi là một phân ngành trong toán học, nghiên cứu việc tích hợp hệ
thống máy tính vào mục đích tổ chức. Các loại thông tin quản lý được coi như là
những dữ liệu.
Các đặc trưng của hệ thống: Đó là tính tổ chức, tính biến động, hệ thống phải có
môi trường hoạt động, hệ thống phải có tính điều khiển.
5
• Tính tổ chức: Các phần tử trong hệ thống không tách rời nhau mà chúng
phải có những mối quan hệ nhất định, ràng buộc lẫn nhau.
• Tính biến động: Bất kỳ hệ thống nào cũng có tính biến động, tức là luôn có
sự phát triển cho phù hợp với yêu cầu nhiệm vụ từng giai đoạn. Mục tiêu
chính của phân tích và thiết kế hệ thống là để cải tiến hệ thống cấu trúc.
• Hệ thống phải có môi trường hoạt động: Môi trường là tập hợp các phần tử
không thuộc hệ thống nhưng có thể tác động vào hệ thống hoặc bị tác động
bởi hệ thống. Không có môi trường hoạt động, không thể kiểm nghiệm được
tính đúng đắn của hệ thống.
• Hệ thống phải có tính điều khiển: Cơ chế điều khiển nhằm phối hợp, dẫn dắt
chung các phần tử của hệ thống để chúng không trượt ra ngoài mục đích của
hệ thống.
- Khái niệm hệ thống thông tin: Một tập hợp thống nhất, kết hợp của các phần
cứng, phần mềm, các hệ thống mạng truyền thông được xây dựng và sử dụng
để thu thập, tạo, tái tạo, phân phối và chia sẻ các dữ liệu, thông tin, tri thức
nhằm phục vụ các mục tiêu, yêu cầu của tổ chức. Tập hợp các yếu tố, các
hành động, các thao tác, xử lý thông tin có mối quan hệ tác động lẫn nhau

nhằm hỗ trợ cho quá trình quản lý và điều hành. Một giải pháp quản lý của
tổ chức dựa trên công nghệ thông tin để thích ứng nhanh với môi trường.
- Như ta đã biết mục tiêu chính của quản trị quá trình phân tích và thiết kế hệ thống
là để cải tiến hệ thống cấu trúc. Thông thường điều này liên quan đến phát triển
hay tạo được phần mềm ứng dụng và huấn luyện nhân viên để sử dụng nó. Phần
mềm ứng dụng, cũng còn được gọi là một hệ thống, được thiết kế để hỗ trợ một
nhiệm vụ hay một quy trình được tổ chức cụ thể như quản lý tồn kho, chi trả
lương, phân tích thị trường chứng khoán…Mục tiêu của phần mềm ứng dụng là
chuyển dữ liệu thành thông tin, ví dụ một phần mềm được phát triển cho một cửa
hàng dược phẩm có thể theo dõi được loại thuốc bán chạy nhất trong tuần hay
trong tháng với doanh số bao nhiêu. Hay phần mềm quản lý tiền lương có thể theo
dõi được sự thay đổi lương của nhân viên theo các mốc thời gian quy định, sự tăng
thưởng, phạt…
6
Ngoài phần mềm ứng dụng, hệ thống thông tin còn bao gồm:
• Phần cứng (hardware) và phần mềm hệ thống (system software) là nền tảng
để phần mềm ứng dụng hoạt động. Phần mềm hệ thống trợ giúp các chức
năng của máy tính, trong khi phần mềm ứng dụng trợ giúp người sử dụng
hoàn thành các công việc như viết lách, chuẩn bị bảng tính, báo cáo…
• Các tài liệu huấn luyện: Là các tài liệu được tạo bởi người phân tích hệ
thống để trợ giúp nhân viên sử dụng phần mềm.
• Các vai trò công việc cụ thể gắn liền với hệ thống, ví dụ như người chạy
máy tính và việc duy trì hoạt động của phần mềm.
• Kiểm soát (controls) là các phần việc của phần mềm nhằm ngăn chặn sự
xâm nhập trái phép, gian lận, trộm cắp…
• Người sử dụng phần mềm nhằm thực hiện công việc của mình.
2. MÔ HÌNH HỆ THỐNG THÔNG TIN
7
- Các đặc điểm của hệ thống thông tin:
• Mục tiêu của hệ thống xác định,

• Dữ liệu liên quan phù hợp, tương thích,
• Quy trình xử lý chặt chẽ,
• Có sự tham gia của nhiều thiết bị hỗ trợ, phần cứng, phần mềm,
• Có sự tham gia xử lý, điều khiển, quyết định bởi con nguời,
• Có môi trường xác định khi hoạt động,
• Hệ thống chuẩn tắc,
• Dữ liệu và quy trình
• Thu thập, lưu trữ, xử lý, phân phối và khai thác dữ liệu.
8
- Sự xác định hệ thống và các thành phần của nó:
Một hệ thống là một tập tương quan giữa các thành phần được sử dụng trong một
đơn vị doanh nghiệp, cùng hoạt động vì một mục tiêu nào đó. Ví dụ một hệ thống
trong bộ phận lương sẽ theo dõi chính xác khoản chi trả, trong khi hệ thống kho sẽ
theo dõi chính xác các hoạt động cung ứng. Hai hệ thống này hoàn toàn tách biệt.
Một hệ thống có 9 tính chất, qua đó ta thấy một hệ thống tồn tại trong một thế giới
rộng mở, một môi trường. Một đường biên tách hệ thống với môi trường của nó,
hệ thống nhận nguồn vào từ bên ngoài, xử lý chúng và gửi kết quả ngược lại môi
trường của nó.
• Thành phần hệ thống (component),
• Liên hệ giữa các thành phần,
• Ranh giới (boundary),
• Mục đích (purpose),
• Môi trường (environment),
• Giao diện (interface);
• Đầu vào (input);
• Đầu ra (output);
• Ràng buộc (constraints).
Một hệ thống được cấu tạo từ các thành phần, một thành phần hoặc là một phần
đơn (không thể chia nhỏ được) hoặc là một tập các thành phần còn được gọi là hệ
thống con (subsystem). Khái niệm đơn của một thành phần rất quan trọng, ví dụ

với một hệ thống âm thanh thiết kế khoa học, chúng ta có thể sửa chữa hay nâng
cấp hệ thống bằng cách thay đổi từng thành phần mà không phải thay đổi toàn bộ
hệ thống.
Các thành phần là tương quan, nghĩa là chức năng của một thành phần bằng cách
nào đó thắt chặt với chức năng của thành phần khác. Một hệ thống có một biên
giới mà tất cả các thành phần chứa đựng trong đó, nó còn thiết lập giới hạn của hệ
9
thống, tách nó khỏi các hệ thống khác. Các thành phần trong biên giới có thể được
thay đổi trong khi các hệ thống bên ngoài biên giới không thể bị thay đổi. Tất cả
các thành phần làm việc với nhau để đạt được một vài mục tiêu toàn diện cho hệ
thống lớn hơn: lý do tồn tại của hệ thống.
Một hệ thống tồn tại trong một môi trường, mọi thứ bên ngoài biên giới hệ thống
có ảnh hưởng đến hệ thống:
Ví như một trường đại học bao gồm những sinh viên tương lai, tiền dự trữ, các quỹ
tài trợ và thông tin tin tức. Thông thường hệ thống tương tác với môi trường của
nó. Trường đại học tương tác với sinh viên bằng cách ưu ái và tuyển chọn từ
trường trung học địa phương. Một hệ thống thông tin tương tác với môi trường của
nó bằng việc tiếp nhận dữ liệu (sự kiện thô) và thông tin (dữ liệu qua xử lý ở một
dạng có ích).
II. CÁC MÔ HÌNH XÂY DỰNG HỆ THỐNG THÔNG TIN
1. CÁC GIAI ĐOẠN
10
2. Giai đoạn 1: Đánh giá yêu cầu
Lập kế hoạch đánh giá yêu cầu
Làm rõ, đầy đủ, chi tiết các yêu cầu
Xây dựng các phương án thực thi
Đánh giá khả năng thực thi của các phương án, tìm phương án tối ưu
Chuẩn bị và trình bày báo cáo đánh giá yêu cầu và giải pháp thực hiện.
Giai đoạn 2: Phân tích chi tiết
Lập kế hoạch phân tích chi tiết,

 Nghiên cứu môi trường của hệ thống thực tại
 Nghiên cứu hệ thống thực tại
 Chẩn đoán và xác định các yếu tố liên quan đến
giải pháp thực hiện
 Đánh giá lại tính khả thi của việc phát triển
 Sửa đổi đề xuất phát triển hệ thống thông tin
11
 Chuẩn bị và trình bày báo cáo phân tích chi tiết.
Giai đoạn 3: Thiết kế mô hình Logic
Thiết kế mô hình dữ liệu
 Thiết kế mô hình xử lý, tương tác
 Thiết kế các kiểm soát của hệ thống thông tin
 Đánh giá mô hình thiết kế với mô hình hiện tại
 Hoàn chỉnh tài liệu mô hình lôgíc Hợp thức hoá mô
hình lôgíc.
Giai đoạn 4: Đề xuất phương án Giải pháp
Xác định các ràng buộc tổ chức và công nghệ,
 Xác định các yêu cầu cấp thiết, các yêu cầu
chưa cấp thiết, mục tiêu chính, mục tiêu chấp nhận được
 Xây dựng các phương án của giải pháp, Đánh giá các
12
phương án của giải pháp,
 Chuẩn bị và trình bày báo cáo về các phương án của giải pháp.
Giai đoạn 5: Thiết kế vật lý
Lập kế hoạch thiết kế vật lý,
 Thiết kế chi tiết các giao diện vào/ra,
 Thiết kế phương thức giao tác với phần tin học hóa
 Thiết kế các thủ tục thủ công,
 Thiết kế các kiểm soát hệ thống,
 Chuẩn bị và trình bày báo cáo thiết kế vật lý.

Giai đoạn 6: Triển khai hệ thống
Lập kế hoạch thực hiện kỹ thuật
 Thiết kế chi tiết hệ thống,
13
 Triển khai các yếu tố công nghệ, thiết bị, lập trình
 Thử nghiệm kiểm tra, đánh giá, hiệu chỉnh,
 Chuẩn bị các tài liệu cho hệ thống.
Giai đoạn 7: Cài đặt và khai thác
Lập kế hoạch triển khai áp dụng,
 Triển khai hoạt động thử nghiệm,
 Chuyển đổi mô hình, dữ liệu, …
 Triển khai hoạt động thực tế,
 Chuyển giao thực hiện
 Khai thác và bảo trì, Đánh giá.
1. MÔ HÌNH THÁC NƯỚC (WATERFALL)
Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt
động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu
chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước
trở thành đầu vào của giai đoạn sau.
14
Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có
thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai
đoạn trước. Tuy nhiên, hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà
thôi. Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích
của các nhà quản lí dự án. Thời gian hoàn thành dự án thường được dự báo với độ
chính xác hơn so với các mô hình khác. Các tài liệu đầu ra của từng giai đoạn cũng
được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô hình này có một số nhược
điểm lớn là:
- Đòi hỏi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách
hàng. Yêu cầu này hiếm khi đạt được bởi khách hàng ít khi xác định được chính

xác họ muốn gì ở ngay giai đoạn đầu của dự án, sở thích của họ cũng thay đổi khá
thường xuyên. Việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi của
khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm.
- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn
phân tích yêu cầu và test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất
cả các công việc liên quan đã được hoàn thành.
15
Quá trình phân tích thiết kế hệ thống trong mô hình thác nước yêu cầu phải được
tiến hành bởi đội dự án đã có kinh nghiệm, các yêu cầu từ khách hàng phải được
xác định rõ ngay từ đầu và phải được cam kết từ phía khách hàng là không có sự
thay đổi quy trình nghiệp vụ trong quá trình thực hiện.
Việc đánh giá các tài liệu phân tích thiết kế hệ thống phải thông qua khách hàng.
Các tài liệu cần phải đủ rõ để khách hàng có thể hình dung ra được hệ thống hoạt
động như thế nào, giao diện được hiển thị ra sao, các thao tác tương tác giữa người
và hệ thống …
Trong quá trình thiết kế, để giảm thiểu các rủi ro về mặt nghiệp vụ cần phải xây
dựng các lớp chức năng có tính trừu tượng hóa cao, sau đó cụ thể hóa với hệ thống
bằng các tham số. Điều này sẽ giảm thiểu chi phí trong trường hợp khách hàng có
sự thay đổi yêu cầu đối với hệ thống.
2. MÔ HÌNH TIẾN HÓA (EVOLUTIONARY)
Mô hình tiến hóa được đưa ra nhằm giải quyết những khó khăn gây ra do yêu cầu
của khách hàng không rõ ràng hoặc hay thay đổi. Ý tưởng của mô hình này là phát
triển phẩn mềm qua nhiều phiên bản, mỗi phiên bản được đưa ra lấy ý kiến khách
hàng, được sửa chữa, làm mịn cho đến khi đạt được phiên bản hoàn chỉnh.
16
Mô hình tiến hóa: Các phiên bản 1, 2, 3 có thể rất khác nhau
Hai kiểu mô hình tiến hóa cơ bản là:
- Khám phá và phát triển (exploratory development): Đội dự án sẽ làm việc
cùng khách hàng để làm rõ các yêu cầu của họ. Dự án sẽ bắt đầu trước tiên với
những yêu cầu đã rõ ràng. Các đặc tính khác sẽ được thêm vào dần dần dựa trên đề

nghị của khách hàng.
- Làm nhiều bản mẫu nhưng không sử dụng (throwaway prototyping): Mô
hình này được áp dụng cho giai đoạn phân tích yêu cầu. Theo đó, đội dự án sẽ làm
các bản mẫu (prototype) để lấy ý kiến khách hàng nhằm kiểm chứng và làm rõ các
yêu cầu chưa rõ ràng. Khi đã có một bản yêu cầu hoàn chỉnh, giai đoạn phát triển
tiếp theo có thể sử dụng mô hình thác nước.
17
Mô hình tiến hóa cho phép khách hàng tham gia sâu hơn vào quá trình phát triển,
nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách
hàng. Tuy nhiên, mô hình này cũng có các nhược điểm là:
- Khó khăn trong việc thiết kế: Việc phát triển qua nhiều phiên bản có thể phá vỡ
kiến trúc tổng thể của phần mềm.
- Khó khăn trong việc quản lí: Đặc biệt là việc quản lý tiến độ, chi phí. Rất khó
để có thể xác định ngay từ đầu thời gian để hoàn thành dự án vì các nội dung công
việc được phát sinh hàng ngày. Ngoài ra, các tài liệu mô tả cho từng phiên bản
thường không được lập đầy đủ.
- Khó khăn do khách hàng gây ra: Khách hàng có thể nhầm tưởng rằng một bản
mẫu có thể tốt gần như sản phẩm thật. Trong thực tế từ bản mẫu đến sản phẩm
cuối cùng là một khảng cách xa. Ngoài ra khách hàng có xu hướng đưa thêm vào
những yêu cầu không cần thiết.
- Khó khăn về địa lý: Mô hình tiến hóa đòi hỏi đội dự án phải ngồi gần khách
hàng. Các dự án outsourcing khó có thể đáp ứng yêu cầu này.
Theo Ian Sommerville trong cuốn “Software Engineering“, mô hình tiến hóa là
mô hình phù hợp nhất cho các dự án vừa và nhỏ (dưới 500 000 dòng code). Các dự
án lớn và phức tạp nên sử dựng một mô hình kết hợp giữa mô hình thác nước và
tiến hóa. Trong đó, các bản mẫu được dùng để làm rõ các yêu cầu của khách hàng.
Các yêu cầu đã rõ ràng được tiếp tục phát triển theo mô hình thác nước. Các yêu
cầu chưa rõ ràng có thể sử dụng mô hình khám phá và phát triển.
Việc quản trị các dự án xây dựng theo mô hình này rất khó khăn. Yếu tố quan
trọng nhất là phải xác định các bản mẫu như thế nào là đủ mịn và đáp ứng được

nhu cầu của khách hàng. Ngoài ra, các sự thay đổi của các hệ thống nhỏ sẽ dẫn đến
sự thay đổi của cả hệ thống lớn. Vì vậy, chúng ta phải tập trung làm các module
chủ chốt của hệ thống coi nó là xương sống của hệ thống, sau đó rồi mới từ từ phát
triển ra các nhánh khác nhau.
3. MÔ HÌNH TĂNG TRƯỞNG (INCREMENTAL)
Mô hình tăng trưởng kết hợp những ưu điểm của mô hình thác nước và mô hình
tiến hóa. Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng
18
trưởng (được gọi là các increments) và phát triển, bàn giao chúng lần lượt cho
khách hàng theo mức độ quan trọng. Phần tăng trưởng nào đến lượt được phát
triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía
khách hàng cho những phần chưa được phát triển mới được chấp nhận.
Theo Ian Sommerville, mỗi phần tăng trưởng không nên quá 20 000 dòng code và
phải mang lại những lợi ích nhất định cho khách hàng. Còn theo Mike Cotterell và
Bob Hughes trong “Software Project Management”, mỗi phần tăng trưởng nên
chiếm từ 1% đến 5% của toàn dự án và không nên kéo dài quá một tháng.
Mô hình tăng trưởng có những ưu điểm sau đây:
- Rút ngắn thời gian chờ đợi của khách hàng. Khách hàng không phải đợi đến
khi toàn bộ hệ thống hoàn thành mới được hưởng lợi. Những thành phần quan
trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng.
- Tăng chất lượng phần mềm. Thành phần quan trọng nhất của hệ thống được
phát triển và đi vào hoạt động sớm nhất, bởi vậy nó được test nhiều nhất. Ngoài ra,
19
những ý kiến của khách hàng cũng như kinh nghiệm phát triển các thành phần
trước sẽ được áp dụng ngay lập tức cho các thành phần sau.
- Giảm bớt những yêu cầu không cần thiết từ khách hàng. Khi một tính năng
chưa có mặt trong hệ thống, họ sẽ nghĩ rằng nó sẽ được tích hợp vào ở những lần
bàn giao tiếp theo
- Tăng năng suất lao động. Nhiều lập trình viên làm việc tốt hơn trong các dự án
nhỏ mà họ sớm nhìn thấy thành quả lao động của mình.

Việc quản trị quá trình phân tích, thiết kế hệ thống theo mô hình tăng trưởng gặp
khó khăn ngay ở khâu xác định bài toán. Không phải hệ thống nào cũng có thể
chia được thành các phần tăng trưởng đủ nhỏ để có thể phát triển và bàn giao tuần
tự. Theo mô hình này, điều quan trọng là xác định được thành phần có vị trí chủ
chốt và tập trung xây dựng nó. Các phần phân tích thiết kế vì thế cũng sẽ tản mác
hơn do không được thực hiện ở cùng thời điểm. Vì vậy khi thực hiện phân tích
thiết kế cần phải chú ý tới việc liên kết các phân hệ của hệ thống đã được xây dựng
từ trước hay nhất là phát triển từ các hệ thống trước theo đúng ý nghĩa của mô hình
là tăng trưởng.
III. PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN
1. PHÂN TÍCH THIẾT KẾ HƯỚNG (CẤU TRÚC) CHỨC NĂNG
Đặc trưng của phương pháp hướng cấu trúc là phân chia chương trình chính thành
nhiều chương trình con, mỗi chương trình con nhằm đến thực hiện một công việc
xác định. Trong phương pháp hướng cấu trúc, phần mềm được thiết kế dựa trên
một trong hai hướng : hướng dữ liệu và hướng hành động.
Cách tiếp cận hướng dữ liệu xây dựng phần mềm dựa trên việc phân rã phần mềm
theo các chức năng cần đáp ứng và dữ liệu cho các chức năng đó. Cách tiếp cận
hướng dữ liệu sẽ giúp cho những người phát triển hệ thống dễ dàng xây dựng ngân
hàng dữ liệu.
Cách tiếp cận hướng hành động lại tập trung phân tích hệ phần mềm dựa trên các
hoạt động thực thi các chức năng của phần mềm đó.
20
Cách thức thực hiện của phương pháp hướng cấu trúc là phương pháp thiết kế từ
trên xuống (top-down). Phương pháp này tiến hành phân rã bài toán thành các bài
toán nhỏ hơn, rồi tiếp tục phân rã các bài toán con cho đến khi nhận được các bài
toán có thể cài đặt được ngay sử dụng các hàm của ngôn ngữ lập trình hướng cấu
trúc.
Phương pháp hướng cấu trúc có ưu điểm là tư duy phân tích thiết kế rõ ràng,
chương trình sáng sủa dễ hiểu. Tuy nhiên, phương pháp này có một số nhược điểm
sau:

- Không hỗ trợ việc sử dụng lại. Các chương trình hướng cấu trúc phụ thuộc
chặt chẽ vào cấu trúc dữ liệu và bài toán cụ thể, do đó không thể dùng lại
một modul nào đó trong phần mềm này cho phần mềm mới với các yêu cầu
về dữ liệu khác.
- Không phù hợp cho phát triển các phần mềm lớn. Nếu hệ thống thông tin
lớn, việc phân ra thành các bài toán con cũng như phân các bài toán con
thành các modul và quản lý mối quan hệ giữa các modul đó sẽ là không phải
là dễ dàng và dễ gây ra các lỗi trong phân tích và thiết kế hệ thống, cũng
như khó kiểm thử và bảo trì
2. PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
Khác với phương pháp hướng cấu trúc chỉ tập trung hoặc vào dữ liệu hoặc vào
hành động, phương pháp hướng đối tượng tập trung vào cả hai khía cạnh của hệ
thống là dữ liệu và hành động. Cách tiếp cận hướng đối tượng là một lối tư duy
theo cách ánh xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực.
Với cách tiếp cận này, một hệ thống được chia tương ứng thành các thành phần
nhỏ gọi là các đối tượng, mỗi đối tượng bao gồm đầy đủ cả dữ liệu và hành động
liên quan đến đối tượng đó. Các đối tượng trong một hệ thống tương đối độc lập
với nhau và phần mềm sẽ được xây dựng bằng cách kết hợp các đối tượng đó lại
với nhau thông qua các mối quan hệ và tương tác giữa chúng. Các nguyên tắc cơ
bản của phương pháp hướng đối tượng bao gồm :
• Trừu tượng hóa (abstraction): trong phương pháp hướng đối
tượng, các thực thể phần mềm được mô hình hóa dưới dạng các đối tượng.
Các đối tượng này được trừu tượng hóa ở mức cao hơn dựa trên thuộc tính
21
và phương thức mô tả đối tượng để tạo thành các lớp. Các lớp cũng sẽ được
trừu tượng hóa ở mức cao hơn nữa để tạo thành một sơ đồ các lớp được kế
thừa lẫn nhau. Trong phương pháp hướng đối tượng có thể tồn tại những lớp
không có đối tượng tương ứng, gọi là lớp trừu tượng. Như vậy, nguyên tắc
cơ bản để xây dựng các khái niệm trong hướng đối tượng là sự trừu tượng
hóa theo các mức độ khác nhau.

• Tính đóng gói (encapsulation) và ẩn dấu thông tin: các
đối tượng có thể có những phương thức hoặc thuộc tính riêng (kiểu private)
mà các đối tượng khác không thể sử dụng được. Dựa trên nguyên tắc ẩn
giấu thông tin này, cài đặt của các đối tượng sẽ hoàn toàn độc lập với các
đối tượng khác, các lớp độc lập với nhau và cao hơn nữa là cài đặt của hệ
thống hoàn toàn độc lập với người sử dụng cũng như các hệ thống khác sử
dụng kết quả của nó.
• Tính modul hóa (modularity): các bài toán sẽ được phân chia
thành những vấn đề nhỏ hơn, đơn giản và quản lý được.
• Tính phân cấp (hierarchy): cấu trúc chung của một hệ thống
hướng đối tượng là dạng phân cấp theo các mức độ trừu tượng từ cao đến
thấp. Ưu điểm nổi bật của phương pháp hướng đối tượng là đã giải quyết
được các vấn đề nảy sinh với phương pháp hướng cấu trúc:
• Hỗ trợ sử dụng lại mã nguồn : Chương trình lập trình theo phương pháp
hướng đối tượng thường được chia thành các gói là các nhóm của các lớp
đối tượng khác nhau. Các gói này hoạt động tương đối độc lập và hoàn toàn
có thể sử dụng lại trong các hệ thống thông tin tương tự.
• Phù hợp với các hệ thống lớn: Phương pháp hướng đối tượng không chia
bài toán thành các bài toán nhỏ mà tập trung vào việc xác định các đối
tượng, dữ liệu và hành động gắn với đối tượng và mối quan hệ giữa các đối
tượng. Các đối tượng hoạt động độc lập và chỉ thực hiện hành động khi
nhận được yêu cầu từ các đối tượng khác. Vì vậy, phương pháp này hỗ trợ
phân tích, thiết kế và quản lý một hệ thống lớn, có thể mô tả các hoạt động
nghiệp vụ phức tạp bởi quá trình phân tích thiết kế không phụ thuộc vào số
22
biến dữ liệu hay số lượng thao tác cần thực hiện mà chỉ quan tâm đến các
đối tượng tồn tại trong hệ thống đó.
a. Các khái niệm cơ bản của hướng đối tượng
• Đối tượng (object): một đối tượng biểu diễn một thực thể vật lý, một thực thể
khái niệm hoặc một thực thể phần mềm. Có thể định nghĩa một đối tượng là một

khái niệm, sự trừu tượng hoặc một vật với giới hạn rõ ràng và có ý nghĩa với một
ứng dụng cụ thể.
• Lớp (Class): là mô tả của một nhóm đối tượng có chung các thuộc tính, hành vi
và các mối quan hệ. Như vậy, một đối tượng là thể hiện của một lớp và một lớp là
một định nghĩa trừu tượng của đối tượng.
• Thành phần (component): là một phần của hệ thống hoạt động độc lập và giữ
một chức năng nhất định trong hệ thống.
• Gói (package): là một cách tổ chức các thành phần, phần tử trong hệ thống thành
các nhóm. Nhiều gói có thể được kết hợp với nhau để trở thành một hệ thống con
(subsystem).
• Kế thừa: Trong phương pháp hướng đối tượng, một lớp có thể có sử dụng lại các
thuộc tính và phương thức của một hoặc nhiều lớp khác. Kiểu quan hệ này gọi là
quan hệ kế thừa, được xây dựng dựa trên mối quan hệ kế thừa trong bài toán thực
tế. Ví dụ, giải sử ta có lớp Người gồm các thuộc tính : tên, ngày sinh, quê quán,
giới tính ; Lớp Nhân Viên có quan hệ kế thừa từ lớp Người sẽ có tất cả các thuộc
tính trên và bổ sung thêm các thuộc tính mới gồm : chức vụ, lương.
Vòng đời phát triển phần mềm hướng đối tượng cũng có các pha tương tự như các
vòng đời phát triển phần mềm nói chung. Các pha cơ bản đặc trưng trong phát
triển phần mềm hướng đối tượng bao gồm:
• Phân tích hướng đối tượng: xây dựng một mô hình chính xác để mô tả hệ thống
cần xây dựng là gì. Thành phần của mô hình này là các đối tượng gắn với hệ thống
thực.
• Thiết kế hướng đối tượng: Là giai đoạn tổ chức chương trình thành các tập hợp
đối tượng cộng tác, mỗi đối tượng trong đó là thực thể của một lớp. Kết quả của
23
pha thiết kế cho biết hệ thống sẽ được xây dựng như thế nào qua các bản thiết kế
kiến trúc và thiết kế chi tiết.
• Lập trình và tích hợp: Thực hiện bản thiết kế hướng đối tượng bằng cách sử
dụng các ngôn ngữ lập trình hướng đối tượng (C++, Java, …).
b. Các bước phân ch thiết kế hướng đối tượng

Các bước phân tích thiết kế hướng đối tượng được xây dựng dựa trên biểu đồ các
ký hiệu UML. Đó là ngôn ngữ mô hình hoá thống nhất được xây dựng để mô hình
hoá quá trình phát triển hệ thống phần mềm hướng đối tượng.
Các bước phát triển hệ thống hướng đối tượng
Pha phân tích
- Xây dựng Biểu đồ use case: Dựa trên tập yêu cầu ban đầu, người
phân tích tiến hành xác định các tác nhân, use case và các quan hệ giữa các
24
use case để mô tả lại các chức năng của hệ thống. Một thành phần quan
trọng trong biểu đồ use case là các kịch bản mô tả hoạt động của hệ thống
trong mỗi use case cụ thể.
- Xây dựng Biểu đồ lớp: Xác định tên các lớp, các thuộc tính của lớp,
một số phương thức và mối quan hệ cơ bản trong sơ đồ lớp.
- Xây dựng biểu đồ trạng thái: Mô tả các trạng thái và chuyển tiếp
trạng thái trong hoạt động của một đối tượng thuộc một lớp nào đó.
Trong Pha thiết kế
- Xây dựng các biểu đồ tương tác (gồm biểu đồ cộng tác và biểu
đồ tuần tự): mô tả chi tiết hoạt động của các use case dựa trên các scenario
đã có và các lớp đã xác định trong pha phân tích.
- Xây dựng biểu đồ lớp chi tiết: tiếp tục hoàn thiện biểu đồ lớp
bao gồm bổ sung các lớp còn thiếu, dựa trên biểu đồ trạng thái để bổ sung
các thuộc tính, dựa trên biểu đồ tương tác để xác định các phương thức và
mối quan hệ giữa các lớp.
- Xây dựng biểu đồ hoạt động: mô tả hoạt động của các phương
thức phức tạp trong mỗi lớp hoặc các hoạt động hệ thống có sự liên quan
của nhiều lớp. Biểu đồ hoạt động là cơ sở để cài đặt các phương thức trong
các lớp.
- Xây dựng biểu đồ thành phần: xác định các gói, các thành phần
và tổ chức phần mềm theo các thành phần đó.
- Xây dựng biểu đồ triển khai hệ thống: xác định các thành

phần và các thiết bị cần thiết để triển khai hệ thống, các giao thức và dịch vụ
hỗ trợ.
25