why is the waterfall model valuable to the management of information technology projects

Document Sample
why is the waterfall model valuable to the management of information technology projects Powered By Docstoc

Software engineering is the practice of using selected process techniques to improve the
quality of a software development effort. This is based on the assumption, subject to
endless debate and supported by patient experience, that a methodical approach to
software development results in fewer defects and, therefore, ultimately provides shorter
delivery times and better value. The documented collection of policies, processes and
procedures used by a development team or organization to practice software
engineering is called its software development methodology (SDM) or system
development life cycle (SDLC).

Water Fall Methodology

Rather than try to give an all-encompassing definition for methodologies that should be
classified as waterfall approaches, it easier to describe some common characteristics.
Primarily, a waterfall methodology structures a project into distinct phases with defined
deliverables from each phase. The phases are always named something different,
depending on which company is trying to differentiate its own particular flavor, but the
basic idea is that the first phase tries to capture What the system will do (its
requirements), the second determines How it will be designed, in the middle is the actual
programming, the fourth phase is the full system Testing, and the final phase is focused
on Implementation tasks such as go-live, training, and documentation.

             15%       Design
                Waterfall Sequence                                            5%
                  Waterfall Deliverables
           Define        Design           Code         Test              Imp

          Require      Screens       UI           Test Scripts      Training
                       Database      Logic        Defect Report     Documentat
                       Objects       Reports      User              ion
                       Test Plan
                                     Project Management
                      Project Charter, Status Reports, Change Requests

Typically waterfall methodologies result in a project schedule with 20-40% of the time
budgeted for the first two phases, 30-40% of the time to the programming, and the rest
allocated to testing and implementation time. The actual project organization tends to be
highly structured. Most medium to large size projects will include a rigidly detailed set of
procedures and controls to cover everything from the types of communications to use in
various situations, to authorizing and tracking change orders, to the specific ways that
defects are logged, communicated, resolved, and re-tested.

Perhaps most importantly, waterfall methodologies also call for an evolution of project
staffing throughout the various phases. While typical consulting companies will refer to
the differences in staffing as simply “roles,” which imply that the same people could
remain on the project and simply switch roles, the reality is that the project staff
constantly changes as it progresses. Reasons for the change include economics,
mentoring, and expertise - economics in the sense that the project budget encourages
the replacement of a relatively highly paid architect with a lower paid staff programmer
as soon as possible. On the other hand, an architect with a particular skill set or an
analyst with valuable subject area knowledge may be demanded on another project. A
fundamental assumption is that the extensive project documentation and control
procedures enable relatively easy knowledge transfer to new project staff.

                      Waterfall Resources
            Define       Design            Code           Test           Imp

           SMEs         SMEs         Architects     Testers         Analysts
           Analysts     Analysts     Coders         Coders          Coders
           Proj         Architects   Proj. Mgr.     Proj. Mgr.      Proj. Mgr.
                        Proj. Mgr.
    Waterfall Strengths

    Most of the benefits from using a waterfall methodology are directly related to its
    underlying principles of structure. These strengths include:

■                          Ease in analyzing potential changes

■                          Ability to coordinate larger teams, even if geographically distributed

■                          Can enable precise dollar budget

■                          Less total time required from Subject Matter Experts

    Waterfall Weaknesses

    While waterfall has advantages, its highly structured approach also leads to
    disadvantages such as the following:

■                          Lack of flexibility

■                          Hard to predict all needs in advance

■                          Intangible knowledge lost between hand-offs

■                          Lack of team cohesion

■                          Design flaws not discovered until the Testing phase

    Spiral Methodology

    While the waterfall methodology offers an orderly structure for software development,
    demands for reduced time-to-market make its series steps inappropriate. The next
    evolutionary step from the waterfall is where the various steps are staged for multiple
    deliveries or handoffs. The ultimate evolution from the water fall is the spiral, taking
    advantage of the fact that development projects work best when they are both
    incremental and iterative, where the team is able to start small and benefit from
    enlightened trial and error along the way.

    The spiral methodology reflects the relationship of tasks with rapid prototyping,
    increased parallelism, and concurrency in design and build activities. The spiral method
    should still be planned methodically, with tasks and deliverables identified for each step
    in the spiral.
     1. P a rtial       2. P ro to typ e    3. R isk       4. D e sig n
  R e q u ire m e n t                      A n a lysi s

        Add                    7.                          5. C o d e
  R e q u ire m e n t   O p e ra tio n s   6. T e stin g

Rapid Prototype Model
Graphic representation of model:

       Waterfall Model              Rapid Prototype
                                        Model                    Spiral model
Pro.                             Pro.                   Pro.
    Documentation                   Allows frequent        Risk analysis preceding
    Maintenance easier           changes                each phase
    Quality product at finish       Helps define user      Allows for changing
                                 requirements           requirements
                                     Rapid return on       Allows prototyping
Con.                             Con.                   Con.
    Specification document          Increased               Once risk cannot be
    Have to get it right first   maintenance costs      mitigated the project is
time                                How do you know     terminated.
    Does not allow for           you are finished?          Not effective for large-scale
prototype                           Build-and-fix       projects.
    Time consuming
    Hard to accommodate
   Doesn’t accommodate
new requirements

Joint Application Development

What is a JAD?
    JAD Definition: Joint Application Development (JAD) is a management process which
    helps IS work effectively with users to develop information technology solutions that
    really work.

    JAD Purpose

    To define the project, design a solution, and monitor the project until it reaches

    JAD Philosophy

    The JAD process is based on four simple ideas:

          People who actually do a job have the best understanding of that job.
          People who are trained in information technology have the best understanding of
    the possibilities of that technology.
          Information systems and business processes rarely exist in isolation -- they
    transcend the confines of any single system or office and effect work in related
    departments. People working in these related areas have valuable insight on the role of
    a system within a larger community.
          The best information systems are designed when all of these groups work
    together on a project as equal partners.

    JAD Scope

    The JAD should cover the complete development life cycle of a system. The JAD is
    usually a 3 to 6 month well-defined project. For large-scale projects, it is
    recommended that the project be approached incrementally, and that separate JAD's
    be used for each increment.

    The real problem is typically very different from the one first perceived by the client.
    Don't just be a problem solver...look deeper. Don't assume that one person ever
    knows everything about a problem.

    Who is involved in a JAD?

    this is the executive who charters the project, the system owner. They must be high
    enough in the organization to be able to make decisions and provide the necessary
    resources and support for the project.

    Business Users
Intended users of the system being designed. They are here because of their
business expertise. There are two kinds of business users: real end users and big
picture users.

Real End Users

They will have to use the new system to do their jobs. Big Picture Users
understand the standards and methodologies of the business functions. It is
important to have both types of users, if you only have Big Picture Users you will
end up with a great theoretical model of how things should work, but it may not
work in practice, if you just have Real End Users, you will get a good system for
today, but it may not work a year or two down the road.

Systems Analysts

They provide non-technical explanations that help other JAD members
understand and fully utilize the technology available. Monitor design for ease of
use/maintenance and adherence to standards. Provide Hardware/software

Extreme Programming
    Rational Unified Process (RUP) Methodology

    The Rational Unified Process attempts to capture many of modern software
    development's best practices in a form suitable for a wide range of projects and
    organizations. This process recognizes that the traditional waterfall approach can be
    inefficient because it idles key team members for extended periods of time. Many feel
    that the waterfall approach also introduces a lot of risk because it defers testing and
    integration until the end of the project lifecycle. Problems found at this stage are very
    expense to fix.

    By contrast, RUP represents an iterative approach that is superior for a number of

          It lets you take into account changing requirements which despite the best efforts
    of all project managers are still a reality on just about every project.
            Integration is not one "big bang" at the end; instead, elements are integrated
            Risks are usually discovered or addressed during integration. With the iterative
    approach, you can mitigate risks earlier.
            Iterative development provides management with a means of making tactical
    changes to the product. It allows you to release a product early with reduced
    functionality to counter a move by a competitor, or to adopt another vendor for a given
            Iteration facilitates reuse; it is easier to identify common parts as they are
    partially designed or implemented than to recognize them during planning.
            When you can correct errors over several iterations, the result is a more robust
    architecture. Performance bottlenecks are discovered at a time when they can still be
    addressed, instead of creating panic on the eve of delivery.
            Developers can learn along the way, and their various abilities and specialties
    are more fully employed during the entire lifecycle. Testers start testing early, technical
    writers begin writing early, and so on.
            The development process itself can be improved and refined along the way. The
    assessment at the end of an iteration not only looks at the status of the project from a
    product or schedule perspective, but also analyzes what should be changed in the
    organization and in the process to make it perform better in the next iteration.

    Agile Modeling

    1.1 What is Agile Modeling (AM)?

    Agile Modeling (AM) is a practice-based methodology for effective modeling and
    documentation of software-based systems. Simply put, Agile Modeling (AM) is a
    collection of values, principles, and practices for modeling software that can be applied
    on a software development project in an effective and light-weight manner. The secret
    to AM isn’t the modeling techniques themselves -- such as use case models, class
    models, data models, or user interface models -- but how they’re applied. You may take
    an agile modeling approach to requirements, analysis, architecture, and design.

    AM is not a prescriptive process, in other words it does not define detailed procedures
    for how to create a given type of model, instead it provides advice for how to be effective
    as a modeler. AM is not about less modeling, in fact many developers will find that they
    are doing more modeling following AM than they did in the past. AM is “touchy-feely”,
    it’s not hard and fast – think of AM as an art, not a science.

    1.2 What is an agile model?

    Agile models are more effective than traditional models because they are just barely
    good enough, they don't have to be perfect. A paper prototype could be an agile model,
    a whiteboard sketch could be an agile model, a Visio diagram could be an agile model,
    or a physical data model (PDM) created using a CASE tool could be an agile model.
    The type of model, or the tool with which it was created doesn't really matter. What is
    important is that the model is just good enough for the task at hand.

    1.3 How does AM fit in?

    An important concept to understand about AM is that it is not a complete software
    process. AM’s focus is on effective modeling and documentation. That’s it. It doesn’t
    include programming activities, although it will tell you to prove your models with code. It
    doesn’t include testing activities, although it will tell you to consider testability as you
    model. It doesn’t cover project management, system deployment, system operations,
    system support, or a myriad of other issues. Because AM’s focus in on a portion of the
    overall software process you need to use it with another, full-fledged process such as
    XP, DSDM, SCRUM, or RUP as depicted in the figure below. You start out with a base
    process, such as XP or UP or perhaps even your own existing process, and then tailor it
    with AM (hopefully adopting all of AM) as well as other techniques as appropriate to form
    your own process that reflects your unique needs.

    Figure. AM enhances other software processes.

    1.4 What pain does AM address?

    Within many traditional environments modeling and documentation are almost always
    dysfunctional efforts which rarely add value and sometimes even cause a project to
    grind to a virtual halt under the weight of the artifacts being generated. As a result many
    developers think that modeling and documentation are a waste of their time, and in
    traditional environments they're often correct. It doesn't have to be this way.

    AM describes techniques which enable your modeling and documentation efforts to be
    very streamlined and effective, you can gain the benefits of modeling without the
    dysfunctional costs of useless documentation. Don't get me wrong, you still document,
    it's just that you do so in a very smart way.

    1.5 What are the benefits of Agile Modeling?

    The benefits of AM are:

           Cost effectiveness. AM defines a collection of values, principles and practices
    pertaining to effective, light-weight modeling and documentation. By creating models
    and documents which are just barely good enough you maximize stakeholder ROI.
           It defines explicit techniques for agile projects. AM addresses the issue of how
    agile developers model and document on software projects taking an agile approach
    such as eXtreme Programming (XP), Dynamic Systems Development Method (DSDM),
    or SCRUM. To quote Kent Beck from eXtreme Programming Explained (XPE) "We will
    continually refine the design of a system, starting from a very simple beginning. We will
    remove any flexibility that doesn't prove useful." Contrary to the claims of some of XP's
    detractors you do in fact invest time modeling when taking an XP approach, but only
    when you have no other choice. Sometimes it is significantly more productive for a
    developer to draw some bubbles and lines to think through an idea, or to compare
    several different approaches to solving a problem, than it is simply start hacking out
    code. Read the essay Agile Modeling and XP for more details.
           To improve modeling and documentation on prescriptive processes. AM
    addresses the issue of how to model effectively on a Unified Process (UP) project,
    common instantiations of which include the Rational Unified Process (RUP) and the
    Enterprise Unified Process (EUP). The RUP and EUP includes several modeling-
    oriented workflows -- Requirements, Business Modeling, Analysis & Design, Enterprise
    Business Modeling, Enterprise Architecture -- which when applied at face value can
    become quite burdensome. AM helps to improve the effectiveness of your modeling
    efforts on an UP project (or any project for that matter). Read the essay Agile Modeling
    and The Unified Process for more details.

    2. Agile Modeling In Practice

    2.1 What is Agile Model Driven Development (AMDD)?

    AMDD is the agile version of Model Driven Development (MDD). The following figure
    depicts a high-level lifecycle for AMDD for the release of a system. The initial modeling
    activity includes two main sub-activities, initial requirements modeling and initial
    architecture modeling. These are done during cycle (iteration) 0, the first iteration before
    you start into development cycles. The other activities – model storming, reviews, and
    implementation – potentially occur during any cycle, including cycle 0. The time
    indicated in each box represents the length of an average session: perhaps you’ll model
    for a few minutes then code for several hours.

    The fundamental idea is that you do just enough modeling to determine your strategy for
    proceeding. In the case of initial modeling you want to model just enough to identify and
    agree to the initial scope of your work as well as the potential architecture for your
    solution. With model storming you will work through higher level issues that are not well
    addressed with code. This might be an inclusive modeling session with your
    stakeholder(s) to understand their requirements, or could be a quick design session with
    other developers to determine how to build something.

    Figure 2. Taking an AMDD approach on a project.

    Other Methodologies

         Adaptive Project Framework
         Agile Software Development
         Crystal Methods
         Dynamic Systems Development Model (DSDM)
         Extreme Programming (XP)
         Feature Driven Development (FDD)
         Information Technology Infrastructure Library (ITIL)
         Joint Application Development (JAD)
         Lean Development (LD)
         PRINCE2
         Rapid Application Development (RAD)
         Rational Unified Process (RUP)
         Scrum
         Spiral
         Systems Development Life Cycle (SDLC)
         TenStep Project Management Process
         Waterfall (a.k.a. Traditional)

Description: Free pdf about why is the waterfall model valuable to the management of information technology projects