程序代写案例-ECM2434

欢迎使用51辅导,51作业君孵化低价透明的学长辅导平台,服务保持优质,平均费用压低50%以上! 51fudao.top
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作业君
51作业君

Email:51zuoyejun

@gmail.com

添加客服微信: abby12468