Sofhware life cycle-The series of stages a software system goes through during its development and deployment.While the specific stages differ from one project to the next,they generally include the activities of requirements specification,design,code, testing and maintenance 3.2 Expected Benefits of Reuse Software reuse clearly has the potential to improve productivity and hence reduce cost:it also improves the quality of software systems. Productivity Improvement.The obvious benefit of software reuse is improved productivity. resulting in cost savings.This productivity gain is not only in code development,costs are also saved in analysis.design.and testing phases.Systems built from reusable parts also have the potential for improved performance and reliability,because the reusable parts can be highly optimized and will have been proven in practice.Conformance to standard design paradigms will reduce training costs.allow more effective practice of quality disciplines.and reduce schedule risk Reduced Maintenance Cost.Even more significantly,reuse reduces maintenance cost. Because proven parts are used,expected defects are fewer.Also,there is a smaller body of software to be maintained.For example,if a maintenance organization is responsible for several different systems with a common graphic user interface,only one fix is required to correct a problem in that software,rather than one for each system. Improved Interoperability.A more specialized benefit is the opportunity to improve interoperability among systems.Through the use of single implementations of interfaces, systems will be able to more effectively interoperate with other systems.For example,if multiple communications systems use a single software package to implement the X.25 protocol,it is very likely that they will be able to interact correctly.Following a written standard has much less guarantee of compatible interpretation. Support for Rapid Prototyping.Another benefit of reuse is support for rapid prototyping,or putting together quick operational models of systems,typically to get customer or user feedback on the capability.A library of reusable components provides an extremely effective basis for quickly building application prototypes Reduced Training Cost.Finally.reuse reduces training cost,or the less formal cost associated with employee familiarization with new assignments.It is a move toward packaged technology that is the same from system to system.Just as hardware engineers work with the same basi repertoire of available chips when designing different kinds of systems,software engineers will work with a library of reusable parts with which they will become familiar and adept. Industry Examples.All of these benefits lead directly to lower-cost,higher-quality software. Some industry experiences have shown such improvements: 3-2
3-2 Software life cycle—The series of stages a software system goes through during its development and deployment. While the specific stages differ from one project to the next, they generally include the activities of requirements specification, design, code, testing, and maintenance. 3.2 Expected Benefits of Reuse Software reuse clearly has the potential to improve productivity and hence reduce cost; it also improves the quality of software systems. Productivity Improvement. The obvious benefit of software reuse is improved productivity, resulting in cost savings. This productivity gain is not only in code development; costs are also saved in analysis, design, and testing phases. Systems built from reusable parts also have the potential for improved performance and reliability, because the reusable parts can be highly optimized and will have been proven in practice. Conformance to standard design paradigms will reduce training costs, allow more effective practice of quality disciplines, and reduce schedule risk. Reduced Maintenance Cost. Even more significantly, reuse reduces maintenance cost. Because proven parts are used, expected defects are fewer. Also, there is a smaller body of software to be maintained. For example, if a maintenance organization is responsible for several different systems with a common graphic user interface, only one fix is required to correct a problem in that software, rather than one for each system. Improved Interoperability. A more specialized benefit is the opportunity to improve interoperability among systems. Through the use of single implementations of interfaces, systems will be able to more effectively interoperate with other systems. For example, if multiple communications systems use a single software package to implement the X.25 protocol, it is very likely that they will be able to interact correctly. Following a written standard has much less guarantee of compatible interpretation. Support for Rapid Prototyping. Another benefit of reuse is support for rapid prototyping, or putting together quick operational models of systems, typically to get customer or user feedback on the capability. A library of reusable components provides an extremely effective basis for quickly building application prototypes. Reduced Training Cost. Finally, reuse reduces training cost, or the less formal cost associated with employee familiarization with new assignments. It is a move toward packaged technology that is the same from system to system. Just as hardware engineers work with the same basic repertoire of available chips when designing different kinds of systems, software engineers will work with a library of reusable parts with which they will become familiar and adept. Industry Examples. All of these benefits lead directly to lower-cost, higher-quality software. Some industry experiences have shown such improvements:
Raytheon Missile Systems the redundaney in its busines systems nd euse program In an ysis r over 00pr9 programs,three major classes were were designed for each class,and a library of parts developed by modifying existing modules to fit the architectures.Raytheon reports an average of 60%reuse and 50%net productivity increase in new developments. NEC Software Engineering Laboratory analyzed its business applications and identified 32 logic templates and 130 common algorithms.A reuse library was established to catalogue these templates and components.The library was automated and integrated into NEC's software development environment,which enforces reuse in all stages of development.NEC reports a 6.7:1 productivity improvement and 2.8:1 quality improvement Fujitsu analyzed its existing electronic switching systems and catalogued potential reusable parts in its Information Support Center-a library staffed with domain experts. software engineers,and reuse experts.Use of the library is compulsory;library staff members are included in all design reviews. With this a Fujitsu has mpro ement fror m2006。 fprojects on chedule in ng system evelopmen and porate. GTE Data Services has established a co clude ida these assets in an automa e -wide reuse program.Its activities t mainter o14%mago support,an managemer support group.GTE st ye 1.5 million,and projected million savings,in telephony management software development SofTech,Inc.employs a generic architecture approach in building Ada compiler products.Compilers for new host and target systems can be developed by replacing only selected modules from the standard architecture.This has led to productivity leve of 50K lines of code per person-year(10-20 times the industry average).This is typical of compiler developers,as this is a field in which reuse is accepted practice. Universal Defence Systems(UDS),in Perth,Australia,develops Ada command and control applications.The company began its work in this business with a reuse focus and has developed a company-owned library of 396 Ada modules comprising 400-500 thousand LOC.With this base,UDS developed the Australian Maritime Intelligent Support Terminal with approximately 60%reuse,delivering a 700 thousand LOC system in 18 months.A recently begun new project anticipates 50-70%reuse based on Bofors Electronics had a requirement to develop command control and communications systems for five ship classes As each ship class was specific to a different country,there are antly different require nts for each.'In order to e efit fro Bofo gle gene a se scale reusa ole parts to fit that we -structured design,interna reuse,anc a transition to Ad rn CAS. tools, productivity improvement even in building the first ship-from 1.3 lines of code(LOC per hour previously to 3.28 LOC per hour.Improvements are much greater for 3-3
3-3 • Raytheon Missile Systems recognized the redundancy in its business application systems and instituted a reuse program. In an analysis of over 5000 production COBOL programs, three major classes were identified. Templates with standard architectures were designed for each class, and a library of parts developed by modifying existing modules to fit the architectures. Raytheon reports an average of 60% reuse and 50% net productivity increase in new developments. • NEC Software Engineering Laboratory analyzed its business applications and identified 32 logic templates and 130 common algorithms. A reuse library was established to catalogue these templates and components. The library was automated and integrated into NEC’s software development environment, which enforces reuse in all stages of development. NEC reports a 6.7:1 productivity improvement and 2.8:1 quality improvement. • Fujitsu analyzed its existing electronic switching systems and catalogued potential reusable parts in its Information Support Center—a library staffed with domain experts, software engineers, and reuse experts. Use of the library is compulsory; library staff members are included in all design reviews. With this approach, Fujitsu has experienced an improvement from 20% of projects on schedule to 70% on schedule in electronic switching systems development • GTE Data Services has established a corporate-wide reuse program. Its activities include identification of reusable assets and development of new assets, cataloguing of these assets in an automated library, asset maintenance, reuser support, and a management support group. GTE reports first year reuse of 14% and savings of $1.5 million, and projected figures of 50% reuse and $10 million savings, in telephony management software development • SofTech, Inc. employs a generic architecture approach in building Ada compiler products. Compilers for new host and target systems can be developed by replacing only selected modules from the standard architecture. This has led to productivity level of 50K lines of code per person-year (10-20 times the industry average). This is typical of compiler developers, as this is a field in which reuse is accepted practice. • Universal Defence Systems (UDS), in Perth, Australia, develops Ada command and control applications. The company began its work in this business with a reuse focus, and has developed a company-owned library of 396 Ada modules comprising 400-500 thousand LOC. With this base, UDS developed the Australian Maritime Intelligent Support Terminal with approximately 60% reuse, delivering a 700 thousand LOC system in 18 months. A recently begun new project anticipates 50-70% reuse based on the company’s asset library. • Bofors Electronics had a requirement to develop command, control, and communications systems for five ship classes. As each ship class was specific to a different country, there are significantly different requirements for each. In order to benefit from reuse, Bofors developed a single generic architecture and a set of largescale reusable parts to fit that architecture. Because of a well-structured design, internal reuse, and a transition to Ada and modern CASE tools, Bofors experienced a productivity improvement even in building the first ship—from 1.3 lines of code (LOC) per hour previously to 3.28 LOC per hour. Improvements are much greater for
subsequent ships,with a projected productivity of 10.93 LOC per hour for the fifth ship. which is expected to obtain 65%of its code from reuse 3.3 Dimensions of Reuse Reuse has several dimensions;the guidance in this manual supports all of thes Compositional versus Generative Approaches.Approaches to reuse may be classified as either compositional or generative.Compositional approaches support the bottom-up development of systems from a library of available lower-level components.Much work has been devoted to classification and retrieval technology and to the development of automated systems to support this process.Generative approaches are application domain specific;they adopt a standard domain architecture model(a generic architecture)and standard interfaces for the components.Their goal is to be able to automatically generate a new system from an appropriate specification of its parameters.(The Fourth Generation Languages [4GLs]used in the commercial world can be considered an example of generative reuse.)Such approaches can be highly effective in very well understood domains,but significant effort is required to develop the initial model Small-scale versus Large-scale Reuse.Another dimension is the scale of the reusable components.Reuse on asmall scale-for example,use ofa library of mathematical functions is practiced fairly widely today.The effort saved from a single reuse is not great:payoff comes from the widespread reuse that is possible.On a large scale,entire subsystems(for example,an aircraft navigation subsystem or a message handling subsystem)may be reused.Here the saving from a single reuse is great;many thousands of lines of code may be reused.However, the opportunities for reuse of a given component are more limited.Large-scale reuse can pay for itself even if a component is only reused once or twice,because of the amount of effort saved. As-is Reuse versus Reuse with Modification.Components may be reused as is,or may required modification.Generally reusable components are designed to be flexible-fo example,through parameterization-but often modification is necessary to meet the reuser's requirement.Modifiability -the capability of a software component to be easily modified-is particularly important in reusable software. Generality versus Performance.Sometimes there is a trade-off between component generality and performance.A component designed to be general and flexible will often include extra processing to support that generality.Appropriate reusability guidelines help avoid this penalty:guidelines for the reuser can provide mechanisms for coping with performance problems that may arise 34
3-4 subsequent ships, with a projected productivity of 10.93 LOC per hour for the fifth ship, which is expected to obtain 65% of its code from reuse. 3.3 Dimensions of Reuse Reuse has several dimensions; the guidance in this manual supports all of these. Compositional versus Generative Approaches. Approaches to reuse may be classified as either compositional or generative. Compositional approaches support the bottom-up development of systems from a library of available lower-level components. Much work has been devoted to classification and retrieval technology and to the development of automated systems to support this process. Generative approaches are application domain specific; they adopt a standard domain architecture model (a generic architecture) and standard interfaces for the components. Their goal is to be able to automatically generate a new system from an appropriate specification of its parameters. (The Fourth Generation Languages [4GLs] used in the commercial world can be considered an example of generative reuse.) Such approaches can be highly effective in very well understood domains, but significant effort is required to develop the initial model. Small-scale versus Large-scale Reuse. Another dimension is the scale of the reusable components. Reuse on a small scale—for example, use of a library of mathematical functions— is practiced fairly widely today. The effort saved from a single reuse is not great; payoff comes from the widespread reuse that is possible. On a large scale, entire subsystems (for example, an aircraft navigation subsystem or a message handling subsystem) may be reused. Here the saving from a single reuse is great; many thousands of lines of code may be reused. However, the opportunities for reuse of a given component are more limited. Large-scale reuse can pay for itself even if a component is only reused once or twice, because of the amount of effort saved. As-is Reuse versus Reuse with Modification. Components may be reused as is, or may required modification. Generally reusable components are designed to be flexible—for example, through parameterization—but often modification is necessary to meet the reuser’s requirement. Modifiability—the capability of a software component to be easily modified—is particularly important in reusable software. Generality versus Performance. Sometimes there is a trade-off between component generality and performance. A component designed to be general and flexible will often include extra processing to support that generality. Appropriate reusability guidelines help avoid this penalty; guidelines for the reuser can provide mechanisms for coping with performance problems that may arise
3.4 Forms of Reuse Reusable components are not necessarily code;they can be specifications, designs,code,tests,or documentation Specification Reuse.Reuse of specifications is particularly relevant when aiming for large scale reuse.Large-scale reuse requires up-front consideration during the requirements definition activity.If an entire subsystem is to be designed for reuse,this should be made explicit from the start.The specification is then reusable in systems that will reuse the component,guaranteeing that requirements will match.Reuse of specifications greatly increases the likelihood that design and code will also be reusable.Furthermore,reuse of specifications can reduce time spent on requirements definition and help ensure interoperability,even if neither design or code are reused Design Reuse.Sometimes a design can be reused even when the code cannot;for example,the code may not be in the required programming language,or it may have inappropriate environment dependencies.Design reuse can save significant effort in one of the most costly life-cycle phases,provided that the design is specified so as to facilitate reuse.Furthermore,the design phase establishes the software architecture that provides a framework for reuse.Reuse of the software architecture will provide significantly greater code reuse opportunities by establishing a standard functional allocation and uniform interfaces. Code Reuse.The greatest payoff comes from reuse of actual code.Clearly this is possible only when the specification and design are also reusable.Reusable code should be accompanied by its associated life-cycle products-its requirements and design specifications,its tests,and its documentation-so the reuser will not have to regenerate them Test Reuse.Ideally,a reusable code component should be accompanied by test cases that can be used to test it in the environment in which it is reused.A less obvious point is that tests can be reusable even when code is not,with reusable test cases accompanying specification reuse. An example might be the reuse of a specification and a set of test cases for a particular communications protocol.Even if the design and implementation differ from the original, specification and test reuse will save effort and help ensure correctness and interoperability Documentation Reuse.Documentation is a major source of software development cost.To be most valuable,a reusable component must be accompanied by appropriate documentation items.Clearly,reuse of a specification or design is only meaningful when the component is in a written form.However,other documentation such as users manuals may also be reusable, even when the code is not. 35
3-5 3.4 Forms of Reuse Reusable components are not necessarily code; they can be specifications, designs, code, tests, or documentation. Specification Reuse. Reuse of specifications is particularly relevant when aiming for large scale reuse. Large-scale reuse requires up-front consideration during the requirements definition activity. If an entire subsystem is to be designed for reuse, this should be made explicit from the start. The specification is then reusable in systems that will reuse the component, guaranteeing that requirements will match. Reuse of specifications greatly increases the likelihood that design and code will also be reusable. Furthermore, reuse of specifications can reduce time spent on requirements definition and help ensure interoperability, even if neither design or code are reused. Design Reuse. Sometimes a design can be reused even when the code cannot; for example, the code may not be in the required programming language, or it may have inappropriate environment dependencies. Design reuse can save significant effort in one of the most costly life-cycle phases, provided that the design is specified so as to facilitate reuse. Furthermore, the design phase establishes the software architecture that provides a framework for reuse. Reuse of the software architecture will provide significantly greater code reuse opportunities by establishing a standard functional allocation and uniform interfaces. Code Reuse. The greatest payoff comes from reuse of actual code. Clearly this is possible only when the specification and design are also reusable. Reusable code should be accompanied by its associated life-cycle products—its requirements and design specifications, its tests, and its documentation—so the reuser will not have to regenerate them. Test Reuse. Ideally, a reusable code component should be accompanied by test cases that can be used to test it in the environment in which it is reused. A less obvious point is that tests can be reusable even when code is not, with reusable test cases accompanying specification reuse. An example might be the reuse of a specification and a set of test cases for a particular communications protocol. Even if the design and implementation differ from the original, specification and test reuse will save effort and help ensure correctness and interoperability. Documentation Reuse. Documentation is a major source of software development cost. To be most valuable, a reusable component must be accompanied by appropriate documentation items. Clearly, reuse of a specification or design is only meaningful when the component is in a written form. However, other documentation such as users manuals may also be reusable, even when the code is not
3.5 Issues in Achieving Reuse Reuse involves significant change to traditional practice;there a number of challenges to be overcome in achieving its full benefits. Identifying Opportunities for Reuse.A major technical issue is simply identifying opportunities for reuse.A software engineer may know that similar software has been written before;finding it is another matter.Reuse libraries help solve this problem.Once a component is found.it may be hard to determine if it is indeed a fit,and hard to modify it if change is required.Often software that appears to be reusable in fact will not be-it has inappropriate interfaces,hidden dependencies,inflexible functional limitations,or is simply so difficult to understand that the engineer will be better off simply starting over.The objective of software reusability guidelines is to help avoid these problems. Investment.Making software that is reusable generally requires investment above and beyond that required for a one-time system.This effort goes into making the software more flexible ensuring its quality,and providing additional documentation required.Each organization must make decisions about how the investment is supported. The"Not Invented Here"Syndrome.Sometimes developers are unwilling to reuse software Software engineers enjoy the creative aspects of their profession,and can feel that these are diminished when reusing software.Management encouragement,training,and perhaps other incentives can help engineers shift to a view of reativity that involves larger"uilding blocks"-reusable software components. Estimating and Measuring.Estimating and measuring software development activities has always been difficult,but there are some organizational methods in place that work relatively well.These traditional methods will require modification in a reuse environment,and little data is available to support that modification. Contractual,Legal,and Ownership Issues.There are a number of contractual,legal,and ownership issues that impact software reuse.Today's usual contracting methods can create a disincentive for contractors to reuse existing software or to provide software for reuse by others.Legal issues arise over liabilities and warranties.Responsibility for maintenance mus be identified. These organizational challenges are,for the most part,outside the scope of this set of manuals. Each organization must develop its own solutions.Managers must be aware of the challenges and address them if reuse is to succeed. 3-6
3-6 3.5 Issues in Achieving Reuse Reuse involves significant change to traditional practice; there a number of challenges to be overcome in achieving its full benefits. Identifying Opportunities for Reuse. A major technical issue is simply identifying opportunities for reuse. A software engineer may know that similar software has been written before; finding it is another matter. Reuse libraries help solve this problem. Once a component is found, it may be hard to determine if it is indeed a fit, and hard to modify it if change is required. Often software that appears to be reusable in fact will not be—it has inappropriate interfaces, hidden dependencies, inflexible functional limitations, or is simply so difficult to understand that the engineer will be better off simply starting over. The objective of software reusability guidelines is to help avoid these problems. Investment. Making software that is reusable generally requires investment above and beyond that required for a one-time system. This effort goes into making the software more flexible, ensuring its quality, and providing additional documentation required. Each organization must make decisions about how the investment is supported. The “Not Invented Here” Syndrome. Sometimes developers are unwilling to reuse software. Software engineers enjoy the creative aspects of their profession, and can feel that these are diminished when reusing software. Management encouragement, training, and perhaps other incentives can help engineers shift to a view of creativity that involves larger “building blocks”—reusable software components. Estimating and Measuring. Estimating and measuring software development activities has always been difficult, but there are some organizational methods in place that work relatively well. These traditional methods will require modification in a reuse environment, and little data is available to support that modification. Contractual, Legal, and Ownership Issues. There are a number of contractual, legal, and ownership issues that impact software reuse. Today’s usual contracting methods can create a disincentive for contractors to reuse existing software or to provide software for reuse by others. Legal issues arise over liabilities and warranties. Responsibility for maintenance must be identified. These organizational challenges are, for the most part, outside the scope of this set of manuals. Each organization must develop its own solutions. Managers must be aware of the challenges and address them if reuse is to succeed