# Hasara Sathsara, Final Year Research Project, full handover **How to use this file.** Paste the whole thing into Claude or ChatGPT, then ask your questions. Start the conversation with something like: > This is my final year research project. I am preparing for my viva. Use only the facts in this > document. If I ask something that is not in here, tell me it is not in the document rather than > guessing. Explain things simply. Everything below is fact taken from the submitted thesis, the analysis output and the test evidence. No figure in this file is estimated or rounded for effect. --- ## 1. The basics | Field | Value | |---|---| | Title | Smart Tourism Event Management System: A Platform for Hotel-Hosted Social Events in Sri Lanka | | Student | Nanayakkarawasam Mahakapuge Hasara Sathsara, ID 28461 | | Degree | BSc in Management Information Systems (Special), Faculty of Computing, NSBM Green University | | Supervisor | Ms. Pavithra Subashini | | Final thesis submitted | 11 September 2026 | | Length | 165 pages, 7 chapters, 5 appendices, 40 IEEE-numbered references | | Data collection window | 3 July 2026 to 2 September 2026 | | Respondents | 64 tourists and 40 hotel organizers, total N = 104 | | Artefact | EVENTIA, a deployed web application | | Interim 01 | 29 June 2026, Chapters 1 to 3, superseded | | Interim 02 | 20 August 2026, canonical wording for Chapters 1 to 3 | **Scope.** National. The target population is hotels, guesthouses and villas across Sri Lanka that host social events. The Southern Province coastal belt, specifically Mirissa and Matara, is the primary case setting inside that national scope, not the limit of the claim. Three stated reasons for that case setting: highest density of registered small and medium coastal accommodation, high enough event frequency to produce a usable sampling frame of organizers, and a documented operational profile consistent with small operators nationally, which supports analytical generalisation. --- ## 2. The problem Hotels, guesthouses and beach villas across Sri Lanka host social events: beach parties, live acoustic music, cultural shows, themed dinners. They are announced on chalkboards, printed flyers, scattered WhatsApp groups and social pages. Bookings come by phone call, WhatsApp message or walk-in. There is no shared place where a hotel can show its event to a traveller not already staying there, and no single page where a traveller can compare what is on across several hotels on a given night. **Consequences, measured.** - 37 of 40 organizers (92.5%) had an event run short-staffed or short-stocked at least sometimes because turnout differed from expectation. Only 1 said never. - 53 of 64 tourists (82.8%) had changed plans last minute because something at an event was unavailable on arrival. **Existing tools do not solve it.** Booking.com sells room nights and ignores the social programme. Eventbrite sells event tickets and has no concept of a room allocation or parking slot. Neither coordinates tickets, rooms, meals and parking together for one hotel's evening. --- ## 3. The model Three independent variables, one dependent variable. | Code | Name | Meaning | |---|---|---| | IV1 | Real-time Event Visibility | Can people find out what is on nearby, while it still matters | | IV2 | Pre-booking and Resource Coordination | Can people reserve entry, a room, a meal or parking in advance | | IV3 | Centralized Information Access | Are schedule, price, inclusions and remaining availability in one trusted place | | E0 | Coordination Effectiveness | The outcome. Would centralized coordination make these events run better | **Three hypotheses, written in Chapter 3 before any data was collected.** - H1: IV1 has a statistically significant positive effect on E0. - H2: IV2 has a statistically significant positive effect on E0. - H3: IV3 has a statistically significant positive effect on E0. Supported means the standardized beta is significant at p < 0.05. **Outcome: H1 not supported. H2 not supported. H3 supported in both samples.** --- ## 4. The headline finding All three predictors correlate strongly and significantly with the outcome at the bivariate level, in identical rank order in both samples. In simultaneous multiple regression, only IV3 contributes uniquely. | Predictor | Tourist beta | Tourist p | Organizer beta | Organizer p | |---|---|---|---|---| | IV1 | 0.096 | 0.368 | 0.234 | 0.138 | | IV2 | 0.118 | 0.356 | 0.192 | 0.269 | | **IV3** | **0.665** | **< 0.001** | **0.461** | **0.002** | **Why correlation and regression disagree.** The three predictors overlap heavily with each other. IV2 and IV3 correlate at 0.738 in the tourist sample. When all three enter together, the variance in the outcome that IV1 and IV2 explain is largely variance they also share with IV3, so it is attributed to IV3. **The correct statement of the finding.** It is not that real-time visibility and pre-booking do not matter. Both correlate strongly with the outcome. It is that their contribution operates *through* unified information access rather than independently of it. A platform that delivers visibility or booking without unifying the underlying record implements the two capabilities that carry no unique effect while omitting the one that does. **Two cautions that must accompany the result.** The tourist model is underpowered for detecting small unique effects at n = 64, so non-significant coefficients are a failure to detect, not evidence of absence. And the organizer coefficients for IV1 (0.234) and IV2 (0.192) are of a magnitude that would plausibly reach significance in a larger sample. --- ## 5. Every statistic ### Reliability, before and after instrument purification | Construct | Sample | Initial alpha | Item removed | Final alpha | |---|---|---|---|---| | IV1 | Tourist | 0.502 | Q7 at -0.304 | 0.789 | | IV1 | Organizer | 0.425 | Q7 at -0.338 | 0.691 | | IV2 | Tourist | 0.802 | none | 0.802 | | IV2 | Organizer | 0.665 | none | 0.665 | | IV3 | Tourist | 0.868 | none | 0.868 | | IV3 | Organizer | 0.758 | none | 0.758 | | E0 | Tourist | 0.540 | Q20 at -0.622 | 0.886 | | E0 | Organizer | 0.159 | Q20 at -0.623 | 0.690 | Purification rule, fixed in advance: remove items with a corrected item-total correlation below 0.30, worst first, recomputing after each removal, and never let a scale fall below 3 items. Only 2 items in the whole instrument ever crossed that threshold, and they were exactly the 2 reverse-coded items, in both independent samples. ### Dimensionality Principal component analysis on every purified scale returned exactly one eigenvalue above 1, with all first-component loadings above 0.57. Tourist first component variance explained: 62.4% IV1, 63.2% IV2, 71.7% IV3, 74.8% E0. Organizer: 52.0%, 51.1%, 58.2%, 52.2%. This also showed E0 to be empirically unidimensional, so the three conceptual sub-dimensions defined in Chapter 3 (Operational Performance, Decision-Making Accuracy, Booking Confidence) are retained as conceptual facets and are not scored separately. ### Descriptives and correlations | Construct | Tourist mean (SD) | Organizer mean (SD) | r with E0, tourist / organizer | |---|---|---|---| | IV1 | 3.676 (0.721) | 3.456 (0.658) | 0.571 / 0.580 | | IV2 | 3.672 (0.744) | 3.519 (0.697) | 0.677 / 0.633 | | IV3 | 3.812 (0.784) | 3.788 (0.706) | 0.809 / 0.683 | | E0 | 3.945 (0.759) | 3.719 (0.677) | n/a | All four constructs sit above the 3.00 scale midpoint in both samples. Inter-predictor correlations range from 0.456 to 0.738, below the 0.80 to 0.90 band that would signal a multicollinearity problem. ### Regression models | | Tourist | Organizer | |---|---|---| | n | 64 | 40 | | R squared | 0.673 | 0.572 | | Adjusted R squared | 0.657 | 0.536 | | F | F(3, 60) = 41.181 | F(3, 36) = 16.038 | | p | < 0.001 | < 0.001 | | Durbin-Watson | 2.165 | 1.617 | | VIF, IV1 / IV2 / IV3 | 2.058 / 2.959 / 2.236 | 1.996 / 2.462 / 1.562 | All VIF below the conservative threshold of 5, all tolerances above 0.10, both Durbin-Watson inside the acceptable 1.5 to 2.5 range. Assumptions were checked before interpretation. --- ## 6. Who answered **40 organizers.** Role: 45.0% event coordinator or events manager, 27.5% owner or general manager, 17.5% front desk or guest relations, 10.0% food and beverage manager. Property type: 35.0% boutique or guesthouse under 20 rooms, 30.0% mid-size 20 to 60 rooms, 27.5% beach or holiday villa, 7.5% resort of 60 rooms or more, so 62.5% below mid-size. Event frequency: 47.5% a couple of times a month, 30.0% weekly, 12.5% several times a week, 10.0% rarely, so 90.0% host regularly. Staffing: 42.5% dedicated event staff, 32.5% handled alongside other duties, 22.5% outsourced, 2.5% nobody, so 55.0% without dedicated event staff. **64 tourists.** Age: 60.9% aged 25 to 34, 39.1% aged 18 to 24, nobody outside that range. Origin: 96.9% domestic Sri Lankan travellers, 3.1% international, which is 2 people. Visit frequency: 46.9% 2 to 3 times including this trip, 25.0% more than 6 times, 17.2% first time, 10.9% 4 to 6 times. Trip duration: 40.6% 2 to 3 days, 39.1% a day trip, 12.5% more than a week, 7.8% 4 to 7 days, so 79.7% staying 3 days or fewer. --- ## 7. The instrument Both questionnaires share a 25-item structure so the same constructs are measured on both sides and the model can be tested twice independently. | Items | Purpose | |---|---| | 1 to 4 | Respondent and property profile, not scored | | 5 to 9 | IV1, 5 items, Q7 reverse-coded and later removed | | 10 to 13 | IV2, 4 items | | 14 | Supplementary disruption frequency, reported as a frequency, not scored into a scale | | 15 to 18 | IV3, 4 items | | 19 to 23 | E0, 5 items, Q20 reverse-coded and later removed | | 24, 25 | Open text, analysed thematically | All scored items use a 5-point Likert scale, 1 strongly disagree to 5 strongly agree. The variable labels are deliberately hidden from respondents so nobody can guess what is being measured. This was one of the changes made after the supervisor rejected the first draft questionnaires in June 2026 as looking machine-written and as lacking free-text questions. **Known internal inconsistency.** Table 3.2 in Chapter 3 lists the planned item counts as 5 / 5 / 5 for the three IVs and 6 for the DV. Table 4.2 in Chapter 4 reports the allocation actually administered, which is the table above. Every statistical result in the thesis is computed on the Table 4.2 allocation, and Appendix A contains the instrument itself. If asked, explain that Table 3.2 is the design-stage plan and Table 4.2 is what was administered and analysed. --- ## 8. The thematic analysis Six-phase Braun and Clarke procedure. Themes derived inductively from a full reading, then expressed as explicit coding rules so counts are reproducible. Blank answers, answers under 15 characters and non-substantive answers were excluded and reported separately. Substantive counts: tourist Q24 = 36, tourist Q25 = 40, organizer Q24 = 28, organizer Q25 = 30. All percentages below are of substantive responses. One response can carry more than one theme. **Tourist Q24, experiences of failed event discovery or access** | Code | Theme | % | |---|---|---| | T1 | Information incomplete, unclear or outdated | 47.2 | | T2 | Forced to contact the property directly or ask locally | 33.3 | | T3 | Missed the event or found it sold out after the delay | 16.7 | | T6 | Booking or payment mechanism failed | 13.9 | | T4 | Resource exhausted on arrival | 8.3 | | T5 | Conflicting information between channels | 8.3 | | T12 | Undisclosed eligibility or access restriction | 8.3 | **Tourist Q25, desired change** | Code | Theme | % | |---|---|---| | T7 | One centralized platform as a single source | 52.5 | | T9 | Complete event detail in one view | 50.0 | | T10 | Direct, secure or instant booking | 35.0 | | T8 | Live availability and capacity visibility | 27.5 | | T11 | Mobile application form factor | 25.0 | | T13 | Better promotion and communication channels | 15.0 | **Organizer Q24, events that did not go as expected** | Code | Theme | % | |---|---|---| | O1 | Last-minute changes and coordination gaps | 46.4 | | O5 | Schedule slippage and delays | 28.6 | | O6 | Technical or preparation failure | 21.4 | | O3 | Turnout mismatch causing waste or cost overrun | 21.4 | | O4 | Promotion and reminder failure | 17.9 | | O2 | Event information scattered across channels | 14.3 | **Organizer Q25, adoption conditions** | Code | Theme | % | Became | |---|---|---|---| | O8 | Reliability and stability under pressure | 66.7 | NFR-01, NFR-03 | | O7 | Ease of use | 53.3 | NFR-06 | | O9 | Security and data protection | 46.7 | NFR-05 | | O11 | Proof from other operators first | 43.3 | Chapter 7 launch strategy | | O10 | Cost and pricing transparency | 40.0 | NFR-08 | **The key interpretation.** The dominant tourist complaint is not that events go unadvertised. It is that the information available is incomplete, unclear or stale. The deficit is one of **information integrity, not information volume.** That reframing is the single most quotable sentence in the thesis. --- ## 9. The design mandate From Section 4.3.11. Because IV3 is the only significant unique predictor in both samples, centralized information access is not one desirable feature among three. It is the mechanism through which the other two deliver value. Therefore: - The **unified information layer is the architectural core**. Event schedule, pricing, inclusions and live remaining availability constitute one authoritative record, read identically by the tourist deciding whether to attend and the organizer deciding how much to procure. - **Real-time visibility is a read surface** over that record. - **Pre-booking is the write path** into it, so a booking made by a tourist immediately and necessarily changes the availability figure both parties see. Three refinements from the qualitative evidence: availability must be live-derived rather than organizer-maintained status text, because staleness is the primary failure. The organizer view must be operational and live rather than a periodic report, because the failure happens during events. And the adoption conditions become specified testable non-functional requirements rather than generic quality attributes. --- ## 10. The artefact, EVENTIA A responsive web application. Next.js with the App Router, TypeScript, Tailwind CSS, Supabase (managed PostgreSQL, Auth, Realtime, Row Level Security), hosted on Vercel. Client-side QR generation with camera-based scanning. Every technology is justified against a constraint from the data, not preference. PostgreSQL over a document store because a booking must be transactional across several inventory rows, and because Chapter 2 found that platforms on eventually consistent stores expose stale availability, which is the exact failure the research exists to eliminate. Managed services throughout because 55.0% of properties have no dedicated event staff and cost transparency appeared in 40.0% of adoption responses. ### Six tables 1. `profiles`: who someone is, and whether they are an organizer or a tourist 2. `properties`: the hotel, guesthouse, villa or resort, owned by one profile 3. `events`: one event at one property, with a capacity ceiling and draft / published / cancelled status 4. `resource_types`: **tickets, rooms and add-ons in ONE table**, distinguished by a `kind` column, each row carrying price, total quantity and remaining quantity 5. `bookings`: one booking by one tourist on one event, with status and QR token 6. `booking_items`: one line per resource booked, with `unit_price_at_booking` copied in at booking time **Why table 4 is the thesis written as a schema.** Tickets, rooms and add-ons differ in what they represent to a guest but behave identically to the system. One table produces one query returning the complete resource position, one realtime subscription keeping every surface consistent, and one locking discipline governing all decrements. Modelling them separately would fragment availability across three code paths and reintroduce, inside the system, the same inconsistency between information sources that the research identifies as the primary failure of the arrangements it replaces. `booking_items` stores the unit price at the time of booking rather than referencing the live price, so a later price change cannot alter the recorded value of a booking already taken. ### The four contribution features 1. **The unified information layer.** Not a component. The property that schedule, price, inclusions and live availability form one record, read identically by both sides. Implemented by the single inventory table, by `remaining_quantity` being written only by the booking procedure, and by both surfaces subscribing to the same table. 2. **The multi-resource inventory model.** Any number of resources per event. Remaining initialised equal to total, then only changed by bookings. One validation rule: a total may be reduced but never below the quantity already committed to confirmed bookings, otherwise you create an oversell through configuration rather than concurrency. Events also carry a capacity ceiling across all ticket-kind resources. 3. **Atomic multi-resource booking.** The naive implementation reads availability, decides, then writes, leaving a window in which another booking can commit. Instead, the check and the decrement happen inside one database transaction invoked as a single remote procedure call. Rows are locked with `SELECT ... FOR UPDATE` in ascending id order, which removes the race window and makes deadlock unreachable. The failure path names the exhausted resource so the booking panel can mark one line rather than discarding the basket. The QR token is a cryptographically random value, not a sequential id or a hash of the booking id. 4. **Live availability propagation.** Both the organizer dashboard and the tourist event page subscribe to changes on `resource_types`. On commit, PostgreSQL publishes the row change and every subscriber receives the new figure with no polling and no refresh. The subscription runs from the browser directly to the database service. If the channel is unavailable, the client falls back to polling **and displays an indicator that figures may lag**, because silently showing stale numbers would reproduce the exact failure the research identified. ### QR check-in, three outcomes Unknown token or wrong event: refused with the reason shown. Already checked in: refused as a replay, original check-in time displayed. Valid and confirmed: admitted, status set, timestamp recorded, booking contents displayed. The timestamps produce attendance data, which is the number organizer items 9 and 11 described as missing. ### Access control Row Level Security policies at the database, not checks in the interface. A guest reads only their own booking because the database refuses, not because the page hides a link. An organizer reads bookings on events at their own properties only. The `profiles` policy was initially self-only, which left organizers unable to put a name to a booking they had received. It was widened to include guests holding a booking on that organizer's own events, deliberately narrowly, with three extra checks added to TC-09 to hold that boundary. ### Seed data 6 properties across all 4 property types, 14 events of which 12 published, 42 resource types across all 3 kinds, 288 bookings. Seeded with partial availability rather than full stock, because a system tested only against untouched inventory never exercises the boundary conditions. No real person's name, phone number or email appears in it. ### Out of scope, deliberately Payment gateway integration (bookings record a total and are marked pending payment), email and SMS notifications, reviews and ratings, multi-language, admin moderation, native mobile apps, image upload, social login, refunds beyond a status change. All declared in Section 1.10. --- ## 11. Requirements 14 functional and 9 non-functional, each traced to a survey figure or a cited source. **Four functional requirements are marked critical**, as the minimum set implementing the supported hypothesis: - **FR-04** Each event presented as a single unified record containing schedule, pricing, inclusions and live availability - **FR-05** Live remaining availability per resource, derived from committed bookings and never manually maintained - **FR-08** Concurrent bookings shall not oversell any resource; a booking that cannot be satisfied in full commits nothing - **FR-11** Organizers view a dashboard with live booking counts and remaining stock without manual refresh Non-functional requirements are derived from the organizer adoption conditions rather than from a generic quality checklist. NFR-01 page load under 2 seconds, NFR-02 propagation under 2 seconds, NFR-03 operable under concurrent load, NFR-04 zero oversell and zero partial commit, NFR-05 access control at the data tier with unpredictable tokens, NFR-06 a first-time organizer publishes without training material, NFR-07 usable at 375, 768 and 1440 pixels, NFR-08 no per-property licence cost, NFR-09 data minimisation. --- ## 12. Testing ### Evaluation strategy Three strategies selected: functional testing against the traced requirement set, concurrency and data integrity testing, and non-functional measurement. Two considered and not used, with stated reasons. A usability panel, not conducted because the artefact reached a testable state too close to the deadline to run one with adequate rigour, and running it badly would have produced a number with no evidential value. Comparative benchmarking against a commercial platform, rejected on validity grounds because Chapter 2 established that no existing platform combines the three capabilities this system integrates. ### Ten test cases, all passed | ID | Scenario | Result | |---|---|---| | TC-01 | Organizer publishes an event; one lacking capacity or inventory is refused | Pass, 4 checks | | TC-02 | Ticket, room and add-on defined on one event; total cut below booked quantity refused | Pass, 6 checks | | TC-03 | Tourist books across two resource kinds in one action | Pass, 8 checks | | TC-04 | Booking past the capacity ceiling refused, nothing decremented | Pass, 5 checks | | TC-05 | 20 simultaneous booking requests against a resource holding 10 units | Pass, 7 checks | | TC-06 | Valid QR token admits the guest, timestamp recorded | Pass | | TC-07 | The same token presented a second time refused as a replay | Pass | | TC-08 | Dashboard updates without refresh when a booking commits elsewhere | Pass | | TC-09 | Cross-guest and cross-property reads issued directly against the API | Pass, 9 checks | | TC-10 | Every screen at 375, 768 and 1440 pixels | Pass, 39 screens | **TC-05 result.** Exactly 10 committed, exactly 10 refused with INSUFFICIENT_STOCK naming the resource, remaining quantity landed on exactly 0, and peak concurrency was 20 of 20 requests in flight at once. The peak-overlap assertion is what makes the test meaningful: had the requests been serialised by the runtime rather than held by the database lock, the outcome would have looked identical while proving nothing. **TC-05 and TC-09 were run programmatically rather than through the interface**, because TC-05 needs genuine parallelism and TC-09 must bypass the interface, since a check that lives only in the interface passes a screen-driven test while leaving the data exposed. ### Measured non-functional results | ID | Target | Measured | Verdict | |---|---|---|---| | NFR-01 browse | under 2000 ms | 501 ms p95, 400 ms p50, n = 30 | Pass | | NFR-01 detail | under 2000 ms | 336 ms p95, 252 ms p50, n = 30 | Pass | | NFR-02 propagation | under 2000 ms | 580 ms p95, 265 ms p50, n = 11 | Pass | | NFR-03 concurrent load | no functional failure | 40 concurrent, 40 succeeded, 0 failed | Pass | | NFR-04 booking integrity | zero oversell, zero partial | Verified by TC-05 | Pass | | NFR-07 responsive | 3 breakpoints, no overflow | 39 screens clean | Pass | | NFR-06 usability | task completion without documentation | Not measured | **Unverified** | One of twelve NFR-02 samples did not arrive within the ten second observation window and is excluded, leaving n = 11. It was the first sample after the channel subscribed. This is reported rather than dropped silently. These are prototype figures measured against a development server with the database in the Supabase Singapore region. The thesis reports them as prototype measurements, not production service levels. ### Seven defects found by testing 1. **A pinned search path hid the token generator.** The booking function pins its schema search path as a security definer function should, but the hosting platform installs the cryptographic extension into a separate schema, so the random token generator was invisible and every booking failed. TC-05 caught it with all 20 requests rejected for the wrong reason. Fixed by widening the pinned path, keeping it explicit rather than removing the pin. 2. **Client-side environment variables were undefined.** The helper read variables through a dynamic key, and the framework only substitutes public variables into the browser bundle on static property access, so every client component opening a database connection failed in the browser while server-rendered markup looked correct. 3. **The screenshot evidence was captured from error pages.** A consequence of defect 2. Because an error page does not overflow its viewport, TC-10 passed against 36 screenshots of a stack trace. Found by opening the images, not by reading the test output. The capture script now fails the run if any screen rendered an error or rendered empty. 4. **Organizers could not create an event at all.** Inserting a row and returning it evaluates the read policy on the new row in the same statement, and that policy called a helper marked stable, which reads a snapshot taken before the insert. Fixed by testing ownership through the property reference on the new row itself. 5. **Every booking on the dashboard showed the guest as "Guest".** The profile policy was self-only. Widened narrowly, with three added TC-09 checks. 6. **Horizontal overflow on the browse screen.** A grid track defaults to a minimum width derived from its contents, and a date input carries a large intrinsic minimum, pushing the page to 437 px inside a 375 px viewport. 7. **Cover photography illustrated nothing.** The seed used a random image service, so a photograph of an airport terminal appeared above a live music event. Replaced with a typographic panel. ### What the evaluation does and does not establish It establishes conformance to the specification derived in Chapter 4, and the concurrency and access control guarantees directly rather than by inspection. It does **not** establish realised coordination effectiveness in the field. Usability was not evaluated with participants, so NFR-06 is specified but unverified, which the thesis names as the weakest point in the evaluation. --- ## 13. Chapter 7, conclusions ### Objectives - **Objective 1, identify current challenges: accomplished.** 92.5% of organizers and 82.8% of tourists hit the failure at least sometimes. The character matters more than the frequency: the deficit is information integrity, not information volume. - **Objective 2, analyse statistical relationships: accomplished.** Full chain on both samples independently. This produced the principal empirical contribution. - **Objective 3, design and develop the prototype: accomplished.** The unified information layer is a physical property of the schema, not a presentation convention. Had the regression identified real-time visibility as dominant, a different architecture would have followed. - **Objective 4, evaluate performance and adoption intent: partially accomplished.** Adoption intent measured fully. All 10 functional test cases and all 6 measured targets passed. Usability evaluation with real participants was not conducted. ### Adoption intent Organizer composite E0 3.719 out of 5, willingness to try it for a real event 3.850, willingness to recommend to other properties 3.900. Tourist composite 3.945. ### Four problems encountered 1. **Sample shortfall.** 104 against a planned 400. The organizer sample stays proportionally strong at roughly half the qualifying properties. The tourist sample is small and narrow: 62 of 64 domestic and all aged 18 to 34. Findings generalise to the domestic young-adult traveller segment. 2. **Both reverse-coded items failed psychometrically.** Documented method factor, plausibly aggravated by respondents completing the instrument in a second language. Standard remedy applied and reported in full. 3. **The development window was compressed**, which is why Objective 4 is only partly accomplished. 4. **The dependent variable could only be measured as perceived, not realised.** The artefact did not exist in the field at survey time, so E0 was captured through behavioural intention as a TAM-grounded proxy. ### Self-reflection The most valuable result was an unexpected one. The proposal-stage assumption was that all three capabilities would contribute, with real-time visibility likely dominant, because visibility is the most visible failure to anyone standing in Mirissa on an event night. The data said otherwise, twice, in two independent samples. Treating that as the finding rather than as a problem with the data was the most useful shift in the project. The temptation to report the bivariate correlations, which support all three hypotheses handsomely, and to pass over the regression, was real and was resisted. Three steep learning curves: that reliability analysis is a diagnostic that can invalidate an instrument rather than a formality; that the gap between code that appears correct and code that is correct under contention is not visible by reading; and that stating limitations before an examiner finds them strengthens the work rather than weakening it. ### Business insight - **The wedge is the information layer, not the booking engine.** A product entering this market should lead with the unified listing and live availability. This also lowers the supply-side barrier: a property can be listed and useful before processing any payment. - **The pricing model is constrained by the evidence.** Organizer item 23 on cost mattering more than feature count returned 3.600, and cost transparency appeared in 40.0% of adoption responses. A per-property subscription is wrong where 62.5% of properties are below mid-size. Commission on completed bookings, or free listing with paid transaction handling, aligns cost to value received. - **Trust must be manufactured deliberately.** Demonstrated results and peer reviews appeared in 43.3% of adoption responses. Launch on a small number of visible reference properties, and provide an affordance for trialling on one low-stakes event. - **The realistic initial market is bounded and reachable** at roughly 60 to 80 qualifying properties in the primary collection belt. ### Six future recommendations 1. Measure realised coordination effectiveness by deploying across a season and measuring procurement variance against actual attendance, events running under capacity, and turnout prediction accuracy, each against a pre-deployment baseline. 2. Extend the sample to international visitors, currently essentially unmeasured at 3.1%. 3. Redesign or drop the reverse-scored items. 4. Conduct the System Usability Scale evaluation to verify NFR-06. 5. Separate the sub-dimensions of Coordination Effectiveness with a longer instrument. 6. Re-verify the concurrency guarantee at a larger scale before commercial deployment. --- ## 14. Methodology, in one block Post-positivist paradigm. Deductive approach, with hypotheses formalised before data collection. Design Science Research as the strategy, justified by elimination: a behavioural study alone would produce no artefact, and a software project alone would produce no validation. Peffers' six-phase DSRM as the execution workflow: problem identification (Chapters 1 and 2), define objectives (Chapter 1), design and development (Chapter 5), demonstration (Chapters 5 and 6), evaluation (Chapters 4 and 6), communication (all chapters). Two structured Google Forms questionnaires on a 5-point Likert scale. Tourist target 350 from the Krejcie and Morgan table, achieved 64. Organizer target 50 as a near-census of an estimated 60 to 80 qualifying properties, achieved 40. Organizers sampled purposively, tourists by convenience with a screening question confirming prior or planned attendance at a hotel-hosted event. Analysis sequence fixed in advance: reliability with Cronbach's Alpha at a 0.70 threshold, then Pearson bivariate correlation, then simultaneous multiple regression with significance at p < 0.05. Agile with SCRUM two-week sprints for project management. Ethics: voluntary participation with consent on the first page, anonymity with no names, emails or phone numbers collected, secure storage with raw data deleted on graduation, and academic honesty. The commitment carried through to the artefact, where no real person's details appear in the seed data. --- ## 15. History of the project - **December 2025.** Original framing: a resilient multi-stakeholder event coordination framework for live events in developing regions, with four independent variables including buffering mechanisms for network failure, aimed at large events, vendors and crowd safety. - **June 2026.** Reframed to hotel-hosted social events. "Resilient", "crowd awareness" and "multi-stakeholder" dropped. Buffering mechanisms dropped as a variable. Three IVs remained, and the outcome was named Coordination Effectiveness. Supervisor approved. - **June 2026.** First draft surveys rejected by the supervisor as looking machine-written and lacking free-text questions. Redesigned with plainer wording, hidden variable labels, and two open questions per survey. That rejection is why Chapter 4 contains a thematic analysis. - **29 June 2026.** Interim Submission 01, Chapters 1 to 3. - **3 July to 2 September 2026.** Data collection. - **20 August 2026.** Interim Submission 02. Title changed from "in Mirissa and Matara" to "in Sri Lanka". Scope formalised as national with the Southern coastal belt as the primary case setting. **This is the canonical wording.** - **Early September 2026.** EVENTIA built, deployed, seeded and tested. Seven defects found and fixed. - **11 September 2026.** Final thesis submitted. --- ## 16. Where the evidence lives | Appendix | Contents | |---|---| | A | Both survey instruments in full | | B | Full statistical output for both samples, plus thematic coding frequencies | | C | The 5 remaining use case specifications (registration, authentication, profile management, property registration, booking history) | | D | Remaining test cases and full measurement output, including the concurrency and access control transcripts | | E | Selected source code: the database schema, the `create_booking` function, and the row level security policies | Chapter page ranges: Ch 1 p12-19, Ch 2 p20-33, Ch 3 p34-45, Ch 4 p46-86, Ch 5 p87-103, Ch 6 p104-114, Ch 7 p115-121, References p122-126, Appendices p127-165. --- ## 17. Things to be careful about when answering questions - **Never claim the system improved a real hotel.** It has not been deployed for a season. The evaluation proves conformance to specification, not operational effect. - **Never say all three hypotheses worked.** Two were not supported, and that is the interesting result. - **Never say H1 and H2 have no effect.** Say the study failed to detect a unique effect, because the tourist model is underpowered for small effects at n = 64. - **Never quote the response times as production figures.** They are prototype measurements against a development server. - **Never invent a number.** If a figure is not in this document, say so and point at Appendix B or D. - **The scope is national.** Mirissa and Matara is the case setting, not the boundary of the claim. - **Payment is out of scope by design**, declared in Section 1.10, not omitted for lack of time.