Software Engineering HT06
Annabella [email protected]
http://www.cs.umu.se/~bella
http://www.cs.umu.se/kurser/TDBB12/HT06/
PVK--Ht06 2
Course Organisation
Lecture part o Traditional lectureso 1 guest lectureo 3 group exerciseso 2 assignments o Written examination
Project parto Teamwork
• Prototype developmento Team meetingso Oral presentation of
resultso Written reports
Examination: Assignments + Exam+ Project
PVK--Ht06 3
ContentsL1: Introduction L2: Requirements engineering L3: Project management L4: Software design L5: Detailed design and coding L6: Verification and Validation L7: Maintenance Guest Lecture: Product line engineering (?)
PVK--Ht06 4
Introduction
What is software engineeringSoftware development processesSoftware qualityApproaches to improve quality
PVK--Ht06 5
Ariane 5 Failure (in ’96 and ’02)
Inertial Reference computer (SRI-1) tried to convert 64-bit float value to 16-bit signed integer. Value too large, raised exception. SRI-1 computer shut down. Redundant SRI-2 computer performed same conversion, produced same exception. SRI-2 sent bad data to flight control computer, which then put the launcher into an unstable flight trajectory. Result: Self-destruct mechanism was activated. Failure Cause: improperly constrained computation. http://news.bbc.co.uk/2/hi/science/nature/2565387.stmhttp://www.esa.int/export/esaCP/ESACVS7708D_index_0.html
PVK--Ht06 6
What is Software Engineering?“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” Definition proposed by Fritz Bauer
at the NATO conference ‘68 in Garmisch [NRB 76]
COMPUTERSCIENCE
SOFTWAREENGINEERING
CUSTOMER
Theories
Tools andTechniques toSolve Problem
ProblemComputerFunctions
ENGINEERINGPRINCIPLES
ProvenTechniques
PVK--Ht06 7
Elements of Software Engineering
Languages
Technical “how tos” to support software development tasks
Notations to support methods
(Semi-) automated support for (the usage of) methods and languages
Coordination and management of software development tasks supported by methods, languages, and tools
Tools
Processes
Methods
Economically produce quality software
PVK--Ht06 8
Software processes
A structured set of activities required to develop a software systemo Specification;o Design;o Validation;o Evolution.
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.
PVK--Ht06 9
The Waterfall Model
AnalysisDesign
Testing
Coding
Operation and
Maintenance
Installation
Require-ments
Requirements
Specification
Planning
PVK--Ht06 10
PLAN DEVELOP AND TEST
DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS
EVALUATE ALTERNATIVES
AND RISKS
Requirements,life-cycle plan
Budget1
Alternatives1
Constraints1
Riskanalysis1
Risk analysis2
Risk analysis3
Risk analysis4
Constraints2
Constraints3
Constraints4
Budget2Budget3Budget4
Altern
ativ
es2
Altern
ative
s 3
Altern
ative
s 4
Prototype1
Proto-type2
Proto-type3
Proto-type4
Conceptof operation
Softwar
e
requ
irem
en
tsValidated
requirements
DevelopmentplanIntegrationand test plan
Softwar
e
design
Validated,
verified design
Detaileddesign
Code
Unit test
SystemtestAcceptance
test
The Spiral Model
start
Plan next phase
Simulations, models
PVK--Ht06 11
Waterfall vs. Spiral Model
Model ComplexitySimple, linearsequence of phases
Complex, iterative model;many integrated tasks
Management Document driven Risk driven
Quality Control Natural milestoneafter each phase
Continuous evaluation,integrated into the model
Customerinteraction No Prototypes are built and
evaluated by customers in every iteration
Risk High (late feedback) Low (risk analysis isintegrated in the model)
Usability Small and/or lowrisk projects
Large projects
Waterfall Model Spiral Model
PVK--Ht06 12
Incremental and Iterative Processes
ProjectManagement
QualityAssurance
Reuse Documentation
Maintenance Version- and Confi-guration Control
RequirementsEngineering
Design
Implemen-tation
RequirementsEngineering
Design
Implemen-tation
RequirementsEngineering
Design
Implemen-tation
Iterations
PVK--Ht06 13
Rational Unified Process
RUP is a method of managing OO Software DevelopmentIt can be viewed as a Software Development Framework which is extensible and features:o Iterative Developmento Requirements Managemento Component-Based Architectural Visiono Visual Modelling of Systemso Quality Managemento Change Control Management
PVK--Ht06 14
RupO
rgan
i sat i
on
al o
ng
con
t ext
PVK--Ht06 15
Agile processes
Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:o Focus on the code rather than the design;o Are based on an iterative approach to software
development;o Are intended to deliver working software quickly
and evolve this quickly to meet changing requirements.
Agile methods are probably best suited to small/medium-sized business systems or PC products.
PVK--Ht06 16
eXtreme Programming project
PVK--Ht06 18
Rules and Practices of Extreme Programming
The Customer is Always Available
Coding Standards
Code the Unit Test First
Pair Programming
Sequential Integration
Integrate Often
Collective Code Ownership
Optimise Last
No Overtime
Unit Tests
Acceptance Tests
User Stories
Release Plan
Make frequent small releases
Iterative Development
iteration Planning
Move People Around
Daily Stand Up Meeting
Simplicity is the Key
CRC Cards
Create a Spike Solution
Never Add Functionality Early
PVK--Ht06 19
Component-based software engineering
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.Process stageso Component analysis;o Requirements modification;o System design with reuse;o Development and integration.
This approach is becoming increasingly used as component standards have emerged.
PVK--Ht06 20
Relative Costs of Development Phases1%
6%
5%
7%
8%
4%
67%
2%Requirements
Specification
Planning
Design
Coding
Testing
Integration
MaintenanceCompiled data from 1976-1981, see [Schach 97].
PVK--Ht06 21
Relative Costs of an Error
1 2 3 4 1030
200
1 2 3 4 10
52
368
0
50
100
150
200
250
300
350
400
Requ
iremen
ts
Analys
Plan
ning
Design
Implem
enta
tion
Inte
grat
ion
Maint
enan
ce
Studies from 1974-1980
IBM AS/400 [94]
See [Schach 97].
PVK--Ht06 22
Fault vs Failure
?!human error fault failure
can lead to can lead to
PVK--Ht06 23
Causes of Errors12%8%
6%
14%
34%
4%22%
Incorrect or misunderstoodrequirementsIncorrect or misunderstoodspecificationsDesign faultinvolvingseveral componentsDesign- or code fault in onecomponentSpelling mistake or similar
Fault correction
Other reasons
Study from 1978, see [GoRu 95].
PVK--Ht06 24
Introduction
What is Software Engineering Software Development Processes Software QualityApproaches to Improve Quality
PVK--Ht06 25
Quality is ...
… I know it when I see it… it suits the client/user … it conforms to the specification… it has some inherent quality… it depends on the price
PVK--Ht06 26
And Quality is …
Efficiency
Reliability
Easy to learn
Functionality
Flexibility
Increased productivity
Low costs
Easy to use
Readable codeGood design
Good documentation
Few errors
SponsorUser
Maintainer/modifier
Short time of delivery Easy to remember
PVK--Ht06 27
Quality Factors
(ISO 9126)
Functionality
Replaceability
Suitability
Accuracy
InteroperabilitySecurity
Maturity
Fault toleranceRecoverabilityUnderstandabilityLearnability
Operability
Time behaviorResource behaviorAnalyzability
ChangeabilityStability
Testability
Adaptability
Installability
Conformance
Reliability
Efficiency
Usability
Maintainability
Portability
PVK--Ht06 28
How Companies Pursue Software Quality
4%24%
20%
9%
42%
1%
None
Slogans
Improved testing
Focus on prevention
Process improvement
Other
A survey from the CASE Research Corporation (1990), see [Yourdon 92].
PVK--Ht06 29
How To Measure Quality?Quality Factor
Property/Criteria
Property/Criteria
Property/Criteria
Metric MetricMetric
depends on
Efficiency
SpeedSize
Response timeLOC...
determined by
Metrics are (objective) measurements to determine (subjective) quality factors
PVK--Ht06 30
Some Example MetricsTo measure efficiencyo Time behaviour
• Transactions per second
• Response time• Screen refresh time
o Resource behaviour• KBytes of executables• LOC• Number of processors
To measure usabilityo Training timeo Number of help frames
To measure reliabilityo MTTF (Mean Time To
Failure)o Availability
To measure robustnesso Time to restart after a
failureo Probability of data
corruption on failureTo measure portabilityo Number of target systemso Percentage of target
dependent statements
Measurement is necessary
PVK--Ht06 31
Purpose of MeasurementAnalysis: Determine current quality Prediction: Predict future quality
Not only code can be measured, but also
o Products• Documentation• Design
oProcesses•Analysis phase•Test phase
oResources•Personnel•Budget
PVK--Ht06 32
Approaches to Improve Quality
Capability Maturity Model Integrated (CMM)Personal Software Process (PSP)InspectionsStandards (ISO9000, ...)Cleanroom engineeringStatistical quality controlGoal Question Metrics (GQM)…..
PVK--Ht06 33
The CMMI model
Developed by SEI for the DoD (Cmm in 1986, Cmmi in 2001) An integrated capability model that includes software and systems engineering capability assessment.The model has two instantiationso Staged where the model is expressed in terms
of capability levels;o Continuous where a capability rating is
computed.
PVK--Ht06 34
The staged CMMI model
Level 3Defined
Level 2Managed
Level 1Initial
Level 4Quantitatively
managed
Level 5Optimizing
PVK--Ht06 35
The continuous CMMI model
This is a finer-grain model that considers individual or groups of practices and assesses their use.The maturity assessment is not a single value but is a set of values showing the organisations maturity in each area.The CMMI rates each process area from levels 1 to 5.The advantage of a continuous approach is that organisations can pick and choose process areas to improve according to their local needs.
PVK--Ht06 36
CMM Results
Model predictions for the development of a 200.000 LOC data processing product (1993), see [Schach 97].
CMMlevel
1
2
3
4
5
Developmenttime
29,8
18,5
15,2
12,5
9,0
Personmonths
593,5
143,0
79,5
42,8
16,0
Faults detectedduring dev.
1.348
328
182
97
37
Faults delivered
and installed
61
12
7
5
1
Total dev. costsin US$
5.440.000
1.311.000
728.000
392.000
146.000
PVK--Ht06 37Source: http://www.sei.cmu.edu/sema/profile.html
CMM Process Maturity Profileof Software Organizations
PVK--Ht06 38
Goal Question Metric
The paradigm helps an organisation to focus on its goals. It consists of three steps:
Specify a set of goals Generate a set of quantifiable questions Define a set of metrics
PVK--Ht06 39
GQM TemplatePurpose: Analyse some (objects: processes, products, other
experience models) for the purpose of (why: characterisation, evaluation,
prediction, motivation, improvement) Perspective: with respect to (focus: cost, correctness, defect removal,
changes, reliability, user friendliness,...) from the point of view of (who: user, customer, manager,
developer, corporation,...) Environment: in the following context (problem factors, people factors,
resource factors, process factors,...)
PVK--Ht06 40
Goal Goal Goal
QuestionQuestion Question
Metric Metric Metric
Goal: Evaluate the reliability of the final software product
Goal: Analyze the final product for the purpose of evaluation with respect to defect classes from the point of view of developer
in the context of company XYZ
Question: What is the defects distribution by phase of entry? How many faults and failures are there in the final product? Metric: Number of Requirements faults, Number of Design faults, MTTF,...
GQM Example
PVK--Ht06 41
CMM and GQM
CMM
Level 2
Level 3
Level 4
Level 5
KPA
KPA
KPA
Goal
Goal
Goal
Question
Question
Question
Metric
Metric
Metric
KPA
Question
Metric
Metric
Metric