Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 2 times |
10.1
System implementation and maintenance
IMS9001 - Systems Analysis and Design
10.2
Implementation (Build)
Build and deliver the system
Build, test, installand deliver the
new system
User acceptance testing
User Documentation
Technical Design Report
MAINTENANCE
DESIGN
SystemVendors Hardware/
Software
System Owners
User Training
Production System
System and Technical
Documentation
SystemUsers
Project Report
10.3
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
Implementing the System
10.4
Systems ImplementationAcceptance 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
REVIEW
REVIEW
REVIEW
REVIEW
FINALISE DOCUMENTATION
CONDUCT SYSTEM TESTING
CONDUCT ACCEPTANCE TESTING
OPERATIONS HANDOVER
IMPLEMENTATIONPLANNING
10.5
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
REVIEW
REVIEW
CONDUCT TRAINING
GET SYSTEM READY
FOR START-UP
CONDUCT SYSTSEM
ACCEPTANCE
WRAP UP
Systems implementation cont.
10.6
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
Implementation Planning
10.7
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
Finalise Documentation
10.8
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
Finalise documentation cont.
10.9
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)
Testing
10.10
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
Testing Steps
10.11
Stages of Testing
Performance test
Function test
Unit (module) test
Installation test
Acceptance test
Integration test
tested modules
integrated modules
functioning system
validated software
accepted system
system in use
Systems design
Systems implementation
Systems analysis &
design
User requirements
Systems specifications
Program specifications
Programs, procedures,
data
10.12
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
Module or Unit Testing
10.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
10.14
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.
System Testing
10.15
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
Function Testing
10.16
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
Performance Testing
10.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
10.18
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
Prepare the Site
10.19
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
Data Conversion
10.20
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?
Conduct Training
10.21
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"
User Training
10.22
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
User training
10.23
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
Install the System
10.24
Alternatives
Direct installation or Abrupt cut-over Parallel installation Phased installation or Staged installation Pilot installation or Single Location
conversion
Install the System
10.25
Old system New system
Total cutover
Old system stops and new system starts
Direct Installation(Abrupt Cutover)
10.26
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
Direct Installation(Abrupt Cutover)
10.27
Old system
New system
Total cutover
Old and new systems operated concurrently
Parallel Installation
10.28
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
Parallel Installation
10.29
Old system
Total cutover
New system
System installed in stages
Phased Installation(Staged Installation)
10.30
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
Phased Installation(Staged Installation)
10.31
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.
Phased Installation(Staged Installation)
10.32
Old system
New system
Total cutover
Old system New system
Old system New system
Old and new systems operated concurrently
Pilot Installation
10.33
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
Pilot Installation
10.34
Monitor user satisfaction with functional requirements with system performance
Run benchmark tests
Tune system
Monitor Operations
10.35
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
Transition to Maintenance
10.36
Maintenance
Fix it / Make it better
Maintain the new system
Project staff
Problems/New ideas
Technical problems and new technology
PRODUCTION SYSTEM
System
Users
Fixes andenhancem
ents
Additional training anddocumentation
Modifications
back to INITIATION
Escalating maintenance
10.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
10.38
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
Corrective Maintenance
10.39
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
Adaptive Maintenance
10.40
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
Preventative Maintenance
10.41
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
Perfective Maintenance
10.42
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
Cost Elements of Maintenance
10.43
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
Cost Elements of Maintenance
10.44
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?
Cost Elements of Maintenance
10.45
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
Cost Elements of Maintenance
10.46
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
Measuring Maintenance Effectiveness
10.47
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
Maintenance Life Cycle
10.48
Review
What went wrong/right? Why?
System Audit Report
Review thesystem and the
project
Project staff
Problems/New ideas
Project issues andsystem bugs
MAINTENANCE
System
Users
Auditor
Fixes andenhancem
ents
Steering Committee
Project Review Report
10.49
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
Post Implementation Review
10.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