Software Maintenance and Support

1
Software Maintenance and Support

• Jon Hustead
• Joel Ruisi

2
Software Maintenance
3
Maintenance Overview

• Some Definitions
• Software Maintenance - the process of enhancing
  and optimizing deployed software, as well as
  remedying defects.
• Software Bug - an error, flaw, mistake, failure,
  or fault in a computer program that prevents it
  from working as intended.

4
Maintenance Overview

• Need for maintenance
• Correct errors
• Correct requirements and design flaws
• Improve the design
• Make enhancements
• Interface with other systems
• Convert to use other hardware
• Migrate legacy systems

5
Maintenance Overview

• Major aspects
• Maintaining control over the system's day-to-day
  functions
• Maintaining control over system modification
• Perfecting existing acceptable functions
• Preventing system performance from degrading to
  unacceptable levels.

6
Maintenance Overview

• Categories of maintenance
• Corrective - reactive modification to correct
  discovered problems.
• Adaptive - modification to keep it usable in a
  changed or changing environment.
• Perfective - improve performance or
  maintainability.
• Preventive - modification to detect and correct
  latent faults.

7
Maintenance Process

• Process implementation tasks
• Develop maintenance plans and procedures
• Establish procedures for modification requests
• Implement the CM (configuration management)
  process

8
Maintenance Process

• Problem and modification tasks
• Perform initial analysis
• Verify the problem
• Develop options for implementing the 
  modification
• Document the results
• Obtain approval for modification option

9
Maintenance Process

• Modification implementation task
• Perform detailed analysis
• Develop, code, and test the modification
• Maintenance Review/Acceptance tasks
• Conduct reviews
• Obtain approval for modification

10
Maintenance Process

• Migration tasks
• Develop a migration plan
• Notify users of migration plan
• Conduct parallel operations
• Notify user that migration has started
• Conduct post-operation review
• Ensure that old data is accessible

11
Maintenance Process

• Software retirement tasks
• Develop a retirement plan
• Notify users of retirement plan
• Conduct parallel operations
• Notify user that retirement has started
• Ensure that old data is accessible

12
Maintenance Issues

• Technical
• Limited understanding (40-60 of maintenance
  effort is devoted to understanding of the
  software to be modified)
• Testing - See Testing
• Impact analysis
• Maintainability - see Quality

13
Maintenance Issues

• Management
• Alignment with organizational issues
• Staffing
• Process issues
• Organizational aspects of maintenance
• The maintainer
• Outsourcing
• Organizational structure

14
Maintenance Issues

• Cost and estimation
• Cost
• Cost estimation
• Parametric models
• Experience

15
Whos Involved In Maintenance?
16
Users

• User Input is important
• Users Define
• Proper Software Functionality
• Proper User Interface
• Software Bugs
• Users Provide
• Defect Reporting
• Constructive Criticism

17
Developers

• Developer Input is important
• Developers Define
• Technical Implementation
• Developers Provide
• Functioning Software
• Prompt Defect Fixes
• A shoulder to cry on (for end users)

18
Management (CM)

• Management Input is important
• Management Define
• Maintenance Process
• Change Requests
• Defect Reporting
• Management Provide
• CM Process
• Communication
• Between end users and developers

19
Keeping Maintenance Under Control

• Maintenance can lead to budget and scope creep
• How do we keep maintenance under control?
• The answer Configuration Management

20
Configuration Management Process

• The control of changes, including the recording
  thereof, that are made to the hardware, software,
  firmware, and documentation throughout the system
  lifecycle
• The control and adaptation of the evolution of
  complex systems. It is the discipline of keeping
  evolving software products under control, and
  thus contributes to satisfying quality and delay
  constraints.

21
Wheres the Repository

• Metrics
• ????
• ????

?????????
Accepted

• Installation Notes
• ?????
• ?????

Placed In Queue
Change Request
Rejected
Version Release
?????????
22
Here it is

• Metrics
• Defects
• App Rework

Repository
Accepted

• Installation Notes
• JARS to Install
• Database Changes

Placed In Queue
Change Request
Rejected
Version Release
Repository
23
When does Maintenance Begin

• Maintenance does not begin at installation time!
• Begins at Initial Development
• No bugs in code means no bugs in application
• Clean code makes for easy maintenance
• Clean code means smaller more efficient files
• Use standard formatting and rules of thumb to
  make for easy maintenance

24
Make Maintenance Simple

• Use standard and rules of thumb when coding
• When naming variables
• Creating class structure
• Interfaces
• Abstract Classes
• Programmers expect a certain format when looking
  at code

25
Example

• Scenario
• Two employees given same task
• Requirements
• Develop company wide email
• Must be updateable
• Email must be updated and sent once a week
• New events
• New employees
• 10hrs per week to complete

26
Employee 1

• Did not think of maintenance before beginning
  development
• Hard to read
• Hard to maintain
• Full of syntactical errors
• Did not use standard rules of thumb
• Did not consider email structure

27
Employee 1 Output

• Upcoming events Company Picnic. Please stop by
  and say hello to are new Employees John Riley,
  and Peter Smith. They are located in the second
  floor offices. To entirecompany_at_company.com
  CCriley.john_at_company.com,smith.peter_at_company.com
  
• Date11/19/2006
• Thanks, Joe Diley (Vice President)
• Please stop by the kitchen for birthday cake on
  November 22, at 200pm. Hope to see you there.
• Current Company Status Sales - 200,000 .
  Expected Sales 150,000

28
What Went Wrong?

• As users of the English language, and email
  protocol, we have certain expectations.
• Recipients at the top
• Subject should be in between greeting and
  closing.
• Date should be placed at top of email

29
Here Comes Trouble!

• Now the boss wants an updated email
• Requirements
• Change the recipients to only be management
• Add new events
• Update the date to be current

30
A Simple Task Turned Ugly

• Who are the recipients?
• Where is the date?
• Where are the events that I need to update?
• Upcoming events Company Picnic. Please stop by
  and say hello to are new Employees John Riley,
  and Peter Smith. They are located in the second
  floor offices. To entirecompany_at_company.com
  CCriley.john_at_company.com,smith.peter_at_company.com
  
• Date11/19/2006
• Thanks, Joe Diley (Vice President)
• Please stop by the kitchen for birthday cake on
  November 22, at 200pm. Hope to see you there.
• Current Company Status Sales - 200,000 .
  Expected Sales 150,000

31
Employee 2

• Thought of maintenance before beginning
  development
• Easy to read
• Easy to maintain
• Clean looking email
• Used standard rules of thumb
• Considered email structure

32
Employee 2 Output

• To entirecompany_at_company.com
• Subject New Events and Employees
• Date November, 19, 2006
• Upcoming Events Company wide picnic
• New Employees John Riley, Peter Smith
• Note Please Join us for birthday cake in kitchen
  on November 22, at 200pm
• Thanks,
• Joe Diley (Vice President)

33
Employee 2 Updates

• Now the boss wants an updated email
• Requirements
• Change the recipients to only be management
• Add new events
• Update the date to be current

34
Piece of Cake

• Everything is where you would expect it.
• To entirecompany_at_company.com
• Subject New Events and Employees
• Date November, 19, 2006
• Upcoming Events Company wide picnic
• New Employees John Riley, Peter Smith
• Note Please Join us for birthday cake in kitchen
  on November 22, at 200pm
• Thanks,
• Joe Diley (Vice President)

35
Crises and Controversies in Software Maintenance

• Software maintenance is often unseen and
  unreported, but some issues and events have
  become notorious
• The Year 2000
• The controversy over testing and correctness
• The growth of support and service management

36
The Future of Software Maintenance

• The end of maintenance is often announced and
  promised as new technologies and new developments
  are promoted. But they offer ever greater
  problems of complexity and fallibility, and ever
  wider opportunities for incremental enhancement.
  The future of software is still the future of
  software maintenance

37
Software Support
38
Defined

• Customer service and support (CSS) is the part of
  a company's customer relationship management
  (CRM) department that interacts with a customer
  for their immediate benefit, including components
  such as the contact center, the help desk, and
  the call management system

39
Software Support Value

• Many people dont realize it but softwares main
  value is in support. The most direct example are
  Open Source companies probably all of them are
  based to some extent in providing high quality
  support for their products

40
Software Support Importance

• A large percentage of software projects fail
  because the developers fail to realize that it
  doesn't matter how much time and planning a
  development team puts into creating software if
  nobody in an organization ends up using it

41
Qualities of a Support Person

• Strong technical background mixed with
  interpersonal communication skills
• Must have both one without the other is useless

42
Open Source Support

• Free software is gaining more and more support in
  the programming community
• The ability for anyone to update the software
  means more extensive support is necessary

43
Open Source Support Methods

• Primary Web Forums
• Live chat (usually over IRC)
• http//www.live2support.com/
• E-Mail (slowest last resort)

44
Support and Training

• As a part of the deployment phase, its very
  important to have training classes for the most
  enthusiastic software users, shifting the
  training towards the neutral users intermixed
  with the avid supporters, and finally incorporate
  the rest of the organization into adopting the
  new software

45
User Input

• Users will have lots of questions and software
  problems which require intense support at every
  step of the development process

46
Types of Support

• General
• Specific
• Electronic

47
General Support

• Usage and installation questions
• Product compatibility and interoperability
  questions
• Interpretation of product documentation
• Diagnostic information reviews) to help isolate
  the cause of a problem
• Configuration samples
• Database searches
• Planning information for software fixes

48
Specific Support

• Personalized for each user
• Intensity depends on warranty coverage
• Assigned to particular department

49
Electronic Support

• Submit your problems and get your answers
  electronically
• View screens remotely
• Submit documents electronically
• View open cases that you have submitted
• Search a question and answer database

50
Support Overview
51
Support Overview (contd)

• Starts with General Support and becomes more
  specific as needed
• Recurring cases may be escalated to higher
  support levels where appropriate

52
Levels of Support Services

• Defect
• Support Line
• Remote Technical Support
• Consult Line

53
Defect Support

• Individual reported errors during a product
  install
• How to diagnose reported problems
• Problem determination, problem source
  identification, dump trace analysis
• Assist with diagnosing interfaces between Code
  and application
• Assist with diagnosing the interfaces between
  Code and User Exit programs
• Assist with incorrect publications via a
  reporting error
• Provide guidance on collection of documentation
  to resolve problems

54
Support Line

• Installation assistance (i.e. clarification of a
  single step in a process)
• General guidance for product installation. Assist
  with general questions on product usage and
  operation
• Interpret manuals regarding Code and application
  interface
• Interpret publications on the use or purpose of a
  User Exit. Provide a sample if one exists.
• Provide available configuration samples
• Interpret and clarify publications
• General questions on maintenance philosophy
• Short duration, general usage assistance
  questions
• Provide instructions on how to collect necessary
  documentation

55
Remote Technical Support

• Outline exact steps to add a new device
• Analyze system reports (e.g. Traces) and provide
  recommendations
• Interface with third party to assist in resolving
  network connectivity problems (may be via dial-in
  or voice)
• More complex or detailed questions than those
  covered by Support Line
• Provide instructions on how to collect necessary
  documentation
• Review configuration and recommend corrective
  actions
• Basic review, recommendations or configuration of
  parameters

56
Consult Line

• In-depth review, recommendations or configuration
  of parameters in a complex environment
• Review performance data sent in for analysis.
  In-depth performance analysis/tuning.
• Upgrade planning
• Capacity planning or review of customer plan
• Diagnose or review the user application code
  without a specific reported error
• Diagnose or review user exit code or write it
  (excluding the interfaces within the scope of
  defect support)
• Write samples (e.g. Application programming)
• Perform or provide step-by-step Assistance (e.g.
  Recover a databaseHSM and VSAM catalogue
  recoverynetwork configuration, data recovery)
• Guide through or analyze requirement for
  application of system maintenance (beyond short
  duration how-to)

57
Important Acronyms and Terms

• APAR Authorized Program Analysis Report. A
  formal report to IBM development, of a problem
  caused by a suspected defect in a current
  unaltered release of a program. An APAR may be
  used by development to document new function
  delivered in the maintenance stream

58
Acronyms and Terms (contd)

• PD Problem Determination. The process of
  isolating the source of a suspected problem to
  hardware or software. Pervasive Designation of an
  APAR which has the potential to affect many
  Customers

59
Acronyms and Terms (contd)

• PMR Problem Management Record. A record of the
  activities performed during the course of
  resolving a customer reported problem.

60
Barriers to Support

• Lackluster/uneducated technical support team
• Overly protective about source code
• Unwillingness to share ideas or suggestions

61
Conclusions

• Software maintenance and support are critical
  aspects of the development process
• Software will always have bugs and will always
  need maintaining
• Software is only useful if people are using it
  and, nobody will use it without proper support

62
References

• IBM Software Support Handbook http//techsupport.
  services.ibm.com/guides/webhndbk.pdf
• Software Support
• http//www-306.ibm.com/software/support/
• IBM Software Support Lifecycle
• http//www-306.ibm.com/software/info/supportlifecy
  cle/
• Software Development Lifecycle
  http//en.wikipedia.org/wiki/Software_development_
  lifecycle
• 60 Years of Software Maintenance Lessons
  Learned http//ieeexplore.ieee.org/iel5/10097/323
  36/01510185.pdf?arnumber1510185
• The Importance of Support
• http//people.warp.es/nacho/blog/?p126

63
Questions?