Systems Analysis II
Making the system operational
INFO 355
Glenn Booker
INFO 355
Week #9
1
Implementation and Deployment

Most of this course has focused on two
middle ‘core processes’ of the SDLC






INFO 355
Identify problem and obtain approval
Plan and monitor the project
Discover and understand details
Design system components
Build, test, & integrate system
components
Complete system tests, deploy solution
Week #9
2
Implementation and Deployment

Now outline the activities in the last
two core processes



INFO 355
Build, test, & integrate system
components
Complete system tests, deploy solution
We won’t focus on the actual
building of system components
(see INFO 15x courses for that)
Week #9
3
Testing


INFO 355
Testing helps to determine if a
component, subsystem, or system
works as intended and whether it
contains any defects
Based on the functional and nonfunctional requirements of the
system, testing helps uncover
defects
Week #9
4
Testing

Types of testing include:






For each test, define test cases



INFO 355
Unit
Integration
Usability
Regression
System and stress
Starting state
Events which take place
Response or ending state
Week #9
5
Testing

Test data must be defined as well;
could be




INFO 355
Contrived data to test handling
extreme cases and errors
Data from typical normal fake inputs
Real data samples from the existing
system
Consider using testing automation
tools!
Week #9
6
Unit testing




INFO 355
Tests individual modules, functions,
classes, or components
Does this piece work in isolation?
May write a driver method to call
the target unit for various test case
input values
May have a stub to simulate code
not written yet
Week #9
7
Integration testing



INFO 355
Tests a group of related methods,
classes, or components
Checks interfaces between units,
parameter values, looks for runtime exceptions, and unexpected
interactions
Trace problems to a unit and fix
Week #9
8
Integration testing

OO issues in integration testing can
include




INFO 355
Which method called the defective
method?
Inherited methods and variables
Dynamic choice of method used based
on inputs
Retained data values between method
calls
Week #9
9
Usability testing


Determine if a method, class,
component, subsystem, or system
meets user requirements
Often based on user interface
assessment



INFO 355
Does the system work?
Is it easy to use? If not, why?
May be repeated often during
development
Week #9
10
Regression testing

Not mentioned in the book, but
iterative development also depends
heavily on regression testing


INFO 355
Makes sure that new functionality
didn’t break stuff that worked before!
Is repeated at the end of every
iteration on functions implemented in
all previous iterations
Week #9
11
System Testing



INFO 355
Tests the entire system or at least
an independent subsystem
Typically near the end of the project
(waterfall) or each iteration
During development, a daily or
frequent system test might be a
“build and smoke” test to look for
obvious problems
Week #9
12
Performance testing

A performance or stress test checks
for non-functional requirements
such as throughput, response time,
capacity, etc.


INFO 355
Often need large data sets or many
simulated system users
Look for performance bottlenecks or
inadequate hardware
Week #9
13
Performance testing

Fixing problems in performance
testing can be challenging



INFO 355
Fix or re-implement software
Replace or reconfigure hardware or
network equipment
Upgrade or replace inadequate
components
Week #9
14
User Acceptance Testing (UAT)



INFO 355
Done at the end of system testing
User tests system to see if it fulfills
the requirements defined in the
project’s RFP and contract
Successful UAT results in payment
and approval for deployment of the
system
Week #9
15
Deployment activities


INFO 355
Deployment takes the system from
the lab to the operational setting
where it will spend most of its life
By the end of deployment, the
system is fully operational (“live”)
for executing day-to-day business
functions, and we’ve reached the
end of the SDLC
Week #9
16
Converting and initializing data

One major activity is getting
preexisting data into the system


INFO 355
Sometimes called DCL (data conversion
and loading), it can be a major effort
all by itself
DCL might include data from a legacy
system, manual (paper) records that
have to be digitized, and data from
other related systems
Week #9
17
Converting and initializing data

Might have to





INFO 355
Restructure data from another
database
Convert a flat file database to relational
Normalize data
Modify or add tables & attributes
Or could reload the existing data,
often using some intermediate data
structure and import/export utilities
Week #9
18
Training users

All of the system actors may need
training specific to their needs and
the functions they use on the
system


INFO 355
End users and system operators may
have very different skills and perform
different functions
Need to define training scope, goals,
materials, format, etc.
Week #9
19
Training users


Training could be self-paced,
instructor-led, etc.
Very large scale systems may need
training for those who will train the
end users


INFO 355
Train the trainer
Timing of training is key – not too
long before system deployment or
they’ll forget everything
Week #9
20
Documentation

Related to training, system
documentation is generally needed




Need to write documentation to the
intended audience


INFO 355
User manuals
System description
Debugging and maintenance guide
Level of computer skills, education
Terminology known
Week #9
21
Configure production environment

Before system software can be
installed, the backbone of the
system must be assembled and
tested



INFO 355
Servers, routers, firewalls, etc.
Install operating systems and other
support software
Often maintain a production system
and a test (sandbox) system
Week #9
22
Planning & managing deployment


Those are the specific activities of
deployment
More generally, a plan needs to be
developed of the implementation,
testing, and deployment sequence


INFO 355
What do you implement first?
This feeds the iteration plan
Week #9
23
Development order

Three common approaches for
deciding the implementation order



INFO 355
IPO – develop Inputs first, then
Processing modules, then Outputs
Top down – start with the highest level
routine (Main?) then develop each
piece below that
Bottom up – opposite of top down!
Start with modules that call nothing
Week #9
24
Development order


Also consider customer needs,
project risks, staff utilization,
security, or other considerations
Use a source code control system
(SCCS, such as RCS)

INFO 355
Controls check in and check out of code
and documentation
Week #9
25
Deployment approaches



Before deployment you’re at point A
– the old system does everything
At some point you’ll be at point B –
the old system is gone, and the new
system does everything
How get from point A to point B?

INFO 355
Choose a deployment approach
Week #9
26
Deployment approaches

Direct deployment (immediate
cutover) has minimal time where
both systems are in use – days or a
few weeks


INFO 355
Simple but risky
No fallback position if new system fails
Week #9
27
Deployment approaches

Parallel deployment keeps both
systems running in parallel longer
(weeks to months) and new
functions are taken over by the new
system gradually


INFO 355
Less risk but higher cost
Good when system failure is very
expensive or dangerous
Week #9
28
Deployment approaches

Phased deployment implements
new system functionality in specific
phases, e.g.




INFO 355
Phase A cuts over manufacturing
processes
Phase B cuts over accounting processes
Phase C cuts over human resources
processes
Low risk but complex to manage
Week #9
29
Change and version control

Throughout system development
and deployment, need processes in
place to manage change and
version control


INFO 355
Part of configuration management (CM)
Versioning keeps track of exactly
what went into each version of the
system
Week #9
30
Versioning


INFO 355
Copies of the system released to
the customer (production
environment) might be a production
release, release version, or
production version
Minor production releases might be
called a maintenance release
Week #9
31
Versioning


INFO 355
Every file (source code, data, script,
documentation) needs to be tracked
over time so you know exactly
which version went into every
release
Need this for recreating bugs
Week #9
32
Versioning


INFO 355
As deployment nears, alpha
releases can go to favored
customers to get initial feedback,
bug reports, etc.
Later beta releases go to wider
distribution to check system
stability before production release
Week #9
33
Change control processes


INFO 355
With versioning, need a change
control process to assess possible
changes to the system before they
are implemented
For an FAA change control process
example, see here
Week #9
34
Change control processes

Key change control ideas include




INFO 355
Standard reporting methods for both
bug reports and new feature ideas
Systematic review of incoming reports
Planning and control over changes to
the system (estimate, plan, assign, fix,
test, approve)
Accommodation of normal and
emergency changes
Week #9
35