Agile Software Development Methods 2010 e Ga Co

BQI Research
Agile Software Development

The most important Methods Status Report 2010
jan.liwski@axadirect.pl
Table of ConTenTs
1 2 3 INTRODUCTION AGILITY IN SOFTWARE DEVELOPMENT 2.1 Definition Agility 2.2 The agile manifesto AGILE PROCEDURE MODELS 3.1 ActiF 3.2 Adaptive Software Development (ASD) 3.3 Agile Enterprise (formerly X Breed) 3.4 Agile Model Driven Development (AMDD) 3.5 Behavior Driven Development (BDD) 3.6 Crystal 3.7 Design Driven Development (D3) 3.8 Dynamic System Development Method (DSDM) 3.9 Eclipse Way Process 3.10 Evolutionary Process For Integrating Cots-Based Systems (EPIC) 3.11 Evolutionary Project Management & Product Development (EVO) 3.12 Extreme Programming (XP) 3.13 Feature Driven Development (FDD) 3.14 Iconix 3.15 Internet-Speed Development 3.16 Lean Software Development (LSD) 3.17 Microsoft Solutions Framework For Agile Software Development (MSF4ASD) 3.18 Mobile-D 3.19 Rapid Application Development (RAD) 3.20 Scrum 3.21 Test Driven Development (TDD) 3.22 Unified Process (UP) 3.23 Usability Driven Development (UDD) EVALUATION 4.1 Coverage of disciplines in software engineering 4.2 Profiles after evaluating the methods 4.3 Tables LINKS SUMMARY ABOUT BQI DISCLAIMER 4 5 5 5 7 9 9 10 11 12 13 14 15 17 17 19 20 25 29 31 32 36 37 37 38 40 41 46 49 49 52 58 68 70 71 73
5 6 7 8
foReWoRD
Rapidly growing business rivalry, shorten product life-cycles, high complexity as well as high expectations concerning quality lead to the fact that software should not only be innovative and useful. In order to stay competitive as a business company, applications have to be deployed more quickly to the user. User-requests that change very quickly should be answered short-termed. Thus, the development of software has to be carried out quickly, flexible, efficient and under compliance of a constant level of quality. Through these requirements, a variety of software engineering methods have been evolved over the course of the last years, which are categorized as agile in common sense. As a consequence consulting- and system house are faced with this subject upon its customers in growing extent. Either in the way that projects are already accomplished agile or in the way that customers are getting support from us during introducing appropriate method(s). As soon as you concern yourself about agile software development, you may recognize quickly that there are plenty of methods and that it is not easy to identify the ones that come into consideration for your objective. Therefore we designed this overview including a try of evaluating every single method. Despite knowing approximately in what we are getting into, when it came to inquiry we were surprised by the diversity of methods that are internationally existing. We had to limit ourselves in order to publish this survey as intended in 2010. Thus, a few methods we know will not be further discussed you will find a list of these in chapter 4. The authors wish the gentle reader as many new insights as the authors had them while researching. The BQIs Project Team
Berlin, June 2010
eXeCUTIVe sUMMaRY
This report addresses particularly these methods of agile software development, which have been internationally established until now. On the basis of public sources and documentation, 26 methods will be shown in the first part. In the second part, these methods will be evaluated by a series of criteria, which have been developed by our group of authors. It has been examined, which disciplines of software-engineering are covered, which types of projects are supported, if there are focuses concerning branches and if there are tools to the methods available. Furthermore, the level of normalization, standardization, certification, licensing and the support during adoption and use has been examined. Last, but not least the popularity and the level of dissemination with the help of predefined parameter has been included regarding to evaluation. The object of evaluation was to give the persons responsible during application-development a sort of compass to the phase of orientation before the adoption of agile methods. The figures at the chapter of evaluation are chosen in a way that the reader should be able to emerge two or three methods for more in-depth research, when he applies his own criteria of decision.
1 InTRoDUCTIon
Agile methods facilitate projects in software development more and more. According to Gartners Hype Cycle for Application Development (2008 and 2009), agile methods have been classified as Early Mainstream (see figure 1). Concluding, this methodology (in Gartner classified as technology) has already been used and worked out. Vendors, the method itself and the adoption of agile methods will evolve rapidly in the next years. Further, Gartner presumes it will take about five to ten years until the plateau of productivity is reached, in which agile methods will be accepted in most enterprises. From then on a substantial benefit will be recognizable. Yet the analysts do not arrive at an agreement completely. According to a contemporary study from Forrester, agile software development processes appear to be already established. However, what means agility in software development acutally? What characterizes agile software development? Which agile methods exist already? The Best Quality Institute and its team of international authors have concerned themselves with these issues intensely and summed up the achieved insights in this global study. Popular methods (like Scrum or Extreme Programming) as well as less known ones (like Iconix) have been analyzed. In order to gain a true benefit for the reader, at the end an evaluation in terms of different criteria takes place (see chapter 5).
Figure 1: Hype Cycle for Application Development 2008 (source: Gartner, Hype Cycle for Application Development 2008)
2 aGIlITY In sofTWaRe DeVeloPMenT

2.1
When the term Agility comes into ones mind, people think of mobility, adaptability and flexibility. Once it gets connected with the word software development, the question what does it mean basically? arises. Based on the manifest for agile software development the following points are relevant to the defintion: Early deployment of working software Customer-requests can be incorporated at any time Collaboration of the involved persons daily Face-to-face Communication among all involved persons The team is self-organizing The team achieves growing effectivity autonomously
DefInITIon aGIlITY
Agile software development takes changes as a chance to a competitive advantage in order to meet customers requests as flexible as possible and without a big bureaucratic overhead. This way a high customer-satisfaction can be achieved. The adaptability is crucial to the whole agile process it can lead to the point that changes have to be set up, if these changes appear to be reasonable, resulting in an advantage. Now agile software development can be defined as an software development process: which adopts new situations flexible, fast and without a big bureaucratic overhead that takes changes as advantage at which involved persons meet each other in face-to-face-communication and daily collaboration in which the project-team is self-organizing and responsible for growing effectivity in which customer requests can be incorporated at any time that deploys an operating software (not a prototype!) early
The agile manifesto (www.agilemanifesto.org) was founded in 2001 by Kent Beck, Martin Fowler and Ken Schwaber; it represents a new paradigm in software development. It describes a way off from rigid, inflexible and formal processes toward flexibility and communication. The agile manifesto encompasses four valuations and twelve principles. Those valuations are: Individuals and interactions override processes and tools. Viable products override expanded documentation Collaboration with the customer overrides contract Dwelling on changes overrides rigorous tracing of concepts
2.2
The aGIle ManIfesTo
The principles of the agile manifesto are: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
The agile manifesto is the foundation of agile software development. Agile procedure models apply on that foundation and implement the valuations and principles of the agile manifesto.
3 aGIle PRoCeDURe MoDels

During our substantial research many as agile named methods have been found. In the second list below you will find those methods that are indeed known to us, but which either do not fit to our scale or appear to be too exceptionally to be discussed here. List of the analyzed methods: ActiF Adaptive Software Development (ASD) Agile Enterprise (formerly X Breed) Agile Model Driven Development (AMDD) Behavior Driven Development (BDD) Crystal Design Driven Development (D3) Dynamic System Development Method (DSDM) Eclipse Way Process Evolutionary Process for integrating COTS-Based Systems (EPIC) Evolutionary Project Management & Product Development (EVO) Extreme Programming (XP) Feature Driven Development (FDD) Iconix Internet Speed Development Lean Software Development (LSD Microsoft Solutions Framework for agile Development (MSF4ASD) Mobile-D Rapid Application Development (RAD) Scrum Test Driven Development (TDD) Unified Process (UP) Usability Driven Development (UDD)
Agile, but not widespread methods: Universal Application UPXS
Concerning the following methods has been ascertained that these do not fit to our definition of agility (see chapter 3.1), hence can not be classified as agil and were not analyzed further: Pragmatic Programming: ~ is not an agile method, but a guideline to adopt these things from other methods, which appear to be reasonable. It goes back to the book Der Pragmatische Progammierer (the pragmatic programmer) from Andrew Hunt and David Thomas. Software-Expedition: ~ is not an agile method, but a dissertation in which it is examined to what extent the guiding principle of an expedition can lead to a better understanding of software development projects. Process Patterns:
~ represent a proven (pattern-)process that solve a frequently occurring problem. The problem embodies a concrete situation, which can arise during the software development. The process describes a bunch of activities that can be implemented to solve the problem. Catalysis: ~ is not an agile method, but an approach to shape on the foot of UML (see http://www.catalysis.org/index.html). Software Prototyping: ~ is not automatically agile it just tells us that it should be worked with prototypes. Software Craftsmanship ~ is not an agile method, but an extension of the agile manifesto concerning assertions to software handwerkskunst (software craftsmanship) (see http://manifesto.software-craftsmanship.org/)
3.1
aCTIf
ActiF is a procedure model concerning software planning and software development, which is supported by the product in-Step that comes from the same enterprise named microTOOL. It is grounded on an agile, iterative approach and is strongly driven by requirements. ActiF arranges the organized handling (allocation and administration) with tasks and responsabilities within a group of developers. ActiF is tailored to object-oriented development by UML in C# or Visual Basic .NET with Microsoft Visual Studio .NET. ActiF thereby provides a concrete process pattern to this development platform. It defines all activities and results, which may be found in an agile project in this technical environment. Wherever possible, ActiF offers machine-made templates for the results.
According to the developer of the ASD-Methodology James A. Highsmith III a software-developer team is a complex system, in which several persons work together to generate one solution. Generally it is believed that those complex systems need complex rules as well in order to work anyway. Yet Highsmith denies that and alleges that few, simple basic rules are sufficient. By his own admission, software development should be fun and, moreover, the best software emerges rather accidentally. He declares this phenomenon as Emergence, which is one of the most important signs to adaptive software development. Emergence is equal to realization of new ideas, solving problems as well as creativity in this context. In order to prevent a disorderly running project, ASD provides a framework including only just as many guidelines as needed not to displace Emergence. The focus of this method is more upon the results and the quality of these (component-orientation) than upon the tasks to be carried out or the process that is needed to achieve the objective (taskorientation). This is achieved by adaptive development-cycles. The foundation of every cycle is the waterfall-model with the following stages: Plan Build Implement
3.2
aDaPTIVe sofTWaRe DeVeloPMenT (asD)
These traditional stages are substituted in ASD by the following terms: Speculate Collaborate Learn
A greater acceptance to the agile approach shall be reached by renaming the stages. Thus, a plan is generally speaking as defined inexactly and every drift from the plan is considered as a mistake. By renaming Plan (plan) to Spekulation (speculation) an understanding shall be created, meaning a drift from the plan is nothing bad and that it can be used as advantage and chance. For this purpose, new approaches and ideas are welcome. Every cycle consists of the above mentioned stages. The result of every cycle is an executable piece of software.
sPeCUlaTe: In this stage the entire superior strategy of the procedure and objectives concerning the development cycle takes place. The basic conditions of this project are defined in the project mission, which already sets a rough framework for the end product. The whole development is controlled in a way that the project mission can be realized. WoRkInG ToGeTheR (CollaboRaTe): The cycles that have been envisaged in the prior stage speculate are translated and implemented here. Beneath highlighting the importance of team work, several components are developed simultaneously. The descriptions of the individual components are refined constantly to document new information immediately. leaRnInG (leaRn): If additional cycles shall be integrated, it can take place in this stage only. Other cycles are declared as Learning Loop. Quality assurance is the foundation, which focuses the functionality of the developed software. It can take place just in the presence of the customer.
10
Learning Loop
Project start
Figure 2: Adaptive Development Cycle (own chart, after Highsmith
Planning of adaptive cycles
Simultaneous development of components
Quality assurance
Final quality assurance & release
Speculate
Collaborate
Learn
X Breed was originally pictured by Mike Beedle and is a combination of Scrum and XP . Since Scrum is more management-oriented and XP rather technical, both models complement each other. Meanwhile X Breed has become Agile Enterprise. Agile Enterprise supports not only individual projects, but coordinates several projects in a company simultaneously that may rely on the same resources. Therefore Agile Enterprise applies techniques like the Scrum of ScrumsMeeting. However, it also entrenches more resources like the Global Backlock or the Shared Resources Team. Furthermore Agile Enterprise publicizes the use of Scrum when it comes to adoption of new business processes or modification of existing ones.
3.3
aGIle enTeRPRIse (foRMeRlY X bReeD)
AMDD is the agile version of Model-Driven-Software development (MDSD). The main difference between these two methods is the blue print of the models. In MDSD extensive models are being developed (for example in UML) before writing the source code, in AMDD the development of models with minimal effort (for example whiteboard) takes places in order to depict the most basic requirements first. The developed models shall just meet the current workload. In further iterations (Iterations Development), the basic requirements are being refined and optimized. The AMDD-Process is depicted in figure 3 and contains the following stages: enVIsIonInG: At the beginning of a project a close cooperation with stakeholders takes place in order to determine the most important basic requirements and to model the extent roughly. The system architecture is also modelled roughly to specify the technical direction. The entire model at this stage is less detailed and just sufficient. It is essential that the problem itself gets understood.
3.4
aGIle MoDel DRIVen DeVeloPMenT (aMDD)
11
Figure 3: AMDD Process (own chart)
DeVeloPMenT ITeRaTIons: At the beginning of each iteration, the team plans its work and prioritizes the requirements. By means of close cooperation between stakeholder and developer in every iteration new or extended requirements can be developed. The development is carried out by Test Driven Development (TDD). Release: Within this stage final- and acceptance-test is carried out to verify the functionality of the whole system. Any errors occurring will be corrected. End users are being trained to work with the system effectively. PRoDUCTIon: To keep the system maintained and to support the users handling is the aim in this stage. It ends when a system or the support expires.
Behavior Driven Development (BDD) was developed in 2003 by Dan North as an answer to Test Driven Development. BDD focuses to develop software that is relevant for users. Concerning the identification of requirements, the behaviour in the form of pre- and post condition is acquired as well as the user stories (scheme: As a <ROLE> I want <ACTION> so that <BENEFIT>). The means for this purpose is the scheme Given When Then, which can be described as pre condition action post condition. Thus, for a user story several scenarios with different boundary conditions can be created. They describe in a natural language the way the software will behave in each case. In the following you will find an example with a bancomat as an explanation. The user story for drawing a certain amount of money is:
3.5
behaVIoR DRIVen DeVeloPMenT (bDD)
Role
As customer
action
I want to withdraw money at the bancomat
Benefit
So that I dont need to line up at the counter
12
There are different scenarios that need to be considered, like Is the account balanced? Is the ec or credit card valid? These scenarios are described as below:
Given
If the account is balanced AND the credit card is valid AND the PIN is entered correctly AND the desk has enough money
When
WHEN the customer wants to withdraw money
Then
THEN check, if the account is balanced AND ensure that money will be paid out AND ensure that the credit card will be returned
As shown in this example, multiple conditions can be linked with AND. Once you described the requirements this way, the surface shall be developed at first. The surface is what the users see. It will be tuned and comply with the users feedback. Starting from the surface the rest of the application will be implemented step by step.
Crystal is not a single method for software development, but a collection of best practices in software development projects. Its developer, Alistair Cockburn, was ought to elaborate a method for object-oriented development in the early 1990s for the IBM Consulting Group. However, at that time there were no means of comparison at which the result could be oriented by.
3.6
CRYsTal
Fehler in Software bedeutet Gefahr fr:
Figure 4: ProjectClassification according to Crystal (own chart)
13
That is why Cockburn analyzed as many projects as possible and asked the relevant project teams, which things were crucial to the success or failure. He came to the surprising result that projects were completed successful, when the project team did not follow a fixed procedure, but simply communicated with each other regularly. The results remained consistently from 1991 to 1999, internationally as well as across various development languages. Cockburn consequently concluded that both each project and each team is unique and that there is no general approach. Based on that, a rough distinction of software development projects takes place in Crystal by the following sizes (see figure 4): Number of employees Criticality (impact of the failure) Priorities of the project (such as early delivery, governmental regulations)
The number of employees represents the number of project employees that should be coordinated. The criticality classifies, if the errors in the software affect the comfort of the user only (lowest level), the additional costs for the principal, the enterprises survival or if these errors may have even an impact on human lives (highest level). Priorities can be determined individually and as required. These dimensions facilitate both choosing the most appropriate method before the project begins and making adjustments during the project as required. Particular components, that could be chosen individually and assembled, thereby support the flexibility of this family of methods. Each single method within this family of methods is named by a color (Crystal Clear, Crystal Yel-
low, Crystal Orange, ) (see Figure 4). Thereto, Crystal defines just a few general guidelines and does not force the user to any specific course of action. Crystal simply points out the experience from various projects in which teams made some particular experience including the resulting consequences. The different techniques within crystal could differ strongly, but show the following common characteristics: The different techniques within crystal could differ strongly, but show the following common characteristics: The customer receives executable, intermediate versions of the software regularly (at least every quarter) Problems and differences (both within the team and to superiors) are discussed openly Ongoing search, collection and prioritization of improvement proposals Close communication (in the team and the customer) On the customer side an experienced employee must be accessible as a user of the product at any time Employees work targeted Use of version control (better: configuration management) Frequent (automated) testing of program code as well as Creating an executable test version regularly.
14
Design Driven Development (D3) was developed by Henry Jacob. Objective is to create innovative solutions. D3 is an agile process, which gives priority to the design of an application. The process can be applied independently, but also as a complement to other non-agile and agile methods. D3 is based on the following valuations: Abundance of design and dream-fulfillment is the new mantra for business success. Design is a fortuitous event that occurs during conception. Maximizing the likelihood of occurrence is key to innovation. No process can guarantee a better design. The creation of the right environment with the right people is the only way to yield innovations. Best designs are always the result of a continuous simplification and refinement. Customers and users often need support on understanding, description, visualization and organization their requirements. Figure 5 depicts the interaction between D3, Scrum and XP:
3.7
DesIGn DRIVen DeVeloPMenT (D3)
15
3.8
The Dynamic System Development Method (DSDM) was designed in the 90s in the UK by the DSDM Consortium, an association of IT companies. DSDM is an extension to the Rapid Application Developments (RAD) it pursues an iterative, incremental approach and emphasizes the continuous involvement of users. DSDM consists of nine principles, which need to be respected in a project. The nine principles are: The customer is actively involved in the work of the team. The power of decisions (at least in large parts) rests on the team. A regular supply of completed (partial-) products is aspired. Every (partial-) delivery must have a transaction value for the user, which is the relevant acceptance criterion (Business-Value-Driven). An iterative, incremental development is necessary to achieve an adequate solution. All changes during development are revocable or reversible. Requirements are fixed at a relatively high level. Testing is an integral part of the whole process. The cooperative collaboration among all involved persons is essential.
DYnaMIC sYsTeM DeVeloPMenT MeThoD (DsDM)
Figure 5: Interaction between D3, Scrum and XP
The process of development in DSDM encompasses seven phases. Depending on project constellation, individual phases may be omitted. Phase 1 - PRe-PRojeCT: The pre-project phase includes the project selection and the Go/ No-Go decision of a project. Phase 2 - feasIbIlITY sTUDY: In the feasibility study it is examined, whether DSDM is the most appropriate approach by the known surrounding conditions. Furthermore, the feasibility, the risks and the costs will roughly be analyzed. Phase 3 - bUsIness sTUDY: The business study serves the identification of affected processes and user groups, identifying the requirements and preparing a business case. Phase 4 - fUnCTIonal MoDel ITeRaTIon: Within the functional model iteration, based on the results of the Business Study, the product is specified, the architecture created and a prototype developed. Phase 5 - DesIGn anD bUIlD ITeRaTIon: The design and development of the system takes place in this phase. Phase 6 - IMPleMenTaTIon: The completed product is delivered to the users. Phase 7 - PosT-PRojeCT: In the Post-Project phase, it is examined whether, the system works effectively and efficiently. It is also analyzed, whether enhancements are needed. In addition DSDM uses the following core technologies: TIMe boXInG: Each iteration has a defined duration. Iterations can be characterized by various lengths and different phases. The MosCoW PRInCIPle: Requirements are classified into the following categories: Must have Should have Could have Wont have (This time not implemented, but earmarked for future implementation)
16
Within an iteration, requirements from different categories will be implemented. If within one iteration problems concerning the implementation arise, low-priority requirements could be removed from this iteration.
The latest version of DSDM is DSDM Atern (or just Atern). In this version, all IT-specifica have been removed from the procedure model so that this method is applicable even in non-IT projects.
The Eclipse Way process gets its name from the widely used open-source development environment Eclipse. It describes the way in which Eclipse is developed. It is a combination of agile methods, methods from the open-source development and techniques for work in large, distributed teams. Not shown in this figure are the basic elements: Iterative Incremental Reflection Adaptation Feedback
3.9
eClIPse WaY PRoCess
17
Figure 6: Techniques of Eclipse Way (source: http://www.ibm. com/developerworks/rational/library/edge/08/jul08/vanVelzen/)
The techniques of the Eclipse Way Process can be composed modular and are adaptable to the specific project condition. The Eclipse Way Process is very similar to the Open Unified Process.
3.10 eVolUTIonaRY PRoCess foR InTeGRaTInG CoTs-baseD sYsTeMs (ePIC)
COTS stands for Commercial off-the-shelf and is the english term for standard-software. This includes, in addition to classical standard-software, such as SAP , shareware/ freeware and prefabricated components. EPIC is an approach for the selection, adaptation and introduction of standard-software and has been developed at the Software Engineering Institute of Carnegie Mellon University in Pittsburgh.
Although the authors of the method do not talk about agility, the concepts of EPIC cover the valuations of the agile manifesto as well. Based on the Rational Unified Process (RUP), a framework has been developed that publicizes the integration of users, an iterative approach and the periodical deployment of results. The following figure depicts the course of an iteration:
18
Figure 7: Content of an iteration in EPIC
In reference to the RUP EPIC consists of the initialization phase, prepara, tion phase, elaboration phase, development phase and delivery phase. In each phase at least one iteration comes to pass. The further one progresses in the project, the more concrete the objectives and content gets, as the following figure illustrates:
Figure 8: Containment of the solution space in progressing time
3.11 eVolUTIonaRY PRojeCT ManaGeMenT & PRoDUCT DeVeloPMenT (eVo)
EVO was described in 1988 for the first time by Tom Gilb in his book Principles of Software Engineering Management, at that time named Evolutionary Development. Back then Gilb already recommended to create small, incremental releases or builds of software and to make them regularly and frequently availble to the customers. Planning should be dynamically in order to be able to take the feedback of users into account. EVO is characterized by the following properties: Tracking of multiple targets Early and frequent iterations Complete analysis, design, implementation and testing in each iteration User orientation Consideration of the entire system, not individual algorithms Open base-architecture Target-oriented, not (software development) process-oriented
Within EVO, the project is divided into small pieces (chunks), each chunk should include no more than 5% of the total expense. In doing so, those functions are developed first, which profit the most and are implemented easily. In the meantime, EVO was refined and afterwards renamed to Evolutionary Project Management & Product Development by Tom Gilb and his son Kai. The following figure shows the key elements of the current version of EVO: sTakeholDeR ValUes, PRoDUCT QUalITY ReQUIReMenTs UnD DeVeloPMenT ResoURCe bUDGeTs: Clarifying the requirements and the available resources.
19
Figure 9: Key elements of EVO
solUTIons: Ideas for solutions in order to satisfy the stakeholder values and product quality requirements with the available resources. IMPaCT esTIMaTIon: Mapping the ideas for solutions onto the stakeholder values, product qualities and development resources. Intention is to proof, whether the solutions concerning the stakeholder values and product quality requirements are sustainable and whether they can be implemented with the resources.
eVolUTIonaRY Plan: Initial rough plan of the sequence and the way, how one will achieve the stakeholder values and product quality requirements. The necessary detailing of the evolutionary plan is evolved together with the project during implementation. fUnCTIons: Description of what the system does. DefInITIons: Description of terms and concepts.
3.12 eXTReMe PRoGRaMMInG (XP)
Extreme Programming (XP) was developed in the mid 90s by Kent Beck, Ward Cunningham and Ron Jeffries. It is an iterative, incremental procedure model. XP is composed of valuations, principles, techniques and roles.
20
3.12.1 ValUaTIons
Communication Simplicity Courage Feedback Respect
The valuations of XP are:
CoMMUnICaTIon: Ongoing and intensive communication between the developer and with the customer facilitates ensuring fastest possible feedback, preventing unnecessary functionality, resolving emerging problems as quickly as possible and alleviating the problem of missing documentation. sIMPlICITY: The software should be desigend as simple as possible, no preparation of possible future extensions, no redundant or unnecessary functionality and no redundant structures are tolerated. Thereby, the system remains simple and maintainable. This is based on the assumption that it is more efficient to create something simple today and to invest a little more effort tomorrow to incorporate changes rather than to develop something complex today, which will not be used tomorrow or not in the anticipated form. CoURaGe: The implementation of principles and valuations requires courage. This includes communicating the truth about the project progress and efforts, not to look for excuses for failures and to accept changes whenever they occur. feeDbaCk: Many of todays (software development) projects fail due to misunderstandings between developers and users. Evolutionary development of the system in releases as little as possible and a permanent availability of customers facilitate quick feedback and thus a flexible control of the project progress. Another important source of feedback is the development of tests for different
levels (unit testing, test-stories) in order to check, whether the realized functionality is correct, solid and meets the given requirements. ResPeCT: Everyone gives and receives the respect he deserves as a team member. Each individual delivers its contribution to success, even if it is just enthusiasm. Developer respect the expertise of customers and vice versa.
3.12.2 PRInCIPles
The principles bridge between the abstract valuations and the specifically applicable practices. XP describes the following 13 principles: Humanity Efficiency Double-sided advantage Improvements Diversity Reflection Flow Accepting failures Perceiving occasions Quality Avoid duplications Small steps Accepted responsibility
21
hUManITY: Software is developed by humans. So people are the factor that should be given special attention according to XP . By creating a comfortable atmosphere, the basic needs of the developer (security, completion, identification with the group, perspective and understanding) shall be met. effICIenCY anD MUTUal benefIT: The developed software or a single functionality has to be efficient and nevertheless to yield a true value on the one hand. On the other hand, it must be beneficial for both sides and satisfying for all parties (development team and customer). IMPRoVeMenTs anD DIVeRsITY: The reuse of existing solutions is essential, which means for example accomplishing various different tests continually and automatically. Thereby, everyone gets straight that the first solutions are usually not the best ones. New insights gained by oneself through feedback shall lead to improved solutions. Recognizing better solutions day by day is only made possible by steady reflection and calling the respective approaches within the team continuously into question. The productivity of this proceeding increases proportionally to the heterogeneity of the team, which is constituted of varying skills and characters. Differing opinions are not only tolerated, but even encouraged. This requires a conflict management to be established. floW, ToleRaTInG faIlURes anD PeRCeIVInG oPPoRTUnITIes: The executability of software has to be guaranteed at any time. Although short iterations with continuous feedback facilitate keeping the project in a flow, nevertheless failures have to be taken into account. In the course of this, it is
quite usual and accepted to conduct an implementation that initially may not be optimal or even faulty. These difficulties have to be taken as opportunity and chance to ripen further both the product and the team. The more all involved persons are willingly to accept their responsibility, the better a straightforwardly, constructive dealing with the challenges of software development takes place. Charging a developer with an activity and a responsibility disciplinary is not enough, since he has to agree to that responsibility actively and to live it. QUalITY: Another important point is high quality, which is - in accordance to XP - in contrast to other factors like resources, features or expiry date, not under consideration. This basic attitude differs from many other methods of software development, where software has to be completed at a certain point of time and in a defined range of functions, among which almost always the software quality suffers. However, quality is crucial to hold the product usable, bug-free and expandable. Software with good design and high quality is medium-dated cheaper, more expendable and less buggy than fast developed, so-called Quick-and-dirty-software. aVoID DUPlICaTIon: The prevention of redundancy is part of good quality as well. These are automatable steps that have been executed unnecessarily multiple times or manually. sMall sTePs: Through quick, small steps the team remains adjustable and is able to adapt new surrounding conditions and to respond to feedback quickly. The negative consequences of a single, small step that has not been successful can be compensated much more quickly than in case of a single, major step.
22
3.12.3 TeChnIQUes

The following techniques are used in XP: Experimental game Small releases System metaphor Simple design Pair-programming Refactoring Continuous testing Collective Code-Ownership On-site customer Coding standards 40 hour week Continuous integration
eXPeRIMenTal GaMe: In the experimental game, available developer-resources are brought into line with customer requirements. Here it is decided, which functionality will be implemented next. Functions are prioritized and described as User Stories. Developers estimate the effort on user stories. Based on that, it is decided which functions are to be implemented newly.
sMall Releases: Start with the smallest meaningful extent of functions. Deliver early, frequently and add new features every time. sYsTeM MeTaPhoR: System metaphor is conceived as basic architecture of the system. This refers to the overall picture that all developers have in mind. Every developer does not only know a part or subsystem on which he works, but also the overall objective and the basic architecture that determine the system. sIMPle DesIGn: The most simple, possible design that meets the current requirements is selected always. The requirements change daily, so you should not do anything that you might need tomorrow. PaIR-PRoGRaMMInG: Two developers are working together on a computer. One of them is Driver, who develops and the other is the Follower, whose considerations are incorporated too. These roles are switched constantly. Thus, a review of code takes place at the same time as development. RefaCToRInG: By refactoring the internal structure of the program, improvement is achieved without changing behavior or functionality of the program. ConTInUoUs TesTInG: Before a developer implements a new function, he first writes a test for it (Test first). Typically, these are unit tests, which are grouped into test suites that run after each integration automatically. ColleCTIVe CoDe-oWneRshIP: The source code belongs to the whole team. Every developer should always be able to edit any of the code. on-sITe CUsToMeR: The development team is working at the customer site. Thus, an intensive cooperation and communication is possible. Developers get quick feedback on the provided release likewise PRoGRaMMInG GUIDelInes: The predetermined coding standards (e.g. naming conventions) have to be respected by all. Thus, the source code is consistent, which makes it easier to ensure that all developers can work anywhere. 40 hoUR Week: In the length of time, extra hours reduce motivation and productivity of developer. In exceptional circumstances extra hours are allowed. However, if it is getting a permanent condition, something concerning the process is going wrong. ConTInUoUs InTeGRaTIon: All changes are loaded to the code base at least once a day. The tests must run both before and after integration completely and correctly.
23
3.12.4 Roles

In a XP-project there are the following roles: Customer Developers Manager
CUsToMeR: The customer decides what creates an added value to him, prioritizes these points and then chooses what shall be implemented and what is to be put back. In addition, he defines tests that verify the functionality of the system (acceptance tests). DeVeloPeR: The developer estimates efforts and complexity of the user stories and controls pace that functionality is being developed and deployed with. ManaGeR: The manager makes up customers and developers and helps them to coalesce to a powerful team. PRoCess: The XP process is an iterative process, where the above-described techniques are repeated constantly. Figure 10 represent the complete frame of a XP-project.
24
Figure 10: The XP-Process (source: www.extremeprogramming. org)
An action within an iteration at that is the development. There the abovementioned techniques apply. Within an iteration the following actions (Figure 11) take place:
Figure 11: Process within an iteration in XP (source: www. extremeprogramming.org
3.13 feaTURe DRIVen DeVeloPMenT (fDD)
Feature Driven Development (FDD) was designed in 1997 by Jeff De Luca, Peter Coad as slim method for software development. As time went by the method was enhanced continuously. FDD puts the term Feature in center of development. At that a feature is defined as something useful in the eyes of the customer. Thus, each feature represents a value to the customer. The description of a feature according to the scheme looks like:
25
<action>
compute
<result>
the balance
<object>
of the account
Consequently, features are very fine-grained functions. Dependencies between the features often exist. Related features are grouped to so-called Feature Sets. The description of a Feature Set follows the pattern:
<action>
mak-
<-ing>
-ing
<object>
a product sale
In turn, Feature Sets are grouped to superior, professional groups the Major Feature Sets. The Major Feature Sets are described by the scheme: <object> management Example: product sale management For the implementation of these features FDD provides processes, roles and Best Practices.
3.13.1 Role MoDel
The role model subclassifies key roles, support roles and additional roles.
keY
Roles: Project-Manager Chief Architect Development Director (administrative support of the Chief-Programmer in their daily work) Chief-Programmer Class-Responsibles Experts (users, customers, sponsors, etc.)
sUPPoRTInG Roles: Domain-Manager (Head of domain experts in large teams, coincides mostly with Project-Manager) Release Manager (controls the project progress) Language Lawyer or Language Guru (a specialist in used programming-language or technology) Build Engineer Toolsmith (creates project-specific development tools) System-Administrator
26
aDDITIonal Roles: Testers Deployers (system installation and deployment, including data conversion) Technical Writers Typically - especially in small teams - employees occupy several roles
3.13.2 PRoCess MoDel

The process model consists of five processes: Development of the overall-model Creation of feature-list Planning of each feature Design of each feature Construction of each feature
The first three processes are usually passed only once. The last two processes, however, represent the realization of features and run in cycles.
Figure 12: FDD process flow (source: wikipedia
DeVeloPMenT of The oVeRall-MoDel: Aim of the first process is to reach a consensus concerning content and range of the system to be developed, as well as developing the technical core model. Thereto, experts and developers define content and range of the system, led by the chief architect. In small groups technical models for the different system-areas are developed, which will be presented in the group, eventually revised and finally integrated.
CReaTIon of feaTURe-lIsT: In the second process, the previously specified system-areas the features will be defined. In this process the aforementioned three-step scheme (Major Feature Sets, Feature Sets and Features) is used. The implementation of a feature may not take longer than two weeks. The result of this second process is a categorized feature-list, whose categories come onto top level from the experts of process # 1. PlannInG PeR feaTURe: In the third process, the Project-Manager, the Development Director and the Chief Programmer are planning the order the features shall be realized. Thereto, they comply with dependencies between features, workload of the developing team and the complexity of the features. Based on the plan, the completion dates for each business activity will be defined. Each business activity gets a chief-programmer as owner assigned. Moreover, for known core classes developers will be set as owner (Class Owner List). DRafT of eaCh feaTURe: The chief programmer analyzes its associated feature and puts, on the basis of the involved classes, the feature team together. A Domain Walkthrough is executed, the object model refined, the design of the Feature Set fixed and finally reviewed during an inspection. ConsTRUCTIon foR eaCh feaTURe: In the fifth process, the developers code the features that have been prepared in the fourth process. During programming, component tests and code inspections will take place for the purpose of quality assurance. FDD makes no fixings concerning iterations beyond incremental development per feature. Yet for larger projects, it is useful to define formal milestones, by those parts of the final product may be presented. Thus, one is able to document the progress even by executable code.
27
3.13.3 besT PRaCTICes
Best Practices are methods and procedures that have been proven in many projects. FDD allows the use for the following Best Practices: Domain Object Modeling Developing by Feature Individual Class (Code) Ownership Feature Teams Inspections Regular Builds Configuration Management Visibility of Progress and Results
DoMaIn objeCT MoDelInG: At the beginning of each project, it is about getting an overview as good as possible about the problem area. For this purpose, FDD includes the production of a Domain Object Model. The Domain Object Model thereby encompasses only those business objects that are usually persistent. GUIs and Control-
Objects do not matter at this stage - these would make the view onto the Business Object Model more difficult. DeVeloPInG bY feaTURe: Features are small and manageable units that are realizable in no more than two weeks. Each function that is too complex to be realized in that time, will be detailed as long as an appropriate size is reached. This facilitates delivering correct functionality and extending or modifying the system more easily. InDIVIDUal Class (CoDe) oWneRshIP: In contrast to Collective Code Ownership (all developers are jointly responsible for the code base, as for example XP), FDD propagates Individual Code Ownership. So there are dedicated persons in charge to individual pieces of source code. Those responsible persons are in charge concerning consistency, performance and conceptual integrity of their code. feaTURe TeaMs: Feature teams are teams that come together dynamically to implement features. Thus, various design proposals will be discussed at implementation, before a commitment onto a certain design follows. InsPeCTIons: As a step of quality assurance, FDD envisions inspections. Here, development results of other team members are being assessed and reviewed. This conduces improvement of code base on the one hand, on the other hand knowledge transfer between team members will be aided. Inspections also help to promote effective enforcement of coding standards. Within the scope of FDD, code inspections are typically done in the context of feature teams, whereas the Chief-Programmer as the leading team member determines the level of formality of such an inspection. FDD has no built-in test, as it has become popular through XPs Test First for example. That does not mean that this practice in context of FDD would not be useful or not assimilable. It is just not imperatively required. In general, it is referenced to the existing quality assurance processes within the organisation concerning the issue of testing. Each developer should run his own SmokeTest with his coded components. ReGUlaR bUIlDs: Regularly compiled builds of the entire product serve for one thing the visibility of project progress - linked to executable code - and for another thing (especially in large projects) the prevention of dramatic integration problems. There is no frequency specified in terms of these builds in FDD. Depending on the project, a weekly, daily or even a continuous build-process could be the best choice. FDD requires only that the build takes place regularly. In doubt, a short cycle is the better choice. ConfIGURaTIon ManaGeMenT: Each project should have a configuration management, independently of a process model. Configuration management is central basis for project results and thus the Single Point of Truth. In principle, all artifacts created in the project (analysis, design, code, test cases, etc.) are subject to configuration management.
28
VIsIbIlITY of PRoGRess anD ResUlTs: Continuous tuning of the project process requires a quickly and fine-grained visible project progress. The degree of granularity is, in turn, the single feature. Thereto, FDD proposes a simple report-format based on Mini-milestones. The following six milestones are set as each feature is being developed: Domain Walkthrough Design Design Inspection Code Code Inspection Promote to Build
Every single milestone is defined in a way that its achievement is a binary decision. The domain walkthrough is complete, the design is created, the design is inspected, the code is created, the code is inspected, the code is approved for the next build. In order to achieve milestones, a certain percentage of the total cost is attached to the creation of each feature set. Feature-specific estimations are not considered during this step, but default values that are in accordance with previous experiences within the organization. In their book A Practical Guide to Feature Driven Development, Palmer and Felsing recommend the following starting values:
29
Design by feature
Domain Walkththrough 1% Design 40% Design Inspection 3%
build by feature
Code 45% Code Inspection 10% Promote to Build 1%
Based on that, for every single feature a percentual level of completion can be calculated. This level may not seem to be entirely correct, but as features are fine-grained requirements (hence small), the faults are mostly small and negligible. On the same basis, the plans are drawn by each team (or the responsible Chief-Programmer) via estimating as long as it will take to complete the feature. Detailed planning of each milestone will be carried out in compliance with the above-mentioned scheme.
As RUP (Rational Unified Process), Iconix represents a UML-based software development method that indeed is much more lightweight1 as RUP . The Iconix-process generally consists of four phases (see figure 13) and uses a total
3.14 IConIX
1 Before the agile manifesto (2001) existed, the term lightweight was used instead of agile. Both terms are to be understood as synonyms
of four diagrams based on UML (Use Case, Sequence, Domain, Class) in order to transfer prioritized uscases to executable code through iterations. In each phase a validation of previously completed work takes place, followed by an adjustment as far as needed. ReQUIReMenTs: Functional requirements upon the system are gathered at first. So as to create a common vocabulary for clear communication between the team members, a dictionary will be set up (Domain Modeling). Goal is to ensure that each
30
Figure 13: Iconix Process (own chart)
member in the project understands the problem area without doubt. Moreover, the dictionary defines the extent and shapes foundation for use cases. At the end of this phase, it is ensured that the description of use cases match the customers expectations. Validation of use cases takes place in small bundles in order to prioritize them and afterwards to design them in the next step (Analysis/ Preliminary Design). analYsIs / PRelIMInaRY DesIGn: In this phase, the development strategy is set. Thus, assumptions concerning design as well as technical architecture are made. Potential errors within the use case descriptions shall be identified by the Robustness Analysis. In doing so, missing classes become apparent, ambiguities can be corrected and attributes are added to the Domain-Objects. Afterwards, the domain model shall be updated. Before switching to the next phase, another validation of the work performed in this phase is carried out. DeTaIleD DesIGn: Since in the previous phase a development strategy has been defined only, it will be implemented here. Domain model and use case descriptions are used to design the system. Thus, the domain model is converted to a class diagram (Class). Use case descriptions are used to compile sequence diagrams (Sequence). At the end of this phase, a validation takes place too. IMPleMenTaTIon: Based on previous phases, the programming of both software and unit tests now takes place. Thereto, class diagrams - as well as sequence diagrams - will be used as guidelines. The actual development takes place in compliance with Test Driven Development (TDD). The levels Analysis / Preliminary Design, Detailed Design and implementation will be run through until the software meets the desired customer requirements
Internet-Speed Development was developed in the late 90s. It is a combination of the waterfall model and spiral model. When the method was developed, aim was to carry out the acutal development in a structured way on the one hand, and to uphold required flexibility to be able to act on changes on the other. The following figure shows the flow of Internet-Speed Development: Internet-Speed Development is an iterative procedure, whose in each iteration the phases Envisioning, Planning, Developing, Stabilizing and Deploying are passed through. At the end of an iteration an executable version of software is ready.
3.15 InTeRneT-sPeeD DeVeloPMenT
31
Figure 14: The phase-model of the Internet-Speed Development
The contents of each phase are: enVIsIonInG: During Envisioning phase the requirements are analyzed, scope is defined and risks are identified. PlannInG: In the Planning phase, a functional specification, a rough design and a planning is created. DeVeloPInG: In the Development phase, the functions are realized. sTabIlIzInG: During Stabilization phase, the fully developed features are tested and errors corrected. DePloYInG: In the deployment phase, the system is installed and activated.
Lean Software Development was developed in 2003 by Mary and Tom Poppendieck, whereby Lean Development served as a model. Lean Development led to far reaching changes primarily in the automotive industry. They realized great similarities between the ideas from product development and agile methods in software development. Lean Software Development has seven principles which are transformed by means of 22 approaches. The seven principles are: Avoiding waste Support learning Deciding as late as possible Deploying as early as possible Giving responsibility to the team Incorporate integrity Seeing the Whole
3.16 lean sofTWaRe DeVeloPMenT (lsD)
32
aVoIDInG WasTe: Anything that provides no added value to the customer is waste. This may be a feature nobody uses or documents which remain unread in a cupboard. In order to avoid waste, you have to recognize it at first. This is the first action in Lean Software Development as well: recognizing waste. The following seven points are classical sources of waste, according to which one should look for in the project: Incomplete work: Incomplete software provides no added value. Either it is lying and completed later (which causes induction expenses), or it will never be completed. Unnecessary processes: Any unnecessary setting during development process is waste. This insight is also known in the Crystal method. Unnecessary features: Features not needed by the customer are waste. Switching developers: Developers often work in several projects simultaneously. The persistent switching between projects is borne by productivity. Waiting: Any kind of waiting is waste - no matter whether the tester is waiting for the development or the whole team for procurement of a special tool. Movement: How many stations have to be crossed to find out who can help one with a problem? How often has an issue to be moved from one person in charge to the next until it creates added value? Each avoidable movement is waste. Bugs/ Failures: Unfortunately, bugs can not be completely avoided. They can be very expensive, in worst case even cost human lives. Therefore, mechanisms must be provided so that emerging bugs or failures can not hurt people.
Management: A written status report that is created every day is as well as waste of time than recording of worked time that is controlled by nobody. Same is true for the technical management - over-engineering of architectures is waste. Another approach to avoid waste are value chains. Based on the added value for the customer, each activity that contributes to a certain added value is located in a sketch. This helps to examine all steps of a development process concerning the value they provide. If one step only provides low to no value, he will be dropped. sUPPoRT leaRnInG: In the course of a project all parties learn - both the customer and the developers. This is greatly desired and should be supported. One aid to this is feedback. Feedback is a quick response on work outcomes. In this way, for example, one can try different variants directly in the source code and will receive feedback about the running ability immediately - instead of large-scale architecture- and design documents. And instead of gathering requirements completely, it is better to design a few screens and discuss them with the customer. In order to apply feedback purposefully, iteration is used. By regular provision of executable software, one is able to obtain appropriate feedback from the customer. Thereby, iterations might differ in length. However, it is important to keep in mind that iterations are Time-boxed, which means that the final date is fixed. If a bottleneck arises, extent of the respective iteration is changed, not the final date. The Set based Design acts as a further aid to support learning. The idea behind is to keep as many alternatives as long as possible open. The commitment to an alternative is not made until in ones view is learned enough to make a decision. This also aids a further principle of Lean Software Developments, namely, to decide as late as possible. DeCIDInG as laTe as PossIble: In Lean Software Development it is postulated to make a decision as late as possible. Before then, the development in all affected areas is fostered, until one has gathered the required information to make the right decision. In particular, professional analysis, architecture, design and implementation are fostered parallel. This is known as Concurrent Development. A supporting way is thinking in options. As long as one does not have all the necessary information to make a decision, one does not commit oneself and leaves different options open. Those who think in options, are thus capable of delaying decisions. It is, however, equally important to recognize the right time for a decision. This is the next resource, the latest possible moment. The right time for a decision is when one might block an important alternative otherwise. This should not just happen, but by a conscious decision. Making decisions is also another resource of Lean Software Development. Decisions are taken by experience and with gut instinct. In doing so, it is very important to involve all those people that have to be part of implementation.
33
DePloYInG as eaRlY as PossIble: Delaying decisions affect not only technical decisions. Even the professional choices should not be made until the professionals have understood the implications clearly. In many cases, all involved persons need to have experience with executable software. Hence, it is necessary to deliver software as early as possible, which makes high demands to the task management. Thereto, resources exist as well. Such is the pull system, where upcoming activities will be collected as in a card index. The activities are prioritized, the developer take tasks out of this box by priority and their own abilities. Regular (daily) meetings take place to support coordinating the tasks. By some sort of black board it is made transparent, who is working at which tasks and which ones are to be developed next. The Pull System can be regarded as a chain of queues. The Queuing theory is a resource of Lean Software Development. The queuing theory is a branch of systemic thinking. There are several optimization methods to queues. The costs of delays are also a resource. Rapid development is not always the more favorable alternative. It may be necessary to purchase expensive tools that cost more than the possible saved working time. In such decisions, Lean Software Development recommends to consider not only the direct savings, but also the costs for a delayed delivery. Business management teaches that the costs for missed market opportunities overlie development costs far above all. GIVInG ResPonsIbIlITY To The TeaM: Lean Software Development promotes the idea of transferring responsibility to the team as one of the biggest motivators. In order to motivate the team, Lean Software Development provides the approach that the team may determine its goals itself. Objectives that have been specified by themselves are to be achieved more often than ones which come from others. However, self-set goals are not yet sufficient. Team members must be motivated too. Often, it is tried to motivate employees with rewards (usually financial). But this affects only the external motivation. In order to achieve a genuine internal motivation, it is necessary to address the following factors in accordance with motivation researchers: Membership Security Expertise Visible progress
34
But you need more: Leadership. A leading personality helps the team to find direction and to organize the environmental work situation, which is needed to successful work. It protects the team against interferences from the outside, without interfering the necessary information flow. Leadership leads to a good team that is able to fight a crisis successfully, if it should slip in there once.
InCoRPoRaTe InTeGRITY: Integrity of a system means that this forms a coherent whole. Lean Software Development distinguishes between internal, conceptual integrity and external, perceived integrity. The conceptual integrity describes the technical structure of the system. Is the architecture both understandable and extensible? Is it possible to build in new features without problems? Is the design consistent? The perceived integrity, however, is a characteristic of the user interface. Does the user interface use as few as possible and catchy metaphors? Is an appropiate level concerning the ease of use reached? If same things appear, are they named equally? Integrity can not be included initially. As a text has to be read again and again in order to be correct, a user interface or a design also has to be checked critically and changed, especially since integrity is usually not a big issue at the beginning of a project. It is not critical until changes occur that oversize the planned extent. In particular, the attempt to incorporate those changes - without touching the existing code preferably - lead to backpacks, spaghetti code and ultimately to the death of the project. Thus, the next important item is the perceived integrity. A close cooperation between developers and users is basic requirement to enable users perceived integrity, when they work with a system. The better this communication works, the more easily wrong decisions can be detected and corrected. By short iterations with executable software, this coordination works best. For more complex tasks, earlier coordination may make sense. In addition to the perceived integrity, the conceptual integrity is of importance. The best perceived integrity will hardly to be uphold in the length of time, if it is sheer a big front, and if it reflects no internal conceptual integrity. Ensuring the internal conceptual integrity is the main task of the Master Developer. Therefore, above all, the communication within the team has to work. However, software that comes incrementally loses its conceptual integrity over time. To counteract that, a further methodology is applied: The refactoring. This point was already discussed in section 4.12 Extreme Programming (XP). Another, already well-known resource for ensuring the integrity is automated testing. Besides securing the code quality and the stability towards changes, automated tests answer the following purposes as well: Communication of requirements Feedback Skeleton for further methodologies, such as for example Refactoring Documentation Maintainability
35
seeInG The Whole: Project management is not just about quality, time, scope and costs. All these points are important. However, none of these points can be applied singularly.
A successful project manager needs to see the whole thing: the various individual interests of customers, employees and suppliers, the many professional and technical factors and the inner dynamic of a project. They are all closely intertwined. They do not shape simple cause-effect chains, but a complex system including feedback loops, delays and unpredictable events. Understanding these correlations and influencing them is the essential task of each project manager. Measurement serves as a basis in fulfilling this task . However, herewith is not meant to apply highly complex, meaningless metrics, but to oberservate the project consciously in general and to interpret the apparent project progess. Simple key figures, such as e.g. the number of open errors, are absolutely sufficient. Drawing a bow to cooperation, one resource remains: the contracts. Contracts serve as a basis for mainly two purposes. First, they are the foundation to cooperation and secondly, they allocate the responsibility to the contracting parties.
36
A method similar to Lean Software Development is Kanban. Kanban was developed in 2007 by David Anderson and is based on the principles of Lean Development too. The method relies on a limitation of the Work in Progress (WiP), whereupon no more than a defined set of requirements may be implemented at the same time. A visualization of the WiP , e.g. on a whiteboard, makes visible where bottlenecks are in the processing. By eliminating the bottlenecks an improvement of the flow path is achieved. Since Kanban and Lean Software Development are elsewhere very similar, in the further progress of this study Kanban will not be explicitly addressed.
The Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts and guidelines for IT-projects. A specific process model is not given by default - it can be applied both for the classical developing as well as for agile approaches. The Microsoft Solutions Framework for Agile Software Development (MSF4ASD) is a particular expression of the MSF, just for agile development. Thereby it is about a template for the Visual Studio Team System (VSTS). Product definition, development and testing are processed in overlapping iterations with the aim of completing the project incrementally. Each iteration has a slightly different focus, such as the following figure shows. Furthermore, MSF4ASD provides a variety of principles, roles and ways of thinking, which are based on the agile manifesto. Similarly, many types of results are pre-defined to which the template for the VSTS includes examples and templates for the given situation.
3.17 MICRosofT solUTIons fRaMeWoRk foR aGIle sofTWaRe DeVeloPMenT (Msf4asD)
Figure 15: Contents of iterations in MSF4ASD
Mobile-D is the agile methode for mobile application development of the Finnish research-organisation VTT. The method includes the phases Explore Initialize (iteration 0) Productionize Stabilize System Test & Fix
3.18 MobIle-D
37
The phases Productionize, Stabilize and System Test & Fix run iteratively and include each of the steps Planning Day, Working Day and Release Day. The sequence within a phase is shown in Figure 16.
3.19 RaPID aPPlICaTIon DeVeloPMenT (RaD)
Figure 16: The end of a phase in Mobile-D
The rapid application development is to ascribed to an idea by Brian Gallagher, Alex Balchin, Barry Boehm and Scott Shultz by the 1980s, in order to make the heavy software development methods developed from the 1970s more flexible. The term RAD thereby was not popular until the early 1990s. James Martin developed a method based on iterative development of prototypes, while IBM published a book called Rapid Application Development in 1991. As shown in figure 17, the process starts with a discussion including all parties to create a rough list of basic requirements and prioritize them. Both developers and customers may have conversations with each other, as opposed to further discussions. Based on the list of basic requirements, developers design a working prototype of the software as soon as possible according to
the relevance of priorities. They may use a software building kit so as to assemble the most important basic requirements quickly. After completion of the first prototype, a test by the customer takes place. He adds further requirements and refines existing requirements. In a further meeting, the agent shall notify the principle concerning enhanced and/or new requirements. This meeting shall thereby rather be performed as a monologue of the agent.
Figure 17: RAD process (Source: http://blog.twinklesprings.com)
38
The new requirements are optimized in a short development cycle (from one day to three weeks) and added to the software. This iteration is repeated until the software with all properties desired by the customer is present. This approach creates in each iteration new, improved versions of the software. By minimal planning in advance and planning parallel to development, RAD promises operational software in less than 120 days.
3.20 sCRUM
As early as in the 1980s, it was looked for more flexible approaches in software development. Scrum is an agile framework both for the software development as well as for project management. Based on Lean Production, it was designed by Ken Schwaber, Jeff Sutherland and Mike Beedle. Both methods, Lean Production and Scrum, focus the continuous development (employees, processes, resources, methods) with the aim of ongoing production improvement so as to reach highest quality with minimal effort. In Scrum, there is the cardinal hypothesis that production assembly as well as development processes are suchlike extensive that particular phases and steps can not be planned in advance. However, if a team organizes itself in compliance with fixed presettings, this will lead to more effectiveness. Scrum uses its own vocabulary to known standard terms. For that reason, the most significant terms will be explained hereinafter. Three roles are involved directly in the process.
PRoDUCT oWneR: The Product Owner shall provide the agent role and is placed in general by the department. He writes and prioritize the requirements and determines their order. He is available to the team for information and is responsible for the success of the project likewise.
3.20.1 Roles
sCRUM MasTeR: As a coach and facilitator of the team, the Scrum Master makes sure that the scrum rules are sticked to. He manages the entire process, eliminates disorders and works closely with the Product Owner together in order to shape the project as value-adding as possible for the company. Moreover, he helps the team to increase its productivity. TeaM: There are people with different expertise involved to the development of the product within the team. The team has all the qualifications needed to transfer the defined requirements in functionality.
3.20.2 MaIn eleMenTs
PRoDUCT baCkloG: The product backlog shows all the properties of the product to be developed in a prioritized list. These requirements can be removed and new requirements added. The processing of requirements is carried out in decreasing order of priority. sPRInT: Fixed cycle (iteration) in two to four weeks usually, within the product is developed. At the end of each sprint, a functional increment can be deployed. Yet in order to gain real added value to the company, usually several sprints are necessary. sPRInT baCkloG: The Sprint Backlog defines the work scope of the team for each individual sprint. It contains the selected requirements from the Product Backlog. In addition, a summary of all tasks to be developed is compiled regularly so as to achieve the goal of the sprint. DaIlY sCRUM: A to 15 minutes limited meeting, which takes place every day. Regular communication serves the exchange of information among each other related to: Status quo Future tasks Problems occured
39
In a list (Product Backlog) requirements are added, completed and prioritized. In collaboration with the Product Owner, the higher prioritizied requirements of the Product Backlog are extracted regularly by the team and during an iteration (Sprint) completely implemented. Parts of the Product Backlog that have not been extracted so far may be prioritized again by the Product Owner for subsequent sprints. During Sprint, the team works focused and without interferences in order to transfer the requirements of the Sprint Backlog in a completely finished and potentially productive, operating application part (Potentially Shippable Functionality). A to 15 minutes limited Information meeting (Daily Scrum) takes place every day to assure that all team members reach the same level of knowledge and to proactively point to potential problems. At the end of the
3.20.3 oPeRaTIonal seQUenCe DesCRIPTIon
Sprint, the team demonstrates all involved persons the fully developed and executable properties on the system in real time (Sprint Review Meeting). Reactions of participants and new requirements are incorporated into the next Sprint Planning Meeting, which is to be held before each sprint. The process (see figure 18) will be passed through again.
40
Figure 18: Scrum Process
The traditional software development proposes implementing customer requirements first in phases and to test independently at the end. The tests are created either parallel to the development of software or only at the end of development. TDD reverses this procedure. Before coding, the programmer thinks about the requirements the software has to meet and which tests are appropiate. Based on the tests, the actual programming is done gradually in short, iterative cycles. Any cycle traversed optimizes the software to additional properties. This procedure is executed the following way: 1sT: CReaTInG a TesT A new test is generated to each new feature a customer requires related to the software. In order to create a test, the developer has to clearly understand the customers requirements or special features of the software. 2nD: eXeCUTInG a TesT (1) By the first test run, the programming is not to be checked, since no single line of code was written. The first test run is used for the functional validation of the testing environment and to ensure that the test runs itself and provides the expected result error.
3.21 TesT DRIVen DeVeloPMenT (TDD)
3RD: WRITInG/ fITTInG CoDe: After the first test, the code is being written with as little effort as possible in order to just pass the next test. Additional functionality of future phases should not be anticipated. The written code in present condition is not perfect, but is optimized in the next passes.
41
Figure 19: Test Driven Development Lifecycle (own presentation)
4Th: eXeCUTInG a TesT (2) When the code is written or adjusted, a test run takes place again. The third and fourth step thereby will be looped, until all test cases are passed for the programmed unit. Developers now can be confidently that the code meets all the tested requirements. 5Th: RefaCToRInG In the last step, the code is simplified by refactoring, eliminating redundancy and making it comprehensible. At the end of refactoring, it is recommended to execute a last test run in order to ensure that no existing functionality has been damaged by refactoring. Figure 19 illustrates the entire process. The development of a software is structured in different units. Each unit passes through the lifecycle. The stages three and four (Writing/ fitting code, executing a test) are repeated, until the desired functionality of a unit is reached, all errors have been eliminated and the developer can not think of more reasonable tests. The process will be passed through by each unit. TDD is no test method, but a software development method.
The Unified Process (UP) is a popular process framework. The most known realization is the Rational Unified Process (RUP). However, there are other variants of the UP . The common foundation of all realizations of UP is: DeVeloPMenT Phases: The development is divided into phases. The UP resembles the following phases:
3.22 UnIfIeD PRoCess (UP)
Inception Elaboration Construction Transition
Some variants of the UP extend this phase model. DIsCIPlInes: The following disciplines are processed in a software development project: Business Modeling Requirements Analysis and Design Implementation Test Deployment
Over the phases, the cost distribution concerning the disciplines is represented in the following figure 20.
42
ITeRaTIVe anD InCReMenTal: Within the phases, project results are progressed iteratively and incrementally. Use Case DRIVen: In order to document the functional requirements, use cases will be employed.
Figure 20: Cost distribution of the different disciplines about the phases of the UP (source: Wikipedia)
aRChITeCTURe-CenTeReD: UP focuses the efforts in the design of a system-architecture.
RIsk-foCUseD: Risks are addressed early within UP . The results of each phase are selected in a way that points with the highest risks are progessed first. The following realizations of the Unified Process exist: Agile Unified Process (AUP): A lightweight version by Scott W. Ambler Essential Unified Process (EssUP): A lightweight version by Ivar Jacobson Open Unified Process (OpenUP): The development process of the Eclipse Process Frameworks Rational Unified Process (RUP): The development process of the company Rational (now IBM) Rational Unified Process-System Engineering (RUP-SE): Adaptation of RUP for systems engineering Enterprise Unified Process (EUP) An extension to the RUP at phases for the entire lifecycle of software (operating and phase-out) Oracle Unified Method (OUM): The development process of the Oracle company
The Unified Process and its most famous realization, the Rational Unified Process, are no agile process models. The same is true of the Rational Unified Process for system engineering, the Enterprise Unified Process and the Oracle Unified Method. In the following, only those variants of the UP will be considered in more detail, which support the agile methodology.
43
3.22.1 aGIle UnIfIeD PRoCess (aUP)
Figure 21: Phases and disciplines of the Agile Unified Process (source: www.ambysoft. com)
The Agile Unified Process (AUP) is a simplified version of the Rational Unified Process and was developed by Scott W. Ambler. The goal is to facilitate agility within the framework of RUP . Therefore, the disciplines Business Modeling, Requirements and Analysis and design have been aggregated to Model. As
shown in figure 21, this discipline takes significantly less effort to complete. In this case, it is sufficient that models are just good enough for the project. AUP distinguishes between iterations in Development Releases and in Production Releases as well: Development releases are deployed in a QA- and/ or demo environment. A production release, on the other hand, goes in production. Even though not all releases are going to be in production, all releases will be targeted as executable results. The AUP is thereby based on the following principles: The whole team knows what it does Simplicity Agility (within the meaning of the agile manifesto) Focus on current tasks Tool independence Possibilty of tailoring the method
44
3.22.2 essenTIal UnIfIeD PRoCess (essUP)
The Essential Unified Process (EssUP) was developed by Ivar Jacobson as an improvement to the Rational Unified Process. It identifies practices such as use cases, Architecture Driven Development, team practices and process practices borrowed from CMMI, RUP and agile development. From all these practices, one can now take those, which are appropiate for the concrete situation and merge them to a separate process.
The Open Unified Process (OpenUP) is a lean realization of the Unified Process, which provides iterative, incremental approaches in a structured life cycle. It is part of the Eclipse Process Framework, an Open Source Process Framework of the Eclipse Foundation. The OpenUP is based on four basic principles: Cooperation in favor of common understanding and balance of interests Competing priorities are balanced to the highest user benefits Early focus to the architecture to minimize risks and to guide development Continuous feedback and improvement
3.22.3 oPen UnIfIeD PRoCess (oPenUP)
The content of the OpenUP is divided into three areas: Personal area: Encompasses the work of each individual as a microincrement Team area: The whole team develops operating software within one iteration Stakeholder area: Encompasses the full project life cycle
DIsCIPlInes: As all representatives of the Unified Process, OpenUP encompasses different disciplines as well. These are: Requirements Architecture Development Test Project Management Configuration and Change Management
45
Figure 22: Content areas of the OpenUP (Source: http://epf.eclipse.org/wikis/openup/)
The project life cycle of an OpenUP project is depicted below in figure 23.
Figure 23: Project Life Cycle under OpenUP (source:http://www.eclipse. org/epf/general/OpenUP . pdf)
3.23 UsabIlITY DRIVen DeVeloPMenT (UDD)
Usability Driven Development (User Interface Driven Develpoment or UI-First Software Development likewise) is an iterative development process that centers the usability of a system. Extreme Programming serves as a model - it has been extended with elements of the User Centered Design. Each iteration consists of nine phases in UDD: Experimental game Cost estimation Interface design Modeling Test design Programming Integration Deployment Usability Test
The sequence of phases is shown in figure 24.
46
Figure 24: End of an iteration in UDD (source: http://www. jensjaeger.com/tag/usabilitydrivendevelopment/)
Programming
Phase 1 - eXPeRIMenTal GaMe: The development of software in accord with UDD begins with an experimental game. The customer or a team member of the business side notes all the tasks the system should be able to handle in terms of story cards. These story cards are ordered as per priority and developed according to that order. The experimental game is repeated at each iteration. This gives the customer the ability to change prioritization in each iteration and to add completely new story cards. More story cards will be added by usability tests taken place in the course of development. These have got to be prioritized by the customer likewise. Phase 2 - CosT esTIMaTIon: Each developer takes story cards, which encompass the work to be done until the next experimental game. Here, the cost estimation is done by the developers themselves. The actual times with the estimated target times are compa-
red after each iteration. This results in a better basis for further estimates in the course of a project. Phase 3 - InTeRfaCe DesIGn: Compared to the design of interfaces, programming is very complex and only difficultly alterable. Hence, in UDD the GUI of an application is considered first. Shaping the surface of software is relatively easy. A sketch on a sheet of paper is made quickly and altered easily. Another important reason to design the interface first is that the surface is what users get to see. It will be difficult to attract customers with an application software, which has great features, but an unattractive surface. In case of extensions or extensive changes concerning the surface, it shall be made use of the option to jump in the phase of usability testing. Thus, the drafted design will be examined and possibly improved, before too much work has been invested. Phase 4 - MoDellInG: Once the surface of a function is designed, the phase of modelling begins. An overview explaining the way the new functionality may be integrated in the whole system shall be created within the modelling. What database fields are needed, where in the layer model the function is to be implemented, which library functions can be used, which algorithms are most suitable for the solution of problems? These questions should be asked and answered by the developers. If in doubt, the views of colleagues will be obtained or if possible, a test will be developed. A load test can be quite revealing, especially in case of performance issues. In this stage it is not about describing the functionality to be developed down to the last detail with UML charts. Charts should only be used, where it is useful and thus creating benefit. Phase 5 - TesT DesIGn: The next phase is named test design. All on the story card listed features to be elaborated will be implemented in terms of tests. It results in an executable specification of the functionality relating to the story card (see Test Driven Development). Exceptions are story cards, which deal exclusively with improvements to the surface and do not alter any functionality of the system. These may have emerged by a usability test and may be difficult or not mechanically testable at all. In that case, this phase will be skipped. Phase 6 - PRoGRaMMInG: In the programming phase, the results from the previous phases will be implemented. The previously designed user interface is implemented, required classes and methods written and database structures developed. In doing so, the simplest solution that works should always be chosen and implemented. Programming is done, when all tests can be executed correctly. After successfully testing, the newly developed source code should be trialed by a refactoring.
47
Phase 7 - InTeGRaTIon: Integration means bringing the modified source code with the code base together. Before this step can be made, all tests have to be completed successfully. As a tool to integration, a version management should be used by all means. It is advisable that the possibly created charts during the modelling phase get checked in as well in the version management in addition to the source code. On tools that automatically pass all tests and trigger a build in each software version, which is recorded to the version management, should not be waived. Thus, errors, such as a forgotten check-in of a file in the version management, can be easily detected. Phase 8 - DePloYMenT: The term deployment describes the automatic distribution and delivery of the developed software. Ideally, the newly created function is recorded in the production system.
48
This leads to the advantage that further developments are available immediately to the users. Despite extensive testing, this yet implies the risk of errors within the productive version. In order to take this risk, the possibility of revoking a deployment has to be present at any time. If an immediate production start of a new release is not possible or not desired, one should deploy at least on a test system to have a working system with the latest software version for tests and demonstrations always available. Phase 9 - UsabIlITY TesT: The usability test is the final phase of a UDD-iteration. The developer will test the newly implemented function regarding to the functionality description on the story card. If, despite of extensive testing, errors are found, the preceding deployment will be called off immediately and the iteration will be passed through again with a view to debugging. The functionality should be ensured normally. However, it will often be the case that ideas for improving regarding the just developed functionality or a different feature of the system arise. These are listed in terms of story cards and have to be prioritized by the customers in the next experimental game.
4 eValUaTIon
In the following sections, the agile methods are being evaluated in accordance to various criteria. The criteria are: Coverage of disciplines in software engineering Level of awareness and dissemination of methods Support for different types of projects Support by tools Normalization, standardization, certification, licensing Industry focus Support during introduction and utilization
A detailed description of the criteria used and the individual evaluations is provided in the respective chapters.
4.1
It will be examined below, to what extent agile methods cover disciplines of software engineering. As disciplines of software engineering will be considered: Project Management Quality Management Requirements Management System design / technical conception Implementation Test Integration and deployment Maintenance Operation
CoVeRaGe of DIsCIPlInes In sofTWaRe enGIneeRInG
49
PRojeCT ManaGeMenT: Project management is use of knowledge, skills, tools and techniques on project activities to meet project requirements. This encompasses the activities of planning, controlling and checking, and the areas of time management, scope management, risk management, cost management, project-specific procurement of products and services, human resource planning, project integration and project communication. QUalITY ManaGeMenT: Quality Management is understood as coordinated activities to direct and control an organization in terms of quality. Directing and controlling in terms of quality typically includes setting the quality policy and quality objectives, quality planning, quality assurance and quality improvement (ISO 9000).
ReQUIReMenTs ManaGeMenT: Requirements management is the process of identification, inquiry, documentation, analysis, tracking, prioritization and coordination of requirements. According to IEEE 610, a requirement is a documented representation of a condition or capability as per 1. or 2.: 1. Habit or ability that user need to solve a problem or to achieve an objective. 2. Habit or ability that is complied or needed by a system or system part, in order to fulfill a contract, a standard, a specification or other formally given document. sYsTeM DesIGn / TeChnICal ConCePTIon: System design is the definition of a system-architecture as well as the components, modules, interfaces and data of a software-system. IMPleMenTaTIon: Implementation is the conversion of the technical specification and the algorithms into an executable software program. TesT: The test supports ensuring the software quality and to test, whether the requirements concerning the software will be met. According to IEEE 829, a test is a certain quantity in one or more test cases. A test case regarding to IEEE 610 comprises the following: The necessary pre-conditions for the accomplishment The set of input values (one value per test object parameter) The set of predicted results The expected post-conditions
50
Test cases are developed with a view to a certain target or a test condition, e.g. executing a particular program path or examining the compliance with specific requirements (such as handing off inputs the test object and reading off desired values). InTeGRaTIon anD DePloYMenT: Integration is the process of linking individual components to larger units and ultimately to the whole system. Deployment is the commissioning of software and the roll-out to the users. MaInTenanCe: Maintenance is the modification of a software product after its deployment in order to correct error conditions, to improve the performance or other characteristics or to adapt the product for a different environment.
oPeRaTIon: Operation means securing the productive use of software. This encompasses the following topics in compliance with ITIL V3 Service Strategy Service Design Service Transition Service Operation Continual Service Improvement
with their respective processes.
51
The result of evaluation is presented in the following figures in the form of spider charts. The evaluation is done with the values 0-4, where 0 means no and four full coverage. It has been evaluated, to what extent the disciplines of software engineering will be addressed by the respective methods. The evaluation does not specify the quality of results to a specific project. PRofIles The following abbreviations are used in the spider charts: PM: Project Management QM: Quality Management RM: Requirements Management SD: System design / technical conception IMP: Implementation T: Test INT: Integration and Deployment M: Maintenance O: Operation
4.2
PRofIles afTeR eValUaTInG The MeThoDs
52
ActiF
4
B PM QM B
Agile Enterprise
4 3 2
RM W PM QM
3 2
1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
AMDD
4
B PM QM B
ASD
4 3 2
RM W PM QM
53
3 2
1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
BDD
4
B PM QM B
Crystal
4 3 2
RM W PM QM
3 2
1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
Design Driven Development (DDD)

4
B PM QM
Dynamic System Development Method (DSDM)

4
B PM QM
3 2 1 0
3 2 1 0
RM
RM
INT T IMP
SD
INT T IMP
SD
Eclipse Way Process
54
B
4 3 2
W
PM QM
Evolutionary Process for integrating COTS-Based Systems (EPIC)

4 3 2
W PM QM
B RM
1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
Evolutionary Project Management & Product Development (EVO)

4 3 2
W PM QM W RM
Extreme Programming (XP)

4
B PM QM
3 2 1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
Feature Driven Development (FDD)

4
B PM QM W B
Iconix
4 3 2 1 0
PM QM
3 2 1 0
RM
RM
INT T IMP
SD
INT T IMP
SD
Internet-Speed Development (ISD)

4
B PM QM
Lean Software Development (LSD)

4
B PM QM
55
3 2 1 0
3 2 1 0
RM
RM
INT T IMP
SD
INT T IMP
SD
MS Solution Framework (MSF4ASD)

4
B PM QM W B
Mobile-D
4 3 2 1 0
RM RM PM QM
3 2 1 0
INT T IMP
SD
INT T IMP
SD
Rapid Application Development (RAD)

4
B PM QM W B
Scrum
4 3 2 1 0
RM RM PM QM
3 2 1 0
INT T IMP
SD
INT T IMP
SD
Unified Process
56
B
4 3 2
W
PM QM
Agile Unified Process (AUP)

4
B RM PM QM
3 2 1 0
1 0
RM
INT T IMP
SD
INT T IMP
SD
Essential Unified Process (EssUP)

4
B PM QM
Open Unified Process (OpenUP)

4
B PM QM
3 2 1 0
3 2 1 0
RM
RM
INT T IMP
SD
INT T IMP
SD
Test Driven Development (TDD)

4
B PM QM
Usability Driven Development (UDD)

4
B PM QM
3 2 1 0
3 2 1 0
RM
RM
INT T IMP
SD
INT T IMP
SD
57
The following table summarizes the evaluation, where the following symbols are used: 0 1 2 3 4 No cover Low coverage Medium coverage Coverage Full coverage
4.3
Tables
The following abbreviations are used in the tables: PM: Project Management QM: Quality Management RM: Requirements Management SD: System design / technical conception IMP: Implementation T: Test INT: Integration and Deployment M: Maintenance O: Operation
58
Method actif agile enterprise aMDD asD bDD Crystal DDD DsDM eclipse Way Process ePIC eVo extreme Programming (XP) fDD Iconix IsD lsD Mobile-D Ms solution framework RaD scrum TDD UDD Unified Process aUP essUP oUP
Table 1: Summary of evaluation.
PM 3 4 1 2 0 2 0 2 4 4 4 1 3 3 3 1 2 3 1 4 0 2 1 4 4 4
QM 2 3 2 4 3 3 1 2 2 3 2 3 3 4 0 4 2 2 1 3 3 3 1 1 2 1
RM 4 4 2 1 4 2 3 4 4 3 2 3 3 4 3 2 2 2 2 4 1 3 4 3 3 4
sD 3 2 2 1 1 0 1 4 4 3 3 2 4 4 1 3 1 2 0 1 0 2 4 3 4 4
IMP 4 4 3 2 2 3 1 4 4 2 2 4 3 4 3 3 2 3 4 1 4 2 4 4 4 4
T 1 4 4 1 2 4 1 4 4 3 4 4 1 4 3 4 3 3 3 1 4 4 3 3 3 3
InT 3 3 3 0 1 1 0 4 3 3 2 2 1 3 4 2 1 2 3 3 2 4 3 3 3 3
W 0 1 3 0 0 1 0 3 1 0 0 1 0 1 0 1 0 0 1 1 1 1 1 1 1 1
b 0 0 3 0 0 0 0 2 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0
59
4.3.1
The evaluation of the level of awareness and dissemination of agile methods was performed by reference to the following parameters: nUMbeR of seaRCh ResUlTs In GooGle: The number of search results in Google (www.google.com) has been analyzed. In order to find only the most relevant methods and to prevent obtaining results with other meanings of a term (the term Scrum e.g. comes from the rugby sports), the following search text was used <method> agile development The method thereby has been written with no abbreviations. Example: Test Driven Development agile development The number of results for the level of diffusion has been divided in high, medium and low.
leVel of aWaReness anD DIsseMInaTIon of MeThoDs
60
Level of diffusion high: > 100.000 hits by the above search Level of diffusion medium: 10.000-100.000 hits Level of diffusion low: <10.000 hits
nUMbeR of books aVaIlable aT aMazon: The obtained number of books, on the web page of Amazon (www.amazon. com) has been analyzed. The same search terms as on Googles page have been used. The number of results for level of diffusion has been divided in high, medium and low. Level of diffusion high: > 10 hits by the above search Level of diffusion medium: 5-10 hits Level of diffusion low: < 5 hits
nUMbeR of PeRsons WITh knoWleDGe anD eXPeRIenCe In The MeThoDs: Profiles that are saved in a Western European portal for freelancers have been analyzed. In doing so, the candidates profiles have been searched for the respective method names. In order to only find the appropriate methods, the methods have been searched in quotation marks. Example: Feature-driven development The number of results for level of diffusion has been divided in high, medium and low. Level of diffusion high: > 100 hits by the above search Level of diffusion medium: 10-100 hits Level of diffusion low: < 10 hits
Method actif agile enterprise aMDD asD bDD Crystal DDD DsDM eclipse Way Process ePIC eVo extreme Programming (XP) fDD Iconix IsD lsD Mobil-D Ms solution framework RaD scrum TDD UDD Unified Process aUP essUP oUP
Google
Low Medium Medium Low Low High Low Medium Low Low Medium High Medium Low Low Medium Low Low Medium High High Low Medium Medium Medium Medium
books
Low Low Low Low Low Low Low Low Low Low Low High Medium Medium Low High Low Low Medium High Medium Low Medium Low Low Low
People
Low Low Low Low Low High Low Low Low Low Low High Medium Low Low Low Low Low Medium High Medium Low Medium Low Low Low
Total
Low Low Low Low Low High Low Low Low Low Low High Medium Low Low Medium Low Low Medium High Medium Low Medium Low Low Low
61
Table 2: Evaluation of level of awareness and dissemination.
The following figure depicts the results graphically: The top ones can be seen as the favorites, the ones below rather as the exotic.
XP Scrum Crystal TDD FDD LSD RAD Unified Process AUP
62
EssUP OUP Agile Enterprise AMDD DSDM EVO Iconix Actif ASD BDD DDD Eclipse Way Process EPIC ISD Mobil-D MSF4ASD
Figure 25: Overall evaluation regarding to the level of awareness (Google, books, people)
UDD 0 2 4 6 8 10
4.3.2
Another criterion for the evaluation of the methods is the support of different types of projects. Three types of projects were considered: New development of custom software Further development of custom software Customizing and adjusting development of standard software
sUPPoRT of DIffeRenT TYPes of PRojeCTs
neW DeVeloPMenT of CUsToM sofTWaRe: The new development of custom software is understood as the development of a new software system. DeVeloPMenT of CUsToM sofTWaRe: The further development of custom software is understood as the functional extension of an existing software system. CUsToMIzInG anD aDaPTInG DeVeloPMenT of sTanDaRD sofTWaRe: Customizing of standard software and adapting development is understood as the adoption of a standard system to company-specific circumstances. Customizing thereby is the adjustment of configuration of the software without programming activities (e.g. the change of configuration files in the text editor), while in the adapting development the software is made ready for operation by programming activities (e.g. ABAP-development in an SAP system). We have come to the conclusion that in an agile project environment it can not be differentiated between different types of projects, since the project approach primarily depends on the basic, surrounding conditions (e.g. stability and maturity of the requirements, standard project approach of a company, desired appointments and guidelines). Thus, as an example, the new development of custom software can take place both in a classical and an agile way. It is restrictively to be said that the use of Test Driven Development or the use of the Test First approach of Extreme Programming is not recommended both in case of further development and customizing of standard software. In case of further development of custom software, the use of these methods depends on the existing coverage of the software by unit-tests, in case of customizing it generally depends on the presence of a unit-test framework.
63
In order to use a method reasonable, a tool support is often helpful. It was analyzed, whether there is a support by specialized software solutions to the respective methods. With this, tools of basic nature that may be used in the agile software development, e.g. MS Excel or Bugzilla, are not meant, but tools specifically designed for the use of a particular method (e.g. Scrumworks). See Table 3.
4.3.3
sUPPoRT bY Tools
4.3.4
In order to be able to assess the future viability and reliability of a method, the issues of normalization / standardization, certification and licensing have been considered. In detail, the following questions have been examined: Who is the carrier/ driver of a method (single company, consortium, non-profit organization, community)? Is there a standardization authority? Is there a training program with certification (e.g., Certified Scrum Master)? Does a method have to be licensed before utilization?
noRMalIzaTIon, sTanDaRDIzaTIon, CeRTIfICaTIon, lICensInG
The points are presented In table 4.
64
As part of the research, we have come to the insight that for the application of agile software development methods no industry focus can be seen. In our opinion, an agile approach suits in branches, in which companies act both innovative and value-oriented and have to adopt on market demands quickly and flexibly in order to remain competitive in the market (such as in the Telecommunications industry). For branches with a focus on safety-critical aspects (e.g. military, air & space), a strong legal precept (e.g. banking sector) and public institutions suits a more traditional method, such as the waterfall model, or V-model XT. However, there are additional criteria that have a bearing on the decision, whether it should be proceeded traditional or agile. Thus, as an example, in the banking sector a customer portal may be developed agile, the core banking system in contrast should be developed in a more traditional way due to availability and data security.
4.3.5
InDUsTRY foCUs
When a new method or a new process is introduced, it is often drawn on outside help. It is not different within agile software development. For this reason it has been examined, which methods support and consulting is available to during introduction. Table 5 shows, whether support (e.g. extern consultant, trainings) for a method is offered.
4.3.6
sUPPoRT DURInG InTRoDUCTIon anD Use
support by Tools
Yes No No Yes Yes Yes No Yes No No No Yes Yes No No No No Yes Yes Yes Yes No Yes No No Yes
65
Table 3: describes, whether there is a specialized tool support to a method.
Method actif agile enterprise aMDD asD bDD Crystal DDD DsDM
normalization / standardization
No No No No No No No Yes No Yes Yes No No No No Yes No No No Yes No No Yes Yes No No
Certifiation
No No No No No Yes No Yes No No No No Yes No No Yes No No No Yes Yes No Yes Yes No Yes
licensing
No No No No No No No Yes No Yes No No No No No No No No No No No No Yes No Yes No
66
eclipse Way Process ePIC eVo extreme Programming (XP) fDD Iconix IsD lsD Mobile-D Ms solution framework RaD scrum TDD UDD Unified Process aUP essUP oUP
Table 4: Overview of normalization / standardization, certification and licensing
support available
Yes No No Yes No Yes No Yes Yes Yes Yes Yes Yes Yes No Yes No Yes No Yes Yes Yes Yes Yes Yes Yes
67
Table 5: shows, whether support (e.g. extern consultant, trainings) for a method is offered.
5 lInks
aCTIf http://www.microtool.de/instep/en/actif.asp aDaPTIVe sofTWaRe DeVeloPMenT (asD) http://en.wikipedia.org/wiki/Adaptive_Software_Development http://www.jimhighsmith.com/articles/messy.htm http://www.pss-europe.com/P478.pdf aGIle enTeRPRIse (foRMeRlY X bReeD) aGIle MoDel DRIVen DeVeloPMenT (aMDD) http://www.agilemodeling.com/essays/amdd.htm http://conferences.embarcadero.com/article/images/32437/3202.pdf http://bestofcyber.wordpress.com/2007/02/09/amdd-agile-model-drivendevelopment/ behaVIoR DRIVen DeVeloPMenT (bDD) http://en.wikipedia.org/wiki/Behavior_Driven_Development http://behaviour-driven.org/ http://www.code-magazine.com/article.aspx?quickid=0805061 CRYsTal http://alistair.cockburn.us/Crystal+methodologies http://alistair.cockburn.us/Crystal+light+methods http://www.agilekiwi.com/crystal_clear.htm DesIGn DRIVen DeVeloPMenT (D3) http://www.designdrivendevelopment.org/ http://en.wikipedia.org/wiki/Design-driven_development DYnaMIC sYsTeM DeVeloPMenT MeThoD (DsDM) http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method http://www.dsdm.org/ http://www.freetutes.com/systemanalysis/sa2-dynamic-systemdevelopment-method.html eClIPse WaY PRoCess http://www.eclipsezone.com/eclipse/forums/t20805.html http://www.ibm.com/developerworks/rational/library/edge/08/jul08/ vanVelzen eVolUTIonaRY PRoCess foR InTeGRaTInG CoTs-baseD sYsTeMs (ePIC) http://www.sei.cmu.edu/library/abstracts/reports/02tr009.cfm http://en.wikipedia.org/wiki/Evolutionary_Process_for_Integrating_ COTS-Based_Systems http://www.ibm.com/developerworks/rational/library/aug05/perairepannone/index.html eVolUTIonaRY PRojeCT ManaGeMenT & PRoDUCT DeVeloPMenT (eVo) eXTReMe PRoGRaMMInG (XP) http://www.extremeprogramming.org/ http://en.wikipedia.org/wiki/Extreme_Programming http://xprogramming.com/index.php feaTURe DRIVen DeVeloPMenT (fDD) http://www.featuredrivendevelopment.com/ http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf IConIX http://en.wikipedia.org/wiki/iconix http://iconixprocess.com/iconix-process/
http://www.e-architects.com/AE/
68
http://www.gilb.com/Project-Management
InTeRneT sPeeD DeVeloPMenT http://www.viswiki.com/en/Internet-Speed_Development lean sofTWaRe DeVeloPMenT (lsD) http://www.poppendieck.com/ http://agilesoftwaredevelopment.com/leanprinciples http://www.leanprimer.com/downloads/lean_primer.pdf MICRosofT solUTIons fRaMeWoRk foR aGIle DeVeloPMenT (Msf4asD) http://download.microsoft.com/download/8/6/3/86375d9e-1263-4ba0-b5f2f696aceb94f3/20060418.ppt http://www.microsoft.com/downloads/details.aspx?FamilyId=9F3EA426C2B2-4264-BA0F-35A021D85234&displaylang=en MobIle-D http://virtual.vtt.fi/virtual/agile/mobiled.html RaPID aPPlICaTIon DeVeloPMenT (RaD) http://www.cs.bgsu.edu/maner/domains/RAD.htm http://en.wikipedia.org/wiki/Rapid_application_development sCRUM http://en.wikipedia.org/wiki/Scrum_(development) http://www.scrumalliance.org/ TesT DRIVen DeVeloPMenT (TDD) http://en.wikipedia.org/wiki/Test-driven_development http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_ gci1246164,00.html UnIfIeD PRoCess (UP) http://en.wikipedia.org/wiki/Unified_Process http://www.ambysoft.com/unifiedprocess/agileUP.html http://www.ivarjacobson.com/process_improvement_technology/essential_ unified_process_software/ http://www.eclipse.org/epf/general/OpenUP.pdf UsabIlITY DRIVen DeVeloPMenT (UDD) http://cakebaker.42dh.com/2007/07/07/usability-driven-development/
69
6 sUMMaRY
Agile software development is on the rise all over the world. Evidence of that is the variety of methods in agile environment. The huge number of methods testaments that THE agile Method does not exist (yet?). Each of the methods examined has its specific focus, its strengths and its weaknesses, but its eligibility as well. Each project is unique regarding to its content and its boundary conditions. Choosing the appropriate method to implementation is usually not easy. Nevertheless, the application of a particular method does not guarantee project success. By selecting the right team or the right partner, you can set the course already to success before project start, regardless of the applied method. At the end of the day, it comes down to the experience, skills and knowledge of people, who realize the project - for projects are carried out by man, not by methods.
70
7 aboUT bQI
The Best Quality Institute (BQI), based in Berlin, is the leading institute for awards which measure and assess the quality of companies and employees. BQI is the first place to call for developing highly specialized research studies and assessment models for the most diverse areas of your business. BQI is a pioneer in standardizing quality assessment of software and personnel. Independence, comparability and transparency are BQIs core competencies and allow BQI to live up to the high expectations of its clients and participating companies.
71
72
8 DIsClaIMeR
The contents of this document are protected due to copyright by BQI. Citation is allowed whilst taking the usual rules and guidelines into account. Copying or printing belatedly, including excerpts as well as photomechanical reproduction or saving on a storage medium is only permitted by written approval of the BQI. The corresponding safeguard provision hold true for brands and business relationships, that are used in the content of this presentation, even if they are not labelled as such. eXClUsIon of lIabIlITY: The BQI assumes no liability for the actuality, correctness, completeness or quality of the information provided at all. Liability claims against the BQI, based on disadvantages or harms of any kind relating to a physical or imaginary way, which have been caused by use or disuse of the presented information or the use of incomplete and faulty information, are principally excluded, as far as there is no evidence of deliberate or reckless guiltiness on the part of the BQI.
73
This research has been carried out exclusively for BQI by PENTASYS AG Rdesheimer St. 9 80686 Munich www.pentasys.de
BQI Best Quality Institute GmbH Jgerstrae 67-69 D-10117 Berlin Germany www.bqi.eu Mail: contact@bqi.eu

Agile Software Development Methods 2010 e Ga Co

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agile Software Development Methods 2010 e Ga Co

Transféré par

Droits d'auteur :

Formats disponibles

BQI Research

Agile Software Development

Berlin, June 2010

2 aGIlITY In sofTWaRe DeVeloPMenT

The aGIle ManIfesTo

3 aGIle PRoCeDURe MoDels

Agile, but not widespread methods: Universal Application UPXS

aDaPTIVe sofTWaRe DeVeloPMenT (asD)

Planning of adaptive cycles

Simultaneous development of components

Final quality assurance & release

aGIle enTeRPRIse (foRMeRlY X bReeD)

aGIle MoDel DRIVen DeVeloPMenT (aMDD)

Figure 3: AMDD Process (own chart)

behaVIoR DRIVen DeVeloPMenT (bDD)

Fehler in Software bedeutet Gefahr fr:

Figure 4: ProjectClassification according to Crystal (own chart)

DesIGn DRIVen DeVeloPMenT (D3)

DYnaMIC sYsTeM DeVeloPMenT MeThoD (DsDM)

Figure 5: Interaction between D3, Scrum and XP

eClIPse WaY PRoCess

Figure 6: Techniques of Eclipse Way (source: http://www.ibm. com/developerworks/rational/library/edge/08/jul08/vanVelzen/)

3.10 eVolUTIonaRY PRoCess foR InTeGRaTInG CoTs-baseD sYsTeMs (ePIC)

Figure 8: Containment of the solution space in progressing time

3.11 eVolUTIonaRY PRojeCT ManaGeMenT & PRoDUCT DeVeloPMenT (eVo)

Figure 9: Key elements of EVO

3.12 eXTReMe PRoGRaMMInG (XP)

The valuations of XP are:

In a XP-project there are the following roles: Customer Developers Manager

Figure 10: The XP-Process (source: www.extremeprogramming. org)

Figure 11: Process within an iteration in XP (source: www. extremeprogramming.org

3.13 feaTURe DRIVen DeVeloPMenT (fDD)

3.13.1 Role MoDel

3.13.2 PRoCess MoDel

Figure 12: FDD process flow (source: wikipedia

3.13.3 besT PRaCTICes

3.15 InTeRneT-sPeeD DeVeloPMenT

Figure 14: The phase-model of the Internet-Speed Development

3.16 lean sofTWaRe DeVeloPMenT (lsD)

3.17 MICRosofT solUTIons fRaMeWoRk foR aGIle sofTWaRe DeVeloPMenT (Msf4asD)

Figure 15: Contents of iterations in MSF4ASD

3.19 RaPID aPPlICaTIon DeVeloPMenT (RaD)

Figure 16: The end of a phase in Mobile-D

Figure 17: RAD process (Source: http://blog.twinklesprings.com)

3.20.2 MaIn eleMenTs

3.20.3 oPeRaTIonal seQUenCe DesCRIPTIon

Figure 18: Scrum Process

3.21 TesT DRIVen DeVeloPMenT (TDD)

Figure 19: Test Driven Development Lifecycle (own presentation)

3.22 UnIfIeD PRoCess (UP)

Inception Elaboration Construction Transition

aRChITeCTURe-CenTeReD: UP focuses the efforts in the design of a system-architecture.

3.22.1 aGIle UnIfIeD PRoCess (aUP)

3.22.2 essenTIal UnIfIeD PRoCess (essUP)

3.22.3 oPen UnIfIeD PRoCess (oPenUP)

Figure 22: Content areas of the OpenUP (Source: http://epf.eclipse.org/wikis/openup/)

3.23 UsabIlITY DRIVen DeVeloPMenT (UDD)

The sequence of phases is shown in figure 24.

Figure 24: End of an iteration in UDD (source: http://www. jensjaeger.com/tag/usabilitydrivendevelopment/)

CoVeRaGe of DIsCIPlInes In sofTWaRe enGIneeRInG

with their respective processes.

PRofIles afTeR eValUaTInG The MeThoDs

Design Driven Development (DDD)