Waterfall vs. Agile Methodology
(→Example of Use) |
|||
| (48 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ''Developed by Julian Ofenstein'' | |
| − | The Waterfall methodology represents the traditional approach, where the development process is conducted in a linear series of events. On its way toward the conclusion, the progress flows continuously through the phases of a project (analysis, design, development, testing, release) like a waterfall. The entire project is planned in advance. | + | |
| − | Agile is a more recently developed software development methodology, where the linear approach is replaced by an incremental, iterative one. Instead of planning the whole project in advance, Agile enables the adaption of requirements during the whole project. | + | |
| − | This article provides an introduction to each methodology, | + | There are two main software development methodologies: Waterfall and Agile. A development methodology is a procedure used by an engineering team in order to create the desired product. |
| + | The Waterfall methodology represents the traditional approach, where the development process is conducted in a linear series of events. On its way toward the conclusion, the progress flows continuously through the phases of a project lifecycle (analysis, design, development, testing, release) like a waterfall. The entire project is planned in advance. | ||
| + | Agile is a more recently developed software development methodology, where the linear approach is replaced by an incremental, iterative one. Instead of planning the whole project in advance, Agile enables the adaption of requirements during the whole project.<BR> | ||
| + | This article provides an introduction to each methodology, their pros and cons, and examples of use, in order to facilitate the decision whether Agile or Waterfall is more suitable for the next project. | ||
=Waterfall Methodology= | =Waterfall Methodology= | ||
| − | The lifecycle model which is today known as traditional or Waterfall model was first described by Royce in 1970.<ref> Sommerville I., "Software process models | + | The lifecycle model which is today known as traditional or Waterfall model was first described by Royce in 1970.<ref> Sommerville I., "Software process models", ACM Computing Surveys (CSUR), vol. 28, pp. 269-271, 1996 </ref> It is called Waterfall model because of its sequential and down-flow characteristic where the phases analysis, design, implementation, testing and release are processed consecutively downwards.<ref name= "Comparative Study"> Dubey A.; Jain A.; Mantri A., "Comparative Study: Waterfall v/s Agile Model", International Journal of Engineering Sciences & Research Technology (IJESRT), 2015 </ref> Each phase of the Waterfall model is processed in order without any overlapping and within a specified time period. Once a phase is completed there is no going back to a previous phase as it will be frozen.<ref name= "Waterfall v/s Agile"> Balaji S.; Dr. Sundararajan Murugaiyan M., "Waterfall vs V-Model vs Agile: A Comparative Study on SDLC", International Journal of Information Technology and Business Management (JITBM), 2012 </ref> |
| Line 18: | Line 21: | ||
'''Design''' | '''Design''' | ||
| − | The outcome of the design phase is a specified hardware and a virtual overview of the desired system or software.<ref name= " | + | The outcome of the design phase is a specified hardware and a virtual overview of the desired system or software.<ref name= "Comparative Study"/> |
'''Implementation''' | '''Implementation''' | ||
| Line 35: | Line 38: | ||
After releasing the product in the customer environment there can occur problems in the performance of the product. Hence, the company must provide maintenance in order to solve this issues.<ref name= "Bomarius"/> | After releasing the product in the customer environment there can occur problems in the performance of the product. Hence, the company must provide maintenance in order to solve this issues.<ref name= "Bomarius"/> | ||
| + | |||
| + | The general literature has identified the following pros and cons of the Waterfall methodology:<ref name= "Comparative Study"/><ref name= "Waterfall v/s Agile"/> | ||
==Pros== | ==Pros== | ||
| Line 40: | Line 45: | ||
- All requirements are clearly documented before the development of the product starts | - All requirements are clearly documented before the development of the product starts | ||
| − | - | + | - The time period for finishing each phase before moving to the next is specified |
- Waterfall is simple to implement as it is a linear model | - Waterfall is simple to implement as it is a linear model | ||
| − | - | + | - Small amount of resources needed for implementing the waterfall methodology |
| − | - Each phase follows appropriate documentation in order to ensure | + | - Each phase follows appropriate documentation in order to ensure high quality of development |
==Cons== | ==Cons== | ||
| Line 54: | Line 59: | ||
- If a customer wants to change requirements of the product they cannot be implemented in the current development process | - If a customer wants to change requirements of the product they cannot be implemented in the current development process | ||
| − | - Even small changes or errors in the finalized product might be very costly and cause a lot of problems | + | - Even small changes or errors in the finalized product might be very costly and cause a lot of problems |
=Agile Methodology= | =Agile Methodology= | ||
| − | |||
[[File:AgileModel.png|thumb|right|500px|Figure 2: Agile Model]] | [[File:AgileModel.png|thumb|right|500px|Figure 2: Agile Model]] | ||
| − | The Agile methodology uses an incremental, iterative approach instead of a linear and sequential one. Instead of extensive planning in advance, it provides practices, tools and a culture that enable close collaboration of a team in a quickly changing environment. During several successive iterations with a predetermined duration, the team develops working products in order to get continuous feedback from the customer.<ref name= "Agile Principles"/> Every iteration consists of a planning and analyzing phase followed by a fast design, build and test phase and results in deployment.<ref name= "Applying Agile Principles"/> This procedure enables the team to improve the product with every iteration by adapting the backlog, a list of prioritized requirements for | + | The Agile methodology uses an incremental, iterative approach instead of a linear and sequential one. Instead of extensive planning in advance, it provides practices, tools and a culture that enable close collaboration of a team in a quickly changing environment. During several successive iterations with a predetermined duration, the team develops working products in order to get continuous feedback from the customer.<ref name= "Agile Principles"/> Every iteration consists of a planning and analyzing phase followed by a fast design, build and test phase and results in deployment.<ref name= "Applying Agile Principles"/> This procedure enables the team to improve the product with every iteration by adapting the backlog, a list of prioritized requirements for each iteration. Furthermore, Agile approaches emphasize teamwork and communication. The teams are selforganized and cross-functional (incorporating planners, designers, developers and testers) with empowered members. This team set-up motivates to create high-quality outcomes.<ref name= "Agile Principles"/> |
Scrum, Kanban, Lean, Extreme Programming (XP) and Feature Driven Development (FDD) are popular methods of the Agile methodology that provide concrete agile practices and comprise the following characteristics:<ref name= "Applying Agile Principles"> Von Rosing M. et al., "Applying Agile Principles to BPM", Complete Business Process Handbook: Body of Knowledge From Process Modeling To Bpm — 2014, Volume 1, pp. 553-577</ref> | Scrum, Kanban, Lean, Extreme Programming (XP) and Feature Driven Development (FDD) are popular methods of the Agile methodology that provide concrete agile practices and comprise the following characteristics:<ref name= "Applying Agile Principles"> Von Rosing M. et al., "Applying Agile Principles to BPM", Complete Business Process Handbook: Body of Knowledge From Process Modeling To Bpm — 2014, Volume 1, pp. 553-577</ref> | ||
| Line 76: | Line 80: | ||
| − | Generally, the different methods of Agile differ slightly one from the other but contain practices that cover the full range of product development. In some cases, it is recommendable to combine different practices in order to create a situation-specific method.<ref name= "Applying Agile Principles"/> All Agile | + | Generally, the different methods of Agile differ slightly one from the other but contain practices that cover the full range of product development. In some cases, it is recommendable to combine different practices in order to create a situation-specific method.<ref name= "Applying Agile Principles"/> All Agile methodologies have in common, that they are driven by Agile values and principles, which are explained in the Agile Manifesto published in 2001:<ref>Schwaber K. et. al., "Manifesto for Agile Management", 2001, Retrieved from http://agilemanifesto.org/ 22.09.2017 </ref> |
* Individuals and interactions over processes and tools | * Individuals and interactions over processes and tools | ||
| Line 83: | Line 87: | ||
* Responding to change over following a plan | * Responding to change over following a plan | ||
| − | The twelve principles of Agile enlarge on this four value statements | + | |
| + | The twelve principles of Agile enlarge on this four value statements:<ref>K. Schwaber et. al., "Twelve principles of agile software", 2001. Retrieved from http://agilemanifesto.org/principles.html 22.09.2017</ref> | ||
| + | |||
| + | * Early customer satisfaction through delivering valuable software | ||
| + | * Meeting changing requirements even if they occur late in development | ||
| + | * Frequent delivery of working software | ||
| + | * Daily collaboration between business people and developers | ||
| + | * Projects are built by motivated individuals | ||
| + | * Face-to-face conversation is the best way of communication | ||
| + | * Working software is the most important measure of progress | ||
| + | * Sustainable development with a constant pace | ||
| + | * Permanent focus on excellent technique and good design | ||
| + | * Simplicity | ||
| + | * Working in self-organized teams | ||
| + | * Regular adaption to changes | ||
| + | |||
| + | The general literature has identified the following pros and cons of Agile methodologies:<ref name= "Comparative Study"/><ref name= "Agile Principles"> Boral S.,"Domain I: Agile Principles and Mindset", Ace the Pmi-acp pp. 1-27, 2016</ref><ref name= "AgilevsWaterfall"> Shiotsu Y., "Agile vs. Waterfall: A Side-by-Side Comparison", Retrieved from https://www.upwork.com/hiring/development/agile-vs-waterfall/, 22.09.2017</ref> | ||
==Pros== | ==Pros== | ||
| Line 89: | Line 109: | ||
- Changing requirements can be implemented at any phase of the process due to short development cycles | - Changing requirements can be implemented at any phase of the process due to short development cycles | ||
| − | - | + | - An icrement of a product can be developed very quickly |
- Continuous improvement enables fast and high-quality delivery | - Continuous improvement enables fast and high-quality delivery | ||
| Line 96: | Line 116: | ||
- The Agile methodology attaches great importance to teamwork as it requires frequent communication and face-to-face interactions. | - The Agile methodology attaches great importance to teamwork as it requires frequent communication and face-to-face interactions. | ||
| − | |||
==Cons== | ==Cons== | ||
| Line 102: | Line 121: | ||
- High dependency on collaboration with the customer. Especially in long projects that is not always possible | - High dependency on collaboration with the customer. Especially in long projects that is not always possible | ||
| − | - Due to lack of documentation, there is an increased dependence of interaction between developers | + | - Due to lack of documentation, there is an increased dependence of interaction between developers |
| − | - Compared to linear and sequential models agile methodologies are more difficult to comprehend | + | - Compared to linear and sequential models agile methodologies are more difficult to comprehend |
- When used in large and complex projects it is difficult to estimate the costs and schedule | - When used in large and complex projects it is difficult to estimate the costs and schedule | ||
| − | - Knowing that changes are possible the team could take hurried decisions without a proper analysis | + | - Knowing that changes are possible the team could take hurried decisions without a proper analysis |
=Waterfall or Agile?= | =Waterfall or Agile?= | ||
| Line 114: | Line 133: | ||
[[File:WaterfallorAgile.png|thumb|right|500px|Figure 3: Scope of application of Waterfall and Agile Methods]] | [[File:WaterfallorAgile.png|thumb|right|500px|Figure 3: Scope of application of Waterfall and Agile Methods]] | ||
| − | As a sequential | + | As a sequential model, Waterfall works best for simple projects where the requirements are clear and will not change during the development process.<ref name= "Waterfall v/s Agile"/> A good consensus with the customer and decision-making based on facts are favored frame conditions.<ref name= "Agile Principles"/> |
| Line 120: | Line 139: | ||
| − | Projects with | + | Projects with a very high level of uncertainty and disagreement with the customer should be rejected or avoided until the conditions change. After exceeding a certain point of complexity the expectation for a successful completion of the project is little. There is no adequate method that works under these circumstances. <ref name= "Agile Principles"/> |
=Example of Use= | =Example of Use= | ||
| − | The following examples demonstrate the different approaches of each methodology.<ref> "Product development: The Waterfall methodology (model) in software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-the-waterfall-methodology-model-in-software-development/, 22.09.2017</ref> <ref> "Product development: Using Agile methodology for software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-using-agile-methodology-for-software-development/, 22.09.2017</ref> The project goal is the development of a customer address book. In the beginning, a document with the following requirements is created by the product manager: | + | The following examples demonstrate the different approaches of each methodology.<ref> "Product development: The Waterfall methodology (model) in software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-the-waterfall-methodology-model-in-software-development/, 22.09.2017</ref> <ref> "Product development: Using Agile methodology for software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-using-agile-methodology-for-software-development/, 22.09.2017</ref> The project goal is the development of a virtual customer address book. In the beginning, a document with the following requirements is created by the product manager: |
• Enable user to create new contacts<BR> | • Enable user to create new contacts<BR> | ||
| Line 132: | Line 151: | ||
==Waterfall Model== | ==Waterfall Model== | ||
| + | |||
| + | '''Product Requirements''' | ||
| + | |||
| + | The created document will comprise detailed requirements, user scenarios and potential structures of the final product. | ||
'''Analysis''' | '''Analysis''' | ||
| − | |||
The document is discussed and analysed with the engineering team in order to provide for clarity. At the end of this phase, all requirements should be clear and the product manager can update document. | The document is discussed and analysed with the engineering team in order to provide for clarity. At the end of this phase, all requirements should be clear and the product manager can update document. | ||
| Line 160: | Line 182: | ||
'''Product Requirements''' | '''Product Requirements''' | ||
| − | The created document will be simple and list the requirements of the product by priority. will | + | The created document will be simple and list the requirements of the product by priority. Questions will arise during each iteration and can be discussed as they occur. For each iteration some requirements from the list are choosen, starting with the highest prioritized ones. |
Timeframe: 1 week | Timeframe: 1 week | ||
| − | '''Iteration Nr.1''' The team | + | '''Iteration Nr.1''' The development team starts working on the product, which comprises the features to create new contacts and to view contacts. This process includes designing, developing and testing of the features. At the end of the iteration, the product manager examines the first increment of the product. The team receives a feedback and further changes can be discussed. |
Timeframe: 2 weeks | Timeframe: 2 weeks | ||
| − | '''Iteration Nr.2''' | + | '''Iteration Nr.2''' The team continues working on the product and adds the features to import contacts, to email and to add pictures to the contacts. Again, this process includes designing, developing and testing of the features. At the end of the iteration, the next increment of the product is demonstrated to the product manager. The team receives another feedback and further changes can be discussed. |
Timeframe: 2 weeks | Timeframe: 2 weeks | ||
| − | '''Iteration Nr.3''' Team conducts a regression test and prepares | + | '''Iteration Nr.3''' Team conducts a regression test in order to make sure that the new adaptions did not cause any errors in the product already tested and prepares the product for the release. |
Timeframe: 1 week | Timeframe: 1 week | ||
| − | '''Release''' The product | + | '''Release''' The product is released. |
Total elapsed time: 6 weeks | Total elapsed time: 6 weeks | ||
| − | + | Any adaptions or changes in requirements during the project would cause an adjustment of the concerned iteration. | |
=Findings and Conclusion= | =Findings and Conclusion= | ||
| − | As already discussed, the Waterfall model is a linear model with a sequential set of processes where the development "flows" from the start point to the delivery of a working product with several stages in between. Waterfall is a plan-driven methodology and hence, the whole project strictly follows a clear plan, which requires extensive planning upfront. That allows an estimation of costs and timeline which can be discussed with the customer in advance. The existence of an elaborated plan and clear documentation also results in a more secure project as everyone exactly knows what to do.<BR> | + | As already discussed, the Waterfall model is a linear model with a sequential set of processes where the development "flows" from the start point to the delivery of a working product with several stages in between. Waterfall is a plan-driven methodology and hence, the whole project strictly follows a clear plan, which requires extensive planning upfront. That allows an estimation of costs and timeline which can be discussed with the customer in advance. The existence of an elaborated plan and clear documentation also results in a more secure project as everyone exactly knows what to do and new members can easily join the team.<BR> |
In comparison, the Agile methodology provides flexible models which enable adaptive planning and development. While the product delivery at Waterfall occurs at the very end of the process, Agile methods are divided into small releases which provide the customer with small increments of the final product. During several iterations, the team works on this small packages of the product what allows direct customer feedback at the end of every iteration. Thus, rapid and effective responses to changing customer requirements are possible. But in return, it also requires the permanent availability of the customer.<ref name= "Applying Agile Principles"/> | In comparison, the Agile methodology provides flexible models which enable adaptive planning and development. While the product delivery at Waterfall occurs at the very end of the process, Agile methods are divided into small releases which provide the customer with small increments of the final product. During several iterations, the team works on this small packages of the product what allows direct customer feedback at the end of every iteration. Thus, rapid and effective responses to changing customer requirements are possible. But in return, it also requires the permanent availability of the customer.<ref name= "Applying Agile Principles"/> | ||
| + | |||
| + | Waterfall and Agile are two very different methodologies and it depends on the given conditions which approach is more suitable and promising. Thus, before chosing one methodology, the team/organization must analyse internal and external circumstances and estimate the eligibility of each approach. | ||
| + | |||
| + | =Annotated Bibliography= | ||
| + | |||
| + | *Von Rosing M. et al., "Applying Agile Principles to BPM", Complete Business Process Handbook: Body of Knowledge From Process Modeling To Bpm — 2014, Volume 1, pp. 553-577 <BR> | ||
| + | Examination of characteristics, concepts and conventional fields of application of Agile in order to clearify important issues. What is Agile? Why is Agile needed? What is the difference between Agile and tradional approaches? | ||
| + | |||
| + | * Bomarius F. et al., "Product-Focused Software Process Improvement", 10th International Confernce, Springer, 2009 <BR> | ||
| + | Examination of software engineering and development. Provides a detailed explanation of Agile and the Waterfall model and how to apply the latter in large scale development. | ||
| + | |||
| + | *Dubey A.; Jain A.; Mantri A., "Comparative Study: Waterfall v/s Agile Model", International Journal of Engineering Sciences & Research Technology (IJESRT), 2015 <BR> | ||
| + | Identification and comparison of characteristics of Agile and the Waterfall model. | ||
=References= | =References= | ||
<references/> | <references/> | ||
Latest revision as of 19:41, 17 November 2018
Developed by Julian Ofenstein
There are two main software development methodologies: Waterfall and Agile. A development methodology is a procedure used by an engineering team in order to create the desired product.
The Waterfall methodology represents the traditional approach, where the development process is conducted in a linear series of events. On its way toward the conclusion, the progress flows continuously through the phases of a project lifecycle (analysis, design, development, testing, release) like a waterfall. The entire project is planned in advance.
Agile is a more recently developed software development methodology, where the linear approach is replaced by an incremental, iterative one. Instead of planning the whole project in advance, Agile enables the adaption of requirements during the whole project.
This article provides an introduction to each methodology, their pros and cons, and examples of use, in order to facilitate the decision whether Agile or Waterfall is more suitable for the next project.
Contents |
[edit] Waterfall Methodology
The lifecycle model which is today known as traditional or Waterfall model was first described by Royce in 1970.[1] It is called Waterfall model because of its sequential and down-flow characteristic where the phases analysis, design, implementation, testing and release are processed consecutively downwards.[2] Each phase of the Waterfall model is processed in order without any overlapping and within a specified time period. Once a phase is completed there is no going back to a previous phase as it will be frozen.[3]
Analysis
In this phase, all the requirements and customer needs of the desired system or product are gathered and recorded in detail in a specification document.[2] This document will be used as input in the design and implementation phase. The requirements of the product should be clear before moving to the next phase as changes in requirements cannot be adapted later in the process.[3]
Design
The outcome of the design phase is a specified hardware and a virtual overview of the desired system or software.[2]
Implementation
The actual development of the system starts in the implementation phase. The system is therefore divided into small subunits which are tested by the developers before forwarding them to the testing phase. A quality gate checklist helps to control if there is a deviation from the requirements, planned timeline and product scope.[4]
Testing
In this phase, the subunits are integrated into one working system which is tested regarding quality and functional aspects. The collected measures of performance are used for the decision whether the system is ready for the release. In order to ensure that the outcome of the project meets the customers' requirements, the tested system is reviewed according to a checklist. [4]
Release
The product gets prepared for being released into the market or delivered to the customer (including installation instructions of the system for customers and user-guides). There is another quality gate in order to check if the final product meets the customer and quality requirements and whether it is delivered in time. [4]
Maintenance
After releasing the product in the customer environment there can occur problems in the performance of the product. Hence, the company must provide maintenance in order to solve this issues.[4]
The general literature has identified the following pros and cons of the Waterfall methodology:[2][3]
[edit] Pros
- All requirements are clearly documented before the development of the product starts
- The time period for finishing each phase before moving to the next is specified
- Waterfall is simple to implement as it is a linear model
- Small amount of resources needed for implementing the waterfall methodology
- Each phase follows appropriate documentation in order to ensure high quality of development
[edit] Cons
- You cannot return to a previous phase. If the design phase fails the project might become very complicated in the implementation phase
- If a customer wants to change requirements of the product they cannot be implemented in the current development process
- Even small changes or errors in the finalized product might be very costly and cause a lot of problems
[edit] Agile Methodology
The Agile methodology uses an incremental, iterative approach instead of a linear and sequential one. Instead of extensive planning in advance, it provides practices, tools and a culture that enable close collaboration of a team in a quickly changing environment. During several successive iterations with a predetermined duration, the team develops working products in order to get continuous feedback from the customer.[5] Every iteration consists of a planning and analyzing phase followed by a fast design, build and test phase and results in deployment.[6] This procedure enables the team to improve the product with every iteration by adapting the backlog, a list of prioritized requirements for each iteration. Furthermore, Agile approaches emphasize teamwork and communication. The teams are selforganized and cross-functional (incorporating planners, designers, developers and testers) with empowered members. This team set-up motivates to create high-quality outcomes.[5]
Scrum, Kanban, Lean, Extreme Programming (XP) and Feature Driven Development (FDD) are popular methods of the Agile methodology that provide concrete agile practices and comprise the following characteristics:[6]
- Responsiveness: being able to provide an appropriate response to any changes
- Flexibility: being able to adapt to changes at every time
- Speed: enable rapid and iterative development of a product
- Leannes: focus on cost saving, high quality and a short time frame
- Learning: ability to improve before and after product development
Generally, the different methods of Agile differ slightly one from the other but contain practices that cover the full range of product development. In some cases, it is recommendable to combine different practices in order to create a situation-specific method.[6] All Agile methodologies have in common, that they are driven by Agile values and principles, which are explained in the Agile Manifesto published in 2001:[7]
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The twelve principles of Agile enlarge on this four value statements:[8]
- Early customer satisfaction through delivering valuable software
- Meeting changing requirements even if they occur late in development
- Frequent delivery of working software
- Daily collaboration between business people and developers
- Projects are built by motivated individuals
- Face-to-face conversation is the best way of communication
- Working software is the most important measure of progress
- Sustainable development with a constant pace
- Permanent focus on excellent technique and good design
- Simplicity
- Working in self-organized teams
- Regular adaption to changes
The general literature has identified the following pros and cons of Agile methodologies:[2][5][9]
[edit] Pros
- Changing requirements can be implemented at any phase of the process due to short development cycles
- An icrement of a product can be developed very quickly
- Continuous improvement enables fast and high-quality delivery
- Continuous dialogue between the customer and the development team ensures immediate user feedback
- The Agile methodology attaches great importance to teamwork as it requires frequent communication and face-to-face interactions.
[edit] Cons
- High dependency on collaboration with the customer. Especially in long projects that is not always possible
- Due to lack of documentation, there is an increased dependence of interaction between developers
- Compared to linear and sequential models agile methodologies are more difficult to comprehend
- When used in large and complex projects it is difficult to estimate the costs and schedule
- Knowing that changes are possible the team could take hurried decisions without a proper analysis
[edit] Waterfall or Agile?
As a sequential model, Waterfall works best for simple projects where the requirements are clear and will not change during the development process.[3] A good consensus with the customer and decision-making based on facts are favored frame conditions.[5]
Methods which follow the Agile methodology are well suited for complex and complicated projects as requirements are not always clear and may change throughout the development process. Therefore, a close exchange with the customer, an immediate customer feedback and the ability to adapt to quickly changing requirements are important properties for a successful conclusion of such projects.[5] Also, projects in a team-oriented environment may prefer an Agile method as it encourages high interaction between all stakeholders and involved designers. [6]
Projects with a very high level of uncertainty and disagreement with the customer should be rejected or avoided until the conditions change. After exceeding a certain point of complexity the expectation for a successful completion of the project is little. There is no adequate method that works under these circumstances. [5]
[edit] Example of Use
The following examples demonstrate the different approaches of each methodology.[10] [11] The project goal is the development of a virtual customer address book. In the beginning, a document with the following requirements is created by the product manager:
• Enable user to create new contacts
• Enable user to see his contacts
• Enable user to import contacts from other applications
• Enable user to email his contacts from the address book
• Enable user to add pictures to represent his contacts
[edit] Waterfall Model
Product Requirements
The created document will comprise detailed requirements, user scenarios and potential structures of the final product.
Analysis
The document is discussed and analysed with the engineering team in order to provide for clarity. At the end of this phase, all requirements should be clear and the product manager can update document.
Timeframe: 3 week
Design Engineering team creates a design for the product, including database design, mockups and workflows.
Timeframe: 3 weeks
Implementation The engineering team develops the address book and last preparations for testing are made.
Timeframe: 1 week
Testing The product team conducts various tests on the developed address book and reviews its entire functionality.
Timeframe: 2 weeks
Release The fully working product is released.
TOTAL elapsed time: 9 weeks
[edit] Agile Model
Product Requirements
The created document will be simple and list the requirements of the product by priority. Questions will arise during each iteration and can be discussed as they occur. For each iteration some requirements from the list are choosen, starting with the highest prioritized ones.
Timeframe: 1 week
Iteration Nr.1 The development team starts working on the product, which comprises the features to create new contacts and to view contacts. This process includes designing, developing and testing of the features. At the end of the iteration, the product manager examines the first increment of the product. The team receives a feedback and further changes can be discussed.
Timeframe: 2 weeks
Iteration Nr.2 The team continues working on the product and adds the features to import contacts, to email and to add pictures to the contacts. Again, this process includes designing, developing and testing of the features. At the end of the iteration, the next increment of the product is demonstrated to the product manager. The team receives another feedback and further changes can be discussed.
Timeframe: 2 weeks
Iteration Nr.3 Team conducts a regression test in order to make sure that the new adaptions did not cause any errors in the product already tested and prepares the product for the release.
Timeframe: 1 week
Release The product is released.
Total elapsed time: 6 weeks
Any adaptions or changes in requirements during the project would cause an adjustment of the concerned iteration.
[edit] Findings and Conclusion
As already discussed, the Waterfall model is a linear model with a sequential set of processes where the development "flows" from the start point to the delivery of a working product with several stages in between. Waterfall is a plan-driven methodology and hence, the whole project strictly follows a clear plan, which requires extensive planning upfront. That allows an estimation of costs and timeline which can be discussed with the customer in advance. The existence of an elaborated plan and clear documentation also results in a more secure project as everyone exactly knows what to do and new members can easily join the team.
In comparison, the Agile methodology provides flexible models which enable adaptive planning and development. While the product delivery at Waterfall occurs at the very end of the process, Agile methods are divided into small releases which provide the customer with small increments of the final product. During several iterations, the team works on this small packages of the product what allows direct customer feedback at the end of every iteration. Thus, rapid and effective responses to changing customer requirements are possible. But in return, it also requires the permanent availability of the customer.[6]
Waterfall and Agile are two very different methodologies and it depends on the given conditions which approach is more suitable and promising. Thus, before chosing one methodology, the team/organization must analyse internal and external circumstances and estimate the eligibility of each approach.
[edit] Annotated Bibliography
- Von Rosing M. et al., "Applying Agile Principles to BPM", Complete Business Process Handbook: Body of Knowledge From Process Modeling To Bpm — 2014, Volume 1, pp. 553-577
Examination of characteristics, concepts and conventional fields of application of Agile in order to clearify important issues. What is Agile? Why is Agile needed? What is the difference between Agile and tradional approaches?
- Bomarius F. et al., "Product-Focused Software Process Improvement", 10th International Confernce, Springer, 2009
Examination of software engineering and development. Provides a detailed explanation of Agile and the Waterfall model and how to apply the latter in large scale development.
- Dubey A.; Jain A.; Mantri A., "Comparative Study: Waterfall v/s Agile Model", International Journal of Engineering Sciences & Research Technology (IJESRT), 2015
Identification and comparison of characteristics of Agile and the Waterfall model.
[edit] References
- ↑ Sommerville I., "Software process models", ACM Computing Surveys (CSUR), vol. 28, pp. 269-271, 1996
- ↑ 2.0 2.1 2.2 2.3 2.4 Dubey A.; Jain A.; Mantri A., "Comparative Study: Waterfall v/s Agile Model", International Journal of Engineering Sciences & Research Technology (IJESRT), 2015
- ↑ 3.0 3.1 3.2 3.3 Balaji S.; Dr. Sundararajan Murugaiyan M., "Waterfall vs V-Model vs Agile: A Comparative Study on SDLC", International Journal of Information Technology and Business Management (JITBM), 2012
- ↑ 4.0 4.1 4.2 4.3 Bomarius F. et al., "Product-Focused Software Process Improvement", 10th International Confernce, Springer, 2009
- ↑ 5.0 5.1 5.2 5.3 5.4 5.5 Boral S.,"Domain I: Agile Principles and Mindset", Ace the Pmi-acp pp. 1-27, 2016
- ↑ 6.0 6.1 6.2 6.3 6.4 Von Rosing M. et al., "Applying Agile Principles to BPM", Complete Business Process Handbook: Body of Knowledge From Process Modeling To Bpm — 2014, Volume 1, pp. 553-577
- ↑ Schwaber K. et. al., "Manifesto for Agile Management", 2001, Retrieved from http://agilemanifesto.org/ 22.09.2017
- ↑ K. Schwaber et. al., "Twelve principles of agile software", 2001. Retrieved from http://agilemanifesto.org/principles.html 22.09.2017
- ↑ Shiotsu Y., "Agile vs. Waterfall: A Side-by-Side Comparison", Retrieved from https://www.upwork.com/hiring/development/agile-vs-waterfall/, 22.09.2017
- ↑ "Product development: The Waterfall methodology (model) in software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-the-waterfall-methodology-model-in-software-development/, 22.09.2017
- ↑ "Product development: Using Agile methodology for software development", 2009, Retrieved from https://www.marsdd.com/mars-library/product-development-using-agile-methodology-for-software-development/, 22.09.2017
