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.)
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
but:
„ Knowledge from several sources
„ Two versions of the book this year
„ An auxiliary book in Swedish:
Wohlin: “Introduktion till programvaruutveckling”
Studentlitteratur, ISBN 914402861X, 2005.
„ Web pages
„ Other books and articles
„ It is your job to find the material you like
You will get an overview of concepts, methods,
tools & techniques for the entire Software
Engineering life-cycle. (TDDB62)
2. You will also become prepared to the TDDC02
project course when it comes to the broad picture
and requirements and planning in particular.
(TDDC06)
3. First-hand experience of running a development
project. (TDDB62)
4. Acquaintance with design and coding tools and
database components. (TDDB62)
1.
Make processes, but also components, tools, people,... fit nicely together
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
„ ......
A common theory course,
Kristian Sandahl, IDA
krisa@ida.liu.se
Charette, R.N. (2005) Why Software
Fails, IEEE Spectrum, September 2005
„
Course goals
„
„
Space shuttle
Nike
„ Denver airport
„ Frequent failures:
„
„
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
My view
Kristian Sandahl, IDA
krisa@ida.liu.se
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
1
„ Mail me questions, reflections and solutions
to assignments.
„ Begin the topic with the string “TDDB62:” or
“TDDC06:”
„ Muddy-card evaluation 6 September
„ I’m curious to listen to the students’ union
evaluation
„ Martin Fransson, course assistant, labs,
projects
„ Klas Arvidsson, labs, projects
„ Anne Moe, administrator
Short
Essays
„ JDBC
„ JBuilder
„ CVS
„ Rational Rose
Kristian Sandahl, IDA
krisa@ida.liu.se
„ Tasks:
„ analyze
„ design
„ implement
„ integrate
„ test
„
„
„
„
„
„
„
Kristian Sandahl, IDA
krisa@ida.liu.se
Requirements
specification
Project plan
Design specification
”Test report”
Experience report
Planning seminar
Demonstration seminar
Process audit
Kristian Sandahl, IDA
krisa@ida.liu.se
„ Why not forming a study-group?
„ 18 hours browsing other materials
Kristian Sandahl, IDA
krisa@ida.liu.se
„ 40 hours reading the book of your choice
„ 11 lectures = 22 hours
„ 2p = 80 effective working hours
„ Plan reading
„
„ Delivarables:
„ 2 System groups:
„ 3 component groups
„ 6-8 students
„ Prepare the first 3 labs for the first occasion!
„ Tools:
Advice
Projects (TDDB62)
„ I will go through one of them
„ Last year’s exams will be on the home page
to 3 hand-written pages?
„ What about changing aids from a text-book
2.
1.
„ Two categories of questions:
„ Written
Exam
Labs (TDDB62)
Kristian Sandahl, IDA
krisa@ida.liu.se
„ Be active at lectures
„ Kristian Sandahl, course leader, examiner
Kristian Sandahl, IDA
krisa@ida.liu.se
Communication
Personnel
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
de Facto reference model
„ forward engineering
„ manageable
„ fixed documents
4
4
10
4
Actual
(weeks)
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Replacement
Maintenance
Operation
Installation
Test
Implementation
Design
Requirements
Concept
exploration
Waterfall model
4
Requirements
and planning
Guess
(weeks)
Simple example
k
ac
-b
ed
fe
„
„
„
„
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?
Exercise
Sample documents (contd.)
output
4