Phát triển hệ thống thông tin kế toán: Mô-đun doanh nghiệp, cơ sở dữ liệu và giao diện
Phát triển hệ thống thông tin kế toán: Mô-đun doanh nghiệp, cơ sở dữ liệu và giao diện!
Một số gói phần mềm kế toán có sẵn cung cấp nhiều tính năng khác nhau. Chúng có giá thấp hơn nhiều so với những gì phần mềm kế toán tùy chỉnh sẽ có giá. Tuy nhiên, các gói phần mềm này chỉ cung cấp cấu trúc cho các hệ thống thông tin kế toán. Nhiều nhất, họ làm giảm nỗ lực lập trình cho các hệ thống thông tin kế toán.
Hình ảnh lịch sự: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg
Sự phát triển của hệ thống thông tin kế toán không chỉ là phần mềm để đăng tải sổ cái và lập báo cáo. Nó cũng liên quan đến việc thiết lập các thủ tục để thu thập dữ liệu và phân phối, cũng như phân tích thông tin kế toán.
Sự phát triển của một hệ thống thông tin kế toán được giải thích với sự tham khảo đặc biệt đến các yêu cầu của một doanh nghiệp kinh doanh có quy mô vừa và lớn. Tuy nhiên, các bước này sẽ phổ biến cho hầu hết các hệ thống thông tin khác trong một doanh nghiệp kinh doanh.
1. Mô-đun doanh nghiệp:
Mô-đun doanh nghiệp phát triển hệ thống thông tin liên quan đến việc xác định các thực thể cơ bản và mối quan hệ tương tác của chúng, xác định các hoạt động cơ bản và tập hợp lại các hoạt động này vào các hệ thống phụ. Sau đó, các ưu tiên được quyết định trên cơ sở phân tích lợi ích chi phí cho doanh nghiệp.
Xác định thực thể:
Một số lượng lớn các thực thể tồn tại trong một doanh nghiệp kinh doanh và danh sách cũng đa dạng như các hoạt động kinh doanh. Tuy nhiên, ở giai đoạn này, mối quan tâm chính là xác định các thực thể rộng lớn, mỗi thực thể chứa một nhóm các thực thể cơ bản. Kerner 5 chỉ ra sáu thực thể cơ bản trong một doanh nghiệp kinh doanh.
Họ là khách hàng, sản phẩm, nhà cung cấp, nhân sự, cơ sở và tiền bạc. Trong một hệ thống thông tin kế toán, có ba thực thể cơ bản là giao dịch, tài khoản và thời gian xử lý. Mối tương quan giữa các thực thể này có thể được thể hiện bằng các sơ đồ ER như trong Hình 8.2.
Các giao dịch sẽ có nhiều loại khác nhau, chẳng hạn như biên lai, thanh toán, bán, mua, mua lại tài sản hoặc trả nợ, v.v. và mỗi trong số chúng có thể được gọi là một thực thể cấp thấp hơn. Tương tự, tài khoản có thể có nhiều loại khác nhau, chẳng hạn như tài sản, nợ phải trả, doanh thu và chi phí.
Mỗi người đứng đầu có thể có các thực thể cấp thấp hơn như tài sản cố định và tài sản hiện tại. Những thực thể này có thể được chia thành các thực thể cấp thấp hơn như đất đai và xây dựng, nhà máy và máy móc, v.v. Tuy nhiên, ở giai đoạn này, các thực thể rộng cần phải được xác định. Các chi tiết được thực hiện tại thời điểm thiết kế cơ sở dữ liệu.
Các thực thể được xác định theo ánh sáng và với mục đích xác định phạm vi và trọng tâm của hệ thống thông tin. Ví dụ, nếu hệ thống thông tin đang được xem là một hệ thống thông tin chiến lược, các thực thể rộng sẽ được xác định dưới ánh sáng của các lực đẩy chiến lược mà doanh nghiệp dự định cung cấp cho các hoạt động của mình với sự trợ giúp của hệ thống thông tin.
Những lực đẩy này có thể là tối thiểu hóa chi phí, dịch vụ khách hàng, phân biệt sản phẩm và các liên minh chiến lược. Các thực thể cơ bản trong trường hợp như vậy sẽ là khách hàng, kênh, doanh nghiệp cạnh tranh, sản phẩm, v.v.
Phân tích hoạt động:
Một khía cạnh quan trọng khác của mô-đun doanh nghiệp là xác định các hoạt động liên quan đến các thực thể. Các hoạt động này được xác định rộng rãi dưới dạng các mối quan hệ trong sơ đồ ER. Tuy nhiên, chi tiết có được với sự trợ giúp của phân tích hoạt động. Cơ cấu tổ chức hiện tại là một nguồn thông tin quan trọng liên quan đến các hoạt động rộng lớn được thực hiện bởi doanh nghiệp.
Nhưng, để phát triển các hệ thống thông tin độc lập với cấu trúc tổ chức hiện tại, điều cần thiết là phải phân tích hoạt động trên các thực thể cơ bản đã được xác định ở trên. Cấp độ phân tích hoạt động tiếp theo liên quan đến việc xác định các hoạt động vòng đời. Trong trường hợp 'giao dịch' là một trong những thực thể cơ bản trong hệ thống thông tin kế toán, có bốn hoạt động vòng đời rộng, cụ thể là:
1. Vòng đời mua hàng
2. Vòng đời sản xuất
3. Vòng đời doanh thu
4. Vòng đời đầu tư
Tương tự, giai đoạn xử lý có hai hoạt động vòng đời cơ bản là:
a. Lập kế hoạch và kiểm soát vòng đời
b. Vòng đời báo cáo nội bộ và bên ngoài
Các hoạt động vòng đời này là các hoạt động đang diễn ra và được thực hiện liên tục. Mỗi hoạt động này có thể liên quan tuần tự đến một số hoạt động khác. Cấp độ phân tích hoạt động thứ ba liên quan đến việc phân chia các hoạt động vòng đời thành các chức năng.
Ví dụ, mỗi loại giao dịch phải được bắt đầu và công nhận; sau đó dữ liệu liên quan đến giao dịch phải được nắm bắt, mã hóa để phân loại trong tương lai, phân loại, tóm tắt và báo cáo. Các chức năng này sẽ được thực hiện khác nhau cho các loại giao dịch khác nhau. Quá trình xác định các chức năng chỉ tập trung vào các hoạt động tạo, cập nhật hoặc sử dụng thông tin trong cơ sở dữ liệu của doanh nghiệp.
Ở cấp độ phân tích hoạt động này, các hoạt động được khép kín, đã xác định rõ ràng các sự kiện hoặc nút bắt đầu và kết thúc và một người có thể nhận dạng hoặc một nhóm người chịu trách nhiệm thực hiện chức năng.
Các chức năng này sau đó có thể được chia thành các chức năng phụ cho đến khi các chức năng đủ cụ thể để xác định mô-đun cho các chương trình máy tính. Việc phân chia các hoạt động của vòng đời thành các chức năng và chức năng phụ giúp xác định các chức năng được lặp lại trong nhiều hơn một hoạt động của vòng đời.
Ví dụ, chức năng phân loại dữ liệu bị bắt có thể được thực hiện trong vòng đời mua và tiếp thị. Phân tích hoạt động như vậy giúp xác định các cơ hội để cải thiện thiết kế hiện có bằng cách:
1. loại bỏ các chức năng dư thừa
2. kết hợp các chức năng trùng lặp
3. đơn giản hóa và cải tiến các phương pháp xử lý
Sự dư thừa có thể được xác định bằng cách phân tích cẩn thận các hoạt động. Các hoạt động có khả năng cung cấp cơ hội để cải thiện việc xử lý bao gồm các hoạt động:
a. Điều đó cũng được thực hiện ở nơi khác
b. Điều đó có thể được kết hợp với các hoạt động khác
c. Điều đó cũng có thể được xử lý bởi một số người khác
d. Điều đó có thể được thực hiện ở một số giai đoạn khác của vòng đời không thêm bất kỳ giá trị nào vào sản phẩm hoặc dịch vụ của hệ thống thông tin.
Một lời cảnh báo ở đây là không phải tất cả các khoản dự phòng đều xấu. Trong thực tế, một số dự phòng hoặc sao chép có thể được cố ý cho phép leo vào hệ thống. Điều này có thể được thực hiện để cải thiện hiệu suất và độ tin cậy của hệ thống.
Ví dụ, một số sao chép có thể cần thiết để đảm bảo tính đơn giản của quy trình và cải thiện tốc độ xử lý. Loại bỏ sự dư thừa có thể dẫn đến việc 'đặt tất cả trứng vào một giỏ' và do đó có thể ảnh hưởng đến độ tin cậy. Nguy cơ của những tác động bất ngờ và lợi nhuận thấp từ phương pháp hoặc thủ tục mới được đề xuất là những yếu tố khác đáng được chú ý trước khi những thay đổi được đề xuất trong hệ thống thông tin.
Phân nhóm các hoạt động thành các hệ thống phụ:
Sau khi các hoạt động được xác định bằng cách sử dụng phương pháp từ trên xuống được thông qua ở trên, chúng được nhóm lại để tạo thành các hệ thống phụ. Một quyết định quan trọng được đưa ra trong giai đoạn này liên quan đến cơ sở của nhóm. Có thể không tồn tại một tiêu chí khách quan duy nhất để quyết định hệ thống phụ mà một hoạt động thuộc về.
Cơ cấu tổ chức hiện tại có thể cung cấp một trong những cơ sở để nhóm các hoạt động. Nhưng, cấu trúc tổ chức hiện tại có thể trải qua những thay đổi và tính hữu ích của hệ thống thông tin có thể bị mất.
Để nhóm các hoạt động thành hệ thống phụ, chúng tôi có sự trợ giúp từ lý thuyết tổ chức. Một trong những tính năng thiết yếu của bất kỳ cấu trúc tổ chức tốt nào là nó nhằm mục đích tạo điều kiện phối hợp các hoạt động.
Một hệ thống truyền thông hiệu quả là điều cần thiết để phối hợp tốt hơn. Do đó, điều cần thiết là phải hoạt động nhóm theo cách sao cho việc giao tiếp được tạo điều kiện thuận lợi trong nhóm và nhu cầu giao tiếp giữa các nhóm được giảm thiểu.
Với mục đích đại diện và ghi lại việc phân nhóm các hoạt động vào các hệ thống con, biểu đồ cấu trúc hoặc sơ đồ khối phân cấp được sử dụng. Hình 8.3 đưa ra biểu đồ cấu trúc hiển thị các thành phần của chu kỳ doanh thu.
Các biểu đồ cấu trúc tương tự có thể được chuẩn bị cho các cụm hoạt động khác và cuối cùng, các hệ thống phụ này được tích hợp với nhau cung cấp các khối xây dựng cho một hệ thống thông tin kế toán.
Các hệ thống phụ được xác định bằng cách phân cụm các hoạt động là các ứng cử viên nghiêm trọng để trở thành các thực thể trong cấu trúc tổ chức. Ưu điểm của phương pháp phân cụm để nhóm các hoạt động là việc phân nhóm dựa trên các chức năng và tài nguyên chứ không dựa trên các khu vực địa lý.
Một cụm như vậy trên cơ sở các chức năng đảm bảo tính đồng nhất giữa các thành viên của nhóm người được liên kết với mỗi hệ thống phụ. Tác động của tổ chức hệ thống thông tin đến cấu trúc tổ chức không phải là hiếm.
Thông thường, việc giới thiệu các hệ thống thông tin đã đi kèm với những thay đổi trong cấu trúc tổ chức vì thực tế là các hệ thống thông tin mới thay đổi cách mọi người làm việc trong một tổ chức.
Do đó, điều quan trọng hơn cả là các nhà thiết kế hệ thống thông tin làm việc liên kết tích cực với những người phát triển tổ chức trong khi nhóm các hoạt động thành các cụm và hệ thống phụ đang được thực hiện. Điều này đảm bảo không chỉ cấu trúc mới thực dụng hơn mà còn được mọi người chấp nhận hơn. Trong những trường hợp như vậy, việc chuyển đổi từ hệ thống cũ sang hệ thống mới ít đau đớn hơn và ít tốn kém hơn.
Đặt ưu tiên:
Khi các hệ thống phụ đã được xác định và tích hợp toàn bộ, các ưu tiên cần được xác định trong số các hệ thống phụ và tính năng khác nhau trong mỗi hệ thống. Hệ thống thông tin sẽ yêu cầu sự cam kết của các nguồn tài chính.
Ngoài ra, có thể có chi phí ngầm của hệ thống mới về các thay đổi cần thiết trong quá trình hoạt động. Do đó, điều cần thiết là cân nhắc ưu và nhược điểm của từng hệ thống con và hệ thống con trước khi chúng được thiết kế và thực hiện.
Mỗi hệ thống phụ được đánh giá trên cơ sở các tiêu chí đánh giá được xác định rõ được xác định theo các yếu tố thành công quan trọng (CSF). Những yếu tố này đã được xác định trong Mục 8.2.
Phương pháp khác là, động não, trong đó những người có liên quan trong tổ chức cùng nhau xác định các yếu tố đáng được xem xét trong việc xác định các ưu tiên. Dòng ý tưởng miễn phí được khuyến khích ở giai đoạn đầu tiên.
Nguyên tắc cơ bản, ở đây, là không có ý tưởng nào là ngớ ngẩn hoặc không liên quan ở giai đoạn này. Trong giai đoạn thứ hai, quá trình loại bỏ bắt đầu và sau khi thảo luận, các đề xuất được hoàn thành.
Khi danh sách các yếu tố được hoàn thành, các trọng số tương đối được chỉ định và chức năng của một tiêu chí được xác định để đánh giá từng thành phần của hệ thống thông tin kế toán được đề xuất.
2. Mô-đun cơ sở dữ liệu:
Hệ thống thông tin kế toán xử lý khối lượng dữ liệu lớn. Do đó, quản lý dữ liệu là một trong những cân nhắc chính trong quá trình phát triển của nó. Có hai cách tiếp cận cơ bản để thiết kế dữ liệu, đó là:
a. Cách tiếp cận truyền thống, theo định hướng ứng dụng và
b. Cách tiếp cận cơ sở dữ liệu.
Cách tiếp cận truyền thống:
Cách tiếp cận truyền thống để thiết kế dữ liệu được định hướng theo ứng dụng theo nghĩa là đối với mỗi ứng dụng, một bộ tệp dữ liệu riêng biệt được tạo theo yêu cầu của nó. Nói cách khác, các tệp dữ liệu được dành riêng cho một ứng dụng nhất định và theo cách 'sở hữu' bởi ứng dụng.
Ví dụ: ứng dụng phải thu tài khoản sẽ có tệp dữ liệu chính của khách hàng, tệp giao dịch bán hàng và biên nhận từ tệp giao dịch của khách hàng. Những tệp dữ liệu này chỉ được sử dụng cho các ứng dụng tài khoản phải thu.
Cách tiếp cận này phù hợp với các hệ thống thông tin kế toán nhỏ hơn vì tính đơn giản của nó. Tuy nhiên, khi hệ thống thông tin phát triển về mặt khối lượng dữ liệu và độ phức tạp của phân tích, nó cũng dẫn đến một số vấn đề nhất định.
Vấn đề cơ bản với cách tiếp cận truyền thống là các chương trình ứng dụng phụ thuộc vào các tệp dữ liệu họ sử dụng và thao tác. Do đó, bất kỳ thay đổi nào trong tệp dữ liệu (về mặt bổ sung hoặc xóa mục dữ liệu) đều yêu cầu thay đổi trong tất cả các chương trình sử dụng tệp dữ liệu.
Sự phụ thuộc dữ liệu này không khuyến khích các thay đổi trong các tệp dữ liệu dẫn đến tính không linh hoạt. Trong trường hợp không có bất kỳ công cụ nào để thực hiện các hoạt động quản lý dữ liệu loại thông thường trên dữ liệu, các phương tiện đó sẽ được đưa vào các chương trình sử dụng tệp dữ liệu. Điều này làm phức tạp chương trình. Một vấn đề khác liên quan đến việc đáp ứng truy vấn ad hoc.
Đối với loại truy vấn bất ngờ, các chương trình đặc biệt cần phải được viết. Các chương trình đặc biệt như vậy cần có thời gian để phát triển và chỉ có một lần sử dụng và do đó, rất tốn kém. Có rất nhiều sự trùng lặp trong việc ghi lại các mục dữ liệu.
Ví dụ: các mục dữ liệu như tên khách hàng, số hóa đơn, giá, v.v. có thể được bao gồm trong các tệp giao dịch cho ứng dụng xử lý đơn đặt hàng, cũng như ứng dụng phải thu. Điều này gây ra sự dư thừa trong dữ liệu.
Sự dư thừa dữ liệu dẫn đến việc sử dụng phương tiện lưu trữ không hiệu quả. Nó cũng ảnh hưởng đến chất lượng dữ liệu vì việc cập nhật một mục dữ liệu nhất định có thể không diễn ra trong tất cả các tệp nơi mục dữ liệu đó được lưu trữ.
Tiếp cận cơ sở dữ liệu:
Phương pháp hiện đại để thiết kế dữ liệu là phương pháp cơ sở dữ liệu. Cách tiếp cận này dựa trên các giả định rằng một số ứng dụng yêu cầu các bộ dữ liệu có nhiều điểm chung. Do đó, tốt hơn là có một kho lưu trữ dữ liệu chung đáp ứng các yêu cầu dữ liệu của từng ứng dụng trong hệ thống thông tin.
Kho lưu trữ chung được gọi là cơ sở dữ liệu và được quản lý bởi một hệ thống quản lý có tên là Hệ thống quản lý cơ sở dữ liệu (DBMS). DBMS là phần mềm được thiết kế đặc biệt để quản lý dữ liệu trong cơ sở dữ liệu theo các yêu cầu từ các chương trình ứng dụng, cũng như từ những người đến trực tiếp từ người dùng. Thiết kế khái niệm của môi trường cơ sở dữ liệu được hiển thị với sự trợ giúp của Hình. 8, 5.
Phương pháp cơ sở dữ liệu quan tâm đến các vấn đề của phương pháp ứng dụng. Nó đảm bảo tính độc lập dữ liệu vì DBMS đảm nhiệm luồng dữ liệu từ cơ sở dữ liệu đến các chương trình ứng dụng. Ứng dụng người dùng không cần bận tâm về vị trí của dữ liệu trong cơ sở dữ liệu. Một từ điển dữ liệu được duy trì và dữ liệu có thể được gọi bằng các từ được chỉ định trong từ điển dữ liệu.
Cách tiếp cận cơ sở dữ liệu cũng làm giảm kích thước và độ phức tạp của các chương trình ứng dụng vì loại hoạt động xử lý dữ liệu thông thường như sắp xếp được thực hiện bởi DBMS. DBMS cũng được sử dụng để phục vụ nhu cầu truy vấn ad hoc. DBMS sử dụng Ngôn ngữ truy vấn có cấu trúc (SQL) làm ngôn ngữ để giao tiếp giữa người dùng và cơ sở dữ liệu.
Ngôn ngữ rất đơn giản và khá gần với tiếng Anh. Điều này đảm bảo rằng người dùng có thể lấy thông tin từ cơ sở dữ liệu theo yêu cầu. Số lượng đào tạo được yêu cầu bởi các nhà quản lý để thực hiện các truy vấn ad hoc là tối thiểu và vài giờ đào tạo có thể cung cấp các kỹ năng cơ bản để sử dụng ngôn ngữ. Có lẽ, lợi thế quan trọng nhất của phương pháp cơ sở dữ liệu là giảm sự dư thừa trong cơ sở dữ liệu.
Có nhiều mô hình thường được sử dụng trong thiết kế cơ sở dữ liệu. Tuy nhiên, cách tiếp cận hiện đại là tuân theo Mô hình ER của thiết kế cơ sở dữ liệu. Cách tiếp cận này là cách tiếp cận từ trên xuống và các biểu đồ ER được vẽ trước đó trong Mô-đun doanh nghiệp trở thành điểm khởi đầu.
Đối với mỗi thực thể và mối quan hệ, các thuộc tính được xác định và ghi lại trong sơ đồ ER mở rộng (sơ đồ EER). Trong hệ thống thông tin kế toán, EER có thể được rút ra cho từng thực thể (giao dịch và tài khoản) và mối quan hệ (hiệu lực) cho các tài khoản giao dịch được hiển thị trong sơ đồ ER. Ví dụ, đối với giao dịch bán hàng, các thuộc tính có thể được chỉ định và ghi lại như trong Hình 8.6.
Các thuộc tính này trở thành các mục dữ liệu (các trường) trong một bản ghi trong tệp dữ liệu cho từng thực thể (trong trường hợp này là tệp giao dịch bán hàng). Tương tự, đối với các thực thể và mối quan hệ khác như sơ đồ ER (EER) mở rộng được vẽ.
Khi các thuộc tính này được xác định, có khả năng một số thuộc tính sẽ phổ biến trong các biểu đồ EER khác nhau. Để tránh trùng lặp các thuộc tính phổ biến như vậy, việc chuẩn hóa dữ liệu được thực hiện.
3. Module giao diện:
Một mô-đun giao diện xác định nguồn của các mục dữ liệu và các định dạng của màn hình nhập / xuất và đối thoại sẽ được sử dụng trong hệ thống. Nó cũng xác định các định dạng báo cáo và màn hình để điều hướng từ một phần của hệ thống thông tin sang phần khác.
Nói cách khác, mô-đun liên quan đến việc xác định giao diện giữa người dùng và máy. Tầm quan trọng của mô-đun giao diện đã tăng lên do sự giao tiếp giữa người dùng và hệ thống thông tin tăng lên.
Cả mục nhập dữ liệu và truy vấn dữ liệu đã trở nên tương tác. Trong nhiều trường hợp, các biểu mẫu đầu vào được loại bỏ khỏi quy trình và việc nhập dữ liệu diễn ra trực tiếp. Các yêu cầu thay đổi của truy vấn dữ liệu khiến nhiều biểu mẫu báo cáo quá cứng nhắc. Màn hình báo cáo tương tác cung cấp tính linh hoạt cao hơn trong truy vấn dữ liệu và cho phép người dùng xác định định dạng báo cáo để xem và in.
Màn hình nhập:
Các màn hình đầu vào được xác định theo ánh sáng của quá trình tự nhiên của hoạt động kinh doanh. Do đó, chúng phụ thuộc chủ yếu vào các biểu mẫu được sử dụng để ghi lại dữ liệu theo cách thủ công khi chúng được doanh nghiệp nhận lần đầu tiên. Các hình thức này, trong một hệ thống thông tin kế toán, có thể bao gồm hóa đơn, đơn đặt hàng, đơn đặt hàng, chứng từ chi phí, v.v.
Do đó, trong mô-đun giao diện, các biểu mẫu cũng được xem xét; màn hình được thiết kế lại và đầu vào được xác định trong ánh sáng của các hình thức được sử dụng bởi doanh nghiệp. Trong một hệ thống thông tin kế toán, người ta cần cẩn thận hơn về thiết kế màn hình.
Một cải tiến nhỏ trong màn hình nhập dữ liệu giúp nhập dữ liệu có thể giúp tiết kiệm đáng kể vì số lần màn hình nhập dữ liệu được sử dụng là rất lớn. Các yếu tố sau có thể được ghi nhớ trong khi thiết kế màn hình nhập liệu:
(a) Phù hợp với các hình thức:
Các định dạng màn hình đầu vào phải phù hợp với các hình thức đầu vào. Đôi khi, nó trả tiền để áp dụng định dạng tương tự được sử dụng bởi biểu mẫu đầu vào. Trong phạm vi có thể, thậm chí màu nền của màn hình có thể được khớp với màu của biểu mẫu nhập.
(b) Tương tác:
Màn hình nhập phải tương tác. Nó sẽ chỉ ra lỗi trong nhập dữ liệu ngay tại thời điểm nhập và cho phép sửa chữa. Mỗi mục dữ liệu phải có một số điều kiện xác thực dữ liệu và mọi vi phạm điều kiện xác thực dữ liệu đó phải được tự động làm nổi bật tại thời điểm nhập dữ liệu.
Ví dụ: màn hình nhập dữ liệu để nhập hóa đơn phải chỉ ra lỗi nhập ngày nếu ngày không hợp lệ. Ngày có thể không hợp lệ vì nằm ngoài kỳ kế toán hoặc tháng được nhập lớn hơn mười hai.
(c) Tính nhất quán:
Các màn hình đầu vào phải nhất quán trong việc xác định các thuật ngữ và vị trí cho một số loại mục dữ liệu phổ biến nhất định. Nó giúp giảm thời gian đào tạo vì nó cải thiện sự quen thuộc; ví dụ: ngày giao dịch có thể luôn được đặt ở góc bên phải của mỗi tài liệu giao dịch.
(d) Đơn giản:
Một trong những tính năng cơ bản của màn hình nhập liệu tốt là sự đơn giản. Quá nhiều phần được tô sáng, nhấp nháy các giá trị hoặc thuộc tính hoặc đặt quá nhiều hộp và gạch chân chỉ làm tăng thêm sự phức tạp và nhầm lẫn. Đôi khi, tiếng bíp được sử dụng để chỉ ra lỗi nhập dữ liệu. Cần phải sử dụng thận trọng những tiếng bíp như vậy và nói chung, những điều này nên tránh.
(e) Linh hoạt:
Màn hình đầu vào phải có thể sửa đổi. Nó nên cho phép người dùng thực hiện các sửa đổi về mặt bổ sung hoặc xóa và di chuyển mục dữ liệu. Thủ tục sửa đổi nên đơn giản. Ngày nay, Trình tạo màn hình có sẵn từ các nhà sản xuất phần mềm khác nhau cung cấp các tính năng như kéo và sửa / thả bất kỳ mục dữ liệu nào khỏi màn hình bằng cách sử dụng thiết bị trỏ thông thường như chuột.
(f) Tùy chỉnh được thực hiện:
Các màn hình phải được tùy chỉnh thực hiện cho từng loại người dùng. Điều này sẽ làm giảm quá trình bắt đầu và nhập cảnh quá dài.
Màn hình báo cáo:
Các báo cáo có thể được chuẩn bị để phân tích thêm bởi một số chương trình máy tính khác hoặc bởi chính người dùng. Dữ liệu được định hướng để xử lý bởi các chương trình máy tính, như bảng tính, gói thống kê, bộ xử lý văn bản, được lưu trong các tệp dữ liệu.
Tốt hơn là đặt chúng ở định dạng dữ liệu tiêu chuẩn để chúng có thể được truy cập dễ dàng. Các báo cáo có nghĩa là cho người dùng thường được lưu giữ dưới dạng văn bản, bảng và biểu đồ. Cần nỗ lực để đảm bảo rằng các báo cáo được thực hiện và truyền đạt kịp thời, chính xác, rõ ràng và với chi phí thấp.
Màn hình đối thoại:
Các màn hình hội thoại là những màn hình được sử dụng để xác định và thực hiện các nhiệm vụ trong hệ thống thông tin. Họ xác định những gì có thể được thực hiện với sự trợ giúp của hệ thống thông tin, cách điều hướng từ một nhiệm vụ / thủ tục này sang một nhiệm vụ khác và cách thực hiện các nhiệm vụ khác nhau mà hệ thống thông tin cho phép.
Những màn hình này nên đơn giản và rõ ràng. Sự đơn giản có thể được giới thiệu bằng cách cung cấp Giao diện người dùng đồ họa (GUI) và có số lượng mục menu hạn chế trong một màn hình. Quy trình điều hướng từ menu này sang menu khác phải đơn giản, đúng trình tự và dễ làm theo. Nó cũng nên chỉ ra sai lầm trong việc thực hiện các tùy chọn và được nhắc nhở để sửa quy trình.
Công cụ CASE cho thiết kế màn hình:
Một loạt các công cụ CASE có sẵn để thiết kế biểu mẫu, màn hình và báo cáo. Các công cụ này có lợi thế là cung cấp môi trường thiết kế linh hoạt và dễ hiểu ngay cả đối với người dùng mới.
Vì các công cụ này có các phương tiện tạo mẫu màn hình, nên có thể có sự tham gia lớn hơn của người dùng trong quá trình thiết kế màn hình. Tất nhiên, các công cụ như vậy cho phép thay đổi nhanh chóng và cải thiện năng suất của các lập trình viên bằng cách tạo mã để thực hiện cuối cùng. Điều này dẫn đến giảm thời gian phát triển.
Khi các biểu mẫu, màn hình đầu vào / đầu ra và màn hình hộp thoại đã sẵn sàng, chúng cần được kiểm tra và sửa đổi cho phù hợp. Các hình thức và màn hình được thiết kế bằng các công cụ CASE có thể dễ dàng sửa đổi. Do đó, những nỗ lực phải được thực hiện để cải thiện khả năng chấp nhận của hệ thống bằng cách kiểm tra và sửa đổi đúng các biểu mẫu và màn hình.
4. Module ứng dụng:
Mô-đun này mở rộng các hệ thống phụ đã được xác định trong mô-đun doanh nghiệp. Đối với mỗi hệ thống phụ được xác định trong biểu đồ cấu trúc, quy trình xử lý chi tiết được xác định trong mô-đun này.
Nói cách khác, mô-đun ứng dụng chủ yếu liên quan đến các quy trình liên quan đến việc chuyển đổi dữ liệu đầu vào thành các giá trị sẽ tạo thành một phần của các báo cáo như được xác định trong mô-đun giao diện. Có thể lưu ý rằng chỉ những quy trình được xác định rằng
(a) Thay đổi các giá trị trong cơ sở dữ liệu hoặc
(b) Đó không phải là một phần của cơ sở dữ liệu nhưng được yêu cầu trong các báo cáo được xác định trong mô-đun giao diện.
Các giá trị đã tồn tại trong cơ sở dữ liệu có thể được truy cập bằng ngôn ngữ truy vấn DBMS theo yêu cầu của người dùng mà không cần phát triển chương trình cho mục đích này. Do đó, nhiệm vụ của mô-đun ứng dụng bị giảm bởi công việc đã được thực hiện trong thiết kế cơ sở dữ liệu và thiết kế màn hình.
Sơ đồ luồng dữ liệu:
Vai trò của người quản lý trong mô-đun này về cơ bản là xác định quy trình xử lý cơ bản. Các thuật toán chi tiết thường được xác định và ghi lại bởi chuyên gia hệ thống thông tin, tất nhiên, với sự giúp đỡ tích cực từ người quản lý.
Công cụ được sử dụng để thể hiện các quy trình sẽ được thực hiện để chuyển đổi dữ liệu đầu vào thành đầu ra là Sơ đồ luồng dữ liệu (DFD). Nó mô tả dòng dữ liệu. Nó định nghĩa những gì phải được thực hiện và bỏ qua cách nó được thực hiện hoặc làm thế nào nó được thực hiện trước đó. Cách tiếp cận này cho phép thay đổi trong hệ thống và các điểm yếu của hệ thống hiện tại có thể được loại bỏ theo phương pháp này.
Biểu tượng DFD:
Có bốn biểu tượng cơ bản được sử dụng trong DFDs. Họ đang:
(i) Kẻ hủy diệt:
Terminator là một nguồn bên ngoài của luồng dữ liệu hoặc bên ngoài của dữ liệu. Nó là một thực thể hoặc đối tượng bên ngoài như khách hàng, nhà cung cấp, cổ đông, v.v. Vì các đầu mối là các thực thể bên ngoài, nên việc liên lạc giữa các đầu mối được loại trừ khỏi hệ thống. Dấu kết thúc được ký hiệu bằng một hình chữ nhật (nói chung, bị bóng) và nhãn được đặt trong hình chữ nhật.
(ii) Luồng dữ liệu:
Luồng dữ liệu mang một loạt các mục dữ liệu liên quan đến sự kiện do bộ kết thúc khởi tạo. Nó được ký hiệu bằng một mũi tên trong DFD và hướng của dòng chảy được chỉ định bởi hướng của mũi tên. Các mũi tên, nói chung, được dán nhãn trừ khi chúng được hướng đến hoặc từ các tệp dữ liệu. Như đã chỉ ra trước đó, luồng dữ liệu giữa hai đầu mối không được bao gồm trong DFD và do đó, dữ liệu không thể chảy trực tiếp giữa hai đầu mối.
(iii) Quy trình:
Quá trình biến đổi dữ liệu đến để chuyển hướng sang lưu trữ dữ liệu hoặc bộ kết thúc. Nó được ký hiệu bởi một hình chữ nhật với các góc tròn hoặc hình tròn. Nó được dán nhãn với một động từ, tất nhiên.
(iv) Lưu trữ dữ liệu:
Các tệp là kho lưu trữ dữ liệu trong các hệ thống thông tin và được thể hiện trong DFD dưới dạng hình chữ nhật mở. Nói chung, chúng tương ứng với các bảng trong cơ sở dữ liệu. Một khung nhìn một phần của sơ đồ luồng dữ liệu để xử lý đơn đặt hàng được trình bày trong Hình 8.7.
Có thể lưu ý rằng một số biểu tượng bổ sung và các biến thể nhỏ trong các biểu tượng đại diện cho các thành phần khác nhau của DFD cũng được sử dụng. Các biểu tượng trên là những biểu tượng được sử dụng phổ biến nhất và theo quy ước đồ họa được đề xuất bởi Gane và Sarson.
Nhiều lần, một người quản lý nhận thấy việc vẽ DFD rất khó khăn và bực bội. Mỗi lần rút ra một DFD, người ta thấy rằng đã bỏ qua một hoặc một khía cạnh khác của luồng dữ liệu. May mắn thay, các công cụ CASE có sẵn có các phương tiện để tạo và sửa đổi DFD. Tuy nhiên, người mới bắt đầu nên làm theo các bước sau để khắc phục vấn đề này:
(a) Xác định tất cả các luồng dữ liệu đầu vào và luồng dữ liệu đầu ra riêng biệt cùng với các đầu cuối, đặt các luồng dữ liệu đầu vào ở bên trái và luồng dữ liệu đầu ra ở bên phải.
(b) Dán nhãn cho các đầu mối bằng cách sử dụng danh từ luồng dữ liệu hoặc tên tính từ.
(c) Xác định các quá trình chuyển tiếp từ các luồng dữ liệu đầu vào và ngược lại từ các luồng dữ liệu đầu ra cho đến khi chúng gặp nhau ở giữa.
(d) Dán nhãn cho các quá trình sử dụng tên động từ.
Người quản lý phải được chuẩn bị để vẽ lại DFD vì nhiều lần, các luồng dữ liệu trở nên rõ ràng đối với người quản lý chỉ sau khi vẽ DFD. Sự tham gia của người dùng trong giai đoạn này rất hữu ích không chỉ trong việc giảm nỗ lực từ phía người quản lý mà còn trong việc cải thiện DFD.
Kiểm tra DFD:
Có ý kiến cho rằng DFD phải được kiểm tra kỹ lưỡng trước khi hoàn thành. Sau đây là một số lỗi phổ biến trong thiết kế DFD:
a. Nhãn terminator có thể là tên của một người hoặc một doanh nghiệp thay vì lớp. Ví dụ, một terminator có thể được dán nhãn là M / s. BR Ltd. thay vì nhà cung cấp duy nhất. Một sai lầm khác có thể là nhà mạng được đặt làm đầu cuối thay vì thực thể bên ngoài liên quan trực tiếp đến luồng dữ liệu.
b. Dữ liệu có thể chảy trực tiếp từ một terminator này đến một terminator khác.
c. Không có luồng dữ liệu có thể được chỉ định đến hoặc từ một quá trình.
d. Luồng dữ liệu được chỉ định từ terminator đến kho lưu trữ dữ liệu (tệp) hoặc từ tệp đến terminator hoặc giữa hai tệp mà không xử lý.
e. Các quy trình được dán nhãn là các đối tượng, chẳng hạn như hóa đơn hoặc danh từ, chẳng hạn như nhân viên đặt phòng.
Sau khi DFD được rút ra cho từng hệ thống phụ, các chi tiết xử lý trong tương lai có thể được đưa ra và mô tả bằng tiếng Anh có cấu trúc (mã psedo). Các mã psedo này sau đó được sử dụng để mã hóa các ứng dụng. Vai trò của người quản lý trong quy trình này chỉ giới hạn trong việc giúp các hệ thống thông tin chuyên nghiệp trong việc xác định và hiểu các thuật toán liên quan đến quá trình xử lý.
5. Module thực hiện:
Mô-đun này chủ yếu liên quan đến việc thử nghiệm hệ thống, đào tạo người dùng và cài đặt hệ thống.
Kiểm tra hệ thống:
Việc kiểm tra các mô-đun khác nhau được thực hiện ở các giai đoạn khác nhau của quá trình phát triển. Nguyên tắc vàng cần được ghi nhớ trong khi thử nghiệm là thử nghiệm nên được thực hiện với mục đích xác định các cách thức mà hệ thống có khả năng thất bại. Không nên với mục tiêu chứng minh rằng hệ thống sẽ hoạt động theo đặc điểm kỹ thuật thiết kế. Kiểm tra hệ thống là quá trình tìm kiếm câu trả lời cho hai câu hỏi cơ bản:
1. Hệ thống thông tin có phục vụ nhu cầu thông tin của doanh nghiệp không? Quá trình tìm kiếm câu trả lời cho câu hỏi này được các chuyên gia hệ thống thông tin gọi là quá trình xác nhận hệ thống.
2. Hệ thống thông tin có hoạt động chính xác không? Quá trình xác minh tìm kiếm câu trả lời cho câu hỏi này.
Vì bản chất và mức độ nghiêm trọng của lỗi là khác nhau ở các giai đoạn phát triển hệ thống khác nhau, các thử nghiệm khác nhau được thực hiện ở các mô-đun khác nhau và tại toàn bộ hệ thống.
Bài kiểm tra đơn vị:
Các thử nghiệm được sử dụng ở cấp độ mô-đun có thể được gọi là thử nghiệm đơn vị. Các thử nghiệm này được thực hiện để phát hiện lỗi trong giao diện, cơ sở dữ liệu, hoạt động số học và logic điều khiển. Chúng được thực hiện bằng cách chạy một mô-đun của hệ thống thông tin trên dữ liệu thử nghiệm được thiết kế đặc biệt để kiểm tra xem hệ thống:
a. Chấp nhận loại dữ liệu không chính xác (ví dụ: chấp nhận giá trị số cho tên);
b. Chấp nhận ngoài dữ liệu phạm vi hợp lệ (ví dụ: chấp nhận ngày có tháng lớn hơn 12);
c. Nguyên nhân nhảy không chính xác từ một thủ tục sang một thủ tục khác.
Kiểm tra hệ thống:
Vì các thử nghiệm đơn vị được tiến hành một cách cô lập, điều cần thiết là các thử nghiệm tích hợp phải được tiến hành để kiểm tra xem các đơn vị này có hoạt động chính xác như một nhóm hay không. Do tính đa dạng của lỗi, các chiến lược kiểm tra khác nhau sẽ được tuân theo để kiểm tra tính hợp lệ và xác minh hệ thống. Fertucks đề xuất ba chiến lược để kiểm tra hệ thống thông tin:
(a) Xóa hộp kiểm tra:
Trong chiến lược này, các thử nghiệm được thiết kế để xác định xem các quy trình tiếp theo để xử lý có khớp với các yêu cầu của ứng dụng hay không. Điều này có thể đạt được với sự giúp đỡ của các chuyên gia hệ thống thông tin đồng nghiệp, những người không liên quan trực tiếp ở giai đoạn phát triển.
Ngoài ra, phương pháp đi bộ có cấu trúc có thể được sử dụng. Trong phương pháp này, một nhóm người xem xét các quy trình, trước tiên hãy xem xét các phần dễ bị lỗi và xác định các sửa chữa cần được thực hiện. Sau đó, các thành viên nhóm đánh giá đầu ra mà hệ thống sẽ cung cấp cho một loại đầu vào nhất định và kiểm tra xem đầu ra của hệ thống có chính xác hay không.
(b) Kiểm tra hộp đen:
Trong chiến lược này, hệ thống được kiểm tra dữ liệu không hợp lệ hoặc dữ liệu có thể gây ra lỗi trong hoạt động của hệ thống. Đầu ra được kiểm tra để thiết lập xem có bất kỳ lỗi nào xảy ra không. Ví dụ: dữ liệu có thể chứa giá trị âm cho số lượng đặt hàng hoặc giá trị phân số cho một biến chỉ có thể lấy toàn bộ giá trị.
(c) Thử nghiệm hộp thử:
Chiến lược này giả định rằng không bao giờ có thể cung cấp một hệ thống thông tin hoàn toàn không có lỗi. Vì vậy, sau tất cả các thử nghiệm và sửa đổi, cần phải ước tính số lượng lỗi vẫn còn trong hệ thống. Để ước tính con số này, một vài lỗi có thể được cố tình đưa vào hệ thống. Sau đó, các bài kiểm tra lại được tiến hành để phát hiện lỗi.
Tỷ lệ lỗi được giới thiệu được phát hiện được lấy làm ước tính tỷ lệ lỗi thực sự được phát hiện trong các thử nghiệm trước đó. Do đó, nếu 90% lỗi được giới thiệu được phát hiện trong quá trình kiểm tra hộp đánh dấu trong khi tổng số 450 lỗi được phát hiện ban đầu trong quá trình kiểm tra hộp rõ ràng và kiểm tra hộp đen, điều đó có nghĩa là 50 lỗi thực sự tiếp tục không bị phát hiện trong hệ thống.
Cài đặt:
Cài đặt là một quá trình thay thế hệ thống cũ bằng một hệ thống mới. Nhìn rộng ra, có bốn cách tiếp cận để cài đặt. Việc cài đặt 'lạnh' được thực hiện khi hệ thống cũ bị ngừng ngay lập tức và được thay thế bằng một hệ thống mới.
Cài đặt như vậy có lợi thế là điều chỉnh tâm lý nhanh hơn với thực tế là hệ thống mới sẽ được sử dụng. Tuy nhiên, cách tiếp cận như vậy có thể không phù hợp nếu dữ liệu cũ từ hệ thống trước đó có giá trị hoặc hệ thống mới có một số vấn đề. Để cài đặt hệ thống thông tin kế toán, phương pháp này đã không được chấp nhận. Các phương pháp thay thế bao gồm:
(a) Cài đặt thí điểm:
Một hệ thống có thể được cài đặt để chỉ sử dụng bởi một nhóm người dùng đại diện được chọn để kiểm tra hệ thống bằng cách thực sự sử dụng nó. Những người dùng khác tiếp tục sử dụng hệ thống cũ. Khi các vấn đề trong hệ thống được quan tâm, những người dùng khác cũng bắt đầu sử dụng hệ thống. Cách tiếp cận này cũng không phổ biến lắm đối với các hệ thống thông tin kế toán vì toàn bộ cơ sở dữ liệu kế toán phải được cập nhật trước khi người dùng có thể sử dụng nó.
Yêu cầu thông tin của người dùng vượt qua ranh giới của các bộ phận và bộ phận trong sơ đồ tổ chức. Tuy nhiên, cách tiếp cận này có thể được sử dụng cho các thực thể kế toán hoàn chỉnh như chi nhánh, văn phòng khu vực, v.v. Do đó, một hệ thống thông tin kế toán có thể được sử dụng bởi các chi nhánh được chọn. Một khi chúng được phát hiện là không có lỗi, chúng cũng có thể được sử dụng bởi các nhánh khác.
(b) Cài đặt theo pha:
Theo cách tiếp cận này, việc cài đặt diễn ra theo từng giai đoạn. Các giai đoạn này là các thành phần độc lập của hệ thống thông tin. Vì vậy, vòng đời doanh thu của một hệ thống thông tin kế toán có thể được cài đặt lần đầu tiên và các vòng đời khác có thể nối tiếp nhau. Cách tiếp cận này giúp tập trung vào một phần được chọn của hệ thống. Nó giúp cải thiện khả năng chấp nhận hệ thống giữa những người dùng vì nó cho phép người dùng đối phó với sự thay đổi một cách dễ dàng.
(c) Cài đặt song song:
Cài đặt song song có nghĩa là chạy đồng thời cả hệ thống cũ và hệ thống mới trong một thời gian nhất định cho đến khi tiện ích của hệ thống mới được chứng minh. Phương pháp này là phổ biến nhất cho hệ thống thông tin kế toán vì đây là phương pháp an toàn nhất trong tất cả các phương pháp khác. Khó khăn duy nhất, ở đây, là chi phí của hoạt động song song và xu hướng kéo dài thời gian chạy song song bởi những người chống lại sự thay đổi.
Đánh giá bài thực hiện:
Mỗi hệ thống phải được xem xét sau khi thực hiện xong. Việc xem xét như vậy không chỉ giúp xác định các điểm yếu của hệ thống mà còn chuẩn bị một chương trình nghị sự để sửa đổi cho tương lai. Trên thực tế, đó là một quá trình học tập. Kiểm toán hệ thống cũng có thể được thực hiện để kiểm tra mức độ thành công của hệ thống, về chi phí, tiến độ giao hàng, tính đầy đủ và chất lượng.
