Cloud Computing (COMM034) Coursework description, 2018-19
Cloud Computing1代写 To demonstrate an understanding of how to construct a Cloud application using multiple services across two Cloud providers
To demonstrate an understanding of how to construct a Cloud application using multiple services across two Cloud providers, involving specifiable scaling.
You will propose, implement, test, evaluate, and demonstrate, an application that estimates the value of Pi (π) to:
i) a given number of tests;
ii) a given decimal place of accuracy.Cloud Computing1代写
using a so-called Monte Carlo method. See Approach, and – in particular – part iv regarding the estimates. Your application will need to adopt the Approach within the set of provided Requirements, and you will make Submissions as outlined.
Contents Cloud Computing1代写
Weighting and Composition 6
Marks and feedback 6
Marking criteria – part 1 7
Marking criteria – part 2 8
Marking criteria – viva 9
i The approach involves generating random numbers and using an inequality to generate a ratio. Theratio allows for the estimation of Pi (π). It proceeds as follows:
a.Assume a circular dartboard of radius r, and a square backboard on which it sits. If the dartboard fits perfectly inside the backboard, we have a square of width and height 2r. The area of the circle is πr2, and the area of the square is4r2.
b.Now assume a dart player with little control over where the dart lands – all darts land within the square, but not all land within the circle. After an incredibly large number of shots, the ratio between those landing inside the circle to all of those thrown shouldbecome:
Area of circle / Area of square = πr2/ 4r2 = π/ 4
and so the ratio multiplied by 4 should approximate Pi.
ii.Consider the circle as a unit circle of radius 1, with centre at the origin (0, 0) in the Cartesian coordinate system. If we pick random numbers for x and y, with both between -1 and +1, we will land in the square and perhaps inside the circle. We can test the latter, if √(x2+ y2) < 1 , as (x2 + y2) <
iii.The code, then, is relatively straightforward – generate random values, test if they are inside the circle, and multiply the resulting value by
iv.A single run of this code will produce one estimate. Multiple runs, serially, willproduce multiple estimates. There are three things that we could do from here:
a.Determine an estimate of Pi by averaging from a number of (parallel)runs
b.Determine an estimate of Pi across multiple parallel runs of the code (i.e. not calculating Pi for each, but determining its value using information about shots and incircle across allruns)Cloud Computing1代写
c.Determine an estimate of Pi accurate to a given decimal place through multiple iterations of b, above by comparison to a given value of Pi (in Python, from math.pi), repeating parallel runs until a ‘good’ value is obtained.
This coursework requires b and c to be undertaken, but NOT a.
Figure 1: An example chart – estimated value vs shots (values are taken at increments of 10,000 shots here), in contrast to Pi. Note that being within a given number of decimal places may happen reasonably early but might not occur again for a while.
i.You must use:(i) Google App Engine, (ii) AWS Lambda, and (iii) one of the other scalable services in AWS: Elastic Compute Cloud (EC2), Elastic MapReduce (EMR) or – should you wish to explore – EC2 Container Service (ECS).
Subsequent mentions of scalable services in this document mean Lambda plus your choice of (EC2 or EMR or ECS).
ii.Your system must offer a persistent front-end through which you can present information about (accuracy of) estimates of the value of Pi to end users.
iii.The system must present a Chart, either using image-charts.com or the newer Google Charts(https://developers.google.com/chart/) [since the nice, easy to use Google ‘Image’ Charts will be killed off mid-March] that shows the value settling to Pi over the number of data points (shots) with value on the y-axis and shots on the x-axis.
Estimates for values of Pi must also be presented in a table on the same page as the chart.
iv.The scalable services, and notGoogle App Engine, must run the Pi estimation code, with results made available for presentation by the persistent front end.
v.The scalable servicesmust be used dynamically – i.e. any resources used in calculating the Monte Carlo values should be switched on and off (automatically, via code) for the purpose and shall not be left on continuously.Cloud Computing1代写
vi.It must be possible to specify values for the following parameters through the persistentfront-end:
a.to allow for a choice between estimating to a given number of data points (shots) or a given decimal place ofaccuracy
b.a value of S, as the number of data points (shots) to use for estimating Pi / a value of Dfor the decimal place of accuracy, based on selection between shots and accuracy (above)
c.a value of R, as the number of resources (in the scalable services), to be used for estimating Pi, so that each run uses approximately S/Rshots (if D is not met, additional runs should also happen at this rate).
d.a value of Qas the reporting rate: if 1,000,000 shots (S) were requested across 10 resources (R), a reporting rate of 10 would mean each run returns 10 values, one after each 10,000 shots. The graph, as shown, would then display 100 values, each representing a further 10,000.Cloud Computing1代写
e.the scalable service to use for Monte Carlo – e.g. a selection between Lambda and EC2; there is no requirement to use both scalable services at the sametime.
vii.Except for specifying values, the user must be able to run an analysis with a single
viii.Data about each run must be retained. You will need to consider where such data should be stored.
Your system may incorporate additional Cloud components, for example for storage. However, the mantra of Keep It Stupid-Simple should be followed and additional components should not be added unnecessarily.
Submissions for part 1 and part 2 must use the A4 version of the IEEE Manuscript Templates for Conference Proceedings available at: http://www.ieee.org/conferences_events/conferences/publishing/templates.html. A link to the MS Word (2003) version for this is: http://www.ieee.org/publications_standards/publications/conferences/2014_04_msw_a4_format.doc
Two columns should be used throughout, with only large figures and tables allowed to span both columns.
Do not modify the template, e.g. by changing margins. This will impact on structure/quality, which is assessed for both written submissions.
1. Submit a 2 page paper, using the IEEE template, that discusses how the system will work. This needs to:
a.Provide an abstract and introduction which relates your system to NIST SP 800-145from the perspective of i) a developer and ii) a [20 marks]
b.Present (i) a high-level view of the major components of the system – perhaps using the AWS icons with suitable additions, and (ii) discuss what data/information needs to be communicated between the major components, in order for the system to work and meetthe [30 marks]Cloud Computing1代写
c.Demonstrate an understanding of how the system will work by presenting relevant results from running the code and from making changes that will be needed for it to be usable as anticipated (a few lines of modified code may be included forthis purpose). [30 marks]
d.Submission structure and qualityof [20 marks]
2. Submit a 4 page paper, using the IEEE template, that presents the system. This needs to:
a.Improve your abstract and introduction from Part 1 – evaluated with respect to (g),
b.Present (i) the final high-level view of the major components of the system – perhaps using the AWS icons with suitable additions, and (ii) discuss what data/information needs to be communicated between the major components, in order for the system to work and meet the requirements. Explain, also, the choice you made in the additional scalable serviceto use and any other services used (contrast to others available). [20 marks]Cloud Computing1代写
c.Discuss (i) your implementation (i.e. what you needed to write code for, what you used from elsewhere) and how you have approached scalingto be able to parallelise the approach, and (ii) what tests you ran against your [20 marks]
d.Present and discuss a snapshot of results that the system produces, and explain what happens with highernumbers of [20 marks]
e.Identify requirements notmet, and what you could have done in order to meet [20 marks]
f.Compare the costs of running each of the scalable services for large numbers of shots, and explain which is the morecost-effective. [10 marks]
g.Submission structure, including the abstract and introduction, and qualityof [10 marks]
3. Submit a short presentation and source code of your system for a viva in which you will:
a.Give a short presentation (maximum of 5 minutes) using slideshighlighting what you managed to complete in respect to the requirements (as achievements) and where improvements should have been made. [40 marks]
b.Give a short demonstration (maximum of 5 minutes) of your system – this should cover how you have usedeach Cloud service, and how and where you analyse the [30 marks]Cloud Computing1代写
c.Demonstrate the user’s view of the overall system, and respond to any questions about the system and your Ease of running and using the system – for a theoretical end user – will be key factors. [30 marks]
Coursework represents 100% of the assessment for this module, and so should be considered as requiring significant effort in order to complete.
The coursework has three parts, weighted at 30%:40%:30%. The three parts are:
- A written submission that proposes a structure, a means of operation, and exemplifies the work to be done in the form of a 2 page (A4) IEEE conference-style
This accounts for 30%. Cloud Computing1代写
- A written submission in the form of a 4 page (A4) IEEE conference-style paper that documents a final system, offering a design, implementation, testing, evaluation and This accounts for 40%.
- A viva, requiring submitted code and a brief presentation and demonstration of your This accounts for30%.
Part 1 (2 pages): 4pm, Tuesday 26 March (week 8) – submission on SurreyLearn.
Part 2 (4 pages): 4pm, Monday 20 May (week 12), with a submission of your code also – submission on SurreyLearn.
Part 3 (Viva): To take place in week 14/15 – date/time will be scheduled once the examinations timetable is known. Presentation slides to be submitted on SurreyLearn by a date to be confirmed – 6 or 7 June are candidate dates for the Viva.
Part 1: Friday 26 April.
Part 2, Part 3: Friday 28 June.
You will be informed of any variations to the above dates should variation become necessary or unavoidable. Note that the standard duration for return of marks and feedback is 3 semester weeks.Cloud Computing1代写
Marking criteria for subsequent parts will be provided after part 1 is complete.
|Weight (for marking purposes
|80-100||Excellent demonstration of relating to NIST 800-145, demonstrating mastery of applicability.||Exemplary demonstration of how the system will be composed and would operate. Easy to conceive of an implementation from this point.||Excellent demonstration of usage and modifications, as supports the feasibility of the proposal. Detail used in a highly effective manner.
|Highest standard of submission with logical progression and clear discussion. A well-written and highly readable piece with negligible spelling or grammatical errors that provides an effective
|High standard of demonstration of relating to NIST 800-145, demonstrating a good extent of mastery in respect to relevant components.||High standard of presentation of how the system will be composed and would operate. Easy to conceive of an implementation from this point, although specific
aspects will require clarification.
|Effective demonstration of usage and modifications to support the feasibility of the proposal. Detail used in an effective manner.||Clear and logical progression and clear discussion. An engaging, well-written and highly readable submission with negligible spelling or grammatical errors that
provides an effective summary.
|60-69||Demonstration of clear associations to NIST 800-145, showing a reasonable extent of mastery in respect to relevant components.||Relatively comprehensive standard of presentation of how the system will be composed and would operate. Specific aspects will require additional clarification ahead
of being able to implement such a system.
|Evidence of some consideration of usage and modifications as supports feasibility. Detail used in varying amounts to illustrate .||Clear progression and good standard of discussion.
Structure has room for improvement and spelling and grammatical errors may distract the reader.
|50-59||Showing some clarity with respect to NIST 800-145, but not necessarily relating. The extent of such coverage also requires some improvement to ensure that correctness or coverage convinces others.||Good demonstration of how the system might be composed and would operate, but vital aspects of the system will likely need to be reappraised ahead of being able to implement such a system.||Limited treatment of usage and modification. Detail suggests how the approach might work, but less convincing than should be the case.||Clarity of progression and standard of discussion has good room for improvement. Spelling and grammatical errors may distract the reader.|
|An unclear demonstration of how NIST 800-145 relates to the system, either due to limited discussion or limited understanding.
|Certain key aspects of the composition of the system are omitted, which will make an implementation challenging. These must be addressed as a priority.||Little evidence that the approach is sufficiently understood such that a suitable implementation is a next natural step.||Difficulties in clarity. Standard of discussion has significant room for improvement. Spelling and grammatical errors may significantly distract the
|30-39||Limited or inadequate knowledge/association presented.||Limited or inadequate system description.||Barely a hint of evidence of consideration for how to make the approach work.||Poor standard of presentation with significant spelling and/or grammatical errors.|
|< 30||No demonstration that the student has gained useful knowledge of NIST 800-145.||No demonstration that the student has considered how to construct such a system.||Limited or no evidence that the student knows what to do.
|Very poor standard of presentation. Much more attention needs to be paid to producing work of a suitable quality in future.|
|Mark||Architecture (b)||Implementation/testing (c)||Results (d)||Requirements
|Writing (a, g)|
(for marking purposes
|Exemplary discussion of how the system is composed and operates. Easy to conceive of the implementation from this point.||Excellent discussion of the implementation and testing approach. Detail used in a highly effective manner to illustrate the salient features of the approach.||Excellent demonstration of results from the system, and in respect to scale.||Exquisitely critiqued and significant discussion of possible improvements.||Comprehensive treatment of cost- effectiveness, addressing clear outcomes and preferences with evidence.||Highest standard of submission with logical progression and clear discussion. A well- written and highly readable piece with negligible spelling or grammatical errors that provides an effective
|70-79||High standard of presentation of how the system is composed and operates. Easy to conceive of the implementation from this point, although specific aspects will
|Effective discussion of the implementation and testing. Detail used in an effective manner to illustrate the salient features of the approach.||Effective demonstration of results from the system and in respect to scale.
|Well-critiqued with significant discussion of possible improvements.||High standard of treatment of cost- effectiveness, addressing some clarity in outcomes and preferences with evidence.||Clear and logical progression and clear discussion. An engaging, well-written and highly readable submission with negligible spelling or grammatical errors that provides an effective
|Relatively comprehensive standard of presentation of how the system is composed and operates. Specific aspects will require
|Evidence of consideration of implementation and testing. Detail used in varying amounts to illustrate the salient features of the approach.||Evidence of analysis of data being analysed by the system and some efforts in respect to scale.||Critique and discussion of possible improvements exists but could be more considered.||Consideration of cost- effectiveness has specific gaps.||Clear progression and good standard of discussion. Structure has room for improvement and spelling and grammatical errors may distract the reader.|
|Good demonstration of how the system is composed and operates, but vital aspects of the system are less clearly
|Consideration of implementation and testing requires improvement.
Detail demonstrates how the implementation should work, but less convincing
|Consideration of the generation of results requires improvement.
evidence in respect to scaling.
|Some moderate critique and discussion of possible improvements exists.||Consideration of cost- effectiveness requires improvement in depth and/or breadth.||Clarity of progression and standard of discussion has good room for improvement. Spelling and grammatical errors may
distract the reader.
|40-49||Certain key aspects of the composition of the system are omitted, which suggests difficulty in the implementation. These should have
been addressed as a priority.
|Little evidence that the implementation and/or the testing were sufficiently understood such that the implementation could be meaningful.||Little evidence that the approach to analysis was sufficiently understood such that the system could produce useful results.||Some critique and discussion of possible improvements exists, but in a limited form.||Limited consideration of cost-effectiveness.||Difficulties in clarity. Standard of discussion has significant room for improvement. Spelling and grammatical errors may significantly distract the reader.|
|Inherently limited system description.||Barely a hint of that the implementation could be tested.
|Barely a hint of evidence of analysis and implementation leading to results.||Little by way of critique and discussion of possible improvements.||Very limited consideration of cost- effectiveness.||Poor standard of presentation. More attention needs to be paid to producing work
of a suitable quality in future.
|< 30||Inadequate or no demonstration that the student has considered how to
construct such a system.
|Inadequate or no evidence that the student knows what to do.||Inadequate or no evidence that the student knows what to do.||Inadequate or no evidence that the student knows what to do.||Inadequate or no evidence that the student knows what to do.||Very poor standard of presentation. Much more attention needs to be paid to producing
work of a suitable quality in future.
|Weight (for marking purposes
|Exemplary presentation of achievements and improvements from which an understanding of requirements completed is trivial to comprehend.||Excellent demonstration of either a fully working system or a substantively operational system with a clear perspective on what would be needed to make this complete. Shown in a highly effective manner to
illustrate the salient features of the approach.
|Functional, and straightforward for the user, demonstrating mastery in respect to required data/information, and system scalability and presentation of results.|
|70-79||High standard of presentation of achievements and improvements from which an understanding of requirements completed is readily comprehensible, with few aspects requiring clarification.||Effective demonstration of a significant subset of an operational system with specific ideas of what priorities for improvement would be.||Demonstrating very strong understanding of data/information, system scalability, and presentation of results.|
|Relatively comprehensive standard of presentation of achievements and improvements from which an understanding of requirements completed can be gathered but with specific aspects requiring additional clarification.||Effective demonstration of a moderate subset of an operational system with specific ideas of what priorities for improvement would be.||Functional interface offering for a subset of possible capabilities.|
|50-59||Good presentation of achievements and improvements, but vital aspects of how the system meets requirements are less clearly outlined without additional clarification.||Demonstration of certain aspects of an operational system, consistent with the explanation of requirements met or unmet with specific ideas of priorities for improvement.||Functional interface offering access to a limited subset of possible capabilities.|
|Certain key details of meeting requirements were omitted, which should have been addressed as a priority, and may not have been
|A demonstration limited by what was actually demonstrable. Progress made demonstrates limitations.||User interface with key shortcomings in being able to conduct the analysis.|
|30-39||Presentation struggled to address what was achieved or not achieved in respect to the requirements.||Limited evidence of a demonstrable system suggesting limited effort in implementation.||An interface providing little capability|
|< 30||Presentation largely failed to make a clear relationship to the requirements.||Very little or no evidence of demonstrable progress.||Little, if any, thought given to what users need to be able to do.|
其他代写：algorithm代写 analysis代写 app代写 assembly代写 assignment代写 C++代写 C/C++代写 code代写 course代写 CS代写 cs作业代写 Data Analysis代写 dataset代写 data代写 finance代写 java代写 source code代写 Task代写 web代写 作业加急 北美cs代写 北美代写 北美作业代写 数据分析代写 编程代写