de Facto reference model
forward engineering
manageable
fixed documents
Kristian Sandahl, IDA
krisa@ida.liu.se
Replacement
Maintenance
Operation
Installation
Test
Implementation
Design
Requirements
Concept
exploration
Waterfall model
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Charette, R.N. (2005) Why Software
Fails, IEEE Spectrum, September 2005
This course will present you some basic SE-elements
mostly suited for 101-102 people projects.
Kristian Sandahl, IDA
krisa@ida.liu.se
Always ask how does it work?, when does it work?, what can I get?
The rest is like finishing a jigsaw-puzzle.
(The Boeing 777-200 has about 1400 data processing units
and 5 million lines of code.)
Make processes, but also components, tools, people,... fit nicely together
My view
Space shuttle
Nike
Denver airport
Frequent failures:
high quality
high complexity
delivered promptly
low price
Increased demands for software with:
Application of systematic, disciplined, quantifiable
approach to software development, operation and
maintenance of software. (IEEE-Std.)
The term software engineering was used
occasionally in the late 1950s and early 1960s. It was
popularized as a response to the software crisis
during the 1968 NATO Software Engineering
Conference (held in Garmisch, Germany) by its
chairman F.L. Bauer, and has been in widespread
use since.
Why do we need SE?
Software Engineering
k
ac
-b
ed
e
f
Coding
System
testing
Acceptance
testing
Kristian Sandahl, IDA
krisa@ida.liu.se
Downstream
activities
Kristian Sandahl, IDA
krisa@ida.liu.se
Different types of knowledge:
Understanding customers
Understanding users
Managing projects and people
Communication
Staffing
Design at many levels
Programming tools
Components
Testing
Quality assurance
Business
Risk management
Technology assessment
......
Unit and
integration
testing
Quality and process management
Program
design
System
design
Requirements
analysis
V-model
criticality
# users
# developers
# platforms
risk
cost
There will be changes
degrading performance
maintenance account for
70% of life cycle cost
Everyone want the latest
technology
Different types of software:
Challenges to SE
1
evaluation
Kristian Sandahl, IDA
krisa@ida.liu.se
I’m curious to listen to the students’ union
Muddy-card evaluation 28 March
to assignments.
Begin the topic with the string “TDDC01:”
Mail me questions, reflections and solutions
Be active at lectures
Communication
Kristian Sandahl, IDA
krisa@ida.liu.se
Requirements
Planning & Processes
Design & Architechture
Test
Qualityfactors
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Aid: 2 A4 sheets handwritten notes (e.g. 4 pages)
Grade 3: certain credits in each area + a minimal
total credit sum
I will go through a typical exam
Written
Five areas of questions:
Exam
but:
Knowledge from several sources
Two recommended course books
An auxiliary book in Swedish
Web pages
Other books and articles
It is your job to find the material you like
1. You will get an overview of concepts,
methods, tools & techniques for the entire
Software Engineering life-cycle.
2. You will also become prepared to the
TDDC02 project course when it comes to
the broad picture and requirements and
planning in particular.
A common theory course,
Course goals
Kristian Sandahl, IDA
krisa@ida.liu.se
Why not forming a study-group?
30 hours browsing other materials
Kristian Sandahl, IDA
krisa@ida.liu.se
60 hours reading the book of your choice
15 lectures = 30 hours
3p = 120 effective working hours
Plan reading
Advice
Preparations assignments
Home assignments
Discussion seminars
Guest lectures
Traditional
Lectures and assignments
2
replace
use supplementary
written specification
case3
use special tool
use special tool
case2
use PowerPoint
case1
new
use many models
new
use many models
use only models
Kristian Sandahl, IDA
krisa@ida.liu.se
use code generation
use supplementary
written specification
modify
Example: Blocked case-study
Kristian Sandahl, IDA
krisa@ida.liu.se
assessment, weekly measurement (hours,
lines of code)
OK: Write experience reports
Good: Formulate a model, make predictions
(set goals), explain results
Low key: Written reflections, daily
Dilbert: Work, work, work...., try to forget.
Learning from experience
8
4
4
Design and
coding
Testing
Writing report
Argumentation theory
4
Requirements
and planning
Guess
(weeks)
Simple example
4
4
10
4
Actual
(weeks)
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
components? What properties do they have? How do
they interact?
Detailed design description: What functions will be
implemented? Input? Output? Parameters?
Code: Good list of code
Unit test cases: input and expected output per
component
Unit test report: Which test-cases passed/have not
yet pass?
Architectural description: What are the main
needed? Which level of quality is needed?
Requirements specification: What functions are
Sample documents
social science
+ other methods from natural science and
Controlled experiments
Comparative studies
Parallel design
Gradual introduction: students, pilot, full-scale
Higher division
3
Kristian Sandahl, IDA
krisa@ida.liu.se
<<component>>
reader
message
<<component>>
writer
world!”
Kristian Sandahl, IDA
krisa@ida.liu.se
input = “Hi, HAL” ⇔ message is T ⇔ output is “Hello,
input
system, for example:
Create all documents for a trivial 2-component
Integration test planning: In what order will the
components be put together? Test-cases for each
intermediary build.
System test report: Which black-box test-cases
passed/have not yet pass? What was the result of
quality tests?
Acceptance test report: Which acceptance test cases
passed/have not yet passed?
Installation manual: How do I install and run the
system?
User manual: How do I operate the system?
Home assignment1
Sample documents (contd.)
output
4