Đề tài Phân tích, thiết kế chương trình quản lý hợp đồng bảo hiểm tại phòng kinh doanh hàng hải thuộc công ty Bảo Hiểm Dầu Khí Việt Nam - Chi nhánh khu vực Tây Bắc

MỤC LỤC

MỤC LỤC 67

CHƯƠNG I: GIỚI THIỆU TỔNG QUAN VỀ CƠ SỞ THỰC TẬP VÀ ĐỀ TÀI NGHIÊN CỨU 1

1.1. Tổng quan về công ty bảo hiểm dầu khí Việt Nam 1

1.1.1. Lịch sử hình thành và phát triển 1

1.1.2. Chức năng của cơ quan 4

1.1.2.1. Các loại hình bảo hiểm 4

1.1.2.2. Hợp tác và tái bảo hiểm 6

1.1.2.3. Hoạt động đầu tư 6

1.1.3. Sơ đồ tổ chức của tổng công ty BHDK VN 7

1.1.4. Cơ cấu tổ chức và nhân sự chi nhánh BHDK – KV Tây Bắc 8

1.1.5. Sơ đồ tổ chức của chi nhánh công ty BHDK – KV Tây Bắc 8

1.1.6. Phòng ban nơi thực tập (P. Bảo hiểm Hàng hải) 9

1.1.6.1. Chức năng nhiệm vụ của phòng bảo hiểm Hàng Hải 9

1.1.6.2. Lĩnh vực kinh doanh bảo hiểm 10

1.1.6.3. Cơ cấu tổ chức nhân sự 10

1.1.6.4. Tình trạng trang bị tin học hoá của phòng BH Hàng Hải 10

1.2. Tổng quan về đề tài nghiên cứu 11

1.2.1. Lý do lựa chọn đề tài 11

1.2.2. Mô tả về đề tài 12

1.2.3. Phương pháp luận sử dụng để nghiên cứu 13

1.2.4. Kế hoạch để thực hiện đề tài 14

CHƯƠNG II: PHƯƠNG PHÁP LUẬN XÂY DỰNG HỆ THỐNG THÔNG TIN QUẢN LÝ HỢP ĐỒNG 15

2.1. Tổng quan về hệ thống thông tin 15

2.1.1. Thông tin 15

2.1.2. Hệ thống thông tin(HTTT) 16

2.1.2.1. Khái niệm về HTTT 16

2.1.2.2. Hệ thống thông tin quản lý 18

2.1.2.3. Phân loại HTTT trong tổ chức 18

2.1.2.4. Mô hình biểu diễn hệ thống thông tin 19

2.2. Nguyên nhân dẫn đến viếc phát triển một HTTT 21

2.2.1. Những vấn đề về quản lý 21

2.2.2. Yêu cầu của lãnh đạo 22

2.2.3. Yêu cầu của công nghệ 23

2.2.4. Sự thay đổi về sách lược chính trị 23

2.3. Mục đích xây dựng một HTTT 24

2.4. Phương pháp phát triển một HTTT 26

2.4.1. Giai đoạn đánh giá yêu cầu 27

2.4.2. Giai đoạn phân tích chi tiết 28

2.4.3. Thiết kế logic 32

2.4.4. Đề xuất các phương án của giải pháp 33

2.4.5. Thiết kế vật lý ngoài 34

2.4.6. Triển khai kỹ thuật hệ thống 34

2.4.7. Cài đặt, bảo trì và khai thác hệ thống 36

2.5. Giới thiệu về quản trị cơ sở dữ liệu Microsoft Access và ngôn ngữ lập trình Visual Basic 6.0 37

2.5.1. Hệ quản trị cơ sở dữ liệu Microsoft Access 37

2.5.2. Giới thiệu về Visual Basic 37

2.5.2.1. Lý do lựa chọn Visual Basic 6.0 37

CHƯƠNG III: PHÂN TÍCH VÀ THIẾT KẾ CHƯƠNG TRÌNH QUẢN LÝ HỢP ĐỒNG BẢO HIỂM 40

3.1. Tìm hiểu chung về nghiệp vụ và sản phẩm bảo hiểm 40

3.1.1. Quy trình khai thác hợp đồng bảo hiểm của nghiệp vụ viên (Cán bộ khai thác) 40

3.1.2. Mô tả thuộc tính, đối tượng các dịch vụ của BHDKVN (gọi chung là Công ty) 45

3.1.2.1. Mô tả Hợp đồng bảo hiểm và dịch vụ bảo hiểm của BHDKVN 45

3.1.2.2. Mô tả biểu phí 46

3.2. Xây dựng hệ thống quản lý hợp đồng bảo hiểm tại chi nhánh BHDK-KV Tây Bắc 47

3.2.1. Khảo sát và phân tích 47

3.2.1.1. Thực trạng và các vấn đề xem xét 47

3.2.1.2. Những yêu cầu đặt ra cho bài toán quản lý hợp đồng 48

3.2.2. Phân tích hệ thống quản lý hợp đồng Bảo hiểm tại BHDK-chi nhánh KV Tây Bắc 49

3.2.2.1. Sơ đồ luồng thông tin IFD (Information Flow Diagram) hệ thống thông tin quản lý hợp đồng bảo hiểm 49

3.2.2.2. Sơ đồ luồng dữ liệu DFD (Data Flow Diagram) hệ thống thông tin quản lý hợp đồng 51

3.2.3. Thiết kế cơ sở dữ liệu trên Microsoft Access 2003 53

3.2.3.1. Bảng CanBo 53

3.2.3.3. Bảng HoaHong 53

3.2.3.2. Bảng DichVu 54

3.2.3.4. Bảng HopDong 54

3.2.3.5. Bảng KhachHang 56

3.2.3.7. Bảng ThuPhi 56

3.2.3.8. Bảng DieuKhoan 57

3.2.4. Thiết kế giao diện 59

 

doc69 trang | Chia sẻ: maiphuongdc | Ngày: 30/10/2013 | Lượt xem: 1573 | Lượt tải: 4download
Bạn đang xem nội dung tài liệu Đề tài Phân tích, thiết kế chương trình quản lý hợp đồng bảo hiểm tại phòng kinh doanh hàng hải thuộc công ty Bảo Hiểm Dầu Khí Việt Nam - Chi nhánh khu vực Tây Bắc, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
ể được mô tả theo nhiều cách khác nhau, khái niệm mô hình rất quan trọng vì nó tạo ra một trong những nền tảng của phương pháp phân tích thiết kế và cài đặt hệ thống thông tin. Có ba mô hình được dùng để mô tả hệ thống thông tin: Mô hình logic, mô hình vật lý ngoài, mô hình vật lý trong. Mô hình logic (Góc nhìn quản lý) Mô hình vật lý ngoài (Góc nhìn sử dụng) Mô hình vật lý trong (Góc nhìn kỹ thuật) Mô hình ổn định nhất Mô hình hay thay đổi nhất Cái gì? Để làm gì? Cái gì? Ở đâu? Khi nào? Như thế nào? Mô hình biểu diễn một hệ thống thông tin Mô hình logic: Mô tả hệ thống làm gì, dữ liệu mà nó thu thập xử lý phải thực hiện, các kho để chứa các kết quả hoặc dữ liệu để lấy ra cho các xử lý phải thực hiện, các kho để chứa các kết quả hoặc dữ liệu để lấy ra cho các xử lý và những thông tin mà hệ thống sản sinh ra. Mô hình này trả lời các câu hỏi “cái gì” và “để làm gì?” chứ nó không quan tâm đến phương tiện được sử dụng cũng như địa điểm hay thời điểm mà dữ liệu được xử lý. Mô hình vật lý ngoài: Chú ý tới những khía cạnh nhìn thấy được hệ thống như: vật mang dữ liệu và vật mang kết quả cũng như hình thức đầu vào và đầu ra, phương tiện để thao tác với hệ thống, những dịch vụ, bộ phận, con người và vị trí công tác trong hoạt động xử lý, các thủ tục thủ công cũng như các yếu tố về địa điểm thực hiện xử lý dữ liệu, loại màn hình, bàn phím sử dụng. Mô hình này cũng chú ý tới mặt thời điểm mà các hoạt động xử lýdữ liệu cùng xảy ra. Nó trả lời câu hỏi: Cái gì? Ai? Ở đâu? Khi nào? Mô hình vật lý trong: liên quan tới những khía cạnh vật lý của hệ thống tuy nhiên không phải là cái nhìn của người sử dụng mà là của nhân viên kỹ thuật. Chẳng hạn đó là thông tin liên quan tới trang thiết bị được dùng để thể hiện hệ thống dung lượng kho lưu trữ và tốc độ xử lý của các thiết bị, tổ chức vật lý của dữ liệu trong kho chứa, cấu trúc các chương trình và ngôn ngữ thể hiện. Mô hình trả lời câu hỏi: Như thế nào? Cả ba mô hình đều có độ ổn định khác nhau trong đó mô hình logic có độ ổn định cao nhất và hay thay đổi nhiều nhất là mô hình vật lý trong. Trong một HTTT, với một mô hình vật lý ngoài có thể tồn tại nhiều mô hình vật lý trong tương ứng nên dựa vào thực tế chi phí, hiệu quả kỹ thuật và nhiều yếu tố liên quan để xét duyệt và lựa chọn mô hình vật lý trong sao cho phù hợp. Một HTTT thường được mô tả theo ba mô hình sau: Lưu trữ dữ liệu Logic Vật lý ngoài Vật lý trong Logic Vật lý ngoài Vật lý trong Logic Vật lý ngoài Vật lý trong Thông tin ra Thông tin vào Logic Vật lý ngoài Vật lý trong Đích Nguồn Một HTTT theo ba mô hình 2.2. Nguyên nhân dẫn đến viếc phát triển một HTTT 2.2.1. Những vấn đề về quản lý Trước khi có máy tính, vấn đề quản lý đối với một doanh nghiệp thực sự là rất khó khăn và phức tạp. Ví dụ như việc truyền yêu cầu và mệnh lệnh từ giám đốc tới nhân viên sẽ phải thông qua nhiều người, tốn nhiều thời gian, thậm chí có thể bị sia lệch về nội dung. Trong khi đó nếu sử dụng HTTT trong doanh nghiệp và sự kết nối mạng, thông tin sẽ được truyền đi một cách nhanh chóng và chính xác, người quản lý có thể truyền mệnh lệnh trực tiếp cho cá nhân phụ trách công việc. Ngoài vấn đề về truyền đạt các yêu cầu và mệnh lệnh, vấn đề cập nhật thông tin như chính sách thuế, thông tin về khách hàng… cũng được thực hiện nhanh chóng và chính xác hơn. Căn cứ vào thông tin được cập nhật cán bộ quản lý có thể ra những quyết định nhanh chóng mang tính chiến lược. Ngày nay, cùng với sự phát triển rất nhanh của xã hội thì quy mô các doanh nghiệp cũng phát triển với tốc độ tương tự. Các tổ chức doanh nghiệp lớn không chỉ làm việc tại một cơ sở mà ở nhiều cơ sở, nhiều chi nhánh và đại lý ở khắp trong và ngoài nước, tuy vậy trụ sở chính thì chỉ ở một nơi. Do vậy việc quản lý ngày càng trở nên cực kỳ phức tạp. Vậy yêu cầu đặt ra là làm sao để các nhà quản lý có thể ngồi một chỗ mà vẫn có thể uản lý được mọi hoạt động của cơ quan? Để làm được điều đó bắt buộc người quản lý phải dựa vào công nghệ tin học, một HTTT hiện đại sẽ là phương pháp hữu hiệu nhất trong trường hợp này. 2.2.2. Yêu cầu của lãnh đạo Những yêu cầu mới của nhà quản lý cũng có thể dẫn đến sự cần thiết phát triển một HTTT mới. Người lãnh đạo trong cơ quan thì luôn cần các công cụ hỗ trợ cho hoạt động quản lý của mình. Với một HTTT có tính chuyên nghiệp và hiệu quả sẽ là một công cụ trợ giúp đắc lực cho các nhà lãnh đạo. Các quyết định của nhà lãnh đạo liên quan trực tiếp đến sự thành công hay thất bại của cơ quan. Để có được các quyết định đúng đắn thì nhf lãnh đạo cần những căn cứ xác đáng, các nguồn thông tin nội bộ hay bên ngoài đầy đủ và chính xác. Nếu có được một HTTT quản lý tốt thì việc thu thập thông tin sẽ trở nên đơn giản hơn nhiều. 2.2.3. Yêu cầu của công nghệ Áp dụng công nghệ tiên tiến vào trong quản lý không chỉ của riêng cơ quan, doanh nghiệp nào mà là một nhu cầu bắt buộc chung của xã hội. Trên thực tế, công nghệ tiên tiến hiện đại cũng la một lợi thế thương mại của các công ty. Đặc biệt trong những năm gần đây, lợi thế thương mại này được cạnh tranh một cách gay gắt và trở thành cuộc chạy đua công nghệ trong các doanh nghiệp. Sự thành, bại của các doanh nghiệp cũng phụ thuộc cơ bản vào việc doanh nghiệp đó có áp dụng công nghệ tiên tiến nhất hay không? Nói đến việc áp dụng công nghệ mới thì chúng ta không thể chỉ nói đến công nghê trong sản xuất ma phải áp dụng cả trong công tác quản lý. Việc xuất hiện các công nghệ mới cũng có thể dẫn đến việc một tổ chức phải xem lại những thiết bị hiện có trong tổ chức của mình. Khi các hệ quản trị cơ sở dữ liệu ra đời nhiều tổ chức phải rà soát lại HTTT của mình để quyết định những gì họ sẽ phải cài đặt, phải thay đổi khi muốn sử dụng những công nghệ mới này. Tuy nhiên sự thay đổi như vậy không thể thực hiện một cách nhanh chóng được, nó sẽ làm sáo trộn hệ thống quản lý cũng như sản xuất của tổ chức. Muốn vậy ta có thể áp dụng từ từ hệ thống mới để người sử dụng có thể làm quen với sự thay đổi và những chức năng hiện đại hơn. Cũng có những HTTT được phát triển chỉ vì người quản lý muốn mở rộng quyền lực của mình bởi vì ông ta biết rằng thông tin là một phương tiện có thể thực hiện điều đó. 2.2.4. Sự thay đổi về sách lược chính trị Một nguyên nhân rất quan trọng buộc các tổ chức phải thay đổi HTTT cũ đó là các chính sách của nhà nước. Các chính sách được đưa ra mang tính cưỡng chế thi hành và không có sự lựa chọn. Chính vì vậy các tổ chức không thể không thay đổi, phát triển HTTT của mình. Hiện nay nhà nước đang có chủ trương xây dựng “chính phủ điện tử” nên việc tin học hoá công tác quản lý của các tổ chức là vô cùng cần thiết. Tuy nhiên việc người ta nhận ra yêu cầu phát triển HTTT rõ rang là chưa đủ để bắt đầu sự phát triển này. Trong phần lớn các tổ chức, có các cơ chế chính thức đang tồn tại, để xác định liệu một nghiên cứu phát triển về HTTT có nên được thực hiện hay không. Vấn đề là một yêu cầu đơn giản gửi tới từ một bộ phận hoặc một phòng ban đến lãnh đạo các bộ phận tin học của một tổ chức, những người này chịu trách nhiệm quyết định yêu cầu có thể chấp nhận được không? Bởi vì tình trạng như vậy có thể được xem như là để ngỏ, nhiều tổ chức đặt ra một hội đồng tin học được ccấu thành từ người chịu trách nhiệm về tin học cùng với những người chịu trách nhiệm về các chức năng chính của tổ chức. Cách thức này đảm bảo mọi khía cạnh đều được xem xét khi một quyết định được đưa ra. Quyết định của hội đồng hoặc của người chịu trách nhiệm về tin học trong một số trường hợp, có thể không bắt buộc phải dẫn tới việc cài đặt một hệ thống mới, nó chỉ mới khởi động một dự án phát triển. Suốt quá trình của dự án, người ta phải xem lại quyết định này có nghĩa là phải xác định xem sẽ tiếp tục dự án hay kết thúc nó. 2.3. Mục đích xây dựng một HTTT Một HTTT tốt luôn là công cụ hỗ trợ đắc lực trong quản lý và sản xuất. Đó chính là lý do và mục tiêu duy nhất để xây dựng và phát triển một hệ thống. Vậy có những tiêu chuẩn nào có thể đánh giá một hệ thống là tốt? Ta có thể căn cứ vào sự thuận tiện của hệ thống, tính than thiện của nó…nhưng quan trọng nhất vẫn là những gì mà nó cung cấp. Thông tin đầu ra là một hệ thống cung cấp phải đảm bảo thoả mãn được yêu cầu của người sử dụng. Tiêu chuẩn để đánh giá thông tin là: Độ tin cậy thể hiện các mặt về tính xác thực và độ chính xác. Thông tin ít độ tin cậy sẽ gây cho tổ chức những hậu quả tồi tệ. Chẳng hạn hệ thống lập hoá đơn bán hàng có nhiều sai sót, nhiều khách hàng kêu ca về tiền phải trả ghi cao hơn giá trị hàng đã thực mua sẽ dẫn đến hình ảnh xấu về cửa hàng, lượng khách hàng sẽ giảm và doanh số bán sẽ giảm xuống. Nếu số tiền ghi trên hoá đơn thấp hơn số tiền phải trả thì cửa hàng sẽ bị thất thu. Tính đầy đủ của thông tin thể hiện sự bao quát các vấn đề đáp ứng yêu cầu của nhà quản lý. Nhà quản lý sử dụng một thông tin không đầy đủ có thể dẫn đến các quyết định và hành động không đáp ứng được với đòi hỏi của tình hình thực tế. Ví dụ một nhà sản xuất ghế tựa yêu cầu báo cáo về số lượng ghế làm ra mỗi tuần. Để so sánh, báo cáo cũng có nêu ra số lượng ghế làm ra mõi tuần trước đó và của cùng kì năm trước. Ông chủ thấy số lượng ghế là ra tăng đều và có thể sẽ cho rằng tình hình sản xuất là tốt đẹp. Tuy nhiên trong thực tế có thể hoàn toàn khác, HTTT chỉ cung cấp số lượng ghế sản xuất mà không phản ánh về năng suất. Một sự không đầy đủ của HTTT như vậy sẽ gây thiệt hại cho doanh nghiệp. Tính thích hợp và dễ hiểu Nhiều nhà quản lý không muốn sử dụng một số loại báo cáo mặc dù chúng liên quan tới các hoạt đọng thuộc trách nhiệm của ông ấy. Nguyên nhân chủ yếu là do chúng chưa thích hợp và khó hiểu. Có thể là có quá nhiều thông tin chưa thích ứng, thiếu sự sang sửa, sử dụng quá nhiều từ viết tắt hoặc đa nghĩa hoặc bố trí chưa hợp lý của các trường thông tin. Điều đó dẫn đến hoặc là tốn phí cho việc tạo ra nhưng thông tin không dùng hoặc là ra quyết định sai và thiếu thông tin cần thiết. Tính được bảo vệ thông tin là một nguồn lực quý báu của một tổ chức cũng như vốn và nguyên vật liệu. Thật hiếm có doanh nghiệp nào mà bất kỳ ai cũng có thể tiếp cận được tới vốn hoặc nguyên liệu, và cũng phải làm như vậy đối với thông tin. Thông tin phải được bảo vệ và chỉ những người được quyền mới được phép tiếp cận tới thông tin. Sự thiếu an toàn về thông tin cũng có thể gây ra những thiệt hại lớn cho tổ chức. Tính kịp thời thông tin có thể là tin cậy, dễ hiểu và thích ứng và được bảo vệ an toàn nhưng vẫn không có ích khi nó không được gửi tới người sử dụng vào lúc cần thiết. Một công đoàn có thể biểu tình nếu việc phiếu trả lương phát chậm nhiều lần, một cửa rút tiền tự động có thời gian trả lời tới 5 phút thì sẽ mất khách hàng rất nhanh. Làm thế nào để một hệ thống thông tin hoạt động tốt có hiệu qủ cao là một trong những cong việc của bất kì một nhà quản lý hiện đại nào. Để giải quyết vấn đề đó cần phải xem xét cơ sở kỹ thuật cho các hệ thống thông tin, phương pháp phân tích thiết kế và cài đặt hệ thống thông tin. Trên đây là những tiêu chuẩn để đánh giá một hệ thống thông tin trong doanh nghiệp nói chung, nhưng tuỳ từng doanh nghiệp áp dụng hệ thống thông tin mà nó sẽ có thêm những tiêu chuẩn riêng khác nhau. Riêng đối với Công ty Bảo hiểm Dầu khí – chi nhánh KV Tây Bắc thì đòi hỏi một hệ thống thông tin tốt là phải đáp ứng được các yêu cầu sau: Luôn cập nhật thông tin kịp thời, cho phép đưa ra báo cáo chính xác tại mọi thời điểm. Phần mềm phải có giao diện đẹp, hài hoà và thân thiện. Phần mầm phải có tính dễ sử dụng và tính bảo mật cao. 2.4. Phương pháp phát triển một HTTT Mục đích của việc xây dựng, phát triển HTTT là có được một sản phẩm đáp ứng nhu cầu của người sử dụng, hoà nhập vào các hoạt đọng của tổ chức, chính xác về mặt kỹ thuật, tuân thủ các giới hạn về tài chính và thời gian định trước. Không nhất thiết phải theo đuổi một phương pháp để phát triển một HTTT, tuy nhiên nếu không có phương pháp ta có nguy cơ không đạt được những mục tiêu đã đặt trước. Một HTTT là một đối tượng phức tạp, vận đọng trong một môi trường rất phức tạp. Để thực sự làm chủ được nó, cần có một phương pháp để tiến hành. Sau đây là các công đoạn xây dựng, phát triển một HTTT. 2.4.1. Giai đoạn đánh giá yêu cầu Một dự án phát triển hệ thống không tự động tiến hành ngay sau khi có bản yêu cầu vì loại hình dự án này đòi hỏi đầu tư không chỉ tiền bạc, thời gian mà còn cả nguồn nhân lực và chất xám. Do đó việc quyết định vấn đề này phải được thực hiện sau khi phân tích cho phép xác định cư hội và khả năng thực thi. Sự phân tích này được đánh giá hay thẩm định yêu cầu hay còn gọi là nghiên cứu khả thi và cơ hội. Đánh giá đúng yêu cầu là yếu tố quyết định cho sự thành công của một dự án. Chỉ cần một sai lầm nhỏ cũng có thể gây ra hao tổn tiền bạc, nhân lực hay đẩy lùi tiến trình thực hiện dự án, thậm chí có thể phá hỏng dự án. Đánh giá yêu cầu được bắt đầu từ việc nêu vấn đề, ước đoán độ lớn của dự án và những thay đổi có thể, đánh giá tác động cuả những thay đổi và tính khả thi của dự án, những gợi ý hỗ trợ cho người ra quyết định. Giai đoạn này được tiến hành trong thời gian tương đối ngắn để tiết kiệm chi phí về thời gian và tiền của. Giai đoạn này bao gồm các công việc cụ thể như sau: Lập kế hoạch: Gồm các công việc như làm quen với hệ thống đang xét, xác đinh thông tin cần thu thập cũng như nguồn và phương pháp thu thập. Làm rõ yêu cầu: Giúp cho phân tích viên hiểu rõ yêu cầu của khách hàng, xác định chính xác đối tượng yêu cầu, thu thập những yếu tố cơ bản của môi trường hệ thống và định dạng khung cảnh nghiên cứu. Đánh giá khả thi: Tìm xem có những yếu tố nào ngăn cản sự thành công của dự án, đánh giá khả thi về tổ chức, về tài chính, về thời hạn và kỹ thuật. Chuẩn bị và trình bày báo cáo đánh giá yêu cầu. 2.4.2. Giai đoạn phân tích chi tiết Đây là giai đoạn giúp cho cán bộ phân tích hiểu sâu sắc và toàn vẹn về hệ thống thông tin đàn tồn tại – nghĩa là xác định được những vấn đề chính cũng như các yêu cầu nảy sinh của chúng, xác định được các công việc phải làm, các công cụ được sử dụng cũng như mục tiêu cần đạt được của hệ thống mới. Các công việc cần thực hiện trong giai đọcn này bao gồm: 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. Chuẩn đoán và xác định các yếu tố giải pháp. Đánh giá lại tính khả thi. Sửa đổi đề xuất của dự án. Chuẩn bị và trình bày báo cáo phân tích chi tiết. Để có thể nghiên cứu chính xác được môi trường của hệ thống cũ. Các phương pháp thu thập thông tin gồm: + Phỏng vấn: Đây là công cụ đắc lực, ta có thể thu được những nội dung cơ bản khái quát về hệ thống mà tài liệu không thể có được hay gặp được những người có trách nhiệm, nắm được mục tiêu của tổ chức. + Sử dụng phiếu điều tra: Phương pháp này sử dụng khi phải lấy thông tin từ một số lượng lớn các đối tượng và trên phạm vi điạ lý rộng lớn. Nhưng để vận dụng phương pháp này thì người gửi thường phải là những người cấp trên của các đối tượng nhận phiếu. + Quan sát: Đây là phương pháp khó khăn và tốn thời gian vì người bị quan sát có thể hoạt động không giống thực tế mà người sử dụng có vai trò rất quan trọng khi tham gia vào đội ngũ phân tích. Sau bước thu thập thông tin, dữ liệu được tập chung và được chuẩn bị cho việc phân tích. Nhưng trước khi phân tích những dữ liệu này nhất thiết phải mã hoá. Mã hoá được xem là việc xây dựng một tập hợp những hàm thức mang tính quy ước và gán cho tập hợp này một ý bằng cách cho liên hệ với tập hợp những đối tượng cần biểu diễn. Hay nói một cách khác, việc mã hoá thông tin là thay thế thông tin ở dạng “tự nhiên” thành một dãy kí hiệu thích ứng với mục tiêu của người sử dụng. Mục tiêu đó là nhận diện nhanh và không nhầm lẫn các đối tượng, mô tả nhanh chóng các đối tượng, tiết kiệm không gian lưu trữ và thời gian xử lý, thực hiện những phép kiểm tra logic hình thức hoặc thể hiện vài đặc tính của đối tượng. Các phương pháp mã hoá cơ bản - Phương pháp mã hoá phân cấp - Phương pháp mã hoá liên tiếp - Phương pháp mã hoá tổng hợp - Phương pháp mã hoá theo seri - Phương pháp mã hoá gợi nhớ - Phương pháp mã hoá ghép nối Cách thức tiến hành mã hoá Xác định tập hợp các đối tượng cần mã hoá Xác định các xử lý cần thực hiện Lựa chọn giải pháp mã hoá + Xác định lựa chọn đẳng cấp các tiêu chuẩn lựa chọn. + Kiểm tra lại những bộ mã hiện hành. + Tham khảo ý kiến của người đã sử dụng. + Kiểm tra độ ổn định của các thuộc tính. + Kiểm tra khả năng thay đổi của các đối tượng. Các công cụ sử dụng trong giai đoạn phân tích chi tiết Để có cái nhìn tổng quát đối với một HTTT, cán bộ phân tích phải tiến hành mô hình hoá hệ thống đó. Có nghĩa là phải biểu diễn hệ thống đó dưới dạng các mô hình, sơ đồ hay hình hoạ nhằm giúp cho tất cả mọi người có thể hiểu một cách tổng quát và nhanh chóng đối với hệ thống. Hiện nay có các công cụ phổ biến để mô hình hoá hệ thống đó là: Sơ đồ luồng thông tin (Information Flow Diagram - IFD), sơ đồ luông dữ liệu (Data Flow Diagram). Sơ đồ luông thông tin (IFD) Tin học hoá hoàn toàn Giao tác người - máy Thủ công Xử lý Kho lưu trữ dữ liệu Tin học hoá Thủ công - Điều khiển - Dòng thông tin Tài liệu Các phích vật lý Phích luồng thông tin Phích kho chứa dữ liệu Phích chứa xử lý Sơ đồ luông dữ liệu (DFD) DFD dùng để mô tả chính HTTT nhưng trên góc độ trừu tượng. Trên sơ đồ chỉ bao gồm các luông dữ liệu, các xử lý, các lưu trữ dữ liệu, nguồn và đích nhưng không hề quan tâm tới nơi, thời điểm và đối tượng chịu trách nhiệm xử lý. Sơ đồ IFD chỉ đơn thuần mô tả hệ thống làm gì? và để làm gì? Tên người/bộ phận phát nhận thông tin Các kí pháp dùng cho DFD Nguồn hoặc đích Tên dòng dữ liệu - Dòng dữ liệu Tên tiến trình xử lý - Tiến trình xử lý Tệp dữ liệu - Kho dữ liệu Các mức của DFD Sơ đồ ngữ cảnh (Context diagram) thể hiện nội dung tổng quát nhất của hệ thống thông tin. Trong sơ đồ này có thể bỏ qua các xử lý cập nhật, các kho dữ liệu. Sơ đồ ngữ cảnh hay còn gọi là sơ đồ mức 0. Sơ đồ phân rã: nhằm mô tả chi tiết hơn nội dung của hệ thống. Bắt đầu từ sơ đồ ngữ cảnh, sẽ phân rã thành sơ đồ mức 0, mức 1, 2… Các phích logic Phích luồng dữ liệu Phích phần tử thông tin Phích kho dữ liệu Phích tệp dữ liệu 2.4.3. Thiết kế logic Mục đích của công đoạn này là xác định một cách chi tiết và chính xác những gì hệ thống mới phải làm để đạt được những mục tiêu đã thiết lập từ giai đoạn trước. Sản phẩm cuối cùng của giai đoạn này là các sơ đồ luồng dữ liệu DFD, các sơ đồ cấu trúc dữ liệu DSD, các sơ đồ phân tích và tra cứu, các phích logic của từ điển hệ thống. Các công việc chính của giai đoạn này gồm: Thiết kế cơ sở dữ liệu Thiết kế xử lý Thiết kế các dòng vào Hoàn chỉnh tài liệu logic Hợp thức hoá mô hình logic Thiết kế cơ sở dữ liệu là công việc rất khó khăn và phức tạp, bởi phân tích viên sẽ phải gặp gỡ những người sử dụng và hỏi họ danh sách dữ liệu mà họ cần. Việc hỏi han này thường không đạt hiệu quả cao và sẽ dễ dàng làm cho hệ thống có những phần không đạt yêu cầu. Để khắc phục tình trạng này, phân tích viên bắt buộc phải phân tích kĩ lưỡng cơ sở dữ liệu của hệ thống, thậm chí có thể phải làm việc đơn độc và sẽ tuỳ từng trường hợp mà có những phương pháp thu thập thích hợp. Tuy nhiên phân tích viên có thể áp dụng một trong những phương pháp sau: Thiết kế dữ liệu từ các thông tin đầu ra: đây là phương pháp cổ điển và cơ bản của việc thiết kế cơ sở dữ liệu.Phương pháp này dựa trên các văn bản hay báo cáo đầu ra để từ đó xác định các trường dữ liệu cần thiết. Vấn đề quan trọng nhất của phương pháp này là áp dụng các chuẩn hoá trong quá trình lọc dữ liệu. Các mức chuẩn hoá như sau: Chuẩn hoá mức 1: mỗi danh sách không được phép chứa những thuộc tính lặp. Nếu có các thuộc tính lặp thì phải tách các thuộc tính lặp đó thành các danh sách con, có một ý nghĩa dưới góc độ quản lý đồng thời gắn tên và thuộc tính định danh riêng cho nó. Chuẩn hoá mức 2: Trong một danh sách mỗi thuộc tính phải phụ thuộc hàm vào toàn bộ khóa chứ không chỉ phụ thuộc vào một phần của khoá. Nếu có sự phụ thuộc như vậy thì phải tách những thuộc tính đó thành một danh sách con mới. Chuẩn hoá mức 3: Trong một danh sách không được phép có sự phụ thuộc bắc cầu giữa các thuộc tính. Phải tách chúng thành các thuộc tính riêng rẽ, gán tên và xác định khóa cho chúng. Thiết kế cơ sở dữ liệu bằng phương pháp mô hình hoá: Đây là phương pháp dựa trên sự thể hiện giữa các thực thể với nhau thông qua các liên kết. Sự thể hiện này được biểu diễn trên mô hình quan hệ thực thể. Mối quan hệ giữa các thực thể với nhau có thể dưới dạng một - một (1@1), một - nhiều (1@N), nhiều - nhiều (N@N). 2.4.4. Đề xuất các phương án của giải pháp Cho tới giai đoạn này cán bộ tin học đã có thể xác định được những xử lý, cơ sở dữ liệu cần có của hệ thống và nhiệm vụ cần đạt được của hệ thống mới. Tuy nhiên họ vẫn chưa biết được cách thức xử lý nào được dùng là hợp lý nhất, phương tiện nào thích hợp, có tính khả thi nhất và môi trường của HTTT là như thế nào? Đây cũng chính là mục đích mà cán bộ tin học cần đạt được trong giai đoạn này. Cụ thể họ sẽ phải làm những công việc như sau: Xác định các rang buộc tin học và tổ chứ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. Công việc quan trọng nhất của giai đoạn này là đánh giá phương án của giải pháp. Bởi thực chất đó là quá trình phân tích, đánh giá chi phí và lợi ích của phương pháp. Kết quả của việc đánh giá này sẽ quyết định dự án có được tiếp tục triển khai nữa hay không, hay phải hay đổi theo phương pháp thực hiện khác. Nếu như việc đánh gía bị sai lệch thì sẽ gây hao tổn rất lớn và ảnh hưởng mạnh tới kết quả về sau của dự án. 2.4.5. Thiết kế vật lý ngoài Thực chất của giai đoạn thiết kế vật lý ngoài là mô tả chi tiết phương án của giải pháp đã được lựa chọn ở giai đoạn trước. Đó là những mô tả về giao diện, về các thao tác người sử dụng sẽ cần sử dụng đến. Thiết kế cách thức tiếp cận hệ thống… Kết quả của giai đoạn thiết kế vật lý ngoài sẽ tác đọng đén việc dự án có được người tiêu dùng chọn lựa và áp dụng lâu dài hay không? Bởi vì đối với người sử dụng giao diện thân thiện, thao tác dễ dàng, dễ hiểu là một tiêu chuẩn đánh giá rất quan trọng. Cụ thể phân tích viên sẽ phải thực hiện các công việc như sau: Lập kế hoạch thiết kế vật lý ngoài. Thiết kế chi tiết các giao diện vào ra. Thiết kế cách thức tương tác với phần tin học hoá. Thiết kế các thủ tục thủ công. Chuẩn bị và trình bày báo cáo. 2.4.6. Triển khai kỹ thuật hệ thống Triển khai kỹ thuật hệ thống thông tin là thực hiện việc lựa chọn công cụ phát triển hệ thống, tổ chức vật lý của cơ sở dữ liệu, cách thức truy nhập tới các bản ghi của các tệp và những chương trình máy tính khác nhau cấu thành nên hệ thống. Mục tiêu chính của giai đoạn này là xây dựng một hệ thống hoạt đọng tốt. Những công việc chính của giai đoạn này gồm: Lập kế hoạch triển khai. Thiết kế vật lý trong. Lập trình. Thử nghiệm. Hoàn thiện hệ thống các tài liệu Đào tạo người sử dụng Các khái niệm cần chú ý trong giai đoạn này - Sự kiện (Evenement): là một việc thực thi đến nó là khởi sinh việc thực hiện cuả một hoặc nhiều xử lý nào đó. Có những sự kiện nằm ngay trong cơ chế của tổ chức hoặc nằm ngoài tổ chức. - Công việc (Operation): là một dãy xử lý có chung một sự kiện khởi sinh. - Tiến trình (Process): là một dãy các công việc mà các xử lý bên trong của nó nằm trong cùng một lĩnh vực nghiệp vụ. Nếu tiến trình quá lớn có thể chia cắt thành những file nhỏ hơn. - Nhiệm vụ: là một xử lý được xác định thêm các yếu tố về tổ chức: Ai? Ở đâu? Khi nào thực hiện nó? - Pha xử lý: Là tập hợp các nhiệm vụ có tính đến các yếu tố tổ chức và sự thực hiện chúng, không phụ thuộc vào sự kiện nào khác mà chỉ phụ thuộc vào sự kiện khởi sinh ban đầu. - Module xử lý: Là một xử lý cập nhật hoặc tra cứu bên trong của một pha và thao tác với số lượng tương đối ít dữ liệu. Đây là cách chia nhỏ các xử lý. Công việc Tiến trình 1 Tiến trình 2 Tiến trình 3 Pha 1 Pha 2 Pha 3 Mô hình tổng quát thiết kế vật lý trong đối với các xử lý Lập trình là công việc quan trọng nhất trong giai đoạn này, đây là công đoạn mà lập trình viên đưa tất cả những thiết kế từ đầu đến nay vận dụng vào chương trình và trực tiếp xây dựng chương trình. Công đoạn này đòi hỏi lập trình viên phải có một trình độ hiểu biết cao về ngôn ngữ lập trình được áp dụng cũng như các công cụ khác được sử dụng kèm theo. 2.4.7. Cài đặt, bảo trì và khai thác hệ thống Đây là giai đoạn cuối cùng trong toàn bộ quá trình xây dựng HTTT. Mục tiêu của giai đoạn này là tích hợp hệ thống được phát triển vào các hoạt động của tổ chức một cách ít va vấp nhất và đáp ứng những thay đổi có thể xảy ra trong suốt quá trình sử dụng. Hai nhiệm vụ chính của giai đoạn này là chuyển đổi về mặt kỹ thuật và chuyển đổi về mặt con người. Việc cài đặt hệ thống mới có thể kéo theo một sự thay đổi lớn đối với tổ chức. Để là giảm sự thay đổi đó ta có thể áp dụng một trong các cách cài đặt hệ thống như sau: Cài đặt trực tiếp Cài đặt song song Cài đặt thí điểm cục bộ Chuyển đổi theo giai đoạn 2.5. Giới thiệu về quản trị cơ sở dữ li

Các file đính kèm theo tài liệu này:

  • doc13696.DOC