Pub Date : 1998-03-16DOI: 10.1109/ICSM.1998.738515
R. Fanta, V. Rajlich
In this paper, we describe the reengineering of a deteriorated object-oriented industrial program written in C++. The main problem of the program was misplaced code, most often functions that were members of the wrong class. In order to deal with this problem, we designed and implemented several restructuring tools and used them in specific reengineering scenarios. We also discuss how this set of tools could be enhanced in the future, and the importance of restructuring for object-oriented software maintenance.
{"title":"Reengineering object-oriented code","authors":"R. Fanta, V. Rajlich","doi":"10.1109/ICSM.1998.738515","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738515","url":null,"abstract":"In this paper, we describe the reengineering of a deteriorated object-oriented industrial program written in C++. The main problem of the program was misplaced code, most often functions that were members of the wrong class. In order to deal with this problem, we designed and implemented several restructuring tools and used them in specific reengineering scenarios. We also discuss how this set of tools could be enhanced in the future, and the importance of restructuring for object-oriented software maintenance.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"193 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122507562","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 : 1998-03-16DOI: 10.1109/ICSM.1998.738493
T. Pearse
I have been working on HP LaserJet firmware as it has evolved for over the last ten years. During that time functionality has been reused, ported and leveraged across over two dozen laser printers ranging from personal home printers to office, network and color printers. New features continue to be added, such as new font technologies, higher resolutions, disk file systems, additional printing languages, different I/O protocols, copier features and color. During this ten years the size of the firmware has grown 10X in size. I'd like to share two things with you that I have found very important in measuring software. (1) gather metrics; and (2) use them! Either of these alone isn't very useful, although often done. I have seen cases in which people measure, but don't use the metrics or actually try to make decisions on subjective opinions without any data.
{"title":"Using software metrics to control firmware evolution","authors":"T. Pearse","doi":"10.1109/ICSM.1998.738493","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738493","url":null,"abstract":"I have been working on HP LaserJet firmware as it has evolved for over the last ten years. During that time functionality has been reused, ported and leveraged across over two dozen laser printers ranging from personal home printers to office, network and color printers. New features continue to be added, such as new font technologies, higher resolutions, disk file systems, additional printing languages, different I/O protocols, copier features and color. During this ten years the size of the firmware has grown 10X in size. I'd like to share two things with you that I have found very important in measuring software. (1) gather metrics; and (2) use them! Either of these alone isn't very useful, although often done. I have seen cases in which people measure, but don't use the metrics or actually try to make decisions on subjective opinions without any data.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"48 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115633965","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 : 1998-03-16DOI: 10.1109/ICSM.1998.738501
M. Vigder, John C. Dean
Maintaining large software systems based on Commercial Off-The-Shelf (COTS) components is a major cost driver for these systems. Maintenance includes activities from component replacement to trouble-shooting and configuration management. The maintenance costs for COTS based software systems can be reduced by building systems according to specific design criteria. This paper identifies the major activities of a system maintainer, describes the properties that can be designed into a system to facilitate these activities, and outlines a checklist of items that can be verified during a design or code review, or during the evaluation of a COTS components in order to guarantee these properties are built into the system. The verification is illustrated using a photo imaging system that is currently under development.
{"title":"Building maintainable COTS based systems","authors":"M. Vigder, John C. Dean","doi":"10.1109/ICSM.1998.738501","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738501","url":null,"abstract":"Maintaining large software systems based on Commercial Off-The-Shelf (COTS) components is a major cost driver for these systems. Maintenance includes activities from component replacement to trouble-shooting and configuration management. The maintenance costs for COTS based software systems can be reduced by building systems according to specific design criteria. This paper identifies the major activities of a system maintainer, describes the properties that can be designed into a system to facilitate these activities, and outlines a checklist of items that can be verified during a design or code review, or during the evaluation of a COTS components in order to guarantee these properties are built into the system. The verification is illustrated using a photo imaging system that is currently under development.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"59 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127080850","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 : 1998-03-16DOI: 10.1109/ICSM.1998.738498
F. Calzolari, P. Tonella, G. Antoniol
The dynamic evolution of ecological systems in which predators and prey compete for survival has been investigated by applying suitable mathematical models. Dynamic systems theory provides a useful way to model interspecies competition and thus the evolution of predator and prey populations. This kind of mathematical framework has been shown to be well suited to describe evolution of economical systems as well, where instead of predators and prey there are consumers and resources. Maintenance and testing activities absorb the most relevant part of the total life-cycle cost of software. Such economic relevance strongly suggests to investigate the maintenance and testing processes in order to find new models allowing software engineers to better estimate, plan and manage costs and activities. We show how dynamic systems theory could be usefully applied to maintenance and testing context, namely to model the dynamic evolution of the effort. When programmers start trying to recognize and correct code defects, while the number of residual defects decreases, the effort spent to find out any new defect has an initial increase, followed by a decline, in a similar way as prey and predator populations do. The feasibility of this approach is supported by the experimental data about two real world software projects.
{"title":"Dynamic model for maintenance and testing effort","authors":"F. Calzolari, P. Tonella, G. Antoniol","doi":"10.1109/ICSM.1998.738498","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738498","url":null,"abstract":"The dynamic evolution of ecological systems in which predators and prey compete for survival has been investigated by applying suitable mathematical models. Dynamic systems theory provides a useful way to model interspecies competition and thus the evolution of predator and prey populations. This kind of mathematical framework has been shown to be well suited to describe evolution of economical systems as well, where instead of predators and prey there are consumers and resources. Maintenance and testing activities absorb the most relevant part of the total life-cycle cost of software. Such economic relevance strongly suggests to investigate the maintenance and testing processes in order to find new models allowing software engineers to better estimate, plan and manage costs and activities. We show how dynamic systems theory could be usefully applied to maintenance and testing context, namely to model the dynamic evolution of the effort. When programmers start trying to recognize and correct code defects, while the number of residual defects decreases, the effort spent to find out any new defect has an initial increase, followed by a decline, in a similar way as prey and predator populations do. The feasibility of this approach is supported by the experimental data about two real world software projects.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"117 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133647384","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 : 1998-03-16DOI: 10.1109/ICSM.1998.738483
S. Pfleeger
As we maintain systems and build new ones, we have to make decisions about when to use old technology and when to adopt new ones. Especially when using components, we must decide when to use an old one whole, when to modify it, and when to create a new one. In this talk, I will look at such changes in the larger context of how we make decisions about adopting new technology. We will see that the decision-making must involve information in three arenas: technological, organizational and evidential. That is, we must know not only about the contrast between the old and new technologies, but also about the characteristics of the receiving organization, and the credibility of the evidence that the new technology is an improvement over the old.
{"title":"Making Change: The *Other* Components of Software Maintenance","authors":"S. Pfleeger","doi":"10.1109/ICSM.1998.738483","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738483","url":null,"abstract":"As we maintain systems and build new ones, we have to make decisions about when to use old technology and when to adopt new ones. Especially when using components, we must decide when to use an old one whole, when to modify it, and when to create a new one. In this talk, I will look at such changes in the larger context of how we make decisions about adopting new technology. We will see that the decision-making must involve information in three arenas: technological, organizational and evidential. That is, we must know not only about the contrast between the old and new technologies, but also about the characteristics of the receiving organization, and the credibility of the evidence that the new technology is an improvement over the old.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127507759","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 : 1998-03-16DOI: 10.1109/ICSM.1998.738502
J. Singer
This paper describes the results of an interview study conducted at ten industrial sites. The interview focused on the work practices of software engineers engaged in maintaining large scale systems. Five 'truths' emerged from this study. First, software maintenance engineers are experts in the systems they are maintaining. Second, source code is the primary source of information about systems. Third, the documentation is used, but not necessarily trusted. Fourth, maintenance control systems are important repositories of information about systems. Finally, reproduction of problems and/or problem scenarios is essential to problem solutions. These truths confirm much of the conventional wisdom in the field. However, in fleshing them out, details were elaborated, and additionally new knowledge was acquired. These results are discussed with respect to tool design.
{"title":"Practices of software maintenance","authors":"J. Singer","doi":"10.1109/ICSM.1998.738502","DOIUrl":"https://doi.org/10.1109/ICSM.1998.738502","url":null,"abstract":"This paper describes the results of an interview study conducted at ten industrial sites. The interview focused on the work practices of software engineers engaged in maintaining large scale systems. Five 'truths' emerged from this study. First, software maintenance engineers are experts in the systems they are maintaining. Second, source code is the primary source of information about systems. Third, the documentation is used, but not necessarily trusted. Fourth, maintenance control systems are important repositories of information about systems. Finally, reproduction of problems and/or problem scenarios is essential to problem solutions. These truths confirm much of the conventional wisdom in the field. However, in fleshing them out, details were elaborated, and additionally new knowledge was acquired. These results are discussed with respect to tool design.","PeriodicalId":271895,"journal":{"name":"Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)","volume":"198 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121817162","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}