Systems Development and Program Change Activities [EARNING OBJECTIVES LEARNING OBJECTIVI Alter studying this chapter, you should: ‘+ Be able to identify the stages in the systems development life cycle (SDLC). * Understand the importance of strategic system planning. * Be able to identify the basic features of both the structured and objectoriented approaches to systems design. Be able fo identify and discuss the major steps involved in a cost-benefit analysis of proposed information systems Understand the advantages ond disadvantages of the commercial software option, and be able to discuss the decisionmaking process used to select commercial software. Be familiar with different types of system documentation and the, purposes they serve. Understand the risks, controls, and audit issues related to systems development and maintenance procedures. his chapter concludes our treatment cof general control issues as they relate to "Tecan ‘and auditor responsibilities under SOX Section 404. It begins by describing the roles of the participants involved in developing an organization's information system, including systems professionals, users, and stakeholders. Then it outlines the key activities that constitute the SDLC. These include systems planning, systems analysis, conceptual design, system selection, detailed design,'system imple- mentation, and program change procedures (maintenance). This multistage proce- dure is used to guide systems development in many organizations. Finally, the chapter discusses the risks, controls, and audit issues related to systems development snd program change procedures.174 Chapter 5: Systems Development and Program Change Activities THE SYSTEMS DEVELOPMENT PROCESS The systems development process constitutes a set of activities by which organizati, obtain IT-based information systems. These activities are of interest to auditors in the, conduct of a financial statement audit for two reasons. First, the creation of an enti, wide information system involves significant financial transactions. Conceptually, 5, tems development is not unlike like any manufacturing process that produces a comple, product through a series of stages. Such transactions must be planned, authorized, scheg, uled, accounted for, and controlled. Auditors are as concerned about the integrity of yi, process as they are with any manufacturing process that has financial resourc, implications, The second and often the more pressing concern for auditors has to do with the actual products that emerge from the systems development process. The quality of accounting information presented in an organization’s financial statements is dis related to the quality of the accounting information systems that process and report j, A materially flawed financial application can corrupt financial data, which may then be incorrectly reported in the financial statements. Systems development processes that are formal and well controlled are more likely to produce AIS applications that are free from internal control weaknesses than those that are informal and poorly controlled. Stronger application controls translates into lower control risk, which results in less substantive testing that auditors need to perform to achieve their audit objectives. In this first major section of the chapter we examine the key activities that constitute a formal systems development process. The discussion will include both new develop. ment and program change (maintenance) activities. The second major section examines the control and audit issues related to systems development. eS PARTICIPANTS IN SYSTEMS DEVELOPMENT ‘The patticipants in systems development can be classified into three broad groups: ss- tems professionals, end users, and stakeholders. 1. Systems professionals are systems analysts, systems engineers, database designers, and programmers. These individuals actually build the system. They gather facts about problems with the current system, analyze these facts, and'formulate a solu- tion to solve the problems. The product of their efforts is a new information system. 2. End users are those for whom the system is built. There are many users at all levels in an organization. These include managers, operations personnel from various functional areas including accountants. During systems development, systems pro- fessionals work with the primary users to obtain an understanding of the users’ problems and a clear statement of their needs. For example, accountants must specify accounting techniques to be used for certain transactions, internal control requirements (such audit trails), and special algorithms (such as depreciation models). 3. Stakeholders are individuals who have an interest in the system, but are not form! end users, These include the internal steering committee that oversees systems development, internal auditors including IT auditors, and external auditors acting as consultants or serving in the role of internal auditor. ? Stakeholders work with 1 The relationship between tests of controls and substantive tests is discussed in Chapter 1. 2 As discussed in Chapter 1, SOX legislation prohibits external auditors from direct involvement it # audit client's systems development activities.xoation Srstems Acqulstion “ 175 the dey, lo Controls go-M°* team to ens the ture that user’s needs are met, that adequate internal re desi, Systems ‘Ned into S development Priorat systems under construction, and that elf is properly implemented and controlle FORMATION SYSTEMS ac One ofthe y ‘QUISITION user 1st valu Ue oented informatie’ “815 of the modern business organization is responsive, iaipe inventories, elimi System. A well-designed system can increase productivity, Prove management decing nonsvalue added activities, enhance customer service, Organizations a and coordinate activities throughout the organization. tneheeeauite information systems in two ways: (1) they develop Se Commercial grouse ough formal sytems development activites and (2) they ese tWo alternatives,» ® {0m Software vendors. This section of the chapter discusses In-House Development Many organizat, ganiza Such firms fe systems that are highly tuned to their unique operations. development sun’, {88 their own information systems through in-house systems staf of analysts house development requires maintaining a fulltime systems tom systeme at Programmers who identify usr information needs and crate, cus- Commercial Systems A popular option is to purchase commercial systems from software vendors. Manage- ments are thus confronted with many competing packages, some with features in com- mon and others with unique features and attributes that they must choose between. Making the right choice requires an informed decision as to the system and the vendor that will best serve the needs of the organization. Trends in Commercial Software Four factors have contributed to the growth of the commercial software market: (1) the relatively low cost of general commercial software as compared to customized software; (2) the emergence of industry specific vendors who target their software to the needs of articular types of businesses; (3) a growing demand from businesses that are too small to afford in-house systems’ development staff; and (4) the trend toward downsizing orga- nizational units and the move toward distributed data processing has made the commer- Gal. software option appealing to larger organizations, Indeed, organizations that vnaintain an in-house systems development staf will often purchase commercial software when the need permits. For our purposes ‘commercial software packages are divided into three basic groups: turnkey systems, backbone systems and vendor-supported systems. systems are completely finished and tested systems that Tursey Stent Tony a as are ready for implement Tumkey systems are usally sold only as compiled pro- tomized to a specie i jmited ably to customize them to tel speci neds gram modules, and uses Tara options that allow te user to customize input, ou Some turnkey systems Ravt Os menu choices. Other turnkey system vendors will ell put, and some P! wurce code if program changes are desired. For a fee, the user or the their customers the S176 Chapter 5: Systems Development and Program Change Activities vendor can then customize the system by reprogramming the original source code. Some examples of turnkey systems are described next. General accounting systems are designed t0 Serve g wide variety of user needs. By mass-producing a standard system, the vendor is able to reduce the unit cost of these systems to a fraction of in-house development costs. To provide flexibility, general accounting systems are designed in modules. This alloy, eed, Typical modules include users to purchase the modules that meet their specific n accounts payable, accounts receivable, payroll processing» inventory control, general led. ger, financial reporting, and fixed asset General Accounting Systems. Special-Purpose Systems. Some software vendors create special-purpose systems that target selected segments of the economy. For ‘example, the medical field, the banking industry, and government agencies have unique accounting procedures, ae. and con. mmodate. ventions that general-purpose accounting systems do not always 2°90 sation systems are computer systems that Office Automation Systems. Office autor 7 improve the productivity of office workers. Examples of office automation systems include word processing packages, database management systems: spreadsheet programs, and desktop publishing systems. Backbone Systems. Backbone systems provide a basic system structure on which to build, Backbone systems come with all the primary processing modules programmed. ‘The vendor designs and programs the user interface to sult the lient’s needs. Some sys- tems such as enterprise resource planning (ERP) offer a vast array of modules for dealing terfaced seamlessly into a with alimost every conceivable business process, and all are in te modules, the customer can create a highly single system. By selecting the appropria! Customized system. Customizing a commercial system, however: 0 be expensive and time consuming. A fally functional ERP system may take 18,t0 24 months to install and costs anywhere from $10 million to $100 million. M Vendor-Supported Systems. Vendor-supported systems are custom systems that the vendor develops and maintains for the client organization. A number of different support levels are possible under this model including: «Application installation, ‘system configuration, data conversion, personnel training, and trouble shooting and maintenance. Database support involves developing and maintaining the database tables for the application. © Configuring the server and Interfacing the vendor suppor where data sharing between systems is necessary. «Back up and recovery of programs and data as part of an organization's disaster recovery plan. operating system to host the application and database. ted application to other in-house supported systems Advantages of Commercial Software ; 1m systems often take a long time to develop. Months re a custom system can be developed through in- ion successfully anticipates future informa tion needs and schedules application development accordingly, it may experience Tong periods of unsatisfied need. However, commercial software can be imple- mented almost immediately once a need is recognized. The user does not have © Implementation Time. Custo: or even years may pass befor house procedures. Unless the organizati to wait.wet Development Life Cycle W7 + Cost. A 5; Of comp nBle user | commer ag way ur howe development cs Sine th cost j TREE to action og et Actos! many ses, Hower the unit cost is ably ton cepa oo am hose ‘developed system. ing reat felease to Wiable commercial software packages are thoroughly tested 308 testing are ely oem math Any system errors not discovered dur- SBREsted Although be uncovered by user organizations shortly after release and ate is less likely no p2teM™ Is certified as being free from errors, commercial 'y to have errors than an equivalent in-house system. Disadvantages of * Independence Commercial Software le ve * Pu endor for mages a vendor-supported system makes the firm dependent on fenance. The user runs the risk that the vendor will cease to Support the st tage of vendor-epeare {g0 out of business, This is perhaps the greatest disadvan- 1¢ need for ted systems, the ability ee systems. The prime advantage of in-house development is describes a ee f luce applications to exact specifications. This advantage also unique and nant of commercial softvare, Sometimes, the user's needs are 100 nent MPs and commercially available software is either too general or Maintena : needs change Business information systems undergo frequent changes. If the user’s Inhouse ee widens be tial or even impossible to modify commercial software. iment, ho 4 si : ; can be economically ae provides users with proprietary applications that Both the i a See devepment and the commercial pickageoptos have advantages aay eee ages. They ae nt however, mutually exclusive propositions. A company Ina say sete of i infomation nes by puchaig commercial software and develop other systems invhouse. Both apraches are enbaned by formal procedures _ that lend structure to the decision-making process. The SDLC described next is generally associated with in-house development, but many of its phases, particularly those involy- ing needs analysis and system specification, are employed even when the final system is purchased from an outside vendor. THE SYSTEMS DEVELOPMENT LIFE CYCLE * Information systems have a life cycle that begins with the recognition of an informa- tion problem. This initiates, the systems development process, which results in the Tementation of a new information system. Over time, because of ‘ds and technology innovations, the information system will undergo modifications to keep it current. This so called “maintenance” phase in the life cycle may last many years. At some point however, the system reaches the end of its life cycle when it becqmes impractical to keep patching it. This recognition of seed for a new system triggers the systems development process and the life cycle creation and imp! changes in business nee begins again. . . : “The length of the systems development life cycle will vary among business organi- ions depending on their industry, competition pressure, the degree to which techno- zations ve ravation impacts the companys and the scale of the project. Some companies logical inno legacy systems originally designed in the 1980's while 7 ing elements 0! are stil operat erience life cytes of only five to ten yeas,178 pate Chapter 5: Systems Development and Progr Chane Systems Development Life Cycle New Systems Development Fonda (Programming, ation /4 Te fepsoms lmfowanes Leh oe nsoraiatn HOP Marry ‘Selection ‘Design Testy Fe] [ee Mutiole tom Detailed rome | [Seu] [eee] [gem | [See ee | [tse] jeeeel | set | cos System Documentation ‘The SDLC activities described in this section are generally accepted in the systens community as “best practices,” The number of phases and the labels attached to them wi, however, differ among. organizations. Different authorities have proposed SDLC modds with as few as 4 and as many as 14 specific activities. From an auditing perspective, wear concerned about the substance of the process and its consistent application, regardless of how it is defined. The SDLC in Figure 5.1 is an eight-phase process consisting of two major stages: new systems development and program change procedures (maintenance). The first seven phases of the SDLC describe the activities that all new systens should undergo. New systems development involves conceptual steps that can apply to any problem-solving process: identify the problem, understand what needs to be done, consider alternative solutions, select the best solution, and, finally, implement the sol-. tion. Each phase in the SDLC produces a set of required documentation that together constitutes a body of audit evidence about the overall quality the SDLC. An eighth step, systems maintenance, constitutes the organization’s’ program change. procedures It begins once the seven phases are complete and the system is fully implemented. Eat of the SDLC phases is briefly outlined next. Systems Plan Phase I ‘The objective of systems planning is to link individual system projects or applications tothe strategic objectives ofthe firm, Infact, the bass for the systems plan is the organization's but ness plans which specifies where the firm plans to go and how it will get there. In parti systems projects are analyzed against IT strategic plan, which is developed from and congrue* with the organization's business plan. Figure 5.2 presents the relationship between these pl" and the strategic objectives ofthe firm. There must be congruence between the individ! projects and the business plan, or the firm may fail to meet its objectives. Who Should Do Systems Planning? Most firms that take systems planning seriously establish a systems steering commit to provide guidance and review the status of system projects. The composition ©nome Business Plan Strategj , YC Objectives of the Firm "Life Cycle. 179 Relation Betwee, '? Systems Plans and Organizational Objectives systems Plan [<= Projets steering commi 8 committee may include the CEO, the CFO, the CIO, senior management from user areas, the i ¢ inal patties pe luna auditor, and senior management from computer services. Exter- cal Tesponsib ‘lit 25 management consultants may also supplement the committee. Typi- ities for a steering committee include the following: Resolving conflicts that arise from new systems Reviewing projects and assigning priorities Budgeting funds for systems development Reviewing the status of individual projects under development Determining at various checkpoints throughout the SDLC whether to continue with the project or terminate it Systems planning occurs at two levels: strategic systems planning and project planning. Strategic Systems Planning Strategic systems planning involves the allocation of systems resources at the macro level. It usually deals with a time frame of three to five years. This process is similar to budgeting resources for other strategic activities, such as product development, plant expansions, market research, and manufacturing technology. Technically, strategic systems planning is not part of the SDLC because the SDLC pertains to specific applications, The strategic systems plan is concerned with the allocation of systems resources such as employees (the number of systems profes- sionals to be hired), hardware (the number of workstations, servers, and mainframes to be purchased), software (the funds to be allocated to new systems projects and for systems maintenance), and telecommunications (the funds allocated to networking and EDI). Why Pe erform Strategic Systems Planning? Information systems planning is . uncertainty. Who can look five years into the future and accu- characterize nA aiete of systems technology? Because of this long-term plans are ate Fs ae How, therefore, can a firm do strategic systems planning? Why likely to % should it?180 rogram change Acti? ter 5: Systems Development and P ing: 11, Strategic plannin 8 chan tems goal. Even if it my ior to simply Wandering & ni astfiations for strategic S775 plant ser than no plan at h its information sys planning is super ‘There are four j A plan that changes the path the firm wil making many midcourse the wilderness. © Strategic planning plan is a model for identifying and P future needs, recogniz : 1 are eds before the sympvoms of under TA ‘peony ata rig that ti ee recive ers f ,blem, Often, problems reach a crisis le ; in whlch edversly ree the quality of the solution. Stave nnn = Nuctured means of separating legitimate needs from desires, a problems. © Strategic systems plannit systems plan lays out au systems are congruent wit tems can be just as damaging juipment. «Cast management, Historically, systems planning has proven to be a cost-effectng smeane of managing systems projects and application development. , constantly is be II follow to read adjustments, i development. & §, wonent in systems ‘ ean ng user needs. It allows manager reduces the crisis sn their early stages, and g i eq ng provides authorization contr for the SDLC. The stra, ig Provtion rues to ensure that decisions to develop spe, irm. Investing in the wrong s, ith the objectives of the firm. Inv toca firm as investing in the wrong plant ang Project Planning : The purpose of project planning is to allocate resources to individual applications within the framework of the strategic plan. This involves identifying areas of user needs, prepa ing proposals, evaluating each proposal’s feasibility and contribution to the busines: plan, prioritizing individual projects, and scheduling the work to be done. The basic pu- pose of project planning is to allocate scarce resources to specific projects. The produt of this phase consists of two formal documents: the project proposal and the projet schedule. The project proposal provides management with a basis for deciding whether to proceed with the project. The formal proposal serves two purposes. First, it summaris the findings of the study conducted to this point into a general recommendation fora new or modified system. This enables management to evaluate the perceived problem along with the proposed system as a feasible solution. Second, the proposal outlines linkage between the objectives of the proposed system and the business objectives of tt firm, especially those outlined in the IT strategic plan. It shows that the proposed ne system complements the strategic direction of the firm. _The project schedule represents management's commitment to the project The project schedule is a budget of the time and costs for all the phases of the SDLC. Ap ect team selected from systems professionals, end users, and other specialists such * emma) and internal auditors will complete these phases, The composition of aoe pis cumptence and dedication of its members are critical to the success Systems Analysis—Phase Il We ; I pe s ae a ie a second phase in the SDLC, Systems analysis is actually @ to" Se aE ne first a survey of the current system and then an analysis o : » A business problem must be fully understood by the systems até!pe ptems Development Life Cycle 181 before he * he or she 10.an incomplete an vormulate a solution. An incomplete or defective analysis will lead plete : the rest of the spice sctve solution. Therefore, systems analysis i the foundation for Feport, which presents The deliverable from this phase is a formal systems analysis system, ‘ls the findings of the analysis and recommendations for the new The Survey Step Most system “ and related mihi developed from scratch. Usually, some form of information system determining what ns are currently in place. The analyst often begins the analysis by the new system, Tyee Hf any, ofthe current system should be preserved as part of liminary questions ween eS & father detailed system survey. Facts pertaining to pre- eater depth of tout the system are gathered and analyzed As the analyst obtains 2 tions for which etstanding ofthe problem, he or she develops more specifi ques, iterations, ‘When ail facts must be gathered. This process may go on through several 'en all the relevant facts have been gathered and ‘analyzed, the analyst arrives at an assess : dlandvantages ee i ‘current system. Surveying the current system has both Disadi i pa vantages of Surveying the Current System 2 hen Physical tar pit. This term is used to describe the tendency on the part of ¢ analyst to be “sucked in” and then “bogged down” by the task of surveying the current dinosaur system. ? Thinking inside the box. Some argue that current system surveys stifle new ideas. By studying and modeling the old system, the-analyst may develop a constrained notion about how the new system should function. The resilt is an improved old system rather than.a radically new approach. Advantages of Surveying the Current System «© Identifying what aspects of the old system should be kept. Some elements of the sys- tem may be functionally sound and can, provide the foundation for the new system. By fully understanding the current system, the analyst can identify those aspects worth preserving or modifying for use in the new system. «Forcing systems analysts to fully understand the system. When the new system is implemented, the users must go through a conversion process whereby they for- mally break away from the old system and move to the new one. The analyst must determine what tasks, procedures, and data will be phased out with the old m and which will continue. To specify these conversion procedures, the ana not only what is to be done by the new system but also what was Id one. This requires a thorough understanding of the curfent syste lyst must know: done by the 0 system. + Tolating the root of problem symptoms. By surveying the current system, the analyst may determine conclusively the cause of the reported problem symp- toms. Perhaps the root problem is not the information system at all; it may be a management or employee problem that can be resolved without redesigning information system. We may not be able to identify the root cause of the rreblem if we discard the existing system without any investigation into ‘the symptoms. li nt against surveying the current system, i re most compelling argument against surveying mine 3, This is perhaps182 ies change Acti and Progra” es Development 3 Chapter 5: Sy ; gathering, activity. The fact, Gathering Facts jg essentially a fact-Bal jtuations, and rei,6% ant system. is €55 ae key features, situal Tel The survey ofthe current rat ata that describe Ke Farad classes ty cred by the analyst are pis ha oe ol ships of the system. System facts fall int the @ Data sources. These include external enti 3 internal sources from other departs ete Users. These include both managers at ore cou a0 od ssukee doom, fate stores, Data stores are the files, cat20as™ i . tions that decision or an action triggered by inforrne movement Sr aacumpente ed «Data flows, Data flows are represented by the OVEN. Data flows cana between data sources, data stores, processing 5 «an aos represented in Unifed Modeling Langage aoe ontrls and maybe * Controls. These include both secountng and opt a, 1 procedures or computer controls. : *, Transaction volumes. The analyst must obtain @ measure os te tran volumes for a specified period of time. Many systems ae 5S te * have reached their capacity. Understanding the characteristics © systems tras tion volume and its rate of growth are important elements in ASSESSing capacy requirements for the new system. i © Error rates. Transaction errors are closely related to transaction volume. AS a sy, tem reaches capacity, error rates increase to an intolerable level. Although no systex, is perfect, the analyst must determine the acceptable error tolerances for the ney system. : 's Resource costs. The resources used by the current system include the costs of ibe, computer time, materials (such as invoices), and direct overhead. Any resource css that disappear when the current system is eliminated are called escapable cost Later, when we perform a cost-benefit analysis, escapable costs will be treated s benefits of the.new system. Bottlenecks and redundant operations. The analyst should note points where dau flows come together to form a bottleneck, At peak-load periods, these can result it delays and promote processing errors. Likewise, delays may be caused by redundt operations, such as unnecessary approvals or sign-ofls. By identifying these probes areas during the survey phase, the analyst can avoid making the same mistakes i the design of the new system. ties, such as customers OF vendors, By Fact-Gathering Techniques Systems analysts employ several techniques to gather the previously cited facts. Cot monly used techniques include observation, task participation, personal interview reviewing key documents, Observation. Observation involves passively watching the physical procedures of system. This allows the analyst to determine what gets done, who performs the ' when they do them, how they do them, why they do them, and how long they take: Task Participation. Participation is an extension of observation, whereby the at" takes an active role in performing the user’s work. This allows the analyst to expet firsthand the problems involved in the operation of the current system, For ext®#™ the analyst may work on the sales desk taking orders from customers and prep! sales orders. The analyst can determine that documents are improperly designe ™pester Development Life Cycle is insufficient time Sause bottlenecks envision better STIs to perform the required procedures, or that peakcload problems an Processing errors. With hands-on experience, the analyst can often ‘WAYS to perform the task, Personal ‘ system ang terion, Interviewing ts a method of extracting fats about the current Used to gather her ePtions about the requirements for the new system. The instrument hese facts may be openvended questions or formal questionnaires. on! Questions allow users to elaborate on the problem as they see it and lit analyze, bay nn’ "commendations. Answers to these questions tend to be dies © this type i they give the analyst a feel for the scope of the problem. The anal rae Examples of eV" must be a good listener and able to focus on the important fas our sales ogcPet-ended questions ae: “What do you think isthe main problem © Question rit system?” and “How could the system be improved?” ; ser sraies are used to ask more specific, detalled questions and to restrict the nataee SPOUSES. This is a good technique for gathering objective facts about the nen, of SPeific procedure, volumes of transactions processed, sources of data 'sers of reports, and control issues, Reviewing — ion’ ts are another source of facts abon’ Xf Documents. The organization's documen tthe system being surveyed. Examples of these include the following: Organizational charts Job descriptions Accounting records Charts of accounts Policy statements Descriptions of procedures Financial statements Performance reports System flowcharts Source documents ‘Transaction listings Budgets Forecasts ‘Mission statements Ce wee ccc wc ee oe. + Following the fact-gathering phase, the analyst formally documents his or her impressions and understanding of the system. This will take the form of notes, system flowcharts, and data flow diagrams. These documentation techniques are discussed in more detail in Chapter 6. nalysis Ste, ’ peta analyse ise intel process that is commingled with fact gathering. The is si ly analyzing as he or she gathers facts. The mere recognition of aaa cos pesumer sme understanding of he nom or dese sate Is herfore df felt to identify where the survey ends and the analysis begins. alysis Report Me ree rvarks the concusion of the systems analysis phase is the pieparation of a The er analysis report. This report presents to management or the steering committee formal syste gs the problems identied with the curent syste, the users needs, and the survey oe the new system. Figure 5.3 contains a possible format for this report. the requirem184 systems Analysis Report Outline of Main Topics ina Systems Analysis Report Chapter 5: Systems Development and Program change Activites ns for System Analysis, vt “nemo es i esa ene ear . Additional reasons bes oem cited by the projet proposal B. Changes in scope stem Iu, Problems Identified with Current SY shering facts A Tecmues set ne aan roses . Analysis of facts /. Statement of User Requirements : I, Salome godin oy aoe, Sh 2 1” Output requirements 2. Transaction volumes: 3. Response time B. Nontechnical terms for a broad-based aud! 1. End users 2, User management 3, Systems management 4 Steering commition jence, including: VV. Resource Implications }. Preliminary assessment of economic effect feo B: Is economic feasibilty as stated in proposal reason: VI. Recommendations ‘A. Continue or drop the project y” B. Any changes to feasbliy, strategic impact, or priority of the project as a result of analysis, ‘The primary purpose for conducting a ystems analysis is to identify user needs and spe ‘The report should set out in detail what the system mut requiresnents for the new system. do rather than how to do it. The requirements statement within the report establishes at nderstanding between systems professionals, management, users, and other stakeholies ‘This document constitutes a formal contract that specifies the objectives and goals of thesy* tem, The systems analysis report should establish in clear terms the data sources, users di files, general processes, ata flows, controls, and transaction volume capacity. “The systems analysis report does not specify the detailed design of the proposed tem. For example, it does not specify processing methods, storage media, record str tures, and other details needed to design the physical system, Rather, the repot remains at the objectives level to avoid placing artificial constraints on the concept design phase. Several possible designs may serve the user's needs, and the developmes" process must be free to explore all of these. Conceptual Sytems Design-Phase It ‘The purpose of the conceptual design phase is to ive conceptual ° Cs Produce several alternative con se tems that satisfy the system requirements identified during systems analysis. By presen’ Ageste DEMIOPH Lie Ce 185 @ numbe constraints on WE alternatives, the systems profesional avoid imposing Pre: re On the aematives gee *78tem. The use wl evaluate these conceptual models and 1 BO to the systems enn SPPERE Mast plausible and appealing, These alternative designs compared and a1 Iection phase of SDLC, where their respective costs and benefits are By keeping aioe imum design is chosen. minimize the inyeetgn, 88% conceptual throughout these phases of the SDLC, we Tejected, lent of resources in alternative designs that, ultimately, will be The Where itis designe a S78 that emerges proceeds tothe final phases of the SDLC, is scr od etal and implemented. approach and the ees t40 approaches to conceptual systems desig: the structured system from eciith pattie approach. The structured approach develops each new from the bottoms ct {0% the top doven. Object-oriented design (OOD) builds systems system from cick nee assembly of reusable modules rather than create each SDLC where aa OOD is most often associated with the iterative approach to rapidly, with ‘chunks” or modules cycle through all’ of the SDLC phases rather 4 short time frame from beginning to end. ‘Then additional modules are led in Some appropriate fashion until the whole system has been developed. ined way of designing systems from the top ts of starting with the “big picture” of the proposed system that is grad- approach ee sed into more and more detail unti it s fully understood. Under this cerca aie business process under design is usually documented by data flow and liagrams. Figure 5.4 shows the use of data flow diagrams (DFDs) and a structure diagram. to depict the top-down decomposition of a hypothetical business process. down. It consis ually decompo: Wee can see from these diagrams how the systems designer follows a top-down approach. The designer starts with an abstract description of the system and, through successive steps, redefines this view to produce a more detailed description. In our example, Process 2.0 in the context diagram is decomposed into an intermediate level DED. Process 2.3 in the intermediate DED is further decomposed into-an elementary DED. This decomposition could involve several levels to obtain sufficient details. Let's assume that three levels are sufficient in this case. The final step transforms Process 2.3.3 into a structure diagram that defines the program modules that will constitute the process. | ‘The conceptual design phase should highlight the differences between critical features of competing systems rather than their similarities. Therefore, system designs at this point should be general. The designs. should identify all the inputs, outputs, processes, and special features necessary to distinguish one alternative from another. Figure 5.5 presents two alternative conceptual designs for a purchasing system. These designs lack the details needed to implement the system. For instance, they do not include these necessary components: Database record structures Processing details Specific control techniques . Formats for input screens and source documents Output report formats The designs do, however, possess sufficient detail to demonstrate how the two sys- ne ev diffeent in their functions To ustrate, les examine the genera tems al features of each system.Activities ind Program Chae fopment and 186 Devel ign Approach De Top-Down Decomposition of th Structured Context Levol DFO GD aa Ga Itgrestate Level l oF! Process => recess P| Process — Structure Diagram [mr | [none Option A is a traditional batch purchasing system, The initial input for the process 8 the piirchase requisition from inventory control. When inventoriés reach their predete mined reorder points, new inventories are ordered according to their economic order qu" tity, Transmittal of purchase orders to suppliers takes place once a day via the US. mil In contrast, Option B employs EDI technology. The trigger to this system is @ put chase requisition from production planning, The purchases system determines the que tty and the vendor and then transmits the order online via EDI software to the ven187 sot games| ot Lee momen sums 103 | wets 103 [GH BuOvONn sono : apo oneyorr oreuaind meee sonore tz) one mwa 1opuen wayshg 103 ‘a vondO ‘sr000%¢ ~ a ss000td mn << = suseuaina << a 510010 “| onyping re souoieg wayshg yojeg ‘y uoNdO - aeeek = wens ‘fa paionieg taisds Buysoypind b 404 suByseq jonjde2uo eayowioyynd Program change Aetie® Chapter $1 systems Develop tion A is its simplicig ‘A benefit of OP! Ronee Bot Wes have pros and cons. systems F tha joth alternatives have P' tower demand (a ee time of design, ease of implementation, is that ft Option B. On one han a negative aspect of iS ow the firm to reduce OF even carry inventories. On the other hand, Option ‘more expensive and sophisticateg tthe cost of tnd soph tempt to evaluate t mets seo art phase in the SDLC. At this poin, ing plausible system designs. eliminate inventories. This benefit comes a" | system resources. It is premature, at this point of these alternatives. This is done formally in ¥ system designers are concerned only wit information systems from res. The Object-Oriented Approach is to build proach st ee equated tothe proces of The object-oriented design (OOD) ap able standard components ot objects. This approach may 06 CW at from scratch, building an automobile, Car manufacturers do not create each new TNE New models are actually built from standard components that 109 OTC For example, each model of car produced by a particular manu = : _ Some of the car's compo. typeof engine, gearbox, teat, ear ele rio, 294 3 on crres. Such nents will be industry-standard products that are o : things as wheels, tne spark pe and headlights fall into this category Tn Pee be that the only component actualy created from scratch for. 2 ne body. =e “ “The automobile industry operates in ths fashion to stay competitive. By using stan- dard components, car manufacturers minimize production and maintenance costs. At the same time, they can remain responsive to consumer demands for new products and preserve manufacturing flexibility by mixing and matching components according to the ‘customer's specification. The concept of reusability is central to the object-oriented approach to systems be used in other systems with similar design. Once created, standard modules can tems wit needs. Ideally, the organization's systems professionals will create a library (inventory) of modules that can be used by other system designers within the firm. The benefits of this approach include reduced time and cost for development, maintenance, and testing and improved user support and flexibility in the development process. System Evaluation and Selection—Phase IV The next phase in the SDLC is the procedure for selecting the one system from the set of alternative conceptual designs that will go to the detailed design phase. The systems evaluation and selection phase is an optimization process that seeks to identify the best system, This decision represents a critical juncture in the SDLC. At this point, there is a great deal of uncertainty about the system, and a poor decision here can be disastrous, The purpose of a formal evaluation and selection’ procedure is to structure this decision-making process and thereby reduce both uncertainty and the risk of making a poor decision. The evaluation and selection process involves two steps: © Perform a detailed feasibility study ‘* Perform a cost-benefit analysis Perform a Detailed Feasibility Study The following discussion outlines five aspects of project feasibility that need to be con sidered. Each competing project will be assessed in the same manner. By assessing the major constraints on the proposed system, management can evaluate the project's likeli hood for success, before committing large amounts of financial and human resourcesgems DeveFopME Life Cycle 189 The acroy i for techni TELOS pro Te ate economia ean for assessing projet esi, The term stands echnical ry “il, operational, and schedule feasibility. be develgeasibility, min! inder. caning echnical feasibility is concerned with whether the system can Te aD the techno cetnORY oF if new technology is needed. AS 2 general CRPY Therefore, frome, IME marketplace I far ahead of mast fms’ ability to co Gat MOSt firms, the ty viewpoint, technical feasibility is not usually an or. iven that technology i: issue is their desire and ability to apply available technol- is aspect bears hem SY is the physical basis for most of the system's design features, evil Economie Feagi 'Y on the overall feasibility of the competing system. bili . complete the project uy Economic feasibility pertains to the availability of funds to mitment to this project this point, we are concerned with management's financial com- The Level of ayatayac |” View of other competing capital projects under consideration, oad "'e Economic support rectly impacts the operational nature and System design fore oo AE a cost-benefit analysis i ‘used to identify the best Legal Feasibiti tem and the cor ty. Legal feasibility identifies any conflicts between the conceptual sys- mpany's ability to di ei ; we have studic ty to discharge its legal responsibilities. In previous chapters, Danes-Oak a the need to comply with the control requirement laid down in the Sar~ invasion a AC and SAS 103. In addon, many regulations and statutes deal with ra be ce Ptivecy and the confidentiality of stored information. The decision maker ain the proposed system falls inside all legal boundaries. Operational Feasibility. Operational feasibility shows the degree of compatibility yeen the firm’s existing procedures and personnel skills and the operational require- ments of the new system. Implementing the new system may require adopting new pro- cedures and retraining operations personnel. The question that must be answered is, can adequate procedural changes be made, sufficient personnel ‘retrained, and new skills obtained to make the system operationally feasible? Schedule Feasibility. Schedule feasibility relates to the firm's ability to implement the project within an acceptable time. This feasibility factor impacts both the scope of the project and whether it will be developed in-house or purchased from a software vendor. If the project, as conceptually envisioned, cannot be produced internally by the target date, then its design, its acquisition method, or the target date must be changed. Perform a Cost-Benefit Analysis Cost-benefit analysis helps management determine whether (and by how much) the benefits received from a proposed system will outweigh its costs, This technique is frequently used for estimating the expected financal value of business investments. this case, the investment is an information system, and the costs and bene- salt to identify and quantify than those of traditional capital projects. ie werect for this setting, cost-benefit analysis is employed because of its Ae aa the absence of a clearly better alternative. In spite of its limitations, the sin enefit analysis, combined with feasibilty factors, i a useful tool for comparing ing systems designs. competing yer analysis involves thre steps: identify costs, identify benefits, and compare Saal Tenefits, We discuss each of these steps next « However, fits are more diffi ‘ne method of identifying costs is to divide them into two categories: ysts. 7 . Hentify en and rocuting cost, One-time costs include the init investment to ‘one-time190 Chapter 5: Systems Development and Program Change Activites ge ee (EET One-Time and Recurring Costs One-Time Costs Hardware acquisition Site preparation Software acquisition Systems devon Programming and testing Da conversion from od system fonew sys Recurring Costs Hordware maintenance Software maintenance contracts Inguronce ! Supplies EE Ramon et ae en i ing and mainten: deve i pecursing costs include operating a ce ap nd penn pen. ering rm of a ee costs that recur over the life of the systet time and recurring costs. ‘One-time costs include the following: A cost of mainframe, minicomputers Hart jsition. ‘This cost includes the id oe uch as tape drives and disk packs, microcomputers, and peripheral equipment, ‘These cost figures can be obtained from the vendor. aves such frequently overlooked costs as, building conditioning or making structural changes), .equp- Jude the use of heavy equipment), and freight obtained from the vendor and the subcon- Site preparation. This cost i modifications (eg, adding ait tment installation (which may inc Charges. Estimates ofthese costs cam be tractors who do the installation. + Sgmare aqustion. These costs apply to allsoftware purchased forthe proposed stem, inling operating stem software (if not bundled with the hardware), net ste vol sofware, and commercial applications (such as accounting packages). otimates ofthese costs can be obtained from vendors. Stems dev. These cots are those incurred by systems profesionals performing the planing, analysis, and design functions. Technically, such costs incurred up this point are “sunk” and ielevant to the decision, The analyst should estimate onl the costs needed to complete the detailed design. + Programming and testing. Programming costs are based on estimates of the personne! hours required to write new programs and modify existing programs for the proposed spt, System testing cost involve bringing together all the individual program nied a eng an ne sen, THis at bea rigorous exercise if itis to be mean- pees ieee eres ere The caperence ofthe frm inthe aa i the best basi for aoa acto ‘Dela colts Thee contain the tanaer af data rom oe nseg a to another: F ' 1m one storage medium er, For example, the accounting records of a manual verted to magnetic form when the system becomes c system mat Be sent a agfeal tai. The bls for extimany consent ened caker od size of the files to be converted. ig conversion costs is the number andgeet DVR Lie Cyc id 91 ¢ could dete Involve educating users to operate the new system. In-house 2 remote iy. 2h extensive training program provided by an outside orgs ly Obaineg fo through on-thejob training, The cost of formal taining OOM fatigce cost Of a in-house training program includes instruction Meet budgets andi and lost productivity, This cost Is often the fist one cut to ERP implementation =o” action can be fatal to systems development (eg, Hershey's training before “aon disaster was blamed in part on the drastic reduction in employee BEF Of cuting the io ve". * Accountants and auditors should be aware ofthe dan- Reciur 'mportant part of systems development. SUtTing costs in. clude the following: Hardwar ing the ee This cost involves the upgrading of the computer (increas- and periphe md 8 well as preventive maintenance and repairs to the computer with the vendor ¢ luipment. The organization may enter into a maintenance contract obtained from aguante and budget these costs. Estimates for these costs can be Software maintena lors and existing contracts. tems, purchased, These costs include upgrading and debugging operating sy=- contracts with applications, and in-house developed applications. Maintenance Estimates of i Software vendors can be used to specify these costs fairly accurately. insurens Thee maintenance can be derived from historical data. dalisnr sag hs COM covers Such hazards and disasters as fre, hardware file, van- © Supplies These est" Y disgruntled employees. * ‘These costs are incurred through routine consumption of such items as el Magnetic disks, CDs, and general office supplies. ; “ersonnel costs. These are the salaries of individuals who are part of the information system, Some employee costs are direct and easily identifiable, such as the salaries of Operations personnel exclusively employed as part of the system under analysis. Some personnel involvement (such as the database administratot and computer room personnel) is common to many systems. Such personnel costs must be allo- cated on the basis of expected incremental involvement with the system. Identify Benefits, ‘The next step if the cost-benefit analysis is to identify the benefits of the system. These may be both tangible and intangible. Table 5.2 lists several types of tangible benefits. Tangible benefits fall into two categories: those that increase revenue and those that reduce costs. For example, assume a proposed EDI system will allow. the organization to reduce inventories and at the same time improve customer service by reducing stockouts. The reduction of inventories is a cost-reducing benefit. The proposed system will use fewer resources (inventories) than the current system. The value of this benefit is the dollar amount of the carrying costs saved by the annual reduction in inventory. The esti- mated increase in sales due to better customer service is a revenue-increasing benefit. ‘When measuring cost savings, itis important to include only escapable costs in the analysis. Escapable costs are directly related to the system, and they cease to exist when the system ceases to exist. Some costs ‘that appear to be escapable to the user are not truly escapable and, if included, can lead to a flawed analysis. For example, data pro- cessing centers often “charge back” their operating costs to their user constituency through cost allocations. The charge-back rate they use for this includes both fixed Costs (allocated to users) and direct costs created by the activities of individual users, Figure 5.6 illustrates this technique, ru a discus it ERP eystems are discussed in Chapter 11.12 icone 5 6 DP Center Cost Charge-Back to User Areas tivities Chapter 5; PIE: Deveapment and Progam ane CoE Tangible Benefits Increased Revenv' ; Increased soles within exist" Expansion into other markets Cost Reduction Labor reduction Operating cost reduction (0¢h © Reduced inventories Less expensive equipment Reduced equipment maintenance morkels supplies ond overhead) ses to acquire a computer system at the proposal isthe cost sav. ‘Assume the management in User Area B prop’ rent data processing center, and perform its own data processing locally. One benefit ings derived by escaping the charge-back from the cu i f Although the user may see this as a $400,000 anal ‘charge, only the direct cost portion ($50,000 i ecapable bythe organization asa whole. Should the proposal be approved, the remaining $350,000 of the charge-back does not go away ‘The remaining users of the current system must now absorb this cost. Table 5.3 lists some common categories of intangible benefits are often of overriding importance in informal be easily measured and quantified. For example, assut penefits. Although intangible ition system decisions, they cannot me that a proposed point-of-sale Total Charge-Back to User Area B = $400,000 Direct Traceable Costs = $278,000T | ff sn jos Development Life Cycle 193 Intangible Benefits ; Ineteased customer satisfaction j Improved employee satisfaction curren nfrmaton Improved decision making Foster i response fo competior actions ‘Mote aflicent operations le internal and external communications . ‘proved planning : ‘Operational flexibility system for a 5, sales depart, ce transaction from Tent 2° will reduce the average time to process a customer sal ere ibe get Minutes to 3 minutes. The time saved can be quantified and pro- ips benefit in the form of an operating cost saving, An intangible benefit is But what is the nc atsfction; no one likes to stand in long lines to pay for purchases. tomer satisfac eva Of this intangible benefit to the organization? Increased cus~ store—and sao” MAY translate into increased-sales. More customers will buy at the do we quanua ee Miling to pay slightly more to avoid long checkout lines. But how ¢ a tify this translation? Assigning a value is often highly subjective. are) Dench any Professionals draw upon many sources in attempting to quantify intangible ven, and manipulate them into financial terms. Some common techniques include customer (and employee) opinion surveys, statistical analysis, expected value techniques, and simulation models. Though systems professionals may succeed in quantifying some of these intangible benefits, more often they must be content to simply state the benefits as precisely as good judgment permits. Because they defy precise measurement, intangible benefits are sometimes exploited for political reasons. By overstating or understating these benefits, a system may be Pushed forward by its proponents or killed by its opponents. Compare Costs and Benefits. ‘The last step in the cost-benefit analysis is to com- Pare the costs and benefits identified in the first two steps. The two most common meth- ods used for evaluating information systems are net present value and payback. Under the net present value method, the present value of the costs is deducted from the present value of the benefits over the life of the system, Projects with a positive net present value are economically feasible. When comparing competing projects, the ‘optimal choice is the project with the greatest net present value. Table 5.4 illustrates the net present value method by comparing two competing designs. ‘The example is based on the following data: en TS seat) Project completion time 1 year 1 year Expected useul life of system Syears "5 years Onetime costs {thousonds) : $300 $140 Recurring cols (Howson) incred in begining of yoors 1 $45 $55 through 5 rt “Annuol tangible bones (hovsonds) cured in end of yeors 1 $170 $138 through 5 :194 Chapter 5: Systems Development and Program Change Activites ke a, Net Present Value Method of Cost-Benefy, Analysis Beginnin Beginning rd Year End Year End Yoor Year Time _Outflows _Inflows _Outflows Outflows Inflow, ° $3,000,000) 0 (55,000) 138,009 1 (45,000) 170,000 ' A 1us000) 170,000 a (55,000) 135,009 3 {45,000} 170,000 3 135,000) 135.00 4 (45,000) ‘170,000 4 er 5 (45,000) 170,000 ~ 5 Lao ence PV Out $479,672) oe see PV In $628,428 vin $(369,599) He Tae Win $499,089 Interest Rate 8.00% If costs and tangible benefits alone were being considered, then Design A woul selected over Design B. However the value of intangible benefits along with the design feasibility scores, must also be factored into the final analysis. tak “The payback method is a variation of break-even analysis. The break-even point ix reached when total costs equal total benefits. Figure 5,7(A) and 5.7(B) illustrates this approach using the data from the previous example. ‘The total-cost curve consists of the ‘one-time costs plus the present value of the recurring costs over the life ofthe projet. The total benefits curve js the present value of the tangble enefte The intersection ofthese lines represents the number of years into the future when the project breaks even, or pays for itself. The chaded area between the benefit curve and the total cost curve represents the present value of future profits eared by the system. Tn choosing an information system, payback speed is often a decisive factor. With the effective lives of informs. brief product life cycles and rapid advances in technology, tion systems te iterion, Design B, ‘vith a payback period of wid to be short. Using this crit four yrs, would be selected over Design A, whose payback wil take four and one-half years The length of the payback period often takes precedence over other considerations represented by intangible benefits. Prepare Systems Selection Report ‘The deliverable product of the systems. selection process is the systems selection report. ‘This formal document consists ofa revised feasibility study, a cost-benefit analysis, and list and crenata of'intangible benefits for each alternative design. On the basis of this report, the steering committee will select a single system that will cd to the next phase of the SDLC—detailed design. em Se Detailed Design—Phase V The purpose of the detailed design is phase is to produce a detailed description of tt propose system that both satis the system requirements identified a es : ysis and is in accordance with the conceptual design. In this phase, all system ‘components( pesos DEEPEN LI 195 k tohed ‘of Cash flow ‘Analysis 600 500 400 300 Dollars (thousands) 200 Payback Point 100 Discounted 809, Payback Method of Cost-Benefit 500, Analysis @ 400 z 3 £3007 “ g 5 8 200 3 é 100196 Development and Program Chane ‘ctvites Chapter 5: Sy usly specified. At the eng ina detailed design FePort. This formats, output report layouts, ren proceed £0 the finaj physically constructed, siculo% (ser views, database tables, processes and cont ty me of this phase, these components are PreseOIeN TN Teen report constitutes a set of blueprints that specy MPH y plans th database structures, and proces lope These COMES. system is phase in the SDL systems implementation" Pe stem Design Walkthrough sforms a system desi SEO ee the Sted gr the development team See at edd Vala ie trallthrough to ensure thatthe design is fee from conceptual errs roughs conducted grammed into the final system. ade up of programmers, by a quality assurance group. This group is an in late the operation of the analysts, users, and internal auditors. The jab of | belaat Sign, Most system err0rs ema. system to uncover errors, omissions, and ambiguities inthe es coreting eros nate from poor designs rather than programming mis rae in the design phase thus reduces costly reprogramming SSS up is to simul Review System Documentation 7 is point. Thi The dead design report documents and describes the system to this point. This report includes the following: and source documents for the system. i inputs Designs for all screen input vvational documents: # Designs ofall screen outputs, reports, and oP: i ements. f Normalized data for database tables, specifying all data elem ; Sacre etractures and diagrams: Entity relationship (ER) diagrams describing the aanavetations in the system, context diagrams for the overall system, low-level data cesses, structure diagrams for the program mod- flow diagrams of specific system ules in the system—including @ ps ‘An updated data dictionary describing ead «Processing logic (flowcharts). ‘eudocode description of each module, hh data element in the database. ‘the qualty contol group scutnizes these documents, and any errors detected are recorded ina walkthrough report. Depending on the extent of the system errors, the quality Assurance group wll make a recommendation. The system design will be accepted without mod- ication, aecepted subject to modification of minor errors, or rejected because of material errors, 'At this point, a decision is made either to return the system for additional design or to proceed to the next phase—system coding and testing. Assuming the design goes for- ward, the documents in the design report constitute the blueprints that guide application programmers and the database designers in constructing the physical system, Application Programming and Testing—Phase VI Program the Application Software ‘The next stage of the SDLC is to select a programming language from among the various languages available and suitable to the application. These include procedural languages like COBOL, ‘event-driven languages like Visual Basic, or object-oriented programming tees Janguages like jes or C++. This section presents a brief overview of various ramming approaches, Systems i i it decisi Ine! diitds whdectre af ucts eee Procedural Languages. A procedi i gramm. ; Languages. A procedural language requires the pro to specify the Brecon which the program logis executed, Procedural Tnnguages Seesaw {hd-generation languages (3GLs), Examples of 3GLs include COBOL, FORTRAN, G In business (particularly in, accounting) applications, COBOL was the dominantr ne sens Development Life Cycle 197 language for ‘ Years, Individual data reoguge os PSS Brat capability for performing highly detaled operations ¢ ‘Wordy” language har itd hans large files. very efficiently. However, itis an extremely 8 Viable language beeag cnt <*S Programming a time-consuming task. COBOL has survived a8 Were coded in ConoL Y Of the “legacy systems” written inthe 1970s and 1980s which to these systems mags sil in operation today. Major retrofits and routine maintenance 200 bilion tines of ee, OE coded In COBOL. A 2009 survey revealed that upwards of COBOL code were in use with 5 billion new lines being added each year. Event-Drive, respond to At84A8eS. Programs writen in event-driven languages are designed when the user pres nal actions or “events” that are initiated by the user. For example, automatically executes key, or “clicks” on an icon on the computer screen, the program the 3GL era eet Sod asocated with that event. This i a fundamental shift from tom in accordanen of signing applications that execute sequentially from top to bot- determines the tee oe the programe thinks they shoul Fncion the user Mic t's Vik ‘code execution, innguage sang Visual Basc isan example of an evnt-ven language. The syntax ofthe tions that con Pl Yet powerful, Visual Basic is used to creat real-time and batch applca- that greatly feonuste fat ies or relational databases. It has a screén-painting feature 13 Y facilitates the creation of sophisticated graphical user interfaces (GUD. Rein dented Languiages. Central to achieving the benefits of the object-oriented discussed previously, is developing software using an object-oriented Programming (OOP) language such as C++ or Java, Many examples of OOP languages exist that offer various features, however, a computer language is said to be object oriented. only if it supports the following Object ‘Objects are realworld phenomena that possess two characteristics: They have state and they have behavior. An automobile is an example of an ‘object. Ithas state (brand, color, horse power) and behavior (starting, chang- ing speed, opening window, and stopping}. Software objects are conceptu- ally similar to realworld objects: The object's state is represented by stored attributes (variables or fields). Object behavior is displayed through meth- ods, which cre functions or procedures that are performed on or by the ‘object to change the state ofits tributes. ‘Class and A dass is a blueprint that defines the attributes and the methods common to Instance cll objects of a certain type. An instance is'a single occurrence of an object within a class. For example, Inventory is a classi, refrigerator, washing machine and dryer are instances of the inventory class. Encapsulation Encapsulation is the act of placing data and methods in the same class and thus restricting access to the object’s components. In this way the internal representation of an object is hidden from outside view. This protects object integrity by preventing users from corrupting its internal data by accidentally or intentionally seting it to on invalid stoe. jtance Inheritance means that each object instance inherits the attributes and meth- Inheritance ods ofthe class to which it belongs. is ‘olymorphism allows multiple and different objects to respond to the same Polymorphism Pome reach objec! may conn the some method name, bul ect upon the mahod diferenly becouse the programming code behind i s'different ineach class. An example of polymorphism isthe function of printing docu- ments. Every object that can be printed (text, graphics, or spreadsheet] must [now howto print itself. The “Print” message sent to these different objec is the same, but the implementation to accomplish the print function within the object is different for each class. 5198 ge Activities sn Cha Chapter 5: systems Development and FOB age used, modern : ing ey small YO programme oduces small programs Programming the Syste. t 1 prodoer sociated with ac efits tata he flow 2 othe Following three ben at perform narrowly def ; modular programming. 4 and tested independent» which Lp ing efficiency. Modules can be cel a ogi 18 Sige , ‘any reduces Programming time. A firni can we few modules. These are system, Working in parallel, the programmers © then assembled into the completed system yze and. change, which are ¢a it les ive changes canbe > Nn a ces the start-up t 1 ance ti parceled out to several programmers si ely to contain material FTO of 3. Control By keeping modules small, they are less likely "6 NO. errors are con- fraudulent logic. Since each module is independent ° tained within the module. Test the Application Software jy céated: Thee are All program, eos must be thoroughly tested before ther ae re deelope, some proven concepts about testing that should be followed PY and considered by auditors in conducting audits. Testing Methodology. ‘The process itself has struct shows a program-teting procedure involving the creation of hyPOt™ and transactions files that are processed by the modules being tes! ‘ured steps to follow. Figure 5.8 ion of hypothetical master files ed. ‘The results of Program- Testing Procedures Test Sales Order Transactions File fAcct# [Name | Sale Amount (432 | John Smith] 100 Test Accounts Receivable Master File AAR Update Application [fen >| Actual Test Compare Results Lo7 fe System Implementation: *hase VII gs Development Life Cycle 199 the testé are and logic erro; to identify programmin8 ‘ccounts receivable update ite an accounts receivable '$1,000 and a sales order the programmer COn- the module's internal fhe run with the Pre then ¢ 18, FaaitPated agnnst predetermined results *xample, in testing the logic of th ted ing the logic of the ai master file record fo Figure 5.8, the programmer might creat transaction record oy oht Smith with a current balance of cludes that anew ot, 100: Befoe performing the update testy logic, the program atte® of $1100 should be created. To verify ramm determined res fet compares the actual results obtained from 1] Testing 0, 8 Offline before Deploying Online. The first point that is critical in testing is to never ‘i i ImplementiensStimate the principle of esting offine before deploying # 27 online. e-commerce fy em without testing ofline is an invitation te disaster. One online testing it offi im went out of business because it implemented a system online without crackers Aone Ls and accidentally left vulnerable Web server oP to attacks from ane (ake sole thousands of eet card numbers and eventually the online ae Dee Creating meaningfl test data is an extremely time-consuming aspect of Chapter 7, ae This activity can, however, provide future benefits. As we shall see in Chaplet 7, application audting sometimes involves progr testing, To facilitate future Th ® eh lata prepared during the implementation phase should be retained for reuse. ea test data will give the auditor a frame of reference for designing and evaluating uture audit tests. For example, if'a program has undergone no maintenance changes since its original implementation, the test results from the audit should be identical to the original test results. Having a basis for comparison, the auditor can thus quickly ver- ify the integrity of the program code. If changes have occurred, however, the original test data can provide evidence regarding these changes. The auditor can thus focus attention upon those areas, Maintaining test data and its results is also a significant control fea- ture, as future systems development can use the test data and results to test future changes to the application software. Tn the system implementation phase of the systems development process, databas® opulated with data, equipment is purchased and installed, structures are created and P' Smployess are trained, te system is documented and the new stem i installed. The smplementation process engages the efforts of designers, programmers database admin- istrators, users, and accountants. The activities in this phase entail extensive costs and will often consume more an all other pre-implementation phases of personnel-hours th: the SDLC combined. i Entire System Bie Earn have been coded and tested, they must be brought together and tested as a. whole, User personnel should direct system-wide testing as a prelude to the formal System implementation. The procedure involves processing hypothetical data through Sy re ou of te syste. then reconciled with predetermined results, test is docu imented to provide evidence of the system’s performance. Finally, fied with the results, they should then complete ucting the tests are ‘This is an explicit acknowledgment by the user that the document.200 Chapter 5: Systems Development and Program Cha"Be Laue document becomes x acceptance system in question meets sated requemens. THEE Consity dunn the pos. important in reconciling differences and assigning: implementation review of the system. : Documenting th m it tial information about how. ‘The system's ary provides the auditor ei oe groups—systems designery the system works, The documentation requiremen's ™ o¢ particular importance, and programmers, computer operators, and end Use sajners od yrogtamn Designer and Programmer Documentation. SYST TC oy the system, Ths need documentation to debug errors and perform Ty which requires both gen. group is involved with the system on a highly ei through DFDS, ER diagrams, ang ‘ral and detailed information. Some of this is provi 05am flowcharts, and program structure diagrams. In addition, system flowcharts, PTne system flowchart shows the code listings are important forms of documentation. Towcrer, it does not reveal the relationship of input files, programs, and output files. "7 owchart provides logic of individual programs that constitute the system. tion of the program. Each pro. 2 detailed description ofthe sequential and logical OPer8H0" OT owchart, as shown gram in the system's flowchart is represented by 2 seP2 7 jew and evaluate the pro- in Figure 5.9. From these, the programmer can visually TT” i comments that gram’s logic. The program code should itself be documen describe each major program segment. Zeus ‘System Designer and Programmer Documental Program Code Program Flowchart < sat > Open $0 File IF EOF THEN END <> on se > (Open Customer File IF EOF THEN a3] cet END Ree Eise 1 oS Read Sales Order Record eed ~~ Read Customer Record Ree {IF Cus_1D = Cus_NoTHEN H (program code continues) N { s y ' . Update { . Master ' ec i : i i[ens Besloiment Life Cyt . 201 Operato; r D Manual, whign "eMation, include; Gesctibes ory go COMPULEr operators use documentation called a rue ‘ 'OW to run the system. ‘The typical contents of a run manual 1 name . the g run ystem, such as Py ‘ edule a h as Purchases System : esuired han ae al weekly, time of day, ete) Eu Fedutemene eT pes, dks, printers, of spell hardware) 6S Used in the ina ‘ying all the transaction (input) files, master files, and output Run-tim, Ne instruct sand the na ons describ ing the error messages that may appear, actions to be system fi * ME and tele es yee a hone number of the programmer on call, should the ist of “SEIS Who receive the output from the run code Het ettY and co this segregatio tem’s internal iNgS should pert F880Ns, system flowcharts, logic owcharts, and program activities of Patt of the operator documentation. We saw in Chapter 2 2 OF deer ammers and operators should be separated. Consistent with Topic tS 8806, operators should not have acces tothe deals ofa 595 User Docu: m User tasks ier @tion. Users need documentation describing how to use the system. account bal documentation technology. Thus, assess and classi scheme: include such thin, ate 5 Hae auLies of ss te ;, making inquiries of ces apdati nef,leting input for transactions, making ing ‘Updating accounts, and generating output reports. The nature of user will depend on the user's degree of sophistication with computers and S, before designing user documentation, the systems professional must ify the user’s skill level. The following is one possible classification Novices have litle or no experience with computers and are embarrassed to ask Questions. Novices also know little about their assigned tasks. User training and doc- mentation for novices must be extensive and detailed. Occasional users once understood the: system but have forgotten some essential commands and procedures.. They require less training and documentation than novices. Frequent light users are familiar with limited aspects of the system. Although func- tional, they tend not to explore beneath the surface and lack depth of knowledge. This group knows only what it needs to know and requires training and documen- tation for unfamiliar areas. Frequent power users understand the existing system and will readily adapt to new systems. They are intolerant of detailed instructions that waste their time. They like to find shortcuts and use macro commands to improve performance. This group requires only abbreviated documentation. User Handbook. With these classes in mind, user documentation often takes the form of a user handbook, as well as online documentation. The typical user handbook will contain the following items: wee ‘An overview of the system and its major functions structions for getting started Darton of procedures with step-by-step visual references Examples of input screens and instructions for entering data ‘A complete list of error message codes and descriptions202 Development and Program Change Activites apter St Systems «A reference manual of commands to run the system @ A glossary of Key terms «Service and support information wll guide the user interactively in the ust of the system, Some commonly found online features include tutorials and help features. Online tutorials can be used to train the novice OF the occasional ty, que is based on the tutoral’s degree of realism. Tutor, see sano restrict the user frm acces to legitimate fonctions imple to sophisticated. A simpy Help Features. Online help features range from simple to sophisti help feature may be nothing more than an efror Memegy displayed on the Screen, The 10 the problem. Mor ee must “walk through” the screens in search of the solution to the pr sophisticated help is context-related, When the ut makes an error, the system wil " * the context of what send the message, “Do you need help?” The help feature anal ‘ fat the user is doing atthe time ofthe error and provides help with that specific function ( Online documentatior Tutorials. The success of this techni command). Converting the Databases * Database conversion is a critical step in the implementation phase. This is the transfer of data from its current form to the format or medium required by the new system. The degree of conversion depends on the technology Jeap from the old system to the new one, Some conversion activities are very labor intensive, requiring data to be entered into new databases manually. For example, the move from a manual system to a com- puter system will require converting files from paper to magnetic disk or tape. In other Situations, data transfer may be accomplished by writing special conversion programs. A case in point is changing the file structure of the databases from sequential to direct access files. In any case, st be carefully controlled. The following precautions should be taken: 1. Validation. The old database must be validated before conversion. This requires ana- Iyzing each class of data to determine whether it should be reproduced in the new database. 9, Reconailiaion, After the conversion action, the new database must be reconced agnnst the orignal. Sometimes this must be done manually, record by record and field by field. In many instances, this process can be automated by writing pro 1m that will compare the two sets of data, be kept as backup against discrepancies in 3, Backup. Copies of the original files must the converted data, If the current files are already in magnetic form, they can be conveniently backed up and stored. However, paper documents can create storage problems. When the user feels confident about the accuracy and completeness of the new databases, he or she may destroy the paper documents. data conversion is risky and mu: Converting to the New System The process of converting from the old system to the new one is called the cutover: ‘A system cutover will usually follow one of three approaches: sin oto approaches: cold turkey, phased, 0" Cold Turkey Cutover.' Under the cold turke i i xy cutover approach (also called the “Big Bang approach), the firm switches to the new system and simultaneously terminates the ‘ld system. When implementing simple systems, this is often the easiest and least cost”aa vere Life Cele er 203 approach, Wit skydiving widen complex systems, itis the riskest. Cold turkey cutover is akin to there is no problegy eer¥e Patachute As long asthe main parachute fanctions properly> errors that were not = things don't alwaye work the way they are supposed 10. System unexpectedly, Wily ote ring the walkthrdugh and testing steps may materialize transaction hout a backup system, an organization can find itself unable to process S and meet it its obligations to it ‘. ‘customers and creditors. Phased Cutover. - ‘once. The phased cut Sometimes an entire system cannot, or need nots be cutover ct Figure 5.10 shows (earn Devin operating the new system in modules. For example, followed by the in }ow we might implement a system, starting with the sales subsystem, By phasing rielon, control xbsysiem, and finally the purchases subsystem failure. However, the shee modules, we reduce the risk of a devastating sYSte™ tems and yet-to-benn phased approach can create incompatibilities between Tew subsys- t0-be-replaced old subsystems. This problem may be all menting speci 5 period Pci conversion systems that provide temporary rterfeces during the cutover aaa Operation Cutover. Parallel operation cutover involves running the old system and the new system simultaneously for 2 period of time. Figure 5.11 illustrates = ipproach, which is the most time-consuming and costly of the three approaches. ning two systems in parallel essentially doubles resource consumption- During the poe Peal baae atias Se ele Old Sales System New Sales System ‘Old Inventory Control System | ‘New Inventory Control System ‘Old Purchases System. [__.New Purchases System Time ‘ld Sales Order System Now Sales Order System ‘Simultaneous poration Parody RA grandee re eeand Program Change ‘Activities Chapter 5:_ systems Developmen single system. Th, ‘ rces of a single is twice the resources O° Se the databas yo piems conse ing tie ce the data cutover period, the 8 includes twice the soures documents, vec ores and twice the output production. risk. By runn} ms, nip predic ye reduction 1 et pefre runing business cycle, such The advantage of paral the user can reconcil new system solo, Parallel operation shoul as one month. This allows the user t0 as a final test of the system's functionality- rato deny esos and debe er ats at the end ofthe cyl, Post-Implementation Review 7 ctually takes place soy One of the most important steps in the implementation acted by A indesees one oe acer a pestimplementaion review. The TeV OT after the dust hy months [te in a ve the sccess of the system and of th Foot re on budge, settled, Although systems professionals strive (© prodace the ge ait Naan asy user needs, this goal is not always ataines eights ito ws = review of a newly installed system can provide management te (both ied ce, improve the process for future systems. It can also provide auditors val and the ad external) with evidence regarding the adequacy of the SDLC in age abl 1¢ risks Susociated with a particular system, The following are examples of valuable post- implementation evidence. Systems Design Adequacy. The physical features of the system should be reviewed to see jf they meet user need, The reviewer should seek answers to the following types of questions: 2 «Does the output from the system possess such characteristics of information as rele- vance, timeliness, completeness, accuracy, and so ont I the output in the format most useful and desired by the user (such as table, graphs, electronic, hard copy, ete)? ‘are the databases accurate, complete, and accessible? Were data lost, corrupted, or duplicated by the conversion process? ‘Are input forms and screens properly designed and meeting user needs? ‘Are the users using the system properly? Does the processing appear to be correct? Can all program modules be accessed and executed properly, or does the user evr get stuck in a loop? Is user documentation accurate, complete, and easy to follow? Does the system provide the user adequate help and tutorials? Accuracy of Time, Cost, and Benefit Estimates. The task-of estimating timé costs, and benefits for a proposed system is complicated by uncertainty. This is particu- larly true for large projects involving many activities and long time frames. The mote variables in the process, the greater the likelihood for material error in the estimates. History is often the best teacher for decisions of this sort. Therefore, a review of actual performance compared to budgeted amounts provides critical input for future budgeting decisions. From such information, we can learn where mistakes were made and how t0 avoid them next time, The following questions provide some insight: Were actual costs in line with budgeted costs? ‘What were the areas of significant departures from budget? Were departures from budget controllable (internal) in the short run or noncontrol- lable (eg, supplier problems)?yd Auditing the aise am Aualiting the SDLc 205 Sstimat, a8 th "8 of the Ae use 8° of rewor net Fines of program code accurate Were yal; Teceiving the expecret {sigh and coding errors acceptable? ANNES assigned to t , ‘ected benefits from the system? ems Mi te te ible and, especially, intangible benefits accurate? 5 ten: especially, le ance—Phase yy Once a system is ini nal 'S imple date eg formal p en en the final phase in is life cycle. Systems mainte- system aoe 19 user needs” gent lication programs undergo changes to accommo, aso Produce a new Ne application changes are trivial, such as modifying the also be extensive, such ng PO" OF changing the length of a data field. Maintenance can interface. Dependine nyo ™king major changes to an application's logic and the user Years or longer, Syste 'pon the organization, the systems maintenance period can last five system life spans, When highly competitive business environments see much shorter tain an aging system: yt $80 longer feasible fr the organization to continue to main- Maintenance repre ct2PPC% and a newesystems development life cycle begins. ment costs. Over 5 Presents significant resource outlay compared to initial develop- be incurred in the ott life span, as mach as 80 to 90 percent of its total cost may : e mai j Ee On ay nance in the next geaneTane® Phase. We review the auditing implications of mainte, CONTROLLING AND AUDITING THE spc pro in this chapter we established the importance of the systems development and in, ee ele as an internal control and audit issue that auditors need to consider either ia luct of a financial: audit. A properly functioning development process sures that only needed applications are created, that they are properly specified, that they possess adequate controls, and that they are thoroughly tested before being imple- mented. Systems maintenance procedures ensure that only legitimate changes are made to applications and that those changes are also tested before being implemented. Together, these processes establish the accuracy of new applications and preserve their integrity throughout the period under review. If the auditor can verify that these processes are controlled and functioning effec- tively, he or she may limit the extent of application control testing that needs to be done and can establish a basis for limiting substantive tests. If, however, audit evidence shows SDLC controls to be weak and inconsistently applied, application testing and sub- stantive testing cannot be reduced. In some situations, it may even be necessary to expand the scope of the audit. With this perspective in place, let's now examine the con- trols, audit objectives, and audit procedures related to these important processes. New Systems Development The first five controllable discussed next deal with the authorization, develop- net and implementation ofthe original system, The last two controllable activities per- tain to systems maintenance procedures. uthorization Activities Systems be properly authorized to ensure their economic justification and feasi- Al aa ‘with all material transactions, authorizing the development of a new informa- pees ould be a formal step in the process. Typically, this requires that each new tion ;Activites Chapter sytem Development and Program Core Acti i tems professionals who have by sited in weiting by users to systems A jest be submited in WT id approve (oF Feject) the request. | system requ the ai authority to the expertise and User Specification eed in the systems development process. Their involvemen, Users should be actively Te he proposed system is technically complex. Regardless of should not be sited Beste “er ean and should provide a detailed written description the te ee hat must be satisfied bythe system. The creation ofa use specifica. ofthe log! neem involves the joint efforts of the user and systems professional nanever, Mra most important that this document remain a statement of user needs. j Hower ibe the user’ view of the problem, not that ofthe systems professionals Technical Design Activities The technical design activities of the SDLC translate user specifications of need into a set of detailed technical specifications of a system that meets those needs. The scope of these activities includes systems analysis, general systems design, feasibility analysis, and detailed systems design, The adequacy of these activities is measured by the quality of the documentation that emerges from each phase, Documentation is both a control and evidence of control and is critical to the system’s long-term success, Specific documents. tion requirements were discussed previously. Internal Audit Participation ‘The internal auditor plays an important role,in the control of systems development activities, The auditor should become involved at the inception of the process and con- tinue throughout all phases of the development process and into the maintenance phase. ‘The following describe auditor involvement in key area of the SDLC. The Auditor’s Role in Systems Planning. Systems planning greatly reduces the risk that an organization has produced unneeded, inefficient, defective, or fraudulent sys- tems. Therefore, internal auditors review the planning process to verify that the systems produced are consistent with the organization's goals and objectives. The Auditor’s Role in* Systems Analysis. ‘The business problem to be solved through technology must be fully understood by the systems analyst. A significant misun- derstanding of the user needs and expectation’ at this early juncture can result in a mate- rially flawed project. An IT professional's domain of expertise lies in the area of technology; he or she may not have expertise in functional business areas’stch as account- ing, End users, on the other hand, are expert in their business fields, but may know little of nothing about technology. An internal audit group, astute in computer technology and with a solid grasp of the business problems of users serves in an essential liaison capacity in the meeting of the minds that must occur early in the development process. The Auditor’s Role in Conceptual Systems Design. The auditability of a system depends in part on its design characteristics. Some computer auditing techniques such as the Embedded Audit Module (EAM) and the Integrated Test Facility (ITF) need to be designed into systems as integral components, The internal auditor is best qualified to determine if the system under consideration is a good candidate for an integrated audit features and, if so, which feature is best suited for the system. Integrated audit tools will add costs and significant features to the system that should be specified at the conceptual design stage and budgeted into the project. 0 SE 5 Discussed in Chapter 7.jog and Avating the SDLC 207 for’s cerned th; ‘ole in Ey Rt the economic fr ittion and Selection, ‘The internal auditor 18 com cally, the aud OF the Proposed system is measured as accurately Only escapabe co, tor shauld ensure five things: R ts ; Reasonable interest rare Sd calelations of cost savings benefits. ne te and recur i ae measuring present values of cath flows Realistic nsf tir os te completly and acurtely reported tangible benefits re ted in comparing competing projets. re assigned reasonable financial values. sand mi tort the analysis and and misrepresentations in the accounting for such items can dis- The ‘Audi ind result in a flawed decision. uditor’s Ry ; their expertise to ae in System Implementation. internal auditors should lend may get involved in the and shape the finished system. Specifically, internal auditors following ways. : Provide Te, tions of weet Expertise. ‘The detailed design phase involves precise specifica- compliance with Gane rules, and conventions to ensure that the system is in regulations. Failir \P, GAAS, SEC regulations, IRS codes, and certain international choosing the ara comply may lead to legal exposure for the firm. For example, cal background depreciation method or asset valuation technique requires a techni- Fide thi Bot necessarily possessed by systems professionals. The ‘auditor may pro- expertise to the systems design process. Specify Documentation Standards. In the implementation phase, the auditor plays a role in specifying system documentation, Since financial systems must periodically be audited, they must be adequately documented. The auditor should actively encourage adherence to effective documentation standards. Verify Control Adequacy and Compliance with SOX. The AIS applications that emerge from the SDLC must possess adequate controls. In addition, compliance with SOX legislation requires management to certify the existence and effectiveness of those controls. During the implementation process, the internal audit function plays a Key role in these verification and compliance activities. User Test and Acceptance Procedures ‘Before implementation, the individual modules of the system must be tested #8 a unified aol A test team comprising wer personnel, systems professionals, and intemal audit per sonnel subjects the system to rigorous testing, Once the test team is satisfied that the system meets its stated requirements the system is formally accepted by the user department(s). "The formal testing and acceptance of the system. by the user is considered by many auditors to be the most important control over the SDLC. This is the last point at which the user can determine that the system adequately meets his or her needs. Although dis- sng a material flaw at this juncture may be costly, discovering the flaw later, during Serta sre devastating, The user's acceptance of the new system should be for- oy mally documented. ted to New Systems Development ies are applied consistently and in accordance with manage- ‘Audit Objectives Relat Verify that SDLC activiti ‘ment's Len the system as originally implemented was free from material errors Determ! and fraud.208 Chapter 5: Systems Development and Program Change Activities Confirm thatthe system was judged to be necessary and justified at various check, points throughout the SDLC. © Verify that system documentation is sufficiently accurate and complete to facilitate audit and maintenance activities. ‘Audit Procedures Related to New Systems Development projects and review the documentation The auditor should select a sample of completed t : eetilence of compliance with SDLC polices. Specific points for review should include determining the following: : End user and IT management A preliminary feasibility study sl AA detailed analysis of user needs designs. «A ccost-benefit analysis was conducted using reasonably accurate figures. The project’s documentation shows that the detailed design was an appropriate and accurate solution to the user’s problem. «Test results show that the system was thoroughly tested at both the individual mod- tule and the total system level before implementation. (To confirm these test results, the auditor may decide to retest selected applications.) There is a checklist of specific problems detected during the conversion period, along with evidence that they were corrected in the maintenance phase. «systems documentation complies with organizational requirements’ and standards, properly authorized the project. showed that the project had merit. ‘was conducted that resulted in alternative general ‘The Controlling and Auditing Systems Maintenance The last two controllable activities pertain to systems maintenance. Upon implementa- tion, the system enters the maintenance phase of the SDLC. This is the longest period in the SDLC, often spanning several years. It is important to recognize that systems do not remain static throughout this period. Rather, they may undergo substantial changes that constitute a financial outlay many times their original cost. If an application has undergone maintenance (and even if it has not), its integrity may have been compro- mised since implementation. The auditor's review may, therefore, extend into the main- tenance phase to determine that application integrity is still intact. In this section, we see how uncontrolled program changes can increase a firm's exposure to financial misstatement due to programming errors. Some programming terrors are subtle, resulting in the creation and distribution of incorrect information that goes undetected by the user, Other forms of errors are more apparent.and result in sys- tem failures that can disrupt data processing and even bring operations to a halt. In addition to these exposures, program fraud may take root in an environment of poorly controlled maintenance and can go undetected for years. Maintenance Authorization, Testing, and Documentation ‘The benefits achieved from controlling new system development can be quickly lost dur- ing system maintenance if control does not continue into that phase. Access to systems for maintenance purposes increases the possibility of systems errors. Logic may be cor- rupted either by the accidental introduction of errors or intentional acts to defraud. To minimize the potential exposure, all maintenance actions should require, as a minimum, four controls: formal authorization, technical specification of the changes, retesting the system, and updating the documentation. In other words, maintenance activities shoulding 20d Aves oo 18 the SDLC 209 be given and ji tially . Whe Potent aE treatment as new development. The extent of the change as inven tMANCE cause HE system should govern the degree of control applied. tance premeMt bythe inn ete changes to program logic, additional controls, such S° Procedures may je sit! auditor and the implementation of user test, and aCceP- sary. Source p, ie rogtam Li ‘ Tn spite of the proceae™*tY Controls dized by in ng ma divi intenance procedures, application integrity can be jeopar- section deals —e Bain unauthorized cers ee. ‘The remainder of this ‘orized acces to applica udu and procedures for preventing and detecting una- n Programs, disks called the ‘ystems, application program source code is stored on magnetic - between the SPL a ae Program library (SPL). Figure 5.12 illustrates the relationship To execute 2 prog HEF components ofthe operating environment. load module that re tio” application, it must first be compiled and linked to create ‘ and free from the gee Peet Can process. As a practical matter, load modules are seams maintenance and qenett of unauthorized modification. Program changes (both autho ned Source code can enauthorized changes) are accomplished by frst making changes to Sttved on the SPL and then recompiling and linking the program to create a rec, ond module that incorporates the changed code. Therefore, the SPL is a sense Area, which, to preserve application integrity, must be properly controlled The Worst-Case Situation: No Controls ‘ Figure 5.12 shows the SPL without controls. This arrangement has the potential to create the following two serious forms of exposure (see the following list). * eae Uncontrolled Access to the Source Program Library ‘Systems Development Programmers Source Program Library Production Load Library Lion Object Link Ett canal medute Program Production Application210 pange Activites Chapter 5: Systems Deveapment and Programs a0 restricted, Programmers and others can access ons is completely ree is no provision for detecting an una. Le Access to programs It eer rath any programs stored e thorized intrusion. srams are subject to unauthorized chan, weaknesses, prog? ies, 2. Because ofthese ctr earring on the effectiveness of other controls (maint. Hence, there Is 1 program testing, and ¥locumentation). In other words, with no a eae ecting unauthorized access to the SPL, program integrity cannot be provisio “ verified. is ‘ict with operational flexibility and efficiency. For these rea. Control away con must work daly nthe doa'eavroament socio fons, settroling the SPL. To achieve a mutually acceptable control-lexblity trade. oPPemtween the needs of systems professionals and auditors, both must understand the Siposures that are created when control features are not employed or are routinely cr ‘cumivented. In spite of the exposure just described, the no-controls approach is often the ' choice (perhaps inadvertently) that management makes. A Controlled SPL Environment To control the SPL, protective features and procedures must be explicitly addressed, and this requires the implementation of an SPL management system (SPLMS). Figure 5.13 illustrates the use of this technique. ‘The black box surrounding the SPL. signifies the SPLMS. This software is used to control four routine but critical functions: (1) storing programs on the SPL, (2) retrieving programs for maintenance purposes, (3) deleting obsolete programs from the library, and (4) documenting program changes to provide an audit trail of the changes. ‘ You may have recognized the similarities between the SPL management system and a database management system. This is a valid analogy, the difference being that SPL. software manages program files and DBMSs manage data files. SPLMSs may be supplied by the computer manufacturer as part of the operating system or may be purchased through software vendors. Some organizations, to provide special control “features, develop their own SPL software. The mere presence of an SPLMS does not guarantee program integrity. Again, we can draw an analogy with the DBMS. To achieve data integrity, the DBMS must be properly used; control does not come automatically, it must be planned. Likewise, an SPL requires specific planning and control techniques to ensure program integrity. The control techniques discussed in the following paragraphs address only the-most vulnera- ble areas and should be considered minimum control. Password Control, Assigning passwords provides one form of access control over the SPL. This is similar to password controls used, in a DBMS to protect data files. Every financially significant program stored in the SPL can be assigned a separate pass- word. As previously discussed, passwords have drawbacks, When more than one person is authorized to access a program, preserving the secrecy of a shared password is a prob- Jem. As more authorized personnel have a need to know the password, the potential for losing control of the password increases, Since responsibility for the secrecy of a shared password lies with the group rather than with an individual, personal accountability is reduced, and individuals within the group may take less care in protecting the password, Separate Test Libraries. Figure 5.13 illustrates an improvement on the shared pass" word approach through the creation of separate password-controlled libraries (or direc- tories) for each programmer. Under this concept, programs are copied into thef jotiag a Auditing the SDi.g Systems systems Maintenance Programmers Development programmers. Jr} Compile and Link Edit Maintenance Request os] Program —| Listing programmer's library for maintenance and testing. Direct access to the production SPL is limited to an authorized librarian who approves all requests to modify, delete, and copy programs, Further, passwords to access programs should be changed regularly and dis- closed only on a need-to-know basis ‘An enhancement to this control feature is the implementation of program naming sconventions, The name assigned a program clearly distinguishes it as being either a test ‘ot a production program, When a program is copied from the production SPL. to the programmer's library, it is given a temporary “test” name. When the program is returned to the SPL, it is renamed with its original production name. This technique greatly reduces the risk of.accidentally running an untested version of a program in place of the production program. ‘Audit Trail and Management Reports, An important feature of SPL manage- st software is the creation of reports that enhance management control and- the mudi function. The most useful of these are program modification reports, which aut Fane all program changes (additions and deletions) to each module, Thee putt should be part of the documentation file of each application to form an212 caper $1 Stems Development and Program Change Actives ; aver the life of the application. During an audit, thse at ol am et a ae mee changes requested and ‘authorized were actually implemented. For example, if a pro. grammer attempted to use a legitimate maintenaie® action as an opportunity to com, nit program fraud, the unauthorized changes (0 the program code would be presente in the program modification report. These reports can be produced as hard copy ang ‘on disk and can be governed by password control, thus limiting access to managemen and auditors. Program Version Numbers. The SPLMS assigns a version number automaticly each program stored on the SPL. When programs are first placed in the libraries (upon ‘fiplementation), they are assigned a version number bf 0, With each modification to the program, the version number is increased by 1. For instance, after five authorized main. Penance changes, the production program will be designated version 05, as illustrated in Figure 5.14. This feature, when combined with audit trail reports, provides evidence for identifying unauthorized changes to program modules. An unauthorized change is sig naled by a version number on the production load module that cannot be reconciled to the number of authorized changes. For example, if 10 changes wete authorized but the production program shows version 12, then one of two possibilities explain this dis. crepancy: (1) authorized changes occurred that are unsupported by documentation or (2) unauthorized changes were made to the program, which incremented the version nuimbers. (ERIE uaiting spi software System = * Medio ‘Syria Development Testa 5 Stems [Apteaton ‘SPL Management System Dovlopmert bs] Prem 1 \ sropanmers Sco Prat ! Usry (0) | Auborzes and La Compt and | Reasests New ithe onicatons Systems Mabtnance ka H Test Ubrary Program 1 Se ‘optcaon | C satanarce >>| Progam | \ eooarmes 1 1 lege 05 ! | Requests i {Sen = | — See 1 ‘Autor confims maintenance o6| Poo 1 reauests with user management oat to verty maintenance authorization one) and conten. Bap a t ‘Auditor compares te curent ‘Autor recorces program ‘maintenance request, program program version number in the tings, and program changes overly Socamentaton fe wih the currant ‘he noed for and accuracy of program \vorslon number ofthe production mmalnerarce. rogram. Oiserepancies incicato “undeeunerted program changesing 204 Avdting the SDC 213 | contol, ‘Ace Wwerful ‘m, ‘SS to gram Version (onanee commengnanee Commands, SPL management systems use ating a recon ification) na et oF eliminate program passwords, alter the Po- designers and admis Modifcation atl temporarily modify a program without gener- nance comman, ‘ministrators need ieee are legitimate technical reasons why systems gram modi OPED the poss commands However, i nat controlled, mainte- Password-cont, ‘Ons. Hence, access " _ of unrecorded, and perhaps unauthorized, pro- or the sean rolled, and the auth '0 the maintenance commands themselves should be ‘urity group, lority to use them should be controlled by management Audit Object; * Detect ‘ce to System Maintenance Processing Raa Fein maintenance (which may have resulted in significant applications from nts) Determine that (1) maintenance procedures protect . SrTors, and (3) pro nauthorized changes, (2) applications are free from material wea ram libraries are protected from unauthorized access. pay that are necessary to, a of these objectives in turn, focusing on the tests of controls tion employs SPL sone tht obiestive. The discussion will assume thatthe organiza- ire to control program maintenance. It should be noted that without SPL software, j e vare, it can be difficult 7 ; ve oo described next are illustrated in Fig it aleve these audit objectives. The procedures a Procedures Related to System Maintenance le Fl i iy Unauthorized Changes. To establish that program changes were autho- et auditor should examine the audit trail of program changes for a sample of applications that have undergone maintenance. The auditor can confirm that authoriza- tion procedures were followed by performing the following tests of controls. © Reconcile program version numbers. The permanent file of the application should contain program change authorization documents that correspond to the current version number of the production application. In other words, if the production application is in its 10th version, there should be 10 program change authorizations in the permanent file as supporting documentation. Any discrepancies between ver- sion numbers and supporting documents may indicate that unauthorized changes were made. © Confirm maintenance authorization. ‘The program maintenance authorization docu- ments should indicate the nature of the change requested and the date of the» Change. It should also be signed and approved by the appropriate management ter services and the user departments. The auditor should confirm from both comput ; a i confin the facts contained in the maintenance authorization and verify the authorizing sig- natures with the managers involved. P ication Errors. The auditor can determine that programs are free Identify Application srming thre types of tests of controls: reconciling the source ial errors by P' ) ae ec the test results, and retesting the program. code, de, Each application's permanent file should contain the cur- ae iend listings ofall changes made to the application. These docu- rent Pr etal the application's maintenance history. In addition, the ments describe 1 change should be clearly stated on the program change nature of the PTO “The auditor should select a sample of applications and authorization Reconcile the source 00Pr hange Activities m4 Chapter Stems Development and Programs Crane sth the appropriate authorization documents, crm ne modular approach t0 sYS6% "greatly facilitates this testing technique, small discrete progran Tae odules enhances the auditor's ability to identifying’ se ce ions, and potentially fraudulent programm rites that indicate er70 : rs, omiss code, rogram change should be thoroughly tested before deis Review test Lereeastin ‘procedures should be properly documented by ta implemented arg and processing results, which support the programmer’ dest objectives a the change. The auditor should review this record for each signe on rogram change t esablish that testing was suficenty rigorous to iden ca . Rejest the program. The auditor can retest the application to confirm its integrity, * We examine several techniques for application testing in Chapter 7. reconcile each pr Test Access to Libraries. The existence of a secure program library is cefttral to pre. venting errors and program fraud. One method is to assign library access rights excly, sively to individuals who act as librarians. Their function is to retrieve applications from the program libraries for maintenance and to restore the modified programs to the library. In this arrangement, programmers perform program maintenance and testing in their own “private” libraries but do not have direct access to the program library. The auditor should establish that the program library and private libraries are pro. tected from unauthorized access by performing the following tests of controls. # Review programmer authority tables. The auditor can select a sample of program. mers and review their access authority. The programmer's authority table will spec- ify the libraries a programmer may access. These authorizations should be matched against the programmer's maintenance authority to ensure that no irregularities exist. * Test authority table. The auditor should simulate the programmer's access privileges and then violate the authorization rules by attempting to access unauthorized librar- ies. Any such attempts should be denied by the operating system. a ee This chapter examined the structure, control, and audit of the SDLC. It began by describing the roles of the participants involved in systems development, including systems professionals, users, and stakeholders. Then it outlined the key activities asso- ciated with SDLC. This process consists of two primary sets of activities: new systems development and maintenance, The former, which is used to guide the development of information systems in many organizations, includes systems planning, systems analysis, conceptual design, system selection, detailed design, system programming and testing, and systern implementation. A properly functioning systems development pro- cess ensures that only needed applications are created, that they are properly specified, that they possess adequate controls, and that they are thoroughly tested before being implemented. Upon implementation, new systems enter the systems mainte- nance phase, where they undergo modifications to keep them current until they are