Transcript Time to Market -Solving the Problem of Viable Processes

Karl Reed NR 5/1/2001
Software Engineering Technology
Transfer…the way forward or the
way back
by Assoc. Prof. Karl Reed,FACS, FIE-Aust., MSc,ARMIT
Chair IEEE-Computer Society Tech. Council on Software Engineering
Governor, IEEE-Computer Society(1997-1999,2000-2002),
Director, Computer Sys. & Software Engineering Board, ACS,
Department of Computer Science & Computer Engineering, La Trobe
University
Hon. Visiting Professor, Middlesex University
liberal use will be made of ideas from Jason Baragry,
David Cleary and Jacob Cybulski
“those who fail to study history are bound to repeat it”
1
Some Definitions..
Karl Reed NR 5/1/2001
TECHNOLOGY AWARENESS…
 To
be aware of some aspect of the technology not currently being used,
and to understand it well enough to decide to adopt or not to adopt.

TECHNOLOGY TRANSFER…
 To
achieve technology its adoption to a level proficiency which permits
use to produce products and services on a commercial basis, or their
improvement

Conditions of Necessity
 The
creation of an irresistible desire for or belief in the value of some
technology that leads to its adoption as a matter of urgency
 Demonstration that new technology can solve some commercial problem
or improve some process
2
Karl Reed NR 5/1/2001
Our Problem…
A.
Are we making a real improvement?
 Obviously
B.
we are.. We’re doing research aren’t we?
How can we be sure this is true?
 You
mean it may not be?
 If it were believed to be true, there’d be no real TT
problem.
3
Stages of SE...
Immature
methodologies, Fortran,
Cobol, Assembler70’s,telephone systems
Customer req
dominate,ROI
mandatory
Karl Reed NR 5/1/2001
Cottage industry,
but well
intentioned
Systems Analysis and
Design methodologies
70’s-80’s
Formal Methods, info. Hiding,
architecture, strong typing,
CASE,RE,SCS,formalised testing,
banking networks,internet,PC-OS,
Determinate,
quality driven,
high reliability,
business model
oriented
Mature?
Body of Knowledge
but no universal
success
OO,CMM,Process Modelling,re-use,
cots,dig.flight control
systems,EFTPOS
Large-scale s/w,
comsumer
goods,engine
management
systems,
ABS
time to market,
extreme
programming, web
systems, free-ware,
94-00’s
Unreliable, technology
history free, ROI
independent-business
model? s/w surprises
Cottage industry,
reversion to the
old-days
4
Karl Reed NR 5/1/2001
Where Are We?
Traditionalist’s View
 Bowsers that are
limited
 Time-To-Market web-application deployment
 16 year old wunder-kinder throwing systems together
 poorly designed functionality
Modernist’s View
 rapidly deployed functionality
 rapid evolution of systems to meet customer needs
 conventional approaches being left behind
 the old do not understand the new
5
Karl Reed NR 5/1/2001
To many surprises….!!!(nsf report on s/w research
1998)
“F1. Current software has too many surprises. The sources of surprise
are poorly understood.”
“F2. Key sources of software surprise include immature or poorly integrated
software domain sciences, construction (product) principles, and engineering
processes. Software research emphases have swung from process to product
research, with weak coverage of domain sciences and integration.”
Sources of surprises... Real and apparent ambiguity in the means
of representation of systems, e.i. Languages (cf 3 pages of c++ with 3
pages of government regulations)(Reed, 2000)
6
Karl Reed NR 5/1/2001
No surprises….!!!(nsf report on s/w research 1998)
“F1. Current software has too many surprises. The sources of surprise
are poorly understood.”
Sources of surprises... Real and apparent unpredictability in
behaviour...
“Teenagers have less trouble with PC software because they are
adept at playing computer games” Charles Wright, editor Melbourne Age
“green pages” computer section 2000
“Building ‘bots’ that play computer games with near human
competence is not that hard” US researcher in AI….
7
By way of Illustration...Some
Contradictions……
and confusion
Karl Reed NR 5/1/2001
1. Software Architecture.. ‘not immutable, not always determinable
a’priori,multiple versions in one artefact, retrofitable…. Analog with “built”
systems not clear.
2. Software Process.. CMM vs fine-grained process independent, Time To
Market vs Planned Process, Phase incompletedness, Extreme Programming.
3. Software Process... Often mandated, but not followed… few detailed
studies similar to production engineering (see Hess)
4. Re-use… not successful, yet components industry emerging
5. Engineering & SE.. Poor choices of analogues from traditional domains,
e.g. “immutable components”
8
Some Contradictions……
and confusion (cont’d)
Karl Reed NR 5/1/2001
6. SWEBOK.. Organised body of knowledge opposed by leading SE
players.
7. Prescriptive Design processes... only slowly beginning to appear,
perhaps via UML.
8. Requirements Engineering... Cannot always be completed in
advance..may be continuous part of the implementation process...
9. Software Crisis… yet increasingly, successful large-scale applications
are ubiquitous
10. High Quality training for 30 yrs.. Yet each new s/w development wave
starts with a blank mind, e.g. web-based computing
11. Documentation matters but.. It’s seldom actually done
9
Karl Reed NR 5/1/2001
The optimists view of technology
transfer..
10
10
Karl Reed NR 5/1/2001
A Tech-Transfer Model
11
11
Karl Reed NR 5/1/2001
Our Knowledge of Industry The
Australian Example..
 THE
SOFTWARE INDUSTRY OF THE LATE 1960'S AND
EARLY 1970'S WAS…
a) PACKAGE (and hence re-use) ORIENTED
A wide range of packaged software on 16 bit and mainframes was produced.
E.G. Accounting, payroll, engineering design, manufacturing, insurance, etc.
b) KNEW ABOUT PORTABILITY…
Many of these were transported between different OS and machines.
One suite of packages in assembler (50klocs) was "ported" to at least 6 different
systems
c) RECOGNISED THE RE-USE OF SKILLS , IDEAS AND
DESIGN…
The concept of "the continuity of experience" syndrome, the human "experience
factory".
FORMAL PROCESS MODELS DO NOT APPEAR TO HAVE
BEEN IMPORTANT
12
Australia (cont’d)
Karl Reed NR 5/1/2001

THE SOFTWARE INDUSTRY BY THE MID
1980'S WAS…(cont'd)
a)A HIGH-LEVEL TOOL DEVELOPER
Developed "4GL's" and APPLICATION GENERATORS
Both HP and DataGeneral used Australian products for their early Application
Generators
The product Lansa (ASPECT) is one of three Application Generators for the
S/38 (now AS/400)
b) PRODUCING LARGE-SCALE MAINFRAME
PACKAGES & SYSTEMS…
Major international supplier of insurance s/w,
Major developer of large-scale s/w for Govt. and Industry.
c) UNDERSTOOD PROTOTYPING
CDA used SNOBOL in the mid-1970's for protoyping commercial systems.
13
Australia (cont’d)
Karl Reed NR 5/1/2001

BY THE LATE 1980'S EARLY 1990'S WAS…
a)PRODUCING OO LANGUAGES AND TOOLS…
The language OCHRE…
b)UNDERTAKING INDUSTRY-WIDE STUDIES…
Productivity studies based on function points (Aust. Software Metrics Assoc.)
SPICE (Software Quality Association/ACS)
c)DEVELOPING S/W QUALITY STDS AND
CERTIFICATION…
AS3563, S/W Assurance Standard being mandated by Govt.
Software Quality Institute lead by Geoff Dromey at Griffith Univ.
d)OTHER THINGS…
F-P estimating tools, OO based specialists consultancies…commercial use of
Formal Methods on small scale
e)TTM competency…
F-P estimating tools, OO based specialists consultancies…commercial use of
Formal Methods on small scale
14
Karl Reed NR 5/1/2001
THE HISTORY…(cont'd)

THE SOFTWARE INDUSTRY'S
WEAKNESSES…
a)LIMITED INTERACTION WITH RESEARCH
COMMUNITY…
b)JEALOUS AND SECRETIVE ABOUT
DEVELOPMENT METHODS
c) ABSENCE OF TARGETED RESEARCH CENTRES
d)NEEDED GREATER EMPHASIS ON WINDOWS &
MacIntosh S/W

THE SOFTWARE INDUSTRY'S ASSETS…
a)Good supply of well trained graduates in CS and
EDP
More than 14 000 p.a.!
(now 7 SE degrees in Australia)
b)Strong managerial/ technical culture of package
and product development
15
Australia (cont’d)

Karl Reed NR 5/1/2001
THE SOFTWARE INDUSTRY's PARAMETERS…
TOTAL SALES…US$1.8B
S/W PRODUCT @ 50% of total
DOMESTIC SHARE OF PRODUCT
@ 40%
EXPORTS
US$500M
(1993 FIGURES)
by comparison, the Japanese s/w industry has less than 15% of
T.O. in s/w product.
There are 40 Australian S/W companies selling product in
Japan
16
Karl Reed NR 5/1/2001
Approaching Software Developers…

Technico-Commercial Drivers… the linkage
 The
goal is to find a high-level, one-line statement of
pressing commercial issue that maps directly on to a
“technology acquisition” (research) agenda (map idea to
common concept base accessible to highest management)

Show an economic benefit
Be able to show ROI after adoption costs (equipment +
training) and productivity losses due to learning curves
after adoption. (improved profit)
 Show resolution of competitive advantage problems
(beat off competitors, maintain market share)
 Show new market opportunities due to new
products/services

17
Karl Reed NR 5/1/2001
Research-Commercial Mapping… Defining
Relevance
Typical SE Research Agenda
Technico-commercial Drivers
Australia ~ 1997
¶ Impact of developments in runtime platforms
1.Re-engineering and Empirical
Studies of s/w Practice,
¶ Low-cost and evolving software
2.Tools and Methodologies, and
Design Representation,
¶ User Interface Development
¶ Software Productivity
¶ Performance Predictability
¶ Software Product Quality
Certification
¶ Time to Market ¶
3. Re-Use,
4. Evolving Software,
6. Object Oriented Dev.
7. Product Quality Measurement
8. Time-to-Market
9. Testing
18
Table I - Relationship Between Technico-Commerc ial Issues
and Research Agendas
TechnicalCommercial Issue
The
ANSEI
TechnicoComercial
Driver to
Research
agenda
mapping
Proposed Rese arch
Issue
Impact of
developm e
nts in runt ime
plat form s
Implications
Add
funct ion alit y
to legacy
System s
(e.g.GU I),
ability to
mov e
software
between
plat form s,
need to
reduce
maintance
Main Agenda Items
1.Re -en gi neerin g an d
Em pirical S tudi es of
s/w Practice ,
Sub-Agenda s
Design
reaso ning
recording,
emperical
studies of
pract ice,
software
m igratio n,
impact on
metho dologies
OUTCOMES
Too ls and
metho dologies
, detailed
kn owledge of
current
pract ice
Low-cost
and
evolving
software
Mo difiability,
maintanance,
techniques
for designing
3. Re-U se,
Metho dologie
s for
modifiable
and evolving
software,
emperical
studies of
existing
pract ice
Ergonom ics,
charact erisato
n of
processing,
metho dologies
for this
Metho dologie
s incorp.
design for
evolut ion , s/w
quality , tools
Metho dologie
s for
engineering
user
interfaces,
All
metho dologies,
ergonom ics
Software
resuse, and
metho dologies
explicit ly
including this,
prescript ive
metho dologies
, s/w
architecture,
improved
design
representat ion,
project
t racking
Performance
engineering,
metho dologies
, o perat ion al
mathemat ical
metho ds
Metho dologie
s generat ing
re-usable
compo nent s,
maxim ising
re-use within
single
projects, and
maxim insing
re-use of
"art ifacts",
including
design
Design
recording,
nature of
software
engineering,
s/w
architecture,
evolving
software
Metho dologie
s incl. new
mathemat ical
models, tools
suppp ort ing
this,
diagram m ing
schemes
Design
recording,
nature of
software
engineering,
s/w architecture
Program
st ructure,
met rics and
language
processors
Too ls for
automat ic
measurement
S/ W
architecture,
design
recording,
nature of SE
As for
produc t ivit y,
but special
emph asis on
incremental
delivery, and
quality
enhancin g
metho dologies
Metho dologie
s and too ls,
design
recording
s/w
architecture, reuse and
evolving
software

4. Evo lvi ng Software,
6. Object Oriented
Devel op ment
8. T i me-to-Market
User
Interface
Developm e
nt
Design for
ergonom ics,
engineering
based on
applicat ions
data
processing
1. Re-engin eering and
Empirical Stud ies of s / w
Practice,
3. Re-U se,
5. Engi ne e ri ng of
Use r Interface s,
Karl Reed NR 5/1/2001
Supp orts
Process
improvement,
validat ion of
metho dologies,
actual measures
of s/w qua lity,
s/w
architecture,
domain
engineering,
evolving s/w,
nature of
software
engineering
Automat ic
quality
measurement,
process
improvement,
nature of
software
engineering
6. Object Ori ent ed
Devel op ment
Software
Productivit
y
Reuse,
improved
metho ds
9. Te s ti ng
1. Re-engin eering and
Empirical Stud ies of s / w
Practice,
2. Too ls and
Methodo logies, and Design
Represent ati on,
3. Re-Use ,
9. Te s ti ng
Performanc
e
Predicatabil
ity
Software
Product
Quality
Cert ificat io
n
Approp riat e
metho ds for
including
constraint s in
design
1. Re-engin eering and
Automat ic
and
incremental
measurement
of produc t
1.Re-engin eering and
Empirical Stud ies of s / w
Practice,
Em pirical S tudi es of
s/w Practice ,
2.To ols and
Methodolog ies, an d
Des ign
Represen tation,
9. Testin g
2.Tools and Methodologies,
and Des ign Rep resentation,
3. Re-U se,
4. Evo lving So ftware,
7. Product Q.
Me as urement
9. Testin g
Tim e to
Market
Improved
Development
techniques,
Too l support,
CASE
1.Re-engin eering Empi ri cal
Studies of s / w Practi ce,
2.Tools and Methodologies,
and Des ign Rep resentation,
3. Re-U se,
4. Evo lving So ftware,
6. Object Ori ent ed Dev.
7. Product Quality
Measurement
8. TTM
9. Testin g
19
Technology Transfer Mechanisms
Karl Reed NR 5/1/2001
 “Champions” in the organistions targetted.. Need to
be involved by the researchers
 Disclosure, workshops, training, publications,
technical newspapers
Professional associations SIG’s and meetings
 Wining and dinning managers
Joint trials of technology, may need to be funded by
research centre…(various models, including fully
profitable contracts.. Must counter lost opportunity cost
problem)
“Exemplar” projects by the research centre, creating
“technology pull”
 Incremental technologies may be easier to adopt
20
Technology Transfer Mechanisms(cont’d)
Karl Reed NR 5/1/2001
 NIH has cultural, economic and technical
basis..
(It took ~ 5 years for Ada/Clean-room/OO to show an
overall cost benefit cf Fortran at NASA/SEL)
 50% productivity gain needed for break-even
in one learning curve time..
21
issues
Karl Reed NR 5/1/2001
Baragry’s conjectures and their implications..
The work products problem…
The work-products (documentation) are not
appropriate to actual s/w development practice
§ if the methodologies are not leveraging the design
process(Reed),
 Documentation will not reflect design...
 Documentation will be an external, non-design
process… since it is based on conceptual models other
than those being used!..
 S/W development processes in practice consist of
“work arounds” like other prescription based systems
22
Karl Reed NR 5/1/2001
What if we had a large re-engineering project?
component semantics and concept extraction.. The
role of re-engineering.. S/W Archaeology...
 program is a model of some real world process
 exactly what “concepts” are represented in terms
of non-procedure replicated code fragments?
 What are their semantics?
-What impact do these have on program
composition?
 How do these relate to different problems in the
same domain?
..different problems in different domains?
 How are components modified in practice and
what is the outcome?
23
Karl Reed NR 5/1/2001
The role of re-engineering.. S/W Archaeology and S/W
Architecture....
 recovery of standard architectures
 identification of s/w construction practices, e.g.
shifts from one programming style to another
 development of maintainability and evolvability
classifications for --
§ design methodologies
§ architectural styles
 development of maintainability and evolvability
classifications for architectural styles
24
Karl Reed NR 5/1/2001
component semantics and concept extraction.. The role
of re-engineering.. Architecture issues for the S/W
Archaeologist
 identification of design approaches which ensure that
conceptual architectures are transferred to implementation
 identification of standard mappings from conceptual to
actual architectures which occur using different design
approaches on different problems
25
Karl Reed NR 5/1/2001
Tak Ska du har…
26