This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
What went well
Collaboration within the team was very good throughout the development process. Everyone focused on the parts of the project assigned to them and we held regular online meetings to discuss our plans and to distribute the workload among the team members. Often, when a member had spare time after completing their own tasks, they also worked on other urgent tasks that needed to be finished before the deadline. For example, finishing up the documentation or working on more general parts of code and fixing bugs. Of course this wasn’t always possible because some of the coding tasks were very specific and required more knowledge, like low-level communication with the ID card.
The communication with the customer was exceptional throughout the entire development process. We made sure to meet with the customer during each iteration once in person to talk about the project’s process, demonstrate what we had done at that point and to discuss any difficulties that we had with implementing the features and how we could solve these issues. We also used e-mail consistently to clarify smaller details.
When we consider the fact that we had no previous experience with Android development and mobile authentication, we can confidently say that the development process turned out rather well. We managed to implement the most important functionality, which is the authentication functionality so in that sense we can say the project has been successful. While we would like to say that we should have started working on some problems earlier, we sometimes simply did not have enough time because we have to take other courses as well. Nevertheless we usually managed to finish the necessary iterations on time. Some of the tasks that we set for ourselves got delayed, because there wasn’t always a reasonable way to split them into parts, so we just pushed them to the next iteration.
The requirements elicitation process was quite successful despite some of the struggles that are described later on. We talked to the customer about how the end result should work and we managed to create initial user stories and use cases (later on we had to refine and improve them), which we could use to start developing the application. We decided to drop some things like the UML diagram because our app didn’t store almost any data besides a few key-value pairs. For this reason we found that there was really no point in creating a UML diagram and the customer agreed with it as well so omitting the UML diagram was not a problem.
The application’s design process was quite straightforward and there were no issues with it. We created some sketches that we based our initial design on and moved on from there. We also tried to implement Material Design principles whenever possible and we tried to make sure that the application is easy to use and navigate and that the authentication process consists of as few steps as possible so the application design in the end is quite minimalistic. We are happy with the end result.
We used manual testing to test the implemented functionalities and for our project it was suitable because we had to use NFC and NFC-capable ID cards, which makes creating automated tests very difficult (unfeasible). We managed to make sure that the application works well so the lack of automated tests did not cause any problems for us. If anything, the automated tests would have hindered the development as the time spent on automating these tests would have been disproportional to the possible benefits. Later on we used acceptance tests, that we had created on the base of use cases, to guide the testing process.
What should have been done differently
The requirements engineering process was somewhat wasteful for us. This was caused by our lack of experience with Android development and mobile authentication. We spent a lot of time eliciting requirements that we had to change or scrap later on because we initially did not have enough knowledge on how things should be done. It is hard to tell what we should’ve done differently as it was mostly caused by a lack of experience, but maybe we should have just skipped some requirements initially or made them very brief instead. This would’ve saved us a lot of time that we could’ve used to work on new functionalities or other important things. It is important to note that the customer was very helpful during the development process and without his help the situation would’ve been worse.
Additionally, when talking about requirements, we should have been probably a little bit less ambitious in the beginning. In the end we had to discard a few use cases and user stories because we didn’t have the time and means to finish them. Instead of adding broken features at the last moment, we focused on the features that were most important for the customer and made sure that these worked without any issues. We could have possibly cut down on the number of user stories and use cases earlier, during the first 2 iterations, to avoid unnecessary workload or even the pressure that having these requirements created for us.
We also should’ve thought more about how to implement code review. Initially we wanted each branch to be reviewed by two different team members before merging it to the main branch, but this did not quite work out. We found out very soon that because we are students who take different courses at the same time and not actual employees who work on one project every day, it was simply not feasible. Sometimes the merge request would sit for a few days without being reviewed because other team members did not have time to do it at that particular moment. For this reason we dropped the code review requirement at the end of the second iteration.
Even though the collaboration in the team was good most of the time, there were a couple of times when the communication in the team could have been better. It was not caused by lack of motivation or by simply ignoring other team members, but by lack of time. Sometimes there were a lot of assignments in the other courses so it was not possible to focus 100% on the project. However, lack of time or not, this is not ideal and more effort should be shown so that team members don’t get the feeling like they are struggling alone on something.
What we learnt
The project and course taught us to work in a bigger team and how to organize work in a team. Because of the course requirements we had to develop the project according to the agile practices with iterations, but in the future when doing a project of similar size/scope, we would probably go with a non-iterative Kanban-like approach because the features we developed were very different in size and difficulty so trying to organize them into iterations felt forced sometimes. We feel like this would help to make the development process more efficient.
Most of us felt that we had certainly improved our time management skills. In the future we have to be more conservative with time estimates, because things tend to take a lot longer to implement than initially expected, even when you know how to do something. A simple bug or a mistake caused by absent-mindedness can take multiple hours to fix and this is something that has to be accounted for when creating time estimates or planning iterations.
The project also improved our version control practices because in a project of this size it was really important to use branches whenever possible. In some other courses it is possible to get by without using branches at all, but it was simply not feasible this time around.
Last but not least, the entire project was a big learning experience for all the team members as we had no prior experience with mobile application development or mobile authentication when we chose this project. This was a risk for us as it would have been easier to develop a web application because it is something that we have previously learnt and done in other courses such as Web Application Development. However, choosing a simpler project would have been less challenging and rewarding. The skills that we acquired while working on this project are certainly going to be useful in the future.
Customer's opinion and future plans
Mobile Authentication project fulfilled the purpose of the POC, demonstrating that web-eid is implementable in tandem with non-browser (not connected directly to the browser like an extension)authentication agents and it is reasonably simple and straightforward to integrate it with a website that has been updated to support web-eid.
Next steps after the POC is to formalize the lessons learned when it comes to the web-eid protocol, the mobile app triggering protocol (custom URL handler format/QR format) and the web-eid.js library support for triggering non-extension agents via QR code generation and mobile app link generation, with some developer helpers to smoothly detect mobile environments.
The app itself can be further improved with integrated QR code reader, improved UX, and possibly a small rewrite for a version 1.0. An iOS application with similar capabilities would be great.