Waterfall Model - Revision history

User at 23:58, 16 August 2023

2023-08-16T23:58:08Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T19:13:16Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 17:28, 23 September 2019

2019-09-23T17:28:02Z

User at 16:23, 23 September 2019

2019-09-23T16:23:15Z

User at 15:54, 23 September 2019

2019-09-23T15:54:30Z

User at 15:50, 23 September 2019

2019-09-23T15:50:41Z

User at 15:45, 23 September 2019

2019-09-23T15:45:11Z

User at 19:48, 12 September 2019

2019-09-12T19:48:00Z

User: Created page with "'''Content coming soon'''"

2018-12-11T03:13:03Z

Created page with "'''Content coming soon'''"

New page

'''Content coming soon'''

@@ Line 41: / Line 41: @@
 *Ample resources with required expertise are available to support the product.
 *The project is short.
@@ Line 59: / Line 48: @@
 *Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between systems analysis and programming. This is because implementing any non-trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider.
 *In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with [[Risk]] Reduction".
-*Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and [[Incremental Development]].
+*Some organizations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and [[Incremental Development]].
 *While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to [[market]] alternative development methodologies.
 *[[Rational Unified Process (RUP)]] phases acknowledge the programmatic need for milestones, for keeping a project on track, but encourage iterations (especially within Disciplines) within the Phases. RUP Phases are often referred to as "waterfall-like".

@@ Line 1: / Line 1: @@
 == Definition of Waterfall Model ==
-The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining - What is the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>
+The waterfall [[model]] is a classical model used in [[system]] development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the [[output]] of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining - What is the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>
-The waterfall methodology is composed of seven non-overlapping stages:
+The waterfall [[methodology]] is composed of seven non-overlapping stages:
 *Requirements: Potential requirements, deadlines and guidelines for the project are analyzed and placed into a functional specification. This stage handles the defining and planning of the project without mentioning specific processes.
-*Analysis: The system specifications are analyzed to generate product models and business logic   that will guide production. This is also when financial and technical resources are audited for feasibility.
+*Analysis: The system specifications are analyzed to generate [[product]] models and [[business]] logic   that will guide production. This is also when financial and technical resources are audited for feasibility.
-*Design: A design specification document is created to outline technical design requirements such as programming language, hardware, data sources, architecture and services.
+*[[Design]]: A design specification document is created to outline technical design requirements such as programming language, [[hardware]], [[data]] sources, [[architecture]] and services.
 *Coding/Implementation: The source code is developed using the models, logic and requirements designated in the prior stages. Typically, the system is designed in smaller components, or units, before being implemented together.
-*Testing: This is when quality assurance, unit,  system   and  beta tests take place to report issues that may need to be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes the tests, the waterfall continues forward.
+*Testing: This is when [[quality]] assurance, unit,  system   and  beta tests take place to report issues that may need to be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes the tests, the waterfall continues forward.
-*Operation/Deployment: The product or application is deemed fully functional and is deployed to a live environment.
+*Operation/Deployment: The product or [[application]] is deemed fully functional and is deployed to a live environment.
 *Maintenance: Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update and enhance the final product. This could include releasing  patch   updates or releasing new versions.<ref>What are the stages of the Waterfall Model? [https://searchsoftwarequality.techtarget.com/definition/waterfall-model Techtarget]</ref>
@@ Line 17: / Line 17: @@
 == History of the Waterfall Method<ref>A History of the Waterfall Method [https://www.smartsheet.com/when-choose-waterfall-project-management-over-agile Smartsheet]</ref> ==
-Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements:  Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.
+Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large [[Software]] Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements:  Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.
-Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration Management Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.
+Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration [[Management]] Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.
-Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems Software Development. It described the software development cycle as follows:
+Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems [[Software Development]]. It described the software development cycle as follows:
-*Software Requirements Analysis
+*Software [[Requirements Analysis]]
 *Preliminary Design
 *Detailed Design
 *Coding and Unit Testing
-*Computer Software Component (CSC) Integration and Testing
+*[[Computer]] Software Component (CSC) Integration and Testing
 *CSCI Testing
-The forward states that “this standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.” However, the requirement was laid out in black and white and followed religiously.
+The forward states that “this [[standard]] is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software [[acquisition]] program.” However, the [[requirement]] was laid out in black and white and followed religiously.
-The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.
+The Waterfall method began to fade from popular use when [[industry]] leaders became frustrated with its inflexibility and developed the [[Agile Manifesto]]. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.
@@ Line 48: / Line 48: @@
 *The waterfall is easy to manage, sequential, and rigid method.
 *Agile is very flexible and it possible to make changes in any phase.
-*In Agile process, requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst.
+*In Agile [[process]], requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst.
 *In Agile Description of project, details can be altered anytime during the SDLC process which is not possible in Waterfall method.
@@ Line 58: / Line 58: @@
 *Designers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems.
 *Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between systems analysis and programming. This is because implementing any non-trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider.
-*In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction".
+*In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with [[Risk]] Reduction".
-*Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and Incremental Development.
+*Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and [[Incremental Development]].
-*While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies.
+*While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to [[market]] alternative development methodologies.
-*Rational Unified Process (RUP) phases acknowledge the programmatic need for milestones, for keeping a project on track, but encourage iterations (especially within Disciplines) within the Phases. RUP Phases are often referred to as "waterfall-like".
+*[[Rational Unified Process (RUP)]] phases acknowledge the programmatic need for milestones, for keeping a project on track, but encourage iterations (especially within Disciplines) within the Phases. RUP Phases are often referred to as "waterfall-like".

← Older revision		Revision as of 17:28, 23 September 2019
Line 41:		Line 41:
	*Ample resources with required expertise are available to support the product.		*Ample resources with required expertise are available to support the product.
	*The project is short.		*The project is short.
		+
		+
		+	== Agile Vs. Waterfall Model<ref>What is the Difference between Agile and Waterfall Model [https://www.guru99.com/waterfall-vs-agile.html Guru99]</ref> ==
		+	Agile and Waterfall are very different software development methodologies and are good in their respective way.The table below gives a view into the main difference between the two models. However, there are certain major differences highlighted below -
		+	*Waterfall model is ideal for projects which have defined requirements, and no changes are expected. On the other hand, Agile is best suited where there is a higher chance of frequent requirement changes.
		+	*The waterfall is easy to manage, sequential, and rigid method.
		+	*Agile is very flexible and it possible to make changes in any phase.
		+	*In Agile process, requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst.
		+	*In Agile Description of project, details can be altered anytime during the SDLC process which is not possible in Waterfall method.
		+
		+	[[File:Waterfall_Vs_Agile.png\|400px\|Difference between Agile and Waterfall Model]]<br />

← Older revision		Revision as of 16:23, 23 September 2019
Line 1:		Line 1:
−	The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>	+	== Definition of Waterfall Model ==
		+	The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining - What is the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>
		+
		+	The waterfall methodology is composed of seven non-overlapping stages:
		+	*Requirements: Potential requirements, deadlines and guidelines for the project are analyzed and placed into a functional specification. This stage handles the defining and planning of the project without mentioning specific processes.
		+	*Analysis: The system specifications are analyzed to generate product models and business logic that will guide production. This is also when financial and technical resources are audited for feasibility.
		+	*Design: A design specification document is created to outline technical design requirements such as programming language, hardware, data sources, architecture and services.
		+	*Coding/Implementation: The source code is developed using the models, logic and requirements designated in the prior stages. Typically, the system is designed in smaller components, or units, before being implemented together.
		+	*Testing: This is when quality assurance, unit, system and beta tests take place to report issues that may need to be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes the tests, the waterfall continues forward.
		+	*Operation/Deployment: The product or application is deemed fully functional and is deployed to a live environment.
		+	*Maintenance: Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update and enhance the final product. This could include releasing patch updates or releasing new versions.<ref>What are the stages of the Waterfall Model? [https://searchsoftwarequality.techtarget.com/definition/waterfall-model Techtarget]</ref>

← Older revision		Revision as of 15:54, 23 September 2019
Line 21:		Line 21:

	The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.		The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.
		+
		+
		+	== Waterfall Model - Application<ref>When Can the Waterfall Model be Applied? [https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm Tutorials Point]</ref> ==
		+	Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −
		+	*Requirements are very well documented, clear and fixed.
		+	*Product definition is stable.
		+	*Technology is understood and is not dynamic.
		+	*There are no ambiguous requirements.
		+	*Ample resources with required expertise are available to support the product.
		+	*The project is short.

@@ Line 2: / Line 2: @@
-[[File:Waterfall_Model.png|400px|The Waterfall Model]]<br />
+[[File:Waterfall_Model.png|500px|The Waterfall Model]]<br />
 source: [https://tech-talk.org/2015/01/21/system-development-life-cycle-sdlc-approaches/ Tech Talk]
@@ Line 21: / Line 21: @@
 The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.

← Older revision		Revision as of 15:45, 23 September 2019
Line 1:		Line 1:
	The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>		The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>
		+
		+
		+	[[File:Waterfall_Model.png\|400px\|The Waterfall Model]]<br />
		+	source: [https://tech-talk.org/2015/01/21/system-development-life-cycle-sdlc-approaches/ Tech Talk]
		+
		+
		+	== History of the Waterfall Method<ref>A History of the Waterfall Method [https://www.smartsheet.com/when-choose-waterfall-project-management-over-agile Smartsheet]</ref> ==
		+	Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements: Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.
		+
		+	Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration Management Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.
		+
		+	Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems Software Development. It described the software development cycle as follows:
		+	*Software Requirements Analysis
		+	*Preliminary Design
		+	*Detailed Design
		+	*Coding and Unit Testing
		+	*Computer Software Component (CSC) Integration and Testing
		+	*CSCI Testing
		+	The forward states that “this standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.” However, the requirement was laid out in black and white and followed religiously.
		+
		+	The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.

← Older revision		Revision as of 19:48, 12 September 2019
Line 1:		Line 1:
−	~~'''Content coming soon'''~~	+	The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.<ref>Defining the Waterfall Model [https://economictimes.indiatimes.com/definition/waterfall-model Economic Times]</ref>