Presentation is loading. Please wait.

Presentation is loading. Please wait.

70-358 Chapter 22, Part 2 70-358.

Similar presentations


Presentation on theme: "70-358 Chapter 22, Part 2 70-358."— Presentation transcript:

1 70-358 Chapter 22, Part 2 70-358

2 Physical Systems Design Systems Analysis Conceptual Systems Design
Output Design File and DB Design Input Design Program Design Proce- dures Design Controls Design Implementation and Conversion Operation and Maintenance

3 There text discusses two principal types of data input:
Input Design Systems designers must identify the different types of data input and optimal input methods. There text discusses two principal types of data input: Forms Computer screens - Considerations for input design are shown in Table 22-4 on page 687. 70-358

4 70-358

5 1) General Considerations 2) Introductory Section Of Form
Forms Design Table 22-5 on page 688 provides some considerations for evaluating existing forms and designing new ones: 1) General Considerations 2) Introductory Section Of Form 3) Main Body Of Form 4) Conclusion Section Of Form 70-358

6 1. General Considerations
Preprint as much data as possible. Use appropriate weight and grade of paper. Use bold type, double-thick lines, and shading to highlight different parts of the form. Use a standard size and one that is consistent with requirements for filing, binding, or mailing. If mailed to external parties, position the address for placement in a window envelope. Have copies of the form printed in different colors to facilitate accurate distribution. Include clear instructions for completing the form. 70-358

7 2. Introductory Section Of Form
Form date at top in bold type. Consecutively numbered. Company name and address and other contact info on forms sent to external parties. 70-358

8 Provide sufficient field length for each data item.
3. Main Body Of Form Group logically related information together such as customer name, number, etc. Provide sufficient field length for each data item. Provide for proper sequencing of data entry. Codes, check-offs, abbreviations, etc. should be adequately explained. 70-358

9 Provide space for final disposition of form.
4. Conclusion Provide space for final disposition of form. Provide space for transaction approval signature(s). Provide space for approval date. Provide spaces for numeric and currency totals. Indicate on form distribution of various copies. 70-358

10 Designing Computer Screens
It is more efficient to enter data directly into the computer than to record it on paper for subsequent entry. Therefore, it’s important to design computer screens for input as well as output. 70-358

11 Computer screens are most effective when these procedures are followed:
Organize the screen so data can be entered quickly, accurately and completely. Minimize input by retrieving as much as possible from the system. Example: If the customer number is entered, retrieve the name/address data from the system. Enter data in the same order as displayed on paper forms used to capture the data. 70-358

12 Complete the screen from left to right and top to bottom
Complete the screen from left to right and top to bottom. Group together logically related data. Design the screen so users can jump from one data entry location to another or use a single key or go directly to screen locations. 70-358

13 Make it easy to correct mistakes
Make it easy to correct mistakes. Clear and explicit error messages that are consistent across all screens are essential. Restrict the amount of data on a screen to avoid clutter. Limit the number of menu options on a single screen. 70-358

14 Program Design Actual program development is usually longest part of physical design stage. 70-358

15 70-358

16 To improve software quality, organizations should develop programming standards. This contributes to consistency among programs and makes them easier to read and maintain. Consider doing structured program walk-throughs to find incorrect logic, errors, omissions, or other problems. 70-358

17 The text provides eight steps for developing software:
Although accountants need not be computer programmers, they should understand how software is created. The text provides eight steps for developing software: 70-358

18 Step 1 Determine user needs.
Systems analysts consult with users and agree on software requirements. (Step 1 is performed as a part of the systems analysis phase of the SDLC). 70-358

19 Step 2 Develop a plan. A development plan is produced and documented. (Step 2 is done during conceptual systems design and may carry over to the beginning of physical design). 70-358

20 Step 3 Write program instructions (computer code).
This is when the computer code (or program instructions) is written. 70-358

21 Step 4 Test the program. Debugging is discovering and eliminating program errors. After a program is coded, a visual and mental review, referred to as desk checking, is conducted to discover programming errors. Programs are tested for logic errors using test data that simulates both valid transactions and all possible error conditions. 70-358

22 Large programs are often tested in three stages:
Individual program modules. The linkages between the module and the control module. The interfaces between the program being tested and other application programs. 70-358

23 As quoted in the text, the Gartner Group estimates that bugs that are not discovered until later in the SDLC cost 80% to 1,000% more to fix than those discovered earlier. Auditors will be extremely interested in testing if they intend to rely on systems and may do their own testing of programs. Documentation of testing procedures, output and results needs to be retained for audit review. 70-358

24 FOCUS 22-1 on page 689 discusses the difficulty of testing software and the consequences of releasing software with undetected errors. Most of the tasks in steps 3 and 4 are done during systems design and are completed during systems implementation. 70-358

25 Step 5 Document the program.
Documentation explains how programs work and is used to help find, correct and resolve errors. Documentation includes flowcharts, record layouts, E-R diagrams, REA data models, narrative descriptions of the system, etc., organized in a manual. Steps 5 and 6 started in design phase and usually completed in installation phase 70-358

26 Step 6 Train program users.
Program documentation is often used to train users. 70-358

27 Step 7 Install the system.
All system components, including the programs, are combined and the company begins to use the system. Step 7 is completed during systems implementation and conversion. 70-358

28 Step 8 Use and modify the system.
Factors that require existing programs to be revised, referred to as program maintenance, include requests for new or revised reports; changes in input, file content, or values such as tax rates; error detection; and conversion to new hardware. Step 8 is part of the operation and maintenance phase. 70-358

29 Procedures and Controls Design
Everyone who interacts with a newly designed AIS needs procedures that answer who, what, when, where, why and how questions related to all AIS activities. 70-358

30 70-358

31 Procedures may take the form of:
System manuals User instruction classes Training materials Online help screens 70-358

32 The procedures may be written by:
Development teams; Users; or Teams representing both groups. 70-358

33 The often-heard computer adage “garbage in, garbage out” emphasizes that improperly controlled input, processing, and database functions produce information of little value. Controls must be built into an AIS to ensure its effectiveness, efficiency and accuracy. 70-358

34 Some of the more important control concerns that must be addressed are summarized in Table 22-6 on page 690. 70-358

35 70-358

36 70-358

37 Are all interactions valid? 2. Authorization
1. Validity Are all interactions valid? 2. Authorization Are input, processing, storage, and output activities authorized by the appropriate managers? 3. Accuracy Is input verified to ensure accuracy? What controls ensure that data is not lost when passing between processing activities? 70-358

38 Is the system protected against:
4. Security Is the system protected against: - Unauthorized physical and logical access to prevent improper use, alteration, destruction, or disclosure of information and software? - Theft of system resources?  5. Numerical control Are documents pre-numbered to prevent errors or intentional misuse and to detect when documents are missing or stolen? 70-358

39 6. Availability Is the system available as set forth in agreements? Can users enter, update, and retrieve data during those times? 7. Maintainability Can the system be modified without affecting system availability, security, and integrity? Are only authorized, tested, and documented changes made to the system and data? Are resources available to manage, schedule, document, and communicate changes to management and authorized users? 70-358

40 Can data be traced from source to output and vice versa?
8. Integrity Is processing complete, accurate, timely, and authorized? Is it free from unauthorized or inadvertent manipulations? 9. Audit trail Can data be traced from source to output and vice versa? 70-358

41 Physical Systems Design Report
At the end of this phase, the team prepares a physical systems design report that summarizes what was accomplished and serves as the basis for management’s decision whether or not to proceed to the implementation phase. Example of what included in the table on page 695. 70-358

42 70-358

43 70-358


Download ppt "70-358 Chapter 22, Part 2 70-358."

Similar presentations


Ads by Google