1. Capability Maturity Model Integration
CMMI Level 3: Process Overview
CMMI (Capability Maturity Model Integration) is a proven industry framework to improve product quality and development efficiency for both hardware and software
–CMMI has been established as a model to improve business results
CMMI, staged, uses 5 levels to describe the maturity of the organization,

2. Agenda CMMI Overview CMMI Process Areas
CMMI Process Areas - Organization
CMMI Process Areas - Project Management
CMMI Process Areas –Process
CMMI Process Templates
Q & A

3. Capability Maturity Model Integration (CMMI)
CMMI Overview
Capability Maturity Model Integration (CMMI)
CMMI (Capability Maturity Model Integration) is a proven industry framework to improve product quality and development efficiency for both hardware and software
–CMMI has been established as a model to improve business results
CMMI, staged, uses 5 levels to describe the maturity of the organization,

4. CMMI Staged Representation - 5 Maturity Levels
Process performance continually improved through incremental and innovative technological improvements.
Optimizing
Level 4
Maturity Level 3 deals with defined processes.
A defined process is a managed process that:
Well defined, understood, deployed and executed across the entire organization. Proactive.
Processes, standards, procedures, tools, etc. are defined at the organizational (Organization X ) level. Project or local tailoring is allowed, however it must be based on the organization’s set of standard processes and defined per the organization’s tailoring guidelines.
Major portions of the organization cannot “opt out.”
Quantitatively
Managed
Processes are controlled using statistical and other quantitative techniques.
Process Maturity
Level 3
Processes are well characterized and understood. Processes, standards, procedures, tools, etc. are defined at the organizational (Organization X ) level. Proactive.
Defined
Goal
Level 2
Managed
Processes are planned, documented, performed, monitored, and controlled at the project level. Often reactive.
Level 1
Initial
Processes are unpredictable, poorly controlled, reactive.

5. CMMI Process Areas Level 2 Level 3 Level 4 Level 5 (Defined) 7 11 2 2
(Managed) 7
Level 3
(Defined) 11
Level 4
(Quantitatively Managed) 2
Level 5
(Optimizing) 2
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Organizational Process Performance (OPP)
Causal Analysis & Resolution (CAR)
Measurement and Analysis (MA)
Integrated Project Management (IPM)
Quantitative Project Management (QPM)
Organizational Performance Management (OPM)
Project Monitoring and Control (PMC)
Organizational Process Definition (OPD)
Project Planning (PP)
Organizational Process Focus (OPF)
Risk Management (RSKM)
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Process and Product Quality Assurance (PPQA)
Organizational Training (OT)
Technical Solution (TS)
Requirements Management (REQM)
Product Integration (PI)
Verification (VER)
Supplier Agreement Management (SAM)
Requirements Development (RD)
Validation (VAL)

6. CMMI Process Areas – Level 3
Project Management
Engineering
Process Management
Support
Integrated Project Management (IPM)
Requirements Management (REQM)
Organizational Process Definition (OPD)
Measurement and Analysis (MA)
Project Planning (PP)
Requirements Development (RD)
Organizational Process Focus (OPF)
Process and Product Quality Assurance (PPQA)
Project Monitoring and Control (PMC)
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Technical Solution (TS)
Organizational Training (OT)
Configuration Management (CM)
Risk Management (RSKM)
Product Integration (PI)
Decision Analysis and Resolution (DAR)
Verification (VER)
Supplier Agreement Management (SAM)
Validation (VAL)

7. CMMI Process Groups & Areas Process Management
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Training (OT)
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Need more details for OPD, OPF and OT(Process and Templates)
Managing and controlling the Organizational metrics database
Organization Vision
Organization Mission
Quality Policy
Customer Policy
Business Strategy
Management
Sales & Marketing
Supplier Management
Product/Solution/Service Life Cycle
Project Management
Life Cycle Model
Requirements Management
Configuration Management
Process Management
Quality Management System
Process Improvement
Automation
Tailoring - Handbook
Audits and Assessments
Measurement and Metric
Training
Admin HR
Sub Contract Management

8. CMMI Process Areas - Organization
Organization Quality Statement
“Excelsoft is committed to deliver value to all customers’ through high quality products, solutions and services by continual improvement of business processes, knowledge and skills by adopting global standards.”
Meet and Exceed Customer Satisfaction in every delivery
Develop Effort estimates to allow accurate project schedule development
Control Project Schedule slippage within 5 % deviation
Ensure Cost within estimated budget
Ensure Post release Defect less than 1
Continuously improve Process Compliance to ensure complete process institutionalization
Provide relevant training for current role, personal and professional growth
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Need more details for OPD, OPF and OT(Process and Templates)
Managing and controlling the Organizational metrics database
Organization Vision
Organization Mission
Quality Policy
Customer Policy
Business Strategy
Management
Sales & Marketing
Supplier Management
Product/Solution/Service Life Cycle
Project Management
Life Cycle Model
Requirements Management
Configuration Management
Process Management
Quality Management System
Process Improvement
Automation
Tailoring - Handbook
Audits and Assessments
Measurement and Metric
Training
Admin HR
Sub Contract Management
Reference: Organization Policy

9. CMMI Process Areas - Organization
Organization Mission Statement
Delivering Value to all stakeholders: Customers, Shareholders, Society, Business Partners, Employee, through:
Strong Leadership and innovative business model
Open, Clear, Ethical and Sound Business Practices
Confidence to Customers, Business Partners and Share holders
Highest Employee Satisfaction and high Quality of Workforce
Excellence in operational services acquiring continuous knowledge and skills
Acquire best in state of the art appropriate IT technology
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Need more details for OPD, OPF and OT(Process and Templates)
Managing and controlling the Organizational metrics database
Organization Vision
Organization Mission
Quality Policy
Customer Policy
Business Strategy
Management
Sales & Marketing
Supplier Management
Product/Solution/Service Life Cycle
Project Management
Life Cycle Model
Requirements Management
Configuration Management
Process Management
Quality Management System
Process Improvement
Automation
Tailoring - Handbook
Audits and Assessments
Measurement and Metric
Training
Admin HR
Sub Contract Management
Reference: Organization Policy

10. CMMI Process Areas - Organization
Organization Vision Statement
“Be a Global Leader in enabling Education & Training Services by leveraging Information Technology.”
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Need more details for OPD, OPF and OT(Process and Templates)
Managing and controlling the Organizational metrics database
Organization Vision
Organization Mission
Quality Policy
Customer Policy
Business Strategy
Management
Sales & Marketing
Supplier Management
Product/Solution/Service Life Cycle
Project Management
Life Cycle Model
Requirements Management
Configuration Management
Process Management
Quality Management System
Process Improvement
Automation
Tailoring - Handbook
Audits and Assessments
Measurement and Metric
Training
Admin HR
Sub Contract Management
Reference: Organization Policy

11. CMMI Process Area vs Template
ES QMS Process / Procedure
ES QMS Template
Requirements Management (REQM)
ES Change Management Process - V
Change Request Form-V Change Register-V
Project Planning (PP)
ES Project Planning Process - V
Statement of Work - V Project Plan Template Project Charter - V Estimation Template-Hrs-V Project Closure Report - V LessonLearnt-Format-V
Integrated Project Management (IPM)
Project Monitoring and Control (PMC)
ES Project Monitoring Process - V
Weekly_Status_Report-V Meeting Minutes-V Project Status Report
Measurement and Analysis (M&A)
TFS Data
(for schedule, effort, productivity, bugs)
Process and Product Quality Assurance (PPQA)
ES-Project SQA Process - V
Internal-Audit Report-V QMS - NC - Report - V
Configuration Management (CM)
ES Configuration Management Process - V
ConfigurationManagementPlan-V
Requirements Development (RD)
ES Requirement Process - V
Software Requirements Specification - V RequirementsGapAnalysisTemplate-V

12. CMMI Process Area vs. Template Continued..
ES QMS Process / Procedure
ES QMS Template
Technical Solution (TS)
ES Design -TechSolution Process - V
TAD-Template-V
Product Integration (PI)
Decision Analysis and Resolution (DAR)
Verification (VER)
ES Verification Process - V
TFS Data (for document review, code review comments)
Validation (VAL)
ES Validation Process - V
Test Plan - V Test Case-Import Format for TFS QA Report - V Release Notes-V
Risk Management (RSKM))
ES Risk Mgmt Process - V
Risk management and WSR.
Organizational Process Definition (OPD)
ES Process Definition Process- V
ES QMS
Organizational Process Focus (OPF)
CORRECTIVE&PREVENTIVE ACTION-V QMS - NC - Report - V PROCESS CHANGE REQUEST TEMPLATE - V Internal-AuditReport-V
Organizational Training (OT)
ES Training Process
Training Request Forms

13. CMMI vs. Agile CMMI Process Area Agile Comments
Requirements Management (REQM)
Project Backlog
Intake Kick off meeting, User stories, Clarifications, Backlog refinement, Review and approval of requirements
Integrated Project Management (IPM)
Continuous integration
Requirements Development (RD)
User Stories
User case documentation
Technical Solution (TS)
Decision on tooling
Decided at the beginning of the project
Project Planning (PP)
Sprint Planning
Stories / Sprint Planning Standardization of estimation model
Configuration Management (CM)
Configuration tools
Product Integration (PI)
Continuous Integration
Decision Analysis and Resolution (DAR)
Structured Decision making process
Verification (VER)
Review Process
Peer Review, Peer testing, Code review checklist
Validation (VAL)
Testing
Automated Testing(Tool-Selenium)

14. CMMI Process Area vs. Agile
Comments
Risk Management (RSKM))
Risk management at early phase
Maintain Projects Risk register
Project Monitoring and Control (PMC)
Stand-up Meeting , Project Dashboards, Burn down charts, Sprint closure meeting,
Review and Control-Risk Analysis.
Measurement and Analysis (M&A)
Measurements as per project dashboard and tools used for project monitoring
Standardized few measurements across the Sprints maintained in standard contract dashboard
Process and Product Quality Assurance (PPQA)
Audits
Regular Audits by external quality auditor using standard audit checklist. Retrospective meetings
Organizational Process Definition (OPD)
OPD is to establish and maintain a usable set of organizational process assets and work environment standards.
Organizational Process Focus (OPF)
Organization Process Focus provides for the planning of an implementation of the process
improvement effort.
Organizational Training (OT)
Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently .
CMMI Trainings
The organization’s processes include all processes used by the organization and its projects. Candidate improvements to the organization’s processes and process assets are obtained from various sources, including the measurement of processes, lessons learned in implementing processes, results of process appraisals, results of product and service evaluation activities, results of customer satisfaction evaluations, results of benchmarking against other organizations’ processes, and recommendations from other improvement initiatives in the organization.
Process improvement occurs in the context of the organization’s needs and is used to address the organization’s objectives. The organization encourages participation in process improvement activities by those who perform the process. The responsibility for facilitating and managing the organization’s process improvement activities, including coordinating the participation of others, is typically assigned to a process group. The organization provides the long-term commitment and resources required to sponsor this group and to ensure the effective and timely deployment of improvements.

15. CMMI Process Groups & Areas Project Management, Engineering & Support
Initiating
Planning
Executing
Monitoring & Controlling
Closing
Integrated Project Management (IPM)
Product Integration (PI)
Project Monitoring and Control (PMC)
Requirements Management (REQM)
Verification (VER)
Measurement and Analysis (MA)
Project Charter
by using Contract/ SOW/
Business Case
Requirements Development (RD)
Validation (VAL)
Decision Analysis and Resolution (DAR)
Technical Solution (TS)
Project Plan(PP)
Verifying Deliverables Customer Acceptance
Lessons Learned
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Configuration Management (CM)
Risk Management (RSKM)
Process and Product Quality Assurance (PPQA)
Supplier Agreement Management (SAM)

16. Initiating Initiating Project Project scope Project Charter Timelines
by using SOW
Project scope
Timelines
Cost
Assumption
Constraints
Risk
Stakeholder details
Initiating Project
References: Project Charter

17. Planning
Project Planning

18. Integrated Project Management (IPM)
Reference document link-
Project Management Plan
Requirement (Scope) Management
Human Resource Management
Project Management Plan
Schedule (Time) Management
Communication Management
Quality Management
Stakeholder Management
Risk Management
Procurement Management
Project Plan and Integration plan(Combined)
Estimation technique-
Coordinator presents each expert with a specification and an estimation form.
Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.
Experts fill out forms anonymously.
Coordinator prepares and distributes a summary of the estimates
Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely
Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.
Project Templates
Statement of Work V
Project Plan Template
Project Charter V
Estimation Template Hrs V
Project Closure Report V
Lessons Learnt-Format V
Cost Management

19. Requirements Management (REQM)
Gather Requirement
Validation
Control
Document the requirements tools(Workshops/Interviews/Prototype)
Various sections
->Talk about the tools- Workshops, interviews, prototype..etc
->Change control process
-> Change control board
->Change approval process
-> etc
Gathering requirements –tool
CCB Process
Change request process
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project.
Project Templates
Software Requirements Specification - V dotx
Change Request Form-V
Change Register-V
References: Requirements Management

20. Requirements Development (RD)
Collect Requirements
Analyze Requirements
Collecting Requirements
Analyze the Requirements
Baseline the Requirement
Baseline Requirements

21. Requirements Development (RD)
Stakeholder(S)/Client/Customer
Begin No
Requirements Elicitation
Product Evolution / New Client Acquisition / New Requests
Yes
Update and Review SRS No
Gathering Requirements for Product/Project
Update SRS
Form Stakeholders Committee
Finalize SRS
Requirements from Stakeholders
If any Non-Compliance with stakeholder
Review and Approval of SRS
Analyze Requirements
\\nas\QMS-Templates\Artifacts
\\nas\QMS-Templates\Guide Lines
\\nas\QMS-Templates\Hand Books
\\nas\QMS-Templates\IntegrationDocuments
\\nas\QMS-Templates\InternalAuditReports
\\nas\QMS-Templates\LDS\Flow Diagrams(Architecture diagram)
\\nas\QMS-Templates\LDS
\\nas\QMS-Templates\MOM
\\nas\QMS-Templates\Procedures
\\nas\QMS-Templates\Process
\\nas\QMS-Templates\Report
\\nas\QMS-Templates\RiskDatabase
\\nas\QMS-Templates\Standards
\\nas\QMS-Templates\Templates
Yes
Initiate SRS Document
Finalize and Baseline SRS
SRS and RTM
PM/PDM
Yes
SRS Template
PM/PDM
End
References: Requirement Process
Software Requirements Specification
Requirements Gap Analysis
Discard Product / Project / Request

22. Technical Solution (TS) Process
System Architecture
Data Modeling
High Level Design
A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system.[1] An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.
Data modeling in software engineering is the process of creating a data model for an information system by applying formal data modeling techniques.
(Reference- process_modeling)
High Level Design (HLD) is the overall system design - covering the system architecture and database design. It describes the relation between various modules and functions of the system. data flow, flow charts and data structures are covered under HLD. Low Level Design (LLD) is like detailing the HLD.
A high-level design document or HLDD adds the necessary details to the current project description to represent a suitable model for coding. This document includes a high-level architecture diagram depicting the structure of the system, such as the database architecture, application architecture (layers), application flow (navigation), security architecture and technology architecture. [1]
High-level design (HLD) explains the architecture that would be used for developing a software ... of the system. In contrast, low-level design further exposes the logical detailed design of each of these elements for programmers.
Low-level design (LLD) is a component-level design process that follows a step-by-step refinement process. This process can be used for designing data structures, required software architecture, source code and ultimately, performance algorithms. Overall, the data organization may be defined during requirement analysis and then refined during data design work. Post-build, each component is specified in detail.[1]
Low Level Design

23. Technical Solution (TS) Process …Continued
Tech / Solution Architect
Begin
Governance
Team
Not Approved
Verify and Validate High level Design
Baseline SRS
Start Technical Design Process
Low Level Design
System/Software Architecture
Not Approved
Verify and Validate Low level Design
Not Approved
Verify and Validate Architecture
Approved
Deployment Architecture
Approved
Data Modeling
Not Approved
Verify and Validate Deployment Architecture
Not Approved
A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system.[1] An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.
(Reference- process_modeling)
Data modeling in software engineering is the process of creating a data model for an information system by applying formal data modeling techniques.
High Level Design (HLD) is the overall system design - covering the system architecture and database design. It describes the relation between various modules and functions of the system. data flow, flow charts and data structures are covered under HLD. Low Level Design (LLD) is like detailing the HLD.
A high-level design document or HLDD adds the necessary details to the current project description to represent a suitable model for coding. This document includes a high-level architecture diagram depicting the structure of the system, such as the database architecture, application architecture (layers), application flow (navigation), security architecture and technology architecture. [1]
High-level design (HLD) explains the architecture that would be used for developing a software ... of the system. In contrast, low-level design further exposes the logical detailed design of each of these elements for programmers.
Breakdown the requirement to Module Level
System / Software Architecture
Scoping of Requirements
Features are collection of functionalities.
Modules are collection of features.
Identify major and minor interfaces.
Define in-scope and out of scope for the requirements.
Define components.
Identify external and internal interfaces
Define Functional Components
Exceptions
Instantiation
Define Reusable Components
List the Use Case representing the functionality of the requirement.
Defining the Dynamic behavior:
Identify the reusable components in Product / Project.
In Case of Distributed and concurrent system:
Define Constraints.
Describe message signature (e.g. IDL)
Performance optimization for the components mapped.
Map components to a Process of a Physical System.
Data Modeling
Review with same with relevant stakeholders.
Product / Project component analyzed using appropriate DAR templates.
Identify and Document Data Entities
Derive the preliminary data model from the information gathered by identifying objects.
Describe purpose and goal for each entity while creating a data model.
Create Data Model by gathering existing information of the Product / Project.
Define and document relationships
Create a Data Flow Diagram.
Analyse each row and column intersection for possible relationships.
Identify required relationships between entities, without directly considering physical design issues.
Draft preliminary Conceptual Data Model.
Record the verb at each intersection that describes a relationship.
Draw the relationships between the entities.
Identify the entity involved in the most relationships and draw that entity near the centre of the Entity-Relationship Diagram.
Identify and document the business rules.
Ensure that each entity and relationship accurately represents the reality of the business being modeled.
Determine relationship dependencies and relationship cardinality.
Begin to derive the Logical Data Model from the Conceptual Data Model.
Review the data model with relevant stake holder.
Decompose many-to-many relationships.
Identify entity super types and subtypes.
Identify attributes
Determine relationship dependencies and relationship cardinality for new entities.
Normalize the Data Model
Describe all logical paths to access data contained in the data model, identifying primary, candidate, and foreign keys.
Define, name, and document entity attributes.
Translate entities and relationships into two-dimensional tables with each column in the table representing an entity attribute and each row an occurrence.
The process of Normalization may also uncover additional entities and relationships.
Refine the assignment of attributes to entities and relationships. Follow the rules of Normalization to verify that attributes are properly assigned to entities and relationships to avoid data redundancy.
De-normalizing tables if required.
High-level architectural diagram depicting the components interfaces and networks that need to be further specified or developed.
Provide overview of a Product / Project.
High Level Design
Provide clarity at high level of the ownership, activities and collaboration between various project teams.
High Level design provides workflows and data flows between component systems.
Defining the actual logic for each and every component of the Product / Project.
Detailing the HLD
Low Level Design
The LLD will contain:
Class Diagrams with all the methods along with relationship for Classes for the Product / Project.
All interface details with complete API references(both requests and responses)
Database tables with all elements including their type and size
Detailed functional logic of the module in pseudo code
Complete input and outputs for a module
All dependency issues - error message listings
Low-level design (LLD) is a component-level design process that follows a step-by-step refinement process. This process can be used for designing data structures, required software architecture, source code and ultimately, performance algorithms. Overall, the data organization may be defined during requirement analysis and then refined during data design work. Post-build, each component is specified in detail.[1]
Verify and Validate Data Modeling
Approved
Approved
Update RTM
High Level Design
End
References: Technical Solution Process , TAD-Template-V

24. System Requirement Specification
Project Plan
System Requirement Specification
Create WBS
Estimations
Capacity Planning
Schedule
Verification and Change Request
Quality Plan
Risk Plan

25. Project Plan …Continued
Estimation Guideline
Begin
PM/Project Team
Work Breakdown Structure
Estimation Template
Estimations
Project Plan
Capacity Planning
DM/Deployment Team
Schedule Development
Deployment Plan
Deployment Plan
Test Plan
QA Team
Test Plan
Risk Plan
Risk Planning No
Verified
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Need more details for OPD, OPF and OT(Process and Templates)
Yes No
Validated
Yes
Incorporate Changes
Approval from Stakeholders
Approved Project Plan
References: Project Planning Process ,
Project Plan Template.mpp
End

26. Configuration Management (CM) Process
Identify Configuration Items
Create Plan
Review Plan
Identify Configuration Items
Create Plan
Review Plan
Baseline Plan
Baseline Plan

27. Configuration Management (CM) Process …Continued
Configuration Management Plan
Review Forms
Begin
Change Required to Baseline? No
Yes
Identify Configuration Items
Identify Affected Configurations
SQA
Prepare the Configurations Management (CMP)
Incorporate Changes to Baselines
Review CMP
Yes
Review and Approve Changes
Change Required?
Configuration Control
Identify Configuration Items
Create Plan
Review Plan
Baseline Plan No
Backups
Baseline CMP
Configuration Audits
Establish CM Library
End
Check in/baseline
References: ES ConfigurationManagementProcess , ES ConfigurationManagementPlan

28. Risk Management (RSKM) Process
Risk Management form
Identify Risk
Identify severity & probability of each risk
Capture the Risk
Perform Qualitative Analysis
Risk Mitigation & Contingency
Identify Risk
Capturing the Risk(Risk Register)
Perform Quantative Analysis
Risk Response
Update Register(Baseline)
Risk Response

29. Risk Management (RSKM) Process …Continued
Begin
Risk Management Template
Project team (PM/TL)
Identify Risks
Document risks in Risks Management Templates
Identify the type of Risk
Identify Severity & Probability of each risk
Calculate Risk Magnitude base on Severity & Probability
Minutes of Meeting (MOM)
Determine Risk Mitigation & Contingency Plan
Identify Risk
Capturing the Risk(Risk Register)
Perform Quantative Analysis
Risk Response
Update Register(Baseline)
Identify Risk Owner
Track & Monitor each risk till closure
End
References: Risk Management(RSKM) Process, Change Register, Change Request Form

30. Process and Product Quality Assurance (PPQA)
SQA Planning
Review and Approve
Audit Report
Execute Plan
Quality Management
Quality Assurance
Quality Control
\\nas\QMS-Templates\Process\ES Internal Audit Process- V doc
\\nas\QMS-Templates\InternalAuditReports\MetricsReports\
References: ES-Project SQA Process , Audit Report, QMS-NC-Report

31. Audit Process Define Plan Conducting Recording Reviewing
Audit Checklist
Define Plan
Process deviation
Conducting
Ensure that team has addressed the process findings
Recording
Reviewing
Audit Report
which includes Non- Compliance (NC) details
Summary Report
References: Audit Process, Metrics Report

32. Executing
Executing

33. Verification (VER) Process
Plans,
Requirement Specs,
Design Specs,
Code and
Test Cases
Reviews
Walkthroughs
Inspections
Review Plans
Project Plans
RTM
Update Review Comments
Verify review plan with all relevant stakeholders
Obtain feedback and update review plan
Obtain approval and commit plan for the project
Weekly Status Report(MOM)
QA Report
Performance Test Results
Security Testing Results
Audit Report
QMS
Project Closure
References: ES Verification Process

34. Verification (VER) Process …Continued
TFS Data (for document review, code review comments)
Begin
PM/TL/SQA
Review Plan
Perform Review
Review Report
Templates/Forms
Project Plan/Quality Plan
Review Check lists
Review Form
Review-Peer Review Report
Yes
Change required? No
Review & Approved Review Report
Modify Work Product
PM/TL/SQA
Yes No
Modify work product based on Review
Update review report in Configuration tool
References:
ES Verification Process
End

35. Validation (VAL) Process
Testing
The actual product/software
Change Request
Validate Results
References: ES Validation Process

36. Validation (VAL) Process …Continued
PM/TL
Begin
QA Lead/QA Engineer
Project Plan
Test Plan (UT, IT, ST) / Test Cases
PM/QA Manager/TL
Review
Review - Peer Review Report
Yes
Change required No
Modify test plan / Test cases
Templates/Forms
Test Plan - V
Test Case-Import Format for TFS
QA Report - V
Release Notes-V
Update test plan and test cases documents in configuration tool
End
References: ES Validation Process

37. Verification & Validation
Product Integration
Incremental
Integrating
Products Components
Verification & Validation
This process area addresses the integration of product components into more complex product components or into complete products.
The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.
A critical aspect of product integration is the management of internal and external interfaces of the products and product components to ensure compatibility among the interfaces. Attention should be paid to interface management throughout the project.
Product integration is more than just a one-time assembly of the product components at the conclusion of design and fabrication. Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components. This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic incremental functionality until the final product is achieved. In each successive build, prototypes (virtual, rapid, or physical) are constructed, evaluated, improved, and reconstructed based on knowledge gained in the evaluation process. The degree of virtual versus physical prototyping required depends on the functionality of the design tools, the complexity of the product, and its associated risk. There is a high probability that the product, integrated in this manner, will pass product verification and validation. For some products and services, the last integration phase will occur when they are deployed at the intended operational site
References: Technical Solution Process

38. Monitoring and Controlling

39. Project Monitoring and Control (PMC)
Frequency/
As needed
Planning
Project reports
Collecting Status
Analyze Variance
Change request-Accept/Reject
Risk-Mitigation/Contingency
Change Request
Update the changes/Risks

40. Project Monitoring and Control (PMC)
Begin
Project Reports
Monitor Project Planning
Project Templates
Weekly_Status_Report-V
Meeting Minutes-V
Project Status Report
Collect Status
Analyze Variance from Plan No
Change Required
Stakeholders
(Management/ Customer / SQA)
Yes
Incorporate Changes
Review Form
Review Changes
Revised & Approved PMP
End
References: ES Project Monitoring Process

41. Measurement and Analysis (MA)
Reduce time to delivery
• Deliver specified functionality completely
• Improve prior levels of quality
• Improve prior customer satisfaction ratings
QMS
Define Objective
TFS Data
(for schedule, effort, productivity, bugs)
Project Reports
Project Data Collection and Storage
Change request-(Accept/Reject)
Risk-Mitigation/
Contingency
Tracking actual performance against established plans and objectives
Analysis
Corrective/Preventive actions
· Tracking actual performance against established plans and objectives
· Identifying and resolving process-related issues
· Providing a basis for incorporating measurement into additional processes in the future
Reduce time to delivery
• Reduce total lifecycle cost
• Deliver specified functionality completely
• Improve prior levels of quality
• Improve prior customer satisfaction ratings
• Maintain and improve the acquirer/supplier relationships
SP 1.1: Establish and maintain measurement objectives
that are derived from identified information needs and
objectives.
SP 1.2: Specify measures to address the measurement
SP 1.3: Specify how measurement data will be obtained and
stored.
This practice simply asks for a definition of how and where data
are collected. An example would be: “Every Monday, each
project manager collects actual effort hours expended on project
SP 1.4: Specify how measurement data will be analyzed
and reported.
This practice helps clarify what to look for in the data. For
Reports
References: Metric Reports, Corrective & Preventive actions

42. Decision Analysis and Resolution (DAR)
Business decisions
Requirements prioritization
Supplier selection
Any business problem
Technical decision
Architectures
Technical solutions
Any technical problem
Change Request,
Risk Mitigation, Contingency Plan
Problem Statement
Formal Evaluation Process
Recommended Solution
program. However, care should be taken to limit it to key
DAR can apply to all levels of decisions made within a
program decisions (identified within the program through the
event triggers defined in Section 1.4) so as to not impede the
program's progress. Completed DAR worksheets will be stored
Configuration Management Plan.
in the approved program document repository according to the
specified program cost increase threshold
ã Capital expenditures over a specified cost
ã Significant architectural changes
ã Make/buy/reuse decisions
ã Significant schedule slip
ã Addition of a new release family
ã Selection of third party solution providers
ã Modification of organizational processes
ã Selection of organizational tools
Brainstorming
ã Solution solicitation
ã Question and answer
ã Market research
ã Competitor analysis
ã Customer feedback
ã Analysis of similar problems solved on other programs
and their solutions
Formual Evaluation Process
Issues from stakeholders
Recommended Solution
Issues that have multiple alternatives and
􀂄 Personnel
evaluation criteria lend themselves to DAR
􀂄 Requirements
prioritization
􀂄 Supplier selection
problem
􀂄 Any business
􀂄 Life cycles
􀂄 Platforms
􀂄 Architectures
languages
􀂄 Programming
􀂄 Technical solutions
􀂄 Any technical
(Business /Technical) Decision
Problem/Issue
Establish guidelines for Decision Analysis
Establish Evaluation Criteria
Identify Alternative Solution
Select Evaluation Methods
Evaluate Alternative
Select Solution

43. Closing
Closing

44. Updating Project Documents
Closing
Customer Acceptance
Lessons Learned
Updating Project Documents
References: Project Closure Report , Project Product Sign Off , Lesson Learnt Report

45. CMMI Documents Repository
Portal URL :
Credentials : Username and Password
CMMI folder path : Home Page->Knowledge Repository (Left side menu bar)-> CMMI Folder

46. Thank you
Question and Answer