Mobile dashboard for coordination of software development projects

id180279 MOBILE DASHBOARD FOR COORDINATION OF SOFTWARE DEVELOPMENT PROJECTS ANDREI MESINA Thesis supervisor: CARLES FARRE TOST (Department of Service and Information System Engineering) Thesis co-supervisor: JORDI MARCO GÓMEZ Degree: Master Degree in Informatics Engineering Thesis report Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 29/06/2023 Table of contents Table of contents 1 Abstract 3 Resum 4 Resumen 5 Acknowledgements 6 1. Introduction, motivation and objectives 7 1.1 Introduction 7 1.2 Motivation 8 1.3 Goal and research questions 8 1.4 Objectives 9 2. Background analysis 11 3. Work plan 12 4. Feasibility, overall economic analysis and comparison with other alternatives 18 4.1 Cost estimation 18 5. Sustainability report 20 5.1 Economic dimension 23 5.2 Environmental dimension 24 5.3 Social dimension 25 6. Risk assessment 26 7. State of the art 29 7.1 Market analysis 29 7.2 Literature review 32 7.3 Literature review 33 7.4 Discussion 34 7.5 Results 35 7.6 Conclusions 37 8. Specification and design of the solution 38 8.1 Specifications 38 8.2 Design 45 9. Development of the work 69 9.1 Tools 69 9.2 Metrics development 70 10. Experimentation and assessment of the proposal/technique/work 72 10.1 Validation technique 72 10.2 Validation stages 72 10.3 Usability testing 73 10.4 Validation results 74 1 10.4.1 Initial feedback results 74 10.4.2 Usability testing results 77 10.5 Validation conclusions 81 11. Conclusions 83 12. List of references used 84 13. Annexes with supplementary information 87 13.1 Gantt Chart 87 13.2 Work plan overview 88 13.3 Figma design mock-ups 89 13.4 Metrics table 90 13.5 App navigation diagram 94 13.6 Application directories structure 95 2 Abstract The purpose of this work consists of a thorough analysis to determine which metrics are more relevant in order to monitor the performance of Agile software development projects by taking advantage of data drawn from tools such as version control systems and project management tools. To further assess the selected metrics in a near real-world scenario, a project management and performance tool, the Mobile Dashboard, has been designed and implemented. The development of such an application has gone through the planning, design, development, and validation phases, applying state-of-the-art Software-Engineering technologies, techniques, and tools. 3 Resum L'objectiu d'aquest treball consisteix en una anàlisi exhaustiva per determinar quines mètriques són més rellevants per tal de controlar el rendiment dels projects de desenvolupament àgil de software aprofitant les dades extretes d'eines com ara els sistemes de control de versions i les eines de gestió de projectes. Per avaluar amb més detall les mètriques seleccionades en un escenari gairebé real, s'ha dissenyat i implementat una eina de gestió i rendiment de projectes, el Mobile Dashboard. El desenvolupament d'aquesta aplicació ha passat per les fases de planificació, disseny, desenvolupament i validació, aplicant tecnologies, tècniques i eines avançades de l'Enginyeria del Software. 4 Resumen El objetivo de este trabajo consiste en un análisis exhaustivo para determinar qué métricas son más relevantes para controlar el rendimiento de los proyectos de desarrollo ágil de software aprovechando los datos extraídos de herramientas como los sistemas de control de versiones y las herramientas de gestión de proyectos. Para evaluar con mayor detalle las métricas seleccionadas en un escenario casi real, se ha diseñado e implementado una herramienta de gestión y rendimiento de proyectos, el Mobile Dashboard. El desarrollo de esta aplicación ha pasado por las fases de planificación, diseño, desarrollo y validación, aplicando tecnologías, técnicas y herramientas avanzadas de la Ingeniería del Software. 5 Acknowledgements I would like to start with a sincere “Thank you” to my family, my girlfriend and my dear friends for their support during the whole period of my studies, and of course during the research and development of my master thesis, while I was away from home for 5 months. I want to thank my supervisors Carles Farré and Jordi Marco for their continuous support during the whole semester of exchange, always being available to offer great advice with a smile on their face, give relevant feedback and especially help me understand the harder parts of research activity. During the validation phase of the project I have received invaluable feedback from the participants, so I want to thank them for their time. Finally, the Erasmus study mobility has been an awesome experience, and it wouldn’t have been the same without all the good people I met, making me feel like home in Barcelona. Therefore I want to thank them and thank the Polytechnic University of Catalonia and University Politehnica of Bucharest for giving me the opportunity to develop myself. 6 1. Introduction, motivation and objectives 1.1 Introduction The Master's Thesis, abbreviated as “TFM” and titled "Mobile Dashboard for Coordination of Software Development Projects," is part of the Master in Informatics Engineering program provided by the Faculty of Computer Science of Barcelona (FIB), under the Polytechnic University of Catalonia (UPC). This TFM is carried out within the Software and Service Engineering Group (GESSI) and is also part of the author’s Erasmus Study Mobility for the Spring semester of 2023 at UPC, coming from University Politehnica of Bucharest (UPB). The aim of this master thesis is to bring value in the IT industry by combining the aggregation of domain specific knowledge related to metrics, indicators, performance tracking and monitoring in Agile software development projects, together with a Minimum Viable Product (MVP) of the Mobile Dashboard - a project management application that makes good use of the data it is provided and allows its users to visualize and monitor their project performance over various periods of time. In order to obtain the best results, the main focus of the research activity is carrying out a literature review that considers various academic, industry and market sources that discuss the topic of performance metrics in Agile software development projects, trying to understand their point of view and method of validation, and carefully considering their research results, so that at the end of our review we will have a good overview of this subject, and enough validated data ready to be used in Mobile Dashboard. 7 1.2 Motivation Software development projects are growing in scale and complexity year by year, and with them the need for coordination of efforts and resources. Development teams are now distributed across various locations and even different time zones, so keeping every team member on the same page is a challenging task. On the other hand, after using specific methods of coordination, in the form of tools, team members roles, methodologies and management standards, the evaluation of the results is not given enough attention oftentimes. The motivation for this TFM comes from these challenges that most of the software development projects encounter, even if they are small sized or very complex. The proposal of the Mobile Dashboard application which focuses both on the coordination challenges, but also on the quantifiable results, the performance tracking, also aligns with the broader trend of mobile-first solutions in the industry, allowing its users to stay updated no matter where they are. 1.3 Goal and research questions The objective of this research and development project is to discover the most relevant performance tracking metrics in Agile projects and to leverage their power in a project management platform. The outcome of this project will bring a big benefit in the industry, both for Software Developers and Project Managers, as it will not only serve as a tool for tracking and managing tasks but also as a platform for measuring and analyzing performance metrics. In order to concentrate the exploration into the development of the project, we have identified several key research questions. These questions represent fundamental considerations that target the design, functionality, and effectiveness of the application. They serve as a guide, directing our research efforts towards the most important topics for the successful realization of our project. The following research questions have been formulated to describe integrating project management features, performance metrics, and third-party platforms in a user-friendly mobile application interface. Q1. Which metrics should be used? 8 After the initial sketching of the Work plan table, the author has developed a more detailed representation of the project’s available timeline, divided in relevant stages, both related to the practical project (application), but also the research (written paper), as following: February (4 weeks) ●Project Initiation and Initial Research ○The project begins with setting up the local learning dashboard, providing a crucial foundation for understanding and utilizing the tool throughout the project. ○Concurrently, an in-depth study of Agile metrics is initiated. Grasping these metrics is integral as they underpin the performance tracking features of the project. ○Research questions are defined, offering guidance and maintaining focus on the project's objectives. ●Work Plan Development and Market Analysis ○A comprehensive work plan is formulated to ensure efficient task management and time allocation. ○A 'State of the Market' analysis is conducted to investigate existing solutions, identify potential gaps, and understand how the project can provide innovative or superior solutions. ●Project Timeline and Literature Review ○A Gantt chart is created to visualize the project timeline, providing clear start and end dates for each task. ○Work commences on the 'State of the Art for Metrics' section of the thesis. This involves reviewing secondary papers to gain an understanding of existing theories and practices in the field of performance tracking metrics. March (4 weeks) ●Paper: Introduction, Motivation, and Objectives ○The paper commences with an overview of the project's context, significance, and aims. ●App: Flutter Learning 15 ○Learning of Flutter, a powerful framework for mobile application development, is initiated to lay the foundation for the mobile dashboard's development. ●App: Mock-Up Creation and User Profile Definition ○A mock-up of the application is developed using Flutter, reflecting the project's objectives. ○Potential user profiles are defined, and brainstorming sessions are held to devise relevant questions to understand their requirements and preferences. ●Paper: User Feedback ○Questionnaires based on the mock-up are created to gather user feedback. ○Feedback received is reviewed, analyzed, and documented. ●Paper: Solution Design ○The design of the proposed solution is outlined based on the feedback received. April (3 weeks) ●App: Continuous learning ○During this period, learning of Flutter continues, and the acquired skills are practiced. ○Work on the mock-up persists, implementing the features required for the application. ●Paper: Proposal Development ○The section detailing the development of the proposal or technique commences, to be completed once the solution is more fully defined. May (4 weeks) ●App: MVP Implementation ○The development of the Minimum Viable Product (MVP) of the application starts. This version contains the most essential features of the application. ●Paper: User Feedback ○Another round of questionnaires, based on the MVP, is created to gather additional user feedback. ●App: Feature Refinement 16 ○Based on the feedback, the functionalities of the app are refined and polished. ●Paper: User Testing ○User testing is conducted, and the results are documented. June (3 weeks) ●Master Thesis Presentation ○The master thesis presentation is prepared, summarizing the work and findings. ●Paper: Final Touches ○The remaining chapters of the paper are completed. ●Thesis Presentation ○The master thesis is presented to professors, peers, or other relevant parties. This extended work plan provides a detailed guide for the master thesis project, breaking down each task into manageable steps. 17 4. Feasibility, overall economic analysis and comparison with other alternatives 4.1 Cost estimation A well-structured cost estimation is critical to ensuring that a project is executed efficiently and within the allocated budget. We are employing a quantitative assessment of the resources needed to complete the project activities, in order to get an insight into the financial feasibility of the project. Cost estimation is an integral part of project planning. In the context of this project, we will be evaluating the cost estimation based on two main resources: human resources, which encompass the time and expertise of the individuals working on the project, and material resources, which include any physical or digital assets used in the project execution. Given the nature of our project, human resources play a significant role, and hence, a detailed breakdown that uses hourly salary rates collected for [2] is provided below (Table 1). Human Resource Time assigned Cost estimation Project Manager 7 hours / week, 20 weeks Hour: 19.23 EUR Total: 2692.2 EUR Research Specialist 16 hours / week, 20 weeks Hour: 18.04 EUR Total: 5772.8 EUR Software Engineer 22 hours / week, 20 weeks Hour: 17.79 EUR Total: 7827.6 EUR Total: 16.292,6 EUR Table 1. Human resources cost estimation Here is a detailed breakdown of each of the Human Resources roles: ●Project Manager (approximately 15% of the time): This role is responsible for carefully developing project plans and helping keep the development on track. In our project of 900 total hours, the project manager would have spent around 135 hours (900 * 0.15), translating to roughly 7 hours per week over a 20-week period. 18 ●Research Specialist (approximately 35% of the time): This role is responsible with conducting high quality research on the market and performance metrics topic. The research specialist would have worked for about 315 hours (900 * 0.35), representing approximately 16 hours a week over a 20-week period. ●Software Developer (approximately 50% of the time): The role involves designing, implementing, testing, and maintaining the software application. They would have dedicated around 450 hours (900 * 0.50) to this project, which equates to approximately 22 hours a week over a 20-week timeframe. Material resources necessary for the research and development of the project are very important to consider when studying the feasibility, so that we can plan the budget accordingly. For this project, only two devices have been used: one laptop and one tablet. We use their power consumption ratings, together with the price for 1 KWh in [3] to estimate the costs of the consumed energy by these devices. Material Resource Electricity price Consumption Cost Laptop 1 KWh = 0.34 EUR 100 watt-hour, 900 hours Hour: 0.034 EUR Total: 30.6 EUR Tablet 28.6 watt-hour, 450 hours Hour: 0.01 EUR Total: 4.5 EUR Total: 35.1 EUR Table 2. Material resources cost estimation According to Table 2, by considering each material resource energy consumption and the electricity price, we obtain a total cost of 35.1 EUR for the duration of research and development. 5. Sustainability report In this chapter, we make an examination of the project's sustainability in three key areas: Economic, Environmental, and Social. This analysis will be executed 19 using an instrument known as the Sustainability Matrix. This matrix serves as a tool for obtaining an overview of the project's impact, taking into account both the current research and development phase as well as the project's entire lifespan. The matrix helps us evaluate our project across three stages: the Project Put into Production (PPP) stage (includes planning, development, and deployment), the Lifetime stage, which represents the period from the project's implementation to its conclusion, and the Risks stage, which is used for the identification of potential issues or threats that could surface throughout the project's duration. We populate the matrix by responding to a series of questions, which belong to two categories: those related to the project's early stage (designated by "I") and those related to the final stage (designated by "F"). Some questions apply to a large-scale engineering project but not to a final degree project (TFG), and they are indicated with "P". For a detailed evaluation, we will assign a corresponding value to each cell, representing the specific intersection of dimension and stage. This value will provide a qualitative assessment of our project's sustainability across the mentioned dimensions and stages. [4] The formula applied for calculating the overall sustainability matrix result is: 𝑆𝑦𝐶𝑆 = 𝑃𝑃𝑃 + 2*𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒 − 2*𝑅𝑖𝑠𝑘𝑠 Through this systematic and comprehensive evaluation, we hope to ensure that our project isn't just successful in its immediate outcomes or profitability. Rather, we aim to ascertain that it also contributes positively to broader economic, environmental, and social contexts. In the following sections, we will delve into each of these areas in more detail. Project Put into Production (PPP) Lifetime Risks Environmental Design consumption Ecological footprint Environmental risks 20 9 18 -7 Economic Bill Viability plan Economic risks 8 16 -6 Social Personal impact Social impact Social risks 8 16 -7 Sustainability 8 17 -7 Result: 28 Table 3. Sustainability matrix According to the cited paper, the scores for each cell must be assigned based on a self-assessment, with respect to the possible value ranges (PPP: 0 - 10; Lifetime: 0 - 20; Risks: -20 - 0), and also considering the responses to the questions. The following section expands on the details for choosing each score: Economic Dimension ●Project Put into Production (PPP): The economic feasibility of this project was assessed from the outset, considering the costs associated with the development tools, platforms, and resources needed. As we opted to use open-source and free tools like Flutter and Firebase, the direct financial costs were kept minimal. The main economic factor was the time and effort spent by the developer, which is an investment towards building a valuable skill set and creating a useful project management tool. ●Lifetime: Once implemented, the economic sustainability of the project is maintained through its continued utility and minimal maintenance costs. As the tool is designed to help improve project management efficiency, it contributes to economic sustainability by potentially saving time and resources for its users. ●Risks: The major economic risks include the potential for increased competition in the project management software market, and the necessity for ongoing updates and maintenance to keep the tool relevant and useful. 21 Environmental Dimension ●PPP: The project was developed digitally, requiring only the use of computing resources. Thus, it had a low environmental footprint during the production phase, with the main impact being energy consumption for the development and testing processes. ●Lifetime: The environmental impact during the life of the project remains low. As a digital tool, it does not contribute to physical waste, and it promotes remote work and digital collaboration, which can reduce travel-related carbon emissions. ●Risks: The environmental risks are minimal, given the digital nature of the project. One potential risk could be increased energy usage if the tool becomes widely adopted and used extensively. Social Dimension ●PPP: During the development phase, social sustainability was considered by ensuring the project was developed ethically, respecting intellectual property rights, and adhering to industry best practices. ●Lifetime: The tool can contribute to social sustainability by improving project collaboration and communication, promoting efficient work practices, and potentially enhancing work-life balance if it helps to streamline project processes. ●Risks: Social risks include the potential for misuse of the tool (e.g., over-monitoring of employees), and the necessity to ensure ongoing data security and privacy protections for users. 22 5.1 Economic dimension For the research and development of this project, the author has been involved, with the guidance of the supervisors, as a solo developer in the process of planning, designing and creation of the mobile application. Given this project team composition, a very important factor when considering the economical dimension of this project is the human resources (my developer salary during the PPP stage) and the cost of hardware and software resources. Resource Cost Human resources 16,292.6 EUR Hardware resources 35.1 EUR Software resources 0 EUR Office resources 0 EUR Total: 16,327.7 EUR Table 4. Economic estimation The considered human resources represent the various roles the author had during the project research and development, for the interval of 1 February 2023 - 26 June 2023, totalling 16,327.7 EUR for the whole PPP stage. The hardware resources are represented by the laptop that has been used for research and development during the whole duration of the project, a MacBook M1 Pro 2021 16-inch, and a tablet that was used as an external monitor for the laptop and for notes, an iPad Air 4 64GB 2020. The software and office resources are totalling 0 EUR during the research and development of the project, thanks to the possibility of remote work, and the use of open source / free tools such as Android Studio, Flutter, Figma, Google Docs. 23 5.2 Environmental dimension The environmental dimension is an integral component of any project's sustainability, reflecting our growing consciousness about the planet's health and our responsibility towards it. While developing the project, it was not only essential to consider the direct impact on the environment but also to factor in how our choices and processes can contribute to a more sustainable world. In our case, the remote work setup means saving power consumption and carbon emission related to commuting from home to the university or another office, as well as consuming resources while working in the office, such as electricity, gas, water. During the PPP stage, the laptop and tablet combined had a power consumption rating of around 128.6 Watt-Hour. Resource Calculation Power consumption Laptop 100 Watt-hour * 900 hours 90 KWh Tablet 28.6 Watt-hour * 450 hours 12.87 KWh Total: 102.87 KWh Table 5. Power consumption calculation By multiplying the power consumption rating of each resource with the amount of time the specified resource has been used during the project’s research and development, and adding all these values, we obtain a total of 102.87 KWh consumed between the start and end of the work. 24 data-driven insights facilitate informed decision-making and ensure teams can respond promptly to any changes or issues. ●Shortcut: Reporting and data visualization are critical for effective project management. Shortcut offers a limited yet very useful range of reports that can be used to track the performance and progress of a project, including Velocity, Burndown, Cycle / Lead Time charts. ●Jira and Shortcut share some important common performance metrics, such as: Velocity, Burndown, Cycle Time, Cumulative Flow Diagram. This is a strong signal that these four metrics are relevant in the industry 6. Mobile Access ●Jira: With mobile and web applications, Jira allows users to stay connected and updated, no matter where they are. This can significantly enhance productivity and ensure that all team members are always in sync. ●Shortcut: The availability of a mobile application can offer increased convenience and accessibility, especially for teams that work remotely or have flexible working arrangements. Shortcut does not offer this feature yet. In conclusion, while both Jira and Shortcut offer robust capabilities for project management, they cater to slightly different use cases and user preferences. Jira offers a more comprehensive feature set, suitable for larger organizations and more complex projects. 31 7.2 Literature review In this chapter, we present the results of a thorough literature review conducted on the topic of performance metrics used in Agile software development teams and projects. The primary aim of this research was to identify and understand the key performance metrics relevant to Agile teams and their impact on software development projects, in order to complete the first two objectives and answer the research question Q1. An initial exploration of the performance metrics for Agile projects revealed a high number of primary studies, focused on specific areas of performance. At the same time, multiple secondary studies which considered a higher number of metrics and concepts have been observed, and in order to obtain a better coverage of the field, we decided to focus on the secondary papers. The literature review encompassed seven secondary papers on the topic. Each of these papers discussed the impact of various performance metrics on the projects they evaluated and whether these metrics were relevant in tracking the performance of the software development teams involved. After an in-depth analysis of these papers, a comprehensive table was compiled. This table aggregates all the performance metrics mentioned across all the papers. For each metric, the table highlights the number of times it was mentioned and the number of times it was considered to be of high relevance or impact. The table serves as a valuable resource for understanding the state of the art in performance metrics for Agile teams. It provides a consolidated view of the metrics that are commonly mentioned in the literature and those considered to be highly impactful or relevant. This research serves as a crucial foundation for the development of our project management application. It provides insights into the types of metrics that Agile teams find valuable and those that have a significant impact on project outcomes. These insights will guide the development of the performance tracking functionality in our application, ensuring it provides meaningful and relevant data to Agile teams. In the following sections, we will provide a detailed discussion of the most frequently mentioned and impactful metrics, as well as the insights gained from the literature review. 32 7.3 Literature review The research effort was focused on the topic of performance metrics used in Agile software development teams and projects. Therefore, pursuing high quality and relevant secondary research in this area, the author used the following query string on Google Scholar: allintitle: agile metrics systematic (review OR mapping). The resulting papers were as follows: S1. Using metrics in Agile and Lean Software Development – A systematic literature review of industrial studies by Eetu Kupiainen, Mika V. Mäntylä, Juha Itkonen, 2015 [1] S2. Software Process Metrics in Agile Software Development: A Systematic Mapping Study by Syeda Sumbul Hossain, Pollab Ahmed, Yeasir Arafat, 2021 [10] S3. Productivity Metrics for an Agile Software Development Team: A Systematic Review by Giovanni Hernández, Álvaro Martínez, Robinson Jiménez, Franklin Jiménez, 2019 [11] S4. How Agile Organizations Use Metrics: A Systematic Literature Mapping by Stephanie Leal, Jean C. R. Hauck, Gustavo Vieira, Monique Bertan, 2022 [12] S5. Use of software and project management metrics in agile software development methodologies by Dimitrios Chloros, Vassilis C. Gerogiannis, George Kakarontzas, October 2022 [13] S6. Potential Metrics for Agile and Lean: Systematic Literature Review and Survey by Kalyan Chakravarthy Maddila, 2015 [14] S7. Systematic Review of Metrics in Software Agile Projects by Amrita Raj Mukker, Dr. Latika Singh, Anil Kumar Mishra, 2014 [15] 33 7.4 Discussion In this subchapter, we provide an overview of the seven secondary papers (referred to as S1 through S7) that were reviewed as part of our literature review. Each paper offered unique insights into performance metrics used in Agile software development projects, contributing to our overall understanding of the subject. After the initial papers exploration part, the author has established a set of criteria, academically known as inclusion and exclusion criteria, that will help us focus on the right types of papers, without going out of the scope. (Table 7) Criteria code Criteria description Inclusion Criteria IC1 Topic relevance: The secondary study should focus on performance metrics related to Agile project management, Scrum, or Agile software development practices. IC2 Quality of research: The secondary study should demonstrate a rigorous research methodology. Exclusion Criteria EC1 Non-English language: Studies that are not available in English may be excluded due to language barriers. EC2 Lack of empirical data: Studies that do not present empirical data, such as opinion pieces or editorials, may be excluded. Table 7 - Inclusion and Exclusion criterias S1 was considered the most valuable source because it provided a dual-dimensional view of each metric: its occurrences and its importance. This approach allowed us to understand and identify a correlation between the popularity of certain metrics and their actual relevance in Agile software development. 34 S2, while it discussed the impact of a couple of metrics, did not provide specific scores for these impacts and the occurrences of the specified metrics weren't clearly defined, making it less useful in our analysis. S4 contained a wealth of information, presenting over 300 metrics. However, it did not discuss their specific impacts on projects, so we decided to focus on the most frequently mentioned Product Quality metrics specified in the paper. S6 had an interesting approach where the metrics initially identified through a systematic literature review were further verified with industries by conducting an industrial survey. The metrics were then chosen based on the mean value of a score of satisfied respondents. This approach provided a valuable perspective on the industry's view of the metrics. S7 conducted a systematic review of metrics used in Agile projects, but did not provide as much detailed analysis or verification as S1 or S6. S3 and S5 have been kept out of the literature review conclusion because they did not meet the inclusion criteria. In conclusion, S1 and S6 were the most informative and useful papers for our state of the art research. They provided a comprehensive analysis of performance metrics and offered insightful perspectives, making them instrumental in shaping our understanding of the relevance and impact of different metrics in Agile software development. 7.5 Results Based on the literature review and the systematic analyses presented in the papers, we aggregated a total of 49 performance metrics used in Agile software development. The complete table of metrics is included in the Annex 13.4, but for the purpose of this chapter, we will present the top 11 metrics that were mentioned most frequently and deemed highly relevant in the papers. Each of these metrics provides a unique perspective on the performance of Agile teams, and their combined use can offer a comprehensive picture of a team's overall performance. Besides the Metric ID, Metric Name and Description column, in the table we can observe columns that reference each of the secondary papers that met the 35 inclusion / exclusion criterias. The values in the respective columns are either X, * or blank. X means that the metric on this row has been considered relevant in the paper referenced on this column, * means that the metric has been mentioned but not considered important in this paper, and blank means that the metric has not been mentioned in the paper. The Relevant mentions count column reflects the sum of the relevant mentions for that particular metric in all the included papers, so technically it is a count of value “X” on each row. Metric ID Metric Name Description S 1 S 2 S 4 S 6 S 7 Relevant mentions count M1 Velocity Feature points developed per iteration / sprint [1] X * X X X 4 M2 Lead time The average time it takes for one feature request to go through the entire process from start to finish [1] / release X X X 3 M3 Cycle time Time it takes for story to be completed [1] X * * X 2 M4 Burndown Amount of work to be done or the number of story points to be done in a Sprint [3] * X X * 2 M5 Defect count Not defined in primary study. Probably means amount of defects after first round of testing [1] or defects per iteration - This metric is calculated either as a simple count or count weighted by the severity of defects [15] X * X 2 M6 Technical debt Technical debt in amount of hours it would take to fix all the issues increasing technical debt calculated by third party tool called Sonar [1] X X 2 M7 Queue time The average time between sub-processes that the request sits around waiting [1] X X 2 M8 Work in progress Amount of stories per work phase (sprint?) [1] X * X 2 36 Metric ID Metric Name Description S 1 S 2 S 4 S 6 S 7 Relevant mentions count M9 Cost types Cost distribution of a requirement [1] X X 2 M10 Test coverage How much Source Code executed during Test Execution [1] X X * 2 M11 Time in state Average time a task remains in a state (To do, In Progress, Block, Stopped Progress, In code review) [11] X 1 Table 8. Most frequent and relevant metrics 7.6 Conclusions Given the State of the art table that the author has compiled, which includes the best performance metrics we have found in literature review, we are in a good position to select the metrics that will be used in the application and answer the research question Q1. For the metrics selection, we have considered the following criterias: 1. It must be of a high relevance 2. It must be easily represented as a numerical value, either integer or decimal 3. It must be computable based on the data that the application is going to work with - like tasks dates and story points Based on these criterias, we have completed the first two objectives of the project, by answering the research question Q1 “Which metrics should be used?”. The metrics, which were carefully chosen so that they also make sense in our project, are the following: ●Velocity ●Lead time ●Cycle time ●Queue time ●Time in state 37 8. Specification and design of the solution 8.1 Specifications 8.1.1 Functional requirements Task Management 1. As a user, I want to create and edit tasks. Acceptance Criteria: ●The application displays an interface for managing tasks. ●I can add a new task with a title, description, story points, owner, sprint, priority, state. ●I can edit the details of an existing task. ●I can assign a task to another team member. 2. As a user, I want to view tasks. Acceptance Criteria: ●I can see a list of the tasks. ●I can open a task and see all its details. 3. As a user, I want to estimate tasks using story points. Acceptance Criteria: ●I can assign a number of story points to each task. ●The total number of story points is calculated for each sprint. Sprint Management 4. As a user, I want to create and edit sprints. Acceptance criteria: ●The application displays an interface for managing sprints. ●I can create a new sprint with a name, start date and end date. 38 ●I can edit the details of an existing sprint. 5. As a user, I want to view sprints. Acceptance criteria: ●The application displays a list of all the sprints of the project. ●For each sprint, I can see the name, progress, start date, end date and story points. ●I can see the boards and tasks that are related to a particular sprint. Project Management 6. As a user, I want to select a project. Acceptance criteria: ●I can view a list of all the available projects. ●I can select a project from the list. 7. As a user, I want to connect a project to a GitHub repository. Acceptance Criteria: ●I can link a GitHub repository to a project. ●The application retrieves data from the linked GitHub repository. Performance Metrics 8. As a user, I want to view performance metrics. Acceptance Criteria: ●The application displays a dashboard with performance metrics. ●I can select one or more sprints to view the evolution of metrics. ●I can visualize an individual metric’s evolution across multiple sprints. 39 User Management 9. As a user, I want to log into my account. Acceptance Criteria: ●The application displays an interface for login. ●I can login with my account’s credentials. 8.1.2 Non-functional requirements (using Volere’s Requirements Template [39]) Requirement Description Justification Acceptance criteria 10th Appearance The application must have a clean and intuitive user interface. A well-designed and intuitive interface will promote better user engagement and easier interpretation of the metrics. The validation phase feedback regarding user interface must be positive. 11st Ease of use The application must be easy to navigate and have accessible features. Performing common tasks should not require complex steps. Ease of use is important for user adoption and for the efficiency of task completion in the app. The users are able to navigate through the app and perform tasks by themselves during validation. 11c Learning Learning and understanding how to use the app should take a minimum amount of time and any complex features should have Any user in the IT industry should be able to learn to use the app. The participants in the validation phase understand and learn to use the app in a very short 40 This subchapter provides a visual overview of the implemented screens in the mobile dashboard application. Each subsection presents a pair of screens, offering a glimpse into how they function within the application. Home Screen and Project Selector Screen Home screen: The Home screen is the first page that a user sees after selecting a project. It presents the currently selected project and offers the option to choose another one. This screen also displays the name and progress of the active sprint, the total number of tasks assigned to the user, and the top three tasks ranked by priority. Two call-to-action buttons lead the user to the Workspace - the main feature of the app where tasks, boards, and sprints are interacted with - and to a quick overview of the user's current tasks. Project Selector screen: This screen is displayed when the user first opens the app or decides to select a different project. It showcases all available projects for the current user, providing details like title, description, and deadline. Figure 8. Home screen and Project Selector screen 47 Performance screen and Metric Details screen Performance screen: The Performance screen allows users to track performance across selected sprints. It features a radar chart that focuses on the main performance metrics, and allows comparison of performance evolution across the sprints. This screen also offers the ability to connect to a GitHub repository and visualize individual metrics. Metric Screen: The Metric Details screen enables users to view an individual metric's evolution across selected sprints. It provides the name and description of that metric for easy identification and understanding. Figure 9. Performance screen and Metric Details screen 48 Sprints screen and Sprint Details screen Sprints screen: This screen presents a list of all the sprints that were created for the selected project. It provides information like sprint name, completion status, and the current deadline state (whether the sprint will start in X days, end in X days, or ended X days ago). Clicking on a sprint navigates the user to the Sprint Details Screen. Sprint Details screen: The Sprint Details screen displays all the boards and tasks assigned to the selected sprint, along with general information such as the Sprint name, start and end dates, assigned story points, and completion status. The example below showcases three boards: To Do, In Progress, and Done. Tapping on any task will open the Task Details Screen. Figure 10. Sprints screen and Sprint Details screen 49 Task Details screen and Sprint Creation screen Task Details screen: This screen is accessed when a user clicks on a specific task or wants to create a new task. It displays all the attributes that a task can have, including title, description, story points, assigned user, assigned sprint, priority, and progress state. Sprint Creation screen: This screen allows users to create a new sprint by providing a name, and optionally, start and end dates. Tasks are assigned to a sprint individually, providing a user experience similar to other popular project management platforms. Figure 11. Task Details screen and Sprint Creation screen 50 The implementation of these screens represents the translation of our design work into a functioning application. Our focus has been on creating a user-friendly interface that offers clear navigation and a comprehensive overview of project metrics and tasks. The following chapters will delve into further aspects of the application's development. 8.2.1.4 Navigation The navigation within the application has been designed following two standard patterns commonly used in modern mobile applications. These patterns aim to make the app intuitive and easy to navigate, enhancing the user experience. Overall application navigation The navigation within the app follows a typical mobile interface design pattern, often referred to as a [18] pattern. This navigation style is prevalent in mobile applications due to its intuitive nature and seamless user experience. In this pattern, when a user interacts with an element that triggers navigation, such as clicking on a task or a button, a new screen is pushed onto the top of the navigation stack. This new screen overlays the current screen, becoming the active interface that the user interacts with. The stack nature of this navigation pattern becomes evident when a user wants to return to the previous screen. Either by tapping the back arrow within the application or using the device's back button or gesture, the current screen is "popped" off the stack. This action dismisses the current screen and reveals the previous one underneath, effectively navigating back. This pattern allows for intuitive forward and backward navigation within the app, contributing to a user-friendly and efficient user interface. In the following Figure 12, which can be viewed in full size in the Annex 13.5, we can observe the application’s overall navigation diagram, including all the screens and the possible navigation actions as arrows. 51 Figure 12. App navigation diagram Bottom navigation bar The main or root navigation of the application is based on a bottom navigation bar. This navigation bar is visible at the bottom of the screen and provides access to the main features of the application. The bottom navigation bar includes two primary destinations: ●Home screen ●Performance screen The following figure 13 shows the bottom navigation bar, highlighting the options for the Home and Performance screens. 52 Figure 13. Bottom navigation bar Tab bar navigation The secondary layer of navigation exists within the Workspace and is based on a tab bar navigation design. The tab bar, located at the top of the screen, allows the user to navigate between various Workspace destinations, such as tasks, boards, sprints, and others. Below is an image depicting the tab bar navigation within the Workspace. The different tabs for tasks, boards, and sprints can be clearly seen. Figure 14. Workspace tab bar navigation The combination of bottom navigation bar and tab bar navigation enables users to move seamlessly through the application, accessing key features and content with ease. The following sections will delve into further aspects of the application's development. 53 8.2.2 Internal design 8.2.2.1 Initial evaluation During the initial period of research for this project, the evaluation session also included discussions with the thesis supervisors regarding the right platform and technologies to choose for the development of the application. Besides the Flutter option, an obvious alternative was developing an application for the Android ecosystem, considering the author’s experience with Android development. Here are a couple of considerations for Android: ●Development time: Given the existing experience with Android development, we may have been able to reduce the time spent learning a new language and could have potentially started the development process sooner. This could have resulted in a shorter overall project timeline. ●Platform-specific features: Android development might have allowed you to leverage platform-specific features more easily, potentially adding more value to the app for Android users. ●Cross-platform limitations: The downside, however, would be the limitation of the app to only Android users. Although there were some strong considerations for an Android native application, we have decided that Flutter would be a better choice, due to the following advantages: ●Cross-platform support: the Flutter app is cross-platform, thus making the project more accessible to a wider range of users (including iOS, web, desktop users), which is a significant advantage. ●Hot reload feature: allows the developer to visually observe the code changes he made immediately, without rebuilding the application ●Application performance: because Flutter apps are compiled to native code, the performance impact is minimal, compared to writing a native application. ●Growing community and support: Flutter still has a growing community and strong support from Google. This means it's easy to find help, tutorials, and libraries that can speed up development and solve common problems. 54 Among the debated subjects regarding the functionality of the application and the research direction, we have also discussed providing more integrations - besides GitHub, other Git platforms like [19], or some project management tools like [20]. Here is an overview of the considerations regarding this decision: ●Development time & cost: Integrating with multiple platforms can be a complex task, potentially increasing the development time and cost. Depending on the platforms, we might have had to deal with different APIs, data formats, authentication methods, etc. This could have increased the project's complexity and required more resources, potentially reducing the number of project management features we could’ve implemented in the app. ●User Experience: More integrations might have made the app more versatile and adaptable to various workflows, potentially attracting users who rely on multiple platforms for their work. However, reducing the project management features might have limited its standalone utility as a comprehensive project management tool. ●Performance metrics feature: If less time was spent on project management features, there might have been more time to refine and expand the performance metrics feature. This could have resulted in a more comprehensive and detailed performance analysis tool. However, the usefulness of these metrics would be highly dependent on the reduced project management functionality. If essential features were lacking, the metrics might not have been as valuable or actionable. These alternatives highlight some of the trade-offs involved in project decisions. The requirements of balancing the need for cross-platform availability, comprehensive project management functionality, and meaningful performance metrics were decisive for our choice to develop a Flutter app with a focus on project management features. 8.2.2.2 Architecture 8.2.2.2.1 Flutter architecture analysis 55 The architecture of a system represents the structure that supports all the functionalities and capabilities, dictating its performance, extensibility, and maintainability. The choice of architecture is a critical decision in the system's development process as it determines how the system will respond to changes in requirements, how it will scale, and how easy it will be for other developers to understand and work on. In the context of our project developed using Flutter, our choice of architecture takes into account the unique requirements and constraints of the platform, the type of data we are dealing with, the need for responsiveness, and the necessity to deliver an exceptional user experience. This chapter will provide a comprehensive overview of the chosen architecture. We will explore the different components of the system, including the data layer, repositories, models, and user interface, and examine how they interact with each other to create a consistent whole. We will also dive into the reasons behind our architectural choices, the benefits and drawbacks of the chosen approach, and how it compares with other popular architectures in the Flutter ecosystem. Following the decision to use Flutter as the development platform for our project, the author has conducted a thorough analysis of the state of the art of Flutter architecture in 2023. Continuously keeping in mind our project’s specifications and requirements, we carefully reviewed three architectural patterns pros and cons, that would then be compared for the final decision of choosing the most suitable architecture for our project. The three architectural patterns we considered are: Redux, Provider + ChangeNotifier and Repository + ValueNotifier. In the following section, we can observe the information and analysis that has been made. Redux 56 repositories, which manage data access and conversion. The repositories return domain models, encapsulating the necessary fields, which are then consumed by the UI layer. The following figure presents an example of a conversion from the data model that is received by the repository, to the domain model that is returned by the repository method. Figure 19. Data model to domain model conversion example In alignment with DDD, we also utilize a Ubiquitous Language, a shared language that is used by the author and the thesis supervisors and is structured around the domain model. The domain models such as “Project”, “Task”, “Board”, “Sprint”, “Metric” serve as part of this language, allowing for clear and consistent communication about the core business concepts. While our application does not fully incorporate all aspects of DDD, such as Bounded Contexts and Aggregate Design, it nonetheless embodies the core principles of this approach. By prioritizing the core domain and domain logic, we have developed an application that is both robust and flexible, capable of evolving in response to changing business needs. [28] 8.2.2.2.5 Repository pattern The Repository Pattern is a key aspect of our application's architecture. It forms an abstraction layer between the data layer and the rest of the application, providing a way to access the domain data from various sources in a consistent manner. Applying this pattern to our implementation allows the application to have a dedicated layer of components that are specialized in dealing with the data, both from the requests, responses and data conversion point of view, but also from a 63 persistence point of view, enabling the application to cache data in memory with a lifecycle smaller or equal to the whole application’s lifecycle. A brief example of applying this pattern is the UsersRepository, that offers two main functionalities: fetching a list of users, and caching the list of users in memory. Figure 20. UsersRepository This is a short but powerful example of this layer of persistence. The great benefit comes on the consumer side. In the following example, we can observe the Team screen, where we listen to the ValueNotifier which caches the list of fetched users from the UsersRepository, and thanks to this pattern the consumers side (UI in this case) does not have to deal with any part of data fetching, conversion, or error handling. At the same time it does not even have to know the data source - the information could come from Firebase or from a totally different source, such as the local database, or a Web service. [29] 64 Figure 21. Repository data consumed in UI 8.2.2.2.6 Firebase In order to offer a seamless user experience and work efficiently, we have decided to use Firebase for data storage in the cloud. The Cloud Firestore service offered by Google represents a “scalable NoSQL cloud database to store and sync data for client- and server-side development” [30]. It basically is a very powerful Backend-as-a-Service that allows the application to stay in sync with the data in the cloud every time it is connected to the internet. On the other hand, Firebase offers a very powerful yet easy to use SDK, which empowers the developers to achieve the intended behavior with less effort compared to other solutions. The following figure presents a chain of function calls that request all the tasks from Firestore, that belong to the selected project and are assigned to the current user: Figure 22. Firestore tasks fetching 65 8.2.2.2.7 Declarative UI Declarative UI is a programming paradigm that allows developers to describe what the user interface should look like based on the current state of the application, rather than how to change it over time. This approach abstracts away the need for direct manipulation of the UI elements, instead, the developer simply declares the state of the UI that they want, and the framework figures out how to get there. Flutter is built around this concept of declarative UI. In a Flutter app, the UI is defined as a tree of widgets, where each widget describes part of the UI in the current frame. When the state changes, a new widget tree is generated (Figure 23), and the Flutter framework diffs the new and old trees to determine the most efficient way to update the UI. [31] This approach has several benefits: ●Simplicity: The state describes the UI at one point in time, so there is no need to keep track of changes over time and manage transitions between states. ●Consistency: Because we are defining the state of the UI, it's much easier to keep the UI consistent across different parts of the app or even across platforms. ●Efficiency: Flutter's diffing algorithm allows for efficient updates to the UI, as only the widgets that depend on the changed state are rebuilt. Figure 23. Declarative UI representation [31] In the following example, we can observe a StatelessWidget that draws a pie chart, being defined with multiple attributes and values. The only way to change its appearance is by updating the progress value, which it uses as one of its parameters. 66 Figure 24. Pie Chart widget 8.2.2.3 Technology Stack A Flutter application represents a complex technology stack, which starts from bottom to top with the Embedder, the component that has a special implementation based on the platform the app is built on (Android, iOS, Linux, etc) and handles the core OS concepts like threading and rendering. It follows with the C/C++ Engine which contains low level components, and it concludes with the Dart Framework, which contains the high level components that we use in the applications. (Figure 25) On top of this Flutter technology stack, we also have the third party libraries, which are manually included based on the app’s requirements. Our application uses collection,http and intl to handle the core functionalities of working with collections, making HTTP requests and formatting dates. Other important libraries that we use are get_it for dependency injection, firebase_core and cloud_firestore for the Firebase services, and several charting libraries. 67 Figure 25. Flutter architectural overview [32] 8.2.2.4 Design patterns “Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.” [33] Our application makes good use of these patterns to improve the structure of the code through the following: ●Singleton pattern: The dependency injection framework called GetIt that is used in our app supports the Singleton Pattern by allowing registration of services as lazy singletons. For example, all the repositories in the app are registered as lazy singletons. This ensures that only one instance of each repository exists during the runtime of the application and provides a global access point to those instances. [34] ●Observer pattern: The ValueNotifier library represents a good showcase of an Observer pattern implementation. As per the definition, the object maintains a list of its observers and notifies them automatically of any state changes [35]. Our application is using this component in many places to ensure a reactive design. 68 9. Development of the work 9.1 Tools 9.1.1 Integrated Development Environment (IDE) Android Studio [36] is a very powerful IDE created and maintained by Google, on top of the IntelliJ IDE owned by JetBrains. The author has used it extensively in order to develop the Mobile Dashboard application, thanks to the support that Google offered for Flutter, Android Studio being the primary development environment for native Android applications. Some important features of Android Studio are: support for Git operations, integrated mobile device emulators and intelligent code autocompletion. Apart from the powerful tooling, this IDE also offers a great development experience thanks to its various visualisation options, such as Package manager, Console and Terminal. The following figure depicts the standard view the author has used during the development. Figure 26. Android Studio 69 9.1.2 Version Control System (VCS) VCS is an important part of software development for reasons such as keeping a history of all the updates to the project, better structuring the work, separating the workspace between different features that are implemented at the same time, and many more. For this project, the author chose the most popular Version Control System: Git, together with the GitHub platform. The project can be found at the following link: https://github.com/andreimesina/mobile-dashboard. At the same time, the application .APK file is available to test at the following link, through Firebase App Distribution: https://appdistribution.firebase.dev/i/92484683f1adddfa. 9.2 Metrics development 9.2.1 Velocity [1]: Measures the amount of work (story points) a team completes during a sprint 𝑉𝑡𝑎𝑠𝑘𝑠=𝑖=0 ∑𝑡𝑎𝑠𝑘𝑠𝑖 9.2.2 Lead Time [1]: The total time from the moment a new task is created until it is completed. It can help teams understand the duration of their workflow. 𝐿𝑡𝑎𝑠𝑘𝑠=𝑖=0 𝑛−1 ∑𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐷𝑎𝑡𝑒 −𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐷𝑎𝑡𝑒 𝑛 9.2.3 Cycle Time [1]: The time it takes for a task to go from started to completed. It's a good indicator of the efficiency of a team's workflow. 𝐶𝑡𝑎𝑠𝑘𝑠=𝑖=0 𝑛−1 ∑𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐷𝑎𝑡𝑒 −𝑡𝑎𝑠𝑘𝑠𝑖.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐷𝑎𝑡𝑒 𝑛 70 9.2.4 Queue Time [1]: The amount of time a task spends waiting to be moved to in progress. Monitoring queue time can help teams spot bottlenecks and improve their process efficiency. 𝑄𝑡𝑎𝑠𝑘𝑠=𝑖=0 𝑛−1 ∑𝑡𝑎𝑠𝑘𝑠𝑖.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐷𝑎𝑡𝑒 −𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐷𝑎𝑡𝑒 𝑛 9.2.5 Time in State [11]: Measures how long a task remains in a particular state (like 'To Do', 'In Progress', 'Done'). This metric can provide insights into how work is flowing through different states. 𝑇𝑆𝑡𝑎𝑠𝑘𝑠=𝑖=0 𝑛−1 ∑(𝑡𝑎𝑠𝑘𝑠𝑖.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐷𝑎𝑡𝑒 −𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐷𝑎𝑡𝑒) + (𝑡𝑎𝑠𝑘𝑠𝑖.𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐷𝑎𝑡𝑒 −𝑡𝑎𝑠𝑘𝑠𝑖.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐷𝑎𝑡𝑒) 2𝑛 71 10. Experimentation and assessment of the proposal/technique/work 10.1 Validation technique The development of this project placed a strong emphasis on validation and usability, ensuring that the final product would not only meet its functional objectives but also offer an intuitive and seamless user experience. We have decided that the best setup for the experimentation and validation phase of the project would be achieved in two distinct stages of testing: initial feedback gathering and post-implementation usability testing. These two stages proved to be critical for the research and development of the project, therefore also representing the answer to the research question Q3, which had an objective of creating questionnaires and holding interviews with relevant stakeholders. 10.2 Validation stages 10.2.1 Initial Feedback Gathering In the early stages of the project, an initial feedback gathering stage was conducted. This stage was designed to validate the main idea of the project and the proposed user interface designs, prior to any extensive development. During this stage, participants were presented with the project's Figma mock-ups, referenced in the annex 13.3. They were then asked a series of questions about their understanding of the project's purpose, their impressions of the design, and their thoughts on the proposed functionality. Their responses were carefully noted and analysed, offering invaluable insights that helped shape the direction of the project. This feedback was instrumental in refining our initial designs and making necessary adjustments before moving forward with the implementation phase. 10.2.2 Post-Implementation Usability Testing Upon completion of the project's implementation, we embarked on a comprehensive usability testing stage. This phase was conducted in a two-step process. 72 Figure 32. Design feedback chart Navigability: The navigation within the app was rated slightly lower, with a mean score of 4.25 out of 5. While the score is still high, indicating that users could navigate through the app with relative ease, there is scope for improvement. User feedback in this area should be closely examined to identify specific navigation elements or flows that could be optimized for a more seamless user experience. (Figure 33) Figure 33. Navigation feedback chart 79 Task creation, editing and progress tracking: All participants found the task creation and editing process in the app to be intuitive. This is a strong indicator that these core functionalities of the app align well with user expectations and work processes. The positive feedback suggests that the user journey, from creating to editing tasks, is smooth and straightforward. Although 75% of participants found it easy to track task progress in the app, 25% were unsure, meaning that while the task tracking feature generally meets user needs, there could be a subset of users who find it less intuitive or clear. It would be beneficial to gather more detailed feedback from these users to understand their challenges and refine the task tracking feature accordingly. (Figure 34) Figure 34. Tasks feedback charts Metrics and performance visualization: All participants found the selected metrics for project performance tracking to be useful, with a mean score of 4.25 out of 5. This feedback confirms that the chosen metrics effectively serve their purpose and align well with the users' needs in managing and evaluating project 80 performance. Participants also rated the ease of visualizing and understanding performance metrics highly, with a mean score of 4.5 out of 5. This indicates that the presentation of the metrics is effective and user-friendly. It also suggests that the visualization aids employed in the app, such as charts or graphs, are successful in conveying complex performance data in an easily digestible manner. Despite the opportunity to provide suggestions for different metrics or other ways to visualize them, no feedback was given by the participants in this area. This result can be interpreted in a positive light, as it suggests that participants found the existing selection and presentation of metrics satisfactory. (Figure 35) Figure 35. Metrics feedback chart 10.5 Validation conclusions The validation phase played an integral role in the development of our project. User experience emerged as a pivotal aspect of our app. During this phase, the participants highlighted the importance of displaying relevant and meaningful content. The participants needed clear, concise information that would assist them and improve their productivity. This led us to refine how we present information and performance metrics, focusing on clarity and ease of understanding. Lastly, the validation phase enabled us to test and fine-tune the newly incorporated features of our app. By gathering feedback and observing user interaction, we ensured these features genuinely added value and enhanced the 81 overall app experience, not only by improving the existing functionality, but also by adding additional information, like charts and explanations. In conclusion, validation was instrumental in moving our app from good to great. It wasn't merely a bug-checking exercise; it provided critical insights into user behavior, leading to an app that is not only functional but also user-friendly, meaningful, and relevant. 82 11. Conclusions The research and development activity conducted on the project was a success, obtaining good results in terms of the literature review, the performance metrics table serving as a great reference for the development of the Mobile Dashboard application, but also as a good source for future work, be it on the same project or for other developments. The technical development of the project was also a success, providing an important source of learning for the author with regards to many technologies, and generally the software development topic itself. We have achieved the proposed objectives of creating a MVP that contains the required project management and performance tracking features, and doing so, together with the literature and market analysis, we have managed to respond to all the research questions. Possible future work objectives could be developing the specific user interfaces for the other platforms as well (Desktop, Web), adding the possibility to insert user’s own custom metrics, and conducting more research in the direction of performance metrics categories - as a way to obtain even better context when visualizing the performance charts. 83 12. List of references used [1] Using metrics in Agile and Lean Software Development – A systematic literature review of industrial studies by Eetu Kupiainen, Mika V. Mäntylä, Juha Itkonen, 2015 [2] Average salary for a Software Engineer in Spain by Glassdoor - https://www.glassdoor.com/Salaries/spain-software-engineer-salary-SRCH _IL.0,5_IN219_KO6,23.htm [3] Price of electricity in Spain - https://www.globalpetrolprices.com/Spain/electricity_prices/ [4] Guía y evaluación de la sostenibilidad en los Trabajos de Fin de Grado by Fermín Sánchez-Carracedo, Jordi Garcia Almiñana, Eva Vidal, David Lopez et al, 2015 - https://www.researchgate.net/publication/335207262_Guia_y_evaluacion_ de_la_sostenibilidad_en_los_Trabajos_de_Fin_de_Grado [5] A comprehensive solution for risk management in software development projects by Dr. Raghavi K Bhujang, 2018 - https://www.academia.edu/52588051/A_comprehensive_solution_for_risk _management_in_software_development_projects [6] Analysis on Risk Management of Software Outsourcing Project by Jiongjie Zhang, 2022 - https://bcpublication.org/index.php/BM/article/view/1486 [7] Jira - https://www.atlassian.com/software/jira [8] Shortcut - https://www.shortcut.com [9] 10 Best Project Management Software of 2023 by Alana Rudder, Amy Smith - https://www.forbes.com/advisor/business/software/best-project-manageme nt-software/ [10] Software Process Metrics in Agile Software Development: A Systematic Mapping Study by Syeda Sumbul Hossain, Pollab Ahmed, Yeasir Arafat, 2021 84 [11] Productivity Metrics for an Agile Software Development Team: A Systematic Review by Giovanni Hernández, Álvaro Martínez, Robinson Jiménez, Franklin Jiménez, 2019 [12] How Agile Organizations Use Metrics: A Systematic Literature Mapping by Stephanie Leal, Jean C. R. Hauck, Gustavo Vieira, Monique Bertan, 2022 [13] Use of software and project management metrics in agile software development methodologies by Dimitrios Chloros, Vassilis C. Gerogiannis, George Kakarontzas, October 2022 [14] Potential Metrics for Agile and Lean: Systematic Literature Review and Survey by Kalyan Chakravarthy Maddila, 2015 [15] Systematic Review of Metrics in Software Agile Projects by Amrita Raj Mukker, Dr. Latika Singh, Anil Kumar Mishra, 2014 [16] Figma - https://www.figma.com/ [17] Nucleus UI: Mobile App - UI Component Library (Community) by Gray - https://www.figma.com/community/file/994524773760785442 [18] Principles of Navigation by Google - https://developer.android.com/guide/navigation/principles#navigation_state _is_represented_as_a_stack_of_destinations [19] GitLab - https://about.gitlab.com [20] Taiga - https://taiga.io [21] Flutter + Redux by Paulina Szklarska - https://hackernoon.com/flutter-redux-how-to-make-shopping-list-app-1cd3 15e79b65 [22] Single source of truth - https://en.wikipedia.org/wiki/Single_source_of_truth [23] ChangeNotifier by Google - https://docs.flutter.dev/data-and-backend/state-mgmt/simple#changenotifie r [24] ValueNotifier - https://api.flutter.dev/flutter/foundation/ValueNotifier-class.html [25] SOLID - https://en.wikipedia.org/wiki/SOLID [26] Clean Architecture by Robert C. Martin, 2012 - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.ht ml 85 [27] GetIt - https://pub.dev/packages/get_it [28] Best Practice - An Introduction to Domain-Driven Design by David Laribee - https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/be st-practice-an-introduction-to-domain-driven-design [29] Design the infrastructure persistence layer by Microsoft - https://learn.microsoft.com/en-us/dotnet/architecture/microservices/micros ervice-ddd-cqrs-patterns/infrastructure-persistence-layer-design [30] Cloud Firestore by Google - https://firebase.google.com/docs/firestore [31] Start thinking declaratively by Google - https://docs.flutter.dev/data-and-backend/state-mgmt/declarative [32] Flutter architectural overview by Google - https://docs.flutter.dev/resources/architectural-overview [33] What’s a design pattern? - https://refactoring.guru/design-patterns/what-is-pattern [34] Singleton - https://refactoring.guru/design-patterns/singleton [35] Observer - https://refactoring.guru/design-patterns/observer [36] Android Studio by Google - https://developer.android.com/studio [37] Validation feedback form by Andrei Mesinahttps://forms.gle/EL3bXjKMYrDeZ4v4A [38] Usability Testing - https://www.usability.gov/how-to-and-tools/methods/usability-testing.html [39] Volere Non-Functional Requirements Template - https://www.volere.org/templates/volere-requirements-specification-templa te/ 86 13. Annexes with supplementary information 13.1 Gantt Chart 87 13.2 Work plan overview 88 13.6 Application directories structure 95