Repository navigation
Assignment 3
Our prior solution solely provided support for displaying wait times for non-emergency services and the number of patients in queue at hospitals. However, our clients have requested the inclusion of wait times for emergency services within our system. The rationale behind this modification is to furnish patients with more comprehensive information, particularly those requiring immediate medical attention. Following the addition of this feature to our system, we were able to offer patients more accurate estimates of the waiting time for emergency services. The fishbone diagram below identifies possible causes for the lack of emergency wait time support.
Our clients expressed a desire to incorporate wait times for emergency services into our system, as they found our application to be lacking in user features. The addition of this feature has significantly enhanced the overall functionality of our application. The fishbone diagram presented below outlines potential factors contributing to the inadequate number of features.
Our clients have requested to have the website optimized for mobile devices, citing issues with user accessibility. Consequently, we are presently engaged in the process of modifying the existing application to ensure compatibility with mobile devices. Upon completion of this undertaking, we anticipate a marked improvement in user accessibility, resulting in an enhanced user experience. The fishbone diagram presented below explores some potential causes of the absence of mobile functionality.
With regards to our clients' requests to make our program compatible with mobile devices, one of the problems that can be explored is in our program's unfriendliness for a mobile user interface. The fishbone diagram below explores some causes for the lack of mobile support.
We want to define the goal in terms of accommodating clients' request about adding the feature to display wait times for emergency services in our system. The client and developers should be involved and probed for their thoughts, but also the instructional team should be consulted for advice regarding the issue as well.
Therefore, the goal can be described as follows:
"Analyze the project scope to identify whether or not there is enough time to include this functionality; display of emergence queue in our system from the viewpoint of developers. clients, and the instructional team in the context of the course's time and scope constraints."
When asking questions to tackle this goal, each perspective should be considered: the course (and instructional team), the developers, and the clients. It is also essential to consider which aspects of the goal are associated with each perspective: the time left in the course, the development time, and the client demand.
Therefore, the questions can be defined as follows:
- What was the impact of adding the feature to display wait times for emergency services in addition to non-emergency services and queue length in hospitals?
- Did this change improve the system's ability to provide more accurate and helpful information to patients who require urgent care?
- Did this change expand the system's capabilities beyond non-emergency services and hospital queue length?
When deciding the metrics to determine which data needs to be gathered, it is essential to ask how each question can be answered with a quantity. The course length must be considered concerning the due date of the project's last milestone, the semester's end date, and the date of when the instructional team is willing to accept submissions. In terms of development time, it can be measured with man-hours, and the developers can be asked about how long they think it will take to implement. Client demand is a bit tricky to quantify. Still, they can be surveyed using a survey to gauge their interest in the effectiveness of this change in providing more accurate and helpful information to patients who require urgent care and expanding the system's capabilities.
The metrics to provide possible answers are:
- Number of customer support requests received per day/week/month.
- Average time is taken to resolve customer support requests.
- Customer satisfaction ratings based on feedback surveys.
- Number of unresolved customer support requests.
- Number of unresolved customer support requests.
Overall, the GQM for the RCA on lack of Emergency Wait Time Support can be summarized as follows.
We want to define the goal by providing a wait time estimate to help users make informed decisions in emergencies. The client and developers should be involved and probed for their thoughts, but also the instructional team should be consulted for advice regarding the issue as well.
Therefore, the goal can be described as follows:
"Analyze the project scope to identify whether or not there is enough time to modify and develop our application by providing an estimated time of emergence queue in our system from the viewpoint of developers. clients, and the instructional team in the context of the course's time and scope constraints."
When asking questions to tackle this goal, each perspective should be considered: the course (and instructional team), the developers, and the clients. It is also essential to consider which aspects of the goal are associated with each perspective: the time left in the course, the development time, and the client demand.
Therefore, the questions can be defined as follows:
- What feature requests have our clients made for our application?
- How will implementing these features increase the functionality of our application?
- What benefits will our clients and our business gain from these additional features?
When deciding the metrics to determine which data needs to be gathered, it is essential to ask how each question can be answered with a quantity. The course length must be considered concerning the due date of the project's last milestone, the semester's end date, and the date the instructional team is willing to accept submissions. In terms of development time, it can be measured with man-hours, and the developers can be asked about how long they think it will take to implement. Client demand is a bit tricky to quantify. Still, they can be surveyed using a survey to gauge their interest in providing a comprehensive system that displays both the emergence and non-emergency wait time, expanding the system's capabilities.
The metrics to provide possible answers are: *Number of feature requests made by clients
- Days left in terms of date to the last milestone submission
- Man-hours for programming the implementation
- User satisfaction.
- Revenue
Overall, the GQM for the RCA on Not Enough Features can be summarized as follows.
We want to define the goal by Modifying an existing application to make it compatible with mobile devices. The client and developers should be involved and probed for their thoughts, but also the instructional team should be consulted for advice regarding the issue as well.
Therefore, the goal can be described as follows:
"Analyze the project scope to identify whether or not there is enough time to Modify an existing application to make it compatible with mobile devices in our system from the viewpoint of developers. clients, and the instructional team in the context of the course's time and scope constraints."
When asking questions to tackle this goal, each perspective should be considered: the course (and instructional team), the developers, and the clients. It is also essential to consider which aspects of the goal are associated with each perspective: the time left in the course, the development time, and the client demand.
Therefore, the questions can be defined as follows:
- What are the most important features and functionalities for mobile users?
- What are the most common user pain points when accessing the website on a mobile device?
- How can we improve the website's mobile user interface design?
- How can we optimize the website's performance on mobile devices?
When deciding the metrics to determine which data needs to be gathered, it is essential to ask how each question can be answered with a quantity. The course length must be considered concerning the due date of the project's last milestone, the semester's end date, and the date the instructional team is willing to accept submissions. In terms of development time, it can be measured with man-hours, and the developers can be asked about how long they think it will take to implement. Client demand is a bit tricky to quantify. Still, they can be surveyed using a survey providing a pie chart of the percentage of mobile users who access the website regularly and their complains.
The metrics to provide possible answers are:
- Percentage of mobile users who access the website regularly.
- Average page load time for mobile devices.
- Man-hours for programming the implementation
- Days left in terms of date to the last milestone submission
- User satisfaction based on online survey
- Number of user complaints or support tickets related to mobile functionality
Overall, the GQM for the RCA on Not Enough Features can be summarized as follows.
We want to define the goal in terms of determining if mobile support is viable with respect to the time needed for such an implementation and and the time left in the course. The client and developers should be involved and probed for their thoughts, but also the instructional team should be consulted for advice regarding the issue as well.
Therefore, the goal can be described as follows:
"Analyze the scope of the project to identify whether or not there is enough time to design, test, and implement mobile support from the viewpoint of developers, clients, and the instructional team in the context of course's time and scope constraints."
When asking questions to tackle this goal, each perspective should be considered: the course (and instructional team), the developers, and the clients. It is also important to consider which aspects of the goal is associated to each perspective: the time left in the course, the development time, and the client demand.
Therefore, the questions can be defined as follows:
- How much time do we have left in the course?
- How long would it take for the developers to learn and implement a mobile UI for their program?
- How much client demand is there for this functionality?
When deciding the metrics to determine which data needs to be gathered, it is important to ask how each question can be answered with a quantity. The course length must be considered with respect to the due date of the project's last milestone, the semester's end date, and the date of when the instructional team is willing to accept submissions. In terms of development time, it can be measured with man-hours and the developers can be asked about their experiences with mobile development and how long they think it will take to implement. Client demand is a bit tricky to quantify but they can perhaps be surveyed using a Likert scale to gauge their interest in mobile support.
Therefore, the metrics to provide possible answers are:
- How much time do we have left in the course?
- Days left in terms of the date of the last milestone submission
- The semester's end date
- The instructional team's date for accepting submissions
- How long would it take for the developers to learn and implement a mobile UI for their program?
- Hours to design a mobile UI
- Hours to learn mobile development
- Man-hours for programming the implementation
- How much client demand is there for this functionality?
- Survey scores for functionality demand from the client
- Survey scores for UI preferences
- Researching current systems and seeing the amount of demand and/or praise for mobile support
Overall, the GQM for the RCA on Unfriendly Mobile UI can be summarized with the following:
Please follow the steps outlined in the README.md file attached in the root of this repository to get the fully functional application running locally on your machine.