introduction to software engineering - it.uc3m.es · pdf filesoftware design 5. software...

1

1

Communication Software

2009-2010

© The Authors

Introductionto Software Engineering

Authors: Simon PickinMarisol García Valls

Address: Departamento de Ingeniería Telemática Universidad Carlos III de MadridSpain

Version: 1.0

2


2009-2010

© The Authors

Index

1. Overview / definition of terms

2. Lifecycle models

3. Requirements capture, analysis and specification

4. Software design

5. Software quality

6. Software testing

7. Some recent developments

2

3


2009-2010

© The Authors

1. Overview / definition of terms

4


2009-2010

© The Authors

What is Software Engineering? (1/4)

• The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines

F.L. Bauer. Software Engineering.Information Processing 71., 1972

3

5


2009-2010

© The Authors


• Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates

R. Fairley. Software Engineering Concepts. McGraw-Hill (New York), 1985.

6


2009-2010

© The Authors


• Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)

IEEE Std 610-1990

4

7


2009-2010

© The Authors


• Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.

SEI Report on Undergraduate Software Engineering Education, 1990.

8


2009-2010

© The Authors

What is not Software Engineering? (1/2)

• Computer science– concerned with theory and fundamentals– software engineering concerned with practicalities

of developing and delivering useful software.

– still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering).

Software Engineering,Sommerville

5

9


2009-2010

© The Authors

What is not Software Engineering? (2/2)

• System engineering– concerned with all aspects of computer-based

systems development including hardware, software and process engineering

– software engineering is the part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

– system engineers involved in system specification, architectural design, integration and deployment.

Software Engineering,Sommerville

10


2009-2010

© The Authors

Why Software Engineering (1/4)?

• Term “software engineering” popularised in the late 1960s

• Response to the so-called “software crisis”

– hardware performance was increasing much faster than software performance.

– large software system development was unsatisfactory; major projects:

• were usually delivered late (sometimes very late)

• usually went over-budget (sometimes massively over-budget)

• gave rise to unreliable products that were difficult to maintain

6

11


2009-2010

© The Authors


• Techniques used for “single-developer”software do not scale up.

– large projects require a team

– quality of communication between members a serious problem → documentation

• Desire to benefit from previous experience

• Need to plan for maintenance and evolution

– important design decisions must be documented

12


2009-2010

© The Authors


• Communication with the client/user is of paramount importance

– understand the client requirements

– e.g. Xtreme programming: client represented on development team

7

13


2009-2010

© The Authors


• Need to estimate how much effort, time and money needed

– based mainly on modelling of current project & comparison to previous projects

– do we want the job? how much to charge?

– c.f. Constructive Cost Model COCOMOConstructive Systems Engineering Cost Model COSYSMO

– c.f. The mythical man month, Brooks, 1975:adding manpower to a late software project makes it later

14


2009-2010

© The Authors

What is a software development process?

• Process:A series of actions or operations conducing to an end (Websters)

• Software development processThe set of activities, methods and practices used in the production and evolution of software.

8

15


2009-2010

© The Authors

What is a software development process?

• A software development process can include– a lifecycle model

• dividing the development into phases and prescribing the activities to be carried out in each phase

• providing criteria to determine when each development phase has terminated

• defining the deliverables / artifacts / products of each phase

– consideration of tools and equipment

– consideration of personnel and their organisation

– constraints on activities, artifacts, tools, personnel, etc.

• For many authors:Software Development Process = Software Life-Cycle

16


2009-2010

© The Authors

What is a software life-cycle?

• The period of time that starts when a software is conceived and ends when the product is no longer available for use.

• The software life-cycle typically includes a requirements phase, design phase, implementation phase, test phase, installation and check-out phase, operation and maintenance phase, and sometimes, retirement phase.

• A Software Lifecycle Model is a particular abstraction that represents a Software Life Cycle. A Software Life Cycle model is often called a Software Development Life Cycle (SDLC).

IEEE Standard Glossary of Soft. Eng. Terminology

9

17


2009-2010

© The Authors

Software (& Hardware) Modelling

• Sceptic’s view of Software Models:

“bubbles and arrows, as opposed to programs,never crash” Bertrand Meyer 1997

• The use of models is as old as engineering– before building the real thing, engineers build models and

learn from them

• Some desirable characteristics of a model– abstract

– understandable

– accurate

– predictive

– inexpensive to build

18


2009-2010

© The Authors

Modelling: The Purpose of Models

• To help us understand a complex problem by analysis and simulation

• To enable the investigation and comparison of alternative solutions

• To facilitate the communication of ideas about a problem or a solution

• To enable the detection of errors and omissions during the design

• To drive the implementation– software peculiarity:

the model becomes the implementation

10

19


2009-2010

© The Authors

2. Life cycle Models

20


2009-2010

© The Authors

The Software Development Process

Development Operation and Maintenance

System analysis

User requirements

Software system

11

21


2009-2010

© The Authors

Waterfall Life Cycle Model (1/2)

Requirementsanalysis


DesignDesign

Implementation and unit testingImplementation and unit testing

Integration and system testing

Integration and system testing

Operationand maintenance


22


2009-2010

© The Authors

Waterfall Life Cycle Model (2/2)



DesignDesign

Implementationand unit testingImplementationand unit testing

Integration andsystem testingIntegration andsystem testing



Specification of software system

Design of architecture and components

Implemented components

Integrated system

12

23


2009-2010

© The Authors

V Life Cycle Model

Requirementscapture

Requirementscapture



Architecturaldesign

Architecturaldesign

Componentdesign

Componentdesign

Componentcoding

Componentcoding

Unittesting

Unittesting

SubsystemintegrationSubsystemintegration

Systemintegration

Systemintegration

Acceptancetesting

Acceptancetesting

Operation andMaintenance

Operation andMaintenance

Real world

validation

System

verification

Subsystems

verification

Components

verification

24


2009-2010

© The Authors

Incremental Life Cycle Model

• Planning of whole system and the different iterations is done at the beginning

• Development & delivery broken down into increments– each increment delivers part of the required functionality

• User requirements prioritised– highest priority included in early increments

• Requirements for an increment whose development has started are frozen– requirements for later increments can continue to evolve.

• Prototyping :– each iteration can be treated as a prototype

13

25


2009-2010

© The Authors

Evolutionary Life Cycle Model

• No initial planning of whole system and different iterations– final system evolves from initial outline specification

• Start with well-understood requirements and add new features as proposed by the customer on last iteration

• Objective of each iteration is to understand the system requirements

• Prototyping :– each iteration can be treated as a prototype

26


2009-2010

© The Authors

Spiral Life Cycle Model (generalised)

Determine:objectivesalternativesconstraints

Evaluate alternatives

Identify and resolve risks

Plan next phaseDevelop next level product and process

Verify / validate product and process

Cost

Progress

14

27


2009-2010

© The Authors

Spiral Life Cycle Model (original version)

Source: A Spiral Model of Software Development and EnhancementBarry Boehm, IEEE Computer, May 1988

28


2009-2010

© The Authors

3. Capture, Analysis and Specificationof Requirements

15

29


2009-2010

© The Authors

Requirements Engineering

Systematic use of well-established principles, techniques, languages and tools to obtain the cost-effective analysis and documentation of continually-evolving user needs and the specification of the external behaviour of a system that satisfies these needs.

Donald Reifer (see Pressman)

The task of capturing, structuring and accurately representing the user’s requirements so that they can be correctly embodied in systems which meet those requirements.

FOLDOC (http://foldoc.org/)

30


2009-2010

© The Authors

Context of the Analysis Phase

Requirementscapture /

development

Softwaredesign


(andspecification)

whatwhatwhatwhat

howhowhowhow

Usual definition:requirements engineering = requirements capture, analysis and specification

Some authors:requirements engineering = requirements analysis ⊂ requirements capture and specification

16

31


2009-2010

© The Authors

Structured Analysis

datadictionary

entity-relation diagrams

state-transition diagrams

data-flow diagrams

data

des

crip

tion

functional description

control description

32


2009-2010

© The Authors

OO Analysis

• Based on objects and their operations/attributes instead of on data flows

• Currently most commonly-used notation: UML– structural models (class model, component model,…)

– behavioural models (use-cases, state model, collaborations, interactions,…)

• Structural models– via domain analysis

• Behavioural models– use-case modelling is favoured technique

– other behavioural models can be problematic• refinement of analysis model to design model?

17

33


2009-2010

© The Authors

4. Software Design

34


2009-2010

© The Authors

Brief Historical Notes (1/2)

• Late 1960s: control oriented design (Structured Programming)– modularity

– single-entry, single-exit program constructs (sequence, selection, iteration)

– no use of “go to” construct (but what about exception handling?) :

“Goto Statement Considered Harmful”, Dijkstra, Comm. ACM, 1969

18

35


2009-2010

© The Authors

Brief Historical Notes (2/2)

• 1970s: data-structure oriented design (extension of Structured Programming)– program code structure reflects data structure

e.g. Jackson Structured Programming

• 1980s: object-oriented design– unifies data-structure oriented and control oriented

design (or does it?)

– currently most commonly-used notation: UML

36


2009-2010

© The Authors

What is software architecture?

• The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems

19

37


2009-2010

© The Authors

Software Architectures

SystemSystem

SubsystemSubsystem

Component

Module

DataData FunctionsFunctions

top-downdesign

bottom-updesign

DeploymentUnit (not only!)

Compilationunit

38


2009-2010

© The Authors

Software Architecture Essentials

• Components and subsystems– what are the individual elements

• Connections– how components communicate

• Topology– how components and connections are organised

• Constraints– restrictions on components, connections,

topology, evolution,…

20

39


2009-2010

© The Authors

Software Architectural Styles

• Restrict the way in which components can be connected

• Promote fundamental principles– separation of concerns, generality, incrementality,

low coupling, high cohesion,…

• Based on success stories– also chosen in function of application type

• Examples:– pipe-and-filter, layers, software bus, client-server,

peer-to-peer, hierarchical, centralised control, 3-tier client-server, etc.

40


2009-2010

© The Authors

Typical Design Process

Design model: architecture

Detaileddesign

Detaileddesign

Architecturaldesign

Architecturaldesign

Specification of software requirements

Design model: components

· Subsystems

· Interfaces

· Interactions

· Control

· Components

· Interfaces

· Modules

· Data

· Procedures

· Algorithms

21

41


2009-2010

© The Authors

Some Basic Design Concepts

• Abstraction– emphasis on important details, omitting characteristics that

are not relevant in the context

• Refinement– the process of gradually adding more detail, going from

more abstract models to more concrete models

• Modularity– decomposition into components that are to be integrated to

satisfy the problem requirements

• Information hiding– ensuring components only make available such information

as is needed by other components(interfaces do not show design/implementation details)

42


2009-2010

© The Authors

5. Software Quality

22

43


2009-2010

© The Authors

Some Design Quality Factors (1/2)

• External criteria (user point of view)– Correctness

– Reliability

– Usability / user-friendliness

– Good performance

– Robustness

• Internal criteria (developer point of view)– Efficiency

– Maintainability

– Reusability

– Portability

– Interoperability

44


2009-2010

© The Authors

Some Design Quality Factors (2/2)

• From the maintenance and reuse perspective

– Functional independence of components• High intra-component cohesion• Low inter-component coupling

– Readability / understandability• Naming scheme• Complete and up-to-date documentation• Simplicity / Elegance

– Adaptability• Evolvability and generality• Automation of access to documentation• Automation of version control

23

45


2009-2010

© The Authors

Quality Assurance /Software Quality Control (1/2)

• Involves activities performed throughout the software life cycle

• Definition of verification (after IEEE):– ensure a software system, or a model of it, meets a specification

(often produced in a previous development phase)

– concerned with internal consistency

– “are we building the system right?”

• Definition of validation (after IEEE):– ensure a software system, or a model of it, meets the requirements

(customer’s intent)

– concerned with external consistency

– “are we building the right system?”

• Software Testing– usually considered validation but can also be verification

• Software Metrics

46


2009-2010

© The Authors

Quality Assurance /Software Quality Control (2/2)

Source: Object-oriented Software Engineering.Steven Schach. McGraw-Hill.

24

47


2009-2010

© The Authors

Formal Methods (1/2)

• Formal semantics : semantics based on set theory, algebra, logic, automata, graph theory, etc.

• Formal specification : an abstract description with a formal semantics; specification styles:– model-oriented– property-oriented

• Formal method : a method used in software/hardware development involving use and manipulation of formal specifications:– proving properties on formal specifications

– deriving implementations, or other software artifacts (e.g. testcases), from formal specifications

– proving properties on implementations by using an abstract interpretation of the code

– …

48


2009-2010

© The Authors

Formal Methods (2/2)

• Especially important for safety-critical systems, e.g.:– aircraft, trains, metro– power grid, power stations– telecom networks– ...

• Also for secure systems

• May also be worthwhile for low-cost but massively produced systems

• Often introduced after serious problem occurs, e.g.:– model-checking at Intel after Pentium floating point division

error discovered

25

49


2009-2010

© The Authors

Formal Methods for Quality Assurance (1/2)

• Increase understanding of the system modelled

• Automate common software development activities– code generation

– test generation / test synthesis

– …

• Analysis/simulation of models from early phases of software development:– early consistency checking

– early detection of errors, omissions, ambiguities, undesirable properties,…

50


2009-2010

© The Authors

Formal Methods for Quality Assurance (2/2)

• Analyse implementations– detection of errors, omissions, ambiguities, undesirable

properties,…

• Model transformation & consistency checking between models:– at different levels of abstraction

– from different development phases

26

51


2009-2010

© The Authors

6. Software Testing

52


2009-2010

© The Authors

Overview

• The execution of the software implementation in a controlled fashion using carefully chosen input data and the observation of the result.

• Software testing is one aspect of Software Quality Assurance (SQA)

27

53


2009-2010

© The Authors

Definition of a test case

• A specification of an interaction– between the Implementation Under Test (IUT) and the test

software, or human user (playing the role of the IUT environment),

– in which the latter stimulates the IUT via its interfaces, observes its behaviour and its responses

– and, if it includes a test oracle, assigns a verdict to the result of this interaction.

• A test case is designed to exercise a particular execution or verify compliance with a specific requirement.

54


2009-2010

© The Authors

Software Testing: True or False (1/3)

• The effort that must be dedicated to testing is under-estimated by most software developers.� undoubtedly; developers tend to think in terms of lines of code per

day

• Testing must always be carried out by people from a different team to the development team.

not all testing always (e.g. unit testing), but some testing always

• No testing can be carried out until the implementation of the whole application is available.

e.g. unit testing

• Testing is more of a craft than a science.� experience of the test personnel is often crucial

• No test cases can be written before the code to be tested is available.

not always (e.g. unit testing with JUnit)

28

55


2009-2010

© The Authors


• The ultimate goal of testing is to demonstrate that the softwarebeing developed is error-free.

impossible to do with testing

• After fixing errors found in the testing phase the software being developed should be re-tested.� the errors may not have been fixed and the attempt to fix them

(successful or not) may have introduced new errors

• The testing phase of a typical software development life cycle terminates when the software being developed contains no more errors.

one can never be sure of this

• If a module from a well-tested software product is re-used in another product from the same product line, it does not need re-testing.

e.g. Ariane 5

56


2009-2010

© The Authors


• Testing activities can be easily automated.this is precisely why it is still more of a craft than a science

• All errors found in testing of a software product under development should be fixed before the product is released.

Always a compromise between severity of the error and cost of fixing it

• Automatic test generation has the potential to produce huge productivity gains� automation is difficult but very desirable

• When software is modified, the test cases that were used on the previous version should be executed on the modified version.� this is regression testing; new test cases may also be necessary,

of course

29

57


2009-2010

© The Authors

Basic Software Testing Notions (1/2)

• The goal of testing is to find errors NOT to prove their absence– a successful test finds an error

– no amount of testing can guarantee an error-free program

• Should test that the application– does what it is supposed to do

– does not do what it is not supposed to (as far as possible).

• Testing approaches (sometimes term “grey box” is also used)– black box testing

– white box testing (structural testing)

• Testing phases– unit testing

– integration testing

– system testing

58


2009-2010

© The Authors

Basic Software Testing Notions (2/2)

• Test coverage– white box: segments, branches, conditions, loops,…

– black box: requirements

• Test data selection (mainly for black box)– equivalence partition (uniformity hypothesis)

– boundary value analysis

• Other types of testing– acceptance testing

– performance testing

– robustness testing

– stress testing

– interoperability testing

– regression testing– mutation testing

30

59


2009-2010

© The Authors

7. Some recent developments

60


2009-2010

© The Authors

Some Recent Developments (1/3)

• Design patterns– general, repeatable solution to a commonly-occurring

problem in software design

– inspiration in architecture, esp. work of Christopher Alexander

– insufficient theoretical foundation?

• Software frameworks:– a reusable design for a software system or subsystem

(architectural pattern?)

• Software product lines– software development process for a set of related products

– generally use software frameworks

31

61


2009-2010

© The Authors


• Lightweight development (in response to software & documentation “bloat”):– extreme programming, Scrum, etc.

– agile modelling

• Model driven development– primary artifacts are models rather than programs (⇒ code

generation)

– OMG’s MDA initiative (PIMs and PSMs)

– design refactoring

• Service-oriented architecture (SOA)– architectural style whose goal is to achieve loose coupling

among interacting software agents playing producer or consumer roles

62


2009-2010

© The Authors


• Component Based Software Engineering– system assembled (at least partially) from existing cmpnts.

• Open Source Software Engineering– collaboration between often large numbers of spatially-

separated developers

– novel management and organisational structure

– heterogeneity in use of tools, approaches etc.

– study of relation to traditional S.E. on-going

• Web Engineering (development of Web applications)– currently very popular types of applications

– are there particular development characteristics or is it just “hype”?

introduction to software engineering - it.uc3m.es · pdf filesoftware design 5. software...

Documents