Systems Design, Implementation, and Operation

Dosen Pengampu:

Dra. Diah Hari Suryaningrum, [Link], Ak, CA, CMA.

KELAS A KELOMPOK 5 :

Rosidah 17013010041
Khoirun Nisa L.N 17013010058
Regita Permata Sari 17013010063
Amilia Riska 17013010068
Novia Putri A.W 17013010070

Berliana Safira 1701301

PROGRAM STUDI AKUNTANSI

FAKULTAS EKONOMI DAN BISNIS

UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN”

JAWA TIMUR

2019
Conceptual Systems Design

In conceptual design, the developer creates a general framework for implementing user
requirements and solving the problems identified in the analysis phase.

EVALUATE DESIGN ALTERNATIVES

The following standards should be used to evaluate design alternatives:

(1) how well it meets organizational and system objectives,

(2) how well it meets user needs,
(3) whether it is economically feasible, and
(4) how advantages weigh against disadvantages. The steering committee evaluates the
alternatives and selects the one that best meets the organization’s needs.

Table 22-1 summarizes design considerations and alternatives.

PREPARE DESIGN SPECIFICATIONS AND REPORTS

Once a design alternative is selected, conceptual design specifications are created for the fol-
lowing elements:

1. Output. Because the system is designed to meet user information needs, output
specifica- tions are prepared first. To evaluate store sales, SM must decide (a) how often
to produce a sales analysis report, (b) what the report should contain, (c) what it will look
like, and (d) whether it is a hard-copy or screen (or both) output.

2. Data storage. Data storage decisions include which data elements must be stored to
pro- duce the sales report, how they should be stored, and what type of file or database
to use.

3. Input. Input design considerations include which sales data to enter; sale location and

amount; and where, when, and how to collect the data.

4. Processing procedures and operations. Design considerations include how to process

the input and stored data to produce the sales report and in which sequence the
processes must be performed.
A conceptual systems design report summarizes conceptual design activities, guides phys-

Physical Systems Design

During physical design, the broad, user-oriented AIS requirements of conceptual design are
translated into detailed specifications that are used to code and test the computer programs.

Failing to take sufficient time on conceptual and physical design can cause problems. A rush to
implement an enterprise resource planning (ERP) package at [Link] caused early
design problems. The result was a mistake-laden Oracle implementation. The ERP pack- age
was out-of-sync with the accounting software, causing the order tracking system to go down for
a week. Ultimately, five years of earnings had to be restated, with revenue reduced by $12.9
million and increased losses of $10.3 million.

OUTPUT DESIGN

The objective of output design is to determine the nature, format, content, and timing of reports,
documents, and screen displays. Output usually fits into one of the following four categories:

1. Scheduled reports have a prespecified content and format and are prepared on a regular
basis. Examples include monthly performance reports, weekly sales analyses, and annual
financial statements.
 2. Special-purpose analysis reports have no prespecified content or format and are not
prepared on a regular schedule. They are prepared in response to a management request to
evaluate an issue, such as which of three new products would provide the highest profits.

3. Triggered exception reports have a prespecified content and format but are prepared only
in response to abnormal conditions. Excessive absenteeism, cost overruns, inventory
shortages, and situations requiring immediate corrective action trigger such reports.

4. Demand reports have a prespecified content and format but are prepared only on re-
quest. Both triggered exception reports and demand reports can be used effectively to
facilitate the management process.

FILE AND DATABASE DESIGN

Data in various company units should be stored in compatible formats to help avoid the prob-
lem AT&T faced: 23 business units, a jumble of incompatible systems and data formats, and an
inability to communicate and share data with other units. AT&T spent five years creating a
“single view” of each customer so customer data could be shared across business units.

INPUT DESIGN

Input design considerations include what types of data will be input and the optimal input
method. Considerations for input design are shown in Table 22-4.

FORM DESIGN

Although systems are moving away from paper documents and toward source data automation,
form design is still an important topic. Form design principles are summa-rized in Table 22-5.
COMPUTER SCREEN DESIGN

It is more efficient to enter data directly into the computer than onto paper for subsequent entry.
Computer input screens are most effective when these proce-dures are followed:

1. Organize the screen so data can be entered quickly, accurately, and completely. Minimize
data input by retrieving as much data as possible from the system.

2. Enter data in the same order as displayed on paper forms that capture the data.

3. Group logically related data together. Complete the screen from left to right and top to
bottom.

4. Design the screen so users can jump from one data entry location to another or use a single
key to go directly to screen locations.

5. Make it easy to correct mistakes. Clear and explicit error messages that are consis-tent
across all screens are essential. There should be a help feature to provide online assistance.

6. Restrict the data or the number of menu options on a screen to avoid clutter.
PROGRAM DESIGN

Program development, one of the most time-consuming SDLC activities, takes place in the eight
steps shown below. Step 1 is part of the systems analysis phase. Step 2 begins in concep-tual
systems design and may carry over to physical design. Most of steps 3 and 4 are done dur-ing
systems design and are completed during systems implementation. Steps 5 and 6 are begun in
systems design, but most of the work is done during systems implementation. Step 7 is done
during systems implementation and conversion. Step 8 is part of operation and maintenance.

1. Determine user needs.

Systems analysts consult with users and reach an agreement on user needs and
software requirements.

2. Create and document a development plan.

3. Write program instructions (computer code).

 Program preparation time may range from a few days to a few years, depending on
program complexity. Programming standards (rules for writing programs) contribute to
program consistency, making them easier to read and maintain. structured programming a
modular approach to program-ming in which each module per-forms a specific function
and is coordinated by a control module.

4. Test the program. Debugging  the process of discovering and eliminating program errors.

5. Document the program.

Documentation explains how programs work and is used to correct errors. Program
documentation includes flowcharts, data flow diagrams, E-R diagrams, data models,
record layouts, and narrative descriptions. These items are stored in a documentation
manual.
6. Train program users.
Program documentation is often used to train users.
7. Install the system.
All system components, including the programs and the hardware, are combined, and the
company begins to use the system.
8. Use and modify the system.
Factors that require existing programs to be revised, referred to as program
maintenance, include requests for new or revised reports; changes in input, file content,
or values such as tax rates; error detection; and conversion to new hardware.

PROCEDURES AND CONTROLS DESIGN

Everyone who interacts with a system needs procedures that answer the who, what, when,
where, why, and how questions related to IS activities. Procedures should cover input
preparation, transaction processing, error detection and correction, controls, reconciliation of
balances, database access, output preparation and distribution, and computer operator
instructions.
Procedures documentation and training may take the form of system manuals, user instruction
classes, training materials, or online help screens. Developers, users, or teams representing
both groups may write procedures. A physical systems design report summarizes what was
accomplished and serves as the basis for management’s decision whether or not to proceed to
the implementation phase.
Systems Implementation
Systems implementation is the process of installing hardware and software and getting the
AIS up and running. Implementation.

IMPLEMENTATION PLANNING AND SITE PREPARATION

An implementation plan consists of implementation tasks, expected completion dates, cost
estimates, and who is responsible for each task. The plan specifies when the project should be
complete and when the AIS is operational. The implementation team identifies factors that
decrease the likelihood of successful implementation, and the plan contains a strategy for
coping
with each factor.
AIS changes may require adjustments to a company’s existing organizational structure. New
departments may be created, existing ones may be eliminated or downsized, or the IS
department itself may change.
Site preparation is a lengthy process and should begin well in advance of the installation date. A
large computer may require extensive changes, such as additional electrical outlets, data
communications facilities, raised floors, humidity controls, special lighting, air conditioning, fire
protection, and an emergency power supply. Space is needed for equipment, storage, and
offices.
SELECTING AND TRAINING PERSONNEL

Employees are hired from outside the company or transferred internally, which often is the less
costly alternative because they already understand the firm’s business and operations.
Transferring employees who are displaced because of the new system could boost employee
loyalty and morale.

Employees must be trained on the hardware, software, and any new policies and
procedures. Training should be scheduled for just before systems testing and conversion. Many
training options are available, such as vendor training, self-study manuals, computer-assisted
instruction, videotape presentations, role-playing, case studies, and experimenting with the
system under the guidance of experienced users.

Boots the Chemists, a British pharmacy chain with over 1,000 stores, developed a novel
approach to training employees nervous about a forthcoming system. They were invited to a
party at a store where a new POS system had been installed. They were invited to try to harm
the system by pushing the wrong buttons or fouling up a transaction. Employees quickly found
they could not harm the system and that it was easy to use.
COMPLETE DOCUMENTATION

Three types of documentation must be prepared for new systems:

1. Development documentation describes the new AIS. It includes a system description;

copies of output, input, and file and database layouts; program flowcharts; test results; and
user acceptance forms.

2. Operations documentation includes operating schedules; files and databases accessed;

and equipment, security, and file-retention requirements.

3. User documentation teaches users how to operate the AIS. It includes a procedures
manual and training materials.

TESTING THE SYSTEM

Inadequate system testing was another reason for the Blue Cross and Blue Shield system
failure.

1. Walk-throughs are step-by-step reviews of procedures or program logic to find incorrect

logic, errors, omissions, or other problems. The development team and system users
attend walk-throughs early in system design. The focus is on the input, files, outputs,
and data flows of the organization. Subsequent walk-throughs, attended by
programmers, address logical and structural aspects of program code.
2. Processing test data, including all valid transactions and all possible error conditions, is
performed to determine whether a program operates as designed; that is, valid
transactions are handled properly and errors are detected and dealt with appropriately.
To evaluate test results, the correct system response for each test transaction must be
specified in advance.
3. Acceptance tests use copies of real transactions and files rather than hypothetical
ones. Users develop the acceptance criteria and make the final decision whether to
accept the AIS.

Systems Conversion

Conversion is changing from the old to the new AIS. Many elements must be converted:
hardware, software, data files, and procedures. The process is complete when the new AIS is a
routine, ongoing part of the system. Four conversion approaches are used:
  Direct conversion terminates the old AIS when the new one is introduced. For example,
SM could discontinue its old system on Saturday night and use its new AIS on Monday
morning. Direct conversion is appropriate when a new system is so different that
comparisons between the two are meaningless. The approach is inexpensive, but it
provides no backup AIS. Unless a system has been carefully developed and tested,
direct conversion carries a high risk of failure. Focus 22-3 discusses the problems at
Sunbeam, caused in part by attempting a direct conversion.
 Parallel conversion operates the old and new systems simultaneously for a period. For
example, SM could process transactions with both systems, compare the output,
reconcile the differences, correct problems, and discontinue the old system after the new
system proves itself. Parallel processing protects companies from errors, but it is costly
and stressful to process transactions twice. Because companies often experience
problems during conversion, parallel processing has gained widespread popularity.
 Phase-in conversion gradually replaces elements of the old AIS with the new one. For
example, SM could implement its inventory system, then disbursements, then sales
collection, and so forth, until the whole system is functional. Gradual changes allow data
processing resources to be acquired over time. The disadvantages are the cost of
creating the temporary interfaces between the old and the new AIS and the time
required to make the gradual changeover.
 Pilot conversion implements a system in one part of the organization, such as a branch
location. For example, SM could install its new POS system at one of its stores using a
direct, parallel, or phase-in approach. When problems with the system are resolved, the
new system could be implemented at the remaining locations. This localizes conversion
problems and allows training in a live environment.

Operation and Maintenance

The final SDLC step is to operate and maintain the new system. A postimplementation review is
conducted to determine whether the system meets its planned objectives. Important review
considerations are listed in Table 22-7. Problems uncovered during the review are brought to
management’s attention, and the necessary adjustments are made. Table 22-8 illustrates what
the postimplementation review report should contain. User acceptance of the report is the final
activity in the systems development process.