Скачать презентацию QUALITY MANAGEMENT AT DIFFERENT STAGES OF IT PROJECT Скачать презентацию QUALITY MANAGEMENT AT DIFFERENT STAGES OF IT PROJECT

6e36d88909a9cc5777df149b54a6c0e8.ppt

  • Количество слайдов: 56

QUALITY MANAGEMENT AT DIFFERENT STAGES OF IT PROJECT & METRICS USED Harshal (133) Neeraj QUALITY MANAGEMENT AT DIFFERENT STAGES OF IT PROJECT & METRICS USED Harshal (133) Neeraj VK (131) Tushar Bonde (108) Shreekant Rane (137) Bhoumik Bhagat (104) Reagan Ceasar (109)

BASIC PHASES OF PROJECT MANAGEMENT Project Conception and Initiation Project Defining and Planning Project BASIC PHASES OF PROJECT MANAGEMENT Project Conception and Initiation Project Defining and Planning Project Execution Project Performance and Control Project Closure

PROJECT QUALITY MANAGEMENT NEERAJ VASANTKUMAR (MIM - 131) PROJECT QUALITY MANAGEMENT NEERAJ VASANTKUMAR (MIM - 131)

PROJECT QUALITY MANAGEMENT Ø Project quality management involves those activities that ensure the project PROJECT QUALITY MANAGEMENT Ø Project quality management involves those activities that ensure the project delivers a product or products that satisfies project objectives. Ø This includes Ø Ø The definition of quality policies, objectives and responsibilities, And is implemented by means such as Ø Quality Planning, Ø Quality Control, Ø Quality Assurance and Ø Quality Improvement, within the quality system.

PROJECT QUALITY MANAGEMENT Quality Management Quality Policy s tion Ac Issues Quality Planning Ev PROJECT QUALITY MANAGEMENT Quality Management Quality Policy s tion Ac Issues Quality Planning Ev al ua te Requirements Objectives Quality Assurance Quality Control Quality Improvement

PROJECT QUALITY PLANNING Ø Quality Planning is the process for PROJECT QUALITY PLANNING Ø Quality Planning is the process for "identifying which quality standards are relevant to the project and determining how to satisfy them“. Ø Quality Planning Principles: Ø Customer Satisfaction Ø Prevention over Inspection Ø Management Responsibility/Buy-In Ø Continuous Improvement.

QP: TOOLS Ø Cost Benefit Analysis Ø Benchmarking Ø Design Of Experiments Ø Cost QP: TOOLS Ø Cost Benefit Analysis Ø Benchmarking Ø Design Of Experiments Ø Cost Of Quality

QP: OUTPUTS Ø Quality Management Plan : Action plan for Quality Policy Implementation. Ø QP: OUTPUTS Ø Quality Management Plan : Action plan for Quality Policy Implementation. Ø Quality Metrics Ø Quality Checklist Ø Process Improvement Plan Ø Quality Baseline

QUALITY ASSURANCE Quality Assurance is the process for QUALITY ASSURANCE Quality Assurance is the process for "applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet the requirements“ Tools & Techniques: Quality Planning Tools: Such as Brainstorming, Flowcharts, Affinity Diagrams. Quality Audits Process Analysis Quality Control Tools

QA: OUTPUTS Requested Changes Recommended Corrective Actions Update of Organisation Process Assets Update of QA: OUTPUTS Requested Changes Recommended Corrective Actions Update of Organisation Process Assets Update of Project Management Plan

QUALITY CONTROL Quality Control is the process for QUALITY CONTROL Quality Control is the process for "monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of un-satifactory performance“ Factors to be considered Prevention vs Inspection Attribute Sampling vs Variable Sampling Special Causes vs Common Causes Tolerance vs Control Limits

QC: TOOLS & TECHNIQUES Cause & Effect (Fishbone) Diagrams, Pareto Charts Run Charts Flowcharts QC: TOOLS & TECHNIQUES Cause & Effect (Fishbone) Diagrams, Pareto Charts Run Charts Flowcharts Inspection Defect Repair Review

QC: OUTPUTS Quality Control Measurements Validated Defect Repair Updated Quality Baseline Recommended corrective and QC: OUTPUTS Quality Control Measurements Validated Defect Repair Updated Quality Baseline Recommended corrective and preventive actions Recommended defect repair Validated Project deliverables.

CONFIGURATION MANAGEMENT The purpose of Software Configuration Management is to establish and maintain the CONFIGURATION MANAGEMENT The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items. Configuration Item: A physical entity, such as a computer or router A logical entity, such as an instance of a database Conceptual, such as a Requisition Service

CM: FUNCTION'S Configuration Management Plan Independent Configuration Audit from within the project team (CTL) CM: FUNCTION'S Configuration Management Plan Independent Configuration Audit from within the project team (CTL) Assessed by Internal Quality Audit

CONFIGURATION MANAGEMENT PLAN Scope References CI Nomenclature Baselines Change Control Verification & Audits CONFIGURATION MANAGEMENT PLAN Scope References CI Nomenclature Baselines Change Control Verification & Audits

 PROJECT REPORTING AND REVIEWS TUSHAR BONDE (108) PROJECT REPORTING AND REVIEWS TUSHAR BONDE (108)

PROJECT REPORTING AND REVIEWS Project reporting is element of the project controlling process and PROJECT REPORTING AND REVIEWS Project reporting is element of the project controlling process and project governance. To ensure that the objectives of the project are being met by monitoring and measuring progress regularly to determine variances from the plan. Project Report Components Agenda Scope and Objective of the report/Project Milestones/Phases Resources Budget Current state Future/Next Action Items Summary

PROJECT REPORTING AND REVIEWS TYPES OF PROJECT REPORT 1. Status Report 2. Risk Register PROJECT REPORTING AND REVIEWS TYPES OF PROJECT REPORT 1. Status Report 2. Risk Register 3. Issue Log 4. Executive Summary

PROJECT REPORTING AND REVIEWS PROJECT REVIEWS – Evaluation of project or deliverable 1. Phase PROJECT REPORTING AND REVIEWS PROJECT REVIEWS – Evaluation of project or deliverable 1. Phase Review 2. Peer Review 3. Audits 4. Post Implementation Review 5. Decision Point 6. Formal/informal Review

PROJECT REPORTING AND REVIEWS PROJECT REPORTING AND REVIEWS

PROJECT PROCUREMENT MANAGEMENT PROCESS & SUBCONTRACTOR MANAGEMENT SHREEKANT RANE (MIM - 137) PROJECT PROCUREMENT MANAGEMENT PROCESS & SUBCONTRACTOR MANAGEMENT SHREEKANT RANE (MIM - 137)

PROJECT PROCUREMENT MANAGEMENT PROCESS Ø Project Procurement Process is a method for establishing relationships PROJECT PROCUREMENT MANAGEMENT PROCESS Ø Project Procurement Process is a method for establishing relationships between an organization’s purchasing department and external suppliers to order, receive, review and approve all the procurement items necessary for project execution. . Ø Procurement management is a form of management, where goods and services are acquired from a different organization or firm. Ø Procurement management is known to help an organization to save much of the money spent when purchasing goods and services from outside.

PROJECT PROCUREMENT MANAGEMENT PROCESS THE KEY STEPS Specification The purchasing department communicates with the PROJECT PROCUREMENT MANAGEMENT PROCESS THE KEY STEPS Specification The purchasing department communicates with the project manager on the specifications for the products to be procured, Selection The purchasing department looks for potential vendors who could supply the necessary products according to the procurement items list. Contracting The purchasing department communicates with the selected vendors and concludes a procurement contract/agreement. Control The purchasing department takes control of the procurement process to ensure on-time delivery of the purchased products and their appropriateness. Measurement The purchasing department in cooperation with the project manager creates a system of KPIs for measuring the process performance.

SUBCONTRACTOR MANAGEMENT What is a contract/subcontract? Prime Recipient/Contract An agreement between two or more SUBCONTRACTOR MANAGEMENT What is a contract/subcontract? Prime Recipient/Contract An agreement between two or more parties that creates an obligation to perform a particular duty The prime recipient is the organization/entity that is the direct recipient of the sponsor’s funds/contract and in this capacity assumes a number of responsibilities, including management of subcontracts Subcontract Any contract or agreement to perform work in support of or on behalf of a prime The subcontract provisions are influenced by the prime’s contract Any modification to the provisions in the statement of work by a subcontractor will require approval from the prime

CHARACTERISTICS OF EFFECTIVE SUBCONTRACT ARRANGEMENTS Transparency and clarity about which subcontractors are being used CHARACTERISTICS OF EFFECTIVE SUBCONTRACT ARRANGEMENTS Transparency and clarity about which subcontractors are being used Formal agreements between prime and sub contractors Subcontractors have high degree of awareness of prime’s methods of working and client’s expectations Subcontractors are allowed to attend client/contractor progress meetings Subcontractors are encouraged and rewarded for innovation Adherence to formal procedures for selection, surveillance plan, following the statement of work, etc. Prime receives/reviews copies of subcontractor progress meetings, postinspection reports, accreditation, etc. Subcontractor performance is a standing agenda item in meetings

METRICS Reagan Caesar (14 -I-109) METRICS Reagan Caesar (14 -I-109)

WHAT ARE METRICS? Software process and project metrics are quantitative measures They offer insight WHAT ARE METRICS? Software process and project metrics are quantitative measures They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework Basic quality and productivity data are collected These data are analyzed, compared against past averages, and assessed The goal is to determine whether quality and productivity improvements have occurred The data can also be used to pinpoint problem areas Remedies can then be developed and the software process can be improved

USES OF MEASUREMENT Can be applied to the software process with the intent of USES OF MEASUREMENT Can be applied to the software process with the intent of improving it on a continuous basis Can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control Can be used to help assess the quality of software work products and to assist in tactical decision making as a project proceeds

REASONS TO MEASURE To characterize in order to 1. Gain an understanding of processes, REASONS TO MEASURE To characterize in order to 1. Gain an understanding of processes, products, resources, and environments 2. Establish baselines for comparisons with future assessments To evaluate in order to 1. Determine status with respect to plans To predict in order to 1. Gain understanding of relationships among processes and products 2. Build models of these relationships To improve in order to 1. Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance

METRICS IN THE PROCESS DOMAIN METRICS IN THE PROCESS DOMAIN

METRICS IN THE PROCESS DOMAIN Process metrics are collected across all projects and over METRICS IN THE PROCESS DOMAIN Process metrics are collected across all projects and over long periods of time They are used for making strategic decisions The intent is to provide a set of process indicators that lead to long-term software process improvement The only way to know how/where to improve any process is to Measure specific attributes of the process Develop a set of meaningful metrics based on these attributes Use the metrics to provide indicators that will lead to a strategy for improvement

METRICS IN THE PROCESS DOMAIN We measure the effectiveness of a process by deriving METRICS IN THE PROCESS DOMAIN We measure the effectiveness of a process by deriving a set of metrics based on outcomes of the process such as Errors uncovered before release of the software Defects delivered to and reported by the end users Work products delivered Human effort expended Calendar time expended Conformance to the schedule Time and effort to complete each generic activity

ETIQUETTE OF PROCESS METRICS Use common sense and organizational sensitivity when interpreting metrics data ETIQUETTE OF PROCESS METRICS Use common sense and organizational sensitivity when interpreting metrics data Provide regular feedback to the individuals and teams who collect measures and metrics Don’t use metrics to evaluate individuals Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Never use metrics to threaten individuals or teams Metrics data that indicate a problem should not be considered “negative” Such data are merely an indicator for process improvement Don’t obsess on a single metric to the exclusion of other important metrics

METRICS IN THE PROJECT DOMAIN METRICS IN THE PROJECT DOMAIN

METRICS IN THE PROJECT DOMAIN Project metrics enable a software project manager to 1. METRICS IN THE PROJECT DOMAIN Project metrics enable a software project manager to 1. Assess the status of an ongoing project 2. Track potential risks 3. Uncover problem areas before their status becomes critical 4. Adjust work flow or tasks 5. Evaluate the project team’s ability to control quality of software work products Many of the same metrics are used in both the process and project domain Project metrics are used for making tactical decisions - They are used to adapt project workflow and technical activities

METRICS IN THE PROJECT DOMAIN The first application of project metrics occurs during estimation METRICS IN THE PROJECT DOMAIN The first application of project metrics occurs during estimation - Metrics from past projects are used as a basis for estimating time and effort As a project proceeds, the amount of time and effort expended are compared to original estimates As technical work commences, other project metrics become important - Production rates are measured (represented in terms of models created, review hours, function points, and delivered source lines of code) - Error uncovered during each generic framework activity (i. e, communication, planning, modeling, construction, deployment) are measured

METRICS IN THE PROJECT DOMAIN Project metrics are used to Minimize the development schedule METRICS IN THE PROJECT DOMAIN Project metrics are used to Minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks Assess product quality on an ongoing basis and, when necessary, to modify the technical approach to improve quality In summary As quality improves, defects are minimized As defects go down, the amount of rework required during the project is also reduced As rework goes down, the overall project cost is reduced

SOFTWARE MEASUREMENT SOFTWARE MEASUREMENT

CATEGORIES OF SOFTWARE MEASUREMENT Two categories of software measurement Direct measures of the I. CATEGORIES OF SOFTWARE MEASUREMENT Two categories of software measurement Direct measures of the I. Software process (cost, effort, etc. ) II. Software product (lines of code produced, execution speed, defects reported over time, etc. ) Indirect measures of the Software product (functionality, quality, complexity, efficiency, reliability, maintainability, etc. ) Project metrics can be consolidated to create process metrics for an organization

SIZE-ORIENTED METRICS Derived by normalizing quality and/or productivity measures by considering the size of SIZE-ORIENTED METRICS Derived by normalizing quality and/or productivity measures by considering the size of the software produced Thousand lines of code (KLOC) are often chosen as the normalization value Metrics include Errors per KLOC - Errors person-month 2. Defects per KLOC - KLOC person-month 1. Dollars per KLOC - Dollars per page of documentation 4. Pages of documentation per KLOC 3.

SIZE-ORIENTED METRICS Size-oriented metrics are not universally accepted as the best way to measure SIZE-ORIENTED METRICS Size-oriented metrics are not universally accepted as the best way to measure the software process Opponents argue that KLOC measurements Are dependent on the programming language Penalize well-designed but short programs Cannot easily accommodate nonprocedural languages Require a level of detail that may be difficult to achieve

FUNCTION-ORIENTED METRICS Function-oriented metrics use a measure of the functionality delivered by the application FUNCTION-ORIENTED METRICS Function-oriented metrics use a measure of the functionality delivered by the application as a normalization value Most widely used metric of this type is the function point: FP = count total * [0. 65 + 0. 01 * sum (value adj. factors)] Function point values on past projects can be used to compute, for example, the average number of lines of code per function point (e. g. , 60)

FUNCTION POINT CONTROVERSY Like the KLOC measure, function point use also has proponents and FUNCTION POINT CONTROVERSY Like the KLOC measure, function point use also has proponents and opponents Proponents claim that FP is programming language independent FP is based on data that are more likely to be known in the early stages of a project, making it more attractive as an estimation approach Opponents claim that FP requires some “sleight of hand” because the computation is based on subjective data Counts of the information domain can be difficult to collect after the fact FP has no direct physical meaning…it’s just a number

RECONCILING LOC AND FP METRICS Relationship between LOC and FP depends upon The programming RECONCILING LOC AND FP METRICS Relationship between LOC and FP depends upon The programming language that is used to implement the software The quality of the design FP and LOC have been found to be relatively accurate predictors of software development effort and cost However, a historical baseline of information must first be established LOC and FP can be used to estimate object-oriented software projects However, they do not provide enough granularity for the schedule and effort adjustments required in the iterations of an evolutionary or incremental process

LOC PER FUNCTION POINT LOC PER FUNCTION POINT

ESTABLISHING A METRICS BASELINE By establishing a metrics baseline, benefits can be obtained at ESTABLISHING A METRICS BASELINE By establishing a metrics baseline, benefits can be obtained at the software process, product, and project levels The same metrics can serve many masters The baseline consists of data collected from past projects Baseline data must have the following attributes Data should be collected for as many projects as possible Measures must be consistent (e. g. , a line of code must be interpreted consistently across all projects) Data must be reasonably accurate (guesses should be avoided) Past applications should be similar to the work that is to be estimated After data is collected and metrics are computed, the metrics should be evaluated and applied during estimation, technical work, project control, and process improvement

GETTING STARTED WITH METRICS Understand your existing process Ø Define the goals to be GETTING STARTED WITH METRICS Understand your existing process Ø Define the goals to be achieved by establishing a metrics program Ø Ø Identify metrics to achieve those goals Keep the metrics simple Ø Be sure the metrics add value to your process and product Ø Identify the measures to be collected to support those metrics Ø

METRICS (contd. ) Bhoumik Bhagat (14 -I-104) METRICS (contd. ) Bhoumik Bhagat (14 -I-104)

OBJECT-ORIENTED METRICS Number of scenario scripts (NSS) Number of key classes (NKC) Number of OBJECT-ORIENTED METRICS Number of scenario scripts (NSS) Number of key classes (NKC) Number of support classes (e. g. UI classes, database access classes, computations classes, etc. ) Average number of support classes per key class Number of subsystems (NSUB)

USE CASE-ORIENTED METRICS Describe (indirectly) user-visible functions and features in language independent manner Number USE CASE-ORIENTED METRICS Describe (indirectly) user-visible functions and features in language independent manner Number of use case is directly proportional to LOC size of application and number of test cases needed However use cases do not come in standard sizes and use as a normalization measure is suspect Use case points have been suggested as a mechanism for estimating effort

WEBAPP PROJECT METRICS Number of static Web pages (Nsp) Number of dynamic Web pages WEBAPP PROJECT METRICS Number of static Web pages (Nsp) Number of dynamic Web pages (Ndp) Customization index: C = Nsp / (Ndp + Nsp) Number of internal page links Number of persistent data objects Number of external systems interfaced Number of static content objects Number of dynamic content objects Number of executable functions

SOFTWARE QUALITY METRICS Factors assessing software quality come from three distinct points of view SOFTWARE QUALITY METRICS Factors assessing software quality come from three distinct points of view (product operation, product revision, product modification). Software quality factors requiring measures include correctness (defects per KLOC) maintainability (mean time to change) integrity (threat and security) usability (easy to learn, easy to use, productivity increase, user attitude) Defect removal efficiency (DRE) is a measure of the filtering ability of the quality assurance and control activities as they are applied through out the process framework DRE = E / (E + D) E D= number of defects found after work product delivery = number of errors found before delivery of work product

INTEGRATING METRICS WITH SOFTWARE PROCESS Many software developers do not collect measures. Without measurement INTEGRATING METRICS WITH SOFTWARE PROCESS Many software developers do not collect measures. Without measurement it is impossible to determine whether a process is improving or not. Baseline metrics data should be collected from a large, representative sampling of past software projects. Getting this historic project data is very difficult, if the previous developers did not collect data in an on-going manner.

ARGUMENTS FOR SOFTWARE METRICS If you don’t measure you have no way of determining ARGUMENTS FOR SOFTWARE METRICS If you don’t measure you have no way of determining any improvement By requesting and evaluating productivity and quality measures software teams can establish meaningful goals for process improvement Software project managers are concerned with developing project estimates, producing high quality systems, and delivering product on time Using measurement to establish a project baseline helps to make project managers tasks possible

THANK YOU !!! THANK YOU !!!