Introduction to Information Systems Analysis Systems Operations and Support Review

1
Introduction to InformationSystems
AnalysisSystems Operations and SupportReview

• INFO 503
• Glenn Booker

2
Operations vs. Support

• Most systems spend the vast majority of their
  existence in the operations and support phase
  sort of like peoples adulthood
• Operations is the routine use of a system to
  perform business functions
• A system used for operations is an operational or
  production system (? operating system)

3
Systems Support

• Support includes providing user help, fixing
  system bugs, and adding new features (our main
  focus here)
• Systems support covers the maintenance and
  improvement of a system after its initial
  operational use
• Its success depends heavily on the level of
  control established early in support

4
Data Supporting Support

• Systems require various types of data to manage
  their lives
• Repository system knowledge, models, and
  documentation
• Program Library system software (off-the-shelf
  software, libraries, and custom code)
• Business Data data records contained in the
  system (the reason the system exists)

5
Types of System Support

• Four major types of support activities, p. 739
  (579), often occur simultaneously
• System Maintenance (correct errors)
• System Recovery from failures
• Technical Support for system users
• System Enhancement (add new requirements)

6
System Maintenance

• Validate the Problem
• Benchmark Program
• Study and Debug the Program
• Test the Program

7
Validate the Problem

• A.k.a. before-modification testing, problem
  validation testing, or problem re-creation
• Try to re-create the problem - copy the inputs
  and commands used when theproblem occurred
• May require reconfiguring the hardware and/or
  software to match users system

Notice that this requires the problem report
has enough detail to re-create the problem
8
Validate the Problem

• Tries to keep rare or unique problems from
  wasting developers time...
• Results in a validated problem or an invalidated
  problem
• Networking problems are notoriously hard to
  re-create some cases may require extensive
  diagnostics to trap the bug

9
Benchmark Program

• Establish what is normal behavior and performance
  of the system
• May use the test cases developed to prove the
  system was ready for operational use may also
  use automated testing tools
• Keep a set of predefined baseline inputs and
  expected outputs to prove system functions
  normally, used for regression tests

10
Study and Debug the Program

• In order to fix the system, you must know the
  system extremely well!
• This is supported by well maintained system
  documentation (including well commented code) and
  clearly defined change control
• Dead or poorly structured code can make this
  extra challenging

11
Study and Debug the Program

• Now solve the validated problems by determining
  what system changes are needed to fix them
• During this task, the programmer analyzes the
  problem and determines a candidate solution

12
Test the Program

• Like small scale development effort, the
  candidate solution is tested
• Includes unit testing of the solution
• Regression testing against the benchmark test
  cases (ensure we didnt break the old program)
• Integration and system testing to make sure the
  changes dont interfere with each other

13
Test the Program

• Changes to code are managed using version control
  software, so if a fix produces unexpected
  problems, you can revert back (or roll back) to
  an older version of code
• When done, system-level testing should be able to
  prove that the fix keeps the original problem
  from occurring again and didnt compromise the
  previous system

14
Update Documentation
Added step not in the book!

• Changes to fix system problems may result in
  updates to system design documentation, source
  code comments, user manual changes, etc.
• May also need to define, implement, and test the
  means for installing the fix (e.g. give detailed
  instructions), and proving the installation was
  successful

15
System Recovery

• System recovery assistance may be needed if a
  user crashes or hangs the system (e.g. ABEND,
  for abnormal end)
• May only involve one or two simple commands
• May need system administrator to kill a wayward
  process, reboot the system (IPL), or guide the
  user through isolating the part of the system
  which is causing the hang

ABEND and IPL are terms from IBM, now widely
used
16
System Recovery

• After recovery, user may need help to
• Get back to a familiar system state
• Help keep user from making the same mistake
  again
• Trap key problem data and report the problem
• Help recover lost or corrupted data
  (transactions)
• Get someone to fix a hardware problem

17
Technical Support

• System support may also include
• Monitoring system performance and activity
• Staffing a help desk for end users
• Supplementing or clarifying the users
  documentation and/or training
• Measuring customer satisfaction (surveys)
• Recording ideas for system improvements
• Recording reported problems

18
System Enhancement

• Requirements evolve for most systems
• Minor changes can be handled in conjunction with
  the process for fixing bugs
• Major changes may require a significant new
  project to revamp the system
• All possible changes require analysis to
  determine if you really want to do them

19
System Enhancement

• Three major tasks for enhancing or
  re-engineering a system
• Analyze Enhancement Request
• Make the Quick Fix
• Recover Existing Physical Systems

20
Analyze Enhancement Request

• Enhancements may come from
• New business problems, which make existing system
  unusable or ineffective
• New business requirements, such as new reports or
  features desired
• New technical requirements (upgrades)
• New design requirements (improve existing
  features through redesign)

21
Analyze Enhancement Request

• New business problems may require redoing problem
  analysis (then the remaining life cycle)
• New business requirements may require
  re-analyzing the system (ditto)
• New technical requirements may require decision
  analysis, then re-designing the system (ditto)
• New design requirements may require re-designing
  the system (ditto)

22
Analyze Enhancement Request

• Screen requests to
• Determine if they are well defined, unique
  enhancements (not already suggested)
• Determine the parts of the system affected
• Estimate the scope to implement (cost, time,
  number of people needed)
• Determine the priority of the enhancement

23
Make the Quick Fix

• Many enhancements can be implemented via simple
  new programs
• Simple means no new or revised data structures
  are needed
• May include minor business process changes
• Generally includes new reports or other output
  which affect only a small portion of the system
• New code may be stored and managed locally, is
  not shared with the system

24
Recover Existing Physical Systems

• Consists of various possible tasks, usually along
  these lines
• Database Recovery
• Program Analysis Recovery

25
Database Recovery

• May need to convert flat files to relational or
  object-oriented files (re-engineering)
• Corruption or loss of existing data is a major
  risk
• Need to analyze the existing structure and map
  how each field is going to appear in the new
  system (if at all)

26
Database Recovery

• Then processes must change to use the new
  structures
• Data, process, and network models will also
  change to suit the new order
• Some CASE tools support this type of work, or it
  may be done manually
• Validate conversions carefully before use!

27
Program Analysis Recovery

• An existing system may be analyzed to determine
  if it needs to be re-engineered
• Cost of existing maintenance activities is one
  factor
• Can measure the existing system to determine if
  it is too complex to be easily maintained

28
Program Analysis Recovery

• Software complexity measures can include
• Measures of complexity within each module, like
  cyclomatic complexity, knots in the control
  flow, or number of lines of code
• Complexity between modules
• fan in - how many modules call this module
• fan out - number of other modules called by
  this module
• See INFO 630 for lots of measures

29
Program Analysis Recovery

• Three methods may be used to re-engineer a
  systems code
• Code reorganization breaks modules into new
  pieces or merges them to reduce complexity
• Code conversion translates code from one language
  to another (e.g. Cobol to C)
• Code slicing extracts parts of a module to become
  a new module

30
The End is Near!
31
System Obsolescence

• A system may become obsolete when
• Its operations and support costs become too high
• It can no longer solve major business problems
• It can not fulfill major requirements
• At this point a new project is proposed to
  replace the obsolete system, and we start the
  FAST model all over again!

32
INFO 503 Course Review

• The course has been based on the FAST model which
  is unique to the text (but based on commonly
  accepted principles and activities)
• It captures the major activities needed for
  information system analysis and design

33
FAST Methodology Phases

• Scope Definition
• Problem Analysis
• Requirements Analysis
• Logical Design
• Decision Analysis
• (Procurement Phase)

• 6. Physical Design Integration
• Construction Testing
• Installation Delivery
• System Operations Support

Beware that phase numbering is inconsistent in
the 6th edition of text.
34
Scope Definition (Study) Phase

• 1.1 Identify baseline problems and opportunities
• 1.2 Negotiate baseline scope (may be concurrent
  with 1.1)
• 1.3 Assess baseline project worthiness
• 1.4 Develop baseline schedule and budget
• 1.5 Communicate the project plan

35
Problem Analysis (Study) Phase

• 2.1 Understand the problem domain
• 2.2 Analyze problems and opportunities
• 2.3 Analyze business processes (BPR only)
• 2.4 Establish system improvement objectives
• 2.5 Update or refine the project plan
• 2.6 Communicate findings and recommendations

36
Requirements Analysis (Definition) Phase

• 3.1 Identify and express system requirements
• 3.2 Prioritize system requirements
• 3.3 Update or refine the project plan
• 3.4 Communicate the requirements statement

37
Logical Design Phase

• 4.1a Structure functional requirements and/or
• 4.1b Prototype functional requirements
• 4.2 Validate functional requirements
• 4.3 Define acceptance test cases

38
Decision Analysis (Configuration) Phase

• Decision analysis phase identifies candidate
  configurations, and picks the best one
• Activities are
• 5.1 Identify Candidate Solutions
• 5.2 Analyze Candidate Solutions
• 5.3 Compare Candidate Solutions
• 5.4 Update the Project Plan
• 5.5 Recommend a System Solution

39
Procurement Phase

• New tasks for the Procurement phase are
• 4.1 Research Technical Criteria and Options
• 4.2 Solicit Proposals from Vendors
• Revised Decision Analysis phase tasks
• 5A.1 Validate Vendor Claims and Performance
• 5A.2 Evaluate and Rank Vendor Proposals
• 5A.3 Award Contract and Debrief Vendors

40
Physical Design Integration Phase

• This phase bridges the gulf between the user
  requirements and the builders input needs
• 6.1 Design the Application Architecture
• 6.2 Design the System Database
• 6.3 Design the System Interface
• 6.4 Package Design Specifications
• 6.5 Update Project Plan

41
Construction Phase

• The Construction phase covers building and
  testing the actual system, and has four tasks
• 7.1 Build and Test Networks (if needed)
• 7.2 Build and Test Databases
• 7.3 Install and Test New Software Packages (if
  needed)
• 7.4 Write and Test New Programs

42
Implementation Phase

• The implementation and delivery phase consists of
  five not-very-sequential tasks
• 8.1 Conduct System Test
• 8.2 Prepare Conversion Plan
• 8.3 Install Databases
• 8.4 Train System Users
• 8.5 Convert to New System

43
System Operations Support

• Four major types of support activities, often
  occur simultaneously
• System Maintenance (correct errors)
• System Recovery from failures
• Technical Support for system users
• System Enhancement (add new requirements)

44
Where to go from here?

• Look out for steps missed vs. done poorly
• Stay tuned to the SEI and STSC web sites for
  current research
• Study programming and/or networking as your
  interests dictate
• My web site will be active indefinitely
• Dont be afraid to write if you have any
  questions!