Chapter 7
Introduction to acquiring and developing BIS
Definitions
BIS acquisitions: Process of evaluating and implementing for a BIS.
Systems development lifecycle (SDLC): Any information system project follows a logical series of
development phases. These are known as the systems development lifecycle.
SDLC stages: Initiation, feasibility study, analysis of business requirements, systems design, system
build and implementation and, finally, reviews and maintenance.
Besproke development: An IS is developed ‘from scratch’ by an IS professional to suit the business
requirements of the application.
Off-the-shelf purchase: An acquisition method that involves direct purchase of a pre-written application
used by more than one company.
User-developed software: Software written by non-IS professionals i.e. the business users.
Enterprise application integration (EAI): Software used to facilitate communication between business
applications including data transfer and control.
Initiation phase: The startup phase in an IS development project. Its aims are to establish whether the
project is feasible and then prepare to ensure the project is successful.
Initiation phase context:
Input: creative thought and/or systematic evaluation of IS needs
Output: idea for initiation of a new information system
Feasibility assessment: An activity at the start of a project to ensure that the project is a viable business
proposition. The feasibility report analyses the need for and impact of the system and considers different
alternatives for acquiring software.
Feasibility assessment content:
Input: idea for initiation of a new information system
Output: feasibility report and recommendation to proceed
Systems analysis: The capture of the business requirements of a system from talking to or observing
end-users and using other information sources such as existing system documentation. Defines what
the system will do.
Systems analysis context: Input: terms of reference in feasibility report describing outline
requirements
Output: detailed requirements specification summarising systems
functions
Supported by diagrams showing the information flow and processes that are required.
Systems design: Define how the system will work in key areas of user interface, program modules,
security and database structure and transactions.
Systems design context:
Input: requirement specification
Output: detailed design specification
System build: Describes the creation of software by programmers. It involves writing the software code
(programming), building release versions of the software, constructing and populating the database and
testing by programmers and end-users. Writing of documentation and training may also occur at this
stage.
System build context:
Input: requirements and design specification
Output: working software, user guides and system documentation
System implementation: Involves the transition or changeover from the old system to the new and the
preparation for this such as making sure the hardware and network infrastructure for a new system are
in place; testing of the systems; and also human issues of how best to educate and train staff who will
be using or affected by the new system.
System implementation context: Input: working system, not tested by users
Output: signed-off, operational information system installed in all
locations
Post-implementations review: A meeting that occurs after a system is operational to review the success
of the project and learn lessons for the future.
Rapid application development (RAD): A method of developing information systems which uses
prototyping to achieve user involvement and faster development.
Prototyping: A prototype is a preliminary version of part of a framework of all of an information system
which can be reviewed by end-users. Prototyping is an iterative process where users suggest
modifications before further prototypes and the final information system is built.
Spiral model: An iterative systems development in which the stages of analysis, design, code and
review repeat as new features.
Lean software development: Lean software development is an approach to software development
where software is developed and deployed in small and useful feature sets which work incrementally.
Dynamic Systems Development Method (DSDM): A methodology that describes how RAD can be
approached. The latest version is named DSDM Atern
1.
How and why is information systems acquired?
Organisation spend significant sums on information systems
Organisation’s business strategy will determine where business is going and why
Creates ‘demand’ for information and applications software that can provide it
Need to acquire, implement and manage applications – reason for software acquisition process
3 alternatives available to organisation to acquire software: bespoke development, off-the-shelf
and user-developed
1.1
Bespoke development
System developed from ‘scratch’ by IS professionals
IS professionals either work for the business (in-house development) or for third party
(outsourced)
Benefits: - producing sow tailored to precise requirements of business
- may confer competitive advantage since competitor organisations do not have same
software solution
Difficulties - Expense: most expensive way of developing new information system
- Time: notorious for time overruns
- Quality: not usually free from bugs
1.2
Purchasing ‘off-the-shelf’ software
AKA as packaged software
Is indirect purchase of pre-written application used by more than 1 company
Written to offer broad functionality that will suit wide range of different businesses
Disadvantages:
- May offer too many features for any particular business - feel they pay for features not
used
- May force business to process information in a way they do not usually do business
- May not offer sufficient features
Benefits:
- Low cost when compared with bespoke systems
- Less likely to suffer from bugs that afflict bespoke systems
Tailored off-the-shelf package = pre-written software purchased from supplier, but can be
configured to be specific to company by changing software code
Component off-the-shelf package = different modules may be purchased from different
suppliers and built together
1.3
User-developed software
Written by non-professionals i.e. business users
Enterprise resource planning/institutional applications = those that affect general corporate
activities, cut across more than 1 department/functional area
End-user applications = may be departmental or personal; usually output-/report-orientated
Benefits: - normally used by those who develop it - requirements not subject to mistranslation
Disadvantages: - inappropriate software development tools might be used
- may be full of bugs due to corner-cutting
1.4
Factors affecting software acquisition
3 critical factors: time, cost and quality
Different acquisition options have different strengths when considered in terms of critical
factors (see table below)
Acquisition option
Delivery
Cost
Quality: bugs Quality: fits
time
business needs
Bespoke in-house
Poor
Poor
Poor
Good
Bespoke software house Good
Very poor
Medium
Medium
End-user development
Poor
Medium
Poor
Good
Tailored - off-the-shelf
Good
Good
Good
Medium
Standard - off-the-shelf
Very good Very good Very good
Poor
Other factors affecting software acquisition:
- Organisation size
- In-house IS/IT expertise
- Complexity of the required information system
- Uniqueness of business or business area to be supported
- IS/IT expertise among end-users
- Linkages with existing applications software
2.
Software acquisition and the systems development lifecycle
SDLC approach recognises that systems are developed in a series of steps or phases and
each phase needs to be completed before the next one can start
Example of waterfall model
2.1
Initiation
AKA startup phase
First phase in SDLC
Aims to establish whether project is feasible and then prepare to ensure project is successful
Context - Input: creative thought and/or systematic evaluation of IS needs
- Output: idea for initiation of a new information system
Contains the stimulus from which the need to develop new BIS arises
Stimulus can be internal or external
Source of initiation process may be:
- Managing director or other senior management
- Information systems department
- Functional business area
2.2
Feasibility assessment
Ensure that project is viable business proposition
Feasibility report analyses need for and impact of system and considers different alternatives
of acquiring software
Context - Input: idea for initiation of a new information system
- Output: feasibility report and recommendation to proceed
3 criteria used to determine feasibility of information system:
1) technically feasible - technology exist or can be created to support required system
2) economically feasible - it must generate more benefits than the cost needed to
produce it
3) operationally and organisationally feasible
operationally: system must be capable of performing within required speed,
volume, usability and reliability parameters
organisationally: proposed information system must either be capable of running
alongside work patterns or existing work patterns must be
capable of being adapted or re-engineered to run alongside
new information system
2.3
Systems analysis
Capture of business requirements
Context - Input: terms of reference in feasibility report describing outline requirements
- Output: detailed requirements specification summarising systems functions
Once system showed to be feasible it is necessary to carry out detailed work of assessing
precise requirements that intended users have for new system
3 main tasks:
1) gain understanding of how current information system works
2) diagrammatic model of current system workings is produced to ensure IT
professionals and systems users agrees
3) set of requirements for new information system is produced
Requirements specification will define:
- featured that new system is required to contain
- scope of system under consideration
- intended users of new system
- system performance standards
- environment requirements
2.4
Systems design
Defines how system will work in key areas of user interface, program modules, security and
database transactions
Context - Input: requirement specification
- Output: detailed design specification
Task of systems design - convert requirements into a number of design alternatives - select best
Deal with matters such as:
- choosing appropriate database management system
- establishing general systems security standards
- deciding on methods of system navigation
- general standards for printed report production
- screen design standards for input and output
- data capture requirements
- data storage requirements
2.5
Systems build
Creation of software by programmers
Involves writing software code (programming), building release versions of software, constructing
and populating database and testing by programmers and end-users
Writing of documentation and training may also occur
Context: - Input: requirements and design specification
- Output: working software, user guides and system documentation
3 substeps: physical database construction, programming and testing
2.6
Systems implementations and changeover
Covers practical issues such as making sure hardware and network infrastructure for new system
are in place, testing of the system and human issues on how best to educate and train
staff who will be using or affected by new system
Also involves transition or change-over from old to new system
Context - Input: working system, not tested by users
- Output: signed-off, operational information system installed in all locations
Implementation had difficulties
Data converted from old information system or directly entered into new database
New system will become operational directly, in phases or after period of parallel running
2.7
Review and maintenance
Inevitable that changes will be required over time
2 different types of maintenance:
- unproductive maintenance - stems from errors or oversights in original systems
development
- addition of new features and facilities that extent scope and functionality of system
Must also undertake post-implementation review
3.
Bespoke development
Project failures implied that traditional structured methodologies such as SDLC have tendency to
deliver systems that arrive too late and do not meet their original requirements
Traditional methods can fail in number of ways:
- gap of understanding between users and developers
- tendency of developers to isolate themselves from users
- quality measured by closeness of product to specification
- long development times
- business needs change during the development process
- what users get isn’t necessarily what they want
Possible solution = rapid applications development (RAD)
RAD uses prototyping to involve users and increase development speed
Role of prototyping within SDLC:
3.1
Spiral model
Iterative systems development model
Developed in recognition of fact that systems development projects tend to repeat stages of
analysis, design and code as part of prototyping process
Four main activities:
1) planning - setting project objectives, defining alternatives
2) risk analysis - analysis or alternatives and identification and solution of risks
3) engineering - equivalent to build phase of SDLC with coding and testing
4) customer evaluation - testing of product by customers
3.2
Agile and lean software development
Lean software development - emphasises incremental approach to software development where
software is developed and deployed in small and useful feature sets which work incrementally
7 principles of lean software development:
1) eliminate waste
2) create knowledge
3) build quality in
4) defer commitment
5) deliver fast
6) respect people
7) improve the system
Agile software related to software engineering aspects of systems development
Encompasses a number of agile software development methods:
- Adaptive software development (ASD)
- Agile unified process (AUP)
- Scrum
- Dynamic systems development methodology (DSDM)
AUP has 4 phases in development cycle:
1) Inception
2) Elaboration
3) Construction
4) Transition
3.3
Dynamic Systems Development Methodology (DSDM)
9 key principles of DSDM:
1) Active user involvement is imperative
2) DSDM teams must be empowered to make decisions
3) The focus is on frequent delivery of products
4) Fitness for business purpose is the essential criterion for acceptance of deliveries
5) Iterative and incremental development is necessary to converge on an accurate
business solution
6) All changes during development are reversible
7) Requirements are baselined at a high level
8) Testing is integrated throughout the lifecycle
9) A collaborative and co-operative approach between all stakeholders is essential
4.
Purchase of off-the-shelf package
4.1
Software selection criteria for packaged software
Primary drivers - those that form a set of essential requirements, which if not met, means that
software solution will not be suitable for organisation
Primary drivers in descending order of importance:
- Features: software features and functionality of package
- Technology: compatibility of solution under consideration with existing hardware,
operating systems, database management systems, Internet, networking and ecommerce setups
- Support and services: support for day-to-day operational requirements
- Cost: different vendors have different approaches to pricing
- Customisation: organisation will want to make small changes
5.
User-developed applications
Should be develop in line with steps in bespoke development process
Main difference: end-user-developed applications (EUDA) usually smaller scale
Tools and techniques associate with bespoke development still have role in end-userdeveloped information systems
Steps is waterfall model:
- Initiation: stimulus come from personal or departmental requirement
systems may be standalone or use databases and database extracts from
corporate information systems and manipulate data in order to
produce information not previously made available
- Feasibility: user must be sure that necessary and appropriate end-user development
tools exist or can be acquired to proceed with development
analyse cost involved - needs to be justified on economic grounds
- Analysis: no need to present information system requirements to IS/IT specialist
reduces risk of mistranslating information system requirements and increase
probability that developed system is what user actually wants
- Design: EUDA have a tendency to be developed more on trial and error basis than
through formal design techniques
if it works well = faster development of application software
poor design may result in a system that at best does not work quite as it
should and at worst a system may actually results in incorrect information
being produced
- Build: much easier for end-user to build systems as inexpensive development tools
(e.g. Visual Basic for PC) becomes more available
- Implementation/changeover: less critical than with company-wide information system
data gathered locally or extracted from central databases
- Maintenance and review: all software has to be maintained in some way
maintenance could be more problematic with EUDA as
development is often not documented