” COMP2913程序 写作、 辅导Python，C++语言COMP2913 Software Engineering Group ProjectGroup Project Description1 IntroductionThis project involves development a software system for the management of a cinema.Each system will have a set of requirements that are provided as a separate document published bythe end of Week 2.You have been grouped into teams of approximately 6 students to work on this. Groups will shortlybe allocated; see an announcement on Minerva for further details. Further details are given inSection 5.The project work begins in Week 3. Your team should arrange a meeting once groups are arrangedand use this initial meeting to exchange contact details, discuss each others skill sets, review thisdocument and consider technology choices for the project. Each of you should also check that youare able to access Your teams GitLab project area (see Section 6).Sprint 1 begins on Monday 15th February. Each sprint lasts for two weeks. You will have three fullsprints before the Easter vacation, during which we expect much of the functionality to beimplemented. The remainder of the timeencompassing the Easter vacation and the first weekback after the vacationshould be used to implement any outstanding low-priority features, fixbugs, polish the implementation and finalise deliverables. The project concludes with a demo of thefinished product.2 Problem DomainFamiliarising yourself with the problem Domain would be useful preparation for this project. Spendsome time exploring how similar systems work. Examine similar businesses that you are aware of.3 ImplementationSpecific stakeholder requirements are enumerated in the product backlog, provided separately.One important (and hopefully obvious) point to note is that your solution will not be a real system!It will need to record details of bookings and payments, but it will not actually make thosebookings. The payment process should be simulated, but should be realistic.You should, however, use real data where possible. These data can be created manually; we do notexpect your solution to acquire such information automatically. You will need to collect a realisticset of data in order to demonstrate your system.Although your solution is subject to the technical constraints outlined below, this still leaves youwith a certain amount of freedom to choose tools, frameworks, libraries and programminglanguages that suit your teams interests and abilities. You will need to demonstrate your systemoperating at some points so please Bear this in mind as part of your solution.In choosing technology, be realistic about what your team can do in the time available, and keep inmind that a reasonably good mark is achievable for relatively modest implementations provided thatthe organisation and management of the project is good.4 Basic Architecture4.1 ServerYour solution should have a client-server architecture. It will be easiest to use HTTP as the baseprotocol for communication between clients and server, and this will also provide you with the mostflexibility, but a TCP-based solution is acceptable. For the best marks, the server should supportmultiple simultaneous connections from clients.The server should interact with a database that stores details specific to the domain: for example,registered users, available classes, sessions and bookings. Ideally, this should be an SQL database. Asolution in which data are stored as files in CSV, JSON or some other format is acceptable, but notas professional.To simplify development, demonstration and marking, use either an embedded database or adatabase server that can be run without needing special privileges or installation in systemdirectories. SQLite is a suitable choice of embedded database. If you are using Java on the serverside, Java DB comes bundled with the JDK and can run either as an embedded database or adatabase servereither of which would be suitable for this project.4.2 ClientsThere are 2 required interfaces to the system: a user/customer and an employee/managerA solution will provide a single client interface for the customer and appropriately separatedinterfaces for employee and Manager. You have the following options for your interfaces:1 (a) . A web interface that customers can use to view availability and book sessions;1 (b). A mobile app, for Android or for iOS, that customers can use to view availability and booksessions;2. A desktop or web application simulating the interface that an employee would use face-to-face tomake bookings and take payment;3. A desktop or web application that the manager can use to perform selected administrativefunctions such as calculating income for the week, reviewing aspects of the business.4.3 TestingTesting should not be an afterthought. You solution should be tested throughout its development,and testing should be automated where possible. It is worth devoting significant effort to this. Usethe testing tools discussed in the exercise worksheets where appropriate, but feel free to researchand use other tools if they are helpful to you.4.4 Building DeployingYou should automate as much of the build and deployment processes as possible. Ant, Maven andGradle may be viable options for this. Others tools may be more appropriate, depending on thenature of your system and your technology choices.It should be possible to build, deploy and run your solution using your chosen build tool(s), with aminimal number of commands. For example, a single command to build the whole system, onecommand to run the server and one command to run the desktop application (assuming youve thechosen the latter option) would be a good way of arranging things.Note that we do not expect you to deploy the server-side components of your solution to realservers in the cloud! You are welcome to implement this as an optional feature, if you have theaptitude and the interest in doing so, but it is not required.As with testing, it is worth Starting early and devoting significant effort to this. Build automationcan save you a lot of time and pain, so you should aim to get it set up as soon as possible.5 Approach5.1 OverviewThe broad approach to be followed by all teams is a simplified and scaled-down version of theScrum method already discussed in lectures.The process is driven by the Product Owner (PO), who will provide each team with an initialprioritised list of requirements in the product backlog (published separately by end of Week 2).The primary period of development is broken down into a sequence of three two-week sprints. Atthe start of each sprint, you should have a sprint planning meeting in which you agree on a subset ofproduct backlog items to implement, identify the tasks required to deliver those product backlogitems and then allocate those tasks to team members.In this simplified version of Scrum, the PO will not be present at these planning meetings. The teamwill therefore need to check the product backlog before each planning meeting and seekclarification from the PO if necessary, via Class Teams.You should hold two or three status meetings during each sprint. Status meetings are shortnomore that 15 minutes in lengthand involve each team member briefly describing what they havedone since the team last met, what they will be doing from now until the next status meeting, andfinally what issues they are facing that might prevent progress. Discussion of issues should bedeferred to other meetings or online communication, not necessarily involving the whole team.You should finish your sprint with a sprint review meeting. This should begin with, or follow soonafter, a brief discussion of progress with the PO. All members of a team are expected to attend thismeeting. You should use it to reflect on the feedback given by the PO and identify aspects of yourdevelopment process that can be improved for the next sprint.5.2 Scrum MasterYou will need someone to take on the role of Scrum Master (SM). The SM should organise andchair all of the sprint planning, sprint review and status meetings. The SM should nominate anotherteam member to take notes during planning and review meetings. The note-taker is responsible foruploading their notes to the project wiki (see below). Formal notes are not required for the statusmeetings.The SM should keep attendance Records for all meetings (including the status meetings), using oneor more page in the project wiki. The SM should also investigate any absences or missed taskdeadlines, on behalf of the team, via Teams or other means as appropriate.Remember that the SM is not the project manager! Decisions affecting the project should be takenby the entire team. The SM is a facilitator, not a decision-maker. In our modified version of Scrum,the SM is also a developer but is entitled to do less development work than others on the teambecause of the aforementioned duties.It is recommended that the SM role be rotated amongst team members, but changes in SM are onlypermitted between sprints, not during a sprint.5.3 Team MembersTeam members should attend all meetings if possible, and provide apologies that are noted for anyabsences.Team members should use the projects issue tracker (see Section 6.2) to record information aboutthe tasks they are carrying out. Other project documentation should be stored in the wiki (seeSection 5.3).Team members should use Git version control for all programming activities (see Section 6.1) andshould push the changes they have made locally back up to the remote project repository on aregular basis, to facilitate code review and sharing of the new code with others in the team.Team members can work on tasks alone but ideally in collaboration with others. You shouldconsider adopting a pair programming approach such as that advocated by XP, for instance. This isparticularly recommended for complex or critical parts of the system.6 Project ToolsProject management should be done using a remotely-hosted instance of GitLab, at httpss://gitlab.com. You should create a project area for your work. You must add the module staff, toyour project with master access, so that we can review your work when required. We will addguidance on this to Minerva soon.A vital first task for every team member is to check whether you can successfully access yourteams project area. Make sure you do this before Sprint 1 starts.6.1 Version ControlAll source code must be managed using the Git version control system. Each team should have ashared repository, which can be accessed via the HTTPS or SSH protocols:HTTPS httpss://gitlab.com/xxx/team.gitSSH git@gitlab.com:xxx/team.gitSubstitute your teams name (in lowercase) for team above.By default, any clone, fetch or push operation involving the remote repository will requireauthentication. This can be done by supplying your GitLab username and password when prompted.It is possible to avoid manual authentication on every clone, fetch or push by using the SSHprotocol and uploading an SSH public key to your account. For further information on this, see httpss://gitlab.com/help/ssh/README.mdIf youve not already set up SSH access, we recommend that you do this before Sprint 1 begins.One other important decision that you NEed to make before Sprint 1 begins is your preferred Gitworkflow. Please refer to the module Learning Resources for detailed discussion of this. By default,all team members have been granted Master permission in GitLabwhich means that all teammembers have permission to push commits into the master branch. However, it is probably best toavoid this and follow a feature branch workflow, whereby individuals or pairs work on eachfeature in separate branches and then issue merge requests when the feature is complete.Someone will need to act on merge requests and handle the task of merging features into the masterbranch, resolving any conflicts that arise. We recommend appointing one or more lead developers todo this. Ideally, lead developers will be the most experienced programmers / Git users on your team.6.2 Issue TrackerEach teams project area should include an issue tracker. There is documentation at httpss://docs.gitlab.com/ee/user/project/issues/Your team should agree on some suitable issue labels and set them up before recording any issues inthe tracker. GitLab provides a reasonable set of defaults, to which you can add or remove labels asyou see fit. You can also prioritise labels if you wish.In addition to setting up some labels, you should also define milestones. Sprint 1, Sprint 2,Sprint 3 and Final Demo are needed, but you can define others if you wish.Use the tracker to record the tasks given to each team member. That team member should berecorded in the tracker as the assignee of the issue. Note that the assignee is responsible forclosing the issue when the task has been completed. You should also use the tracker to record bugsfound during testing, suggestions for changes to features, etc.Issues are written using GitLabs own flavour of a lightweight mark-up language called Markdown.Take some time to familiarise yourself with it. More information can be found at httpss://gitlab.com/help/user/markdown.mdGitLab also provides an issue board, which allows you to group issues into different columns toshow current status, Kanban-style. You might find this to be useful way of visualising the overallstatus of the project. More information can be found at httpss://gitlab.com/help/user/project/issue_board.md6.3 WikiEach teams project area Should include a simple wiki, which can be accessed at httpss://gitlab.com/xxx/team/wikis/homewhere team is your team name in lowercase.The wiki is your projects web site and the home for all project-related materials that arenot stored in the repository. Further details of what we expect to see in the wiki are given inSection 6. httpss://docs.gitlab.com/ee/user/project/wiki/Wiki pages are written using GitLab-flavoured Markdown, so take some time to familiariseyourself with the syntax (see links above).如有需要，请加QQ：99515681 或WX：codehelp
“
添加老师微信回复‘’官网 辅导‘’获取专业老师帮助，或点击联系老师1对1在线指导。
