From 2750c419a2b3cdae8768935ca97b32c04ab009bb Mon Sep 17 00:00:00 2001 From: Richard Thomas Date: Tue, 8 Aug 2023 16:09:18 +1000 Subject: [PATCH] Finialised supplementary assessment requirements. --- assessment/supplementary/criteria.tex | 77 --------------------------- assessment/supplementary/main.tex | 71 ++++++++++-------------- 2 files changed, 27 insertions(+), 121 deletions(-) delete mode 100644 assessment/supplementary/criteria.tex diff --git a/assessment/supplementary/criteria.tex b/assessment/supplementary/criteria.tex deleted file mode 100644 index 033c323a..00000000 --- a/assessment/supplementary/criteria.tex +++ /dev/null @@ -1,77 +0,0 @@ -\clearpage - -\newgeometry{left=12mm,right=7mm,top=5mm,bottom=12mm} - -\begin{landscape} - -\fontsize{9}{11}\selectfont - -\begin{xltabular}{\linewidth}{| P{1.55cm} | X | X | X | X | X | X | X |} -\hline -\multicolumn{1}{|c}{\multirow{2}{*}{\textbf{Criteria}}} & - \multicolumn{7}{c|}{\textbf{Standard}} \\ \cline{2-8} -\multicolumn{1}{|c}{} & - \multicolumn{1}{c|}{\textbf{Exceptional ~ (7)}} & - \multicolumn{1}{c|}{\textbf{Advanced ~ (6)}} & - \multicolumn{1}{c|}{\textbf{Proficient ~ (5)}} & - \multicolumn{1}{c|}{\textbf{Functional ~ (4)}} & - \multicolumn{1}{c|}{\textbf{Developing ~ (3)}} & - \multicolumn{1}{c|}{\textbf{Little Evidence ~ (2)}} & - \multicolumn{1}{c|}{\textbf{No Evidence ~ (1)}} \\ \hline -\endhead -% -\textbf{System\newline Scope\newline20\%} & -MVP's originally proposed functional \& non-functional requirements, or those agreed \& documented early in the project, are fully delivered. & -MVP's originally proposed functional \& non-functional~require\-ments, or those agreed \& documented early in the project, are delivered with small variances. & -MVP's functional \& non-functional requirements were revised \& documented later in the project, and are almost fully delivered. & -All important functional \& non-functional requirements are delivered but some other requirements are not, whether or not original plan was revised. & -Most important functional \& non-functional requirements are delivered, whether or not original plan was revised. & -Some important functional \& non-functional requirements are delivered, whether or not original plan was revised. & -Few important functional \& non-functional requirements are delivered, whether or not original plan was revised. \\ -\hline - -\textbf{Architecture\newline Suitability\newline 20\%} & -Delivered architecture, supplemented by the design reflection, is very well suited to delivering all specified functional \& non-functional require\-ments, including an appropriate level of security. & -Delivered architecture, supplemented by the design reflection, is~well suited to delivering~al\-most all specified functional \& non-functional requirements, including an appropriate level of security. & -Delivered architecture, supplemented by the design reflection, is fairly well suited to delivering the key functional \& non-functional requirements, including a mostly appropriate level of security. & -Delivered architecture, supplemented by the design reflection, is capable of delivering most key functional \& non-functional requirements, including a mostly appropriate level of security. & -Delivered architecture, supplemented by the design reflection, requires workarounds in a few cases to deliver key functional \& non-functional requirements. Design has one or two obvious security issues. & -Delivered architecture, supplemented by the design reflection, requires workarounds in several cases to deliver key functional \& non-functional requirements. Design has a few obvious security issues. & -Delivered architecture, supplemented by the design reflection, makes it difficult to deliver many functional \& non-functional requirements. Design does not appear to consider security issues. \\ -\hline - -\textbf{Testing\newline Quality\newline 20\%} & -All functional \& non-functional requirements, \& architectural components are well tested (or are described well in a test plan) and, where feasible, are mostly automated. & -Most key functional \& non-functional require\-ments, \& key architec\-tural components are well tested (or are described adequately in a test plan) and, where feasible, are mostly automated. & -Most key functional \& non-functional require\-ments, \& key architec\-tural components are fairly well tested (or are described fairly adequately in a test plan) and, where feasible, many are automated. & -Most key functional \& non-functional require\-ments, \& key architectural components are fairly well tested (or are described fairly adequately in a test plan) and, with some attempt at automation. & -Main test cases for most key functional \& non-functional requirements, \& key architectural components are fairly well tested (or have some informative description in a test plan). & -Main test cases for a few key functional \& non-functional requirements, \& key architectural components are moderately well tested (or have a general description in a test plan). & -Testing is poor, superficial or extremely limited. Or, extent of testing cannot be determined from submitted artefacts. \\ -\hline - -\textbf{Architecture\newline Description\newline 20\%} & -Clear, accurate, concise \& complete description of all aspects of the architecture. Diagrams \& narrative text complement each other. Views support describing all aspects of the architecture. Decisions about design trade-offs are well described. & -Clear, accurate \& mostly complete description of the architecture. Diagrams \& narrative text complement each other. Views support description of the architecture. Decisions about important design trade-offs are well described. & -Mostly clear, accurate \& complete description of the architecture. Diagrams \& narrative text support each other. Views support some description of the architecture. Decisions about most important design trade-offs are adequately described. & -Fairly clear, \& mostly accurate \& complete~des- cription of the architecture. Diagrams \&~narra- tive text are consistent. Views provide little~sup- port describing the architecture. Decisions about some important design trade-offs are fairly adequately described. & -Some parts of the description are unclear, inaccurate or incomplete. Most diagrams are relevant to the narrative text or a necessary diagram is missing. Decisions about a few important design trade-offs are fairly adequately described. & -Some parts of the description inaccurate or incomplete, or many parts are unclear. Some diagrams are relevant to the narrative text or a few necessary diagrams are missing. Few design trade-offs are adequately described. & -Many parts of the description are unclear, inaccurate or incomplete. Few diagrams are relevant to the narrative text or many necessary diagrams are missing. Trade-offs are poorly described. \\ -\hline - -\textbf{Architecture\newline Evaluation\newline 20\%} & -Critique \& evaluation clearly demonstrate that the delivered architecture, varied a little by the reflection comments, can deliver all functional \& non-functional requirements of the full system. & -Critique \& evaluation clearly demonstrate~that the delivered architecture, varied by the reflection comments, can deliver all functional \& non-functional requirements of the full system. & -Critique \& evaluation demonstrate that the delivered architecture, varied by the reflection comments, can deliver all important functional \& non-functional requirements of the full system. & -Critique \& evaluation demonstrate that the delivered architecture, varied by the reflection comments, can deliver all important functional \& non-functional requirements of the MVP \& part of the full system. & -Critique \& evaluation demonstrate that the delivered architecture, varied by the reflection comments, can deliver all important functional \& non-functional requirements of the MVP but little of the full system. & -Critique \& evaluation demonstrate that the delivered architecture, varied by the reflection comments, can deliver some important functional \& non-functional requirements of the MVP but little of the full system. & -Critique \& evaluation demonstrate that the delivered architecture, varied by the reflection comments, is unlikely to deliver most functional or non-functional requirements of the MVP. Or, they are too unclear to determine. \\ -\hline - -\end{xltabular} - -\end{landscape} - -\restoregeometry \ No newline at end of file diff --git a/assessment/supplementary/main.tex b/assessment/supplementary/main.tex index 7791f82f..2f728d04 100644 --- a/assessment/supplementary/main.tex +++ b/assessment/supplementary/main.tex @@ -11,51 +11,26 @@ } \makeatother -% RUBRIC -\usepackage{multirow} -\usepackage{array} -\usepackage{xltabular} -\usepackage{pdflscape} -\usepackage{enumitem} - -\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}} -% RUBRIC \title{Supplementary Assessment} \author{Richard Thomas} \date{Semester 1, 2023} + \begin{document} \maketitle \section*{Summary} To assess that you have achieved the learning objectives for the course, you need to design and evaluate the architecture for a complex system. -\begin{itemize} - \item propose a non-trivial software project, - \item identify the primary quality attributes which would enable success of the project, - \item design an architecture suitable for the aims of the project, - \item deploy the architecture, utilising any techniques you have learnt in or out of the course, and - \item evaluate and report on the success of the software project. -\end{itemize} -\noindent -The successful completion of the project will result in three deliverables, namely, -\begin{enumerate}[label=\roman*] - \item a proposal of a software project, the proposal must clearly indicate and prioritise two or three quality attributes most important to the project's success, - \item the developed software, as both source code, and a deployed artifact, and - \item a report which evaluates the success of the developed software relative to the chosen quality attributes. -\end{enumerate} - -\noindent -Your software deliverable must include all supporting software (e.g. test suites or utilities) that are developed to support the delivered software. \section{Introduction} TradeOverflow wishes to provide a more dynamic shopping experience than traditional auction sites. Rather than items being listed for auction over a period of time, with a fixed end date, the sales model will be a trading platform. TradeOverflow will scan all items that are listed for sale on the site. -It will aggregate all items of the same type. +It will aggregate all items of the same type into a trading set. (e.g. It will find all copies of the Dune Ultra HD Bluray that are for sale, and aggregate them into a single trading set.) Once items have been aggregated into a trading set, the system will provide a dynamic trading platform for the item. @@ -125,25 +100,24 @@ \section{Design} \item Performing the trading strategy of when the active purchasing group wants to purchase more items than are available in the active sales group. \item A seller changing the minimum sales price for a listing that has not yet been sold. \end{itemize} - You should make use of an appropriate architectural view that allows you to demonstrate how the architecture achieves the non-functional requirements described above. \section{Evaluation} You need to describe how you would test the TradeOverflow system to demonstrate that it delivers its key non-functional requirements. -What infrastructure and test environment would be needed to perform adequate testing? +This needs to describe the infrastructure and test environment that would be needed to perform adequate testing. +You need to justify why the proposed testing strategy would be sufficient to provide confidence that the system meets its functional and non-functional requirements. \section{Report} -The report should include the following content. - +You need to submit a report that includes the following content. \begin{description} \item[Diagrams] C4 diagrams of the system's architecture. \item[Architecture] Textual description of the software architecture. \item[Justification] Describe how the architecture delivers the key non-functional requirements. Justify the architectural choices you made in the design. Explain why the selected AWS services are suitable to deliver the key non-functional requirements. + \item[Security] Describe the potential digital attack surface of the system and how it should be designed and implemented to reduce the risk of unauthorised access to the system. \item[Evaluation] Summarise how the TradeOverflow system could be tested. \end{description} - You do not need to have sections for each topic above, though your report needs to contain the content summarised above. For example, the architectural description and diagrams could be interleaved with each other. @@ -155,18 +129,26 @@ \section{Report} \section{Presentation} You must complete a presentation as part of this supplementary assessment. You cannot pass the assessment without completing the presentation. -The presentation will consist of a five minute summary of your architectural design. +The presentation will consist of a six minute summary of your architectural design and justification of your design choices. You should use diagrams from your report to help the audience understand your architecture. -After your five minute summary, you will need to answer questions about your architectural design. +After your summary presentation, you will need to answer questions about your architectural design. Questions may ask you to -\begin{itemize}[itemsep=3pt] +\begin{itemize} \item explain parts of the detail of your architecture, \item justify choices made in your architectural design, or \item justify the technologies or services selected to deliver the architecture. \end{itemize} +\section{Submission} +\begin{itemize} + \item Submit your report by 4pm on 18 August 2023 through the Supplementary Assessment TurnItIn link on the CSSE6400 BlackBoard site. + \item Arrange an appointment to make your presentation by emailing \href{mailto:richard.thomas@uq.edu.au}{richard.thomas@uq.edu.au} by 4pm on 18 August 2023. + \item Make your presentation in-person by 4pm on 22 August 2023, unless external factors make that impossible, in which case the presentation will be made over Zoom. +\end{itemize} + + \section{Academic Integrity} As this is a higher-level course, you are expected to be familiar with the importance of academic integrity in general, and the details of UQ's rules. If you need a reminder, review the \link{Academic Integrity Modules} @@ -183,16 +165,17 @@ \section{Academic Integrity} \section{Grading Criteria} - -\begin{description}[itemsep=3pt] - \item[20\%] Extent to which project's scope was delivered. - \item[20\%] Suitability of architecture to deliver system goals. - \item[20\%] Quality and thoroughness of testing. - \item[20\%] Clarity, accuracy and completeness of architecture's description. - \item[20\%] Insightfulness of architecture's evaluation. +This is a pass/fail assessment. +Your result will either be a passing or failing grade for the course. +You must pass \textbf{all} of the following criteria. +\begin{description} + \item[Architecture] The described architecture is capable of delivering the system's functional and non-functional requirements. + \item[Technology] The selected AWS services are capable of achieving the non-functional requirements of the system and the architecture structures these in a fashion that will work. + \item[Justification] You demonstrate appropriate consideration of trade-offs when selecting services and making architectural design choices. + \item[Security] You demonstrate adequate knowledge of potential security risks in the architecture and how these may be managed. + \item[Evaluation] You demonstrate adequate knowledge of how to test a complex distributed system. + \item[Presentation] You demonstrate in-depth knowledge of the architecture design and its rationale. \end{description} -\input{criteria} - \end{document} \ No newline at end of file