Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 29 views

    Limitations of A Sequential Process

    Uploaded by

    chalu account
    The document discusses the limitations of a sequential or waterfall development process. It notes that this approach pushes risk later in the project, making mistakes costly to fix. It also identifies two flawed assumptions: that requirements will remain frozen and the design can be fully worked out on paper before implementation. The document explains how requirements inevitably change and designs may have flaws not discovered until late in the process, making the sequential approach problematic for most projects. It concludes the waterfall model only works well for small, low-risk projects that are similar to past work.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Limitations of A Sequential Process

    Uploaded by

    chalu account
    29 views3 pages
    The document discusses the limitations of a sequential or waterfall development process. It notes that this approach pushes risk later in the project, making mistakes costly to fix. It also identifies two flawed assumptions: that requirements will remain frozen and the design can be fully worked out on paper before implementation. The document explains how requirements inevitably change and designs may have flaws not discovered until late in the process, making the sequential approach problematic for most projects. It concludes the waterfall model only works well for small, low-risk projects that are similar to past work.

    Original Title

    Limitations of a sequential process

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses the limitations of a sequential or waterfall development process. It notes that this approach pushes risk later in the project, making mistakes costly to fix. It also identifies two flawed assumptions: that requirements will remain frozen and the design can be fully worked out on paper before implementation. The document explains how requirements inevitably change and designs may have flaws not discovered until late in the process, making the sequential approach problematic for most projects. It concludes the waterfall model only works well for small, low-risk projects that are similar to past work.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    29 views3 pages

    Limitations of A Sequential Process

    Uploaded by

    chalu account
    The document discusses the limitations of a sequential or waterfall development process. It notes that this approach pushes risk later in the project, making mistakes costly to fix. It also identifies two flawed assumptions: that requirements will remain frozen and the design can be fully worked out on paper before implementation. The document explains how requirements inevitably change and designs may have flaws not discovered until late in the process, making the sequential approach problematic for most projects. It concludes the waterfall model only works well for small, low-risk projects that are similar to past work.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 3

    Limitations of a sequential process

    Sequential model is like a programming language without control structures!

    Most software teams still use a waterfall process for development projects,
    where they complete each phase in a strict sequence of requirements, then
    analysis and design, then implementation/integration, and then testing. Or,
    more commonly, a modified waterfall approach with feedback loops added
    to the basic overall flow just described. Such approaches leave key team
    members idle for extended periods of time and defer testing until the end of
    the project life cycle, when problems tend to be tough and expensive to
    resolve, and pose serious threats to release deadlines
    The fundamental problem of this approach is that it pushes risk forward in
    time so that it's costly to undo mistakes from earlier phases.
    Two fundamentally wrong assumptions in the sequential development
    process are
    1. Requirements will be frozen.
    2. We can get the design right on paper before proceeding.

    Requirements Will Be Frozen

    We must accept the fact that the requirements change as we proceed with the
    development work. New requirements continue to appear. Requirements
    change for many reasons.
    • The users change.
    The users' needs cannot be frozen in time. Over a period of time they
    become better educated as they see other systems and other products.
    Their own work environment evolves.
    • The problem changes.
    After the system is implemented or while it is being implemented, the
    system itself affects the perspective of users. As soon as the end users
    see how their intentions have been translated into a system, the
    requirements change. This is known as the IKIWISI effect: "I'll Know
    It When I See It." Users don't really know what they want, but they
    know what they do not want when they see it.
    • The underlying technology changes.

    New software or hardware techniques and products emerge, and we


    want to exploit them.

    • The market changes.

    The competition might introduce better products to the market. In this


    situation, there is no point of developing the perfect product relative to
    the original specification.

    • We cannot capture requirements with sufficient detail and precision.

    We Can Get the Design Right on Paper before Proceeding

    It is not possible to ensure that our design is the right (correct, efficient,
    feasible, and so on) solution to the problem. You can accumulate pages and
    pages of design documentation and hundreds of blueprints and spend weeks
    in reviews, only to discover, late in the process, that the design has major
    flaws that cause serious breakdowns.

    Sequential process may work

    The sequential, or waterfall, process works fine on projects in which we


    could clearly anticipate what would happen. This is true for small projects (a
    few weeks to a few months duration) and on projects in which all hard
    aspects were well understood. If the current project is somewhat like the one
    you completed in recent past and if you use the same people, the same tools,
    and the same design, the sequential approach will work well.

    You might also like