Systems Analysis II Making the system operational

1
Systems Analysis IIMaking the system operational

• INFO 355
• Glenn Booker

2
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

3
Implementation and Deployment

• Now outline the activities in the last two core
  processes
• Build, test, integrate system components
• Complete system tests, deploy solution
• We wont focus on the actual building of system
  components (see INFO 15x courses for that)

4
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

5
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

6
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!

7
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

8
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

9
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

10
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

11
Regression testing

• Not mentioned in the book, but iterative
  development also depends heavily on regression
  testing
• Makes sure that new functionality didnt break
  stuff that worked before!
• Is repeated at the end of every iteration on
  functions implemented in all previous iterations

12
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

13
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

14
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

15
User Acceptance Testing (UAT)

• Done at the end of system testing
• User tests system to see if it fulfills the
  requirements defined in the projects RFP and
  contract
• Successful UAT results in payment and approval
  for deployment of the system

16
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 weve reached the end of
  the SDLC

17
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

18
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

19
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.

20
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 theyll forget everything

21
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

22
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

23
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

24
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

25
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

26
Deployment approaches

• Before deployment youre at point A the old
  system does everything
• At some point youll 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

27
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

28
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

29
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

30
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

31
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

32
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

33
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

34
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

35
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