Software Processes
Process should be
 Visible: Activities should provide clear
indications of progress (deadlines/milestones)
 Understandable: Activities and their order of
execution are well-defined
 Supportable: Automated support for activities
is available
 Usable: Process is acceptable to and usable
by developers
Defining Processes

A defined process:
 facilitates communication about the process
 provides a basis for process automation
 facilitates process reuse and evolution
 aids process management

Elements of process descriptions
 general description
 each activity has an entry and exit criteria
 activities are organized in “sequence”
 guiding principles explain goals of activities
 process may contain subprocesses
 resources, constraints
Evolution of Software Process Models

“Code and Fix” model
 code, test, debug

Problems
 requirements analysis and design ignored
 code does not evolve gracefully
 debugging is difficult
• Why? Unstructured, spaghetti coding, changes not localized,
not modular, difficult to trace, relationships hard to determine
SWEng Paradigms for Prescriptive Process Models
Chosen based on nature of project, methods, tools used,
controls and deliverables required







Linear Sequential Models (Classic or Waterfall, V-shaped)
Prototyping
RAD Model
Evolutionary Process Models (Incremental, Spiral,
Iterative, Concurrent)
Formal Methods
4GL
Combinations
Process Models

Linear Sequential
 Analysis, design, coding, testing, maintenance
 Difficulties:
• Projects rarely follow sequential flow
• Requirements defined up-front a must (rarely done)
• Patient customer/no immediate feedback
Waterfall Methods and Variants

Phases (similar to develop hardware)
 Analysis, Design, Code, Test, Maintain

Difficulties
 projects rarely follow sequential flow
 requirements defined up-front a must (rarely done)
 patient customers/no immediate feedback
 no insight given into how each activity transforms an
intermediate product into another

Variants
 V-shaped model: relationship between types of tests
and phases before testing
 Prototyping variant: requirements and design
prototypes
Process Models

Prototyping
 quick design, build prototype, evaluate, refine
prototype, … engineer product

Prototyping
 Paper/working subset of features/existing program
with some features
 Requirements, quick design, build prototype,
customer evaluation, refine prototype, engineered
product
 Problems:
• Customer sees prototype, then wants a few fixes quick and
delivery
• Implementation compromises made to get prototype done
quickly/forgets compromises and become part of the system
Process Models

RAD Model
 Short development cycle, “high-speed” linear
sequential using component-based construction
 Well understood requirements, constrained scope,
IS apps
 Uses reusable components and 4GLs
 Problems:
•
•
•
•
Need sufficient human resources for RAD teams
Need committed developers and customers
Modular system key
Not appropriate when technical risks are high (new technology,
performance an issue
Process Models

Evolutionary Process Model
 Spiral, Incremental, Iterative
Evolutionary Models (Microsoft)
Build 1
Build 2
Build 3
Developers
Release 1
Release 2
Release 3
Users
Incremental/Iterative Development
Incremental: functionality developed in pieces
Iterative: put in all features, but they are limited
Benefits and Problems of Evolutionary
Development
 Incremental: Each build focuses on a subset of
functionality, simplifying development
 Opportunity to learn about problem as design develops
 customer get a product early and can provide feedback
for future builds
 customer can test software
 different releases can focus on enhancements that
require specialized expertise
 improperly planned builds result in complex system
 backward compatibility limits elegance of future
releases (and can force hacking)
 error in basic system architecture may require changes
to basic structure that invalidate earlier releases
Process Models

Transformation (4GLs)
 No coding phase
 formal models mechanically transformed to code
 Requirements, “design”, implementation using
4GL (specifications into code generator), testing
 domain engineering (lex, YACC, SDL)
 Problems:
•
•
•
•
•
Limited to Business IS
Some CASE tools produce skeletonized code
Reduces time to produce SW
Design/Analysis also reduced
4GTs for large SW development efforts as much A/D/testing
Other Process Models

Operational (5GLs)
 executable specifications

Combining Paradigms
Choosing a Process Models

Choice depends on nature of project
 requirements clearly defined and stable?
 Pressure to produce a working product quickly?
 Consequences of operational errors serious?

Classified along a spectrum ranging from
 radical: all activities carried out in parallel
• suitable when quick results needed and requirements fuzzy
 conservative: all activities carried out in a strict
sequence with no overlap
• suitable when consequences of errors serious and
requirements are clear and stable

None of the extremes are viable