PopMedNet Software Development Life Cycle Chayim Herzig-Marx Harvard Pilgrim Health Care Institute Daniel Dee Lincoln Peak Partners

Agenda Objectives SDLC Methodology Requirements and the Backlog Development and Test Questions?

Objectives Give our constituents confidence that PopMedNet is supported by a rigorous and well-documented product development methodology Explain how our constituents across multiple distributed research networks engage in the product development life cycle

SDLC Methodology Agile approach Dedicated teams Clearly defined roles, responsibilities, authorities Short development cycles, because requirements and priorities change frequently Each cycle delivers tangible capability Daily status check-in with technical teams Routine meetings with network and project teams JIRA used as the management tool

Open Source Community NIH DRN CRNnet HMORNnet Networks Contribute to PMN 5 PopMedNet MDPHnet PCORnet Mini- Sentinel

PMN Work Across Projects Contracts by Network (DRN) / Project Mini-Sentinel PCORnet MDPHnet NIH Collaboratory DRN Clinical Trials Projects Distributed Regression Projects Other Projects Contract Management DRN 3 DRN 2 DRN 1 Determine how different goals across projects can fit together Work with DRN teams to define requirements and timelines Complete development work, following software development process Complete testing & demo new features for DRN teams Release new software version to networks and open source community

Requirements and the Backlog Standard format for writing a business case Driving requirements = what PMN enables end-users to do; aka “Epics” The list of all current epics is the “backlog” Supported scenarios = how PMN will work Context diagram = how end-users relate to each other and to PMN LPP elaborates epics into detailed stories = technical requirements Anyone can add an epic to the backlog Backlog is “groomed” – continuous review and editing of requirements

JIRA Used for interactions between: PMN team and LPP teams for managing the development and testing processes PMN team and network constituents for tracking wish list items, requirements, and use cases Collaborative tool for managing the development work Requirements documentation Use cases Workflow and context diagrams Wiki collaboration space(s) for each group of constituents Used for sharing the status on contracted work, upcoming work, SOPs, etc. Integrated with JIRA for PMN team and network constituent collaboration Collaboration Tools

Sources of development work: Identified from project vision, resulting in a contract for specific development activities Wish list/backlog and bugs – networks typically have funds for ongoing software enhancements and bug fixes Coordinate and leverage work and resources across stakeholders and other PopMedNet networks PMN Software Development Process

PMN Software Development Life Cycle

Cast of Characters Product Owner Architect Product Owner Project Manager Team Lead Developer PMN Software Development Life Cycle

Product Owner Epics Writes Epics for Release Picks Playing 3 Sprints at a Time Plan PMN Software Development Life Cycle Product Owner Project Manager

Stories Writes Scope Fixed for 2 Week Sprint Define PMN Software Development Life Cycle Architect Stories for Sprint Picks Architect Product Manager User Story: As who, I want what, so that why.

Team Lead Subtasks Writes 2 Week Sprint Development Sprint Developer Codes Subtasks Bugs Fixes PMN Software Development Life Cycle Rank by Priority and Due Date Update, Build, Test, Commit, Monitor, Resolve

Development Principles Commit Early, Commit Often Tool: Subversion Continuous Integration Tool: TeamCity

PMN SDLC – Sprint – Summary Once work is selected for development: Requirements defined with use cases and user stories Technical tasks written Level of effort estimated in story points Issues prioritized based on 2 week development sprint schedule Status review routine intersection / sprint review meeting 16 User Story: As who, I want what so that why JIRA issues Estimate effort in Story Points Sprint review 2 Week Development Sprint

QA Lead Test Plan Candidates for Automation Writes QA Sprint Runs in Separate Project Sprint Length Corresponds to Release Cycle QA Sprint QA Runs Test Plan Manual Regression Test Picks PMN Software Development Life Cycle

Once development work is completed: QA teams complete 2-3 week testing sprints PMN team completes user acceptance testing (UAT) with standard testing scripts Software changes presented to constituents Software release considerations: Network-specific functionality & priorities Data Partner impact (e.g. software install needed, DPs part of multiple networks) Scheduling requirements (e.g. critical release, release to all networks or slower phased roll-out) Open source software release 18 Sprint review 2-3 Week Testing Phase (LPP QA Team) New Functionality Validated (PMN Team) PMN Software Release (contains multiple sprints)

Development Period Always Ends with a Sprint Source Code Snapshot Taken at Release Release PMN Software Development Life Cycle

Commitment Predictability PMN Software Development Life Cycle

Following a software release: Retrospective meeting and planning sessions held New epics added to backlog for future development work Release notes circulated Training sessions and demos held with constituents Backlog continuously groomed and requirements finalized for next round of development for each network 21 PMN Software Release (contains multiple sprints) Sprint review (retrospective and planning session Wish List Vision

Coding Cycle Development Server Demo Server PCORnet MDPHnet MiniSentinel HDC NIH SVN QA Server Edge Server Bug UAT Deployment Package Full QA Production Sites (Major with Workarounds) Deployment Platforms

How to Engage

How to Engage

How to Engage

Questions? Thanks for your time and attention!