The nature of the steps within the design phase of the SDLC is different, depending on whether the organization intends to purchase software or design the software in-house. Much of the software used by organizations today is purchased. However, even when software is purchased, it is likely to be modified or customized to suit the specific needs of the organization. Therefore, there are similarities in the steps of the system design phase when software is purchased and when it is designed and written in-house. Exhibit 6-5 shows the typical steps undertaken when software is purchased.
When the project team has reached the design phase, user needs and system requirements have previously been determined in the systems analysis phase. Therefore, the project team is ready to solicit proposals from different software vendors for accounting systems that satisfy the identified user needs and meet the system requirements.
Often, an organization hires a consultant to assist in the selection, design, and implementation of purchased software. If the organization intends to hire a consulting firm, such hiring may take place at this point. However, it is important to understand that a consultant could be hired for any part or parts of the SDLC. The hiring of the consultant is mentioned at this point (see Exhibit 6-5) to show how consulting firms may be used throughout the SDLC.
The process to solicit proposals is called a request for proposal, or RFP. A RFP may be sent to each software vendor offering a software package that meets the system and user needs. When the vendor returns the RFP, it will include details such as a description of the software that it intends to sell, the technical support that it intends to provide, and the related prices.
Once all RFPs have been received, the project team and IT governance committee should evaluate the proposals in order to select the best software package. There are many things that the project team and IT governance committee should consider when evaluating each proposal, such as the following:
The project team or IT governance committee must choose one of the several competing software products. The technical feasibility is an assessment of whether or not the existing computer hardware, or hardware to be purchased, represents adequate computing power to run the software. The operational feasibility refers to the capability of the existing staff of employees and any planned new hires to use the software as it is intended. The economic feasibility refers to the cost–benefit analysis of each software package. The cost–benefit analysis is a comparison of costs with benefits. The schedule feasibility is an analysis of the time to install and implement each software package. From the evaluation of these factors, the software system that best fits the organization's needs will be selected and purchased.
In general, purchased software is less costly and more reliable and has a shorter implementation time than software designed in-house. Purchased software has these advantages because it is written by the software vendor, its cost is spread over several clients, and the coding and testing are already complete when a customer buys the software. However, nearly every organization has unique needs or circumstances that may not match the software exactly. There is often a need to customize the software or the reports within it. The project team should develop design specifications for any modifications to the software or the reports. In the case of major modifications to purchased software or in the case of in-house design, the system design phase would include specific steps to design the outputs, inputs, processes, controls, and data storage of the revised system. The next section describes the steps of the in-house design phase.
As discussed in the previous section, the systems analysis report identifies user needs and system requirements. Exhibit 6-6 shows a process map for the in-house design of accounting system software, with the systems analysis report containing the input information to begin this phase.
As discussed, while it is not necessary to hire a consulting firm, many organizations find that the special expertise of consulting firms is most beneficial in the design and implementation of accounting system software. Such firms have a broad range of expertise, assisting many different types of organizations with many different types of software systems. The choice of whether to use a consultant and the point at which to hire one are fully dependent on the extent of in-house expertise available within the organization.
Whether or not a consulting firm is hired, the next step is the conceptual design phase, which involves identifying the alternative conceptual design approaches to systems that will meet the needs identified in the system analysis phase. This step could be viewed as a sort of “brainstorming” to generate the different conceptual approaches in a system design that will meet the identified needs. In the case of purchased software, this step is taken by sending RFPs to several software vendors. In the case of in-house design, the project team must identify different conceptual design approaches. For example, there are different types of payment processing available to organizations to receive and pay invoices. The different approaches range from a traditional system that matches the purchase order, receiving, and invoice documents and involves relatively little complex technology to a Web-based electronic invoice presentment and payment (EIPP) system. The EIPP system is a “matchless” system in which invoices are paid as soon as they are electronically delivered; there is no matching of documents prior to the approval and payment of the invoice. While both of these systems accomplish the payment of invoices, they each rely on differing amounts of technology and complexity. The EIPP system requires more complex and advanced technology and fewer manual steps. The traditional document matching requires simpler technology and involves more manual tasks. These are examples of different conceptual design approaches. The project team should identify the different conceptual designs that meet the identified needs.
When the conceptual designs are identified, the project team must evaluate the alternatives and choose the best design. Evaluation and selection is the process of assessing the feasibility and fit of each of the alternative conceptual approaches and selecting the one that best fits the organization's needs. The evaluation process includes a more detailed feasibility study, with the same set of feasibility assessments identified earlier examined in detail for each of the conceptual designs. The feasibility assessments in the study include the following:
In this phase, the assessment of each feasibility aspect is more detailed and the scope of the study is much different from the feasibility study in the systems planning phase.
As you may recall, the purpose of the feasibility study in the systems planning phase was to assist the IT governance committee in determining which of the several different systems within the organization has the highest priority. For example, the IT governance committee might have been trying to determine whether revising the order entry system is more important than revising the invoice payment system. Assume that the IT governance committee decided that the invoice payment system is the higher priority. The end result of the system planning phase would be to announce this decision and to assign resources and a project team to begin the revision of the invoice payment system. Now we move forward through the other phases. In the conceptual design phase, the project team identified a traditional invoice-matching system and a Web-based invoice payment system as the alternative conceptual designs. At the point of evaluation within the design phase, the project team must now evaluate whether the matching or Web-based system better meets organizational needs, and select the optimal system.
Since the project team has a more narrow and defined scope, the estimates of the technology needed, the operational requirements, the economic aspect, and the schedule for implementation can be more precise than in the systems planning phase. The project team may now be able to attach quantifiable measurements to these feasibility assessments, such as dollars, weeks, or number of employees needed.
The project team should study each aspect of the feasibility assessment for each of the alternative conceptual designs. Examples of the type of assessments and analysis the project team would make are described in the following list:
The project team must summarize and analyze the results of these four feasibility tests for the purpose of selecting the single best design from the alternatives available. The task of summarizing and analyzing can become difficult because there may be conflicting signals across the four feasibilities. For example, a system may have high benefits when costs are compared (economic feasibility), but it may also require a longer time to implement (schedule feasibility). The team must then assess the trade-offs involved in higher cost–benefit, but longer implementation time. In most cases, the cost–benefit analysis is the most important of the four tests. However, any one of the four feasibilities can cause the team to drop an alternative design. For example, a design that meets all other feasibilities, but cannot be operated by the company's staff (operational feasibility) would not be selected.
At some point in the SDLC, managers might consider cloud computing as part of the conceptual model or approach to their IT system. You may recall from previous chapters that there are several approaches to cloud computing, including public clouds, private clouds, Software as a Service (SaaS), Database as a Service (DaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS). Regardless of the approach the company considers, the incorporation of cloud computing requires a careful, controlled approach to system design. This means the team conducting the SDLC must consider the risks, costs and benefits, and feasibility of the cloud computing approach. Cloud computing can entail greater security, availability, processing integrity, and confidentiality risks (as described in chapter 4), and these must be appropriately weighed against the benefits of scalability, expanded access, cost savings, and IT infrastructure changes.
In addition to the risks and benefits mentioned here, there are other considerations related to adopting or increasing cloud computing usage, such as the following:
Ideally, any intent to move toward cloud computing, or any increase in the use of cloud computing, should follow the steps within the SDLC. These steps were previously described in this chapter to include systems planning, systems analysis, and the remaining steps of the SDLC. The inclusion of a discussion about cloud computing in the conceptual design section of this chapter does not imply that it is the only phase within the SDLC to consider cloud computing.
The end result of the evaluation and selection phase of the SDLC is that the best alternative design is selected. Once the design has been selected, the details of that selection must be designed. The purpose of the detailed design phase is to create the entire set of specifications necessary to build and implement the system. The various parts of the system that must be designed are the outputs, inputs, processes, data storage, and internal controls. Each of these parts must be designed in enough detail that programmers and analysts can develop the program code necessary to build the software system. However, the actual writing of program code is not part of the design phase. The coding of software occurs in the implementation phase.
Outputs of the system are reports and documents, such as income statements, aged accounts receivable listings, inventory status reports, and sales by product. Other outputs are documents or turn-around documents. For example, checks printed by the accounts payable system and invoices printed by the billing system are outputs. Each output of the system being revised must be designed in detail. The form and format must be designed. The form may be a printed report or a report viewed on the screen. The format is the actual layout of the report or document. The details of the rows and columns of data and how they appear on the report must be crafted. Since users need these reports on an ongoing basis as part of their jobs, it is critical to have user feedback in designing the details of output reports. If output reports do not meet the needs of the intended users, they are not very useful.
The organization needs customized output reports even when software is purchased rather than designed in-house. Therefore, when software is purchased, it is often necessary for the customer company to design detailed formats of output reports.
Inputs are the forms, documents, screens, or electronic means used to put data into the accounting system. There are many ways that data can be input, ranging from the manual keying in of data on a keyboard to computerized input such as bar code scanning. The project team must design the input method to fit the system being revised. For example, if the evaluation and selection phase results in the selection of an EIPP system, then invoices will be received electronically and there is no matching of the related documents. Therefore, there is no reason to design a paper copy of a receiving report. Instead, the project team must design the systems that will receive, read, and convert the electronic invoice. There are so many different forms of input that it is not possible to describe here the details of all possible forms. The overriding concern, regardless of the form of input, is ensuring the efficiency and accuracy of input. That is, the inputs must be designed to work efficiently and with as few errors as possible. Samples of the different methods of data input are as follows:
In general, the manual input from item (1) is more error-prone and much slower than the other electronic methods of input. Regardless of the method, internal controls should be incorporated to reduce input errors. Input controls were described in the application control section of Chapter 4 and include electronic data validation controls such as validity checks, limit checks, and completeness checks.
In the case of purchased software, input screens are often modified to better suit the specific needs of the organization. Before the screens are modified, the project team should follow the process of detailed design of the input screens and solicit user involvement. Lack of user input can result in screens that are difficult to use, resulting in input errors.
All details of the processes of the system must also be designed. As you may recall from your study of processes, there are many different processes in an accounting system. Each one usually requires many detailed steps. For example, processing payroll checks requires many steps, including timekeeping, calculation of gross pay and deductions, approvals for the payroll, and printing and distribution of checks. In the detailed design phase, all of the individual steps within a process must be designed. The project team again should have user input in designing these processes. Without user input, the processes may be designed in a way that makes it difficult or undesirable for users to use the system. Any such difficulties or reluctance by users to use the system can lead to efficiency problems or errors in the process.
The internal controls within the system must be designed during the detailed design phase. Internal controls are much more effective when they are designed into the processes from the beginning. Adding internal controls after the system has been implemented is much more difficult. To understand why this is true, let's think about the global positioning systems (GPSs) that are now built into some cars. When those cars were designed, the electronics, dashboard space, and dashboard controls had to be designed simultaneously. If you buy a car without the GPS and decide to add it later, your add-on system is likely to be less effective than a built-in GPS. Likewise, internal controls that are initially designed into the system are more effective. Chapter 4 described the types of controls that should be a part of IT systems.
An IT system must also have the proper amount and type of data storage to accomplish the functions it was designed to do. The data storage method and size must match the design of the inputs, processes, and outputs. The project team must design the method, size, and format of the data storage. For example, if data are to be stored in a relational database, the team must design all the elements, including the tables, the rows and columns within the tables, and the relationships between the tables. Chapter 13 on databases includes details about the storage and use of data in a relational database.
When the project team has completed the detailed design of outputs, inputs, processes, internal controls, and data storage, the implementation phase can begin.