8 April
Maintenance
Reverse Engineering
Ethics
Software Engineering
Elaborated Steps









Concept
Requirements
Architecture
Design
Implementation
Unit test
Integration
System test
Maintenance
Best (and Worst) Testing Practices
(Boris Beizer)













Unit testing to 100% coverage: necessary but not sufficient for new or
changed
Integration testing: at every step; not once
System testing: AFTER unit and integration testing
Testing to requirements: test to end users AND internal users
Test execution automation: not all tests can be automated
Test design automation: implies building a model. Use only if you can
manage the many tests
Stress testing: only need to do it at the start of testing. Runs itself out
Regression testing: needs to be automated and frequent
Reliability testing: not always applicable. statistics skills required
Performance testing: need to consider payoff
Independent test groups: not for unit and integration testing
Usability testing: only useful if done early
Beta testing: not instead of in-house testing
Maintenance: the Final Chapter
Cost of Maintenance


Estimates of percentage of total life
cycle cost: 40% - 90%
Cost of fixing a bug





Requirements 1x
Design 5x
Coding 10x
Testing 20x
Delivery 200x
Problems of Maintenance

Organizational



Process




Impact
Documentation
Regression testing
Technical


Alignment with objectives
Cost benefit analysis
Building software that is maintainable
Professional hierarchy
Objectives of Maintenance




Change over time!
At release: bug-free
Six months later: competitive or
competition-leading features
Two years later: reduce maintenance
cost
Building Maintainable Software

Code

Well documented code




Names, headers, style, …
Can names be too long?
Decoupled code
Documentation


Architecture, design documentation, use
cases, requirements, …
But only if maintained!!!!!
Software Maintenance Types




Adaptive maintenance: changes needed as a
consequence of operation system, hardware, or
DBMS changes
Corrective maintenance: the identification and
removal of faults in the software
Perfective maintenance: changes required as a
result of user requests
Preventive maintenance: changes made to
software to make it more maintainable
Why adaptation?

Lehman’s Law (1985): if a program
doesn’t adapt, it becomes increasingly
useless


Example: programs that didn’t adapt to the
web
The majority of maintenance is
concerned with evolution deriving from
user requested changes
Lehman’s Second Law

As an evolving program changes, its structure
tends to become more complex


Extra resources must be devoted to preserving the
semantics and simplifying the structure
For most software, nothing has been done
about it, so changes are increasingly more
expensive and difficult
Reengineering

Code gets messy over time


At some point, quality suffers



Extreme programming re-factoring
Changes slow
Fixes introducing errors
Need to invest in the code!



Rules as to when to rewrite a module
Abstractions: variables -> methods
Harder: when is REDESIGN needed?
Lehman’s Five Laws
1. The law of continuing change: A program that is used in a real-world
environment necessarily must change or become less and less useful in that
environment.
2. The law of increasing complexity: As an evolving program changes, its
structure becomes more complex unless active efforts are made to avoid this
phenomenon.
3. The law of large program evolution: Program evolution is a self-regulating
process and measurement of system attributes such as size, time between
releases, number of reported errors, etc., reveals statistically significant trends
and invariances.
4. The law of organizational stability: Over the lifetime of a program, the rate
of development of that program is approximately constant and independent of
the resources devoted to system development.
5. The law of conservation of familiarity: Over the lifetime of a system, the
incremental system change in each release is approximately constant.
Lehman, M. and Belady, L. (1985). Program Evolution: Processes of Software Change, volume
27 of A.P.I.C. Studies in Data Processing. Academic Press.
Lehman M.M. and Ramil J.F. (2001), “Rules and Tools for Software Evolution Planning and
Management”, Annals of Software Eng., spec. issue on software management, vol. 11, pp.
15-44.
Steps for handling a change







Understand the problem
Design the changes
Analyze impact
Implement changes
Update documentation
Regression test
Release
Cost Benefit (Risk) Analysis





Will this problem reduce the number of
programs that I sell?
Will this problem impact future sales?
How many people will it affect?
How important are the customers it will
affect?
Is it a “show stopper” or an annoyance?
Patches

What is a patch?


When should it be used?


Quick fix that doesn’t go through the full process
Error that is preventing use of the system
Problems with use




Multiple patches can be order dependent
Users can barely track which ones have been
applied
Code version explosion
Permanent fix may or may not be compatible
Legacy Systems

Existing systems that are still useful

May not want to invest in enhancements


Future functions will use new process
May not be able to easily modify



Unsupported language or libraries
Lack of skills
No source code available!
Handling Legacy Systems

Incorporation


Business as usual
Encapsulation


Accessed from new system
Adapters


Wrapper around the legacy system
Adapters in new system
Reverse Engineering
Reverse Engineering

What is it?



Discovering the technology through
analysis of a program’s structure and
operation
Analyzing a system to identify its
components and interrelationships in order
to create a higher abstraction
Is it legal?

Associated with hackers and crackers
Fundamental Problem
Understanding code
with …



no comments
meaningless
variable names
no visible structure
void p (int M)
{
int c = 2;
while (c <= M)
{
int t = 2;
boolean f = true;
while (t ** 2 <= c)
{
if (c % t == 0)
{
f = false;
break;
}
t++;
}
if (f) l(c);
c++;
}
}
Reverse Engineering

Lots of tools for simple translation




Approaches to Understanding





Disassemblers, decompilers, hex editors, …
How useful are these?
What can they do and not do?
Source-to-source translation
Object recovery and specification
Incremental approaches
Component-based approaches
Wikibook on the topic
http://en.wikibooks.org/wiki/Reverse_Engineering
Uses of Reverse Engineering

Reasonably legal









managing clearly owned code
recovery of data from proprietary file formats
creation of hardware documentation from binary drivers (often
used for producing Linux drivers)
enhancing consumer electronics devices
malware analysis
discovery of undocumented APIs (but probably a bad idea)
criminal investigation
copyright and patent litigation
Probably unethical even when legal


malware creation, often involving a search for security holes
breaking software copy protection (games and expensive
engineering software)
Digital Millennium Copyright Act (1998)


Criminalizes production and dissemination of
technology that can circumvent measures
taken to protect copyright
Exceptions



Interoperability between software components
Retrieval of data from proprietary software
Full text

http://www.copyright.gov/legislation/dmca.pdf
Ethics
ACM Code of Ethics and Professionalism
(Excerpt)

GENERAL MORAL IMPERATIVES









Contribute to society and human well-being
Avoid harm to others
Be honest and trustworthy
Be fair and take action not to discriminate
Honor property rights including copyrights and patent
Give proper credit for intellectual property
Respect the privacy of others
Honor confidentiality
ORGANIZATIONAL LEADERSHIP IMPERATIVES





Articulate social responsibilities
Enhance the quality of working life
Proper and authorized uses of computing and communication resources
Ensure that those affected by a system have their needs clearly articulated;
validate the system to meet requirements
Protect the dignity of users
Intellectual Honesty
(McConnell, Code Complete)






Refusing to pretend you’re an expert when you’re not
Readily admitting your mistakes
Trying to understand a compiler warning rather than
suppressing the message
Clearly understanding your program – not compiling
it to see if it works
Providing realistic status reports
Providing realistic schedule estimates and holding
your ground when management asks you to adjust
them
Whistle Blowing



What are the alternatives?
When is it okay?
When is it not a choice?
Ethics of a project





intended use
potential misuse
consequences
fairness to the knowing users
implications for unknowing users