lecture 1: introduction · lecture 1 software engineering the problem is complexity. many sources...

LECTURE 1: INTRODUCTION

Software Engineering

Mike Wooldridge

Lecture 1 Software Engineering

1 Why Software Engineering?

• Software development is hard.

• Important to distinguish “easy” systems(one developer, one user, experimental useonly) from “hard” systems (multipledevelopers, multiple users, products).

• Experience with “easy” systems ismisleading.One-person techniques do not scale up.

• Analogy with bridge building:— over a stream = easy, one person job— over River Severn. . .The techniques don’t scale.

Mike Wooldridge 1


• The problem is complexity.

•Many sources of complexity, but size iskey:

– UNIX contains 4 milliion lines of code– Windows 2000 contains 108 lines of code

“If steel girders could be infinitely long,and didn’t bend no matter what you did,then buildings could be as large andcomplex and computer systems.”(Brian Reid)

• Software engineering is about managingthis complexity.

Mike Wooldridge 2


2 Goals of Software Development

• Satisfy users requirements.

• High reliability.

• Low maintenance costs.

• Delivery on time.

• Low production costs.

• High performance.

• Ease of reuse.

Note importance of tradeoffs.

Mike Wooldridge 3


2.1 Satisfying User Requirements

•Many programs simply don’t do what endusers want.

• Typical percentages for large-scalecommissioned systems:45% delivered but not used27% paid for but not delivered17% abandoned6% used after changes5% used as delivered

• Users find it hard to articulate what theywant.

• Developers find it hard to understandwhat users say!

Mike Wooldridge 4


2.2 High Reliability

•Mistakes in programs are genericallyknown as bugs.

• A crucial lesson:You can prove that bugs are there; you can’tprove that they aren’t.

• Bugs can be expensive, in terms of. . .

– human lives:in safety critical systems, e.g., nuclearreactor control, fly-by-wire aircraft

– money:software bug in failed Ariane 5 launchcost US$500 million

– poor customer relations:Microsoft problems with originalWindows release caused the companyhuge problems.

Mike Wooldridge 5


2.3 Low Maintenance Costs

•Maintenance is what is done to softwareafter it starts being used.

•Maintenance may be:

– corrective — fixing bugs (21%);– adaptive — altering software to fit

changing software (25%);– perfective — to meet new requirements

(50%);– preventative — to reduce further

maintenance (4%).

•Maintenance is expensive — muchsoftware is “finely balanced”, withapparently small changes having a majorimpact.(Imagine being a car mechanic, andhaving to figure out from scratch how theengine works every time you start workon a new car.)

•Maintenance typically accounts for 65% ofoverall project costs.

Mike Wooldridge 6


2.4 Delivery on Time

• Software projects are notorious foroverrunning.

• It is extraordinarily hard to reliably predicthow much effort a software project willrequire, and when it will be completed.

• The relationship between person monthsdevoted and development time is almost neverlinear:

– adding person months of effort to aproject frequently has no effect;

– adding person months of effort oftenmakes the project slower.

Mike Wooldridge 7


2.5 Production Costs

• Software production an enormousindustry:

– in 1985, US$70 billion spent ondevelopment in 1985

– OS/360 cost US$200 million– estimated expenditure for year 2000:

US$770 billion– 12% growth per annum!

• Software developer skills in poor supply⇒ expensive.

Mike Wooldridge 8


2.6 High Performance

• Systems that are specially tailored to workquickly are optimised.

• Optimization can improve throughput(speed) and memory usage, but:

– resource intensive;– results in systems tailored to a specific

environment;– less comprehensible to developers;– less easy to change;– less easy to port to other environments.

Mike Wooldridge 9


2.7 Ease of Reuse

• Goal of software reuse: use same softwarein different systems and softwareenvironments:

– reduce development costs;– improve reliability.

•Most software has two parts:

– environment independent part — canbe moved between environments quiteeasily (usually includes the “logic” ofthe system);

– environment dependent part — cannotbe moved easily (includes e.g., GUI,hardware controllers, . . . )

A clear separation between the 2 is crucial.

• Requires designing for reuse.

Mike Wooldridge 10


3 The Software Process

• The waterfall model of the softwarelifecycle:

Mike Wooldridge 11


• Requirements analysis and definition.

– The system’s services, constraints, andgoals are established.

– Requirements analysis means longconsultations with the end-user toestablish exactly what they want.

– Requirements definition means statingwhat the user wants, in terms that areunderstandable by both end-users andsystem developers; relatively informal.

– Requirements specification is a moreformal statement which sets outproposed system services in detail. Thisdocument may act as contract betweensystem procurer and developer.

– Software specification is an abstractdescription of system structure &operation, intended to serve as the basisfor the design stage.

– Deliverables: requirements definitiondocument, requirements specificationdocument & software specificationdocument.

Mike Wooldridge 12


• System and software design.

– Requirements are divided into thoserelating to hardware and those relatingto software.

– Software design then meansrepresenting the functions of each unitin a way that may be transformed intocode.

– Deliverables: unit and system designs.

Mike Wooldridge 13


• Implementation and unit testing.

– Unit designs are transformed intoprograms.

– Individual units are then tested, toensure that they satisfy theirspecification.

– Deliverables: implemented and testedunit programs.

Mike Wooldridge 14


• System testing.

– Individual programs & units areintegrated (gradually!) and tested toensure that system requirements havebeen met.

– The system is then installed.– The system is then maintained.– Deliverables: implemented, tested

system.

Mike Wooldridge 15


4 Other Development Models

• Prototyping:

– develop “quick and dirty” systemquickly;

– expose to user comment;– refine;

until adequate system developed.Particularly suitable where:

– detailed requirements not possible;– powerful development tools (e.g., GUI)

available.

• Formal transformation:

– inolves use of mathematical methodsfor specification, development,verification;

– despite several decades of effort, notusable without special skills;

– used in certain applications (e.g.,verification of DS1 controller).

Mike Wooldridge 16


5 Challenges for Software Engineering

• The legacy challenge.

– Hardware evolves much faster thansoftware.

– Most software systems in use todaywere developed many years ago.

– They are technologically obsolete (cfCOBOL Y2K problem) but performbusiness-critical tasks.

– Frequently, nobody understands howthe software works.

– Modifications over the years havemeant that the software logic hasbecome corrupted and confused.

– Original developers have moved on.– How to manage, maintain, replace,

integrate this software?

Mike Wooldridge 17


• The heterogeneity challenge.

– Isolated software systems — once thenorm — are now the exception.

– Most commercial systems are nownetworked.

– Implies that software systems mustcleanly integrate with other differentsoftware systems, built by differentorganisations & teams using differenthardware and software platforms.

Mike Wooldridge 18


• The delivery challenge.

– Software projects are notorious forbeing overdue and over budget.

– The delivery challenge is aboutconsistently being able to deliversystems on budget and on schedule.

– As the complexity of systems that wedevelop increases, this challengebecomes harder.

Mike Wooldridge 19


6 Professional Issues

• Bridge builders and other types of“conventional” engineer are acutely awareof their professional responsibilities.

• Software engineers have professionalresponsibilities as well:

– Confidentiality.Engineers should respect theconfidentiality of their employers andclients.

– Competence.Engineers should not misrepresent theirlevel of competence.

– Intellectual property rights (IPR).These relate to who owns ideas.Typically, your employer does! Youneed to understand laws governingthese, and how they relate to the workyou are doing.

Mike Wooldridge 20


– Computer misuse.Software engineers should not misusetheir skills to misuse other people’scomputers.

Mike Wooldridge 21

lecture 1: introduction · lecture 1 software engineering the problem is complexity. many sources...

Documents