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

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

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

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

Software Reuse

CSE301Harry R. Erwin, PhD

University of Sunderland

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

ResourcesThis 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

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

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

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

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.

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

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)

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

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.

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

What do you reuse?

• GUI objects• Server-side components• Infrastructure components• Services frameworks• High-level patterns• Packaged applications

(Radding, 1998)

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

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

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

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

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

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

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

High-Level Patterns

• Will be addressed later in this module

• Support design reuse• Must be programmed or purchased

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

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