The Software Development Process

1
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
2
A Software Development Process Organizes the
Activities of Software Development
. . .
. . .
Following a defined process makes software
development more orderly, predictable and
repeatable
3
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.

4
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
5
When Bad Process Happens to Good People

• Some processes are rigid and bureaucratic dont
  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 dont
  agree with) dont allow these people to have
  authority over the process

6
Characteristics of a Good Process

• A good software process is
• Repeatable
• Predictable
• Adaptable
• Learnable
• Measurable
• Improvable

7
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

8
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.

9
Terminology cont

• Software Process, Methods, and Methodologies

10
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

11
Big-M Methodology
12
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.
• Its important to distinguish between a label
  given to a phase and the activity that occurs
  during that phase.

13
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 isnt a one-to-one
  correspondence between phase name and activity
  within that phase.

14
Phase Names vs. Activity Names cont

• The Rational Unified Process (RUP) avoids any
  ambiguity/confusion by using phase names that
  cant 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.

15
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

16
Antiquated Software Life Cycle Models

• Code-and-Fix Development
• Waterfall

17
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.

18
Waterfall

• Sequential stages with little or no backtracking

19
The Waterfall Model Illustrated
20
Whats Wrong with these Antiquated Life Cycle
Models?

• Code-and-fix lacks discipline and is inefficient
• Waterfall, although appropriate for some
  projects, doesnt fit well in todays environment

21
Risk Profile of Waterfall Project

• When following the waterfall process model risks
  arent resolved until late in the development
  cycle.

22
Iterative and Incremental

• A characteristic of modern life cycle models. The
  product evolves incrementally over a series of
  iterations.

23
Benefits of an Iterative and Incremental Approach

• More appropriate for applications with emergent
  requirements. For many UI applications,
  requirements arent 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)

24
Modern Software Life Cycle Models

• Spiral
• Staged
• Evolutionary Prototyping
• Evolutionary Delivery

25
Spiral
26
Staged

• Requirements and planning occur up-front but
  product is developed and delivered over a series
  of iterations.

27
Evolutionary Prototyping

• The contents of each iteration is driven by
  feedback from previous iterations.

28
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.

29
Guidelines for Selecting a Lifecycle Model
30
Throwaway Prototyping

• The creation of a prototype is standard
  engineering practice.
• With throwaway prototyping, a mock-up is created
  to learn more about a systems requirements,
  design or implementation. Once the goals of
  creating the prototype are accomplished, it is
  discarded and the information is used to inform
  the development of a production-quality version
  of the system.

31
Anchoring the Software Process

• IntuitivelyRequirements, Architecture, Design,
  Codeseem like good milestones for marking
  progress during a software project, but in
  practice they dont 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

32
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.

33
(No Transcript)