These are the lecture notes I created which I used to revise for the CS3003 Software Engineering exam at Brunel University in which I received a First Class in.
Module: CS3003
Lecture Topic: Software Maintenance and Evolution
Week: 2
Software Maintenance
The process of modifying a software system or component (class/method) to corrects bugs
(faults/defects/errors), improve performance or other attributes, or adapt to a changed
environment.
Software maintenance is once software has been initially developed, and then repeatedly updating it
for various reasons.
• Maintenance of evolving software is unavoidable, continuous and essential
• Important to design for maintenance. When you design a system, how much maintenance is
anticipated. Design a system to allow for maintenance to be minimal.
• Think about why software maintenance is so difficult.
Types of Maintenance
Adaptive maintenance
• Adapting to changes in the environment, both hardware and software (new laws etc)
Corrective maintenance
• Correcting errors/bugs
Perfective maintenance
• Making what’s there “better”, making the code which works, better, more understandable,
efficiency, speed, simplified.
Preventative maintenance
• Future proofing the code for later. Taking steps now so that for future, any problems that
arise will be handled.
,Key to maintenance
During Development
• Higher quality code = less corrective maintenance, better code, less bugs
• Anticipating changes = less adaptive maintenance
• Better development practices = better code = less perfective maintenance
• Better tuning to user needs = less maintenance overall
• Less code = less maintenance overall
-Avoid code “bloat” = too much code, a lot may be unnecessary.
-Avoid smells emerging
Maintenance is expensive
• 70% of software costs attributed to maintenance
• Costs vary across application domain. E.g. real time system costs more than a game/due to
the nature of the system. Such as software for nuclear reactor.
Maintenance is difficult
• 47% of effort goes into understanding the system and identifying dependencies
• Making changes is risky due to ripple and side effects
• Can be a low morale job
Factors that affect maintenance & evolution
1. Team stability: are staff leaving/joining or the same people through the development
2. Poor development practice, quality of code
3. Staff skills: relates to ^
4. Program age and structure. Systems will decline overtime, worth it to keep system/maintain
it?
5. The amount of technical debt in a system
• The result of not doing maintenance when you should
• The ignored maintenance will come back to haunt you later
Two factors that help us manage software evolutions
1. Change management
• Many change requests are generated for most systems
• Need to ensure that change is implemented rationally
• Factors that need to be considered include urgency, value, impact, benefit, cost
Usually companies have a team who analyse and prioritise change requests
In XP customers involved in prioritising changes.
, 2. Version Control
• A repository of the first version of the system and all subsequent changes made to it
• Subsequent version stored in the form of diffs
• All software has multiple versions (branches)
-Different platforms
-Different customer variants
-Different stages in the lifecyle
Need to be able to:
• Recreate old versions
• Keep track of and control changes
• Support independent development
Why is version control important?
• Stops changes being made to the wrong version
• Prevents the wrong version being delivered to a user
• Controlling change is a major issue
-“Requirements creep” is prevented. Overload of requests for different changes
(new requirements) Overly burdened for the new requirements.
-Many change requests will be generated – so controlling it is important
• Allows the right files to be associated with the right version/release
• A change can be rolled back
• Concurrent changes by developers controlled
• The evolution of the system tracked
• New releases, versions, families of software can be developed in a more organised way
• Can help in fault identification
• Who and when made a particular change is recorded
Relevant topics to Maintenance and system evolution
• Software Evolution Theory
Lehman’s Laws of Software Evolution
1. Continuing Change: A system must be continually adapted else it becomes progressively less
satisfactory in use
2. Increasing Complexity: As a system evolves its complexity increases unless work is done to
maintain or reduce it
3. Continuing Growth: The functional capability of systems must be continually increased to maintain
user satisfaction over the system lifetime
4. Declining Quality: Unless rigorously adapted to take into account changes in the operational
environment, the quality of a system will appear to decline as it is evolved
5. Feedback System: Evolution processes are multi-level, multi-loop, multi-agent feedback systems
, • Defensive Programming
A technique where you assume the worst for all inputs.
This helps maintenance because you are insuring for the future
Rules of defensive programming:
• Rule 1: Never assume anything about the input
Most problems in code comes from unexpected input (e.g. negative age)
• Rule 2: Use standards
Using a proper coding standard and stuck to it such as positions of brackets in Java
• Rule 3: Keep your code as simple as possible
Reuse wherever possible because it is usually more trusted and documented
• Defensive programming conforms to the “fail fast” principle
-Get the bugs out of the systems asap
• Techniques:
-Use diagnostic code
-Standardise error handling
-Use exception handling and assertions
-Always test external API and library references
-Assume nothing about the input (expect the worse)
• Mob Programming
A software development approach where the whole team works on the same thing at the same
time, same place, same computer. Not pair programming. Group programming
Builds on the principles of lean manufacturing, XP, and lean software development.
Covers definition of user stories requirements, designing, coding, testing, deploying software, and
working with the customer and business experts
Work is handled in working meetings or workshops:
• All involved in creating the software and considered to be team members, including the
customer and business experts
• Also works for distributed teams in the same virtual space using screen sharing.
May be difficult due to the organisational aspects, .e.g. meeting times. Shown to be useful as it
produces robust code and critical part of the system where everyone’s input is essential.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller cslbrunel. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $9.13. You're not tied to anything after your purchase.
