-
Director
-
Virtualization and Software DevelopmentOpportunities to improve
outcomes
Jack AlexanderCA Technologies
2015
-
The lifecycle of an application project
4
Whether traditional development SDLC such as waterfall or
Agile
is adopted, the fundamental components of a project do not
change.
-
The lifecycle of an application project
5
Requirements & Analysis
Design
Development
Integration & Test
Deployment
Maintenance & Operations
These core phases are common to all
SDLC models, although they may
have slightly different names.
Each has numerous components, and
some bleeding between the
phases.
Within these lurk factors that
normally pose huge risk to project
schedule and budget, and application
quality.
-
The lifecycle of an application project
6
Requirements & Analysis
Design
Development
Integration & Test
Deployment
Maintenance & Operations
These core phases are common to all
SDLC models, although they may
have slightly different names.
Each has numerous components, and
some bleeding between the
phases.
Several phases where opportunities
exist for maximum benefit to the
project with low risk:
Low risk / High reward
-
Opportunity to improve: Testing
7
Requirements & Analysis
Design
Development
Integration & Test
Deployment
Maintenance & Operations
TestingTesting is done throughout an applications lifecycle:
Test definition (how we will test) By developers as they test
the
modules they are building Unit test Integration test System test
UAT Performance test Regression test
-
Opportunity to improve : Testing
8
Requirements & Analysis
Design
Development
Integration & Test
Deployment
Maintenance & Operations
Testing challengesTesting is not a sexy issue. Its boring, and
it doesnt get the respect it deserves.
Reality: Inadequate or poor testing is the root of most problems
when trying to roll out a new application or a changes to existing
applications in M&O.
-
Opportunity to improve : Testing
9
Requirements & Analysis
Design
Development
Integration & Test
Deployment
Maintenance & Operations
Testing challenges Enough environments to satisfy the
demands of the project Enough test data scenarios to do
robust
testing Coordination of all required interfaces
and data can make end-to-end testing virtually impossible
Cost of environments and associated licenses means that theres
usually never enough
Waiting for databases to be reset, waiting for external systems
to be available, waiting for a component to be completed before
testing can begin
-
10
Testing can be difficult & very costly:
Systems under test need to interface to other systems,
so our ability to test can be dependent on many things
Challenges
System A needs to talk to system B. System B is not available
until tomorrow. Testing of System A must wait until tomorrow.
10
Developers will create artificial versions of the interfaces to
test against duringdevelopment these are simple versions that dont
really mimic reality
-
11
Testing can be difficult & very costly:
Often many separate testing environments are needed
Challenges
11
Test environments are expensive: hardware, and a complete set of
software toreplicate a complete system: database, applications,
etc.
-
Challenges
12 Project readiness 12
Testing can be difficult & very costly:
Making sure that tests are of high quality (test coverage)
12
Tests need to reflect the real world: test for every possible
scenario, with testdata that is robust and realistic.
Test data gets burned once its used, it needs to be reset.
Multiple teams testing at the same time can stomp on other peoples
test data scenarios.
Test data can be very sensitive to time. Sometimes a test case
for an infant mustalways be an infant. A five-year-old test
scenario yields a five-year-old child. A teenagers test scenario
turns into an adult test scenario. Dates are critical!
-
Challenges
13 Project readiness
Testing can be difficult & very costly:
Insuring realistic test scenarios are used, and that we do
not test with production data
13
Ideally, test scenarios will look like production, with
high-quality realisticdata, but with de-sensitized versions, data
that has been thoroughly cleansed.
-
Challenges
14 Project readiness 14
System A needs to talk to system B. System B is not available
until tomorrow. Testing of System A must wait until tomorrow.
A large percentage of developers time is spent waiting to
test.
Testing delays are a major contributor to overall project
delays.
Testing can be difficult & very costly:
Often, developers must wait for the ability to test
-
15 Project readiness 15
Testing can be difficult & very costly:
Risk of too many defects making it into production
15
Schedule pressure and constraints on the ability to test can
result insystems that have not been adequately tested making it
into production.
15
Poor system performance. Crashes
Incorrect resultsUnhappy users
-
16
DHCS and Service Virtualization
Reduce Risk, Increase the Pace of Innovation and
Reduce Cost with Service Virtualization
Presented by Chris Cruz
Chief Information Officer
Deputy Director, Enterprise Innovation Technology Services
Division
-
17
About DHCS
The largest Health and Human Services Department in the
US outside of the Federal government
Overseeing the development of the largest MMIS program in
the United States, CAMMIS
Developed Enterprise Architecture
Developed Strategic Plan, outlining key capabilities, goals,
and objectives.
-
DHCS Vision
18
One of the key elements of DHCS strategic plan is:
Identify, test and incorporate radical innovations to
enhance
DHCS delivery
Service Virtualization is just the type of innovation needed
to
dramatically improve DHCS ability to deliver its development
projects, and those of its programs and partners.
-
Challenges
19
Improve/increase capacity for work DHCS maintains a key data hub
(MEDS) that most,
if not all health-related programs in California rely upon
DHCS is responsible to provide access to test environments to
core DHCS systems to many different partners: CA-MMIS CalWIN, C-IV,
LEADER Health Exchange (Covered California & CalHEERS) Internal
applications / groups.
-
Application SDLC Challenges
20
Must keep existing system up-to-date while replacement system is
being developed
Many interfaces and complexities Both existing and new system
uses the same
backend system Large number of development and test
environments to support both existing and new systems is
needed
-
CAMMIS Challenges
21
Tight schedule avoid penalties and change orders
Critical system system quality is paramount, as these are core
systems to the State and the agency.
High profile. No room for error.
-
DHCS
Goals for Service Virtualization
22
Reduce Infrastructure Cost Less mainframe LPARs
Less physical servers
Control Labor Cost Maintain Infrastructure
Manage, replicate and refresh test data
Minimize Contention for Resources Reduce likelihood of CAMMIS
modernization effort
interfere with the maintenance effort needed to keep the
existing CAMMIS current
-
DHCS
Goals for Service Virtualization
23
Remove Development Constraints
Shorten test data creation time from weeks to days/hours
Remove legacy constraints - Allow CAMMIS development to begin
while the DHCS modernize and SOA-enable the backend
Improve Test Scenario Development
No longer rely only on existing test data
Create and build new test data to support enhanced testing
processes
-
DHCS
Goals for Service Virtualization
24
Improve Quality of Existing and New Systems Allow testing
earlier in the system development
process Allow more frequent regression testing Allow mini-UAT to
minimize last minute surprises
Increase Project Success Reduce project risks Reduce potentials
of penalties and change orders Meet project schedule Deliver a
stable and quality system that meets
expectation
-
DHCS
Goals for Service Virtualization
25
Revolutionize how DHCS builds new applications and maintains
existing applications
Become a model for the State on how to do IT legacy system
modernization & testing
Enable broader collaboration / support to build key citizen
services. Create a virtual catalog of shared services to test
against throughout DHCS: (e.g. MEDS-in-a-box, Covered
California-in-a-box, etc)
-
Director
