COMP3900设计编程辅导、web，HTML 写作

” COMP3900设计编程辅导、web，HTML 写作COMP3900/9900Project Deliverables andAssessmentThis document describes group formation, assessments, and other project coursedeliverables.! Group Formation: A group will be five (5) students in size, with all members being inthe same lab (unless there is no possibility to have 5 group members because of thesize of the lab, in which case a group of 4 may be accepted with the mentorspermission). Please do register your group on the WebCMS3 course website under theGroups page and specify group Members as well as the Scrum Master (as Admin inWebCMS3 Groups terminology).! Roles: Each group should have a Scrum Master and four (or three) Developers. Theirresponsibilities are discussed in the lecture. Note that these roles are foraccountability. We expect that all members should be involved in coding. ScrumMaster may contribute marginally less coding efforts, e.g., 10% less, if he/she willadministrate GitHub (having a Maintainer role) and Jira accounts for the team.! GitHub: Each group should use their GitHub classroom repository to store andmaintain the entire code-base used for their project, and ensure they keep commithistory accurate to represent Contributions made by each team-member.2Work DiaryEach student should maintain a work diary (call it z0001234.txt if your student zID isz0001234) and check the file into GitHub.From Week 1 onwards, we expect that you will update this file every week with your newcontributions 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 1Group formed. I created the Jira GitHub accounts. Together with JohnSmith, I wrote the user story sprints section of the proposal. I alsofound and discussed with the team all available software tools andlibraries that we can use for the project.Week 2I wrote the first version of hello.c, api.h, api.c and drafted a design forthe 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 theproject 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 wereovercome (or what was tried and did not work)- what was not finished, why this happened, how this affects the overall projectprogress and what adjustments (if any) are needed so the success of the project isnot 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 othersare up to, but you should not modify your peers work diary.3The Proposal! Project Proposal (due Monday Week 4 @ 9.00am, 21 June) (10%): Students willchoose a project from a list of possible projects with a given description and projectobjectives. They will produce a proposal that describes: the background for theirproject, the product backlog to be used for satisfying all project objectives, an initialsprint backlog, user storyboards, and the system architecture. The requirements andcriteria for the proposal are described below.! Please make sure you also take a look at the WebCMS Proposal assessmentsubmission page for submission instructions, and follow those submissioninstructions.! Students may request to undertake a custom project only if 8 distinct projectobjectives of similar technical depth scope to existing projects are clearly definedwith the request. A clear project description should also be included with therequest. Such requests are subject to mentor approval and amendment, and are tobe sought prior to week 2 by filling in and agreeing to the terms on the customproject form that can be found at httpss://rebrand.ly/aje7pe4 .! The proposal should Be self-contained, (ie: no content should be outside of the reportand simply linked to), and follow the following formatting requirements:a) Include a title page containing: project title; a nominated group name; eachmembers 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 isreadable with Acrobat.c) Include a table of contents, and page numbers.d) Include references and use either APA ( httpss://student.unsw.edu.au/apa) orHarvard ( httpss://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 theirdrawbacks.4b) User stories Sprints (50%): Product backlog of correctly structured user stories, describing the functionality tobe delivered, with screenshots showing all these user stories defined in Jira. Theentire 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 ofweeks 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 userstories allocated to the first Sprint in Jira. The entire text of each user story shouldbe readable inside the report. Clearly communicates how all project objectives are satisfied by user stories thatare defined. Describes how some of the defined user stories provide novel functionalitycompared to existing systems.c) Technical depth, scale, report formatting (40%) Report conforms to the formatting requirements specified above; and is easy toread. Interface and flow diagrams (Storyboards for user stories)Storyboards should be developed to illustrate the system functionality, and howusers interact with the system. One storyboard can cover multiple user stories.All user stories should be covered by these storyboards. System ArchitectureA clear description showing the presentation, business and data layers in thesystem, and what each layer contains.A clear description of the external actors (eg: user types) and how they interactwith 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 plannedto 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 CriteriaCategory Max MarkTeamMark CommentsBackground (10%)Problem domain, existing work/systems, and theirdrawbacksClearly identifies problem(s) being solved 0.5 Marks considered separately for this categoryClear evidence of research as to existing work orsystems in the same problem domain and what theirdrawbacks are.0.5Marks consideredseparately for this categoryUser stories and sprints (50%) 5Product backlog of correctly structured user stories,describing the functionality to Be delivered, withscreenshots showing all these user stories defined in Jira1.5Marks consideredseparately for this categoryDefines the start and end dates for all sprints envisagedduring the length of term 0.5Marks consideredseparately for this categoryIdentifies user stories in scope for the first sprint withscreenshots showing all user stories allocated to the firstsprint in Jira1Marks consideredseparately for this categoryClearly communicates how all project objectives aresatisfied by user stories that are defined 1Marks consideredseparately for this categoryDescribes how some of the defined user stories to beimplemented provide novel functionality compared toexisting systems1Marks consideredseparately for this categoryTechnical depth, scale, report formatting / readability(40%) 4Report conforms to the formatting requirements specifiedfor the Proposal in this Project Deliverables andAssessment document; and is easy to read0.5Marks consideredseparately for this categoryIncludes clearly a Detailed software architecture diagram 1.5 Marks considered separately for this categoryInterface and flow diagrams 2 Marks considered separately for this categoryTotal Mark (out of 10) 106The 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 havenot yet been demonstrated, and how well you have developed functionality to supportthese.! Marking criteria:a) Completed stories to be demonstrated are shown in Jira and described, withthese stories having the Correct status in Jira (Done) (1%)b) Demonstrates the functionality used to support each completed story (1%)c) Keeps to 12 minutes or less (0.5%)! Group members absent for a progressive demo receive 0 marks for that entire demo.7The Retrospectives! Retrospective A (Week 7 Lab Time) (2.5%)and Retrospective B (Week 9 Lab Time) (2.5%):A retrospective is a reflective activity, where the team meets to think about their teamwork process over the past sprint, and discuss: what went well, what didnt go so well,and what the team should try to over the next sprint to improve their work process.Additional aspects are also described in the marking criteria below. This meeting shouldfollow soon after the sprint demo (usually in the same day). The deliverable for eachretrospective should be emailed By the team scrum-master to your mentor and alsosubmitted through WebCMS (make sure the document submitted on WebCMS is thesame one sent over email).! Marking criteria:请加QQ：99515681 或邮箱：99515681@qq.com WX：codehelp

“