Báo cáo bài tập quản trị quá trình triển khai hệ thống 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

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 4

I CÁC KHÁI NIỆM VỀ HỆ THỐNG THÔNG TIN 4

1 NHỮNG VẤN ĐỀ CƠ BẢN VỀ HỆ THỐNG THÔNG TIN 4

2 MÔ HÌNH HỆ THỐNG THÔNG TIN 6

II CÁC MÔ HÌNH XÂY DỰNG HỆ THỐNG THÔNG TIN 9

1 CÁC GIAI ĐOẠN PHÁT TRIỂN HỆ THỐNG THÔNG TIN 1 MÔ HÌNH THÁC NƯỚC (WATERFALL) 9

2 MÔ HÌNH TIẾN HÓA (EVOLUTIONARY) 11

3 MÔ HÌNH TĂNG TRƯỞNG (INCREMENTAL) 13

III PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN .15 1 PHÂN TÍCH THIẾT KẾ HƯỚNG (CẤU TRÚC) CHỨC NĂNG 15

2 PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 16

3 NGÔN NGỮ UML 20

IV CÁC TÁC NHÂN THAM GIA QUÁ TRÌNH PTTK 27

V CÁCH THỨC TỔ CHỨC, QUẢN TRỊ QUÁ TRÌNH PTTK 30

1 CÔNG TÁC CHUẨN BỊ 30

2 QUẢN TRỊ MODULES 30

3 QUẢN TRỊ NHÂN SỰ 31

4 QUẢN TRỊ CHẤT LƯỢNG 32

5 QUẢN TRỊ RỦI RO 32

PHẦN II: QUẢN TRỊ QUÁ TRÌNH TRIỂN KHAI HỆ THỐNG QUẢN LÝ THUẾ TẠI HÀ NỘI 34

1.1 Mục đích 5

1.2 Khái niệm, thuật ngữ 5

1.3 Mô tả tài liệu 6

2.1 Kiến trúc tổng thể hệ thống 6

2.2 Giải pháp triển khai tổng thể 8

2.2.1 Giải pháp triển khai ứng dụng Quản lý thuế cấp Tổng cục 8

2.2.2 Giải pháp triển khai các ứng dụng Quản lý thuế cấp Cục và Chi cục

2.3.3 Chuẩn bị về mạng và đường truyền 20

2.3.4 Backup dữ liệu Cục thuế trước triển khai 20

2.4 Các giải pháp triển khai chi tiết 21

2.4.1 Giải pháp cài đặt Database 21

2.4.2 Giải pháp cài đặt máy trạm 21

2.4.3 Giải pháp kiểm tra và xác nhận công việc triển khai 22

2.4.4 Giải pháp xử lý lỗi chương trình trong quá trình triển khai 22

2.5 Danh sách các đĩa cài đặt 22

3.1 Quy trình triển khai tại Tổng cục thuế 23

3.2 Quy trình triển khai tại Cục thuế 23

3.3 Quy trình triển khai tại Chi cục thuế Mô hình cục 25

3.4 Quy trình triển khai tại Chi cục thuế Mô hình VAT 26

4.1 Danh sách các điểm triển khai 27

PHẦN I: KIẾN THỨC CƠ BẢN VỀ QUẢN TRỊ PTTK 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.

 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

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…

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 Ệ THỐNG THÔNG TIN ỐNG THÔNG TIN

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

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

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

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

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,

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

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.

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

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.

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

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,

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 NG PHÁP PHÂN TÍCH THI T K H TH NG THÔNG TIN ẾT KẾ HỆ THỐNG THÔNG TIN ẾT KẾ HỆ THỐNG THÔNG TIN Ệ THỐNG THÔNG TIN ỐNG THÔNG TIN

1 PHÂN TÍCH THI T K H ẾN HÓA (EVOLUTIONARY) ẾN HÓA (EVOLUTIONARY) ƯỚC (WATERFALL) NG (C U TRÚC) CH C NĂNG ẤU TRÚC) CHỨC NĂNG Ứ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 đó

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 ẾN HÓA (EVOLUTIONARY) ẾN HÓA (EVOLUTIONARY) ƯỚC (WATERFALL) NG Đ I T ỐNG THÔNG TIN ƯỢNG 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

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ố

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

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 tí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

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

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

một số phương thức và mối quan hệ cơ bản trong sơ đồ lớ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ế

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

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.

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

và tổ chức phần mềm theo các thành phần đó.

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

3 NGÔN NG UML Ữ UML

a Tổng quan về UML

Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả James Rumbaugh, Grady Booch và Ivar Jacobson với chủ đích là:

- Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.

- Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá.

- Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau.

- Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy (biểu đồ)

UML được xây dựng để đặc tả, phát triển và viết tài liệu cho các khía cạnh trong phát triển phần mềm hướng đối tượng UML giúp người phát triển hiểu rõ và ra quyết định liên quan đến phần mềm cần xây dựng UML bao gồm một tập các khái niệm, các ký hiệu, các biểu đồ và hướng dẫn UML hỗ trợ xây dựng hệ thống hướng đối tượng dựa trên việc nắm bắt khía cạnh cấu trúc tĩnh và các hành vi động của hệ thống

- Các cấu trúc tĩnh định nghĩa các kiểu đối tượng quan trọng của hệ thống, nhằm cài đặt và chỉ ra mối quan hệ giữa các đối tượng đó.

- Các hành vi động (dynamic behavior) định nghĩa các hoạt động của các đối tượng theo thời gian và tương tác giữa các đối tượng hướng tới đích.

b UML và các giai đoạn phát triển của phần mềm

Giai đoạn nghiên cứu sơ bộ:

UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của khách hàng (người

sử dụng) UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống.

Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía

hệ thống (tức là Use case) Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case của UML Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng: Anh ta hay chị ta chờ đợi điều gì ở phía hệ thống mà không hề để ý đến việc chức năng này sẽ được thực thi ra sao.

Giai đoạn phân tích:

Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa đầu tiên (các lớp và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn đề Sau khi nhà phân tích

đã nhận biết được các lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được miêu tả bằng công cụ biểu đồ lớp (class diagram) của UML Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ được miêu tả nhờ vào các mô hình động (dynamic models) của UML Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa Các lớp kỹ thuật định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giao diện người dùng, cho ngân hàng dữ liệu, cho sự giao tiếp, trùng hợp, v.v , chưa phải là mối quan tâm của giai đoạn này

Giai đoạn thiết kế:

Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thành một giải pháp kỹ thuật Các lớp mới sẽ được bổ sung để tạo thành một hạ tầng cơ sở kỹ thuật: Giao diện người dùng, các chức năng để lưu trữ các đối tượng trong ngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi và các máy móc khác trong hệ thống, Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống.

Giai đoạn xây dựng:

Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng đối

tượng cụ thể (không nên dùng một ngôn ngữ lập trình hướng chức năng!) Phụ thuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một công việc khó khăn hay dễ dàng Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên cố gắng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòng code Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống; vì vậy, vội vàng đưa ra những kết luận

về việc viết code có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành code.

Thử nghiệm:

Một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thử nghiệm khác nhau Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu

đồ lớp (class diagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này.

c Các thành phần của UML

Ngôn ngữ UML bao gồm một loạt các phần tử đồ họa (graphic element) có thể được kếp hợp với nhau để tạo ra các biểu đồ Bởi đây là một ngôn ngữ, nên UML cũng có các nguyên tắc để kết hợp các phần tử đó

Một số những thành phần chủ yếu của ngôn ngữ UML:

Hướng nhìn (view): Hướng nhìn chỉ ra những khía cạnh khác nhau của hệ thống

cần phải được mô hình hóa Một hướng nhìn không phải là một bản vẽ, mà là một

sự trừu tượng hóa bao gồm một loạt các biểu đồ khác nhau Chỉ qua việc định nghĩa của một loạt các hướng nhìn khác nhau, mỗi hướng nhìn chỉ ra một khía cạnh riêng biệt của hệ thống, người ta mới có thể tạo dựng nên một bức tranh hoàn thiện về hệ thống Cũng chính các hướng nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn phát triển Một số hướng nhìn trong UML:

- Hướng nhìn Use case (use case view) : đây là hướng nhìn chỉ ra khía cạnh

chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.

- Hướng nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bên

trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động của hệ thống.

- Hướng nhìn thành phần (component view): chỉ ra khía cạnh tổ chức của

các thành phần code.

- Hướng nhìn song song (concurrency view): chỉ ra sự tồn tại song song/

trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong

hệ thống.

- Hướng nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệ

thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác).

Biểu đồ (diagram): Biểu đồ là các hình vẽ miêu tả nội dung trong một hướng nhìn.

UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống Một số biểu đồ:

- Biểu đồ Use case (Use Case Diagram): Một biểu đồ Use case chỉ ra một số

lượng các tác nhân ngoại cảnh và mối liên kết của chúng đối với Use case

mà hệ thống cung cấp (nhìn hình 3.2) Một Use case là một lời miêu tả của một chức năng mà hệ thống cung cấp Lời miêu tả Use case thường là một văn bản tài liệu, nhưng kèm theo đó cũng có thể là một biểu đồ hoạt động Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng), không miêu tả chức năng được cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao Các Use case định nghĩa các yêu cầu về mặt chức năng đối với

hệ thống.

- Biểu đồ lớp (Class Diagram): Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các

lớp trong hệ thống (nhìn hình 3.3) Các lớp là đại diện cho các “vật” được

xử lý trong hệ thống Các lớp có thể quan hệ với nhau trong nhiều dạng thức: liên kết (associated - được nối kết với nhau), phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), hay đóng gói ( packaged - hợp với nhau thành một đơn vị) Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation) Biểu đồ được coi là biểu

đồ tĩnh theo phương diện cấu trúc được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào trong toàn bộ vòng đời hệ thống.

- Biểu đồ đối tượng (Object Diagram): Một biểu đồ đối tượng là một phiên

bản của biểu đồ lớp và thường cũng sử dụng các ký hiệu như biểu đồ lớp.

Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp Một biểu đồ đối tượng vì vậy là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi: bức tranh mà hệ thống có thể có tại một thời điểm nào đó Biểu đồ đối tượng sử dụng chung các ký hiệu của biểu đồ lớp, chỉ trừ hai ngoại lệ: đối tượng được viết với tên được gạch dưới và tất

cả các thực thể trong một mối quan hệ đều được chỉ ra Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng có thể được sử dụng để ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và những mối quan hệ như thế thì bức tranh toàn cảnh sẽ ra sao Một biểu đồ đối tượng thường thường được sử dụng làm một thành phần của một biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động giữa một loạt các đối tượng.

- Biểu đồ trạng thái (State Diagram): Một biểu đồ trạng thái thường là một

sự bổ sung cho lời miêu tả một lớp Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái (hình 3.5) Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua đi – hay là một số điều kiện nào đó đã được thỏa mãn.

Một sự thay đổi trạng thái được gọi là một sự chuyển đổi trạng thái (State

Transition) Một chuyển đổi trạng thái cũng có thể có một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái này diễn ra Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng và thay đổi qua các trạng thái khác nhau Biểu

đồ trạng thái cũng có thể được vẽ cho hệ thống tổng thể Biểu đồ trạng thái được miêu tả chi tiết hơn trong chương sau (Mô hình động).

- Biểu đồ trình tự (Sequence Diagram): Một biểu đồ trình tự chỉ ra một

cộng tác động giữa một loạt các đối tượng (xem hình 3.6) Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) được gửi giữa các đối tượng Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống Các biểu đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ

Một biểu đồ trình tự cho Print Server

- Biểu đồ cộng tác (Collaboration Diagram): Một biểu đồ cộng tác chỉ ra

một sự cộng tác động, cũng giống như một biểu đồ trình tự Thường người

ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác Bên cạnh

việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), biểu đồ cộng

tác chỉ ra các đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh).

IV CÁC TÁC NHÂN THAM GIA QUÁ TRÌNH PTTK

Các tác nhân tham gia vào quá trình phân tích thiết kế hệ thống

 Đại diện khách hàng (Customer): Có vai trò đưa ra bài toán, các yêu cầu

đối với hệ thống, giúp bộ phận phân tích nghiệp vụ làm rõ các yêu cầu cụ thể chi tiết của khách hàng đối với phần mềm, cũng như hiện trạng sử dụng phần mềm của công ty Những người này thường là cán bộ CNTT lâu năm hiểu rõ quy trình nghiệp vụ của công ty hoặc các cán bộ nghiệp vụ có kiến thức về CNTT đảm nhiệm.

 Quản lý dự án (Project Manager): Là người chịu trách nhiệm toàn bộ dự

án Là người phụ trách điều hành hoạt động của bộ máy làm việc của toàn

bộ team work dựa trên nguồn nhân lực, các tài nguyên sẵn có của team Ngoài ra, PM còn phải có các kế hoạch dự phòng trong trường hợp các rủi

ro về phía khách hàng (thay đổi yêu cầu phần mềm) và phía team work (kế hoạch nhân sự thay đổi, các dự án chồng chéo …) PM cũng là người định

hướng kiến trúc hệ thống, cũng như cách tổ chức xây dựng hệ thống sao cho tối ưu, giảm thiểu rủi ro, và tuân theo các chính sách của doanh nghiệp.

 Phân tích nghiệp vụ (Bussiness Analyst): Có vai trò trách nhiệm phân tích

nghiệp vụ thực tế của khách hàng, trao đổi với khách hàng làm rõ các yêu cầu mong muốn của khách hàng đối với hệ thống Bộ phận này phải làm rõ được các yêu cầu nghiệp vụ, các hoạt động, luồng công việc (work flow) và cách thức giao tiếp của hệ thống đối với khách hàng

 Thiết kế phần mềm (Software Architect): Có vai trò thiết kế kỹ thuật hệ

thống Dựa trên các tài liệu được cung cấp từ bộ phận Phân tích nghiệp vụ,

bộ phận thiết kế phần mềm có nhiệm vụ xây dựng các tài liệu Usercase Diagram (các trường hợp người sử dụng), các sơ đồ trình tự luồng (Sequence Diagram), sơ đồ lớp và sự tương tác giữa các lớp, sơ đồ triển khai hệ thống, cơ sở dữ liệu dùng trong hệ thống.

 Lập trình viên (Developer): Dựa trên các tài liệu phân tích và thiết kế đặc

biệt là sơ đồ UserCase, các Developer sẽ thiết kế giao diện các chức năng của hệ thống Qua các giao diện mẫu này khách hàng có thể nhìn thấy và hình dung rõ hơn hệ thống.

 Kiểm thử viên (Tester): Dựa trên các tài liệu phân tích và thiết kế, giao

diện, bộ phận Tester sẽ lên các kịch bản test các trường hợp thông thường

và ngoại lệ Có thể phối hợp với phân tích nghiệp vụ và khách hàng để phân tích được rõ hơn các kịch bản.

V CÁCH TH C T CH C, QU N TR QUÁ TRÌNH PTTK ỨC TỔ CHỨC, QUẢN TRỊ QUÁ TRÌNH PTTK Ổ CHỨC, QUẢN TRỊ QUÁ TRÌNH PTTK ỨC TỔ CHỨC, QUẢN TRỊ QUÁ TRÌNH PTTK ẢN TRỊ QUÁ TRÌNH PTTK Ị QUÁ TRÌNH PTTK

1 CÔNG TÁC CHU N B ẨN BỊ Ị

a Lựa chọn mô hình

Là bước rất quan trọng Lựa chọn mô hình phát triển phần mềm sẽ quyết định các giai đoạn trong vòng đời của phần mềm (trong đó có giai đoạn PTTK) được tổ chức thực hiện như thế nào

Căn cứ vào các ưu điểm nhược điểm của từng mô hình phát triển cũng như đặc thù của hệ thống mà quản trị dự án đưa ra quyết định lựa chọn mô hình nào cho phù hợp.

b Lựa chọn phương pháp

Phương pháp phân tích thiết kế hệ thống quyết định tới tất cả các giai đoạn của quá trình PTTK, từ việc lên kế hoạch cũng như tổ chức thực hiện, kiểm tra kết quả Việc lựa chọn phương pháp phù hợp phụ thuộc vào mức độ quy mô của bài toán Với những bài toán quen thuộc, đã được xây dựng nhiều và chúng ta có những kinh nghiệm nhất định thì có thể lựa chọn phương pháp hướng chức năng Còn với những hệ thống lớn, với các mô tả chức năng chưa rõ ràng hoặc có tính linh động cao ta có thể lựa chọn phương pháp hướng đối tượng.

c Lựa chọn công cụ

Tùy từng phương pháp, mô hình mà ta lựa chọn công cụ xây dựng cho phù hợp Với phương pháp hướng chức năng, các lưu đồ quan trọng bao gồm sơ đồ chức năng, sơ đồ luồng dữ liệu … đối với phương pháp hướng đối tượng, phổ biến nhất hiện nay là sử dụng ngôn ngữ mô hình hóa UML, công cụ hỗ trợ xây dựng các mô hình có thể sử dụng Ration Rose, Enterprise Architect, MS Visio …

2 QU N TR MODULES ẢN TRỊ MODULES Ị

a Chia để trị

Dựa trên kế hoạch công việc của dự án, phân chia hệ thống thành các hệ thống nhỏ hơn (các module) Các module được phân chia dựa vào các yếu tố:

- Chức năng của module trong hệ thống (Thu thập dữ liệu, khai thác dữ liệu, đồng bộ dữ liệu …)

- Công nghệ, Database sử dụng để xây dựng module (dot Net, Java …)

- Phân loại nghiệp vụ của các module (ví dụ quản trị nhân sự, kế toán ngân hàng …)

- Đặc thù khác của module (triển khai 1 cấp, nhiều cấp …)

b Lập kế hoạch tiến độ và nhân sự

Dựa trên kế hoạch chung của hệ thống, các leader lên các kế hoạch tiến độ và nhân sự cho các module của mình, kế hoạch này được thảo luận kỹ lưỡng trước khi được quản lý dự án thông qua.

3 QU N TR NHÂN S ẢN TRỊ MODULES Ị Ự

a Trình độ nhân sự

- Trình độ chuyên môn, chuyên ngành, nghiệp vụ liên quan.

- Kinh nghiệm công tác.

- Hiệu quả công việc.

- Có kế hoạch bố trí nhân sự phù hợp với năng lực của cá nhân.

c Kế hoạch nhân sự

- Tổ chức các nhóm, phân công trưởng nhóm (leader) Trưởng nhóm phụ trách phân công công việc trong nhóm và chịu trách nhiệm báo cáo tiến độ chất lượng công việc của nhóm cho phụ trách dự án.

- Lập kế hoạch nhân sự dự phòng trong trường hợp bất khả kháng.

4 QU N TR CH T L ẢN TRỊ MODULES Ị ẤU TRÚC) CHỨC NĂNG ƯỢNG NG

a Lên kế hoạch kiểm tra

Có các kế hoạch kiểm tra chất lượng theo các giai đoạn khác nhau Định kỳ (hàng ngày, hàng tuần …) đột xuất (khi gặp các vấn đề đột xuất hoặc hóc búa), kiểm tra giai đoạn (đầu, giữa, kết thúc …)

b Phương pháp kiểm tra, đánh giá chất lượng

- Kiểm tra chéo: Các thành viên trong một nhóm hoặc giữa các nhóm với nhau có thể kiểm tra công việc lẫn nhau.

- Kiểm tra nội bộ: Các nhóm phụ trách các module nên dành ra khoảng thời gian định kỳ (ngày, 3 ngày, tuần …) để rà soát lại công việc đã thực hiện cũng như kết quả đạt được Các kết quả được ghi nhận lại trong biên bản kiểm tra.

- Sau mỗi giai đoạn thực hiện, thực hiện kiểm tra giai đoạn Các leader

sẽ báo cáo quản trị dự án kết quả, tiến độ hiện tại và các khó khăn trong quá trình thực hiện Các kết quả được ghi nhận lại trong biên bản kiểm tra.

5 QU N TR R I RO ẢN TRỊ MODULES Ị ỦI RO

a Rủi ro khách quan

Các rủi ro về khách hàng rất khó có thể kiểm soát Thường thì các rủi ro này là các rủi ro liên quan đến nghiệp vụ của hệ thống Các yêu cầu của khách hàng thường xuyên thay đổi trong suốt quá trình phân tích thiết kế, tuy nhiên đến một lúc nào đó các yêu cầu vượt quá giới hạn và gây rất nhiều khó khăn trong việc hệ thống hóa nó Khi đó cần phải xem xét và thương lượng lại với khách hàng Trong một số trường hợp, bắt đầu lại từ đầu là lựa chọn tốt nhất Vì vậy, trong thời gian đầu tiên của quá trình phân tích, cần phải lên được khung sườn chức năng của hệ thống trước, sau đó sẽ làm mịn dần các yêu cầu trong các giai đoạn tiếp theo.

b Rủi ro chủ quan

- Rủi ro về tiến độ: Đặt một số giới hạn về chậm tiến độ (ví dụ: bình thường, chậm, rất chậm …) và chuẩn bị các kế hoạch khi gặp phải các tình huống đó Các kế hoạch có thể là tăng thêm thời gian làm việc, tăng cường nhân sự, thay thế leader phù hợp hơn … Khi lập kế hoạch tiến độ cần để một thời gian dự phòng cho trường hợp chậm tiến độ (thông thường là khoảng 5% tổng thời gian)

- Rủi ro về chất lượng: Các kết quả thu được theo từng giai đoạn cần phải được xem xét đánh giá thường xuyên Lên kế hoạch định kỳ kiểm tra chất lượng theo thời gian (hàng ngày, hàng tuần …) và theo công việc (module, chức năng …) Thường xuyên duy trì các quan hệ với khách hàng để kịp thời điều chỉnh công việc theo đúng hướng.

- Rủi ro về nhân sự: Luôn có kế hoạch dự phòng về nhân sự Các tài liệu tuân theo các quy chuẩn của quy trình phân tích thiết kế để các nhân sự mới có thể tiếp cận công việc nhanh nhất.

PH N II: QU N TR QUÁ TRÌNH TRI N KHAI H TH NG ẦN II: QUẢN TRỊ QUÁ TRÌNH TRIỂN KHAI HỆ THỐNG ẢN TRỊ MODULES Ị ỂN KHAI HỆ THỐNG Ệ THỐNG THÔNG TIN ỐNG THÔNG TIN

QU N LÝ THU T I HÀ N I ẢN TRỊ MODULES ẾN HÓA (EVOLUTIONARY) ẠI HÀ NỘI ỘI

GIỚI THIỆU

Mục đích

Tài liệu này mô tả giải pháp và quy trình triển khai các ứng dụng Quản lý thuế tại 3 cấp củangành Thuế đáp ứng quy trình nghiệp vụ quy định trong các văn bản pháp quy đã được banhành trong năm 2011, bao gồm các ứng dụng:

Khái ni m, thu t ng ệm, thuật ngữ ật ngữ ữ