Closers David Beaton Kumaran Mahenthiran Jedadiah Crelly STEP Sponsors Dr.David Kluge Rick Voight Dr. Chloe Alexon Faculty Coach Prof. Tom Reichlmayr

Agenda  Introduction  Background  Goals  Process  Metrics  Current status  Demo  Reflections

What is EMS Online Directory?  One and only one nationally expanding online database of Emergency Medical Services.  A central location for your EMS and public safety organizations in your county, state or any region you wish to explore!  A tool for creating printed directories of all available EMS in as big as national or as small as specific county.

Previous Development  Ongoing project of last 2 years by SE Seniors. Phase 1 ( ): Hazmat – Designed, developed and released to staging. Phase 2 ( ): Pinchhitters – Re-designed, improved, existing features, implemented printable format, and released to production.

Goals For This Year  Improve search features  Minimize needed editor intervention for s tandardization  Automate creation of Printable Format of the directory  Adapt more Organization Types  Prevent multiple registration of organizations.  Move to a permanent server

 Lightweight model development  Easily adaptable based on priorities  Small iterations, weekly scheduling Agile Development Process

Feature Driven Development  We aren’t reinventing the wheel  Sponsors had a full year to assess software  Many of our tasks were defined in terms of features to be added  Features submitted through “feature request” document and assessed based on risk, priority and technical difficulty

Reactive Development (agile process)  Priorities changed weekly  Long-term schedule less structured, based more on higher level goals  Short-term schedule very fluid, reassessed weekly  Our process evolved throughout the quarter

Metrics (Hours per Phase)

Metrics cont. (Hours per task)

Metrics cont. (TCE total containment effectiveness)  Defects-escape to a subsequent phase  Errors-discovered during the phase that created them  Industry standard 65-98%  We were at 87.5%

Testing  Testing occurred for two weeks before deployment. Sponsors were given test environment to experiment with Small incremental changes allowed during testing Test plan developed to address major aspects of system

Lifecycle Environment  Two separate environments Production Testing  Features first added to testing environment  Sponsors would review and approve changes  Approved changes were migrated to production on a bi-weekly basis

Architecture

Major Features Added  Duplicate organization prevention  Automated address suffix standardization  Automated data population into printed directory  Last modified search  Survey management  Search result display enhancements

Demo 

Future Features  A method to retrieve survey results  Mass address overrides  notification enhancements

Positive Aspects  Delegation of work  Team cooperation  Sponsor feedback  Release management

Areas Of Improvement / Challenges  Better feature identification  Feature creep  Source control  Teleconferencing can be challenging  Adapting process to match active system Sponsors had timeframe they wanted to all organizations to update information. System was live-we had to be precise, no room for error

Questions?