ECM2434 Software Engineering Group Project Project Specification Re-connecting the student community online: a framework to promote student engagement Dr Matthew Collison January 2021 This document outlines the assessment structure for the ECM2434 Group Software Engineering Project module and provides a description of the project specification. This specification is to be released to students on 1st February 2021. Adjsutments may be made to the specification to clarify any queries raised before Friday 5th February 2021. After this date the specification will not be changed. ECM2434 Software Engineering Group Project Project Specification 1 Assessment 1.1 Groups This assessment is to be carried out by groups to produce a shared product. • Student groups were finalised in week 3 and have been published on the ELE page linked below. https://vle.exeter.ac.uk/course/view.php?id=10898#section-3 • Groups will have weekly module leader standup meetings during the group working period. Each group must suggest a time for the regular meeting and agree this with the module leader. The agreed weekly meeting slots will listed on the Group Allocation ELE page linked above. All students are expected to attend these meetings which will run weekly beginning in week 5. The purpose of these meetings will alternate between ’client meetings’ where the module leader will act as a client and ’marking meetings’ where the students will be given 6 minutes to present their sprint submission from the previous week. • One group member will submit the group project files as a zip file for each sprint for the entire team. All group members should also submit an independent text file containing the name of their group, their peer assessment and the candidate number for the team member that submitted the group project files for each sprint. Full submission details for each sprint will be provided in the ELE pages with example submissions. Note, the final peer review submission will be an individual submission and should be considered separate from the group submissions for sprint 1, 2 and 3. • Individuals will receive a mark that is weighted 50% for the group project files and 50% for the adjusted peer assessment component. The assssment is setup to encourage teams to work together. However, if there is evidence of individuals not engaging or not contributing towards team submissions the module leader reserves the right to adjust individual marks to reflect this. If team members experience any disputes please raise these with the module leader at the earliest opportunity. 1.2 Submissions There are three assessment points and submission deadlines for group submissions: • Sprint 1 (30%): Thursday February 11th 2021 (Week 5); • Sprint 2 (30%): Thursday February 25th 2021 (Week 7); • Sprint 3 (30%): Thursday March 11th 2021 (Week 9). Submissions will be assessed on three main criteria: • Process documents - to capture the process of group work and the Kanban agile methodology; • Technical documents - to capture the technical contributions, particularly source code, of the team; • Product documents - to capture the end product and client deliverables. Marks for sprint 1 assessment will focus process success, and submissions are expected to demon- strate the team following an agile and kanban methodology and making good headway working 2 ECM2434 Software Engineering Group Project Project Specification together. You should document the early stages of planning, prioritising and populating the back- log as well as early technical contributions. Process documents (particularly the Kanban board) will be the main mechanism of assessment at the stage although product documents may contain early designs that have progressed through the agile process to delivery. Marks for sprint 2 assessment will focus half on process success and half on product success. Submissions are expected to demonstrate the kanban agile framework being put to good use and delivery of early iterations of the product will demonstrate early product success. Marks for sprint 3 assessment will focus on product success. The features and quality of the final product will be assessed involving both the documentation and a presentation where the final product will be presented to the client. Technical details and professional delivery of the product will be rewarded as well as creativity in the solution. 1.2.1 Process documents The Kanban board should be a chart divided into four headline columns and seven ticket sub- columns columns: Backlog, Specification (doing and done), Implementation (doing and done) and Validation (doing and done). The board should clearly identify group members and the tasks they are undertaking (and have completed). Regular snapshots of the agile board should be taken to show the progression of tickets. Records of meetings should be kept with clear note of attendance and project progress metrics. It should be clear which members have worked on which tickets and tasks and how those tickets link to technical contributions in the source code and technologies that are being used. Links to the live agile board, live source code and any deployed software should be included in submissions where possible. 1.2.2 Technical documents A snapshot of technical progress should be provided as a link or file containing all of the technical artefacts (source code, designs and any digital assets such as database schemas) that the group have built. Professional and consistent coding conventions suitable for the chosen language should be followed. A testing strategy and the developer documentation should be included to demonstrate maturity, reliability and professionalism of the technical contributions and adherence to the software engineering principles. 1.2.3 Product documents The product documents are designed and published for the client to receive. These should reflect curated deliverable documents that relate to the product. Product documentation will culminate in a public presentation and demo of your project. This event is currently planned for Friday 12th March although is subject to change due to current cirumstances around lockdown restrictions and social distancing. 3 ECM2434 Software Engineering Group Project Project Specification 1.2.4 Marking meetings Marking meetings be held in module leader meetings after each submission deadline. In these meetings each team will give an insight into what the team have been up to, how the product works and the contributions of the team members all team members should contibute, no more than one minute speaking per group member and no longer than 6 minutes in total. This meeting will enable immidiate feedback to enable improvements for the next submission as requested in the previous year. 1.3 Submission process Each sprint submission should be made electronically using eBART. The electronic submission of group project files should consist of a single .zip file for the group, whose name is of the form GroupXSprintY.zip. As above, for each sprint one team member should submit the group project documents, all team members should then submit a peer assessment which includes the candidate number of the team member who submitted the documents. Example formatting for the peer assessment documents will be provided on ELE. 1.4 Peer review The final submission is a peer review and separate from the sprint submissions (that contain a peer assessment). Each group member will be asked to anonymously reflect on the contributions of every other group members using the SFIA framework (Skills Framework for the Information Age). These ratings will be used to calculate a peer review mark. The peer review mark is worth 10% of the module mark. 4 ECM2434 Software Engineering Group Project Project Specification 2 Requirements The requirement for this courserwork is to create an appplication to help students reconnect in a blended learning environment. 2.1 Overview Since March 2020 the student experience has drammatically changed. The learning process is often online, the opportunities for socialisation and social study are reduced and constrained, and access to a support network of friends and family has been restricted. This project aims to create a platform that promotes a better student community, through providing social opportunities and providing infrastructure to help students engage with eachother and foster student community. 2.2 Gamification A key component of the new system should be gamification. The priority for this application is to promote engagement and this should be achieved through a series of virtual rewards linked to activities and challenges that promote positive engagement with the student community. The metrics that are used for gamification and the link to achievements and recognition is inten- tionally open ended. It is up to each group to design a system they think will reconnect student in a blended learning environment and foster community. 2.3 User profiles At its core this application is designed to support students in higher education so there are a series of privileged users you need to consider: 1. Student users - These are the target audience for the main app. Student users are current students at University that you can assume will access the app primarily through a mobile device. 2. Univeristy stakeholders (academics) - This will be a member of staff responsible for the students engaging with the app and any related learning. The academic should be able to configure and update some aspects of the student interactions relating directly to learning and specifc topics. This user will expect to access the app through a desktop or laptop browser. 3. The student support network - These are people that are related to the student users, such as friends and family, that have an interest in the student user’s wellbeing but may not be a registered user of the app. 4. Developers - Developers should be able to build, extend and redeploy the app for future and alternative uses. Developers will expect to be able to access the source code from an online repository and expect clear and concise documentation and deployment instructions. The module leader, Matt Collison, will act as the client and consider all roles when discussing the project delivery. 5 ECM2434 Software Engineering Group Project Project Specification 2.4 Features 2.4.1 Community Students community relates to the students identifying with and engaging with other students through activities and study. Community networks must be supported responsibly so data sharing is selective. I’ve made some implementation suggestions below: 1. Users may get involved in activities to interact with other students 2. Users may share study notes or resources 3. Users may select ’study networks’ for students studying at the same course or at the same University, or on the same course at the same University 4. Users may track wellbeing goals, such as daily step goals or daily learning activities 5. Users may share wellbeing metrics with a support network 6. Users may interact with other students and particate in virtual activties together 7. Students may undertake virtual challenges to complete achievements 8. Students may set challenges for others to attempt 2.4.2 Gamification expanded Student engagement is absolutely key to this project. One of the key challenges is promoting regular interactions with the student community so one of the requirements of this project is to include gamification so students are incentivised with virtual rewards for regular interactions. Below are some suggestions for digital rewards and incentives for students to engage: 1. Students may achieve virtual awards that show up in the app. 2. Students may see a leaderboard of student achievements. Note this must be done responsibly and sensitively, low engagement or performance must not be visible in the app. 3. Students may be able to upvote or approve digital media or helpful resources related to their studies, similarly to stackoverflow or wiki pages. 4. Staff may be able to distinguish University approved activities with recognised roles, such as peer mentoring if they regularly participate in mentoring meetings with other students. 5. Staff may be able to set extra curricular learning challenges relating to University courses. 6. Students may be able to record and track wellbeing indicators such as mood and study time. 7. Wellbeing metrics may be shared with the support network (close friends and family). Note, this isn’t gamification per say but wellbeing metrics may be used with different triggers and more selective sharing measures. 8. Users may be able to enter live reactions and updates during streamed events. 9. Group goals may be set, for example once the entire class fulfils a goal it is recognised. Again, these metrics must be anonymised so no students are austracised by the activity. 6 ECM2434 Software Engineering Group Project Project Specification 3 Summary In summary, this project is about helping students connect with their peers during online and blended learning and promoting student community through the gamification of engagement. The assessment is a balance of ’process’, evidence of effective team work using the kanban agile method- ology, and ’product’, producing a professional and engaging application. Each team must be creative and distinguish their application from other teams in a unique way. If you have any questions at any point throughout the project please do not hesitate to get in touch,
[email protected]. 7
欢迎咨询51作业君