CMMi Awareness

Ver 1.0
Date : 01.12.12
Agenda

 Introduction to CMMi
 Level 2 Process Area
 Level 3 Process Area
What is CMMi
 Is a process model for improving organization
process
 Is a structured collection of practices that
describes characteristics of effective process
 Practices included are those proven by
experience to be effective
 Tells ‘what’ not ‘how’ . Provides a guide and
direction
 Product suit consists of model, training material
and appraisal method SCAMPI(Standard CMMi
Appraisal Method for Process Improvement)
History
Integrated Product
Software CMM V2 Systems Engg. CMM V.1. Development CMM

CMMi 1.1

CMMI for Acquisition CMMi for Development

CMMI for Services
V1.2 V1.2
V1.2

CMMi for Development CMMI for Services

CMMI for Acquisition V1.3 V1.3
V1.3
Structure of the CMMI

Maturity Levels

Process Area 1 Process Area 2 Process Area n

Specific Generic
Goals Goals

Specific Generic
Practices Practices
CMMI for Acquisition
V1.3
The Maturity Levels

Optimizing
5
Focus on process improvement

4
Quantitatively
Process measured and controlled Managed

3 Process characterized for the organization

Defined
and is proactive

2 Process characterized for projects Managed

and is often reactive

1 Initial
Process unpredictable,
poorly controlled, and
reactive
The Process Areas

Continuously improving Organizational Process Management

5 Optimizing Causal Analysis and Resolution
process
Organizational Process Performance
4 Quantitatively Quantitative Project Management
Predictable process and Managed
Quantitative Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Standard, consistent process 3 Defined Organizational Process Focus
Organizational Process Definition
achieving process Organizational Training
standardization Integrated Project Management for IPPD
Risk Management
Decision Analysis and Resolution

Requirements Management
Project Planning
Basic Project Management 2 Managed Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
1 Initial No Process Areas © 2004 KPMG
Technical Solution

SG 1 Select Product Component Solution

SP 1.1 Develop Alternative Solution and Selection Criteria
SP 1.2 Select Product Component Solution
SG 2 Develop the Design
SP 2.1 Design Product or Product Component
SP 2.2 Establish a Technical Package
SP 2.3 Design Interface Using Criteria
SP 2.4 Perform Make , Buy or Reuse Analysis
SG 1 Implement the Product Design
SP 1.1 Implement the Design
SP 1.2 Develop Product Support Component
Generic Practices
GG1 Achieve Specific Goals
GG 1.1 Perform Specific Practices
GG 2 Institutionalize a Managed Process
GG 2.1 Establish an Organizational Policy
GG 2.2 Plan the Process
GG 2.3 Provide Resources
GG 2.4 Assign Responsibility
GG 2.5 Train People
GG 2.6 Control Work Products
GG 2.7 Identify and Involve Relevant Stakeholders
GG 2.8 Monitor and Control the Process
GG 2.9 Objectively Evaluate Adherence
GG 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process
GG 3.1 Establish Defined Process
GG 3.2 Collect Process Related Experience
Level -1
 Adhoc or Chaotic
 Engineering vs. Creativity
 Success is people dependent
 Process “Out of Control”
 Cannot predict results
 Team tackles projects in different ways each time
 Can have strong successes, but may not repeat
 Some time/cost estimates are accurate, many far
off
Level -2
 Basic processes in place
 Processes are project oriented
 Project management, Configuration
Management, Quality Control and Requirements
management are in use
Level -3
 Organization wide process focus by now
 Organization Processes defined; however,
tailoring by projects is allowed
 Process data base very important
 Learning is captured and used in for future
projects
Level -4
 Quantitative measures being used extensively for
predicting and monitoring
 Process data base used for doing so.
 An engineered organization - that can accurately
predict what it will do
Level -5
 PARADIGM Shift
- Defect detection to defect prevention
- Why did the problem occur?
 Assess Processes to fine tune continuously
 Basis of process improvements is now factual
IT Services Scope: Projects >= 1500 Hours (FP Projects)
Phase Activiy Discription Deliverable/Output
Standard Alternative
Pre-Sales Get Request for Proposal / Work Request Document / Mail
Order
Effort Estimation By Technical Team
Prepare Proposal Proposal Email
Contract Get Signed Contract Signed proposal/Contract
Perform Contract Review Contract review document
Send Initiation Note for execution Project Initiation note, Related
Documents
Project Initiation Assign PM / TL for the Project Allocation Email to PM / TL
Send Request for creation Create Project repository with
SVN/VSS/TFS/CVS/GIT documents
Prepare for Internal-Kick off Internal Kick-off Meeting MoM Email
Do Kick-off with Internal
Stakeholders
Send Request for Resources Email request for Resource/ Discuss
in internal kick-off
Prepare for External Kick-off External Kick-off Meeting MoM
Do Kick-off with the Client
Project Planning Estimate effort for project / Verify Project effort estimation sheet / -
Estimation Revised Estimates
Contract Hours
Estimate for each enhancement
Prepare Project Schedule Project Schedule(MPP, Excel) Excel
Release Schedule
Start & End Date with Planning
Activity
Identify Project Risks Risk Register
Prepare Project Plan IPMP
Prepare CM Plan CMP
Review Project Plans Review Log
Approve Project Plans Approval of IPMP, CMP, Risk
Register
If Tailoring, approve IPMP from Approved IPMP
SEPG
Work Product Audit (Pan) Audited IPMP
Perform SQA Initiation Audit SQA Audit Report
IT Services Scope: Projects >= 1500 Hours
Phase
Project Monitoring & Control
Activiy Discription
Conduct Team Meetings
Send Status Report to client
Conduct Review with
Sr.Management
Log Issues
Update Risk Register
Prepare Time Sheet for Resources
Conduct Review at the end of
Milestone
Re-estimate effort at different
Phases as required
Update PHR
Perform Defect Analysis at
Milestone
Inform any change of Resources
Receive Approval for change in
resources from client
Prepare Revised Schedule / Plan ( if Rrvised Project Schedule(MPP,
Required) , review and approval
Project contract review as required Review Evidence
– in the middle of the project to
review changes to contract
(FP Projects)
Deliverable/Output
Standard Alternative
Projects MOMs ( with Client and Mail
Internal) (Progress Reviews)
Project Status Report client Mail
Project Review Reports (Sr.
Management Review) / MOMs
Jira/Excel
Risk Register (Updated)
Jira
Milestone Reviews Release Review
Revised Estimates Revised Estimates for
enhancements
Updated PHR
Defect Analysis Defect Analysis after Release
Defect Analyais of Inavlid Bugs
Periodic Defect Analysis
Inform change of resource
Approval on change of resources
Excel
Excel)
Revised Release Plan
Revised Project Schedule / Plan
Review and approved
Request for additional resources (If
any)
IT Services Scope: Projects >= 1500 Hours
Phase Activiy Discription
Requirements Gather Requirements
Prepare SRS
Conduct Internal Review of SRS
Get Sign-off from Client of SRS
Prepare Change Request
Prepare Imact Analysis Document
Update CR Log
Get Approval from Client for CR
Update Requirement Traceability
Matrix
Conduct Work Product Audit
Design Prepare Architecture Document
Conduct Internal Review of
Architecure Doc
Prepare Design Document
Conduct Internal Review of Design
Document
Prepare DAR related to Projects
Define Product Integration Plan
Conduct Work Product Audit
Update RTT
Deliverable/Output
Standard Alternative
Requirements gathering (Mails /
MOMs)
Requirement analysis & discussions
(MOMs) Analysis and Categorisation of
Tickets
Software Requirement Specification Requirements Understanding Doc.
Requirements Understanding in
Tickets
Requirements Review Log
Customer approval of SRS Requirements Understanding Doc.
Sign-off mail
CR Documents CR Tracker
Impact Analysis Document Impact Anayalys in Tracker
CR Log CR Log in Tracker
CR Approval (if it is from RSPL) CR Approval (if from RSPL) in
Tracker
RTT Creation & Updation
Work Product Audit
Architecture Document
Architecure Document Review Log
Design Documents Design understanding Doc.
How bugs needs to be fixed
Design Document Review Log
DAR
Product Integration Plan (Design Product Integration Plan Doc
Document)
Work Product Audit
Updated RTT
IT Services Scope: Projects >= 1500 Hours
Phase Activiy Discription Deliverable/Output
Standard Alternative
Development Coding Developed Code
Conduct Code Reviews Code Reviews Log
Prepare Unit Testing Unit Test Cases Unit Test Checklist
Perform Unit Testing Unit Test Results Unit Test Checklist
Update RTT Updated RTT
Testing Prepare Test Plan Test Plan
Conduct Review of Test Plan Test Plan Review
Prepare Test Cases (Functional, Test Case Preparation Test Case Checklist / Test Case in
Integration, System) Jira
Conduct Review of Test Cases Test Case Review Defects logged in Test Case Checklist Review Defects
Jira / Review Log logged Jira / Review Log
Test Execution (Functional, Bug Tracker(Jira) Tool specified by Customer
Integration, System)
Perform Non-Functional Testing (If Jira Tool specified by Customer
budgeted)
Defect Report Tracking/Bug Bugs logged in Jira Tool specified by Customer
Tracking
Update RTT Updated RTT
Work Product Audit (Test Cases) Work Product Audit Report
Build Build Management Update Configuration Plan
Release Prepare Release Note Release Note Release Mail
Prepare Test Summary Report Test Summary Report
Get QA Sign-off for each release QA - Sign Off
Work Product Audit (Release) Audit report
UAT Jira Bug Logs
Tool specified by Customer
Bug Verification by Client
Get UAT Sign-off from Client UAT Sign off Bug Closure by Client
Get Customer Feedback Customer feedback
Get Project Sign-off Project Sign-Off
Release Sign-off Release Sign-off
Yearly Lessons Learnt Lessons Learnt Document
Project Closure Conduct Project Closure Meeting Project Closure MOM
Lesson Learnt / Best Practices
Project Closure report
Release of Resources
Archive Project Artifacts Archives
Conduct Project Closure Audit Project closure Audit
Process Conduct Regular SQA Audits SQA Audits Reports
Project Initiation
Project Initiation (Audit Check Points)
Phase Activiy Discription
Pre-Sales Get Request for Proposal / Work
Order
Effort Estimation
Prepare Proposal
Contract Get Signed Contract
Perform Contract Review
Send Initiation Note for execution
Project Initiation Assign PM / TL for the Project
Send Request for creation
SVN/VSS/TFS/CVS/GIT
Prepare for Internal-Kick off
Do Kick-off with Internal
Stakeholders
Send Request for Resources
Prepare for External Kick-off
Do Kick-off with the Client
Deliverable/Output
Standard Alternative
Request Document / Mail
By Technical Team
Proposal Email
Signed proposal/Contract
Contract review document
Project Initiation note, Related
Documents
Allocation Email to PM / TL
Create Project repository with
documents
Internal Kick-off Meeting MoM Email
Email request for Resource/ Discuss
in internal kick-off
External Kick-off Meeting MoM

1. Check the date of the proposal ?

2. Check whether the proposal has been signed ?
3. Contract Review has been signed by All. Check the dates ?
4. Date of PI Note should be after the Contract Review Date?
5. Check the date of mail. Should be after PI Note.
6. Compare the dates with PI Note.
7. Check the contents of Internal Kick-off MOM. Check the name participants.
Person from SST,SQA Training should attend the meeting.
8 .External Kick off MOM and ppt Available ? Check the contents of the MOM
and ppt.
Project Planning and Monitoring
Project Planning

The purpose of Project Planning is to establish and maintain plans

that define project activities
Project Planning
 Develop a Work break down structure
 Estimate the effort based on defined methods ( FP, UCP, Task
based )
 Prepare Project Plan using template
• Identify Stakeholders
• Resource Plan
• Training Plan
• Metrics Plan
• Schedule
 Peer Review Project Plan
 Obtain approval of Project Plan from Head – Delivery.
Procedure Project Planning
Guidelines Estimation Guidelines, Tailoring Guidelines
Template IPMP, FP Estimation Template, UCP Estimation Template
Checklist Project Review checklist
Integrated Project Management

 Tailor the process if required . Obtain SEPG approval

 Integrate other plans that affect the project with the project
plan
 Establish work environment for project in terms of facilities,
tool, equipment and review periodically
 Defined Shared Vision ( for team) and team charter ( Project
Code of conduct, Team Communication)
 Propose improvements to the organizational process assets
 Document lessons learned from the project for inclusion in the
organization's process asset library
 Track the critical dependencies and commitments and take
corrective action as appropriate
Integrated Project Management

Procedure
Guidelines
Template Lessons Learnt and best practices
Checklist
Project Monitoring and Control

The purpose of Project Monitoring and Control is to provide an

understanding of the project’s progress so that appropriate
corrective actions can be taken when the project’s performance
deviates significantly from the plan
Project Monitoring and Control
Effort
Project
Plan
Cost
Status
Report
Schedule
Corrective
Action

Size

Risks Image courtesy KPMG

Project Monitoring and Control
 Regular Monitoring of project through Team Meetings. Review
should be done at least once a month.
 MOMs should be prepared. SST and Training representative
should attend meeting if required.
 Following parameters should be reviewed during meetings:
• Effort
• Schedule
• Risks
• Metrics
• Stakeholder Involvement
 Milestone Reviews at the end of each milestone.
 Issue Management in terms of logging, tracking and closing of
issues.
 Client Status Reporting
Project Monitoring and Control

Procedure Project Monitoring and Control

Guidelines PHR Guidelines
Template PHR Template, MOM , Weekly Status
Checklist
Measurement and Analysis

The purpose of Measurement and Analysis is to develop and

sustain a measurement capability that is used to support
management information needs
Measurement and Analysis

 Type of metrics : Process and product metrics , Base Metrics

and derived metrics
 Metrics are defined as organization level with goals
 Following metrics are defined :
• Size Variance ( 10%)
• Effort Variance (10%)
• Schedule Variance (5%)
• Defect Density (In-Process ) .5 / FP
• Defect Density (Post Release ) .05/FP
• Testing Effectiveness (60%)
 Metrics goals are defined at Projects level. Project track these
metrics against goals defined in IPMP
 Metrics are collated at organization level and analyzed.
Measurement and Analysis

Procedure Measurement and Analysis

Guidelines Metrics Analysis Guidelines
Template Metrics Analysis Report (CAPA), PHR
Checklist
Configuration Management

The purpose of Configuration Management is to establish and

maintain the integrity of work products using configuration
identification, configuration control, configuration status
accounting, and configuration audits
Configuration Management

 Configuration Management Plan is prepared

 CI (Configurable Items) are identified
 Configuration control board(CCB) if formed for approval of any
change request
 Configuration Librarian is assigned.
 How Baselining is done
 Three type of Configuration : Baseline, Managed and
controlled, Managed, Controlled.
 Maintain the status and history of each configuration item
 Perform configuration Audits at regular frequency by SQA. It is
part of regular audits.
Configuration Management

Procedure Configuration Management

Guidelines

Template Environment Verification Template, CM Plan, Release Note, CM Audit,

Checklist
Risk Management

The purpose of Risk Management is to identify potential

problems before they occur, so that risk-handling activities may
be planned and invoked as needed across the life of the product
or project to mitigate adverse impacts on achieving objectives
Risk Management

 Prepare Risk Register( Identify Risk, Mitigation , Contingency

Plan)
 Use Risk Database at organization level for identification of
risk.
 Review Risk Register at regular intervals at least one a month.

Procedure Risk Management

Guidelines
Template Risk Register Template
Checklist
Project Planning
Phase Activiy Discription Deliverable/Output
Standard Alternative
Project Planning Estimate effort for project / Verify Project effort estimation sheet / -
Estimation Revised Estimates
Contract Hours
Estimate for each enhancement
Prepare Project Schedule Project Schedule(MPP, Excel) Excel
Release Schedule
Start & End Date with Planning
Activity
Identify Project Risks Risk Register
Prepare Project Plan IPMP
Prepare CM Plan CMP
Review Project Plans Review Log
Approve Project Plans Approval of IPMP, CMP, Risk
Register
If Tailoring, approve IPMP from Approved IPMP
SEPG
Work Product Audit (Pan) Audited IPMP
Perform SQA Initiation Audit SQA Audit Report
Project Planning (Audit Check Points)
 Estimation
• Is any methodology followed for estimation ( FP / UCP/ Task Based estimation)
• Check the estimation sheet how it has been arrived.
• Ideally, productivity used should be the organization level productivity.
 Schedule
• Whether the schedule and estimation is matching.
• How the schedule has been arrived at.
• whether the resources are specified in the schedule.
• Is the version of schedule been maintained.
• Check the activities such as Unit testing , reviews , SQA Product Audits has been
defined in the schedule.
 Risk Register
• Risk Register is reviewed and approved.
• Check the risk register is properly defined.
• Check whether Information Security Risks has been identified.
 IPMP
 There should not be much gap between IPMP Preparation and PI Note date.
 IPMP is reviewed. Check the date of review is after the PI Note. Check the review
log. In case there is no comments it should be questioned. Check whether review
comments are closed.
 Project Planning (Audit Check Points)
 IPMP
• Check if IPMP is approved. The date of approval is after review and incorporation of
• review comments date.
• Check that all the sections of IPMP are defined. Check the PMP for frequency of
Team Meeting, Status Report, Sr. Management Review and Client Meetings are
defined in IPMP
• In case of tailoring is taken, is the approval mail and MOM available.
• In case metrics goals are not same as organization goals. Is justification provided.
 CM Plan
• Is CM Plan reviewed and approved.
• CI items are defined properly. Check whether the auditee understands the CI Types.
• Whether Access Rights are defined.? Check whether the request has been sent for
access rights to TST.
• Naming convention specified in the Plan. Are documents as per the naming
conventions.
 Test Plan
• Is test plan prepared , reviewed and approved.
• Check the type of testing defined in the plan.

 Check that Skill Assessment Sheet is available mentioning all the resources in the team.
Project Monitoring (Audit Check Points)
Phase
Project Monitoring & Control
Activiy Discription
Conduct Team Meetings
Send Status Report to client
Conduct Review with
Sr.Management
Log Issues
Update Risk Register
Prepare Time Sheet for Resources
Conduct Review at the end of
Milestone
Re-estimate effort at different
Phases as required
Update PHR
Perform Defect Analysis at
Milestone
Inform any change of Resources
Receive Approval for change in
resources from client
Prepare Revised Schedule / Plan ( if Rrvised Project Schedule(MPP,
Required) , review and approval
Project contract review as required Review Evidence
– in the middle of the project to
review changes to contract
Deliverable/Output
Standard Alternative
Projects MOMs ( with Client and Mail
Internal) (Progress Reviews)
Project Status Report client Mail
Project Review Reports (Sr.
Management Review) / MOMs
Jira/Excel
Risk Register (Updated)
Jira
Milestone Reviews Release Review
Revised Estimates Revised Estimates for
enhancements
Updated PHR
Defect Analysis Defect Analysis after Release
Defect Analyais of Inavlid Bugs
Periodic Defect Analysis
Inform change of resource
Approval on change of resources
Excel
Excel)
Revised Release Plan
Revised Project Schedule / Plan
Review and approved
Request for additional resources (If
any)
 Project Monitoring (Audit Check Points)
 Check the PMP for frequency of Team Meeting, Status Report, Sr. Management Review
and Client Meetings .
 Check the MOMs of the meetings. Check that following are discussed in the meeting :
• Project Schedule
• Project Efforts
• Project Risks
• Project Dependencies
• Commitment and deliverables
• Involvement of Stakeholders
• Configuration Management / Data Management
• Project Metrics
• Open Issues
• Critical Success Factors
• Audits and NCs
 Meetings are attended by TST , SQA whenever required.
 Check PHR is available for each month. In case of deviations whether these are discussed
in team meeting.
 Weather the milestone review has been done. The metrics / status has been discussed.
 Check CM Audits are done at frequency defined in IPMP by person defined in CM Plan
 Check the history of SVN in case of any change in version. Whether Version are tagged
properly.
Project Monitoring (Audit Check Points)
 Check that Skill Assessment Sheet resources in case of any new resource, removal of
resource
 Estimation
• Check if there are any revisions in the estimations due CRs
• Whether the Schedule has been updated
 Risk Register
• Check if the risk register is updated regularly as per the monitoring frequency
• Check if there any risk realized. Whether the same has been moved to issue register.
• Check the risk register is properly updated. Is there any changes in probability, impact
 Speak to the team members separately and check about the meeting. What is being
discussed in meeting. Check what they are saying is same as been told by other members.
Requirements
Requirements Management
The purpose of Requirements Management is to manage the
requirements of the project's products and product components
and to identify inconsistencies between those requirements and
the project's plans and work products
Requirements Management
 Obtaining commitments for requirements from stake-holders
 Objective criteria for the acceptance of requirements
 Impact on the project participants should be evaluated when
the requirements change or at the start of a new requirement
 Maintain bi-direction traceability from a requirement to its
derived requirements.
 Review the project's plans, activities, and work products for
consistency with the requirements and the changes made to
them
Procedure Requirements Development and Management
Guidelines
Template CR Log, RTT
Checklist
Requirements Development

The purpose of Requirements Development is to produce and

analyze customer, product, and product-component
requirements
Requirements Development
 Engaging relevant stakeholders using methods for eliciting
needs, expectations, constraints and external interfaces
 Capturing Non-Functional requirements
 Prioritize requirements
 Prepare Requirements Document (SRS / Requirements
Understanding Document) using templates
 Perform Peer Reviews of Requirements Document
 Obtain sign-off from customer

Procedure Requirements development and management

Guidelines Elicitation Guidelines
Template SRS, Requirements Understanding
Checklist Requirements Review Checklist
 Requirements
Phase Activity Description
Requirements Gather Requirements
Prepare SRS
Conduct Internal Review of SRS
Get Sign-off from Client of SRS
Prepare Change Request
Prepare Imact Analysis Document
Update CR Log
Get Approval from Client for CR
Update Requirement Traceability Matrix
Conduct Work Product Audit
Deliverable/Output
Standard Alternative
Requirements gathering (Mails / MOMs)
Requirement analysis & discussions (MOMs)
Analysis and Categorisation of
Tickets
Software Requirement Specification Requirements Understanding Doc.
Requirements Understanding in
Tickets
Requirements Review Log
Customer approval of SRS Requirements Understanding Doc.
Sign-off mail
CR Documents CR Tracker
Impact Analysis Document Impact Anayalys in Tracker
CR Log CR Log in Tracker
CR Approval (if it is from RSPL) CR Approval (if from RSPL) in
Tracker
RTT Creation & Updation
Work Product Audit
Requirements (Audit Check Points)
 Evidence available for the requirements / gathering clarification from client.( Mails,
MOMs)
 SRS has been prepared as per our template and all the sections are defined properly.
specifically Interfaces Requirement, Non-Functional Requirements, Priority , Acceptance
Criteria
 If SRS is not as per our template tailoring should be available.
 SRS has been reviewed and review comments available in review log.
 No comments are not acceptable. All the review comments should be closed.
 Requirements Traceability has been filled up properly. All the columns should be defined
including dependencies.
 In case of any change request, CR log should be filled-up as per the template. Approval
should be available from client.
 Check whether estimation has been changed to include CR in case of CRs
 Check whether schedule has been changed as next version.
 Check the impact of CR on IPMP, SRS, Design , test cases. If any of these are getting
impacted whether these have been changed and baselined.
 Check the baseline evidence.( Either in Baseline Report or SVN)
 Check whether the acceptance criteria is defined
 SQA Product Audit has been performed for SRS before delivery.
 Customer Sign-off has been obtained.
 Check the review dates, SRS delivery dates are matching in schedule.
Design and Development
Technical Solution

The purpose of Technical Solution is to design, develop, and

implement solutions to requirements. Solutions, designs, and
implementations encompass products, product components, and
product-related life-cycle processes either singly or in combinations
as appropriate
Technical Solution

 Generate alternative solutions and define criteria for selection

 Select the best set of alternative solutions that satisfy the
established selection criteria
 Define External Interfaces
 Identify the product-component solutions that will be reused
or acquired
 Define the technical data package
 Prepare design document using design template
 Review design document and log defect in review log
 Develop Code using Coding Standards
 Perform Code Review based on Coding Standards / Checklist
and log defects in Jira
Technical Solution

Procedure Software Design , Code and Code reivew,

Guidelines Coding Standards

Template Detailed Design Document

Checklist Code Review Checklist, Design Review Checklist

Product Integration

The purpose of Product Integration is to assemble the product from

the product components, ensure that the product, as integrated,
functions properly, and deliver the product
Product Integration

 Select the best integration sequence (Build)

 Develop an integration environment if a suitable environment
cannot be acquired
 Establish and maintain criteria for validation and delivery of
the integrated product
 Provide deployment and installation instructions

Procedure Software Design

Guidelines

Template Detailed Design Document

Checklist
Decision Analysis and Resolution

The purpose of Decision Analysis and Resolution is to analyze

possible decisions using a formal evaluation process that
evaluates identified alternatives against established criteria
Decision Analysis and Resolution

 Identify different alternative solutions

 Define criteria which can be used for evaluation along with
importance
 Evaluate proposed alternative solutions based on criteria

Procedure Decision and Analysis Resolution

Guidelines
Template DAR Template
Design and Development (Audit Check Points)
Phase Activiy Discription Deliverable/Output
Standard Alternative
Design Prepare Architecture Document Architecture Document
Conduct Internal Review of Architecure Document Review Log
Architecure Doc
Prepare Design Document Design Documents Design understanding Doc.
How bugs needs to be fixed
Conduct Internal Review of Design Design Document Review Log
Document
Prepare DAR related to Projects DAR
Define Product Integration Plan Product Integration Plan (Design Product Integration Plan Doc
Document)
Conduct Work Product Audit Work Product Audit
Update RTT Updated RTT
Development Coding Developed Code
Conduct Code Reviews Code Reviews Log
Prepare Unit Testing Unit Test Cases Unit Test Checklist
Perform Unit Testing Unit Test Results Unit Test Checklist
Update RTT Updated RTT
Design and Development (Audit Check Points)
 Design Document have been prepared as per template. Design document should have the
following :
• Alternative Design using DAR
• Make, Buy , Re-use Analysis
• External Interface Design
• Technical Package
• Product Integration Plan

 Check how DAR is done. Also, check how it is implemented in design.

 Check whether the review dates are matching in schedule
 Check whether the review time has been logged in Jira
 Ask for the checklist has been used for review ? Where it is available ?
 Check RTT, whether RTT has been updated for design
 Coding Standard used in Coding.
 Unit testing done. Check for the evidence. ( Unit Test Cases / Unit Testing Checklist / Unit
Testing Time logged, Unit Testing schedule)
 Check for the code review comments, check for code review time logged in Timesheet
 Check RTT, whether RTT has been updated for design and coding
 Ask the team members the process of design and check whether they are also aware of
the same process or not.
Testing
Verification

The purpose of Verification is to ensure that selected work

products meet their specified requirements
Verification

 Prepare Test Plan using template, Review Test Plan

 Prepare Test Case using template, Review Test Cases
 Plan for peer reviews for all documents
 Perform Peer Reviews and log review defects in review log /
Jira
 Perform testing and log defects in Jira
 Obtain QA –Sign-off
 Analyze defects.
Procedure Software Testing, Review Procedure
Guidelines Testing Guidelines, Defect Analysis Guidelines
Review Log Template, Test Plan Template, Test Case Template, Estimation
Template Template, QA-Sign Off Template
Checklist Test Case Review Checklist
Validation

The purpose of Validation is to demonstrate that a product or

product component fulfills its intended use when placed in its
intended environment
Validation

 Plan for UAT

 Identify UAT environment requirements
 Log defects of UAT in Jira
 Analyze defects of UAT
 Obtain UAT Sign-Off from Clients based on acceptance criteria

Procedure Software Testing

Guidelines Testing Guidelines, Defect Analysis Guidelines
Template
Checklist
Testing(Audit Check Points)
Phase Activiy Discription Deliverable/Output
Standard Alternative
Testing Prepare Test Plan Test Plan
Conduct Review of Test Plan Test Plan Review
Prepare Test Cases (Functional, Test Case Preparation Test Case Checklist / Test Case in
Integration, System) Jira
Conduct Review of Test Cases Test Case Review Defects logged in Test Case Checklist Review Defects
Jira / Review Log logged Jira / Review Log
Test Execution (Functional, Bug Tracker(Jira) Tool specified by Customer
Integration, System)
Perform Non-Functional Testing (If Jira Tool specified by Customer
budgeted)
Defect Report Tracking/Bug Bugs logged in Jira Tool specified by Customer
Tracking
Update RTT Updated RTT
Work Product Audit (Test Cases) Work Product Audit Report
Testing (Audit Check Points)
 Test Planning has been done. Review and Approval done.
 Test Cases have been prepared. Based on the test type to be performed whether test
cases are available.
 Check randomly any requirements and whether test case is available for that requirement.
 How is test data prepared. If provided by client, has it been masked.
 Test Case review has been done and review records available. Check review dates with the
schedule.
 Test Case template should be same as in QMS. If not whether tailoring has been taken.
 Check whether test cases have been updated with the pass / fail for the cycle. Also,
whether the Bug No. are logged in case of failure. Check in Jira whether it has been
logged.
 Check whether the bugs have been logged properly means root cause, bug category
should be filled.
 Check the dates of bugs logged in and schedule deigned randomly. It should match.
 Check whether the dates has been logged in bugs and not as task as bug fixing.
 Check whether the defect analysis has been done properly at the end of phase.
 Check whether the UAT Plan has been prepared and is available in schedule.
 Check whether the UAT Bugs have been logged either in Jira or excel.
 Check whether proper defect analysis has been done of UAT bugs.
Release
Phase Activiy Discription Deliverable/Output
Standard Alternative
Build Build Management Update Configuration Plan
Release Prepare Release Note Release Note Release Mail
Prepare Test Summary Report Test Summary Report
Get QA Sign-off for each release QA - Sign Off
Work Product Audit (Release) Audit report
UAT Jira Bug Logs
Tool specified by Customer
Bug Verification by Client
Get UAT Sign-off from Client UAT Sign off Bug Closure by Client
Get Customer Feedback Customer feedback
Get Project Sign-off Project Sign-Off
Release Sign-off Release Sign-off
Yearly Lessons Learnt Lessons Learnt Document
Project Closure
Phase Activiy Discription
Project Closure Conduct Project Closure Meeting
Archive Project Artifacts
Conduct Project Closure Audit
Process Conduct Regular SQA Audits
Deliverable/Output
Standard Alternative
Project Closure MOM
Lesson Learnt / Best Practices
Project Closure report
Release of Resources
Archives
Project closure Audit
SQA Audits Reports
Process and Product Quality Assurance

The purpose of Process and Product Quality Assurance is to

provide staff and management with objective insight into
processes and associated work products
Process and Product Quality Assurance
 Audits to are conducted by SQA as per defined plan
 Types of Audits (Initiation, Regular, Closure)
 Work Product Audit
 Audit checklists are used for conducting audits
 Audit Reports are generated. NC are logged in case of non-
compliance with expected date of closure.
 NCs are closed as per target date
 Audits are conducted to ensure that processes are
implemented as defined.
 Role of SQA. ( Ensure processes are implemented as defined
in QMS)