Reliability with Maintainability and Supportability of COTS - Research Paper Example

?Reliability, Maintainability, and Supportability of COTS Commercially off the shelf (COTS) is a term which defines a none developmental item (NDI) that is both sold in substantial quantities and commercial in the market place. It can be utilized or procured under contracts done by the government in the same mode as it is accessible to the public. Examples items which are related technology wise, such as computer hardware systems or software with commercial support. Purchases of COTS are alternatives to one off governmental funded development or in house development. These systems basically, require specifications which are tailored for specific purposes. The use of COTS is wide spread across many business and governmental programs; this is because these products offer significant savings in maintenance, procurement and development. The motivation behind the usage of COTS a component includes reduced maintenance cost in the long run and hopes that the overall system cost and development, this is because components can be licensed or bought instead of developing them. COTS were considered remedies for intractable problems during the 1990s. COTS development came into being with tradeoffs which were not so obvious. An example been initial and development cost and time which not so much a problem can be reduced but at the expense of another. Such as depending on a third party who is to lease components and increase in the integration of software component works. Software specifications are encrypted externally so government agencies view that in the long run when changes are done to the product compatibility will be a hindrance (McKinney 23). COTS reliability can be verified using an analysis and reliability estimation technique applicable to high level designs. The technique is known as Scenario-Based Reliability Estimation (SBRE). SBRE is specific for COTS whose analysis is purely based on executable scenarios. While using scenarios, we construct a probability model known as Component Dependency Graph (CDG). These are graphs which represent component reliability, components, interface and link reliability, transition probabilities, transitions, components average time of execution. In CDG, components link and interface reliabilities are given focus as the first class elements to be put in the model. The reliability of the application is analyzed by an algorithm presented its analysis also include; reliability of its interface and components. The SBRE algorithm identifies critical component interface and critical components by interpolating the sensitivity of the application reliability to changes in the interface and components. To ensure a software application is reliable is a difficult task even if it was commercially pretested therefore, there has been the emergence of several techniques for analysis and estimation of components based application reliability. And they are categorized as: Component Based Reliability Estimation - the reliability of the application is estimated using the individual’s components reliability and interconnection mechanism. System Level Reliability Estimation – applications reliability is estimated as a whole. For example using system level architecture evaluation or system testing (Ammar, H , et al, 2004) Underestimating the technical risk associated with evaluation, integration and selection of software components can result to high maintenance/development cost and long schedule delays. Trends in computer based products, such as mobile phones and vehicles, is shorter lifecycles and shorter. Therefore, time spent on the development of new versions of a product or new products must be reduced. A solution to one of the emerging problems is reusing of solutions and software designs in new versions of products and systems. Properly handling reuse will greatly improve the reliability since the code is executed in a different context and longer time. However, reuse is not trivial; it puts strong demands on the methods of development in order to achieve success. Reuse application in the development of real-time systems, complexity in methodology sets in since both temporal and functional behavior must be considered. Using of COTS components can be a way of reducing time of development been competitive by getting products to the market inexpensive and fast. COTS components provide increased reliability as compared to custom made components since field testing is done intensively to their products. Some of the advantages of developing a system using COTS components: components are less costly than those developed in-house; functionality is accessible to the developer instantly, component vendor may be an expert in the functionality of the component. In order for a COTS component to be integrated in a system, the developer should put relevant properties of the component into consideration such as temporal behavior, robustness, limitations, preconditions and other forms of underlying assumptions on the environment (Froberg 11). Software maintenance includes activities required to see software evolve over its lifetime. Although the motivation for COTS maintenance and custom based systems is the same, handling of personnel maintaining the COTS is different. The different activities required for COTS maintenance arise because of a number of reasons. The primary reason for the different activities of maintenance is the fact that evolution and upgrade for the individual COTS components and products are outside the control of the acquisition organization and system developers. Agents or product developers are the ones who are involved with COTS product support and maintenance. The system developer or the agent must treat these products as a single entity. With no or little visibility into the internal parts of the product, and perform maintenance in large scale rather than at the source code level. The source code required for the integration of large scale COTS products is the only source code been maintained. This includes code for tailoring and wrapping the individual’s products as well as the code required to connect products together. Tailoring and wrapping of products becomes essential to overcome architectural mismatch between products, to build codes that work around problems in order to overcome the inevitable bugs that are included in almost all COTS products and product customization so that it can conform to local requirements. From the perspective of acquisition agencies, they have ceded control effectively over evolution and maintenance of large parts of the system to commercial agents outside. COTS intensive system maintenance is now driven by venders in a large part of the variety of products rather than maintained by the system developer. Having amortized the maintenance and development cost among a number of different users, acquisition agencies are now among many users pointing in the direction of COTS software development. In order to manage and maintain effectively COTS-based systems it is important to identify the activities of management and maintenance personnel. Once activities are identified, strategies are developed in order to facilitate these activities. Activities for maintenance include: Troubleshooting and repair - all systems are due to failure and COTS based systems are no different. However, with COTS based systems management and maintenance personnel cannot check inside components when isolating causes of failure in systems. Trouble shooting activities comprises of liaising with the COTS product managers, developing workarounds or loopholes with the product and identifying various causes of failures among COTS products. Component reconfiguration – reconfiguring components is the art of adding, deleting and replacing components within a system. Reconfiguration occurs for a number of reasons the most common being frequency with which updated versions of the software is released. Other reasons include replacing of aging components from competing vendor, or to delete and add products as a system evolves functional requirements. Reconfiguring of components is an expensive activity requiring the integrators to pass through a complete release cycle which includes system regression testing, design, testing and evaluation. Configuration management – management for COTS based systems configuration is done at the product level as opposed to the source code level. Issues that must be addressed by the maintainers include: support and availability level provided by the vendor of the product; individual product history change; management of the COTS-based systems configuration that are installed at each deployed site; constraints and compatibility requirements between sets of products; and issues of licensing associated with each product. The maintenance activity description include; tracking deployment configurations, determining versions of a product that are compatible and tracking versions of different COTS products. Testing and evaluating – this is an ongoing activity during maintenance of COTS products. New products as well as new versions of products must be evaluated for inclusion within the system and product testing during operation use. Tailoring user level services – COTS products provide a functionality that can be used a variety of organization and applications. Tailoring and customizing of this functionality is done by system interrogators to satisfy local operation requirements that are unique to the end user. Systems are said to be successful if they can be tailored and modified to meet evolving user requirements. Tailoring for COTS involves an ongoing process of configuring and customizing products, and service combination of multiple products. System monitoring – system maintainers and managers must continuously monitor a system during its operation. This must be done for the measurement of resource usage and performance, determine user behavior and watching for failures. Monitoring for maintenance purposes can be difficult to do effectively because, COTS software is a black box, with limited visibility into internal behavior (Dr. Vigder and Dean 19). COTS component qualification also known as software selection is a process for determining usage fitness of components developed previously and are being applied in a new system. Component qualification is a process for component selection when competing products exist in a market place. Selection of a product can extend to include selection of the development process used to maintain and create it example ensuring the validation of algorithms and code inspection has taken place. This is obvious mostly in applications that are safety critical, but can reduce the usage of pre existing components. There are three faces of COTS component qualification: evaluation, definition and alternatives identification (Kontio, 16). The evaluation criteria definition process decomposes the requirements of the COTS into a set of hierarchy whereby each branch ends in an evaluation attribute. The criteria comprise quality aspects that are difficult to isolate such as reliability of components, usability and predictability, component and functionality. Example, the type of services provided, aspects of a components interface such as the use of standards. The identification alternative involves the screening and search of COTS components of candidates that should be included for detailed evaluation. In the evaluation phase, the evaluation criteria is used to identify and asses the property of the candidates components. While there are several aspects focusing on software selection, there is little agreement on which quality measures or attributes of a component are critical to its use in a COTS based system. A useful work includes delta technology framework that helps with the evaluation of new software technology, Software Engineering Institute (SEI) and PORE, a template based method to support acquisition requirements for COTS product qualification. Another technique off the shelf option provides a decision framework and addresses the complexity of component selection that supports analysis multi-variable component selection. The above evaluation approaches involve a combination of paper-based studies of the components, discussions with users of those components, prototyping and hands on benchmarking. However, the soft issues or none technical factors are not adequately addressed by this approach. An appropriate COTS based software evaluation framework should be simple to relate and use. While addressing the economical and political factors that often separate a winning technology from other contenders. Software sustainment is the process, material, people, information and procedures required to support, operate and maintain the software aspects of a system. Software sustainment addresses not only integral parts of maintenance such as deployment, configuration, documentation, security, operations, training of sustainment personnel and users, management, technology refresh, help desk and COTS product management. A successful software sustainment comprises of more than updating and modifying source codes. It also depends on the skills of the sustainment team, experience of the sustainment organization, the operational domain of the team and the customers’ adaptability. Therefore, software operations as well as maintenance should be considered part of software sustainment. A criterion for a system to enter sustainment is as shown while not all inclusive; A stable software production baseline. Negotiated and current sustainment transition plan. Authority to operate for an operational software system. Current and complete software documentation. Sustainment training and staffing plan. Signed Source of Repair Assignment Process or equivalent documentation. A program is said to be good if it effectively does the work instructed to do without errors in its execution. Programs that uses COTS Based Software know how good a program are if, they smoothly work together during implementation, if it does the analysis of comparative advantage and happens to use the given COTS Based Software. COTS Based Systems are used widely even in space some of the reasons for using this software are: Every three years a new generation of leading COTS technology is introduced. COTS parts capabilities and performance continue to increase example high density memories and processing power. The availability of COTS parts is proliferating Acquisition cost of COTS is much less as compared to radiant hardened counterparts; by using radiation tolerance the cost advantage can be preserved. Some COTS parts have been seen to demonstrate good to excellent reliability. In the Jet Propulsion Experiment (JPE) the mars pathfinder used a COTS hybrid converter because of schedule and cost constraints. They ordered from a non-QML supplier to be specified to military temperature range. To be a successful COTS product and COTS-Based System evaluator you need to; develop COTS software criteria of evaluation, determine COTS software evaluation requirements, and understand the impact of COTS software products on the system development process, employ a process that addresses the inherent tradeoffs of a COTS software evaluation. Successful COTS product evaluation is part of a large process of sustaining, architecting, building and designing COTS based systems. COTS Based systems are compose of one or more COTS products. Each COTS software product life cycle includes refreshes, updates and obsolescence. This life cycle is not based on the budgetary cycles or on the users’ request, but rather on COTS software vendors’ business plan and on the marketplace demands. The technology on which COTS based software is constantly advancing; this requires the program office plan to maintain an orderly refresh plan. Without careful thought and planning in designing a COTS intensive system, the retesting, development and redesign efforts due to the difference in tailoring and configuration of the replacement COTS products can be substantial. It is essential for organizations to maintain and create a thorough COTS management plan that does the addressing of issues and provide clear plans to incorporate updates and new releases of COTS software products. The evolution of the system must account to how changes to one component can affect the others and how all the COTS software components work together. Adequate training skills, development tools and parallel testing and production environment are needed to test and integrate updates and new releases. Many organizations buy COTS Based systems and have them delivered and integrated by a third party integrator. In conclusion the initial deployment of a system is usually accomplished by the development organization. As part of deployment, an organization resolves users’ issues, problems and questions in the form of a help desk. Users of a system easily become accustomed to the height of shore up that is provided. The level of support the user receives from the help desk must be improved or maintained during the sustainment and during the transition. Issues that may arise during the transition time frame are: the mechanics of contacting the help desk, the amount of hand holding expected by the users and overall user satisfaction. Users are reluctant to use system upgrade because it represents transformation and people despise it, at least most of them. Users are accustomed to the current system and while it may be faulty they know how to handle them because they know what to expect. Users expect and need hand holding to work through issues. When system upgrade is transitioned to sustainment, the amount of hand holding will definitely change and from the perspective of the user this is a negative change usually met with opposition and criticism. COTS Based Systems are inexpensive and have an advantage over other categories of software hence their usage is wide spread. These systems are tested extensively hence probability of errors is minimal if not none. There is also the fact that product support is readily available. References McKinney, D, 2001, Impact of Commercial Off-The-Shelf (COTS) Software and Technology on System Engineering, Raytheon's Network Centric Systems group, Texas. Ammar, H , et al, 2004, Scenario-Based Reliability of Component-Based Software, west Virginia University, Morgantown. Froberg, J, 2002, Software Components and COTS in software system development, Malardalen University, Vasteras. Dr. Vigder, R and Dean, J, 1998, Building Maintainable COTS-Based Systems, IEEE Computer Society, Washington , DC. Kontio, J, 1996, A Case Study in Applying a Systematic Method for COTS selection, Sage publications, London. Read More