Software Prototyping

lumpysteerSoftware and s/w Development

Dec 2, 2013 (3 years and 6 months ago)

68 views

CS 551


Software Life
Cycle






Think like an engineer



What is Engineering?


Engineering is the quantitative &
systematic application of knowledge
to create and build cost
-
effective
solutions to practical problems.

Making trade
-
offs.

What is systems engineering?

The systematic synthesis and analysis of solutions to
problems with a focus on

1.
Understanding the problem domain

2.
Defining the clients needs creating a set of feature
definitions that satisfy the need

3.
Mapping the features to components that perform
defined functions

4.
Specifying the components and their interfaces

5.
Studying the economic viability of the solution

Viewpoints


Systems engineers determine what

should be.


Software engineers determine what

can be.


Be able to answer these Four Questions

l
Is this proposed software centric system feasible?

l
If it is, how much will it cost?

l
If we are willing to pay, how long will it take to
build and to deploy?

l
What is the development plan, especially the
detailed schedule?

“…[I]n software there has always been a great

willingness to make changes in the specifications,

and this makes the job tenuous; hardware people

have a habit of freezing a design and not letting a

large number of new things be incorporated into it.

When you allow changes you risk errors, delays

and cost overruns
.”


R.W. Hamming, preeminent software

philosopher

Journal of Systems Integration
, Vol. 6, Number 1/2, March 1996, Kluwer Academic

Publishers Boston ISSN: 0925
-
4676, p. 6

Software Requirements Process

l
Requirements Elicitation

l
Requirements Analysis

l
Use Cases

l
Requirements Specification

l
Prototype

l
Requirements Management

Five Great Processes


Solo Virtuoso

Code Ownership

Engage QA

Divide and Conquer

Prototype

Reference: Technical Memorandum by J. O. Coplien Document No. BL0112650
-
940906
-
50TM

‘Code then fix’





Test

Fix

Code

Run

This approach leads to unstructured, unstable
software that sometimes meets users’ needs.
Problems are hard to find and harder to fix.


HACKING

PROBLEM

Reqts Spec

Tech Spec

Code

System

Simplified Model

Analysis

Design

Coding

Testing

Integration



Document Focused



Phases in lockstep



Encourages point solutions



Mistakes found late



Leads to tightly coupled systems


The Waterfall Model

Waterfall Model with feedback

Reqts Eng

Design

Implementation

Test

V&V

Maintenance

Waterfall: document
-
driven milestones

l
Baselined Requirements Specification

l
Baselined Test Plan

l
Baselined Design Specification

l
Baselined Code

l
Test Results report


Why is Waterfall still used?

l
Easy to understand

l
Familiar to customers, steps make intuitive sense

l
‘Natural’ Structure for new staff or teams

l
Tight control by project management

l
Requirements are stable

l
Forces documentation


Prototyping by Barry Boehm

Listen to customer

Build/revise mockup

Customer test drives mockup

When finished:
Design
, Implement, Test, Maintain

Product Size Reduction

TRADITIONAL PROCESS

PROTOTYPING


40% REDUCTION

20%

80%

40%

30%

45%

25%

Systems

Engineering

Design,

Develop,

Test,

Install

Final

Development,

Deployment

Systems

Engineering &

Prototype

Final

Development

Deployment


Risk Focused


Incremental and iterative


Evolutionary Feature Discovery


Prototyping with quick feedback


Continuous integration

Analysis

Design

Testing

Coding

The Spiral Model

Extreme Programming (XP)

l
Test before Coding

l
Pair Programming

l
On
-
Site Customers

l
Ad hoc functionality

l
Evolutionary Development

l
Continuous Integration

l
Short Cycles with Feedback

l
Incremental Development


Vision

l
People

l
Process

l
Product

l
Project (control, risk, schedule, trustworthiness)

l
Technology and Platforms (rules, tools, assets)

l
People work days, computers work nights

l
Work, not people, needs to be mobile

l
Productivity must continue to double with
no

loss of
reliability or performance

Customer Interests

I
N
S
T
A
L
L
A
T
I
O
N


Before




Features



Price



Schedule


After




Reliability



Response Time



Throughput



Customer buys


off
-
the
-
shelf





System works


with 40
-
60%


flow
-

through





Developers complies


with enhancements

BUT



Customer refuses


critical Billing


Module




Customer demands


33 enhancements


and tinkers with


database




Unintended


system


consequences





Why bad things happen to good systems

Lessons Learned

l
One common process is not the goal

l
Commonly managed processes are possible

l
Scalability is essential

CMM

LEVEL

FOCUS

KEY PROCESS AREAS

5
Optimizing

Continual
Process
Improvement

Defect prevention, Technology change
management,

Process change management

4 Managed

Product and
process quality

Quantitative process management,Software
quality management

3 Defined

Engineering
processes and
organizational
support

Organization process focus, Organization process
definition, Training program, Integrated software
management, Software product engineering,
Intergroup coordination, Peer reviews

2
Repeatable

Project
management
processed

Requirements management, Software project
planning, software project tracking and
oversight, Software subcontract management,
Software QA, Software configuration
management

1 Initial

Competencies

And heroics and small teams

Brooks: System Production

Program

Programming System

Programming Product

Programming System

Product

x3

x3

x9

Techniques for Project Planning

l
Some sort of work breakdown structure, tasks into
subtasks with constraints

l
Beware of over and under analysis

l
Beware of diffuse responsibility

l
Gantt chart
-

Microsoft project (do not represent
dependencies between activities)

l
Identify critical path activities (should know w/o
automation)

l
Sensitivity analysis
-

“what if” questions

l
Also informal methods
--

milestones

Mindset


Move from a culture of minimal change to one of maximal
change.


Move to "make it work, make it work right, make it work
better" philosophy through prototyping and delaying code
optimization.

Give the test teams the "right of refusal" for any code that was
not reasonably tested by the developers.

Productivity

Productivity =


F
{people,




system nature,






customer relations,







capital investment}

As of
8/31/06

People 20:1

l
20:1 difference between people but ‘20:1ers’ are 1% of
population

l
Code ownership with
one

developer making module
changes; apprentice permitted

l
Source module size = 20
-
40 new function points;
smaller modules carry too much overhead; larger
modules become too big for people to understand

l
Production module size
-

constrained only by the
execution environment

System Nature 10:5:1

l
If Report Generation Software =1, then

l
On
-
line Software =5, and

l
Communications or Real
-
time =10

l

1:5:10 is the degree of difficulty or complexity
which impacts productivity

Customer Relations 2:1

l
Projects that team with customers are twice as
productive as those that have contracts

l
Prototypes build customer relations and increase
productivity by 40%.

Capital Investment

l
100:1 improvement every 20 years measured by
the expansion factor

l
OOT coming with 3:1 potential

l
Objects in the large, and 80% reuse by turn of the
century

Function Point Metric

Function Points/Staff Month

Technology

0

2

4

6

8

10

12

14

16

18

20

IDMS

IMS

MVS

Oracle

UNIX

VM

Composite


80 Projects


98 Projects


Benefits of Objects:


1. Manages complexity


2. Speeds development


3. Encourages module reuse


4. Enables scaling


Prerequisites for Supporting Object
-
Oriented Design:


1. Software technologies and techniques


2. Tools and infrastructure


3. Management process and culture


4. Know
-
how



Objects


3
15
30
37.5
47
75
113
142
475
638
81
1
10
100
1000
1960
1965
1970
1975
1980
1985
1990
1995
2000
Expansion

Factor

Technology

Change:

Regression

Testing

4GL

Small Scale

Reuse

Machine

Instructions

High Level

Languages

Macro

Assemblers

Database

Managers

On
-
Line

Dev

Prototyping

Subsec

Time

Sharing

Object

Oriented

Programming

Large Scale

Reuse

Order of Magnitude

Every Twenty Years

Each date is an estimate of widespread use of a software technology

The ratio of

Source line

of code to a

machine

level line of

code



Trends in Software Productivity

Barry Boehm

USC Center for Systems and Software Engineering


Keynote Address, EQUITY 2007


March 19, 2007


Revisiting Software Engineering Economics

Implications for the future


l
Estimation

l
Value
-
based approaches

l
Agility

l
Systems
-
of
-
Systems

Software Estimation: 1980’s Expectations

Unprece
-

dented

Prece
-

dented




Estimation

Error




Domain Understanding

Software Estimation: The Receding Horizon

Unprece
-

dented

Prece
-

dented

Component
-

based

RAD

Open

Source

Systems of

Systems

A

B

C

D

Relative

Productivity



Estimation

Error



Domain Understanding


RAD: Rapid Application Development

The Future of Systems and Software

l
Eight surprise
-
free trends

1.
Increasing integration of SysE and SwE

2.
User/Value focus

3.
Software Criticality and Dependability

4.
Rapid, Accelerating Change

5.
Distribution, Mobility, Interoperability, Globalization

6.
Complex Systems of Systems

7.
COTS, Open Source, Reuse, Legacy Integration

8.
Computational Plenty

l
Three surprises

9.
Autonomy and Adaptable Software

10.
Combinations of Biology and Computing

11.
Multi
-
threading returns

Why Software Projects Fail

Pareto 80
-
20 distribution of test case value

[Bullock, 2000]

Actual business value


% of
Value
for
Correct
Customer
Billing
Customer Type
100
80
60
40
20
5
10
15
Automated test
generation tool
-
all tests have equal value
% of
Value
for
Correct
Customer
Billing
Customer Type
100
80
60
40
20
5
10
15
Automated test
generation tool
-
all tests have equal value
Business Case for Value
-
Based Testing

-1
-0.5
0
0.5
1
1.5
2
0
20
40
60
80
100
% Tests Run
Return on Investment
(ROI)
Pareto testing
ATG testing
Defect Removal Estimates

-

Nominal Defect Introduction Rates

60
28.5
14.3
7.5
3.5
1.6
0
10
20
30
40
50
60
70
VL
Low
Nom
High
VH
XH
Delivered Defects

/ KSLOC

Composite Defect Removal Rating

Trustworthy Trends

l
Software increasingly success
-
critical to product and services


Provides competitive differentiation, adaptability to change

l
Dependability is generally not vendors’ top
-
priority


“The IT industry spends the bulk of its resources… on rapidly bringing
products to market.”


US PITAC Report

l
By 2025, there will be a “9/11”


magnitude software failure


that will raise trustworthiness to priority 1


Major loss of life or collapse of world financial system


Market demand; stronger warranties and accountability


Value
-
based trustworthy processes and tools

l
But other trends will make trustworthy solutions harder


System complexity, globalization, rapid change