CS5103
Software Engineering
Lecture 02
More on
Software Process Models
The Prototype Model
Requirements
engineering
Formalize
requirements
Design + build
prototype
Design and
implementation
Validate
prototype
Integration
UTSA CS5103
2
The Prototype Model

Looks like a two-cycle water fall model


Improvements from waterfall



3
Actually not, it is weak + strong
Good: users involve more (by using prototype), reveal
small errors in requirements / design
Not solved: still can not handle frequent requirement
changes
Bad: prototype is discarded (waste of some effort,
sometimes can be even more expensive than water fall)
UTSA CS5103
In practice


4
Used frequently for requirement collection
Rarely used as a whole software development
process
UTSA CS5103
The Iterative Model
Solve these risks by infinite weak cycles
Requirements
engineering
Design &
Implementation
& Integration
Testing
5
UTSA CS5103
Iterative Model

Plan for change

Use the same steps as waterfall

6
But expect to iterate the whole process
continually, and spend less effort on each iteration
(weak cycles)
UTSA CS5103
Example: Ant Project
7

Building tool for Java

First stable version 1.1 released in June 2000

Small developer group with 3-4 people

First prototype version released in one month

First stable version released in about half a year
UTSA CS5103
Example: Ant Project

The Project evolves for 13 years

8
5770 issue (bugs & new features) reports from users,
2581 reports handled

7 more major versions in 13 years

Code commits 12,000 +

File modifications 50,000 +

Lines of code from 25.6k to 260k
UTSA CS5103
Advantages

Cheaper to get a working software


Users involve earlier


Important in many cases, e.g., in competitions
Keep refining requirements, and accommodates
changes

9
User can give feedback after the first version released
The software always work, though not perfect


Get the first version very fast
Cost for requirement changes/errors are small
UTSA CS5103
Disadvantages


10
More bugs, sometimes may cause severe loss
Design is critical to make sure a change does not
affect the whole system
UTSA CS5103
In practice

Most existing software projects use this model



Not suitable for systems that are costly for
testing or very critical in quality


11
Daily builds
Releases
NASA programs
Military / Scientific / …
UTSA CS5103
Before we go to Extreme Programming,
Let’s see an opinion on time
12

Time is the enemy of all software projects

Why time matters?
UTSA CS5103
Time matters

The World Changes





13
requirement may change
Techniques become obsolete
Computing environment changes
Business Competition
Within a very short period of time, the world can
be viewed as unchanged
UTSA CS5103
Extreme Programming

14
Extreme Programming still uses iterative process
model, but goes to extreme
UTSA CS5103
Shorter cycles (2-4 weeks)

Small requirements



Simple design




Simplest design to pass test cases
Pair programming
Code refactoring frequently
Quick evaluation

15
Testable user stories
Write test cases first
Have customers involved to evaluate the software
frequently
UTSA CS5103
Simple Requirements – User Stories
16
UTSA CS5103
Simple Requirements – User Stories
17
UTSA CS5103
Sample Requirements – test cases
Customer must describe how the stories are
tested



Test case example

1.
2.
3.
4.
5.
18
With concrete data examples
Tests should be automated
I create an account “savings”
I ask for list of accounts, I must obtain “savings”
I create an account “savings” again, I must get error
I check the balance the account “savings”, I must get 0
…
UTSA CS5103
Simple design

Just in time


No optimization for future

19
Design and implement what you know now, not worry too
much about future : future is unpredictable
It is common that the optimization becomes unnecessary
 Example: optimization to handle large input data, but
later found the input changed (e.g., smaller format, or
available in a summarized form)
UTSA CS5103
Pair programming

Programmer and Monitor



20
Pilot and Copilot
Or Driver and Navigator
Programmer types, monitor think about high-level
issues

Disagreement points to design decisions

Pairs are shuffled
UTSA CS5103
Advantages

Result in better code



Knowledge and skill migration


Better coding styles
Reduces Risk

21
Instant code review
Monitor always notice the big picture
More people understands the code
UTSA CS5103
Why people don’t like


Stressful to relate to people all the time
Slows the programming


Waste of personnel

22
But save for time in maintenance
But less bugs, and more people can work on it, once bugs
are revealed
UTSA CS5103
Regression Testing and Evaluation


Automatic comprehensive suite is required
Always keeps code working


Do regression testing before/after any major changes
Plan coding to allow frequent tests


Do not do too comprehensive changes, try to break them
to smaller phases
Example: Add a product query feature for shopping
software




23

Add list all products first
Add text query
Add filtering conditions one by one
Add sorting
…
UTSA CS5103
When to use extreme programming

Use for:

Requirement prone to change
Easy to get testable requirements (often true in the
maintenance phase on a software)
Need quick delivery (business competition)

In practice, frequently used in start-up companies



Not to use for:


24
Large group for large project (still can be used for
components)
No highly-involved customers
UTSA CS5103
Next Class

Software Requirements
 Concepts
 Process





25
Elicitation
Analysis
Specification
Validation
Elicitation Approaches
UTSA CS5103
Assignment I is online now:
http://xywang.100871.net/CS5103.htm
26
UTSA CS5103