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
Communication Software
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
Communication Software
2009-2010
© The Authors
1. Overview / definition of terms
4
Communication Software
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
Communication Software
2009-2010
© The Authors
What is Software Engineering? (2/4)
• 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
Communication Software
2009-2010
© The Authors
What is Software Engineering? (3/4)
• 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
Communication Software
2009-2010
© The Authors
What is Software Engineering? (4/4)
• 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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
Why Software Engineering (2/4)?
• 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
Communication Software
2009-2010
© The Authors
Why Software Engineering (3/4)?
• Communication with the client/user is of paramount importance
– understand the client requirements
– e.g. Xtreme programming: client represented on development team
7
13
Communication Software
2009-2010
© The Authors
Why Software Engineering (4/4)?
• 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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
2. Life cycle Models
20
Communication Software
2009-2010
© The Authors
The Software Development Process
Development Operation and Maintenance
System analysis
User requirements
Software system
11
21
Communication Software
2009-2010
© The Authors
Waterfall Life Cycle Model (1/2)
Requirementsanalysis
Requirementsanalysis
DesignDesign
Implementation and unit testingImplementation and unit testing
Integration and system testing
Integration and system testing
Operationand maintenance
Operationand maintenance
22
Communication Software
2009-2010
© The Authors
Waterfall Life Cycle Model (2/2)
Requirementsanalysis
Requirementsanalysis
DesignDesign
Implementationand unit testingImplementationand unit testing
Integration andsystem testingIntegration andsystem testing
Operationand maintenance
Operationand maintenance
Specification of software system
Design of architecture and components
Implemented components
Integrated system
12
23
Communication Software
2009-2010
© The Authors
V Life Cycle Model
Requirementscapture
Requirementscapture
Requirementsanalysis
Requirementsanalysis
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
3. Capture, Analysis and Specificationof Requirements
15
29
Communication Software
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
Communication Software
2009-2010
© The Authors
Context of the Analysis Phase
Requirementscapture /
development
Softwaredesign
Requirementsanalysis
(andspecification)
whatwhatwhatwhat
howhowhowhow
Usual definition:requirements engineering = requirements capture, analysis and specification
Some authors:requirements engineering = requirements analysis ⊂ requirements capture and specification
16
31
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
4. Software Design
34
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
Software Architectures
SystemSystem
SubsystemSubsystem
Component
Module
DataData FunctionsFunctions
top-downdesign
bottom-updesign
DeploymentUnit (not only!)
Compilationunit
38
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
5. Software Quality
22
43
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
Quality Assurance /Software Quality Control (2/2)
Source: Object-oriented Software Engineering.Steven Schach. McGraw-Hill.
24
47
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
6. Software Testing
52
Communication Software
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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
Software Testing: True or False (2/3)
• 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
Communication Software
2009-2010
© The Authors
Software Testing: True or False (3/3)
• 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
Communication Software
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
Communication Software
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
Communication Software
2009-2010
© The Authors
7. Some recent developments
60
Communication Software
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
Communication Software
2009-2010
© The Authors
Some Recent Developments (2/3)
• 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
Communication Software
2009-2010
© The Authors
Some Recent Developments (3/3)
• 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”?