Introduction
Due to changes in technology, the nature of work done by most accountants and auditors has changed significantly (Gelinas, Dull, and Wheeler 2011). This is partly because computer systems can be used to automate transactions and provide information to be used by accountants and auditors. With the aid of such systems, accountants can summarize transactions and organize useful financial data in standardized formats. As a result these accounting packages make a major reduction in the tedious routine associated with data management and record keeping (Gelinas et al., 2011).
These computerized systems allow accountants and auditors increased mobility because client’s computers can be used to extract information via resources such as the internet (Gelinas et al., 2011). This trend has caused a growing number of accounting professionals to specialize in correcting software problems or in the development and creation of software. The result is that many accounting professionals also undertake technical tasks such as controlling, implementation and audits of computer networks and systems (Gelinas et al., 2011).
This trend has made it easier for decision makers to access information and made the task of accounting more interesting and challenging. This suggests that the accountants of today require both advanced accounting skills and some knowledge in the field of information systems. This is also crucial given the recent legislative changes such as those mentioned in the Sarbanes-Oxley Act of 2002 (Gelinas et al., 2011). Under this law, it is suggested that for a company to comply with the legal requirements, it must identify, document and evaluate adequate internal controls (Gelinas et al., 2011). Given the rapid pace at which computerized systems are changing such legislation implies accountants of the future will require some knowledge of computer based systems. In this report the discussion will attempt to provide a description of how to develop a suitable computer based system for a home owners association. In doing this task the report will mention consideration given in creation of inputs, outputs and controls used in the creation of the computer based system.
Identifying Inputs
Given the need to automate specific aspects of the home owner’s accounting information system it becomes crucial to identify the data items that will be used as inputs. To identify these inputs the systems analyst can use either data flow diagrams of system flowcharts to conceptualize the actual system (Satzinger, Jackson, & Burd 2008). However, the approach used will also be influenced by whether the proposed system is to be constructed using a traditional of object oriented approach. This is because both traditional and object oriented approaches of software development differ in how a systems response to an event is modeled (Satzinger et al., 2008).
In the traditional approach the system is viewed as a collection of processes which interact to accomplish a task. On the other hand an object oriented approach views the system as a collection of objects that interact to accomplish a specified task (Satzinger et al., 2008). Given that this project can be implemented using both approaches a brief description of the procedure of identifying inputs will be discussed for both methods. As it has been mentioned earlier, the traditional approach considers the system as a group of processes interacting to accomplish a specific task. To assist in the task of identifying processes, analysts may use graphic constructs such as the data flow diagram (Satzinger et al., 2008). Though there are other models such as activity diagrams, the data flow diagram is the most commonly used in the traditional approach.
Many data flow diagrams can be used to identify system requirements. The data flow diagrams can be modeled to either provide a higher or lower view of the proposed information system (Satzinger et al., 2008). The highest and most abstract view of the system is shown using a context (data flow) diagram. In this diagram all external agents and data flows in and out of the system are shown in a single diagram where the entire system is represented as a single process (See Appendix A).
After the context diagram has been constructed each trigger for an external event can be considered as input for an external data flow. In addition to that the source of this trigger is also considered an external agent (Satzinger et al., 2008). The analyst will normally be required to create each segment of the DFD separately, concentrating on each part of the proposed system. As the analyst creates further fragments one at a time, each and every process triggered is identified and the inputs to be used at every stage of the systems can be identified (Satzinger et al., 2008).
After repeated decomposition of the steps followed within the system, the analyst will eventually arrive at a point where further definition is unnecessary. At this point the analyst may consider the use of an alternative approach of defining the system. One such approach is known as Structured English. This approach involves the use of brief statements to describe a process very carefully (Satzinger et al., 2008). Structured English has a strong resemblance to programming statements without the reference to computer based concepts. The rules of structured English are followed and indentation is used for clarity. Some statements are instructions and the procedure always starts at the top ending at the bottom (Satzinger et al., 2008). This approach will also prove useful when it comes to identification of outputs required.
As mentioned earlier in the report the proposed accounting information system can also be developed using an object oriented approach. The use of object oriented programming to solve computer system problems is common due to the ability to store additional information about an entity. However, in an object oriented model more complex data types can be stored e.g. pictures, etc (Gelinas et al., 2011). These object oriented models allow the system analyst store abstract data types that allow the user to define the attributes later. This overcomes one weakness of relational data models which limits the data to what can be stored in table columns (Gelinas et al., 2011).
An object allows us to store data which can be used in a relation and actions which can be performed on that object. These instructions or actions are commonly known as encapsulated methods (Gelinas et al., 2011). In addition to this objects can be placed in a hierarchy so that low level objects can inherit attributes from higher level objects. In the construction of a computerized system using the object oriented approach it is common for analysts to develop entity relationship diagrams (Gelinas et al., 2011).
This approach of developing a database from the top down is also sometimes referred to as the event driven approach. This is because the approach allows us to consider all aspects of business events and processes (Gelinas et al., 2011). The consideration of all possible aspects of an event, including those not currently in use the analyst gains insight that can allow them design a better computerized system. This is because as opposed to merely automating current practices the analyst can make changes that will improve the system. For example, the analyst can consider collecting new information about customers that can be used in marketing thus increasing effectiveness of the advertising budget (Gelinas et al., 2011).
Anything that the business requires information about can be considered an entity. Further information on entities can be collected by interviewing system users to identify entities that each group of users requires (Gelinas et al., 2011). On completion of this task the analyst can use the information to establish the relationships that exist between various entities. These relationships can be useful in identifying other potential uses of the data. For example, the data on sales can be used to create reports that can help identify good markets and potentially good areas to increase advertising (Gelinas et al., 2011).
Identifying Controls
Given that the information contained in the database of this system is sensitive it will be essential to have some controls that can prevent possible loss or damage to the records. In regard to such controls, access controls are approaches used to restrict and provide access to specific system features (Kim & Solomon 2010). In day to day activities we may use keys to unlock various locks, doors, cabinets, etc, these are access controls. In the case of the computerized accounting information system the proposed system will be required to provide controls to manage four separate tasks with regard to control.
The first task is the system must provide a mechanism to authorize the systems users. This suggests there should be a mechanism to check who is allowed access and what actions does the level of authorization permit (Kim & Solomon 2010). The system should therefore grant or deny access to the system and resources based on the policy defined.
Also in relation to control, it has been observed that the system should be located in a secure area where access to the system can be monitored. This statement suggests that in addition to the system based control there should a physical barrier to help limit access to the system (Kim & Solomon 2010). These mechanisms are put in place to ensure only the permitted users have access to the system and the resources stored on it. This protects a system resource from unauthorized use and in some cases restricts the actions the user is allowed to take on a specific resource.
The final type of control mechanism that the system requires is accountability controls. These controls are placed to track actions back to the user who makes the changes to the system (Kim & Solomon 2010). In addition to granting permission to the user, controls are required which keep track of the user when various changes or events are taking place on the system. Such controls are useful in that they make it easy to trace faults down to an individual or group of individuals (Kim & Solomon 2010).
Another wise solution to cater for control is the provision frequent back up of data held on the system at an alternative location (Hall 2010). Other than having control of the physical system it is also good practice to offer a mechanism that allows the system survive some form of disaster. This above control is considered due to the fact that there are many ways that a system can become vulnerable other than by human access. Natural disasters such as storms and floods have the potential of destroying entire systems in cases where there is no consideration given to backing up data (Hall 2010). The process of backing up data can be handled once after a set duration or even on a daily basis.
Potential Problem Areas
As it has been mentioned, the owner of the business intends to expand in the next few years. In the course of this expansion, it is expected that the number of customers and employees will grow. This growth could cause potential problems in relation to the concurrency of data maintained on the system (Sumathi & Esakkijaran 2007). However, for the system to succeed there must be a mechanism in place to handle issues of concurrency in a distributed environment.
Due to this potential problem, the level of concurrency is among the most important issues to consider when dealing with distributed systems (Sumathi & Esakkijaran 2007). For this reason, the concurrency control mechanisms must attempt to identify a suitable trade-off between maintaining consistency of the database and maintaining a high level of concurrency. For transactions to maintain internal consistency the simplest means of avoiding concurrency problems is to execute each transaction alone. One approach is to serialize transactions or use a time stamp mechanism when dealing with transactions (Sumathi & Esakkijaran 2007).
In addition to concurrency control mechanisms, a distributed system is prone to errors that result from deadlocks. A deadlock is a situation where a request has been made to access a single resource by two or more actors in the system (Sumathi & Esakkijaran 2007). Due to this the system becomes locked as each system waits to be allocated the resource. The resource could a specific record in a file which needs to be updated. To handle this, the system needs to have a mechanism by which it can check if such a situation has occurred and resolve it immediately.
Some of the inputs that could form a part of this system include:
- Customer id, First Name, Last name, Telephone, Address, Check Id, Amount, Account balance, etc.
Some of the outputs include:
- Monthly payment report, Late payment report, Balance report, etc.
References
Gelinas, U.J., Dull, R. B., & Wheeler, P. (2011). Accounting Information Systems. Mason, OH: South-Western Cengage Learning.
Hall, J. A. (2010). Accounting Information Systems. Mason, OH: Cengage Learning.
Kim, D., & Solomon, M. (2010). Fundamentals of Information Systems Security. Sudbury, MA: Jones & Bartlett Learning, LLC.
Satzinger, J., Jackson, R., & Burd, S. (2008). Systems Analysis & Design in a Changing World. Boston, MA: Course Technology.
Sumathi, S., & Esakkijaran, S. (2007). Fundamentals of Relational Database Systems. Berlin: Springer.
Appendix
Appendix A: Context Diagram (Dataflow Diagram)
Appendix B: Level 0 and Level 1 Dataflow diagrams
Appendix C: Inheritance in Object oriented Model
Appendix D: Entity Relationship Diagram
