Upload
vankhanh
View
229
Download
1
Embed Size (px)
Citation preview
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)
• To be provided in class
F.L. Bauer. Software Engineering.Information Processing 71., 1972
3
5
Communication Software
2009-2010
© The Authors
What is Software Engineering? (2/4)
• To be provided in class
R. Fairley. Software Engineering Concepts. McGraw-Hill (New York), 1985.
6
Communication Software
2009-2010
© The Authors
What is Software Engineering? (3/4)
• To be provided in class
IEEE Std 610-1990
4
7
Communication Software
2009-2010
© The Authors
What is Software Engineering? (4/4)
• To be provided in class
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)?
• To be provided in class
6
11
Communication Software
2009-2010
© The Authors
Why Software Engineering (2/4)?
• To be provided in class
12
Communication Software
2009-2010
© The Authors
Why Software Engineering (3/4)?
• To be provided in class
7
13
Communication Software
2009-2010
© The Authors
Why Software Engineering (4/4)?
• To be provided in class
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 investigate and compare alternative solutions
• To communicate ideas about a problem or a solution
• To detect errors and omissions in 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?
• To be provided in class
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)
– 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)
– 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.– 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. test
cases), 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
– …
• Analyse implementations– detection of errors, omissions, ambiguities, undesirable
properties,…
50
Communication Software
2009-2010
© The Authors
Formal Methods for Quality Assurance (2/2)
• Analysis/simulation of models from early phases of software development:– early consistency checking
– early 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
• Software testing involves executing the software implementation in a controlled fashion using carefully chosen input data and observing 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.
– answer to be provided in class
• Testing must always be carried out by people from a different team to the development team.
– answer to be provided in class
• No testing can be carried out until the implementation of the whole application is available.
– answer to be provided in class
• Testing is more of a craft than a science.
– answer to be provided in class
• No test cases can be written before the code to be tested is available.
– answer to be provided in class
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.
– answer to be provided in class
• After fixing errors found in the testing phase the software being developed should be re-tested.
– answer to be provided in class
• The testing phase of a typical software development life cycle terminates when the software being developed contains no more errors.
– answer to be provided in class
• 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.
– answer to be provided in class
56
Communication Software
2009-2010
© The Authors
Software Testing: True or False (3/3)
• Testing activities can be easily automated.
– answer to be provided in class
• All errors found in testing of a software product under development should be fixed before the product is released.
– answer to be provided in class
• Automatic test generation has the potential to produce huge productivity gains
– answer to be provided in class
• When software is modified, the test cases that were used on the previous version should be executed on the modified version.
– answer to be provided in class
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 application / Web services development– currently very popular types of applications
– are there particular development characteristics or is it just “hype”?