Post release support and maintenance
This presentation is the property of its rightful owner.
Sponsored Links
1 / 13

Post-Release Support and Maintenance PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on
  • Presentation posted in: General

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. Service and Support Activities. On- line Support. FAQ db. Customer

Download Presentation

Post-Release Support and Maintenance

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Post release support and maintenance

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


Service and support activities

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


Direct customer service support

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


Technical problem fix analysts

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.


Special customization service

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.


Service support and maintenance activities

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


Functional updates and maintenance releases

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.


Different types of evolving changing systems

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)


Software maintenance and multiple releases

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.


Lehman s laws of software evolution

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 ?


Categorizing basic maintenance activities

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


A sample distribution of maintenance lientz and swanson survey of 480 some organizations

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%


Non corrective maintenance and product improvements

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.


  • Login