1 / 22

Software Reuse

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)

ayanna
Download Presentation

Software Reuse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Reuse By: Ben Poon and Elena CorinaCiobanu submitted to Professor ShervinShirmohammadi in partial fulfillment of the requirements for the course ELG 5100

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

  3. 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*

  4. What is reuse? Reduce Recycle Reuse

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

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

  7. Sounds good but… • Code/binary reuse is simple enough to understand… • Requirements/Specifications reuse? • Categorized into “Artefacts”

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

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

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

  11. Reuse Process Sample Reuse during Waterfall LC • Reuse By Object-Oriented Techniques (REBOOT) methodology terms: “Development-for-reuse” “Development-by-reuse”

  12. 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”

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

  14. Tool Example – i-SAM • Built in-house by Space Agency Center / Indian Space Research Organization (SAC/ISRO) • internalSoftware Asset Management • 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

  15. i-SAM GUI

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

  17. Danfoss results • 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.

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

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

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

  21. References • Cybulski, Jacob L. "Introduction to software reuse." Department of Information Systems, The University of Melbourne, Parkville, Australia (1996). • Jalender, Govardhan and A. Premchand."Designing Code Level Reusable Software Components." International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.1, January 2012 • Verma, Yogesh, and R. Nandakumar. "Development of software asset management system to facilitate software reuse." (2012): 9-9. • Hauksdottir, Dagny, Arne Vermehren, and JuhaSavolainen. "Requirements reuse at Danfoss." Requirements Engineering Conference (RE), 2012 20th IEEE International. IEEE, 2012.

  22. Thank You!

More Related