Chapter3-2Chapter 3Documenting AccountingInformation SystemsIntroductionWhy Documentation Is ImportantDocument and Systems FlowchartsProcess Maps and Data Flow diagrams
Chapter3-3Chapter 3Documenting AccountingInformation SystemsOther documentation toolsEnd-user Computing And DocumentationAIS at work—flowcharts help recoverembezzled assetsSummary
Chapter3-4Documentation of SystemsDocumentation is a vital part of any AIS.Accountants use many different types ofdiagrams to trace the flow of accountingdata through an AIS.A wide variety of software isavailable for documenting AISs.
Chapter3-5Why Documentation IsImportantDepicting how the system worksTraining usersDesigning new systemsControlling system developmentand maintenance costsStandardizing communicationswith others
Chapter3-6Auditing AISsDocumenting business processesComplying with the SarbanesOxley Act of 2002Establishing accountabilityWhy Documentation IsImportant
Chapter3-7Types of FlowchartsDocument FlowchartsDocument flowchart traces the physicalflow of documents through an organization.Systems FlowchartsSystem flowcharts depict the electronic flowof data and processing steps in an AIS.
Chapter3-8Document FlowchartsConstructing a document flowchart beginsby identifying the different departments orgroups that handle the documents of aparticular system.Auditors and accountants may usedocument flowcharts whenanalyzing a current system forweaknesses in controls and reports.
Chapter3-9Keying operationDocumentMultiple copies ofa specific documentManual OperationConnector betweentwo points on aflowchartJournal or ledgerCommon DocumentFlowcharting Symbols
Chapter3-10Permanent file ofmanual documentsInformation flowDocument flowAnnotation foradditionalexplanationEnvelopefor mailingor distributingbills or checks,etc.Adding machinetape used forbatch controlCommon DocumentFlowcharting Symbols
Chapter3-11A Sample Document FlowchartRequesting Department Central Supplies DepartmentPRFAAPRF1 2File1
Chapter3-12Document FlowchartingGuidelinesIdentify all departments involvedClassify activities department-wise.Identify documents by numbers orcolor-coding.Account for the distribution of everycopy of a document.
Chapter3-13Use on-page and off-page connectorsand connect by using same letter ornumber.Annotate document for clarity.Consider sequencing whenever important.Avoid acronyms to avoid confusion.Consider using automated flowchart tools.Document FlowchartingGuidelines
Chapter3-14System FlowchartsThey use symbols that are industry conventionsstandardized by the National Bureau ofStandards.Each processing phase of a system flowchartusually involves preparing one or more controlreports.These flowcharts depict an electronic job streamof data through processing phases of an AIS, andtherefore illustrate audit trails.
Chapter3-15Common System FlowchartSymbolsOn-line keyingScreen DisplayInput/OutputDocumentComputer ProcessingOn-line StorageCommunicationLinkMagneticDisk
Chapter3-17Systems FlowchartingGuidelinesArrange to read from top to bottom andleft to right.Use appropriate, standard symbols.Always use a process symbol between aninput and an output symbol. This is calledthe sandwich rule.Use connectors to avoid crossedlines and cluttered flowcharts.
Chapter3-18Sketch a flowchart before designing the finaldraft.Use annotated descriptions and comments inflowcharts for clarification.Systems FlowchartingGuidelines
Chapter3-19The sandwich rule states that:a. You should only create logic diagrams that havesome ‘‘meat’’ in themb. Every diagram should have a cover page and asummary pagec. A processing symbol should be between an input andan output symbold. In DFDs, there should always be data flow linesleading to and from filesQuestionSystems FlowchartingGuidelines
Chapter3-20Process Maps and DataFlow DiagramsProcess maps document business processes ineasy-to-follow diagrams.Data flow diagrams (DFDs) are primarily usedin the systems development process as a tool foranalyzing an existing system.
Chapter3-21Process Map for the OrderFulfillment process
Chapter3-23Guidelines for DrawingProcess MapsIdentify and define the process of interest tostay focused.Understand the purpose for the process map.Meet with employees to get their ideas,suggestions, and comments.Remember that processes have inputs, outputs,and enablers.
Chapter3-24Show key decision points.Pay attention to the level of detail you capture.Avoid mapping the “should-be” or “could-be”.Map what is.Practice, practice, practice.Guidelines for DrawingProcess Maps
Chapter3-25Data Flow DiagramsSymbols usedA square represents an external datasource or data destination.A circle indicates a internal entity thatchanges or transforms data.Two horizontal lines represent the storageof data. This is usually a file.A line with an arrow indicates thedirection of the flow ofdata.
Chapter3-26Parts of the DFDContext diagram an overview of the systemPhysical Data Flow Diagrams – first level ofdetailLogical Data Flow Diagrams –idea of whatparticipants do
Chapter3-28Context DiagramsData flow diagrams are usually drawn inlevels that include increasing amounts of detail.A top level (or high-level) DFD that providesan overall picture of an application or system iscalled a context diagram.A context diagram is then decomposed,or exploded, into successively lowerlevels of detail.
Chapter3-29Physical Data FlowDiagramsResemble the document flowchartsFocus on physical entities as well as thetangible documents, reports, and similar hard-copy inputs and outputs that flow through thesystemList the job title of one typical employeeAre simple, more readable, and thereforemore easily understood
Chapter3-31Logical Data Flow DiagramsDecompose DFDs into successive levelsAddress what participants do.Consist of bubbles – each bubble contains a verb thatindicates a task the system performs.Help designers decide what system resources to acquire, what activities employees must perform to run thesesystems, and how to protect and control these systems after installation.
Chapter3-33DecompositionIs the act of exploding data flow diagrams tocreate more detail.Level 0 data flow diagrams may be exploded intosuccessive levels of detail. The next level of detailwould be a level 1 data flow diagram.The DFDs become linked together ina hierarchy, which would fullydocument the system.
Chapter3-35Guidelines for DrawingDFDsAvoid detail in high level DFDs.Ensure that between five and sevenprocesses are in each DFDGive different data flows different names.Ensure all data stores have data flows both intothem and out of them.Include even temporary files in a DFD.
Chapter3-36Classify most of the final recipients of systeminformation as external entities.Classify personnel and departments that processthe data of the current system as internal entities.Display only normal processing routines inhigh-level DFDs.Use only one entity to represent severalsystem entities that perform the sametask,Guidelines for DrawingDFDs
Chapter3-37Which of these is not a good guideline to follow when creatingDFDs?a. Avoid detail in high-level DFDsb. Avoid drawing temporary files in DFDsc. Classify most of the final recipients of system outputsas external entitiesd. Avoid showing error routines or similar exceptiontasksQuestionGuidelines for DrawingDFDs
Chapter3-38Other Documentation ToolsProgram flowchartsOrganizations use structured programming techniques tocreate large computer programs in a hierarchical fashionDecision tablesOrganizations use a table of conditions and processingtasks that indicates what action to take for each possibility.Software Tools for Graphicaldocumentation and SOX complianceMicrosoft Word, Excel, and PowerPointCASE ToolsSOX Compliance
Chapter3-39Program flowchartsoutline the processing logicindicate the order of processing stepspresent the steps in a structuredwalk-through which helps the reviewers assess the soundness of the logic, detect and correct design flaws, and make improvementsmacro program flowcharts serve as an overview ofthe data processing logic
Chapter3-41QuestionThe diagram here is most likely a:a. document flowchartb. system flowchartc. data flow diagramd. program flowchartFlowcharts
Chapter3-42Decision TablesA decision tableis a matrix of conditions and processing tasks thatindicate what action to take for each possibility,is used when the computer program involves manyconditions and subsequent courses of action,is used as an alternative to program flowcharts or inaddition to the flowcharts.
Chapter3-43The drawbacks of a decision table arethey do not show the order in which a programtests data conditions or takes processing actionsrequire an understanding of documentationtechniques beyond flowchartingrequire extra work to prepare, which may notbe cost effectiveDecision Tables
Chapter3-45Software Tools for Graphicaldocumentation and SOX complianceMicrosoft Word, Excel, and PowerPointAll the programs have the “AutoShapes” option for the graphicsymbols and logic diagramsExcel can create large drawings and has the option to embedcomputed values in flowcharting symbols.CASE ToolsHas capabilities of graphical documentation software that exceedthose of word-processing or spreadsheet packages.SOX Compliance SoftwareEnable businesses to reduce the time and costs required to satisfySarbanes Oxley Act of 2002 requirements.
Chapter3-46CASE ToolsCASE is an acronym forcomputer-assisted software engineering.CASE tools automate costly, inefficient, slowdocumentation tasks.CASE tools can reduce the time and cost toproduce high-quality documentation fornew systems, thus supporting rapidapplication development (RAD).
Chapter3-48End-User ComputingEnd-user computingrefers to the ability of non-IT employeesto create their own computer applications,is important for end-users to documentapplications they develop.
Chapter3-49Importance of End-UserDocumentationEnd users require complete, easy-to-followtraining manuals, tutorials, and referenceguides.Documentation is important for learning howto accomplish things or undo mistakes.Documentation is also important for endusers as time is wasted when other employeesneed to alter a system but lack the basicdocumentation to accomplish this task.
Chapter3-50Policies for End-UserComputing and Documentation1. Formally evaluate large projects.2. Adopt formal end-user development policies.3. Formalize documentation standards.4. Limit the number of employees authorizedto create end-user applications.5. Audit new and existing systems.
Chapter3-51QuestionA meeting in which computer programmers outline theirlogic to others is called a:a. Decision meetingb. RAD meetingc. mythical eventd. structured walkthroughComputing
Chapter3-52CopyrightCopyright 2008 John Wiley & Sons, Inc. All rights reserved.Reproduction or translation of this work beyond that permitted inSection 117 of the 1976 United States Copyright Act without theexpress written permission of the copyright owner is unlawful.Request for further information should be addressed to thePermissions Department, John Wiley & Sons, Inc. The purchasermay make backup copies for his/her own use only and not fordistribution or resale. The Publisher assumes no responsibility for errors,omissions, or damages, caused by the use of these programs or from theuse of the information contained herein.