Portal de Periódicos da CAPES

An Introduction to Software Stability

2001; Association for Computing Machinery; Volume: 44; Linguagem: Inglês

1557-7317

Mohamed E. Fayad, Adam Altman,

Software Engineering Research

here is little doubt thefield of software engineer-ing, like all other engi-neering fields, has helpedmake life what it is today. Withsoftware controlling more equip-ment, software engineering isbecoming an integral part of ourlives. However, unlike many otherengineering fields, the productsproduced through software engi-neering are largely intangible.Also, unlike the products of otherengineering fields, software prod-ucts are unlikely to remain stableover a long period of time.This column is the first in aseries offering insight into thecentral themes of software stabil-ity. In this series we examine theunique characteristics of softwarethat distinguish it from otherengineering fields. We also studythe artifacts of analysis, design,development, and other factorsthat tend to produce stable orunstable software products. In hardware areas, failure ratesof products often start high, droplow, and then go high again.Early in a hardware product’s life-cycle, there are some problemswith the system. As these prob-lems are fixed, the failure ratedrops. However, as hardware getsold, physical deterioration causesit to fail. In other words, thehardware wears out and the fail-ure rate rises again.Software, on the other hand,is not subject to hardware’s samewear and tear. There are no envi-ronmental factors that cause soft-ware to break. Software is a set ofinstructions, or a recipe, for apiece of hardware to follow.There are no moving parts insoftware; nothing can physicallydeteriorate. Software should notwear out. Unfortunately, it does.Countless authors in the field ofsoftware engineering have identi-fied this problem. However, thesoftware engineering techniquesoutlined by many software-engi-neering authors have notachieved an adequate amount ofstability in software projects.This problem is more than justan inconvenience for softwareengineers and users. The reengi-neering required for these soft-ware products does not comewithout a price. It is common tohear of reengineering projectscosting hundreds of thousands, tomillions of dollars. This does nottake into account the time wastedby continual reengineering.Software defects and deteriora-tion are caused by changes insoftware. Many of these changescannot be avoided. They can,however, be minimized. Cur-rently, when a change is made toa software program, most of thetime the entire program isreengineered. It doesn’t matter ifthe change is due to new tech-nology or a change in clientele.This reengineering process isridiculous. If the core purpose ofthe software product has notchanged, why, then, must theentire project be reengineered toincorporate a change?The concepts of “enduringbusiness themes” (EBTs) and“business objects” (BOs) havebeen introduced as a proposedsolution to this problem. Theidea in this case is to identifyaspects of the environment inwhich the software will operatethat will not change and caterthe software to these areas. Themajority of the engineering doneon a software project should bedone to fit the project to thoseareas remaining stable. Thisyields a stable core design and,thus, a stable software product.