Post-Release Support and Maintenance

1. Post-Release Support and Maintenance • Once the software product is released to the user there are two on-going main tasks: • User and Customer Support • Software Product fixes, maintenance, and multiple new releases

2. Service and Support Activities On- line Support FAQ db Customer Service Support Reps. Customers/ users On-line Problem/ Fix information . . . . Technical Problem-Fix Analysts Call Mgmt Telephone Call Customers/ users Problem Fixes & Packaging (some minor customization) Direct Customer Support

3. Direct Customer Service & Support • After a software product is released to the customer, the customers and users still need support: • Usage Questions • Product content and advanced function questions • Defect/Problem reporting and status tracking • “Work-around-defect” solutions • Fix / updates information and fix releases • Installation questions • Help plan for future changes and growth (very rarely) Most of the above can be serviced by the Customer Service Support Representatives, who are familiar with the software but are not necessarily programmers. This set of activities are sometimes called “Level-1” support

4. Technical Problem-Fix Analysts • There are problems that the Customer Support Service Representatives can not resolve: • Problems that require in depth code analysis • Fixing the code • Retesting the fixes • Packaging a fix • Updating a FAQ db with complex problem work-around solution • Very Minor customer customization (hopefully temporary and will be taken out.) Most of the above require some software design and code knowledge. They are performed by Technical Problem-Fix Analyst, who are more familiar with the software and are capable of programming. This set of support activities are sometimes called “Level-2” support. Some include some minor customization ---- dangerous activity.

5. Special Customization Service • This is a big business, but not one that can be easily performed by a regular problem-fix support organization - - - Why? Because: 1. Once the software is customized, that part of the code is different from everyone else’s. If a 1000 customers modified their code, there would be 1000 different versions to support! (does the support group need to keep copies of 1000 versions?) 2. If there is there is fix release, 1000 different fixes and installs may be needed. Because of these problems, special customer customization is usually handled by a separate service group, whose mission is driven by customization and supporting the customized versions ----- possibly for ever.

6. Service, Support, and Maintenance Activities On- line Support FAQ db Product Functional Updates And Future Releases Customer Service Support Reps. Customers/ users On-line Problem/ Fix information . . . . Technical Problem-Fix Analysts Call Mgmt Telephone Call Customers/ users Direct Customer Support Problem Fixes & Packaging and Future Releases

7. Functional Updates and Maintenance Releases • Besides problem fixes and simple code updates, a software product will often go through multiple “maintenance” releases after its initial release because: • Technology improvements and changes (new platforms and architecture) • Industry and Business process changes (new flow) • Increased Competition (more functionalities) • Pre-planed and Evolving Product Enhancements • Recurring product changes (due to law changes) • Major Product Problem “fix” (e.g. performance, quality, etc.) • Business mergers and acquisitions driven changes These “maintenance” releases are conducted much like the original software release, with the complete product planning, requirements, design, code, test , integrate, and package cycle. The personnel involved is much more than just the regular service-support personnel. Sometimes the original developers are retained for many years to develop the multiple maintenance releases.

8. Different Types of Evolving/Changing Systems • Besides the obvious changes introduced through fixes, software systems can be categorized into three main categories (S-P-E classification) by the nature of the problem it is solving and the offered up solution: • Static systems (S-system) which do not change much because both the problem (requirements) and the solution is well understood and both stay fairly constant. • Abstract Problem systems (P-system) which describes real problems with an abstraction and resolve the problem with known solutions. However, real problems can not be completely captured by abstraction and the requirements have to be continuously fine tuned. So these software will change along with the changing requirements. • Embedded system (E-system) are those which describes real problems in real world context. Since the real world continues to evolve, E-system (embedded in real world) by definition must evolve with the changing world (e.g. changing requirements and changing solutions)

9. Software Maintenance and Multiple Releases • It is known that there is rarely a single-release system any more because most of our software systems are E-type. • Different reports show that more than 50% of the software effort is now dedicated to maintenance activities of multiple releases. • Eventually, we will have to sunset and withdraw the software based on: • Cost of on-going maintenance • How much of the existing system is still useful • Is the system “evolvable” any more (e.g. new technology, basic architecture and constraints, overly patched and non-comprehensible, etc.) • Existence of new competition and other better systems.

10. Lehman’s “Laws of “ Software Evolution • Continuing Change: large systems are never completed - - - they continue to evolve and decay • Increasing Complexity: continuing changes to a system deteriorate the system structure, unless conscientious effort is applied to reduce complexity. • Fundamental law of program evolution: program change can be captured by measures of global system and project attributes and thus can be made into a “deterministic” model. • Conservation of organizational stability: there is no wild or wide fluctuations in organizational productivity or other organizational characteristics. • Conservation of familiarity: After multiple releases, the effect of one more subsequent release starts to diminish. Do you agree or believe all of these - - - why or why not ?

11. Categorizing Basic Maintenance Activities • Corrective Maintenance: this is controlling and fixing the day-to-day problems and shipping a maintenance release with a set of fixes to the users • Adaptive Maintenance: this is the updates and improvements necessitated due to some other changes to the system or to changing requirements. • Perfective Maintenance: this is the redesign and recoding needed to improve the system (e.g. performance, complexity, quality, or functionality) • Preventive maintenance: this is the modifications made in anticipation of potential problems

12. A Sample Distribution of Maintenance(Lientz and Swanson survey of 480 some organizations) Adaptive Maintenance 25% Perfective Maintenance 50% Corrective Maintenance 21% Non-bug related product enhancements maintenance releases Bug related Maintenance releases Preventive 4%

13. Non-Corrective Maintenance and Product Improvements • There are times when the software needs to be rejuvenated before it can be further touched. This happens when a software is “transferred” to another group or when making any changes to it becomes too painfully costly. • For improvement of knowledge: • Reverse engineer to recover and re-discover all the pieces of requirements, architecture, design, code, test, integration and how the software was constructed • Re-document to clarify all the material and possibly missing material • For improvement of the software: • Restructuring to improve and simplify parts of the design and code • Reengineer the complete product by first reverse engineering and then forward engineer.