After your evaluation, reclaim resources completely:

cd /opt/project_dps_demo
docker-compose down -v  # -v removes volumes (logs, db)
sudo rm -rf /opt/project_dps_demo
docker system prune -a --volumes

Why so thorough? Leftover DPS demo containers can interfere with new demo installs from other vendors.

1. Command Interface (CLI)

2. Dependency Validation

3. Containerized Orchestration

4. Sample Data Seeding

5. Network & Ports

Executing a successful Demo Install follows a disciplined methodology. First, the team defines the scope—limiting the demo to 20-30% of the full system’s complexity, yet including all high-risk integration points. For a DPS, this might involve one power distribution unit, one battery string, one monitoring client, and a simulated load. Second, the install is performed in an isolated test lab using installation scripts, configuration files, and network settings identical to those planned for production. Third, the team runs a predefined test suite: power failover, data replication latency, alarm generation, and user access controls. Crucially, the Demo Install is iterative. Bugs discovered—such as a misconfigured SNMP trap or a timeout in the authentication handshake—are logged, fixed, and retested within the demo environment before any code is promoted to the full build.