Table of Contents
Type: Capstone Project | Subject: Computing | Level: Masters | Word Count: ~3,400 words
This model capstone project was produced by an Essays UK specialist as reference material for learning purposes only. For support in this field, see our computer science and computing project specialists.
Design, build and evaluate a working software artefact (3,000-3,800 words, plus supporting diagrams) that addresses a genuine problem for an organisation of your choice. Your report should justify your requirements and design decisions, describe your implementation and testing approach, evaluate the artefact against its stated objectives using real or realistic data, and reflect critically on the project’s limitations.
This capstone project designs, builds and evaluates a Student Attendance Analytics Dashboard (SAAD) for the Department of Computing at Ashcombe University, addressing a well-documented problem: personal tutors received attendance information up to six weeks after non-engagement began, limiting opportunities for timely intervention. Grounded in learning-analytics research linking early engagement to retention and attainment (Tinto, 1993; Sclater, 2017), the project follows a design-science approach to build a lightweight, GDPR-compliant dashboard that consolidates attendance data from three existing systems, swipe-card logs, virtual-learning-environment (VLE) login records, and seminar sign-in sheets, into a single weekly view for personal tutors.
Methods: requirements were gathered through semi-structured interviews with six personal tutors and the department’s registry officer, followed by an agile, three-sprint build of an ETL pipeline, a PostgreSQL data warehouse, and a Streamlit-based dashboard implementing a tiered, rule-based risk-scoring model. Findings: a six-week pilot with two first-year cohorts (n=187) reduced the average time between disengagement and tutor contact from 41 days to 6 days, with 27 of 31 tutors who completed the evaluation survey rating the dashboard “moderately” or “highly” useful. Limitations, data-ethics considerations and recommendations for department-wide rollout are discussed.
In UK higher education, engagement and attendance are established, well-evidenced predictors of retention and degree outcomes (Tinto, 1993; Office for Students, 2022). Departments that can identify disengaging students early are better placed to intervene before non-attendance becomes non-completion. At Ashcombe University’s Department of Computing, however, attendance is currently recorded across three disconnected systems: swipe-card readers at lecture-theatre entrances, VLE login logs for online seminar materials, and paper sign-in sheets for small-group tutorials, which registry staff transcribe into a single spreadsheet roughly once every six weeks.
Personal tutors are formally expected, under the university’s student-support policy, to identify and contact disengaging students early. In practice, the six-week reporting cycle means tutors often only see attendance data long after a student has effectively stopped attending, by which point re-engagement is considerably harder and the student may already have fallen behind on assessed coursework. The Head of Department commissioned this project to explore whether a lightweight, department-built dashboard could close this visibility gap without requiring investment in an expensive institution-wide system.
The problem is not unique to Ashcombe: departmental staff surveys conducted alongside this project’s scoping phase found that four of five personal tutors relied primarily on informal, anecdotal signals, a student missing several consecutive tutorial sessions, rather than on the official attendance record, to judge whether a student was disengaging, since the official record was too infrequently updated to be actionable. This informal reliance meant that quieter students, who might attend fewer optional sessions without drawing attention in the way a visibly struggling student would, were disproportionately likely to be missed until attendance had fallen substantially.
The aim of this project is to design, build and evaluate a Student Attendance Analytics Dashboard that gives personal tutors near-real-time, actionable visibility of student engagement, without requiring registry staff or academic tutors to adopt new data-entry processes. The specific objectives are to:
The scope is limited to Level 4 (first-year) undergraduate students within the Department of Computing across a single semester. Postgraduate students and placement-year undergraduates are excluded, as their engagement is tracked through separate mechanisms that fall outside this project’s timeframe and data-access permissions.
The link between attendance, engagement and student success is well established in UK and US higher-education research. Tinto’s (1993) model of student integration frames early academic and social engagement as central to retention, while the National Survey of Student Engagement literature similarly treats participation as a leading indicator of outcomes rather than a mere administrative record (Kuh, 2009). More recent UK sector data reinforces this link at scale, with the Office for Students (2022) reporting a consistent association between low early-semester engagement and non-continuation, particularly in the first year of study.
Learning analytics, the measurement and analysis of data about learners for the purpose of understanding and improving learning, has grown into an established field within UK higher education, supported by sector guidance from JISC on both effective practice and ethical implementation (Sclater, 2017; JISC, 2022; JISC, 2023). An early and influential example is Purdue University’s Course Signals system, which combined learning-management-system and student-information-system data into a simple traffic-light risk indicator shown to students and advisors, and was associated with improved grades and retention in early evaluations (Arnold and Pistilli, 2012). Subsequent critique, however, cautioned that visible risk labels shown directly to students can create self-fulfilling or demotivating effects if poorly designed, and argued that analytics interventions require careful pedagogical framing rather than a raw risk score (Wise, 2014). This critique directly informed a key design decision in this project: SAAD surfaces risk information only to staff, not directly to students, avoiding the labelling risk identified in the literature while still enabling timely human-led contact.
Within educational data mining more broadly, Baker and Inventado (2014) distinguish between transparent, rule-based approaches and opaque predictive models; the latter can offer greater predictive accuracy at scale but require larger datasets and are harder for non-technical staff to trust and interpret. JISC’s Code of Practice for Learning Analytics (JISC, 2023) explicitly recommends that institutions adopt analytics approaches proportionate to their data maturity and be able to explain any intervention triggered by the data to the student concerned. Given the department’s limited historical dataset and the project’s short delivery window, a transparent, rule-based risk model was judged the more defensible and auditable choice over a predictive model for this first iteration. Finally, dashboard-design literature emphasises minimising decorative complexity and maximising the proportion of visual “ink” devoted to genuinely informative content (Few, 2013), a principle applied directly to SAAD’s visual design in the Implementation section below.
A further consideration drawn from the software-engineering literature concerns build-versus-buy decisions in resource-constrained academic settings. Sommerville (2016) and Pressman and Maxim (2020) both argue that smaller, bespoke tools are often preferable to large commercial systems when requirements are narrow, well understood and unlikely to change substantially in the short term, provided the bespoke tool is built with maintainability in mind, for example through modular code, automated tests and clear documentation, so that it does not become a fragile, single-person dependency once the original developer has graduated. This consideration shaped several implementation choices described below, including the decision to keep the ETL logic in well-tested, modular Python functions rather than a single monolithic script.
This project followed a design-science research approach (Vaishnavi and Kuechler, 2015), appropriate for an applied computing capstone that both builds an artefact and evaluates it against a real organisational problem: problem awareness, drawing on the introduction above; suggestion, informed by the literature review; development, an agile, three-sprint build; evaluation, a six-week pilot; and conclusion, presented in the final two sections of this report.
Requirements were gathered through six semi-structured interviews, five personal tutors and the department’s registry officer, each around twenty-five minutes, thematically analysed to derive functional requirements (a weekly cohort summary view, an individual-student drill-down, an automatically generated flag list, and a lightweight digest notification) and non-functional requirements (role-based access restricted to a student’s own personal tutor, response times under two seconds for standard queries, and no requirement for registry staff to change their existing data-collection workflow).
The build followed three two-week agile sprints. Sprint one delivered the ETL (extract, transform, load) pipeline: Python scripts using the pandas library extract weekly exports from the three source systems, standardise inconsistent timestamp formats and student identifiers into a common schema, and load the cleaned data into a PostgreSQL data warehouse running on the department’s existing Linux server. Sprint two delivered the risk-scoring logic and an initial dashboard built with Streamlit and the Plotly charting library, chosen over a commercial business-intelligence tool because both integrate directly with the existing Python codebase, carry no licensing cost, and can be deployed on infrastructure the department already controls (Sommerville, 2016; Pressman and Maxim, 2020). Sprint three added role-based authentication, a weekly automated email digest, and refinements identified during user-acceptance testing with three volunteer tutors.
The ETL transformation logic was covered by a pytest unit-test suite (94% statement coverage on the core transformation module), verifying correct handling of missing records, duplicate entries and inconsistent date formats across the three source exports, in addition to the manual user-acceptance testing sessions described above. All development and testing used a pseudonymised dataset, with real student identifiers replaced by non-reversible tokens; production access was restricted to authenticated personal tutors via role-based access control, consistent with UK GDPR data-minimisation principles (Information Commissioner’s Office, 2023) and JISC’s Code of Practice for Learning Analytics (JISC, 2023). The project received departmental ethics-panel approval (reference COMP-ETH-24-118) prior to the pilot, and students in the pilot cohorts were informed, via the standard programme handbook update, that attendance data already collected for administrative purposes would additionally be used to support personal-tutoring conversations.
Version control was managed through a private Git repository throughout the three sprints, with a lightweight code-review step, a second team member reviewing each pull request before merging, applied to the ETL and risk-scoring modules given their direct influence on which students would be flagged to tutors. Configuration values, including the risk-band thresholds in Table 1 and the database connection details, were kept outside the application code in a separate configuration file, so that thresholds could be adjusted by department staff after the pilot without requiring a code change or redeployment, a maintainability consideration consistent with standard software-engineering practice (Fowler, 2018).
Figure 1 summarises SAAD’s architecture. The three source systems feed a nightly batch ETL process, which loads standardised records into a PostgreSQL warehouse; the Streamlit dashboard queries this warehouse directly, applying the risk-scoring rules in Table 1 to generate a weekly cohort overview for personal tutors and a separate summary view for the programme team. During the pilot, the pipeline processed approximately 3,200 attendance records per week across the two participating cohorts, completing the nightly batch run in under four minutes.
Figure 1: SAAD system architecture, from source data through the ETL pipeline and warehouse to the tutor-facing dashboard.
The risk-scoring engine applies the rules shown in Table 1 to each student’s rolling four-week attendance percentage, recalculated nightly. The thresholds were set conservatively during Sprint two, following discussion with the pilot tutors, to minimise false positives while still catching genuine disengagement early enough to allow a meaningful intervention.
| Risk Band | Rolling 4-Week Attendance | Trigger Logic | Recommended Tutor Action |
|---|---|---|---|
| Green (Low Risk) | ≥85% | None | No action required |
| Amber (Monitor) | 70–84% | Below 85% for 2 consecutive weeks | Appears in weekly digest; reviewed at next scheduled tutorial |
| Red (At Risk) | <70%, or 3 consecutive missed sessions | Flag generated on next overnight batch run | Tutor contact required within 5 working days |
During the six-week pilot, 56 of the 187 pilot students (30.0%) were flagged Red at least once, generating a total of 71 individual flag events across the period, as several students moved in and out of the Red band as attendance fluctuated. The dashboard’s cohort-heatmap view, showing all students in a cohort colour-coded by current risk band, was the feature tutors reported using most frequently, followed by the individual student drill-down, which plots a student’s rolling attendance percentage against the three risk thresholds over the semester to date. Registry staff reported that the automated nightly ETL process removed the need for their previous manual six-weekly compilation exercise entirely, freeing an estimated three hours of administrative time per week.
Accessibility was considered from the outset given that the dashboard would be used by staff with a range of visual abilities: risk bands are distinguished by both colour and an accompanying text label (Green/Amber/Red plus the percentage figure), rather than colour alone, following the general principle in the Web Content Accessibility Guidelines that information should not be conveyed by colour as the sole visual means (W3C, 2018), and font sizes and contrast ratios in the dashboard’s charts were checked against the same guidelines during Sprint three.
Against Objective 4, Table 2 compares pilot outcomes with the department’s pre-dashboard baseline, drawn from the previous year’s equivalent cohort where tutors relied on the six-weekly spreadsheet compilation. The average time between the onset of disengagement, defined as the point a student’s rolling attendance first dropped into the Red band, and the first recorded tutor contact fell from 41 days at baseline to 6 days during the pilot.
| Metric | Baseline (Prior Cohort, Pre-Dashboard) | Pilot (With SAAD) |
|---|---|---|
| Average days from disengagement onset to first tutor contact | 41 days | 6 days |
| Red-flagged students who re-engaged within 3 weeks of contact | Not tracked | 61% (34 of 56) |
| Tutors rating usefulness “moderate” or “high” (of 31 respondents) | n/a | 87% (27 of 31) |
| Registry staff time spent compiling attendance reports per week | 3.5 hours | 0.5 hours |
Of the 56 students flagged Red during the pilot, 34 (61%) returned to at least Amber-band attendance within three weeks of tutor contact, a result tutors attributed largely to how much earlier contact now occurred relative to the previous six-weekly cycle. Of 34 personal tutors involved across the two pilot cohorts, 31 completed a short post-pilot evaluation survey; 27 of these (87%) rated the dashboard “moderately useful” or “highly useful”, with the weekly digest and cohort heatmap cited most often as valuable features, and two tutors specifically welcoming the shift away from raw spreadsheet data towards a colour-coded, prioritised view.
Against the original objectives, the project met Objectives 1-4 within the pilot’s scope: requirements were gathered and prioritised, the ETL pipeline and warehouse were built and ran reliably throughout the pilot, the dashboard and risk-scoring engine were implemented and used by tutors, and the pilot demonstrably reduced time-to-contact against baseline. The main limitation is sample size and duration: a six-week pilot with 187 students provides encouraging but not statistically definitive evidence, and the re-engagement figures cannot yet be linked to end-of-semester assessment outcomes, since the pilot concluded before final marks were available.
It is recommended that the Department of Computing extend SAAD to all Level 4 and Level 5 cohorts from the next academic year, subject to registry-team sign-off on data-sharing arrangements for the additional modules involved. Prior to wider rollout, institutional single sign-on should replace the pilot’s stand-alone authentication stub, and the automated weekly digest should be extended to include a short, tutor-facing explanation of why each student was flagged, improving transparency in line with JISC’s guidance on explainable analytics (JISC, 2023). A follow-up evaluation linking Red-flag history to end-of-semester attainment is recommended once a full semester of post-intervention data is available.
Principal risks for wider rollout include planned upgrades to the university’s swipe-card system, which would require the ETL pipeline’s extraction logic to be updated, and the risk that tutor capacity to respond to flags does not scale linearly as cohort numbers grow; a review of tutor caseloads is recommended alongside any expansion. Data-governance oversight should also scale accordingly, with the departmental ethics panel asked to review the wider rollout before it proceeds.
On reflection, the design-science approach provided a useful structure for balancing technical build work against genuine evaluation against a real organisational problem, rather than building a technically interesting system in isolation from its intended users. The most significant technical challenge was reconciling three source systems with inconsistent timestamp formats and student-identifier conventions within the ETL layer; this consumed more of Sprint one than originally planned and is a useful lesson for any future integration project of this kind, in that data-cleaning effort is easy to underestimate at the requirements stage. The most significant design lesson was the value of transparent, staff-facing risk information over a more sophisticated predictive model: given the literature’s caution about opaque or student-facing risk labels (Wise, 2014), and the department’s still-limited historical dataset, the simpler rule-based approach used here proved both technically achievable within the project timeline and more readily trusted by the tutors who had to act on it. A natural next step, once two or more years of consistent data exist, would be to evaluate whether a modest predictive model can improve on the current rule-based thresholds without sacrificing this explainability.
A final reflection concerns the boundary between what SAAD was built to do and what it was deliberately kept from doing. The project team resisted several suggestions raised during requirements gathering to extend the dashboard into automated messaging directly to students, or into a broader wellbeing-tracking tool covering factors beyond attendance, on the grounds that both would raise materially more complex ethical and data-governance questions than could be resolved within a single capstone’s timeline and ethics approval. Keeping SAAD narrowly scoped to attendance-based, staff-facing risk flagging made the six-week pilot achievable and the ethics-panel approval straightforward, and this scope discipline is offered as a practical lesson for other student teams attempting applied, data-driven capstone projects within academic departments: a smaller, well-evaluated artefact built and tested end-to-end is of considerably more value, both academically and organisationally, than a more ambitious system left partially built or unevaluated at submission.
Arnold, K.E. and Pistilli, M.D. (2012) ‘Course Signals at Purdue: using learning analytics to increase student success’, in Proceedings of the 2nd International Conference on Learning Analytics and Knowledge (LAK ’12). New York: ACM, pp.267-270.
Baker, R.S. and Inventado, P.S. (2014) ‘Educational data mining and learning analytics’, in Learning Analytics: From Research to Practice. New York: Springer, pp.61-75.
Beck, K. et al. (2001) Manifesto for Agile Software Development. Agile Alliance.
Few, S. (2013) Information Dashboard Design: Displaying Data for At-a-Glance Monitoring. 2nd edn. Sebastopol: Analytics Press.
Fowler, M. (2018) Refactoring: Improving the Design of Existing Code. 2nd edn. Boston: Addison-Wesley.
Information Commissioner’s Office (2023) Guide to the UK GDPR. Wilmslow: ICO.
JISC (2022) Effective Learning Analytics: A Guide for Higher Education. Bristol: JISC.
JISC (2023) Code of Practice for Learning Analytics. Bristol: JISC.
Kuh, G.D. (2009) ‘The National Survey of Student Engagement: conceptual and empirical foundations’, New Directions for Institutional Research, 2009(141), pp.5-20.
Office for Students (2022) Data and Analysis: Continuation and Attainment. Bristol: OfS.
PostgreSQL Global Development Group (2023) PostgreSQL 15 Documentation. Berkeley: PostgreSQL Global Development Group.
Pressman, R.S. and Maxim, B.R. (2020) Software Engineering: A Practitioner’s Approach. 9th edn. New York: McGraw-Hill.
Sclater, N. (2017) Learning Analytics Explained. Abingdon: Routledge.
Sommerville, I. (2016) Software Engineering. 10th edn. Harlow: Pearson.
Streamlit Inc. (2023) Streamlit Documentation. San Francisco: Streamlit Inc.
Tinto, V. (1993) Leaving College: Rethinking the Causes and Cures of Student Attrition. 2nd edn. Chicago: University of Chicago Press.
Vaishnavi, V. and Kuechler, W. (2015) Design Science Research Methods and Patterns. 2nd edn. Boca Raton: CRC Press.
W3C (2018) Web Content Accessibility Guidelines (WCAG) 2.1. Cambridge, MA: World Wide Web Consortium.
Wise, A.F. (2014) ‘Designing pedagogical interventions to support student use of learning analytics’, in Proceedings of the 4th International Conference on Learning Analytics and Knowledge (LAK ’14). New York: ACM, pp.203-211.
Need a Model Capstone Project Written to Your Exact Brief?
Our 350+ UK-qualified writers deliver referenced model documents from £15 per 250 words, with free plagiarism and AI-detection reports.
You May Also Like
All work is written by human writers. 100% AI free, guaranteed.
100% money back guarantee if you find plagiarism in our work.
COMPANY DETAILS
