1

Chapter 5

Systems Development and Management

 2

Learning Objectives
• Provide an overview of system development
• Discuss the different system building
alternatives concept
• Compare strengths, weaknesses of the different
system building approaches
• Understand the project management concept
 3

5.1 Overview of Systems Development

• Systems development: Activities that go into

producing an information system solution to an
organizational problem or opportunity
🞄Feasibility Study
🞄Analysis
🞄Design
🞄Installation & Implementation
🞄Review & Maintenance
 4

The Systems Development Process

Feasibility study

Analysis

Design

Installation &Implementation

Review &Maintenance

Building a system can be broken into 5 core activities.

 5
System development process
• Factors of initiating or affecting Systems Development:
 Internal
 Top management executives
 Instruction or support from top management to develop such a new
IS to offer more functions, more accurate data for decision making
process and improve the work efficiency.
 User requests
 As users rely heavily on IS to perform their jobs, they are likely to request
more IT services & support.
 IT department
IT department staff often make recommendation based on their
knowledge of business operations and technology trends.
 Existing systems
 Errors or problems in existing systems can trigger requests for new
systems projects.
 6

System development process

• Factors of Systems Development:
 External
 Software and Hardware vendors
 The software & hardware used should compatible to each
other as software and hardware vendors may used to
launch new version of hardware and software from time to
time.
 Technology
 Changing technology is a major force affecting business.
 Customers
 Customer are vitally important in any business.
Information systems that interact with customers usually
receive top priority and focus.
 7

System development process

• Factors of Systems Development:
 External
 Competitors
 Competition among companies drives many information
system development decision.
 The economy
 In a period of economic expansion, firms must be ready
with scalable system that can handle additional volume
and growth.
 Government
Federal, state and government regulations affect
the design of the IS.
 System development process

• Reasons of Systems Development

 Reduced costs
 Improved service
 Better performance
 More information
 Stronger control

8
 System development process
• Reasons of Systems Development
 Reduced costs
The current system could be expensive to operate or
maintain.
 Improved service
System requests aimed at improving services to
customers or users within a company.

9
 System development process
• Reasons of Systems Development
 Better performance
The current system might not meet performance
requirements.
 More information
The current system might produce information that is
insufficient, incomplete, inaccurate or not fulfill
user’s/business’s needs.

10
 System development process
• Reasons of Systems Development
 Stronger controls
The current system may lack of effective controls to
ensure that data is secure and safe to be used.

11
Feasibility Study
• A feasibility study is a collection of test/studies
that investigates the information needs of prospective
users and determines the resource requirements,
costs, benefits and feasibility of a proposed project
determine whether that solution was feasible or
achievable from a perspective of time, financial,
technical, and organizational standpoint……Include:
▫ Technical feasibility
▫ Economic feasibility
▫ Operational feasibility
▫ Schedule feasibility

12
Feasibility Study
Steps in feasibility study: -
▫ Gather information/data for a feasibility study.
E.g. define project scope & constraints.
Project scope  definition/extent of what the project is
supposed to accomplish.

constraint requirement or condition that the system must

satisfy. Constraints may involve hardware, software, time,
policy or cost.
e.g. of constraint (cost)the whole project must not cost
more than RM 500,000.

13
Feasibility Study
Steps in feasibility study: -
▫ Formalized a written report including the preliminary
specifications and a developmental plan for the proposed
system.
Preliminary investigation report
includes sections like introduction, system request
summary, findings, recommendations, project roles, time
and cost estimates, expected benefits, appendix.

14
 Feasibility Study
Steps in feasibility study: -
▫ Submit the report for management approval.
 Present & submit the PI report to management and
wait for its approval.
▫ Begin system analysis (if management approves
the recommendations of the feasibility study).

15
 16

Overview of Feasibility Study

 Feasibility Study
Feasibility of a system can be evaluated in term of 4 major categories: -

• Economic feasibility - focuses on whether the expected cost

savings, increased profits, reductions in required investment and
other types of benefits will exceed the costs of developing and
operating a proposed system.
• Economic Feasibility Example– Are there sufficient benefits
in creating the system to make the costs available? Or, are the
costs of not creating the system so great that the project must be
undertaken?
Economic Feasibility is to determine whether the benefit
(tangible and intangible) of proposed solution is greater than
the cost of implementing it. (Cost of acquiring, installing
and operating…)

17
 Feasibility Study
Feasibility of a system can be evaluated in term of major
categories: -

• Technical feasibility - focuses on the reliability/capability of the

hardware and software and other technology needed to meet the
needs of the proposed system, and whether they can be acquired
or developed in the required time.
• Technical Feasibility Example– Can the work for the project
be done with current equipment, existing software technology,
and available personnel? If new technology is required, what is
the likelihood that it can be developed?
A project that is technical feasible where the propose solution must be
capable of implemented by using the available hardware, software,
personnel and any other equipment. (technical resources to develop,
purchase, install or operate the system…)

18
 Feasibility Study
Feasibility of a system can be evaluated in term of major categories: -
• Operational feasibility - focuses on the willingness and ability of
the management, employees, customers, suppliers and others to
operate, use and support the proposed system.
▫Operational Feasibility Example – Will the system be
used if it is developed and implemented? Will there be
resistance from users that will undermine the possible
application benefits. Does management supports the project?
Will the new system difficult to use? If so, will the company
prepared to provide the necessary resource for user training?
Does the system developed contrast with the company goals or
government policy?
Operational Feasibility is to determine whether it is practical or
not to use the proposed system to solve a problem or take
advantage of an opportunity to achieve the company goals.

19
 Feasibility Study
Feasibility of a system can be evaluated in term of major
categories: -
• Schedule feasibility – focuses on whether the new IS can be
developed within the acceptable time frame.
• Schedule Feasibility Example -Will it take too long to
be completed? Can it be done within the time frame set?
A measure of how reasonable the projected timetable is
and how likely the project will be done within the given
time frame.

20
Analysis

 Analysis is an in-depth study of end user information

needs.
Generally, the analysis process can be classified into
2 categories:
 Analysis of the present system
 Determine functional requirement of
proposed system

21
Analysis
Analysis of the present system
• Before designing a new system, a detailed
analysis of the current system (manual
or automated) must be completed.
• An analysis of the present system involves
analyzing activities, resources and the products,
such as report and displays.
• Document how the information activities of
input, processing, output, storage, and control
are being accomplished.

22
Analysis
Determine functional requirement of proposed system
• It is refer to a detailed statement of the information needs that a
new system must satisfy and achieve.
• It identifies who needs what information, when, where and how
the information is needed.
• Steps involved: -
▫ Determining what type of information each business activity
requires.
▫ Determining the information processing capabilities required
for each system activity (input, processing, output, storage and
control) to meet the information needs.
▫ Develop functional requirements (information requirements
that are not tied to the hardware, software and people resources
that end users presently use or might use in the new system).
 Analysis
The following is a list of possible Accounts Payable
functional requirements examples:
• Supports three way matching - purchase order, receipts,
and supplier
invoices
• Supports the option to place an individual invoice on hold
• Allows for modifications to invoice account distribution
after
processing
• Supports the partial payment of invoices
• Etc….
Analysis
Under analysis phase, fact-finding techniques
involved are as follows:
• Interview
• Questionnaires
• Observation
• Document review
 Interview
Meeting where the system analyst can ask the user face
to face on how the current system works and about the
new sys. requirement.
Process of obtaining information by means of
conversation.
Interviewees are current users, sometimes
customers/suppliers, of the current system or potential
users of the proposed systems.
An interview should enable the analyst to overcome the
fears and resistance to change that may be felt by the
employee, in addition to finding out facts about his
work.

26
 Interview
Guidelines to be adopted by the analyst who is conducting an
interview.
• The interviewer must adapt his approach to suit the
individual
interviewee.
e.g. Schedule a specific day and time that made convenient for
interviewee to attend for interview.
e.g. Arrange the location for interview at interviewee’s office
 Interview
Guidelines to be adopted by the analyst who is conducting an
interview.
• The interviewer should be fully prepared for the interview.
Prepare a complete list of interview questions in advance
Must study on the subject matter background beforehand

• Employees ought to be informed before the interview.

 Get the approval from interviewee’s supervisor.
Place a reminder call to interviewee to confirm the interview date,
time, venue.
 Interview
Guidelines to be adopted by the analyst who is conducting an
interview.
• The interviewer must ask questions at the level appropriate
to the
employee's position within the organization.
e.g. for top/senior management  topics covered up overall
company direction, plan, strategy, mission…
e.g. for operational management  topics covered up
detailed
operation practices/procedures
 Interview
Guidelines to be adopted by the analyst who is conducting a fact-
finding interview.
• The interview should not be too formal in a question and answer
session.

• The interviewer should not jump to conclusions or confuse

opinions
with facts.

• The interviewer should gain the interviewee's confidence by

explaining in full what is going on and not giving the impression
that he is there solely to find fault.
 Interview
Guidelines to be adopted by the analyst who is conducting an interview.

• The interviewer should arrange interviews so that he moves progressively

through the system.

• The interviewer should refrain from making off the record comments during
the course of the interview.

• The interview should be long enough for the interviewer to obtain the
information.
• The interview should be concluded by a resume of its main points.
 Questionnaires
Formal lists of questions which can be submitted to a user for
him or her to answer at their leisure which include open ended
questions and close ended questions.
• The use of questionnaires may be useful whenever a limited
amount of information is required from a large number of
individuals, or where the organization is decentralized with
many ‘separate entity’ locations.
 33

Sample of questionnaire….
 Questionnaires
• Guidelines to carry out questionnaires.
Employees ought to be informed before receiving the
questionnaire.
Questions must be designed to obtain exactly the
information necessary for the study.  e.g. Design
straight forward question & avoid leading respondent to
a bias / favouring an issue.
 Questionnaires
▫ Questionnaires should be designed with the following in mind:-
 They should not contain too many questions.
 They should be organized in a logical sequence.
 They should include an occasional question.

 Ideally, they should be designed so that each question can be

answered by either ‘yes’ or ‘no’ or a ‘tick’ rather than sentences
or paragraphs.
Questionnaire uses more close-ended questions rather than
open ended question.
 Questionnaires
▫ Questionnaires should be designed with the following in mind:-
 The test answers should enable the systems analyst to establish
the effectiveness of his questions and help determine the level
of subsequent interviews and observations.
 the questionnaire’s feedback should reflect here to
interviewer on what areas/fields/topics to cover up more in the
coming interview/observation/survey.
 They should take into account the sensitivity of individuals in
respect of their job security, change of job definition etc.
 Submit the questionnaire without written name on the
top.
Observation
Process of observing the current operating procedures, in order to
have a fully understanding of the system’s operation.
Through observation, we might correct any misconceptions or
erroneous impressions.
▫ Observation is used to cross-check with the facts obtained by
interview or questionnaire.
▫ It should be noted that staff may act differently from normal if they
know that they are being observed (Hawthorne Effect): whereas
there might normally be a lack of adherence (persistence) to
procedures lay down in manuals, these might be rigorously
followed in the presence of a systems analyst.
Document Review
▫ The systems analyst-must investigate the documents that are used
in the system. Examples: - organization charts, procedures
manuals and standard operational forms.
▫ The overriding risk is that staff do not follow documented policies
and procedures or that these documents have not been properly
updated, so this method is best used in tandem with one or more
other techniques.
work as a technique to cross-check and verify fact as it provides
SA a better understanding of procedures through detailed
description of work documents but be careful that existing
documents reviewed might be no longer in use or the actual
practices might not comply to the system documentation.
 39

Design
• The analysis stage describes what a system should do to
meet the information needs of users.
• The design stage specifies how the system should work to
accomplish this objective.
Refer to the process of producing overall system
specifications/blueprints (design plan/model) for a new
system.
These blueprints should address all the managerial
organizational and technological components of the new
system solution.
 40

Design
• In short, the design stage consists of 3 activities, which includes:-
 User interface design
 Data design
 Processes design
 Design
User interface design
🞄User interface design focuses on designing the
interactions between end user and computer systems.
🞄User interface design produces detailed specifications
for information products such as: -
🞄Display screens
🞄 Interactive user/computer dialogues box
🞄Audio responses
🞄Forms
🞄Documents
🞄Reports.

41
 42

User Interface Design Sample

 Design
Data design
▫ The data design activity focuses on the design of the
structure of databases and files to be used by a proposed
IS.
▫ Data design frequently produces a data dictionary, which
consists of the detailed descriptions of the: -
🞄 Attributes or characteristics of the entities (objects, people, places,
events) about which the proposed IS needs to maintain information.
🞄 Relationships these entities have to each other.
🞄 Specific data elements (databases, files record, etc) that need to be
maintained for each entity tracked by the IS.
🞄 Integrity rules that govern how each data element is specified and
the used in the IS.

43
 Design
Data design
▫ Example of data dictionary are as follows:
DATA FLOW NAME : Applicant’s particulars
DESCRIPTION : Personal particulars of an applicant.

SOURCE : Applicant

DESTINATION : 1. New Membership Registration

CONTENTS : Applicant’s name +applicant’s gender

+ applicant’s address

VOLUME : Average 5 applicants per day

44
Design
Processes design
▫ The process design activity focuses on the design of
software resources, that is, computer programs and of
procedures needed by the proposed IS.
▫ It concentrates on developing detailed specifications for
the program modules that will have to be developed by
custom programming.

45
Design
Process design
▫ Example of process design specifications (e.g. DFD) are as
follows:
Overview diagram of a grading system

Test mark
Student grade
2
Compute
GPA

Assignment
mark

46
 Design
• Finally, the systems designer will details all the design that
will deliver such functions identified during system analysis
stage and put it into a document design specification
document.
• Design specification document --- overall plan or model for
the system (e.g. include of user interface design, database
structures, processing and control structures).
• However, the design should be based on the criteria such as
simple, ease of use, effectiveness and efficiency and
reliable that is fulfills user’s unique requirements within a
specific set of technical, organizational, financial and time
constraints.
47
 48

Design
• A list of system specifications that should produced in the
design specification document:-
OUTPUT PROCESSING DOCUMENTATION
Medium Computations Operations documentation
Content Program modules Systems documents
Timing Required reports User documentation
Timing of outputs
INPUT CONVERSION
Origins MANUAL Transfer files
Flow PROCEDURES Initiate new procedures
Data What activities Who Select testing method
entry performs them When Cut over to new system
How
USER Where TRAINING
INTERF Select training techniques
ACE CONT Develop training modules
Simplicity ROLS Identify training facilities
Efficiency Input controls (characters, limit, reasonableness)
ORGANIZATIONAL
Logic Processing controls (consistency, record counts)
CHANGES
Feedback Output controls (totals, samples of output)
Task redesign
Errors Procedural controls (passwords, special forms)
Job redesign
DATABA SECURITY Process design
SE Access controls Organization structure design
DESIGN Catastrophe plans Reporting relationships
Logical data model Audit trails
Volume and speed
requirements
File organization and
design
Record
specifications
Installation and Implementation
• Once a proposed IS has been designed, it must
be implemented accordingly.
• The system implementation stage involves: -
A. Coding
B. Testing of programs and procedures
C. Development of documentation
D.Education and training of end users and specialists
who will operate the new system.
E.Converting from the use of the present system to the
operation of a new or improved system.
A. Coding

• Coding/programming  a process of
translating system specifications from design
stage into software program code.
• The software programs can be either written
by internal IT staff or end user, purchase
application or customized software packages
from software vendors or employ outsourcing
firms that in-charge of application software
development and operation part for them.

50
 A. Coding
• Example of program code:-
• // File SmileMIDlet.java
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class SmileMIDlet extends MIDlet {
private Command exitCommand;
private Display display;
public SmileMIDlet() {
display = Display.getDisplay(this);
}
public void startApp() {
SmileGameCanvas canvas = new SmileGameCanvas(this);
display.setCurrent(canvas);
}
public void pauseApp() { }
public void destroyApp(boolean unconditional) { }
}
51
 52

B. Testing
• Checks to see if the computer code will produce
the expected and desired results under certain
conditions.
• 3 types of testing activities:
▫ Unit testing:
▫ Systems testing:
▫ Acceptance testing:
 Types of testing
Unit testing
• Test of an individual program or module .
• Objective - to identify & eliminate errors of such
program/module.
• Test data – correct (real) data & erroneous data
Types of testing
System Testing
• After completion of unit testing, one must run a series of
system tests that involve the entire information system.
Test the entire the system as a whole.
• It determines those discrete and separate modules will
function together as planned.
• Among the area examined are performance time, capacity
for file storage and handling peak loads, recovery and
restart capabilities and manual procedures.
• During a system test, user enters data, including of live
data, perform queries, and print reports to simulate actual
operating conditions.
Overview of System Testing
Types of testing
Acceptance Testing
• It is the final stage before system is sending for
installation.
• Objective: Demonstrate that users can interact with
the system successfully.
• It provides the final certification that the system is
ready to be used in a production setting.
• Generally, it is tested by users and reviewed by
management.
• When all parties are satisfied that the new system
meets their standards, the system is formally accepted
for installation.
 57

Test Plan
• The systems development team works with users
to devise a systematic test plan.
• Test plan – it is prepared by the development
team in conjunction with the users.
• When developing a test plan, it is imperative to
include the various conditions to be tested, the
requirements for each condition tested, and the
expected results. Test plans require input from
both end users and information systems
specialists.
 58

Sample Test Plan to Test a

Record Change
C. Documentation Writing

• Accurate documentation helps a programmer who

needs to carry out a future program change to make
maintenance easier, faster and less expensive.
• Detailed documentation must be established in order
to show how the system works and so that it can be
used during training time and everyday operation.
 Documentation can be further divided into two major
types:
 System documentation
 User documentation

59
C. Documentation Writing
System documentation
• Records detailed information about a system’s design
specifications, its internal workings and its functionality.
• Examples of system documentation: part of the program
source code or code that is generated at compile time, the
outcome of all of the structured diagramming
techniques, such as data flow (DFD), entity-relationship
techniques (ERD), real program code etc.

60
 C. Documentation Writing
User documentation
• Written or other visual information about an application
system, how it works, and how to use it.
Less technical compare to system documentation.
• Two target audiences: the new employee who knows nothing
about the system, and the experienced employee who uses
the documentation only for occasional reference.
• User documentation includes the following:
▫ Systems overview that clearly describes all major system
features, capabilities, and limitations.—user manual
▫ Menu and data entry screen options, contents, and processing
instructions.
▫ Reports that are produced regularly or available at the user’s
request, including routine report (transaction & summary) &
ad-hoc report samples.
▫ Security and audit trail information.
▫ Procedures for requesting changes and reporting problems.
61
▫ Frequently asked questions (FAQs)
 D. Training
• All people who have primary or secondary use of the
system must be trained.
• This includes everyone from data-entry personnel to
those who will use output to make decisions
without personally using a computer.
• The amount of training requires depend on how
much someone’s job will change because of the new
system.
• Different individual will have different knowledge,
education level, working responsibilities, and many
other factors that will be needed to take into
consideration.
• Possible training source:
▫ Vendors
▫ In-House trainer (by Systems Analyst)
▫ External paid trainers (Outside training
resources) 62
 63

E. Conversion
• The process of converting from the old system
to the new system.
• Four major conversion strategies:-
▫ Direct conversion:
▫ Parallel conversion:
▫ Pilot conversion:
▫ Phased conversion:
 64

E. Conversion

Direct
 65

E. Conversion
Old New
Syste Syste
Direct Conversion m m
• It replaces the old system entirely with the new
system on an appointed day.
• Advantages
▫ Save time
▫ Save cost
• Disadvantages
▫ Risky
▫ Costly (if serious problems exist in future)
 66

E. Conversion Old
S y st e m

New
S y st e m
Parallel Conversion
• Both the old and its potential replacement are run together
for a time until everyone is assured that the new one
functions correctly.
• Advantages
▫ Safest approach  in the event of error or processing disruptions,
the old system can act as a backup.
• Disadvantages
▫ Very expensive
▫ Time consuming
▫ Additional resources (like additional staff) may require to run the
extra system.
 67

E. Conversion
Ol Ne
d System
w
System
Pilot Conversion
• It introduces the new system to only a limited area of the
organization, such as a single department or operating unit.
 For instance, a new sales reporting system might be implemented
in just one branch office. And this group that uses the news system
first is called the pilot site
• When pilot version is complete, it is installed throughout the rest of
the organization, either simultaneously or by stages.
• Advantages
 While problems exist, just the selected area / unit will be affected.
 Able to identify errors at the early stage.
• Disadvantages
▫ Except the selected unit, the other units still have to use back with
the
old system. Other units have to take time to wait.
 68

E. Conversion Ol Ne
Syste
d w
Syste
m m
Phased Conversion
• It introduces the new system in stages, either by functions or by
organizational units.
 Instead of implementing a new ERP system all at once, it is being
divided into a number of parts or modules and introduce to the
whole organization part-by-part.
Advantage
•
▫ While problems exist, just the selected function will be affected.
Disadvantage
•
▫ Time taken if to convert the entire system.
▫ Not applicable for the system which can’t be segmented at all.
 69

Review and Maintenance

• During this stage, the system will be reviewed by both users

and technical specialists to determine how well it has met its
original objectives.
• Meanwhile, they are also here to decide whether any
revisions
or modifications are to consider further.
• Usually, a post-implementation evaluation will be
considered to assess the overall quality of the information
system and necessary changes to be made further if any.
• A post-implementation evaluation should examine all aspects
of the development effort and the end product, the developed
information system.
• The same fact-finding techniques use in systems analysis can
be used in this post-implementation evaluation.
 70

Review and Maintenance

• Maintenance – is the process of involving

changes in hardware, software, documentation or
procedures to a production system to correct errors,
meet new requirements or improve processing
efficiency.
 71

Review and Maintenance

• Types of maintenance:
▫ Corrective – correction of
errors
detect & fix error
 72

Review and Maintenance

• Types of maintenance:
▫ Adaptive – adding new features to make it easier to
use & adapt to business environment changes
Add new capability & enhancement
 73

Review and Maintenance

• Types of maintenance:
▫ Perfective – changing an operational IS to make it
more efficient, reliable and maintainable
changes made to improve Efficiency &
Effectiveness
 74

Review and Maintenance

• Types of maintenance:
▫ Preventive – changing an operational IS to reduce
chance of future system failure
changes made to reduce the possibility of future
system failure.
 75

5.2Traditional Systems Life Cycle

• Also known as System Development Life Cycle (SDLC).
• The systems life cycle is a traditional methodology for
developing an information systems that partitions the
systems development process into formal stages that must
be completed sequentially with a very formal division of
labor between end users and information systems
specialists.
• Usually, IS/technical specialists are systems analysts and
programmers, who are responsible on the systems analysis,
design and implementation tasks.
• End users / users are limited to providing information
requirements and reviewing the technical staff’s
work.
 76

5.2Traditional Systems Life Cycle

• The systems life cycle is mainly like a “waterfall”
approach in which a task in one stage is completed
before next stage begins.
• However, it is possible here for the systems builders to
go back and forth among stages in the life cycle to
perform additional analysis or review new information
that has not been discussed before.
• But when requirements and specifications need to be
revised, steps need to be repeated and a new document
(result) must be re-generated.
 77

5.2Traditional Systems Life Cycle

• The steps involves in traditional SDLC are: -

▫ System Investigation / System Planning
▫ System Analysis
▫ System Design
▫ System Implementation
▫ System Maintenance
SDLC
Understand the  Determine how to address business opportunities &
business System priorities.
problem / Investigation  Conduct a feasibility study to determine whether a
opportunity Feasibility Study new / improved business systems is feasible solution.
 Develop a project management plan & obtain
management approval.
Develop an IS System Analysis  Analyze the information needs of employees, customers,
solution
Functional & other business stakeholders.
Requirements  Develop the functional requirements of a system that can
meet
business priorities & the needs of all stakeholders.
System Design  Develop specifications for the hardware, software, people,
System network & data resources, & the information products that
Specifications will satisfy the functional requirements of the proposed
business IS.

Implement the IS System  Acquire (or develop) hardware & software.

solution Implementation  Test the system, & train people to operate & use it.
Operational IS  Convert to the new business system.

System  Use a post-implementation review process to monitor, evaluate

Maintenance & modify the business as needed.
Approved System
SDLC

Advantages of SDLC:
 Useful for large, complex systems and projects.
-highly structured approach follow rigorous & systematic way to develop a
project especially emphasis on the importance of analysis & design phase to
ensure that business need is meet / ↓ chances of redo.
 Provides sequential step-by-step formal process. easy to follow
 To take into account the future need of the organization  required to
maintain / improve system from time to time.
SDLC

Disadvantages of SDLC:
 Slow and expensive
must complete 5 phases in sequence, X skip any phase in between
 Discourage changes
as any new changes/requirement add in later in the subsequent
stages will cause you to redo part/whole of the earlier phase
 Massive paperwork to manage.
 especially during Investigation, Analysis, Design stage…
 81

5.3 Alternative System-

Building Approaches
• Prototyping: The process of building an
experimental system quickly and inexpensively
for demonstration and evaluation.
• Application software packages: A set of
prewritten, pre-coded application software
programs that are commercially available for sale
or lease.
• Outsourcing: The practice of contracting
computer center operations, telecommunication
networks, or applications development to external
vendors
 82

5.3.1 Prototyping
• Prototype: The preliminary working version of an
information system for demonstration and
evaluation purposes.
• Prototyping: The process of building an
experimental system quickly and inexpensively for
end user demonstration and evaluation so that
users can better determine information
requirements that they want.
 83

Prototyping (Cont.)
• Steps in Prototyping
1. Identify the user’s basic requirements
2. Develop initial prototype
3. Use (test & trial out) the prototype
4. Revising and enhancing the prototype
 84

Prototyping (Cont.)
Identify
basic
STEP 1
requirements

Develop a
working STEP 2
prototpe

Use the
STEP 3
prototyp
e

YES
User
satisfied
?
NO

Revise and
Operationa enhance the STEP 4
l prototype
Prototype
 85

System Prototype….
• System Prototype working model of the
information system, ready for implementation.

Planning Analysis Design SYSTEM

PROTOTYPE

Implementation
 86

Design Prototype
• Design prototypeuser-approved design
prototype that documents and benchmarks the
features of the finished system.

Planning Analysis Design Implementation

DESIGN
PROTOTYPE
 87

Prototyping (Cont.)
• Advantages:
▫ most useful when user requirements are
uncertain.
▫ Functional/valuable in designing information system’s
end-user interface (data-entry screen, reports or Web
pages).
▫ Encourages intensive user involvement.
 88

Prototyping (Cont.)
• Disadvantages:
▫ Rapid prototyping may gloss over (skip) essential
steps
in system development
e.g. skip the phase of analysis & design in system
development ---redo & incur more cost later.
 89

Prototyping (Cont.)
• Disadvantages:
▫ Not suitable for large systems development
 Large project need to integrate with other system,
not
easy to call & involved lots of user for testing purpose.
▫ Time consuming due to user changes
 It required time that some users may not be able or
not
wanted to spend.
 90

Prototyping (Cont.)
5.3.2 Application software packages

• Can be categorized into two:

A. Purchased Applications
B. Customization of software package

91
 A. Purchased Applications

• Also called ‘off-the-shelf’ packages.

▫ Many examples: MYOB, QuickPay, UBS, SAP ERP 6.0
etc
• Why Purchased?
▫ Well designed, tested
▫ Easily Available
▫ save time and money

92
 93
Steps in Purchasing ready-made Software Package
Step 1
Evaluate the IS Requirement

Step 2
Identifying Potential s/w Vendors

Step 3
Evaluate s/w Package
Alternatives

Step 4
Make the purchase

Step 5
Install the s/w package
 94

A. Purchased Applications
Steps in purchasing ready-made software
1. Evaluate the information system requirements
▫ Identify the key features of the system

▫ Estimate volume and future growth

E.g.
▫ Specify any hardware
constraints
 95

A. Purchased Applications
Steps in purchasing ready-made software
1. Evaluate the information system requirements
▫ Prepare a request for proposal (RFP)

• ***** Request For Proposal (RFP) is a document describes

your company, lists the IT services or products you need,
and specifies the features you requires which send to the
respective software vendors.
• It can include some essential or optional features there for
which you want it.
 96

A. Purchased Applications
Steps in purchasing ready-made software
2. Identify potential software vendors

3. Evaluate software package alternatives

▫ Existing users
▫ Testing
▫ Benchmarking

4. Make the purchase

5. Install the software package

 97

A. Purchased Applications

Advantages of purchasing
• Fewer analysts and programmers required
• Low Cost
• Low maintenance costs
• Excellent documentation
• Fast implementation
• Continually updated
 98

A. Purchased Applications

Purchasing risks
• Not meeting the requirements
• Less efficient
• Lack of vendor supports
• Purchases may pay for features they don’t need
• Problems of maintenance
 99

B. Customization of software package

• Customization can be defined as the processes of modify the
software package to meet an organization’s unique requirements
without destroying the package software’s integrity.
Buy commercial s/w + modification

3 Ways to further customize a s/w package

• You can purchase a basic package from s/w vendors. Many vendors
offered the add-on components that later you can configure it
yourself.
• You can negotiate directly with the software vendors to make
enhancements at software to meet your need by paying them the
extra charges.
• You can purchase the package and make your own modifications
(done by the internal IT dept staff).
 100

B. Customization of software package

Advantages
• Satisfy unique requirement
• Meet constraints of existing systems and technology
• Development time should be much quicker, given that
most of the system will be written already.
 101

B. Customization of software package

Disadvantages
• Costly
• May cause time delay
• Not meet the requirements
• May introduce bugs that do not exist in the standard version
• New skill and expertise needed
• Problems of maintenance
 102

5.3.3 Outsourcing
▫ Is the process of turning over an organization’s computer
center operations, telecommunication networks or
applications development to external vendors.
Practice of contracting computer center operations,
telecommunications networks, or applications
development to external vendors.

▫ In other words, outsourcing is the use of outside

companies to handle a portion of a company’s workload.
 103

Outsourcing (Cont.)
▫ The outsourcing vendor might be domestic or
in other country (offshore outsourcing).
▫ Domestic outsourcing driven by firms need for
additional skills, resources and assets.
▫ Offshore outsourcing driven by cost-savings
purposes. For example, a skilled programmer in
India or Russia earn about US 9,000 per year
compared to US 65,000 per year for a comparable
programmer in the United States.
 104

Outsourcing (Cont.)
• Advantages:
▫ Improved financial planning
▫ Reduced license and maintenance fee
▫ Increased attention to core business
 Internal staff are more focus on their own field/ area of
concern.
 105

Outsourcing (Cont.)
• Advantages:
▫ Shorter implementation cycles
▫ Reduction of personnel and fixed costs
▫ Availability of ongoing consulting as part of the
standard support exploit the intellect of another
organization
 106

•
Outsourcing (Cont.)
Disadvantages:
▫ Loss of control  Increases vulnerability of strategic
information.

▫ Reduces technical know-how for future innovation  risks of
losing a competitive advantage
Internal IT staff “LOYALTY & COMMITMENT”
 107

Outsourcing (Cont.)
• Disadvantages:
▫ Increases dependency on other organizations  Loss of
experienced employees
▫ Contract problems
e.g. When a contract is coming to an end and due for
renewal, the organization is often not at the bargaining
end when comes to negotiating prices.
 108

Project Management and Concept

Project: A planned undertaking of related activities to reach an objective that
has a beginning and an end.
Project management:
• Project management is the ongoing process of directing and coordinating all
the steps in the development of an information system.
• The main objective of project management is to ensure a successful
completion of a project. A project will be considered as successful only if it
is completed with certain quality level, within the budget allocated and the
time duration planned.
• Effective project management is necessary throughout the entire systems
development life cycle to ensure successful completion of the project.
• Many stages are involved in a particular project development. A project
manager, therefore, needs to have the necessary skills and experience to
manage the project.
 109

Project manager:
• Responsible for creating high-level feasibility
plans and detailed project plans as well as
staffing project team
• Determining the size, scope, and resource
requirements for a project
• Required to have interpersonal skills, leadership
skills and technical skills
 110

Project Management
• A controlled process of initiating, planning, executing, controlling
and closing down a project.
• The focus of the following section is on the project management
process. The activities involved in managing a project occur in four
phases:

1. Initiating the project

2. Planning the project
3. Executing the project (control and monitoring the
project)
4. Closing down the project
 111

Project Initiation:
• The first phase of the project management which several
activities are performed to assess the size, scope, and
complexity of the project and to establish procedures to
support later project activities.
Project Planning:
• The second phase of the project management process
which focuses on defining clear, discrete activities and
the work needed to complete each activity within a single
project.
 112

Project Execution:
• The third phase of the project management process in which the
plans created in the prior phases (project initiation and planning)
are put into action.
Project Close-Down:
• The final phase of the project management process that focuses
on
bringing a project to an end.
• Projects can conclude with a natural or unnatural termination.
• A natural termination occurs when the requirements of the
project
have been meet –the project has been completed and is a success.
• An unnatural termination occurs when the project is stopped before
completion.