Task 1 needs to be done. It is a review of the report in the zip file, according to the requirements in the pdf
We are a small company in risk management area 1/4 Software Architecture – 2020 Group assignment – Phase 2 Reviewing and Improving Software Design of a Distributed System to Support Emergency Healthcare Services Objective: Gaining skills and experience in understanding and enhancing a designed architecture and reflecting upon the design approaches and decisions made for improvements. It is important that you demonstrate the ability to critically assess software architecture of a system with respect to the quality attributes and suggest improvements to others’ architecture design and redesign architecture for improvements and enhancements. Formatting: Times New Roman, 10 Font Size, A4 Page Size Group size: Same as the phase 1 Phase 2 assessment weight: 25% (15% group and 10% individual). Please note that task 1 is an individual task while task 2 is a group task. Due dates: There are different due dates for different tasks. Please see the due date for each task along with the task description given below. Individual Task Task 1 – Evaluation Summary (Deadline: 23:55, 1st Nov 2020) (10%) The teaching staff will email you via Canvas the architecture solution (produced in phase 1) from the team assigned to you for evaluating their architecture. If you don’t receive the architecture document by the end of 18th Oct 2020, please contact the teaching staff. Carefully study the architecture assigned to you and prepare a 2-page summary that should contain the following. 1. Synopsis of your understanding of the architecture and associated artifacts of the assigned team. For example, which architectural style, patterns, tactics, modelling tools, and technologies the team has used to construct the architecture (1/2 page) 2. Strengths of the constructed architecture and associated artifacts that in your view qualify the architecture to be a good architecture. The example questions you may consider during the review of the architecture are as follows. Please note that these are example questions, your review should be broader than merely answering these questions. You are expected to identify at least five solid strengths and justify briefly as to why you think such are strengths of the architecture. (1/2 page) a. Are the design/architectural patterns and tactics used correctly? b. Are the services and features identified correctly and are closely aligned with the system description? 2/4 c. Are the services and their interactions in the constructed architecture suitable for accomplishing various functional and non-functional requirements? d. Are the impacts on multiple quality attributes considered during the construction of the architecture? e. Are there any design decisions that contradict each other? f. Is the documentation of the architecture clear, concise, and unambiguous? g. Is the architecture and the related artifacts correctly modelled using a standard modelling language? h. Is the granularity of the services correct and logical? i. Is the selection of technologies (for implementing the system) suitable? 3. Weaknesses of the constructed architecture and associated artifacts that hinder the qualification of the constructed architecture to be a good architecture. The examples of questions to be answered in this section are the same as posed for strengths in the previous section. This is a very important part as the outcome of this part will be used in the subsequent parts for the improvement of the architecture. Therefore, it is important to identify as many weaknesses as possible along with solid justification as to why you believe that your identified weakness will lead to serious consequences if not addressed., i.e., what are the parts (e.g., design decisions and patterns etc.) that you think makes the architecture a bad architecture. You are expected to identify and report at least five main weaknesses. (1/2 page) 4. Questions and Suggestions on various aspects of the constructed architecture. This part gives the opportunity to the students to pin down their questions about anything that is not clear to them based on their reading of the architectural document from the assigned group so that the students can clarify those points in the architecture enhancement phase. You can also suggest any changes that you think will improve the constructed architecture. Each student is supposed to outline at least five well-thought questions/suggestions. (1/2 page) How to Submit: Please submit your 2-page summary with the name Surname_Phase2- Task1 (e.g., Josh_Phase2-Task1) to the submission box (Project Phase 2 – Individual) on Canvas for assessment. Group Task Task 2 – Design Improvements (Deadline: 23:55, 15th Nov 2020) (15%) The teaching staff will share the 2-page summaries (from task 1) with the relevant project groups. If you do not receive the summaries by the end of 2nd Nov 2020, please contact the teaching staff. In this task, you will focus on design improvements and enhancements of the SOA architecture designed in the first phase of the project. Your team is required to improve the existing architecture by taking into consideration the outcomes of the review of your own architecture or the architecture that you would have reviewed and the feedback provided to you by your classmates in the 2-page summaries (from Task 1). You must try to address as many concerns (you realized while reviewing another group’s architecture or the members of other groups has raised) as much as possible. As per the required improvements, modify the report that you have submitted for phase 1. Please provide 3/4 traceability by including a table (like the one shown below) to identify which parts of the previously submitted artifacts (e.g., technical architecture, scenarios, services, and design decisions etc.) have been modified or newly added/removed. Please note that the traceability table should be a comprehensive table including a clear and detailed description of the enhancements and rationale for changes. Each group is expected to make at least 15 improvements. The outcome of this part will be a report that will be an enhanced version of the report submitted as the outcome of group task in phase 1 of the project. The traceability table should appear after the table of contents and before the introduction section in the report to be submitted as outcome of task 2. How to Submit: Please submit your enhanced architecture report (outcome of task 2) as a pdf file to the submission box (Project Phase 2 – Group). Only one member from the group is expected to submit the report on behalf of the whole group. Please name your pdf file as GroupNumber_Phase2-Task2 (e.g., 1_Phase2-Task2). Table 1: Traceability of Enhancements Sr # Enhancement description Type Rationale (what motivate you to make the change) Section/subsection & Page Number Comments 1 A brief description of what you have modified Type of Modification (e.g., modify /add/remove) Source of origin of the enhancement. Section/subsection and page number of the document where enhancement is made Any additional comments. 2 3 Some relevant sources [1] M. Ali Babar, “Evaluating Software Architectures: Methods and Techniques” Book Chapter [2] Paul Clements, Rick Kazman, Mark Klein, “Evaluating a Software Architecture” – Book Chapter The assignments of groups for architecture evaluation For the project phase 2, following groups are assigned to evaluate the architecture solution of each other. There is one group (group 3) whose architecture will be evaluated by the teaching team and subsequently, the teaching team will write the 2-page evaluation summary. Group 3 will evaluate the architecture of Group 1, whose architecture will also be evaluated by Group 2. The aforementioned assignment happens because we have odd (11) number of groups in the course. The remaining group assignment for evaluation is as follows: 4/4 Group 1 and Group 2 will evaluate each other's architecture solutions. Group 4 and Group 5 will evaluate each other's architecture solutions. Group 6 and Group 7 will evaluate each other's architecture solutions. Group 8 and Group 9 will evaluate each other's architecture solutions. Group 10 and Group 11 will evaluate each other's architecture solutions. Evaluation Rubrics Task 1: (a) the synopsis underpins the key points from the evaluated architecture document (b) there are five concrete and logical strengths identified (c) there are at least five concrete and logical weaknesses identified (d) the summary is professionally drafted, proofread, and easily readable for another person (e) the summary clearly indicates that the student has carefully reviewed the entire architectural solution. Task 2: (a) the improved architecture design document clearly traces the changes with the architectural document from phase 1 (b) while enhancing, the group has addressed all the concerns highlighted in the evaluation summaries (c) the outcome of task 2 (phase 2 of project) is a more professional and logically correct architectural document as compared to the architectural document submitted as part of phase 1. If you need any explanation or face any challenge, please feel free to email one of the teaching staff or make an appointment for a face-to-face meeting. Group_Task/Report.docx Software Architecture 25 September 2020 Benedict Soh (a1719741) Jiayi Litten (a1723823) Jinheng Xu (a1719740) John Bullas (a1719756) Group Task Report Table of Contents 1. Introduction3 2. Use Cases4 3. Quality Attributes13 3.1 Performance13 3.2 Availability14 3.3 Modifiability14 3.4 Security15 3.5 Data Consistency16 3.6 Utility Tree17 4. Functional Architecture18 4.1 Logical View18 4.2 Process View19 5. Technical Architecture20 5.1 Logical View20 5.2 Execution View21 5.2.1 Creating an Emergency Activity21 5.2.2 Update Emergency Information22 5.2.3 Joining an Emergency Activity23 5.3 Deployment View24 6. Architectural Threat Analysis25 6.1 Security View Model and Threats25 6.2 Countermeasures26 7. Design Decisions27 7.1 Decision View Model27 7.2 Design Decisions28 8. Viable Technologies30 Appendix A: References31 1. Introduction To facilitate the need to create an emergency activity application, we have documented many of the key components that make up the software architecture of this application. It is understood that this application will be for hospital staff and paramedics for them to better respond to emergencies. As a result of this, it must be designed to fit all devices and thus will be a web application. The application will have several roles as there are different types of users in an emergency activity such as the phone operator, emergency response manager, paramedics, and hospital staff. All these users will share the same UI but may have slightly different functionalities depending on their role within the system. This document includes the use cases for the application, the