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

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

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

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.

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)

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.

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

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

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

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

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

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