Ingen bildrubrik

1
Software Evolution and Maintenance32Lecture 6
Emergency Management Predelivery/prerelease
maintenance phase Transition phase Documentation
Maintainers education and training
This lecture is based on Chapters 26-30
Bild 1
2
EMERGENCY

• An emergency is an unforeseen combination of
  circumstances or an unforeseen state that calls
  for immediate action.
• Usually, it involves some kind of danger.
• The danger is loss of life or loss of business.
• Emergencies are unpredictable in their
  occurrence.
• The information of their underlying causes is
  scarce and the sequence of events during the
  emergency is not always certain.

2
3
Virtual IT Infrastructure
Bild 3
4
Emergency Process Model Structure

• Products to be encompassed by the emergency
  process
• Safety-critical, commercial systems.
• Define severity levels
• Organisations/departments/teams involved in the
  process
• Sw systems may be managed by several
  organisations
• Sw systems may interface other organisations
  systems.
• Process and its phases
• Operational levels
• Roles
• Permanent and temporary roles
• Point of contact.

4
5
CM3 process phases
Alert Level 1
Alert Level 2
Alert Level 3
Normal Operation
Increased Attention
Emergency Situation
Owner Emergency Administrator
Owner Emergency Manager
Owner Task Force Leader
Emergency Closure
Emergency Follow-Up
Owner Task Force Leader
Owner Task Force Leader
Post-Alert phases
Bild 5
6
Operational levels
Bild 6
7
Emergency process at SAS

• It was created in 1996-97
• Why was it created Lack of responsibility /
  control increasing costs and down time
• What did it solve

Not my problem
7
8
Emergency process model
9
Future interoperability problem?
Who should be responsible for the problem?
10
Organisations involved
10
11
Operational levels at SAS and CSC
Bild 11
12
Experience of the process at SAS

• Gained control of the process
• Gained control of vendor activities
• Focus on the impact on SAS business
• Decreased investigation and correction time
  increased uptime
• (One hour down in RESAID 3 MSEK lost revenue)
• RESAID works 24/365

13
Statistics

• Uptime vs. SLA (business critical systems)
• Reservation system gt99,73
• Amadeus gt 99,75
• Internet gt 99,50
• 2004 severity 1 and 2 incidents
• 7 severity 1
• 61 severity 2
• 2004 incidents requiring task force 5

14
Predelivery/prerelease
Predelivery/prerelease maintenance process
Activities preparing the software system under
development or evolution and maintenance for
future maintenance.
Mira and Thomas Pigoski the father of the
predelivery and transition phases, the authour of
ISO/IEC FDIS 14764
Bild 14
15
Protests raised by

• Jones C., Martin J, McClure C, Pigoski T, Rombach
  D, and Swanson B.
• Maintenance is viewed as a purely postdelivery
  phase.
• Therefore, we have problems.
• Maintenance should start simultaneously with
  development.

15
16
Defintion suggested byThomas Pigoski
Software maintenance is the totality of
activities required to provide cost-effective
support to a software system. Activities are
performed during the predelivery stage as well as
the postdelivery stage. Predelivery activities
include planning for postdelivery operations,
supportability, and logistics determination.
Postdelivery activities include software
modification, training, and operating a help
desk.
Bild 16
17
Predelivery maintenance
Transition (handover)
Predelivery
Initial development
Evolution and Maintenance
Retirement

• Predelivery Maintenance Stage.
• Postdelivery Maintenance Stage.

• Transition (Handover) Stage

18
Maintenance Definition Perspective CM3
Roadmap
Bild 18
19
Predelivery stage of software maintenance
organisation

• The software maintenance organisation should
• Be designated and involved before signing a
  contract.
• Participate in the development of the contract
  specification.
• Sign the contract.

This is an ideal situation
Bild 19
20
Predelivery Software Maintenance(The conflict)

• The customer acquires the system, and wants it
  built quickly and inexpensively.
• The developer must develop the system, and wants
  to deliver it on time and within budget.
• But what about the product quality?
• The maintainer must live with the results of the
  development, and must maintain it for some
  extended period (far longer than the
  development).

Bild 20
21
How to avoid the conflict?

• Maintenance Planning
• Maintainability Planning

Bild 21
22
Predelivery activities

• Management of
• Maintainability Plan
• Maintenance Plan
• Contract
• Education
• Evaluation of the development process

23
Maintainability
23
24
Managing Contract
24
25
Maintenance Plan
25
26
Education
26
27
Evaluation
27
28
Two main predelivery activities

• Maintenance Planning
• Maintainability Planning

Bild 28
29
Maintenance Plan should cover

• Why support will be needed?
• Who will do what work?
• What the roles and responsibilities of everyone
  involved will be?
• What the estimated size of the maintenance staff
  will be?
• How the work will be performed?
• What resources will be available for support?
• Where support will be performed?
• When support will commence?

Bild 29
30
Example of aMaintenance Plan

• 1. Introduction
• Describe the system to be supported.
• Identify the initial status of the software.
• Describe why support is needed.
• Identify the maintainer.
• Describe any contractual protocols between
  customer and supplier.
• 2. Maintenance concept.
• Describe the concept
• Describe the level of support for the system.
• Describe the support period from predelivery to
  postdelivery support.
• Tailor the maintenance process by referring to
  the maintainers process manual.
• 3. Organisation and maintenance activities.
• Define the predelivery roles and
  responsibilities of the maintainer.
• Quality Assurance
• Testing
• Independent Verification and Validation (IVV)
• Define the postdelivery roles and
  responsibilities of the maintainer.
• Software Modification
• Quality Assurance

Bild 30
31

• 4. Specify resources
• determine personnel requirements
• Size of staff for the project
• Identify software needed to support the system,
  plus software maintenance tools requirements.
• Identify hardware needed to support the system,
  plus software maintenance testing requirements.
• Identify facilities requirements
• Identify documentation units.
• Software quality plan
• Project management plan
• Development documents
• Maintenance manuals
• Identify data requirements
• Identify other resource requirements (if needed)
• 5. Identify the process and how the work will be
  performed.
• Give an overview of the maintainers process
• Tailor the process
• 6. Identify training requirements
• Identify training needs of the maintainer
• Identify training needs of the user

Example of Maintenance Plan
Bild 31
32
Summing up, the maintenance plan should plan for
the following

• Choice of maintenance organisation
• Scope of maintenance
• Evolution and maintenance processes
• Resources
• Maintainers training
• Schedule.

Bild 32
33
Evaluating Maintainer Candidates

• Long-term costs
• Start-up costs
• Space
• Qualifications
• Past performance
• Availability
• Schedule
• Domain knowledge.

Bild 33
34
Estimating life-cycle costs(a function of scope
of sm)
Personnel cost such as salaries and benefits for
the maintenance staff (the largest cost
driver). Travel to user locations. Training
(maintenance staff, users). Attendance at
conferences. Cost of annual maintenance of the
hardware and software environment. Technical
publications and other related support
material. Overhead expenses per day. Annual
maintenance costs for full maintenance is between
10 and 15 of the development costs.
Bild 34
35
Definition of Maintainability
Maintainability - an important non-functional
requirement. The ease with which one may change
software systems. We have a very nice definition
of maintainability, but we do not know what it
is.
Bild 35
36
Maintainability

• Am organisational model of maintainability should
  be created and continuously revised. It would
• ensure that the maintainability attributes are
  uniformly understood
• ensure that the maintainability attributes are
  consistently applied
• ensure the maximal readability of software
  documentation and software code
• provide a basis for the maintainability plan.

Bild 36
37
Maintainability plan

• We do not have any detailed standard of a
  maintainability plan.

Bild 37
38
Maintainability Plan (FDIS 14764)

• Maintainability should be addressed prior to
  software development.
• Maintainability Plan should be developed by the
  developer.
• It should encompass
• qualitative and quantitative requirements
• to be implemented by the developer
• to be monitored by the maintainer.
• Procedures for checking the maintainability.

Bild 38
39
Maintainability Plan

• Master thesis Outline and validate a
  Maintainability Plan

Bild 39
40
Transition
Software transition is a controlled and
co-ordinated sequence of actions wherein software
product passes from the organisation performing
initial software development to the organisation
performing software maintenance.
Bild 40
41
Questions to ponder
Software transition is divided into two parts

• When should the maintainer be designated?
• When should the maintainer get involved during
  the development process?
• What should the maintainer do during development?
• Who should be responsible for the transition
  phase?

Software development transition. Software
maintainer transition.
Bild 41
42
Transition phases
Software transition is divided into two parts
Software development transition. Software
maintainer transition.

• Software development transition
• Software maintainer transition

Bild 42
43
Software Development Transition
A sum of activities to successfully transition
all the software development responsibilities
from the developer to the maintainer. This
involves the transfer of Hardware Software Experi
ence from the developer to the maintainer.
Bild 43
44
The best ways of transferring experience are

• Provide some form of software-specific training
  to the maintainer.
• Review configuration status.
• Study the software documents.
• Maintenance escorts.
• Spend some time with the developer.

Bild 44
45
Software Maintainer Transition

• Maintainer transition includes all the activities
  needed for the maintainer to implement the
  software predelivery activties as defined in the
  Maintenance Plan plus some additional
  handover activities
• Staffing.
• Training.
• Develop software configuration plans and
  procedures.
• Exercise the process and the product.

Bild 45
46
Transition Plan
A comprehensive transition plan is needed if the
transition is to be successful. The
organisation that is in the best position to
develop the transition plan is the maintainer.
A smooth, orderly transition is
important! Users have high expectations. Greater
influx of modification requests. Resources must
be well planned full staffing early on is
imperative in the beginning, can be reduced
later. Total credibility with the users can be
lost if the transition is not smooth and orderly.
Bild 46
47
1. General Purpose of the plan Overview of the
plan Software Transition Process Designation of
the maintainer Transition Planning transition
objective and phases software transition
responsibilities maintenance responsibilities ma
intenance funding 2. Requirements Software
Documentation Requirements Development
documentation Test documentation User
documentation Quality assurance and sw
configuration Management
documentation System Software Support Software
Software Packages Developer Written
Software Tools Other software tools Special
devises software licences Software support
hardware requirements Equipment Description (on
board/order) Equipment Description
(Option) System firmware Maintenance Contractor
Support (if required)
Transition plan
3. Installation and testing Installation
schedule Software testing development
testing operational testing testing
capability test programs and test data files.
4. Training Training Planning for
Personnel Factory/Vendor training System
specific training software training funding 5.
Other transition requirements facilities personn
el other resources other resources 6
Milestones Master Schedule and milestones 7.
References 8. Appendix A, Software transition
checklist B. Listing of software moduls.
Bild 47
48
Sample Software Transition Checklist
1. Have the engineering environment and test
environment software been delivered, installed,
and evaluated? 2. Have licensing agreements been
properly transferred for commercial software? 3.
Have documents, notebooks, and manuals used in
the software development process been identified
and turned over to the maintainer? 4. Have all
modification requests and problem reports been
delivered? 5. Have formal configuration audits
been completed? 6. Have identified discrepancies
been accounted for and properly documented in the
corrective action system? 7. Has the current
configuration been delivered to the
maintainer? 8. Are sufficient personnel with the
necessary skills and experience available to
sustain the projected maintenance level of
effort? 9. Have functional area and system
specific training identified in the transition
plan been completed? 10. Have adequate office
and storage space been identified to support
maintenance? 11. Are adequate utilities available
available (e.g. Electrical power, air
conditioning, and heat) to support
maintenance? 12. Has computer cabling been
properly laid, connected , and tested? ...
Bild 48
49
Transition Process Model

• Master thesis Outline and validate a model of
  software transition

49
50
Documentation role

• To describe a software system
• To describe a software process

50
51
Why is documentation important?

• Annually, many billions of dollars are spent on
  software systems by industry, government and
  commerce.
• A significant portion of this investment is lost
  due to poor-quality software and/or lack of or
  inadequate documentation.
• A disproportionate amount of resources are spent
  on maintenance.
• Documentation is an important prerequisite for
  successful management of software systems during
  their life-cycle

51
52
Documentation of a system

• Software system documentation, if correct,
  complete and constistent
• facilitates understanding and communication
• eases the learning and relearning process
• makes system more maintainable
• improves maintainers productivity
• improves maintainers work quality.
• is a key component in software quality and
  maintainability
• Poor system documentation
• misleads the maintainer in her work
• contributes to the quick software ageing
• contributes to the high cost of maintenance
• contributes to the distaste for maintenance work

Bild 52
53
Documentation of a process

• Pervasive process documentation
• increases the visibility into the development and
  maintenance work
• stages, tasks, roles, decisions, motivations,
  etc.
• a prerequisite for achieving mature processes
• Inadequate process documentation
• main reason for loosing control over the
  processes
• decreases the chances to improve the process
  quality.

Bild 53
54
Documentation Requirements
Bild 54
55
The system documentation is correct, complete and
consistent when the system is transferred from
development to maintenance.

• Support for
• learning the overall purpose and structure of the
  system
• determining the software components to be
  affected by modifications.

The maintainers cannot achieve good quality of
documentation during maintenance if it is not
right from the very beginning.
55
56
User manual is consistent with the state of the
software system.
Software system
consistent with
Manual

• More usable from the users perspective
• Reduces maintenance effort at Support Line 1 and 2

56
57
The software system is documented at all
granularity levels of system documentation.

• To preserve maintainability and traceability

57
58
Traceability between all levels of system
documentation and traceability of change is
ensured.
The degree of consistency of system descriptions
at all granularity levels

• to measure ACM
• to estimate future modification magnitude

Bild 58
59
Regression test case specification is revised and
modified, if required.
Test case ID
Test case ID
Test case ID
Test case ID
Test case ID
Test case ID

• Regression test case documentation can be
  voluminous.

59
60
Guidelines for documenting a software system are
defined.

• To aid maintenance engineers in producing high
  quality documentation
• to aid in the evaluation of the quality of
  software system documentation
• to make the documentation process more effective,
• to keep up the quality of documentation uniform
  and consistent within the whole organisation.

60
61
Control and approval of documentation

• The maintenance task is not approved as
  accomplished until the quality of all levels of
  system documentation for this task has been
  inspected.
• The quality of the documentation is periodically
  checked by some documentation process manager.

61
62
Documentation Requirements
System development documentation
System development journal
System maintenance journal
Supporting tool

• System Development Documentation
• System Development Journal
• System Maintenance Journal

62
63
Documenting changes

• All system changes are recorded during evolution
  and maintenance.
• History of the reported software problems is
  recorded for each product/product component.

Bild 63
64
Maintainability Plan

• Master thesis How much enough (documentation) is
  enough?

Bild 64
65
Maintainers education and training

• A second class activity
• on-the-job training for beginners
• low-status assignments for the outcasts and the
  fallen
• Lack of formal training

One considered maintenance as a dull, inferior,
non-creative and non-challenging activity
requiring no more than average intelligence.
Bild 65
66
Evolution and maintenance is difficult

• Diagnosing problems
• Lack of documentation
• Knowledge of the product
• Lack of process models
• Writing skills
• Low status of maintainer role
• Insufficiency of other support levels

• The ability of conducting the evolution and
  maintenance chores are strongly dependent on how
  the maintainers are prepared

66
67
Why did we create a process model for
maintainers education training?

• Maintainers do not possess enough knowledge of
  the software system.
• Engineers do not possess sufficient knowledge of
  the problem management process.
• 20-25 of problem reports are the result of the
  customers lack of product knowledge.
• Upfront (support) maintainers are not efficient
  in filtering duplicate problems.

Bild 67
68
CM3 Maturity Levels
All process models are presented on the Optimal
level.
Bild 68
69
CM3 Maintainers Education and Training
Maturity Levels

• Level 1Initial
• sporadically invoked
• Level 2 Defined
• simple process (individual engineer level)
• Level 3 Optimal
• elaborated process (organisational level)

Bild 69
70
CM3 Maintainers Education and Training
Maturity Level 1

• A general education and training programme of
  maintenance engineers is institutionalised.
• Maintainers are educated when a need arises.

Bild 70
71
CM3 Maintainers Education and Training
Maturity Level 2

• Resources for maintenance education and training
  are assigned to each individual maintenance
  engineer.
• ABB ROP two person-weeks a year
• ABB APR no bounds defined
• Time for self-study is reserved.
• ABB APR plan for 70 of full time
• ABB ROP plan for 80 of full time

Tuesdays at 2-3 pm
Bild 71
72
CM3 Maintainers Education and Training
Maturity Level 2

• Maintenance staff is familiarised and
  re-familiarised with the maintained product on a
  regular basis
• ABB ROP regular courses ABB ROP Regular Course
• ABB APR occasional courses, regular meetings
  seminars
• Maintenance engineers are adequately trained and
  motivated for performing their tasks within the
  maintenance process
• ABB APR the process is well documented but not
  always followed.
• ABB ROP the process has just been documented and
  is followed.
• Maintainers are educated on when, where and how
  they are allowed to deviate from following the
  defined process
• ABB APR ABB ROP Not actively taught.

Bild 72
73
ABB ROP Regular Course

• DAY 1 Development and Maintenance Process
• DAY 2 Controller HW, OS, I/O-system and
  Frameworks
• DAY 3 Motion Control and Functions
• DAY 4 Mechatronics in a Robot Project
• DAY 5 Robot Language and applications
• DAY 6 System, Project and Products.
• Back

Bild 73
74
CM3 Maintainers Education and Training
Maturity Level 2

• End users are sufficiently educated and trained
  to utilise the software product.
• ABB APR ABB ROP upfront (support) maintainers
  keep a watchful eye on their customers.
• A model for introducing newly employed
  maintainers into the maintenance work is
  institutionalised.
• ABB APR ABB ROP a specially tailored programme
  model for introducing newly employed maintenance
  engineers. ABB model
• Training in communication skills is provided.
• ABB APR ABB ROP Not implemented yet.

Bild 74
75
ABB ROP Model for a newly employed

• Preparations
• Introduction
• Presentation of the organisation
• Meetings with key individuals
• Competence development
• Plan for 20 weeks
• Follow up conversation.
• back

Bild 75
76
CM3 Maintainers Education and Training
Maturity Level 3

• The organisation provides a detailed
  specification of each role, its job description
  and required qualifications.
• ABB APR ABB ROP Partially implemented.
• The organisation makes an organisation-wide
  inventory of its knowledge and skill assets.
• ABB APR ABB ROP Not implemented yet.
• On-going evaluations of the maintainers
  qualifications and educational needs are made
  with respect to their roles and career plans.
• ABB APR Interviews contracts.
• ABB ROP Interviews.

Shouldnt we examine the maintenance engineers?
Bild 76
77
CM3 Maintainers Education and Training
Maturity Level 3

• The organisation provides a common glossary of
  terms to facilitate education and communication.
• ABB APR ABB ROP Implemented.
• The organisation anonymously records the
  instances of bad process behaviour.
• ABB APR ABB ROP Not implemented.
• The organisation provides education and training
  in proficiency in writing.
• ABB APR ABB ROP Not implemented.

Bild 77