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

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

5
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
6
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

7
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
  isnt documented, it probably isnt 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

8
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

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

10
Terminology cont

• Software Process, Methods, and Methodologies

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
(No Transcript)
16
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

17
Antiquated Software Life Cycle Models

• Code-and-Fix Development
• Waterfall

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

19
Waterfall

• Sequential stages with little or no backtracking

20
The Waterfall Model Illustrated
21
Risk Profile of Waterfall Project

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

22
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

23
Iterative and Incremental

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

24
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)

25
Modern Software Life Cycle Models

• Spiral
• Staged
• Evolutionary Prototyping
• Evolutionary Delivery

26
Spiral
27
Staged

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

28
Evolutionary Prototyping

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

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

30
Guidelines for Selecting a Lifecycle Model
31
Other forms of prototyping

• Evolutionary prototyping is a life cycle modela
  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.

32
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
  subjects actions Nielson 93.
• Most integrated development environments (IDEs)
  come with tools for creating UIs by dragging and
  dropping UI elements on a canvas. You dont 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 isnt 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.

33
Horizontal and vertical prototyping

• A prototype represents a subset of the eventual
  system functionality. There are two dimensions
  along which a prototype can vary.

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

35
Other definitions of horizontal and vertical
prototyping

• In the 1995 book, Advances in Computers, Marvin
  Zelkowitz defines horizontal and vertical
  prototyping such that the vertical axis is
  quality.
• This interpretation of the terms has been largely
  replaced by the definition given by Nielsen on
  page 94 in Usability Engineering 1993.

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

37
Throwaway Prototyping

• 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 proceed
  with a production-quality increment of the system
  under development.
• The creation of throwaway prototypes is standard
  engineering practice.

38
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

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

40
(No Transcript)