代写Assignment、代写matlab Assignment、代写python Assignment、代写essay

日期：2018-08-26 06:17

1 Aim

In this assignment your team will build a proof-of-concept app that will utilise existing location mapping and

weather forecasting services, to present the user with historical temperature data and assist with their decisions

in growing sustainable crops.

2 Background

itGrowsOnYou is an Australian farming advocate group (based out in regional Victoria) with a focus on helping

farmers prepare for water shortages, parasites, and other factors affecting the quality of their produce.

Due to the extremes of temperature that their members have been dealing with they have decided to set up a

system, to help farmers plan what to grow based on recent temperature readings. They have opened a tender

for interested parties to help them develop an app to make suggestions for farmers and are asking for a proof

of concept as part of this tender process.

This proof of concept should demonstrate that one can determine the effects on given crops on any particular

day as if the whole season would be like this.

Table 1: sample heat tolerance for different crops

Table 1 represents some example, you can utilise this table as your base data; however, feel free to add new

crop information as required.

Each crop has a name and a safe temperature range; within the safe temperature range the crop is expected

to provide a high yield (produces a lot of food).

In addition we have a Low-yield offset and tolerance; the danger offset represents the number of degrees outside

of the safe range before the crop is in danger of dying.

For example: Corn produces a high yield between 10 to 35 degrees Celsius, and with a low yield offset of

5

◦C , in temperatures ranges of 5-10◦C (low temperatures) and 35-40◦C (high temperatures) it will be in low

2

yield range. In low yield temperatures the crop will still survive but it will produce a low yield. Based on the

same example, corn will begin to die at 5◦C or below and 40◦C or above.

The amount of time a crop can survive in dangerous temperatures is coupled with the tolerance. The tolerance

is the number of days a crop can survive at the boundary with dangerous temperatures; for each degree

past the boundary the number of days is divided by (degreesP ast + 1).

You can use the following formulas to find a crops tolerance:

Given a Current Temperature (CurrentTemp), if CurrentTemp is below the Minimum

Safe Temperature (minTemp), or above the Maximum Safe Temperature (maxTemp) by

Low Yield Offset (offset) degrees, then the number of days that the crop of interest can

survive (survivalDays) can be calculated via:

Finally each crop has a season in which it grows, the times of the year of each season depends on where you

live but for simplicity in this assignment you may assume each location’s seasons are at the same time of the

year as they are where you live.

3

3 What you need to do

This assignment consists of multiple tasks, including programming, documentation, and use of software tools.

It is strongly recommended that you practice pair programming rather than trying to split up the coding and

attempting parts individually.

You will need to communicate effectively with your team while working on the assignment. Your individual

use of Git, Asana, and Google Drive will affect your final marks on this assignment and as with Assignment

1, your final marks will be scaled by your team contribution as determined by CATME feedback (see section

titled CATME Peer Assessment).

Finally, there will be a 15-minute team “client” presentation as well as an individual interview on your submitted

code, both of which will occur during your week 12 practical class. This is described in a later section

in this document.

3.1 Getting started

1. One team member should create an “assignment2” directory with the necessary initial directory structure

in your team Git repository by committing the provided skeleton code (see the Skeleton code and also

the “Submission” section below).

2. Someone in your team needs to sign up for an account on DarkSky.net, the web service you will use for

weather data (see Resources section below). You will need an API key to call the DarkSky.net JavaScript

API.

3. Read and discuss the list of required functionality below and create Asana tasks for the necessary features.

4. Discuss and plan out how the functionality of the app will work, which can be done by drawing activity

diagrams for the process flow of the app.

5. Draw out the storyboard and wireframes for the entire app. (You will do this in your Week 8 prac

activity)

6. Identify and draw the class diagram for the two main classes being used.

7. Based on your storyboard and wireframes, break down the work to be done and assign them to each

team member on Asana. We strongly recommend doing pair programming for those that are weak in

coding.

Note: Your team can modify or extend your app and the provided skeleton; however, it must meet all required

functionality listed in assignment and you must ensure usability (See Week 11 prac) when designing

the behaviour of the app.

4

3.2 Required Functionality

Feature 1: Location and crop lists

Update mainPage.js such that the full list of locations and crops are populated on the screen; these should

have the relevant code to either send the user to the view page for a given location (if a location is selected) or

trigger the removal of a crop if a crop is selected. The users are greeted with this page and it should include

the following functionalities:

Feature 1.1: Add Crop button

Residing on the title bar and it will open the crop page (refer to Feature 2.1)

Feature 1.2: Add Location button

Residing on the title bar and it will open the location page (refer to Feature 3.1)

Feature 1.3: Delete Crop

When the user taps on a crop, your code should remove that crop from the list of crops and update local

storage appropriately (this should use your code to save/load crop data to/from local storage). Once a

crop has been removed you should ensure that the list has updated appropriately to not include the

removed crop.

Note: you should confirm the user hasn’t tapped the wrong crop by accident before proceeding

Feature 1.4: View Location

When the user taps on a location, they should be taken to the view location page for that location (Refer to

feature 3.2.)

Note: Your app should show temperature data for the current day for every location listed (see Feature 3.3).

Feature 1.5: Delete Location

There should be a button in the view location page which allows the user to remove a location; on tapping

this the location should be removed from local storage and the user returned to the index page.

Feature 2: Crop Page

This is where you create new crops (see feature 2.1) and any crops created here will appear on the main index

page (see 1.Main Page).

5

Feature 2.1: Adding Crops

You should setup the addCrop.html and addCropPage.js files so that the user is able to create a new crop (by

providing all relevant information) and create an instance of the crop class. This instance should be saved to

local storage using the code you will implement in one of the features listed later on. Once a crop has been

saved the user should be returned to the index page where their new crop should now appear in the list (see

Location and crop lists feature).

Feature 2.2: Crop class

You should create a Crop class in the shared.js file which has the following attributes:

• name – the name of the crop

• season – the season in which it grows (e.g. summer)

• safeTempRange – the safe range of temperatures for a good yield

• lowYieldOffset – the number of degrees beyond the safe range which can become dangerous to the crop

• _tolerance – how much a crop can stand dangerous temperatures

Feature 3: Location Pages

In this section youll provide the features to:

• Add new locations (see feature 3.1)

• View a location information with historical weather and temperature information and the estimated

impact on crops (see features 3.2 to 3.8)

– The temperature data for the last 12 months is retrieved from Dark Sky API, cached in local storage

and then retrieved from cache for the user; unless not available in cache; in which case it will be

updated by using Dark Sky API again (see features 3.3 to 3.5)

– Check seasonality of crops and estimate the impact of weather on a crop of interest, based on

historical temperatures (see features 3.6 to 3.8)

6

Feature 3.1: Add Location Page

You should update the addLocation.html and addLocationPage.js files so that the user is able to enter a location

(by Suburb and country e.g. Melbourne, Australia or Clayton, Australia) and, using MapQuest’s geocoding

API (see “Resources” section below), you should be able to find a GPS coordinate for this location and display

this location on the map.

The app should display the given address as an annotation on the map. The map and address annotation is

intended to allow the user to check the address was recognised as the desired location. Next, the user can

optionally enter a nickname for the location. If successful you should add this location to your list and update

local storage appropriately.

Note: If there is no valid GPS position for a location entered by the user (treat anything less accurate than city

level as an invalid position), then nothing should be added to the Locations List and an error can be shown to

the user.

Feature 3.2: Select a location

Users will be directed here after tapping on their selected location on the "Location and crop lists page". On

this page they should see a map view clearly showing the location itself (e.g. if Monash Clayton were the

location it would appear in the map with a symbol or mark of some form) as well as a nickname if one was

given. On this page you will later show weather details for a given date and allow the user to remove the

location. These are included in features listed later on but you may wish to ensure the user has a means of

entering a desired date at this point.

Feature 3.3: Getting temperature data from Dark Sky API

You should setup code which allows you to connect with the Dark Sky API (refer to Resources section) and

request forecast information for a given date and location. The user should be able to choose a date on the

view location page (only the last 12 months from today) and if valid this date should be shown on the page.

With a valid date, your code should contact the API and request a daily forecast for that date and location

chosen (see resources on how to do this). This may take some time to come back (see feature 3.5). Once

the data comes back, you should update the view page to show the high and low temperature of that day.

Remember to use the correct date format (you can use the Dark SkyDateString function of the Date object to

do so).

Note: Before a date is chosen, your app should show temperature data for the current day.

7

Feature 3.4: LocationWeatherCache class

You should start by creating a class (LocationWeatherCache) in the shared.js file to represent a set of historical

data held persistently by the app (this will help to reduce time waiting from the Dark Sky API later on).

Note: This class should have a locations attribute which holds a series of objects (identified by location and

date) which hold weather information for that date and location.

Feature 3.5: Getting data from the cache

Since the API allows a limited number of calls and can take some time to return with data, we want to save

results as we get them. Using your LocationWeatherCache class you should store weather information

(identified uniquely by location and date) and keep this up to date in local storage (refer to Other Important

Considerations - Storing and retrieving from local storage). Now you will need to update your code for

requesting data from Dark Sky to first check whether that information is in your cache; if the data is in your

cache you should retrieve that instead and only if the data isn’t in the cache should you make an API request

from Dark Sky.

Feature 3.6: checking which crops are in season

You should have a representation for the dates that correspond to the seasons in Australia.

Once you have this, you should consider the date of a given forecast and determine which of the crops stored

in local storage (refer to Other Important Considerations - Storing and retrieving from local storage) are in

season (e.g. a summer crop is in season if the date of the measurement falls within summer). You should

display the crops which are in season on the view page along with their safe temperature range.

Feature 3.7: Estimating effect of weather on crop

Once you have the list of crops in season for a given date you should check the highest and lowest temperature

of that day against the crop requirements.

You should then determine which situation of the below applies

• [cropName] will have a high yield – where both high and low temperatures are within the safe range

• [cropName] will survive but have low yield – where high or low temperatures are outside the safe range

but not far enough to be dangerous (e.g. 35-40 is safe with a low yield offset of 3 and the low is 33 and

the high is 42)

• [cropName] will perish after [X] days – where either the max or min temperature is in the dangerous

range. In this case, X is the number of days the crop would survive (See background)

– if both max and min are dangerous, compute days of survival based on the more extreme (e.g. -20

is more extreme than 30 if a crop’s safe range is 20-25 with a 3 degree low yield offset)

8

Feature 3.8: Displaying relevant crops and effects

Finally, update the view page to display the state for each crop in season; e.g. both corn and tomatoes are in

season and the max temperature is 48 and the min temperature is 30. In this case it would say that corn has

a safe range of 10-35 and would perish in 1.11 days and it would say that tomatoes have a safe range of 15-45

and would have a low yield.

Note: It should make it clear that this assumes the temperature is consistent with this over the full season.

Feature 4: Other Important Considerations

Feature 4.1: Storing and retrieving from local storage

You will need to prepare code to save forecasts and crops to local storage and separate code to retrieve them

from local storage. On retrieving you will need to create new instances of the relevant classes as appropriate.

The Programming component of this assignment is worth 9% of your unit mark.

Your team can modify or extend your app as you like, provided it has the required functionality. In particular,

ensure you consider usability (See Week 11 prac) when designing the behaviour of the app.

4 Resources

• MDL: Material Design Lite documentation

• Mozilla Developer Network: Reading the GPS sensor

• Mozilla Developer Network: Date documentation

• The Dark Sky Forecast AI documentation

• MapQuest’s Geocoding API

9

4.1 Technical Documentation

Your team should produce three pieces of technical documentation for your app. The documents should be

submitted as A4 size pdf files (font size 12).

• A basic Project Management Plan. This is internal documentation detailing:

– Project aim and scope

– Team members, and their responsibilities

– How you are going to do the project, e.g., team meetings, minutes, handling communication of

changes to the code, processes

– Any other information you would want to give to a new team member

Note: See Project Management Plan document template on Moodle for what should be included.

• A Class Diagram. This is internal and external documentation for developers detailing:

– The full set of classes used in the code (including all their attributes, methods, and class name),

(excluding API classes)

– The relationship(s) between different classes

∗ and multiplicities for these relationships

Note: This should be an A4 PDF page in landscape orientation

Note2: You should also consider the need to represent elements within the LocationWeatherCache

class as instances of some other class and the relation between them [YOU DO NOT NEED

TO IMPLEMENT THIS IN CODE HOWEVER IT SHOULD BE INCLUDED AS

APPROPRIATE IN YOUR CLASS DIAGRAM]

Note3: You should prepare this diagram on the computer (rather than by hand) e.g. visio, powerpoint,

google drawings, etc.

• A User Guide. This is external documentation for users that detail:

– How to get started using the app, with screenshots

– Any known bugs or limitations

Note: See user guide document template on Moodle for what should be included.

Your team will be assessed based on the quality of these documents. This will be worth 9% of your mark for

the unit.

10

5 What you are provided with

We have made available a skeleton version of the app. The skeleton provides you with several HTML pages

and associated JavaScript and CSS files representing the structure of the app. You will need to implement the

logic and functionality for each of these pages as described below. You are NOT allowed to change the

file names.

The app skeleton contains 4 web pages that utilise MDL for their interface:

• addCrop.html

• addLocation.html

• index.html

• viewLocation.html

The app skeleton contains 1 css file in the css folder which is listed as follows, and linked in all html files.

• style.css (included in all html files)

The app skeleton contains 5 JavaScript files in the js folder which are linked as follows:

• addCropPage.js (included in addCrop.html)

• addLocationPage.js (included in addLocation.html)

• dateExtensions.js (included in index.html)

– this file includes the darkSkyDateString function which can be run as someDate.darkSkyDateString()

to get a new Date object which is in the format Dark Sky expects

• mainPage.js (included in index.html)

• shared.js (included in index.html, addCrop.html, addLocation.html and viewLocation.html)

• viewLocationPage.js (included in addRoute.html, index.html and navigate.html)

You will need to create relevant classes in the shared.js JavaScript file so that they can be used by all html files.

The pages in the app skeleton are mostly blank and include sample entries to demonstrate how to communicate

information from one page to another.

You may modify these as you like, however you must not change the names of the files.

11

6 Submission

Your team should submit their final version of the application online via Moodle. You must submit the

following:

• A zip file of your Assignment 2 folder named based on your team (e.g., “Team014.zip”).

This should contain your code and documents with the folder structure below.

This should be a ZIP file and not any other kind of compressed folder (e.g. .rar, .7zip, .tar).

Please ensure that your Assignment 2 folder (and Git repository) use the following structure:

The submission should be uploaded by the team leader and must be finalised by week 11 – Friday 07/09/2018

23:55 (local time). Please note: Your entire team needs to accept the assignment submission statement individually

on Moodle.

You also need to individually complete the CATME peer assessment survey as described under “CATME Peer

assessment”.

Your assignment will be assessed based on the contents of the Assignment 2 folder you submit via Moodle.

You should ensure that the copy of the assignment submitted to Moodle is the final version that exists in your

Git repository. We will use the same phones as your team phone when marking your assignments.

Your presentation will be given during your practical classes in week 12.

12

7 Presentation

This assignment includes a presentation component worth 6% of your unit mark.

Your team has completed their proof of concept and is ready to show it off to itGrowsOnYou. Their representative

Wahrum Day has organised for all the teams to give presentations across the same week. Mr Day

will evaluate each presentation and use them to decide which team to award the final contract to. That team

would then go on to extend this prototype to estimate how past data is likely to impact on the next year and

dynamically make suggestions for itGrowsOnYou’s members for what to plant in the coming year.

In your week 12 prac class your team will deliver a formal client presentation. It will be based on the app you

produced for Assignment 2. You should ensure that your presentation isn´t framed as a university assignment,

but a formal project. Note that the purpose of this is not to sell the app, but rather to convince the client

that you met the requirements. As with any good presentation, it should be prepared well in advance of the

due date (including any visual aids) and it should be well rehearsed as a group and individually.

Format

Each student team will deliver a 15-minute oral presentation (in prac class) describing and demonstrating the

functionality of their app and detailing any limitations of the application. Every member of the team should

present for 3-4 minutes.

• The target audience for this presentation is the client.

• This presentation would be delivered in a formal business setting and so all team members should be

dressed appropriately.

• This presentation must discuss the structure and functionality of the application as well as any design

decisions made.

13

8 Marking criteria

This assignment consists of several component assessment items with the following associated marks (percentages

of total marks for the unit):

• App code and functionality 9% (group)

• Production of technical documentation 9% (group)

• Use of Git (Code), Asana (Task Management) and Google Drive (Documentation)

(moderating factor to assignment)

• Presentation - individual component 3% (individual)

• Presentation - Team component 3% (group)

• Interview (moderating factor to code)

• Peer Assessment (moderating factor to assignment)

App code and technical documentation

Assessment criteria:

• Required functionality and correct behaviour of the produced app

• Quality of app source code, including overall structure and code documentation

• Clarity and quality of individual oral presentations

• Structure, appropriateness, and level of team-client presentation

• Participation and appropriate use of tools for team software development, including communication style

• Appropriateness of technical documentation, including structure, completeness and communication quality

You will be marked as a group, however your individual marks will be subject to peer review moderation based

on CATME feedback and scaling factors.

A detailed marking rubric will be available on the unit Moodle page.

14

Contribution through use of collaborative tools

Each team member will be individually assessed on their use of three tools for collaborative software development:

• Git (and GitKraken desktop client) for managing revisions of the app source, and handling commits by

multiple team members.

• Asana for team communication, project management and issue tracking.

• Google Drive for document authoring.

The history of your contribution over the entire period of the assignment, on Git, Asana and Google

Drive will be individually considered. For the use of each of these tools you will be given a score depending on

your observed level of contribution. Students with less than the acceptable level of contribution for will incur

a penalty to their assignment mark:

Score Penalty

No contribution 10%

Some contribution 5%

Appropriate contribution 0%

Note: It is not enough to just use these tools for some dummy actions just prior to submission. This will not

be counted. It is expected that you will use these tools regularly throughout the term of the assignment. You

must give your demonstrator access to your team Asana workspace and Google Drive folder for Assignment

2.

15

Presentation assessment

Students are marked individually for this assignment on their presentation skills Assessment criteria:

• Voice is of appropriate volume, speed and enthusiasm

• Language is appropriate for a formal context and jargon is only used where necessary (and explained if

used)

• Eye contact is consistent and covers most of the audience

• Body language complements the presentation

• Explanations are clear and visual aids used appropriately

Teams are assessed on the structure and management of the presentation using the following criteria:

• Introduction clearly identifies the members of the team, what is to be spoken about, and who is talking

about what

• Conclusion clearly closes the presentation and refers to previously covered content

• Material included is relevant, justified and of high quality

• Speakers are given an equal share of time and are smoothly transitioned between

• The presentation adheres to the required time limit and the time spent on a section is appropriate for

the complexity of that section

• Attire is appropriate for a formal setting

• Appropriate use of visual aids

Final marks will be a combination of both the individual and team marks.

16

Assignment code interview

During your week 12 prac class your demonstrator will spend a few minutes interviewing each team member

to individually gauge the student’s personal understanding of your Assignment 2 code. The purpose of this is

to ensure that each member of a team has contributed to the assignment and understands the code submitted

by the team in their name.

You will be assigned a score based on your interview, and your code mark will be penalised if you are unable

to explain your team’s submission:

Category Description Penalty

No understanding

The student has not prepared,

cannot answer even the most basic questions

and likely has not even seen the code before.

100%

Trivial understanding

The student may have seen the code before

and can answer something partially relevant

or correct to a question but they clearly cant

engage in a serious discussion of the code.

30%

Selective understanding

The student gives answers that are partially

correct or can answer questions about one

area correctly but another not at all. The

student has not prepared sufficiently.

20%

Good understanding

The student is reasonably well prepared and

can consistently provide answers that are

mostly correct, possibly with some prompting.

The student may lack confidence or speed

in answering.

10%

Complete understanding

The student has clearly prepared and

understands the code. They can answer

questions correctly and concisely with

little to no prompting.

0%

17

CATME Peer assessment

You are expected to work together as a team on this assignment and contribute roughly equal amounts of

work. Peer assessment will be conducted via the CATME online system. You will receive email reminders at

the appropriate time.

Not completing the CATME peer assessment component may result in a score of zero for the assignment.

Do:

• Give your teammates accurate and honest feedback for improvement

• Leave a short comment at the end of the survey to justify your rating

• If there are issues/problems, raise them with your team early

• Contact your demonstrators if the problems cannot be solved amongst yourselves

Do NOT:

• Opt out of this process or give each person the same rating

• Make an agreement amongst your team to give the same range of mark

18

Other information

Where to get help

There will be a FAQ posted in Moodle and updated periodically. You can also ask questions about the

assignment on the General Discussion Forum on the unit’s Moodle page. This is the preferred venue for

assignment clarification-type questions. You should check this forum (and the News forum) regularly, as the

responses of the teaching staff are “official” and can constitute amendments or additions to the assignment

specification. Before asking for a clarification, please look at the FAQ and forum.

Plagiarism and collusion

Cheating, Plagiarism and collusion are serious academic offenses at Monash University. Students must not

share their team’s work with any student outside of their team. Students should consult the policies linked

below for more information.

https://www.monash.edu/students/academic/policies/academic-integrity

https://eng.monash.edu.au/current-students/cheating-and-plagiarism.html

See also the video linked on the Moodle page under the Assignment block.

Students involved in collusion or plagiarism will be subject to disciplinary penalties, which can include:

• The work not being assessed

• A zero grade for the unit

• Suspension from the University

• Exclusion from the University

You are required to reference code that has been obtained or provided by other sources (i.e. online), including

formulas for calculating. This should be done within a comment above the code.

Late submissions

We do not accept late submissions without special consideration. Such special consideration applications

should be made to the unit email address with a completed form and supporting documentation within two

business days of the assignment deadline.

http://www.monash.edu/exams/changes/special-consideration

19

Extensions

We do not grant extensions on the assignment unless the majority of a team has been affected substantially

over the period of the assignment by factors out of your control, as outlined in the special consideration form.

Such special consideration applications should be made to the unit email address with a completed form and

supporting documentation within two business days of the assignment deadline for each affected member.

http://www.monash.edu/exams/changes/special-consideration

Unavailable team members

If team members are missing on the day of the presentation, the remaining members should proceed without

them. Missing team members will receive a mark of zero unless they are granted special consideration. Such

special consideration applications should be made to the unit email address with a completed form and supporting

documentation within two business days of the presentation date.

http://www.monash.edu/exams/changes/special-consideration

You must also inform your team members ahead of time if you will be absent on the day of the presentation.

If your team has less than three members presenting, notify the unit staff.