- Aug 30: Those who want to meet up with others to form a team are recommended to attend the Lego session at Lindholmen.
- Aug 23: On Aug 31 we will introduce Scrum by a workshop. There will be
fourthree sessions and you will participate in only one of the sessions. The sessions are
Divide into teams of six and e-mail Håkan team members, team name and preferred session. This information will be repeated at the first lecture.
- Aug 15: Homepage is up and running. The homepage will be continuously edited, reflecting the evolution of the course.
Software remains malleable, often illogical, and incomplete forever. Sequential approaches to software development, such as the waterfall model, assumes that it is possible to take every single variable that could affect a project into account beforehand. Considerable effort is spent to identify risks, plan mitigation, and what consequences these may have. From a traditional product perspective, this can be compared to creating an assembly line to produce software.
Given the nature of software, is it really feasible to identify all variables beforehand? Iterative and incremental approaches accepts that changes are inevitable and integrates change management into the development process. Agile approaches promotes iterative and incremental development by using a very tight design-code-test cycle. If we again use a traditional product perspective, this can be compared to new product development.
Most of the course time is spent on a course project. This year the project is run in collaboration with students from the Interaction design master and Restadgård supportgroup. The scope of the project will be presented in more detail on Sep 14.
In this course you will learn how to design and develop software, and to manage projects:
-
Knowledge and understanding, the student should be able to:
- identify the complexities of software design and development
- describe the fundamentals of software engineering, such as stakeholders and requirements
- describe the difference between the Customer, the Solution, and the Endeavour as well as the different methods used for each
-
Skills and abilities, the student should be able to:
- elicitate requirements from and design a solution to a real-world problem
- plan and execute a small software development project in a team
- apply skills from programming courses and other relevant courses in a project-like environment
- learn new tools and APIs on his/her own
-
Judgement and approach, the student should be able to:
- reflect on the choice of software engineering methods used in the project
The grading policy will be updated before the first lecture. The aim is to meet the requests from last year's course evaluation.
| ID | Name | Gitname | Contact | Role |
|---|---|---|---|---|
| HB | Håkan Burden | hburden | burden@cse.gu.se / burden@chalmers.se | Course responsible |
| JP | Jan-Philipp Steghöfer | steghoja | jan-philipp.steghofer@cse.gu.se | Examiner |
| RJ | Rodi Jolak | rodijolak | Lecturer | |
| DS | Daniel Sjölie | dsjolie | daniel.sjolie@ait.gu.se | Lecturer |
| Program | Name |
|---|
Book:
- Kniberg, H. (2015) Scrum and XP from the Trenches - 2nd Edition. Free with registration
Vision:
Agile:
Git:
- Pro Git, Git Videos
- A successful Git branching model
- GitHub Student Developer Pack
- Interactive Git learning: Learn Git Branching
Android:
- Design patterns explained with Android examples
- Android tutorials
- Android development tools and docs
The details of the lectures, exercises, workshops and deliverables will be explained during the first lecture. Note that the TimeEdit schedule contains all possible sessions, while the schedule below contains those that we actually use!
| Week | Date & Time | Room | Topic | Who | Deliverable(s) |
|---|---|---|---|---|---|
| 01 | Aug 29 10.00-11.45 | VasaA | Course introduction | HB | |
| Aug 30 10.00-11.45 | 5215 | Tool supervision | RJ | ||
| Aug 31 10.00-17.00 | Mållgan / 5215 | Lego exercise | HB & JS | D1A | |
| 02 | Sep 05 10.00-11.45 | HC4 | Scrum & Assessment | HB | |
| Sep 06 10.00-11.45 | 5215 | Tool supervision | RJ | ||
| Sep 07 10.00-11.45 | HC4 | ||||
| 03 | Sep 12 10.00-11.45 | HC4 | Project management | HB | |
| Sep 13 10.00-11.45 | 5215 | Tool supervision | RJ | ||
| Sep 14 13.00-17.00 | Lindholmen Open Arena | Project introduction | HB, DS & RJ | D1B | |
| 04 | Sep 19 10.00-11.45 | HC4 | Task breakdown | JS & HB | |
| Sep 21 10.00-11.45 | HC4 | AR & HCI | DS | ||
| 05 | Sep 26 10.00-11.45 | HC4 | From waterfall to agile | Maria Carlsson, VCC | |
| Sep 28 13.00-17.00 | Lindholmen Open Arena | Half-time Review | HB | D2 | |
| 06 | Oct 03 10.00-11.45 | HC4 | How to grow a community | Joel Rozada, The Techno Creatives | |
| Oct 05 10.00-11.45 | HC4 | Product and organisation in agile development | Michael Öhman, Spotify | ||
| 07 | Oct 10 10.00-11.45 | HC4 | TBD | ||
| Oct 12 13.00-17.00 | Lindholmen Open Arena | Last chance demo | HB | ||
| 08 | Oct 17 10.00-11.45 | HC4 | Reflection | HB | |
| Oct 19 13.00-17.00 | Lindholmen Open Arena | Final presentation | HB | D3 | |
| 09 | Oct 28 17.00 | -- | Hand off | HB | D4 |
| -- | Nov 28 13.00-16.00 | ML3 | Feedback | HB |
The individual grades are based on the team contribution. Contribution is in turn defined according to Stakeholder value, Protoype and Reflection report. Each category represents a certain number of points so that the total number of points sums to 50. The points are not evenly distributed across the categories since the assessment occurs at different points in time and represent different efforts.
To pass the course each team has to deliver:
- D1: Setup: The first deliverable consists of two parts,
- D1.A: A one-page document drawing on the lessons from the Lego scrum exercise on how to initially work with scrum. Describe three insights from the exercise and how these will affect how you implement Scrum in your project. An insight can be that you want to do more or less of a practice, or that you want to change how you applied a practice. To be e-mailed to the course responsible at Sep 02 17.00 at the latest.
- D1.B: A vision or a concept for the prototype. An initial product backlog. A social contract for the team. Make sure the documents are in your git repo and an invitation to your scrum board is sent to JS before Sep 16 17.00.
- D2: Half-time evaluation: A one-page document reflecting on the work so far, both in terms of process and product. D2 should be uploaded to the git repo before Sep 30 17.00.
- D3: Final presentation: The third deliverable is a working prototype (APK) for the final presentation. D3 should be uploaded to the git repo before Oct 19 13.00.
- D4: Signing off: The last deliverable consists of deliverables D1, D2 and D3 including the source code and the output from gitinspector as well as the artefacts asked for under [Prototype](### Prototype) and [Reflection Report](### Reflection Report). Do not touch the git repo after Oct 28 17.00.
within the designated deadlines.
To pass the course a student has to deliver:
- evidence for active participation in the team effort. The level of student participation is determined on a combined assessment of the output from gitinspector and the mean values from the team evaluation.
- an evaluation of the members of the team, including themselves. Imagine that you have a budget of $10 per group member, including yourself (so, $50 for a group of 5). How would you distribute this "pay" among your group members, based on their value and contribution? Email your evaluation (name and amount for each group member including yourself) to burden@cse.gu.se no later than 03 June 17:00 2016. (The evaluation will not affect the group grade, it will only be used to determine individual variation within a group. However, if you do not submit this evaluation, you will not pass the course).
within the designated deadline
The stakeholder value is assessed during the final presentation. The total score is the sum of
- Completeness (features outlined in vision are present, one application and stable operation)
- GUI (self-explanatory for intended users, clarity and no excess information)
- Relevance to vision (efficiency and clear relation to problem domain)
- Acceptance test
Each part is worth 0-3 points where 0 represents failed delivery, 1 equals major remarks, 2 signifies minor remarks and 3 no remarks.
All artefacts related to the prototype should be in the Git repository. These will be assessed after the final deadline of the course.
- Code quality, 3p. Code quality is based on the verdict of FindBugs where the sum of issues gives the number of points for code quality
- 0-10 = 3p
- 11-20 = 1p
-
21 = 0p where the impact of each kind of Correctness issues counts as 4, Bad style as 2, Dodgy as 2 and Performance as 1. Each team is responsible for uploading the FindBugs report to their repository.
- Unit / integration / system tests, 3p
- Design rationale (choice of API-level, external dependencies, database structure etc.), 3p
- Overview, 3p
- Behavioural
- Structural (What major parts / components are there in the application)
- Protocol (client/server)
- User stories, 3p
Each part worth 3 points has an allocation strategy where 0 represents failed delivery, 1 equals major remarks, 2 signifies minor remarks and 3 no remarks.
The reflection report is also uploaded to the git repository as a PDF-file. It will be assessed after the final deadline of the course.
- Application of scrum
- Roles, team work and social contract (relates to D1B)
- Used practices (pair programming, stand-up meetings, etc.)
- Time distribution (person / role / tasks etc.)
- Effort and velocity and task breakdown
- Reflection on the sprint retrospectives
- Documentation of sprint retrospectives, 0-1p
- Reflection on the sprint reviews
- Best practices for using new tools and technologies
- Reflection on the relationship between prototype, process and stakeholder value
- Relation of your process to literature and guest lectures
- Evaluation of D1A and D2
- Burn-down chart, 0-1p
Each part worth 3 points has an allocation strategy where 0 represents failed delivery, 1 equals major remarks, 2 signifies minor remarks and 3 no remarks. Including sprrint retrospectives for all sprints gives 1 point, including the burn-down chart is also worth 1 point.
Reflection is here defined as “assessment of what is in relation to what might or should be and includes feedback designed to reduce the gap” (R. Smith. Formative Evaluation and the Scholarship of Teaching and Learning. New Directions for Teaching and Learning, vol. 88, 2001, pp. 51-62). This means that you should describe the situation as it is, what you would like it to be as well as a realistic way to get there.
The team grade is given by the total number of points for the team effort:
- 00 - 20: U (Fail)
- 21 – 30: 3 / G (Pass)
- 31 – 40: 4
- 41 – 50: 5 / VG
The team grade then serves as a baseline for the individual grades so that students with higher contributions and team effort receive a higher grade than the team grade and students with lower individual scores receive a lower grade. Higher and lower are approximately 25% more / less than team average.
We strive for a transparent and fair assessment strategy. That is why we as teachers are the ones that do the grading based on our experience.