23
Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Software Engineering ftware Engineering is the science and a ding significant software systems that on time on budget with acceptable performance with correct operation.

3 introduction

Embed Size (px)

Citation preview

Page 1: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 1

Software Engineering

• Software Engineering is the science and art ofbuilding significant software systems that are:

1) on time2) on budget3) with acceptable performance4) with correct operation.

Page 2: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 2

The economies of all developed nations are dependent on software.

More and more systems are software controlled. Software engineering is concerned with theories,

methods and tools for professional software development.

Software engineering expenditure represents a significant fraction of the GNP of developed countries.

Software Engineering

Page 3: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 3

Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost.

Software costs more to maintain than it does to develop.

Software engineering is concerned with cost-effective software development.

Software Costs

Page 4: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 4

Software Products Generic products:

– Stand-alone systems which are produced by a development organization and sold on the open market to any customer.

Customized products:– Systems which are commissioned by a specific customer and

developed specially by some contractor.

Page 5: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 5

Software Product Attributes Maintainability Dependability Efficiency Usability

Page 6: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 6

Importance of Product Characteristics The relative importance of these characteristics

depends on the product and the environment in which it is to be used.

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

dependability and efficiency.

Costs tend to rise exponentially if very high levels of any one attribute are required.

Page 7: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 7

Efficiency CostsCost

Ef ficiency

Page 8: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 8

The Software Process Structured set of activities required to develop a

software system– Specification– Design– Validation– Evolution

Activities vary depending on the organization and the type of system being developed.

Must be explicitly modeled if it is to be managed.

Page 9: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 9

Engineering Process Model Specification: Set out the requirements and

constraints on the system. Design: Produce a model of the system. Manufacture: Build the system. Test: Check the system meets the required

specifications. Install: Deliver the system to the customer and

ensure it is operational. Maintain: Repair faults in the system as they

are discovered.

Page 10: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 10

Software Engineering is Different

Normally, specifications are incomplete. Very blurred distinction between specification,

design and manufacture. No physical realization of the system for testing. Software does not wear out - maintenance

does not mean component replacement.

Page 11: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 11

Generic Software Process Models Waterfall

– Separate and distinct phases of specification and development

Evolutionary– Specification and development are interleaved

Formal Transformation– A mathematical system model is formally transformed to an

implementation

Reuse-based– The system is assembled from existing components

Page 12: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 12

Waterfall Process ModelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Page 13: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 13

Evolutionary Process Model

Validation Finalversion

Development Intermediateversions

Specification Initialversion

Outlinedescription

Concurrentactivities

Page 14: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 14

Process Model Problems Waterfall

– High risk for new systems because of specification and design problems.

– Low risk for well-understood developments using familiar technology.

Prototyping– Low risk for new applications because specification and

program stay in step.– High risk because of lack of process visibility.

Transformational– High risk because of need for advanced technology and

staff skills.

Page 15: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 15

Hybrid Process Models Large systems are usually made up of several

sub-systems. The same process model need not be used for

all subsystems. Prototyping for high-risk specifications. Waterfall model for well-understood

developments.

Page 16: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 16

Spiral Process Model

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

Page 17: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 17

Spiral Model Advantages Focuses attention on reuse options. Focuses attention on early error elimination. Puts quality objectives up front. Integrates development and maintenance. Provides a framework for hardware/software

development.

Page 18: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 18

Spiral Model Problems Contractual development often specifies

process model and deliverables in advance. Requires risk assessment expertise.

Page 19: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 19

Process Visibility Software systems are intangible so managers

need documents to assess progress. Waterfall model is still the most widely used

model.

Page 20: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 20

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

Page 21: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 21

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.

Page 22: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 22

Professional Responsibility Software engineers should not just be concerned

with technical considerations. They have wider ethical, social and professional responsibilities.

No clear rights and wrongs about many of these issues:– Development of military systems– Whistle blowing

Page 23: 3 introduction

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 23

Ethical Issues Confidentiality Competence Intellectual property rights Computer misuse