Pub Date : 1994-05-21DOI: 10.1109/ICSE.1994.296788
W. Tracz
In ACM Software Engineering Notices, vol. 13, no. 1, pp. 17-21 (1988), the author published the paper "Software reuse myths". This paper comments on these "myths" in the light of recent technology advances: (1) software reuse is a technical problem; (2) special tools are needed for software reuse; (3) reusing code results in huge increases in productivity; (4) artificial intelligence will solve the reuse problem; (5) the Japanese have solved the reuse problem; (6) Ada has solved the reuse problem; (7) designing software from reusable parts is like designing hardware using integrated circuits; (8) reused software is the same as reusable software; and (9) software reuse will just happen.<>
{"title":"Software reuse myths revisited","authors":"W. Tracz","doi":"10.1109/ICSE.1994.296788","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296788","url":null,"abstract":"In ACM Software Engineering Notices, vol. 13, no. 1, pp. 17-21 (1988), the author published the paper \"Software reuse myths\". This paper comments on these \"myths\" in the light of recent technology advances: (1) software reuse is a technical problem; (2) special tools are needed for software reuse; (3) reusing code results in huge increases in productivity; (4) artificial intelligence will solve the reuse problem; (5) the Japanese have solved the reuse problem; (6) Ada has solved the reuse problem; (7) designing software from reusable parts is like designing hardware using integrated circuits; (8) reused software is the same as reusable software; and (9) software reuse will just happen.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"63 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115533541","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 : 1994-05-21DOI: 10.1109/ICSE.1994.672729
B. Curtis
The fundamentals of software engineering lie in establishing and controlling a process that gives engineers time to execute their skills and allows them to maintain project coordination. When these fundamentals are weak software development resembles thrashing, with the customer receiving the worst of it. Tools and design methods were not designed to solve these problems. Without a fundamentally sound process to protect their use, advanced technologies will have little chance to score impressively. People in crisis rarely use their tools well. The Software Engineering Institute's Capability Maturity Model for Software was designed to help establish sound fundamentals for building software. Its initial focus is on strengthening the project management and organizational deficiencies that so often confound good software developers.
{"title":"A process for hitting paydirt","authors":"B. Curtis","doi":"10.1109/ICSE.1994.672729","DOIUrl":"https://doi.org/10.1109/ICSE.1994.672729","url":null,"abstract":"The fundamentals of software engineering lie in establishing and controlling a process that gives engineers time to execute their skills and allows them to maintain project coordination. When these fundamentals are weak software development resembles thrashing, with the customer receiving the worst of it. Tools and design methods were not designed to solve these problems. Without a fundamentally sound process to protect their use, advanced technologies will have little chance to score impressively. People in crisis rarely use their tools well. The Software Engineering Institute's Capability Maturity Model for Software was designed to help establish sound fundamentals for building software. Its initial focus is on strengthening the project management and organizational deficiencies that so often confound good software developers.","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125321822","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 : 1994-05-21DOI: 10.1109/ICSE.1994.672727
S. Fickas, P. Selfridge
Are requirements modeling languages, because of their subject matter, fundamentally different from programming and specification languages whose subject matter (software systems) is man-made, bounded and objectively known? As such, do designers of requirements modeling languages need to turn to research in areas other than core computer systems and programming languages (areas such as knowledge representation), in search of ideas and research results that can serve as basis for the design of their languages?
{"title":"software engineering and artificial intelligence","authors":"S. Fickas, P. Selfridge","doi":"10.1109/ICSE.1994.672727","DOIUrl":"https://doi.org/10.1109/ICSE.1994.672727","url":null,"abstract":"Are requirements modeling languages, because of their subject matter, fundamentally different from programming and specification languages whose subject matter (software systems) is man-made, bounded and objectively known? As such, do designers of requirements modeling languages need to turn to research in areas other than core computer systems and programming languages (areas such as knowledge representation), in search of ideas and research results that can serve as basis for the design of their languages?","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"83 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124586233","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296786
V. Basili
Discusses the three most important facts or myths affecting reuse. There is a great deal of misunderstanding about reuse in the software domain and it is difficult to pick out only three: there has been to much emphasis on the reuse of code; software reuse implies some form of modification of the artifact being reused; and software development processes do not explicitly support reuse, in fact they implicitly inhibit reuse.<>
{"title":"Facts and myths affecting software reuse","authors":"V. Basili","doi":"10.1109/ICSE.1994.296786","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296786","url":null,"abstract":"Discusses the three most important facts or myths affecting reuse. There is a great deal of misunderstanding about reuse in the software domain and it is difficult to pick out only three: there has been to much emphasis on the reuse of code; software reuse implies some form of modification of the artifact being reused; and software development processes do not explicitly support reuse, in fact they implicitly inhibit reuse.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"72 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127333828","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296785
Kevin D. Wentzel
The concept of systematic software reuse is simple: the idea of building and using "software preferred parts." By building systems out of carefully designed, pre-tested components, one will save the cost of designing, writing and testing new code. The practice of reuse has not proven to be this simple however, and there are many misconceptions about how to implement and gain benefit from software reuse.<>
{"title":"Software reuse - facts and myths","authors":"Kevin D. Wentzel","doi":"10.1109/ICSE.1994.296785","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296785","url":null,"abstract":"The concept of systematic software reuse is simple: the idea of building and using \"software preferred parts.\" By building systems out of carefully designed, pre-tested components, one will save the cost of designing, writing and testing new code. The practice of reuse has not proven to be this simple however, and there are many misconceptions about how to implement and gain benefit from software reuse.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"47 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115746301","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296784
J. Kramer
The term "distributed software engineering" is ambiguous. It includes both the engineering of distributed software and the process of distributed development of software, such as cooperative work. This paper concentrates on the former, giving an indication of the special needs and rewards in distributed computing. In essence, we argue that the structure of these systems as interacting components is a blessing which forces software engineers towards compositional techniques which offer the best hope for constructing scalable and evolvable systems in an incremental manner. We offer some guidance and recommendations as to the approaches which seem most appropriate, particularly in languages for distributed programming, specification and analysis techniques for modeling and distributed paradigms for guiding design.<>
{"title":"Distributed software engineering","authors":"J. Kramer","doi":"10.1109/ICSE.1994.296784","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296784","url":null,"abstract":"The term \"distributed software engineering\" is ambiguous. It includes both the engineering of distributed software and the process of distributed development of software, such as cooperative work. This paper concentrates on the former, giving an indication of the special needs and rewards in distributed computing. In essence, we argue that the structure of these systems as interacting components is a blessing which forces software engineers towards compositional techniques which offer the best hope for constructing scalable and evolvable systems in an incremental manner. We offer some guidance and recommendations as to the approaches which seem most appropriate, particularly in languages for distributed programming, specification and analysis techniques for modeling and distributed paradigms for guiding design.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"86 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115868135","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296787
M. Griss
At Hewlett-Packard, we have had visible divisional software reuse efforts since the mid-1980s. In 1990, we initiated a multi-faceted corporate reuse program to gather information about reuse from within HP and from other companies. As we studied the existing reuse programs, we discovered that certain issues were poorly understood, and as a consequence, mistakes were made in starting and running certain programs at HP and elsewhere. Our corporate reuse program focused on packaging best-practice information and guidelines to avoid common pitfalls. We also developed technology transfer and educational processes to spread this information and enhance reuse practice within the company. In 1992, we launched a multi-disciplinary research program to investigate and develop better methods for domain-specific, reuse-based software engineering. We have learned that for large-scale reuse to work, the problems to be overcome are mostly non-technical.<>
{"title":"Software reuse experience at Hewlett-Packard","authors":"M. Griss","doi":"10.1109/ICSE.1994.296787","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296787","url":null,"abstract":"At Hewlett-Packard, we have had visible divisional software reuse efforts since the mid-1980s. In 1990, we initiated a multi-faceted corporate reuse program to gather information about reuse from within HP and from other companies. As we studied the existing reuse programs, we discovered that certain issues were poorly understood, and as a consequence, mistakes were made in starting and running certain programs at HP and elsewhere. Our corporate reuse program focused on packaging best-practice information and guidelines to avoid common pitfalls. We also developed technology transfer and educational processes to spread this information and enhance reuse practice within the company. In 1992, we launched a multi-disciplinary research program to investigate and develop better methods for domain-specific, reuse-based software engineering. We have learned that for large-scale reuse to work, the problems to be overcome are mostly non-technical.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"102 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124011766","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296789
M. Wasmund
This paper on software reuse is the view of a practitioner rather than of a scientist. Myth 1: OO technology eats up reuse. Fact 1: OO does not automatically yield high reuse rates-both OO and reuse can complement each other. Myth 2: Incentives are key to reuse success. Fact 2: Incentives create awareness, are cheap but don't change much. Myth 3: Reuse is for free. Fact 3: Reuse is a mid-term investment impacting the entire software development process. It must be based on a product strategy which spans several releases or a family of products.<>
{"title":"Reuse facts and myths","authors":"M. Wasmund","doi":"10.1109/ICSE.1994.296789","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296789","url":null,"abstract":"This paper on software reuse is the view of a practitioner rather than of a scientist. Myth 1: OO technology eats up reuse. Fact 1: OO does not automatically yield high reuse rates-both OO and reuse can complement each other. Myth 2: Incentives are key to reuse success. Fact 2: Incentives create awareness, are cheap but don't change much. Myth 3: Reuse is for free. Fact 3: Reuse is a mid-term investment impacting the entire software development process. It must be based on a product strategy which spans several releases or a family of products.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116163633","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296772
Y. Takada, Ken-ichi Matsumoto, K. Torii
To organize and manage software development teams, it as important to evaluate the capability of each programmer based on reliable and easily collected data. We present a system which automatically monitors programmer activities, and propose a programmer debugging performance measure based on data monitored by the system. The system automatically categorizes programmer activity in real time into three types (compilation, program execution, and program modification) by monitoring and analyzing key strokes of a programmer. The resulting outputs are the time sequences of monitored activities. The measure we propose is the average length of debugging time per fault, D, estimated from the data sequences monitored by the system. To estimate the debugging time per fault, we introduce a testing and debugging process model. The process model has parameters associated with the average length of a program modification, d, and the probability of a fault being fixed completely by a program modification, r. By taking account of r as well as d, the debugging time per fault can be estimated with high accuracy. The model parameters, such as d and r, are computed from the monitored data sequences by using a maximum likelihood estimation method.<>
{"title":"A programmer performance measure based on programmer state transitions in testing and debugging process","authors":"Y. Takada, Ken-ichi Matsumoto, K. Torii","doi":"10.1109/ICSE.1994.296772","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296772","url":null,"abstract":"To organize and manage software development teams, it as important to evaluate the capability of each programmer based on reliable and easily collected data. We present a system which automatically monitors programmer activities, and propose a programmer debugging performance measure based on data monitored by the system. The system automatically categorizes programmer activity in real time into three types (compilation, program execution, and program modification) by monitoring and analyzing key strokes of a programmer. The resulting outputs are the time sequences of monitored activities. The measure we propose is the average length of debugging time per fault, D, estimated from the data sequences monitored by the system. To estimate the debugging time per fault, we introduce a testing and debugging process model. The process model has parameters associated with the average length of a program modification, d, and the probability of a fault being fixed completely by a program modification, r. By taking account of r as well as d, the debugging time per fault can be estimated with high accuracy. The model parameters, such as d and r, are computed from the monitored data sequences by using a maximum likelihood estimation method.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"78 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126250103","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 : 1994-05-21DOI: 10.1109/ICSE.1994.296802
J. Kramer
The author advocates the use of a separate and explicit structural language to describe software architectures. The structural nature makes it amenable to both textual and graphical description. Since it is a language, it can be used to support general descriptions and to provide the framework for checking interconnections. In addition, it can be used to generate and manage the system itself. This approach, initially under the guise of simple "module interconnection languages" (MIL) and subsequently as "configuration languages", provides generalised support for a wide variety of component and interaction types. Generic (skeleton) architectures provide the means for reusing structures with different constituent components. Dynamic constructs support explicit extension while constraining the potential structures of the system to those expressed as valid. Further, change can be supported at the architectural level, either offline on the design or code, or dynamically on the system itself. System structure (architecture), separately and explicitly described, should be recognised as the unifying framework upon which to hang specification, design, construction and evolution of systems.<>
{"title":"Exoskeletal software","authors":"J. Kramer","doi":"10.1109/ICSE.1994.296802","DOIUrl":"https://doi.org/10.1109/ICSE.1994.296802","url":null,"abstract":"The author advocates the use of a separate and explicit structural language to describe software architectures. The structural nature makes it amenable to both textual and graphical description. Since it is a language, it can be used to support general descriptions and to provide the framework for checking interconnections. In addition, it can be used to generate and manage the system itself. This approach, initially under the guise of simple \"module interconnection languages\" (MIL) and subsequently as \"configuration languages\", provides generalised support for a wide variety of component and interaction types. Generic (skeleton) architectures provide the means for reusing structures with different constituent components. Dynamic constructs support explicit extension while constraining the potential structures of the system to those expressed as valid. Further, change can be supported at the architectural level, either offline on the design or code, or dynamically on the system itself. System structure (architecture), separately and explicitly described, should be recognised as the unifying framework upon which to hang specification, design, construction and evolution of systems.<<ETX>>","PeriodicalId":432962,"journal":{"name":"Proceedings of 16th International Conference on Software Engineering","volume":"101 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-05-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128771827","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
扫码关注我们
求助内容：
应助结果提醒方式：