Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525967
J. Leathrum, K.A. Liburdy
The development of formal test specifications for an open system standard is described. The effort is being conducted within the environment provided by the Clemson Automated Testing System (CATS). CATS features the ability to automatically translate formal test specifications into executable tests. The formal test specifications are written in accordance with a specification language designed in support of this effort. An overview of the CATS architecture and formal test specification language provide a backdrop for an experience report on the development of formal test specifications for IEEE Std 1003.5 POSIX Ada Language Interfaces. A discussion of scale-up issues concludes the paper.
{"title":"Formal test specifications in open systems","authors":"J. Leathrum, K.A. Liburdy","doi":"10.1109/SESS.1995.525967","DOIUrl":"https://doi.org/10.1109/SESS.1995.525967","url":null,"abstract":"The development of formal test specifications for an open system standard is described. The effort is being conducted within the environment provided by the Clemson Automated Testing System (CATS). CATS features the ability to automatically translate formal test specifications into executable tests. The formal test specifications are written in accordance with a specification language designed in support of this effort. An overview of the CATS architecture and formal test specification language provide a backdrop for an experience report on the development of formal test specifications for IEEE Std 1003.5 POSIX Ada Language Interfaces. A discussion of scale-up issues concludes the paper.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114055813","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525960
P. Joannou, J. Harauz
There currently exists a plethora of standards for software engineering, with IEEE having the most comprehensive set. Despite the abundance of standards, Ontario Hydro and Atomic Energy Canada Ltd (AECL) found that the existing standards did not meet our needs and hence undertook to write our own standards for software engineering. This paper outlines our requirements for standards for software engineering, assesses existing standards against them and describes the framework of standards that was developed by Ontario Hydro and AECL to meet our requirements.
{"title":"Ontario Hydro/AECL standards for software engineering deficiencies in existing standards that created their need","authors":"P. Joannou, J. Harauz","doi":"10.1109/SESS.1995.525960","DOIUrl":"https://doi.org/10.1109/SESS.1995.525960","url":null,"abstract":"There currently exists a plethora of standards for software engineering, with IEEE having the most comprehensive set. Despite the abundance of standards, Ontario Hydro and Atomic Energy Canada Ltd (AECL) found that the existing standards did not meet our needs and hence undertook to write our own standards for software engineering. This paper outlines our requirements for standards for software engineering, assesses existing standards against them and describes the framework of standards that was developed by Ontario Hydro and AECL to meet our requirements.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115077949","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525959
J. Voas, K. Miller
Standards for quality software are increasingly important, especially for critical systems. Development standards and practices must be subjected to quantitative analyses; it is no longer adequate to encourage practices because they "make sense" or "seem reasonable." Process improvement must be demonstrated by a history of improved products. Fault-injection methods can be used to assess the quality of software itself and to demonstrate the effectiveness of software processes. Fault-injection techniques can help developers move beyond the practical limitations of testing. Fault-injection techniques focus on software behavior, not structure; process-oriented techniques cannot measure behavior as precisely. Fault-injection methods are dynamic, empirical, and tractable; as such, they belie the notion that measuring the reliability of critical software is futile. Before focusing too narrowly on the assessment of software development processes, we should further explore the measurement of software behaviors.
{"title":"Using fault injection to assess software engineering standards","authors":"J. Voas, K. Miller","doi":"10.1109/SESS.1995.525959","DOIUrl":"https://doi.org/10.1109/SESS.1995.525959","url":null,"abstract":"Standards for quality software are increasingly important, especially for critical systems. Development standards and practices must be subjected to quantitative analyses; it is no longer adequate to encourage practices because they \"make sense\" or \"seem reasonable.\" Process improvement must be demonstrated by a history of improved products. Fault-injection methods can be used to assess the quality of software itself and to demonstrate the effectiveness of software processes. Fault-injection techniques can help developers move beyond the practical limitations of testing. Fault-injection techniques focus on software behavior, not structure; process-oriented techniques cannot measure behavior as precisely. Fault-injection methods are dynamic, empirical, and tractable; as such, they belie the notion that measuring the reliability of critical software is futile. Before focusing too narrowly on the assessment of software development processes, we should further explore the measurement of software behaviors.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124339593","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525975
Silas F. Rahhal, N. Madhavji
A major concern for organizations who are seeking registration to ISO 9000, or seeking the implementation of any quality related process, is the ability to estimate the work/effort required for meeting the stated requirements. This is an a priori requirement in corporate decision making, regardless of the maturity level of the organization (W.S. Humphrey, 1989), the current state of the quality system, or the extent to which the organization complies to the requirements of the ISO 9000 standard. The paper presents a statistical regression model that predicts the effort required for meeting the requirements of ISO 9001. We carried out a survey in February 1995, which was sent to 1190 organizations in North America. We had a 38.8% response (462 responses). The effort estimation model we present is for ISO 9001 (all industries), and is based on the 112 responses we had from ISO 9001 registered organizations. Subsequent models for ISO 9001 (software), ISO 9002 and ISO 9003 are being built using the remaining data.
{"title":"An effort estimation model for implementing ISO 9001","authors":"Silas F. Rahhal, N. Madhavji","doi":"10.1109/SESS.1995.525975","DOIUrl":"https://doi.org/10.1109/SESS.1995.525975","url":null,"abstract":"A major concern for organizations who are seeking registration to ISO 9000, or seeking the implementation of any quality related process, is the ability to estimate the work/effort required for meeting the stated requirements. This is an a priori requirement in corporate decision making, regardless of the maturity level of the organization (W.S. Humphrey, 1989), the current state of the quality system, or the extent to which the organization complies to the requirements of the ISO 9000 standard. The paper presents a statistical regression model that predicts the effort required for meeting the requirements of ISO 9001. We carried out a survey in February 1995, which was sent to 1190 organizations in North America. We had a 38.8% response (462 responses). The effort estimation model we present is for ISO 9001 (all industries), and is based on the 112 responses we had from ISO 9001 registered organizations. Subsequent models for ISO 9001 (software), ISO 9002 and ISO 9003 are being built using the remaining data.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132675285","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525972
T. Natsume
It is well known that there are two groups for the international software standardization body in the area of quality and dependability, that is ISO/SC2/TC176/WG5 Quality system and quality management for software application and IEC/TC56/WG10 Software Aspects for Dependability. WG 5 developed ISO 9000-3 as a complementary document for ISO 9001 in 1991. However this is not perfectly acceptable for the worldwide industry due to its narrow applications. WG10 is still developing the dependability area guidelines which address the barriers to development such as rapid progress of software industries, system aspects, limitation of application for various software products, rapid change from industrial fundamental innovation and traditional industry for product views. Here current software industrial progress and issues for international standardization by such technical and industrial environment are discussed to help seek common understanding and mutual recognition and to try to offer some proposals for the issues raised. The discussions in the paper are based on the author's experience through the service as a national committee member of IEC/TC56 and WG10, and also ISO/SC2/TC176 and WG15 (Japanese WG to WC5).
{"title":"Issues of software standardization in the industrial area of quality and dependability","authors":"T. Natsume","doi":"10.1109/SESS.1995.525972","DOIUrl":"https://doi.org/10.1109/SESS.1995.525972","url":null,"abstract":"It is well known that there are two groups for the international software standardization body in the area of quality and dependability, that is ISO/SC2/TC176/WG5 Quality system and quality management for software application and IEC/TC56/WG10 Software Aspects for Dependability. WG 5 developed ISO 9000-3 as a complementary document for ISO 9001 in 1991. However this is not perfectly acceptable for the worldwide industry due to its narrow applications. WG10 is still developing the dependability area guidelines which address the barriers to development such as rapid progress of software industries, system aspects, limitation of application for various software products, rapid change from industrial fundamental innovation and traditional industry for product views. Here current software industrial progress and issues for international standardization by such technical and industrial environment are discussed to help seek common understanding and mutual recognition and to try to offer some proposals for the issues raised. The discussions in the paper are based on the author's experience through the service as a national committee member of IEC/TC56 and WG10, and also ISO/SC2/TC176 and WG15 (Japanese WG to WC5).","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"30 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115078035","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525945
J. R. Matras
The Department of Defence has identified the need to analyze safety systems to eliminate or reduce the associated risk of personnel injury, equipment damage, and environmental damage; Mil-Std-882B, "System Safety Program Requirements" was developed to guide this analysis. The IEEE Computer Society further realized that when software was part of the safety system design software specific additional requirements to Mil-Std-882B were required. The IEEE Computer Society developed IEEE Std 1228, "IEEE Software Safety Plans", which addresses the planning of the management and technical aspects of the safety system software development process to identify, hazards associated with the software design. The nuclear industry, relying on the techniques identified in the above standards, felt a need for the analysis of abnormal conditions and events (ACE) when a digital computer is used in the design of safety systems in nuclear power plants. The paper identifies the requirements for performing an ACE analysis during or after completion of a computer system design and the methodologies that could be used when preforming the analysis.
{"title":"Requirements for abnormal conditions and events analysis","authors":"J. R. Matras","doi":"10.1109/SESS.1995.525945","DOIUrl":"https://doi.org/10.1109/SESS.1995.525945","url":null,"abstract":"The Department of Defence has identified the need to analyze safety systems to eliminate or reduce the associated risk of personnel injury, equipment damage, and environmental damage; Mil-Std-882B, \"System Safety Program Requirements\" was developed to guide this analysis. The IEEE Computer Society further realized that when software was part of the safety system design software specific additional requirements to Mil-Std-882B were required. The IEEE Computer Society developed IEEE Std 1228, \"IEEE Software Safety Plans\", which addresses the planning of the management and technical aspects of the safety system software development process to identify, hazards associated with the software design. The nuclear industry, relying on the techniques identified in the above standards, felt a need for the analysis of abnormal conditions and events (ACE) when a digital computer is used in the design of safety systems in nuclear power plants. The paper identifies the requirements for performing an ACE analysis during or after completion of a computer system design and the methodologies that could be used when preforming the analysis.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125769211","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525969
H. Hecht
The article describes requirements for and implementation of an error classification methodology for high integrity systems. It is largely based on a software error classification scheme recommended for nuclear power safety systems. The emphasis is on the purposes of the classification, the required data, and their logical ordering. There is no intention to propose a specific data format or database management system. Nevertheless, it is very convenient to adopt the terminology of a generic database manager.
{"title":"A proposal for standardized software dependability data","authors":"H. Hecht","doi":"10.1109/SESS.1995.525969","DOIUrl":"https://doi.org/10.1109/SESS.1995.525969","url":null,"abstract":"The article describes requirements for and implementation of an error classification methodology for high integrity systems. It is largely based on a software error classification scheme recommended for nuclear power safety systems. The emphasis is on the purposes of the classification, the required data, and their logical ordering. There is no intention to propose a specific data format or database management system. Nevertheless, it is very convenient to adopt the terminology of a generic database manager.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130473002","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525968
S. Minami, T. Suganuma, T. Miyazaki
NTT has developed a set of specifications called Multivendor Integration Architecture (MIA) for open systems codeveloped with vendors, etc. NTT then implemented conformance testing for MIA products, and is now using it's results for procurement. We evaluate the results of this implemented MIA conformance testing. The proportion of nonconformances detected by test programs when tests were run as an integral part of the debugging process, was eight times as great as the proportion detected when testing was done after debugging had been completed. On the basis of these results, it is important to make it easy for the vendors to use the test programs as one of the debugging tools in order to promote their efficient use, and therefore we mention some further requirements that would be desirable to help make this happen.
{"title":"An evaluation of MIA conformance tests","authors":"S. Minami, T. Suganuma, T. Miyazaki","doi":"10.1109/SESS.1995.525968","DOIUrl":"https://doi.org/10.1109/SESS.1995.525968","url":null,"abstract":"NTT has developed a set of specifications called Multivendor Integration Architecture (MIA) for open systems codeveloped with vendors, etc. NTT then implemented conformance testing for MIA products, and is now using it's results for procurement. We evaluate the results of this implemented MIA conformance testing. The proportion of nonconformances detected by test programs when tests were run as an integral part of the debugging process, was eight times as great as the proportion detected when testing was done after debugging had been completed. On the basis of these results, it is important to make it easy for the vendors to use the test programs as one of the debugging tools in order to promote their efficient use, and therefore we mention some further requirements that would be desirable to help make this happen.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"18 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131778085","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525958
F. Mazzanti
This paper presents some limits and irregularities in current standards for safety critical software development, and suggests ways to improve the state of the art. The need for well organized, rigorous and verifiable coding regulations to promote the development of software with predictable quality and safety characteristics is explained. We show specific examples of weaknesses in standards and make proposals for improvement.
{"title":"Coding regulations for safety critical software development","authors":"F. Mazzanti","doi":"10.1109/SESS.1995.525958","DOIUrl":"https://doi.org/10.1109/SESS.1995.525958","url":null,"abstract":"This paper presents some limits and irregularities in current standards for safety critical software development, and suggests ways to improve the state of the art. The need for well organized, rigorous and verifiable coding regulations to promote the development of software with predictable quality and safety characteristics is explained. We show specific examples of weaknesses in standards and make proposals for improvement.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130605544","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1995-08-21DOI: 10.1109/SESS.1995.525957
N. Thuy, F. Ficheux-Vapne
This paper presents an outline of the work currently done at Electricite de France for the identification of requirements applicable to software in category, B (as defined by publication 1226 of the IEC) systems. The first part presents an analysis of the weaknesses of publication 880 of the IEC, an existing and related standard expressing requirements applicable to software in category A systems. Based on this feedback of experience, the second part identifies some general recommendations and guidelines that should be followed for the establishment of requirements in a standard for software. The third part presents the main technical objectives that can be proposed for software in category B systems. These technical objectives are all derived from a unique primacy objective: safety integrity, i.e., the likelihood of software to achieve its safety functions under all stated conditions within a stated period of time.
{"title":"IEC 880: feedback of experience and guidelines for future work","authors":"N. Thuy, F. Ficheux-Vapne","doi":"10.1109/SESS.1995.525957","DOIUrl":"https://doi.org/10.1109/SESS.1995.525957","url":null,"abstract":"This paper presents an outline of the work currently done at Electricite de France for the identification of requirements applicable to software in category, B (as defined by publication 1226 of the IEC) systems. The first part presents an analysis of the weaknesses of publication 880 of the IEC, an existing and related standard expressing requirements applicable to software in category A systems. Based on this feedback of experience, the second part identifies some general recommendations and guidelines that should be followed for the establishment of requirements in a standard for software. The third part presents the main technical objectives that can be proposed for software in category B systems. These technical objectives are all derived from a unique primacy objective: safety integrity, i.e., the likelihood of software to achieve its safety functions under all stated conditions within a stated period of time.","PeriodicalId":178570,"journal":{"name":"Proceedings of Software Engineering Standards Symposium","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121254310","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：