信息科学翻译-敏捷软件方法最新的进展水平AgileSoftwareMethodsState-of-the-Art

1、计算机与信息学院 本科毕业设计（论文）外文资料翻译原文部分Agile Software Methods:State-of-the-Art(Abstract from Agile Software Development Quality Assurance,written by Ioannis G. Stamelos and Panagiotis Sfetsos)AbstractThis chapter is aimed at comprehensively analyzing and defining agile methodologies of software development fr

2、om a software quality assurance perspective. A unique way of analyzing agile methodologies to reveal the similarities that the authors of the methods never tell you is introduced. The chapter starts by defining agile methodologies from three perspectives: a theoretical definition, a functional defin

3、ition, and a contextualized definition. Then an agile quality assurance perspective is presented starting from a brief review of some of the traditional understandings of quality assurance to the innovations that agility has added to the world of quality. The presented analysis approach opens a wind

4、ow into an understanding of the state-of-the-art in agile methodologies and quality, and what the future could have in store for software developers. An understanding of the analysis framework for objectively analyzing and comparing agile methodologies is illustrated by applying it to three specific

5、 agile methodologiesIntroductionAgile software development methodologies have taken the concepts of software quality assurance further than simply meeting customer requirements,validation, and verification. Agility innovatively opens new horizons in the area of software quality assurance. A look at

6、the agile manifesto (Agile Alliance, 2001) reveals that agile software development is not just about meeting customer requirements (because even rocess-driven methodologies do that), but it is about meeting the changing requirements right up to the level of product deployment. This chapter introduce

7、s a technique for analyzing agile methodologies in a way that reveals the fundamental similarities among the different agile processes.As for now, there is a reasonable amount of literature that seeks to describe this relatively new set of methodologies that have certainly changed the way software d

8、evelopment is done. Most of the existing work is from the authors of the methodologies and a few other practitioners. What lacks is therefore a more balanced evaluation comparing what the original intents of the authors of agile methodologies were, to the actual things that have been done through ag

9、ile methodologies over the last few years of their existence as a group, and the possible future applications.While most of those who have applied agile methods in their software development projects have gained margins that are hard to ignore in the areas of product relevance (a result of embracing

10、 requirements instability) and quick delivery (a result of iterative incremental development), some have not joined this new fun way to develop software due to a lack of understanding the fundamental concepts underlying agile methodologies. Hence, this chapter intends to give the necessary understan

11、ding by comprehensively defining agile methodologies and revealing how agile methodologies have taken software quality assurance further than traditional approaches. The second concern resulted from more than three years of research into agile methodology practices where the author discovered that t

12、he individual agile methods such as extreme programming, scrum, and lean development etc. are not that different from each other. The apparent difference is because people from different computing backgrounds authored them and happen to view the real world differently. Hence, the differences are not

13、 as much as the authors would like us to believe. The evaluation technique introduced here will reveal the similarities in a novel way and address the adoption concerns of agile methodologies. This also reveals what quality in an agile context means.Chapter objectivesThe objective of this chapter is

14、 to introduce you to the fundamentals of analyzing agile methodologies to reveal the bare bones of agile development. After reading this chapter, you will: Understand three approaches to the definition of agile methodologies (i.e., a theoretical definition, a functional definition, and a contextuali

15、zed definition). Understand the state-of-the-art in agile methodologies. Understand the presented framework for objectively analyzing and comparing agilemethodologies. Understand the meaning of software quality assurance in an agile context.BackgroundThis section will start by defining agile methodo

16、logies based on what people say about agile methodologies, what people do with agile methodologies, and what agile methodologies have done to the broad area of software development.Defining Agile MethodologiesThe agile software development methodologies group was given the name “agile” when a group

17、of software development practitioners met and formed the Agile Alliance (an association of software development practitioners that was formed to formalize agile methodologies) in February 2001. The agile movement could mark the emergence of a new engineering discipline (Mnkandla & Dwolatzky, 200

18、4a) that has shifted the values of the software development process from the mechanistic (i.e., driven by process and rules of science) to the organic (i.e., driven by softer issues of people and their interactions). This implies challenges of engineering complex software systems in work environment

19、s that are highly dynamic and unpredictable.Theoretical definitionAfter the first eWorkshop on agile methodologies in June 2002, Lindvall et al. (2002) summarized the working definition of agile methodologies as a group of software development processes that are iterative, incremental, self-organizi

20、ng, and emergent. The meaning of each term in the greater context of agility is shown next.1. Iterative: The word iterative is derived from iteration which carries with it connotations of repetition. In the case of agile methodologies, it is not just repetition but also an attempt to solve a softwar

21、e problem by finding successive approximations to the solution starting from an initial minimal set of requirements. This means that the architect or analyst designs a full system at the very beginning and then changes the functionality of each subsystem with each new release as the requirements are

22、 updated for each attempt. This approach is in contrast to more traditional methods, which attempt to solve the problem in one shot. Iterative approaches are more relevant to todays software development problems that are characterized by high complexity and fast changing requirements. Linked with th

23、e concept of iterations is the notion of incremental development, which is defined in the next paragraph.2. Incremental: Each subsystem is developed in such a way that it allows more requirements to be gathered and used to develop other subsystems based on previous ones. The approach is to partition

24、 the specified system into small subsystems by functionality and add a new functionality with each new release. Each release is a fully tested usable subsystem with limited functionality based on the implemented specifications. As the development progresses, the usable functionalities increase until

25、 a full system is realized.3. Self-organizing: This term introduces a relatively foreign notion to the managementof scientific processes. The usual approach is to organize teams according to skills and corresponding tasks and let them report to management in a hierarchical structure. In the agile de

26、velopment setup, the “self-organizing” concept gives the team autonomy to organize itself to best complete the work items. This means that the implementation of issues such as interactions within the team, team dynamics, working hours, progress meetings, progress reports etc. are left to the team to

27、 decide how best they can be done. Such an approach is rather eccentric to the way project managers are trained and it requires that the project managers change their management paradigm all together. This technique requires that the team members respect each other and behave professionally when it

28、comes to what has been committed on paper. In other words management and the customer should not get excuses for failure to meet the commitment and there should be no unjustified requests for extensions. The role of the project manager in such a setup is to facilitate the smooth operation of the tea

29、m by liaising with top management and removing obstacles where possible. The self-organizing approach therefore implies that there must be a good communication policy between project management and the development team.4. Emergent: The word implies three things.Firstly, based on the incremental natu

30、re of the development approach the system is allowed to emerge from a series of increments. Secondly, based on the self-organizing nature a method of working emerges as the team works. Thirdly, as the system emerges and the method of working emerges a framework of development technologies will also

31、emerge. The emergent nature of agile methodologies means that agile software development is in fact a learning experience for each project and will remain a learning experience because each project is treated differently by applying the iterative, incremental, self-organizing, and emergent technique

32、s. Figure 1 sums up the theoretical definition of agile methodologies.Figure 1. Definition of agility © copyright Ernest Mnkandla PhD thesis University of the WitwatersrandThe value of agility is in allowing the concepts defined above to mutate within the parameters set by the agile values and

33、principles (For details on agile values and principles see the agile manifesto at . ). There is always a temptation to fix a framework of software development if success is repeatedly achieved, but that would kill the innovation that comes with agile development.Functional

34、 definitionAgile methodologies will now be defined according to the way some agile practitioners have understood them as they used them in real world practice. The term “agile” carries with it connotations of flexibility, nimbleness, readiness for motion, activity, dexterity in motion, and adjustabi

35、lity (Abrahamsson, Salo, Ronkainen, & Warsta, 2002). Each of these words will be explained further in the context of agility in order to give a more precise understanding of the kinds of things that are done in agile development. Flexibility: This word implies that the rules and processes in agi

36、le development can be easily bended to suit given situations without necessarily breaking them. In other words, the agile way of developing software allows for adaptability and variability. Nimbleness: This means that in agile software development there must be quick delivery of the product. This is

37、 usually done through the release of usable subsystems within a period ranging from one week to four weeks. This gives good spin-offs as the customer will start using the system before it is completed. Readiness for motion: In agile development, the general intention is to reduce all activities and

38、material that may either slow the speed of development or increase bureaucracy. Activity: This involves doing the actual writing of code as opposed to all the planning that sometimes takes most of the time in software development. Dexterity in motion: This means that there must be an abundance of sk

39、ills in the activity of developing code. The skills referred to are the mental skills that will arm thedevelopers for programming challenges and team dynamics. Adjustability: This is two fold; firstly there must be room for change in the set of activities and technologies that constitute an agile de

40、velopment process, secondly the requirements, code, and the design/architecture must be allowed to change to the advantage of the customer.According to Beck (1999), agile methodologies are a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. These t

41、erms will be defined in this context to give a functional perspective of agile development. Lightweight： implies minimizing everything that has to be done in the development process (e.g., documentation, requirements, etc.) in order to increase the speed and efficiency in development. The idea of mi

42、nimizing documentation is still a controversial one as some assume agility to mean no documentation at all. Such views are however not unfounded because some agile extremists have expressed connotations of zero documentation claiming that the code is sufficient documentation. As agile methodologies

43、approach higher levels of maturity minimizing documentation has evolved to generally imply providing as much documentation as the customer is willing pay for in terms of time and money. Efficient means doing only that work that will deliver the desired product with as little overhead as practically

44、possible. Low-risk implies trading on the practical lines and leaving the unknown until it is known. In actual fact, all software development methodologies are designed to reduce the risks of project failure. At times, a lot of effort is wasted in speculative abstraction of the problem space in a bi

45、d to manage risk. Predictable implies that agile methodologies are based on what practitioners do all the time, in other words the world of ambiguity is reduced. This however does not mean that planning, designs, and architecture of software are predictable. It means that agility allows development

46、of software in the most natural ways that trained developers can determine in advance based on special knowledge. Scientific means that the agile software development methodologies are based on sound and proven scientific principles. It nevertheless remains the responsibility of the academia to cont

47、inue gathering empirical evidence on agile processes because most of the practitioners who authored agile methodologies seem to have little interest and time to carryout this kind of research. Fun way because at last developers are allowed to do what they like most (i.e., to spend most of their time

48、 writing good code that works). To the developers, agility provides a form of freedom to be creative and innovative without making the customer pay for it, instead the customer benefits from it.Schuh (2004) defines agile development as a counter movement to 30 years of increasingly heavy-handed proc

49、esses meant to refashion computer programming into software engineering, rendering it as manageable and predictable as any other engineering discipline.On a practical perspective, agile methodologies emerged from a common discovery among practitioners that their practice had slowly drifted away from

50、 the traditional heavy document and process centered development approaches to more people-centered and less document-driven approaches (Boehm & Turner, 2004; Highsmith, 2002a; Fowler, 2002). There is a general misconception that there is no planning or there is little planning in agile processe

51、s. This is due to the fact that the agile manifesto lists as one of its four values the preference for responding to change over following a plan (Agile Alliance, 2001). In fact, planning in agile projects could be more precise than in traditional processes it is done rigorously for each increment a

52、nd from a project planning perspective agile methodologies provide a risk mitigation approach where the most important principle of agile planning is feedback. Collins-Cope (2002) lists the potential risks as: risks of misunderstandings in functional requirements, risks of a deeply flawed architectu

53、re; risks of an unacceptable user interface; risks of wrong analysis and design models; risks of the team not understanding the chosen technology et cetera.Feedback is obtained by creating a working version of the system at regular intervals or per increment according to the earlier planning effort

54、(Collins-Cope, 2002). Besides dealing with the most pertinent risks of software development through incremental development, agile methodologies attack the premise that plans, designs, rchitectures, and requirements are predictable and can therefore be stabilized. Agile methodologies also attack the

55、 premise that processes are repeatable (Highsmith, 2001; Schwaber & Beedle, 2002). These two premises are part of fundamental principles on which traditional methodologies are built, and they also happen to be the main limitations of the traditional methodologies.Boehm et al. (2004) view agile m

56、ethodologies as a challenge to the mainstream software development community that presents a counter-culture movement, which addresses change from a radically different perspective. All agile methodologies follow the four values and 12 principles as outlined in the agile manifesto.Contextual definit

57、ionFrom these definitions of agile methodologies, a contextual definition can be derived which looks at what agility means in terms of certain specific software engineering concepts. Examples of that would be concepts are software quality assurance, software process improvement, software process mod

58、eling, and software project management. Agile methodologies will now be defined according to these concepts. Since this book is specifically focused on agile software quality assurance the definition of agile software quality assurance will be given in more detail.Agile software Quality AssuranceThi

59、s section starts by summarizing the traditional definitions of quality and then presents a summary of the work that has been done in the area of agility and quality. References to older literature on software quality are not intended to be exhaustive, but to be simply present a fare baseline for evaluating software quality perspectives in the modern processes. The authors are aware of a number of initiatives in research and academic i