INFO 503Lecture #101 Introduction to Information Systems Analysis Systems Operations and Support Review INFO 503 Glenn Booker

INFO 503Lecture #102 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)

INFO 503Lecture #103 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

INFO 503Lecture #104 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)

INFO 503Lecture #105 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)

INFO 503Lecture #106 System Maintenance Validate the Problem Benchmark Program Study and Debug the Program Test the Program

INFO 503Lecture #107 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 the problem 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

INFO 503Lecture #108 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

INFO 503Lecture #109 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

INFO 503Lecture #1010 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

INFO 503Lecture #1011 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

INFO 503Lecture #1012 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

INFO 503Lecture #1013 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

INFO 503Lecture #1014 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!

INFO 503Lecture #1015 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

INFO 503Lecture #1016 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

INFO 503Lecture #1017 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

INFO 503Lecture #1018 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

INFO 503Lecture #1019 System Enhancement Three major tasks for enhancing or re-engineering a system –Analyze Enhancement Request –Make the Quick Fix –Recover Existing Physical Systems

INFO 503Lecture #1020 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)

INFO 503Lecture #1021 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)

INFO 503Lecture #1022 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

INFO 503Lecture #1023 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

INFO 503Lecture #1024 Recover Existing Physical Systems Consists of various possible tasks, usually along these lines –Database Recovery –Program Analysis & Recovery

INFO 503Lecture #1025 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)

INFO 503Lecture #1026 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!

INFO 503Lecture #1027 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

INFO 503Lecture #1028 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

INFO 503Lecture #1029 Program Analysis & Recovery 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

INFO 503Lecture #1030 The End is Near!

INFO 503Lecture #1031 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 503Lecture #1032 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

INFO 503Lecture #1033 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 6 th edition of text.

INFO 503Lecture #1034 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

INFO 503Lecture #1035 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

INFO 503Lecture #1036 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

INFO 503Lecture #1037 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

INFO 503Lecture #1038 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

INFO 503Lecture #1039 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

INFO 503Lecture #1040 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

INFO 503Lecture #1041 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

INFO 503Lecture #1042 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

INFO 503Lecture #1043 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)

INFO 503Lecture #1044 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!