Software Processes

1
Chapter 3

• Software Processes

2
Software Processes

• Coherent sets of activities for specifying,
  designing, implementing and testing software
  systems.

3
Objectives

• To introduce software process models.
• To describe a number of generic process models
  and when they may be used.
• To outline lower-level process models for (1)
  requirements engineering, (2) software
  development, (3) testing, and (4) evolution.
• To introduce CASE technology to support software
  process activities

4
Topics covered

• Software process models
• Process iteration
• Software specification
• Software design and implementation
• Software verification validation
• Software evolution
• Automated process support

5
The software process

• A process is a structured set of activities
  required to develop a software system, e.g.
• Specification
• Design
• Validation / Verification
• Evolution
• A process model is an abstract representation of
  a process. It presents a description of a process
  from some particular perspective
• Models should be as simple as possible, but no
• simpler. A. Einstein

6
Generic software process models

• The Waterfall Model separate and distinct
  phases of specification and development.
  Traditionally not iterative.
• Evolutionary Development specification and
  development are interleaved.
• Formal Systems Development a mathematical
  system model is formally (or informally)
  transformed to an implementation.
• Reuse-Based Development the system is assembled
  from existing components.
• (And, at no additional cost Incremental,
  eXtreme, and Spiral.)

7
Waterfall model (W. Royce)
8
Waterfall model problems

• Inflexible partitioning of the project into
  distinct stages
• makes it difficult to respond to changing
  customer requirements.
• Thus, this model is only appropriate when the
  requirements are well-understood (to begin with).
• --------------------------------------------
  -
• In general, the drawback of the waterfall model
  is the difficulty of accommodating change after
  the process is underway.
• Can we say anything good about the Waterfall
  model?

9
Evolutionary development

• Exploratory Development objective is to work
  with customers and to evolve a final system from
  an initial outline specification. (Development
  starts with well-understood parts of system.)
  important theme in Agile Development
• Throw-Away Prototyping objective is to
  understand the system requirements. (Prototyping
  focuses on poorly understood requirements.)
• also known as exploratory programming, or
  evolutionary prototyping

10
Evolutionary development
customer
trash
11
Evolutionary development

• Potential problems
• Lack of process visibility. (via documents c.f.
  Waterfall model)
• Final version/prototype is often poorly
  structured.
• Special skills (e.g., in languages for rapid
  prototyping) may be required. -- working
  effectively with people
• Applicability
• For small or medium-size interactive systems.
• For parts of large systems (e.g., the user
  interface).
• For short-lifetime systems. (In the case of
  exploratory development why?)

12
Formal systems development

• Based on the transformation of a mathematical
  specification (through possibly several different
  representations) to an executable program.
• Transformations are correctness-preserving so
  it is possible to show that the program conforms
  to its specification.
• Embodied in Mills Cleanroom approach to
  software development.

13
Formal systems development
Code Generator?
Not realistic, unless Formal specification is
source code
14
Formal transformations
(futuristic)
15
Formal systems development

• Problems
• Need for specialized skills and training to apply
  the technique.
• Difficult to formally specify some aspects of the
  system such as the user interface (thus, focus is
  usually limited to functional requirements).
• Applicability
• Critical systems, especially those where a safety
  or security case must be made before the system
  is put into operation.
• Critical parts of large systems.

16
Reuse-oriented development

• Based on systematic (as opposed to serendipitous)
  reuse of existing software units.
• Units may be
• Procedures or functions (common for past 40
  years)
• Components (component-based development)
• Core elements of an application (application
  family)
• Entire applications -- COTS (Commercial-off-the-sh
  elf) systems
• May also be based on use of design patterns.

17
Reuse-oriented development

• Process stages
• Reusable software analysis (whats available?)
• Requirements modification why?
• System design with reuse
• Development and integration
• This approach is becoming more important, but
  experience is still limited.
• Software Repositories research was a major DoD
  thrust in the late 80s.

18
Reuse-oriented development
19
Process iteration

• For large systems, requirements ALWAYS evolve in
  the course of a project.
• Thus, process iteration is ALWAYS part of the
  process.
• Iteration can be incorporated in any of the
  generic process models. (but not in spirit of
  Waterfall)
• Two other approaches that explicitly incorporate
  iteration
• Incremental development (Mills)
• Spiral development (Boehm)

20
Mills Incremental development

• Rather than deliver the system as a single unit,
  the development and delivery is broken down into
  increments, each of which incorporates part of
  the required functionality.
• User requirements are prioritised and the highest
  priority requirements are included in early
  increments.
• Once the development of an increment is started,
  its requirements are frozen while requirements
  for later increments can continue to evolve.
• (Compromise between Waterfall Evolutionary
  development)

21
Mills Incremental development
22
Incremental development advantages

• Useful functionality is delivered with each
  increment, so customers derive value early.
• Early increments act as a prototype to help
  elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
  receive the most testing. (subject to more
  validation steps)

23
Potential problem with incremental development

• Requirements may NOT be partitionable into
  stand-alone increments. (e.g., a compiler)

24
Extreme programming (Beck 99)

• Recent evolution of incremental approach based on
• Development and delivery of very small increments
  of functionality
• Significant customer involvement in process
• Constant code improvement
• Egoless, pair-wise programming
• NOT document-oriented
• Gaining acceptance in some small (and now medium
  sized) organizations.
• Representative of the Agile development
  paradigm.
• www.agilealliance.org

25
Boehms spiral development

• Process is represented as a spiral rather than a
  sequence of activities.
• Each loop in the spiral represents a phase in the
  process.
• No fixed phases such as specification or design
  loops in the spiral are chosen depending on what
  is required.
• Explicitly incorporates risk assessment and
  resolution throughout the process.

26
Spiral model of the software process
27
Spiral model quadrants

• Objective Setting specific objectives for the
  phase are identified.
• Risk Assessment and Reduction risks are
  assessed and activities put in place to reduce
  the key risks.
• Development and Validation a development model
  for the system is chosen which can be any of the
  generic models.
• Planning the project is reviewed and the next
  phase of the spiral is planned.

28
Models for (lower level) fundamental process
activities

• Software specification/requirements engineering
  (RE)
• Software development (design and implementation)
• Software verification and validation
• Software evolution

29
Software specification / RE

• The process of establishing what services are
  required and the constraints on the systems
  operation and development.
• Requirements Engineering (RE) process
• Feasibility (technical and otherwise) study
• Requirements elicitation and analysis
• Requirements specification (documentation)
• Requirements validation

30
The requirements engineering process
31
Software design and implementation

• The process of producing an executable system
  based on the specification
• Software design design a software structure
  that realizes the specification.
• Implementation translate this structure into an
  executable program.
• The activities of specification, design, and
  implementation are closely related and may be
  interleaved.

32
Design process activities

• High-Level design activities
• Architectural design subsystems and their
  relationships are identified
• Abstract specification of each sub-systems
  services
• Interface design among sub-systems
• Low-Level design activities
• Component design services allocated to
  different components and their interfaces are
  designed
• Data structure design
• Algorithm design

33
The software design process
34
Design methods

• Systematic (canned) approaches to developing a
  software design. the cookbook approach
• The design is usually documented as a set of
  graphical models.
• Possible models
• Data-flow model
• Entity-relation-attribute model
• Structural model
• Object models

35
Programming and debugging

• Translating a design into a program and removing
  errors from that program.
• Programming is a personal activity there is
  no generic programming process.
• Programmers carry out some program testing to
  discover faults (unit testing), and remove
  faults in the debugging process.
• (Compare this model with Cleanroom SE.)

36
The debugging process
37
Software verification validation

• Verification and validation (VV) determines
  whether or not a system (1) conforms to its
  specification and (2) meets the needs of the
  customer.
• Involves inspection / review processes and
  (machine-based) testing.
• Testing involves executing system elements with
  test cases that are derived from specifications
  and/or
• program logic.

38
Testing stages (topic 15)

• Unit/Module testing - individual
  function/procedures are tested
• (unit/module) Integration testing
• Component testing - functionally related
  units/modules are tested together
• (component) Integration testing
• Sub-system/product testing - sub-systems or
  products are tested
• (product/sub-system) Integration testing
• System testing - testing of the system as a
  whole, including user acceptance test
• cf traditional (i.e., waterfall) model of
  testing

39
Software evolution

• Software is inherently flexible and subject to
  change.
• As requirements change through changing business
  circumstances, the software that supports the
  business must also evolve and change.
• The distinction between development and evolution
  is increasingly irrelevant as fewer and fewer
  systems are completely new.

40
System evolution
e.g., change requests
41
Automated process support (CASE)

• Computer-aided software engineering (CASE) is
  software to support software development and
  evolution processes.
• Activity automation (examples)
• Graphical editors for system model development
• Data dictionaries for name management
• GUI builders for user interface construction
• Debuggers to support program fault finding
• Automated translators to generate new versions of
  a program
• (e.g., restructuring tools)

42
CASE technology

• CASE technology has led to significant
  improvements in the software process, but not the
  order of magnitude improvements that were once
  predicted.
• Software engineering involves design activity
  requiring creative thought this is not readily
  automatable.
• Software engineering is a team activity and, for
  large projects, much time is spent in team
  interactions. CASE technology does not support
  this well.

43
CASE classification

• Classification helps us understand the different
  types of CASE tools / systems and their support
  for process activities
• Functional perspective tools are classified
  according to their specific function.
• Process perspective tools are classified
  according to process activities that are
  supported.
• Integration perspective CASE systems are
  classified according to their breadth of support
  for the software process.

44
Functional tool classification
MS Project
RCS, Make
LISP, 4GLs
coverage tools
45
Activity-based classification
Actually far more lower CASE tools than upper CASE
46
CASE integration

• Tools support individual process tasks such as
  design consistency checking, text editing, etc.
• Workbenches support a process phase such as
  specification or design, Normally include a
  number of integrated tools.
• Environments support all or a substantial part
  of an entire software process. Normally include
  several integrated workbenches.

47
Tools, workbenches, environments
48
Key points

• Software processes are the activities involved in
  producing and evolving a software system. They
  are represented in a software process model.
• Fundamental (lower level) activities are
  specification, design and implementation,
  validation verification, and evolution.
• Generic models are very general process models
  representing different approaches to development.
• Iterative process models describe the software
  process as a cycle of activities.

49
Key points

• Requirements engineering is the process of
  establishing what services are required and the
  constraints on the systems operation and
  development.
• Design and implementation processes produce an
  executable system based on the specification.
• VV involves checking that the system meets its
  specification and satisfies user needs.
• Evolution is concerned with modifying the system
  after it is placed in use.
• CASE technology supports software process
  activities.