1、 毕业论文（设计） 外文翻译 题 目 ： 学 院： 数理与信息学院 学生姓名： 专 业： 计算机科学与技术 班 级： 指导教师： 起 止 日期： 2013.3.29 至 2013.6.18 2013 年 4 月 26 日 1 Paper1 Extreme Programming As we have explored in several issues of eAD , the two most pressing issues in information technology today are: How do we deliver functionality to business cli
2、ents quickly? How do we keep up with near-continuous change? Change is changing. Not only does the pace of change continue to accelerate, but, as the September issue of eAD pointed out, organizations are having to deal with different types of change - disruptive change and punctuated equilibrium. Di
3、sruptive technologies, like personal computers in the early 1980s, impact an industry (in the case of PCs, several related industries), while a punctuated equilibrium - a massive intervention into an ecosystem or an economy - impacts a very large number of species, or companies. The Internet, which
4、has become the backbone for e-commerce and e-business, has disrupted a wide range of industries - more a punctuated equilibrium than a disruption. When whole business models are changing, when time-to-market becomes the mantra of companies, when flexibility and interconnectedness are demanded from e
5、ven the most staid organization, it is then that we must examine every aspect of how business is managed, customers are delighted, and products are developed. The Extreme Programming movement has been a subset of the object-oriented (OO) programming community for several years, but has recently attr
6、acted more attention, especially with the recent release of Kent Becks new book Extreme Programming Explained: Embrace Change . Dont be put off by the somewhat in-your- face moniker of Extreme Programming (XP to practitioners). Although Beck doesnt claim that practices such as pair programming and i
7、ncremental planning originated with XP, there are some very interesting, and I think important, concepts articulated by XP. Theres a lot of talk today about change, but XP has some pretty good ideas about how to actually do it. Hence the subtitle, Embrace Change . There is a tendency, particularly b
8、y rigorous methodologists, to dismiss anything less ponderous than the Capability Maturity Model (CMM) or maybe the International Organization 2 for Standardizations standards, as hacking. The connotation: hacking promotes doing rather than thinking and therefore results in low quality. This is an e
9、asy way to dismiss practices that conflict with ones own assumptions about the world. Looked at another way, XP may be a potential piece of a puzzle Ive been writing about over the past 18 months. Turbulent times give rise to new problems that, in turn, give rise to new practices - new practices tha
10、t often fly in the face of conventional wisdom but survive because they are better adapted to the new reality. There are at least four practices I would assign to this category: XP - the focus of this issue of eAD Lean development - discussed in the November 1998 issue of eAD Crystal Light methods -
11、 mentioned in the November 1999 issue of eAD and further discussed in this issue . Adaptive software development - described in the August 1998 issue of eAD (then called Application Development Strategies - ADS ). Although there are differences in each of these practices, there are also similarities
12、: they each describe variations from the conventional wisdom about how to approach software development. Whereas lean and adaptive development practices target strategic and project management, XP brings its differing world view to the realm of the developer and tester. Much of XP is derived from go
13、od practices that have been around for a long time. None of the ideas in XP are new. Most are as old as programming, Beck offers to readers in the preface to his book. I might differ with Beck in one respect: although the practices XP uses arent new, the conceptual foundation and how they are melded together greatly enhance these older practices. I think there are four critical ideas to take away from XP (in addition to a number of other good ideas): The cost of change Refactoring Collaboration Simplicity
