Newsletter (to FAU Students) 2017-04

Hello everyone, and welcome back to our Newsletter!

Table of Contents

Continue reading Newsletter (to FAU Students) 2017-04

Final Thesis: A Quality Model for Inner Source

Abstract: Inner Source (IS) ist die Verwendung von Open Source (OS) Entwicklungspraktiken innerhalb einer Organisation. Einige Organisationen führen IS Projekte oder sogar IS Programme durch. Bisher gibt es zwar veröffentlichte OS Qualitätsmodelle, allerdings ist kein Qualitätsmodell speziell für IS bekannt. Dieses Papier präsentiert ein Qualitätsmodell für IS Programme und Projekte. Wir führen fünf Interviews mit IS Experten durch und analysieren diese mittels thematischer Analyse. Anhand der daraus entstandenen Einblicke entwickeln wir ein hierarchisches Qualitätsmodell für IS Programme und IS Projekte, die wir anschließend zu recherchierten OS Qualitätsmodellen abgrenzen.

Keywords: Inner source, inner source quality, inner source metrics

PDFs: Master ThesisThesis Description

Reference: Bernd Grillenberger. A Quality Model for Inner Source. Master Thesis, Friedrich-Alexander-Universität Erlangen-Nürnberg: 2017.

GI AK Microservices and DevOps on Oct 19-20, 2017, in Nuremberg

We are organizing a meeting of the GI AK on microservices and devops on October 19-20th in Nuremberg. Suse has generously offered their event space for the workshop. The workshop is free and open to the professional public. There is a preliminary agenda and you can make a talk suggestion. If you would like to participate, please don’t forget to register. Despite this English-language announcement, the workshop is likely to be held in German.

Show-casing the 2017 AMOS project “Simulating a car’s ECUs using a Raspberry Pi”

Project name Simulating a car’s ECUs using a Raspberry Pi
Project mission The mission of the project is to implement a scriptable Electronic Control Unit simulation environment that can siumlate diagnostic communication. Diagnostic Developers can model the diagnostic behaviour of single ECUs or whole cars inside a box such a Rasperry Pi. The communication protocol used in the vehicle diagnostic is Unified Diagnostic Services. It is a Request-Response Protocol. The ECU provides Services which can be called by the client. The mission of this particular project (in the context of the product vision).
Industry partner AVL DiTest
Team logo
Project summary Our task was to simulate ECUs from a car via Raspberry Pi. For the communication, the ECUs in a car are connected via CAN-Bus. We used the UDS-protocol for the communication of the ECUs. Which functions from the ECUs are supported is defined in the lua file. An example: If you are reading the name of the ECU, each lua file (ECU) should send another name back, e.g. engine, airbag… Because each ECU has a different task in in the car, all the definitions within the different lua files are different. Due to the fact that the Raspberry Pi is loading several lua files at the same time, a behaviour like in the car is simulated, because several ECUs are communicating with each other.
Project illustration
Project repository https://github.com/christian-reintges/amos-ss17-proj4

Show-casing the 2017 AMOS project “Raspberry Pi as user control board for multimedia evaluation boards”

Project name Raspberry Pi as user control board for multimedia evaluation boards
Project mission The mission of our project is to enhance the Sivantos Fitting Software System with a Raspberry Pi user control board to test the software efficiently and rapidly replacing the existing manual interaction with the system under test. Our project enables test engineers and manual testers at Sivantos to test their software faster, more comfortably, more efficiently and more thoroughly. By enabling one of the world’s leading manufacturers for hearing aids to increase the safety of their products, we provide value to patients suffering from hearing loss all around the world.
Industry partner Sivantos
Team logo
Project summary At first, we were not quite sure what our project was about. The subject was quite abstract and we had few experience with the hardware. The first sprints were needed to get familiar with the development environment, the hardware components and the protocols needed to talk to the RaspberryPi.
As soon as we got familiar with all the components, we were able to implement more actual features. Testing was a bottleneck, as we had to test the soft-/ hardware interaction but only had two fully functional breadboards. The close cooperation with our industry partner was helpful not only for defining the scope of the project and prioritize features, but also for debugging hardware related problems. We learned a lot, not only about software development in unknown terrain but also about Scrum in general and the importance of interaction and communication within the team in particular.
Project illustration

Team photo
Project repository https://github.com/varj888/amos-ss17-projSivantos

Show-casing the 2017 AMOS project “A factory simulation game for software testing and operator training”

Project name A factory simulation game for software testing and operator training
Project mission The mission of this 2017 AMOS project was to create a factory simulation in the style of a game. The core functionality should be the visualization of factory interior with all its machines and product flows. The elements should interact and at the end one should be able to retrieve statistics to improve the production process.
Industry partner Weber Maschinenbau GmbH, represented by Nuveon GmbH
Team logo
Project summary At the beginning of the semester, our customer Christoph Sauer from the software development company Nuveon gave us an introduction to the topic. The project started with two product owners and seven developers. By the end of sprint #4 there were three developers left. In 13 sprints we accomplished 38 user stories and released 10 official versions of our software. The product was implemented as a web application and from sprint #8 on our customer provided a server with public access for better manual testing (by the product owners and the customer). The final project release of the software provides basic administration and gameplay features. At the demo day our two customers confirmed that they are planning to extended it at Nuveon and/or another AMOS project.
Project illustration
Project repository https://github.com/PrinzKarneval/amos-ss17-proj5

Show-casing the 2017 AMOS project “Virtual Ledger”

Project name Virtual Ledger
Project mission The mission of this 2017 AMOS project is to create a banking app that represents the product vision of the Adorsys banking app. The Adorsys banking app will have a multiple accounts feature. This allows the user to add and delete all existing bank accounts he or she has in a simple way. With one click he can overview his overall financial status and the balance for every single account. Furthermore, he can get access to all the transactions that happen within the bank accounts. In this way the application ensures that the user has full view over every bank account and every transaction in one single app. As special features the user will be able to create virtual saving accounts for his own purpose and manage this accounts together with other users, so that he can achieve his saving goals with the help of an intelligent algorithm that transfers constantly money to the saving account.
Industry partner adorsys
Team logo
Project summary The Virtual Ledger App is capable of storing different bank accesses – and therefore accounts- from different banking institutions. So that a user can manage his or her accesses through one application. Furthermore, past transactions from one or several bank accounts can be shown – ranging from 4 weeks to 1 year or an user defined time span. In addition, in the calendar overview one month per page is shown and the balance for each date is accessible. Specific transactions of a date can be seen through clicking on it. Moreover, the app allows registered users to add friends to a contact screen and share a common saving goal with them . These saving goals can be specified for any future goal with or without other contacts. Additionally, the user can assign each saving goal several bank accounts.
Project illustration

Team photo
Project repository https://github.com/BankingBoys/amos-ss17-proj7

Show-casing the 2017 AMOS project “Alexa, your personal financial Assistant”

Project name Alexa, your personal financial Assistant
Project mission The mission of this 2017 AMOS project is to create minimum viable product (MVP) for Alexa with the financial extension. Core functionality will be to check bank account information like the balance, transactions, or the credit limits. Manage transactions, pay bills, manage spending habits grouped in categories, all through a secure communication are features that will be included in the MVP. Additional functionality like a smart financial component will be added to the product if the time permits.
Industry partner Senacor
Team logo
Project summary In a team of 2 product owners and 6 software developers we developed a personal financial assistant using amazon’s speech recognition hardware, alexa. Our implemented skill, is able to support the customers in their daily financial activities. Using speech, the customer is able to get information about the bank account status, transactions, stock shares and more. Furthermore, the customer can easily pay bills, send money to friends or create a savings plan. Our skill provides a tool to manage expenses in various categories like: auto, health or lifestyle, offering our customers an easy solution to track their spendings.
Project illustration
Project repository https://github.com/c-i-ber/amos-ss17-alexa.git

Student Teams of the 2017 AMOS Demo Day

Continue reading Student Teams of the 2017 AMOS Demo Day

Invitation to the 2017 AMOS Projects Demo Day

On July 26th, 2017, (tomorrow!) this year’s AMOS Demo Day will take place. Student teams from The AMOS Project course will show-case the results of three months of hard software development work. The demo day will take place in “Nebenraum Cafeteria” (Room 00.136) in the main Cafeteria building at Erwin-Rommel-Straße 60, 91058 Erlangen. The demo day is open to the interested professional public.

Demo Day Schedule

Start Time Responsible Person Content
10:00 Uhr Industry partners Arrival of industry partners, public
10:15 Uhr Prof. Riehle Opening remarks
10:20 Uhr Student teams One-slide presentation on project
10:45 Uhr Everyone Demos and discussions in presentation booths, photo op
12:30 Uhr Everyone Official end of demos, leaving for lunch

If you are new to the AMOS project, please read The AMOS Project in a Nutshell.

We would like to thank this year’s projects sponsors:

Adorsys

AVL DiTest

Senacor

Sivantos

Weber