General outline

Introduction

For this course there are two projects to select from. We provide their outline on the respective pages, leaving many parts unspecified and free for interpretation. Completing and fully specifying these parts is your first task. After this is done, another team picks up the design, and actually implements it in C++, while you pick up the other team's design and implement it. This way, everyone will ultimately work with both projects, but with different roles.

Teams

For this project teams of 2-4 people are formed. The teams are split into two groups. The first group will work on the specification and design for the first project and the second group will do the same for the second project. Afterwards, the groups will swap projects and so each team will implement the specifications that some team from another group has designed.

Please register your team's name and members on Moodle before February 25th.

Process

The general process is the same no matter which project a team was assigned to. The work on the project has to be done in a GitLab repository so that it's easier for TAs to track progress. We provide a template repository that you can clone to get started.

All documents that you should prepare as deliverables must be in a commonly used format (PDF, or PNG for images). You are free to use any tool (e.g. LibreOffice, Google Docs, Notepad, etc.), as long as the end result is converted to PDF.

To track your process on your own, it is recommended to use GitLab Issues, Boards and Milestones functionality. For more information refer to the documentation:

• Boards: https://docs.gitlab.com/ee/user/project/issue_board.html
• Milestones: https://docs.gitlab.com/ee/user/project/milestones/

Communication

For asking questions that might be of interest to all teams, please use the public Moodle forum.

For private questions that only concern your team's situation, send us a email. Please format your email subject as follows so we don't lose your email: [SoftwareEngineering][TEAM_NAME] Subject.

Please discuss the issue within your team first before sending us an email.

Submission

In order to submit projects for grading you just have to upload your last commit (before the correspondent deadline) as a release. For this purpose gitlab offers the Releases functionality. For the first two phases please upload the two documents as .pdf files.

For the lecturers group to see the team's work, you need to add us as project members individually with "Reporter" level, see this Moodle thread for details (this needs to be done once).

Projects

There are two projects you will work on in this course. We do not expect you to have significant background knowledge about the projects' domains: you should focus on the software engineering process, and not on being as realistic as possible.

CAS (Computer Algebra System)

A console application for performing algebra calculations, in the spirit of MATLAB/Octave, Maple, R, etc. See the description.

Health Monitor

An event handling pipeline connecting various health sensors to hospital systems. See the description.

Grading

Pass/Fail. Quality of the implementation is not a big factor, excluding extreme cases. What is important is that you devote enough time, follow through the whole process, keep to the deadlines, and provide all required deliverables. In order to check this, we will look at your GitLab repositories, so make sure to use them as a cornerstone for organizing your work.

CAS

A computer algebra system (CAS) is a mathematical application that can manipulate mathematical expressions in a way similar to the traditional manual computations of mathematicians and scientists.

Your scientist friends are tired of using existing CAS software and computing things on paper and so they decided to ask you, a software engineering dream-team, to create one for them.

They know that there are two categories of CAS: specialized and general-purpose. For now they request a general-purpose one so that it can be later extended to various fields of their interest.

After reading through the Wikipedia article, you know that are certain common pieces of functionality for a general-purpose CAS:

• a user interface allowing to enter and display mathematical formulas, (This is needed)

• a programming language and an interpreter (the result of a computation commonly has an unpredictable form and an unpredictable size; therefore user intervention is frequently needed), (This is needed)

• a simplifier, which is a rewrite system for simplifying mathematics formulas, (This is extra)

• a memory manager, including a garbage collector, needed by the huge size of the intermediate data, which may appear during a computation, (Don't do this)

• an arbitrary-precision arithmetic, needed by the huge size of the integers that may occur, (This is extra)

• a large library of mathematical algorithms and special functions. (Just a fair amount of functions is fine, e.g. 10)

Implementing all of these would be infeasible in the timescope of this course, so you need to carefully consider which parts are crucial, and what is your view on how they should look like. We have included some suggestions in bold above.

Deliverable 1 - Software Requirements Specification (SRS)

This document has to contain ~12 functional and ~5 non-functional software requirements. It also has to contain 4 scenarios in a format described during the lecture.

More information about the first deliverable in general, no matter the project, and the feedback can be found here. The template that you should use can be found here.

Here are some examples of possible requirements:

• It supports addition, multiplication, subtraction, division, modulo, power.
• It supports nested expressions using parenthesis.
• It supports variable assignment and later use in expressions.
• It supports trigonometric functions.
• It supports Matrix operations.
• It can be configured via a .ini file.

Deliverable 2 - Software Design Specification (SDS)

For this phase you will design the architecture of your liking that will satisfy the requirements of the first deliverable.

More information about the second deliverable in general, no matter the project, and the feedback can be found here. The template that you should use can be found here.

One architecture pattern that you might consider is the MVC (Model-View-Controller) pattern. The console is the view, the interpreter is the controller and the computational kernel with the stored data structures is the model.

Deliverable 3 - Implementation

For this phase you will implement the design that the other team has prepared for you.

As a guideline, your implementation should contain at most around 800-1000 lines of code. This is not a requirement, but a guideline: if you feel you need more, you probably need to rethink your implementation and follow the DRY (don't repeat yourself) principle.

Some tips you might find helpful:

• For parsing the input, a simple recursive descent parser should be enough.

• If you use matrices it is recommended that all your inputs are matrices (have the same type in computations) as for example in older versions of MATLAB where even the scalars had dimensions.

• If you want to support different types of any kind (scalar vs. matrix, integer vs. floating-point), you will probably find C++ templates very helpful. Before deciding to do this, you should make sure enough people in your team are comfortable with templates.

Deliverable 4 - Testing report

See here.

Health Monitor Project

A health monitor system monitors the devices of each (candidate) patient in a hospital, extracts and stores information regarding one or more patients from sensor devices. This information is used for controlling some actuators that help improve the health of the patient or alert the personnel responsible in case of some events. Each device (sensor or actuator) communicates with the monitor system via TCP sockets, the communication protocol (format of communication data) and possible communication scenarios are given below in section Device Communication.

The purpose of this project is to design the core of this architecture: a monitor that accepts input from devices, processes it, and then possibly sends commands to some actuator devices. The image below depicts the communication flow between the devices and the Health Monitor application.

Figure 1: The communication network topology of such a system. Each device can send or receive data from the system.

The complexity of creating such an architecture from scratch exceeds what we can do as a part of this course. So, instead of using the topology above where multiple devices communicate with the system, the image below presents a simplified approach.

Figure 2: The simulator and the Health Monitor communication topology. There is one stream for input to the Health monitor and one stream for output. All sensor measurements use the Health Monitor input stream and all the actuator commands use the Health Monitor output stream.

The simulator has been already been implemented and can be found in this link. Information on how to use it is provided both in Device Communication below and in the repository itself.

Rather than having a separate link/stream between each device and the monitor, the simulator only uses two streams (input and output): it sends all information (measurements) from potentially multiple simulated devices via the monitor input stream, and reads commands to simulated actuators via the output stream.

In order to distinguish between multiple simulated devices, every message sent and received must contain a unique id of some device. The monitor, for example, can use this id to call different handler functions for messages from different sensors.

Main Focus

The main focus of the project should be to design and implement an application that parses incoming messages messages from sensors and potentially stores them. Also, it has rules (logic) of your design which specify what commands should be sent to which actuators and when. As such, you should specify in the requirements what are the sensor devices that the Health Monitor system reads data from, what are the actuators, what commands do the actuators accept, and the logic of trigerring these commands. Then you should design how the system will actually handle the input and use the the logic to produce the required outputs.

For example:

If a skin thermometer sensor is over 40 degrees Celsius threshold for 5 minutes and the nurse alarm for this patient has not been on since the thermometer passed this threshold, then set nurse alarm on for this patient.

Device communication

The devices communicate with the monitor via 2 TCP ports. One port handles the incoming messages from the sensors, and the other is used to send commands to the actuators. You have to decide on the port numbers by yourself. The messages have a certain format as can be seen below.

Sensor messages have the general format of:

{
  "deviceId": number,
  "deviceDescription": The sensor device's description string,
  "data": the measurement of the sensor
}

Actuator messages have the format:

{
  "deviceId": number,
  "state": number
}

All messages are JSON objects.

Both sensors and actuators are simulated by the same tool. The simulated sensors and actuators are configured via a JSON file. Configuration options include the type of measurements, their range, frequency, etc.

The sensors can be thought of as TCP clients and the actuators as TCP servers. The ports they use can be also configured in the same JSON configuration file. For more detailed information, refer to the simulator tool repo.

From the C++ side there also a library which can be useful for handling the communication with the simulator from the HealthMonitor. It is a renewal of an educational version of the Berkeley C socket API for TCP and UDP. It can be found in this repository. It can be easily used for this project. Details and descriptions can be found in the link. Also there is an examples folder which has various examples of how to use this library to handle TCP communication in different ways.

The simulator

Output of each device

Below there are example configurations for possible sensor device outputs and example messages coming from the simulator.

1. Heart rate: One integer number varying each 5 seconds. Configuration:

   {
     "deviceId": 0,
     "deviceDescription": "HeartRate",
     "outputType": "int",
     "range": [0, 400],
     "timeInterval": 5
   }
   

   Message:

   { "deviceId": 1, "deviceDescription": "HeartRate", "data": 72 }
   

2. Blood Systolic, Diastolic Pressure: Two integer number varying each 5 seconds.

Configurations:

[
  {
    "deviceId": 0,
    "deviceDescription": "BloodSystolic",
    "outputType": "int",
    "range": [0, 200],
    "timeInterval": 5
  },
  {
    "deviceId": 1,
    "deviceDescription": "BloodDiastolic",
    "outputType": "int",
    "range": [0, 200],
    "timeInterval": 5
  }
]

Messages:

   {'deviceId': 0, 'deviceDescription': 'BloodSystolic', 'data': 72}
   {'deviceId': 1, 'deviceDescription': 'BloodDiastolic', 'data': 102}

3. Temperature(Celsius): An integer number changing every minute.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Thermometer",
  "outputType": "integer",
  "range": [0, 100],
  "timeInterval": 60
}

Messages:

{ "deviceId": 0, "deviceDescription": "Thermometer", "data": 24 }

4. Spirometer flow rate: A floating number between 0.0 and 100.0 every 30 seconds.

Configuration:

{
  "deviceId": 0,
  "deviceDescription": "Spirometer",
  "outputType": "float",
  "range": [0, 100],
  "timeInterval": 30
}

Messages:

{ "deviceId": 0, "deviceDescription": "Spirometer", "data": 52.342 }

5. Skin humidity at 20 different points: 20 floating numbers in the range of 0-100, changing every minute. Configurations:

   [
   {"deviceId": 0,
    "deviceDescription": "SkinThermometer",
    "outputType": "float",
    "range": [0,100],
    "timeInterval": 60},
   {"deviceId": 1,
    "deviceDescription": "SkinThermometer",
    "outputType": "float",
    "range": [0,100],
    "timeInterval": 60},
    ... repeat for another 18 times (and 18 different ids)
    ]
   

   Messages:

   {'deviceId': 0, 'deviceDescription': 'SkinThermometer', 'data': 22.4142}
   {'deviceId': 1, 'deviceDescription': 'SkinThermometer', 'data': 22.402}
   {'deviceId': 15, 'deviceDescription': 'SkinThermometer', 'data': 22.3112}
   {'deviceId': 2, 'deviceDescription': 'SkinThermometer', 'data': 22.40}
   ...
   

   Note that the messages are not send always in order even if the timing is the same message from sensor with id 15 comes before message from sensor with id 2.

6. Room temperature(Celcius): An integer number changing every two minutes.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Thermometer",
  "outputType": "int",
  "range": [0, 100],
  "timeInterval": 120
}

Messages:

{ "deviceId": 0, "deviceDescription": "Thermometer", "data": 25 }

7. Room humidity: A floating number in the range of 0-100, changing every two minutes.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Humidity",
  "outputType": "float",
  "range": [0.0, 100.0],
  "timeInterval": 120
}

Messages:

{ "deviceId": 0, "deviceDescription": "Humidity", "data": 70.0023 }

8. Sleeping state: Boolean value if patient is sleeping changing every one minute. This can be thought as an integer in the range [0,1].

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Sleeping",
  "outputType": "int",
  "range": [0, 1],
  "timeInterval": 60
}

Messages:

{ "deviceId": 0, "deviceDescription": "Sleeping", "data": 0 }

9. Substance of X in blood: float value in the range 0-1 changing every 10 minutes. X can be any mineral out of {calcium, iron, magnesium, potassium, zinc}.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "magnesiumSubstance",
  "outputType": "float",
  "range": [0.0, 1.0],
  "timeInterval": 600
}

Messages:

{ "deviceId": 0, "deviceDescription": "magnesiumSubstance", "data": 0.00003 }

10. Level of substance Y artificially provided: float value in the range 0-1 changing every 30 seconds.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Ysubstance",
  "outputType": "float",
  "range": [0.0, 1.0],
  "timeInterval": 30
}

Messages:

{ "deviceId": 0, "deviceDescription": "Ysubstance", "data": 0.002 }

11. Patient image frames from a camera per 30 seconds.

Configurations:

{
  "deviceId": 0,
  "deviceDescription": "Camera",
  "outputType": "image",
  "range": [324, 224],
  "timeInterval": 30
}

Messages:

  {'deviceId': 0, 'deviceDescription': 'Camera', 'data': [[[8,23,254]...],...]}

The messages data holds an array of size 224 x 324 x 3 with integer numbers in the range of [0,255].

12. Muscle electrical tension out of 10 muscles updated every 20 seconds.

Configurations:

[
 {"deviceId": 0,
  "deviceDescription": "mVTension",
  "outputType": "float",
  "range": [0.0, 20.0],
  "timeInterval": 20},
 {"deviceId": 1,
  "deviceDescription": "mVTension",
  "outputType": "float",
  "range": [0.0, 20.0],
  "timeInterval": 20},
  ... 8 more such devices are defined
]

Messages:

  {'deviceId': 9, 'deviceDescription': 'mVTension', 'data': 10.07}
  {'deviceId': 0, 'deviceDescription': 'mVTension', 'data': 10.07}
  {'deviceId': 8, 'deviceDescription': 'mVTension', 'data': 10.07}
  ...

13. Feel free to provide any additional outputs, but you have to change the generation tool.

Configuration:

{"deviceId": "unique device id number",
 "deviceDescription": "A description string of the sensor device",
 "outputType": "float | int | image",
 "range": ["low","high"],
 "timeInterval": "number of seconds between transmissions",
 "scenario": [{"time": "time between transmission of
                        the previous state and this state",
               "value": "The deterministic value of simulated measurement"},
              ...
              ]
}

Possible outputs of the backend

Below there are example configurations for possible actuator device inputs and example messages coming from the HealthMonitor. Messages should end with a newline (Unix) character, spaces do not matter.

1. Send text to hospital system to call an ambulance.

Configuration:

{
  "deviceId": 2,
  "deviceDescription": "textAmbulance",
  "inputType": "text",
  "range": []
}

Message:

{ "deviceId": 2, "state": "Come now to the health center!!!" }

2. Invoke nurse alarm, to help the patient.

Configuration:

{
  "deviceId": 2,
  "deviceDescription": "nurseAlarm",
  "inputType": "text",
  "range": []
}

Message:

{ "deviceId": 2, "state": "Nurse needed at room 7!!!" }

3. Increase or decrease substance Y level inside a range 0-1.

Configuration:

{
  "deviceId": 2,
  "deviceDescription": "substanceYlevel",
  "inputType": "float",
  "range": [0, 1]
}

Message:

{ "deviceId": 2, "state": 0.7 }

4. Invoke doctor alarm, to see the patient (Something is not going well).

Configuration:

{
  "deviceId": 2,
  "deviceDescription": "doctorAlarm",
  "inputType": "int",
  "range": [0, 1]
}

Message:

{ "deviceId": 2, "state": 1 }

If message

{ "deviceId": 2, "state": 3 }

is sent then the simulator will not change the actuator's state and will return back to the HealthMonitor an error message in JSON format:

{'deviceId': 2, 'deviceDescription': 'doctorAlarm', 'data': the current state, 'error': true}

5. Statistics report for the doctor.

Configuration:

{
  "deviceId": 3,
  "deviceDescription": "doctorStatistics",
  "inputType": "text",
  "range": []
}

Message:

{ "deviceId": 3, "state": "stats:Healthy" }

6. Feel free to provide any additional outputs.

Configuration:

{
  "deviceId": "unique device id number",
  "deviceDescription": "Device functionality description",
  "inputType": "float|int",
  "range": ["low", "high"]
}

How to read/output JSONs

One common library to use for parsing and outputting json objects/files is the jsonxx. This is a recommended library of course, but not the only one you could use.

Deliverable 1 - Software Requirements Specification (SRS)

In this document ~12 functional and ~5 non-functional software requirements will be defined and described. Also 4 scenarios have to be described inside this document using the template form of the lectures. The most requirements come from the fact that your logic (sensor messages processing) is static and not abstract leading to easier functional requirements and less non-functional requirements. More information about the first deliverable in general, no matter the project, and the feedback can be found in this document. The template which will be used is this document or its corresponding doc which is more compatible.

Deliverable 2 - Software Design Specification (SDS)

The architecture you will use it is your choice, the (MVC) Model-View-Controller pattern may not necessary be applicable for this project. For this document you will design the architecture of your liking that will satisfy the requirements of the first deliverable. This application is event driven application, meaning that the most code is actually executed whenever a sensors message reaches HealthMonitor. So, for your first design draft it is recommended to think in terms of information flow. Another recommendation is to try not making the logic of the application too abstract. The logic of dealing with specific sensors and actuators is hardwired into your application.

More information about the second deliverable in general, no matter the project, and the feedback can be found in this document. The template which will be used is this document.

Deliverable 3 - Implementation

For this phase you will implement the design that the other team has prepared for you.

A good way to start your implementation is to look at what the Python tool is doing to output data. Also the examples in the practical CPP sockets will help to deal with the communication. However, avoid use threads if you are not already comfortable with the concepts. Download the package, set it up and test it with the simulator before starting to implement anything.

As a guideline, your implementation should contain at most around 800-1000 lines of code. This is not a requirement, but a guideline: if you feel you need more, you probably need to rethink your implementation and follow the DRY (don't repeat yourself) principle.

If your application needs a configuration file, this file can have any format, not only JSON.

The application configuration can be static and baked into the source code, however it can also be dynamic and read from a file. In order to read and parse these files you may find an open-source library and use it as a dependency, but you need to make sure there is no issues with the license and this dependency is mentioned in the README.

Deliverable 4 - Testing report

See here.

Deliverables

Deliverable 1.0

The software requirements are the essence of any project. Generally, a company does not deliver code, it delivers features. So it makes sense to specify them in the very early stage of project work. There are various standards proposing a common format for a document specifying software requirements, one of them is the IEEE SRS (Software Requirements Specification), that we will be basing on.

We provide a template here that you should use for your requirements specification. This is a standard IEEE document with some of the sections grayed out. You don't need to fill in the grayed out sections: they are there to give you a general feel of how the full template looks like, but for the sake of this course we only ask you to fill in the sections in black.

The number of functional requirements should be 12 +/- 1 and the number of non-functional should be 5 +/- 1. The +/- depends on how complex they are. There are also at least 4 scenarios required. Every scenario should illustrate as many requirements as possible and show examples of using the system. Furthermore, each scenario should illustrate different requirements, minimizing the overlap with other scenarios.

The deliverable is finalized by creating a release in your GitLab repository using the Releases functionality.

Access for feedback

After your SRS is complete, you need to give access to your GitLab repository to the team you are paired with. They will download the final document and prepare their feedback. We will send emails to team leaders with instructions on how to provide access.

Feedback - Deliverable 1.1

Your feedback should be provided as a CSV document with a specific structure:

title,description
"My Issue Title", "(1,1,something): My Issue Description"

It should contain one row for every issue you find.

• title is a short summary of the issue.
• description should have the form "(page, paragraph, starting phrase of the text you are referring to): description of the issue".

If the starting phrase is a diagram then write the word diagram#n where n is the number of the diagram in that page. This process makes it easier for the other team to find and correct their mistakes.

Keep in mind when giving feedback for an application that the other team is thinking differently than you. So try to understand what they are trying to design before writing a negative comment.

You should send a merge request to the other team's repository adding your feedback CSV document once you're done.

After you receive the feedback from the other team (and merge it so the file is in your repository), you should use the Issue Importer API to import the feedback contents as issues into your repository.

After the feedback round each team should produce a new release of their fixed requirements document, before continuing to the next deliverable. This new version does not have to address all reported issues, but the ones the team thinks are actually problematic. The new release should have a comment indicating which issues were handled. Also, for each issue in the Issues tab there should be a reply either addressing the issue or explaining why it's not important.

Deliverable 2.0 1

Now that you have received some feedback for the requirements specification and hopefully understand various aspects of your project better, it is time to prepare the software design.

The deliverable for this design phase is a PDF document and PlantUML source files. The document should follow the SDS (Software Design Specification) template available here. You should use PlantUML to prepare various diagrams for the document: keep the PlantUML source files in a single directory in your repository (e.g. uml/source), and their compiled versions in another directory (e.g. uml/images). You should of course also insert the compiled images into your PDF document, but keeping stand-alone files can be helpful if e.g. the font is too small.

There is no specific guidelines for the number of diagrams, it is up to you to decide if your requirements are covered by your design.

If at some point you feel it is necessary to go back and modify your requirements, you can do that, but you have to use a separate commit to clearly distinguish changes to requirements from your work on design.

Once your deliverable is ready, it has to be published using a GitLab release in the same way as the previous deliverable.

Feedback - Deliverable 2.1

The feedback process for this phase is the same as before. Each team has to fill out a CSV file and send it as a merge request. The other team then has to accept the merge request, and import the file using the Issue Importer API. Please refer to the previous deliverable page for more detailed instructions on providing feedback.

Installing PlantUML

The UML tool that will be used for this deliverable is PlantUML. You can download it here: the JAR version is compatible with any OS that has Java installed. Guides and language manuals can be found on the PlantUML webpage.

In order to draw sequence diagrams Graphviz should be installed from here.

Deliverable 3.0

In this phase of the project you have to implement the design of another team. Implementation should be done in C++, using CMake as a build system. You can use any text editors or IDEs you like, as long as the project can be built with CMake, if you do not have a preference, we recommend either CLion (a full-featured IDE), or VS Code (a somewhat simpler text editor).

Your implementation must be done in a GitLab repository, see below for more details about the workflow.

In general you are free to use any tool you find useful for your workflow and feel confident using. We strongly recommend using Doxygen for automatically generated documentation. It makes it easier for everyone to navigate your project on a high-level through a generated web page with documentation. We also recommend that you use GTest for writing unit tests.

GitLab workflow

You have been using GitLab for the previous phases, and you should continue doing it for the implementation. Since every team seems to have a more or less unique workflow, we only make two hard requirements:

• Your implementation must be in a repo that TAs can access.
• Your implementation must have a CMakeLists.txt in the root directory that can be used to build the project with CMake.

There are also a few points where you can choose what works best:

• You can either use the implementation skeleton provided in the template repository, or create your own repo structure. All of the content in the template repository is for your convenience only, you are not obliged to use it.

• You can keep the implementation code in either of these places:

  • The repository with the other team's design (Recommended). You should have developer access to it from before, and this way the code lives in the same place as the corresponding design document.
  • The repository with your own design. This makes it a bit confusing, but if you already started working with this approach, it is fine to continue.
  • A new, fresh repository. This can be useful, for example, if you want to use the template repository as a base, and the repository you would otherwise work in was not using it; or the other way around, if you don't want to use the template repository code, but the existing repository is using it.

Wherever you choose to keep your code, after you are done, you must create a GitLab release with the final commit, and create a GitLab issue in the repository with the design you were implementing. The issue should be named "Implementation complete", and its description should contain a link to the release you created, whichever repository this release is in.

Resources for tools

Here we provide some links that you might find helpful to get to know the tools you are using better.

Git and GitLab

The GitLab docs have useful tips and guides about both Git and GitLab. In particular, you may want to read up on branches and merging, since it is likely that you will have to merge your work from separate branches.

CMake

CMake can be a bit daunting at first, but if you walk through the tutorial you should be able to write simple CMake files that should be sufficient for this project. You can also check out the CMake configuration provided in the template repository to get a general idea of which CMake commands you may need.

Make

Make is a more basic build system that CMake uses under the hood. You most likely will not have to interact with Makefiles yourself.

Google Test (GTest)

Google Test includes a nice introduction guide in their official repository.

Documentation (Doxygen)

Doxygen manual is somewhat verbose, but the sections "Getting started" and "Documenting the code" should contain most of the basic information.

Operating System

All of the listed tools should work on any platform, but it is much easier for TAs to provide support if you are using Linux.

Deliverable 4.0

In this final part of the project, you need to test the implementation provided by your partner team to make sure that it works in the scenarios described in the requirements document (SRS). You may also test other scenarios, as long as they can be reasonably inferred from other requirements you had prepared.

You do not have to prepare a formal document this time (though there are of course IEEE templates for that), a simple structured Markdown file will do.

There are some frameworks for integration testing, but their use is more varied, and generally a lot of projects have their own peculiar way of running integration tests. For the sake of not spending too much time on this phase, you do not need to make your tests automatic: it is enough if you check all scenarios manually. That said, if you feel comfortable enough will shell scripts, you may still find them useful.

You should add your testing report to the root directory of the same repository as your SRS and SDS, with name testing_report.md.

The general structure of your "testing report" Markdown file should be as follows:

# Test Summary Report

## Introduction

The overall verdict in brief.

## Scenarios tested

### Scenario 1 (PASSED/FAILED)

Short description of the expected behavior.

Result:

> Pass/Fail. (If fail, how the actual behavior is different from expected)

### Scenario 2 (PASSED/FAILED)

...

## Other concerns and comments

(If you wish to add anything)