Chapter 3

System Development Process

&
Documentation Techniques

1
Learning Objectives:
 Prepare system development and
documentation tools and techniques.
 Explain the five phases of the systems
development life cycle(SDLC).
 Describe the strategies of developing AIS.
 Apply the techniques of Improving system
development process.

2
1
3.1. System Development & Documentation Tools & Techniques
 Accountants use many different types of diagrams to
depict the flow of accounting data through the AIS.
 Flow of data- data entry, processing , storage, information
output, system control, etc.
 Documentation includes the following types of tools:
Narratives (Writte descriptions), Flow charts,
Tables, Diagrams& Other written materials
 Both DFDs and Flowcharts are easy to prepare and revise
when one of the recently developed DFDs or Flowcharting
Software packages is used.

3
2
3.1. System Development & Documentation Tools & Techniques
Functions:
1. Depicting how the system works: Studying and reviewing written
descriptions of the inputs, processing steps, and outputs of the system make
the job easier.
2. Training users: Documentation also includes the user guides, procedure
manuals, and other operating instructions that help people learn how the AIS
operate.
3. Designing new systems: Documentation helps system designers develop
new systems in much the same way that blueprints help architects design
buildings.
4. Auditing AISs: Documentation helps auditors determine the strengths and
weaknesses of a systems controls.
5. Documenting business processes: By mapping the business processes,
documentation helps managers better understand the ways in which their
businesses operate.

4
3
3.1. System Development & Documentation Tools & Techniques. (Cont’d…)

Functions:
5. Standardizing communications with others: Documentation
techniques such as flowcharts and data flow diagrams are standard industry
tools, and they are more likely to be interpreted the same way by all
parties viewing them.
6. Controlling system development and maintenance costs: Good
documentation helps system designers develop object-oriented SW, that is,
programs that contain modular, reusable code. This object-orientation
helps programmers avoid writing duplicate programs and facilities changes
when programs must be modified later.
7. Accountability: It is used to establish accountability.
8. etc.
5
4
 3.1. System Development & Documentation Tools & Techniques
Tool 1: Data Flow Diagrams (DFDs)
 It graphically describes the flow of data within an organization
(i.e. where data comes from and where it goes, how it flows, the
processes performed on it, and how data are stored.)
 It is used to document existing systems and plan and design
new ones.
 Elements in a Data Flow Diagram
 A DFD is composed of four basic elements each represented in a
DFD by a unique symbol.
i. Data sources and destinations
ii. Data flows
iii. Transformation processes, and
iv. Data stores

6
5
3.1. System Development & Documentation Tools & Techniques

7
6
3.1. System Development & Documentation Tools & Techniques

8
7
3.1. System Development & Documentation Tools & Techniques
 Types of DFDs
1. Physical DFD ( Data Flow Diagram)
 It documents the physical structure of an existing system.
 It answers questions such as where an entity works, how an
entity works, the work is done by whom, etc.
 It has no lower levels.
 It focuses on physical entities as well as the tangible documents,
reports, and similar hard-copy inputs and outputs that flow
through the system.
 It lists the job title of one typical employee and it is simple, more
readable, and therefore more easily understood.

9
8
3.1. System Development & Documentation Tools & Techniques
2. Logical DFD (Data Flow Diagram):
 It documents the processes(tasks) in an existing
or proposed system.
 It focuses on the logical flow of data. Because the
logic of a system changes infrequently, relative to
its physical nature, a logical DFD will remain
relatively constant over time.
 It usually drawn in levels that include increasing
amounts of detail.
 It typically has levels below the level-0 diagram.
10
9
 3.1. System Development & Documentation Tools & Techniques
Tool 1: Data Flow Diagrams (DFDs)
 There is no ideal way to develop a DFD, because different
problems call for different methods.
 Some general guidelines for developing DFDs are:
1. Understand the system- involves observing the flow of information
through an organization and interviewing the individuals who use and
process the data.
2. Ignore certain aspects of the system- as DFD diagrams the origin,
flow, transformation, storage and destinations of data, all control actions
and processes should be ignored.
3. Determine system boundaries- is determining what to include in and
exclude from the system. All relevant data elements shall be included in
the DFD because excluded items will not be considered during systems
development. When in doubt about an element's importance, include it
until a definitive decision can be made to discard it.
11
10
3.1. System Development & Documentation Tools & Techniques
4. Develop a context diagram- a context diagram is a good way of
depicting system boundaries. In the diagram's center is a circle; inside of
it is displayed the system of concern. The outside entities, with which the
system interacts directly, are in boxes on either side, connected by data
flows depicting the data passed between them. DFDs are prepared, in
successively more detail, to depict data flows in the system.
5. Identify data flows- all data flows shall be identified entering or
leaving the system's boundary, including where the data originate and the
final destination. Any significant movement of information is usually a
data flow. All data flows come from and go to either a transformation
process, a data store (file), or a data source or destination. As each of this
is identified, it should be connected to the appropriate data flow. Data
flows can move in two directions, shown as a line with arrows on both
ends.

12
11
3.1. System Development & Documentation Tools & Techniques
6. Group data flows- a data flow consists of one or more pieces of datum.
Data elements that always flow together should be grouped together and
shown as one data flow until they are separated. If the data elements do
not always flow together, then they should be shown as two separate data
flows.
7. Identify transformation processes- this is by placing a circle
wherever work is required to transform one data flow into another. All
transformation processes should have one or more incoming or outgoing
data flows.
8. Group transformation processes- transformation processes that are
logically related or occur at the same time and place should be grouped
together. Unrelated items shall never be combined into a single
transformation process. If data are not processed together, or are
sometimes processed differently, then, they shall be separate.

13
12
3.1. System Development & Documentation Tools & Techniques
9. Identify all files or data stores- data are stored temporarily or
permanently in most systems. Each data repository, and each data flow into and
out of it, should be identified.
10. Identify all data sources and destinations- all sources and destinations of
data should be identified and included on the DFD.
11. Name all DFD elements- except for data flows into or out of data stores
(data store is sufficient to identify the data flow), data elements should be given
unique and descriptive names representing what is known about them. This
makes DFD easier to read and understand as it provides the reader with key
information. Naming data flows first forces the developer to concentrate on the
all-important data flows, rather than on the processes or stores. Once data
flows have been labeled, naming the process and data stores is usually easy,
because they typically take their names from the data inflows or outflows.
Choosing active and descriptive names such as daily inventory update and
validate transaction, rather than input data or update process. Process names
should include action verbs such as update, edit, prepare, and record.

14
13
3.1. System Development & Documentation Tools & Techniques
12. Subdivide the DFD- a cluttered DFD is hard to read and
understand. If there are more than five to seven processes on a single
page, then, higher level and lower level DFDs shall be used. The
context diagram shall be decomposed into high level processes, and
then exploded into successively lower level processes.
13. Give each process a sequential number- in completed DFD, each
process is given a sequential number that helps readers move back and
forth between different DFD levels. Data flows should only go from
lower numbered to higher numbered processes.
14. Repeat the process- DFD developers must work through
organization data flows several times. Each subsequent pass helps refine
the diagram and identify the fine points. When refining, the DFD shall
be organized to flow from top to bottom and from left to right.
15. Prepare a final copy- the final copy of the DFD shall be drawn. Data
flow lines shall be allowed to cross over each other, if necessary, a data
store or destination may be repeated. The name of the DFD, the data
prepared, and the preparer shall be placed

15
14
3.1. System Development & Documentation Tools & Techniques
Tool 2: Flowcharts
 It is a standard set of symbols (analytical technique) pictorially
describes transaction processing procedures (information
system) in a clear, concise, and logical manner.
 They are classified in to three: Document Flow chart, System Flow
chart and Program Flowcharts.
 Flowchart Symbols:
• There are various types of symbols used to create flowcharts.
• Each symbol has a special meaning that is easily conveyed by its
shape.
• The shape indicates and describes the operation performed and the
input, processing, output, and storage media employed.
• The symbols are drawn by a software program or with a
flowcharting template.

16
15
3.1. System Development & Documentation Tools & Techniques
Tool 2: Flowcharts
 Flowcharting symbols can be divided into the following four
categories:
a. Input/output symbols- represent devices or media that provide
input to or record output from processing operations.
b. Processing symbols- either show what type of device is used to
process data or indicate when processing is completed manually.
c. Storage symbols- represent the device used to store data that the
system is not currently using.
d. Flow and miscellaneous symbols- indicate the flow of data and
goods. They also represent such operations as where flowcharts begin
and end, where decisions are made, and when to add explanatory notes
to flowcharts.
17
16
18
17
19
18
20
19
21
20
3.1. System Development & Documentation Tools & Techniques
1. Document Flowchart
 It is a graphical description of the physical flow of documents and
information through an organization (i.e. between departments or
areas of responsibility within an organization.)
 It shows where a document originates, its distribution, the purpose for
which it is used, its ultimate disposition, and everything that happens
as it flows through the system. (i.e. cradle to its grave)
 It is particularly useful in analyzing the adequacy of control procedures
in a system, such as internal checks and segregation of duties.
 If it describes and evaluates internal controls , it is often called to as
internal control flowcharts.
 It can reveal weaknesses or inefficiencies in a system such as inadequate
communication flows, unnecessary complexity in document flows, or
procedures responsible for causing wasteful delays.
 It also can be prepared as part of the system design process and should be
included in the documentation of an information system.

22
21
23
22
3.1. System Development & Documentation Tools & Techniques
2. System Flowcharts:
 It is a graphical description of the relationship among the
input, processing, and output in an information system.
 It shows the electronic flow of data and processing steps in
AIS.
 It is an important systems analysis, design, and evaluation tool.
 It is universally employed in systems work and provide an
immediate form of communication among workers.
 It is an excellent vehicle for describing information flows
and procedures within AIS.

24
23
3.1. System Development & Documentation Tools & Techniques
3. Program Flowcharts:
 It is a graphical description of the sequence of logical operations that a
computer performs as it executes a program.
 Once designed and approved, the program flowchart serves as the
blueprint for coding the computer program.
a. Flow line -connects the symbols and indicates the sequence of
operations.
b. Processing symbol- represents a data movement or arithmetic
calculation.
c. Input/output symbol- represents either reading of input or writing
of output.
d. Decision symbol - represents a comparison of one or more variables
and the transfer of flow to alternative logic paths.
e. Terminal symbol - represents all points where the flow begins or
ends.

25
24
 System Flow Chart vs. Program Flow chart

26
25
3.1. System Development & Documentation Tools & Techniques
General guidelines for preparing flowcharts:
1. Understand a system before flowcharting it- by interviewing users,
developers, auditors, and management or having them complete a
questionnaire as well as by reading through a narrative description of the
system, or walking through system transactions.
2. Identify the entities to be flowcharted - such s departments, job
functions, or external parties as well as identifying documents and
information flows in the system and the activities or processes performed
on the data, for instance drawing a box around the entities, a circle around
the documents and a line around the activities.
3. Divide the flowchart into columns - when several entities such as
departments and functions need to be shown on the flowchart with a label
for each followed by flowcharting the activities of each entity in its
respective columns.
27
26
3.1. System Development & Documentation Tools & Techniques
4. Flowchart only the normal flow of operations -
ensuring that all procedures and processes are in proper order
and identifying exception procedures by using an annotation
symbol.
5. Design the flowchart - so that flow proceeds from top to
bottom and from left to right.
6. Give the flowchart a clear beginning and ending - by
designing where the document originated and showing the
final disposition of all documents so there are no loose ends
that leave the reader dangling.
7. Use the standard flowcharting symbols- and drawing
28
them with a template or a computer
27
3.1. System Development & Documentation Tools & Techniques
8. Clear labeling all symbols - by writing a description of the
input, process, or output inside the symbol. If description may
not fit, annotation symbol shall be used.
9. Place document numbers in the top right hand
corner of the symbol when using multiple copies of a
document. The document numbers should accompany the
symbols as it moves through the system.
10.Have an input and output for each manual
processing symbol- Two documents shall not be connected
directly except when moving from one column to another
column

29
28
3.1. System Development & Documentation Tools & Techniques
11. Use on page connectors to avoid excess flow lines - which
results in a neat looking page as well as using off-page connectors to
move from one flowchart page to another. All connectors shall be clearly
labeled to avoid confusion.
12. Use arrow heads on all flow lines - and not assuming that the
reader will know the direction of the flow.
13. Clearly label the pages - 1 of 3, 2 of 3 etc if a flowchart can not fit
into a single page.
14. Show documents or reports first in the column - in
which they are created and then moving to another column
for further processing. A manual process is not needed to
show documents being flowcharted.

30
29
3.1. System Development & Documentation Tools & Technique
15. Show all data entered into or retrieved from a computer file- as
passing through a processing operation (a computer program) first.
16. Draw a line from the document to a file to indicate that it is
being filed - A manual process is not needed to show a document
entering a file.
17. Draw rough sketch of the flowchart as a first effort. Concern shall
be with capturing content than perfect drawing. Few systems can be
flowcharted in a single draft.
18. Redesign the flowchart to avoid clutter and a large number of
crossed lines.
19. Verify the flowchart's accuracy - by reviewing it with the people
familiar with the system. It shall be assured that all uses of flowchart
conventions are consistent.
20. Draw the final copy of the flowchart - placing the name of the
flowchart, the date, and the preparer's name on each page.
31
30
3.2. Systems Development
 It refers to overhauling the existing system or creating a new AIS.
 It is needed since the business environment is competitive and ever changing so as to
get new, faster, and more reliable ways of obtaining information.
 Reasons for change:
1. Technological change- as technology advances and becomes less costly.
2. Changes in user or business needs- increased competition, business growth or
consolidation, merger ,etc.
3. Competitive advantage- Increased quality, quantity & speed of information for
improved product or service.
4. Productivity gains- automating clerical & repetitive tasks decreases the performance
time of other tasks.
5. Growth- companies outgrow their systems and must either upgrade or replace them
entirely.
6. Improved business processes- many companies have inefficient business processes
that require updating.
7. Downsizing- to move from centralized mainframes to networked PCs or to
Internet-based systems to take advantage of their price/performance ratios.

32
31
3.2.1. The key Players in System Development Process
1. Management - providing support and encouragement, establishing
system goals and objectives & determine information requirements.
2. Accountants - determine their information needs, may be members
of the project development team, play an active role in designing system
controls.
3. Information systems steering committee - set policies that
govern the AIS, ensures top-management participation, guidance and
control, facilitates coordination and integration of IS activities
4. Project development team - plan each project, monitor project,
make sure proper consideration is given to the human element.
5. Systems analysts and programmers - study existing systems,
design new systems and prepare specifications & write computer
programs
6. External players -Customers, Vendors, Government, etc.

33
32
3.2.2. The Systems Development Life Cycle (SDLC)
 It is sometimes called Systems Development Methodology.
 It is a conceptual model used in Project Management that describes the stages
involved in an information system development project, from an initial
feasibility study through maintenance of the completed application.
 It is a logical process by which systems analysts, software engineers, programmers
and end-users build information systems and computer applications to solve
business problems and needs.
 Various SDLC methodologies are :
1. Waterfall model (which was the original SDLC method);
2. Rapid application development (RAD);
3. Joint application development (JAD);
4. Fountain model;
5. Spiral model;
6. Build and fix; and
7. Synchronize-and-stabilize
 Frequently, several models are combined into some sort of hybrid methodology.

34
33
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)
In general, an SDLC methodology follows the following steps:
1. Evaluating the existing system- deficiencies are identified. This can be done by
interviewing users of the system and consulting with support personnel.
2. Defining the new system requirements - in particular, the deficiencies in the
existing system must be addressed with specific proposals for improvement.
3. Designing the proposed System - plans are laid out concerning the physical
construction, hardware, operating systems, programming, communications, and security
issues.
4. Developing the new system - the new components and programs must be obtained
and installed. Users of the system must be trained in its use, and all aspects of
performance must be tested. If necessary, adjustments must be made at this stage.
5. Implementing the new system- this can be done in various ways. The new system
can phased in, according to application or location, and the old system gradually
replaced. In some cases, it may be more cost-effective to shut down the old system and
implement the new system all at once.
6. Evaluating the new system - Once the new system is up and running for a while, it
should be exhaustively evaluated. Maintenance must be kept up rigorously at all times.
Users of the system should be kept up-to-date concerning the latest modifications and
procedures.

35
34
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)

Romney and Steinbart identified the following

five as the components of SDLC.
1. Systems analysis
2. Conceptual design
3. Physical design
4. Implementation and conversion
5. Operations and maintenance

36
35
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d...)

37
36
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)
 Stage 1: Systems Analysis:
 It is the first step in SDLC where in-depth understanding about a system starts.
 At this stage, the information needed to purchase or develop a new system is gathered.
 Since analysis is too costly (in terms of time, effort, money, etc), it is mostly started after
the project is approved and green light is obtained from the management.
 When a new or improved system is needed, a written request for systems development
is prepared. The request describes the current system’s problems, why the change is
needed, and the proposed system’s goals and objectives. It also describes the anticipated
benefits and costs.
 It is the stage of:
1.studying the current business system
2.understanding how the existing system works
3.determining the weakness and strength of the existing system
4.defining the business needs and requirements (user requirement determination and system
requirement determination independent of technology issues), etc
 System analysis report – prepared by the team which becomes the basis for management’s
decision whether to proceed to the conceptual system design.

38
37
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)
 Stage 2: Conceptual System design:
 It is the evaluation of alternative solutions and the
specification and construction of a detailed computer based
solution.
 It involves the development of a general framework for
implementing user requirements and solving problems identified in
the analysis phase.
 The three steps in conceptual design?
1. Evaluate design alternatives.
2. Prepare design specifications.
3. Prepare conceptual systems design report.

39
38
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)
 Stage 2: Conceptual System design ( Cont’d)
Step 1: Evaluate design alternatives - the criteria include:
 How well it meets organizational and system objectives
 How well it meets users’ needs
 Whether it is economically feasible
 Its advantages and disadvantages
 Prepare design specifications.
 Prepare conceptual systems design report.

Step 2: Prepare design specifications - the team develops the conceptual design
specifications for the following elements such as Output, Data storage, Input,
Processing procedures and operations
Step 3: Prepare conceptual systems design report: At the end of the conceptual
design, a conceptual systems design report is developed and submitted so as to:
 Guide physical systems design activities
 Communicate how management and user information needs will be met
 Help assess systems’ feasibility

40
39
3.2.2.The Systems Development Life Cycle (SDLC)( Cont’d..)
 Stage 3: Physical System Design
1. Output Design – its objective is to determine the characteristics of reports, documents,
and screen displays. Output fits into one of four categories: Scheduled reports, Special-
purpose analysis,Triggered exception reports, Demand reports
2. File and Database Design- Some file and database design considerations: medium of
storage, organization and access, processing mode, maintenance, size and activity level
3. Input Design - the design team must identify the different types of data input and
optimal input method. The two principal types of data input are Forms and Computer
Screens
4. Procedures Design- it should answer who, what, where, and how questions related to
all AIS activities. It covers input preparation, transaction processing, error detection and
corrections, controls, reconciliation of balances, database access, output preparation and
distribution, computer operator instructions.
5. Control Design- Some control design considerations are Validity, Authorization,
Accuracy, Security, Numerical Control, Availability, Maintainability, Integrity, Audit
Control
 Physical system design report – is prepared by the team which becomes the basis for
management’s decision whether to proceed to the implementation phase.

41
40
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d..)
Stage 4: Implementation and Conversion:
 System Implementation - is the process of installing hardware and software and
getting the AIS up and running.
 Implementation Progress report – is prepared by the team which becomes the
basis for management’s decision whether to proceed to the operation phase.

42
41
 3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d…)
 Stage 4: Implementation and Conversion: (Cont’d…)
1. Implementation Planning - An implementation plan consists of implementation tasks,
expected completion dates, cost estimates, and the person or persons responsible for each
task.
2. Develop and test software programs - Seven steps are followed when developing and
testing software programs- Determine user needs, Develop a plan, Write program
instructions (code), Test the program, Document the program, Train program users, Install and
use the system.
3. Site Preparation - a large system may require extensive changes, such as additional
electrical outlets. Site preparation should begin well in advance of the installation date.
4. Select and train personnel - Effective AIS training should include employees’ orientation
to new policies and operations. Training should occur before systems testing and conversion.
5. Complete documentation - three types of documentation must be prepared for new
systems: Development documentation, Operations documentation, User documentation
6. Test the System - three common forms of testing are Walk-through, Processing of test
transactions and Acceptance tests
7. Data Conversion: Data files may need to be modified in three ways:
 Files may be moved to a different storage
 Data content may be changed
 File format may be changed
43
42
3.2.2. The Systems Development Life Cycle (SDLC)( Cont’d…)
 Four conversion approaches :
 Approach 1: Direct conversion

 Approach2: Parallel conversion

 Approach 3: Phase-in conversion

 Approach 4: Pilot conversion

44
43
3.2.2.The Systems Development Life Cycle (SDLC)( Cont’d..)
Stage 5: Operations and Maintenance:
 Some factors to consider during the post implementation
include : Goals and objectives, Satisfaction, Benefits, Costs,
Reliability, Documentation Timeliness, Controls and
security, Errors , Training, Communications, Organizational
changes, Accuracy, Compatibility, etc.
Post implementation review report – is prepared by the
team which becomes the basis for management’s decision to
evaluate its performance.

45
44
3.2.3. Ongoing Activities over System Development Life Cycle

1.System Development Planning

 The importance of Systems Development Planning are : Consistency, efficiency,
cutting edge, lower costs, adaptability.
 The types of systems development plans needed are:
a) Project Plan- portions of the entire projects.
b) Master Plan- for the entire project.
 The two techniques/approaches for scheduling and monitoring systems
development activities are:
Approach 1: PERT (Program Evaluation and Review Technique):
 It requires that all activities and the preceding and subsequent relationships among
them be identified.

46
45
3.2.3. Ongoing Activities over System Development Life Cycle
Approach 2: Gantt chart: A bar chart with project activities listed on the left-
hand side and units of time across the top.

47
46
 3.2.3. Ongoing Activities over System Development Life Cycle
2. Feasibility Analysis:
 Feasibility study (also called a business case) - is prepared during systems analysis
( Stage 1)and updated as necessary during the remaining steps in the SDLC.
 The Steering committee uses the study to decide whether to terminate a project,
proceed unconditionally, or proceed conditionally.
 The five important aspects need to be considered during a feasibility study are:
1. Technical feasibility - technology
2. Operational feasibility - labor
3. Legal feasibility - Contractual agreement
4. Scheduling feasibility - time
5. Economic feasibility - finance
 What is the basic framework for feasibility analysis? Capital Budgeting Model
 Capital Budgeting Techniques include:
1. Payback period ( PBP)
2. Net present value (NPV)
3. Internal rate of return (IRR)

48
47
 3.2.3. Ongoing Activities over System Development Life Cycle
3. Behavioral Aspects of Change
 Individuals involved in systems development are agents of change who are
continually confronted by people’s reaction and resistance to change.
 The best system will fail without the support of the people it serves.
 Reasons for the occurrence of behavioral problems are :
a) Personal characteristics and background.
b) Manner in which change is introduced.
c) Experience with prior changes.
d) Communication.
e) Disruptive nature of the change process.
f) Fear/phobia.
 Ways how people resist AIS changes :
a) Aggression- violence/attacking the system
b) Projection- protrusion /criticizing the system
c) Avoidance- denial/ rejection of the system

49
48
3.2.3. Ongoing Activities over System Development Life Cycle
Ways of Overcoming  Ways of Overcoming
behavioral problems: behavioral problems :
(Cont’d…)
a) meet needs of the users
a) provide honest feedback
b) keep communication lines b) humanize the system
open c) describe new challenges
c) maintain a safe and open and opportunities
atmosphere d) reexamine performance
d) obtain management support evaluation
e) test the system’s integrity
e) alleviate fears
f) avoid emotionalism
f) seek user participation
g) present the system in the
g) make sure users understand proper context
the system h) control the users’
expectations
i) keep the system simple

50
49
3.2.4. Improving System Development Process
Approach 1: Business Processes  Challenges Faced by
Reengineering (BPR) Reengineering Efforts:
 It is the thorough analysis and complete
redesign of business process and a) Tradition
information systems to achieve b) Resistance
performance improvements.
 BPR reduces a company to its essential c) Time requirements
business processes & focuses on why they d) Risk
are done rather than on the details of how
they are done. e) Lack of management support
 Principles of Reengineering:
a) Organize around outcomes, not tasks.
f) Skepticism
b) Require those who use the output to g) Retraining
perform the process.
c) Require those who produce
h) Controls
information to process it.
d) Centralize and disperse data.
e) Integrate parallel activities
f) Empower workers, use built-in
controls, and flatten the organization
chart.
g) Capture data once, at its source.
51
50
3.2.4. Improving System Development Process
Approach 2: Prototyping  Advantages of Prototyping
 It is an approach of designing a a) Higher user involvement and
simplified working model of a system. satisfaction
 A prototype is quickly built and b) Better definition of user needs
provided to users for testing. c) Faster development time
 What four steps are involved in d) Fewer errors
developing a prototype? e) More opportunity for changes
a) Identify basic systems requirements. f) Less costly
b) Develop an initial prototype that meets  Disadvantages of Prototyping
the agreed-on requirements. a) Significant user time
c) Users identify changes, developers make b) Unending development
changes, and the system is turned over to c) Less efficient use of system
the user.
resources
d) Use the system approved by the users.
d)Incomplete systems development
e) Inadequately tested and documented
systems
f) Negative behavioral reactions

52
51
3.2.4. Improving System Development Process
Approach 3: Computer-Aided Software Engineering (CASE) Tools
 It is an integrated package of computer-based tools that automate important
aspects of the software development process.
 CASE tools are used to plan, analyze, design, program, maintain an
information system.
 Advantages of CASE Technology
a) Cost savings in system development
b) Improved productivity
c) Improved program quality
d) Improved control procedures
e) Simplified documentation
 Disadvantages of CASE Technology
a) Cost of technology
b) Incompatibility
c) Unmet expectations

53
52
3.4. AIS Development Strategies
 They refer to the possible alternatives of using AIS in the given company.
Approach 1: Purchase Software
a) Canned software- is written by software development companies & is sold on the
open market to different users with similar requirements. E.g. Peachtree Accounting
Software
b) Turn key systems – are a combination of software & hardware sold as a package. The
vendor installs the entire system & user needs only to “turn the key”. E.g. Banking
Software
c) Application service providers (ASPs) - Internet has given companies a new way
to acquire software. They host Web-based software on their computers and deliver
the software to their clients over the Internet.
 The screening methods: Bench marking, Point Scoring and Requirement Costing.
 Companies that buy rather than develop AIS software still go through the systems
development life cycle (SDLC).
a) Systems analysis
b) Conceptual design
c) Physical design
d) Implementation and conversion
e) Operation and maintenance
54
53
3.4. AIS Development Strategies(Cont’d…)
Approach 2: Development by In-House IS Department
 Custom software is developed because Canned software does not fit their specific
needs.
1. Custom Software Development by an Outside Company:. Some guidelines
when contracting with an outside organization are :
a) Carefully select a developer
b) Sign a contract
c) Plan and monitor each step
d) Maintain effective communication
e) Control all costs
2. End-User-Developed Software : End-User Computing (EUC) is the hands-on
development, use, and control of computer-based information systems by users.
Examples of end user development uses:
a) Retrieving information from company db to produce simple reports or queries
b) Performing “what if ” sensitivity or statistical analyses
c) Developing applications using prewritten software (spreadsheet or database system)
d) Preparing schedules & lists, such as depreciation schedules, A/R aging, etc.

55
54
 3.4. AIS Development Strategies(Cont’d…)
 Benefits of End-User Computing
a) Systems that meet user needs
b) Timeliness
c) User creation, control, and implementation
d) Freeing up IS resources
e) Versatility and ease of use
 Risks of End-User Computing
a) Logic and development errors
b) Inadequately tested applications
c) Inefficient systems
d) Poorly controlled and documented systems
e) Systems incompatibility
f) Duplication of systems
g) Increased costs
56
55
3.4. AIS Development Strategies(Cont’d…)
Approach 3: Outsourcing the System  Benefits of Outsourcing
 It is hiring an outside company to handle all a) Access to greater expertise and more
or part of an organization’s data processing advanced technology
activities b) Lower costs
1. Mainframe Outsourcing
c) Improved development time
agreement- the outsourcers buy their
client’s computers and hire all or d) A business and information solution
most of the client’s employees. e) Asset utilization
2. Client/Server or PC Outsourcing f) Elimination of peaks and valleys usage
agreement- an organization outsources g) Facilitation of downsizing
a particular service, a segment of its
business, a particular function, or PC  Risks of Outsourcing
support. a) Loss of control of system and/or data
b) Inflexibility
c) Reduced competitive advantage
d) Locked-in system
e) Unfulfilled goals
f) Possibility of poor service

57
56