A Software Reuse in Small Scale Industry: A Survey

A Software Reuse in Small Scale Industry: A Survey

Tincy Rani, Sushil Garg

CES Dept, RIMT-IET, Mandi Gobindgarh, HOD in CSE Dept, RIMT-IET, Mandi Gobindgarh.

Abstract

Software Engineering is the very integrated part of the industry from mid nineties. Small scale enterprises are a very important in the gears of the world economy. Software industry becomes significant economical activity from the last few decades. According to Fayad et al. [8] 99.2% of software development companies are small (fewer than 150 employees).They develop significant products, for the construction of which the firms need efficient software engineering practices that are suitable for their particular size and type of business. Effectively gathering user requirements is a critical first step of any project and perhaps one of the most challenging project management skills. To avoid cost overruns, dissatisfied users or even project cancellation, it is vitally important to build the project on well-formed, testable, and verifiable user requirements. After project requirement and implementation by firm implementation of software is comes into act which in turn complete the project in major sense. Usually companies tends to reuse their assets, resources and software policies to cut- off their expenses and to increase utilization of available resources.

1. Introduction

Software reuse is the process of creating software systems from e xisting software rather than building software systems fro m scratch. This simple yet powerful v ision was introduced in 1968. Software products are expensive. Therefore, software project managers are always worried about the high cost of software development. A possible way to reduce development cost is to reuse parts fro m previously developed software. In addition to reduced development cost and time ,

Reuse also lead to higher quality of the developed products since the reusable components are ensured to have high quality. A reuse approach that is of late gaining pro minence is component based development. Co mponent-based software development is different fro m the traditional software development in that software is developed by assembling software fro m off-the-shelf components. Reuse is an umbrella concept, encompassing a variety of approaches and situations [Morisio02]. The reusable components or assets can take several forms: subroutines in lib rary, free -standing COTS (Co mme rcia l-Off-The- Shelf) or OSS (Open Source Soft ware) components, modules in a domain-specific fra me work (e.g. Sma llta lk M VC c lasses), or entire software architectures and their components forming a product line or a product fa mily.

Morisio02 et al. define reusability as a combination of two characteristics:

1. Usefulness, which is the extent to wh ich an asset is often needed.

2. Usability, which is the e xtent to which an asset is

packaged for reuse.

Frakes et al [3] define software reuse as The use of e xisting software knowledge or artifacts to build new software artifacts, a definition that includes reuse of software knowledge. Morisios [2] definit ion is closer to what is meant by software reuse in our research; i.e. reuse of building blocks knowledge, or patterns may happen without reuse of building blocks and is captured in domain engineering. Deve loping for reuse has its price, which is the reason for analyzing the success of reuse programs to improve the chances of succeeding.

1. Basic issues in any reuse program

   The follo wing are so me of the basic issues that must be clearly understood for starting any reuse program.

   1. Component creation

      For component creation, the reusable components have to be first identified. Se lection of the right kind of co mponents having potential for reuse is important. Do ma in analysis as a promising technique which can be used to create reusable components.

   2. Component indexing and storing

      Indexing requires classification of the reusable components so that they can be easily searched when we look for a component for reuse. The components need to be stored in a relational database management system (RDBMS) or an Object-Oriented Database System (ODBM S) for efficient access when the number of co mponents becomes large.

   3. Component searching

      The programmers need to search for right components matching their require ments in database of components. To be able to decide whether they can reuse the component. To facilitate understanding, the components should be well documented and should do something simple .

   4. Component adaptation

      Often, the components may need adaptation before they can be reused, since a selected component may not e xact ly fit the proble m at hand. However, tinkering with the code is also not a satisfactory solution because this is very likely to be a source of bugs.

   5. Repository mainte nance

      A component repository once is created requires continuous maintenance. New co mponents, as and when created have to be entered into the repository. The faulty components have to be tracked. Further, when new applications emerge, the order applications become obsolete. In this case, the obsolete components might have to be removed fro m the repository

2. Reuse at organizatio n level

   Reusability should be a standard part in all software development activities including specification, design, imp le mentation, test, etc. ideally, there should be a steady flow of reusable components. In practice, however, things are not so simple. Extracting reusable components from pro jects that were co mpleted in the past pres ents an important difficulty not encountered while e xt racting a reusable component from an ongoing project – typically; the original developers are no longer available for consultation. Development of new systems leads to an assortment of products, since reusability ranges fro m ite ms whose reusability is immed iate to those items whose reusability is highly imp robable.

   Achieving organization-leve l reuse requires adoption of the following steps:

   Assess of an items potential fo r reuse Re fine the ite m for greater reusability Enter the product in the reuse repository

   We elaborate these three steps required to achieve organization-level reuse. Assessing a products potential fo r reuse.

   Reusability could act as the major tool in growth of small scale industry. Due to boost in globalization in technology, agile practices comes into act and many sma ll scales companies are also adopting the Agile approach so better utilization of resources is ma jor challenge as well as a opportunity for small scale industry [6].

3. Reuse advantages

   1. Increase d de pendability

      Reused software that has been tried and tested in working systems should be more dependable than new software. The init ial use of the software reveals any design and imple mentation faults. These are then fixed, thus reducing the number of failures when the software is reused.

   2. Re duce d pr ocess risk

      If software e xists, there is less uncertainly in the costs of reusing that software than in the costs of development. This is an important factor for pro ject manage ment as it reduces the margin of error in project cost estimat ion. This is particularly true when relat ively la rge software co mponents such as sub-system are reused.

   3. Effecti ve use of s pecialists

      Instead of application specialists doing the same work on different projects, these specialists cn develop reusable software that encapsulate their knowledge.

   4. Standar ds compliance

   Some standards such as user interface standards can be imp le mented as a set of standard reusable components. For exa mp le, if menus in a user interfaces are imp le mented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability as users. The use of standard user interfaces improves dependability as users are less likely to ma ke mistakes when presented with a fa miliar interface.

4. Reuse problems

   1. Increase d mainte nance costs

      If the source code of a reused software system or component is not available then ma intenance costs may be increased as the reused elements of the system may beco me increasingly inco mpatible with system changes.

   2. Lack of tool support

      CASE tool sets may not supports development with reuse. It may be difficult or impossible to integrate these tools with a co mponent libra ry system. Th e software process assumed by these tools may not take reuse into account.

   3. Not-invente d-here syndrome

      Some software engineers sometimes prefer to re- write co mponents as they believe that they can improve on the reusable component. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other peoples software.

   4. Creating and maintaini ng a c omponent librar y

      Populating a reusable component library and ensuring the software developers can use this lib rary can be e xpensive. Our current techniques for classifying, cataloguing and retrieving software components are immature.

   5. Findi ng, understanding and adapting reusable components

   Software co mponents have to be discovered in a lib rary, understood and, sometimes, adapted to work in a new environ ment. Engineers must be reasonably confident of finding a co mponent search as part of their norma l development process.

5. Conclusion

   There is an a mple scope of research in stated area. Present study will reflect the importance of user require ments in any software project and how we can utilize resources with better approach with reusability. It will e xp lore how way of require ment gathering is modified when reuse of recourses are taken into part at very initia l step. It provides guidance for sma ll scale co mpanies to achieve growth during resource reusability.

6. References

1. B.Jalender, Dr. A Govardhan, Dr.P Premchand, A Pragmatic approach to software reuse; journal of Theoretical and Applied Information Technology.

2. [M orisio02] M orision, M ., Ezran, M ., Tully, C.: Success and Failures in Software Reuse.IEEE Trans. Software Engineering, 28(4), pp. 340-357, April 2002.

3. W.B. Frakes, C.J. Fox, Sixteen Questions about Software Reuse, Comm. ACM , 38(6):75-87, 1995.

4. Francisco J. Pino Æ Fe´lix Garc´a Æ M ario Piattini, Software process improvement in small and medium software enterprises: a systematic review: Published online: 21 November 2007_ Springer Science Business M edia, LLC 2007.

5. [Griss95] Griss, M .L., Wosser, M .: M aking Reuse Work in Hewlett-Packard. IEEE Software, 12(1), pp. 105-107, January 1995.

6. Version one, 3rd Annual Survey: The State of Agile Development,

   www.versionone.com/pdf/3rdAnnualStateOfAgile_F ullDataReport.pdf, 2008.

7. Tim M enzies, Justin S. Di Stefano, M ore Success and Failure Factors in Software Reuse, IEEE trans. soft. eng. vol. xx, no. y, month 2002.

8. Fayad, M . E., Laitinen, M ., & Ward, R. P. (2000). Software engineering in the small. Communications of the ACM , 43(3), 115118.