Software Reuse in Software Development - Essay Example

Your name Professor Subject Date Software Reuse Issues in the Software Development Process Introduction As humans, we learn the benefits of reuse as soon as we begin to perceive our world in a rational manner. As part of our everyday life, we reuse almost everything ideas, objects, arguments, abstractions, processes and more. It is like reinventing what is already been invented. In the software community, reuse is any procedure that produces a system by reusing something from a previous development effort. Software reuse although a promising approach to software development still needs to answer some important issues to facilitate successful implementation. The discussion on this paper covers the extent of software reuse in the development process and the primary issues and impediment it is implementation. Extent of Software Reuse Practice in the Software Development Process Software Reuse Software reuse is the method of updating software systems using currently available software resources. These software resources are not just source codes but include all software products from requirements, proposals, specifications, designs, manuals, and test data. In other words, it is anything produced from the software development effort can be reused (Jordan, 1997, p.3). Reuse is not an object but a common activity that means to “use something again” (Pressman, 1997, p.728). A more conventional wisdom about reuse is building software from components and the larger and universal the components, the better. Now software products could be built completely using reused components (Glass, 2001, p.1).  A properly planned software reuse process makes it possible to increase the efficiency, quality, dependability, and reduce the costs and completion time (Jordan, 1997, p.3). Systematic reuse of earlier written code is a technique to enhance software development productivity in addition to the quality of the software (Rothenberger, 1999, p.1). At first, there is an initial outlay in implementing a software reuse process but the effort pays off in the next few reuses (Jordan, 1997, p.3). According to Pressman (1997, p.729), there is much more to gain than just a simple cost saving during the software development stage. Reusing known reliable components is much better with lesser risk than redesigning and rewriting the same component again. The development of a reuse process and repository will serve as the base of knowledge that will consequently further improves its quality after every reuse. It will help reduce the amount of development effort and risk for upcoming projects (Jordan, 1997, p.3). Types of Reuse Horizontal reuse refers to those software components used across a broad range of applications. This includes the usual software program’s library of components, such as object class, functions and routines, and existing GUI functions. The use of commercially available off-the-shelf applications such as word processing programs, spreadsheet, e-mail packages are also part of horizontal reuse (Jordan, 1997, p.3). On the other hand, Vertical reuse notably untouched by the majority of the software community is potentially more functional and has extensive influence on both current and future software development. Unlike component based horizontal reuse, this type of reuse is for reprocessing the system’s functional areas that can be used by a group of related systems with comparable functionality (Jordan, 1997, p.4. Domain and Application Engineering Encouraged by the prospect of reusing the entire quality subsystems without alteration; the idea has spawned a new engineering discipline commonly known as Domain Engineering, which is a broad, iterative, life-cycle development, employed by organizations who want to pursue strategic business goals. Application engineering conversely creates products to meet specific customer’s needs. The outline and structure of application engineering activity are shaped by domain engineering to enable each project working in a business area to use common knowledge and resources to produce premium products customized to the desires of its consumers. In summary, domain engineering as the fundamental concept and centre of today’s reuse efforts, creates and maintains reuse repositories of functional areas while application engineering take advantage of these repositories to implement new products. Software reuse does not yield same amount of benefits as in domain engineering method. The reason is not technical but rather managerial in nature. Although libraries of reusable codes and other resources are imperative, they will not be fully utilize if management and process do not support of reuse (Jordan, 1997, p.4). Issues on Managements Support There are barriers to software reuse that managers and technical men should take into account. Many software firms do not consider software reuse a top priority and few of these organizations do not have any intention of applying software reusability plan in the near future. In addition, even though it provides direct and complete assistance to the entire software reusability system, software developers are reluctant to use tools from software vendors. Another barrier is the availability of intensive training to help software technical personnel understand and implement software reuse. Although few training vehicles target reuse, the topic is just briefly mentioned and insufficient to address software reuse. Many software practitioners still believe that the idea of reuse is more difficult than its value while other companies encourages a different approach opposing software reuse (Pressman, 1997, p.730). It is a common knowledge within the industry that developing components suitable for reuse usually needs more effort and resources than building components tailored for a single project. The time and effort consumed on retrieving components and the effort on writing reusable components weigh against writing non-reusable components can counterbalance the benefits from reuse (Rothenberger, 1999, p.2). The traditional software development process does not support reuse. In fact, software are develop as "one-time only," without the possibility of a more robust open interfaces for the reuse process contrary to the principle that reusable resources should be designed and built with brief interface specifications, comprehensible documentation, and an open way for future use (Jordan, 1997, p.5). The software development process must grow and adapt in order to take advantage of software reuse. Almeida (2005) referring to Bayer et. al. statement that the existing methods are not flexible enough to meet the needs of various industrial situations. It is unclear and unsuitable without solid understanding and support. The software community must have a flexible and customisable method that can support different enterprise conditions with enough guidance and support. The present reuse processes are encountering problems like gaps in essential activities in the development and putting more emphasis on some specific activities such as analysis, design, and implementation. Even with the knowledge of software product lines surfacing, the software community still does not have a comprehensible consensus involving the activities like inputs, outputs, artefacts, and the primary necessities to ensure a successful reuse process (Almeida, 2005, p.1). Evidently, a solid organizational underpinning must exist with key abilities and unwavering commitment to the objectives of reuse (Jordan, 1997, p.5) Issues on Behavioural and Cultural Factors Another noteworthy issue presented by Price (n.d., p. 1) in his position paper described the taxonomy of behavioural and cultural factors that influence an organization’s ability to implement effective reuse practices. The study reveals that barriers in effective reuse are deep-seated in human nature that best overcomes through perceptive, holistic, multidisciplinary effort. Through the knowledge of sociological and psychological components of individual behaviour, reuse supporter according to Price (n.d. p.1) will have a better understanding of the barriers to reuse a program; will be aware of the proper remedial action to take, and will be motivated to align with other advocate of the organization. Although software reuse is a technical issue, calculating the overall success of the reuse efforts is strenuous. The attrition of the reuse staff and the depressing failures of applications for which reusable components were initially proposed, all are important factors significant to the behavioural issues in reusable components deployment. Furthermore, the customers are also confused about the issues in the compatibility of a library’s internal reliability check against the letter of an industry standard, error handing, and more. Finally, the reuse software and its sponsor succeeded or failed because of the inclusion of individual behaviours and therefore a behavioural issue. The business underlying principle for software reuse or the slothfulness in adopting apparent additional benefits is a clear denial of common sense. By nature and by common business principle, it is not easy to grasp the idea of “reinventing the wheel” or waste time on non-value adds activities. Software manufacturers are unwilling to accept that non-technical issues inspire such significant part of a futuristic software technology (Price, n.d., p.5). In addition, organizational roadblocks frequently overshadow the apparent benefits of software reuse, a lack of understanding of its true nature (Pressman, 1997, p.729). Issues on Technical and Practical Feasibility (Bloating, Integration, and Evolution) Aside from organizational and behavioural issues presented by Price (n.d.), Muller (2006) presents a more technical issue on software reuse practical feasibility. The problem according to him is in determining which functionality should be generic and which functionality must be implemented specific. In his study, many attempts to build a platform of reusable components end in a disaster due to the creation of over generic components. Using a Medical Imaging System program as a real-life example, Muller (2006) noticed the original coding of a “Tool” class to be over generic because it contains too many if-then-else clauses, configuration options, stubs for application specific extension, and best guess defaults, and as a result, the product contains more codes than it should actually have. Bloating is the needless growth of codes and one major cause of software crisis. The actual code required is habitually an order of magnitude less than the actual solution utilized. The Figure below shows the amount of overhead and a number of causes for bloating (Muller, 2006, p.6). Bloating process consequently causes more bloating and overheads. In principle, larger codes should be decomposed to smaller ones and good modules contain 100 to 1000 lines. The larger ones or the bloated versions are decomposed (an overhead by itself) resulting to some more interfacing overhead. Every bit of these extra codes does not only cost additional development, test and maintenance work, but degrades the overall system performance. Furthermore, considerable loss in system performance requires unnecessary repair resulting to even more codes. Software reuse should not set off such bloating process because it will only counterbalance all the reuse benefits (Muller 2006, p.6). Integration according to Muller (2006) is also one of the practical problems facing software reuse. In many situations, integration is harshly underestimated and distressing in most development projects. Normally, there is no problem in the decomposition phase of the project and component builders are confident in making and testing their assigned components. The problem only becomes visible when the integration begins causing considerable delay. Another problem is architectural mismatches arising from combing existing software packages. Mismatch in design approaches particularly in exception handling and configuration management prevents straightforward integration. To get around, more codes are added resulting to a more complex modules that does not add any end-user value. Performance and resource usage are usually not optimal after a software package merger. Although many developers are concern about duplication of functionality, the real problem in practice is in the architectural design and integration. This concern is caused by software a reuse initiative that addresses the wrong or non-existing problem of duplication rather than the more serious architectural flaws particularly in the integration concept (Muller, 2006, p.12). The evolution of platform is also one of the major concerns in software reuse. Managers and specialist often expect a platform to be stable. They assumed that after its creation, only a small and limited maintenance is required. The reality is that platforms works for a very dynamic quickly changing market and built using a technology that itself is changing rapidly. This means it is impossible for a platform to be stable when both sides of are not stable at all. The changes in platforms recorded from 1991 to 1996 clearly shows considerable increase in the amount of codes added to its original content while 50% of the existing code were changed. Further, according to recent study, software evolves and changes over time. Majority software vendors have a collection of software modules, a number of which are used in various applications. Software errors that apparent in a particular application which no impact to end users are neglected and are not modified which causes the propagation of software errors to the following product lines. Also, conversion to new operating environment will have an effect on the initial requirements description and may result in software issues at some stage in testing and operation (Levenson and Weiss, 2004, p.1) Incentive Issues Incentive argument expected in traditional programs of reuse is the key inhibitor and probably the most talked about issue in the software development community. In an investigation conducted by Fichman and Kemerer (2001) with dozens of software professionals, they found out that the top priority on a project is to get them done on time and within a certain budget. The priorities they added, seems to conflict with reuse process thus creating a discouragement or disincentives to pursue reuse. The main problem is that reuse choices are assigned to individual developers who typically are not aware what is to be reused in addition to programmers “not invented here” attitude and assets that frequently do no meet the operational or performance requirements of the project. In addition, the difficult coordination and ownership issues of reuse across team boundaries and the version management issues are also conflicts that still have not been resolved (Fichman and Kemerer, 2001, p.2). Fichman and Kemerer (2001) investigation concluded that contrary to common belief, the current practice of reuse is informal and unplanned and tends to be driven by the immediate needs and prospects of individual projects. The as-is reuse of components which is the main objective of the software reuse initiatives are now very rare and most large reuse initiatives are abandoned. More importantly, the overall reuse programs are incompatible with the current software development culture and incentives that fosters team sovereignty and accountability for results on individual projects. The authors further confirms that the conventional wisdom that expects software teams to adopt organization level standpoint is right and strongly suggest that companies who wants to create programs requiring systematic software reuse to prioritized incentive-compatible philosophy. Conclusion Software reuse is no doubt a tool for better software development but it can never prosper in an environment full of organizational and technical issues and practitioners with contradictory opinions. It is true that nobody can force programmers to write a good reusable code but in general, programmers are goal-oriented and wants to do a good job. Motivation is a vital part of the reuse process and a key to successful component reuse. The technical and organization problems such as management, legal, cultural, financial, and production issues must be address to ensure smooth systematic software reuse. We are now aware that software reuse is informal and not widely accepted and its application is driven only by the immediate needs and opportunities to individual projects. Finally, serious consideration should be given to reality of rapid software evolution otherwise; software reuse will be too late to perform its specific functions and offset it full potential and benefits. References Almeida Eduardo Santana, 2005, “Towards a Practical and Efficient Process for Software Reuse”, Federal University of Pernambuco and C.E.S.A.R. – Recife Center for Advanced Studies and Systems Fichman and Kemerer, 2001, “Incentive and Compatibility and Systematic Software Reuse”, Journal of Systems and Software, New York; Apr 27, 2001; Vol. 57, Iss. 1; pg. 45 Glass Robert L., 2001, “What’s Wrong with Software Reuse?” Computing Trends , Article, online, 03/21/07, http://www.stickyminds.com/ sitewide.asp?Function= edetail&ObjectType= COL&ObjectId=2731 Jordan Kimberly, 1997, “Software Reuse”, MYJ Team, George Mason University, Fairfax, VA, USA, online, 03/21/07, http://www.baz.com/kjordan/swse625/htm/tp-kj.htm Levenson and Weiss, 2004, “Making Embedded Software Reuse Practical and Safe”, Aeronautics and Astronautics; Engineering Systems, Massachusetts Institute of Technology, SIGSOFT’04/FSE-12, Oct.31–Nov. 6, 2004, Newport Beach, CA, USA. Copyright 2004 ACM 1-58113-855-5/04/0010 Muller Gerrit, 2006, “Software Reuse; Caught between strategic importance and practical feasibility”, Article, Embedded Systems Institute, Den Dolech 2 (Laplace Building 0.10) P.O. Box 513, 5600 MB Eindhoven The Netherlands Pressman Roger, 1997, “Software Engineering: A Practitioner Approach”, International Edition, McGraw-Hill, ISBN0-07-052182-4 Price Eric, n.d., “Organizational Culture and Behavioral Issues Affecting Software Reuse”, Lexis-Nexis, 9595 Springboro Pike, Dayton, Ohio 45342, online, 03/21/07, http://www.cs.umaine.edu/~ftp/wisr/wisr8/papers/price/price.html Rothenberger Marcus, 1999, “Systems Development with Systematic Software Reuse: an Empirical Analysis of Project Success Factors”, School of Accountancy and Information Management, Arizona State University Read More