Software Reuse, Architectures, and Requirements Ronald J. Leach

1. Software Reuse, Architectures, and Requirements Ronald J. Leach

2. OUTLINE: Introduction Designing for reuse Using reuse to drive requirements Case studies Conclusion

3. What is software reuse? The process of developing software using previously created software components that: • have well-defined standard interfaces • are carefully tested • have a well-defined functionality • have precisely defined performance.

4. Many types of software artifacts can be reused: • Algorithms • Architectures • Complete applications • Data • Requirements

5. • Designs • Source code • Test plans and test cases • Documentation • Integration plans

6. Software reuse has many potential advantages: • Potential for reducing cost • Faster system development • Increased quality • More! Better! Cheaper! Faster!

7. Software reuse has potential disadvantages: • Systematic reuse plans cost money • Measurement is expensive • Potentially slower initial system development • Decreased, or unknown quality • Legal issues • Security issues

8. Possible objections to software reuse: • Destroys creativity • Not-Invented-Here syndrome • Hard to start systematic programs • Hard to measure savings • Hard to use COTS (Commercial- Off-The Shelf) software.

9. A success story: FORTRAN math libraries. Unfortunately most reuse situations are more complicated: • Difficult to identify needed functionality • Unstable domains,less well understood • Less modular organization • Evolving technology and standards • Fewer instances of reuse of each artifact

10. Unsystematic, or ad hoc, reuse programs are not generally successful • Often depend upon fortunate discussions of a few individuals with vast,unwritten, knowledge. • Hard to repeat successes • Hard to measure successes • Up-front analysis costs are ignored • Integration costs are not predicted accurately

11. Systematic software reuse includes most of: • Domain Analysis • Standard Interfaces • Object-Oriented Approaches • Metrics and Reuse Measurement • Designing for Reuse • Reuse-Driven Requirements Engineering

12. Systematic software reuse, continued: • COTS integration • Reuse library management • Configuration management • Certification • Cost modeling • Reengineering (if necessary)

13. Certification Issues: Quality metrics Standard interfaces Coding standards Documentation standards Performance standards

14. Cost Modeling Issues: • Life cycle phase where reuse occurs • Coding is a small portion of life cycle activities • Reuse of requirements leads to greatest savings • Percentage of system from reusable components • Amount of change in each reused component • Special issues with COTS products (standards, quality, integration costs,...) • Quality of reused component • Overhead of systematic reuse with measurement (selection, certification, repository maintenance) • How to charge general reuse overhead to projects

15. Designing for reuse: Use of standard interfaces and other standards. Use of existing high level building blocks and COTS products when possible. Designs should be changed if they use little existing software. Interface size and standards must be considered. Designs should be subjected to domain analysis.

16. • Designs should be rejected if they do not use the available reuse libraries. • Designs should be rejected if they do not contribute software artifacts to a reuse library. • Design teams must have both domain experts and domain analysts on the team. • Designing for reuse is more expensive than not, at least for the pure cost of design. Costs should be underwritten as part of a systematic reuse program.

17. Reuse-Driven Requirements • Get requirements from customer. • If an existing system meets requirements, done. • If not, 1. Perform domain analysis 2. Determine existing system closest to customer requirements. 3. Negotiate requirements with customer to determine if agreement on a system meeting fewer requirements but lower cost.

18. • If customer will not accept new proposed solution with reduced requirements, decompose system into subsystems. • Use classification scheme determined by domain analysis for the decomposition into subsystems. • For each subsystem, produce existing subsystem that either matches subsystem requirements or is closest to them. Negotiate reduced subsystem requirements with customer, allow selecting a subsystem with reduced functionality.

19. • Each negotiation with customer includes detailed descriptions of tradeoffs in capability vs.. reduced cost of system. Estimation of integration and maintenance costs is essential at each stage. • Continue the process of domain and system decomposition as much as necessary, • New code is to be written only as a last resort. • COTS-only systems are an extreme case. * Few models: (Waund, Ellis at Loral, Kontio, Basili at Maryland, IMACCS project at NASA/Goddard).

20. Skills needed for this approach: • Domain knowledge • Domain analysis • Software engineering economics • Negotiation

21. Common experiences with this approach: !. Considerable up-front effort 2. Hard to map requirements to specifications of existing SW. 3. Selection is harder than with source code. 4. Potential payoff is large.

22. The IMACCS project at NASA Goddard Goal - develop a substantial system for spacecraft control integrating COTS products. Results: • Considerable up-front cost savings. • Unknown quality of resulting product • Complete life cycle cost not known • Special Licensing Agreements with vendors

23. Landsat-7 Control System at NASA Goddard Evaluation of automatic requirements generation system vs.. COTS vs. standard development. • Mapping of requirements to system architecture. • Requirements may be repackaged • Aggregate requirements to match COTS specs • Separate requirements to atomic levels • Intermediate grouping • Emphasis on cost and quality measures.

24. First question - how much of the system can be assembled from COTS and GOTS? Lines of code irrelevant since measures of COTS are not available. Counting requirements cannot describe system complexity. Function point analysis characterizes system requirements more accurately.

25. Analysis of how requirements should be packaged is ongoing. Work of Keepence and Mannion * for European Space Agency suggests decomposing all requirements into atomic ones is better than aggregating them. Currently validating their approach. * (Tutorial at IEEE Symposium on Software Reusability, 1997)

26. A few related ongoing NASA Projects: • IMP-8 and other legacy systems Evaluation of reengineering/reuse potential. Development of metrics for process efficiency and product quality

27. Conclusion Systematic software reuse programs include: • knowledge of the domain • designing for reuse • using reuse to guide the requirements process

28. Biggerstaff, T., and A. Perlis, eds., Software Reusabiltiy, Vol. 1, No. 2, ACM Press, New York, 1989. Boehm, B., Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ, 1981. Griss, M., et al, Software Reuse: ACM Press, 1997. Hooper, J. W., and R. Chester, Software Reuse: Guidelines and Methods, Plenum Press, New York, 1991. Johnson, Ralph E., and Foote, Brian, "Designing reusable classes." Journal of Object-Oriented Programming, 1988, Vol.1, No. 2, 22-35. References

29. Kontio, J., "A Case Study in Applying a Systematic Method for COTS Selection," Proceedings of the 18th International Conference on Software Engineering, (ICSE-18), Berlin, Germany, March 25-29. Leach, R. J. , Software Reuse: Methods, Models, Costs, McGraw-Hill, New York, November, 1996. Leach, R. J., and T. L. Fuller, "An Illustration of the Domain Analysis Process," Software Engineering Notes, ACM, Vol. 20, No. 5, December, 1995, pp. 79-82. Prieto-Diaz, R., "Status Report: Software Reusability," IEEE Software, May, 1993, pp. 61-66. References, continued