comp1531

[leo英系代essay]

题意： 通过测试、开发和维护python后端服务器写几个开发文档 解析： 1.在协议接口中为所有的功能创建测试 2.写一个pdf，记录你当前对产品的了解和对用户需求的理解 3.对规范和所提供功能的解释提出假设，写在assumptions.md里 4.写一个计划文档，介绍自己下一步将如何进行开发阶段，写在plan.md 5.写下对团队合作如何成功运作以及对团队合作的思考，写在Reflection.md 涉及知识点： 团队合作思考，开发计划文档 原文 COMP1531 Major Project Aims: • To provide students with hands on experience testing, developing, and maintaining a backend server in python. • To develop students’ problem solving skills in relation to the software development lifecycle. • Learn to work effectively as part of a team by managing your project, planning, and allocation of responsibilities among the members of your team< • Gain experience in collaborating through the use of a source control and other associated modern team-based tools. • Apply appropriate design practices and methodologies in the development of their solution • Develop an appreciation for product design and an intuition of how a typical customer will use a product. Changelog Nothing here yet Background To manage the transition from trimesters to hexamesters in 2020, UNSW has established a new focus on building an in-house digital collaboration and communication tool for groups and teams. Rather than re-invent the wheel, UNSW has decided that it finds the functionality of Slack to be nearly exactly what it needs. For this reason, UNSW has contracted out Rayden Pty Ltd (a small software business run by Rob and Hayden) to build the new product. In UNSW’s attempt to connect with the younger and more “hip” generation that fell in love with flickr, Tumblr, etc, they would like to call the new UNSW-based product slackr. Rayden Pty Ltd has sub-contracted two software firms: • BananaPie Pty Ltd (two software developers, Sally and Bob, who will build the initial web-based GUI) • YourTeam Pty Ltd (a team of talented misfits completing COMP1531 in 19T3), who will build the backend python server and possibly assist in the GUI later in the project In summary, UNSW contracts Rayden Pty Ltd, who sub contracts: • BananaPie (Sally and Bob) for front end work • YourTeam (you and others) for backend work Rayden Pty Ltd met with Sally and Bob (the front end development team) 2 weeks ago to brief them on this project. While you are still trying to get up to speed on the requirements of this project, Sally and Bob understand the requirements of the project very well. Because of this they have already specified a common interface for the front end and backend to operate on. This allows both parties to go off and do their own development and testing under the assumption that both parties comply will comply with the common interface. This is the interface you are required to use Beside the information available in the interface that Sally and Bob provided, you have been told (so far) that the features of slackr that UNSW would like to see implemented include: Ability to login, register if not logged in, and log out Ability to reset password if forgotten it Ability to see a list of channels Ability to create a channel, join a channel, invite someone else to a channel, and leave a channel Within a channel, ability to view all messages, view the members of the channel, and the details of the channel Within a channel, ability to send a message now, or to send a message at a specified time in the future Within a channel, ability to edit, remove, pin, unpin, react, or unreact to a message Ability to view user anyone’s user profile, and modify a user’s own profile (name, email, handle, and profile photo) Ability to search for messages based on a search string 10.Ability to modify a user’s admin privileges: (MEMBER, ADMIN, OWNER) 11.Ability to begin a “standup”, which is a 15 minute period where users can send messages that at the end of the period will automatically be collated and summarised to all users To get further information about the requirements, Rayden Pty Ltd will provide a pre-recorded video briefing (with verbal and visual descriptions) of what they’d like to see in the Slackr product. This will be released on September 23rd. Setup After your week 2 tutorial, you should know who your team members are. Follow the instructions on the tutorial sheet to ensure your team is registered. You need to do this by Thursday 9PM in week 2. If you registered your team on time, then on Sunday of week 2, you should have access to an individual repository at this URL: https://gitlab.cse.unsw.edu.au/COMP1531/19T3/team_name where team-name is the name of your group as registered on the course website. Progress check-in During your lab class, in weeks without demonstrations (see below), you and your team will conduct a short stand-up in the presence of your tutor. Each member of the team will briefly state what they have done in the past week, what they intend to do over the next week, and what issues they faced or are currently facing. This is so your tutor, who is acting as a representative of the client, is kept informed of your progress. They will make note of your presence and may ask you to elaborate on the work you’ve done. Iteration 1: Tests and Stories Task In this iteration, you are expected to: Create extensive tests (using pytest) for all of the functions in the agreed upon interface. These should all be in files of the formn *_test.py. See below for more information. Create user stories for your current understanding of the product based on your previous understanding of a slack-like app. Each individual story should form its own card on the project task board. Write assumptions that you feel you are making in your interpretation of the specification and of the functions provided. Write these in markdown in assumptions.md. Write a brief 1-page plan highlighting how you will approach the following iteration (the development stage). Write these in markdown in plan.md. You may include diagrams, tables or whatever other information you believe conveys your plan. Write a brief 1-page reflection on how this iteration has gone and how you successfully operated as a well-functioning team. Write these in markdown in reflection.md. You are not expected to begin developing or completing the actual functions themselves. The files described above should all be in the root of your repository. If you’ve not written markdown before (which we assume most of you haven’t), it’s not necessary to research the format. Markdown is essentially plain text with a few extra features for basic formatting. You can just stick with plain text if you find that easier. Tests It is up to you how you structure your tests, but we do require that you write all of your stubs and tests in the /server/ folder. Our recommendation is to break all of the functions to test up into 1 or many files (this is a decision for you and your team), and then create test files in the same directory as the files the tests are testing. An example of this has been done with: • /server/echo.py /server/echo_test.py • Remember that we encourage you to write stub functions for all of the functions we provide. Stub functions are dummy implementations of functions that allow them to be trivially tested. E.G. A stub function for a user to login may always return a dummy auth token “123456”. This will allow your tests to successfully compile. It is expected that some errors may appear in your tests as you write them that you won’t discover until you develop the backend in iteration 2. You may also wish to create some helper files with extra helper functions if that would assist you writing your tests. (More info) User Stories The scaffold for user stories will be provided in the lecture on Monday 23rd September. Please refer to that lecture for information about the structure of the user stories. Submission This iteration is due to be submitted at 5pm Sunday 6th October (week 3). You will then be demonstrating this in your week 4 lab. All team members must attend this lab session. To submit, run this command in the CSE environment: 1531 submit iteration1 This will submit the contents of your repo on GitLab and perform a check to make sure that the files above are present. Make sure that everything you intend to submit is included in your repo. User stories should be entered into GitLab on the task board for your project.