Software Project Management Matrics. Complied by Heng Sovannarith

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Software Project Management Matrics. Complied by Heng Sovannarith heng_sovannarith@yahoo.com"

Transcription

1 Software Project Management Matrics Complied by Heng Sovannarith

2 Introduction Hardware is declining while software is increasing. Software Crisis: Schedule and cost estimates -> Inaccurate Software poor quality A productivity rate that is increasing more slowly than the demand for software.

3 Why we need Software Metrics The software crisis must be addressed and, to extent possible, resolved. Accurate schedule and cost estimates, better quality products, and higher productivity. Use software matrices can help better management result, both short time and long term,

4 Software Metrics The terms measure, measurement, and metrics are often used interchangeable. We CANNOT Control what we CANNOT Measure -- Tom DeMarco, American Software Engineer.

5 Software Metrics (cont.) A software metric is a technique or method that applies software measurements to a class of software engineering objects to achieve a predefined goal The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments.

6 Software Metrics (cont.) More than 300 metrics have been defined. How can you judge the two images? What will you to judge them?

7 Types of Metrics ( Types of Measured data) Nominal - Categories -- Database programming, operating system... Ordinal - Ranking -- programmer experience level maybe measured as low, medium, or high. Interval - Differences. For example... complexity is 4 unit more complex than a program with complexity f 2. Ratio scale - example. a program which have 2000 line of code is twice as large as a program of 1,000 line...

8 Characteristics of a Metric Object of measurement Products, processes and projects Purpose of measurement (Measurable Characterization, assessment, evaluation, prediction Source of measurement Measured property Context of measurement

9 Who benefit from Measurement? Managers What does each process cost? How productivity is the staff? How good is the code being developed? Will the user be satisfied with the product? How can we improve? Engineers Are the requirement testable? Have we found all the failures? Have we met our product or process goals? What can we predict about our software product in the future?

10 Software Metrics Categories Product metrics Used to measure aspects of artifacts delivered to the customer Information flow metrics, function points, complexity Process metrics Used to measure aspects of the development and maintenance process example: time to correct defect, number of components changed per correction

11 Software Metrics Categories (cont.) Design metrics : Design metrics enable you to decide how much you have deviated from the requirements of the project. Maintenance metrics These measure the progress of a maintenance project.

12 Product Metrics Analysis done using the product metrics can provide you an insight into the quality of work done by the development teams. Product metrics trace and measure the quality of a deliverable in different phases. A set of metrics measures the quality and timeliness of the deliverable.

13 Product Metrics (cont.) To measure the metric of source code, you can use the format displayed

14 Product Metrics (cont.) Effectiveness of a deliverable is measured in terms of the quantity of the deliverable completed and the number of quality goals achieved. You can use the following formula to calculate effectiveness of a deliverable:

15 Product Metrics (cont.) For example, 80 percent of source code is completed and 90 percent of the quality goals are achieved in developing that source code. Effectiveness = 80 * 90/100 Effectiveness = 72

16 Design Metric Complexity is a characteristic measured during this phase. Complexity can be measured for the structure, data components, and the interface design of a software program. Complexity can affect the size, testability, and effort spent on developing and testing the modules of a project.

17 Design Metric (cont.) The measure of the complexity of a software design is called a design metric. Design metrics are seldom used in organizations because organizations find it time-consuming to analyze their results. Moreover, design metrics are difficult to implement.

18 Design Metric (cont.) There can be many varieties of design metric. One variety is architecture design metrics It address the three types of complexities of a software program. Structural complexity Eg. a module invoked by a module parent -> increase the complexity Data complexity Input and output variable System complexity Combine structural complexity and data complexity

19 Project Metrics Project metrics are specific to the actual execution of a project. They enable you to execute a project with a systematic and technical approach. Project metrics can help you avoid project delays. You can also use them to avoid and mitigate project risks.

20 Project Metrics (cont.) Project metrics are also used to assess the quality of a finished product on a periodic basis. Examples of project metrics are the metrics that measure the size, complexity, or the time and effort spent on a project.

21 Project Metrics (cont.) Six important project metrics are commonly used in an organization. Effort the amount of effort required to complete a project Productivity Measure human effort according to the number of hours spend on work. Cost -- measures the planned versus actual expense incurred on a project Size (important) -- calculated for an entire project and not for any particular phase of a project. Defects Defects are errors that occur in a work product The number of defects defines the quality of a project. Testing measure the number of test cases required to test software. Test case is a specification that needs to be executed to test a particular module in a software program.

22 Effort Metrics The effort metric enable you to determine the amount of effort to complete a project. It is calculated in person-month (manmonths). A person-month is a mount of effort required to complete work in a month. Person-month is a measure of work effort. Other similar measures are person-day and person-year.

23 Effort Metrics Effort Metrics Analysis Design Coding Testing Total Planned effort (personmonths) Planned effort (personmonths) Planned effort (personmonths)

24 Effort Metrics (cont.) If a project will take 2 months to finish with 3 people working full time on it, the project requires 2*3 = 6 personmonth effort. If an employee worked 20 days on a project, his contribution to the project is 1*20/30 = personmonth. (Note that month is considered 30 days in such calculations.) Effort percentage question isn't clear but if it means the percentage effort put in by an employee towards a certain project, just calculate his person-months and divide that by total person-months for that project.

25 Productivity Metric What is Productivity? Amount (or value) of output per unit of input (e.g., cars per work hours) Why do we care? To make the right resource allocations & have the right policies Obviously measuring personal productivity is important, and the reasons why are obvious. If you do not know how your staff is doing, then how can you truly know the inner workings of your own company? Staff discontent can put your company in serious jeopardy, while on the other hand, high staff productivity can be your best company asset.

26 Productivity Metric (cont.) The definition of productivity is the output-input ratio within a time period with due consideration for quality. Productivity = outputs/inputs (within a time period, quality considered) The formula indicates that productivity can be improved by (1) by increasing outputs with the same inputs, (2) by decreasing inputs but maintaining the same outputs, or (3) by increasing outputs and decreasing inputs change the ratio favorably. Software Productivity = Function Points / Inputs

27 Productivity Metric The effort in performing an FP (Function Point) of work in an hour is called productivity. To calculate productivity, you first determine the total amount of FP for the SW project. Measurements that help determine how to make more products with fewer resources, such as producing the most parts with the fewest numbers of employees.

28 Productivity Metric Function Points measure software size by quantifying the functionality provided to the user based solely on logical design and functional specifications Has gained acceptance in terms of productivity (for example FP/year) and quality (defects/fp)

29 Productivity Metric (cont.)

30 Productivity Metric (cont.) Measurement parameter Weighting factor Simple Average Complex Number of user inputs Number of user outputs Number of user inquiries Number of files Number of external interfaces

31 Productivity Metric (cont.)

32 Productivity Metric (cont.)

33 Productivity Metric (cont.) To calculate accurate productivity for a particular phase, you need type of data: Actual effort expressed in person hours. Actual size of the project in FP Metric Analysis Design Coding Testing Total Productivity in hours/fp Planned Actual Difference (+/-)

34 Cost metrics A cost metric measure the planned vs actual expense incurred on a project. An important component of the cost metric is the cost of resources (human resource and material resources)

35 Cost Metrics (cont.) Metrics Analysis Design Coding Testing Total Cost in USD Resources Planned 40, , , , ,000 Communi cation Actual 55, , , , ,000 Planned 10,000 7,000 1,000 1,000 19,000 Actual 20,000 4, ,700 Total Actual 75, , , , ,700 Total deviation in percentage (actual planned/planned * 100)

36 Size Metrics Size metric is a calculated for an entire project and not for any particular phase of a project. The size of a project may vary with respect to the changes required by the customer. The size metric directly affects effort, testing, and productivity metrics of a project. There are two main components of the size metric: Change in the required effort due to change in project size Percentage growth in project size

37 Size Metrics (cont.) Line of Code: It is one of the earliest and simpler metrics for calculating the size of computer program. It is generally used in calculating and comparing the productivity of programmers. Function Count: The size of a large software product can be estimated in better way through a larger unit called module. A module can be defined as segment of code which may be compiled independently. For example, let a software product require n modules. It is generally agreed that the size of module should be about line of code. Therefore size estimate of this Software product is about n x 60 line of code.

38 Size Metric (cont.) Token Count: Operands and operator of any computer language is called tokens. Any symbol or keyword in a program that specifies an algorithmic action is considered an operator, while a symbol used to represent data is considered an operand. In terms of the total tokens used, the size of the program can be expressed as N=N1+N2 Here, N1: count of total occurrence of operators N2: count of total occurrence of operands

39 Size Metrics (cont.) Size in FP Metric Total Size Planned 100 Size Actual 120 Change in size +20 Growth of size in % 20

40 Defects Metric The number of defects defines the quality of a project. If the number of defects is large, the quality of the product is inferior. Defects can occur during any phase of the SDLC. Defects not defected in a particular phase continue to be present during the subsequent phases in the SDLC.

41 Defects Metric (cont.) Very useful as measure of organizational capability to produce defect-free outputs Can be compared with other organizations in the same domain Outlier information useful to spot problem projects and problem components Can be used in-process, if comparison is with defect densities of other projects in same phase If much lower, may indicate defects not being found If much higher, may indicate poor quality of work (In other words, need to go behind the numbers to find out what is really happening. Metrics can only provide triggers)

42 Defects Metric (cont.) Defect evaluation is driven by the need for Defect prevention. Understanding defects and metrics surrounding them will help eliminate defect injection and rework. Most metrics won t mean anything at first until we can establish a baseline to compare to. This is digging deeper into the data available and the resources involved finding out why a defect has entered the system. Examples could be Developer Error, Missing Tests/Requirements, Unclear Requirements, or Environmental (Client/Server) or any of the reasons. It s important to identify it correctly to be able to look for patterns or repeats of specific reason types.

43 Defects Metric (cont.) This will help to identify problem areas and propose solutions to resolve.

44 Defects Metric (cont.)

45 Defects Metric (cont.) Errors Defects in the human thought process made while trying to understand given information, to solve problems, or to use methods and tools Faults Concrete manifestations of errors within the software One error may cause several faults Various errors may cause identical faults Failures Departures of the operational software system behavior from user expected requirements A particular failure may be caused by several faults

46 Defects Metric (cont.) Severe defects critically affect the functionality of a product. Major defects logically affect the functionality of a product. A minor defect is a slight defect that may act as an irritant for users but does not disturb the functionality of the application.

47 Defects Metric (cont.) Defect density Number of defects per size of the software project Size of project measured in LOC or Function Points Useful metric in determining if a software release is ready for delivery to the customer Defect density in released code ( defect density at release ) is a good measure of organizational capability Defects found after release / size of released software Can only compare across similar projects

48 Defects Metric (cont.) Pair Programming Two software developers work together at one computer One developer is coding, the other developer is reviewing Potential to find defects earlier because the code is under constant review On average, PP leaves 15% fewer defects than conventional methods

49 Defect Metrics Metric Analysis Design Coding Testing Total Defects per KLOC Severe Planned (less than equal to) Actual Major Planned (less than equal to) Actual Minor Planned (less than equal to) Actual

50 Defect Metrics (cont.) Prevention Methods Introduced by Michael Fagan in the 1970s at IBM Involves reviewing a software work product by a group of trained individuals Reviewers review the software code changes and relay comments back to the author for clarification or further work. Initial costs are in training individuals on the process. Software developers are reviewing instead of coding.

51 Defect Metrics (cont.) Figure is a cost analysis of defect prevention Clearly, defects found earlier saves money Team can be set up dedicated to the defect prevention activities

52 Defect Metrics (cont.) Personal Work Experience Software development experience of 2 years Software test experience of 3 years Use peer reviews to minimize software defects Run unit tests and integration tests with test team witness Been a part of 2 major software releases and several patch releases Tough to anticipate all behaviors of system

53 Testing Metrics (cont.) Test metrics provides the visibility into the readiness of the product, and gives clear measurement of the quality and completeness of the product. Testing metric is used to track actual testing progress against plan and therefore to be able to be proactive upon early indications that testing activity is falling behind. Indicators that show the quality of the software under test and the effectiveness of the testing activities.

54 Testing Metrics (cont.) Test metrics can give us the information about the software quality, and help the PM to make decision. Metrics are the numerical data which will help us to measure the test effectiveness.

55 Testing Metrics (cont.) Test Metrics is a process of measuring the Software Testing Process with respect to the Actual Test Plan in the organizations. Based on the feedback, the organizations will improve the testing process that they are following. Test metrics are essentially data which provide you insight into the status of either 1) your testing itself or 2) the product under test.

56 Testing Metrics (cont.) The first is a metric which provides such insight as how far through your testing are you (how many test cases exist, how many have you executed, how many remain, what's your execution rate, what is your projected end date). The second is a metric providing insight into the state of the product under test. How many open bugs are there? How many resolved bugs? How many bugs are being opened per day? Per test pass? Per test case? Is the rate of bugs being resolved higher than the rate of bugs being opened? How many bugs are 'stale' (older than a certain number of days?), etc.

57 Testing Metrics (cont.) Test Metrics is measuring the Testing Activities. Test Metrics are varying from company. Every company following there own metrics. In some companies, they following metrics are: Number of Test Cases Executed Number of Test Cases Passed Number of Test Cases Failed Total Number of Defects Raised. Number of Defects Raised in SIT (System Integrated Test) Number of Defects Raised in UAT (User Accept Test)

58 Testing Metrics (cont.) The testing metric is also used to measure the number of test case required to test SW. Test case is a specification that needs to be executed to test a particular module in a SW program. There are a separate test cases for integration testing and unit testing: Integration testing refers to the overall black box testing of the entire SW project. In contrast, unit testing refers to testing individual modules of a SW project.. Every testing project should be measured for its schedule and the quality requirement for its release.

59 Why do we need the test metric?

60 Testing Metrics (cont.) Testing Metrics Coding Test cases per FP Planned 5 Actual 4

61 Testing Metrics Test case Defect Density The number of errors found in test cases v/s test cases developed and executed ( Defective Test cases / Total Test cases ) * 100 Example : Total no of test cases developed is 1360, total test cases executed is 1280, total no of test cases passed is 1065, total no of test scripts failed is 215 So Test case Defect Density is : 215 X = 16.8 % 1280 The 16.8 % value can also be called as Test Case Efficiency % which depends upon the total number of Test cases which found defects

62 Process Metrics 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

63 Process Metrics 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

64 Maintenance Metrics Software Maintenance is the general process of changing a system after it has been delivered. The changes made to the software may be simple changes to correct the code errors, more extensive changes to correct design errors, or significant enhancements to correct specification errors or accommodate new requirement.

65 A Typical Maintenance Flow Customer nominal path Help desk Written MR s Proposed M. R. s Approved M. R. s Maintenance engineer Current source & documentation Change control board Modified source & documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

66 Types of Maintenance Fixing Enhancing Corrective defect identification and removal Adaptive changes resulting from operating system, hardware or DBMS changes Perfective changes resulting from user requests Preventative changes made to the software to make it more maintainable

67 Maintenance Metrics (cont.) When development of a software product is complete and it is released to the market, it enters the maintenance phase of its life cycle. During this phase the defect arrivals by time interval and customer problem calls (which may or may not be defects) by time interval are the de facto metrics. However, the number of defect or problem arrivals is largely determined by the development process before the maintenance phase. Not much can be done to alter the quality of the product during this phase.

68 Maintenance Metrics (cont.) What can be done during the maintenance phase is to fix the defects as soon as possible and with excellent fix quality. Such actions, although still not able to improve the defect rate of the product, can improve customer satisfaction to a large extent. The following metrics are therefore very important: Fix backlog and backlog management index Fix response time and fix responsiveness Percent delinquent fixes Fix quality

69 Fix Backlog and Backlog Management Index It is related to both the rate of defect arrivals and the rate at which fixes for reported problems become available. It is a simple count of reported problems that remain at the end of each month or each week. Using it in the format of a trend chart, this metric can provide meaningful information for managing the maintenance process.

70 Fix Backlog and Backlog Management Index (cont.) Another metric to manage the backlog of open, unresolved, problems is the backlog management index (BMI). As a ratio of number of closed, or solved, problems to number of problem arrivals during the month, if BMI is larger than 100, it means the backlog is reduced. If BMI is less than 100, then the backlog increased. More investigation and analysis should be triggered when the value of BMI exceeds the control limits. Of course, the goal is always to strive for a BMI larger than 100.

71

72 Fix response time and fix responsiveness Most organisations have established guidelines on the time limit within the fixes should be available for the reported defects Severe problems are usually being as soon as possible, less severe has more relaxed time The fix response time metric is usually calculated for all problems as follows: Mean time of all problems from open to closed

73 Fix response time and fix responsiveness (cont.) Sometimes there are less severe problems that customers just ignore, so the problem remains open for a long time ->distortion of mean time ->in these cases, medians should be used instead of mean time values Idea: short time in fix process leads to customer satisfaction and determines how good the process is in this field

74 Percent Delinquent Fixes The mean (or median) response time metric is a central tendency measure. A more sensitive metric is the percentage of delinquent fixes. For each fix, if the turnaround time greatly exceeds the required response time, then it is classified as delinquent:

75 Fix Quality Fix quality or the number of defective fixes is another important quality metric for the maintenance phase. From the customer's perspective, it is bad enough to encounter functional defects when running a business on the software. It is even worse if the fixes turn out to be defective. A fix is defective if it did not fix the reported problem, or if it fixed the original problem but injected a new defect.

76 Fix Quality (cont.) The metric of percent defective fixes is simply the percentage of all fixes in a time interval (e.g., 1 month) that are defective. This metric, therefore, should be a straight count of the number of defective fixes. The quality goal for the maintenance process, of course, is zero defective fixes without delinquency.

77 Steps To Create Metrics Define the goal of a metric Identify the requirement of a metric (Human, Data Collection Technique, Methodology) Determine the baseline figure of the metric Review the metric created

78 End

79 References Pok, Leakmony. Software Engineering, Phnom Penh, RUPP, Kan, Stephen H., Metrics and Models in Software Quality Engineering (2nd Edition), Boston: Addison-Wesley, Sommerville, I. Software Engineering (9th edition), Pearson, 2010, Other resources

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management International Journal of Soft Computing and Engineering (IJSCE) A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management Jayanthi.R, M Lilly Florence Abstract:

More information

Fundamentals of Measurements

Fundamentals of Measurements Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role

More information

Software Engineering Compiled By: Roshani Ghimire Page 1

Software Engineering Compiled By: Roshani Ghimire Page 1 Unit 7: Metric for Process and Product 7.1 Software Measurement Measurement is the process by which numbers or symbols are assigned to the attributes of entities in the real world in such a way as to define

More information

Measurement Information Model

Measurement Information Model mcgarry02.qxd 9/7/01 1:27 PM Page 13 2 Information Model This chapter describes one of the fundamental measurement concepts of Practical Software, the Information Model. The Information Model provides

More information

TEST METRICS AND KPI S

TEST METRICS AND KPI S WHITE PAPER TEST METRICS AND KPI S Abstract This document serves as a guideline for understanding metrics and the Key performance indicators for a testing project. Metrics are parameters or measures of

More information

Chap 1. Software Quality Management

Chap 1. Software Quality Management Chap. Software Quality Management.3 Software Measurement and Metrics. Software Metrics Overview 2. Inspection Metrics 3. Product Quality Metrics 4. In-Process Quality Metrics . Software Metrics Overview

More information

An Introduction to. Metrics. used during. Software Development

An Introduction to. Metrics. used during. Software Development An Introduction to Metrics used during Software Development Life Cycle www.softwaretestinggenius.com Page 1 of 10 Define the Metric Objectives You can t control what you can t measure. This is a quote

More information

Testing Metrics. Introduction

Testing Metrics. Introduction Introduction Why Measure? What to Measure? It is often said that if something cannot be measured, it cannot be managed or improved. There is immense value in measurement, but you should always make sure

More information

Darshan Institute of Engineering & Technology Unit : 7

Darshan Institute of Engineering & Technology Unit : 7 1) Explain quality control and also explain cost of quality. Quality Control Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work

More information

Measurement and Metrics Fundamentals. SE 350 Software Process & Product Quality

Measurement and Metrics Fundamentals. SE 350 Software Process & Product Quality Measurement and Metrics Fundamentals Lecture Objectives Provide some basic concepts of metrics Quality attribute metrics and measurements Reliability, validity, error Correlation and causation Discuss

More information

Measuring and Managing In-process Software Quality Stephen H. Kan IBM Rochester, Minnesota USA skan@us.ibm.com

Measuring and Managing In-process Software Quality Stephen H. Kan IBM Rochester, Minnesota USA skan@us.ibm.com Measuring and Managing In-process Software Quality Stephen H. Kan IBM Rochester, Minnesota USA skan@us.ibm.com Abstract Using in-process metrics to determine the quality status of a software project under

More information

Unit 11: Software Metrics

Unit 11: Software Metrics Unit 11: Software Metrics Objective Ð To describe the current state-of-the-art in the measurement of software products and process. Why Measure? "When you can measure what you are speaking about and express

More information

Topics. Project plan development. The theme. Planning documents. Sections in a typical project plan. Maciaszek, Liong - PSE Chapter 4

Topics. Project plan development. The theme. Planning documents. Sections in a typical project plan. Maciaszek, Liong - PSE Chapter 4 MACIASZEK, L.A. and LIONG, B.L. (2005): Practical Software Engineering. A Case Study Approach Addison Wesley, Harlow England, 864p. ISBN: 0 321 20465 4 Chapter 4 Software Project Planning and Tracking

More information

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or

More information

FUNCTION POINT ANALYSIS: Sizing The Software Deliverable. BEYOND FUNCTION POINTS So you ve got the count, Now what?

FUNCTION POINT ANALYSIS: Sizing The Software Deliverable. BEYOND FUNCTION POINTS So you ve got the count, Now what? FUNCTION POINT ANALYSIS: Sizing The Software Deliverable BEYOND FUNCTION POINTS So you ve got the count, Now what? 2008 Course Objectives The primary webinar objectives are to: Review function point methodology

More information

Measure for Measure: A Practical Quality Management Program. Robert Altizer and Don Downin Motorola Semiconductor Products Sector Tempe, AZ

Measure for Measure: A Practical Quality Management Program. Robert Altizer and Don Downin Motorola Semiconductor Products Sector Tempe, AZ Measure for Measure: A Practical Management Program Robert Altizer and Don Downin Motorola Semiconductor Products Sector Tempe, AZ 1 Attempts to Manage With Metrics Organizations collect and report standard

More information

Effort and Cost Allocation in Medium to Large Software Development Projects

Effort and Cost Allocation in Medium to Large Software Development Projects Effort and Cost Allocation in Medium to Large Software Development Projects KASSEM SALEH Department of Information Sciences Kuwait University KUWAIT saleh.kassem@yahoo.com Abstract: - The proper allocation

More information

Software Quality. Software Quality Assurance and Software Reuse. Three Important Points. Quality Factors

Software Quality. Software Quality Assurance and Software Reuse. Three Important Points. Quality Factors Software Quality Software Quality Assurance and Software Reuse Peter Lo Conformance to explicitly-stated functional and performance requirements, explicitly-documented development standards, and implicit

More information

Software Quality Data Part 1: Basic and Derived Metrics

Software Quality Data Part 1: Basic and Derived Metrics Abstract We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? This is the first of three papers in which we will

More information

Project Scorecard Template

Project Scorecard Template Project Scorecard Template 1. Identify criteria for success: Review the objectives and deliverables in the Project Definition, as well as any other existing information that is relevant to the project.

More information

Benefits of Test Automation for Agile Testing

Benefits of Test Automation for Agile Testing Benefits of Test Automation for Agile Testing Manu GV 1, Namratha M 2, Pradeep 3 1 Technical Lead-Testing Calsoft Labs, Bangalore, India 2 Assistant Professor, BMSCE, Bangalore, India 3 Software Engineer,

More information

Orthogonal Defect Classification in Agile Development

Orthogonal Defect Classification in Agile Development Orthogonal Defect Classification in Agile Development Monika Jagia, IBM Software Group India, monika.jagia@in.ibm.com Seema Meena, IBM Software Group India, seemeena@in.ibm.com 2008 IBM Corporation Copyright

More information

1. Introduction. Annex 7 Software Project Audit Process

1. Introduction. Annex 7 Software Project Audit Process Annex 7 Software Project Audit Process 1. Introduction 1.1 Purpose Purpose of this document is to describe the Software Project Audit Process which capable of capturing different different activities take

More information

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur Module 1 Introduction to Software Engineering Lesson 2 Structured Programming Specific Instructional Objectives At the end of this lesson the student will be able to: Identify the important features of

More information

SOFTWARE ENGINEERING INTERVIEW QUESTIONS

SOFTWARE ENGINEERING INTERVIEW QUESTIONS SOFTWARE ENGINEERING INTERVIEW QUESTIONS http://www.tutorialspoint.com/software_engineering/software_engineering_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Software Engineering

More information

ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition

ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition Version 0.6 - Page 3 / 43 Table of Contents 1. Process Introduction... 5 1.1. Process Scope... 5 1.2. Process Objectives and Benefits... 5

More information

Baseline Code Analysis Using McCabe IQ

Baseline Code Analysis Using McCabe IQ White Paper Table of Contents What is Baseline Code Analysis?.....2 Importance of Baseline Code Analysis...2 The Objectives of Baseline Code Analysis...4 Best Practices for Baseline Code Analysis...4 Challenges

More information

CUT COSTS, NOT PROJECTS

CUT COSTS, NOT PROJECTS CUT COSTS, NOT PROJECTS Understanding and Managing Software Development Costs A WEBINAR for State of Washington Agencies Critical Logic, Inc. July 9 2009 Starting at 3pm, Pacific Daylight Time Critical

More information

Description of Services for A Quality Assurance Engineer for SQA Assignment for eservices Development Projects ICTA/CON/IC/P5/411B

Description of Services for A Quality Assurance Engineer for SQA Assignment for eservices Development Projects ICTA/CON/IC/P5/411B Description of Services for A Quality Assurance Engineer for SQA Assignment for eservices Development Projects ICTA/CON/IC/P5/411B 1. Introduction The Information and Communication Technology Agency of

More information

Software Quality Metrics Overview

Software Quality Metrics Overview 4 Software Quality Metrics Overview Software metrics can be classified into three categories: product metrics, process metrics, and project metrics. Product metrics describe the characteristics of the

More information

Software Project Audit Process

Software Project Audit Process Software Project Audit Process Version 1.2 Information and Communication Technology Agency of Sri Lanka July 2013 Copyright 2011 ICTA Software Project Audit Process-v-1.2 Revision History Date Version

More information

White Paper from Global Process Innovation. Fourteen Metrics for a BPM Program

White Paper from Global Process Innovation. Fourteen Metrics for a BPM Program White Paper from Global Process Innovation by Jim Boots Fourteen Metrics for a BPM Program This white paper presents 14 metrics which may be useful for monitoring progress on a BPM program or initiative.

More information

Keywords Software metrics; Software quality; Customer Satisfaction; Statistical tools; Metrics Analysis; Quality Assurance metrics

Keywords Software metrics; Software quality; Customer Satisfaction; Statistical tools; Metrics Analysis; Quality Assurance metrics Volume 4, Issue 8, August 2014 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Framework for

More information

A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review

A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review Susan M. Mitchell and Carolyn B. Seaman Information Systems Department,

More information

Software Testing. Knowledge Base. Rajat Kumar Bal. Introduction

Software Testing. Knowledge Base. Rajat Kumar Bal. Introduction Software Testing Rajat Kumar Bal Introduction In India itself, Software industry growth has been phenomenal. IT field has enormously grown in the past 50 years. IT industry in India is expected to touch

More information

Knowledge Infrastructure for Project Management 1

Knowledge Infrastructure for Project Management 1 Knowledge Infrastructure for Project Management 1 Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur Kanpur, India 208016 Jalote@iitk.ac.in Abstract In any

More information

A Capability Maturity Model (CMM)

A Capability Maturity Model (CMM) Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability

More information

A Framework for Project Metrics

A Framework for Project Metrics A Framework for Project Metrics Deciding what to measure and how to measure it August 13, 2007 Dr. Gary J. Evans, PMP CVR/IT Consulting LLC www.cvr-it.com Welcome! Focus of this workshop: Project Metrics

More information

Definitions. Software Metrics. Why Measure Software? Example Metrics. Software Engineering. Determine quality of the current product or process

Definitions. Software Metrics. Why Measure Software? Example Metrics. Software Engineering. Determine quality of the current product or process Definitions Software Metrics Software Engineering Measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. Number of errors Metric -

More information

Software Process for QA

Software Process for QA Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called

More information

Optimization of Software Quality using Management and Technical Review Techniques

Optimization of Software Quality using Management and Technical Review Techniques Optimization of Software Quality using Management and Technical Review Techniques Inibehe Emmanuel Akpannah Post Graduate Student (MSc. Information Technology), SRM University, Chennai, India Abstract

More information

Biometrics Enterprise Architecture Project Management Plan (BMEA PMP)

Biometrics Enterprise Architecture Project Management Plan (BMEA PMP) Biometrics Enterprise Architecture Project Management Plan (BMEA PMP) Version 1.0 Prepared by: Date: November 24, 2008 Revision History Purpose Revision Date Level 11/17/2009 First Draft 1.0 Responsible

More information

SOFTWARE ESTIMATING RULES OF THUMB. Version 1 - April 6, 1997 Version 2 June 13, 2003 Version 3 March 20, 2007

SOFTWARE ESTIMATING RULES OF THUMB. Version 1 - April 6, 1997 Version 2 June 13, 2003 Version 3 March 20, 2007 SOFTWARE ESTIMATING RULES OF THUMB Version 1 - April 6, 1997 Version 2 June 13, 2003 Version 3 March 20, 2007 Abstract Accurate software estimating is too difficult for simple rules of thumb. Yet in spite

More information

Process Improvement. Objectives

Process Improvement. Objectives Process Improvement Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1 Objectives To explain the principles of software process improvement To explain how software process factors

More information

PROJECT RISK MANAGEMENT

PROJECT RISK MANAGEMENT PROJECT RISK MANAGEMENT DEFINITION OF A RISK OR RISK EVENT: A discrete occurrence that may affect the project for good or bad. DEFINITION OF A PROBLEM OR UNCERTAINTY: An uncommon state of nature, characterized

More information

EVALUATING METRICS AT CLASS AND METHOD LEVEL FOR JAVA PROGRAMS USING KNOWLEDGE BASED SYSTEMS

EVALUATING METRICS AT CLASS AND METHOD LEVEL FOR JAVA PROGRAMS USING KNOWLEDGE BASED SYSTEMS EVALUATING METRICS AT CLASS AND METHOD LEVEL FOR JAVA PROGRAMS USING KNOWLEDGE BASED SYSTEMS Umamaheswari E. 1, N. Bhalaji 2 and D. K. Ghosh 3 1 SCSE, VIT Chennai Campus, Chennai, India 2 SSN College of

More information

SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART

SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART Software Productivity Research an Artemis company SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART Capers Jones, Chief Scientist Emeritus Six Lincoln Knoll Lane Burlington, Massachusetts 01803

More information

Basic Testing Concepts and Terminology

Basic Testing Concepts and Terminology T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts

More information

And the Models Are 16-03-2015. System/Software Development Life Cycle. Why Life Cycle Approach for Software?

And the Models Are 16-03-2015. System/Software Development Life Cycle. Why Life Cycle Approach for Software? System/Software Development Life Cycle Anurag Srivastava Associate Professor ABV-IIITM, Gwalior Why Life Cycle Approach for Software? Life cycle is a sequence of events or patterns that are displayed in

More information

Set Up and Operation of a Design Process Measurement System

Set Up and Operation of a Design Process Measurement System Set Up and Operation of a Design Process Measurement System Included below is guidance for the selection and implementation of design and development process measurements. Specific measures can be found

More information

CSTE Mock Test - Part I - Questions Along with Answers

CSTE Mock Test - Part I - Questions Along with Answers Note: This material is for Evaluators reference only. Caters to answers of CSTE Mock Test - Part I paper. 1. A branch is (Ans: d) a. An unconditional transfer of control from any statement to any other

More information

Project Risks. Risk Management. Characteristics of Risks. Why Software Development has Risks? Uncertainty Loss

Project Risks. Risk Management. Characteristics of Risks. Why Software Development has Risks? Uncertainty Loss Project Risks Risk Management What can go wrong? What is the likelihood? What will the damage be? What can we do about it? M8034 @ Peter Lo 2006 1 M8034 @ Peter Lo 2006 2 Characteristics of Risks Uncertainty

More information

Introduction to Software Engineering. 8. Software Quality

Introduction to Software Engineering. 8. Software Quality Introduction to Software Engineering 8. Software Quality Roadmap > What is quality? > Quality Attributes > Quality Assurance: Planning and Reviewing > Quality System and Standards 2 Sources > Software

More information

Cisco Change Management: Best Practices White Paper

Cisco Change Management: Best Practices White Paper Table of Contents Change Management: Best Practices White Paper...1 Introduction...1 Critical Steps for Creating a Change Management Process...1 Planning for Change...1 Managing Change...1 High Level Process

More information

Useful Automated Software Testing Metrics

Useful Automated Software Testing Metrics Useful Automated Software Testing Metrics By Thom Garrett IDT, LLC Adapted from the book Implementing Automated Software Testing, by Elfriede Dustin, Thom Garrett, Bernie Gauf Author Bio: Thom Garrett

More information

Introduction to Software Engineering. 9. Project Management

Introduction to Software Engineering. 9. Project Management Introduction to Software Engineering 9. Project Management Roadmap > Risk management > Scoping and estimation > Planning and scheduling > Dealing with delays > Staffing, directing, teamwork 2 Literature

More information

WHITE PAPER. Effectively managing project performance reporting.

WHITE PAPER. Effectively managing project performance reporting. WHITE PAPER Effectively managing project performance reporting. Summary This white paper helps project teams identify performance measures for Information Technology (IT) support and maintenance projects,

More information

copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.

copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. Software Engineering: A Practitioner s Approach, 6/e Chapter 26 Quality Management copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student

More information

Brillig Systems Making Projects Successful

Brillig Systems Making Projects Successful Metrics for Successful Automation Project Management Most automation engineers spend their days controlling manufacturing processes, but spend little or no time controlling their project schedule and budget.

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Analysis, Design and Implementation Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Programs to Application Systems Products Software Development:

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Individual Programs to Complete Application Systems Software Development: Goals, Tasks, Actors,

More information

Nova Software Quality Assurance Process

Nova Software Quality Assurance Process Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance

More information

Application Support Solution

Application Support Solution Application Support Solution White Paper This document provides background and administration information on CAI s Legacy Application Support solution. PRO00001-MNGMAINT 080904 Table of Contents 01 INTRODUCTION

More information

Basic Trends of Modern Software Development

Basic Trends of Modern Software Development DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development 2 3 Software Engineering FAQ What is software engineering? An engineering

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

Role of Software Quality Assurance in Capability Maturity Model Integration

Role of Software Quality Assurance in Capability Maturity Model Integration Role of Software Quality Assurance in Capability Maturity Model Integration Rekha Chouhan 1 Dr.Rajeev Mathur 2 1 Research Scholar, Jodhpur National University, JODHPUR 2 Director, CS, Lachoo Memorial College

More information

The «SQALE» Analysis Model An analysis model compliant with the representation condition for assessing the Quality of Software Source Code

The «SQALE» Analysis Model An analysis model compliant with the representation condition for assessing the Quality of Software Source Code The «SQALE» Analysis Model An analysis model compliant with the representation condition for assessing the Quality of Software Source Code Jean-Louis Letouzey DNV IT Global Services Arcueil, France jean-louis.letouzey@dnv.com

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

Webpage: www.ijaret.org Volume 2, Issue VII July 2014 ISSN 2320-6802

Webpage: www.ijaret.org Volume 2, Issue VII July 2014 ISSN 2320-6802 A Framework for Software Engineering Metrics for Software Development Firms W.A.L.Madushanka 1, P.H.A.M.De Silva 2, B.A.L.Madhushani 3 M.G.T.H.Malalagama 4, Ivantha Guruge 5 1,2,3,4,5 Sri Lanka Institute

More information

REVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS

REVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS REVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS Lisana Universitas Surabaya (UBAYA), Raya Kalirungkut, Surabaya, Indonesia E-Mail: lisana@ubaya.ac.id

More information

Data Quality Assurance

Data Quality Assurance CHAPTER 4 Data Quality Assurance The previous chapters define accurate data. They talk about the importance of data and in particular the importance of accurate data. They describe how complex the topic

More information

Essential Elements for Any Successful Project

Essential Elements for Any Successful Project In this chapter Learn what comprises a successful project Understand the common characteristics of troubled projects Review the common characteristics of successful projects Learn which tools are indispensable

More information

Driving Quality Improvement and Reducing Technical Debt with the Definition of Done

Driving Quality Improvement and Reducing Technical Debt with the Definition of Done Driving Quality Improvement and Reducing Technical Debt with the Definition of Done Noopur Davis Principal, Davis Systems Pittsburgh, PA NDavis@DavisSys.com Abstract This paper describes our experiences

More information

Chapter 23 Software Cost Estimation

Chapter 23 Software Cost Estimation Chapter 23 Software Cost Estimation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Software cost estimation Predicting the resources required for a software development process

More information

White Paper February 2009. IBM Cognos Supply Chain Analytics

White Paper February 2009. IBM Cognos Supply Chain Analytics White Paper February 2009 IBM Cognos Supply Chain Analytics 2 Contents 5 Business problems Perform cross-functional analysis of key supply chain processes 5 Business drivers Supplier Relationship Management

More information

Coverity White Paper. Effective Management of Static Analysis Vulnerabilities and Defects

Coverity White Paper. Effective Management of Static Analysis Vulnerabilities and Defects Effective Management of Static Analysis Vulnerabilities and Defects Introduction According to a recent industry study, companies are increasingly expanding their development testing efforts to lower their

More information

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at

More information

ITRM Guideline CPM 110-01 Date: January 23, 2006 SECTION 4 - PROJECT EXECUTION AND CONTROL PHASE

ITRM Guideline CPM 110-01 Date: January 23, 2006 SECTION 4 - PROJECT EXECUTION AND CONTROL PHASE PROJECT MANAGEMENT GUIDELINE SECTION 4 - PROJECT EXECUTION AND CONTROL PHASE Table of Contents Introduction... 3 Project Execution and Control Phase Overview... 3 Activities and Documents in the Execution

More information

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS. BCS Level 5 Diploma in IT APRIL 2013 IT PROJECT MANAGEMENT EXAMINERS REPORT

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS. BCS Level 5 Diploma in IT APRIL 2013 IT PROJECT MANAGEMENT EXAMINERS REPORT BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT APRIL 2013 IT PROJECT MANAGEMENT EAMINERS REPORT Section A A1 a) Name FOUR criteria by which a project can

More information

Quality Management. Managing the quality of the software process and products

Quality Management. Managing the quality of the software process and products Quality Management Managing the quality of the software process and products Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 1 Objectives To introduce the quality management process

More information

Project Execution, Monitoring and Control (IS PM 8. Lecture; 2012 Spring)

Project Execution, Monitoring and Control (IS PM 8. Lecture; 2012 Spring) Project Execution, Monitoring and Control Topics of the lecture as follows: PDCA cycle Project execution processes by PMBOK Project monitoring and controlling processes by PMBOK Project monitoring and

More information

Smarter Balanced Assessment Consortium. Recommendation

Smarter Balanced Assessment Consortium. Recommendation Smarter Balanced Assessment Consortium Recommendation Smarter Balanced Quality Assurance Approach Recommendation for the Smarter Balanced Assessment Consortium 20 July 2012 Summary When this document was

More information

Chapter 8: Project Quality Management

Chapter 8: Project Quality Management CIS 486 Managing Information Systems Projects Fall 2003 (Chapter 8), PhD jwoo5@calstatela.edu California State University, LA Computer and Information System Department Chapter 8: Project Quality Management

More information

ST3006 - Software Engineering

ST3006 - Software Engineering University of Dublin Trinity College ST3006 - Software Engineering Anthony Harrington Department of Computer Science Trinity College Dublin Anthony.Harrington@cs.tcd.ie Lifecycles A software project goes

More information

OPTIMISING PROCESSES OF IT ORGANISATION THROUGH SOFTWARE PRODUCTS CONFIGURATION MANAGEMENT

OPTIMISING PROCESSES OF IT ORGANISATION THROUGH SOFTWARE PRODUCTS CONFIGURATION MANAGEMENT OPTIMISING PROCESSES OF IT ORGANISATION THROUGH SOFTWARE PRODUCTS CONFIGURATION MANAGEMENT Lecturer PhD Ion BULIGIU Associate Professor PhD Sorin POPA Associate Professor PhD Liviu Ion CIORA University

More information

Verification and Validation of Software Components and Component Based Software Systems

Verification and Validation of Software Components and Component Based Software Systems Chapter 5 29 Verification and Validation of Software Components and Component Based Christina Wallin Industrial Information Technology Software Engineering Processes ABB Corporate Research christina.wallin@mdh.se

More information

Project Planning. COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe. Software Engineering 2013

Project Planning. COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe. Software Engineering 2013 Project Planning COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe Software Engineering 2013 Overview Assignment: The assignment sheet specifies a minimum Think about what

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

CSSE 372 Software Project Management: Managing Software Projects with Measures

CSSE 372 Software Project Management: Managing Software Projects with Measures CSSE 372 Software Project Management: Managing Software Projects with Measures Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu Dimensional Analysis Abuse Learning

More information

Industry Metrics for Outsourcing and Vendor Management

Industry Metrics for Outsourcing and Vendor Management Industry Metrics for Outsourcing and Vendor Management Scott Goldfarb Q/P Management Group, 10 Bow Street Stoneham, Massachusetts 02180 sgoldfarb@qpmg.com Tel: (781) 438-2692 FAX (781) 438-5549 www.qpmg.com

More information

Keywords: SQA,Black Box Testing( BBT), White Box testing(wbt).

Keywords: SQA,Black Box Testing( BBT), White Box testing(wbt). Volume 3, Issue 10, October 2013 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Enhancing Software

More information

The Importance of Project Quality Management. What Is Project Quality? The International Organization for Standardization (ISO)

The Importance of Project Quality Management. What Is Project Quality? The International Organization for Standardization (ISO) Chapter 8 Project Quality Management November 17, 2008 2 The Importance of Project Quality Management Many people joke about the poor quality of IT products People seem to accept systems being down occasionally

More information

Lecture 8 About Quality and Quality Management Systems

Lecture 8 About Quality and Quality Management Systems Lecture 8 About Quality and Quality Management Systems Kari Systä 10.03.2014 10.03.2014 TIE-21100/21106; K.Systä 1 Content of today s lecture Two weeks ago we discussed about testing and inspections, that

More information

EPL603 Topics in Software Engineering

EPL603 Topics in Software Engineering Lecture 10 Technical Software Metrics Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740 EPL603 Topics in Software Engineering Topics covered Quality

More information

Construction. Industry Advisor. Winter 2015. Simpler accounting option now available for leasing entities. Impressing your surety in an iffy economy

Construction. Industry Advisor. Winter 2015. Simpler accounting option now available for leasing entities. Impressing your surety in an iffy economy Construction Industry Advisor Winter 2015 Simpler accounting option now available for leasing entities Succession planning Will your buy-sell agreement work when you need it? Impressing your surety in

More information

SOFTWARE PROJECT MANAGEMENT

SOFTWARE PROJECT MANAGEMENT SOFTWARE PROJECT MANAGEMENT http://www.tutorialspoint.com/software_engineering/software_project_management.htm Copyright tutorialspoint.com The job pattern of an IT company engaged in software development

More information

Chapter 9 Software Evolution

Chapter 9 Software Evolution Chapter 9 Software Evolution Summary 1 Topics covered Evolution processes Change processes for software systems Program evolution dynamics Understanding software evolution Software maintenance Making changes

More information

Application Performance Testing Basics

Application Performance Testing Basics Application Performance Testing Basics ABSTRACT Todays the web is playing a critical role in all the business domains such as entertainment, finance, healthcare etc. It is much important to ensure hassle-free

More information

SOFTWARE QUALITY - QUALITY COMPONENTS SOFTWARE ENGINEERING SOFTWARE QUALITY THE QUALITY SYSTEM. THE QUALITY SYSTEM (cont d)

SOFTWARE QUALITY - QUALITY COMPONENTS SOFTWARE ENGINEERING SOFTWARE QUALITY THE QUALITY SYSTEM. THE QUALITY SYSTEM (cont d) SOFTWARE ENGINEERING SOFTWARE QUALITY Today we talk about software process quality and certification SOFTWARE QUALITY - QUALITY COMPONENTS Objective quality component: properties that can be measured or

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information