{"title":"量化软件的可靠性和准备情况","authors":"A. Asthana, J. Olivieri","doi":"10.1109/CQR.2009.5137352","DOIUrl":null,"url":null,"abstract":"As the industry moves to more mature software processes (e.g., CMMI) there is increased need to adopt more rigorous, sophisticated (i.e., quantitative) metrics. While quantitative product readiness criteria are often used for business cases and related areas, software readiness is often assessed more subjectively & qualitatively. Quite often there is no explicit linkage to original performance and reliability requirements for the software. The criteria are primarily process-oriented (versus product oriented) and/or subjective. Such an approach to deciding software readiness increases the risk of poor field performance and unhappy customers. Unfortunately, creating meaningful and useful quantitative in-process metrics for software development has been notoriously difficult.","PeriodicalId":186033,"journal":{"name":"2009 IEEE International Workshop Technical Committee on Communications Quality and Reliability","volume":"19 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2009-05-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"44","resultStr":"{\"title\":\"Quantifying software reliability and readiness\",\"authors\":\"A. Asthana, J. Olivieri\",\"doi\":\"10.1109/CQR.2009.5137352\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"As the industry moves to more mature software processes (e.g., CMMI) there is increased need to adopt more rigorous, sophisticated (i.e., quantitative) metrics. While quantitative product readiness criteria are often used for business cases and related areas, software readiness is often assessed more subjectively & qualitatively. Quite often there is no explicit linkage to original performance and reliability requirements for the software. The criteria are primarily process-oriented (versus product oriented) and/or subjective. Such an approach to deciding software readiness increases the risk of poor field performance and unhappy customers. Unfortunately, creating meaningful and useful quantitative in-process metrics for software development has been notoriously difficult.\",\"PeriodicalId\":186033,\"journal\":{\"name\":\"2009 IEEE International Workshop Technical Committee on Communications Quality and Reliability\",\"volume\":\"19 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2009-05-12\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"44\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2009 IEEE International Workshop Technical Committee on Communications Quality and Reliability\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/CQR.2009.5137352\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2009 IEEE International Workshop Technical Committee on Communications Quality and Reliability","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/CQR.2009.5137352","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
As the industry moves to more mature software processes (e.g., CMMI) there is increased need to adopt more rigorous, sophisticated (i.e., quantitative) metrics. While quantitative product readiness criteria are often used for business cases and related areas, software readiness is often assessed more subjectively & qualitatively. Quite often there is no explicit linkage to original performance and reliability requirements for the software. The criteria are primarily process-oriented (versus product oriented) and/or subjective. Such an approach to deciding software readiness increases the risk of poor field performance and unhappy customers. Unfortunately, creating meaningful and useful quantitative in-process metrics for software development has been notoriously difficult.