Acquiring Information Systems

• The main choices when acquiring information systems can be

categorized as
• off-the-shelf (packaged),
• bespoke applications developed by an in-house IT department or
• a software house and end-user developed systems
Bespoke development
• Bespoke development refers to when an information system is developed by an information systems
professional to match the business requirements of the application.
• The information systems professionals will either work for the business which is termed ‘in-house’
bespoke development or for a third party such as a software house which is termed ‘outsourced’
software development.
• Bespoke development has the benefit of producing software tailored to the precise requirements of
the business.
• Disadvantages include cost, bespoke development is the most expensive way of developing new
information systems.
• In terms of time bespoke development, especially when using formal structured development
methodologies, is notorious for time overruns, with delays of months or years not uncommon and
quality.
• The quality bespoke software is not usually free from bugs; software bugs can range from the trivial
to the catastrophic, the latter often attributable to poor analysis of requirements.
Off-the-shelf software
• This involves direct purchase of a pre-written application used by more than one
company.
• This type of software is pre-written and offers a broad functionality that will suit a
wide range of different businesses.
• It also may offer too many features for any particular business, which may then feel
that it is paying for things it will not use.
• It may require businesses to process information in a particular way that is at odds
with the way they normally do business.
• Alternatively, a certain off-the-shelf software package may not offer sufficient features.
• The major benefit, however, of off-the-shelf software packages is their low cost when
compared with acquiring bespoke software with the same level of functionality.
• In addition, because packaged software has been developed for a commercial market,
it is less likely to suffer from the bugs that afflict bespoke software.
End-user-developed software
• End-user-developed software is software written by non-IS professionals, i.e. the
business users.
• Enterprise resource planning or institutional applications are those that affect
general corporate activities, cut across more than one department or functional
area, or systems that involve organizational data held in corporate databases.
• Examples include accounting systems, sales order processing systems and materials
requirements planning.
• End-user applications are more limited in scope. Applications may be departmental
or personal in nature and are usually output- or report-oriented rather than input-
driven.
• These applications may either be written by IT professionals or by the end-users
themselves. If the latter is the case, they are often referred to as end-user-
developed applications.
Factors affecting software acquisition

• Organisation size. A small or medium-sized business will inevitably have relatively

limited resources for the purchasing of information systems and information
technology (IS/IT). So there will be a tendency for such organizations to favor the
purchase of off-the-shelf packages or possibly end-user applications development.
• In-house IS/IT expertise. Where little in-house IS/IT expertise exists, either in the
form of IS/IT professionals or experienced end-users, there will be a need to use
third parties in the acquisition of new business information systems.
• Complexity of the required information system. Where a business information
system requirement is particularly complex, or for an unusual application not
available as a packaged solution, it is possible that one may view bespoke software
(either developed in-house or by a third party) as the only viable solution.
• Uniqueness of the business or business area to be supported. The higher
the degree of uniqueness that exists in the area to be supported, the less
likely it is that a suitable off-the-shelf package can be found. This is clearly
an indicator, therefore, for bespoke development of some kind.
• IS/IT expertise among end-users. A certain degree of IS/IT literacy and
expertise is necessary if end-users are to be able to develop information
systems. In addition, such literacy is desirable when selecting suitable off-
the-shelf packaged software, as it can help the business focus more clearly
on its precise requirements from both a functional and a technological
perspective.
• Linkages with existing applications software. Where new business
software needs to integrate very tightly with existing information systems,
there is a higher probability that at least some bespoke development work
will need to be done to integrate the two systems. Also, a high degree of
integration may imply that the new information system has to be developed
in a bespoke fashion in order to achieve the desired level of integration.
The systems development life cycle
• The systems development life cycle (SDLC) is the classical approach
used to develop information systems
• The SDLC approach recognizes that systems are developed in a series
of steps or phases and that each phase needs to be completed before
the next one commences.
• Recognition is also given to the fact that the programming activity
(part of the build phase) should only commence once user
requirements have been determined and the system design
produced. We will now summaries the basic steps that most systems
development projects follow.
• Following are the different phases of software development cycle:
• System study/ Problem ID/ Initiation
• Feasibility study
• System analysis
• System design
• Coding and Testing
• Implementation and Maintenance
System study/Initiation/Problem ID
• Involves acknowledging the need for an information system and showing
where the system will be most useful or how the system will benefit the
organization.
• In practice, the system study is done in two phases.
• the preliminary survey of the system is done which helps in identifying the scope of
the system.
• Amore detailed and in-depth study in which the identification of user’s requirement
and the limitations and problems of the present system are studied.
• After completing the study, a system proposal is prepared by the System
Analyst (who studies the system) and placed before the user.
• system study phase passes through the following steps:
• problem identification and project initiation
• background analysis
• inference or findings
Feasibility study
• The feasibility study is basically the test of the proposed system in the
light of its workability, meeting user’s requirements, effective use of
resources and, the cost effectiveness.
• The main goal of feasibility study is not to solve the problem but to
achieve the scope.
• The following studies are normally carried out;
• Economic
• Technical
• Operational
• Motivational
System Analysis
• Analysis involved a detailed study of the current system, leading to specifications
of a new system.
• A requirements specifications document is produced which contains;
• Hardware and Software specifications
• Functional and Non – functional requirements
• Analysis is a detailed study of various operations performed by a system and their
relationships within and outside the system. During analysis, data are collected
by;
• Observation
• Questionnaires
• Interviews
• Experiments
System Design
• The design proceeds in two stages :
• preliminary or general design
• Structure or detailed design
• Preliminary or general design: the features of the new system are specified. The costs of
implementing these features and the benefits to be derived are estimated.
• Structure or Detailed design: computer oriented work begins. At this stage, the design of the
system becomes more structured. Structure design is a blue print of a computer system solution
to a given problem having the same components and inter-relationship among the same
components as the original problem. Input, output and processing specifications are drawn up in
detail. In the design stage, the programming language and the platform in which the new system
will run are also decided.
• There are several tools and techniques used for designing. These tools and techniques are:
• Flowchart
• Data flow diagram (DFDs)
• Data dictionary
• Structured English
• Decision table
• Decision tree
Coding and Testing
• Coding implements the design through writing the system in a specific
programming language.
• Testing involves checking if the system works as expected. It is in
several levels;
• Unit testing (error corrections)
• Integration testing
• System acceptance testing (goes with training)
Implementation and Maintenance
• Implementation involves changing over from the old system to the
new one which can be done using any of the following methods;
• Direct changeover
• Parallel changeover
• Pilot changeover
• Phased changeover
• Maintenance involves continuous improvement and correction of
errors in the system during its lifetime, which can be;
• Corrective
• Additive
Systems Development Methodologies
• Two main approaches to SDLC
• Traditional approach: structured systems development and information
engineering. E.g. Waterfall methodology
• Agile approach: Concentrates on ensuring that the system is in the hands of
the user as fast as possible. Hence it uses object technologies which requires
different approach to analysis, design, and programming. E.g. Prototyping,
Rapid Application Development, Spiral, Extreme Programming, etc.
Waterfall methodology
• each phase falls into next phase
• Freeze planning specifications before analysis
• Freeze analysis specifications before design
• Once go over the waterfall for each phase, do not go back
• Overlapping (or concurrent) phases
• Waterfall is not realistic, we are not perfect
• Overlaps can be more efficient than waterfall
Waterfall Advantages
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule
Waterfall Disadvantages
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits
flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development –
iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be
too late)
Systems Development Methodologies
• Rapid Application Development (RAD)
• RAD-based methodologies adjust the SDLC phases to get some part of
system developed quickly and into the hands of the users.
• Most RAD-based methodologies recommend that analysts use special
techniques and computer tools to speed up the analysis, design, and
implementation phases, such as CASE (computer-aided software
engineering) tools.

System Analysis and Design System Analysis 20

Systems Development Methodologies
• Rapid Application Development (RAD)
• Five key factors
1. Extensive user involvement
2. Joint Application Design sessions
3. Prototyping
4. Integrated CASE tools
5. Code generators

System Analysis and Design System Analysis 21

Systems Development Methodologies
• Rapid Application Development (RAD)
• RAD is a general strategy rather than a single methodology
• Goals
• To analyze a business process rapidly
• To design a viable system solution through intense cooperation
between users and developers
• To get the finished application into the hands of the users quickly
• Traditional SDLC steps are followed, but phases are
combined
• Iteration is limited to design and development phases

System Analysis and Design System Analysis 22

 Systems Development Methodologies (RAD)
Advantages
Dramatic time savings the systems development
effort
Can save time, money and human effort
Tighter fit between user requirements and system
specifications
Works especially well where speed of development
is important
Ability to rapidly change system design as
demanded by users
System optimized for users involved in RAD
process
Concentrates on essential system elements from
user viewpoint
Strong user stake and ownership of system
System Analysis and Design
Disadvantages
More speed and lower cost may lead to lower
overall system quality
Danger of misalignment of system developed via
RAD with the business due to missing information
May have inconsistent internal designs within and
across systems
Possible violation of programming standards
related to inconsistent naming conventions and
inconsistent documentation
Difficulty with module reuse for future systems
Lack of scalability designed into system
Lack of attention to later systems administration
built into system
High cost of commitment on the part of key user
personnel
System Analysis 23
Systems Development Methodologies
• Prototyping methodology
• Prototyping methodology perform the analysis, design and
implementation phases concurrently.
• All three phases are performed repeatedly in a cycle until the system is
completed.
• A prototype is a smaller version of the system with a minimal amount of
features.

System Analysis and Design System Analysis 24

Systems Development Methodologies
• Prototyping methodology
• Quickly converts requirements to working version of system
• Once the user sees requirements converted to system, will ask for
modifications or will generate additional requests
• Most useful when:
• User requests are not clear
• Few users are involved in the system
• Designs are complex and require concrete form
• History of communication problems between analysts and users
• Tools are readily available to build prototype

System Analysis and Design System Analysis 25

Systems Development Methodologies
• Prototyping methodology
• Types of prototypes
• Prototype are of two types
• Evolutionary
• Evolutionary prototype is continually refined until it contains all of the functionality that
the users require of the new system
• A requirements/throwaway prototype
• Developed as a way to define the functional requirements of the new system when the
users are unable to determine exactly what they want
• A requirements prototype review the requirements, features are added, users are able
to define the processing required for the new system

System Analysis and Design System Analysis 26

Systems Development Methodologies
• Prototyping methodology
• Development of an Evolutionary Prototype
1. Identify user needs: the developer interviews users to obtain an idea of what is
required from the system
2. Develop a prototype: the developer uses one or more prototyping tools to develop a
prototype
3. Determine if the prototype is acceptable: the users decide if the prototype is
satisfactory or not. If not the prototype is go back to the step one
4. Use the prototype: the prototype becomes the production system

System Analysis and Design System Analysis 27

Systems Development Methodologies
• Prototyping methodology
• Development of a Requirements Prototype
• The first three steps to develop a requirements prototype are the same as
those taken to develop an evolutionary prototype. The next steps are as
follows
4. Code the new system: the developer uses the prototype as the basis for coding the new
system
5. Test the new system
6. Determine if the new system is acceptable: the users advises the developer whether
the system is acceptable or not. If not go back to step four
7. Put the new system into production

System Analysis and Design System Analysis 28

Systems Development Methodologies
• Prototyping methodology
• Advantages:
• Most important functionalities are considered as and when they
arrive
• Consistency between requirements is checked in each iteration
• Customers feel the progress of the development process
• Developer can use the prototype in any iteration as a source for
winning customer contracts
• Disadvantages:
• Identifying the most important subset of requirements at any
stage is a tedious task
• Establishing consistency in each iteration is a repetitive work,
particularly when new subset of requirements bear no
relationships with the existing ones
• Sharing data with other systems is often not considered
• Project deadline cannot be estimated

System Analysis and Design System Analysis 29

Spiral Model
• The spiral model was developed in recognition of the fact that systems
development projects tend to repeat the stages of analysis, design and code
as part of the prototyping process. Each spiral consists of four main activities
which are:
• Planning. Setting project objectives, defining alternatives.
• Risk analysis. Analysis of alternatives and the identification and solution of risks.
• Engineering. Equivalent to the build phase of the SDLC with coding and testing.
• Customer evaluation. Testing of the product by customers.
•  The model is closely related to RAD, since it implies iterative development
with a review possible after each iteration or spiral, which corresponds to the
production of one prototype or incremental version.
• Before the first spiral starts the requirements plan is produced, so it can be
seen that the spiral model does not detail the initiation and analysis phase of
the SDLC, focusing on design and build.