info 503lecture #101 introduction to information systems analysis systems operations and support...

INFO 503 Lecture #10 1

Introduction to InformationSystems Analysis

Systems Operations and SupportReview

INFO 503

Glenn Booker


Operations vs. Support

• Most systems spend the vast majority of their existence in the operations and support phase; sort of like people’s 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)


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


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)


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)


System Maintenance

• Validate the Problem

• Benchmark Program

• Study and Debug the Program

• Test the Program


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 user’s system

* Notice that this requires the problem report has enough detail to re-create the problem


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


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


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


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


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 didn’t break the old program)– Integration and system testing to make sure

the changes don’t interfere with each other


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 didn’t compromise the previous system


Update Documentation

• 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

Added step not in the book!


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


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


Technical Support

• System support may also include– Monitoring system performance and activity– Staffing a help desk for end users– Supplementing or clarifying the user’s

documentation and/or training– Measuring customer satisfaction (surveys)– Recording ideas for system improvements– Recording reported problems


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


System Enhancement

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


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)



• 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)



• 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


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


Recover Existing Physical Systems

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


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)


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!


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



• 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



• Three methods may be used to re-engineer a system’s 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


The End is Near!


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!


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


FAST Methodology Phases

1. Scope Definition

2. Problem Analysis

3. Requirements Analysis

4. Logical Design

5. Decision Analysis

(Procurement Phase)

6. Physical Design & Integration

7. Construction & Testing

8. Installation & Delivery

System Operations & Support

Beware that phase numbering is inconsistent in the 6th edition of text.


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


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


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


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


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


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


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


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


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


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)


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• Don’t be afraid to write if you have

any questions!

info 503lecture #101 introduction to information systems analysis systems operations and support...

Documents

system changes

system existslecture

system knowledge

system functions

system maintenancevalidate

system bugs

users system

production system