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.
Waterfall Sequence 5%
Define Design Code Test Imp
Require Screens UI Test Scripts Training
Database Logic Defect Report Documentat
Objects Reports User ion
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.
Define Design Code Test Imp
SMEs SMEs Architects Testers Analysts
Analysts Analysts Coders Coders Coders
Proj Architects Proj. Mgr. Proj. Mgr. Proj. Mgr.
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
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
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
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.
Hard to accommodate
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
To define the project, design a solution, and monitor the project until it reaches
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.
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.
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
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.
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
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.
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.
Adaptive Project Framework
Agile Software Development
Dynamic Systems Development Model (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Information Technology Infrastructure Library (ITIL)
Joint Application Development (JAD)
Lean Development (LD)
Rapid Application Development (RAD)
Rational Unified Process (RUP)
Systems Development Life Cycle (SDLC)
TenStep Project Management Process
Waterfall (a.k.a. Traditional)