INCREMENTAL SOFTWARE REUSE Juan Llorens (
[email protected]) Informatics Department. Universidad Carlos III de Madrid Avda. de la Universidad, 30 E-28911 Leganés, Madrid, Spain José M. Fuentes (
[email protected]) R&D Dept., The Reuse Company, Virginia , USA Ruben Prieto-Diaz (
[email protected]) James Madison University Virginia, USA Hernán Astudillo (
[email protected]) Universidad Técnica Federico Santa María Valparaíso, Chile
reuse for internal processes improvement [Morisio 02], [Meyer05], [Desouza06].
ABSTRACT Current reuse techniques disincentive their mass practice in software development organizations because of their large initial investments, the changes they required in ways of developing software, and their fragility in front of domain evolutions. We argue that the root of these problems is the poor resolution of retrieval techniques to identify candidate artifacts to utilize in new projects. We suggest an approach to reuse based on artifacts retrieval by content, which allows incremental adoption at low cost. The Incremental Reuse Method (IRM), founded on these principles, can solve the big problems of traditional reuse, allowing their application in all manner of organizations. To validate these claims, three case studies in three organizations of different kinds are also presented. Keywords: Software Reuse, Incremental Reuse, Traceability, Reuse Process, Content-based Retrieval. 1. Why isn’t Software widespread as it should be?
Reuse
as
Software Reuse is a well known concept in Software Engineering: it could be compared to the “holy grail” which has always been sought and has been impossible to reach. The reuse concept brings up strong reactions among computer industry professionals. All of us are aware that it represents a needed best practice we should know and apply within our organizations [Jacobson97], [Mili02], [Morisio02], but many of us also show certain level of skepticism in the success possibilities to institutionalize
A possible reason to understand this paradox could perhaps be found in the difficulty to balance both positive and negative effects towards its practice. Among the benefits of practicing reuse we can mention the classical ones: Increment of productivity, reduction of time to market, reduction of project planning overheads, increment of quality, improvements in support and maintenance, better use of resources, and better tackling of system complexity. Both the Capability Maturity Model (CMM) and CMMI consider reuse a “best practice” [CMM06]. In their new versions they already mention software reuse, and not only covering source code. But not everything is so promising in this vision. Many professionals, including the authors, consider that there are severe obstacles to introducing software reuse (further explained in the next section): • • • • •
Significant resources must be spent to support the reuse process. The investments are usually very high, so organizations must perform Return on Investment (ROI) analysis and there is high risk of failure. A specific Software Development Process (SDP) must be applied to produce SW, which is usually quite different from classical SDPs. Comprehensive training processes must be performed. Extra efforts must be done in identifying commonalities and variabilities (C/V). In fact, C/V
1
• •
identification is the core activity of the classical reuse processes. Extra efforts must be spent in supporting C/V knowledge. It is not easy to find in the market CASE applications fully supporting the reuse process.
We believe these difficulties, in addition to the fact that the retrieval technology to find artifacts by semantic content was non-existent, have been the key factors for the low impact of software reuse among software development professionals. The structure of the paper is organized as follows: In the next section we present why the lack of content based semantic retrieval technology has led to the approach to SW Reuse used so far. In section 3 we describe how software reuse should evolve to be even more attractive to practitioners, and we present our approach to Software Reuse, called Incremental Reuse Method (IRM). In section 4 we explain the results of its application in three different organizations: two large development organizations and a highly specialized computer based Small Medium Enterprise (SME). Finally the conclusions section is presented. 2. Software Reuse so far The literature offers more than 30 different definitions of reuse and software reuse, many of them with different shades. Some of the general definitions of reuse don’t help very much our practitioners: ‘To use again.’ ’further or repeated use’ [Merriam05], ’Use again after processing’ [FODC05]. More specialized meanings put a better focus on the topic. McIlroy [McIlroy69] didn’t mention the term reuse, but mentioned the concept of reuse: ’I would like to see components become a dignified branch of software engineering. I would like to see standard catalogues of routines, classified.’ The 90s showed up several good definitions, like the IEEE [IEEE90]: ’...a software module or other work product that can be used in more than one computer program or software system’; Charlie Krueger [Krueger92]: ‘…the process of using existing software artifacts rather than building them from scratch.’ In 1994 Bill Frakes [Frakes94] inserted a very interesting new view to the definition: ‘...the use of engineering knowledge or artifacts from existing systems to build new ones - is a technology for improving software quality and productivity’. Will Tracz [Tracz95] stated that ’Software Reuse is the process of reusing software that was designed to be reused'. Finally, Ezran, Morisio, and Tully stated, in 2002 [Ezran02] that ‘Software reuse is the systematic practice of developing software from a stock of building blocks, so that similarities in requirements
and/or architecture between applications can be exploited to achieve substantial benefits in productivity, quality and business performance’. All of these definitions, covering nearly 40 years of experience, guide software reusers to develop new products by “finding” and using existing work-p roducts in new projects, yet this has certainly NOT been applied in practice. On the contrary, software reuse has been shaped by the fact that available retrieval techniques do not enable reuse as previously defined because they do not allow an individual reuser to search for assets by their content: they allow only searching by keywords, facets or metadata [Prieto-Diaz91], which seem not to be enough for practitioners as shown by their lack of use. For example, some interesting and valuable requests that are currently very hard are: What UML communication diagrams from previous projects are similar to this one I have drawn in my CASE tool? Do I already have a test case definition that fits with this requirement? Did I use requirements similar to a particular one in the past? Did it have a set of successfully retired risks? How many existing COTS fulfill an interface I have designed in UML? Is there a Design Pattern that models something similar to my class diagram sketch? etc. The inability to tackle these questions has led reusers to replace the problem of dynamic identification of artifacts with the problem of using previously developed architectural frameworks or reusable assets, thus dispensing with the need for content retrieval technology. Hence, the approach to reuse was transformed into coping with commonality and variability in order to define forthcoming reusable assets: this implies performing domain engineering in advance. The results of this process were pre-modeled assets: Product Lines (PLs ), Generators, Frameworks... and everybody must/should (re)use them. As a consequence to this philosophy, the reuse process had to be adapted to this way of proceeding: Karlsson [Karlsson95] suggested what can today be considered the standard reuse process: SW for Reuse / SW with Reuse (see Figure 1).
2
Reuse Management Lead, Promote, Support, Plan, Fund,..
Domain Engineering
New project
Software with Reuse
Software for Reuse
Find, customize, glue SW, integrate, OR create SW
Reusable Assets, PLs, Frameworks, DLLs,…
New Solution
Figure 1: Standard Reuse Process representation This process has the following features: • • • • • • • • • •
Based on the Producer / Consumer paradigm Software with Reuse as the driving goal Software for Reuse as an investment Based on the application of Domain Engineering (DE) DE needs to be performed in advance DE usually only applied to architecture (solution) Architecture-based software development process (SDP) Commonality is found, modeled and furthered reused Variability is modeled through configuration, inheritance and/or templates It needs great investments!!!
Aside from the inherent drawbacks of this approach, as described in the previous section, it works well only if two premises are fulfilled: • •
Business: The reusable domain is mature (clear in its definitions and relationships) and stable (does not change along time). Technology: The technology evolution does not affect the reusable architecture.
In our experience, it is possible to find mature domains but we have never found mature and stable domains in our 20 years of profession: all of them have a strong dynamic dimension that makes them evolve very quickly in time. Similarly the technology evolution is unstoppable and sooner or later it affects the business premise. At the end, this requirement demands more investment and cost.
Current retrieval technology allows retrieving assets by semantic content similarity [Llorens02], and if the retrieval technology starts to be solved, it may be possible to think of different approaches to reuse software. In the next section we propose an incremental version of the software reuse process where the classical drawbacks from existing reuse approaches can be minimized. As a consequence of this approach, Software Reuse may be accessible to all organizations, including SMEs. 3. Incremental Reuse Method (IRM) The Incremental Reuse Method (IRM) approach pretends to minimize the previously presented drawbacks in order to offer a very attractive set of conditions for an organization to “jump into” reuse. For us, those conditions should be: • •
• •
• •
It must be possible to introduce SW Reuse based on the argument that investment should be minimal, almost zero. The introduction of Software Reuse must not impact the internal Software Development Process in any significant way. The software engineers should carry on their own SDP (perhaps with slight differences). Introducing Software Reuse doesn’t have to imply heavy training activities. It must be possible to introduce Software Reuse incrementally; no need to have or model anything for reuse in advance. The artifacts from the finished projects become the reusable artifacts for the new ones . The Software Reuse process must be robust against business dynamics (domain changes) and technology evolution. ROI does not have to be the most important decision factor: Organizations should be able to consider other criteria as well: • • • •
Quality Improvement Issues Time To Market Knowledge Management Knowledge Value as an asset in the organization
The IRM aims to fill these conditions. Its grounds can be found on Basili’s taxonomic definition of reuse [Basili91] (shown in Figure 2).
These premises lead to ROI issues. The investments to introduce reuse within an organization are significant and depend on forthcoming issues like how the domain is going to react in the future. Usually organizations don’t like this uncertain approach, and reuse suffers from it. However, the situation may have changed already.
3
Reuse Retrieve Identify Characterize
Modify Evaluate
model) is the atomic component of information that is linked, by one or more relationships, with other concepts to form knowledge. A concept can also be a sub-artifact (an information container found inside a wider artifact). A concept is represented by a normalized term (a keyword coming from a controlled vocabulary, or domain).
Select
Match
< Artifact >
Figure 2: Taxonomic definition of reuse For us, as for Basili et al., the two main aspects when defining a practical reuse process are Retrieval and C/V engineering (that is, to cope with variability by modifying what we have found to be reused). In IRM, the assets retrieval techniques and tools are considered essential. The improvements reached in the 80’s when the facets [Prieto-Diaz91] approach was published do not support trying to find artifacts 1 by their very content. To succeed with this approach, a repository must be able to represent all different artifacts’ contents independently of their typology, as well as provide retrieval algorithms for finding artifacts by content. In IRM, the repository representation schema is based on the RSHP meta-model [Llorens02]. RSHP stands for “RelationSHiP,” and it was designed to jointly represent all different types of information using a common meta-model that allows all possible information models to be stored in the same repository, in order to enable traceability between the represented information artifacts. For example, it must be possible to represent, in similar ways, an association between two UML classes and a text requirement, if both represent the same information. The philosophy of RSHP is based on the ground idea that information is in essence, related facts, and therefore, it is necessary to bring the relationship itself to the highest priority of a representation model. As a result of this premise, “In order to represent information in the RSHP representation model, the main description element to be found within the container of the information to be represented should be the relationship. This relationship is in charge of linking concepts” [Llorens02]. A concept (named Knowledge Element in the RSHP
1
We use Artifact instead of asset. An Artifact is “a tangible piece of information that (1) is created, changed, and used by workers when performing activities, (2) represents an area of responsibility, and (3) is likely to be put under separate version control. An artifact can be a model, a model element, or a document “[Jacobson97]
< RSHP >
< Concept > Figure 3: RSHP Metamodel Aside from enhanced semantic retrieval, IRM embraces the Commonality/Variability study as a need to provide better support to universal reuse. As we mentioned above, in the 20th Century the prevalent approach to reuse was to identify beforehand the domain commonality, transforming it into a set of reusable assets, and then “forcing” to reuse the result, trying to cope as well as possible with variability through extension mechanisms (interfacing, inheritance, parameterization, configuration, templating). In our opinion to cope with variability was one of the weakest parts of last century’s reuse, because it worked only when variability was very low. In Figure 4, we present IRM’s ranking of reusable techniques according to the new project variability level. All the existing reuse techniques, from PL’s to Components Engineering, cover only the low variability section of the dimension. They could only be applied to a new project to be developed if it has a high level of commonality with regards to what has been modeled before. The closer to zero the variability, the larger the artifacts that can be reused (PLs), and the easiest variability modeling techniques (configuration). On the other side, if the variability of the new project increases, the candidate reusable artifacts will become smaller and the retrieval needs appear to be able to find them within their own projects. This large area where the variability is not low has not been covered by classical reuse techniques, because it supposes to be able to represent all the small artifacts (requirements, risks, tests,
4
UML diagrams, etc.) by content in a repository. This area is covered in IRM by the Seek + Find + Trace Navigation + Reuse approach: SFT Reuse. Essentially, the SFT Reuse is to bring back the copy/paste philosophy, present in all the reuse definitions, into practice. “If I find something in the previous project that seems to be reusable for my new project, with no dependency of what it is, I’ll copy and paste it.” If traceability between artifacts is supported in the previous project, it becomes possible to “navigate” through an interesting artifact to reuse traced artifacts as well.
High
– No Reuse
of requirements coming application project )
from
a
different
or •
Which needed to be configured to fit with project requirements or specifications (e.g. a product line configured to a new product)
•
Where only parts of them were incorporated to the new project (e.g. An association between two UML classes coming from a previous UML Class diagram)
or
In order to put into practice the previous statements, the Incremental Reuse Method pretends to offer a framework for the creation of a Reuse Unit within every interested organization without huge investments. It is based on the dimensions shown in Figure 5.
– Seek + Find [+ Trace] + Reuse FCP Method: Find + Copy/Paste Assets – Eg. Requirements (Common Criteria) – Eg. Class Diagrams, Use Cases, etc. l FTCP Method: Find + Trace + Copy/Paste Assets – Eg. Requirements Tests for Requirements – Eg. Classes Diagrams from Requirements, etc. l
Reuse Process & Metrics
– Components (OTS Reuse, Interfacing).. – Frameworks (Parameterize, Inheritance) – Generators – Product Lines (Configuration) – Use of Apps, Components, etc..
Domain Model
Low
Variability level of the new project
Figure 4: C/V modeling in IRM The most important aspects of the C/V modeling in IRM is that it is possible to perform reuse in extremely high variability needs (including inter-domain reuse) through the Seek + Find + Trace Navigation (SFT) Reuse. Therefore, our working definition for reuse focuses on Retrieval and C/V Engineering: Reuse is the use of all kinds of [known or unknown] previously created artifacts (assets) in a new project, but: •
Slightly modified to fit with the problem or solution definition in the new project (e.g. a design pattern applied to my particular domain)
•
Which were defined to work in a different context or environment or application (e.g. a set
or
Technology and Tools
Roles
Figure 5: IRM Dimensions
3.1 Domain Model In essence, the RSHP meta-model used in IRM as the repository representation schema can be considered equivalent to an Ontology representation. Using the RSHP meta-model, the IRM approach represents every artifact in a repository by a kind of sub-ontology structure. Joining all the artifacts representations together, an overall representation can be obtained, as an ontology representing the organization domain. In order to create this representation for every artifact stored and classified in the repository, indexers extract the semantic contents of the different assets once they are produced in a project, and use it to represent them in RSHP. To create the ontological representation of every artifact, the indexers locate and find the relationships present in their content.
5
PMre Voc Req Risk SfR? Plan
WG
Find + Reuse
Ana
CM Traceability
Des Cod
Software with Reuse
The existence of the ontological representation is very important for retrieval purposes. The IRM uses the ontology as a kernel to the retrieval algorithms that allow finding similar artifacts by content [Llorens03].
SDP + Reuse Management
New Project
Software for Reuse
Due to this approach, there is no need to create an ontology in advance because it is created incrementally while the organization is developing new projects, and the cost to do it is minimal: just supervision and management.
Tes Db
3.2 Reuse Process
Ix
In order to reduce barriers and costs for the potential reusers, their software development process should not be essentially affected when introducing a reuse program. The reuse process should wrap the SDP used by the organization, offering only a few new activities to add to the existing one and several new phases within the software lifecycle. Software Architecting
New Project
>
Domain Engineering
Assets Engineering (Software For Reuse)
Reuse Centered Life Cycle (RCLC) Based on the existing SDP in the organization
Assets Reuse (Software With Reuse)
Software Architecting
New Application
Figure 7: IRM Reuse Centered SW Life Cycle Where the acronyms stand for: PMre Voc Req Risk SfR? Plan Ana Des Cod Tes Db Ix CM WG
Project Management Information Reuse Vocabulary Definition Requirements Engineering Risks Management Evaluation of the construction of SW for Reuse Project Planning Problem formal Specification Detailed Design Coding Testing activities Project Iteration Debriefing Indexing and Classification in Repository Configuration Management Workgroup Management
New Application
Figure 6: The IRM reuse process The organization’s SDP become and activity in the IRM process, called Reuse Centered Life Cycle (RCLC) and the new activities included are Software For Reuse (SFR), Software With Reuse (SWR) and Domain Engineering. The flow relationships are presented in Figure 6.
The RCLC provides the following functionality: 1.
2.
The RCLC Activity The RCLC activity wraps the organizations’ SDP as it is (for example, the Unified Process, a classical waterfall, etc.) including two particular tasks specifically included for reuse purposes (the SFR Evaluation task and the indexing task). The following figure shows a standard SDP but including the reuse tasks.
3.
Offers SW For Reuse to all the different phases of the SDP by indexing the produced artifacts (in the Indexing Phase) and allowing to retrieve candidate reusable artifacts as a result of a similarity query. Includes a phase called Software For Reuse Evaluation, where the organization should debate if particular artifacts of the new project will have a particular design for reuse. Includes the Indexing phase, where, at the end of the project, all the artifacts produced are indexed, classified and stored in the repository
With these functionalities an organization transforms its SDP into a Reuse Based SW Life Cycle (RCLC). The Software for Reuse Activity The SFR activity is in charge of the indexing task, preparing and checking the contents, guiding in the debriefing task and controlling the overall results.
6
The Software with Reuse Activity The SWR is in charge of defining how to support a repository and maintain the artifacts stored in it. The Domain Engineering activity The Domain engineering activity is in charge of • • •
Maintaining the domain representation generated by the indexing process (artifacts, vocabulary, relationships, the ontology representation, etc.) Look fo r common patterns in the representation of the produced artifacts. Manage the C/V engineering, to produce reusable artifacts as it was done in the 20th century
• • • • •
And regarding reuse capabilities: • • • •
Based on the previous description, the main features of the IRM’s process are:
•
• • • • •
• •
• • • •
Project-based SDP instead of Domain-based SDP is extended with new activities SDP is forced to support full trace Debriefing is a key improvement factor. Based on an ontological Domain Representation but it is not necessary to start with a complete one. Domain Engineering is optional, and performed continuously and incrementally Provides support for the retrieval of all types of “artifacts by content” Need reuse oriented CASE tools No need for great investments to start with
3.3 Technology and Tools The IRM approach demands a reuse based CASE tool that can provide support to the most important features of this approach: to cover the whole life cycle, to provide full trace between activities and to include SFT Reuse support at every activity. swREUSER is a CASE tool with full support to the IRM software reuse process. The main features of the tool are, regarding SDP support: • • • • • • •
Domain management Requirements management Risks tracking Planning support Estimation (Function Points + COCOMO II and the POP method from Price) UML modeling (full UML 1.5 support, model comparer, full bidirectional connection to Rational Rose) Code generation: Java (inverse and reverse
engineering), C# code generation, XML Schemas generation Metrics: MOOD, MOOSE Testing Full trace Collaborative work Document generator
Reuse support at every activity of the SDP Automatic creation of a domain representation using ontologies Full access to the ontological structure Creation of modeling elements (UML) from conceptual elements in the ontology Creation and management of Requirements Patterns: a requirement pattern is made of requirements, risks and tests Indexing and retrieval into a repository Connection between the retrieval module and the reuse module
3.4 Required Roles IRM demands the following roles, which can be fulfilled by a single person depending on the organization needs and work volume: • •
• •
•
Domain Architect: Expert in building domain representations. Its main role is the construction and evolution of the ontology that represents the Domain. Domain Expert: Skilled person within the Organization Domain. Its main role is to validate the knowledge of the Domain during the construction and evolution process. Librarian: In charge of performing the debriefing and indexing activities once the project is finished. Reuse Manager: Responsible for the operation of the Reuse Unit. Its main role is to be responsible for the management of the Domain construction and evolution. Other responsibilities are Coordination, ROI studies if necessary, Metrics, etc. Chief knowledge Officer (CKO): The evolution of the Reuse Unit is the Knowledge Office. The Reuse manager would become the CKO
4. Empirical Validation To present experimental results with the adoption of a new process in an organization si a hard task, mainly because it is difficult to measure its impact and implications, and it takes a long time to certify them. The IRM method has been tested in the professional
7
market since middle 2005. We present here our three most relevant experiences 2 .
has been created representing the company’s application domain.
4.1 Accounting SW Factory
Reuse of other software assets: thanks to the swREUSER capabilities, together with the knowledge enclosed in the already created ontology, this company is able to reuse any kind of software asset defined in swREUSER (UML models, requirements, risks, tests…).
The first target company is a leader company in the European market commercializing small tools for company management (accounting, billing…). Its major business goal is the Small Medium Enterprise companies (SMEs) all over Europe, where they have more than 10 million customers. The Spanish branch of this organization, formed by about 600 persons to cover more than 2 million customers, has recently created a completely professional SW Factory for the production of SW products. This SW Factory did not support SW reuse. As this company is driven by customers’ needs, the main idea in its software factory is to serve as a bridge between the marketing department and the development department. Therefore, its life cycle is really driven by the customer by means of the marketing people (around 130). Bearing this in mind, the reusability approach of this company was oriented to be able to reuse high-level decisions (requirements, risks, decision for developing a new functionality) and knowledge instead of just reusing code, executable components… in order to get a software development Decision Support System. The IRM approach has been applied with the following results: Requirements Reuse: Thanks to IRM, this software factory is able to reuse requirements for new releases production out of the set of requirements defined in previous projects, as well as the idea of requirement patterns implemented by IRM and the swREUSER [SWR06] CASE tool (which allows them to define and reuse different sets of requirements, both horizontal and vertical). Feedback Reuse: as stated before, the company wanted to manage the customers’ feedback in order to incorporate new ideas to their products and fix, in a short period of time, any possible mistakes that the customers found in their products. The questions to answer now are: “What’s the bigger concern of my customers?”, “What kind of aspects are the cars manufacturing companies focusing on?”, “Are there any problems recurrent in time?”… In order to answer those questions, aside of data mining techniques, real semantic tools are being used. And, in order to enhance these semantic capabilities, an ontology
2
In this document we’ll avoid to mention the companies until we get their explicit permission. If needed, please visit www.reusecompany.com
Creating an ontology used to be a scary proposition to every company, since the amount of time and resources needed to do it is usually quite high. Nevertheless, we have used our own set of NLP tools and methodology so that the resulting ontology has been finished in one month and a half, and with a reduced implication of the domain experts (provided by the customer). 15K terms have been found and the final number of relationships between them will be around 20K.
4.2 A Large Aerospace Company The next IRM implementation is an on-going project that covers only one department of a large aerospace company (around 50 people). This case is totally different from the previous one: the target department has been developing computer systems for many years without systematic concern for reuse. Our challenge was to be able to reuse software created months or years before, developed in previous projects using a spiral SDP. The first step was to develop connectors (bridges) among our tools and all the tools that this department had used for many years (mainly Rational Rose and Telelogic DOORS). The second step dealt with the translation of some of the swREUSER CASE tool processes (the one they are already using) to fit with the processes used by the department. One example is the branching and merging tasks involving the software semantics and a Configuration Management tool. Once these previous steps were fulfilled (running at present time), the idea now is to create an ontology out of their knowledge about its domain. This ontology, that one more time will be created in a semi-automated fashion, will enhance all of the reuse capabilities of swREUSER and will allow to reuse requirements (clearly common between projects in this domain), risks, UML models , and actual tests. The experience of implanting the IRM on this organization is that the possibility to start from an already existing department (the department was created from
8
splitting different units in different departments) makes the implementation of Reuse very attractive while the cost still remains very low. Indeed, the department did not have to modify its SDP to match it with the IRM because they had flexibility to particularize the general organization SDP to their own needs. The only extra cost was to adapt the swReuser CASE tool document outputs to be compatible with the multi-national group needs (they work together with other groups within the company that have a fixed documentation standard).
of class diagrams and tests.
4.3 SME Software Development Company
This article has proposed a method to solve the applicability problems of classical reuse methods. The proposed process allows incremental adoption, without modifying the organization’s software development process, at low cost, and with robustness to domain evolution.
The third and last IRM implementation took place in a Small-Medium Enterprise. The company has 25 employees, where 10 are devoted to software development. Its main activity is the development of software tools for the software engineering market. The approach was to implement the IRM in an incremental way, with no initial investment in domain engineering and the software development process used in the company (a classical spiral one) was not changed. The following activities were performed: 1.
2.
3.
An investment in HW and SW to support the repository was made which included A PC Pentium IV 3,02Ghz with 1 GByte RAM and a Windows 2003 SBS including SQLServer 2000. Corporate licenses for swReuser were included. A 20 hours training course to the 10 developers and the 2 managers on how the IRM affect the classical SDP they were using and on the importance of the debriefing activity. A 16 hours course to a selected person out of the 10 developers, who was nominated as reuse manager. His new duties were: • • • • •
To decide if the new projects must include particular developments generalized for further reuse. To review the debriefing activity done in the new projects. To index the new projects when they are finished. To maintain the ontology created by the indexing activity. To help and support the rest of the developers in looking for reusable artifacts.
The IRM project started in October 2005. To date, 3 software projects have been indexed into the repository, with almost no reuse of the second from the first but successful requirements reuse from the first in the third. Through traceability the third project was able to reuse Use Cases (by pasting them in the new project), sections
We have not developed yet methodologies to measure the reuse levels gathered by this approach. This experience has allowed us to prove that it is possible to implement IRM in a small company at very low cost (below 20K€). 5. Conclusions
The Incremental Reuse Method (IRM) is based on offering retrieval and reuse of artifacts to all activities in the software development process. These artifacts are stored in a repository that is maintained through incremental indexing of all work products of an organization’s projects. Its low implementation cost and minimal impact on existing SDP activities have given high success rates in actual implementation cases. 6. References [Basili91] V. R. Basili, H. D. Rombach: “Support for comprehensive reuse.” IEEE Software Engineering Journal, 6(5):303–316, September 1991 [Desouza06] K.C. Desouza, Y Awazu, A. Tiwana: “Four dynamics for bringing use back into software reuse.” Communications of the ACM, 49(1), January 2006. [Ezran02] M. Ezran, M. Morisio, C. Tully: Practical Software Reuse. Practitioner Series, Springer 2002. [Frakes94] W. B. Frakes, S. Isoda: “Success factors of systematic reuse.” IEEE Software, pp.14-19, September 1994 [Gamma95] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1995. [IEEE90] IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering (1990). [Jacobson97] I. Jacobson, M. Griss, P. Jonsson: Software Reuse: Architecture, Process and Organization for Business Success. ACM Press. Addison Wesley 1997.
9
[Karlsson95] E.-A. Karlsson: Software Reuse – A Holistic Approach. John Willey and Sons. 1995. [Krueger92] C. W. Krueger: “Software Reuse.” ACM Computing Surveys. 24(2), June 1992, pp.131-183. [Llorens02] J. Llorens, J. Morato, G. Genova, “RSHP: An information representation model based on relationships.” In: Ernesto Damiani, Lakhmi C. Jain, Mauro Madravio (Eds.), Soft Computing in Software Engineering (Studies in Fuzziness and Soft Computing Series, Vol. 159), Springer 2004, pp 221-253. Available for reviewers in ftp://www.ie.inf.uc3m.es/llorens/ICSR.zip
[Meyer05] Meyer, B. Failure, Preconditions, and Reuse http://www.artima.com/intv/except3.html Last visited on 28th of December of 2005. [SWR06] http://www.reusecompany.com/swReuser.aspx Last visited on 15th of January of 2006. [TRC06] The Reuse Company LLC. www.reusecompany.com Last visited on 15th of January of 2006.
[Llorens03] J. Llorens, J.M. Fuentes, J. Morato: “UML Retrieval and Reuse using XMI.” IASTED International Conference on Software Engineering and Applications (SEA 2003) Marina del Rey, CA. USA. November 2003. [McIlroy69] M. D. McIlroy: “Mass produced software components.” Proc. NATO Software Engineering Conference, Garmisch, Germany (1968) pp. 138155. Proceedings published in 1969. [Mili02] H. Mili, A. Mili, S. Yacoub, E. Addy: ReuseBased Software Engineering: Techniques, Organizations, and Controls. John Wiley & Sons. 2002 [Morisio02] M. Morisio, M. Ezran, C. Tully: “Success and Failure Factors in Software Reuse.” IEEE Transactions on Software Engineering, 28(4), April 2002. [Prieto-Diaz91] R. Prieto-Diaz: “Imple menting faceted classification for software reuse,” Communications of the ACM, 34(5), May 1991 [Tracz95] W. Tracz, Confessions of a User Program Salesman: Institutionalizing Software Reuse. Addison Wesley Publishing Company. Reading, MA, 1995. Web sites [CMM 06] http://www.sei.cmu.edu/cmmi/ [FODC05] The Free On-line Dictionary of Computing. http://dict.die.net. Last visited on 15th of November of 2005. [Merriam05] Merriam-Webster On-Line Dictionary. http://www.m-w.com/dictionary. Last visited on 21st of December of 2005.
10
