{"title":"Review of Frank Niessink's thesis","authors":"H. Vliet","doi":"10.1002/1096-908X(200005/06)12:3%3C185::AID-SMR210%3E3.0.CO;2-H","DOIUrl":"https://doi.org/10.1002/1096-908X(200005/06)12:3%3C185::AID-SMR210%3E3.0.CO;2-H","url":null,"abstract":"Frank Niessink showed me your review of his thesis (see pages 187–195 in this issue of the Journal of Software Maintenance ). I am somewhat puzzled by the negative ‘tone’ of Section 5 of your review, labeled ‘Comments’. Under item 1, you say ‘Had the researcher used control theory and practice as a base, nearly the entire book could have been readily condensed into an “application of” medium-length paper.’ To me, this sounds as a pretty negative overall opinion. I know control theory can be applied to software development, software maintenance, and process improvement. I must confess I had not consciously thought of applying it here. It might have allowed him to make certain arguments more concise. I doubt whether it would have reduced the whole thing to a medium-length paper. You noticed in the first paragraph of your review that much of the dissertation has been published in seven papers. These seven papers have together been reviewed by quite a few people. There have of course been quite a few remarks by those referees, but not a single one of them mentioned control theory. This may hint at a serious lack of knowledge of this community. It may also indicate something else. Finally, the external examiner of Frank’s thesis was Dr Shari Lawrence Pfleeger, whom you undoubtedly know. Her written comments on the thesis go as follows. ‘This dissertation does a wonderful job of describing a measurement problem, identifying key issues related to it, deriving from the literature the important lessons learned about the problem in the past, and creating a framework for further understanding and improvement . . . . In summary, Mr Niessink has done a fine job, not only in demonstrating his ability to do good research, but also in synthesizing and extending current research to produce practical, effective solutions to important problems.’ I may be biased, but I do think Frank wrote a good thesis.","PeriodicalId":383619,"journal":{"name":"J. Softw. Maintenance Res. Pract.","volume":"244 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2000-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115097085","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}
{"title":"Evolution in software product lines: two cases","authors":"Mikael Svahnberg, J. Bosch","doi":"10.1002/(SICI)1096-908X(199911/12)11:6%3C391::AID-SMR199%3E3.0.CO;2-8","DOIUrl":"https://doi.org/10.1002/(SICI)1096-908X(199911/12)11:6%3C391::AID-SMR199%3E3.0.CO;2-8","url":null,"abstract":"This paper discuss the results of two case studies from a technical perspective, concentrating on the evolution of software assets in two Swedish organizations that have employed a product-line architecture approach for several years. This paper describes and analyses the commonalities and differences of these two cases, emphasising categories of the evolution of the requirements, of the software architecture and of the software components. This paper concludes with three types of lessons learned about evolution in software product lines: three evolution categories are predominant, three other categories are less significant but still common, and seven guidelines for software product-line evolution emerge. Copyright (C) 1999 John Wiley & Sons, Ltd.","PeriodicalId":383619,"journal":{"name":"J. Softw. Maintenance Res. Pract.","volume":"48 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1999-11-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125426748","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}
{"title":"ART: an architectural reverse engineering environment","authors":"R. Fiutem, G. Antoniol, P. Tonella, E. Merlo","doi":"10.1002/(SICI)1096-908X(199909/10)11:5%3C339::AID-SMR196%3E3.0.CO;2-I","DOIUrl":"https://doi.org/10.1002/(SICI)1096-908X(199909/10)11:5%3C339::AID-SMR196%3E3.0.CO;2-I","url":null,"abstract":"When programmers perform maintenance tasks, program understanding is often required. One of the rst activities in understanding a software system is identifying its subsystems and their relations, i.e. its software architecture. Since a large part of the eeort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems, by showing them architectural information. This paper describes an environment for the architectural recovery of software systems called Architectural Recovery Tool (ART). The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a diierent architectural view of a system or of some of its parts. Recognizers embody knowledge about architectural clich es and use ow analysis techniques to make their output more accurate. To test the accuracy and eeectiveness of ART, a suite of public domain applications containing interesting architectural organizations was selected as a benchmark. Results are presented by showing ART performance in terms of precision and recall of the architectural concept retrieval process. The results obtained show that clich e based architectural recovery is feasible and the recovered information can be a valuable support in reengineering and maintenance activities.","PeriodicalId":383619,"journal":{"name":"J. Softw. Maintenance Res. Pract.","volume":"10 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1999-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130653580","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}
{"title":"Removing clones from the code","authors":"R. Fanta, V. Rajlich","doi":"10.1002/(SICI)1096-908X(199907/08)11:4%3C223::AID-SMR194%3E3.0.CO;2-D","DOIUrl":"https://doi.org/10.1002/(SICI)1096-908X(199907/08)11:4%3C223::AID-SMR194%3E3.0.CO;2-D","url":null,"abstract":"In this paper we discus the elimination of function and class clones from industrial object-oriented code. Clone removal can decrease code size and facilitate maintenance. We eliminate clones by reengineering scenarios that are based on automated restructuring tools. The paper presents examples of clones, reengineering scenarios, and restructuring tools. The usefulness of the approach is demonstrated in a case study","PeriodicalId":383619,"journal":{"name":"J. Softw. Maintenance Res. Pract.","volume":"44 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1999-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116414612","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}