-
Notifications
You must be signed in to change notification settings - Fork 2
Project Milestone 4
The purpose of this question set is to assess how effectively the Mr. ED architecture addresses stakeholders' concerns and interests, as well as to evaluate their overall satisfaction.
All stakeholders must have their concerns, roles, and interests represented within the architecture for the Mr. ED application.
- List all your concerns corresponding to the architecture. Are all these concerns addressed? **
- Is the architecture documentation clear and understandable? The architecture documentation is very easy to read and explains the architecture very well. There was a clear understanding of the architecture once finished reading the architecture package.
- Are there any inconsistencies between the architecture diagrams, textual descriptions, and models? *There are a few inconsistencies between the architecture diagrams and current architecture. Specifically, the sequence diagrams and class diagram.
- Does the architecture meet all needs of the stakeholders? *Yes, the architecture meets all the needs of the stakeholders. *
- Does the architecture protect my data? No.
- List potential risks that you see arising from our architecture? No data protection and patients do not get a warning when they need to be at the hospital soon (being next in line).
- Does the architecture follow industry standards and guidelines? No data protection, which is critical with industry standards and guidelines.
- Are there any potential risks with the current implementation that are not addressed? Yes, no data protection and no notification when user is next in line (come to hospital now).
- How easily can the architecture accommodate future change? Very easily.
- Is the architecture an improvement to the current method used? Yes, the architecture is an improvement to the current method used.
- Is the architecture efficient and easy to use? Yes.
For any concerns listed by the stakeholders, they should be properly addressed. The documentation should be clear and understandable. The diagrams, descriptions and models should be consistent. The architecture should meet the needs of the stakeholders. The architecture should protect stakeholder data. The risks from our architecture should be properly addressed. The architecture should follow industry standards and guidelines. The architecture should be future-proof. The architecture should improve upon the currently used method. The architecture should be efficient and easy to use.
Questions concerning baseline architecture function are most important, followed by questions concerning industry standard, followed by questions concerning ease of use.
This question set is appropriate for determining the needs of our stakeholders and whether or not they have been met. It ensures that concerns regarding functionality, data protection, and usability are addressed comprehensively. Additionally, it highlights areas for improvement by evaluating alignment with industry standards and accommodating future changes. By systematically documenting stakeholder feedback, this process fosters collaboration and supports informed decision-making to refine the architecture.
The purpose of this question set is to assess how effectively the Mr. ED architecture addresses stakeholders' concerns and interests, as well as to evaluate their overall satisfaction.
All stakeholders must have their concerns, roles, and interests represented within the architecture for the Mr. ED application.
- List all your concerns corresponding to the architecture. Are all these concerns addressed? Scope
- Is the architecture documentation clear and understandable? Yes, it was very clear.
- Are there any inconsistencies between the architecture diagrams, textual descriptions, and models? A few within the sequence diagrams.
- Does the architecture meet all needs of the stakeholders? Although it might not meet all the wants like a map etc. It definitely meets the fundamental needs of all stakeholders.
- Does the architecture protect my data? No.
- List potential risks that you see arising from our architecture? No data protection.
- Does the architecture follow industry standards and guidelines? Although the architecture does well at following the industry standards and guidelines, it falls short with data protection. There is no architecture present to secure user data.
- Are there any potential risks with the current implementation that are not addressed? *Yes, there is no data protection and cybersecurity. *
- How easily can the architecture accommodate future change? It can accomodate future easily. For examples, new priorities and emergency departments can be implemented easily.
- Is the architecture an improvement to the current method used? *Yes, because there is no method currently that allows patients to enter emergency triage virtually. *
- Is the architecture efficient and easy to use? Yes, it is very simple.
For any concerns listed by the stakeholders, they should be properly addressed. The documentation should be clear and understandable. The diagrams, descriptions and models should be consistent. The architecture should meet the needs of the stakeholders. The architecture should protect stakeholder data. The risks from our architecture should be properly addressed. The architecture should follow industry standards and guidelines. The architecture should be future-proof. The architecture should improve upon the currently used method. The architecture should be efficient and easy to use.
Questions concerning baseline architecture function are most important, followed by questions concerning industry standard, followed by questions concerning ease of use.
This question set is appropriate for determining the needs of our stakeholders and whether or not they have been met. It ensures that concerns regarding functionality, data protection, and usability are addressed comprehensively. Additionally, it highlights areas for improvement by evaluating alignment with industry standards and accommodating future changes. By systematically documenting stakeholder feedback, this process fosters collaboration and supports informed decision-making to refine the architecture.
Specify the remaining implementation goals for this last sprint. Implement them and comment on the completion. Describe what goals were in the previous sprints, why they were shifted, and when they were completed.
The following describes the goals in each sprint/milestone:
- Milestone 1: Obtain a clear idea of the project's system, identify primary actors, create and describe use case diagrams.
- Milestone 2: Develop a comprehensive plan for the code architecture, complete all required design diagrams, complete the full-stack development (front-end, back-end, database, and connections) for the login and registration pages.
- Milestone 3: Complete 80% of the system's code, implement design patterns and architectural tactics, and update design diagrams.
- Milestone 4: Complete the remaining features, minor bug fixes, and styling for this web application, write and review the architecture package, and update design diagrams.
Some goals in these milestones were moved to other milestones.
- Milestone 1: All goals were completed in Milestone 1.
- Milestone 2: There were difficulties with creating the connections between the front-end, back-end, and database in MongoDB. This task was shifted to and completed in Milestone 3. All other goals set for Milestone 2 were completed in Milestone 2.
- Milestone 3: All goals were completed in Milestone 3.
- Milestone 4: All goals were completed in Milestone 4.
A detailed description of the implementation goals for this last sprint are described below. All implementation goals set for Milestone 4 were completed.
- Doctor view: View the medical ticket details (priority, symptoms, emergency department, and medical information) and accept the ticket to treat the patient.
- Notify patient: Notify the patient on the "Patient Waiting" screen. When the nurse has set a priority to the patient's ticket, the patient will be notified what place in line they are in. If more patients enter the queue, the place in line will continue to be updated. In addition, the patient will be notified when the doctor is ready to see them.
- User authentication: Only allow certain user types to view/use certain pages. For example, Patients should only be allowed to access the "Enter Virtual Triage" page.
- Added multiple rest API routes, with GET and POST HTTP methods used.
The Mr. ED web application is now complete and fully functional.
** It is very important to note that this web application will not function without our MongoDB database. If needed, we can come to campus and demo it. **
- Ashley: Worked on the doctor view feature so the doctor can select and view medical ticket details. Performed testing on the web application. Completed documentation in the Wiki, including the Incremental Construction and a description of our final implementation. Conducted the review of the architectural package.
- Liam:
- Erich:
- Issac: