About the course


Software Engineering

(for Intelligent Distributed Systems)

A.Y. 2024/2025

Giovanni Ciatto


Compiled on: 2025-06-30 — printable version

back

Teacher

Virtuale

https://virtuale.unibo.it/course/view.php?id=63902

Students must enroll

Organization

  • Tuesdays (14:30-17:30) in lab 4.2

    • you may use the PCs in the lab, or bring your laptops

  • Thursdays (11:00-13:00) in lab 3.1

    • you may use the PCs in the lab, or bring your laptops

  • Virtual room on Teams is just for the chat

    • lectures will be held in person
    • no blended lectures by default

I will do my best follow the Italian convention “quarto d’ora accademico”
(i.e., starting 15 minutes after the scheduled time to allow people to accommodate)

  • please try to enter the room on time

What is the course about? (pt. 1)

(Only insights here, there will be a dedicated lecture on this topic)

  • Put it simply, software engineering is about producing working software products

    • not only writing code, but also
      1. understanding the requirements,
      2. designing the product,
      3. testing it,
      4. deploying it,
      5. and maintaining it

  • In particular, nowadays, software engineering must also deal with:

    • distribution, i.e. multiple software components interconnected over the Internet
    • artificial intelligence, i.e. software components that may exhibit human-like capabilities to some extent
      • e.g. understanding natural language, recognizing objects, making decisions, learning from data, etc.

What is the course about? (pt. 2)

  • At the end of the course…

    • … you shall have a clear understanding on the whole process of software engineering
    • … you should be able to set up and design a software project
    • … you should be able to reason about the quality of a software project
    • … you should have a clear understanding of brings cost or value in a software project
    • … you will not be required to be an expert developer

  • To reach that goal, we shall follow a learn-by-doing approach

Exam (overview)

  • The exam consists of: written test and a (optionally) a project work

    • the written test is mandatory and the maximum score is 27/30
    • the project work is optional and the maximum score is 6/30
      • students can choose to skip this part, but they will not be able to reach the maximum score (30/30)
    • the final score is the sum of the two scores, capped to 30/30

  • The rationale is as follows:

    1. the written test is aimed at assessing the theoretical knowledge of the student
    2. the project work is aimed at assessing the practical knowledge of the student

  • The written test consists of a closed-book exam with open-ended questions

    • exam is in presence, with no internet connection, and with a time limit
    • there will be 6 opportunities to take the exam along the year, roughly 4 in the summer session and 2 in the winter session

  • The project work consists of an individual or group effort where

    1. the student(s) develop a software artifact and write a report on the development process
    2. and finally they will present and discuss the project work with the teacher in an oral discussion
      • the oral discussion will be held upon appointment with the teacher, possibly remotely

Details about the written test (pt. 1)

  • There will be 6 calls for the written tests along the academic year

    • roughly in June, July, August, September, January, and February

  • The exact dates and locations of the exams will be made available on AlmaEsami, where you will be able to register for exam calls

    • registration is strictly necessary for participation (no registration, no exam)
    • dates are not negotiable, so please plan your presence accordingly
    • the amount of seats for each exam call is limited (by the capacity of the room)
      • so, please register to the exam call only if you are sure you will attend

  • The written test will be in presence, no exception

    • if you are not available for one of the exam calls, you will have to wait for the next one

  • The written test should be conducted on the University’s computers, but may fall back on paper in case of technical issues

    • the day of the exam you must bring:
      1. your ID card or passport to prove your identity
      2. a pen (possibly black or blue)

Details about the written test (pt. 2)

  • The written test is closed-book, with open-ended questions

    • any attempt to cheat will result in the immediate failure of the exam

  • The list of potential questions that the written test may contain is available here

    • further questions may be appended during the course

  • During the exam, you will be subject to the following restrictions:

    • no communication with other people, no internet connection, no phone usage, no access to notes or books
    • no leaving the room before the end of the exam
    • you can renounce to the exam at any time (implies that your test will not be evaluated)

  • Results will be available on AlmaEsami within a few days from the exam

    • in case of failure or unsatisfying results, you will be able to retry in the next call
    • concluding the test without renouncing implies that any prior exam result will be overwritten

  • Students should inform the teacher of any provable special needs or disabilities that may require special arrangements for the exam

    • please don’t do this at the last moment

  • Upon reaching a successful result ($\geq$ 18/30), it is up the student to:

    1. inform the teacher that they intend to skip the project work and accept the result, hence finalizing the exam
    2. or just keep working on the project work, hence postponing the finalization of the exam

Details about the project work

  • The project work is optional, but it is strongly recommended

    • it is a great opportunity to apply the concepts learned during the course
    • it is a great opportunity to practice with teamwork

  • The project work can be done either individually or in groups of up to 3 students

    • groups shall be declared on Virtuale by the students before starting the project work
    • the groups shall be stable and unchangeable during the project work
      • group member cannot be added/removed after the group’s project idea has been approved
    • the members of the group shall present their project work together

  • The evaluation of the project work will focus not only on the outcome (the software artifact) but also on the process (the report)

    • the software artifact can be small and simple…
    • … yet the report should describe all the aspects of the software engineering process presented in the course
    • the report should be written in English

Project work’s activity flow

(Starting after passing the written test is recommended by not mandatory)

  1. Proposal: students propose a project theme/topic/concept on the Project work forum

    • in case of group project, the group members should be declared here (names + emails)

  2. Approval: the teacher may provide feedback, suggest changes/strategies, or set requirements, and eventually approve the proposal

  3. Repositories creation: students create a GitHub organization and grant the teacher access to it

    • granting admin access to the teacher’s GitHub account (username: gciatto)
    • the organization should be named unibo-dtm-se-2425-YOUR_PROJECT_NAME
    • the organization should contain (at least) one repository for the software artifact and another for the report

  4. Development: students develop the software artifact and write the report

    • the report should be written in Markdown and match this template
    • the report should be written in English

  5. Submission: students submit their GitHub organization URL on the Project work forum and ask an appointment for the discussion

    • submission is not retractable
    • appointments may be scheduled in any moment of the academic year…
    • … of course taking the teachers’ availability into account

  6. Discussion: students present and discuss their project work with the teacher

    • the discussion will be held in English
    • remote discussion may be possible via Microsoft Teams, in case of well-justified needs
    • the discussion will include all the members of the group

Details about the software artifact

If you decide to do the project work, you will have to develop a software artifact to prove your capability to carry out a software project

  • The software to be developed can range from simple to complex, depending on your familiarity with development

    • proposing an idea that you’re able to complete is part of the game
      • so do not over-promise!

  • Simple or complex, the point of the software artifact is to demonstrate your understanding of the software engineering process

    • so, you should encompass and document all the phases of the software development process
      • e.g. the requirements analysis, the design, the implementation, the testing, the deployment, and the maintenance of the software artifact

  • The software artifact can be developed in any programming language of choice

    • we recommend using Python

  • Exploitation of Git, GitHub, and version control is important and will be evaluated

  • Templates and guidelines for the source code will be provided on the GitHub organization of the course

Details about the software artifact’s report (pt. 1)

The report (documenting the process) is as important as the code it describes (the outcome)

  • The report must be a document describing the design and development processes of the software artifact

    • possibly speculating on the aspects of development which have not been completed

  • The report is the entry point for evaluating the project work

    • it should detail what has been done and what has not been done (and why) …
    • … w.r.t. all the aspects of software engineering presented in the course

  • Technically speaking, the report should be written in Markdown and should match this template

    • so that it can be rendered as a static Web page, via GitHub Pages (example here)

Details about the software artifact’s report (pt. 2)

  1. Title + Authors List + Abstract
  2. [opt] Disclaimers (e.g., conflicts of interests, usage of AI, etc.)
  3. Concept: short description of the idea behind the software being developed
  4. Requirements: requirements + user stories + use cases + acceptance criteria
  5. Design: overall architecture, structure, interaction, behaviour, etc.
  6. Development: conventions on the usage of DVCS, other relevant implementation details
  7. Validation: description of the testing activities, including unit tests, integration tests, etc.
  8. Release: how to build, package, and release the software + details about licenses
  9. Deployment: how to deploy the software and/or how to install and run it
  10. CI/CD: description of the CI/CD pipelines, if any
  11. User guide: how to use the software
  12. Developer guide: how to contribute to the software
  13. Self-evaluation: what went well, what went wrong, what could be improved (1 section per group member)
  14. Future works: what could be done in the future to improve the software

Scoring and Grading

  • The written test is evaluated numerically, after the written test is over:

    • each question is assigned a maximum score
    • each student’s answers is given a score from 0 to the maximum
    • the resulting score is the sum of the scores of all the answers, normalized to 27

  • Project work is evaluated once per group

    1. an overall score is assigned to the project work, hence to the group
    2. individual score are then adjusted based on the individual contributions to the project work
    3. each individual score is then normalized to 6

  • Assessing a software project is not trivial, and subjectivity is unavoidable

  • The final score is the sum of the normalized scores of the written test and the project work

    • as the maximum final score is 33/30, the final mark is capped to 30/30
    • if no project work is done, and the maximum final mark is 27/30
    • if the project work is perfect (i.e., 6/6), any written test score $\geq$ 24/30 will result in a final mark of 30/30
    • the final mark 30L (cum laude) is assigned when the final mark (before capping) is above 30/30

What project work may you choose? (pt. 1)

  • A video game, e.g. a remake of classical games such as Pong, Arkanoid, Pacman, Snake, Tetris, etc., as well as board or card games

    • easier if you use a game engine, e.g. PyGame
    • offline, and single player much easier than online, and multiplayer
    • turn-based much easier than real-time
    • 2D much easier than 3D

  • A web application providing some useful functionality to multiple users

    • e.g. a to-do list, a chat, a forum, a blog, a social network, etc.
    • it is totally OK to take inspiration from existing services / Web apps
    • better to use ad-hoc frameworks for the backend (e.g. Flask, Django, etc.)
    • as well as ad-hoc frameworks for the frontend (e.g. React, Vue, etc.)

  • A desktop application providing some useful functionality to a single user

    • e.g. a function visualizer, a notebook, a music player, a photo editor, etc.
    • better to use ad-hoc frameworks for the GUI (e.g. Kivy, PyQt, etc.)

  • A command-line application providing some useful functionality to developers

    • e.g. a clone of tool such as jq, curl
    • e.g. a tool for generating the text of an exam given a pool of questions in CSV

  • A library for doing something useful

    • e.g. drawing fractals, matrix computations, etc.
    • e.g. a clone of (a subset of) relevant Python libraries (e.g. NumPy, SciPy, Pandas, Matplotlib)

What project work may you choose? (pt. 2)

Examples

Technical Requirements for the Course

  • An account on GitHub (create one if missing)

    • possibly, based on your university email address
      • if you already have a GitHub account, please add it as the secondary email address
    • optionally, with a profile picture showing your face or a recognizable avatar
    • possibly, with a professional username (e.g., john-doe instead of johnny-the-king)

  • A working installation of Python

    • possibly version 3.11.x

  • A working installation of Git

  • A working installation of Visual Studio Code

  • [Useful] A working installation of PyCharm

    • the community edition is free, and it’s enough

About recordings

  • Lectures are recorded by default

    • recordings will be available on Virtuale, in the Panopto section

  • During the course, access to recordings is by-request only (send an email to the teacher)

    • only well motivated requests will be accepted (health issues, family issues, transport issues, etc.)

  • At the end of the course, the recordings will be made available to all students

  • Recordings are not a substitute for attending the lectures

    • they are a complementary tool to support the learning process

  • Recordings will be made following a best-effort approach

    • technical issues may arise, and some lectures may not be recorded
    • recordings may be incomplete, or contain defects

About the slides

  • Slides and other materials are available on Virtuale and GitHub

    • they are produced along the way, so they may not be available in advance, or change abruptly overnight
    • also, please re-download / re-load them before each class

  • The online version of the slides is updated automatically

    • you will always see the latest version when you load the page

  • If you need to print the slides, please use the printable version of the slides, which is commonly available in the first slide of each lecture

About the exploitation of Generative AI in the course

  • If you use Generative AI tool (e.g. ChatGPT, Copilot, etc.) in writing your code or report, this is fine

  • But you must be transparent about what AI tool you used and why

    • you must declare that by means of a disclaimer at the beginning of your report, e.g.:

      “During the preparation of this work the author(s) used [NAME TOOL / SERVICE] in order to [REASON]. 
After using this tool/service, 
the author(s) reviewed and edited the content as needed 
and take(s) full responsibility for the content of the final report/artifact.”

  • If the disclaimer is not present in your report, this will be interpreted as “no Generative AI was used at all”

If I have the impression that some student has blindly copy-pasted content (from either AI chat, or the slides, or some book) without understanding it, I will set up an oral examination and ask further questions to investigate whether the student has actually understood what they wrote or not

Lecture is Over


Compiled on: 2025-06-30 — printable version

back to ToC