Software Processes

1
Chapter 4

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

struhk-cherd adjective having and manifesting
a clearly defined structure or organization.
7
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.
• Reuse-Based Development e.g., component-based
  the system is assembled from existing components.
• (And, at no additional cost Incremental,
  eXtreme, and Spiral.)

8
Waterfall model (W. Royce)
9
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?

10
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
• (cont'd)

11
Evolutionary development
customer
trash
(cont'd)
12
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?)

13
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.
• (cont'd)

14
Reuse-oriented development

• Process stages (following initial requirements
  specification)
• 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.
• (cont'd)

15
Reuse-oriented development
(whats available?)
16
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 keeping with
  spirit of Waterfall)
• Two other approaches that explicitly incorporate
  iteration
• Incremental delivery
• Spiral development (Boehm)

17
Incremental delivery

• 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 prioritized 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)
• (cont'd)

18
Incremental delivery
(cont'd)
19
Incremental delivery 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. (they're subject to
  more validation steps)
• (cont'd)

20
Potential problem with incremental delivery

• Requirements may NOT be partitionable into
  stand-alone increments. (e.g., a compiler)
• (A generalization of incremental delivery, known
  as Incremental Software Development, is discussed
  in Chap. 17, Rapid Software Development.)

21
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

22
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.
• (cont'd)

23
Spiral model of the software process
24
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.

25
Models for (lower level) fundamental process
activities

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

26
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
• (cont'd)

27
The requirements engineering process
28
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.

29
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

30
The software design process
31
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

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

33
The debugging process
34
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.

35
Testing stages (topic 14)

• 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

36
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.
• (cont'd)

37
System evolution
e.g., change requests
(cont'd)
38
The Rational Unified Process

• A modern process model derived from the work on
  the UML and associated process.
• Normally described from 3 perspectives
• A dynamic perspective that shows phases over
  time
• A static perspective that shows process
  activities
• A practice perspective that suggests good
  practice.

A hybrid process model that brings together
elements from all of the generic process
modelsrepresents a new generation of generic
processes
(cont'd)
39
RUP phase model
cf Waterfall Model RUP phases are more closely
related to business rather than technical
concerns.
(cont'd)
40
RUP phases

• Inception
• Establish the business case for the system.
• Elaboration
• Develop an understanding of the problem domain
  and the system architecture.
• Construction
• System design, programming and testing.
• Transition
• Deploy the system in its operating environment.

(cont'd)
41
RUP good practice

• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software (e.g., UML packages,
  sequence
• 
  models, state machine models)
• Verify software quality
• Control changes to software

(cont'd)
42
Static workflows (process activities)
43
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)

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

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

46
Functional tool classification

• TOOL TYPES
• Planning tools
• Editing tools
• Change mgmt tools
• Configuration mgmt tools
• Prototyping tools
• Method-support tools
• Language-processing tools
• Program analysis tools
• Testing tools
• Debugging tools
• Documentation tools
• Reengineering tools

• EXAMPLES
• PERT tools, estimation tools, spreadsheets
• Text editors, diagram editors, word processors
• Rqmts traceability tools, change control sys
• Version mgmt systems, system building tools
• V. high-level langs, user interface generators
• Design editors, data dicts, code generators
• Compilers, interpreters
• Cross ref generators, static/dynamic analyzers
• Test data generators, file comparators
• Interactive debugging systems
• Page layout programs, image editors
• Cross-ref systems, program restructuring systems

47
Activity-based classification
Actually far more lower CASE tools than upper CASE
48
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.

49
Tools, workbenches, environments
50
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.

51
Key points (contd)

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