Software Engineering Project

Dynamic and secure integration of AI demos in a web platform

Introduction

Together with the students, we, Appsfactory GmbH, would like to develop a web-based AI demonstrator platform and publish it to a to be defined domain.

The entire product development process from conception to delivery is mapped. We organize the project with SCRUM. For this purpose, the planning & review meetings as well as retrospectives with the students are scheduled. The students also have the opportunity to meet in the "Daily" to vote on a daily basis. We provide appropriate video conference software (Google Meet) for this.

Goal

The result of the project should be a web-based platform, catering access- and cost controlling, which dynamically embeds AI demos, which are created by Appsfactory’s AI team

Prerequisites and Requirements

The students should have an affinity for AI and web technologies. Basic knowledge of the programming languages Python and JavaScript, as well as CSS and HTML5 are a prerequisite for development. Furthermore, knowledge of public cloud deployment processes and infrastructure setup would be really helpful.

Project organization & Implementation

We work on the project according to the agile method "SCRUM". This means that we plan so-called sprints with different tasks in regular appointments and then look together to see how well or badly the implementation went. The duration of a sprint is 1 week in order to have swift turnarounds, if the student is facing certain issues. We offer explanation and guiding support to the student with regards to the Scrum process.

Component	Description
Sprint	Fixed period in which a certain selection of tasks is implemented.
Sprint Planning	Requirements and tasks are discussed, estimated and planned for sprint backlog.
Daily	Daily voting meeting among the students for progress, open questions or problems
Sprint Review	Joint appointment to present the completed tasks.
Retrospective	Review of past sprints and a joint appointment to improve implementation and organization.

 

The requirements are discussed and planned in joint planning meetings. The students organize themselves during a sprint, e.g. through regular coordination meetings (daily). In a task and planning software like Trello, the progress of the tasks is documented and evaluated. The version management "Git" helps the students to develop together on the project. With the help of code reviews (pull requests), the students independently ensure high code quality and learn from each other at the same time. Within Azure DevOps (Continuous Integration Software), the software versions are automatically checked for quality, tested and built. Developers themselves have to ensure that the software is always executable. A deliverable software status should be achieved at the end of each sprint.
Each task in the sprint goes through the following intermediate steps:

Step	Description
Backlog	Unplanned task that has to be discussed and scheduled in the planning appointment
Open	Planned and estimated tasks in the active sprint
In progress	Tasks that are currently being implemented
Review	Completed tasks that need to be checked again
Finished	Fully completed and reviewed tasks

Project milestones

The following milestones should be planned and implemented with the students:

• Initial Demo Environment Setup, incl. Access Control
• Demo Content Integration
• Build a Sample Demo and Test the Process of Auto-Deployment of new AI Demos
• Integrate Cost Control and Reporting

The exact requirements are worked out together with the students.

Location / Where to work

Our office is located in downtown Leipzig. The project itself can be carried out completely remotely. We offer software such as Google Meet for communication free of charge. For mutual coordination Appsfactory GmbH will be happy to provide the appropriate premises for planning appointments.

Contact Person

For the entire duration of the project, we provide the following contact persons for both students and lecturers:

Chief Technology Officer (CTO): Dr. Rolf Kluge, (rolf.kluge(at)appsfactory.de)

Technical Contact: Andre Karge (andre.karge(at)appsfactory.de)

Misc

• Technology and work equipment such as test equipment, software or laptops are provided
  on site or can be borrowed.
• The project is part of an NDA agreement, to be signed between Appsfactory GmbH and the
  respective student
• Rooms in our office can be used with prior registration.
• In terms of copyright, the source code written by the students as part of the project remains
  with Appsfactory GmbH.

Implementation of a VSCode Plugin for the deployment of Eclipse Velocitas-based Automotive Apps

Introduction

A modern car contains more than 200 million lines of code, and this number keeps rising steadily. In more and more vehicles this code runs on powerful vehicle computers instead of many distributed embedded control units. With this shift to more computational power, in addition to increased connectivity, and faster innovation cycles, value creation for a vehicle more and more moves towards software. Today these systems are in many cases still developed in silos by each car manufacturer or its suppliers in-house. However, maintaining and integrating hundreds of millions of lines of code in separate silos for separate product lines and domains is neither time- nor cost-effective.

To address this topic the Eclipse Software Defined Vehicle Working Group (SDV WG) was formed. Its mission is to provide a forum for individuals and organizations to build and promote open source software, specifications, and open collaboration models needed to create a scalable, modular, extensible, industry-ready open source licensed vehicle software platform to support in-vehicle and around the vehicle applications development and deployment.

The Vehicle Signal Specification (VSS) of the COVESA consortium provides a unified representation of vehicle signals in a tree like data structure. Projects such as Eclipse Kuksa of the Eclipse SDV working group provide access to the VSS tree via a data broker component. The broker is only available in the car. However, there are use cases existing – think of vehicle simulation in the cloud or vehicle app testing in a cloud-based test environment – which require a VSS databroker component being accessible in the cloud. The task is to find and implement an VSS databroker – similar to the already existing one of the Eclipse Kuksa project – but running as a cloud service and not as an in-vehicle service. Note that the Eclipse Kuksa implementation of the VSS databroker only processes data of one vehicle. If a service is running in the cloud, it needs to support more than one vehicle, which requires a tenant concept to be implemented as well.

Together with the students, the project team of Eclipse Kuksa would like to provide cloud-based service implementation for the VSS API.
The work will happen on the actual Open Source Project Eclipse Kuksa and organized as an agile team effort on the students` side who interact with the open source projects via public pull requests and issue tracker.
We plan to map the entire product development process from conception to delivery and expect that a student team organizes its work by using the SCRUM framework. The Eclipse SDV WG team provides a member, who will act as the Product Owner with whom the student team interacts regularly. For this purpose, the student team organizes the planning and review meetings, as well as retrospectives. The students also can decide whether to meet in a "Daily" to report on impediments and the tasks ahead.
The Eclipse Kuksa project provides infrastructure for development and building. The code is hosted on the GitHub organization of the Eclipse Foundation [1], video conferencing solutions for project meetings can be provided.

Goal

Goal of the project is an implementation of a cloud-service, which acts as a cloud-based VSS broker providing the VSS API for arbitrary providers of vehicle signals. The functionality of the implemented service can be demonstrated with the Carla Simulation Toolbox [2].

Prerequisites and Requirements

The envisioned next-gen automotive apps are container-based. Thus, a basic understanding of Linux and container technology should be available.
The already existing code base of Eclipse Kuksa can be checked on GitHub. To setup, run and configure Kuksa an understanding of the VSS broker concept is beneficial too.

Technologies

The dominant programming language for Eclipse Kuksa is Rust. Thus, implementing the service in Rust seems a viable approach. However, there might be reasons to implement the service in another language, which can be discussed initial project phase.

Name	Link	Description
Eclipse Kuksa	eclipse-kuksa.github.io/kuksa- website/	Broker implementation for the VSS spec
containerd	containerd.io	Container Runtime
Kubernetes	kubernetes.io	Framework for Container Orchestration
Eclipse Kanto	websites.eclipseprojects.io/kanto/	Edge Container Management Platform
Rust programming language	www.rust-lang.org

Project organization & Implementation

The project should use SCRUM as agile framework and adjust it to the concrete circumstances of the task and project team at hand.

Project milestones

The following milestones should be planned and implemented with the students:

• Setup test environment for Cloud Service
• Setup Cloud Service plugin skeleton
• Implement VSS API (probably on the basis of the already existing Kuksa databroker)
• Conceptualize and implement Demo for deployment functionality.

The exact requirements are worked out together with the students.

Location / Where to work

Inherent to an Open Source project is its distributed nature. So, the project itself is carried out remotely. The team can decide on communication channels. If required, the project contact person can arrange a video conferencing solution for the meetings. The student team and contact person may also arrange face-to-face meetings if it is needed. The contact person is located in Berlin. If the meetings are in Leipzig, appropriate rooms at Leipzig University need to be organized. Otherwise, the contact person can arrange a meeting space in Berlin.

Misc

• The students are required to provide their own development equipment
• The project is not subject to confidentiality
• Code hosting and CI environment is provided via Eclipse Foundation
• It is assumed that the code developed by the students will be published as open source in the Eclipse Kuksa project which is under the terms of the Eclipse Public License 2.0. To contribute to any Eclipse project, developers need to register at eclipse.org and fill out and ECA (Eclipse Contributor Agreement).

Resources

[1] projects.eclipse.org/projects/automotive.kuksa

[2] github.com/carla-simulator/carla

[3] websites.eclipseprojects.io/velocitas/docs/about/use_cases/seat_adjuster/

Introduction

EWERK Group is a full IT service provider, offering a diverse array of services including digitalization consulting, IT architecture, infrastructure, operation and software development. For more about us, please visit: https://www.ewerk.com/.

The Project
In our software development teams, we use pointing poker for time estimates. After estimating, the resulting times are manually transferred to our Jira ticket system. This is annoying because we have to switch between several browser tabs for the tickets and the pointing poker during the refinements. We also have to re-enter the pointing poker session data for each session.

Goal

Create a pointing poler tools with the following features:

• Jira connection (should work with on-premise and cloud)
  • JQL filter for ticket list - show metadata for the actual selected ticket
  • transfer estimation into the selected Jira ticket
• Real-Time-Communication
  • Workflow Session Handling:
  • Create as session (with a name f.e.)
  • estimation options (for example 4h, 8h, 24h, etc) free to define, persistent saveable
  • Define an on top buffer for estimation
  • save SQL filter - share the link of the session
• Rough workflow:
  • creator of the session is the moderator
  • participants take part via the link and choose a name (with profile picture) or may just be an observer
  • moderator chooses a ticket
  • Everyone sees the same ticket metadata
  • Everyone (except observer) can vote
  • Everyone will only see the results of each individual participant once everyone has voted or the moderator ends the vote
  • Moderator transfers agreed estimate (or assigns own) to Jira

Prerequisites and Requirements

• Java
• Angular
• GraphQL (Nice2Have)

Technologies

Java & Angular

Project organization

Working method	Group working
Group size	3 - 5 students
Working materials	Inputs and requirements will be given/discussed with the company manager.
Support from the company	EWERK will provide a senior developer for clarify requirements & technical support (if necessary).
Working equipment	The participants of the module need a suitable working device (laptop is recommended). Working equipment will not be provided.
Skills required	Java Angular GraphQL (Nice2Have)
Communication	Collaboration with the company takes place via MS Teams and in person meetings. (Bi)weekly meetings are expected during the project time.
Confidentiality	The project is not subject to confidentiality.
Rights	The source code written by the students as part of the project remains the copyright of the company.
Mode of working	The students work in an agile setup. The way of working is practiced together with a supervisor of the company.
Location	Meeting could be at our EWERK office (city center) or via MS Teams.

Project milestones

The project includes three main steps:

Step	Description	Note
Step1: definition of a skill evaluation model	Need definition: students will talk in detail with a manager of EWERK for defining the specific use case. Requirement analysis: specific requirements and ideas will be provided/discussed with students for clarification (e.g., skills, measurement, weighting, evaluation, etc.)	(Bi)weekly meeting with the respondent manager of EWERK will be set up for the first phase of the project.
Step 2: solution design for the application	Students propose/describe solutions for the application/tool that can be used for data entry/storing, connection and display.	Students can consult with our managers at EWERK
Step 3: Implementation of the software	Students will build the application based on the agreed solution design. Testing & deployment of the application.	Programming language selected could be as suggested or upon students’ decision depending on the agreement with the company.

Contact person

• Dr. Toan Nguyen
• Sourcing manager - EWERK Digital GmbH (Brühl 24, 04109 Leipzig)
• Email: t.nguyen(at)ewerk.com

INTRODUCTION

About Us
We are a young team with approximately 60 people. Together we develop customized software in various areas such as FinTech, automotive or logistics. We practice holistic software development according to agile principles. With us you will find an open tone and a familiar atmosphere. Modern technologies are the A&O of our work, therefore we offer many learning and training opportunities in our company.
Currently we are working on around 10 different projects in teams of 3-8 people. Usually we use Java (Spring), TypeScript (Angular) and services like AWS.
The Project
The goal is to develop an application that allows capturing and monitoring team moods over an extended period. The Moodtracker is designed to provide an overview of the team's collective mood and, thus, assist in evaluating the overall well-being of teams and making organizational adjustments as needed.
The Topic
A Moodtracker is to be developed as part of this software engineering project at the University of Leipzig. The entire product development process from conception to delivery is mapped. We organize the project with SCRUM. For this purpose, the planning & review meetings as well as retrospectives with the students are scheduled. The students also have the opportunity to meet in the "Daily" to vote on a daily basis. We provide appropriate video conference software (Microsoft Teams) for this.

GOAL

The result of the project should be a usable application that allows capturing and monitoring team moods over an extended period. The Moodtracker is designed to provide an overview of the team's collective mood and, thus, assist in evaluating the overall well-being of teams and making organizational adjustments as needed.

PREREQUISITES AND REQUIREMENTS

The students should have an affinity for web technologies. Basic knowledge of frontend and / or backend development is a prerequisite for development. Furthermore, basic knowledge of software design patterns is useful to better understand the frameworks themselves.

TECHNOLOGIES

Students can independently choose suitable technologies after the design phase. The following technologies are also used in our company and are therefore possible:

• Backend: Java, Spring Boot
• Frontend: TypeScript, JavaScript, Angular, React, Vue.JS
• Design: Figma, Prototyping
• App Development: Flutter, Ionic, React Native
• Ops: Docker, Kubernetes

Project organization & Implementation

User Stories
As a scrum master I want to create and manage teams.
As a scrum master I want to visualize the current mood of my team.
As a scrum master I want to monitor the mood over an extended time period.
As CEO of my company I want to make well thought-out decisions about our projects.
As a user I want to display my current mood on a scale from 0-10 (on my team).
As a user I want to view the general mood of my team.

Implementation

We work in the project according to the agile method "SCRUM". This means that we plan so-called sprints with different tasks in regular appointments and then look together to see how well or badly the implementation went. The duration of a sprint is decided with the students and can be between 1 and 4 weeks. Our contacts support you in adhering to the SCRUM guidelines.
The following SCRUM components are used in the project:

Component	Description
Sprint	Fixed period in which a certain selection of tasks is implemented
Planning	Tasks and requirements are discussed, estimated and planned in sprints
Daily	Daily voting meeting among the students for progress, open questions or problems
Sprint Review	Joint appointment to present the completed tasks
Retrospective	Review of past sprints and a joint appointment to improve implementation and organization

 

The requirements are discussed and planned in joint planning meetings. The students organize themselves during a sprint, e.g. through regular coordination meetings (daily). In a task and planning software like Trello, the progress of the tasks is documented and evaluated. The version management "Git" helps the students to develop together on the project. With the help of code reviews (pull requests), the students independently ensure high code quality and learn from each other at the same time.
Each task in the sprint goes through the following intermediate steps:

Step	Description
Backlog	Unplanned task that has to be discussed and scheduled in the planning appointment
Open	Planned and estimated tasks in the active sprint
In progress	Tasks that are currently being implemented
Review	Completed tasks that need to be checked again
Finished	Fully completed and reviewed tasks

 

PROJECT MILESTONES

The MVP (minimal viable product) should be planned and implemented by the students:

• Create teams
• Manage teams
• Vote my mood
• Have an overview of the team mood

Afterward there are options to implement additional features:

• Authentication (Oauth2)
• Roles and Actions (User can only see their teams)
• detailed votes (Wheel of life)
• Evaluation and Alerting

The exact requirements are worked out with the students.

LOCATION / WHERE TO WORK

Our office is located in downtown of Leipzig, in Barfußgäßchen 12, 04109 Leipzig. The project itself can be carried out completely remotely. We offer free software like Microsoft Teams for communicating with each other.
Contact Person
For the entire duration of the project, we provide the following contact persons for both students and lecturers:
Laura Rosenbaum (l.rosenbaum@finatix.de)

MISC

• Technology and work equipment such as test equipment, software or laptops are provided on site or can be borrowed.
• The project is not subject to confidentiality.
• Remote work is guaranteed via OpenVPN.
• Rooms in our office can be used with prior registration.
• In terms of copyright, the source code written by the students as part of the project remains with Finatix GmbH.

 

Cross-platform development with web technologies

INTRODUCTION

Together with the students, we, TIMETOACT Software & Consulting GmbH (in the following mentioned as TIMETOACT) would like to develop a web application to capture and evaluate questionnaires for an initial IT asset management question set. The Web App name can be defined by the students.

GOAL

Scope of the project is the development of a browser-based app solution to capture and evaluate questionnaires. Data capturing, analysis and representation must base on a tailored scoring model to (semi)automatically derive recommendations according to the input given. An optional goal is the porting of the browser-based solution to a mobile application.

PREREQUISITES AND REQUIREMENTS

The students should have an affinity for web technologies. Basic knowledge of the programming languages JavaScript, CSS and HTML5 are a prerequisite for development. Furthermore, basic knowledge of software design patterns and database design is useful to better understand the solution architecture.
The project mandates the use of open-source technologies and frameworks throughout the software development lifecycle. The working environment and tooling can be Atlassian Jira and Confluence. Both tools can be provided by TIMETOACT.

TECHNOLOGIES

The project will utilize a set of modern web development and cloud-native technologies, tailored for creating an interactive and user-friendly web application for IT asset management questionnaires. This setup will enable efficient data collection, processing, and dynamic result visualization.

Name	Module	Description
VueJS	Web Frontend	Optimal for developing the user interface, Vue.js facilitates building dynamic, responsive web applications. It's particularly suitable for interactive forms like IT asset management questionnaires.
Vuetify	Web Interface	Leveraging Vuetify, a Vue.js UI library with Material Design components, enhances the user interface, making the questionnaire visually appealing and easy to navigate.
TypeScript with Node.js	Server-side Logic	TypeScript, used along with Node.js, offers a scalable framework for backend logic, including handling questionnaire submissions, data processing, and analytics. TypeScript ensures code reliability and maintainability, which is crucial for complex logic involved in IT asset management assessments.
D3.js	Data Visualization	Essential for presenting the questionnaire results, D3.js will be used to create interactive and sophisticated visualizations, offering insights into IT asset management efficiently.
Microsoft Azure	Cloud Hosting	The choice of Microsoft Azure as the hosting platform guarantees a secure, scalable cloud environment for deploying the web application, ensuring high availability and performance.
Azure DevOps	Continuous Integration/Deployment	Implementing Azure DevOps for CI/CD streamlines the development process, from code integration, testing, to deployment, facilitating continuous delivery with minimal manual intervention.
MongoDB	Database	MongoDB's flexible document model is well-suited for storing questionnaire data and results, allowing for scalable storage solutions and easy retrieval of IT asset management information.
OAuth 2.0	Authentication	Implementing OAuth 2.0 ensures that only authorized users can access and interact with the questionnaire, safeguarding sensitive IT asset information.

 

Project organization & Implementation

Project team roles

• Project Manager
  • Project and meeting coordinator
  • Main reporter of project status
• Business and Data Analyst and Designer (incl. Report Design):
  • Workflow and report design
  • Specification of requirements
• Frontend Developer
  • Software development of frontend
  • Specification of requirements
• Backend and Database Developer
  • Software development of backend and database
  • Specification of requirements
• Test Manager and IT-Security Officer
  • Quality assurance of software development
  • Quality assurance of data integrity and IT-security standards while development

Methodical documentation
Documentation is key and must be delivered:

• Project plan, meeting schedule and frequent project status
• Documentation of solution architecture and database design
• Documentation of functional requirements (e. g. user stories)
• Documentation of non-functional requirements for solution
• Code documentation mapped to functional requirements
• Mutual agreement on coding guideline (e.g., Google, Mozilla, etc.)
• Basic test documentation

The project set-up and delivery approach can be determined by the students themselves.

Methodical approach
Development of a browser-based solution for recording and evaluating questionnaires based on an
individual logical model (scoring model with sufficient distinction of cases to display reasonable
results). Optionally, this "web app" should also be able to be displayed as a "mobile app". The following
tasks, i. e. set of features, can be performed to successfully implement the software solution(s):
Work package 1

• Definition of questionnaire together with TIMETOACT
• Definition of a fitting solution architecture
• Implementation of questionnaire

Work package 2

• Definition of scoring model to indicate recommendation from answered questions together with TIMETOACT
• Implementation of scoring model
• Administrator shall be able to view (and edit) scoring model

Work package 3

• Definition of recommendation catalogue together with TIMETOACT
• Implementation of recommendation catalogue
• Users view: Design of visualization of recommendations and benchmark (comparison) in contrast to other questionnaire users (scoped view and anonymized for other users)
• Administrator view: Design of visualization of recommendations and benchmark (comparison) in contrast to other questionnaire users, additional reporting and KPI

Work package 4

• End-to-end implementation of minimal viable product (MVP)
• Demonstration of MVP to TIMETOACT and mutual review of MVP

Optional: Work package 5:

• Adaption of browser-based application to mobile application
• Demonstration of self-developed and running MVP on a mobile platform at choice
• Publishing of solution in at least one mobile app store (e. g. Google Play Store or Apple App Store)

Further work packages can be determined together with TIMETOACT. A review of proposed work packages can also be done with TIMETOACT before the project start. Functional requirements (Detail view)
Whereas the goal and work packages mentioned above are key to success the software engineering project the following detailed requirements shall provide a detailed view on how individual work packages can look like. The requirements analysis and specifications of functional requirements in alignment with the work packages above together with TIMETOACT (e. g. in a scoping workshop) are part of the project.

PROJECT MILESTONES

The following milestones should be planned and implemented with the students:

• Specification of requirements and acceptance
• Specification of data model and acceptance
• MVP and Mock-up for initial look and feel of solution
• Feature development
• Feature tests
• Feature launch and acceptance for productive usage

The specific requirements are determined collaboratively with the students.

LOCATION / WHERE TO WORK

Our office for a possible consultation is in downtown Leipzig. The project itself can be carried out completely remotely. For communication, we provide software such as Microsoft Teams free of charge. Team meetings are held on the university premises.
Contact Person
For the entire duration of the project, we provide the following contact persons for both students and lecturers:

• Project coordinator:
  • Antonio Heimrath (Antonio.heimrath@timetoact.de)
• Requiring business unit responsible:
  • Dr. Jan Hachenberger (Jan.hachenberger@timetoact.de)

Our developers will be happy to answer any technical questions you may have about implementation:

• Developer:
  • Ilkin Kazimov (Ilkin.kazimov@timetoact.de)

MISC

• The project is subject to confidentiality.
• In terms of copyright, the source code written by the students as part of the project remains with TIMETOACT.