Software EngineeringDD1365 MVK-09

Karl MeinkeNADA

karlm@nada.kth.se

2

Overview of Course

Aim: To introduce students to the theory and practice of software engineering.

Activities: • formal lectures, • invited industrial speakers, • a group project (10-12 students – 6+9 points)• Project presentations (every student)

3

DD143X

• Follow on course• 6 + 9 points• SE engineering lectures• Project work + presentations• Batchelors thesis (kandidat ex-jobb) with

support.• Compulsory for students who wish to finish

the project

4

Overview (cont)

Assessment: individuals will be assessed by weighting thegrades awarded for the group project.

There is no formal examination .

5

Software Engineering Theory

We will organize our study of theory around the

Waterfall lifecycle model

This will support and guide your project work

6

User Requirements

Software Requirements

Architecture Design

Detailed design & Coding

Testing

Delivery

The WaterfallLifecycle Workflow

Time

Business Process Modeling

System Modeling

Architectures &Patterns

You know this!

Software QA

UML

7

Theory

• We will consider other theoretical subjects such as:

• Lifecycle models• Managing project risk• Project management

8

Group Project (6+9 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.

9

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.

10

Project List 08 (selection)1. Virtual reality Environmental Problems, Kimmo Eriksson, m.fl.2. Sonera SmartTrust AB3. WAP Portal Interaction Design Strategy, Andreas Soneby, UNIBT.4. Visualisering av data från A/D-omvandlare, Sten Ternström,

TMH.5. Merging two python open-source projects by merging

ElementTree and PDIS XPath engine, Anna Thorslund. 6. Beräkningar och gränssnitt I samband med tillverkning av

rostfritt stål, Rutger Gyllenram, Kobolde&Partners7. Gymnastik vid datorn, Helena Tobiasson, Staffan Romberger8. Varors och tjänsters miljöpåverkan, Sinna Lindqvist

11

Project Handbook

• This year (2009/2010) there is an (online) project handbook under development.

• http://www.nada.kth.se/~karlm/mvk/Project_Handbook.pdf

• This aims to centralize most of the information you will need.

• Has document templates• Has tips from previous students

12

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.

13

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 and is graded U/G/VG

14

Project Reporting

• Each phase ends with a written and oral report,

• Delivery dates are on web page. • Two persons per group to deliver a 5 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

15

Project Timetable: Period 2

• Tues 3rd Nov, D1, 1500-1700: Introduction to projects and choice of project.

• Tues 17th Nov, D1 1500-1700 : Presentation and submission of Project Planning Document (PPD).

• Wed 8th Dec, D1, 1500-1700: Submission and Presentation of User Requirements Document (URD).

16

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

17

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

18

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).

19

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).

20

PPF Phase: How to? (cont.)

• First task is to assign yourselves a group name (legal and decent.),

• Collect your names, personal numbers, e-mail addresses and telephone numbers in a project staffing document (PSD)

• e-mail me the PSD in .pdf format• 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

21

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: An optional role, but favored by many in industry, senior responsibility for coding, a person who delegates simpler programming tasks.

22

Roles (cont.)• Programmer: 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: A technical writer, assigned tasks by the secretary or documentation manager.

• Tester: 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.

23

Roles (cont.)• Requirements Analyst: 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: Responsible for problem analysis, solution inception and software design. Tasks normally assigned by project leader.

• GUI expert: An optional but common specialist role. Tasks assigned by project leader/ chief programmer.

• Project planner: An optional role otherwise performed by the project leader and/or secretary. May also monitor progress and reschedule tasks to incorporate change.

24

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.

25

PPF Deliverable: PPDCover page, Contents page, Abstract (1-2 paragraphs)1. Statement of the Problem

1.1. Statement of the Problem1.2. Motivation1.3. Goals1.4. Skills Baseline

2. Background to the Problem2.1. Commercial background2.2. Scientific background2.3. Technical Background

Conclusion: Feasibility AssessmentAppendix(Total: covers + 4-6 pages?)