Waterfall vs. Agile Methodology
| Line 6: | Line 6: | ||
=Waterfall Methodology= | =Waterfall Methodology= | ||
| − | The lifcycle 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 and testing 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 privious phase as it will be frozen.<ref>Balaji S.; Dr. Sundararajan Murugaiyan M., " | + | The lifcycle 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 and testing 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 privious 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> |
'''Analysis''' | '''Analysis''' | ||
In this phase all the requirements and customer needs of the desired system or product are gatherd and recorded in detail in a specification document.<ref name= "Comparative Study"/> This document will be used as input in the design and implementation phase. | In this phase all the requirements and customer needs of the desired system or product are gatherd and recorded in detail in a specification document.<ref name= "Comparative Study"/> 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 requirement can not be adapted later in the process.<ref | + | The requirements of the product should be clear before moving to the next phase as changes in requirement can not be adapted later in the process.<ref name= "Waterfall v/s Agile"/> |
'''Design''' | '''Design''' | ||
| − | The outcome of the design phase are a specified hardware and a virtual overview of the desired system or software.<ref | + | The outcome of the design phase are a specified hardware and a virtual overview of the desired system or software.<ref name= "Waterfall v/s Agile"/> |
'''Implementation''' | '''Implementation''' | ||
| − | The actual development of the system starts in the implementation phase. The system is therefor divided in small sub units 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 time-line and product scope.<ref>Bomarius F. et al., "Product-Focused Software Process Improvement", 10th International Confernce, Springer, 2009 </ref> | + | The actual development of the system starts in the implementation phase. The system is therefor divided in small sub units 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 time-line and product scope.<ref name= "Bomarius"> Bomarius F. et al., "Product-Focused Software Process Improvement", 10th International Confernce, Springer, 2009 </ref> |
'''Testing''' | '''Testing''' | ||
| − | In this phase the sub units are integrated to one working system which is tested regarding quality and functional aspects.<ref | + | In this phase the sub units are integrated to one working system which is tested regarding quality and functional aspects.<ref name= "Bomarius"> |
==Pros== | ==Pros== | ||
Revision as of 13:49, 22 September 2017
Most software development projects apply either the Waterfall or Agile methodology. A development methodology is the procidure used by an engineering team in order to create a 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 continously through the phases of a project (analysis, design, development, testing) 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 artice provides an introduction of each methodology, a comparison and examples of use, in order to facilitate the decision whether Agile or Waterfall is more suitable for the next project.
Waterfall Methodology
The lifcycle 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 and testing 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 privious phase as it will be frozen.[3]
Analysis
In this phase all the requirements and customer needs of the desired system or product are gatherd 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 requirement can not be adapted later in the process.[3]
Design
The outcome of the design phase are a specified hardware and a virtual overview of the desired system or software.[3]
Implementation
The actual development of the system starts in the implementation phase. The system is therefor divided in small sub units 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 time-line and product scope.[4]
Testing
In this phase the sub units are integrated to one working system which is tested regarding quality and functional aspects.[4]
Cite error:
<ref> tags exist, but no <references/> tag was found
