From 218a82f5e5e5bdcc2974e3c8476013268dc1d70e Mon Sep 17 00:00:00 2001
From: "86.LAK" <lakshan392@gmail.com>
Date: Sun, 26 May 2024 11:33:26 +1000
Subject: [PATCH] removing task sheet

---
 report/REPORT.md | 49 ------------------------------------------------
 1 file changed, 49 deletions(-)

diff --git a/report/REPORT.md b/report/REPORT.md
index cdae843..2f2dad6 100644
--- a/report/REPORT.md
+++ b/report/REPORT.md
@@ -1,52 +1,3 @@
-<!--- 
-Title Name of your software project.
-Abstract Summarise the key points of your document.
-Changes Describe and justify any changes made to the project from what was outlined in the proposal.
-Architecture Options What architectural design patterns were considered and their pros and cons.
-Architecture Describe the MVP’s software architecture in detail.
-Trade-Offs Describe and justify the trade-offs made in designing the architecture.
-Critique Describe how well the architecture supports delivering the complete system.
-Evaluation Summarise testing results and justify how well the software achieves its quality attributes.
-Reflection Lessons learnt and what you would do differently.
-
-You do not need to have sections for each topic above, though your report needs to contain the content
-summarised above. For example, the description of the architecture could include discussion of trade-
-offs. Similarly, the critique and evaluation could be combined so that both are discussed in relation to an
-architecturally significant requirement (ASR) [2].
-When writing your report, you may assume that the reader is familiar with the project proposal. You will
-need to describe any changes your team has made to the original proposal. A rationale should be provided
-for each change. Small changes only need a brief summary of the reason for the change. Significant
-changes to functionality of the MVP, or changes to important quality attributes, need a more detailed
-justification for the change. You should provide a reference and link to the original proposal.
-Compare and contrast different architectural design patterns that could be used to deliver the system.
-Explain the pros and cons of each architectural design pattern in the context of the system’s functionality
-and ASRs. Justify your choice of the architectural design pattern you used in your design.
-Describe the full architecture of your MVP in enough detail to give the reader a complete understanding
-of the architecture’s design. Use appropriate views, diagrams and commentary to describe the software
-architecture. You should describe parts of the detailed design that demonstrate how the architecture sup-
-ports delivering key quality attributes [2]. (e.g. If interoperability was a key quality attribute, you would
-need to describe the parts of the detailed design that support this. For example, how you use the adapter
-design pattern to communicate with external services.)
-Describe any trade-offs made during the design of the architecture. Explain what were the competing
-issues2 and explain why you made the decisions that resulted in your submitted design.
-When describing the architecture and trade-offs, you should summarise and/or reference ADRs that
-relate to important decisions that affected your architecture.
-Your critique should discuss how well the architecture is suited to delivering the full system functionality
-and quality attributes. Use test results to support your claims, where this can be shown through testing.
-For quality attributes that cannot be easily tested (e.g. extensibility, interoperability, ...), you will need to
-provide an argument, based on your architectural design, about how the design supports or enables the
-attribute. Some quality attributes (e.g. scalability) may require both test results and argumentation to
-demonstrate how well the attributed is delivered.
-Summarise test plans and test results in the report. Provide links to any test plans, scripts or code in
-your repository. Where feasible, tests should be automated. Describe how to run the tests. Ideally, you
-should use GitHub Actions3 to run tests and potentially deploy artefacts.
-Your report should end with a reflection that summarises what you have learnt from designing and
-implementing this project. It should include descriptions of what you would do differently, after the expe-
-rience of implementing the project. Describe potential benefits or improvements that may be delivered
-by applying the lessons you have learnt during the project. You will not lose marks for identifying problems
-with your architecture or software design.
---->
-
 # UniBasement
 
 ## Abstract