Commercial-off-the-Shelf (COTS) Products -- An Appropriate Strategy for Reuse in the Development of Object Oriented Systems

Michael B. Kachmarik

Endicott Johnson Corporation

222 Water St., Binghamton, NY 13902

Tel: (607)772-4700 ext 280  

Email:  mkachmar@stny.lrun.com 

A retail shoe business assessed the need for a change in its MIS environment, a complete change both in hardware and software. The existing hardware system was mainframe based and of old technology. The existing software consisted of batch programs written in COBOL language which frequently broke, were difficult to debug and could not be changed to reflect changes in the way business operations were conducted in the company. There was the need to change hardware to newer technology and to update software to keep abreast with new operations within the business. The decision was to go from a mainframe-based to a client-server environment. The complete reorganization of the MIS environment was guided by the principles of the Object Oriented Approach to Systems Development, focusing particularly on Ivar Jacobson’s Use-Case Approach. The theory was useful in assessing system requirements. It is the experience of the author that over and beyond assessing internal requirements, some consideration of already existing commercial-off-the-shelf (COTS) products needs to be made to assess what is already available and how these can be utilized and "fitted" into the overall design and development of a large scale system. Design and development of a new MIS system occurred much more quickly and with more guarantees for success by using already developed and tested commercial products.

This position paper shows how Commercial-off-the-Shelf (COTS) products were successfully used in the development and integration of a MIS system. The use of COTS products is usually associated with software. When one is building systems (where systems refers to the integration of hardware and software components), integrating ready made off-the-shelf products and components can be quite a challenging undertaking. However, proponents of Object Oriented technology say the reuse of products and product components are the most efficient way to develop and build. This position paper will show that attention to COTS early on in the development cycle is beneficial not only for the final outcome of the process but also in contributing to the elements of each step in the development cycle. Thus, where traditional object-oriented technology would say attention to COTS should come after the design phase, in our experience, surveying COTS even during the requirements gathering phase can help redefine the scope of requirements. Since COTS products will be used down the line, attention to them in the beginning phase will help in successful integration of these products.

Ivar Jacobson in his book, "Object Oriented Software Engineering: A Use-Case Driven Approach" (1996) presents an innovative view of how software and systems engineering can enhance their methods and cycle of development. He said that both software and systems engineering industries are young industries. They have not yet reached the level of maturity found in older more well established engineering industries. They, therefore, lack established practices and standards that would help in creating and utilizing "ready-made" products. Development of software, therefore, is marked by a very creative but labor-intensive process with a lot of effort expended in recreating elements that would otherwise have been available as "components" in the market.

 Jacobson emphasizes the need to "industrialize" the process of software and systems development. He says the only way we can make significant advances is to move in the direction of making "commercially" available software products and system components, "...produce not just well-engineered software systems but also viable living products that can be exploited in an industrial environment." He presents the concept of "manufactured" software and software components that are readily available and reusable. This concept of manufactured software and a software component provides a new twist to the old principle of reuse. Here, Jacobson is presenting the idea of not just utilizing fragments of code, modules, or dynamic link libraries used over many program applications but of creating stand alone software and software components that can be sold separately in the market and fitted and dropped into any application or systems integration effort. Software developers are already keenly aware of the labor-saving advantages of reusing of code. In the area of systems development, however, the use of drop-in solutions and the utilization of commercially packaged software and systems components is still quite new and radical. It is the experience of this group that Jacobson’s concept of utilizing and fitting together commercial-off-the-shelf (COTS) software and systems components is a viable, yet speedy solution to the development of software and systems environments. The System Engineering Institute’s (SEI’s) Commercial-off-the-Shelf (COTS)--Based Systems Initiative is a move in this direction. It helps people in the Information Technology environment become more aware of the potential and success of this approach.

 The case presented is that of a company in the retail shoe business that decided to change their MIS environment from a mainframe-based system to a client-server based system. The conceptual framework that directed initial efforts in systems development was Ivar Jacobson’s Use-Case Driven Approach to Object-Oriented Systems development. The approach was fruitful in guiding efforts towards understanding the problem domain and identifying process requirements. The MIS team successfully completed the first of 5 stages of the traditional software development cycle below:

• Requirements Analysis
• Design
• Implementation
• Testing
• Reengineering and Deployment

 The listing above shows the chronology of the software development cycle. For a more extensive discussion of these steps refer to Booch (1991), Jacobson (996), Kachmarik et al. (1996), Land et al (1996a,b,c). The final paper, Land et al. (1996c) contains a extensive discussion of the different methods of testing software. The results of initial efforts, the performance of requirements analysis, produced a document that identified use-cases, problem domain, and system requirements for the different departments of the company (Bonto-Kane, 1998). The next step was design. In this particular case, design was not carried out in the "purist’s" tradition of creating an ideal system that will address system requirements without regard for implementation and real world constraints (Jacobson, et al., 1996; Coad & Yourdon, 1991). In the second stage, efforts were devoted towards the purchase of commercial products and the modification and integration of these products to fit system requirements. The approach of using commercially available software packages as drop-in solutions is perfectly within the framework of object-oriented technology. This approach is called the COTS-Based Systems Initiative where COTS stands for commercial-off-the-shelf (COTS) products.

 The MIS team expected some degree of recursive behavior in the Design phase Implementation phase and Testing phase. The determination of code reuse and the best fitness applies here. Example, the COTS product solution Requirements Analysis phase called for Oracle Financials, Richter Merchandising Systems, and Impromptu. Impromptu was replaced with Business Objects. During Phase 2 through 4 you can expect it to be dynamic, a third party software solutions offered may change support of their integrated products during your roll out and your solution must accommodated.

 The Reengineering and Deployment phase in the object oriented client server environment is a study in itself that goes beyond the scope of this paper. Further research is currently being done by our team and will disclose in detail at a latter point in time.

 In this paper, we began considering COTS products not at the implementation phase but early on at the requirements gathering phase. After, having obtained some preliminary requirements and assessment of the problem domain, research was done to find out what products can serve that business process. The efforts were done separately. One group was involved with the traditional gathering of system requirements using the Use-Case approach and the other group was involved in the survey and examination of commercially available software applications and services. It will be shown in this paper that the simultaneous employment of both approaches (from opposite sides) helped develop an appropriate, state-of-the-art, speedy solution to systems development.

 After a good assessment of process requirements was done, results of the other team’s efforts in surveying commercial product applications were examined. Some products had most of the functionality needed while others fell short. Those that came short of the functionality required were not in the candidate list or were listed as alternative choices. Other considerations besides functionality came into play such as: price, support, and stability of the company (company could stay long enough in the market to provide support and develop future upgrades to the product).

 The assessment of system requirements was based on use-cases within the business processes of the company. This is appropriate in the paradigm of object-oriented technology. However, these use-cases are based on a unique and confined environment, on current methods and practices by which the company performs its business. These methods and processes may actually be obsolete, cumbersome, or inefficient. Examining commercially distributed software applications may reveal a function-rich application having capabilities one would not have designed into a product due to the narrow exposure one gets from working in one business context. Thus, examining COTS products, actually expanded the scope of functionality requirements of the system. Also, examining innovative COTS products may change the way one performs internal processes vital to the business. COTS products may be able to replace obsolete or cumbersome business processes in the company.

 After having decided on the best candidate, the product was still not a "perfect fit". At this point, it was the team to determine where the software fell short of in-house requirements by doing a functional gap analysis. When this assessment was completed, programming work was defined to bridge the gap and help with a good integration of all the software and hardware components. All in all, a software application or a system component was quickly put together and tested before the next area of business process was addressed.

 The following is a summary discussion of the pros and cons of using the COTS Initiative:

 There are two disadvantages to using COTS products:

• One disadvantage to the use of COTS products is that they may have only some of the functionality that one is looking for. It may, therefore, not address all of the requirements. Customization of in-house code or third party modifications may be needed, resulting in questions, who will support the modifications as time goes on, how will you do upgrades, etc. For a corporation, it becomes an economy of scale.

• Another disadvantage is that COTS products may fulfill most if not all of the functionality requirements one is looking for but that the task flow or the method of accomplishing the procedure is not an exact match to how one’s business performs the task. The human factors considerations becomes important issue when looking at process change and the willingness of existing personnel to change business processes to fit new system designs can be a challenge corporations may not want.

These are limitations that people usually are aware of already. Thus, some work may still be involved in modifying and customizing COTS products to suit one’s needs. On the other hand, if the program is not modifiable, one may be stuck with a work process that is set by the software and to which one has to adapt. Thus, one may have to alter one’s processes to suit the product. There are cases where this will be helpful especially when obsolete business processes need to be replaced.

There are advantages, as well to using COTS products. The advantages, in fact, outweigh the disadvantages:

• COTS products may offer greater functionality not previously considered in the requirements specifications. Since, system requirements are derived in the narrow confines of one’s problem domain, one will not be able to pay attention to and design other kinds of capabilities. Thus, one may purchase a product that turns out to be function-rich and performs a lot more than what one expected.
• COTS products come as already available ready-to-use applications. If they directly address one’s needs and requirements, there is no need to "reinvent the wheel."

• COTS products are developed by a dedicated team of programmers and developers. Considerable time in man hours has been dedicated to the product that usually is beyond comparison to the hours that a small business company might invest. This team will already have invested considerable man-hours of work that will be beyond what any small or medium sized MIS department of a business company can give.

• COTS products will have undergone a considerable amount of software testing. Since there is a dedicated team working on the product, systems test, functionality test, usability test and other evaluations have already been carried out. Also, by making the product available out in the market, it allows itself to be reviewed by users and experts. The real test is how a product performs out in the real world with a variety of users and compare to other similar software in the commercial world. A product that stands up to this kind of a test is already well on its way to being a good candidate as a software solution for a company.

• The initial disadvantage of having a product that is not an exact match to one’s process, task flow, or workflow may prove to be not a con in some cases. The result will be that one may change the way one does business but it may, in fact, improve the way one does things.

• Using COTS allows one to stay competitive. Using tools that other companies also use, helps one keep abreast with the way the business is conducted in the real world. Also, one is aware of what the competitors are using and how they are doing their business.

• Using COTS allows one to avail of upgrades to the product and, therefore, keep current with trends and advances in technology.

 In the process of fitting together software and systems components, the MIS team saw both the pros and cons unfolding. The PROS were not a concern but the CONS were related to deficiencies in functionality that failed to meet system and process requirements. As far as this was concerned, a functional gap analysis was performed to assess what functionality was missing. Efforts were confined to the creating the appropriate code that will supply the missing functionality or integrate the functionality of one product to another. As far as the functional gap analysis was concerned, this method helped in integrating various software components and helped for a quicker implementation of a component solution.

Thus, it seems that from the author’s experience, the consideration of COTS products early on in the development cycle, not only helps uncover what has already been designed and developed as a commercial tool but also helps one become aware of how one can change the way one does business. The identification of use-cases is very helpful in problem domain analysis. However, these use-cases are specific to the current methods by which tasks are being performed. One can benefit from alternative ways of performing process while achieving the same objectives.

Bonto-Kane, Marivic A. (1998). Object-Oriented MIS Systems Design and Architecture Systems Requirements Analysis: A User’s Perspective. (Master’s Thesis, Binghamton University).

Booch, Grady (1991). Object-Oriented Design with Applications. Redwood City, California: The Benjamin/Cummings Publishing Company, Inc.

Coad, Peter & Yourdon, Edward (1991). Object-Oriented Analysis. Englewood Cliffs, New Jersey: Prentice Hall, Inc.

Jacobson, Ivar, Christerson, M., Jonsson, P., & Overgaard, G. (1996). Object-Oriented Software Development: A Use-Case Driven Approach. Addison-Wesley Publishing, 1994, ISBN 0-201-54435-0.

Kachmarik, Michael B., Wang, Feiqiao, Tian, Zhen, Zhang, Junsheng (1996). "ACME Warehouse Management, Inc. Case Study of ACME Warehouse Information Management System". (Binghamton University research paper)

Land, Walker H., Kachmarik, Michael B., Wang, Feiqiao, Tian, Zhen, Zhang, Junsheng 91996a). Object-Oriented Software Engineering Approach to Develop Reusable System Components and Code. (Binghamton University research paper)

Land, Walker H., Kachmarik, Michael B., Wang, Feiqiao, Tian, Zhen, Zhang, Junsheng (1996b). Object-Oriented Software Engineering Approach to Use Cases Requirements and Its Formulation. (WISR’8 at Ohio State University)

Land, Walker H., Kachmarik, Michael B., Wang, Feiqiao, Tian, Zhen, Zhang, Junsheng (1996c). Object-Oriented Software Engineering Approach to Metrics Measurements. (Binghamton University research paper)