Software Development LifeCycle

Process (SDLC)
AI-Enhanced — Version 2.0
Verifone
Date: 09 April 2026
Author: Gaurav Sehrawat
Revision History
Date Version Description Author
Miguel
03/05/2019 1.0 First Draft version Ferreyra,
Rafael Cuenca
05/08/2019 1.0 Comment and review Dimitri Binazzi
28/01/2021 1.01 Comment and review Dimitri Binazzi
05/02/2021 1.02 Comment and review Dimitri Binazzi
Comments and review. Chapter 3.9 added with list of
31/01/2022 1.04 related documentation to improve the security of the Dimitri Binazzi
code
24/10/2023 1.05 Comments and review Saifan Pasha
21/11/2025 1.06 Clean up of document & formatting, added Security N Cloke
Standards
AI-Enhanced SDLC integration — AI tooling across Gaurav
09/04/2026 2.0 all phases, PCI guardrails, tool comparison matrix, Sehrawat
adoption roadmap. Organisation-wide policy.

Definitions
Term Definition
Release Particular version of a configuration item that is made available for a specific
purpose (for example, test release)
SDLC Software Development LifeCycle
Validation Confirmation, through the provision of objective evidence, that the requirements for
a specific intended use or application have been fulfilled.
Verification Confirmation, through the provision of objective evidence, that specified
requirements have been fulfilled.

Contents
Part I — Core SDLC Process
1. Introduction
2. Processes
 2.1 Software Requirements and Design
2.2 Software Development Process
2.3 Software Integration and Release Process
2.4 Software Testing Process
2.5 Operation and Maintenance
3. Project Standards
3.1 – 3.8 (SRS, SDD, Traceability, Release Notes, Install Guide, Test Plan, Related Docs)
Part II — AI-Enhanced SDLC
4. Executive Summary
5. AI Integration by Phase
5.1 Requirements & Planning
5.2 Design & Specification
5.3 Implementation (Coding)
5.4 Code Review & Quality
5.5 Testing
5.6 CI/CD & Deployment
5.7 Monitoring & Maintenance
6. Guardrails & Governance
7. Tool Comparison Matrix
8. Adoption Roadmap
9. Appendices
 Part I — Core SDLC Process

1. Introduction
The purpose of this document is to describe the Software Development Life Cycle Process. The
life of a software product can be modelled by a life cycle model consisting of stages. Models
may be used to represent the entire life from concept to disposal or to represent the portion of
the life corresponding to the current project. The life cycle model is a sequence of stages that
may overlap and/or iterate, as appropriate for the project scope, magnitude, complexity,
changing needs and opportunities. Each stage is described with a statement of purpose and
outcomes.
The life cycle processes and activities are selected in a stage to fulfil the purpose and
outcomes of that stage.
The core SDLC consists of five interconnected processes: Software Requirement & Design
Process, Software Development Process, Software Testing Process, Software Integration &
Release Process, and Software Operation & Maintenance Process.
Process Management and Project Management are involved in the evolution and delivery of
the product. During the various phases of the development lifecycle, various teams are involved
to ensure that the software is designed and coded, the product is tested and deployed to the
several environments.
Part II (Sections 4–8) extends this foundation with AI-driven development tooling, guardrails,
and an adoption roadmap.

2. Processes
Conception
During the conception phase the business case for the project and the scope of the project are
established. This phase begins when either internal VeriFone Customers or a VeriFone Client
specifies or confirms the need for a new product or feature or for modifications to an existing
product or feature.
2.1 Software Requirements and Design
Overview: Establish and maintain an architectural design and detailed design solution for the
requirements of the customer and other stakeholders. When user requirements are understood
from the start of a project, client satisfaction with the resulting software will be much greater.
Process owner: Business Analysts
Purpose: Establish and maintain an architectural design and detailed design solution for the
requirements of the customer and other stakeholders.
Process Inputs Process Outcomes
Product requirements in JAMA – User Software Requirements Specification in JIRA – Story
Stories with sub-tasks
Acquirer Solution Specification Software Design Document, SDD
Architectural design / Test data Architectural design / Interface specifications / Detailed
design*
Activities
Activity Records
1. Analyze requirements — ensure quality criteria including Product requirements in JAMA.
unambiguity, completeness, traceability, security, Software Requirements in JIRA.
feasibility, verifiability SDD.
2. Baseline requirements — record approvals, baseline, Product requirements Baseline
place under change control approved in JAMA
3. Develop design structure — evaluate alternatives for Architectural design, SDD
architecture, security, structure
4. Develop interface specifications Interface specifications, SDD
5. Allocate requirements to design elements and interfaces Traceability Matrix in JAMA
6. Validate design with Product Owner Design validation issues / approval
7. Establish component specification* Detailed design, SDD
8. Establish and maintain design description Software Design Document, SDD
Resources: Documentation repository, JAMA, JIRA, Confluence, Database scheme, Standard
test data
Responsibilities: Product Owner (design validation), Software Architect (architecture,
interfaces, process), Technical Leader (component specification, design description)
Related documentation: SRS in Jira, SRS review template, Traceability Matrix in Jama, SDD in
Confluence
Measurement: Defects — Total number of defects injected in the process. *When necessary
2.2 Software Development Process
Overview: The implementation phase is when the product or feature is developed, tested and
deployed. The emphasis is on resource management and managing scope, costs and
schedules while maintaining quality.
Process owner: Technical Leader
Purpose: Produce a specified product component.
Process Inputs Process Outcomes
Software requirements specification in Jira Software component in Development
environment
Software Design Document, SDD in SQL Scripts / SDD / Installation Guides*
Confluence*
Activities
Activity Records
1. Establish the implementation strategy — methods, standards, tools, Implementation
constraints strategy
2. Implement product components — understand assignation, create Software component
branch, implement, request review, analyze review feedback (Dev env)
3. Elaborate SQL Scripts* — change script + rollback script SQL Scripts
4. Approve SQL Scripts* — evaluate DB impact SQL Scripts approval
5. Develop documentation* Software Design
Document
6. Continuous code review — automatic daily review Code review record
7. Unit test of product component Unit testing records
Resources: Check Style, Code review tools (Bitbucket, Sonar), Software repository (Git)
Responsibilities: Development Manager (strategy, SQL approval, continuous review),
Developer (implement, test, document)
Related documentation: OWASP, SANS CWE Top 25, ISO 27001:2022 Annex A Control 8.25,
PCI DSS V4.01 – Requirement 6
Measurement: Issues (total), Defect Density (defects/KLOC). *When necessary
Coding
Development is carried out iteratively in sprints. Coding follows Secure Coding guidelines
(OWASP-based, SonarQube enforced, Security team reviewed), Standard Coding conventions
(Sonar inspected), and Check-style for Java standards compliance.
All developers undergo secure coding training on joining and receive annual refresher training.
Continuous Code Review
Regular code reviews are performed using Bitbucket pull requests. The reviewer is decided by
the Development Manager, most often a fellow developer familiar with the work.
Unit Test of Product Component
Unit tests verify that each programmed module will function properly when inserted into the
system.
2.3 Software Integration and Release Process
Overview: Focused on making the software available to end users. Includes releases,
production releases, bug fix and enhancement releases.
Process owner: Technical Leader
Purpose: Integrate product components and deploy to QA and Certification environments.
Process Inputs Process Outcomes
Software component in Dev environment / Software product / Install & config guide /
SQL Scripts / SDD / Installation Guides Release notes / SQL Scripts / Security Reports
Activities
Activity Records
1. Establish integration strategy Integration strategy
2. Obtain integration resources Resources available
3. Review and coordinate interface definitions* Integration strategy
4. Assemble product components (Jenkins, release Software product, SQL Scripts,
notes, tagging, SQL, install guide) Release notes, Install guide
5. Deploy integrated product in QA Environment Software product (QA env)
6. Confirm integrated product operation (Sonar, login, Security Reports
version, rollback, CAB request*)
7. Record integration information* (CAB, pen test, Integration Issues
issues)
8. Deploy product in Certification Environment Release notes
Integration Strategy
Continuous integration — code pushes to GIT trigger builds and automated tests. SCM is GIT
with standardized branching and versioning conventions. All changes tracked via Jira.
Branching Model — Gitflow Workflow
Two main branches: master (production code) and develop (integration branch). Feature
branches off develop, hotfix branches off master, release hardening branches off develop.
Deployments
Environments: Development Testing (QA), Customer Testing (CST), Pre-Production (PPE),
Production (PROD), Certification (CERT). Production deployments require CAB Meeting
approval registered in Release Notes.
2.4 Software Testing Process
Overview: Testing is carried out after each development cycle, allowing defects to be found
earlier and reducing fix costs.
Process owner: Test Leader
Purpose: Provide confidence that products satisfy specified requirements and operational
needs.
Process Inputs Process Outcomes
Software Product / Test data / Test cases / Security Reports Issues/Bugs / Final test report
Activities
Activity Records
1. Develop testing strategy Test Plan - Approach
2. Develop testing procedures (test cases, data sets) Testing procedures
3. Establish and maintain QA environment QA environment
4. Test incremental work products Test records, Issues/Bugs
5. Verify End-Products against requirements Verification records, Issues/Bugs
6. Validate End-Products in representative environments Validation records, Issues/Bugs
7. Analyze evaluation results —
8. Report results Final test report
Resources: Automatic test tools, Test cases (Jama), Bug tracking (Jira), CI (Jenkins)
Responsibilities: Test Leader (strategy, procedures, analysis, reporting), Tester (testing,
verification, validation), VCS (QA environment)
Sprint Activities: Before Sprint (QA reviews, test case prep) → During Sprint (execution) →
Completion (bug fix verification, QA signoff, test reports)
2.5 Operation and Maintenance
Software and applications must be monitored constantly to ensure proper operation. Defects
and bugs discovered in production must be reported and resolved/remediated. This job must be
integrated in the SDLC process.
3. Project Standards
3.1 Identification Requirements
Every document must include: Date of issue and status, Company name and Project name,
Authorship, and Change/Revision history.
3.2 Software Requirements Specification (SRS)
The SRS precisely describes what the system will do. Based on user needs, it sets the stage for
design and system testing. Reference: IEEE Standard 830:1998. Chapters cover Introduction,
References, Glossary, Software Product Overview (purpose, functions, users, environment,
risks), Specific Requirements (external interfaces, functional requirements, non-functional
requirements, design constraints, logical DB requirements).
3.3 Software Design Document (SDD)
Outlines implementation satisfying the SRS. Covers division into components,
communications/APIs/dependencies, classes/attributes/operations, data representation,
component behavior, and internal APIs. Reference: IEEE Standard 1016:2009. Three Confluence
templates: Basic, Limited, Complete.
3.4 Traceability Matrix
Matrix mapping Requirements (rows) to Components (columns).
3.5 Release Notes
Introduction (product name, code, version, DB version, date), Resolved Issues, Known Issues
(optional), Deployment Instructions (optional), Related Documentation (optional).
3.6 Installation and Configuration Guide
Introduction, References, Glossary, System Requirements, Configuration process (optional),
Appendices.
3.7 Test Plan
Introduction, References, Glossary, Test Scope (items, features to test/not test), Test Approach,
Pass/Fail Criteria, Suspension/Resumption, Deliverables, Tasks, Environmental Needs,
Responsibilities, Staffing, Schedule, Risks, Appendices. Reference: IEEE 829-2008.
3.8 Related Documentation
Secure coding guideline (.NET, Angular, [Link], v1.0) and SDLC security assurance Policy Rev
1.07.
 Part II — AI-Enhanced SDLC

4. Executive Summary
4.1 Vision
AI-driven development tools represent a fundamental shift in how software is built, reviewed,
and maintained. This section defines how AI tools integrate into every phase of the SDLC —
from requirements gathering through production deployment — while maintaining quality
standards and PCI DSS compliance that a payment processing environment demands.
The goal is not to replace human judgment but to amplify it. AI pair-programming, automated
code review, spec-driven test generation, and intelligent planning accelerate delivery velocity
while raising the quality floor for every commit.

AI-enhanced SDLC — tool integration points

1. Requirements & planning 2. Design & specification
Claude Code (plan), Copilot Chat Spec-driven workflow, API contracts

3. Implementation (coding) 4. Code review & quality

Claude Code, Copilot, Cursor PCI auditor, security scanner
pool kcabdeeF

5. Testing 6. CI/CD & deployment

TDD agents, E2E, spec-driven tests Jenkins, Helm, K8s manifests

7. Monitoring & maintenance

Log analysis, auto-docs, deps

PCI DSS guardrails & governance

Human review gates: payment logic, crypto, auth, settlement

Human-in-the-loop checkpoints AI agent automation layer

Phases 1–7 form a continuous cycle. AI tools accelerate each phase while
PCI guardrails enforce mandatory human review at critical decision points.
Figure 1: AI-Enhanced SDLC Lifecycle — all 7 phases with tool integration points
4.2 Expected Impact
Metric Current Baseline Expected with AI Measurement
Sprint velocity Baseline +25–40% increase Story points per
sprint
Code review ~4–8 hours <1 hour (AI pre-review) PR open to first
turnaround review
Test coverage Variable >80% line coverage SonarQube reports
target
Time-to-production Sprint + release Reduced by ~30% Jira lead time
cycle
Defect density Baseline ~20–30% reduction SonarQube + Jira
defects/KLOC

4.3 Risk Summary — What AI Must NOT Do

In a payment processing system, AI tools must never: generate, store, or log raw cardholder
data (PAN, CVV, expiry); hardcode secrets, API keys, or credentials; bypass human review for
payment logic, cryptographic operations, authentication, or settlement; make autonomous
decisions about encryption schemes or key management; access production environments,
secrets vaults, or live cardholder data; generate code that writes unvalidated input to logs or
databases.
5. AI Integration by Phase
5.1 Phase 1: Requirements & Planning
Enhances: Section 2.1 — Software Requirements and Design
AI-Assisted Story Creation: LLMs draft Jira stories from business requirements documents,
producing structured output including summary, description, acceptance criteria, and
estimated complexity.
Codebase Exploration: AI agents explore the repository to understand which files, services,
and configurations a change will touch, producing dependency graphs and identifying
downstream impacts.
Architecture Planning: AI generates dependency graphs, deployment sequence
recommendations, and risk assessments.
Tools: Claude Code (plan mode), Copilot Chat
Human Checkpoints: Product Owner validates AI-drafted stories. Technical Lead reviews
dependency analysis. All AI-generated stories reviewed before sprint commitment.
5.2 Phase 2: Design & Specification
Enhances: Section 2.1 — Design activities

Spec-driven development workflow

Jira story [Link] [Link] [Link] Code
Requirements AI drafts spec AI gen fixtures AI gen tests Implementation

TDD cycle (AI-assisted)

RED GREEN REFACTOR
AI writes failing tests AI writes impl to pass AI improves code

Iterate until all specs pass

Human developer reviews and owns all output at every stage

Figure 2: Spec-driven workflow pipeline and TDD cycle

Spec-Driven Development Workflow: [Link] → [Link] → [Link] → Implementation. This

sequence ensures design decisions are captured as executable specifications before
implementation begins.
API Contract Generation: AI generates OpenAPI/Swagger specifications from natural-
language endpoint descriptions.
Backward Compatibility Analysis: AI traces code paths from changed interfaces to all
consumers, identifying breaking changes.
Tools: Claude Code (/specs-driven, /plan), Architecture diagrams
Human Checkpoints: Software Architect validates design. Product Owner approves against
requirements. Breaking changes require explicit sign-off.
5.3 Phase 3: Implementation (Coding)
Enhances: Section 2.2 — Software Development Process
AI Pair Programming: Developers work alongside AI for code generation, refactoring, and
completion. AI understands project context through [Link] configuration files, coding
standards, and the existing codebase.
Test-Driven Development (RED → GREEN → REFACTOR): AI writes tests first from specs,
then generates implementation to satisfy those tests, then suggests improvements while
maintaining passing tests.

Multi-agent AI development workflow

Developer assigns task
Parallel agents
Explorer agent Impl agent Review agent
Scans codebase Writes code from spec Checks conventions

AI code review
PCI audit + security scan + coverage

Human review gate

Mandatory for payment, crypto, auth
AI pre-screens every change; humans make the final call on sensitive code

Figure 3: Multi-agent workflow — parallel agents converge through AI review to human gate

Multi-Agent Workflows: Explorer agent (scans codebase for patterns/dependencies),

Implementation agent (writes code from spec), Review agent (checks conventions and
security). Agents work in parallel and converge through AI code review before reaching
mandatory human review gates.
PCI Guardrails for AI-Generated Code
Prohibited Pattern Why Detection
Hardcoded secrets or API keys PCI DSS Req 2.2.7, 6.2.2 SonarQube secret
scanning
Raw PAN/CVV in log statements PCI DSS Req 3.3, 3.4 Custom lint rules + AI
review
Unvalidated input in SQL/NoSQL OWASP Injection SAST scanning
queries (A03:2021)
Disabled SSL/TLS verification PCI DSS Req 4.2.1 Code review + scanner
Unencrypted cardholder data at rest PCI DSS Req 3.5 Architecture review
Direct database access bypassing Data access control Code review
ORM
Tools
Tool Usage Strengths
Claude Code Full implementation, TDD, multi-agent Deep context, plan mode, agentic
GitHub Copilot Inline completion, quick suggestions IDE-native, fast autocomplete
Cursor AI-first IDE experience Visual diff, multi-file editing
Coding Standards (Unchanged): All existing secure coding guidelines from Section 2.2
remain in force for AI-generated code. SonarQube analysis is mandatory.
5.4 Phase 4: Code Review & Quality
Enhances: Continuous Code Review in Section 2.2
Automated PR Review: AI reviews every PR for coding conventions, security anti-patterns
(OWASP Top 10), test coverage gaps, documentation completeness, and backward
compatibility.
PCI DSS Compliance Scanning: Dedicated AI agents scan for cardholder data exposure,
insecure crypto, missing input validation, and hardcoded credentials.
Test Coverage Analysis: AI identifies untested endpoints and code paths, generating test
stubs for missing coverage.
 Tool Command Purpose
Claude Code CodeReviewer agent Automated PR review
Claude Code /pci-auditor PCI DSS compliance checks
Claude Code /security-scanner OWASP Top 10 scanning
Claude Code /test-coverage-analyzer Coverage gap identification
SonarQube Continuous analysis Code quality metrics
Bitbucket Pull request reviews Peer review workflow
Mandatory Human Review Gates
Category Reviewer Rationale
Payment processing logic Technical Lead + Security Financial accuracy and
Manager compliance
Cryptographic operations Security Manager Key management and algorithm
selection
Authentication/authorization Technical
Manager
Lead + Security Access control integrity
Settlement calculations Technical Lead + Product Financial reconciliation accuracy
Owner
Database schema changes DBA + Technical Lead Data integrity and migration
safety
Infrastructure/K8s changes DevOps Lead Deployment stability
Regression Risk — AI Reviewing AI: When the same model writes and reviews code, use
different AI tools for generation vs. review, ensure human reviewers are always final approver,
rotate reviewers, and track defect detection rates.
5.5 Phase 5: Testing
Enhances: Section 2.4 — Software Testing Process
AI-Generated Unit Tests: Backend (Mocha/Chai) and Frontend (Jest/Karma) suites generated
from specs. Covers happy paths, edge cases, error conditions, and boundary values.
Integration Test Generation: Tests generated from API contracts verifying end-to-end flows
across service boundaries.
E2E Test Workflows: AI-assisted Playwright test generation from user story acceptance
criteria.
Regression Testing Intelligence: AI analyzes code changes to target the most relevant
existing tests.
 Tool Command Test Type
Claude Code FrontendTestWriter agent Jest/Karma frontend tests
Claude Code /tdd Test-driven backend tests
Claude Code /e2e Playwright E2E tests
Copilot Test generation Inline test suggestions
Jenkins CI pipeline Automated test execution
Metric Target Tool
Unit test coverage >80% line coverage SonarQube
Integration test coverage All API endpoints covered Custom report
E2E test coverage All critical user flows Playwright report
Test generation time <30 min per story Jira tracking

5.6 Phase 6: CI/CD & Deployment

Enhances: Section 2.3 — Software Integration and Release Process
Pipeline Configuration: AI generates Jenkinsfile stages, Helm chart values, and K8s manifests
with environment-specific parameterization.
Deployment Runbook Generation: AI creates step-by-step deployment sequences including
pre-deployment checks, DB migrations with rollback, service deployment order, health checks,
and rollback procedures.
Build Error Resolution: AI agents analyze build logs, identify root cause, and suggest or
implement fixes.
Tools: Claude Code (build-error-resolver agent), Jenkins, Helm, Git (Gitflow)
Environment Progression (Unchanged): QA → CST → PPE → PROD → CERT. Production
deployments require CAB approval.
5.7 Phase 7: Monitoring & Maintenance
Enhances: Section 2.5 — Operation and Maintenance
AI-Assisted Debugging: Log analysis, error correlation across services, root cause tracing
through codebase.
Documentation Generation: Auto-updated codemaps, API docs, architectural diagrams,
runbooks.
Dependency Management: Outdated package detection, CVE tracking, license compliance,
breaking change warnings.
Knowledge Retention: AI memory systems preserve context across sessions — decisions,
rationale, debugging insights.
6. Guardrails & Governance
PCI guardrails and mandatory human review gates
PCI DSS compliance boundary
AI permitted activities AI prohibited activities
Code generation from specs Access production secrets
Test generation (unit, integration, E2E) Handle cardholder data (PAN/CVV)
Code review for conventions Generate crypto implementations
Dependency analysis Log sensitive data
Documentation generation Bypass human review gates
Build error diagnosis Access production environment

Mandatory human review gates

Payment logic Cryptography Auth / access Settlement
TechLead + SecMgr Security Manager TechLead + SecMgr Lead + PO

DB migrations Infrastructure
DBA + Technical Lead DevOps Lead
No AI-generated code in these categories may be merged without human sign-off

Figure 4: PCI guardrails — permitted vs. prohibited AI activities and human review gates

6.1 PCI DSS Compliance

Rule Detail
No cardholder data in AI Never paste PAN, CVV, expiry, or track data into AI tools
prompts
No production data in AI AI tools operate on development/test data only
context
No AI-generated crypto Cryptographic code must use approved libraries and be
human-reviewed
No AI access to production API keys, HSM credentials, vault tokens never exposed to AI
secrets
Logging restrictions AI must not generate code that logs cardholder data, even
masked
6.2 Code Ownership
All AI-generated code is owned by the developer who committed it. The developer reviews
every line, understands the logic, ensures compliance with standards, and accepts
accountability for defects.
6.3 Secret Handling
Environment AI Access Rationale
Development (local) Permitted with synthetic No real credentials or cardholder data
data
QA/Staging No direct access May contain realistic test data
Production Strictly prohibited Contains real cardholder data and
credentials
Secrets vaults (Vault, AWS Never AI must never interact with secret
SM) stores

6.4 Data Residency

Tool Provider Data Processing Data Retention
Location
Claude Code Anthropic US (AWS) Not used for training (business
plan)
GitHub GitHub/Microsoft US (Azure) Not used for training (business
Copilot plan)
Cursor Cursor Inc. US Configurable per plan
All tools must be on business/enterprise plans with DPAs in place. Legal review of ToS required
before deployment.
7. Tool Comparison Matrix
7.1 Capability Comparison
Capability Claude Code GitHub Copilot Cursor
Inline code completion Via terminal Excellent (IDE- Excellent
native)
Multi-file editing Strong (agentic) Limited Strong
Codebase-wide Excellent (full repo) Good (open files + Good
context index) (indexing)
Plan/architecture Excellent (/plan) Limited Moderate
mode
Test generation Excellent (TDD workflow) Good Good
Code review Excellent (agents) Limited Moderate
Custom Excellent ([Link], skills, Limited Moderate
commands/skills hooks) (rules)
Terminal/CLI Native Requires IDE IDE-based
integration
Multi-agent Yes (parallel agents) No Limited
orchestration
PCI-specific tooling Custom (/pci-auditor, No No
/security-scanner)

7.2 Recommended Use Cases

Use Case Recommended Tool Why
Sprint planning & story creation Claude Code Plan mode, codebase exploration
Day-to-day coding (inline) GitHub Copilot Fastest autocomplete, IDE-native
Complex multi-file changes Claude Code Full repo context, agentic workflows
Quick prototyping Cursor Visual diffs, fast iteration
Code review Claude Code Custom agents, security scanning
Test generation Claude Code TDD workflow, spec-driven
CI/CD debugging Claude Code Build-error-resolver agent
Documentation Claude Code Codemap generation, API docs
7.3 Cost Analysis
Tool Plan Cost/Developer/Month Notes
Claude Code Max ~$100 Includes API usage, no training
(Business) on data
GitHub Copilot Business ~$19 IP indemnity, no training on data
Cursor Business ~$40 Configurable privacy settings
Total per ~$159
developer
Costs are approximate and subject to change. Verify current pricing before budgeting.
8. Adoption Roadmap
AI adoption roadmap — phased rollout
Now Sprint N+1 Next quarter

Phase 1: Individual Phase 2: Team-wide Phase 3: CI/CD

Install AI tools per developer Spec-driven workflow Automated AI PR review
Shared [Link] config AI pre-review on all PRs Pipeline test generation
AI story creation pilot Test coverage reporting Build-error auto-resolver
AI pair programming trial PCI guardrail validation Metrics dashboard

Each dev uses AI for 1+ story All PRs get AI pre-review Measurable velocity gains
Success criteria per phase — each phase gates the next
PCI guardrails and human review gates enforced at every phase

Figure 5: Three-phase adoption roadmap with gated success criteria

Phase 1: Individual Developer Adoption (Now)

Activity Timeline Owner
Install and configure Claude Code for all developers Week 1 DevOps Lead
Establish shared [Link] with project Week 1 Technical Lead
conventions
Use Claude Code for sprint planning and story Sprint N Product Owner + Technical
creation Lead
Developers use AI pair programming for Sprint N Individual developers
implementation
Pilot AI code review on 2–3 PRs per sprint Sprint N Technical Lead
Success Criteria: Each developer has used AI tools for at least one story. Team captures
lessons learned.
Phase 2: Team-Wide Workflows (Next Sprint)
Activity Timeline Owner
Deploy shared [Link], custom skills, and hooks to all Week 1 Technical Lead
repos
Implement spec-driven workflow ([Link] → fixture → spec → Sprint All developers
impl) N+1
AI-assisted code review on all PRs Sprint Technical Lead
N+1
AI-generated test coverage reports per PR Sprint QA Lead
N+1
Establish PCI guardrail validation in AI workflow Sprint Security
N+1 Manager
Success Criteria: All PRs receive AI pre-review. Test coverage increases measurably. No PCI
guardrail violations.
Phase 3: CI/CD Integration (Next Quarter)
Activity Timeline Owner
Automated AI PR review in CI pipeline (Jenkins) Month 1 DevOps Lead
AI-generated test stubs for uncovered endpoints Month 1 QA Lead
Build-error-resolver agent integration with Jenkins Month 2 DevOps Lead
AI-generated deployment runbooks per release Month 2 Technical Lead
Automated PCI compliance scanning in PR pipeline Month 3 Security Manager
Metrics dashboard: AI impact on velocity, quality, coverage Month 3 Technical Lead
Success Criteria: AI quality checks run automatically on every PR. Build failures diagnosed by
AI. Measurable improvements in velocity and defect density.
9. Appendices
Appendix A: Guardrails Checklist for Payment System AI Usage
Before Using AI Tools:
☐ No production data, credentials, or cardholder data in the AI context
☐ Working with synthetic/test data only

☐ AI tool is on an approved business plan with DPA in place

During AI-Assisted Development:

☐ AI-generated code does not hardcode secrets or API keys
☐ AI-generated code does not log cardholder data (even masked)

☐ AI-generated code validates all user input

☐ AI-generated code uses approved cryptographic libraries (not custom)

☐ AI-generated code follows existing secure coding guidelines

Before Committing AI-Generated Code:

☐ Developer has reviewed and understands every line
☐ SonarQube analysis passes with no critical or high issues

☐ If payment logic: human review by Technical Lead + Security Manager scheduled

☐ If crypto/auth: human review by Security Manager scheduled

☐ If database changes: DBA review scheduled

☐ Test coverage meets or exceeds team standards

Before Deployment:
☐ AI-generated deployment runbook reviewed by DevOps Lead
☐ Rollback procedures verified and documented

☐ CAB approval obtained (for production deployments)

Appendix B: Glossary
Term Definition
BRD Business Requirements Document
CAB Change Advisory Board
CVV Card Verification Value
DPA Data Processing Agreement
E2E End-to-End (testing)
HSM Hardware Security Module
LLM Large Language Model
OWASP Open Worldwide Application Security Project
PAN Primary Account Number (card number)
PCI DSS Payment Card Industry Data Security Standard
SAST Static Application Security Testing
SDD Software Design Document
SDLC Software Development LifeCycle
SRS Software Requirement Specification
TDD Test-Driven Development
Testware All artifacts created during testing (tools, automated tests, docs)
Validation Confirmation that requirements for a specific intended use have been fulfilled
Verification Confirmation that specified requirements have been fulfilled

This document is a living reference. It will be updated as AI tools evolve, team workflows mature, and new
compliance requirements emerge.