SE 386 Software Maintenance and Reengineering
Notes 001
Textbook: Practical Software Maintenance, Thomas Pigoski, 1996.
The advantages of Software Maintenance and those who live the maintenance life!
1 Introduction



In 1997 there was an estimated 100 Billion lines of code in execution.
In 2007 there were over 200 Billion lines of COBOL in production.
Couldn’t find any more current numbers on total lines of code.
1.1 When Should Maintenance Start
Consideration of Maintenance should begin when the decision is made to develop a new system
 Architecture – should support maintenance
 Schedule – know when maintenance will need to start, need to have people knowledgeable
of the system to do maintenance once the system is released.
 Budgets – money needs to be allocated for maintenance.
 Transition Plans – don’t want to just throw it over the wall separating the Development
team from the Maintenance team!
 How will the system (s/w and all the artifacts) be turned over to maintenance folks?
 What are the responsibilities and the deliverables?
 Documentation and Specifications – how will knowledge of the system be transitioned over
to the maintainers?
1.2 A few words about this book and other books on maintenance and software
system evolution

Even though significant effort and resources go into maintenance phase, there is a
disproportionate small amount of material (textbooks) on the topic when compared to firsttime design and development.
©2012 Mike Rowe
Page 1
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001

There are also very few undergraduate programs that have courses on software
maintenance – most maintenance and reengineering courses are graduate level.
2 Overview of Software Maintenance (p7)
2.1 Why is there confusion and lack of information about the Software Maintenance
Process?




There are few textbooks or published papers. Try doing a “google” search on “Software
Maintenance” and compare it to “Object Oriented Design”
Software maintenance methods that work are kept secret!
The processes that companies use are highly tailored:
o based on industry requirements (regulatory agencies)
o personnel available
o company’s position in the industry (leader v. new comer)
o maturity of the product and industry
o even the physical (building) layout of the company
Most companies continuously experiment with their maintenance process.
o One company I worked for changed organizational structure at least once a year – I
don’t think they ever got it right.
2.2 What Is Software Maintenance?
Maintenance officially begins once the system has been released to a significant user population
(Alpha or Beta tests).
 Part of the specification of when maintenance begins is due to IRS tax rules.
o Money spent prior to release to customers can be treated as R&D
o Once it is released to a customer work done on the software becomes an expense.
 Anything we can do to make an existing software system better.
o Add features
o Fix Bugs – Y2K
o Improve speed/footprint
o Keep Software current with Operating Systems (Windows 95 to NT to XP to Vista to
Windows 7, etc.)
o Port to new platforms/Operating Systems (XP to Linux)
o Structural/architectural changes to improve maintenance
2.2.1 Where Maintenance fits into a Software Lifecycle

Needs Determination – requirements should include maintenance needs.
©2012 Mike Rowe
Page 2
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001




Design and architecture – design to allow future extension, modification, porting, . . .
Development – develop to ensure maintainability
Production – may require having multiple versions produced and available to customers at
one time
Maintenance and Support – various customers maybe using different versions of the
software in many different environments
2.2.2 Lifecycle Model (yet again) and how maintenance fits in
2.2.2.1 Waterfall



Very Sequential
Doesn't allow for changes and mid course corrections.
Maintenance occurs only after Delivery. Often the system may require significant
maintenance from initial release to be usable.
2.2.2.2 Incremental




All Requirements are defined first.
The system is assembled in stages, with each stage adding functionality.
Often the product may actually go into some limited release at later stages.
These later stages require maintenance and support. …
2.2.2.3 Evolutionary






RAD, RUP, XP, Agile and Spiral models
Requirement and build stages iterate with hopefully successive approximations of the
finished product.
Often used when requirements cannot be exactly defined or are frequently changing. Also
can be used when technologically difficult implementations are necessary.
Often the product may have several limited releases and the maintenance folks may be
responsible for fixing discovered bugs.
Allows the user community to provide a great deal of very relevant input.
Can cut down on the need for feature adding during the maintenance phase
2.3 Why is Maintenance Necessary?


Not all user requirements can be anticipated during design and implementation.
o “A user won’t know what they don’t want until they see what has been delivered.”
o Thus, we will have enhancements added to a system
It may not make sense to hold up delivery until all requirements are implemented.
o It is often better to ship version 1.0 as soon as possible to build market share and
start a revenue stream.
o Then follow with Phase II, III, IV, …
©2012 Mike Rowe
Page 3
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001



o Sometimes features may be ready to go, but are held back for marketing reasons –
like get people to pay for future upgrades.
o Once saw a computer upgrade done. The technician came into the room with an
empty cardboard box. Took out a card, put it in the cardboard box and the
computer ran 50% faster!
Make Enhancements: The implementation may invoke ideas for system extensions.
Correct Implementation and Design Errors:
o It is often hard to test all code under all conditions (network loadings, timings, …).
o Also, complete system analysis may not be possible and designing for worst case
may miss actual “in the wild” worst case. Production use may “discover” problems
with code.
Computing Environment Changes:
 New Hardware (16 bit to 32 bit to 64 bit architectures) changes. I’ve heard rumors
that Windows 8 may only be available in 64 bit version?
 New operating systems (Win 3.x to Win NT to NT2000 to XP to Vista to Windows 7 to
Windows 8, . . . ).
 New Databases, network architectures, Web enabling of legacy systems, …
 Multi-core processor architectures are latest evolutionary change to which our
software must adapt.
2.3.1 What are the Three or Four Categories of Maintenance?
Swanson
 Corrective: A system does not satisfy requirements, including keep running without “blue
screens”.
 Adaptive: Keep up with computing environment changes.
 Perfective: (hopefully it is moving in the direction of Perfection). Change system
functionality to meet evolving customer needs.
2.3.2 IEEE Maintenance Categories
IEEE 1219 - 1993
 Corrective – bug fixes
 Perfection – Adaptive plus Perfective from above.
 Environmental evolution
 Functional Enhancements
 Prevention Maintenance – Prevent or minimize the likelihood of possible problems. This is
very important for mission critical systems (control systems for pipelines, transportation,
utilities, …
©2012 Mike Rowe
Page 4
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001
2.3.3 ISO/IEC 12207 (loosely defined)




Corrective – fix defects
Adaptive – Environmental evolution
Improvement – Functional enhancements
Preventive – improve maintainability
2.3.4 Is Maintenance More than Just Fixing Bugs? Yes.

Why is it important to track and differentiate between Bugs and Enhancements?
o Generally, enhancements are more expensive than original development and fixing
bugs.
o If we don’t differentiate between bug fixing and enhancements
 it will distort budget estimations
 It distorts estimates of quality
 If defect reports and enhancement requests are combined into generic
Maintenance Requests, we may have excellent quality, but just a lot of
potential for extending functionalities.
 Need data on whether a system can be put into production?
2.4 Why is Maintenance Hard? or What needs to be done to make it easier!


Maintenance folks need to be involved as early in the process as possible. This gives them
a clue about the system.
o If maintenance folks are not involved early, artifacts may be missing that are
necessary for easy maintenance.
Need to track the product and the process that created it.
o what the requirements for a system are,
o what is the design,
o what were the technical tradeoffs that drove the design and implementation,
o how was the product tested,
o what changes were made and why were they made,
o how did the changes affect the architecture: design, testing coverage,
documentation, training classes, support organizations, sales and marketing, existing
installed systems (are conversion programs necessary for upgrading – like database
changes might),
o what other systems were impacted by changes to this system.
2.5 How should we structure a Maintenance Organization?
Separate Group or part of Development group or something else?
©2012 Mike Rowe
Page 5
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001
2.5.1 A Subgroup of folks in the Development Group
People Designated as Maintenance Resources, but who work as a subgroup of a Development
Organization. They have responsibility for any work that comes in regardless of subsystem. They
report to the same management.
 Pluses
o Developers best know the system – being close to development subgroups can
improve communications.
o Might think that we can take shortcuts with documentation – not true, people move
on, get hit by runaway beer trucks, some systems are too large that there is little
chance of the same developer actually fixing the code that they wrote.
o Cuts down on communications overhead – don’t have to go up and down
management chains to get simple questions answered.
o Teams can take ownership and have pride in keeping systems or parts of a system
running well.
 Minuses
o Many developers don’t like to get involved with fix bugs or aren’t up to the
challenge of fitting new features into existing architectures – they find a position
elsewhere where full-time development is done.
o When a developer leaves, a significant amount of expertise about a system
disappears. Don’t have both the development group and maintenance group
expertise.
o New system development often gets a higher priority than maintenance, and thus,
maintenance work slides.
2.5.2 Separate Maintenance Organization
Maintenance and new development groups are under separate management branches. VP of
Maintenance and VP of Development may report to VP of Engineering.
 Pluses
o They will insist on good documentation and formal procedures from the
development group.
o Maintenance folks may be more objective than the designers in analyzing strengths
and weaknesses of a system.
o Separation of maintenance and development groups provides a system of checks
and balances.
o Generally establish and follow good software maintenance procedures because it is
their primary interest/business – maintenance does not compete with original
development.
o Some people really get into maintenance. Often maintenance people can do
rotations in customer support, user training, etc. as a break. This also gives
maintenance folks a perspective into how users break systems.
 Minuses
©2012 Mike Rowe
Page 6
7/13/2017
SE 386 Software Maintenance and Reengineering
Notes 001
o There is overhead in the transition or handover of a system from development
organization to the maintenance reorganization. Generally, more involved that just
saying, “here is a system with a couple million lines of code, have fun”.
o Maintenance burnout.
o Maintenance organizations may not have strong funding support due to visibility 
New product development generally takes front stage.
o Some extra overhead is involved in duplicated software, hardware, …
2.5.3 Team approaches
A team is responsible for both development and maintenance of a part of a system (like a
subsystem). People are not designated as either developers or maintenance. Folks are assigned
based on who is the most appropriate person for the task (based on availability and competing
needs).
 Sometimes this model is appropriate for long-lived evolving software systems – when new
releases are shipped every quarter or semiannually.
 Work can be prioritized based on importance.
 Have a team of people responsible to the development and maintenance of specific
subsystems. They allocate resources necessary for the care and feeding of the existing code
and the evolving system. Often junior members can learn system architecture by hunting
bugs and making small enhancements.
 Often builds strong sense of code ownership.
2.5.4 Matrix organizations



All resources belong to a central pool of engineers. Teams are formed from the pool and
report to a project manager for the duration of a project.
Advantages:
o Efficient utilization of people
Disadvantages:
o Little continuity on products
©2012 Mike Rowe
Page 7
7/13/2017