Showing posts with label #Rentals. Show all posts
Showing posts with label #Rentals. Show all posts

Thursday, 31 July 2025

WHAT IS A JAD SESSION

30 July 2025


Let's look at a definition and early history of JAD and SSADM, take a look at the roles of the participants and design a template agenda.

A JAD session - short for Joint Application Development session -  is a structured meeting that brings together business users, developers, and analysts to collaboratively define system requirements or design solutions. It’s particularly useful during the early stages of a software project.

JAD was a response to slow and error-prone traditional methods of gathering system requirements going way back to the 1970s, a methodology developed at IBM by Chuck Morris and Tony Crawford.

SSADM - Structured Systems Analysis and Design Method - dates back to the early 1980s. It was developed under contract to the UK government’s Central Computer and Telecommunications Agency (CCTA) as a standardised method for analysing and designing information systems.

By the mid 1990s, SSADM was on the way out due to the rise of RAD (Rapid Application Development), Agile, and object-oriented methods.

Object-Oriented Methods (OOM) are a way of designing and building software systems based on the concept of “objects”. These are self-contained units that combine data and behaviour, an approach mirrors the way we understand real-world entities like a car, a user, or a booking.. each has its own characteristics and actions.

An object has

- Attributes (data/state) — e.g., a User has a name, email, password.

- Methods (behaviour) — e.g., a User can log in, edit a profile, make a booking.

- Objects belong to classes, which are like blueprints for creating multiple similar objects. User gives hosts and guests.


🔍 What Happens in a JAD Session?

  • Facilitated workshop, often lasting several hours to a few days
  • Focused on rapid consensus-building
  • Participants work through use cases, data flows, interfaces, or UI mockups
  • Typically led by a facilitator, with a scribe, users, and technical experts
Business users who know the domain
Analysts who map the requirements
Developers who understand system capabilities

🧩 Typical Roles in a JAD Session

Role Responsibility
Facilitator Guides the discussion, ensures all voices are heard
Scribe Takes detailed notes, records decisions and diagrams
Business Users Share domain knowledge, describe real-world processes
Developers Ask clarifying questions, assess technical feasibility
Analysts Translate discussion into models, user stories, or specs

✅ Advantages

  • Cuts down on back-and-forth emails
  • Produces a shared understanding of goals
  • Captures accurate, detailed requirements
  • Increases buy-in from all stakeholders

📌 Use Case for Rentals

If rhe team were all co-located or online for a few hours, it would be possible to run a JAD session to:

  • Finalise feature priorities for the MVP
  • Walk through the booking flow from a user's perspective
  • Agree on UI elements based on tester feedback
  • Tackle tricky areas like deposit handling or ICal sync

Here's a JAD session agenda or template for the team.


📌 JAD session agenda

- 🎯 Purpose: Finalise MVP features, align design + functionality Participants: • 

Facilitator: Project lead analyst • Developers: [Insert Names] • Testers / Users: [Insert Names]

Session Agenda:

1. Welcome + Goals Overview (10 min)

2. Review of Core User Flows (20 min)

3. Feature Prioritisation Discussion (20 min)

4. UI/UX Walkthrough with Feedback (20 min)

5. Issue Resolution and Open Questions (15 min)

6. Wrap-up + Action Plan (5 min)

[End]

Friday, 18 July 2025

RENTALS MVP DATABASE SCHEMA

18 July 2025

1. Objective

To design a relational database back-end for a small short-term rentals business, using an Agile development approach.

The goal is a solid database schema that supports bookings, calendars, payments, reviews, messaging, etc., for a website-based Property Management System (PMS).

2. Step-by-Step Methodology (Agile-aligned)

2.1. Define MVP Scope and Roles (Agile: Product Backlog)

Identify the core features the database must support:

Properties

Availability & Bookings

Hosts and Guests

Messaging

Payments

Define user types:

Host (owner or manager)

Guest (renter)

Admin (yourself or future superuser)

Create high-level User Stories:

“As a guest, I want to book a property, so that I can stay during my trip.”

“As a host, I want to manage my property calendar, so that I avoid double bookings.”

2.2. Identify Entities and Relationships (Agile: Sprint 0 – Architecture planning)

Create an Entity List based on user stories. Typical entities:

Users (hosts, guests, admins)

Properties

Amenities

Bookings

Calendar

Payments

Reviews

Messages / Enquiries

Draw relationships:

One host → many properties

One guest → many bookings

One booking → one property

Many-to-many: property ↔ amenities

2.3. Define Primary Keys and Foreign Keys (Database Normalisation)

Every entity gets a primary key (PK)

Use foreign keys (FK) to establish links

E.g., property_id in bookings table

Use surrogate keys (like UUID or auto-increment ID)

Avoid data duplication: follow 3rd Normal Form (3NF) unless performance says otherwise

2.4. Build the Logical Data Model (Agile: Deliverable of First Sprint)

Create a visual ERD (Entity Relationship Diagram)

Use standard notation (Crow’s foot or SSADM box-style)

Colour code:

Green = Master Data (users, properties, amenities)

Blue = Transactional Data (bookings, payments)

Purple = Others (messages, reviews)

2.5. Validate with User Stories (Agile: Sprint Review & Feedback)

Review each user story:

“Can this data model support the scenario?”

E.g., “Does the booking table include guest ID, property ID, dates, and status?”

Adjust schema if necessary

2.6. Prepare for Sprint-Based Dev Build (Agile: Incremental Development)

Export schema for developers (SQL or DBML)

Link database to front-end via REST or GraphQL API

Use iterative Agile sprints to:

Add features (e.g., cancellation handling, discounts)

Refine performance

Handle edge cases (e.g., double bookings, partial refunds)

2.7. Test, Iterate, Deploy (Agile: Sprint Cycles)

Unit test DB schema (e.g., FK constraints, NOT NULL, ENUM values)

Mock data to simulate real-world use

Start with local DB (SQLite or Postgres)

Migrate to cloud-based DBMS (AWS RDS, Firebase, Supabase)

3. Final Thoughts

This method blends Agile’s iterative design with relational database rigour. The key is modularity: build minimum core features first, then expand in layers. Each sprint delivers something usable and testable — just as Agile intends.


Rentals MVP Database Schema

Master entities (green): hold reference data 
- users, hosts, guests, properties, amenities

Transaction entities (blue): record activity or events 
- bookings, payments, calendar, reviews

Junction Tables (purple): resolve many-to-many relationships or track system-level changes 
property_amenities, booking_events

Log or Event Entities: capture state/history 
- booking_events records the lifecycle of a booking (confirmed, paid, cancelled etc.)
Cross between audit logs and system workflows. Not true “transactions”, but they are time-sensitive and often append-only


Glossary

MVP – Minimum Viable Product, the smallest functional version of our system
User Story – short statement describing what a user wants to do and why
3NF – Third Normal Form, a method of designing databases to reduce redundancy
ERD – Entity Relationship Diagram, visual map of database tables and relationships
Sprint – a short development cycle (typically 1–2 weeks) in Agile methodology


A HISTORY OF THE AGILE METHODOLOGY

18 July 2025


1. Overview

The Agile methodology is a set of principles for software development that prioritise flexibility, customer collaboration, and quick delivery over rigid planning and documentation.

2. Origins of Agile

Before Agile, software was typically developed using the Waterfall model – a linear, sequential process.

Problems arose: requirements changed mid-project, documentation-heavy processes slowed delivery, and customers often got what they asked for but not what they needed.

3. Precursors to Agile
Several lightweight, iterative methods emerged to address Waterfall's weaknesses:

Rapid Application Development (RAD)

Scrum (developed in the 1990s)

Extreme Programming (XP)

Feature-Driven Development (FDD)
These shared similar values: shorter cycles, user involvement, and adaptability.

4. The Agile Manifesto (2001)

Seventeen software developers met in Utah and created the Agile Manifesto, which formalised Agile principles.

It valued:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a fixed plan

5. Post-Manifesto Evolution

Agile grew into various frameworks like Scrum, Kanban, Lean, and SAFe.

Widely adopted across industries, not just in software.

6. Conclusion
Agile emerged as a reaction to rigid methodologies. Its success lies in delivering usable software faster while adapting to change and maintaining close collaboration with users.

Glossary
Waterfall Model – a step-by-step, linear approach to software development.
Iterative – a cyclical process where feedback and adjustments happen continuously.
Agile Manifesto – a declaration of the core values and principles guiding Agile.
Scrum/XP/FDD – specific Agile frameworks or methodologies.

Source:

[End]

AGILE AND SSADM COMPARED, WHAT IS A USER STORY

17 July 2025


Agile User Stories and SSADM



1. Summary: What is a User Story?

A user story is a short, simple description of a feature or requirement written from the perspective of the person who desires the functionality - typically a user or customer. In Agile development, user stories replace traditional system requirements to promote flexibility, collaboration, and fast iteration.

A user story typically follows the format:
“As a [type of user], I want [an action] so that [a benefit/a value].”

This ensures the feature is grounded in user value. User stories are intentionally brief and act as placeholders for further conversation and refinement. They are prioritised in a product backlog, broken down into epics or tasks, and selected for development during sprint planning.

A well-written user story is INVEST:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable

The 'Three Cs' of user stories are:
- Card: The written description (usually on a card or in a tracking system)
- Conversation: Dialogue among stakeholders to clarify and refine
- Confirmation: Acceptance criteria that confirm completion

This method supports iterative development, continuous feedback, and stakeholder engagement.

2. Glossary of Agile User Story Methodology

·        User Story: A brief, simple description of a feature from the user's perspective.

·        Agile: A methodology emphasizing iterative development, collaboration, and flexibility.

·        Product Backlog: A prioritized list of all desired work or features.

·        Epic: A large user story that can be broken down into smaller ones.

·        Task: A technical work unit derived from a user story.

·        Sprint: A fixed time period for completing selected user stories.

·        Sprint Planning: A meeting to choose which user stories to implement during a sprint.

·        INVEST: Checklist for good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

·        Three Cs: Card (description), Conversation (discussion), Confirmation (acceptance criteria).

·        Acceptance Criteria: Conditions that must be met for a story to be complete.

·        Customer-Centric: Focus on delivering value to the user, not internal technical needs.

3. Comparison of Agile User Stories vs. SSADM

SSADM (Structured Systems Analysis and Design Methodology) is a waterfall methodology focused on thorough planning, rigorous documentation, and structured stages: feasibility, requirements analysis, logical data modeling, etc. It is best for stable and regulated environments.

Agile uses evolving user stories instead of static requirements. It values working software, frequent feedback, and adaptation. Documentation is minimal and collaboration is central.

Agile’s user stories fit a 'Three Layered' approach to requirements:
1. Epics (high-level goals)
2. Stories (concrete features)
3. Tasks (developer-level implementation units)

In contrast, SSADM follows:
1. Business Requirements
2. Functional Specification
3. Technical Specification

Where SSADM assumes requirements are knowable upfront, Agile embraces change and iterative clarification.

4. Glossary Mapping: Agile vs. SSADM

Agile Term

SSADM Equivalent

Comment / Mapping Logic

User Story

Process Specification

Describes functionality; refined into DFD and ELH in SSADM

Epic

Business Area Definition

High-level domain requirements

Task

Elementary Process / Module

Breakdown of a process step in DFD

Product Backlog

Requirements Catalogue

Centralised list of required system behaviours

Sprint

Phase in Project Plan

Time-boxed execution within structured lifecycle

Acceptance Criteria

Test Specification

Formal validation in SSADM

Three Cs

Structured Interview + Requirement Statement

Story lifecycle mirrors early SSADM stages

INVEST

Requirement Quality Guidelines

SSADM lacks explicit acronym but uses best practice

Card

Requirement Entry

Initial placeholder; becomes documented formally in SSADM

Conversation

Stakeholder Workshops

Corresponds to structured interviews and JAD sessions

Confirmation

Verification via Test Plan

Formalised in SSADM Test and Evaluation phase

Backlog Grooming

Requirements Review Meeting

SSADM equivalent is periodic review cycles

Logical Model

LDM (Logical Data Model)

Agile infers data; SSADM models explicitly

Flow of Interaction

DFD (Data Flow Diagram)

DFDs model data movement—analogous to interaction flow

State or Scenarios

ELH (Entity Life History)

Entity behaviour over time; maps loosely to user scenarios


What is a JAD session?

[End]