Transcript The Software Development Process

The Software Development
Process
"It is better not to proceed at all, than to
proceed without method." --Descartes
"Stop the life cycle--I want to get off"
-- Barry Boehm
A Software Development Process Organizes
the Activities of Software Development
. . .
Developing software without a
defined process is chaotic and
inefficient
. . .
Following a defined process
makes software development
more orderly, predictable and
repeatable
Software Process
• A software process is more detailed than a life
cycle model.
• A Software process says who does what when.
• A software process includes:
–
–
–
–
–
Roles
Workflows
Procedures
Standards
Templates
Resistance to Process
• Some people view following a process as an unnecessary
tax on productivity. That is, they view the time devoted to
following a process as taking away from time that could
otherwise be spent on “productive work” without any
otherwise appreciable affects on the development process
[McConnell 1998].
The Reality
• A group not following a defined process might show more
productivity at the start, but rework due to poor
development practices will quickly outweigh any time
saved by not following a process [McConnell 1998].
Too little process in the beginning often
leads to too much process towards the end
The overhead of following a process
decreases with time
When Bad Process Happens to
Good People
• Some processes are rigid and bureaucratic;
don’t use these
• Some people abuse process for their own
agenda (i.e. feed their desire to have power
and control, block changes or developments
they don’t agree with); don’t allow these
people to have authority over the process
Characteristics of a Good Process
• A good software process is:
– Repeatable – a process is repeatable if it can be performed again
on a new project? If the process isn’t documented, it probably isn’t
repeatable.
– Predictable – Organizations like predictability. It means they
know what to expect when repeating the process.
– Adaptable - the process can be tailored for the unique aspects of a
project. In general, the more adapted a process is, the less
predictable it will be.
– Learnable –
– Measurable – Measurability is important for tracking, control,
visibility and improvability.
– Improvable
Terminology
• Software Life Cycle – The high-level phases or stages that
software goes through from the moment it is
conceptualized until the last version is removed from the
last machine. The software life cycle consists of new
development followed by a number of maintenance
updates and finally retirement. [IEEE 610]
• Software Development Life Cycle (SDLC) – The
sequence of phases a project goes through from start to
finish. The standard phases of the SDLC are: requirements
specification, analysis, design, implementation and test.
Inception and delivery may also be included. Note, these
phases are not necessarily sequential. They may overlap or
be performed iteratively. The SDLC is applied to new
development and maintenance updates. [IEEE 610]
Terminology [cont]
• Software Life Cycle Models (aka Software
Process Models) – abstract models that describe a
class of development approaches with similar
characteristics. Some of the criteria used to
distinguish software life cycle models are: timing
between phases, entry and exit criteria between
phases and the artifacts created during each phase.
Examples include: Waterfall, Spiral, Rapid
Prototyping, Incremental Development, etc.
Terminology [cont]
• Software Process, Methods, and
Methodologies
Phase Names vs. Activity Names
• Is requirements (or design, or coding, or etc.) a
phase or an activity?
• Terms such as requirements, design, coding, etc.
are used to characterize a phase (adjective) and
also an activity (verb/adverb) that might occur
during one or more phases.
• It’s important to distinguish between a label given
to a phase and the activity that occurs during that
phase.
Phase Names vs. Activity Names [cont]
• The label on a phase is descriptive of the dominate
activity performed during that phase. It becomes
confusing when there isn’t a one-to-one
correspondence between phase name and activity
within that phase.
Phase Names vs. Activity Names [cont]
• The Rational Unified Process (RUP) avoids any
ambiguity/confusion by using phase names that
can’t be confused with the activities that might
take place during a phase.
• The names are also more appropriate because they
better match the milestones and deliverable of the
phases.
Software Life Cycle Models
• Abstract models that define a few broad types
of software development processes
• Life cycle models specify:
– Major phases including milestones and
deliverables
– Timing between each phase
– Entry and exit criteria for each phase
• Life cycle models are a starting point for
project management
Antiquated Software Life Cycle
Models
• Code-and-Fix Development
• Waterfall
Code-and-Fix Development
• Not a viable development model for most
projects.
• Code-and-Fix is to software development as
dog paddling is to swimming.
Waterfall
• Sequential stages with little or no
backtracking
The Waterfall Model Illustrated
Risk Profile of Waterfall Project
• When following the waterfall process model
risks aren’t resolved until late in the
development cycle.
What’s Wrong with these
Antiquated Life Cycle Models?
• Code-and-fix lacks discipline and is
inefficient
• Waterfall, although appropriate for some
projects, doesn’t fit well in today’s
environment
Iterative and Incremental
• A characteristic of modern life cycle
models. The product evolves incrementally
over a series of iterations.
Benefits of an Iterative and
Incremental Approach
• More appropriate for applications with emergent
requirements. For many UI applications,
requirements aren’t well-known form the start but
rather emerge over time based on experience with
early increments and prototypes.
• Incremental functionality is a more accurate
measure of progress than paper deliverables. This
provides better visibility into project status.
• Manages risks better (technical risks with
architecture and programming and project risks
with meeting schedule and budget targets)
Modern Software Life Cycle
Models
•
•
•
•
Spiral
Staged
Evolutionary Prototyping
Evolutionary Delivery
Spiral
Staged
• Requirements and planning occur up-front
but product is developed and delivered over
a series of iterations.
Evolutionary Prototyping
• The contents of each iteration is driven by
feedback from previous iterations.
Evolutionary Delivery
• The middle ground. Considerable planning and
product definition occur up-front, but the content
of each iteration is also influenced by feedback
from previous iterations.
Guidelines for Selecting a Lifecycle Model
Other forms of prototyping
• Evolutionary prototyping is a life cycle model—a way of
organizing the activities of software development.
• Prototyping can also be used selectively on any project as a
technique for buying information.
• Developing the wrong product can be costly. Sometimes it
pays to invest in an early quick-and-dirty prototype to
explore requirements and resolve technical risks before
committing to expensive production-quality development.
• With evolutionary prototyping the product increment is
expected to evolve into the eventual production system.
With other forms of prototyping the software created may
or may not be a part of the eventual implementation. If it is
a paper prototype, definitely not. If the prototype is a series
of screens created with an IDE, the screens may very well
end up in the final product.
Options for creating a prototype
• Paper mock-ups are perhaps the simplest form of prototyping. A paper
mock-up is a stack of fabricated screen shots created by hand or with
the help of a graphics editing or desktop publishing system. There
should be a page for every view and/or state of the application you
want to test. The experimenter simulates the behavior of the
application by showing different pages at different times in reaction to
the test subject’s actions [Nielson 93].
• Most integrated development environments (IDE’s) come with tools
for creating UI’s by dragging and dropping UI elements on a canvas.
You don’t have to implement the behavior behind each screen to have
a useful prototype. A small amount of control logic may be helpful to
move from screen to screen.
• If your target language isn’t conducive to prototyping, you can create
the prototype with a prototyping tool or high level (possibly scripting)
language that has better support for rapid application development.
Horizontal and vertical prototyping
• A prototype represents a subset of the eventual system
functionality. There are two dimensions along which a
prototype can vary.
Horizontal and vertical prototyping
• A horizontal prototype is one that includes many
features but little functionality behind each one.
Think of a movie set with store front facades but
no actual stores behind them. Horizontal
prototyping helps to clarify requirements and
evaluate usability.
• A vertical prototype is one that implements only a
few features but each one in depth. Vertical
prototyping can be used to explore various design
and implementation options.
Throwaway Prototyping
• When code is written quickly without regard for sound
engineering practices, it is poor bases on which to build
and should be thrown out once the goals for creating the
prototype have been accomplished. This form of
prototyping is appropriately called throwaway prototyping.
Anchoring the Software Process
• Intuitively—Requirements, Architecture,
Design, Code—seem like good milestones for
marking progress during a software project,
but in practice they don’t work so well.
• Rarely do these products evolve sequentially
as discrete entities.
• More commonly, these artifacts evolve slowly
in parallel. This makes them poor milestones
for anchoring a software development process
•
Anchoring the Software
Process
2
Barry Boehm proposes an alternative set of
milestones that are more appropriate for iterative
development [IEEE Software July 1996]:
– Life cycle objectives (Major requirements, major scenarios
of operation, candidate architecture, and top-level plan are
known)
– Life cycle architecture (Most requirements and scenarios of
operations are known, validated system architecture)
– Initial operational capability (The product is ready for
transition to its production environment.