USER SUPPORT AND SOFTWARE MAINTENANCE PROCESS MODEL.

A CASE STUDY
Andrius Adamonis

Vilnius University, Faculty of Mathematics and Informatics, doctoral student

Naugarduko g. 24, Vilnius-2006

Tel.no. +370 (686) 10234

andrius.adamonis@maf.vu.lt

INTRODUCTION
This study started as an attempt to summarize the practical experience gained in several projects where user
support was the key element of software development and maintenance activities. As it appeared practically, user
support played the major role determining user satisfaction with the information system implemented, sometimes
even more important than the functionality of the systems. On the other hand, maintenance and user support
activities should follow strictly defined process in order to make them manageable. At this stage industry best
practice might become handy. However, generic models, as they aimed at more wide applications, are not always
straightforward to implement.

The scope of this study is user support and maintenance processes that could be described as activities, which are
performed during software operation phase, but are more of service nature, i.e. directed at providing user support
and software maintenance rather than operation of software, or, in other words, which provide support to users by
assisting them to use the software and modifying software in order to keep it corresponding to changing users
requirements.

This paper seeks for the following goals:

Define elements of the user support and maintenance process following the baseline processes from widely
accepted standards ISO12207 and ISO15504, but to more detail and concreteness, as applicable to user support
and maintenance processes,
Present a case study of the user support and maintenance process implementation at a large and highly
computerized industrial company, which undertakes software development and maintenance activities for its
own needs. The case study will present the user support and software maintenance process as it is
implemented in a real organization using the terminology conforming to internationally accepted standards.
The case is believed to be mature, which is makes it worth to be investigated and generalized in order to share
experience and best practice. Moreover this paper targets to factorize the process into its basic elements in
order to categorize process elements into basic and more advanced ones therefore making a way for process
capability improvement.

A note on terminology: this paper uses terms software and software system (or just system) interchangeably. Term
base process is used to name the underlying technological process, i.e. base practices that compose the process
of making product; in the case of user support process product is user support service, in the case of maintenance it
is the problem resolutions and modifications to the software maintained. Base process activities are also called
base practices.

1
USER SUPPORT AND MAINTENANCE PROCESS MODEL FRAMEWORK
The international standard ISO/IEC 12207:1995 establishes a common framework for software life cycle
processes, with well-defined terminology. Among others it also contains processes, activities and tasks that are
applied during the operation and maintenance of software products (ISO12207, 1995).

ISO/IEC 15504:1998 (also known as SPICE) defines a set of universal software engineering processes that are
fundamental to good software engineering and that cover best practice activities. The reference model describes
processes that an organization may perform to acquire, supply, develop, operate, evolve and support software, and
the process attributes that characterize the capability of those processes (ISO15504, 1998; SPICE, 1997).

As ISO15504 is harmonized with ISO12207, the process and activities are grouped similarly. Let us introduce
those processes and activities that are relevant to performing user support and maintenance activities. The table
also provides the mapping between ISO12207 and ISO15504 activities, as given in ISO15504, 1998, part 2:

Table 1. User Support and Maintenance activities

12207 12207 Processes and activities 15504 15504 processes and base practices
5.4 Operation process CUS.4 Operation process
5.4.1 Process implementation CUS.4.1 Operational use process:
BP1. Identify operational risks.
5.4.2 Operational testing: BP2. Perform operational testing.
Perform operational testing. BP3. Operate the software.
Verify operational readiness. BP4. Resolve operational problems.
5.4.3 System operation BP5. Handle user requests.
BP6. Document temporary work-arounds.
BP7. Monitor system capacity and service.
5.4.4 User support: CUS.4.2 Customer support process:
Assist and consult users. BP1. Train customer.
Handle user requests. BP2. Establish product support.
Communicate work-arounds. BP3. Monitor performance.
BP4. Determine customer satisfaction level.
BP5. Compare with competitors.
BP6. Communicate customer satisfaction.
5.5 Maintenance process ENG.2 System and software maintenance process:
5.5.1 Process implementation BP1. Determine maintenance requirements.
BP2. Develop maintenance strategy.
5.5.2 Problem and modification analysis: BP3. Analyze user problems and enhancements.
Analyze the problem for its impact. BP4. Determine modifications for next upgrade.
Replicate or verify the problem. BP5. Implement and test modifications.
Develop modification options. BP6. Upgrade user system.
Document request and options. BP7. Retire user system.
Approve options.
5.5.3 Modification implementation:
Determine modification scope.
Implement and test modifications.
5.5.4 Maintenance review/acceptance:
Conduct reviews.
Obtain approval.
5.5.5 Migration:
Develop migration plan.
Communicate the migration plan.
Conduct parallel operations.
Perform a post-migration review.
5.5.6 Software retirement:
Develop retirement plan.
Communicate the retirement plan.
Conduct parallel operations.
Archive retired product.

2
According to ISO12207, user support and maintenance activities are linked to other processes (most often employ
other processes); the major dependencies are presented in the table below:

Table 2. Process references

Process Type of Link Linked Process

Is managed by 7.1 Management
5.4.2 Operational testing Employs 6.8 Problem Resolution
5.4.3 System operation Employs 5.5 Maintenance
5.4.4 User Support Employs 6.1 Documentation
Tasks 7.4 Training process
Is managed by 7.1 Management
Employs 7.2 Infrastructure
Employs 6.8 Problem Resolution
5.5 Maintenance
Employs 6.2 Configuration Management
Tasks 5.3 Development
Employs 6.1 Documentation
In our model, we will not consider activities that are not relevant to the user support and maintenance directly,
such as:

5.4.2 Operational testing,

5.4.3 System operation,
5.5.5 Migration,
5.5.6 Software retirement. Comentado [AA1]:
ISO15504 Base Practice ...
PROCESS MODEL
This section presents user support and maintenance process model. The model describes base process in terms that
are compatible with the standards described above. Following the capability modeling tradition, this model forms
normative part of the paper and presents base practices and their work products. An example interpretation is
given in the next section.

The model presents two processes: User Support and Maintenance. Model outline consists of activities, tasks and
subtasks going to detail. On higher levels model elements coincide with those that are presented in ISO12207,
however on more detailed levels, original wording is given (as it is absent from the standards). Where activity or
tasks wording matches those that in ISO12207 standard, the process or activity number from ISO12207 is given in
the second column. Also, mapping to equivalent or similar activities or tasks from ISO15504 model, where
matching exists, is given in the last column.

Where applicable, work products are presented following the wording of ISO15504 and leaving the original work
product number; this conforms to both SPICE versions, where work product codes have not changed between the
versions). If a new work product is introduced, two asterisks instead of the number are given (**).

3
Table 3. Process Model

Process, activity, task ISO Input Output ISO

12207 15504*
U User Support 5.4.4
U1. Process implementation. 5.4.1.2
U1.1. Define user support strategy 51) Contract **) Support CUS.4.2.
strategy/plan BP2
52) Customer
requirements
U1.2. Develop user support process **) Support 87) Communication CUS.4.2.
strategy/plan mechanism BP2

**) Support
procedures
**) Knowledge DB
U1.3. Review user support process 52) Customer **) Support CUS.4.2.
requirements strategy/plan BP3

**) Knowledge DB CUS.4.2.

BP4
usage
CUS.4.2.
84) Problem resolutions BP5
**) Support CUS.4.2.
strategy/plan BP6
U2. Assist and consult users. 5.4.4.1

U2.1. Train users 51) Contract 89) Training records CUS.4.2.

BP1
52) Customer
requirements
U2.2. Resolve operational problems 84) Problem report 94) Change request CUS.4.1.
BP4
73) System
U3. Handle user requests. 5.4.4.2
U3.1. Handle user requests: 83) Customer request 84) Problem report CUS.4.1.
a) Accept incoming request, BP5
87) Communication
b) Determine request type, mechanism
c) Document request,
d) Route to resolution provider,
e) Document resolution,
f) Communicate user
U3.2. Manage Knowledge DB: 84) Problem report 84) Problem report
a) Update known errors, **) Knowledge DB **) Knowledge DB
b) Extend Knowledge DB,
c) Create usage report **) Knowledge DB
usage
U4. Communicate work-arounds. 5.4.4.3
U4.1. Document temporary work-arounds 84) Problem report 99) Work-around CUS.4.1.
BP6

*
Titles of the base practices are given in the Table 1.

4
Table 3. Process Model (cont)
Process, activity, task ISO Input Output ISO
12207 15504
M Maintenance 5.5
M1. Process implementation. 5.5.1

M1.1. Determine maintenance requirements 52) Customer 52) Maintenance ENG.2.

requirements requirements BP1
83) Customer request
84) Problem reports
53) System
design/architecture
M1.2. Develop maintenance process 5.5.1.1 52) Maintenance 16) Maintenance ENG.2.
requirements strategy/plan BP2

M1.3. Develop maintenance process 5.5.1.2 16) Maintenance **) Maintenance

strategy/plan procedures
52) Maintenance **) Knowledge DB
requirements
M1.4. Review maintenance system **) Knowledge DB 16) Maintenance
usage strategy/plan
16) Maintenance
strategy/plan
M1.5. Establish link with Configuration 5.5.1.3 16) Maintenance 69) Release strategy
Management process. strategy/plan /plan
M2. Problem and modification analysis. 5.5.2
M2.1. Problem and modification analysis: 52) Maintenance 21) Analysis Results ENG 2.
requirements BP3
a) Analyze the problem for its impact
b) Replicate or verify the problem 83) Customer request
c) Develop modification options 84) Problem reports
d) Document request and options 53) System
e) Approve options design/architecture
M3. Modification implementation. 5.5.3
M3.1. Determine modification scope 21) Analysis results 95) Change Control ENG.2.
83) Customer request record BP4
94) Change request 69) Release strategy
84) Problem reports /plan
34) Testing strategy 52) Maintenance
requirements
67) Regression test
strategy
M3.2. Implement and test modifications 95) Change Control 70) Release package ENG.2.
record BP5
71) Release
52) Maintenance information
requirements
107) System
component
Refer to 5.3 Deve-
lopment and 6.1 Do-
cumentation WP
M3.3. Upgrade user system 70) Release package Refer to 6.2 Confi- ENG.2.
guration Manage- BP6
71) Release information
ment WP
107) System component
M4. Maintenance review/acceptance. 5.5.4
M4.1. Maintenance review/acceptance: 52) Maintenance Refer to 5.4.4 User ENG.2.
requirements Support and 6.1 Do- BP5
a) Conduct reviews
107) System component cumentation WP
b) Obtain approval

5
CASE STUDY
The case study presents user support and maintenance process implementation in a large commercial company that
operates a number of large and diverse computerized systems to support its business. The company has a large
division to operate and maintain the systems. User support and maintenance process is established: there are
clearly defined roles, responsibilities, tasks, and work products.

The high-level process model is presented in the diagram below. The circles denote subprocesses that constitute
the user support and maintenance process, arrows show data flow between subprocesses.

Additional
Information

Trouble Problem Problem Problem

Help Desk
Ticket Report Resolution Resolutions

Defect
User Development System
Description
Work Release
Task Package
Approved
Change Change Planning/ Configuration
Change Release
Request Management approval Management
Request
Release Package
Release Package
User
Acceptance
Test Testing
Management Problem Testing
Report

Figure 1. High-level User Support and Maintenance process diagram Comentado [AA2]: Mapping:
Process, activity, task ...
Subprocesses in the diagram are:

Help Desk
Problem Resolution
Change Management
Planning/approval
Development
Testing
User Acceptance Testing
Configuration Management
Management
Provides first line support to system users: handles incoming reports, registers
incidents (trouble tickets), and provides feedback about resolved issues.
Provides second line support: provides work-arounds or resolutions to issues
reported by users, registers problem resolutions in the knowledge database, in
case of system defect, registers defects in the defects database and forwards to
the development process.
Receives change requests from users, initiates change request implementation
analysis, tracks and reports status of accepted change requests.
Plans maintenance tasks: sets priorities for defect fixing and requested change
implementation and plans the work.
Provides software development workforce to implement required changes in
the system: performs development life cycle: analysis, design and
development of changes.
Performs tests of the pending changes from the development process, raises
issues, if found in the modified system, rejects or approves new releases.
Performs user acceptance testing, raises issues in the modified system from a
system user perspective, rejects or approves new releases.
Performs configuration management of system components: manages register
of maintained systems, tracks changes in the systems, releases changes from
development process across environments.
Manages the support and maintenance organization: sets organization
priorities, business and technology strategy, tracks and manages support and
maintenance performance.

6
In order to prove adequacy of the model to process in practice, the linking between two models is investigated.
The three subprocesses were selected: Help Desk, Problem Resolution and Change Management. The next table
illustrates how the work procedure for the selected subprocesses is matched with the elements of the model
investigated:

Table 4. Process mapping to model elements

Procedure Work Products (indirect WP) Mapped element from the model
Help Desk
1. Accept incoming call/email U2.3a Accept incoming request
2. Register in the database Trouble ticket U2.3b Determine request type
U2.3c Document request
3. If service request, fulfill the request and Problem resolution, U2.1 Train users
inform user. Call/email U2.2 Resolve operational issues
U2.3f Communicate user
4. If problem report, search Knowledge db Work-around, Call/email U4. Communicate work-arounds
for work-around and report to user.
5. Assign problem to specialist. Problem report U2.3d Route to resolution provider
5. Inform the user that action will be taken. Call/email U2.3f Communicate user
6. Inform the user, when the problem is Problem resolution, U2.3f Communicate user
resolved. Call/email
Problem Resolution
1. Provide and document temporary work- Work-around U4.1 Document work-arounds
around for the problem
2. Resolve reported problem Problem resolution U2.2 Resolve operational
problems
3. Document problem resolution in the Problem resolution U2.3e Document resolution
Knowledge db U3.2a Update known errors
U3.2b Extend Knowledge db
4. If system defect, document system Defect description
defect
5. Route Defect to Development process Defect description U2.3d Route to resolution provider
6. Periodically review Knowledge db and Problem resolution U3.2a Update known errors
merge, remove and update resolutions U3.2b Extend Knowledge db
Change Management
1. Accept change request from user Change request U2.3a Accept incoming request
U2.3b Determine request type
U2.3c Document request
2. Route to Development for estimates Change request M2.1a Analyze the problem for its
impact.
M2.1c Develop modification
options.
M3.1 Determine modification
scope.
3. Confirm estimates with the user Approved change request M2.1e Approve options
4. Get management approval Approved change request M2.1e Approve options
5. Route to Development to implement Approved change request M3.2 Implement and test
modifications
6. Inform user when change request is Call/email U2.3f Communicate user
implemented

The next page contains the diagram of a graphical mapping between the processes, where organizational process is
represented using the element from the process model.

7
8
Figure 2. Graphical representation of the mapping between process models
CONCLUSION
The presented user support and software maintenance process model introduces key elements (base practices) of
the process. The model is defined in the terms of base practices and their associated work products. The model is
compatible with the ISO12207 standard by its construction.

The model adequacy is proven by presenting a case study of the user support and software maintenance process
implementation in a real organization. The mapping between case study and process model is given, which shows
the adequacy of the model to the case investigated.

This model will serve as a background for the investigation of the user support and maintenance process capability
modeling as defines the base process that will be augmented with capability practices.

REFERENCES
ISO12207, 1995 ISO/IEC. ISO/IEC 12207: Information Technology - Software Life Cycle Processes.
International Organization for Standardization and the International Electrotechnical
Commission, 1995.

ISO15504, 1998 ISO/IEC. ISO/IEC 15504: Information technology Software process assessment, (parts 1-9)
International Organization for Standardization and the International Electrotechnical
Commission, 1998. <URL: http://www.seg.iit.nrc.ca/spice>

SPICE, 1997 ISO/IEC. SPICE Software Process Assessment, version 1.0, (parts 1-9). International
Organization for Standardization and the International Electrotechnical Commission, 1997.

SANTRAUKA

VARTOTOJO PARAMOS IR PROGRAM PRIEIROS PROCESO MODELIS.

ATVEJO TYRIMAS

Andrius Adamonis

Doktorantas

Vilniaus Universitetas, Matematikos ir informatikos fakultetas

iame darbe praktin patirtis, gyta tiriant praktin vartotojo paramos ir program prieiros proces,
apibendrinama ir derinama su visuotinai pripaintais proceso modeliais, ireikianiais geriausi program sistem
krimo praktik.

Darbe pateikiamas vartotojo paramos ir program prieiros bazinio proceso modelis, suderintas su ISO12207 ir
ISO15504 silomais proceso modeliais, naudojant standart silom terminologij, bei vedant papildomus
elementus, kur standartai nra pakankamai detals.

Taip pat darbe nagrinjamas praktinis proceso pavyzdys: pateikiamas organizacijoje naudojamo proceso apraas
bei jo atitikimas straipsnyje silomam modeliui, taip pagrindiant sudaryto vartotojo paramos ir program
prieiros modelio adekvatum realiam organizacijoje vykdomam procesui.