1. CSE301 Harry R. Erwin, PhD University of Sunderland
Software Reuse
CSE301
Harry R. Erwin, PhD
University of Sunderland

2. Resources This lecture is about how to think critically about reuse.
Martin, R. C., 2003, Agile Software Development, Prentice-Hall.
Schmidt, D. C., 2003, “Why software reuse has failed and how to make it work for you,”
Radding, A., 1998, “Hidden Costs of Code Reuse,”

3. Why Reuse Software? What we most need are systems that are:
Portable
Flexible
Extensible
Predictable
Efficient
Reliable
(Schmidt, 2003)
Software meeting these qualities is hard to develop (and even harder to develop for reuse).

4. Software Economics and Reuse
Highly skilled software professionals are rare and expensive (~£12,000/person-month (PM) including overhead).
Productivity is low for essential and critical systems development ( lines of code per PM).
Modern systems are large ( PM) and costly (£1M-£100M).
Reuse can reduce these costs by three to ten-fold.
However, initially developing the software for reuse triples (x3) the cost. (Radding, 1998)
So reuse has a delayed payoff.

5. Why Does Reuse Fail?
Communications—how to make requirements reflect both programmer and business needs?
Economics—who pays for it?
Administration—who maintains the reuse libraries?
Politics—“rice bowls”.
Psychological—programmer resistance, NIH (“not invented here”).
Technical—how do you organize it?
(Schmidt, 2001)

6. What is Reuse?
Components, frameworks, and applications are what you reuse.
Components are self-contained instances of abstract data types that can be plugged together to create complete applications.
Frameworks are integrated collections of classes that support the following:
System infrastructure
Middleware integration
Enterprise applications
Both live in packages.

7. What do you reuse? GUI objects Server-side components
Infrastructure components
Services frameworks
High-level patterns
Packaged applications
(Radding, 1998)

8. GUI Object Reuse Easy to achieve Often requires no code development
Improves quality and consistency
Implications: good practice, but not a big cost driver, so does not save much money

9. Server-Side Components
Reusable business logic
Significant potential for pay-back
Require extensive front-end analysis and design
Have to be provided an architectural foundation
Require protection as trade secrets
Become obsolete fairly rapidly

10. Infrastructure Components and Services Frameworks
Provide standards-based generic services for transaction processing, messaging, security, and database access
Require extensive analysis and design and complex programming
Often available as commercial off-the-shelf (COTS)
“Make versus buy” decision

11. High-Level Patterns Will be addressed later in this module
Support design reuse
Must be programmed or purchased

12. Packaged Applications
Guaranteed reuse
Not necessarily a close match to the user requirements, so customization may be required
Locks the customer into the vendor, which is good for the vendor but not so good for the customer
End of life issues, as well