T-76.4115/5115 Course Overview

T-76.4115/5115Course OverviewAalto UniversitySchool of Science and Technology

9/7/2010

Contents

• Introduction– motivation– project stakeholders and roles– educational goals

• Project topics– legal issues– selection

• Support to the projects– software development process– mentoring– experience exchange sessions– hw/sw infrastructure– evaluation

9/7/20102

Jari Vanhanen

Motivation – SW Development Scenario 1

• Small software• Developed alone• As a passionate hobby• For the own needs of the developer• No major consequences of bugs• No schedule pressure• No limitations on effort usage• Software will be maintained by nobody or by the developer

9/7/20103

Jari Vanhanen


• Large software system• Developed by a team• Developers’ daily work• SW is used by many different users• SW is done for a paying customer• Every work hour costs money• Management wants to follow the project• Strict schedule and budget• Bugs may cause serious consequences• Maintained by others

What needs attention in this scenario?

9/7/20104

Jari Vanhanen


• Large software system (complexity, architectural design)• Developed by a team (communication, coordination, team spirit)• Developers’ daily work (motivation)• SW is used by many different users (understanding real needs)• SW is done for a paying customer (accountability)• Every work hour costs money (efficiency, prioritization)• Management wants to follow the project (visibility, risks)• Strict schedule and budget (predictability)• Bugs may cause serious consequences (quality, proof of quality)• Maintained by others (maintainability, documentation, training)

9/7/20105

Jari Vanhanen

Course = Project Work

• SW development projects from requirements specification to delivery

• Real customers with real topics– the results will be used by the customers

9/7/20106

Jari Vanhanen

Project Stakeholders - Responsibilities

• Project group– 7-9 students

– develop the system

• Customer– 1 or several persons from the customer organization

– provides the topic and problem description/requirements for the system

– often can also help with technical issues

– takes the responsibility of the system after the project

• Mentor– course personnel

– observes and helps the group with the working methods

9/7/20107

Jari Vanhanen

Project Stakeholders - Goals

Customer•getting sw that solves their problems•getting experiences of technologies and working methods

Mentor•ensuring the fullfillment of educational goals•giving tips and ideas•helping notice problems before it is too late

Project group•learning about sw engineering and software development•good grade from the course•fame from producing great sw•networking with employers

Project

9/7/20108

Jari Vanhanen

Course•at least satisfactorily success for all projects•good enough results for the customers, even though real projects are only a tool to reach the educational goals

Roles in the Project Group - SE Experts

• Project manager– planning and coordinating the project– monitoring and controlling the project– motivating the team

• “QA manager”– requirements engineering– customer relationship– planning and controlling QA– active participation to performing QA

• Architect– architectural design– supervising the developers– active participation to development

An expert takes responsibility, but everyone may participate in

all kind of tasks.

The group may tune the responsibilities of each role, and switch roles between members.

9/7/20109

Jari Vanhanen

Roles in the Project Group - Developers

• 4-6 per group• participate in

– programming– low level design– testing and other QA tasks– assisting some of the SE experts

9/7/2010Jari Vanhanen

10

Course Versions

T-76.4115• size

– 8p, substitutes T-76.115– 6p, default– 5p, for certain modules

• student’s role– developer (or SE expert)

T-76.5115• size

– 6 or 8p, depends on module

• student’s role– SE expert


11

Prerequisites

• T-76.5115 (Project II)– T-76.4115 (mandatory)

– all SoberIT’s SE courses

• T-76.4115 (Project I)– T-76.601 Introduction to Software

Engineering (mandatory)

– T-76.4602 Software Development Methods

– good programming skills


12

Educational Goals (1/3)

• Getting hands-on experience of a real, whole software project– requirements engineering, design, programming, QA– project management

• Learning to apply SE practices and tools and analyze their value– try something new and analyze experiences– understand the limits of practices and tools– enlarge your SE toolkit

• Learning state-of-the-art technologies

– project topics often require using and studying the latest technologies

9/7/201013

Jari Vanhanen


• Learning various general academic skills– management skills– social skills– presentation skills– writing skills– networking– internationalization– business thinking– project work in general

The selected role affects what you learn.

9/7/201014

Jari Vanhanen


• After this course you should– understand the challenges involved in commercial sw development– be able to select good practices and tools for your future projects– have improved in many academic skills applicable practically anywhere


15

Use this opportunity to learn something new about software engineering!

In “real” projects you are often too busy to do that …

Contents




9/7/201016

Jari Vanhanen

Project Topics

• Proposals collected from Aalto university and industry

• Lots of alternatives

• Software development projects– secondary goals may include e.g. technology reviews

• Project scope flexible


17

Project Topics – Legal Issues

• Intellectual property rights (IPR) – open source, or– customer gets IPRs

• Non-disclosure agreement (NDA)– required by some customers– project documentation is public

• except code and technical specs• if NDA required, customer must review

materials before publication

• Participation fee for customers– commitment– course costs

• Contract prepared by Aalto lawyers– between Aalto and customers– between Aalto and students– DL 21.10.

9/7/201018

Jari Vanhanen

Registration and Forming of the Groups

• Register to the course by We 8.9. 13:00 (tomorrow!)

• Teacher selects the SE experts on We 8.9. 13:00– 2-3 more chosen than needed, last ones without a trio become developers

• SE experts form trios– send e-mail to the teacher immediately after a trio has been formed– after Fr 10.9. 13:00, teacher forms trios of the remaining SE experts

• SE expert trios recruite developers– send e-mail to the teacher immediately after you have recruited someone– on Fr 17.9. 13:00 the teacher assigns the remaining developers into groups

Optimal group composition:

seniors and juniors, common work times, similar topic and technology prefs, broad coverage of SE courses passed

9/7/201019

Jari Vanhanen

opinnot.tik.ohjelmatyo

Project Topics – Selection Process

• Customers present themselves and the topics Tu 14.9. 17:00-19

– no contacting before that

• SE expert trios apply for topics– contact 2-4 customers

– “sell” your group to the customer

• short CV of the group

• having good developers may help

• Ensure that the customer– is committed to the project

– understands the domain

– provides needed infrastructure

– doesn’t expect skills that the group doesn’t have or cannot acquire quickly

– appreciates the educational context

• Say “yes” quickly– get confirmation from the customer

– say no to other customers immediately

– send e-mail to the teacher

• If all the customers say “no”– contact new customers


20

If you are not sure, try another customer.

Project Topics – Which one to choose?

• What do you want to learn?– domain– technology– getting to know a certain customer’s organization

• Too easy a topic?– boring– no ”bonus” points in the evaluation

• Too demanding a topic?– unsatisfied customer– fulfilling customer’s goals may take too much focus away from other educational

goals of the course

9/7/201021

Jari Vanhanen

Contents




9/7/201022

Jari Vanhanen

Software Process – Framework

• Process framework provided– iterative and incremental

• phasing and schedule fixed – enforces certain good and educational work practices and

documents– allows lots of freedom (and responsibility) for customization

• Lecture on Tu 21.9. • Every student in any role should read all process

framework materials in the beginning of the project– http://www.soberit.hut.fi/T-76.4115/10-11/instructions/process.html


23

Software Process – Challenges (1/2)

• Project is done for an external customer– understanding the true (and changing) needs

-> requirements engineering during the whole project

-> managing customer’s expectations

• Physical distribution– if no common workplace and time for project stakeholders

-> special care for communication and project visibility

• Temporal distribution– only one of several on-going ”projects” for all participants– long duration, but only 10-15h of effort a week

-> you can’t keep everything in your head-> documentation overhead


24

Software Process – Challenges (2/2)

• New team and organization– no existing development culture (process)– all members do not know each other

-> process must be planned from scratch and communicated to everyone

-> team spirit

• Software will be maintained by other people– after the delivery the group is not responsible for the system

-> high quality code and technical documentation

-> involving the customer’s technical people early

-> knowledge transfer via training and documentation


25

and new technologies, inexperienced managers or developers, multicultural teams, …

Software Process – Iterations

9/7/201026

Jari Vanhanen

Software Process – Project Control Variables• Time (duration and effort) fixed

– project end date and major control points fixed by the course schedule

– effort fixed to 27h/study point

• e.g. 6p = 162h ~ 10h/week

• Quality ”fixed”– high quality recommended

– carefully selected exceptions allowed if explicitly asked by the customer (e.g. prototype projects)

• Scope flexible– iterative development process allows refining plans later

– tuned based on the group’s size and skills and domain knowledge

9/7/201027

Jari Vanhanen

This means considerable amount of

work!

Mentoring (1/2)

• Purpose– help the project succeed– ensure enough focus on the educational goals

• Meetings with the mentor– in 3 iteration demos– in 3 mentor meetings– in 1-2 process reviews– in some work sessions (customer meetings, code review etc.)

• invitation from the group

• Other forms of participation– continuously observing the project

• status reports, meeting memos, irc, …

– answering project related questions by e-mail– evaluating the group in the end of iterations

• points and comments


28

Mentoring (2/2)

• Help the mentor help you!– keep him up-to-date

– prepare questions for the mentor meetings

– invite him to some work sessions• increases visibility to work practices

• Every project will face problems– identify and solve them quickly

– ask help when needed

• Mentor’s rough effort allocation per group– ~1h for each meeting (*~9)

– ~4h for reading, grading and feedback in the end of each iteration (*3)

– ~3h/iteration (*3) for• observing the project• answering e-mails• preparing for mentor meeting

– ~30h TOTAL


29

Experience Exchange Sessions (EES)

• Discussion on problems and good practices related to a certain SE theme– project mgmt, RE, QA, architecture and sw development

• Participants– 1-3 students per group, those who are responsible of the EES’s theme– teacher and some guest experts from Accenture & SoberIT

• Content– groups propose topics before each session (DL 13:00 the previous day)

• practical problems and/or innovative solutions from your project

– teacher prepares an agenda• each topic is introduced shortly by one proposer before discussion

• Sending 2 topics and participating to an EES gives 0.5p to the group– writing an essay is an alternative for English speaking students

• 10 sessions: 3 for PMs, 3 for QAs, 2 for architects, 2 for developers


30

Evaluation – General

• Both the results and working methods are evaluated

• Evaluators– customer

• mentor ensures the objectivity of customers’ evaluation

– mentor

• mentor adjust his scale in evaluation meetings with other mentors

– group members

• may evaluate personal contribution of other group members


31

Evaluation – Course Grade

• Points are given both during and after the project– in the end of each iteration

• Scale from points to grades is published in the end of the course


32

Evaluation – Iterations (Customer)

• Focus on iteration’s results– but working methods are considered, too


33

Manage customer’s expectations in

iteration planning

Evaluation – Iterations (Mentor)

• Focus on work practices• Conformance to the mandatory

practices (educational goals)– plan and usage

• Intelligent process customization– use of any other good work practices– continuous process improvement

• Visibility to work practice– show them to the mentor

– avoid unnecessary documentation e.g. invite the mentor to some work sessions


34

Scale• 8 fulfills some requirements with

distinction and at most a couple of minor complaints

• 7 meets requirements and at most some minor complaints

• 6 at most a couple of major or some minor complaints

• 4-5 some major or lots of minor complaints

• 2-3 several major complaints• 0-1 virtually no results

Evaluation – Project’s Results

• Customer– compares to the

original/updated project goals

• Mentor– compares to typical course

project results

– +/- a few points based on project’s difficultymanage customer’s expectations in

the beginning and during the project

9/7/201035

Jari Vanhanen

Evaluation – Personal Contribution

• Each group member may evaluate each other's contribution– raises and deductions of +/-1 grade, but the sum must be 0

• Unanimous proposal from the group is recommended– alternatively each student can send their proposal privately to the mentor

• Mentor may change personal grades by +/-1 based on the proposals

If the group gets enough points for grade 5, deductions are discarded.

9/7/201036

Jari Vanhanen

Infrastructure

• Hardware– Maarintalo has some group work rooms

http://itservices.tkk.fi/fi/tilat/maari/

• Software– Microsoft MSDN AA

• licenses for students own computers• accounts will be sent to all registered students• info: msdn (at) soberit.hut.fi

– Magic Draw Personal Edition UML tool• licenses for students own computers

– TKK wiki, CVS, subversion, Agilefant, …

Customer must provide other necessary hw/sw

9/7/201037

Jari Vanhanen

Personnel

• Other parties– several teachers and researchers from

SoberIT

– Accenture

• Teachers email– t764115#soberit.hut.fi

9/7/201038

Jari Vanhanen

More Materials

• Course homepage(s)– https://noppa.tkk.fi/noppa/kurssi/t-76.4115/etusivu

– http://soberit.hut.fi/T-76.4115/

• Course Instructions– http://www.soberit.hut.fi/T-76.4115/

• Projects from the previous years (since 1995)– http://www.soberit.hut.fi/T-76.4115/10-11/projects/index.html

• Newsgroup for students– http://news.tky.fi/thread.php?group=opinnot.tik.ohjelmatyo


39

Your Feedback

• We continuously want to improve the course!

• Inform us immediately, if– you see ambiguities in our instructions

– you have any suggestions for improving the on-going course

• Give feedback in the project final report

• Fill the course feedback form after the course (mandatory)


40

Next Seven Days

• Register immediately to the course• Form a group

– SE Experts• form a trio (here, today?)• recruit max. 3 developers

– Developers• try to get recruited into a SE expert trio

• Read the topic proposals– choose some favorites

• Come to the topic presentation lecture next Tuesday 17:00– Introduce your group to some interesting customers (group’s CV)


41

T-76.4115/5115 Course Overview

Documents

jari vanhanencourseat

sw engineering

real projects

large software systemdeveloped

project visibility

risksstrict schedule

projectstrict schedule

real topicsthe results