Commercial Off The Shelf (COTS)

Commercial Off-the-shelf (COTS) Jain University I Sem Avionics:

Commercial Off-the-shelf (COTS) Jain University I Sem Avionics By BK Deepak Mujeeb Jeelani Shiny Nivolya

Index:

Index COTS definition issues and examples. Function fit analysis process. COTS in Aricraft.

Slide 3:

Commercial, off-the-shelf (COTS) or simply off the shelf (OTS) is a term defining technology which is ready-made and available for sale, lease, or license to the general public. The term often refers to computer software or hardware systems and may also include free software with commercial support.

Slide 4:

COTS typically requires configuration that is tailored for specific uses. The use of COTS has been mandated across many government and business programs, as such products may offer significant savings in procurement, development, and maintenance. Motivations for using COTS components include hopes for reduction of overall system development and costs (as components can be bought or licensed instead of being developed from scratch) and reduced long-term maintenance costs.

Slide 5:

For c ommercial o ff- t he- s helf , an adjective that describes software or hardware products that are ready-made and available for sale to the general public. For example, Microsoft Office is a COTS product that is a packaged software solution for businesses. COTS products are designed to be implemented easily into existing systems without the need for customization.

Slide 6:

Organizations faced with the difficulties and costs associated with the development of software have turned to the reuse of existing software or using commercial off-the-shelf (COTS) software as an option. Reuse, whether involving home-grown or COTS components, certainly promises lower cost, better quality, a decrease in risk, and the potential for a less stressful development process. Many such efforts succeed, but the promises of decreased cost and risk are not always realized. Requirements, algorithms, functions, business rules, architecture, source code, test cases, input data, and scripts can all be reused. Architecture is a key for reuse

Slide 7:

Many programs that plan substantial reuse find that the assumptions made concerning how much functionality could be achieved were overly optimistic. They are then disappointed when the amount is less than projected or they experience much higher costs for reuse than had been estimated. Reuse is not a ultimate saver of schedule, or cost reduction measure that optimistic estimators managers promise. In reality, reuse or COTS can lower cost, but only partially. COTS application software often satisfies less than 40 percent of the functionality of an application.

Slide 8:

Issues and Considerations when using COTS Supporting, maintaining, and upgrading systems with long life-cycles (10+years) Licensing and Data Rights COTS Software is usually distributed under license (a per-user fee is typical) COTS documentation is normally copyrighted - distribution as part of another product usually requires special arrangements and a copy fee Software source code and designs for hardware are usually protected by copyright or patent - even after it is no longer distributed

Slide 9:

Even when functional requirements are reasonably well satisfied, critical non-functional requirements such as security, reliability, and performance must be addressed, resulting in schedule and cost impacts. If the functional or interface requirements are not satisfied, wrappers (additional code required to make the new development able to use the existing software) must be planned, designed, developed, and tested. In all cases, the system or software architecture must be sufficiently mature to allow the detailed design of critical interfaces and the conduct of reasonable trade-offs to enable the evaluation, selection, acquisition, and integration of the capability into the system or software architecture.

Slide 10:

Examples : Software: Operating Systems (UNIX, Windows/NT, OS2) Databases (Oracle, Sybase) Graphics Packages ( Motif) Hardware: Busses (VME, PCI, cPCI ) Processors (Motorola, HP, Sun, Intel) Disk Drives (Western Digital, Red Rock) Peripherals (Printers, Monitors, Keyboards, etc.)

Slide 11:

Today many organizations are attempting to reduce software development effort and schedule by purchasing off-the-shelf solutions rather than building them in-house. This strategy can be very cost effective if the Commercial Off-The-Shelf (COTS) solution meets the customer requirements. Unfortunately in numerous situations, COTS solutions have proven to be a great disappointment. This is largely due to the lack of fit in meeting the required functionality.

Slide 12:

The result is a major COTS enhancement project comparable to a custom developed solution in terms of overall project schedule and cost. And highlighting the fact that, it is important to conduct a complete and accurate assessment of how well a COTS solution fits the requirements and not rely on vendor claims of high compatibility.

Slide 13:

Function Fit Analysis The technique, called Function Fit Analysis, is based on function point analysis. Function point analysis is the decomposition of an existing or planned system based on the user's perspective of functional requirements. Function fit analysis therefore can be used to evaluate various COTS solutions, select the best solution, and determine the degree of enhancement work necessary to meet customer requirements.

Slide 14:

Function Fit Analysis provides the ability to: Document functional requirements in terms understandable to users and technicians Identify the functional gap of the COTS products Quantify the effort necessary to enhance the COTS package Provide input into the "make versus buy" decision making process .

Slide 15:

Function Fit Analysis Process

Slide 16:

Step 1: Requirement for Function Point Analysis This step is used to identify and document exactly what functionality is necessary to meet the customer needs. This assessment should be completed early in the development life cycle to provide insight into the scope of the project.

Slide 17:

Step 2: COTS Functional Evaluation This step involves reviewing the various COTS choices and comparing their functionality to the requirements documented in the first step. Each database and panel in a COTS alternative is reviewed to identify functions that: A. Exist in the COTS with no change required [Unchanged]

Slide 18:

B. Exist in the COTS but require enhancements to meet the requirements [Change] C. Need to be added to the COTS product [Add] D. Exist in the COTS but are unrelated to the requirements and will not be used [Unused]

Slide 19:

Step 3: Functional Gap/Fit Analysis This step is used to apply a percentage to the 'fit' between the requirements and the COTS product. By comparing the function point counts from the previous two steps a fit can be determined.

Slide 20:

Step 4: The function point data from the previous steps is used to develop the project estimates in Step 4. This step uses a top-down approach to estimate effort, staff, and schedule for each alternative under review.

Slide 21:

Personnel and Management - focuses on knowledge and experience of I/S and user personnel involved in the project. Process and Methods - focuses on what development and project management methods are used and the extent the methods are followed. Technology and Tools - evaluates the technology being utilized and the effectiveness of the tools available to the developers.

Slide 22:

Environment and Support - evaluates the development environment in terms of computer resources, administrative resources, and overall working environment.

Slide 23:

Step 5: Make/Buy Analysis The function point information and estimate data from Steps 1 through 4 is used in Step 5, the Make/Buy Analysis. The Make/Buy Analysis is the decision making process to determine whether to implement a COTS solution or build a custom solution.

Slide 24:

Examples where COTS has replaced traditional (custom) systems Space Shuttle (non mission-critical systems) Missile Guidance systems Military ground based and shipboard sensors (radar, sonar) Industrial control and monitoring systems Telecommunications Air traffic control COTS IN AIRCRAFT

Slide 25:

Areas in U.S. military budgets that are among the driving factors for COTS systems are: The unmanned aerial vehicle (UAV) Reconnaissance(C4ISR) programs. High-fidelity simulation systems that duplicate real-world environments are necessary to help pilots and warfighters prepare for any situation like : Refueling in mid-air To avoiding runway incursions To engaging in air-to-air combat.

Slide 26:

The Virtual Avionics Procedure Trainer (VAPT) provides flight crews with training and mission preparation using new avionics equipment that is a combination of commercial off-the-shelf (COTS) hardware and re-hosted software

Slide 27:

COTS systems add value in three primary areas for the Department of Defense (DoD) Aircraft are designed and produced to a recognized and approved government standards and approval process. Timing Spreading risk from a sole military user to the market base

Slide 28:

A UH-72A Lakota COTS products are ripe for second- and third-level suppliers Environmental control units Electro-optic infrared sensors Medevac kits Commercial seats Commercial rescue hoists Searchlights Lakota

Slide 29:

DuraNET® 1268 Gigabit Ethernet switch, an ideal COTS SWaP-constrained aircraft In tactical ground vehicles and maritime assets. It is rugged Layer 2+ Gigabit Ethernet switch Ten triple-speed 10/100/1000Mbps ports Connecting IPv4 and IPv6 compatible Designed for very demanding MIL-STD-810F environmental and MIL-STD-1275/704/461

Slide 30:

Built on COTS (Commercial Off-The-Shelf) components and a baseline, ATC*ISS has an open architecture that offers high flexibility in data source interface, human machine interface and system architecture design. Its modularity accommodates large installations with a distributed network of hundreds of workstation and small ones with a few user positions. It is thus suitable for both air traffic control centre and control tower. COTS in Air Traffic Control

Slide 31:

Telephonics’ AeroTrac® system is fully developed It’s an advanced air traffic control system using an open architecture, and incorporates our premier multi-radar data processor, next generation flight data processor and advanced high resolution graphical controller workstation displays based on a robust COTS system architecture.

Slide 32:

The Aerospace Corporation, and the Canadian Department of National Defence have shown the inherent weaknesses and risks of using COTS products to develop new systems. This is studied by comparing COTS – Myth vs. Reality Risk Factors

Slide 33:

COTS Myth COTS Reality Less expensive development costs Higher integration costs & risks; more up-front testing COTS acquisition costs – licenses & fees Lower life-cycle costs Maintenance of COTS products required Software modification can be difficult & costly Product upgrades may include needed functionality, but may be incompatible with prior releases & other software Shorter development schedules Inexperienced integrator will require learning curve Schedule must include product upgrade integration time Functionality exists in COTS Software may only partially satisfy requirements Software may satisfy unnecessary requirements Limited requirements influence, risks vendor failure Application portability/interoperability Not guaranteed, even among similar operating systems Ease of interfacing proportional to system complexity Higher reliability COTS products still contain bugs, possibly malicious code Developer must rely on COTS vendor to fix problems Difficult to determine source errors Vendor not liable for failure Better user interface Interfaces unmodifiable for generic user communities Complete/true documentation, manuals Variable documentation, undocumented features Vendor service available Variable support, training, integration

Slide 34:

QUESTIONS ?