INFO 355 Week #9 1

Systems Analysis IIMaking the system operational

INFO 355Glenn Booker

Implementation and Deployment

Most of this course has focused on two middle ‘core processes’ of the SDLC 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

INFO 355 Week #9 2

Implementation and Deployment

Now outline the activities in the last two core processes 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)

INFO 355 Week #9 3

Testing

Testing helps to determine if a component, subsystem, or system works as intended and whether it contains any defects

Based on the functional and non-functional requirements of the system, testing helps uncover defects

INFO 355 Week #9 4

Testing

Types of testing include: Unit Integration Usability Regression System and stress

For each test, define test cases Starting state Events which take place Response or ending state

INFO 355 Week #9 5

Testing

Test data must be defined as well; could be 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!

INFO 355 Week #9 6

Unit testing

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

INFO 355 Week #9 7

Integration testing

Tests a group of related methods, classes, or components

Checks interfaces between units, parameter values, looks for run-time exceptions, and unexpected interactions

Trace problems to a unit and fix

INFO 355 Week #9 8

Integration testing

OO issues in integration testing can include Which method called the defective

method? Inherited methods and variables Dynamic choice of method used based

on inputs Retained data values between method

calls

INFO 355 Week #9 9

Usability testing

Determine if a method, class, component, subsystem, or system meets user requirements

Often based on user interface assessment Does the system work? Is it easy to use? If not, why?

May be repeated often during development

INFO 355 Week #9 10

Regression testing

Not mentioned in the book, but iterative development also depends heavily on regression testing 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

INFO 355 Week #9 11

System Testing

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

INFO 355 Week #9 12

Performance testing

A performance or stress test checks for non-functional requirements such as throughput, response time, capacity, etc. Often need large data sets or many

simulated system users Look for performance bottlenecks or

inadequate hardware

INFO 355 Week #9 13

Performance testing

Fixing problems in performance testing can be challenging Fix or re-implement software Replace or reconfigure hardware or

network equipment Upgrade or replace inadequate

components

INFO 355 Week #9 14

User Acceptance Testing (UAT)

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

INFO 355 Week #9 15

Deployment activities

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

INFO 355 Week #9 16

Converting and initializing data

One major activity is getting preexisting data into the system 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

INFO 355 Week #9 17

Converting and initializing data

Might have to 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

INFO 355 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 End users and system operators may

have very different skills and perform different functions

Need to define training scope, goals, materials, format, etc.

INFO 355 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 Train the trainer

Timing of training is key – not too long before system deployment or they’ll forget everything

INFO 355 Week #9 20

Documentation

Related to training, system documentation is generally needed User manuals System description Debugging and maintenance guide

Need to write documentation to the intended audience Level of computer skills, education Terminology known

INFO 355 Week #9 21

Configure production environment

Before system software can be installed, the backbone of the system must be assembled and tested Servers, routers, firewalls, etc. Install operating systems and other

support software Often maintain a production system

and a test (sandbox) system

INFO 355 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 What do you implement first? This feeds the iteration plan

INFO 355 Week #9 23

Development order

Three common approaches for deciding the implementation order 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

INFO 355 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) Controls check in and check out of code

and documentation

INFO 355 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? Choose a deployment approach

INFO 355 Week #9 26

Deployment approaches

Direct deployment (immediate cutover) has minimal time where both systems are in use – days or a few weeks Simple but risky No fallback position if new system fails

INFO 355 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 Less risk but higher cost Good when system failure is very

expensive or dangerous

INFO 355 Week #9 28

Deployment approaches

Phased deployment implements new system functionality in specific phases, e.g. 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

INFO 355 Week #9 29

Change and version control

Throughout system development and deployment, need processes in place to manage change and version control Part of configuration management (CM)

Versioning keeps track of exactly what went into each version of the system

INFO 355 Week #9 30

Versioning

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

INFO 355 Week #9 31

Versioning

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

INFO 355 Week #9 32

Versioning

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

INFO 355 Week #9 33

Change control processes

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

INFO 355 Week #9 34

Change control processes

Key change control ideas include 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

INFO 355 Week #9 35