The development process choosen for this project is SCRUM(SCRUM Primer), an agile project management framework.
As per agile development, SCRUM defines a loose set of activities that enable the development team to embrace an iterative and incremental process.
The development process will be devided sprints of the lenght of one week each. Every sprint starts with a meeting, called sprint planning, where items from the product backlog will be selected to be implemented and expandend in multiple items, adding up to form the sprint backlog. The team members volontier to work on a given item and progress is tracked in the sprint backlog.
At the end of a given sprint a meeting takes place with 3 goals:
Members of the development team will also roleplay as:
Dialy SCRUM meetings have been ditched for efficient indipendent work. A meeting will take place once a week to close the previous sprint and to start the next one.
Trello will be used for coordination, while meeting will take place through Google Meet videocalls.
Test-Driven Development(TDD) will be followed during code production throughout the project.
TDD is a software development approach here developers write tests for a feature or function before implementing the actual code. The process follows a simple cycle, often referred to as “Red-Green-Refactor”:
For time constraints reasons the testing will not cover the GUI part of the project.
Git flow branching model will be used.
Two main branches will always exist:
main : for stable releases;develop : for feature integration.Feature branches can be created, branching from the develop branch, to implement new fetures. Once a new feature is implemented it should be merged into the develop branch. To create a new release the develop branch is merged into the main branch.
Hotfix and fix branches can be branched from the main and develop branches accordingly for bug fixes.
gitflow command line tool will be used for high-level repository operations.
Commit messages must follow a standardized form:
<type>: <short summary>
Where type is one of the following types:
- feat: A new feature is introduced to the codebase;
- fix: A bug fix;
- docs: Documentation updates only;
- style: Changes related to formatting, like spacing or indentation, that don’t affect the code’s logic;
- refactor: Code changes that neither fix a bug nor add a feature, typically done to improve the structure;
- test: Adding or updating tests;
- chore: Routine tasks like updating dependencies or configuration;
- perf: Code changes aimed at improving performance.
and short summary is a short summary of the commit contents.
The following Quality Assurance tools have been considered:
Scala style and CPD have been discarded due to compatibility issues.
Default configuration has been used.
Scoverage allows to check for the test coverage percentage. This is also used in the Continuous Integration pipeline.
It works flawlessly with the Metals plugin for VSCode. Using Alt + Shift + F will automatically update the file formatting according to the provided instructions in the scalafmt config file.
It’s still possible to do it manually using the following commands:
- ./gradlew scalafmt formats your scala and sbt source code (main sourceset only);
- ./gradlew checkScalafmt checks whether all files are correctly formatted, if not, the task fails (main sourceset only);
- ./gradlew testScalafmt formats your test scala code based on the provided configuration;
- ./gradlew checkTestScalafmt checks whether your test scala code is correctly formatted;
- ./gradlew scalafmtAll formats scala code from all source sets;
- ./gradlew checkScalafmtAll checks formatting of all source sets.
It works flawlessly with the Metals plugin for VSCode.
It finds warts in the code defined in the wartremover config file.
It is a code linter with configuration defined in the scalafix config file.
It can be run using the comand gradle scalafix.
Gradle has been chosen as the build automation tool.
To ensure code correctness and integrity a Continuous Integration pipeline has been setup, using Github Actions, to execute the test on various operative systems every code update.
CI is configured in the github actions config file