3 April

MaintenanceReverse Engineering

EthicsCathedral and Bazaar

Dilemma

Calendar Review of Online Course

Evaluation System

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

Alignment with objectives Cost benefit analysis

Process Impact Documentation Regression testing

Technical 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, … 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 semantic 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

Extreme programming re-factoring At some point, quality suffers

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 Laws1. 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.

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?

Quick fix that doesn’t go through the full process

When should it be used? 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

Disassemblers, decompilers, hex editors, … How useful are these? What can they do and not do?

Approaches to Understanding 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

Cathedral and Bazaar

Open Source

What is open source? http://

www.opensource.org/docs/definition.php

What is different about open source? Who are the developers?

Why is it beneficial?

The Cathedral and the Bazaar

Eric Raymond

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Different open source models

Cathedral Code developed between releases by exclusive set

of developers Bazaar

Code developed openly in public view Introduced by Linux and Linus Torvalds

Raymond’s Principles1. Every good work of software starts by scratching a

developer's personal itch.2. Good programmers know what to write. Great ones

know what to rewrite (and reuse). 3. “Plan to throw one away; you will, anyhow.'' (Brooks)4. If you have the right attitude, interesting problems

will find you. 5. When you lose interest in a program, your last duty to

it is to hand it off to a competent successor. 6. Treating your users as co-developers is your least-

hassle route to rapid code improvement and effective debugging.

7. Release early. Release often. And listen to your customers.

Raymond’s Principles (cont.)8. Given enough eyeballs, all bugs are shallow. 9. Smart data structures and dumb code works a lot

better than the other way around. 10. If you treat your beta-testers as if they're your most

valuable resource, they will respond by becoming your most valuable resource.

11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

13. “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' (Saint-Exupery)

Raymond’s Principles (cont.)14. Any tool should be useful in the expected way, but a

truly great tool lends itself to uses you never expected. 15. When writing gateway software of any kind, take pains to

disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

17. A security system is only as secure as its secret. Beware of pseudo-secrets.

18. To solve an interesting problem, start by finding a problem that is interesting to you.

19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Two Other Gems

Mythical Man-Month

Book of essays Very readable Still most heavily used software

engineering book

No Silver Bullet

Essence vs. Accident Essence is what makes it hard

specification, design, and testing of this conceptual construct

Accidents have been fixed labor of representing it and testing

the fidelity of the representation http://inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html