System build, implementation and maintenance

1
Chapter 12

• System build, implementation and maintenance

2
Learning objectives

• After this lecture, you will be able to
• state the purpose of the build phase, and its
  difference from changeover and implementation
• specify the different types of testing required
  for a system
• select the best alternatives for changing from an
  old system to a new system
• recognise the importance of managing both
  organisational change and software change
  associated with introduction of a new BIS.

3
Management issues

• From a managerial perspective, this chapter
  addresses the following questions
• How should the system be tested?
• How should data be migrated from the old system
  to the new system?
• How should the changeover between old and new
  systems be managed?

4
System build and implementation

• System build The creation of software by
  programmers involving programming, building
  release versions of the software and testing by
  programmers and end-users. Writing of
  documentation and training may also occur at this
  stage.
• 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 system and
  also human issues of how best to educate and
  train staff who will be using or will be affected
  by the new system.
• Changeover The period of migration from existing
  systems to a new system.

5
Software quality

• The quality of software is dependent on two key
  factors
• the number of errors or bugs in the software
• the suitability of the software to its intended
  purpose, i.e. does it have the features
• identified by users which are in the
  requirements specification?

6
Examples of source of
introducing errors
7
Ideal proportions of time for
different project phases
8
Data migration

• Data migration Data migration is the transfer of
  data from the old system to the new system. When
  data are added to a database, this is known as
  populating the database.
• Import and export Data can be exported from an
  old system and then imported into a new system.

9
Testing

• Test specification A detailed description of the
  tests that will be performed to check that the
  software works correctly.
• Test plan Plan describing the type and sequence
  of testing and who will conduct it.

10
Figure 12.1 The V-model of systems development
relating analysis and design activities to
testing activities
11
Types of testing

• Module or unit testing Individual modules are
  tested to ensure that they function correctly for
  given inputs.
• System testing When all modules have been
  completed and their interactions assessed for
  validity, links between all modules are assessed
  in the system test. In system testing,
  interactions between all relevant modules are
  tested systematically.
• Volume testing Testing assesses how system
  performance will change at different levels of
  usage.
• Regression testing Testing performed before a
  release to ensure that the software performance
  is consistent with previous test results, i.e.
  that the outputs produced are consistent with
  previous releases of the software.
• Functional testing Testing of particular
  functions or modules either following a test
  script or working through the module
  systematically.
• Multi-user testing The effect of different users
  accessing the same customer or stock record is
  tested. Software should not permit two users to
  modify the same data at the same time.
• User acceptance testing This is the final stage
  of testing which occurs before the software is
  signed off as fit for purpose and the system can
  go live.

12
Changeover

• Test environment A specially configured
  environment (hardware, software and office
  environment) used to test the software before its
  release.
• Live (production) environment The term used to
  described the setup of the system (hardware,
  software and office environment) where the
  software will be used in the business.

13
Introducing test versions

• Configuration management Procedures that define
  the process of building a version of the software
  from its constituent program files and data
  files.
• Alpha release Alpha releases are preliminary
  versions of the software released early in the
  build process. They usually have the majority of
  the functionality of the system in place, but may
  suffer from extensive bugs.
• Alpha testing The purpose of alpha testing is
  to identify bugs and any major problems with the
  functionality and usability of the software.
  Alpha testing is usually conducted by staff
  inside the organisation developing the software
  or by favoured customers.
• Beta release Beta releases occur after alpha
  testing and have almost complete functionality
  and relatively few bugs.
• Change (modification) requests A modification to
  the software thought to be necessary by the
  business users or developers.

14
Figure 12.2 Alternative changeover methods for
system implementation
15
Assessing different
changeover methods
Method

Main advantages

Main disadvantages

Immediate cutover

Rapid, lowest cost

High risk if serious errors in system

Parallel running

Lower risk than immediate

Slower and higher cost than immediate


cutover

cutover

Phased implementation

Good compromise bet
ween

Difficult to achieve technically due to


immediate cutover and

interdependencies between modules


parallel running

Pilot system

Essential for multinational

Has to be used in combination


or national rollouts

with the other methods

16
Business-level change

• Business process management
• An approach supported by software tools intended
  to increase process efficiency by improving
  information flows between people as they perform
  business tasks.
• Incremental change
• Relatively small adjustments required by an
  organisation in response to their business
  environment.
• Discontinuous change
• Change involving a major transformation in an
  industry.

17
BPM according to Gartner (2003)

• BPM is a methodology, as well a collection of
  tools that enables enterprises to specify
  step-by-step business processes. Proper analysis
  and design of BPM flows require a strong
  understanding of the atomic business steps that
  must be performed to complete a business process.
  As BPM executes a business process, these atomic
  steps will often correspond to well-known
  business activities, such as checking credit
  ratings, updating customer accounts and checking
  inventory status. In effect, the BPM process flow
  is often just a sequence of well-known services,
  executed in a coordinated fashion.

18
Degrees of change

• Business process re-engineering (BPR)
• Identifying radical, new ways of carrying out
  business operations, often enabled by new IT
  capabilities
• Business process improvement (BPI)
• Optimizing existing processes typically coupled
  with enhancements in information technology.
• Business process automation (BPA)
• Automating existing ways of working manually
  through information technology.

19
Alternative terms for using IS
to enhance company performance
20
Achieving user involvement

• Non-involvement Here, users are unwilling to
  participate or are not invited to.
• Involvement by advice User advice is solicited
  through interviews or questionnaires during
  analysis.
• Involvement by signoff Users approve the results
  produced by the project team, such as
  requirements specifications.
• Involvement by design team membership Active
  participation occurs in analysis and design
  activities (including interviews of other users,
  creation of functional specifications and
  prototyping).
• Involvement by project team membership User
  participation occurs throughout the project since
  the user manages and owns the project.

21
Types of involvement

• System sponsors System sponsors are senior
  managers or board members who are responsible for
  a system at a senior level in a company.
• System owners These are managers who are
  directly responsible for the operational use of a
  system.
• Stakeholders All staff who have a direct
  interest in the system.

22
Figure 12.3 Transition curve showing reaction of
staff through time from when change is first
suggested
23
Resistance to change forms

• aggression in which there may be physical
  sabotage of the system, deliberate entry of
  erroneous data or abuse of systems staff
• projection where the system is wrongly blamed
  for difficulties encountered while using it
• avoidance withdrawal from or avoidance of
  interaction with the system, non-input of data,
  reports and enquiries ignored, or use of manual
  substitutes for the system.

24
Maintenance

• Maintenance Maintenance occurs after the system
  has been signed off as suitable for users. It
  involves reviewing the project and recording and
  acting on problems with the system.

25
Post-implementation review

• Post-implementation review A meeting that occurs
  after a system is operational to review the
  success of the project.
• The review could include the following
• faults and suggested enhancements with agreement
  on which need to be implemented in a future
  release
• success of system in meeting its budget and
  timescale targets
• success of system in meeting its business
  requirements has it delivered the anticipated
  benefits described in the feasibility study?
• development practices that worked well and poorly
  during the project.