IMS 9001 — Systems Analysis and Design System

IMS 9001 - Systems Analysis and Design System implementation and maintenance 1

Implementation (Build) System Users § Build and deliver the system DESIGN User acceptance testing Technical Design Report User Documentation System Vendors Hardware/ Software Build, test, install and deliver the new system User Training Production System and Technical Documentation MAINTENANCE Project Report System Owners 2

Implementing the System § § § implementation planning Build and test software Build/modify databases, networks etc. finalise documentation prepare the site convert data into required form and media conduct training install system monitor system transition to maintenance mode post-implementation review 3

Systems Implementation IMPLEMENTATION PLANNING REVIEW FINALISE DOCUMENTATION REVIEW CONDUCT SYSTEM TESTING REVIEW CONDUCT ACCEPTANCE TESTING REVIEW OPERATIONS HANDOVER REVIEW Acceptance Checklist, Implementation Schedule, Training Schedule, Re-estimate Training Guides, User Manuals Test Data Preparation, System Test: Functional & Performance, Test Conversion Acceptance Test Computer Documents, I/O Documents, Operating Guide 4

Systems implementation cont. CONDUCT TRAINING GET SYSTEM READY FOR START-UP Distribute Manuals, Test Equipment, Conduct Training, Set up / Convert Files REVIEW CONDUCT SYSTSEM ACCEPTANCE System Installation, Monitor Operations, Secure Acceptance, Run Benchmark Tests, Tune System REVIEW WRAP UP REVIEW Hand over Technical Documentation, Post Implementation Review (What went wrong ? ) 5

Implementation Planning § Implementation stage of the project § requires a great deal of co-ordination with professionals outside the development team § Implementation plan § will have been developed at earlier stage of project § will need to be extended in greater detail § must be updated to reflect the current situation § Poor planning can cause significant delays in deadline! § Tasks § finalise acceptance checklist § complete and confirm training schedule § review and revise implementation plan 6

Finalise Documentation § Documentation describes how a system works to a wide audience The four main areas are: § Training documentation § used specifically during the training sessions § especially designed to put the novice user at ease § User documentation § tells users how to work with the system and perform their tasks § may be a user manual, on-line help, quick reference guide etc 7

Finalise documentation cont. § System documentation § a communications tool and to review and revise the system during development § also facilitates maintenance and enhancement of the system § Operations documentation § aimed at a centralised operations group (not on-line operators) § details what tasks an operator needs to carry out for a particular program 8

Testing is. . . § " the process of exercising or evaluating a system by manual or automatic means to verify that it satisfies specified requirements or to identify differences between expected and actual results " (IEEE, 1983) 9

Testing Steps § All testing involves the following steps: select what is to be measured by the test decide how it is to be tested develop the test cases determine the expected or correct results (you must ensure that expected results can be measured - vagueness does not encourage adequate testing) § execute the test cases § compare actual results to expected results § § 10

Stages of Testing Installation test User requirements Systems analysis & design Systems specifications system in use Acceptance test accepted system Performance validated software test Function test functioning system Systems design Program specifications Systems implementation Programs, procedures, data Integration test integrated modules Unit (module) tested modules test 11

Module or Unit Testing § Each module is tested individually § Lists what is being tested § Lists expected outcome § Identifies data to be used. . all possible combinations § Who carries out Module Testing? § Programmer - tests at code level § Analyst - tests at application level 12

Integration Testing § Verifies that system components work together: § data can be lost across interfaces § a function may not perform as expected when combined with another function § one module can have an adverse effect on another § Use an incremental approach to integrate moduleseasier to detect and correct errors: § Top-down testing § Bottom-up testing § Sandwich testing 13

System Testing § The process of testing the integrated software in the context of the total system it supports § Performed after all unit and integration testing is complete § Tests conducted at this stage include: § Function tests - demonstrate that all the functions specified for the system in the requirements specification are operational § Performance tests - demonstrate that the system meets the non-functional requirements specified. 14

Function Testing § Performed after all programming and integration testing is finished § Test cases § must cover every aspect of the system’s functionality § should have a high probability of detecting errors § Test plan § should be developed from the original specification § must include expected results that are measurable 15

Performance Testing § Compares the integrated modules with the nonfunctional system requirements such as speed, performance § § § Stress tests Configuration tests Security tests Timing tests Quality tests Maintenance tests Volume tests Compatibility tests Documentation tests Environmental tests Recovery tests Human factors tests 16

Acceptance Testing § Involves installing the system at user sites and is required when acceptance testing has not been performed on site § The test focuses on completeness of the installed system and verification of any functional or nonfunctional characteristics that may be affected by site conditions § Testing is complete § When the customer is satisfied with the results § The system can then be formally delivered 17

Prepare the Site § Ensure that facilities are adequate: § adequate space for all resources, ergonomic furniture, noise reduction, privacy, security, appropriate electrical connections, uninterrupted power, etc. § Install the hardware and software required to run the system § must be tested to ensure no damage during transportation, product not defective, product changes between purchase and delivery are acceptable etc § People responsible § Vendor Engineer, Technical Support Group 18

Data Conversion § Current production data needs to be converted Format, Content, Storage Medium Done according to the conversion plan Manual file conversion is a time-consuming task Often needs specially written conversion programs e. g. § Database Load Program § Record Transformation Program § Data must be confirmed to be correct § May need to support both old and new systems’ files § § § can introduce time lag § files may be out of step 19

Conduct Training § Need to consider: § who is the audience? § what level of detail should be imparted to the audience? § who should conduct the training? § where should the training be conducted? § when should the training be conducted? 20

User Training § Training - a complete and concentrated course in system use at the time of delivery § Ongoing training needs; new staff, staff changes etc. § Training must be planned § methods § resources § should also consider Help during and after installation for new users, infrequent users and users who want to "brush up" 21

User training § Training aids § § § must be easy to use reliable demonstrations and classes documentation on-line help and icons expert users § Supportive User Manager who provides training, motivation, support 22

Install the System § Method of installation depends on several criteria § Cost - if there are cost constraints certain choices are not viable § System criticality - if system failure would be disastrous, the safest approach should be selected regardless of cost § User computer experience - the more experience the users have, the less necessary it is to delay changeover § System complexity - the more complex the system, the greater the chance of flaws. . . a safer approach is better § User resistance - need to consider what the users are best able to cope with 23

Install the System § Alternatives § Direct installation or Abrupt cut-over § Parallel installation § Phased installation or Staged installation § Pilot installation or Single Location conversion 24

Direct Installation (Abrupt Cutover) § Old system stops and new system starts Total cutover Old system New system 25

Direct Installation (Abrupt Cutover) § This approach is meaningful when § § the system is not replacing any other system the old system is judged absolutely without value the old system is either very small and/or very simple the new system is completely different from the old and comparisons would be meaningless § Advantages § costs minimised § Disadvantages § high risk 26

Parallel Installation § Old and new systems operated concurrently Total cutover Old system New system 27

Parallel Installation § § Old and new systems operated concurrently Cut-over at end of a business cycle Balancing between both systems Advantages § risks low if problems occur § Disadvantages § cost of operating both systems 2. 5 times the resources 28

Phased Installation (Staged Installation) § System installed in stages Total cutover Old system New system 29

Phased Installation (Staged Installation) § System installed in stages § Subsequent stages provide more features § Phases or stages need to be identified at general design § Advantages § lower costs for earlier results § benefits can be realised earlier § rate of change for users minimised 30

Phased Installation (Staged Installation) § Disadvantages § close control of systems development is essential § costs associated with the development of temporary interfaces to old systems § limited applicability § demoralising - no sense of completing a system. 31

Pilot Installation § Old and new systems operated concurrently Total cutover Old system New system 32

Pilot Installation § § Old and new systems operated concurrently Only part of the organisation tries out the new system The pilot system must prove itself at the test site Advantages § risks relatively low if problems occur § errors are localised § can be used to train users before implementation at their own site § Disadvantages § lack of consistency between different parts of organisation 33

Monitor Operations § Monitor user satisfaction § with functional requirements § with system performance § Run benchmark tests § Tune system 34

Transition to Maintenance § Most organisations have formal procedures set up § A "maintenance" section is responsible! § Procedures should be set up to request maintenance § Owners of the new system must be informed of relevant procedures 35

Maintenance System Users § Fix it / Make it better Fixes and enhancements Problems/New ideas Maintain the new system Additional training and documentation Technical problems and new technology Project staff Escalating maintenance back to INITIATION Modifications PRODUCTION SYSTEM 36

Maintenance § § Corrective - fix errors Adaptive - satisfy changing needs Perfective - enhance performance Preventative - fix potential problems § If the cost of maintenance is too high consider other options: § new development, purchase a software package, re-engineer/modify 37

Corrective Maintenance § Corrects analysis, design and implementation errors § Can be the most expensive kind of maintenance § costs of functions not working correctly § having to undo what has been developed § Requires immediate attention § typically urgent, interfere with normal operations § Needs skilled maintenance staff to ensure rapid diagnosis of errors and their correction § must have or quickly develop high level of familiarity with the system § May use software tools for diagnosis 38

Adaptive Maintenance § To satisfy changes in the environment, changing business needs or new user requirements § changes in tax laws, takeovers and mergers, new OS, etc § new type of report, new class of customer etc. § Less urgent - changes occur over time § Adaptive maintenance is inevitable, does add value § Maintenance staff need strong analysis and design skills as well as programming skills § changes often require a complete SDLC § also need good understanding of the system 39

Preventative Maintenance § Pay now or pay more later § defects or potential problems found and corrected before they cause any damage § reduce chance of future system failure § eg expand number of records beyond needs, standardise formats across platforms § A natural by-product of maintenance work identify and fix any potential problems noted while fixing other errors § Ideally have periodic (monthly / half-yearly / annual) reviews of system to uncover and anticipate problems 40

Perfective Maintenance § To enhance performance, maintainability, usability § adds desired features rather than required § better run times, faster transaction processing etc. § To meet user requirements not previously recognised or given high priority § missed in development or not known about § considered unimportant § Legacy systems (old systems running for at least 10 years) are likely candidates for perfective maintenance § May involve technical systems specialists as well as general maintenance staff § network specialist to change network design for improved performance 41

Cost Elements of Maintenance § Maintainability § the ease with which software can be understood, corrected, adapted and enhanced § Low maintainability results in uncontrollable maintenance expenses § The following factors affect ‘maintainability’ § Defects § Customers § Documentation § Personnel § Tools § Software structure 42

Cost Elements of Maintenance § Defects § the number of latent or unknown errors existing after system installation § influences most maintenance costs, drives all other cost factors § few errors --> low maintenance costs § Customers § the number of customers/users of system § more customers, more maintenance effort/cost § greater need for high maintainability 43

Cost Elements of Maintenance § Documentation § quality of system documentation § exponential effect on maintenance costs § Personnel § quality of maintenance personnel § highly skilled programmers, typically not original programmers, to quickly understand carefully change system § separate from development? in-house? dedicated end-user support? 44

Cost Elements of Maintenance § Tools § appropriate automated development tools § programming tools, code generators, debuggers, hardware, CASE, diagnostics, etc § reverse engineering for no documentation § Software structure § quality of software structure and maintainability § formalisation of code, comments, versioning § structure charts, OO 45

Measuring Maintenance Effectiveness § There is a need to measure maintenance § understand quality of development/maintenance effort § We measure the following factors § number of failures § time between each failure § type of failure § Mean Time Between Failures (MTBF) § calculated using number of failures and time between each failure, widely used measure of quality 46

Maintenance Life Cycle § Software Maintenance Life Cycle (SMLC) § receive a Maintenance Request § transform the Maintenance Request to a Change (analysis) § specify the Change (design) § develop the Change (code) § test the Change § train users and run an acceptance test § convert and release to operations § update the documentation § conduct a Post-Maintenance Review Chapin, 1988 47

Review System Users § What went wrong/right? Why? System Audit Report Problems/New ideas Auditor Fixes and enhancements Review the system and the project MAINTENANCE Project issues and system bugs Project Review Report Steering Committee Project staff 48

Post Implementation Review § A PIR analyses what went right and wrong with a project. It is conducted 2 to 6 months after conversion by a team which includes user reps, development staff, internal auditors and sometimes external consultants development team is not in charge § look at original requirements and objectives § evaluate how well they were met § compare costs of development and operation against original estimates (maintenance costs ? ? ) § compare original and actual benefits § new system reviewed to see whether more of original or additional benefits can be realised 49

References § HOFFER, J. A. , GEORGE, J. F. and VALACICH (2005) Modern Systems Analysis and Design, (4 th edition), Pearson Education Inc. , Upper Saddle River, New Jersey, USA. Chapters 15, 16 § WHITTEN, J. L. , BENTLEY, L. D. and DITTMAN, K. C. (2001) 5 th ed. , Systems Analysis and Design Methods, Irwin/Mc. Graw-Hil. I, New York, NY. Chapters 16, 17 50