An Introduction to Extreme Programming (XP) Development Methodology Process in Healthcare: Managing Critical Projects, Delivering Rapid Results in Healthcare Payer and Provider Environments

An Introduction to
Extreme Programming
(XP) Development
Methodology Process
in Healthcare
Managing critical projects, delivering rapid results
in healthcare payor and provider environments
www.salusoneed.com

All information in this course is subject to change
without notice.
This document is provided for informational and
knowledge purposes only and SO Health, Inc.
makes no guarantees, representations or
warranties, either expressed or implied, about the
information contained within the document or
about the document itself. SO Health®, Salus One,
Inc.™ are trademarks of Salus One, Ltd.
Copyright © 2017 Salus One, Ltd. All rights
reserved.
Created in the United States of America.
Copyright 2017 SOEd 2

Course Content
• XP Process Definition
• Benefits to the Customer
• How to Engage the Process
• XP Process Overview
• Swim Lane Process Diagram and Detail
• Process Narrative
• Reporting
• Administration
• Supporting Toolset
• Solution Delivery Method Control Objective Language
3

XP Process Definition:
Purpose, Scope, and Audience

Customized Extreme Programming development
methodologies are created to provide a repeatable,
sustainable process for focused payor efforts.
The complexities of extreme programming require such
changes as the regulatory, legacy, and integrated innovation
that are required on an ongoing basis are necessary to
ensure rapid, accurate design and delivery of insurance
products and services.
Copyright 2017 SOEd5

These initiatives involve:
A) new, generally smaller IT
software development and
B) development on products
considered to be a
‘differentiator’ for payor
organizations within the
industry.

Extreme Programming,
commonly referred to as ‘XP’, is
a lightweight, people-oriented,
and highly test-driven
development approach to
software development.

Similarly, XP is not time-boxed.

Traditional Agile may approach sprints on a regularly defined
schedule of a few to several weeks.

In other words, an Agile team is
‘boxing itself in’ by stating it will
provide A, B and C functionality
within the next Sprint or the
next X weeks.
XP, however, adds new
functionality on a daily, or even
shorter basis, and may deploy to
production with relatively little
effort.
10

A primary focus is on creating the simplest solution while
focusing on immediate needs to avoid costs towards
potential irrelevance.
A key concept behind XP is the practice of doing “the
simplest thing that could possibly work.”

XP does not have a ‘Scrum Master’ as it is not Scrum.

The XP team largely manages
itself, primarily utilizing a
feedback loop between a highly
automated toolset, the
development team and the
customer.

The customer, in the role of Product Owner,
sits onsite with the development team and is
empowered to make all necessary business
decisions.
Instant communication and rapid knowledge
distribution creates an ongoing, updateable,
and shared view of the goal across the team.

XP project teams are typically
very lean with a maximum of
6-10 resources.

With these philosophies in mind, XP
also adheres to the following
Development Guidelines:
16

Test-first development: In other
words, “XP developers write the
test cases first.”

These tests should be
written/scripted prior to the
development of the functionality
that is being tested.
This helps ensure that the
application is written for
testability.

• First, fail the test cases: The idea here is to ensure that the
test really works and can catch an error.

Once this is shown, the
underlying functionality can be
implemented.
This has been coined the "test-
driven development mantra",
known as red/green/refactor
where red means fail and green
is pass.
In short, for every requirement,
there is a corresponding test
case that cannot be passed.

• Keep the unit small: For XP test driven
development, a unit is most commonly
defined as a class or group of related
functions, often called a module.

Keeping units relatively small is
claimed to provide critical
benefits.

KISS (Keep It Simple Stupid) and
YAGNI (You Aren't Gonna Need It):
Developers should not add
functionality until deemed
necessary and should focus on
writing only the code necessary to
pass tests.

XP focuses on one piece at a time and
does not design for an idealized end
state X number of years from now
(which may never occur).

Audience
The primary audience for this
guide includes:
• information technology (IT)
resources who would be
engaged on Project Teams
(including their business
customers engaged on the
team),
• IT technical and procedural
support areas, and
• IT governance teams
• Project sponsors/owners,
• Internal Enterprise Project
Management Office (EPMO)
resources, and
• any and all resources assigned to
a project to complete various
tasks.

Assumptions
and Constraints
The XP effort is a work stream within
larger, inflight internal projects.

This XP Knowledge Guide is intended to serve as an initial baseline for
the purposes of moving the larger, more detailed project and program
efforts forward in the spirit of incremental, iterative progress.

This guide represents a summary of the
core activities for an XP based
development project.

Based on the scope of a given
project, additional activities
and/or detail may be required.
The success of a project is
dependent on the professional
expertise of its resources.

Non-Compliance
Risks
In 2006, the National
Association of Insurance
Commissioners (NAIC) adopted
revisions to the Model Audit
Rule (MAR), the purpose of
which is to improve the state
insurance departments’
surveillance of the financial
condition of insurers.

Any individual or stand-alone non-public
company, including insurance companies,
captive insurance companies, nonprofit insurers
or health plans, filing an annual statement with
their domiciliary state regulator is affected.
The processes described in this documentation
series are critical to this state of compliance.
31

Failure to comply with XP development
processes may put at risk the company’s NAIC
MAR compliance, which could ultimately result
in a loss of business and/or financial penalties.
Copyright 2017 SOEd

Benefits to
the Customer

Benefits to the Customer:
Who is the Customer?
There are several customers of information technology XP
development methodology throughout the payor organization.

Benefits to the Customer: Who is the Customer?
Sample Organizational Flow
StepOne
First, the outputs of the
XP effort, namely
applications and
services in the form of
products, provide direct
benefit for both the
payor organization’s
Lines of Business
(Group, Government
and Retail) as well as the
primary customers of
the payor (Employers,
Members, Producers
and Providers).
StepTwo
Secondly, Project Teams,
including Project
Managers, and IT and
Business Owners, are
customers of the
process as their final
product benefits from
the efforts developed
through the use of XP.
StepThree
Finally, several other
processes across the
organization will
consume the outputs of
this process, including
but not limited to,
Change Management,
Release Management,
Project Portfolio
Management, and IT
and the payor
organization’s senior
leadership teams.

Benefits to the Customer:
What is the Value to the
Customer?
XP provides value to Project Teams within the
payor organization by providing a repeatable
development framework in which smaller, yet
high-priority and/or high-visibility development
activities can be produced quickly in response to
market pressures or business demands.
36

Adherence to this process
should produce:

Adherence to this process should produce:
• a higher quality final product, thereby
reducing risks to production and protecting
availability and reliability
38

• a very high speed-to-market,
allowing the payor
organization’s business lines the
flexibility necessary to quickly
respond to customer requests
and other market pressures

• an ability to rapidly respond to, and apply,
changes to requirements and priorities
40

How to Engage the Process

The XP process is engaged when a product
requiring the XP methodology has been
identified as within scope for a program/project
during the Intake & Demand Management
Process and/or confirmed during development
of a Project Planning Package or PPP (a
compilation of all components required for a
successful initiative).

All products and associated requirements that
can be validated by the project planning
process are then engaged along with
identified Stakeholders.
43

Copyright 2017 SOEd
XP Process Overview
44

The SIPOC (Suppliers, Inputs, Process,
Outputs, Customers) diagram depicts the
overall XP process from the highest level.

Further details for the XP process
will be found within the RACI,
Process swim lanes, and associated
narratives in the sections following
the SIPOC.
46

A RACI Matrix describes the
responsibilities associated with
the activities reflected within
the XP Swim lane diagram.
A stakeholder may have one of
four roles for each activity within
a RACI:

Swimlane Process
Diagram and Detail

As shown previously, the swim lane process diagram reflects a more
detailed-level view of the XP development lifecycle than the SIPOC.

The following documented
activities represent iterative
activities involving continuous
integration and delivery into the
Acceptance environment.
These steps are highly fluid,
occur rapidly, and may not
necessarily follow the precise
order indicated below.
50

The following section details the granularity of each XP swim lane
activity as shown in the previous diagram:

XP Swim Lane Activity One:
• Via Inception and Technical Discovery, create User Stories/Epics
(& Wireframes if applicable)
XP Swim Lane
Activity
• The project Inception meeting is held, followed by the Technical
Discovery effort. User epics/stories are developed. If necessary,
wireframes may also be produced to supplement the story.
Description
• User Stories
• Epics
Approximate
Activity Output

XP Swim Lane Activity Two:
• Assess, Prioritize & Estimate User Stories (Iteration
Planning Meeting)
XP Swim Lane
Activity
• The Project Team determines the complexity of user
stories (equating to high level estimates) and prioritizes
and sequences the backlog.
Description
• Prioritized Backlog
Approximate
Activity Output

XP Swim Lane Activity Three:
1
XP Swim Lane Activity
•Validate candidate architectural &
identify risks/challenges
2
Description
•The Application Architect validates
the candidate architectural
diagram based on the user stories
and finalized high level estimates.
3
Approximate Activity Output
•Candidate Architecture;
•Solution Architecture;
•Logical Design

XP Swimlane Activity Four:
XP Swimlane Activity
•Select & Elaborate User Story (and
refine Logical Design as needed)
1
Description
•Product Owner will work with the
Developer to select, clarify and
refine the user stories. The logical
design will be refined as needed.
This step roughly represents the
beginning of XP’s iterative
development and integration
activities.
2
•Logical Design
3

XP Swimlane Activity Five:
• Self-provision Development (DEV) environments (if
necessary)
XP Swimlane
Activity
• Product Owner and/or the Developer utilize self-
provisioning capabilities to prepare environments for
development.
Description
• Provisioned Environment(s)
Approximate
Activity Output

XP Swimlane Activity Six:
XP Swimlane
Activity
• Create Developer
Oriented Test Cases
Description
• Development related
test cases & scripts are
created.
Approximate
Activity Output
• Developer Oriented
Test Cases

XP Swimlane Activity Seven:
XP Swimlane
Activity
• Source Test Data
Description
• Data relevant to testing
is populated as
necessary.
Approximate
Activity Output
• Test Data

XP Swimlane Activity Eight:
• Refine solution
architecture & logical
design (and candidate
architecture as needed)
Description
• As necessary, the
Application Architect will
refine the candidate
architectural diagram
based on the elaborated
user stories. Additionally,
Application Architect will
provide low level design
guidance to the
developer.
Approximate Activity
Output
• Candidate Architecture;
• Solution Architecture;
• Logical Design

XP Swimlane Activity Nine:
• Create Failing Unit Test Case
XP Swimlane
Activity
• Via continuous integration, Developer will utilize test driven
development to first create a failing unit test case for the
story being coded.
Description
• Unit Test Case
Approximate
Activity Output

XP Swimlane Activity Ten:
• Code (Pairing)
Description
• Via continuous
integration,
Developer will pair
with another
developer for more
rapid, high quality,
development.
Output
• Code;
• Refactored Code

XP Swimlane Activity Eleven:
• Unit Test
XP Swimlane
Activity
• Via continuous integration, Developer will ensure that the
code passes the unit test in order for the continuous
integration loop to be successful.
Description
• Unit Test Results
Approximate
Activity Output

XP Swimlane Activity Twelve:
• Execute SIT, regression, and
other tests (as required)
Description
• Via an automated tooling
solution, the developer
executes SIT (if required) to
test the integrity of the
overall system as well as
with the larger ecosystem, if
applicable. QA/Testing to be
engaged for independent,
specialized forms of testing
(e.g. load and performance,
security, etc.)
• SIT Results;
• Regression Test Results;
• Other Test Results

XP Swimlane Activity Thirteen:
• Promote Build to
Acceptance
Environment
Description
• The tested,
integrated build is
promoted to the
acceptance
environment where
it is ‘available’ for
user acceptance
testing.
Output
• UAT Ready Build

XP Swimlane Activity Fourteen:
• Execute UAT (as required)
Description
• If it is determined that a
given build reflects a need
for user acceptance, UAT
(User Acceptance Testing) is
executed to validate that
the delivered code meets
desired functionality. The
Product Owner will
continuously deliver user
stories to the developer
until the release is ready to
be deployed.
• UAT Results;
• UAT Approval

XP Swim Lane Activity Fifteen:
• Validate Requirements and Approve Release?
XP Swim Lane
Activity
• After sufficient buildup of user stories, Product
Owner will decide when to deploy a release.Description
• Decision to release
Approximate
Activity Output

XP Swim Lane Activity Sixteen:
• Promote Build to
Staging
Environment
Description
• The user approved
build is promoted to
the staging
environment where
it is positioned for
deployment to the
production
environment.
Output
• Production Ready
Build

XP Swim Lane Activity Seventeen:
• Document Release &
present for internal
Change Advisory
team approval
Description
• Proper
documentation for
the release is
completed and
presented to the
Change Advisory
team for deployment
approval.
Output
• Change Order;
• Implementation Plan;
• Approved Release

XP Swim Lane Activity Eighteen:
XP Swim Lane
Activity
• Auto-Deploy to
Production
Description
• In conjunction with
the developer, the
relevant
deployment tool
auto-deploys the
release into
production.
Output
• Deployed Product

Process Narrative

The initial development of
high level requirements,
business needs and/or epics
for an XP effort will occur
within the Intake & Demand
and Requirements & Design
sub processes.

Once populated into the project, these initial
needs/epics are broken down into user stories
by the Product Owner, usually in conjunction
with the IT Project Manager, the Development
team and other project-level stakeholders
during the project inception meeting.

XP user stories are small, are being continually
written on a regular basis, and each story
includes clearly defined acceptance criteria
indicating how the Product Owner will
ultimately accept or reject the story within user
acceptance testing (UAT).

Process Narrative:
Iteration Planning Meeting
In optimal environments, once a week, the XP
project team should hold their internal Iteration
Planning Meeting, or ‘IPM.’

Typically within iteration
planning meetings, the business
owner will introduce new
stories into the backlog, and the
team as a whole will discuss,
assess, prioritize and refine
existing stories.

One common outcome of the
IPM is to break down a user
story seen as being ‘too large’
into several smaller stories.

The meeting also allows the
team to assign a complexity
rating to each story:
1, 2 or 3. 1 represents the
lowest complexity, while some
highly complex stories rated a 3
may potentially need to be
further broken into smaller
stories.

The meeting also allows the
team to assign a complexity
rating to each story: 1, 2 or 3. 1
represents the lowest
complexity, while some highly
complex stories rated a 3 may
potentially need to be further
broken into smaller stories.
The longest effort a story
should require is roughly 6-7
hours of development at the
absolute maximum.

XP does not focus on estimated
hours for stories, however the
complexity ratings themselves are
utilized by the Agile tracking
software to determine project
estimations.
79

If it is determined that a written
story cannot be worked on for a
given reason (usually a
dependency of some sort), the
story is not placed in the backlog,
but in a holding area referred to
as the ‘icebox.’
Only stories which may be
worked on are placed within the
backlog.

The IPM, therefore, continues
to re-populate the backlog and
refine stories on an ongoing
basis.

Process Narrative:
Test Driven
Development
XP is a ‘test driven development’
methodology.

As with other Agile methodologies, XP utilizes user stories
and story acceptance criteria; however within XP, the
developer is highly focused on writing test scripts prior to
beginning development.
83

All testing from unit to system to
integration is automated and a given
user story may have in the
approximate range of 6-10 related
automated test cases.
84

The only manual testing that occurs is User
Acceptance Testing, referred to as ‘verification’,
which is performed by the Product Owner later
in the lifecycle.

Process Narrative:
Pair Programming
Another unique aspect of XP is
pair programming.
86

In pair programming, two
developers sit down at one
computer and write code
together.

At any given moment, the team consists of a
navigator and an observer.
One developer is coding, while the partner is
providing peer review.
This collaboration also allows the team to more
easily overcome hurdles if one developer might
become stuck.
88

Developers on an XP project
team switch roles and self-
select partners on a regular
basis.
The combination of two XP
philosophies, pair programming
along with the regular daily
assignment of new user stories,
assures that broad technical
and functional knowledge exists
across the team.

Process Narrative:
Beginning
Development
Once a project backlog is
populated and the team is
ready to begin development,
the XP development process
becomes highly fluid and
unfolds rapidly.
Steps may not occur in this
precise order, but the general
approach to the development
of a story will resemble the
following:

Process Narrative: Beginning Development
Copyright 2017 SOEd
Pair programming
is utilized to code
& review the story.
When ready, the
Developers will
merge their story
into the build.
Step Four:
The Developer
scripts the
automated
unit/SIT/regression
test cases based
upon the
acceptance criteria
found within the
user story.
Similarly, the User
Acceptance Test is
developed by the
Product Owner.
Step Three
The necessary
development and
testing
environments are
auto-provisioned.
Step Two
The development
& build phase of
the XP cycle
‘begins’ as the
Development pair
selects a prioritized
user story from the
backlog for
development.
Step One
91

• The development & build phase of
the XP cycle ‘begins’ as the
Development pair selects a
prioritized user story from the
backlog for development.
92

• The necessary development
and testing environments are
auto-provisioned.

• The Developer scripts the automated unit/SIT/regression test
cases based upon the acceptance criteria found within the user
story. Similarly, the User Acceptance Test is developed by the
Product Owner.

• Pair programming is utilized to
code & review the story.

• When ready, the Developers will merge
their story into the build.

Process
Narrative:
Develop and
Build Phase
The development & build phase of the XP cycle
‘begins’ as the Development pair selects a prioritized
user story from the backlog for development.

• The necessary development
and testing environments are
auto-provisioned.

• The Developer scripts the
automated unit/ SIT/
regression test cases based
upon the acceptance criteria
found within the user story.
• Similarly, the User
Acceptance Test is developed
by the Product Owner.

• Pair programming is utilized
to code & review the story.

• When ready, the Developers
will merge their story into the
build.

Once the Continuous
Integration (CI) tool recognizes
that the developer is requesting
to merge new code into the
build, it will automatically
execute all regression testing.

Only if 100% of tests have
passed (a ‘green build’, as in a
green test status) is the code
merge permitted with the
Source repository.
In most environments, this
merge is also automatically
coordinated by the CI tool.

Now having the latest code merged
into the source, and all integration
testing complete, the source code has
effectively changed its version, which
XP refers to as a ‘version bump.’
A bump resides within the Staging
environment, which equates to being
‘one click away’ from Production.
104

It does not always make sense for
the business, represented by the
Product Owner, to verify each and
every build-ready merge.
105

Some merges may be focused on
addressing technical debt or other
similar IT specific efforts.

The project team works together to
decide that a given build version will
reflect the addition of functionality
to the point where it ‘makes sense’
to perform user verification.
107

Process Narrative:
User Acceptance
Testing
When ready for UAT, the
Continuous Integration tool will
generate a verification-ready
build out of the necessary
artifacts and deploy it to
Staging, one step below
Production.

The Product Owner then manually
verifies the build, executing ‘User
Acceptance.’ UAT is the only manual
testing that occurs within XP.
109

Within UAT, the business owner
utilizes the build release notes
and related user stories to mark
each story as either accepted or
rejected (each user story also
includes specific acceptance
criteria attached to the story).

Therefore, UAT is ‘accepted’ only via
testing and accepting all individual
related user stories.

Should a business owner reject a
given story, and therefore the
proposed build, the Staging
environment housing that build is
automatically destroyed via the
environment management tool.

The rejected story, along with
rationale and other notes, are sent
back to the developer to be
worked on again, to ideally again
be integrated within a future.

Once verification is complete and the build is
formally approved, the project team documents
the release, obtains any other production related
approvals, and the build is auto-deployed into
production via the XP toolset.
114

Post-implementation verification (PIV) activities are
performed and results are added to the Change
Order as part of the Change Management Process.
115

Reporting

In an effort to automate as many
aspects of lifecycle management
as possible, a fundamental aspect
of XP is its tight integration with
supporting toolsets.
117

The ability to extract and
generate value-added
information from these toolsets
goes hand in hand with this
philosophy.
As this industry effort matures,
and internal payor
organization’s toolsets are
formally implemented,
reporting within the XP lifecycle
will be defined.

Administrative

Administrative:
Management
Review
As an NAIC MAR compliant
process, the XP process ownership
is required to review XP processes
on a regular (usually annual) basis.

Administrative:
Training
Due to limited resources and other
priorities in most organizations, XP
training is usually limited to on-the-
job training in support of XP pilot
projects.

Administrative:
Monitoring and
Control
As a process that supports NAIC
MAR compliance, management
monitoring of the process is
critical.
Under most circumstances, the
XP Process Owner is tasked with
the monitoring of the process for
adherence to IT and payor
organization policies and
processes.

As changes to XP processes are
implemented, the company’s internal
XP Process Team should contact the
internal IT department’s business
process management team for
updates to this processes used by
both teams.
This can be done on an as needed
basis, at the discretion of the XP
Process Team.

In most organizations - if there is
no update request from the XP
Process Team - the Process Team
will send one annual refresh
notification (12 months from the
last review date) to the process
owners with a due date prior to
the refresh deadline.

To ensure accuracy, this process will require
document review by the Process Owner and Subject
Matter Experts and will incorporate any changes
identified as a result.
Any formatting changes that may be adopted by the
IT Process Central team will also be incorporated at
that time.
125

Future State Project Management Lifecycle (PMLC)
SIPOC

Supporting Toolsets

XP processes are designed to be agnostic in the
context of supporting toolsets and should
remain largely unchanged even if the underlying
tools do change.
Along this vein, the following popular XP toolsets
may evolve in the context of greater IT design
and delivery effort and related enterprise
direction.
*Please note: This is not an exclusive list of all
available tools. Additionally, they do not exist in
all organizations.

Supporting
Toolsets
Tool: Cloud Foundry
Development: Pivotal Software
Purpose: Cloud Computing Platform;
Environment Management &
Provisioning

Supporting Toolsets
Tool: GitHub
Development: GitHub
Purpose: Source Management & Revision Control

Supporting
Toolsets
Tool: Jasmine
Development: GitHub
Purpose: Test Automation
131

Supporting Toolsets
Tool: Jenkins CI
Development: Open Source
Purpose: Continuation Integration and Test Automation
132

Supporting
Toolsets
Tool: Pivotal Tracker
Development: Pivotal Software
Purpose: Agile & Project
Management; Estimation; User
Stories & Requirements
Tracking; User Acceptance

Solution Delivery Method
Control Objective Language

The controls identified on the
XP Process SIPOC and the PMLC
represent the current SMD
control set as they pertain to
any iterative information
technology operating model
processes.
The following section is a
summary of the objective
language for each control for
reference.

Control Type One:
Maintain the enablers of the management system and
control environment for enterprise IT, and ensure that they
are integrated and aligned with the enterprise's governance
and management philosophy and operating style.

These enablers include the clear
communication of expectations
and requirements.
The management system should
encourage cross-divisional co-
operation and teamwork,
promote compliance and
continuous improvement, and
handle process deviations
(including failure).
137

Control Type Two
Identify and maintain
requirements, standards,
procedures and practices for
key processes to guide the
enterprise in meeting the intent
of the agreed-on Quality
Management System.

This should be in line with the IT control framework
requirements.
Consider certification for key processes, organizational units,
products or services.

Control Type Three
Assess, plan and execute the continual
improvement of processes and their maturity
to ensure that they are capable of delivering
against enterprise, governance, management
and control objectives.

Consider COBIT process implementation guidance, emerging
standards, compliance requirements, automation
opportunities, and the feedback of process users, the
process team and other stakeholders.
Update the process and consider impacts on process
enablers.
141

Control Type Four
(Pre-Planning
Certification)
Manage stakeholder
engagement to ensure an active
exchange of accurate,
consistent and timely
information that reaches all
relevant stakeholders.
This includes planning,
identifying and engaging
stakeholders and managing
their expectations.

Control Type Five:
Project Plan
Define and document the nature and
scope of the project to confirm and
develop amongst stakeholders a
common understanding of project
scope and how it relates to other
projects within the overall IT-enabled
investment program.
The definition should be formally
approved by the program and project
sponsors.

Establish and maintain a formal,
approved integrated project plan
(covering business and IT
resources) to guide project
execution and control throughout
the life of the project.
The scope of projects should be
clearly defined and tied to building
or enhancing business capability.

Control Type Six:
Coordinate
Feedback
Co-ordinate feedback from affected
stakeholders and, at predetermined
key stages, obtain business sponsor
or product owner approval and sign-
off on functional and technical
requirements, feasibility studies, risk
analyses and recommended
solutions.
145

Control Type
Seven Develop
and Document
Develop and document high-level
designs using agreed-on and
appropriate phased or rapid agile
development techniques.
Ensure alignment with the IT
strategy and enterprise architecture.
Reassess and update the designs
when significant issues occur during
detailed design or building phases or
as the solution evolves.
Ensure that stakeholders actively
participate in the design and
approve each version.
146

Control Type Eight:
Establish a test plan based on enterprise-wide
standards that define roles, responsibilities, and
entry and exit criteria.
Ensure that the plan is approved by relevant parties.
147

Control Type Nine:
Required Testing
Test changes independently in
accordance with the defined test
plan prior to migration to the live
operational environment.

Control Type Ten:
Optimal Testing

Control Type Eleven:
Conduct a post-implementation review to confirm outcome
and results, identify lessons learned, and develop an action
plan.
Evaluate and check the actual performance and outcomes of
the new or changed service against the predicted
performance and outcomes (i.e., the service expected by the
user or customer).

Control Type Twelve
Define and establish a secure test
environment representative of the planned
business process and IT operations
environment, performance and capacity,
security, internal controls, operational
practices, data quality and privacy
requirements, and workloads.

Control Type
Thirteen
152

Control Type
Fourteen
Promote the accepted solution to
the business and operations.
Where appropriate, run the solution
as a pilot implementation or in
parallel with the old solution for a
defined period and compare
behavior and results.
If significant problems occur, revert
back to the original environment
based on the fallback/backout plan.
Manage releases of solution
components.

www.salusoneed.com

An Introduction to Extreme Programming (XP) Development Methodology Process in Healthcare: Managing Critical Projects, Delivering Rapid Results in Healthcare Payer and Provider Environments

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to An Introduction to Extreme Programming (XP) Development Methodology Process in Healthcare: Managing Critical Projects, Delivering Rapid Results in Healthcare Payer and Provider Environments

Similar to An Introduction to Extreme Programming (XP) Development Methodology Process in Healthcare: Managing Critical Projects, Delivering Rapid Results in Healthcare Payer and Provider Environments (20)

Recently uploaded

Recently uploaded (20)

An Introduction to Extreme Programming (XP) Development Methodology Process in Healthcare: Managing Critical Projects, Delivering Rapid Results in Healthcare Payer and Provider Environments