Project Methodology

Overview

RODENT follows an iterative and incremental method. Each stage adds something testable to the research platform. The client later clarified that the platform and model-integration framework matter more than building our own biological rat model, so we adjusted the user workflow and roadmap rather than presenting the original placeholder as finished science.

The methodology is suited to the project because the simulation contains several independent but interconnected components, including the simulation engine, arena, behavioural agents, stimuli, treatment conditions, recording mechanisms and user interface.

Iterative Development

Development is divided into focused development cycles. Each cycle identifies a set of features or improvements to implement, followed by implementation, testing and review.

A typical development cycle follows:

1. Identify the required functionality.
2. Break the functionality into smaller development tasks.
3. Design the required components and interfaces.
4. Implement the functionality.
5. Develop automated tests where appropriate.
6. Integrate the feature with the existing simulation.
7. Run the existing test suite to identify regressions.
8. Review the implementation against the requirements.
9. Document the completed functionality.

This allows problems to be identified early rather than waiting until the entire system has been implemented.

Incremental Feature Development

The project is built incrementally. Core simulation functionality is implemented before more advanced functionality is added.

The development progression broadly follows:

Core Simulation
      ↓
Arena and Environment
      ↓
Behavioural Agents
      ↓
Stimuli and Treatments
      ↓
Recording and Data Export
      ↓
User Interface
      ↓
Testing and Refinement

This is a broad history of how the foundation grew, not a rule that all UI and testing must come last. Core stepping and plugins were developed first, followed by 3D presentation and the website. In that sense the first phase was largely bottom-up. After client and user feedback, we worked from the researcher journey back into the interface: project creation, team roles, Setup, Run and Review. Automated tests continue throughout, rather than being postponed to the last box.

Modular Design

The project uses a modular architecture so that major areas of functionality can be developed independently. Plugins are used to separate responsibilities within the simulation.

For example, the simulation includes separate functionality for:

• Arena management
• Environmental stimuli
• Behavioural agents
• Data recording

This reduces coupling between components and makes individual features easier to test, modify and extend.

Testing During Development

Testing is performed throughout development rather than being postponed until the end of the project.

Automated tests are used to verify important behaviours such as:

• Correct simulation initialisation
• Stimulus activation at the expected simulation step
• Recording of state changes
• Treatment event recording
• Deterministic behaviour when using the same random seed

Existing tests are also executed after significant changes to ensure that new functionality does not introduce regressions.

Requirements Traceability

Development tasks should link back to requirements and acceptance criteria. A feature is considered ready for integration when its behaviour is demonstrated, relevant tests pass and the team can explain any deployment dependencies. A feature branch alone does not prove a live feature is complete.

This provides a traceable relationship between:

Requirement
    ↓
Development Task
    ↓
Implementation
    ↓
Automated Test
    ↓
Verified Feature

Team Collaboration

Team members work on separate areas of functionality where practical. Tasks are divided according to project responsibilities and recorded in the work tracker.

The team uses version control to allow individual contributions to be developed independently before being integrated into the main project.

The work tracker provides an overview of:

• Assigned responsibilities
• Current progress
• Completed tasks
• Outstanding work

For Sprint 2, stakeholder and user feedback is logged with the participant, observed difficulty, resulting change and follow-up understanding. See Sprint 2 User Feedback for the supplied qualitative notes and Testing and evidence for the repeatable evidence format. Exact dates, timings and quotations should not be invented when they were not recorded.

Our Experience Applying the Methodology

As the project progressed, we found it easier to build new features from the existing code than to start each feature from scratch. The simulation loop, arena data, plugin structure and recording workflow gave us established places to add behaviour. For example, the same step-based approach used for stimuli could support treatment events and their recording, while later interface work could expose functionality that already existed in the simulation.

Building in small increments also helped us see how a new feature affected the rest of the platform. We could implement one part, connect it to the current workflow, run the relevant tests and refine it using feedback. The client and user comments led us to reorganise the interface and improve the guide while continuing to build on the underlying simulation. This experience showed us the practical value of modular code and frequent integration: existing components made further development more manageable, and regular review helped us keep the platform aligned with researcher needs.

Why This Methodology Was Selected

An iterative and incremental approach was selected because the project is expected to evolve as the simulation requirements become clearer. It also allows the team to demonstrate working functionality throughout development.

The approach provides several advantages:

• Early identification of implementation problems
• Continuous testing
• Smaller and easier-to-review changes
• Reduced integration risk
• Clear progress between development stages
• Easier allocation of work between team members
• Ability to extend the simulation without redesigning the entire system

The methodology therefore supports both the technical requirements of the simulation and the collaborative requirements of the development team.

---

AI Attribution: The preceding document was generated and edited with assistance from ChatGPT Web (GPT-5.6 Luna).

---