- Sep 10: Thanks to Gustaf there is now a slack for the course. Feel free to create the channels you need, there is already a channel named ask_a_teacher for asking course relevant stuff
The course consists of two phases. The first phase consists of two weeks and is used to introduce the course topics through lectures and exercises. During the first week the students are expected to form a scrum development team. The second phase consists of six-seven weeks and centres around weekly supervision. During this phase the teams work together to develop applications for a specific purpose. Through guest lectures the students are given the opportunity to reflect on how their own work relates to what professional software engineers do and to put their own experiences into a bigger picture. The second phase finishes with a final presentation the week before the examination week. The examination week can then be used to write the final reflection and other relevant documentation needed for signing off.
The majority of the course work is done in project teams. The topic this time is Android apps within the automotive domain. The case will be introduced during the second week of the course.
DAT256 Software Engineering project is the continuation of the course DAT255 Software Engineering Project.
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:
- describe software engineering as an engineering discipline by using relevant terminology
- describe the relationship between stakeholder, product, and process
-
Skills and abilities, the student should be able to:
- specify, implement, and evaluate a system based on what different stakeholders perceive as valuable
- learn tools and APIs which are relevant for the project in collaboration with the other team members
- apply a structured software development process as a member of a team
-
Judgement and approach, the student should be able to:
- reflect on how the process was applied in a project
- reflect on the own and the team's learning strategies
Since a substantial part of the work is conducted in teams, please consider the Chalmers rules regarding your work conditions. If you encounter problems, contact a course teacher immediately!
| ID | Name | Gitname | Contact | Role |
|---|---|---|---|---|
| HB | Håkan Burden | hburden | burden@chalmers.se | Course responsible |
| JS | Jan-Philipp Steghöfer | steghoja | jan-philipp.steghofer@cse.gu.se | Examiner |
| Program | Name | |
|---|---|---|
| TIDAL | hojmark@student.chalmers.se | André Höjmark |
| TIDAL | davolofs@student.chalmers.se | David Olofsson |
| TIDAL | weanton@student.chalmers.se | Anton Wester |
The course evaluation meeting will take place Dec 07 at kl 15.00. Place to be announce later by e-mail.
Agile:
- Kniberg, H. (2015) Scrum and XP from the Trenches - 2nd Edition. Free with registration
- Breaking a feature into tasks
- Maintaining the full view of a complex system
- Scrum of scrums
Git:
- Pro Git, Git Videos
- A successful Git branching model
- GitHub Student Developer Pack
- Interactive Git learning: Learn Git Branching
Android:
- The code and docs for Semcon's Android AUTO project are available as a zip-file on Google Drive
- Useful patterns for Android applications
The details of the lectures, exercises, workshops and deliverables will be explained during the first lecture. As we strive to mirror the TimeEdit schedule, please inform us if you find any differences!
| Wk | Date & Time | Room | Topic |
|---|---|---|---|
| 01 | Sep 03 08:15-10:00 | Gamma | Software Engineering |
| Sep 03 10:15-12:00 | Gamma | Kata & Template | |
| Sep 04 08:15-12:00 | Jupiter122 | Lego Exercise | |
| Sep 05 10:15-12:00 | Svea219 | Software Engineering cnt. | |
| 02 | Sep 10 10:15-12:00 | Svea226 | Project Introduction |
| Sep 11 10:15-12:00 | Svea219 | Android CAR | |
| Sep 12 10:15-12:00 | Gamma | MVP Exercise | |
| 03 | Sep 17 10:00-11:45 | Lindholmen Open Arena | Supervision |
| 04 | Sep 24 10:00-11:45 | Lindholmen Open Arena | Supervision |
| Sep 25 10:15-12:00 | Svea118 | Guest Lecture | |
| 05 | Oct 01 10:00-11:45 | Lindholmen Open Arena | Supervision |
| 06 | Oct 08 10:00-11:45 | Lindholmen Open Arena | Supervision |
| 07 | Oct 15 10:00-11:45 | Lindholmen Open Arena | Supervision |
| Oct 16 10.15-12.00 | Alfa | Conclusion | |
| 08 | Oct 24 09.30-11.00 | Södra Porten | Final presentation |
| 09 | Nov 02 17:00 | Sign Off |
The assessment is done on both individual and team level. The assessment is done in terms of reflecting on pre-defined topics that you can find below. Smith states that reflection is "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) which can be boiled down to describing ...
... the current situation or "what is" (A),
... what you want the situation to be or "what might or should be" (B), and
... a plan for getting from where you are to where you want to be or ""feedback designed to reduce the gap" (A -> B).
While we ask you to reflect every week, we will only assign points to your final report (due in week 9) which should summarise and synthesise the learning from the project as a whole (Step A: "what is"), describe what you would like to do in a similar future project (Step B"what might or should be") and how you can make the change come true (Step C: "feedback designed to reduce the gap"). We will also have a look at the reflections from previous iterations to see if your chain of reflection is complete.
Each week (i.e., in each iteration), you will thus have to upload one document that describes the reflection of the entire team to the repository. In addition, you will also have to upload an individual reflection to the repository each week. The contents of these documents are described below. What is important to note is that there might be weeks where some of the topics are more relevant than others. You might decide to skip a topic, but please provide a rationale if you do so. We strongly suggest structuring your documents in a way that makes it clear where each individual topic is addressed. Finally, we will ask you to create a peer assessment in the final week. This assessment indicates how the workload has been distributed amongst the team members.
In the individual reflection, please address the following questions, using the A, B, A -> B reflective loop as described above:
- what do I want to learn or understand better?
- how can I help someone else, or the entire team, to learn something new?
- what is my contribution towards the team’s application of Scrum?
- what is my contribution towards the team’s deliveries?
That means that for the personal learning objective you will each week write down what you have achieved in relation to last week's ambition (technologies, concepts and skills learnt as well as how this was achieved), what you would like to achieve for the next week and how to make the change happen. The first week of the course you describe the current situation by motivating a learning objective. It is perfectly fine to change objective/s each week as long as you can motivate the change and you evaluate the outcome of the previous week (e.g. describing the current situation).
As a team you should reflect on the following topics:
Customer Value and Scope
- the chosen scope of the application under development including priority of features and for whom you are creating value
- the success criteria for the team in terms of what you want to achieve with your application
- your user stories in terms of using a standard pattern, acceptance criteria, task breakdown and effort estimation
- your acceptance tests, such as how they were performed and with whom
- the three KPIs you use for monitoring your progress and how you use them
Social Contract and Effort
- your social contract, i.e., the rules that define how you work together as a team (this means, of course, you should create one in the first week)
- the time you have spent on the course (so keep track of your hours so you can describe the current situation)
Design decisions and product structure
- how your design decisions (e.g., choice of APIs, architecture patterns, behaviour) support customer value
- what you document and why, by using e.g. use cases, interaction diagrams, class diagrams, domain models or component diagrams, text documents etc.
- how you use and update your documentation throughout the sprints
- how you ensure code quality, enforce coding standards, and
Application of Scrum
- the roles you have used within the team
- the agile practices you have used for the current sprint
- the sprint review (either in terms of outcome of the current week's exercise or meeting the product owner)
- best practices for using new tools and technologies (IDEs, version control, scrum boards etc.)
- relation to literature and guest lectures (how do your reflections relate to what others have to say?)
The peer assessment provides an indication of the distribution of the work in the team. It is used to identify outliers within the team that either contributed significantly more or less than the average. This information will be used in setting the individual grades.
Each step of the reflective cycle (A, B, A -> B) is worth one point per topic, so that you can achieve a maximum of 3 points per topic in the team reflection. You can only score a point for a step if you received a point for the previous step(s). This means if is possible to receive 0 points if you only describe where you want to be (B) while not describing the current situation (A). That also means that you need a complete chain of reflection throughout all weeks. You can not reflect in week n if you have not recorded a reflection for week n-1, since this means that the chain of reflection is broken.
The total for the team is then 16*3 = 48 but each team gets two additional points if all team members have completed their individual reflections, so that the total = 50. The team grade is then computed so that a total score within the range 00 - 20 = U (fail) 21 - 30 = 3 or G (pass) 31 - 40 = 4 41 - 50 = 5 or VG (pass w. distinction)
The individual grade is then based on the team grade, the individual reflections, the outcome of analysing the contribution towards the team repository (for instance by gitinspector) and the outcome of the peer assessment. In order to pass, the individual reflections have to be uploaded and complete. There should be a record that shows that an individual has also contributed to the source code and the peer assessment should indicate that the student participated in a meaningful way. We will change the individual grade from the team grade only if more than one of these indicators provide evidence for excellent or sub-par contributions.
For instance, if the team has been awarded a grade for the course and there is a weekly individual reflection the grade of each team member can then be lowered or raised if both repository analysis and the peer assessment indicate a difference of 25% or more compared to the team mean. This means that in a team of six team members, receiving the team grade 4 where someone is responsible for 20% of the code and scored 14 out of 20 on the peer assessment, that person will get the individual grade 5. Conversely, a team of six with the team grade 3 where a team member committed 5% of the code and scored a mean of 7 out of 20 from peer assessment, that person will be failed.
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.