Software Reuse

1. 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,” http://www.cs.wustl.edu/~schmidt/reuse-lessons.html • Radding, A., 1998, “Hidden Costs of Code Reuse,” http://www.informationweek.com/708/08iuhid.htm

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 (100-320 lines of code per PM). • Modern systems are large (100-10000 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