CUNA Mutual Group’s CUNA Mutual Group’s Quality Assurance ProcessQuality Assurance Process

In the context of Solution In the context of Solution DeliveryDelivery

What is Solution What is Solution Delivery?Delivery?

The process of delivering a new technology solution

or delivering new functionality in an existing

technology solution

Solution Delivery Solution Delivery ExamplesExamples

Building a new business systemBuilding a new business system Adding to an existing business systemAdding to an existing business system Purchasing a business systemPurchasing a business system Creating a Lotus Notes databaseCreating a Lotus Notes database Adding a new storage system to our serversAdding a new storage system to our servers Upgrading our word processing toolUpgrading our word processing tool Bringing in a new development toolBringing in a new development tool Operating system maintenance cyclesOperating system maintenance cycles Upgrading network topologyUpgrading network topology Making a configuration changeMaking a configuration change

Working Customerw/ Scheduled Operation

Plan

Iden

tifie

d P

lan

to

Res

olve

Nee

d

New Application or

Technology Tools

SystemDiagnostics

Operate

ProductionReady

Solution

Co

nsu

lt

(People or Process)

Inte

rpre

t

Implement& Stabilize

ProductionAcceptance

Reactive orProactive

Need

EstablishedSchedule

Non-technical solution

Fixes

Existing Component

Logg

ed a

nd R

oute

d R

eque

stStrategicPlanning

Running Solution

SelectedTechnology

SolutionTestedSolution

DevelopFeasibility& Planning

Co

nce

ptu

aliz

e

DefinedHigh Level

Drivers

Gate Gate

CUNA Mutual’sIT Process Workflow

Business Case(Scope)

Checkpoint

RequirementsCheckpoint

Design ComponentIntegration Test

ConstructCheckpoints

Environment Integration

Test

AcceptanceTest

ImplementationTest

BenefitsRealizationAssessment

= Verify

= Validate

Test PhasesSpecification Phases

Component (Unit)Test

Checkpoint

CUNA Mutual’sQA V-Model

Conceptualization

Feasibility/Planning

Develop

Implement/Stabilize

Operate Are we doing the right job?

Are we doing the job right?

Quality Assurance CheckpointsQuality Assurance Checkpoints

Verification/ValidationVerification/Validation Test Planning on left (Review)Test Planning on left (Review) Test Execution on right (Testing)Test Execution on right (Testing) Dual Development pathsDual Development paths CommunicationCommunication Roles definedRoles defined Business Involved ThroughoutBusiness Involved Throughout No SurprisesNo Surprises

Before it gets physical...Before it gets physical...

Quality PlanQuality Plan

The Quality Plan describes the specific deliverables that are inspected at each checkpoint on the V-Model. In addition to detailing the validation and verification objectives on each deliverable, the plan lists the roles that are involved and the contribution each role makes.

The Quality Plan is documented in the Wizard in the IT Process Workflow Book.

Quality Plan ExpectationsQuality Plan Expectations

Deliverables should be stable when entering a checkpointDeliverables should be stable when entering a checkpoint Informal reviews can be held throughout development to Informal reviews can be held throughout development to

enhance the quality with formal review looking for defectsenhance the quality with formal review looking for defects Standards vs. GuidelinesStandards vs. Guidelines Suggestions will be incorporated or addressed with appropriate Suggestions will be incorporated or addressed with appropriate

authority (See the Quality Plan for each deliverable)authority (See the Quality Plan for each deliverable) Defects need to be fixed at the point of origin and cycle back Defects need to be fixed at the point of origin and cycle back

through the processthrough the process Changes need to be reflected to previously reviewed Changes need to be reflected to previously reviewed

deliverables - may require follow up reviewsdeliverables - may require follow up reviews The project plan needs to be evaluated at every checkpointThe project plan needs to be evaluated at every checkpoint Test results will be approved by someone other than the testerTest results will be approved by someone other than the tester

Test Planning makes Test Planning makes testing a non-eventtesting a non-event

Business Case(Scope)

Checkpoint

RequirementsCheckpoint

Design ComponentIntegration Test

ConstructCheckpoints

Environment Integration

Test

AcceptanceTest

ImplementationTest

BenefitsRealizationAssessment

= Verify

= ValidateComponent

(Unit)Test

Checkpoint

QA V-Model

Conceptualization

Feasibility/Planning

Develop

Implement/Stabilize

Operate Are we doing the right job?

Are we doing the job right?

Traditional development example

Business Case(Scope)

Checkpoint

RequirementsCheckpoint

Design ComponentIntegration Test

ConstructCheckpoints

Environment Integration

Test

AcceptanceTest

ImplementationTest

BenefitsRealizationAssessment

= Verify

= ValidateComponent

(Unit)Test

Checkpoint

QA V-Model - Purchased View:

Purchaser is responsible for tasks ‘above’ the line.

Conceptualization

Feasibility/Planning

Develop

Implement/Stabilize

Operate Are we doing the right job?

Are we doing the job right?

Vendor Performs ‘below’ the line.

Business Case(Scope)

Checkpoint

RequirementsCheckpoint

Design ComponentIntegration Test

ConstructCheckpoints

Environment Integration

Test

AcceptanceTest

ImplementationTest

BenefitsRealizationAssessment

= Verify

= ValidateComponent

(Unit)Test

Checkpoint

QA V-Model

Conceptualization

Feasibility/Planning

Develop

Implement/Stabilize

Operate Are we doing the right job?

Are we doing the job right?

Infrastructure/Hardware example

Our Approach to ProcessOur Approach to Process

Learn the rules so you know how to break them Properly

Dalai Lama

Questions?Questions?