Software Engineering

(for Intelligent Distributed Systems)

A.Y. 2023/2024



Compiled on: 2024-05-07 — printable version

back

Teachers

Module “Principles and Methods”

teacher: Giovanni Ciatto, Junior assistant professor (RTD-A)

email: giovanni.ciatto@unibo.it

Module “Engineering of Distributed Systems and Enterprise Applications”

teacher: Alessandro Ricci, Associate Professor

email: a.ricci@unibo.it

Remarks

office hours dynamic, send an email to the teachers for an appointment

Prof. Giovanni Ciatto is responsible for the course, contact him for any aspect related to the course or the exam

Virtuale

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

Students must enroll

Organization

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

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

  • Thursdays (11:00-13:00) in room 2.13

    • please, bring your laptops

  • Virtual room on Teams is just for the chat

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

We will do our 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 a project work to be produced and presented by students

  • The project work consists of

    1. the source code of a software artifact and
    2. a textual report describing the design and development processes of the artifact itself

  • The report is more important than the source code

    • the code could be a simple, pissibly incomplete, prototype or stub

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

    • we recommend doing it in groups, to practice with teamwork
    • individual contributions will be assessed via DVCS

  • Students are encouraged to propose project works themes/topics/concepts

    • we may help in refining initial proposals

  • We incentivise students to complete their project work as soon as possible

    • better if within the next exam session
    • possibly within the same academic year

Exam (workflow)

  1. Proposal: students propose a project theme/topic/concept on Virtuale

    • in case of group project, the group members should be declared here

  2. Approval: the teacher will provide feedback and possibly suggest changes/strategies or set requirements

  3. Repository creation: students create a GitHub repository and share it with the teacher

    • granting admin access to the teacher’s GitHub account (username: gciatto)

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

    • the report should be written in Markdown and stored in the repository (e.g. README.md)
    • the report should be written in English

  5. Submission: students submit the repository URL on Virtuale and ask an appointment for the discussion

    • submission is not retractable
    • appoitments 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

Exam (the software artifact)

We don’t really require you to be expert developers, nor to complete the development of a software artifact

  • The software artifact can be a simple prototype or stub, possibly incomplete

    • of course, completeness will be rewarded

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

    • we recommend using Python

  • The software arftifact is mostly aimed at demostrating students’ understanding of the many aspects of software engineering, so that’s what we will mostly evaluate

    • e.g., analysing requirements, modelling a solution, designing interfaces, writing tests, managing dependencies, automating builds, tracking development, versioning, etc.

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

  • Templates and guidelines for the source code will be provided on Virtuale

Exam (the report)

The report is more important than the software artifact

  • 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

  • Templates and guidelines for the report will be provided on Virtuale

Exam (the evaluation)

  • Project work is evaluated once per group

    1. an overall mark is assigned to the project work, hence to the group
    2. individual marks are then adjusted based on the individual contributions to the project work

  • Roughly speaking the evaluation of the project work will be based on the following aspects:

    • the quality of the report and the presentation
    • the precision of requirements elicitation and analysis
    • the clarity of the design documentation
    • the presence of tests and the meaningfulness of the testing process
    • the correct exploitation of
      1. version control systems
      2. build automation systems
      3. continuous integration systems
    • the adequate management of dependencies, versions, and licenses

  • Extra points may be granted in case of (details on Virtuale):

    • early submission
    • completeness of the software artifact
    • quality of the software artifact

Exam (examples of project works)

  1. A web, mobile, or desktop App, possibly involving some remote service

    • e.g., a simple video game (involving online multiplayer)
    • e.g., a calculator (involving a remote computation for advanced operations)
    • e.g., an instant messaging application
    • e.g., a note-taking, to-do list, calendar app (involving cloud storage)
    • e.g., a weather forecast (relying on pre-existing forecasting services)
    • e.g., a news aggregator (possibly scraping news from the web)

  2. A startup idea, possibly involving some remote service

    • e.g., booking and managing appointments for professionals
    • e.g., general all-you-can-eat menus for restaurants
    • e.g., food delivery service
    • e.g., a platform for sharing and renting cars, bikes, rooms, etc.

  3. A toolkit supporting some (data?) processing or anlysis activity (with an output)

    • e.g., data analysis on social media, or GitHub
    • e.g., a tool for systematic literature reviews
    • e.g., a tool for automated document difference (possibly relying on third-party Web services)
    • e.g., a tool generating datasets via LLM

Example proposal 1

An analysis of developer distress on social media

  • Type: mixed
  • Group size: 2-4

This activity consists in the analysis (via scraping / API) of social media posts that indicate developers’ distress, and on a classification of their origin. Sources may include Twitter, Reddit, Stack Overlow, etc.

Notes:

  • It might benefit of pre-existing skills in sentiment analysis

Example proposal 2

How are successful GitHub workflows organized?

  • Type: mixed
  • Group size: 2-4

This activity consists in the analysis (via API) of some interesting relationships that could be found on GitHub, with the goal of investigating developer’s habits and their evolution with time.

Some questions of interests may be:

  • do the developer count relate to the branch count?
  • do the presence of merge commits relate to the “success” of the project?

Notes:

  • Identifying developers univocally may not be so easy
  • More metrics could be devised
  • Project success should be measured somehow but it is not trivial at all

Example proposal 3

Private clouds with Kubernetes: a complete setup

  • Type: project
  • Group size: 1-2

This activity consists in the construction of a working private cloud based on Kubernetes. Required features:

  • Resilience to the loss of a master node (multi-master)
  • Ability to run services (long-lived processes) or tasks (short-lived processes)
  • Resource control and allocation via RBAC

Notes:

  • Compute servers will be provided by the teacher
  • Setup details should be collected into a guide
  • Previous experience with Kubernetes and containerization is helpful

Example proposal 4

Automated document difference

  • Type: project
  • Group size: 1-2

The goal of this project is to build a library leveraging the web API of Draftable to produce differential documents. The software can be developed in any language of choice, and must feature appropriate automation (build) and get published on official distribution channels.

The library should be exercised with a GitHub action.

Notes:

  • The API key for the Draftable service will be provided by the teacher
  • The language should be agreed with the teacher
    • Python, Java, Scala, Kotlin, Rust, and Ruby are all valid picks, other should be discussed

Example proposal 5

A tool to support systematic literature reviews

  • Type: project
  • Group size: 1-2

The goal of this project is to build a software that queries multiple sources in the literature (Google Scholar, Pubmed, Scopus, Web of Science, Arxiv…) with a specific query, supporting the scientific investigation of existing results. The software can be developed in any language of choice, and must feature appropriate automation (build) and get published on official distribution channels.

Notes:

  • The language should be agreed with the teacher
    • Python, Java, Scala, Kotlin, Rust, and Ruby are all valid picks, other should be discussed

Techical Requirements

  • 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

  • [Recommended] A working installation of PyCharm

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

Module “Principles and Methods”

held by Prof. Giovanni Ciatto

Remarks

  • Lectures are recorded by default

    • recordings will be available on Virtuale
    • access to recordings is by-request only (send an email to the teacher)

  • Slides and other materials are available on Virtuale

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

Module contents and action plan

(order of lectures is not final)

  1. Introduction to software engineering
  2. Preliminary notions for Software Development
  3. Decentralized version control (with git) and team organization
  4. QA, testing, TDD, reproducibility and replicability (examples in Python)
  5. Build automation, packaging, and release (examples with Poetry)
  6. Versioning, Conventional Commit
  7. Continuous integration (examples with GitHub Actions)
  8. Licensing

Extras