|
The waterfall model is a popular and an oldest version of the
systems development
life cycle model for software engineering. Often considered the classic approach to the systems development
life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development
has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once
the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it
cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development
proceeds to the next phase and there is no turning back. Here's a typical representation of the waterfall
model:
- VISION/VALIDATION - Business requirements are identified, success measures documented, and cost
and benefit analysis conducted to secure funding for the project. The feasibility study is conducted. A Vision
Scope document will summarize findings.
- REQUIREMENTS GATHERING AND DEFINITION/VALIDATION - The potential users are questioned to determine
the features and functionality that needs to be provided by the application or product. This process culminates
with the creation of high-level functional requirements document (captured in use case scenarios or purpose
statements) that will guide the rest of the phases.
- ANALYSYS AND PLANNING - During the Analysis phase, logic model of the application is built. Technical
Specifications created during this phase can be produced in two phases according to the nature of the project.
Initially this phase will examine "what" technically needs to occur within the project and does not initially
try to answer "how" it will be solved. Planners will then identify the Technical Designs, which show "how"
the technical work will be accomplished. Planners will also finalize "Who, When, and for how long" team members
will do the work that will be summarized in the Technical Specification.
- DESIGN/VALIDATION
- Architecture Design - high-level components and technologies are selected to build specific application
or product. Architecture defines the infrastructure to contain the system being developed - the common framework
into which all of the applications within an organization need to fit. The architecture provides consistence
and structure in the systems environment and also provides for greater degree of compatibility between systems
and applications in the environment.
- System Design - design details for specific application are worked out. The analysis model is applied
to create system design model. While Requirements Gathering and Analysis phases were working out "what"
functionality is needed, the System Design phase is responsible for working out "how" the system will be
implemented.
- IMPLEMENTATION/VERIFICATION - The descriptions of the desired system on paper are used to actually
implement the software, which usually amounts to coding.
- TESTING/VERIFICATION & ACCEPTANCE
- IN-HOUSE TESTING - The developer validates their work with unit or subsystem testing. The development
team passes this work onto the technical testing team for separate integration and system testing.
- BETA TESTING - User acceptance testing validates that the business requirements are met. Integration
testing validates system compatibility with the production environment and other system interactions. Related
documentation is concluded within this phase.
- DEPLOYMENT AND SUPPORT/REVALIDATION - Beta testing is continued with predefined user champions
in the production environment. This can be followed with a series of pilot tests in production where the number
of users increase at a controlled rate. Final production implementation concludes deployment.
The advantage of waterfall development is that it allows for departmentalization and managerial control.
A schedule can be set with deadlines for each stage of development and a product can proceed through the development
process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through
design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each
phase of development proceeds in strict order, without any overlapping or
iterative steps.
The disadvantage of waterfall development is that it does not allow for much reflection or revision.
Once an application is in the testing stage, it is very difficult to go back and change something that was not
well-thought out in the concept stage. Alternatives to the waterfall model include joint application development
(JAD),
rapid application development (RAD),
synch and stabilize,
build and
fix, and the spiral
model
Agile software development (ASD) is a methodology for the creative process that anticipates the need for
flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development
focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as
they're ready. The goal of ASD is to build upon small client-approved parts as the project progresses, as opposed
to delivering one large application at the end of the project. When larger teams are involved, the cycles can
be longer, to account for the difficulties in communication.
Using a agile method is not for everyone. There are a number of things to bear when deciding to follow this
path. In today's environment, the most common methodology is code and fix. Applying more discipline than chaos
will almost certainly help, and the agile approach has the advantage that it is much less of a step than using
a heavyweight method. Here much of the advantage of the agile methods is indeed their light weight. Simpler
processes are more likely to be followed when you are used to no process at all.
The following factors suggest for the adaptive (agile) process:
- Uncertain or volatile requirements
- Responsible and motivated developers
- Customer who understands and will get involved.
These factors suggest a predictive process like Waterfall:
- A team of over a hundred
- Fixed price, or more correctly a fixed scope, contract
Extreme Programming, or XP, is a derivative of Agile methodology - a lightweight discipline of software development
based on principles of simplicity, communication, feedback, and courage.
XP is designed for use with small teams who need to develop software
quickly in an environment of rapidly-changing requirements.
Extreme Programming is a pragmatic approach to program development that emphasizes business results first
and takes an incremental, get-something-started approach to building the product, using continual testing and
revision. The conception of Kent Beck, who has written a book about it,
XP proceeds with the view that code comes first. Beck emphasizes that in order to write the code,
however, you have to write a test for it first so that you will know when your code succeeds. Beck also introduces
the relatively novel idea that code should be written by pairs of programmers, forcing the main programmer to
describe the code to the other programmer and perhaps to stimulate further ideas.
Beck calls Extreme Programming a "lightweight methodology" that challenges the assumption that getting the
software right the first time is the most economical approach in the long run. Beck's fundamental idea is to
start simply, build something real that works in its limited way, and then fit it into a design structure that
is built as a convenience for further code building rather than as an ultimate and exhaustive structure after
thorough and time-consuming analysis. Rather than specialize, all team members write code, test, analyze, design,
and continually integrate code as the project develops. Because there is much face-to-face communication, the
need for documentation is minimized, according to Beck
XP was developed by Kent Beck, who wrote the original book
on the subject, Extreme Programming
Explained. Two new books will reach the market by October, Extreme Programming Installed, by Ron Jeffries
(your host), Ann Anderson, and Chet Hendrickson; and Planning Extreme Programming, by Kent Beck and Martin Fowler.
There are twelve key practices in XP:
- The Planning Process - also called The Planning Game, the
XP planning process allows the XP "customer" to define
the business value of desired features, and uses cost estimates provided by the programmers, to choose what
needs to be done and what needs to be deferred. The effect of XP's
planning process is that it is easy to steer the project to success by prioritizing implementation of the
most important features.
- Small Releases - XP teams put a simple system into
production early, and update it frequently on a very short cycle.
- Metaphor - XP teams use a common "system of names"
and a common system description that guides development and communication.
- Simple Design - A program built with XP should be
the simplest program that meets the current requirements. There is not much building "for the future". Instead,
the focus is on providing business value. Of course it is necessary to ensure that you have a good design,
and in XP this is brought about through "refactoring".
- Testing - XP teams focus on validation of the software
at all times. Programmers develop software by writing tests first, then software that fulfills the requirements
reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features
they need are provided.
- Refactoring - XP teams improve the design of the
system throughout the entire development. This is done by keeping the software clean: without duplication,
with high communication, simple, yet complete.
- Pair Programming - XP programmers write all production
code in pairs, two programmers working together at one machine. Pair programming has been shown by many experiments
to produce better software at similar or lower cost than programmers working alone.
- Collective Ownership - All the code belongs to all the programmers. This lets the team go at full
speed, because when something needs changing, it can be changed without delay.
- Continuous Integration - XP teams integrate and build the software system multiple times per day.
This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating
more frequently tends to eliminate integration problems that plague teams who integrate less often.
- 40-hour Week - Tired programmers make more mistakes. XP
teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.
- On-site Customer - An XP project is steered by a
dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the
programmers have them. The effect of being there is that communication improves, with less hard-copy documentation
- often one of the most expensive parts of a software project.
- Coding Standard - For a team to work effectively in pairs, and to share ownership of all the code,
all the programmers need to write the code in the same way, with rules that make sure the code communicates
clearly.
Iterative and Incremental development is especially known as a part of
Extreme Programming. The
basic idea behind iterative enhancement is to develop a software system incrementally, allowing the
developer to take advantage of what was being learned during the development of earlier, incremental,
deliverable versions of the system. Learning comes from both the development and use of the system,
where possible. At each iteration, design modifications are made along with addition new functional
capabilities.
The iteration step of the process involves the redesign and implementation of a task from project
control list, and the analysis of the current version of the system. The goal for the design and implementation
of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or
as a task added to the project control list. The code represents the major source of documentation of
the system. The analysis of an iteration is based upon user feedback and the program analysis facilities
available. It involves analysis of the structure, modularity, usability, reliability, efficiency, and
achievement of goals. The project control list is modified in light of the analysis results.
Guidelines that drive the implementation and analysis include:
- Any difficulty in design, coding and testing a modification should signal the need for redesign
or re-coding.
- Modifications should fit easily into isolated and easy-to-find- modules. If they do not, some
redesign is needed.
- Modifications to tables should be especially easy to make. If any table modification is not quickly
and easily done, redesign is indicated.
- Modifications should become easier to make as the iterations progress. If they are not, there
is a basic problem such as a design flaw or a proliferation of patches.
- Patches should normally be allowed to exist for only one or two iterations. Patches may be necessary
to avoid redesigning during an implementation phase.
- The existing implementation should be analyzed frequently to determine how well it measures up
to project goals.
- Program analysis facilities should be used whenever available to aid in the analysis of partial
implementations
- User reaction should be solicited and analyzed for indications of deficiencies in the current
implementation.
Using analysis and measurement as drivers of the enhancement process is one major difference between
iterative enhancement and the current
agile software development.
It provides support for determining the effectiveness of the processes and the quality of product. It
allows one to study, and therefore improve and tailor, the processes for the particular environment.
This measurement and analysis activity can be added to existing agile development methods.
Feature Driven Development (FDD) was developed by Jeff De Luca and long time OO guru Peter Coad. The idea
behind FDD is that strong but flexible design will create a process that is better managed and therefore more
efficient. Like the other adaptive methodologies, it focuses on short iterations that deliver "features" - small
pieces of project that possess some customer value. In FDD's case the iterations are two weeks long.
FDD has five processes. The first three are done at the beginning of the project.
- Develop an Overall Model
- Build a Features List
- Plan by Feature
The last two are done within each iteration.
- Design by Feature
- Build by Feature
Each process is broken down into tasks and is given verification criteria
The developers come in two kinds: class owners and chief programmers. The chief programmer are the most experienced
developers. They are assigned features to build. However they don't build them alone. Instead the chief programmer
identifies which classes are involved in implementing the feature and gathers their class owners together to
form a feature team for developing that feature. The chief programmer acts as the coordinator, lead designer,
and mentor while the class owners do much of the coding of the feature.
Until recently, documentation on FDD was very skimpy. Finally there is a full
book on FDD. Jeff De Luca, the primary inventor.
now has an FDD portal with articles, blogs, and discussion
boards. The original description was in Peter Coad et al's
UML in Color book. His company,
TogetherSoft, also does consulting and training on FDD.
The Unified Process is an iterative software design
method that was developed by Philippe Kruchten, Ivar Jacobson and others at Rational (now a division of
IBM) as the process complement to the UML. Ironically, RUP
is not an actual a process but a process framework and as such can accommodate a wide variety of processes.
Hence the main criticism of RUP - since it can be anything
it ends up being nothing. Many software developers prefer a process that tells you what to do rather than provide
endless options.
RUP describes how to effectively deploy software using commercially proven techniques. It encompasses a large
number of different activities, and is designed to be tailored, in the sense of selecting only the needed features
suited for a particular software project, considering its size and type. It is recognized to be particularly
applicable to larger software development teams working on large projects. As a result of this process framework
mentality, RUP can be used in a very traditional waterfall
style or in an agile manner. So as a result you can use RUP
as a agile process, or as a heavyweight process - depending on how it's customized.
Here are the basic ideas/rules behind the RUP:
- Iterative software development - given that requirements often change in course of the project, iteration
allows greater understanding of a project through successive refinements and addresses a project's highest
risk items as the highest priority task. Ideally each iteration ends up with an executable release - this
helps reduce a project's risk profile, allows greater customer feedback and helps developers stay focused.
- Requirements management - good documentation is essential for the success of the project. It includes
requirements gathering and working out use case scenarios.
- Component-based architecture - allows for easily extensible, reusable and understandable code.
- Use UML to visualize the software model. By the way,
this is Rational's marketing catch.
- Quality control - RUP assists in planning quality control and assessment built into the entire process
involving all members of a teams.
- Software changes control - RUP defines methods to control, track and monitor changes.
Craig Larman is a strong proponent of using the RUP in
a agile manner. His excellent introductory book
on OO development contains a process that's very much based on his light
RUP thinking. His view is that much of the recent push to
agile methods is nothing more than accepting mainstream OO development that's been captured as
RUP. One of the things that Craig does is spend the first
two or three days of a month long iteration with the whole team using the UML to outline the design of the work
to be done during the iteration. This is not a blueprint that can't be deviated from, but rather a sketch that
gives people a perspective on how things can be done over the iteration.
Another tack at agile RUP is Robert Martin's
dX process. The dx process is a fully compliant
instance of RUP, that just happens to be identical to
XP (turn dX upside down to see the joke). dX is designed for
folks that have to use RUP, but want to use
XP. As such it is both XP
and RUP and thus a good example of the agile use of
RUP.
This article uses excerpts from Martin Fowler's article, "The New
Methodology". The entire article can be found
here.
If you like this article, feel free to link to it from your website or your blog, or bookmark it.
|
