Yesterday, RiSE group discussed a paper titled “Reuse Strategy based on Quality Certification of Reusable Components”. The main idea of the paper is: reuse components without quality could be worst than doesn’t reuse anything and one form of promoting reuse and reducing risks is guaranteeing the quality of software components. The paper presents 7 activities that should be executed in order to promote reuse with quality in software organizations: (1) Incorporation of Domain Analysis into the development process; (2) Incorporation of a Domain Analyst; (3) Incorporation of reuse into the development process; (4) Use of patterns; (5) Use of standards; (6) Certification of all types of reusable components; and (7) Use of reusable components repository. These activities show that we need a well-define software reuse process in order to incorporate this reuse process in the organization’s software process (i.e. process adaptation). After that, we need to store and manage the software assets developed in the organization, however, the quality evaluation of those assets are primordial before stored those assets. In this way, the assets certification could be useful in this case, certifying software assets in general (i.e. requirements, use case, architecture, source-code, etc.). The authors presented a set of quality characteristics that could be useful for requirements specification, design specification and source-code. After that, they considering a set of V&V techniques which should be considered in three quality layers cited above.One interesting aspect of this paper is that we, from RiSE, are developing a robust software reuse framework that considering the same ideas of the activities stands out in the paper (and other ones also). Besides, we are applying this framework in real case environments and a set of tools were developed to support this environment. The main goal is increase the software productivity of software companies. Is it interested?? Contact RiSE.
4 comments:
I read this paper also, but it did not convince me. Their motivation about software reuse (NIH syndrome) is not true, besides their assumption about repository, but, it is another point. My point is more reflective about work with reuse. Yes, we known that reuse is a competitive advantage, however, we had seen works just approaching very high level solution as this one. I agree with them about some steps, such as domain analysis, a domain analyst role, a well-defined process, certification, and repository. It is a consensus. The important questions could be: how to perform this domain analysis? Is it necessary a defined approach (I like it) or a meta level process with steps such as: planning, modeling, validation documentation? Moreover, in a solution uses design patterns and standards, I do not know, for me, it is obvious. But, what kind of patterns? What are the best one for modeling variability? To design an architecture reference? etc. The same feeling, I had about the quality attributes for components (in that case, specification, architecture and code).
yes, I agree with you. This is a very high-level paper with lack of details about the activities cited on the paper. It could be more interesting focus on a specific area and describe more close the steps, inputs and outputs.
besides the high-level issue, I think that exists a lack of some important references in determined activities such as when the author speaks about components certification. Alexandre's work, beyond already having been published in the IRI conference, was also published in the main conferences of the area and is one of the main researches that work with components certification.
In the actual scenario of software organizations, to require such degree of detail in software certification become almost impossible. I believe that initial activities closer to current user environment will be more successful and step by step growing until achieve such degree of exigency. I do not disagree with the important of software certification and its methods, but I only think they should be more realistic to the current scenario of software organization.
Post a Comment