DIT113 V22 Miniprojekt: Systemutveckling

Jump to today

Welcome to the course homepage of DIT113 V22 Mini Project: Systems Development. The syllabus for the course can be found here.

The course is given by the Department of Computer Science and Engineering at Campus Lindholmen during Study Period 4, 2022. You find information about the course below.

We use a Slack workspace to make the communication easier. Join the course Slack by clicking here.

Course Examiner

Francisco Gomes (francisco.gomes@cse.gu.se)

Course Coordinator

Dimitrios Platis (dimitris@platis.solutions)

Student representatives

Notes from the halfway course evaluation meeting are here.

Course evaluation

At the end of the course, we encourage you to take part of the course evaluation. Your feedback is important. Please do your part by filling out evaluation for all your courses in a constructive, helpful spirit!
You find the survey in the menu bar to the left “Course evaluations” and is open during the last week of lectures, two weeks before the course ends. It’s also here you will find the results after the deadline.

Read more about course evaluation at the Student portal.

Course Material:

Course Schedule and Activities

We use Mondays and Wednesdays 08:15 - 12:00 as placeholders for lectures, group presentation and supervision sessions. Those booked slots will be used for the activities below. Note that we may not need all 4 hours for the course activities. However, we expect that you dedicate that time to attend course sessions or meetings.

About remote participation: Lectures will be on campus but we will stream the lectures depending on the availability of streaming equipment in the classroom. Lectures, weekly check-ins and the sprint demonstrations rely benefit from the live interaction and participation which are hard to do in a hybrid setup. Note that this is a campus course and we strongly recommend students to attend the campus activities.  Also, for the sprint demos, at least one member from the group must attend to do the presentation.

  • Lectures and Tutorials:

    • Goals: Teach students with the technical background on using the API and technologies required for the project.
    • Each tutorials length will vary depending on the topic. We have four main topics that must be covered via lectures. They are:
      • Using the SmartCar API and the SMCE Emulator.
      • Connecting the SmartCar and make it communicate with other devices.
      • The basics of C++ needed to use the API and libraries
      • The importance and how to use Continuous Integration in your project

  • Sprint Demo and Presentation:

    • Goals: Sharing knowledge and experiences in the project. Evaluate correctness and completeness of the development process and its product.
    • 4 minute presentation to the class showing results of the Sprint.
      • One slide summarizing the features completed and/or demo of the newly delivered features in the car or in the emulator.
    • Students should attend the presentation for all groups.
    • At least one member should do the presentation.
    • Focus on the product

  • Every week: Weekly standup

    • Goals: Check the progress of each group. Identify development risks early to support the group in overcoming them.
    • This is a 15 minutes session scheduled in advance with the TA and with a fixed time.
    • Group should present a 1-2-slide presentation to the TAs answering the questions:
      • What is the progress since last week?
      • What are the main obstacles hindering our progress?
    • All members should attend the weekly stand-up. Students that miss the meetings must provide a reason to the TA.

You can find the schedule of lectures in TimeEdit

Course Description

The course introduces a project, based on a problem based learning approach, guided by realistic and challenging customer requirements. The project course is organized as group work. Based on an idea, the students shall deliver a requirement and design specification of the system to be developed. The system, that consist of an already existing hardware and software platform shall be controlled by software.

The students shall implement the software part based on the design, test and demonstrate the results. In this course the students learn to analyze the demands of a customer, capture these in a software requirements specification including quality requirements, and to design and develop software from this analysis. The students train their skills in requirements analysis, software design, quality analysis, programming, and testing.

During the work the students will utilize modern techniques, methods and approaches for system and software development and project management. The system aspects integrated in the software implementation will be in the focus of the project.

Project Goal and Task

Your team is tasked to create a proof-of-concept application, for an automotive business case. You are expected to integrate software with hardware on a system running on multiple platforms, e.g. the car microcontroller and a smartphone or a PC.

To expedite the development of your system, you should take advantage of open source software. The Smartcar library enables its users to control RC and autonomous vehicles. Additionally, since the availability of physical components is limited an emulator was created to facilitate distributed and remote development.

You will be assigned to a team of developers (fellow students) and tasked to implement a system which will satisfy the business needs of your customer (Dimitris or Francisco). You will be expected to work in an Agile manner, abiding by software engineering best practices. On a bi-weekly basis, there will be sprint demos in front of the classroom as well as planning meetings with your Product Owner (teaching assistant) and customer.

Learning outcomes

In this course the students will learn how to design and develop software, and to manage projects, using the following principles:

  • Define software in a system context
  • Describe system requirements, system and software design, and relations between the requirements and software design
  • Organize software development teams and conduct software development projects,
    using modern software engineering methodologies such as agile development
  • Elicit, analyze, and document requirements in the form of a requirements specification
  • Design software and document outcome of design work
  • Implement software according to a documented software design
  • Reflect on integration between software and non-software components
  • Evaluate traceability between requirements, design, and implementation artifacts

After passing the course, the students will be able to participate in agile projects, use test and quality driven development, analyze the software and system requirements.

Teaching Assistants (TA)

Teaching assistants will act as product owners (PO) to the project groups. Each group will be assigned to 2 teaching assistants for redundancy, as shown below:

The Teaching Assistants distribution per group and schedule for the weekly stand-up are as follows:

  • During Wednesdays, the weekly stand-up will happen in Alfons.
  • During Thursdays, the weekly stand-up will happen in the Svea building. Please contact your TA for the specific room.

Important: The whole group should attend the weekly stand-up. Members and TAs can join on campus or remotely, but we strongly recommend campus attendance. If a member cannot show up, their absence must be justified.

Group TA Weekday Time
Group 01 Krasen, Kamila, Leila Thursday 11:00-11:20
Group 02 Maja, Alexandre, Malik Wednesday 14:50-15:10
Group 03 Noor, Renyuan Wednesday 13:00-13:20
Group 04 Krasen, Kamila Thursday 09:00-09:20
Group 05 Maja, Alexandre, Leila Wednesday 13:00-13:20
Group 06 Noor, Renyuan, Malik Wednesday 13:50-14:10
Group 07 Krasen, Kamila, Malik Thursday 09:30-09:50
Group 08 Maja, Alexandre Wednesday 13:55-14.15
Group 09 Noor, Renyuan, Leila Wednesday 14:40-15:00
Group 10 Krasen, Kamila, Leila Thursday 11:30-11:50
Group 11 Maja, Alexandre, Malik Wednesday 15:10-15:30
Group 12 Noor, Renyuan Wednesday 13:25-13:45
Group 13 Krasen, Kamila Thursday 10:00-10:20
Group 14 Maja, Alexandre, Leila Wednesday 13:20-13:40
Group 15 Noor, Renyuan, Malik Wednesday 14:15-14:35
Group 16 Krasen, Kamila, Malik Thursday 10:30-10:50
Group 17 Maja, Alexandre Wednesday 14:15-14:35

 

Examination and Grading Criteria

The course will be examined by (i) the delivered system, (ii) a group report,  (iii) a personal report, (iv) active participation throughout the course and the group activities. As a group, the following elements will be taken into consideration to achieve the grade below:

  • 3 (pass): All requirements below are necessary to pass the course.
      • Timely delivery of all submissions (including bi-weekly backlog refinement tasks)
      • Two-tier system where a client with a GUI receives/sends data to/from the miniature vehicle that provides adequate value to the customer
      • Basic requirements tracing (i.e. Requirements are documented and one can understand how they are implemented via the code commits)
      • Continuous Integration that ensures newly introduced changes do not break at least two components of the system
        • The idea is that a very basic automated sanity check of what you commit should be performed.
  • 4 (pass with merit): All requirements to pass (3) + all requirements below:
    • Accurate, valuable and continuously improving Features / Requirements / Milestones. This is assessed by manual inspection of your Github repo and its wiki pages
    • Traceability from requirements to user stories and code commits and vice versa for the majority of your work. Assessed by the links between commits, pull requests, user stories and milestone and wiki pages in the Github repo.
    • Pristine development process, documentation, modelling, work tracking. This is assessed by the artefacts used in the process and documented in the Github repo (e.g., kanban boards, summary of weekly stand-up, diagrams, etc.)
  • 5 (pass with distinction): All requirements to pass with merit + one of the two requirements below.
    • Technically advanced deliverable system. This is assessed by inspection of your code quality (readability, coupling, etc.) and product quality (e.g., quality of the demo and variety of features).
    • Automated tests for a part of your system. This is assessed by the quality of the test cases such as failure revealing capability or code coverage.

Grading is individual but your group's performance will be used as a baseline for your personal grade. For example, you are deemed to have exceeded the expectations you may receive a better grade than your group. Similarly, if your performance is poor then you could receive a worse grade or even fail.

We try to keep the criteria for grading as transparent and objective as possible. These include, but are not limited to:

  • Your technical contributions to the product.
    • Measured by the committed code, produced documents, authored documentation, created stories and milestones, etc.
    • You must write some code to pass the course, but only code will not be enough.
  • How well you facilitated and were engaged into the development process
    • Measured by the peer reviews, teaching assistant input, valuable participation in meetings etc
  • Individual submissions
    • Measured by the quality and timeliness of the submitted material (e.g. final report)

Re-examination format:

In case a student does not pass the assignment, he or she will receive two re-examination opportunities. The re-examination is an individual assignment where the student will be given a set of tasks to complete related to their project. Those tasks are related to their group project, such as specific features to complete, or parts of their report to rewrite or correct. In case, no project was submitted in the first round, or the student did not follow the course's scheduled activities and assignments, he or she will need to do the project alone.

During the re-examination, the student must rely on the course material and content from lectures or contact the teacher for question. There is no TA support for the re-examination, as the TAs are scheduled to work during the course period. For the re-examination, there are no weekly stand-up or sprint demos, the student is evaluated based on the submission provided by the deadline.

In case the student fails during the first re-examination he or she will be given more feedback to help them complete their project tasks which they can submit before the re-examination 2 deadline. In case a student fails both re-examination opportunities, he or she needs to retake the course during its next instance (Spring 2023). The deadlines for the re-examination are:

  • Re-examination 1: 2022-08-15
  • Re-examination 2: 2022-09-19

 

Tools used in the Course

1- Github:

In the DIT113 course we will fully utilise GitHub's tracing features, specifically the issues , the labels , the milestones , the wiki pages and the project board.

  • Issues
    • Issues will be representing bugs or user stories. They can be referenced via commit messages.
  • Labels
    • Labels will be representing sprints. For example, a label called "Sprint 2" should be added to all stories planned to be worked on during Sprint 2. Using labels for other purposes (e.g. showing what type of work is included in an issue) is also allowed.
  • Milestones
    • Milestones should be representing features and each story should be added to a feature/milestone. They should contain a short high-level description and a link to a version controlled wiki page with the full-set of related requirements. A story can only belong to one sprint, as a story can only belong to one feature. If you think that a story belongs to two features then it is very possible that you need to slice down your features and their common part to be a new feature of its own.
  • Wiki pages
    • Wiki pages should be used to describe features/milestones and link back to them. They can also optionally be used for other documentation purposes.
  • Project board
    • The project board should be used for illustrating the current progress of the team.

The above setup enables the development team to have two-way traceability between the code and the requirements as well as enable every stakeholder to monitor the current progress.

2- Arduino IDE:

The development team will have to program the microcontroller found on the miniature vehicle. In order to do so, it is suggested they use the Arduino IDE . A good alternative is PlatformIO on VSCode .

Course summary:

Date Details Due