software engineering technology transfer…the way forward or the way back

1

Karl Reed NR 5/1/2001

Software Engineering Technology Transfer…the way forward or the way back

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

by Assoc. Prof. Karl Reed,FACS, FIE-Aust., MSc,ARMIT

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”

2


Some Definitions..Some Definitions.. 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

3


Our Problem…Our Problem…

Obviously we are.. We’re doing research aren’t we?

You mean it may not be? If it were believed to be true, there’d be no real TT

problem.

A. Are we making a real improvement?

B. How can we be sure this is true?

4


Stages of SE...Immature methodologies, Fortran, Cobol, Assembler-70’s,telephone systems

Systems Analysis and Design methodologies70’s-80’s

Formal Methods, info. Hiding, architecture, strong typing, CASE,RE,SCS,formalised testing, banking networks,internet,PC-OS,

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

Customer req dominate,ROI mandatory

Unreliable, technology history free, ROI independent-business model? s/w surprises

Cottage industry, but well intentioned

Mature?Body of Knowledge but no universal success

Cottage industry, reversion to the old-days

Determinate, quality driven, high reliability, business model oriented

5


Where Are We?

Bowsers that are limited

Time-To-Market web-application deployment

16 year old wunder-kinder throwing systems together

rapidly deployed functionality

NO PROBLEMS

NO PROBLEMS

MATE!MATE!

DISASTER

IN WAITING!

poorly designed functionality

rapid evolution of systems to meet customer needs conventional approaches being left behind

the old do not understand the new

Traditionalist’s View

Modernist’s View

6


“F1. Current software has too many surprises. The sources of surprise are poorly understood.”

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)

“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.”

To many surprises….!!!(nsf report on s/w research

1998)

7


“F1. Current software has too many surprises. The sources of surprise are poorly understood.”

Sources of surprises... Real and apparent unpredictability in behaviour...

No surprises….!!!(nsf report on s/w research 1998)

“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….

8


By way of Illustration...Some Contradictions……

and confusion

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”

1. Software Architecture.. ‘not immutable, not always determinable a’priori,multiple versions in one artefact, retrofitable…. Analog with “built” systems not clear.

9


Some Contradictions……and confusion (cont’d)

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

6. SWEBOK.. Organised body of knowledge opposed by leading SE players.

11. Documentation matters but.. It’s seldom actually done

10


10

The optimists view of technology The optimists view of technology transfer..transfer..

11


11

A Tech-Transfer ModelA Tech-Transfer Model

12


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) ORIENTEDA 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

13

Karl Reed NR 5/1/2001Australia (cont’d)

THE SOFTWARE INDUSTRY BY THE MID 1980'S WAS…(cont'd)a)A HIGH-LEVEL TOOL DEVELOPER

Developed "4GL's" and APPLICATION GENERATORSBoth HP and DataGeneral used Australian products for their early Application GeneratorsThe 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 PROTOTYPINGCDA used SNOBOL in the mid-1970's for protoyping commercial systems.

14


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

15


THE HISTORY…(cont'd)

THE SOFTWARE INDUSTRY'S WEAKNESSES…a)LIMITED INTERACTION WITH RESEARCH

COMMUNITY…b)JEALOUS AND SECRETIVE ABOUT

DEVELOPMENT METHODSc)ABSENCE OF TARGETED RESEARCH CENTRESd)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

16


THE SOFTWARE INDUSTRY's PARAMETERS…

TOTAL SALES…US$1.8BS/W PRODUCT of totalDOMESTIC SHARE OF PRODUCT 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

17


Approaching Software Developers…Approaching Software Developers…

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

Technico-Commercial Drivers… the linkage

Show an economic benefit

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)

18


Typical SE Research Agenda Australia ~ 1997

1.Re-engineering and Empirical Studies of s/w Practice,

2.Tools and Methodologies, and Design Representation,

3. Re-Use,

4. Evolving Software,

6. Object Oriented Dev.

7. Product Quality Measurement

8. Time-to-Market

9. Testing

¶ Impact of developments in run-time platforms

¶ Low-cost and evolving software

¶ User Interface Development

¶ Software Productivity

¶ Performance Predictability

¶ Software Product Quality Certification

¶ Time to Market ¶

Technico-commercial Drivers

Research-Commercial Mapping… Defining Relevance

19


The ANSEI

Technico-Comercial Driver to Research agenda

mapping

Table I - Relationship Between Technico-Commercial Issuesand Research Agendas

Technical-Commercial Issue

Proposed Research

Issue Implications Main Agenda Items Sub-Agendas OUTCOMES SupportsImpact ofdevelopments in run-timeplatforms

Addfunctionalityto legacySystems(e.g.GUI),ability tomovesoftwarebetweenplatforms,need toreducemaintance

1.Re-engineering andEmpirical Studies ofs/w Practice,

Designreasoningrecording,empericalstudies ofpractice,softwaremigration,impact onmethodologies

Tools andmethodologies, detailedknowledge ofcurrentpractice

Processimprovement,validation ofmethodologies,actual measuresof s/w quality,s/warchitecture,domainengineering,evolving s/w,nature ofsoftwareengineering

Low-costandevolvingsoftware

Modifiability,maintanance,techniquesfor designing

3. Re-Use,


6. Object OrientedDevelopment

8. Time-to-Market

Methodologies formodifiableand evolvingsoftware,empericalstudies ofexistingpractice

Methodologies incorp.design forevolution, s/wquality , tools

Automaticqualitymeasurement,processimprovement,nature ofsoftwareengineering

UserInterfaceDevelopment

Design forergonomics,engineeringbased onapplicationsdataprocessing

1. Re-engineering andEmpirical Studies of s/wPractice,

3. Re-Use,

5. Engineering ofUser Interfaces,

6. Object OrientedDevelopment

9. Testing

Ergonomics,characterisaton ofprocessing,methodologiesfor this

Methodologies forengineeringuserinterfaces,

Allmethodologies,ergonomics

SoftwareProductivity

Reuse,improvedmethods

1. Re-engineering andEmpirical Studies of s/wPractice,

2. Tools andMethodologies, and DesignRepresentation,

3. Re-Use,

9. Testing

Softwareresuse, andmethodologiesexplicitlyincluding this,prescriptivemethodologies, s/warchitecture,improveddesignrepresentation,projecttracking

Methodologies generatingre-usablecomponents,maximisingre-use withinsingleprojects, andmaximinsingre-use of"artifacts",includingdesign

Designrecording,nature ofsoftwareengineering,s/warchitecture,evolvingsoftware

PerformancePredicatability

Appropriatemethods forincludingconstraints indesign

1. Re-engineering andEmpirical Studies ofs/w Practice,

2.Tools andMethodologies, andDesignRepresentation,9. Testing

Performanceengineering,methodologies, operationalmathematicalmethods

Methodologies incl. newmathematicalmodels, toolssuppportingthis,diagrammingschemes

Designrecording,nature ofsoftwareengineering,s/w architecture

SoftwareProductQualityCertification

Automaticandincrementalmeasurementof product

1.Re-engineering andEmpirical Studies of s/wPractice,

2.Tools and Methodologies,and Design Representation,

3. Re-Use,


7. Product Q.Measurement

9. Testing

Programstructure,metrics andlanguageprocessors

Tools forautomaticmeasurement

S/Warchitecture,designrecording,nature of SE

Time toMarket

ImprovedDevelopmenttechniques,Tool support,CASE

1.Re-engineering EmpiricalStudies of s/w Practice,

2.Tools and Methodologies,and Design Representation,

3. Re-Use,


6. Object Oriented Dev.

7. Product QualityMeasurement8. TTM9. Testing

As forproductivity,but specialemphasis onincrementaldelivery, andqualityenhancingmethodologies

Methodologies and tools,designrecording

s/warchitecture, re-use andevolvingsoftware

20


Technology Transfer Mechanisms “Champions” in the organistions targetted.. Need to be involved by the researchers Disclosure, workshops, training, publications, technical newspapersProfessional 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

21

Karl Reed NR 5/1/2001Technology Transfer Mechanisms(cont’d)

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

22


issuesBaragry’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

23


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?

24


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

§ architectural styles

development of maintainability and evolvability classifications for --

development of maintainability and evolvability classifications for architectural styles

§ design methodologies

25


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

26


Tak Ska du har…Tak Ska du har…

software engineering technology transfer…the way forward or the way back

Documents