Formal Process of QA and quality related certifications

1.  Formal Process of QA and quality related certifications MIM 3rd year – Sem V Abhishek Mishra – 27 Hemant Morajkar – 28 Deepak Waje – 52 Gagandeep Singh – 55 Amey Gode – 61 Jugal Anwekar – 62

2. Software Quality Assurance • It is the Process of verifying or determining whether products or services meet or exceed customer expectations • QA is a process driven approach with specific steps to help define and attain goals, the process considers design, development, production and service. • Shewhart cycle to determine QA-developed by Dr. W. Edwards Deming , it includes Plan , Do, Check, Act.

3. Formal SQA Process

4. Plan • The Key to Quality Assurance is proper validation and documentation , it starts with a detailed plan. • The plan documents the expectations of the customer, it includes the techniques, procedures and methodologies that will be used to assure timely delivery of the software that meets specified requirements within project resources.

5. Do • This includes to implement the solution or process change. • Monitor results and collect data.

6. Check • Use data to analyze the results of the change and determine whether it made a difference. • Ensure that any deviations in software or work products are documented and handled according to a documented procedure. • Record any evidence of noncompliance and reports them to management.

7. Act • Purpose is to find defects (errors) before they are passed on to another software engineering activity or released to the customer. • Software engineers (and others) conduct formal technical reviews (FTR) for software engineers. • Using informal technical reviews (walkthroughs or inspections) is an effective means for improving software quality.

8. Formal Technical Reviews - 1 • Involves 3 to 5 people (including reviewers) • Advance preparation (no more than 2 hours per person) required • Duration of review meeting should be less than 2 hours • Focus of review is on a discrete work product • Review leader organizes the review meeting at the producer's request.

9. Formal Technical Reviews - 2 • Reviewers ask questions that enable the producer to discover his or her own error (the product is under review not the producer) • Producer of the work product walks the reviewers through the product • Recorder writes down any significant issues raised during the review • Reviewers decide to accept or reject the work product and whether to require additional reviews of product or not.

10. Why do peer reviews? • To improve quality. • Catches 80% of all errors if done properly. • Catches both coding errors and design errors. • Enforce the spirit of any organization standards. • Training and insurance.

11. Formality and Timing • Formal review presentations • resemble conference presentations. • Informal presentations • less detailed, but equally correct. • Early • tend to be informal • may not have enough information • Later • tend to be more formal • Feedback may come too late to avoid rework

12. Formality and Timing • Analysis is complete. • Design is complete. • After first compilation. • After first test run. • After all test runs. • Any time you complete an activity that produce a complete work product.

13. Review Guidelines • Keep it short (< 30 minutes). • Don’t review product fragments. • Use standards to avoid style disagreements. • Let the coordinator run the meeting and maintain order.

14. Statistical Quality Assurance • Information about software defects is collected and categorized • Each defect is traced back to its cause • Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the "vital few" defect causes • Move to correct the problems that caused the defects

15. Quality related certifications ISO 9000 SEI – CMM Model People Capability Maturity Model (P-CMM) CMMi Model COPC 2000 eSCM BS 7799 Six Sigma

16. ISO 9000 • It is series of an international set of documents on quality assurance. • ISO 9001 - model for quality assurance in design/development, production, installation and servicing. • ISO 9002- model for quality production and installation. • ISO 9003 - model for quality assurance in final inspection and test. • Two supporting guidelines documents, namely ISO 9000 and ISO 9004

17. SEI – CMM Model The CMM describes an improvement path from an adhoc, immature to a mature, disciplined software process. It covers practices for planning, engineering and managing software development and mantainance. The CMM is composed of five maturity levels Each maturity level provides a layer in the foundation for continuous process improvement.

18. P - CMM It is a process at managing and developing an organisation's work force and adopts the maturity framework of Capability Maturity Model for software. It is designed to allow software organisations to integrate workforce improvement with software process improvement programs guided by SEI-CMM. P-CMM consists of five maturity levels

19. CMMi Model • The purpose of CMMi is to provide guidance for improving your organization's processes and your ability to manage the development, acquisition, and maintenance of products and services. • The CMMi helps your organization assess • its organizational maturity • process area capability • establish priorities for improvement • guide the implementation of these improvements.

20. eSCM • Caters the unique requirements of ITES/BPO services. • Focuses on assisting customers to measure the capability of service providers. • Initiates and guides service providers through the process of continuous improvement by specifying practices to be implemented.

21. Six Sigma • Six Sigma is a methodology that provides businesses with the tools to improve the capability of their business processes • Six Sigma is a rigorous and a systematic methodology that • Utilizes information and statistical analysis to measure and improve a company's operational performance. • Practices and systems by identifying and preventing 'defects' in manufacturing and service-related processes.

22. Thank you