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
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.
User Support and Maintenance Process Model Framework
The international standard ISO/IEC12207: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/IEC15504: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 practices5.4 / Operation process / CUS.4 / Operation process
5.4.1 / Process implementation / CUS.4.1 / Operational use process:
BP1. Identify operational risks.
BP2. Perform operational testing.
BP3. Operate the software.
BP4. Resolve operational problems.
BP5. Handle user requests.
BP6. Document temporary work-arounds.
BP7. Monitor system capacity and service.
5.4.2 / Operational testing:
Perform operational testing.
Verify operational readiness.
5.4.3 / System operation
5.4.4 / User support:
Assist and consult users.
Handle user requests.
Communicate work-arounds. / CUS.4.2 / Customer support process:
BP1. Train customer.
BP2. Establish product support.
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:
BP1. Determine maintenance requirements.
BP2. Develop maintenance strategy.
BP3. Analyze user problems and enhancements.
BP4. Determine modifications for next upgrade.
BP5. Implement and test modifications.
BP6. Upgrade user system.
BP7. Retire user system.
5.5.1 / Process implementation
5.5.2 / Problem and modification analysis:
Analyze the problem for its impact.
Replicate or verify the problem.
Develop modification options.
Document request and options.
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.
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 Process5.4.2 Operational testing
5.4.3 System operation
5.4.4 User Support / Is managed by / 7.1 Management
Employs / 6.8 Problem Resolution
Employs / 5.5 Maintenance
Employs / 6.1 Documentation
Tasks / 7.4 Training process
5.5 Maintenance / Is managed by / 7.1 Management
Employs / 7.2 Infrastructure
Employs / 6.8 Problem Resolution
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[AA1].
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 (**).
Table 3. Process Model
Process, activity, task / ISO12207 / Input / Output / ISO 15504[*]
U User Support / 5.4.4
U1. Process implementation. / 5.4.1.2
U1.1. Define user support strategy / 51) Contract
52) Customer requirements / **) Support strategy/plan / CUS.4.2. BP2
U1.2. Develop user support process / **) Support strategy/plan / 87) Communication mechanism
**) Support procedures
**) Knowledge DB / CUS.4.2. BP2
U1.3. Review user support process / 52) Customer requirements
**) Knowledge DB usage
84) Problem resolutions
**) Support strategy/plan / **) Support strategy/plan / CUS.4.2. BP3
CUS.4.2. BP4
CUS.4.2. BP5
CUS.4.2. BP6
U2. Assist and consult users. / 5.4.4.1
U2.1. Train users / 51) Contract
52) Customer requirements / 89) Training records / CUS.4.2. BP1
U2.2. Resolve operational problems
/ 84) Problem report
73) System / 94) Change request / CUS.4.1. BP4
U3. Handle user requests. / 5.4.4.2
U3.1. Handle user requests:
a) Accept incoming request,
b) Determine request type,
c) Document request,
d) Route to resolution provider,
e) Document resolution,
f) Communicate user / 83) Customer request / 84) Problem report
87) Communication mechanism / CUS.4.1. BP5
U3.2. Manage Knowledge DB:
a) Update known errors,
b) Extend Knowledge DB,
c) Create usage report / 84) Problem report
**) Knowledge DB / 84) Problem report
**) Knowledge DB
**) 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
Table 3. Process Model (cont)
Process, activity, task / ISO12207 / Input / Output / ISO 15504
M Maintenance / 5.5
M1. Process implementation. / 5.5.1
M1.1. Determine maintenance requirements / 52) Customer requirements
83) Customer request
84) Problem reports
53) System design/architecture / 52) Maintenance requirements / ENG.2. BP1
M1.2. Develop maintenance process / 5.5.1.1 / 52) Maintenance requirements / 16) Maintenance strategy/plan / ENG.2. BP2
M1.3. Develop maintenance process / 5.5.1.2 / 16) Maintenance strategy/plan
52) Maintenance requirements / **) Maintenance procedures
**) Knowledge DB
M1.4. Review maintenance system / **) Knowledge DB usage
16) Maintenance strategy/plan / 16) Maintenance strategy/plan
M1.5. Establish link with Configuration Management process. / 5.5.1.3 / 16) Maintenance strategy/plan / 69)Release strategy /plan
M2. Problem and modification analysis. / 5.5.2
M2.1. Problem and modification analysis:
a) Analyze the problem for its impact
b) Replicate or verify the problem
c) Develop modification options
d) Document request and options
e) Approve options / 52) Maintenance requirements
83) Customer request
84) Problem reports
53) System design/architecture / 21) Analysis Results / ENG 2. BP3
M3. Modification implementation. / 5.5.3
M3.1. Determine modification scope / 21) Analysis results
83) Customer request
94) Change request
84) Problem reports
34) Testing strategy
67) Regression test strategy / 95) Change Control record
69) Release strategy /plan
52) Maintenance requirements / ENG.2. BP4
M3.2. Implement and test modifications / 95) Change Control record
52) Maintenance requirements / 70)Release package
71)Release information
107) System component
Refer to 5.3Development and 6.1Documentation WP / ENG.2. BP5
M3.3. Upgrade user system / 70)Release package
71)Release information
107) System component / Refer to 6.2 Configuration Management WP / ENG.2. BP6
M4. Maintenance review/acceptance. / 5.5.4
M4.1. Maintenance review/acceptance:
a) Conduct reviews
b) Obtain approval / 52) Maintenance requirements
107) System component / Refer to 5.4.4User Support and 6.1Documentation WP / ENG.2. BP5
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.
Figure 1. High-level User Support and Maintenance process diagram[AA2]
Subprocesses in the diagram are:
Help Desk– / Provides first line support to system users: handles incoming reports, registers incidents (trouble tickets), and provides feedback about resolved issues.Problem Resolution– / 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.
Change Management– / Receives change requests from users, initiates change request implementation analysis, tracks and reports status of accepted change requests.
Planning/approval– / Plans maintenance tasks: sets priorities for defect fixing and requested change implementation and plans the work.
Development– / Provides software development workforce to implement required changes in the system: performs development life cycle: analysis, design and development of changes.
Testing– / Performs tests of the pending changes from the development process, raises issues, if found in the modified system, rejects or approves new releases.
User Acceptance Testing– / Performs user acceptance testing, raises issues in the modified system from a system user perspective, rejects or approves new releases.
Configuration Management– / Performs configuration management of system components: manages register of maintained systems, tracks changes in the systems, releases changes from development process across environments.
Management– / Manages the support and maintenance organization: sets organization priorities, business and technology strategy, tracks and manages support and maintenance performance.
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 modelHelp 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 inform user. / Problem resolution, Call/email / U2.1 Train users
U2.2 Resolve operational issues
U2.3f Communicate user
4. If problem report, search Knowledge db for work-around and report to user. / Work-around, Call/email / U4. Communicate work-arounds
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 resolved. / Problem resolution, Call/email / U2.3f Communicate user
Problem Resolution
1. Provide and document temporary work-around for the problem / Work-around / U4.1 Document work-arounds
2. Resolve reported problem / Problem resolution / U2.2 Resolve operational problems
3. Document problem resolution in the Knowledge db / Problem resolution / U2.3e Document resolution
U3.2a Update known errors
U3.2b Extend Knowledge db
4. If system defect, document system defect / Defect description
5. Route Defect to Development process / Defect description / U2.3d Route to resolution provider
6. Periodically review Knowledge db and merge, remove and update resolutions / Problem resolution / U3.2a Update known errors
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 implemented / Call/email / U2.3f Communicate user
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.
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, 1995ISO/IEC. ISO/IEC 12207: Information Technology - Software Life Cycle Processes. International Organization for Standardization and the International Electrotechnical Commission, 1995.
ISO15504, 1998ISO/IEC. ISO/IEC 15504: Information technology – Software process assessment, (parts 1-9) International Organization for Standardization and the International Electrotechnical Commission, 1998. <URL:
SPICE, 1997ISO/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ų priežiūros proceso modelis. Atvejo tyrimas
Andrius Adamonis
Doktorantas
Vilniaus Universitetas, Matematikos ir informatikos fakultetas
Šiame darbe praktinė patirtis, įgyta tiriant praktinį vartotojo paramos ir programų priežiūros procesą, apibendrinama ir derinama su visuotinai pripažintais proceso modeliais, išreiškiančiais geriausią programų sistemų kūrimo praktiką.
Darbe pateikiamas vartotojo paramos ir programų priežiūros bazinio proceso modelis, suderintas su ISO12207 ir ISO15504 siūlomais proceso modeliais, naudojant standartų siūlomą terminologiją, bei įvedant papildomus elementus, kur standartai nėra pakankamai detalūs.
Taip pat darbe nagrinėjamas praktinis proceso pavyzdys: pateikiamas organizacijoje naudojamo proceso aprašas bei jo atitikimas straipsnyje siūlomam modeliui, taip pagrindžiant sudaryto vartotojo paramos ir programų priežiūros modelio adekvatumą realiam organizacijoje vykdomam procesui.
1
[*] Titles of the base practices are given in the Table 1.
[AA1]1
ISO15504 Base Practice / SPICE / Inputs / Work ProductsCUS 4.1 Operational use
CUS 4.1.1 Identify operational risks / CUS.6.1 / 84) Problem Report
42) Service Level Measures
41) Field Measures / 22) Risk Analysis
CUS 4.1.2 Perform operational testing / CUS.6.2 / 59) Test Plan
60) Test Script
61) Test Case / 62) Test Results
CUS 4.1.3 Operate the software / CUS.6.3 / 4) Job Procedures
CUS 4.1.4 Resolve operational problems / CUS.6.4 / 84) Problem Report
73) System / 94) Change Request
CUS 4.1.5 Handle user requests / CUS.6.5 / 83) Customer Request / 84) Problem Report
87) Communication Mechanism
CUS 4.1.6 Document temporary work-arounds / CUS.6.6 / 84) Problem Report / 99) Work-around
CUS 4.1.7 Monitor system capacity and service / CUS.6.7 / 73) System / 42) Service Level Measures
CUS 4.2 Customer support
CUS 4.2.1 Train customer / CUS.7.1 / 51) Contract
52) Requirements Specification / 89) Training Records
CUS 4.2.2 Establish product support / CUS.7.2 / 51) Contract
52) Customer Requirements / 87) Communication Mechanism
CUS 4.2.3 Monitor performance / CUS.7.3 / 41) Field Measures
84) Problem Reports / 42) Service Level Measures
CUS 4.2.4 Determine customer satisfaction level / CUS.8.1 / 85) Customer Satisfaction Survey
41) Field Measures
31) Review records / 86) Customer Satisfaction Data
CUS 4.2.5 Compare with competitors / CUS.8.2 / 86) Customer Satisfaction Data
82) Competitor Information / 43) Benchmarking Data
CUS 4.2.6 Communicate customer satisfaction / CUS.8.3 / 86) Customer Satisfaction Data
43) Benchmarking Data / 87) Communication Mechanism
ENG 2 System and software maintenance
ENG 2.1 Determine maintenance requirements / ENG.7.1 / 52) Customer Requirements
83) Customer Request
84) Problem Reports
53) System Design / Architecture / 52) Maintenance Requirements
ENG 2.2 Develop maintenance strategy
ENG 2.3 Analyze user problems and enhancements / ENG.7.2 / 52) Maintenance Requirements
83) Customer Request
84) Problem Reports
53) System Design / Architecture / 21) Analysis Results
ENG 2.4 Determine modifications for next upgrade / ENG.7.3 / 21) Analysis Results
83) Customer Request
94) Change Request
84) Problem Reports
34) Testing Strategy
67) Regression Test Strategy / 95) Change Control record
69) Release strategy /plan
52) Maintenance Requirements
ENG 2.5 Implement and test modifications / ENG.7.4 / 95) Change Control
52) Maintenance Requirements / Development + documentation
ENG 2.6 Upgrade user system / ENG.7.5 / 95) Change Control
52) Maintenance Requirements / User support + documentation
ENG 2.7 Retire user system
[AA2]1Mapping: