A of Japanese Car Manufacturer - Case Study Example

Part Toyota Prius Hybrid Software Glitch Introduction Software reliability is a major consideration, by every developer, for the success of any software. Any software has to be able to perform its intended purpose accurately and consistently over its intended period and environment of use. A software failure can result to very expensive errors or huge losses. In cases where software operates as part of a larger system, it partially determines the reliability of the entire system. Its failure can cause malfunction of the entire system and subsequently huge losses. Causes of software failure can vary from bugs, design flaws, ambiguities or even human errors from the software users. Software quality-related failures can be classified into errors, defects and failures. Errors commonly originate from mistakes made by the programmers while coding the software while defects are commonly from bugs incorporated in the software at the coding stage. Failures commonly occur during software execution where the hardware executes a program and gives a feedback that is not compatible with the program (ISTQB Exam Certification, 2015). All the aforementioned errors can be eliminated or prevented during the software development process. It is very important for any software to go through the quality tests to ensure its reliability and prevent massive losses in the future of its use. This paper is going to cover a case of Japanese car manufacturer, Toyota, where the company incurred huge losses as a result of a software glitch in its Toyota Prius Hybrid vehicle. This paper will look deeper into the case and determine how the software problem was discovered and to what extent the company and its customers were affected. It will also look into the actions taken by Toyota, Japan and the improvements that were made later to prevent the recurrence of such software glitches. How it manifested itself The Toyota Prius model has experienced three major recalls since the beginning of its production. The Toyota Prius is a hybrid vehicle and thus it has lots of electric systems. Most of these electric systems are automated and thus use various software programs for proper and efficient functioning. The programs used in such systems mostly involve numerous lines of code which increases the chances of bugs, errors, defects or even software failure. Two of the three major recalls for Toyota’s Prius model were software quality related. The first software related recall was in 2010, a year after commencement of Prius production. This was as a result of software glitch in the vehicle’s anti-lock braking system. About three hundred and ninety seven thousand Prius Hybrid vehicles were recalled to fix the software glitch. The error was discovered by some drivers in the United Kingdom who reported four crashes as a result of anti-lock braking system failure. Concerns about the faulty system were forwarded to the National Highways and Transportation and Safety Authority which later contacted Toyota over the same. Upon investigation of the production systems used for the Prius, Toyota acknowledged that there was an error and initiated a costly worldwide recall of all the Prius vehicles with the problem. The glitch occurred as a result of an inconsistency between the anti-lock braking system and the regenerative braking system (British Broadcasting Corporation, 2010). The second recall of the Prius hybrid vehicle model involved the third generation model. There was faulty software that was critical for the operation of the hybrid engine. This recall happened in 2014 and about 1.9 million third generation Prius hybrid vehicles were recalled to fix the software flaw. Quality Attributes Affected In the 2010 recall over anti-lock braking system, Toyota acknowledged that the braking system was not as responsive as it should have been. According to the NHTSA investigation, the responsiveness of the software was faulty and thus resulted to increased braking distance. Software accuracy and compatibility attributes were affected by these faults. In instances where a driver would have considered it necessary to apply emergency brakes, the vehicle took long to respond. In a statement by Toyota spokesperson, the vehicle manufacturer argued that though the braking system might have been taking a longer time to respond, it eventually responded and the vehicle would come to a stop (Toyota House, United States, 2012). In this case the fault was not in the software itself as the software still carried out the braking function that it was designed to perform. However, the faulty braking system was a result of incompatibility with the rest of the regenerative braking. An analysis of this system would indicate that the software attribute of compatibility with other software and hardware had not been fully achieved. The software’s effectiveness was also compromised by its operating environment. This is true upon an evaluation of its compatibility with the rest of the system. It is important to note that the software failure presented itself as a glitch as it would occur periodically and not all the Prius vehicles produced by then had experienced the problem. In the 2014 recall that involved about 1.9 vehicles, the affected attributes were performance, reliability, safety, dependability precision and compatibility. The software involved was used in the hybrid engine’s systems and it was used to operate boost converters for the engine. Errors in the software would cause malfunctioning of electric circuits and transistors in the injection system. This would result to overheating of the electric components in the gasoline-electric hybrid engine. According to how the hybrid system was designed to work, such a scenario could easily cause the vehicle to stall. The first indicator of this scenario would be a warning light located on the vehicle’s dashboard. Once this light switches on, the vehicle would automatically get into a pre-programmed mode called “limp home mode”. This was designed as a kind of a fail-safe mode. Once the vehicle got into this mode, it would automatically slow down to a minimal speed and sometimes it would shut down at any point on the road. However, Toyota claimed that the hybrid engine system would rarely shut down completely. Magnitude of the Loss Similar to many other software applications, the program that experienced glitches in the Toyota Prius model were used for critical functions in the vehicle. Failures in such programs could have serious implications just like it happened in the two recall cases under focus. In the United States of America alone, Toyota was faced with one hundred and twenty two lawsuits by owners of Prius hybrid vehicles over the hybrid system software malfunction. There were also hundreds of other lawsuits in other countries where Toyota had been sued for varying reasons. Some of these reasons were selling a defective product that compromised the safety of the buyers, inconveniences caused by the recall and several near miss incidents. There were several claims that the software glitches had caused accident that had resulted to loss of lives. After investigations by the NHTSA and other safety authorities in other reported countries it was discovered that there were accidents involving the Prius model but the accidents had not been caused by glitches in the ABS and hybrid control software. Complaints were lodged to the justice department over how the recall was handled. Some customers claimed that the automaker did not properly communicate about the recall and did not fully disclose the reasons for the recall. The Japanese vehicle manufacturer was hit with heavy fines, worth millions of dollars, as compensation for the affected drivers. Toyota put in efforts to make out of court settlements for the lawsuits. According to BBC news, Toyota was fined sixteen million dollars in the United States over the recall of its vehicles. Toyota Motor Corporation’s image and reputation were also affected by the recall. There had been other recall by the same vehicle manufacturer and so customers and business analyst were worried of the trend. The recall coupled with the global economic situation had a denting effect on Toyota’s reputation. As at the time of these recalls, Toyota had already placed itself as the global leader in production of environmental friendly and top passenger safety vehicles. Among the other alternative energy vehicles, which include the Chevrolet Plug-In and the Nissan Leaf, Toyota’s Prius model had by far proved to be the most successful in the sub-industry. However, cases of software failures in its green model cast aspersions as to the safety of the vehicles. Cases touching on consumer safety and product liability are usually very sensitive and commonly make international headlines. Lack of a wide variety of alternatives for this model made the recall to be big news that attracted a lot of attention even from players in different industries such as the finance industry. There was significant market loss as a result of the Toyota recall. It was estimated at around two billion dollars lost in sales and costs incurred during the recalls (British Broadcasting Corporation, 2010). According to BBC, the lost trust and damaged reputation saw the company’s profits dip and the company got into a crisis that saw some of the top executives lose their positions. More research into the effects of the recalls on Toyota’s reputation reveals that the damage on reputation was positively related to its volume of sales. As at the time of the recalls, the auto manufacturer had sold millions of units worldwide and had recorded the highest number of vehicles sold per model. This can be interpreted to mean that a defect in software functioning will be as widespread as the manufacturer’s model are. The moment news about a software malfunction in one of the models spreads in the global motor vehicle industry; sales of other models will also be negatively affected. Further complicating the matters of damaged reputation are business commentators and analysts who give opinions that shape the industry. Negative publicity by the media only served to damage the consumers’ trust to the company. During the second recall of the third generation Prius hybrid, competitor companies commenced offering rebates on their vehicle models. This served to worsen Toyota market as competitor took advantage of the situation to capture part of Toyota’s large market (Deutsche Welle, 2014). Measures Taken to Rectify the Problem After investigation by the NHTSA and Toyota Motor Corporation, the immediate response was a recall of all the Toyota Prius vehicles that were manufactured in the period from year 2009 to year 2011. Almost all of the vehicle owners complied with the recall. In the first major recall that involved anti-lock braking system software failure, about three hundred and ninety seven thousand vehicles were recalled. The corrective action involved re-installing an improved version of the software. Toyota Motor Corporation developed the anti-lock braking system in its headquarters in Japan and distributed the software to all its service centres worldwide. Owners of the Prius vehicles would drive to these service centres and their vehicles they would have the former program pulled down and the new version installed. The software glitch that affected the hybrid engine system was treated as urgent as the problem affected some of the most critical components of the Prius vehicle model. It is important to note that this recall was voluntary and it was a proactive measure by Toyota since there had been no reported accident as at the time of the recall. Upon completion of investigation by the National Highway Transport and Safety Authority and Toyota Motor Corporation, there was a recall of all third-generation Toyota Prius hybrid models. The corrective measure involved an upgrade of the software controlling gasoline-electric engine system. According to a statement by Toyota spokesperson, this upgrade would take just about forty to fifty minutes. There were instances where the software update would present some unique difficulties. In such instances, the vehicles were fitted with a control module that would control the hybrid system but not as effectively as the previously installed software. In regions where Toyota did not have service centre, the owners would have their vehicles shipped to the nearest countries with Toyota service centres. Improvements Implemented Afterwards Immediately after the recall Toyota directed some of its resources towards establishing the problems in the software that were involved. The first step involved upgrading the anti-lock braking system that was being used for the vehicles being manufactured at that time. This would ensure no more vehicles would be released by the manufacturer with the said defects. Toyota Motor Corporation had to effect some changes from the Toyota Production System (TPS). Since Toyota Motor Corporation uses KAIZEN, engineers, programmers and other staffs were involved in making changes. Programmers created software updates and debugged the existing software. Part 2: Address book Program Using a weighting scale of; 1-Simple, 2-Average, 3-Complex, then the unadjusted function point is 22*1 +60*2 + 42*3 = 268 Factor Description Weight T1 Response Adjectives 1 T2 End user efficiency 1 T3 Complex Processing 1 T4 Reusable code 1 T5 Easy to Install 1 T6 Easy to Use 2 T7 Portable 2 T8 Easy to change 2 T9 Concurrent 1 T10 Access for third party 1 T11 Special training required 1 The technical components are as indicated T1 to T11. T1 component measures the address book program’s ability to recognize adjectives that are used by both the programmer and the end user form the end user interface. End user efficiency is a component that measures the level of interaction between the user and the address book program. The third technical component is complex processing. This component gives a measure of the address book program’s ability to accept complex instructions as well as give complex outputs to the users. This component is very important as it determines, to a large extent, the program’s abilities and reliability as the more complex a program is the more chances there are that a glitch might occur. The next component is reusable code. This determines the programs ability to be replicated and used in environment with different systems. The next technical component is the program’s ease of installation. The address book program in this case should be easy to install as it a program that is used widely. This component measures the possibility that it can be installed by a semi-skilled user and then the user proceeds to use it in any system that is locally available. The next component is the program’s ease of use. This component measures the level to which the program can be used by different users. Aspects that are considered in this component include the program’s user interface, inputs and outputs. An address with a high score in this measure commonly has a user-guiding interface that makes its operation by the user very easy and quick (Developer Shed Network, 2004). Portability is a component that measures the address book program’s ability to be used in different hardware components in a system (John Wiley and Sons, 2002). Ease of change component is a measure that gives the programs flexibility and ability to adapt to system changes. Access by third party measures the program’s restrictions and security. Special training is a component that determines whether users of the address book program will require special user training in order to use the program (Banerjee, 2001). TCF=  (Factor value* weight) TCF= 87 Function Point= Unadjusted Function Point* Value Adjustment Factor FP= 268* 0.65=174 Program development duration= 0.65* number of functions* days per function Duration=0.65 * 6*2= 7.8 days (Alexander, 2004) In the case of an address book program, the function point method is an appropriate value estimation method. This is because it gives the value of the program based on what the program is capable of doing rather than its size. Function point analysis method has got several advantages. Function point analysis gives function measurements from a user’s perspective. This is important especially for programs meant for commercial purposes. Function point method fairly independent of the existing technology. Throughout this method there is a consistent link to functionality and finally it has comparatively better defined rules of enumeration. Function point method also has some disadvantages. In order for counters to be effective, they must be trained adequately. It is a method that requires a lot of information. Some of the required information might not be available at the beginning of the program project. Finally, since it is a method that uses the user perspective, there has to be adequate user information to ensure an accurate count (Galorath, 2006). Works Cited Alexander, A. (2004). How to Determine Your Application Size Using Function Points. Retrieved March 30, 2015, from Embarcadero Technologies Inc. Website: http://conferences.embarcadero.com/article/32094 Al-Badareen, A. B., Selamat, M. H., Jabar, M. A., Din, J., & Turaev, S. (2010, November). Reusable software components framework. In European Conference of Computer Science (ECCS 2011) (pp. 126-130). Al-Qutaish, R. E. (2010). Quality models in software engineering literature: an analytical and comparative study. Journal of American Science, 6(3), 166-175. Banerjee, G. (2001). Use of Case Points- Etimates aPPROACH. London: MSN. Betts, B. (2010). Recall and reboot. Engineering & Technology, 5(4), 54-55. Black, R., & Mitchell, J. L. (2011). Advanced Software Testing-Vol. 3: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst. Rocky Nook, Inc.. British Broadcasting Corporation. (2010, February 4). Toyotas reputation could be tarnished for years. Retrieved March 28, 2015, from http://news.bbc.co.uk/2/hi/business/8498036.stm British Broadcasting Corporation. (2010, February 4). US to probe Toyota Prius brake problems. Retrieved March 27, 2014, from http://news.bbc.co.uk/2/hi/business/8497471.stm Burrows, R., Ferrari, F. C., Garcia, A., & Taïani, F. (2010, May). An empirical evaluation of coupling metrics on aspect-oriented programs. In Proceedings of the 2010 ICSE Workshop on Emerging Trends in Software Metrics (pp. 53-58). ACM Cameron, L., & Watson, T. (2010). The truth about Toyota. Canadian Business, 83(6), 28-31. Chopra, K., Sachdeva, M., & Dhawan, S. Classification of Software Projects Based on Software Metrics: A Review. Cole, R. E. (2011). What really happened to Toyota. MIT Sloan Management Review, 52(4), 29-35. Deutsche Welle. (2014). Retrieved March 28, 2015, from http://www.dw.de/japanese-carmaker-toyota-announces-recall-of-19-million-prius-hybrid-cars/a-17425647 Developer Shed Network. (2004, June 2). An Overview of Function Point Analysis. Retrieved March 30, 2015, from Developer Shed Network Website: http://www.devshed.com/c/a/practices/an-overview-of-function-point-analysis/ Fenton, N., & Bieman, J. (2014). Software metrics: a rigorous and practical approach. CRC Press. Fitsilis, P., Kameas, A., & Anthopoulos, L. (2011). Classification of Software Projects’ Complexity. In Information Systems Development (pp. 149-159). Springer New York. Galorath, D. (2006). Software Sizing, Estimation, and Risk Management. London: CRC Press. Gillies, A. (2011). Software quality: theory and management. Lulu. com. Hegde, R., Mishra, G., & Gurumurthy, K. S. (2011). An insight into the hardware and software complexity of ecus in vehicles. In Advances in Computing and Information Technology (pp. 99-106). Springer Berlin Heidelberg. ISTQB Exam Certification. (2015). What is a Failure in software testing? Retrieved March 26, 2015, from ISTQB Exam Certification Website: http://istqbexamcertification.com/what-is-a-failure-in-software-testing/ John Wiley and Sons. (2002). Function Point Analysis. Retrieved March 30, 2015, from John Willey and Sons Website: http://onlinelibrary.wiley.com/doi/10.1002/0471028959.sof137/abstract;jsessionid=65FC0B1B603E754065513A6F92BB8FBA.f01t02 Jones, C., & Bonsignour, O. (2011). The economics of software quality. Addison-Wesley Professional. Keshavarz, G., Modiri, N., & Pedram, M. (2011). Metric for Early Measurement of Software Complexity. Interfaces, 5(10), 15. Liker, J. K., & Ogden, T. (2011). Toyota under fire. McGraw-Hill Professional. Mala, M., & Çil, I. (2011, July). A taxonomy for measuring complexity in agent-based systems. In Software Engineering and Service Science (ICSESS), 2011 IEEE 2nd International Conference on (pp. 851-854). IEEE. Merkow, M. S., & Raghavan, L. (2010). Secure and resilient software development. CRC Press. Naik, K., & Tripathy, P. (2011). Software testing and quality assurance: theory and practice. John Wiley & Sons. Pohl, K. (2010). Requirements engineering: fundamentals, principles, and techniques. Springer Publishing Company, Incorporated. Toyota House, United States. (2012). Toyota Case Study. Retrieved March 27, 2015, from Reseacrh Works Website: https://deresearchworks.files.wordpress.com/.../toyota-case-study1.pdf Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer Science & Business Media. Ye, Y. (2011). Interior point algorithms: theory and analysis (Vol. 44). John Wiley & Sons. Read More