The waterfall method can be directly correlated with the Software development life cycle. Each stage in this method is directly linked to a corresponding stage with in the lifecycle.
According to Pfleeger and Atlee, the software development life cycle contains nine major milestones:
- Requirement Analysis and Definition
- System Design
- Program Design
- Application Implementation (Writing Code)
- Unit Testing
- Integration Testing
- System Testing
- System Delivery
The purpose of the requirement analysis and definition stage is to document desired application functionality and define general terms and concepts so that all stakeholders will have a universal understanding of the project regardless of background or experience. Also, the desired output articles are defined and the client’s method of delivery. However this stage is shortened in other software development methodologies like in agile programming because they return periodically to this stage to ensure that the program is meeting the clients current requirements and allows for more focuses to be applied to areas of the business that need more attention.
Common Sub processes of the requirements analysis and definition stage are:
- Interviews: Interviews with clients and users aid defining system requirements by obtaining system needs from a very general perspective.
- Documentation: The Interviews must be documented and compiled so that they can be reviewed collectively and used as the base information to derive the top level requirements by system analysts.
- Define Project Terms and Vocabulary: In order for all stake holders to communicate properly, the definition of general terms and concepts can be beneficial when communicating with stakeholders of various knowledge and backgrounds.
- Define Requirements, System Environment, Development Tools, and Development Language: This sub process is the most important process of the requirements analysis and definition stage because it extracts detailed requirements from the documented interviews to be used later in the system design process. Some methods like agile method do not spend as much time on this sub process compared to others like the waterfall method because they constantly iterating through all the SDLC stages multiple times before a project is considered complete.
- Define Project Outputs: All programming methodologies require this stage because this is where the required outputs of the project are defined. For example, a windows based desktop application would require an executable file as opposed to a web application that would need to be a series of files.
- Client Review/Acceptance: This stage can make or break a project regardless of methodologies because the client must first review the defined system requirements against what they thought they were requesting. In addition, the project can be stopped dead in its tracks if the client does not want to accept the purposed required work.
The system design stage is where the accepted requirements of the client are placed into a plan in order to ensure that all the requirements are met for the client. Typically this process decompresses the requirements so that they may be converted into basic components that show a relationship between each other. In addition, reference models are built in order to further examine the how the system will apply business functionality to components and what will be applied to the components. Finally various analyses will be applied to determine the best model based on tests like trade off analysis and cost-benefit analysis. One benefit of using the agile methodology is that every x number of days the system design will be review for accuracy against the old requirements and any changes made by the client.
Common Sub processes of the system design stage are:
- Design Process Plan: This plan is used to figure out how all the clients requirements can be integrated into one system.
- Create architecture reference models: These models show the decomposed requirements in a component form in order to so the relationships between all components. This is vital to the system design stage because it is the first look at converting system requirements into actually groupings so that designers can see how each component interacts with the others.
- Trade off Analysis: This analysis determines the best design based on technical benefits compared against other designs.
- Cost-Benefit Analysis: This analysis determines the best design based on costs of the design and business benefits against other designs.
The program design stage is where the foundation of a projects design principles are defined in order to have uniformity in regards to how required functionality and behaviors into component based modules. In addition, graphical representations for these components are also developed in order to document the design. Design patterns are also selected in order to define the best practices based on templates for common solutions.
Common Sub processes of the program design stage are:
- Definition of design principles: these principles are basic guidelines for how business rules should be broken down from functionality and behaviors into modules.
- Representations of designs: This takes the form of UML, and allows components to be viewed based on a graphical representation.
- Define design patterns: this is the process of codifying design decisions based on already documented best practices solutions for solving common problems.
The application implementation stage is where the bulk of the work is preformed in the waterfall method. Programming standards and procedures are defined as well as programming guidelines. Then finally the actual programming begins in this stage.
One thing to note is that the waterfall method only utilizes this stage once, so all the business functionally must be fully implemented at the end of the stage. On the other hand, agile methodologies allow and plan to enter this phase multiple times before the project is considered competed. This allows for more time to be taken to evaluate how the program is written and allow for the application to change as the business needs of the client change.
Common Sub processes of the application implementation stage are:
- Definition of programming standards and procedures: these standards and procedures are needed because multiple people could be working on code and need to understand why it was written, what was written, and how it is related to the work of others.
- Definition of programming guidelines: these guidelines ensure the design quality within the code
- Programming Process: This is the actual process of writing the program.
The stage of unit testing just like the writing of program stage is encountered multiple times in methodologies that apply agile concepts to development because once the code is altered in any way it must be again tested to ensure for accuracy and correctness.
Common Sub processes of the unit testing stage are:
- Examination of code: Code exams check for misunderstanding, inconsistencies, and other error that may occur by objective parties and their primary objective is to check for faults.
- Code walkthrough: Code walkthrough elevate misunderstandings between the developer and the system requirements because all the code and documentation sent for review by a third party to ensure that the code is correct based on the requirements.
- Formal code Proofing: views code as statements of logical flow, and then these statements are tested for correctness.
- Create test cases: According to Construx.com, test cases are a description of inputs, execution instructions, and expected results, which are created for the purpose of determining whether a specific software feature works correctly or a specific requirement has been satisfied.
- Apply test cases to code: This is the act of testing code with predefined test cases.
The stage of integration testing: like unit testing stage is encountered multiple times in methodologies that apply agile concepts to development because once the component code has been altered then it must be tested to ensure for accuracy and correctness.
Common Sub processes of the integration testing stage are:
- Definition of Test Plan: Pfleeger and Atlee define a test plan as defining the test objectives, designing test cases, writing test cases, testing test cases, executing tests, and evaluating the test results.
- Defining of test plan completion requirements: this defines when the test requirements have been meet an testing is complete.
- Perform tests: this is the act of implementing the test plan.
- The system test stage is very basic in that it tests the system to ensure that it does what the customer wants it to do. Typically this stage is only addressed in the waterfall method, however this stage could be multiple times before a project is considered to be complete.
Common Sub processes of the system testing stage are:
- Function Testing: this test compares the functionality of the system against the system requirements.
- Performance Testing: this test compares components with non functional system requirements like speed, security, and reliability.
- Acceptance testing: this test ensures the system that was built was developed based solely on there requirements.
- Installation Testing: this test is preformed at the actual installation site to ensure that the system functions properly and any additional problems are documented.
- Regression Testing: this test attempts to find new faults in the system as corrections for older faults are corrected.
The system delivery stage is only entered once all previous stages have been completed in the waterfall methodology and the system is ready to be delivered to the customer. Although agile methodologies can potentially deliver a system to the client every time new system development iteration is completed.
Common Sub processes of the system testing stage are:
- Installation: this is the act of actually installing the software at the client’s desired location.
- Training: this is the act of training the users and client how to use the system.
- Documentation: This is the act of providing all the corresponding project outputs to the client.
Once the project is completed both the waterfall and agile methodologies place the project into the maintenance phase. This phase basically updates the code in order to fix any unforeseen errors that may occur based on the customer requirements.
Common sub processes of the system testing stage are:
- Updates and Patches: this is the act of updating code base to account for system errors and bugs.
- Construx. (2009) Glossary. Retrieved July 27, 2009, from Thiyagarajan.WordPress.com Web site: http://www.construx.com/Page.aspx?hid=1279
- Pfleeger, S & Atlee, J.(2009). Software Engineering: Theory and Practice. Boston:Prentice Hall