IMS9001 - Systems Analysis and Design

1. IMS9001 - Systems Analysis and Design System implementation and maintenance

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

3. 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

4. IMPLEMENTATIONPLANNING 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 REVIEW FINALISE DOCUMENTATION REVIEW CONDUCT SYSTEM TESTING REVIEW CONDUCT ACCEPTANCE TESTING REVIEW OPERATIONS HANDOVER REVIEW Systems Implementation

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

6. 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

7. 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

8. 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

9. Testing 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)

10. 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

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

12. 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

13. 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 modules- easier to detect and correct errors: • Top-down testing • Bottom-up testing • Sandwich testing

14. 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.

15. 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

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

17. 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

18. 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

19. 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

20. 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?

21. 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"

22. 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

23. 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

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

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

26. 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

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

28. 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

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

30. 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

31. 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.

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

33. 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

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

35. 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

36. 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 Modifications Escalating maintenance Project staff PRODUCTION SYSTEM back to INITIATION

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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 and carefully change system • separate from development? in-house? dedicated end-user support?

45. 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

46. 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

47. 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

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

49. 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

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