Software Engineering
DD1363 MVK-08
Karl Meinke
NADA
karlm@nada.kth.se
Overview of Course
Aim: To introduce students to the theory and
practise of software engineering.
Activities:
• formal lectures,
• invited industrial speakers,
• a group project (10-12 students – 6 points)
• an individual term paper (1 student – 6 points)
2
Overview (cont)
Assessment: individuals will be assessed by
weighting the grades awarded for:
• the group project and
• the term paper.
There is no formal examination .
3
Software Engineering Theory
We will organise our study of theory around the
Waterfall lifecycle model
This will support and guide your project work
4
User Requirements
Business Process Modeling
UML
System Modeling
Software Requirements
Architectures &
Patterns
Architecture Design
Detailed design & Coding
The Waterfall
Lifecycle Workflow
Testing
You know this!
Software QA
Delivery
Time
5
Theory
• We will consider other theoretical subjects
such as:
• Lifecycle models
• Managing project risk
• Project management
6
Term Paper (6 points)
• An original, in-depth exploration of some current topic in SE.
• Topic must be software-engineering-related
• e.g.: project management, software lifecycle models, software
development environments and tools, requirements capture,
verification and validation, testing, programming language design,
future programming languages, platforms or architectures,
emerging standards, project failures, risk management etc etc.
• particular merit if oriented towards the state of the art and/or
current research.
• main purpose is to assign a course grade to each student that is
based on their own individual work effort. The term paper is not a
collaborative exercise!
• You may write your term paper in Swedish or English.
7
Term Paper (cont)
• The term paper assignment has 2 components:
initial abstract and final submission.
• You must avoid writing on the same subject as
someone else on the course.
8
Initial Abstract
• You have three weeks to choose a subject and
write an initial abstract in a 1-page singlespaced document.
• abstract must convince the course leader that
your subject matter is suitable for a term
paper
• Provide at least 4 references that give a
context for the theme of the paper
9
Final Submission
• 7 pages double-spaced (excluding references)
• A survey of your chosen subject, not a new
research contribution
• Completeness is more important than
originality
• Reflects your level of understanding and your
command of the literature well
• Individual effort – no collaboration or
plagiarism!
10
Group Project (6 points)
• The practical work for the course will consist
of group project work (10-12 students)
• Carry out a substantial design,
implementation and test of a "large" system
according to course theory.
• Practice a waterfall model of software
development. (Evolutionary GUI?)
• Analysis and design take place before
implementation.
11
Group Project
• A list of projects will be circulated and
discussed in class.
• Students will be instructed as to how to divide
up into groups of 10-12 persons.
• You should meet as a complete group at least
once a week
• You must attend unless you have strong
reasons not to.
12
Project List 08 (incomplete?)
1.
2.
3.
4.
5.
Virtual reality Environmental Problems, Kimmo Eriksson, m.fl.
Sonera SmartTrust AB
WAP Portal Interaction Design Strategy, Andreas Soneby, UNIBT.
Visualisering av data från A/D-omvandlare, Sten Ternström, TMH.
Merging two python open-source projects by merging ElementTree
and PDIS XPath engine, Anna Thorslund.
6. NoName, Helge Stephansen, T-VIPS AS/Mats Erixon.
7. NoName, Örjan Melin, United Network.
8. Beräkningar och gränssnitt I samband med tillverkning av rostfritt stål,
Rutger Gyllenram, Kobolde&Partners
9. Gymnastik vid datorn, Helena Tobiasson, Staffan Romberger
10. Varors och tjänsters miljöpåverkan, Sinna Lindqvist
11. NoName, Niklas Rudemo, Virtutech
12. NoName, Klas Orsvärn, EVP Business Development
13
Project Schedule
• Divided into 6 phases of a waterfall model:
(1) Project Planning and Feasibility Study,
(2) User Requirements Analysis, (3)
Software Requirements Specification, (4)
Architectural Design. (5) Detailed Design
and Coding. (6) Testing and Delivery.
14
Project Deliverables
• Each group will deliver a report at the end of
phases 1-4.
• Phase 5 deliverable is simply code
• Phase 6 deliverable is a group presentation of
the project for the class, followed by an
individual software demo.
• Each phase carries equal credit points.
15
Project Reporting
• Each phase ends with a written and oral
report,
• Delivery dates are also on web page.
• Two persons per group to deliver a 6 minute
presentation of the report to class using OHP
slides.
• Presenters must hand in a bound typed
hardcopy of the report.
• ESA PSS 05 reporting standard
16
Project Timetable: Period 2
• Week 45: Tues 4th Nov, E1, 1500-1700:
Introduction to projects and choice of project.
• Week 47: Tues 18th Nov, E1 1500-1700 :
Presentation and submission of Project
Planning Document (PPD).
• Week 50: Wed 10 Dec, E1, 1500-1700:
Submission and Presentation of User
Requirements Document (URD).
17
Project Timetable Periods 3,4
• Week ?: ?? Jan 2009, ??, ????-???? : Submission and
Presentation of Software Requirements Document
(SRD).
• Week ?: ?? Feb 2009, ??, ????-????: Submission and
Presentation of Architectural Design Document (ADD).
• Week ??: May 2009, ??, ????-????, ????-???? : Final
presentation of the completed project, delivery of User
Manual. Schedule individual project times for practical
software demonstration.
• NOTE: Each project member must make at least one
oral project presentation
18
Project Meeting Minutes
• Must record the dates and times that your project group
meets.
• May prepare an agenda for meeting
• Secretary must take minutes of meeting
(mötesanteckningar)
• Minutes must be circulated electronically to group
• Minutes must include actions and individual
responsibilities
• Minutes must be checked again at next meeting to follow
up actions, and outcomes must be recorded
• Latest minutes must be included with each deliverable
report
• See web page for examples
19
Phase 1: Project Planning and
Feasibility Study
• It is important that you function "as a group".
• Get to know one another (different skills, interests and experiences)
• Establish standards for discussion, reaching agreement and
resolving conflict.
• Project planning and feasibility phase not officially part of the PSS
05 standard.
• Success will:
– connect you as a coherent group, with an agreed and understood joint
set of objectives and approaches.
– Lower the project risk attached to your project. (A more detailed risk
analysis comes later.)
– help you prepare for first major task: writing the User Requirements
Document (URD).
20
PPF Phase: How to?
• ASAP you must meet as a group and establish
a regular weekly meeting time
• You can meet in any location you wish.
• From time to time smaller working groups can
meet.
• To maintain progress you must meet every
week. Evidence of this meeting, will be sets of
minutes submitted for all meetings with each
project deliverable (URD, SRD, ADD).
21
PPF Phase: How to? (cont.)
• First task is to assign yourselves a group name
(legal and decent.),
• Collect your names, e-mail addresses and
telephone numbers and e-mail me this
information
• Perform a skills audit of the group, i.e. technical
strengths and weaknesses of each group member
(e.g. Unix expert, Windows expert, GUI expert,
etc.)
• Team members need to be honest and open
about this
22
Project Roles
• On the basis of skills audit you should assign roles to
group members (one member can have more than one
role.)
• Project leader: Responsible for overall co-ordination,
and ultimate decisions and responsibility, deep
understanding of the project and the PSS 05 standard.
• Project secretary: Responsible for writing/delegating
documentation and report writing, taking minutes of
meetings, deep understanding of the PSS 05 standard.
• Chief programmer(s): An optional role, but favoured
by many in industry, senior responsibility for coding, a
person who delegates simpler programming tasks.
23
Roles (cont.)
• Programmer(s): A more flexible programming role that
might also include documentation and testing.
• Documentation Manager: An optional role that could
be separated from the secretary role, write and/or
produce reports.
• Report Writer(s): A technical writer, assigned tasks by
the secretary or documentation manager.
• Tester(s): Responsible for unit module and system
testing. Receives tasks assigned by the project leader
or chief programmer(s). Typically programmers are not
allowed to test their own code.
24
Roles (cont.)
• Requirements Analyst(s): An optional role, responsible for
capture, exploration and analysis of end-user requirements.
Good social skills are important for this role, as well as
technical ability.
• Designer(s): Responsible for problem analysis, solution
inception and software design. Tasks normally assigned by
project leader.
• GUI expert(s): An optional but common specialist role.
Tasks assigned by project leader/ chief programmer.
• Project planner(s): An optional role otherwise performed
by the project leader and/or secretary. May also monitor
progress and reschedule tasks to incorporate change.
25
Roles (cont.)
• Customer Account Manager: Industrial end-users tend to
be very busy, so one single reliable unique point of
contact reduces confusion and improves communication.
Excellent social skills are important for this role.
• NOTE: all the above project roles must be manned by
some person (exception: optional roles!). Roles must be
recorded in the planning document
• Everyone expected to contribute to ideas and decisions
• You should be democratic, although in the case of conflict
project leader has the final say.
26
PPF Deliverable: PPD
Cover page, Contents page, Abstract (1-2 paragraphs)
1. Statement of the Problem
1.1. Statement of the Problem
1.2. Motivation
1.3. Goals
1.4. Skills Baseline
2. Background to the Problem
2.1. Commercial background
2.2. Scientific background
2.3. Technical Background
Conclusion: Feasibility Assessment
Appendix
(Total: covers + 4-6 pages?)
27