IT Services
SDLC, Peer and Gate Review Approach
September 2011
Agenda
• Review three supported Methodologies Project Life Cycle Software Development Life Cycle Scrum
• Review Peer and Gate Review Approaches within methodologies
• Q&A
Product Life Cycle (PLC)
Project Life Cycle (PLC)
• Non-development life cycle Straight Forward Internal projects
Upgrades Installs Conversions
• Shared artifacts Where appropriate
Project Life Cycle (PLC)
Software Development Life Cycle (SDLC)
The GAI SDLC:•Phases provide incremental, or staged, delivery of functionality.•Iterations provide the progressive development and rework of functionality.•Provides repeatable/predictable scheduling, development, and testing processes.•Emphasizes the continual delivery of business value at predictable intervals.•Shows consistent progress while being better able to respond to changes.
The SDLC – What Is It?
The SDLC is a hybrid of the Rational Unified Process (RUP) and Agile development methodologies.
There are four distinct phases:–Inception–Elaboration–Construction–Transition
“A Phased Approach”
ProposeDefine and
Approve the Project
Prototype Capabilities & Prove-Out the Architecture
Develop the Solution Move the Solution into Production
Incremental Development
• The progressive development of features and functionality via the delivery of smaller pieces that are valuable to the customer
• Encourages progressive integration (not “big bang” integration)
• Each Phase can have 1 or more releases
• Each release can add functionality
Phase
Release
Iteration
Things of Value
Roles Within Iteration• Business Partner• Program Manager• PMO• Project Manager • Business Analyst• Architect• Development Lead• Data Modeler• Web Services• Tester
SDLC Releases
What comprises a Release?“… A stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions”
(Rational Unified Process Glossary)
GAI ITS Releases:•A release is a completed set of functionality with artifacts (business and internal).•Each Phase may deliver one or more “releases.”•A release progresses through each of the environments.•Releases begin with “1” and increment by “1” as necessary.•A release can be “major” (increment by 1) or “minor” (increment by .1).•Shows consistent progress while being better able to respond to changes.
Putting It Together - Iterative DevelopmentInceptionInception
• PM begins Project Charter• PM coordinates meeting with
Resource Managers (RM)• RM understands objectives and
assign resources• Lead PM and PMO coordinate
project plan linking sessions with all PMs
• BA begins Reqs for iteration 1
• PM begins Project Charter• PM coordinates meeting with
Resource Managers (RM)• RM understands objectives and
assign resources• Lead PM and PMO coordinate
project plan linking sessions with all PMs
• BA begins Reqs for iteration 1
• PM conducts Kick-off meeting with resources and business partner
• PM coordinates JAD sessions• Architect creates high level
design with Data Modeler• Test Lead creates test plan• PMO and PM plan gate and peer
reviews for project
• Iteration 1 begins
• PM conducts Kick-off meeting with resources and business partner
• PM coordinates JAD sessions• Architect creates high level
design with Data Modeler• Test Lead creates test plan• PMO and PM plan gate and peer
reviews for project
• Iteration 1 begins
RequestRequest
PlanningPlanning
Kick-offKick-off
• Business Partner makes requests for product development
• Program Manager evaluates request and assigns Lead Project Manger (PM)
• PM begins to gather information on request
• PMO, Program & Project Manager agree on governance approach
• Business Partner makes requests for product development
• Program Manager evaluates request and assigns Lead Project Manger (PM)
• PM begins to gather information on request
• PMO, Program & Project Manager agree on governance approach
Putting It Together - Iterative DevelopmentIteration 1Iteration 1
• BAs document Iteration 2 Reqs. • Testers begin creating test cases
for Iteration 1 Reqs.• Architects, Developers, and Data
Modelers may begin Preliminary Design for Iteration 1
• BAs validate functionality developed in Iteration 1
• BAs document Iteration 2 Reqs. • Testers begin creating test cases
for Iteration 1 Reqs.• Architects, Developers, and Data
Modelers may begin Preliminary Design for Iteration 1
• BAs validate functionality developed in Iteration 1
Iteration 2Iteration 2
• Developers and Data Modelers perform detail design for Iteration 1 Reqs.
• Developers code for Iteration 1 Reqs. Start 2
• BAs document system and data requirements to be developed in Iteration 3
• BAs validate functionality developed in Iteration 2
• Testers finalize test cases for functionality developed in Iteration 1 and start 2
• Developers and Data Modelers perform detail design for Iteration 1 Reqs.
• Developers code for Iteration 1 Reqs. Start 2
• BAs document system and data requirements to be developed in Iteration 3
• BAs validate functionality developed in Iteration 2
• Testers finalize test cases for functionality developed in Iteration 1 and start 2
Iteration 3Iteration 3
• Developers and Data Modelers perform detail design for Iteration 2 Reqs.
• BAs document system and data requirements to be developed in Iteration 4
• BAs validate functionality developed in Iteration 3
• Testers test functionality developed in Iteration 2
• Testers finalize test cases for functionality developed in Iteration 3
• UAT for functionality developed in Iteration 1 and 2
• Developers and Data Modelers perform detail design for Iteration 2 Reqs.
• BAs document system and data requirements to be developed in Iteration 4
• BAs validate functionality developed in Iteration 3
• Testers test functionality developed in Iteration 2
• Testers finalize test cases for functionality developed in Iteration 3
• UAT for functionality developed in Iteration 1 and 2
Month 1Month 1
Month 2Month 2
Month 3Month 3
Elaboration Phase – Iteration Tasks
Artifacts Developed During This Phase
• Project Plan• Project Status Report• Change Requests
Project
• Architectural Spec.• Architectural Review
Checklist• Design Review Docs• Code Review Docs• High-Level Design Docs• Detailed Design Docs
Arch., Design, Develop.
• Product Hierarchy• Coverage Matrix• Non-Functional Specs• User Dialogs• Business Rules• Data• Dictionary/Glossary• Data Mapping• GUI Screens• GUI Data Tables• Data Transformation
Requirements
• Conceptual Data Model• Logical Data Model• Physical Data Model• CXML Model• DDL /DML Scripts
Data
• Test Plan• Test Cases• Test Scripts
Testing
Elaboration Phase – Artifact Flow
SDLC - Elaboration Phase – Artifact Flow
PM
BA
Requirements
Te
ster
Dat
a
Mod
eler
De
velo
per
Le
ad
Arc
hite
ct
BA
Planning Requirements Analysis Design Build Test
PM Arch DevLead DM Tester
Project WBS
Owner
Project Audit
Checklist
Architectural Specification
Architectural Review
Checklist
System Requirements – Next Iteration
User Dialogs
GUIsBusiness
Rules
Non -Functional
Reqs.
Data Requirements – Next Iteration
Data Mapping & Transform
Data Dictionary
Coverage Matrix
PHM
High Level
Design
Data Models
Test PlanTest
Cases
Detail Design
Data Models
Test Scripts
Ch
an
ge
Req
ue
sts
DDL , DML Scripts
Code
Transition Phase – Iteration Tasks
•UAT Testing•Acceptance Criteria met
Artifacts Developed During This Phase
• Update Project Plan• Project Status Report• Change Requests• Transition Checklist• Project Close-Out Report
Project
• Update Arch. Docs• Update Design Docs• Design Review Docs• Code Review Docs
Arch., Design, Develop.
• Update Requirements
Requirements
• Update Data Models
Data
• Update Test Plans• Update Test Scripts
Testing
• Communication Plan for Delivery
• Training Materials
User Preparation
Fully tested and major defects corrected
Scrum
The Scrum Process
• Implementing Scrum Outside Consultants Time Frames Successful Teams
Peer Reviews
Formal Reviews
True Peer Review – New authors and/or high risk material (audience = peers)
Technical Review – Authors with solid material (audience = peers and internal consumers)
Combined Peer and Technical Review – Experienced authors with low risk material (audience = peers, internal consumers, and business partners)
Informal Reviews
• Code reviews, logical/physical data models, deployment plans, customer care hand-off plans, test plans, and ETL Specification reviews Audience – a peer or team mate Value add - formal meetings are not required, team/person
reviewing will record metrics and share with PMO Timing – as needed; efficient and flexible The goal is to have a knowledgeable second set of eyes
reviewing the work prior to development
Industry Standards for Proving the Value
Production
Certification Test
COST TO COST TO REPAIR 1 REPAIR 1 DEFECTDEFECT
Unit Test Unit Test
Code
$1000
$7000
$14000
Integration Test
$2500
Integration Test
$2500System
Test$4500
SystemTest
$4500
Planning AnalysisSystem Design
$140
Planning AnalysisSystem Design
$140
Proving the Value
• Dashboards Time Tracking Unit Code Coverage UAT Defects Peer Review results
• Health check Compliance with methodology
Q&A
• What’s on your mind?
Recommended