COMP3900编程语言代写、代做C/C++设计程序

日期：2021-06-27 02:56

COMP3900/9900

Project Deliverables and

Assessment

This document describes group formation, assessments, and other project course

deliverables.

! Group Formation: A group will be five (5) students in size, with all members being in

the same lab (unless there is no possibility to have 5 group members because of the

size of the lab, in which case a group of 4 may be accepted with the mentor's

permission). Please do register your group on the WebCMS3 course website under the

Groups page and specify group members as well as the Scrum Master (as Admin in

WebCMS3 Groups terminology).

! Roles: Each group should have a Scrum Master and four (or three) Developers. Their

responsibilities are discussed in the lecture. Note that these roles are for

accountability. We expect that all members should be involved in coding. Scrum

Master may contribute marginally less coding efforts, e.g., 10% less, if he/she will

administrate GitHub (having a Maintainer role) and Jira accounts for the team.

! GitHub: Each group should use their GitHub classroom repository to store and

maintain the entire code-base used for their project, and ensure they keep commit

history accurate to represent contributions made by each team-member.

2

Work Diary

Each student should maintain a work diary (call it z0001234.txt if your student zID is

z0001234) and check the file into GitHub.

From Week 1 onwards, we expect that you will update this file every week with your new

contributions to the team and the project. Check the file into GitHub at least once a week

(can be more frequent).

The content of the file should be brief but clear. For example, it should be like:

Week 1

Group formed. I created the Jira & GitHub accounts. Together with John

Smith, I wrote the user story & sprints section of the proposal. I also

found and discussed with the team all available software tools and

libraries that we can use for the project.

Week 2

I wrote the first version of hello.c, api.h, api.c and drafted a design for

the Web service API between the client and the server – all by myself.

You should also include in this diary the following information (if applicable) about the

project progress:

- what was planned for the period since the last work diary entry

- what was finished

- what were the main technical and non-technical obstacles and how they were

overcome (or what was tried and did not work)

- what was not finished, why this happened, how this affects the overall project

progress and what adjustments (if any) are needed so the success of the project is

not endangered

- what is planned for the next period (e.g., next week)

We expect that other members of the team may access this file to know where others

are up to, but you should not modify your peer’s work diary.

3

The Proposal

! Project Proposal (due Monday Week 4 @ 9.00am, 21 June) (10%): Students will

choose a project from a list of possible projects with a given description and project

objectives. They will produce a proposal that describes: the background for their

project, the product backlog to be used for satisfying all project objectives, an initial

sprint backlog, user storyboards, and the system architecture. The requirements and

criteria for the proposal are described below.

! Please make sure you also take a look at the WebCMS Proposal assessment

submission page for submission instructions, and follow those submission

instructions.

! Students may request to undertake a custom project only if 8 distinct project

objectives of similar technical depth & scope to existing projects are clearly defined

with the request. A clear project description should also be included with the

request. Such requests are subject to mentor approval and amendment, and are to

be sought prior to week 2 by filling in and agreeing to the terms on the custom

project form that can be found at https://rebrand.ly/aje7pe4 .

! The proposal should be self-contained, (ie: no content should be outside of the report

and simply linked to), and follow the following formatting requirements:

a) Include a title page containing: project title; a nominated group name; each

member’s name, email, student ID, role; proposal submission date.

b) Be at least 5 pages long (at most 12pt font with reasonable margins & spacing),

not including the title page and references page, and be in PDF format that is

readable with Acrobat.

c) Include a table of contents, and page numbers.

d) Include references and use either APA (https://student.unsw.edu.au/apa) or

Harvard (https://student.unsw.edu.au/harvard-referencing) referencing style.

! The proposal should include:

a) Background (10%)

" Clearly identifies the problem(s) being solved.

" Identifies existing work or systems in the same problem domain, and their

drawbacks.

4

b) User stories & Sprints (50%):

" Product backlog of correctly structured user stories, describing the functionality to

be delivered, with screenshots showing all these user stories defined in Jira. The

entire text of each user story should be readable inside the report.

" Defines the start and end dates for all sprints envisaged during term.

? Note: ensure that the sprints you define allow you to undertake a demo in each of

weeks 5 and 8; as well as a retrospective before each of the labs in weeks 7 and 9.

" Identifies user stories in scope for the first sprint with screenshots showing all user

stories allocated to the first sprint in Jira. The entire text of each user story should

be readable inside the report.

" Clearly communicates how all project objectives are satisfied by user stories that

are defined.

" Describes how some of the defined user stories provide novel functionality

compared to existing systems.

c) Technical depth, scale, report formatting (40%)

" Report conforms to the formatting requirements specified above; and is easy to

read.

" Interface and flow diagrams (Storyboards for user stories)

? Storyboards should be developed to illustrate the system functionality, and how

users interact with the system. One storyboard can cover multiple user stories.

All user stories should be covered by these storyboards.

" System Architecture

A clear description showing the presentation, business and data layers in the

system, and what each layer contains.

A clear description of the external actors (eg: user types) and how they interact

with the system.

A clear description of the technologies/languages planned for use (eg: mysql,

sql server, msmq, .NET, java, etc), including all third party functionality planned

to be used (eg: clouds/services/APIs/libraries/code).

5

! Proposal is marked out of 10, contributes 10% towards the final mark for the project,

and is marked according to the marking criteria below.

Project Proposal Marking Criteria

Category Max Mark

Team

Mark Comments

Background (10%)

Problem domain, existing work/systems, and their

drawbacks

1

Clearly identifies problem(s) being solved 0.5 Marks considered separately for this category

Clear evidence of research as to existing work or

systems in the same problem domain and what their

drawbacks are.

0.5

Marks considered

separately for this category

User stories and sprints (50%) 5

Product backlog of correctly structured user stories,

describing the functionality to be delivered, with

screenshots showing all these user stories defined in Jira

1.5

Marks considered

separately for this category

Defines the start and end dates for all sprints envisaged

during the length of term 0.5

Marks considered

separately for this category

Identifies user stories in scope for the first sprint with

screenshots showing all user stories allocated to the first

sprint in Jira

1

Marks considered

separately for this category

Clearly communicates how all project objectives are

satisfied by user stories that are defined 1

Marks considered

separately for this category

Describes how some of the defined user stories to be

implemented provide novel functionality compared to

existing systems

1

Marks considered

separately for this category

Technical depth, scale, report formatting / readability

(40%) 4

Report conforms to the formatting requirements specified

for the Proposal in this Project Deliverables and

Assessment document; and is easy to read

0.5

Marks considered

separately for this category

Includes clearly a detailed software architecture diagram 1.5 Marks considered separately for this category

Interface and flow diagrams 2 Marks considered separately for this category

Total Mark (out of 10) 10

6

The Progressive Demos

! Progressive Demo A (Week 5 Lab Time) (2.5%)

and Progressive Demo B (Week 8 Lab Time) (2.5%):

Progressive demonstrations provide an opportunity to showcase user stories that have

not yet been demonstrated, and how well you have developed functionality to support

these.