COTS

1. What are COTS solutions?

COTS solutions are third-party solutions that are bought, licensed, or acquired; often, they are integrated into a larger system. COTS-based systems (CBS) are COTS solutions in which at least 50% of a system is based on a COTS product. COTS products often have customized configurations, but may also be solutions in which the base product deviates into a modified-off-the-shelf (MOTS) solution.

2. What are considerations before buying COTS?

Prior to even considering COTS, the “make or buy scope” decision must look at the work breakdown structure (WBS), risk breakdown structure (RBS), and cost breakdown structure (CBS).

3. What are risks of COTS products?

a. By choosing to use COTS, an architect takes on an additional risk that he or she cannot control. Vendors may go out of business, choose not to support the existing components, etc.... COTS components are just another factor that an architect must consider when choosing or designing the architecture of a system. Use of COTS has its associated risks, as COTS components can be thought of as black boxes that just work. The tradeoffs between COTS components and homegrown components are development time versus flexibility and control. Because COTS components are restricting by nature it is critical for appropriate stakeholders to be more involved in those aspects of the system that are not controlled by a software architect.

b. COTS projects are surrounded by known and unknown risks, both for implementation and for ongoing sustained engineering and maintenance. One of the biggest questions after the procurement decision is how to address the underlying COTS paradigm regarding which project management strategy or strategies to best manage the project.

In part, this revolves around the development or implementation requirements for COTS: Are we dealing with Glue Code, tailoring effort, or assessment effort? Glue Code is the requirement for custom development by an application that is external to the COTS package to allow integration. Tailoring effort requires custom code by the vendor within the COTS package to allow integration. Assessment effort evaluates the suitability of using the COTS right out of the box with only altering the human workflow processes to use the COTS 

4. RFP? requests for proposals (RFP) 
    SOW scope of work
The RFP SOW must be detailed sufficiently to allow prospective sellers to determine if they are capable of providing the item, service, or solution.

5. What is glue code?

Glue code, also called binding code, is custom-written programming that connects incompatible software components. Glue code can be written in the same language as the code it is connecting together, but it is often written in a specialized interpreted scripting language for connecting system components called a glue language .

6. Why do COTS project management processes can be challenging?

COTS project management processes are challenging because of the integration of the vendor’s software and hardware as well as the extension of the in-house system or environment. Understanding the threat and value brought to the organization by COTS also requires a highly flexible plan to incorporate the dynamics.

In-house non-COTS deliverables, COTS configuration support, and COTS tailoring activities must correlate to the COTS vendor milestones. COTS solutions still require some type of software development methodology to allow parallel activities of vendor and customer. 

7. What are important factors to consider COTS?

Strategy defines direction, requires knowledge of desired outcomes, and influences decisions on the allocation of time, people, and money. For a COTS solution strategy, there needs to be a diligent assessment process: between the requirements and software or technology being implemented; the IT or technology/development life cycle of in-house and COTS vendor; and the project management approach to meeting customer needs, delivering business value, and being as effective and efficient as possible. The strengths, weaknesses, opportunities, threats (SWOT) approach should be also be considered in the contract negotiations for the COTS solution from these perspectives.

8. testing COTS?

Agile testing brings testing in as early on as the detail design phase and continues through each iteration. Project situations also dictate the “just enough” testing and entail developer unit tests, scenario tests, acceptance tests, and paired testing (like paired programming). The client checkpoint at the end of the iteration reflects what has been done, learned, and needed for the next iteration. Frequent and effective testing increases the cost in the short term but reduces the cost of poor quality at handoff. Waiting for end game testing does not allow the team enough time to act on defects found at the end.

Conclusion

Conclusion

Value added COTS solutions are complex and require integration of milestone activities. COTS project strategy involves pre-planning and the assessment of best value added solution, including glue code and tailoring. COTS solution solicitations must contain requirements to determine the best feature match and what integration effort and risks must be accounted for in the project plan. SWOT assessments of vendor and in-house capabilities must be considered in the COTS selection.

The reality of COTS solutions is that the project management strategy must be flexible in order to handle the challenging integration environment as well as vendor and in-house development life cycle alignment. Cost of poor quality can be attributed to ineffective processes, and quality metrics must be applied throughout the project with the client checkpoint being taken seriously for integration alignment by both the in-house and vendor team staffs.

COTS solution handoffs at rollout must consider the operation team, customer, support and operational level agreements for upgrades (in-house and vendor), and integration dialogues.