Noah Hartmann

About

As part of the Software Engineering course, the software development process was followed through a project to develop a web application for tracking income and expenses. At the end of the project, a release branch "rel/1.0" was created in each repository (backend and frontend) and linked to the PaaS platform Render and the hosting platform Netlify.
A detailed report (in German) can be found here.

Screen Capture

Process Model: Scrumban

We chose the Scrumban methodology, which combines elements of Scrum and Kanban to enable flexible and agile project management. This choice was based on several factors:

• Lack of Experience: Most team members had little experience in software engineering and development, making agile methods suitable for learning new skills during the project.
• Flexibility: Agile methods allowed for quick responses to problems and changes.
• Adaptation to Needs: Since the project was in an artificial setting and we were not working on it full-time, Scrumban was adapted to specific needs.

Adaptions to Scrumban

• Role Distribution: The entire team took on all roles (Scrum Master, Product Owner, development team, planning team, and customer).
• Sprint Duration: Sprints lasted one week to accommodate the short project timeline.
• Sprint Meetings: Review, retrospective, and planning were combined into sessions lasting at least two hours. Daily standups were eliminated.

Organization and Visualization

• Kanban Board and Gantt Chart: A Kanban board and Gantt chart were used to organize and visualize the workflow.
• Software YouTrack: The Kanban board and Gantt chart were managed using the YouTrack software, which also documented effort estimates and time spent.
• Time Tracking: Non-ticket-based time, such as sprint meetings, was recorded in an Excel spreadsheet.

Requirements Analysis

The requirements for the web application were captured using user stories (including acceptance criteria and definition of done) to systematically document and prioritize user needs and wishes.

Software Design

Used Software Architectures:

• Three-tier architecture
• Publisher-Subscriber architecture
• Client-Server architecture
• Component-based architecture

Used Design Patterns:

• Observer
• MVVM (Model-View-ViewModel)
• Singleton
• IoC (Inversion of Control) and DI (Dependency Injection)

Various UML diagrams were created for visual support and as a basis for discussion:

• Use Case Diagrams
• Class Diagram for the backend
• Component Diagram for the backend
• Sequence Diagram
• ERM (Entity-Relationship Model)
• Relational Model

Testing

Backend
Integration tests were written for controller and service classes as well as repository interfaces. For example, the ExpenseControllerTests class verifies the interaction between the ExpenseController and the ExpenseService to ensure that the controller endpoints deliver the expected results.
Due to the low complexity of the methods, no isolated unit tests were written.

Frontend
Unit tests were created for the frontend components and functionality was additionally tested using whitebox testing. This included testing the "happy path" where everything works as expected, as well as attempting to provoke possible exception states through various combinations of incorrect inputs.

My responsibilities

Backend

• Create a Gantt chart (using YouTrack) to have a clear view at any point in the project of our progress and the next steps
• Create a UI mockup using Figma
• Provide a PoC for the frontend and backend of the application
• Create Controllers
• Write integration tests for the backend
• Researched and integrated the Log4J logging framework into our application
• Implemented consistent and clear exception handling for our Spring Boot application
• Continuously helping my team members with their assigned tasks

Frontend

• Implemented GET requests in the services
• Integrated the PrimeNG MessageService for visual feedback on user interactions
• Worked with the ngx-translate library for internationalization (i18n) in Angular applications, enabling runtime translation and language switching. This was necessary as both our backend and frontend were written in English, but the user interface (UI) was to be in German
• Continuously helping my team members with their assigned tasks

At the end of the implementation phase, I undertook refactoring and documentation (using Springdoc OpenAPI and Compodoc) of the code in both the backend and frontend. Additionally, I looked into CI/CD.
We did not implement Continuous Integration and Continuous Delivery since we addressed the topic of CI/CD at the end of the project. Code changes were manually merged into the main branch after each sprint. However, we did set up Continuous Deployment.
For that I configured automatic deployment of the frontend to the hosting platform Netlify, triggered by a push to the rel/1.0 branch.
For the deployment of the Backend I created a Dockerfile defining a multi-stage build process using a Gradle image for building the application and an OpenJDK image for running the built jar file. Upon a push to the rel/1.0 branch, the PaaS platform Render clones the repository, builds an image based on the Dockerfile, and starts a container running the application. Additionally, I set up a PostgreSQL instance on Render.

Learnings

• Scrumban worked flawlessly, and thanks to our Gantt chart, we managed to stay on schedule throughout the entire project, avoiding extreme time difficulties (+)
• Communication via WhatsApp between sprint meetings was a very good support to quickly and easily exchange information (+)
• We all have a better overview of the steps involved in software engineering (+)
• We got to know new frameworks and tools (+)
• Architectural patterns and design patterns are less abstract (+)
• We regularly forgot to use Planning Poker for effort estimation in our sprint meetings (-)
• There was no time left for topics like application security (-)
• We all had difficulties creating the UML diagrams - this was the task that required the most iteration cycles (-)
• We did not think about the form of commit messages, so they varied in detail and precision (-)
• The naming of branches according to the scheme established at the beginning was not followed by all members (-)