Course syllabus

Jump to today

Course-PM

DAT256 / DIT543 Software engineering project lp4 vt19 (7.5 hp)

The course is offered by the Department of Computer Science and Engineering

Go directly to the weekly breakdown and list of deliverables

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

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

Jan-Philipp Steghöfer

Course representatives:

Course purpose

The course provides a practical introduction to Software Engineering. Students work on an open problem that delivers value to stakeholders outside of the students' team. That means that students will not be able to define the project scope entirely by 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 what 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 continuous improvement of their way of working

The course is organised 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.

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.

Since the course is taken by students from at least four different programs, and therefore have different skills and knowledge, the groups shall consist of 6 (or 7) students where

  • 2 students are from the Business Management program (I), and
  • 4 students are from Software Engineering (IT), Computer Engineering (D), Computer Science (DV) or similar programs

In this way, each team will have access to a broader set of resources while the team members have the opportunity to work across disciplinary borders, both aspects that reflect the needs within the software engineering industry and that are appreciated by recruiters.

The groups will be formed at the second lecture by a matchmaking exercise. 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 from as stated above) or a sub-group (still considering the restrictions).  

Course Week 1 (Week 13):

  • Mon 10.00 - 11.45 Introduction to software engineering and the course organisation
  • Mon 13.15 - 15.00 Kata exercise and matchmaking for project groups
  • Tue 08.00 - 12.00 Lego exercise, groups Aipom to Jynx
  • Tue 13.00 - 17.00 Lego exercise, groups Kirlia to Weedle
  • Fri 13.15 - 15.00 Introduction to project scope and organisation
  • Deliverable: A social contract should be uploaded to the group repository by Fri 17.00 (instead of the team reflection)
  • Additional deliverable: Individual reflection

Course Week 2 (Week 14):

  • Mon 10.00 - 11.45 Agile software engineering
  • Wed 13.15 - 15.00 "Slicing the cake" exercise
  • Fri 13.15 - 15.00 Project Pitches
  • Deliverable: A description of your project scope using a business model canvas together with a mockup. This deliverable consists of two parts: upload a description, the business model canvas and the mockup to your repository; also create a post in the discussion forum that contains the description of your project scope. The description should have a differentiating factor compared to already posted descriptions and be uploaded by Friday 17.00
  • Additional deliverables: Individual reflections

Course Weeks 3-10 (Weeks 15-21):

  • Mon 08.00 - 12.00 Supervision, groups Aipom to Jynx
  • Mon 13.00 - 17.00 Supervision, groups Kirlia to Weedle
  • 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
  • Additional deliverables: Team reflection and individual reflections

Course Week 9 (Week 21):

  • Fri 15.00 - 17.00 Preparing for final hand-in
  • Deliverables: Team reflection and individual reflections

Course Week 10 (Week 22):

  • Mon 08.00 - 12.00 Final presentation

Course Week 11 (Week 23):

  • Assignment: Final reflection report (see Assignments)

Changes made since the last occasion

No substantial changes since the spring of 2019 have been made.

Learning objectives and syllabus

Learning objectives:

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

  1. Knowledge and understanding, the student should:
    1. describe software engineering as an engineering discipline by using relevant terminology
    2. describe the relationship between stakeholder, product, and process
  2. Skills and abilities, the student should:
    1. specify, implement, and evaluate a system based on what different stakeholders perceive as valuable
    2. learn tools and APIs which are relevant for the project in collaboration with the other team members
    3. apply a structured software development process as a member of a team
  3. Judgement and approach, the student should:
    1. reflect on how the process was applied in a project
    2. reflect on the own and the team's learning strategies

Link to the syllabus on Studieportalen: Study plan

Examination form

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 sprint, we will only assign points to your final report (due latest June 7th, 5PM CET) 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 sprint, 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 sprint. The contents of these documents are described below. 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. 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.

Individual reflection

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.

Team reflection

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)
  • 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?)

Peer Assessment

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.

Grading

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 it 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 of the course. You can not reflect in sprint n if you have not recorded a reflection for sprint n-1, since this means that the chain of reflection is broken.

Points are deducted if the reflection is incomplete, too vague (e.g., if you only state that there was an issue but do not describe it), makes incorrect use of Scrum ceremonies (e.g., stating that tasks should be broken down during stand-up meetings), incorrect use of terminology, false statements (e.g., "Håkan was our Product Owner") or other mistakes.

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 the [peer assessment][PeerAssessment], 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.

For instance, if the team has been awarded a grade for the course and there is an individual reflection for each sprint, 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. 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 even be failed, independent of the team grade. 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 and provides insufficient individual reflections, will be failed.

Course summary:

Date Details Due