Five Phases of the Systems Development Life Cycle (SDLC)

CHAPTER 20- INTRODUCTION TO SYSTEMS DEVELOPMENT AND SYSTEMS ANALYSIS

1. Five Phases of the Systems Development Life Cycle (SDLC)

Systems analysis- tahap ketika seluruh informasi yang dibutuhkan untuk membeli,

mengembangkan atau memodifikasi sistem dikumpulkan. Karena terbatasnya sumber daya yang

dimiliki, permintaan pengembangan harus disaring dan diprioritaskan. Jika tujuannya adalah untuk

membuat sistem lebih baik, maka:

o (initial investigation)

sifat dan ruang lingkup proyek yang diajukan harus diidentifikasi

o (systems survey)

lakukan survey terhadap sistem yang ada saat ini untuk mengidentifikasi keunggulan dan

kelemahan sistem

o (feasibility study)

tentukan apakah proyek tersebut feasible

o (information needs and system requirements)

jika proyek feasible, identifikasi dan dokumentasikan seluruh informasi yang dibutuhkan

untuk memilih atau mengembangkan sistem yang baru

o (deliver system requirement)

Siapkan laporan system analysis dan laporkan kepada information system steering

committee

Conceptual design – menentukan bagaimana memenuhi keinginan users.

o (design alternatives)

pilih antara membeli software, develop-in-house, outsource

o (design specifications)

sistem seperti apa yang ingin dibuat dan bagaimana pengendalian atas sistem tersebut

o (conceptual design requirements)

permintaan desain secara konseptual dilaporkan pada information system steering

committee

Physical design

o mengartikan permintaan desain konseptual lebih spesifik seperti detail sandi dan uji

program komputer, pembuatan dokumen input dan output, pembuatan file dan databases,

pembuatan prosedur dan pengendalian atas sistem yang baru.

o (developed system)

Hasil physical design kemudian dilaporkan kepada information system steering committee

Implementation and conversion – penggabungan seluruh sistem dan aktivitas pembangunan

sistem

o perencanaan dibuat dan dilaksanakan (planning),

o hardware dan software diinstal dan diuji

o pegawai direkrut, detraining atau direlokasi

o prosedur diuji dan dimodifikasi

o standar dan pengendalian telah terbentuk dan dokumen sudah siap

o organisasi menggunakan sistem baru, membuat beberapa penyesuaian, dan melakukan

evaluasid an koreksi atas implementasi sistem baru.

o membuat laporan operational system dan melaporkannya kepada information system

steering committee

operations and maintenance – sistem bar uterus direview dan dimodifikasi. Jika terjadi

modifikasi besar-besaran atau perubahan sistem dalam tahap ini, maka proses akan kembali ke

tahap pertama

2. People involved in systems development and the role they played

Management - menekan pentingnya keterlibatan users dalam proses pembuatan sistem,

mendukung dan mendorong proyek pengembangan sistem, menyelaraskan sostem dengan

tujuan perusahaan, menetapkan tujuan pembangunan sistem, memilih dan melakukan penilaian

atas kinerja dari pimpinan system department, menetapkan kebijakan atas proyek yang terpilih,

dan berpartisipasi dalam kepuntusan penting terkait sistem tersebut. User management

menentukan informasi yang dibutuhkan, mendampingi analis dengan pertimbangan cost dan

benefit, menempatkan staf dalam proyek pengembangan tersebut, dan mengalokasikan dana

untuk proyek terkait.

Accountants and other users

o sebagai pengguna : menentukan informasi yang dibutuhkan

o sebagai anggota tim proyek atau anggota steering committee : membantu pengembangan

sistem

o jika diminta, akuntan dapat membantu membuat, menguji dan mengaudit kontrol yang

memastikan keakuratan dan kelengkapan pemrosesan data

information system steering committee – membuat perencanaan dan mengawasi information

system function, membuat kebijakan AIS, memastikan keterlibatan, arahan dan kontrol dari top-

management memfasilitasi koordinasi dan integrasi aktivitas dalam sistem.

Project development team – mengarahkan pengembangan, merencanakan proyek, mengawasi

untuk memastikan ketepatan waktu dan efektifitas biaya penyelesaian, memastikan

pertimbangan yang tepat dalam pemilihan personel, mengkomunikasikan status proyek ke top

management dan steering committee dan memfasilitasi penerimaan pengguna atas sistem baru.

System analyst and programmers

o system analysts: mempelajari sistem yang ada, mendesain sistem baru, mempersiapkan

detail yang dibutuhkan programmer, menjembatani gap antara manusia dan teknologi

dengan sering berinteraksi dengan pegawai terkait pengembangan sistem, dan memastikan

bahwa sistem yang baru dapat memenuhi kebutuhan users.

o computer programmer: membuat program berdasarkan detail yang diberikan sistem analyst

dan memodifikasi atau menjaga program yang masih ada.

External players – pelanggan, vendor, auditor eksternal, dan pemerintah.

3. The importance of system developments planning and planning techniques

Kenapa harus ada planning?

memudahkan untuk menyelaraskan tujuan pembuatan atau pembangunan sistem dengan

tujuan perusahaan secara keseluruhan

sistem lebih efisisen, subsistem saling terhubung, dan terdapat dasar untuk memilih aplikasi

baru dalam pengembangan sistem

perusahaan update dengan perubahan terbaru dalam IT

sistem menjadi less costly dan lebih mudah digunakan

manajemen siap untuk sumber daya yang dibutuhkan dan pegawai siap atas perubahan yang

terjadi.

Bentuk planning:

Project development plan – disiapkan oleh tim proyek; berisikan analisis cost/benefit,

permintaan developmental dan operasional (orang, dana, hardware, software), dan jadwal

aktivitas untuk membangun dan mengoperasikan sistem yang baru.

Master plan – dibuat oleh steering committee, menspesifikasikan apa saja yang terdapat dalam

sistem, cara pengembangan, siapa yang mengembangkan, bagaimana mendapatkan sumber

daya yang dibutuhkan, dan tujuan AIS tersebut.

Teknik Perencanaan:

Program Evaluation and Review Techniques (PERT)

seluruh aktivitas dan hubungan antara aktivitas sebulum dan sesudahnya harus diidentifikasi

untuk menggambarka PERT diagram yang menunjukan mana aktivitas yang memerlukan

pengeluaran sumber daya dan waktu yang paling banyak, penyelesaian dan awal mula suatu

proyek. Setelah waktu penyelesaian ditentukan, tentukan pula critical path (proses yang

memerlukan waktu pengerjaan paling lama).

Gantt charts

diagram batang yang terdiri dari aktivitas di bagian kiri dan satuan waktu pada bagian atas.

Diagram batang digambarkan sepanjang waktu pengerjaan (starting-ending). Diagram batang

diiisi sepanjang pengerjaan proyek berdasarkan tingkat penyelesaiannya. Keuntungannya :

diagram ini memperlihatkan keseluruhan progress aktivitas. Kelemahannya : diagram ini tidak

dapat menunjukan hubungan antar aktivitas

4. Various types of feasibility analysis and calculate economic feasibility

Kenapa harus nalisis feasibility? untuk menentukan menghentikan proyek, melanjutkan proyek tanpa

syarat apapun atau melanjutkan proyek jika suatu masalah telah terselesaikan. Makin lama proyek

berjalan makin sulit untuk dibatalkan, sehingga keputusan ini harus ditetapkan sedini mungkin.

Jenis feasibility analysis:

economic feasibility – berapa waktu, uang dan sumber daya yang dibutuhkan untuk

implementasi sitem (bandingkan biaya dengan payback period, NPV dan IRR)

technical feasibility – apakah sistem dapat dikembangkan dan diimplementasikan dengan

teknologi yang ada saat ini

legal feasibility – apakah sistem telah mengikuti aturan yang berlaku

scheduling feasibility – apakah sistem dapat dikembangkan dan diimplementasikan dalam waktu

yang telah ditetapkan

operational feasibility – apakah organisasi memiliki akses terhadap orang yang mendesain,

mengimplementasikan dan mengoperasikan sistem ini? apakah sistem ini akan digunakan?

5. Why systems changes behavioral reactions, form of resistance and how to minimize the problem

Mengapa terjadi?

Fear- muncul mdar ketidak tahuan, ketakutan kehilangan pekerjaan, kehilangan status,

kegagalan, teknologi, dan ketidakpastian

top management support- ketika kurang dukungan top mmanagemenmt ats perubahan yang

dilakukan, mereka akan memopertanyakan mengapa mereka harus menyetujui perubahan

tersebut

experience with prior change – ketika mereka pernah memiliki pengalam buruk pada perubahan

sebelumnya

communication-pegawai tidak mau mendukung perubahan kecuali ada penjelasan mengapa

perubahan tersebut terjadi

disruptive nature of change – permintaan informasi dan interview membuat mereka menggangu

dan menambah beban bagi pegwai sehingga menimbulkan kesan negatif

manner in which chang is occurred – alasn perubahan yang diterma top management bisa jadi

tidak dpt diterima oleh lower level

biases and emotions – jika sisi emosional terpengaruh

personal characteristic and background – semakin muda dan semakin berpendidikan lebih

mudah menerima perubahan

Bentuk penolakan:

aggression

perilaku yang merusak, melumpuhkan dan melemahkan sistem, seperti meningkatnya kesalahan

atau sabotase.

projection

menyalahkan sistem jika suatu hal berjalan tidak sesuai.

avoidance

mengacuhkan sistem yang baru dengan harapan sistem tersebut tidak akan digunakan lagi.

Bagaimanan mencegah hal tersebut terjadi?

dapatkan dukungan manajer, penuhi kebutuhan users, libatkan users dalam proses pembuatan,

menekankan keuntungan sistem baru, bersikap loggis, megadakan training, evaluasi kinerja sistem baru,

selalu membuka komunikasi dengan users, menguji sistem, dan humanize sistem.

CHAPTER 21 – AIS DEVELOPMENT STRATEGIES

Purchasing software

canned software-djual pada pengguna yang memiliki kesamaan kebutuhan, turnkey software-software

yang dijual sepaket dengan hardware nya. ASP merupakan pnyedia jasa penyewaan software mellaui

internet.

Tahap :

pemilihan vendor-bisa mellaui konferensi, internet, majalah, buku telepon, dll.

acquiring hardware-software – untuk pembelian yang banyak dan complex maka gunakan RFP

agar: menghemat waktu )tanpa harus interview berulang), menyederhanakan proses

pembuatan keputusan (semua respons berdasarkan format dan info yang sama), mengurangi

eror (tidak perlu overlook), dan mengurangi kemungkinan ketidakcocokan (masing2 pihak sudah

memiliki ekspektasi tertentu). Kekurangannya : vendor tidak dapat menyarankan alternatif lain,

masalah teknis yang menjadi urusan vendor sulit dianalisa dan mnambah biaya yang dikenakan.

evaluating proposal and select system – proposal yang menyediakan informasi yang kurang,

tidak memenui permintaan dasar dan ambigu akan ditolak. Jika lolos dalam paper screening,

proposal dicocokan dengan sistem requirement. vendor kemudian diminta untuk

mendemonstrasikan sisrem tersebut. Membandingkan vendor dengan menggunakan point

scoring-dimana tiap-tiap kriteria diberikan berat brebeda berdasarkan tingkat kepentingannya.

Setelah itu membandingkan biaya yang dibutuhkan (purchasing cost + requirement cost)..

Development in house

End user developed software

end user computing – pengembangan, penggunaan dan pengendalian sistem dilakukan oleh users

Keuntungan:

user creation, control and implementation-user mengendalika proses pengembangan

system that meet user needs

timeliness- menghemat waktu

freeing up of system resources – sumberdaya dapat digunakan untuk pengembangan sistem

lain

versatility and ease of use – mudah dipahami, dapat dimodifikasi, dan dpat digunakan

diamana saja

Kelemahan :

logic and development error- user yang mengembangkan sistem tidak memiliki pengetahuan IS

yang baik, sehingga seringkali mereka banyak melakukan eror atau tidak menyadari adanya eror

tersebut

inadequately tested application – jarang dilakukan tes yang menyeluruh karene tidak

mengetahui kegunaan tes tersebut

inefficien systems

poorly controlled and documented system:

system incompatibilities

wasted resources – ada duplikasi sistem

increased cost- update

Cara mengatasi kelemahan : help desk (menyelesaikan masalah, evaluasi hardware software baru,

melakukan training, menyediakan bantuan teknis dan pendampingan dalam pembuatan aplikasi

OUTSOURCING

Merupakan kegiatan merekrut perusahaan luar untuk menangani seluruh aktivitas pemrosesan data

organisasi.

Keuntungan:

a business solution –agar perusahaan lebih fokus pada bisnis utamanya

asset utilization – menjual aset pada outsourcer

access to greater expertise and better technology – diserahkan pada ahlinya

lower cost – mengurangi biaya labor, instalasi, dll

less development time – perusahaan outsourcer yang baik dapat mengerjakan pengembangan

lebih cepat

elimination of peaks and valley usage – mengurangi penggunanaan untuk mengurangi

operational cost

facilitation of downsizing – merampingkan struktur

Kelemahan :

inflexibility – kontrak berkisar 10 tahun, jika ada ketidak[uasan dari pelnggan sangat sulit proses

untuk pembatalan kontrak tersebut

loss of control –terutama kontrol atas system dan data

reduce competitive advantage – karena tidak mengetahui proses

locked in system – pengeluaran cukup besar, sehingga harus tetap menggunakan sistem yang

dibangun

unfulfilled goals – banyak tujuan yang tidak terpenuhi

poor service – outsourcer kurang responsive terdapat perubahan yang terjadi

increased risk – ope, fin, tech, strategy , personnel, legal dan regulatory risk

BUSINESS PROCESS MANAGEMENT

Business process reengineering (BPR) is the analysis and redesign of business processes and information

systems to achieve significant performance improvements. Karena dinilai kurang efektif maka proses ini

dikembangkan menjadi BPM dengan pengembangan yang m=berkelanjutan untuk mengoptimalkan

proses bisnis dalam organisasi. Prinsip penting di bawah BPM :

Proses bisnis dapat menciptakan competitive advantage

Proses bisnis harus dikoordinasikan dan dikomunikasikan dengan baik.

business proses harus dapat beradaptasi mennyesuaikan perubahan yang terjadi

bisnis proses harus selaras dengan tujuan dan kebutuhan perusahaan

empat komponen utama BPM :

proses untuk membuat dan menjalankan aplikasi, termasuk peraturan dalam bisnis

analisa bisnis untuk mengidentifikasi isu, tren dan kesempatan

integrasi seluruh aktivitas

menyetorkan dan mengamankan dokumen dan file penting lainnya

PROTOTYPING

Four steps are involved in developing a prototype:

1. STEP ONE: Identify basic requirements

The first step is to identify basic requirements by meeting with users to agree on the size and scope of

the system and decide what it should include and exclude. Developer and users also determine decision-

making and transaction processing outputs and inputs and data needed to produce those outputs. The

emphasis is on what outputs should be produced rather than how. The developer must ensure user

expectations are realistic and their basic information requirements are met. The designer uses the

information requirements to develop cost, time, and feasibility estimates for alternative AIS solutions

2. STEP TWO: Develop an initial prototype

The second step involves developing an initial prototype that meets the agreed-on requirements. The

emphasis is on speed and low cost rather than efficiency of operation. The goal is to implement the

prototype within a short time period. Because of time constraints, some aspects are sacrificed. For

example, at this point, there is ignorance of non-essential functions, system controls, exception

handling, validation of input data, processing speed, and efficiency considerations. Users must see and

use tentative versions of data entry display screens, menus, input prompts, and source documents. They

must also respond to prompts, query the system, judge response times, and issue commands. When the

prototype is finished, the developer returns to the users and demonstrates the system. Users are

instructed to experiment and comment on what they do and do not like.

3. STEP THREE: Repeated iterations

The third step involves repeated iterations of users identifying changes, developers making the changes,

and the system being turned back to users for next round. This step continues until users are satisfied—

usually 4 to 6 iterations.

4. STEP FOUR: Use the system

The final step involves using the system approved by the users. An approved prototype is typically used

in one of two ways. Half of the prototypes are turned into fully functional systems referred to as

operational prototypes. To make them operational, the developer must add needed controls, improve

operational efficiency, provide backup and recovery, and integrate the prototype with the systems with

which it interfaces. Changes may be necessary to allow the program to accept real input, access real

data files, process data, make necessary computations and calculations, and produce real output. When

it’s not practical to modify the prototype to make a fully functional system, non-operational or

throwaway prototypes can be used in several ways. They may be discarded, and the systems

requirements identified in the process of building them can be used to develop a new system. If so, the

SDLC is followed to develop the system, and the prototype is a model. Alternately, they may be used as

the initial prototype for an expanded system designed to meet needs of many users. As a final

alternative, if users and developers decide the system is unsalvageable, the prototype can be discarded

completely.

There are some advantages of prototyping :

1. Better definition of user needs -- Because of intensive end-user involvement

2. Higher user involvement and satisfaction

3. Faster development time -- It may take days or weeks to get a prototype up vs. a year or

more for a traditional system

4. Fewer errors -- Errors are detected early because the users experiment with each

version. It’s also easy to identify and terminate an infeasible AIS early

5. More opportunity for changes

6. Less costly -- Some for 10–20% of the cost of traditional systems

Despite its advantage, prototype also has several disadvantages :

1. Significant user time

2. Less efficient use of system resources -- Shortcuts in developing the system may result in poor

performance and reliability and high maintenance and support costs

3. Incomplete system development

4. Inadequately tested and documented systems

5. Negative behavioral reactions -- If the prototype is discarded, users may be upset about using it

and losing it. Users may also be dissatisfied if all their suggestions are not incorporated or if they

have to go through too many iterations

6. Never-ending development -- If not managed properly, the development could get stuck in a

terminal loop

CASE TOOLS

Computer-aided software (or systems) engineering (CASE) tools are an integrated package of computer-

based tools that automate important aspects of the software development process. It is used to plan,

analyze, design, program, and maintain an information system. It is also used to enhance efforts of

managers, users, and programmers in understanding information needs.

There are several advantages of CASE technology :

1. Increased productivity -- Can generate bug-free code from system specifications and automate

repetitive tasks

2. Improved program quality -- Can simplify enforcement of structured development standards,

which improves quality of development and reduces threat of serious design errors; can check

internal accuracy of design and detect inconsistencies

3. Cost savings -- Cost savings of up to 80–90% are possible

4. Improved control procedures -- Encourages development early in the design process of system

controls, security measures, system auditability, and error handling procedures

5. Simplified documentation -- Automatically documents as the system development progresses

Despite its advantage, CASE technology also has several disadvantages :

1. Incompatibility -- Some tools don’t interact effectively with some systems

2. Cost -- Some packages > $360,000

3. Unmet expectations -- Only 37% of CIOs believe they achieved expected benefits

CHAPTER 22 – SYSTEM DESIGN, IMPLEMENTATION AND OPERATION

Conceptual Systems Design

In the conceptual systems design phase, a general framework is created for implementing user

requirements and solving the problems identified in the analysis phase. The three main steps are :

1. Evaluate design alternatives

The steering committee evaluates the alternatives. Following are some design considerations and

alternatives:

How should the communications channel be configured? -- Point-to-point, Multi-drop, or

Line-sharing

What type of communications channel should be used? -- Phone lines, Coaxial cable, Fiber

optics, Microwave, or Satellite

What type of communications network should be used? – Centralized, Decentralized,

Distributed, or Local area

What type of storage media should be used for data? – Tape, Disk, Diskette, Hard drive, CD,

or Paper

What type of data storage structure should be used? – Files or Database

How should files be organized and accessed? – Random, Sequential, orIndexed-sequential

access

What media should be used to input data? – Keying, OCR, MICR, POS, EDI, or Voice

What format will the input take? -- Source documents, Turnaround documents, Source data

automation, or Screen

How will the system be operated? -- In-house or Outsourcing

How frequently will outputs be produced? – Instantly, Hourly, Daily, Weekly, or Monthly

What media will be used for output? – Paper, Screen, Voice, Diskette, CD, or Microfilm

How will output be scheduled? -- On demand or at predetermined times

What format will the output take? – Narrative, Table, Graph, Electronic file or

communication

What form will printed output take? -- Pre-printed forms, Turnaround documents, or

System-generated forms

What processing mode will be used? – Manual, Batch, orReal time

What type of processor will be utilized? -- Personal computer, Minicomputer, or Mainframe

How will software be acquired? – Canned, Custom, or Modified

How will transactions be processed? -- By batch or Online

How frequently will updates occur? – Instantly, Hourly, Daily, Weekly, or Monthly

2. Prepare design specifications

Once a design has been selected, the project team develops the conceptual design specifications for the

following elements:

Output -- Because output is what goes to the user and the system must be designed to meet

user needs, the output specifications are prepared first

Data storage -- How will data be stored to produce the desired outputs?

Input -- What types of data must be entered to produce the desired outputs?

Processing procedures and operations -- How will data be processed and in what sequence

to produce the desired outputs?

3. Prepare the conceptual systems design report.

A conceptual systems design report is prepared at the end of the conceptual design phase to guide

physical system design activities, communicate how management and user information needs will be

met, and help the steering committee assess system feasibility.

Physical System Design

1. Output Design

The objective of output design is to determine the nature, format, content, and timing of printed

reports, documents, and screen displays. Important design considerations include :

Use of the output -- Who will use it and why?, when is it needed?, and what decisions will it

facilitate?

Output medium – Paper, Screen, Voice response, Diskette, Microfilm, and Other

Output format -- Should select the format that clearly conveys the most information. It could be

table, narrative, or graphic.

Pre-printed -- Should paper output be on preprinted form and/or turnaround document?

Location -- Where is the output to be sent?

Access -- Who should be able to access hard-copy and screen output?

Detail -- Lengthy output should be preceded by an executive summary and a table of contents.

Headings and legends organize data and highlight important items. Detailed info goes in an

appendix.

Timeliness -- How often should the output be produced?

Outputs usually fit into one of the following four categories:

Scheduled reports -- have pre-specified content and format, are prepared on a regular basis, for

examples: weekly sales analysis and monthly financial statements

Special-purpose analysis reports -- no pre-specified content and format, typically prepared in

response to a management request, for example: analysis of impact of a government mandate

on profitability

Triggered exception reports -- have pre-specified content and format, prepared only in response

to abnormal conditions, i.e., the “trigger”, for example: cost overruns

Demand reports -- have pre-specified content and format and prepared only on request.

2. File and database design

Important file and database design considerations include:

Storage medium -- Hard drive, Disk, Diskette, CD, Tape, or Paper

Processing mode – Manual, batch or real time

Maintenance -- What procedures are needed to effectively maintain the data?

Size -- How many records and how big are they? and how fast are they expected to grow?

Activity level -- What portion of records are added or deleted each year? and what portion

needs to be updated?

3. Input design

There are two principal types of data input, forms and computer screens. Considerations in input design

include:

Input medium – Keyboard, OCR, MICR, POS terminal, EDI, and Voice input

Input source – Computer, Customer, and Remote location

Input format -- Source or turnaround document, screen, and source data

automation

Input type -- What is the nature of the data?

Volume -- How much data are to be entered?

Personnel -- What functions and expertise do the data entry operators have? and is

additional training necessary?

Frequency -- How often is data to be entered?

Cost -- How can costs be minimized without adversely affecting efficiency and

accuracy?

Error detection and correction -- What errors are possible? and how can they be

detected and corrected?

4. Form design

Following are important principles for designing new forms and evaluating existing ones:

• General considerations -- Preprint as much data as possible; use appropriate weight and grade

of paper; use bold type, double-thick lines, and shading to highlight different parts of the form;

use a standard size and one that is consistent with requirements for filing, binding, or mailing; if

mailed to external parties, position the address for placement in a window envelope; have

copies of the form printed in different colors to facilitate accurate distribution; and include clear

instructions for completing the form.

• Introductory section of form -- Place the form name at the top in bold type; have the forms pre-

numbered consecutively; and if distributed to external parties, have company name and address

pre-printed on the form.

• Main body of form -- Group together logically related information (e.g., info about the customer,

info about the product); provide sufficient room to record each item; order the data items

consistent with the sequence in which the data is likely to be gathered; use codes and check-offs

in places where standardized explanations are likely.

• Conclusion section of form -- Provide space for recording final disposition of the form, approval

signatures, dates of approval and final disposition, and a dollar or numeric total ; clearly indicate

the distribution of each form.

Computer screens are most effective when the following principles are used:

Organize the screen for quick, accurate, and complete entry of the data -- Minimize input by

retrieving as much as possible from the system. Example: If the customer number is entered,

retrieve his name/address data from the system.

Enter data in the same order it appears on the document

Complete the screen from left to right and top to bottom, grouping logically related data together

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

Make it easy to correct mistakes -- Use clear and explicit error messages that are consistent on all

screens and provide a help feature for online assistance

Avoid clutter by restricting the amount of data on one screen -- Limit the number of menu

options on a single screen

5. Program design

The following slides discuss the eight steps for developing software and where these steps take place in

the SDLC.

STEP ONE: Determine user needs -- Occurs during the systems analysis stage of the SDLC.

STEP TWO: Develop and document a plan -- Occurs during the conceptual design phase and

the beginning of physical design.

STEP THREE: Write the program code -- Design in increasing levels of detail, known as

hierarchical program design. It begun during systems design and completed during systems

implementation.

STEP FOUR: Test the program code -- Debugging is discovering and eliminating program

errors. Desk checking happens after a program is coded and involves a visual and mental

review to discover programming errors. Programs are tested for logic errors using test data

that simulates both valid transactions and all possible error conditions. Large programs are

often tested in three stages, such as individual program modules, the linkages between the

module and the control module, and the interfaces between the program being tested and

other application programs. Errors need to be found as soon as possible in the development

process. Errors discovered late cost 80–1000% more to fix than those found early.

STEP FIVE: Document the program -- Documentation explains how programs work and helps

correct and resolve errors. It includes flowcharts, record layouts, E-R diagrams, REA data

models, narrative descriptions of the system, etc., organized in a manual.

STEP SIX: Train program users -- Often uses the program documentation.

STEP SEVEN: Install the system -- All components are brought together, and the company

begins to use the system.

STEP EIGHT: Use and modify the system -- Program maintenance is a response to any factors

that require program revision. It includes requests for new or revised reports; changes in

input, file content, or values such as tax rates; error detection and correction; and

conversion to new hardware.

6. Procedure design

Individuals who interact with a newly-designed AIS need procedures to cover input preparation,

transaction processing, error detection and correction, controls, reconciliation of balances, database

access, output preparation and distribution, and computer operator instructions. Procedures may take

the form of system manuals, user instruction classes, training materials, and online help screen. The

procedures may be written by development teams; users; or teams representing both groups.

7. Controls design

Improperly controlled input, processing, and database functions produce information of questionable

value. Controls must be built into an AIS to ensure its effectiveness, efficiency, and accuracy. These

controls should minimize errors and detect and correct errors when they do occur. Accountants play a

vital role in this area. Important control concerns that must be addressed include:

Validity -- Are all interactions valid?

Authorization -- Are input, processing, storage, and output activities authorized by

the appropriate managers?

Accuracy -- Is input verified to ensure accuracy? and what controls ensure that data

is not lost when passing between processing activities?

Security -- Is the system protected against unauthorized physical and logical access

to prevent improper use, alteration, destruction, or disclosure of information and

software and theft of system resources?

Numerical control -- Are documents pre-numbered to prevent errors or intentional

misuse and to detect when documents are missing or stolen?

Availability -- Is the system available as set forth in agreements? and can users

enter, update, and retrieve data during those times?

Maintainability -- Can the system be modified without affecting system availability,

security, and integrity?; Are only authorized, tested, and documented changes made

to the system and data?; Are resources available to manage, schedule, document,

and communicate changes to management and authorized users?

Integrity -- Is processing complete, accurate, timely, and authorized?; Is it free from

unauthorized or inadvertent manipulations?

Audit trail -- Can data be traced from source to output and vice versa?

8. Physical system design report

At the end of the physical design phase, a physical systems design report is prepared, summarizing what

was accomplished. This report serves as the basis for management’s decision whether to proceed to

implementation.

Systems Implementation and Conversion

Systems implementation is the process of installing hardware and software and getting the AIS up and

running. Phases include

1. Developing a plan

An implementation plan consists of implementation tasks, expected completion dates, cost estimates

and specification of the person(s) responsible for each task. The plan specifies when the project should

be complete and operational. The implementation team should identify risk factors that decrease the

likelihood of successful implementation, and the plan should contain a strategy for coping with each of

the risks. AIS changes may require adjustments to the company’s organizational structure, including

creation of new departments; elimination or downsizing of existing departments; and changes even in

the data processing department.

2. Preparing the site : Installing and testing hardware and software

A large computer may require changes such as new electrical outlets; data communications facilities;

raised floors; humidity controls; special lighting; air-conditioning; security measures, such as fire

protection and emergency power supply; space for equipment, storage, and offices. Site preparation is a

lengthy process and should begin well ahead of the installation date.

3. Selecting and training personnel

Employees can be hired from outside or transferred internally. Hiring from within is usually more

effective and less costly, because the employees already understand the business. Transferring displaced

employees can enhance loyalty and morale. Companies take training shortcuts because effective

training is time-consuming and expensive and those who understand the system are maintaining and

upgrading it. When training is insufficient, the company will not achieve the expected return on

investment. The hidden cost is that users will turn to their coworkers who have mastered the system for

help. It results in less productive coworkers and increased costs. Effective training includes hardware

and software skills and orientation to new policies and operations. The training should be scheduled just

before systems testing and conversion. Types of training include technical training from vendors, self-

study manuals, computer-aided instruction, videotape presentations, role-playing, case studies, and

experimenting with the AIS under the guidance of experienced users.

4. Completing documentation

Three types of documentation must be prepared for new systems:

Development documentation -- Describes the AIS and includes a system description;

copies of output, input, file, and database layouts; program flowcharts; test results;

and user acceptance forms.

Operations documentation – Includes operating schedules; files and databases

accessed; and equipment, security, and file retention requirements

User documentation -- Teaches users how to operate the AIS. and includes a

procedures manual and training materials.

5. Testing the system

Inadequate system testing has contributed to the failure of systems. Three common forms of testing

include:

Walk-throughs -- Step-by-step reviews of procedures or program logic : Attended by

the development team and users early in system design; focus is on organization

input, files, outputs, and data flows; subsequent walk-throughs are attended by

programmers; and address logical and structural aspects of program code.

Processing test transactions -- Determines whether the program operates as

designed; requires both valid and erroneous data; the correct response for each test

should be specified in advance.

Acceptance tests -- Uses copies of real transactions and files rather than

hypothetical ones; users develop acceptance criteria; and then make final decision

whether to accept.

Conversion is the process of changing from the old AIS to the new. Many elements must be converted,

including hardware, software, data files, and procedures. The process is complete when the new AIS has

become a routine, ongoing part of the system. Four conversion approaches are used to change from an

old to a new system:

1. Direct conversion

Immediately terminates the old AIS when the new one is introduced. Appropriate when the old AIS has

no value; or the new AIS is so different that comparisons between the two are meaningless. Main

advantage to direct conversion is inexpensive, but the main disadvantage is it provides no backup AIS.

There is a high risk of failure unless the new system has been very carefully developed and tested.

2. Parallel conversion

Operates the old and new systems simultaneously for a period of time. You can process transactions

with both systems, compare output, reconcile differences, and make corrections to the new AIS. Main

advantage to parallel conversion is it protects the company from errors but the main disadvantage is it is

costly and stressful for employees to process all transactions twice. Because companies often

experience problems during conversion, parallel processing has gained widespread popularity.

3. Phase-in conversion

Gradually replaces elements of the old AIS with the new one. The new system is often phased in a

module at a time. The main advantage is data processing resources can be acquired over time, but the

disadvantages are costs of creating temporary interfaces between old and new AIS and time required to

make the complete conversion.

4. Pilot conversion

Implements a system in just one part of the organization, e.g., a branch office or a single store. When

problems with the system are resolved, the new system could be implemented at the remaining

locations. The advantages of this conversion is it localizes conversion problems and allows training in a

live environment. But the disadvantages are long conversion time and need for interfaces between old

and new systems.

Data conversion can be time-consuming, tedious, and expense. The difficulty and magnitude is easy to

underestimate. Data files may need to be modified in three ways, there are files may be moved to a

different storage medium (e.g., tape to disk), data content may be changed (e.g., fields added or

deleted), and a file or database format may be changed. Steps in the data conversion process:

1. Decide which data files need to be converted.

2. Check files for completeness and data inaccuracies, and remove any

inconsistencies.

3. Do the actual data conversion.