Project Summary - L6mps/LasaLaraAP GitHub Wiki
For the course "Tarkvaraprojekt", our group took up a proposed project named "Lasalara". Although most of the team's members had very little previous experience with Android development, the project itself did not seem to be too hard, even when starting from scratch. Over the course of three months, the group produced various pieces of documentation, held several meetings and most importantly, developed an Android application that fulfills the customer's major expectations.
What is LasaLara?
LasaLara is an enviroment, where teachers can create a study book with questions and answers, so that students could study content in an optimized way on their mobile devices. Study books consist of various chapters, which can be shared with other teachers and used in more than one book. Each chapter contains questions and answers, which the user views and gives feedback on, based on their knowledge. Based on this feedback, the user's progress is tracked locally, which is calculated by a custom time-influenced algorithm.
What went well?
The group produced an Android application that can:
- communicate with LasaLara servers by downloading study books from them and allowing users to propose questions
- store downloaded study books in an internal SQLite database
- show stored study books in an aesthetic way
- gather feedback from the users about their knowledge
- calculate and show progress based on a custom algorithm
The group managed to work together, taking into account its members' skills, interests and free time. There was an aura of professionalism, which kept any remarkable conflicts from happening. The further the project developed, the more the group understood, what was most important for the client, who became more and more pleased with our work as the project's deadlines passed. During the group's last meeting with the client, he said that our project is good enough for future development and use by him.
What should have been done differently?
- Internal code review should have been done more frequently. Several code commits were looked over well over a month after their creation and some have never been looked at thoroughly, leaving minor architectural differences into the code base
- More consistent work patterns. GitHub statistics show that given any development week, there is usually just one day that stands out in terms of number of commits - if development would have been consistent, the commits would have been more evenly spaced out
- More work at the start. Connected with the previous issue, the members would have benefited from putting more work into the app at the start of the project. Instead, the app could not be used to complete the core use cases until the end of Iteration 3
- More research into Android development before writing key components of the app. One of the architectural differences that came up was the use of activities and fragments - the communication with LasaLara servers was written under the assumption that the app uses different activities for different screens, but the final implementation uses a single activity with multiple interchanging fragments instead. Whether this approach is better or not is unclear
- More communication with the client. Because of our inconsistent work patterns, more frequent meetings would not have yielded more results, but if the aforementioned problems would not have existed, we should have had more meetings with our client for more feedback and instructions
Major changes during project development
- Increased amount of work, starting some time after Iteration 2
- More frequent meetings with the client, starting some time before end of Iteration 3
- More focus on design on client's request
- Shift in members' responsibilities around the time of the first demo because of an unofficial "crunch"