SlideShare a Scribd company logo
1 of 17
Senthil
June 26, 2014
Parallel Computing
Background
“We all have done, are doing and will do
Parallel Computing in our daily lives”
Examples
 Studying for an exam
 Multiple subjects in a semester
 Working together as a team – Towards a
common goal
 Our Brain – All in all
“No super computer has reached the
processing capabilities of a human brain”
Today…
“We will try to bridge the Tech and Non Tech
understanding of Parallel Computing”
 Tech – Java
 Non Tech – Self and Team Work
Need
 Faster processing
 Save power
 Efficient utilization of resources
Processing
 Serial Run – One after the other – Semester
Exam – One exam a day
 Parallel Run
 Threading – Reading a book
 Executors – Working as a team
 Fork Join – Working as an efficient team
Threading
 Non Tech Example – Reading a book or Studying
for an exam
Threading
 See
 Read
 Underline important points
 Understand
 Remember
“Similarly, a computer process can spawn
threads to compute a problem in parallel”
Executors – Java 6
 Single Core vs. Multi Core
 How to use multi core
 Thread Pooling
“Working together as a team”
Fork Join – Java 7
 Divide and Conquer
 Use multiple cores
 Special Algorithm – WORK STEALING
“Working as an efficient team”
Work Stealing
 Steal the work from cores that are busy
 Full utilization of CPU
“If you are free,
share the work load of your team mates”
Practical
 100 tasks need to be run on a Quad Core machine
 Following ways
 Serial
 Parallel – Executors [4 & 16 threads]
 Parallel – Fork Join
 Observe the CPU Chart
Note
 Practical code - Parallel.zip available
mfinfiles02/Public_Engineering_India/_Device_Team/Senthil/Parallel.zip
 Study jDevSim code [jDevSim, jAppDownload, jGcmServer] –
http://mfinsvn/repo-mirror/devices/trunk/JavaDeviceSimulator
CPU Chart – Serial
 122.777 seconds
 10 to 15% CPU Utilization
CPU Chart – Executors – 4 Threads
 36.624 seconds
 ~50+% CPU Utilization
CPU Chart – Executors – 16 Threads
 16.842 seconds
 Almost 100%
CPU Chart – Fork Join
 15.889 seconds
 100% – Complete Utilization
Thank You

More Related Content

Viewers also liked

7)2016-1_Caperón Peralta_Roberto Arturo
7)2016-1_Caperón Peralta_Roberto Arturo7)2016-1_Caperón Peralta_Roberto Arturo
7)2016-1_Caperón Peralta_Roberto Arturomarconuneze
 
Wida nursyahidah 6701140054_pis1405_tugas apsi
Wida nursyahidah 6701140054_pis1405_tugas apsiWida nursyahidah 6701140054_pis1405_tugas apsi
Wida nursyahidah 6701140054_pis1405_tugas apsiuwidd
 
Using Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesUsing Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesF5 Networks
 

Viewers also liked (6)

7)2016-1_Caperón Peralta_Roberto Arturo
7)2016-1_Caperón Peralta_Roberto Arturo7)2016-1_Caperón Peralta_Roberto Arturo
7)2016-1_Caperón Peralta_Roberto Arturo
 
2009felhő
2009felhő2009felhő
2009felhő
 
Exp Cert
Exp CertExp Cert
Exp Cert
 
IIITDM LOR
IIITDM LORIIITDM LOR
IIITDM LOR
 
Wida nursyahidah 6701140054_pis1405_tugas apsi
Wida nursyahidah 6701140054_pis1405_tugas apsiWida nursyahidah 6701140054_pis1405_tugas apsi
Wida nursyahidah 6701140054_pis1405_tugas apsi
 
Using Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesUsing Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and services
 

Similar to Parallel Computing

Multi t hreading_14_10
Multi t hreading_14_10Multi t hreading_14_10
Multi t hreading_14_10Minal Maniar
 
Module05 arena
Module05 arenaModule05 arena
Module05 arenaBoPeng76
 
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScript
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScriptJS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScript
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScriptJSFestUA
 
Processes and-threads
Processes and-threadsProcesses and-threads
Processes and-threadsjavaicon
 
Java Performance, Threading and Concurrent Data Structures
Java Performance, Threading and Concurrent Data StructuresJava Performance, Threading and Concurrent Data Structures
Java Performance, Threading and Concurrent Data StructuresHitendra Kumar
 
Mulitthread
MulitthreadMulitthread
MulitthreadDeepaR42
 
12. Parallel Algorithms.pptx
12. Parallel Algorithms.pptx12. Parallel Algorithms.pptx
12. Parallel Algorithms.pptxMohAlyasin1
 
Concurrency in java
Concurrency in javaConcurrency in java
Concurrency in javaSaquib Sajid
 
Operating Systems - "Chapter 4: Multithreaded Programming"
Operating Systems - "Chapter 4:  Multithreaded Programming"Operating Systems - "Chapter 4:  Multithreaded Programming"
Operating Systems - "Chapter 4: Multithreaded Programming"Ra'Fat Al-Msie'deen
 
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTES
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTESPARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTES
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTESsuthi
 
Cloudera Impala Internals
Cloudera Impala InternalsCloudera Impala Internals
Cloudera Impala InternalsDavid Groozman
 
Multithreading 101
Multithreading 101Multithreading 101
Multithreading 101Tim Penhey
 
Multithreaded Programming Part- II.pdf
Multithreaded Programming Part- II.pdfMultithreaded Programming Part- II.pdf
Multithreaded Programming Part- II.pdfHarika Pudugosula
 
Introduction to Java performance tuning
Introduction to Java performance tuningIntroduction to Java performance tuning
Introduction to Java performance tuningMarouane Gazanayi
 
C# Parallel programming
C# Parallel programmingC# Parallel programming
C# Parallel programmingUmeshwaran V
 
Node JS Express : Steps to Create Restful Web App
Node JS Express : Steps to Create Restful Web AppNode JS Express : Steps to Create Restful Web App
Node JS Express : Steps to Create Restful Web AppEdureka!
 
6-9-2017-slides-vFinal.pptx
6-9-2017-slides-vFinal.pptx6-9-2017-slides-vFinal.pptx
6-9-2017-slides-vFinal.pptxSimRelokasi2
 
Clustered PHP - DC PHP 2009
Clustered PHP - DC PHP 2009Clustered PHP - DC PHP 2009
Clustered PHP - DC PHP 2009marcelesser
 

Similar to Parallel Computing (20)

Multi t hreading_14_10
Multi t hreading_14_10Multi t hreading_14_10
Multi t hreading_14_10
 
Module05 arena
Module05 arenaModule05 arena
Module05 arena
 
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScript
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScriptJS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScript
JS Fest 2019. Александр Хотемский. Способы распараллеливания тестов в JavaScript
 
Processes and-threads
Processes and-threadsProcesses and-threads
Processes and-threads
 
Java Performance, Threading and Concurrent Data Structures
Java Performance, Threading and Concurrent Data StructuresJava Performance, Threading and Concurrent Data Structures
Java Performance, Threading and Concurrent Data Structures
 
Java multi thread programming on cmp system
Java multi thread programming on cmp systemJava multi thread programming on cmp system
Java multi thread programming on cmp system
 
Mulitthread
MulitthreadMulitthread
Mulitthread
 
12. Parallel Algorithms.pptx
12. Parallel Algorithms.pptx12. Parallel Algorithms.pptx
12. Parallel Algorithms.pptx
 
Concurrency in java
Concurrency in javaConcurrency in java
Concurrency in java
 
Operating Systems - "Chapter 4: Multithreaded Programming"
Operating Systems - "Chapter 4:  Multithreaded Programming"Operating Systems - "Chapter 4:  Multithreaded Programming"
Operating Systems - "Chapter 4: Multithreaded Programming"
 
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTES
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTESPARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTES
PARALLEL ARCHITECTURE AND COMPUTING - SHORT NOTES
 
Cloudera Impala Internals
Cloudera Impala InternalsCloudera Impala Internals
Cloudera Impala Internals
 
Multithreading 101
Multithreading 101Multithreading 101
Multithreading 101
 
Multithreaded Programming Part- II.pdf
Multithreaded Programming Part- II.pdfMultithreaded Programming Part- II.pdf
Multithreaded Programming Part- II.pdf
 
Introduction to Java performance tuning
Introduction to Java performance tuningIntroduction to Java performance tuning
Introduction to Java performance tuning
 
C# Parallel programming
C# Parallel programmingC# Parallel programming
C# Parallel programming
 
Node JS Express : Steps to Create Restful Web App
Node JS Express : Steps to Create Restful Web AppNode JS Express : Steps to Create Restful Web App
Node JS Express : Steps to Create Restful Web App
 
6-9-2017-slides-vFinal.pptx
6-9-2017-slides-vFinal.pptx6-9-2017-slides-vFinal.pptx
6-9-2017-slides-vFinal.pptx
 
concurrency
concurrencyconcurrency
concurrency
 
Clustered PHP - DC PHP 2009
Clustered PHP - DC PHP 2009Clustered PHP - DC PHP 2009
Clustered PHP - DC PHP 2009
 

Parallel Computing

  • 2. Background “We all have done, are doing and will do Parallel Computing in our daily lives”
  • 3. Examples  Studying for an exam  Multiple subjects in a semester  Working together as a team – Towards a common goal  Our Brain – All in all “No super computer has reached the processing capabilities of a human brain”
  • 4. Today… “We will try to bridge the Tech and Non Tech understanding of Parallel Computing”  Tech – Java  Non Tech – Self and Team Work
  • 5. Need  Faster processing  Save power  Efficient utilization of resources
  • 6. Processing  Serial Run – One after the other – Semester Exam – One exam a day  Parallel Run  Threading – Reading a book  Executors – Working as a team  Fork Join – Working as an efficient team
  • 7. Threading  Non Tech Example – Reading a book or Studying for an exam
  • 8. Threading  See  Read  Underline important points  Understand  Remember “Similarly, a computer process can spawn threads to compute a problem in parallel”
  • 9. Executors – Java 6  Single Core vs. Multi Core  How to use multi core  Thread Pooling “Working together as a team”
  • 10. Fork Join – Java 7  Divide and Conquer  Use multiple cores  Special Algorithm – WORK STEALING “Working as an efficient team”
  • 11. Work Stealing  Steal the work from cores that are busy  Full utilization of CPU “If you are free, share the work load of your team mates”
  • 12. Practical  100 tasks need to be run on a Quad Core machine  Following ways  Serial  Parallel – Executors [4 & 16 threads]  Parallel – Fork Join  Observe the CPU Chart Note  Practical code - Parallel.zip available mfinfiles02/Public_Engineering_India/_Device_Team/Senthil/Parallel.zip  Study jDevSim code [jDevSim, jAppDownload, jGcmServer] – http://mfinsvn/repo-mirror/devices/trunk/JavaDeviceSimulator
  • 13. CPU Chart – Serial  122.777 seconds  10 to 15% CPU Utilization
  • 14. CPU Chart – Executors – 4 Threads  36.624 seconds  ~50+% CPU Utilization
  • 15. CPU Chart – Executors – 16 Threads  16.842 seconds  Almost 100%
  • 16. CPU Chart – Fork Join  15.889 seconds  100% – Complete Utilization

Editor's Notes

  1. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  2. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  3. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  4. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  5. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  6. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  7. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  8. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  9. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  10. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  11. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  12. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  13. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  14. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources
  15. New product Version releases Test Plans, and test cases development and test execution Regression, new features & Performance testing is performed Comprehensive Release documentation- Field Release letter   Maintenance releases (Post Production releases) Primarily major or high priority bug fixes comprise in this release The approach (1) simulate the defect (2) apply the fix (3) validate the fix (4) test the impacted areas Comprehensive Release documentation- Field Release letter   General Availability (GA) in Mformation Context Definition: As per defined and agreed requirements, the MSM software operates on a common understanding as to what is included and/or excluded from a release GA decision Process: A panel of Mformation stakeholders across groups (PDM, Engineering & Deployment) review and decide go/no-go decision for GA release based on the open P1 blockers, P1 majors and P1 & P2 Normal defects in the product as on the date of release to field   GA qualification of a release New feature Testing: New test cases will be developed against the defined requirements and scope of the feature. This will be targeted for a single test pass during QA cycle. Regression: All the pre-existing MSM applicable features in a particular release will be targeted for a single test pass. This implies that all deprecated features from the product will not be tested. Product Field release letter is a comprehensive document that describes all aspects of a release The number of test cases will depend on the definitive content of new features and the regression suite. Total TCs as on date is about ~4500+ (Core MSM features + Generic features applicable to majority of the operators) Upgrade process Upgrades are applicable for existing customers only Upgrade path & scripts are seamless from MSM version 9.x onwards to latest targeted release. This is verified by MF QA during the GA release cycle On a special request, MF QA performs customer specific upgrade testing with customer DB dump and verifies customer specific ATP   Question if arise on resources>>> As on date we have 3- QA resources