CSC/ECE 517 Fall 2010/ch6 6d NM
Agile vs. other software-development methods
Software development methodologies
Software development methodology is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.
Types of Software development methodologies
There are wide variety of software development approaches used in the industry. Few of them are,
- Waterfall Approach : linear framework type.
- Prototyping Approach : iterative framework type
- Incremental Approach: combination of linear and iterative framework type
- Spiral Approach : combination of linear and iterative framework type
- Rapid Application Development (RAD) Approach: Iterative Framework Type
- Agile Methodologies
Agile Methodology
Software development methodology Agile means – moving quickly and lightly. Similarly, the goal of Agile methodology is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams. Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc.. Well-known agile methods include
- Agile Unified Process (AUP)- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
- Dynamic Systems Development Method (DSDM)- iterative and incremental approach that emphasizes continuous user involvement
- Essential Unified Process (EssUP) - identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
- Extreme Programming (XP)- intended to improve software quality and responsiveness to changing customer requirements
- Feature Driven Development (FDD)- model-driven short-iteration process
- Open Unified Process (OpenUP)- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
- [1]- a process skeleton that contains sets of practices and predefined roles.
- Velocity tracking– tracking a measure of productivity sometimes used in agile software development
Agile vs waterfall
Waterfall
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.
Comparison with Agile
- Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
- Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
- Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
- Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.
Agile Vs Spiral
Spiral model
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.
Comparison with Agile
- Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
- Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
- Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
- Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
- Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
- Risk: Spiral model has known risks while
- Cost: spiral models are usually expensive compared to Agile models
- Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.
Agile vs Iterative
Iterative Software development
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.
Comparison with Agile
Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
- Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
- Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
- Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
- Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
- Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
- Team size: Iterative model has large team size while agile model has large team size.
- Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.
Agility in context
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
- Insufficient customer involvement can result in confused and incomplete requirement document and bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
- The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
- Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequent sync calls and sharing wiki pages.
- Even though some projects are characterized by slow Rate of change making them fall into other software development category, they can be good candidates for agile if other agile development methods can be applied to the project effectively
Limitations of agile methodology
- They are difficult when used with the large teams. (Team having members more than 20).
- Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
- It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
- It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
- It does not work best, when the requirements are predictable.
- Lack of documentation may result into failure in understanding the project in future by an outside expert.
- User interface are developed using the paper prototype based approach rather than model-driven design.
Limitations of other software development methodologies
- Lack of customer interaction results into last moment surprises.
- Incorporation of the changes during the software development cycle is very difficult task.
- High amount of prediction is required which result into higher risk involved.
- Documentation consumes lot of time in the software development cycle.
- More pre-planning is required compared to agile methods.
- Stringent team structure may result into conflicts.
Conclusion
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently. Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.
References
[1] http://www.buzzle.com/articles/waterfall-model-vs-agile.html
[2] M. A. Awad, "A Comparison between Agile and Traditional Software Development Methodologies"
[3] Boehm B, "A Spiral Model of Software Development and Enhancement"ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
[4] Rashina H, Philippe K, James N and Stuart M, ”Agility in Context”, ACM OOOPSLA 2010