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

Tài liệu giảng dạy Phân tích thiết kế hệ thống thông tin hệ thống hóa kiến thức từ cơ bản đến nâng cao ngành phục vụ đào tạo và n

• Tác giả: Nguyễn Văn Vy
• Trường học: Đại Học Quốc Gia Hà Nội
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Phân Tích Thiết Kế Hệ Thống Thông Tin
• Loại tài liệu: Giáo trình
• Năm xuất bản: 2004
• Địa điểm: Hà Nội

Mục lục chi tiết

• Lời nói đầu
• 1. CHƯƠNG 1: PHƯƠNG PHÁP LUẬN PHÁT TRIỂN HTTT
• 1.1. Khái niệm về hệ thống thông tin
• 1.2. Tiến hoá của cách tiếp cận phát triển HTTT
• 1.3. Vòng đời phát triển một hệ thống thông tin
• 1.4. Các phương pháp khác nhau phát triển HT
• 1.5. Xây dựng thành công HTTT
• 1.6. Sơ đồ tổng quát quá trình phân tích thiết kế HTTT
• 1.7. Câu hỏi cuối chương
• 1.8. Phụ lục
• 2. CHƯƠNG 2: KHẢO SÁT HIỆN TRẠNG XÁC ĐỊNH YÊU CẦU HỆ THỐNG
• 2.1. Khảo sát thu thập thông tin của hệ thống
• 2.2. Các phương pháp truyền thống xác định yêu cầu
• 2.3. Phương pháp hiện đại để xác định yêu cầu
• 2.4. Các khái niệm sử dụng trong khảo sát
• 2.5. Các bước thực hiện sau khảo sát
• 2.6. Câu hỏi cuối chương
• 2.7. Bài tập
• 3. CHƯƠNG 3: MÔ HÌNH NGHIỆP VỤ CỦA HỆ THỐNG
• 3.1. Khái niệm về mô hình nghiệp vụ
• 3.2. Biểu đồ phân rã chức năng
• 3.3. Hai dạng biểu diễn của biểu đồ phân rã chức năng
• 3.4. Xác định phạm vi hệ thống
• 3.5. Ví dụ
• 3.6. Câu hỏi cuối chương
• 3.7. Bài tập
• 4. CHƯƠNG 4: MÔ HÌNH HOÁ QUÁ TRÌNH XỬ LÝ
• 4.1. Mô hình hoá tiến trình nghiệp vụ
• 4.2. Biểu đồ luồng dữ liệu
• 4.3. Phát triển các biểu đồ luồng dữ liệu của một ứng dụng để phân tích
• 4.4. Sử dụng biểu đồ luồng dữ liệu
• 4.5. Ví dụ
• 4.6. Câu hỏi cuối chương
• 4.7. Bài tập
• 5. CHƯƠNG 5: MÔ HÌNH HOÁ LÔGIC TIẾN TRÌNH
• 5.1. Mô hình hoá lôgic với tiếng Anh cấu trúc
• 5.2. Mô hình hoá lôgic với bảng quyết định
• 5.3. Mô hình hoá logic với cây quyết định
• 5.4. Mô hình hoá lôgic thời gian
• 5.5. Câu hỏi cuối chương
• 5.6. Bài tập
• 6. CHƯƠNG 6: MÔ HÌNH DỮ LIỆU QUAN NIỆM
• 6.1. Khái niệm về mô hình dữ liệu quan niệm
• 6.2. Khái niệm và ký pháp của mô hình E-R
• 6.3. Mô hình hoá các trường hợp mở rộng
• 6.4. Biểu diễn qui tắc nghiệp vụ
• 6.5. Các bước xây dựng một mô hình dữ liệu quan niệm
• 6.6. Phát triển mô hình E-R bằng CASE
• 6.7. Câu hỏi cuối chương
• 6.8. Bài tập
• 7. CHƯƠNG 7: THIẾT KẾ MÔ HÌNH DỮ LIỆU LOGIC
• 7.1. Nội dung thiết kế mô hình dữ liệu logic
• 7.2. Các loại mô hình cơ sở dữ liệu lôgic
• 7.3. Mô hình dữ liệu quan hệ
• 7.4. Xây dựng mô hình dữ liệu logic
• 7.5. Quy trình thiết kế mô hình dữ liệu logic
• 7.6. Ví dụ
• 7.7. Câu hỏi cuối chương
• 7.8. Bài tập
• 8. CHƯƠNG 8: THIẾT KẾ HỆ THỐNG VẬT LÝ
• 8.1. Hoàn thiện phân tích nghiệp vụ
• 8.2. Những vấn đề đặt ra cho thiết kế hệ thống
• 8.3. Xây dựng biểu đồ luồng dữ liệu vật lý
• 8.4. Thiết kế giao diện người - máy và tương tác
• 8.5. Cấu trúc các thành phần hệ thống
• 8.6. Thiết kế các đối thoại
• 8.7. Thiết kế tệp và cơ sở dữ liệu vật lý
• 8.8. Ví dụ thiết kế hệ thống
• 8.9. Câu hỏi cuối chương
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Vì sao giáo trình phân tích thiết kế hệ thống là cốt lõi

Giáo trình phân tích thiết kế hệ thống thông tin là nền tảng không thể thiếu trong lĩnh vực công nghệ phần mềm. Nó cung cấp một bộ khung phương pháp luận, công cụ và kỹ thuật để xây dựng các hệ thống thông tin quản lý (MIS) hiệu quả, đáp ứng đúng nhu cầu của tổ chức. Tầm quan trọng của môn học này được nhấn mạnh trong tài liệu của tác giả Nguyễn Văn Vy (2004), khi chỉ ra rằng việc phân tích và thiết kế trở thành yêu cầu bắt buộc để có được một hệ thống tốt. Một hệ thống thông tin không chỉ là một ứng dụng công nghệ, mà là sự tích hợp toàn diện các thành tựu của công nghệ thông tin vào một tổ chức. Quá trình này bắt đầu từ việc phân tích yêu cầu cho đến khi triển khai và vận hành. Tác giả nhấn mạnh, do đặc thù sản phẩm "không nhìn thấy" và ngày càng phức tạp, việc thiếu một bản thiết kế vững chắc sẽ dẫn đến những sai sót nghiêm trọng. Các kỹ năng cần thiết cho một nhà phân tích không chỉ dừng lại ở kỹ thuật, mà còn bao gồm kỹ năng phân tích, nghiệp vụ, quản lý và giao tiếp. Chính vì vậy, giáo trình này không chỉ trang bị kiến thức về sơ đồ luồng dữ liệu (DFD) hay sơ đồ quan hệ thực thể (ERD), mà còn rèn luyện tư duy hệ thống và khả năng phân tích nghiệp vụ (Business Analyst). Việc nắm vững các nguyên tắc trong phân tích thiết kế hệ thống thông tin giúp các kỹ sư công nghệ thông tin đọc hiểu các bản vẽ thiết kế, tham gia hiệu quả vào các dự án và giảm thiểu rủi ro trong quá trình phát triển.

1.1. Tầm quan trọng của phân tích nghiệp vụ trong công nghệ phần mềm

Hoạt động phân tích nghiệp vụ là bước khởi đầu, quyết định sự thành bại của một dự án phần mềm. Mục tiêu chính là hiểu rõ các quy trình vận hành, mục tiêu chiến lược và những vấn đề mà tổ chức đang đối mặt. Một nhà phân tích nghiệp vụ (Business Analyst) phải làm việc trực tiếp với các bên liên quan để thu thập, tài liệu hóa và xác thực các yêu cầu. Giáo trình của Nguyễn Văn Vy (2004) đề cập đến việc "hoàn thiện phân tích nghiệp vụ" như một bước quan trọng trước khi thiết kế vật lý. Quá trình này không chỉ đơn thuần là ghi nhận thông tin, mà còn bao gồm việc mô hình hóa các quy trình thông qua sơ đồ luồng dữ liệu (DFD) và biểu đồ phân rã chức năng. Việc này đảm bảo rằng tất cả các yêu cầu đều được hiểu đúng và đầy đủ, tạo ra một cầu nối vững chắc giữa người dùng cuối và đội ngũ phát triển. Thiếu đi giai đoạn này, hệ thống được xây dựng có nguy cơ cao không đáp ứng được mong đợi, dẫn đến lãng phí tài nguyên và chi phí bảo trì tăng vọt.

1.2. Vai trò của tài liệu đặc tả yêu cầu trong quản lý dự án

Một trong những sản phẩm quan trọng nhất của giai đoạn phân tích là tài liệu đặc tả yêu cầu. Đây là văn bản chính thức, mô tả chi tiết những gì hệ thống cần thực hiện, bao gồm các chức năng, phi chức năng, ràng buộc và quy tắc nghiệp vụ. Tài liệu này đóng vai trò như một hợp đồng giữa khách hàng và đội ngũ phát triển, là cơ sở cho các hoạt động thiết kế, lập trình, kiểm thử phần mềm và nghiệm thu. Trong quản lý dự án phần mềm, tài liệu này giúp kiểm soát phạm vi dự án, tránh tình trạng "scope creep" (yêu cầu phát sinh không kiểm soát). Một tài liệu đặc tả yêu cầu rõ ràng, nhất quán và đầy đủ sẽ giảm thiểu sự hiểu lầm, giúp các thành viên trong dự án có cùng một tầm nhìn về sản phẩm cuối cùng. Nó cũng là nguồn thông tin đầu vào cho việc tạo ra các kịch bản kiểm thử, đảm bảo rằng hệ thống hoạt động đúng như mong đợi. Tóm lại, đây là công cụ quản lý không thể thiếu để đảm bảo dự án đi đúng hướng và đạt được mục tiêu đề ra.

II. Những thách thức trong phân tích thiết kế hệ thống hiện đại

Quá trình phân tích thiết kế hệ thống thông tin đối mặt với nhiều thách thức, đặc biệt khi quy mô và độ phức tạp của các hệ thống ngày càng tăng. Một trong những khó khăn lớn nhất là việc xác định chính xác và đầy đủ yêu cầu từ người dùng. Yêu cầu thường mơ hồ, mâu thuẫn hoặc thay đổi liên tục trong suốt vòng đời phát triển hệ thống (SDLC). Thách thức thứ hai đến từ chi phí sửa lỗi. Theo một điều tra của IBM được trích dẫn trong giáo trình của Nguyễn Văn Vy, "những sai sót trong phân tích và thiết kế làm cho chi phí bảo trì trung bình của các hệ thống thông tin chiếm tới gần 60% tổng chi phí". Nghiêm trọng hơn, một lỗi bị bỏ sót trong giai đoạn phân tích, đến giai đoạn lập trình mới phát hiện ra thì chi phí sửa chữa tăng tới 40 lần, và nếu để đến giai đoạn bảo trì thì con số này lên tới 90 lần. Điều này cho thấy tầm quan trọng của việc đầu tư đúng mức vào giai đoạn đầu của dự án. Một thách thức khác là sự thiếu hụt các công cụ và phương pháp luận phát triển hệ thống chuẩn hóa, dẫn đến việc phát triển mang tính nghệ thuật, khó bảo trì và tích hợp. Việc lựa chọn công nghệ phù hợp, từ hệ quản trị cơ sở dữ liệu đến ngôn ngữ lập trình, cũng là một bài toán khó, đòi hỏi sự cân bằng giữa hiệu năng, chi phí và khả năng mở rộng trong tương lai.

2.1. Chi phí sai sót trong vòng đời phát triển hệ thống SDLC

Chi phí để sửa một sai sót tăng theo cấp số nhân qua từng giai đoạn của vòng đời phát triển hệ thống (SDLC). Một yêu cầu bị hiểu sai ở giai đoạn phân tích có thể chỉ tốn vài giờ để sửa đổi trong tài liệu. Tuy nhiên, nếu sai sót này không được phát hiện và tiếp tục đi vào giai đoạn thiết kế cơ sở dữ liệu và lập trình, việc sửa chữa sẽ đòi hỏi thay đổi cấu trúc dữ liệu, viết lại mã nguồn và thực hiện lại quy trình kiểm thử phần mềm. Như trích dẫn từ nghiên cứu của IBM trong tài liệu gốc, chi phí này có thể tăng lên hàng chục, thậm chí hàng trăm lần khi hệ thống đã đi vào vận hành. Nguyên nhân là do sự thay đổi ở giai đoạn sau ảnh hưởng đến nhiều thành phần liên quan, đòi hỏi nỗ lực lớn hơn để tái kiểm tra và đảm bảo tính toàn vẹn của toàn hệ thống. Do đó, việc đầu tư vào các kỹ thuật phân tích yêu cầu kỹ lưỡng và các phương pháp xác thực sớm như làm bản mẫu (prototyping) là một chiến lược kinh tế hiệu quả, giúp giảm thiểu rủi ro và tổng chi phí sở hữu hệ thống.

2.2. Khó khăn trong việc phân tích yêu cầu từ người dùng cuối

Việc thu thập và phân tích yêu cầu từ người dùng cuối là một nghệ thuật và khoa học. Người dùng thường biết họ muốn gì nhưng lại gặp khó khăn trong việc diễn đạt nó một cách rõ ràng và nhất quán theo ngôn ngữ kỹ thuật. Các yêu cầu có thể không đầy đủ, mâu thuẫn với nhau hoặc dựa trên những quy trình nghiệp vụ chưa được tối ưu. Nhà phân tích phải sử dụng nhiều kỹ thuật khác nhau như phỏng vấn, quan sát, tổ chức hội thảo và phân tích tài liệu hiện có để khám phá ra các yêu cầu ẩn. Hơn nữa, các bên liên quan khác nhau có thể có những ưu tiên và góc nhìn khác nhau về hệ thống. Ví dụ, nhà quản lý quan tâm đến báo cáo tổng hợp, trong khi nhân viên vận hành cần một giao diện nhập liệu nhanh chóng và hiệu quả. Việc dung hòa các yêu cầu này và xây dựng một tài liệu đặc tả yêu cầu được tất cả các bên đồng thuận là một thách thức lớn, đòi hỏi kỹ năng giao tiếp, đàm phán và phân tích nghiệp vụ xuất sắc.

III. Phương pháp luận phát triển hệ thống thông tin chi tiết nhất

Một phương pháp luận phát triển hệ thống cung cấp một quy trình có cấu trúc để dẫn dắt dự án từ khi khởi tạo đến khi hoàn thành. Giáo trình phân tích thiết kế hệ thống thông tin của Nguyễn Văn Vy giới thiệu nhiều phương pháp luận, trong đó vòng đời phát triển hệ thống (SDLC) là khái niệm trung tâm. SDLC mô tả các pha tuần tự mà một hệ thống phải trải qua, bao gồm: khởi tạo và lập kế hoạch, phân tích, thiết kế, triển khai, vận hành và bảo trì. Mỗi pha có các hoạt động, mục tiêu và sản phẩm đầu ra cụ thể. Ví dụ, sản phẩm của pha phân tích là tài liệu đặc tả yêu cầu, trong khi sản phẩm của pha thiết kế là các mô hình chi tiết về kiến trúc, dữ liệu và giao diện. Ngoài mô hình thác nước truyền thống, giáo trình cũng đề cập đến các phương pháp linh hoạt hơn như làm bản mẫu (prototyping) và mô hình xoắn ốc. Phương pháp làm bản mẫu cho phép xây dựng nhanh một phiên bản thử nghiệm của hệ thống để người dùng tương tác và đưa ra phản hồi sớm. Điều này đặc biệt hữu ích khi các yêu cầu chưa rõ ràng. Việc lựa chọn phương pháp luận phù hợp phụ thuộc vào đặc điểm của dự án như quy mô, độ phức tạp và mức độ ổn định của các yêu cầu.

3.1. Các giai đoạn chính trong vòng đời phát triển hệ thống SDLC

Mô hình vòng đời phát triển hệ thống (SDLC) truyền thống, hay còn gọi là mô hình thác nước, chia quá trình phát triển thành các giai đoạn tuần tự và riêng biệt. Giai đoạn 1 là Lập kế hoạch, nơi xác định phạm vi, mục tiêu và tính khả thi của dự án. Giai đoạn 2 là Phân tích, tập trung vào việc thu thập và phân tích yêu cầu để hiểu rõ hệ thống cần làm gì. Giai đoạn 3 là Thiết kế, nơi các nhà phát triển xác định hệ thống sẽ được xây dựng như thế nào, bao gồm thiết kế cơ sở dữ liệu và kiến trúc phần mềm. Giai đoạn 4 là Triển khai (Implementation), bao gồm việc viết mã và xây dựng hệ thống theo bản thiết kế. Giai đoạn 5 là Kiểm thử phần mềm, đảm bảo hệ thống không có lỗi và đáp ứng các yêu cầu. Cuối cùng, Giai đoạn 6 là Vận hành và Bảo trì, nơi hệ thống được đưa vào sử dụng và được cập nhật, sửa lỗi định kỳ. Mỗi giai đoạn phải được hoàn thành trước khi chuyển sang giai đoạn tiếp theo, tạo ra một quy trình có cấu trúc và dễ quản lý.

3.2. So sánh các mô hình Thác nước Xoắn ốc và Làm bản mẫu

Mỗi phương pháp luận phát triển hệ thống có ưu và nhược điểm riêng. Mô hình Thác nước có cấu trúc chặt chẽ, dễ quản lý, phù hợp với các dự án có yêu cầu rõ ràng và ổn định ngay từ đầu. Tuy nhiên, nó thiếu linh hoạt và không cho phép quay lại các giai đoạn trước một cách dễ dàng. Phương pháp Làm bản mẫu (Prototyping) lại rất linh hoạt, cho phép người dùng tham gia sớm và liên tục, giúp làm rõ các yêu cầu không chắc chắn, đặc biệt là thiết kế giao diện người dùng (UI/UX). Nhược điểm là có thể dẫn đến việc bỏ qua các tài liệu thiết kế chi tiết. Mô hình Xoắn ốc kết hợp các yếu tố của cả hai mô hình trên, thêm vào đó là yếu tố quản lý rủi ro. Mỗi vòng lặp của mô hình xoắn ốc là một dự án nhỏ, đi qua các bước lập kế hoạch, phân tích rủi ro, kỹ thuật và đánh giá. Mô hình này phù hợp với các dự án lớn, phức tạp và có nhiều rủi ro công nghệ, nhưng đòi hỏi chuyên môn cao về quản lý.

IV. Cách mô hình hóa quy trình xử lý và cấu trúc dữ liệu hiệu quả

Mô hình hóa là một kỹ thuật cốt lõi trong phân tích thiết kế hệ thống thông tin, giúp trực quan hóa các khía cạnh phức tạp của hệ thống thành các sơ đồ dễ hiểu. Có hai loại mô hình chính được đề cập sâu trong giáo trình: mô hình hóa quá trình xử lý và mô hình hóa dữ liệu. Để mô hình hóa quá trình, sơ đồ luồng dữ liệu (DFD) là công cụ phổ biến nhất. DFD mô tả cách dữ liệu di chuyển qua hệ thống, các quá trình xử lý biến đổi dữ liệu đó, nơi dữ liệu được lưu trữ và các tác nhân bên ngoài tương tác với hệ thống. Nó giúp phân tích hệ thống từ góc độ chức năng mà không cần quan tâm đến các chi tiết triển khai vật lý. Mặt khác, để mô hình hóa cấu trúc dữ liệu, sơ đồ quan hệ thực thể (ERD) được sử dụng. ERD xác định các thực thể chính trong hệ thống (ví dụ: Sinh viên, Môn học), các thuộc tính của chúng và các mối quan hệ giữa chúng (ví dụ: một Sinh viên đăng ký nhiều Môn học). ERD là nền tảng cho việc thiết kế cơ sở dữ liệu quan hệ, đảm bảo dữ liệu được tổ chức một cách logic, nhất quán và giảm thiểu sự trùng lặp. Việc kết hợp cả DFD và ERD cung cấp một cái nhìn toàn diện về hệ thống, từ đó tạo ra một bản thiết kế vững chắc.

4.1. Kỹ thuật vẽ sơ đồ luồng dữ liệu DFD từ cơ bản đến nâng cao

Sơ đồ luồng dữ liệu (DFD) sử dụng bốn ký hiệu chính: tiến trình (process), kho dữ liệu (data store), luồng dữ liệu (data flow) và tác nhân ngoài (external entity). Kỹ thuật vẽ DFD thường bắt đầu với sơ đồ ngữ cảnh (mức 0), chỉ hiển thị hệ thống như một tiến trình duy nhất cùng các tác nhân ngoài tương tác với nó. Sau đó, sơ đồ này được phân rã thành các sơ đồ chi tiết hơn ở các mức thấp hơn (mức 1, mức 2,...). Quá trình này được gọi là phân rã từ trên xuống (top-down decomposition), giúp quản lý độ phức tạp của hệ thống. Một DFD tốt phải đảm bảo tính cân bằng, nghĩa là các luồng dữ liệu vào và ra của một tiến trình ở mức cao phải khớp với tổng các luồng dữ liệu vào và ra của các tiến trình con của nó ở mức thấp. DFD là công cụ giao tiếp hiệu quả giữa nhà phân tích và người dùng vì tính trực quan và không yêu cầu kiến thức kỹ thuật sâu.

4.2. Xây dựng sơ đồ quan hệ thực thể ERD cho thiết kế CSDL

Sơ đồ quan hệ thực thể (ERD) là công cụ trực quan để thiết kế cơ sở dữ liệu ở mức quan niệm. Quá trình xây dựng ERD bắt đầu bằng việc xác định các thực thể, tức là các đối tượng hoặc khái niệm quan trọng mà hệ thống cần lưu trữ thông tin (ví dụ: Khách hàng, Sản phẩm). Tiếp theo, xác định các thuộc tính mô tả cho mỗi thực thể, trong đó có một hoặc nhiều thuộc tính được chọn làm khóa chính để định danh duy nhất. Cuối cùng, xác định các mối quan hệ giữa các thực thể và bản số của chúng (một-một, một-nhiều, nhiều-nhiều). Một ERD hoàn chỉnh sẽ là đầu vào cho quá trình thiết kế logic, nơi nó được chuyển đổi thành một tập hợp các bảng quan hệ trong một hệ quản trị cơ sở dữ liệu. Việc xây dựng một ERD chính xác giúp đảm bảo tính toàn vẹn, nhất quán và hiệu quả của cơ sở dữ liệu.

V. Bí quyết thiết kế hệ thống vật lý Giao diện và cơ sở dữ liệu

Sau khi hoàn thành giai đoạn phân tích và thiết kế logic, quá trình phân tích thiết kế hệ thống thông tin chuyển sang thiết kế vật lý. Giai đoạn này quyết định hệ thống sẽ được triển khai cụ thể như thế nào trên một nền tảng công nghệ nhất định. Có hai thành phần quan trọng cần tập trung là thiết kế giao diện người dùng (UI/UX) và thiết kế cơ sở dữ liệu vật lý. Thiết kế giao diện không chỉ là về thẩm mỹ, mà còn về tính khả dụng, đảm bảo người dùng có thể tương tác với hệ thống một cách dễ dàng, hiệu quả và không gặp lỗi. Các nguyên tắc như tính nhất quán, cung cấp phản hồi kịp thời và thiết kế luồng công việc tự nhiên là rất quan trọng. Song song đó, thiết kế cơ sở dữ liệu vật lý chuyển đổi mô hình ERD logic thành các cấu trúc lưu trữ cụ thể trong một hệ quản trị cơ sở dữ liệu đã chọn. Quá trình này bao gồm việc chọn kiểu dữ liệu phù hợp cho từng cột, tạo chỉ mục (index) để tăng tốc độ truy vấn, và thực hiện các quy tắc chuẩn hóa để loại bỏ dư thừa dữ liệu. Một thiết kế vật lý tốt sẽ đảm bảo hệ thống có hiệu năng cao, an toàn và dễ bảo trì, đáp ứng được các yêu cầu phi chức năng của tổ chức.

5.1. Nguyên tắc thiết kế giao diện người dùng UI UX tối ưu

Một thiết kế giao diện người dùng (UI/UX) tối ưu cần tuân thủ nhiều nguyên tắc. Tính nhất quán là yếu tố hàng đầu: các thành phần, thuật ngữ và hành động tương tự nên được biểu diễn nhất quán trên toàn bộ hệ thống. Điều này giúp người dùng học và sử dụng hệ thống nhanh hơn. Cung cấp phản hồi rõ ràng cho mọi hành động của người dùng (ví dụ: thông báo lưu thành công, chỉ báo đang tải) giúp họ cảm thấy kiểm soát được hệ thống. Bố cục màn hình cần được tổ chức hợp lý, nhóm các thông tin liên quan và tuân theo một luồng công việc logic, tự nhiên. Giảm thiểu tải nhận thức bằng cách sử dụng các giá trị mặc định, cung cấp các gợi ý và hạn chế số lượng lựa chọn trên một màn hình. Cuối cùng, hệ thống cần có cơ chế xử lý lỗi thân thiện, thông báo lỗi rõ ràng và đưa ra hướng dẫn để khắc phục. Việc áp dụng các nguyên tắc này sẽ tạo ra một trải nghiệm người dùng tích cực, tăng năng suất và mức độ hài lòng.

5.2. Chuyển đổi từ mô hình logic sang thiết kế cơ sở dữ liệu vật lý

Quá trình chuyển đổi từ mô hình logic (ERD) sang thiết kế cơ sở dữ liệu vật lý là một bước kỹ thuật quan trọng. Mỗi thực thể trong ERD thường trở thành một bảng (table) trong cơ sở dữ liệu. Mỗi thuộc tính của thực thể trở thành một cột (column) trong bảng tương ứng. Khóa chính của thực thể được dùng làm khóa chính của bảng. Mối quan hệ một-nhiều được triển khai bằng cách thêm khóa chính của bảng "một" vào bảng "nhiều" để làm khóa ngoại. Mối quan hệ nhiều-nhiều được giải quyết bằng cách tạo một bảng trung gian (bảng nối) chứa khóa ngoại từ cả hai bảng tham gia. Trong thiết kế vật lý, cần phải ra các quyết định cụ thể về nền tảng công nghệ, chẳng hạn như chọn kiểu dữ liệu (ví dụ: VARCHAR, INT, DATE) cho mỗi cột và xác định các chỉ mục để tối ưu hóa hiệu suất truy vấn. Đây là bước hiện thực hóa cấu trúc dữ liệu để hệ thống có thể hoạt động hiệu quả.

VI. Tương lai của ngành phân tích và thiết kế hệ thống thông tin

Ngành phân tích thiết kế hệ thống thông tin liên tục phát triển để đáp ứng những thay đổi của công nghệ và môi trường kinh doanh. Trong khi các nguyên tắc cơ bản về phân tích yêu cầu và mô hình hóa vẫn giữ nguyên giá trị, các công cụ và phương pháp luận đã có những bước tiến vượt bậc. Các phương pháp phát triển linh hoạt (Agile) như Scrum và Kanban đang ngày càng thay thế mô hình thác nước truyền thống, nhấn mạnh vào sự hợp tác, các chu kỳ phát triển ngắn và khả năng thích ứng nhanh với thay đổi. Các công cụ CASE (Computer-Aided Software Engineering) ngày càng mạnh mẽ, tự động hóa nhiều công đoạn từ vẽ sơ đồ đến sinh mã. Một xu hướng quan trọng khác là sự trỗi dậy của ngôn ngữ mô hình hóa thống nhất (UML), cung cấp một bộ ký hiệu chuẩn để mô tả các khía cạnh khác nhau của hệ thống hướng đối tượng. Vai trò của người phân tích nghiệp vụ (Business Analyst) cũng ngày càng được đề cao, không chỉ là người thu thập yêu cầu mà còn là nhà tư vấn chiến lược, giúp doanh nghiệp tận dụng công nghệ để đổi mới và tạo lợi thế cạnh tranh. Tương lai của ngành này đòi hỏi các chuyên gia phải liên tục cập nhật kiến thức, thành thạo nhiều công cụ và sở hữu các kỹ năng mềm xuất sắc.

6.1. Xu hướng ứng dụng ngôn ngữ mô hình hóa thống nhất UML

Ngôn ngữ mô hình hóa thống nhất (UML) là một bộ ký hiệu đồ họa tiêu chuẩn được sử dụng để trực quan hóa, đặc tả, xây dựng và tài liệu hóa các thành phần của một hệ thống phần mềm hướng đối tượng. UML cung cấp một loạt các biểu đồ, mỗi loại phục vụ một mục đích khác nhau. Ví dụ, biểu đồ Lớp (Class Diagram) mô tả cấu trúc tĩnh của hệ thống, biểu đồ Ca sử dụng (Use Case Diagram) mô tả chức năng từ góc nhìn người dùng, và biểu đồ Tuần tự (Sequence Diagram) mô tả sự tương tác giữa các đối tượng theo thời gian. Việc sử dụng UML mang lại nhiều lợi ích: tạo ra một ngôn ngữ chung cho tất cả các bên liên quan, giúp phát hiện sớm các sai sót trong thiết kế và tạo ra các tài liệu thiết kế rõ ràng, dễ bảo trì. Đây là công cụ không thể thiếu trong các dự án phát triển theo hướng đối tượng hiện đại.

6.2. Tầm nhìn phát triển cho Kỹ sư Phân tích nghiệp vụ BA

Vai trò của Kỹ sư Phân tích nghiệp vụ (Business Analyst - BA) đã vượt ra khỏi phạm vi truyền thống của việc viết tài liệu đặc tả yêu cầu. Các BA hiện đại được kỳ vọng sẽ là những đối tác chiến lược của doanh nghiệp. Họ không chỉ trả lời câu hỏi "Hệ thống cần làm gì?" mà còn phải trả lời "Tại sao chúng ta cần làm điều đó và nó mang lại giá trị gì?". Điều này đòi hỏi BA phải có sự hiểu biết sâu sắc về ngành kinh doanh của tổ chức, khả năng phân tích dữ liệu để xác định các cơ hội cải tiến và kỹ năng tư vấn để đề xuất các giải pháp công nghệ sáng tạo. Tầm nhìn phát triển cho một BA chuyên nghiệp là trở thành một cầu nối thực sự giữa kinh doanh và công nghệ, thúc đẩy quá trình chuyển đổi số và giúp doanh nghiệp đạt được các mục tiêu chiến lược một cách hiệu quả.

Trích đoạn nội dung tài liệu

chương IÏÍ và mục 4.6 chươ khuôn khổ của pháp lý hiện hành. Ngoài các phân tích trên người ta A. Xác định luồng hệ thống còn phân tích một số khả thí khác. Khi chọn được các biểu đồ luồng dữ liệu (từ mục 4.6 chương IV) Khi dự án được chấp nhận, thì đối tương tổng quát của dự án như có chứa các tiến trình lá, ta thay các kho dữ liệu bằng các quan hệ phạm vi của dự án, kế hoạch triển khai dự án phải được vạch ra và tương ứng và tiến hành thiết kế hệ thống vất lý ta có các kết quả sau: thông qua để triển khai(xem phụ lục cuối chương).

Biên soan: Nguyễn Văn Vv Biên soạn: Nguyễn Văn Vy ˆ ° Phương pháp luận phát triển HTTT _ | — 19 198 - PHAN TICH THIET KE HE THONG THONG TIN 1. Phân tích hệ thống 8. Một số định dang thiết kế _ Phân tích hệ thống nhằm xác định nhu cầu thông tin của tổ chức. Nó sẽ cung cấp những dữ liệu cơ sở cho việc thiết kế HITTT Sản phẩm của pha thiết kế tệp và cơ sở đữ liệu vật lí là một tập thuộc phạm vi Trước đó cần tiến hành khảo sát hiện trạng của tổ chức các đặc tả mà các nhà lập trình hoặc các nhà phân tích dữ liệu sẽ sử vụ cho việc xây liên quan đến dự án.

Những dữ liệu thu được phục gồm mô dụng để xác định định dạng và cấu trúc các dữ liệu trong bộ nhớ thứ dựng mô hình quan niệm về hệ thống hiện thời: mô hình bao tài liệu bổ sung cấp (bộ nhớ ngoài) của máy tính. Các đặc tả đưa ra phải phù hợp với hình dữ liệu và mô hình xử lý của hệ thống cùng các phần mềm hệ thống đã lựa chọn. Khi sử dụng các công cụ CASE, kho khác. | dữ liệu của CASE hay từ điển dữ liệu đự án là nơi lưu trữ tất cả các đặc yêu cầu: Phân tích bao gồm một vài pha nhỏ: (rước hết xác dịnh tả nêu ra ở trên.

Các đặc tả thiết kế tiêu biểubao gồm: các đặc tả về các định cái gì các nhà phân tích làm việc cùng với người sử dụng để xác cứu yêu trường, về bản ghi và về các loại tệpdữ liệu(xem [2]). người dùng chờ đợi từ hệ thống dự kiến. Tiếp theo là nghiên bên ngoài và Khi thiết kế cơ sở dữ liệu, ngoài các tệp dữ liệu chính cần thêm cầu và cấu trúc nó phù hợp với mối quan hệ bên trong, 3 là tìm giải một số loại tệp để phục vụ quá trình xử lý, đảm bảo an toàn và bảo mật những- giới hạn đật lên các dịch vụ cần thực hiện. Thứ ra, so sánh để pháp cho các thiết kế bạn đầu để đạt được yêu cầu đặt dữ liệu, tận dụng không gian nhớ và làm việc.

Một HTTT có thể cần cầu với chỉ phí, - lựa chọn giải pháp thiết kể tốt nhất đấp ứng các yêu tới sáu loại. tệp sau: Tệp đữ liệu (Data file), tệp lấy đữ liệu (look up qua. nguồn lực, thời gian và kĩ thuật cho phép để tổ chức thông table file), tệp giao dịch (transaction file), tệp làm việc (work file), tệp bảo vệ (protection file), tệp lịch sử (hístory file). Thiết kế hệ thống ứng các .3, Ví dụ thiết kế CSDL vật lý — Thiết kế là tìm các giải pháp công nghệ thông tin để đáp yêu cầu ở pha trước yêu cầu dat ra o trên.

Đặc tả giải pháp cho các tả vật lý. Từ các Xét ví dụ ở mục 76 của chương 7, ta nhận được các kết quả ở được chuyển thành đặc tá hệ thống logic rồi là đặc hình khâu thiết kế lôgic với các quan hệ sau: khía cạnh của hệ thống. thiết kế được xem xét bất đầu từ màn và các tương tác, các cái vào và cái ra (các báo cáo) đến cơ sở đữ liệu KHÁCH (mãkhách, tênkhách, địachikhách) (1) này gồm hai pha nhỏ: tiến trình xử lí chỉ tiết bên trong. Pha thiết kế HANG (mahang, ténhang, donvihang, motahang) (2) thiết kế logic và thiết kế vật lý.

hệ thống logic không DƠN HÀNG ( sốđơn , mãkhách , ngàyđặt) Hy Am xay, oe ne cee (3) Thiết kế logic. Vẻ mạt lí thuyết, thiết kế nào. Thiết kế logic tập gắn với bất kì phần cúng và phần mềm hệ thống thực vì vậy một vài trung vào các khía cạnh nghiệp vụ của hệ thống thiết kế nghiệp vụ. phương pháp luận vòng đời còn gọi pha này là pha Biên soạn: Nguyễn Văn Vy Biên soạn: Nguyễn Văn Vv -30 Chương Vill Thiét kế hệ thống vật lý | 197 _ PHANÂN TICH Tí THIETSr yeKE HEue THOTueNG THO NG TIN - Thiết kế tệp Các đối t từng VÀY quanona nid hệ BA được mô tả ở đây là những khái niệm, các 0 tượng mà không phải các thực thể vật lý - Thiết cơ sở đữ liệu vật lý.

‹ , Thiết kế wá lý HÀ nu ve o 8. Quá trình thiết kế - bản haere Nal # R quả trình chuyển mô hình logic trừu tượng thành thổ 4 € val lv hay Các đặc tả kĩ thuật. aintNhững phần khác nhau của_— hệ Trên thực tế, nhiều tổ chức đã có sẵn các chuẩn về hệ điều hành, Ne › cược được gảnpắn vào vào nhữ ck những thao tác và thiết bị vật lý cần thiết để tiên lợi về hệ quản trị CSDI, và.ngôn ngữ truy nhập dữ liệu và xem chúng như cho | việệc c thu thậpip đữdữ liệ liệuu,, xử xử lí vàvà đưa ra thông tin cần thiết cho tổ chức là các yếu tố đã được chọn. Các thông tin cần thiết để thiết kế các tệp m Trongbe Pmha Gt an k& \ yards À a „ at lý cần phải quyết định lựa chon ngôn và cơ sở dữ liệu vật lý bao pồm: a ( HE SO ngữ GH Hen, cate trie file t6 chite dit ten nha.

cứng, : haệ peeđiểu hàn vờ mi mái ra. uc dit liệu, Cu, những& phan phả - Các quan hệ đã chuẩn hoá, kể cả ước lượng về khối lượng dữ cuốiee cùng Me dew của hank va moi pha thiết kế làtrudng đãc tí mang ha cén thế duceve Xâyó7 dựng. Sản phẩm i liệu cần lưu trữ. 1C tả hệ thống vật lý ở dang 4 tổ tại trê LIẾ, Sáo chỉ cáo nề tac co ey ở dạng như nó -_ Từ điển dữ liệu | | sự trên thực lễ, sao cho các nhà lập trình và kỹ sư phần cứng có thể tồn dễ dàng chuyển thành Chương trình và Các mô tả cho biết ở đâu và khi nào dữ liệu được sử dụng.

cấu trúc hệ thống. Triển khai hệ thống Các yêu cầu và mong đợi về sử dụng và tích hợp dữ liệu, bao gồm các yêu cầu về thời gian đáp ứng, các mức độ an toàn, ghi Tronp pha nav. a hành ‘ đượcJe, E Sau_đó đặc tỉ hệ trathống được kiém vi được ` chuyển : thành hỏ : thống > vận+a tạm, phục hồi, phân bố trong không gian địa lý. ` HC ì dưa vào sử dụnp.

Bước triể : bao gồm việccC lấplá) fdra Cáccá Chươn® chụ trình, tiến hà aeng. Suge „x2 tien Khai Các mô tả về công nghệ được sử dụng để triển khai tệp và ¬ cài typ 4 _¬ § trinh, Hé hành: tàn thự, , đắpldÐ đội đất thiế]thưới CSI1L (thiết bị lưu trữ, hệ điều hành, hệ quản tri CSDL.) bi, cdi dat chiang trình và Chuyến đổi hé thong mạ a. Tao lập các chương “Trong thiết kế tệp và dữ liệu vật lí người thiết kế phải đưa ra một trình _ số các quyết định cơ bản có ý nghĩa đối với sự tích hợpvà hiệu năng lệ mẫnTrướ tra c ,hết cầncần lựalựa c chọn sh phần mềm ề nềnin (platform : hé diéu hanh của hệ thống ứng dụng là: S. mm nhiêu li h nộ dữ liệu, Ngon ngit lap trinh, phan mém tạng.

vn Tường hợp, Trong - Chọn định dạng lưu trữ cho mỗi thuộc tính của các quan hệ. HỘ ngôn ngữ lập 4 trình cócó thêthể chínchính h làlà ngôn ngữ quản trịa 1 cơ sở` dữ liệu hav của ngữ của hệ Nhóm các thuộc tính vào các bản ghi vật lí È Ả của hệhCệ ứng ú dụngụng được sửsủ dụng). Sau \ _¬ đó 5 — ch các hphần thàn các mềm nhân đóng TUgói. - Cuối KHÔI củng cũ chuyểnnc các đặcẠC tả4 tá the Sắp xếp các bản ghỉ có quan hệ với nhau vào bộ nhớ ngoài (đĩa, hiết kếkế còn thiết còn ine lại lai được tiến een mem bang từ và trong bộ nhớ ) sao cho chúng được lưu trữ, cập nhật và (các chương trình) cho máy tính, Chương trình ức he CÔN ảnh KIỎT kiêm thứ cho đến khi ¡ đặtđạt yêu lấy ra nhanh chóng (gọi là tổ chức tệp).

yêu cầucầu đểđ ra. Quá trì thử bao lể m ane. g6m kiém AK,SIKH) ihửt cáccác môd mô; un chức : nãnă g ng (kié ¢ Wi điểmm thứ thự đơn ae tanh w Ì ácie hệ Lựa chọn phương tiện và cấu trúc để lưu trữ đữ liệu đảm bảo truy hthốngope conon H(Hiể G m l thử tí,ich hợp), sự hoạt —~- i.v7? ` độnđô5động la cá cả hệ1 hệ thốn cập hiệu quả hơn, an toàn, é théng) và nphiệm thu cuối 9M H O Ạ I g cưa thốithông g (kiể C2 ee m thứ;is cùng (kiêm thịỷ chấp nhận ). | Biên soạn: Nguyễn Văn Vy Bién soạn.

Phương pháp luận phát triển HTTT - _196 PQ PHAN TICH THIET RE HE THONG THONG TIN' b. Cài đặt và chuyển đổi hệ thống ¬ Trong biểu đồ dõi thoại, ta nối các hôp màn hình với nhau theo trình tự xuất hiện của chúng. Tất cả các đườn Quá trình chuyển đổi bao gồm việc cài đặt các chương trình trên hệ g nối piữa các màn hình trong biểu đổ đối thoại là hai chiều, người thống phần cứng đang tổn tại hay hệ thống phần cứng mới lắp đạt, chuyển sử dụng được phép di chuyên lên trước hay quay ngược lại. Nếu muốn - đổi toàn bộ hoạt động của tổ ch ức trong: hệ thống cũ sang hoạt động với hệ : sự di chuyển trong đối thoại chỉ theo một hướng thì có thể thêm dấu mũi tên vào phía thống mới (bao gồm việc chuyển đổi dữ liệu, sắp xếp đỗi ngũ cán bộ trên tương ứng của đường nối.

Trong biểu đồ đối thoại có thể biểu diễn một trình hệ thống mới và đào tạo ngườisử dụng, khai thác hệ thống). Chuẩn bị các _ tự của các màn hình, theo đó một màn hình hiển thị tiếp sau tài liệu chỉ tiết thuyết minh vẻ việc khai thác và sử dụng hệ thống (cả vẻ cái khác mặt kỹ thuật, về hệ thống và tại nơi làm việc của người sử dụng): Nó cần hoặc việc sử dụng lặp lại.