Systems Analysis II Making the system operational - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

Systems Analysis II Making the system operational

Description:

Systems Analysis II Making the system operational INFO 355 Glenn Booker INFO 355 Week #9* – PowerPoint PPT presentation

Number of Views:98
Avg rating:3.0/5.0
Slides: 36
Provided by: glen1186
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com