Deprecation in Java is a language feature that allows API producers to mark program elements as obsolete. However, previous work has identified that this mechanism is co-opted to indicate another concept entirely: a misuse of deprecation. This leaves room for improvement because deprecation warning mechanisms do not fully describe the true reasoning with which API producers choose to misuse the deprecation mechanism. In this thesis, we create a taxonomy of five reasons why API producers misuse the deprecation functionality found in open-source software by analyzing 763 methods. Using this taxonomy, we create alternatives meant to help API producers avoid deprecation misuse by introducing five new annotations meant to be specific in API abnormalities. To test this proposed alternative, we conduct a user study. However, as no current experimental settings fit our needs, we create an experimental platform, RESPIRED, publishing it to improve the state-of-the-art in software engineering experiments. Finally, we test our alternatives using this platform, finding that changing only the warning text does not have a significant impact on developers.

The E-Sports Game Arena will launch an esports cafe in the summer of 2017. At this location, the company wants to introduce membership cards to create a sense of community. The goal of the project was to explore the technological possibilities of such cards and to create a working prototype that makes use of these possibilities.

At the start of the project the assignment was still broad: explore the possibilities of a card system at the Arena. The first goal was to set a clear scope for the project by brainstorming with the client. After the brainstorm sessions, some ideas were selected while keeping factors like allotted time and technical practicality in mind. From these ideas, requirements were created to establish the essential functionalities necessary for the system. User scenarios were created to formulate the requirements in real world use cases to get a better understanding of the situations in which the system is used.

Following the design phase, the technical specification was constructed. Together with our client we decided that creating a proper software foundation for the card system was vital to this project, as it would later be expanded with other features and systems. Additionally, we created four prototype applications that make use of this foundation.

During the project, we analyzed the security aspects in detail by listing risks, possible attacks, and solutions that could be used to mitigate such attacks. For security solutions that were not implemented during the course of the project, we made recommendations as a guideline for future improvements.

This report also details the testing process used in this project, describing the use of testing frameworks and approaches. Then, the proceedings of the project with respect to its group members, the coach, the client, and the Software Improvement Group are evaluated. Afterward, the product as a whole is evaluated in retrospect, taking the project requirements into account.

Finally, a conclusion is made, evaluating the success of the project and giving our final recommendations. From this we can say that the project has been a success, as the success criteria have been met.