PopMedNet Software Development Life Cycle Chayim Herzig-Marx Harvard Pilgrim Health Care Institute...
Transcript of PopMedNet Software Development Life Cycle Chayim Herzig-Marx Harvard Pilgrim Health Care Institute...
PopMedNet Software Development
Life Cycle
Chayim Herzig-MarxHarvard Pilgrim Health Care Institute
Daniel DeeLincoln 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
5PopMedNet
MDPHnetPCORnet
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
Cast of Characters
Product Owner
Architect
Product OwnerProject 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 OwnerProject Manager
Stories
Writes
Scope Fixed for 2 Week Sprint
Define
PMN Software Development Life Cycle
Architect
Stories for Sprint
Picks
ArchitectProduct Manager
User Story: As who, I want what, so that why.
Team Lead Subtasks
Writes
2 Week Sprint
Development Sprint
Developer
CodesSubtasksBugs
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 LeadTest PlanCandidates for Automation
Writes
QA Sprint Runs in Separate Project
Sprint Length Corresponds to Release Cycle
QA Sprint
QA
RunsTest PlanManual Regression Test
Picks
PMN Software Development Life Cycle
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
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
CodingCycle
Development Server
DemoServer
PCORnet
MDPHnet
MiniSentinel
HDCNIH
SVN
QAServer
EdgeServer
Bug
UAT
DeploymentPackage
Full QA
Production Sites
(Major with Workarounds)
Deployment Platforms
• https://popmednet.atlassian.net/wiki/
How to Engage