A comprehensive analysis of warranty claims and optimal policies

Nowadays many products, such as 3C products (Computer, Communication and Consumer Electronics) and cars, consist of software and hardware. The causes of warranty claims of such products may be attributed to software specific failures, hardware specific failures, software-hardware interaction failures and human errors. Apparently, those causes may be dependent. For example, one may claim warranty due to the malfunction of the embedded software in a product item and then the entire item may be replaced. Nevertheless, the existing research on warranty management studies mainly concentrates on warranty analysis of hardware subsystems, assuming that the warranty claims are statistically independent of those caused by the failures of software subsystems or human factors, that is, the interactions between those causes are neglected. This paper investigates warranty costs incurred due to those three subsystems with a focus on their interactions. It estimates the costs due to different cause, develops integrated warranty cost models and optimises warranty policies considering the above possible combinations. Numerical examples are given to illustrate the proposed models

Analysis of costs and delivery intervals for multiple-release software

Project managers of large software projects, and particularly those associated with Internet Business-to-Business (B2B) or Business-to-Customer (B2C) applications, are under pressure to capture market share by delivering reliable software with cost and timing constraints. An earlier delivery time may help the E-commerce software capture a larger market share. However, early delivery sometimes means lower quality. In addition, most of the time the scale of the software is so large that incremental multiple releases are warranted. A Multiple-Release methodology has been developed to optimize the most efficient and effective delivery intervals of the various releases of software products, taking into consideration software costs and reliability. The Multiple-Release methodology extends existing software cost and reliability models, meets the needs of large software development firms, and gives a navigation guide to software industrial managers. The main decision factors for the multiple releases include the delivery interval of each release, the market value of the features in the release, and the software costs associated with testing and error penalties. The input of these factors was assessing using Design of Experiments (DOE). The costs included in the research are based on a salary survey of software staff at companies in the New Jersey area and on budgets of software development teams. The Activity Based Cost (ABC) method was used to determine costs on the basis of job functions associated with the development of the software. It is assumed that the error data behavior follows the Non-Homogeneous Poisson Processes (NHPP)

Availability and Reliability Analysis of Computer Software Systems Considering Maintenance and Security Issues

Ph.DDOCTOR OF PHILOSOPH

Predicting Cost/Reliability/Maintainability of Advanced General Aviation Avionics Equipment

A methodology is provided for assisting NASA in estimating the cost, reliability, and maintenance (CRM) requirements for general avionics equipment operating in the 1980's. Practical problems of predicting these factors are examined. The usefulness and short comings of different approaches for modeling coast and reliability estimates are discussed together with special problems caused by the lack of historical data on the cost of maintaining general aviation avionics. Suggestions are offered on how NASA might proceed in assessing cost reliability CRM implications in the absence of reliable generalized predictive models

Reliability models and analyses of the computing systems

Ph.DDOCTOR OF PHILOSOPH

Prognostics-Based Two-Operator Competition for Maintenance and Service Part Logistics

Prognostics and timely maintenance of components are critical to the continuing operation of a system. By implementing prognostics, it is possible for the operator to maintain the system in the right place at the right time. However, the complexity in the real world makes near-zero downtime difficult to achieve partly because of a possible shortage of required service parts. This is realistic and quite important in maintenance practice. To coordinate with a prognostics-based maintenance schedule, the operator must decide when to order service parts and how to compete with other operators who also need the same parts. This research addresses a joint decision-making approach that assists two operators in making proactive maintenance decisions and strategically competing for a service part that both operators rely on for their individual operations. To this end, a maintenance policy involving competition in service part procurement is developed based on the Stackelberg game-theoretic model. Variations of the policy are formulated for three different scenarios and solved via either backward induction or genetic algorithm methods. Unlike the first two scenarios, the possibility for either of the operators being the leader in such competitions is considered in the third scenario. A numerical study on wind turbine operation is provided to demonstrate the use of the joint decision-making approach in maintenance and service part logistics

Vulnerable Software: Product-Risk Norms and the Problem of Unauthorized Access

Unauthorized access to online information costs billions of dollars per year. Software vulnerabilities are a key. Software currently contains an unacceptable number of vulnerabilities. The standard solution notes that the typical software business strategy is to keep costs down and be the first to market even if that means the software has significant vulnerabilities. Many endorse the following remedy: make software developers liable for negligent or defective design. This remedy is unworkable. We offer an alternative based on an appeal to product-risk norms. Product-risk norms are social norms that govern the sale of products. A key feature of such norms is that they ensure that the design and manufacture of products impose only acceptable risks on buyers. Unfortunately, mass-market software sales are not governed by appropriate product-risk norms; as result, market conditions exist in which sellers profitably offer vulnerability-ridden software. This analysis entails a solution: ensure that appropriate norms exist. We contend that the best way to do so is a statute based on best practices for software development, and we define the conditions under which the statute would give rise to the desired norm. Why worry about creating the norm? Why not just legally require that software developers conform to best practices. The answer is that enforcement of legal’s requirement can be difficult, costly, and uncertain; once the norm is in place, however, buyers and software developers conform on their own initiative

Vulnerable Software: Product-Risk Norms and the Problem of Unauthorized Access

Unauthorized access to online information costs billions of dollars per year. Software vulnerabilities are a key. Software currently contains an unacceptable number of vulnerabilities. The standard solution notes that the typical software business strategy is to keep costs down and be the first to market even if that means the software has significant vulnerabilities. Many endorse the following remedy: make software developers liable for negligent or defective design. This remedy is unworkable. We offer an alternative based on an appeal to product-risk norms. Product-risk norms are social norms that govern the sale of products. A key feature of such norms is that they ensure that the design and manufacture of products impose only acceptable risks on buyers. Unfortunately, mass-market software sales are not governed by appropriate product-risk norms; as result, market conditions exist in which sellers profitably offer vulnerability-ridden software. This analysis entails a solution: ensure that appropriate norms exist. We contend that the best way to do so is a statute based on best practices for software development, and we define the conditions under which the statute would give rise to the desired norm. Why worry about creating the norm? Why not just legally require that software developers conform to best practices. The answer is that enforcement of legal’s requirement can be difficult, costly, and uncertain; once the norm is in place, however, buyers and software developers conform on their own initiative

Audio DSP Amplifier

The key concept of this project is to create a microcontroller system that serves as an interface between a DSP board and a total of 4 amplifier channels. The fully integrated system will provide a fully inclusive audio DSP amplifier for use in 2.1 or bi-amplified stereo speaker setups. The project will focus on developing an intuitive interface that is operable from the device or a computer that programs the DSP board for various speaker applications. The finished design will provide a custom computer sound amplifier in one package, eliminating the need for multiple components by interfacing two stereo amplifiers, a DSP unit, and an LCD menu using a microcontroller. This solution will provide a more affordable alternative to the current market solution for creating a DSP enabled, 2.1 sound system. The system will provide higher quality audio with more customization options than current competing market solutions

Architecting Fail-Safe Supply Chains / Networks

Disruptions are large-scale stochastic events that rarely happen but have a major effect on supply networks’ topology. Some examples include: air traffic being suspended due to weather or terrorism, labor unions strike, sanctions imposed or lifted, company mergers, etc. Variations are small-scale stochastic events that frequently happen but only have a trivial effect on the efficiency of flow planning in supply networks. Some examples include: fluctuations in market demands (e.g. demand is always stochastic in competitive markets) and performance of production facilities (e.g. there is not any perfect production system in reality). A fail-safe supply network is one that mitigates the impact of variations and disruptions and provides an acceptable level of service. This is achieved by keeping connectivity in its topology against disruptions (structurally fail-safe) and coordinating the flow through the facilities against variations (operationally fail-safe). In this talk, I will show that to have a structurally fail-safe supply network, its topology should be robust against disruptions by positioning mitigation strategies and be resilient in executing these strategies. Considering “Flexibility” as a risk mitigation strategy, I answer the question “What are the best flexibility levels and flexibility speeds for facilities in structurally fail-safe supply networks?” Also, I will show that to have an operationally fail-safe supply network, its flow dynamics should be reliable against demand- and supply-side variations. In the presence of these variations, I answer the question “What is the most profitable flow dynamics throughout a supply network that is reliable against variations?” The method is verified using data from an engine maker. Findings include: i) there is a tradeoff between robustness and resilience in profit-based supply networks; ii) this tradeoff is more stable in larger supply networks with higher product supply quantities; and iii) supply networks with higher reliability in their flow planning require more flexibilities to be robust. Finally, I will touch upon possible extensions of the work into non-profit relief networks for disaster management