All desktop side and server side software are COTS as they come with wide range of features and options that they fit into all the demanding needs of versatile customers. COTS products are adopted by using built-in configuration mechanism that allow the functionality of the system to be tailored to specific customer needs.
“A commercial-off-the-shelf (COTS) product is a software system that can be adapted to the needs of different customers without changing the source code of the system.”
Software reuse based on COTS has become increasingly common. The vast majority of new business information processing systems are now built using COTS rather than using an object-oriented approach. Although there are often problems with this approach to system development (Tracz, 2001), success stories (Baker, 2002; Balk and Kedia, 2000; Brownsword and Morris, 2003; Pfarr and Reis, 2002) show that COTS-based reuse reduces effort and the time to deploy the system.
There are two types of COTS product reuse, namely COTS-solution systems and COTS-integrated systems.
COTS-solution systems consist of a generic application from a single vendor that is configured to customer requirements.
COTS-integrated systems involve integrating two or more COTS systems.
COTS can be either software or hardware
Operating Systems (UNIX, Windows/NT, OS2)
Databases (Oracle, Sybase)
Graphics Packages (Motif, ??)
Busses (VME, PCI, cPCI)
Processors (Motorola, HP, Sun, Intel)
Disk Drives (Western Digital, Red Rock)
Peripherals (Printers, Monitors, Keyboards, etc.)
There are many areas where COTS successfully replaced traditional custom software examples are
– Space Shuttle (non-mission-critical systems)
– Missile Guidance systems
– Military ground based and shipboard sensors (radar, sonar)
– Industrial control and monitoring systems
– Air traffic control
This approach to software reuse has been very widely adopted by large companies over the last 15 or so years, as it offers significant benefits over customized software development:
1. As with other types of reuse, more rapid deployment of a reliable system may be possible.
2. It is possible to see what functionality is provided by the applications and so it is easier to judge whether or not they are likely to be suitable. Other companies may already use the applications so experience of the systems is available.
3. Some development risks are avoided by using existing software. However, this approach has its own risks, as I discuss below.
4. Businesses can focus on their core activity without having to devote a lot of resources to IT systems development.
5. As operating platforms evolve, technology updates may be simplified as these are the responsibility of the COTS product vendor rather than the customer.
Of course, this approach to software engineering has its own problems:
1. Requirements usually have to be adapted to reflect the functionality and mode of operation of the COTS product. This can lead to disruptive changes to existing business processes.
2. The COTS product may be based on assumptions that are practically impossible to change. The customer must therefore adapt their business to reflect these assumptions.
3. Choosing the right COTS system for an enterprise can be a difficult process, especially as many COTS products are not well documented. Making the wrong choice could be disastrous as it may be impossible to make the new system work as required.
4. There may be a lack of local expertise to support systems development.
Consequently, the customer has to rely on the vendor and external consultants for development advice. This advice may be biased and geared to selling products and services, rather than meeting the real needs of the customer.
5. The COTS product vendor controls system support and evolution. They may go out of business, be taken over, or may make change that cause difficulties for customers.
In 1994, then Secretary of Defense William Perry well recognized the potential for commercial products in the Directorate of Defense and authored what has come to be known as the “Perry Memo.” Entitled Acquisition Reform – Mandate for Change, Perry asserted that business policies that once made sense were no longer applicable to current technologies. Commercial-off-the-shelf, or COTS would become an integral part of DoD procurement.
With a COTS item – already built – the government cannot monitor the build process, nor should it. For example, Dell computer hardware is widely used in the DoD. Think of what a waste of time, money, and really how downright silly it would be for DoD program managers to monitor operations at a Dell facility. And so, milspecs cannot apply; they simply do not make sense (Carter & Perry, 1999). Rather, the government puts forth performance-based requirements, and then the program manager finds a COTS product that meets those needs.
1- Software Engineering 9th Edition by Sommervillie Page 440-445
Related Technology News:
- Alternate mark inversion (AMI)
- Encoding Schemes
- Differential Manchester encoding
- What is Cyclic Redundancy Check (CRC)
- Component Based Software Engineering (CBSE)