Download
software reuse n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Reuse PowerPoint Presentation
Download Presentation
Software Reuse

Software Reuse

138 Vues Download Presentation
Télécharger la présentation

Software Reuse

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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!