Vision statement

---

Mantis is a software error-tracking program that enables users to allocate tasks and resolve issues related to the development of software. At its core, Mantis streamlines the process by which users can address the fundamental problems underlying a software development project. When it comes to improving software, organization and distribution of resources are critical. Mantis seeks to simplify the problem-solving process involved in bug-tracking to improve the efficiency of those involved in software development, whether they are a developer or not.

As with anything related to technology, the realm of software creation is ever-changing, requiring flexibility. In addition, deciding how to divide the workload can be stressful and time-consuming. There is also the need to keep track of accountability. Mantis is a comprehensive tool to ease all of these burdens. It acts as a non-software-specific bridge to unify efforts from the technology and business sectors of a company so that software issues can be thoroughly understood, assigned with clear intent, and tackled head-on.

The primary user base includes software developers and project managers. The application will provide simplicity for those not technically inclined while offering a layer of complexity for those who have more experience with software development.

Once a user has joined Mantis, they can assign themselves roles such as “Developer” or “Project Manager” which will grant them the appropriate permissions. Users can create individual and team projects, and then within a project, they can create 'tickets' that represent specific software bugs. Tickets will allow users to describe and document bugs, assign them to team members, and establish deadlines. Tickets and projects will be searchable on a separate 'board' which can be filtered out using various criteria.

A scheduling system along with a personal calendar will be implemented to help users stay on track. Users can add tickets to their schedule and specify a date and time duration, and then these tickets will appear on their calendars. This will allow users to plan and organize their tasks for any given day, week, and month.

Since the presence of remote work options is increasing in popularity, it is important to maintain quality communication between team members and management, so Mantis will include a built-in messaging system. This will allow users to remain in the application and increase productivity along with accountability.

The success criteria will be purely user-oriented as they can now be considered a new set of stakeholders in the agile design methodology. Approximately 28% of all applications are uninstalled after 30 days [1]. Given this statistic, our goal is to meet or exceed a 72% retention rate regarding users who have downloaded the application. Furthermore, we would like to obtain user retention of at least one interaction in the application every 12 hours [2]. As a final success metric, we aim for an active community of at least 2500 users after 18 months [2]. In conclusion, we chose these success criteria as we now consider our active users stakeholders with valuable user stories for future development.

Post Mordem

Overall the project was a learning experience in group work, humility, and large intertwined code bases. The material of the class and the actual group work were like peanut butter and jelly, they complemented each other well. Utilizing the agile methodology, SOLID principles, and n-tiered architecture were crucial for the success we had achieved, and when ignored contributed to our failures.

What was the overall architecture of your system (particularly if it is different from the demo system)?

We stuck fairly close to the three-tiered architecture that we had learnt about in class, as well as what was provided in the sample project. Our architecture was fairly different compared to the sample project.

What went right in the development process?

During the development process, our group held a high standard of communication and freely shared ideas. In general, we had a very healthy group dynamic. There was this general understanding of obligations outside of the course and how we all have other academic obligations. We had several meetings outside of class. This helped everyone stay up to date with the project even if they didn’t have time to work on it. There was always a concept of we win together we lose together so there was never any real tension or communication breakdowns.

What went wrong in the development process, and what would we do differently if we had to start over?

Initially, we had very high expectations of what could be accomplished and we spread out too far instead of building solid foundations. This hurt our second iteration which we had to sink a lot of time in to accomplish very little. We did rebound from this in the last iteration and implemented it quite a bit while fixing a lot. If we could start over, we would definitely focus on a small group of objects first, and build out from that. For example, instead of focusing on user credential login firsts, we should have focused on getting a robust UI that we could grow instead of an authentication process. It would have been easy to add that to a chain of responsibility. Also, having a better architecture diagram and planning it together would have been worth the time investment over trying to learn and add to un-planned code. This touches on what is discussed in our retrospective, where we changed our velocity expectations and used our time for a more efficient task than a wide range of tasks. In a sense, we were doing “shotgun surgery” and spreading our work out too far. This is why if we could start again, putting more effort into planning in our early iterations and getting some ideas written down instead of “the right idea” written down would have been helpful.

Can you draw any conclusions from what you've done?

There is a lot to be concluded from this project. Firstly, group work is hard but worth the effort. There is very little chance that any one person can accomplish what we did as a team. Group work also comes with some complications, but with good communication, we managed to mitigate most of them. As far as software development went, Android Studio is a great piece of software that massively helps us in our project. There was a fairly large learning curve when it came to developing software with other people, especially with integration. With the use of testing suites and tools like Junit, Mockito, and Espresso we could really test our features well before integration. Sometimes we did not utilize them enough, but we eventually did to ensure a boarder range of functionality is tested. They would have helped us tackle some debugging. A good portion of the troubles came from the database, it took a while to get functioning, and because of that, our integration across layers was late to be tested. This was one of the larger hiccups and was just a part of the development process. We overestimated our abilities while underestimating the difficulties. This is where the agile methodology really helped. It allowed us to learn and adjust during the development process. As mentioned in our retrospective, we had the ability to get a bunch of features done, but we didn't have the UI to display and access them. Going back to what was previously stated it would have potentially been a better use of time early on to have a more robust UI infrastructure to add onto.