Introduction toSoftware Engineering(INSE)

Lectures by Kit Lester

“Housekeeping”

Fire alarm Escape routes from this room Assembly point

Please check the escape route & assembly point from your tutorial room as well…

The unit Depends on experiences you should

have had in first-year programming units…

… but is not “more programming”. It’s about the whole process, not the

technical details It “feeds” final-year ADSE and various

other 2nd- & final-year units

You/your course

The unit is core for all the “hard-technology” computing degrees

It is a required unit for exemptions if you wish to go on to be a Chartered Engineer

Contacting me

kit.lester@port.ac.uk lesterk.myweb.port.ac.uk/inse/

Office: Buckingham 1.12

Me Dr C Lester, BSc MSc PhD CEng Software industry background Interests in SE technology support

especially Programming languages, SE-oriented editors, & formal methods: Increasingly – “Web Engineering”

Administrative matters

Lectures A one-hour session per week

Tutorials Weekly, various rooms & times - see your

timetable

Notes & books Handout notes booklet

is also on the /inse/ website is enough to pass…

Suggestion: to do better than “just pass”also buy one of the books described in the

handout booklet & use it to follow up lectures (you have

nearly a day a week to spend on this unit…)

Assessment

Coursework… … a team project … to illustrate the theory from the lectures … handout in tutorial 4 … which provides plenty of SE issues to

think about ready for... … the exam

Tutorials & the exam

First 2 tutorials, last 2, and a few between are of a style that should help prepare you for the exam – tutorial 1 explains how

Last 2 tutorials are overt exam-preparation: The “theme” of this year’s exam & A past paper

So skipping the tutorials is unwise…

INSE - Lecture 1

What is “Software Engineering”?

“What is SE?” - key answers Thinking about the problems of

constructing all kinds of program ... ...not just commercial/admin programs. In particular...… engineering the program(s);… dealing with “difficulties” such as

size, complexity, real-time response, safety, distribution, etc

Historical background to S.E. ambitious attempt at things we can’t do yet… … led to programming and data structures

early 1960s mundane but massive admin tasks needing

moderate-sized programs… … led to systems analysis

late 1960s/early 1970s attempts at tasks that demand large & reliable

programs… … led to software engineering

Fundamental problems

Cost of software goes up faster than proportionally with size…

… which goes up faster than proportionally with the perceived functionality

Reliability also drops alarmingly as size goes up.

Management difficulties

New problems of scale

Solutions to small-scale problems

seldom scale up

into solutions to large-scale problems

Non-admin software Operating systems + LAN systems Compilers, raw-text editors, IDEs Word-processors, spreadsheets Browsers, multimedia, sound etc Database, network, & other under-pinnings for the

admin programs Web-servers, browsers, TCP/IP stacks Real-time programs - industrial control, avionics,

medical, communications “Embedded” - in some other product ...

Tensions in S.E.

Tensions in S.E.

methods ………… ……..……. principles

Tensions in S.E.

methods ………… ……..……. principles

compromise ……. ………..…. perfection

Tensions in S.E.

methods ………… ……..……. principles

compromise ……. ………..…. perfection

handleturning ….. …………….……. flair

Tensions in S.E.

methods ………… ……..……. principles

compromise ……. ………..…. perfection

handleturning ….. …………….……. flair

generality ………. …………… precision

Tensions in S.E.

methods ………… ……..……. principles

compromise ……. ………..…. perfection

handleturning ….. …………….……. flair

generality ………. …………… precision

complex need …. ... sophisticated need

Tensions in S.E.

methods ………… ……..……. principles

compromise ……. ………..…. perfection

handleturning ….. …………….……. flair

generality ………. …………… precision

complex need …. ... sophisticated need

S.A. S.E

Reality...

Lets look at some press cuttings

Usual problems The software was late The software was over budget

the above 2 often come together The software seriously mismatches the

specification The specification was wrong

which is horribly common The management were not experienced SE

managers which is also horribly common

The nature of Software “Engineering”

So what is S.E.? (1)

The whole collection of things we do to try to build software well

the determination to turn it into an Engineering discipline

So what is S.E? (2)

The study of all matters concerned with the reliable and efficient production of reliable and efficient programs

(note the absence of any limits on the kinds of program)

Aims of the S.E. unit to create awareness of the problems

encountered in developing “difficult” software

to introduce commonly-accepted techniques for combatting those problems

to provide links to S.E. aspects of other units of your course

to start to prepare you for “the real world” of software production

After this lecture

think about your past programming efforts - to what extent were they what you would call “engineering”?

the first tutorial also addresses the issue of “what is (or should be) S.E.”

© C Lester 1997-2014