Course syllabus

Jump to today

Course-PM

DAT257 Agile software project management lp1 HT19 (7.5 hp).

The course is offered by the department of Computer Science and Engineering.

Contact details

Please use the discussion forum for general questions regarding course organisation and assignments. In this way, everyone can participate and we don't spend our time answering the same questions again and again. If you want to discuss a personal question or another student, please e-mail both teachers at the same time as this makes it easier for us to respond fast and appropriate.

Håkan Burden

  • github account: hburden
  • contact: burden@cse.gu.se
  • formal role: course responsible

Jan-Philipp Steghöfer

Nils-Martin Robeling

Student representatives:

Albin Becevic: albbec@student.chalmers.se
David Hermansson: davherm@student.chalmers.se
Dara Khadjehnouri: dara@student.chalmers.se
Lucas Rosvall: lucasrosvall@gmail.com
Marcus Schmidt: whiaen@hotmail.com

Course purpose

Aim

The course is intended to provide the students with the basic knowledge, and first experience, in the creation of value through software within the scope of a practical project.

Learning outcomes (after completion of the course the student should be able to)

After completion of this course the student should possess the following understanding, skills, abilities and judgement: 
Knowledge and understanding, the student should:

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

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

  • reflect on how the process was applied in a project
  • reflect on the own and the team's learning strategies

Content

The course provides a practical introduction to Software Engineering. Students work on an open problem that is defined by stakeholders outside of the students' team. That means that students will not be able to define the project they work on themselves. In order to address this challenge, students will learn:

  • a software development process to structure their work
  • how to specify and evaluate requirements and the collaboration with stakeholders to assure that was is being delivered is perceived as valuable
  • new technologies and tools and fitting ways to use them in order to realise the value proposition based on the students' own learning strategies
  • how to organise themselves in a team in order to reach a joint goal with limited resources
  • how to reflect on their own work and learning to enable a continuous improvement of their way of working

Organisation

The course is organized as a project where the students work in teams of usually six students to address a real-world software engineering assignment. The teams have weekly supervision meetings. The project is supplemented by exercises and lectures that provide insight into the assignment students are working on and software engineering in general. The weekly supervision is an integral part of the course design in which the students and the teaching staff together make sense of the learning objectives in relation to the experiences of the students. 

Schedule

TimeEdit

Course literature

There is no required reading, but the following have proved to be helpful resources. 

Scrum:

Git:

Course design

The first two weeks of the course introduces software engineering in general and the Scrum methodology in detail. The theoretical content is inter-woven with practical exercises so that students have the opportunity to develop their own praxis of how to apply a project management methodology in practice. The underlying pedagogical frameworks will be briefly introduced during the lectures.

The scope of the project is to deliver software that enables real-time data for passenger ferries. The different tasks will be described and motivated during week 2 by representatives from the EU-project Real-Time Ferries who will be represented by a project manager, a professional scrum master / system architect and a product owner. You will work with databases for public transport, open formats for journey planning and geographical systems developing software that enables more people to plan and make journeys including multiple modes of transport.

Course Week 1:

  • Mon - first half introduces software engineering and the course organisation, the second half is an exercise introducing the plan-execute-evaluate cycle which is paramount for the course
  • Tue - the Lego exercise
  • Wed - Agile software engineering 
  • Deliverable: A social contract should be uploaded to the group repository by Fri 17.00 (instead of the team reflection)

Course Week 2:

  • Mon  - Introduction to project scope and organisation
  • Tue - "Slicing the cake" exercise
  • Wed - Backup slot which might be removed
  • Deliverables:
    • A description of your project scope together with a mockup. Upload both to your team repository by Friday 17.00 (No team reflection this week)
    • Individual reflection

Course Weeks 3-7:

  • Mon - Supervision with the Real-Time Ferries reps and teaching staff
  • Week 7 there is a lecture to detail the finals submissions and the final presentation
  • Deliverable: A team reflection report and an individual reflection report, uploaded to the group repository. The deadline is decided by each team so that it fits with the sprint structure

Course Week 8:

  • Wed - Final presentation in Dome of Visions
    • 0800 - 0930 Preparation (if you want to rig a table or check the AV-equiptment)
    • 0930 - 1200 Presentation (each team gives a 3 minute pitch followed by a mini fair)
  • Deliverables: No deliverables. This weeks reflections are merged into the final reflection (see week 9).

Course Week 9:

  • Deliverable: The team's Final reflection report where you summarise and synthesise the previous reflections (including reflections from week 8). And the same for the final individual reflection report. To be uploaded to your repo by 01 NOV 1700. 

The project teams will be formed during the exercises during the first week. If you wish to collaborate with one or more of your friends, we will try to take that into consideration and you can make it more probable by preparing suggestions for full groups (6-7 students).  

Changes made since the last occasion

This is the first time DAT257 is given. It replaces DAT256 Software Engineering Project Course and the major changes are

  • the introduction of pass / fail grades (U/G) which in turn has an impact on how we assess the teams and the students, see examination
  • the inclusion of entrepreneurial experiences, as defined and recommended by Chalmers, as as pedagogical framework for the course objectives.

Learning objectives and syllabus

Learning objectives:

After completion of this course the student should possess the following understanding, skills, abilities and judgement:
Knowledge and understanding, the student should:

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

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

  • reflect on how the process was applied in a project
  • reflect on the own and the team's learning strategies

Link to the syllabus Chalmers.
Link to the syllabus GU.

Examination form

The examination consists of two parts - one for assessing the project teams and one for each individual student.

Team grade 

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 sprint, we will only assign points to your final report 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.

As a team you should reflect on the topics below. It is not necessary to reflect on all topics every week. Instead, you are asked to make a selection of the topics that are relevant in any given week. However, the final report should address all topics. That means that you need to reflect on each topic at least twice to show your progress.

Customer Value and Scope

  • the chosen scope of the application under development including the priority of features and for whom you are creating value
  • the success criteria for the team in terms of what you want to achieve within the project (this can include the application, but also your learning outcomes, your teamwork, or your effort)
  • your user stories in terms of using a standard pattern, acceptance criteria, task breakdown and effort estimation and how this influenced the way you worked and created value
  • your acceptance tests, such as how they were performed, with whom, and which value they provided for you and the other stakeholders
  • the three KPIs you use for monitoring your progress and how you use them to improve your process

Social Contract and Effort

  • your social contract, i.e., the rules that define how you work together as a team, how it influenced your work, and how it evolved during the project (this means, of course, you should create one in the first week and continuously update it when the need arrives)
    There is a survey you can use for evaluating how the team is perceiving the process and if it is used by several teams it will also help you to assess if your team is following a general pattern or not.
  • the time you have spent on the course and how it relates to what you delivered (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
  • which technical documentation you use and why (e.g. use cases, interaction diagrams, class diagrams, domain models or component diagrams, text documents)
  • how you use and update your documentation throughout the sprints
  • how you ensure code quality and enforce coding standards

Application of Scrum

  • the roles you have used within the team and their impact on your work
  • the agile practices you have used and their impact on your work
  • the sprint review and how it relates to your scope and customer value (Did you have a PO, if yes, who?, if no, how did you carry out the review? Did the review result in a re-prioritisation of user stories? How did the reviews relate to your DoD? Did the feedback change your way of working?)
  • best practices for learning and using new tools and technologies (IDEs, version control, scrum boards etc.; do not only describe which tools you used but focus on how you developed the expertise to use them)
  • relation to literature and guest lectures (how do your reflections relate to what others have to say?)

Each sprint, you will thus have to upload one document that describes the reflection of the entire team to the repository. It might require a few iterations but the ambition is that each team will be able to evaluate the previous sprint, including writing down the reflections, and plan the next sprint within four hours. What is important to note is that there might be sprints 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. 

For the team to pass the course there has to be 

  • a final report that summarises and synthesises the weekly reflections. The reflections should clearly detail the teams' own experiences, the proposed changes to improve on the topic, how the changes were evaluated (KPIs, acceptance testing etc.) and subsequent experiences and changes
  • a repo named after the team including the source code, tests, a breakdown of contributions (such as gitinspector), the technical documentation, instructions on how to install and use the system and an executable if applicable (such as an apk- or jar-file) and the weekly reflections
  • a scrum board with well-formed user stories, including efforts and task breakdown, as well as epics

We expect the teams to submit the report and invitations to the repo and scrum board through the Canvas submission system before the deadline. A late final submission results in the team failing the course.  

The supervision slots are a good time to discuss and get feedback on your weekly reflections, both team and individual.

Individual grades

Each team member submits an individual reflection each week (starting week 1). 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 use of Scrum?
  • what is my contribution towards the team’s deliveries?

That means that for the personal learning objective you will each sprint write down what you have achieved in relation to last sprint's ambition (technologies, concepts and skills learnt as well as how this was achieved), what you would like to achieve for the next sprint 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 sprint as long as you can motivate the change and you evaluate the outcome of the previous sprint (e.g. describing the current situation). Please make sure to be concrete about your goals and how to achieve them and remember that the learning objectives in this course are about working with a process and not individual technologies.

The individual grade is then based on the team grade, the individual reflections, the outcome of the peer assessment , and finally the outcome of analysing the contribution towards the team repository (for instance by gitinspector). In order to pass, the individual reflections have to be uploaded, complete, and need to reflect how you as an individual contributed to the process and to the team. There should be a record that shows that an individual has also contributed to the source code (e.g., by having commits in the repo or by reflecting around pair programming) and the peer assessment should indicate that the student participated in a meaningful way. If more than one of these indicators provide evidence for excellent or sub-par contributions, the student will either fail the course or might receive an individual grade that differs from the team grade.

If there are indications that an individual does not provide sufficient evidence that they reached the learning objectives by actively participating in the group, contributing code and/or documentation, and reflecting on their role in the team as described above, this individual will be failed, independent of the team grade. 

In the case of the opposite, that one team member is doing all the work for the entire team, we suggest you use the supervision slot to raise the issue, The reasoning is that it does not reflect the agile principles to let other team members get away with doing nothing, rather you should raise the issue and work for a change. Letting others off will most probably result in getting failed. Instead, raise the issue since getting ideas for and feedback on changing the situation is one of the things we teachers can help you with during supervision. 

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. Your comments will help us understand the points you award better. This information will be used in setting the individual grades. Only the teachers will see the final results of the peer assessment for grading.

 

Course summary:

Date Details Due