Software Engineering Design and Accounting Process

(1)

Software Engineering

Then, and Now

Hans van Vliet

Vrije Universiteit

Amsterdam, The Netherlands

email: [email protected]

My personal history

1967 computer operator, programmer

1973-1978 MSc Mathematics/CS 1979 PhD, ALGOL 68

1996- Research Software Architecture (ALMA, GRIFFIN, Stephenson) 1979 PhD, ALGOL 68

1986 Professor Software Engineering, VU University 1983 Software Engineering textbook (1993, 2000, 2008) 2008 Journal of Systems and Software (EiC)

Today’s agenda

Software Engineering = Engineering? Teaching Software Engineering

Recent developments

Software engineering The beginning

 1968/69 NATO conferences: introduction of the term Software Engineering

 Idea: software development is not an art, or a bag of tricks

 Build software like we build bridges

Central themes

 SE is concerned with BIG programs

 complexity is an issue  software evolves  you’re doing it together

It gets bigger and bigger

Handset: from 2 to 10 MLOC in the next 4 years

Car: from 1 to 100 MLOC between 2000 and 2010Car: from 1 to 100 MLOC between 2000 and 2010

(2)

Growth of maintenance problem

1975: ~75,000 people in maintenance (17%)

1990: 800,000 (47%)

2005: 2,500,000 (76%)

2015: ??

(Numbers from Jones (2006))

How high do you fly, on average?

IF read_meter1 (V1) THEN display(V1) ELSE IF read_meter2 (V2) THEN display(V2) ELSE

display(3000)

Engineering in SE

Engineering words: building software, requirements, specification, maintenance, prototyping, …

Metaphor plays active role in our thought processes

Example

Requirements engineering:

Information flows from A (user) to B (software engineer)

Good communication is without friction or blockage

Good reception only involves extraction

Model: RE is about documentation

Alternative: RE is about understanding

Overall message

There’s more to software engineering than engineering

In particular: there’s an important In particular: there s an important social dimension

Today’s agenda

Software Engineering = Engineering?

Teaching Software Engineering Recent developments

(3)

Characterization of students

entering the SE course

Not familiar with requirements engineering Do not know how to relate requirements to

ff t effort

Do not know how to document a design

One comment: “how can I possibly write down what the system does when I haven’t programmed the damn thing yet?”

Brooks’ law

Op een hard zadel is het slecht zitten

Adding manpower to a late project makes it later

A utility tree

Performance

Transaction response time (H, M) Throughput 150 transactions/sec

Utility Usability

Maintainability

Training

Database vendor releases new version

Normal operations

What is a utility tree? Today’s agenda

Software Engineering = Engineering?

Teaching Software Engineering

(4)

Recent developments Rise of agile methods

Shift from producing software to using software

Success of Open Source Software

Software development becomes more heterogeneous

Software engineering becomes data-intensive

The Agile Manifesto

 Individuals and interactions over processes and tools

 Working software over comprehensive

g p

documentation

 Customer collaboration over contract negotiation

 Responding to change over following a plan

Producing software Using software

Builders build pieces, integrators integrate them

Component-Based Development (CBSD)

Software Product Lines (SPL)

Commercial Off-The-Shelves (COTS)

Service Orientation (SOA)

Open Source: crowdsourcing

1. Go to LEGO site

2. Use CAD tool to design your favorite castle

3. Generate bill of materials

4. Pieces are collected, packaged, and sent to you

5. Leave your model in LEGO’s gallery

6. Most downloaded designs are prepackaged

 No requirements engineers needed!

 Gives rise to new business model

Heterogeneity

Old days: software development department had everything under control

Nowadays:y

Teams scattered around the globe

Components acquired from others

Includes open source parts

Services found on the Web

Data-intensive software engineering

Mining software archive (version control data)

Mining bug repositoryMining bug repository

Recovering audit information from a large set of documents

(5)

Context

hundreds of developers

decades of development

millions LOC

developed in C, C++, C#, … Magnetic Resonance

(MR)

How (un)evolvable is this architecture?

Subs1 _Subs

2 Subs3

Subs4

Subs5

Example cluster hierarchy

The Top 10 Hot Spots

Hot Spot

Non-issue

Issue

Already known

Yet unknown

1 2 3 4 5 6 7 8 9 10

Wide format printers, scanners, copiers

Mining bug repository

Architect can specify everything

Takes a lot of time

Curtails developers

Architects can specify less

Saves time

(6)

The Architect & Defects: a case study  Defects for the architect…

 What type of defects?

 How many are really about architecture?

 What is the relation with specs?

 Did the specs change?

 Did the architecture change?Did the architecture change?

 How many people were involved?

 …

Data mining: analyse the defects to find improvement areas.

A Reading Guide for Newcomers

Problem:

No reading guide for software product documentation

Where can one find relevant architectural knowledge?

Solution:

Architectural Knowledge Discovery

‘Reading guide’ for software product documentation

Technique: Latent Semantic Analysis (LSA)

Uncovers latent semantic structure of documentation

Employ this structure to guide the reader

A ≈ A*_{= U}*_{* S}*_{* V}*T

A Reading Guide: Where to start reading?

Auditor knows nothing yet interested in ‘architecture’ in a broad sense

Preference of short documents over long documents

Q: What is the document that best matches the term ‘architecture’ ordered by document size?

A: Document #46:

2 pages long,

does not contain the literal word ‘architecture’,

doesprovide an architectural overview (components, environment, relations, …)

Conclusions

Software engineering is ALIVE

Themes come and go

Software engineering is social too