介绍小组会议的雷曼软件进化定律,在上下文中

N. Madhavji
{"title":"介绍小组会议的雷曼软件进化定律,在上下文中","authors":"N. Madhavji","doi":"10.1109/ICSM.2002.1167748","DOIUrl":null,"url":null,"abstract":"If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]:","PeriodicalId":385190,"journal":{"name":"International Conference on Software Maintenance, 2002. Proceedings.","volume":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2002-10-03","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"6","resultStr":"{\"title\":\"Introduction to the panel session Lehman's laws of software evolution, in context\",\"authors\":\"N. Madhavji\",\"doi\":\"10.1109/ICSM.2002.1167748\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]:\",\"PeriodicalId\":385190,\"journal\":{\"name\":\"International Conference on Software Maintenance, 2002. Proceedings.\",\"volume\":null,\"pages\":null},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2002-10-03\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"6\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"International Conference on Software Maintenance, 2002. Proceedings.\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ICSM.2002.1167748\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"International Conference on Software Maintenance, 2002. Proceedings.","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ICSM.2002.1167748","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 6

摘要

如果在我们的社区中有人从软件工程之旅的开始就一直开着“远光灯”,那么在我看来,毫无疑问,这个人就是Manny Lehman教授。当我们中的大多数人还处于婴儿期或者正在解决软件问题时,雷曼已经把他的眼光放在了编程过程的前面,正如1969年发表的一篇开创性的论文[1]所证明的那样。在大约35年的时间里,雷曼一直关注软件的长期健康,实际上,它超越了下一个版本,而其他大多数人——在实践和研究中——都有“低垂的目光”,好像下一个版本是软件产品或系统的最终版本。当我们在漆黑的软件工程道路上行驶时,为什么会遇到意外,这一点无需进一步解释。虽然在早期,软件系统不那么可靠,用途非常有限,这对整个社会来说无关紧要,但今天,随着我们社会对软件的依赖已经很重,而且越来越多,情况就不同了。然而,没有回头路可走,我们必须寻找方法来创建和发展软件系统,以便在我们的动态环境中长期提供持续的高质量服务。幸运的是,在实践和研究中,许多人已经开始意识到软件进化的重要性,以及短期思维在经济和服务质量上的巨大代价。这个小组会议并不是关于软件进化的,尽管我毫不怀疑一些讨论可能会朝着这个方向发展。它是关于雷曼的软件进化法则,在其他公司经验的背景下。雷曼多年来对许多实际软件系统的演变进行了实证研究:OS/360-70和1968年[1]至1985年[2]之间的其他系统,以及最近在FEAST(反馈、演变和软件技术)项目(19962001)[3,4](与ICL、Logica、MoDDERA、Matra-BAe Dynamics、朗讯技术、BT实验室以及同事(特别是Turski、Perry和Ramil[5,6])合作)中,他已经能够确认、完善和扩展早期的结果。正是通过这些不懈的努力,在很长一段时间内,雷曼制定并完善了软件进化的八条定律(见表-摘自[7])。多年来,这些法则慢慢地、但肯定地在教育界、工业界和研究界获得了不同程度的认可。我不打算在这里讨论这些法律,尽管我毫不怀疑小组成员会讨论这些法律,但值得注意的是,选择“法律”一词是因为[7]:
本文章由计算机程序翻译,如有差异,请以英文原文为准。
查看原文
分享 分享
微信好友 朋友圈 QQ好友 复制链接
本刊更多论文
Introduction to the panel session Lehman's laws of software evolution, in context
If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]:
求助全文
通过发布文献求助,成功后即可免费获取论文全文。 去求助
来源期刊
自引率
0.00%
发文量
0
期刊最新文献
An algorithm to compare OO-conceptual schemas From legacy to Web through interaction modeling Union slices for program maintenance Putting escape analysis to work for software testing Corrective Maintenance Maturity Model: Problem Management
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
现在去查看 取消
×
提示
确定
0
微信
客服QQ
Book学术公众号 扫码关注我们
反馈
×
意见反馈
请填写您的意见或建议
请填写您的手机或邮箱
已复制链接
已复制链接
快去分享给好友吧!
我知道了
×
扫码分享
扫码分享
Book学术官方微信
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术
文献互助 智能选刊 最新文献 互助须知 联系我们:info@booksci.cn
Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。
Copyright © 2023 Book学术 All rights reserved.
ghs 京公网安备 11010802042870号 京ICP备2023020795号-1