Download - SECh123
Slide 1
Introduction Text Book: Sommerville (+Pressman) Assessment:
• Project: 30 % (Doc 1: 20 in week 8 + Doc 2: 10 in week 12)• Tutorial participation: 10 %• Examination: 60%• Grades: (no one failed in CP3110 in the last 5 years !!)
• Pass: get at least a total of 50 marks (out of 100). • Credit: total > 65 and Exam > 30 Marks• Distinction: total > 75 and Exam > 39 Marks• High Distinction: total > 85 Marks
Tutorial participation: • Questions released on Friday• Bring your solutions to the tutorial• Participate at least 10 tutorial sessions
Slide 2
from a colleague in Netherlands (1990)
A short story
• Move to a new large house ?• No! Too good a location + sentiments
• House too small• Study room became a child’s bedroom• Wife thought kitchen too small
• Consulted an architect about renovation • Blueprint for large kitchen + 4 new rooms• Attractive and apparently cheaper than moving
• Brother (building industry) warned of the mess• but, thought they can handle it• Applied for permission and got it in 6 months
Slide 3
Short story - cont. In Aug 1991, contract signed for a fixed price
•September: 1 week’s work done in the 1st month•Oct: part of the roof to be removed•Surprise: more to be demolished
•Nov: roof up (lucky, only 2 days rain)•New kitchen to be installed: remove a brick wall•problem: old heating systems right behind the wall•…
•Finished in January •many tiny expenses (unaccounted for) added up to a pretty sum•Lot of trouble (big brother is right again!)
•estimated time: 60 working days (November finish)•extra things: wiring, new central heating•estimated on the back of an envelop
Slide 4
Story is true for many software projects
Software too often delivered late More expensive (time and money both) Does not meet its specifications Faulty Underestimate non-technical factors … The Software Crisis … Want to avoid ?
• Take CP3110 seriously
Slide 5
Software engineering The economies of ALL developed nations are
dependent on software More and more systems are software controlled Software engineering expenditure represents a
significant fraction of GNP in all developed countries Therefore, cost-effective software production is
essential to national & international economies Software engineering is concerned with theories,
methods and tools for professional software development
Slide 6
What is software?
Computer programs and associated documentation Software products may be developed for a
particular customer or may be developed for a general market
Software products may be• Generic - developed to be sold to a range of different customers
• Bespoke (custom) - developed for a single customer according to their specification
Slide 7
What is software engineering?
Software engineering is an engineering discipline which is concerned with all aspects of software production
Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available
Slide 8
What is a software process?
A set of activities whose goal is the development or evolution of software
Generic activities in all software processes are:• Specification • Development• Validation • Evolution
Generic process models• Waterfall• Evolutionary development• Formal transformation• Integration from reusable components
Slide 9
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. For systems with a long life, maintenance costs may be several times development costs
Roughly 60% of costs are development costs, 40% are testing costs.
Distribution of costs depends on the system being developed and the development model used
Software engineering is concerned with cost-effective software development
Software costs
Slide 10
What are the attributes of good software? The software should deliver the required functionality and
performance to the user and should be maintainable, dependable and usable
Maintainability• Software must evolve to meet changing needs
Dependability• Software must be trustworthy
Efficiency• Software should not make wasteful use of system resources
Usability• Software must be usable by the users for which it was designed
Slide 11
Emergent properties
Properties of the system as a whole rather than properties that can be derived from the properties of components of a system
Emergent properties are a consequence of the relationships between system components
They can therefore only be assessed and measured once the components have been integrated into a system
Slide 12
Examples of emergent properties
The overall weight of the system • This is an example of an emergent property that can be computed
from individual component properties.
The reliability of the system • This depends on the reliability of system components and the
relationships between the components.
The usability of a system • This is a complex property which is not simply dependent on the
system hardware and software but also depends on the system operators and the environment where it is used.
Slide 13
Types of emergent property
Functional properties • These appear when all the parts of a system work together to
achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.
Non-functional emergent properties• Examples are reliability, performance, safety, and security. These
relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.
Slide 14
What are the key challenges facing software engineering?
Coping with legacy systems, coping with increasing diversity and coping with demands for reduced delivery times
Legacy systems• Old, valuable systems must be maintained and updated
Heterogeneity• Systems are distributed and include a mix of hardware and
software
Delivery• There is increasing pressure for faster delivery of software
Slide 15
Professional and ethical responsibility
Software engineering involves wider responsibilities than simply the application of technical skills
Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals
Ethical behaviour is more than simply upholding the law.
Slide 16
Issues of professional responsibility
Confidentiality • Engineers should normally respect the confidentiality of their
employers or clients (even if no confidentiality agreement).
Competence • Engineers should not misrepresent their level of competence.
Should not knowingly accept work beyond their competence.
Intellectual property rights • Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc.
Computer misuse • Should not misuse their technical skills (virus).
Slide 17
Code of ethics - principles from IEEE/ACM
1. PUBLIC • Software engineers shall act consistently with the public
interest.
2. CLIENT AND EMPLOYER • Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT • Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
Slide 18
Code of ethics - principles JUDGMENT
• Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT • Software engineering managers and leaders shall
subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION • Software engineers shall advance the integrity and
reputation of the profession consistent with the public interest.
Slide 19
Code of ethics - principles 7. COLLEAGUES
• Software engineers shall be fair to and supportive of their colleagues.
8. SELF • Software engineers shall participate in lifelong learning
regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
Slide 20
Software Myths (from Pressman)
Myth: It’s in the software. So, we can easily change it.• Reality: Requirements changes are a major cause of software
degradation
Myth: We can solve schedule problems by adding more programmers.• Reality: Maybe. It increases coordination efforts and may slow
things down.
Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code.• Reality: Incomplete up-front definition is the major cause of
software project failures.
Slide 21
Software Myths...
Myth: I can’t tell you how well we are doing until I get parts of it running.• Reality: Formal reviews of various types
• can give good information and • are critical to success in large projects.
Myth: The only deliverable that matters is working code.• Reality: Documentation, test history, and program configuration are
critical parts of the delivery.
Myth: I am a (super) programmer. Let me program it, and I will get it done.• Reality: A sign of immaturity. A formula for failure. Software
projects are done by teams, not individuals, and success requires much more than just coding.
Slide 22
Key points Software engineering is an engineering discipline which is
concerned with all aspects of software production.
Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability.
Emergent properties are properties that are characteristic of the system as a whole and not its component parts
The software process consists of activities which are involved in developing software products. Basic activities are software specification, development, validation and evolution.
Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.
Slide 23
10 minute break: a brain teaser
Your are in the cellar of your house. There are three light switches which individually switch on or off three light bulbs in your attic. You may go from your cellar to your attic only once. How can you find out which bulb is connected to which switch?
Initially, all switches are in the "off" position. Further tools or persons are not available. All bulbs are in perfect working order, you cannot see from the cellar to the attic, metaphysical and esoteric phenomena are not permitted.
Slide 24
Solution to the brain teaser switch 1 on wait 5 minutes switch 1 off switch 2 on go to your attic feel: the hot bulb is connected with switch 1 look: the shining bulb is connected with switch 2 conclude: the last bulb is connected with switch 3
First lesson about modeling. If you use the simple model "bulb has 2 states (on/off)" to solve the problem, you forget an additional implicit aspect of the real world ("heat"), which must be taken into consideration.
Slide 25
Ch.3: Software Processes
Coherent sets of activities for specifying, designing, implementing and testing software systems
Chapter Objectives To introduce software process models To describe a number of different process models and when
they may be used To describe outline process models for requirements
engineering, software development, testing and evolution To introduce CASE technology to support software process
activities
Slide 26
The software process A structured set of activities required to develop a
software system• Specification
• Design
• Validation
• Evolution
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective
Slide 27
3.1 Generic software process models The waterfall model
• Separate and distinct phases of specification and development
Evolutionary development• Specification, development and validation are interleaved
Formal systems development• A mathematical system model is formally transformed to an
implementation
Reuse-based development• The system is assembled from existing components
Slide 28
Waterfall modelRequirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Slide 29
Waterfall model problems
The drawback of the waterfall model is the difficulty of accommodating change after the process is underway• Inflexible partitioning of the project into distinct
stages
• This makes it difficult to respond to changing customer requirements
Therefore, this model is only appropriate when the requirements are well-understood
Slide 30
Evolutionary development
Exploratory development Objective is to work with customers and to evolve a final system from an initial
outline specification. Should start with well-understood requirements
Throw-away prototypingObjective is to understand the system requirements. Should start with poorly
understood requirements
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
Concurrentactivities
Slide 31
Evolutionary development Problems (from engineering/management perspective)
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid prototyping) may be required
Applicability• For small or medium-size interactive systems
• For parts of large systems (e.g. the user interface)
• For short-lifetime systems Further discussed in Ch. 8
Slide 32
Formal systems development Based on the transformation of a mathematical
specification through different representations to an executable program
Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification
Embodied in the ‘Cleanroom’ approach to software development
Requirementsdefinition
Formalspecification
Formaltransformation
Integration andsystem testing
Slide 33
Formal transformations
R2Formal
specificationR3
Executableprogram
P2 P3 P4
T1 T2 T3 T4
Proofs of transformation correctness
Formal transformations
R1
P1
Problems• Need for specialised skills and training to apply the technique• Difficult to formally specify some aspects of the system (eg. UI)
Applicability• Safety Critical systems
Slide 34
Reuse-oriented development Based on systematic reuse where systems are
integrated from existing components or COTS (Commercial-off-the-shelf) systems
Process stages• Component analysis
• Requirements modification
• System design with reuse
• Development and integration
This approach is becoming more important but still limited experience with it
Slide 35
Reuse-oriented development Based on systematic reuse where systems are
integrated from existing components or COTS
Requirementsspecification
Componentanalysis
Developmentand integration
System designwith reuse
Requirementsmodification
Systemvalidation
Slide 36
3.2 Process iteration System requirements ALWAYS evolve in the
course of a project so process iteration where earlier stages are reworked is always part of the process for large systems
Iteration can be applied to any of the generic process models
Two (related) approaches• Incremental development
• Spiral development
Slide 37
Incremental development Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with each increment delivering part of the required functionality
User requirements are prioritised and the highest priority requirements are included in early increments
Once the development of an increment is started, the requirements are frozen
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
Slide 38
Incremental development advantages
Customer value can be delivered with each increment so system functionality is available earlier
Early increments act as a prototype to help elicit requirements for later increments
Lower risk of overall project failure The highest priority system services tend to
receive the most testing
Slide 39
Spiral development Process is represented as a spiral rather than as a
sequence of activities with backtracking Each loop in the spiral represents a phase in the
process. No fixed phases such as specification or design -
loops in the spiral are chosen depending on what is required
Risks are explicitly assessed and resolved throughout the process
Slide 40
Spiral model of the software process
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
Slide 41
Spiral model sectors Objective setting
• Specific objectives for the phase are identified
Risk assessment and reduction• Risks are assessed and activities put in place to reduce the key
risks
Development and validation• A development model for the system is chosen which can be any
of the generic models
Planning• The project is reviewed and the next phase of the spiral is
planned
Slide 42
3.3 Software specification The process of establishing what services are required and
the constraints on the system’s operation and development Requirements engineering process (4 steps)
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Slide 43
3.4 Software design and implementation
The process of converting the system specification into an executable system
Software design• Design a software structure that realises the specification
Implementation• Translate this structure into an executable program
The activities of design and implementation are closely related and may be inter-leaved
Slide 44
The software design process
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Slide 45
Design methods Systematic approaches to developing a software
design The design is usually documented as a set of
graphical models Possible models
• Data-flow model
• Entity-relation-attribute model
• Structural model
• Object models
Will be discussed in Ch. 7
Slide 46
Programming and debugging Translating a design into a program and removing
errors from that program Programming is a personal activity - there is no
generic programming process Programmers carry out some program testing to
discover faults in the program and remove these faults in the debugging process
The debugging process
Locateerror
Designerror repair
Repairerror
Re-testprogram
Slide 47
3.5 Software validation Verification and validation is intended to show
that a system conforms to its specification and meets the requirements of the system customer
Involves checking and review processes and system testing
System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system
Slide 48
The testing process
Sub-systemtesting
Moduletesting
Unittesting
Systemtesting
Acceptancetesting
Componenttesting
Integration testing Usertesting
Slide 49
Testing phases
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
Slide 50
3.6 Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances,
the software supporting the business must also evolve and change Although there has been a demarcation between development and
evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new
Assess existingsystems
Define systemrequirements
Propose systemchanges
Modifysystems
Newsystem
Existingsystems
Slide 51
3.7 Automated process support (CASE)
Computer-aided software engineering (CASE) is software to support software development and evolution processes
Activity automation• Graphical editors for system model development
• Data dictionary to manage design entities
• Graphical UI builder for user interface construction
• Debuggers to support program fault finding
• Automated translators to generate new versions of a program Case technology has led to significant improvements in the
software process though not the order of magnitude improvements that were once predicted• Software engineering requires creative thought - not automatable
Slide 52
CASE classification Classification helps us understand the different
types of CASE tools and their support for process activities
Functional perspective• Tools are classified according to their specific function
Process perspective• Tools are classified according to process activities that are
supported
Integration perspective• Tools are classified according to their organisation into
integrated units
Slide 53
Functional tool classification
Activity-based classification
Reengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processingtools
Method support tools
Prototyping tools
Configurationmanagement tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification Design Implementation Verificationand
Validation
Slide 55
CASE integration Tools
• Support individual process tasks such as design consistency checking, text editing, etc.
Workbenches• Support a process phase such as specification or design,
Normally include a number of integrated tools
Environments• Support all or a substantial part of an entire software process.
Normally include several integrated workbenches
Slide 56
Tools, workbenches, environments
Single-methodworkbenches
General-purposeworkbenches
Multi-methodworkbenches
Language-specificworkbenches
Programming TestingAnalysis and
design
Integratedenvironments
Process-centredenvironments
Filecomparators
CompilersEditors
EnvironmentsWorkbenchesTools
CASEtechnology
Slide 57
Key points Software processes are the activities involved in
producing and evolving a software system. They are represented in a software process model
General activities are specification, design and implementation, validation and evolution
Generic process models describe the organisation of software processes
Iterative process models describe the software process as a cycle of activities
Slide 58
Key points Requirements engineering is the process of
developing a software specification Design and implementation processes transform
the specification to an executable program Validation involves checking that the system
meets to its specification and user needs Evolution is concerned with modifying the system
after it is in use CASE technology supports software process
activities