{"title":"计算机软件设计中的失效模式及影响分析","authors":"N. Ozarin","doi":"10.1109/RAMS.2004.1285448","DOIUrl":null,"url":null,"abstract":"Performing FMEA on computer software presents problems and challenges not found in FMEA of electronic hardware. Contractual directions are usually very limited or nonexistent, leaving the analyst to establish and tailor guidelines needed for a particular analysis. Where code is unavailable or off limits to the analysis, the FMEA is of limited usefulness but can still contribute to a more reliable system design. Unfortunately, many reliability analysts have more difficulty developing an approach to software analysis than doing it. An understanding of the software design process and a discussion of various approaches to software design FMEA is presented to make development of an appropriate approach and performance of the analysis itself easier to understand. Moving from the lowest level of analysis to the highest level typically from the method level to the module or package level - a FMEA becomes less accurate, less precise, and less informative, while the process becomes less difficult, less tedious, and less time-consuming. Moving from the lowest level of analysis to the highest also means a FMEA is based increasingly on the stated intent of the software designers and less on the actual product behavior. For any analysis above the code level, the analyst's conclusions about effects at each level is unfortunately be no better than the descriptions that the software designers provide.","PeriodicalId":270494,"journal":{"name":"Annual Symposium Reliability and Maintainability, 2004 - RAMS","volume":"81 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2004-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"25","resultStr":"{\"title\":\"Failure modes and effects analysis during design of computer software\",\"authors\":\"N. Ozarin\",\"doi\":\"10.1109/RAMS.2004.1285448\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Performing FMEA on computer software presents problems and challenges not found in FMEA of electronic hardware. Contractual directions are usually very limited or nonexistent, leaving the analyst to establish and tailor guidelines needed for a particular analysis. Where code is unavailable or off limits to the analysis, the FMEA is of limited usefulness but can still contribute to a more reliable system design. Unfortunately, many reliability analysts have more difficulty developing an approach to software analysis than doing it. An understanding of the software design process and a discussion of various approaches to software design FMEA is presented to make development of an appropriate approach and performance of the analysis itself easier to understand. Moving from the lowest level of analysis to the highest level typically from the method level to the module or package level - a FMEA becomes less accurate, less precise, and less informative, while the process becomes less difficult, less tedious, and less time-consuming. Moving from the lowest level of analysis to the highest also means a FMEA is based increasingly on the stated intent of the software designers and less on the actual product behavior. For any analysis above the code level, the analyst's conclusions about effects at each level is unfortunately be no better than the descriptions that the software designers provide.\",\"PeriodicalId\":270494,\"journal\":{\"name\":\"Annual Symposium Reliability and Maintainability, 2004 - RAMS\",\"volume\":\"81 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2004-08-24\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"25\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Annual Symposium Reliability and Maintainability, 2004 - RAMS\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/RAMS.2004.1285448\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Annual Symposium Reliability and Maintainability, 2004 - RAMS","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/RAMS.2004.1285448","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Failure modes and effects analysis during design of computer software
Performing FMEA on computer software presents problems and challenges not found in FMEA of electronic hardware. Contractual directions are usually very limited or nonexistent, leaving the analyst to establish and tailor guidelines needed for a particular analysis. Where code is unavailable or off limits to the analysis, the FMEA is of limited usefulness but can still contribute to a more reliable system design. Unfortunately, many reliability analysts have more difficulty developing an approach to software analysis than doing it. An understanding of the software design process and a discussion of various approaches to software design FMEA is presented to make development of an appropriate approach and performance of the analysis itself easier to understand. Moving from the lowest level of analysis to the highest level typically from the method level to the module or package level - a FMEA becomes less accurate, less precise, and less informative, while the process becomes less difficult, less tedious, and less time-consuming. Moving from the lowest level of analysis to the highest also means a FMEA is based increasingly on the stated intent of the software designers and less on the actual product behavior. For any analysis above the code level, the analyst's conclusions about effects at each level is unfortunately be no better than the descriptions that the software designers provide.