X hits on this document

322 views

0 shares

0 downloads

0 comments

10 / 120

Today’s technology is unfortunately tomorrow’s legacy system. For example, the

Web 2.0 revolution sees the current crop of web sites as legacy Web applications

comprised of multiple HTML pages; Web 2.0 envisions sites where a user interacts with a

single dynamic page—rendering a user experience that is more like traditional desktop

applications [2]. Porting the current crop of legacy web sites to Web 2.0 will require

understanding the architecture and design of these legacy sites—again requiring reverse

engineering skills and tools.

At first glance, it may seem that the need for SRE can be lessened by simply

maintaining good documentation for all software that is written. While the presence of

that ideal would definitely decrease the need; it just has not become a reality. For

example, even a company that has brought software to market may no longer understand

it because the original designers and developers may have left, or components of the

software may have been acquired from a vendor who is no longer in business [1].

Going forward, the vision is to include SRE incrementally, as part of the normal

development, or “forward engineering” of software systems. At regular points during the

development cycle, code would be reversed to rediscover its design so that the

documentation can be updated. This would help avoid the typical situation where

detailed information about a software system such as its architecture, design constraints,

and trade-offs are found only in the memory of its developer [1].

2

Document info
Document views322
Page views323
Page last viewedSun Dec 04 18:21:56 UTC 2016
Pages120
Paragraphs2913
Words25794

Comments