ELEMENTS OF THE SYSTEMS DESIGN PHASE OF THE SDLC (STUDY OBJECTIVE 5)

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.

THE PURCHASE OF SOFTWARE

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.

Exhibit 6-5 System Design Process Map for Purchased Software

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:

1. The price of the software or software modules
2. The match of system and user needs to the features of the software
3. The technical, operational, economic, and schedule feasibility
4. Technical support provided by the vendor
5. Reputation and reliability of the vendor
6. Usability and user friendliness of the software
7. Testimonials from other customers who use the software.

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.

IN-HOUSE DESIGN

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.

Hiring a Consultant

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.

Exhibit 6-6 System Design Process Map for In-House Design

CONCEPTUAL DESIGN

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.

EVALUATION AND SELECTION

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:

1. Technical feasibility
2. Operational feasibility
3. Economic feasibility
4. Schedule feasibility

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:

1. Technical feasibility. The project team will assess the technical feasibility of each alternative conceptual design. In general, designs that require more complex technology have a lower feasibility than designs with less complex technology. The project team may place a numeric score on the technical feasibility. For example, on a scale of 1 to 10, the invoice-matching system may be scored as a 10, because the lower technology requirements make it much easier and less risky to acquire and/or implement. The Web-based system may be scored as a 5, since the technology is more complex and thus more risky to acquire and implement.
2. Operational feasibility. The project team will assess the realism of the possibility of operating each of the alternative designs. During this process, the team must consider the number of employees, their capabilities and expertise, and any supporting systems necessary to operate each alternative design. The team attempts to determine whether existing staff and support systems are adequate to operate the systems. For example, with a given staff size, a highly computerized system such as a Web-based system may be more operationally feasible, because it would require fewer staff members to operate. However, the staff using the system probably needs more computer expertise. Also, to implement a Web-based system, there must be an adequate number of highly reliable vendors and a high degree of trust between the company and its vendors. This is true because any invoice presented will be paid, without matching supporting documents. In summary, all of the support staff and underlying supporting systems must be examined, with the intention of assessing how easily the company could operate each alternative system design. Again, the project team may assign numerical assessment on a scale to indicate the relative operational feasibility.
3. Economic feasibility. The project team must estimate the costs and benefits of each alternative design. The costs and benefits can be compared by a formal cost–benefit method such as net present value, internal rate of return, or payback period. The purpose of this analysis is to determine which of the alternative designs is most cost effective. The costs of the system designs might include hardware and software costs, training expenses, and increases in operating and supplies costs. These examples of systems-related costs do not represent a complete list. Benefits might include cost savings from reductions in staff, increased operating efficiency, and elimination of non-value-added steps. Cost savings should be compared with the cost of a system by a formal analysis that allows the organization to determine whether tangible benefits outweigh costs. When a company is revising systems, there are also intangible benefits that are difficult to estimate in dollars. For instance, an improved accounting system might result in better feedback to management and, therefore, improved decision making. However, it is very difficult to place a dollar value on improved decision making. Since it may not be possible to estimate the dollar amount of intangible benefits, they cannot be included in an analysis such as net present value. The project should not ignore the intangible benefits, however. The report of the project team should include a written description of the intangible benefits.
4. Schedule feasibility. For each alternative design, the project team must estimate the total amount of time that will be required to implement the revised system. The designs that take longer to implement are less feasible.

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.

CLOUD COMPUTING AS A CONCEPTUAL DESIGN

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:

1. The customer support provided by the cloud vendor. It is important to fully understand the level and reliability of support provided by a cloud vendor.
2. The service level agreement (SLA) with the cloud provider. This contract should clearly specify the vendor's responsibilities, including the billing terms, expectations about the amount of downtime allowable, and whether the vendor will correct downtime issues or compensate the client for downtime.
3. The manner of monitoring cloud service usage. Since cloud computing is often a pay for service model in which the client pays for the level of service used, it is important that the client is able to monitor usage and reconcile billing with the actual service usage. As a simple analogy, you probably carefully review your cell phone bill to make sure you were not charged for more services than you used. Likewise, cloud computing clients must be able to track their usage of the cloud services and reconcile their measure of services used to the billing provided by the cloud vendor.

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.

DETAILED DESIGN

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:

1. Keying in data with a keyboard from data on a paper form. The person operating the keyboard must enter data from a paper form into an input screen on the computer.
2. Magnetic ink character recognition (MICR) is used on checks and turnaround documents such as the portion of your credit card bill that you return. The computer system reads the magnetic ink to determine information such as account number.
3. Electronic data interchange (EDI), in which standard business documents are transmitted electronically.
4. Internet commerce, in which the customer enters customer and order data.
5. Bar code scanning, such as in the point-of-sale systems used by grocery and department stores.

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.