u Designing, building and maintaining large software systems

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide

Software Engineering

u Designing, building and maintaininglarge software systems


Objectivesu To define software engineering and explain its

importanceu To discuss the concepts of software products and

software processesu To explain the importance of process visibilityu To introduce the notion of professional

responsibility


Topics coveredu Software productsu The software processu Boehm’s spiral modelu Process visibilityu Professional responsibility


u The economies of ALL developed nations aredependent on software

u More and more systems are software controlledu Software engineering is concerned with theories,

methods and tools for professional softwaredevelopment

u Software engineering expenditure represents asignificant fraction of GNP in all developedcountries

Software engineering


u Software costs often dominate system costs. Thecosts of software on a PC are often greater thanthe hardware cost

u Software costs more to maintain than it does todevelop. For systems with a long life,maintenance costs may be several timesdevelopment costs

u Software engineering is concerned with cost-effective software development

Software costs


Software productsu Generic products

• Stand-alone systems which are produced by a developmentorganisation and sold on the open market to any customer

u Bespoke (customised) products• Systems which are commissioned by a specific customer and

developed specially by some contractor

u Most software expenditure is on generic productsbut most development effort is on bespokesystems


Software product attributesu Maintainability

• It should be possible for the software to evolve to meetchanging requirements

u Dependability• The software should not cause physical or economic damage in

the event of failure

u Efficiency• The software should not make wasteful use of system resources

u Usability• Software should have an appropriate user interface and

documentation


Importance of product characteristicsu The relative importance of these characteristics

depends on the product and the environment inwhich it is to be used

u In some cases, some attributes may dominate• In safety-critical real-time systems, key attributes may be

dependability and efficiency

u Costs tend to rise exponentially if very highlevels of any one attribute are required


Efficiency costsCost

Ef ficiency


The software processu Structured set of activities required to develop a

software system• Specification• Design• Validation• Evolution

u Activities vary depending on the organisationand the type of system being developed

u Must be explicitly modelled if it is to bemanaged


Process characteristicsu Understandability

• Is the process defined and understandability

u Visibility• Is the process progress externally visible

u Supportability• Can the process be supported by CASE tools

u Acceptability• Is the process acceptable to those involved in it


Process characteristicsu Reliability

• Are process errors discovered before they result in producterrors

u Robustness• Can the process continue in spite of unexpected problems

u Maintainability• Can the process evolve to meet changing organisational needs

u Rapidity• How fast can the system be produced


Engineering process modelu Specification - set out the requirements and

constraints on the systemu Design - Produce a paper model of the systemu Manufacture - build the systemu Test - check the system meets the required

specificationsu Install - deliver the system to the customer and

ensure it is operationalu Maintain - repair faults in the system as they

are discovered


Software process modelsu Normally, specifications are

incomplete/anomalousu Very blurred distinction between specification,

design and manufactureu No physical realisation of the system for testingu Software does not wear out - maintenance

does not mean component replacement


Generic software process modelsu The waterfall model

• Separate and distinct phases of specification and development

u Evolutionary development• Specification and development are interleaved

u Formal transformation• A mathematical system model is formally transformed to an

implementation

u Reuse-based development• The system is assembled from existing components


Waterfall modelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


Waterfall model phasesu Requirements analysis and definitionu System and software designu Implementation and unit testingu Integration and system testingu Operation and maintenanceu The drawback of the waterfall model is the

difficulty of accommodating change after theprocess is underway


Evolutionary development

Validation Finalversion

Development Intermediateversions

Specification Ini tialversion

Outlinedescription

Concurrentactivities


Evolutionary developmentu Exploratory prototyping

• Objective is to work with customers and to evolve a finalsystem from an initial outline specification. Should start withwell-understood requirements

u Throw-away prototyping• Objective is to understand the system requirements. Should start

with poorly understood requirements


Evolutionary developmentu Problems

• Lack of process visibility• Systems are often poorly structured• Special skills (e.g. in languages for rapid prototyping) may be

required

u Applicability• For small or medium-size interactive systems• For parts of large systems (e.g. the user interface)• For short-lifetime systems


Risk managementu Perhaps the principal task of a manager is to

minimise risku The 'risk' inherent in an activity is a measure of

the uncertainty of the outcome of that activityu High-risk activities cause schedule and cost

overrunsu Risk is related to the amount and quality of

available information. The less information, thehigher the risk


Process model risk problemsu Waterfall

• High risk for new systems because of specification anddesign problems

• Low risk for well-understood developments using familiartechnology

u Prototyping• Low risk for new applications because specification and

program stay in step• High risk because of lack of process visibility

u Transformational• High risk because of need for advanced technology and

staff skills


Hybrid process modelsu Large systems are usually made up of several

sub-systemsu The same process model need not be used for

all subsystemsu Prototyping for high-risk specificationsu Waterfall model for well-understood

developments


Spiral model of the software process

Riskanalys is

Riskanalys is

Riskanalys is

Riskanalysis Proto-

ty pe 1

Prototype 2Prototype 3

Opera-ti onalprotoype

Concept ofOperati on

Simul ati ons, models, b ench marks

S/Wrequi rements

Requi rementvalid ati on

Desi gnV&V

Productdesi gn Detail ed

desi gn

CodeUni t tes t

Integr ationtestAcceptance

testServ ice Develop, v erifynext-l evel product

Ev aluate altern ativesid en tify, resol ve risks

Determ ine ob jectiv esalternatives and

cons traints

Plan next phase

Integrati onand test p lan

Developmentpl an

Requi rements pl anLi fe-cycle pl an

REVIEW


Phases of the spiral modelu Objective setting

• Specific objectives for the project phase are identified

u Risk assessment and reduction• Key risks are identified, analysed and information is sought to

reduce these risks

u Development and validation• An appropriate model is chosen for the next phase of

development.

u Planning• The project is reviewed and plans drawn up for the next round

of the spiral


Template for a spiral roundu Objectivesu Constraintsu Alternativesu Risksu Risk resolutionu Resultsu Plansu Commitment


Quality improvementu Objectives

• Significantly improve software quality

u Constraints• Within a three-year timescale

Without large-scale capital investmentWithout radical change to company standards

u Alternatives• Reuse existing certified software

Introduce formal specification and verificationInvest in testing and validation tools


u Risks• No cost effective quality improvement possible

Quality improvements may increase costs excessivelyNew methods might cause existing staff to leave

u Risk resolution• Literature survey

Pilot projectSurvey of potential reusable componentsAssessment of available tool supportStaff training and motivation seminars


u Results• Experience of formal methods is limited - very hard to

quantify improvementsLimited tool support available for company standarddevelopment system.Reusable components available but little reuse tool support

u Plans• Explore reuse option in more detail

Develop prototype reuse support toolsExplore component certification scheme

u Commitment• Fund further 18-month study phase


Catalogue Spiralu Objectives

• Procure software component catalogue

u Constraints• Within a year

Must support existing component typesTotal cost less than $100, 000

u Alternatives• Buy existing information retrieval software

Buy database and develop catalogue using databaseDevelop special purpose catalogue


u Risks• May be impossible to procure within constraints

Catalogue functionality may be inappropriate

u Risk resolution• Develop prototype catalogue (using existing 4GL and an

existing DBMS) to clarify requirementsCommission consultants report on existing informationretrieval system capabilities.Relax time constraint


u Results• Information retrieval systems are inflexible. Identified

requirements cannot be met.Prototype using DBMS may be enhanced to completesystemSpecial purpose catalogue development is not cost-effective

u Plans• Develop catalogue using existing DBMS by enhancing

prototype and improving user interface

u Commitment• Fund further 12 month development


Spiral model flexibilityu Well-understood systems (low technical risk) -

Waterfall model. Risk analysis phase isrelatively cheap

u Stable requirements and formal specification.Safety criticality - Formal transformation model

u High UI risk, incomplete specification -prototyping model

u Hybrid models accommodated for different partsof the project


Spiral model advantagesu Focuses attention on reuse optionsu Focuses attention on early error eliminationu Puts quality objectives up frontu Integrates development and maintenanceu Provides a framework for hardware/software

development


Spiral model problemsu Contractual development often specifies

process model and deliverables in advanceu Requires risk assessment expertiseu Needs refinement for general use


Process visibilityu Software systems are intangible so managers

need documents to assess progressu However, this may cause problems

• Timing of progress deliverables may not match the time neededto complete an activity

• The need to produce documents constraints process iteration• The rime taken to review and approve documents is significant

u Waterfall model is still the most widely useddeliverable-based model


Waterfall model documents

Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation


Process model visibilityProcess model Process visibilityWaterfall model Good visibility, each activity produces some

deliverableEvolutionarydevelopment

Poor visibility, uneconomic to producedocuments during rapid iteration

Formaltransformations

Good visibility, documents must be producedfrom each phase for the process to continue

Reuse-orienteddevelopment

Moderate visibility, it may be artificial toproduce documents describing reuse andreusable components.

Spiral model Good visibility, each segment and each ringof the spiral should produce some document.


Professional responsibilityu Software engineers should not just be concerned

with technical considerations. They have widerethical, social and professional responsibilities

u No clear rights and wrongs about many of theseissues• Development of military systems• Whistleblowing• What’s best for the software engineering profession


Ethical issuesu Confidentialityu Competenceu Intellectual property rightsu Computer misuse


Key pointsu Software engineering is concerned with the

theories, methods and tools for developing,managing and evolving software products

u Software products consist of programs anddocumentation. Product attributes aremaintainability, dependability, efficiency andusability

u The software process consists of those activitiesinvolved in software development


Key pointsu The waterfall model considers each process

activity as a discrete phaseu Evolutionary development considers process

activities as concurrentu The spiral process model is risk-drivenu Process visibility involves the creation of

deliverables from activitiesu Software engineers have ethical, social and

professional responsibilities

u Designing, building and maintaining large software systems

Documents

Transcript of u Designing, building and maintaining large software systems