View
1
Download
0
Category
Preview:
Citation preview
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Software Engineering
u Designing, building and maintaininglarge software systems
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Topics coveredu Software productsu The software processu Boehm’s spiral modelu Process visibilityu Professional responsibility
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Efficiency costsCost
Ef ficiency
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Waterfall modelRequirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Evolutionary development
Validation Finalversion
Development Intermediateversions
Specification Ini tialversion
Outlinedescription
Concurrentactivities
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Template for a spiral roundu Objectivesu Constraintsu Alternativesu Risksu Risk resolutionu Resultsu Plansu Commitment
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Spiral model problemsu Contractual development often specifies
process model and deliverables in advanceu Requires risk assessment expertiseu Needs refinement for general use
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
Ethical issuesu Confidentialityu Competenceu Intellectual property rightsu Computer misuse
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 1 Slide
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
Recommended