1. Introduction to Software Engineering (INSE)  Lectures by Kit Lester

2. “Housekeeping” u Fire alarm u Escape routes from this room u Assembly point u Please check the escape route & assembly point from your tutorial room as well…

3. 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 2 nd - & final-year units

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

5. Contacting me  kit.lester@port.ac.uk  lesterk.myweb.port.ac.uk/inse/  Office: Buckingham 1.12

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

7. Administrative matters  Lectures  A one-hour session per week  Tutorials  Weekly, various rooms & times - see your timetable

8. 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 … )

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

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

11. INSE - Lecture 1 What is “ Software Engineering ” ?

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

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

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

15. New problems of scale Solutions to small-scale problems seldom scale up into solutions to large-scale problems

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

17. Tensions in S.E.

24. Reality...  Lets look at some press cuttings

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

36. The nature of Software “ Engineering ”

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

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

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

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

41. u © C Lester 1997-2014