Waterfall Model

10 Key excerpts on "Waterfall Model"

• 

  eBook - PDF

  Programming with C++

  • Kyla McMullen, Elizabeth Matthews, June Jamrich Parsons, , Kyla McMullen, Kyla McMullen, Elizabeth Matthews, June Jamrich Parsons(Authors)
  • 2021(Publication Date)
  • Cengage Learning EMEA

    (Publisher)

  Additional advantages include: • With specifications locked down, programmers have a clear mandate and don’t need to be concerned with last-minute change orders that might have a domino effect throughout the code. • The documentation created during the analysis and design phases needs only minor edits to become documentation for the final software product. The major criticism of the Waterfall Model is its lack of flexibility. During the analysis and design phases, developers rarely can anticipate every way in which users will interact with the software. Business policies and regulations might change while development is ongoing. Because the software specifications are locked down at the beginning, developers have limited leeway to add or improve features during the coding phase. Figure 29-4 Phases of the waterfall development model Analysis Design Coding Testing Deployment List of requirements Software specifications Alpha version of software Beta version of software Production version of software Analysis: Analyze what the software is supposed to accomplish. Design: Develop algorithms and data structures that specify how the requirements should be implemented. Coding: Create working modules that fulfill all of the specifications. Testing: Test the modules to make sure they work as specified. Deployment: Deliver and distribute the final product. Out of the chaos emerged a systematic approach to software development based on a rigidly structured sequence of analysis and design phases. This approach, known as the Waterfall Model, divides software devel- opment into a series of cascading tasks that are performed one after the other. As shown in Figure 29-4, each phase produces a deliverable that is the input for the next phase. Q Suppose you are a member of a development team producing an advanced driver assistance system (ADAS) that monitors blind spots, helps drivers stay in their lane, and autonomously avoids collisions.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  How to Manage Projects

  Essential Project Management Skills to Deliver On-time, On-budget Results

  • Paul J Fielding(Author)
  • 2019(Publication Date)
  • Kogan Page

    (Publisher)

  Figure 7.1 .

  Figure 7.1  Sequential project representation

  This type of project depiction has been around for some time. Someone thought this looked like water falling down a set of rapids; maybe the arrowheads are the splash as the water hits the lower landing. With that, they called this the Waterfall Model , and the colloquial term stuck. If you mention this term to just about any English-speaking project manager, they will know exactly what you mean.

  When a project has these characteristics:

  • you are able to gather adequate, complete, accurate requirements (to which everyone agrees);
  • you have access to sufficient knowledge about what such a project takes to complete; and
  • the project is constructing something in a physical/physical-like sense;

  then you can follow these steps:

  1. Gather complete requirements and get all relevant parties to agree on the requirements.
  2. Design what it is you intend to build – and develop a plan for how you will build it.
  3. Build it/implement your design.
  4. Validate /confirm you got it right.
  5. Maintain /deliver what you built.

  Some texts may refer to this model as the predictive lifecycle, because you must start the project by predicting all the things that your team must do. When you can follow these steps, the predictive/waterfall lifecycle model is probably the most efficient, effective project model you can use. See Figure 7.2 .

  Figure 7.2  The predictive Waterfall Model

  Over time the project progresses in order through steps from Requirements to Design to Implementation to Verification to Maintenance.

  There are two key assumptions implicit to this model.

  Assumption 1

  That you are able to gather adequate, complete, accurate requirements – and get everyone to agree on those requirements

  You might think no one would start a project without knowing the goal. Go back to the opening scenario in Chapter 2

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Software Engineering

  • Kassem Saleh(Author)
  • 2009(Publication Date)
  • J. Ross Publishing

    (Publisher)

  One of the strengths of the Waterfall Model is that it is well structured with clearly identified phases. Each phase has well-specified inputs and deliverables and is composed of a set of activities. In addition, as a result of the activities of the Waterfall Model phases, a large amount of documentation is produced. Although it seems that this amount of documentation is excessive and costly, in the long term, the detailed documents reduce future maintenance cost.

  An ideal realization of the Waterfall Model implies that once a phase is completed and its deliverables are approved, the subsequent phase can start. The development activities are executed in sequence without a need to repeat any of the preceding activities. However, in practice, although a phase is complete, errors discovered in later phases might be traced backward to an already completed phase. Hence, a realistic Waterfall Model is more iterative in nature, allowing the revisiting of preceding phases if necessary. For example, if, during the design phase, an ambiguity in the software requirements is discovered, the designer has to report this error to the manager, and the analysis team has to deal with this ambiguity. Ignoring this error during the design might have severe consequences, including higher repair cost to deal with the same error in the future. In addition, it would be irresponsible and unethical for the designer to ignore or neglect reporting this analysis error in a timely fashion and through the proper reporting channels. Similarly, while in the coding phase, the programmer might discover a flaw in the detailed design. This flaw must be reported to the designers and the appropriate actions must take place to address the error. Figure 2.1 illustrates, with dashed arrows, the iterations needed from one phase to its preceding phases. Table 2.2 shows the phases of the Waterfall Model and their corresponding deliverables.

  Figure 2.1 Waterfall Model phases and its ongoing umbrella activities

  Table 2.2 Software life cycle development phases and corresponding deliverables

  2.4 SOFTWARE MAINTENANCE ACTIVITIES

  After the proper installation and acceptance of the software, its intended users begin running the software by invoking its functions or services. Software maintenance activities include the management of software improvement requests, the identification, categorization, and prioritization of needed improvements, and the scheduling and execution of the needed improvements.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Beyond Agile

  How To Run Faster, Smarter and Less Wasteful Projects

  • Andrew Walker, Paul Scott, Grace O'Brien(Authors)
  • 2017(Publication Date)
  • 3wks

    (Publisher)

  Once the code is written and delivered, the project advances into the testing and quality assurance phase. Here the software is tested against the requirements outlined way back in steps one and two. Tests can include things like unit testing, integration testing and system testing. There is, naturally, a lot of recording and documenting of test cases and test results.

  7. Delivery

  Assuming the architecture, design and finished product meet the original requirements of the project, the software is finally delivered. This includes presenting, installing and configuring it for the intended user. Sometimes, resources are dedicated to supporting users post-delivery to troubleshoot any issues and bugs.

  This is a very simplified version of waterfall, and it’s also just that – a version. Waterfall exists in many different forms. But at the heart of the method is the notion of sequence; of arpeggiated steps, strictly followed. Progression to one step in the sequence is contingent on one’s completion of its predecessor. There is no iteration. Once the water has flowed over the edge, the only way is down.

  Waterfall is somewhat of a cumbersome methodology, but it’s easy to see what made it so attractive in the late 20th century. By its very nature and design, waterfall enforced structure on development projects. It controlled decision-making processes and kept things moving along a predictable, manageable schedule of work that advanced from planning through to development. On paper it makes near-perfect sense.

  This is perhaps why waterfall rose to great popularity in the first place, and why it remains the default modus operandi in many industries today. Automobile manufacturing is a good example of such an industry. When producing cars, manufacturers typically don’t consult their customers at every step for their feedback. Why? Well, for the most part, car manufacturing is a heavily automated, standardised and regulated process – and with good reason. Making small iterations to the design of a car in response to customer feedback would likely result in some seriously unsafe, ugly, unbefitting cars. And there are already enough of those on the market.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Beginning Software Engineering

  • Rod Stephens(Author)
  • 2022(Publication Date)
  • Wiley

    (Publisher)

  The water represents information and the stages act like buckets. When one bucket is full (you’ve finished filling it up with information), the information floods from that bucket into the next so that it can direct the following task. The Waterfall Model can work reasonably well if all the following assumptions are satisfied: ➤ The requirements are precisely known in advance. ➤ The requirements include no unresolved high-risk items. ➤ The requirements won’t change much during development. ➤ The team has previous experience with similar projects, so they know what’s involved in building the application. ➤ There’s enough time to do everything sequentially. You can add additional steps or split steps to give more detail if you like. For example, you could break Verification into Testing and Validation, or you could break Design into High-Level Design and Low-Level Design. You can also elaborate on a step. For example, you could break Design into User Interface Design, Security Design, High-Level Design, Low-Level Design, and possibly other pieces. Few developers use the pure Waterfall Model these days, but some of its variations are quite useful. WATERFALL WITH FEEDBACK If you assume that you can carry out each step perfectly (and nothing changes during development), then the Waterfall Model leads to inevitable success. Unfortunately, it’s hard to perform every step of development perfectly. Because the model doesn’t allow you to go back to earlier steps, if you fail at Requirements Design Implementation Verification Deployment Maintenance FIGURE 17.1: In the Waterfall Model, each step follows the one before in a strict order. 434 ❘ CHAPTER 17 PREDICTIVE MODELS any step, then all of the later steps will be wrong. For example, if the requirements are wrong, then the development team plods along anyway, headed in the wrong direction like a cabbie trying to navigate in Singapore with a street map of London.

  Sign up to read

  Learn more about book
• 

  No longer available |Learn more

  How to Manage Projects

  Essential Project Management Skills to Deliver On-time, On-budget Results

  • Paul J Fielding(Author)
  • 2022(Publication Date)
  • Kogan Page

    (Publisher)

  The problem with capturing thoughts/managing knowledge work is that we do not develop thoughts in the same way we construct physical things. Thoughts often grow in response to a need. Thoughts might develop circularly. We might build our thinking from previous smaller thoughts, or have flashes of insight. Sometimes we need to think something through completely, see that we got it wrong, learn from our mistakes and start all over again (a disastrous process if you are constructing a building). Sometimes we develop ideas through random discussions with others. Knowledge work processes can be dramatically different from classical construct processes.

  For projects where software/knowledge capture is a major component, the Waterfall Model is not useful. Attempts to apply this model to such things made it the epitome of project management schemes everyone loves to hate. Often the term ‘predictive method’ is used pejoratively, implying that it is impossible to predict the future and therefore this model is silly.

  This model is not silly; it simply is not the right lifecycle model for managing certain activities.

  The Waterfall Model This model is virtually ideal:

  • when you are constructing something physical;
  • when you have adequate corporate familiarity/knowledge about the goal;
  • when you can develop good requirements; and
  • when you have corporate familiarity with what it will take to complete the components of the project.

  When these things are true, then a good way to model your project may be to:

  1. Develop good requirements everyone agrees with.
  2. Design the thing you intend to build – along with the process for building it.
  3. Implement your plan.
  4. Validate and confirm that what you built satisfies your requirements.
  5. Maintain or deliver what you built.

  The V-model

  The V-model is similar to the Waterfall Model, but it is folded, with explicit connections between the project’s final stages and the initial stages. Each development activity explicitly connects to a testing activity that measures the success of the development activity. Here steps come in a pairs; an activity/task pairs to a test. Defining the tests for an activity/task is a critical part of the planning stage. By knowing upfront what the test criteria are (knowledge), workers may focus on building what will pass these tests. The theory is if everything passes these tests, then you have created a successful product.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Software Testing and Continuous Quality Improvement

  • William E. Lewis(Author)
  • 2017(Publication Date)
  • Auerbach Publications

    (Publisher)

  The following provides an overview of the waterfall life-cycle development methodology and the associated testing activities. Deming’s continuous quality improvement is applied with technical review and testing techniques.

  Waterfall Development Methodology

  The life-cycle development or waterfall approach breaks the development cycle down into discrete phases, each with a rigid sequential beginning and end (see Figure 6.1 ). Each phase is fully completed before the next is started. Once a phase is completed, in theory during development, one never goes back to change it.

  In Figure 6.1 you can see that the first phase in the waterfall is user requirements. In this phase, the users are interviewed, their requirements are analyzed, and a document is produced detailing what the users’ requirements are. Any reengineering or process redesign is incorporated into this phase.

  In the next phase, entity relation diagrams, process decomposition diagrams, and data flow diagrams are created to allow the system to be broken down into manageable components from a data and functional point of view. The outputs from the logical design phase are used to develop the physical design of the system. During the physical and program unit design phases, various structured design techniques, such as database schemas, Yourdon structure charts, and Warnier–Orr diagrams, are used to produce a design specification that will be used in the next phase.

  Figure 6.1    Waterfall development methodology.

  In the program unit design phase, programmers develop the system according to the physical design produced in the previous phase. Once complete, the system enters the coding phase, where it will be written in a programming language, unit or component tested, integration tested, system tested, and finally, user tested (often called acceptance testing).

  Now the application is delivered to the users for the operation and maintenance phase (not shown in Figure 6.1

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Managing Information in the Public Sector

  • Jay D White(Author)
  • 2015(Publication Date)
  • Routledge

    (Publisher)

  Each of the approaches may apply to the development of new information systems consisting of hardware and software decisions, or to modifications of existing systems including hardware and software, or to just software acquisition or development by itself without reference to new hardware acquisitions. This distinction is important because many contemporary systems development improvements involve only additions to or modifications of software; an entire software acquisition capability maturity model will be addressed in this chapter. For now, it is best to think of the approaches to systems development as involving decisions about the development of software applications for existing hardware foundations, although hardware choices may also be needed in some circumstances.

  This chapter will present the major approaches to systems development and implementation in the following order: the waterfall method, prototyping, rapid applications development, agile software development, joint applications development, end user development, the Software Acquisition Capability Maturity Model (SA-CMM), types of system implementation, and finally systems maintenance. Some of the major similarities and differences among the major approaches will be noted.

  The Waterfall Method

  The waterfall method is also known as the systems development life cycle (SDLC) and has been around in one form or another since the mid-1960s.1 The term “waterfall” reflects the top-down approach of the SDLC as the systems development process proceeds from one step to another until the process has been completed, with each step being considered as a “deliverable,” in project management terms, that requires someone’s approval or “sign off.” Each stage in the life cycle cascades downward in a linear fashion until the project is completed.

  Given its long history, the steps in the SDLC have been enumerated in slightly different ways at different levels of detail, but the steps are pretty much all the same. Here the steps in the SDLC will be presented from the official Department of Justice Systems Development Life Cycle Guidance Document , which can serve as a model for all other depictions of the waterfall approach.2 Exhibit 7.1

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Mastering Software Project Requirements

  A Framework for Successful Planning, Development & Alignment

  • Barbara Davis(Author)
  • 2013(Publication Date)
  • J. Ross Publishing

    (Publisher)

  The Capability Maturity Model illustrates the need for a managed and optimized approach to processes in order to see consistent delivery and enable success in applying those processes. One of the key factors in Waterfall, which aligns to this model, is the delineation of roles across these managed processes. While this delineation and role definition are still evolving and changing, by and large the industry is making an effort to manage these roles to produce better results. Approaches—such as extreme programming—that attempt to remove layers and role definition, so every resource is more accountable and delivery can occur more rapidly, demand more of the allocated resources, and in the long run, the industry will see that this is not the answer.

  A systematic approach works best when everyone is on the same page and knows what to do and when to do it. Control gates throughout the process manage those pieces to ensure that key criteria are met before products with massive defects are released. However, control gates also require clear criteria, enforcement, and buy-in to be effective. Properly regulated and managed control gates allow projects to be held accountable for delivery standards at every stage of the development process and forces the team to justify the work being done with hard evidence. These controls play no favorites and are intended to prevent failing projects from advancing.

  RISKS OF WATERFALL

  The biggest risk from Waterfall is that there is no governing body, such as The Open Group or the Institute of Electrical and Electronics Engineers for Agile, to educate people and companies which choose to utilize it and to certify “levels” for practitioners. Furthermore, governance is left to companies to determine and manage. Again, resources—who may be full time employees or contract resources—apply the methodology inconsistently. It is important to note that the risk is primarily people-based, which results in inconsistent quality or requirements and a host of other project issues. These people-based issues result in problems from two perspectives: limited vision (scotoma) about how to change and overloading the resources, which reduces their ability to deliver quality outcomes.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Information Technology Project Management

  • Bennet Lientz(Author)
  • 2017(Publication Date)
  • Red Globe Press

    (Publisher)

  You really wanted to get each stage right before moving on to the next, because of the effort in making changes and rework. Thus, from the start, the SDLC was viewed as sequential stages. 296 IT ACTIVITIES Probably, the oldest sequential version of the SDLC was the Waterfall Model. This is a truly sequential model spanning definition through maintenance. Due to the sequential nature of work, after the requirements have been signed, there is no formal process to make changes due to new or modified requirements. As a result some systems that were implemented became obsolete on day 1 of operations. This is especially the case if requirements are not well-known and are fuzzy. This is especially true for projects that are complex or are long in duration. Some version of the SDLC is employed by almost every methodology. This is obvious since you have to know what you are going to do (requirements) and how to do it (design) before you can do it. However, change was in the wind due to: • Maturity of knowledge due to gathering experiences from development; • High failure rate of projects; • Real business need and benefit to be more adaptive to legitimate requirement changes; • New methods and tools including programming, designing, testing, and integration methods and tools; • Frustration with the sequential nature of the traditional life cycle. Evolution of development methods and tools Over the years many methods and tools for development have emerged. Tools are soft-ware packages that aid in the performance of specific tasks. Methods are approaches to undertaking design, development, and other work. Tools support methods. Failure can occur because of some of the following factors: • The method is unsupported by a tool so that the staff must resort to manual methods. • The tools are not compatible with each other, resulting in substantial duplication and even contradictory work.

  Sign up to read

  Learn more about book