Software Reuse

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 6 months ago)

54 views

Software Reuse

By: Ben Poon and Elena
Corina

Ciobanu

submitted
to Professor
Shervin

Shirmohammadi

in partial fulfillment of the
requirements for the course ELG 5100

Agenda


Background


What is reuse?


What to reusable?


How to do it?


Benefits and Caveats


Tool example (
i
-
SAM)


Case Study Example (
Danfoss
)


Future Work

1

Background


Topic of study: building reusability into the software
development life cycle (LC)



Keep in mind, topic as old as time (in computer speak)


Object Oriented Programming was “new”


Before “Software Project Management” was popular


In fact, before “Agile” was popular



In other words, Google wasn’t there to do everything for us!
*gasp*

2

What is reuse?

Reuse

Recycle

Reduce

3

What to reuse?


Before:


Code modules (ex. Plug
-
ins
)


Data Structures (ex. Database Tables)


Entire Apps (CGI in web)


Now:


Any part of development
LC,
between iterations, or even project
-
to
-
project



4

How to do it?


Choose the right level of abstraction


Higher = better, until becomes counter
-
productive


Communication


Need to include “reuse” as part of task


Need to measure “reusability”


i.e. how adaptable is it?


Computer Aided Software Engineering (CASE) tools


Often use UML
-
like language

5

Sounds good but…


Code/binary reuse is simple enough to understand…



Requirements/Specifications reuse?


Categorized into “
Artefacts


6

Artefacts


Code Fragment (e.g. code, libraries)


Logical
program
structures (e.g. modules, data structures)


Functional structures (e.g. function specs)


Domain knowledge (e.g. physics, laws)


Knowledge
of development
process (LCs)


Environment
-
level
information (e.g. feedback)

7

Useful
Artefacts


Flexible


E.g., Transferable, Additive, Adaptable, Language Independent,
Modular, Simple


Proper Abstraction Levels


E.g., General use, but with well defined (use, I/O, dependencies)


Use (some sort of) Formal Notation


Machine Representable (e.g. identifiable by meta
-
data)


Predictable/Repeatable (e.g. no unexplainable output by an
algorithm)


8

Reuse in the Life Cycle


Implementation


Cross
-
language and/or platform libraries (e.g. CGI in web apps)


Design


Pseudo
-
code, flow diagrams, high level documentation, design
patters (e.g. Model
-
View
-
Controller)


Requirements


Higher level abstractions (e.g. Designing an OS, fault
-
tolerance,
UI, etc.)


Domain Analysis


General methodology for solving similar types of problems, very
high level (e.g. interactions, features, etc.)


Done in models: definition, knowledge representation, domain
-
specific language, instructional, functional




9

Reuse Process


Re
use
B
y
O
bject
-
O
riented
T
echniques
(REBOOT) methodology terms:

“Development
-
for
-
reuse”

“Development
-
by
-
reuse”

Sample Reuse
during Waterfall LC

10

Benefits


Made better:


Productivity, Reliability, Maintenance, Documentation, Cost

“A study of nine companies showed
reuse led to 84% lower project costs,
cycle time reduction of 70%, and
reduced defects”


“312 projects in aerospace industry
Average 20% increase in productivity;
20% reduction in customer
complaints; 25% reduction in time to
repair; 25% reduction in time to
produce the system”

11

Caveats


Was a unique skill to expert developer


No process, lack of core competencies, tools


Learned to program, now learn to un
-
program


Not universally successful


Often developed solutions were too specific


New expense (without guaranteed
ROI)


Unlikely with legacy software


Difficult when orchestrating between teams


Reusable items obsoleted by new standards


Inefficient components


Blackbox
-
like effect, adds complexity

12

Tool Example


i
-
SAM


Built in
-
house by
Space
Agency Center / Indian
Space Research
Organization

(SAC/ISRO)


i
nternal

S
oftware
A
sset
M
anagement


Uses Web 2.0 + MySQL backend


5 Steps:


1. Identify domains and subdomains


2. Identify actors


3. Determine
artefacts

to archive (for reuse)


4. Meta
-
data for archived
artefacts


5. Develop
i
-
SAM architecture and implement


Split into 10 modules:


1) User
Auth
, 2) (sub)domain management, 3) SAM
submission, 4) Asset
eval

+ acceptance, 5)
Search/Download, 6) Version control, 7)
Email
notification
,

8) Report Generation, 9) Security measures, 10) GUI

13

i
-
SAM GUI

14

Case Study


Danfoss


Power Industry, makes components for automation,
thermostats, heating/cooling controls, valves, etc…


Combined: Power Equipment (PE) and Solar Inverters (SI)


Requirements reuse method: projects can select from a set of
master “Company requirements” to use, but…


PE used a “direct requirements reuse” approach (I.e. no changes
can be made)


SI landscape changes (laws, specs, standards,
etc
)


SI
extended

methodology to “adjustable requirements reuse”


Color code to signify changeable parts


“Origin” field to map back to company


requirements


Added role “Requirements Owner”


Ensures requirements is proper


15

Danfoss

results

16


Table 1
shows the number of requirements and
the percentage
of
requirements reused.



The
main result is
the second
project was able to reuse in total over 80%
of
the requirements documented:


43
% of the requirements
are directly reused


38
% are reused with adjustments.

Danfoss

Lessons Learnt


Rationale


Difficult to determine what requirements are relevant or useful
(e.g. legacy requirements, new requirements), therefore, need to
add rationale to changes to stay sane


Structure of requirements


E.g. Business need versus standards compliancy.


Constraints


Limits nonsensical combinations


Useful, but rarely done, and time consuming, users are experts in
the field anyway.


Customize approach to application


Incrementally perform domain analysis and refine reusable assets
between projects


17

Future Work


Consider how to add reuse to other parts of the development
Life Cycle



Consider the implications of “reuse” in the different non
-
Waterfall methodologies (e.g. Agile, Scrum, etc.)



Consider metrics for reuse and how to determine the
thresholds of reuse (i.e. when does reuse become
detrimental?)



18

Conclusion


Take away: Rise of middle ware!



Reuse is possible in any part of the Software Development Life
Cycle.



General consensus is that reuse is beneficial, but this is not
always true.

19

References

1.
Cybulski
, Jacob L. "Introduction to software reuse."
Department of Information Systems, The University of
Melbourne, Parkville, Australia

(1996)
.

2.
Jalender
,
Govardhan

and
A.
Premchand
.

"
Designing Code
Level Reusable Software Components."
International
Journal
of Software Engineering & Applications (IJSEA), Vol.3, No.1,
January
2012

3.
Verma
,
Yogesh
, and R.
Nandakumar
. "Development of
software asset management system to facilitate software
reuse." (2012): 9
-
9.

4.
Hauksdottir
,
Dagny
, Arne
Vermehren
, and
Juha

Savolainen
.
"Requirements reuse at
Danfoss
."
Requirements Engineering
Conference (RE), 2012 20th IEEE International
. IEEE, 2012.


20

Thank
You!

21